> The way I see it, to fix this we have 2 basic choices when a Unicode object > is passed as a filename: > * we call the Unicode versions of the CRTL. > * we auto-encode using the "mbcs" encoding, and still call the non-Unicode > versions of the CRTL. > > The first option has a problem in that determining what Unicode support > Windows 95/98 have may be more trouble than it is worth. Sticking to purely > ascii versions of the functions means that the worst thing that can happen > is we get a regular file-system error if an mbcs encoded string is passed on > a non-Unicode platform. > > Does anyone have any objections to this scheme or see any drawbacks in it? > If not, I'll knock up a patch... The Mac has a very similar problem here: unless you go to the unicode APIs (which is pretty much impossible for stdio calls and such at the moment) you have to use the "current" 8-bit encoding for filenames. Could you put your patch in such a shape that it could easily be adapted for other platforms? Something like PyOS_8BitFilenameFromUnicodeObject(PyObject *, char *, int) or so? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
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