[Python-Dev] getch() in msvcrt does not accept extended characters. (original) (raw)

Terry Reedy tjreedy at udel.edu
Tue Jul 5 23:42:23 CEST 2005

"Darryl Dixon" <esrever_otua at pythonhacker.is-a-geek.net> wrote in message news:1120081396.14913.13.camel at unixadmindazfc2.chh.co.nz...

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

More information about the Python-Dev mailing list