homepage

> What does use getlocale is time.strptime and datetime.datetime.strptime
calendar.LocaleTextCalendar also uses getlocale() and getdefaultlocale(). The result from getdefaultlocale() cannot be set via setlocale() in Windows, which also breaks resetlocale().
 >>> locale.getdefaultlocale()
 ('en_GB', 'cp1252')
 >>> locale._build_localename(locale.getdefaultlocale())
 'en_GB.cp1252'
This is doubly invalid. It's a BCP-47 locale name with an encoding that's not UTF-8. As of Windows 10 v1803, UTF-8 is supported in ucrt locales, and for BCP-47 locale names, only UTF-8 is allowed to be set explicitly. (If not set to UTF-8 explicitly, then ucrt implicitly uses the given locale's legacy ANSI code page.) Even if something other than UTF-8 were allowed, ucrt will not accept a code page with a "cp" prefix.
Default LocaleTextCalendar case:
 >>> c = calendar.LocaleTextCalendar()
 >>> try: c.formatweekday(1, 10)
 ... except Exception as e: print(e)
 ...
 unsupported locale setting
It works as long as setting the locale succeeds and it can restore the original locale. For example, setting "es" (Spanish):
 >>> c = calendar.LocaleTextCalendar(locale='es')
 >>> locale.setlocale(locale.LC_TIME, 'C')
 'C'
 >>> c.formatweekday(1, 10)
 ' martes '
Now try with the current locale as a BCP-47 locale name.
 >>> locale.setlocale(locale.LC_TIME, 'en')
 'en'
The parsed getlocale() result is, like with the default locale, doubly invalid. It's a BCP-47 locale name with an encoding that's not UTF-8, and the 'ISO8859-1' codeset is meaningless to ucrt.
 >>> locale.getlocale(locale.LC_TIME)
 ('en_US', 'ISO8859-1')
So restoring the locale fails:
 >>> try: c.formatweekday(1, 10)
 ... except Exception as e: print(e)
 ...
 unsupported locale setting
and it's still set to "es":
 >>> locale.setlocale(locale.LC_TIME)
 'es'