Martin v. Löwis wrote:
> 
> Martin v. Löwis <martin@v.loewis.de> added the comment:
> 
>> Being pedantic about forcing some encoding onto things that don't
>> have an encoding won't really work out in practice. Dealing with
>> file names, OS environments, pipes and sockets is dirty work, so
>> I think we should go with the 80-20 approach in making 80% easy
>> and 20% harder, but still possible.
> 
> Unix applications can always use the byte-oriented file name APIs
> if they need to. Then you are back to the state that things have
> in Python 2. No need to have a user-tunable file system encoding
> there.

Right and if you take the position of refusing to guess
which we usually do in Python, then interfacing to file names
using bytes would be the appropriate way to handle the situation.

However, since Python3 has chosen to regard file names as
text regardless of platform, we're now in the situation that
we have to come up with some educated guess on the encoding.

> However, I completely fail to see the advantage that the
> PYTHONFSENCODING variable has over the LANG variable. If it's
> possible to set PTHONFSENCODING in some application, it surely
> is also possible to set LANG (or LC_CTYPE), no? Setting the
> latter also gives you the advantage that environment variables
> and command line arguments use the same encoding as file names.

The advantage is that you can change the Python files system
encoding *without* having to change your locale settings.

You can't possibly expect a user to switch to using UTF-8 for
all his/her applications just because Python needs this to
properly decode file names.

Users of applications written in Python will most likely not
even know how to change the locale encoding.