This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author zhirsch
Recipients akuchling, loewis, techtonik, zhirsch
Date 2009-03-09.09:56:48
SpamBayes Score 1.66533e-16
Marked as misclassified No
Message-id <>
> * 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.
Date User Action Args
2009-03-09 09:56:54zhirschsetrecipients: + zhirsch, loewis, akuchling, techtonik
2009-03-09 09:56:54zhirschsetmessageid: <>
2009-03-09 09:56:53zhirschlinkissue2889 messages
2009-03-09 09:56:51zhirschcreate