I have an app which wants to use a mostly curses interface with some
parts readline, however, doing so much as "import readline" causes
readline to claim ownership of sigwinch, thus breaking the ability of
the app to resize.

Worse, it seems to claim it at the C level -- doing signal.getsignal
(signal.SIGWINCH) returns SIG_DFL, so I can't see anything I can do at
the python level to manually set the signals to be handled in the way I
want :-/

I would think it best to set the handler at the start (for
compatability, and because the vast majority of apps will expect it
that way), but set it via python's signal module, so that app writers
can take the signal handler and call it in their own way (In my case, I
want the app to listen for the signal, and the app's handler will call
readline's and curses's handlers in turn)

See related(?) bpo-3180.

Is this actually about how SIGWINCH handlers are installed, or is it a complaint about readline affecting how curses handles resize events? I am assuming this is about handling resize events, so is a duplicate of bpo-2675.

If it is specifically about SIGWINCH, I understand Gnu Readline recently changed its SIGWINCH handling so that it only installs the handler when it is active. As a result, we recently changed Python to install its own SIGWINCH handler on behalf of Readline (bpo-23735). But I understand in both cases, the handler for Readline chain calls the original handler, so there should be no problem.