homepage

The curses.get_wch() function does not check if wget_wch() returned OK or KEY_CODE_YES. In either case, it simply returns the character code.
This makes get_wch() unusable when keypad is enabled, because the caller cannot distinguish function key or arrow key presses from real unicode code points. For example, get_wch() returns 259 both for an up arrow press and for the input character 'ă'.
It seems like this API needs to be redesigned somehow to allow terminal keypad codes to be distinguished from unicode input.

Oh, right. I agree that the current implementation of window.get_wch() is useless. I missed completly key codes.
Attached patch changes the API of get_wch() from get_wch()->key:int to get_wch()->(is_key_code: bool, key: str). Examples: (True, 'KEY_UP'), (False, 'é').
Problem: unget_wch() test fails. "unget_wch('é'); is_key_code, ch = win.get_wch()" returns is_key_code=True, ch=''. I don't see how to specify to unget_wch() if the argument is a key code or not... It's maybe an issue in unget_wch() API that cannot be fixed in Python?

I consider this issue as a release blocker because the bug requires to change the API (of a function added to Python 3.3).
If this issue cannot be fixed before Python 3.3 final, I prefer to drop the function until a better implementation is written.

Please get a review from another developer before I consider this for rc2.

> + Get a wide character as (is_key_code, key). *is_key_code* is True for
> + function keys, keypad keys and so, in this case, *key* is a multibyte string
> + containing the key name. Otherwise, *key* is a single character
> + corresponding to the key.
The curses module already exposes the integer KEY_* constants. I think the
API would be easier to use if it simply returned the integer keycode constant
rather than returning the human-readable name returned by keyname().
I suspect most callers will want to compare the keycode against one of these
KEY_* constants to see what type of key was pressed so they can take action on
specific keys. Comparing the return value against one of the curses.KEY_*
constants seems easier than having to compare it to the result of
curses.keyname(curses.KEY_*)
The curses module also already exposes the keyname() function if callers do
want to get the human-readable string for an integer keycode.
If the function returned either a single-character unicode string or an integer
keycode, this would also make it possible to completely drop the is_key_code
part of the return value. (Callers could simply check the type of the return
value to see if it is a keycode.)

> If the function returned either a single-character unicode string or an
integer
> keycode, this would also make it possible to completely drop the
is_key_code
> part of the return value. (Callers could simply check the type of the
return
> value to see if it is a keycode.)
I tried to mimic the getkey() function, but I like your idea. In many cases
you don't have to check explicitly the type. Example: if key == "q":
quit(), or if key == curses.KEY_UP: move(1). It works also if the key is
used as a key of a dictionary: key => callback. And yes, keyname() can be
used to mimic manually getkey() behaviour.
It does not solve unget_wch() issue, but I propose to drop the
unget_wch()+get_wch() test on non-ASCII keys because it looks like a bug in
the curses library.

New patch fixing the issue with a better API: window.get_wch()->int or str depending on the key (int for key codes, str for other keys).
Oh, I realized that test_curses does also fail on my laptop without the patch. My laptop is running Fedora 11 which uses libncurses 5.7. This version is old and has known bugs. So the "unget_wch" issue is maybe unrelated.

Perhaps you should simply remove the new function, and re-add it in 3.4 when you've thought it out a bit more.

window.get_wch() has been added by the issue #6755, and curses.unget_wch() by #12567. Copy the nosy of the issue #6755.

New patch with a test for this specific issue.
(It's not easy to me to write a patch because my version of libncurses doesn't work with integers bigger than 128...)

> Perhaps you should simply remove the new function, and re-add it in 3.4 when you've thought it out a bit more.
Python 3 forces somehow to use Unicode, and the Unicode support of the curses module in Python 3.2 is incomplete or broken (see . Many issues have been fixed in Python 3.3. It would be a regression to remove get_wch(), it's an important function to use the curses module with Python 3.
Changes between Python 3.2 and 3.3:
http://docs.python.org/dev/whatsnew/3.3.html#curses 

bitdancer tested the patch version 3 for me and it fails: unget_wch(KEY_UP) inserts the character U+0103 (259, à) instead of KEY_UP in get_wch() buffer. unget_wch() cannot be used to insert key codes, only classic keys like letters.
So I removed the patch version 3 and restored patch version 2 which only changes the get_wch() API and adapts the existing unit test.

@simpkins: can you please try my patch?

bitdancer proposes (on IRC) a better doc for get_wch():
"Get a wide character. Return a character for most keys, or an integer for function keys, keypad keys, and other special keys."
We may also replace "and so on" by "and other special keys" in getkey() definition.

New changeset c58789634d22 by Victor Stinner in branch 'default':
Issue #15785: Modify window.get_wch() API of the curses module: return a
http://hg.python.org/cpython/rev/c58789634d22 

@georg.brandl: Can you please include the important fix c58789634d22 into Python 3.3 final?

Now picked into 3.3.0 release clone in 23377e88487b.

New changeset 23377e88487b by Victor Stinner in branch 'default':
Issue #15785: Modify window.get_wch() API of the curses module: return a
http://hg.python.org/cpython/rev/23377e88487b