On 04/03/2011 01:33, anatoly techtonik wrote:
On Thu, Mar 3, 2011 at 11:58 PM, Michael Foord
<[email protected]> 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?
Because the system under test may use its own signal handlers.
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.
What's more relevant are the following two facts:
* It isn't guaranteed to work, the keyboard interrupt can interrupt code
at any arbitrary point so the system *could* be in an unstable state and
result reporting may then fail.
* It changes the default behaviour of pressing control-c which normally
stops code immediately. This continues to execute an arbitrary amount of
code after pressing control-c.
For all these reasons I think it is better to make it a user option than
on by default. Besides which it is already done and released in two
major versions of Python (2.7 & 3.2).
(The behaviour *is* configurable / controllable via the api - which I
guess is what you mean by "some internal flag". The command line option
is the way to control it when using the default runner and not the api.)
By the way, is calling unittest.main() is using unittest via api?
Not really, that's the standard test runner. Perhaps slightly debatable.
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). ;)
:-)
Well there are only 52 short alphabetical options available, but yes we
should be careful with them and I'm not proposing adding any more at the
moment.
All the best,
Michael Foord
--
http://www.voidspace.org.uk/
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
