Message169272
| Author |
vstinner |
| Recipients |
Arfrever, georg.brandl, loewis, simpkins, vstinner |
| Date |
2012年08月28日.10:54:13 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<CAMpsgwYvEJftWN8y3FKEsFZ_NoFgJXpwtFzAwLikdToCra8t6Q@mail.gmail.com> |
| In-reply-to |
<1346124222.32.0.617662222379.issue15785@psf.upfronthosting.co.za> |
| Content |
> 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. |
|