Suggestion: KeybaordInterrupt pdb

[amosonn]

When debugging infinite-loop issues, it can sometimes be useful to enable dropping to debugger upon Ctrl+C. Currently --pdb only catches other exceptions, KeyboardInterrupt is specifically ignored (runner.py:193, CallInfo.__init__). It would be nice to have a switch that makes it swallow KeyboardInterrupt-s as well instead. It would of course make it harder to quit (although a few consecutive Ctrl+C's usually due the trick), but it's a reasonable price to pay for those cases.

[pytestbot]

GitMate.io thinks possibly related issues are #1948 (--pdbcls implies --pdb), #1461 (Suggestion: merge .fixture and .yield_fixture), #262 (--pdb drops you into pdb if you have an xfail), #1324 (--pdb and yield tests), and #1343 (Can not restart tests from pdb).

[brianmaissy]

I could do this. @nicoddemus sounds reasonable as described? How concerned are we about feature bloat? Is a legitimate use case reason enough to add a feature, or must it also be a reasonably common use case?

[nicoddemus]

Thanks for the offer @brianmaissy, IMHO this sounds useful, I have needed something like this a few times in the past as well. I think adding a new flag seems harmless, but I wonder how the implementation will look like. I would say give it a go and we can discuss this over the PR.

[amosonn]

My "Hacky" implementation simply changed the `KeyboardInterrupt` handler in said place from re-raising to creating a trace object. I suppose this would just need to be bounded by the flag-check. Unless someone has a suggestion of making graceful exit possible - perhaps, in response to `Ctrl+C`, asking the user if they want to terminate or drop to debugger?

…

On 5 April 2018 at 03:51, Bruno Oliveira ***@***.***> wrote: Thanks for the offer @brianmaissy <https://github.com/brianmaissy>, IMHO this sounds useful, I have needed something like this a few times in the past as well. I think adding a new flag seems harmless, but I wonder how the implementation will look like. I would say give it a go and we can discuss this over the PR. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3299 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC_zrWrEdNpXYzV09e5lP9xA0MQDEas5ks5tlXihgaJpZM4SmoQA> .

[blueyed]

I think it should be possible to know if Ctrl-C was emitted when inside pdb already, or outside of it.
In the former case it would not drop into pdb again, but exit.
Related (for ideas/handling): #2619

[RonnyPfannschmidt]

currently i believe the debugging plugin explicitly ignores interrupts to ctrl*c - in order to enable exiting the test run via a interrupt

[amosonn]

Yes, I wrote that in the top post. It's not at the debugging plugin level, it's the whole error-handling mechanism, which doesn't wrap `KeyboardInterrupt`-s but re-raises them instead. AFAIK, pdb ignores `Ctrl+C`, as is to be expected by a shell. I don't know if there's a way to change that behaviour - or if this is wanted, as people expect `Ctrl+C` not to exit their pdb session.

…

On 5 April 2018 at 13:23, Ronny Pfannschmidt ***@***.***> wrote: currently i believe the debugging plugin explicitly ignores interrupts to ctrl*c - in order to enable exiting the test run via a interrupt — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3299 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC_zrYJezpL0Dj4y7MIJyzuECjVJgrCdks5tlf6ggaJpZM4SmoQA> .

[blueyed]

pdb ignores Ctrl+C,

True. Ctrl-C results in (Pdb) --KeyboardInterrupt--

Maybe pytest wrapping could then handle bdb.BdbQuit internally as to not stop again?
This gets raised when using Ctrl-d.

btw: with pdbpp you have pdb.disable() which disables/skips all future set_trace calls: https://github.com/antocuni/pdb/blob/b7e789b836340ecbc131e26f8fd93d74fe652297/pdb.py#L1009-L1012.
I.e. with something like --pdb-on-sigint you could then do import pdb; pdb.disable() when using pdbpp.

But altogether with the new option you would basically only have to replace ctrl-c with ctrl-c + ctrl-d when using the new pdb-on-sigint, no?

[brianmaissy]

The current behavior of KeyboardInterrupt after dropping to pdb is to exit the test session, so I would be inclined to preserve that. It has the added benefit that if you pressed control-C with the intention of stopping the test session and then got a pdb the second control-C will indeed quit.

So I'll go ahead an implement the "naive" approach?

I thought to call the option --pdb-on-keyboard-interrupt and have it imply --pdb. Does that sound right?

[nicoddemus]

The current behavior of KeyboardInterrupt after dropping to pdb is to exit the test session, so I would be inclined to preserve that.

Agreed.

It has the added benefit that if you pressed control-C with the intention of stopping the test session and then got a pdb the second control-C will indeed quit.

I like that.

I thought to call the option --pdb-on-keyboard-interrupt and have it imply --pdb. Does that sound right?

Contrary to what I said in #3299 (comment), perhaps we can avoid adding a new option and let --pdb imply that control-C will enter pdb, and a second control-C quit pdb?

[brianmaissy]

Hmm interesting, I think I like that.

[nicoddemus]

Fixed in #3436, thanks @brianmaissy!