"Martin v. Loewis" wrote:
>
> > 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*).
Right. I am starting to believe that unicodefilenames() doesn't really
provide enough information to make it useful for cross-platform
programming.
> > > 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
Sounds like this would be a good candidate for platform.py which I'll
check into CVS soon. With its many platform querying APIs it should
easily be possible to add a function which returns the above
information based on the platform Python is running on.
> 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).
I doubt that you'll have any luck in trying to convince a user
to switch OSes just because Python applications don't cope
with native file names. The UTF-8 locale on Unix is also hard to
push: e.g. existing latin-1 file names will probably stop working the
minute you switch to that locale. (I always leave the setting to "C"
and simply don't use locale based file names -- that way I don't
run into problems; non-[a-zA-Z0-9\-\._]+ file names are a no-go
for cross-platform-code if you ask me...)
--
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