Author poolie
Recipients benjamin.peterson, gz, pitrou, poolie, r.david.murray, vila, vstinner
Date 2011-12-22.01:16:53
SpamBayes Score 1.19598e-11
Marked as misclassified No
Message-id <>
In-reply-to <>
On 22 December 2011 11:21, STINNER Victor <> wrote:
> This discussion is becoming very long, I didn't remember the original
> purpose.

The proposal is that in some cases where Python currently assumes
filenames are ascii on Linux, it ought to instead assume they are

> You want to use UTF-8 instead of ASCII, so what? What do you
> want to do with your nicely well decoded filenames? You cannot print it
> to your terminal nor pass it to a subprocess, because your terminal uses
> ASCII, as subprocess. I don't see how it would help you.

When the application has a unicode string, it can always encode itself
in whatever way it thinks most appropriate.  For instance if it is a
network service, the locale in which it was started may be entirely
irrelevant to the encoding it wants to talk to a particular peer.

However, there are or were some Python filesystem APIs where it is
very hard for the application to avoid being limited to the encoding
Python assumes at startup.  Also, for good reasons, the application
cannot change the filesystem encoding once it starts.  So the reason
for proposing a patch to Python is that there is no way for the
application to escape, once Python's assumed all names will be ascii.

It may be that all of those limitations have since been fixed
separately, either through pep383 or separate patches, so the
application at least has a chance to work around it.  It would be nice
to not burden the application or user with working around this when
the filenames really are valid in what should be the user's locale,
but perhaps this is the OS's fault for not having the right locale
Date User Action Args
2011-12-22 01:16:55pooliesetrecipients: + poolie, pitrou, vstinner, vila, benjamin.peterson, r.david.murray, gz
2011-12-22 01:16:54poolielinkissue13643 messages
2011-12-22 01:16:53pooliecreate