[Python-Dev] Python-3.0, unicode, and os.environ
James Y Knight
foom at fuhm.net
Sat Dec 6 02:37:45 CET 2008
On Dec 5, 2008, at 7:48 PM, Nick Coghlan wrote:
> You can't display a non-decodable filename to the user, hence the user
> will have no idea what they're working on. Non-filesystem related apps
> have no business trying to deal with insane filenames.
Sigh, same arguments, all over again.
Again, *both* KDE and Gnome apps display non-decodable filenames to
the user, and let the user work with the files. They display as good a
rendition as they can, using a replacement character as appropriate.
In some earlier versions, KDE did not work at all on poorly-encoded
files, and, users submitted bug reports. People do care, it does
happen in real life, and it is a bug in your software if you cannot
deal with the users' files. They just want the software to work. If it
shows something weird in the window titlebar, that's a bit irritating
but at least it doesn't get in the way of working.
> Linux is moving towards a standard of UTF-8 for filenames, and once we
> get to the point where the idea of encoding filenames and environment
> variables any other way is seen as crazy, then the Python 3 approach
> will work seamlessly.
I seriously doubt that would ever enforce utf-8 filenames/env vars/
command arguments. Oddly encoded strings will always be with us in
some form or another.
Now, perhaps you use crontab? At least on the systems I have, programs
run by cron don't have any locale environment variables set, and so
default to the "C" locale. So utf-8 encoded filenames/etc will fail,
by default, for any python3 program run under cron.
I'd like to make an analogy: what if Python3 couldn't deal with
filenames with spaces in them on unix? Most filenames don't have
spaces in them, so it should be okay, right? And those people who
really need to deal with space-containing filenames can use this other
API variant, instead of the recommended and most obvious one. That'd
be okay, right? No, of course it wouldn't be okay!
James
More information about the Python-Dev
mailing list