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

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

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.

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.

• 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.

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:

• Change all references to _ISPAD into _PAD (obviously this needs to be
  done better since what I did will break the ncurses compatibility);
• Change "(long) (n << 8)" into "COLOR_PAIR (n)". This should be
  compatible between curses implementations.

With this package, I've been able to run the Mercurial "crecord"
extension on Windows.

Any progress yat?

It can't go into 2.x anymore.

Brian or Tim any interest in this?

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.

-1 for PDCurses

I have no strong opinion, Roumen, (and no experience with the package)
but why -1 from you?

Recent ncurses pass python tests with only one small update (part of patch to bpo-3871):
=====================================

--- ./Lib/test/test_curses.py.MINGW	2010-08-09 00:03:48.000000000 +0300
+++ ./Lib/test/test_curses.py	2010-08-09 00:05:38.000000000 +0300
@@ -167,11 +167,16 @@
     curses.delay_output(1)
     curses.echo() ; curses.echo(1)
 
-    f = tempfile.TemporaryFile()
+    fx = tempfile.TemporaryFile()
+    # cf tempfile.py TemporaryFile vs NamedTemporaryFile
+    if os.name != 'posix' or os.sys.platform == 'cygwin':
+        f = fx.file
+    else:
+        f = fx
     stdscr.putwin(f)
     f.seek(0)
     curses.getwin(f)
-    f.close()
+    fx.close()
 
     curses.halfdelay(1)
     curses.intrflush(1)

=====================================
About TERM environment variable - I don't have time to test ncurses if is not set.

Also PDCurses is not updated since 2008.

PDCurses is not updated, because it is considered stable and mature library that has been tested on Windows platform by many roguelikes. I doubt that ncurses hackers care about Windows compatibility more than just to make it run.

What is the status of this bug?

I tried to build the svn trunk with patches provided by zhirsch but I had problems applying the patches. I went ahead and made a new patch which is pretty similar to the earlier patch (mentioned above). The one change is that I implemented mkstemp() so putwin() and getwin() work.

Curses binaries for Python 2.5, 2.6, 2.7, 3.1 and 3.2, win32 and win-amd64, are available at <http://www.lfd.uci.edu/~gohlke/pythonlibs/#curses\>.

@Christoph Gohlke any chance of providing a build for 3.3?

Can this be closed as curses binaries for Python 2.5, 2.6, 2.7, 3.1, 3.2, 3.3 and 3.4, win32 and win-amd64, are available at <http://www.lfd.uci.edu/~gohlke/pythonlibs/#curses\>, plus there is also https://pypi.python.org/pypi/UniCurses/1.2 ?

Python is supposed to be cross platform. This has been a major incompatibility issue between Windows and *nix and you think this patch, which has been ready for nearly 7 years now, should simply get discarded because the fix is available from pip?

I think there are two possible remedies to this:

• Accept this patch.
• Remove curses from the Python standard library for *nix (breaks backwards compatibility for *nix, but fixes compatibility between Windows and *nix going forward.)

This patch is a huge improvement over the current situation, which is we don't have a cross-platform curses implementation in the standard library.

The alternatives listed by Mark aren't sufficient. For the two reasons given below:

• The implementation at http://www.lfd.uci.edu/~gohlke/pythonlibs/#curses does not support unicode characters, which is a big limitation in today's general computing tasks.

• The UniCurses module isn't compatible with the curses standard lib implementation since it wraps curses/pdcurses and does not provide python own wrappers like the ability of addstr to accept encoded byte strings. This essentially makes UniCurses a 3rd-party library requirements regardless of the operating system, which is always nice to have but does not help the batteries included principles behind python standard library.

Conclusion:
Please implement this patch ASAP. It's been many years since it was made available. It works, it passes all tests and we all benefit if we close this python cross-compatibility issue.

The patch would need updating to be applicable. Minimum changes I would expect to be required:

1. Update to build for Python 3.5 (the patch will *not* be included in earlier versions, as it is a new feature), which means it needs the Visual Studio 2015 build files updating.
2. Rather than wholesale dumping a curses implementation into the Python source (which is what pdcurses.patch seems to do) the appropriate curses source should be fetched via the externals.bat script, like the other external dependencies.
3. Documentation. At a minimum "available in Windows from Python X.Y", but probably also document any differences from Unix, which from the comments here are likely to exist if the patch uses pdcurses on Windows.
4. Tests. Again, make sure that any functionality that differs is properly covered on Windows, or skip specific Unix-only functionality.

That's quite a lot of changes, in practice.

Unless someone is going to step up and do all of that (and keep it maintained until it gets merged, which probably won't be till 3.6) *and* there's one of the core devs willing to support the code going forward once its committed, then I think closing this as "won't fix" and referring to the external packages is the best solution.

A documentation patch to https://docs.python.org/3.4/howto/curses.html ("Curses programming with Python") which explained how to set up one of the external curses modules on Windows, and how to write cross-platform code that uses the core implementation on Unix and the 3rd party module on Windows, would be immensely useful for people interested in this patch. Probably far more so than pushing for this patch to go in, in all honesty, as it's easier to do and would be useful to people on older versions of Python as well.

Just as an FYI, there is a repository for building curses wheels for Windows at https://github.com/zephyrproject-rtos/windows-curses, based on patches from here and Gohlke's work.

Building wheels is less straightforward than it used to be, e.g. due to term.h disappearing from PDCurses.

We also make wheels available on PyPI.

Current ncurses master is buildable on Visual Studio, using msys2.

It should be possible to create a vcxproject and integrate it in the Visual Studio build.

@pfmoore:

Unless someone is going to step up and do all of that (and keep it maintained until it gets merged, which probably won't be till 3.6) and there's one of the core devs willing to support the code going forward once its committed, then I think closing this as "won't fix" and referring to the external packages is the best solution.

+1

Also, the windows-curses package seems to be fairly up to date for those who want to use PDCurses on Windows.

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

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

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

Windows-curses quit silently on Cpython3.12. is it possible to reopen this issue?

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

See also #40725.

See also #40725.

that one seems not for MSVC compiler. Could I directly try this patch?

that one seems not for MSVC compiler. Could I directly try this patch?

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.

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