[ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting

[SourceForge.net]

Bugs item #1080864, was opened at 2004-12-07 21:23
Message generated for change (Comment added) made by lemburg
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: Open
Resolution: None
Priority: 5
Submitted By: stas Z (childsplay)
Assigned to: Nobody/Anonymous (nobody)
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: M.-A. Lemburg (lemburg)
Date: 2004-12-08 10:05

Message:
Logged In: YES 
user_id=38388

The LANG (and other similar OS environment variables) define
what the user wishes to see being used as locale in the
applications that are started in that environment. See the
setlocale man page for details.

On some OSes such as Windows these settings are stored
differently, which is why the locale module has provisions
for finding these settings (thanks to Fredrik).

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-08 08:04

Message:
Logged In: YES 
user_id=21627

There is no "default locale setting" in most operating
systems. In what sense is the value of the LANG environment
variable a "default"?

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-08 00:08

Message:
Logged In: YES 
user_id=38388

Of course, I don't agree with you, Martin :-)
locale.getdefaultlocale() does server a purpose, namely that
of getting the default locale setting. The encoding
information is an often used extension when setting the
locale in the OS environment. If not set, the module
provides common defaults.

The locale "nb_NO" is not known to the module alias table.
Which locale, language and encoding would that be ?

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-07 23:13

Message:
Logged In: YES 
user_id=21627

To get the default encoding for the current locale, you
should use locale.getpreferredencoding(). You should not use
getdefaultlocale becaus it is (IMO) inherently broken, and
should not have been part of the standard library in the
first place.

--

Comment By: Jarek Zgoda (zgoda)
Date: 2004-12-07 22:39

Message:
Logged In: YES 
user_id=9

getdefaultlocale() is often used to get default encoding for
current system locale.
And, if function is provided in standard library, why
shouldn't one use it?

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-07 21:25

Message:
Logged In: YES 
user_id=21627

Why do you want to use getdefaultlocale()?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting

[SourceForge.net]

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: Open
Resolution: None
Priority: 5
Submitted By: stas Z (childsplay)
Assigned to: Nobody/Anonymous (nobody)
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-08 13:29

Message:
Logged In: YES 
user_id=638376

The reason I use getdefaultlocale(), is to get a platform
independant way of getting the systems locale setting.
The biggest advantage is that on Windows a "Linux like"
locale is returnt so that I can use the same language
support stuff on all
platforms. (Win,Linux,OSX).
Besides, what's the problem of adding the missing locale?

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-08 10:05

Message:
Logged In: YES 
user_id=38388

The LANG (and other similar OS environment variables) define
what the user wishes to see being used as locale in the
applications that are started in that environment. See the
setlocale man page for details.

On some OSes such as Windows these settings are stored
differently, which is why the locale module has provisions
for finding these settings (thanks to Fredrik).

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-08 08:04

Message:
Logged In: YES 
user_id=21627

There is no "default locale setting" in most operating
systems. In what sense is the value of the LANG environment
variable a "default"?

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-08 00:08

Message:
Logged In: YES 
user_id=38388

Of course, I don't agree with you, Martin :-)
locale.getdefaultlocale() does server a purpose, namely that
of getting the default locale setting. The encoding
information is an often used extension when setting the
locale in the OS environment. If not set, the module
provides common defaults.

The locale "nb_NO" is not known to the module alias table.
Which locale, language and encoding would that be ?

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-07 23:13

Message:
Logged In: YES 
user_id=21627

To get the default encoding for the current locale, you
should use locale.getpreferredencoding(). You should not use
getdefaultlocale becaus it is (IMO) inherently broken, and
should not have been part of the standard library in the
first place.

--

Comment By: Jarek Zgoda (zgoda)
Date: 2004-12-07 22:39

Message:
Logged In: YES 
user_id=9

getdefaultlocale() is often used to get default encoding for
current system locale.
And, if function is provided in standard library, why
shouldn't one use it?

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-07 21:25

Message:
Logged In: YES 
user_id=21627

Why do you want to use getdefaultlocale()?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting

[SourceForge.net]

Bugs item #1080864, was opened at 2004-12-07 21:23
Message generated for change (Comment added) made by lemburg
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: Open
Resolution: None
Priority: 5
Submitted By: stas Z (childsplay)
Assigned to: Nobody/Anonymous (nobody)
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: M.-A. Lemburg (lemburg)
Date: 2004-12-08 14:06

Message:
Logged In: YES 
user_id=38388

Please provide some authorative source which describes the
locale your are using (nb_NO) and the commonly used encoding
for that locale (see the existing dictionary in locale.py).

--

Comment By: stas Z (childsplay)
Date: 2004-12-08 13:29

Message:
Logged In: YES 
user_id=638376

The reason I use getdefaultlocale(), is to get a platform
independant way of getting the systems locale setting.
The biggest advantage is that on Windows a "Linux like"
locale is returnt so that I can use the same language
support stuff on all
platforms. (Win,Linux,OSX).
Besides, what's the problem of adding the missing locale?

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-08 10:05

Message:
Logged In: YES 
user_id=38388

The LANG (and other similar OS environment variables) define
what the user wishes to see being used as locale in the
applications that are started in that environment. See the
setlocale man page for details.

On some OSes such as Windows these settings are stored
differently, which is why the locale module has provisions
for finding these settings (thanks to Fredrik).

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-08 08:04

Message:
Logged In: YES 
user_id=21627

There is no "default locale setting" in most operating
systems. In what sense is the value of the LANG environment
variable a "default"?

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-08 00:08

Message:
Logged In: YES 
user_id=38388

Of course, I don't agree with you, Martin :-)
locale.getdefaultlocale() does server a purpose, namely that
of getting the default locale setting. The encoding
information is an often used extension when setting the
locale in the OS environment. If not set, the module
provides common defaults.

The locale "nb_NO" is not known to the module alias table.
Which locale, language and encoding would that be ?

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-07 23:13

Message:
Logged In: YES 
user_id=21627

To get the default encoding for the current locale, you
should use locale.getpreferredencoding(). You should not use
getdefaultlocale becaus it is (IMO) inherently broken, and
should not have been part of the standard library in the
first place.

--

Comment By: Jarek Zgoda (zgoda)
Date: 2004-12-07 22:39

Message:
Logged In: YES 
user_id=9

getdefaultlocale() is often used to get default encoding for
current system locale.
And, if function is provided in standard library, why
shouldn't one use it?

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-07 21:25

Message:
Logged In: YES 
user_id=21627

Why do you want to use getdefaultlocale()?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1081370 ] Bad reference in whrandom docs

[SourceForge.net]

Bugs item #1081370, was opened at 2004-12-08 15:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081370&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Lars Marius Garshol (larsga)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad reference in whrandom docs

Initial Comment:
The third paragraph of the documentation of the whrandom module 
has a sentence saying: "Instances of the whrandom class conform to 
the Random Number Generator interface described in section ." The 
section name/number and link are missing.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081370&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1079545 ] python-2.4.msi install error

[SourceForge.net]

Bugs item #1079545, was opened at 2004-12-05 20:02
Message generated for change (Comment added) made by maharal
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079545&group_id=5470

Category: Installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: maharal (maharal)
Assigned to: Martin v. Löwis (loewis)
Summary: python-2.4.msi install error

Initial Comment:
when I try to install python2.4. using the python-
2.4.msi-file, it stopps with the error message: 
"The installer has encountered an unexpected error 
installing this package. This may inidicate a problem with 
this package. The error code is 2738"



--

>Comment By: maharal (maharal)
Date: 2004-12-08 14:16

Message:
Logged In: YES 
user_id=1171290

Dear Mr. Löwis, 
Your presumption was right: vbscript 5.6 was all that was 
needed to make the installation run! 
Thanks a lot for your help!
Ralf 


--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-06 21:59

Message:
Logged In: YES 
user_id=21627

Can you please try to install VBScript, from

http://msdn.microsoft.com/downloads/list/webdev.asp

and report whether this works?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079545&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting

[SourceForge.net]

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: Open
Resolution: None
Priority: 5
Submitted By: stas Z (childsplay)
Assigned to: Nobody/Anonymous (nobody)
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-08 16:09

Message:
Logged In: YES 
user_id=638376

This is what I've put into /python2.3/locale.py:

locale_alias = {
...
'bokmål':   'nb_NO.ISO8859-1',
'nb': 'nb_NO.ISO8859-1',
'nb_no':'nb_NO.ISO8859-1',
'nynorsk':  'nn_NO.ISO8859-1',
'nn': 'nn_NO.ISO8859-1',
'nn_no':'nn_NO.ISO8859-1',
   
   
}

I have tested it on a number of apps and it fixes the problem.


--

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-08 14:06

Message:
Logged In: YES 
user_id=38388

Please provide some authorative source which describes the
locale your are using (nb_NO) and the commonly used encoding
for that locale (see the existing dictionary in locale.py).

--

Comment By: stas Z (childsplay)
Date: 2004-12-08 13:29

Message:
Logged In: YES 
user_id=638376

The reason I use getdefaultlocale(), is to get a platform
independant way of getting the systems locale setting.
The biggest advantage is that on Windows a "Linux like"
locale is returnt so that I can use the same language
support stuff on all
platforms. (Win,Linux,OSX).
Besides, what's the problem of adding the missing locale?

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-08 10:05

Message:
Logged In: YES 
user_id=38388

The LANG (and other similar OS environment variables) define
what the user wishes to see being used as locale in the
applications that are started in that environment. See the
setlocale man page for details.

On some OSes such as Windows these settings are stored
differently, which is why the locale module has provisions
for finding these settings (thanks to Fredrik).

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-08 08:04

Message:
Logged In: YES 
user_id=21627

There is no "default locale setting" in most operating
systems. In what sense is the value of the LANG environment
variable a "default"?

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-08 00:08

Message:
Logged In: YES 
user_id=38388

Of course, I don't agree with you, Martin :-)
locale.getdefaultlocale() does server a purpose, namely that
of getting the default locale setting. The encoding
information is an often used extension when setting the
locale in the OS environment. If not set, the module
provides common defaults.

The locale "nb_NO" is not known to the module alias table.
Which locale, language and encoding would that be ?

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-07 23:13

Message:
Logged In: YES 
user_id=21627

To get the default encoding for the current locale, you
should use locale.getpreferredencoding(). You should not use
getdefaultlocale becaus it is (IMO) inherently broken, and
should not have been part of the standard library in the
first place.

--

Comment By: Jarek Zgoda (zgoda)
Date: 2004-12-07 22:39

Message:
Logged In: YES 
user_id=9

getdefaultlocale() is often used to get default encoding for
current system locale.
And, if function is provided in standard library, why
shouldn't one use it?

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-07 21:25

Message:
Logged In: YES 
user_id=21627

Why do you want to use getdefaultlocale()?

[ python-Bugs-1080634 ] PythonWin Tray Icon in system Tray on Windows platform

[SourceForge.net]

Bugs item #1080634, was opened at 2004-12-07 20:56
Message generated for change (Comment added) made by dileep_nirala
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080634&group_id=5470

Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dileep Nirala (dileep_nirala)
Assigned to: Nobody/Anonymous (nobody)
>Summary: PythonWin Tray Icon in system Tray on Windows platform

Initial Comment:
The python icon remains in the system Tray even if 
you close the application.

--

>Comment By: Dileep Nirala (dileep_nirala)
Date: 2004-12-08 22:31

Message:
Logged In: YES 
user_id=1173293

PythonWin tray icons remains in the system tray once you 
close the application for Python-2.4.0-243 build on Windows 
platform. If you hover the mouse then only it goes off. If you 
open and close PythonWin application 10 times, you will see 
10 tray icons. Any probable date, when this could get 
resolved. 

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080634&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1081633 ] LDAP search segfaults on RedHat FC3

[SourceForge.net]

Bugs item #1081633, was opened at 2004-12-08 13:23
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081633&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tessa Lau (tlau)
Assigned to: Nobody/Anonymous (nobody)
Summary: LDAP search segfaults on RedHat FC3

Initial Comment:
Doing an LDAP search against one of our intranet LDAP
servers results in a segmentation fault with Python
2.3.4 on Fedora Core 3.  Here is a 2-line test case:

server = ldap.initialize(URL)
results = server.search_st(BASE, ldap.SCOPE_ONELEVEL,
'([EMAIL PROTECTED])',
['cn', 'email'])

The gdb backtrace is attached.

If I run the same code on a different system (Debian,
Python 2.3.4, OpenLDAP 2.1.30), instead of a segfault I
see an LDAP error:

ldap.NO_RESULTS_RETURNED: {'info': '', 'desc': 'No
results returned'}

Based on the backtrace, I think the FC3 system is not
handling that error correctly.

Python version information:

Python 2.3.4 (#1, Oct 26 2004, 16:42:40) 
[GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2

Python and LDAP RPMs installed:

python-2.3.4-11
nss_ldap-220-3
python-ldap-2.0.1-2
openldap-2.2.13-2
openldap-devel-2.2.13-2
openldap-clients-2.2.13-2
openldap-servers-2.2.13-2

uname -a:
Linux xxx.yyy.net 2.6.9-1.681_FC3.WKD_tr_mts_1 #1 Tue
Nov 23 22:35:54 EST 2004 i686 athlon i386 GNU/Linux

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081633&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting

[SourceForge.net]

Bugs item #1080864, was opened at 2004-12-07 21:23
Message generated for change (Comment added) made by loewis
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: Open
Resolution: None
Priority: 5
Submitted By: stas Z (childsplay)
Assigned to: Nobody/Anonymous (nobody)
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: Martin v. Löwis (loewis)
Date: 2004-12-08 22:28

Message:
Logged In: YES 
user_id=21627

MAL: that doesn't answer my question, though: In what sense
does getdefaultlocale get a "default" locale? default as
opposed to what custom setting?

childsplay: the problem with adding additional aliases is
a) we can never hope to get a complete list of locales, so
this is a never-ending maintenance problem, and
b) the dictionary might be wrong on some systems. E.g.
sometimes, 'nb' might denote an ISO-8859-15 locale,  or a
UTF-8 locale (e.g. when UTF-8 becomes the standard encoding
on Unix some day). If so, Python will silently compute an
incorrect default - in particular wrt. the encoding of the
"default" locale.


--

Comment By: stas Z (childsplay)
Date: 2004-12-08 16:09

Message:
Logged In: YES 
user_id=638376

This is what I've put into /python2.3/locale.py:

locale_alias = {
...
'bokmål':   'nb_NO.ISO8859-1',
'nb': 'nb_NO.ISO8859-1',
'nb_no':'nb_NO.ISO8859-1',
'nynorsk':  'nn_NO.ISO8859-1',
'nn': 'nn_NO.ISO8859-1',
'nn_no':'nn_NO.ISO8859-1',
   
   
}

I have tested it on a number of apps and it fixes the problem.


--

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-08 14:06

Message:
Logged In: YES 
user_id=38388

Please provide some authorative source which describes the
locale your are using (nb_NO) and the commonly used encoding
for that locale (see the existing dictionary in locale.py).

--

Comment By: stas Z (childsplay)
Date: 2004-12-08 13:29

Message:
Logged In: YES 
user_id=638376

The reason I use getdefaultlocale(), is to get a platform
independant way of getting the systems locale setting.
The biggest advantage is that on Windows a "Linux like"
locale is returnt so that I can use the same language
support stuff on all
platforms. (Win,Linux,OSX).
Besides, what's the problem of adding the missing locale?

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-08 10:05

Message:
Logged In: YES 
user_id=38388

The LANG (and other similar OS environment variables) define
what the user wishes to see being used as locale in the
applications that are started in that environment. See the
setlocale man page for details.

On some OSes such as Windows these settings are stored
differently, which is why the locale module has provisions
for finding these settings (thanks to Fredrik).

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-08 08:04

Message:
Logged In: YES 
user_id=21627

There is no "default locale setting" in most operating
systems. In what sense is the value of the LANG environment
variable a "default"?

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-08 00:08

Message:
Logged In: YES 
user_id=38388

Of course, I don't agree with you, Martin :-)
locale.getdefaultlocale() does server a purpose, namely that
of getting the default locale setting. The encoding
information is an often used extension when setting the
locale in the OS environment. If not set, the module
provides common defaults.

The locale "nb_NO" is not known to the module alias table.
Which locale, language and encoding would that be ?

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-07 23:13

Message:
Logged In: YES 
user_id=21627

To get the default enco

[ python-Bugs-1081633 ] LDAP search segfaults on RedHat FC3

[SourceForge.net]

Bugs item #1081633, was opened at 2004-12-08 22:23
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081633&group_id=5470

Category: Extension Modules
>Group: 3rd Party
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Tessa Lau (tlau)
Assigned to: Nobody/Anonymous (nobody)
Summary: LDAP search segfaults on RedHat FC3

Initial Comment:
Doing an LDAP search against one of our intranet LDAP
servers results in a segmentation fault with Python
2.3.4 on Fedora Core 3.  Here is a 2-line test case:

server = ldap.initialize(URL)
results = server.search_st(BASE, ldap.SCOPE_ONELEVEL,
'([EMAIL PROTECTED])',
['cn', 'email'])

The gdb backtrace is attached.

If I run the same code on a different system (Debian,
Python 2.3.4, OpenLDAP 2.1.30), instead of a segfault I
see an LDAP error:

ldap.NO_RESULTS_RETURNED: {'info': '', 'desc': 'No
results returned'}

Based on the backtrace, I think the FC3 system is not
handling that error correctly.

Python version information:

Python 2.3.4 (#1, Oct 26 2004, 16:42:40) 
[GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2

Python and LDAP RPMs installed:

python-2.3.4-11
nss_ldap-220-3
python-ldap-2.0.1-2
openldap-2.2.13-2
openldap-devel-2.2.13-2
openldap-clients-2.2.13-2
openldap-servers-2.2.13-2

uname -a:
Linux xxx.yyy.net 2.6.9-1.681_FC3.WKD_tr_mts_1 #1 Tue
Nov 23 22:35:54 EST 2004 i686 athlon i386 GNU/Linux

--

>Comment By: Martin v. Löwis (loewis)
Date: 2004-12-08 22:30

Message:
Logged In: YES 
user_id=21627

python-ldap is not part of the Python project; please report
this bug to http://python-ldap.sourceforge.net/

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081633&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Feature Requests-1075902 ] ignore element format character for PyArg_ParseTuple

[SourceForge.net]

Feature Requests item #1075902, was opened at 2004-11-30 11:28
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1075902&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sean Proctor (sproctor)
Assigned to: Nobody/Anonymous (nobody)
Summary: ignore element format character for PyArg_ParseTuple

Initial Comment:
Some kind of option to indicate there is an element,
but we don't care about its value would be nice. It
could be _. then an example would be:
PyArg_ParseTuple (tuple, "_i", &my_int);

This indicates that there is another value before the
int, but we don't care about it one way or the other.

--

>Comment By: Martin v. Löwis (loewis)
Date: 2004-12-08 22:42

Message:
Logged In: YES 
user_id=21627

What's wrong with using O as the format character?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1075902&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1079545 ] python-2.4.msi install error

[SourceForge.net]

Bugs item #1079545, was opened at 2004-12-05 21:02
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079545&group_id=5470

Category: Installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: maharal (maharal)
Assigned to: Martin v. Löwis (loewis)
Summary: python-2.4.msi install error

Initial Comment:
when I try to install python2.4. using the python-
2.4.msi-file, it stopps with the error message: 
"The installer has encountered an unexpected error 
installing this package. This may inidicate a problem with 
this package. The error code is 2738"



--

>Comment By: Martin v. Löwis (loewis)
Date: 2004-12-08 23:12

Message:
Logged In: YES 
user_id=21627

Ok, I have added an entry into

http://www.python.org/2.4/bugs.html

For 2.4.1, I will try to do without VB.

--

Comment By: maharal (maharal)
Date: 2004-12-08 15:16

Message:
Logged In: YES 
user_id=1171290

Dear Mr. Löwis, 
Your presumption was right: vbscript 5.6 was all that was 
needed to make the installation run! 
Thanks a lot for your help!
Ralf 


--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-06 22:59

Message:
Logged In: YES 
user_id=21627

Can you please try to install VBScript, from

http://msdn.microsoft.com/downloads/list/webdev.asp

and report whether this works?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079545&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1076861 ] Bad IDLE shortcut by 2.4 installer on XP

[SourceForge.net]

Bugs item #1076861, was opened at 2004-12-01 17:28
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076861&group_id=5470

Category: Installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jean M. Brouwers (jbrouwers)
Assigned to: Martin v. Löwis (loewis)
Summary: Bad IDLE shortcut by 2.4 installer on XP

Initial Comment:
There is a problem with the Python 2.4 installer on
Windows XP.

The IDLE shortcut set up by the installer in the
StartUp folder does not work.  If the shortcut is
removed and recreated manually, it works fine.

That was *after* a complete reinstall of Python 2.4 and
after removing the previous version of Python 2.3 on
the machine.  With Python 2.3 present, the IDLE
shortcut installed by Python 2.4 runs the 2.3 version.

See also



and




--

>Comment By: Martin v. Löwis (loewis)
Date: 2004-12-08 23:13

Message:
Logged In: YES 
user_id=21627

I've added an entry to

http://www.python.org/2.4/bugs.html

now and hope to fix the problem for 2.4.1.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076861&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1076861 ] Bad IDLE shortcut by 2.4 installer on XP

[SourceForge.net]

Bugs item #1076861, was opened at 2004-12-01 10:28
Message generated for change (Comment added) made by jbrouwers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076861&group_id=5470

Category: Installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jean M. Brouwers (jbrouwers)
Assigned to: Martin v. Löwis (loewis)
Summary: Bad IDLE shortcut by 2.4 installer on XP

Initial Comment:
There is a problem with the Python 2.4 installer on
Windows XP.

The IDLE shortcut set up by the installer in the
StartUp folder does not work.  If the shortcut is
removed and recreated manually, it works fine.

That was *after* a complete reinstall of Python 2.4 and
after removing the previous version of Python 2.3 on
the machine.  With Python 2.3 present, the IDLE
shortcut installed by Python 2.4 runs the 2.3 version.

See also



and




--

>Comment By: Jean M. Brouwers (jbrouwers)
Date: 2004-12-08 19:16

Message:
Logged In: YES 
user_id=832557

One more piece of data.  We installed Python 2.4 in
directory "C:\Program Files\Python24".  Maybe the space in
the name is causing the problem.

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-08 16:13

Message:
Logged In: YES 
user_id=21627

I've added an entry to

http://www.python.org/2.4/bugs.html

now and hope to fix the problem for 2.4.1.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076861&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1081824 ] Rewrite of docs for compiler.visitor

[SourceForge.net]

Bugs item #1081824, was opened at 2004-12-09 02:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081824&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Kent Johnson (kjohnson)
Assigned to: Nobody/Anonymous (nobody)
Summary: Rewrite of docs for compiler.visitor

Initial Comment:
I was recently prompted to look at the docs for
compiler.visitor (Lib Ref 19.4 Using Visitors to Walk
ASTs). With all due respect it is not up to the
standards of most of the docs. I have attempted a
rewrite which is in the attachment.

I suggest also that the entry for walk() on the main
compiler doc page (19.1) should be updated to refer to
19.4 for details.

HTH
Kent

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081824&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Feature Requests-1075902 ] ignore element format character for PyArg_ParseTuple

[SourceForge.net]

Feature Requests item #1075902, was opened at 2004-11-30 05:28
Message generated for change (Comment added) made by sproctor
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1075902&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sean Proctor (sproctor)
Assigned to: Nobody/Anonymous (nobody)
Summary: ignore element format character for PyArg_ParseTuple

Initial Comment:
Some kind of option to indicate there is an element,
but we don't care about its value would be nice. It
could be _. then an example would be:
PyArg_ParseTuple (tuple, "_i", &my_int);

This indicates that there is another value before the
int, but we don't care about it one way or the other.

--

>Comment By: Sean Proctor (sproctor)
Date: 2004-12-08 22:35

Message:
Logged In: YES 
user_id=43755

If I use O, then I need to have a variable to store it in. I
think it's less readable. Like with pattern matching in ML,
you can use a variable instead of _, but it's not obvious
that you aren't going to use that value. With some kind of
place holder, this is made clear, and I don't need to create
a variable to store a value that I don't care about.

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-08 16:42

Message:
Logged In: YES 
user_id=21627

What's wrong with using O as the format character?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1075902&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Feature Requests-1075902 ] ignore element format character for PyArg_ParseTuple

[SourceForge.net]

Feature Requests item #1075902, was opened at 2004-11-30 05:28
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1075902&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sean Proctor (sproctor)
Assigned to: Nobody/Anonymous (nobody)
Summary: ignore element format character for PyArg_ParseTuple

Initial Comment:
Some kind of option to indicate there is an element,
but we don't care about its value would be nice. It
could be _. then an example would be:
PyArg_ParseTuple (tuple, "_i", &my_int);

This indicates that there is another value before the
int, but we don't care about it one way or the other.

--

>Comment By: Tim Peters (tim_one)
Date: 2004-12-09 00:04

Message:
Logged In: YES 
user_id=31435

If you want to make C code look like ML, declare

PyObject** _;

and use _ in the argument list.

I'm -1 on this:  the case has almost never arisen in my 
experience, and the limited pool of format characters should 
be preserved for high-value uses.

--

Comment By: Sean Proctor (sproctor)
Date: 2004-12-08 22:35

Message:
Logged In: YES 
user_id=43755

If I use O, then I need to have a variable to store it in. I
think it's less readable. Like with pattern matching in ML,
you can use a variable instead of _, but it's not obvious
that you aren't going to use that value. With some kind of
place holder, this is made clear, and I don't need to create
a variable to store a value that I don't care about.

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-08 16:42

Message:
Logged In: YES 
user_id=21627

What's wrong with using O as the format character?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1075902&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1081879 ] Pydoc can't find browser (bug+solution!)

[SourceForge.net]

Bugs item #1081879, was opened at 2004-12-08 22:14
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081879&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Stewart Midwinter (midtoad)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pydoc can't find browser (bug+solution!)

Initial Comment:
I've got Python 2.3 installed on Mandrake Linux 10.1 with 
KDE 3.2 running.  When I run "pydoc -g" and search on 
any term, if I try to display the relevant documentation, 
pydoc throws an exception: 
 
Traceback (most recent call last): 
  File "/usr/lib/python2.3/lib-tk/Tkinter.py", line 1345, in 
__call__ 
return self.func(*args) 
  File "/usr/lib/python2.3/pydoc.py", line 1970, in open 
webbrowser.open(url) 
  File "/usr/lib/python2.3/webbrowser.py", line 43, in 
open 
get().open(url, new, autoraise) 
  File "/usr/lib/python2.3/webbrowser.py", line 38, in get 
raise Error("could not locate runnable browser") 
Error: could not locate runnable browser 
 
I did some research and found that the problem is that 
KDE sets the BROWSER environment variable to an 
unexpected value: 
BROWSER='kfmclient openProfile webbrowsing' 
 
The solution would be to test for this strange setting. I 
patched webbrowser.py on my system in an inelegant 
fashion by simply inserting the following code at the top 
of the file, just after the 'import' statements: 
 
#patch for KDE mangling of BROWSER environment 
variable 
#per: 
http://mail.python.org/pipermail/tutor/2004-September/032060.html 
 
if os.environ.has_key("BROWSER") and \ 
   os.environ["BROWSER"]=='kfmclient openProfile 
webbrowsing': 
os.environ["BROWSER"] = 'konqueror' # set it to 
konqueror 
 
 
 

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081879&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Feature Requests-1075902 ] ignore element format character for PyArg_ParseTuple

[SourceForge.net]

Feature Requests item #1075902, was opened at 2004-11-30 05:28
Message generated for change (Comment added) made by sproctor
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1075902&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sean Proctor (sproctor)
Assigned to: Nobody/Anonymous (nobody)
Summary: ignore element format character for PyArg_ParseTuple

Initial Comment:
Some kind of option to indicate there is an element,
but we don't care about its value would be nice. It
could be _. then an example would be:
PyArg_ParseTuple (tuple, "_i", &my_int);

This indicates that there is another value before the
int, but we don't care about it one way or the other.

--

>Comment By: Sean Proctor (sproctor)
Date: 2004-12-09 00:37

Message:
Logged In: YES 
user_id=43755

that would turn my example into PyArg_ParseTuple (tuple,
"Oi", _, &my_int);

I don't particularly care. I thought it was a good
suggestion. To me _ looks like a blank. I wouldn't really
want to use it in a format string for something besides an
any/none scenario. Your reasoning about preserving format
characters seems really weak.

You've never had a tuple where you didn't care about the
value of each element?

Somewhat separate topic. Could you say "PyArg_ParseTuple
(tuple, "Oi", NULL, &my_int);" ? I guess that would be a
less elegant way of doing what I intended.

--

Comment By: Tim Peters (tim_one)
Date: 2004-12-09 00:04

Message:
Logged In: YES 
user_id=31435

If you want to make C code look like ML, declare

PyObject** _;

and use _ in the argument list.

I'm -1 on this:  the case has almost never arisen in my 
experience, and the limited pool of format characters should 
be preserved for high-value uses.

--

Comment By: Sean Proctor (sproctor)
Date: 2004-12-08 22:35

Message:
Logged In: YES 
user_id=43755

If I use O, then I need to have a variable to store it in. I
think it's less readable. Like with pattern matching in ML,
you can use a variable instead of _, but it's not obvious
that you aren't going to use that value. With some kind of
place holder, this is made clear, and I don't need to create
a variable to store a value that I don't care about.

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-08 16:42

Message:
Logged In: YES 
user_id=21627

What's wrong with using O as the format character?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1075902&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com