> 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.
If you are thinking of Unix: It seems unicodefilename has to return 0
on Unix, meaning that you need to use byte-oriented file names if you
want to access all files (not that you will be able to display all
file names to the user, though ... there is nothing we can do to
achieve *that*).
> > 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.
I think you are missing the point that unicodefilenames, as defined,
does not take any parameters. It says either yay or nay. So it could
be replaced in application code with
if sys.platform == "win32":
use_unicode_for_filenames = windowsversion in ['nt','w2k','xp']
elif sys.platform.startswith("darwin"):
use_unicode_for_filenames = 1
else:
use_unicode_for_filenames = 0
I would not use such code in my applications, nor would I ever use
unicodefilenames. Instead, I would just use Unicode file names all the
time, and risk that some users have problems with some files. Those
users I would tell to fix their systems (i.e. use NT instead of
Windows, or use a UTF-8 locale on Unix). Most users will never notice
any problem (except for Neil, who likes to put funny file names on his
disk :-), so this is a typical 80-20 problem here (or maybe rather
99-1).
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