No putp()/tigetflag()/tigetnum()/... (term.h) makes it messy to build Python wheels about pdcurses HOT 5 CLOSED

In retrospect, I think it was a terrible mistake to ever include them. I'm not inclined to bring them back.

Linking _cursesmodule.c against PDCurses didn't actually work anyway, did it? I mean, in terms of the result being usable. That's why there are multiple alternative Python curses interfaces to work with PDCurses, is it not?

I think the correct approach would be to make Python's curses API more portable. Relying on non-working stubs is not the way. (And, it's mostly not possible to make them work -- PDCurses just isn't designed that way at all.)

from pdcurses.

Works fine after making some minor modifications and #defining a few macros.

The README in the windows-curses repository has an overview of how _cursesmodule.c fits into things. I think all Python/PDCurses integrations link against it. The prebuilt wheels from Christoph Gohlke also do (windows-curses is just those wheels set up for rebuilding).

We've been using it to make a menuconfig interface available on Windows in addition to Linux. The only special-casing in the code is related to resizing (see _get_wch_compat() in menuconfig.py).

from pdcurses.

Random idea:

Do you think they could be hidden behind a PDCurses compile-time setting? That way, you'd have to explicitly ask for them, and you wouldn't get code compliling but silently failing because it expects the stubs to work otherwise.

Can see if you don't want to litter the code up like that though.

from pdcurses.

Try to compile (and link) a copy of terminfo.c when building the _cursesmodule Python extension with the new PDCurses. Works for me.

from pdcurses.

@cgohlke
Seems like the least painful option. Thanks for the idea!

from pdcurses.