[issue25900] unittest ignores the first ctrl-c when it shouldn't

2016-03-13 Thread Robert Collins

Robert Collins added the comment:

I'd rather make this super simple: just terminate the test run immediately. We 
can catch KeyBoardInterrupt in the UI layer to still permit outputting summary 
information. That removes one more source of global state that makes testing 
fragile.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25900] unittest ignores the first ctrl-c when it shouldn't

2015-12-22 Thread Marius Gedminas

Marius Gedminas added the comment:

Somewhat unrelated nitpick: I'm not very happy that _InterruptHandler doesn't 
return early after calling the original handler.

It's all very well, if the original handler raises or does nothing at all, but 
if it's a user-installed handler that does something (e.g. print a stack trace 
to sys.stderr), then it might get called twice (or three times, after my patch).

AFAIU the situation would have to be pretty contrived:

- there's a user-provided SIGINT handler
- unittest installs its own on top
- one of the tests (or some test runner plugin) overrides the SIGINT handler 
again
- user presses Ctrl-C
- the current SIGINT handler delegates to the unittest _InterruptHandler
- _InterruptHandler notices it's not the current handler and delegates to the 
original one
- the original handler doesn't raise
- _InterruptHandler.__call__ doesn't return early and goes on to perform the 
"if called check"
- if this is a second Ctrl-C, the original handler will get called a second 
time for the same Ctrl-C event
- if there are no registered results, my new code will cause the original 
handler to get called again (a third, or a 2nd time for the same Ctrl-C event)

Is there a good reason not to add early returns after defering to the original 
handler?  Maybe it's desired that ^C should stop the test suite even if a test 
overrides the SIGINT handler but delegates back to the unittest one?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25900] unittest ignores the first ctrl-c when it shouldn't

2015-12-22 Thread Marius Gedminas

Marius Gedminas added the comment:

Here's an updated patch with tests

--
Added file: 
http://bugs.python.org/file41383/dont-ignore-first-ctrl-c-with-tests.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25900] unittest ignores the first ctrl-c when it shouldn't

2015-12-22 Thread Marius Gedminas

Marius Gedminas added the comment:

I looked for any existing tests (by grepping for 'signals' and 'import' on the 
same line), didn't find any (because my assumption that 'signals' would have to 
be explicitly imported was wrong).

Wrote some new tests, which made me also make some further changes to 
unittest/signals.py: https://gist.github.com/mgedmin/a91872054884dbaaa344

And that's how I discovered that there's an existing test suite for SIGINT 
handling, in test_break.py, and that it fails after my changes.

Stay tuned.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25900] unittest ignores the first ctrl-c when it shouldn't

2015-12-21 Thread Michael Foord

Michael Foord added the comment:

Suggested behaviour sounds good, patch looks sensible. Is it possible to add a 
test too?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25900] unittest ignores the first ctrl-c when it shouldn't

2015-12-18 Thread Marius Gedminas

New submission from Marius Gedminas:

unittest.signals._InterruptHandler is very nice: on first ^C it tells any 
registered unittest Result instances to gracefully stop the test run, and on 
any subsequent ^C it defers to the default interrupt handler, which immediately 
terminates the test run (possibly without giving it a chance to output summary 
information).

This doesn't work very well when a test runner forgets to register the Result 
instance: the first ^C is then quietly ignored.  (See 
https://github.com/django-nose/django-nose/issues/252 for an example.)

Suggestion: if there are no registered results in the unittest.signals._results 
dict, don't silently ignore the first ^C.  Instead, immediately defer to the 
saved interrupt handler.

Since code is often clearer than words, I'm attaching a patch.

--
components: Library (Lib)
files: dont-ignore-first-ctrl-c.patch
keywords: patch
messages: 256656
nosy: mgedmin
priority: normal
severity: normal
status: open
title: unittest ignores the first ctrl-c when it shouldn't
type: behavior
Added file: http://bugs.python.org/file41345/dont-ignore-first-ctrl-c.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25900] unittest ignores the first ctrl-c when it shouldn't

2015-12-18 Thread R. David Murray

Changes by R. David Murray :


--
nosy: +michael.foord, rbcollins

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com