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 Arfrever, lemburg, loewis, pitrou, vstinner
Date 2010-05-05.07:45:18
SpamBayes Score 2.1322e-11
Marked as misclassified No
Message-id <>
In-reply-to <>
STINNER Victor wrote:
> I don't think it's a good idea to display an fatal error at runtime. If nl_langinfo(CODESET) is not available, configure should fail or we should fallback to an hardcoded encoding (ok but which one?).

If nl_langinfo(CODESET) fails, Python should assume the default
locale, which is "C" on POSIX platforms. The "C" locale uses
ASCII as encoding, so Python should use that as well. Note that the
manpage for nl_langinfo() doesn't mention any errors that could
be raised by it:

       If  no  locale  has  been  selected  for  the appropriate category, nl_langinfo() returns a
       pointer to the corresponding string in the "C" locale.

       If item is not valid, a pointer to an empty string is returned.

       This pointer may point to static data that may be overwritten on the next call to  nl_lang‐
       info() or setlocale(3).

As with all locale APIs, it is not thread-safe, which can become
an issues if Python gets embedded in a multi-threaded application.

There's also another issue: it's possible that nl_langinfo(CODESET)
returns an encoding which is not known to Python.

In such a case, it would be best to issue a warning to the
user and fall back to ASCII as in the "C" locale case.

Terminating Python with a fatal error would provide the worst of
all user experiences. -1 on that.
Date User Action Args
2010-05-05 07:45:21lemburgsetrecipients: + lemburg, loewis, pitrou, vstinner, Arfrever
2010-05-05 07:45:19lemburglinkissue8610 messages
2010-05-05 07:45:18lemburgcreate