Re: python3-prompt_toolkit: don't handle sigint

[ahesford <ahesford@users.noreply.github.com>]

[-- Attachment #1: Type: text/plain, Size: 2917 bytes --]

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/pull/35730#issuecomment-1053693604

Comment:
I understand the isssue and how your patch fixes it. Unless upstream merges your proposed handler changes, I will not accept a Void patch that does the same. The two options I *will* accept before upstream makes a decision are:
1. Your original patch to change to change the default SIGINT handling behavior from `True` to `False`, effectively restoring prior behavior and leaving any custom handlers untouched; or
2. A modification of your proposal that drops the conditional `cysignals` dependency and simply saves and restores Python signals in the prompt_toolkit event loop. (This will *not* fix your custom SIGINT problem in C extensions and probably is probably worse than Option 1 from your perspective.)

Option #1 may cause IPython to crash when it receives SIGINT, but that is functionally no worse than a revert to a prior version of `prompt_toolkit` and I can live with it.

Whether `cysignals` supports fewer platforms than `prompt_toolkit` is irrelevant to the discussion of whether it should be a hard dependency of `prompt_toolkit`. Python dependencies can be specified per-platform, so `cysignals` can always be restricted to the platforms where it can be built. However, I suspect that the need to maintain (and test) a platform-specific dependence on `cysignals` may make upstream less likely to accept this approach. For the same reason, I imagine upstream may be disinclined to incorporate its own compiled extension to manage `sigaction`.

The optional dependency on `cysignals` is unattractive because there are many different ways to set handlers via `sigaction` with Python: by compiling a C extension directly, by doing it directly in a Cython module that may have broader purposes or by using some FFI like the built-in `ctypes`. The population of people who rely on `cysignals` is likely to be small; having `prompt_toolkit` take special branches in every iteration of the event loop on the off chance that an arbitrary package is installed does not seem to be the right approach and certainly doesn't cover these alternatives.

Upstream needs to decide whether they even care about this problem and, if so, how to solve it. They might
- Declare `cysignals` as the one true way to manage `sigaction` and add a hard dependency on platforms that can use it
- Implement their own approach to save/restore as they see fit
- Find some other means to save/restore signals
- Accept your conditional approach, which solves the `sigaction` problem for some subset of people who may have actually defined a custom handler
I'm not going to decide among these for upstream.

If you do PR your optional approach upstream, you should probably define a package option to declare the dependency so that the package can advertise the possibility.