Description
Bug report
Bug description:
In _curses.window.{getkey,get_wch}
, we are checking for possible interrupting signals and say:
In no-delay mode, an exception is raised if there is no input
However, in getch
, we say:
In no-delay mode, -1 is returned if there is no input.
In particular, I think we should also check for signals and possibly raise an exception if PyErr_CheckSignals
fails, and otherwise return -1 as documented. (note that getch
returns ERR in no-delay mode, see https://linux.die.net/man/3/wgetch).
CPython versions tested on:
CPython main branch
Operating systems tested on:
No response
Linked PRs
Metadata
Metadata
Assignees
Projects
Status
Activity
zydtiger commentedon May 19, 2025
Hi! I think this fix should raise an error when
PyErr_CheckSignals()
failed. This is copied from theget_wch()
no-delay code:zydtiger commentedon May 19, 2025
Another potential issue that I am seeing is a return type mismatch between
getch
andget_wch
orgetkey
. Both ofget_wch()
andgetkey()
returns aPyObject *
. Maybe we can change_curses_window_getch_impl
to return aPyLong
pointer similar toget_wch_impl
andgetkey_impl
? This would make sure we are always dealing with the same return type.picnixz commentedon May 19, 2025
It's not a mismatch. It's handled by Argument Clinic so it's fine.
picnixz commentedon May 19, 2025
But I'll probably handle it as part of the rest of the cleanup
_curses.window.getch
#134326_curses.window.{get_wch,getkey}
#134646gh-134210: handle signals in `_curses.window.getch` (#134326)
pythongh-134210: handle signals in `_curses.window.getch` (pythonGH-1…
_curses.window.getch
(GH-134326) #134783[3.13] pythongh-134210: handle signals in `_curses.window.getch` (pyt…
_curses.window.getch
(GH-134326) #1347845 remaining items