In configure.ac there are explicit checks for pre-2.1 Readline versions (and later versions). Maybe it is reasonable to require 4.0 these days. But I think this should only be done in the next Python version (3.6+).

To support Editline (and pre-4.0 Readline versions), I agree some conditional #ifdef thing would probably be best. My version of Editline claims to support 4.2, but doesn’t have rl_resize_terminal().

I played with Readline 6.2 where this resize bug is not present. Getsignal() also returns SIG_DFL there, so I won’t worry too much about that :)

But it seems everything else worked fairly smoothly with 6.2. If you register your own SIGWINCH handler, it seems to be chain called by Readline. However with the current patch there are three differences that I can see to the 6.2 behaviour:

* it overrides the SIGWINCH handler at import
* it does not chain to the old SIGWINCH handler
* the handler in “readline” is lost if another handler is set after import

You say it didn’t work before 6.3; what did you try? Also, I think a custom SIGWINCH handler does currently work with 6.3, and the patch would break that. How do you mean that doesn’t work now?

So I am still a bit concerned that in some circumstances the current patch could break working programs.

Maybe there is a solution that doesn’t need an API change: Only register SIGWINCH in readline_until_enter_or_signal(), and chain call to the original handler as well.

FWIW I am not a fan of signals, because they are hard to handle robustly. But in this case I don’t know of a good alternative. Perhaps we could call pselect() instead of select(), and mask SIGWINCH, but I doubt it is worth the effort (portablility problems?). Or maybe something similar to signal.set_wakeup_fd() would be better.