New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
curses.get_wch() returns keypad codes incorrectly #59989
Comments
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. |
The curses module already exposes the integer KEY_* constants. I think the I suspect most callers will want to compare the keycode against one of these The curses module also already exposes the keyname() function if callers do If the function returned either a single-character unicode string or an integer |
I tried to mimic the getkey() function, but I like your idea. In many cases It does not solve unget_wch() issue, but I propose to drop the |
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. |
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...) |
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: |
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': |
@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': |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: