| msg8774 - (view) |
Author: Syver Enstad (syvere) |
Date: 2002-01-16 04:56 |
| locale.setlocale doesn't recognize the the format that locale.py uses to set the locale, ie. no_NO and friends. 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) *  |
Date: 2002-01-16 05:07 |
| Logged In: YES user_id=31435 Mark, know anything about this? I don't. |
|
|
| msg8776 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2002-01-16 11:50 |
| Logged In: YES user_id=21627 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 user_id=428736 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\locale.py", line 384, in resetlocale _setlocale(category, _build_localename(getdefaultlocale ())) locale.Error: locale setting not supported And to clarify what input getdefaultlocale returns on my machine: >>> locale.getdefaultlocale() ('no_NO', 'cp1252') and: >>> locale._build_localename(locale.getdefaultlocale()) 'no_NO.cp1252' By the way, is this bug fixed in python 2.2? |
|
|
| msg8778 - (view) |
Author: Johannes Gijsbers (jlgijsbers) *  |
Date: 2004-11-08 18:59 |
| Logged In: YES user_id=469548 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 information. >>> import locale >>> locale.getdefaultlocale() ['en_US', 'utf'] >>> locale.resetlocale() Traceback (most recent call last): File "", line 1, in ? File "/home/johannes/python/Lib/locale.py", line 389, in resetlocale _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. http://python.org/sf/813449 seems to be the same bug, BTW. |
|
|
| msg8779 - (view) |
Author: Georg Brandl (georg.brandl) * |
Date: 2005-06-05 18:04 |
| Logged In: YES user_id=1188172 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 user_id=259388 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 information. >>> import locale; locale.getdefaultlocale() ('en_US', 'utf') >>> locale.resetlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/locale.py", line 389, in resetlocale _setlocale(category, _build_localename(getdefaultlocale())) locale.Error: unsupported locale setting |
|
|
| msg8781 - (view) |
Author: Georg Brandl (georg.brandl) * |
Date: 2006-02-20 19:09 |
| Logged In: YES user_id=849994 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 ? Should getdefaultlocale be earmarked for deprecation? |
|
|
| msg185041 - (view) |
Author: Marc-Andre Lemburg (lemburg) * |
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) * |
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: Alyssa Coghlan (ncoghlan) * |
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()? |
|
|