Design of a curses module

Andrew KUCHLING (fnord@cs.mcgill.ca)
15 Jul 1994 16:07:41 GMT

I think a curses module for Python would be a really useful thing. If
anyone is working on one, please get in touch with me; I'd like to
help.

If no one is currently writing a curses module, I'll write one myself.
However, I'm not sure what a good design would be, so I'm throwing the
question out for discussion. Currently I'm thinking of the following
design: (initially I'd implement only the basic set of functions; the
extensions would be added later.)

* The curses module has one top-level function init(), which
would return a screen object that's simply a wrapper around the curses
stdscr variable. init() would automatically call initscr(), cbreak(),
nonl(), and so on; finer control of the terminal's state would not be
possible in the basic functionality. (Possible extension: also have a
newterm() function for handling multiple terminals in one Python
program.)

* Screen objects would then have numerous methods, such as addch,
mvaddch, newwin, refresh, etc. (Extension: Window objects would have the
same methods, when applicable.) (Possible extension 2: Support for pads.)

I'm unsure as to how attributes (underline, standout, etc.)
should be handled. Should functions such as addch() have a second,
optional parameter for the attribute, which defaults to normal text?
Or should we have an attrset() method for screens and windows, which
affects all future output to that screen/window until the next
attrset() call? Personally, I think the first solution is better,
since it seems clearer when you're reading the code, and you don't
have to worry about things like forgetting to turn off standout mode.

Another worry: What if you're running a curses-mode Python
script, and an uncaught exception is raised? Or the sys.exit() method
is called? The terminal might be left in an unusable state, which
should be absolutely avoided. I've no idea how to handle this: I
wouldn't like to dodge the issue and require an exception handler for
all scripts that use curses, but I also wouldn't want to patch the
error handling to have it turn off curses mode automatically, because
that would require making changes outside of the Modules subdirectory.
The best solution, IMHO, is to require calling sys.exitfunc() to
ensure that a curses.endwin() method is called on program exit;
curses.endwin() would also be called from a script's own exit function
to shut down politely. It would be nicer to do it transparently,
without needing to do anything special, but I can't think of a way to
accomplish that.

Thanks in advance...


Andrew Kuchling
fnord@binkley.cs.mcgill.ca