See also issue 1699853.

The problem here is that resetlocale calls getdefaultlocale, and getdefaultlocale returns something that setlocale cannot consume on Windows.  For example, on my US windows system, getlocale returns ('English_United States', '1252'), while getdefaultlocale returns ('en_US', 'cp1252').  The latter results in the 'unsupported locale settting' error message when passed to setlocale.

Since getdefaultlocale contains special-case code for the win32 platform, I wonder if this is a bug in getdefaultlocale.  I suspect it is operating as designed, but is that operation useful if the result isn't recognized by the platform in question?  Or if, as it appears from looking at the Python code (but I haven't looked at the C code) the data is actually coming from the C runtime, perhaps the bug is that setlocale doesn't accept the output of getdefaultlocale on windows?

Hopefully Mark Andre will have an answer, but I've also added our windows experts to nosy to see if they have any insights.

Given the long standing nature of this issue, it seems that the priority isn't very high, especially since the bug is revealed not by user code but by a diagnostic routine in the stdlib.