> > Also, what would os.listdir() return ? Unicode strings or 8-bit > > strings ? > > This would not change. > > This is what my testing shows: > > * I can switch to a German locale, and create a file using the keystrokes > "`atest`o". The "`" is the dead-char so I get an umlaut over the first and > last characters. (Actually, grave accents, but I'm sure that to Aussie eyes, as to Americans, they's all Greek. :-) > * os.listdir() returns '\xe0test\xf2' for this file. I don't understand. This is a Latin-1 string. Can you explain again how the MBCS encoding encodes characters outside the Latin-1 range? > * That same string can be passed to "open" etc to open the file. > > * The only way to get that string to a Unicode object is to use the > encodings "Latin1" or "mbcs". Of them, "mbcs" would have to be safer, as at > least it has a hope of handling non-latin characters :) > > So - assume I am passed a Unicode object that represents this filename. At > the moment we simply throw that exception if we pass that Unicode object to > open(). I am proposing that "mbcs" be used in this case instead of the > default "ascii" > > If nothing else, my idea could be considered a "short-term" solution. If > ever it is found to be a problem, we can simply move to the unicode APIs, > and nothing would break - just possibly more things _would_ work :) I have one more question. The plan looks decent, but I don't know the scope. Which calls do you plan to fix? --Guido van Rossum (home page: http://www.python.org/~guido/)
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