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

[Terry Reedy]

"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