> The restriction when compiling Python in wide mode on Windows > should be lifted: The PyUnicode_AsWideChar() API should be used > to convert 4-byte Unicode to wchar_t (which is 2-byte on Windows). While I agree that this restriction ought to be removed eventually, I doubt that Python will be usable on Windows with a four-byte Unicode type in any foreseeable future. Just have a look at unicodeobject.c:PyUnicode_DecodeMBCS; it makes the assumption that a Py_UNICODE* is the same thing as a WCHAR*. That means that the "mbcs" encoding goes away on Windows if HAVE_USABLE_WCHAR_T does not hold anymore. Also, I believe most of PythonWin also assumes HAVE_USABLE_WCHAR_T (didn't check, though). > Why is "unicodefilenames" a function and not a constant ? In the Windows binary, you need a run-time check to see whether this is DOS/W9x, or NT/W2k/XP; on DOS, the Unicode API is not available (you still can pass Unicode file names to open and listdir, but they will get converted through the MBCS encoding). So it clearly is not a compile time constant. I'm still not certain what the meaning of this function is, if it means "Unicode file names are only restricted by the file system conventions", then on Unix, it may change at run-time, if a user or the application sets an UTF-8 locale, switching from the original "C" locale. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4