[devjoe]

This PR comes from https://bugs.python.org/issue22135.
I mainly use registered signal_handler to handle Ctrl-C behavior and add a unit test.

https://bugs.python.org/issue22135

• Issue: allow to break into pdb with Ctrl-C for all the commands that resume execution #66333

[devjoe]

@blueyed thanks for your super fast feedback, will refine this PR in the following days.

[devjoe]

PR updated, feel free to let me know your thoughts.

[devjoe]

@blueyed 🙏

[blueyed]

@devjoe
LGTM (only skimmed it quickly now), but I am not in the position to really judge / acknowledge it unfortunately.

[devjoe]

@xdegaye sorry for bothering you, could help to review this PR again? 🙏

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[devjoe]

@gaogaotiantian
Thanks for your sharing in PyConTW 2026. It reminds me of this old PR and motivates me to wrap it up.

As of now, next, until, and return still have the same behavior (Ctrl+C interrupts the program with KeyboardInterrupt) in Linux and Windows.

Do you think it is worth making next, until, and return aligning to continue's behavior when Ctrl+C is fired?

[gaogaotiantian]

What's the reason to change sigint_handler? Is it necessary? You also changed the behavior for ctrl+c in continue - is that indended as well?

[devjoe]

In my original implementation, the reasons of changing sigint_handler were:

1. Taking issue24283 into consideration, so a try ... catch is introduced
2. Simplifying the logic for continue (removes redundant self.set_step() before self.set_step() because at 2019 self.set_step() is called in self.set_trace())
3. Adding SIGINT handling for next , until , and return using self.set_step() . However, this does not reliably stop inside an already-running child frame that is not being traced.

Based on the current codebase, I propose the following scope for this PR:

1. Ignore issue24283 and do not bring in such complexity here
2. Remove the use of self.set_step() in sigint_handler to avoid an unwanted situation when any breakpoint exists (see the first snapshot below)
3. Let next, until, return, and continue share the same architecture as possible (i.e. by using self.set_trace() in siginit_handler)
4. Fix a handler restoration edge case when a user defines his own signal.signal(signal.SIGINT, new_handler) during continue (see the second snapshot below)

Would this be a reasonable scope for the PR?

[gaogaotiantian]

Let's handle one thing at a time. Can you just do the same mechanism in step, next and until as continue?

[devjoe]

Sure. It makes the implementation easier and simpler.

Just to confirm the scope: you want to include step instead of return, right?

[python-cla-bot]

All commit authors signed the Contributor License Agreement.

[read-the-docs-community]

Documentation build overview

📚 cpython-previews | 🛠️ Build #35690736 | 📁 Comparing 6e8ab89 against main (d7ea5ba)

  🔍 Preview build  

124 files changed · ± 124 modified

± Modified

• builtins/exceptions.html
• builtins/functions.html
• builtins/stdtypes.html
• builtins/threadsafety.html
• c-api/bool.html
• c-api/code.html
• c-api/codec.html
• c-api/dict.html
• c-api/extension-modules.html
• c-api/frame.html
• and 114 more...

[devjoe]

@gaogaotiantian

I’ve revised the patch so that step, next, and until use the same SIGINT handling as continue.

The main changes are:

1. Keep sigint_handler() as close to its existing implementation as possible.
2. Remove the redundant self.set_step() call from sigint_handler(), since set_trace(frame) already sets up the next stop.
3. Extract the SIGINT handler setup from do_continue() into a shared _install_sigint_handler() helper.
4. Override dispatch_call() to avoid stepping into Pdb’s own SIGINT handler.
5. Add tests for Ctrl-C during continue, step, next, and until.
6. Save and restore SIGINT handler state around each doctest to prevent tests from affecting one another.

Feel free to let me know your thoughts.

[devjoe]

Added the support for return. Please take a look again!