[Python-Dev] _cursesmodule linking, and portability

[Eric S. Raymond]

Mark Favas <m.favas@per.dem.csiro.au>:
> Earlier today I uploaded a patch to SF for _cursesmodule.c so that it
> would link on Tru64 Unix (Version 4.0F). The problem was that the
> function has_key() is not present on this platform (nor, apparently, on
> SGI or Sun). Moshe queried whether this patch was required to link
> against ncurses on Tru64. ncurses does not exist on Tru64. Access to the
> functionality of V 4 of the X/Open curses API spec is enabled by the
> macro _XOPEN_SOURCE_EXTENDED - neither the header file nor the (only)
> curses library have any reference to has_key(). I am not a curses person
> (except when... <wink>), so I do not know whether has_key() is part of
> the _standard_ (new?) curses, but I am concerned that the
> _cursesmodule.c code exposes this interface for all but SGI, Sun and
> Tru64 systems. What happens when Python code is written that uses this
> function? It will fail on at least these three platforms... Should the
> has_key() function be removed, or a wrapper written for those systems
> that don't support this function?

OK.  The story is this:

1. has_key() is unique to ncurses.  It's not specified in the 
   X/Open curses API.  

2. We added it for a reason :-).  It's hard to write programs that adapt to
   different numbers of function keys without it -- and this is still an issue.
   because that number still varies even though all the world is a VT100 
   emulator these days.

So I recommend trying to add has_key to the curses module interface in Python,
conditionalized on whether you can pick it out of the local curses headers.
You can use the implementation in ncurses as a model.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

You know why there's a Second Amendment?  In case the government fails to
follow the first one.
         -- Rush Limbaugh, in a moment of unaccustomed profundity 17 Aug 1993