Marc-Andre Lemburg <m...@egenix.com> added the comment:
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:
"""
RETURN VALUE
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.
----------
nosy: +lemburg
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue8610>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
