From report at bugs.python.org Fri Aug 1 02:17:05 2008
From: report at bugs.python.org (Dominique Parolin)
Date: Fri, 01 Aug 2008 00:17:05 +0000
Subject: [New-bugs-announce] [issue3481] Length of struct.pack('HL', 1,
1) incorrect (8 instead of 6 bytes)
In-Reply-To: <1217549825.77.0.356584888827.issue3481@psf.upfronthosting.co.za>
Message-ID: <1217549825.77.0.356584888827.issue3481@psf.upfronthosting.co.za>
New submission from Dominique Parolin <d.parolin at gmx.net>:
Python Versions tested:
Windows 2.5.2 (r252:60911)
Debian Linux Python 2.4.4
Example:
>>> import struct
>>> struct.pack('HL', 1, 1)
results in '\x01\x00\x00\x00\x01\x00\x00\x00'
although '\x01\x00\x01\x00\x00\x00' was expected.
if concatenated or done separately
>>> struct.pack('H', 1) + struct.pack('L', 1)
result is as expected '\x01\x00\x01\x00\x00\x00'
or
'\x01\x00' and '\x01\x00\x00\x00' respectively
Error:
Length is 8 where it should be 6
This is as well true for "hl", "hL" and "Hl".
Free description:
I could not find another error regarding that, nor any information using
popular search.
Further no explanation found why that might be valid behaviour.
Regards,
Dominique
----------
components: Library (Lib)
messages: 70535
nosy: dparolin
severity: normal
status: open
title: Length of struct.pack('HL', 1,1) incorrect (8 instead of 6 bytes)
type: behavior
versions: Python 2.4, Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3481>
_______________________________________
From report at bugs.python.org Fri Aug 1 09:20:22 2008
From: report at bugs.python.org (Benoit Thiell)
Date: Fri, 01 Aug 2008 07:20:22 +0000
Subject: [New-bugs-announce] [issue3482] re.split,
re.sub and re.subn should support flags
In-Reply-To: <1217575222.11.0.84305922701.issue3482@psf.upfronthosting.co.za>
Message-ID: <1217575222.11.0.84305922701.issue3482@psf.upfronthosting.co.za>
New submission from Benoit Thiell <badzil at gmail.com>:
Given that the search operations support flags, it seems natural for a
developer that the other functions in the module support flags as well.
So when running "re.split(pattern, string, re.I)", the split() command
seems to not work and don't return a message error (I understand that
're.I' is understood as 'maxsplit=0'.)
This is confusing and I think that it should be changed so that all
functions in the module are consistent.
----------
messages: 70543
nosy: benoit
severity: normal
status: open
title: re.split, re.sub and re.subn should support flags
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3482>
_______________________________________
From report at bugs.python.org Fri Aug 1 18:06:08 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 01 Aug 2008 16:06:08 +0000
Subject: [New-bugs-announce] [issue3483] sys.stdin.read won't return on EOF
In-Reply-To: <1217606768.05.0.96179990455.issue3483@psf.upfronthosting.co.za>
Message-ID: <1217606768.05.0.96179990455.issue3483@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
$ ./python.exe -c "import sys; sys.stdin.read()"
^D
In 2.6, this returns, but in 3.0, it still hangs despite having gotten
EOF. When a KeyboardInterrupt is given, this is the traceback:
^CTraceback (most recent call last):
File "<string>", line 1, in <module>
File "/temp/python/py3k/Lib/io.py", line 1692, in read
decoder.decode(self.buffer.read(), final=True))
File "/temp/python/py3k/Lib/io.py", line 923, in read
chunk = self.raw.read()
KeyboardInterrupt
----------
components: Library (Lib)
messages: 70565
nosy: benjamin.peterson
priority: release blocker
severity: normal
status: open
title: sys.stdin.read won't return on EOF
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3483>
_______________________________________
From report at bugs.python.org Fri Aug 1 18:26:09 2008
From: report at bugs.python.org (Rob Cakebread)
Date: Fri, 01 Aug 2008 16:26:09 +0000
Subject: [New-bugs-announce] [issue3484] Sphinx tests fail because of
missing dir
In-Reply-To: <1217607969.56.0.300706889583.issue3484@psf.upfronthosting.co.za>
Message-ID: <1217607969.56.0.300706889583.issue3484@psf.upfronthosting.co.za>
New submission from Rob Cakebread <cakebread at gmail.com>:
When I try to run the unit tests with tests/run.py they fail because
this directory is missing: tests/root/_build
If I simply create the directory and run the tests, they pass.
Running Sphinx test suite...
EEE...
======================================================================
ERROR: test_config.test_core_config
----------------------------------------------------------------------
Traceback (most recent call last):
File "/usr/lib/python2.5/site-packages/nose/case.py", line 182, in runTest
self.test(*self.arg)
File
"/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/test_config.py",
line 20, in test_core_config
cfg = TestApp(confoverrides=overrides).config
File
"/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/util.py",
line 106, in __init__
freshenv)
File
"/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/sphinx/application.py",
line 101, in __init__
self.builder = builderclass(self, freshenv=freshenv)
File
"/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/sphinx/builder.py",
line 58, in __init__
os.mkdir(self.doctreedir)
OSError: [Errno 2] No such file or directory:
'/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/root/_build/doctrees'
======================================================================
ERROR: test_config.test_extension_values
----------------------------------------------------------------------
Traceback (most recent call last):
File "/usr/lib/python2.5/site-packages/nose/case.py", line 182, in runTest
self.test(*self.arg)
File
"/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/test_config.py",
line 65, in test_extension_values
app = TestApp()
File
"/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/util.py",
line 106, in __init__
freshenv)
File
"/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/sphinx/application.py",
line 101, in __init__
self.builder = builderclass(self, freshenv=freshenv)
File
"/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/sphinx/builder.py",
line 58, in __init__
os.mkdir(self.doctreedir)
OSError: [Errno 2] No such file or directory:
'/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/root/_build/doctrees'
======================================================================
ERROR: Failure: OSError ([Errno 2] No such file or directory:
'/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/root/_build/doctrees')
----------------------------------------------------------------------
Traceback (most recent call last):
File "/usr/lib/python2.5/site-packages/nose/loader.py", line 364, in
loadTestsFromName
addr.filename, addr.module)
File "/usr/lib/python2.5/site-packages/nose/importer.py", line 39, in
importFromPath
return self.importFromDir(dir_path, fqname)
File "/usr/lib/python2.5/site-packages/nose/importer.py", line 84, in
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
File
"/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/test_markup.py",
line 21, in <module>
app = TestApp()
File
"/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/util.py",
line 106, in __init__
freshenv)
File
"/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/sphinx/application.py",
line 101, in __init__
self.builder = builderclass(self, freshenv=freshenv)
File
"/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/sphinx/builder.py",
line 58, in __init__
os.mkdir(self.doctreedir)
OSError: [Errno 2] No such file or directory:
'/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/root/_build/doctrees'
----------------------------------------------------------------------
Ran 6 tests in 3.785s
FAILED (errors=3)
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 70567
nosy: cakebread, georg.brandl
severity: normal
status: open
title: Sphinx tests fail because of missing dir
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3484>
_______________________________________
From report at bugs.python.org Fri Aug 1 19:16:06 2008
From: report at bugs.python.org (Isaac Morland)
Date: Fri, 01 Aug 2008 17:16:06 +0000
Subject: [New-bugs-announce] [issue3485] os.path.normcase
documentation/behaviour unclear on Mac OS X
In-Reply-To: <1217610966.27.0.918507533161.issue3485@psf.upfronthosting.co.za>
Message-ID: <1217610966.27.0.918507533161.issue3485@psf.upfronthosting.co.za>
New submission from Isaac Morland <ijmorlan at uwaterloo.ca>:
$ python
Python 2.5.1 (r251:54863, Apr 15 2008, 22:57:26)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from os.path import normcase
>>> normcase ('aB')
'aB'
>>>
>From http://docs.python.org/lib/module-os.path.html: "On Unix, this
returns the path unchanged; on case-insensitive filesystems, it converts
the path to lowercase." Of course, Mac OS X is both Unix and
case-insensitive, which is a rather bizarre combination, but that's it
is. Where is the item for "make all file systems case-sensitive, put
the case-insensitivity in the user interface"?
----------
components: Macintosh
messages: 70571
nosy: ijmorlan
severity: normal
status: open
title: os.path.normcase documentation/behaviour unclear on Mac OS X
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3485>
_______________________________________
From report at bugs.python.org Fri Aug 1 19:47:30 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Aug 2008 17:47:30 +0000
Subject: [New-bugs-announce] [issue3486] bytes.join does not accept a
sequence of bytearrays
In-Reply-To: <1217612850.46.0.924257550681.issue3486@psf.upfronthosting.co.za>
Message-ID: <1217612850.46.0.924257550681.issue3486@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
This works in py3k but not in 2.x. I don't know if it is deliberate:
Python 3.0b2+ (py3k, Jul 27 2008, 12:52:40)
[GCC 4.3.1 20080626 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> b"".join([bytearray(b"")])
b''
Python 2.6b2+ (trunk, Aug 1 2008, 01:47:52)
[GCC 4.3.1 20080626 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> b"".join([bytearray(b"")])
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: sequence item 0: expected string, bytearray found
----------
components: Interpreter Core
messages: 70573
nosy: pitrou
priority: normal
severity: normal
status: open
title: bytes.join does not accept a sequence of bytearrays
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3486>
_______________________________________
From report at bugs.python.org Fri Aug 1 19:53:32 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 01 Aug 2008 17:53:32 +0000
Subject: [New-bugs-announce] [issue3487] sre "bytecode" verifier
In-Reply-To: <1217613212.91.0.751968430358.issue3487@psf.upfronthosting.co.za>
Message-ID: <1217613212.91.0.751968430358.issue3487@psf.upfronthosting.co.za>
New submission from Guido van Rossum <guido at python.org>:
Attached is a verifier for the binary code used by the _sre module (this
is often called bytecode, though to distinguish it from Python bytecode
I put it in quotes).
I wrote this for Google App Engine, and am making the patch available as
open source under the Apache 2 license. Below are the copyright
statement and license, for completeness.
Barry, I'm assigning this to you only so that you can decide whether
this is okay to check in before beta3. The patch works for 2.6 as well
as for 3.0 (and even for 2.5, but I don't think it's worth changing that
-- or is it?). If you agree (which I hope you will do), please assign
back to me with instructions and I'll submit it. The performance impact
is minimal: it only runs when the compiled "bytecode" is passed from the
re compiler (written in Python) to the C code, during the sre
compilation stage. All tests pass. We've had this code in use in App
Engine since April without complaints.
# Copyright 2008 Google Inc.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
It's not necessary to include these copyrights and bytecode in the
source file. Google has signed a contributor's agreement with the PSF
already.
----------
assignee: barry
files: sre-verifier.diff
keywords: patch, patch
messages: 70574
nosy: barry, gvanrossum
priority: release blocker
severity: normal
status: open
title: sre "bytecode" verifier
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11030/sre-verifier.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3487>
_______________________________________
From report at bugs.python.org Fri Aug 1 19:56:56 2008
From: report at bugs.python.org (Anand B Pillai)
Date: Fri, 01 Aug 2008 17:56:56 +0000
Subject: [New-bugs-announce] [issue3488] Provide compress/uncompress
functions on the gzip module
In-Reply-To: <1217613416.28.0.352724086622.issue3488@psf.upfronthosting.co.za>
Message-ID: <1217613416.28.0.352724086622.issue3488@psf.upfronthosting.co.za>
New submission from Anand B Pillai <abpillai at gmail.com>:
Python has great in-built support for all sorts of text compression
including bzip, gzip, tarfile and other general purpose modules like
zlib etc.
Of these, I have a gripe with gzip - it does not provide a simple
way of compressing/uncompressing a string like the other modules
to (namely bzip, zlib) at the module level.
It is relatively easy to perform gzip de-compression using the
GzipFile class and StringIO objects, but compression is not
that straight-forward.
It would be great for the gzip module to have "compress"
and "uncompress" functions at the module level without having
to go through GzipFile every-time.
I think being able to send gzip compressed strings directly would be
useful for applications which require to send gzip data over the wire
without having to write to files and read-back.
----------
components: Library (Lib)
messages: 70578
nosy: pythonhacker
severity: normal
status: open
title: Provide compress/uncompress functions on the gzip module
type: feature request
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3488>
_______________________________________
From report at bugs.python.org Fri Aug 1 19:57:58 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Aug 2008 17:57:58 +0000
Subject: [New-bugs-announce] [issue3489] add rotate{left,
right} methods to bytearray
In-Reply-To: <1217613478.49.0.00141126667538.issue3489@psf.upfronthosting.co.za>
Message-ID: <1217613478.49.0.00141126667538.issue3489@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
While tweaking the BufferedWriter implementation it came to me that it
would be useful to have rotate_left and rotate_right methods on
bytearray, so as to rotate the array by a number of bytes without any
wasteful memory allocations and copies.
(or, if memoryview is one day implemented it could be a memoryview
method instead...)
----------
components: Interpreter Core
messages: 70579
nosy: pitrou
priority: normal
severity: normal
status: open
title: add rotate{left,right} methods to bytearray
type: feature request
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3489>
_______________________________________
From report at bugs.python.org Sat Aug 2 04:54:19 2008
From: report at bugs.python.org (Adam)
Date: Sat, 02 Aug 2008 02:54:19 +0000
Subject: [New-bugs-announce] [issue3490] Example Code Error in Tutorial
Documentation
In-Reply-To: <1217645659.61.0.258873000656.issue3490@psf.upfronthosting.co.za>
Message-ID: <1217645659.61.0.258873000656.issue3490@psf.upfronthosting.co.za>
New submission from Adam <yoshokun at gmail.com>:
In section 4.4 of the Python Tutorial
(http://docs.python.org/tut/node6.html) there is a code example using
prime numbers that results extraneous output. The else is incorrectly
indented one tab too far to the right and is nested under (for x in
range) rather than (for n in range).
Current:
>>> 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'
...
Correct:
>>> 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'
...
----------
assignee: georg.brandl
components: Documentation
messages: 70613
nosy: georg.brandl, yoshokun
severity: normal
status: open
title: Example Code Error in Tutorial Documentation
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3490>
_______________________________________
From report at bugs.python.org Sat Aug 2 04:59:59 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 02 Aug 2008 02:59:59 +0000
Subject: [New-bugs-announce] [issue3491] compile error fixing
(_multiprocessing, windows)
In-Reply-To: <1217645999.36.0.923455204468.issue3491@psf.upfronthosting.co.za>
Message-ID: <1217645999.36.0.923455204468.issue3491@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:
This will fix the compile error on buildbot. Thank you.
----------
components: Windows
files: fix_compile_error.patch
keywords: patch, patch
messages: 70615
nosy: ocean-city
severity: normal
status: open
title: compile error fixing (_multiprocessing, windows)
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file11036/fix_compile_error.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3491>
_______________________________________
From report at bugs.python.org Sat Aug 2 12:15:59 2008
From: report at bugs.python.org (Anand B Pillai)
Date: Sat, 02 Aug 2008 10:15:59 +0000
Subject: [New-bugs-announce] [issue3492] Zlib compress/decompress functions
returning bytearray
In-Reply-To: <1217672159.34.0.803781605821.issue3492@psf.upfronthosting.co.za>
Message-ID: <1217672159.34.0.803781605821.issue3492@psf.upfronthosting.co.za>
New submission from Anand B Pillai <abpillai at gmail.com>:
>>> import zlib
>>> s='This is a string'
>>> sc=zlib.compress(s)
>>> sc
bytearray(b'x\x9c\x0b\xc9\xc8,V\x00\xa2D\x85\xe2\x92\xa2\xcc\xbct\x00/\xc2\x05\xcd')
>>> zlib.decompress(sc)
bytearray(b'This is a string')
>>>
This is wrong behavior as compress functions should return byte
,not a bytearray. Same for decompress.
----------
components: Library (Lib)
messages: 70625
nosy: pythonhacker
severity: normal
status: open
title: Zlib compress/decompress functions returning bytearray
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3492>
_______________________________________
From report at bugs.python.org Sat Aug 2 21:03:48 2008
From: report at bugs.python.org (Marc Rambert)
Date: Sat, 02 Aug 2008 19:03:48 +0000
Subject: [New-bugs-announce] [issue3493] No Backslash (\) in IDLE 1.2.2
In-Reply-To: <1217703828.28.0.450562077127.issue3493@psf.upfronthosting.co.za>
Message-ID: <1217703828.28.0.450562077127.issue3493@psf.upfronthosting.co.za>
New submission from Marc Rambert <rambert.marc at free.fr>:
With my MacBook, on IDLE application, I can't type any character like this
one \.
----------
components: IDLE
messages: 70637
nosy: Marc67
severity: normal
status: open
title: No Backslash (\) in IDLE 1.2.2
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3493>
_______________________________________
From report at bugs.python.org Sat Aug 2 21:11:17 2008
From: report at bugs.python.org (Fabio Zadrozny)
Date: Sat, 02 Aug 2008 19:11:17 +0000
Subject: [New-bugs-announce] [issue3494] "[Errno 11] Resource temporarily
unavailable" while using tracing facility/threads (in linux
listdir with unicode path)
In-Reply-To: <1217704277.74.0.0700671746724.issue3494@psf.upfronthosting.co.za>
Message-ID: <1217704277.74.0.0700671746724.issue3494@psf.upfronthosting.co.za>
New submission from Fabio Zadrozny <fabioz at users.sourceforge.net>:
A bug has been reported against pydev complaining about os.listdir()
failing while debugging (with a unicode path).
The link for that is:
http://sourceforge.net/tracker/index.php?func=detail&aid=2012138&group_id=85796&atid=577329
After trying to find its cause, it appears that pydev is exercising a
python bug (which is reproduced in the file attached). I have no idea
why that's happening.
I've reproduced it in python 2.4 and python 2.5 under ubuntu 6.10, but I
believe it happens on other versions too -- the original bug was
reported in Ubuntu 8.04 AMD64 Hardy Heron)
----------
components: Interpreter Core, Library (Lib)
files: listdir_problem.py
messages: 70638
nosy: fabioz
severity: normal
status: open
title: "[Errno 11] Resource temporarily unavailable" while using tracing facility/threads (in linux listdir with unicode path)
type: crash
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file11039/listdir_problem.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3494>
_______________________________________
From report at bugs.python.org Sun Aug 3 02:09:01 2008
From: report at bugs.python.org (Ian Stokes-Rees)
Date: Sun, 03 Aug 2008 00:09:01 +0000
Subject: [New-bugs-announce] [issue3495] site module doc typo
In-Reply-To: <1217722141.33.0.0489020423949.issue3495@psf.upfronthosting.co.za>
Message-ID: <1217722141.33.0.0489020423949.issue3495@psf.upfronthosting.co.za>
New submission from Ian Stokes-Rees <ijstokes at alumni.uwaterloo.ca>:
http://docs.python.org/lib/module-site.html | sed -e "s/2.3/2.5/g"
----------
assignee: georg.brandl
components: Documentation
messages: 70647
nosy: georg.brandl, ijstokes
severity: normal
status: open
title: site module doc typo
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3495>
_______________________________________
From report at bugs.python.org Sun Aug 3 18:12:57 2008
From: report at bugs.python.org (Paul Moore)
Date: Sun, 03 Aug 2008 16:12:57 +0000
Subject: [New-bugs-announce] [issue3496] distutils fails with mingw binutils
2.18.50.20080109
In-Reply-To: <1217779977.05.0.102107142392.issue3496@psf.upfronthosting.co.za>
Message-ID: <1217779977.05.0.102107142392.issue3496@psf.upfronthosting.co.za>
New submission from Paul Moore <p.f.moore at gmail.com>:
The latest version of Mingw binutils, 2.18.50.20080109, uses a 4-part
version number which distutils does not like (StrictVersion only allows
for 3 parts).
The attached patch fixes this, simply by using LooseVersion (the version
number has already been checked to be a series of numbers in the regex
check just previous).
Can this be fixed for 2.6/3.0, as it is likely that the new binutils
will become common while these versions of Python are current?
----------
components: Distutils
files: distutils.patch
keywords: patch
messages: 70655
nosy: pmoore
severity: normal
status: open
title: distutils fails with mingw binutils 2.18.50.20080109
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file11043/distutils.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3496>
_______________________________________
From report at bugs.python.org Sun Aug 3 21:35:56 2008
From: report at bugs.python.org (vadim suvorov)
Date: Sun, 03 Aug 2008 19:35:56 +0000
Subject: [New-bugs-announce] [issue3497] a bug in the interpreter?
In-Reply-To: <1217792156.96.0.844275585646.issue3497@psf.upfronthosting.co.za>
Message-ID: <1217792156.96.0.844275585646.issue3497@psf.upfronthosting.co.za>
New submission from vadim suvorov <zzPythonTracker at stelary.com>:
The result of the attached script execution is extremely unstable. The
change in the print statement in line 146 from 'print "1"' to 'print 1'
(string literal to numerical) changes the result of execution to the
correct (presumably) one. The results are also affected by commenting
out calls to empty method in lines 143 or 227. The use of dis.dis()
affects results of the execution as well. More than, the location of
error (the triggered assert) shifts in the code, or it is possible that
an Exception is raised.
The script was tested in Python 2.5.2 in Windows XP SP2 and SP3,
2.6beta2 in Windows XP SP3 and in 2.5.2 Ubuntu 8.0.4 with consistent
results. (I mean that behavior of the script is changed by calling of
empty methods or irrelevant print statements. The assert shifts.)
Sorry for the long script. I failed to further reduce its size because
effect disappears.
Expected output:
~~~~~~~~~~~~~~~~~~~~~
1
1
1
1
1
1
1
1
1
1
1
1
Congratulations: grid solved!
1 2 3 4 5 6 7 8 910
1 B B B B B . B . . B
2 . B . . B B B B . B
3 . . . . . B B . B B
4 . . . B B B B B B .
5 B . B B B . . B B B
~~~~~~~~~~~~~~~~~~~~~
Received output (example):
~~~~~~~~~~~~~~~~~~~~~
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
Traceback (most recent call last):
File "E:\pet projects\nonograms\nonogramsolver10.py", line 244, in
<module>
g.solve()
File "E:\pet projects\nonograms\nonogramsolver10.py", line 230, in solve
seq.simplescan()
File "E:\pet projects\nonograms\nonogramsolver10.py", line 99, in
simplescan
assert self.clues, "a seq with no clues"
AssertionError: a seq with no clues
~~~~~~~~~~~~~~~~~~~~~
----------
components: Interpreter Core
files: nonogramsolver10.py
messages: 70658
nosy: bad
severity: normal
status: open
title: a bug in the interpreter?
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file11045/nonogramsolver10.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3497>
_______________________________________
From report at bugs.python.org Mon Aug 4 14:47:17 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Mon, 04 Aug 2008 12:47:17 +0000
Subject: [New-bugs-announce] [issue3498] mod_cls
In-Reply-To: <1217854037.97.0.189815073445.issue3498@psf.upfronthosting.co.za>
Message-ID: <1217854037.97.0.189815073445.issue3498@psf.upfronthosting.co.za>
New submission from Robert Schuppenies <okkotonushi at googlemail.com>:
Using sphinx I get the following error if I want to document methods via
automethod:
reading sources... copyright glossary [..] refbrowser Exception
occurred: File
"[..]/doctools/sphinx/ext/autodoc.py", line 313, in resolve_name
if not mod_cls:
UnboundLocalError: local variable 'mod_cls' referenced before
assignment. [..]
I am not familiar with the code base, but from the comments the attached
patch should address the issue.
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: mod_cls.patch
keywords: patch
messages: 70697
nosy: georg.brandl, schuppenies
severity: normal
status: open
title: mod_cls
type: behavior
Added file: http://bugs.python.org/file11057/mod_cls.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3498>
_______________________________________
From report at bugs.python.org Mon Aug 4 18:36:17 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 04 Aug 2008 16:36:17 +0000
Subject: [New-bugs-announce] [issue3499] Python 2.6 requires pre-installed
Python to build
In-Reply-To: <1217867777.22.0.746958377378.issue3499@psf.upfronthosting.co.za>
Message-ID: <1217867777.22.0.746958377378.issue3499@psf.upfronthosting.co.za>
New submission from Marc-Andre Lemburg <mal at egenix.com>:
Here's the "make -d" output:
Prerequisite `Parser/Python.asdl' is older than target
`Include/Python-ast.h'.
Prerequisite `Parser/asdl.py' is older than target
`Include/Python-ast.h'.
Prerequisite `Parser/asdl_c.py' is newer than target
`Include/Python-ast.h'.
Must remake target `Include/Python-ast.h'.
./Parser/asdl_c.py -h ./Include ./Parser/Python.asdl
/usr/bin/env: No such file or directory
And these are the file times:
orig/Python-2.6b2> ls -l Include/Python-ast.h
-rw-r--r-- 1 lemburg users 20081 2008-03-30 08:40 Include/Python-ast.h
orig/Python-2.6b2> ls -l Parser/asdl*
-rw-r--r-- 1 lemburg users 11306 2006-03-01 23:49 Parser/asdl.py
-rwxr-xr-x 1 lemburg users 39771 2008-06-09 06:58 Parser/asdl_c.py
Because Python-ast.h is older than the script used for generating it
(asdl_c.py), it always tries to rebuild the .h file. Since this requires
Python to be installed, it fails on a machine that doesn't always have
an existing Python binary installed.
This happens in both 2.6b1 and 2.6b2.
I guess the release process should make sure that the Python-ast.h and
Python-ast.c are always newer than the scripts used to build them.
----------
components: Build
messages: 70706
nosy: lemburg
priority: critical
severity: normal
status: open
title: Python 2.6 requires pre-installed Python to build
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3499>
_______________________________________
From report at bugs.python.org Mon Aug 4 21:13:34 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 04 Aug 2008 19:13:34 +0000
Subject: [New-bugs-announce] [issue3500] unbound methods of different
classes compare equal
In-Reply-To: <1217877214.51.0.0221142821046.issue3500@psf.upfronthosting.co.za>
Message-ID: <1217877214.51.0.0221142821046.issue3500@psf.upfronthosting.co.za>
New submission from Jean-Paul Calderone <exarkun at divmod.com>:
If a method is inherited by two different classes, then the unbound
method objects which can be retrieved from those classes compare equal
to each other. For example:
Python 2.6b2+ (trunk:65502M, Aug 4 2008, 15:05:07)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class X:
... def y(self):
... pass
...
>>> class A(X):
... pass
...
>>> class B(X):
... pass
...
>>> A.y == B.y
True
This is bad behavior because A.y and B.y are otherwise distinguishable
(for example, they repr differently, they have different values for the
`im_class? attribute, they cannot be used interchangably for invoking
the method because they place different type restrictions on the `self?
parameter, etc).
----------
components: Interpreter Core
messages: 70714
nosy: exarkun
severity: normal
status: open
title: unbound methods of different classes compare equal
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3500>
_______________________________________
From report at bugs.python.org Tue Aug 5 00:20:47 2008
From: report at bugs.python.org (Mike Speciner)
Date: Mon, 04 Aug 2008 22:20:47 +0000
Subject: [New-bugs-announce] [issue3501] expm1 missing
In-Reply-To: <1217888447.93.0.520646287679.issue3501@psf.upfronthosting.co.za>
Message-ID: <1217888447.93.0.520646287679.issue3501@psf.upfronthosting.co.za>
New submission from Mike Speciner <speciner_michael at emc.com>:
The math module contains log1p but is missing expm1 (the inverse of
log1p). These functions are necessary to avoid loss of precision in
floating point calculations, and are part of the C99 standard math library.
----------
components: None
messages: 70722
nosy: ms
severity: normal
status: open
title: expm1 missing
type: feature request
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3501>
_______________________________________
From report at bugs.python.org Tue Aug 5 02:33:53 2008
From: report at bugs.python.org (Ramon Garcia)
Date: Tue, 05 Aug 2008 00:33:53 +0000
Subject: [New-bugs-announce] [issue3502] Inconsistency between
string.letters and default encoding.
In-Reply-To: <1217896433.93.0.654864556475.issue3502@psf.upfronthosting.co.za>
Message-ID: <1217896433.93.0.654864556475.issue3502@psf.upfronthosting.co.za>
New submission from Ramon Garcia <ramong at cnmv.es>:
In python on Windows, under Idle, the string.letters includes extended
characters. But the default codec, used when translating from string to
unicode, is still ascii. This behaviour causes crashes with python win32
extensions.
>>> string.letters
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz\x83\x8a\x8c\x8e\x9a\x9c\x9e\x9f\xaa\xb5\xba\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff'
But still, unless the user customizes the installation,
sys.getdefaultencoding() returns ascii.
The consequence is that after instating a COM object, pywin32 211 issues
this exception:
File "C:\Python25\Lib\site-packages\win32com\client\build.py", line
297, in MakeFuncMethod
return self.MakeDispatchFuncMethod(entry, name, bMakeClass)
File "C:\Python25\Lib\site-packages\win32com\client\build.py", line
318, in MakeDispatchFuncMethod
s = linePrefix + 'def ' + name + '(self' + BuildCallList(fdesc,
names, defNamedOptArg, defNamedNotOptArg, defUnnamedArg, defOutArg) + '):'
File "C:\Python25\Lib\site-packages\win32com\client\build.py", line
604, in BuildCallList
argName = MakePublicAttributeName(argName)
File "C:\Python25\Lib\site-packages\win32com\client\build.py", line
542, in MakePublicAttributeName
return filter( lambda char: char in valid_identifier_chars, className)
File "C:\Python25\Lib\site-packages\win32com\client\build.py", line
542, in <lambda>
return filter( lambda char: char in valid_identifier_chars, className)
UnicodeDecodeError: 'ascii' codec can't decode byte 0x83 in position 52:
ordinal not in range(128)
The line that causes this exception is from win32com.client.build.
This fragment is enough to reproduce the bug (from build.py in
win32com/client):
valid_identifier_chars = string.letters + string.digits + "_"
...
return filter( lambda char: char in valid_identifier_chars, className)
Try to print the expression in the return statement and set className to
anything you wish in Unicode. It will crash
It is contradictory that the default codec does not allow translation of
characters 0x83, and that string.letters includes it. If one regards
this character as printable, then it should be encoded successfully.
----------
components: Windows
messages: 70725
nosy: ramong
severity: normal
status: open
title: Inconsistency between string.letters and default encoding.
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3502>
_______________________________________
From report at bugs.python.org Tue Aug 5 03:51:04 2008
From: report at bugs.python.org (Jim Sizelove)
Date: Tue, 05 Aug 2008 01:51:04 +0000
Subject: [New-bugs-announce] [issue3503] Calls to print() function in Python
3.0 tutorial
In-Reply-To: <1217901064.2.0.318710120877.issue3503@psf.upfronthosting.co.za>
Message-ID: <1217901064.2.0.318710120877.issue3503@psf.upfronthosting.co.za>
New submission from Jim Sizelove <jimsize at gmail.com>:
I decided to learn more about the coming changes in Python 3.0 by
installing the beta and working through the tutorial. I found some
discrepancies between the code examples and the output I got. The
attached patch shows several places where the print() function is called
incorrectly. These are mostly examples that are missing the parentheses.
The rest of this comment pertains to only one change included in the
patch that I find less than satisfactory. In introduction.html, there
is an example of printing a fibonacci sequence in one line of output by
using the end keyword. When actually run in the python interpreter, the
>>> prompt shows at the end of the same line as the fibonacci numbers.
The patch fixes this by enclosing a "print()" within an else clause.
This "fix" produces the expected output, but I don't think the else
clause has been described yet in the tutorial. A better fix would be to
wrap the while statement in a function with a print() function call
after the end of the while statement (this is how the fib() function is
defined in http://docs.python.org/dev/3.0/tutorial/modules.html). But
functions have not been explained this early in the tutorial.
Perhaps it would be best to drop this example of using the end keyword
to the print function in the introduction and explain it later in the
tutorial.
----------
assignee: georg.brandl
components: Documentation
files: print.diff
keywords: patch
messages: 70727
nosy: georg.brandl, jsizelove
severity: normal
status: open
title: Calls to print() function in Python 3.0 tutorial
versions: Python 3.0
Added file: http://bugs.python.org/file11061/print.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3503>
_______________________________________
From report at bugs.python.org Tue Aug 5 11:38:40 2008
From: report at bugs.python.org (paul stoop)
Date: Tue, 05 Aug 2008 09:38:40 +0000
Subject: [New-bugs-announce] [issue3504] Python Reference Manual
inconsistency (Notation)
In-Reply-To: <1217929120.44.0.382303757014.issue3504@psf.upfronthosting.co.za>
Message-ID: <1217929120.44.0.382303757014.issue3504@psf.upfronthosting.co.za>
New submission from paul stoop <paul.stoop.nl at gmail.com>:
On page http://docs.python.org/ref/notation.html the following text:
name ::= lc_letter
lc_letter ::= "a"..."z"
The first line says that a name is an lc_letter followed by a sequence
of zero or more lc_letters and underscores
...
should read (imho)
name ::= lc_letter(_|lc_letter)*
...
----------
assignee: georg.brandl
components: Documentation
messages: 70732
nosy: georg.brandl, pavlosto
severity: normal
status: open
title: Python Reference Manual inconsistency (Notation)
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3504>
_______________________________________
From report at bugs.python.org Tue Aug 5 14:42:57 2008
From: report at bugs.python.org (paul stoop)
Date: Tue, 05 Aug 2008 12:42:57 +0000
Subject: [New-bugs-announce] [issue3505] single/double quote error in Python
v2.6b2 documentation
In-Reply-To: <1217940177.03.0.531342969311.issue3505@psf.upfronthosting.co.za>
Message-ID: <1217940177.03.0.531342969311.issue3505@psf.upfronthosting.co.za>
New submission from paul stoop <paul.stoop.nl at gmail.com>:
hi,
On http://docs.python.org/ref/strings.html we find
longstring ::= "'''" longstringitem* "'''" | '"""' longstringitem* '"""'
(correct),
but,
on http://docs.python.org/dev/reference/lexical_analysis.html#id7
we find:
v v
longstring ::= ""'" longstringitem* ""'" | '"""' longstringitem* '"""'
^ ^
(not correct, i think(?)).
----------
assignee: georg.brandl
components: Documentation
messages: 70735
nosy: georg.brandl, pavlosto
severity: normal
status: open
title: single/double quote error in Python v2.6b2 documentation
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3505>
_______________________________________
From report at bugs.python.org Tue Aug 5 20:48:11 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 05 Aug 2008 18:48:11 +0000
Subject: [New-bugs-announce] [issue3506] Change buffer/memoryview
DeprecationWarning
In-Reply-To: <1217962091.36.0.181182833526.issue3506@psf.upfronthosting.co.za>
Message-ID: <1217962091.36.0.181182833526.issue3506@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Right now in 2.6, using buffer() warns that it is going away and to use
memoryview(). Unfortunately memoryview() won't be backported to 2.6 in
time for release.
That means the warning is covering something that is within 2to3's
realm. So the warning should be changed to more align with any specific
difference between buffer() and memoryview() (or bring buffer() back to
3.0).
----------
components: Interpreter Core
messages: 70755
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Change buffer/memoryview DeprecationWarning
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3506>
_______________________________________
From report at bugs.python.org Tue Aug 5 21:35:31 2008
From: report at bugs.python.org (jqxvjqxv)
Date: Tue, 05 Aug 2008 19:35:31 +0000
Subject: [New-bugs-announce] [issue3507] spelling in try.html
In-Reply-To: <1217964931.67.0.287440079483.issue3507@psf.upfronthosting.co.za>
Message-ID: <1217964931.67.0.287440079483.issue3507@psf.upfronthosting.co.za>
New submission from jqxvjqxv <jqxv at mailinator.com>:
http://docs.python.org/ref/try.html
Please replace "propogate" with correct spelling "propagate".
----------
assignee: georg.brandl
components: Documentation
messages: 70760
nosy: georg.brandl, jqxvjqxv
severity: normal
status: open
title: spelling in try.html
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3507>
_______________________________________
From report at bugs.python.org Wed Aug 6 06:25:32 2008
From: report at bugs.python.org (Diego)
Date: Wed, 06 Aug 2008 04:25:32 +0000
Subject: [New-bugs-announce] [issue3508] range() is not a generator when
used in for's
In-Reply-To: <1217996732.69.0.453344669108.issue3508@psf.upfronthosting.co.za>
Message-ID: <1217996732.69.0.453344669108.issue3508@psf.upfronthosting.co.za>
New submission from Diego <jacobidiego at gmail.com>:
Hi.
I am a debian lenny user so i am still using python 2.5 so i dont know
how is this "bug" working on newer pythons. Please close it if you find
that it doesnt exists.
It may not be a bug but.
I have maked an script to optimice minterms sums (This is electronics
stuff to reduce the number of logic devices in an electronic design).
The algorithm depends exponentially on the number of bits in the input
and the output. So to test it i have to generate 2**N_input_bits
strings in a list. Each string being of N_input_bits+N_output_bits long.
The problem starts when N_input_bits is too much long. (from 25 and up)
The function range(2**N_input_bits) instantiates a list with all thoose
numbers.
I have maked a test script to check it out:
import time
N=32
try:
range(2**N)
# range(): allocates N's integer's items in a list
except Exception, error:
print "ERROR: ",error, " Items=",N
print
time.sleep(10)
def RANGE(a):
# GENERATOR: Creates one output eachtime it is called.
i=0
while i<a:
yield i
i=i+1
return
try:
for x in RANGE(2**N):
if not x%100:
print x
except Exception, error:
print "ERROR: ",error, " Items=",N
print
If i am not mistaken, "RANGE" will only take up one integer of memory
each time instead of a complete list with "range()".
So it is better to use RANGE (a generator) with for's when i do not
need to edit the list.
I think that range is mostly used in for's, so it will be a big improve
to make the line:
for ... in range(....):
as a generator behavior and the normal range use:
alist = range(50)
as the same list.
This for line is very common in many programs and the content of the
list can not be edited inside the for, it is only used by the for.
So, it can speed up python a little without requiring any changes.
Please if you consider this i not a bug or suggestion, or what ever,
just close/delete/ignore the post. :)
Cheers.
Diego.
----------
messages: 70769
nosy: epsilon_da
severity: normal
status: open
title: range() is not a generator when used in for's
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3508>
_______________________________________
From report at bugs.python.org Wed Aug 6 10:26:26 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Wed, 06 Aug 2008 08:26:26 +0000
Subject: [New-bugs-announce] [issue3509] La Lutte,
Je Vais Vous Montrer Mon Piquer!
In-Reply-To: <01c8f7a6$7cc55c80$30c53a52@birick.mathieu>
Message-ID: <01c8f7a6$7cc55c80$30c53a52@birick.mathieu>
New submission from Jean Brouwers <MrJean1 at Gmail.com>:
Soyez heureux avec votre taille et de rendre votre partenaire heureux et satisfait.
Alors que VPXL elargissement chirurgie est couteux et parfois dangereux, pilules pourrait facilement etre oublie de prendre et d'autres produits sont le plus souvent que Travailler pour l'OMS, le VPXL est sur et facile a utiliser.}
Commander VPXL et bienvenue dans le monde de heureux et confiant hommes.
http://surekeep.com
----------
files: unnamed
messages: 70775
nosy: MrJean1
severity: normal
status: open
title: La Lutte, Je Vais Vous Montrer Mon Piquer!
Added file: http://bugs.python.org/file11063/unnamed
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3509>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20080806/d5f10bb3/attachment.txt>
From report at bugs.python.org Wed Aug 6 17:06:06 2008
From: report at bugs.python.org (P. Roebuck)
Date: Wed, 06 Aug 2008 15:06:06 +0000
Subject: [New-bugs-announce] [issue3510] Site-specific configuration hook
documentation incorrect
In-Reply-To: <1218035166.89.0.646760261694.issue3510@psf.upfronthosting.co.za>
Message-ID: <1218035166.89.0.646760261694.issue3510@psf.upfronthosting.co.za>
New submission from P. Roebuck <plroebuck at mdanderson.org>:
Documentation does not match due to version number inconsistency.
Current:
< Then the following directories are added to sys.path, in this order:
<
<
< /usr/local/lib/python2.3/site-packages/bar
< /usr/local/lib/python2.3/site-packages/foo
Proposed:
> Then the following directories are added to sys.path, in this order:
>
>
> /usr/local/lib/python{X.Y}/site-packages/bar
> /usr/local/lib/python{X.Y}/site-packages/foo
Syntax for proposed documentation fix may be incorrect, but this gives
the general idea anyway...
<http://svn.python.org/view/python/trunk/Doc/library/site.rst?
rev=62788&view=markup>
----------
assignee: georg.brandl
components: Documentation
messages: 70785
nosy: georg.brandl, proebuck
severity: normal
status: open
title: Site-specific configuration hook documentation incorrect
versions: Python 2.4, Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3510>
_______________________________________
From report at bugs.python.org Wed Aug 6 21:42:15 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 06 Aug 2008 19:42:15 +0000
Subject: [New-bugs-announce] [issue3511] Incorrect charset range handling
with ignore case flag?
In-Reply-To: <1218051735.51.0.548930988583.issue3511@psf.upfronthosting.co.za>
Message-ID: <1218051735.51.0.548930988583.issue3511@psf.upfronthosting.co.za>
New submission from Matthew Barnett <python at mrabarnett.plus.com>:
While working on the regex code in sre_compile.py I came across the
following code in the handling of charset ranges in _optimize_charset:
for i in range(fixup(av[0]), fixup(av[1])+1):
charmap[i] = 1
The function fixup converts the ends of the range to lower case if the
ignore-case flag is present. The problem with this approach is
illustrated below:
>>> import re
>>> print re.match(r'[9-A]', 'A')
<_sre.SRE_Match object at 0x00A78058>
>>> print re.match(r'[9-A]', 'a')
None
>>> print re.match(r'[9-A]', '_')
None
>>> print re.match(r'[9-A]', 'A', re.IGNORECASE)
<_sre.SRE_Match object at 0x00D0BFA8>
>>> print re.match(r'[9-A]', 'a', re.IGNORECASE)
<_sre.SRE_Match object at 0x00A78058>
>>> print re.match(r'[9-A]', '_', re.IGNORECASE)
<_sre.SRE_Match object at 0x00D0BFA8>
>>>
'_' doesn't lie between '9' and 'A', but it does lie between '9' and 'a'.
Surely the ignore-case flag should not affect whether non-letters are
matched or not?
----------
components: Regular Expressions
messages: 70799
nosy: mrabarnett
severity: normal
status: open
title: Incorrect charset range handling with ignore case flag?
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3511>
_______________________________________
From report at bugs.python.org Thu Aug 7 06:07:41 2008
From: report at bugs.python.org (Ian Charnas)
Date: Thu, 07 Aug 2008 04:07:41 +0000
Subject: [New-bugs-announce] [issue3512] Change fsync to use fullfsync on
platforms (like OS X) that have/need it
In-Reply-To: <1218082061.12.0.0384174375737.issue3512@psf.upfronthosting.co.za>
Message-ID: <1218082061.12.0.0384174375737.issue3512@psf.upfronthosting.co.za>
New submission from Ian Charnas <ian.charnas at gmail.com>:
fsync on OSX does not actually flush the file to disk as is desired.
This is a problem because application developers rely on fsync for file
integrity. SQLite [1] and MySQL [2] and other major database systems
all use 'fullfsync' on OS X instead of fsync, because 'fullfsync'
provides the desired behavior.
Because the documented behavior of python's fsync function is to "force
write of file with filedescriptor to disk", I believe that on OS X the
fullfsync call should be used instead of fsync.
The supplied patch adds this functionality in a non-platform-specific
way. It checks if there is a FULLFSYNC fcntl call available (using
"#ifdef F_FULLFSYNC", where F_FULLFSYNC is defined in sys/fcntl.h), and
if this symbol is defined then a fnctl(F_FULLFSYNC, fd, 0) is called
instead of fsync.
[1] SQLite uses fullfsync on all platforms that define it:
http://www.sqlite.org/cvstrac/fileview?f=sqlite/src/os_unix.c
[2] MySQL uses fullfsync only on the darwin platform and only when
F_FULLFSYNC is defined as 51, which seems to be short-sighted in that
this symbol may change value in future versions of OS X. To see this
code, download a mysql 5.x source snapshot and open up
mysql-<version-number>/innobase/os/os0file.c
----------
components: Library (Lib)
files: fullfsync.patch
keywords: patch
messages: 70810
nosy: icharnas
severity: normal
status: open
title: Change fsync to use fullfsync on platforms (like OS X) that have/need it
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11066/fullfsync.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3512>
_______________________________________
From report at bugs.python.org Thu Aug 7 07:32:55 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 07 Aug 2008 05:32:55 +0000
Subject: [New-bugs-announce] [issue3513] test_multiprocessing hangs without
this patch on win2k
In-Reply-To: <1218087175.32.0.636360370646.issue3513@psf.upfronthosting.co.za>
Message-ID: <1218087175.32.0.636360370646.issue3513@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:
Hello. I'm not familiar with socket, but I found workaround for this
problem. socket.getfqdn("127.0.0.1") returns computer name, but with this
test_multiprocess doesn't work. With 'localhost' test works.
Maybe win2003 community buildbot hangs with same reason?
http://www.python.org/dev/buildbot/community/trunk/x86%20Windows%202003%20trunk/builds/13/step-test/0
----------
components: Extension Modules
files: workaround.patch
keywords: patch
messages: 70814
nosy: ocean-city
severity: normal
status: open
title: test_multiprocessing hangs without this patch on win2k
versions: Python 2.6
Added file: http://bugs.python.org/file11067/workaround.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3513>
_______________________________________
From report at bugs.python.org Thu Aug 7 09:41:24 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Thu, 07 Aug 2008 07:41:24 +0000
Subject: [New-bugs-announce] [issue3514] pickle segfault with infinite loop
in __getattr__
In-Reply-To: <1218094884.25.0.929413492042.issue3514@psf.upfronthosting.co.za>
Message-ID: <1218094884.25.0.929413492042.issue3514@psf.upfronthosting.co.za>
New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:
I found a segfault in pickle.load when you overload __getattr__ and
create yourself a infinite loop in the latest svn checkout of python 3:
########################################
import pickle
class Foo:
def __getattr__(self, key):
self.foo
with open('foo.db', 'wb') as f:
foo = Foo()
pickle.dump(foo, f)
with open('foo.db', 'rb') as f:
pickle.load(f)
########################################
This results in this stack trace on my mac:
Reason: KERN_PROTECTION_FAILURE at address: 0x0000000c
0x0000dc6b in PyObject_Call (func=0x0, arg=0x44cd58, kw=0x0) at
Objects/abstract.c:2174
2174 if ((call = func->ob_type->tp_call) != NULL) {
(gdb) bt
#0 0x0000dc6b in PyObject_Call (func=0x0, arg=0x44cd58, kw=0x0) at
Objects/abstract.c:2174
#1 0x004c1b4d in unpickler_call (self=0x4a6240, func=0x0, arg=0x4b66c8)
at /Users/Shared/erickt/Projects/py3k.svn/Modules/_pickle.c:413
#2 0x004cac9a in load_build (self=0x4a6240) at
/Users/Shared/erickt/Projects/py3k.svn/Modules/_pickle.c:3844
#3 0x004cbb4f in load (self=0x4a6240) at
/Users/Shared/erickt/Projects/py3k.svn/Modules/_pickle.c:4047
#4 0x004cbe71 in Unpickler_load (self=0x4a6240) at
/Users/Shared/erickt/Projects/py3k.svn/Modules/_pickle.c:4119
#5 0x000f2fef in call_function (pp_stack=0xbfffea84, oparg=0) at
Python/ceval.c:3387
#6 0x000edfdb in PyEval_EvalFrameEx (f=0x326cd8, throwflag=0) at
Python/ceval.c:2205
#7 0x000f157e in PyEval_EvalCodeEx (co=0x4a9628, globals=0x487f50,
locals=0x0, args=0x32593c, argcount=1, kws=0x325940, kwcount=0,
defs=0x0, defcount=0, kwdefs=0x4b6428, closure=0x0) at
Python/ceval.c:2840
#8 0x000f39e5 in fast_function (func=0x4b4ab8, pp_stack=0xbfffee54,
n=1, na=1, nk=0) at Python/ceval.c:3501
#9 0x000f35cf in call_function (pp_stack=0xbfffee54, oparg=1) at
Python/ceval.c:3424
#10 0x000edfdb in PyEval_EvalFrameEx (f=0x3257f8, throwflag=0) at
Python/ceval.c:2205
#11 0x000f157e in PyEval_EvalCodeEx (co=0x444c28, globals=0x255818,
locals=0x255818, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:2840
#12 0x000e564f in PyEval_EvalCode (co=0x444c28, globals=0x255818,
locals=0x255818) at Python/ceval.c:519
#13 0x00122a96 in run_mod (mod=0x872c80, filename=0xbffff228 "foo.py",
globals=0x255818, locals=0x255818, flags=0xbffff628, arena=0x322020) at
Python/pythonrun.c:1553
#14 0x00122884 in PyRun_FileExFlags (fp=0xa00dcde0, filename=0xbffff228
"foo.py", start=257, globals=0x255818, locals=0x255818, closeit=1,
flags=0xbffff628) at Python/pythonrun.c:1510
#15 0x00120e39 in PyRun_SimpleFileExFlags (fp=0xa00dcde0,
filename=0xbffff228 "foo.py", closeit=1, flags=0xbffff628) at
Python/pythonrun.c:1048
#16 0x001202f9 in PyRun_AnyFileExFlags (fp=0xa00dcde0,
filename=0xbffff228 "foo.py", closeit=1, flags=0xbffff628) at
Python/pythonrun.c:845
#17 0x00134d1c in Py_Main (argc=2, argv=0x227028) at Modules/main.c:592
#18 0x00002574 in main (argc=2, argv=0xbffff748) at python.c:57
It seems that this isn't just for infinite loops. If you replace the
class with this:
class Foo:
def __init__(self):
self.foo = {}
def __getattr__(self, key):
self.foo[5]
It still errors out. So I'm guessing pickle is just not handling
exceptions properly.
----------
components: Library (Lib)
messages: 70815
nosy: erickt
severity: normal
status: open
title: pickle segfault with infinite loop in __getattr__
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3514>
_______________________________________
From report at bugs.python.org Thu Aug 7 12:54:55 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 07 Aug 2008 10:54:55 +0000
Subject: [New-bugs-announce] [issue3515] refcount gc bug?
In-Reply-To: <1218106495.5.0.346677441059.issue3515@psf.upfronthosting.co.za>
Message-ID: <1218106495.5.0.346677441059.issue3515@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:
I'm not sure this is bug or not, but shouldn't `io' be collected by
refcount GC? This happens on python2.5 but doesn't happend on python3.0.
import os
def foo():
io = open("a.txt", "w")
raise RuntimeError()
try:
foo()
except:
pass
os.remove("a.txt") # WindowsError (Error32)
# Process cannot access to the file.
# Another process is using it.
----------
messages: 70816
nosy: ocean-city
severity: normal
status: open
title: refcount gc bug?
versions: Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3515>
_______________________________________
From report at bugs.python.org Thu Aug 7 15:33:06 2008
From: report at bugs.python.org (nadav)
Date: Thu, 07 Aug 2008 13:33:06 +0000
Subject: [New-bugs-announce] [issue3516] string formatting quirk using %.%
In-Reply-To: <1218115986.04.0.715940138525.issue3516@psf.upfronthosting.co.za>
Message-ID: <1218115986.04.0.715940138525.issue3516@psf.upfronthosting.co.za>
New submission from nadav <blop.blopy at gmail.com>:
>>> "%.%s" % ()
'%s'
>>> "%(a).%(b)s" % dict(a=2)
'%(b)s'
>>> "%(a).%(b)s" % dict(a=2, b=3)
'%(b)s'
>>> "%(a).%(b)s" % dict()
Traceback (most recent call last):
File "<pyshell#6>", line 1, in -toplevel-
"%(a).%(b)s" % dict()
KeyError: 'a'
this is counter intuitive and cannot be deduced from the documentation.
----------
components: Interpreter Core
messages: 70822
nosy: blop
severity: normal
status: open
title: string formatting quirk using %.%
type: behavior
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3516>
_______________________________________
From report at bugs.python.org Thu Aug 7 19:31:59 2008
From: report at bugs.python.org (Ian Charnas)
Date: Thu, 07 Aug 2008 17:31:59 +0000
Subject: [New-bugs-announce] [issue3517] PATCH - Providing fullfsync on
supported platforms
In-Reply-To: <1218130319.91.0.361112026251.issue3517@psf.upfronthosting.co.za>
Message-ID: <1218130319.91.0.361112026251.issue3517@psf.upfronthosting.co.za>
New submission from Ian Charnas <ian.charnas at gmail.com>:
Python currently provides os.fsync to call the POSIX 'fsync' on
platforms that support it. While this function forces the operating
system to force a file buffer to the storage device, data may still be
waiting in the hardware write buffers on the storage device. Certain
platforms (so far, only OS X) provide "fullfsync" [1] to request that
storage devices flush their write buffers to the actual physical media.
This functionality is especially useful to VCS and DB developers, and
already appears in SQLite [2] and MySQL [3], amongst others.
This patch includes code changes to Modules/posixmodule.c that exposes
os.fullfsync on supported platforms, including the appropriate
documentation added to Doc/library/os.rst
-Ian Charnas
[1] Discussion of fsync and fullfsync on darwin platform:
http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00072.html
[2] SQLite uses fullfsync on all platforms that define it:
http://www.sqlite.org/cvstrac/fileview?f=sqlite/src/os_unix.c
[3] MySQL uses fullfsync only on the darwin platform and only when
F_FULLFSYNC is defined as 51, which seems to be short-sighted in that
this symbol may change value in future versions of OS X. To see this
code, download a mysql 5.x source snapshot and open up
mysql-<version-number>/innobase/os/os0file.c
----------
components: Library (Lib)
files: fullfsync.patch
keywords: patch
messages: 70842
nosy: icharnas
severity: normal
status: open
title: PATCH - Providing fullfsync on supported platforms
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11072/fullfsync.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3517>
_______________________________________
From report at bugs.python.org Thu Aug 7 19:46:08 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Aug 2008 17:46:08 +0000
Subject: [New-bugs-announce] [issue3518] multiprocessing:
BaseManager.from_address documented but doesn't exist
In-Reply-To: <1218131168.54.0.934616092257.issue3518@psf.upfronthosting.co.za>
Message-ID: <1218131168.54.0.934616092257.issue3518@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
The BaseManager.from_address method is documented at:
http://docs.python.org/dev/library/multiprocessing.html#multiprocessing.ma
nagers.BaseManager.from_address
but it looks as though this method doesn't actually exist. In contrast,
the BaseManager.connect method appears to be necessary for making remote
connections, but is not documented.
----------
assignee: jnoller
components: Documentation
messages: 70844
nosy: jnoller, marketdickinson
severity: normal
status: open
title: multiprocessing: BaseManager.from_address documented but doesn't exist
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3518>
_______________________________________
From report at bugs.python.org Thu Aug 7 23:53:16 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 07 Aug 2008 21:53:16 +0000
Subject: [New-bugs-announce] [issue3519] Evaluation order example lacks
suffix
In-Reply-To: <1218145996.93.0.279881671552.issue3519@psf.upfronthosting.co.za>
Message-ID: <1218145996.93.0.279881671552.issue3519@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
Language reference/ Expressions/ Evaluation order
...
In the following lines, expressions will be evaluated in the arithmetic
order of their suffixes:
...
func(expr1, expr2, *expr3, **expr4)
The omission of a suffix from the function expression could imply that
such are somehow not included in the left-to-right rule. Suggest
'func0', 'f_expr0', 'func_expr0' or just 'expr0' possibly renumbered from 1.
expr1(expr2, expr3, *expr4, **expr5)
is probably most consistent with other examples.
----------
assignee: georg.brandl
components: Documentation
messages: 70864
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Evaluation order example lacks suffix
versions: Python 2.5, Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3519>
_______________________________________
From report at bugs.python.org Fri Aug 8 00:13:24 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 07 Aug 2008 22:13:24 +0000
Subject: [New-bugs-announce] [issue3520] New Global Module Index glitch on
WinXP
In-Reply-To: <1218147204.29.0.833867911272.issue3520@psf.upfronthosting.co.za>
Message-ID: <1218147204.29.0.833867911272.issue3520@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
New to beta2 (a4,b1 worked fine as I remember).
It is possible that I installed xp sp3 in between.
In any case, I keep xp updated as per MS downloads.
Windows XP: open Start/Python3.0/Python Manuals to get
'Python v3.0b2 documentation' window. Click 'Global Module Index' on
contents list. Get
Internet Explorer Script Error
!An error has occurred in the script on this page.
Line 16
Char 7
Error: 'DOCUMENTATION_OPTIONS' is undefined
Code: 0
URL: mk at MSITStore:C:\Program
Files\Python30\Doc\python30b2.chm::/modindex.html
Do you want to continue running scripts on this page?
When I click yes, seems to work ok as before.
Error repeats when I go back to index again.
----------
assignee: georg.brandl
components: Documentation
messages: 70865
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: New Global Module Index glitch on WinXP
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3520>
_______________________________________
From report at bugs.python.org Fri Aug 8 00:36:51 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 07 Aug 2008 22:36:51 +0000
Subject: [New-bugs-announce] [issue3521] file.readline: bad exception
recovery
In-Reply-To: <1218148611.21.0.579552262714.issue3521@psf.upfronthosting.co.za>
Message-ID: <1218148611.21.0.579552262714.issue3521@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
WinXP, 3.0b2
>>>f=open('somefile', 'r')
>>>f.readline(somefloat)
Traceback (most recent call last):
File "<pyshell#70>", line 1, in <module>
f.readline(1.0)
File "C:\Program Files\Python30\lib\io.py", line 1766, in readline
return line[:endpos]
TypeError: slice indices must be integers or None or have an __index__
method
At this point, any f.read or f.readline calls fail with a similar
TypeError. The error recovery seems incomplete. The same does *not*
happen with f.read(float). Recovery is complete and subsequent
f.read/f.readline calls work.
In 2.5, float size arg worked with a deprecation warning, so issue does
not arise. I presume same is true in 2.6.
----------
components: Interpreter Core
messages: 70866
nosy: tjreedy
severity: normal
status: open
title: file.readline: bad exception recovery
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3521>
_______________________________________
From report at bugs.python.org Fri Aug 8 02:11:53 2008
From: report at bugs.python.org (Jim Sizelove)
Date: Fri, 08 Aug 2008 00:11:53 +0000
Subject: [New-bugs-announce] [issue3522] zip() function example in tutorial
In-Reply-To: <1218154313.32.0.167482410859.issue3522@psf.upfronthosting.co.za>
Message-ID: <1218154313.32.0.167482410859.issue3522@psf.upfronthosting.co.za>
New submission from Jim Sizelove <jimsize at gmail.com>:
The zip() function is now a generator in Python 3.0. There is an
example of using the zip() function in the Python 3.0 tutorial,
http://docs.python.org/dev/3.0/tutorial/datastructures.html.
When running the example, I got:
>>> mat = [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
>>> zip(*mat)
<zip object at 0x70fc60>
I wrapped it in a call to list() to get the example output:
>>> list(zip(*mat))
[(1, 4, 7), (2, 5, 8), (3, 6, 9)]
The attached patch file contains this change.
----------
assignee: georg.brandl
components: Documentation
files: datastructures.diff
keywords: patch
messages: 70871
nosy: georg.brandl, jsizelove
severity: normal
status: open
title: zip() function example in tutorial
versions: Python 3.0
Added file: http://bugs.python.org/file11077/datastructures.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3522>
_______________________________________
From report at bugs.python.org Fri Aug 8 02:24:22 2008
From: report at bugs.python.org (Jim Sizelove)
Date: Fri, 08 Aug 2008 00:24:22 +0000
Subject: [New-bugs-announce] [issue3523] Reverse quotes in Python 3.0
tutorial
In-Reply-To: <1218155062.71.0.673827854609.issue3523@psf.upfronthosting.co.za>
Message-ID: <1218155062.71.0.673827854609.issue3523@psf.upfronthosting.co.za>
New submission from Jim Sizelove <jimsize at gmail.com>:
The Input and Output section of the tutorial says: "Reverse quotes (``)
are equivalent to repr(), but they are no longer used in modern Python
code and are removed in future versions of the language." Is now that
future time with Python 3.0? I get syntax errors when I try to run the
examples that use reverse quotes. The attached patch removes the
explanation and examples of reverse quotes.
----------
assignee: georg.brandl
components: Documentation
files: input_output.diff
keywords: patch
messages: 70873
nosy: georg.brandl, jsizelove
severity: normal
status: open
title: Reverse quotes in Python 3.0 tutorial
versions: Python 3.0
Added file: http://bugs.python.org/file11079/input_output.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3523>
_______________________________________
From report at bugs.python.org Fri Aug 8 02:42:35 2008
From: report at bugs.python.org (Jim Sizelove)
Date: Fri, 08 Aug 2008 00:42:35 +0000
Subject: [New-bugs-announce] [issue3524] IOError when attempting negative
seek in file (Python 3.0 tutorial)
In-Reply-To: <1218156155.34.0.949676293741.issue3524@psf.upfronthosting.co.za>
Message-ID: <1218156155.34.0.949676293741.issue3524@psf.upfronthosting.co.za>
New submission from Jim Sizelove <jimsize at gmail.com>:
The Input and Output section of the Python 3.0 tutorial
(http://docs.python.org/dev/3.0/tutorial/inputoutput.html) shows an
example of seeking in a negative direction from the end of a file. I
get an IOError when attempting to run the example in Python 3.0b2 on Mac
OS X 10.4 (PPC). I don't know whether the tutorial or the code should
be changed.
>>> f = open('workfile', 'r+')
>>> f.write('0123456789abcdef')
16
>>> f.seek(-3, 2)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File
"/Users/jimsize/Programming/Python/py3k/3.0b2/lib/python3.0/io.py", line
1609, in seek
raise IOError("can't do nonzero end-relative seeks")
IOError: can't do nonzero end-relative seeks
----------
assignee: georg.brandl
components: Documentation
messages: 70874
nosy: georg.brandl, jsizelove
severity: normal
status: open
title: IOError when attempting negative seek in file (Python 3.0 tutorial)
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3524>
_______________________________________
From report at bugs.python.org Fri Aug 8 03:10:28 2008
From: report at bugs.python.org (Jim Sizelove)
Date: Fri, 08 Aug 2008 01:10:28 +0000
Subject: [New-bugs-announce] [issue3525] Changes to exceptions not reflected
in tutorial examples.
In-Reply-To: <1218157828.17.0.153809100644.issue3525@psf.upfronthosting.co.za>
Message-ID: <1218157828.17.0.153809100644.issue3525@psf.upfronthosting.co.za>
New submission from Jim Sizelove <jimsize at gmail.com>:
PEPs 3109 and 3110 describe changes to Exceptions. The attached patch
file makes changes to the tutorial to bring it in line with the changes
to errors and exceptions implemented in Python 3.0.
I'll make a comment about the .args of exceptions instances. The
tutorial states "use of .args is discouraged." I found, however, that
the alternative of unpacking the args using __getitem__ raises a
TypeError.
>>> try:
... raise Exception('spam', 'eggs')
... except Exception as inst:
... x, y = inst
...
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
Exception: ('spam', 'eggs')
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<stdin>", line 4, in <module>
TypeError: 'Exception' object is not iterable
Does that mean that now .args is encouraged?
----------
assignee: georg.brandl
components: Documentation
files: errors.diff
keywords: patch
messages: 70876
nosy: georg.brandl, jsizelove
severity: normal
status: open
title: Changes to exceptions not reflected in tutorial examples.
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11080/errors.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3525>
_______________________________________
From report at bugs.python.org Fri Aug 8 12:13:01 2008
From: report at bugs.python.org (=?utf-8?q?S=C3=A9bastien_Sabl=C3=A9?=)
Date: Fri, 08 Aug 2008 10:13:01 +0000
Subject: [New-bugs-announce] [issue3526] Customized malloc implementation on
SunOS and AIX
In-Reply-To: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
Message-ID: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
New submission from S?bastien Sabl? <sable at users.sourceforge.net>:
Hi,
We run a big application mostly written in Python (with Pyrex/C
extensions) on different systems including Linux, SunOS and AIX.
The memory footprint of our application on Linux is fine; however we
found that on AIX and SunOS, any memory that has been allocated by our
application at some stage will never be freed at the system level.
After doing some analysis (see the 2 attached pdf documents), we found
that this is linked to the implementation of malloc on those various
systems:
The malloc used on Linux (glibc) is based on dlmalloc as described in
this document:
http://g.oswego.edu/dl/html/malloc.html
This implementation will use sbrk to allocate small chunks of memory,
but it will use mmap to allocate big chunks. This ensures that the
memory will actually get freed when free is called.
AIX and Sun have a more naive malloc implementation, so that the memory
allocated by an application through malloc is never actually freed until
the application leaves (this behavior has been confirmed by some experts
at IBM and Sun when we asked them for some feedback on this problem -
there is a 'memory disclaim' option on AIX but it is disabled by default
as it brings some major performance penalities).
For long running Python applications which may allocate a lot of memory
at some stage, this is a major drawback.
In order to bypass this limitation of the system on AIX and SunOS, we
have modified Python so that it will use the customized malloc
implementation dlmalloc like in glibc (see attached patch) - dlmalloc is
released in the public domain.
This patch adds a --enable-dlmalloc option to configure. When activated,
we observed a dramatic reduction of the memory used by our application.
I think many AIX and SunOS Python users could be interested by such an
improvement.
--
S?bastien Sabl?
Sungard
----------
files: customized_malloc_SUN.pdf
messages: 70897
nosy: sable
severity: normal
status: open
title: Customized malloc implementation on SunOS and AIX
type: resource usage
Added file: http://bugs.python.org/file11082/customized_malloc_SUN.pdf
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________
From report at bugs.python.org Fri Aug 8 12:44:33 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 08 Aug 2008 10:44:33 +0000
Subject: [New-bugs-announce] [issue3527] Py_WIN_WIDE_FILENAMES removal
In-Reply-To: <1218192273.13.0.480212879714.issue3527@psf.upfronthosting.co.za>
Message-ID: <1218192273.13.0.480212879714.issue3527@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:
Py_WIN_WIDE_FILENAMES is not used anywhere, this patch removes this macro.
----------
files: remove_macro.patch
keywords: patch
messages: 70899
nosy: ocean-city
severity: normal
status: open
title: Py_WIN_WIDE_FILENAMES removal
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11085/remove_macro.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3527>
_______________________________________
From report at bugs.python.org Fri Aug 8 14:29:54 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Fri, 08 Aug 2008 12:29:54 +0000
Subject: [New-bugs-announce] [issue3528] TypeError when compiling with no
translator
In-Reply-To: <1218198594.3.0.422262573033.issue3528@psf.upfronthosting.co.za>
Message-ID: <1218198594.3.0.422262573033.issue3528@psf.upfronthosting.co.za>
New submission from Robert Schuppenies <robert.schuppenies at gmail.com>:
I just ran 'make html' with the latest version and got this exception:
loading translations [en]... Exception occurred:
File "/home/bob/data/dvl/python/svn/doctools/sphinx/builder.py", line
184, in load_i18n
self.info('selected locale not available' % self.config.language)
TypeError: not all arguments converted during string f
The enclosed patch fixes the issue.
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: str_formatting.patch
keywords: patch
messages: 70901
nosy: georg.brandl, schuppenies
severity: normal
status: open
title: TypeError when compiling with no translator
type: behavior
Added file: http://bugs.python.org/file11087/str_formatting.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3528>
_______________________________________
From report at bugs.python.org Sat Aug 9 03:05:49 2008
From: report at bugs.python.org (Jim Sizelove)
Date: Sat, 09 Aug 2008 01:05:49 +0000
Subject: [New-bugs-announce] [issue3529] Remove long integer literals from
Python 3.0 tutorial
In-Reply-To: <1218243949.59.0.896920703107.issue3529@psf.upfronthosting.co.za>
Message-ID: <1218243949.59.0.896920703107.issue3529@psf.upfronthosting.co.za>
New submission from Jim Sizelove <jimsize at gmail.com>:
The distinction between integers and long integers has been removed in
Python 3.0. The attached patch file changes the long literals to Python
3.0 integer literals in the Floating Point Arithmetic section of the
tutorial.
----------
assignee: georg.brandl
components: Documentation
files: floatingpoint.diff
keywords: patch
messages: 70922
nosy: georg.brandl, jsizelove
severity: normal
status: open
title: Remove long integer literals from Python 3.0 tutorial
versions: Python 3.0
Added file: http://bugs.python.org/file11090/floatingpoint.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3529>
_______________________________________
From report at bugs.python.org Sat Aug 9 04:26:14 2008
From: report at bugs.python.org (daishi)
Date: Sat, 09 Aug 2008 02:26:14 +0000
Subject: [New-bugs-announce] [issue3530] ast.NodeTransformer bug
In-Reply-To: <1218248774.79.0.612230512704.issue3530@psf.upfronthosting.co.za>
Message-ID: <1218248774.79.0.612230512704.issue3530@psf.upfronthosting.co.za>
New submission from daishi <python at daishi.fastmail.fm>:
I am testing python 2.6 from SVN version: 40110
I tried the following, based on the documentation
and example in the ast module. I would expect the
second 'compile' to succeed also, instead of
throwing an exception.
Python 2.6b2+ (unknown, Aug 6 2008, 18:05:08)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> a = ast.parse('foo', mode='eval')
>>> x = compile(a, '<unknown>', mode='eval')
>>> class RewriteName(ast.NodeTransformer):
... def visit_Name(self, node):
... return ast.copy_location(ast.Subscript(
... value=ast.Name(id='data', ctx=ast.Load()),
... slice=ast.Index(value=ast.Str(s=node.id)),
... ctx=node.ctx
... ), node)
...
>>> a2 = RewriteName().visit(a)
>>> x2 = compile(a2, '<unknown>', mode='eval')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: required field "lineno" missing from expr
>>>
----------
components: Library (Lib)
messages: 70923
nosy: daishiharada
severity: normal
status: open
title: ast.NodeTransformer bug
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3530>
_______________________________________
From report at bugs.python.org Sat Aug 9 04:29:45 2008
From: report at bugs.python.org (Andrew Dalke)
Date: Sat, 09 Aug 2008 02:29:45 +0000
Subject: [New-bugs-announce] [issue3531] file read preallocs 'size' bytes
which can cause memory problems
In-Reply-To: <1218248985.75.0.478147960205.issue3531@psf.upfronthosting.co.za>
Message-ID: <1218248985.75.0.478147960205.issue3531@psf.upfronthosting.co.za>
New submission from Andrew Dalke <dalke at dalkescientific.com>:
I wrote a buggy PNG parser which ended up doing several file.read(large
value). It causes a MemoryError, which was strange because the file was
only a few KB long.
I tracked it down to the implementation of read(). When given a size
hint it preallocates the return string with that size. If the hint is
for 10MB then the string returned will be preallocated fro 10MB, even if
the actual read is empty.
Here's a reproducible
BLOCKSIZE = 10*1024*1024
f=open("empty.txt", "w")
f.close()
f=open("empty.txt")
data = []
for i in range(10000):
s = f.read(BLOCKSIZE)
assert len(s) == 0
data.append(s)
I wasn't sure if this is properly a bug, but since the MemoryError
exception I got was quite unexpected and required digging into the
source code to figure out, I'll say that it is.
----------
components: Interpreter Core
messages: 70924
nosy: dalke
severity: normal
status: open
title: file read preallocs 'size' bytes which can cause memory problems
type: resource usage
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3531>
_______________________________________
From report at bugs.python.org Sat Aug 9 18:29:54 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sat, 09 Aug 2008 16:29:54 +0000
Subject: [New-bugs-announce] [issue3532] bytes.tohex method
In-Reply-To: <1218299394.34.0.421334599583.issue3532@psf.upfronthosting.co.za>
Message-ID: <1218299394.34.0.421334599583.issue3532@psf.upfronthosting.co.za>
New submission from Matt Giuca <matt.giuca at gmail.com>:
I haven't been able to find a way to encode a bytes object in
hexadecimal, where in Python 2.x I'd go "str.encode('hex')".
I recommend adding a bytes.tohex() method (in the same vein as the
existing bytes.fromhex class method).
I've attached a patch which adds this method to the bytes and bytearray
classes (in the C code). Also included documentation and test cases.
Style note: The bytesobject.c and bytearrayobject.c files are all over
the place in terms of tabs/spaces. I used tabs in bytesobject and spaces
in bytearrayobject, since those seemed to be the predominant styles in
either file.
Commit log:
Added "tohex" method to bytes and bytearray objects. Also added
documentation and test cases.
----------
components: Interpreter Core
files: bytes.tohex.patch
keywords: patch
messages: 70932
nosy: mgiuca
severity: normal
status: open
title: bytes.tohex method
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file11091/bytes.tohex.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3532>
_______________________________________
From report at bugs.python.org Sat Aug 9 18:46:11 2008
From: report at bugs.python.org (Barry Alan Scott)
Date: Sat, 09 Aug 2008 16:46:11 +0000
Subject: [New-bugs-announce] [issue3533] mac 10.4 buld of 3.0 --with-pydebug
fails no __eprintf
In-Reply-To: <1218300371.75.0.851068496859.issue3533@psf.upfronthosting.co.za>
Message-ID: <1218300371.75.0.851068496859.issue3533@psf.upfronthosting.co.za>
New submission from Barry Alan Scott <barry-scott at users.sourceforge.net>:
I wanted to use Py_DEBUG build to help debug a problem
with ref counts in a C++ extension.
I cannot find eprintf in the sources of python
where does this symbol come from? How do I fix the
build to define it?
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.4.11
BuildVersion: 8S165
$ ./configure --enable-framework --enable-debug --with-pydebug
$ make
...
/usr/bin/install -c -d -m 755 Python.framework/Versions/3.0
if test ""; then \
gcc -o Python.framework/Versions/3.0/Python -dynamiclib \
-isysroot "" \
-all_load libpython3.0.a -Wl,-single_module \
-install_name
/Library/Frameworks/Python.framework/Versions/3.0/Python \
-compatibility_version 3.0 \
-current_version 3.0; \
else \
/usr/bin/libtool -o Python.framework/Versions/3.0/Python
-dynamic libpython3.0.a \
-lSystem -lSystemStubs -arch_only ppc -install_name
/Library/Frameworks/Python.framework/Versions/3.0/Python
-compatibility_version 3.0 -current_version 3.0 ;\
fi
ld: Undefined symbols:
___eprintf
/usr/bin/libtool: internal link edit command failed
make: *** [Python.framework/Versions/3.0/Python] Error 1
----------
components: Build
messages: 70935
nosy: barry-scott
severity: normal
status: open
title: mac 10.4 buld of 3.0 --with-pydebug fails no __eprintf
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3533>
_______________________________________
From report at bugs.python.org Sat Aug 9 20:17:13 2008
From: report at bugs.python.org (Roger Upole)
Date: Sat, 09 Aug 2008 18:17:13 +0000
Subject: [New-bugs-announce] [issue3534] refactor.py can lose indentation
for relative imports
In-Reply-To: <1218305833.19.0.0391754178644.issue3534@psf.upfronthosting.co.za>
Message-ID: <1218305833.19.0.0391754178644.issue3534@psf.upfronthosting.co.za>
New submission from Roger Upole <rupole at hotmail.com>:
Here's an excerpt from the output when run with --verbose.
@@ -138,7 +136,7 @@
def _MakeColorizer(self):
ext = os.path.splitext(self.GetDocument().GetPathName())
- import formatter
+from . import formatter
return formatter.BuiltinPythonSourceFormatter(self, ext)
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 70947
nosy: collinwinter, rupole
severity: normal
status: open
title: refactor.py can lose indentation for relative imports
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3534>
_______________________________________
From report at bugs.python.org Sun Aug 10 11:27:28 2008
From: report at bugs.python.org (alonwas)
Date: Sun, 10 Aug 2008 09:27:28 +0000
Subject: [New-bugs-announce] [issue3535] zipfile has problem reading zip
files over 2GB
In-Reply-To: <1218360448.56.0.0890131265061.issue3535@psf.upfronthosting.co.za>
Message-ID: <1218360448.56.0.0890131265061.issue3535@psf.upfronthosting.co.za>
New submission from alonwas <alon.was at gmail.com>:
zipfile complains about "Bad magic number for central directory" when I
give it files over 2GB. I believe the problem is that the offset for the
central directory should be read as an unsigned long rather than as a
signed long. Modifying structEndArchive from "<4s4H2lH" to "<4s4H2LH"
(note the capital L) should probably fix it. When the offset is >2^31
you get a negative offset and the code fails to find the central
directory. I'll appreciate it if someone more knowledgeable looks at the
problem and the suggested fix, Thanks, Alon
----------
components: Library (Lib)
messages: 70968
nosy: alonwas
severity: normal
status: open
title: zipfile has problem reading zip files over 2GB
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3535>
_______________________________________
From report at bugs.python.org Sun Aug 10 14:06:32 2008
From: report at bugs.python.org (=?utf-8?q?Ozan_=C3=87a=C4=9Flayan?=)
Date: Sun, 10 Aug 2008 12:06:32 +0000
Subject: [New-bugs-announce] [issue3536] case conversion problems in Turkish
In-Reply-To: <1218369992.36.0.178922687211.issue3536@psf.upfronthosting.co.za>
Message-ID: <1218369992.36.0.178922687211.issue3536@psf.upfronthosting.co.za>
New submission from Ozan ?a?layan <ozancag at gmail.com>:
>>> sys.getdefaultencoding()
'utf-8'
>>> s = 'i?'
>>> s.upper()
'II' # should be '?I'
>>> t = 'I?'
>>> t.lower()
'ii' # should be '?i'
>>> unicodedata.name('?') # The small dotless one
'LATIN SMALL LETTER DOTLESS I'
>>> unicodedata.name('I') # The capital dotless one
'LATIN CAPITAL LETTER I'
>>> unicodedata.name('i') # The small 'i'
'LATIN SMALL LETTER I'
>>> unicodedata.name('?') # The corresponding capital one
'LATIN CAPITAL LETTER I WITH DOT ABOVE'
The other non-ascii turkish characters '??????????' are correctly
handled by case conversion methods.
----------
components: Unicode
messages: 70972
nosy: ozan
severity: normal
status: open
title: case conversion problems in Turkish
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3536>
_______________________________________
From report at bugs.python.org Sun Aug 10 20:10:24 2008
From: report at bugs.python.org (Roger Upole)
Date: Sun, 10 Aug 2008 18:10:24 +0000
Subject: [New-bugs-announce] [issue3537] dict creation failure causes crash
In-Reply-To: <1218391824.09.0.805958642576.issue3537@psf.upfronthosting.co.za>
Message-ID: <1218391824.09.0.805958642576.issue3537@psf.upfronthosting.co.za>
New submission from Roger Upole <rupole at hotmail.com>:
If the first item can't be inserted the interpreter will crash
eventually.
while 1:
try:
d = { 'a':a,
'b':'b',
'c':'c',
'd':'d',
'e':'e',
'f':'f',
'g':'g',
'h':'h',
'i':'i',
'j':'j',
'k':'k',
'l':'l',
'm':'m',
'n':'n',
'o':'o'
}
except:
pass
As best I can tell, this only happens for the first item.
In a debug build, this assert fails on the second time thru
the loop (dictobject.c, line 247):
assert (mp->ma_table == mp->ma_smalltable);
Apparently something is leaving one of the entries in the list
of preallocated dict objects in an inconsistent state.
----------
messages: 70990
nosy: rupole
severity: normal
status: open
title: dict creation failure causes crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3537>
_______________________________________
From report at bugs.python.org Mon Aug 11 00:16:34 2008
From: report at bugs.python.org (Rambo007)
Date: Sun, 10 Aug 2008 22:16:34 +0000
Subject: [New-bugs-announce] [issue3538] Docstring typos
In-Reply-To: <1218406594.2.0.281031629955.issue3538@psf.upfronthosting.co.za>
Message-ID: <1218406594.2.0.281031629955.issue3538@psf.upfronthosting.co.za>
New submission from Rambo007 <wxpythoner at gmail.com>:
Hello. I was pokinf around in the Python 3.0b2 interpreter and I found
some typos in the following doctring:
>>> import sys; print(sys.platform.__doc__)
str(string[, encoding[, errors]]) -> str
Create a new string object from the given encoded string.
encoding defaults to the current default string encoding.
errors can be 'strict', 'replace' or 'ignore' and defaults to 'strict'.
Please fix the docstring words 'encoding' and 'errors' to have the
capital initial letter, so that the docstring would look like this:
str(string[, encoding[, errors]]) -> str
Create a new string object from the given encoded string.
Encoding defaults to the current default string encoding.
Errors can be 'strict', 'replace' or 'ignore' and defaults to 'strict'.
Please fix other similar typos if you find them. Thank you.
----------
assignee: georg.brandl
components: Documentation
messages: 70996
nosy: Rambo007, georg.brandl
severity: normal
status: open
title: Docstring typos
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3538>
_______________________________________
From report at bugs.python.org Mon Aug 11 02:55:55 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 11 Aug 2008 00:55:55 +0000
Subject: [New-bugs-announce] [issue3539] Problem with pgen make dependencies
in certain circumstances
In-Reply-To: <1218416155.29.0.722740811463.issue3539@psf.upfronthosting.co.za>
Message-ID: <1218416155.29.0.722740811463.issue3539@psf.upfronthosting.co.za>
New submission from Skip Montanaro <skip at pobox.com>:
I usually build Python directly in my source repository (the directory
containing the configure script). Accordingly, I have .o files scattered
throughout my sandbox.
Today I decided to build --with-pydebug, so I created a debug directory,
then ran ../configure from within that directory, giving the arguments
I wanted. When I ran make it croaked with a link error linking pgen.
The linker complained that tokenizer_pgen.o and pgenmain.o weren't found.
Messing around with make -d I figured out that when make ran it
concluded that Parser/pgenmain.o didn't need to be rebuilt. It thought
that ../Parser/pgenmain.o satisfied the dependency for Parser/pgenmain.o.
I don't know if this is a problem with GNU make's VPATH processing or
with the dependency specification in Python's makefile.
I can work around the problem by avoiding builds directly in my sandbox
but it would be nice if this worked.
(I'm experiencing a sense of deja vu. Perhaps I've reported this problem
sometime in the dim, dark past, but I can't find anything searching for
either "VPATH" or "makefile".)
----------
components: Build
messages: 70998
nosy: skip.montanaro
severity: normal
status: open
title: Problem with pgen make dependencies in certain circumstances
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3539>
_______________________________________
From report at bugs.python.org Mon Aug 11 11:59:34 2008
From: report at bugs.python.org (MATSUI Tetsushi)
Date: Mon, 11 Aug 2008 09:59:34 +0000
Subject: [New-bugs-announce] [issue3540] NotEmptyErrorError
In-Reply-To: <1218448774.78.0.853237126897.issue3540@psf.upfronthosting.co.za>
Message-ID: <1218448774.78.0.853237126897.issue3540@psf.upfronthosting.co.za>
New submission from MATSUI Tetsushi <mft at users.sourceforge.net>:
In the library reference of mailbox,
NotEmptyError appears as NotEmptyErrorError.
For exampe:
http://docs.python.org/dev/3.0/library/mailbox.html#mailbox.NotEmptyErrorError
----------
assignee: georg.brandl
components: Documentation
messages: 71007
nosy: georg.brandl, mft
severity: normal
status: open
title: NotEmptyErrorError
versions: Python 2.5, Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3540>
_______________________________________
From report at bugs.python.org Mon Aug 11 15:07:02 2008
From: report at bugs.python.org (Kuang-che Wu)
Date: Mon, 11 Aug 2008 13:07:02 +0000
Subject: [New-bugs-announce] [issue3541] bsddb memory leak on ubuntu
In-Reply-To: <1218460022.22.0.445363609563.issue3541@psf.upfronthosting.co.za>
Message-ID: <1218460022.22.0.445363609563.issue3541@psf.upfronthosting.co.za>
New submission from Kuang-che Wu <kcwu at csie.org>:
On ubuntu, python 2.5.2.
The memory usage of following program is increasing infinitly. There may
be something leaking.
However, it only consumes constant memory on windows (python 2.5.2).
import bsddb
d = bsddb.hashopen('a.db', 'c')
d.close()
while True:
d = bsddb.hashopen('a.db')
d.close()
----------
components: Extension Modules
messages: 71013
nosy: kcwu
severity: normal
status: open
title: bsddb memory leak on ubuntu
type: resource usage
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3541>
_______________________________________
From report at bugs.python.org Mon Aug 11 17:30:21 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Aug 2008 15:30:21 +0000
Subject: [New-bugs-announce] [issue3542] Building an MSI installer crashes
In-Reply-To: <1218468621.31.0.60930081544.issue3542@psf.upfronthosting.co.za>
Message-ID: <1218468621.31.0.60930081544.issue3542@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
msilib hasn't been updated for py3k, consequently bdist_msi fails. The
provided patch fixes it, but encoding issues are not worked out (in my
tests, selecting an utf-8 codepage produces unrecognized msi files).
----------
components: Library (Lib)
files: msilib.patch
keywords: patch
messages: 71018
nosy: loewis, pitrou
priority: critical
severity: normal
status: open
title: Building an MSI installer crashes
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file11099/msilib.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3542>
_______________________________________
From report at bugs.python.org Mon Aug 11 20:37:58 2008
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 11 Aug 2008 18:37:58 +0000
Subject: [New-bugs-announce] [issue3543] ctypes works on Intel OS X,
fails on PPC OS X
In-Reply-To: <1218479878.6.0.0482444198059.issue3543@psf.upfronthosting.co.za>
Message-ID: <1218479878.6.0.0482444198059.issue3543@psf.upfronthosting.co.za>
New submission from Bill Janssen <bill.janssen at gmail.com>:
Hi, I'm having more problems with ctypes.util.find_library. On my
Intel box, this works fine:
% python
Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import CDLL, RTLD_GLOBAL
>>> from ctypes.util import find_library
>>> print CDLL(find_library("iconv"), RTLD_GLOBAL)
<CDLL '/usr/lib/libiconv.dylib', handle 311df0 at 8a1b0>
>>>
But on my PowerPC box, I get this:
% python
Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:16)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import CDLL, RTLD_GLOBAL
>>> from ctypes.util import find_library
>>> print CDLL(find_library("iconv"), RTLD_GLOBAL)
<CDLL 'None', handle fffffffe at 75af0>
>>>
Both have /usr/lib/libiconv.dylib, both are running 10.5.4.
----------
components: Library (Lib)
messages: 71028
nosy: janssen
priority: normal
severity: normal
status: open
title: ctypes works on Intel OS X, fails on PPC OS X
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3543>
_______________________________________
From report at bugs.python.org Tue Aug 12 01:29:56 2008
From: report at bugs.python.org (endolith)
Date: Mon, 11 Aug 2008 23:29:56 +0000
Subject: [New-bugs-announce] [issue3544] "expection" typo
In-Reply-To: <1218497396.52.0.0979019785158.issue3544@psf.upfronthosting.co.za>
Message-ID: <1218497396.52.0.0979019785158.issue3544@psf.upfronthosting.co.za>
New submission from endolith <endolith at gmail.com>:
http://docs.python.org/lib/typecontextmanager.html
"if any expection that occurred should be suppressed"
----------
assignee: georg.brandl
components: Documentation
messages: 71035
nosy: endolith, georg.brandl
severity: normal
status: open
title: "expection" typo
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3544>
_______________________________________
From report at bugs.python.org Tue Aug 12 12:05:31 2008
From: report at bugs.python.org (Anders Bensryd)
Date: Tue, 12 Aug 2008 10:05:31 +0000
Subject: [New-bugs-announce] [issue3545] Python turning off assertions
(Windows)
In-Reply-To: <1218535531.94.0.182570624972.issue3545@psf.upfronthosting.co.za>
Message-ID: <1218535531.94.0.182570624972.issue3545@psf.upfronthosting.co.za>
New submission from Anders Bensryd <anders.bensryd at aveva.com>:
We are using Windows XP SP2, Visual Studio 2005 & Python 2.5.2.
In Objects/exceptions.c the following code turns off all assertions.
#if defined _MSC_VER && _MSC_VER >= 1400 && defined(__STDC_SECURE_LIB__)
/* Set CRT argument error handler */
prevCrtHandler = _set_invalid_parameter_handler
(InvalidParameterHandler);
/* turn off assertions in debug mode */
prevCrtReportMode = _CrtSetReportMode(_CRT_ASSERT, 0);
#endif
As far as I understand, this is to make sure that no assertion dialogs
pop up during the internal Python tests. For ordinary users, this is
not an issue.
However, we are using the Python DLL in our product and when developing
we always use the debug version of the Python DLL (as recommended).
When we do Py_Initialize() all assertions are turned off, even our
assertions, and this is not what we want. The current workaround is as
follows (this is in our code):
prevCrtReportMode=_CrtSetReportMode(_CRT_ASSERT,_CRTDBG_REPORT_MODE);
Py_Initialize();
prevCrtReportMode=_CrtSetReportMode(_CRT_ASSERT,prevCrtReportMode);
I am not certain if this is a bug or a feature and I really do not have
a suggested solution since I do not know the real reasons for turning
off assertions. Perhaps there already is a way to avoid this problem
that I have not found?
All comments are appreciated.
----------
components: Windows
messages: 71049
nosy: abe
severity: normal
status: open
title: Python turning off assertions (Windows)
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3545>
_______________________________________
From report at bugs.python.org Tue Aug 12 16:54:30 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Tue, 12 Aug 2008 14:54:30 +0000
Subject: [New-bugs-announce] [issue3546] Missing linebreak in ext.doctest
output
In-Reply-To: <1218552870.92.0.456647494435.issue3546@psf.upfronthosting.co.za>
Message-ID: <1218552870.92.0.456647494435.issue3546@psf.upfronthosting.co.za>
New submission from Robert Schuppenies <robert.schuppenies at gmail.com>:
There is a linebreak missing in the doctest extension. See attached patch.
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: linebreak.patch
keywords: patch
messages: 71053
nosy: georg.brandl, schuppenies
severity: normal
status: open
title: Missing linebreak in ext.doctest output
type: behavior
Added file: http://bugs.python.org/file11102/linebreak.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3546>
_______________________________________
From report at bugs.python.org Tue Aug 12 18:20:18 2008
From: report at bugs.python.org (Tim Maxwell)
Date: Tue, 12 Aug 2008 16:20:18 +0000
Subject: [New-bugs-announce] [issue3547] Ctypes is confused by bitfields of
varying integer types
In-Reply-To: <1218558018.93.0.569249577557.issue3547@psf.upfronthosting.co.za>
Message-ID: <1218558018.93.0.569249577557.issue3547@psf.upfronthosting.co.za>
New submission from Tim Maxwell <timmaxw at gmail.com>:
Steps to reproduce:
Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *
>>> fields = [('a', c_short, 4), ('b', c_short, 4), ('c', c_long, 24)]
>>> class Foo(Structure):
... _fields_ = fields
...
>>> Foo.a
<Field type=c_short, ofs=0:0, bits=4>
>>> Foo.b
<Field type=c_short, ofs=0:4, bits=4>
>>> Foo.c
<Field type=c_long, ofs=-2:8, bits=24> # Wrong!
More about my machine:
>>> sizeof(c_short)
2
>>> sizeof(c_long)
4
This particular example comes from a 32-bit Mac OS X Intel machine. The
bug has been reproduced on Linux as well, but could not be reproduced on
Windows XP.
----------
assignee: theller
components: ctypes
messages: 71060
nosy: theller, tim.maxwell
severity: normal
status: open
title: Ctypes is confused by bitfields of varying integer types
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3547>
_______________________________________
From report at bugs.python.org Tue Aug 12 19:23:59 2008
From: report at bugs.python.org (Miki Tebeka)
Date: Tue, 12 Aug 2008 17:23:59 +0000
Subject: [New-bugs-announce] [issue3548] subprocess.pipe function
In-Reply-To: <1218561839.36.0.810217326739.issue3548@psf.upfronthosting.co.za>
Message-ID: <1218561839.36.0.810217326739.issue3548@psf.upfronthosting.co.za>
New submission from Miki Tebeka <miki.tebeka at gmail.com>:
Attached is a patch that add "pipe" command to the "subprocess" module.
pipe(["ls"], ["grep", "test_"]) will return the output of
"ls | grep test_".
----------
components: Library (Lib)
files: pipe.patch
keywords: patch
messages: 71062
nosy: tebeka
severity: normal
status: open
title: subprocess.pipe function
type: feature request
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11104/pipe.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3548>
_______________________________________
From report at bugs.python.org Wed Aug 13 23:29:14 2008
From: report at bugs.python.org (Paul Chew)
Date: Wed, 13 Aug 2008 21:29:14 +0000
Subject: [New-bugs-announce] [issue3549] Missing IDLE Preferences on Mac
In-Reply-To: <1218662954.17.0.753425221317.issue3549@psf.upfronthosting.co.za>
Message-ID: <1218662954.17.0.753425221317.issue3549@psf.upfronthosting.co.za>
New submission from Paul Chew <chew at cs.cornell.edu>:
When the latest Mac installer (Python 2.5.2 for Macintosh OS X) is used on
a new Mac (10.5.4) the resulting IDLE does not have a Preferences... entry
in its File menu. The only fix that I've found is to use the previous Mac
installer (python-2.5.1-macosx.dmg).
----------
components: IDLE, Installation, Macintosh
messages: 71100
nosy: pchew
severity: normal
status: open
title: Missing IDLE Preferences on Mac
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3549>
_______________________________________
From report at bugs.python.org Thu Aug 14 04:24:20 2008
From: report at bugs.python.org (Andrew R.)
Date: Thu, 14 Aug 2008 02:24:20 +0000
Subject: [New-bugs-announce] [issue3550] Socket Python 3k Documentation
failure OR Unicode string is not supported with socket.send
In-Reply-To: <1218680660.59.0.981908565171.issue3550@psf.upfronthosting.co.za>
Message-ID: <1218680660.59.0.981908565171.issue3550@psf.upfronthosting.co.za>
New submission from Andrew R. <ajr1991 at comcast.net>:
I am confused by the socket docs for Python 3000. It says to pass a
string through socket.send or socket.sendall, however, it does not seem
to account for the ASCII to Unicode transition. Trying to send an
ordinary Python 3k string through socket.send fails with a TypeError
stating that the first arg must be bytes or buffers but not a str.
Besides the misdocumented sockets, I would think it would be easier to
translate a Unicode string to ASCII, however, I fear this might violate
the "Explicit is better than implicit" rule and RFC tables.
----------
assignee: georg.brandl
components: Documentation
messages: 71105
nosy: georg.brandl, st33med
severity: normal
status: open
title: Socket Python 3k Documentation failure OR Unicode string is not supported with socket.send
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3550>
_______________________________________
From report at bugs.python.org Thu Aug 14 13:11:21 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 14 Aug 2008 11:11:21 +0000
Subject: [New-bugs-announce] [issue3551] multiprocessing.Pipe terminates
with ERROR_NO_SYSTEM_RESOURCES if large data is sent (win2000)
In-Reply-To: <1218712281.34.0.473878484861.issue3551@psf.upfronthosting.co.za>
Message-ID: <1218712281.34.0.473878484861.issue3551@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
I noticed sometimes regrtest.py fails in test_multiprocessing.py
(test_connection) on win2000.
I could not reproduce error by invoking test_multiprocessing alone, but
finally I could do it by incresing 'really_big_msg' to 32MB or more.
I attached reproducable code. I don't know why this happens yet.
----------
components: Library (Lib), Windows
files: reproduce.py
messages: 71119
nosy: ocean-city
severity: normal
status: open
title: multiprocessing.Pipe terminates with ERROR_NO_SYSTEM_RESOURCES if large data is sent (win2000)
versions: Python 2.6
Added file: http://bugs.python.org/file11109/reproduce.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3551>
_______________________________________
From report at bugs.python.org Thu Aug 14 16:50:28 2008
From: report at bugs.python.org (Matt Giuca)
Date: Thu, 14 Aug 2008 14:50:28 +0000
Subject: [New-bugs-announce] [issue3552] uuid - exception on uuid3/uuid5
In-Reply-To: <1218725428.36.0.572136195282.issue3552@psf.upfronthosting.co.za>
Message-ID: <1218725428.36.0.572136195282.issue3552@psf.upfronthosting.co.za>
New submission from Matt Giuca <matt.giuca at gmail.com>:
The test suite breaks on the Lib/test/test_uuid.py, as of r65661. This
is because uuid3 and uuid5 now raise exceptions.
TypeError: new() argument 1 must be bytes or read-only buffer, not bytearray
The problem is due to the changes in the way "s#" now expects a
read-only buffer in PyArg_ParseTupleAndKeywords. (Which was changed in
r65661).
A rundown of the problem:
Lib/uuid.py:553 (in uuid.uuid3):
hash = md5(namespace.bytes + bytes(name, "utf-8")).digest()
namespace.bytes is a bytearray, so the argument to md5 is a bytearray.
Modules/md5module.c:517 (in _md5.md5.new):
if (!PyArg_ParseTupleAndKeywords(args, kwdict, "|s#:new", kwlist,
Using s# now requires a read-only buffer, so this raises a TypeError.
The same goes for uuid5 (which calls _sha1.sha1, and has exactly the
same problem).
The commit log for r65561 suggests changing some s# into s* (which
allows readable buffers). I don't understand the ramifications here
(some problem with threading), and when I made that change, it seg
faulted, so I'll leave well enough alone. But for someone who knows more
what they're doing, that may be a more "root-of-the-problem" fix.
In the meantime, I propose this simple patch to fix uuid: I think
namespace.bytes should actually return a bytes, not a bytearray, so I'm
modifying it to return a bytes.
Related issue:
http://bugs.python.org/issue3139
Patch for r65675.
Commit log:
Fixed TypeError raised by uuid.uuid3 and uuid.uuid5, by passing a
bytearray to hash functions. Now namespace.bytes returns a bytes instead
of a bytearray.
----------
components: Library (Lib)
files: uuid.patch
keywords: patch
messages: 71129
nosy: mgiuca
severity: normal
status: open
title: uuid - exception on uuid3/uuid5
type: compile error
versions: Python 3.0
Added file: http://bugs.python.org/file11110/uuid.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3552>
_______________________________________
From report at bugs.python.org Thu Aug 14 17:44:56 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Aug 2008 15:44:56 +0000
Subject: [New-bugs-announce] [issue3553] "2to3 -l" doesn't work when
installed in /opt
In-Reply-To: <1218728696.82.0.307782254741.issue3553@psf.upfronthosting.co.za>
Message-ID: <1218728696.82.0.307782254741.issue3553@psf.upfronthosting.co.za>
New submission from STINNER Victor <haypo at users.sourceforge.net>:
I just installed Python 3.0b2 in /opt/py3k and tried 2to3 tool:
$ /opt/py3k/bin/2to3 -l
Available transformations for the -f/--fix option:
Traceback (most recent call last):
File "/opt/py3k/bin/2to3", line 5, in <module>
sys.exit(refactor.main("lib2to3/fixes"))
File "/opt/py3k/lib/python3.0/lib2to3/refactor.py", line 69, in main
for fixname in get_all_fix_names(fixer_dir):
File "/opt/py3k/lib/python3.0/lib2to3/refactor.py", line 102, in
get_all_fix_names
names = os.listdir(fixer_dir)
OSError: [Errno 2] No such file or directory: 'lib2to3/fixes'
fixer_dir is the relative directory name "lib2to3/fixes", it should be
an absolute directory. Example (ugly code copied from
RefactoringTool.get_fixers()) to get the full path in refactor.py
(main function):
if not os.path.isabs(fixer_dir):
fixer_pkg = fixer_dir.replace(os.path.sep, ".")
if os.path.altsep:
fixer_pkg = fixer_pkg.replace(os.path.altsep, ".")
mod = __import__(fixer_pkg, {}, {}, ["*"])
fixer_dir = os.path.dirname(mod.__file__)
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 71132
nosy: collinwinter, haypo
severity: normal
status: open
title: "2to3 -l" doesn't work when installed in /opt
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3553>
_______________________________________
From report at bugs.python.org Thu Aug 14 18:39:52 2008
From: report at bugs.python.org (Kevin Watters)
Date: Thu, 14 Aug 2008 16:39:52 +0000
Subject: [New-bugs-announce] [issue3554] ctypes.wstring_at and string_at
call Python API without the GIL
In-Reply-To: <1218731992.24.0.0258351695719.issue3554@psf.upfronthosting.co.za>
Message-ID: <1218731992.24.0.0258351695719.issue3554@psf.upfronthosting.co.za>
New submission from Kevin Watters <kevinwatters at gmail.com>:
in Lib/ctypes/__init__.py the wstring_at and string_at functions are
declared with CFUNCTYPE.
This means that in Modules/_ctypes/callproc.c when the functions are
invoked, Py_UNBLOCK_THREADS and Py_BLOCK_THREADS surround the call. But
string_at and wstring_at call PyString_FromString and
PyUnicode_FromWideChar, respectively.
The solution (I think) is to declare the functions with PYFUNCTYPE
instead, so that callproc.c doesn't release the GIL when calling them.
----------
assignee: theller
components: ctypes
messages: 71135
nosy: kevinwatters, theller
severity: normal
status: open
title: ctypes.wstring_at and string_at call Python API without the GIL
type: crash
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3554>
_______________________________________
From report at bugs.python.org Thu Aug 14 21:03:35 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Thu, 14 Aug 2008 19:03:35 +0000
Subject: [New-bugs-announce] [issue3555] Regression: nested exceptions crash
(Cannot recover from stack overflow)
In-Reply-To: <1218740615.84.0.303510238935.issue3555@psf.upfronthosting.co.za>
Message-ID: <1218740615.84.0.303510238935.issue3555@psf.upfronthosting.co.za>
New submission from Daniel Diniz <ajaksu at gmail.com>:
The following code works[1] on trunk and 2.5.1, but crashes with "Fatal
Python error: Cannot recover from stack overflow," on py3k as of rev65676:
######
# Python 3.0b2+ (py3k:65676, Aug 14 2008, 14:37:38)
# [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
import sys
def overflower():
try:
return overflower()
except:
return sys.exc_info()
def f():
try:
return f()
except:
return overflower()
f()
######
Catching RuntimeError crashes, letting it be raised avoids the crash.
Adding "finally: return overflower()" along with a non
RuntimeError-catching except also gives a Fatal Python error.
A smaller test case for hitting the overflow in py3k would be "def f():
[...] except: return f()", but that hangs in an (desirable?) infinite
loop in 2.5 and trunk.
[1] "Works" as in "doesn't crash", but both the code above and the
infinite loop hit issue2548 when run on a debug build of trunk. Calling
overflower() alone in trunk hits the "undetected error" discussed in
that issue, but works fine in py3k.
----------
components: Interpreter Core
messages: 71141
nosy: ajaksu2
severity: normal
status: open
title: Regression: nested exceptions crash (Cannot recover from stack overflow)
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3555>
_______________________________________
From report at bugs.python.org Thu Aug 14 22:21:19 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 14 Aug 2008 20:21:19 +0000
Subject: [New-bugs-announce] [issue3556] test_raiseMemError consumes an
insane amount of memory
In-Reply-To: <1218745279.31.0.475449103672.issue3556@psf.upfronthosting.co.za>
Message-ID: <1218745279.31.0.475449103672.issue3556@psf.upfronthosting.co.za>
New submission from Martin v. L?wis <martin at v.loewis.de>:
It appears that test_unicode::test_raiseMemError was meant to produce a
MemoryError. Unfortunately, on my machine (Linux 2.6.25, 32-bit
processor, 1GiB main memory, plenty swap), allocation *succeed*, and
then brings the machine to a near halt, trying to fill that memory with
data.
IMO, the patch should be rewritten to either reliably produce a
MemoryError (why not allocate sys.maxsize characters, or sys.maxsize//2?),
or else it should be removed.
----------
assignee: amaury.forgeotdarc
messages: 71150
nosy: amaury.forgeotdarc, loewis
severity: normal
status: open
title: test_raiseMemError consumes an insane amount of memory
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3556>
_______________________________________
From report at bugs.python.org Fri Aug 15 04:39:35 2008
From: report at bugs.python.org (Matt Giuca)
Date: Fri, 15 Aug 2008 02:39:35 +0000
Subject: [New-bugs-announce] [issue3557] Segfault in sha1
In-Reply-To: <1218767975.42.0.656822559371.issue3557@psf.upfronthosting.co.za>
Message-ID: <1218767975.42.0.656822559371.issue3557@psf.upfronthosting.co.za>
New submission from Matt Giuca <matt.giuca at gmail.com>:
Continuing the discussion from Issue 3552
(http://bugs.python.org/issue3552).
r65676 makes changes to Modules/md5module.c and Modules/sha1module.c, to
allow them to read mutable buffers.
There's a segfault in sha1module if given 0 arguments. eg:
>>> import _sha1
>>> _sha1.sha1()
Segmentation fault
Docs here suggest this should be OK:
http://docs.python.org/dev/3.0/library/hashlib.html
This crashes on the Lib/test/test_hmac.py test case, but apparently
(according to Margin on issue 3552) none of the build bots see it
because they use libopenssl and completely bypass the _md5 and _sha1
modules. Also there are no direct test cases for either of these modules.
This is because new code in r65676 doesn't initialise a pointer to NULL.
Fixed in patch (as well as replaced tab with spaces for consistency, in
both modules).
I strongly recommend that a) A "build bot" be made to use _md5 and _sha1
instead of OpenSSL (or they aren't running that code at all), AND/OR b)
Direct test cases be written for _md5 and _sha1.
Commit log:
Fixed crash on _sha1.sha1(), with no arguments, due to not initialising
pointer.
Normalised indentation in md5module.c and sha1module.c.
----------
components: Interpreter Core
files: sha1.patch
keywords: patch
messages: 71157
nosy: mgiuca
severity: normal
status: open
title: Segfault in sha1
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file11118/sha1.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3557>
_______________________________________
From report at bugs.python.org Fri Aug 15 06:46:01 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Aug 2008 04:46:01 +0000
Subject: [New-bugs-announce] [issue3558] Operator precedence misdocumented
In-Reply-To: <1218775561.6.0.243287416094.issue3558@psf.upfronthosting.co.za>
Message-ID: <1218775561.6.0.243287416094.issue3558@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
Reference/Expressions/Primaries: "Primaries represent the most tightly
bound operations of the language. Their syntax is:
primary ::= atom | attributeref | subscription | slicing | call"
This (along with the fact that all sections after 'call' doc follow in
order of decreasing precedence) implies to me that atom is highest and
call is lowest of this group. Certainly, attributeref seems higher than
those that follow, as ob.attr[x] and ob.attr(x) are executed as
(ob.attr)[x] and (ob.attr)(x), not as ob.(attr[x]) or ob.(attr(x)) (both
taken literally are syntax errors). (Michael Tobis gave an example today
on c.l.p showing this.)
But the Summary of precedence at the chapter end lists attriburef to
call as low to high. I think these should be reversed.
----------
assignee: georg.brandl
components: Documentation
messages: 71160
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Operator precedence misdocumented
versions: Python 2.5, Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3558>
_______________________________________
From report at bugs.python.org Fri Aug 15 07:34:49 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Aug 2008 05:34:49 +0000
Subject: [New-bugs-announce] [issue3559] Pasted \n not same as typed \n
In-Reply-To: <1218778489.95.0.525643042727.issue3559@psf.upfronthosting.co.za>
Message-ID: <1218778489.95.0.525643042727.issue3559@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
Winxp, 3.0b2, but I suspect earlier as well, since reported on c.l.p.
If I paste '1+2\n' into the command window interpreter, it responds with
'3' and a new prompt. In IDLE, the pasted \n is ignored and a typed \n
is required to trigger execution. As a consequence, pasting multiple
statements does not work; anything after the first is ignored.
If this cannot be changed, following
Paste -- Insert system-wide clipboard into window
with (The shell will only recognize one statement)
would at least document the limitation.
----------
components: IDLE
messages: 71161
nosy: tjreedy
severity: normal
status: open
title: Pasted \n not same as typed \n
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3559>
_______________________________________
From report at bugs.python.org Fri Aug 15 11:37:07 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Aug 2008 09:37:07 +0000
Subject: [New-bugs-announce] [issue3560] redundant "base" field in
memoryview objects
In-Reply-To: <1218793027.62.0.312203864665.issue3560@psf.upfronthosting.co.za>
Message-ID: <1218793027.62.0.312203864665.issue3560@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
PyMemoryViewObject has a "base" field which points to the originator of
the buffer. However, this field has become redundant now that the
Py_buffer struct has received an "obj" field which also points to the
originator of the buffer (this has been done as part of the fix to #3139).
Not removing "base" would make for a confusing and error-prone API.
However, removing it is complicated by the fact that "base" is sometimes
abused to contain a tuple (for PyBUF_SHADOW type buffers, which are
neither mentioned in the PEP nor used anywhere in py3k).
----------
components: Interpreter Core
messages: 71164
nosy: pitrou, teoliphant
priority: critical
severity: normal
status: open
title: redundant "base" field in memoryview objects
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3560>
_______________________________________
From report at bugs.python.org Fri Aug 15 19:17:23 2008
From: report at bugs.python.org (Jason Spiro)
Date: Fri, 15 Aug 2008 17:17:23 +0000
Subject: [New-bugs-announce] [issue3561] Windows installer should add Python
and Scripts directories to the PATH environment variable
In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za>
Message-ID: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za>
New submission from Jason Spiro <jasonspiro4 at gmail.com>:
The Python Windows installer[1] should automatically add the Python and
Scripts directories to the PATH environment variable. (If you like,
you can also provide a checkbox in the installer GUI that users can
uncheck if they don't want this behavior.)
This issue was discussed at http://nabble.com/Why-does-Python-never-add-
itself-to-the-Windows-path--td8044465.html and the majority consensus
was that this is a good idea, but nobody has volunteered to implement
it.
^ [1]. The installer is generated by the code at
http://svn.python.org/view/python/trunk/Tools/msi/
----------
components: Installation, Windows
messages: 71172
nosy: christian.heimes, jasonspiro, loewis
severity: normal
status: open
title: Windows installer should add Python and Scripts directories to the PATH environment variable
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3561>
_______________________________________
From report at bugs.python.org Fri Aug 15 23:08:56 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Aug 2008 21:08:56 +0000
Subject: [New-bugs-announce] [issue3562] Intermitent failure in
test_multiprocessing.test_number_of_objects
In-Reply-To: <1218834536.55.0.521559442827.issue3562@psf.upfronthosting.co.za>
Message-ID: <1218834536.55.0.521559442827.issue3562@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
Just got the following on trunk:
test test_multiprocessing failed -- Traceback (most recent call last):
File "/home/antoine/py3k/memapi/Lib/test/test_multiprocessing.py",
line 1040, in test_number_of_objects
print(self.manager._debug_info())
File "/home/antoine/py3k/memapi/Lib/multiprocessing/managers.py", line
555, in _debug_info
return dispatch(conn, None, 'debug_info')
File "/home/antoine/py3k/memapi/Lib/multiprocessing/managers.py", line
85, in dispatch
raise convert_to_error(kind, result)
multiprocessing.managers.RemoteError:
---------------------------------------------------------------------------
Traceback (most recent call last):
File "/home/antoine/py3k/memapi/Lib/multiprocessing/managers.py", line
187, in handle_request
result = func(c, *args, **kwds)
File "/home/antoine/py3k/memapi/Lib/multiprocessing/managers.py", line
305, in debug_info
keys.sort()
TypeError: unorderable types: str() < int()
---------------------------------------------------------------------------
----------
assignee: jnoller
components: Library (Lib), Tests
messages: 71184
nosy: jnoller, pitrou
priority: high
severity: normal
status: open
title: Intermitent failure in test_multiprocessing.test_number_of_objects
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3562>
_______________________________________
From report at bugs.python.org Sat Aug 16 09:03:08 2008
From: report at bugs.python.org (Ali Polatel)
Date: Sat, 16 Aug 2008 07:03:08 +0000
Subject: [New-bugs-announce] [issue3563] fix_idioms.py generates bad code
In-Reply-To: <1218870188.26.0.589326010093.issue3563@psf.upfronthosting.co.za>
Message-ID: <1218870188.26.0.589326010093.issue3563@psf.upfronthosting.co.za>
New submission from Ali Polatel <hawking at gentoo.org>:
fix_idioms.py generates bad code for conversions in try/except blocks.
Example:
s=(1, 2, 3)
try:
t = list(s)
t.sort()
except TypeError:
pass
fix_idioms.py generates this diff:
--- test.py (original)
+++ test.py (refactored)
@@ -7,8 +7,7 @@
s=(1, 2, 3)
try:
- t = list(s)
- t.sort()
-except TypeError:
+ t = sorted(s)
+ except TypeError:
pass
except TypeError is indented wrongly.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 71199
nosy: collinwinter, hawking
severity: normal
status: open
title: fix_idioms.py generates bad code
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3563>
_______________________________________
From report at bugs.python.org Sat Aug 16 09:05:11 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Sat, 16 Aug 2008 07:05:11 +0000
Subject: [New-bugs-announce] [issue3564] making partial functions comparable
In-Reply-To: <1218870311.31.0.296416489838.issue3564@psf.upfronthosting.co.za>
Message-ID: <1218870311.31.0.296416489838.issue3564@psf.upfronthosting.co.za>
New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:
functools.partial functions are not comparable, in both python 2.5 and
3.0:
>>> def foo(): pass
>>> functools.partial(foo) == functools.partial(foo)
False
It can be worked around by comparing the func, args, and keywords, but
this means that if a partial function is stored in some structure, such
as:
>>> def foo(): pass
>>> f1=functools.partial(foo)
>>> f2=functools.partial(foo)
>>> (1,'a',f1) == (1,'a',f2)
False
Which complicates things when I'm comparing things in a function that
works with generic data structures. Would it be possible to extend
partial to support comparisons?
----------
components: Library (Lib)
messages: 71200
nosy: erickt
severity: normal
status: open
title: making partial functions comparable
type: feature request
versions: Python 2.5, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3564>
_______________________________________
From report at bugs.python.org Sat Aug 16 11:14:13 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sat, 16 Aug 2008 09:14:13 +0000
Subject: [New-bugs-announce] [issue3565] array documentation,
method names not 3.0 compliant
In-Reply-To: <1218878053.61.0.879399084038.issue3565@psf.upfronthosting.co.za>
Message-ID: <1218878053.61.0.879399084038.issue3565@psf.upfronthosting.co.za>
New submission from Matt Giuca <matt.giuca at gmail.com>:
A few weeks ago I fixed the struct module's documentation which wasn't
3.0 compliant (basically renaming "strings" to "bytes" and "unicode" to
"string"). Now I've had a look at the array module, and it's got similar
problems.
http://docs.python.org/dev/3.0/library/array.html
Unfortunately, the method names are wrong as far as Py3K is concerned.
"tostring" returns what is now called a "bytes", and "tounicode" returns
what is now called a "string".
There are a few other errors in the documentation too, like the 'c' type
code (which no longer exists, but is still documented), and examples
using Python 2 syntax. Those are trivial to fix.
I suggest a 3-step process for fixing this:
1. Update the documentation to describe the 3.0 behaviour using 3.0
terminology, even though the method names are wrong (I've done this
already).
2. Rename "tostring" and "fromstring" methods to "tobytes" and
"frombytes". I think this is quite important as the value being returned
can no longer be described as a "string".
3. Rename "tounicode" and "fromunicode" methods to "tostring" and
"fromstring". I think this is less important, as the name "unicode"
isn't ambiguous, and potentially undesirable, as we'd be re-using method
names which previously did something else.
I'm aware we've got the final beta in 4 days, and there's no way my
phase 2-3 can be done after that. I think we should aim to do phase 2,
but probably not phase 3.
I've fixed the documentation to accurately describe the current
behaviour, using Python 3 terminology. This doesn't change any behaviour
at all, so it should be able to be committed immediately.
I'll have a go at a "phase 2" patch shortly. Is it feasible to even
think about renaming a method at this stage?
Commit log:
Doc/library/array.rst, Modules/arrayobject.c:
Updated array module documentation to be Python 3.0 compliant.
* Removed references to 'c' type code (no longer valid).
* References to "string" changed to "bytes".
* References to "unicode" changed to "string".
* Updated examples to use Python 3.0 syntax (and show the output of
evaluating them).
----------
assignee: georg.brandl
components: Documentation, Interpreter Core
files: doc-only.patch
keywords: patch
messages: 71201
nosy: georg.brandl, mgiuca
severity: normal
status: open
title: array documentation, method names not 3.0 compliant
versions: Python 3.0
Added file: http://bugs.python.org/file11121/doc-only.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3565>
_______________________________________
From martin at v.loewis.de Sat Aug 16 11:22:31 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 16 Aug 2008 11:22:31 +0200
Subject: [New-bugs-announce] [issue3565] array documentation,
method names not 3.0 compliant
In-Reply-To: <1218878053.61.0.879399084038.issue3565@psf.upfronthosting.co.za>
References: <1218878053.61.0.879399084038.issue3565@psf.upfronthosting.co.za>
Message-ID: <48A69C57.1050402@v.loewis.de>
> 2. Rename "tostring" and "fromstring" methods to "tobytes" and
> "frombytes". I think this is quite important as the value being returned
> can no longer be described as a "string".
I'm not a native speaker (of English), but my understanding is that the
noun "string", in itself, can very well be used to describe this type:
the result is a "byte string", as opposed to a "character string".
Merriam-Webster's seems to agree; meaning 5b(2) is "a sequence of like
items (as bits, characters, or words)"
From report at bugs.python.org Sat Aug 16 17:41:19 2008
From: report at bugs.python.org (C. Scott Ananian)
Date: Sat, 16 Aug 2008 15:41:19 +0000
Subject: [New-bugs-announce] [issue3566] httplib persistent connections
violate MUST in RFC2616 sec 8.1.4.
In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za>
Message-ID: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za>
New submission from C. Scott Ananian <cscott at cscott.net>:
Although HTTP/1.1 says that servers SHOULD send a Connection: close
header if they intend to close a persistent connection (sec 8.1.2.1),
clients (like httplib) "MUST be able to recover from asynchronous close
events. Client software SHOULD reopen the transport connection and
retransmit the aborted sequence of requests without user interaction so
long as the request sequence is idempotent" (sec 8.1.4) since servers
MAY close a persistent connection after a request due to a timeout or
other reason. Further, "Clients and servers SHOULD both constantly
watch for the other side of the transport close, and respond to it as
appropriate." (sec 8.1.4).
httplib currently does not detect when the server closes its side of the
connection, until the following bit of HTTPResponse in httplib.py
(python2.5.2):
def _read_status(self):
# Initialize with Simple-Response defaults
line = self.fp.readline()
...
if not line:
# Presumably, the server closed the connection before
# sending a valid response.
raise BadStatusLine(line)
...
So we end up raising a BadStatusLine exception for a completely
permissible case: the server closed a persistent connection. This
causes persistent connections to fail for users of httplib in mysterious
ways, especially if they are behind proxies: Squid, for example, seems
to limit persistent connections to a maximum of 3 requests, and then
closes the connection, causing future requests to raise the BadStatusLine.
There appears to be code attempting to fix this problem in
HTTPConnection.request(), but it doesn't always work. RFC793 says, "If
an unsolicited FIN arrives from the network, the receiving TCP can ACK
it and tell the user that the connection is closing. The user will
respond with a CLOSE, upon which the TCP can send a FIN to the other TCP
after sending any remaining data." (sec 3.5 case 2) Key phrase here is
"after sending any remaining data": python is usually allowed to put the
request on the network without raising a socket.error; the close is not
signaled to python until HTTPResponse.begin() invokes
HTTPResponse._read_status.
It would be best to extend the retry logic in request() to cover this
case as well (store away the previous parameters to request() and if
_read_status() fails invoke HTTPConnection.close(),
HTTPConnection.connect(), HTTPConnection.request(stored_params), and
retry the HTTPConnection.getresponse(). But at the very least python
should document and raise a EAGAIN exception of some kind so that the
caller can distinguish this case from an actual bad status line and
retry the request.
----------
components: Library (Lib)
messages: 71221
nosy: cananian
severity: normal
status: open
title: httplib persistent connections violate MUST in RFC2616 sec 8.1.4.
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3566>
_______________________________________
From report at bugs.python.org Sat Aug 16 20:32:48 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Aug 2008 18:32:48 +0000
Subject: [New-bugs-announce] [issue3567] test_ossaudiodev fails when run
with -bb
In-Reply-To: <1218911568.33.0.627988957615.issue3567@psf.upfronthosting.co.za>
Message-ID: <1218911568.33.0.627988957615.issue3567@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
I suppose the sunau module hasn't received a lot ot love lately :-)
test test_ossaudiodev failed -- Traceback (most recent call last):
File "/home/antoine/py3k/__svn__/Lib/test/test_ossaudiodev.py", line
146, in test_playback
sound_info = read_sound_file(findfile('audiotest.au'))
File "/home/antoine/py3k/__svn__/Lib/test/test_ossaudiodev.py", line
27, in read_sound_file
au = sunau.open(fp)
File "/home/antoine/py3k/__svn__/Lib/sunau.py", line 469, in open
return Au_read(f)
File "/home/antoine/py3k/__svn__/Lib/sunau.py", line 158, in __init__
self.initfp(f)
File "/home/antoine/py3k/__svn__/Lib/sunau.py", line 167, in initfp
magic = int(_read_u32(file))
File "/home/antoine/py3k/__svn__/Lib/sunau.py", line 138, in _read_u32
if byte == '':
BytesWarning: Comparison between bytes and string
----------
components: Library (Lib)
messages: 71229
nosy: pitrou
priority: normal
severity: normal
status: open
title: test_ossaudiodev fails when run with -bb
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3567>
_______________________________________
From report at bugs.python.org Sat Aug 16 21:29:17 2008
From: report at bugs.python.org (Jacek)
Date: Sat, 16 Aug 2008 19:29:17 +0000
Subject: [New-bugs-announce] [issue3568] list enumeration corrupt when
remove()
In-Reply-To: <1218914957.69.0.531370039263.issue3568@psf.upfronthosting.co.za>
Message-ID: <1218914957.69.0.531370039263.issue3568@psf.upfronthosting.co.za>
New submission from Jacek <jaworski at autograf.pl>:
Hi
I wrote my first program in python, and I found bug in it.
I explain it in example (I do it under Windows XP):
1. At the begining create some directories:
>mkdir .\test\
>mkdir .\test\.svn
>mkdir .\test\cvs
>mkdir .\test\pdk
2. Next create file ".\bug.py" with content:
import re
import os
print 'example1:'
lpatternDirSkip = re.compile(r'(^cvs$)|(^[.].*)', re.IGNORECASE)
for lroot, ldirs, lfiles in os.walk(r'.\\test\\'):
ldirIndex = 0
for ldirName in ldirs:
if lpatternDirSkip.search(ldirName):
ldirs.remove(ldirName)
print ldirs
print 'example2:'
lpatternDirSkip = re.compile(r'(^cvs$)|(^[.].*)', re.IGNORECASE)
for lroot, ldirs, lfiles in os.walk('.\\test\\'):
ldirIndex = 0
while ldirIndex < len(ldirs):
if lpatternDirSkip.search(ldirs[ldirIndex]):
ldirs.remove(ldirs[ldirIndex])
ldirIndex -= 1
ldirIndex += 1
print ldirs
3. Next run cmd.exe (in the same directory) and type "bug.py". Result is:
example1:
['cvs', 'pdk']
[]
[]
example2:
['pdk']
[]
5. Comment:
In this example I want to remove from list of directories (ldirs) every
hiden directories (like ".svn") and directory "CVS".
Example1 is the comfortable way, but it products wrong result (the "cvs"
directory is not remove). This is only happen when I remove some
directories from the list. I don't care that there was deleted one
element from the list. It should be special case, and enumeration on the
rest elements should be correct.
Example2 works correcty (it's work around of this problem).
Jacek Jaworski
----------
components: Build
messages: 71230
nosy: jacek
severity: normal
status: open
title: list enumeration corrupt when remove()
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3568>
_______________________________________
From report at bugs.python.org Sat Aug 16 22:39:47 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 Aug 2008 20:39:47 +0000
Subject: [New-bugs-announce] [issue3569] Glitch in eval() doc
In-Reply-To: <1218919187.91.0.149398237755.issue3569@psf.upfronthosting.co.za>
Message-ID: <1218919187.91.0.149398237755.issue3569@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
LibRef/built-in functions/eval() has this section
This function can also be used to execute arbitrary code objects (such
as those created by compile()).
In this case pass a code object instead of a string.
The code object must have been compiled passing 'eval' as the kind argument.
As pointed out by Patrick Maupin on py-dev today, the first and third
statements are contradictory: 'arbitrary' != 'limited to kind "eval"'
and the third is wrong in 2.5. It is still wrong in 3.0b2:
>>> eval(compile('1+2', '', 'eval'))
3
>>> eval(compile('1+2', '', 'exec')) # runs and returns None
Because of the first line, I assume this is intended.
Patrick suggests that the third line be expanded to
In order to return a result other than None to eval's caller, the code
object must have been compiled passing 'eval' as the kind argument.
I prefer the slightly more compact
In order for eval to return a result other than None, the code object
must have been compiled passing 'eval' as the kind argument.
or even
However eval will return None unless the code object was compiled with
'eval' as the kind argument.
----------
assignee: georg.brandl
components: Documentation
messages: 71235
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Glitch in eval() doc
versions: Python 2.5, Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3569>
_______________________________________
From report at bugs.python.org Sat Aug 16 23:22:24 2008
From: report at bugs.python.org (Andy Harrington)
Date: Sat, 16 Aug 2008 21:22:24 +0000
Subject: [New-bugs-announce] [issue3570] str.find docstring typo
In-Reply-To: <1218921744.88.0.490515931091.issue3570@psf.upfronthosting.co.za>
Message-ID: <1218921744.88.0.490515931091.issue3570@psf.upfronthosting.co.za>
New submission from Andy Harrington <aharrin at luc.edu>:
When you enter help("".find)
you get
...
such that sub is contained within s[start,end]
...
s[start, end] makes no sense. It should be s[start:end].
----------
assignee: georg.brandl
components: Documentation
messages: 71240
nosy: andyharrington, georg.brandl
severity: normal
status: open
title: str.find docstring typo
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3570>
_______________________________________
From report at bugs.python.org Sat Aug 16 23:37:38 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Aug 2008 21:37:38 +0000
Subject: [New-bugs-announce] [issue3571] test_closerange in test_os can
crash the test suite
In-Reply-To: <1218922658.18.0.0206081400424.issue3571@psf.upfronthosting.co.za>
Message-ID: <1218922658.18.0.0206081400424.issue3571@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
I've been trying to track down the following failure which very recently
has started to plague the py3k buildbots:
[...]
test_os
Traceback (most recent call last):
File "./Lib/test/regrtest.py", line 1197, in <module>
main()
File "./Lib/test/regrtest.py", line 400, in main
print(test)
File
"/home/buildbot/slave/py-build/3.0.norwitz-amd64/build/Lib/io.py", line
1490, in write
self.flush()
File
"/home/buildbot/slave/py-build/3.0.norwitz-amd64/build/Lib/io.py", line
1455, in flush
self.buffer.flush()
File
"/home/buildbot/slave/py-build/3.0.norwitz-amd64/build/Lib/io.py", line
1071, in flush
self._flush_unlocked()
File
"/home/buildbot/slave/py-build/3.0.norwitz-amd64/build/Lib/io.py", line
1079, in _flush_unlocked
n = self.raw.write(self._write_buf)
IOError: [Errno 9] Bad file descriptor
I've determined that the failure in writing to the raw stream underlying
stdout is caused by the fact that the file descriptor 0 has been closed
in test_os.test_closerange:
def test_closerange(self):
f = os.open(support.TESTFN, os.O_CREAT|os.O_RDWR)
# close a fd that is open, and one that isn't
os.closerange(f, f+2)
The problem arises when the call to os.open above returns 0. Normally 0
is the file descriptor underlying stdin, I don't know why it ends up
available for other uses, this would deserve investigation.
In the meantime, a way of circumventing this problem would be to rewrite
test_closerange in a saner way, such that closerange() doesn't try to
close important file descriptors.
----------
components: Tests
messages: 71241
nosy: pitrou
priority: critical
severity: normal
status: open
title: test_closerange in test_os can crash the test suite
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3571>
_______________________________________
From report at bugs.python.org Sun Aug 17 00:20:57 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Aug 2008 22:20:57 +0000
Subject: [New-bugs-announce] [issue3572] with closed file descriptor #2
(stderr), py3k hangs when trying to print an exception
In-Reply-To: <1218925257.81.0.638124043012.issue3572@psf.upfronthosting.co.za>
Message-ID: <1218925257.81.0.638124043012.issue3572@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
Reproducing this bug is simple:
./python -c "import os; os.close(2); 1/0"
----------
components: Interpreter Core
messages: 71244
nosy: pitrou
priority: high
severity: normal
status: open
title: with closed file descriptor #2 (stderr), py3k hangs when trying to print an exception
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3572>
_______________________________________
From report at bugs.python.org Sun Aug 17 01:32:26 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 16 Aug 2008 23:32:26 +0000
Subject: [New-bugs-announce] [issue3573] IDLE hangs when passing invalid
command line args (directory(ies) instead of file(s))
In-Reply-To: <1218929546.33.0.178143371283.issue3573@psf.upfronthosting.co.za>
Message-ID: <1218929546.33.0.178143371283.issue3573@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
Passing a single directory as a command line argument can make IDLE hang.
To achieve this the user needs to configure IDLE to open an editor
window by default.
The attached patch discards filenames that failed to load, so in the end
it may open an empty editor window instead of hanging.
----------
components: Library (Lib)
files: fix_idle_startup_hang.diff
keywords: patch
messages: 71249
nosy: gpolo
severity: normal
status: open
title: IDLE hangs when passing invalid command line args (directory(ies) instead of file(s))
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11129/fix_idle_startup_hang.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3573>
_______________________________________
From report at bugs.python.org Sun Aug 17 02:39:40 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 17 Aug 2008 00:39:40 +0000
Subject: [New-bugs-announce] [issue3574] compile() cannot decode Latin-1
source encodings
In-Reply-To: <1218933580.53.0.0614369271998.issue3574@psf.upfronthosting.co.za>
Message-ID: <1218933580.53.0.0614369271998.issue3574@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
The following leads to a SyntaxError in 3.0:
compile(b'# coding: latin-1\nu = "\xC7"\n', '<dummy>', 'exec')
That is not the case in Python 2.6.
----------
messages: 71251
nosy: brett.cannon
severity: normal
status: open
title: compile() cannot decode Latin-1 source encodings
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3574>
_______________________________________
From report at bugs.python.org Sun Aug 17 11:13:55 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 17 Aug 2008 09:13:55 +0000
Subject: [New-bugs-announce] [issue3575] [py3k] tell() fails in some
situation
In-Reply-To: <1218964435.67.0.36705888367.issue3575@psf.upfronthosting.co.za>
Message-ID: <1218964435.67.0.36705888367.issue3575@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
Hello. I noticed test_mailbox (test_add) fails on my win2k machine.
It's something like this.
======================================================================
ERROR: test_add (__main__.TestMbox)
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_mailbox.py", line 60, in tearDown
self._box.close()
File "e:\python-dev\py3k\lib\mailbox.py", line 642, in close
self.flush()
File "e:\python-dev\py3k\lib\mailbox.py", line 600, in flush
stop - self._file.tell()))
File "e:\python-dev\py3k\lib\io.py", line 1625, in tell
chars_decoded += len(decoder.decode(next_byte))
File "e:\python-dev\py3k\lib\io.py", line 1295, in decode
output = self.decoder.decode(input, final=final)
TypeError: decode() argument 1 must be string or pinned buffer, not
bytearray
And this is simple reproducable code. ("a.txt" contains some text)
f = open("a.txt")
f.read(1)
f.tell() # boom
I searched the place where raises this error in C code,
and I found mbidecoder_decode() is.
if (!PyArg_ParseTupleAndKeywords(args, kwargs, "t#|i:decode",
incrementalkwarglist, &data, &size, &final))
return NULL;
This uses "t#", so cannot accept bytearray, probably.
I hope attached file solves this issue. Thank you.
----------
files: fix_mbidecoder_decode.patch
keywords: patch
messages: 71262
nosy: ocean-city
severity: normal
status: open
title: [py3k] tell() fails in some situation
versions: Python 3.0
Added file: http://bugs.python.org/file11135/fix_mbidecoder_decode.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3575>
_______________________________________
From report at bugs.python.org Sun Aug 17 12:36:27 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 17 Aug 2008 10:36:27 +0000
Subject: [New-bugs-announce] [issue3576] Demo/embed builds against old
version
In-Reply-To: <1218969387.96.0.461430360814.issue3576@psf.upfronthosting.co.za>
Message-ID: <1218969387.96.0.461430360814.issue3576@psf.upfronthosting.co.za>
New submission from Matt Giuca <matt.giuca at gmail.com>:
The Python 2.6 version of Demo/embed/Makefile builds against
libpython2.5.a, which doesn't exist in this version.
Quick patch to let it build against libpython2.6.a.
Commit log:
Fixed Demo/embed/Makefile to build against libpython2.6.a.
----------
components: Build
files: embed.makefile.patch
keywords: patch
messages: 71264
nosy: mgiuca
severity: normal
status: open
title: Demo/embed builds against old version
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file11136/embed.makefile.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3576>
_______________________________________
From report at bugs.python.org Sun Aug 17 14:15:29 2008
From: report at bugs.python.org (John J Lee)
Date: Sun, 17 Aug 2008 12:15:29 +0000
Subject: [New-bugs-announce] [issue3577] Interpreter name: python vs.
python-3.0
In-Reply-To: <1218975329.44.0.7329421423.issue3577@psf.upfronthosting.co.za>
Message-ID: <1218975329.44.0.7329421423.issue3577@psf.upfronthosting.co.za>
New submission from John J Lee <jjlee at users.sourceforge.net>:
The tutorial says:
"The Python interpreter is usually installed as /usr/local/bin/python on
those machines where it is available"
Shouldn't that be "python3" or "python-3.0"? And the same throughout
the rest of the tutorial?
make install seems to think that Python 3 should not be installed as
"python", and should be installed as "python-3.0".
----------
assignee: georg.brandl
components: Documentation
messages: 71268
nosy: georg.brandl, jjlee
severity: normal
status: open
title: Interpreter name: python vs. python-3.0
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3577>
_______________________________________
From report at bugs.python.org Sun Aug 17 15:42:07 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 17 Aug 2008 13:42:07 +0000
Subject: [New-bugs-announce] [issue3578] 'dictionary changed size' error in
test_multiprocessing
In-Reply-To: <1218980527.78.0.883807944764.issue3578@psf.upfronthosting.co.za>
Message-ID: <1218980527.78.0.883807944764.issue3578@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
Here's a report from Ismail Donmez (cartman), extracted from the
issue 3419 discussion in an effort to avoid putting multiple
problems under one tracker issue.
[cartman]
With trunk when running test_multiprocessing in a tight loop I saw
another problem:
test_multiprocessing
Process Process-61:
Traceback (most recent call last):
File "/Users/cartman/Sources/py3k/Lib/multiprocessing/process.py",
line 229, in _bootstrap
Process Process-60:
Traceback (most recent call last):
File "/Users/cartman/Sources/py3k/Lib/multiprocessing/process.py",
line 229, in _bootstrap
Process Process-62:
Traceback (most recent call last):
File "/Users/cartman/Sources/py3k/Lib/multiprocessing/process.py",
line 229, in _bootstrap
util._run_after_forkers()
File "/Users/cartman/Sources/py3k/Lib/multiprocessing/util.py", line
138, in _run_after_forkers
util._run_after_forkers()
File "/Users/cartman/Sources/py3k/Lib/multiprocessing/util.py", line
138, in _run_after_forkers
util._run_after_forkers()
File "/Users/cartman/Sources/py3k/Lib/multiprocessing/util.py", line
138, in _run_after_forkers
items = list(_afterfork_registry.items())
items = list(_afterfork_registry.items())
File "/Users/cartman/Sources/py3k/Lib/weakref.py", line 103, in items
File "/Users/cartman/Sources/py3k/Lib/weakref.py", line 103, in items
items = list(_afterfork_registry.items())
File "/Users/cartman/Sources/py3k/Lib/weakref.py", line 103, in items
for key, wr in self.data.items():
RuntimeError: dictionary changed size during iteration
for key, wr in self.data.items():
RuntimeError: dictionary changed size during iteration
for key, wr in self.data.items():
RuntimeError: dictionary changed size during iteration
----------
assignee: jnoller
components: Extension Modules
messages: 71274
nosy: cartman, jnoller, marketdickinson
severity: normal
status: open
title: 'dictionary changed size' error in test_multiprocessing
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3578>
_______________________________________
From report at bugs.python.org Sun Aug 17 18:51:44 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Aug 2008 16:51:44 +0000
Subject: [New-bugs-announce] [issue3580] failures test_os
In-Reply-To: <1218991904.92.0.339312182303.issue3580@psf.upfronthosting.co.za>
Message-ID: <1218991904.92.0.339312182303.issue3580@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
I get failures under test_os when launched under Windows XP. More
precisely, it's a Windows XP image inside qemu with the Python build dir
in a Samba mount.
======================================================================
FAIL: test_1565150 (__main__.StatAttributeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "Lib\test\test_os.py", line 291, in test_1565150
self.assertEquals(os.stat(self.fname).st_mtime, t1)
AssertionError: 1159195039.0 != 1159195039.25
======================================================================
FAIL: test_1686475 (__main__.StatAttributeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "Lib\test\test_os.py", line 300, in test_1686475
self.fail("Could not stat pagefile.sys")
AssertionError: Could not stat pagefile.sys
----------------------------------------------------------------------
----------
assignee: pitrou
components: Tests
messages: 71282
nosy: pitrou
priority: normal
severity: normal
status: open
title: failures test_os
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3580>
_______________________________________
From report at bugs.python.org Sun Aug 17 18:53:17 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Aug 2008 16:53:17 +0000
Subject: [New-bugs-announce] [issue3581] failures in test_uuid
In-Reply-To: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>
Message-ID: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
I get failures in test_uuid when run inside a qemu virtual machine. It
is related to the fake MAC address used by qemu.
======================================================================
FAIL: test_ipconfig_getnode (__main__.TestUUID)
----------------------------------------------------------------------
Traceback (most recent call last):
File "Lib\test\test_uuid.py", line 326, in test_ipconfig_getnode
self.check_node(node, 'ipconfig')
File "Lib\test\test_uuid.py", line 288, in check_node
self.assertEqual(universal_local_bit, 0, message)
AssertionError: 525400123456 doesn't look like a real MAC address
======================================================================
FAIL: test_windll_getnode (__main__.TestUUID)
----------------------------------------------------------------------
Traceback (most recent call last):
File "Lib\test\test_uuid.py", line 351, in test_windll_getnode
self.check_node(uuid._windll_getnode(), 'windll')
File "Lib\test\test_uuid.py", line 288, in check_node
self.assertEqual(universal_local_bit, 0, message)
AssertionError: 525400123456 doesn't look like a real MAC address
----------------------------------------------------------------------
----------
messages: 71283
nosy: pitrou
severity: normal
status: open
title: failures in test_uuid
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3581>
_______________________________________
From report at bugs.python.org Sun Aug 17 23:00:19 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 17 Aug 2008 21:00:19 +0000
Subject: [New-bugs-announce] [issue3582] thread_nt.c update
In-Reply-To: <1219006819.0.0.701658895964.issue3582@psf.upfronthosting.co.za>
Message-ID: <1219006819.0.0.701658895964.issue3582@psf.upfronthosting.co.za>
New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:
Here is a suggested update to thread_nt.c. It has two significant
changes:
1) it uses the new and safer _beginthreadex API to start a thread
2) it implements native TLS functions on NT, which are certain to be as
fast as possible.
----------
files: thread_nt.patch
keywords: patch, patch
messages: 71289
nosy: krisvale
severity: normal
status: open
title: thread_nt.c update
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file11141/thread_nt.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3582>
_______________________________________
From report at bugs.python.org Sun Aug 17 23:21:01 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 17 Aug 2008 21:21:01 +0000
Subject: [New-bugs-announce] [issue3583] test_urllibnet.test_bad_address()
fails when using OpenDNS
In-Reply-To: <1219008061.86.0.538682955954.issue3583@psf.upfronthosting.co.za>
Message-ID: <1219008061.86.0.538682955954.issue3583@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
OpenDNS has a "feature" where if you enter an address that doesn't
exist, you get a 404 and a Google-looking search page. Problem is that
urllib.urlopen() does not raise any exception on a 404.
Probably should just change the test such that if no exception is
raised, check if a 404 was returned and still consider the test passed.
----------
components: Library (Lib)
messages: 71292
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: test_urllibnet.test_bad_address() fails when using OpenDNS
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3583>
_______________________________________
From report at bugs.python.org Mon Aug 18 01:34:29 2008
From: report at bugs.python.org (Jim Hermann)
Date: Sun, 17 Aug 2008 23:34:29 +0000
Subject: [New-bugs-announce] [issue3584] Exception for test_urllib2_localnet
In-Reply-To: <1219016069.28.0.247374147192.issue3584@psf.upfronthosting.co.za>
Message-ID: <1219016069.28.0.247374147192.issue3584@psf.upfronthosting.co.za>
New submission from Jim Hermann <python at jimhermann.com>:
When I installed Python 2.5.2 on my Fedora Core 4 system, I ran 'make
test" and the process stopped at this point:
test_urllib2_localnet
Exception in thread Thread-1067:
Traceback (most recent call last):
File "/usr/local/src/Python-2.5.2/Lib/threading.py", line 486, in
__bootstrap_inner
self.run()
File "/usr/local/src/Python-2.5.2/Lib/test/test_urllib2_localnet.py",
line 64, in run
self._RequestHandlerClass)
File "/usr/local/src/Python-2.5.2/Lib/test/test_urllib2_localnet.py",
line 22, in __init__
RequestHandlerClass)
File "/usr/local/src/Python-2.5.2/Lib/SocketServer.py", line 330, in
__init__
self.server_bind()
File "/usr/local/src/Python-2.5.2/Lib/BaseHTTPServer.py", line 101, in
server_bind
SocketServer.TCPServer.server_bind(self)
File "/usr/local/src/Python-2.5.2/Lib/SocketServer.py", line 341, in
server_bind
self.socket.bind(self.server_address)
File "<string>", line 1, in bind
error: (98, 'Address already in use')
Thanks.
Jim
----------
components: Tests
messages: 71300
nosy: jimhermann
severity: normal
status: open
title: Exception for test_urllib2_localnet
type: crash
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3584>
_______________________________________
From report at bugs.python.org Mon Aug 18 03:03:29 2008
From: report at bugs.python.org (Clinton Roy)
Date: Mon, 18 Aug 2008 01:03:29 +0000
Subject: [New-bugs-announce] [issue3585] pkg-config support
In-Reply-To: <1219021409.35.0.10935334414.issue3585@psf.upfronthosting.co.za>
Message-ID: <1219021409.35.0.10935334414.issue3585@psf.upfronthosting.co.za>
New submission from Clinton Roy <clinton.roy at gmail.com>:
This patch adds pkg-config support to the python build, a python.pc file
is installed in the pkgconfig directory such that autoconf buildsystems
can trivially link against the python library.
Diff made against revision 65796
----------
components: Build
files: pkgconfig.diff
keywords: patch
messages: 71305
nosy: ClintonRoy
severity: normal
status: open
title: pkg-config support
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file11142/pkgconfig.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3585>
_______________________________________
From report at bugs.python.org Mon Aug 18 12:22:44 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 18 Aug 2008 10:22:44 +0000
Subject: [New-bugs-announce] [issue3586] pwd.getpwnam('nobody') produces
incorrect results if sizeof(uid_t) < sizeof(long)
In-Reply-To: <1219054964.79.0.647831105855.issue3586@psf.upfronthosting.co.za>
Message-ID: <1219054964.79.0.647831105855.issue3586@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
On a 64-bit OS X build of Python, built with:
./configure --with-universal-archs=64-bit --enable-universalsdk=/ MACOSX_DEPLOYMENT_TARGET=10.5 &&
make
I get the following result:
Python 2.6b2+ (trunk:65805M, Aug 18 2008, 10:59:08)
[GCC 4.0.1 (Apple Inc. build 5484)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pwd
>>> pwd.getpwnam('nobody')
pwd.struct_passwd(pw_name='nobody', pw_passwd='*', pw_uid=4294967294, pw_gid=4294967294,
pw_gecos='Unprivileged User', pw_dir='/var/empty', pw_shell='/usr/bin/false')
Here the pw_uid and pw_gid should presumably be -2, not 4294967294. I haven't had time to
investigate properly, but the problem is almost certainly something to do with the fact that
sizeof(uid_t) is 4 and sizeof(long) is 8 for this build. (Though interestingly, the configure
script detects sizeof(long) as 4, which may not be helping matters.)
This problem is causing test_httpservers to fail on 64-bit OS X.
System info: it's a MacBook Pro; uname -a gives:
Darwin Macintosh-3.local 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun 9 19:30:53 PDT 2008; root:xnu-
1228.5.20~1/RELEASE_I386 i386
----------
components: Extension Modules
messages: 71318
nosy: marketdickinson
severity: normal
status: open
title: pwd.getpwnam('nobody') produces incorrect results if sizeof(uid_t) < sizeof(long)
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3586>
_______________________________________
From report at bugs.python.org Mon Aug 18 14:02:23 2008
From: report at bugs.python.org (Misha Seltzer)
Date: Mon, 18 Aug 2008 12:02:23 +0000
Subject: [New-bugs-announce] [issue3587] Bad parsing of compiling regex with
re.MULTILINE
In-Reply-To: <1219060943.01.0.111673832239.issue3587@psf.upfronthosting.co.za>
Message-ID: <1219060943.01.0.111673832239.issue3587@psf.upfronthosting.co.za>
New submission from Misha Seltzer <misha at seltzer.com>:
import re
regex = r"[\w]+"
# Normal behaviour:
>>> re.findall(regex, "hello world", re.M)
['hello', 'world']
>>> re.compile(regex).findall("hello world")
['hello', 'world']
# Bug behaviour:
>>> re.compile(regex).findall("hello world", re.M)
['rld']
----------
components: Regular Expressions
messages: 71323
nosy: misha
severity: normal
status: open
title: Bad parsing of compiling regex with re.MULTILINE
type: behavior
versions: Python 2.4, Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3587>
_______________________________________
From report at bugs.python.org Mon Aug 18 15:01:36 2008
From: report at bugs.python.org (Konrad Hinsen)
Date: Mon, 18 Aug 2008 13:01:36 +0000
Subject: [New-bugs-announce] [issue3588] sysconfig variable LINKFORSHARED
has wrong value for MacOS X framework build
In-Reply-To: <1219064496.5.0.0710172743091.issue3588@psf.upfronthosting.co.za>
Message-ID: <1219064496.5.0.0710172743091.issue3588@psf.upfronthosting.co.za>
New submission from Konrad Hinsen <konrad.hinsen at laposte.net>:
On a MacOS X framework build, the LINKFORSHARED variable obtained from
distutils.sysconfig.get_config_vars() has the value
-u _PyMac_Error Python.framework/Versions/2.5/Python
The last item is incomplete, it needs to be prefixed with the path in
which the Python framework is installed.
Looking at config/Makefile (from which Distutils takes the variables), I
find
LINKFORSHARED= -u _PyMac_Error
$(PYTHONFRAMEWORKDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK)
and
PYTHONFRAMEWORKDIR= Python.framework
One fix would be to use PYTHONFRAMEWORKINSTALLDIR instead of PYTHONFRAMEWORKDIR in the definition of LINKFORSHARED, but I don't know
if this could have undesirable effects on the build process.
----------
components: Distutils
messages: 71324
nosy: khinsen
severity: normal
status: open
title: sysconfig variable LINKFORSHARED has wrong value for MacOS X framework build
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3588>
_______________________________________
From report at bugs.python.org Mon Aug 18 15:27:25 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 18 Aug 2008 13:27:25 +0000
Subject: [New-bugs-announce] [issue3589] Misleading names for
multiprocessing "convenience" functions
In-Reply-To: <1219066045.43.0.199498522059.issue3589@psf.upfronthosting.co.za>
Message-ID: <1219066045.43.0.199498522059.issue3589@psf.upfronthosting.co.za>
New submission from Nick Coghlan <ncoghlan at gmail.com>:
The package level imports from the new multiprocessing package exhibit
some very strange behaviour because they are actually functions
pretending to be classes:
Python 2.6b1+ (trunk:64945, Jul 14 2008, 20:00:46)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing as mp
>>> isinstance(mp.Lock(), mp.Lock)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: isinstance() arg 2 must be a class, type, or tuple of classes
and types
>>> mp.Lock.__name__
'Lock'
>>> mp.Lock.__module__
'multiprocessing'
>>> mp.Lock().__class__.__name__
'Lock'
>>> mp.Lock().__class__.__module__
'multiprocessing.synchronize'
The delayed import functions in multiprocessing.__init__ look like a
serious misfeature to me. I'd be inclined to replace them with "from
.synchronize import *" and "from .process import *" (leaving anything
which isn't covered by those two imports to be retrieved directly from
the relevant mp submodule)
----------
assignee: jnoller
components: Library (Lib)
messages: 71327
nosy: jnoller, ncoghlan
priority: critical
severity: normal
status: open
title: Misleading names for multiprocessing "convenience" functions
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3589>
_______________________________________
From report at bugs.python.org Mon Aug 18 17:06:15 2008
From: report at bugs.python.org (Edward K Ream)
Date: Mon, 18 Aug 2008 15:06:15 +0000
Subject: [New-bugs-announce] [issue3590] sax.parser hangs on byte streams
In-Reply-To: <1219071975.28.0.899711064426.issue3590@psf.upfronthosting.co.za>
Message-ID: <1219071975.28.0.899711064426.issue3590@psf.upfronthosting.co.za>
New submission from Edward K Ream <edreamleo at gmail.com>:
While porting Leo to Python 3.0, I found that passing any byte stream to
xml.sax.parser.parse will hang the parser. My quick fix was to change:
while buffer != "":
to:
while buffer != "" and buffer != b"":
at line 123 of xmlreader.py
Here is the entire function:
def parse(self, source):
from . import saxutils
source = saxutils.prepare_input_source(source)
self.prepareParser(source)
file = source.getByteStream()
buffer = file.read(self._bufsize)
### while buffer != "":
while buffer != "" and buffer != b"": ### EKR
self.feed(buffer)
buffer = file.read(self._bufsize)
self.close()
For reference, here is the code in Leo that was hanging::
parser = xml.sax.make_parser()
parser.setFeature(xml.sax.handler.feature_external_ges,1)
handler = saxContentHandler(c,inputFileName,silent,inClipboard)
parser.setContentHandler(handler)
parser.parse(theFile)
Looking at the test_expat_file function in test_sax.py, it appears that
the essential difference between the code that hangs and the successful
unit test is that that Leo opens the file in 'rb' mode. (code not shown)
It's doubtful that 'rb' mode is correct--from the unit test I deduce
that the default 'r' mode would be better. Anyway, it would be nice if
parser.parse didn't hang on dubious streams.
HTH.
Edward
----------
components: Library (Lib)
messages: 71339
nosy: edreamleo
severity: normal
status: open
title: sax.parser hangs on byte streams
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3590>
_______________________________________
From report at bugs.python.org Mon Aug 18 18:57:49 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Aug 2008 16:57:49 +0000
Subject: [New-bugs-announce] [issue3591] elementtree tests do not include
bytes handling
In-Reply-To: <1219078669.04.0.473516144349.issue3591@psf.upfronthosting.co.za>
Message-ID: <1219078669.04.0.473516144349.issue3591@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
In py3k, there should be explicit tests for byte string input (in
addition to unicode input) to elementtree's parser, including non-UTF8
encodings and non-ASCII chars.
----------
components: Tests, XML
messages: 71351
nosy: effbot, pitrou
priority: normal
severity: normal
status: open
title: elementtree tests do not include bytes handling
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3591>
_______________________________________
From report at bugs.python.org Mon Aug 18 23:13:52 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 18 Aug 2008 21:13:52 +0000
Subject: [New-bugs-announce] [issue3592] Patch to add imp.get_codingspec()
In-Reply-To: <1219094032.27.0.00275483545794.issue3592@psf.upfronthosting.co.za>
Message-ID: <1219094032.27.0.00275483545794.issue3592@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Attached is a patch to add imp.get_codingspec(); a function that returns
the encoding of a source file.
The motivation is to remove the import of the re module in linecache to
speed up interpreter startup.
----------
components: Library (Lib)
files: reviewed_get_encodingspec.diff
keywords: patch, patch
messages: 71379
nosy: brett.cannon, christian.heimes
priority: low
severity: normal
status: open
title: Patch to add imp.get_codingspec()
type: feature request
versions: Python 3.1
Added file: http://bugs.python.org/file11149/reviewed_get_encodingspec.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3592>
_______________________________________
From report at bugs.python.org Mon Aug 18 23:30:28 2008
From: report at bugs.python.org (Miki Tebeka)
Date: Mon, 18 Aug 2008 21:30:28 +0000
Subject: [New-bugs-announce] [issue3593] subprocess + stdout redirection +
wait + svn= hang
In-Reply-To: <1219095028.86.0.31629994109.issue3593@psf.upfronthosting.co.za>
Message-ID: <1219095028.86.0.31629994109.issue3593@psf.upfronthosting.co.za>
New submission from Miki Tebeka <miki.tebeka at gmail.com>:
The attached script hangs on Ubuntu + Python 2.5.2.
When make the limit smaller (like 10) or not redirecting stdout, it works.
Running the svn command from shell took about 4sec, I gave up on the
script after a minute.
I tried it both with svn 1.4.6 and 1.5.1 - no change.
----------
components: Library (Lib)
files: svnout.py
messages: 71385
nosy: tebeka
severity: normal
status: open
title: subprocess + stdout redirection + wait + svn= hang
versions: Python 2.6
Added file: http://bugs.python.org/file11150/svnout.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3593>
_______________________________________
From report at bugs.python.org Tue Aug 19 03:19:39 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Aug 2008 01:19:39 +0000
Subject: [New-bugs-announce] [issue3594] PyTokenizer_FindEncoding() never
succeeds
In-Reply-To: <1219108779.12.0.628146919019.issue3594@psf.upfronthosting.co.za>
Message-ID: <1219108779.12.0.628146919019.issue3594@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Turns out that PyTokenizer_FindEncoding() never properly succeeds
because the tok_state used by it does not have tok->filename set, which
is an error condition in the tokenizer. This error has been masked by
the one place the function is used, imp.find_module() because a NULL
return is never checked for an error, but instead just assumes the
default source encoding suffices.
----------
components: Extension Modules
messages: 71397
nosy: brett.cannon, christian.heimes
priority: critical
severity: normal
status: open
title: PyTokenizer_FindEncoding() never succeeds
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3594>
_______________________________________
From report at bugs.python.org Tue Aug 19 04:24:45 2008
From: report at bugs.python.org (Ahir Reddy)
Date: Tue, 19 Aug 2008 02:24:45 +0000
Subject: [New-bugs-announce] [issue3595] Windows base64 Decode
In-Reply-To: <1219112685.57.0.506715853146.issue3595@psf.upfronthosting.co.za>
Message-ID: <1219112685.57.0.506715853146.issue3595@psf.upfronthosting.co.za>
New submission from Ahir Reddy <ahirreddy at gmail.com>:
I'm new to this and not quite sure how to go about posting an issue, but
I will do the best I can. In Python 2.5.2, both from python.org and
active state, all methods of decoding in base64 under Windows produce
different output than base64 decoding under UNIX (I've tested it both on
OS X and Linux, which produce the same results). I ran into this while
writing a script that downloads email and parses mime attachments which
are base64 encoded by a similar upload script. UNIX systems are able to
download the attachments and decode the base64 back to the original
attachments correctly, which I've verified with md5sum hashes. The same
script under windows produces an incorrect file. At first I was not sure
what the issue was, and I eventually wrote the raw base64 attachment to
a file. I then used a windows command line tool to decode the file and
it produced the correct output (again checked by md5sum). This leads me
to believe that something is strange with base64 under Windows. I hope
my explanation has helped some. If need be I'll upload the script so
others can replicate my results.
Ahir
----------
components: Library (Lib)
messages: 71400
nosy: ahirreddy
severity: normal
status: open
title: Windows base64 Decode
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3595>
_______________________________________
From report at bugs.python.org Tue Aug 19 05:06:16 2008
From: report at bugs.python.org (Heikki Toivonen)
Date: Tue, 19 Aug 2008 03:06:16 +0000
Subject: [New-bugs-announce] [issue3596] Provide a way to disable SSLv2 (or
better yet, disable by default)
In-Reply-To: <1219115176.99.0.339604404005.issue3596@psf.upfronthosting.co.za>
Message-ID: <1219115176.99.0.339604404005.issue3596@psf.upfronthosting.co.za>
New submission from Heikki Toivonen <hjtoi-bugzilla at comcast.net>:
There should be a way to disable SSLv2 since it is insecure. It would be
even better if SSLv2 was disabled out of the box, but maybe there could
be a way to re-enable it.
I made the default to disable SSLv2 in M2Crypto, but those that want it
can explicitly request unsecure connection. You can take a look at
http://svn.osafoundation.org/m2crypto/trunk/M2Crypto/SSL/Context.py to
see how I did it.
Modern web browsers are also removing SSLv2 support from them, so it
should be really rare to actually need v2 anywhere.
----------
components: Library (Lib)
messages: 71404
nosy: heikki
severity: normal
status: open
title: Provide a way to disable SSLv2 (or better yet, disable by default)
type: security
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3596>
_______________________________________
From report at bugs.python.org Tue Aug 19 05:38:11 2008
From: report at bugs.python.org (Heikki Toivonen)
Date: Tue, 19 Aug 2008 03:38:11 +0000
Subject: [New-bugs-announce] [issue3597] Allow application developers to
select ciphers, and default to strong in ssl lib
In-Reply-To: <1219117091.2.0.876896713341.issue3597@psf.upfronthosting.co.za>
Message-ID: <1219117091.2.0.876896713341.issue3597@psf.upfronthosting.co.za>
New submission from Heikki Toivonen <hjtoi-bugzilla at comcast.net>:
The 2.6 documentation states selecting the most compatible SSLv23 mode
may mean low quality ciphers, which does not really help the application
developers. It would be better to provide a way to set the allowed
ciphers. Even better, IMO, would be if the ssl module would default to
the stronger ciphers. I use the following default in M2Crypto:
set_cipher_list('ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH').
----------
components: Library (Lib)
messages: 71406
nosy: heikki
severity: normal
status: open
title: Allow application developers to select ciphers, and default to strong in ssl lib
type: security
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3597>
_______________________________________
From report at bugs.python.org Tue Aug 19 08:50:57 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 19 Aug 2008 06:50:57 +0000
Subject: [New-bugs-announce] [issue3598] multiprocessing.Pool windows/linux
behaviour difference
In-Reply-To: <1219128657.72.0.0468830015115.issue3598@psf.upfronthosting.co.za>
Message-ID: <1219128657.72.0.0468830015115.issue3598@psf.upfronthosting.co.za>
New submission from Mark Summerfield <mark at qtrac.eu>:
When the attached program is run on Linux it runs "instantly" and
outputs one line, e.g.:
$ python3 mtest.py
100 files, 1702627142 bytes
(The number of bytes will vary depending on the system.)
When run on Windows XP there is no output at all; many processes seem to
be created but nothing seems to actually get done.
In both cases I'm using Py30b2.
----------
components: Library (Lib)
files: mtest.py
messages: 71408
nosy: mark
severity: normal
status: open
title: multiprocessing.Pool windows/linux behaviour difference
versions: Python 3.0
Added file: http://bugs.python.org/file11154/mtest.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3598>
_______________________________________
From report at bugs.python.org Tue Aug 19 16:48:35 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Aug 2008 14:48:35 +0000
Subject: [New-bugs-announce] [issue3599] test_pydoc after test_urllib2
causes exception in Popen.__del__
In-Reply-To: <1219157315.63.0.32622319144.issue3599@psf.upfronthosting.co.za>
Message-ID: <1219157315.63.0.32622319144.issue3599@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
./python.exe Lib/test/regrtest.py -uall -f ../trunk/tests.txt
test_urllib2
test_pydoc
All 2 tests OK.
Exception TypeError: TypeError("'NoneType' object is not callable",) in
<bound method Popen.__del__ of <subprocess.Popen object at 0x15ffd10>>
ignored
----------
components: Tests
messages: 71422
nosy: benjamin.peterson
priority: high
severity: normal
status: open
title: test_pydoc after test_urllib2 causes exception in Popen.__del__
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3599>
_______________________________________
From report at bugs.python.org Tue Aug 19 17:37:28 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 19 Aug 2008 15:37:28 +0000
Subject: [New-bugs-announce] [issue3600] Include Tcl/Tk 8.5.4 in the windows
binary for the upcoming beta3
In-Reply-To: <1219160248.58.0.797023815673.issue3600@psf.upfronthosting.co.za>
Message-ID: <1219160248.58.0.797023815673.issue3600@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
May I suggest the inclusion of Tcl/Tk 8.5.4 in the windows binary for
the upcoming beta3 ? beta2 included 8.5.3, but now the 8.5.4 bugfix
release arrived.
----------
components: Windows
messages: 71427
nosy: gpolo
severity: normal
status: open
title: Include Tcl/Tk 8.5.4 in the windows binary for the upcoming beta3
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3600>
_______________________________________
From report at bugs.python.org Tue Aug 19 17:42:05 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Aug 2008 15:42:05 +0000
Subject: [New-bugs-announce] [issue3601] test_unicode.test_raiseMemError
fails in UCS4
In-Reply-To: <1219160525.52.0.218582324378.issue3601@psf.upfronthosting.co.za>
Message-ID: <1219160525.52.0.218582324378.issue3601@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
======================================================================
ERROR: test_raiseMemError (test.test_unicode.UnicodeTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/temp/python/trunk/Lib/test/test_unicode.py", line 1122, in
test_raiseMemError
self.assertRaises(MemoryError, alloc)
File "/temp/python/trunk/Lib/unittest.py", line 336, in failUnlessRaises
callableObj(*args, **kwargs)
File "/temp/python/trunk/Lib/test/test_unicode.py", line 1121, in <lambda>
alloc = lambda: u"a" * (sys.maxsize - 100)
OverflowError: repeated string is too long
----------------------------------------------------------------------
----------
assignee: pitrou
messages: 71429
nosy: benjamin.peterson, pitrou
priority: critical
severity: normal
status: open
title: test_unicode.test_raiseMemError fails in UCS4
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3601>
_______________________________________
From report at bugs.python.org Tue Aug 19 20:35:47 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Aug 2008 18:35:47 +0000
Subject: [New-bugs-announce] [issue3602] Move
test.test_suport.catch_warning() to the 'warnings' module
In-Reply-To: <1219170947.01.0.817487779131.issue3602@psf.upfronthosting.co.za>
Message-ID: <1219170947.01.0.817487779131.issue3602@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Since most UNIX distros don't ship Python's test directory,
test.test_support.catch_warning() needs to be moved to the 'warnings'
directory so it can be used to suppress warnings in modules outside the
'test' package.
The default for 'record' will change to False so it is less
test-oriented. The name might change as well since it is more about
saving the state of 'warnings' then actually catching an exception,
although having it return an object representation of a warning makes
the current name make sense.
----------
assignee: brett.cannon
components: Library (Lib)
messages: 71459
nosy: brett.cannon
priority: critical
severity: normal
status: open
title: Move test.test_suport.catch_warning() to the 'warnings' module
type: behavior
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3602>
_______________________________________
From report at bugs.python.org Tue Aug 19 21:11:05 2008
From: report at bugs.python.org (Santiago Gala)
Date: Tue, 19 Aug 2008 19:11:05 +0000
Subject: [New-bugs-announce] [issue3603] trivial typo in Include/pymath.h
In-Reply-To: <1219173065.49.0.835954949015.issue3603@psf.upfronthosting.co.za>
Message-ID: <1219173065.49.0.835954949015.issue3603@psf.upfronthosting.co.za>
New submission from Santiago Gala <sgala at apache.org>:
file Include/pymath.h has the typo s/doube/double/, hidden by the fact
that any sane OS defines copysign:
diff --git a/Include/pymath.h b/Include/pymath.h
index a3735c2..7cea9ae 100644
--- a/Include/pymath.h
+++ b/Include/pymath.h
@@ -19,7 +19,7 @@ functions and constants
*Note: PC/pyconfig.h defines copysign as _copysign
*/
#ifndef HAVE_COPYSIGN
-extern double copysign(doube, double);
+extern double copysign(double, double);
#endif
#ifndef HAVE_ACOSH
It is both in trunk and py3k
----------
messages: 71465
nosy: sgala
severity: normal
status: open
title: trivial typo in Include/pymath.h
type: compile error
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3603>
_______________________________________
From report at bugs.python.org Tue Aug 19 21:46:18 2008
From: report at bugs.python.org (Matt Beaumont-Gay)
Date: Tue, 19 Aug 2008 19:46:18 +0000
Subject: [New-bugs-announce] [issue3604] broken link in curses module docs
In-Reply-To: <1219175178.82.0.559397561246.issue3604@psf.upfronthosting.co.za>
Message-ID: <1219175178.82.0.559397561246.issue3604@psf.upfronthosting.co.za>
New submission from Matt Beaumont-Gay <mattb at cs.ucla.edu>:
The link to the "Curses Programming with Python" page on the curses
module doc page (http://www.python.org/doc/lib/module-curses.html) is
broken; the correct link is apparently
'http://docs.python.org/dev/howto/curses.html'.
----------
assignee: georg.brandl
components: Documentation
messages: 71472
nosy: georg.brandl, mattb
severity: normal
status: open
title: broken link in curses module docs
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3604>
_______________________________________
From report at bugs.python.org Tue Aug 19 22:42:18 2008
From: report at bugs.python.org (Roger Upole)
Date: Tue, 19 Aug 2008 20:42:18 +0000
Subject: [New-bugs-announce] [issue3605] Py_FatalError causes infinite loop
In-Reply-To: <1219178538.87.0.507520309186.issue3605@psf.upfronthosting.co.za>
Message-ID: <1219178538.87.0.507520309186.issue3605@psf.upfronthosting.co.za>
New submission from Roger Upole <rupole at hotmail.com>:
Py_FatalError calls PyErr_Occurred() which requires a current thread
state. This mean that if the original error was a thread state error
Py_FatalError is triggered again, ad infinitum.
----------
components: Interpreter Core
messages: 71478
nosy: rupole
severity: normal
status: open
title: Py_FatalError causes infinite loop
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3605>
_______________________________________
From report at bugs.python.org Wed Aug 20 00:05:41 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Aug 2008 22:05:41 +0000
Subject: [New-bugs-announce] [issue3606] 2to3: commands varible replaced by
subprocess
In-Reply-To: <1219183541.38.0.933947202959.issue3606@psf.upfronthosting.co.za>
Message-ID: <1219183541.38.0.933947202959.issue3606@psf.upfronthosting.co.za>
New submission from STINNER Victor <haypo at users.sourceforge.net>:
I tried 2to3 on my python-ptrace project and with minor changes, it
works fine. One of the minor changes is to replace
subprocess.split(";") by commands.split(";"). The original code was:
commands = command
ok = True
for command in commands.split(";"):
command = command.strip()
ok &= self.execute(command)
I don't import subprocess and I don't use this module in my code. It
is possible to reproduce the bug only with two lines:
commands = "a;b;c"
x = commands.split(";")
So 2to3 doesn't care if commands is a module or variable, it just
replaced the text pattern... It looks like the change is done
by "fixes/fix_imports.py", maybe this pattern:
# Find usages of module members in code e.g. urllib.foo(bar)
yield """power< (%s)
trailer<'.' any > any* >
""" % mod_name_list
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 71490
nosy: collinwinter, haypo
severity: normal
status: open
title: 2to3: commands varible replaced by subprocess
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3606>
_______________________________________
From report at bugs.python.org Wed Aug 20 00:08:00 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Aug 2008 22:08:00 +0000
Subject: [New-bugs-announce] [issue3607] test_multiprocessing failure
(Unserializable message)
In-Reply-To: <1219183680.84.0.240976772511.issue3607@psf.upfronthosting.co.za>
Message-ID: <1219183680.84.0.240976772511.issue3607@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
I have the following deterministic failure on py3k:
test test_multiprocessing failed -- Traceback (most recent call last):
File "/home/antoine/py3k/__svn__/Lib/test/test_multiprocessing.py",
line 932, in test_dict
self.assertEqual(sorted(d.keys()), indices)
File "<string>", line 2, in keys
File "/home/antoine/py3k/__svn__/Lib/multiprocessing/managers.py",
line 738, in _callmethod
raise convert_to_error(kind, result)
multiprocessing.managers.RemoteError:
---------------------------------------------------------------------------
Unserializable message: ('#RETURN', <dict_keys object at 0x956ddb0>)
---------------------------------------------------------------------------
----------
assignee: jnoller
components: Library (Lib), Tests
messages: 71492
nosy: jnoller, pitrou
priority: critical
severity: normal
status: open
title: test_multiprocessing failure (Unserializable message)
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3607>
_______________________________________
From report at bugs.python.org Wed Aug 20 00:50:39 2008
From: report at bugs.python.org (Roger Upole)
Date: Tue, 19 Aug 2008 22:50:39 +0000
Subject: [New-bugs-announce] [issue3608] memoryview constructor has no
deallocator
In-Reply-To: <1219186239.27.0.516821193842.issue3608@psf.upfronthosting.co.za>
Message-ID: <1219186239.27.0.516821193842.issue3608@psf.upfronthosting.co.za>
New submission from Roger Upole <rupole at hotmail.com>:
When using PyMemoryView_FromMemory to create a new object, you have to
pass in a preallocated buffer. However, there's no way to specify a
routine to free the memory, and it leaks when the object is destroyed.
----------
components: Interpreter Core
messages: 71495
nosy: rupole
severity: normal
status: open
title: memoryview constructor has no deallocator
type: resource usage
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3608>
_______________________________________
From report at bugs.python.org Wed Aug 20 02:51:17 2008
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 20 Aug 2008 00:51:17 +0000
Subject: [New-bugs-announce] [issue3609] does parse_header really belong in
CGI module?
In-Reply-To: <1219193477.24.0.768590998992.issue3609@psf.upfronthosting.co.za>
Message-ID: <1219193477.24.0.768590998992.issue3609@psf.upfronthosting.co.za>
New submission from Bill Janssen <bill.janssen at gmail.com>:
Not sure how to class this, but shouldn't the "parse_header" function in
cgi really be in email.header? And what about parse_multipart?
----------
components: Library (Lib)
messages: 71500
nosy: janssen
priority: normal
severity: normal
status: open
title: does parse_header really belong in CGI module?
type: feature request
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3609>
_______________________________________
From report at bugs.python.org Wed Aug 20 03:08:18 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Aug 2008 01:08:18 +0000
Subject: [New-bugs-announce] [issue3610] Fix gdbinit for Python 3.0
In-Reply-To: <1219194498.13.0.487280154525.issue3610@psf.upfronthosting.co.za>
Message-ID: <1219194498.13.0.487280154525.issue3610@psf.upfronthosting.co.za>
New submission from STINNER Victor <haypo at users.sourceforge.net>:
I'm trying to track down a bug in Python 3.0 (or my program?). I fixed
some functions of gdbinit:
- pystack and pylocals: use the new function py_printstr
- lineno: call CPython "PyCode_Addr2Line" instead of ugly gdb
reimplementation
New functions:
- py_decref: decrement the reference counter and *always* call
_Py_Dealloc(obj)
- py_printstr: display a string as UTF-8 using printf "%s" and
PyUnicodeUCS2_AsUTF8String()
Problem: PyUnicode_AsUTF8String() is unknown, so I have to use
PyUnicodeUCS2_AsUTF8String... (but it can be UCS4)
I'm unable to test pylocals, I don't know the good context to test it.
In PyEval_EvalFrameEx if fails because "f" is unknown but pystack
works and pystack calls lineno which uses "f" !?
----------
components: None
files: gdbinit.patch
keywords: patch
messages: 71501
nosy: haypo
severity: normal
status: open
title: Fix gdbinit for Python 3.0
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file11167/gdbinit.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3610>
_______________________________________
From report at bugs.python.org Wed Aug 20 04:33:20 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Aug 2008 02:33:20 +0000
Subject: [New-bugs-announce] [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
New submission from STINNER Victor <haypo at users.sourceforge.net>:
After few seconds (30 sec to 5 minutes), my program (Fusil) crashs at:
PyEval_EvalFrameEx (f=0x85b4324, throwflag=0) at Python/ceval.c:2459
Py_CLEAR(tstate->exc_traceback);
It crashs because tstate->exc_traceback points to a zombi object:
{_ob_next = 0xdbdbdbdb, _ob_prev = 0xdbdbdbdb, ob_refcnt = -606348326,
ob_type = 0xdbdbdbdb}
(refcnt is 0xdbdbdbdb-1)
I'm using py3k rev 65882 compiled with CFLAGS "-O0 -ggdb"
and --with-pydebug. Sorry, I don't have more informations yet and I
can't explain how to reproduce the bug :-/
----------
components: Interpreter Core
messages: 71503
nosy: haypo
severity: normal
status: open
title: invalid exception context
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________
From report at bugs.python.org Wed Aug 20 07:03:52 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 20 Aug 2008 05:03:52 +0000
Subject: [New-bugs-announce] [issue3612] Add some basic mssing types in
ctypes.wintypes
In-Reply-To: <1219208632.69.0.435134240035.issue3612@psf.upfronthosting.co.za>
Message-ID: <1219208632.69.0.435134240035.issue3612@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
This patch adds some basic mssing types in ctypes.wintypes.
I think pointer type like LPDWORD would be usuful too, but maybe you
cannot ignore the overhead of POINTER object creation.
----------
assignee: theller
components: ctypes
files: add_some_missing_types.patch
keywords: patch
messages: 71511
nosy: ocean-city, theller
severity: normal
status: open
title: Add some basic mssing types in ctypes.wintypes
versions: Python 2.6
Added file: http://bugs.python.org/file11169/add_some_missing_types.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3612>
_______________________________________
From report at bugs.python.org Wed Aug 20 08:00:34 2008
From: report at bugs.python.org (Dmitry Dvoinikov)
Date: Wed, 20 Aug 2008 06:00:34 +0000
Subject: [New-bugs-announce] [issue3613] base64.encodestring does not
actually accept strings
In-Reply-To: <1219212034.35.0.601192649417.issue3613@psf.upfronthosting.co.za>
Message-ID: <1219212034.35.0.601192649417.issue3613@psf.upfronthosting.co.za>
New submission from Dmitry Dvoinikov <dmitry at targeted.org>:
This quote from base64.py:
---
bytes_types = (bytes, bytearray) # Types acceptable as binary data
...
def encodestring(s):
"""Encode a string into multiple lines of base-64 data.
Argument and return value are bytes.
"""
if not isinstance(s, bytes_types):
raise TypeError("expected bytes, not %s" % s.__class__.__name__)
...
---
shows that encodestring method won't accept str for an argument, only
bytes. Perhaps this is by design, but then wouldn't it make sense to
change the name of the method ?
Anyway, this behavior clashes in (the least I know) xmlrpc.client, line
1168 when basic authentication is present:
---
auth = base64.encodestring(urllib.parse.unquote(auth))
---
because unquote() returns str, not bytes.
----------
components: Library (Lib)
messages: 71513
nosy: ddvoinikov
severity: normal
status: open
title: base64.encodestring does not actually accept strings
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3613>
_______________________________________
From report at bugs.python.org Wed Aug 20 08:13:34 2008
From: report at bugs.python.org (Dmitry Dvoinikov)
Date: Wed, 20 Aug 2008 06:13:34 +0000
Subject: [New-bugs-announce] [issue3614] typo in xmlrpc.client
In-Reply-To: <1219212814.95.0.707077475128.issue3614@psf.upfronthosting.co.za>
Message-ID: <1219212814.95.0.707077475128.issue3614@psf.upfronthosting.co.za>
New submission from Dmitry Dvoinikov <dmitry at targeted.org>:
In xmlrpc.client:1204:
---
headers = {}
if extra_headers:
for key, val in extra_headers:
header[key] = val
---
shouldn't it read
---
headers[key] = val
^
---
?
Otherwise it bails out with
---
NameError: global name 'header' is not defined
---
----------
components: Library (Lib)
messages: 71514
nosy: ddvoinikov
severity: normal
status: open
title: typo in xmlrpc.client
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3614>
_______________________________________
From report at bugs.python.org Wed Aug 20 10:49:13 2008
From: report at bugs.python.org (=?utf-8?q?J._Pablo_Fern=C3=A1ndez?=)
Date: Wed, 20 Aug 2008 08:49:13 +0000
Subject: [New-bugs-announce] [issue3615] Expect methods for testing.
In-Reply-To: <1219222153.94.0.41823703199.issue3615@psf.upfronthosting.co.za>
Message-ID: <1219222153.94.0.41823703199.issue3615@psf.upfronthosting.co.za>
New submission from J. Pablo Fern?ndez <pupeno at pupeno.com>:
I'm attaching a patch that adds expect methods to TestCase. They are
like fail methods, but they don't fail immediately. They are useful when
you want to catch more than one error at a time.
I included some tests.
There are docstrings but more documentation might be needed. I'll gladly
write it if/when the code is good to go.
The original code was written by Donovan Baarda for an internal project
at Google, I only extracted the bits that made sense to publish and
changed the style to me more Python-alike.
----------
components: Library (Lib)
files: expect.diff
keywords: patch
messages: 71518
nosy: pupeno
severity: normal
status: open
title: Expect methods for testing.
versions: Python 3.0
Added file: http://bugs.python.org/file11171/expect.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3615>
_______________________________________
From report at bugs.python.org Wed Aug 20 11:00:58 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Aug 2008 09:00:58 +0000
Subject: [New-bugs-announce] [issue3616] shutil.rmtree() fails on invalid
filename
In-Reply-To: <1219222858.65.0.105309255151.issue3616@psf.upfronthosting.co.za>
Message-ID: <1219222858.65.0.105309255151.issue3616@psf.upfronthosting.co.za>
New submission from STINNER Victor <haypo at users.sourceforge.net>:
If the directory contains invalid filenames (invalid in the system
charset), an exception is raised by os.path.join() used by
shutil.rmtree():
fullname = os.path.join(path, name)
File "/home/haypo/prog/py3k/Lib/posixpath.py", line 64, in join
if b.startswith('/'):
TypeError: expected an object with the buffer interface
name is an bytes object, not a str object. My system charset is utf-8.
Example to reproduce the problem:
mkdir x
# create a file with an invalid name
touch -- $(echo -e 'x/--\0250--')
python -c "import shutils; shutil.rmtree('x')"
=> TypeError: expected an object with the buffer interface
----------
components: Library (Lib)
messages: 71521
nosy: haypo
severity: normal
status: open
title: shutil.rmtree() fails on invalid filename
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3616>
_______________________________________
From report at bugs.python.org Wed Aug 20 11:47:44 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 20 Aug 2008 09:47:44 +0000
Subject: [New-bugs-announce] [issue3617] Add MS EULA to the list of
third-party licenses in the Windows installer
In-Reply-To: <1219225664.77.0.244141020372.issue3617@psf.upfronthosting.co.za>
Message-ID: <1219225664.77.0.244141020372.issue3617@psf.upfronthosting.co.za>
New submission from Marc-Andre Lemburg <mal at egenix.com>:
Since we are shipping the msvcr90.dll (+ assemblies) together with the
Python installer for Windows, we need to include the MS EULA for VS2008
in the third-party licenses section as this is the license that covers
the VS DLLs.
----------
messages: 71527
nosy: lemburg
severity: normal
status: open
title: Add MS EULA to the list of third-party licenses in the Windows installer
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________
From report at bugs.python.org Wed Aug 20 13:00:50 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Aug 2008 11:00:50 +0000
Subject: [New-bugs-announce] [issue3618] possible deadlock in IO library
(Lib/io.py)
In-Reply-To: <1219230050.91.0.189582586712.issue3618@psf.upfronthosting.co.za>
Message-ID: <1219230050.91.0.189582586712.issue3618@psf.upfronthosting.co.za>
New submission from STINNER Victor <haypo at users.sourceforge.net>:
BufferedWriter from Lib/io.py is thread-safe, but... the Python
instruction "with self._write_lock:" could be interrupted when the
lock is already acquired. Especially, _lsprof.Profiler() uses ceval
hook and is called when the lock is acquired. But if the profiler (or
any other module using the hook) re-use the stream (stdout or stderr),
we get a deadlock!?
Well, this problem is really not critical since only developers
profilers (really?).
Solution: use C implementation of Lib/io.py (from Python 2.6) to avoid
ceval hook?
Example with py3k trunk:
>>> import _lsprof
>>> prof=_lsprof.Profiler(42)
>>> prof.enable()
# _lsprof calls 42()
# -> 42 is not callable
# -> call PyErr_WriteUnraisable(<42 is not callable>)
# -> deadlock
Traceback example:
#6 0x080ecb30 in PyThread_acquire_lock (lock=0x820f550, waitflag=1)
at Python/thread_pthread.h:352
(...)
#8 0x08162521 in PyCFunction_Call (func=0x83abfbc, arg=0xb7dc6034,
kw=0x0) at Objects/methodobject.c:81
#9 0x080b3659 in call_function (pp_stack=0xbfbf9474, oparg=0) at
Python/ceval.c:3403
#10 0x080ae7a6 in PyEval_EvalFrameEx (f=0x83b9f94, throwflag=0) at
Python/ceval.c:2205
#11 0x080b3aae in fast_function (func=0x83a25b4, pp_stack=0xbfbf9724,
n=2, na=2, nk=0) at Python/ceval.c:3491
#12 0x080b37ef in call_function (pp_stack=0xbfbf9724, oparg=1) at
Python/ceval.c:3424
#13 0x080ae7a6 in PyEval_EvalFrameEx (f=0x83b981c, throwflag=0) at
Python/ceval.c:2205
#14 0x080b1aee in PyEval_EvalCodeEx (co=0x838a328, globals=0x8330534,
locals=0x0, args=0x8373da0, argcount=2, kws=0x0, kwcount=0, defs=0x0,
defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:2840
#15 0x0814ab2e in function_call (func=0x83a3b8c, arg=0x8373d8c,
kw=0x0) at Objects/funcobject.c:628
#16 0x08118d19 in PyObject_Call (func=0x83a3b8c, arg=0x8373d8c,
kw=0x0) at Objects/abstract.c:2181
#17 0x08132eb0 in method_call (func=0x83a3b8c, arg=0x8373d8c, kw=0x0)
at Objects/classobject.c:323
#18 0x08118d19 in PyObject_Call (func=0x83037dc, arg=0x83141f4,
kw=0x0) at Objects/abstract.c:2181
#19 0x080b2ed8 in PyEval_CallObjectWithKeywords (func=0x83037dc,
arg=0x83141f4, kw=0x0) at Python/ceval.c:3283
#20 0x08141779 in PyFile_WriteObject (v=0x8398e28, f=0x83ab0dc,
flags=1) at Objects/fileobject.c:164
#21 0x08141974 in PyFile_WriteString (s=0x819a2f2 "Exception ",
f=0x83ab0dc) at Objects/fileobject.c:189
#22 0x080c473c in PyErr_WriteUnraisable (obj=0x81fbd78) at
Python/errors.c:696
#23 0xb7f9612f in CallExternalTimer (pObj=0x83a7aa8)
at /home/haypo/prog/py3k/Modules/_lsprof.c:135
#24 0xb7f96984 in Stop (pObj=0x83a7aa8, self=0x826c6d8,
entry=0x826ec80) at /home/haypo/prog/py3k/Modules/_lsprof.c:337
#25 0xb7f96c60 in ptrace_leave_call (self=0x83a7aa8, key=0x81cb150)
at /home/haypo/prog/py3k/Modules/_lsprof.c:420
#26 0xb7f96d5c in profiler_callback (self=0x83a7aa8, frame=0x835a0b4,
what=6, arg=0x83ab92c) at /home/haypo/prog/py3k/Modules/_lsprof.c:471
#27 0x080b28cb in call_trace (func=0xb7f96c85 <profiler_callback>,
obj=0x83a7aa8, frame=0x835a0b4, what=6, arg=0x83ab92c)
at Python/ceval.c:3090
#28 0x080b35da in call_function (pp_stack=0xbfbf9d74, oparg=1) at
Python/ceval.c:3403
#29 0x080ae7a6 in PyEval_EvalFrameEx (f=0x835a0b4, throwflag=0) at
Python/ceval.c:2205
ceval hook: Python/ceval.3403:
PCALL(PCALL_CFUNCTION);
if (flags & (METH_NOARGS | METH_O)) {
...
} else {
PyObject *callargs;
callargs = load_args(pp_stack, na);
READ_TIMESTAMP(*pintr0);
C_TRACE(x, PyCFunction_Call(func,callargs,NULL)); <= **here**
READ_TIMESTAMP(*pintr1);
Py_XDECREF(callargs);
}
----------
components: Library (Lib)
messages: 71537
nosy: haypo
severity: normal
status: open
title: possible deadlock in IO library (Lib/io.py)
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3618>
_______________________________________
From report at bugs.python.org Wed Aug 20 16:00:34 2008
From: report at bugs.python.org (Kent Tenney)
Date: Wed, 20 Aug 2008 14:00:34 +0000
Subject: [New-bugs-announce] [issue3619] A more informative message for
ImportError
In-Reply-To: <1219240834.62.0.382152843898.issue3619@psf.upfronthosting.co.za>
Message-ID: <1219240834.62.0.382152843898.issue3619@psf.upfronthosting.co.za>
New submission from Kent Tenney <ktenney at gmail.com>:
from foo import bar
ImportError: cannot import name bar
The error may be due to the wrong 'foo' being found, some investigation
is required.
If the the ImportError message included the filename for 'foo', the
problem would be obvious.
ImportError cannot import name bar from /usr/lib/<snip>/foo.pyc
A c.l.p. thread on this is at
http://groups.google.com/group/comp.lang.python/browse_thread/thread/88474a32877026fc/
a patch from Wojtek Walczak is here and attached
http://www.stud.umk.pl/~wojtekwa/patches/from-import-py2.5.1.patch
a thread about it on python-dev is here
http://mail.python.org/pipermail/python-dev/2008-August/081889.html
including a comment on the patch
http://mail.python.org/pipermail/python-dev/2008-August/081897.html
----------
components: None
files: from-import-py2.5.1.patch
keywords: patch
messages: 71542
nosy: ktenney
severity: normal
status: open
title: A more informative message for ImportError
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file11173/from-import-py2.5.1.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3619>
_______________________________________
From report at bugs.python.org Wed Aug 20 17:09:29 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Aug 2008 15:09:29 +0000
Subject: [New-bugs-announce] [issue3620] test_asyncore is not cleanup after
its self?
In-Reply-To: <1219244969.03.0.636728598981.issue3620@psf.upfronthosting.co.za>
Message-ID: <1219244969.03.0.636728598981.issue3620@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
This is from the sparc Unbuntu 3.0 bot. I'm having trouble reproducing
it, though.
test test_smtplib produced unexpected output:
**********************************************************************
*** line 2 of actual output doesn't appear in expected output after line 1:
+ error: uncaptured python exception, closing channel
<test.test_smtplib.SimSMTPChannel 127.0.0.1:38832 at 0x268d0a8> (<class
'socket.error'>:[Errno 9] Bad file descriptor
[/home/pybot/buildarea/3.0.klose-ubuntu-sparc/build/Lib/asyncore.py|readwrite|100]
[/home/pybot/buildarea/3.0.klose-ubuntu-sparc/build/Lib/asyncore.py|handle_write_event|426])
**********************************************************************
----------
components: Tests
messages: 71549
nosy: benjamin.peterson
priority: critical
severity: normal
status: open
title: test_asyncore is not cleanup after its self?
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3620>
_______________________________________
From report at bugs.python.org Wed Aug 20 18:14:10 2008
From: report at bugs.python.org (Jason Spiro)
Date: Wed, 20 Aug 2008 16:14:10 +0000
Subject: [New-bugs-announce] [issue3621] it would be nice if installers made
by bdist_wininst stored an EstimatedSize property in the
Windows registry
In-Reply-To: <1219248850.4.0.277642755083.issue3621@psf.upfronthosting.co.za>
Message-ID: <1219248850.4.0.277642755083.issue3621@psf.upfronthosting.co.za>
New submission from Jason Spiro <jasonspiro4 at gmail.com>:
== Summary ==
Installers made by bdist_wininst never set EstimatedSize in the Windows
registry. So Windows makes an estimate[1] of the installed software's
size so the Add/Remove Programs control panel can tell users how much
space the software is are taking up. Windows overestimates the size:
it estimates the size as equal to the size of the entire C:\Python
directory.
Nowadays, disk space is cheaper than ever, so I assume it's uncommon
for people to try to uninstall software to gain space back. So I do
not think it's worth fixing this bug. Does anyone think it *is* worth
fixing?
== Steps to repro ==
You *must* be running Windows XP or higher to repro this.[2] I used
Python 2.5 (which I installed using the MSI installer) but I would be
extremely surprised if this was already fixed in a newer Python's
distutils.
- Download the attached testcase.zip
- Unzip it to a temp directory
- From the temp directory, run the commands:
setup.py bdist_wininst
cd dist
foo-1.0.win32.exe
- Click on Start Menu > Settings > Control Panel > Add/Remove Programs
- Scroll down to "Python 2.5 foo-1.0".
== Actual results ==
- The "Size" column on the right says 46.86MB (that's the size of my
entire "C:\Python 2.5" directory.)
== Expected results ==
- The "Size" column on the right should say something close to 0.1
megabytes.
== Suggested fix ==
- When creating an installer, bdist_wininst should look at the total
size of all files to install, multiply that number by 3 (a reasonable
estimate of the total size the .pyc and .pyo files will take up), and
make the installer set the EstimatedSize[3] in the registry to that
number.
== Footnotes ==
^ [1]. See the blog entry "How does Add/Remove Programs get the size
and other information?" by Raymond Chen at
http://blogs.msdn.com/oldnewthing/archive/2004/07/09/178342.aspx for
info on the algorithm Windows uses.
^ [2]. Versions of Windows older than XP never try to estimate the
size of installed programs.
^ [3]. This is
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\(application
descriptor)\EstimatedSize and should be a DWORD representing the number
of kilobytes the software takes up, according to
http://forum.installsite.net/?showtopic=698#entry12501
----------
components: Distutils
messages: 71554
nosy: jasonspiro
severity: normal
status: open
title: it would be nice if installers made by bdist_wininst stored an EstimatedSize property in the Windows registry
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3621>
_______________________________________
From report at bugs.python.org Thu Aug 21 00:42:04 2008
From: report at bugs.python.org (Allan Crooks)
Date: Wed, 20 Aug 2008 22:42:04 +0000
Subject: [New-bugs-announce] [issue3622] Slight documentation quirk for
random.random
In-Reply-To: <1219272124.61.0.469101656014.issue3622@psf.upfronthosting.co.za>
Message-ID: <1219272124.61.0.469101656014.issue3622@psf.upfronthosting.co.za>
New submission from Allan Crooks <amc1 at users.sourceforge.net>:
The documentation for random.random function shows this:
random() -> x in the interval [0, 1).
That should either be "[0, 1]" or "(0, 1)".
----------
assignee: georg.brandl
components: Documentation
messages: 71582
nosy: amc1, georg.brandl
severity: normal
status: open
title: Slight documentation quirk for random.random
type: behavior
versions: Python 2.3, Python 2.4, Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3622>
_______________________________________
From report at bugs.python.org Thu Aug 21 00:58:44 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Aug 2008 22:58:44 +0000
Subject: [New-bugs-announce] [issue3623] _json: fix raise_errmsg(),
py_encode_basestring_ascii() and linecol()
In-Reply-To: <1219273124.72.0.104841129313.issue3623@psf.upfronthosting.co.za>
Message-ID: <1219273124.72.0.104841129313.issue3623@psf.upfronthosting.co.za>
New submission from STINNER Victor <haypo at users.sourceforge.net>:
_json module of python 3.0 has some bugs.
(a) [_json.c] raise_errmsg() calls json.decoder.errmsg() from Python
module, but this function may fails. If it fails, error should be be
set to NULL. Example:
>>> import _json
>>> _json.scanstring(b"xxx", 1, "xxx")
Erreur de segmentation (core dumped)
=> json.decoder.errmsg() calls linecol() which raise an error on
b"xxx".index("\n").
(b) [_json.c] py_encode_basestring_ascii() calls PyBytes_Check(rval)
but rval can be NULL if ascii_escape_str() or ascii_escape_unicode()
fails. Example:
>>> import _json
>>> _json.encode_basestring_ascii(b"xx\xff")
Erreur de segmentation (core dumped)
(c) [Lib/json/decoder.py] linecol() doesn't support bytes, but it's
called with bytes argument: see point (a). For an example, see point
(a).
----------
components: Library (Lib)
files: _json.patch
keywords: patch
messages: 71588
nosy: haypo
severity: normal
status: open
title: _json: fix raise_errmsg(), py_encode_basestring_ascii() and linecol()
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file11181/_json.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3623>
_______________________________________
From report at bugs.python.org Thu Aug 21 01:04:03 2008
From: report at bugs.python.org (Matt Aasted)
Date: Wed, 20 Aug 2008 23:04:03 +0000
Subject: [New-bugs-announce] [issue3624] Null byte \0 not listed as a
possible escape sequence
In-Reply-To: <1219273443.74.0.909358695048.issue3624@psf.upfronthosting.co.za>
Message-ID: <1219273443.74.0.909358695048.issue3624@psf.upfronthosting.co.za>
New submission from Matt Aasted <aasted at gmail.com>:
In current, future and past documentation, the valid escape sequence \0
(equivalent to \x00) is missing from the list of possible escape
sequences in the documentation. As far as I can tell, it is not a case
covered by any of the other elements in the list, and is valid python
though I have only tested current (2.5.2) for it.
Current version can be found here: http://docs.python.org/ref/strings.html
----------
assignee: georg.brandl
components: Documentation
messages: 71590
nosy: georg.brandl, voket
severity: normal
status: open
title: Null byte \0 not listed as a possible escape sequence
versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3624>
_______________________________________
From report at bugs.python.org Thu Aug 21 05:22:16 2008
From: report at bugs.python.org (Mark Hammond)
Date: Thu, 21 Aug 2008 03:22:16 +0000
Subject: [New-bugs-announce] [issue3625] test issues on 64bit windows
In-Reply-To: <1219288936.06.0.57687304874.issue3625@psf.upfronthosting.co.za>
Message-ID: <1219288936.06.0.57687304874.issue3625@psf.upfronthosting.co.za>
New submission from Mark Hammond <mhammond at users.sourceforge.net>:
A number of tests are designed to be skipped on 64bits, but they don't
detect 64bit windows builds as 64bits. Also, test_bytes.test_repeat()
assumes sys.maxint bytes can't be allocated, which isn't necessarily
true on Win64.
I'm attaching a patch that arranges to skip these tests.
----------
assignee: mhammond
components: Tests, Windows
files: win64_test_failures.patch
keywords: 64bit, patch, patch
messages: 71603
nosy: mhammond
severity: normal
status: open
title: test issues on 64bit windows
versions: Python 2.6
Added file: http://bugs.python.org/file11184/win64_test_failures.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3625>
_______________________________________
From report at bugs.python.org Thu Aug 21 06:36:02 2008
From: report at bugs.python.org (Yaakov (Cygwin Ports))
Date: Thu, 21 Aug 2008 04:36:02 +0000
Subject: [New-bugs-announce] [issue3626] python3.0 interpreter on Cygwin
ignores all arguments
In-Reply-To: <1219293362.56.0.98048679745.issue3626@psf.upfronthosting.co.za>
Message-ID: <1219293362.56.0.98048679745.issue3626@psf.upfronthosting.co.za>
New submission from Yaakov (Cygwin Ports) <yselkowitz at users.sourceforge.net>:
Attempting to build 3.0b3, the sharedmods make target results only in a
python command prompt. In fact, it seems that the interpreter doesn't
accept any arguments:
$ /usr/bin/python --version
Python 2.5.2
$ /usr/bin/python -c 'print "Hello, World!"'
Hello, World!
$ ./python.exe --version
Python 3.0b3 (r30b3:65927, Aug 20 2008, 22:34:44)
[GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
$ ./python.exe -c 'print "Hello, World!"'
Python 3.0b3 (r30b3:65927, Aug 20 2008, 22:34:44)
[GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
The same happened with 3.0b2 when I tried to determine if this was a
recent regression. I have successfully built 2.5 on a number of occasions.
----------
components: Interpreter Core
messages: 71606
nosy: yselkowitz
severity: normal
status: open
title: python3.0 interpreter on Cygwin ignores all arguments
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3626>
_______________________________________
From report at bugs.python.org Thu Aug 21 07:43:42 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Thu, 21 Aug 2008 05:43:42 +0000
Subject: [New-bugs-announce] [issue3627] apple security patches need to be
forward ported to py3k
In-Reply-To: <1219297422.68.0.603691629557.issue3627@psf.upfronthosting.co.za>
Message-ID: <1219297422.68.0.603691629557.issue3627@psf.upfronthosting.co.za>
New submission from Neal Norwitz <nnorwitz at gmail.com>:
The trunk revision was 65335.
----------
components: Interpreter Core
messages: 71608
nosy: nnorwitz
priority: release blocker
severity: normal
status: open
title: apple security patches need to be forward ported to py3k
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3627>
_______________________________________
From report at bugs.python.org Thu Aug 21 10:06:31 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 21 Aug 2008 08:06:31 +0000
Subject: [New-bugs-announce] [issue3628] IDLE does not run with Py30b3
In-Reply-To: <1219305991.9.0.193360679175.issue3628@psf.upfronthosting.co.za>
Message-ID: <1219305991.9.0.193360679175.issue3628@psf.upfronthosting.co.za>
New submission from Mark Summerfield <mark at qtrac.eu>:
When I try to run IDLE in Py30b3 I get a traceback, then the main window
appears with an error message box and an OK button; once I click OK,
IDLE goes away.
$ ~/opt/python30b3/bin/idle
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/home/mark/opt/python30b3/lib/python3.0/idlelib/run.py", line
76, in main
sockthread.set_daemon(True)
AttributeError: 'Thread' object has no attribute 'set_daemon'
It looks like there's been some mixup with threading... in an earlier
beta there was setDaemon(), then it became set_daemon(), and now it is
back to setDaemon() again. And unfortunately, the obvious fix (change
the name to setDaemon()), although it gets past this problem, just leads
to another:
$ ~/opt/python30b3/bin/idle # using setDaemon
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/home/mark/opt/python30b3/lib/python3.0/idlelib/run.py", line
76, in main
sockthread.setDaemon(True)
File "/home/mark/opt/python30b3/lib/python3.0/threading.py", line 674,
in setDaemon
"Thread.daemon property", DeprecationWarning)
File "/home/mark/opt/python30b3/lib/python3.0/warnings.py", line 18,
in showwarning
file.write(formatwarning(message, category, filename, lineno, line))
TypeError: idle_formatwarning_subproc() takes exactly 4 positional
arguments (5 given)
I did run make test and got 300 tests OK with 22 skipped all expected on
linux2.
----------
components: IDLE
messages: 71611
nosy: mark
severity: normal
status: open
title: IDLE does not run with Py30b3
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3628>
_______________________________________
From report at bugs.python.org Thu Aug 21 10:42:01 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 21 Aug 2008 08:42:01 +0000
Subject: [New-bugs-announce] [issue3629] Py30b3 won't compile a regex that
compiles with 2.5.2 and 30b2
In-Reply-To: <1219308121.8.0.569099168761.issue3629@psf.upfronthosting.co.za>
Message-ID: <1219308121.8.0.569099168761.issue3629@psf.upfronthosting.co.za>
New submission from Mark Summerfield <mark at qtrac.eu>:
Here are the results of running the same tiny program against 2.5.2,
30b2, and 30b3. The program creates a regex and tries to match 3
strings. For 2.5.2 and 30b2 this works fine; for 30b3 the regex won't
even compile:
$ python -V
Python 2.5.2
$ python /tmp/retext.py
name="name1" value="value1"
name="name2" value="value #2"
name="name3" value="value '3'"
$
$ ~/opt/python30b2/bin/python3.0 -V
Python 3.0b2
$ ~/opt/python30b2/bin/python3.0 /tmp/retext.py
name="name1" value="value1"
name="name2" value="value #2"
name="name3" value="value '3'"
$
$ ~/opt/python30b3/bin/python3.0 /tmp/retext.py
Traceback (most recent call last):
File "/tmp/retext.py", line 8, in <module>
""", re.VERBOSE)
File "/home/mark/opt/python30b3/lib/python3.0/re.py", line 203, in compile
return _compile(pattern, flags)
File "/home/mark/opt/python30b3/lib/python3.0/re.py", line 255, in
_compile
p = sre_compile.compile(pattern, flags)
File "/home/mark/opt/python30b3/lib/python3.0/sre_compile.py", line
520, in compile
groupindex, indexgroup
RuntimeError: invalid SRE code
----------
components: Regular Expressions
files: retext.py
messages: 71614
nosy: mark
severity: normal
status: open
title: Py30b3 won't compile a regex that compiles with 2.5.2 and 30b2
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11185/retext.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3629>
_______________________________________
From report at bugs.python.org Thu Aug 21 11:54:16 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Aug 2008 09:54:16 +0000
Subject: [New-bugs-announce] [issue3630] Unable to inherit bytes:
bytes.__init__() doesn't accept arguments
In-Reply-To: <1219312456.78.0.90200161612.issue3630@psf.upfronthosting.co.za>
Message-ID: <1219312456.78.0.90200161612.issue3630@psf.upfronthosting.co.za>
New submission from STINNER Victor <haypo at users.sourceforge.net>:
Example:
class MyBytes(bytes):
def __init__(self, *args, **kw):
bytes.__init__(self, *args, **kw)
a = bytes(b"hello") # ok
b = MyBytes(b"hello") # error
=> DeprecationWarning: object.__init__() takes no parameters
The example works fine in Python 2.6 but fails in Python 3.0.
----------
components: Library (Lib)
messages: 71619
nosy: haypo
severity: normal
status: open
title: Unable to inherit bytes: bytes.__init__() doesn't accept arguments
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3630>
_______________________________________
From report at bugs.python.org Thu Aug 21 14:29:03 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Aug 2008 12:29:03 +0000
Subject: [New-bugs-announce] [issue3631] Improve gdbinit of Python 2.6
In-Reply-To: <1219321743.09.0.122028214381.issue3631@psf.upfronthosting.co.za>
Message-ID: <1219321743.09.0.122028214381.issue3631@psf.upfronthosting.co.za>
New submission from STINNER Victor <haypo at users.sourceforge.net>:
I wrote a patch to improve gdbinit (gdb macros):
- implement py_decref
- reuse pyo in pylocals
- direclty call PyCode_Addr2Line() in lineno instead of a long and
complex reimplemention in gdb script language
- avoid memory leak in pylocals: call py_decref($_name)
See also #3610 (for Python 3.0).
----------
files: gdbinit_python26.patch
keywords: patch
messages: 71627
nosy: haypo
severity: normal
status: open
title: Improve gdbinit of Python 2.6
Added file: http://bugs.python.org/file11191/gdbinit_python26.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3631>
_______________________________________
From report at bugs.python.org Thu Aug 21 14:39:40 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Aug 2008 12:39:40 +0000
Subject: [New-bugs-announce] [issue3632] use string_print() in gdb
In-Reply-To: <1219322380.25.0.792509106776.issue3632@psf.upfronthosting.co.za>
Message-ID: <1219322380.25.0.792509106776.issue3632@psf.upfronthosting.co.za>
New submission from STINNER Victor <haypo at users.sourceforge.net>:
"pyo" macro from gdbinit (see #3631) uses _PyObject_Dump() to display
an object. This function calls (indirectly) string_print() to display
one line of text. But if the GIL is released (I guess it's the GIL or
is it called the "thread state"?), gdb crashs Python:
object : Fatal Python error: PyEval_SaveThread: NULL tstate
Program received signal SIGABRT, Aborted.
0xffffe410 in __kernel_vsyscall ()
Workaround: ensure GIL before Py_BEGIN_ALLOW_THREADS... That sounds
ugly but it works :-) So I propose to enable it in debug mode (#ifdef
Py_DEBUG) with a patch.
I guess that the issue is very specific to (gdb) debugging and should
not affect normal usage of Python. That's why I choosed to enable it
only in debug mode.
----------
components: Library (Lib)
files: string_print.patch
keywords: patch
messages: 71628
nosy: haypo
severity: normal
status: open
title: use string_print() in gdb
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file11192/string_print.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3632>
_______________________________________
From report at bugs.python.org Thu Aug 21 15:18:35 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Aug 2008 13:18:35 +0000
Subject: [New-bugs-announce] [issue3633] float.fromhex discrepancy under
Solaris
In-Reply-To: <1219324715.21.0.0788061296903.issue3633@psf.upfronthosting.co.za>
Message-ID: <1219324715.21.0.0788061296903.issue3633@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
This is a failure that seems to occur quite often (always?) on the
Solaris buildbot:
======================================================================
FAIL: test_invalid_inputs (test.test_float.HexFloatTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/home2/buildbot/slave/3.0.loewis-sun/build/Lib/test/test_float.py",
line 451, in test_invalid_inputs
self.assertRaises(ValueError, fromHex, x)
AssertionError: ValueError not raised by fromhex
----------------------------------------------------------------------
----------
components: Interpreter Core
messages: 71635
nosy: pitrou
priority: critical
severity: normal
status: open
title: float.fromhex discrepancy under Solaris
type: behavior
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3633>
_______________________________________
From report at bugs.python.org Thu Aug 21 19:25:01 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Aug 2008 17:25:01 +0000
Subject: [New-bugs-announce] [issue3634] invalid result value of
_weakref.__init__()
In-Reply-To: <1219339501.95.0.782408070152.issue3634@psf.upfronthosting.co.za>
Message-ID: <1219339501.95.0.782408070152.issue3634@psf.upfronthosting.co.za>
New submission from STINNER Victor <victor.stinner at haypocalc.com>:
_weakref.__init__() doesn't catch errors correctly. Example:
--------------------- 8< -------------------------
from gc import collect
import _weakref
class FuzzingUserClass:
pass
obj = _weakref.ref(FuzzingUserClass)
# Exception not raised??
obj.__init__(
0,
0,
0,
)
# Exception catched here??
collect()
--------------------- 8< -------------------------
Attached patch fix the bug for py3k branch: return -1 on error
(instead of 1).
----------
components: Library (Lib)
files: weakref_init.patch
keywords: patch
messages: 71662
nosy: haypo
severity: normal
status: open
title: invalid result value of _weakref.__init__()
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11195/weakref_init.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3634>
_______________________________________
From report at bugs.python.org Thu Aug 21 21:21:40 2008
From: report at bugs.python.org (Michael Yang)
Date: Thu, 21 Aug 2008 19:21:40 +0000
Subject: [New-bugs-announce] [issue3635] pickle.dumps cannot save instance
of dict-derived class that overrides __getattribute__
In-Reply-To: <1219346500.78.0.74794831892.issue3635@psf.upfronthosting.co.za>
Message-ID: <1219346500.78.0.74794831892.issue3635@psf.upfronthosting.co.za>
New submission from Michael Yang <yangofzeal at gmail.com>:
# pickle.dumps is not able to process an instance of
# a class that inherits from 'dict' and
# overrides the built-in __getattribute__ method
# but can successfully process one that
# overrides the__getattr__ method
>>> class Examp1(dict):
... def __getattr__(self,name):
... return self[name]
...
>>> class Examp2(dict):
... def __getattribute__(self,name):
... return self[name]
...
>>> ex1 = Examp1()
>>> ex2 = Examp2()
>>> ex1['aKey'] = (3,4)
>>> ex2['aKey2'] = (4,5)
>>> ex1
{'aKey': (3, 4)}
>>> ex1.aKey
(3, 4)
>>> ex2
{'aKey2': (4, 5)}
>>> ex2.aKey2
(4, 5)
>>> import pickle
>>> pickle.dumps(ex1)
b'\x80\x03c__main__\nexamp1\nq\x00)\x81q\x01X\x04\x00\x00\x00aKeyq\x02K\x03K\x04\x86q\x03s}q\x04b.'
>>> pickle.dumps(ex2)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "[hidden]/python3/3.0b2/common/lib/python3.0/pickle.py", line
1319, in dumps
Pickler(f, protocol).dump(obj)
File "<stdin>", line 3, in __getattribute__
KeyError: '__reduce_ex__'
----------
components: Extension Modules
messages: 71671
nosy: msyang
severity: normal
status: open
title: pickle.dumps cannot save instance of dict-derived class that overrides __getattribute__
type: behavior
versions: Python 2.5, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3635>
_______________________________________
From report at bugs.python.org Thu Aug 21 22:24:25 2008
From: report at bugs.python.org (richard_b_martin)
Date: Thu, 21 Aug 2008 20:24:25 +0000
Subject: [New-bugs-announce] [issue3636] Managing dual 2.x and 3.0
installations on Windows
In-Reply-To: <1219350265.84.0.067322027975.issue3636@psf.upfronthosting.co.za>
Message-ID: <1219350265.84.0.067322027975.issue3636@psf.upfronthosting.co.za>
New submission from richard_b_martin <martin at ambric.com>:
I installed a 3.0 beta for the first time in Windows. I was surprised
when my 2.5 scripts started to fail. I traced it down to the 3.0
install modifying the registry.
If you run "assoc .py" from a command line, the return value is
Python.File. If you search the registry for references to Python.File,
you'll find a path that points to python.exe. The 3.0 install changed
this value.
So at least a warning in the installation instructions would be nice.
Probably better would be a script that allow a user to switch between
2.x and 3.0 installations. That would include having to perhaps modify
the env. variables, Path and PYTHONPATH (see bug 2375) and the registry.
Many thanks, by the way, to all the python developers over the years.
----------
assignee: georg.brandl
components: Documentation
messages: 71676
nosy: georg.brandl, richard_b_martin
severity: normal
status: open
title: Managing dual 2.x and 3.0 installations on Windows
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3636>
_______________________________________
From report at bugs.python.org Thu Aug 21 22:46:16 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 20:46:16 +0000
Subject: [New-bugs-announce] [issue3637] 2to3 refactoring
In-Reply-To: <1219351576.1.0.980085138833.issue3637@psf.upfronthosting.co.za>
Message-ID: <1219351576.1.0.980085138833.issue3637@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
The attached patch moves cmdline processing logic out of RefactoringTool
and into its own module lib2to3.main. Guido and Collin: If you could
review this (it's on Rietveld [1]) sometime soon, I can check this in
and start writing the API docs for 2to3.
Thanks.
[1] http://codereview.appspot.com/3247
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: 2to3_refactoring.patch
keywords: patch
messages: 71678
nosy: benjamin.peterson, collinwinter, gvanrossum
severity: normal
status: open
title: 2to3 refactoring
type: feature request
Added file: http://bugs.python.org/file11198/2to3_refactoring.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3637>
_______________________________________
From report at bugs.python.org Fri Aug 22 00:00:14 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Aug 2008 22:00:14 +0000
Subject: [New-bugs-announce] [issue3638] tkinter.mainloop() is meanling less
and crash: remove it
In-Reply-To: <1219356014.43.0.144260212562.issue3638@psf.upfronthosting.co.za>
Message-ID: <1219356014.43.0.144260212562.issue3638@psf.upfronthosting.co.za>
New submission from STINNER Victor <victor.stinner at haypocalc.com>:
mainloop() is a method of a Tkapp object, but it's also a method of
_tkinter module. In TkApp_MainLoop, self is seen as a TkappObject
whereas it can be a module object! So instruction
like "self->dispatch=1" will replace a random byte in the module
object (eg. ob_type attribute). Example to crash:
import gc
import _tkinter
_tkinter.mainloop()
gc.collect()
It always crashs in my Python 3.0, but not in Python 2.6.
Solution: just remove _tkinter.mainloop() => it should have no side
effect since users use tkinter (without the "_") which only uses
Tkapp.mainloop() (the right way to use Tkapp_MainLoop() function).
Solution "implemented" in the patch.
----------
components: Library (Lib)
files: tkinter_remove_mainloop.patch
keywords: patch
messages: 71691
nosy: haypo
severity: normal
status: open
title: tkinter.mainloop() is meanling less and crash: remove it
type: crash
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11200/tkinter_remove_mainloop.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3638>
_______________________________________
From report at bugs.python.org Fri Aug 22 00:30:27 2008
From: report at bugs.python.org (Lisandro Dalcin)
Date: Thu, 21 Aug 2008 22:30:27 +0000
Subject: [New-bugs-announce] [issue3639] segfaults calling warnings.warn()
with non-string message
In-Reply-To: <1219357827.01.0.105768400803.issue3639@psf.upfronthosting.co.za>
Message-ID: <1219357827.01.0.105768400803.issue3639@psf.upfronthosting.co.za>
New submission from Lisandro Dalcin <dalcinl at gmail.com>:
from warnings import warn
warn("hello world") # -> Success
warn(UserWarning) # -> Segmentation fault
warn(None) # -> Segmentation fault
warn(1) # -> Segmentation fault
----------
components: Interpreter Core
messages: 71694
nosy: dalcinl
severity: normal
status: open
title: segfaults calling warnings.warn() with non-string message
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3639>
_______________________________________
From report at bugs.python.org Fri Aug 22 01:21:43 2008
From: report at bugs.python.org (Mark Hammond)
Date: Thu, 21 Aug 2008 23:21:43 +0000
Subject: [New-bugs-announce] [issue3640] test_cpickle crash on AMD64 Windows
build
In-Reply-To: <1219360903.53.0.323822932018.issue3640@psf.upfronthosting.co.za>
Message-ID: <1219360903.53.0.323822932018.issue3640@psf.upfronthosting.co.za>
New submission from Mark Hammond <mhammond at users.sourceforge.net>:
[from python-dev]
I've found a recursion related crash in test_cpickle on 64bit builds.
Specifically, the 'cPickleDeepRecursive' is causing a stack overflow,
and the debugger tells me the actual recursion depth was 629 at the crash.
The reason the 64bit build doesn't see more crashes is apparently due to
another regression in 2.6 - http://bugs.python.org/issue3373. It
appears that in some cases, the recursion counter is actually
incremented *twice* for each entry, thereby causing the "maximum
recursion depth exceeded" exception to appear at a true recursion limit
of 500. However, test_cpickle takes a different path and doesn't see
this doubling of the count - therefore dieing at the depth of 629 that I
can see.
My solution to this was to simply double the stack size for the
executables in 64bit builds, from 2MB to 4MB (2.1 and 4.2 for debug
builds.) Is this an appropriate fix?
----------
components: Tests
messages: 71697
nosy: mhammond, pitrou
severity: normal
status: open
title: test_cpickle crash on AMD64 Windows build
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3640>
_______________________________________
From report at bugs.python.org Fri Aug 22 02:19:55 2008
From: report at bugs.python.org (tav)
Date: Fri, 22 Aug 2008 00:19:55 +0000
Subject: [New-bugs-announce] [issue3641] Builtin ascii() function from
future_builtins includes leading "u" of unicode strings
In-Reply-To: <1219364395.89.0.296676765919.issue3641@psf.upfronthosting.co.za>
Message-ID: <1219364395.89.0.296676765919.issue3641@psf.upfronthosting.co.za>
New submission from tav <tav at espians.com>:
Perhaps I misunderstood the intended behaviour of the ascii() builtin in
the future_builtins module, but the following behaviour is unexpected:
>>> from __future__ import unicode_literals
>>> from future_builtins import ascii
>>> test = 'hello'
>>> ascii(test)
"u'hello'"
Surely the leading 'u' should not be there?
After all, this is a future builtin we are importing -- when all
'strings' are unicode by default?
----------
components: Library (Lib)
messages: 71708
nosy: tav
severity: normal
status: open
title: Builtin ascii() function from future_builtins includes leading "u" of unicode strings
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3641>
_______________________________________
From report at bugs.python.org Fri Aug 22 03:03:01 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 22 Aug 2008 01:03:01 +0000
Subject: [New-bugs-announce] [issue3642] Objects/obmalloc.c:529: warning:
comparison is always false due to limited range of data type
In-Reply-To: <1219366981.65.0.722546455294.issue3642@psf.upfronthosting.co.za>
Message-ID: <1219366981.65.0.722546455294.issue3642@psf.upfronthosting.co.za>
New submission from Christian Heimes <lists at cheimes.de>:
I'm getting a compiler warning on Linux AMD64. It's most probably an
issue related to 64bit builds, because size_t > uint_t on 64bit systems.
Such warnings may hide overflow issues.
gcc -pthread -c -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I.
-IInclude -I./Include -DPy_BUILD_CORE -o Objects/obmalloc.o
Objects/obmalloc.c
Objects/obmalloc.c: In function 'new_arena':
Objects/obmalloc.c:529: warning: comparison is always false due to
limited range of data type
I was able to silence the compiler by declaring numarenas as size_t
instead of uint.
----------
components: Build
keywords: 64bit, needs review
messages: 71712
nosy: christian.heimes
priority: release blocker
severity: normal
status: open
title: Objects/obmalloc.c:529: warning: comparison is always false due to limited range of data type
type: compile error
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3642>
_______________________________________
From report at bugs.python.org Fri Aug 22 03:41:23 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Aug 2008 01:41:23 +0000
Subject: [New-bugs-announce] [issue3643] Add more checks to testcapi
In-Reply-To: <1219369283.37.0.028447493951.issue3643@psf.upfronthosting.co.za>
Message-ID: <1219369283.37.0.028447493951.issue3643@psf.upfronthosting.co.za>
New submission from STINNER Victor <victor.stinner at haypocalc.com>:
test_thread_state() doesn't check that the argument is a function and
doesn't check function call result and so the exception is catched
later:
Non callable argument:
import _testcapi
_testcapi._test_thread_state(10)
# no exception raise here
import gc
# exception raised too late!
=> TypeError: 'int' object is not callable
Callback error:
import _testcapi
def err():
raise ValueError("xxx")
_testcapi._test_thread_state(err)
# no exception raise here
import gc
# exception raised too late!
=> ValueError: xxx
So I wrote a patch which fixes that but also raise_exception() which
have to check that the argument is an exception class.
----------
components: Library (Lib)
files: testcapi_py26.patch
keywords: patch
messages: 71714
nosy: haypo
severity: normal
status: open
title: Add more checks to testcapi
type: feature request
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11204/testcapi_py26.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3643>
_______________________________________
From report at bugs.python.org Fri Aug 22 05:36:57 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Aug 2008 03:36:57 +0000
Subject: [New-bugs-announce] [issue3644] ``make htmlview`` for docs fails on
OS X
In-Reply-To: <1219376217.3.0.964627444856.issue3644@psf.upfronthosting.co.za>
Message-ID: <1219376217.3.0.964627444856.issue3644@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Running ``make htmlview`` on OS X Leopard causes the following::
> make htmlview
~/Dev/python/3.x/scratch/Doc
mkdir -p build/html build/doctrees
python2.5 tools/sphinx-build.py -b html -d build/doctrees -D
latex_paper_size= . build/html
Sphinx v0.5, building html
loading pickled environment... done
building [html]: targets for 0 source files that are out of date
updating environment: 0 added, 0 changed, 0 removed
no targets are out of date.
Build finished. The HTML pages are in build/html.
python2.5 -c "import webbrowser; webbrowser.open('build/html/index.html')"
0:42: execution error: An error of type -2110 has occurred. (-2110)
----------
assignee: georg.brandl
components: Documentation
messages: 71720
nosy: brett.cannon, georg.brandl
priority: low
severity: normal
status: open
title: ``make htmlview`` for docs fails on OS X
type: behavior
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3644>
_______________________________________
From report at bugs.python.org Fri Aug 22 07:41:09 2008
From: report at bugs.python.org (Henry Precheur)
Date: Fri, 22 Aug 2008 05:41:09 +0000
Subject: [New-bugs-announce] [issue3645] readline module Crashs on
OpenBSD/amd64
In-Reply-To: <1219383669.6.0.427882345707.issue3645@psf.upfronthosting.co.za>
Message-ID: <1219383669.6.0.427882345707.issue3645@psf.upfronthosting.co.za>
New submission from Henry Precheur <henry at precheur.org>:
$ python2.5
Python 2.5.2 (r252:60911, Jun 16 2008, 15:20:47)
[GCC 3.3.5 (propolice)] on openbsd4
Type "help", "copyright", "credits" or "license" for more information.
>>> def complete(text, state):
... print 'complete %r %d' % (text, state)
... if text == 'i' and state == 0:
... return 'import'
... else:
... return None
...
>>> import readline; readline.parse_and_bind("tab: complete")
>>> readline.set_completer(complete)
>>> i<TAB> # <TAB> is press the tab key
complete 'i' 0
complete 'i' 1
Segmentation fault (core dumped)
The problem is that Python is using a function present in libreadline
but not declared in readline/readline.h: completion_matches. Instead of
using rl_completion_matches.
Therefor the return type of completion_matches was an int which is
32bits on amd64 but the function was supposed to returns a pointer which
is 64 bits. So when the pointer had a "high" value, it was truncated.
The problem is fixed by adding libcurses to AC_CHECK_LIB when checking
for functions in libreadline since libreadline depends on curses. This
makes Python use the correct functions declared on readline.h with a
correct return type.
Patch is attached.
(Others versions of Python should also be affected)
----------
components: Library (Lib)
files: patch.configure.in
messages: 71723
nosy: henry.precheur
severity: normal
status: open
title: readline module Crashs on OpenBSD/amd64
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file11206/patch.configure.in
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3645>
_______________________________________
From report at bugs.python.org Fri Aug 22 10:13:46 2008
From: report at bugs.python.org (Konrad Hinsen)
Date: Fri, 22 Aug 2008 08:13:46 +0000
Subject: [New-bugs-announce] [issue3646] MacOS X framework install to
non-standard directory fails
In-Reply-To: <1219392826.4.0.166247537114.issue3646@psf.upfronthosting.co.za>
Message-ID: <1219392826.4.0.166247537114.issue3646@psf.upfronthosting.co.za>
New submission from Konrad Hinsen <konrad.hinsen at laposte.net>:
The file Mac/README in Python 2.6b3 says:
Installing in another place, for instance $HOME/Library/Frameworks if
you have no admin privileges on your machine, has only been tested very
lightly. This can be done by configuring with --enable-
framework=$HOME/Library/Frameworks. The other two directories,
"/Applications/MacPython-2.6" and /usr/local/bin, will then also be
deposited in $HOME. This is sub-optimal for the unix tools, which you
would want in $HOME/bin, but there is no easy way to fix this right
now.
In reality, the framework is installed in the directory given on the
command line, but the installer then wants to write the app to
/Applications/MacPython-2.6 and crashes due to lack of write permission:
DYLD_FRAMEWORK_PATH=/shared_scratch/Python-2.6b3: ../python.exe
./scripts/Buil\
dApplet.py \
--destroot "" \
--
python=/shared_scratch/Library/Frameworks/Python.framework/Versions/2\
.6/Resources/Python.app/Contents/MacOS/Python`test -f
"/shared_scratch/Library/\
Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/M
acOS/Py\
thon-32" && echo "-32"` \
--output "/Applications/Python 2.6/Build Applet.app" \
./scripts/BuildApplet.py
kCGErrorRangeCheck : Window Server communications from outside of
session allow\
ed for root and console user only
./scripts/BuildApplet.py:34: DeprecationWarning: catching of string
exceptions \
is deprecated
except buildtools.BuildError, detail:
Traceback (most recent call last):
File "./scripts/BuildApplet.py", line 149, in <module>
main()
File "./scripts/BuildApplet.py", line 33, in main
buildapplet()
File "./scripts/BuildApplet.py", line 116, in buildapplet
progress=verbose, destroot=destroot)
File "/Volumes/User data/Scratch/Python-2.6b3/Lib/plat-
mac/buildtools.py", li\
ne 115, in process
copy_codefragment, raw, others, filename, destroot)
File "/Volumes/User data/Scratch/Python-2.6b3/Lib/plat-
mac/buildtools.py", li\
ne 140, in process_common
is_update, raw, others, filename, destroot)
File "/Volumes/User data/Scratch/Python-2.6b3/Lib/plat-
mac/buildtools.py", li\
ne 327, in process_common_macho
builder.build()
File "/Volumes/User data/Scratch/Python-2.6b3/Lib/plat-
mac/bundlebuilder.py",\
line 147, in build
os.mkdir(builddir)
OSError: [Errno 13] Permission denied: '/Applications/Python 2.6'
make[1]: *** [install_BuildApplet] Error 1
make: *** [frameworkinstallapps] Error 2
----------
components: Build
messages: 71728
nosy: khinsen
severity: normal
status: open
title: MacOS X framework install to non-standard directory fails
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3646>
_______________________________________
From report at bugs.python.org Fri Aug 22 14:54:36 2008
From: report at bugs.python.org (Senthil)
Date: Fri, 22 Aug 2008 12:54:36 +0000
Subject: [New-bugs-announce] [issue3647] urlparse - relative url parsing and
joins to be RFC3986 compliance
In-Reply-To: <1219409676.71.0.379802173537.issue3647@psf.upfronthosting.co.za>
Message-ID: <1219409676.71.0.379802173537.issue3647@psf.upfronthosting.co.za>
New submission from Senthil <orsenthil at gmail.com>:
Attaching two patches to make the current urlparse library, especially
the relative url parsing and urljoin to be RFC3986 compliance.
I have included all the tests prescribed in RFC3986 and verified them
to pass with the patches.
Our parsing functionality of netloc (to
username,password,hostname,port) is same as what RFC3986 specifies. It
uses the term 'authority' instead of 'netloc'. I did not feel the need
for name change. If required, it can done.
----------
components: Library (Lib)
files: urlparse_rfc3986-py26.diff
keywords: patch
messages: 71743
nosy: orsenthil
severity: normal
status: open
title: urlparse - relative url parsing and joins to be RFC3986 compliance
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11208/urlparse_rfc3986-py26.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3647>
_______________________________________
From report at bugs.python.org Fri Aug 22 16:14:10 2008
From: report at bugs.python.org (electronixtar)
Date: Fri, 22 Aug 2008 14:14:10 +0000
Subject: [New-bugs-announce] [issue3648] 'ascii' shoud be range(256) or just
set another default encoding
In-Reply-To: <1219414450.32.0.0238360557627.issue3648@psf.upfronthosting.co.za>
Message-ID: <1219414450.32.0.0238360557627.issue3648@psf.upfronthosting.co.za>
New submission from electronixtar <electronicstar at 126.com>:
One of the MOST common scene for Python developers on CJK/Widecharacter
is this error:
'ascii' codec can't decode byte 0xe5 in position 0: ordinal not in range
(128)
Why cann't Python just define ascii to range(256), or alternatively,
just use another default encoding that handles 0x00 to 0xff. Sometimes
encoding problems in Python are driving me mad.
Currently I am using mbcs, but it's only available on Windows.
----------
components: Interpreter Core
messages: 71747
nosy: electronixtar
severity: normal
status: open
title: 'ascii' shoud be range(256) or just set another default encoding
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3648>
_______________________________________
From report at bugs.python.org Fri Aug 22 18:26:46 2008
From: report at bugs.python.org (Pascal Bach)
Date: Fri, 22 Aug 2008 16:26:46 +0000
Subject: [New-bugs-announce] [issue3649] IA5 Encoding should be in the
default encodings
In-Reply-To: <1219422406.98.0.675538880211.issue3649@psf.upfronthosting.co.za>
Message-ID: <1219422406.98.0.675538880211.issue3649@psf.upfronthosting.co.za>
New submission from Pascal Bach <pascal.bach at nextrem.ch>:
This encoding is used in the GSM standard it is a 7-bit encoding similar
to ASCII.
The encoding definition is found in:
Short Message Service Centre EMI - UCP Interface 4.6 Specification (p. 79)
as well as in:
[3GPP 23.038] 3GPP TS 23.038 Alphabets and language-specific information.
I think this encoding would be useful for other GSM specific use cases.
----------
components: Unicode
files: ia5.py
messages: 71755
nosy: pascal.bach
severity: normal
status: open
title: IA5 Encoding should be in the default encodings
type: feature request
versions: Python 2.5
Added file: http://bugs.python.org/file11214/ia5.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3649>
_______________________________________
From report at bugs.python.org Fri Aug 22 23:30:58 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 22 Aug 2008 21:30:58 +0000
Subject: [New-bugs-announce] [issue3650] Memory leak in bytes.split()
In-Reply-To: <1219440658.47.0.131327756004.issue3650@psf.upfronthosting.co.za>
Message-ID: <1219440658.47.0.131327756004.issue3650@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:
./python Lib/test/regrtest.py -R:: test_bytes
reveals a leak in py3k.
This is exactly the same as the one corrected by r65785 to bytearray.
(easy) patch attached, needs approval!
----------
files: bytes-split.patch
keywords: needs review, patch
messages: 71779
nosy: amaury.forgeotdarc
severity: normal
status: open
title: Memory leak in bytes.split()
versions: Python 3.0
Added file: http://bugs.python.org/file11222/bytes-split.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3650>
_______________________________________
From report at bugs.python.org Sat Aug 23 00:09:43 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 22 Aug 2008 22:09:43 +0000
Subject: [New-bugs-announce] [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:
version 3.0, any call to eval() leaks one reference:
>>> eval('1')
1
[42093 refs]
>>> eval('1')
1
[42094 refs]
>>> eval('1')
1
[42095 refs]
>>> eval('1')
1
[42096 refs]
----------
components: Interpreter Core
messages: 71783
nosy: amaury.forgeotdarc
priority: release blocker
severity: normal
status: open
title: eval() leaks 1 reference every time
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________
From report at bugs.python.org Sat Aug 23 03:13:10 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 23 Aug 2008 01:13:10 +0000
Subject: [New-bugs-announce] [issue3652] Remove DeprecationWarning in
_warnings about 'line'
In-Reply-To: <1219453990.4.0.253900549478.issue3652@psf.upfronthosting.co.za>
Message-ID: <1219453990.4.0.253900549478.issue3652@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
The DeprecationWarning introduced in Python 2.6/3.0 about the 'line'
argument for showwarning() can be removed in 2.7/3.1.
----------
assignee: brett.cannon
components: Library (Lib)
messages: 71797
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Remove DeprecationWarning in _warnings about 'line'
type: behavior
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3652>
_______________________________________
From report at bugs.python.org Sat Aug 23 18:55:55 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 23 Aug 2008 16:55:55 +0000
Subject: [New-bugs-announce] [issue3653] segfault calling sys.excepthook
with non-Exception argument
In-Reply-To: <1219510555.19.0.327680854391.issue3653@psf.upfronthosting.co.za>
Message-ID: <1219510555.19.0.327680854391.issue3653@psf.upfronthosting.co.za>
New submission from Daniel Diniz <ajaksu at gmail.com>:
Calling sys.excepthook(1,'1',1) crashes 3.0:
Python 3.0b3+ (py3k:65987, Aug 23 2008, 10:04:31)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys; sys.excepthook(1,'1',1)
Segmentation fault
gdb points at "PyException_GetTraceback at Objects/exceptions.c:265
265 Py_XINCREF(base_self->traceback);"
This was found by Fusil and Victor Stinner (haypo) sent me a patch (see
attachment).
Thanks bpeterson for triaging :)
PS: I also think that issue3643 should be targeted to 3.0, as the
underlying issue is the same, it would be an easy way to segfault
python3.0 and has a clean patch available.
----------
components: Interpreter Core
files: print_exception.patch
keywords: patch
messages: 71807
nosy: ajaksu2
severity: normal
status: open
title: segfault calling sys.excepthook with non-Exception argument
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file11229/print_exception.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3653>
_______________________________________
From report at bugs.python.org Sat Aug 23 22:28:18 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 23 Aug 2008 20:28:18 +0000
Subject: [New-bugs-announce] [issue3654] Duplicated test name in regex test
script
In-Reply-To: <1219523298.64.0.249650635001.issue3654@psf.upfronthosting.co.za>
Message-ID: <1219523298.64.0.249650635001.issue3654@psf.upfronthosting.co.za>
New submission from Matthew Barnett <python at mrabarnett.plus.com>:
The regex test script test_re.py has 2 tests called 'test_ignore_case'.
----------
components: Tests
messages: 71813
nosy: mrabarnett
severity: normal
status: open
title: Duplicated test name in regex test script
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3654>
_______________________________________
From report at bugs.python.org Sat Aug 23 23:11:02 2008
From: report at bugs.python.org (Pauli Virtanen)
Date: Sat, 23 Aug 2008 21:11:02 +0000
Subject: [New-bugs-announce] [issue3655] latexwriter: \footnotemark can only
take numbers as arguments
In-Reply-To: <1219525862.69.0.109867227566.issue3655@psf.upfronthosting.co.za>
Message-ID: <1219525862.69.0.109867227566.issue3655@psf.upfronthosting.co.za>
New submission from Pauli Virtanen <pav at iki.fi>:
LaTeXTranslator.visit_footnote_reference generates improper Latex if
the footnote marker given is not a number. This will result in a Latex
error if the RST document contains footnotes where the marker is not a
number.
The problem is that the Latex commands \footnotemark and \footnotetext
apparently expect their [] argument to always be a number.
For example:
\footnotemark[x]
results to error:
! Missing number, treated as zero.
<to be read again>
x
l.4733 ...\footnotemark[x]
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 71817
nosy: georg.brandl, pv
severity: normal
status: open
title: latexwriter: \footnotemark can only take numbers as arguments
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3655>
_______________________________________
From report at bugs.python.org Sun Aug 24 05:01:51 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 03:01:51 +0000
Subject: [New-bugs-announce] [issue3656] unicode encoding has lots of leaks
of bytes
In-Reply-To: <1219546911.7.0.779995437215.issue3656@psf.upfronthosting.co.za>
Message-ID: <1219546911.7.0.779995437215.issue3656@psf.upfronthosting.co.za>
New submission from Neal Norwitz <nnorwitz at gmail.com>:
Some of these leaks reported by valgrind are likely duplicates. I don't
know how many individual cases of these leaks there are.
11,119 bytes in 14 blocks are possibly lost in loss record 86 of 119
realloc (vg_replace_malloc.c:429)
_PyBytes_Resize (bytesobject.c:3159)
multibytecodec_encode (multibytecodec.c:536)
MultibyteCodec_Encode (multibytecodec.c:588)
PyObject_Call (abstract.c:2181)
PyEval_CallObjectWithKeywords (ceval.c:3283)
PyCodec_Encode (codecs.c:354)
PyUnicodeUCS2_AsEncodedString (unicodeobject.c:1347)
unicode_encode (unicodeobject.c:6682)
PyEval_EvalFrameEx (ceval.c:3403)
PyEval_EvalFrameEx (ceval.c:3491)
PyEval_EvalCodeEx (ceval.c:2840)
11,882 bytes in 15 blocks are possibly lost in loss record 87 of 119
malloc (vg_replace_malloc.c:207)
PyBytes_FromStringAndSize (bytesobject.c:87)
PyUnicodeUCS2_EncodeUTF8 (unicodeobject.c:2250)
utf_8_encode (_codecsmodule.c:719)
PyEval_EvalFrameEx (ceval.c:3403)
PyEval_EvalFrameEx (ceval.c:3491)
PyEval_EvalFrameEx (ceval.c:3491)
PyEval_EvalCodeEx (ceval.c:2840)
function_call (funcobject.c:628)
PyObject_Call (abstract.c:2181)
PyEval_EvalFrameEx (ceval.c:3704)
PyEval_EvalCodeEx (ceval.c:2840)
271,937 bytes in 437 blocks are definitely lost in loss record 108 of 119
malloc (vg_replace_malloc.c:207)
PyBytes_FromStringAndSize (bytesobject.c:87)
PyEval_EvalFrameEx (ceval.c:3403)
PyEval_EvalCodeEx (ceval.c:2840)
PyEval_EvalFrameEx (ceval.c:3501)
PyEval_EvalFrameEx (ceval.c:3491)
PyEval_EvalCodeEx (ceval.c:2840)
function_call (funcobject.c:628)
PyObject_Call (abstract.c:2181)
PyEval_EvalFrameEx (ceval.c:3704)
PyEval_EvalCodeEx (ceval.c:2840)
function_call (funcobject.c:628)
331,647 bytes in 277 blocks are definitely lost in loss record 111 of 119
realloc (vg_replace_malloc.c:429)
_PyBytes_Resize (bytesobject.c:3159)
PyUnicodeUCS2_EncodeUTF8 (unicodeobject.c:2256)
_PyUnicodeUCS2_AsDefaultEncodedString (unicodeobject.c:1412)
source_as_string (bltinmodule.c:504)
builtin_exec (bltinmodule.c:788)
PyEval_EvalFrameEx (ceval.c:3403)
PyEval_EvalCodeEx (ceval.c:2840)
PyEval_EvalFrameEx (ceval.c:3501)
PyEval_EvalCodeEx (ceval.c:2840)
PyEval_EvalCode (ceval.c:519)
builtin_exec (bltinmodule.c:785)
274,686 bytes in 446 blocks are definitely lost in loss record 114 of 128
malloc (vg_replace_malloc.c:207)
PyBytes_FromStringAndSize (bytesobject.c:87)
PyEval_EvalFrameEx (ceval.c:3403)
PyEval_EvalCodeEx (ceval.c:2840)
PyEval_EvalFrameEx (ceval.c:3501)
PyEval_EvalFrameEx (ceval.c:3491)
PyEval_EvalCodeEx (ceval.c:2840)
function_call (funcobject.c:628)
PyObject_Call (abstract.c:2181)
PyEval_EvalFrameEx (ceval.c:3704)
PyEval_EvalCodeEx (ceval.c:2840)
function_call (funcobject.c:628)
734,178 bytes in 293 blocks are definitely lost in loss record 121 of
realloc (vg_replace_malloc.c:429)
_PyBytes_Resize (bytesobject.c:3159)
PyUnicodeUCS2_EncodeUTF8 (unicodeobject.c:2256)
_PyUnicodeUCS2_AsDefaultEncodedString (unicodeobject.c:1412)
source_as_string (bltinmodule.c:504)
builtin_exec (bltinmodule.c:788)
PyEval_EvalFrameEx (ceval.c:3403)
PyEval_EvalCodeEx (ceval.c:2840)
PyEval_EvalFrameEx (ceval.c:3501)
PyEval_EvalCodeEx (ceval.c:2840)
PyEval_EvalCode (ceval.c:519)
builtin_exec (bltinmodule.c:785)
----------
components: Interpreter Core
messages: 71825
nosy: nnorwitz
priority: release blocker
severity: normal
status: open
title: unicode encoding has lots of leaks of bytes
type: resource usage
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3656>
_______________________________________
From report at bugs.python.org Sun Aug 24 09:01:48 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 07:01:48 +0000
Subject: [New-bugs-announce] [issue3657] pickle can pickle the wrong function
In-Reply-To: <1219561308.34.0.393729548724.issue3657@psf.upfronthosting.co.za>
Message-ID: <1219561308.34.0.393729548724.issue3657@psf.upfronthosting.co.za>
New submission from Neal Norwitz <nnorwitz at gmail.com>:
test_pickletools fails sporadically on at least two platforms I've seen.
http://www.python.org/dev/buildbot/all/x86%20gentoo%20trunk/builds/4120/step-test/0
http://www.python.org/dev/buildbot/all/ppc%20Debian%20unstable%20trunk/builds/1908/step-test/0
File
"/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/pickletools.py",
line ?, in pickletools.__test__.disassembler_test
Failed example:
dis(pickle.dumps(random.random, 0))
Expected:
0: c GLOBAL 'random random'
15: p PUT 0
18: . STOP
highest protocol among opcodes = 0
Got:
0: c GLOBAL 'bsddb.test.test_thread random'
31: p PUT 0
34: . STOP
highest protocol among opcodes = 0
**********************************************************************
1 items had failures:
1 of 25 in pickletools.__test__.disassembler_test
----------
components: Interpreter Core
messages: 71830
nosy: nnorwitz
priority: release blocker
severity: normal
status: open
title: pickle can pickle the wrong function
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3657>
_______________________________________
From report at bugs.python.org Sun Aug 24 15:10:29 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 24 Aug 2008 13:10:29 +0000
Subject: [New-bugs-announce] [issue3658] fix for pychecker property
complaints
In-Reply-To: <1219583429.18.0.798677952106.issue3658@psf.upfronthosting.co.za>
Message-ID: <1219583429.18.0.798677952106.issue3658@psf.upfronthosting.co.za>
New submission from Skip Montanaro <skip at pobox.com>:
Attached is a patch to fix some pychecker complaints Neal Norwitz
uncovered. All involved tests pass. Submitting patch simply because
we're past beta3.
----------
assignee: nnorwitz
components: Library (Lib)
files: pychecker.diff
keywords: easy, needs review, patch
messages: 71836
nosy: nnorwitz, skip.montanaro
severity: normal
status: open
title: fix for pychecker property complaints
versions: Python 2.6
Added file: http://bugs.python.org/file11233/pychecker.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3658>
_______________________________________
From report at bugs.python.org Sun Aug 24 18:11:55 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Aug 2008 16:11:55 +0000
Subject: [New-bugs-announce] [issue3659] sqlite: enumeration value
'TYPE_STRING' not handled in switch
In-Reply-To: <1219594315.65.0.145921400813.issue3659@psf.upfronthosting.co.za>
Message-ID: <1219594315.65.0.145921400813.issue3659@psf.upfronthosting.co.za>
New submission from Christian Heimes <lists at cheimes.de>:
I'm getting the compiler warning:
Modules/_sqlite/statement.c: In function
'pysqlite_statement_bind_parameter':
Modules/_sqlite/statement.c:133: warning: enumeration value
'TYPE_STRING' not handled in switch
I tried to make sense of the code before the warning. It looks like
TYPE_STRING isn't handled at all. The warning may be sign for a design
flaw or missing feature in the code.
----------
components: Extension Modules
messages: 71839
nosy: christian.heimes
priority: release blocker
severity: normal
status: open
title: sqlite: enumeration value 'TYPE_STRING' not handled in switch
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3659>
_______________________________________
From report at bugs.python.org Sun Aug 24 21:12:59 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 19:12:59 +0000
Subject: [New-bugs-announce] [issue3660] reference leaks in 3.0
In-Reply-To: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
Message-ID: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
New submission from Neal Norwitz <nnorwitz at gmail.com>:
Even after adding the current patch in http://bugs.python.org/issue3651
there are many reference leaks. This bug can be a placeholder for all
the reference leaks returned from:
./python ./Lib/test/regrtest.py -R 3:2 -uall,-bsddb
The current list is:
test_unittest leaked [124, 124] references, sum=248
test_array leaked [110, 110] references, sum=220
test_audioop leaked [75, 75] references, sum=150
test_binascii leaked [4, 4] references, sum=8
test_binhex leaked [4, 4] references, sum=8
test_codecs leaked [3, 3] references, sum=6
test_ctypes leaked [9, 9] references, sum=18
test_dbm leaked [194, 194] references, sum=388
test_dbm_gnu leaked [2, 2] references, sum=4
test_fcntl leaked [2, 2] references, sum=4
test_file leaked [8, 8] references, sum=16
test_fileio leaked [1, 1] references, sum=2
test_memoryio leaked [3, 3] references, sum=6
test_minidom leaked [5, 5] references, sum=10
test_mmap leaked [307, 307] references, sum=614
test_ossaudiodev leaked [2, 2] references, sum=4
test_pickle leaked [130, 130] references, sum=260
test_pickletools leaked [503, 503] references, sum=1006
test_pyexpat leaked [1, 1] references, sum=2
test_re leaked [4, 4] references, sum=8
test_site leaked [88, 88] references, sum=176
test_socket leaked [13, 13] references, sum=26
test_sqlite leaked [17, 17] references, sum=34
test_ssl leaked [82, 82] references, sum=164
test_struct leaked [5, 5] references, sum=10
test_unicode leaked [2, 2] references, sum=4
test_urllib2_localnet leaked [3, 3] references, sum=6
test_xmlrpc leaked [18, 18] references, sum=36
test_xmlrpc_net leaked [1, 1] references, sum=2
test_zlib leaked [10, 10] references, sum=20
----------
components: Interpreter Core
messages: 71851
nosy: nnorwitz
priority: release blocker
severity: normal
status: open
title: reference leaks in 3.0
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3660>
_______________________________________
From report at bugs.python.org Sun Aug 24 21:29:05 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 24 Aug 2008 19:29:05 +0000
Subject: [New-bugs-announce] [issue3661] sys.call_tracing segfaults
In-Reply-To: <1219606145.44.0.504923400807.issue3661@psf.upfronthosting.co.za>
Message-ID: <1219606145.44.0.504923400807.issue3661@psf.upfronthosting.co.za>
New submission from Daniel Diniz <ajaksu at gmail.com>:
The following code causes a segfault for me:
import sys; sys.call_tracing(type,2)
Running on:
Python 3.0b3+ (py3k:66015, Aug 24 2008, 16:21:19)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
gdb output:
[New Thread -1210857280 (LWP 8823)]
python: Objects/typeobject.c:1854: type_new: Assertion `args != ((void
*)0) && ((((((PyObject*)(args))->ob_type))->tp_flags & ((1L<<26))) !=
0)' failed.
Program received signal SIGABRT, Aborted.
[Switching to Thread -1210857280 (LWP 8823)]
0xffffe410 in __kernel_vsyscall ()
(gdb) backtrace
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7d67875 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7d69201 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0xb7d60b6e in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#4 0x0806e802 in type_new (metatype=0x81ba120, args=0x81fbda8,
kwds=0x0) at Objects/typeobject.c:1854
#5 0x0806bd0e in type_call (type=0x81ba120, args=0x81fbda8, kwds=0x0)
at Objects/typeobject.c:636
#6 0x08118ec5 in PyObject_Call (func=0x81ba120, arg=0x81fbda8, kw=0x0)
at Objects/abstract.c:2181
#7 0x080b2ac5 in _PyEval_CallTracing (func=0x81ba120, args=0x81fbda8)
at Python/ceval.c:3109
#8 0x080e7830 in sys_call_tracing (self=0xb7f073b4, args=0xb7a53bcc) at
Python/sysmodule.c:771
#9 0x081626b1 in PyCFunction_Call (func=0xb7f081bc, arg=0xb7a53bcc,
kw=0x0) at Objects/methodobject.c:81
#10 0x080b378f in call_function (pp_stack=0xbf9b6b84, oparg=2) at
Python/ceval.c:3403
#11 0x080ae8d2 in PyEval_EvalFrameEx (f=0x829bb14, throwflag=0) at
Python/ceval.c:2205
#12 0x080b1c24 in PyEval_EvalCodeEx (co=0xb7a9b9e8, globals=0xb7f0b5d4,
locals=0xb7f0b5d4, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at
Python/ceval.c:2840
#13 0x080a69cb in PyEval_EvalCode (co=0xb7a9b9e8, globals=0xb7f0b5d4,
locals=0xb7f0b5d4) at Python/ceval.c:519
#14 0x080df64b in run_mod (mod=0x82a2aa0, filename=0x819e3be "<string>",
globals=0xb7f0b5d4, locals=0xb7f0b5d4,
flags=0xbf9b6f60, arena=0x82b1060) at Python/pythonrun.c:1560
#15 0x080df393 in PyRun_StringFlags (str=0x8203fd8 "import sys;
sys.call_tracing(type,2)\n", start=257, globals=0xb7f0b5d4,
locals=0xb7f0b5d4, flags=0xbf9b6f60) at Python/pythonrun.c:1494
#16 0x080ddd37 in PyRun_SimpleStringFlags (command=0x8203fd8 "import
sys; sys.call_tracing(type,2)\n", flags=0xbf9b6f60)
at Python/pythonrun.c:1073
#17 0x080ef5ca in Py_Main (argc=2, argv=0xb7ede028) at Modules/main.c:533
#18 0x0805a689 in main (argc=2, argv=0xbf9b80b4) at ./Modules/python.c:57
----------
components: Interpreter Core
messages: 71853
nosy: ajaksu2
severity: normal
status: open
title: sys.call_tracing segfaults
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3661>
_______________________________________
From report at bugs.python.org Sun Aug 24 21:37:10 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 24 Aug 2008 19:37:10 +0000
Subject: [New-bugs-announce] [issue3662] _fileio._FileIO segfaults
In-Reply-To: <1219606630.97.0.430551791743.issue3662@psf.upfronthosting.co.za>
Message-ID: <1219606630.97.0.430551791743.issue3662@psf.upfronthosting.co.za>
New submission from Daniel Diniz <ajaksu at gmail.com>:
This snippet causes a segfault from fileio_init calling PyMem_Free:
import _fileio; _fileio._FileIO("1",0, 0 )
Found using Fusil
[Switching to Thread -1210070848 (LWP 10184)]
0x0805f5ff in _PyObject_DebugCheckAddress (p=0xb7b2f0e8) at
Objects/obmalloc.c:1461
1461 if (tail[i] != FORBIDDENBYTE) {
(gdb) backtrace
0 0x0805f5ff in _PyObject_DebugCheckAddress (p=0xb7b2f0e8) at
Objects/obmalloc.c:1461
1 0x0805f3c4 in _PyObject_DebugFree (p=0xb7b2f0e8) at
Objects/obmalloc.c:1375
2 0x0805de07 in PyMem_Free (p=0xb7b2f0e8) at Objects/object.c:1693
3 0x0810afa9 in fileio_init (oself=0xb7b18238, args=0xb7b815b4,
kwds=0x0) at ./Modules/_fileio.c:281
4 0x0806bdd0 in type_call (type=0x81d3760, args=0xb7b815b4, kwds=0x0)
at Objects/typeobject.c:650
5 0x08118ec5 in PyObject_Call (func=0x81d3760, arg=0xb7b815b4, kw=0x0)
at Objects/abstract.c:2181
6 0x080b42a5 in do_call (func=0x81d3760, pp_stack=0xbfab5c84, na=3,
nk=0) at Python/ceval.c:3616
7 0x080b394a in call_function (pp_stack=0xbfab5c84, oparg=3) at
Python/ceval.c:3426
8 0x080ae8d2 in PyEval_EvalFrameEx (f=0x829bb14, throwflag=0) at
Python/ceval.c:2205
9 0x080b1c24 in PyEval_EvalCodeEx (co=0xb7b5b9e8, globals=0xb7fcc5d4,
locals=0xb7fcc5d4, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at
Python/ceval.c:2840
10 0x080a69cb in PyEval_EvalCode (co=0xb7b5b9e8, globals=0xb7fcc5d4,
locals=0xb7fcc5d4) at Python/ceval.c:519
11 0x080df64b in run_mod (mod=0x82a2ac0, filename=0x819e3be "<string>",
globals=0xb7fcc5d4, locals=0xb7fcc5d4,
flags=0xbfab6060, arena=0x82b1060) at Python/pythonrun.c:1560
12 0x080df393 in PyRun_StringFlags (str=0x8203fd8 "import _fileio;
_fileio._FileIO('1',0, 0 )\n", start=257,
globals=0xb7fcc5d4, locals=0xb7fcc5d4, flags=0xbfab6060) at
Python/pythonrun.c:1494
13 0x080ddd37 in PyRun_SimpleStringFlags (command=0x8203fd8 "import
_fileio; _fileio._FileIO('1',0, 0 )\n",
flags=0xbfab6060) at Python/pythonrun.c:1073
14 0x080ef5ca in Py_Main (argc=2, argv=0xb7f9e028) at Modules/main.c:533
15 0x0805a689 in main (argc=2, argv=0xbfab71b4) at ./Modules/python.c:57
----------
messages: 71854
nosy: ajaksu2
severity: normal
status: open
title: _fileio._FileIO segfaults
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3662>
_______________________________________
From report at bugs.python.org Sun Aug 24 22:20:29 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 24 Aug 2008 20:20:29 +0000
Subject: [New-bugs-announce] [issue3663] Extra DECREF on syntax errors
In-Reply-To: <1219609229.98.0.504787107965.issue3663@psf.upfronthosting.co.za>
Message-ID: <1219609229.98.0.504787107965.issue3663@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:
The following output is very suspect: the total number of references
decreases!
Python 3.0b3+ (py3k, Aug 24 2008, 21:56:40) [MSC v.1500 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> f(1=1)
File "<stdin>", line 1
SyntaxError: keyword can't be an expression
[42055 refs]
>>> f(1=1)
File "<stdin>", line 1
SyntaxError: keyword can't be an expression
[42054 refs]
>>> f(1=1)
File "<stdin>", line 1
SyntaxError: keyword can't be an expression
[42053 refs]
>>> f(1=1)
File "<stdin>", line 1
SyntaxError: keyword can't be an expression
[42052 refs]
>>> f(1=1)
File "<stdin>", line 1
SyntaxError: keyword can't be an expression
[42051 refs]
>>> f(1=1)
File "<stdin>", line 1
SyntaxError: keyword can't be an expression
[42050 refs]
After several hundred statements, I got:
Fatal Python error: deallocating None
----------
messages: 71859
nosy: amaury.forgeotdarc
priority: deferred blocker
severity: normal
status: open
title: Extra DECREF on syntax errors
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3663>
_______________________________________
From report at bugs.python.org Sun Aug 24 22:26:35 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 24 Aug 2008 20:26:35 +0000
Subject: [New-bugs-announce] [issue3664] Pickler.dump from a badly
initialized Pickler segfaults
In-Reply-To: <1219609595.23.0.140986466622.issue3664@psf.upfronthosting.co.za>
Message-ID: <1219609595.23.0.140986466622.issue3664@psf.upfronthosting.co.za>
New submission from Daniel Diniz <ajaksu at gmail.com>:
This script segfaults:
##
import _pickle
obj = _pickle.Pickler(open("/bin/ls")) #can be open(__file__) for scripts
try: obj.__init__('pouet', 87)
except Exception as err: pass
obj.dump(0)
###
[Switching to Thread -1210775360 (LWP 19096)]
0xb79fbf91 in pickler_write (self=0xb7a2fe4c, s=0xbff441a1 "...", n=2)
at /home/ajaksu/py3k/Modules/_pickle.c:442
442 memcpy(self->write_buf + self->buf_size, s, n);
(gdb) backtrace
#0 0xb79fbf91 in pickler_write (self=0xb7a2fe4c, s=0xbff441a1 "...",
n=2) at /home/ajaksu/py3k/Modules/_pickle.c:442
#1 0xb7a00a8c in dump (self=0xb7a2fe4c, obj=0x81fbd78) at
/home/ajaksu/py3k/Modules/_pickle.c:2288
#2 0xb7a00bb8 in Pickler_dump (self=0xb7a2fe4c, args=0xb7b30034) at
/home/ajaksu/py3k/Modules/_pickle.c:2328
#3 0x081626b1 in PyCFunction_Call (func=0xb796c3ec, arg=0xb7b30034,
kw=0x0) at Objects/methodobject.c:81
#4 0x080b378f in call_function (pp_stack=0xbff442e4, oparg=1) at
Python/ceval.c:3403
#5 0x080ae8d2 in PyEval_EvalFrameEx (f=0x829bafc, throwflag=0) at
Python/ceval.c:2205
#6 0x080b1c24 in PyEval_EvalCodeEx (co=0xb7acf2c8, globals=0xb7a9a8f4,
locals=0xb7a9a8f4, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at
Python/ceval.c:2840
Found using Fusil.
----------
messages: 71860
nosy: ajaksu2
severity: normal
status: open
title: Pickler.dump from a badly initialized Pickler segfaults
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3664>
_______________________________________
From report at bugs.python.org Sun Aug 24 22:33:52 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 24 Aug 2008 20:33:52 +0000
Subject: [New-bugs-announce] [issue3665] Support \u and \U escapes in regexes
In-Reply-To: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za>
Message-ID: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za>
New submission from Georg Brandl <georg at python.org>:
Since \u and \U aren't interpolated in raw strings anymore, the re
module should support those escapes in addition to the \x and octal ones
it already does. Attached patch.
----------
components: Library (Lib)
files: re_unicode_escapes.diff
keywords: patch
messages: 71861
nosy: georg.brandl
priority: critical
severity: normal
status: open
title: Support \u and \U escapes in regexes
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11235/re_unicode_escapes.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3665>
_______________________________________
From report at bugs.python.org Sun Aug 24 22:39:12 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 24 Aug 2008 20:39:12 +0000
Subject: [New-bugs-announce] [issue3666] atexit.register with bad input
segfaults on exit
In-Reply-To: <1219610352.03.0.944854344602.issue3666@psf.upfronthosting.co.za>
Message-ID: <1219610352.03.0.944854344602.issue3666@psf.upfronthosting.co.za>
New submission from Daniel Diniz <ajaksu at gmail.com>:
The following crashes the interpreter on exit:
import sys, atexit; atexit.register(lambda: 1, 0, 0, (x for x in (1,2)),
0, 0); sys.exit()
Found with Fusil.
----------
messages: 71862
nosy: ajaksu2
severity: normal
status: open
title: atexit.register with bad input segfaults on exit
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3666>
_______________________________________
From report at bugs.python.org Sun Aug 24 22:55:00 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 24 Aug 2008 20:55:00 +0000
Subject: [New-bugs-announce] [issue3667] Reloading an extension module
always leaks
In-Reply-To: <1219611300.04.0.860759707504.issue3667@psf.upfronthosting.co.za>
Message-ID: <1219611300.04.0.860759707504.issue3667@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:
With python2.6, reloading extension modules does not always leak memory:
Python 2.6b2+ (trunk, Aug 19 2008, 23:45:24) [MSC v.1500 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
[34467 refs]
>>> import audioop; del sys.modules['audioop']
[34677 refs]
>>> import audioop; del sys.modules['audioop']
[34677 refs]
But with 3.0, reloading audioop leaks 60 references every time (seen in
test_unittest):
Python 3.0b3+ (py3k, Aug 24 2008, 21:56:40) [MSC v.1500 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
[42018 refs]
>>> import audioop; del sys.modules['audioop']
[42257 refs]
>>> import audioop; del sys.modules['audioop']
[42317 refs]
>>> import audioop; del sys.modules['audioop']
[42377 refs]
>>> import audioop; del sys.modules['audioop']
[42437 refs]
>>> import audioop; del sys.modules['audioop']
[42497 refs]
OK, many things cannot be reinitialized for C-written modules (static
variables &co), this is not the case for audioop. Furthermore, I thought
that the new module API was to support proper cleanup of modules
----------
messages: 71867
nosy: amaury.forgeotdarc
priority: release blocker
severity: normal
status: open
title: Reloading an extension module always leaks
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3667>
_______________________________________
From report at bugs.python.org Sun Aug 24 23:02:58 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 24 Aug 2008 21:02:58 +0000
Subject: [New-bugs-announce] [issue3668] "s*" argument parser marker leaks
memory
In-Reply-To: <1219611778.13.0.51285980437.issue3668@psf.upfronthosting.co.za>
Message-ID: <1219611778.13.0.51285980437.issue3668@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:
When PyArg_ParseTuple correctly parses a s* format, but raises an
exception afterwards (for a subsequent parameter), the user code will
not call PyBuffer_Release() and memory will leak.
Seen by "regrtest -R:: test_binascii"
For example:
>>> binascii.a2b_qp("", **{1:1})
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: keywords must be strings
[42278 refs]
>>> binascii.a2b_qp("", **{1:1})
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: keywords must be strings
[42279 refs]
>>> binascii.a2b_qp("", **{1:1})
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: keywords must be strings
[42280 refs]
The same pattern was correctly handled by the "et#" type (where the user
has to call PyMem_Free) with the help of a cleanup list (see the
addcleanup() function in getargs.c). (See issue501716)
----------
messages: 71870
nosy: amaury.forgeotdarc
priority: release blocker
severity: normal
status: open
title: "s*" argument parser marker leaks memory
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3668>
_______________________________________
From report at bugs.python.org Sun Aug 24 23:19:08 2008
From: report at bugs.python.org (Robert Lehmann)
Date: Sun, 24 Aug 2008 21:19:08 +0000
Subject: [New-bugs-announce] [issue3669] sqlite3.Connection.iterdump docs
pythonicity
In-Reply-To: <1219612748.54.0.0398165047003.issue3669@psf.upfronthosting.co.za>
Message-ID: <1219612748.54.0.0398165047003.issue3669@psf.upfronthosting.co.za>
New submission from Robert Lehmann <lehmannro at gmail.com>:
The `sqlite3` docs are a little unpythonic. When using `str.join` on
`Connection.iterdump`, the example in the docs manually unpacks the
generator using a LC. I propose this'd be improved.
Patch attached. Same applies to the py3k docs, it's just a few lines
above there.
----------
assignee: georg.brandl
components: Documentation
files: connection-iterdump.patch
keywords: patch
messages: 71875
nosy: georg.brandl, lehmannro
severity: normal
status: open
title: sqlite3.Connection.iterdump docs pythonicity
type: feature request
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11237/connection-iterdump.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3669>
_______________________________________
From report at bugs.python.org Sun Aug 24 23:50:31 2008
From: report at bugs.python.org (Kent Johnson)
Date: Sun, 24 Aug 2008 21:50:31 +0000
Subject: [New-bugs-announce] [issue3670] Reporting bugs - no such sections
In-Reply-To: <1219614631.74.0.871671228316.issue3670@psf.upfronthosting.co.za>
Message-ID: <1219614631.74.0.871671228316.issue3670@psf.upfronthosting.co.za>
New submission from Kent Johnson <kjohnson at users.sourceforge.net>:
The "Reporting Bugs" section of the Python 2.6b3 docs
http://docs.python.org/dev/bugs.html
says,
please use either the ?Add a comment? or the ?Suggest a change? features
of the relevant page in the most recent online documentation at
http://docs.python.org/.
I don't see either of these features in the 2.6 docs or the 2.5 docs at
the link.
----------
assignee: georg.brandl
components: Documentation
messages: 71885
nosy: georg.brandl, kjohnson
severity: normal
status: open
title: Reporting bugs - no such sections
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3670>
_______________________________________
From report at bugs.python.org Sun Aug 24 23:53:17 2008
From: report at bugs.python.org (Kent Johnson)
Date: Sun, 24 Aug 2008 21:53:17 +0000
Subject: [New-bugs-announce] [issue3671] What's New in 2.6 - corrections
In-Reply-To: <1219614797.59.0.814774740709.issue3671@psf.upfronthosting.co.za>
Message-ID: <1219614797.59.0.814774740709.issue3671@psf.upfronthosting.co.za>
New submission from Kent Johnson <kjohnson at users.sourceforge.net>:
These are minor corrections to the What's New in Python 2.6[b3] doc.
Note: the PEP references are to the headers in What's New, not the
actual PEPs
- PEP 371: The multiprocessing Package
- "apply() or apply_async, adding a single request, and map() or
map_async()" All four function names should link to the Pool
docs. Currently apply and map link to the docs for the builtins
of the same name; the other two don't link.
- PEP 3101: Advanced String Formatting
- In the first example, "uid = 'root'" is not needed
- PEP 3112: Byte Literals
- In the second example, the value of b should not have a space in
the middle, i.e. bytearray(b'\xe2\x87\xaf\xe3\x89\x84') instead
of bytearray(b'\xe2\x87\xaf \xe3\x89\x84')
- Other Language Changes
- next(*iterator*, [*default*]) - the asterisks are not needed
- "letting complex(repr(cmplx)) will now round-trip values" -> so
complex(repr(cmplx)) will now round-trip values
- Interpreter Changes
- "**encoding** or **encoding**:**errorhandler**" - Are the **
truly part of the syntax?
- New, Improved, and Deprecated Modules
- heapq.merge() returns a generator; the example should be
list(heapq.merge([1, 3, 5, 9], [2, 8, 16]))
- All the new itertools functions return iterators, not lists;
their examples should also be wrapped in list()
- itertools.product([1,2], repeat=3)) <- extra )
- shutil - "ignore_patterns() takes an arbitrary number of
glob-style patterns and will ignore any files and directories
that match this pattern." -> ignore_patterns() takes an arbitrary
number of glob-style patterns and returns a callable which will
ignore any files and directories that match this pattern.
- The future_builtins module
- I think all the ** are extraneous.
----------
assignee: georg.brandl
components: Documentation
messages: 71888
nosy: georg.brandl, kjohnson
severity: normal
status: open
title: What's New in 2.6 - corrections
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3671>
_______________________________________
From report at bugs.python.org Sun Aug 24 23:56:51 2008
From: report at bugs.python.org (Adam Olsen)
Date: Sun, 24 Aug 2008 21:56:51 +0000
Subject: [New-bugs-announce] [issue3672] Ill-formed surrogates not treated
as errors during encoding/decoding
In-Reply-To: <1219615011.7.0.279537729369.issue3672@psf.upfronthosting.co.za>
Message-ID: <1219615011.7.0.279537729369.issue3672@psf.upfronthosting.co.za>
New submission from Adam Olsen <rhamph at gmail.com>:
The Unicode FAQ makes it quite clear that any surrogates in UTF-8 or
UTF-32 should be treated as errors. Lone surrogates in UTF-16 should
probably be treated as errors too (but only during encoding/decoding;
unicode objects on UTF-16 builds should allow them to be created through
slicing).
http://unicode.org/faq/utf_bom.html#30
http://unicode.org/faq/utf_bom.html#42
http://unicode.org/faq/utf_bom.html#40
Lone surrogate in UTF-8 (effectively CESU-8):
>>> '\xED\xA0\x81'.decode('utf-8')
u'\ud801'
Surrogate pair in UTF-8:
>>> '\xED\xA0\x81\xED\xB0\x80'.decode('utf-8')
u'\ud801\udc00'
On a UTF-32 build, encoding a surrogate pair with UTF-16, then decoding
again will produce the proper non-surrogate scalar value. This has
security implications, although rare as characters outside the BMP are rare:
>>> u'\ud801\udc00'.encode('utf-16').decode('utf-16')
u'\U00010400'
Also on a UTF-32 build, decoding of a lone surrogate in UTF-16 fails
(correctly), but encoding one does not:
>>> u'\ud801'.encode('utf-16')
'\xff\xfe\x01\xd8'
I have gotten a report of a user decoding bad data using
x.decode('utf-8', 'replace'), then getting an error from Gtk+ when the
ill-formed surrogates reached it.
Fixing this would cause issue 3297 to blow up loudly, rather than silently.
----------
messages: 71889
nosy: Rhamphoryncus
severity: normal
status: open
title: Ill-formed surrogates not treated as errors during encoding/decoding
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3672>
_______________________________________
From report at bugs.python.org Mon Aug 25 05:42:22 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Mon, 25 Aug 2008 03:42:22 +0000
Subject: [New-bugs-announce] [issue3673] bsddb module leaks memory
In-Reply-To: <1219635742.08.0.574987175435.issue3673@psf.upfronthosting.co.za>
Message-ID: <1219635742.08.0.574987175435.issue3673@psf.upfronthosting.co.za>
New submission from Neal Norwitz <nnorwitz at gmail.com>:
The attached patch against 2.6 fixes the memory leaks reported against
the bsddb module. There are still (probably) reference leaks.
Jesus, it would be great if you can look at this before the release.
----------
assignee: jcea
components: Extension Modules
files: bsddb.patch
keywords: patch, patch
messages: 71907
nosy: jcea, nnorwitz
priority: critical
severity: normal
status: open
title: bsddb module leaks memory
type: resource usage
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11238/bsddb.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3673>
_______________________________________
From report at bugs.python.org Mon Aug 25 05:43:30 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 25 Aug 2008 03:43:30 +0000
Subject: [New-bugs-announce] [issue3674] test_dbm_ndbm skip is unexpected on
win32?
In-Reply-To: <1219635810.63.0.758747925367.issue3674@psf.upfronthosting.co.za>
Message-ID: <1219635810.63.0.758747925367.issue3674@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
Currently, I get following messege.
E:\PYTHON~1\py3k\Lib\test>py3k regrtest.py test_dbm_ndbm.py
test_dbm_ndbm
test_dbm_ndbm skipped -- No module named _dbm
1 test skipped:
test_dbm_ndbm
1 skip unexpected on win32:
test_dbm_ndbm
I don't know about dbm, but win32 buildbots are skiping this test, maybe
is this skip expected?
----------
components: Tests
files: regrtest.patch
keywords: patch
messages: 71908
nosy: ocean-city
severity: normal
status: open
title: test_dbm_ndbm skip is unexpected on win32?
versions: Python 3.0
Added file: http://bugs.python.org/file11239/regrtest.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3674>
_______________________________________
From report at bugs.python.org Mon Aug 25 14:15:44 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Mon, 25 Aug 2008 12:15:44 +0000
Subject: [New-bugs-announce] [issue3675] Python 2.6 can't read sets pickled
with Python 3.0
In-Reply-To: <1219666544.55.0.587307324969.issue3675@psf.upfronthosting.co.za>
Message-ID: <1219666544.55.0.587307324969.issue3675@psf.upfronthosting.co.za>
New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:
After pickling a set of ints with Python 3.0 and pickle protocol 2:
[hagenf at chage ~]$ python3.0
Python 3.0b3 (r30b3:65927, Aug 21 2008, 11:48:29)
[GCC 4.1.0 20060304 (Red Hat 4.1.0-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
>>> f = open("test", "wb")
>>> pickle.dump({1,2,3}, f, 2)
>>> f.close()
I get the following error when trying to read this with Python 2.6:
[hagenf at chage ~]$ python
Python 2.6b3 (r26b3:65922, Aug 21 2008, 11:42:25)
[GCC 4.1.0 20060304 (Red Hat 4.1.0-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
>>> f = open("test", "rb")
>>> pickle.load(f)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/MC/hagenf/local/lib/python2.6/pickle.py", line 1370, in load
return Unpickler(file).load()
File "/home/MC/hagenf/local/lib/python2.6/pickle.py", line 858, in load
dispatch[key](self)
File "/home/MC/hagenf/local/lib/python2.6/pickle.py", line 1090, in
load_global
klass = self.find_class(module, name)
File "/home/MC/hagenf/local/lib/python2.6/pickle.py", line 1124, in
find_class
__import__(module)
ImportError: No module named builtins
----------
components: Library (Lib)
messages: 71916
nosy: hagen
severity: normal
status: open
title: Python 2.6 can't read sets pickled with Python 3.0
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3675>
_______________________________________
From report at bugs.python.org Mon Aug 25 15:37:48 2008
From: report at bugs.python.org (Oren Tirosh)
Date: Mon, 25 Aug 2008 13:37:48 +0000
Subject: [New-bugs-announce] [issue3676] Obsolete references to PEP 291 in
py3k lib
In-Reply-To: <1219671468.62.0.218344277949.issue3676@psf.upfronthosting.co.za>
Message-ID: <1219671468.62.0.218344277949.issue3676@psf.upfronthosting.co.za>
New submission from Oren Tirosh <orent at hishome.net>:
The comments in the following modules contain references to PEP 291 or
to remaining compatible with version 2.x. However, they all include non
backward compatible python 3 syntax like "except x as y".
decimal.py
modulefinder.py
pkgutil.py
subprocess.py
----------
components: Library (Lib)
messages: 71921
nosy: orent
severity: normal
status: open
title: Obsolete references to PEP 291 in py3k lib
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3676>
_______________________________________
From report at bugs.python.org Mon Aug 25 17:00:28 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 25 Aug 2008 15:00:28 +0000
Subject: [New-bugs-announce] [issue3677] importing from UNC roots doesn't
work
In-Reply-To: <1219676428.29.0.220923454973.issue3677@psf.upfronthosting.co.za>
Message-ID: <1219676428.29.0.220923454973.issue3677@psf.upfronthosting.co.za>
New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:
When executing a script from a UNC path, e.g. //myhost/exports/a.py,
r"\\myhost\exports" gets prepended to sys.path. But it doesn't work.
This means that in a.py, "import b" will fail even though b.py is
present in the same directory.
The workaround is to manually prepend a backslass to the UNC path in
sys.path.
Note the related defect: http://bugs.python.org/issue954115
This intdoruces two functions for testing UNC paths, but it appears
that these functions are nowhere used!
----------
components: Interpreter Core
messages: 71932
nosy: krisvale
priority: normal
severity: normal
status: open
title: importing from UNC roots doesn't work
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3677>
_______________________________________
From report at bugs.python.org Mon Aug 25 22:28:09 2008
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 25 Aug 2008 20:28:09 +0000
Subject: [New-bugs-announce] [issue3678] Ignored LDFLAGS during linking
libpython$(VERSION).so
In-Reply-To: <1219696089.59.0.174711225307.issue3678@psf.upfronthosting.co.za>
Message-ID: <1219696089.59.0.174711225307.issue3678@psf.upfronthosting.co.za>
New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:
LDFLAGS are ignored during linking libpython$(VERSION).so.
(LDFLAGS are respected during linking $(BUILDPYTHON) and $(PGEN).)
----------
components: Build
files: python-respect_LDFLAGS.patch
keywords: patch
messages: 71952
nosy: Arfrever
severity: normal
status: open
title: Ignored LDFLAGS during linking libpython$(VERSION).so
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11253/python-respect_LDFLAGS.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3678>
_______________________________________
From report at bugs.python.org Mon Aug 25 22:37:16 2008
From: report at bugs.python.org (Toby Donaldson)
Date: Mon, 25 Aug 2008 20:37:16 +0000
Subject: [New-bugs-announce] [issue3679] pressing HOME key in IDLE editor
ends IDLE
In-Reply-To: <1219696636.82.0.798556102821.issue3679@psf.upfronthosting.co.za>
Message-ID: <1219696636.82.0.798556102821.issue3679@psf.upfronthosting.co.za>
New submission from Toby Donaldson <tjdonaldson at gmail.com>:
In IDLE 3.0b2, whenever I press the Home key in an IDLE editor window,
IDLE ends and all windows disappear.
----------
components: IDLE
messages: 71953
nosy: tjd
severity: normal
status: open
title: pressing HOME key in IDLE editor ends IDLE
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3679>
_______________________________________
From report at bugs.python.org Mon Aug 25 22:43:45 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Mon, 25 Aug 2008 20:43:45 +0000
Subject: [New-bugs-announce] [issue3680] Cycles with some iterator are
leaking.
In-Reply-To: <1219697025.92.0.458237292903.issue3680@psf.upfronthosting.co.za>
Message-ID: <1219697025.92.0.458237292903.issue3680@psf.upfronthosting.co.za>
New submission from Robert Schuppenies <robert.schuppenies at gmail.com>:
The dict, set, and deque iterators do not implement tp_traverse although
they reference container objects. This can lead to reference cycles
which will not be collected. The attached cycle.py script from Amaury
demonstrates the problem for dict iterators. The attached patch
addresses the issue for the above mentioned types. The method applied in
the demonstration script was used for test cases.
This is my first excursion into cyclic garbage collector
implementations, so please review carefully. Also, I am not sure about
tp_traverse for the deque type. Must the block member also be considered
or is the deque member sufficient?
Finally, do you consider this a show stopper?
----------
components: Interpreter Core
files: cycle.py
keywords: patch
messages: 71955
nosy: amaury.forgeotdarc, schuppenies
severity: normal
status: open
title: Cycles with some iterator are leaking.
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11254/cycle.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3680>
_______________________________________
From report at bugs.python.org Mon Aug 25 23:38:45 2008
From: report at bugs.python.org (Rahul Ghosh)
Date: Mon, 25 Aug 2008 21:38:45 +0000
Subject: [New-bugs-announce] [issue3681] Cannot read saved csv file in a
single run
In-Reply-To: <1219700325.8.0.911345891687.issue3681@psf.upfronthosting.co.za>
Message-ID: <1219700325.8.0.911345891687.issue3681@psf.upfronthosting.co.za>
New submission from Rahul Ghosh <rahul.ghosh at gmail.com>:
I am trying to save a csv file from a scope and then open it to post
process the data.
The file is getting created currectly, but when it tries to open the
csv file it complains about file not found. I am trying to do this in
a single run. If I rerun the code again, the file open function works
correctly.
It cannot see the newly created csv file till the python code stops
and I rerun it. How can I refresh the directory on the fly so that the
newly saved file is seen right away. I am on windows xp machine.
Appreciate your help.
Thanks.
----------
components: IDLE
messages: 71958
nosy: paul
severity: normal
status: open
title: Cannot read saved csv file in a single run
type: feature request
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3681>
_______________________________________
From report at bugs.python.org Tue Aug 26 02:03:48 2008
From: report at bugs.python.org (Damien Miller)
Date: Tue, 26 Aug 2008 00:03:48 +0000
Subject: [New-bugs-announce] [issue3682] test_math: math.log(-ninf) fails to
raise exception on OpenBSD
In-Reply-To: <1219709028.38.0.6245780787.issue3682@psf.upfronthosting.co.za>
Message-ID: <1219709028.38.0.6245780787.issue3682@psf.upfronthosting.co.za>
New submission from Damien Miller <djmdjm at users.sourceforge.net>:
Hi,
On OpenBSD 4.4, the test_math.py regression test fails with the following:
Traceback (most recent call last):
File "Lib/test/test_math.py", line 419, in testLog
self.assertRaises(ValueError, math.log, NINF)
AssertionError: ValueError not raised
This is because libm's log function does not return NaN when passed
-INFINITY. It returns -INFINITY and sets EDOM. This behaviour seems to
be permitted by the C99 spec (ISO/IEC 9899:1999):
> 7.12.1 Treatment of error conditions
> paragraph2:
> ... On a domain error, the function returns an implementation-defined
> value; if the integer expression math_errhandling & MATH_ERRNO is
> nonzero, the integer expression errno acquires the value EDOM;
in mathmodule.c:math_1() errno seems to be deliberately ignored when the
result is infinite. The attached patch modified math_1() to retain EDOM
errors for infinite results.
----------
components: Library (Lib)
files: patch-Modules_mathmodule_c
messages: 71963
nosy: djmdjm
severity: normal
status: open
title: test_math: math.log(-ninf) fails to raise exception on OpenBSD
versions: Python 2.6
Added file: http://bugs.python.org/file11258/patch-Modules_mathmodule_c
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3682>
_______________________________________
From report at bugs.python.org Tue Aug 26 03:35:13 2008
From: report at bugs.python.org (Damien Miller)
Date: Tue, 26 Aug 2008 01:35:13 +0000
Subject: [New-bugs-announce] [issue3683] compilation --without-threads fails
In-Reply-To: <1219714513.04.0.272760224775.issue3683@psf.upfronthosting.co.za>
Message-ID: <1219714513.04.0.272760224775.issue3683@psf.upfronthosting.co.za>
New submission from Damien Miller <djmdjm at users.sourceforge.net>:
Compilation with --without-threads fails with the following error. Patch
attached.
cc -c -fno-strict-aliasing -DNDEBUG -O2 -pipe
-DTHREAD_STACK_SIZE=0x20000 -fPIC -I. -IInclude -I./Include
-DPy_BUILD_CORE -o Python/import.o Python/import.c
Python/import.c: In function `PyImport_ImportModuleNoBlock':
Python/import.c:2037: error: `import_lock_thread' undeclared (first use
in this function)
Python/import.c:2037: error: (Each undeclared identifier is reported
only once
Python/import.c:2037: error: for each function it appears in.)
*** Error code 1
----------
components: Interpreter Core
files: patch-Python_import_c
messages: 71964
nosy: djmdjm
severity: normal
status: open
title: compilation --without-threads fails
versions: Python 2.6
Added file: http://bugs.python.org/file11259/patch-Python_import_c
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3683>
_______________________________________
From report at bugs.python.org Tue Aug 26 04:30:26 2008
From: report at bugs.python.org (Brodie Rao)
Date: Tue, 26 Aug 2008 02:30:26 +0000
Subject: [New-bugs-announce] [issue3684] traceback.format_exception_only()
misplaces the caret for certain SyntaxErrors
In-Reply-To: <1219717826.16.0.00104451287551.issue3684@psf.upfronthosting.co.za>
Message-ID: <1219717826.16.0.00104451287551.issue3684@psf.upfronthosting.co.za>
New submission from Brodie Rao <junk at dackz.net>:
>> +
File "<stdin>", line 1
+
^
SyntaxError: invalid syntax
>>> import sys
>>> import traceback
>>> traceback.print_exception(sys.last_type, sys.last_value, None)
File "<stdin>", line 1
+
^
SyntaxError: invalid syntax
>>> sys.last_value
SyntaxError('invalid syntax', ('<stdin>', 1, 2, '+\n'))
print_error_text() effectively ignores trailing newlines when placing
the caret, while traceback.format_exception_only() does not. For certain
syntax errors the offset reported is sometimes at the newline, as in the
case of a line of code that ends just with a plus sign (and in other
similar cases).
I'm attaching a patch for trunk that fixes this issue. I know it also
affects Python 2.5, and I'm sure it affects versions prior. I don't know
about Python 3.0.
----------
components: Library (Lib)
files: traceback-caret.patch
keywords: patch
messages: 71967
nosy: brodierao
severity: normal
status: open
title: traceback.format_exception_only() misplaces the caret for certain SyntaxErrors
type: behavior
Added file: http://bugs.python.org/file11260/traceback-caret.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3684>
_______________________________________
From report at bugs.python.org Tue Aug 26 08:52:34 2008
From: report at bugs.python.org (Henry Precheur)
Date: Tue, 26 Aug 2008 06:52:34 +0000
Subject: [New-bugs-announce] [issue3685] Crash while compiling Python 3000
in OpenBSD 4.4
In-Reply-To: <1219733554.71.0.0422559715732.issue3685@psf.upfronthosting.co.za>
Message-ID: <1219733554.71.0.0422559715732.issue3685@psf.upfronthosting.co.za>
New submission from Henry Precheur <henry at precheur.org>:
I tried to compile Python 3000 under OpenBSD and the compilation fails
because of a 'MemoryError':
Fatal Python error: can't create sys.path
object : MemoryError()
type : MemoryError
refcount: 4
address : 0x20abfbd08
lost sys.stderr
Abort trap (core dumped)
*** Error code 134
Stop in /home/henry/compile/py3k (line 410 of Makefile).
The command which fail is:
CC='gcc -pthread' LDSHARED='gcc -pthread -shared -fPIC ' OPT='-DNDEBUG
-g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build
Here is the backtrace:
(gdb) r -E ./setup.py build
Starting program: /home/henry/compile/py3k/python -E ./setup.py build
Fatal Python error: can't create sys.path
object : MemoryError()
type : MemoryError
refcount: 4
address : 0x2042d3d08
lost sys.stderr
Program received signal SIGABRT, Aborted.
[Switching to process 20134, thread 0x2015d4800]
0x000000020dc4432a in kill () from /usr/lib/libc.so.48.0
(gdb) bt full
#0 0x000000020dc4432a in kill () from /usr/lib/libc.so.48.0
No symbol table info available.
#1 0x000000020dc8b105 in abort () at /usr/src/lib/libc/stdlib/abort.c:68
p = (struct atexit *) 0x2064fd000
cleanup_called = 1
mask = 4294967263
#2 0x0000000000468a59 in Py_FatalError (msg=0x4ea6 <Address 0x4ea6 out
of bounds>)
at Python/pythonrun.c:1880
No locals.
#3 0x000000000046e06c in PySys_SetPath (path=0x4ea6) at
Python/sysmodule.c:1390
v = (PyObject *) 0x0
#4 0x0000000000466b8c in Py_InitializeEx (install_sigs=1) at
Python/pythonrun.c:213
interp = (PyInterpreterState *) 0x20f8af900
tstate = (PyThreadState *) 0x20adeda00
bimod = (PyObject *) 0x2042dc128
sysmod = (PyObject *) 0x2042dc128
pstderr = (PyObject *) 0x2042dc128
p = 0x0
codeset = 0x2042dc128 "\034"
#5 0x0000000000474136 in Py_Main (argc=4, argv=0x20f0331a0) at
Modules/main.c:497
r1 = 0
r2 = 0
c = 0
sts = 4
command = 0x0
filename = (wchar_t *) 0x0
module = 0x0
fp = (FILE *) 0x964e70
p = 0x6c05 <Address 0x6c05 out of bounds>
unbuffered = 0
skipfirstline = 0
stdin_is_interactive = 1
help = 0
version = 0
saw_unbuffered_flag = 0
cf = {cf_flags = 0}
#6 0x0000000000412866 in main (argc=4, argv=0x7f7ffffc7920) at
Modules/python.c:57
argsize = 140187732310304
argv_copy = (wchar_t **) 0x20f0331a0
argv_copy2 = (wchar_t **) 0x20f033140
i = 0
res = -231136
oldloc = 0x20e0c1b00 "C"
I also have core file. If you are interested mail me.
----------
messages: 71968
nosy: henry.precheur
severity: normal
status: open
title: Crash while compiling Python 3000 in OpenBSD 4.4
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3685>
_______________________________________
From report at bugs.python.org Tue Aug 26 10:32:33 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 26 Aug 2008 08:32:33 +0000
Subject: [New-bugs-announce] [issue3686] PKG-INFO file should differentiate
between authors and maintainers
In-Reply-To: <1219739553.56.0.760950139316.issue3686@psf.upfronthosting.co.za>
Message-ID: <1219739553.56.0.760950139316.issue3686@psf.upfronthosting.co.za>
New submission from Marc-Andre Lemburg <mal at egenix.com>:
The PKG-INFO file currently only provides an "Authors" field which is
mapped to the DistributionMetadata.get_contact() information.
However, the latter method is really meant to provide access to contact
information and not authorship, which is why it prefers the maintainer
infos over the actual author infos.
As a result, the maintainer can appear as author in the PKG-INFO file,
which is wrong.
Ideal would be to have both an "Author" and "Maintainer" field in the
PKG-FILE with 1-1 mappings to the setup() parameters.
----------
components: Distutils
messages: 71970
nosy: lemburg
priority: normal
severity: normal
status: open
title: PKG-INFO file should differentiate between authors and maintainers
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3686>
_______________________________________
From report at bugs.python.org Tue Aug 26 17:57:45 2008
From: report at bugs.python.org (Vincent Legoll)
Date: Tue, 26 Aug 2008 15:57:45 +0000
Subject: [New-bugs-announce] [issue3687] Popen() object stdout attribute
reassignment behaviour
In-Reply-To: <1219766265.83.0.904411616188.issue3687@psf.upfronthosting.co.za>
Message-ID: <1219766265.83.0.904411616188.issue3687@psf.upfronthosting.co.za>
New submission from Vincent Legoll <vincent.legoll at gmail.com>:
The subprocess.Popen() object documentation should indicate
that the stdout attribute should not be modified after
object construction. Because that won't work.
Or the attribute may be rendered read-only
>>> from subprocess import Popen, PIPE
>>> import sys, os
>>> p1 = Popen(["echo", "1"], stdout = PIPE)
>>> p2 = Popen(["cat"], stdin = p1.stdout, stderr = PIPE, stdout = PIPE)
>>> p2.stdout = sys.stdout
>>> print p2.communicate()
This blocks forever
----------
assignee: georg.brandl
components: Documentation
messages: 71983
nosy: georg.brandl, vincent.legoll
severity: normal
status: open
title: Popen() object stdout attribute reassignment behaviour
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3687>
_______________________________________
From report at bugs.python.org Tue Aug 26 19:06:02 2008
From: report at bugs.python.org (Dwayne Litzenberger)
Date: Tue, 26 Aug 2008 17:06:02 +0000
Subject: [New-bugs-announce] [issue3688] open() rejects bytes as filename
In-Reply-To: <1219770362.29.0.73954618161.issue3688@psf.upfronthosting.co.za>
Message-ID: <1219770362.29.0.73954618161.issue3688@psf.upfronthosting.co.za>
New submission from Dwayne Litzenberger <dlitz at dlitz.net>:
On Linux/ext3, filenames are stored natively as sequences of octets. On
Win32/NTFS, they are stored natively as sequences of Unicode code points.
In Python 2.x, the way to unambiguously open a particular file was to
pass the filename as a str object on Linux/ext3 and as a unicode object
on Win32/NTFS. os.listdir(".") would return every filename as a str
object, and os.listdir(u".") would return every filename as a unicode
object---based on the current locale settings---*except* for filenames
that couldn't be decoded that way.
Consider this bash script (executed on Linux under a UTF-8 locale):
export LC_CTYPE=en_CA.UTF-8 # requires the en_CA.UTF-8 locale to be
built
mkdir /tmp/foo
cd /tmp/foo
touch $'UTF-8 compatible filename\xc2\xa2'
touch $'UTF-8 incompatible filename\xc0'
Under Python 2.52, you get this:
>>> import os
>>> os.listdir(u".")
['UTF-8 incompatible filename\xc0', u'UTF-8 compatible filename\xa2']
>>> os.listdir(".")
['UTF-8 incompatible filename\xc0', 'UTF-8 compatible filename\xc2\xa2']
>>> [open(f, "r") for f in os.listdir(u".")]
[<open file 'UTF-8 incompatible filename?, mode 'r' at 0xb7cee578>,
<open file 'UTF-8 compatible filename?', mode 'r' at 0xb7cee6e0>]
Under Python 3.0b3, you get this:
>>> import os
>>> os.listdir(".")
[b'UTF-8 incompatible filename\xc0', 'UTF-8 compatible filename?']
>>> os.listdir(b".")
[b'UTF-8 incompatible filename\xc0', b'UTF-8 compatible filename\xc2\xa2']
>>> [open(f, "r") for f in os.listdir(".")]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 1, in <listcomp>
File "/home/dwon/python3.0b3/lib/python3.0/io.py", line 284, in __new__
return open(*args, **kwargs)
File "/home/dwon/python3.0b3/lib/python3.0/io.py", line 184, in open
raise TypeError("invalid file: %r" % file)
TypeError: invalid file: b'UTF-8 incompatible filename\xc0'
This behaviour of open() makes it impossible to write code that opens
arbitrarily-named files on Linux/ext3.
----------
components: Windows
messages: 71986
nosy: dlitz
severity: normal
status: open
title: open() rejects bytes as filename
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3688>
_______________________________________
From report at bugs.python.org Tue Aug 26 22:17:15 2008
From: report at bugs.python.org (Jeff Hall)
Date: Tue, 26 Aug 2008 20:17:15 +0000
Subject: [New-bugs-announce] [issue3689] reversed() not working as intended
on lists
In-Reply-To: <1219781835.24.0.0803885539905.issue3689@psf.upfronthosting.co.za>
Message-ID: <1219781835.24.0.0803885539905.issue3689@psf.upfronthosting.co.za>
New submission from Jeff Hall <hall.jeff at gmail.com>:
reversed() built in is not functioning correctly with list (specifically
with len() )
l = [1,2,3,4]
rl = reversed(l)
type(rl)
<type 'listreverseiterator'>
vs. strings and tuples which just return 'reverse' objects
listreverseiterators apparently have a len() defined that changes with
each .next() call
----------
messages: 71993
nosy: laxrulz777
severity: normal
status: open
title: reversed() not working as intended on lists
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3689>
_______________________________________
From report at bugs.python.org Tue Aug 26 22:52:03 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Tue, 26 Aug 2008 20:52:03 +0000
Subject: [New-bugs-announce] [issue3690] sys.getsizeof wrong for Py3k bool
objects
In-Reply-To: <1219783923.07.0.717830637968.issue3690@psf.upfronthosting.co.za>
Message-ID: <1219783923.07.0.717830637968.issue3690@psf.upfronthosting.co.za>
New submission from Robert Schuppenies <robert.schuppenies at gmail.com>:
sys.getsizeof returns wrong results for bool objects in Python 3000.
Although bool objects use the same datatype as long objects, they are
allocated differently. Thus, the inherited long_sizeof implementation is
incorrect. The applied patch addresses this issue.
----------
components: Interpreter Core
files: bool_sizeof.patch
keywords: patch
messages: 71996
nosy: schuppenies
severity: normal
status: open
title: sys.getsizeof wrong for Py3k bool objects
type: behavior
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file11264/bool_sizeof.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3690>
_______________________________________
From report at bugs.python.org Tue Aug 26 23:23:48 2008
From: report at bugs.python.org (Tim Hemming)
Date: Tue, 26 Aug 2008 21:23:48 +0000
Subject: [New-bugs-announce] [issue3691] Incorrect variable reference
In-Reply-To: <1219785828.16.0.340928364781.issue3691@psf.upfronthosting.co.za>
Message-ID: <1219785828.16.0.340928364781.issue3691@psf.upfronthosting.co.za>
New submission from Tim Hemming <timhemming at gmail.com>:
The following line is referencing a variable "d", but it should be "dict":
logging.warning("Protocol problem: %s", "connection reset", extra=d)
Page:- http://www.python.org/doc/2.5/lib/module-logging.html
----------
assignee: georg.brandl
components: Documentation
messages: 71998
nosy: georg.brandl, timh
severity: normal
status: open
title: Incorrect variable reference
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3691>
_______________________________________
From report at bugs.python.org Wed Aug 27 01:20:14 2008
From: report at bugs.python.org (kai zhu)
Date: Tue, 26 Aug 2008 23:20:14 +0000
Subject: [New-bugs-announce] [issue3692] improper scope in list
comprehension, when used in class declaration
In-Reply-To: <1219792814.12.0.663300668565.issue3692@psf.upfronthosting.co.za>
Message-ID: <1219792814.12.0.663300668565.issue3692@psf.upfronthosting.co.za>
New submission from kai zhu <davidbranniganz at gmail.com>:
in 3rd line, list comprehension tries to access class_attribute1 as a
global variable (code is valid in python 2.5)
>>> class Foo(object):
... class_attribute1 = 1
... class_attribute2 = [class_attribute1 for x in range(8)]
...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in Foo
File "<stdin>", line 3, in <listcomp>
NameError: global name 'class_attribute1' is not defined
----------
components: Interpreter Core
messages: 72002
nosy: kaizhu
severity: normal
status: open
title: improper scope in list comprehension, when used in class declaration
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3692>
_______________________________________
From report at bugs.python.org Wed Aug 27 03:51:36 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 27 Aug 2008 01:51:36 +0000
Subject: [New-bugs-announce] [issue3693] Obscure array.array error message
In-Reply-To: <1219801896.33.0.491668230509.issue3693@psf.upfronthosting.co.za>
Message-ID: <1219801896.33.0.491668230509.issue3693@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
In 2.5
>>> import array
>>> a = array.array('b', 'fox')
>>>
In 3.0
>>> import array
>>> a = array.array('b', 'fox')
Traceback (most recent call last):
File "<pyshell#2>", line 1, in <module>
a = array.array('b', 'fox')
TypeError: an integer is required
This puzzled me because an integer argument most certainly is not
allowed (one would raise other exceptions.) Then I realized that 'an
integer' here actually means 'an iterator producing integers' or more
exactly, 'an iterable whose iterator yields integers in the range
implied by the type code'. What I would like to see is something like
TypeError: for typecode 'b', the optional initializer must be an
iterable of 1 byte integers (such as bytes).
I would also like to see a minor change in the array and array.array
docstrings. Array.__doc__ lists the typecodes, array.array.__doc__
lists all the other info needed, so that help(array) gives everything
while help(array.array) omits the needed typecode info. So I would like
to see the typecode info moved to the class docstring with everything
else (and replaced by 'Defines one class: array') so help(array) and
help(array.array) would both give all needed info.
----------
components: Library (Lib)
messages: 72004
nosy: tjreedy
severity: normal
status: open
title: Obscure array.array error message
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3693>
_______________________________________
From report at bugs.python.org Wed Aug 27 06:29:52 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 27 Aug 2008 04:29:52 +0000
Subject: [New-bugs-announce] [issue3694] Undetected error in
_struct.pack_into
In-Reply-To: <1219811392.29.0.37826020023.issue3694@psf.upfronthosting.co.za>
Message-ID: <1219811392.29.0.37826020023.issue3694@psf.upfronthosting.co.za>
New submission from Daniel Diniz <ajaksu at gmail.com>:
The following code leads to XXX Undetected errors in debug builds of
trunk and 3.0:
import _struct
_struct.pack_into(b"8", bytearray(1), None)
Besides that, there's something fishy happening in non-debug builds:
2.6:
>>> _struct.pack_into(b"8", bytearray(1), None);
>>> _struct.pack_into(b"8", bytearray(1), None);
>>> import sys
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: an integer is required
3.0:
>>> _struct.pack_into(b"8", bytearray(1), None)
>>> _struct.pack_into(b"8", bytearray(1), None)
SystemError: Objects/longobject.c:433: bad argument to internal function
Found with Fusil.
----------
components: Extension Modules
messages: 72005
nosy: ajaksu2
severity: normal
status: open
title: Undetected error in _struct.pack_into
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3694>
_______________________________________
From report at bugs.python.org Wed Aug 27 06:36:49 2008
From: report at bugs.python.org (Michel Salim)
Date: Wed, 27 Aug 2008 04:36:49 +0000
Subject: [New-bugs-announce] [issue3695] Source tarball for Sphinx 0.4.3
missing
In-Reply-To: <1219811808.96.0.614683444156.issue3695@psf.upfronthosting.co.za>
Message-ID: <1219811808.96.0.614683444156.issue3695@psf.upfronthosting.co.za>
New submission from Michel Salim <salimma at fedoraproject.org>:
Sphinx's website stated that 0.4.3 has been released; however, the
download site only has 0.4.2. Is 0.4.2 still the latest version, or has
the source upload been accidentally omitted?
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 72006
nosy: georg.brandl, hircus
severity: normal
status: open
title: Source tarball for Sphinx 0.4.3 missing
type: feature request
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3695>
_______________________________________
From report at bugs.python.org Wed Aug 27 08:29:32 2008
From: report at bugs.python.org (Henry Precheur)
Date: Wed, 27 Aug 2008 06:29:32 +0000
Subject: [New-bugs-announce] [issue3696] Error parsing arguments on OpenBSD
<= 4.4
In-Reply-To: <1219818572.87.0.301585519224.issue3696@psf.upfronthosting.co.za>
Message-ID: <1219818572.87.0.301585519224.issue3696@psf.upfronthosting.co.za>
New submission from Henry Precheur <henry at precheur.org>:
The function mbstowcs is buggy on OpenBSD <= 4.4:
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/locale/multibyte_sb.c#rev1.7
Because of this the following command fails:
./python -E setup.py build
The attached patch fixes the problem.
----------
components: Build, Interpreter Core
files: fix_mbstowcs_openbsd.diff
keywords: patch
messages: 72010
nosy: henry.precheur
severity: normal
status: open
title: Error parsing arguments on OpenBSD <= 4.4
versions: Python 3.0
Added file: http://bugs.python.org/file11266/fix_mbstowcs_openbsd.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3696>
_______________________________________
From report at bugs.python.org Wed Aug 27 13:06:00 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Aug 2008 11:06:00 +0000
Subject: [New-bugs-announce] [issue3697] "Fatal Python error: Cannot recover
from stack overflow" on Windows buildbots
In-Reply-To: <1219835160.32.0.648492582618.issue3697@psf.upfronthosting.co.za>
Message-ID: <1219835160.32.0.648492582618.issue3697@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
This error appears more or less regularly on the Windows py3k buildbots.
Today it has appeared following my changes to isinstance() /
issubclass(), but it had already appeared before, e.g.
http://www.python.org/dev/buildbot/3.0.stable/x86%20XP-4%203.0/builds/1093/step-test/0
What puzzles me is that the said "Fatal Python error" is computed in a
deterministic way (from the overflowing of the recursion counter),
therefore it shouldn't occur randomly on only some selected platforms.
----------
components: Interpreter Core, Windows
messages: 72017
nosy: pitrou
priority: critical
severity: normal
status: open
title: "Fatal Python error: Cannot recover from stack overflow" on Windows buildbots
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3697>
_______________________________________
From report at bugs.python.org Wed Aug 27 14:30:00 2008
From: report at bugs.python.org (Guillaume Coffin)
Date: Wed, 27 Aug 2008 12:30:00 +0000
Subject: [New-bugs-announce] [issue3698] incompatible arguments in warning
formatting for idle
In-Reply-To: <1219840200.32.0.559754862412.issue3698@psf.upfronthosting.co.za>
Message-ID: <1219840200.32.0.559754862412.issue3698@psf.upfronthosting.co.za>
New submission from Guillaume Coffin <guillaumecoffin at gmail.com>:
In idle, the function idle_formatwarning_subproc overrides
warnings.formatwarning, however the latter in Python 2.6 is called from
warnings._show_warning with an additional "line" argument:
line 29, in _show_warning
file.write(formatwarning(message, category, filename, lineno, line))
whereas idle_formatwarning_subproc still only accepts 4 arguments. The
optional line argument should be added.
----------
components: IDLE
messages: 72023
nosy: gcoffin
severity: normal
status: open
title: incompatible arguments in warning formatting for idle
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3698>
_______________________________________
From report at bugs.python.org Wed Aug 27 14:53:27 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Aug 2008 12:53:27 +0000
Subject: [New-bugs-announce] [issue3699] test_bigaddrspace broken
In-Reply-To: <1219841607.12.0.523528748152.issue3699@psf.upfronthosting.co.za>
Message-ID: <1219841607.12.0.523528748152.issue3699@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
./python3 Lib/test/regrtest.py -v -M 2.1Gb test_bigaddrspace
test_bigaddrspace
test_concat (test.test_bigaddrspace.StrTest) ... ERROR
test_optimized_concat (test.test_bigaddrspace.StrTest) ... ERROR
======================================================================
ERROR: test_concat (test.test_bigaddrspace.StrTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/antoine/py3k/__svn__/Lib/test/support.py", line 697, in
wrapper
return f(self)
File "/home/antoine/py3k/__svn__/Lib/test/test_bigaddrspace.py", line
13, in test_concat
s1 = 'x' * MAX_Py_ssize_t
OverflowError: repeated string is too long
======================================================================
ERROR: test_optimized_concat (test.test_bigaddrspace.StrTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/antoine/py3k/__svn__/Lib/test/support.py", line 697, in
wrapper
return f(self)
File "/home/antoine/py3k/__svn__/Lib/test/test_bigaddrspace.py", line
18, in test_optimized_concat
x = 'x' * MAX_Py_ssize_t
OverflowError: repeated string is too long
----------------------------------------------------------------------
Ran 2 tests in 0.019s
----------
components: Tests
messages: 72025
nosy: pitrou
priority: high
severity: normal
status: open
title: test_bigaddrspace broken
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3699>
_______________________________________
From report at bugs.python.org Wed Aug 27 15:15:27 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Aug 2008 13:15:27 +0000
Subject: [New-bugs-announce] [issue3700] test_bigmem broken
In-Reply-To: <1219842927.03.0.0279927049136.issue3700@psf.upfronthosting.co.za>
Message-ID: <1219842927.03.0.0279927049136.issue3700@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
./python3 Lib/test/regrtest.py -v -M 2.1Gb test_bigmem
test_bigmem
[snip skipped tests]
======================================================================
ERROR: test_center_unicode (test.test_bigmem.StrTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/antoine/py3k/__svn__/Lib/test/support.py", line 682, in
wrapper
return f(self, maxsize)
File "/home/antoine/py3k/__svn__/Lib/test/test_bigmem.py", line 60, in
test_center_unicode
s = SUBSTR.center(size)
MemoryError
======================================================================
ERROR: test_encode_raw_unicode_escape (test.test_bigmem.StrTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/antoine/py3k/__svn__/Lib/test/support.py", line 682, in
wrapper
return f(self, maxsize)
File "/home/antoine/py3k/__svn__/Lib/test/test_bigmem.py", line 102,
in test_encode_raw_unicode_escape
return self.basic_encode_test(size, 'raw_unicode_escape')
File "/home/antoine/py3k/__svn__/Lib/test/test_bigmem.py", line 92, in
basic_encode_test
s = c * size
TypeError: can't multiply sequence by non-int of type 'float'
----------------------------------------------------------------------
Ran 88 tests in 0.225s
----------
components: Tests
messages: 72027
nosy: pitrou
priority: critical
severity: normal
status: open
title: test_bigmem broken
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3700>
_______________________________________
From report at bugs.python.org Wed Aug 27 15:59:44 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Aug 2008 13:59:44 +0000
Subject: [New-bugs-announce] [issue3701] test_ntpath.test_relpath fails when
launched from a different Windows drive
In-Reply-To: <1219845584.1.0.97722173565.issue3701@psf.upfronthosting.co.za>
Message-ID: <1219845584.1.0.97722173565.issue3701@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
C:\>z:PCbuild\python_d.exe z:Lib\test\regrtest.py -uall -v test_ntpath
test_ntpath
test_abspath (test.test_ntpath.TestNtpath) ... ok
test_commonprefix (test.test_ntpath.TestNtpath) ... ok
test_expandvars (test.test_ntpath.TestNtpath) ... ok
test_isabs (test.test_ntpath.TestNtpath) ... ok
test_join (test.test_ntpath.TestNtpath) ... ok
test_normpath (test.test_ntpath.TestNtpath) ... ok
test_relpath (test.test_ntpath.TestNtpath) ... ERROR
test_split (test.test_ntpath.TestNtpath) ... ok
test_splitdrive (test.test_ntpath.TestNtpath) ... ok
test_splitext (test.test_ntpath.TestNtpath) ... ok
test_splitunc (test.test_ntpath.TestNtpath) ... ok
======================================================================
ERROR: test_relpath (test.test_ntpath.TestNtpath)
----------------------------------------------------------------------
Traceback (most recent call last):
File "Z:\py3k\__svn__\lib\test\test_ntpath.py", line 171, in test_relpath
tester('ntpath.relpath("a")', 'a')
File "Z:\py3k\__svn__\lib\test\test_ntpath.py", line 13, in tester
%(str(fn), str(wantResult), str(gotResult)))
test.support.TestFailed: ntpath.relpath("a") should return: a but
returned: ..\a
----------
components: Library (Lib), Tests
messages: 72030
nosy: pitrou
priority: normal
severity: normal
status: open
title: test_ntpath.test_relpath fails when launched from a different Windows drive
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3701>
_______________________________________
From report at bugs.python.org Wed Aug 27 16:01:42 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Aug 2008 14:01:42 +0000
Subject: [New-bugs-announce] [issue3702] test_urllib2.test_trivial fails
when run from another Windows drive
In-Reply-To: <1219845702.82.0.0720973084926.issue3702@psf.upfronthosting.co.za>
Message-ID: <1219845702.82.0.0720973084926.issue3702@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
======================================================================
ERROR: test_trivial (test.test_urllib2.TrivialTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "Z:\py3k\__svn__\lib\urllib\request.py", line 1199, in
open_local_file
stats = os.stat(localfile)
WindowsError: [Error 3] Le chemin d'acc?s sp?cifi? est introuvable:
'\\py3k\\__s
vn__\\lib\\urllib\\request.py'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "Z:\py3k\__svn__\lib\test\test_urllib2.py", line 32, in test_trivial
f = urllib.request.urlopen(file_url)
File "Z:\py3k\__svn__\lib\urllib\request.py", line 122, in urlopen
return _opener.open(url, data, timeout)
File "Z:\py3k\__svn__\lib\urllib\request.py", line 359, in open
response = self._open(req, data)
File "Z:\py3k\__svn__\lib\urllib\request.py", line 377, in _open
'_open', req)
File "Z:\py3k\__svn__\lib\urllib\request.py", line 337, in _call_chain
result = func(*args)
File "Z:\py3k\__svn__\lib\urllib\request.py", line 1178, in file_open
return self.open_local_file(req)
File "Z:\py3k\__svn__\lib\urllib\request.py", line 1213, in
open_local_file
raise URLError(msg)
urllib.error.URLError: <urlopen error [Error 3] Le chemin d'acc?s
sp?cifi? est i
ntrouvable: '\\py3k\\__svn__\\lib\\urllib\\request.py'>
----------------------------------------------------------------------
----------
components: Library (Lib), Tests
messages: 72031
nosy: pitrou
priority: normal
severity: normal
status: open
title: test_urllib2.test_trivial fails when run from another Windows drive
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3702>
_______________________________________
From report at bugs.python.org Wed Aug 27 16:26:02 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Wed, 27 Aug 2008 14:26:02 +0000
Subject: [New-bugs-announce] [issue3703] open() on directory raises IOError
with unhelpful message
In-Reply-To: <1219847162.49.0.00805052293115.issue3703@psf.upfronthosting.co.za>
Message-ID: <1219847162.49.0.00805052293115.issue3703@psf.upfronthosting.co.za>
New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:
When trying to open a directory (on Linux), Python 2.x complained with
>>> open("local")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
IOError: [Errno 21] Is a directory
Python 3.0 however gives the rather unhelpful or even wrong
>>> open("local")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/MC/hagenf/local/lib/python3.0/io.py", line 284, in __new__
return open(*args, **kwargs)
File "/home/MC/hagenf/local/lib/python3.0/io.py", line 223, in open
closefd)
IOError: [Errno 0] Error: 'local'
----------
components: Library (Lib)
messages: 72033
nosy: hagen
severity: normal
status: open
title: open() on directory raises IOError with unhelpful message
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3703>
_______________________________________
From report at bugs.python.org Wed Aug 27 19:01:41 2008
From: report at bugs.python.org (Andy Kilpatrick)
Date: Wed, 27 Aug 2008 17:01:41 +0000
Subject: [New-bugs-announce] [issue3704] cookielib doesn't handle URLs with
/ in parameters
In-Reply-To: <1219856501.23.0.0473308500082.issue3704@psf.upfronthosting.co.za>
Message-ID: <1219856501.23.0.0473308500082.issue3704@psf.upfronthosting.co.za>
New submission from Andy Kilpatrick <andy.kilpatrick at metaswitch.com>:
cookielib doesn't handle URLs like "http://server/script?
err=/base/error.html&ok=/base/ok.html", as
CookieJar::_cookie_from_cookie_tuple uses rfind("/") to strip off the
end of the URL, returning "http://server/script?
err=/base/error.html&okc=/base" instead of "http://server/script".
My suggested fix (attached, line 1465-1468) is to first strip off
anything after "?" if present, then continue as with existing code.
----------
components: None
files: cookielib.py
messages: 72035
nosy: andyk
severity: normal
status: open
title: cookielib doesn't handle URLs with / in parameters
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file11271/cookielib.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3704>
_______________________________________
From report at bugs.python.org Wed Aug 27 20:05:41 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Aug 2008 18:05:41 +0000
Subject: [New-bugs-announce] [issue3705] py3k aborts if "-c" or "-m" is
given a non-ascii value
In-Reply-To: <1219860341.22.0.260624764626.issue3705@psf.upfronthosting.co.za>
Message-ID: <1219860341.22.0.260624764626.issue3705@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
The explanation is quite simple: in Py_Main, the arguments are converted
from wide to byte strings, but the required length of the byte string is
assumed equal to that of the wide string.
Which gives:
$ ./python -c "print('?')"
Fatal Python error: not enough memory to copy -c argument
Erreur de segmentation (core dumped)
$ ./python -m ?
Fatal Python error: not enough memory to copy -m argument
Erreur de segmentation (core dumped)
----------
messages: 72036
nosy: pitrou
severity: normal
status: open
title: py3k aborts if "-c" or "-m" is given a non-ascii value
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3705>
_______________________________________
From report at bugs.python.org Thu Aug 28 00:35:07 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 27 Aug 2008 22:35:07 +0000
Subject: [New-bugs-announce] [issue3706] Fix error message for wrong exec()
argument type
In-Reply-To: <1219876507.34.0.480466354345.issue3706@psf.upfronthosting.co.za>
Message-ID: <1219876507.34.0.480466354345.issue3706@psf.upfronthosting.co.za>
New submission from Georg Brandl <georg at python.org>:
Fixes exec() message that claims it supports file objects.
Also makes error messages from compile(), exec() and eval() more
concrete, and in the case of compile() more correct.
----------
files: bltin.diff
keywords: needs review, patch, patch
messages: 72046
nosy: georg.brandl
priority: normal
severity: normal
status: open
title: Fix error message for wrong exec() argument type
Added file: http://bugs.python.org/file11274/bltin.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3706>
_______________________________________
From report at bugs.python.org Thu Aug 28 00:44:19 2008
From: report at bugs.python.org (Mike Speciner)
Date: Wed, 27 Aug 2008 22:44:19 +0000
Subject: [New-bugs-announce] [issue3707] help('finally') behaves bizarrely
In-Reply-To: <1219877059.52.0.153636497207.issue3707@psf.upfronthosting.co.za>
Message-ID: <1219877059.52.0.153636497207.issue3707@psf.upfronthosting.co.za>
New submission from Mike Speciner <speciner_michael at emc.com>:
I'm running Python 3.0b2 (r30b2:65106, Jul 18 2008, 18:44:17) [MSC
v.1500 32 bit (Intel)] on win32.
Typing help('finally') loops, repeatedly typing the following two lines
File "C:\Python30\lib\pydoc.py", line 1777, in showtopic
return self.showtopic(target)
----------
messages: 72047
nosy: ms
severity: normal
status: open
title: help('finally') behaves bizarrely
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3707>
_______________________________________
From report at bugs.python.org Thu Aug 28 01:30:12 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 27 Aug 2008 23:30:12 +0000
Subject: [New-bugs-announce] [issue3708] os.urandom(1.1): infinite loop
In-Reply-To: <1219879812.7.0.142620771907.issue3708@psf.upfronthosting.co.za>
Message-ID: <1219879812.7.0.142620771907.issue3708@psf.upfronthosting.co.za>
New submission from Daniel Diniz <ajaksu at gmail.com>:
Calling os.urandom(1 + float(x)) ends in a infinite loop due to a naive
condition check:
while len(bytes) < n:
bytes += read(_urandomfd, n - len(bytes))
Trivial patch attached.
----------
components: Library (Lib)
files: urandom.diff
keywords: patch
messages: 72050
nosy: ajaksu2
severity: normal
status: open
title: os.urandom(1.1): infinite loop
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11277/urandom.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3708>
_______________________________________
From report at bugs.python.org Thu Aug 28 01:43:47 2008
From: report at bugs.python.org (Yang Zhao)
Date: Wed, 27 Aug 2008 23:43:47 +0000
Subject: [New-bugs-announce] [issue3709] BaseHTTPRequestHandler innefficient
when sending HTTP header
In-Reply-To: <1219880627.35.0.0859788959986.issue3709@psf.upfronthosting.co.za>
Message-ID: <1219880627.35.0.0859788959986.issue3709@psf.upfronthosting.co.za>
New submission from Yang Zhao <yang at yangman.ca>:
send_header() in BaseHTTPRequestHandler currently does a write to socket
every time send_header() is called. This results in excessive number of
TCP packets being regenerated. Ideally, as much of the HTTP packet is
buffered as possible, but, at minimum, the header should be sent with a
single write as there is a convenient end_header() functional available.
Behaviour is observed under python 2.5, but the related code looks
identical in SVN trunk.
Will contribute patch if request is deemed reasonable but no one is
available to work on it; I just need a few days.
----------
components: Library (Lib)
messages: 72051
nosy: yangman
severity: normal
status: open
title: BaseHTTPRequestHandler innefficient when sending HTTP header
type: performance
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3709>
_______________________________________
From report at bugs.python.org Thu Aug 28 02:09:04 2008
From: report at bugs.python.org (Ben Cottrell)
Date: Thu, 28 Aug 2008 00:09:04 +0000
Subject: [New-bugs-announce] [issue3710] Reference leak in thread._local
In-Reply-To: <1219882144.91.0.399316525956.issue3710@psf.upfronthosting.co.za>
Message-ID: <1219882144.91.0.399316525956.issue3710@psf.upfronthosting.co.za>
New submission from Ben Cottrell <tamino at wolfhut.org>:
This is a copy of a message I sent to the python-dev mailing list; it
was suggested in a reply that I file a bug for this issue. I'm
filing it against Python 2.5 because that's where I noticed it,
but it doesn't look like this code has changed much in trunk.
I noticed that thread._local can leak references if objects are
being stored inside the thread._local object whose destructors
might release the GIL.
The way this happens is that in Modules/threadmodule.c, in the
_ldict() function, it does things like this:
Py_CLEAR(self->dict);
Py_INCREF(ldict);
self->dict = ldict;
If the Py_CLEAR ends up taking away the last reference to an object
contained in the dict, and a thread context switch occurs during that
object's deallocation, then self->dict might not be NULL on return
from Py_CLEAR; another thread might have run, accessed something in
the same thread._local object, and caused self->dict to be set to
something else (and Py_INCREF'ed). So when we blindly do the
assignment into self->dict, we may be overwriting a valid reference,
and not properly Py_DECREFing it.
The recent change (revision 64601 to threadmodule.c) did not address
context switches during the Py_CLEAR call; only context switches
during tp_init.
The attached patch (against trunk) is my first attempt at fixing this.
It detects if self->dict has been set to something else after the
Py_CLEAR, and retries the Py_CLEAR (because _ldict really only cares
about installing the proper value of self->dict for the currently
running thread).
However, I am still uncomfortable about the fact that local_getattro
and local_setattro discard the value returned from _ldict, and instead
hand off control to the PyObject_Generic layer and trust that by the
time self->dict is actually used, it still has the correct value for
the current thread. Would it be better to, say, inline a copy of the
PyObject_Generic* functions inside local_getattro/local_setattro,
and force the operations to be done on the actual dict returned by
_ldict()?
----------
components: Extension Modules
files: threadmodule.c.diff
keywords: patch
messages: 72052
nosy: tamino
severity: normal
status: open
title: Reference leak in thread._local
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file11278/threadmodule.c.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3710>
_______________________________________
From report at bugs.python.org Thu Aug 28 11:31:57 2008
From: report at bugs.python.org (Gabriel Genellina)
Date: Thu, 28 Aug 2008 09:31:57 +0000
Subject: [New-bugs-announce] [issue3711] docs still say to use .dll for
compiled extensions
In-Reply-To: <1219915917.83.0.610729726797.issue3711@psf.upfronthosting.co.za>
Message-ID: <1219915917.83.0.610729726797.issue3711@psf.upfronthosting.co.za>
New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:
The "Extending and Embedding" document still says, in section "Building
C and C++ Extensions on Windows":
http://docs.python.org/dev/extending/windows.html#a-cookbook-approach
that a C extension may be called spam.dll or spam_d.dll
Since version 2.5 the file must be called spam.pyd or spam_d.pyd -
the .dll file extension isn't recognized anymore.
A proposed doc patch is attached.
----------
assignee: georg.brandl
components: Documentation
files: windows.diff
keywords: patch
messages: 72071
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: docs still say to use .dll for compiled extensions
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11284/windows.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3711>
_______________________________________
From report at bugs.python.org Thu Aug 28 13:01:49 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 28 Aug 2008 11:01:49 +0000
Subject: [New-bugs-announce] [issue3712] memoryview leaks references
In-Reply-To: <1219921309.45.0.320042219605.issue3712@psf.upfronthosting.co.za>
Message-ID: <1219921309.45.0.320042219605.issue3712@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:
Two problems with memoryview:
- The buffer interface of memoryview leaks a reference:
str(memoryview(b'text'), 'utf-8')
- memoryview does not implement tp_traverse and tp_clear, so reference
cycle cannot be collected, as with:
import gc
class MyBuf(bytes): pass
def f():
buf = MyBuf(b'abc')
m = memoryview(buf)
buf.m = m
gc.collect();gc.collect();gc.collect()
each call to f() leaks 6 references.
----------
messages: 72078
nosy: amaury.forgeotdarc
priority: release blocker
severity: normal
status: open
title: memoryview leaks references
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3712>
_______________________________________
From report at bugs.python.org Thu Aug 28 15:05:50 2008
From: report at bugs.python.org (Andy)
Date: Thu, 28 Aug 2008 13:05:50 +0000
Subject: [New-bugs-announce] [issue3713] Compile warning for
Objects/stringlib
In-Reply-To: <1219928750.12.0.164403487904.issue3713@psf.upfronthosting.co.za>
Message-ID: <1219928750.12.0.164403487904.issue3713@psf.upfronthosting.co.za>
New submission from Andy <flossyfriend at hotmail.com>:
Checked out the PY3K branch and built. Received a warning
about "characters after #ifdef ignored" from Objects/stringlib/find.h
the line in question is:
#ifdef STRINGLIB_WANT_CONTAINS_OBJ && !defined(FROM_BYTEARRAY)
Which is likely to mean that it will not do what is expected.
System is Ubuntu using GCC (otoh can't remember full compiler spec will
post in later)
Patch to follow that modifies the above line to:
#if defined(STRINGLIB_WANT_CONTAINS_OBJ) && !defined(FROM_BYTEARRAY)
and will change the comment on the closing #endif too.
hope component choice is correct
----------
components: Library (Lib)
messages: 72087
nosy: kirkshorts
severity: normal
status: open
title: Compile warning for Objects/stringlib
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3713>
_______________________________________
From report at bugs.python.org Thu Aug 28 16:10:21 2008
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Thu, 28 Aug 2008 14:10:21 +0000
Subject: [New-bugs-announce] [issue3714] nntplib module broken by str to
unicode conversion
In-Reply-To: <1219932621.55.0.439111476187.issue3714@psf.upfronthosting.co.za>
Message-ID: <1219932621.55.0.439111476187.issue3714@psf.upfronthosting.co.za>
New submission from Dmitry Vasiliev <dima at hlabs.spb.ru>:
The following commands fail badly:
>>> from nntplib import NNTP
>>> s = NNTP("free-text.usenetserver.com")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/py3k/Lib/nntplib.py", line 116, in __init__
self.welcome = self.getresp()
File "/py3k/Lib/nntplib.py", line 215, in getresp
resp = self.getline()
File "/py3k/Lib/nntplib.py", line 209, in getline
elif line[-1:] in CRLF: line = line[:-1]
TypeError: 'in <string>' requires string as left operand, not bytes
Actually there are many places in nntplib module which need to be
converted to bytes, or socket input/output values need to be converted
from/to str. I think API need to be updated to pass user defined
encoding at some stages. I can make a patch later if needed.
----------
components: Library (Lib)
messages: 72090
nosy: hdima
severity: normal
status: open
title: nntplib module broken by str to unicode conversion
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3714>
_______________________________________
From report at bugs.python.org Thu Aug 28 19:44:19 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Thu, 28 Aug 2008 17:44:19 +0000
Subject: [New-bugs-announce] [issue3715] hashlib's docstring throws
exception in pydoc
In-Reply-To: <1219945459.86.0.239279043076.issue3715@psf.upfronthosting.co.za>
Message-ID: <1219945459.86.0.239279043076.issue3715@psf.upfronthosting.co.za>
New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:
Hello,
I noticed that doing "pydoc3.0 hashlib" was throwing this exception:
Traceback (most recent call last):
File "/opt/local/bin/pydoc3.0", line 5, in <module>
pydoc.cli()
File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pydoc.py", line 2237, in cli
help.help(arg)
File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pydoc.py", line 1714, in help
elif request: doc(request, 'Help on %s:')
File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pydoc.py", line 1504, in doc
pager(render_doc(thing, title, forceload))
File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pydoc.py", line 1319, in pager
pager(text)
File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pydoc.py", line 1339, in <lambda>
return lambda text: pipepager(text, 'less')
File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pydoc.py", line 1360, in pipepager
pipe.write(text)
File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/io.py", line 1486, in write
b = encoder.encode(s)
File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/encodings/mac_roman.py", line 19, in encode
return codecs.charmap_encode(input,self.errors,encoding_table)[0]
This problem is coming from this block of text:
>>> import hashlib
>>> m = hashlib.md5()
>>> m.update(b"Nobody inspects")
>>> m.update(b" the spammish repetition")
>>> m.digest()
b'\xbbd\x9c\x83\xdd\x1e\xa5\xc9\xd9\xde\xc9\xa1\x8d\xf0\xff\xe9'
Specifically, the last line. It seems that pydoc is interpreting the
last line as a unicode string, and then when it tries to print it out on
my mac it errors out.
----------
components: Library (Lib)
messages: 72099
nosy: erickt
severity: normal
status: open
title: hashlib's docstring throws exception in pydoc
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3715>
_______________________________________
From report at bugs.python.org Thu Aug 28 21:21:29 2008
From: report at bugs.python.org (Alex7564)
Date: Thu, 28 Aug 2008 19:21:29 +0000
Subject: [New-bugs-announce] [issue3716] mistake in 3.4.2 Customizing
attribute access
In-Reply-To: <1219951289.51.0.953784677576.issue3716@psf.upfronthosting.co.za>
Message-ID: <1219951289.51.0.953784677576.issue3716@psf.upfronthosting.co.za>
New submission from Alex7564 <noname9968 at gmail.com>:
"Note that if the attribute is found through the normal mechanism,
__getattr__() is not called."
"...because otherwise __setattr__() would have no way to access other
attributes of the instance."
I think it should be __getattr__() instead of __setattr__()
----------
assignee: georg.brandl
components: Documentation
messages: 72105
nosy: Alex7564, georg.brandl
severity: normal
status: open
title: mistake in 3.4.2 Customizing attribute access
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3716>
_______________________________________
From report at bugs.python.org Thu Aug 28 22:48:51 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Thu, 28 Aug 2008 20:48:51 +0000
Subject: [New-bugs-announce] [issue3717] Py_InitModule* is still referenced
in docs
In-Reply-To: <1219956531.21.0.0850096773002.issue3717@psf.upfronthosting.co.za>
Message-ID: <1219956531.21.0.0850096773002.issue3717@psf.upfronthosting.co.za>
New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:
The docs still reference Py_InitModule*, which was removed in r64107.
Also, Demo/embed/demo.c still use Py_InitModule, and thus doesn't
compile.
----------
assignee: georg.brandl
components: Documentation
messages: 72111
nosy: erickt, georg.brandl
severity: normal
status: open
title: Py_InitModule* is still referenced in docs
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3717>
_______________________________________
From report at bugs.python.org Fri Aug 29 00:18:52 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 28 Aug 2008 22:18:52 +0000
Subject: [New-bugs-announce] [issue3718] environment variable MACHDEP and
python build system
In-Reply-To: <1219961932.19.0.767904041106.issue3718@psf.upfronthosting.co.za>
Message-ID: <1219961932.19.0.767904041106.issue3718@psf.upfronthosting.co.za>
New submission from Roumen Petrov <bugtrack at roumenpetrov.info>:
A) The reason to propose this patch following paragraph
from README:
--------------------
2) To set sys.platform to something sensible, pass the
following environment variable to the configure script:
MACHDEP=unicosmk
--------------------
The sentence above is not true in all cases. It don't state how to pass
as example
1) MACHDEP=abcd
export MACHDEP
./configure ....
2) MACHDEP=abcd ./configure ....
3) ./configure MACHDEP=abcd ....
The Makefile.pre.in contain dependency rule "Run the configure script":
that create config.status if file "configure" is changed as run the script.
>From above three samples for environment varaible passing only 3) will
save MACHDEP
into variable CONFIG_ARGS from generated Makefile.
The case 2) alwais lost it if config.status is created from makefile rule.
The case 1) will work only if developer don't remeber to set it every day.
B) The test case (note that MACHDEP isn't valid name!):
$ MACHDEP=linuxTEST ./configure --disable-ipv6
checking MACHDEP... linuxTEST
....
checking for build directories... done
configure: creating ./config.status
....
creating Makefile
Now lets see if "configure" script is changed:
$ touch configure; make
/bin/sh ./configure '--disable-ipv6'
checking MACHDEP... linux2 <-- MACHDEP is lost
....
checking for build directories... done
configure: creating ./config.status
config.status: creating Makefile.pre
config.status: creating Modules/Setup.config
config.status: creating pyconfig.h
config.status: pyconfig.h is unchanged
creating Modules/Setup
creating Modules/Setup.local
creating Makefile
CONFIG_FILES=Makefile.pre CONFIG_HEADERS= /bin/sh config.status
config.status: creating Makefile.pre
make -f Makefile.pre Makefile
make[1]: Entering directory `..../python-release25-maint'
make[1]: `Makefile' is up to date. <--- extra
make[1]: Leaving directory `..../python-release25-maint'
/bin/sh ./Modules/makesetup -c ./Modules/config.c.in \
....
The Makefile was updated, you may need to re-run make.
gcc -pthread -c ....
....
Note an extra attempt to create Makefile.
C) Next lets see after patch:
(the python configuration is the same as above):
$ touch configure; make
/bin/sh ./config.status --recheck
running CONFIG_SHELL=/bin/sh /bin/sh ./configure --disable-ipv6
MACHDEP=linuxTEST --no-create --no-recursion
checking MACHDEP... linuxTEST <-- MACHDEP is same as at
configure time
....
checking for build directories... done
configure: creating ./config.status
creating Modules/Setup
creating Modules/Setup.local
creating Makefile
/bin/sh ./config.status Makefile.pre
config.status: creating Makefile.pre
/bin/sh ./Modules/makesetup -c ./Modules/config.c.in \
-s Modules \
Modules/Setup.config \
Modules/Setup.local \
Modules/Setup
The Makefile was updated, you may need to re-run make.
gcc -pthread -c - ....
(ignore failure here since MACHDEP=linuxTEST is used only to show problem)
D) Rerefence (from autoconf textinfo sections):
4.8.5 Automatic Remaking
7.2 Setting Output Variables (see macro AC_ARG_VAR)
16 config.status Invocation
----------
components: Build
files: python-release25-MACHDEP.patch
keywords: patch
messages: 72116
nosy: rpetrov
severity: normal
status: open
title: environment variable MACHDEP and python build system
versions: Python 2.5
Added file: http://bugs.python.org/file11299/python-release25-MACHDEP.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3718>
_______________________________________
From report at bugs.python.org Fri Aug 29 02:40:13 2008
From: report at bugs.python.org (jfdp)
Date: Fri, 29 Aug 2008 00:40:13 +0000
Subject: [New-bugs-announce] [issue3719] platform.py: _syscmd_file() can't
handle target path with space or special shell character
In-Reply-To: <1219970413.68.0.263157286627.issue3719@psf.upfronthosting.co.za>
Message-ID: <1219970413.68.0.263157286627.issue3719@psf.upfronthosting.co.za>
New submission from jfdp <joe.dipol at sun.com>:
If you install python in a location which has a space
or shell character in the path then platform.platform()
will generate an error and/or fail to get all platform
information.
For example
$ pwd
/disk0/tmp/foobar(2)/python2.4/bin
$ ./python
Python 2.4.4 (#8, Apr 11 2008, 11:42:39) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> print platform.platform()
sh: syntax error at line 1: `(' unexpected
SunOS-5.10-sun4u-sparc-32bit
Note the error from 'sh' was well as the fact that "ELF"
is missing from the platform string. If you are in a path
with a space then it silently fails to identify "ELF".
The problem is in platform.py: _syscmd_file(target,default='')
in particular this line:
f = os.popen('file %s 2> /dev/null' % target)
This should be:
f = os.popen('file "%s" 2> /dev/null' % target)
Note the double quotes to protect the path from the shell.
I've examined the 2.5, 2.6 and 3.0 source and they all
have this same problem.
----------
components: Library (Lib)
messages: 72118
nosy: jfdp
severity: normal
status: open
title: platform.py: _syscmd_file() can't handle target path with space or special shell character
type: behavior
versions: Python 2.4
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3719>
_______________________________________
From report at bugs.python.org Fri Aug 29 06:19:32 2008
From: report at bugs.python.org (Gideon Smeding)
Date: Fri, 29 Aug 2008 04:19:32 +0000
Subject: [New-bugs-announce] [issue3720] segfault in for loop with evil
iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
New submission from Gideon Smeding <gideon.smeding at gmail.com>:
The attached example crashes python. The crash is caused by an evil
iterator that removes its own next function.
----------
files: baditerator.py
messages: 72119
nosy: gideon
severity: normal
status: open
title: segfault in for loop with evil iterator
type: crash
versions: Python 2.5, Python 3.0
Added file: http://bugs.python.org/file11300/baditerator.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________
From report at bugs.python.org Fri Aug 29 09:35:26 2008
From: report at bugs.python.org (ivo)
Date: Fri, 29 Aug 2008 07:35:26 +0000
Subject: [New-bugs-announce] [issue3721] invalid literal for int() with base
16: ''
In-Reply-To: <1219995326.44.0.411202937388.issue3721@psf.upfronthosting.co.za>
Message-ID: <1219995326.44.0.411202937388.issue3721@psf.upfronthosting.co.za>
New submission from ivo <xhomol11 at stud.fit.vutbr.cz>:
I tested metode urllib2.read() on 2000 web_pages and there was a
exception ValueError in only one case, here is short code:
import urllib2
req = urllib2.urlopen('http://www.peachbit.org/')
req.read()
Traceback (most recent call last):
File "httplib_bug.py", line 6, in <module>
req.read()
File "/usr/lib/python2.5/socket.py", line 291, in read
data = self._sock.recv(recv_size)
File "/usr/lib/python2.5/httplib.py", line 509, in read
return self._read_chunked(amt)
File "/usr/lib/python2.5/httplib.py", line 548, in _read_chunked
chunk_left = int(line, 16)
ValueError: invalid literal for int() with base 16: ''
----------
components: Installation
messages: 72121
nosy: xhomol11
severity: normal
status: open
title: invalid literal for int() with base 16: ''
type: crash
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3721>
_______________________________________
From report at bugs.python.org Fri Aug 29 12:54:13 2008
From: report at bugs.python.org (Chris Withers)
Date: Fri, 29 Aug 2008 10:54:13 +0000
Subject: [New-bugs-announce] [issue3722] print followed by exception eats
print with doctest
In-Reply-To: <1220007253.68.0.614144600028.issue3722@psf.upfronthosting.co.za>
Message-ID: <1220007253.68.0.614144600028.issue3722@psf.upfronthosting.co.za>
New submission from Chris Withers <chris at simplistix.co.uk>:
Here's an example from a python interpreter session:
Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> def test():
... print "hello"
... raise Exception()
...
>>> test()
hello
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 3, in test
Exception
Now, turning this into a doctests gives:
"""
>>> def test():
... print "hello"
... raise Exception()
...
>>> test()
hello
Traceback (most recent call last):
...
Exception
"""
Which when run gives:
**********************************************************************
File "C:\Projects\doctestbug.py", line 6, in __main__
Failed example:
test()
Exception raised:
Traceback (most recent call last):
File "C:\Python25\lib\doctest.py", line 1212, in __run
compileflags, 1) in test.globs
File "<doctest __main__[1]>", line 1, in <module>
test()
File "<doctest __main__[0]>", line 3, in test
raise Exception()
Exception
**********************************************************************
1 items had failures:
1 of 2 in __main__
***Test Failed*** 1 failures.
The problem is that the function prints output before raising the
exception. If I take the printed output away, the doctest passes fine.
However, especially with dummy fixtures common in doctests, that printed
output needs to be seen to test that things are happening as they should
prior to the exception being raised.
----------
components: Library (Lib)
messages: 72124
nosy: cjw296
severity: normal
status: open
title: print followed by exception eats print with doctest
versions: Python 2.4, Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3722>
_______________________________________
From report at bugs.python.org Fri Aug 29 14:11:10 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 29 Aug 2008 12:11:10 +0000
Subject: [New-bugs-announce] [issue3723] Py_NewInterpreter does not work
In-Reply-To: <1220011870.63.0.171875917127.issue3723@psf.upfronthosting.co.za>
Message-ID: <1220011870.63.0.171875917127.issue3723@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:
The example Demo/embed/importexc.c crashes, because Py_NewInterpreter
cannot reimport builtins and sys modules. This problem seems important
for embedding applications like mod_python, for example.
(the "import exceptions" statement does not work with python 3.0, but
replacing with e.g. "import types" does not change anything: the
interpreter is not correctly renewed)
I tried to put "-1" in the m_size structure of these modules, and they
seem to import correctly. However, "builtins" comes with its original
dictionary - without the standard exceptions.
I think that these modules should be made re-importable, with specific
functions.
Maybe two related problems:
- once you've done
del sys.modules['sys']
it's not possible to get it back, "import sys" raises an error...
- the usual trick to call sys.setdefaultencoding will not work, since it
needs to "imp.reload(sys)"
----------
components: Extension Modules
messages: 72127
nosy: amaury.forgeotdarc, loewis
priority: release blocker
severity: normal
status: open
title: Py_NewInterpreter does not work
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3723>
_______________________________________
From report at bugs.python.org Fri Aug 29 14:32:20 2008
From: report at bugs.python.org (Florian Mayer)
Date: Fri, 29 Aug 2008 12:32:20 +0000
Subject: [New-bugs-announce] [issue3724] math.log(x,
10) gives different result than math.log10(x)
In-Reply-To: <1220013140.94.0.0541204512227.issue3724@psf.upfronthosting.co.za>
Message-ID: <1220013140.94.0.0541204512227.issue3724@psf.upfronthosting.co.za>
New submission from Florian Mayer <flormayer at aim.com>:
I have found out that the result of math.log(x, 10) is slightly more
inaccurate than the one of math.log10(x). Probably the best example is
math.log(1000, 10) and math.log10(1000). I have attached a patch that
forces math.log to internally use log10 when it gets the base 10. Patch
is against revision 66056. Also adds 3 tests to test_math.py to test new
behaviour implemented.
----------
files: log.patch
keywords: patch
messages: 72129
nosy: segfaulthunter
severity: normal
status: open
title: math.log(x, 10) gives different result than math.log10(x)
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11302/log.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3724>
_______________________________________
From report at bugs.python.org Fri Aug 29 14:43:46 2008
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Fri, 29 Aug 2008 12:43:46 +0000
Subject: [New-bugs-announce] [issue3725] telnetlib module broken by str to
unicode conversion
In-Reply-To: <1220013826.6.0.647840298479.issue3725@psf.upfronthosting.co.za>
Message-ID: <1220013826.6.0.647840298479.issue3725@psf.upfronthosting.co.za>
New submission from Dmitry Vasiliev <dima at hlabs.spb.ru>:
Simple example:
>>> from telnetlib import Telnet
>>> t = Telnet("google.com", 80)
>>> t.write("GET / HTTP/1.1\r\n")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/py3k/Lib/telnetlib.py", line 280, in write
self.sock.sendall(buffer)
TypeError: sendall() argument 1 must be string or buffer, not str
>>> t.write(b"GET / HTTP/1.1\r\n")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/py3k/Lib/telnetlib.py", line 277, in write
if IAC in buffer:
TypeError: Type str doesn't support the buffer API
----------
components: Library (Lib)
messages: 72131
nosy: hdima
severity: normal
status: open
title: telnetlib module broken by str to unicode conversion
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3725>
_______________________________________
From report at bugs.python.org Fri Aug 29 15:44:43 2008
From: report at bugs.python.org (Will Maier)
Date: Fri, 29 Aug 2008 13:44:43 +0000
Subject: [New-bugs-announce] [issue3726] Allow ',
<whitespace>' delimiters in logging.config.fileConfig()
In-Reply-To: <1220017483.8.0.409780209991.issue3726@psf.upfronthosting.co.za>
Message-ID: <1220017483.8.0.409780209991.issue3726@psf.upfronthosting.co.za>
New submission from Will Maier <willmaier at ml1.net>:
Currently, logging.config.fileConfig() inconsistently handles lines like:
[handlers]
keys = spam, eggs
[formatters]
keys = foo, bar
It does, however, correctly handle the ', ' delimiter in the [loggers]
section. This is because the various _install_*() functions in
logging.config aren't consistent about whether (and when) or not they
strip whitespace when generating key names.
Though the stdlib documentation only includes examples in the [handlers]
and [formatters] section with ',' delimiters, it seems reasonable to
expect that logging.config.fileConfig() should handle ', '. The attached
test demonstrates the failure and suggests a solution.
Thanks!
whitespace
----------
components: Library (Lib)
files: logging.diff
keywords: patch
messages: 72134
nosy: wcmaier
severity: normal
status: open
title: Allow ',<whitespace>' delimiters in logging.config.fileConfig()
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11304/logging.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3726>
_______________________________________
From report at bugs.python.org Fri Aug 29 15:59:50 2008
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Fri, 29 Aug 2008 13:59:50 +0000
Subject: [New-bugs-announce] [issue3727] poplib module broken by str to
unicode conversion
In-Reply-To: <1220018390.31.0.482710376741.issue3727@psf.upfronthosting.co.za>
Message-ID: <1220018390.31.0.482710376741.issue3727@psf.upfronthosting.co.za>
New submission from Dmitry Vasiliev <dima at hlabs.spb.ru>:
Example:
>>> from poplib import POP3
>>> p = POP3("localhost")
>>> p.user("user")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/py3k/Lib/poplib.py", line 179, in user
return self._shortcmd('USER %s' % user)
File "/py3k/Lib/poplib.py", line 151, in _shortcmd
self._putcmd(line)
File "/py3k/Lib/poplib.py", line 98, in _putcmd
self._putline(line)
File "/py3k/Lib/poplib.py", line 91, in _putline
self.sock.sendall('%s%s' % (line, CRLF))
TypeError: sendall() argument 1 must be string or buffer, not str
>>> p.user(b"user")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/py3k/Lib/poplib.py", line 179, in user
return self._shortcmd('USER %s' % user)
File "/py3k/Lib/poplib.py", line 151, in _shortcmd
self._putcmd(line)
File "/py3k/Lib/poplib.py", line 98, in _putcmd
self._putline(line)
File "/py3k/Lib/poplib.py", line 91, in _putline
self.sock.sendall('%s%s' % (line, CRLF))
TypeError: sendall() argument 1 must be string or buffer, not str
----------
components: Library (Lib)
messages: 72136
nosy: hdima
severity: normal
status: open
title: poplib module broken by str to unicode conversion
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3727>
_______________________________________
From report at bugs.python.org Fri Aug 29 16:05:33 2008
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Fri, 29 Aug 2008 14:05:33 +0000
Subject: [New-bugs-announce] [issue3728] imaplib module broken by str to
unicode conversion
In-Reply-To: <1220018733.89.0.00018896297534.issue3728@psf.upfronthosting.co.za>
Message-ID: <1220018733.89.0.00018896297534.issue3728@psf.upfronthosting.co.za>
New submission from Dmitry Vasiliev <dima at hlabs.spb.ru>:
Example:
>>> from imaplib import IMAP4
>>> m = IMAP4("localhost")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/py3k/Lib/imaplib.py", line 185, in __init__
self.welcome = self._get_response()
File "/py3k/Lib/imaplib.py", line 912, in _get_response
if self._match(self.tagre, resp):
File "/py3k/Lib/imaplib.py", line 1021, in _match
self.mo = cre.match(s)
TypeError: can't use a string pattern on a bytes-like object
>>> m = IMAP4(b"localhost")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/py3k/Lib/imaplib.py", line 185, in __init__
self.welcome = self._get_response()
File "/py3k/Lib/imaplib.py", line 912, in _get_response
if self._match(self.tagre, resp):
File "/py3k/Lib/imaplib.py", line 1021, in _match
self.mo = cre.match(s)
TypeError: can't use a string pattern on a bytes-like object
----------
components: Library (Lib)
messages: 72137
nosy: hdima
severity: normal
status: open
title: imaplib module broken by str to unicode conversion
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3728>
_______________________________________
From report at bugs.python.org Fri Aug 29 16:59:08 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Fri, 29 Aug 2008 14:59:08 +0000
Subject: [New-bugs-announce] [issue3729] SystemError on calling len() if
__len__() doesn't return an int
In-Reply-To: <1220021948.65.0.928639960663.issue3729@psf.upfronthosting.co.za>
Message-ID: <1220021948.65.0.928639960663.issue3729@psf.upfronthosting.co.za>
New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:
On Python 3.0:
>>> class C:
... def __len__(self): return "foo"
...
>>> len(C())
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
SystemError: Objects/longobject.c:433: bad argument to internal function
On Python 2.6 the behaviour is different for old and new-style classes,
with old-style classes giving the more informative error message and
both accepting (and truncating) floats.
I attached a patch for Python 3.0, which refuses everything but ints and
gives an informative error message. Or does the float-truncating
behaviour of Python 2.x need to be preserved?
----------
files: len_check.diff
keywords: patch
messages: 72141
nosy: hagen
severity: normal
status: open
title: SystemError on calling len() if __len__() doesn't return an int
type: behavior
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11307/len_check.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3729>
_______________________________________
From report at bugs.python.org Fri Aug 29 17:54:00 2008
From: report at bugs.python.org (Chris AtLee)
Date: Fri, 29 Aug 2008 15:54:00 +0000
Subject: [New-bugs-announce] [issue3730] Update BaseHTTPServer docs
In-Reply-To: <1220025240.46.0.36189752437.issue3730@psf.upfronthosting.co.za>
Message-ID: <1220025240.46.0.36189752437.issue3730@psf.upfronthosting.co.za>
New submission from Chris AtLee <chris at atlee.ca>:
The BaseHTTPServer docs don't mention 'server' as an instance variable
in the instance variable section for BaseHTTPRequestHandler. It is
mentioned in passing a few paragraphs above in the BaseHTTPServer class
description, but it's too easy to miss there.
Index: basehttpserver.rst
===================================================================
--- basehttpserver.rst (revision 66056)
+++ basehttpserver.rst (working copy)
@@ -68,6 +68,11 @@
address.
+ .. attribute:: server
+
+ Contains the server instance.
+
+
.. attribute:: command
Contains the command (request type). For example, ``'GET'``.
----------
assignee: georg.brandl
components: Documentation
messages: 72144
nosy: catlee, georg.brandl
severity: normal
status: open
title: Update BaseHTTPServer docs
type: feature request
versions: Python 2.5, Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3730>
_______________________________________
From report at bugs.python.org Fri Aug 29 20:15:37 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Aug 2008 18:15:37 +0000
Subject: [New-bugs-announce] [issue3731] import warning in multiprocessing
In-Reply-To: <1220033737.12.0.773803477499.issue3731@psf.upfronthosting.co.za>
Message-ID: <1220033737.12.0.773803477499.issue3731@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
I get the following when running "regrtest.py -uall" under trunk:
/home/antoine/cpython/__svn__/Lib/multiprocessing/__init__.py:82:
ImportWarning: Not importing directory
'/home/antoine/cpython/__svn__/Modules/_multiprocessing': missing
__init__.py
import _multiprocessing
----------
assignee: jnoller
components: Library (Lib)
messages: 72146
nosy: jnoller, pitrou
severity: normal
status: open
title: import warning in multiprocessing
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3731>
_______________________________________
From report at bugs.python.org Fri Aug 29 23:42:51 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 29 Aug 2008 21:42:51 +0000
Subject: [New-bugs-announce] [issue3732] bdist_msi gives a deprecation
warning when run with Python 2.6
In-Reply-To: <1220046171.76.0.656167236844.issue3732@psf.upfronthosting.co.za>
Message-ID: <1220046171.76.0.656167236844.issue3732@psf.upfronthosting.co.za>
New submission from Marc-Andre Lemburg <mal at egenix.com>:
d:\Python26\lib\msilib\__init__.py:5: DeprecationWarning: the sets
module is deprecated
import sets, os, string, re
Should be easy to solve.
----------
components: Distutils, Library (Lib)
keywords: easy
messages: 72162
nosy: lemburg
priority: normal
severity: normal
status: open
title: bdist_msi gives a deprecation warning when run with Python 2.6
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3732>
_______________________________________
From report at bugs.python.org Sat Aug 30 00:16:53 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 29 Aug 2008 22:16:53 +0000
Subject: [New-bugs-announce] [issue3733] Adding bin and Scripts folder into
PATH
In-Reply-To: <1220048213.92.0.257328590649.issue3733@psf.upfronthosting.co.za>
Message-ID: <1220048213.92.0.257328590649.issue3733@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
The windows installer could add two entries in the PATH environment
variable. This would make "Python.exe" and other binaries available from
the command prompt without having to change PATH manually.
----------
components: Installation, Windows
messages: 72167
nosy: mhammond, tarek
severity: normal
status: open
title: Adding bin and Scripts folder into PATH
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3733>
_______________________________________
From report at bugs.python.org Sat Aug 30 00:39:10 2008
From: report at bugs.python.org (Blair)
Date: Fri, 29 Aug 2008 22:39:10 +0000
Subject: [New-bugs-announce] [issue3734] subclassing complex
In-Reply-To: <1220049550.4.0.0881969750537.issue3734@psf.upfronthosting.co.za>
Message-ID: <1220049550.4.0.0881969750537.issue3734@psf.upfronthosting.co.za>
New submission from Blair <bidihall at gmail.com>:
The following is quoted from the Python docs (ref/numeric_types):
"Note: If the right operand's type is a subclass of the left operand's
type and that subclass provides the reflected method for the operation,
this method will be called before the left operand's non-reflected
method. This behavior allows subclasses to override their ancestors'
operations."
My issue is that the built-in complex type does not respect this rule
(see code below). Note that float can be subclassed using the method
shown below and the rules are applied correctly. It seems that it is
only a problem with complex.
class xcomplex( complex ):
def __new__(cls,*args,**kwargs):
return complex.__new__(cls,*args,**kwargs)
def __coerce__(self,other):
t = complex.__coerce__(self,other)
try:
return (self,xcomplex(t[1]))
except TypeError:
return t
def __add__(self,x):
return xcomplex( complex.__add__(self,x) )
def __radd__(self,x):
return xcomplex( complex.__radd__(self,x) )
print type(z + xz) # gives complex when xcomplex is required
----------
components: None
messages: 72169
nosy: gumtree
severity: normal
status: open
title: subclassing complex
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3734>
_______________________________________
From report at bugs.python.org Sat Aug 30 01:07:09 2008
From: report at bugs.python.org (David Decotigny)
Date: Fri, 29 Aug 2008 23:07:09 +0000
Subject: [New-bugs-announce] [issue3735] allow multiple threads to
efficiently send the same requests to a processing.Pool
without incurring duplicate processing
In-Reply-To: <1220051229.09.0.236623735385.issue3735@psf.upfronthosting.co.za>
Message-ID: <1220051229.09.0.236623735385.issue3735@psf.upfronthosting.co.za>
New submission from David Decotigny <com.d2 at free.fr>:
I posted a recipe on ASPN: http://code.activestate.com/recipes/576462/
and Jesse, cheerleader for the inclusion of (multi)processing into
python-core, suggested that it could be interesting to add this feature
to the next pythons.
This recipe is based on version 0.52 of the standalone "processing"
package, and allows to avoid redundancy when multiple threads send the
same job requests to a pool of background worker processes. The recipe
details the why and the how.
Some notes on the implementation, though:
- There is a "Begin/End workaround" section in the code, which aims at
working around a limitation of processing 0.52 (see comments and
docstring for details). I sent issue #014431 to the issue tracker for
processing on berlios, this would allow to get rid of this workaround
- Read my comment #2 to the recipe, dealing with my thoughts of using
weak references
----------
components: Library (Lib)
messages: 72170
nosy: DavidDecotigny, jnoller
severity: normal
status: open
title: allow multiple threads to efficiently send the same requests to a processing.Pool without incurring duplicate processing
type: feature request
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3735>
_______________________________________
From report at bugs.python.org Sat Aug 30 01:46:30 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 29 Aug 2008 23:46:30 +0000
Subject: [New-bugs-announce] [issue3736] super is a built-in type
In-Reply-To: <1220053590.33.0.225544185622.issue3736@psf.upfronthosting.co.za>
Message-ID: <1220053590.33.0.225544185622.issue3736@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
super is defined as a built-in function
http://docs.python.org/dev/library/functions.html
but it is a type, shouldn't it be replaced ?
----------
assignee: georg.brandl
components: Documentation
messages: 72174
nosy: georg.brandl, tarek
severity: normal
status: open
title: super is a built-in type
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3736>
_______________________________________
From report at bugs.python.org Sat Aug 30 12:47:48 2008
From: report at bugs.python.org (zouzhile)
Date: Sat, 30 Aug 2008 10:47:48 +0000
Subject: [New-bugs-announce] [issue3737] An error in Python Library
Reference document
In-Reply-To: <1220093268.84.0.83776548912.issue3737@psf.upfronthosting.co.za>
Message-ID: <1220093268.84.0.83776548912.issue3737@psf.upfronthosting.co.za>
New submission from zouzhile <zouzhile at 126.com>:
Problem:
On the page http://docs.python.org/lib/built-in-funcs.html, there is a
description about "super(type[,object-or-type])": Return the superclass
of type. If the second argument....
This is NOT true. it will actually return an instance of the type
"super", instead of "the superclass of type".
Suggested fix:
Return a new instance of the type "super".
----------
messages: 72190
nosy: zouzhile
severity: normal
status: open
title: An error in Python Library Reference document
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3737>
_______________________________________
From report at bugs.python.org Sat Aug 30 14:13:13 2008
From: report at bugs.python.org (David W. Lambert)
Date: Sat, 30 Aug 2008 12:13:13 +0000
Subject: [New-bugs-announce] [issue3738] logging.Handler.close does something
In-Reply-To: <1220098393.98.0.954077896829.issue3738@psf.upfronthosting.co.za>
Message-ID: <1220098393.98.0.954077896829.issue3738@psf.upfronthosting.co.za>
New submission from David W. Lambert <lambertdw at corning.com>:
Library documents claim that logging.Handler.close does nothing, but
the source code shows otherwise---it removes itself from the internal
handler list. The error propagates treelike through the subclasses.
(I found references to close in stream handler flush and
NTEventLogHandler subclass). I have source code for version 2.5, but
the error likely persists through version 3.03b which
http://docs.python.org/dev/3.0/library/logging.html#logging.StreamHandl
er
claims,
"flush()?
Flushes the stream by calling its flush() method. Note that the close
() method is inherited from Handler and so does nothing, so an
explicit flush() call may be needed at times.
"
Actually, before reading the manual I tried
del streamHandler_on_my_stream; my_stream.close()
which didn't fix subsequent log messages that reported failure writing
to closed stream. __del__ might be easy to implement, and it seems
natural.
Respectfully,
Dave
----------
assignee: georg.brandl
components: Documentation
messages: 72191
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: logging.Handler.close does something
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3738>
_______________________________________
From report at bugs.python.org Sat Aug 30 15:05:19 2008
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Sat, 30 Aug 2008 13:05:19 +0000
Subject: [New-bugs-announce] [issue3739] unicode-internal encoder reports
wrong length
In-Reply-To: <1220101519.85.0.185335325424.issue3739@psf.upfronthosting.co.za>
Message-ID: <1220101519.85.0.185335325424.issue3739@psf.upfronthosting.co.za>
New submission from Walter D?rwald <walter at livinglogic.de>:
The encoder for the "unicode-internal" codec reports the wrong length:
Python 3.0b3+ (py3k, Aug 30 2008, 11:55:21)
[GCC 4.0.1 (Apple Inc. build 5484)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import codecs
>>> codecs.getencoder("unicode-internal")("a")
(b'a\x00', 2)
I would have expected it to output:
(b'a\x00', 1)
instead.
----------
components: Unicode
messages: 72193
nosy: doerwalter
severity: normal
status: open
title: unicode-internal encoder reports wrong length
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3739>
_______________________________________
From report at bugs.python.org Sat Aug 30 17:14:49 2008
From: report at bugs.python.org (Paul Pogonyshev)
Date: Sat, 30 Aug 2008 15:14:49 +0000
Subject: [New-bugs-announce] [issue3740] PEP 3121 --- module state is not
nul-initalized as claimed in the PEP
In-Reply-To: <1220109289.56.0.0975805859845.issue3740@psf.upfronthosting.co.za>
Message-ID: <1220109289.56.0.0975805859845.issue3740@psf.upfronthosting.co.za>
New submission from Paul Pogonyshev <pogonyshev at gmx.net>:
PEP 3121 states that: "The module state will be null-initialized". This
is not the case as it seems.
----------
components: Interpreter Core
messages: 72197
nosy: _doublep
severity: normal
status: open
title: PEP 3121 --- module state is not nul-initalized as claimed in the PEP
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3740>
_______________________________________
From report at bugs.python.org Sun Aug 31 19:14:49 2008
From: report at bugs.python.org (Paul "TBBle" Hampson)
Date: Sun, 31 Aug 2008 17:14:49 +0000
Subject: [New-bugs-announce] [issue3741] DISTUTILS_USE_SDK set causes
msvc9compiler.py to raise an exception
In-Reply-To: <1220202889.53.0.172923498575.issue3741@psf.upfronthosting.co.za>
Message-ID: <1220202889.53.0.172923498575.issue3741@psf.upfronthosting.co.za>
New submission from Paul "TBBle" Hampson <Paul.Hampson at Pobox.com>:
Basically, if DISTUTILS_USE_SDK is set in the environment and an
extension is attempted to be built from within the Windows SDK shell
(ie. MSSdk is set in the environment as well), msvc9compiler.py will
raise an exception due to a reference to the undefined self.__paths in
MSVCCompiler.find_exe class, called from MSVCCompiler.initialize.
self.__paths is used both in MSVCCompiler.find_exe and further through
MSVCCompiler.initialize, but only exists if the else branch of the
DISTUTILS_USE_SDK if/else is taken.
I've attached a patch which trivially fixes this by setting self.__paths
to [] before the test for DISTUTILS_USE_SDK.
However, the use of MSVCCompiler.find_exe in this test might be wrong.
Short of raising an exception, MSVCCompiler.find_exe always returns what
it is supplied if it can't find anything better. So testing the truth of
this value is likely incorrect. (I assume that find_exe used to return a
false value if the requested program could not be found on the path or
in self.__paths[]...)
If the find_exe is removed from the test, then the setting of
self.__paths can be done inside the if branch, paralleling the else branch.
----------
components: Distutils
files: msvc9compiler-windowssdk.diff
keywords: patch
messages: 72209
nosy: TBBle
severity: normal
status: open
title: DISTUTILS_USE_SDK set causes msvc9compiler.py to raise an exception
versions: Python 2.6
Added file: http://bugs.python.org/file11318/msvc9compiler-windowssdk.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3741>
_______________________________________
From report at bugs.python.org Sun Aug 31 21:43:38 2008
From: report at bugs.python.org (Joshua Logan)
Date: Sun, 31 Aug 2008 19:43:38 +0000
Subject: [New-bugs-announce] [issue3742] Parsing XML file with Unicode
characters causes problem
In-Reply-To: <1220211818.88.0.0185485536041.issue3742@psf.upfronthosting.co.za>
Message-ID: <1220211818.88.0.0185485536041.issue3742@psf.upfronthosting.co.za>
New submission from Joshua Logan <dear.jay.logan at gmail.com>:
Python 3.0b2 will not parse the XML file located at
http://rubyquiz.com/SongLibrary.xml.gz
It complains of a UnicodeEncodeError
'charmap' codec can't encode character '\xc8' in position 45: ch
aracter maps to <undefined>
I included a sample program, just in case I was doing something wrong
while coding.
Python 3.0b2 (r30b2:65106, Jul 18 2008, 18:44:17) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
----------
components: XML
files: read_song_xml.py
messages: 72211
nosy: jaylogan
severity: normal
status: open
title: Parsing XML file with Unicode characters causes problem
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11319/read_song_xml.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3742>
_______________________________________
From report at bugs.python.org Sun Aug 31 22:40:38 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 31 Aug 2008 20:40:38 +0000
Subject: [New-bugs-announce] [issue3743] PY_FORMAT_SIZE_T is not for
PyString_FromFormat
In-Reply-To: <1220215238.73.0.721040984863.issue3743@psf.upfronthosting.co.za>
Message-ID: <1220215238.73.0.721040984863.issue3743@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:
test_deque fails on win64 buildbot:
AssertionError: 'deque([7, 8, 9], maxlen=%Id)' != 'deque([7, 8, 9],
maxlen=3)'
A PY_FORMAT_SIZE_T format is incorrectly used with PyUnicode_FromFormat.
The correct format here is "%zd". PY_FORMAT_SIZE_T should be reserved
for the OS printf routines, PyOS_snprintf, PySys_WriteStderr.
The attached patch replaces
"%" PY_FORMAT_SIZE_T "%d"
with
"%zd"
----------
files: fromformat.patch
keywords: patch
messages: 72212
nosy: amaury.forgeotdarc
severity: normal
status: open
title: PY_FORMAT_SIZE_T is not for PyString_FromFormat
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11320/fromformat.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3743>
_______________________________________