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 vstinner
Recipients ixokai, lemburg, loewis, pitrou, pjenvey, ronaldoussoren, vstinner
Date 2010-10-11.12:15:19
SpamBayes Score 5.7954797e-10
Marked as misclassified No
Message-id <201010111415.12700.victor.stinner@haypocalc.com>
In-reply-to <4CB20496.9070108@v.loewis.de>
Content
> > ... So Antoine and Martin: which encoding do you prefer?
> 
> I still propose to drop the fsname encoding. Then this question goes away.

You mean that we should use the following encoding for the command line 
arguments, environment variables and all filenames/paths:
 - Mac OS X: utf-8
 - Windows: unicode for command line/env, mbcs to decode filenames
 - others OSes: locale encoding

To do that, we have to:
 - "others OSes": delete the PYTHONFSENCODING variable
 - Mac OS X: use utf-8 to decode the command line arguments (we can use 
PyUnicode_DecodeUTF8()+PyUnicode_AsWideCharString() before Python is 
initialized)

On "others OSes", we continue to use the FS encoding to encode command 
line/env vars, because the FS encoding will always be the locale encoding. And 
it's more pratical to use sys.getfilesystemencoding() than mbstowcs(), 
wcstombs(), _Py_wchar2char(), _Py_char2wchar(), etc. because the FS encoding 
doesn't depend on the current locale, and it uses Python codecs which support 
more error handlers.

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.
History
Date User Action Args
2010-10-11 12:15:22vstinnersetrecipients: + vstinner, lemburg, loewis, ixokai, ronaldoussoren, pitrou, pjenvey
2010-10-11 12:15:20vstinnerlinkissue9992 messages
2010-10-11 12:15:19vstinnercreate