Repository navigation
curses for windows (alternative patch) #47138
Description
| BPO | 2889 |
|---|---|
| Nosy | @loewis, @pfmoore, @jkloth, @Trundle, @ipatrol, @ulfalizer, @madebr |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2008-05-16.06:38:26.189>
labels = ['extension-modules', 'type-feature', 'OS-windows']
title = 'curses for windows (alternative patch)'
updated_at = <Date 2021-04-05.14:37:31.276>
user = 'https://bugs.python.org/techtonik'bugs.python.org fields:
activity = <Date 2021-04-05.14:37:31.276>
actor = 'jkloth'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Extension Modules', 'Windows']
creation = <Date 2008-05-16.06:38:26.189>
creator = 'techtonik'
dependencies = []
files = ['10339', '10340', '12862', '13282', '15171', '20492', '20493']
hgrepos = []
issue_num = 2889
keywords = ['patch']
message_count = 23.0
messages = ['66920', '67288', '80554', '82781', '83365', '94309', '114011', '114013', '114370', '114399', '114740', '114770', '114778', '116224', '126887', '128191', '185746', '222640', '236384', '237855', '237857', '349089', '375683']
nosy_count = 16.0
nosy_names = ['loewis', 'paul.moore', 'techtonik', 'jkloth', 'rpetrov', 'zhirsch', 'Trundle', 'cgohlke', 'jmb', 'ipatrol', 'Prasun Ratn', 'christoph.baumgartner', 'Taylor.Marks', 'Mario Figueiredo', 'ulfalizer', 'maarten']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue2889'
versions = ['Python 3.3']
Activity
techtonik commentedon May 16, 2008
Make curses available on Windows by using PDCurses library. Alternative
patch for bpo-1005895 using current trunk.
Attached .bat file is used to compile it under MinGW, but I'd be glad to
know how to integrate the patch into Python build system.
PDCurses includes support for mouse functions compatible with ncurses,
but to turn it on if requires to define NCURSES_MOUSE_VERSION to 2
before <curses.h> is included. I am not familiar with configure.* stuff,
so I've just pasted required definitions into _cursesmodule.c
With attached .bat file it works by external definition.
Some functions, such as initterm are not available on Windows platform
and were defined out.
I hope that curses module will be included in next Python 2.6
loewis commentedon May 24, 2008
The patch, in its current form, is incomplete. Can you please provide:
a) a VS 2008 project file, which builds both the curses module and the
pdcurses library, fetching the sources for that from ../../pdcurses (or
some such); the project file should be structured similar to all the
other project files in PCbuild
b) a patch to PCbuild/readme.txt, with instructions on how to build the
extension
zhirsch commentedon Jan 26, 2009
Here's a patch against the head of trunk that adds vcproj files for
_curses and _curses_panel, modifies (slightly) the test suite and
_cursesmodule.c (again, slightly) to get Python to work with pdcurses on
windows. I also added a blurb to PCbuild\readme.txt.
With this, test_curses.py passes and I'm able to run all the curses
demos that come with Python's source.
akuchling commentedon Feb 26, 2009
I can't say anything about the Windows build aspects. Some observations
about the curses/test_curses changes:
test_curses: I'd be happier to see the 'if' statement as sys.platform
!= 'win32' and (not term or term == 'unknown') -- easier to read.
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.
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).
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.
zhirsch commentedon Mar 9, 2009
OK, fixed.
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.
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.
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.
jmb commentedon Oct 21, 2009
I've built a package for python 2.6 using a slightly modified version of
this patch. I've uploaded it here: http://jeberger.free.fr/python/
I'm attaching my version of the patch here. I had to make two
modifications for it to work:
done better since what I did will break the ncurses compatibility);
compatible between curses implementations.
With this package, I've been able to run the Mercurial "crecord"
extension on Windows.
ipatrol commentedon Aug 15, 2010
Any progress yat?
loewis commentedon Aug 15, 2010
It can't go into 2.x anymore.
BreamoreBoy commentedon Aug 19, 2010
Brian or Tim any interest in this?
tjguk commentedon Aug 19, 2010
I'll pick it up for the moment to shepherd it along because I'm reasonably keen to see a Windows curses in the stdlib. However, I'm no expert in curses and I don't promise to do anything immediate with it.
rpetrov commentedon Aug 23, 2010
-1 for PDCurses
14 remaining items
erlend-aasland commentedon May 20, 2022
@pfmoore:
+1
Also, the windows-curses package seems to be fairly up to date for those who want to use PDCurses on Windows.
AA-Turner commentedon May 28, 2022
Closing as windows-curses exists, and per Paul & Erlend. If someone would like to do the work to implement curses on windows, we could re-open this issue or discuss in a new one (referencing 3.12+ rather than 3.6!)
A
irvinren commentedon Nov 24, 2023
Windows-curses quit silently on Cpython3.12. is it possible to reopen this issue?
irvinren commentedon Dec 1, 2023
@AA-Turner
windows-curses stopped active development and looking for another maintainer, is it possible to reopen this issue?
zephyrproject-rtos/windows-curses#50 (comment)
erlend-aasland commentedon Dec 4, 2023
See also #40725.
irvinren commentedon Dec 4, 2023
that one seems not for MSVC compiler. Could I directly try this patch?
erlend-aasland commentedon Dec 4, 2023
I'm not sure which patch you are referring to, but I'd expect all the attached files both in this issue and #40725 to be seriously outdated; I would not expect any of these to merge cleanly into
main, and even if they would merge "cleanishly", I would not expect them to compile. Any attempt at getting this ball rolling again would have to start by either adapting one of the outdated patches to work with the current C API, or by writing the extension module from scratch.cgohlke commentedon Dec 5, 2023
FWIW, I moved the code and build script used for https://www.lfd.uci.edu/~gohlke/pythonlibs/#curses to https://github.com/cgohlke/python-curses-build
ashm-dev commentedon Nov 13, 2025
Ping. Is this issue still relevant?