"Martin v. Loewis" wrote: > > [unicodefilenames()] > > Perhaps we ought to drop that function altogether and let the > > various file IO functions raise run-time errors instead ?! > > That was my suggestion as well. However, Neil points out that, on > Windows, passing Unicode is sometimes better: For some files, there is > no byte string file name to identify the file (if the file name is not > representable in MBCS). OTOH, on Unix, some files cannot be accessed > with a Unicode string, if the file name is invalid in the user's > encoding. Sounds like the run-time error solution would at least "solve" the issue in terms of making it depend on the used file name and underlying OS or file system. I'd say: let the different file name based APIs try hard enough and then have them bail out if they can't handle the particular case. > It turns out that only OS X really got it right: For each file, there > is both a byte string name, and a Unicode name. I suppose this is due to the fact that Mac file systems store extended attributes (much like what OS/2 does too) along with the file -- that's a really nice way of being able to extend file system semantics on a per-file basis; much better than the Windows Registry or the MIME guess-by-extension mechanisms. Oh well. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
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