> The only option I see to make this situation less painful is > to write a filename subsystem which implements two generic > APIs: > > 1. file open using strings and Unicode I think this "pretty much" works in Python 2.2 already. It uses the "mbcs" encoding on Windows, and the locale's encoding on Unix if locale.setlocale has been called (and the C library is good enough). That might be still wrong if the file system expects UTF-8, or a fixed encoding (e.g. on an NTFS or VFAT partition mounted on Linux), but I don't think there is anything that can be done about this: It would be a misconfigured system if then the user doesn't also use an UTF-8 locale. > 2. file listing using either Unicode or strings with a predefined > encoding in the output list That is something that certainly needs to be done. Having a PEP on that would be useful. 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