[Python-Dev] Whither cursesmodule?

[Guido van Rossum]

> On comp.lang.python, "Juergen A. Erhard" <jae@ilk.de> wrote about
> cursesmodule:
> > Why two versions?  Did Oliver forget to submit his patches to Guido
> > (et al)?  Or did Guido not accept them?  If so, why not?
> > 
> > What needs to be done to synchronize the canonical Python and the
> > Python RPMs?
> 
> For python-dev readers: Oliver Andrich's Python RPMs contain his
> enhanced cursesmodule, which supports many ncurses features.  The
> cursesmodule in the Python distribution supports only plain curses.
> Question: what should be done about this?
> 
> The problem is that Oliver's enhanced module probably won't work on
> systems that support only BSD curses.  I haven't verified this,
> though.  On the other hand, ncurses implements the SYSV curses API,
> and maybe there are no platforms left that only have plain curses.
> 
> Options:
> 
> 1) Forget about it and leave things as they are.
> 
> 2) Include the ncurses version of the module, backward compatibility
>    be damned.
> 
> 3) Split the curses module out of the standard distribution, and
>    distribute it separately; users then download the plain or ncurses
>    version as they see fit.
>    
> 4) Attempt to make patches for Oliver's module that will make it work 
>    with plain curses.
> 
> I don't like #1; if the code is going to be unmaintained in the
> future, why leave it in at all?  #2 might be OK, if it's the case that
> the SYSV curses API is widespread these days; is it?  I'd be willing
> to take a crack at #4, but have no idea where I could find a system
> with only plain curses.  (Apparently OpenBSD, at least, includes the
> old BSD curses as libocurses.)  

I vote for #3 -- I have zero interest in curses, and it is probably
better off having its own website, Vaults of Parnassus entry, etc.,
than being in the core and utterly unmaintained.  (Also note that long
ago, someone gave me patches for support of color curses; there was
absolutely no interest, so I haven't integrated them.)

Note that we have a similar situation with the BSDDB module: the
distribution contains a wrapper for BSDDB 1.85, while someone else
maintains a wrapper for Sleepycat's BSDDB 3.x.  The reasons for the
fork are a bit different there: BSDDB 3.x, while superior, isn't as
free as 1.85, so some people must use 1.85 (if they want to use it
commercially but don't want to license 3.x from Sleepycat).

--Guido van Rossum (home page: http://www.python.org/~guido/)