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
Deprecate locale.getdefaultlocale() function #90817
The locale.getdefaultlocale() function only relies on environment variables. At Python startup, Python calls setlocale() is set the LC_CTYPE locale to the user preferred encoding.
Since Python 3.7, if the LC_CTYPE locale is "C" or "POSIX", PEP-538 sets the LC_CTYPE locale to a UTF-8 variant if available, and PEP-540 ignores the locale and forces the usage of the UTF-8 encoding. The *effective* encoding used by Python is inconsistent with environment variables.
Moreover, if setlocale() is called to set the LC_CTYPE locale to a locale different than the user locale, again, environment variables are inconsistent with the effective locale.
In these cases, locale.getdefaultlocale() result is not the expected locale and it can lead to mojibake and other issues.
For these reasons, I propose to deprecate locale.getdefaultlocale(): setlocale(), getpreferredencoding() and getlocale() should be used instead.
For the background on these issues, see recent issue:
For these reasons, I propose to deprecate locale.getdefaultlocale(): setlocale(), getpreferredencoding() and getlocale() should be used instead.
Please see the discussion on https://bugs.python.org/issue43552: locale.getpreferredencoding() needs to be deprecated as well. Instead we should have a single locale.getencoding() as outlined there... perhaps in a separate ticket ?! Thanks.
Please see the discussion on https://bugs.python.org/issue43552: locale.getpreferredencoding() needs to be deprecated as well. Instead we should have a single locale.getencoding() as outlined there... perhaps in a separate ticket ?! Thanks.
Yeah, I read this issue. But these things are too complicated :-) I prefer to move step by step.
Once locale.getencoding() (or a similar function) is added, we can update the deprecation message.
I hope to be able to deprecate getdefaultlocale() and to add such new function in Python 3.11.
getdefaultlocale() falls back to LANG and LANGUAGE. It allows also to specify a list of looked up environment variables. How could this use case be covered with getlocale()?
getdefaultlocale() falls back to LANG and LANGUAGE.
_Py_SetLocaleFromEnv(LC_CTYPE) (e.g. setlocale(LC_CTYPE, "")) gets called at startup, except for the isolated configuration [1].
I think calendar.Locale*Calendar should try the LC_CTYPE locale if LC_TIME is "C", i.e. (None, None). Otherwise, it's introducing new default behavior. For example, with LC_ALL set to "ru_RU.utf8":
Serhiy: "getdefaultlocale() falls back to LANG and LANGUAGE. It allows also to specify a list of looked up environment variables. How could this use case be covered with getlocale()?"
What's your use case to use env vars rather than the current LC_CTYPE locale?
My concern is that when setlocale() is called, the current LC_CTYPE locale is inconsistent and you can get mojibake and others issues.
Maybe the deprecation message should be clarified. I dislike locale.getlocale(), it can return invalid locale which is not accepted by setlocale(). I wanted to deprecate it.
The point of having getlocale() is to be able to normalize the returned values to make them compatible to setlocale().
The C lib API of setlocale() to actually fetch the current locale values is completely counterintuitive, which is why I had added getlocale() instead. On top of this, setlocale() does not always return values which you can feed back into it.
@shinewook: Could you please check what locale._setlocale(locale.LC_TYPE) returns on your Windows system ? It's possible that we'll have to add more aliases to the table to fix this. Thanks.
BTW: Perhaps better to open a separate ticket for that problem...
Return of locale.getlocale() is not compatibile with typical locale string (Python 3.11.7 on Windows):
'it_IT' permits to fastly use gettext ./locale/<it_IT>/... translations mo files.
We are running into the same issue for our project. I just reconfirmed this with Python 3.12.
Hum, the API is surprising, but locale.setlocale() should be used to get the current locale: locale.setlocale(locale.LC_CTYPE, None) gets the current LC_CTYPE locale for example.
It is indeed quite misleading. I had thought setlocaleonly did just that - set the locale. However, we still have the same issue - LC_CTYPE still returns a non-POSIX locale code on Windows.
BTW: Perhaps better to open a separate ticket for that problem...
I didn't find any existing issue for this. For me, getlocale and setlocale returns 'English_Australia', similar to what shineworld reported. We have been discussing a work-around in our project of using Win32 directly, but it's not a comprehensive substitute.
I didn't find any existing issue for this. For me, getlocale and setlocale returns 'English_Australia', similar to what shineworld reported. We have been discussing a work-around in our project of using Win32 directly, but it's not a comprehensive substitute.
Please open a new ticket, so we can track the issue. Thanks.
Python 3.14.5
<string>:1: DeprecationWarning: 'locale.getdefaultlocale' is deprecated and slated for removal in Python
3.15. Use setlocale(), getencoding() and getlocale() instead.
('en_US', 'UTF-8')
Activity
vstinner commentedon Feb 6, 2022
The locale.getdefaultlocale() function only relies on environment variables. At Python startup, Python calls setlocale() is set the LC_CTYPE locale to the user preferred encoding.
Since Python 3.7, if the LC_CTYPE locale is "C" or "POSIX", PEP-538 sets the LC_CTYPE locale to a UTF-8 variant if available, and PEP-540 ignores the locale and forces the usage of the UTF-8 encoding. The *effective* encoding used by Python is inconsistent with environment variables.
Moreover, if setlocale() is called to set the LC_CTYPE locale to a locale different than the user locale, again, environment variables are inconsistent with the effective locale.
In these cases, locale.getdefaultlocale() result is not the expected locale and it can lead to mojibake and other issues.
For these reasons, I propose to deprecate locale.getdefaultlocale(): setlocale(), getpreferredencoding() and getlocale() should be used instead.
For the background on these issues, see recent issue:
vstinner commentedon Feb 6, 2022
cal_locale.py: Test calendar.LocaleTextCalendar() default locale, manual test for #75349.
vstinner commentedon Feb 6, 2022
New changeset 04dd60e by Victor Stinner in branch 'main':
bpo-46659: Update the test on the mbcs codec alias (GH-31168)
04dd60e
vstinner commentedon Feb 6, 2022
New changeset 06b8f16 by Victor Stinner in branch 'main':
bpo-46659: test.support avoids locale.getdefaultlocale() (GH-31167)
06b8f16
malemburg commentedon Feb 6, 2022
Please see the discussion on https://bugs.python.org/issue43552: locale.getpreferredencoding() needs to be deprecated as well. Instead we should have a single locale.getencoding() as outlined there... perhaps in a separate ticket ?! Thanks.
vstinner commentedon Feb 6, 2022
Yeah, I read this issue. But these things are too complicated :-) I prefer to move step by step.
Once locale.getencoding() (or a similar function) is added, we can update the deprecation message.
I hope to be able to deprecate getdefaultlocale() and to add such new function in Python 3.11.
vstinner commentedon Feb 6, 2022
This change is not correct, I created bpo-46668 to fix it.
vstinner commentedon Feb 7, 2022
New changeset 7a0486e by Victor Stinner in branch 'main':
bpo-46659: calendar uses locale.getlocale() (GH-31166)
7a0486e
serhiy-storchaka commentedon Feb 8, 2022
getdefaultlocale() falls back to LANG and LANGUAGE. It allows also to specify a list of looked up environment variables. How could this use case be covered with getlocale()?
eryksun commentedon Feb 8, 2022
_Py_SetLocaleFromEnv(LC_CTYPE) (e.g. setlocale(LC_CTYPE, "")) gets called at startup, except for the isolated configuration [1].
I think calendar.Locale*Calendar should try the LC_CTYPE locale if LC_TIME is "C", i.e. (None, None). Otherwise, it's introducing new default behavior. For example, with LC_ALL set to "ru_RU.utf8":
3.8:
>>> locale.getlocale(locale.LC_TIME) (None, None) >>> locale.getlocale(locale.LC_CTYPE) ('ru_RU', 'UTF-8') >>> cal = calendar.LocaleTextCalendar() >>> cal.formatweekday(0, 15) ' Понедельник '3.11.0a5+:
>>> locale.getlocale(locale.LC_TIME) (None, None) >>> locale.getlocale(locale.LC_CTYPE) ('ru_RU', 'UTF-8') >>> cal = calendar.LocaleTextCalendar() >>> cal.formatweekday(0, 15) ' Monday ' >>> locale.setlocale(locale.LC_TIME, '') 'ru_RU.utf8' >>> cal = calendar.LocaleTextCalendar() >>> cal.formatweekday(0, 15) ' Понедельник '[1] https://docs.python.org/3/c-api/init_config.html?#isolated-configuration
vstinner commentedon Feb 8, 2022
Serhiy: "getdefaultlocale() falls back to LANG and LANGUAGE. It allows also to specify a list of looked up environment variables. How could this use case be covered with getlocale()?"
What's your use case to use env vars rather than the current LC_CTYPE locale?
My concern is that when setlocale() is called, the current LC_CTYPE locale is inconsistent and you can get mojibake and others issues.
See for example:
https://bugs.python.org/issue43552#msg389069
Marc-Andre Lemburg wants to deprecate it:
https://bugs.python.org/issue43552#msg389076
21 remaining items
vstinner commentedon Jan 30, 2024
Maybe the deprecation message should be clarified. I dislike locale.getlocale(), it can return invalid locale which is not accepted by setlocale(). I wanted to deprecate it.
malemburg commentedon Apr 16, 2024
The point of having getlocale() is to be able to normalize the returned values to make them compatible to setlocale().
The C lib API of setlocale() to actually fetch the current locale values is completely counterintuitive, which is why I had added getlocale() instead. On top of this, setlocale() does not always return values which you can feed back into it.
@shinewook: Could you please check what locale._setlocale(locale.LC_TYPE) returns on your Windows system ? It's possible that we'll have to add more aliases to the table to fix this. Thanks.
BTW: Perhaps better to open a separate ticket for that problem...
Wedge009 commentedon Mar 2, 2025
We are running into the same issue for our project. I just reconfirmed this with Python 3.12.
It is indeed quite misleading. I had thought
setlocaleonly did just that - set the locale. However, we still have the same issue -LC_CTYPEstill returns a non-POSIX locale code on Windows.Have there been any issues reported for this?
malemburg commentedon Mar 3, 2025
Is there a separate issue we can track this ?
I just tried on my German Windows box and it returns 'de_DE' just fine. Perhaps there's some alias missing from the normalization logic ?!
Wedge009 commentedon Mar 3, 2025
I didn't find any existing issue for this. For me,
getlocaleandsetlocalereturns 'English_Australia', similar to what shineworld reported. We have been discussing a work-around in our project of using Win32 directly, but it's not a comprehensive substitute.vstinner commentedon Mar 3, 2025
This issue is closed. Please open a new issue.
malemburg commentedon Mar 3, 2025
Please open a new ticket, so we can track the issue. Thanks.
maint: avoid warning related to locale.getdefaultlocale deprecation
cclauss commentedon Jun 11, 2026
Will
locale.getdefaultlocale()be removed in Python 3.15?Py3.14 says yes but Py3.15b2 still has it.
%
python3.14 -V && python3.14 -c 'import locale;print(locale.getdefaultlocale())'%
python3.15 -V && python3.15 -c 'import locale;print(locale.getdefaultlocale())'hugovk commentedon Jun 11, 2026
No, it was undeprecated in #130796 / #143069.
Let's backport the undeprecation to avoid further confusion.
fix: getdefaultlocale depracate python/cpython#90817
fix: getdefaultlocale depracate python/cpython#90817
fix: getdefaultlocale depracate python/cpython#90817
fix: getdefaultlocale depracate python/cpython#90817
Revert "fix: getdefaultlocale depracate python/cpython#90817"