@eryksun: Does this approach look good to you? It's basically restores Python 3.10 behavior. I just adjusted the test.

Does this approach look good to you? It's basically restores Python 3.10 behavior. I just adjusted the test.

Yes, having a fallback for the process ANSI code page is for the best -- even though we support all of the known code pages in standard Windows locales. Thank you for clarifying the reason for its existence in the comments.

I'd prefer to also have a fallback to "oem" for the process OEM code page, but adding _winapi.GetOEMCP() is an enhancement request.

Thanks @eryksun for your review.

My use case is to deprecate the locale.getdefaultlocale() function. Adding an alias for the OEM page code is unrelated. If you consider that it's an useful feature, you can open a separated PR. So far, nobody requested it, so maybe it's not needed. I'm not convinced that the fallbak for the ANSI code page is used by anyone.

I'm not convinced that the fallbak for the ANSI code page is used by anyone.

I don't know whether the ANSI fallback is used by anyone. As I said, I've never worked with supplemental/replacement custom locales. The suggestion can be shelved until someone has an issue or explicitly requests a fallback for OEM as something required for their work environment.

The suggestion can be shelved until someone has an issue or explicitly requests a fallback for OEM as something required for their work environment.

It sounds perfectly reasonable :-)