the halting problem: when a mutation triggers an infinite loop about mutmut

[boxed]

Ah, yea, I forgot about that. Yes, it should handle this... I already store the time it took for a non-mutated test run so should be fairly trivial. It just makes tests_pass() a bit more complex since I can't have a simple blocking call.

[boxed]

Huh. Seems check_call has a timeout option in Python 3.3+, I think I'll use that. It means you won't get infinite loop checking in lower python versions, but that seems like an ok tradeoff to me. With a warning message I think it's fine. What do you think?

[boxed]

Oh, and I was thinking that the timeout should be baseline_time_elapsed * 10 to be very resistant against timing issues.

[asottile]

Seems fine to me! The first three projects of mine I tried mutmut on hit this pretty quickly (each contained one of the state-machine-like loops). (another non-portable timeout mechanism is signal.alarm -- though the check_call timeout is probably good enough for what I'd want 👍)

I'm also willing to hack on this if you'd like

[boxed]

I'd welcome a PR for sure. Should be just a matter of inserting an extra kwargs on the check_output call if the python version is > 3.3.

If you haven't looked at the source for mutmut yet you'll be surprised and delighted at how super tiny the code is I think :P

[boxed]

It was super trivial and I had some time over, so I fixed this and another bug and rolled a new release. Let me know if it didn't work!