Neil Hodgson wrote: > > M.-A. Lemburg, regarding unicodefilenames(): > > > 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. > > It is much better to choose a technique that will always work rather than > try to recover from a technique that may fail. 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. > 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. > unicodefilenames() will allow other environments to declare that client code > will be more robust by choosing to use Unicode strings as file name > arguments. This could include UTF-8 based systems such as OS X and BeOS, as > well as Windows variants like CE. -- 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