M.-A. Lemburg: > Is it really ? The problem is that under some OSes it is possible > to work with multiple very different file system from within a > single Python program. In those cases, the unicodefilename() > API wouldn't really help all that much. On NT the core file system calls are Unicode based with the narrow string calls being shims on top of this. When mounting non-native file systems, NT may perform name mapping, but that name mapping is 'complete and consistent' in that it is not possible to do anything with the narrow APIs that cannot be achieved with the Unicode APIs. > > unicodefilenames() can be dropped in favour of explicit OS and version > > checks but this is replacing a simple robust check with a more fragile one. > > What kind of checks do you have in mind then ? If possible, it should > be possible to pass unicodefilenames() a path to check for Unicode- > capability, since on Unix (and probably Mac OS X as well), the path > decides which file system get's the ioctrl calls. Any platform experts know how this works on MacOS X or BeOS? Do non-native file systems get mapped to Unicode names so that UTF-8 will always work? Neil
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