[Python-Dev] Python-3.0, unicode, and os.environ

[James Y Knight]

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