classification
Title: curses.get_wch() returns keypad codes incorrectly
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.4, Python 3.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Arfrever, Nicholas.Cole, akuchling, cben, georg.brandl, gpolo, haypo, inigoserna, jcea, loewis, phep, pitrou, python-dev, r.david.murray, simpkins, zeha
Priority: release blocker Keywords: patch

Created on 2012-08-26 10:09 by simpkins, last changed 2012-09-09 09:18 by python-dev. This issue is now closed.

Files
File name Uploaded Description Edit
curses_get_wch-2.patch haypo, 2012-08-28 22:18 review
Messages (18)
msg169165 - (view) Author: Adam Simpkins (simpkins) Date: 2012-08-26 10:09
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.
msg169171 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2012-08-26 21:07
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?
msg169172 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2012-08-26 21:09
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.
msg169219 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2012-08-27 21:13
Please get a review from another developer before I consider this for rc2.
msg169248 - (view) Author: Adam Simpkins (simpkins) Date: 2012-08-28 03:23
> +   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.)
msg169272 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2012-08-28 10:54
> 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.
msg169311 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2012-08-28 22:18
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.
msg169312 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-08-28 22:19
Perhaps you should simply remove the new function, and re-add it in 3.4 when you've thought it out a bit more.
msg169313 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2012-08-28 22:23
window.get_wch() has been added by the issue #6755, and curses.unget_wch() by #12567. Copy the nosy of the issue #6755.
msg169314 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2012-08-28 22:31
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...)
msg169316 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2012-08-28 22:55
> 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
msg169318 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2012-08-28 23:10
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.
msg169319 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2012-08-28 23:14
@simpkins: can you please try my patch?
msg169321 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2012-08-28 23:31
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.
msg169322 - (view) Author: Roundup Robot (python-dev) Date: 2012-08-28 23:41
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
msg169632 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2012-09-01 13:26
@georg.brandl: Can you please include the important fix c58789634d22 into Python 3.3 final?
msg170030 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2012-09-08 05:49
Now picked into 3.3.0 release clone in 23377e88487b.
msg170090 - (view) Author: Roundup Robot (python-dev) Date: 2012-09-09 09:18
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
History
Date User Action Args
2012-09-09 09:18:56python-devsetmessages: + msg170090
2012-09-08 05:49:49georg.brandlsetstatus: open -> closed
resolution: fixed
messages: + msg170030
2012-09-03 10:43:51schodetsetnosy: - schodet
2012-09-01 13:26:14hayposetmessages: + msg169632
2012-08-28 23:41:47python-devsetmessages: + msg169322
2012-08-28 23:31:04hayposetmessages: + msg169321
2012-08-28 23:14:00hayposetmessages: + msg169319
2012-08-28 23:10:39hayposetmessages: + msg169318
2012-08-28 23:06:46hayposetfiles: - curses_get_wch-3.patch
2012-08-28 23:06:25hayposetfiles: + curses_get_wch-2.patch
2012-08-28 22:55:14hayposetmessages: + msg169316
2012-08-28 22:31:59hayposetfiles: - curses_get_wch-2.patch
2012-08-28 22:31:48hayposetfiles: + curses_get_wch-3.patch

messages: + msg169314
2012-08-28 22:23:43hayposetnosy: + akuchling, jcea, cben, gpolo, r.david.murray, inigoserna, phep, zeha, schodet, python-dev, Nicholas.Cole
messages: + msg169313
2012-08-28 22:19:05pitrousetnosy: + pitrou
messages: + msg169312
2012-08-28 22:18:17hayposetfiles: - curses_get_wch.patch
2012-08-28 22:18:04hayposetfiles: + curses_get_wch-2.patch

messages: + msg169311
2012-08-28 10:54:13hayposetmessages: + msg169272
2012-08-28 03:23:41simpkinssetmessages: + msg169248
2012-08-27 21:13:43georg.brandlsetmessages: + msg169219
2012-08-27 21:02:26pitrousetnosy: + loewis, georg.brandl
2012-08-26 21:09:31hayposetpriority: normal -> release blocker

messages: + msg169172
2012-08-26 21:07:39hayposetfiles: + curses_get_wch.patch
keywords: + patch
messages: + msg169171
2012-08-26 19:51:17Arfreversetnosy: + Arfrever
2012-08-26 16:32:20ned.deilysetnosy: + haypo
2012-08-26 10:09:38simpkinscreate