Hi all, Please CC: me on any replies as I am not subscribed to this list. I am the lead maintainer for the ntlmaps project (http://ntlmaps.sourceforge.net). Recently a bugreport logged against ntlmaps has brought an issue to my attention (see: https://sourceforge.net/tracker/index.php?func=detail&aid=1224877&group_id=69259&atid=523935). The getpass() function in module getpass does not accept extended characters on Windows. On Windows, the getpass() source uses the msvcrt module to capture one character at a time from stdin via the _getch() function defined in conio.h. Microsoft support capturing extended characters via _getch (see: http://support.microsoft.com/default.aspx?scid=kb;en-us;57888), but it requires making a second call to getch() if one of the 'magic' returns is encountered in the first call (0x00 or 0xE0). The relevant chunk of code in Python that would probably need to be changed to support this appears to be in msvcrtmodule.c: static PyObject * msvcrt_getch(PyObject *self, PyObject *args) { int ch; char s[1]; if (!PyArg_ParseTuple(args, ":getch")) return NULL; Py_BEGIN_ALLOW_THREADS ch = _getch(); Py_END_ALLOW_THREADS s[0] = ch; return PyString_FromStringAndSize(s, 1); } It would seem that it could be made to support extended characters by changing it to: static PyObject * msvcrt_getch(PyObject *self, PyObject *args) { int ch; char s[1]; if (!PyArg_ParseTuple(args, ":getch")) return NULL; Py_BEGIN_ALLOW_THREADS ch = _getch(); + if (ch == 0x00 || ch == 0XE0) + ch = _getch(); Py_END_ALLOW_THREADS s[0] = ch; return PyString_FromStringAndSize(s, 1); } I haven't yet read the code for PyString_FromStringAndSize(), but presumably it can coerce unicode/extended results out of the int (or could be made to)? What are the chances of modifying msvcrt_getch() to support extended chars? The unix_getpass() seems to already work OK with extended characters, so this would ~seem~ to be a logical extension to the Windows version. Thoughts? -- Darryl Dixon <esrever_otua@pythonhacker.is-a-geek.net>