"Martin v. Loewis" wrote: > > > 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. > > Such a solution is impossible to implement in some case. E.g. on > Windows, if you use the ANSI (*A) APIs to list the directory contents, > Windows will *silently* (AFAIK) give you incorrect file names, i.e. it > will replace unrepresentable characters with the replacement char > (QUESTION MARK). Samba does the same for mounted Windows shares, BTW. > OTOH, on Unix, there is a better approach for listdir and > unconvertable names: just return the byte strings to the user. Sigh. > > 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. > > That is a good idea. However, in case of the WinNT replacement > strategy, the application may still want to know. > > Passing *in* Unicode objects is no issue at all: If they cannot be > converted to a reasonable file name, you clearly get an exception. True and that's good :-) -- 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