Logged In: YES 
user_id=567623

Right.  I've had enough of this nonsense, listen carefully:
as English isn't your first language I'll make this as
simple as possible:

1) I didn't come here to start a flame war, but rather to
point out a genuine deficiency in the Windows getpass,
compared to the *nix version.

2) You didn't lie, and *I didn't accuse you of that*, but
rather pointed out that all was not correct or complete in
your assertion.  *I* was right, as you carefully neglected
to mention that you're using a native keyboard, with an NLS
system that puts ü below ASCII 127 in your local codepage

3) getpass.getpass(), when called on *nix, allows me to
input '¿' and every other character under the sun.  When
called on Windows, *it does not*.  This Means Complex
Passwords With getpass() Aren't Portable.  End Of Story. It
Is Undocumented.  This Is A Bug.

4) Yes the problem isn't that getch() isn't doing what it
should, it is that getch() is the *wrong function to use* in
order to gain parity with the *nix version.

5) Finally, you seem hell-bent on ignoring what I've
written.  I was wrong about getch() behaviour on python-dev,
but That Isn't The Problem, which is why *I* didn't mention
it in this initial bug-report.  My assertion below that
getch() won't get anything above ASCII 255 is *completely
accurate*.  It is the Wrong Function To Use.  This Is A Bug
In Getpass.

6) Finally, Finally, please read this and understand: As per
the initial bug-report, the problem is that getpass on
Windows is limited in ways that getpass on *nix isn't.