[ python-Bugs-1080811 ] full test with all unicode text files
Bugs item #1080811, was opened at 2004-12-07 19:53 Message generated for change (Comment added) made by makaron You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080811&group_id=5470 Category: None Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: full test with all unicode text files Initial Comment: samall bug? while performing full test on pythonthon core with all required files (unicode). This can be found when "python -u regrtest.py -uall" is executed - perhaps some encodings are not preserved - test_codecmaps_kr fails with message: "JOHAB.TXT not found, download from http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/KSC/JOHAB.TXT " this file exists on my system and is placed in lib/test, as required. when its running as standalone test everything is OK. -- >Comment By: Grzegorz Makarewicz (makaron) Date: 2004-12-10 09:54 Message: Logged In: YES user_id=115179 my system is windows 2000 pro sp4 with latest fixes from ms, polish language, python from cvs (head), msvc 7.1 -- Comment By: Walter Dörwald (doerwalter) Date: 2004-12-09 20:06 Message: Logged In: YES user_id=89016 I can't reproduce this on Linux. Putting JOHAB.TXT (and the other files) into the current directory (dist from a CVS checkout) and running "python Lib/test/regrtest.py" works. Putting all the files into Lib/test and running regrtest.py from there works too. Which version of Python are you using? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080811&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1082944 ] Documentation for PyUnicode_TailMatch incorrrectly says it r
Bugs item #1082944, was opened at 2004-12-10 14:38 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=1082944&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Fulton (dcjim) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation for PyUnicode_TailMatch incorrrectly says it r Initial Comment: nuf said ;) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082944&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1082944 ] Documentation for PyUnicode_TailMatch incorrrectly says it r
Bugs item #1082944, was opened at 2004-12-10 09:38 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082944&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Fulton (dcjim) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation for PyUnicode_TailMatch incorrrectly says it r Initial Comment: nuf said ;) -- >Comment By: Tim Peters (tim_one) Date: 2004-12-10 10:53 Message: Logged In: YES user_id=31435 Umm, no, you typed so much into the Summary box that it got truncated. It ends with "incorrectly says it r". I assume "r" started as "returns", but that's where my telepathy stalls . -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082944&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1082944 ] Documentation for PyUnicode_TailMatch incorrrectly says it r
Bugs item #1082944, was opened at 2004-12-10 14:38 Message generated for change (Comment added) made by dcjim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082944&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Fulton (dcjim) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation for PyUnicode_TailMatch incorrrectly says it r Initial Comment: nuf said ;) -- >Comment By: Jim Fulton (dcjim) Date: 2004-12-10 16:44 Message: Logged In: YES user_id=73023 Crap. SourceForge accepted a long title and then truncated it. :( The Documentation for PyUnicode_TailMatch incorrrectly says it returns a PyObject pointer, which is incorrect. It returns an int. (It doesn't mention error returns. I assume that, in absense of any statement, a return value of -1 indicates an error, as is standard.) -- Comment By: Tim Peters (tim_one) Date: 2004-12-10 15:53 Message: Logged In: YES user_id=31435 Umm, no, you typed so much into the Summary box that it got truncated. It ends with "incorrectly says it r". I assume "r" started as "returns", but that's where my telepathy stalls . -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082944&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI
Bugs item #1075984, was opened at 2004-11-30 13:13
Message generated for change (Comment added) made by kerofin
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470
Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Maik Hertha (mhertha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory fault pyexpat.so on SGI
Initial Comment:
I build the latest RC1 of python 2.4.
System SGI Fuel IP35, Irix 6.5.26m
cc -version
MIPSpro Compilers: Version 7.3.1.3m
- make tests passes test_pyexpat without error
- running this code leads to a core dump
-- code ---
import xml.dom.minidom
doc = xml.dom.minidom.parseString(fstream)
<<< core dump >>>
--- runing python -v test.py
#
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
matches
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py
import xml.dom.expatbuilder # precompiled from
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
import xml.parsers # directory
/opt/python24c1/lib/python2.4/xml/parsers
#
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
matches
/opt/python24c1/lib/python2.4/xml/parsers/__init__.py
import xml.parsers # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
# /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py
import xml.parsers.expat # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so",
2);
Memory fault(coredump)
- running this code from an interactive session leads
not to a coredump
I need some assistance howto provide further debug
information.
--maik./
--
Comment By: Stephen Watson (kerofin)
Date: 2004-12-10 16:46
Message:
Logged In: YES
user_id=471223
I also got a core dump importing pyexpat on Solaris (SPARC)
and somebody else reported it on a *BSD system.
It appears to be a problem with older versions of expat not
being tested for. I used gdb to trace it down to line 1972
in pyexpat.c where it attempts to define the first constant
from 1.95.8. I had expat 1.95.7. After upgrading to 1.95.8
it worked fine, as did the *BSD system.
I think Python needs to check the expat version, as it does
elsewhere in the file, before defining those constants.
I am still puzzelled over how it managed to compile
pyexpat.c in the first place...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI
Bugs item #1075984, was opened at 2004-11-30 13:13
Message generated for change (Comment added) made by mwh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470
Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Maik Hertha (mhertha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory fault pyexpat.so on SGI
Initial Comment:
I build the latest RC1 of python 2.4.
System SGI Fuel IP35, Irix 6.5.26m
cc -version
MIPSpro Compilers: Version 7.3.1.3m
- make tests passes test_pyexpat without error
- running this code leads to a core dump
-- code ---
import xml.dom.minidom
doc = xml.dom.minidom.parseString(fstream)
<<< core dump >>>
--- runing python -v test.py
#
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
matches
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py
import xml.dom.expatbuilder # precompiled from
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
import xml.parsers # directory
/opt/python24c1/lib/python2.4/xml/parsers
#
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
matches
/opt/python24c1/lib/python2.4/xml/parsers/__init__.py
import xml.parsers # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
# /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py
import xml.parsers.expat # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so",
2);
Memory fault(coredump)
- running this code from an interactive session leads
not to a coredump
I need some assistance howto provide further debug
information.
--maik./
--
>Comment By: Michael Hudson (mwh)
Date: 2004-12-10 16:52
Message:
Logged In: YES
user_id=6656
Uh, Python includes its own copy of expat, and I really
thought we were supposed to prefer our own version over
anything found on the system...
--
Comment By: Stephen Watson (kerofin)
Date: 2004-12-10 16:46
Message:
Logged In: YES
user_id=471223
I also got a core dump importing pyexpat on Solaris (SPARC)
and somebody else reported it on a *BSD system.
It appears to be a problem with older versions of expat not
being tested for. I used gdb to trace it down to line 1972
in pyexpat.c where it attempts to define the first constant
from 1.95.8. I had expat 1.95.7. After upgrading to 1.95.8
it worked fine, as did the *BSD system.
I think Python needs to check the expat version, as it does
elsewhere in the file, before defining those constants.
I am still puzzelled over how it managed to compile
pyexpat.c in the first place...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI
Bugs item #1075984, was opened at 2004-11-30 13:13
Message generated for change (Comment added) made by kerofin
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470
Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Maik Hertha (mhertha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory fault pyexpat.so on SGI
Initial Comment:
I build the latest RC1 of python 2.4.
System SGI Fuel IP35, Irix 6.5.26m
cc -version
MIPSpro Compilers: Version 7.3.1.3m
- make tests passes test_pyexpat without error
- running this code leads to a core dump
-- code ---
import xml.dom.minidom
doc = xml.dom.minidom.parseString(fstream)
<<< core dump >>>
--- runing python -v test.py
#
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
matches
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py
import xml.dom.expatbuilder # precompiled from
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
import xml.parsers # directory
/opt/python24c1/lib/python2.4/xml/parsers
#
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
matches
/opt/python24c1/lib/python2.4/xml/parsers/__init__.py
import xml.parsers # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
# /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py
import xml.parsers.expat # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so",
2);
Memory fault(coredump)
- running this code from an interactive session leads
not to a coredump
I need some assistance howto provide further debug
information.
--maik./
--
Comment By: Stephen Watson (kerofin)
Date: 2004-12-10 17:01
Message:
Logged In: YES
user_id=471223
Maybe it compiled against its own copy of expat, but pulled
in the system's copy when run?
--
Comment By: Michael Hudson (mwh)
Date: 2004-12-10 16:52
Message:
Logged In: YES
user_id=6656
Uh, Python includes its own copy of expat, and I really
thought we were supposed to prefer our own version over
anything found on the system...
--
Comment By: Stephen Watson (kerofin)
Date: 2004-12-10 16:46
Message:
Logged In: YES
user_id=471223
I also got a core dump importing pyexpat on Solaris (SPARC)
and somebody else reported it on a *BSD system.
It appears to be a problem with older versions of expat not
being tested for. I used gdb to trace it down to line 1972
in pyexpat.c where it attempts to define the first constant
from 1.95.8. I had expat 1.95.7. After upgrading to 1.95.8
it worked fine, as did the *BSD system.
I think Python needs to check the expat version, as it does
elsewhere in the file, before defining those constants.
I am still puzzelled over how it managed to compile
pyexpat.c in the first place...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&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
Bugs item #1081370, was opened at 2004-12-08 09:01 Message generated for change (Comment added) made by rhettinger 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: Closed >Resolution: Fixed 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. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 12:24 Message: Logged In: YES user_id=80475 Fixed. See Doc/lib/libwhrandom.tex 1.15.30.1 Thanks for the report. -- 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-1079011 ] Incorrect error message (somewhat)
Bugs item #1079011, was opened at 2004-12-04 14:44 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079011&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect error message (somewhat) Initial Comment: Comparing complex numbers with cmp yields: >>> cmp(1+3j, 1+3j) 0 >>> cmp(1+3j, 3+4j) Traceback (most recent call last): File "", line 1, in ? TypeError: cannot compare complex numbers using <, <=, >, >= Well, I didn't use <, <=, > or >=. It's not a major bug, but it doesn't look too nice... would it be possible to return NotImplemented? Or would that be semantically incorrect? -- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 12:31 Message: Logged In: YES user_id=80475 That is incorrect be == and != are implemented. The message is slightly weird but still helpful. Any rewording I can think of makes the message more obtuse, so I recommend leaving it alone and closing this bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079011&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080660 ] thread.error: release unlocked lock on Queue put
Bugs item #1080660, was opened at 2004-12-07 09:48 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080660&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Speno (corvus) >Assigned to: Tim Peters (tim_one) Summary: thread.error: release unlocked lock on Queue put Initial Comment: System is Python 2.3.3 on Solaris 9. I'm using the classic Python thread model. Main thread puts stuff into a Queue.Queue() and worker threads get stuff out of it and do their thing. On occaision, I get an exception in the main thread when it tries to put something into the Queue. File "/usr/local/bin/poller.py", line 47, in fragnap_it work_queue.put((foo, bar, baz)) File "/usr/local/lib/python2.3/Queue.py", line 106, in put self.fsema.release() thread.error: release unlocked lock This error still happens intermittently, and I haven't been able to reduce it to a simple case. I can alter my applications to do something useful for debugging this problem when it happens, if you can figure out what "something useful" would be. Just let me know. The queue is unbounded, and I'm using blocking get/put. The main thread creates 20 worker threads, and 1 recorder thread. Then it puts upto 1500 items in the Queue.Queue named work_queue. The 20 worker threads take stuff out work_queue, process some using pure python code, or others by using subprocess.py. Results from the workers are put into another Queue.Queue named results_queue. The Recorder thread gets from the results_queue and writes stuff to a MySQL db. I've never seen the error happen when putting into the results_queue, only from the main thread putting into the work_queue. Thread defines in my python config.h are: #define HAVE_PTHREAD_H 1 #define HAVE_PTHREAD_SIGMASK 1 #define HAVE_THREAD_H 1 #define PTHREAD_SYSTEM_SCHED_SUPPORTED 1 #define SIZEOF_PTHREAD_T 4 #define WITH_THREAD 1 And all the thread related python tests (test_thread, test_threading, and test_queue) pass. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 12:35 Message: Logged In: YES user_id=80475 Tim, was this something you already fixed in Py2.4? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080660&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080660 ] thread.error: release unlocked lock on Queue put
Bugs item #1080660, was opened at 2004-12-07 09:48 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080660&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Speno (corvus) >Assigned to: Nobody/Anonymous (nobody) Summary: thread.error: release unlocked lock on Queue put Initial Comment: System is Python 2.3.3 on Solaris 9. I'm using the classic Python thread model. Main thread puts stuff into a Queue.Queue() and worker threads get stuff out of it and do their thing. On occaision, I get an exception in the main thread when it tries to put something into the Queue. File "/usr/local/bin/poller.py", line 47, in fragnap_it work_queue.put((foo, bar, baz)) File "/usr/local/lib/python2.3/Queue.py", line 106, in put self.fsema.release() thread.error: release unlocked lock This error still happens intermittently, and I haven't been able to reduce it to a simple case. I can alter my applications to do something useful for debugging this problem when it happens, if you can figure out what "something useful" would be. Just let me know. The queue is unbounded, and I'm using blocking get/put. The main thread creates 20 worker threads, and 1 recorder thread. Then it puts upto 1500 items in the Queue.Queue named work_queue. The 20 worker threads take stuff out work_queue, process some using pure python code, or others by using subprocess.py. Results from the workers are put into another Queue.Queue named results_queue. The Recorder thread gets from the results_queue and writes stuff to a MySQL db. I've never seen the error happen when putting into the results_queue, only from the main thread putting into the work_queue. Thread defines in my python config.h are: #define HAVE_PTHREAD_H 1 #define HAVE_PTHREAD_SIGMASK 1 #define HAVE_THREAD_H 1 #define PTHREAD_SYSTEM_SCHED_SUPPORTED 1 #define SIZEOF_PTHREAD_T 4 #define WITH_THREAD 1 And all the thread related python tests (test_thread, test_threading, and test_queue) pass. -- >Comment By: Tim Peters (tim_one) Date: 2004-12-10 12:45 Message: Logged In: YES user_id=31435 No, and there are no known bugs in Queue in 2.3.j. If John can't whittle it down to a test case that fails for others, I expect this bug is hopeless. We talked about it on c.l.py, and what he's seeing should be impossible. Presuming it's a Solaris-specific bug. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 12:35 Message: Logged In: YES user_id=80475 Tim, was this something you already fixed in Py2.4? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080660&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1081045 ] readline module doesn't build on MacOSX
Bugs item #1081045, was opened at 2004-12-07 18:19 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081045&group_id=5470 Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Brett Cannon (bcannon) Summary: readline module doesn't build on MacOSX Initial Comment: Recent changes to either configure or setup.py seem to have conspired to prevent the readline module from building on MacOSX. I configured and built with LDFLAGS='-L/sw/lib' CPPFLAGS='-I/sw/include' ../ configure '--prefix=/Users/skip/local' make The relevant readline bits are in /sw/... but the module is not built. The following bits containing /sw grep out of the generated Makefile: INSTALL=/sw/bin/install -c CPPFLAGS= -I. -I$(srcdir)/Include -I/sw/include LDFLAGS=-L/sw/lib CONFIG_ARGS='--prefix=/Users/skip/local' 'CPPFLAGS=-I/sw/include' 'LDFLAGS=-L/sw/lib' Assigning to Brett since he touched this most recently. Skip -- >Comment By: Brett Cannon (bcannon) Date: 2004-12-10 11:44 Message: Logged In: YES user_id=357491 I have uploaded a patch to add some debugging output. Can you run make and let me know what it outputs (might need to touch a file to trigger the need for setup.py to execute)? I need to know exactly what the environment variables are set to when they are parsed and what setup.py ends up with for its library and include directories. -- Comment By: Skip Montanaro (montanaro) Date: 2004-12-07 18:46 Message: Logged In: YES user_id=44345 More on this... Sticking a print of lib_dirs just before setup.py checks for readline shows that /sw/lib is not in that list. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081045&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1083110 ] truncated gzip file triggers zlibmodule segfault
Bugs item #1083110, was opened at 2004-12-10 10:54
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=1083110&group_id=5470
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Sam Rushing (rushing)
Assigned to: Nobody/Anonymous (nobody)
Summary: truncated gzip file triggers zlibmodule segfault
Initial Comment:
If gzip.py reads a mangled/truncated file and leaves
the file pointer at EOF, the zlibmodule will crash when
it calls 'flush' (PyZlib_unflush()). I've traced through
zlib a bit, and I think the problem is that the 'avail_in'
slot of the decompression struct is left uninitialized.
The problem can be made to go away by setting that
slot to zero in either PyZlib_decompressobj(), or in
PyZlib_unflush() itself. However, I'm not familiar enough
with the code to know if there's some other reason
the slot contains garbage.
Reproduction:
>>> open ('x.gz', 'wb').write
('\x1f\x8b\x08\x08b\xee\xb9A\x00\x03x\x00')
>>> import gzip
>>> gzip.GzipFile ('x.gz', 'rb').read()
Segmentation fault (core dumped)
[the above data is simply a small gzip file truncated
after the zero-terminated filename]
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083110&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1083177 ] Change in signal function in the signal module
Bugs item #1083177, was opened at 2004-12-10 13:58 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=1083177&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gary H. Loechelt (loechelt) Assigned to: Nobody/Anonymous (nobody) Summary: Change in signal function in the signal module Initial Comment: The signal function of the signal module handles arguments differently in Python 2.4 than in Python 2.3. I am running on an HP-UX 11 workstation. If I set a handler for a signal that cannot be trapped, like KILL (signal 9), the signal function accepts the argument in Python 2.3 but ignores the operation. However, if I do the same thing in Python 2.4, the signal function rejects the argument and raises a RuntimeError. I am not sure if this change in behavior is intentional or not. It makes sense in one way to complain about an invalid argument (as in Python 2.4) rather than just ignore the operation (as in Python 2.3). However, I did not find this change in either the documentation or the release notes, and it caught me by surprise. Granted, the stricter argument checking probably caught a sloppy line of coding. Still, some kind of user warning would have been nice if this was an intentional change. I am enclosing a simple Python script which illustrates the problem. It finishes normally when using Python 2.3 and raises a RuntimeError when using Python 2.4: Traceback (most recent call last): File "set_signals.py", line 7, in ? signal.signal(signal.SIGKILL, dummy) RuntimeError: (22, 'Invalid argument') Gary H. Loechelt -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083177&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1083202 ] UnboundLocalError raised by atexit module
Bugs item #1083202, was opened at 2004-12-10 14:39 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=1083202&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gary H. Loechelt (loechelt) Assigned to: Nobody/Anonymous (nobody) Summary: UnboundLocalError raised by atexit module Initial Comment: The following exception is raised on exit by Python 2.4 under certain circumstances: Error in sys.exitfunc: Traceback (most recent call last): File "/usr/local/python/python2.4/lib/python2.4/atexit.py", line 24, in _run_exitfuncs exc_info = sys.exc_info() UnboundLocalError: local variable 'sys' referenced before assignment I traced the problem to a missing import statement in the atexit.py file. I am enclosing a corrected file with the patch. Gary H. Loechelt -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083202&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
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: Closed >Resolution: Fixed 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-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 "never-ending maintenance problem" is the result of the locale horror we all have to live with until there's a final solution/standard for it. b) Agree, I now understand your "getdefaultlocale .. inherently broken" comment. But we still have a locale module that supports some of the valid locales but not all, which is (IMO) worse then having none at all. BTW: getting the
[ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting
Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Settings changed) 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: 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: 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 "never-ending maintenance problem" is the result of the locale horror we all have to live with until there's a final solution/standard for it. b) Agree, I now understand your "getdefaultlocale .. inherently broken" comment. But we still have a locale module that supports some of the valid locales but not all, which is (IMO) worse then having none at all. BTW: getting the
[ python-Bugs-1083299 ] Distutils doesn't pick up all the files it should.
Bugs item #1083299, was opened at 2004-12-10 19:22 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=1083299&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: Distutils doesn't pick up all the files it should. Initial Comment: Distutils doesn't pick up files specified in setup.py that it knows about. For instance, files listed on the depends keyword of the Extension class don't get included in a source distribution, or copied to the build directory when building a binary distribution. The data-files keyword to the setup function reportedly suffers the same fate. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083299&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1083202 ] UnboundLocalError raised by atexit module
Bugs item #1083202, was opened at 2004-12-10 16:39 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083202&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gary H. Loechelt (loechelt) Assigned to: Nobody/Anonymous (nobody) Summary: UnboundLocalError raised by atexit module Initial Comment: The following exception is raised on exit by Python 2.4 under certain circumstances: Error in sys.exitfunc: Traceback (most recent call last): File "/usr/local/python/python2.4/lib/python2.4/atexit.py", line 24, in _run_exitfuncs exc_info = sys.exc_info() UnboundLocalError: local variable 'sys' referenced before assignment I traced the problem to a missing import statement in the atexit.py file. I am enclosing a corrected file with the patch. Gary H. Loechelt -- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 21:54 Message: Logged In: YES user_id=80475 Fixed. See Lib/atexit.py 1.9 and 1.8.2.1. Thanks for the bug report. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083202&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1083177 ] Change in signal function in the signal module
Bugs item #1083177, was opened at 2004-12-10 15:58 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083177&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gary H. Loechelt (loechelt) >Assigned to: Anthony Baxter (anthonybaxter) Summary: Change in signal function in the signal module Initial Comment: The signal function of the signal module handles arguments differently in Python 2.4 than in Python 2.3. I am running on an HP-UX 11 workstation. If I set a handler for a signal that cannot be trapped, like KILL (signal 9), the signal function accepts the argument in Python 2.3 but ignores the operation. However, if I do the same thing in Python 2.4, the signal function rejects the argument and raises a RuntimeError. I am not sure if this change in behavior is intentional or not. It makes sense in one way to complain about an invalid argument (as in Python 2.4) rather than just ignore the operation (as in Python 2.3). However, I did not find this change in either the documentation or the release notes, and it caught me by surprise. Granted, the stricter argument checking probably caught a sloppy line of coding. Still, some kind of user warning would have been nice if this was an intentional change. I am enclosing a simple Python script which illustrates the problem. It finishes normally when using Python 2.3 and raises a RuntimeError when using Python 2.4: Traceback (most recent call last): File "set_signals.py", line 7, in ? signal.signal(signal.SIGKILL, dummy) RuntimeError: (22, 'Invalid argument') Gary H. Loechelt -- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 22:32 Message: Logged In: YES user_id=80475 On WinME, I appropriately get an AttributeError consistently for Py2.2, Py2.3, and Py2.4. Anthony, you've made the most recent updates to the signalmodule. What do you think? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083177&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1083110 ] truncated gzip file triggers zlibmodule segfault
Bugs item #1083110, was opened at 2004-12-10 13:54
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083110&group_id=5470
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 6
Submitted By: Sam Rushing (rushing)
>Assigned to: A.M. Kuchling (akuchling)
Summary: truncated gzip file triggers zlibmodule segfault
Initial Comment:
If gzip.py reads a mangled/truncated file and leaves
the file pointer at EOF, the zlibmodule will crash when
it calls 'flush' (PyZlib_unflush()). I've traced through
zlib a bit, and I think the problem is that the 'avail_in'
slot of the decompression struct is left uninitialized.
The problem can be made to go away by setting that
slot to zero in either PyZlib_decompressobj(), or in
PyZlib_unflush() itself. However, I'm not familiar enough
with the code to know if there's some other reason
the slot contains garbage.
Reproduction:
>>> open ('x.gz', 'wb').write
('\x1f\x8b\x08\x08b\xee\xb9A\x00\x03x\x00')
>>> import gzip
>>> gzip.GzipFile ('x.gz', 'rb').read()
Segmentation fault (core dumped)
[the above data is simply a small gzip file truncated
after the zero-terminated filename]
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-10 22:43
Message:
Logged In: YES
user_id=80475
On WinME, I can confirm segfaults in Py2.3 and Py2.4.
Andrew, I think this is your baby.
BTW, the OP's example would make an excellent testcase.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083110&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1082487 ] font lock keyword regular expressions
Bugs item #1082487, was opened at 2004-12-09 16:43 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082487&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Brown (robert-brown) >Assigned to: Skip Montanaro (montanaro) Summary: font lock keyword regular expressions Initial Comment: I've noticed that when I use Python mode (alpha 1) with font lock mode, "self" is highlighted in the following line: his_self() The problem appears to be a combination of using "\b" in the Python font lock regular expressions and my .emacs file, which does: (modify-syntax-entry ?\_ "_" py-mode-syntax-table) I do not experience similar problems with highlighting in C mode, but there "\<" and "\>" are used in the font lock regular expressions. Using these word delimiters instead of "\b" appears to fix the problem for me in Python mode. Please wrap keywords with "\<" and "\>" instead of with "\b" in the font lock regular expression. Thanks very much. Bob -- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 22:36 Message: Logged In: YES user_id=80475 Skip, can you field this one? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082487&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1082874 ] Unable to see Python binary
Bugs item #1082874, was opened at 2004-12-10 12:26 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=1082874&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Prabal Rakshit (prabal_rakshit) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to see Python binary Initial Comment: After extracting the Python-2.3.3.tar we could get the appropriate folder structure. We then executed the configure script. Therafter when we execute the make command the Python binary is not created in /usr/local/bin. Any pointers?? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082874&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
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-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 "never-ending maintenance problem" is the result of the locale horror we all have to live with until there's a final solution/standard for it. b) Agree, I now understand your "getdefaultlocale .. inherently broken" comment. But we still have a locale module that supports some of the valid locales but not all, which is (IMO) worse then having none at all. BTW: getting the current locale to get a platform independant language setting, should perhaps be part of gettext.py instead of locale.py? -- Comment By: Martin v. Löwis (loewis) Date: 2004-12-08 22:28 Message: Logged In: YES user_id=21627 MAL: that doesn't an
[ python-Bugs-1082944 ] Documentation for PyUnicode_TailMatch incorrrectly says it r
Bugs item #1082944, was opened at 2004-12-10 09:38 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082944&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jim Fulton (dcjim) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation for PyUnicode_TailMatch incorrrectly says it r Initial Comment: nuf said ;) -- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 12:14 Message: Logged In: YES user_id=80475 Fixed. See Doc/api/concrete.tex 1.59 and 1.58.2.1. -- Comment By: Jim Fulton (dcjim) Date: 2004-12-10 11:44 Message: Logged In: YES user_id=73023 Crap. SourceForge accepted a long title and then truncated it. :( The Documentation for PyUnicode_TailMatch incorrrectly says it returns a PyObject pointer, which is incorrect. It returns an int. (It doesn't mention error returns. I assume that, in absense of any statement, a return value of -1 indicates an error, as is standard.) -- Comment By: Tim Peters (tim_one) Date: 2004-12-10 10:53 Message: Logged In: YES user_id=31435 Umm, no, you typed so much into the Summary box that it got truncated. It ends with "incorrectly says it r". I assume "r" started as "returns", but that's where my telepathy stalls . -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082944&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080660 ] thread.error: release unlocked lock on Queue put
Bugs item #1080660, was opened at 2004-12-07 09:48 Message generated for change (Comment added) made by corvus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080660&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Speno (corvus) Assigned to: Nobody/Anonymous (nobody) Summary: thread.error: release unlocked lock on Queue put Initial Comment: System is Python 2.3.3 on Solaris 9. I'm using the classic Python thread model. Main thread puts stuff into a Queue.Queue() and worker threads get stuff out of it and do their thing. On occaision, I get an exception in the main thread when it tries to put something into the Queue. File "/usr/local/bin/poller.py", line 47, in fragnap_it work_queue.put((foo, bar, baz)) File "/usr/local/lib/python2.3/Queue.py", line 106, in put self.fsema.release() thread.error: release unlocked lock This error still happens intermittently, and I haven't been able to reduce it to a simple case. I can alter my applications to do something useful for debugging this problem when it happens, if you can figure out what "something useful" would be. Just let me know. The queue is unbounded, and I'm using blocking get/put. The main thread creates 20 worker threads, and 1 recorder thread. Then it puts upto 1500 items in the Queue.Queue named work_queue. The 20 worker threads take stuff out work_queue, process some using pure python code, or others by using subprocess.py. Results from the workers are put into another Queue.Queue named results_queue. The Recorder thread gets from the results_queue and writes stuff to a MySQL db. I've never seen the error happen when putting into the results_queue, only from the main thread putting into the work_queue. Thread defines in my python config.h are: #define HAVE_PTHREAD_H 1 #define HAVE_PTHREAD_SIGMASK 1 #define HAVE_THREAD_H 1 #define PTHREAD_SYSTEM_SCHED_SUPPORTED 1 #define SIZEOF_PTHREAD_T 4 #define WITH_THREAD 1 And all the thread related python tests (test_thread, test_threading, and test_queue) pass. -- >Comment By: John Speno (corvus) Date: 2004-12-10 12:57 Message: Logged In: YES user_id=2138 Given that I can't reproduce it in a simple test, and it happens so rarely in my real applications, I'm okay with notice of it just being in google and here on sf. Maybe someday someone will encounter it again and we can make progress. -- Comment By: Tim Peters (tim_one) Date: 2004-12-10 12:45 Message: Logged In: YES user_id=31435 No, and there are no known bugs in Queue in 2.3.j. If John can't whittle it down to a test case that fails for others, I expect this bug is hopeless. We talked about it on c.l.py, and what he's seeing should be impossible. Presuming it's a Solaris-specific bug. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 12:35 Message: Logged In: YES user_id=80475 Tim, was this something you already fixed in Py2.4? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080660&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1082874 ] Unable to see Python binary
Bugs item #1082874, was opened at 2004-12-10 12:26 Message generated for change (Comment added) made by dyoo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082874&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Prabal Rakshit (prabal_rakshit) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to see Python binary Initial Comment: After extracting the Python-2.3.3.tar we could get the appropriate folder structure. We then executed the configure script. Therafter when we execute the make command the Python binary is not created in /usr/local/bin. Any pointers?? -- Comment By: Danny Yoo (dyoo) Date: 2004-12-10 21:19 Message: Logged In: YES user_id=49843 The 'make install' target will copy the built binary to '/usr/local/bin'. Did you try 'make install' yet? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082874&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
