[issue2889] curses for windows (alternative patch)

[Zach Hirsch]

Zach Hirsch <zhirsch at umich.edu> added the comment:

> * test_curses: I'd be happier to see the 'if' statement as sys.platform
> != 'win32' and (not term or term == 'unknown')  -- easier to read.

OK, fixed.

> * test_curses: does putp() make PDCurses crash, or is it not available?
>  If the latter, I'd prefer to see 'if hasattr(curses, "putp"): <putp
test>'.    Same for the tparm() test.

They're stubs in pdcurses that always return an error. I'm not sure
which is better in this case -- make them available through the curses
module but always raise an exception on Windows, or make them
unavailable and have it be an AttributeError if something tries to call
them on Windows.

> * Given that you include term.h and IRIX included term.h, I wonder if we
> should make _cursesmodule.c include term.h on all platforms that have
it, and then fix the resulting breakage claimed by the comment (if any).

Yea, it was actually really easy to resolve the conflicts. I've done
that, and tested the result on Linux and OS X 10.4.

> * Is setupterm() a no-up on Windows?  Maybe the function just shouldn't
> be defined on Windows, then, so that user code can check for the
function's existence.

PDCurses does the same thing for setupterm as it does for putp/tparm
(and a number of other unsupported functions) -- always returns an
error. However, the curses module keeps track of whether it's been
initialized based on whether setupterm has been called, so I think it
makes sense to keep setupterm available but not call PDCurses's
setupterm function on Windows.

----------
message_count: 4.0 -> 5.0
Added file: http://bugs.python.org/file13282/python-pdcurses-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2889>
_______________________________________