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 Arfrever, lemburg, loewis, pitrou, vstinner
Date 2010-05-07.23:51:02
SpamBayes Score 0.00062885485
Marked as misclassified No
Message-id <1273276268.34.0.154592646957.issue8610@psf.upfronthosting.co.za>
In-reply-to
Content
I realized that fallback to ASCII instead of UTF-8 is not possible yet because of #8611: if it fallbacks to ASCII, it's not more possible to run Python in a non-ASCII directory. I have a patch set fixing #8611 but it's huge and complex. I will not be fixed quickly (if it would be possible someday to fix it).

My new patch fallback to utf-8 instead of ascii, even if I agree that it would be better to fallback to ascii. Improve unicode, surrogates & friends is complex, and I prefer to fix bugs step by step. I propose to first ensure that Py_FileSystemEncoding is always set, and later write a new patch to fallback to ASCII instead of UTF-8.

Patch version 5:
 - fallback to utf-8 instead of ascii
 - Set Py_FileSystemDefaultEncoding to NULL to Py_Finalize(): thanks to that, it should be possible to call Py_InitializeEx() (initfsencoding()) twice or more
 - initfsencoding() doesn't call _PyCodec_Lookup() on get_codeset() success because  get_codeset() does already call it
 - explain that the fatal error is very unlikely
History
Date User Action Args
2010-05-07 23:51:08vstinnersetrecipients: + vstinner, lemburg, loewis, pitrou, Arfrever
2010-05-07 23:51:08vstinnersetmessageid: <1273276268.34.0.154592646957.issue8610@psf.upfronthosting.co.za>
2010-05-07 23:51:06vstinnerlinkissue8610 messages
2010-05-07 23:51:05vstinnercreate