locale.getlocale() returns wrong encoding if the locale name doesn't have one

[epozuelo]

Bug report

Bug description:

Some locales don't have an encoding especifier, and python (wrongly) assumes it is ISO-8859-1, when it may not be. For example, the following code:

import locale

l = locale.getlocale()
print(f"locale: {l}, encoding: {locale.getencoding()}")
locale.setlocale(locale.LC_ALL, l)

Returns:

$ LANG=en_GB.UTF-8 python3 test.py 
locale: ('en_GB', 'UTF-8'), encoding: UTF-8
$ LANG=en_IN python3 test.py 
locale: ('en_IN', 'ISO8859-1'), encoding: UTF-8
Traceback (most recent call last):
  File "/home/emilio/profesional/freexian-ext/test.py", line 5, in <module>
    locale.setlocale(locale.LC_ALL, l)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/locale.py", line 615, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

Traceback (most recent call last):
  File "/home/emilio/test.py", line 5, in <module>
    locale.setlocale(locale.LC_ALL, l)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/locale.py", line 615, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

The en_IN locale uses UTF-8, which is correctly returned in locale.getencoding(), but not in locale.getlocale(). Using the tuple returned by locale.getlocale() in a setlocale call fails.

This probably affects other locales that use UTF-8 as their encoding but don't especify it in the locale name.

This was tested on Debian stable (trixie) with Python 3.13.

CPython versions tested on:

3.13

Operating systems tested on:

Linux

[harjothkhara]

I can reproduce the underlying data issue on current main:

>>> import locale
>>> locale.normalize('en_IN')
'en_IN.ISO8859-1'
>>> locale._parse_localename('en_IN')
('en_IN', 'ISO8859-1')
>>> locale.locale_alias['en_in']
'en_IN.ISO8859-1'

So getlocale() reports ISO8859-1 while getencoding() reports UTF-8, and on the reported glibc setup (where en_IN is UTF-8-only) the round-trip setlocale(LC_ALL, getlocale()) then fails.

The root cause looks like it's in the alias data, not just the parse path: Tools/i18n/makelocalealias.py applies the X11 locale.alias table after the glibc SUPPORTED list, so X11's legacy en_IN → ISO8859-1 overrides glibc's en_IN/UTF-8 during regeneration. getlocale() → _parse_localename → normalize then surfaces that invented encoding. Note that fixing only the _parse_localename return is insufficient: setlocale(cat, ('en_IN', None)) goes back through _build_localename → normalize → 'en_IN.ISO8859-1' and fails again, so a complete fix has to touch normalize/the alias data (or the setlocale tuple path), not just the getter.

This is long-standing, documented behavior — the normalize docstring promises a default encoding for the locale code, but that assumption no longer holds universally on modern UTF-8-only systems — and it overlaps the still-open meta-issue #87281, where returning None for the encoding was discussed and never decided.

Two candidate directions, with a maintainer call needed on which:

1. Narrow data fix — 'en_in': 'en_IN.UTF-8' in the alias table (plus a special-case in makelocalealias.py, mirroring the existing c.utf8/el_gr@euro carve-outs). Tiny blast radius, fixes the reported locale and the round-trip in both directions. Downside: it's localized — doesn't help en_GB, fr_FR, etc. on UTF-8-only systems.
2. General contract fix — stop inventing an encoding when the locale name carries none (return None, per the documented "encoding may be None" contract), paired with a setlocale/_build_localename change so the round-trip still works. Larger blast radius: every getlocale()[1] consumer on glibc with a bare LANG would start seeing None, and test_locale.NormalizeTest currently codifies the guessing behavior. This is essentially the change left undecided in locale.getlocale fails if locale is set #87281.

Happy to put up a PR for whichever direction you prefer. (Caveat on my end: I verified the alias-data behavior via direct _parse_localename/normalize calls; I can't run the full glibc setlocale round-trip locally, so the cross-platform proof would lean on Linux CI.)