getch() in msvcrt does not accept extended characters.
Hi, I'm sorry, I don't seem to have done a very good job at explaining the situation. I'll try again: 'getch()' is a low-level function provided on Windows to capture a single character of input from a user, /without echoing it to the screen/. As far as I can tell there's no other way of doing this with Python on Windows. The Python interface to this function is in the C code in msvcrtmodule.c, which has a (very thin) wrapper around the raw OS system call. Microsoft provide a way of accepting both normal ASCII codes, and extended characters via this system call. Currently, the Python wrapper in msvcrtmodule.c only supports the semantics of getting the bare ASCII codes, and not the extended characters. I would strongly suggest that it should support both. So, I guess in answer to the questions raised below; 1) I can't do it in Python code without getch() (hence the original email) 2) I would argue that in fact getch() is 'broken' in its current Python implementation, as it doesn't support what the OS implies /should/ be supported (and, indeed, if I input an extended character in response to a 'getch()' call, all I get back currently is an empty string). Hope this helps, D Fredrik wrote:
Darryl Dixon wrote:
Microsoft support capturing extended characters via _getch, but it requires making a second call to getch() if one of the 'magic' returns is encountered in the first call (0x00 or 0xE0).
so why not do that in your python code?
The relevant chunk of code in Python that would probably need to be changed to support this appears to be in msvcrtmodule.c:
if you change msvcrt, you'll break all the programs that uses getch() in the prescribed way...
</F> -- Darryl Dixon
Whatever it is that you need 'getch' to do, can't you incorporate it first in an extension module you bundle with your application or library, rather than using the (broken?) wrapper in the msvcrt module? Jeff
"Darryl Dixon"
I'm sorry, I don't seem to have done a very good job at explaining the situation. I'll try again:
Actually, I think you did fine the first time, and the second time, and I see nothing new here. You, like thousands of others (including Guido himself), want at least one little bit of Python to be different. But you seem more persistent in ignoring responses and not takinge 'no' for an answer. So I suggest that you reread previous responses more carefully, and/or take your complaint to comp.lang.python.
'getch()' is a low-level function provided on Windows to capture a single character of input from a user, /without echoing it to the screen/. As far as I can tell there's no other way of doing this with Python on Windows. The Python interface to this function is in the C code in msvcrtmodule.c, which has a (very thin) wrapper around the raw OS system call.
How many people have to say how many times that the thinness is intentional. The module was added some years ago to make life easier for Windows programmers to wanted to use the calls they were familiar with in the way they were familiar with, even though it makes their programs non-portable.
Microsoft provide a way of accepting both normal ASCII codes, and extended characters via this system call.
According to you, Microsoft requires two calls. Quoting you:
Microsoft support capturing extended characters via _getch, but it requires making a second call to getch() if one of the 'magic' returns is encountered in the first call (0x00 or 0xE0).
You seem to be complaining that Python mimics Microsoft too well.
Currently, the Python wrapper in msvcrtmodule.c only supports the semantics of getting the bare ASCII codes, and not the extended characters.
Based on the source code and your posts, the Python sematics is the same as the MS semantics with 'Python char' (string of length 1) substituted for 'C char'. So it seems untrue that Microsoft supports something Python does not and I am baffled why you keep saying so. If making a second call from Python somehow acts differently than making a second call from C, then you *have* failed to demonstrate or explain *that*, and that seems to me like itmight be a legitimate reason to complain. Terry J. Reedy
Sorry all, It seems that the list mods have finally released a duplicate message that I wrote last week when I wasn't subscribed to the list. Please ignore the message below if you have read the previous copy already. D On Thu, 2005-06-30 at 09:43 +1200, Darryl Dixon wrote:
Hi,
I'm sorry, I don't seem to have done a very good job at explaining the situation. I'll try again: 'getch()' is a low-level function provided on Windows to capture a single character of input from a user, /without echoing it to the screen/. As far as I can tell there's no other way of doing this with Python on Windows. The Python interface to this function is in the C code in msvcrtmodule.c, which has a (very thin) wrapper around the raw OS system call. Microsoft provide a way of accepting both normal ASCII codes, and extended characters via this system call. Currently, the Python wrapper in msvcrtmodule.c only supports the semantics of getting the bare ASCII codes, and not the extended characters. I would strongly suggest that it should support both.
So, I guess in answer to the questions raised below;
1) I can't do it in Python code without getch() (hence the original email)
2) I would argue that in fact getch() is 'broken' in its current Python implementation, as it doesn't support what the OS implies /should/ be supported (and, indeed, if I input an extended character in response to a 'getch()' call, all I get back currently is an empty string).
Hope this helps, D
Fredrik wrote:
Darryl Dixon wrote:
Microsoft support capturing extended characters via _getch, but it requires making a second call to getch() if one of the 'magic' returns is encountered in the first call (0x00 or 0xE0).
so why not do that in your python code?
The relevant chunk of code in Python that would probably need to be changed to support this appears to be in msvcrtmodule.c:
if you change msvcrt, you'll break all the programs that uses getch() in the prescribed way...
</F> -- Darryl Dixon
participants (3)
-
Darryl Dixon -
Jeff Epler -
Terry Reedy