Bugs item #1080864, was opened at 2004-12-07 21:23
Message generated for change (Comment added) made by childsplay
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: stas Z (childsplay)
Assigned to: M.-A. Lemburg (lemburg)
Summary: locale.py doesn't recognize valid locale setting
Initial Comment:
[EMAIL PROTECTED]:~$ locale
LANG=nb_NO
[...]
[EMAIL PROTECTED]:~$ python
Python 2.3.4 (#2, Sep 24 2004, 08:39:09)
[GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> locale.getdefaultlocale()
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.3/locale.py", line 346, in
getdefaultlocale
return _parse_localename(localename)
File "/usr/lib/python2.3/locale.py", line 280, in
_parse_localename
raise ValueError, 'unknown locale: %s' % localename
ValueError: unknown locale: nb_NO
>>>
--
>Comment By: stas Z (childsplay)
Date: 2004-12-11 17:18
Message:
Logged In: YES
user_id=638376
I've looked at the CVS/locale.py but is the utf8 entry missing?
Don't know about the X alias mapping, but I suspect that
there should also be an utf8 entry also for nb_NO/nn_NO.
(Just as there is for no_NO)
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-10 22:58
Message:
Logged In: YES
user_id=38388
Checking in Lib/locale.py;
/cvsroot/python/python/dist/src/Lib/locale.py,v <-- locale.py
new revision: 1.29; previous revision: 1.28
done
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-10 14:16
Message:
Logged In: YES
user_id=38388
Well, if the alias mapping is good enough for X, then it's
good enough for me :-)
I think we ought to update the alias table with the current
data of the X locale.alias file. This file also includes the
mappings that childsplay mentioned.
There also seems to be a bug in the encoding alias table:
"utf" is no longer recognized by setlocale(). This should be
changed to "utf8".
I'll fix that and post an update here.
--
Comment By: Martin v. Löwis (loewis)
Date: 2004-12-10 00:26
Message:
Logged In: YES
user_id=21627
getdefaultencoding might be "targeted" at the OS level - but
the implementation certainly is not. On the OS level, the C
library will often use a different encoding after
locale.setlocale(locale.LC_ALL,"") is called, compared to
what getdefaultencoding returns. The approach takien inside
getdefaultencoding is inherently flawed, and cannot possibly
work in all cases; getpreferredencoding fixes that flaw.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-09 10:56
Message:
Logged In: YES
user_id=38388
childsplay (I wish people would use real names on SF...):
We can add the aliases you gave below, but we need some URLs
to add as reference. Please provide this information, so
that we can document that the aliases are in common use and
why iso-8859-1 is their usually used encoding.
Thanks.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-09 10:42
Message:
Logged In: YES
user_id=38388
Martin:
"default" as opposed to whatever locale setting is currently
active for the program, i.e. the locale setting the program
would see after a single call to setlocale(LC_ALL, "") right
after the start of the program.
getdefaultlocale() mimics the lookup mechanism of
setlocale(LC_ALL, "").
The fact that the alias table may sometimes not give the
correct encoding is not a fault of Python or the table - if
the user wants to see a different encoding used as default
encoding for the set locale, then the user should include
that information in the LANG (or other) OS environment
variable of the process running the Python program.
Note that this is different than the "preferred" encoding
which a user can set in a window manager (KDE or Gnome) or
browser. Those settings are restricted to certain
application spaces. getdefaultencoding() is targetted at the
OS level setting which may be different from e.g. a KDE
setting (think a program running in a shell vs. a KDE
application run by a user).
--
Comment By: stas Z (childsplay)
Date: 2004-12-09 10:27
Message:
Logged In: YES
user_id=638376
I agree that "default" would probably be called "preferred".
@loewis:
a)
I agree with your point of view but I as a developer I just
want to get the current locale in use and locale.py serves
that purpose in a platform independant way. The
