[Python-Dev] Python-3.0, unicode, and os.environ
glyph at divmod.com
glyph at divmod.com
Sat Dec 6 19:53:19 CET 2008
On 02:34 pm, phd at phd.pp.ru wrote:
>On Fri, Dec 05, 2008 at 08:37:45PM -0500, James Y Knight wrote:
>>On Dec 5, 2008, at 7:48 PM, Nick Coghlan wrote:
>>>You can't display a non-decodable filename to the user, hence the
>>>will have no idea what they're working on. Non-filesystem related
>>>have no business trying to deal with insane filenames.
>>Sigh, same arguments, all over again.
>>People do care, it does happen in real
>>life, and it is a bug in your software if you cannot deal with the
>>files. They just want the software to work. If it shows something
>>in the window titlebar, that's a bit irritating but at least it
>>get in the way of working.
> I agree 100%. Russian Unix users use at least 5 different encodings
>(koi8-r, cp1251 and utf-8 are the most frequent in use, cp866 and
>iso-8859-5 are less frequent). I have an FTP server with some filenames
>koi8 encoding - these filenames are for unix clients, - and some
>in cp1251 for w32 clients. Sometimes I run utf-8 xterm (I am
>a commandline/console unixhead) for my needs (read email, write files
>utf-8 with characters beyond koi8-r, which is my primary encoding) -
>I still can work with filenames in koi8/cp1251 encodings. My
>(Midnight Commander, for the matter) shows these files and directories
>"?????.???", but I can chdir to such directories, and I can open such
>files. It would be a big bad blow for me if filemanagers (or other
>programs) start to filter these filenames.
I find it interesting to note that the only users in this discussion who
actually have these problems in real life all have this attitude. It is
expected that in an imperfect world we will have imperfect encodings,
but it is super important that software which can open files can deal
with not understanding the character translation of the filename.
More information about the Python-Dev