[ python-Bugs-1698398 ] wrong % of params for format string in ZipFile.printdir()
Bugs item #1698398, was opened at 2007-04-11 14: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=1698398&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Szabolcs Berecz (szabihernyo)
Assigned to: Nobody/Anonymous (nobody)
Summary: wrong % of params for format string in ZipFile.printdir()
Initial Comment:
In zipfile.py:448
date = "%d-%02d-%02d %02d:%02d:%02d" % zinfo.date_time
should be changed to
date = "%d-%02d-%02d %02d:%02d:%02d" % zinfo.date_time[:6]
checked with python2.[45] on windows and linux
>>> from zipfile import ZipFile
>>> from StringIO import StringIO
>>> s = StringIO()
>>> zf = ZipFile(s, 'w')
>>> zf.writestr('file.ext', '123')
>>> zf.printdir()
File Name Modified Size
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/zipfile.py", line 448, in printdir
date = "%d-%02d-%02d %02d:%02d:%02d" % zinfo.date_time
TypeError: int argument required
>>> zf.filelist[0].date_time
(2007, 4, 11, 13, 38, 58, 2, 101, 1)
>>>
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1698398&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1698398 ] wrong % of params for format string in ZipFile.printdir()
Bugs item #1698398, was opened at 2007-04-11 07:58
Message generated for change (Comment added) made by alanmcintyre
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1698398&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Szabolcs Berecz (szabihernyo)
Assigned to: Nobody/Anonymous (nobody)
Summary: wrong % of params for format string in ZipFile.printdir()
Initial Comment:
In zipfile.py:448
date = "%d-%02d-%02d %02d:%02d:%02d" % zinfo.date_time
should be changed to
date = "%d-%02d-%02d %02d:%02d:%02d" % zinfo.date_time[:6]
checked with python2.[45] on windows and linux
>>> from zipfile import ZipFile
>>> from StringIO import StringIO
>>> s = StringIO()
>>> zf = ZipFile(s, 'w')
>>> zf.writestr('file.ext', '123')
>>> zf.printdir()
File Name Modified Size
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/zipfile.py", line 448, in printdir
date = "%d-%02d-%02d %02d:%02d:%02d" % zinfo.date_time
TypeError: int argument required
>>> zf.filelist[0].date_time
(2007, 4, 11, 13, 38, 58, 2, 101, 1)
>>>
--
Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-04-11 08:34
Message:
Logged In: YES
user_id=1115903
Originator: NO
The same problem appears to be present in 2.6 as well. The date_time
attribute of ZipInfo is a time.struct_time in 2.4 and 2.6 (I don't have 2.5
available to check at the moment), not a tuple. I'm assuming this could be
fixed by changing that line to:
date = "%d-%02d-%02d %02d:%02d:%02d" % tuple(zinfo.date_time)[:6]
At the moment I can't connect to the svn server; when I can I'll submit a
patch for the trunk and 2.5.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1698398&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1697782 ] types.InstanceType is missing but used by pydoc
Bugs item #1697782, was opened at 2007-04-10 17:55 Message generated for change (Comment added) made by tiran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697782&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: types.InstanceType is missing but used by pydoc Initial Comment: >>> help(callable.__call__) Traceback (most recent call last): File "", line 1, in File "/home/heimes/dev/python/p3yk/Lib/site.py", line 348, in __call__ return pydoc.help(*args, **kwds) File "/home/heimes/dev/python/p3yk/Lib/pydoc.py", line 1658, in __call__ self.help(request) File "/home/heimes/dev/python/p3yk/Lib/pydoc.py", line 1702, in help else: doc(request, 'Help on %s:') File "/home/heimes/dev/python/p3yk/Lib/pydoc.py", line 1477, in doc desc = describe(object) File "/home/heimes/dev/python/p3yk/Lib/pydoc.py", line 1436, in describe if type(thing) is types.InstanceType: AttributeError: 'module' object has no attribute 'InstanceType' -- >Comment By: Christian Heimes (tiran) Date: 2007-04-11 15:52 Message: Logged In: YES user_id=560817 Originator: YES types.InstanceType is still used by several stdlib modules. FIX: svn cp the types.py module from Python 2.6 to the p3yk branh -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697782&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1431091 ] CSV Sniffer fails to report mismatch of column counts
Bugs item #1431091, was opened at 2006-02-13 23:47
Message generated for change (Comment added) made by tekkaman
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431091&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Vinko (vvrsalob)
Assigned to: Andrew McNamara (andrewmcnamara)
Summary: CSV Sniffer fails to report mismatch of column counts
Initial Comment:
If one line of a CSV file is missing one or more
commas, the delimiter detection code of the Sniffer
class fails, setting delimiter to an empty string.
This leads to a totally misleading error when using
has_header().
This code shows the problem (Python 2.4.2, FC3 and
Ubuntu Breezy):
import csv
str1 = "a,b,c,d\r\n1,2,foo bar,dead
beef\r\nthis,line,is,ok\r\n"
str2 = "a,b,c,d\r\n1,2,foo bar,dead beef\r\nthis,line
is,not\r\n"
s = csv.Sniffer()
d1 = s.sniff(str1)
d2 = s.sniff(str2)
for line in str1.split('\r\n'):
print line.count(',')
print d1.delimiter
print s.has_header(str1)
for line in str2.split('\r\n'):
print line.count(',')
print d2.delimiter
print s.has_header(str2)
--
Comment By: Simone Leo (tekkaman)
Date: 2007-04-11 17:59
Message:
Logged In: YES
user_id=891539
Originator: NO
Problem is still there as of Python 2.4.3.
Trying to read in a file whose lines have a different number of fields, I
get:
Traceback (most recent call last):
File "../myscript.py", line 59, in ?
main()
File "../myscript.py", line 30, in main
reader = csv.reader(fin, dialect)
TypeError: bad argument type for built-in operation
where "dialect" has been sniffed by feeding the first two lines to the
Sniffer.
What I expect is to either:
1. get different sized rows, with no exception raised
2. get a csv.Error instead of the TypeError above
Thanks
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431091&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1697916 ] Segfaults on memory error
Bugs item #1697916, was opened at 2007-04-10 14:47 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697916&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None >Priority: 6 Private: No Submitted By: STINNER Victor (haypo) >Assigned to: Raymond Hettinger (rhettinger) Summary: Segfaults on memory error Initial Comment: Hi, I'm playing with resource.setrlimit(resource.RLIMIT_AS) to limit memory usage during fuzzing tests. It works quite well but Python crashs sometimes (with SEGFAULT). I downloaded Python source code and recompiled it with EXTRA_FLAGS="-g -O0" to find errors. I found three bugs and wrote a patch for all of them. Comments: * Objects/exceptions.c:33: allocation may returns NULL on memory error * Objects/longobject.c:2511: long_divrem() may allocate new long integers but l_divmod() doesn't check that div and mod are not NULL * Objects/object.c:1284: problem with NULL mro. I don't understand how mro works, but I think that the error may be catched when mro is assigned. Problem: where is it done? in Objects/typeobject.c? So don't apply my patch directly: fix for object.c may be wrong. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697916&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1698398 ] wrong % of params for format string in ZipFile.printdir()
Bugs item #1698398, was opened at 2007-04-11 07:58
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1698398&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
>Group: Python 2.5
Status: Open
Resolution: None
>Priority: 6
Private: No
Submitted By: Szabolcs Berecz (szabihernyo)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: wrong % of params for format string in ZipFile.printdir()
Initial Comment:
In zipfile.py:448
date = "%d-%02d-%02d %02d:%02d:%02d" % zinfo.date_time
should be changed to
date = "%d-%02d-%02d %02d:%02d:%02d" % zinfo.date_time[:6]
checked with python2.[45] on windows and linux
>>> from zipfile import ZipFile
>>> from StringIO import StringIO
>>> s = StringIO()
>>> zf = ZipFile(s, 'w')
>>> zf.writestr('file.ext', '123')
>>> zf.printdir()
File Name Modified Size
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/zipfile.py", line 448, in printdir
date = "%d-%02d-%02d %02d:%02d:%02d" % zinfo.date_time
TypeError: int argument required
>>> zf.filelist[0].date_time
(2007, 4, 11, 13, 38, 58, 2, 101, 1)
>>>
--
Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-04-11 08:34
Message:
Logged In: YES
user_id=1115903
Originator: NO
The same problem appears to be present in 2.6 as well. The date_time
attribute of ZipInfo is a time.struct_time in 2.4 and 2.6 (I don't have 2.5
available to check at the moment), not a tuple. I'm assuming this could be
fixed by changing that line to:
date = "%d-%02d-%02d %02d:%02d:%02d" % tuple(zinfo.date_time)[:6]
At the moment I can't connect to the svn server; when I can I'll submit a
patch for the trunk and 2.5.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1698398&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1698167 ] xml.etree document element.tag
Bugs item #1698167, was opened at 2007-04-11 01:25 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1698167&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: paul rubin (phr) >Assigned to: Fredrik Lundh (effbot) Summary: xml.etree document element.tag Initial Comment: The xml.etree docs vaguely mention an implementation-dependent Element interface without describing it in any detail. I could not figure out from the docs how to get the tag name of an element returned from (say) the getiterator interface. That is, for an element like , I wanted the string "foo". Examining the library source showed that e.tag does the job, at least some of the time, and that was enough to get my app working. Could the actual situation please be documented--thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1698167&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1697943 ] msgfmt cannot cope with BOM
Bugs item #1697943, was opened at 2007-04-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=1697943&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and Tools Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christoph Zwerschke (cito) >Assigned to: Martin v. Löwis (loewis) Summary: msgfmt cannot cope with BOM Initial Comment: If a .po file has a BOM (byte order mark) at the beginning, as is often the case for utf-8 files created on Windows, msgfmt.py complines about a syntax error. The attached patch fixes this problem. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-04-11 11:07 Message: Logged In: YES user_id=80475 Originator: NO Martin, is this your code? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697943&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1697916 ] Segfaults on memory error
Bugs item #1697916, was opened at 2007-04-10 19:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697916&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 6 Private: No Submitted By: STINNER Victor (haypo) Assigned to: Raymond Hettinger (rhettinger) Summary: Segfaults on memory error Initial Comment: Hi, I'm playing with resource.setrlimit(resource.RLIMIT_AS) to limit memory usage during fuzzing tests. It works quite well but Python crashs sometimes (with SEGFAULT). I downloaded Python source code and recompiled it with EXTRA_FLAGS="-g -O0" to find errors. I found three bugs and wrote a patch for all of them. Comments: * Objects/exceptions.c:33: allocation may returns NULL on memory error * Objects/longobject.c:2511: long_divrem() may allocate new long integers but l_divmod() doesn't check that div and mod are not NULL * Objects/object.c:1284: problem with NULL mro. I don't understand how mro works, but I think that the error may be catched when mro is assigned. Problem: where is it done? in Objects/typeobject.c? So don't apply my patch directly: fix for object.c may be wrong. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-04-11 16:11 Message: Logged In: YES user_id=849994 Originator: NO Status update: Fixed the first two bugs locally, and a third one discovered by Victor on #python-dev. The mro one is unclear -- we've asked him to reproduce it and poke around in gdb to see why tp_mro is NULL, which it shouldn't be. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697916&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1672568 ] silent error in email.message.Message.get_payload
Bugs item #1672568, was opened at 2007-03-02 12:04 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672568&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Not a Bug Status: Open Resolution: None Priority: 5 Private: No Submitted By: Renaud Blanch (blanch) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: silent error in email.message.Message.get_payload Initial Comment: I rencently had trouble finding a bug in an email processing script because of an error that pass silently in the email module. The get_payload() method in the email.message module always return something when the decode argument is set to True. This behaviour is well documented, but is their a reason to catch the decoding errors ? Why not let them pop-up to the calling code ? renaud -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672568&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1583862 ] yield+break stops tracing
Bugs item #1583862, was opened at 2006-10-24 10:55
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583862&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Lukas Lalinsky (luks)
Assigned to: Nobody/Anonymous (nobody)
Summary: yield+break stops tracing
Initial Comment:
Here is an example script:
def myiter():
for i in range(10):
yield i
for i in myiter():
break
print "foo"
Now, if I try to trace it:
$ python -m trace --trace --count test.py
--- modulename: threading, funcname: settrace
threading.py(70): _trace_hook = func
--- modulename: test, funcname:
test.py(1): def myiter():
test.py(5): for i in myiter():
--- modulename: test, funcname: myiter
test.py(2): for i in range(10):
test.py(3): yield i
test.py(6): break
c:\python25\lib\ntpath.py:190: RuntimeWarning:
tp_compare didn't return -1 or -2 for exception
if i<=max(p.rfind('/'), p.rfind('\\')):
foo
It stops tracing after the `break` statement. The line
after, `print "foo"`, is not traced nor included in the
coverage output.
I'm not sure RuntimeWarning from ntpath.py is relevant
here, because if I use the trace module in some other
situation it doesn't print it. IMO, it's just a side
effect of some different problem.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-04-11 11:52
Message:
Logged In: YES
user_id=80475
Originator: NO
Using Py2.5.1, the problem seems to have gone away.
Lukas, can you please verify that it is solved and then close.
===
[EMAIL PROTECTED] ~ $ py25/python -m trace --trace --count test.py
--- modulename: threading, funcname: settrace
threading.py(70): _trace_hook = func
--- modulename: trace, funcname:
(1): --- modulename: trace, funcname:
test.py(1): def myiter():
test.py(6): for i in myiter():
--- modulename: trace, funcname: myiter
test.py(2): for i in range(10):
test.py(3): yield i
test.py(7): break
--- modulename: trace, funcname: myiter
test.py(9): print 'foo'
foo
--
Comment By: Lukas Lalinsky (luks)
Date: 2006-10-24 11:05
Message:
Logged In: YES
user_id=587716
Oh, I forgot. This bug is specific to Python 2.5. It works
fine in 2.4.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583862&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1678710 ] dead link in tkinter documentation
Bugs item #1678710, was opened at 2007-03-11 22:34 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678710&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ben Collver (bencollver) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: dead link in tkinter documentation Initial Comment: On the following page, there is a dead link. http://www.python.org/doc/2.3.5/lib/node642.html The dead link is to the following URL. http://www.python.org/doc/2.3.5/lib/classes/ClassPacker.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678710&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1697916 ] Segfaults on memory error
Bugs item #1697916, was opened at 2007-04-10 21:47 Message generated for change (Comment added) made by haypo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697916&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 >Status: Closed Resolution: None Priority: 6 Private: No Submitted By: STINNER Victor (haypo) Assigned to: Raymond Hettinger (rhettinger) Summary: Segfaults on memory error Initial Comment: Hi, I'm playing with resource.setrlimit(resource.RLIMIT_AS) to limit memory usage during fuzzing tests. It works quite well but Python crashs sometimes (with SEGFAULT). I downloaded Python source code and recompiled it with EXTRA_FLAGS="-g -O0" to find errors. I found three bugs and wrote a patch for all of them. Comments: * Objects/exceptions.c:33: allocation may returns NULL on memory error * Objects/longobject.c:2511: long_divrem() may allocate new long integers but l_divmod() doesn't check that div and mod are not NULL * Objects/object.c:1284: problem with NULL mro. I don't understand how mro works, but I think that the error may be catched when mro is assigned. Problem: where is it done? in Objects/typeobject.c? So don't apply my patch directly: fix for object.c may be wrong. -- >Comment By: STINNER Victor (haypo) Date: 2007-04-11 18:53 Message: Logged In: YES user_id=365388 Originator: YES Ignore my bug about NULL mro since i'm not able to reproduce it. Thanks for the 3 other fixes ;-) -- Comment By: Georg Brandl (gbrandl) Date: 2007-04-11 18:11 Message: Logged In: YES user_id=849994 Originator: NO Status update: Fixed the first two bugs locally, and a third one discovered by Victor on #python-dev. The mro one is unclear -- we've asked him to reproduce it and poke around in gdb to see why tp_mro is NULL, which it shouldn't be. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697916&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633648 ] incomplete numerical comparisons
Bugs item #1633648, was opened at 2007-01-11 19:18 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633648&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None >Priority: 6 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: incomplete numerical comparisons Initial Comment: [forwarded from http://bugs.debian.org/334022] bug submitter writes: I've been tracking down the regression failure in python-pgsql under python2.[45], and here's what it comes down to. Python-pgsql includes a short int type named PgInt2, which allows itself to be coerced into all of the usual numeric types. The regression that fails is when a PgInt2 is compared with a float. In this case python determines that the comparison is not implemented. The problem is this: - Under python2.[45], the float type includes tp_richcompare but not tp_compare. - When calling try_rich_to_3way_compare(), python does not try any kind of numeric coercion, and so the comparison fails. - When calling try_3way_compare(), python successfully coerces the PgInt2 into a float, but then the comparison fails because the float type has no tp_compare routine. Presumably what would fix things would be one of the following: - Bring back the trivial float_compare() routine, which was removed with python2.[45] when they brought in the new float_richcompare() instead; - In try_3way_compare(), if the coercion succeeds and neither object has a tp_compare routine, try tp_richcompare before failing completely. Does either of these solutions seem feasible? Thanks - Ben. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-04-11 11:55 Message: Logged In: YES user_id=80475 Originator: NO Raising the priority so this report doesn't get lost. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633648&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1613130 ] str.split creates new string even if pattern not found
Bugs item #1613130, was opened at 2006-12-11 08:03
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613130&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Performance
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 1
Private: No
Submitted By: Antoine Pitrou (pitrou)
Assigned to: Fredrik Lundh (effbot)
Summary: str.split creates new string even if pattern not found
Initial Comment:
Hello,
Several string methods avoid allocating a new string when the operation result
is trivially the same as one of the parameters (e.g. replacing a non-existing
substring). However, split() does not exhibit this optimization, it always
constructs a new string even if no splitting occurs:
$ python
Python 2.5 (r25:51908, Oct 6 2006, 15:22:41)
[GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> s = "abcde" * 2
>>> id(s)
3084139400L
>>> id(str(s))
3084139400L
>>> id("" + s)
3084139400L
>>> id(s.strip())
3084139400L
>>> id(s.replace("g", "h"))
3084139400L
>>> [id(x) for x in s.partition("h")]
[3084139400L, 3084271768L, 3084271768L]
>>> [id(x) for x in s.split("h")]
[3084139360L]
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-04-11 12:09
Message:
Logged In: YES
user_id=80475
Originator: NO
Dropping the priority. This pay-off is near zero and likely not worth the
cost of making the code more complex than it already is.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-12-12 11:21
Message:
Logged In: YES
user_id=849994
Originator: NO
Sounds like this is best assigned to Fredrik.
--
Comment By: Antoine Pitrou (pitrou)
Date: 2006-12-12 06:35
Message:
Logged In: YES
user_id=133955
Originator: YES
Ok, I did a patch which partially adds the optimization (the patch is at
home, I can't post it right now). I have a few questions though:
- there is a USE_FAST flag which can bring some speedups when a
multicharacter separator is used; however, it is not enabled by default, is
there a reason for this?
- where and by whom is maintained stringbench.py, so that I can propose
additional tests for it (namely, tests for unmatched split())?
- split() implementation is duplicated between str and unicode (the
unicode versions having less optimizations), would it be useful to
"stringlib'ify" split()?
- rsplit() does quite similar things as split(), has anyone tried to
factor similar parts? do you see any caveats doing so?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613130&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1621111 ] IDLE crashes on OS X 10.4 when "Preferences" selected
Bugs item #162, was opened at 2006-12-22 23:03 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=162&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.5 Status: Open Resolution: None >Priority: 6 Private: No Submitted By: Mick L (mehum) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: IDLE crashes on OS X 10.4 when "Preferences" selected Initial Comment: When I select 'preferences' (on IDLE 1.2, Python 2.5) or 'Configure IDLE' (IDLE 1.1.4, Python 2.4.4 and IDLE 1.0, Python 2.3.3), Python crashes as soon as the dialog box appears. Terminal reports a "Segmentation fault" upon the crash. My system is an iMac G5 with 1 GB ram running OS X v 10.4.8, Tcl/Tk 8.4.10, and seems otherwise stable. IDLE also appears stable until I select this option. The Python crash log is attached. Please, can anyone suggest what may be causing this problem? Thank you. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-04-11 12:12 Message: Logged In: YES user_id=80475 Originator: NO Bumping up the priority so this doesn't get lost. My guess is that IDLE is tickling some problem with the TkInter bindings. -- Comment By: François Scholder (f_scholder) Date: 2007-02-02 16:55 Message: Logged In: YES user_id=1609867 Originator: NO Erratum: A similar problem arises with WinXP when trying to configure IDLE via the "Options>Configure IDLE..." menu. Clicking on the 'Ok' or 'Apply' buttons of the dialog seemingly has no effect. However when closing the window by clicking on either the window close button (top right 'X') or the 'Cancel' button, several bahaviors are observed depending on how many times one has clicked on the 'Ok' and/or >'Apply'< buttons before: - 0 clicks => expected behavior (dialog is closed, IDLE session is resumed and working fine) - 1 or 2 clicks => dialog is closed but the IDLE shell behaves as a text editor instead of an interpreter - 3 or more clicks => IDLE crashes... Note: I'm running Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 -> WinXP SP2 -- Comment By: François Scholder (f_scholder) Date: 2007-02-02 16:48 Message: Logged In: YES user_id=1609867 Originator: NO A similar problem arises with WinXP when trying to configure IDLE via the "Options>Configure IDLE..." menu. Clicking on the 'Ok' or 'Apply' buttons of the dialog seemingly has no effect. However when closing the window by clicking on either the window close button (top right 'X') or the 'Cancel' button, several bahaviors are observed depending on how many times one has clicked on the 'Ok' and/or 'Cancel' buttons before: - 0 clicks => expected behavior (dialog is closed, IDLE session is resumed and working fine) - 1 or 2 clicks => dialog is closed but the IDLE shell behaves as a text editor instead of an interpreter - 3 or more clicks => IDLE crashes... Note: I'm running Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 -> WinXP SP2 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=162&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1607041 ] Condition.wait timeout fails when system clock changes
Bugs item #1607041, was opened at 2006-12-01 13:45
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607041&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: BC (hashstat)
Assigned to: Nobody/Anonymous (nobody)
Summary: Condition.wait timeout fails when system clock changes
Initial Comment:
If the system clock is adjusted after Condition.wait is called with a timeout,
the timeout does not expire as expected. This appears to be due to the
threading.Condition class using the system clock to calculate the timeout
expiration without taking system clock changes into account. Let me illustrate
this with an example:
import threading
c = threading.Condition()
c.acquire()
try:
...
c.wait(3600.0)
...
finally:
c.release()
Let's say the above snippet is executed at 08:00. Assuming the condition is
never notified, the timeout should expire somewhere close to 09:00. At 08:30
someone notices that the clock is an hour fast and sets it back to 07:30. The
timeout still expire around 09:00 causing a wait of 2 hours instead of the
requested 1 hour.
Now let's say instead that the clock was moved ahead to 09:30 at 08:30. The
timeout would expire immediately after only a 30 minute wait.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-04-11 12:19
Message:
Logged In: YES
user_id=80475
Originator: NO
I don't think this is the right thing to do. Detecting clock changes is
tricky (all you can do is detect backward movement). Then, deciding what
to do about it also involves a certain amount of guesswork (at how much the
time changed and what the user really wants to occur). Also, changing
clocks may affect many parts of the system (log entries being out of order,
etc) and it is not entirely clear what the interactions should be with the
Condition timeout. IOW, when the clock changes, you've likely got bigger
problems. Refuse the temptation to guess.
--
Comment By: Jp Calderone (kuran)
Date: 2006-12-01 17:50
Message:
Logged In: YES
user_id=366566
Originator: NO
Yes, I misunderstood. Please disregard my comments. :)
--
Comment By: BC (hashstat)
Date: 2006-12-01 17:35
Message:
Logged In: YES
user_id=939959
Originator: YES
I submitted patch# 1607149 to add checking for clock variations in the
wait method when called with a timeout.
--
Comment By: BC (hashstat)
Date: 2006-12-01 16:57
Message:
Logged In: YES
user_id=939959
Originator: YES
Apparently my description wasn't as clear as I thought. I don't care
about the clock times in the example. They were only used to illustrate
the point. What I do care about is that if a use c.wait(3600) ("wait 60
minutes"), then my thread should wake up in roughly 60 minutes without
regard to changes in the system clock.
With the current Condition implementation, no matter what timeout is used,
setting the system clock ahead reduces or eliminates the wait while setting
the system clock back increases the wait. So if the clock is set back one
hour in the middle of a 1 microsecond wait (c.wait(1)), wait will return in
an hour and 1 microsecond. Is this the way it should work?
--
Comment By: Jp Calderone (kuran)
Date: 2006-12-01 16:06
Message:
Logged In: YES
user_id=366566
Originator: NO
Why should it work that way?
c.wait(3600) doesn't say "wait until 0900", it says "wait 60 minutes".
If you want c.waitUntil(9 oclock), maybe that would be a good API
addition, but it definitely should be a separate method.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607041&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-1191699 ] make slices pickable
Feature Requests item #1191699, was opened at 2005-04-28 08:44
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191699&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
>Group: Python 2.6
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Sebastien de Menten (sdementen)
Assigned to: Raymond Hettinger (rhettinger)
Summary: make slices pickable
Initial Comment:
As suggested by the summary, provide pickability of
slices by default.
Currently one has to use copy_reg module to register
slices as pickables.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-04-11 13:41
Message:
Logged In: YES
user_id=80475
Originator: NO
Done. See revision 54760.
--
Comment By: Connelly (connelly)
Date: 2006-07-16 13:55
Message:
Logged In: YES
user_id=1039782
Additional use case: I needed picklable slices when logging method calls
to a
database: __setitem__(self, i, x) could not be logged because the
database
module attempted to pickle objects such as ('__setitem__', slice(1, 2, 3),
[]).
For other Python users who have run into this problem: the code needed to
make slices picklable by copy_reg is available at:
http://mail.python.org/pipermail/python-list/2004-November/
248988.html
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-02 19:50
Message:
Logged In: YES
user_id=80475
Okay, sounds reasonable. Will implement when I have time.
--
Comment By: Sebastien de Menten (sdementen)
Date: 2005-04-30 13:02
Message:
Logged In: YES
user_id=820079
Use case for pickable slices.
Let A be a numeric array of size M x N. We want to consider
sub-arrays in this array like A[:4, :] (the first 4 lines of the
array).
If we want to store both the array and the information of
sub-arrays structures, we need to store slices (we can also
store start/end indices of the array ... but this is call a slice
so it would be better to have pickable slices).
In fact, whenever one wants to write generic algorithm
working on "sublist of lists" or "subarrays of arrays" or
"sub-items of collection of items", it is nicer to use slice
objects explicitly and so store them also explicitly.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-30 07:32
Message:
Logged In: YES
user_id=80475
Use cases?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191699&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1697782 ] types.InstanceType is missing but used by pydoc
Bugs item #1697782, was opened at 2007-04-10 15:55 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697782&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 3000 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: types.InstanceType is missing but used by pydoc Initial Comment: >>> help(callable.__call__) Traceback (most recent call last): File "", line 1, in File "/home/heimes/dev/python/p3yk/Lib/site.py", line 348, in __call__ return pydoc.help(*args, **kwds) File "/home/heimes/dev/python/p3yk/Lib/pydoc.py", line 1658, in __call__ self.help(request) File "/home/heimes/dev/python/p3yk/Lib/pydoc.py", line 1702, in help else: doc(request, 'Help on %s:') File "/home/heimes/dev/python/p3yk/Lib/pydoc.py", line 1477, in doc desc = describe(object) File "/home/heimes/dev/python/p3yk/Lib/pydoc.py", line 1436, in describe if type(thing) is types.InstanceType: AttributeError: 'module' object has no attribute 'InstanceType' -- >Comment By: Georg Brandl (gbrandl) Date: 2007-04-11 19:25 Message: Logged In: YES user_id=849994 Originator: NO Fixed all instances of types.InstanceType in rev. 54761. -- Comment By: Christian Heimes (tiran) Date: 2007-04-11 13:52 Message: Logged In: YES user_id=560817 Originator: YES types.InstanceType is still used by several stdlib modules. FIX: svn cp the types.py module from Python 2.6 to the p3yk branh -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697782&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1697916 ] Segfaults on memory error
Bugs item #1697916, was opened at 2007-04-10 19:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697916&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 >Status: Open Resolution: None Priority: 6 Private: No Submitted By: STINNER Victor (haypo) >Assigned to: Georg Brandl (gbrandl) Summary: Segfaults on memory error Initial Comment: Hi, I'm playing with resource.setrlimit(resource.RLIMIT_AS) to limit memory usage during fuzzing tests. It works quite well but Python crashs sometimes (with SEGFAULT). I downloaded Python source code and recompiled it with EXTRA_FLAGS="-g -O0" to find errors. I found three bugs and wrote a patch for all of them. Comments: * Objects/exceptions.c:33: allocation may returns NULL on memory error * Objects/longobject.c:2511: long_divrem() may allocate new long integers but l_divmod() doesn't check that div and mod are not NULL * Objects/object.c:1284: problem with NULL mro. I don't understand how mro works, but I think that the error may be catched when mro is assigned. Problem: where is it done? in Objects/typeobject.c? So don't apply my patch directly: fix for object.c may be wrong. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-04-11 20:11 Message: Logged In: YES user_id=849994 Originator: NO Reopening until I can backport this to the 2.5 branch. -- Comment By: STINNER Victor (haypo) Date: 2007-04-11 16:53 Message: Logged In: YES user_id=365388 Originator: YES Ignore my bug about NULL mro since i'm not able to reproduce it. Thanks for the 3 other fixes ;-) -- Comment By: Georg Brandl (gbrandl) Date: 2007-04-11 16:11 Message: Logged In: YES user_id=849994 Originator: NO Status update: Fixed the first two bugs locally, and a third one discovered by Victor on #python-dev. The mro one is unclear -- we've asked him to reproduce it and poke around in gdb to see why tp_mro is NULL, which it shouldn't be. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697916&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1697782 ] types.InstanceType is missing but used by pydoc
Bugs item #1697782, was opened at 2007-04-10 15:55 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697782&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 3000 >Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Christian Heimes (tiran) >Assigned to: Georg Brandl (gbrandl) Summary: types.InstanceType is missing but used by pydoc Initial Comment: >>> help(callable.__call__) Traceback (most recent call last): File "", line 1, in File "/home/heimes/dev/python/p3yk/Lib/site.py", line 348, in __call__ return pydoc.help(*args, **kwds) File "/home/heimes/dev/python/p3yk/Lib/pydoc.py", line 1658, in __call__ self.help(request) File "/home/heimes/dev/python/p3yk/Lib/pydoc.py", line 1702, in help else: doc(request, 'Help on %s:') File "/home/heimes/dev/python/p3yk/Lib/pydoc.py", line 1477, in doc desc = describe(object) File "/home/heimes/dev/python/p3yk/Lib/pydoc.py", line 1436, in describe if type(thing) is types.InstanceType: AttributeError: 'module' object has no attribute 'InstanceType' -- >Comment By: Georg Brandl (gbrandl) Date: 2007-04-11 20:11 Message: Logged In: YES user_id=849994 Originator: NO Reopening until I can backport this to the 2.5 branch. -- Comment By: Georg Brandl (gbrandl) Date: 2007-04-11 19:25 Message: Logged In: YES user_id=849994 Originator: NO Fixed all instances of types.InstanceType in rev. 54761. -- Comment By: Christian Heimes (tiran) Date: 2007-04-11 13:52 Message: Logged In: YES user_id=560817 Originator: YES types.InstanceType is still used by several stdlib modules. FIX: svn cp the types.py module from Python 2.6 to the p3yk branh -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697782&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1621111 ] IDLE crashes on OS X 10.4 when "Preferences" selected
Bugs item #162, was opened at 2006-12-23 05:03 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=162&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 6 Private: No Submitted By: Mick L (mehum) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: IDLE crashes on OS X 10.4 when "Preferences" selected Initial Comment: When I select 'preferences' (on IDLE 1.2, Python 2.5) or 'Configure IDLE' (IDLE 1.1.4, Python 2.4.4 and IDLE 1.0, Python 2.3.3), Python crashes as soon as the dialog box appears. Terminal reports a "Segmentation fault" upon the crash. My system is an iMac G5 with 1 GB ram running OS X v 10.4.8, Tcl/Tk 8.4.10, and seems otherwise stable. IDLE also appears stable until I select this option. The Python crash log is attached. Please, can anyone suggest what may be causing this problem? Thank you. -- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-04-11 22:24 Message: Logged In: YES user_id=580910 Originator: NO It seems to be caused by Tcl/Tk, I cannot reproduce this with the system version of Tk This is on 10.4.8/intel, with python 2.5.1rc1. I don't think the change in python version fixes this issue. Mick: could you please test what happens when you temporarily move /Library/Frameworks/Tcl.framework and /Library/Frameworks/Tk.framework to another folder. -- Comment By: Raymond Hettinger (rhettinger) Date: 2007-04-11 19:12 Message: Logged In: YES user_id=80475 Originator: NO Bumping up the priority so this doesn't get lost. My guess is that IDLE is tickling some problem with the TkInter bindings. -- Comment By: François Scholder (f_scholder) Date: 2007-02-02 22:55 Message: Logged In: YES user_id=1609867 Originator: NO Erratum: A similar problem arises with WinXP when trying to configure IDLE via the "Options>Configure IDLE..." menu. Clicking on the 'Ok' or 'Apply' buttons of the dialog seemingly has no effect. However when closing the window by clicking on either the window close button (top right 'X') or the 'Cancel' button, several bahaviors are observed depending on how many times one has clicked on the 'Ok' and/or >'Apply'< buttons before: - 0 clicks => expected behavior (dialog is closed, IDLE session is resumed and working fine) - 1 or 2 clicks => dialog is closed but the IDLE shell behaves as a text editor instead of an interpreter - 3 or more clicks => IDLE crashes... Note: I'm running Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 -> WinXP SP2 -- Comment By: François Scholder (f_scholder) Date: 2007-02-02 22:48 Message: Logged In: YES user_id=1609867 Originator: NO A similar problem arises with WinXP when trying to configure IDLE via the "Options>Configure IDLE..." menu. Clicking on the 'Ok' or 'Apply' buttons of the dialog seemingly has no effect. However when closing the window by clicking on either the window close button (top right 'X') or the 'Cancel' button, several bahaviors are observed depending on how many times one has clicked on the 'Ok' and/or 'Cancel' buttons before: - 0 clicks => expected behavior (dialog is closed, IDLE session is resumed and working fine) - 1 or 2 clicks => dialog is closed but the IDLE shell behaves as a text editor instead of an interpreter - 3 or more clicks => IDLE crashes... Note: I'm running Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 -> WinXP SP2 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=162&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1697943 ] msgfmt cannot cope with BOM
Bugs item #1697943, was opened at 2007-04-10 22:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697943&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and Tools Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christoph Zwerschke (cito) Assigned to: Martin v. Löwis (loewis) Summary: msgfmt cannot cope with BOM Initial Comment: If a .po file has a BOM (byte order mark) at the beginning, as is often the case for utf-8 files created on Windows, msgfmt.py complines about a syntax error. The attached patch fixes this problem. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-04-12 00:13 Message: Logged In: YES user_id=21627 Originator: NO It's my code, but I will need to establish first whether it's a bug. That depends on what the PO specification says, and, if is it silent on the matter, what GNU gettext does. -- Comment By: Raymond Hettinger (rhettinger) Date: 2007-04-11 18:07 Message: Logged In: YES user_id=80475 Originator: NO Martin, is this your code? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697943&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1698398 ] wrong % of params for format string in ZipFile.printdir()
Bugs item #1698398, was opened at 2007-04-11 07:58
Message generated for change (Comment added) made by alanmcintyre
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1698398&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Szabolcs Berecz (szabihernyo)
Assigned to: Raymond Hettinger (rhettinger)
Summary: wrong % of params for format string in ZipFile.printdir()
Initial Comment:
In zipfile.py:448
date = "%d-%02d-%02d %02d:%02d:%02d" % zinfo.date_time
should be changed to
date = "%d-%02d-%02d %02d:%02d:%02d" % zinfo.date_time[:6]
checked with python2.[45] on windows and linux
>>> from zipfile import ZipFile
>>> from StringIO import StringIO
>>> s = StringIO()
>>> zf = ZipFile(s, 'w')
>>> zf.writestr('file.ext', '123')
>>> zf.printdir()
File Name Modified Size
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/zipfile.py", line 448, in printdir
date = "%d-%02d-%02d %02d:%02d:%02d" % zinfo.date_time
TypeError: int argument required
>>> zf.filelist[0].date_time
(2007, 4, 11, 13, 38, 58, 2, 101, 1)
>>>
--
Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-04-11 22:28
Message:
Logged In: YES
user_id=1115903
Originator: NO
Patches to fix this have been posted for 2.5 (#1698915) and 2.6 (#1698917)
--
Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-04-11 08:34
Message:
Logged In: YES
user_id=1115903
Originator: NO
The same problem appears to be present in 2.6 as well. The date_time
attribute of ZipInfo is a time.struct_time in 2.4 and 2.6 (I don't have 2.5
available to check at the moment), not a tuple. I'm assuming this could be
fixed by changing that line to:
date = "%d-%02d-%02d %02d:%02d:%02d" % tuple(zinfo.date_time)[:6]
At the moment I can't connect to the svn server; when I can I'll submit a
patch for the trunk and 2.5.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1698398&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-1193128 ] 'str'.translate(None) => identity translation
Feature Requests item #1193128, was opened at 2005-04-30 15:31 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1193128&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Bengt Richter (bokr) Assigned to: Raymond Hettinger (rhettinger) Summary: 'str'.translate(None) => identity translation Initial Comment: This feature would permit passing None as the first argument to str.translate in place of an identity translation table like ''.join([[chr(i) for i in xrange(256)]) This should be handy for deleting characters, e.g., as in s = s.translate(None, delchars) -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-04-11 23:13 Message: Logged In: YES user_id=80475 Originator: NO Done. See revision 54772. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1193128&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1678710 ] dead link in tkinter documentation
Bugs item #1678710, was opened at 2007-03-11 23:34 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678710&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Ben Collver (bencollver) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: dead link in tkinter documentation Initial Comment: On the following page, there is a dead link. http://www.python.org/doc/2.3.5/lib/node642.html The dead link is to the following URL. http://www.python.org/doc/2.3.5/lib/classes/ClassPacker.html -- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2007-04-12 00:56 Message: Logged In: YES user_id=3066 Originator: NO This has been fixed in more recent versions of the documentation. Version 2.3.x is no longer in maintenance; this won't be fixed for older versions; sorry. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678710&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1698944 ] dtdparser discards last line
Bugs item #1698944, was opened at 2007-04-11 22:44
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=1698944&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: L. Peter Deutsch (lpd)
Assigned to: Nobody/Anonymous (nobody)
Summary: dtdparser discards last line
Initial Comment:
The DTD parser in xml.parsers.xmlproc.dtdparser sometimes simply ignores the
last line of the input file. Here is the Python program I used to test it:
--begin
from xml.parsers.xmlproc.dtdparser import DTDParser,\
DTDConsumer, DTDConsumerPE
import tracer
def parse_dtd(dtd):
parser = DTDParser()
handler = DTDConsumerPE()
parser.set_dtd_consumer(handler)
parser.feed(dtd)
tracer.trace(DTDConsumer)
parse_dtd('''\
%score;
''')
--end
where the file t.dtd contained:
--begin
--end
The tracer package (my own code) indicated that the opus element was never
parsed. The same was true if I added a blank line after the %score; entity
reference. However, if I added *two* blank lines after the entity reference,
the element declaration *was* processed.
I would note that while the bug exists in the original xmlproc package (at
least in xmlproc 0.70, downloadable from
http://www.garshol.priv.no/download/software/xmlproc/), the bug does *not*
exist in the PyXML package (downloadable from
http://sourceforge.net/projects/pyxml).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1698944&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
