-
-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
locale.getpreferredencoding() dies when setlocale fails #42982
Comments
I'm on Ubuntu 5.10, with Python 2.4.2-0ubuntu2, and >>> import locale
>>> locale.getpreferredencoding()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/python2.4/locale.py", line 417, in
getpreferredencoding
setlocale(LC_CTYPE, "")
File "/usr/lib/python2.4/locale.py", line 381, in
setlocale
return _setlocale(category, locale)
locale.Error: unsupported locale setting However, if I su - root - or even su right back to my This is of concern (to me, anyway) because this error I chose "Esperanto" as my language when setting up Anyway, within locale.getpreferredencoding(), line 417
>>> locale.setlocale(locale.LC_CTYPE)
'C'
>>> locale.setlocale(locale.LC_CTYPE, "")
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/python2.4/locale.py", line 381, in
setlocale
return _setlocale(category, locale)
locale.Error: unsupported locale setting
>>> locale.setlocale(locale.LC_CTYPE, None)
'C' This makes me wonder if setlocale(LC_TYPE, "") is >>> locale.nl_langinfo(locale.CODESET)
'ANSI_X3.4-1968' ... I get that result whether before or after calling Thus, as far as I can tell, it isn't really necessary
Since I don't really understand what it's doing in the Thanks! |
Logged In: YES I've got the same problem with bzr on Gentoo. If LANG or |
We noticed this too in Chandler. We worked around this issue with the |
Shouldn't the fallback be to setlocale(LC_CTYPE, "C") instead of |
You don't want to completely nix the setlocale(LC_CTYPE, "") call Of course, this might be set to something that might be valid (e.g. Reading SUS (The Single Unix Specification) I see that it explicitly says: "Upon successful completion, setlocale() shall return the string So the patch seems to be correct actually. We try to setlocale(LC_CTYPE, Mmm, but it seems setlocale() in locale.py is not adhering to the |
The patch looks fine to me. |
OK, then I'll apply it. But I am curious about your thoughts about the _parse_localename() |
I fail to see how this is related to this issue. In the OP's report, |
Sorry, I was actually off by a method last night. It turns out the problem lies in _localemodule.c. Let me start with the basic question: is our setlocale() supposed to |
Yes, it is. |
I will first point out where our current implementation is broken, in my Both C90 (7.4.1.1) and C99 (7.11.1.1) state: "A value of "C" for locale specifies the minimal environment for C [...] If a pointer to a string is given for locale and the selection can be Note that neither C or POSIX defines any errors or sets errno or the In C you would typically start your program with a call like: #include <locale.h>
int main(int argc, char *argv[]) {
setlocale(LC_CTYPE, "");
} This will try to set the locale to what the native environment Our current behaviour in Python does not adhere to these semantics. To # Obvious non-existing locale
>>> from locale import setlocale, LC_CTYPE
>>> setlocale(LC_CTYPE, 'B')
Error: unsupported locale setting
# Valid locale, but not available on my system
>>> from os import getenv
>>> from locale import setlocale, LC_CTYPE
>>> getenv('LANG')
>>> 'cy_GB.UTF-8'
>>> setlocale(LC_CTYPE, '')
Error: unsupported locale setting Neither Perl or PHP throw any error when setlocale() is passed an As such I think PyLocale_setlocale() in Modules/_localemodule.c needs to >>> from locale import setlocale, LC_CTYPE
>>> rv = setlocale(LC_CTYPE, 'B')
>>> type(rv)
<class 'NoneType'>
>>> rv = setlocale(LC_CTYPE, 'C')
>>> type(rv)
<class 'str'>
>>> rv
'C' |
Still, this is considered as an error case.
Yes, but that's a bug in the C code, which fails to check the
-1. Errors should never pass silently. That's the whole point of exceptions. |
Interestingly, my setlocale(3p) man page says: """ So isn't it debatable if returning the NULL pointer really is an error? |
I asked that as well on the POSIX/SUS list and Don Cragun responded with: "If you make the last argument to setlocale() be a pointer to On the subject whether or not returning a null pointer should be "The standard is silent on this issue. I am just wondering why we want to be quite different from how many |
On the subject whether or not returning a null pointer should be -> On the subject whether or not returning a null pointer should be |
Georg pointed out a mistake I introduced in my patch, updated now. |
Really correct this time. |
As Jeroen reports, this really means two different things |
Because we have exceptions, and they don't. Would you also propose While it may be debatable whether applications care about the error setlocale(locale.LC_ALL, "de_DE@euro") When they do that, they surely want to be told if this actually
There is also the backwards compatibility issue: your change |
On Sun, 3 May 2009 at 08:55, Jeroen Ruigrok van der Werven wrote:
Only if you imagine that the principal applies to expectations inherited |
Committed the initial patch in r72375 for trunk and r72376 for py3k. Any other branches that would need the merge? 3.0? |
It looks like a bug fix to me - so it would apply to all four active |
Committed in r72381 and r72395. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: