
On comp.lang.python, "Juergen A. Erhard" <jae@ilk.de> wrote about cursesmodule:
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.) -- A.M. Kuchling http://starship.python.net/crew/amk/ When a man tells you that he got rich through hard work, ask him *whose*? -- Don Marquis

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/)

Guido van Rossum writes:
Fine. I'll post to c.l.p and ask if anyone wants to maintain it. If no one expresses an interest, I'll happily wrap the module up neatly and put it someplace (python.org? my Starship pages? www.mems-exchange.org?). But I'm *not* interested in maintaining the plain curses module in future. -- A.M. Kuchling http://starship.python.net/crew/amk/ [John] Dalton's records, carefully preserved for a century, were destroyed during the World War II bombing of Manchester. It is not only the living who are killed in war. -- Isaac Asimov

Guido> I vote for #3 -- I have zero interest in curses, and it is Guido> probably better off having its own website, Vaults of Parnassus Guido> entry, etc., than being in the core and utterly unmaintained. Guido> Note that we have a similar situation with the BSDDB module: the Guido> distribution contains a wrapper for BSDDB 1.85, while someone Guido> else maintains a wrapper for Sleepycat's BSDDB 3.x. Which suggests the general question: What modules in the core distribution don't seem to have a maintainer? I guess by default that's Guido or one of the other CNRI folks, but knowing what modules are sort of flapping in the breeze might stimulate some of us to volunteer to shepherd them. Soundex comes to mind. I know Guido doesn't want to continue supporting soundex.c. On the plane from Spokane to SFO today I merged a couple different Python versions I received from Tim & Fred ages ago. If Tim, Fred and I converge on a Python version, what happens? 1. supplant the C version with the Python version 2. discard the C version and me make it available on my web site (sounds like Andrew's option 3) 3. status quo (perhaps Guido's had a change of heart about soundex.c?) With distutils firming up I think we're getting a lot closer to easily supporting many modules outside the core distribution. If we get carried away we can simply change Python's motto to be "weak batteries included" ;-) Skip

Skip Montanaro writes:
Count me converged on whatever you find useful re: soundex. I don't really care about it; that code was generated by my monkey thread. (I have a few background threads that do nothing but generate random Python code; that was one product of all that, "Documenting Python" was another. ;) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives

On Fri, 25 Feb 2000, Andrew M. Kuchling wrote:
2) Include the ncurses version of the module, backward compatibility be damned.
I think I'm for it. I'm not sure if the backward compatibility problem would be so hard. (I actually did use curses, with the Python module) -- Moshe Zadka <mzadka@geocities.com>. INTERNET: Learn what you know. Share what you don't.

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/)

Guido van Rossum writes:
Fine. I'll post to c.l.p and ask if anyone wants to maintain it. If no one expresses an interest, I'll happily wrap the module up neatly and put it someplace (python.org? my Starship pages? www.mems-exchange.org?). But I'm *not* interested in maintaining the plain curses module in future. -- A.M. Kuchling http://starship.python.net/crew/amk/ [John] Dalton's records, carefully preserved for a century, were destroyed during the World War II bombing of Manchester. It is not only the living who are killed in war. -- Isaac Asimov

Guido> I vote for #3 -- I have zero interest in curses, and it is Guido> probably better off having its own website, Vaults of Parnassus Guido> entry, etc., than being in the core and utterly unmaintained. Guido> Note that we have a similar situation with the BSDDB module: the Guido> distribution contains a wrapper for BSDDB 1.85, while someone Guido> else maintains a wrapper for Sleepycat's BSDDB 3.x. Which suggests the general question: What modules in the core distribution don't seem to have a maintainer? I guess by default that's Guido or one of the other CNRI folks, but knowing what modules are sort of flapping in the breeze might stimulate some of us to volunteer to shepherd them. Soundex comes to mind. I know Guido doesn't want to continue supporting soundex.c. On the plane from Spokane to SFO today I merged a couple different Python versions I received from Tim & Fred ages ago. If Tim, Fred and I converge on a Python version, what happens? 1. supplant the C version with the Python version 2. discard the C version and me make it available on my web site (sounds like Andrew's option 3) 3. status quo (perhaps Guido's had a change of heart about soundex.c?) With distutils firming up I think we're getting a lot closer to easily supporting many modules outside the core distribution. If we get carried away we can simply change Python's motto to be "weak batteries included" ;-) Skip

Skip Montanaro writes:
Count me converged on whatever you find useful re: soundex. I don't really care about it; that code was generated by my monkey thread. (I have a few background threads that do nothing but generate random Python code; that was one product of all that, "Documenting Python" was another. ;) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives

On Fri, 25 Feb 2000, Andrew M. Kuchling wrote:
2) Include the ncurses version of the module, backward compatibility be damned.
I think I'm for it. I'm not sure if the backward compatibility problem would be so hard. (I actually did use curses, with the Python module) -- Moshe Zadka <mzadka@geocities.com>. INTERNET: Learn what you know. Share what you don't.
participants (5)
-
Andrew M. Kuchling
-
Fred L. Drake, Jr.
-
Guido van Rossum
-
Moshe Zadka
-
Skip Montanaro