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.