On Thu, Mar 3, 2011 at 11:58 PM, Michael Foord <fuzzyman at voidspace.org.uk> wrote: >>> >>> Without this option interrupting a test run with a ctrl-c kills the run >>> and >>> reports nothing. Seeing an unexpected failure or error during a long test >>> run and having to wait to the end of the test run to see the traceback >>> can >>> be annoying, this feature solves that problem. >> >> Why not just leave this behavior by default and just return -1 if the >> Ctrl-C was pressed? >> > > Because it means installing a signal handler which is not necessarily > appropriate for all test systems. We *could* make it the default in the > future (for the test runner only - not when unittest is used via the api). What does it mean - "not approriate"? Do signal handlers crash or kill people on some test systems? If tests are run with output buffering then it's reasonable to turn off handling of Ctrl-C. If they are executed by buildbots, I don't see how it hurts the test process. In any case there should be a way to turn Ctrl-C handing using some internal flag, but moving it into user command doesn't seem like a good idea to me. By the way, is calling unittest.main() is using unittest via api? > So you want it on by default but are also worried about the backwards > compatibility issues of it even existing as an option? Anyway, your > assertion that the option is or may be useless is unfounded. Don't worry > about it. I am worried that I won't have space to add more useful options to the runner or they will be lost for users in the abundance of highly technical parameters that runner provides. I am concerned that users will never ever understand the true Awesomeness of the New Runner (tm). ;) -- anatoly t.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4