This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: locale.resetlocale is broken
Type: behavior Stage: needs patch
Components: Library (Lib) Versions: Python 3.11, Python 3.10, Python 3.9
Status: open Resolution:
Dependencies: 813449 Superseder:
Assigned To: Nosy List: ajaksu2, akuchling, georg.brandl, georg.brandl, jlgijsbers, lemburg, loewis, meonkeys, mhammond, ncoghlan, syvere, tim.peters
Priority: normal Keywords:

Created on 2002-01-16 04:56 by syvere, last changed 2022-04-10 16:04 by admin.

Messages (13)
msg8774 - (view) Author: Syver Enstad (syvere) Date: 2002-01-16 04:56
locale.setlocale doesn't recognize the the format that uses to set the locale, ie. no_NO and 

The only way I've succeeded in setting the locale on 
Python 2.1 is to use the format described in the 
Visual C++ C-runtime library docs for setlocale where 
a more verbose format is used to set the locale.
msg8775 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2002-01-16 05:07
Logged In: YES 

Mark, know anything about this?  I don't.
msg8776 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-01-16 11:50
Logged In: YES 

Can you provide a detailed test case? AFAIK, no_NO is indeed
no supported locale name on Windows, and I don't think
Python aanywhere uses it without the application explicitly
saying so.
msg8777 - (view) Author: Syver Enstad (syvere) Date: 2002-01-16 13:39
Logged In: YES 

Sorry, I forgot to mention the testcase I am using. The 
test case that fails is the locale module itself, when 
running it as a standalone application that is.

To be more specific:
  File "d:\devtools\python21\lib\", line 384, in 
    _setlocale(category, _build_localename(getdefaultlocale
locale.Error: locale setting not supported

And to clarify what input getdefaultlocale returns on my 

>>> locale.getdefaultlocale()
('no_NO', 'cp1252')

>>> locale._build_localename(locale.getdefaultlocale())

By the way, is this bug fixed in python 2.2?
msg8778 - (view) Author: Johannes Gijsbers (jlgijsbers) * (Python triager) Date: 2004-11-08 18:59
Logged In: YES 

Still reproducible with Python 2.4:

Python 2.4b2 (#19, Nov  8 2004, 11:15:07)
[GCC 3.3.5 (Debian 1:3.3.5-2)] on linux2
Type "help", "copyright", "credits" or "license" for more
>>> import locale
>>> locale.getdefaultlocale()
['en_US', 'utf']
>>> locale.resetlocale()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/johannes/python/Lib/", line 389, in
    _setlocale(category, _build_localename(getdefaultlocale()))
locale.Error: unsupported locale setting

Note that if I run python with 'LANG=nl_NL python', the
error does not occur. seems to be the same bug, BTW.
msg8779 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2005-06-05 18:04
Logged In: YES 

As this is not Windows specific, setting Category to Library.
msg8780 - (view) Author: Adam Monsen (meonkeys) Date: 2005-09-13 22:27
Logged In: YES 

I'm seeing this error on Fedora Core 4:

Python 2.4.1 (#1, May 16 2005, 15:19:29) 
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for more
>>> import locale; locale.getdefaultlocale()
('en_US', 'utf')
>>> locale.resetlocale()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/", line 389, in resetlocale
    _setlocale(category, _build_localename(getdefaultlocale()))
locale.Error: unsupported locale setting
msg8781 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2006-02-20 19:09
Logged In: YES 

The same applies to other locales.

From #813449 (a duplicate of this):
This is a known limitation: getdefaultlocale should not be
used in new code.

If the intention is to compute the locale's encoding,
locale.getpreferredencoding should be used instead.
msg114172 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-08-17 21:22
Still a problems on py3k.  Set stage to needs patch as it's so easy to reproduce.
msg185023 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2013-03-23 00:53
Can we simply document that getpreferredencoding should be used instead as stated in msg8781 ?  Should getdefaultlocale be earmarked for deprecation?
msg185041 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2013-03-23 12:33
Adding support for locales that are not recognized is easy and the locale parser could also learn about formats that it doesn't yet understand, so patches are welcome.

The main problem here is that setlocale() only understands a very limited set of locale names.

Please note that locale.getdefaultlocale() is not the same as locale.getpreferredencoding():

* getdefaultlocale() aims to find the default locale settings for a program which has not yet called setlocale(LC_ALL, "").

* getpreferredencoding() tries to make an educated guess at the encoding the user has setup for his/her environment. It works well on Windows, but on Unix, requires a call to setlocale() to implement the environment variable parsing, which is exactly what getdefaultlocale() tries to avoid.
setlocale() is not thread-safe, so the approach taken by getpreferredencoding() can have unwanted side-effects.
msg240667 - (view) Author: A.M. Kuchling (akuchling) * (Python committer) Date: 2015-04-13 17:19
It doesn't seem to me that we've really deprecated getdefaultlocale() -- it's not documented as such, and MAL makes the good point that getdefaultlocale() is trying to avoid calling setlocale().

Perhaps this is just a documentation problem?  _build_localename() just glues together the language code and the encoding, resulting in things like en_US.ISO8859-1, which turns out to not work.  So maybe we should document that getdefaultlocale() will sometimes guess wrong.
msg293297 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2017-05-09 09:49
Trying to come up with a short LC_MONETARY example for PEP 538, I just ran into what seems to be a related problem with locale.resetlocale(), which is that it doesn't work properly for categories other than LC_CTYPE: locale.getdefaultlocale() doesn't let you say which category you're actually interested in, so even if you specific a category for resetlocale(), it's going to look at the LC_CTYPE setting, *NOT* the one for the category you're interested in.

So perhaps a suitable design change here would be to update resetlocale() to just pass an empty string (letting the underlying platform API call figure out the right default), rather than passing the result of locale.getdefaultlocale()?
Date User Action Args
2022-04-10 16:04:52adminsetgithub: 35920
2021-12-23 23:26:47ajaksu2setnosy: + ajaksu2

versions: + Python 3.9, Python 3.10, Python 3.11, - Python 2.7, Python 3.3, Python 3.4
2017-05-09 09:49:54ncoghlansetnosy: + ncoghlan
messages: + msg293297
2015-04-13 17:19:19akuchlingsetnosy: + akuchling
messages: + msg240667
2014-02-03 15:43:15BreamoreBoysetnosy: - BreamoreBoy
2013-12-10 18:24:49terry.reedysetversions: + Python 3.3, Python 3.4, - Python 3.1, Python 3.2
2013-03-23 12:33:37lemburgsetnosy: + lemburg
messages: + msg185041
2013-03-23 00:53:51BreamoreBoysetmessages: + msg185023
2010-08-17 21:22:44BreamoreBoysetversions: + Python 3.1, Python 2.7, Python 3.2, - Python 2.6
nosy: + BreamoreBoy
messages: + msg114172

assignee: mhammond ->
stage: test needed -> needs patch
2009-02-13 02:24:59ajaksu2setdependencies: + locale.getdefaultlocale doesnt handle all locales gracefully
type: behavior
stage: test needed
versions: + Python 2.6, - Python 2.4
2002-01-16 04:56:12syverecreate