From report at bugs.python.org Sun Nov 1 17:46:28 2009
From: report at bugs.python.org (Avihu Turzion)
Date: Sun, 01 Nov 2009 16:46:28 +0000
Subject: [New-bugs-announce] [issue7246] getpass crashes when several
returns are in stdin before getpass was called
In-Reply-To: <1257093988.16.0.063739997235.issue7246@psf.upfronthosting.co.za>
Message-ID: <1257093988.16.0.063739997235.issue7246@psf.upfronthosting.co.za>
New submission from Avihu Turzion <avihu at turzion.com>:
When I have the following code:
blah.py
=======
import getpass
nothing = getpass.getpass("blah:")
And I run it like so:
>>> sleep 5
./blah.py <return>
<return>
(I write the ./blah.py and returns while the sleep occurs)
I get the following stack-trace:
Traceback (most recent call last):
File "./xuy.py", line 5, in <module>
nothing = getpass.getpass("XUY:")
File "/usr/local/lib/python2.6/getpass.py", line 81, in unix_getpass
stream.write('\n')
IOError: [Errno 29] Illegal seek
close failed in file object destructor:
IOError: [Errno 29] Illegal seek
This error occurs only when getpass is called with 2 or more returns in
the buffer. One return will not reveal the problem.
Running this code with strace shows clearly that the seek problem is
because that for return in the buffer it tries to seek back. 2 returns
will cause it to seek -2. 7 returns will cause it to seek -7.
This problem was introduced in python 2.6, and is maintained throughout
the minor releases of python 2.6 - 2.6.4. It doesn't appear in python
2.5 and before, and it doesn't appear in python 3.
Doing sys.stdin.flush() doesn't resolve this issue.
----------
components: IO
messages: 94791
nosy: avihu
severity: normal
status: open
title: getpass crashes when several returns are in stdin before getpass was called
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7246>
_______________________________________
From report at bugs.python.org Sun Nov 1 20:20:06 2009
From: report at bugs.python.org (Tony Vroon)
Date: Sun, 01 Nov 2009 19:20:06 +0000
Subject: [New-bugs-announce] [issue7247] 2.6.4 fnctl test failure
In-Reply-To: <1257103206.04.0.134413608226.issue7247@psf.upfronthosting.co.za>
Message-ID: <1257103206.04.0.134413608226.issue7247@psf.upfronthosting.co.za>
New submission from Tony Vroon <tony at vroon.org>:
chainsaw at prometheus ~ $ python2.6
/usr/lib64/python2.6/test/test_fcntl.py
struct.pack:
'\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
test_fcntl_64_bit (__main__.TestFcntl) ... ERROR
test_fcntl_file_descriptor (__main__.TestFcntl) ... ok
test_fcntl_fileno (__main__.TestFcntl) ... Status from fcntl with
O_NONBLOCK:
0
String from fcntl with F_SETLKW:
'\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
ok
======================================================================
ERROR: test_fcntl_64_bit (__main__.TestFcntl)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/usr/lib64/python2.6/test/test_fcntl.py", line 96, in
test_fcntl_64_bit
fcntl.fcntl(fd, cmd, flags)
IOError: [Errno 22] Invalid argument
----------------------------------------------------------------------
Ran 3 tests in 0.000s
FAILED (errors=1)
Traceback (most recent call last):
File "/usr/lib64/python2.6/test/test_fcntl.py", line 105, in <module>
test_main()
File "/usr/lib64/python2.6/test/test_fcntl.py", line 102, in test_main
run_unittest(TestFcntl)
File "/usr/lib64/python2.6/test/test_support.py", line 724, in
run_unittest
_run_suite(suite)
File "/usr/lib64/python2.6/test/test_support.py", line 707, in
_run_suite
raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
File "/usr/lib64/python2.6/test/test_fcntl.py", line 96, in
test_fcntl_64_bit
fcntl.fcntl(fd, cmd, flags)
IOError: [Errno 22] Invalid argument
----------
components: Tests
messages: 94801
nosy: Chainsaw
severity: normal
status: open
title: 2.6.4 fnctl test failure
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7247>
_______________________________________
From report at bugs.python.org Sun Nov 1 23:41:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Nov 2009 22:41:20 +0000
Subject: [New-bugs-announce] [issue7248] test_importlib uses a fixed name in
/tmp
In-Reply-To: <1257115280.67.0.551284747455.issue7248@psf.upfronthosting.co.za>
Message-ID: <1257115280.67.0.551284747455.issue7248@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
test_importlib uses fixed names in /tmp (e.g. /tmp/pkg), which will make
the tests fail is such files/dirs already exist and aren't writable by
the current user (which can happen if several users run the python test
suite...).
----------
assignee: brett.cannon
components: Library (Lib), Tests
messages: 94810
nosy: brett.cannon, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_importlib uses a fixed name in /tmp
type: behavior
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7248>
_______________________________________
From report at bugs.python.org Mon Nov 2 04:50:44 2009
From: report at bugs.python.org (Ryan Leslie)
Date: Mon, 02 Nov 2009 03:50:44 +0000
Subject: [New-bugs-announce] [issue7249] Consider allowing io.BytesIO sizes
to be passed as 'long' in 2.6
In-Reply-To: <1257133844.49.0.793599813853.issue7249@psf.upfronthosting.co.za>
Message-ID: <1257133844.49.0.793599813853.issue7249@psf.upfronthosting.co.za>
New submission from Ryan Leslie <rylesny at gmail.com>:
py> StringIO.StringIO("foo").read(long(1))
'f'
py> io.BytesIO("foo").read(long(1))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: integer argument expected, got 'long'
This is known to cause problems when reading zip data from a BytesIO
object with zipfile. See this recent thread on comp.lang.python:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/337c1b8a48e8acae/
----------
components: Library (Lib)
messages: 94818
nosy: ryles
severity: normal
status: open
title: Consider allowing io.BytesIO sizes to be passed as 'long' in 2.6
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7249>
_______________________________________
From report at bugs.python.org Mon Nov 2 08:34:05 2009
From: report at bugs.python.org (Brandon Bloom)
Date: Mon, 02 Nov 2009 07:34:05 +0000
Subject: [New-bugs-announce] [issue7250] wsgiref.handlers.CGIHandler caches
os.environ, leaking info between requests
In-Reply-To: <1257147245.14.0.668660104401.issue7250@psf.upfronthosting.co.za>
Message-ID: <1257147245.14.0.668660104401.issue7250@psf.upfronthosting.co.za>
New submission from Brandon Bloom <snprbob86 at gmail.com>:
This issue came up while doing Google App Engine development. Apparently
the default wsgi handler logic is to cache os.environ into os_environ at
import time. This is reasonable behavior for wsgi, but when using cgi,
this is a serious security hole which leaks information between requests.
See this related bug at GAE:
http://code.google.com/p/googleappengine/issues/detail?
id=2040&q=cookies%20dev_appserver.py&colspec=ID%20Type%20Status%20Priority
%20Stars%20Owner%20Summary%20Log%20Component
----------
components: Library (Lib)
messages: 94819
nosy: snprbob86
severity: normal
status: open
title: wsgiref.handlers.CGIHandler caches os.environ, leaking info between requests
type: security
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7250>
_______________________________________
From report at bugs.python.org Mon Nov 2 10:43:05 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 02 Nov 2009 09:43:05 +0000
Subject: [New-bugs-announce] [issue7251] Mark expected failures of test_math,
test_cmath and test_round as such.
In-Reply-To: <1257154985.1.0.42933155819.issue7251@psf.upfronthosting.co.za>
Message-ID: <1257154985.1.0.42933155819.issue7251@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
There are some buildbot failures due to platform-specific bugs that need
to be marked as expected failures, using the unittest.expectedFailure
decorator. This may require reorganizing the tests slightly.
* tanh(-0.0) produces 0.0 instead of -0.0 on FreeBSD 6; this causes
test_math and test_cmath to fail. E.g.,
http://www.python.org/dev/buildbot/builders/x86%20FreeBSD%20trunk/builds/2741
* the libm round function on Debian alpha seems to be buggy; this
causes test_round in test_builtin.py to fail. E.g.,
http://www.python.org/dev/buildbot/builders/alpha%20Debian%20trunk/builds/30
----------
assignee: mark.dickinson
components: Tests
keywords: buildbot
messages: 94821
nosy: mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: Mark expected failures of test_math, test_cmath and test_round as such.
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7251>
_______________________________________
From report at bugs.python.org Mon Nov 2 12:59:13 2009
From: report at bugs.python.org (djc)
Date: Mon, 02 Nov 2009 11:59:13 +0000
Subject: [New-bugs-announce] [issue7252] list().index() should provide
better error reporting
In-Reply-To: <1257163153.85.0.398972946442.issue7252@psf.upfronthosting.co.za>
Message-ID: <1257163153.85.0.398972946442.issue7252@psf.upfronthosting.co.za>
New submission from djc <dirkjan at ochtman.nl>:
>>> a = 'b'
>>> [].index(a)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: list.index(x): x not in list
This is suboptimal. IMO it would be much more useful if the ValueError
reported the actual value that wasn't in the list, like this:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: list.index('b'): 'b' not in list
The error in general doesn't really seem to fit in, repeating the code
but with a fake variable name in it. In real contexts, it's mostly just
repeating what's there on a previous line:
File "/home/watt/src/dawkins/ttlib.py", line 86, in shift
bits.append(SHIFTS.index(rest.split('_')[0]))
ValueError: list.index(x): x not in list
So maybe just make it "'b' not in list"? Or do we really need a
reference to the index() method in there?
----------
components: Library (Lib)
messages: 94825
nosy: djc
severity: normal
status: open
title: list().index() should provide better error reporting
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7252>
_______________________________________
From report at bugs.python.org Mon Nov 2 18:13:47 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 02 Nov 2009 17:13:47 +0000
Subject: [New-bugs-announce] [issue7253] AssertionError Tree is insane with
*args and reduce
In-Reply-To: <1257182027.38.0.713900492419.issue7253@psf.upfronthosting.co.za>
Message-ID: <1257182027.38.0.713900492419.issue7253@psf.upfronthosting.co.za>
New submission from Jason R. Coombs <jaraco at jaraco.com>:
Create a file with a single line of code:
def x(arg): return reduce(sum, [])
On Python 3.1.1 (I used Windows 64-bit), run 2to3 on it returns the
following error:
PS C:\Users\jaraco\projects\jaraco.util\jaraco\util>
C:\python\Tools\Scripts\2to3.py .\functools.py
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
Traceback (most recent call last):
File "C:\python\Tools\Scripts\2to3.py", line 6, in <module>
sys.exit(main("lib2to3.fixes"))
File "C:\Python\lib\lib2to3\main.py", line 159, in main
options.processes)
File "C:\Python\lib\lib2to3\refactor.py", line 616, in refactor
items, write, doctests_only)
File "C:\Python\lib\lib2to3\refactor.py", line 276, in refactor
self.refactor_file(dir_or_file, write, doctests_only)
File "C:\Python\lib\lib2to3\refactor.py", line 656, in refactor_file
*args, **kwargs)
File "C:\Python\lib\lib2to3\refactor.py", line 328, in refactor_file
tree = self.refactor_string(input, filename)
File "C:\Python\lib\lib2to3\refactor.py", line 358, in refactor_string
self.refactor_tree(tree, name)
File "C:\Python\lib\lib2to3\refactor.py", line 392, in refactor_tree
self.traverse_by(self.post_order_heads, tree.post_order())
File "C:\Python\lib\lib2to3\refactor.py", line 416, in traverse_by
new = fixer.transform(node, results)
File "C:\Python\lib\lib2to3\fixes\fix_reduce.py", line 33, in transform
touch_import('functools', 'reduce', node)
File "C:\Python\lib\lib2to3\fixer_util.py", line 289, in touch_import
root = find_root(node)
File "C:\Python\lib\lib2to3\fixer_util.py", line 265, in find_root
assert node.parent, "Tree is insane! root found before "\
AssertionError: Tree is insane! root found before file_input node was found.
2to3 on Python 2.6.4 does not exhibit the same error.
Remove 'arg' or the call to reduce and the problem is not exhibited.
----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 94835
nosy: jaraco
severity: normal
status: open
title: AssertionError Tree is insane with *args and reduce
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7253>
_______________________________________
From report at bugs.python.org Mon Nov 2 22:55:36 2009
From: report at bugs.python.org (Vlad)
Date: Mon, 02 Nov 2009 21:55:36 +0000
Subject: [New-bugs-announce] [issue7254] Class members not properly
initialized if declared outside of function
In-Reply-To: <1257198936.49.0.96904959127.issue7254@psf.upfronthosting.co.za>
Message-ID: <1257198936.49.0.96904959127.issue7254@psf.upfronthosting.co.za>
New submission from Vlad <vladc6 at yahoo.com>:
If a class member is declared outside of a function, it's creation is
_not_ repeated with every new instance of the class. Instead, the same
member is created during the first instance and then shared by all the
subsequent instances of that class. This is wrong, because a new member
should be created for every instance.
I have attached a sample code contrasting the incorrect behavior (on
top) with the correct behavior (on bottom). Python behaves correctly if
the member is declared in __init__ (that is, Python initializes a new
member for every instance).
The output of "print b.greet" and "print d.greet" should be the same and
should read "['Howdy']".
----------
files: class_member_init_inconsistency.py
messages: 94851
nosy: vladc6
severity: normal
status: open
title: Class members not properly initialized if declared outside of function
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file15253/class_member_init_inconsistency.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7254>
_______________________________________
From report at bugs.python.org Tue Nov 3 05:22:03 2009
From: report at bugs.python.org (daniel mccloy)
Date: Tue, 03 Nov 2009 04:22:03 +0000
Subject: [New-bugs-announce] [issue7255] "Default" word boundaries for
Unicode data?
In-Reply-To: <1257222123.85.0.715983159645.issue7255@psf.upfronthosting.co.za>
Message-ID: <1257222123.85.0.715983159645.issue7255@psf.upfronthosting.co.za>
New submission from daniel mccloy <bangalore.online at gmail.com>:
Regarding UTS #18 (Unicode Standards for RegEx Engines), which can be
found at:
http://www.unicode.org/reports/tr18/
Is there a plan or commitment for Python to implement at least "default
word boundaries" (a Level 2 feature), rather than the current "simple
word boundaries"? I don't believe that the algorithm for this is a
whole lot more complicated, but it certainly makes a huge difference for
processing non-Roman text.
For example, to match the whole word ?? without matching the word ???
(which has an additional vowel at the end, the vertical line), with
"default word boundary" recognition, you could use the pattern \b??\b.
With Python's current "simple word boundary" recognition, however, the
\b assertion is pretty much useless here, and I have yet to see a decent
zero-width pattern that can take its place.
BTW, the ICU regex libraries do provide this level of Unicode support:
http://userguide.icu-project.org/strings/regexp
It seems to work perfectly on Indic text, based on the tests I've done.
Being open-source, it may be a helpful reference for the algorithm needed.
Dan
----------
components: Regular Expressions
messages: 94856
nosy: RegEx4All
severity: normal
status: open
title: "Default" word boundaries for Unicode data?
type: feature request
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7255>
_______________________________________
From martin at v.loewis.de Tue Nov 3 07:12:44 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Tue, 03 Nov 2009 07:12:44 +0100
Subject: [New-bugs-announce] [issue7255] "Default" word boundaries for
Unicode data?
In-Reply-To: <1257222123.85.0.715983159645.issue7255@psf.upfronthosting.co.za>
References: <1257222123.85.0.715983159645.issue7255@psf.upfronthosting.co.za>
Message-ID: <4AEFC9DC.2000108@v.loewis.de>
> Is there a plan or commitment for Python to implement at least "default
> word boundaries" (a Level 2 feature), rather than the current "simple
> word boundaries"?
No such plan exists at this time. Contributions are welcome.
From report at bugs.python.org Tue Nov 3 12:36:01 2009
From: report at bugs.python.org (Jeroen Habraken)
Date: Tue, 03 Nov 2009 11:36:01 +0000
Subject: [New-bugs-announce] [issue7256] parse_qs and parse_qsl in urlparse
are not documented as New in version 2.6
In-Reply-To: <1257248161.63.0.720725035122.issue7256@psf.upfronthosting.co.za>
Message-ID: <1257248161.63.0.720725035122.issue7256@psf.upfronthosting.co.za>
New submission from Jeroen Habraken <vexocide at gmail.com>:
The parse_qs and parse_qsl functions in the urlparse module seem to be new
since version 2.6, though this is not documented, please add "New in version
2.6.".
----------
assignee: georg.brandl
components: Documentation
messages: 94860
nosy: VeXocide, georg.brandl
severity: normal
status: open
title: parse_qs and parse_qsl in urlparse are not documented as New in version 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7256>
_______________________________________
From report at bugs.python.org Tue Nov 3 19:03:22 2009
From: report at bugs.python.org (Ole Laursen)
Date: Tue, 03 Nov 2009 18:03:22 +0000
Subject: [New-bugs-announce] [issue7257] Improve documentation of list.sort
and sorted()
In-Reply-To: <1257271402.44.0.845935336984.issue7257@psf.upfronthosting.co.za>
Message-ID: <1257271402.44.0.845935336984.issue7257@psf.upfronthosting.co.za>
New submission from Ole Laursen <olau at iola.dk>:
On my Python 3.1, help() for sorted returns
sort(...)
L.sort(key=None, reverse=False) -- stable sort *IN PLACE*
sorted(...)
sorted(iterable, key=None, reverse=False) --> new sorted list
Kindly suggest this be expanded. Here's some text:
sort(...)
Sorts the sequence with a fast stable sort. The sequence is modified in
place. To remind you of this, the function always returns None. Example:
a = [1, 3, 2]
a.sort()
# a is now [1, 2, 3]
Use the "sorted()" built-in function if you need to preserve the
original list.
Set "reverse" to True to sort the elements in reverse order. A function
for extracting a key for comparison from each object can be passed in as
"key", e.g.
a = [{'k': 'foo'}, {'k': 'bar'}]
a.sort(key=lambda x: x['k'])
# a is now [{'k': 'bar'}, {'k': 'foo'}]
Note that "key" can be used to solve many sorting problems, e.g.
key=str.lower can be used for case-insensitive sorting and key=lambda x:
(x['a'], x['b']) can be used to sort by first 'a' then 'b'.
The sort is stable which means that the relative order of elements that
compare equal is not changed.
sorted(...)
Sorts the sequence with a fast stable sort and returns a new list with
the result. Example:
[same text as before]
I'm not sure how this interacts with what's in the online help
(http://docs.python.org/3.1/library/stdtypes.html search for "sort("),
maybe the text could just be copied over. I think it's important to give
copy-pasteable examples for something as important as this, and hint at
how you solve common sorting problems.
----------
assignee: georg.brandl
components: Documentation
messages: 94863
nosy: georg.brandl, olau
severity: normal
status: open
title: Improve documentation of list.sort and sorted()
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7257>
_______________________________________
From report at bugs.python.org Wed Nov 4 02:17:55 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Nov 2009 01:17:55 +0000
Subject: [New-bugs-announce] [issue7258] test_multiprocessing leaves a
temporary directory
In-Reply-To: <1257297475.58.0.890770725694.issue7258@psf.upfronthosting.co.za>
Message-ID: <1257297475.58.0.890770725694.issue7258@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
On my buildbot, test_multiprocessing, although it succeeds, leaves an
empty temporary directory behind it (something like "/tmp/pymp-UHJdgH/").
----------
assignee: jnoller
components: Tests
messages: 94874
nosy: jnoller, pitrou, r.david.murray
priority: low
severity: normal
stage: needs patch
status: open
title: test_multiprocessing leaves a temporary directory
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7258>
_______________________________________
From report at bugs.python.org Wed Nov 4 06:23:39 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 04 Nov 2009 05:23:39 +0000
Subject: [New-bugs-announce] [issue7259] Documentation update for operator
module
In-Reply-To: <1257312219.3.0.741545743577.issue7259@psf.upfronthosting.co.za>
Message-ID: <1257312219.3.0.741545743577.issue7259@psf.upfronthosting.co.za>
New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:
This patch fixes some issues with the documentation of the operator
module:
- docstrings for all augmented assignments incorrectly stated, e.g.,
`operator.iadd(a,b)` is the same as `a += b`. The main documentation
shows `a = operator.iadd(a,b)` instead, and that's correct. This patch
updates all affected docstrings in the operator.c module.
- Added +obj to the table of operators.
- Replaced getslice/setslice/delslice examples (deprecated) with their
getitem/setitem/delitem equivalents. This change unfortunately made the
table some characters wider.
Originally reported by Juanjo Conti:
http://permalink.gmane.org/gmane.org.user-groups.python.argentina/28596
----------
assignee: georg.brandl
components: Documentation
files: operator.diff
keywords: patch
messages: 94878
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: Documentation update for operator module
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15255/operator.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7259>
_______________________________________
From report at bugs.python.org Wed Nov 4 08:04:59 2009
From: report at bugs.python.org (Noam Raphael)
Date: Wed, 04 Nov 2009 07:04:59 +0000
Subject: [New-bugs-announce] [issue7260] SyntaxError with a not-existing
offset for unicode code
In-Reply-To: <1257318299.81.0.115338436222.issue7260@psf.upfronthosting.co.za>
Message-ID: <1257318299.81.0.115338436222.issue7260@psf.upfronthosting.co.za>
New submission from Noam Raphael <noamraph at gmail.com>:
Hello,
This is from the current svn:
> ./python
Python 3.2a0 (py3k:76104, Nov 4 2009, 08:49:44)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> try:
... eval("u'????'")
... except SyntaxError as e:
... e
...
SyntaxError('invalid syntax', ('<string>', 1, 11, "u'????'"))
As you can see, the offset (11) refers to a non-existing character, as
the code contains only 7 characters.
Thanks,
Noam
----------
components: Interpreter Core
messages: 94879
nosy: noam
severity: normal
status: open
title: SyntaxError with a not-existing offset for unicode code
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7260>
_______________________________________
From report at bugs.python.org Wed Nov 4 11:33:13 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 04 Nov 2009 10:33:13 +0000
Subject: [New-bugs-announce] [issue7261] Document 2.x -> 3.x round changes
in "Whats New" documents.
In-Reply-To: <1257330793.87.0.85024867948.issue7261@psf.upfronthosting.co.za>
Message-ID: <1257330793.87.0.85024867948.issue7261@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
The round builtin function changed in three fairly significant ways
between 2.x and 3.x:
(1) In 2.x, halfway cases are rounded using the
round-half-away-from-zero rule, while in 3.x they're
rounded using round-half-to-even.
(2) The single argument version, round(x), generally returns an
integer in 3.x and a float in 2.x. (For float inputs, this
actually changed between 3.0 and 3.1, not between 2.x and 3.x.).
(3) In 3.x, round(x, n) delegates to x.__round__; in 2.x, x is simply
converted to a float (if possible). (So for example, rounding
a Decimal instance in 2.x gives a float result; in 3.x it uses
Decimal.__round__, which returns another Decimal.)
I think all of this is covered (more-or-less) in the 'built-in
functions' section of the documentation, but I suggest that it would be
worth putting an entry for these changes into the 'What's new in Python
3.0' document as well.
The first change above is particularly evil (i.e., likely to cause
late-discovered bugs), since the value of round(x) will change silently,
just for a few values of x. Note that this change affects
integers, too, so it's applicable beyond the "well you should be
using Decimal then" situations.
[2.5]
>>> int(round(2500, -3))
3000
[3.1]
>>> round(2500, -3)
2000
----------
assignee: georg.brandl
components: Documentation
messages: 94886
nosy: georg.brandl, mark.dickinson
severity: normal
stage: needs patch
status: open
title: Document 2.x -> 3.x round changes in "Whats New" documents.
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7261>
_______________________________________
From report at bugs.python.org Wed Nov 4 15:13:30 2009
From: report at bugs.python.org (shamilbi)
Date: Wed, 04 Nov 2009 14:13:30 +0000
Subject: [New-bugs-announce] [issue7262] codecs.open() + eol (windows)
In-Reply-To: <1257344010.52.0.739143662559.issue7262@psf.upfronthosting.co.za>
Message-ID: <1257344010.52.0.739143662559.issue7262@psf.upfronthosting.co.za>
New submission from shamilbi <shamilbi at gmail.com>:
different eol when writing to fp = codecs.open(.., 'w', 'cp866')
(windows, python-2.6.4)
def write(fp):
fp.write("""\
a
""")
# eol=0d0a (windows, python-2.6.4)
with open('0d0a.tmp', 'w') as fp:
write(fp)
# eol=0d0a (windows, python-2.6.4)
with codecs.open('0d0a-codecs.tmp', 'w') as fp:
write(fp)
# --- BUG ---
# eol=0a (windows, python-2.6.4)
with codecs.open('0a-codecs.tmp', 'w', 'cp866') as fp:
write(fp)
----------
components: Library (Lib)
files: eol-bug.py
messages: 94888
nosy: shamilbi
severity: normal
status: open
title: codecs.open() + eol (windows)
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15256/eol-bug.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7262>
_______________________________________
From report at bugs.python.org Wed Nov 4 17:24:39 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 04 Nov 2009 16:24:39 +0000
Subject: [New-bugs-announce] [issue7263] Fix set.intersection docstring
In-Reply-To: <1257351879.79.0.961594941998.issue7263@psf.upfronthosting.co.za>
Message-ID: <1257351879.79.0.961594941998.issue7263@psf.upfronthosting.co.za>
New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:
"""
intersection(...)
Return the intersection of two sets as a new set.
(i.e. all elements that are in both sets.)
"""
Is incorrect because set.intersection takes two or more sets.
Attached patch changes that to
"""
intersection(...)
Return the intersection of two or more sets as a new set.
(i.e. all elements that are in all sets.)
"""
----------
assignee: georg.brandl
components: Documentation
files: set-intersection-doc.diff
keywords: patch
messages: 94892
nosy: belopolsky, georg.brandl
severity: normal
status: open
title: Fix set.intersection docstring
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15257/set-intersection-doc.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7263>
_______________________________________
From report at bugs.python.org Wed Nov 4 21:04:17 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Nov 2009 20:04:17 +0000
Subject: [New-bugs-announce] [issue7264] test_threading_local sometimes
hangs when run with -R
In-Reply-To: <1257365057.55.0.816079780185.issue7264@psf.upfronthosting.co.za>
Message-ID: <1257365057.55.0.816079780185.issue7264@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
If I run something like:
./python -m test.regrtest -R3:2: test_threading_local
Python sometimes hangs and I have to "kill -9" it.
Running through gdb shows it gets stuck at the following point:
/home/antoine/cpython/debug/Lib/threading.py (239): wait
/home/antoine/cpython/debug/Lib/threading.py (638): join
/home/antoine/cpython/debug/Lib/test/test_threading_local.py (68):
test_derived
[snip]
That is, it hangs waiting for a thread to join().
----------
components: Library (Lib), Tests
messages: 94900
nosy: gps, pitrou
priority: normal
severity: normal
status: open
title: test_threading_local sometimes hangs when run with -R
type: crash
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7264>
_______________________________________
From report at bugs.python.org Thu Nov 5 05:51:12 2009
From: report at bugs.python.org (Carey)
Date: Thu, 05 Nov 2009 04:51:12 +0000
Subject: [New-bugs-announce] [issue7265] IDLE not working
In-Reply-To: <1257396672.49.0.0556052422115.issue7265@psf.upfronthosting.co.za>
Message-ID: <1257396672.49.0.0556052422115.issue7265@psf.upfronthosting.co.za>
New submission from Carey <carey.metcalfe at gmail.com>:
IDLE will not open in windows 7 64 bit
My debug log is as follows:
Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
CommandLine: C:\Python31\pythonw.exe
Symbol search path is: srv*
Executable search path is:
ModLoad: 00000000`1d000000 00000000`1d00b000 pythonw.exe
ModLoad: 00000000`76f20000 00000000`770cb000 ntdll.dll
ModLoad: 00000000`76e00000 00000000`76f1f000
C:\Windows\system32\kernel32.dll
ModLoad: 000007fe`fd1e0000 000007fe`fd24b000
C:\Windows\system32\KERNELBASE.dll
ModLoad: 00000000`1e000000 00000000`1e2b0000
C:\Windows\system32\python31.dll
ModLoad: 00000000`76d00000 00000000`76dfa000
C:\Windows\system32\USER32.dll
ModLoad: 000007fe`ff1c0000 000007fe`ff227000 C:\Windows\system32\GDI32.dll
ModLoad: 000007fe`ff1b0000 000007fe`ff1be000 C:\Windows\system32\LPK.dll
ModLoad: 000007fe`fd380000 000007fe`fd44a000 C:\Windows\system32\USP10.dll
ModLoad: 000007fe`fdb30000 000007fe`fdbcf000
C:\Windows\system32\msvcrt.dll
ModLoad: 000007fe`fda50000 000007fe`fdb2b000
C:\Windows\system32\ADVAPI32.dll
ModLoad: 000007fe`fdd00000 000007fe`fdd1f000
C:\Windows\SYSTEM32\sechost.dll
ModLoad: 000007fe`fd250000 000007fe`fd37e000
C:\Windows\system32\RPCRT4.dll
ModLoad: 000007fe`fdf00000 000007fe`fec86000
C:\Windows\system32\SHELL32.dll
ModLoad: 000007fe`fec90000 000007fe`fed01000
C:\Windows\system32\SHLWAPI.dll
ModLoad: 00000000`730a0000 00000000`7313d000
C:\Windows\WinSxS\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4926_none_08e1a05ba83fe554\MSVCR90.dll
(1284.19dc): Break instruction exception - code 80000003 (first chance)
ntdll!LdrpDoDebuggerBreak+0x30:
00000000`76fd1220 cc int 3
0:000> g
ModLoad: 000007fe`fcd50000 000007fe`fcda7000
C:\Windows\system32\apphelp.dll
ModLoad: 000007fe`fd810000 000007fe`fd83e000 C:\Windows\system32\IMM32.DLL
ModLoad: 000007fe`fed90000 000007fe`fee99000 C:\Windows\system32\MSCTF.dll
ntdll!NtTerminateProcess+0xa:
00000000`76f7017a c3 ret
0:000> g
^ No runnable debuggees error in 'g'
0:000> g
^ No runnable debuggees error in 'g'
It seems it cant find a file that it needs, but i dont know why.
----------
components: IDLE
messages: 94919
nosy: Carey
severity: normal
status: open
title: IDLE not working
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7265>
_______________________________________
From report at bugs.python.org Thu Nov 5 16:06:31 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Nov 2009 15:06:31 +0000
Subject: [New-bugs-announce] [issue7266] test_lib2to3 failure under Windows
In-Reply-To: <1257433591.14.0.555852020916.issue7266@psf.upfronthosting.co.za>
Message-ID: <1257433591.14.0.555852020916.issue7266@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
test_lib2to3 fails deterministically on the Windows buildbots:
test test_lib2to3 failed -- Traceback (most recent call last):
File
"E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\lib2to3\tests\test_parser.py",
line 161, in test_all_project_files
self.fail("Idempotency failed: %s" % filepath)
AssertionError: Idempotency failed:
E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\lib2to3\fixer_base.py
If you look at the logs (*), you'll see that it's apparently just a
newline issue. Either the test should be modified to ignore newline
style changes, or lib2to3 should be fixed to output the same kind of
newlines it encountered on input.
(*) e.g.
http://www.python.org/dev/buildbot/trunk.stable/builders/x86%20XP-4%20trunk/builds/2590/steps/test/logs/stdio
----------
assignee: benjamin.peterson
components: 2to3 (2.x to 3.0 conversion tool)
messages: 94933
nosy: benjamin.peterson, pitrou
priority: normal
severity: normal
status: open
title: test_lib2to3 failure under Windows
type: behavior
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7266>
_______________________________________
From report at bugs.python.org Thu Nov 5 17:22:48 2009
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Thu, 05 Nov 2009 16:22:48 +0000
Subject: [New-bugs-announce] [issue7267] format method: c presentation type
broken
In-Reply-To: <1257438168.68.0.774312526176.issue7267@psf.upfronthosting.co.za>
Message-ID: <1257438168.68.0.774312526176.issue7267@psf.upfronthosting.co.za>
New submission from Walter D?rwald <walter at livinglogic.de>:
The c presentation type in the new format method from PEP 3101 seems to
be broken:
Python 2.6.4 (r264:75706, Oct 27 2009, 15:18:04)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> u'{0:c}'.format(256)
u'\x00'
The PEP states:
'c' - Character. Converts the integer to the corresponding Unicode
character before printing, so I would have expected this to return
u'\u0100' instead of u'\x00'.
----------
components: Interpreter Core
messages: 94935
nosy: doerwalter
severity: normal
status: open
title: format method: c presentation type broken
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7267>
_______________________________________
From report at bugs.python.org Fri Nov 6 01:08:56 2009
From: report at bugs.python.org (flashk)
Date: Fri, 06 Nov 2009 00:08:56 +0000
Subject: [New-bugs-announce] [issue7268] 2to3 execfile conversion changes
behavior
In-Reply-To: <1257466136.74.0.490341354872.issue7268@psf.upfronthosting.co.za>
Message-ID: <1257466136.74.0.490341354872.issue7268@psf.upfronthosting.co.za>
New submission from flashk <flashk at gmail.com>:
I recently ran 2to3 on some of my scripts and noticed a change in behavior.
I had a script that used the built-in execfile function. After the conversion, it was
changed to manually open the file and read the contents into the exec function. Now I am
getting a SyntaxError with the modified code.
The SyntaxError is caused when the new exec code is called on a script that ends with an
empty indented line. I'm not sure if this is an error with the 2to3 script or the built-
in exec function.
I've attached a very minimal test case. The test.py file is a simple hello world script
that ends with an empty indented line. The execfile_example.py file simply calls
execfile on the test.py script. The execfile_example_converted.py file is the 2to3
converted version of execfile_example.py.
I'm running Python 2.6.2 on Windows XP.
----------
components: 2to3 (2.x to 3.0 conversion tool), Interpreter Core
files: execfile_problem.zip
messages: 94949
nosy: flashk
severity: normal
status: open
title: 2to3 execfile conversion changes behavior
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15267/execfile_problem.zip
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7268>
_______________________________________
From report at bugs.python.org Fri Nov 6 03:58:52 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Nov 2009 02:58:52 +0000
Subject: [New-bugs-announce] [issue7269] Windows buildbot occasional
DBFileExistsError failures in test_bsddb3
In-Reply-To: <1257476332.86.0.346139621294.issue7269@psf.upfronthosting.co.za>
Message-ID: <1257476332.86.0.346139621294.issue7269@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
The windows buildbot occasionally fails with tracebacks like this:
======================================================================
ERROR: test01_badpointer (bsddb.test.test_misc.MiscTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"E:\cygwin\home\db3l\buildarea\2.6.bolen-windows\build\lib\bsddb\test\test_misc.py",
line 21, in test01_badpointer
dbs = dbshelve.open(self.filename)
File
"E:\cygwin\home\db3l\buildarea\2.6.bolen-windows\build\lib\bsddb\dbshelve.py",
line 106, in open
d.open(filename, dbname, filetype, flags, mode)
File
"E:\cygwin\home\db3l\buildarea\2.6.bolen-windows\build\lib\bsddb\dbshelve.py",
line 171, in open
self.db.open(*args, **kwargs)
DBFileExistsError: (17, 'File exists -- __fop_file_setup: Retry limit
(100) exceeded')
This also happens for several of the other test methods.
----------
assignee: jcea
components: Library (Lib), Tests
keywords: buildbot
messages: 94962
nosy: jcea, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Windows buildbot occasional DBFileExistsError failures in test_bsddb3
type: behavior
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7269>
_______________________________________
From report at bugs.python.org Fri Nov 6 12:26:28 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Nov 2009 11:26:28 +0000
Subject: [New-bugs-announce] [issue7270] Tests for synchronization primitives
In-Reply-To: <1257506788.68.0.0613740035295.issue7270@psf.upfronthosting.co.za>
Message-ID: <1257506788.68.0.0613740035295.issue7270@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
Here is a patch adding unit tests for synchronization primitives in
threading.py (Lock, RLock, Event, Condition). I've left Semaphore and
BoundedSemaphore out of the picture.
----------
components: Library (Lib), Tests
files: locktests.patch
keywords: patch
messages: 94966
nosy: gregory.p.smith, jyasskin, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Tests for synchronization primitives
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15274/locktests.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7270>
_______________________________________
From report at bugs.python.org Fri Nov 6 14:32:26 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 06 Nov 2009 13:32:26 +0000
Subject: [New-bugs-announce] [issue7271] Typo in turtle module documentation.
In-Reply-To: <1257514346.42.0.243931952631.issue7271@psf.upfronthosting.co.za>
Message-ID: <1257514346.42.0.243931952631.issue7271@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
Reported on c.l.p. by Lawrence D'Oliveiro:
<http://docs.python.org/library/turtle.html> -- ?ScrolledCavas? should be
?ScrolledCanvas?.
----------
assignee: georg.brandl
components: Documentation
messages: 94968
nosy: georg.brandl, mark.dickinson
severity: normal
status: open
title: Typo in turtle module documentation.
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7271>
_______________________________________
From report at bugs.python.org Fri Nov 6 16:57:14 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 06 Nov 2009 15:57:14 +0000
Subject: [New-bugs-announce] [issue7272] test_multiprocessing fails
consistently with 'signal 12' on FreeBSD 6.2 buildbot.
In-Reply-To: <1257523034.1.0.340985846807.issue7272@psf.upfronthosting.co.za>
Message-ID: <1257523034.1.0.340985846807.issue7272@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
The x86 FreeBSD buildslave is consistently aborting the test run with a
'Signal 12' failure in test_multiprocessing. See e.g.,
http://www.python.org/dev/buildbot/builders/x86%20FreeBSD%20trunk/builds/2
756/steps/test/logs/stdio
(scroll all the way to the bottom to see the failure).
The failure occurs on 2.7, 3.1 and 3.2. On 2.6, it looks as though
test_multiprocessing is disabled: the message gives a reference to issue
3770.
Note that the maintainer of the buildbot (David Bolen) has offered to
arrange ssh access for anyone wanting to look into this. (See
http://mail.python.org/pipermail/python-dev/2009-November/093857.html
.)
----------
components: Tests
keywords: buildbot
messages: 94977
nosy: db3l, jnoller, mark.dickinson
severity: normal
status: open
title: test_multiprocessing fails consistently with 'signal 12' on FreeBSD 6.2 buildbot.
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7272>
_______________________________________
From report at bugs.python.org Fri Nov 6 17:16:36 2009
From: report at bugs.python.org (Caleb Madrigal)
Date: Fri, 06 Nov 2009 16:16:36 +0000
Subject: [New-bugs-announce] [issue7273] struct.pack adding extra '\x00'
character in very specific case
In-Reply-To: <1257524196.77.0.950133789456.issue7273@psf.upfronthosting.co.za>
Message-ID: <1257524196.77.0.950133789456.issue7273@psf.upfronthosting.co.za>
New submission from Caleb Madrigal <caleb.madrigal at gmail.com>:
struct.pack("17scBH", 'a'*17, 'c', 255, 65535)
produces 'aaaaaaaaaaaaaaaaac\xff\x00\xff\xff'.
Notice the extra '\x00' character between '\xff' and '\xff\xff'.
I have noticed that this happens when there is an odd-length string
(like '17s'), followed by a character ('c'), followed by a byte ('B'),
followed by an unsigned short ('H').
Other variations reproduce it also (such as using a 19-character string).
However, if any one of the following modifications are made to the
format, the problem goes away:
* Change the string to 16s
* Remove the byte ('B')
* Remove the character ('c')
* Remove the unsigned short ('H')
So obviously, this is a seriously deep, dark corner-case.
----------
components: Library (Lib)
messages: 94980
nosy: cmadrigal
severity: normal
status: open
title: struct.pack adding extra '\x00' character in very specific case
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7273>
_______________________________________
From report at bugs.python.org Fri Nov 6 19:11:42 2009
From: report at bugs.python.org (Douglas Shawhan)
Date: Fri, 06 Nov 2009 18:11:42 +0000
Subject: [New-bugs-announce] [issue7274] json module apparently fails
regression found at http://json.org/JSON_checker/test.zip.
In-Reply-To: <1257531102.99.0.282987188143.issue7274@psf.upfronthosting.co.za>
Message-ID: <1257531102.99.0.282987188143.issue7274@psf.upfronthosting.co.za>
New submission from Douglas Shawhan <doug.shawhan at gmail.com>:
Environment:
Ubuntu 9.04 Jaunty
Linux thebadpipsissewah 2.6.28-16-server #55-Ubuntu SMP Tue Oct 20
20:37:10 UTC 2009 x86_64 GNU/Linux
Python 2.6.2 (release26-maint, Apr 19 2009, 01:58:18)
[GCC 4.3.3] on linux2
Passes two "fail" cases:
fail1.json "A JSON payload should be an object or array, not a string."
fail18.json [[[[[[[[[[[[[[[[[[[["Too deep"]]]]]]]]]]]]]]]]]]]]
All other cases pass or fail as indicated.
=== test ===
#!/usr/bin/env python
import json, os
from StringIO import StringIO
def Validate( case ):
try:
l = json.loads( case[1] )
print( "%s %s"%case )
except:
pass
try:
io = StringIO( case[1] )
json.load( io )
print( "%s %s"%case )
except:
pass
for passfail in [ "fail" ]:
cases = [ [( i, open( os.path.join( base, i ), "r").read() )
for i in files if passfail in i ]
for base, subs, files in os.walk( "tests" ) ][0]
[ Validate( case ) for case in cases ]
Sorry for ugly code, in a hurry. If this is wrong, please feel free to
backhand me.
d
----------
components: Extension Modules
messages: 94990
nosy: DougShawhan
severity: normal
status: open
title: json module apparently fails regression found at http://json.org/JSON_checker/test.zip.
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7274>
_______________________________________
From report at bugs.python.org Fri Nov 6 19:12:01 2009
From: report at bugs.python.org (Christian Glinsvad)
Date: Fri, 06 Nov 2009 18:12:01 +0000
Subject: [New-bugs-announce] [issue7275] CoverageResult fails to merge input
file with non-empty callers in trace.py (patch)
In-Reply-To: <1257531121.53.0.200338110704.issue7275@psf.upfronthosting.co.za>
Message-ID: <1257531121.53.0.200338110704.issue7275@psf.upfronthosting.co.za>
New submission from Christian Glinsvad <glinsvad at hotmail.com>:
CoverageResults expects arguments in the order "counts, calledfuncs,
infile, callers..." but the try statement in the last part of __init__
passes "counts, calledfuncs, callers" as positional arguments to a new
instance of the same class. Thus, the secondary instance erroneously
obtains a dict for the "infile" argument, so I propose passing "callers"
as a keyword argument to avoid this.
Not that this has gone unnoticed because an empty dict for the "infile"
argument evaluates to False in "if self.infile:", which must have been
intended as "if self.infile is not None:". If, however, the original
instance loads a pickle file with a non-empty "callers" argument, the
secondary instance tries to run "open({}, 'rb')", which yields:
TypeError: coercing to Unicode: need string or buffer, dict found
----------
components: Library (Lib)
files: trace.diff
keywords: patch
messages: 94991
nosy: glinsvad
severity: normal
status: open
title: CoverageResult fails to merge input file with non-empty callers in trace.py (patch)
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15279/trace.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7275>
_______________________________________
From report at bugs.python.org Fri Nov 6 20:23:17 2009
From: report at bugs.python.org (Ole Laursen)
Date: Fri, 06 Nov 2009 19:23:17 +0000
Subject: [New-bugs-announce] [issue7276] UnboundLocalError scoping problem
with nested functions
In-Reply-To: <1257535397.32.0.778843860173.issue7276@psf.upfronthosting.co.za>
Message-ID: <1257535397.32.0.778843860173.issue7276@psf.upfronthosting.co.za>
New submission from Ole Laursen <olau at iola.dk>:
This works:
def outer(name):
tmp = name
def inner():
print(tmp)
return inner
outer("foo") # prints "foo"
While the same code with one extra line (setting tmp after printing)
fails
def outer(name):
tmp = name
def inner():
print(tmp)
tmp = "hello"
return inner
outer("foo")()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 4, in inner
UnboundLocalError: local variable 'tmp' referenced before assignment
and the following works
def outer(name):
tmp = name
def inner():
tmp = "hello"
print(tmp)
return inner
outer("foo")() # prints "hello"
Now, I understand there's an interesting issue of assignment binding to
the inner-most scope. So tmp = "hello" is binding a new variable, not
changing the outermost tmp. But I should still be able to read tmp,
right? It looks like some kind of optimizer error.
For the record, this pattern came up in a decorator like this
def deco(x = None):
def inner(fn):
if not x:
x = somedefaultvalue
return inner
which gives the same UnboundLocalError error.
----------
messages: 94994
nosy: olau
severity: normal
status: open
title: UnboundLocalError scoping problem with nested functions
type: compile error
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7276>
_______________________________________
From report at bugs.python.org Sat Nov 7 05:08:24 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 07 Nov 2009 04:08:24 +0000
Subject: [New-bugs-announce] [issue7277] online docs out-of-sync with
sources and distributed .chm files
In-Reply-To: <1257566904.77.0.989194227231.issue7277@psf.upfronthosting.co.za>
Message-ID: <1257566904.77.0.989194227231.issue7277@psf.upfronthosting.co.za>
New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:
The online version of the 2.6.4 documentation, at
http://www.python.org/doc/2.6.4/reference/simple_stmts.html#assignment-
statements
includes the changes made in r74822
But neither the source tarball nor the .chm Windows help file
corresponding to the same release include such changes.
Same thing happens with other documentation changes, like r73163.
In case those changes were intentionally not merged into the 2.6
branch, why does the online version show them?
----------
assignee: georg.brandl
components: Documentation
messages: 95008
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: online docs out-of-sync with sources and distributed .chm files
versions: Python 2.6, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7277>
_______________________________________
From report at bugs.python.org Sat Nov 7 10:51:28 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 07 Nov 2009 09:51:28 +0000
Subject: [New-bugs-announce] [issue7278] decimal.py: New instance vs. new
reference
In-Reply-To: <1257587488.65.0.148889938106.issue7278@psf.upfronthosting.co.za>
Message-ID: <1257587488.65.0.148889938106.issue7278@psf.upfronthosting.co.za>
New submission from Stefan Krah <stefan-usenet at bytereef.org>:
In the following case, Decimal() and int() behave differently. I wonder
if this is intentional:
>>> from decimal import *
>>> x = Decimal(2)
>>> y = Decimal(x)
>>> id(x) == id(y)
False
>>>
>>> x = int(2)
>>> y = int(x)
>>> id(x) == id(y)
True
>>>
----------
messages: 95015
nosy: mark.dickinson, skrah
severity: normal
status: open
title: decimal.py: New instance vs. new reference
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7278>
_______________________________________
From report at bugs.python.org Sat Nov 7 11:43:52 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 07 Nov 2009 10:43:52 +0000
Subject: [New-bugs-announce] [issue7279] decimal.py: == and != comparisons
involving NaNs
In-Reply-To: <1257590632.12.0.893741146745.issue7279@psf.upfronthosting.co.za>
Message-ID: <1257590632.12.0.893741146745.issue7279@psf.upfronthosting.co.za>
New submission from Stefan Krah <stefan-usenet at bytereef.org>:
I'm not sure this is a bug, but I am trying to understand the rationale
for mimicking IEEE 754 for == and != comparisons involving NaNs. The
comment in decimal.py says:
"Note: The Decimal standard doesn't cover rich comparisons for Decimals.
In particular, the specification is silent on the subject of what
should happen for a comparison involving a NaN."
First, I think rich comparisons are covered with compare_total(), but
indeed that isn't very useful for == and !=. (It might be useful for
sorting a list of decimals.)
The standard compare() function returns NaN for comparisons involving
NaNs. In addition to that it signals for sNaNs. I'm interpreting this as
"the comparison is undefined". So, in terms of decimal return values,
the standard does define NaN comparisons.
The question remains how to translate "undefined" to a Python truth
value. I'd think that the natural thing is to raise an InvalidOperation
exception in the same way it is done for <, <=, >, >=.
This ...
Decimal("NaN") == 9 ==> InvalidOperation
Decimal("sNaN") == 9 ==> InvalidOperation
... is the behavior of compare_signal(). In my opinion this would follow
the principle of least surprise for the user.
----------
messages: 95017
nosy: mark.dickinson, skrah
severity: normal
status: open
title: decimal.py: == and != comparisons involving NaNs
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7279>
_______________________________________
From report at bugs.python.org Sat Nov 7 21:18:53 2009
From: report at bugs.python.org (Baptiste Lepilleur)
Date: Sat, 07 Nov 2009 20:18:53 +0000
Subject: [New-bugs-announce] [issue7280] PCBuild instruction says to use
nasmw.exe but it no longer exist
In-Reply-To: <1257625133.53.0.426769488546.issue7280@psf.upfronthosting.co.za>
Message-ID: <1257625133.53.0.426769488546.issue7280@psf.upfronthosting.co.za>
New submission from Baptiste Lepilleur <blep at users.sourceforge.net>:
PCBuild requires nasmw.exe but it no longer exists in the latest version
of nasm.
I had to rename nasm.exe to nasmw.exe. Would be nice to add this to the
readme to avoid confusion...
----------
components: Build
files: nasm-doc.patch
keywords: patch
messages: 95025
nosy: blep
severity: normal
status: open
title: PCBuild instruction says to use nasmw.exe but it no longer exist
versions: Python 3.1
Added file: http://bugs.python.org/file15286/nasm-doc.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7280>
_______________________________________
From report at bugs.python.org Sat Nov 7 21:41:39 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 07 Nov 2009 20:41:39 +0000
Subject: [New-bugs-announce] [issue7281] copysign() with NaN arguments on
OpenSolaris
In-Reply-To: <1257626499.13.0.928047451376.issue7281@psf.upfronthosting.co.za>
Message-ID: <1257626499.13.0.928047451376.issue7281@psf.upfronthosting.co.za>
New submission from Stefan Krah <stefan-usenet at bytereef.org>:
Sorry to report so many obscure corner cases. With the combination
Opensolaris/suncc/Python3.x copysign() gives reversed results when the
second argument is a NaN. The bug is in the C99 copysign() function
(OpenSolaris/suncc), but Python2.6 seems to have a workaround:
Python 3.2a0 (py3k:76144, Nov 7 2009, 18:50:00) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> from math import *
>>> copysign(1.0, float("nan"))
-1.0
>>> copysign(1.0, float("-nan"))
1.0
Python 2.6.2 (r262:71600, Nov 7 2009, 19:29:52) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> from math import copysign
>>> copysign(1.0, float("nan"))
1.0
>>> copysign(1.0, float("-nan"))
-1.0
>>>
----------
messages: 95027
nosy: mark.dickinson, skrah
severity: normal
status: open
title: copysign() with NaN arguments on OpenSolaris
type: behavior
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7281>
_______________________________________
From report at bugs.python.org Sun Nov 8 01:00:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Nov 2009 00:00:40 +0000
Subject: [New-bugs-announce] [issue7282] RLocks leak references when used in
raw threads
In-Reply-To: <1257638440.73.0.268077668125.issue7282@psf.upfronthosting.co.za>
Message-ID: <1257638440.73.0.268077668125.issue7282@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
When you use an RLock from a thread which wasn't created through the
high-level `threading` API (but, for example, using
thread.start_new_thread()), the RLock creates a DummyThread object by
calling current_thread(), and that DummyThread is immortal (as well as
its attributes etc.). This implementation wart can easily lead to
reference leaks for unsuspecting users.
One simple solution is not to call current_thread() in RLock, but use
get_ident() instead. Patch attached.
----------
components: Library (Lib)
files: rlock_leak.patch
keywords: patch
messages: 95029
nosy: pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: RLocks leak references when used in raw threads
type: resource usage
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15287/rlock_leak.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7282>
_______________________________________
From report at bugs.python.org Sun Nov 8 01:27:14 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Nov 2009 00:27:14 +0000
Subject: [New-bugs-announce] [issue7283] test_site failure when Python gets
installed along a symbolic link
In-Reply-To: <1257640034.65.0.139323856655.issue7283@psf.upfronthosting.co.za>
Message-ID: <1257640034.65.0.139323856655.issue7283@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
On that buildbot, /var/lib/buildbot is a symlink to /home/buildbot and I
get the following failure:
======================================================================
FAIL: test_s_option (test.test_site.HelperFunctionsTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/home/buildbot/cpython-ucs2/3.x.pitrou-ubuntu/build/Lib/test/test_site.py",
line 107, in test_s_option
self.assertIn(usersite, sys.path)
AssertionError: '/var/lib/buildbot/.local/lib/python3.2/site-packages'
not found in ['/usr/local/lib/python32.zip',
'/home/buildbot/cpython-ucs2/3.x.pitrou-ubuntu/build/Lib',
'/home/buildbot/cpython-ucs2/3.x.pitrou-ubuntu/build/Lib/plat-linux2',
'/home/buildbot/cpython-ucs2/3.x.pitrou-ubuntu/build/Modules',
'/home/buildbot/cpython-ucs2/3.x.pitrou-ubuntu/build/build/lib.linux-x86_64-3.2-pydebug']
----------------------------------------------------------------------
----------
assignee: tarek
components: Tests
messages: 95031
nosy: pitrou, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_site failure when Python gets installed along a symbolic link
type: behavior
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7283>
_______________________________________
From report at bugs.python.org Sun Nov 8 01:56:21 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 08 Nov 2009 00:56:21 +0000
Subject: [New-bugs-announce] [issue7284] optparse - display version in usage
by default
In-Reply-To: <1257641781.98.0.415542584092.issue7284@psf.upfronthosting.co.za>
Message-ID: <1257641781.98.0.415542584092.issue7284@psf.upfronthosting.co.za>
New submission from anatoly techtonik <techtonik at gmail.com>:
It would be useful if optparse could display version right in usage help
before command syntax. Right now it can only output either usage or
version.
----------
messages: 95034
nosy: techtonik
severity: normal
status: open
title: optparse - display version in usage by default
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7284>
_______________________________________
From report at bugs.python.org Sun Nov 8 03:32:00 2009
From: report at bugs.python.org (Kouki Hashimoto)
Date: Sun, 08 Nov 2009 02:32:00 +0000
Subject: [New-bugs-announce] [issue7285] multiprocessing module,
example code error
In-Reply-To: <1257647520.68.0.169575152715.issue7285@psf.upfronthosting.co.za>
Message-ID: <1257647520.68.0.169575152715.issue7285@psf.upfronthosting.co.za>
New submission from Kouki Hashimoto <hsmtkk at gmail.com>:
Example codes on multiprocessing module occur errors.
I attached the patch to fix these errors.
http://docs.python.org/dev/py3k/library/multiprocessing.html#module-
multiprocessing
"16.6.2.10. Listeners and Clients" section
Fix points are
1. Listener argument "authkey" must be a byte string
2. Client argument "authkey" must be a byte string
3. send_bytes argument must be a byte string
This is the server code listed on the section.
$ cat mpserver.py
from multiprocessing.connection import Listener
from array import array
address = ('localhost', 6000) # family is deduced to be 'AF_INET'
listener = Listener(address, authkey='secret password')
conn = listener.accept()
print('connection accepted from', listener.last_accepted)
conn.send([2.25, None, 'junk', float])
conn.send_bytes('hello')
conn.send_bytes(array('i', [42, 1729]))
conn.close()
listener.close()
And the error is
$ python3.2 mpserver.py
Traceback (most recent call last):
File "mpserver1.py", line 5, in <module>
listener = Listener(address, authkey='secret password')
File
"/Users/kosmos/local/stow/py3k/lib/python3.2/multiprocessing/connection.
py", line 100, in __init__
raise TypeError('authkey should be a byte string')
TypeError: authkey should be a byte string
My source code is svn revision 76151.
Regards.
---
Kouki Hashimoto
hsmtkk at gmail.com
----------
assignee: georg.brandl
components: Documentation
files: multiprocessing.rst.diff
keywords: patch
messages: 95035
nosy: georg.brandl, hsmtkk
severity: normal
status: open
title: multiprocessing module, example code error
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file15288/multiprocessing.rst.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7285>
_______________________________________
From report at bugs.python.org Sun Nov 8 07:39:06 2009
From: report at bugs.python.org (Peter Mawhorter)
Date: Sun, 08 Nov 2009 06:39:06 +0000
Subject: [New-bugs-announce] [issue7286] odd exec() behavior or documentation
In-Reply-To: <1257662346.28.0.188136963391.issue7286@psf.upfronthosting.co.za>
Message-ID: <1257662346.28.0.188136963391.issue7286@psf.upfronthosting.co.za>
New submission from Peter Mawhorter <pmawhorter at gmail.com>:
The behavior of the built-in exec() function differs in Python3.1 from
the behavior in Python 2.6 when only a single argument is passed.
Additionally, the documentation for the function does not suggest the
behavior that it has. In Python2.6, an exec statement could both access
and change the values of local variables. In Python3.1, it can read
values from the local scope, but can't change them. Run the attached
script to see examples of this behavior. Note especially that in the
first function, the exec'd code changes the value of a variable called
'value'. However, the change isn't visible after the call to exec(),
because the value changed was a local variable and presumably, the
update is dropped after the exec() finishes. To me, this conflicts with
the statement in the documentation that "In all cases, if the optional
parts are omitted, the code is executed in the current scope." At the
very least, a sentence or two should be added to the documentation
explaining that exec() can't affect the value of local variables. In
addition, it's strange that, for example, in a function declaring
"global value", an exec() statement that modifies 'value' doesn't affect
the value of the global variable. In this sense, the code being exec'd
doesn't seem to be running in a perfect copy of the function's scope.
If it were up to me, I'd allow code being executed by an exec()
statement to modify the value of local variables, because that keeps
with the paradigm of the exec'd code being simply dynamic code that
behaves as if it were written in-line. It also means that programmers
who need to change things with an exec statement aren't limited to
pushing their changes through global variables, which can lead to
conflicts with name sharing (for example, what if my exec() statement is
in a recursive function?). Of course, implementing this may be
difficult... so it may be better just to add to the documentation to
explain this behavior of exec().
----------
assignee: georg.brandl
components: Documentation, Interpreter Core
files: test.py
messages: 95036
nosy: georg.brandl, pmawhorter
severity: normal
status: open
title: odd exec() behavior or documentation
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file15289/test.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7286>
_______________________________________
From report at bugs.python.org Sun Nov 8 14:30:50 2009
From: report at bugs.python.org (Baptiste Lepilleur)
Date: Sun, 08 Nov 2009 13:30:50 +0000
Subject: [New-bugs-announce] [issue7287] import hook demo does not work
In-Reply-To: <1257687050.33.0.193418499466.issue7287@psf.upfronthosting.co.za>
Message-ID: <1257687050.33.0.193418499466.issue7287@psf.upfronthosting.co.za>
New submission from Baptiste Lepilleur <blep at users.sourceforge.net>:
The import hook demo in the source directory
Python-3.1.1\Demo\imputil\knee.py fails to run correctly:
Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import knee
>>> import ctypes.utils
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: import_hook() takes at most 4 positional arguments (5 given)
>>>
----------
components: Demos and Tools
messages: 95040
nosy: blep
severity: normal
status: open
title: import hook demo does not work
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7287>
_______________________________________
From report at bugs.python.org Sun Nov 8 22:46:55 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 Nov 2009 21:46:55 +0000
Subject: [New-bugs-announce] [issue7288] Detect improper leading whitespace
in C files for Vim
In-Reply-To: <1257716815.02.0.0950136651799.issue7288@psf.upfronthosting.co.za>
Message-ID: <1257716815.02.0.0950136651799.issue7288@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
With the proper detection for C files using either tabs or spaces now in
there should also be proper highlighting when the wrong leading whitespace
is used, e.g. if the file uses tabs then any lines with "^ +" should be
flagged as wrong.
----------
assignee: brett.cannon
components: None
keywords: easy
messages: 95047
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: Detect improper leading whitespace in C files for Vim
type: behavior
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7288>
_______________________________________
From report at bugs.python.org Mon Nov 9 00:31:24 2009
From: report at bugs.python.org (Alan Gauld)
Date: Sun, 08 Nov 2009 23:31:24 +0000
Subject: [New-bugs-announce] [issue7289] bad import in redemo.py script in
v3.1
In-Reply-To: <1257723084.57.0.829178832039.issue7289@psf.upfronthosting.co.za>
Message-ID: <1257723084.57.0.829178832039.issue7289@psf.upfronthosting.co.za>
New submission from Alan Gauld <alan.gauld at btinternet.com>:
The Tkinter import in redemo.py in Tools/Scripts folder of the 3.1
distribution uses the old spelling of Tkinter. Changing it to lower case
fixes it. I've just noticed there is a 3.2 listed, I haven't checked
whether it's been fixed there but its not mentioned in the change log for
3.1.1
----------
components: Demos and Tools
messages: 95049
nosy: alan.gauld at btinternet.com
severity: normal
status: open
title: bad import in redemo.py script in v3.1
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7289>
_______________________________________
From report at bugs.python.org Mon Nov 9 04:53:15 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 Nov 2009 03:53:15 +0000
Subject: [New-bugs-announce] [issue7290] Update 'how do I set a global
variable' faq entry
In-Reply-To: <1257738795.91.0.826293712603.issue7290@psf.upfronthosting.co.za>
Message-ID: <1257738795.91.0.826293712603.issue7290@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
Someone else closed issue 7276, but I was thinking of doing so but
wanted to include a pointer to the relevant documentation. I'm not sure
where that documentation is, but I figured there ought to be a FAQ entry
for it. And there is, sort of...the first two sections of the
programming faq's 'core language' section. However, I think that the
way that most people run in to this problem is by getting the
'UnboundLocalError', and so I think the FAQ entry title should mention
that error. I attach a proposed update to the first section of the core
language section of the programming FAQ. I'm also going to attach a
copy of the complete entry since it is hard to read in the patch.
----------
assignee: georg.brandl
components: Documentation
files: UnboundLocalError-faq.patch
keywords: patch
messages: 95057
nosy: georg.brandl, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Update 'how do I set a global variable' faq entry
type: feature request
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15294/UnboundLocalError-faq.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7290>
_______________________________________
From report at bugs.python.org Mon Nov 9 05:38:18 2009
From: report at bugs.python.org (Tatsuhiro Tsujikawa)
Date: Mon, 09 Nov 2009 04:38:18 +0000
Subject: [New-bugs-announce] [issue7291] urllib2 cannot handle https with
proxy requiring auth
In-Reply-To: <1257741498.16.0.683281197284.issue7291@psf.upfronthosting.co.za>
Message-ID: <1257741498.16.0.683281197284.issue7291@psf.upfronthosting.co.za>
New submission from Tatsuhiro Tsujikawa <tsujikawa at gp.hitachi.co.jp>:
urllib2 cannot handle https with proxy requiring authorization.
After https_proxy is set correctly,
Python 2.6.4 (r264:75706, Oct 29 2009, 15:38:25)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib2
>>> c=urllib2.urlopen("https://sourceforge.net")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.6/urllib2.py", line 124, in urlopen
return _opener.open(url, data, timeout)
File "/usr/lib/python2.6/urllib2.py", line 389, in open
response = self._open(req, data)
File "/usr/lib/python2.6/urllib2.py", line 407, in _open
'_open', req)
File "/usr/lib/python2.6/urllib2.py", line 367, in _call_chain
result = func(*args)
File "/usr/lib/python2.6/urllib2.py", line 1154, in https_open
return self.do_open(httplib.HTTPSConnection, req)
File "/usr/lib/python2.6/urllib2.py", line 1121, in do_open
raise URLError(err)
urllib2.URLError: <urlopen error Tunnel connection failed: 407 Proxy
Authentication Required>
This is because HTTPConnection::_tunnel() in httplib.py doesn't send
Proxy-Authorization header.
----------
components: Library (Lib)
messages: 95058
nosy: tsujikawa
severity: normal
status: open
title: urllib2 cannot handle https with proxy requiring auth
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7291>
_______________________________________
From report at bugs.python.org Mon Nov 9 07:31:26 2009
From: report at bugs.python.org (Jonathan)
Date: Mon, 09 Nov 2009 06:31:26 +0000
Subject: [New-bugs-announce] [issue7292] Multiprocessing Joinable race
condition?
In-Reply-To: <1257748286.94.0.346139031927.issue7292@psf.upfronthosting.co.za>
Message-ID: <1257748286.94.0.346139031927.issue7292@psf.upfronthosting.co.za>
New submission from Jonathan <jonathan at kc8onw.net>:
In multiprocessing.JoinableQueue when task_done is called
self._unfinished_tasks.acquire(False) is called non-blocking. My
program reliably crashes with the "task_done() called too many times"
message. If I change the .acquire() call to True (blocking) then my
program no longer crashes and I have not noticed any adverse effects. I
don't know if this would be considered a race condition or something
else but it does lead to crashes even in correct use scenarios.
(Code snippet follows for context, line 292 is the critical one for me)
def task_done(self):
self._cond.acquire()
try:
if not self._unfinished_tasks.acquire(False):
raise ValueError('task_done() called too many times')
if self._unfinished_tasks._semlock._is_zero():
----------
components: None
messages: 95059
nosy: jonathan at kc8onw.net
severity: normal
status: open
title: Multiprocessing Joinable race condition?
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7292>
_______________________________________
From report at bugs.python.org Mon Nov 9 08:00:00 2009
From: report at bugs.python.org (David Bolen)
Date: Mon, 09 Nov 2009 07:00:00 +0000
Subject: [New-bugs-announce] [issue7293] test_msvc9compiler test_reg_class
failure on new Windows box
In-Reply-To: <1257750000.16.0.245083157049.issue7293@psf.upfronthosting.co.za>
Message-ID: <1257750000.16.0.245083157049.issue7293@psf.upfronthosting.co.za>
New submission from David Bolen <db3l.net at gmail.com>:
This is a pretty tiny bug..
The test_reg_class test in test_msvc9compiler.py assumes that there is a
Notepad registry key on Windows systems. That appears to be false until
Notepad is run the very first time. I ran into this setting up a build
slave VM, where I never had the need to run Notepad.
I guess it's pretty rare for Notepad not to be run eventually, but
clearly the comments in the test saying the key is always present is
inaccurate, and perhaps a different key should be chosen or at least
have the test not fail if the key is missing.
It also appears that Windows 7 doesn't have that key even after Notepad
is run.
----------
assignee: tarek
components: Distutils
messages: 95061
nosy: db3l, tarek
severity: normal
status: open
title: test_msvc9compiler test_reg_class failure on new Windows box
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7293>
_______________________________________
From report at bugs.python.org Mon Nov 9 15:34:23 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 09 Nov 2009 14:34:23 +0000
Subject: [New-bugs-announce] [issue7294] MSDN URL in subprocess.py is
incorrect
In-Reply-To: <1257777263.24.0.231988954498.issue7294@psf.upfronthosting.co.za>
Message-ID: <1257777263.24.0.231988954498.issue7294@psf.upfronthosting.co.za>
New submission from Eric Smith <eric at trueblade.com>:
subprocess.py includes this comment, in list2cmdline():
# See
# http://msdn.microsoft.com/library/en-us/vccelng/htm/progs_12.asp
MSDN gets reorganized with surprising regularity, and this URL is no
longer valid. I think the current URL is:
http://msdn.microsoft.com/en-us/library/17w5ykft.aspx
The best way to find this is to go to:
http://msdn.microsoft.com
and search on "Parsing C++ Command-Line Arguments".
----------
components: Library (Lib)
keywords: easy
messages: 95081
nosy: eric.smith
severity: normal
status: open
title: MSDN URL in subprocess.py is incorrect
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7294>
_______________________________________
From report at bugs.python.org Mon Nov 9 17:25:21 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Nov 2009 16:25:21 +0000
Subject: [New-bugs-announce] [issue7295] test_tarfile uses a hardcoded file
name
In-Reply-To: <1257783921.08.0.721111694133.issue7295@psf.upfronthosting.co.za>
Message-ID: <1257783921.08.0.721111694133.issue7295@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
I got this error on my buildbot:
test test_tarfile crashed -- <class 'IOError'>: [Errno 13] Permission
denied: '/tmp/test_tarfile_tmp/testtar.tar.gz'
test_tarfile should not use a hardcoded file name but rely on TESTFN
instead (or any of tempfile.mk*), so that concurrent test runs don't fail.
----------
assignee: lars.gustaebel
components: Library (Lib), Tests
messages: 95086
nosy: lars.gustaebel, pitrou
priority: low
severity: normal
stage: needs patch
status: open
title: test_tarfile uses a hardcoded file name
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7295>
_______________________________________
From report at bugs.python.org Tue Nov 10 00:02:14 2009
From: report at bugs.python.org (jasper)
Date: Mon, 09 Nov 2009 23:02:14 +0000
Subject: [New-bugs-announce] [issue7296] OverflowError: signed integer is
greater than maximum on mips64
In-Reply-To: <1257807734.54.0.518943570242.issue7296@psf.upfronthosting.co.za>
Message-ID: <1257807734.54.0.518943570242.issue7296@psf.upfronthosting.co.za>
New submission from jasper <jasper at humppa.nl>:
While trying to get Python 2.6 working on OpenBSD/sgi (64-bit port)
I ran into the following during build:
OverflowError: signed integer is greater than maximum
I ran the command that triggered this by hand with -v added:
(sgi Python-2.6.3 40)$ export PATH; PATH="`pwd`:$PATH"; export
PYTHONPATH; PYTHONPATH="`pwd`/Lib"; export DYLD_FRAMEWORK_PATH;
DYLD_FRAMEWORK_PATH="`pwd`"; export EXE; EXE=""; cd
./Lib/plat-openbsd4; ./regen
python$EXE -v ../../Tools/scripts/h2py.py -i '(u_long)'
/usr/include/netinet/in.h
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
# /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/site.pyc matches
/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/site.py
import site # precompiled from
/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/site.pyc
'import site' failed; traceback:
Traceback (most recent call last):
File "/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/site.py", line 61,
in <module>
import sys
OverflowError: signed integer is greater than maximum
import encodings # directory
/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/encodings
# /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/encodings/__init__.pyc
matches /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/encodings/__init__.py
import encodings # precompiled from
/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/encodings/__init__.pyc
Python 2.6.3 (r263:75183, Nov 6 2009, 09:50:33)
[GCC 3.3.5 (propolice)] on openbsd4
Type "help", "copyright", "credits" or "license" for more information.
# /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/re.pyc matches
/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/re.py
import re # precompiled from
/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/re.pyc
Traceback (most recent call last):
File "../../Tools/scripts/h2py.py", line 24, in <module>
import sys, re, getopt, os
File "/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/re.py", line 104,
in <module>
import sys
OverflowError: signed integer is greater than maximum
# clear __builtin__._
# clear sys.path
# clear sys.argv
# clear sys.ps1
# clear sys.ps2
# clear sys.exitfunc
# clear sys.exc_type
# clear sys.exc_value
# clear sys.exc_traceback
# clear sys.last_type
# clear sys.last_value
# clear sys.last_traceback
# clear sys.path_hooks
# clear sys.path_importer_cache
# clear sys.meta_path
# clear sys.flags
# clear sys.float_info
# restore sys.stdin
# restore sys.stdout
# restore sys.stderr
# cleanup __main__
# cleanup[1] zipimport
# cleanup[1] signal
# cleanup[1] exceptions
# cleanup[1] _warnings
# cleanup sys
# cleanup __builtin__
# cleanup ints: 3 unfreed ints
# cleanup floats
(sgi plat-openbsd4 41)$
There have been several patches applied:
http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/python/2.6/patches/
Although none seem to be relevant as far as I can see.
Please find attached the build log and the configure log.
----------
components: Build
files: config.log
messages: 95098
nosy: jasper
severity: normal
status: open
title: OverflowError: signed integer is greater than maximum on mips64
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file15300/config.log
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7296>
_______________________________________
From report at bugs.python.org Tue Nov 10 03:38:52 2009
From: report at bugs.python.org (Brandon Dixon)
Date: Tue, 10 Nov 2009 02:38:52 +0000
Subject: [New-bugs-announce] [issue7297] Releasing FamousFoodFinder.com
In-Reply-To: <22e7e1600911091838j58d0a41n27678b169aa7b72c@mail.gmail.com>
Message-ID: <22e7e1600911091838j58d0a41n27678b169aa7b72c@mail.gmail.com>
New submission from Brandon Dixon <brandon.s.dixon at gmail.com>:
For the past 2 months a friend and I have been working on a site (
www.famousfoodfinder.com) that would allow users to search for famous
restaurants. The idea initially came from the fact that I love food and have
been considering traveling around the US for quite some time. I couldn't
think of a better way to enjoy good food and travel than to hit up all the
places that I saw on all my favorite shows. Searching online didn't reveal
any site that contained multiple shows and allowed me to filter my searches.
Rather then wait for someone to add the shows I wanted or the searching
capabilities I felt were necessary, I decided to create my own. The site
currently supports 5 popular shows:
- "Diners, Drive-Ins and Dives"
- "Feasting on Asphalt 1"
- "Feasting on Asphalt 2"
- "The Best Thing I Ever Ate""Throwdown with Bobby Flay"
We are currently working on adding more details to each show as well as a
few other shows that feature more restaurants. The site is still in beta,
but we wanted to release it in it's current state so that users could
suggest ideas on how to improve the design/functionality. We hope you find
it as useful as we do.
Please send any feedback, comments, or requests to:
brandon at famousfoodfinder.com.
----------
files: unnamed
messages: 95101
nosy: brandon.dixon
severity: normal
status: open
title: Releasing FamousFoodFinder.com
Added file: http://bugs.python.org/file15303/unnamed
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7297>
_______________________________________
-------------- next part --------------
<span style="font-family:'Times New Roman';font-size:medium"><div style="background-repeat:initial;background-color:rgb(255, 255, 255);padding-top:0.6em;padding-right:0.6em;padding-bottom:0.6em;padding-left:0.6em;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px">
<span class="Apple-style-span" style="font-family: monospace; font-size: 13px; white-space: pre-wrap; ">For the past 2 months a friend and I have been working on a site (<a href="http://www.famousfoodfinder.com">www.famousfoodfinder.com</a>) that would allow users to search for famous restaurants. The idea initially came from the fact that I love food and have been considering traveling around the US for quite some time. I couldn't think of a better way to enjoy good food and travel than to hit up all the places that I saw on all my favorite shows.
Searching online didn't reveal any site that contained multiple shows and allowed me to filter my searches. Rather then wait for someone to add the shows I wanted or the searching capabilities I felt were necessary, I decided to create my own.
The site currently supports 5 popular shows:<br><ul><li>"Diners, Drive-Ins and Dives"</li><li>"Feasting on Asphalt 1"</li><li>"Feasting on Asphalt 2"</li><li>"The Best Thing I Ever Ate""Throwdown with Bobby Flay"</li>
</ul></span></div><div style="background-repeat:initial;background-color:rgb(255, 255, 255);padding-top:0.6em;padding-right:0.6em;padding-bottom:0.6em;padding-left:0.6em;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px">
<span class="Apple-style-span" style="font-family: monospace; font-size: 13px; white-space: pre-wrap; ">We are currently working on adding more details to each show as well as a few other shows that feature more restaurants. The site is still in beta, but we wanted to release it in it's current state so that users could suggest ideas on how to improve the design/functionality. We hope you find it as useful as we do.<br>
</span></div><div style="background-repeat:initial;background-color:rgb(255, 255, 255);padding-top:0.6em;padding-right:0.6em;padding-bottom:0.6em;padding-left:0.6em;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px">
<font class="Apple-style-span" face="monospace" size="3"><span class="Apple-style-span" style="font-size: 13px; white-space: pre-wrap;">Please send any feedback, comments, or requests to: <a href="mailto:brandon at famousfoodfinder.com">brandon at famousfoodfinder.com</a>.</span></font></div>
</span><br>-- <br>Brandon Dixon - CCNA, OSCP, WebSphere DataPower Solution Developer<br>Information Systems Security Engineer<br><a href="http://www.dueyesterday.net" target="_blank">www.dueyesterday.net</a> - Documentation for the masses<br>
<a href="http://www.famousfoodfinder.com" target="_blank">www.famousfoodfinder.com</a> - Search for famous restaurants around you!<br>
From report at bugs.python.org Tue Nov 10 11:27:38 2009
From: report at bugs.python.org (ledave123)
Date: Tue, 10 Nov 2009 10:27:38 +0000
Subject: [New-bugs-announce] [issue7298] reversed(range(x, -1,
-1)) is empty when x > 1
In-Reply-To: <1257848858.69.0.270094372501.issue7298@psf.upfronthosting.co.za>
Message-ID: <1257848858.69.0.270094372501.issue7298@psf.upfronthosting.co.za>
New submission from ledave123 <ledave123 at yahoo.fr>:
On python 2.4.4, reversed(range()) is correct :
>>> list(reversed(range(12,-1,-1)))
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]
However, on python 3.1.1 :
>>> list(reversed(range(12,-1,-1)))
[]
which is obviously wrong.
When step is positive, the result is okay on python 3.1.1 :
>>> list(reversed(range(13)))
[12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0]
----------
components: Interpreter Core
messages: 95104
nosy: ledave123
severity: normal
status: open
title: reversed(range(x, -1, -1)) is empty when x > 1
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7298>
_______________________________________
From report at bugs.python.org Tue Nov 10 13:56:39 2009
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 10 Nov 2009 12:56:39 +0000
Subject: [New-bugs-announce] [issue7299] setup.py install doesn't honor
PYTHONUSERBASE
In-Reply-To: <1257857799.68.0.397965237537.issue7299@psf.upfronthosting.co.za>
Message-ID: <1257857799.68.0.397965237537.issue7299@psf.upfronthosting.co.za>
New submission from Matthias Klose <doko at debian.org>:
Got an user report about setup.py install not honoring PYTHONUSERBASE.
Is this by design? If not, the attached patch seems to implement this
functionality.
----------
assignee: tarek
components: Distutils
files: userbase.diff
keywords: patch, patch
messages: 95111
nosy: doko, tarek
severity: normal
status: open
title: setup.py install doesn't honor PYTHONUSERBASE
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file15305/userbase.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7299>
_______________________________________
From report at bugs.python.org Tue Nov 10 14:57:35 2009
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Tue, 10 Nov 2009 13:57:35 +0000
Subject: [New-bugs-announce] [issue7300] Unicode arguments in str.format()
In-Reply-To: <1257861455.06.0.0846130484851.issue7300@psf.upfronthosting.co.za>
Message-ID: <1257861455.06.0.0846130484851.issue7300@psf.upfronthosting.co.za>
New submission from Walter D?rwald <walter at livinglogic.de>:
str.format() doesn't handle unicode arguments:
Python 2.6.4 (r264:75706, Oct 27 2009, 15:18:04)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> '{0}'.format(u'\u3042')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\u3042' in
position 0: ordinal not in range(128)
Unicode arguments should be treated in the same way as the % operator
does it: by promoting the format string to unicode:
>>> '%s' % u'\u3042'
u'\u3042'
----------
assignee: eric.smith
components: Interpreter Core
messages: 95114
nosy: doerwalter, eric.smith
severity: normal
status: open
title: Unicode arguments in str.format()
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7300>
_______________________________________
From report at bugs.python.org Tue Nov 10 16:05:31 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 10 Nov 2009 15:05:31 +0000
Subject: [New-bugs-announce] [issue7301] Add environment variable
$PYTHONWARNINGS
In-Reply-To: <1257865531.11.0.841786263832.issue7301@psf.upfronthosting.co.za>
Message-ID: <1257865531.11.0.841786263832.issue7301@psf.upfronthosting.co.za>
New submission from Barry A. Warsaw <barry at python.org>:
It would be very useful to have an environment variable $PYTHONWARNINGS,
tied to the -W option for silencing various warnings (most importantly,
DeprecationWarnings).
Use case: a test suite running many subprocesses, testing that those
subproc output is clean. DeprecationWarnings cannot easily be
suppressed by passing -W flags all around or using liberally sprinkled
filterwarnings(). Setting $PYTHONWARNINGS once and for all to silence
all processes would be very useful.
----------
components: Library (Lib)
messages: 95117
nosy: barry
severity: normal
status: open
title: Add environment variable $PYTHONWARNINGS
type: feature request
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7301>
_______________________________________
From report at bugs.python.org Tue Nov 10 19:39:27 2009
From: report at bugs.python.org (Egon Frerich)
Date: Tue, 10 Nov 2009 18:39:27 +0000
Subject: [New-bugs-announce] [issue7302] Wrong link to Python Language
Mapping Specification
In-Reply-To: <1257878367.72.0.0298687588938.issue7302@psf.upfronthosting.co.za>
Message-ID: <1257878367.72.0.0298687588938.issue7302@psf.upfronthosting.co.za>
New submission from Egon Frerich <e.frerich at nord-com.net>:
There is a wrong link in
http://docs.python.org/library/xml.dom.html#domimplementation-objects
Python Language Mapping Specification
is linked to
http://www.omg.org/docs/formal/02-11-05.pdf
but I assume it should be
http://www.omg.org/spec/PYTH/1.2/PDF
----------
assignee: georg.brandl
components: Documentation
messages: 95126
nosy: efrerich, georg.brandl
severity: normal
status: open
title: Wrong link to Python Language Mapping Specification
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7302>
_______________________________________
From report at bugs.python.org Tue Nov 10 23:12:33 2009
From: report at bugs.python.org (ulrik)
Date: Tue, 10 Nov 2009 22:12:33 +0000
Subject: [New-bugs-announce] [issue7303] pkgutil lacks documentation for
useful functions
In-Reply-To: <1257891153.41.0.767469344024.issue7303@psf.upfronthosting.co.za>
Message-ID: <1257891153.41.0.767469344024.issue7303@psf.upfronthosting.co.za>
New submission from ulrik <ulrik.sverdrup at gmail.com>:
The module pkgutil has no documentation of functions added after its
introduction, in the official python documentation collection.
http://docs.python.org/dev/py3k/library/pkgutil.html
The module is well documented with docstrings.
I assume the module's exposed functions, some very useful, are open for
public use, for example pkgutil.iter_modules and .walk_packages.
Is all that is required copying the docstrings into the documentation?
If someone believes only Python insight and knowledge of reST sytax is
enough to make some passable documentation from the existing docstrings,
I could submit a patch for that.
----------
assignee: georg.brandl
components: Documentation
messages: 95132
nosy: englabenny, georg.brandl
severity: normal
status: open
title: pkgutil lacks documentation for useful functions
type: feature request
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7303>
_______________________________________
From report at bugs.python.org Tue Nov 10 23:32:48 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 10 Nov 2009 22:32:48 +0000
Subject: [New-bugs-announce] [issue7304] email.message.Message.set_payload
and as_string given charset 'us-ascii' plus 8bit data
produces invalid message
In-Reply-To: <1257892368.6.0.221695441401.issue7304@psf.upfronthosting.co.za>
Message-ID: <1257892368.6.0.221695441401.issue7304@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
The following produces a non-conformant message, since the us-ascii
charset is strictly 7bit:
>>> import email.message
>>> m = email.message.Message()
>>> m.set_payload("""A few lines
... of 8-bit text
...
... One high bit character: ?.
... """, 'us-ascii')
>>> print m.as_string()
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
A few lines
of 8-bit text
One high bit character: ?.
>>>
----------
components: Library (Lib)
messages: 95133
nosy: r.david.murray
priority: normal
severity: normal
stage: test needed
status: open
title: email.message.Message.set_payload and as_string given charset 'us-ascii' plus 8bit data produces invalid message
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7304>
_______________________________________
From report at bugs.python.org Wed Nov 11 14:42:52 2009
From: report at bugs.python.org (River Tarnell)
Date: Wed, 11 Nov 2009 13:42:52 +0000
Subject: [New-bugs-announce] [issue7305] urllib2.urlopen() segfault using
SSL on Solaris
In-Reply-To: <1257946972.34.0.0114488119184.issue7305@psf.upfronthosting.co.za>
Message-ID: <1257946972.34.0.0114488119184.issue7305@psf.upfronthosting.co.za>
New submission from River Tarnell <river at flyingparchment.org.uk>:
Using Python 2.6.2 or 2.6.4 on Solaris 10, opening an SSL (https) URL
using urllib2.urlopen() crashes Python:
% python
Python 2.6.4 (r264:75706, Nov 11 2009, 13:23:45) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib2; urllib2.urlopen('https://launchpad.net/~netbook-
remix-team/+archive/ppa')
zsh: segmentation fault (core dumped) python
% pstack core
core 'core' of 14970: python
fe86663f AES_encrypt () + 173
%
Python was compiled using Sun C 5.10 SunOS_i386 2009/06/03 and OpenSSL
0.9.7d (+ Sun security patches) using flags:
CFLAGS='-i -xO4 -xspace -xstrconst -xpentium -mr -xregs=no%frameptr'
LDFLAGS='-L/opt/ts/python/2.6/lib -L/usr/sfw/lib -R/opt/ts/python/2.6/
lib:/usr/sfw/lib -L/opt/ts/X11/lib -R/opt/ts/X11/lib -L/opt/ts/lib -R/
opt/ts/lib -L/opt/ts/python/2.6/lib'
CPPFLAGS='-I/opt/ts/python/2.6/include -I/usr/sfw/include -I/opt/ts/X11/
include -D__EXTENSIONS__ -I/opt/ts/include'
./configure --prefix=/opt/ts/python/2.6 --bindir=/opt/ts/python/2.6/bin
--libdir=/opt/ts/python/2.6/lib --mandir=/opt/ts/python/26/share/man --
datadir=/opt/ts/python/2.6/share --includedir=/opt/ts/python/2.6/
include --infodir=/opt/ts/python/2.6/share/info --libexecdir=/opt/ts/
python/2.6/lib --sysconfdir=/etc/opt/ts --disable-nls --disable-static
--with-threads --enable-ipv6 --prefix=/opt/ts/python/2.6 --enable-shared
----------
components: Extension Modules
messages: 95139
nosy: rtarnell
severity: normal
status: open
title: urllib2.urlopen() segfault using SSL on Solaris
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7305>
_______________________________________
From report at bugs.python.org Wed Nov 11 16:38:05 2009
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 11 Nov 2009 15:38:05 +0000
Subject: [New-bugs-announce] [issue7306] Patch - skip winsound tests if no
default sound is configured
In-Reply-To: <1257953885.18.0.603136766884.issue7306@psf.upfronthosting.co.za>
Message-ID: <1257953885.18.0.603136766884.issue7306@psf.upfronthosting.co.za>
New submission from Brian Curtin <curtin at acm.org>:
I noticed test failures on trunk for test_winsound on only one of my
boxes. Everything works fine on XP, but PlaySoundTest test methods fail
on Windows Server 2003.
It appears that on WS2k3 there are no default system sounds configured.
For example, view the difference of the following registry key on an XP
and Server machine:
HKEY_CURRENT_USER\AppEvents\Schemes\Apps\.Default\SystemExit\.Default.
The patch includes a function to figure out if a WAV file is associated
with a particular sound, and unittest.skipIf is used to decorate some
methods to skip if they don't have a configured sound.
----------
components: Tests, Windows
files: winsound_test_skipping.patch
keywords: patch
messages: 95140
nosy: brian.curtin
severity: normal
status: open
title: Patch - skip winsound tests if no default sound is configured
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file15308/winsound_test_skipping.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7306>
_______________________________________
From report at bugs.python.org Wed Nov 11 21:48:31 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 11 Nov 2009 20:48:31 +0000
Subject: [New-bugs-announce] [issue7307] test_distutils failure under
Windows 7
In-Reply-To: <1257972511.98.0.363169878923.issue7307@psf.upfronthosting.co.za>
Message-ID: <1257972511.98.0.363169878923.issue7307@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
In
http://www.python.org/dev/buildbot/3.x/builders/x86%20Windows7%203.x/builds/10/steps/test/logs/stdio
:
======================================================================
ERROR: test_reg_class
(distutils.tests.test_msvc9compiler.msvc9compilerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\distutils\tests\test_msvc9compiler.py",
line 48, in test_reg_class
v = Reg.get_value(path, "lfitalic")
File
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\distutils\msvc9compiler.py",
line 62, in get_value
raise KeyError(key)
KeyError: 'lfitalic'
----------------------------------------------------------------------
----------
assignee: tarek
components: Distutils
messages: 95150
nosy: pitrou, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_distutils failure under Windows 7
type: behavior
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7307>
_______________________________________
From report at bugs.python.org Wed Nov 11 22:49:21 2009
From: report at bugs.python.org (Stefan Sonnenberg-Carstens)
Date: Wed, 11 Nov 2009 21:49:21 +0000
Subject: [New-bugs-announce] [issue7308] Named group regex error
In-Reply-To: <1257976161.92.0.516283510744.issue7308@psf.upfronthosting.co.za>
Message-ID: <1257976161.92.0.516283510744.issue7308@psf.upfronthosting.co.za>
New submission from Stefan Sonnenberg-Carstens <stefan.sonnenberg at pythonmeister.com>:
>>> import re
>>> p = re.compile(r'(P?<quotedstring>("[^"]*"))')
>>> p.match('"Hallo"')
>>> p = re.compile(r'("[^"]*")')
>>> p.match('"Hallo"')
<_sre.SRE_Match object at 0x0197F758>
>>> p.match('"Hallo"').group()
'"Hallo"'
>>> import sys
>>> sys.version
'2.6.3 (r263:75183, Oct 5 2009, 14:41:55) [MSC v.1500 32 bit (Intel)]'
When I use a named group like above, the regex does not match.
It otherwise does.
I could not find a hint in the docs, so I guess this behaviour is
not intended.
----------
components: Interpreter Core, Library (Lib)
messages: 95152
nosy: pythonmeister
severity: normal
status: open
title: Named group regex error
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7308>
_______________________________________
From report at bugs.python.org Thu Nov 12 11:50:49 2009
From: report at bugs.python.org (Armin Rigo)
Date: Thu, 12 Nov 2009 10:50:49 +0000
Subject: [New-bugs-announce] [issue7309] crasher in str(Exception())
In-Reply-To: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>
Message-ID: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>
New submission from Armin Rigo <arigo at users.sourceforge.net>:
The __str__ method of some exception classes reads attributes without
typechecking them. Alternatively, the issue could be that the user is
allowed to set the value of these attributes directly, without
typecheck. The typechecking is only done when we create the exception,
but not later. Example:
>>> u=UnicodeTranslateError(u'x', 1, 5, 'bah')
>>> u.reason = 0x345345345345345345
>>> str(u)
"can't translate characters in position 1-4: E\x03"
The 'E\x03' comes from PyString_AS_STRING(reason). By playing enough it
is probably possible to come up with a real crasher.
----------
components: Interpreter Core
messages: 95159
nosy: arigo
severity: normal
status: open
title: crasher in str(Exception())
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7309>
_______________________________________
From report at bugs.python.org Thu Nov 12 12:54:01 2009
From: report at bugs.python.org (Kent Johnson)
Date: Thu, 12 Nov 2009 11:54:01 +0000
Subject: [New-bugs-announce] [issue7310] Unhelpful __repr__() in os.environ
In-Reply-To: <1258026841.53.0.960128215471.issue7310@psf.upfronthosting.co.za>
Message-ID: <1258026841.53.0.960128215471.issue7310@psf.upfronthosting.co.za>
New submission from Kent Johnson <kent at kentsjohnson.com>:
In Python 2.x, os.environ extends UserDict.IterableUserDict and
therefore os.environ.__repr__() shows the environment. This makes it
easy and intuitive to view the entire environment in the interactive
interpreter.
In Python 3.1, os.environ extends _abcoll.MutableMapping and uses
object.__repr__(). This is a much less useful representation.
I suggest adding this __repr__() method to class os._Environ (os.py line
380):
def __repr__(self): return repr(self.data)
----------
components: Library (Lib)
messages: 95160
nosy: kjohnson
severity: normal
status: open
title: Unhelpful __repr__() in os.environ
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7310>
_______________________________________
From report at bugs.python.org Thu Nov 12 17:25:50 2009
From: report at bugs.python.org (Chiyuan Zhang)
Date: Thu, 12 Nov 2009 16:25:50 +0000
Subject: [New-bugs-announce] [issue7311] Bug on regexp of HTMLParser
In-Reply-To: <1258043150.41.0.372876851796.issue7311@psf.upfronthosting.co.za>
Message-ID: <1258043150.41.0.372876851796.issue7311@psf.upfronthosting.co.za>
New submission from Chiyuan Zhang <pluskid at gmail.com>:
Hi all,
I'm using BeautifulSoup to parsing an HTML page and find it refused to
parse the page. By looking at the backtrace, I found it is a problem
with the python built-in HTMLParser.py. In fact, the web page I'm
parsing is with some Chinese characters. there is a tag like <img
src=/foo/bar.png alt=??> , note this is legacy html page where the
attributes are not quoted. However, the regexp defined in
HTMLParser.py is :
attrfind = re.compile(
r'\s*([a-zA-Z_][-.:a-zA-Z_0-9]*)(\s*=\s*'
r'(\'[^\']*\'|"[^"]*"|[-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~@]*))?')
Note that the Chinese character (also any other non-english
characters), so it fire an error parsing this. I'm not sure whether
the HTML standard allow un-quoted non-ASCII characters in the
attributes. If it allows, this seems to be a bug. and the regexp to
better be [^>\s] IMHO.
BTW: It seems something like :
<script>
var st = "<a></";
</script>
can not be parsed. :-/
----------
components: Library (Lib)
messages: 95162
nosy: pluskid
severity: normal
status: open
title: Bug on regexp of HTMLParser
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7311>
_______________________________________
From report at bugs.python.org Fri Nov 13 00:58:27 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Nov 2009 23:58:27 +0000
Subject: [New-bugs-announce] [issue7312] Run some tests in a loop until
failure
In-Reply-To: <1258070307.12.0.876277765966.issue7312@psf.upfronthosting.co.za>
Message-ID: <1258070307.12.0.876277765966.issue7312@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
It can be useful to run one or several of the regression tests in a
loop, until one of the tests fail. Here is a patch to do that.
(interesting thing, by the way: you can combine it with -j, in order to
run several instance of the test at once)
----------
components: Tests
files: looptests.patch
keywords: patch
messages: 95166
nosy: jnoller, pitrou, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Run some tests in a loop until failure
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15317/looptests.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7312>
_______________________________________
From report at bugs.python.org Fri Nov 13 13:02:08 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 13 Nov 2009 12:02:08 +0000
Subject: [New-bugs-announce] [issue7313] 2to3 fails when source file starts
with BOM
In-Reply-To: <1258113728.92.0.380027022792.issue7313@psf.upfronthosting.co.za>
Message-ID: <1258113728.92.0.380027022792.issue7313@psf.upfronthosting.co.za>
New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:
If the source file is encoded in UTF-8 with a BOM,
2to3 cannot parse it:
C:\APPS\python\trunk\PCbuild>.\python ..\Tools\scripts
\2to3 c:\temp\test_2to3.py
root: Generating grammar tables from C:\APPS\python
\trunk\lib\lib2to3\PatternGrammar.txt
root: Writing grammar tables to C:\APPS\python\trunk
\lib\lib2to3\PatternGrammar2.7.0.alpha.0.pickle
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: Can't parse c:\temp\test_2to3.py:
ParseError: bad token: type=55, value=u'\ufeff',
context=(u'', (1, 0)
)
RefactoringTool: No files need to be modified.
RefactoringTool: There was 1 error:
RefactoringTool: Can't parse c:\temp\test_2to3.py:
ParseError: bad token: type=55, value=u'\ufeff',
context=(u'', (1, 0)
)
Tested with 3.1.1 and trunk.
----------
components: 2to3 (2.x to 3.0 conversion tool)
files: test_2to3_bom.py
messages: 95176
nosy: gagenellina
severity: normal
status: open
title: 2to3 fails when source file starts with BOM
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15319/test_2to3_bom.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7313>
_______________________________________
From report at bugs.python.org Fri Nov 13 17:52:55 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 13 Nov 2009 16:52:55 +0000
Subject: [New-bugs-announce] [issue7314] test_multiprocessing hangs on
Windows 7 64 bit
In-Reply-To: <1258131175.63.0.744980392566.issue7314@psf.upfronthosting.co.za>
Message-ID: <1258131175.63.0.744980392566.issue7314@psf.upfronthosting.co.za>
New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:
Running a debug python from the py3k branch on my windows 7 machine, 64
bit, test_multiprocessing hangs in the _TestZZZNumberOfObjects test.
I don't know this module, but I did a little digging:
The main process is in the gc.collec() causing some manager object to
call a _decref() method, which is initiating a socket connection to a
child process (I presume.) This is spinning endlessly because the
connection is constantly refused.
The child processes don't have any sockets open (according to the
resource monitor) and when I look at the state they are in, the are
stuck waiting for a ReadFile to succeed. The python traceback appears
to be (innermost first, line numbers approximate:)
queues.py:349
pool.py:45
process.py:83
process.py:215
forking.py:326
----------
components: Tests
keywords: 64bit
messages: 95186
nosy: krisvale
severity: normal
status: open
title: test_multiprocessing hangs on Windows 7 64 bit
type: behavior
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7314>
_______________________________________
From report at bugs.python.org Fri Nov 13 18:05:15 2009
From: report at bugs.python.org (James)
Date: Fri, 13 Nov 2009 17:05:15 +0000
Subject: [New-bugs-announce] [issue7315] os.path.normpath doesn't normalize
../path/something.py
In-Reply-To: <1258131915.3.0.590815402917.issue7315@psf.upfronthosting.co.za>
Message-ID: <1258131915.3.0.590815402917.issue7315@psf.upfronthosting.co.za>
New submission from James <purpleidea at gmail.com>:
os.path.normpath doesn't normalize paths that start with ../
you would expect the final output line in the secpnd run to read:
"normpath: badnormpath.py" instead of: "normpath: ../tmp/badnormpath.py"
example:
james at home:~$ cd tmp/
james at home:~/tmp$ cat badnormpath.py
#!/usr/bin/python
import os.path
print '__file__: %s' % __file__
print 'normpath: %s' % os.path.normpath(__file__)
james at home:~/tmp$ ./badnormpath.py
__file__: ./badnormpath.py
normpath: badnormpath.py
james at home:~/tmp$ ./../tmp/badnormpath.py
__file__: ./../tmp/badnormpath.py
normpath: ../tmp/badnormpath.py
james at home:~/tmp$
----------
components: Library (Lib)
messages: 95189
nosy: purpleidea
severity: normal
status: open
title: os.path.normpath doesn't normalize ../path/something.py
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7315>
_______________________________________
From report at bugs.python.org Fri Nov 13 18:31:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Nov 2009 17:31:48 +0000
Subject: [New-bugs-announce] [issue7316] Add a timeout functionality to
common locking operations
In-Reply-To: <1258133508.5.0.728130823639.issue7316@psf.upfronthosting.co.za>
Message-ID: <1258133508.5.0.728130823639.issue7316@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
Here is a patch which adds a timeout feature to the locking operations
provided by Python. This feature is added at two levels:
- the C API level, with a new function PyThread_acquire_lock_timed()
- the Python level, with an optional `timeout` argument to the acquire()
method of Lock and RLock objects (it also helps simplify the wait()
function of Condition objects)
The timeout duration is expressed in microseconds at the C API level,
and in seconds at the Python API level. There is also a new Python-level
constant, `_thread.TIMEOUT_MAX`, indicating the max allowable timeout
value (values above this raise an OverflowError).
At the C level, the max timeout is PY_TIMEOUT_MAX (in microseconds). The
caller should check the value him/herself.
The patch contains both a POSIX implementation and a Windows
implementation. It still lacks docs.
----------
components: Interpreter Core, Library (Lib)
files: timedlock.patch
keywords: patch
messages: 95192
nosy: gps, pitrou
priority: normal
severity: normal
status: open
title: Add a timeout functionality to common locking operations
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file15321/timedlock.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7316>
_______________________________________
From report at bugs.python.org Fri Nov 13 20:23:35 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Nov 2009 19:23:35 +0000
Subject: [New-bugs-announce] [issue7317] Display full tracebacks when an
error occurs asynchronously
In-Reply-To: <1258140215.22.0.835793798885.issue7317@psf.upfronthosting.co.za>
Message-ID: <1258140215.22.0.835793798885.issue7317@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
When an exception is raised in a __del__ method or a finalizer (i.e. a
weakref callback), only the exception name is printed out.
Unfortunately, arbitrarily complex code can be involved which makes
debugging quite tedious. It would be nice to display the full traceback
so that these errors are easier to diagnose (see issue7060 as an example).
----------
components: Interpreter Core, Library (Lib)
messages: 95197
nosy: pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: Display full tracebacks when an error occurs asynchronously
type: feature request
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7317>
_______________________________________
From report at bugs.python.org Fri Nov 13 20:28:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Nov 2009 19:28:54 +0000
Subject: [New-bugs-announce] [issue7318] multiprocessing should not wait
endlessly
In-Reply-To: <1258140534.04.0.0239961207692.issue7318@psf.upfronthosting.co.za>
Message-ID: <1258140534.04.0.0239961207692.issue7318@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
SocketClient() in multiprocessing.connection loops endlessly when the
connection is refused. It shouldn't, and instead use a timeout.
This is especially annoying since SocketClient() can be called as part
of finalizing an object, which makes debugging very annoying (see
issue7060).
----------
assignee: jnoller
components: Library (Lib)
messages: 95198
nosy: jnoller, pitrou
priority: critical
severity: normal
stage: needs patch
status: open
title: multiprocessing should not wait endlessly
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7318>
_______________________________________
From report at bugs.python.org Sat Nov 14 01:15:53 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 14 Nov 2009 00:15:53 +0000
Subject: [New-bugs-announce] [issue7319] Silence DeprecationWarning by
default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
This issue is to track the silencing of DeprecationWarning by default.
To start a patch has been attached against trunk which silences
DeprecationWarning. Documentation changes are still needed, though.
----------
components: Interpreter Core
files: silence_deprecations.diff
keywords: patch
messages: 95220
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Silence DeprecationWarning by default
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15326/silence_deprecations.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7319>
_______________________________________
From report at bugs.python.org Sat Nov 14 05:30:28 2009
From: report at bugs.python.org (David Bolen)
Date: Sat, 14 Nov 2009 04:30:28 +0000
Subject: [New-bugs-announce] [issue7320] Unable to load external modules on
build slave with debug python
In-Reply-To: <1258173028.92.0.517735390444.issue7320@psf.upfronthosting.co.za>
Message-ID: <1258173028.92.0.517735390444.issue7320@psf.upfronthosting.co.za>
New submission from David Bolen <db3l.net at gmail.com>:
As I mentioned in a recent python-dev post, I've noticed that the
Windows build slaves are skipping tests of external modules (like ssl
and bz2).
After finding an old 2.6a0 tree that I had locally built where things
worked fine, I stepped through some 2.6 tags and discovered that this
broke between 2.6 and 2.6.1
The problem appears to be the the change in r67121 for 2.6 (67120 in
trunk) from Nov, 2008 that removed the embedded manifest. With that
change, you can't import the external modules from python_d in PCBuild,
so the tests will skip. Reverting just that change, even on the 2.6.1
source tree, and importing works fine.
So I don't think the external module tests have been running on the
Windows build slave since late 2008.
I tried creating some external manifest files, but haven't been able to
work around the problem so far. Perhaps embedded manifests could be
permitted in debug mode and/or when building for buildbot?
----------
components: Build, Windows
messages: 95227
nosy: db3l
severity: normal
status: open
title: Unable to load external modules on build slave with debug python
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7320>
_______________________________________
From report at bugs.python.org Sat Nov 14 10:08:49 2009
From: report at bugs.python.org (Damian Eads)
Date: Sat, 14 Nov 2009 09:08:49 +0000
Subject: [New-bugs-announce] [issue7321] PyIter_Check(obj) fails when obj is
of type PySetType
In-Reply-To: <1258189729.02.0.287684022873.issue7321@psf.upfronthosting.co.za>
Message-ID: <1258189729.02.0.287684022873.issue7321@psf.upfronthosting.co.za>
New submission from Damian Eads <damian.eads at gmail.com>:
The instructions for the C interface to the Python set class
http://docs.python.org/c-api/set.html
say to use PyObject_GetIter and follow the iterator protocol. After
following the instructions for the iterator protocol here,
http://docs.python.org/c-api/iter.html
I was able to successfully iterate through a set object. However,
PyIter_Check(obj) returns false yet set objects follow the iterator
protocol. Is this the correct behavior?
Thank you.
Kind regards,
Damian Eads
----------
messages: 95229
nosy: damianeads
severity: normal
status: open
title: PyIter_Check(obj) fails when obj is of type PySetType
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7321>
_______________________________________
From report at bugs.python.org Sat Nov 14 18:16:33 2009
From: report at bugs.python.org (David M. Beazley)
Date: Sat, 14 Nov 2009 17:16:33 +0000
Subject: [New-bugs-announce] [issue7322] Socket timeout can cause file-like
readline() method to lose data
In-Reply-To: <1258218993.08.0.764402701678.issue7322@psf.upfronthosting.co.za>
Message-ID: <1258218993.08.0.764402701678.issue7322@psf.upfronthosting.co.za>
New submission from David M. Beazley <beazley at users.sourceforge.net>:
Consider a socket that has had a file-like wrapper placed around it
using makefile()
# s is a socket created previously
f = s.makefile()
Now, suppose that this socket has had a timeout placed on it.
s.settimeout(15)
If you try to read data from f, but nothing is available. You'll
eventually get a timeout. For example:
f.readline() # Now, just wait
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/socket.
py", line 406, in readline
data = self._sock.recv(self._rbufsize)
socket.timeout: timed out
However, now consider the case where you're reading a line of data, but
the receiver has only received a partial line and it's waiting for the
rest of the data to arrive. For example, type this:
f.readline()
Now, go to the other end of the socket connection and send a buffer with
no newline character. For example, send the message "Hello".
Since no newline character has been received, the readline() method will
eventually fail with a timeout as before. However, if you now retry
the read operation f.readline() and send more data such as the message
"World\n", you'll find that the "Hello" message gets lost. In other
words, the repeated readline() operation discards any buffers
corresponding to previously received line data and just returns the new
data.
Admittedly this is a corner case, but you probably don't want data to be
discarded on a TCP connection even if a timeout occurs.
Hope that makes some sense :-). (It helps to try it out).
----------
components: Library (Lib)
messages: 95245
nosy: beazley
severity: normal
status: open
title: Socket timeout can cause file-like readline() method to lose data
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________
From report at bugs.python.org Sat Nov 14 19:39:20 2009
From: report at bugs.python.org (Adam Tomjack)
Date: Sat, 14 Nov 2009 18:39:20 +0000
Subject: [New-bugs-announce] [issue7323] decimal.Decimal greater than/less
than sometimes gives wrong answers when comparing to floats.
In-Reply-To: <1258223960.66.0.3588708996.issue7323@psf.upfronthosting.co.za>
Message-ID: <1258223960.66.0.3588708996.issue7323@psf.upfronthosting.co.za>
New submission from Adam Tomjack <adam at zuerchertech.com>:
These should all return False, or some of them should raise exceptions:
Python 2.6.2 (release26-maint, Apr 19 2009, 01:58:18)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import decimal
>>> decimal.Decimal('0') > 0
False
>>> decimal.Decimal('0') < 0
False
>>> decimal.Decimal('0') > 0.0
True
>>> decimal.Decimal('0') < 0.0
False
>>> 0.0 > decimal.Decimal('0')
False
>>> 0.0 < decimal.Decimal('0')
True
>>> 0.0 < decimal.Decimal('0.0')
True
>>> decimal.Decimal('0') > decimal.Decimal('0')
False
----------
components: Library (Lib)
messages: 95248
nosy: adamtj
severity: normal
status: open
title: decimal.Decimal greater than/less than sometimes gives wrong answers when comparing to floats.
versions: Python 2.4, Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7323>
_______________________________________
From report at bugs.python.org Sat Nov 14 19:43:11 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Nov 2009 18:43:11 +0000
Subject: [New-bugs-announce] [issue7324] Add sanity-check else case to
regrtest option parsing
In-Reply-To: <1258224191.28.0.763058552728.issue7324@psf.upfronthosting.co.za>
Message-ID: <1258224191.28.0.763058552728.issue7324@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
In forward porting a patch to py3k I noticed that there is a 'g' option
in the optparse argument list in regrtest in 2.x that is not present in
3.x. But the surprising thing was that there are no docs for this
option, nor any option handler in the 2.x regrtest.
I propose to add an 'else' case to the option parsing loop that asks the
user to report a bug if it is handed an unknown option. Patch attached.
My one question is whether this might have been intentional for backward
compatibility reasons: let -g be passed and ignore it silently. I'm
guessing it was just a deletion oversight, though.
----------
components: Tests
files: regrtest-detect-bad-option.patch
keywords: patch, patch
messages: 95249
nosy: pitrou, r.david.murray
priority: low
severity: normal
stage: patch review
status: open
title: Add sanity-check else case to regrtest option parsing
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15330/regrtest-detect-bad-option.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7324>
_______________________________________
From report at bugs.python.org Sat Nov 14 20:27:36 2009
From: report at bugs.python.org (Roy Smith)
Date: Sat, 14 Nov 2009 19:27:36 +0000
Subject: [New-bugs-announce] [issue7325] tempfile.mkdtemp() does not return
absolute pathname when dir is specified
In-Reply-To: <1258226856.45.0.72736645389.issue7325@psf.upfronthosting.co.za>
Message-ID: <1258226856.45.0.72736645389.issue7325@psf.upfronthosting.co.za>
New submission from Roy Smith <roy at panix.com>:
The docs (http://www.python.org/doc/2.5.1/lib/module-tempfile.html) specify that
mkdtemp(), "returns the absolute pathname of the new directory". It does that in
the default case, but if you specify a relative path for 'dir', you get back a
relative path.
$ python
Python 2.5.1 (r251:54863, Oct 17 2008, 14:39:09)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-10)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tempfile
>>> tempfile.mkdtemp(dir='.')
'./tmpHk1pBD'
similar results were obtained on:
Python 2.5.1 (r251:54863, Feb 6 2009, 19:02:12)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Note that mkstemp() gets it right:
>>> tempfile.mkdtemp(dir='.')
'./tmpoPXdL7'
>>> tempfile.mkstemp(dir='.')
(3, '/Users/roy2/tmpwTGZ2y')
>>>
----------
components: Library (Lib)
messages: 95256
nosy: roysmith
severity: normal
status: open
title: tempfile.mkdtemp() does not return absolute pathname when dir is specified
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7325>
_______________________________________
From report at bugs.python.org Sun Nov 15 05:59:03 2009
From: report at bugs.python.org (pablo veloz)
Date: Sun, 15 Nov 2009 04:59:03 +0000
Subject: [New-bugs-announce] [issue7326] SOLUTION
pls? /usr/lib/python2.6/dist-packages/visual/__init__.py", line 59,
in <module> import cvisual
AttributeError: 'Boost.Python.StaticProperty' object
attribute '__doc__' is read-only
In-Reply-To: <1258261143.05.0.897261175565.issue7326@psf.upfronthosting.co.za>
Message-ID: <1258261143.05.0.897261175565.issue7326@psf.upfronthosting.co.za>
New submission from pablo veloz <pveloz16 at msn.com>:
sorry for my english, but how can i reparer that problem? help me pls thank.
----------
messages: 95273
nosy: pveloz
severity: normal
status: open
title: SOLUTION pls? /usr/lib/python2.6/dist-packages/visual/__init__.py", line 59, in <module> import cvisual AttributeError: 'Boost.Python.StaticProperty' object attribute '__doc__' is read-only
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7326>
_______________________________________
From report at bugs.python.org Sun Nov 15 11:29:31 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 15 Nov 2009 10:29:31 +0000
Subject: [New-bugs-announce] [issue7327] format: minimum width: UTF-8
separators and decimal points
In-Reply-To: <1258280971.1.0.983226181609.issue7327@psf.upfronthosting.co.za>
Message-ID: <1258280971.1.0.983226181609.issue7327@psf.upfronthosting.co.za>
New submission from Stefan Krah <stefan-usenet at bytereef.org>:
This issue affects the format functions of float and decimal.
When calculating the padding necessary to reach the minimum width,
UTF-8 separators and decimal points are calculated by their byte
lengths. This can lead to printed representations that are too short.
Real world example (separator):
>>> import locale
>>> from decimal import *
>>> locale.setlocale(locale.LC_NUMERIC, "cs_CZ.UTF-8")
'cs_CZ.UTF-8'
>>> s = format(Decimal("-1.5"), ' 019.18n')
>>> len(s)
19
>>> len(s.decode('utf-8'))
16
>>> s
'-0\xc2\xa0000\xc2\xa0000\xc2\xa0001,5'
>>>
>>>
>>> s = format(-1.5, ' 019.18n')
>>> s
'-0\xc2\xa0000\xc2\xa0000\xc2\xa0001,5'
>>> len(s.decode('utf-8'))
16
>>>
Constructed example (separator and decimal point):
>>> u = {'decimal_point' : "\xc2\xbf", 'grouping' : [3, 3, 0],
'thousands_sep': "\xc2\xb4"}
>>> def get_fmt(x, locale, fmt='n'):
... return Decimal.__format__(Decimal(x), fmt, _localeconv=locale)
...
>>> s = get_fmt(Decimal("1.5"), u, "020n")
>>> s
'00\xc2\xb4000\xc2\xb4000\xc2\xb4001\xc2\xbf5'
>>> len(s.decode('utf-8'))
16
----------
messages: 95283
nosy: eric.smith, mark.dickinson, skrah
severity: normal
status: open
title: format: minimum width: UTF-8 separators and decimal points
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7327>
_______________________________________
From report at bugs.python.org Sun Nov 15 15:34:39 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 15 Nov 2009 14:34:39 +0000
Subject: [New-bugs-announce] [issue7328] pydoc doesn't work from the command
line
In-Reply-To: <1258295679.52.0.0670175954257.issue7328@psf.upfronthosting.co.za>
Message-ID: <1258295679.52.0.0670175954257.issue7328@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
This works under 2.x but not 3.x:
$ ./python -m pydoc str
No module named subprocess
----------
components: Library (Lib)
messages: 95297
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: pydoc doesn't work from the command line
type: crash
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7328>
_______________________________________
From report at bugs.python.org Sun Nov 15 16:10:27 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 15 Nov 2009 15:10:27 +0000
Subject: [New-bugs-announce] [issue7329] global statements outside
functions/methods should raise SyntaxError
In-Reply-To: <1258297827.42.0.98275960381.issue7329@psf.upfronthosting.co.za>
Message-ID: <1258297827.42.0.98275960381.issue7329@psf.upfronthosting.co.za>
New submission from Ezio Melotti <ezio.melotti at gmail.com>:
Python currently accepts global statements at the top level:
>>> global foo
>>>
Beside being a meaningless operation, this might lead unexperienced user
to make mistakes like:
>>> foo = 5
>>> global foo # make foo global
>>> def func():
... print foo # access the global foo
...
>>> func()
5
>>> # it works!
"global foo" should raise a SyntaxError, similarly to what already
happens with "return":
>>> return foo
File "<stdin>", line 1
SyntaxError: 'return' outside function
----------
components: Interpreter Core
messages: 95299
nosy: benjamin.peterson, ezio.melotti
priority: normal
severity: normal
status: open
title: global statements outside functions/methods should raise SyntaxError
type: feature request
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7329>
_______________________________________
From report at bugs.python.org Sun Nov 15 20:42:33 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 15 Nov 2009 19:42:33 +0000
Subject: [New-bugs-announce] [issue7330] PyUnicode_FromFormat segfault when
using widths.
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
There seems to be something wrong with the width handling code in
PyUnicode_FromFormat; or perhaps I'm misusing it.
To reproduce: replace the line
return PyUnicode_FromFormat("range(%R, %R)", r->start, r->stop);
in range_repr in Objects/rangeobject.c with
return PyUnicode_FromFormat("range(%20R, %20R)", r->start, r->stop);
On my machine (OS X 10.6), this results in a segfault when invoking
range_repr:
Python 3.2a0 (py3k:76311M, Nov 15 2009, 19:16:40)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> range(0, 10)
Segmentation fault
Perhaps these modifiers aren't supposed to be used with a width?
----------
messages: 95306
nosy: mark.dickinson
severity: normal
status: open
title: PyUnicode_FromFormat segfault when using widths.
type: crash
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7330>
_______________________________________
From report at bugs.python.org Mon Nov 16 07:14:55 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Nov 2009 06:14:55 +0000
Subject: [New-bugs-announce] [issue7331] Command line testing consistency
between 2.x and 3.x
In-Reply-To: <1258352095.53.0.801407348476.issue7331@psf.upfronthosting.co.za>
Message-ID: <1258352095.53.0.801407348476.issue7331@psf.upfronthosting.co.za>
New submission from Nick Coghlan <ncoghlan at gmail.com>:
I ran into a few gratuitous conflicts forward porting the command line
testing cleanup. This should be eliminated by making script_helper
sufficiently flexible to cover both the 2.x and 3.x use cases.
----------
assignee: ncoghlan
components: Tests
keywords: easy
messages: 95322
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Command line testing consistency between 2.x and 3.x
type: behavior
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7331>
_______________________________________
From report at bugs.python.org Mon Nov 16 08:50:34 2009
From: report at bugs.python.org (liang)
Date: Mon, 16 Nov 2009 07:50:34 +0000
Subject: [New-bugs-announce] [issue7332] python script segment fault
at PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
New submission from liang <xfanliang at hotmail.com>:
In our testbed,we have seem serveral sgement fault in our python scrit.
The enviroment is:
linux=2.6.29.6-0.6.smp.gcc4.1.x86_64
python=2.4.4-41.4-1
GCC = GCC 4.1.2 20070626 (rPath Inc.)] on linux2
Below are the detail call stack:
(gdb) bt
#0 PyMarshal_ReadLastObjectFromFile (fp=0x73a550) at
Python/marshal.c:748
#1 0x000000000047bbf9 in read_compiled_module
(cpathname=0x7fff184ba600
"/usr/lib64/python2.4/sre_constants.pyc",
fp=0x73a550) at Python/import.c:728
#2 0x000000000047da2c in load_source_module (name=0x7fff184bc740
"sre_constants", pathname=0x7fff184bb680
"/usr/lib64/python2.4/sre_constants.py", fp=0x737df0)
at Python/import.c:896
#3 0x000000000047e7bd in import_submodule (mod=0x6ea570,
subname=0x7fff184bc740 "sre_constants", fullname=0x7fff184bc740
"sre_constants") at Python/import.c:2276
#4 0x000000000047ec3c in load_next (mod=0x6ea570, altmod=0x6ea570,
p_name=<value optimized out>, buf=0x7fff184bc740
"sre_constants", p_buflen=0x7fff184bc73c)
at Python/import.c:2096
#5 0x000000000047ee47 in PyImport_ImportModuleEx
(name=0x7fff18bac298 "\001",
globals=0x7fff18bac2bc, locals=<value
optimized out>, fromlist=0x7fff18c90990)
at Python/import.c:1931
#6 0x000000000045f963 in builtin___import__ (self=<value optimized
out>,
args=<value optimized out>) at
Python/bltinmodule.c:45
#7 0x00000000004148e0 in PyObject_Call (func=0x73a550, arg=0x73a550,
kw=0x46e829e3) at Objects/abstract.c:1795
#8 0x00000000004628fd in PyEval_CallObjectWithKeywords
(func=0x7fff18ca5440,
arg=0x7fff18c944c8, kw=0x0) at
Python/ceval.c:3435
#9 0x000000000046461a in PyEval_EvalFrame (f=0x744650) at
Python/ceval.c:2020
#10 0x0000000000468ce0 in PyEval_EvalCodeEx (co=0x7fff18c95ab0,
globals=<value
optimized out>, locals=<value optimized out>,
args=0x0, argcount=0, kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2741
#11 0x0000000000468d92 in PyEval_EvalCode (co=0x73a550,
globals=0x73a550,
locals=0x46e829e3) at Python/ceval.c:484
#12 0x000000000047d29a in PyImport_ExecCodeModuleEx
(name=0x7fff184bfce0
"sre_compile", co=0x7fff18c95ab0,
pathname=0x7fff184bdba0 "/usr/lib64/python2.4/sre_compile.pyc")
at Python/import.c:636
#13 0x000000000047d7d0 in load_source_module (name=0x7fff184bfce0
"sre_compile", pathname=0x7fff184bdba0
"/usr/lib64/python2.4/sre_compile.pyc", fp=<value optimized out>)
at Python/import.c:915
#14 0x000000000047e7bd in import_submodule (mod=0x6ea570,
subname=0x7fff184bfce0 "sre_compile", fullname=0x7fff184bfce0
"sre_compile") at Python/import.c:2276
#15 0x000000000047ec3c in load_next (mod=0x6ea570, altmod=0x6ea570,
p_name=<value optimized out>, buf=0x7fff184bfce0
"sre_compile", p_buflen=0x7fff184bfcdc)
at Python/import.c:2096
#16 0x000000000047ee47 in PyImport_ImportModuleEx
(name=0x7fff18c8fbd0 "\001",
globals=0x7fff18c8fbf4, locals=<value
optimized out>, fromlist=0x6ea570) at Python/import.c:1931
#17 0x000000000045f963 in builtin___import__ (self=<value optimized
out>,
args=<value optimized out>) at
Python/bltinmodule.c:45
#18 0x00000000004148e0 in PyObject_Call (func=0x73a550, arg=0x73a550,
kw=0x46e829e3) at Objects/abstract.c:1795
#19 0x00000000004628fd in PyEval_CallObjectWithKeywords
(func=0x7fff18ca5440,
arg=0x7fff18c94208, kw=0x0) at
Python/ceval.c:3435
#20 0x000000000046461a in PyEval_EvalFrame (f=0x7b6680) at
Python/ceval.c:2020
#21 0x0000000000468ce0 in PyEval_EvalCodeEx (co=0x7fff18c95500,
globals=<value
optimized out>, locals=<value optimized out>,
args=0x0, argcount=0, kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2741
#22 0x0000000000468d92 in PyEval_EvalCode (co=0x73a550,
globals=0x73a550,
locals=0x46e829e3) at Python/ceval.c:484
#23 0x000000000047d29a in PyImport_ExecCodeModuleEx
(name=0x7fff184c3280 "sre",
co=0x7fff18c95500, pathname=0x7fff184c1140
"/usr/lib64/python2.4/sre.pyc")
at Python/import.c:636
#24 0x000000000047d7d0 in load_source_module
(name=0x7fff184c3280 "sre",
pathname=0x7fff184c1140
"/usr/lib64/python2.4/sre.pyc", fp=<value optimized out>)
at Python/import.c:915
#25 0x000000000047e7bd in import_submodule (mod=0x6ea570,
subname=0x7fff184c3280 "sre", fullname=0x7fff184c3280 "sre") at
Python/import.c:2276
#26 0x000000000047ec3c in load_next (mod=0x6ea570, altmod=0x6ea570,
p_name=<value optimized out>, buf=0x7fff184c3280 "sre",
p_buflen=0x7fff184c327c) at Python/import.c:2096
#27 0x000000000047ee47 in PyImport_ImportModuleEx
(name=0x7fff18c8cc90 "\001",
globals=0x7fff18c8ccb4, locals=<value
optimized out>, fromlist=0x7fff18c90450)
at Python/import.c:1931
#28 0x000000000045f963 in builtin___import__ (self=<value optimized
out>,
args=<value optimized out>) at
Python/bltinmodule.c:45
#29 0x00000000004148e0 in PyObject_Call (func=0x73a550, arg=0x73a550,
kw=0x46e829e3) at Objects/abstract.c:1795
#30 0x00000000004628fd in PyEval_CallObjectWithKeywords
(func=0x7fff18ca5440,
arg=0x7fff18c83788, kw=0x0) at
Python/ceval.c:3435
#31 0x000000000046461a in PyEval_EvalFrame (f=0x753bb0) at
Python/ceval.c:2020
#32 0x0000000000468ce0 in PyEval_EvalCodeEx (co=0x7fff18c8a7a0,
globals=<value
optimized out>, locals=<value optimized out>,
args=0x0, argcount=0, kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2741
#33 0x0000000000468d92 in PyEval_EvalCode (co=0x73a550,
globals=0x73a550,
locals=0x46e829e3) at Python/ceval.c:484
#34 0x000000000047d29a in PyImport_ExecCodeModuleEx
(name=0x7fff184c6820 "re",
co=0x7fff18c8a7a0, pathname=0x7fff184c46e0
"/usr/lib64/python2.4/re.pyc") at Python/import.c:636
#35 0x000000000047d7d0 in load_source_module (name=0x7fff184c6820 "re",
pathname=0x7fff184c46e0
"/usr/lib64/python2.4/re.pyc", fp=<value optimized out>) at
Python/import.c:915
#36 0x000000000047e7bd in import_submodule (mod=0x6ea570,
subname=0x7fff184c6820 "re", fullname=0x7fff184c6820 "re") at
Python/import.c:2276
#37 0x000000000047ec3c in load_next (mod=0x6ea570, altmod=0x6ea570,
p_name=<value optimized out>, buf=0x7fff184c6820 "re",
p_buflen=0x7fff184c681c) at Python/import.c:2096
#38 0x000000000047ee47 in PyImport_ImportModuleEx
(name=0x7fff18c8ca50 "\032",
globals=0x7fff18c8ca74, locals=<value
optimized out>, fromlist=0x6ea570) at Python/import.c:1931
#39 0x000000000045f963 in builtin___import__ (self=<value optimized
out>,
args=<value optimized out>) at
Python/bltinmodule.c:45
#40 0x00000000004148e0 in PyObject_Call (func=0x73a550, arg=0x73a550,
kw=0x46e829e3) at Objects/abstract.c:1795
#41 0x00000000004628fd in PyEval_CallObjectWithKeywords
(func=0x7fff18ca5440,
arg=0x7fff18c83680, kw=0x0) at
Python/ceval.c:3435
#42 0x000000000046461a in PyEval_EvalFrame (f=0x7932d0) at
Python/ceval.c:2020
#43 0x0000000000468ce0 in PyEval_EvalCodeEx (co=0x7fff18c8a730,
globals=<value
optimized out>, locals=<value optimized out>,
args=0x0, argcount=0, kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2741
#44 0x0000000000468d92 in PyEval_EvalCode (co=0x73a550,
globals=0x73a550,
locals=0x46e829e3) at Python/ceval.c:484
#45 0x000000000047d29a in PyImport_ExecCodeModuleEx
(name=0x7fff184c9dc0
"difflib", co=0x7fff18c8a730,
pathname=0x7fff184c7c80 "/usr/lib64/python2.4/difflib.pyc")
at Python/import.c:636
#46 0x000000000047d7d0 in load_source_module
(name=0x7fff184c9dc0 "difflib",
pathname=0x7fff184c7c80
"/usr/lib64/python2.4/difflib.pyc", fp=<value optimized out>)
at Python/import.c:915
#47 0x000000000047e7bd in import_submodule (mod=0x6ea570,
subname=0x7fff184c9dc0 "difflib", fullname=0x7fff184c9dc0
"difflib") at Python/import.c:2276
#48 0x000000000047ec3c in load_next (mod=0x6ea570, altmod=0x6ea570,
p_name=<value optimized out>, buf=0x7fff184c9dc0
"difflib", p_buflen=0x7fff184c9dbc) at Python/import.c:2096
#49 0x000000000047ee47 in PyImport_ImportModuleEx
(name=0x7fff18cb9300 "\001",
globals=0x7fff18cb9324, locals=<value
optimized out>, fromlist=0x6ea570) at Python/import.c:1931
#50 0x000000000045f963 in builtin___import__ (self=<value optimized
out>,
args=<value optimized out>) at
Python/bltinmodule.c:45
#51 0x00000000004148e0 in PyObject_Call (func=0x73a550, arg=0x73a550,
kw=0x46e829e3) at Objects/abstract.c:1795
#52 0x00000000004628fd in PyEval_CallObjectWithKeywords
(func=0x7fff18ca5440,
arg=0x7fff18c810a8, kw=0x0) at
Python/ceval.c:3435
#53 0x000000000046461a in PyEval_EvalFrame (f=0x7921c0) at
Python/ceval.c:2020
#54 0x0000000000468ce0 in PyEval_EvalCodeEx (co=0x7fff18623490,
globals=<value
optimized out>, locals=<value optimized out>,
args=0x0, argcount=0, kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2741
#55 0x0000000000468d92 in PyEval_EvalCode (co=0x73a550,
globals=0x73a550,
locals=0x46e829e3) at Python/ceval.c:484
#56 0x00000000004853d9 in run_node (n=<value optimized out>,
filename=<value
optimized out>, globals=0x718650,
locals=0x718650, flags=<value optimized out>)
at Python/pythonrun.c:1285
#57 0x00000000004868b8 in PyRun_SimpleFileExFlags (fp=<value optimized
out>,
filename=0x7fff184ccbcc
"/usr/local/maui/ganglia/lib/ganglia/python_modules/maui_svc.py",
closeit=1, flags=0x7fff184cb350) at Python/pythonrun.c:869
#58 0x000000000041168d in Py_Main (argc=<value optimized out>,
argv=0x7fff184cb478) at Modules/main.c:493
#59 0x00007fff177f48a4 in __libc_start_main () from /lib64/libc.so.6
#60 0x0000000000410a59 in _start ()
Segment fault when it try to load sre_constants.pyc.
Another stack:
#0 PyMarshal_ReadLastObjectFromFile (fp=0x7f33f0) at
Python/marshal.c:748
#1 0x000000000047bbf9 in read_compiled_module
(cpathname=0x7fff069fe830
"/usr/lib64/python2.4/inspect.pyc", fp=0x7f33f0) at Python/import.c:728
#2 0x000000000047da2c in load_source_module
(name=0x7fff06a00970 "inspect",
pathname=0x7fff069ff8b0 "/usr/lib64/python2.4/inspect.py",
fp=0x7d97d0) at
Python/import.c:896
#3 0x000000000047e7bd in import_submodule (mod=0x6ea570,
subname=0x7fff06a00970 "inspect", fullname=0x7fff06a00970 "inspect") at
Python/import.c:2276
#4 0x000000000047ec3c in load_next (mod=0x6ea570, altmod=0x6ea570,
p_name=<value optimized out>, buf=0x7fff06a00970 "inspect",
p_buflen=0x7fff06a0096c) at Python/import.c:2096
Segment fault when it try to load inspect.pyc.
Another core at:
(gdb) bt
#0 PyMarshal_ReadLastObjectFromFile (fp=0x7dd190) at
Python/marshal.c:748
#1 0x000000000047bbf9 in read_compiled_module
(cpathname=0x7fff1bc03de0
"/usr/lib64/python2.4/string.pyc", fp=0x7dd190) at Python/import.c:728
#2 0x000000000047da2c in load_source_module
(name=0x7fff1bc05f20 "string",
pathname=0x7fff1bc04e60 "/usr/lib64/python2.4/string.py", fp=0x7dc6f0)
at
Python/import.c:896
#3 0x000000000047e7bd in import_submodule (mod=0x6ea570,
subname=0x7fff1bc05f20 "string", fullname=0x7fff1bc05f20 "string") at
Python/import.c:2276
#4 0x000000000047ec3c in load_next (mod=0x6ea570, altmod=0x6ea570,
p_name=<value optimized out>, buf=0x7fff1bc05f20 "string",
p_buflen=0x7fff1bc05f1c) at Python/import.c:2096
#5 0x000000000047ee47 in PyImport_ImportModuleEx
(name=0x7fff1c6694b0 "\001",
globals=0x7fff1c6694d4, locals=<value optimized out>,
fromlist=0x6ea570) at
Python/import.c:1931
#6 0x000000000045f963 in builtin___import__ (self=<value optimized
out>,
args=<value optimized out>) at Python/bltinmodule.c:45
#7 0x00000000004148e0 in PyObject_Call (func=0x7dd190, arg=0x7dd190,
kw=0x46e829e3) at Objects/abstract.c:1795
#8 0x00000000004628fd in PyEval_CallObjectWithKeywords
(func=0x7fff1c741440,
arg=0x7fff1c663890, kw=0x0) at Python/ceval.c:3435
#9 0x000000000046461a in PyEval_EvalFrame (f=0x744650) at
Python/ceval.c:2020
#10 0x0000000000468ce0 in PyEval_EvalCodeEx (co=0x7fff1c66a8f0,
globals=<value
optimized out>, locals=<value optimized out>, args=0x0, argcount=0,
kws=0x0,
kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2741
#11 0x0000000000468d92 in PyEval_EvalCode (co=0x7dd190,
globals=0x7dd190,
locals=0x46e829e3) at Python/ceval.c:484
#12 0x000000000047d29a in PyImport_ExecCodeModuleEx
(name=0x7fff1bc094c0
"inspect", co=0x7fff1c66a8f0, pathname=0x7fff1bc07380
"/usr/lib64/python2.4/inspect.pyc") at Python/import.c:636
#13 0x000000000047d7d0 in load_source_module
(name=0x7fff1bc094c0 "inspect",
pathname=0x7fff1bc07380 "/usr/lib64/python2.4/inspect.pyc", fp=<value
optimized
out>) at Python/import.c:915
#14 0x000000000047e7bd in import_submodule (mod=0x6ea570,
subname=0x7fff1bc094c0 "inspect", fullname=0x7fff1bc094c0 "inspect") at
Python/import.c:2276
#15 0x000000000047ec3c in load_next (mod=0x6ea570, altmod=0x6ea570,
p_name=<value optimized out>, buf=0x7fff1bc094c0 "inspect",
p_buflen=0x7fff1bc094bc) at Python/import.c:2096
#16 0x000000000047ee47 in PyImport_ImportModuleEx
(name=0x7fff1c65dba0 "\002",
globals=0x7fff1c65dbc4, locals=<value optimized out>,
fromlist=0x6ea570) at
Python/import.c:1931
Segment fault when it try to load string.pyc.
We have seen it several times.However,the script is long running and
we can not sure how it happened and how to make it reproduce.
Does anyone have any ideas on this?
----------
components: Interpreter Core
messages: 95325
nosy: liang
severity: normal
status: open
title: python script segment fault at PyMarshal_ReadLastObjectFromFile in import_submodule
type: crash
versions: Python 2.4
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________
From report at bugs.python.org Mon Nov 16 15:57:40 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 16 Nov 2009 14:57:40 +0000
Subject: [New-bugs-announce] [issue7333] Add initgroups to the posix/os
modules
In-Reply-To: <1258383460.23.0.536261315778.issue7333@psf.upfronthosting.co.za>
Message-ID: <1258383460.23.0.536261315778.issue7333@psf.upfronthosting.co.za>
New submission from Jean-Paul Calderone <exarkun at divmod.com>:
initgroups(2) is a function for initializing the aux group id list from
site-specific configuration (typically /etc/groups, but not necessarily).
Attached is a patch based on some code from Zope, expanded to have a
test and some docs. Presumably Zope will be happy to use this function
from the stdlib once they can depend on a version of Python which
includes it. Twisted would like to as well.
I wasn't able to test the autoconf related parts of the patch as I don't
have easy access to autoconf 2.61.
I also can't run regrtest.py in my environment for some reason. It
fails to import some names from test_support. So I didn't run the unit
test that I added, either.
----------
components: Library (Lib)
files: initgroups.patch
keywords: patch
messages: 95348
nosy: exarkun
severity: normal
status: open
title: Add initgroups to the posix/os modules
versions: Python 2.7
Added file: http://bugs.python.org/file15345/initgroups.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7333>
_______________________________________
From report at bugs.python.org Mon Nov 16 16:56:08 2009
From: report at bugs.python.org (Gareth Doutch)
Date: Mon, 16 Nov 2009 15:56:08 +0000
Subject: [New-bugs-announce] [issue7334] XML file locking in Jython 2.5
(OSError on Windows)
In-Reply-To: <1258386968.95.0.507644857951.issue7334@psf.upfronthosting.co.za>
Message-ID: <1258386968.95.0.507644857951.issue7334@psf.upfronthosting.co.za>
New submission from Gareth Doutch <gareth.doutch at gmail.com>:
I have a problem with an xml file locking after read and/or write.
I have a short sample code with unit test available here:
http://bugs.jython.org/file741/lock.py
Below are the
outputs from Jython and CPython (v 2.5.4).
I am using Jython 2.5.1 on Windows XP and java version "1.6.0_16".
>jython lock.py
E
======================================================================
ERROR: runTest (__main__.TestDelete)
----------------------------------------------------------------------
Traceback (most recent call last):
File "W:\testTeam\SIT\JySit\sit\scripts\lock.py", line 73, in tearDown
os.remove(self.fileName)
File "C:\jython2.5.1\Lib\os.py", line 342, in remove
raise OSError(0, "couldn't delete file", path)
OSError: [Errno 0] couldn't delete file: 'C:\\testdir\\test.xml'
----------------------------------------------------------------------
Ran 1 test in 0.454s
FAILED (errors=1)
>python lock.py
.
----------------------------------------------------------------------
Ran 1 test in 0.015s
OK
The problem can be cured by applying the changes as per file:
http://bugs.jython.org/file742/ElementTree.py
----------
components: Windows, XML
messages: 95349
nosy: gdoutch
severity: normal
status: open
title: XML file locking in Jython 2.5 (OSError on Windows)
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7334>
_______________________________________
From report at bugs.python.org Mon Nov 16 19:28:41 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 16 Nov 2009 18:28:41 +0000
Subject: [New-bugs-announce] [issue7335] int/long discrepancy when
formatting zero with ".0d"
In-Reply-To: <1258396121.34.0.904400229223.issue7335@psf.upfronthosting.co.za>
Message-ID: <1258396121.34.0.904400229223.issue7335@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
In Python 2.x we have:
>>> "%.0d" % 0
''
>>> "%.0d" % 0L
'0'
In Python 3.x:
>>> "%.0d" % 0
'0'
I think the 2.x behaviour for int comes directly from C's sprintf
behaviour: section 7.19.6.1, p8 of the C99 standard says:
"The result of converting a zero value with a precision of zero is no
characters."
I'm not sure which the more sensible behaviour is, but in 2.x, int and
long should behave in the same way. Fixing long to behave like int
seems both simplest and least likely to break existing code.
----------
components: Interpreter Core
messages: 95356
nosy: eric.smith, mark.dickinson
priority: normal
severity: normal
status: open
title: int/long discrepancy when formatting zero with ".0d"
type: behavior
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7335>
_______________________________________
From report at bugs.python.org Tue Nov 17 00:23:59 2009
From: report at bugs.python.org (R. Tyler Ballance)
Date: Mon, 16 Nov 2009 23:23:59 +0000
Subject: [New-bugs-announce] [issue7336] threading module not properly
handling shutdown
In-Reply-To: <1258413839.38.0.430585773151.issue7336@psf.upfronthosting.co.za>
Message-ID: <1258413839.38.0.430585773151.issue7336@psf.upfronthosting.co.za>
New submission from R. Tyler Ballance <tyler at monkeypox.org>:
Receiving a traceback when shutting down an interpreter with threads
spawned inside of it:
Traceback (most recent call last):
File "/usr/lib/python2.6/threading.py", line 497, in __bootstrap
self.__bootstrap_inner()
File "/usr/lib/python2.6/threading.py", line 538, in __bootstrap_inner
(self.name, _format_exc()))
File "/usr/lib/python2.6/traceback.py", line 235, in format_exc
etype, value, tb = sys.exc_info()
AttributeError: 'NoneType' object has no attribute 'exc_info'
According to mzz on #Python:
17:29 < mzz> rtyler: I think this is worth a bug report. If you look up
threading.py:538 you'll find (assuming our line numbers match) that bit
of code actually goes out of its way to deal with the shutdown problem
I mentioned, but then it calls into the traceback module, which doesn't.
----------
components: Interpreter Core
messages: 95361
nosy: rtyler
severity: normal
status: open
title: threading module not properly handling shutdown
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7336>
_______________________________________
From report at bugs.python.org Tue Nov 17 11:40:40 2009
From: report at bugs.python.org (Ben Bass)
Date: Tue, 17 Nov 2009 10:40:40 +0000
Subject: [New-bugs-announce] [issue7337] Add lossy queue to queue library
module
In-Reply-To: <1258454440.69.0.147012340761.issue7337@psf.upfronthosting.co.za>
Message-ID: <1258454440.69.0.147012340761.issue7337@psf.upfronthosting.co.za>
New submission from Ben Bass <benpaulbass at googlemail.com>:
Many applications would benefit from 'connectionless' queues, i.e. they
don't want to care whether anything is reading from the other end.
Using current queue module classes this is not practical, because there
is a choice between unbounded memory consumption or blocking. I propose
adding a 'LossyQueue' class in the queue module which would allow
bounded memory consumption without blocking on put. (i.e. items are
dropped in fifo manner beyond a certain limit). In my view this is at
least as natural as the PriorityQueue and LifoQueue extensions in that
module.
Outline as follows:
class LossyQueue(Queue):
"Queue subclass which drops items on overflow"
def _init(self, maxsize):
if maxsize > 0:
# build the deque with maxsize limit
self.queue = deque(maxlen=maxsize)
else:
# same as normal Queue instance
self.queue = collections.deque()
# deque alone handles maxsize,
# so we pretend we have none
self.maxsize = 0
if there is interest in this I will offer a proper patch with docs and
tests.
----------
components: Library (Lib)
messages: 95374
nosy: bpb
severity: normal
status: open
title: Add lossy queue to queue library module
type: feature request
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7337>
_______________________________________
From report at bugs.python.org Tue Nov 17 12:01:34 2009
From: report at bugs.python.org (kai zhu)
Date: Tue, 17 Nov 2009 11:01:34 +0000
Subject: [New-bugs-announce] [issue7338] recursive __attribute__ -> Fatal
Python error: Cannot recover from stack overflow.
In-Reply-To: <1258455694.17.0.877793280726.issue7338@psf.upfronthosting.co.za>
Message-ID: <1258455694.17.0.877793280726.issue7338@psf.upfronthosting.co.za>
New submission from kai zhu <kaizhu256 at gmail.com>:
Python 3.1.1 (r311:74480, Sep 13 2009, 17:17:12)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class Foo(object):
... def __getattribute__(self, attr):
... try: return object.__getattribute__(attr)
... except: return self.x
...
>>> Foo().y
Fatal Python error: Cannot recover from stack overflow.
Aborted
$
python2.6 recovers from above w/ a RuntimeError
----------
components: Interpreter Core
messages: 95381
nosy: kaizhu
severity: normal
status: open
title: recursive __attribute__ -> Fatal Python error: Cannot recover from stack overflow.
type: crash
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7338>
_______________________________________
From report at bugs.python.org Tue Nov 17 17:39:11 2009
From: report at bugs.python.org (Paul Colomiets)
Date: Tue, 17 Nov 2009 16:39:11 +0000
Subject: [New-bugs-announce] [issue7339] bsddb crashes when transaction
limit occurs
In-Reply-To: <1258475951.23.0.0144447092049.issue7339@psf.upfronthosting.co.za>
Message-ID: <1258475951.23.0.0144447092049.issue7339@psf.upfronthosting.co.za>
New submission from Paul Colomiets <pc at gafol.net>:
When maximum transaction number exceeded and DBEnv->txn_begin returns
with error ENOMEM, error with following traceback occur:
#0 0x0000000803d4fa48 in DBTxn_dealloc (self=0x846480648) at _bsddb.c:1235
#1 0x0000000803d506dc in newDBTxnObject (myenv=0x804c23d98, parent=0x0,
txn=Variable "txn" is not available.
) at _bsddb.c:1179
#2 0x0000000803d50770 in DBEnv_txn_begin (self=0x804c23d98,
args=Variable "args" is not available.
) at _bsddb.c:4584
#3 0x0000000000523ea4 in PyCFunction_Call ()
[..snip..]
I believe that following patch will fix that problem:
Index: Modules/_bsddb.c
===================================================================
--- Modules/_bsddb.c (revision 76338)
+++ Modules/_bsddb.c (working copy)
@@ -1232,7 +1232,7 @@
if (self->env) {
Py_DECREF(self->env);
} else {
- Py_DECREF(self->parent_txn);
+ Py_XDECREF(self->parent_txn);
}
PyObject_Del(self);
}
Seems that normally either env or parent_txn attribute is not null but
when transaction where not created it's untrue (look at the end of
newDBTxnObject if you don't trust :) )
----------
components: Library (Lib)
messages: 95389
nosy: pc
severity: normal
status: open
title: bsddb crashes when transaction limit occurs
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7339>
_______________________________________
From report at bugs.python.org Tue Nov 17 19:12:47 2009
From: report at bugs.python.org (Greg Hewgill)
Date: Tue, 17 Nov 2009 18:12:47 +0000
Subject: [New-bugs-announce] [issue7340] Doc for sys.exc_info has warning
that is no longer valid
In-Reply-To: <1258481567.01.0.124523901293.issue7340@psf.upfronthosting.co.za>
Message-ID: <1258481567.01.0.124523901293.issue7340@psf.upfronthosting.co.za>
New submission from Greg Hewgill <greg at hewgill.com>:
Based on a short discussion on python-dev:
http://mail.python.org/pipermail/python-dev/2009-November/094306.html
the "Warning" box in the documentation for sys.exc_info needs to be
updated in light of PEP 3134, and perhaps moved elsewhere since the
circular reference problem can now occur whether or not the traceback
returned by sys.exc_info is used.
It might also be worth mentioning that the way to break the circular
reference, if necessary, is to explicitly set the __traceback__ member
of the handled exception to None.
----------
assignee: georg.brandl
components: Documentation
messages: 95393
nosy: georg.brandl, ghewgill
severity: normal
status: open
title: Doc for sys.exc_info has warning that is no longer valid
type: behavior
versions: Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7340>
_______________________________________
From report at bugs.python.org Tue Nov 17 20:50:18 2009
From: report at bugs.python.org (Paul Moore)
Date: Tue, 17 Nov 2009 19:50:18 +0000
Subject: [New-bugs-announce] [issue7341] test_tarfile failing (file in use
when deleting) on Windows buildbots
In-Reply-To: <1258487418.77.0.523197359999.issue7341@psf.upfronthosting.co.za>
Message-ID: <1258487418.77.0.523197359999.issue7341@psf.upfronthosting.co.za>
New submission from Paul Moore <p.f.moore at gmail.com>:
Windows 3.x buildbots are failing in test_tarfile.
The problem, as best I can diagnose it, appears to be a failure
somewhere in the tarfile module to close files on exceptions. The error
is "WindowsError: [Error 32] The process cannot access the file because
it is being used by another process", but I am pretty sure it's actually
the *same* process which still has an open handle on the file. The
problem occurs around test_append_gz, which tries to open the tarfile
but expects an error. I think when the call raises the error, it is
leaving a filehandle open, which is what causes the delete in setUp to fail.
----------
components: Library (Lib), Tests
keywords: buildbot
messages: 95395
nosy: pmoore
priority: normal
severity: normal
status: open
title: test_tarfile failing (file in use when deleting) on Windows buildbots
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7341>
_______________________________________
From report at bugs.python.org Tue Nov 17 23:02:51 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 17 Nov 2009 22:02:51 +0000
Subject: [New-bugs-announce] [issue7342] str(datetime_obj) doesn't include
microseconds if their value is 0
In-Reply-To: <1258495371.1.0.197938868538.issue7342@psf.upfronthosting.co.za>
Message-ID: <1258495371.1.0.197938868538.issue7342@psf.upfronthosting.co.za>
New submission from Ezio Melotti <ezio.melotti at gmail.com>:
Last night, test_strptime failed on one of the buildbots [1] with the
following error:
test test_strptime failed -- Traceback (most recent call last):
File
"C:\buildslave\3.x.moore-windows\build\lib\test\test_strptime.py", line
279, in test_fraction
tup, frac = _strptime._strptime(str(now), format="%Y-%m-%d %H:%M:%S.%f")
File "C:\buildslave\3.x.moore-windows\build\lib\_strptime.py", line
332, in _strptime
(data_string, format))
ValueError: time data '2009-11-16 17:17:14' does not match format
'%Y-%m-%d %H:%M:%S.%f'
The reason is that the __str__ method of datetime objects
(datetime.now() in the test) adds the trailing .%f only if the
microseconds are != 0. Since the possible values of microseconds are
between 0 and 999999 (both included), there is 1 possibility out of
1000000 that the microseconds of datetime.now() are equal to 0 (and
depending on how the value is incremented it might not include 0 among
the possible values at all). Apparently that was the cause of the
failure in the test.
This can be reproduced easily doing:
>>> from datetime import datetime
>>> str(datetime.now())
'2009-11-17 22:11:23.522951'
>>> str(datetime(2012, 12, 21)) # no microseconds
'2012-12-21 00:00:00'
This behavior is defined in Modules/datetimemodule.c, in the C function
datetime_isoformat (line 4145 on py3k, introduced by tim_one in r30151)
and in isoformat_time (line 1278 on trunk, called by datetime_isoformat,
introduced by walter.doerwald in r55714).
Is there a valid reason to omit the microseconds in case they are equal
to 0 instead of just adding the trailing '.000000'?
If the behavior doesn't change the test can be probably fixed checking
the value of the microseconds before the call to str(). The
documentation and other tests to check this should also be added.
(Thanks to R. David Murray for pointing me in the right direction while
I was investigating the problem.)
[1]:
http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/52/steps/test/logs/stdio
----------
assignee: georg.brandl
components: Documentation, Extension Modules, Tests
messages: 95404
nosy: doerwalter, ezio.melotti, georg.brandl, r.david.murray, tim_one
priority: low
severity: normal
stage: test needed
status: open
title: str(datetime_obj) doesn't include microseconds if their value is 0
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7342>
_______________________________________
From report at bugs.python.org Wed Nov 18 06:46:04 2009
From: report at bugs.python.org (Jared Grubb)
Date: Wed, 18 Nov 2009 05:46:04 +0000
Subject: [New-bugs-announce] [issue7343] "What's new in 3.0" says % operator
will be deprecated in 3.1
In-Reply-To: <1258523164.66.0.0511843184453.issue7343@psf.upfronthosting.co.za>
Message-ID: <1258523164.66.0.0511843184453.issue7343@psf.upfronthosting.co.za>
New submission from Jared Grubb <python at jaredgrubb.com>:
The existing text:
http://www.python.org/doc/3.0/whatsnew/3.0.html
"A new system for built-in string formatting operations replaces the %
string formatting operator. (However, the % operator is still supported;
it will be deprecated in Python 3.1 and removed from the language at
some later time.) Read PEP 3101 for the full scoop."
Python 3.1 did not deprecate the % operator, right? Is it appropriate to
edit the 3.0 docs to reflect that?
----------
assignee: georg.brandl
components: Documentation
messages: 95411
nosy: georg.brandl, jaredgrubb
severity: normal
status: open
title: "What's new in 3.0" says % operator will be deprecated in 3.1
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7343>
_______________________________________
From report at bugs.python.org Wed Nov 18 12:50:07 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Nov 2009 11:50:07 +0000
Subject: [New-bugs-announce] [issue7344] wsgiref tests failing on Windows 7
buildbot
In-Reply-To: <1258545007.71.0.460260425004.issue7344@psf.upfronthosting.co.za>
Message-ID: <1258545007.71.0.460260425004.issue7344@psf.upfronthosting.co.za>
New submission from Nick Coghlan <ncoghlan at gmail.com>:
As the subject line says: the wsgiref unit tests fail on the new Windows
7 buildbot.
It appears to be happening every run, but here's one example:
http://www.python.org/dev/buildbot/trunk/builders/x86%20Windows7%20trunk/builds/25/steps/test/logs/stdio
----------
keywords: buildbot
messages: 95421
nosy: ncoghlan
severity: normal
status: open
title: wsgiref tests failing on Windows 7 buildbot
type: behavior
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7344>
_______________________________________
From report at bugs.python.org Wed Nov 18 17:11:44 2009
From: report at bugs.python.org (dingle)
Date: Wed, 18 Nov 2009 16:11:44 +0000
Subject: [New-bugs-announce] [issue7345] calendar.TextCalendar().formatyear
wrong argument list
In-Reply-To: <1258560704.19.0.583792221573.issue7345@psf.upfronthosting.co.za>
Message-ID: <1258560704.19.0.583792221573.issue7345@psf.upfronthosting.co.za>
New submission from dingle <xinjiang.lu at gmail.com>:
class calendar.TextCalendar([firstweekday]):
formatyear(theyear, themonth[, w[, l[, c[, m]]]])
Should delete "themonth". Found this problem with all 2.6, 2.7, 3K
documentation.
----------
assignee: georg.brandl
components: Documentation
messages: 95430
nosy: dingle, georg.brandl
severity: normal
status: open
title: calendar.TextCalendar().formatyear wrong argument list
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7345>
_______________________________________
From report at bugs.python.org Wed Nov 18 18:15:33 2009
From: report at bugs.python.org (Ecir Hana)
Date: Wed, 18 Nov 2009 17:15:33 +0000
Subject: [New-bugs-announce] [issue7346] Redirected stdout fires [Errno 9]
In-Reply-To: <1258564533.69.0.0908463291045.issue7346@psf.upfronthosting.co.za>
Message-ID: <1258564533.69.0.0908463291045.issue7346@psf.upfronthosting.co.za>
New submission from Ecir Hana <ecir.hana at gmail.com>:
I try to log all the output of a program written in Python and C to a
buffer. I create a pipe, redirect stdout to its write-end and then read
its content afterward. However, printing from Python fires "IOError:
[Errno 9] Bad file descriptor". Please see the attached test-case.
It is happening on Windows XP, Python 2.6 and MinGW GCC and I used this
to compile:
gcc -o std.exe std.c -Ic:/dev/include/python2.6 -l python26
PS: It might be that the problem is that Python was compiled with
MSVC2008 and I'm using MinGW but I'm not sure...
----------
components: IO, Windows
files: std.c
messages: 95433
nosy: ecir.hana
severity: normal
status: open
title: Redirected stdout fires [Errno 9]
versions: Python 2.6
Added file: http://bugs.python.org/file15358/std.c
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7346>
_______________________________________
From report at bugs.python.org Wed Nov 18 18:48:15 2009
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 18 Nov 2009 17:48:15 +0000
Subject: [New-bugs-announce] [issue7347] Patch - add RegCreateKeyEx to
_winreg
In-Reply-To: <1258566495.76.0.636986979508.issue7347@psf.upfronthosting.co.za>
Message-ID: <1258566495.76.0.636986979508.issue7347@psf.upfronthosting.co.za>
New submission from Brian Curtin <curtin at acm.org>:
The _winreg module could use the addition of the RegCreateKeyEx call, as
evidenced by this thread on c.l.py:
http://mail.python.org/pipermail/python-list/2009-November/614023.html
This expanded API would benefit users trying to create keys with access
masks (like KEY_WOW64_64KEY), which you can't set through _winreg.CreateKey.
The patch includes the change to _winreg.c, along with doc and test
changes. Comments/suggestions appreciated.
----------
components: Extension Modules
files: winreg_add_createkeyex.patch
keywords: patch
messages: 95434
nosy: brian.curtin
severity: normal
status: open
title: Patch - add RegCreateKeyEx to _winreg
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file15359/winreg_add_createkeyex.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7347>
_______________________________________
From report at bugs.python.org Wed Nov 18 19:58:36 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 18 Nov 2009 18:58:36 +0000
Subject: [New-bugs-announce] [issue7348] StringIO.StringIO.readline(-1)
returns the wrong result compared to other file-like objects
In-Reply-To: <1258570716.97.0.757460234956.issue7348@psf.upfronthosting.co.za>
Message-ID: <1258570716.97.0.757460234956.issue7348@psf.upfronthosting.co.za>
New submission from Jean-Paul Calderone <exarkun at divmod.com>:
cStringIO and file both accept -1 to readline to mean the same thing as
not passing any argument at all. StringIO, on the other hand, gets
totally confused:
>>> from StringIO import StringIO
>>> StringIO('a\nb\nfoo').readline(-1)
'a\nb\nfo'
>>>
----------
components: Library (Lib)
messages: 95438
nosy: exarkun
severity: normal
status: open
title: StringIO.StringIO.readline(-1) returns the wrong result compared to other file-like objects
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7348>
_______________________________________
From report at bugs.python.org Wed Nov 18 20:01:54 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 18 Nov 2009 19:01:54 +0000
Subject: [New-bugs-announce] [issue7349] StringIO.StringIO, io.BytesIO,
and io.StringIO accept None in places where other file-like
objects don't
In-Reply-To: <1258570914.64.0.211682819163.issue7349@psf.upfronthosting.co.za>
Message-ID: <1258570914.64.0.211682819163.issue7349@psf.upfronthosting.co.za>
New submission from Jean-Paul Calderone <exarkun at divmod.com>:
The actual file type rejects None in places like as the argument to read
or readlines. StringIO.StringIO, io.BytesIO, and io.StringIO all accept
None to mean the same as passing no argument at all.
This makes it tricky to write code that might operate on any of these
types (as many APIs accepting a "file-like object" try to). Testing
with one will not demonstrate that code works with any. In particular,
it's common to start test with StringIO, which is more liberal, and only
discover a problem when code is run for real against an actual file.
----------
components: Library (Lib)
messages: 95439
nosy: exarkun
severity: normal
status: open
title: StringIO.StringIO, io.BytesIO, and io.StringIO accept None in places where other file-like objects don't
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7349>
_______________________________________
From report at bugs.python.org Wed Nov 18 20:11:55 2009
From: report at bugs.python.org (Eric Torstenson)
Date: Wed, 18 Nov 2009 19:11:55 +0000
Subject: [New-bugs-announce] [issue7350] csv doesn't handle escaped
characters properly
In-Reply-To: <1258571515.92.0.182844984253.issue7350@psf.upfronthosting.co.za>
Message-ID: <1258571515.92.0.182844984253.issue7350@psf.upfronthosting.co.za>
New submission from Eric Torstenson <e_torstenson at hotmail.com>:
When I use CSV with a separator, if there is an escaped separator in the
field, it causes the next field to become part of the current one:
file = csv.reader(open(filename), delimiter='\t', quotechar="'")
for words in file:
print words[0-8]
If, say line 3 contains: '1709' 'PF01322' 'Cytochrom_C_2'
'Cytochrome_C_2; ' 'Cytochrome C\'' 'Finn RD, Bateman A' 'anon' 'Sarah
Teichmann'
Column 4 will be printed as:
Cytochrome C\'\tFinn RD, Bateman A'
I've checked this with a spreadsheet application, and it opened this
line just fine, but when I used csv to parse, I had to remove that
escaped single quote to get my columns to work out properly for that line.
----------
components: Extension Modules
messages: 95441
nosy: est_python_tracker
severity: normal
status: open
title: csv doesn't handle escaped characters properly
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7350>
_______________________________________
From report at bugs.python.org Wed Nov 18 20:12:35 2009
From: report at bugs.python.org (Retro)
Date: Wed, 18 Nov 2009 19:12:35 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue7351=5D_Documentation_typos?=
=?utf-8?q?_found_in_=22zipfile_=E2=80=94_Work_with_ZIP_archives=22?=
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
New submission from Retro <vinetouu at gmail.com>:
There are some minor typos in the docs. The section zipfile has twp typos:
exception zipfile.BadZipfile
The error raised for bad ZIP files (old name: zipfile.error).
this should be
exception zipfile.BadZipFile
The error raised for bad ZIP files (old name: zipfile.error).
Note: There needs to be a capital F in the exception class name BadZipFile.
There's also a typo in the sentence "Decryption is extremely slow as it
is implemented in native python rather than C." which should be
"Decryption is extremely slow as it is implemented in native Python
rather than C." This sentence is found just above the previous
BadZipfile typo.
Note: The word 'python' is needed to be capitalized.
These typos exist since the creation of the zipfile docs. Please correct
the docs for the selected versions. Thank you.
----------
assignee: georg.brandl
components: Documentation
messages: 95442
nosy: Retro, georg.brandl
severity: normal
status: open
title: Documentation typos found in "zipfile ? Work with ZIP archives"
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________
From report at bugs.python.org Wed Nov 18 21:58:57 2009
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois_Mauger?=)
Date: Wed, 18 Nov 2009 20:58:57 +0000
Subject: [New-bugs-announce] [issue7352] python2.6-config --ldflags out of
/usr and missing -L<install_lib_dir>
Message-ID: <1258577937.58.0.058967075582.issue7352@psf.upfronthosting.co.za>
Changes by Fran?ois Mauger <mauger at lpccaen.in2p3.fr>:
----------
components: Installation
nosy: mauger
severity: normal
status: open
title: python2.6-config --ldflags out of /usr and missing -L<install_lib_dir>
type: feature request
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7352>
_______________________________________
From report at bugs.python.org Wed Nov 18 22:05:41 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 18 Nov 2009 21:05:41 +0000
Subject: [New-bugs-announce] [issue7353] Why was Include/intobject.h removed
in 3.1?
In-Reply-To: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za>
Message-ID: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za>
New submission from Dave Malcolm <dmalcolm at redhat.com>:
I'm attempting to package Python 3 for a Linux distribution, together with a stack of python extension
modules; I'm currently using Python-3.1.1. (see https://fedoraproject.org/wiki/Features/Python3F13 )
Many of these extension modules are close to compiling under both python 2 and python 3.
The page "http://wiki.python.org/moin/PortingExtensionModulesToPy3k" refers to using the macros in
intobject.h, so that all PyInt_* calls in the python 3 build are aliased to PyLong_ API hooks.
Similarly, the page: http://docs.python.org/howto/cporting.html recommends using this file.
However, that header file was removed in this commit:
http://svn.python.org/view?view=rev&revision=71697
with this message:
Issue #4910: PyNumber_Int is deprecated in 3.0.1; will be removed in 3.1.
(which links to this issue: http://bugs.python.org/issue4910 ; that issue refers to removal of the
nb_long slot).
This seems to make it harder to port modules.
Is is acceptable if I ship that header file in my distribution packages of python-3.1.1 ? (possibly
with a reworded deprecation warning?)
Alternatively, is the fix to migrate all usage of the PyInt_ API to the PyLong_ equivalents ? That
would cause a change of behavior for the python 2 builds, assuming a shared source tree.
(I'd much prefer to ship the latest in the py3k branch than to stay with 3.0.1 for this)
In any case, it seems like the porting documentation isn't in sync with the code.
Hope this is helpful.
----------
components: Interpreter Core
messages: 95455
nosy: dmalcolm
severity: normal
status: open
title: Why was Include/intobject.h removed in 3.1?
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7353>
_______________________________________
From report at bugs.python.org Thu Nov 19 00:48:42 2009
From: report at bugs.python.org (Paul Moore)
Date: Wed, 18 Nov 2009 23:48:42 +0000
Subject: [New-bugs-announce] [issue7354] distutils.tests.test_msvc9compiler
- dragfullwindows can have value 2
In-Reply-To: <1258588122.3.0.424936986144.issue7354@psf.upfronthosting.co.za>
Message-ID: <1258588122.3.0.424936986144.issue7354@psf.upfronthosting.co.za>
New submission from Paul Moore <p.f.moore at gmail.com>:
It looks like the "Control Panel\Desktop\dragfullwindows" registry entry
can have value 2 (it does on my buildbot!) The distutils test
"test_msvc9compiler" assumes that only values 0 and 1 are valid.
The following patch (against trunk) fixes this. I've tested it on my
buildbot machine and it seems to do the trick.
----------
assignee: tarek
components: Distutils, Tests
files: msvc9compiler.patch
keywords: buildbot, patch, patch
messages: 95458
nosy: pmoore, tarek
severity: normal
status: open
title: distutils.tests.test_msvc9compiler - dragfullwindows can have value 2
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15361/msvc9compiler.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7354>
_______________________________________
From report at bugs.python.org Thu Nov 19 10:42:01 2009
From: report at bugs.python.org (Steve Krenzel)
Date: Thu, 19 Nov 2009 09:42:01 +0000
Subject: [New-bugs-announce] [issue7355] Struct incorrectly compiles format
strings
In-Reply-To: <1258623721.25.0.299543316527.issue7355@psf.upfronthosting.co.za>
Message-ID: <1258623721.25.0.299543316527.issue7355@psf.upfronthosting.co.za>
New submission from Steve Krenzel <sgk284 at gmail.com>:
The struct module has a calcsize() method which reports the size of the data for a specified format
string. In some instances, to the best of my knowledge, this is wrong.
To repro:
>>> from struct import calcsize
>>> calcsize("ci")
8
>>> calcsize("ic")
5
The correct answer is 5 (a single byte character and a four byte int take up 5 bytes of space). For
some reason when a 'c' is followed by an 'i', this is wrong and instead allocates 4 bytes to the 'c'.
This has been verified in 2.6 and 2.5.
You can also repro this by using 's', '2c', and similar combinations in place of 'c'. as well as 'I'
in place of 'i'. This might effect other combinations as well.
----------
components: Library (Lib)
messages: 95467
nosy: sgk284
severity: normal
status: open
title: Struct incorrectly compiles format strings
type: behavior
versions: Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7355>
_______________________________________
From report at bugs.python.org Thu Nov 19 15:33:08 2009
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 19 Nov 2009 14:33:08 +0000
Subject: [New-bugs-announce] [issue7356] parsing of ldconfig output in
ctypes/utils.py depends on the locale
In-Reply-To: <1258641188.9.0.430542588966.issue7356@psf.upfronthosting.co.za>
Message-ID: <1258641188.9.0.430542588966.issue7356@psf.upfronthosting.co.za>
New submission from Matthias Klose <doko at debian.org>:
% /sbin/ldconfig -p | grep GL
libGLU.so.1 (libc6) => /usr/lib/libGLU.so.1
libGLEW.so.1.5 (libc6) => /usr/lib/libGLEW.so.1.5
libGL.so.1 (libc6, Syst?me d'exploitation ABI : Linux 2.4.20) =>
/usr/lib/libGL.so.1
the regexp fails to parse this. proposing to set LANG=C when calling
ldconfig.
----------
assignee: theller
components: ctypes
files: util.py.diff
keywords: patch
messages: 95475
nosy: doko, theller
severity: normal
status: open
title: parsing of ldconfig output in ctypes/utils.py depends on the locale
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15363/util.py.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7356>
_______________________________________
From report at bugs.python.org Thu Nov 19 16:21:28 2009
From: report at bugs.python.org (Eli Venter)
Date: Thu, 19 Nov 2009 15:21:28 +0000
Subject: [New-bugs-announce] [issue7357] tarfile doesn't detect disk full
error on extraction
In-Reply-To: <1258644088.41.0.896427627172.issue7357@psf.upfronthosting.co.za>
Message-ID: <1258644088.41.0.896427627172.issue7357@psf.upfronthosting.co.za>
New submission from Eli Venter <eventer at jcvi.org>:
tarfile doesn't seem to return any error or raise any exception when an
extraction fills up the disk, making it hard to use safely. Both
extractall and extract suffer from this problem. I'm using CentOS 5.2
and python 2.6.2.
----------
components: Library (Lib)
messages: 95481
nosy: eliv
severity: normal
status: open
title: tarfile doesn't detect disk full error on extraction
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7357>
_______________________________________
From report at bugs.python.org Thu Nov 19 16:50:22 2009
From: report at bugs.python.org (Ryan Shaw)
Date: Thu, 19 Nov 2009 15:50:22 +0000
Subject: [New-bugs-announce] [issue7358] cPickle crash on failed assertion
In-Reply-To: <1258645822.27.0.150067328286.issue7358@psf.upfronthosting.co.za>
Message-ID: <1258645822.27.0.150067328286.issue7358@psf.upfronthosting.co.za>
New submission from Ryan Shaw <ryan.shaw at stanfordalumni.org>:
def save_object(r, key, m):
r.set(key, cPickle.dumps(m))
[4] >>> save_object(r, 'cluster', cluster)
python: ./Modules/cStringIO.c:419: O_cwrite: Assertion `oself->pos + l <
2147483647' failed.
Aborted
Linux 2.6.30.9-96.fc11.x86_64 #1 SMP x86_64 GNU/Linux
----------
components: Library (Lib)
messages: 95482
nosy: rybesh
severity: normal
status: open
title: cPickle crash on failed assertion
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7358>
_______________________________________
From report at bugs.python.org Thu Nov 19 17:15:26 2009
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 19 Nov 2009 16:15:26 +0000
Subject: [New-bugs-announce] [issue7359] mailbox cannot modify mailboxes in
system mail spool
In-Reply-To: <1258647326.68.0.261951425057.issue7359@psf.upfronthosting.co.za>
Message-ID: <1258647326.68.0.261951425057.issue7359@psf.upfronthosting.co.za>
New submission from Matthias Klose <doko at debian.org>:
no change in behaviour in 2.6
the mailbox module in python 2.5 cannot modify mboxes in read-only
directories, e.g. the system mail spool. This is because
mailbox._singlefileMailbox.flush() tries to write the modified mailbox
to a temporary file and then rename it. See:
penelope[tmp]$ python2.5
Python 2.5 (release25-maint, Dec 9 2006, 14:35:53)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import mailbox
>>> mbox = mailbox.mbox("/var/mail/nikolaus")
>>> mbox.clear()
>>> mbox.close()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.5/mailbox.py", line 623, in close
self.flush()
File "/usr/lib/python2.5/mailbox.py", line 570, in flush
new_file = _create_temporary(self._path)
File "/usr/lib/python2.5/mailbox.py", line 1885, in _create_temporary
os.getpid()))
File "/usr/lib/python2.5/mailbox.py", line 1875, in _create_carefully
fd = os.open(path, os.O_CREAT | os.O_EXCL | os.O_RDWR)
OSError: [Errno 13] Permission denied:
'/tmp/mail/nikolaus.1195061622.penelope.4241'
>>>
----------
components: Library (Lib)
messages: 95486
nosy: doko
severity: normal
status: open
title: mailbox cannot modify mailboxes in system mail spool
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7359>
_______________________________________
From report at bugs.python.org Thu Nov 19 17:20:22 2009
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 19 Nov 2009 16:20:22 +0000
Subject: [New-bugs-announce] [issue7360] [mailbox] race: mbox may lose data
with concurrent access
In-Reply-To: <1258647622.46.0.810277433722.issue7360@psf.upfronthosting.co.za>
Message-ID: <1258647622.46.0.810277433722.issue7360@psf.upfronthosting.co.za>
New submission from Matthias Klose <doko at debian.org>:
[forwarded from http://bugs.debian.org/451733]
the mailbox._singlefileMailbox class is not safe with concurrent access,
because mailbox._singlefileMailbox.flush() replaces the underlying file
with a new copy by constructing a temporary file and then renaming it.
This breaks all other class instances which have this mailbox open. I'm
attaching a script demonstrating the problem.
I think it's a bad idea to use rename(2) here; overwriting the file
content would fix the race condition, and #451274 too[1].
----------
components: Library (Lib)
messages: 95487
nosy: doko
severity: normal
status: open
title: [mailbox] race: mbox may lose data with concurrent access
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7360>
_______________________________________
From report at bugs.python.org Thu Nov 19 20:18:08 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 19 Nov 2009 19:18:08 +0000
Subject: [New-bugs-announce] [issue7361] Strange importlib error during
test_multiprocessing failure
In-Reply-To: <1258658288.16.0.0772350847135.issue7361@psf.upfronthosting.co.za>
Message-ID: <1258658288.16.0.0772350847135.issue7361@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
One of the buildbots suffered a test_multiprocessing failure, which
itself is not such an unusual thing. But the error that was
subsequently thrown looks like it might point to a place where
importlib's error handling could be improved. The error that was thrown
certainly gives no clear indication of what really caused the problem.
The full buildbot report was:
http://www.python.org/dev/buildbot/all/builders/ia64%20Ubuntu%203.1/builds/93/steps/test/logs/stdio
Here are the tracebacks (the second one being the interesting one):
Traceback (most recent call last):
File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/multiprocessing/process.py",
line 233, in _bootstrap
self.run()
File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/multiprocessing/process.py",
line 88, in run
self._target(*self._args, **self._kwargs)
File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_multiprocessing.py",
line 1211, in _putter
queue = manager.get_queue()
File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/multiprocessing/managers.py",
line 644, in temp
token, exp = self._create(typeid, *args, **kwds)
File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/multiprocessing/managers.py",
line 544, in _create
id, exposed = dispatch(conn, None, 'create', (typeid,)+args, kwds)
File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/multiprocessing/managers.py",
line 79, in dispatch
kind, result = c.recv()
File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/multiprocessing/connection.py",
line 408, in recv
s = self._conn.recv_bytes()
IOError: [Errno 104] Connection reset by peer
test test_multiprocessing failed -- Traceback (most recent call last):
File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_multiprocessing.py",
line 1222, in test_rapid_restart
queue = manager.get_queue()
File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/multiprocessing/managers.py",
line 644, in temp
token, exp = self._create(typeid, *args, **kwds)
File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/multiprocessing/managers.py",
line 542, in _create
conn = self._Client(self._address, authkey=self._authkey)
File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/multiprocessing/connection.py",
line 427, in XmlClient
import xmlrpc.client as xmlrpclib
File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/importlib/_bootstrap.py",
line 151, in decorated
return fxn(self, module)
File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/importlib/_bootstrap.py",
line 399, in load_module
return self._load_module(module)
File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/importlib/_bootstrap.py",
line 324, in _load_module
code_object = self.get_code(module.__name__)
File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/importlib/_bootstrap.py",
line 411, in get_code
pyc_timestamp = marshal._r_long(data[4:8])
File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/importlib/__init__.py",
line 65, in _r_long
x = int_bytes[0]
IndexError: index out of range
----------
components: Library (Lib)
messages: 95511
nosy: brett.cannon, jnoller, r.david.murray
priority: low
severity: normal
stage: test needed
status: open
title: Strange importlib error during test_multiprocessing failure
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7361>
_______________________________________
From report at bugs.python.org Thu Nov 19 21:54:23 2009
From: report at bugs.python.org (James Lingard)
Date: Thu, 19 Nov 2009 20:54:23 +0000
Subject: [New-bugs-announce] [issue7362] Incorrect error message with
def((x)=0)
In-Reply-To: <1258664063.02.0.823547791226.issue7362@psf.upfronthosting.co.za>
Message-ID: <1258664063.02.0.823547791226.issue7362@psf.upfronthosting.co.za>
New submission from James Lingard <jchl at aristanetworks.com>:
def f((x)=0): pass
gives the following incorrect error message:
SyntaxError: non-default argument follows default argument
"def f((x)): pass" is treated exactly the same as "def f(x): pass", so
it would seem sensible for the same to be true if a default value is
used. But if this syntax is disallowed for some reason, the error
message should be fixed.
This appears to be related to bug #1557232.
[Tested on Python 2.6 (r26:66714, Jun 8 2009, 16:07:29).]
----------
components: Interpreter Core
messages: 95514
nosy: james.lingard
severity: normal
status: open
title: Incorrect error message with def((x)=0)
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7362>
_______________________________________
From report at bugs.python.org Fri Nov 20 01:35:30 2009
From: report at bugs.python.org (Yuv Gre)
Date: Fri, 20 Nov 2009 00:35:30 +0000
Subject: [New-bugs-announce] [issue7363] Inconsisten Indentation In
SocketServer Docs
In-Reply-To: <1258677330.72.0.00426773742619.issue7363@psf.upfronthosting.co.za>
Message-ID: <1258677330.72.0.00426773742619.issue7363@psf.upfronthosting.co.za>
New submission from Yuv Gre <ubershmekel at gmail.com>:
A bit nitpicky but there are 3 spaces instead of 4 in the docs. This is
relevant to py3k and trunk.
http://docs.python.org/library/socketserver.html#socketserver-udpserver-
example
----------
assignee: georg.brandl
components: Documentation
files: 3-spaces-udp-server.patch
keywords: patch
messages: 95517
nosy: georg.brandl, ubershmekel
severity: normal
status: open
title: Inconsisten Indentation In SocketServer Docs
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15366/3-spaces-udp-server.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7363>
_______________________________________
From report at bugs.python.org Fri Nov 20 01:36:24 2009
From: report at bugs.python.org (James Lingard)
Date: Fri, 20 Nov 2009 00:36:24 +0000
Subject: [New-bugs-announce] [issue7364] Traceback contains incorrect line
number for duplicate argument in lambda definition
In-Reply-To: <1258677384.54.0.437692828037.issue7364@psf.upfronthosting.co.za>
Message-ID: <1258677384.54.0.437692828037.issue7364@psf.upfronthosting.co.za>
New submission from James Lingard <jchl at aristanetworks.com>:
The following python file:
lambda a, a: 0
when executed gives the following backtrace:
File "/tmp/test.py", line 0
SyntaxError: duplicate argument 'a' in function definition
Note that the line number is 0, not 1. (It's always 0, regardless of
the position in the file).
---
Note that this doesn't happen for other similar errors in lambda
functions, for example the file:
lambda a=0, a: 0
leads to the following error message:
File "/tmp/test.py", line 1
lambda a=0, a: 0
SyntaxError: non-default argument follows default argument
and it also doesn't happen for the same error in a 'def':
def f(a, a): pass
leads to the following error message:
File "/tmp/test.py", line 1
def f(a, a): pass
SyntaxError: duplicate argument 'a' in function definition
---
Tested on Python 2.6 (r26:66714, Jun 8 2009, 16:07:29).
----------
components: Interpreter Core
messages: 95518
nosy: james.lingard
severity: normal
status: open
title: Traceback contains incorrect line number for duplicate argument in lambda definition
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7364>
_______________________________________
From report at bugs.python.org Fri Nov 20 02:24:05 2009
From: report at bugs.python.org (Ed Plese)
Date: Fri, 20 Nov 2009 01:24:05 +0000
Subject: [New-bugs-announce] [issue7365] grp and pwd should treat uid and
gid as unsigned
In-Reply-To: <1258680245.88.0.627899346962.issue7365@psf.upfronthosting.co.za>
Message-ID: <1258680245.88.0.627899346962.issue7365@psf.upfronthosting.co.za>
New submission from Ed Plese <ed at edplese.com>:
Both Linux and Solaris define uid_t and gid_t as unsigned integers. The
pwd and grp modules cast these to signed long values that are then
converted with PyInt_FromLong. For large values, greater than 2 ** 32 -
1, the result is correct when Python is compiled as a 64-bit executable,
but is incorrect when compiled as a 32-bit executable.
Similar bugs have been noted in the posix module as reported in #4591.
For example, on OpenSolaris build 127, the 32-bit version of Python
returns a negative uid: pw_uid=-2147483647:
$ file /usr/bin/python2.6
/usr/bin/python2.6: ELF 32-bit LSB executable 80386 Version 1 [FPU],
dynamically linked, not stripped, no debugging information available
$ /usr/bin/python2.6
Python 2.6.2 (r262, Oct 26 2009, 01:06:14) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import pwd
>>> pwd.getpwnam('test at foo.com')
pwd.struct_passwd(pw_name='test at foo.com', pw_passwd='x',
pw_uid=-2147483647, pw_gid=10000, pw_gecos='Test User', pw_dir='',
pw_shell='')
$ file /usr/bin/amd64/python2.6
/usr/bin/amd64/python2.6: ELF 64-bit LSB executable AMD64 Version
1 [SSE FXSR FPU], dynamically linked, not stripped, no debugging
information available
$ /usr/bin/amd64/python2.6
Python 2.6.2 (r262, Oct 26 2009, 01:09:04) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import pwd
>>> pwd.getpwnam('test at foo.com')
pwd.struct_passwd(pw_name='test at foo.com', pw_passwd='x',
pw_uid=2147483649, pw_gid=10000, pw_gecos='Test User', pw_dir='',
pw_shell='')
The attached patch against 2.6.4 changes PyInt_FromLong to
PyLong_FromUnsignedLong and changes casts to unsigned long.
----------
components: Extension Modules
files: pwd-grp-unsigned-uid.patch
keywords: patch
messages: 95520
nosy: eplese
severity: normal
status: open
title: grp and pwd should treat uid and gid as unsigned
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15367/pwd-grp-unsigned-uid.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7365>
_______________________________________
From report at bugs.python.org Fri Nov 20 07:07:35 2009
From: report at bugs.python.org (James Henstridge)
Date: Fri, 20 Nov 2009 06:07:35 +0000
Subject: [New-bugs-announce] [issue7366] weakref module example relies on
behaviour not guaranteed by id()
In-Reply-To: <1258697255.57.0.532906770015.issue7366@psf.upfronthosting.co.za>
Message-ID: <1258697255.57.0.532906770015.issue7366@psf.upfronthosting.co.za>
New submission from James Henstridge <james at jamesh.id.au>:
The documentation for the weakref module contains an example that uses
WeakValueDictionary to implement a id2obj() lookup function that doesn't
store strong references to those objects.
This example implicitly assumes that the id() of an object will be
unique for the lifetime of the interpreter, when it is only unique for
the lifetime of the object. The problem can be demonstrated like so:
1. create an object "foo"
2. function 1 remembers the id of this object with "oid1 = remember(foo)"
3. "foo" gets garbage collected
4. an object "bar" is created and happens to get the same memory location
5. function 2 remembers the id of this object with "oid2 = remember(bar)"
6. function 1 looks up its stored object ID with "id2obj(oid1)"
In step 6, the object "bar" is returned rather than an exception being
raised.
As well as the example being broken, the weakref module contains the
functionality a programmer would need to do this kind of thing safely:
use the weakref.ref type directly.
It'd be good to replace the example with a better one.
----------
assignee: georg.brandl
components: Documentation
messages: 95530
nosy: georg.brandl, jamesh
severity: normal
status: open
title: weakref module example relies on behaviour not guaranteed by id()
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7366>
_______________________________________
From report at bugs.python.org Fri Nov 20 08:31:25 2009
From: report at bugs.python.org (Jay Lugo)
Date: Fri, 20 Nov 2009 07:31:25 +0000
Subject: [New-bugs-announce] [issue7367] OSError [errno 13] permission denied
In-Reply-To: <1258702285.22.0.207199237354.issue7367@psf.upfronthosting.co.za>
Message-ID: <1258702285.22.0.207199237354.issue7367@psf.upfronthosting.co.za>
New submission from Jay Lugo <jacewickman at gmail.com>:
I spend the better part of a day figuring out this relatively simple
problem with the help files in IDLE with python 2.6 on a mac OSX
I came about the solution by following the code errors all over
up and down the program files.
Eventual I came about the public folder ex..
Users/ME/Public
I spent time looking through the properties and settings tabs editing my
firewall settings and file sharing options (I reverted them when i fixed
the problem)
but i ended up removing all file sharing settings anyway.
I simply right clicked on the public folder and my permission was set
to "Write only(Drop Box)"
a simple change to "Reed and Write" fixed the IDLE error.
Hope i just saved some one some time.
----------
components: IDLE
messages: 95533
nosy: Quik_Foot
severity: normal
status: open
title: OSError [errno 13] permission denied
type: resource usage
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7367>
_______________________________________
From report at bugs.python.org Fri Nov 20 14:22:49 2009
From: report at bugs.python.org (JoostBehrends)
Date: Fri, 20 Nov 2009 13:22:49 +0000
Subject: [New-bugs-announce] [issue7368] Internal error in threading.py
In-Reply-To: <1258723369.04.0.0815144393289.issue7368@psf.upfronthosting.co.za>
Message-ID: <1258723369.04.0.0815144393289.issue7368@psf.upfronthosting.co.za>
New submission from JoostBehrends <joost at h-labahn.de>:
On Nov.20, 2009 i got the traceback below from Python 3.1.1 under
WindowsXP-SP3, as several times before. From code with
def _core(func, my_args):
A = Thread(target = func, args = my_args); A.start(); A.join()
_core(ask_user, (question, default_answer))
Doesn't matter from what, the traceback is showing no calling line (thus
there is at least a slip in threading.py's exception handlers):
Unhandled exception in thread started by <bound method Thread._bootstrap
of <Thread(Thread-1, stopped 288)>>
Traceback (most recent call last):
File "D:\Programme\Python31\lib\threading.py", line 482, in _bootstrap
self._bootstrap_inner()
File "D:\Programme\Python31\lib\threading.py", line 558, in
_bootstrap_inner
self._stop()
File "D:\Programme\Python31\lib\threading.py", line 569, in _stop
self._block.notify_all()
File "D:\Programme\Python31\lib\threading.py", line 273, in notify_all
self.notify(len(self._waiters))
File "D:\Programme\Python31\lib\threading.py", line 265, in notify
for waiter in waiters:
TypeError: function takes exactly 1 argument (0 given)
----------
components: Library (Lib)
messages: 95539
nosy: 3Jane
severity: normal
status: open
title: Internal error in threading.py
type: compile error
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7368>
_______________________________________
From report at bugs.python.org Fri Nov 20 14:50:32 2009
From: report at bugs.python.org (prm225)
Date: Fri, 20 Nov 2009 13:50:32 +0000
Subject: [New-bugs-announce] [issue7369] Fibonacci example does not include
0; section 4.6
In-Reply-To: <1258725032.09.0.34838264618.issue7369@psf.upfronthosting.co.za>
Message-ID: <1258725032.09.0.34838264618.issue7369@psf.upfronthosting.co.za>
New submission from prm225 <prm225 at gmail.com>:
The example starts off with 1 being printed, while the series is
expected to begin with 0 and 1.
The example in 4.6 (defining functions) should have been:
def fib(n):
a, b = 0, 1
while a < n:
print a,
a, b = b, a+b
fib(2000)
0 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597
----------
assignee: georg.brandl
components: Documentation
messages: 95542
nosy: georg.brandl, prm225
severity: normal
status: open
title: Fibonacci example does not include 0; section 4.6
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7369>
_______________________________________
From report at bugs.python.org Fri Nov 20 17:22:45 2009
From: report at bugs.python.org (Josh Kupershmidt)
Date: Fri, 20 Nov 2009 16:22:45 +0000
Subject: [New-bugs-announce] [issue7370] patch: BaseHTTPServer reinventing
rfc822
In-Reply-To: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>
Message-ID: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>
New submission from Josh Kupershmidt <schmiddy at gmail.com>:
While digging through Lib/BaseHTTPServer.py, I noticed that the
date_time_string() function duplicates rfc822.formatdate(). Attached is
a patch to eliminate this duplication of code.
----------
components: Library (Lib)
files: BaseHTTPServer.patch
keywords: patch
messages: 95554
nosy: schmiddy
severity: normal
status: open
title: patch: BaseHTTPServer reinventing rfc822
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file15369/BaseHTTPServer.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7370>
_______________________________________
From report at bugs.python.org Fri Nov 20 22:24:08 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 20 Nov 2009 21:24:08 +0000
Subject: [New-bugs-announce] [issue7371] Windows 64-bit build "skips"
several projects in VS 2008
In-Reply-To: <1258752248.05.0.167808334648.issue7371@psf.upfronthosting.co.za>
Message-ID: <1258752248.05.0.167808334648.issue7371@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
1. Install Windows 64-bit (SP2)
2. Install Visual Studio 2008 Professional w/ 64-bit components
3. Download Python-2.6.4.tgz
4. Open PCbuild/pcbuild.sln
5. Select "Release" and "x64" in the configuration toolbar
One would notice that only the projects "make_buildinfo" and
"make_versioninfo" are built (which too as Win32, not x64 - for unknown
reason). All projects are *skipped*. I don't know why.
64-bit build would work on a 32-bit Windows machine (cross-
compilation), but not a native 64-bit Windows machine?
Attached is the Visual Studio build log.
----------
components: Build, Windows
files: py264-xp64bit-vs2008-buildlog.txt
messages: 95565
nosy: srid
severity: normal
status: open
title: Windows 64-bit build "skips" several projects in VS 2008
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15371/py264-xp64bit-vs2008-buildlog.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7371>
_______________________________________
From report at bugs.python.org Sat Nov 21 02:03:11 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 21 Nov 2009 01:03:11 +0000
Subject: [New-bugs-announce] [issue7372] Regression in pstats
In-Reply-To: <1258765391.77.0.857956675588.issue7372@psf.upfronthosting.co.za>
Message-ID: <1258765391.77.0.857956675588.issue7372@psf.upfronthosting.co.za>
New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:
Attached zip archive can be run directly to reproduce the bug:
$ ./python.exe bug.zip
Traceback (most recent call last):
File "/Users/sasha/Work/python-svn/trunk/Lib/runpy.py", line 162, in
_run_module_as_main
"__main__", fname, loader, pkg_name)
File "/Users/sasha/Work/python-svn/trunk/Lib/runpy.py", line 72, in
_run_code
exec code in run_globals
File "bug.zip/__main__.py", line 9, in <module>
File "/Users/sasha/Work/python-svn/trunk/Lib/pstats.py", line 268, in
strip_dirs
(cc, nc, tt, ct, newcallers))
File "/Users/sasha/Work/python-svn/trunk/Lib/pstats.py", line 516, in
add_func_stats
add_callers(t_callers, callers))
File "/Users/sasha/Work/python-svn/trunk/Lib/pstats.py", line 526, in
add_callers
zip(caller, new_callers[func])])
TypeError: zip argument #1 must support iteration
This is a regression introduced by r60149 which fixed processing of
cProfile data, but broke processing of profile.
It is fairly easy to fix this problem in pstats, but a better solution
may be to make profile output compatible with cProfile.
See also issue1269 and issue1315 .
----------
components: Library (Lib)
files: bug.zip
messages: 95574
nosy: belopolsky, georg.brandl, matthew.fremont, stromnov, therve
severity: normal
status: open
title: Regression in pstats
type: crash
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15372/bug.zip
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7372>
_______________________________________
From report at bugs.python.org Sun Nov 22 00:56:46 2009
From: report at bugs.python.org (Jon Parise)
Date: Sat, 21 Nov 2009 23:56:46 +0000
Subject: [New-bugs-announce] [issue7373] Use PyModule_AddIntMacro() in
Modules/gcmodule.c
In-Reply-To: <1258847806.44.0.30023872526.issue7373@psf.upfronthosting.co.za>
Message-ID: <1258847806.44.0.30023872526.issue7373@psf.upfronthosting.co.za>
New submission from Jon Parise <jon at indelible.org>:
The attached patch uses PyModule_AddIntMacro() to register the gc
module's constants instead of using a local ADD_INT() macro.
----------
components: Interpreter Core
files: gc_macros-trunk.patch
keywords: patch
messages: 95589
nosy: jon
severity: normal
status: open
title: Use PyModule_AddIntMacro() in Modules/gcmodule.c
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15378/gc_macros-trunk.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7373>
_______________________________________
From report at bugs.python.org Sun Nov 22 09:14:59 2009
From: report at bugs.python.org (Michal Liddle)
Date: Sun, 22 Nov 2009 08:14:59 +0000
Subject: [New-bugs-announce] [issue7374] Property accessor/getter called
twice
In-Reply-To: <1258877699.05.0.144558862329.issue7374@psf.upfronthosting.co.za>
Message-ID: <1258877699.05.0.144558862329.issue7374@psf.upfronthosting.co.za>
New submission from Michal Liddle <michael at liddle.net.nz>:
The following snippet demonstrates the problem:
-------------------------------------
class Test(object):
def get(self):
print "get"
def set(self, v):
print "set"
test = property(get, set)
t = Test()
t.test
t.test = 3
-----------------------------------
"get" is printed twice (expected once?), "set" is printed only once (as
expected)
----------
messages: 95595
nosy: mliddle
severity: normal
status: open
title: Property accessor/getter called twice
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7374>
_______________________________________
From report at bugs.python.org Sun Nov 22 16:40:33 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 22 Nov 2009 15:40:33 +0000
Subject: [New-bugs-announce] [issue7375] 2to3 - does not translate urllib2
to urllib.request correctly for function/method argument
In-Reply-To: <1258904433.77.0.0888742690092.issue7375@psf.upfronthosting.co.za>
Message-ID: <1258904433.77.0.0888742690092.issue7375@psf.upfronthosting.co.za>
New submission from Senthil Kumaran <orsenthil at gmail.com>:
2.x code:
import urllib2
opener = urllib2.build_opener(urllib2.HTTPHandler(debuglevel=1))
2to3 on this would result in:
import urllib.request, urllib.error, urllib.parse
opener = urllib.request.build_opener(urllib2.HTTPHandler(debuglevel=1))
which is wrong. It did not translate the urllib2 in argument.
----------
assignee: benjamin.peterson
messages: 95602
nosy: benjamin.peterson, orsenthil
priority: normal
severity: normal
status: open
title: 2to3 - does not translate urllib2 to urllib.request correctly for function/method argument
type: behavior
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7375>
_______________________________________
From report at bugs.python.org Sun Nov 22 18:57:13 2009
From: report at bugs.python.org (flox)
Date: Sun, 22 Nov 2009 17:57:13 +0000
Subject: [New-bugs-announce] [issue7376] FAIL: Doctest: __main__.DebugRunner
In-Reply-To: <1258912633.73.0.334320263097.issue7376@psf.upfronthosting.co.za>
Message-ID: <1258912633.73.0.334320263097.issue7376@psf.upfronthosting.co.za>
New submission from flox <laxyf at yahoo.fr>:
Running on Debian Lenny, with Python 3.1.
The Python 2.5 version is OK.
~ $ python3 --version
Python 3.1.1+
~ $ python3 -m doctest
F..............
======================================================================
FAIL: Doctest: __main__.DebugRunner
----------------------------------------------------------------------
Traceback (most recent call last):
File "/usr/lib/python3.1/doctest.py", line 2096, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for __main__.DebugRunner
File "/usr/lib/python3.1/doctest.py", line 1644, in DebugRunner
----------------------------------------------------------------------
File "/usr/lib/python3.1/doctest.py", line 1712, in __main__.DebugRunner
Failed example:
runner.run(test)
Expected:
Traceback (most recent call last):
...
doctest.UnexpectedException: <DocTest foo from foo.py:0 (2 examples)>
Got:
Traceback (most recent call last):
File "/usr/lib/python3.1/doctest.py", line 1243, in __run
compileflags, 1), test.globs)
File "<doctest __main__.DebugRunner[15]>", line 1, in <module>
runner.run(test)
File "/usr/lib/python3.1/doctest.py", line 1736, in run
r = DocTestRunner.run(self, test, compileflags, out, False)
File "/usr/lib/python3.1/doctest.py", line 1375, in run
return self.__run(test, compileflags, out)
File "/usr/lib/python3.1/doctest.py", line 1296, in __run
exception)
File "/usr/lib/python3.1/doctest.py", line 1742, in
report_unexpected_exception
raise UnexpectedException(test, example, exc_info)
UnexpectedException: <DocTest foo from foo.py:0 (2 examples)>
----------------------------------------------------------------------
Ran 15 tests in 0.015s
FAILED (failures=1)
~ $
----------
components: Library (Lib), Tests
messages: 95605
nosy: flox
severity: normal
status: open
title: FAIL: Doctest: __main__.DebugRunner
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7376>
_______________________________________
From report at bugs.python.org Sun Nov 22 19:09:56 2009
From: report at bugs.python.org (flox)
Date: Sun, 22 Nov 2009 18:09:56 +0000
Subject: [New-bugs-announce] [issue7377] Slight difference: math.floor
returns an Integral
In-Reply-To: <1258913396.31.0.675484209097.issue7377@psf.upfronthosting.co.za>
Message-ID: <1258913396.31.0.675484209097.issue7377@psf.upfronthosting.co.za>
New submission from flox <laxyf at yahoo.fr>:
The last code snippet on section "25.2.3.2 How are Docstring Examples
Recognized?" does not output the expected result.
http://docs.python.org/dev/py3k/library/doctest.html#how-are-docstring-examples-recognized
Documentation example:
>>> assert "Easy!"
>>> import math
>>> math.floor(1.9)
1.0
Real life (Python 3.1):
>>> math.floor(1.9)
1
----------
assignee: georg.brandl
components: Documentation
messages: 95606
nosy: flox, georg.brandl
severity: normal
status: open
title: Slight difference: math.floor returns an Integral
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7377>
_______________________________________
From report at bugs.python.org Mon Nov 23 11:04:22 2009
From: report at bugs.python.org (Greg Hewgill)
Date: Mon, 23 Nov 2009 10:04:22 +0000
Subject: [New-bugs-announce] [issue7378] unexpected truncation of traceback
In-Reply-To: <1258970662.35.0.76558630095.issue7378@psf.upfronthosting.co.za>
Message-ID: <1258970662.35.0.76558630095.issue7378@psf.upfronthosting.co.za>
New submission from Greg Hewgill <greg at hewgill.com>:
Quite by accident, I came across a case where Python would quit
generating traceback text and skip printing the actual exception
information. Here is a sample program:
exec(compile("spam()", ".", "exec"))
and the output in Python 3.1 ("spam" is undefined):
$ python3.1 test.py
Traceback (most recent call last):
File "test.py", line 1, in <module>
exec(compile("spam()", ".", "exec"))
File ".", line 1, in <module>
$
This was bewildering until I realised that the traceback generator was
unable to read from the filename passed to compile() (my original
example was using a name other than "." that wasn't intended to be a
file name, but just happened to also be a directory name). I didn't
really mind the lack of source text, but the lack of the actual
exception message was most disturbing.
This appears to be a failure mode common to both traceback.c and
traceback.py, through slightly different mechanisms. In traceback.c, if
the source filename refers to a directory, the C open() succeeds but an
error occurs when trying to read from the directory handle. In
traceback.py, the Python open() call fails with an IOError exception,
and the exception wasn't handled gracefully.
I have attached a patch that creates the following output instead:
$ ./python.exe test.py
Traceback (most recent call last):
File "test.py", line 1, in <module>
exec(compile("spam()", ".", "exec"))
File ".", line 1, in <module>
[Errno 21] Is a directory: '.'
NameError: name 'spam' is not defined
$
I have tested the patch against Python 3.1, but it applies cleanly to
the trunk (for some reason I couldn't make the trunk build, but that's
unrelated). This patch may need some finesse for a Win32 build; I don't
have the ability to test that at the moment.
----------
components: Interpreter Core, Library (Lib)
files: traceback.patch
keywords: patch
messages: 95617
nosy: ghewgill
severity: normal
status: open
title: unexpected truncation of traceback
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file15384/traceback.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7378>
_______________________________________
From report at bugs.python.org Mon Nov 23 12:55:07 2009
From: report at bugs.python.org (flox)
Date: Mon, 23 Nov 2009 11:55:07 +0000
Subject: [New-bugs-announce] [issue7379] Docstring for
fractions.Fraction.limit_denominator fails
In-Reply-To: <1258977307.89.0.840946928578.issue7379@psf.upfronthosting.co.za>
Message-ID: <1258977307.89.0.840946928578.issue7379@psf.upfronthosting.co.za>
New submission from flox <laxyf at yahoo.fr>:
Yes, you can reduce the fraction 1234/5678.
Bad Luck :p
~ $ python3 -m doctest /usr/lib/python3.1/fractions.py
**********************************************************************
File "/usr/lib/python3.1/fractions.py", line 165, in
fractions.Fraction.limit_denominator
Failed example:
Fraction(1234, 5678).limit_denominator(10000)
Expected:
Fraction(1234, 5678)
Got:
Fraction(617, 2839)
**********************************************************************
1 items had failures:
1 of 3 in fractions.Fraction.limit_denominator
***Test Failed*** 1 failures.
~ $
----------
components: Library (Lib), Tests
messages: 95620
nosy: flox
severity: normal
status: open
title: Docstring for fractions.Fraction.limit_denominator fails
versions: Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7379>
_______________________________________
From report at bugs.python.org Mon Nov 23 13:33:53 2009
From: report at bugs.python.org (flox)
Date: Mon, 23 Nov 2009 12:33:53 +0000
Subject: [New-bugs-announce] [issue7380] uuid.UUID.bytes gives a bytearray()
instead of bytes
In-Reply-To: <1258979633.13.0.798699674887.issue7380@psf.upfronthosting.co.za>
Message-ID: <1258979633.13.0.798699674887.issue7380@psf.upfronthosting.co.za>
New submission from flox <laxyf at yahoo.fr>:
I've tried some experiments with module uuid, and I meet some
inconsistencies between the documentation, the docstring and the real
behavior of the module.
An interactive session is worth a thousand words:
>>> import uuid
>>> uuid.UUID(bytes='\x12\x34\x56\x78'*4)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.1/uuid.py", line 149, in __init__
assert isinstance(bytes, bytes_), repr(bytes)
AssertionError: '\x124Vx\x124Vx\x124Vx\x124Vx'
>>> uuid.UUID(bytes_le='\x78\x56\x34\x12\x34\x12\x78\x56' +
... '\x12\x34\x56\x78\x12\x34\x56\x78')
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
File "/usr/lib/python3.1/uuid.py", line 144, in __init__
bytes_(reversed(bytes_le[6:8])) +
TypeError: 'str' object cannot be interpreted as an integer
>>>
Ok, the lines above are just parts of the documentation which need
update. But what is more confusing is the last example of the documentation.
http://docs.python.org/dev/py3k/library/uuid.html
Here is the interactive session:
>>> x = uuid.UUID('{00010203-0405-0607-0809-0a0b0c0d0e0f}')
>>> x.bytes
bytearray(b'\x00\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f')
>>> x.bytes_le
b'\x03\x02\x01\x00\x05\x04\x07\x06\x08\t\n\x0b\x0c\r\x0e\x0f'
>>>
Normally both attributes should get a "UUID as a 16-byte string",
according to the documentation. Only the endianness should do the
difference. I guess this one need a patch.
Finally, the docstring fails, too:
~ $ python3 -m doctest /usr/lib/python3.1/uuid.py
**********************************************************************
File "/usr/lib/python3.1/uuid.py", line 16, in uuid
Failed example:
uuid.uuid1()
Expected:
UUID('a8098c1a-f86e-11da-bd1a-00112444be1e')
Got:
UUID('e4bc8a38-d829-11de-9eee-0024e8bc58f0')
**********************************************************************
File "/usr/lib/python3.1/uuid.py", line 24, in uuid
Failed example:
uuid.uuid4()
Expected:
UUID('16fd2706-8baf-433b-82eb-8c7fada847da')
Got:
UUID('71588cf5-7a51-4d59-ad76-05fb6b932673')
**********************************************************************
File "/usr/lib/python3.1/uuid.py", line 39, in uuid
Failed example:
x.bytes
Expected:
b'\x00\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f'
Got:
bytearray(b'\x00\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f')
**********************************************************************
File "/usr/lib/python3.1/uuid.py", line 43, in uuid
Failed example:
uuid.UUID(bytes=x.bytes)
Exception raised:
Traceback (most recent call last):
File "/usr/lib/python3.1/doctest.py", line 1243, in __run
compileflags, 1), test.globs)
File "<doctest uuid[8]>", line 1, in <module>
uuid.UUID(bytes=x.bytes)
File "/usr/lib/python3.1/uuid.py", line 149, in __init__
assert isinstance(bytes, bytes_), repr(bytes)
AssertionError:
bytearray(b'\x00\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f')
**********************************************************************
1 items had failures:
4 of 9 in uuid
***Test Failed*** 4 failures.
~ $
----------
components: Library (Lib)
messages: 95622
nosy: flox
severity: normal
status: open
title: uuid.UUID.bytes gives a bytearray() instead of bytes
versions: Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7380>
_______________________________________
From report at bugs.python.org Mon Nov 23 14:28:37 2009
From: report at bugs.python.org (flox)
Date: Mon, 23 Nov 2009 13:28:37 +0000
Subject: [New-bugs-announce] [issue7381] subprocess.check_output: "docstring
has inconsistent leading whitespace"
In-Reply-To: <1258982917.41.0.193216902616.issue7381@psf.upfronthosting.co.za>
Message-ID: <1258982917.41.0.193216902616.issue7381@psf.upfronthosting.co.za>
New submission from flox <laxyf at yahoo.fr>:
I've tested the docstring of the module subprocess.
Python 2.5 is OK, but Python 3.1 fails.
~ $ python2.5 -m doctest /usr/lib/python2.5/subprocess.py
...............
----------------------------------------------------------------------
Ran 15 tests in 0.012s
OK
~ $ python3 -m doctest /usr/lib/python3.1/subprocess.py
Traceback (most recent call last):
File "/usr/lib/python3.1/runpy.py", line 128, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python3.1/runpy.py", line 34, in _run_code
exec(code, run_globals)
File "/usr/lib/python3.1/doctest.py", line 2637, in <module>
sys.exit(_test())
File "/usr/lib/python3.1/doctest.py", line 2626, in _test
failures, _ = testmod(m)
File "/usr/lib/python3.1/doctest.py", line 1847, in testmod
for test in finder.find(m, name, globs=globs, extraglobs=extraglobs):
File "/usr/lib/python3.1/doctest.py", line 854, in find
self._find(tests, obj, name, module, source_lines, globs, {})
File "/usr/lib/python3.1/doctest.py", line 908, in _find
globs, seen)
File "/usr/lib/python3.1/doctest.py", line 896, in _find
test = self._get_test(obj, name, module, globs, source_lines)
File "/usr/lib/python3.1/doctest.py", line 980, in _get_test
filename, lineno)
File "/usr/lib/python3.1/doctest.py", line 590, in get_doctest
return DocTest(self.get_examples(string, name), globs,
File "/usr/lib/python3.1/doctest.py", line 604, in get_examples
return [x for x in self.parse(string, name)
File "/usr/lib/python3.1/doctest.py", line 566, in parse
self._parse_example(m, name, lineno)
File "/usr/lib/python3.1/doctest.py", line 636, in _parse_example
lineno + len(source_lines))
File "/usr/lib/python3.1/doctest.py", line 722, in _check_prefix
(lineno+i+1, name, line))
ValueError: line 11 of the docstring for subprocess.check_output has
inconsistent leading whitespace: "'"
----------
components: Library (Lib), Tests
messages: 95625
nosy: flox
severity: normal
status: open
title: subprocess.check_output: "docstring has inconsistent leading whitespace"
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7381>
_______________________________________
From report at bugs.python.org Mon Nov 23 16:17:39 2009
From: report at bugs.python.org (Sebastian Hagen)
Date: Mon, 23 Nov 2009 15:17:39 +0000
Subject: [New-bugs-announce] [issue7382] bytes.__getnewargs__ is broken;
copy.copy() therefore doesn't work on bytes, and bytes
subclasses can't be pickled by default
In-Reply-To: <1258989459.99.0.51081222067.issue7382@psf.upfronthosting.co.za>
Message-ID: <1258989459.99.0.51081222067.issue7382@psf.upfronthosting.co.za>
New submission from Sebastian Hagen <sh_pybugs at memespace.net>:
In either python 3.0, bytes instances cannot be copied, and (even
trivial) bytes subclasses cannot be unpickled unless they explicitly
override __getnewargs__() or __reduce_ex__().
Copy problem:
>>> import copy; copy.copy(b'foo')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.1/copy.py", line 96, in copy
return _reconstruct(x, rv, 0)
File "/usr/lib/python3.1/copy.py", line 280, in _reconstruct
y = callable(*args)
File "/usr/lib/python3.1/copyreg.py", line 88, in __newobj__
return cls.__new__(cls, *args)
TypeError: string argument without an encoding
Bytes subclass unpickle problem:
>>> class B(bytes):
... pass
...
>>> import pickle; pickle.loads(pickle.dumps(B(b'foo')))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.1/pickle.py", line 1373, in loads
encoding=encoding, errors=errors).load()
TypeError: string argument without an encoding
AFAICT, the problem is that bytes.__getnewargs__() returns a tuple with
a single argument - a string - and bytes.__new__() refuses to
reconstruct the instance when called with in that manner. That is,
"bytes.__new__(bytes, *b'foo'.__getnewargs__())" fails with a TypeError.
This does not cause a problem for pickling bytes instances (as opposed
to instances of a subclass of bytes), because both the Python and C
versions of pickle shipped with Python 3.[01] have built-in magic
(_Pickler.save_bytes() and save_bytes(), respectively) to deal with
bytes instances, and therefore never call their __getnewargs__().
The pickle case, in particular, is highly irritating; the error message
doesn't indicate which object is causing the problem, and until you
actually try to load the pickle, there's nothing to indicate that
there's anything problematic about pickling an instance of a subclass of
bytes.
----------
components: Library (Lib)
files: pickle_bytes_subclass.py
messages: 95632
nosy: sh
severity: normal
status: open
title: bytes.__getnewargs__ is broken; copy.copy() therefore doesn't work on bytes, and bytes subclasses can't be pickled by default
type: behavior
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file15387/pickle_bytes_subclass.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7382>
_______________________________________
From report at bugs.python.org Mon Nov 23 20:39:22 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 Nov 2009 19:39:22 +0000
Subject: [New-bugs-announce] [issue7383] test_multiprocessing leaks
In-Reply-To: <1259005162.5.0.211028824786.issue7383@psf.upfronthosting.co.za>
Message-ID: <1259005162.5.0.211028824786.issue7383@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
This has started a few days ago. I don't know if this was triggered by a
multiprocessing change or an unrelated one.
On trunk:
test_multiprocessing
beginning 6 repetitions
123456
......
test_multiprocessing leaked [277, 277, 277] references, sum=831
On py3k:
test_multiprocessing
beginning 6 repetitions
123456
......
test_multiprocessing leaked [229, 229, 229] references, sum=687
----------
assignee: jnoller
components: Library (Lib), Tests
messages: 95649
nosy: jnoller, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: test_multiprocessing leaks
type: resource usage
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7383>
_______________________________________
From report at bugs.python.org Mon Nov 23 21:03:48 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 23 Nov 2009 20:03:48 +0000
Subject: [New-bugs-announce] [issue7384] test_curses crash on FreeBSD
buildbots
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
test_curses is currently causing the test runs to abort on the FreeBSD 6.4
and 7.2 buildbots.
I can reproduce this on a FreeBSD 7.2 /amd64 machine by doing
./python Lib/test/regrtest.py -uall test___all__ test_curses
This dumps core, and the traceback points at the call to delwin() in
PyCursesWindow_Dealloc, but it's far from obvious (to me) what's going
wrong. wo->win is not NULL here, and appears to point to a valid WINDOW.
However, stdscr is NULL! As far as I can tell, this shouldn't happen.
test_curses by itself doesn't crash, unless I add an 'import readline' or
'import rlcompleter' to the top of test_curses.py.
I expect to have access to the FreeBSD machine for a few more days. Any
hints about what to try next would be appreciated.
----------
components: Extension Modules
keywords: buildbot
messages: 95652
nosy: mark.dickinson
severity: normal
status: open
title: test_curses crash on FreeBSD buildbots
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________
From report at bugs.python.org Mon Nov 23 23:07:07 2009
From: report at bugs.python.org (Pauli Virtanen)
Date: Mon, 23 Nov 2009 22:07:07 +0000
Subject: [New-bugs-announce] [issue7385] MemoryView_FromObject crashes if
PyBuffer_GetBuffer fails
In-Reply-To: <1259014027.47.0.458918561634.issue7385@psf.upfronthosting.co.za>
Message-ID: <1259014027.47.0.458918561634.issue7385@psf.upfronthosting.co.za>
New submission from Pauli Virtanen <pav at iki.fi>:
In Objects/memoryobject.c:PyMemoryView_FromObject there's a
_PyObject_GC_UNTRACK unpaired with corresponding _PyObject_GC_TRACK,
which seems to cause a segmentation fault. This can be triggered by
calling PyMemoryView_FromObject on an object whose bf_getbuffer returns
an error.
PyMemoryView_FromObject(PyObject *base) {
...
if (PyObject_GetBuffer(base, &(mview->view), PyBUF_FULL_RO) < 0) {
Py_DECREF(mview);
return NULL;
}
...
_PyObject_GC_TRACK(mview);
}
...
static void memory_dealloc(PyMemoryViewObject *self) {
_PyObject_GC_UNTRACK(self);
....
}
----------
components: Interpreter Core
messages: 95660
nosy: pv
severity: normal
status: open
title: MemoryView_FromObject crashes if PyBuffer_GetBuffer fails
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7385>
_______________________________________
From report at bugs.python.org Tue Nov 24 03:25:35 2009
From: report at bugs.python.org (pengyu.ut)
Date: Tue, 24 Nov 2009 02:25:35 +0000
Subject: [New-bugs-announce] [issue7386] More precise document on
os.path.normpath()
In-Reply-To: <1259029535.8.0.110880013855.issue7386@psf.upfronthosting.co.za>
Message-ID: <1259029535.8.0.110880013855.issue7386@psf.upfronthosting.co.za>
New submission from pengyu.ut <pengyu.ut at gmail.com>:
os.path.normpath() doesn't return the trailing '/', if the path is a
directory. But the document doesn't mention this fact.
I recommend document this feature.
----------
assignee: georg.brandl
components: Documentation
messages: 95661
nosy: georg.brandl, pengyu.ut
severity: normal
status: open
title: More precise document on os.path.normpath()
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7386>
_______________________________________
From report at bugs.python.org Tue Nov 24 03:25:52 2009
From: report at bugs.python.org (pengyu.ut)
Date: Tue, 24 Nov 2009 02:25:52 +0000
Subject: [New-bugs-announce] [issue7387] More precise document on
os.path.normpath()
In-Reply-To: <1259029552.04.0.647489871972.issue7387@psf.upfronthosting.co.za>
Message-ID: <1259029552.04.0.647489871972.issue7387@psf.upfronthosting.co.za>
New submission from pengyu.ut <pengyu.ut at gmail.com>:
os.path.normpath() doesn't return the trailing '/', if the path is a
directory. But the document doesn't mention this fact.
I recommend document this feature.
----------
assignee: georg.brandl
components: Documentation
messages: 95662
nosy: georg.brandl, pengyu.ut
severity: normal
status: open
title: More precise document on os.path.normpath()
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7387>
_______________________________________
From report at bugs.python.org Tue Nov 24 10:43:52 2009
From: report at bugs.python.org (Retro)
Date: Tue, 24 Nov 2009 09:43:52 +0000
Subject: [New-bugs-announce] [issue7388] Documentation: capitalizations of
the word 'python' needed when used as a name
In-Reply-To: <1259055832.84.0.933127183577.issue7388@psf.upfronthosting.co.za>
Message-ID: <1259055832.84.0.933127183577.issue7388@psf.upfronthosting.co.za>
New submission from Retro <vinetouu at gmail.com>:
There are 'python' typos in the Python tutorial in these titles:
(1) Tools for Working with Lists:
The following example shows an array of numbers stored as two byte
unsigned binary numbers (typecode "H") rather than the usual 16 bytes
per entry for regular lists of !!!python!!! (should be: Python) int objects
(2) Batteries Included:
Together, these modules and packages greatly simplify data interchange
between !!!python!!! (should be: Python) applications and other tools.
There may be other typos, but I only manage to find those two. Please
capitalize those two words. Thank you.
----------
assignee: georg.brandl
components: Documentation
messages: 95666
nosy: Retro, georg.brandl
severity: normal
status: open
title: Documentation: capitalizations of the word 'python' needed when used as a name
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7388>
_______________________________________
From report at bugs.python.org Tue Nov 24 12:05:59 2009
From: report at bugs.python.org (Retro)
Date: Tue, 24 Nov 2009 11:05:59 +0000
Subject: [New-bugs-announce] [issue7389] Make decimal floating point be
default, remove binary floating point
In-Reply-To: <1259060759.88.0.182067416684.issue7389@psf.upfronthosting.co.za>
Message-ID: <1259060759.88.0.182067416684.issue7389@psf.upfronthosting.co.za>
New submission from Retro <vinetouu at gmail.com>:
The Python interpreter should have the decimal type built into its core.
The mechanism for dealing with decimal numbers should be handled by the
decimal type and not by the processor which spits binary floats. The
time is now. But ask yourself these questions:
Is this doable? If yes:
Would it break anything? If yes, note that:
Python 3.1 opposed to Python 3.0 also had major changes that break the
two appart.
I say go for revolutional change in Python 3.2. But the call is yours.
----------
components: Interpreter Core
messages: 95668
nosy: Retro, gvanrossum
severity: normal
status: open
title: Make decimal floating point be default, remove binary floating point
type: feature request
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7389>
_______________________________________
From report at bugs.python.org Tue Nov 24 13:37:27 2009
From: report at bugs.python.org (=?utf-8?q?S=C3=A9rgio_Surkamp?=)
Date: Tue, 24 Nov 2009 12:37:27 +0000
Subject: [New-bugs-announce] [issue7390] inconsistent type return
In-Reply-To: <1259066247.95.0.49478511562.issue7390@psf.upfronthosting.co.za>
Message-ID: <1259066247.95.0.49478511562.issue7390@psf.upfronthosting.co.za>
New submission from S?rgio Surkamp <sergio at gruposinternet.com.br>:
The type function returns inconsistent value depending on class hierarchy.
>>> class X:
... pass
...
>>> x = X()
>>> type(x)
<type 'instance'>
>>> class Y(object):
... pass
...
>>> x = Y()
>>> type(x)
<class '__main__.Y'>
>>>
>>> class Z(X):
... pass
...
>>> x = Z()
>>> type(x)
<type 'instance'>
>>> class K(Y):
... pass
...
>>> x = K()
>>> type(x)
<class '__main__.K'>
All should reply 'instance'. As long as I have read on documentation the
only way to change the type function return is by writing a
__metaclass__ (PEP3115).
----------
components: Interpreter Core
messages: 95670
nosy: surkamp
severity: normal
status: open
title: inconsistent type return
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7390>
_______________________________________
From report at bugs.python.org Tue Nov 24 15:19:23 2009
From: report at bugs.python.org (Neil Cerutti)
Date: Tue, 24 Nov 2009 14:19:23 +0000
Subject: [New-bugs-announce] [issue7391] Re-title the "Using Backslash to
Continue Statements" anti-idiom
In-Reply-To: <1259072363.61.0.346322429524.issue7391@psf.upfronthosting.co.za>
Message-ID: <1259072363.61.0.346322429524.issue7391@psf.upfronthosting.co.za>
New submission from Neil Cerutti <cerutti at trans-video.net>:
This "anti-idiom" is in the Python HOWTOs->Idioms and Anti-Idioms
The current title is "Using Backslash to Continue Statements"
However, using the line continuation character won't cause mysterious
problems in statements, but only in certain expressions, as the article
goes on to explain.
Moreover, the proposed solution of wrapping expressions in parentheses
is a syntax error in a statement, e.g.:
with (open(roster_path, 'r') as roster_file,
open(disb_path, 'w') as out_file,
open(report_path, 'w') as report_file):
File "C:\project\codxml.py", line 184
with (open(roster_path, 'r') as roster_file,
^
SyntaxError: invalid syntax
I suggest that the title be changed to "Using Backslash to Continue
Expressions."
I'm sorry I don't know for sure when this HOWTO was first included in
the normal Python distribution.
----------
assignee: georg.brandl
components: Documentation
messages: 95676
nosy: Horpner, georg.brandl
severity: normal
status: open
title: Re-title the "Using Backslash to Continue Statements" anti-idiom
versions: Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7391>
_______________________________________
From report at bugs.python.org Tue Nov 24 19:05:41 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 24 Nov 2009 18:05:41 +0000
Subject: [New-bugs-announce] [issue7392] cPickle test failure on
release26-maint branch
In-Reply-To: <1259085941.32.0.227872963702.issue7392@psf.upfronthosting.co.za>
Message-ID: <1259085941.32.0.227872963702.issue7392@psf.upfronthosting.co.za>
New submission from Alexandre Vassalotti <alexandre at peadrop.com>:
I get the following test failure on the release26-maint branch:
./python Lib/test/test_cpickle.py
[...]
======================================================================
ERROR: test_issue2702 (__main__.cPickleDeepRecursive)
----------------------------------------------------------------------
Traceback (most recent call last):
File "Lib/test/test_cpickle.py", line 110, in test_issue2702
self.assertRaises(RuntimeError, cPickle.dumps, n)
File "/home/alex/src/python.org/release26-maint/Lib/unittest.py", line
336, in failUnlessRaises
callableObj(*args, **kwargs)
File "/home/alex/src/python.org/release26-maint/Lib/copy_reg.py", line
74, in _reduce_ex
getstate = self.__getstate__
AttributeError: 'Node' object has no attribute '__getstate__'
----------
components: Library (Lib), Tests
messages: 95692
nosy: alexandre.vassalotti
priority: normal
severity: normal
stage: needs patch
status: open
title: cPickle test failure on release26-maint branch
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7392>
_______________________________________
From report at bugs.python.org Wed Nov 25 08:09:55 2009
From: report at bugs.python.org (Mayuresh)
Date: Wed, 25 Nov 2009 07:09:55 +0000
Subject: [New-bugs-announce] [issue7393] Executing Python program of sum of
2 nos.
In-Reply-To: <1259132995.34.0.685244860607.issue7393@psf.upfronthosting.co.za>
Message-ID: <1259132995.34.0.685244860607.issue7393@psf.upfronthosting.co.za>
New submission from Mayuresh <mayur_marathe at hotmail.com>:
I am getting error of sum of two nos. the output should give addition
of two numbers,but instead it is displaying 2 nos. side-by-side.I have
pasted the program and output for the same.
print "Please give a number: "
a = input()
print "And another: "
b = input()
print "The sum of these numbers is: "
print a + b
output should be a=21,b=21, a+b=42
whereas it is showing 2121.
----------
components: IDLE
messages: 95711
nosy: mayur78
severity: normal
status: open
title: Executing Python program of sum of 2 nos.
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7393>
_______________________________________
From report at bugs.python.org Wed Nov 25 17:39:19 2009
From: report at bugs.python.org (dontbugme)
Date: Wed, 25 Nov 2009 16:39:19 +0000
Subject: [New-bugs-announce] [issue7394] sqlite3: some OperationalError
exceptions should be ProgrammingError (PEP 249)
In-Reply-To: <1259167159.55.0.802533140683.issue7394@psf.upfronthosting.co.za>
Message-ID: <1259167159.55.0.802533140683.issue7394@psf.upfronthosting.co.za>
New submission from dontbugme <pythonbugsbugmenot at spamavert.com>:
The following code raises OperationalError exceptions:
python -c 'import sqlite3; sqlite3.connect(":memory:").execute("bad
syntax")'
python -c 'import sqlite3; sqlite3.connect(":memory:").execute("SELECT *
FROM no_such_table")'
python -c 'import sqlite3; sqlite3.connect(":memory:").execute("SELECT
no_such_column")'
But ProgrammingError should be raised, as per PEP 249:
ProgrammingError
Exception raised for programming errors, e.g. table not
found or already exists, syntax error in the SQL
statement, wrong number of parameters specified, etc. It
must be a subclass of DatabaseError.
----------
components: Library (Lib)
messages: 95719
nosy: dontbugme
severity: normal
status: open
title: sqlite3: some OperationalError exceptions should be ProgrammingError (PEP 249)
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7394>
_______________________________________
From report at bugs.python.org Thu Nov 26 00:35:43 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 25 Nov 2009 23:35:43 +0000
Subject: [New-bugs-announce] [issue7395] pstats add command raises unhandled
exception
In-Reply-To: <1259192143.69.0.167653285401.issue7395@psf.upfronthosting.co.za>
Message-ID: <1259192143.69.0.167653285401.issue7395@psf.upfronthosting.co.za>
New submission from Jean-Paul Calderone <exarkun at divmod.com>:
$ python -m pstats
Welcome to the profile statistics browser.
% help
Documented commands (type help <topic>):
========================================
EOF add callees callers quit read reverse sort stats strip
Undocumented commands:
======================
help
% help add
Add profile info from given file to current statistics object.
% add client.prof
Traceback (most recent call last):
File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
exec code in run_globals
File "/usr/lib/python2.6/pstats.py", line 690, in <module>
browser.cmdloop()
File "/usr/lib/python2.6/cmd.py", line 142, in cmdloop
stop = self.onecmd(line)
File "/usr/lib/python2.6/cmd.py", line 219, in onecmd
return func(arg)
File "/usr/lib/python2.6/pstats.py", line 600, in do_add
self.stats.add(line)
AttributeError: 'NoneType' object has no attribute 'add'
$
----------
components: Library (Lib)
messages: 95729
nosy: exarkun
severity: normal
status: open
title: pstats add command raises unhandled exception
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7395>
_______________________________________
From report at bugs.python.org Thu Nov 26 05:50:15 2009
From: report at bugs.python.org (James G. sack (jim))
Date: Thu, 26 Nov 2009 04:50:15 +0000
Subject: [New-bugs-announce] [issue7396] regrtest single: iterator not
subscriptable
In-Reply-To: <1259211015.26.0.0435309499535.issue7396@psf.upfronthosting.co.za>
Message-ID: <1259211015.26.0.0435309499535.issue7396@psf.upfronthosting.co.za>
New submission from James G. sack (jim) <jgsack at users.sourceforge.net>:
file Lib/tests/regrtest.py
Evidently rev 76260 (trunk) / 76261 (py3k)
broke code at
rev 76324 line 655 (py3k)
rev 76321 line 620 (trunk)
which is
if tests[0] == alltests[i]
because tests was rebound from a list to an iterable, and hence indexing
cannot be performed on tests subsequent to the rebinding.
There are a few other places where tests is indexed, but I suspect those
places are before the rebinding to an iterable.
At first glance, a viable patch might be to use a different name, eg
itests, and leave the original tests list available for use by the line
causing the TypeError. However, I think someone more knowledgeable needs
to have a look.
Ummm, forgive me if this is offbase, but would it be fair to identify as
a bad practice, the rebinding of a variable to a different type.
~jim
----------
messages: 95731
nosy: jgsack
severity: normal
status: open
title: regrtest single: iterator not subscriptable
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7396>
_______________________________________
From report at bugs.python.org Thu Nov 26 12:33:19 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Nov 2009 11:33:19 +0000
Subject: [New-bugs-announce] [issue7397] __import__ docs should reference
imputil.import_module
In-Reply-To: <1259235199.82.0.599302527492.issue7397@psf.upfronthosting.co.za>
Message-ID: <1259235199.82.0.599302527492.issue7397@psf.upfronthosting.co.za>
New submission from Nick Coghlan <ncoghlan at gmail.com>:
Fairly straightforward one - __import__ is no longer the preferred tool
for doing runtime imports, so its documentation should point to
imputil.import_module
(this is a little more than just a "see also", some of the existing
wording in the first few paragraphs should also be tweaked)
----------
assignee: georg.brandl
components: Documentation
keywords: easy
messages: 95736
nosy: georg.brandl, ncoghlan
severity: normal
status: open
title: __import__ docs should reference imputil.import_module
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7397>
_______________________________________
From report at bugs.python.org Thu Nov 26 13:23:48 2009
From: report at bugs.python.org (Paul H)
Date: Thu, 26 Nov 2009 12:23:48 +0000
Subject: [New-bugs-announce] [issue7398] Issue with _PyLong_Format while
trying to build Python on HP-UX itanium
In-Reply-To: <1259238228.23.0.895508664034.issue7398@psf.upfronthosting.co.za>
Message-ID: <1259238228.23.0.895508664034.issue7398@psf.upfronthosting.co.za>
New submission from Paul H <paulh.misc at gmail.com>:
Hello all,
First post here so go easy on me please! And please bear in mind I am
not a C programmer, just a unix admin trying to build python as an
option for other programmers to use.
I am trying to build Python 3.1.1 on HP-UX itanium. OS and compiler
details are as follows:
HP-UX <hostname> B.11.31 U ia64 2812253632 unlimited-user license
aCC: HP C/aC++ B3910B A.06.23 [May 18, 2009]
So far, with the help of this forum and documentation from this and
previous versions of Python, I have been working through the process as
follows:
export CC="/opt/aCC/bin/aCC -Ae +DD64"
export CFLAGS="-Ae +DD64"
export CXX="/opt/aCC/bin/aCC -Ae"
export CXXFLAGS="-Ae +DD64"
export LDFLAGS="+DD64 -L/usr/local/bzip2-1.0.3/lib"
./configure --prefix=<my target>/python/3.1.1 --without-gcc
unset CC CFLAGS CXX CXXFLAGS LDFLAGS
make
I've been working through the various errors I've been getting as best I
can and have hit one that I don't think I can progress:
"Python/../Objects/stringlib/formatter.h", line 1369: error #2140: too many
arguments in function call
return _PyLong_Format(value, base, 0, 1);
It looks like _PyLong_Format is defined in Objects/longobject.c.
Any ideas on how to progress this one, or indeed any tips to get a
successful build on my architecture, would be much appreciated.
Many thanks,
Paul.
----------
components: Build
messages: 95741
nosy: paulh_irl
severity: normal
status: open
title: Issue with _PyLong_Format while trying to build Python on HP-UX itanium
type: compile error
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7398>
_______________________________________
From report at bugs.python.org Thu Nov 26 17:30:26 2009
From: report at bugs.python.org (David Henretty)
Date: Thu, 26 Nov 2009 16:30:26 +0000
Subject: [New-bugs-announce] [issue7399] Possible bug in Python Tutorial
In-Reply-To: <1259253026.9.0.615339023248.issue7399@psf.upfronthosting.co.za>
Message-ID: <1259253026.9.0.615339023248.issue7399@psf.upfronthosting.co.za>
New submission from David Henretty <dhenretty at a2etech.com>:
Hi,
In the v3.1.1 Python Tutorial (section 10.7 - Internet Access), the
sample code (shown below) results in the following error :-
from urllib.request import urlopen
for line in urlopen('http://tycho.usno.navy.mil/cgi-bin/timer.pl'):
if 'EST' in line or 'EDT' in line:
print(line)
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
TypeError: Type str doesn't support the buffer API
I presume this has something to do with the assumed type of the
variable 'line', but I am very new to Python.
Replacing the 'if' line with the following DOES work :-
if 'EST' in str(line) or 'EDT' in str(line):
Can anyone confirm / explain this ?
Thanks,
DH
----------
assignee: georg.brandl
components: Documentation
messages: 95749
nosy: dh, georg.brandl
severity: normal
status: open
title: Possible bug in Python Tutorial
type: compile error
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7399>
_______________________________________
From report at bugs.python.org Thu Nov 26 21:10:41 2009
From: report at bugs.python.org (Renato Cunha)
Date: Thu, 26 Nov 2009 20:10:41 +0000
Subject: [New-bugs-announce] [issue7400] Small typo in Python's library
documentation: set
In-Reply-To: <1259266241.33.0.106034048132.issue7400@psf.upfronthosting.co.za>
Message-ID: <1259266241.33.0.106034048132.issue7400@psf.upfronthosting.co.za>
New submission from Renato Cunha <renato at renatocunha.com>:
In the documentation of the built-in functions, the description of set
says "Return a new set, optionally with elements ARE taken from
iterable. ...".
The referenced text should be either "... optionally with elements taken
from iterable. ...".
----------
assignee: georg.brandl
components: Documentation
files: set-typo-fix.diff
keywords: patch
messages: 95752
nosy: georg.brandl, trovao
severity: normal
status: open
title: Small typo in Python's library documentation: set
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15399/set-typo-fix.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7400>
_______________________________________
From report at bugs.python.org Fri Nov 27 00:22:25 2009
From: report at bugs.python.org (Hugh Secker-Walker)
Date: Thu, 26 Nov 2009 23:22:25 +0000
Subject: [New-bugs-announce] [issue7401] os.write and os.close on pipe from
separate threads hangs on Mac OS X
In-Reply-To: <1259277745.82.0.939130045667.issue7401@psf.upfronthosting.co.za>
Message-ID: <1259277745.82.0.939130045667.issue7401@psf.upfronthosting.co.za>
New submission from Hugh Secker-Walker <hughsw at users.sourceforge.net>:
The attached script demonstrates a problem on Mac OS X 10.5 whereby
Python can hang while simultaneously trying os.write with a large buffer
and os.close, from separate threads on the write and read fds
respectively of a pipe.
----------
components: IO
files: os_pipe_write_close_bug.py
messages: 95755
nosy: hughsw
severity: normal
status: open
title: os.write and os.close on pipe from separate threads hangs on Mac OS X
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15400/os_pipe_write_close_bug.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7401>
_______________________________________
From report at bugs.python.org Fri Nov 27 11:47:22 2009
From: report at bugs.python.org (Christoph Zwerschke)
Date: Fri, 27 Nov 2009 10:47:22 +0000
Subject: [New-bugs-announce] [issue7402] reduce() is an anti-example in
"Idioms and Anti-Idioms"
In-Reply-To: <1259318842.77.0.740725384087.issue7402@psf.upfronthosting.co.za>
Message-ID: <1259318842.77.0.740725384087.issue7402@psf.upfronthosting.co.za>
New submission from Christoph Zwerschke <cito at online.de>:
In the section "Using the batteries" of the "Idioms and Anti-Idioms in
Python" document
(http://docs.python.org/dev/howto/doanddont.html#using-the-batteries),
the reduce statement is used for summing up numbers as an example. I
think this is rather an anti-example, because Python already has a sum
function built-in, i.e. reduce(operator.add, nums)/len(nums) can be
written much simpler as sum(nums)/len(nums).
----------
assignee: georg.brandl
components: Documentation
messages: 95762
nosy: cito, georg.brandl
severity: normal
status: open
title: reduce() is an anti-example in "Idioms and Anti-Idioms"
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7402>
_______________________________________
From report at bugs.python.org Fri Nov 27 12:42:41 2009
From: report at bugs.python.org (Gavin Panella)
Date: Fri, 27 Nov 2009 11:42:41 +0000
Subject: [New-bugs-announce] [issue7403] Race condition in
logging._acquireLock()?
In-Reply-To: <1259322161.32.0.385116687037.issue7403@psf.upfronthosting.co.za>
Message-ID: <1259322161.32.0.385116687037.issue7403@psf.upfronthosting.co.za>
New submission from Gavin Panella <gavin at gromper.net>:
The logging module create a global _lock in what looks like a
thread-unsafe manner:
{{{
_lock = None
def _acquireLock():
"""
Acquire the module-level lock for serializing access to shared data.
This should be released with _releaseLock().
"""
global _lock
if (not _lock) and thread:
_lock = threading.RLock()
if _lock:
_lock.acquire()
}}}
If two threads call _acquireLock() at the same time, and _lock is
None, it's possible that two locks will be created, one of which will
get clobbered.
I think the above could be made thread-safe if written as:
{{{
if thread:
_lock = threading.RLock()
else:
_lock = None
def _acquireLock():
"""
Acquire the module-level lock for serializing access to shared data.
This should be released with _releaseLock().
"""
if _lock:
_lock.acquire()
}}}
----------
components: Library (Lib)
messages: 95764
nosy: allenap
severity: normal
status: open
title: Race condition in logging._acquireLock()?
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7403>
_______________________________________
From report at bugs.python.org Sat Nov 28 04:12:46 2009
From: report at bugs.python.org (Mark Roddy)
Date: Sat, 28 Nov 2009 03:12:46 +0000
Subject: [New-bugs-announce] [issue7404] optparse Documentation References
Example Files that do not Exist
In-Reply-To: <1259377966.36.0.486259270616.issue7404@psf.upfronthosting.co.za>
Message-ID: <1259377966.36.0.486259270616.issue7404@psf.upfronthosting.co.za>
New submission from Mark Roddy <markroddy at gmail.com>:
In the 'Terminology' section of the optparse module documentation, under
the description of the term 'required option', a reference to example
implementations of this concept are stated to be available in two
example files of the source distribution:
"See examples/required_1.py and examples/required_2.py in the optparse
source distribution for two ways to implement required options with
optparse."
These two files do not appear to have ever been available with python
but are found in the original 'Optik' distribution that this module is
derived from. I am guessing that this is a result of the documentation
being copied when the module was added to the standard library as it
also appears in the Optik documentation almost verbatim:
http://optik.sourceforge.net/doc/1.5/tao.html
Suggest the reference to these files:
1) Be removed as to prevent confusion as to their existence/location
2) Be updated to point to the Optik source on source forge
3) Merge the examples in line with the documentation
or
4) Some other option I have not thought of
----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 95780
nosy: MarkRoddy, georg.brandl
severity: normal
status: open
title: optparse Documentation References Example Files that do not Exist
type: feature request
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7404>
_______________________________________
From report at bugs.python.org Sat Nov 28 06:41:13 2009
From: report at bugs.python.org (jeff deifik)
Date: Sat, 28 Nov 2009 05:41:13 +0000
Subject: [New-bugs-announce] [issue7405] compiling python 3.1.1 using cygwin
1.7.0 and gcc 4.3.4
In-Reply-To: <1259386873.79.0.422049105742.issue7405@psf.upfronthosting.co.za>
Message-ID: <1259386873.79.0.422049105742.issue7405@psf.upfronthosting.co.za>
New submission from jeff deifik <jeff at jeffunit.com>:
In order to compile 3.1.1 with the cygwin environment, it was necessary
to edit Modules/main.c after running configure
There are a few tests that still fail when running 'make test', but
overall, python 3.1.1 works fine.
Included is the context diff.
----------
components: Build
files: the_diff.txt
messages: 95784
nosy: lopgok
severity: normal
status: open
title: compiling python 3.1.1 using cygwin 1.7.0 and gcc 4.3.4
versions: Python 3.1
Added file: http://bugs.python.org/file15410/the_diff.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7405>
_______________________________________
From report at bugs.python.org Sun Nov 29 12:56:23 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 29 Nov 2009 11:56:23 +0000
Subject: [New-bugs-announce] [issue7406] int arithmetic relies on C signed
overflow behaviour
In-Reply-To: <1259495783.96.0.0738564373709.issue7406@psf.upfronthosting.co.za>
Message-ID: <1259495783.96.0.0738564373709.issue7406@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
Much of the code in Objects/intobject.c assumes that an arithmetic
operation on signed longs will wrap modulo 2**(bits_in_long) on
overflow. However, signed overflow causes undefined behaviour according
to the C standards (e.g., C99 6.5, para. 5), and gcc is known to assume
that signed overflow never occurs in correct code, and to make use of
this assumption when optimizing.
An obvious example is found in int_add, which looks like this:
static PyObject *
int_add(PyIntObject *v, PyIntObject *w)
{
register long a, b, x;
CONVERT_TO_LONG(v, a);
CONVERT_TO_LONG(w, b);
x = a + b;
if ((x^a) >= 0 || (x^b) >= 0)
return PyInt_FromLong(x);
return PyLong_Type.tp_as_number->nb_add((PyObject *)v, (PyObject
*)w);
}
Here Python is relying on the line 'x = a + b' wrapping on overflow.
While this code doesn't seem to have caused any problems to date, it's
not at all inconceivable that some future version of GCC is clever
enough to figure out that (with its assumption that correct code never
includes signed overflow) the if condition is always false, so can be
optimized away. At that point, a Python interpreter built with this
version of GCC would produce incorrect results for int addition.
More generally, Python's source makes a number of assumptions about
integer arithmetic that aren't guaranteed by the C standards. Most of
these assumptions are likely to be harmless on modern machines, but the
assumptions should probably at least be documented somewhere, and
ideally also checked somewhere in the configuration, so that attempts to
port Python to machines that don't obey these assumptions complain
loudly. Namely, the source assumes at least that:
- C signed ints are represented in two's complement, not ones'
complement or sign-and-magnitude.
- the bit pattern 1000....000 is not a trap representation (so
e.g., INT_MIN = -INT_MAX-1, not -INT_MAX).
- conversion from an unsigned integer type to the corresponding signed
type wraps modulo 2**(appropriate_number_of_bits).
(Relevant standard sections: C99 6.2.6.2, C99 6.3.1.3p3.)
See also issue 1621.
----------
components: Interpreter Core
messages: 95803
nosy: mark.dickinson
severity: normal
stage: needs patch
status: open
title: int arithmetic relies on C signed overflow behaviour
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7406>
_______________________________________
From report at bugs.python.org Sun Nov 29 17:00:12 2009
From: report at bugs.python.org (Floris Bruynooghe)
Date: Sun, 29 Nov 2009 16:00:12 +0000
Subject: [New-bugs-announce] [issue7407] Minor Queue doc improvement
In-Reply-To: <1259510412.02.0.297127408529.issue7407@psf.upfronthosting.co.za>
Message-ID: <1259510412.02.0.297127408529.issue7407@psf.upfronthosting.co.za>
New submission from Floris Bruynooghe <floris.bruynooghe at gmail.com>:
The documentation of the queue module (Queue in 2.x) does not mention
that the constructors have a default argument of 0 for "maxsize". The
trivial patch adds this (patch against py3k trunk).
----------
assignee: georg.brandl
components: Documentation
files: queue.diff
keywords: patch
messages: 95806
nosy: flub, georg.brandl
severity: normal
status: open
title: Minor Queue doc improvement
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15413/queue.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7407>
_______________________________________
From report at bugs.python.org Sun Nov 29 18:21:10 2009
From: report at bugs.python.org (Titus Brown)
Date: Sun, 29 Nov 2009 17:21:10 +0000
Subject: [New-bugs-announce] [issue7408] test_distutils fails on Mac OS X
10.5
In-Reply-To: <1259515270.43.0.427140625875.issue7408@psf.upfronthosting.co.za>
Message-ID: <1259515270.43.0.427140625875.issue7408@psf.upfronthosting.co.za>
New submission from Titus Brown <titus at idyll.org>:
Here's the error:
test_distutils
test test_distutils failed -- Traceback (most recent call last):
File
"/private/tmp/tmp8UfLPT/python27/Lib/distutils/tests/test_sdist.py",
line 342, in test_make_distribution_owner_group
self.assertEquals(member.gid, os.getgid())
AssertionError: 0 != 20
It has been a problem for over a week, at least.
----------
assignee: tarek
components: Distutils
messages: 95809
nosy: tarek, titus
severity: normal
status: open
title: test_distutils fails on Mac OS X 10.5
type: behavior
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7408>
_______________________________________
From report at bugs.python.org Sun Nov 29 23:23:30 2009
From: report at bugs.python.org (Robert Collins)
Date: Sun, 29 Nov 2009 22:23:30 +0000
Subject: [New-bugs-announce] [issue7409] cleanup now deepcopy copies
instance methods
In-Reply-To: <1259533410.59.0.838597204894.issue7409@psf.upfronthosting.co.za>
Message-ID: <1259533410.59.0.838597204894.issue7409@psf.upfronthosting.co.za>
New submission from Robert Collins <robertc at robertcollins.net>:
With deepcopy fixed, I ran across this little fixable component.
----------
components: Library (Lib)
files: deepcopy-works.patch
keywords: patch
messages: 95823
nosy: rbcollins
severity: normal
status: open
title: cleanup now deepcopy copies instance methods
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15417/deepcopy-works.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7409>
_______________________________________
From report at bugs.python.org Mon Nov 30 03:04:48 2009
From: report at bugs.python.org (Robert Collins)
Date: Mon, 30 Nov 2009 02:04:48 +0000
Subject: [New-bugs-announce] [issue7410] deepcopy of itertools.count resets
the count
In-Reply-To: <1259546688.1.0.524850566864.issue7410@psf.upfronthosting.co.za>
Message-ID: <1259546688.1.0.524850566864.issue7410@psf.upfronthosting.co.za>
New submission from Robert Collins <robertc at robertcollins.net>:
>>> from copy import deepcopy
>>> from itertools import count
>>> c = count()
>>> c.next()
0
>>> deepcopy(c)
count(0)
>>> c.next()
1
>>> deepcopy(c)
count(0)
>>> c
count(2)
>>> deepcopy(c).next()
0
I don't see any reason why these shouldn't be deepcopyable (or picklable
for that reason - and that fails too)
----------
components: Library (Lib)
messages: 95830
nosy: rbcollins
severity: normal
status: open
title: deepcopy of itertools.count resets the count
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7410>
_______________________________________
From report at bugs.python.org Mon Nov 30 08:01:16 2009
From: report at bugs.python.org (Phillip M. Feldman)
Date: Mon, 30 Nov 2009 07:01:16 +0000
Subject: [New-bugs-announce] [issue7411] allow import from file having name
containing hyphen or blank
In-Reply-To: <1259564476.99.0.910098142875.issue7411@psf.upfronthosting.co.za>
Message-ID: <1259564476.99.0.910098142875.issue7411@psf.upfronthosting.co.za>
New submission from Phillip M. Feldman <pfeldman at verizon.net>:
It appears that there is currently no way to import from a file whose
name contains a hyphen or blank. This makes it difficult to encode a
version number or date in the file name. The solution that I favor
would be to allow the name of the file to be specified via a quoted string.
----------
components: Interpreter Core
messages: 95832
nosy: pfeldman at verizon.net
severity: normal
status: open
title: allow import from file having name containing hyphen or blank
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7411>
_______________________________________
From report at bugs.python.org Mon Nov 30 10:01:06 2009
From: report at bugs.python.org (Rene Dudfield)
Date: Mon, 30 Nov 2009 09:01:06 +0000
Subject: [New-bugs-announce] [issue7412] distutils install race condition
In-Reply-To: <1259571666.51.0.555227768726.issue7412@psf.upfronthosting.co.za>
Message-ID: <1259571666.51.0.555227768726.issue7412@psf.upfronthosting.co.za>
New submission from Rene Dudfield <illume at users.sourceforge.net>:
hello!
Pythons distutils has a race condition where it starts to copy files
into the python path whilst installing.
This is a race condition, since python programs can be importing the
package whilst the package is being installed.
It would be good for distutils to install things in an atomic manner.
Where things can be installed, or not installed. Like, on unix by moving
the files in from a temporary directory. This would also help reduce
breakages. Since if a package breaks half way installing a package then
the broken version will not over write the existing version.
It's not a very serious problem, since most people don't install things
on live important systems(but some do). It does make hard to diagnose
problems though... which are good ones to fix. Most packaging tools fix
the issues with the source installs (eg, using .deb installers).
I've only looked at the source install, but I imagine other install
methods might be affected too.
os.rename
mkdtemp
http://docs.python.org/library/tempfile.html#tempfile.mkdtemp
Perhaps files should be created in the /tmp first, and then moved in.
/tmp/ can be in a different file system so a rename won't work in that
case on some OSes. If you create the temp directory in the same
directory as the directory to install. In that case rename doesn't
work, using the temp file system(eg /tmp) and then copying to a temp
directory in the site-packages directory, with finally a move into place.
If copying to the site-packages before moving, then there could be left
over temp files in the site-packages directory. So these would need to
be considered, and cruft cleaned up. This is why using the normal temp
directory would be better, since the temp files will be cleaned as
normal policy on the system.
setuptools/distribute writes the .egg-info at the end of the install.
This should also use a move for install, for the same reasons. However,
there might still be a separate race condition since that lives in a
different directory. Since you can not atomically move two things at
once( I think? ) the .egg-info will continue to be a race condition,
unless both directories are moved into the same one.
Just as moving packages into place will make the installs more robust,
so will testing the packages before moving them into place. Some way to
test the install before moving it into place would be good. Or at least
trying to import the package in a sub process. Taking advantage of the
test command could be an idea. Test before moving into place would give
a better chance of good packages being used. Import before moving into
place could also help.
----------
assignee: tarek
components: Distutils
messages: 95833
nosy: illume, tarek
severity: normal
status: open
title: distutils install race condition
type: security
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7412>
_______________________________________