This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients ixokai, lemburg, loewis, pitrou, pjenvey, ronaldoussoren, vstinner
Date 2010-10-11.13:45:41
SpamBayes Score 3.799398e-10
Marked as misclassified No
Message-id <4CB31502.2060606@egenix.com>
In-reply-to <201010111415.12700.victor.stinner@haypocalc.com>
Content
STINNER Victor wrote:
> 
> I like this solution because it doesn't change a lot of things. I agree to 
> drop PYTHONFSENCODING because it looks like PYTHONFSENCODING introduced more 
> inconsistencies than it solved.

If you remove the PYTHONFSENCODING, then we have to reconsider
removal of sys.setfilesystemencoding().

The main argument for removal of the sys function was having
the environment variable.

If you remove both, Python will get very poor grades for OS
interoperability on platforms that often deal with multiple
different encodings for file names.

I am repeating myself, but please keep in mind that the locale
is an application scope setting. It doesn't have anything
to do with what's actually stored in file systems or what the
OS uses internally.

Python therefore has to provide a way to customize the file system
encoding and allow to override the locale guessing that's currently
happening.

You can't just tell people to go with whatever encoding setup
you prefer to make Python's guessing easier or more correct. Python
has to adapt to what the users actually use, not the other way
around. Where that's not easily possible, there have to be ways
to explicitly tell Python what to use... telling the user to adjust
his or her locale settings just to be able to run Python is not
an option.

The world is still moving towards Unicode - it's not 100% there
yet.
History
Date User Action Args
2010-10-11 13:45:46lemburgsetrecipients: + lemburg, loewis, ixokai, ronaldoussoren, pitrou, vstinner, pjenvey
2010-10-11 13:45:43lemburglinkissue9992 messages
2010-10-11 13:45:41lemburgcreate