_curses.window.getch does not check for interruption signals as _curses.window.{getkey,get_wch} do

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

Hi! I think this fix should raise an error when PyErr_CheckSignals() failed. This is copied from the get_wch() no-delay code:

static int
_curses_window_getch_impl(PyCursesWindowObject *self, int group_right_1,
                          int y, int x)
/*[clinic end generated code: output=980aa6af0c0ca387 input=bb24ebfb379f991f]*/
{
    int rtn;

    Py_BEGIN_ALLOW_THREADS
    if (!group_right_1) {
        rtn = wgetch(self->win);
    }
    else {
        rtn = mvwgetch(self->win, y, x);
    }
    Py_END_ALLOW_THREADS

    /* getch() returns ERR in nodelay mode */
    if (PyErr_CheckSignals()) {
      cursesmodule_state *state = get_cursesmodule_state_by_win(self);
      const char *funcname = group_right_1 ? "mvwgetch" : "wgetch";
      PyErr_Format(state->error, "getch(): %s(): no input", funcname);
      return ERR;
    }

    return rtn;
}

Another potential issue that I am seeing is a return type mismatch between getch and get_wch or getkey. Both of get_wch() and getkey() returns a PyObject *. Maybe we can change _curses_window_getch_impl to return a PyLong pointer similar to get_wch_impl and getkey_impl? This would make sure we are always dealing with the same return type.

It's not a mismatch. It's handled by Argument Clinic so it's fine.

But I'll probably handle it as part of the rest of the cleanup

gh-134210: handle signals in `_curses.window.getch` (#134326)

pythongh-134210: handle signals in `_curses.window.getch` (pythonGH-1…

[3.13] pythongh-134210: handle signals in `_curses.window.getch` (pyt…

gh-134210: refactor signal handling in `_curses.window.{get_wch,getke…

[3.14] gh-134210: handle signals in `_curses.window.getch` (GH-134326) (

[3.13] gh-134210: handle signals in `_curses.window.getch` (GH-134326) (

pythongh-134210: handle signals in `_curses.window.getch` (python#134326

pythongh-134210: refactor signal handling in `_curses.window.{get_wch…

pythongh-134210: handle signals in `_curses.window.getch` (python#134326

pythongh-134210: refactor signal handling in `_curses.window.{get_wch…

pythongh-134210: handle signals in `_curses.window.getch` (python#134326

pythongh-134210: refactor signal handling in `_curses.window.{get_wch…

Navigation Menu

Repository navigation

`_curses.window.getch` does not check for interruption signals as `_curses.window.{getkey,get_wch}` do #134210

Bug report

Bug description:

CPython versions tested on:

Operating systems tested on:

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

_curses.window.getch does not check for interruption signals as _curses.window.{getkey,get_wch} do #134210

Description

Bug report

Bug description:

CPython versions tested on:

Operating systems tested on:

Linked PRs

Activity

zydtiger commented on May 19, 2025

zydtiger commented on May 19, 2025

picnixz commented on May 19, 2025

picnixz commented on May 19, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

`_curses.window.getch` does not check for interruption signals as `_curses.window.{getkey,get_wch}` do #134210