You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Deprecation of locale.getdefaultlocale breaks POSIX compatibility on Windows platform #130796
In summary, without getdetfaultlocale, tools that rely on POSIX locales cannot reliably get the same information from getlocale or setlocale on Windows.
For example, Linux will return something like 'en_AU'. But on Windows, getlocale will return something like 'English_Australia'.
I'm afraid that this issue is too late because the ship has already sailed. I don't remember well which alternatives there are for that kind of issue so I'll tag @vstinner who was responsible for the original patch. However, I doubt that we would reinstate locale.getdefaultlocale (or we would do something else).
EDIT: Actually it seems to only be deprecated and planned for removal in 3.15: #111187.
I don't think I - or others - was asking for a reinstatement, just a viable alternative for the cases where POSIX locales are expected for use with other tools such as gettext.
And yes, removal is planned for 3.15, hence the discussion now. As noted in wesnoth/wesnoth#9972 (comment), it's difficult to know how to work around the removal of getdefaultlocale when we don't know what future plans are - if any - for any replacement functionality.
The reason why POSIX compatibility breaks is this:
The windows_locale dictionary is only used by the locale.getdefaultlocale() function and this function is deprecated: it will be removed in Python 3.15.
It is generally a bad idea to call setlocale() in some library routine, since as a side effect it affects the entire program. Saving and restoring it is almost as bad: it is expensive and affects other threads that happen to run before the settings have been restored.
I see that the original reason for removal is the use of non-ASCII characters in locale. Do you think this is a common case?
If fixing the problem is difficult or impossible, perhaps it is worth introducing a similar function called getpreferredlocale?
The windows_locale dictionary is well out of date anyway (and is no longer updated from what I can tell), so keeping the function is not great either. The dictionary itself is not deprecated, and so you should be able to use it. If we do want to provide this functionality on windows, it should be better though out.
I was unable to find any windows API that returns the POSIX format.
I wasn't aware that locale.getdefaultlocale() is the only way to get a POSIX-like locale name on Windows when I deprecated the function. I didn't know neither that there are users of the "read the locale from environment variables" feature. There is no good replacement for these features, so I wrote #143069 to undeprecate locale.getdefaultlocale().
This is why I had added locale.getdefaultlocale() a long while ago: I did not want to break libraries which rely on other custom local settings by calling setlocale(LC_ALL, ""), since this then applies to the whole process. Doing so at random times can be especially problematic for embedded Python interpreters.
Nowadays, CPython does call setlocale(LC_CTYPE, NULL); during startup and that was what triggered the deprecation of locale.setdefaultlocale(). However, you are right in that the call only configures the LC_CTYPE part of the locale settings, not the other ones, such as LC_TIME. We should probably change the startup code to call setlocale(LC_ALL, "") instead - as recommended by the C lib docs.
So I guess two changes would be necessary to fix this situation:
add the Windows locale names to the alias table
have Python init all locale parts during startup
or we leave locale.getdefaultlocale() around, but given that it's purpose has been superseded, I don't think that's a good idea.
Activity
picnixz commentedon Mar 3, 2025
I'm afraid that this issue is too late because the ship has already sailed.I don't remember well which alternatives there are for that kind of issue so I'll tag @vstinner who was responsible for the original patch.However, I doubt that we would reinstatelocale.getdefaultlocale(or we would do something else).EDIT: Actually it seems to only be deprecated and planned for removal in 3.15: #111187.
Wedge009 commentedon Mar 3, 2025
I don't think I - or others - was asking for a reinstatement, just a viable alternative for the cases where POSIX locales are expected for use with other tools such as gettext.
And yes, removal is planned for 3.15, hence the discussion now. As noted in wesnoth/wesnoth#9972 (comment), it's difficult to know how to work around the removal of
getdefaultlocalewhen we don't know what future plans are - if any - for any replacement functionality.vstinner commentedon Mar 3, 2025
On my Windows 11 VM, getlocale() returns a "POSIX" locale as expected:
Can you please elaborate your issue? What are the results of
locale.getlocale()andlocale.setlocale(locale.LC_CTYPE, None)?Wedge009 commentedon Mar 3, 2025
It's as I described above and in #90817 (comment).
@shineworld reported something similar in #90817 (comment)
@Elvish-Hunter reports the same in wesnoth/wesnoth#9972 (comment)
2trvl commentedon Mar 6, 2025
The reason why POSIX compatibility breaks is this:
Windows 22H2, Python 3.13.1:
>>> locale.setlocale(locale.LC_CTYPE) 'English_United States.1252' >>> locale.getlocale() ('English_United States', '1252') >>> locale.getdefaultlocale() ('en_US', 'cp1252')2trvl commentedon Mar 7, 2025
I would like to know how can I find out the system locale for LC_TIME without using
defaultlocale?Apparently I have no other option than to change the interpreter locale:
It is generally a bad idea to call setlocale() in some library routine, since as a side effect it affects the entire program. Saving and restoring it is almost as bad: it is expensive and affects other threads that happen to run before the settings have been restored.
I see that the original reason for removal is the use of non-ASCII characters in locale. Do you think this is a common case?
If fixing the problem is difficult or impossible, perhaps it is worth introducing a similar function called
getpreferredlocale?iw3: waifu2x: Use short language name on Windows in GUI
StanFromIreland commentedon May 17, 2025
The
windows_localedictionary is well out of date anyway (and is no longer updated from what I can tell), so keeping the function is not great either. The dictionary itself is not deprecated, and so you should be able to use it. If we do want to provide this functionality on windows, it should be better though out.I was unable to find any windows API that returns the POSIX format.
6 remaining items
gpshead commentedon Dec 20, 2025
I added the 3.15 release blocker labels as if we don't solve this for 3.15 we should stop the deprecation.
chris-eibl commentedon Dec 22, 2025
Related: #82986 and #67613 (where @eryksun presented a rough prototype to auto-populate
locale_alias, #67613 (comment)).pythongh-130796: Undeprecate locale.getdefaultlocale()
vstinner commentedon Dec 22, 2025
I wasn't aware that
locale.getdefaultlocale()is the only way to get a POSIX-like locale name on Windows when I deprecated the function. I didn't know neither that there are users of the "read the locale from environment variables" feature. There is no good replacement for these features, so I wrote #143069 to undeprecatelocale.getdefaultlocale().vstinner commentedon Dec 22, 2025
FYI
getdefaultlocale()was not removed yet because we are aware of these issues.malemburg commentedon Dec 22, 2025
I suppose we could make
locale.getlocale()work for this use case by adding the Windows locale names to thelocale_aliastable.This is why I had added
locale.getdefaultlocale()a long while ago: I did not want to break libraries which rely on other custom local settings by callingsetlocale(LC_ALL, ""), since this then applies to the whole process. Doing so at random times can be especially problematic for embedded Python interpreters.Nowadays, CPython does call
setlocale(LC_CTYPE, NULL);during startup and that was what triggered the deprecation oflocale.setdefaultlocale(). However, you are right in that the call only configures the LC_CTYPE part of the locale settings, not the other ones, such as LC_TIME. We should probably change the startup code to callsetlocale(LC_ALL, "")instead - as recommended by the C lib docs.So I guess two changes would be necessary to fix this situation:
add the Windows locale names to the alias table
have Python init all locale parts during startup
or we leave
locale.getdefaultlocale()around, but given that it's purpose has been superseded, I don't think that's a good idea.vstinner commentedon Dec 23, 2025
setlocale(LC_CTYPE, "")is called by Python during startup: in_Py_SetLocaleFromEnv(LC_CTYPE)which is called by_PyPreConfig_Write().gh-130796: Undeprecate locale.getdefaultlocale() (#143069)
vstinner commentedon Dec 23, 2025
I close the issue. The function is no longer deprecated in Python 3.15.
[3.14] gh-130796: Undeprecate locale.getdefaultlocale() (GH-143069) (#…
[3.13] gh-130796: Undeprecate locale.getdefaultlocale() (GH-143069) (#…