Repository navigation
curses for win32 #40725
Description
| BPO | 1005895 |
|---|---|
| Nosy | @tonal, @tjguk, @mcepl |
| 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 2004-08-09.11:05:57.000>
labels = ['extension-modules', 'type-feature', 'OS-windows']
title = 'curses for win32'
updated_at = <Date 2016-08-03.03:22:13.589>
user = 'https://github.com/tonal'bugs.python.org fields:
activity = <Date 2016-08-03.03:22:13.589>
actor = 'BreamoreBoy'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Extension Modules', 'Windows']
creation = <Date 2004-08-09.11:05:57.000>
creator = 'shura_zam'
dependencies = []
files = ['6163', '6164', '6165']
hgrepos = []
issue_num = 1005895
keywords = ['patch']
message_count = 16.0
messages = ['46600', '46601', '46602', '46603', '46604', '46605', '46606', '46607', '98813', '99410', '114369', '114372', '114397', '114484', '222627', '271783']
nosy_count = 5.0
nosy_names = ['jlt63', 'techtonik', 'shura_zam', 'tim.golden', 'mcepl']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue1005895'
versions = ['Python 3.4']
Activity
tonal commentedon Aug 9, 2004
I have paths for compile _curses module.
I use
compiler - mingw32 v3.3.1
curses library - Public Domain Curses (PDCurses 2.6)
akuchling commentedon Jun 15, 2005
Logged In: YES
user_id=11375
In the cursesmodule patch, the first argument to intrflush
is changed from NULL to stdscr. Why? According to the
ncurses man page, the window argument is ignored.
use_env() is apparently a no-op for PDcurses; why not just
remove the Python-visible use_env function completely?
In the setting of _C_API_VERSION, what does the string
"PDCurses M" mean? (In particular, what does the 'M' stand
for?)
Except for the above questions, the patches to
test_curses.py and _cursesmodule.c look OK. I have no
access to a Windows machine and no way to test them or the
new .mak file, so I'm reassigning this bug to Jason Tishler,
who does a lot of Cygwin work. Jason, please feel free to
ask me any questions you might have about curses, the
_cursesmodule.c file, or whatever.
tonal commentedon Jun 16, 2005
Logged In: YES
user_id=980085
jlt63 commentedon Jun 16, 2005
Logged In: YES
user_id=86216
Andrew,
Sorry, but I'm confused. What exactly are you
asking me to do? Make sure Alexandr's patch
doesn't break the Cygwin build? Other builds?
Works?
Thanks,
Jason
akuchling commentedon Jun 16, 2005
Logged In: YES
user_id=11375
As maintainer of the curses module, applying the patch is OK
with me, but I'm not going to apply it because I don't use
Cygwin, the affected platform. I leave it up to you to
apply the patch, or reject it, or demand changes; I'm happy
if you decide to apply it, but don't really care.
(Note that the patch to test_curses.py won't apply cleanly;
it includes some other fixes from Alexandr that I've already
applied. If you decide to accept the patch, I can help
straighten out test_curses.py.)
jlt63 commentedon Jun 16, 2005
Logged In: YES
user_id=86216
If the patch affects Cygwin, then it's not obvious:
However, it seems to affect the native Windows build:
Please point out actually where the patch affects Cygwin.
Thanks.
akuchling commentedon Jun 16, 2005
Logged In: YES
user_id=11375
Ah; I looked at the initial description which says 'mingw32'
was used, and thought that was the Cygwin compiler. Sorry!
If this patch applies to the standard windows build, just
unassign it; some Windows person will have to look at it.
jlt63 commentedon Jun 16, 2005
Logged In: YES
user_id=86216
AFAICT, this patch applies to the standard Windows build.
So, I'm unassigning it as suggested by Andrew.
techtonik commentedon Feb 4, 2010
Can this be considered a duplicate of bpo-2889?
jlt63 commentedon Feb 16, 2010
Sorry, but I don't know. I haven't looked at this issue for almost five years! And when I did, I only looked as far to determine it wasn't Cygwin related.
BreamoreBoy commentedon Aug 19, 2010
Brian or Tim any interest in this?
I consider bpo-2889 to be a duplicate of this and not the other way around.
briancurtin commentedon Aug 19, 2010
I have zero knowledge and experience when it comes to curses so I'm afraid I can't really provide much here.
One thing I can say is that this patch would have to be converted to be compiled by MSVC rather than MinGW. That was an early issue with bpo-2889 but it appears that patch was converted.
tjguk commentedon Aug 19, 2010
It looks as though bpo-2889 has a better chance of getting into the VS build than this one, which appears to be MingW-based (at a quick glance). I'm loosely keen to see it in, although I have no knowledge of curses as such. I'll assign it to myself so it appears on my to-do queue but I'm not promising to do anything with it immediately. Anyone who feels up to the task, feel free to take it off me.
Mark: why do you consider bpo-1005895 the master, so to speak? I can see more mileage in pursuing the other?
BreamoreBoy commentedon Aug 21, 2010
Tim: mainly because this was raised some 4 years earlier and the title of bpo-2889 "curses for windows (alternative patch)"
BreamoreBoy commentedon Jul 9, 2014
Is this worth pursuing as https://docs.python.org/3/howto/curses.html states "The Windows version of Python doesn’t include the curses module. A ported version called UniCurses is available" ? This is available at https://pypi.python.org/pypi/UniCurses
mcepl commentedon Aug 1, 2016
Well, basically any solution is better than nothing ;)
erlend-aasland commentedon Dec 4, 2023
See also #47138
ashm-dev commentedon Nov 13, 2025
Ping. Is this issue still relevant?
briancurtin commentedon Nov 13, 2025
I would say no. This has been around for so long with no action, or at least none supportable. The aforementioned UniCurses hasn't had a release since 2012. #47138, an alternative, was also closed. I'll close this one as well then.
If someone has actual activity to contribute to it, they can open it up then. Otherwise I don't see this moving forward.