From report at bugs.python.org Thu Nov 1 16:24:57 2007
From: report at bugs.python.org (Kai)
Date: Thu, 01 Nov 2007 15:24:57 -0000
Subject: [New-bugs-announce] [issue1368] Bug tracker link in about tutorial
page is wrong
Message-ID: <1193930697.14.0.0930864012953.issue1368@psf.upfronthosting.co.za>
New submission from Kai:
http://docs.python.org/tut/about.html has instructions for submitting a
bug doc, but it points to the SourceForge tracker. Change the link to
point to http://bugs.pythong.org
----------
components: Documentation
messages: 57008
nosy: ksjohnson
severity: minor
status: open
title: Bug tracker link in about tutorial page is wrong
type: resource usage
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1368>
__________________________________
From report at bugs.python.org Thu Nov 1 16:26:35 2007
From: report at bugs.python.org (Kai)
Date: Thu, 01 Nov 2007 15:26:35 -0000
Subject: [New-bugs-announce] [issue1369] Reference to Python24 path in
Python 2.5 doc
Message-ID: <1193930795.47.0.130226414395.issue1369@psf.upfronthosting.co.za>
New submission from Kai:
In the second paragraph under 2.1 Invoking the Interpreter, it says on
Windows Python defaults to C:\Python24 . This should be C:\Python25 for
the 2.5 guide. The set path= command also needs to be changed to
C:\Python25.
http://docs.python.org/tut/node4.html
----------
components: Documentation
messages: 57009
nosy: ksjohnson
severity: minor
status: open
title: Reference to Python24 path in Python 2.5 doc
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1369>
__________________________________
From report at bugs.python.org Thu Nov 1 20:51:09 2007
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 01 Nov 2007 19:51:09 -0000
Subject: [New-bugs-announce] [issue1371] Two bsddb tests temporarily
commented out in py3k branch
Message-ID: <1193946669.52.0.205865214576.issue1371@psf.upfronthosting.co.za>
New submission from Guido van Rossum:
In Lib/bsddb/test/test_misc.py in the py3k branch I had to disable two
test in order to make progress on a mega-merge from the trunk.
The tests are test01_badpointer and test04_double_free_make_key_dbt. I
commented them out by inserting "## " in front of each line.
Can you please re-enable these tests and fix the code that currently
breaks then?
----------
assignee: gregory.p.smith
messages: 57031
nosy: gregory.p.smith, gvanrossum
priority: urgent
severity: urgent
status: open
title: Two bsddb tests temporarily commented out in py3k branch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1371>
__________________________________
From report at bugs.python.org Fri Nov 2 11:39:31 2007
From: report at bugs.python.org (Peter Weseloh)
Date: Fri, 02 Nov 2007 10:39:31 -0000
Subject: [New-bugs-announce] [issue1372] zlibmodule.c: int overflow in
PyZlib_decompress
Message-ID: <1193999971.29.0.358180724062.issue1372@psf.upfronthosting.co.za>
New submission from Peter Weseloh:
When I use zlib.decompress to decompress a string where the result would
be >1 GB I get
SystemError: Objects/stringobject.c:4089: bad argument to internal function
I tracked that down to an int overflow of r_strlen in PyZlib_decompress.
Using Py_ssize_t instead of int solved this for me (on 64bit Linux).
The patch is against
python/trunk/Modules/zlibmodule.c
Revision: 56476
Kind regards,
Peter
----------
components: Extension Modules
files: int_overflow.diff
messages: 57047
nosy: PeterW
severity: normal
status: open
title: zlibmodule.c: int overflow in PyZlib_decompress
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file8676/int_overflow.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1372>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: int_overflow.diff
Type: application/octet-stream
Size: 386 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071102/0c946def/attachment.obj
From report at bugs.python.org Fri Nov 2 13:46:28 2007
From: report at bugs.python.org (Adam Hupp)
Date: Fri, 02 Nov 2007 12:46:28 -0000
Subject: [New-bugs-announce] [issue1373] turn off socket timeout in
test_xmlrpc
Message-ID: <1194007588.59.0.396140192089.issue1373@psf.upfronthosting.co.za>
New submission from Adam Hupp:
The attached patch resolves the intermittent test_xmlrpc failures
reported by Neal Norwitz[0].
test_xmlrpc starts the XMLRPC server with a socket timeout. This puts
the socket into non-blocking mode which is incompatible with the use of
socket.makefile as used by SocketServer. To work around this the test
was specifically ignoring temporary read errors but the ignore was no
longer working.
The patch resolves this by removing the call to socket.settimeout and
the code to ignore temporary read errors.
I also had to change the `numrequests' parameter in
FailingServerTestCase from 2->1. This test case only makes a single
request per test (like the others) so numrequests=2 caused the test to hang.
[0]http://mail.python.org/pipermail/python-3000/2007-October/011073.html
----------
components: Tests
files: xmlrpc_nonblock.patch
messages: 57048
nosy: hupp
severity: normal
status: open
title: turn off socket timeout in test_xmlrpc
versions: Python 3.0
Added file: http://bugs.python.org/file8677/xmlrpc_nonblock.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1373>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xmlrpc_nonblock.patch
Type: application/octet-stream
Size: 7567 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071102/64f78236/attachment.obj
From report at bugs.python.org Fri Nov 2 19:27:42 2007
From: report at bugs.python.org (Tal Einat)
Date: Fri, 02 Nov 2007 18:27:42 -0000
Subject: [New-bugs-announce] [issue1374] IDLE - minor FormatParagraph bug fix
Message-ID: <1194028062.43.0.247471106942.issue1374@psf.upfronthosting.co.za>
New submission from Tal Einat:
The format_paragraph_event method was not returning "break", causing
unwanted side effects when called via a key binding.
----------
components: IDLE
files: IDLE_FormatParagraph.071102.patch
messages: 57060
nosy: kbk, taleinat
severity: normal
status: open
title: IDLE - minor FormatParagraph bug fix
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file8678/IDLE_FormatParagraph.071102.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1374>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IDLE_FormatParagraph.071102.patch
Type: application/octet-stream
Size: 385 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071102/d6d07374/attachment.obj
From report at bugs.python.org Fri Nov 2 20:17:01 2007
From: report at bugs.python.org (Ruben Reifenberg)
Date: Fri, 02 Nov 2007 19:17:01 -0000
Subject: [New-bugs-announce] [issue1375] hotshot IndexError when loading
stats
Message-ID: <1194031021.72.0.351195403989.issue1375@psf.upfronthosting.co.za>
New submission from Ruben Reifenberg:
Python 2.4.4 - 64 Bit
This code reproduceably fails with
IndexError: pop from empty list
def start(x):
x.start()
if __name__ == "__main__":
import hotshot
prof = hotshot.Profile("test3_stats")
start(prof)
#prof.start()
prof.stop()
prof.close()
from hotshot import stats
s = stats.load("test3_stats")
Note1: This issue may be identical with Issue1019882 (another situation
but same Error.)
Note2: Workaround exists: Replace the line "start(prof)" with
"prof.start()".
In this case, the resulting stats (binary) file is 1 Byte shorter, and
no error happens.
----------
components: Library (Lib)
messages: 57061
nosy: ratsberg
severity: minor
status: open
title: hotshot IndexError when loading stats
type: crash
versions: Python 2.4
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1375>
__________________________________
From report at bugs.python.org Sat Nov 3 00:13:53 2007
From: report at bugs.python.org (billiejoex)
Date: Fri, 02 Nov 2007 23:13:53 -0000
Subject: [New-bugs-announce] [issue1376] uu module catches a wrong exception
type
Message-ID: <1194045233.33.0.855077145409.issue1376@psf.upfronthosting.co.za>
New submission from billiejoex:
uu module on line 53 erroneously tries to catch an AttributeError
exception type.
try:
mode = os.stat(in_file).st_mode
except AttributeError:
pass
This is not correct since os.stat(), as far as I know, should raise
OSError exceptions only.
This would turn in an error in case we pass a "broken" symlink as
in_file argument.
----------
components: Library (Lib)
messages: 57077
nosy: billiejoex
severity: normal
status: open
title: uu module catches a wrong exception type
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376>
__________________________________
From report at bugs.python.org Sat Nov 3 00:45:03 2007
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 02 Nov 2007 23:45:03 -0000
Subject: [New-bugs-announce] [issue1377] test_import breaks on Linux
Message-ID: <1194047103.5.0.8046180758.issue1377@psf.upfronthosting.co.za>
New submission from Guido van Rossum:
Error output:
test_import at test/test????test test_import failed -- Traceback (most
recent call last): File
"/usr/local/google/home/guido/python/py3k-main/Lib/test/test_import.py",
line 184, in test_sys_path_with_unicode mod =
__import__("testimport%i" % i)ImportError: No module named testimport1
----------
assignee: tiran
messages: 57079
nosy: gvanrossum, tiran
severity: normal
status: open
title: test_import breaks on Linux
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1377>
__________________________________
From report at bugs.python.org Sat Nov 3 16:24:15 2007
From: report at bugs.python.org (roudkerk)
Date: Sat, 03 Nov 2007 15:24:15 -0000
Subject: [New-bugs-announce] [issue1378] fromfd() and dup() for _socket on
WIndows
Message-ID: <1194103455.44.0.390687208828.issue1378@psf.upfronthosting.co.za>
New submission from roudkerk:
The patch adds support for _socket.fromfd() and _socket.socket.dup() on
Windows. It uses the Win32 DuplicateHandle() function.
The patch is to socketmodule.c an test_socket.py.
----------
files: socket_fromfd.patch
messages: 57084
nosy: roudkerk
severity: normal
status: open
title: fromfd() and dup() for _socket on WIndows
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file8682/socket_fromfd.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1378>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: socket_fromfd.patch
Type: application/octet-stream
Size: 3915 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071103/58236311/attachment.obj
From report at bugs.python.org Sat Nov 3 17:51:43 2007
From: report at bugs.python.org (Paul Pogonyshev)
Date: Sat, 03 Nov 2007 16:51:43 -0000
Subject: [New-bugs-announce] [issue1379] reloading imported modules
sometimes fail with 'parent not in sys.modules' error
Message-ID: <1194108703.22.0.307056079238.issue1379@psf.upfronthosting.co.za>
New submission from Paul Pogonyshev:
This is apparently because sys.modules contains Unicode (str) keys,
while 'parentname' is an old-style string. Attached patch seems to fix
it, but I have no idea if it is correct in principle
----------
components: Interpreter Core
files: reloading-fix.diff
messages: 57085
nosy: Paul Pogonyshev
severity: normal
status: open
title: reloading imported modules sometimes fail with 'parent not in sys.modules' error
versions: Python 3.0
Added file: http://bugs.python.org/file8683/reloading-fix.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1379>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: reloading-fix.diff
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071103/6726e63a/attachment.txt
From report at bugs.python.org Sat Nov 3 19:06:42 2007
From: report at bugs.python.org (Adam Hupp)
Date: Sat, 03 Nov 2007 18:06:42 -0000
Subject: [New-bugs-announce] [issue1380] fix for test_asynchat and
test_asyncore on pep3137 branch
Message-ID: <1194113202.87.0.167615791843.issue1380@psf.upfronthosting.co.za>
New submission from Adam Hupp:
The attached patch resolves test failues in test_asynchat and
test_asyncore.
The asynchat failure was due to interpolating a byte string into a
unicode string using %s. This resulted in a b'' byte representation
in the final string. The fix is to use string constants instead of
byte constants. The result is encoded to bytes later on.
The asyncore failure was due to an explicit isinstance(data, bytes)
check on the result of recv. The actual type in this case was buffer.
I've removed the check since the next line calls
data.replace(b'\n', b'')
This all should fail for anything thats not a buffer or bytes.
----------
components: Library (Lib), Tests
files: pep3137-asynfix.patch
messages: 57086
nosy: hupp
severity: normal
status: open
title: fix for test_asynchat and test_asyncore on pep3137 branch
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8684/pep3137-asynfix.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1380>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pep3137-asynfix.patch
Type: application/octet-stream
Size: 1469 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071103/724dd10b/attachment.obj
From report at bugs.python.org Sat Nov 3 19:58:58 2007
From: report at bugs.python.org (Andreas Kloeckner)
Date: Sat, 03 Nov 2007 18:58:58 -0000
Subject: [New-bugs-announce] [issue1381] cmath is numerically unsound
Message-ID: <1194116338.25.0.15025018351.issue1381@psf.upfronthosting.co.za>
New submission from Andreas Kloeckner:
This here basically says it all:
>>> import cmath;[cmath.asinh(i*1e-17).real for i in range(0,20)]
[4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16,
4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16,
4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16,
4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16,
4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16,
4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16,
4.4408920985006257e-16, 4.4408920985006257e-16]
The boost.math toolkit at [2] is an implementation that does better in
the above (real-only) aspect.
[2] http://freespace.virgin.net/boost.regex/toolkit/html/index.html
Tim Peters remarks in [1] that basically all of cmath is unsound.
http://mail.python.org/pipermail/python-bugs-list/2001-February/004126.html
I just wanted to make sure that this issue remains on the radar.
----------
components: Library (Lib)
messages: 57088
nosy: inducer
severity: normal
status: open
title: cmath is numerically unsound
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1381>
__________________________________
From report at bugs.python.org Sun Nov 4 16:49:45 2007
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 04 Nov 2007 15:49:45 -0000
Subject: [New-bugs-announce] [issue1382] py3k-pep3137: patch for test_ctypes
Message-ID: <1194191385.34.0.481652970532.issue1382@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc:
This patch corrects test_ctypes in the py3k-pep3137 branch.
Replacing PyBytes_* by PyString_* was 99% of the task.
Also had to modify binascii, which used to return buffers instead of
bytes strings.
Tested on winXP.
----------
components: Tests
files: ctypes3.diff
messages: 57099
nosy: amaury.forgeotdarc, gvanrossum, tiran
severity: normal
status: open
title: py3k-pep3137: patch for test_ctypes
versions: Python 3.0
Added file: http://bugs.python.org/file8686/ctypes3.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1382>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ctypes3.diff
Type: application/octet-stream
Size: 15409 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071104/546b5895/attachment.obj
From report at bugs.python.org Sun Nov 4 19:35:29 2007
From: report at bugs.python.org (Benjamin Aranguren)
Date: Sun, 04 Nov 2007 18:35:29 -0000
Subject: [New-bugs-announce] [issue1383] Backport abcoll to 2.6
Message-ID: <1194201329.09.0.60972060799.issue1383@psf.upfronthosting.co.za>
New submission from Benjamin Aranguren:
Backported _abcoll.py and it's test to 2.6 including regrtest.py
----------
components: Library (Lib), Tests
files: abcoll_backport_to_2_6.patch
messages: 57103
nosy: baranguren
severity: normal
status: open
title: Backport abcoll to 2.6
versions: Python 2.6
Added file: http://bugs.python.org/file8687/abcoll_backport_to_2_6.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1383>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: abcoll_backport_to_2_6.patch
Type: application/octet-stream
Size: 39211 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071104/0e292d44/attachment-0001.obj
From report at bugs.python.org Sun Nov 4 19:44:55 2007
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 04 Nov 2007 18:44:55 -0000
Subject: [New-bugs-announce] [issue1384] Windows fix for inspect tests
Message-ID: <1194201895.98.0.637065940329.issue1384@psf.upfronthosting.co.za>
New submission from Christian Heimes:
The patch lower()s the file names on Windows. The tests break on my
system because C:\\... != c:\\...
----------
files: py3k_inspect.patch
keywords: patch, py3k
messages: 57105
nosy: tiran
severity: normal
status: open
title: Windows fix for inspect tests
versions: Python 3.0
Added file: http://bugs.python.org/file8688/py3k_inspect.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1384>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k_inspect.patch
Type: text/x-diff
Size: 2769 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071104/919c0601/attachment.patch
From report at bugs.python.org Sun Nov 4 19:52:00 2007
From: report at bugs.python.org (Joachim Wagner)
Date: Sun, 04 Nov 2007 18:52:00 -0000
Subject: [New-bugs-announce] [issue1385] hmac module violates RFC for some
hash functions, e.g. sha512
Message-ID: <1194202320.65.0.260919187967.issue1385@psf.upfronthosting.co.za>
New submission from Joachim Wagner:
(First time submitting a patch to this system.)
The hmac module uses a fixed blocksize of 64 bytes. This is fine for
many hash functions like md5, sha1 and sha256, but not for sha512 or
in the general case. The RFC referenced in the python documentation
specifies that the blocksize has to match the hash function. The
attached patch is the first of three proposed solutions:
1. use the undocumented block_size attribute of the hashing objects
provided in the hashlib modules and fallback to 64 bytes if the
attribute is missing (maybe a depreciated warning would be better); in
this case it would be a good idea to document to block_size attribute
(not included in the patch attached); performance could be improved by
making block_size a class attribute
2. document that the blocksize is 64 and that the RFC is only
correctly implemented if the hash function also has a blocksize of 64
bytes; optionally include the workaround to subclass hmac.HMAC and
overwrite the blocksize (this is documented in the source code, but
unfortunately not in the python docu)
3. make the blocksize a keyword argument to the constructor and
document that it has to match the hash function's blocksize for full
RFC compliance
Regards,
Joachim
----------
components: None
files: hmac_1.patch
messages: 57106
nosy: jowagner
severity: normal
status: open
title: hmac module violates RFC for some hash functions, e.g. sha512
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8689/hmac_1.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1385>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hmac_1.patch
Type: text/x-diff
Size: 652 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071104/d0875516/attachment.patch
From report at bugs.python.org Sun Nov 4 23:08:37 2007
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 04 Nov 2007 22:08:37 -0000
Subject: [New-bugs-announce] [issue1386] py3k-pep3137: patch to ensure that
all codecs return bytes
Message-ID: <1194214117.31.0.466476826392.issue1386@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc:
Most codecs return buffer objects, when the rule is now to return bytes.
This patch adds a test, and corrects failing codecs.
(more PyBytes_* -> PyString_* replacements)
----------
components: Unicode
files: codecs.diff
messages: 57109
nosy: amaury.forgeotdarc, tiran
severity: normal
status: open
title: py3k-pep3137: patch to ensure that all codecs return bytes
versions: Python 3.0
Added file: http://bugs.python.org/file8690/codecs.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1386>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: codecs.diff
Type: application/octet-stream
Size: 6692 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071104/813be2d3/attachment.obj
From report at bugs.python.org Sun Nov 4 23:12:53 2007
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 04 Nov 2007 22:12:53 -0000
Subject: [New-bugs-announce] [issue1387] py3k-pep3137: patch for hashlib on
Windows
Message-ID: <1194214373.18.0.782991994946.issue1387@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc:
On Windows, openssl is not always available, in this case python uses
its own implementation of md5, sha1 &co.
This patch correct the failing tests (test_hashlib and test_uuid), by
returning bytes instead of buffers.
----------
components: Windows
files: hashlib.diff
messages: 57110
nosy: amaury.forgeotdarc, tiran
severity: normal
status: open
title: py3k-pep3137: patch for hashlib on Windows
versions: Python 3.0
Added file: http://bugs.python.org/file8691/hashlib.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1387>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hashlib.diff
Type: application/octet-stream
Size: 1870 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071104/3ce05671/attachment.obj
From report at bugs.python.org Mon Nov 5 01:01:26 2007
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 05 Nov 2007 00:01:26 -0000
Subject: [New-bugs-announce] [issue1388] py3k-pep3137: possible ref leak in
ctypes
Message-ID: <1194220886.12.0.81605317037.issue1388@psf.upfronthosting.co.za>
New submission from Christian Heimes:
~/dev/python/py3k-pep3137$ ./python Lib/test/regrtest.py -R 3:5 test_ctypes
test_ctypes
beginning 8 repetitions
12345678
........
test_ctypes leaked [39, -31, 33, -33, 0] references, sum=8
1 test OK.
[101762 refs]
----------
assignee: theller
components: Library (Lib)
keywords: py3k
messages: 57113
nosy: theller, tiran
priority: normal
severity: normal
status: open
title: py3k-pep3137: possible ref leak in ctypes
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1388>
__________________________________
From report at bugs.python.org Mon Nov 5 01:16:54 2007
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 05 Nov 2007 00:16:54 -0000
Subject: [New-bugs-announce] [issue1389] py3k-pep3137: struct module is
leaking references
Message-ID: <1194221814.03.0.457201446889.issue1389@psf.upfronthosting.co.za>
New submission from Christian Heimes:
~/dev/python/py3k-pep3137$ ./python Lib/test/regrtest.py -R 2:4 test_struct
test_struct
beginning 6 repetitions
123456
......
test_struct leaked [12, 7, 20, 10] references, sum=49
1 test OK.
[65353 refs]
----------
components: Extension Modules
keywords: py3k
messages: 57114
nosy: tiran
priority: normal
severity: normal
status: open
title: py3k-pep3137: struct module is leaking references
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1389>
__________________________________
From report at bugs.python.org Mon Nov 5 01:58:05 2007
From: report at bugs.python.org (Thomas Conway)
Date: Mon, 05 Nov 2007 00:58:05 -0000
Subject: [New-bugs-announce] [issue1390] toxml generates output that is not
well formed
Message-ID: <1194224285.7.0.825321790392.issue1390@psf.upfronthosting.co.za>
Changes by Thomas Conway:
----------
components: Library (Lib)
nosy: drtomc
severity: normal
status: open
title: toxml generates output that is not well formed
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1390>
__________________________________
From report at bugs.python.org Mon Nov 5 02:49:58 2007
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 05 Nov 2007 01:49:58 -0000
Subject: [New-bugs-announce] [issue1391] Adds the .compact() method to bsddb
db.DB objects
Message-ID: <1194227398.84.0.43254190344.issue1391@psf.upfronthosting.co.za>
New submission from Gregory P. Smith:
I'm attaching the patch to add this method here just as a place to track
it for now. It compiles and it looks right, but it causes a crash
within BerkeleyDB when the test case runs using BerkeleyDB 4.6.21. It
passes as expected when using 4.4.20 or 4.5.20.
I won't commit this until the 4.6 crash issue is resolved.
python bindings for the compact method were requested here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1724985&group_id=13900&atid=363900
----------
assignee: gregory.p.smith
components: Extension Modules
files: add-bsddb-db_compact-gps01.patch.txt
keywords: patch, rfe
messages: 57116
nosy: gregory.p.smith
severity: normal
status: open
title: Adds the .compact() method to bsddb db.DB objects
versions: Python 2.6
Added file: http://bugs.python.org/file8693/add-bsddb-db_compact-gps01.patch.txt
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1391>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: add-bsddb-db_compact-gps01.patch.txt
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071105/d5278b78/attachment.txt
From report at bugs.python.org Mon Nov 5 15:22:51 2007
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 05 Nov 2007 14:22:51 -0000
Subject: [New-bugs-announce] [issue1392] py3k-pep3137: str(bytes()) and
str(buffer()) should raise TypeError patch
Message-ID: <1194272571.2.0.948157868786.issue1392@psf.upfronthosting.co.za>
New submission from Christian Heimes:
str(bytes()) == repr(bytes()) and str(buffer()) == repr(buffer()) is
causing a bunch bugs which are extremely hard to understand. On several
occasions I didn't understand the problem until I removed a str() call
or made str(bytes()) and str(buffer()) raise an exception.
----------
assignee: gvanrossum
components: Interpreter Core
files: py3k-pep3137_remove_str_bytes.patch
keywords: patch, py3k
messages: 57124
nosy: gvanrossum, tiran
priority: high
severity: normal
status: open
title: py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8694/py3k-pep3137_remove_str_bytes.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1392>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k-pep3137_remove_str_bytes.patch
Type: text/x-diff
Size: 3719 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071105/2c8d55c7/attachment.patch
From report at bugs.python.org Mon Nov 5 21:40:45 2007
From: report at bugs.python.org (Paul Pogonyshev)
Date: Mon, 05 Nov 2007 20:40:45 -0000
Subject: [New-bugs-announce] [issue1393] function comparing lacks
NotImplemented error
Message-ID: <1194295245.65.0.45134369314.issue1393@psf.upfronthosting.co.za>
New submission from Paul Pogonyshev:
I believe attached script demonstrates a bug in Python 3000. As far as
I can tell, it should print four times 'True'.
----------
components: Interpreter Core
files: test.py
messages: 57135
nosy: Paul Pogonyshev
severity: normal
status: open
title: function comparing lacks NotImplemented error
versions: Python 3.0
Added file: http://bugs.python.org/file8698/test.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1393>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.py
Type: text/x-python
Size: 241 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071105/36b93137/attachment.py
From report at bugs.python.org Mon Nov 5 23:09:01 2007
From: report at bugs.python.org (Paul Pogonyshev)
Date: Mon, 05 Nov 2007 22:09:01 -0000
Subject: [New-bugs-announce] [issue1394] simple patch,
improving unreachable bytecode removing
Message-ID: <1194300541.67.0.109986222934.issue1394@psf.upfronthosting.co.za>
New submission from Paul Pogonyshev:
This patch improves bytecode output, by removing unreachable code. It
doesn't target special cases, as now, but provides a generic implementation.
----------
components: Interpreter Core
files: unreachable-code.diff
messages: 57141
nosy: Paul Pogonyshev
severity: minor
status: open
title: simple patch, improving unreachable bytecode removing
versions: Python 2.6
Added file: http://bugs.python.org/file8699/unreachable-code.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1394>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unreachable-code.diff
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071105/fc6bed03/attachment.txt
From report at bugs.python.org Tue Nov 6 01:21:36 2007
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 06 Nov 2007 00:21:36 -0000
Subject: [New-bugs-announce] [issue1395] py3k: duplicated line endings when
using read(1)
Message-ID: <1194308496.75.0.337158380504.issue1395@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc:
When reading a Windows text file one byte at a time, \r\n get split into
two function calls, and the user receives two \n.
The following test fails (put it somewhere in test_io.py, inside
TextIOWrapperTest for example)
def testReadOneByOne(self):
txt = io.TextIOWrapper(io.BytesIO(b"AA\r\nBB"))
reads = ""
while True:
c = txt.read(1)
if not c:
break
reads += c
self.assertEquals(reads, "AA\nBB")
# AssertionError: 'AA\n\nBB' != 'AA\nBB'
Note that replacing read(1) by read(2) gives the correct result.
This problem is why test_netrc fails on Windows. It may also be the root
cause for issue 1142 (when \r\n position is just a multiple of the
_CHUNK_SIZE).
It also possible that the correction to this problem will have good
effects on test_mailbox, which uses tell() and seek() intensively.
----------
messages: 57147
nosy: amaury.forgeotdarc, gvanrossum, tiran
severity: normal
status: open
title: py3k: duplicated line endings when using read(1)
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1395>
__________________________________
From report at bugs.python.org Tue Nov 6 12:37:59 2007
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 06 Nov 2007 11:37:59 -0000
Subject: [New-bugs-announce] [issue1396] py3k-pep3137: patch for mailbox
Message-ID: <1194349078.97.0.791611531221.issue1396@psf.upfronthosting.co.za>
New submission from Christian Heimes:
Hi Yhg1s!
svn praise shows your name for Lib/mailbox.py more often then other
names. Can you look at my patch and see if it's correct? It fixes most
of the errors in test_mailbox.py and all tests in test_old_mailbox. I'm
unsure about the patch.
Crys
----------
assignee: twouters
components: Library (Lib)
files: py3k-pep3137_fix_mailbox.patch
keywords: patch, py3k
messages: 57158
nosy: tiran, twouters
priority: normal
severity: normal
status: open
title: py3k-pep3137: patch for mailbox
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8702/py3k-pep3137_fix_mailbox.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1396>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k-pep3137_fix_mailbox.patch
Type: text/x-diff
Size: 1603 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071106/31ebcd8e/attachment.patch
From report at bugs.python.org Tue Nov 6 13:29:24 2007
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 06 Nov 2007 12:29:24 -0000
Subject: [New-bugs-announce] [issue1397] py3k-pep3137: failing unit test
test_bsddb
Message-ID: <1194352164.91.0.707733802252.issue1397@psf.upfronthosting.co.za>
New submission from Christian Heimes:
Exception in thread writer 2:
Traceback (most recent call last):
File "/home/heimes/dev/python/py3k-pep3137/Lib/threading.py", line
485, in _bootstrap_inner
self.run()
File "/home/heimes/dev/python/py3k-pep3137/Lib/threading.py", line
445, in run
self._target(*self._args, **self._kwargs)
File
"/home/heimes/dev/python/py3k-pep3137/Lib/bsddb/test/test_thread.py",
line 80, in writerThread
self._writerThread(*args, **kwargs)
File
"/home/heimes/dev/python/py3k-pep3137/Lib/bsddb/test/test_thread.py",
line 254, in _writerThread
self.assertEqual(data, self.makeData(key))
File "/home/heimes/dev/python/py3k-pep3137/Lib/unittest.py", line 325,
in failUnlessEqual
raise self.failureException(msg or '%r != %r' % (first, second))
AssertionError: None != b'2226-2226-2226-2226-2226'
Exception in thread writer 1:
Traceback (most recent call last):
File "/home/heimes/dev/python/py3k-pep3137/Lib/threading.py", line
485, in _bootstrap_inner
self.run()
File "/home/heimes/dev/python/py3k-pep3137/Lib/threading.py", line
445, in run
self._target(*self._args, **self._kwargs)
File
"/home/heimes/dev/python/py3k-pep3137/Lib/bsddb/test/test_thread.py",
line 80, in writerThread
self._writerThread(*args, **kwargs)
File
"/home/heimes/dev/python/py3k-pep3137/Lib/bsddb/test/test_thread.py",
line 269, in _writerThread
self.assertEqual(data, self.makeData(key))
File "/home/heimes/dev/python/py3k-pep3137/Lib/unittest.py", line 325,
in failUnlessEqual
raise self.failureException(msg or '%r != %r' % (first, second))
AssertionError: None != b'1007-1007-1007-1007-1007'
Exception in thread writer 0:
Traceback (most recent call last):
File "/home/heimes/dev/python/py3k-pep3137/Lib/threading.py", line
485, in _bootstrap_inner
self.run()
File "/home/heimes/dev/python/py3k-pep3137/Lib/threading.py", line
445, in run
self._target(*self._args, **self._kwargs)
File
"/home/heimes/dev/python/py3k-pep3137/Lib/bsddb/test/test_thread.py",
line 80, in writerThread
self._writerThread(*args, **kwargs)
File
"/home/heimes/dev/python/py3k-pep3137/Lib/bsddb/test/test_thread.py",
line 269, in _writerThread
self.assertEqual(data, self.makeData(key))
File "/home/heimes/dev/python/py3k-pep3137/Lib/unittest.py", line 325,
in failUnlessEqual
raise self.failureException(msg or '%r != %r' % (first, second))
AssertionError: None != b'0004-0004-0004-0004-0004'
Ubuntu Linux 7.10, i386, db 4.4.20
----------
components: Tests
keywords: py3k
messages: 57161
nosy: gvanrossum, tiran
priority: normal
severity: normal
status: open
title: py3k-pep3137: failing unit test test_bsddb
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1397>
__________________________________
From report at bugs.python.org Wed Nov 7 16:27:30 2007
From: report at bugs.python.org (Daniel)
Date: Wed, 07 Nov 2007 15:27:30 -0000
Subject: [New-bugs-announce] [issue1398] Can't pickle partial functions
Message-ID: <1194449250.48.0.936565568427.issue1398@psf.upfronthosting.co.za>
New submission from Daniel:
Creating a function using functools.partial results in a function which
cannot be pickled.
Attached is a small testcase.
----------
components: Library (Lib)
files: partial_bug.py
messages: 57200
nosy: danhs
severity: normal
status: open
title: Can't pickle partial functions
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file8705/partial_bug.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1398>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: partial_bug.py
Type: text/x-python
Size: 141 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071107/6c59084a/attachment.py
From report at bugs.python.org Wed Nov 7 18:52:18 2007
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Wed, 07 Nov 2007 17:52:18 -0000
Subject: [New-bugs-announce] [issue1399] XML codec
Message-ID: <1194457938.94.0.302802489446.issue1399@psf.upfronthosting.co.za>
New submission from Walter D?rwald:
The patch adds an XML codec. It implements encoding detection as
specified in http://www.w3.org/TR/2004/REC-xml-20040204/#sec-guessing
and supports externally specified encodings for both encoding and decoding.
----------
components: Unicode
files: diff.txt
keywords: patch
messages: 57211
nosy: doerwalter
severity: normal
status: open
title: XML codec
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file8707/diff.txt
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1399>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff.txt
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071107/589428ca/attachment-0001.txt
From report at bugs.python.org Wed Nov 7 19:36:11 2007
From: report at bugs.python.org (Wojciech Walczak)
Date: Wed, 07 Nov 2007 18:36:11 -0000
Subject: [New-bugs-announce] [issue1400] Py3k's print() flushing problem
Message-ID: <1194460571.16.0.187401389382.issue1400@psf.upfronthosting.co.za>
New submission from Wojciech Walczak:
py3k's print() is not flushing when the string's length is 1 byte long
and 'end' parameter is set to ''. Example:
>>> print('x',end='') # it should print 'x' but it does nothing
>>> print('') # we have to call second print() to get buffers flushed
x
>>>
The same thing happens when the string is empty and end's length is 1:
>>> print('',end='x') # it should print 'x' but it does nothing
>>> print('') # we have to call second print() to get buffers flushed
x
>>>
When there is more characters than one, print() is flushing allright
(despite of lack of a newline in the interpreter):
>>> print('x',end='y')
xy>>> print('xx',end='')
xx>>> print('',end='yy')
yy>>>
The same thing happens in scripts. Try this one as script:
-----------------
import time
print('xx',end='')
time.sleep(3)
print('x',end='')
time.sleep(3)
-----------------
First print() will flush immediately even though there is no newline
and flush is not called, while second print() will flush after second
sleep (because python is flushing buffers at the end of the script).
The conclusion is that print() is not flushing immediately when
string is 1 byte long, but when it is longer - then print() is
flushing even when there is no newline or flush was not called by the
programmer.
I guess print() should act in the same way for every string > 0 bytes
long instead of for every string > 1 byte long.
Any ideas where is the bug?
You can find Python-3000's mail list discussion about that bug here:
http://mail.python.org/pipermail/python-3000/2007-November/011191.html
Wojtek Walczak
----------
components: Build
messages: 57215
nosy: wojtekwalczak
severity: normal
status: open
title: Py3k's print() flushing problem
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1400>
__________________________________
From report at bugs.python.org Wed Nov 7 22:42:59 2007
From: report at bugs.python.org (Andres Riancho)
Date: Wed, 07 Nov 2007 21:42:59 -0000
Subject: [New-bugs-announce] [issue1401] urllib 302 POST
Message-ID: <1194471779.09.0.301126280852.issue1401@psf.upfronthosting.co.za>
New submission from Andres Riancho:
There is an error in urllib2 when doing a POST request to a URI that
responds with a 302 redirection. The problem is in urllib2.py:536, where
the HTTPRedirectHandler creates the new Request based on the original one:
newurl = newurl.replace(' ', '%20')
return Request(newurl,
headers=req.headers,
origin_req_host=req.get_origin_req_host(),
unverifiable=True)
The issue is that when it creates the new request, it uses the old
headers (which contain a content-length header, remember that we
originally sent a POST!) but doesn't use the same post-data from the
original request (in fact it doesn't use any post-data). So, when the
new request is sent, urllib2 sends something like:
====START Request=====
GET http://f00/1.php HTTP/1.1
Content-length: 63
Accept-encoding: identity
Accept: */*
User-agent: w3af.sourceforge.net
Host: f00
Content-type: application/x-www-form-urlencoded
==== END REQUEST ===
The server waits some time for the post-data that is advertised in
"Content-length: 63" but it never arrives, so the connection is closed
and urllib2 timeouts.
There are two different solutions to this issue, implementing one is
enough to solve it:
1) when creating the new request, remove the content length header
2) when creating the new request, add the post-data of the old request
I think that the solution 1) is the most RFC-compliant solution. I coded
a small patch for urllib2.py of python2.5 that solves this issue, the
patch simply adds a line that removes the cl header:
newurl = newurl.replace(' ', '%20')
req.headers.pop('content-length')
return Request(newurl,
headers=req.headers,
origin_req_host=req.get_origin_req_host(),
unverifiable=True)
----------
components: None
messages: 57223
nosy: andresriancho
severity: minor
status: open
title: urllib 302 POST
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1401>
__________________________________
From report at bugs.python.org Wed Nov 7 23:05:52 2007
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 07 Nov 2007 22:05:52 -0000
Subject: [New-bugs-announce] [issue1402] Interpreter cleanup: order of
_PyGILState_Fini and PyInterpreterState_Clear
Message-ID: <1194473152.44.0.739478133219.issue1402@psf.upfronthosting.co.za>
New submission from Ronald Oussoren:
Py_Finalize cleans up the thread state by first calling _PyGILState_Fini
and then calling PyInterpreterState_Clear. The latter can cause user
code to run, which could use the GILState API and this then causes a
crash.
The attached file 'threads.py' causes a crash on OSX leopard because of
this issue. The script causes an exception to be set that has an
attribute that uses the GILState API in its dealloc slot.
----------
components: Interpreter Core
files: threads.py
messages: 57225
nosy: ronaldoussoren
priority: normal
severity: normal
status: open
title: Interpreter cleanup: order of _PyGILState_Fini and PyInterpreterState_Clear
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file8710/threads.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1402>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: threads.py
Type: text/x-python-script
Size: 650 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071107/0f53cce9/attachment.bin
From report at bugs.python.org Thu Nov 8 15:01:08 2007
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 08 Nov 2007 14:01:08 -0000
Subject: [New-bugs-announce] [issue1403] io or codecs bug in
codecs.getincrementaldecoder
Message-ID: <1194530468.74.0.0933952267806.issue1403@psf.upfronthosting.co.za>
New submission from Christian Heimes:
$ ./python Lib/compileall.py
Listing /home/heimes/dev/python/py3k/Lib ...
Compiling /home/heimes/dev/python/py3k/Lib/pydoc.py ...
Traceback (most recent call last):
File "Lib/compileall.py", line 162, in <module>
exit_status = int(not main())
File "Lib/compileall.py", line 155, in main
success = compile_path()
File "Lib/compileall.py", line 110, in compile_path
force, quiet=quiet)
File "Lib/compileall.py", line 65, in compile_dir
ok = py_compile.compile(fullname, None, dfile, True)
File "/home/heimes/dev/python/py3k/Lib/py_compile.py", line 137, in
compile
codestring = f.read()
File "/home/heimes/dev/python/py3k/Lib/io.py", line 1243, in read
decoder = self._decoder or self._get_decoder()
File "/home/heimes/dev/python/py3k/Lib/io.py", line 1132, in _get_decoder
make_decoder = codecs.getincrementaldecoder(self._encoding)
File "/home/heimes/dev/python/py3k/Lib/codecs.py", line 951, in
getincrementaldecoder
decoder = lookup(encoding).incrementaldecoder
LookupError: unknown encoding: b'Latin-1'
----------
components: Library (Lib)
keywords: py3k
messages: 57244
nosy: tiran
priority: high
severity: normal
status: open
title: io or codecs bug in codecs.getincrementaldecoder
type: crash
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1403>
__________________________________
From report at bugs.python.org Thu Nov 8 15:02:42 2007
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 08 Nov 2007 14:02:42 -0000
Subject: [New-bugs-announce] [issue1404] warnings module bug: BytesWarning:
str() on a bytes instance
Message-ID: <1194530562.67.0.490755632259.issue1404@psf.upfronthosting.co.za>
New submission from Christian Heimes:
$ ./python -bb Lib/compileall.py
Listing /home/heimes/dev/python/py3k/Lib ...
Compiling /home/heimes/dev/python/py3k/Lib/pydoc.py ...
Traceback (most recent call last):
File "Lib/compileall.py", line 162, in <module>
exit_status = int(not main())
File "Lib/compileall.py", line 155, in main
success = compile_path()
File "Lib/compileall.py", line 110, in compile_path
force, quiet=quiet)
File "Lib/compileall.py", line 65, in compile_dir
ok = py_compile.compile(fullname, None, dfile, True)
File "/home/heimes/dev/python/py3k/Lib/py_compile.py", line 131, in
compile
encoding = read_encoding(file, "utf-8")
File "/home/heimes/dev/python/py3k/Lib/py_compile.py", line 91, in
read_encoding
return str(m.group(1))
File "/home/heimes/dev/python/py3k/Lib/warnings.py", line 62, in warn
globals)
File "/home/heimes/dev/python/py3k/Lib/warnings.py", line 102, in
warn_explicit
raise message
BytesWarning: str() on a bytes instance
----------
assignee: tiran
components: Library (Lib)
keywords: patch
messages: 57245
nosy: tiran
priority: high
severity: normal
status: open
title: warnings module bug: BytesWarning: str() on a bytes instance
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1404>
__________________________________
From report at bugs.python.org Thu Nov 8 17:31:30 2007
From: report at bugs.python.org (Stefan Sonnenberg-Carstens)
Date: Thu, 08 Nov 2007 16:31:30 -0000
Subject: [New-bugs-announce] [issue1405] Garbage collection not working
correctly in Python 2.3
Message-ID: <1194539490.65.0.919114363971.issue1405@psf.upfronthosting.co.za>
New submission from Stefan Sonnenberg-Carstens:
when running this script:
aList = []
for i in xrange(5E5):
aList += [[]]
for j in xrange(10):
aList[-1].append([])
del aList
It does not give back the memory
even a
import gc
gc.collect()
afterwards does not do it.
In Python 2.5 the memory is freed again correctly, at least under Windows.
The problem came up, because I was parsing a CSV file of 50 MB which
resulted in memory usage of more than 500 MB.
----------
components: Interpreter Core
messages: 57256
nosy: pythonmeister
severity: urgent
status: open
title: Garbage collection not working correctly in Python 2.3
type: resource usage
versions: Python 2.3
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1405>
__________________________________
From report at bugs.python.org Thu Nov 8 18:38:31 2007
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 08 Nov 2007 17:38:31 -0000
Subject: [New-bugs-announce] [issue1406] Use widechar api for os.environ
Message-ID: <1194543511.82.0.106464214101.issue1406@psf.upfronthosting.co.za>
New submission from Thomas Heller:
This patch uses the windows widechar apis for os.environ. In this way,
environment variables that use umlauts can be accessed.
----------
components: Interpreter Core, Windows
files: posixmodule.c.diff
keywords: patch, py3k
messages: 57265
nosy: theller
severity: normal
status: open
title: Use widechar api for os.environ
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8715/posixmodule.c.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1406>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: posixmodule.c.diff
Type: text/x-diff
Size: 3033 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071108/545d8802/attachment.diff
From report at bugs.python.org Thu Nov 8 21:30:33 2007
From: report at bugs.python.org (Wojciech Walczak)
Date: Thu, 08 Nov 2007 20:30:33 -0000
Subject: [New-bugs-announce] [issue1407] [performance] Too many closed()
checkings
Message-ID: <1194553833.1.0.901439748582.issue1407@psf.upfronthosting.co.za>
New submission from Wojciech Walczak:
For debugging reasons I have added a simple line to PyObject_Call()
function in Objects/abstract.c:
printf("%s.%s\n", func->ob_type->tp_name, PyEval_GetFuncName(func));
Now, after compiling python and running interpreter with simple
print() call I receive this:
Python 3.0a1 (py3k, Nov 6 2007, 19:25:33)
[GCC 4.1.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print('!',end='')
builtin_function_or_method.print
method.write
function.write
function.closed
function.closed
builtin_function_or_method.ascii_encode
function.closed
function.closed
!method.write # here it goes again for 'end' parameter
function.write
function.closed
function.closed
builtin_function_or_method.ascii_encode
function.closed
builtin_function_or_method.displayhook
>>>
Note that there can be something going on between one function.closed
and the next one, because not every piece of code gets called by
PyObject_Call(), but still - isn't it checking if stream is closed a
bit too often?
Regards,
Wojtek Walczak
----------
components: Build
messages: 57275
nosy: wojtekwalczak
severity: minor
status: open
title: [performance] Too many closed() checkings
type: resource usage
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1407>
__________________________________
From report at bugs.python.org Thu Nov 8 21:59:21 2007
From: report at bugs.python.org (beco)
Date: Thu, 08 Nov 2007 20:59:21 -0000
Subject: [New-bugs-announce] [issue1408] Inconsistence in multiply list
Message-ID: <1194555561.37.0.908448311381.issue1408@psf.upfronthosting.co.za>
Changes by beco:
----------
components: Interpreter Core
nosy: beco
severity: major
status: open
title: Inconsistence in multiply list
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1408>
__________________________________
From report at bugs.python.org Thu Nov 8 22:00:02 2007
From: report at bugs.python.org (Paul Pogonyshev)
Date: Thu, 08 Nov 2007 21:00:02 -0000
Subject: [New-bugs-announce] [issue1409] new keyword-only function
parameters interact badly with nested functions
Message-ID: <1194555602.57.0.256813335387.issue1409@psf.upfronthosting.co.za>
New submission from Paul Pogonyshev:
Attached scripts fails with 'NameError: free variable 'a' referenced
before assignment in enclosing scope'. If you remove '*' in function
parameter list, it works. I think it is a bug.
----------
components: Interpreter Core
files: test.py
messages: 57277
nosy: _doublep
severity: normal
status: open
title: new keyword-only function parameters interact badly with nested functions
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8716/test.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1409>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.py
Type: text/x-python
Size: 191 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071108/e102fc99/attachment.py
From report at bugs.python.org Fri Nov 9 00:13:40 2007
From: report at bugs.python.org (J. Peterson)
Date: Thu, 08 Nov 2007 23:13:40 -0000
Subject: [New-bugs-announce] [issue1410] BaseHTTPServer cannot accept
Unicode data
Message-ID: <1194563620.66.0.0649109555228.issue1410@psf.upfronthosting.co.za>
Changes by J. Peterson:
----------
components: Library (Lib)
nosy: isonno
severity: normal
status: open
title: BaseHTTPServer cannot accept Unicode data
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1410>
__________________________________
From report at bugs.python.org Fri Nov 9 05:35:58 2007
From: report at bugs.python.org (Jeong-Min Lee)
Date: Fri, 09 Nov 2007 04:35:58 -0000
Subject: [New-bugs-announce] [issue1411] A typo in tutorial
Message-ID: <1194582958.24.0.143724736066.issue1411@psf.upfronthosting.co.za>
New submission from Jeong-Min Lee:
In the middle of "3.1.4 Lists", it reads as follow
-----
>>> a
[]
The built-in function len() also applies to lists:
>>> len(a)
8
-----
but it should be ..
-----
>>> a
[]
The built-in function len() also applies to lists:
>>> len(a)
0
-----
http://docs.python.org/tut/node5.html#SECTION005140000000000000000
----------
components: Documentation
messages: 57295
nosy: falsetru
severity: urgent
status: open
title: A typo in tutorial
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1411>
__________________________________
From report at bugs.python.org Fri Nov 9 14:30:50 2007
From: report at bugs.python.org (Denes Vadasz)
Date: Fri, 09 Nov 2007 13:30:50 -0000
Subject: [New-bugs-announce] [issue1412] test_subprocess fails on SuSE 10
Message-ID: <1194615050.49.0.894512947633.issue1412@psf.upfronthosting.co.za>
New submission from Denes Vadasz:
I compiled Python 2.5.1 on SuSE 10 and ran "make test", which reported
test_subprocess.py to fail on lines 537 and 579 with "permission
denied".
After a short investigation it looks the problem is that in SuSE 10 the
shell (bash) rejects to execute scripts residing in the /tmp directory
even if the file permissions would allow that.
An easy way of fixing this could be to place the shell script
statically in the same directory as test_subprocess.py instead of
creating it on-the-fly in /tmp.
----------
components: Tests
messages: 57301
nosy: dvadasz
severity: normal
status: open
title: test_subprocess fails on SuSE 10
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1412>
__________________________________
From report at bugs.python.org Fri Nov 9 15:43:27 2007
From: report at bugs.python.org (=?utf-8?q?Michal_Bo=C5=BEo=C5=88?=)
Date: Fri, 09 Nov 2007 14:43:27 -0000
Subject: [New-bugs-announce] [issue1413] int literal methods inaccessible
Message-ID: <1194619407.27.0.40025808387.issue1413@psf.upfronthosting.co.za>
New submission from Michal Bo?o?:
It's impossible to call methods of int literals directly e.g.
1.__str__() (the same for oct literals).
Even through it works for float, hex, literals, etc..
>>> 0x1.__str__()
'1'
>>> 1e0.__str__()
'1.0'
>>> 1..__str__()
'1.0'
>>> hasattr(1, '__str__')
True
>>> 1.__str__()
File "<stdin>", line 1
1.__str__()
^
SyntaxError: invalid syntax
>>> 01.__str__()
File "<stdin>", line 1
01.__str__()
^
SyntaxError: invalid syntax
----------
messages: 57304
nosy: mykhal
severity: normal
status: open
title: int literal methods inaccessible
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1413>
__________________________________
From report at bugs.python.org Fri Nov 9 16:17:05 2007
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 09 Nov 2007 15:17:05 -0000
Subject: [New-bugs-announce] [issue1414] Fix for refleak tests
Message-ID: <1194621425.79.0.958750228504.issue1414@psf.upfronthosting.co.za>
Changes by Christian Heimes:
----------
assignee: gvanrossum
keywords: patch, py3k
nosy: gvanrossum, tiran
priority: low
severity: normal
status: open
title: Fix for refleak tests
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1414>
__________________________________
From report at bugs.python.org Sat Nov 10 01:00:27 2007
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 10 Nov 2007 00:00:27 -0000
Subject: [New-bugs-announce] [issue1415] py3k: pythonw.exe fails to run
Message-ID: <1194652827.19.0.0139976447149.issue1415@psf.upfronthosting.co.za>
New submission from Christian Heimes:
pythonw.exe fails to run with a runtime error. python.exe works as
expected. While the bug itself isn't serious it should either be fixed
or pythonw.exe be omitted from the next alpha release.
----------
components: Windows
keywords: py3k
messages: 57342
nosy: tiran
priority: high
severity: major
status: open
title: py3k: pythonw.exe fails to run
type: crash
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1415>
__________________________________
From report at bugs.python.org Sat Nov 10 06:58:10 2007
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 10 Nov 2007 05:58:10 -0000
Subject: [New-bugs-announce] [issue1416] @prop.setter decorators
Message-ID: <1194674290.8.0.853140061818.issue1416@psf.upfronthosting.co.za>
New submission from Guido van Rossum:
Here's an implementation of the idea I floated recently on python-dev
(Subject: Declaring setters with getters). This implements the kind of
syntax that I believe won over most folks in the end:
@property
def foo(self): ...
@foo.setter
def foo(self, value=None): ...
There are also .getter and .deleter descriptors. This includes the hack
that if you specify a setter but no deleter, the setter is called
without a value argument when attempting to delete something. If the
setter isn't ready for this, a TypeError will be raised, pretty much
just as if no deleter was provided (just with a somewhat worse error
message :-).
I intend to check this into 2.6 and 3.0 unless there is a huge cry of
dismay. Docs will be left to volunteers as always.
----------
assignee: gvanrossum
files: propset.diff
keywords: patch
messages: 57345
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: @prop.setter decorators
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file8724/propset.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1416>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: propset.diff
Type: text/x-patch
Size: 3094 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071110/39147308/attachment.bin
From report at bugs.python.org Sat Nov 10 13:20:52 2007
From: report at bugs.python.org (MHOOO)
Date: Sat, 10 Nov 2007 12:20:52 -0000
Subject: [New-bugs-announce] [issue1417] Weakref not working properly
Message-ID: <1194697252.02.0.163162643165.issue1417@psf.upfronthosting.co.za>
New submission from MHOOO:
The following code is not working as expected:
import weakref
class cls1:
def giveTo( self, to ):
to.take( self.bla )
def bla(self ):
pass
class cls2:
def take( self, what ):
self.ref = weakref.ref(what)
c1 = cls1()
c2 = cls2()
c1.giveTo( c2 )
print c1.bla
print c2.ref
It prints out:
<bound method cls1.bla of <__main__.cls1 instance at 0x00CA9E18>>
<weakref at 00CAF180; dead>
Why is the weakref pointing to a dead object, when it's still alive?
----------
components: Library (Lib)
files: test2.py
messages: 57348
nosy: MHOOO
severity: major
status: open
title: Weakref not working properly
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file8725/test2.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1417>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test2.py
Type: text/x-python
Size: 252 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071110/b0785c7f/attachment.py
From report at bugs.python.org Sat Nov 10 16:07:51 2007
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 10 Nov 2007 15:07:51 -0000
Subject: [New-bugs-announce] [issue1418] Python/hypot.c is never used
Message-ID: <1194707271.84.0.598290243888.issue1418@psf.upfronthosting.co.za>
New submission from Mark Dickinson:
With the current ./configure setup, it looks to me as though there are
no circumstances under which the file Python/hypot.c is compliled.
There's a line
AC_REPLACE_FUNCS(hypot)
in configure.in; which is supposed (if I understand correctly) to check
for a system hypot(), and use the replacement file hypot.c if the system
hypot() isn't found; but the mechanism for using the replacement file
seems not to work: I tried the following:
(1) replace all occurrences of hypot with myhypot in configure.in,
pyport.h, complexobject.c, mathmodule.c and cmathmodule.c.
(2) move Python/hypot.c to Python/myhypot.c, and rename the function
contained within from hypot to myhypot
(3) rerun autoconf and autoheader
(4) ./configure && make
The result: as expected, during configuration I got:
checking for myhypot... no
but building failed with:
ar cr libpython2.6.a Objects/abstract.o Objects/boolobject.o Objects/
bufferobject.o Objects/cellobject.o Objects/classobject.o Objects/
cobject.o Objects/codeobject.o Objects/complexobject.o Objects/
descrobject.o Objects/enumobject.o Objects/exceptions.o Objects/
genobject.o Objects/fileobject.o Objects/floatobject.o Objects/
frameobject.o Objects/funcobject.o Objects/intobject.o Objects/
iterobject.o Objects/listobject.o Objects/longobject.o Objects/
dictobject.o Objects/methodobject.o Objects/moduleobject.o Objects/
object.o Objects/obmalloc.o Objects/rangeobject.o Objects/setobject.o
Objects/sliceobject.o Objects/stringobject.o Objects/structseq.o
Objects/tupleobject.o Objects/typeobject.o Objects/weakrefobject.o
Objects/unicodeobject.o Objects/unicodectype.o
ar cr libpython2.6.a Python/Python-ast.o Python/asdl.o Python/ast.o
Python/bltinmodule.o Python/ceval.o Python/compile.o Python/codecs.o
Python/errors.o Python/frozen.o Python/frozenmain.o Python/future.o
Python/getargs.o Python/getcompiler.o Python/getcopyright.o Python/
getmtime.o Python/getplatform.o Python/getversion.o Python/graminit.o
Python/import.o Python/importdl.o Python/marshal.o Python/modsupport.o
Python/mystrtoul.o Python/mysnprintf.o Python/peephole.o Python/
pyarena.o Python/pyfpe.o Python/pystate.o Python/pythonrun.o Python/
structmember.o Python/symtable.o Python/sysmodule.o Python/traceback.o
Python/getopt.o Python/pystrtod.o Python/dynload_shlib.o Python/
mactoolboxglue.o Python/thread.o
ar cr libpython2.6.a Modules/config.o Modules/getpath.o Modules/main.o
Modules/gcmodule.o
ar cr libpython2.6.a Modules/threadmodule.o Modules/signalmodule.o
Modules/posixmodule.o Modules/errnomodule.o Modules/pwdmodule.o
Modules/_sre.o Modules/_codecsmodule.o Modules/zipimport.o Modules/
symtablemodule.o Modules/xxsubtype.o
ranlib libpython2.6.a
gcc -L/opt/local/lib -u _PyMac_Error -o python.exe \
Modules/python.o \
libpython2.6.a -ldl
/usr/bin/ld: Undefined symbols:
_myhypot
(I'd like to know how to fix this: I've been working on fixing some of
the numerical problems in the cmath module, and hoped to imitate the
hypot setup for the functions log1p, asinh and copysign.)
----------
components: Build
messages: 57350
nosy: marketdickinson
severity: minor
status: open
title: Python/hypot.c is never used
versions: Python 2.5, Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1418>
__________________________________
From report at bugs.python.org Sun Nov 11 03:31:59 2007
From: report at bugs.python.org (Viktor Ferenczi)
Date: Sun, 11 Nov 2007 02:31:59 -0000
Subject: [New-bugs-announce] [issue1419] ssl module version 1.10 causes
TypeError when accepting connection
Message-ID: <1194748319.4.0.022602913069.issue1419@psf.upfronthosting.co.za>
New submission from Viktor Ferenczi:
The SSLSocket.accept() method passes arguments to SSLSocket's
constructor in wrong order which causes TypeError later in the
constructor. Proposed patch to ssl.__init__.py:
@@ -257,7 +257,7 @@
SSL channel, and the address of the remote client."""
newsock, addr = socket.accept(self)
- return (SSLSocket(newsock, True, self.keyfile, self.certfile,
+ return (SSLSocket(newsock, self.keyfile, self.certfile, True,
self.cert_reqs, self.ssl_version,
self.ca_certs, self.do_handshake_on_connect),
addr)
----------
components: Library (Lib)
messages: 57364
nosy: complex
severity: critical
status: open
title: ssl module version 1.10 causes TypeError when accepting connection
type: crash
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1419>
__________________________________
From report at bugs.python.org Sun Nov 11 15:32:56 2007
From: report at bugs.python.org (Ron Adam)
Date: Sun, 11 Nov 2007 14:32:56 -0000
Subject: [New-bugs-announce] [issue1420] Unicode literals in tokenize.py and
tests.
Message-ID: <1194791576.59.0.681140086087.issue1420@psf.upfronthosting.co.za>
New submission from Ron Adam:
Replaced Unicode literals in tokenize.py and it's tests files with byte
literals.
Added a compile step to the test to make sure the text file used in the
test are valid python code. This will catch changes that need to be
done in to the text (gold file) for future python versions.
----------
components: Library (Lib)
files: tokenize_patch.diff
messages: 57366
nosy: ron_adam
severity: normal
status: open
title: Unicode literals in tokenize.py and tests.
versions: Python 3.0
Added file: http://bugs.python.org/file8732/tokenize_patch.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1420>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tokenize_patch.diff
Type: text/x-patch
Size: 7723 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071111/5c07bd3f/attachment.bin
From report at bugs.python.org Sun Nov 11 15:37:08 2007
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 11 Nov 2007 14:37:08 -0000
Subject: [New-bugs-announce] [issue1421] python.org: outdated and false
information
Message-ID: <1194791828.05.0.091960180389.issue1421@psf.upfronthosting.co.za>
New submission from Christian Heimes:
Short of a bug tracker for errors on python.org I'm using this bug
tracker to support some problems.
http://www.python.org/dev/process/
"Documenting Python" still mentions LaTeX as the system for
documentation of Python.
http://www.python.org/dev/implementations/
"Python for .NET" is either describing a totally different project or
the author of the chapter didn't understand the design goals of Python
for .NET written by Brian Lloyd. It's a bridge between CPython and
.NET/Mono that allows developers to use CPython code and C extensions in
.NET or .NET assemblies in CPython. Compiling Python code to CLR / IL
byte code is not the intention of the project.
The project homepage is wrong (http://pythonnet.sourceforge.net/) and
the project is still maintained. I myself has fixed several bugs this
summer and ported it to Python 2.5, Python 2.6, UCS-4 builds of Python
and Mono.
----------
components: Documentation
messages: 57367
nosy: tiran
priority: high
severity: normal
status: open
title: python.org: outdated and false information
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1421>
__________________________________
From report at bugs.python.org Sun Nov 11 18:26:36 2007
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 11 Nov 2007 17:26:36 -0000
Subject: [New-bugs-announce] [issue1422] Writing to an invalid fd doesn't
raise an exception
Message-ID: <1194801996.44.0.296899248876.issue1422@psf.upfronthosting.co.za>
New submission from Christian Heimes:
The bug is related to http://bugs.python.org/issue1415 and occurs only
with the latest patch from #1415.
Writing to an invalid fd doesn't raise an exception:
>>> f = open(100, 'w')
>>> f.fileno()
100
>>> f.write("test")
4
However reading or opening an invalid fd for reading and writing raises
an exception.
>>> f = open(100, 'r')
>>> f.read()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/heimes/dev/python/py3k/Lib/io.py", line 1253, in read
res += decoder.decode(self.buffer.read(), True)
File "/home/heimes/dev/python/py3k/Lib/io.py", line 756, in read
current = self.raw.read(to_read)
IOError: [Errno 9] Bad file descriptor
>>> f = open(100, 'w+')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/heimes/dev/python/py3k/Lib/io.py", line 195, in __new__
return open(*args, **kwargs)
File "/home/heimes/dev/python/py3k/Lib/io.py", line 169, in open
buffer = BufferedRandom(raw, buffering)
File "/home/heimes/dev/python/py3k/Lib/io.py", line 948, in __init__
raw._checkSeekable()
File "/home/heimes/dev/python/py3k/Lib/io.py", line 301, in _checkSeekable
if msg is None else msg)
IOError: File or stream is not seekable.
I expected that fileio_write() raises an exception when fd is invalid:
n = write(self->fd, ptr, n);
if (n < 0) {
if (errno == EAGAIN)
Py_RETURN_NONE;
PyErr_SetFromErrno(PyExc_IOError);
return NULL;
}
----------
assignee: tiran
components: Interpreter Core
keywords: py3k
messages: 57372
nosy: tiran
priority: normal
severity: normal
status: open
title: Writing to an invalid fd doesn't raise an exception
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1422>
__________________________________
From report at bugs.python.org Sun Nov 11 21:15:28 2007
From: report at bugs.python.org (jeroen)
Date: Sun, 11 Nov 2007 20:15:28 -0000
Subject: [New-bugs-announce] [issue1423] wave sunau aifc 16bit errors
Message-ID: <1194812128.3.0.121145701122.issue1423@psf.upfronthosting.co.za>
New submission from jeroen:
When you write sound files wav sunau of aifc and you are using 16 bits
samples. The number of frames in the files is incorrect. close function
which updates the headers makes a mistake I assume. For the sunau type I
had to double the number of frames in the close function to make it correct.
If you do not correctg number of frames a 10 second file will play 5 seconds
----------
components: Library (Lib)
messages: 57377
nosy: jeroen
severity: normal
status: open
title: wave sunau aifc 16bit errors
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1423>
__________________________________
From report at bugs.python.org Sun Nov 11 21:54:45 2007
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 11 Nov 2007 20:54:45 -0000
Subject: [New-bugs-announce] [issue1424] py3k: readline and rlcompleter
doesn't list choices
Message-ID: <1194814485.68.0.898592111972.issue1424@psf.upfronthosting.co.za>
New submission from Christian Heimes:
Python 2.5:
>>> import readline; import rlcompleter; readline.parse_and_bind("tab:
complete")
>>> import sys
>>> sys.std<tab><tab>
sys.stderr sys.stdin sys.stdout
Python 3.0:
>>> import readline; import rlcompleter; readline.parse_and_bind("tab:
complete")
>>> import sys
>>> import sys.std<tab><tab>
# nothing
----------
components: Extension Modules, Library (Lib)
keywords: py3k
messages: 57378
nosy: tiran
priority: low
severity: normal
status: open
title: py3k: readline and rlcompleter doesn't list choices
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424>
__________________________________
From report at bugs.python.org Sun Nov 11 23:36:43 2007
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 11 Nov 2007 22:36:43 -0000
Subject: [New-bugs-announce] [issue1425] readline: no display matches hook
set
Message-ID: <1194820603.07.0.458448795039.issue1425@psf.upfronthosting.co.za>
New submission from Christian Heimes:
In Python 2.6 and 3.0 the readline module has changed. A new hook to set
a display matches was introduced but no default method is set thus
rendering rlcompleter partly useless.
----------
components: Extension Modules, Library (Lib)
keywords: py3k
messages: 57381
nosy: tiran
severity: normal
status: open
title: readline: no display matches hook set
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1425>
__________________________________
From report at bugs.python.org Sun Nov 11 23:44:08 2007
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 11 Nov 2007 22:44:08 -0000
Subject: [New-bugs-announce] [issue1426] readline module needs a review
Message-ID: <1194821048.12.0.233733442191.issue1426@psf.upfronthosting.co.za>
New submission from Christian Heimes:
The readline module needs a review and cleanup. Several functions don't
do enough error checks and the indention is partly borked with mixes of
tab and 2 space indention.
----------
keywords: py3k
messages: 57383
nosy: tiran
priority: high
severity: normal
status: open
title: readline module needs a review
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1426>
__________________________________
From report at bugs.python.org Mon Nov 12 00:16:40 2007
From: report at bugs.python.org (Damjan Georgievski)
Date: Sun, 11 Nov 2007 23:16:40 -0000
Subject: [New-bugs-announce] [issue1427] Error in standard module calendar
Message-ID: <1194823000.48.0.0016595238228.issue1427@psf.upfronthosting.co.za>
New submission from Damjan Georgievski:
This is LocaleTextCalendar.__init__
def __init__(self, firstweekday=0, locale=None):
TextCalendar.__init__(self, firstweekday)
if locale is None:
locale = locale.getdefaultlocale()
self.locale = locale
Which can not work, obviosly ... let me hilight the important part
if locale is None:
locale = locale.getdefaultlocale()
???
Attached is a patch that corrects this and keeps the signature of the
method with the locale=None keyword.
----------
components: Extension Modules
files: calendar.diff
messages: 57384
nosy: gdamjan
severity: normal
status: open
title: Error in standard module calendar
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file8734/calendar.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1427>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: calendar.diff
Type: application/octet-stream
Size: 620 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071111/9b337ed1/attachment.obj
From report at bugs.python.org Mon Nov 12 00:23:43 2007
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 11 Nov 2007 23:23:43 -0000
Subject: [New-bugs-announce] [issue1428] Update to property.__doc__
Message-ID: <1194823423.41.0.514895809101.issue1428@psf.upfronthosting.co.za>
New submission from Christian Heimes:
The patch adds the new syntax to the doc string of property:
Decorators makes defining new or modifying existing properties easy:
class C(object):
@property
def x(self): return self.__x
@x.setter
def x(self, value): self.__x = value
@x.deleter
def x(self): del self.__x
----------
assignee: gvanrossum
components: Interpreter Core
files: property_docstring.patch
keywords: patch
messages: 57385
nosy: gvanrossum, tiran
priority: low
severity: normal
status: open
title: Update to property.__doc__
type: rfe
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file8735/property_docstring.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1428>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: property_docstring.patch
Type: text/x-diff
Size: 826 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071111/a0dc3d21/attachment.patch
From report at bugs.python.org Mon Nov 12 13:27:34 2007
From: report at bugs.python.org (Luke-Jr)
Date: Mon, 12 Nov 2007 12:27:34 -0000
Subject: [New-bugs-announce] [issue1429] FD leak in SocketServer
Message-ID: <1194870454.07.0.621713310435.issue1429@psf.upfronthosting.co.za>
New submission from Luke-Jr:
SocketServer.ThreadingUnixStreamServer leaks file descriptors when a
request handler throws an exception.
----------
components: Library (Lib)
messages: 57396
nosy: luke-jr
severity: normal
status: open
title: FD leak in SocketServer
versions: Python 2.4
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1429>
__________________________________
From report at bugs.python.org Mon Nov 12 18:08:59 2007
From: report at bugs.python.org (David Barlow)
Date: Mon, 12 Nov 2007 17:08:59 -0000
Subject: [New-bugs-announce] [issue1430] Installing on Vista asks to close
Explorer (and Nokia PC Suite)
Message-ID: <1194887339.5.0.28485262025.issue1430@psf.upfronthosting.co.za>
New submission from David Barlow:
Version 2.5.1.
I'm trying to install Python on 32bit Vista Business. When I run the
MSI file it proceeds smoothly (well, apart from offering to install
to "c:\python..." instead of "c:\program files\python..."), and then
starts the install. It then tells me that I have to close down Explorer
(i.e. the shell!), and Nokia PC Suite 6.84.10.3. I could cope with the
latter, but I'm definitely not prepared to exit explorer. This seems a
bug/oversight in the installer. Is there any wat round it?
----------
components: Installation
messages: 57403
nosy: dabarlow
severity: normal
status: open
title: Installing on Vista asks to close Explorer (and Nokia PC Suite)
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1430>
__________________________________
From report at bugs.python.org Tue Nov 13 00:54:48 2007
From: report at bugs.python.org (Giambattista Bloisi)
Date: Mon, 12 Nov 2007 23:54:48 -0000
Subject: [New-bugs-announce] [issue1431] pth files not loaded at startup
Message-ID: <1194911688.74.0.067622667348.issue1431@psf.upfronthosting.co.za>
New submission from Giambattista Bloisi:
site.py ha two limitations that make difficult to use pth files on my
linux installation (gobolinux):
- it does not process pth files that are located in directories that are
already present in os.path at the time the main method is invoked
- it does not process directory recursively
Please find attached a patch that solves both. Basically known_paths
became a set representing the directories that have been processed.
Duplicates in os.path are avoided by looking directly into it.
----------
components: Library (Lib)
files: site.py.patch
messages: 57432
nosy: gbloisi
severity: normal
status: open
title: pth files not loaded at startup
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file8739/site.py.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1431>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: site.py.patch
Type: application/octet-stream
Size: 1047 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071112/adc9ecac/attachment.obj
From report at bugs.python.org Tue Nov 13 02:18:29 2007
From: report at bugs.python.org (yan)
Date: Tue, 13 Nov 2007 01:18:29 -0000
Subject: [New-bugs-announce] [issue1432] Strange behavior of urlparse.urljoin
Message-ID: <1194916709.09.0.956868163288.issue1432@psf.upfronthosting.co.za>
New submission from yan:
When I use python 2.4/2.5, I found a strange behavior like this:
urlparse.urljoin("http://www.python.org/issue?@template=item","?@template=none")
It will return "http://www.python.org/?@template=none". But I think it
should be "http://www.python.org/issue?@template=none", right? And I
test it in python 2.3. The result is what I supposed it to be.
----------
components: Library (Lib)
messages: 57434
nosy: yan
severity: normal
status: open
title: Strange behavior of urlparse.urljoin
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1432>
__________________________________
From report at bugs.python.org Tue Nov 13 11:53:09 2007
From: report at bugs.python.org (Carl Friedrich Bolz)
Date: Tue, 13 Nov 2007 10:53:09 -0000
Subject: [New-bugs-announce] [issue1433] marshal roundtripping for unicode
Message-ID: <1194951189.44.0.776453257411.issue1433@psf.upfronthosting.co.za>
New submission from Carl Friedrich Bolz:
Marshal does not round-trip unicode surrogate pairs for wide unicode-builds:
marshal.loads(marshal.dumps(u"\ud800\udc00")) == u'\U00010000'
This is very annoying, because the size of unicode constants differs
between when you run a module for the first time and subsequent runs
(because the later runs use the pyc file).
----------
components: Unicode
messages: 57444
nosy: cfbolz
severity: normal
status: open
title: marshal roundtripping for unicode
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1433>
__________________________________
From report at bugs.python.org Tue Nov 13 12:22:51 2007
From: report at bugs.python.org (Luke-Jr)
Date: Tue, 13 Nov 2007 11:22:51 -0000
Subject: [New-bugs-announce] [issue1434] SocketServer creates non-blocking
files
Message-ID: <1194952971.52.0.0175345572361.issue1434@psf.upfronthosting.co.za>
New submission from Luke-Jr:
SocketServer recently started giving my request handler rfiles that
don't block: readfile() gives me a timeout exception. This used to
work fine. I begin writing this server with 2.4.3, and it is currently
running under 2.4.4, so my suspicious is somewhere in between it
changed.
----------
components: Library (Lib)
messages: 57445
nosy: luke-jr
severity: normal
status: open
title: SocketServer creates non-blocking files
versions: Python 2.4
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1434>
__________________________________
From report at bugs.python.org Tue Nov 13 13:18:00 2007
From: report at bugs.python.org (Stavros Korokithakis)
Date: Tue, 13 Nov 2007 12:18:00 -0000
Subject: [New-bugs-announce] [issue1435] Support for multiple handlers for
the "with" statement
Message-ID: <1194956280.18.0.690384214336.issue1435@psf.upfronthosting.co.za>
New submission from Stavros Korokithakis:
Currently, the new "with" statement does not support multiple handlers.
For example, to open two files for input/output you would have to do:
with open("filein") as input:
with open("fileout") as output:
#Do stuff
pass
This adds unnecessary complexity, and would be unwieldy with multiple
code blocks. Would something like the following be feasible?
with open("filein") as input, open("fileout") as output:
# Do stuff
pass
This syntax is fully backwards-compatible, so there shouldn't be any
problem there.
----------
components: None
messages: 57446
nosy: Stavros
severity: minor
status: open
title: Support for multiple handlers for the "with" statement
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1435>
__________________________________
From report at bugs.python.org Tue Nov 13 13:41:46 2007
From: report at bugs.python.org (sebastian)
Date: Tue, 13 Nov 2007 12:41:46 -0000
Subject: [New-bugs-announce] [issue1436] logging.config.fileConfig,
NameError: name 'RotatingFileHandler' is not defined
Message-ID: <1194957706.1.0.150807949301.issue1436@psf.upfronthosting.co.za>
New submission from sebastian:
fileConfig crashes with a NameError when trying to configure a
RotatingFileHandler (I assume the same holds for other handlers defined
in logging.handlers). Using StreamHandler (from the logging package)
works fine. Most likely, I am missing something here, but if not, this
is a really bad joke...
RotatingFileHandler is available on my system, a qualified name must be
used:
Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging
>>> import logging.handlers
>>> RotatingFileHandler("test.log", "a", 5000, 5)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'RotatingFileHandler' is not defined
>>> logging.handlers.RotatingFileHandler("test.log", "a", 5000, 5)
<logging.handlers.RotatingFileHandler instance at 0x7940d0>
fileConfig crashes, with or without qualified names:
>>> import logging.config
>>> logging.config.fileConfig("test.ini")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/logging/config.py",
line 84, in fileConfig
handlers = _install_handlers(cp, formatters)
File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/logging/config.py",
line 149, in _install_handlers
klass = eval(klass, vars(logging))
File "<string>", line 1, in <module>
NameError: name 'RotatingFileHandler' is not defined
>>> logging.config.fileConfig("test.qualified_name.ini")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/logging/config.py",
line 84, in fileConfig
handlers = _install_handlers(cp, formatters)
File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/logging/config.py",
line 149, in _install_handlers
klass = eval(klass, vars(logging))
File "<string>", line 1, in <module>
NameError: name 'logging' is not defined
test.ini (in configurationFiles.zip):
---
[loggers]
keys=root
[handlers]
keys=fileHandler
[formatters]
keys=simpleFormatter
[logger_root]
level=DEBUG
handlers=fileHandler
[handler_fileHandler]
class=RotatingFileHandler
level=DEBUG
formatter=simpleFormatter
args=('test.log', 'a', 5000000, 5)
[formatter_simpleFormatter]
format=%(asctime)s - %(name)s - %(levelname)s - %(message)s
datefmt=
---
test.qualified_name.ini (in configurationFiles.zip):
---
[loggers]
keys=root
[handlers]
keys=fileHandler
[formatters]
keys=simpleFormatter
[logger_root]
level=DEBUG
handlers=fileHandler
[handler_fileHandler]
class=logging.handlers.RotatingFileHandler
level=DEBUG
formatter=simpleFormatter
args=('test.log', 'a', 5000000, 5)
[formatter_simpleFormatter]
format=%(asctime)s - %(name)s - %(levelname)s - %(message)s
datefmt=
---
----------
components: Library (Lib)
files: configurationFiles.zip
messages: 57448
nosy: sebastian
severity: urgent
status: open
title: logging.config.fileConfig, NameError: name 'RotatingFileHandler' is not defined
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file8740/configurationFiles.zip
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1436>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: configurationFiles.zip
Type: application/zip
Size: 670 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071113/0d974e31/attachment.zip
From report at bugs.python.org Tue Nov 13 13:53:38 2007
From: report at bugs.python.org (glubglub)
Date: Tue, 13 Nov 2007 12:53:38 -0000
Subject: [New-bugs-announce] [issue1437] List member inside a class is
shared by all instances of the class
Message-ID: <1194958418.68.0.123960070989.issue1437@psf.upfronthosting.co.za>
New submission from glubglub:
In the class below, 'arr' list should be unique for each instance of
class Blah. In reality, 'arr' is shared by all instances of 'Blah'
class Blah:
arr = [] # this member should not be
# shared across all instances of blah
s = ''
def __init__(self, s):
self.s = s
def __str__( self):
return '[%s, %s]' % (self.s, str(self.arr))
objs = []
objs.append(Blah('obj-a'))
objs.append(Blah('obj-b'))
objs.append(Blah('obj-c'))
# add to first object's array
objs[0].arr.append('abc')
# bug: 'abc' got added to all arrays
# print all arrays
for obj in objs:
print obj
------------------------------
Actual Output:
[obj-a, ['abc']]
[obj-b, ['abc']]
[obj-c, ['abc']]
Expected Output:
[obj-a, ['abc']]
[obj-b, []]
[obj-c, []]
----------
components: Interpreter Core
messages: 57449
nosy: glubglub
severity: normal
status: open
title: List member inside a class is shared by all instances of the class
versions: Python 2.3, Python 2.4, Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1437>
__________________________________
From report at bugs.python.org Tue Nov 13 19:25:43 2007
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 13 Nov 2007 18:25:43 -0000
Subject: [New-bugs-announce] [issue1438] Calling base class methods is slow
due to __instancecheck__ override in abc.py
Message-ID: <1194978343.94.0.00370847654869.issue1438@psf.upfronthosting.co.za>
New submission from Guido van Rossum:
[Guido]
> > I've noticed that abc.py's __instancecheck__ gets called a lot
> > at times when I don't expect it. Can you research this a bit?
[Amaury]
> In classobject.c, method_call() calls PyObject_IsInstance() on the
> first arg when the method is unbound.
> This happens a lot in io.py, each time the code calls a base class
> method.
[Guido]
I wonder if we should get rid of this isinstance check. It is only used
to be able to issue a pedantic error message. Perhaps we could even get
rid of unbound methods, and just return the underlying function object
instead of creating an unbound method object. This should make things a
bit faster.
----------
messages: 57461
nosy: gvanrossum
severity: normal
status: open
title: Calling base class methods is slow due to __instancecheck__ override in abc.py
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1438>
__________________________________
From report at bugs.python.org Tue Nov 13 20:36:37 2007
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 13 Nov 2007 19:36:37 -0000
Subject: [New-bugs-announce] [issue1439] proposed 3000 patch for socket.py -
"socket GC worries"
Message-ID: <1194982597.85.0.542157776482.issue1439@psf.upfronthosting.co.za>
New submission from Bill Janssen:
This patch essentially makes GC of sockets work again.
See http://mail.python.org/pipermail/python-3000/2007-October/
011058.html and all the threads in http://mail.python.org/pipermail/
python-3000/2007-October/thread.html with subject line "socket GC
worries" for a full discussion.
----------
assignee: gvanrossum
components: Library (Lib)
files: b
keywords: patch, py3k
messages: 57470
nosy: gvanrossum, janssen
severity: normal
status: open
title: proposed 3000 patch for socket.py - "socket GC worries"
versions: Python 3.0
Added file: http://bugs.python.org/file8742/b
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1439>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: b
Type: application/octet-stream
Size: 6049 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071113/4b8e734a/attachment.obj
From report at bugs.python.org Wed Nov 14 01:51:07 2007
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 14 Nov 2007 00:51:07 -0000
Subject: [New-bugs-announce] [issue1440] Checks for
PySys_GetObject("std???") == Py_None
Message-ID: <1195001467.42.0.307645979173.issue1440@psf.upfronthosting.co.za>
New submission from Christian Heimes:
Can you please review the patch. It's not urgent. It adds additional
tests for std??? == Py_None to some functions to speed up things or
raise more meaningful exceptions when sys.std??? is None.
----------
assignee: gvanrossum
components: Interpreter Core
files: py3k_std_none_check.patch
keywords: patch, py3k
messages: 57476
nosy: gvanrossum, tiran
priority: low
severity: normal
status: open
title: Checks for PySys_GetObject("std???") == Py_None
versions: Python 3.0
Added file: http://bugs.python.org/file8743/py3k_std_none_check.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1440>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k_std_none_check.patch
Type: text/x-diff
Size: 4191 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071114/5bb11fee/attachment-0001.patch
From report at bugs.python.org Wed Nov 14 04:01:32 2007
From: report at bugs.python.org (Adam Olsen)
Date: Wed, 14 Nov 2007 03:01:32 -0000
Subject: [New-bugs-announce] [issue1441] Cycles through ob_type aren't freed
Message-ID: <1195009292.31.0.0975446267952.issue1441@psf.upfronthosting.co.za>
New submission from Adam Olsen:
If I create a subclass of 'type' that's also an instance of 'type', then
I change __class__ to point to itself, at which point it cannot be freed
(as the type object is needed to delete the instance.)
I believe this can be solved by resetting __class__ to a known-safe
value. Presumably this should be a hidden subclass of type, stored in a
C global, and used specifically for this purpose. type_clear can do the
reset (checking that the passed in type is a heap type, perhaps with a
heap type metaclass); I'm hoping __del__ and weakref callbacks are not
an issue at this point, but I'll defer to the experts for verification.
This log using gdb shows that type_dealloc is called for a normal type
(BoringType), but not for the self-cyclic one (ImmortalType).
ImmortalType shows up in every collection, never actually getting collected.
(I'm assuming Python doesn't bother to delete heap types during
shutdown, which is why type_dealloc isn't called more.)
**********
rhamph at factor:~/src/python-p3yk/build-debug$ gdb ./python
GNU gdb 6.6.90.20070912-debian
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) set height 100000
(gdb) break type_dealloc
Breakpoint 1 at 0x80af057: file ../Objects/typeobject.c, line 2146.
(gdb) commands
Type commands for when breakpoint 1 is hit, one per line.
End with a line saying just "end".
>silent
>printf "*** type_dealloc %p: %s\n", type, type->tp_name
>cont
>end
(gdb) break typeobject.c:2010
Breakpoint 2 at 0x80aec35: file ../Objects/typeobject.c, line 2010.
(gdb) commands
Type commands for when breakpoint 2 is hit, one per line.
End with a line saying just "end".
>silent
>printf "*** type_new %p: %s\n", type, type->tp_name
>cont
>end
(gdb) run
Starting program: /home/rhamph/src/python-p3yk/build-debug/python
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread 0xb7e156b0 (LWP 25496)]
[Switching to Thread 0xb7e156b0 (LWP 25496)]
*** type_new 0x81c80ac: ZipImportError
*** type_new 0x81e9934: abstractproperty
*** type_new 0x81ea484: _Abstract
*** type_new 0x81eab04: ABCMeta
*** type_new 0x81eb6b4: Hashable
*** type_new 0x81ecb7c: Iterable
*** type_new 0x81ed9a4: Iterator
*** type_new 0x81ede84: Sized
*** type_new 0x81ee364: Container
*** type_new 0x822f2fc: Callable
*** type_new 0x822f974: Set
*** type_new 0x823094c: MutableSet
*** type_new 0x8230fec: Mapping
*** type_new 0x823135c: MappingView
*** type_new 0x823183c: KeysView
*** type_new 0x8231eb4: ItemsView
*** type_new 0x823252c: ValuesView
*** type_new 0x8232ba4: MutableMapping
*** type_new 0x82330ac: Sequence
*** type_new 0x8233fa4: MutableSequence
*** type_new 0x81e61ac: _Environ
*** type_new 0x823657c: _wrap_close
*** type_new 0x81d41a4: _Printer
*** type_new 0x81dab84: _Helper
*** type_new 0x81d12a4: error
*** type_new 0x82ad5b4: Pattern
*** type_new 0x82adc2c: SubPattern
*** type_new 0x82ae134: Tokenizer
*** type_new 0x82afb04: Scanner
*** type_new 0x8249f34: _multimap
*** type_new 0x824892c: _TemplateMetaclass
*** type_new 0x82b0634: Template
*** type_new 0x82b34ac: Formatter
*** type_new 0x82b000c: DistutilsError
*** type_new 0x82b40c4: DistutilsModuleError
*** type_new 0x82b440c: DistutilsClassError
*** type_new 0x82b4754: DistutilsGetoptError
*** type_new 0x82b4a9c: DistutilsArgError
*** type_new 0x82b4de4: DistutilsFileError
*** type_new 0x82b512c: DistutilsOptionError
*** type_new 0x82b57d4: DistutilsSetupError
*** type_new 0x82b5b1c: DistutilsPlatformError
*** type_new 0x82b5e64: DistutilsExecError
*** type_new 0x82b61ac: DistutilsInternalError
*** type_new 0x82b64f4: DistutilsTemplateError
*** type_new 0x82b683c: CCompilerError
*** type_new 0x82b6b84: PreprocessError
*** type_new 0x82b6ecc: CompileError
*** type_new 0x82b7214: LibError
*** type_new 0x82b755c: LinkError
*** type_new 0x82b7d4c: UnknownFileError
*** type_new 0x82b9b6c: Log
*** type_new 0x82ba994: Quitter
*** type_new 0x82bcdbc: CodecInfo
*** type_new 0x82bd104: Codec
*** type_new 0x82bdd94: IncrementalEncoder
*** type_new 0x82be224: BufferedIncrementalEncoder
*** type_new 0x82be72c: IncrementalDecoder
*** type_new 0x82bebbc: BufferedIncrementalDecoder
*** type_new 0x82bf0c4: StreamWriter
*** type_new 0x82bf5cc: StreamReader
*** type_new 0x82bfad4: StreamReaderWriter
*** type_new 0x82c022c: StreamRecoder
*** type_new 0x82c221c: CodecRegistryError
*** type_new 0x82c5414: _OptionError
*** type_new 0x82c23f4: BlockingIOError
*** type_new 0x82c25cc: UnsupportedOperation
*** type_new 0x82c2f3c: IOBase
*** type_new 0x82c2924: RawIOBase
*** type_new 0x82c2d3c: FileIO
*** type_new 0x8316844: BufferedIOBase
*** type_new 0x831733c: _BufferedIOMixin
*** type_new 0x8317ddc: BytesIO
*** type_new 0x83182e4: BufferedReader
*** type_new 0x83187ec: BufferedWriter
*** type_new 0x8318e74: BufferedRWPair
*** type_new 0x831966c: BufferedRandom
*** type_new 0x8319b74: TextIOBase
*** type_new 0x831a694: TextIOWrapper
*** type_new 0x831a064: StringIO
*** type_new 0x831a3d4: Codec
*** type_new 0x8317034: IncrementalEncoder
*** type_new 0x82bb32c: IncrementalDecoder
*** type_new 0x82c8ebc: StreamWriter
*** type_new 0x831ab84: StreamReader
*** type_new 0x831ad5c: StreamConverter
*** type_new 0x82c9094: IncrementalEncoder
*** type_new 0x831af34: IncrementalDecoder
*** type_new 0x831b10c: StreamWriter
*** type_new 0x831b2e4: StreamReader
*** type_new 0x831b4bc: open
Python 3.0a1 (py3k:57858M, Nov 13 2007, 17:35:03)
[GCC 4.2.2 (Debian 4.2.2-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gc
[36431 refs]
>>> gc.set_debug(gc.DEBUG_STATS | gc.DEBUG_COLLECTABLE |
gc.DEBUG_UNCOLLECTABLE | gc.DEBUG_OBJECTS)
[36431 refs]
>>> # Our metaclass must start out as a heaptype if we want to change
__class__
... class BoringType(type): pass
...
*** type_new 0x832b42c: BoringType
[36453 refs]
>>> class ImmortalType(type, metaclass=BoringType): pass
...
*** type_new 0x832b604: ImmortalType
[36473 refs]
>>> ImmortalType.__class__ = ImmortalType
[36473 refs]
>>> gc.collect()
gc: collecting generation 2...
gc: objects in each generation: 152 4735 0
gc: done.
0
[36480 refs]
>>> del BoringType
[36478 refs]
>>> gc.collect()
gc: collecting generation 2...
gc: objects in each generation: 4 0 4883
gc: collectable <type 0x832b42c>
gc: 0.0095s elapsed.
gc: collectable <dict 0x830ac14>
gc: 1195008581.8807s elapsed.
gc: collectable <tuple 0x830c934>
gc: 0.0100s elapsed.
gc: collectable <tuple 0x828f06c>
gc: 1195008581.8812s elapsed.
*** type_dealloc 0x832b42c: BoringType
gc: done, 4 unreachable, 0 uncollectable.
4
[36462 refs]
>>> del ImmortalType
[36460 refs]
>>> gc.collect()
gc: collecting generation 2...
gc: objects in each generation: 4 0 4879
gc: collectable <ImmortalType 0x832b604>
gc: 0.0251s elapsed.
gc: collectable <dict 0x830acb4>
gc: 1195008581.8980s elapsed.
gc: collectable <tuple 0x830ca34>
gc: 0.0255s elapsed.
gc: collectable <tuple 0x828cd8c>
gc: 1195008581.8984s elapsed.
gc: done, 4 unreachable, 0 uncollectable.
4
[36452 refs]
>>>
[36452 refs]
gc: collecting generation 2...
gc: objects in each generation: 0 0 4878
gc: collectable <ImmortalType 0x832b604>
gc: 0.0080s elapsed.
gc: collectable <dict 0x830acb4>
gc: 1195008585.4450s elapsed.
gc: collectable <tuple 0x828cd8c>
gc: 0.0124s elapsed.
gc: done, 3 unreachable, 0 uncollectable.
Program exited normally.
(gdb) quit
rhamph at factor:~/src/python-p3yk/build-debug$
**********
Finally, this is what I pasted into gdb to produce that log. Note that
I'm using a somewhat old checkout (r57858), so line numbers may need to
be adjusted. (The second break point is intended to be at the end of
type_new.)
**********
set height 100000
break type_dealloc
commands
silent
printf "*** type_dealloc %p: %s\n", type, type->tp_name
cont
end
break typeobject.c:2010
commands
silent
printf "*** type_new %p: %s\n", type, type->tp_name
cont
end
run
import gc
gc.set_debug(gc.DEBUG_STATS | gc.DEBUG_COLLECTABLE |
gc.DEBUG_UNCOLLECTABLE | gc.DEBUG_OBJECTS)
# Our metaclass must start out as a heaptype if we want to change __class__
class BoringType(type): pass
class ImmortalType(type, metaclass=BoringType): pass
ImmortalType.__class__ = ImmortalType
gc.collect()
del BoringType
gc.collect()
del ImmortalType
gc.collect()
----------
components: Interpreter Core
messages: 57479
nosy: rhamphoryncus
severity: normal
status: open
title: Cycles through ob_type aren't freed
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1441>
__________________________________
From report at bugs.python.org Wed Nov 14 05:07:24 2007
From: report at bugs.python.org (Joseph Armbruster)
Date: Wed, 14 Nov 2007 04:07:24 -0000
Subject: [New-bugs-announce] [issue1442] pythonstartup addition of minor
error checking
Message-ID: <1195013244.94.0.813010409666.issue1442@psf.upfronthosting.co.za>
New submission from Joseph Armbruster:
Trunk revision: 58963
Description: No warning or error is reported it a file pointed to by
PYTHONSTARTUP is not readable.
Request: To display a warning so that the user may be notified.
Note: Errors that may occur in PyRun_SimpleFileExFlags are being cast
away, may be worthwhile to report an error for those as well (unless
this was avoided for good reason :-)
Suggestion:
static void RunStartupFile(PyCompilerFlags *cf)
{
char *startup = Py_GETENV("PYTHONSTARTUP");
if (startup != NULL && startup[0] != '\0') {
FILE *fp = fopen(startup, "r");
if (fp != NULL) {
(void) PyRun_SimpleFileExFlags(fp, startup, 0, cf);
PyErr_Clear();
fclose(fp);
}
else {
fprintf(stderr,"Warning: Could not read startup file %s\n",startup);
}
}
}
----------
components: Interpreter Core
messages: 57482
nosy: JosephArmbruster
severity: minor
status: open
title: pythonstartup addition of minor error checking
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1442>
__________________________________
From report at bugs.python.org Wed Nov 14 20:10:35 2007
From: report at bugs.python.org (neoone)
Date: Wed, 14 Nov 2007 19:10:35 -0000
Subject: [New-bugs-announce] [issue1443] Magic class member variable
initialization with lists
Message-ID: <1195067435.45.0.396965651814.issue1443@psf.upfronthosting.co.za>
New submission from neoone:
Initialization of member variables with lists leads to strange
behavior.
The list object is common to each instance of that class.
File attached results in:
[] [] <__main__.Proof instance at 0x00BA7120>
['STICKYARRAY'] [] <__main__.Proof instance at 0x00BA7148>
So the initialized list a is the same in both instances.
Behaviour has been tested on 2.3 and 2.5
----------
components: Interpreter Core
files: test.py
messages: 57500
nosy: neoone
severity: normal
status: open
title: Magic class member variable initialization with lists
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file8745/test.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1443>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.py
Type: application/octet-stream
Size: 244 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071114/2bffb94f/attachment.obj
From report at bugs.python.org Thu Nov 15 09:06:32 2007
From: report at bugs.python.org (James G. sack (jim))
Date: Thu, 15 Nov 2007 08:06:32 -0000
Subject: [New-bugs-announce] [issue1444] utf_8_sig streamreader bug, patch,
and test
Message-ID: <1195113992.85.0.953910196559.issue1444@psf.upfronthosting.co.za>
New submission from James G. sack (jim):
The streamreader in utf_8_sig.py fails when asked to read a specified
bytelength of data that ends up in the middle of a multibyte utf8 code.
I will attached a atandalone unittest (which does work from autotest, but
doesn't use test_support), test_utf8sig_stream.py.
I will attach a patch (applied to the trunk 2.6 version), u8sig26.diff.
Regards,
..jim
----------
components: Unicode
files: u8sig26.diff
messages: 57520
nosy: jgsack
severity: normal
status: open
title: utf_8_sig streamreader bug, patch, and test
type: crash
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file8749/u8sig26.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1444>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: u8sig26.diff
Type: application/octet-stream
Size: 977 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071115/3c13f3d1/attachment.obj
From report at bugs.python.org Thu Nov 15 11:27:48 2007
From: report at bugs.python.org (Duncan Booth)
Date: Thu, 15 Nov 2007 10:27:48 -0000
Subject: [New-bugs-announce] [issue1445] SystemError accessing uninitialised
cell contents
Message-ID: <1195122468.38.0.534995719828.issue1445@psf.upfronthosting.co.za>
New submission from Duncan Booth:
The following code throws a SystemError exception. cell_get_contents in
Objects\cellobject.c should check for a null op->ob_ref value and throw
an appropriate exception.
>>> def oops():
def f(): cell
f.func_closure[0].cell_contents
cell = None
>>> oops()
Traceback (most recent call last):
File "<pyshell#9>", line 1, in <module>
oops()
File "<pyshell#8>", line 3, in oops
f.func_closure[0].cell_contents
SystemError: error return without exception set
>>>
----------
components: Interpreter Core
messages: 57525
nosy: duncanb
severity: normal
status: open
title: SystemError accessing uninitialised cell contents
type: behavior
versions: Python 2.5, Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1445>
__________________________________
From report at bugs.python.org Thu Nov 15 14:10:33 2007
From: report at bugs.python.org (Gopinath)
Date: Thu, 15 Nov 2007 13:10:33 -0000
Subject: [New-bugs-announce] [issue1446] Link to call me for free
Message-ID: <238882.904191195131510200.JavaMail.tomcat@media1.jaxtr.com>
New submission from Gopinath:
I am using jaxtr, and if you also sign up, we
-sara
P.S. Here is the link to sign up: http://www.jaxtr.com/user/ticket?n=Tzmtvrjje8qrw&type=joininvite
---
Delivered by jaxtr, Inc., 855 Oak Grove Avenue, Suite 100, Menlo Park, California 94025. To stop receiving messages from this sender go to http://www.jaxtr.com/user/reportabuse.jsp?it=Tzmtvrjje8qrw
----------
files: unnamed
messages: 57528
nosy: gopiyadav26
severity: normal
status: open
title: Link to call me for free
Added file: http://bugs.python.org/file8751/unnamed
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1446>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071115/187a101a/attachment.txt
From report at bugs.python.org Thu Nov 15 15:21:35 2007
From: report at bugs.python.org (zouguangxian)
Date: Thu, 15 Nov 2007 14:21:35 -0000
Subject: [New-bugs-announce] [issue1447] patch to make msvccompiler.py work
with vs 2005(MSVC8)
Message-ID: <1195136495.24.0.274632753726.issue1447@psf.upfronthosting.co.za>
New submission from zouguangxian:
It seems that the directory information of MSVC8 *just* can be got from
environment variable instead of registry.
This patch make me compile pywin32 with MSVC8(VS 2005).
----------
files: msvccompiler.py.diff
messages: 57530
nosy: weck
severity: normal
status: open
title: patch to make msvccompiler.py work with vs 2005(MSVC8)
type: compile error
versions: Python 2.5
Added file: http://bugs.python.org/file8752/msvccompiler.py.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1447>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: msvccompiler.py.diff
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071115/10d61555/attachment.txt
From report at bugs.python.org Thu Nov 15 16:08:14 2007
From: report at bugs.python.org (zouguangxian)
Date: Thu, 15 Nov 2007 15:08:14 -0000
Subject: [New-bugs-announce] [issue1448] Build Python with VS 2005(MSVC8)
Message-ID: <1195139294.41.0.21090729901.issue1448@psf.upfronthosting.co.za>
New submission from zouguangxian:
There are several problems that cause us can't build python with vs
2005.
1. some libraries are outdated.
for example, tcl8.4.12, tk8.4.12. Just download a newer version will
resolve this problem.
wget http://prdownloads.sourceforge.net/tcl/tcl8.4.16-src.tar.gz
wget http://prdownloads.sourceforge.net/tcl/tk8.4.16-src.tar.gz
wget http://prdownloads.sourceforge.net/tix/Tix8.4.2-src.tar.gz
I think it's better to upgrade bdb too, so i select bdb 4.6.21.
http://download.oracle.com/berkeley-db/db-4.6.21.tar.gz
upgrade bzip to 1.0.4
wget http://www.bzip.org/1.0.4/bzip2-1.0.4.tar.gz
upgrade openssl to 0.9.9g
wget http://www.openssl.org/source/openssl-0.9.8g.tar.gz
It's not convenient to build sqlite-3.5.2, so we just download a binary
version from it's official site.
wget http://www.sqlite.org/sqlitedll-3_5_2.zip
wget http://www.sqlite.org/sqlite-source-3_5_2.zip
2. more detail on build these libraries
generally, you can follow the guide in PCbuild/readme.txt. but there
are thing you need to pay attention to .
For Tix8.4.2, we should create a python.mak for it, and make a patch on
makefile.vc. User also need to 'set MSVCDIR=%VCINSTALLDIR%' in cmd
window.
For bdb-4.6.21, I can't upgrade dsw to sln with the command:
devenv db-4.6.21\build_windows\Berkeley_DB.dsw /Upgrade
instead, open dsw in VS 2005 IDE, convert and save it.
to build openssl, as the guide said, we can use build_ssl.py in
PCbuild. but we need to move build_ssl.py, build_ssl.bat and _ssl.mak
to PCbuild8, and make a little modification.
3. make pcbuild.sln work properly.
some options are missed in pcbuild.sln and it's projects. we need to
edit pyproject.vsprops and etc.
I can't make make_versioninfo work at first, and then i found that may
have relationship with SxS(Side by Side, manifest), I run the resource
wizard and did'nt add resource, but the wizard create resource.h
and .rc file, after i build the project, it work correctly.
4. output directory changed
build python25 in x86 with debug mode, the *.lib, *.dll, *.pyd etc will
be placed in win32debug. to make build_ssl.py, I calculate the output
directory add it to LIBPATH.
Finally, I changed the readme.txt in PCbuild8, so you can follow the
newer guide.
----------
files: pcbuild8.patch
messages: 57531
nosy: weck
severity: normal
status: open
title: Build Python with VS 2005(MSVC8)
type: compile error
versions: Python 2.5
Added file: http://bugs.python.org/file8753/pcbuild8.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1448>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pcbuild8.patch
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071115/0a084ce0/attachment-0001.txt
From report at bugs.python.org Thu Nov 15 16:23:54 2007
From: report at bugs.python.org (zouguangxian)
Date: Thu, 15 Nov 2007 15:23:54 -0000
Subject: [New-bugs-announce] [issue1449] make msi work the vs 2005(MSVC8)
Message-ID: <1195140234.29.0.51562354757.issue1449@psf.upfronthosting.co.za>
New submission from zouguangxian:
with vs 2003, msi.py get msvcr71.dll from msm. but with vs 2005, It's
better to extract msvcr80.dll from %VCINTALLDIR%\redist\x86
\Microsoft.VC80.CRT\. In addition, it seems to extract file from
Microsoft_VC80_CRT_x86.msm need upgrade MSI to 3.1, i am not sure.
I 'PCbuild' to 'PCbuild8' in msi.py and add extract_msvcr80, that will
make msi.py work with vs 2005.
----------
files: msi.patch
messages: 57532
nosy: weck
severity: normal
status: open
title: make msi work the vs 2005(MSVC8)
type: compile error
versions: Python 2.5
Added file: http://bugs.python.org/file8754/msi.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1449>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: msi.patch
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071115/475af36f/attachment.txt
From report at bugs.python.org Thu Nov 15 16:35:31 2007
From: report at bugs.python.org (zouguangxian)
Date: Thu, 15 Nov 2007 15:35:31 -0000
Subject: [New-bugs-announce] [issue1450] make modulator more general
Message-ID: <1195140931.63.0.827333708733.issue1450@psf.upfronthosting.co.za>
New submission from zouguangxian:
modulator may be outdated. i made a changement to make it use the new
feature of PyTypeObject in Python2.5.
for example, to support members, methods, new, init and etc.
----------
components: Demos and Tools
files: modulator.patch
messages: 57533
nosy: weck
severity: normal
status: open
title: make modulator more general
type: compile error
versions: Python 2.5
Added file: http://bugs.python.org/file8755/modulator.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1450>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: modulator.patch
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071115/261b7ea6/attachment-0001.txt
From report at bugs.python.org Thu Nov 15 18:35:01 2007
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 15 Nov 2007 17:35:01 -0000
Subject: [New-bugs-announce] [issue1451] SSL patch for Python 3000
Message-ID: <1195148101.74.0.11100748697.issue1451@psf.upfronthosting.co.za>
New submission from Bill Janssen:
This patch adds the new SSL module to Python 3000, along with the test
suite for it. It's against revision 58984. Proper Python indentation has
*not* been checked, but leak testing has been done.
----------
assignee: gvanrossum
components: Library (Lib)
files: ssl.patch
keywords: patch, py3k
messages: 57540
nosy: gvanrossum, janssen
severity: normal
status: open
title: SSL patch for Python 3000
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8756/ssl.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1451>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ssl.patch
Type: application/octet-stream
Size: 59726 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071115/7763c2cd/attachment-0001.obj
From report at bugs.python.org Fri Nov 16 15:56:48 2007
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 16 Nov 2007 14:56:48 -0000
Subject: [New-bugs-announce] [issue1452] subprocess's popen.stdout.seek(0)
doesn't raise an error
Message-ID: <1195225008.73.0.984849336269.issue1452@psf.upfronthosting.co.za>
New submission from Christian Heimes:
On Linux:
>>> p = subprocess.Popen("ls", stdout=subprocess.PIPE)
>>> p.stdout.read()
b'...'
>>> p.stdout.seek(0)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/heimes/dev/python/py3k/Lib/io.py", line 809, in seek
pos = self.raw.seek(pos, whence)
IOError: [Errno 29] Illegal seek
>>> p.stdout.read()
b''
On Windows p.stdout.seek(0) does neither raise an error nor works as one
might expect it. The second read() returns an empty byte string, too.
----------
components: Windows
keywords: py3k
messages: 57585
nosy: tiran
severity: normal
status: open
title: subprocess's popen.stdout.seek(0) doesn't raise an error
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1452>
__________________________________
From report at bugs.python.org Fri Nov 16 19:19:39 2007
From: report at bugs.python.org (Miki Tebeka)
Date: Fri, 16 Nov 2007 18:19:39 -0000
Subject: [New-bugs-announce] [issue1453] Python does not honor "CFLAGS"
environment variable
Message-ID: <1195237179.9.0.203968653278.issue1453@psf.upfronthosting.co.za>
New submission from Miki Tebeka:
Setting CFLAGS environment variable do not show up in the build process,
the gcc flags do not include the CFLAGS flags.
----------
components: Build
messages: 57588
nosy: tebeka
severity: normal
status: open
title: Python does not honor "CFLAGS" environment variable
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1453>
__________________________________
From report at bugs.python.org Sat Nov 17 08:28:58 2007
From: report at bugs.python.org (Aldo Cortesi)
Date: Sat, 17 Nov 2007 07:28:58 -0000
Subject: [New-bugs-announce] [issue1454] Generators break trace functionality
Message-ID: <1195284538.89.0.627172491986.issue1454@psf.upfronthosting.co.za>
New submission from Aldo Cortesi:
I rely heavily on a code coverage analysis engine I developed, and a bug
in Python's trace functionality has been bothering me for years. Today I
snapped, and finally tracked it down to a minimal test case. To see the
problem, play with the following code:
import sys
def run(): yield 1
def trace(frame, event, arg):
try:
for i in []: pass
except Exception, e:
pass
sys.settrace(trace)
x = run()
del x
Remove the try clause, and re-run with a debug build of the interpreter
for a different symptom. Add a print statement at the end to verify that
the problem occurs when the generator object is deleted.
The problem occurs due to an interaction between generators and the
trace functionality. When a generator is deleted, the gen_del function
calls gen_close, which then sets a GeneratorExit exception. Eventually,
PyEval_EvalFrameEx is called, with the throwflag set. At this point the
trace function is called, the GeneratorExit exception which is set
causes problems with the FOR_ITER opcode, which then fails.
The attached patch against trunk fixes this by storing exceptions before
the call trace function is called, and restoring the exception
afterwards. All regression tests pass for me with this patch applied.
----------
components: Interpreter Core
files: generator-trace.patch
messages: 57598
nosy: cortesi
severity: major
status: open
title: Generators break trace functionality
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file8765/generator-trace.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1454>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: generator-trace.patch
Type: text/x-patch
Size: 911 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071117/916af99c/attachment.bin
From report at bugs.python.org Sat Nov 17 14:48:13 2007
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 17 Nov 2007 13:48:13 -0000
Subject: [New-bugs-announce] [issue1455] VS2008,
quick hack for distutils.msvccompiler
Message-ID: <1195307293.52.0.874036930861.issue1455@psf.upfronthosting.co.za>
New submission from Christian Heimes:
I've come up with a quick hack to support VS 2008. VS 2008 Standard
Edition doesn't store the include and lib dirs in the registry any more.
However I came up with a nice way to get the env settings from the
vcvarsall.bat. How do you like it?
Do we need support for VS6 and VS7.1 or can I remove the code from the
module?
----------
assignee: loewis
components: Distutils
files: py3k_vs2008_hack.patch
keywords: patch, py3k
messages: 57599
nosy: loewis, tiran
priority: normal
severity: normal
status: open
title: VS2008, quick hack for distutils.msvccompiler
type: rfe
versions: Python 3.0
Added file: http://bugs.python.org/file8766/py3k_vs2008_hack.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1455>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k_vs2008_hack.patch
Type: text/x-diff
Size: 11056 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071117/58818eff/attachment.patch
From report at bugs.python.org Sun Nov 18 05:32:14 2007
From: report at bugs.python.org (Joseph Armbruster)
Date: Sun, 18 Nov 2007 04:32:14 -0000
Subject: [New-bugs-announce] [issue1456] unexpected iterator behavior with
removal
Message-ID: <1195360334.0.0.509971000187.issue1456@psf.upfronthosting.co.za>
New submission from Joseph Armbruster:
Trunk Revision: 58651
Example of potential issue:
>>> a = [1,2,3,4,5]
>>>
>>> for x in a:
... a.remove(x)
...
>>>
>>> a
[2, 4]
If this is the expected behavior of iteration in this case, my
apologies. If this is not, I believe the issue lies in that
listiter_next does not act correctly after a listremove has occurred.
My knowledge of Python development is practically 0, so please take the
patch with a grain of salt.
----------
components: Interpreter Core
files: listobjectpatch.patch
messages: 57611
nosy: JosephArmbruster
severity: normal
status: open
title: unexpected iterator behavior with removal
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file8769/listobjectpatch.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1456>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: listobjectpatch.patch
Type: application/octet-stream
Size: 1638 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071118/ce4d3c6b/attachment.obj
From report at bugs.python.org Sun Nov 18 16:25:30 2007
From: report at bugs.python.org (Tal Einat)
Date: Sun, 18 Nov 2007 15:25:30 -0000
Subject: [New-bugs-announce] [issue1457] IDLE - configDialog - new layout
for key config
Message-ID: <1195399530.13.0.0197942557234.issue1457@psf.upfronthosting.co.za>
New submission from Tal Einat:
As brought up on the idle-dev mailing list, I have redesigned the key
config window. The new layout is two wide frames one above the other,
instead of two tall frames side-by-side. This allows the key-binding
entries to be completely visible in the listbox.
----------
components: IDLE
files: IDLE_configDialog.071118.patch
messages: 57617
nosy: kbk, taleinat
severity: normal
status: open
title: IDLE - configDialog - new layout for key config
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file8771/IDLE_configDialog.071118.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1457>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IDLE_configDialog.071118.patch
Type: application/octet-stream
Size: 4136 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071118/b7fe1a1e/attachment.obj
From report at bugs.python.org Sun Nov 18 23:14:27 2007
From: report at bugs.python.org (Joseph Armbruster)
Date: Sun, 18 Nov 2007 22:14:27 -0000
Subject: [New-bugs-announce] [issue1458] installer crashes on attempted
cancellation
Message-ID: <1195424067.48.0.215930942967.issue1458@psf.upfronthosting.co.za>
New submission from Joseph Armbruster:
Operating System:
OS Name: Microsoft Windows XP Professional
OS Version: 5.1.2600 Service Pack 2 Build 2600
Using the latest Python 2.5.1.msi from:
http://www.python.org/ftp/python/2.5.1/python-2.5.1.msi
Perform the following steps:
- launch python-2.5.1.msi
- select next
- select next
- select Advanced
- select cancel
- select yes
Issue:
I think the issue may reside around line 698/699 in these lines of msi.py
c = advanced.cancel("Cancel", "CompilePyc")
c.event("SpawnDialog", "CancelDlg")
I have vs2005, so I can not really test/utilize msi.py that easily.
Note: If anyone can build an msi with vs2005 please give me the details
on how you did so. My initial hackery went along the lines of:
- built solution in release
- modded msi.py for pcbuild8
- modded msisupport.mak to include libpath for msi.lib
- ran python msi.py
- ...told to run icons.mak in pc dir
- ran icons.mak
- reran python msi.py
- built w9xpopen from PC/VC6/pcbuild solution
... realized I had to change msi.py for VisualStudio8.0 registry keys
and quit here ...
I was advised on #python that the Orcas Beta is where it's at, so I am
downloading now.
----------
components: Installation, Windows
messages: 57625
nosy: JosephArmbruster
severity: minor
status: open
title: installer crashes on attempted cancellation
type: crash
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1458>
__________________________________
From report at bugs.python.org Mon Nov 19 00:01:34 2007
From: report at bugs.python.org (Gabriel Genellina)
Date: Sun, 18 Nov 2007 23:01:34 -0000
Subject: [New-bugs-announce] [issue1459] Bugs lost on migration from
Sourceforge
Message-ID: <1195426894.43.0.983428714797.issue1459@psf.upfronthosting.co.za>
New submission from Gabriel Genellina:
I can't
find the
issue this
mail refers
to:
http://
mail.python.org/
pipermail/
python-bugs-
list/2006-
April/
033139.html
As it was
labeled
"Bug item
#1474680",
I tried
http://
bugs.python.org/
issue1474680
and got a
404 error.
Using the
Search form
(either
searching
into Title
or All
Text)
didn't get
any
results. (I
had to
remember to
set the
Status
field to
"don't
care"
instead of
"open" each
time, but
this is
another
issue).
----------
components: None
messages: 57626
nosy: gagenellina
severity: normal
status: open
title: Bugs lost on migration from Sourceforge
versions: 3rd party
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1459>
__________________________________
From report at bugs.python.org Mon Nov 19 10:29:18 2007
From: report at bugs.python.org (=?utf-8?q?=C3=81rni_M=C3=A1r_J=C3=B3nsson?=)
Date: Mon, 19 Nov 2007 09:29:18 -0000
Subject: [New-bugs-announce] [issue1460] codecs utf7 decoding error
Message-ID: <1195464558.65.0.820353840757.issue1460@psf.upfronthosting.co.za>
New submission from ?rni M?r J?nsson:
There is a utf-7 decoding error when decoding strings which have a shift
sequence at a certain place. To reproduce run the attached program on a
file containing the string:
"0123456789012345678901234567890123456789012345678901234567890123456789X+-".
The shift sequence starts at character 72. The culprit seems to be in
codecs.py: StreamReader.read. The input is split on the 72 character
boundary, and the first decode call raises an exception since the shift
sequence is not terminated. The second one falls back 1 character,
raises no exception, but the previous exception is raised since there is
no newline in the output (?).
The lines I don't understand are, and are the ones raising the exception.
if len(lines)<=1:
raise
----------
files: utf7.py
messages: 57629
nosy: arnimar
severity: normal
status: open
title: codecs utf7 decoding error
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file8773/utf7.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1460>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: utf7.py
Type: application/octet-stream
Size: 283 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071119/2cf0d705/attachment.obj
From report at bugs.python.org Mon Nov 19 11:47:02 2007
From: report at bugs.python.org (Jean-Marc Gillet)
Date: Mon, 19 Nov 2007 10:47:02 -0000
Subject: [New-bugs-announce] [issue1461] 0**0 should raise an error
Message-ID: <1195469222.56.0.177574351963.issue1461@psf.upfronthosting.co.za>
Changes by Jean-Marc Gillet:
----------
nosy: jmgillet
severity: minor
status: open
title: 0**0 should raise an error
type: behavior
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1461>
__________________________________
From report at bugs.python.org Mon Nov 19 16:51:38 2007
From: report at bugs.python.org (Kent Johnson)
Date: Mon, 19 Nov 2007 15:51:38 -0000
Subject: [New-bugs-announce] [issue1462] About this document refers to
SourceForge tracker
Message-ID: <1195487498.98.0.226618413315.issue1462@psf.upfronthosting.co.za>
New submission from Kent Johnson:
"About this document" http://docs.python.org/lib/about.html still refers
to "the Python Bug Tracker at SourceForge". The bug tracker link is
incorrect (should be the new tracker) and the SF reference is obsolete.
----------
components: Documentation
messages: 57635
nosy: kjohnson
severity: normal
status: open
title: About this document refers to SourceForge tracker
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1462>
__________________________________
From report at bugs.python.org Mon Nov 19 16:54:54 2007
From: report at bugs.python.org (Kent Johnson)
Date: Mon, 19 Nov 2007 15:54:54 -0000
Subject: [New-bugs-announce] [issue1463] Minor error in mimetypes docs
Message-ID: <1195487694.12.0.499193424755.issue1463@psf.upfronthosting.co.za>
New submission from Kent Johnson:
In the mimetypes module docs
http://docs.python.org/lib/module-mimetypes.html
the section on add_type() should read "When strict is *true (the
default)* the mapping".
----------
components: Documentation
messages: 57636
nosy: kjohnson
severity: minor
status: open
title: Minor error in mimetypes docs
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1463>
__________________________________
From report at bugs.python.org Mon Nov 19 17:32:18 2007
From: report at bugs.python.org (zouguangxian)
Date: Mon, 19 Nov 2007 16:32:18 -0000
Subject: [New-bugs-announce] [issue1464] inet_pton redefined while building
with windows SDK 6.0
Message-ID: <1195489938.2.0.108560909512.issue1464@psf.upfronthosting.co.za>
New submission from zouguangxian:
in Microsoft SDKs\Windows\v6.0A\Include\ws2tcpip.h, inet_pton was
defined when NTDDI_VERSION >= NTDDI_LONGHORN with the following lines:
#if (NTDDI_VERSION >= NTDDI_LONGHORN)
WINSOCK_API_LINKAGE
INT
WSAAPI
inet_pton(
__in INT Family,
__in PCSTR pszAddrString,
__out_bcount(sizeof(IN6_ADDR)) PVOID pAddrBuf
);
... ...
so in socketmodule.c, inet_pton should not be defined in such a
situation.
----------
components: Library (Lib)
files: socketmodule.c.patch
messages: 57639
nosy: weck
severity: normal
status: open
title: inet_pton redefined while building with windows SDK 6.0
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file8775/socketmodule.c.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1464>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: socketmodule.c.patch
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071119/8409f005/attachment.txt
From report at bugs.python.org Mon Nov 19 19:32:56 2007
From: report at bugs.python.org (=?utf-8?q?Erik_Anders=C3=A9n?=)
Date: Mon, 19 Nov 2007 18:32:56 -0000
Subject: [New-bugs-announce] [issue1466] Special reporting of
NotImplementedError in unittest
Message-ID: <1195497176.97.0.346007507072.issue1466@psf.upfronthosting.co.za>
New submission from Erik Anders?n:
When a unittest test case raises an Exception, that test case is
considered a failure. However, raising NotImplementedError is not a
failure. It is something completely normal during development and
simply indicates that the functionality has not yet been implemented.
Compare this to a test case that genuinely fails, which means that the
implementation does something different from what is is supposed to do.
I therefore think test cases raising NotImplementedError should not be
treated as failures, but be reported separately as what they are --
parts of the program that have not yet been implemented. Reporting such
test cases as failures will give a lot of failure warnings that may
detract attention from those cases that are genuinely errors. Also,
SimpleTextRunner will report a lot of useless stack traces for these
cases, thereby makeing it harder to find the stack traces for those
tests that realy failed.
I have made a patch to unittest that reports such cases as "not
implemented" rather than as failures. This includes changes to the
documentation and unit test case for unittest and doctest.
I have included
"added/changed in version 2.6" remarks in the documentation, so
you have to changed these if the patch gets into some other version.
Patch against 59056 attached
----------
components: Library (Lib)
files: unittest.diff
messages: 57648
nosy: erik_andersen
severity: normal
status: open
title: Special reporting of NotImplementedError in unittest
type: rfe
Added file: http://bugs.python.org/file8780/unittest.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unittest.diff
Type: application/octet-stream
Size: 14884 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071119/de680a8e/attachment-0001.obj
From report at bugs.python.org Mon Nov 19 21:23:59 2007
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Mon, 19 Nov 2007 20:23:59 -0000
Subject: [New-bugs-announce] [issue1467] error in TestResult.addError and
TestResult.addFailure
Message-ID: <1195503839.36.0.580839087549.issue1467@psf.upfronthosting.co.za>
New submission from Raghuram Devarakonda:
The page at
http://docs.python.org/dev/library/unittest.html#module-unittest says:
-------------
TestResult.addError(test, err)
Called when the test case test raises an unexpected exception err is
a tuple of the form returned by sys.exc_info(): (type, value, traceback).
The default implementation appends (test, err) to the instance's
errors attribute.
--------------
Starting from 2.2, a formatted traceback is added to the "error"
attribute instead of the actual sys.exc_info(). The same error is
present for addFailure() as well.
----------
components: Documentation
messages: 57663
nosy: draghuram
severity: minor
status: open
title: error in TestResult.addError and TestResult.addFailure
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1467>
__________________________________
From report at bugs.python.org Thu Nov 1 20:48:18 2007
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 01 Nov 2007 19:48:18 -0000
Subject: [New-bugs-announce] [issue1370] Doc changes left over after
mega-merge from trunk
Message-ID: <1193946491.89.0.831882388568.issue1370@psf.upfronthosting.co.za>
New submission from Guido van Rossum:
When merging the trunk into py3k, a large number of Doc changes
appeared, many of which were conflicts. I checked in the non-Doc
changes, and hope that someone else (Georg?) will do the honors of
sorting through the doc changes. Here are the diffs of what I left
unsubmitted, with conflict markers intact. These files have conflicts:
C Doc/c-api/newtypes.rst
C Doc/c-api/abstract.rst
C Doc/reference/compound_stmts.rst
C Doc/reference/expressions.rst
C Doc/tutorial/controlflow.rst
C Doc/tutorial/classes.rst
C Doc/library/inspect.rst
C Doc/library/difflib.rst
C Doc/library/sqlite3.rst
C Doc/library/xmlrpclib.rst
C Doc/library/dis.rst
C Doc/library/stdtypes.rst
C Doc/library/collections.rst
C Doc/library/functions.rst
C Doc/library/exceptions.rst
C Doc/glossary.rst
----------
assignee: georg.brandl
components: Documentation
files: Doc.diff
messages: 57029
nosy: georg.brandl, gvanrossum
priority: urgent
severity: normal
status: open
title: Doc changes left over after mega-merge from trunk
versions: Python 3.0
Added file: http://bugs.python.org/file8673/Doc.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1370>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Doc.diff
Type: text/x-patch
Size: 170279 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071101/ac2a9c6f/attachment-0001.bin
From report at bugs.python.org Mon Nov 19 22:15:46 2007
From: report at bugs.python.org (Paul Moore)
Date: Mon, 19 Nov 2007 21:15:46 -0000
Subject: [New-bugs-announce] [issue1468] MSI installer does not include SSL
test .pem files
Message-ID: <1195506946.17.0.77518817492.issue1468@psf.upfronthosting.co.za>
New submission from Paul Moore:
The latest MSI daily snapshot installer for Python 2.6 (19 Nov) does not
include the .pem files for the SSL tests from the Lib\test directory.
----------
components: Installation
messages: 57666
nosy: pmoore
severity: normal
status: open
title: MSI installer does not include SSL test .pem files
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1468>
__________________________________
From report at bugs.python.org Mon Nov 19 22:16:14 2007
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 19 Nov 2007 21:16:14 -0000
Subject: [New-bugs-announce] [issue1469] SSL tests leak memory
Message-ID: <1195506974.1.0.683741449371.issue1469@psf.upfronthosting.co.za>
New submission from Bill Janssen:
I'm seeing leaks in the test_ssl run, after various socket.py changes.
I'm looking into it.
----------
assignee: janssen
components: Library (Lib)
keywords: py3k
messages: 57667
nosy: janssen
severity: normal
status: open
title: SSL tests leak memory
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1469>
__________________________________
From report at bugs.python.org Tue Nov 20 01:13:13 2007
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 20 Nov 2007 00:13:13 -0000
Subject: [New-bugs-announce] [issue1470] py3k unit tests are removing %TEMP%
dir on Windows
Message-ID: <1195517593.78.0.154207938544.issue1470@psf.upfronthosting.co.za>
New submission from Christian Heimes:
The unit test suite of py3k is removing the official %TEMP% directory of
Windows. It's not only causing errors in the test suite but also
creating havoc with other apps.
I'm not sure if it is related to my PCbuild9 or some changes to the unit
test suite. Since the update to VS 2008 I can't build the PCbuild any
more due to some .NET problems with Nant.
----------
keywords: py3k
messages: 57672
nosy: tiran
priority: urgent
severity: urgent
status: open
title: py3k unit tests are removing %TEMP% dir on Windows
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1470>
__________________________________
From report at bugs.python.org Tue Nov 20 01:27:07 2007
From: report at bugs.python.org (fbvortex)
Date: Tue, 20 Nov 2007 00:27:07 -0000
Subject: [New-bugs-announce] [issue1471] ioctl doesn't work properly on
64-bit OpenBSD
Message-ID: <1195518427.96.0.197538707678.issue1471@psf.upfronthosting.co.za>
New submission from fbvortex:
The following lines of code work on Linux platforms (amd64), and 32-bit
OpenBSD (i386), but not on 64-bit OpenBSD platforms (at least not on
amd64 or sparc64):
import fcntl,os,pty,termios,select,sys,struct,pwd,signal,os
pid,fd=pty.fork()
fcntl.ioctl(fd, termios.TIOCSWINSZ, struct.pack("HHHH",80,25,0,0))
This gives an "IOError: [Errno 25] Inappropriate ioctl for device"
exception.
The python version in question on OpenBSD is:
Python 2.5.1 (r251:54863, Nov 16 2007, 18:16:44)
[GCC 3.3.5 (propolice)] on openbsd4
The winsize structure as dumped using sizeof(struct winsize) under
OpenBSD/sparc64 is 8 bytes large, and so is the result from the
struct.pack operation. Forcing the endianness big or little in the
struct.pack formatting string has no effect on the error.
----------
messages: 57673
nosy: fbvortex
severity: normal
status: open
title: ioctl doesn't work properly on 64-bit OpenBSD
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1471>
__________________________________
From report at bugs.python.org Tue Nov 20 04:27:34 2007
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 20 Nov 2007 03:27:34 -0000
Subject: [New-bugs-announce] [issue1472] Small bat files to build docs on
Windows
Message-ID: <1195529254.24.0.446660522351.issue1472@psf.upfronthosting.co.za>
Changes by Christian Heimes:
----------
keywords: patch, py3k
nosy: tiran
priority: low
severity: normal
status: open
title: Small bat files to build docs on Windows
type: rfe
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1472>
__________________________________
From report at bugs.python.org Tue Nov 20 05:44:28 2007
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 20 Nov 2007 04:44:28 -0000
Subject: [New-bugs-announce] [issue1473] Drop _EXPORTS macros in PCbuild9
Message-ID: <1195533868.85.0.212456448769.issue1473@psf.upfronthosting.co.za>
New submission from Martin v. L?wis:
I believe it is safe to drop all the _EXPORTS macros (MMAP_EXPORTS,
WINSOUND_EXPORRTS etc) from all projects; atleast I cannot see any
reason for having them. Some are clearly bogus, e.g. unicodedata and
test_capi both define MMAP_EXPORTS, _socket defines WINSOUND_EXPORTS,
and _ssl defines _SOCKET_EXPORTS.
----------
assignee: tiran
keywords: py3k
messages: 57693
nosy: loewis, tiran
severity: normal
status: open
title: Drop _EXPORTS macros in PCbuild9
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1473>
__________________________________
From report at bugs.python.org Tue Nov 20 07:59:54 2007
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 20 Nov 2007 06:59:54 -0000
Subject: [New-bugs-announce] [issue1474] PCbuild9 patch for trunk
Message-ID: <1195541994.39.0.585954762191.issue1474@psf.upfronthosting.co.za>
New submission from Christian Heimes:
The patch contains the modifications to PCbuild9, socketmodule and some
structmember.h related files after a svn copy py3k/PCbuild9 trunk/
----------
assignee: tiran
components: Windows
files: trunk_pcbuild9.patch
keywords: patch
messages: 57695
nosy: loewis, tiran
priority: normal
severity: normal
status: open
title: PCbuild9 patch for trunk
versions: Python 2.6
Added file: http://bugs.python.org/file8785/trunk_pcbuild9.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1474>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trunk_pcbuild9.patch
Type: text/x-diff
Size: 6857 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071120/11ff090f/attachment.patch
From report at bugs.python.org Tue Nov 20 08:36:12 2007
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 20 Nov 2007 07:36:12 -0000
Subject: [New-bugs-announce] [issue1475] test_popen fails when the directory
contains a space
Message-ID: <1195544172.34.0.734753003895.issue1475@psf.upfronthosting.co.za>
New submission from Christian Heimes:
Joseph found the bug during his testing of the py3k branch. The problem
is in subprocess.py line 716.
http://pastebin.com/fa947767
----------
assignee: astrand
components: Library (Lib), Tests, Windows
keywords: py3k
messages: 57696
nosy: astrand, joearmbruster, tiran
severity: normal
status: open
title: test_popen fails when the directory contains a space
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1475>
__________________________________
From report at bugs.python.org Tue Nov 20 19:14:03 2007
From: report at bugs.python.org (Joseph Armbruster)
Date: Tue, 20 Nov 2007 18:14:03 -0000
Subject: [New-bugs-announce] [issue1476] missing debug configuration for
make_versioninfo.vcproj
Message-ID: <1195582443.28.0.303313895927.issue1476@psf.upfronthosting.co.za>
New submission from Joseph Armbruster:
Revision: 59073
make_versioninfo.vcproj is missing the debug configuration. As a
result, if you try to build python in debug, you will receive an error
during compile in python_nt.rc, due to this block:
#define MS_WINDOWS
#include "modsupport.h"
#include "patchlevel.h"
#ifdef _DEBUG
# include "pythonnt_rc_d.h"
#else
# include "pythonnt_rc.h"
#endif
This is because the file pythonnt_rc_d.h is never created. The attached
patch should resolve this.
----------
components: Windows
files: pythonnt.patch
messages: 57704
nosy: JosephArmbruster
severity: normal
status: open
title: missing debug configuration for make_versioninfo.vcproj
type: compile error
versions: Python 3.0
Added file: http://bugs.python.org/file8786/pythonnt.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1476>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pythonnt.patch
Type: text/x-diff
Size: 3575 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071120/386f6435/attachment.patch
From report at bugs.python.org Tue Nov 20 22:17:39 2007
From: report at bugs.python.org (Sean B. Palmer)
Date: Tue, 20 Nov 2007 21:17:39 -0000
Subject: [New-bugs-announce] [issue1477] UnicodeDecodeError that cannot be
caught in narrow unicode builds
Message-ID: <1195593459.02.0.388666867716.issue1477@psf.upfronthosting.co.za>
New submission from Sean B. Palmer:
The following error is uncatchable:
>>> try: ur'\U0010FFFF'
... except UnicodeDecodeError: pass
...
UnicodeDecodeError: 'rawunicodeescape' codec can't decode byte 0x5c
in position 0: \Uxxxxxxxx out of range
This is in a narrow unicode build:
>>> sys.version_info, hex(sys.maxunicode)
((2, 5, 1, 'final', 0), '0xffff')
Of course the r in ur'...' is redundant in the test case above, but
there are cases in which it isn't...
>>> ur'\U0010FFFF\test'
u'\U0010ffff\\test'
- from a wide unicode build
>>> ur'\U0010FFFF\test'
UnicodeDecodeError: 'rawunicodeescape' codec can't decode byte 0x5c
in position 0: \Uxxxxxxxx out of range
- from the narrow unicode build
The problem occurs with .decode('raw-unicode-escape') too.
>>> '\U0010FFFF\test'.decode('raw-unicode-escape')
Traceback (most recent call last):
[&c.]
Most surprisingly of all, however, this problem doesn't occur when you
don't use a raw string:
>>> u'\U0010ffff\\test'
u'\U0010ffff\\test'
So there is at least a workaround for all cases, which is why this bug
is marked as Severity: minor. It did take a while to work out that what
manifests with ur mightn't apply to u, however; it's usually one's first
thought to think the bug is with you, not with python.
----------
components: Unicode
messages: 57710
nosy: sbp
severity: minor
status: open
title: UnicodeDecodeError that cannot be caught in narrow unicode builds
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1477>
__________________________________
From report at bugs.python.org Wed Nov 21 01:00:46 2007
From: report at bugs.python.org (Joseph Armbruster)
Date: Wed, 21 Nov 2007 00:00:46 -0000
Subject: [New-bugs-announce] [issue1478] pythoncore.vcproj fails to generate
buildinfo (when spaces in path)
Message-ID: <1195603246.72.0.391132027071.issue1478@psf.upfronthosting.co.za>
New submission from Joseph Armbruster:
Executable path should be quoted, in case build environment is located
in a path containing spaces. I also made the Debug / Release versions
similar in style.
----------
components: Windows
files: pythoncore.patch
messages: 57718
nosy: JosephArmbruster
severity: normal
status: open
title: pythoncore.vcproj fails to generate buildinfo (when spaces in path)
type: compile error
versions: Python 3.0
Added file: http://bugs.python.org/file8789/pythoncore.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1478>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pythoncore.patch
Type: application/octet-stream
Size: 1064 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071121/98218341/attachment.obj
From report at bugs.python.org Wed Nov 21 07:42:11 2007
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 21 Nov 2007 06:42:11 -0000
Subject: [New-bugs-announce] [issue1479] csv module is leaking references
Message-ID: <1195627331.43.0.528300349254.issue1479@psf.upfronthosting.co.za>
New submission from Christian Heimes:
test_csv leaked [1, 1, 1, 1] references, sum=4
----------
components: Extension Modules, Library (Lib)
keywords: py3k
messages: 57728
nosy: tiran
priority: normal
severity: normal
status: open
title: csv module is leaking references
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1479>
__________________________________
From report at bugs.python.org Wed Nov 21 08:19:45 2007
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 21 Nov 2007 07:19:45 -0000
Subject: [New-bugs-announce] [issue1480] sqlite module is leaking lots of
references
Message-ID: <1195629585.82.0.465075974861.issue1480@psf.upfronthosting.co.za>
New submission from Christian Heimes:
test_sqlite leaked [325, 325, 325, 325] references, sum=1300
----------
components: Extension Modules
keywords: py3k
messages: 57729
nosy: tiran
priority: high
severity: normal
status: open
title: sqlite module is leaking lots of references
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1480>
__________________________________
From report at bugs.python.org Wed Nov 21 09:17:48 2007
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 21 Nov 2007 08:17:48 -0000
Subject: [New-bugs-announce] [issue1481] test_uuid is warning about
unreliable functions
Message-ID: <1195633068.63.0.82173012127.issue1481@psf.upfronthosting.co.za>
New submission from Christian Heimes:
I'm putting the report into the tracker as a reminder.
WARNING: uuid.getnode is unreliable on many platforms.
It is disabled until the code and/or test can be fixed properly.
WARNING: uuid._ifconfig_getnode is unreliable on many platforms.
It is disabled until the code and/or test can be fixed properly.
WARNING: uuid._unixdll_getnode is unreliable on many platforms.
It is disabled until the code and/or test can be fixed properly.
----------
components: Library (Lib), Tests
keywords: py3k
messages: 57733
nosy: tiran
priority: normal
severity: normal
status: open
title: test_uuid is warning about unreliable functions
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1481>
__________________________________
From report at bugs.python.org Wed Nov 21 10:27:55 2007
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 21 Nov 2007 09:27:55 -0000
Subject: [New-bugs-announce] [issue1482] IMAP4 SSL isn't working
Message-ID: <1195637275.04.0.129181694073.issue1482@psf.upfronthosting.co.za>
New submission from Christian Heimes:
The SSL version of the imap4 client isnt' working under 3.0. After I
applied the patch from http://bugs.python.org/issue1210 I tried to
connect to an IMAP server over SSL. The connection hangs.
import imaplib
conn = imaplib.IMAP4_SSL("mailbox.rwth-aachen.de", 993)
After a while I stopped the attempt with CTRL+C
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/heimes/dev/python/py3k/Lib/imaplib.py", line 1137, in __init__
IMAP4.__init__(self, host, port)
File "/home/heimes/dev/python/py3k/Lib/imaplib.py", line 184, in __init__
self.welcome = self._get_response()
File "/home/heimes/dev/python/py3k/Lib/imaplib.py", line 907, in
_get_response
resp = self._get_line()
File "/home/heimes/dev/python/py3k/Lib/imaplib.py", line 1000, in
_get_line
line = self.readline()
File "/home/heimes/dev/python/py3k/Lib/imaplib.py", line 1170, in readline
char = self.sslobj.read(1)
File "/home/heimes/dev/python/py3k/Lib/ssl.py", line 160, in read
return self._sslobj.read(len)
KeyboardInterrupt
----------
assignee: janssen
components: Library (Lib)
keywords: py3k
messages: 57735
nosy: janssen, tiran
priority: normal
severity: normal
status: open
title: IMAP4 SSL isn't working
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1482>
__________________________________
From report at bugs.python.org Wed Nov 21 15:03:15 2007
From: report at bugs.python.org (Yitz Gale)
Date: Wed, 21 Nov 2007 14:03:15 -0000
Subject: [New-bugs-announce] [issue1483]
xml.sax.saxutils.prepare_input_source ignores character
stream in InputSource
Message-ID: <1195653795.8.0.542576278207.issue1483@psf.upfronthosting.co.za>
New submission from Yitz Gale:
In the documentation for xml.sax.xmlreader.InputSource objects
(section 8.12.4 of the Library Reference) we find that
users of InputSource objects should use the following
sequence to get their input data:
1. If the InputSource has a character stream, use that.
2. Otherwise, if the InputSource has a byte stream, use that.
3. Otherwise, open a URI connection to the system ID.
prepare_input_source() skips step 1.
This is a one-line fix in Lib/xml/sax/saxutils.py:
- if source.getByteStream() is None:
+ if source.getCharacterStream is None and source.getByteStream() is
None:
----------
components: Library (Lib)
messages: 57737
nosy: ygale
severity: normal
status: open
title: xml.sax.saxutils.prepare_input_source ignores character stream in InputSource
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1483>
__________________________________
From report at bugs.python.org Wed Nov 21 23:41:17 2007
From: report at bugs.python.org (Gidi Avrahami)
Date: Wed, 21 Nov 2007 22:41:17 -0000
Subject: [New-bugs-announce] [issue1484] logging: callHandlers tests handler
levels instead of logger levels?
Message-ID: <1195684877.23.0.0511912191493.issue1484@psf.upfronthosting.co.za>
New submission from Gidi Avrahami:
I am using the logging module with multiple loggers and the following
behavior seems incorrect to me:
I set the root logger's level to WARN and the foo.bar module's logger's
level to DEBUG, and the foo.bar logger should is writing to a file. So
basically, I want foo.bar to log itself in details behind the scenes
while the main console is quiet.
However, I still get all the sebug info printed to the console. When I
trace down the code, I see that callHandlers() is climbing up the logger
hierarchy, but it's comparing record.level to hdlr.level, not to
c.level. The handler levels, however, don't appear to be set normally
(i.e., after I do getLogger("foo.bar").setLevel, its handlers stay at
level NOTSET). As a result, callHandlers will call all the handlers
above the first one, no matter what the loggers level.
Is this intentional? If it is, how should I get the behavior that I
described above? (I could set propagate=False, but in fact if the rott
logger is DEBUG then I do want it to print the foo.bar messages)
----------
components: Library (Lib)
messages: 57741
nosy: gidi_avrahami
severity: normal
status: open
title: logging: callHandlers tests handler levels instead of logger levels?
type: behavior
versions: Python 2.4, Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1484>
__________________________________
From report at bugs.python.org Thu Nov 22 13:23:18 2007
From: report at bugs.python.org (Grant Delaney)
Date: Thu, 22 Nov 2007 12:23:18 -0000
Subject: [New-bugs-announce] [issue1485] Idle tab command completion
Message-ID: <1195734198.15.0.922045875096.issue1485@psf.upfronthosting.co.za>
New submission from Grant Delaney:
Exception in Tkinter callback
Traceback (most recent call last):
File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1403, in __call__
return self.func(*args)
File "/usr/lib/python2.5/idlelib/AutoCompleteWindow.py", line 217, in
winconfig_event
x, y, cx, cy = self.widget.bbox(self.startindex)
File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 2833, in bbox
self.tk.call((self._w, 'bbox') + args)) or None
File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1030, in _getints
return tuple(map(getint, self.tk.splitlist(string)))
ValueError: invalid literal for int() with base 10: '(72,'
----------
components: IDLE
messages: 57757
nosy: Mufasa
severity: normal
status: open
title: Idle tab command completion
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1485>
__________________________________
From report at bugs.python.org Thu Nov 22 14:02:56 2007
From: report at bugs.python.org (Grant Delaney)
Date: Thu, 22 Nov 2007 13:02:56 -0000
Subject: [New-bugs-announce] [issue1486] Idle tab command completion
Message-ID: <1195736576.61.0.960072107154.issue1486@psf.upfronthosting.co.za>
New submission from Grant Delaney:
Running idle from a terminal window in desktop.
Python 2.5.1 (r251:54863, Nov 22 2007, 13:55:16)
[GCC 4.1.2] on linux2
Type "copyright", "credits" or "license()" for more information.
****************************************************************
Personal firewall software may warn about the connection IDLE
makes to its subprocess using this computer's internal loopback
interface. This connection is not visible on any external
interface and no data is sent to or received from the Internet.
****************************************************************
IDLE 1.2.1
>>> import sys
>>> test = sys. <--- pressing tab should give you the available
options for that module/library.
The error in the console is as follows:
Exception in Tkinter callback
Traceback (most recent call last):
File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1403, in __call__
return self.func(*args)
File "/usr/lib/python2.5/idlelib/AutoCompleteWindow.py", line 217, in
winconfig_event
x, y, cx, cy = self.widget.bbox(self.startindex)
File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 2833, in bbox
self.tk.call((self._w, 'bbox') + args)) or None
File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1030, in _getints
return tuple(map(getint, self.tk.splitlist(string)))
ValueError: invalid literal for int() with base 10: '(128,'
Exception in Tkinter callback
Traceback (most recent call last):
File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1403, in __call__
return self.func(*args)
File "/usr/lib/python2.5/idlelib/AutoCompleteWindow.py", line 217, in
winconfig_event
x, y, cx, cy = self.widget.bbox(self.startindex)
File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 2833, in bbox
self.tk.call((self._w, 'bbox') + args)) or None
File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1030, in _getints
return tuple(map(getint, self.tk.splitlist(string)))
ValueError: invalid literal for int() with base 10: '(128,'
Exception in Tkinter callback
Traceback (most recent call last):
File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1403, in __call__
return self.func(*args)
File "/usr/lib/python2.5/idlelib/AutoCompleteWindow.py", line 217, in
winconfig_event
x, y, cx, cy = self.widget.bbox(self.startindex)
File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 2833, in bbox
self.tk.call((self._w, 'bbox') + args)) or None
File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1030, in _getints
return tuple(map(getint, self.tk.splitlist(string)))
ValueError: invalid literal for int() with base 10: '(128,'
----------
components: IDLE
messages: 57759
nosy: Mufasa
severity: normal
status: open
title: Idle tab command completion
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1486>
__________________________________
From report at bugs.python.org Thu Nov 22 15:22:16 2007
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 22 Nov 2007 14:22:16 -0000
Subject: [New-bugs-announce] [issue1487] PEP 366 implementation
Message-ID: <1195741336.57.0.571137300726.issue1487@psf.upfronthosting.co.za>
New submission from Nick Coghlan:
Patch to implement PEP 366.
Note that it doesn't implement precisely the semantics described in the
version of the PEP posted in July, as some of those ideas didn't prove
feasible due to the fact that imp.new_module can't tell the difference
between normal modules and packages.
An updated version of the PEP will be posted shortly to correct those
problems.
----------
components: Interpreter Core, Library (Lib)
files: pep_366_v1.diff
keywords: patch
messages: 57761
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: PEP 366 implementation
type: rfe
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file8794/pep_366_v1.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1487>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pep_366_v1.diff
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071122/0ca3515c/attachment.txt
From report at bugs.python.org Thu Nov 22 19:41:50 2007
From: report at bugs.python.org (Joseph Armbruster)
Date: Thu, 22 Nov 2007 18:41:50 -0000
Subject: [New-bugs-announce] [issue1488] PCBuild9 _ssl.vcproj improperly
launches build
Message-ID: <1195756910.13.0.910588506266.issue1488@psf.upfronthosting.co.za>
New submission from Joseph Armbruster:
When you attempt to build the _ssl project in release or debug you can
possibly encounter errors in the following scenarios:
1) having spaces in the build path
2) if you launch the build in debug, it attempts to run build_ssl.py
with the python.exe found in the path rather than that just built named
python_d.exe. I believe the solution was designed to run build_ssl.py
with the binary that was built in the configuration. If this is
correct, then this patch applies.
3) some of the dependency paths did not appear to point to the correct
place. Please verify.
See attached patch
----------
components: Windows
files: sslbuild.patch
messages: 57763
nosy: JosephArmbruster, tiran
severity: normal
status: open
title: PCBuild9 _ssl.vcproj improperly launches build
type: compile error
versions: Python 3.0
Added file: http://bugs.python.org/file8795/sslbuild.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1488>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sslbuild.patch
Type: application/octet-stream
Size: 2067 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071122/373277c3/attachment-0001.obj
From report at bugs.python.org Thu Nov 22 22:23:11 2007
From: report at bugs.python.org (Paul Moore)
Date: Thu, 22 Nov 2007 21:23:11 -0000
Subject: [New-bugs-announce] [issue1489] test_socket_ssl hanhs on Windows
(deadlock)
Message-ID: <1195766591.59.0.212085206705.issue1489@psf.upfronthosting.co.za>
New submission from Paul Moore:
When running the test suite on Windows, test_socket_ssl hangs.
After a bit of investigation, it appears that the test is hanging at
line 184 (if self.s.stdout.readline() != "ERROR\n":) in
OpenSSLServer._external.
The problem is that the test assumes it can read a line of stdout from
the openssl.exe process. However, the openssl.exe on my PC (from the
GnuWin32 project) appears to buffer its output, so the Python process
deadlocks waiting for a response.
An easy (if clumsy) fix is to simply skip the check on the output of the
server. I have attached a patch which does this for win32 only (on the
assumption that other platforms don't have this issue).
I guess that other openssl builds don't have the same problem - however,
I can't see an easy way of testing for this.
----------
components: Tests
files: test_socket_ssl.diff
messages: 57768
nosy: pmoore
severity: normal
status: open
title: test_socket_ssl hanhs on Windows (deadlock)
versions: Python 2.6
Added file: http://bugs.python.org/file8796/test_socket_ssl.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1489>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_socket_ssl.diff
Type: application/octet-stream
Size: 801 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071122/30a5a751/attachment.obj
From report at bugs.python.org Fri Nov 23 05:40:31 2007
From: report at bugs.python.org (Arunkumar)
Date: Fri, 23 Nov 2007 04:40:31 -0000
Subject: [New-bugs-announce] [issue1490] Bug in eval() function
Message-ID: <1195792830.97.0.696373913002.issue1490@psf.upfronthosting.co.za>
New submission from Arunkumar:
PythonWin 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win32.
Portions Copyright 1994-2006 Mark Hammond - see 'Help/About PythonWin'
for further copyright information.
>>>
>>>
>>> eval("02*2")
4
>>>
>>> eval("08*2")
Traceback (most recent call last):
File "<interactive input>", line 1, in <module>
File "<string>", line 1
08*2
^
SyntaxError: invalid token
>>> eval("09*2")
Traceback (most recent call last):
File "<interactive input>", line 1, in <module>
File "<string>", line 1
09*2
^
SyntaxError: invalid token
>>>
>>>
>>> eval("07*2")
14
>>>
>>> eval("010*2")
16
>>> eval("9*2")
18
>>>
----------
messages: 57769
nosy: arunkumarrajan
severity: urgent
status: open
title: Bug in eval() function
type: compile error
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1490>
__________________________________
From report at bugs.python.org Fri Nov 23 13:52:40 2007
From: report at bugs.python.org (samwyse)
Date: Fri, 23 Nov 2007 12:52:40 -0000
Subject: [New-bugs-announce] [issue1491] BaseHTTPServer incorrectly
implements response code 100
Message-ID: <1195822360.07.0.215272908737.issue1491@psf.upfronthosting.co.za>
New submission from samwyse:
RFC 2616 sec 8.2.3 states, "An origin server that sends a 100 (Continue)
response MUST ultimately send a final status code, once the request body
is received and processed, unless it terminates the transport connection
prematurely." The obvious way to do this is to invoke the
'send_response' method twice, once with a code of 100, then with the
final code. However, BaseHTTPServer will always send two headers
('Server' and 'Date') when it send a response. One possible fix is to
add an option to the method to suppress sending headers; another is to
add the following code to the 'send_response' method, immediately prior
to the calls to 'self.send_header':
if code == 100:
return
The more paranoid among us may wish to use this code instead:
if code == 100:
expectation = self.headers.get('Expect', "")
if expectation.lower() == '100-continue':
return
----------
components: Library (Lib)
messages: 57783
nosy: samwyse
severity: normal
status: open
title: BaseHTTPServer incorrectly implements response code 100
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1491>
__________________________________
From report at bugs.python.org Fri Nov 23 14:04:07 2007
From: report at bugs.python.org (samwyse)
Date: Fri, 23 Nov 2007 13:04:07 -0000
Subject: [New-bugs-announce] [issue1492] BaseHTTPServer hard-codes
Content-Type for error messages
Message-ID: <1195823047.2.0.185836867459.issue1492@psf.upfronthosting.co.za>
New submission from samwyse:
The send_error method always sends a Content-Type of 'text/html'. Other
content types are both possible and desirable. For example, someone
writing a REST server might wish to send XML error messages. Following
the example of DEFAULT_ERROR_MESSAGE, I propose adding the following in
the appropriate places:
91a92,94
> # Default error content-type
> DEFAULT_ERROR_TYPE = 'text/html'
>
345c348
< self.send_header("Content-Type", "text/html")
---
> self.send_header("Content-Type", error_message_type)
351a355
> error_message_type = DEFAULT_ERROR_TYPE
----------
messages: 57784
nosy: samwyse
severity: normal
status: open
title: BaseHTTPServer hard-codes Content-Type for error messages
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492>
__________________________________
From report at bugs.python.org Sat Nov 24 07:50:34 2007
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 24 Nov 2007 06:50:34 -0000
Subject: [New-bugs-announce] [issue1493] Patch to remove unbound methods
Message-ID: <1195887033.53.0.361766903132.issue1493@psf.upfronthosting.co.za>
New submission from Christian Heimes:
Here is a first patch to remove unbound method objects.
6 tests failed:
test_descr test_inspect test_pyclbr test_typechecks test_unittest
test_weakref
----------
assignee: gvanrossum
components: Interpreter Core
files: py3k_remove_unbound.patch
keywords: patch, py3k
messages: 57798
nosy: gvanrossum, tiran
priority: high
severity: normal
status: open
title: Patch to remove unbound methods
type: rfe
versions: Python 3.0
Added file: http://bugs.python.org/file8799/py3k_remove_unbound.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1493>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k_remove_unbound.patch
Type: text/x-diff
Size: 12503 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071124/140b3cc4/attachment.patch
From report at bugs.python.org Sat Nov 24 17:09:51 2007
From: report at bugs.python.org (Christopher Denter)
Date: Sat, 24 Nov 2007 16:09:51 -0000
Subject: [New-bugs-announce] [issue1494] DOM-Documentation should mention
that appendChild() removes the child it appends
Message-ID: <1195920591.84.0.811892323535.issue1494@psf.upfronthosting.co.za>
Changes by Christopher Denter:
----------
components: Documentation
nosy: dennda
severity: normal
status: open
title: DOM-Documentation should mention that appendChild() removes the child it appends
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1494>
__________________________________
From report at bugs.python.org Sat Nov 24 22:00:40 2007
From: report at bugs.python.org (Magnus Valle)
Date: Sat, 24 Nov 2007 21:00:40 -0000
Subject: [New-bugs-announce] [issue1495] Unicode in a comment.
Message-ID: <1195938040.58.0.768947830961.issue1495@psf.upfronthosting.co.za>
New submission from Magnus Valle:
My script reports this problem:
"""
$ python bug.py
File "bug.py", line 4
SyntaxError: Non-ASCII character '\xc2' in file bug.py on line 4, but no
encoding declared; see http://www.python.org/peps/pep-0263.html for details
"""
This error looks fine and all, but the problem is that the non-ASCII
character (in this case '?') is in a comment, not in the script itself.
If I remove it the non-ASCII character from the comment, it runs perfectly.
I always assumed that comment didn't effect the script.
This isn't exactly a big problem, but I don't think it should be this way.
I included the demo script.
PS.
$ python -V
Python 2.5.1
----------
components: Unicode
files: bug.py
messages: 57817
nosy: wiscados
severity: minor
status: open
title: Unicode in a comment.
versions: Python 2.5
Added file: http://bugs.python.org/file8803/bug.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1495>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug.py
Type: text/x-python
Size: 93 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071124/c6b09051/attachment.py
From report at bugs.python.org Sun Nov 25 02:24:45 2007
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 25 Nov 2007 01:24:45 -0000
Subject: [New-bugs-announce] [issue1496] add str.maketrans()
Message-ID: <1195953885.52.0.314966183764.issue1496@psf.upfronthosting.co.za>
New submission from Georg Brandl:
This patch restores old behavior of str.translate() and adds the
str.maketrans() static method. Docs and tests will follow if this is the
right way to go.
----------
assignee: gvanrossum
files: str-maketrans.diff
messages: 57823
nosy: georg.brandl, gvanrossum
priority: normal
severity: normal
status: open
title: add str.maketrans()
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8804/str-maketrans.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1496>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: str-maketrans.diff
Type: application/pgp-signature
Size: 7371 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071125/f87bc167/attachment.pgp
From report at bugs.python.org Sun Nov 25 12:31:41 2007
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 25 Nov 2007 11:31:41 -0000
Subject: [New-bugs-announce] [issue1497] Patch to remove API to create new
unbound methods
Message-ID: <1195990301.82.0.071232495691.issue1497@psf.upfronthosting.co.za>
Changes by Christian Heimes:
----------
components: Interpreter Core
files: py3k_remove_newunbound.patch
keywords: patch, py3k
nosy: georg.brandl, tiran
priority: high
severity: normal
status: open
title: Patch to remove API to create new unbound methods
versions: Python 3.0
Added file: http://bugs.python.org/file8805/py3k_remove_newunbound.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1497>
__________________________________
From report at bugs.python.org Mon Nov 26 18:50:43 2007
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 26 Nov 2007 17:50:43 -0000
Subject: [New-bugs-announce] [issue1498] Rename __builtins__ to
__root_namespace__?
Message-ID: <1196099443.21.0.514185525416.issue1498@psf.upfronthosting.co.za>
New submission from Guido van Rossum:
In http://bugs.python.org/issue1774369 I mentioned that I wanted to
rename __builtins__ to __rootns__. Though right now I think something
longer and less cryptic might be better. The reason is to avoid for
once and for all the confusion between __builtin__, which is a module,
and __builtins__, a feature mainly used by sandboxing to pass the set of
builtins to be used via the global namespace. This lay at the heart of
the referenced bug.
I'm still in favor of this but haven't had the time to investigate how
much work it would be.
----------
messages: 57842
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: Rename __builtins__ to __root_namespace__?
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1498>
__________________________________
From report at bugs.python.org Mon Nov 26 20:23:00 2007
From: report at bugs.python.org (Achim Gaedke)
Date: Mon, 26 Nov 2007 19:23:00 -0000
Subject: [New-bugs-announce] [issue1499] failure behaviour of compile() is
missing
Message-ID: <1196104980.32.0.085401481115.issue1499@psf.upfronthosting.co.za>
New submission from Achim Gaedke:
Regarding the compile() function in html/lib/built-in-funcs.html:
Please add a note about the exceptions raised by this function.
----------
components: Documentation
messages: 57850
nosy: AchimGaedke
severity: minor
status: open
title: failure behaviour of compile() is missing
versions: Python 2.4, Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1499>
__________________________________
From report at bugs.python.org Mon Nov 26 21:51:30 2007
From: report at bugs.python.org (Steve Jones)
Date: Mon, 26 Nov 2007 20:51:30 -0000
Subject: [New-bugs-announce] [issue1500] Example using range doesn't give
claimed results
Message-ID: <1196110290.45.0.0321063926451.issue1500@psf.upfronthosting.co.za>
New submission from Steve Jones:
See for yourself, on
http://docs.python.org/tut/node6.html
*************************************
>>> for n in range(2, 10):
... for x in range(2, n):
... if n % x == 0:
... print n, 'equals', x, '*', n/x
... break
... else:
... # loop fell through without finding a factor
... print n, 'is a prime number'
...
2 is a prime number ----- this bit is wrong
3 is a prime number
4 equals 2 * 2
5 is a prime number
6 equals 2 * 3
7 is a prime number
8 equals 2 * 4
9 equals 3 * 3
----------
components: Documentation
messages: 57852
nosy: basingwerk
severity: minor
status: open
title: Example using range doesn't give claimed results
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1500>
__________________________________
From report at bugs.python.org Mon Nov 26 22:19:32 2007
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 26 Nov 2007 21:19:32 -0000
Subject: [New-bugs-announce] [issue1501] 0 ** 0 documentation
Message-ID: <1196111972.15.0.594136146103.issue1501@psf.upfronthosting.co.za>
New submission from Jim Jewett:
http://docs.python.org/lib/typesnumeric.html contains a table listing the
mathematical operators. Please add a note to the final row (x ** y meaning
x to the power y) indicating that Python has chosen to define 0**0==1
Note 6: Python defines 0**0 to be 1. For background, please see http://
en.wikipedia.org/wiki/Exponentiation#Zero_to_the_zero_power
This doc change should have prevented issue 1461; I *think* there have been
similar issues in the past.
----------
components: Documentation
messages: 57855
nosy: jimjjewett
severity: minor
status: open
title: 0 ** 0 documentation
type: rfe
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1501>
__________________________________
From report at bugs.python.org Tue Nov 27 00:42:24 2007
From: report at bugs.python.org (Chris Mellon)
Date: Mon, 26 Nov 2007 23:42:24 -0000
Subject: [New-bugs-announce] [issue1502] itertools should grow chunkify
Message-ID: <1196120544.69.0.372337623499.issue1502@psf.upfronthosting.co.za>
New submission from Chris Mellon:
One of the most common requests in c.l.p and #python is a way to break
an iterable up into some particular size chunks. For example, "abcdef"
-> "ab", "cd", "ef". It's pretty easy to write one, but there are a few
subtleties to it (like if you want padding or partial results) and it's
so common that having it in the stdlib would be nice.
Attached is a patch which implements itertools.chunkify. It can
optionally discard, pad, or return any leftovers in the source iterable.
Tests and docstrings are included, but it needs to be documented in the
manual. One thing it does not do, but maybe it should, is guess what
type the yielded values should have based on the input sequence - it
always returns lists.
Patch is against trunk, r59186.
----------
components: Library (Lib)
files: chunkify.patch
messages: 57861
nosy: arkanes
severity: normal
status: open
title: itertools should grow chunkify
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file8811/chunkify.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1502>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: chunkify.patch
Type: application/octet-stream
Size: 8257 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071126/c50f5f4a/attachment.obj
From report at bugs.python.org Tue Nov 27 02:23:19 2007
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 27 Nov 2007 01:23:19 -0000
Subject: [New-bugs-announce] [issue1503] test_xmlrpc is still flakey
Message-ID: <1196126599.89.0.0637627606597.issue1503@psf.upfronthosting.co.za>
New submission from Guido van Rossum:
See e.g.:
http://www.python.org/dev/buildbot/3.0/ppc%20Debian%20unstable%203.0/builds/303/step-test/0
Note how it fails the first time and passes on the re-run. I've seen
this before (just not on any of my own systems). I've also seen it fail
twice (on buildbot machines).
----------
messages: 57864
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: test_xmlrpc is still flakey
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1503>
__________________________________
From report at bugs.python.org Tue Nov 27 12:18:41 2007
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 27 Nov 2007 11:18:41 -0000
Subject: [New-bugs-announce] [issue1504] Add 2to3 fixer for (un)bound methods
Message-ID: <1196162321.58.0.597340041678.issue1504@psf.upfronthosting.co.za>
New submission from Christian Heimes:
Todo:
im_self -> __self__
im_func -> __func__
im_class -> __self__.__class__
instancemethod(func, self, cls) -> instancemethod(func, self)
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
keywords: py3k
messages: 57870
nosy: collinwinter, tiran
severity: normal
status: open
title: Add 2to3 fixer for (un)bound methods
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1504>
__________________________________
From report at bugs.python.org Tue Nov 27 14:02:37 2007
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 27 Nov 2007 13:02:37 -0000
Subject: [New-bugs-announce] [issue1505] Changes to PyMethod_New breaks
ctypes on Windows
Message-ID: <1196168557.19.0.782884662226.issue1505@psf.upfronthosting.co.za>
New submission from Christian Heimes:
The problem is in _ctypes.c:create_comerror() around line 4620.
----------
assignee: theller
components: Extension Modules, Windows
keywords: py3k
messages: 57871
nosy: theller, tiran
priority: high
severity: normal
status: open
title: Changes to PyMethod_New breaks ctypes on Windows
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1505>
__________________________________
From report at bugs.python.org Tue Nov 27 22:15:13 2007
From: report at bugs.python.org (Maarten Thibaut)
Date: Tue, 27 Nov 2007 21:15:13 -0000
Subject: [New-bugs-announce] [issue1506] func alloca inside ctypes lib needs
#include <alloca.h> on solaris
Message-ID: <1196198113.99.0.416874193784.issue1506@psf.upfronthosting.co.za>
Changes by Maarten Thibaut:
----------
components: Library (Lib)
nosy: mthibaut
severity: normal
status: open
title: func alloca inside ctypes lib needs #include <alloca.h> on solaris
type: compile error
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1506>
__________________________________
From report at bugs.python.org Tue Nov 27 23:25:12 2007
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 27 Nov 2007 22:25:12 -0000
Subject: [New-bugs-announce] [issue1507] complex constructor loses signs of
zeros
Message-ID: <1196202312.79.0.339731037994.issue1507@psf.upfronthosting.co.za>
New submission from Mark Dickinson:
In Python2.5 and the current trunk, construction of a complex number from two floats
loses the negative sign of a negative zero in the imaginary part.
>>> complex(-0., 0.).real # behaves as expected
-0.0
>>> complex(0., -0.).imag # loses sign of zero
0.0
There are situations where it's important to preserve the sign of zero (typically
when doing calculations involving functions with branch cuts); there are probably
platforms where this is difficult for one reason or another, but on a platform that
complies with all the usual standards I can't see any reason for Python not to
preserve the signs of zeros, provided that it's straightforward to do so.
The attached patch changes the complex constructor so that if x and y are numeric
and neither x nor y is complex (or a subclass of complex) then complex(x, y) simply
places x into the real part of the complex number and y into the imaginary part.
For someone who doesn't care about the sign of zeros, this patch will have no
noticeable effect. Similarly, on a system that does not have full hardware or
system support for signed zeros, this patch should be harmless. Note that the patch
does *not* change the feature that complex(z1, z2) returns z1 + 1j*z2 when z1 and/or
z2 is itself complex.
There was some previous discussion of this on python-dev earlier this year. See
http://mail.python.org/pipermail/python-dev/2007-January/070770.html
----------
files: complex_new.patch
messages: 57891
nosy: marketdickinson
severity: normal
status: open
title: complex constructor loses signs of zeros
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file8815/complex_new.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1507>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: complex_new.patch
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071127/e3e69a97/attachment.txt
From report at bugs.python.org Wed Nov 28 00:09:58 2007
From: report at bugs.python.org (Joseph Armbruster)
Date: Tue, 27 Nov 2007 23:09:58 -0000
Subject: [New-bugs-announce] [issue1508] Removal of stale code in _csv.c /
pyexpat.c
Message-ID: <1196204998.62.0.0437576024742.issue1508@psf.upfronthosting.co.za>
New submission from Joseph Armbruster:
I found two code blocks that look as if they can be safely removed:
>From _csv.c:
/* begin 2.2 compatibility macros */
#ifndef PyDoc_STRVAR
/* Define macros for inline documentation. */
#define PyDoc_VAR(name) static char name[]
#define PyDoc_STRVAR(name,str) PyDoc_VAR(name) = PyDoc_STR(str)
#ifdef WITH_DOC_STRINGS
#define PyDoc_STR(str) str
#else
#define PyDoc_STR(str) ""
#endif
#endif /* ifndef PyDoc_STRVAR */
>From pyexpat.c:
#ifndef PyDoc_STRVAR
/*
* fdrake says:
* Don't change the PyDoc_STR macro definition to (str), because
* '''the parentheses cause compile failures
* ("non-constant static initializer" or something like that)
* on some platforms (Irix?)'''
*/
#define PyDoc_STR(str) str
#define PyDoc_VAR(name) static char name[]
#define PyDoc_STRVAR(name,str) PyDoc_VAR(name) = PyDoc_STR(str)
#endif
----------
components: Extension Modules
messages: 57895
nosy: JosephArmbruster
severity: minor
status: open
title: Removal of stale code in _csv.c / pyexpat.c
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1508>
__________________________________
From report at bugs.python.org Wed Nov 28 03:10:42 2007
From: report at bugs.python.org (Peter Mawhorter)
Date: Wed, 28 Nov 2007 02:10:42 -0000
Subject: [New-bugs-announce] [issue1509] Documentation lacking for the
sqlite3 module.
Message-ID: <1196215842.85.0.855394455026.issue1509@psf.upfronthosting.co.za>
New submission from Peter Mawhorter:
The current documentation for the sqlite3 module on the web fails to
make any mention of the fetch* functions posessed by the Cursor class
of that module. It in fact gives no indication of how one should
extract results from sql queries. The docstrings in the module (viewed
using the help() function) are woefully incomplete, and are
inconsistent with the function names:
| fetchall(...)
| Fetches one row from the resultset.
|
| fetchmany(...)
| Fetches all rows from the resultset.
|
| fetchone(...)
| Fetches several rows from the resultset.
|
Both of these things need to be fixed in order for this module to be
useful for someone who doesn't already know how to use it.
----------
components: Extension Modules
messages: 57900
nosy: pmawhorter
severity: minor
status: open
title: Documentation lacking for the sqlite3 module.
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1509>
__________________________________
From report at bugs.python.org Wed Nov 28 06:00:44 2007
From: report at bugs.python.org (cfk)
Date: Wed, 28 Nov 2007 05:00:44 -0000
Subject: [New-bugs-announce] [issue1510] help for file/open should state
which is prefered.
Message-ID: <1196226044.27.0.136551028633.issue1510@psf.upfronthosting.co.za>
New submission from cfk:
bltinmodule.c:
PyDoc_STRVAR(open_doc,
"open(name[, mode[, buffering]]) -> file object\n\
\n\
Open a file using the file() type, returns a file object.");
Help for file() is detailed, which would lead people to use file over
open. given that file() is removed in py3k, I think that should be
mentioned in the current file() docstring, and swap the help for file/open.
----------
components: Documentation
messages: 57901
nosy: carlfk
severity: minor
status: open
title: help for file/open should state which is prefered.
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1510>
__________________________________
From report at bugs.python.org Wed Nov 28 06:15:17 2007
From: report at bugs.python.org (Bill Fenner)
Date: Wed, 28 Nov 2007 05:15:17 -0000
Subject: [New-bugs-announce] [issue1511] csv input converts \r\n to \n but
csv output does not when a field has internal line breaks
Message-ID: <1196226917.03.0.0879630569127.issue1511@psf.upfronthosting.co.za>
New submission from Bill Fenner:
When a field has internal line breaks, e.g.,
foo,"bar
baz
biff",boo
that is actually 3 lines, but one csv-file row. csv.reader() converts
this to ['foo', 'bar\nbaz\nbiff', 'boo']. This is a reasonable
behavior.
Unfortunately, csv.writer() does not use the dialect's lineterminator
setting for values with such internal linebreaks. This means that the
resulting file will have a mix of line-termination styles:
foo,"bar\n
baz\n
biff",boo\r\n
If the reading csv implementation is strict about its line termination,
these line breaks will not be read properly.
----------
messages: 57902
nosy: fenner
severity: normal
status: open
title: csv input converts \r\n to \n but csv output does not when a field has internal line breaks
type: behavior
versions: Python 2.4
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1511>
__________________________________
From report at bugs.python.org Wed Nov 28 15:14:07 2007
From: report at bugs.python.org (Joseph Armbruster)
Date: Wed, 28 Nov 2007 14:14:07 -0000
Subject: [New-bugs-announce] [issue1512] Removal of stale code in pyconfig.h
Message-ID: <1196259247.47.0.175425290011.issue1512@psf.upfronthosting.co.za>
New submission from Joseph Armbruster:
Question: Is there any harm in removing this block from pyconfig.h?
#ifndef PY_LONG_LONG
# define PY_LONG_LONG __int64
# define PY_LLONG_MAX _I64_MAX
# define PY_LLONG_MIN _I64_MIN
# define PY_ULLONG_MAX _UI64_MAX
#endif
pyconfig.h contains this small snippet:
/* 64 bit ints are usually spelt __int64 unless compiler has overridden */
#define HAVE_LONG_LONG 1
#ifndef PY_LONG_LONG
# define PY_LONG_LONG __int64
# define PY_LLONG_MAX _I64_MAX
# define PY_LLONG_MIN _I64_MIN
# define PY_ULLONG_MAX _UI64_MAX
#endif
However, in pyport.h, I can see that PY_LONG_LONG may also be defined
here, except the tokens are slightly different:
#ifdef HAVE_LONG_LONG
#ifndef PY_LONG_LONG
#define PY_LONG_LONG long long
#if defined(LLONG_MAX)
/* If LLONG_MAX is defined in limits.h, use that. */
#define PY_LLONG_MIN LLONG_MIN
#define PY_LLONG_MAX LLONG_MAX
#define PY_ULLONG_MAX ULLONG_MAX
#elif defined(__LONG_LONG_MAX__)
/* Otherwise, if GCC has a builtin define, use that. */
#define PY_LLONG_MAX __LONG_LONG_MAX__
#define PY_LLONG_MIN (-PY_LLONG_MAX-1)
#define PY_ULLONG_MAX (__LONG_LONG_MAX__*2ULL + 1ULL)
#else
/* Otherwise, rely on two's complement. */
#define PY_ULLONG_MAX (~0ULL)
#define PY_LLONG_MAX ((long long)(PY_ULLONG_MAX>>1))
#define PY_LLONG_MIN (-PY_LLONG_MAX-1)
#endif /* LLONG_MAX */
#endif
#endif /* HAVE_LONG_LONG */
----------
components: Build
messages: 57913
nosy: JosephArmbruster, tiran
severity: minor
status: open
title: Removal of stale code in pyconfig.h
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1512>
__________________________________
From report at bugs.python.org Wed Nov 28 17:25:09 2007
From: report at bugs.python.org (Joseph Armbruster)
Date: Wed, 28 Nov 2007 16:25:09 -0000
Subject: [New-bugs-announce] [issue1513] object.c do_compare comparison
ordering error
Message-ID: <1196267109.95.0.653970377186.issue1513@psf.upfronthosting.co.za>
New submission from Joseph Armbruster:
URL: http://svn.python.org/projects/python/branches/py3k
Rev: 59215
Session illustrating issue:
>>> a = None
[40667 refs]
>>> cmp(a,None)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: NoneType() < NoneType()
[40715 refs]
Resolution: It appears the equality comparison in do_compare should take
place first, otherwise a TypeError thwarts the desired comparison.
rt.bat Results (I can only test core, since I do not have the third
party libs here):
Failed tests before change:
test_ctypes test_mailbox
Failed tests after change:
test_copy test_ctypes test_mailbox
test_copy is failing because of this block:
def test_deepcopy_reflexive_dict(self):
x = {}
x['foo'] = x
y = copy.deepcopy(x)
self.assertRaises(TypeError, cmp, y, x)
self.assert_(y is not x)
self.assert_(y['foo'] is y)
self.assertEqual(len(y), 1)
A RuntimeError now occurs instead.
self.assertRaises(RuntimeError, cmp, y, x)
Additional Patch Note:
If this is a valid patch, please add a comment prior to the code change
that indicates the EQ test is first for a good reason.
----------
components: Interpreter Core
files: noneEquality.patch
messages: 57914
nosy: JosephArmbruster, loewis, tiran
severity: normal
status: open
title: object.c do_compare comparison ordering error
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8818/noneEquality.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1513>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: noneEquality.patch
Type: text/x-diff
Size: 844 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071128/4214730e/attachment.patch
From report at bugs.python.org Wed Nov 28 22:07:32 2007
From: report at bugs.python.org (David Binger)
Date: Wed, 28 Nov 2007 21:07:32 -0000
Subject: [New-bugs-announce] [issue1514] missing constants in socket module
Message-ID: <1196284052.76.0.985131774299.issue1514@psf.upfronthosting.co.za>
New submission from David Binger:
TCP_NODELAY and some constants are not present in the socket module.
I think maybe "#include <netinet/tcp.h>" should appear somewhere,
perhaps at the top of socketmodule.c?
(This is on OS X 10.5.1 with py3k revision 59215).
----------
components: Library (Lib), Macintosh
messages: 57921
nosy: dbinger
severity: normal
status: open
title: missing constants in socket module
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1514>
__________________________________
From report at bugs.python.org Thu Nov 29 01:41:00 2007
From: report at bugs.python.org (Michael Van Biesbrouck)
Date: Thu, 29 Nov 2007 00:41:00 -0000
Subject: [New-bugs-announce] [issue1515] deepcopy doesn't copy instance
methods
Message-ID: <1196296860.13.0.0113919656838.issue1515@psf.upfronthosting.co.za>
New submission from Michael Van Biesbrouck:
Currently, using deepcopy on instance methods causes an exception to be
thrown. This can be fixed by adding one line to copy.py:
d[types.MethodType] = _deepcopy_atomic
This will not make duplicate copies of mutable values referenced within
the instance method (such as its associated instance), but it will be
the same as the handling of other function types (which have the same
problem).
----------
messages: 57923
nosy: mlvanbie
severity: normal
status: open
title: deepcopy doesn't copy instance methods
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1515>
__________________________________
From report at bugs.python.org Thu Nov 29 01:52:59 2007
From: report at bugs.python.org (Greg Couch)
Date: Thu, 29 Nov 2007 00:52:59 -0000
Subject: [New-bugs-announce] [issue1516] make _ctypes work with non-gcc
compilers
Message-ID: <1196297579.57.0.775741892495.issue1516@psf.upfronthosting.co.za>
New submission from Greg Couch:
To get _ctypes to sucessfully compile with native UNIX compilers (i.e.,
not gcc), several modifications need to be made: (1) use the equivalent
of the Py_GCC_ATTRIBUTE macro for __attribute__ (in ffi.h), (2) include
<ffi_common.h> in callproc.c to conditionally include <alloca.h>, and
(3) modify distutils to know something about assembly language files.
The attached patch is a starting point for the proper patch. It fixes
bugs (1) and (2), but I was unable to figure out the last tweek to get
distutils to work with gcc and native compilers.
The problem with _ctypes comes from the use of gcc's libffi. And libffi
uses assembly language source files for the various supported platforms
and distutils blindly compiles the .S files. Native UNIX compilers want
a .s suffix and if the files are renamed, distutils skips the file. I
tried modifying distutils to compile .s files and give the '-x
assembler-with-cpp' flag to gcc so gcc would still work, but the right
tweek evaded me. So I'm hoping someone can take this and turn it into
something better or make helpful suggestions (other than switching to gcc!).
----------
files: _ctypes.diffs
messages: 57924
nosy: gregcouch
severity: normal
status: open
title: make _ctypes work with non-gcc compilers
versions: Python 2.6
Added file: http://bugs.python.org/file8819/_ctypes.diffs
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1516>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: _ctypes.diffs
Type: application/octet-stream
Size: 8031 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071129/b0afaf1b/attachment.obj
From report at bugs.python.org Thu Nov 29 02:41:10 2007
From: report at bugs.python.org (Adam Olsen)
Date: Thu, 29 Nov 2007 01:41:10 -0000
Subject: [New-bugs-announce] [issue1517] lookdict should INCREF/DECREF
startkey around PyObject_RichCompareBool
Message-ID: <1196300470.07.0.800454639703.issue1517@psf.upfronthosting.co.za>
New submission from Adam Olsen:
(thanks go to my partner in crime, jorendorff, for helping flesh this out.)
lookdict calls PyObject_RichCompareBool without using INCREF/DECREF on
the key passed. It's possible for the comparison to delete the key from
the dict, causing its own argument to be deallocated. This can lead to
bogus results or a crash.
A custom type with its own __eq__ method will implicitly INCREF the key
when passing it as an argument, which prevents incorrect behaviour from
manifesting. There are a couple ways around this though, as shown in my
attachment.
----------
components: Interpreter Core
files: dictbug.py
messages: 57925
nosy: rhamphoryncus
severity: normal
status: open
title: lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool
Added file: http://bugs.python.org/file8820/dictbug.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1517>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dictbug.py
Type: text/x-python
Size: 2071 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071129/68ebbf6f/attachment-0001.py
From report at bugs.python.org Thu Nov 29 10:43:57 2007
From: report at bugs.python.org (Neil Toronto)
Date: Thu, 29 Nov 2007 09:43:57 -0000
Subject: [New-bugs-announce] [issue1518] Fast globals/builtins access (patch)
Message-ID: <1196329437.66.0.0945045609125.issue1518@psf.upfronthosting.co.za>
New submission from Neil Toronto:
I've attached a patch that reduces LOAD_GLOBAL access time by 19% for
globals and 45% for builtins. In my tests, that's barely slower than
LOAD_FAST in both cases.
The approach is to cache pointers to dictionary entries rather than
caching dictionary values as is usually suggested. Dictionaries keep a
64-bit "version" internally that is incremented whenever at least one
entry pointer would become invalid. PyFastGlobalsObject is a
dictionary adapter, allowing quick access to it using an index instead
of a key object. It ensures that its entry pointers are always valid
(by comparing a stored version number against the dictionary's) before
retrieving values from them.
A script of microbenchmarks, fastglobals_test.py, is included in the
patch. My dual-core Intel T2300 1.66GHz on Ubuntu 7.04 (compiled
with -DNDEBUG -g -O3), gets the following results:
Test 2.6a0 trunk 2.6a0 fastglobals % time
---- ----------- ----------------- ----------
Dict ins/del (100000) 41.27 41.59 1.01
Dict get (100000) 21.37 21.35 1.00
Dict set (100000) 21.36 21.33 1.00
Local get (1000000) 15.64 15.60 1.00
Local set (1000000) 16.83 16.94 1.01
Global get (1000000) 21.09 17.04 0.81*
Global set (1000000) 34.15 22.80 0.67*
Builtin get (1000000) 30.99 17.04 0.55*
Function call (100000) 32.87 33.00 1.00
Listcomp (100000) 28.65 25.17 0.88*
Pystone 1.1 (500000) 12.46 11.68 0.94*
PYBENCH 2.0 9.10 9.05 0.99
(* = probably significant)
All regressions that aren't skipped pass except test_gc. I've probably
got a refcount issue or unbreakable cycle somewhere.
----------
components: Interpreter Core
files: fastglobals.patch.txt
messages: 57927
nosy: ntoronto
severity: normal
status: open
title: Fast globals/builtins access (patch)
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file8821/fastglobals.patch.txt
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1518>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fastglobals.patch.txt
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071129/41d6298e/attachment-0001.txt
From report at bugs.python.org Thu Nov 29 15:20:58 2007
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 29 Nov 2007 14:20:58 -0000
Subject: [New-bugs-announce] [issue1519] async_chat.__init__() parameters
Message-ID: <1196346058.65.0.25106672712.issue1519@psf.upfronthosting.co.za>
New submission from Nadeem Vawda:
The __init__() function for asynchat.async_chat doesn't allow the caller
to specify a channel map. I thought it would make sense to add an
optional 'map' parameter, for consistency with asyncore.dispatcher. If
the parameter is not specified, asyncore.dispatcher.__init__() will
default to using the global map, which is the current behaviour.
----------
components: Library (Lib)
files: asynchat.patch
messages: 57930
nosy: nvawda
severity: minor
status: open
title: async_chat.__init__() parameters
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file8822/asynchat.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1519>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asynchat.patch
Type: application/octet-stream
Size: 666 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071129/3531fb02/attachment.obj
From report at bugs.python.org Thu Nov 29 16:15:31 2007
From: report at bugs.python.org (Joseph Armbruster)
Date: Thu, 29 Nov 2007 15:15:31 -0000
Subject: [New-bugs-announce] [issue1520] 'without make' documentation build
anomaly
Message-ID: <1196349331.67.0.490031647679.issue1520@psf.upfronthosting.co.za>
New submission from Joseph Armbruster:
When I run the following from a windows command line, the resulting html
can not be browsed stand-alone:
python tools/sphinx-build.py -bhtml . build/htmlwin
It looks like the paths are getting hosed up; for example:
htmlcygwin/c-api/index.html contains:
<link rel="stylesheet" href="../style/default.css" type="text/css">
<link rel="stylesheet" href="../style/pygments.css" type="text/css">
htmlcmd/c-api/index.html contains:
<link rel="stylesheet" href="style/default.css" type="text/css">
<link rel="stylesheet" href="style/pygments.css" type="text/css">
Notes:
These seemed to work fine:
- building target html it in cygwin using make
- building target html in cygwin without make
- building target htmlhelp in cmd without make then generating chm
----------
components: Documentation, Documentation tools (Sphinx)
messages: 57931
nosy: JosephArmbruster
severity: minor
status: open
title: 'without make' documentation build anomaly
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1520>
__________________________________
From report at bugs.python.org Thu Nov 29 16:33:06 2007
From: report at bugs.python.org (Andreas Eisele)
Date: Thu, 29 Nov 2007 15:33:06 -0000
Subject: [New-bugs-announce] [issue1521] string.decode() fails on long
strings
Message-ID: <1196350386.46.0.0641290280607.issue1521@psf.upfronthosting.co.za>
New submission from Andreas Eisele:
s.decode("utf-8")
sometimes silently truncates the result if s has more than 2E9 Bytes,
sometimes raises a fairly incomprehensible exception:
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
File "/usr/lib64/python2.5/encodings/utf_8.py", line 16, in decode
return codecs.utf_8_decode(input, errors, True)
TypeError: utf_8_decode() argument 1 must be (unspecified), not str
----------
components: Unicode
messages: 57932
nosy: eisele
severity: normal
status: open
title: string.decode() fails on long strings
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1521>
__________________________________
From report at bugs.python.org Thu Nov 29 17:27:34 2007
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 29 Nov 2007 16:27:34 -0000
Subject: [New-bugs-announce] [issue1522] pyvm module patch
Message-ID: <1196353654.85.0.895576631974.issue1522@psf.upfronthosting.co.za>
New submission from Christian Heimes:
I've created a pyvm module for Python 3.0. So far it just contains a
bunch of internal types. What methods do you like to add to pyvm?
Somebody suggested internal functions from sys like the check internal.
----------
components: Extension Modules, Interpreter Core
files: py3k_pyvm.patch
keywords: patch, py3k
messages: 57937
nosy: gvanrossum, tiran
priority: normal
severity: normal
status: open
title: pyvm module patch
versions: Python 3.0
Added file: http://bugs.python.org/file8824/py3k_pyvm.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1522>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k_pyvm.patch
Type: text/x-diff
Size: 4175 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071129/3c20bc98/attachment.patch
From report at bugs.python.org Thu Nov 29 18:15:12 2007
From: report at bugs.python.org (Jack Lloyd)
Date: Thu, 29 Nov 2007 17:15:12 -0000
Subject: [New-bugs-announce] [issue1523] xdrlib fails to detect overflow
(struct bug?)
Message-ID: <1196356512.02.0.767950905039.issue1523@psf.upfronthosting.co.za>
New submission from Jack Lloyd:
The XDR format requires integers to fit into 4 byte values. However (at
least on x86-64) xdrlib will silently accept (and truncate) values
larger than this (up to 2**64-1). Taking a (very brief) look at the
xdrlib code, it appears this is actually a problem in the struct module,
but I don't have the time (or interest) to trace through the _struct
module code.
An example on an x86-64 machine (Python 2.4.3) of encoding 2**32 (which
will not fit in an XDR field) being silently truncated:
$ ./xdr.py
4294967296 -> 00000000 -> 0
An example of struct itself not detecting overflow:
>>> struct.pack("!I", 2**32)
'\x00\x00\x00\x00'
struct.pack will only throw an overflow error if a value >= 2**64 is
used, even if it is encoding into a field that is much smaller.
----------
components: Extension Modules
files: xdr.py
messages: 57939
nosy: lloyd
severity: normal
status: open
title: xdrlib fails to detect overflow (struct bug?)
type: behavior
versions: Python 2.4
Added file: http://bugs.python.org/file8825/xdr.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1523>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xdr.py
Type: application/octet-stream
Size: 417 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071129/48bdbeb1/attachment.obj
From report at bugs.python.org Thu Nov 29 21:16:56 2007
From: report at bugs.python.org (Guy Mott)
Date: Thu, 29 Nov 2007 20:16:56 -0000
Subject: [New-bugs-announce] [issue1524] os.system() fails for commands with
multiple quoted file names
Message-ID: <1196367416.9.0.40290581495.issue1524@psf.upfronthosting.co.za>
New submission from Guy Mott:
Given a call to os.system() with a command string like this:
os.system('"TheCommand" > "MyOutput"') # fails
then the call fails with the following error message on the console:
'TheCommand" > "MyOutput' is not recognized as an internal or
external command, operable program or batch file.
Note that both the executable file name and the redirected output file
name are quoted.
Apparently the command string is being parsed and the first quote is
incorrectly being matched with the last quote. A more general statement
of this bug might say that multiple quoted fields on a command line
cause os.system() to fail. I have not done enough research to better
characterize the problem.
By contrast, if only one of the file names is quoted then the call to
os.system() succeeds. E.g., these calls succeed:
os.system('TheCommand > "MyOutput"') # succeeds
os.system('"TheCommand" > MyOutput') # succeeds
Of course this is a simplified example where it is not necessary to
quote either file name. Real world examples include 2 file names with
imbedded spaces. E.g.:
os.system('"The Command" > "My Output"') # fails
'The' is not recognized as an internal or external command, operable
program or batch file.
A further real-world example is a command line with full path
specifications for both the executable file and the output file. Such
path specifications may include imbedded spaces so both need to be
quoted. However, quoting both causes os.system() to fail. E.g.:
os.system(r'"C:\New Folder\TheCommand" > "C:\New Folder\MyOutput"')
# fails
'C:\New' is not recognized as an internal or external command,
operable program or batch file.
The above described scenario is the situation in the attached script
that includes logic for finding an executable file that may not be
found on the system path but is co-located with the Python script file.
Thus the script and its companion file(s) may be moved from machine to
machine and will work correctly even if not in a directory that is
included on the system path. The script fails because the command line
that it constructs, with executable and output file specifications
quoted, fails in os.system().
Here is output from running the attached script:
-----------------------------------------------
C:\New Folder>buggy.py
strCmdLine=["ListMetadata" > "20071129Metadata.txt"]
'ListMetadata" > "20071129Metadata.txt' is not recognized as an
internal or external command,
operable program or batch file.
Could not find "ListMetadata" on path, looking in script directory
strCmdLine=["C:\New Folder\ListMetadata" > "20071129Metadata.txt"]
'C:\New' is not recognized as an internal or external command,
operable program or batch file.
Traceback (most recent call last):
File "C:\New Folder\buggy.py", line 16, in <module>
raise Exception("Could not locate command")
Exception: Could not locate command
-----------------------------------------------
Note that the command line that is constructed by the attached script
runs just fine and produces the desired result if it is executed
directly at a command line prompt. It is when executed via os.system()
that the command line fails.
Testing environment:
OS = Windows XP Professional
Python = 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)]
----------
components: Extension Modules, Windows
files: buggy.py
messages: 57952
nosy: Quigon
severity: major
status: open
title: os.system() fails for commands with multiple quoted file names
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file8828/buggy.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1524>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: buggy.py
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071129/6b47f572/attachment-0001.txt
From report at bugs.python.org Fri Nov 30 11:00:44 2007
From: report at bugs.python.org (canhuth)
Date: Fri, 30 Nov 2007 10:00:44 -0000
Subject: [New-bugs-announce] [issue1525] Executing Python script using
subprocess.Popen twice interactively fails without error the
second time
Message-ID: <1196416844.07.0.705173497041.issue1525@psf.upfronthosting.co.za>
New submission from canhuth:
Executing script using subprocess.Popen twice interactively fails
without error the second time. File a.py:
print "start"
import subprocess
print "first call"
process = subprocess.Popen(
args = "cmd.exe /c echo 1",
stdout = subprocess.PIPE)
for line in process.stdout:
if not line:
break;
print line;
print "second call"
process = subprocess.Popen(
args = "cmd.exe /c echo 2",
stdout = subprocess.PIPE)
for line in process.stdout:
if not line:
break;
print line;
print "end"
Executing it in Python on Windows, interactively:
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import a
start
first call
1
second call
2
end
>>> import a
>>>
----------
components: Windows
messages: 57971
nosy: canhuth
severity: normal
status: open
title: Executing Python script using subprocess.Popen twice interactively fails without error the second time
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1525>
__________________________________
From report at bugs.python.org Fri Nov 30 14:26:20 2007
From: report at bugs.python.org (Alexander Belchenko)
Date: Fri, 30 Nov 2007 13:26:20 -0000
Subject: [New-bugs-announce] [issue1526] DeprecationWarning in zipfile.py
while zipping 113000 files
Message-ID: <1196429180.06.0.658057999985.issue1526@psf.upfronthosting.co.za>
Changes by Alexander Belchenko:
----------
nosy: bialix
severity: normal
status: open
title: DeprecationWarning in zipfile.py while zipping 113000 files
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1526>
__________________________________
From report at bugs.python.org Fri Nov 30 18:12:28 2007
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 30 Nov 2007 17:12:28 -0000
Subject: [New-bugs-announce] [issue1527] Problem with static libs on Windows
Message-ID: <1196442748.41.0.438893728508.issue1527@psf.upfronthosting.co.za>
New submission from Christian Heimes:
patrickkidd (IRC nick) has reported a problem with creating a static
libraries on Windows. He suggested the appended patch.
----------
assignee: loewis
components: Windows
files: trunk_staticlib.patch
keywords: patch, py3k
messages: 57991
nosy: loewis, tiran
severity: normal
status: open
title: Problem with static libs on Windows
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file8835/trunk_staticlib.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1527>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trunk_staticlib.patch
Type: text/x-diff
Size: 434 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071130/a813e5ea/attachment.patch
From report at bugs.python.org Fri Nov 30 20:17:35 2007
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 30 Nov 2007 19:17:35 -0000
Subject: [New-bugs-announce] [issue1528] Add os.fchmod
Message-ID: <1196450255.5.0.78965588115.issue1528@psf.upfronthosting.co.za>
New submission from Guido van Rossum:
Modern Unix systems have a fchmod() system call, which is like chmod()
but takes a file descriptor instead of a filename. Python's os module
(via the posix module) should support this if it exists on the target
platform.
----------
messages: 57997
nosy: gvanrossum
severity: normal
status: open
title: Add os.fchmod
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1528>
__________________________________
From report at bugs.python.org Fri Nov 30 22:16:52 2007
From: report at bugs.python.org (George Notaras)
Date: Fri, 30 Nov 2007 21:16:52 -0000
Subject: [New-bugs-announce] [issue1529] Error when passing a file object to
tarfile.open()
Message-ID: <1196457412.25.0.63807751084.issue1529@psf.upfronthosting.co.za>
New submission from George Notaras:
Assume a healthy uncompressed tar file: a.tar
When trying to open the tarfile using a fileobject, there is always an
exception:
>>> f_raw = open("a.tar", "rb")
>>> import tarfile
>>> f_tar = tarfile.open(mode="r:", fileobj=f_raw)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.5/tarfile.py", line 1157, in open
return func(name, filemode, fileobj)
File "/usr/lib/python2.5/tarfile.py", line 1183, in taropen
return cls(name, mode, fileobj)
File "/usr/lib/python2.5/tarfile.py", line 1047, in __init__
self.name = os.path.abspath(name)
File "/usr/lib/python2.5/posixpath.py", line 402, in abspath
if not isabs(path):
File "/usr/lib/python2.5/posixpath.py", line 49, in isabs
return s.startswith('/')
AttributeError: 'NoneType' object has no attribute 'startswith'
----------
components: Extension Modules
messages: 58011
nosy: GeorgeNotaras
severity: normal
status: open
title: Error when passing a file object to tarfile.open()
type: crash
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1529>
__________________________________
From report at bugs.python.org Fri Nov 30 23:25:29 2007
From: report at bugs.python.org (Miki Tebeka)
Date: Fri, 30 Nov 2007 22:25:29 -0000
Subject: [New-bugs-announce] [issue1530] doctest should return error if not
all tests passed
Message-ID: <1196461529.28.0.0768640953007.issue1530@psf.upfronthosting.co.za>
New submission from Miki Tebeka:
python -mdoctest mymodule should return an error to the OS when a test
fails.
See patch.
----------
components: Library (Lib)
files: doctest.py.diff
messages: 58020
nosy: tebeka
severity: normal
status: open
title: doctest should return error if not all tests passed
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file8838/doctest.py.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1530>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: doctest.py.diff
Type: text/x-patch
Size: 991 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071130/ce8ebc64/attachment.bin