On 18.02.2021 10:36, Eryk Sun wrote:
> It's not just a Windows problem. For example, getlocale() doesn't return the POSIX locale modifier in a 3-tuple (language, encoding, modifier). So it can't be used to restore a locale for which the modifier is mandatory.

The APIs were written at a time where locale modifiers simply did
not exist. Support could be added via a special locale tuple return
object, which looks like 2-tuple, but comes with extra attributes
to store the modifier, in order to maintain backwards compatibility
-- as is done in several other places as well (e.g. the codec
registry).

This would indeed require a larger rewrite of the logic.

To Steve's question: The locale aliasing logic is based
on the X11 locale aliasing system. It was later extended to
also add glibc aliases. This is portable across many Unix based
systems, but support for Windows is only partial, due to the
completely different approach Windows' CRT took to locales.

Even on most Unix systems, the locale information did not include
encoding information, which we needed to help applications
with Unicode I/O encoding support, so this had to be enriched and
because X11 was the defacto standard on Unix at the time, its locale
aliasing table was used for this.

At the time Fredrik Lundh added some Windows support via
locale codes.