From report at bugs.python.org Thu Oct 1 00:32:35 2009
From: report at bugs.python.org (Jon Parise)
Date: Wed, 30 Sep 2009 22:32:35 +0000
Subject: [New-bugs-announce] [issue7025] Python 3.1 and 3.2 (dev)
opensearch.xml still references 3.0
In-Reply-To: <1254349955.07.0.60985780898.issue7025@psf.upfronthosting.co.za>
Message-ID: <1254349955.07.0.60985780898.issue7025@psf.upfronthosting.co.za>
New submission from Jon Parise <jon at indelible.org>:
The _static/opensearch.xml output on docs.python.org for the 3.1 and 3.2
(dev/py3k) branches still refers to the 3.0 documentation.
Doc/conf.py's html_use_opensearch value should be updated in those
source branches to reflect their updated version numbers.
----------
assignee: georg.brandl
components: Documentation
messages: 93378
nosy: georg.brandl, jon
severity: normal
status: open
title: Python 3.1 and 3.2 (dev) opensearch.xml still references 3.0
type: behavior
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7025>
_______________________________________
From report at bugs.python.org Thu Oct 1 02:49:10 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 01 Oct 2009 00:49:10 +0000
Subject: [New-bugs-announce] [issue7026] test_urllib: unsetting missing
'env' variable
In-Reply-To: <1254358150.75.0.46389883722.issue7026@psf.upfronthosting.co.za>
Message-ID: <1254358150.75.0.46389883722.issue7026@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
test test_urllib failed -- Traceback (most recent call last):
File "/home/apy/rrun/tmp/autotest/apy/lib/python2.6/test/
test_urllib.py", line 106, in setUp
env.unset(k)
NameError: global name 'env' is not defined
Looking in trunk's copy I see this:
def setUp(self):
# Records changes to env vars
self.env = test_support.EnvironmentVarGuard()
# Delete all proxy related env vars
for k, v in os.environ.iteritems():
if 'proxy' in k.lower():
del env[k]
Should not that be "del self.env[k]"?
----------
components: Tests
messages: 93384
nosy: srid
severity: normal
status: open
title: test_urllib: unsetting missing 'env' variable
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7026>
_______________________________________
From report at bugs.python.org Thu Oct 1 03:01:39 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 01 Oct 2009 01:01:39 +0000
Subject: [New-bugs-announce] [issue7027] test_io.py:
codecs.IncrementalDecoder is sometimes None
In-Reply-To: <1254358899.51.0.885628036765.issue7027@psf.upfronthosting.co.za>
Message-ID: <1254358899.51.0.885628036765.issue7027@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
This test failure occurs on Windows XP (x86) with 2.6.3.rc1
======================================================================
ERROR: Test seek/tell using the StatefulIncrementalDecoder.
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Python26\lib\test\test_io.py", line 1063, in testSeekAndTell
testSeekAndTellWithData(input)
File "C:\Python26\lib\test\test_io.py", line 1043, in
testSeekAndTellWithData
decoded = f.read()
File "C:\Python26\lib\io.py", line 1725, in read
decoder = self._decoder or self._get_decoder()
File "C:\Python26\lib\io.py", line 1514, in _get_decoder
decoder = make_decoder(self._errors)
File "C:\Python26\lib\test\test_io.py", line 636, in __init__
codecs.IncrementalDecoder.__init__(self, errors)
AttributeError: 'NoneType' object has no attribute 'IncrementalDecoder'
----------
components: Tests
messages: 93387
nosy: srid
severity: normal
status: open
title: test_io.py: codecs.IncrementalDecoder is sometimes None
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7027>
_______________________________________
From report at bugs.python.org Thu Oct 1 04:51:53 2009
From: report at bugs.python.org (Josh Cogliati)
Date: Thu, 01 Oct 2009 02:51:53 +0000
Subject: [New-bugs-announce] [issue7028] hex function should work with floats
In-Reply-To: <1254365513.69.0.169438970991.issue7028@psf.upfronthosting.co.za>
Message-ID: <1254365513.69.0.169438970991.issue7028@psf.upfronthosting.co.za>
New submission from Josh Cogliati <jjcogliati-r1 at yahoo.com>:
The hex() builtin function only takes integers. Also there is no way to
create a floating point number from a hexadecimal string. However it
would often be useful to be able to see the hexadecimal version of an
float since this is an exact representation as compared to the decimal
version.
I propose that the format 0xMantisaP0xBase2Exponent be used (but other
possibilities would be fine. For example in this way 0.5 decimal would
be 0x1p-0x1 hex. 1.1 decimal would be 0x8cccccccccccdp-0x33 and pi
would be 0x3243f6a8885a3p-0x30
Attached are two functions I created to implement this. If this would
be better as a PEP I will create one.
This will cause a slight incompatibility, since now hex will throw an
exception if it is passed a float.
----------
components: Library (Lib)
files: fhex.py
messages: 93389
nosy: jrincayc
severity: normal
status: open
title: hex function should work with floats
versions: Python 3.1
Added file: http://bugs.python.org/file15011/fhex.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7028>
_______________________________________
From report at bugs.python.org Thu Oct 1 19:16:43 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 01 Oct 2009 17:16:43 +0000
Subject: [New-bugs-announce] [issue7029] Improve pybench
In-Reply-To: <1254417403.92.0.577059221924.issue7029@psf.upfronthosting.co.za>
Message-ID: <1254417403.92.0.577059221924.issue7029@psf.upfronthosting.co.za>
New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:
The attached patch contains suggested fixes to pybench.py:
1) add a processtime timer for windows
2) fix a bug in timer selection: timer wasn't put in 'self'
3) Collect 'gross' times for each round
4) show statistics for per-round sums, both for sum of "adjusted" times
for each round, and 'gross' time per round.
The last one is important. Traditionally, the focus would be on
individual tests. The series of individual timings for each test would
be examined, min and afverage found. These minima and averages would
then be summed up to get a total time. These results are very noisy.
In addition, the sum of individual minima is not a linear operator that
has any meaning and is thus extremely noisy.
Looking at the minimum and average of the sum is a much stabler
indication of total benchmark performance.
Another thing that I found when working with this, is that using
"calibration" significantly adds to noise and can produce incorrect
results. It adds a level of non-linearity to the results that can
appear very strange. Typically the 'overhead' is so low that we should
consider skipping the calibration. The purpose of the benchmark must be
to measure the performance of python in context. The meaning of
individual operations in isolation are pretty meaningless. Although I
didn't change the default number of calibration runs from 10, I would
suggest documenting that it may be useful to turn it to 0 to increase
predictability and get numbers indicative of real performance.
----------
components: Demos and Tools
files: pybench.patch
keywords: patch
messages: 93416
nosy: krisvale
severity: normal
status: open
title: Improve pybench
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file15016/pybench.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7029>
_______________________________________
From report at bugs.python.org Thu Oct 1 22:09:01 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 01 Oct 2009 20:09:01 +0000
Subject: [New-bugs-announce] [issue7030] Update version{added,
changed} entries in py3k unittest docs
In-Reply-To: <1254427741.8.0.290853000948.issue7030@psf.upfronthosting.co.za>
Message-ID: <1254427741.8.0.290853000948.issue7030@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
The py3k unittest docs have a few instances of:
.. versionadded:: 2.7
and
.. versionchanged:: 2.7
Presumably all of these should be either 3.1 or 3.2. I'd fix them, but
I think Michael has a much better chance of getting all the version
numbers right. :)
----------
assignee: michael.foord
components: Documentation
messages: 93419
nosy: mark.dickinson, michael.foord
severity: normal
status: open
title: Update version{added,changed} entries in py3k unittest docs
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7030>
_______________________________________
From report at bugs.python.org Thu Oct 1 22:22:31 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 01 Oct 2009 20:22:31 +0000
Subject: [New-bugs-announce] [issue7031] add assertIsInstance
Message-ID: <1254428551.17.0.819786808833.issue7031@psf.upfronthosting.co.za>
Changes by Georg Brandl <georg at python.org>:
----------
assignee: michael.foord
components: Library (Lib)
files: assertIsInstance.diff
keywords: easy, needs review, patch, patch
nosy: georg.brandl, michael.foord
priority: normal
severity: normal
status: open
title: add assertIsInstance
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15017/assertIsInstance.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7031>
_______________________________________
From report at bugs.python.org Fri Oct 2 00:29:45 2009
From: report at bugs.python.org (Michael Foord)
Date: Thu, 01 Oct 2009 22:29:45 +0000
Subject: [New-bugs-announce] [issue7032] Make assertMultilineEqual default
for unicode string comparison in
In-Reply-To: <1254436185.92.0.46884038882.issue7032@psf.upfronthosting.co.za>
Message-ID: <1254436185.92.0.46884038882.issue7032@psf.upfronthosting.co.za>
New submission from Michael Foord <michael at voidspace.org.uk>:
unittest.TestCase.assertEqual uses the new type equality functions for
comparing containers.
In Python 2.7 assertMultilineEqual should be the default comparison
method for unicode strings and in Python 3.2 for comparing strings.
assertMultilineEqual should only use difflib for showing differences for
strings above a certain length. (For short strings the extra output is
actually more confusing than helpful.)
----------
assignee: michael.foord
messages: 93424
nosy: michael.foord
severity: normal
status: open
title: Make assertMultilineEqual default for unicode string comparison in
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7032>
_______________________________________
From report at bugs.python.org Fri Oct 2 13:14:30 2009
From: report at bugs.python.org (lekma)
Date: Fri, 02 Oct 2009 11:14:30 +0000
Subject: [New-bugs-announce] [issue7033] C/API - Document exceptions
In-Reply-To: <1254482070.14.0.607686602716.issue7033@psf.upfronthosting.co.za>
Message-ID: <1254482070.14.0.607686602716.issue7033@psf.upfronthosting.co.za>
New submission from lekma <lekmalek at gmail.com>:
It would be nice to have an obvious/simple way to document C exceptions
(especially when using the autoexception feature from Sphinx).
Something along:
PyObject *PyErr_Create(char *name, const char *doc)
Creates and returns a new exception object.
This behaves like PyErr_Create2() with base set to NULL.
PyObject *PyErr_Create2(char *name, const char *doc, PyObject *base)
Creates and returns a new exception object.
The name argument must be the name of the new exception, a C string
of the form module.class.
If doc is non-NULL, it will be used to define the docstring for the
exception.
if base is NULL, it creates a class object derived from Exception
(accessible in C as PyExc_Exception).
for py3k the signatures would be:
PyObject *PyErr_Create(const char *name, const char *doc)
PyObject *PyErr_Create2(const char *name, const char *doc, PyObject *base)
Internally, these functions would pass a dict to PyErr_NewException with
the key '__doc__' set to doc.
If there is support for this, I can provide patches for trunk and py3k.
----------
components: Interpreter Core
messages: 93439
nosy: lekma
severity: normal
status: open
title: C/API - Document exceptions
type: feature request
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7033>
_______________________________________
From report at bugs.python.org Fri Oct 2 15:15:44 2009
From: report at bugs.python.org (Nathan Ball)
Date: Fri, 02 Oct 2009 13:15:44 +0000
Subject: [New-bugs-announce] [issue7034] While Loop Bug on a game of 21,
help!
In-Reply-To: <1254489344.22.0.289121223356.issue7034@psf.upfronthosting.co.za>
Message-ID: <1254489344.22.0.289121223356.issue7034@psf.upfronthosting.co.za>
New submission from Nathan Ball <pixelhead777 at gmail.com>:
I'm learning Python in Computer Class... and I've gone nuts trying to
figure out why my code for a 2-player game of 21 (blackjack without the
gambling connotation, I guess... not to mention my innacuracy of
dealing only one card to start (which I know isn't affecting my
glitched code)) has a glitched While loop...
my while loop has a lot within it... which is what's making it so hard
to debug...
If you can tell me why my code is so bugged, I beg of you, let me
know...
(Oh, and my classmate is saying my code is too long for it... when I
want it to look like a decent game and not a crapshoot. >.>)
----------
components: IDLE
files: 21-2Player.py
messages: 93442
nosy: PixelHead777
severity: normal
status: open
title: While Loop Bug on a game of 21, help!
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15019/21-2Player.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7034>
_______________________________________
From report at bugs.python.org Fri Oct 2 16:18:33 2009
From: report at bugs.python.org (Ole Laursen)
Date: Fri, 02 Oct 2009 14:18:33 +0000
Subject: [New-bugs-announce] [issue7035] codecs error handlers lack
documentation
In-Reply-To: <1254493113.5.0.852242878975.issue7035@psf.upfronthosting.co.za>
Message-ID: <1254493113.5.0.852242878975.issue7035@psf.upfronthosting.co.za>
New submission from Ole Laursen <olau at iola.dk>:
import codecs
help(codecs.replace_errors)
results in
replace_errors(...)
(END)
in Python 2.6. Interestingly, http://docs.python.org/library/codecs
actually says "Implements the replace error handling." Which is pretty
useless, though. :) Suggest at least copying the parenthesized notes in
the next-to-last paragraph under codecs.register to the docstrings.
I was looking for docs in the hope of finding something fancy ala
converting ? to ae, alas no cigar.
----------
assignee: georg.brandl
components: Documentation
messages: 93445
nosy: georg.brandl, olau
severity: normal
status: open
title: codecs error handlers lack documentation
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7035>
_______________________________________
From report at bugs.python.org Fri Oct 2 19:15:45 2009
From: report at bugs.python.org (Sebastian Thiel)
Date: Fri, 02 Oct 2009 17:15:45 +0000
Subject: [New-bugs-announce] [issue7036] Doc/reference/datamodel: Slots
description needs update
In-Reply-To: <1254503745.39.0.693240836231.issue7036@psf.upfronthosting.co.za>
Message-ID: <1254503745.39.0.693240836231.issue7036@psf.upfronthosting.co.za>
New submission from Sebastian Thiel <byronimo at gmail.com>:
The section starting with:
"If a class defines a slot also defined in a base class, the instance
variable
defined by the base class slot is inaccessible rendering the meaning
of the
program undefined. [...]"
would need to be revisited as it claims that a check for this issue
might be added in future. As far as I can tell, it has been added in
Python 2.4 or earlier as I get a TypeError in that case.
The attached diff is my attempt to fix this issue.
Kind Regards,
Sebastian
----------
assignee: georg.brandl
components: Documentation
files: docfix.diff
keywords: patch
messages: 93447
nosy: Byron, georg.brandl
severity: normal
status: open
title: Doc/reference/datamodel: Slots description needs update
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/file15020/docfix.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7036>
_______________________________________
From report at bugs.python.org Fri Oct 2 22:15:11 2009
From: report at bugs.python.org (Jan Hosang)
Date: Fri, 02 Oct 2009 20:15:11 +0000
Subject: [New-bugs-announce] [issue7037] test_asynchat fails on os x 10.6
In-Reply-To: <1254514511.94.0.551531757653.issue7037@psf.upfronthosting.co.za>
Message-ID: <1254514511.94.0.551531757653.issue7037@psf.upfronthosting.co.za>
New submission from Jan Hosang <jan.hosang at gmail.com>:
Loads of outputs like
test_string_producer (test.test_asynchat.TestAsynchat_WithPoll) ...
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x3ca670> (<class
'socket.error'>:[Errno 9] Bad file descriptor
[/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/asyncor
e.py|readwrite|107]
[/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/asyncor
e.py|handle_expt_event|441] [<string>|getsockopt|1]
[/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/socket.
py|_dummy|165])
Test says it passes, though. Complete output is attached.
----------
files: test_asynchat.fail
messages: 93452
nosy: chuck
severity: normal
status: open
title: test_asynchat fails on os x 10.6
versions: Python 2.6
Added file: http://bugs.python.org/file15023/test_asynchat.fail
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7037>
_______________________________________
From report at bugs.python.org Fri Oct 2 22:29:44 2009
From: report at bugs.python.org (Jan Hosang)
Date: Fri, 02 Oct 2009 20:29:44 +0000
Subject: [New-bugs-announce] [issue7038] test_curses fails on os x 10.6
In-Reply-To: <1254515384.63.0.944831963301.issue7038@psf.upfronthosting.co.za>
Message-ID: <1254515384.63.0.944831963301.issue7038@psf.upfronthosting.co.za>
New submission from Jan Hosang <jan.hosang at gmail.com>:
test_curses
test test_curses crashed -- <class '_curses.error'>: endwin() returned
ERR
Traceback (most recent call last):
File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/test/re
grtest.py", line 549, in runtest_inner
the_package = __import__(abstest, globals(), locals(), [])
File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/test/te
st_curses.py", line 279, in <module>
curses.endwin()
error: endwin() returned ERR
1 test failed:
test_curses
----------
messages: 93453
nosy: chuck
severity: normal
status: open
title: test_curses fails on os x 10.6
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7038>
_______________________________________
From report at bugs.python.org Fri Oct 2 22:33:08 2009
From: report at bugs.python.org (Jan Hosang)
Date: Fri, 02 Oct 2009 20:33:08 +0000
Subject: [New-bugs-announce] [issue7039] test_distutils fails on os x 10.6
In-Reply-To: <1254515588.38.0.10487932532.issue7039@psf.upfronthosting.co.za>
Message-ID: <1254515588.38.0.10487932532.issue7039@psf.upfronthosting.co.za>
New submission from Jan Hosang <jan.hosang at gmail.com>:
FAIL: test_get_python_inc
(distutils.tests.test_sysconfig.SysconfigTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/distuti
ls/tests/test_sysconfig.py", line 54, in test_get_python_inc
self.assert_(os.path.isdir(inc_dir), inc_dir)
AssertionError: /Users/ronald/Projects/python/r263/Include
----------------------------------------------------------------------
----------
components: Library (Lib), Tests
messages: 93454
nosy: chuck
severity: normal
status: open
title: test_distutils fails on os x 10.6
type: behavior
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7039>
_______________________________________
From report at bugs.python.org Fri Oct 2 22:38:34 2009
From: report at bugs.python.org (Jan Hosang)
Date: Fri, 02 Oct 2009 20:38:34 +0000
Subject: [New-bugs-announce] [issue7040] test_smtplib fails on os x 10.6
In-Reply-To: <1254515914.47.0.694071421893.issue7040@psf.upfronthosting.co.za>
Message-ID: <1254515914.47.0.694071421893.issue7040@psf.upfronthosting.co.za>
New submission from Jan Hosang <jan.hosang at gmail.com>:
Output like:
testAUTH_PLAIN (test.test_smtplib.SMTPSimTests) ... error: uncaptured
python exception, closing channel <test.test_smtplib.SimSMTPChannel
127.0.0.1:54223 at 0x728468> (<class 'socket.error'>:[Errno 9] Bad file
descriptor
[/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/asyncor
e.py|readwrite|107]
[/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/asyncor
e.py|handle_expt_event|441] [<string>|getsockopt|1]
[/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/socket.
py|_dummy|165])
Probably related to #7037 . Complete output attached.
----------
components: Library (Lib), Tests
files: test_smtplib.fail
messages: 93455
nosy: chuck
severity: normal
status: open
title: test_smtplib fails on os x 10.6
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15024/test_smtplib.fail
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7040>
_______________________________________
From report at bugs.python.org Fri Oct 2 23:14:22 2009
From: report at bugs.python.org (Jan Hosang)
Date: Fri, 02 Oct 2009 21:14:22 +0000
Subject: [New-bugs-announce] [issue7041] test_macostools fails on os x 10.6
In-Reply-To: <1254518062.04.0.658322870516.issue7041@psf.upfronthosting.co.za>
Message-ID: <1254518062.04.0.658322870516.issue7041@psf.upfronthosting.co.za>
New submission from Jan Hosang <jan.hosang at gmail.com>:
test_macostools
test_copy (test.test_macostools.TestMacostools) ... ERROR
test_mkalias (test.test_macostools.TestMacostools) ... ERROR
test_mkalias_relative (test.test_macostools.TestMacostools) ... ERROR
test_touched (test.test_macostools.TestMacostools) ... ok
======================================================================
ERROR: test_copy (test.test_macostools.TestMacostools)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/jan/src/python26/Lib/test/test_macostools.py", line 65,
in test_copy
macostools.copy(test_support.TESTFN, TESTFN2)
File "/Users/jan/src/python26/Lib/plat-mac/macostools.py", line 114,
in copy
srcfss = File.FSSpec(src)
AttributeError: 'module' object has no attribute 'FSSpec'
======================================================================
ERROR: test_mkalias (test.test_macostools.TestMacostools)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/jan/src/python26/Lib/test/test_macostools.py", line 73,
in test_mkalias
macostools.mkalias(test_support.TESTFN, TESTFN2)
File "/Users/jan/src/python26/Lib/plat-mac/macostools.py", line 46, in
mkalias
dstfsr, dstfss = Res.FSCreateResourceFile(dstdirfsr,
unicode(dstname),
AttributeError: 'module' object has no attribute 'FSCreateResourceFile'
======================================================================
ERROR: test_mkalias_relative (test.test_macostools.TestMacostools)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/jan/src/python26/Lib/test/test_macostools.py", line 88,
in test_mkalias_relative
macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix)
File "/Users/jan/src/python26/Lib/plat-mac/macostools.py", line 46, in
mkalias
dstfsr, dstfss = Res.FSCreateResourceFile(dstdirfsr,
unicode(dstname),
AttributeError: 'module' object has no attribute 'FSCreateResourceFile'
----------------------------------------------------------------------
Ran 4 tests in 0.006s
FAILED (errors=3)
test test_macostools failed -- errors occurred; run in verbose mode for
details
1 test failed:
test_macostools
----------
components: Library (Lib), Tests
messages: 93456
nosy: chuck
severity: normal
status: open
title: test_macostools fails on os x 10.6
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7041>
_______________________________________
From report at bugs.python.org Fri Oct 2 23:18:30 2009
From: report at bugs.python.org (Jan Hosang)
Date: Fri, 02 Oct 2009 21:18:30 +0000
Subject: [New-bugs-announce] [issue7042] test_signal fails on os x 10.6
In-Reply-To: <1254518310.34.0.718990196712.issue7042@psf.upfronthosting.co.za>
Message-ID: <1254518310.34.0.718990196712.issue7042@psf.upfronthosting.co.za>
New submission from Jan Hosang <jan.hosang at gmail.com>:
======================================================================
FAIL: test_itimer_virtual (test.test_signal.ItimerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/jan/src/python26/Lib/test/test_signal.py", line 368, in
test_itimer_virtual
self.assertEquals(signal.getitimer(self.itimer), (0.0, 0.0))
AssertionError: (0.17993600000000001, 0.20000000000000001) != (0.0, 0.0)
----------------------------------------------------------------------
Complete output attached.
----------
components: Library (Lib), Tests
files: test_signal.fail
messages: 93457
nosy: chuck
severity: normal
status: open
title: test_signal fails on os x 10.6
versions: Python 2.6
Added file: http://bugs.python.org/file15025/test_signal.fail
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7042>
_______________________________________
From report at bugs.python.org Sat Oct 3 02:29:21 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sat, 03 Oct 2009 00:29:21 +0000
Subject: [New-bugs-announce] [issue7043] test_urllib: constructLocalFileUrl
returns invalid URLs on Windows
In-Reply-To: <1254529761.1.0.362605990339.issue7043@psf.upfronthosting.co.za>
Message-ID: <1254529761.1.0.362605990339.issue7043@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
This error happens on Windows. The culprit seems to be the
`constructLocalFileUrl` method that is constructing invalid URLs.
Traceback (most recent call last):
File "C:\Python26\lib\test\test_urllib.py", line 241, in test_copy
test_support.TESTFN), second_temp)
File "C:\Python26\lib\urllib.py", line 94, in urlretrieve
return _urlopener.retrieve(url, filename, reporthook, data)
File "C:\Python26\lib\urllib.py", line 238, in retrieve
fp = self.open(url, data)
File "C:\Python26\lib\urllib.py", line 206, in open
return getattr(self, name)(url)
File "C:\Python26\lib\urllib.py", line 468, in open_file
return self.open_local_file(url)
File "C:\Python26\lib\urllib.py", line 482, in open_local_file
raise IOError(e.errno, e.strerror, e.filename)
IOError: [Errno 22] The filename, directory name, or volume label syntax
is incorrect: '\\\\\\C|\\DOCUME~1\\apy\\LOCALS~1\\Temp\\autotest\\@test'
----------
components: Tests
messages: 93463
nosy: srid
severity: normal
status: open
title: test_urllib: constructLocalFileUrl returns invalid URLs on Windows
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7043>
_______________________________________
From report at bugs.python.org Sat Oct 3 05:30:55 2009
From: report at bugs.python.org (jweber)
Date: Sat, 03 Oct 2009 03:30:55 +0000
Subject: [New-bugs-announce] [issue7044] urllib.urlopen crashes when used on
Mac OS 10.6.1 through a proxy
In-Reply-To: <1254540655.1.0.243210284724.issue7044@psf.upfronthosting.co.za>
Message-ID: <1254540655.1.0.243210284724.issue7044@psf.upfronthosting.co.za>
New submission from jweber <jacob at jacobweber.com>:
In Python 2.6.3 on Mac OS 10.6.1, there is a bug in
lib/python2.6/urllib.py, line 1367. The variable hostIP is used before
it's defined. You can fix it by adding "hostIP = None" at around line
1355. I got the following exception when calling urllib.urlopen using a
proxy:
File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib.
py", line 87, in urlopen
return opener.open(url)
File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib.
py", line 206, in open
return getattr(self, name)(url)
File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib.
py", line 317, in open_http
if proxy_bypass(realhost):
File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib.
py", line 1398, in proxy_bypass
return proxy_bypass_macosx_sysconf(host)
File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib.
py", line 1367, in proxy_bypass_macosx_sysconf
if hostIP is None:
UnboundLocalError: local variable 'hostIP' referenced before assignment
----------
assignee: ronaldoussoren
components: Macintosh
messages: 93473
nosy: jweber, ronaldoussoren
severity: normal
status: open
title: urllib.urlopen crashes when used on Mac OS 10.6.1 through a proxy
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7044>
_______________________________________
From report at bugs.python.org Sat Oct 3 05:46:53 2009
From: report at bugs.python.org (Arc Riley)
Date: Sat, 03 Oct 2009 03:46:53 +0000
Subject: [New-bugs-announce] [issue7045] utf-8 encoding error
In-Reply-To: <1254541613.35.0.521074293953.issue7045@psf.upfronthosting.co.za>
Message-ID: <1254541613.35.0.521074293953.issue7045@psf.upfronthosting.co.za>
New submission from Arc Riley <arcriley at gmail.com>:
The following is a minimal example which does not work under Python
3.1.1 but functions as expected on Pyhton 2.6 and 3.0.
Python 3.1.1 believes the single UTF-8 glyph is two entirely different
(and illegal) unicode characters:
Traceback (most recent call last):
File "t.py", line 2, in <module>
print('?')
UnicodeEncodeError: 'utf-8' codec can't encode character '\ud801' in
position 0: surrogates not allowed
Test system is Ubuntu 9.10-beta 32-bit
----------
components: Interpreter Core
files: t.py
messages: 93475
nosy: ArcRiley
severity: normal
status: open
title: utf-8 encoding error
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file15028/t.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7045>
_______________________________________
From report at bugs.python.org Sat Oct 3 15:30:56 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 03 Oct 2009 13:30:56 +0000
Subject: [New-bugs-announce] [issue7046] decimal.py: use DivisionImpossible
and DivisionUndefined
In-Reply-To: <1254576656.46.0.369353081628.issue7046@psf.upfronthosting.co.za>
Message-ID: <1254576656.46.0.369353081628.issue7046@psf.upfronthosting.co.za>
New submission from Stefan Krah <stefan-usenet at bytereef.org>:
In many cases, decimal.py sets InvalidOperation instead of
DivisionImpossible or DivisionUndefined.
Mark, could I persuade you to isolate these cases by running a modified
deccheck2.py from mpdecimal (See attachment), which does not suppress
differences in the division functions?
----------
files: div-deccheck2.py
messages: 93490
nosy: mark.dickinson, skrah
severity: normal
status: open
title: decimal.py: use DivisionImpossible and DivisionUndefined
Added file: http://bugs.python.org/file15029/div-deccheck2.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7046>
_______________________________________
From report at bugs.python.org Sat Oct 3 15:46:49 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 03 Oct 2009 13:46:49 +0000
Subject: [New-bugs-announce] [issue7047] decimal.py: NaN payload conversion
In-Reply-To: <1254577609.23.0.3782240527.issue7047@psf.upfronthosting.co.za>
Message-ID: <1254577609.23.0.3782240527.issue7047@psf.upfronthosting.co.za>
New submission from Stefan Krah <stefan-usenet at bytereef.org>:
decimal.py sets InvalidOperation if the payload of a NaN is too large:
>>> c = getcontext()
>>> c.prec = 4
>>> c.create_decimal("NaN12345")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.7/decimal.py", line 3797, in create_decimal
"diagnostic info too long in NaN")
File "/usr/lib/python2.7/decimal.py", line 3733, in _raise_error
raise error(explanation)
decimal.InvalidOperation: diagnostic info too long in NaN
decNumber (and fastdec) set ConversionSyntax.
----------
messages: 93491
nosy: skrah
severity: normal
status: open
title: decimal.py: NaN payload conversion
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7047>
_______________________________________
From report at bugs.python.org Sat Oct 3 15:53:17 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 03 Oct 2009 13:53:17 +0000
Subject: [New-bugs-announce] [issue7048] decimal.py: logb: round the result
if it is greater than prec
In-Reply-To: <1254577997.92.0.263128195563.issue7048@psf.upfronthosting.co.za>
Message-ID: <1254577997.92.0.263128195563.issue7048@psf.upfronthosting.co.za>
New submission from Stefan Krah <stefan-usenet at bytereef.org>:
>>> from decimal import *
>>> c = getcontext()
>>> c.prec = 2
>>> c.logb(Decimal("1E123456"))
Decimal('123456')
>>>
This result agrees with the result of decNumber, but the spec says:
"All results are exact unless an integer result does not fit in the
available precision."
My interpretation is that the result should be 1.2E+5.
----------
messages: 93492
nosy: mark.dickinson, skrah
severity: normal
status: open
title: decimal.py: logb: round the result if it is greater than prec
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7048>
_______________________________________
From report at bugs.python.org Sat Oct 3 15:59:24 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 03 Oct 2009 13:59:24 +0000
Subject: [New-bugs-announce] [issue7049] decimal.py: NaN result in pow(x, y,
z) with prec 1
In-Reply-To: <1254578364.09.0.56728742883.issue7049@psf.upfronthosting.co.za>
Message-ID: <1254578364.09.0.56728742883.issue7049@psf.upfronthosting.co.za>
New submission from Stefan Krah <stefan-usenet at bytereef.org>:
If precision 1 is aupported, the following results should not be NaN:
Python 2.7a0 (trunk:74738, Sep 10 2009, 11:50:08)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import *
>>> setcontext(Context(prec=1, rounding=ROUND_UP,
Emin=-999999999999999999, Emax=999999999999999999, capitals=1, flags=[],
traps=[]))
>>> pow(Decimal(0), Decimal(3), Decimal(70))
Decimal('NaN')
>>> pow(Decimal(3), Decimal(0), Decimal(70))
Decimal('NaN')
>>>
----------
messages: 93493
nosy: skrah
severity: normal
status: open
title: decimal.py: NaN result in pow(x, y, z) with prec 1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7049>
_______________________________________
From report at bugs.python.org Sat Oct 3 16:54:34 2009
From: report at bugs.python.org (Mark Fitzgerald)
Date: Sat, 03 Oct 2009 14:54:34 +0000
Subject: [New-bugs-announce] [issue7050] (x,y) += (1,2) crashes IDLE
In-Reply-To: <1254581674.88.0.706780841215.issue7050@psf.upfronthosting.co.za>
Message-ID: <1254581674.88.0.706780841215.issue7050@psf.upfronthosting.co.za>
New submission from Mark Fitzgerald <mark.fitzgerald2 at sympatico.ca>:
Start up IDLE. Type "(x,y) += (1,2)" (without the double-quotes), then
press Enter. IDLE unexpectedly terminates without message, pop-up, or
warning. Admittedly, this line of code is likely not legal, but
shouldn't it just raise SyntaxError?
----------
components: IDLE
messages: 93495
nosy: mfitz
severity: normal
status: open
title: (x,y) += (1,2) crashes IDLE
type: crash
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7050>
_______________________________________
From report at bugs.python.org Sat Oct 3 20:59:15 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 03 Oct 2009 18:59:15 +0000
Subject: [New-bugs-announce] [issue7051] 'g'/'G' format docs need a little
more explanation
In-Reply-To: <1254596355.98.0.43740035661.issue7051@psf.upfronthosting.co.za>
Message-ID: <1254596355.98.0.43740035661.issue7051@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <benjamin at python.org>:
The docs for 'g' say "This prints the number as a fixed-point number,
unless the number is too large." Could you please explain what exactly
constitutes "too large"?
----------
assignee: eric.smith
messages: 93504
nosy: benjamin.peterson, eric.smith
severity: normal
status: open
title: 'g'/'G' format docs need a little more explanation
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7051>
_______________________________________
From report at bugs.python.org Sun Oct 4 09:20:49 2009
From: report at bugs.python.org (Valery)
Date: Sun, 04 Oct 2009 07:20:49 +0000
Subject: [New-bugs-announce] [issue7052] "from logging import *" causes an
error under Ubuntu Karmic
In-Reply-To: <1254640849.21.0.615783238878.issue7052@psf.upfronthosting.co.za>
Message-ID: <1254640849.21.0.615783238878.issue7052@psf.upfronthosting.co.za>
New submission from Valery <khamenya at gmail.com>:
Hi all
(I never filed a bug, so, I am not sure that all fields are OK)
Anyway, here is the self explaining issue:
$ python
Python 2.6.3 (r263:75183, Oct 3 2009, 11:20:50)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from logging import *
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'NullHandler'
$ uname -a
Linux vaktop 2.6.31-11-generic #38-Ubuntu SMP Fri Oct 2 11:55:55 UTC
2009 i686 GNU/Linux
this issue blocks me badly :(
regards
--
Valery
----------
components: Library (Lib)
messages: 93520
nosy: vak
severity: normal
status: open
title: "from logging import *" causes an error under Ubuntu Karmic
type: resource usage
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7052>
_______________________________________
From report at bugs.python.org Sun Oct 4 09:56:01 2009
From: report at bugs.python.org (Mattelaer)
Date: Sun, 04 Oct 2009 07:56:01 +0000
Subject: [New-bugs-announce] [issue7053] wrong overload of slot wrapper
In-Reply-To: <1254642961.53.0.52904342444.issue7053@psf.upfronthosting.co.za>
Message-ID: <1254642961.53.0.52904342444.issue7053@psf.upfronthosting.co.za>
New submission from Mattelaer <olivier.mattelaer at uclouvain.be>:
wrong redirection of slot wrapper:
class.__iter__=list.__iter__
doesn't work. (the __iter__ still refer to the one define in class)
The file in attachment shows an example of this problem
----------
components: None
files: test.py
messages: 93522
nosy: omatt
severity: normal
status: open
title: wrong overload of slot wrapper
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15034/test.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7053>
_______________________________________
From report at bugs.python.org Sun Oct 4 12:31:50 2009
From: report at bugs.python.org (Mark Schlieker)
Date: Sun, 04 Oct 2009 10:31:50 +0000
Subject: [New-bugs-announce] [issue7054] Python25.chm seems to be broken
In-Reply-To: <1254652310.61.0.423717253286.issue7054@psf.upfronthosting.co.za>
Message-ID: <1254652310.61.0.423717253286.issue7054@psf.upfronthosting.co.za>
New submission from Mark Schlieker <Sternenfaenger77 at googlemail.com>:
CHM file for Python 2.5 documentation does not work when being used
without Python installation.
My OS is: Microsoft Windows XP (sp2)
Steps on how to reproduce:
prerequisite:
1) No python has been installed on machine (not sure if necessary)
steps:
1) Download Python25.chm from
http://www.python.org/download/releases/2.5.2/ (md5 digest:
4c2f7e124287525a93849b0b53893bf0)
2) Open file Python25.chm by double clicking on it using file explorer.
noticed behaviour ==>
Help window opens with navigation pane (on the left) showing index but
on the right window pane there is only a text saying that navigation to
website has been cancelled. When clicking on any item in the navigation
pane still no other text gets displayed on the right window pane else
than "Navigation to website has been cancelled".
expected behaviour ==>
Help window shows documentation in the right hand side window pane.
----------
assignee: georg.brandl
components: Documentation
messages: 93530
nosy: Mark77, georg.brandl
severity: normal
status: open
title: Python25.chm seems to be broken
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7054>
_______________________________________
From report at bugs.python.org Sun Oct 4 18:45:11 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Oct 2009 16:45:11 +0000
Subject: [New-bugs-announce] [issue7055] Automatic test___all__
In-Reply-To: <1254674711.55.0.0201125202082.issue7055@psf.upfronthosting.co.za>
Message-ID: <1254674711.55.0.0201125202082.issue7055@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
This patch replaces the explicit list of modules in test___all__ with an
automatic detection of modules having a __all__ attribute, so that we
don't forget any. It doesn't really appear to slow things down;
test___all__ only takes one second here.
----------
components: Library (Lib), Tests
messages: 93548
nosy: georg.brandl, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Automatic test___all__
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/issue7055>
_______________________________________
From report at bugs.python.org Sun Oct 4 21:41:50 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Oct 2009 19:41:50 +0000
Subject: [New-bugs-announce] [issue7056] regrtest runtest_inner calls
findtestdir unnecessarily
In-Reply-To: <1254685310.19.0.164822003436.issue7056@psf.upfronthosting.co.za>
Message-ID: <1254685310.19.0.164822003436.issue7056@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
Running regrtest over an installed, read-only Lib produces several test
failures, and regrtest crashes. In investigating these, which I will
deal with in other issues, I found that the regrtest runtest_inner
method takes a 'testdir' argument, and if it is none calls
'findtestdir'. findtestdir uses __file__ or arg[0] to compute the
directory in which regrtest is located, something that does not change
during the lifetime of a given regrtest run, so at best these repeated
calls are redundant. At worst, it triggered the regrtest abort because
the value of arg[0] was changed by one of the tests.
As it turns out, the testdir argument is never actually referenced in
the body of runtest_inner. runtest_inner in turn is called only by
runtest, which uses _its_ testdir argument only in the call to
runtest_inner.
Attached are two patches. The first just removes testdir from
runtest_inner, the second removes it from runtest as well. On my Gentoo
linux box the full (-uall) test suite passes with either patch applied.
(With the exception of test_ttk_guionly, which failed before the patch
at as well.)
----------
components: Tests
files: remove_testdir_from_runtest_inner.patch
keywords: patch
messages: 93557
nosy: r.david.murray
priority: low
severity: normal
stage: patch review
status: open
title: regrtest runtest_inner calls findtestdir unnecessarily
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15041/remove_testdir_from_runtest_inner.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7056>
_______________________________________
From report at bugs.python.org Mon Oct 5 00:59:28 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 04 Oct 2009 22:59:28 +0000
Subject: [New-bugs-announce] [issue7057] tkinter doc: more 3.x updates
In-Reply-To: <1254697168.63.0.205098696566.issue7057@psf.upfronthosting.co.za>
Message-ID: <1254697168.63.0.205098696566.issue7057@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
The transition from Tkinter/tkinter to tkinter/_tkinker in 3.x docs is
incomplete.
1. There are several places not in titles or beginning of sentences
where Tkinter (roman type) needs to be replaced with tkinter (fixed
type, as elsewhere).
2. "24.1.1. Tkinter Modules
Most of the time, the tkinter is all" <<delete 'the' before tkinter>>
24.1.6.4. Coupling Widget Variables
"from a class called Variable, defined in the tkinter." ditto
3. 24.1.5. How Tk and Tkinter are Related
"tkinter (C)
These commands and their arguments will be passed to a C function in the
tkinter - note the lowercase - extension module"
Change 'tkinter' to '_tkinter' and 'lowercase' to 'underscore'.
"Xlib (C)
the Xlib library to draw graphics on the screen. "
Is this still true? Or does Tk now use native libraries?
Not 3.x specific.
10. "Specifically, the man pages in the mann directory are most useful."
Is 'mann' literally correct? a typo? or meant to mean 'man#', where # is
a digit? If the last, either man# or mann with the last 'n' a different
font would be clearer to me.
This is, of course, *nix specific.
11. "Credits:
Tkinter was written by Steen Lumholt and Guido van Rossum.
Tk was written by John Ousterhout while at Berkeley. "
Except for the first two lines, the entries are in historical order, so
I would reverse the first two.
12. 24.1.6.6. Tk Option Data Types
"To specify an X bitmap filename, give the full path to the file,
preceded with an @, as in "@/usr/contrib/bitmap/gumby.bit"."
*nix only? what about windows .bmp file?
13. (ttk section) 24.2.3.1. Standard Options
"0, 1 or an empty is return." => "0, 1 or an empty string is returned."
PS. I like the colors of the option-description tables.
----------
assignee: georg.brandl
components: Documentation
messages: 93564
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: tkinter doc: more 3.x updates
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7057>
_______________________________________
From report at bugs.python.org Mon Oct 5 01:08:33 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Oct 2009 23:08:33 +0000
Subject: [New-bugs-announce] [issue7058] Add some test execution environment
protection to regrtest
In-Reply-To: <1254697713.91.0.536595090046.issue7058@psf.upfronthosting.co.za>
Message-ID: <1254697713.91.0.536595090046.issue7058@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
One of the failures when regrtest is run with a read-only Lib results
from test_runpy modifying sys.argv. Antoine also found cases where
tests modified os.environ in issue 7055. It seems useful to have
regrtest fix these kinds of environment corruptions when it can, but to
also issue warnings so that the tests in questions can be fixed. In
some cases the warnings might also reveal bugs in the code being tested,
if the code being tested does a modification it should not be doing.
Attached is a patch that adds save/restore for os.environ and sys.argv,
with warning messages.
----------
components: Tests
files: regrtest_guards.patch
keywords: patch
messages: 93566
nosy: r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Add some test execution environment protection to regrtest
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15044/regrtest_guards.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7058>
_______________________________________
From report at bugs.python.org Mon Oct 5 02:52:01 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 05 Oct 2009 00:52:01 +0000
Subject: [New-bugs-announce] [issue7059] 'checking getaddrinfo bug' doesn't
output the result during ./configure
In-Reply-To: <1254703921.37.0.174838855875.issue7059@psf.upfronthosting.co.za>
Message-ID: <1254703921.37.0.174838855875.issue7059@psf.upfronthosting.co.za>
New submission from Ezio Melotti <ezio.melotti at gmail.com>:
This is what I see while running ./configure on both trunk and py3k, on
Linux:
checking for major... yes
checking for getaddrinfo... yes
checking getaddrinfo bug... checking for getnameinfo... yes
checking whether time.h and sys/time.h may both be included... yes
the yes/no after 'checking getaddrinfo bug...' is missing.
FWIW that bit of code is at the line 20225, but I couldn't figure out
how to fix it.
----------
components: Installation
messages: 93568
nosy: ezio.melotti
priority: low
severity: normal
status: open
title: 'checking getaddrinfo bug' doesn't output the result during ./configure
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/issue7059>
_______________________________________
From report at bugs.python.org Mon Oct 5 03:40:57 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Oct 2009 01:40:57 +0000
Subject: [New-bugs-announce] [issue7060] test_multiprocessing dictionary
changed size errors and hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
test_multiprocessing is producing tracebacks and hanging on py3k trunk.
I think this started happening fairly recently, as it seemed to work in
one not-too-old checkout until I did an svn up and then it started
failing. 3.1 seems fine. I've attached the tracebacks, including the
tracebacks I get when I ctrl-C to break the hang. My system is Gentoo
Linux.
----------
assignee: jnoller
files: test_multiprocessing.log
messages: 93570
nosy: jnoller, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: test_multiprocessing dictionary changed size errors and hang
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file15045/test_multiprocessing.log
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7060>
_______________________________________
From report at bugs.python.org Mon Oct 5 06:34:34 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 05 Oct 2009 04:34:34 +0000
Subject: [New-bugs-announce] [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
Reading through 24.5 on the turtle module, I have a number of comments
aimed at improvements. Some are straightforward fixes which any doc
maintainer could enter. Others are questions about meaning that I
presume the current maintainer, gregor lingl may have to answer. But he
is not an option of the Assigned To: pulldown list. These are introduced
by '??'. Quotes are from 3.1.1 docs.
24.5.1. Introduction
"version of python installed with Tk support.": cap 'python' to 'Python'
'which draws on ?the? Screen - instance': delete '-'
"To use multiple turtles an a screen ": an > on
"24.5.2. Overview over available Turtle and Screen methods":
'over' > 'of'
24.5.3.1. Turtle motion
?? distance units? pixel or world, depending on mode?
presume yes, but should say something here.
24.5.3.6. Using events
"turtle.onclick(fun, btn=1, add=None)
It seems that 'add=False' would be same as 'add=None' and more
consistent with below.
"add ? True or False ? if True, a new binding will be added, otherwise
it will replace a former binding "
?? I do not understand what this means. Normal Python binding
(assignment) adds a new binding, replacing an old one if there was one.
How is turtle different? (And why should it be?)
"turtle.onrelease(fun, btn=1, add=None) "
"turtle.onrelease(fun, btn=1, add=None) "
same pair of comments
24.5.3.8. Excursus about the use of compound shapes
'excursus' is so obscure that I have never seen/heard it before and had
to look it up to verify that it was an English word. The definitions I
found do not quite fit the usage. 'Compound shapes' is quite sufficient
for the section title.
If change the title, there is also the reference to this section in
24.5.5. The public classes of the module turtle to be changed.
24.5.4. Methods of TurtleScreen/Screen and corresponding functions
"Most of the examples in this section refer to a TurtleScreen instance
called screen."
However,
24.5.4.1. Window control
turtle.bgcolor(*args) "
and so on throughout the section.
?? I presume that should be
"screen.bgcolor(*args)" and so on throughout the section.
.clear(), .reset()
"Note This TurtleScreen method is available as a global function only
under the name clearscreen. The global function clear is another one
derived from the Turtle method clear."
?? I presume 'another' means 'a different', but then I do not understand
the difference.
"turtle.delay(delay=None)
Parameter: delay ? positive integer
Set or return the drawing delay in milliseconds. (This is approximately
the time interval between two consecutive canvas updates.) The longer
the drawing delay, the slower the animation."
?? Unclear how this interacts with turtle.speed
"turtle.tracer(n=None, delay=None)
Parameters: n ? nonnegative integer
delay ? nonnegative integer
Turn turtle animation on/off and set delay for update drawings. If n is
given, only each n-th regular screen update is really performed. (Can be
used to accelerate the drawing of complex graphics.) Second argument
sets delay value (see delay())."
?? does .tracer() (no args) turn animation off?
"Remark: in order to be able to register key-events, TurtleScreen must
have the focus. (See method listen().
>>> def f():
... fd(50)
... lt(60)
...
>>> screen.onkey(f, "Up")
>>> screen.listen()"
>From the Remark, I expected the two calls to be in the opposite order.
Ditto for .onkeypress()
24.5.4.4. Input methods
"turtle.numinput(title, prompt, default=None, minval=None, maxval=None)
Parameters: title ? string
prompt ? string
default ? number (optional)
prompt ? number (optional)
prompt ? number (optional) "
Last two param names are 'minval' and 'maxval', not 'prompt'.
24.5.4.5. Settings and special methods
?? .mode: 'world' like standard or logo w/r/t angles?
"24.5.4.6. Methods specific to Screen, not inherited from TurtleScreen
turtle.exitonclick()
Bind bye() method to mouse clicks on the Screen."
"If the value ?using_IDLE? in the configuration dictionary is False
(default value), also enter mainloop. Remark: If IDLE with the -n switch
(no subprocess) is used, this value should be set to True in turtle.cfg.
In this case IDLE?s own mainloop is active also for the client script."
>From Windows shortcut, I cannot tell how IDLE is started, but seems to
work. Anything need to be said re IDLE/turtle on windows?
My guess is that IDLE is running normally (without -n), so that there is
a subprocess, so that 'using_IDLE' is False even though I am using it,
just not in the same process. Correct?
24.5.8. Changes since Python 2.6
Sections about 2.x changes should not be in 3.x docs.
----------
assignee: georg.brandl
components: Documentation
messages: 93574
nosy: georg.brandl, gregorlingl, tjreedy
severity: normal
status: open
title: Improve 24.5. turtle doc
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________
From report at bugs.python.org Mon Oct 5 08:11:28 2009
From: report at bugs.python.org (Roman Sokolov)
Date: Mon, 05 Oct 2009 06:11:28 +0000
Subject: [New-bugs-announce] [issue7062] No docs for module 'IN'
In-Reply-To: <1254723088.53.0.157607422381.issue7062@psf.upfronthosting.co.za>
Message-ID: <1254723088.53.0.157607422381.issue7062@psf.upfronthosting.co.za>
New submission from Roman Sokolov <sokolov.r.v at gmail.com>:
Python 2.6.3 (r263:75183, Oct 2 2009, 11:22:08)
>>> import IN
>>> help(IN)
-- contain following lines:
"MODULE DOCS
http://docs.python.org/library/IN"
, but server returns 404 error:
"The requested URL /library/IN was not found on this server."
and no docs found in source distribution:
$ cat ~/terrarium/sources/py26st/Doc/library/IN.rst
cat: /home/roma/terrarium/sources/py26st/Doc/library/IN.rst: No such
file or directory
----------
assignee: georg.brandl
components: Documentation
messages: 93576
nosy: RSokolov, georg.brandl
severity: normal
status: open
title: No docs for module 'IN'
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7062>
_______________________________________
From report at bugs.python.org Mon Oct 5 10:12:29 2009
From: report at bugs.python.org (Jan Hosang)
Date: Mon, 05 Oct 2009 08:12:29 +0000
Subject: [New-bugs-announce] [issue7063] Memory errors in array.array
In-Reply-To: <1254730349.27.0.71088310024.issue7063@psf.upfronthosting.co.za>
Message-ID: <1254730349.27.0.71088310024.issue7063@psf.upfronthosting.co.za>
New submission from Jan Hosang <jan.hosang at gmail.com>:
While I was backporting the new buffer API to 2.7 I noticed some issues
in array_ass_slice() in Modules/arraymodule.c in the python 3k branch.
1) Manual memory reallocation had been replaced by calls to
array_resize. But I think when PyMem_RESIZE is called the pointer to the
memory might change. So this now happens in array_resize, and the
array->ob_item pointer changes but not it's local copy (item) in
array_ass_slice().
2) The function moves too much memory if the array size is increased:
(Py_SIZE(a)-d-ihigh) items should be moved, because Py_SIZE(a) was
already modified by array_resize, but the function moves (Py_SIZE(a)-
ihigh) items.
While 1) might go unnoticed, 2) definitely broke slice tests in a
"segmentation fault"-way (in debug mode forbidden bits show the error).
I tried to write a test, but I don't know how to trigger
array_ass_slice() with a write access, as it is not in array_as_sequence
anymore (like in 2.7). How is slicing handled now?
----------
components: Library (Lib), Tests
messages: 93581
nosy: chuck
severity: normal
status: open
title: Memory errors in array.array
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7063>
_______________________________________
From report at bugs.python.org Mon Oct 5 13:28:35 2009
From: report at bugs.python.org (Ned Deily)
Date: Mon, 05 Oct 2009 11:28:35 +0000
Subject: [New-bugs-announce] [issue7064] Python 2.6.3 / setuptools 0.6c9:
extension module builds fail with KeyError
In-Reply-To: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>
Message-ID: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
Due to a change in distutils released with Python 2.6.3, packages that
use setuptools (version 0.6c9, as of this writing), or the easy_install
command, to build C extension modules fail with a cryptic message ending
with:
... .egg/setuptools/command/build_ext.py", line 85, in get_ext_filename
ext = self.ext_map[fullname] KeyError: <module_name>
Among the packages known to be affected include lxml, zope-interface,
jinja2, and, hence, packages dependent on these packages (e.g. sphinx,
twisted, etc.).
The issue is described in greater detail in the Distribute project
tracker:
http://bitbucket.org/tarek/distribute/issue/41/keyerror-_speedups
The solution there was to modify Distribute, a fork of setuptools, to
accommodate the change in distutils.
An issue has been opened on the setuptools tracker for this problem:
http://bugs.python.org/setuptools/issue85
A discussion on the distutils-sig mailing list starts here:
http://mail.python.org/pipermail/distutils-sig/2009-October/013534.html
The distutils change forces affected users to either:
(1) migrate from setuptools to Distribute, which can generally done by
simply running:
easy_install distribute
(2) avoid upgrading to 2.6.3 until a fix for setuptools is released
(or patch setuptools themselves)
(3) patch or downgrade distutils to restore the previous behavior
The primary purpose of this issue is to serve as a placeholder for users
searching the Python issue tracker for this failure symptom.
----------
assignee: tarek
components: Distutils
messages: 93591
nosy: barry, ned.deily, tarek
severity: normal
status: open
title: Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7064>
_______________________________________
From report at bugs.python.org Mon Oct 5 14:53:23 2009
From: report at bugs.python.org (egreen)
Date: Mon, 05 Oct 2009 12:53:23 +0000
Subject: [New-bugs-announce] [issue7065] bytes.maketrans segfaults
In-Reply-To: <1254747203.73.0.94763018002.issue7065@psf.upfronthosting.co.za>
Message-ID: <1254747203.73.0.94763018002.issue7065@psf.upfronthosting.co.za>
New submission from egreen <egreen at operamail.com>:
The new maketrans static method in Python 3.1 segfaults when using byte
values > 127.
Reproduce: bytes.maketrans(bytes(range(256)), b'X' * 256)
Cause: _Py_bytes_maketrans in Objects/bytes_methods.c uses signed int as
array index.
Fix attached. Also adds test.
----------
components: Interpreter Core
files: maketrans_segfault.patch
keywords: patch
messages: 93599
nosy: egreen
severity: normal
status: open
title: bytes.maketrans segfaults
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15049/maketrans_segfault.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7065>
_______________________________________
From report at bugs.python.org Mon Oct 5 21:40:27 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 05 Oct 2009 19:40:27 +0000
Subject: [New-bugs-announce] [issue7066] archive_util.make_archive doesn't
restore the cwd if an error is raised
In-Reply-To: <1254771627.9.0.528035502085.issue7066@psf.upfronthosting.co.za>
Message-ID: <1254771627.9.0.528035502085.issue7066@psf.upfronthosting.co.za>
New submission from Ezio Melotti <ezio.melotti at gmail.com>:
archive_util.make_archive() changes the value of the cwd, but if an
error is raised in "filename = func(base_name, base_dir, **kwargs)", the
cwd is not restored. This may happen if zlib is not available and causes
other ~60 tests to fail while running regrtest.py.
This trivial fix solve the problem here:
- filename = func(base_name, base_dir, **kwargs)
- if root_dir is not None:
- log.debug("changing back to '%s'", save_cwd)
- os.chdir(save_cwd)
+ try:
+ filename = func(base_name, base_dir, **kwargs)
+ finally:
+ if root_dir is not None:
+ log.debug("changing back to '%s'", save_cwd)
+ os.chdir(save_cwd)
The new test_make_archive_owner_group() test added in r75192 also needs
a @unittest.skipUnless(zlib, "Requires zlib"), otherwise dist_distutils
fails.
Since half of this test doesn't require zlib (i.e. when 'tar' is used)
it might be a good idea to split the test in two, in order to test the
'tar' archives even if 'zlib' is not available.
(Thanks to R. David Murray - he spot the right place where the cwd is
changed and not restored.)
----------
assignee: tarek
components: Distutils
messages: 93618
nosy: ezio.melotti, r.david.murray, tarek
priority: normal
severity: normal
status: open
title: archive_util.make_archive doesn't restore the cwd if an error is raised
type: behavior
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7066>
_______________________________________
From report at bugs.python.org Mon Oct 5 22:52:10 2009
From: report at bugs.python.org (Steven R. Loomis)
Date: Mon, 05 Oct 2009 20:52:10 +0000
Subject: [New-bugs-announce] [issue7067] Suggest better documentation of 2
versus 3 on 3.1.1 site.
In-Reply-To: <1254775930.89.0.646782257739.issue7067@psf.upfronthosting.co.za>
Message-ID: <1254775930.89.0.646782257739.issue7067@psf.upfronthosting.co.za>
New submission from Steven R. Loomis <srl at monkey.sbay.org>:
It would be nice if http://www.python.org/download/releases/3.1.1/ had
the '3 vs 2' explanation made more prominent, just as it was in the 3.0.
Maybe I've been living under a rock, but I didn't realize that 3 was
such a change. Maybe the words 'backwards-incompatible' could be a link
to http://docs.python.org/dev/3.0/whatsnew/3.0.html which explained
things quite nicely. You could also add something on the home page,
with a link to that same page under the title "3 versus 2?"
Please consider the scenario where someone "needs python installed" to
run an existing program, and they go to http://www.python.org - wanting
to download the latest version would be the logical thing to do. You
could use this opportunity to suggest running the 2to3 converter and so
upgrading their existing program. Again, the 3.1.1 release page doesn't
have the link to 2to3, but 3.0 does.
Thank you for your consideration.
----------
assignee: georg.brandl
components: Documentation
messages: 93620
nosy: georg.brandl, srl
severity: normal
status: open
title: Suggest better documentation of 2 versus 3 on 3.1.1 site.
type: feature request
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7067>
_______________________________________
From report at bugs.python.org Tue Oct 6 05:12:05 2009
From: report at bugs.python.org (Shun-ichi Goto)
Date: Tue, 06 Oct 2009 03:12:05 +0000
Subject: [New-bugs-announce] [issue7068] 2.6.3 does not use specified
compiler
In-Reply-To: <1254798725.88.0.648175309715.issue7068@psf.upfronthosting.co.za>
Message-ID: <1254798725.88.0.648175309715.issue7068@psf.upfronthosting.co.za>
New submission from Shun-ichi Goto <shunichi.goto at gmail.com>:
I installed python 2.6.3 on windows from .msi installer and get problem
to build ext modules with MinGW compiler.
It seems that Python 2.6.3 does not use compiler specified by user
via --compiler=xxx or setup.cfg on building ext module. Thus, MSVC
compiler is always used or show unreasonable error message
"error: Unable to find vcvarsall.bat" although specifying
--compiler=mingw32.
I found the change of r72594 cause this issue.
[projects] Diff of
/python/branches/release26-maint/Lib/distutils/command/build_ext.py
http://svn.python.org/view/python/branches/release26-maint/Lib/distutils/command/build_ext.py?view=diff&r1=72593&r2=72594
And following patch get the behaviour like before, but I don't
see why this change is introduced (merged from trunk).
{{{
diff -r 5874f642b473 distutils/command/build_ext.py
--- a/distutils/command/build_ext.py Tue Oct 06 10:39:34 2009 +0900
+++ b/distutils/command/build_ext.py Tue Oct 06 10:43:14 2009 +0900
@@ -303,7 +303,7 @@
# Setup the CCompiler object that we'll use to do all the
# compiling and linking
- self.compiler = new_compiler(compiler=None,
+ self.compiler = new_compiler(compiler=self.compiler,
verbose=self.verbose,
dry_run=self.dry_run,
force=self.force)
}}}
Is there any changes the way to specifying compiler?
----------
assignee: tarek
components: Distutils
messages: 93630
nosy: gotoh, tarek
severity: normal
status: open
title: 2.6.3 does not use specified compiler
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7068>
_______________________________________
From report at bugs.python.org Tue Oct 6 06:32:42 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 06 Oct 2009 04:32:42 +0000
Subject: [New-bugs-announce] [issue7069] inspect.isabstract to return
boolean values only
In-Reply-To: <1254803562.64.0.0318386285546.issue7069@psf.upfronthosting.co.za>
Message-ID: <1254803562.64.0.0318386285546.issue7069@psf.upfronthosting.co.za>
New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:
Currently, inspect.isabstract() may return an integer like 1048576
instead of True, or 0 instead of False.
Although technically correct, no other isXXX function behaves that way;
also, isgeneratorfunction() uses a similar code construct but casts the
result into a boolean.
The attached patch makes inspect.isabstract() return a boolean value
always.
----------
components: Library (Lib)
files: inspect.diff
keywords: patch
messages: 93631
nosy: gagenellina
severity: normal
status: open
title: inspect.isabstract to return boolean values only
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15052/inspect.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7069>
_______________________________________
From report at bugs.python.org Tue Oct 6 10:38:45 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Oct 2009 08:38:45 +0000
Subject: [New-bugs-announce] [issue7070] round(x) gives wrong result for
large odd integers
In-Reply-To: <1254818325.66.0.811291436482.issue7070@psf.upfronthosting.co.za>
Message-ID: <1254818325.66.0.811291436482.issue7070@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
The single-argument form of the builtin round function can give
incorrect results for large integers.
>>> x = 5e15+1
>>> x == int(x)
True
>>> x == round(x) # expect True here
False
>>> x
5000000000000001.0
>>> round(x)
5000000000000002.0
>>> int(x)
5000000000000001
This is already fixed in trunk (and in 3.x); the fix needs to be
backported to release26-maint.
----------
assignee: mark.dickinson
keywords: easy
messages: 93635
nosy: mark.dickinson
priority: high
severity: normal
stage: needs patch
status: open
title: round(x) gives wrong result for large odd integers
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7070>
_______________________________________
From report at bugs.python.org Tue Oct 6 13:11:43 2009
From: report at bugs.python.org (Michael Foord)
Date: Tue, 06 Oct 2009 11:11:43 +0000
Subject: [New-bugs-announce] [issue7071] distutils and IronPython
compatibility
In-Reply-To: <1254827503.56.0.590175679082.issue7071@psf.upfronthosting.co.za>
Message-ID: <1254827503.56.0.590175679082.issue7071@psf.upfronthosting.co.za>
New submission from Michael Foord <michael at voidspace.org.uk>:
distutils package installation isn't compatible with IronPython.
To reproduce first install IronPython 2.6 (RC1 is currently latest
version) from the msi installer. This installs by default on Windows
into "C:\Program Files\IronPython 2.6" and includes a "site-packages"
folder in the "Lib" subfolder.
With the simplest Python package created with "python setup.py sdist"
(CPython) from the first example in the distutils documentation I get
the following on install:
C:\compile\test\foo-1.0>"C:\Program Files\IronPython 2.6\ipy.exe"
setup.py install
running install
running build
running build_py
creating build
creating build\lib
copying foo.py -> build\lib
running install_lib
copying build\lib\foo.py -> C:\Program Files\IronPython
2.6\Lib\site-packages
error: C:\Program Files\IronPython 2.6\Lib\site-packages\foo.py: None
C:\compile\test\foo-1.0>dir "C:\Program Files\IronPython
2.6\Lib\site-packages"
Volume in drive C has no label.
Volume Serial Number is FC33-85DD
Directory of C:\Program Files\IronPython 2.6\Lib\site-packages
06/10/2009 11:37 <DIR> .
06/10/2009 11:37 <DIR> ..
15/09/2009 08:53 121 README.txt
1 File(s) 121 bytes
2 Dir(s) 71,854,129,152 bytes free
See also the following bug report against IronPython on the codeplex
issue tracker. Here the distutils install fails in bytecode compilation.
http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=24810
Bytecode compilation should not be attempted on IronPython as it does
not use Python bytecode. ( sys.dont_write_bytecode is True )
The fixes should be backported to Python 2.6 *if possible* as IronPython
2.6 uses the standard library from SVN and will pick up changes even
between releases.
----------
assignee: tarek
messages: 93640
nosy: michael.foord, tarek
severity: normal
stage: needs patch
status: open
title: distutils and IronPython compatibility
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7071>
_______________________________________
From report at bugs.python.org Tue Oct 6 16:07:45 2009
From: report at bugs.python.org (Naoki INADA)
Date: Tue, 06 Oct 2009 14:07:45 +0000
Subject: [New-bugs-announce] [issue7072] isspace(0xa0) is true on Mac OS X
In-Reply-To: <1254838065.19.0.554814525306.issue7072@psf.upfronthosting.co.za>
Message-ID: <1254838065.19.0.554814525306.issue7072@psf.upfronthosting.co.za>
New submission from Naoki INADA <songofacandy at gmail.com>:
Old FreeBSD's libc has a bug relate to utf-8 locale and Python have
patch for it: http://svn.python.org/view/python/trunk/Include/pyport.h?
view=diff&pathrev=43219&r1=36792&r2=36793
This bug appears in Mac OS X again. This test fails:
>>> s = '\xa0'
>>> assert s.strip() == s
>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'en_US.UTF-8')
'en_US.UTF-8'
>>> assert s.strip() == s
So above patch should be enabled for Mac OS X.
----------
messages: 93650
nosy: naoki
severity: normal
status: open
title: isspace(0xa0) is true on Mac OS X
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/issue7072>
_______________________________________
From report at bugs.python.org Wed Oct 7 00:46:26 2009
From: report at bugs.python.org (Jose Antonio Martin H)
Date: Tue, 06 Oct 2009 22:46:26 +0000
Subject: [New-bugs-announce] [issue7073] Python 2.6.3 final windows
installer installs a release candidate
In-Reply-To: <1254869186.46.0.379870800364.issue7073@psf.upfronthosting.co.za>
Message-ID: <1254869186.46.0.379870800364.issue7073@psf.upfronthosting.co.za>
New submission from Jose Antonio Martin H <jamartinh at fdi.ucm.es>:
Python 2.6.3 (r263rc1:75186, Oct 2 2009, 20:40:30) [MSC v.1500 32 bit
(Intel)] on win32
That is the python that is installed with the python 2.6.3 installer.
----------
components: Installation
messages: 93667
nosy: jamartinh
severity: normal
status: open
title: Python 2.6.3 final windows installer installs a release candidate
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7073>
_______________________________________
From report at bugs.python.org Wed Oct 7 01:39:30 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 06 Oct 2009 23:39:30 +0000
Subject: [New-bugs-announce] [issue7074] Turtle module crashes python
In-Reply-To: <1254872370.89.0.72942382773.issue7074@psf.upfronthosting.co.za>
Message-ID: <1254872370.89.0.72942382773.issue7074@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
Attached file run from IDLE edit window with 3.1, winxp works fine--
turtle moves in response to cursor keys-- if quit soon enough.
But after about 1000 key repeats, pythonw crashes with standard MSVC++
runtime error window, pythonw error window, and IDLE shell window
trackback ending with "RuntimeError: maximum recursion depth exceeded
while calling a Python object". The full traceback in appended to the file.
Disabling the undo buffer did not solve the problem.
Running the file from regular interpreter with
>>>exec(open(filename,'r').read())
gave essentially same result -- same traceback with slightly different
associated messages, so it is not an IDLE problem.
The demo/test at the bottem of turtle.py works fine -- but it does not
run as long.
I do not see the recursion, but calling the configuration merge with
every movement seems fishy.
----------
components: Library (Lib)
files: turtlecrash.py
messages: 93669
nosy: tjreedy
severity: normal
status: open
title: Turtle module crashes python
type: crash
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15059/turtlecrash.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7074>
_______________________________________
From report at bugs.python.org Wed Oct 7 05:46:11 2009
From: report at bugs.python.org (Chu-Cheng)
Date: Wed, 07 Oct 2009 03:46:11 +0000
Subject: [New-bugs-announce] [issue7075] Bug while put a set on a dict
In-Reply-To: <1254887171.46.0.861154287703.issue7075@psf.upfronthosting.co.za>
Message-ID: <1254887171.46.0.861154287703.issue7075@psf.upfronthosting.co.za>
New submission from Chu-Cheng <chucheng at gmail.com>:
>>> x={1:{1}}
>>> x[1] = (x.get(1).add(2))
>>> x
{1: None}
But...
>>> x={1:{1}}
>>> o = x.get(1)
>>> o.add(2)
>>> o
{1, 2}
>>> x[1] = o
>>> x
{1: {1, 2}}
----------
components: None
messages: 93674
nosy: chucheng
severity: normal
status: open
title: Bug while put a set on a dict
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7075>
_______________________________________
From report at bugs.python.org Wed Oct 7 07:48:11 2009
From: report at bugs.python.org (Shawn Ligocki)
Date: Wed, 07 Oct 2009 05:48:11 +0000
Subject: [New-bugs-announce] [issue7076] Documentation add note about
SystemRandom
In-Reply-To: <1254894491.86.0.615800723933.issue7076@psf.upfronthosting.co.za>
Message-ID: <1254894491.86.0.615800723933.issue7076@psf.upfronthosting.co.za>
New submission from Shawn Ligocki <sligocki at gmail.com>:
I did not notice the existence of random.SystemRandom until after I had
implemented my own version. I thought it would be nice to mention it in
the opening section. I've added a tiny note about random.SystemRandom.
What do you guys think, feel free to reword it, I just think that it
should be mentioned.
http://docs.python.org/library/random.html
----------
assignee: georg.brandl
components: Documentation
files: random.patch
keywords: patch
messages: 93678
nosy: georg.brandl, sligocki
severity: normal
status: open
title: Documentation add note about SystemRandom
type: feature request
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15065/random.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7076>
_______________________________________
From report at bugs.python.org Wed Oct 7 14:42:38 2009
From: report at bugs.python.org (Robert Szefler)
Date: Wed, 07 Oct 2009 12:42:38 +0000
Subject: [New-bugs-announce] [issue7077] SysLogHandler can't handle Unicode
In-Reply-To: <1254919358.82.0.721761611674.issue7077@psf.upfronthosting.co.za>
Message-ID: <1254919358.82.0.721761611674.issue7077@psf.upfronthosting.co.za>
New submission from Robert Szefler <robert.szefler at redefine.pl>:
Trying to .emit() a Unicode string causes an awkward exception to be thrown:
Traceback (most recent call last):
File "/usr/lib/python2.5/logging/handlers.py", line 672, in emit
self.socket.sendto(msg, self.address)
TypeError: sendto() takes exactly 3 arguments (2 given)
The issue is fixed simply by adding some sort of encoding coercion
before the sendto, for example:
if type(msg)==unicode: msg=msg.encode('utf-8')
----------
components: Library (Lib)
messages: 93694
nosy: rszefler
severity: normal
status: open
title: SysLogHandler can't handle Unicode
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7077>
_______________________________________
From report at bugs.python.org Wed Oct 7 20:10:27 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 07 Oct 2009 18:10:27 +0000
Subject: [New-bugs-announce] [issue7078] struct help in the interpreter does
not explain about the fmt option
In-Reply-To: <1254939027.81.0.0391767098754.issue7078@psf.upfronthosting.co.za>
Message-ID: <1254939027.81.0.0391767098754.issue7078@psf.upfronthosting.co.za>
New submission from Senthil Kumaran <orsenthil at gmail.com>:
>>> help(struct) mentions the functions which use fmt characters.
The builtin help does not mention the fmt characters and their meaning.
One should go online if he has to refer them.
----------
keywords: easy
messages: 93709
nosy: orsenthil
priority: low
severity: normal
status: open
title: struct help in the interpreter does not explain about the fmt option
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/issue7078>
_______________________________________
From report at bugs.python.org Wed Oct 7 23:10:45 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 07 Oct 2009 21:10:45 +0000
Subject: [New-bugs-announce] [issue7079] file_close() ignores return value
of close_the_file
In-Reply-To: <1254949845.61.0.606264060323.issue7079@psf.upfronthosting.co.za>
Message-ID: <1254949845.61.0.606264060323.issue7079@psf.upfronthosting.co.za>
New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:
I noticed that file_close() calls close_the_file(), then frees the
buffer for the file object. However, close_the_file() may fail and
return NULL if the file object is currently in use by another thread, in
which case freeing the buffer from underneath the C stdio library may
cause a crash.
Here's the relevant bit of code from fileobject.c:
static PyObject *
file_close(PyFileObject *f)
{
PyObject *sts = close_the_file(f);
PyMem_Free(f->f_setbuf);
f->f_setbuf = NULL;
return sts;
}
I think the two middle lines of the function should be wrapped in an "if
(sts)" block.
Attached is a short program that causes python to crash on two of my
systems (Windows XP running Python 2.6.3 and Debian running Python 2.5)
and a patch with my proposed fix.
I think Python 3 is immune because the I/O code has been completely
rewritten. I have not checked the Python 3 code to see if there are any
analogous problems in the new code, however.
----------
components: IO, Interpreter Core
files: fileobject.diff
keywords: patch
messages: 93723
nosy: stutzbach
severity: normal
status: open
title: file_close() ignores return value of close_the_file
type: crash
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15076/fileobject.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7079>
_______________________________________
From report at bugs.python.org Thu Oct 8 01:01:43 2009
From: report at bugs.python.org (egreen)
Date: Wed, 07 Oct 2009 23:01:43 +0000
Subject: [New-bugs-announce] [issue7080] locale.strxfrm raises MemoryError
In-Reply-To: <1254956503.26.0.613752326447.issue7080@psf.upfronthosting.co.za>
Message-ID: <1254956503.26.0.613752326447.issue7080@psf.upfronthosting.co.za>
New submission from egreen <egreen at operamail.com>:
The strxfrm function in the locale module can potentially raise a
MemoryError.
The failing malloc is in Modules/_localemodule.c, line 291.
This is because the variable n0 of type Py_ssize_t is passed to
PyArg_ParseTuple, which expects an int when PY_SSIZE_T_CLEAN is not defined.
Patch attached, which also fixes an unrelated memory leak.
----------
components: Library (Lib)
files: strxfrm_MemoryError.patch
keywords: patch
messages: 93728
nosy: egreen, loewis
severity: normal
status: open
title: locale.strxfrm raises MemoryError
type: crash
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15078/strxfrm_MemoryError.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7080>
_______________________________________
From report at bugs.python.org Thu Oct 8 13:37:48 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 08 Oct 2009 11:37:48 +0000
Subject: [New-bugs-announce] [issue7081] ">" formatting behaving like "="
formatting
In-Reply-To: <1255001868.04.0.9715466253.issue7081@psf.upfronthosting.co.za>
Message-ID: <1255001868.04.0.9715466253.issue7081@psf.upfronthosting.co.za>
New submission from Nick Coghlan <ncoghlan at gmail.com>:
The ">" alignment flag to format() is not right aligning numbers
properly on trunk and the py3k branch:
>>> format(0x1234, "+#08x")
'+0x01234'
>>> format(0x1234, "0=+#8x")
'+0x01234'
>>> format(0x1234, "0>+#8x")
'+0x01234'
That last one should be:
>>> format(0x1234, "0>+#8x")
'0+0x1234'
The intended behaviour of ">" is more obviously correct when you
consider a leading space instead of a leading zero:
>>> format(0x1234, " >+#8x")
' +0x1234'
This is only an error on the development versions - the behaviour is
correct on the 2.6 and 3.1 maintenance branches.
----------
assignee: eric.smith
messages: 93738
nosy: eric.smith, ncoghlan
priority: normal
severity: normal
status: open
title: ">" formatting behaving like "=" formatting
type: behavior
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7081>
_______________________________________
From report at bugs.python.org Thu Oct 8 14:38:33 2009
From: report at bugs.python.org (Darren Worrall)
Date: Thu, 08 Oct 2009 12:38:33 +0000
Subject: [New-bugs-announce] [issue7082] Patch for get attachments in email
Message-ID: <1255005513.55.0.498801642336.issue7082@psf.upfronthosting.co.za>
Changes by Darren Worrall <dw at darrenworrall.co.uk>:
----------
nosy: DazWorrall
severity: normal
status: open
title: Patch for get attachments in email
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7082>
_______________________________________
From report at bugs.python.org Thu Oct 8 15:49:58 2009
From: report at bugs.python.org (=?utf-8?b?QW5kcsOpIEJqw6RyYnk=?=)
Date: Thu, 08 Oct 2009 13:49:58 +0000
Subject: [New-bugs-announce] [issue7083] locals() behaviour differs when
tracing is in effect
In-Reply-To: <1255009798.45.0.553728595296.issue7083@psf.upfronthosting.co.za>
Message-ID: <1255009798.45.0.553728595296.issue7083@psf.upfronthosting.co.za>
New submission from Andr? Bj?rby <andre.bjarby at gmail.com>:
Running the attached script shows that locals() behaves differently
depending on whether sys.settrace() is active.
This does not occur when calling locals() in the global scope, only when
used inside functions.
----------
components: Extension Modules, Interpreter Core
files: localstest.py
messages: 93745
nosy: andbj
severity: normal
status: open
title: locals() behaviour differs when tracing is in effect
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.1
Added file: http://bugs.python.org/file15081/localstest.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7083>
_______________________________________
From report at bugs.python.org Thu Oct 8 23:35:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Oct 2009 21:35:08 +0000
Subject: [New-bugs-announce] [issue7084] printing a list releases the GIL
carelessly
In-Reply-To: <1255037708.8.0.126059126941.issue7084@psf.upfronthosting.co.za>
Message-ID: <1255037708.8.0.126059126941.issue7084@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
Function list_print() in listobject.c releases the GIL before calling
fprintf() but doesn't check the list size again when it gets the GIL
back. If another thread truncated the list, a crash can ensue. The
attached script crashes reliably here.
----------
files: list_print.py
messages: 93764
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: printing a list releases the GIL carelessly
type: crash
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15083/list_print.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7084>
_______________________________________
From report at bugs.python.org Fri Oct 9 00:48:51 2009
From: report at bugs.python.org (Jiri Krivanek)
Date: Thu, 08 Oct 2009 22:48:51 +0000
Subject: [New-bugs-announce] [issue7085] strptime problem
In-Reply-To: <1255042131.92.0.134837798932.issue7085@psf.upfronthosting.co.za>
Message-ID: <1255042131.92.0.134837798932.issue7085@psf.upfronthosting.co.za>
New submission from Jiri Krivanek <jiri.krivanek at betacontrol.cz>:
The following simple code works perfectly on W2K, WXP, Ubuntu, OSX10.4
OSX10.5. It, however, stopped working on OSX10.6 (Snow Leopard): It
simply crashes. It is a strptime() which causes problems to me.
Any idea? Any workaround?
import time
import thread
def test():
print "TS: "
print "%s" % str(time.strptime("2009-09-09 16-56-37", "%Y-%m-%d %H-
%M-%S"))
thread.start_new_thread (test, ())
time.sleep(2.0)
----------
assignee: ronaldoussoren
components: Macintosh
messages: 93765
nosy: kakacek, ronaldoussoren
severity: normal
status: open
title: strptime problem
type: crash
versions: Python 2.4
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7085>
_______________________________________
From report at bugs.python.org Fri Oct 9 00:58:22 2009
From: report at bugs.python.org (Jr Aquino)
Date: Thu, 08 Oct 2009 22:58:22 +0000
Subject: [New-bugs-announce] [issue7086] logging.handlers.SysLogHandler with
TCP support
In-Reply-To: <1255042702.01.0.583220136591.issue7086@psf.upfronthosting.co.za>
Message-ID: <1255042702.01.0.583220136591.issue7086@psf.upfronthosting.co.za>
New submission from Jr Aquino <jr.aquino at citrixonline.com>:
This patch is to address the deficiency in sending syslog messages to an
external syslog server via tcp or udp.
Currently the handler only really supports udp unless it is being
redirected locally through a unix socket.
The submitted patch allows for the standard udp SOCK_DGRAM behavior to
continue being the default, but allows for a protocol object to be defined
as tcp to allow for the alternate protocol.
----------
components: Extension Modules
files: handlers.py.diff
keywords: patch
messages: 93766
nosy: enigma
severity: normal
status: open
title: logging.handlers.SysLogHandler with TCP support
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15084/handlers.py.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7086>
_______________________________________
From report at bugs.python.org Fri Oct 9 04:48:00 2009
From: report at bugs.python.org (s7v7nislands)
Date: Fri, 09 Oct 2009 02:48:00 +0000
Subject: [New-bugs-announce] [issue7087] use keyword 'as' in _xmlplus
In-Reply-To: <1255056480.98.0.446336342031.issue7087@psf.upfronthosting.co.za>
Message-ID: <1255056480.98.0.446336342031.issue7087@psf.upfronthosting.co.za>
New submission from s7v7nislands <s7v7nislands at gmail.com>:
In these files: _xmlplus/xpath/ParsedAbbreviatedAbsoluteLocationPath.py
_xmlplus/xpath/ParsedAbbreviatedRelativeLocationPath.py, use the keyword
'as'.
----------
messages: 93770
nosy: s7v7nislands
severity: normal
status: open
title: use keyword 'as' in _xmlplus
type: compile error
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7087>
_______________________________________
From report at bugs.python.org Fri Oct 9 05:17:19 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 09 Oct 2009 03:17:19 +0000
Subject: [New-bugs-announce] [issue7088] New (in 2.6) functions in signal
module are not documented as unix-only
In-Reply-To: <1255058239.85.0.357925408849.issue7088@psf.upfronthosting.co.za>
Message-ID: <1255058239.85.0.357925408849.issue7088@psf.upfronthosting.co.za>
New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:
2.6 introduced several new functions to the signal module that are not
available on Windows (setitimer, getitimer, and siginterrupt). However,
they aren't documented with Availability: Unix.
----------
assignee: georg.brandl
components: Documentation
messages: 93772
nosy: georg.brandl, stutzbach
severity: normal
status: open
title: New (in 2.6) functions in signal module are not documented as unix-only
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/issue7088>
_______________________________________
From report at bugs.python.org Fri Oct 9 10:11:54 2009
From: report at bugs.python.org (Jan David Mol)
Date: Fri, 09 Oct 2009 08:11:54 +0000
Subject: [New-bugs-announce] [issue7089] shlex behaves unexpected if
newlines are not whitespace
In-Reply-To: <1255075914.03.0.04545559487.issue7089@psf.upfronthosting.co.za>
Message-ID: <1255075914.03.0.04545559487.issue7089@psf.upfronthosting.co.za>
New submission from Jan David Mol <jjdmol at gmail.com>:
The shlex module does not function as expected in the presence of
comments when newlines are not whitespace. An example (attached):
>>> from shlex import shlex
>>>
>>> lexer = shlex("a \n b")
>>> print ",".join(lexer)
a,b
>>>
>>> lexer = shlex("a # comment \n b")
>>> print ",".join(lexer)
a,b
>>>
>>> lexer = shlex("a \n b")
>>> lexer.whitespace=" "
>>> print ",".join(lexer)
a,
,b
>>>
>>> lexer = shlex("a # comment \n b")
>>> lexer.whitespace=" "
>>> print ",".join(lexer)
a,b
Now where did my newline go? The comment ate it! Even though the docs
seem to indicate the newline is not part of the comment itself:
shlex.commenters:
The string of characters that are recognized as comment beginners.
All characters from the comment beginner to end of line are ignored.
Includes just '#' by default.
----------
files: lexertest.py
messages: 93776
nosy: jjdmol2
severity: normal
status: open
title: shlex behaves unexpected if newlines are not whitespace
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/file15087/lexertest.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7089>
_______________________________________
From report at bugs.python.org Fri Oct 9 11:12:34 2009
From: report at bugs.python.org (Mahmoud)
Date: Fri, 09 Oct 2009 09:12:34 +0000
Subject: [New-bugs-announce] [issue7090] encoding uncode objects greater
than FFFF
In-Reply-To: <1255079554.68.0.710322041436.issue7090@psf.upfronthosting.co.za>
Message-ID: <1255079554.68.0.710322041436.issue7090@psf.upfronthosting.co.za>
New submission from Mahmoud <saghaei at med.mui.ac.ir>:
Odd behaviour with str.encode or codecs.Codec.encode or simailar
functions, when dealing with uncode objects above ffff
with 2.6
>>> u'\u10380'.encode('utf')
'\xe1\x80\xb80'
with 3.x
'\u10380'.encode('utf')
'\xe1\x80\xb80'
correct output must be:
\xf0\x90\x8e\x80
----------
components: Unicode
messages: 93780
nosy: msaghaei
severity: normal
status: open
title: encoding uncode objects greater than FFFF
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7090>
_______________________________________
From report at bugs.python.org Fri Oct 9 14:50:28 2009
From: report at bugs.python.org (jmb)
Date: Fri, 09 Oct 2009 12:50:28 +0000
Subject: [New-bugs-announce] [issue7091] Distutils build ignores the
--compiler command line option
In-Reply-To: <1255092628.15.0.61454939103.issue7091@psf.upfronthosting.co.za>
Message-ID: <1255092628.15.0.61454939103.issue7091@psf.upfronthosting.co.za>
New submission from jmb <jeberger at free.fr>:
I tried building an extension on windows with the following command:
> python setup.py build --compiler=mingw32
and got an error: "Unable to find vcvarsall.bat". The way I understand
it, that error shows that it tried to use the MSVC compiler instead of
obeying the --compiler=mingw32 command line option.
I then tried to give a bogus compiler value and got the same error
message (iirc python 2.5 used to say that it didn't know the 'bogus'
compiler).
Finally, I modified _default_compilers in distutils/ccompiler.py and put
'mingw32' in the 'nt' key. Afterward, my extension compiled and works
properly.
Python version: 2.6.3 on WinXP 32 bits.
----------
assignee: tarek
components: Distutils
messages: 93789
nosy: jmb, tarek
severity: normal
status: open
title: Distutils build ignores the --compiler command line option
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7091>
_______________________________________
From report at bugs.python.org Fri Oct 9 16:30:33 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 09 Oct 2009 14:30:33 +0000
Subject: [New-bugs-announce] [issue7092] Test suite emits many
DeprecationWarnings when -3 is enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
New submission from Jean-Paul Calderone <exarkun at divmod.com>:
If the test suite is run with -3, many deprecation warnings are
reported. Quite a few are generated by code in the tests themselves,
but many are from constructs in the stdlib which are different or no
longer supported in 3.x.
Even aside from the fact that many of these warnings being caused by
code which I think many people would agree is not ideal, I think it is
important for these warnings to be fixed for Python 2.7. Since the 3.x
porting guidelines recommend that projects first run their test suite
with -3, these warnings are going to be generating extra noise for
developers to filter through when they try porting their code to 3.x.
They shouldn't need to wade through stdlib warnings to find warnings
about their own code.
Attached is a log of a complete test run with -3.
----------
components: Library (Lib)
files: test.log
messages: 93795
nosy: exarkun
severity: normal
status: open
title: Test suite emits many DeprecationWarnings when -3 is enabled
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file15091/test.log
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________
From report at bugs.python.org Fri Oct 9 16:55:47 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Oct 2009 14:55:47 +0000
Subject: [New-bugs-announce] [issue7093] xmlrpclib.ServerProxy() doesn't
support unicode uri
In-Reply-To: <1255100147.66.0.74499268339.issue7093@psf.upfronthosting.co.za>
Message-ID: <1255100147.66.0.74499268339.issue7093@psf.upfronthosting.co.za>
New submission from STINNER Victor <victor.stinner at haypocalc.com>:
I backported xmlrpclib from Python trunk to Python 2.5 to get "connected
socket" (HTTP/1.1), which implies to backport also httplib, ssl and socket. It
works well. It's *much* faster, eg. 960 ms => 70 ms with HTTPS over a VPN.
I just have a little issue: if ServerProxy() URI is an unicode string and an
argument is an unicode string (with at least one non-ASCII character), the
request fails with:
File ".../SVN/python-trunk/Lib/httplib.py", line 784, in _send_output
msg += message_body
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 320:
ordinal not in range(128)
Attached patch includes a test.
Can uri contains a login and/or pasword? If yes, should it be encoded to UTF-8
(instead of ASCII)?
----------
components: Library (Lib)
files: xmlrpclib_unicode_host.patch
keywords: patch
messages: 93798
nosy: haypo
severity: normal
status: open
title: xmlrpclib.ServerProxy() doesn't support unicode uri
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15093/xmlrpclib_unicode_host.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7093>
_______________________________________
From report at bugs.python.org Fri Oct 9 21:54:04 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 09 Oct 2009 19:54:04 +0000
Subject: [New-bugs-announce] [issue7094] Add alternate float formatting
styles to new-style formatting.
In-Reply-To: <1255118044.58.0.727731702587.issue7094@psf.upfronthosting.co.za>
Message-ID: <1255118044.58.0.727731702587.issue7094@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
Python's old-style formatting supports the use of an alternative form
(specified by including a '#' in the format) for 'e', 'f' and 'g'
formatting:
Python 3.2a0 (py3k:75275:75276, Oct 7 2009, 20:26:36)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> '%.17g' % 1.2
'1.2'
>>> '%#.17g' % 1.2
'1.2000000000000000'
New-style formatting doesn't currently support this:
>>> format(1.2, '#.17g')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: Alternate form (#) not allowed in float format specifier
To aid migration from old-style to new-style formatting, it might be worth
adding the alternate forms. At least the float, complex and Decimal types
would be affected.
----------
components: Interpreter Core
messages: 93807
nosy: eric.smith, mark.dickinson
severity: normal
stage: test needed
status: open
title: Add alternate float formatting styles to new-style formatting.
type: feature request
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7094>
_______________________________________
From report at bugs.python.org Sat Oct 10 01:13:18 2009
From: report at bugs.python.org (schlesin)
Date: Fri, 09 Oct 2009 23:13:18 +0000
Subject: [New-bugs-announce] [issue7095] Multiprocessing.Array(lock=False)
fails
In-Reply-To: <1255129998.33.0.0350728578751.issue7095@psf.upfronthosting.co.za>
Message-ID: <1255129998.33.0.0350728578751.issue7095@psf.upfronthosting.co.za>
New submission from schlesin <schlesin at cshl.edu>:
The documentation for the Multiprocessing.Array says:
multiprocessing.Array(typecode_or_type, size_or_initializer, *,
lock=True)?
...
If lock is False then access to the returned object will not be
automatically protected by a lock, so it will not necessarily be
?process-safe?.
...
However:
In [48]: mp.Array('i',1,lock=False)
---------------------------------------------------------------------------
AssertionError Traceback (most recent call
last)
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
multiprocessing/__init__.pyc in Array(typecode_or_type,
size_or_initializer, **kwds)
252 '''
253 from multiprocessing.sharedctypes import Array
--> 254 return Array(typecode_or_type, size_or_initializer,
**kwds)
255
256 #
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
multiprocessing/sharedctypes.pyc in Array(typecode_or_type,
size_or_initializer, **kwds)
85 if lock is None:
86 lock = RLock()
---> 87 assert hasattr(lock, 'acquire')
88 return synchronized(obj, lock)
89
AssertionError:
-------
I.e. it looks like lock=False is not actually supported.
----------
components: Extension Modules
messages: 93812
nosy: schlesin
severity: normal
status: open
title: Multiprocessing.Array(lock=False) fails
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7095>
_______________________________________
From report at bugs.python.org Sat Oct 10 04:53:53 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 10 Oct 2009 02:53:53 +0000
Subject: [New-bugs-announce] [issue7096] test_curses fails on 3.1 when run
under regrtest
In-Reply-To: <1255143233.91.0.954013064992.issue7096@psf.upfronthosting.co.za>
Message-ID: <1255143233.91.0.954013064992.issue7096@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
test_curses currently fails on 3.1 when run under regrtest. It passes
if run in verbose mode or standalone. The cause turns out to be that
when not run in verbose mode regrtest substitutes an io.StringIO
instance for sys.stdout, and that object does not have a .fileno
attribute. The line that fails is this:
curses.setupterm(fd=sys.stdout.fileno())
This test fails only on 3.1 for a couple of different reasons. On trunk
and py3k, r73072 and the r73678 merge removed the regrtest check that
made sure the tests produced no output on stdout, and therefore it no
longer replaces stdout with a StringIO instance . On 2.6, on the other
hand, the above line references sys.__stdout__.fileno() (presumably for
this very reason!) r74181 was the commit that changed this to the above
on the py3k branch, citing it as the cause of regrtest "duplicating some
output".
It seems to me that not checking for output on stdout in regrtest is a
regression in the quality of the test runner. It is also not clear to
me how test_curses writing to the real stdout would cause regrtest to
duplicate output. So I'm putting the authors of the two patches
involved on the nosy list so they can comment. FYI I reverted the
stdout change in test_curses and regrtest seems to run fine, so I'm not
sure what output was being duplicated.
----------
components: Tests
messages: 93818
nosy: alexandre.vassalotti, pitrou, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: test_curses fails on 3.1 when run under regrtest
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7096>
_______________________________________
From report at bugs.python.org Sat Oct 10 19:40:14 2009
From: report at bugs.python.org (steve steiner)
Date: Sat, 10 Oct 2009 17:40:14 +0000
Subject: [New-bugs-announce] [issue7097] urlparse.urljoin of simple
"http://" and "somedomain.com" produces incorrect result
In-Reply-To: <1255196414.88.0.948496525016.issue7097@psf.upfronthosting.co.za>
Message-ID: <1255196414.88.0.948496525016.issue7097@psf.upfronthosting.co.za>
New submission from steve steiner <ssteiner at users.sourceforge.net>:
Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from urlparse import urljoin
>>> urljoin("http://", "somedomain.com")
'http:///somedomain.com'
Note the three leading slashes, should be "http://somedomain.com"
----------
components: Library (Lib)
messages: 93834
nosy: ssteiner
severity: normal
status: open
title: urlparse.urljoin of simple "http://" and "somedomain.com" produces incorrect result
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7097>
_______________________________________
From report at bugs.python.org Sat Oct 10 20:22:12 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 10 Oct 2009 18:22:12 +0000
Subject: [New-bugs-announce] [issue7098] g formatting for decimal types
should always strip trailing zeros.
In-Reply-To: <1255198932.03.0.979291900289.issue7098@psf.upfronthosting.co.za>
Message-ID: <1255198932.03.0.979291900289.issue7098@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
Type 'g' formatting for Decimal instances doesn't behave in the same way
as for floats when an explicit precision is given. It should strip all
trailing zeros from the result:
Python 2.7a0 (trunk:75309, Oct 10 2009, 13:44:18)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import Decimal
>>> format(Decimal('123.00'), '.6g') # expect '123'
'123.00'
(When no explicit precision is given, Decimal formatting with type 'g'
tries to preserve the information about the exponent of the Decimal
instance whenever possible; this also differs from float formatting, but
it's intentional. This should probably be documented.)
----------
assignee: mark.dickinson
components: Library (Lib)
messages: 93835
nosy: mark.dickinson
priority: normal
severity: normal
stage: test needed
status: open
title: g formatting for decimal types should always strip trailing zeros.
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/issue7098>
_______________________________________
From report at bugs.python.org Sat Oct 10 20:45:23 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 10 Oct 2009 18:45:23 +0000
Subject: [New-bugs-announce] [issue7099] Decimal.is_normal should return
True even for numbers with exponent > Emax
In-Reply-To: <1255200323.46.0.445694394995.issue7099@psf.upfronthosting.co.za>
Message-ID: <1255200323.46.0.445694394995.issue7099@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
Noticed by Stefan Krah:
Python 2.7a0 (trunk:75309, Oct 10 2009, 13:44:18)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import *
>>> x = Decimal('9.99999999e+1000')
>>> c = getcontext()
>>> c.prec = 9
>>> c.Emax = 999
>>> c.Emin = -999
>>>
>>> x.is_normal()
False
>>> x.is_subnormal()
False
>>> x.is_infinite()
False
>>> x.is_nan()
False
>>> x.is_zero()
False
So if x isn't normal, subnormal, zero, nan or infinity, what the ****
is it?!
x.is_normal() should probably be returning True here.
----------
assignee: mark.dickinson
components: Library (Lib)
messages: 93838
nosy: mark.dickinson, skrah
priority: normal
severity: normal
status: open
title: Decimal.is_normal should return True even for numbers with exponent > Emax
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/issue7099>
_______________________________________
From report at bugs.python.org Sat Oct 10 22:39:30 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Oct 2009 20:39:30 +0000
Subject: [New-bugs-announce] [issue7100] test_xmlrpc: global name
'stop_serving' is not defined
In-Reply-To: <1255207170.52.0.845543632042.issue7100@psf.upfronthosting.co.za>
Message-ID: <1255207170.52.0.845543632042.issue7100@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
This happens at least on the py3k branch, I haven't checked other branches.
test test_xmlrpc failed -- Traceback (most recent call last):
File "/home/antoine/py3k/bz-multistream/Lib/test/test_xmlrpc.py", line
344, in tearDown
stop_serving()
NameError: global name 'stop_serving' is not defined
1 test failed:
test_xmlrpc
Unhandled exception in thread started by <bound method Thread._bootstrap
of <Thread(Thread-13, started 140424593951056)>>
Error in sys.excepthook:
TypeError: 'NoneType' object is not callable
Original exception was:
Traceback (most recent call last):
File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
282, in _handle_request_noblock
File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
308, in process_request
File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
321, in finish_request
File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
639, in __init__
File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
693, in finish
File "/home/antoine/py3k/bz-multistream/Lib/socket.py", line 242, in close
AttributeError: 'NoneType' object has no attribute 'RawIOBase'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/antoine/py3k/bz-multistream/Lib/test/test_xmlrpc.py", line
294, in http_server
File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
267, in handle_request
File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
284, in _handle_request_noblock
File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
340, in handle_error
ImportError: No module named traceback
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/antoine/py3k/bz-multistream/Lib/test/test_xmlrpc.py", line
297, in http_server
AttributeError: 'NoneType' object has no attribute 'timeout'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 509,
in _bootstrap_inner
File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 462,
in run
File "/home/antoine/py3k/bz-multistream/Lib/test/test_xmlrpc.py", line
300, in http_server
File "/home/antoine/py3k/bz-multistream/Lib/socket.py", line 178, in close
File "/home/antoine/py3k/bz-multistream/Lib/socket.py", line 173, in
_real_close
AttributeError: 'NoneType' object has no attribute 'socket'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 527,
in _bootstrap_inner
AttributeError: 'Thread' object has no attribute '_exc_info'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 482,
in _bootstrap
File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 557,
in _bootstrap_inner
AttributeError: __exit__
[101191 refs]
1 test failed:
test_xmlrpc
Unhandled exception in thread started by <bound method Thread._bootstrap
of <Thread(Thread-13, started 140014861584720)>>
Error in sys.excepthook:
TypeError: 'NoneType' object is not callable
Original exception was:
Traceback (most recent call last):
File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
282, in _handle_request_noblock
File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
308, in process_request
File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
321, in finish_request
File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
639, in __init__
File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
693, in finish
File "/home/antoine/py3k/bz-multistream/Lib/socket.py", line 242, in close
AttributeError: 'NoneType' object has no attribute 'RawIOBase'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/antoine/py3k/bz-multistream/Lib/test/test_xmlrpc.py", line
294, in http_server
File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
267, in handle_request
File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
284, in _handle_request_noblock
File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
340, in handle_error
ImportError: No module named traceback
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/antoine/py3k/bz-multistream/Lib/test/test_xmlrpc.py", line
297, in http_server
AttributeError: 'NoneType' object has no attribute 'timeout'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 509,
in _bootstrap_inner
File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 462,
in run
File "/home/antoine/py3k/bz-multistream/Lib/test/test_xmlrpc.py", line
300, in http_server
File "/home/antoine/py3k/bz-multistream/Lib/socket.py", line 178, in close
File "/home/antoine/py3k/bz-multistream/Lib/socket.py", line 173, in
_real_close
AttributeError: 'NoneType' object has no attribute 'socket'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 527,
in _bootstrap_inner
AttributeError: 'Thread' object has no attribute '_exc_info'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 482,
in _bootstrap
File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 557,
in _bootstrap_inner
AttributeError: __exit__
[101191 refs]
----------
assignee: krisvale
components: Tests
messages: 93843
nosy: krisvale, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: test_xmlrpc: global name 'stop_serving' is not defined
type: crash
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7100>
_______________________________________
From report at bugs.python.org Sun Oct 11 01:49:22 2009
From: report at bugs.python.org (Denis Martinez)
Date: Sat, 10 Oct 2009 23:49:22 +0000
Subject: [New-bugs-announce] [issue7101] tarfile: OSError with
TarFile.add(..., recursive=True) about non-existing file
In-Reply-To: <1255218562.66.0.694569702907.issue7101@psf.upfronthosting.co.za>
Message-ID: <1255218562.66.0.694569702907.issue7101@psf.upfronthosting.co.za>
New submission from Denis Martinez <deuns.martinez at gmail.com>:
I have written a server backup script (file attached) which archives a
list of directories with tarfile and uploads the file to FTP. Today, the
script hanged, with an exception:
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python2.6/threading.py", line 525, in __bootstrap_inner
self.run()
File "./backup.py", line 48, in run
tar.add(file_or_directory, recursive=True)
File "/usr/lib/python2.6/tarfile.py", line 1981, in add
self.add(os.path.join(name, f), os.path.join(arcname, f), recursive,
exclude)
File "/usr/lib/python2.6/tarfile.py", line 1965, in add
tarinfo = self.gettarinfo(name, arcname)
File "/usr/lib/python2.6/tarfile.py", line 1834, in gettarinfo
statres = os.lstat(name)
OSError: [Errno 2] No such file or directory: '/srv/myfile.htdigest'
What I did here is that I removed the htdigest file while the tarfile
was archiving /srv. I haven't managed to reproduce the bug a second time.
It seems normal that tarfile shouldn't fail is this case; maybe it needs
some exception checking around the stat/lstat calls.
----------
components: Library (Lib)
files: backup2.py
messages: 93845
nosy: denis
severity: normal
status: open
title: tarfile: OSError with TarFile.add(..., recursive=True) about non-existing file
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15098/backup2.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7101>
_______________________________________
From report at bugs.python.org Sun Oct 11 13:16:07 2009
From: report at bugs.python.org (Fredrik Hedman)
Date: Sun, 11 Oct 2009 11:16:07 +0000
Subject: [New-bugs-announce] [issue7102] Problems building pyhton from
source on Snow Leopard (Mac OS X 10.6)
In-Reply-To: <1255259767.14.0.58470388627.issue7102@psf.upfronthosting.co.za>
Message-ID: <1255259767.14.0.58470388627.issue7102@psf.upfronthosting.co.za>
New submission from Fredrik Hedman <fredrik.hedman at me.com>:
-*- mode: outline -*-
* Problems building pyhton from source on Snow Leopard (Mac OS X 10.6)
1 error and 39 warnings and a quick fix.
** Building python from source with --enable-framework
I have a fresh install of Snow Leopard and the accompanying Xcode 3.2;
see below for platform details. I'm trying to build python from
Python-3.1.1.tar.bz2. The build
$ export MACOSX_DEPLOYMENT_TARGET=10.6
$ ./configure --enable-framework
$ make
fails with the following error:
gcc -framework CoreFoundation Python.framework/Versions/3.1/Python -
o python \
Modules/python.o \
Python.framework/Versions/3.1/Python -ldl
ld: warning: in Python.framework/Versions/3.1/Python, file is not of
required architecture
ld: warning: in Python.framework/Versions/3.1/Python, file is not of
required architecture
Undefined symbols:
"_PyMem_Malloc", referenced from:
_main in python.o
_main in python.o
_main in python.o
_main in python.o
"_Py_Main", referenced from:
_main in python.o
_main in python.o
"_PyMem_Free", referenced from:
_main in python.o
_main in python.o
_main in python.o
_main in python.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [python] Error 1
** Error analysis and quick fix
The symbols above that are not defined are all defined in the library
built
before the error occurs: libpython3.1.a. For some reason configure
does not include this library when linking.
Looking at the generated Makefile and the rule BUILDPYTHON one sees
that BLDLIBRARY seems to be not set properly. If I tweak the Makefile
and set
BLDLIBRARY= -L. $(LIBRARY)
then relaunching make works just fine. The failed rule above
completes just fine and make completes without error.
** 39 warnings and "file is not of required architecture"?
The results are not flawless since there are some complaints:
Python build finished, but the necessary bits to build these modules
were not found:
ossaudiodev spwd
To find the necessary bits, look in setup.py in detect_modules() for
the module's name.
Failed to build these modules:
_curses _curses_panel
I choose to ignore these missing bits along with the other 39 warnings
generated during the build. Most seem to be about quality of code.
The most worrying is the one about
ld: warning: in Python.framework/Versions/3.1/Python, file is not of
required architecture
which I do not really understand at this point, being quite new to
Cocoa and frameworks.
** Testing
make test reports:
test_zlib
310 tests OK.
1 test failed:
test_telnetlib
24 tests skipped:
test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
test_codecmaps_kr test_codecmaps_tw test_curses test_epoll
test_largefile test_nis test_normalization test_ossaudiodev
test_pep277 test_smtpnet test_socketserver test_startfile
test_timeout test_tk test_ttk_guionly test_urllib2net
test_urllibnet test_winreg test_winsound test_xmlrpc_net
test_zipfile64
Those skips are all expected on darwin.
So the quick fix should be acceptable.
* A more permanent fix? Needs verification
In file configure.in change (line 674)
BLDLIBRARY=''
to
BLDLIBRARY='-L. -lpython$(VERSION)'
Then generate a new configure script with
autoreconf
./configure MACOSX_DEPLOYMENT_TARGET=10.6 --enable-framework
make && make test
This seems to work fine, but must to be verified by someone with more
Cocoa and Framework knowledge since it sort of goes against the comments
that precede the changed line in configure.in.
* Platform
$ uname -a
Darwin beech.local 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31
22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386
$ xcode-select -version
xcode-select version 895.
----------
assignee: ronaldoussoren
components: Installation, Macintosh
messages: 93851
nosy: FredrikHedman, ronaldoussoren
severity: normal
status: open
title: Problems building pyhton from source on Snow Leopard (Mac OS X 10.6)
type: compile error
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7102>
_______________________________________
From report at bugs.python.org Sun Oct 11 15:09:35 2009
From: report at bugs.python.org (Thomas Courbon)
Date: Sun, 11 Oct 2009 13:09:35 +0000
Subject: [New-bugs-announce] [issue7103] Error in config parser example (w/
Patch)
In-Reply-To: <1255266575.87.0.417277827864.issue7103@psf.upfronthosting.co.za>
Message-ID: <1255266575.87.0.417277827864.issue7103@psf.upfronthosting.co.za>
New submission from Thomas Courbon <harthie at yahoo.fr>:
When ran in python 3.1.1 (hand compiled, fedora 11), the first example
of configparser module fail with :
Traceback (most recent call last):
File "test1.py", line 22, in <module>
config.write(configfile)
File "/usr/local/lib/python3.1/configparser.py", line 394, in write
fp.write("[%s]\n" % section)
TypeError: write() argument 1 must be bytes or buffer, not str
This can be solved by replacing :
with open('example.cfg', 'wb') as configfile:
by :
with open('example.cfg', 'w') as configfile:
Patch attached.
Cheer !
Thomas
----------
assignee: georg.brandl
components: Documentation
messages: 93858
nosy: georg.brandl, tcourbon
severity: normal
status: open
title: Error in config parser example (w/ Patch)
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7103>
_______________________________________
From report at bugs.python.org Sun Oct 11 18:32:13 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sun, 11 Oct 2009 16:32:13 +0000
Subject: [New-bugs-announce] [issue7104] test_descr uses __cmp__ which will
never be called
In-Reply-To: <1255278733.49.0.73816773283.issue7104@psf.upfronthosting.co.za>
Message-ID: <1255278733.49.0.73816773283.issue7104@psf.upfronthosting.co.za>
New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:
The following is from Lib/test/test_descr.py. It's trying to test if
looking up a special method on an object leaks references. It tests it
by using __cmp__. The test will always pass because Python 3 is trying
to look up __eq__, not __cmp__. Hence, __cmp__ should be changed to __eq__.
# Test lookup leaks [SF bug 572567]
import sys,gc
if hasattr(gc, 'get_objects'):
class G(object):
def __cmp__(self, other):
return 0
g = G()
orig_objects = len(gc.get_objects())
for i in range(10):
g==g
new_objects = len(gc.get_objects())
self.assertEqual(orig_objects, new_objects)
----------
components: Tests
messages: 93862
nosy: stutzbach
severity: normal
status: open
title: test_descr uses __cmp__ which will never be called
versions: Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7104>
_______________________________________
From report at bugs.python.org Sun Oct 11 19:29:26 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Oct 2009 17:29:26 +0000
Subject: [New-bugs-announce] [issue7105] weak dict iterators are fragile
because of unpredictable GC runs
In-Reply-To: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za>
Message-ID: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
As mentioned in issue7060, weak dict iterators are easily broken by
cyclic garbage collection changing the size of the underlying dict storage:
File "/home/rdmurray/python/py3k/Lib/weakref.py", line 121, in items
for wr in self.data.values():
RuntimeError: dictionary changed size during iteration
One possible solution is to delay all removals until all iterators are
done. Here is a context manager-based solution.
----------
components: Library (Lib)
files: weakiter.patch
keywords: patch
messages: 93863
nosy: pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: weak dict iterators are fragile because of unpredictable GC runs
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15103/weakiter.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7105>
_______________________________________
From report at bugs.python.org Sun Oct 11 21:40:52 2009
From: report at bugs.python.org (Bruce vanNorman)
Date: Sun, 11 Oct 2009 19:40:52 +0000
Subject: [New-bugs-announce] [issue7106] Python crashed in the middle of an
argument between wx and boa_constructor
In-Reply-To: <1255290052.69.0.436767775927.issue7106@psf.upfronthosting.co.za>
Message-ID: <1255290052.69.0.436767775927.issue7106@psf.upfronthosting.co.za>
New submission from Bruce vanNorman <brucevannorman at gmail.com>:
I don't know where this problem truly belongs, but Python did crash.
- I was trying to save my boa project when the event occurred.
- The software & versions are correctly identified in the "bugreport"
----------
components: Extension Modules
files: python-bugreport.txt
messages: 93872
nosy: bvn
severity: normal
status: open
title: Python crashed in the middle of an argument between wx and boa_constructor
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file15104/python-bugreport.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7106>
_______________________________________
From report at bugs.python.org Sun Oct 11 21:59:58 2009
From: report at bugs.python.org (Grzegorz Adam Hankiewicz)
Date: Sun, 11 Oct 2009 19:59:58 +0000
Subject: [New-bugs-announce] [issue7107] Missing uninstallation instructions
for mac
In-Reply-To: <1255291198.67.0.155699939308.issue7107@psf.upfronthosting.co.za>
Message-ID: <1255291198.67.0.155699939308.issue7107@psf.upfronthosting.co.za>
New submission from Grzegorz Adam Hankiewicz <gradha at users.sourceforge.net>:
I've installed the official 2.6.3 dmg file of python and now want to
uninstall it to revert to the python version included by default by the
OS. I would do so if I knew what I have to remove or change.
----------
components: Installation
messages: 93873
nosy: gradha
severity: normal
status: open
title: Missing uninstallation instructions for mac
type: feature request
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7107>
_______________________________________
From report at bugs.python.org Mon Oct 12 01:33:35 2009
From: report at bugs.python.org (Meador Inge)
Date: Sun, 11 Oct 2009 23:33:35 +0000
Subject: [New-bugs-announce] [issue7108] test_commands.py failing on OS X
10.5.7 due to '@' in ls output
In-Reply-To: <1255304015.86.0.913588485284.issue7108@psf.upfronthosting.co.za>
Message-ID: <1255304015.86.0.913588485284.issue7108@psf.upfronthosting.co.za>
New submission from Meador Inge <meadori at gmail.com>:
I am testing this out of the trunk on OS X 10.5.7:
uclid:trunk minge$ uname -a
Darwin euclid.local 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31
22:52:17 PDT 2009; root:xnu-1228.12.14~1/RELEASE_I386 i386
euclid:trunk minge$ ./python.exe Lib/test/test_commands.py
test_getoutput (__main__.CommandTests) ... ok
test_getstatus (__main__.CommandTests) ... FAIL
======================================================================
FAIL: test_getstatus (__main__.CommandTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "Lib/test/test_commands.py", line 60, in test_getstatus
self.assertTrue(re.match(pat, getstatus("/."), re.VERBOSE))
AssertionError: None is not True
----------------------------------------------------------------------
Ran 2 tests in 0.047s
FAILED (failures=1)
Traceback (most recent call last):
File "Lib/test/test_commands.py", line 69, in <module>
test_main()
File "Lib/test/test_commands.py", line 64, in test_main
run_unittest(CommandTests)
File
"/Users/minge/Research/Languages/python/trunk/Lib/test/test_support.py",
line 884, in run_unittest
_run_suite(suite)
File
"/Users/minge/Research/Languages/python/trunk/Lib/test/test_support.py",
line 867, in _run_suite
raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
File "Lib/test/test_commands.py", line 60, in test_getstatus
self.assertTrue(re.match(pat, getstatus("/."), re.VERBOSE))
AssertionError: None is not True
[30608 refs]
euclid:trunk minge$ patch -p0 < test_commands.patch
patching file Lib/test/test_commands.py
euclid:trunk minge$ ./python.exe Lib/test/test_commands.py
test_getoutput (__main__.CommandTests) ... ok
test_getstatus (__main__.CommandTests) ... ok
----------------------------------------------------------------------
Ran 2 tests in 0.040s
OK
[30459 refs]
According to the OS X documentation for ls(1) [1] the output of ls can
include the '@' character to denote that file has "extended attributes".
The attached patch adjust the regex which is applied to the output of
ls to account for this fact (a more rigorous approach would have
conditioned the '@' check on OS X, but I wasn't sure if it was worth the
added complexity).
[1]
http://developer.apple.com/mac/library/DOCUMENTATION/Darwin/Reference/ManPages/man1/ls.1.html
----------
components: Tests
files: test_commands.patch
keywords: patch
messages: 93881
nosy: minge
severity: normal
status: open
title: test_commands.py failing on OS X 10.5.7 due to '@' in ls output
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file15106/test_commands.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7108>
_______________________________________
From report at bugs.python.org Mon Oct 12 09:21:42 2009
From: report at bugs.python.org (Matthias Kievernagel)
Date: Mon, 12 Oct 2009 07:21:42 +0000
Subject: [New-bugs-announce] [issue7109] broken link on news page
In-Reply-To: <1255332102.92.0.0966225576747.issue7109@psf.upfronthosting.co.za>
Message-ID: <1255332102.92.0.0966225576747.issue7109@psf.upfronthosting.co.za>
New submission from Matthias Kievernagel <mkiever at web.de>:
Hello,
there is a broken link on
http://www.python.org/news/
at
Python 3.0 is an ex-release! Long live Python 3.1!
There will be no Python 3.0.2 release or further 3.0.x maintenance/
security releases. All users of Python 3.0 are strongly encouraged to
upgrade to Python 3.1.
This link is dead (pointing at some fjord, it's an ex-link :):
http://mail.python.org/pipermail/python-list/2009-July/718561.html
Found this in the archives, guess this is the correct link:
http://mail.python.org/pipermail/python-list/2009-July/187218.html
Hope this is the right place to report website issues.
Regards,
Matthias Kievernagel
----------
components: None
messages: 93887
nosy: mkiever
severity: normal
status: open
title: broken link on news page
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7109>
_______________________________________
From report at bugs.python.org Mon Oct 12 10:08:54 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 12 Oct 2009 08:08:54 +0000
Subject: [New-bugs-announce] [issue7110] Output test failures on stderr in
regrtest.py
In-Reply-To: <1255334934.67.0.943013773261.issue7110@psf.upfronthosting.co.za>
Message-ID: <1255334934.67.0.943013773261.issue7110@psf.upfronthosting.co.za>
New submission from Ezio Melotti <ezio.melotti at gmail.com>:
regrtest.py should output all the names of the tests that fail and their
tracebacks on stderr.
This will provide an easy way to filter out the relevant information
(errors and tracebacks) from all the other outputs.
The current behavior seems incoherent, some tracebacks are sent to
stdout and other to stderr (see attached log).
----------
components: Tests
files: stdout_stderr.txt
messages: 93889
nosy: ezio.melotti
priority: normal
severity: normal
stage: needs patch
status: open
title: Output test failures on stderr in regrtest.py
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15108/stdout_stderr.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7110>
_______________________________________
From report at bugs.python.org Mon Oct 12 10:23:20 2009
From: report at bugs.python.org (Peter Eisentraut)
Date: Mon, 12 Oct 2009 08:23:20 +0000
Subject: [New-bugs-announce] [issue7111] core dump when stderr is moved
In-Reply-To: <1255335800.65.0.921782203194.issue7111@psf.upfronthosting.co.za>
Message-ID: <1255335800.65.0.921782203194.issue7111@psf.upfronthosting.co.za>
New submission from Peter Eisentraut <peter_e at gmx.net>:
bash$ python3.1 -c 'pass' 2>&-
Aborted (core dumped)
(I verified, the core dump belongs to python.)
If you remove the redirection thingy at the end, it works.
Not sure why I ever wrote that code, but it has been working since
forever up to python3.0.
----------
components: Interpreter Core
messages: 93891
nosy: petere
severity: normal
status: open
title: core dump when stderr is moved
type: crash
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7111>
_______________________________________
From report at bugs.python.org Mon Oct 12 13:56:49 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 12 Oct 2009 11:56:49 +0000
Subject: [New-bugs-announce] [issue7112] unicodetype_db.h warning: integer
constant is too large for 'long'
In-Reply-To: <1255348609.65.0.0972853196625.issue7112@psf.upfronthosting.co.za>
Message-ID: <1255348609.65.0.0972853196625.issue7112@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
I've got this warning while compiling on coLinux.
gcc -pthread -c -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I.
-IInclude
-I./Include -DPy_BUILD_CORE -o Objects/unicodectype.o
Objects/unicodectype.c
In file included from Objects/unicodectype.c:34:
Objects/unicodetype_db.h: In function '_PyUnicodeUCS2_ToNumeric':
Objects/unicodetype_db.h:2077: warning: integer constant is too large
for 'long'
type
This issue is related to issue1571184, I think.
----------
messages: 93893
nosy: ocean-city
severity: normal
status: open
title: unicodetype_db.h warning: integer constant is too large for 'long'
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7112>
_______________________________________
From report at bugs.python.org Mon Oct 12 14:43:04 2009
From: report at bugs.python.org (albert hofkamp)
Date: Mon, 12 Oct 2009 12:43:04 +0000
Subject: [New-bugs-announce] [issue7113] ConfigParser load speedup
In-Reply-To: <1255351384.96.0.56907836791.issue7113@psf.upfronthosting.co.za>
Message-ID: <1255351384.96.0.56907836791.issue7113@psf.upfronthosting.co.za>
New submission from albert hofkamp <a.t.hofkamp at tue.nl>:
Current implementation (r71564) uses "'%s\n%s' % (old_val, new_line)" to
merge multi-line options into one string.
For options with many lines, this wastes a lot of CPU power.
Attached patch against r71564 fixes this problem by first building a
list of lines for each loaded option, and after reading the whole file,
merging them with the already loaded data. In that way, the '\n'.join()
can be performed once.
Patched ConfigParser.py works against test/test_cfgparser.py (and Python
2.5)
We have witnessed a reduction from 4 hours to 3 seconds loading time
with Python 2.6 and an option of 800000 lines.
----------
components: Library (Lib)
files: speedfix_71564.patch
keywords: patch
messages: 93895
nosy: aioryi
severity: normal
status: open
title: ConfigParser load speedup
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file15109/speedfix_71564.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7113>
_______________________________________
From report at bugs.python.org Mon Oct 12 23:32:53 2009
From: report at bugs.python.org (Greg Baker)
Date: Mon, 12 Oct 2009 21:32:53 +0000
Subject: [New-bugs-announce] [issue7114] HTMLParser doesn't handle <![CDATA[
... ]]>
In-Reply-To: <1255383173.02.0.819385756545.issue7114@psf.upfronthosting.co.za>
Message-ID: <1255383173.02.0.819385756545.issue7114@psf.upfronthosting.co.za>
New submission from Greg Baker <ggbaker at sfu.ca>:
I believe what I'm seeing here is somewhat related to issue 670664, but
is easier to handle because of the CDATA structure. Basically,
HTMLParser doesn't recognize CDATA sections at all, so their content is
incorrectly parsed like normal data.
The following is an attempt to parse (a snippet of) valid XHTML, but it
raises an HTMLParseError.
data = """<script type="text/javascript">
//<![CDATA[
function foo() {
document.write('"></' + 'script>');}
//]]>
</script>"""
from HTMLParser import HTMLParser
parser = HTMLParser()
parser.feed(data)
----------
components: Library (Lib)
messages: 93905
nosy: ggbaker
severity: normal
status: open
title: HTMLParser doesn't handle <![CDATA[ ... ]]>
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7114>
_______________________________________
From report at bugs.python.org Tue Oct 13 00:33:04 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 12 Oct 2009 22:33:04 +0000
Subject: [New-bugs-announce] [issue7115] extension module builds fail when
using paths in the extension name
In-Reply-To: <1255386784.29.0.0870710106996.issue7115@psf.upfronthosting.co.za>
Message-ID: <1255386784.29.0.0870710106996.issue7115@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
This change shows a regression (https://bugs.launchpad.net/bugs/449734),
the setup.py file might not be correct, but it did work before this
change (with plain distutils). Quoting from the report:
Set setup.py file looks like this:
setup(name='update-manager',
...
ext_modules=[Extension('UpdateManager/fdsend',
['UpdateManager/fdsend/fdsend.c'])],
...
With 2.6.4~rc1 the logs read:
copying build/lib.linux-x86_64-2.6/fdsend.so ->
/tmp/buildd/update-manager-0.126.1/debian/tmp/usr/lib/python2.6/dist-packages
With 2.6.3:
copying build/lib.linux-x86_64-2.6/UpdateManager/fdsend.so ->
/home/egon/devel/update-manager/checkout/build-area/update-manager-0.126.1/debian/tmp/usr/lib/python2.6/dist-packages/UpdateManager
So it looks like python is eating a prefix.
http://bugs.python.org/issue7064
is why this change was made.
Reading that, it was done because setuptools assumes that the method
is always called with the full dotted name, when it was just being called
with the last part of it.
However, update-manager isn't using a dotted module path anyway, it's
passing a path.
http://docs.python.org/distutils/setupscript.html#extension-names-and-packages
shows that you would be expected to use
ext_modules=[Extension('UpdateManager.fdsend',
['UpdateManager/fdsend/fdsend.c'])],
(note . not / in the first line)
----------
assignee: tarek
components: Distutils
messages: 93908
nosy: barry, doko, tarek
priority: release blocker
severity: normal
status: open
title: extension module builds fail when using paths in the extension name
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7115>
_______________________________________
From report at bugs.python.org Tue Oct 13 00:37:41 2009
From: report at bugs.python.org (Jess Austin)
Date: Mon, 12 Oct 2009 22:37:41 +0000
Subject: [New-bugs-announce] [issue7116] str.join() should be documented as
taking an iterable
In-Reply-To: <1255387061.17.0.69385266786.issue7116@psf.upfronthosting.co.za>
Message-ID: <1255387061.17.0.69385266786.issue7116@psf.upfronthosting.co.za>
New submission from Jess Austin <jess.austin at gmail.com>:
In its __doc__ string and in the documentation, str.join() is described
as taking a sequence. This is not general enough; it actually takes any
iterable of strings:
>>> ','.join(str(x) for x in range(5))
'0,1,2,3,4'
Maybe this is a small nit to pick, but it slowed me down for a few
minutes, and I already vaguely remembered that str.join() could handle
iterables.
----------
assignee: georg.brandl
components: Documentation, Interpreter Core
messages: 93909
nosy: georg.brandl, jess.austin
severity: normal
status: open
title: str.join() should be documented as taking an iterable
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7116>
_______________________________________
From report at bugs.python.org Tue Oct 13 10:30:27 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Oct 2009 08:30:27 +0000
Subject: [New-bugs-announce] [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
See the thread starting at:
http://mail.python.org/pipermail/python-dev/2009-October/092958.html
Eric suggested that we don't need a separate branch for this; sounds
fine to me. It should still be possible to do the backport in stages,
though. Something like the following?
(1) Check in David Gay's code plus necessary build changes,
configuration steps, etc; conversions still use the old code.
(2) Switch to using the new code for float -> string (str, repr, float
formatting) and string -> float conversions (float, complex
constructors, numeric literals in Python code). [Substeps?]
(3) Fix up builtin round function to use the new code.
(4) Make any necessary fixes to the documentation. (Raymond, I assume
you'll take care of the whatsnew changes when the time comes?)
(1), (3) and (4) should be straightforward. (2) is where most of the
work is, I think. I think it should be possible to do the stage (2)
work in pieces without breaking too much.
----------
assignee: mark.dickinson
components: Interpreter Core
messages: 93918
nosy: eric.smith, mark.dickinson, rhettinger
priority: normal
severity: normal
status: open
title: Backport py3k float repr to trunk
type: feature request
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________
From report at bugs.python.org Tue Oct 13 16:19:48 2009
From: report at bugs.python.org (Gerald Thaler)
Date: Tue, 13 Oct 2009 14:19:48 +0000
Subject: [New-bugs-announce] [issue7118] urllib2.urlopen() timeout argument
ignored after redirect
In-Reply-To: <1255443588.46.0.439555512733.issue7118@psf.upfronthosting.co.za>
Message-ID: <1255443588.46.0.439555512733.issue7118@psf.upfronthosting.co.za>
New submission from Gerald Thaler <gerald at netestate.de>:
When a HTTP request done with urllib2.urlopen() gets redirected, the
second request will ignore the given timeout value and may hang
indefinitely.
----------
messages: 93922
nosy: gthaler
severity: normal
status: open
title: urllib2.urlopen() timeout argument ignored after redirect
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7118>
_______________________________________
From report at bugs.python.org Tue Oct 13 20:58:06 2009
From: report at bugs.python.org (Jon Nelson)
Date: Tue, 13 Oct 2009 18:58:06 +0000
Subject: [New-bugs-announce] [issue7119] email: msg.items() returns
different values before and after msg.as_string()
In-Reply-To: <1255460286.78.0.388078271026.issue7119@psf.upfronthosting.co.za>
Message-ID: <1255460286.78.0.388078271026.issue7119@psf.upfronthosting.co.za>
New submission from Jon Nelson <jnelson at users.sourceforge.net>:
import os
try:
from email.mime.multipart import MIMEMultipart
except ImportError:
from email.MIMEMultipart import MIMEMultipart
m = MIMEMultipart('form-data')
print m.items()
m.as_string()
print m.items()
print out:
[('Content-Type', 'multipart/form-data'), ('MIME-Version', '1.0')]
[('Content-Type', 'multipart/form-data;
boundary="===============0836597002796039051=="'), ('MIME-Version', '1.0')]
The latter is correct, the former is not - it is missing the boundary!
items() should behave the same regardless of whether or not as_string()
has been called.
Confirmed in 2.4 and 2.6
----------
components: Library (Lib)
messages: 93935
nosy: jnelson
severity: normal
status: open
title: email: msg.items() returns different values before and after msg.as_string()
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7119>
_______________________________________
From report at bugs.python.org Wed Oct 14 03:04:06 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 14 Oct 2009 01:04:06 +0000
Subject: [New-bugs-announce] [issue7120] 2.6.4rc1 regression
In-Reply-To: <1255482246.24.0.333134064437.issue7120@psf.upfronthosting.co.za>
Message-ID: <1255482246.24.0.333134064437.issue7120@psf.upfronthosting.co.za>
New submission from Guido van Rossum <guido at python.org>:
Following my own (Twitter) advice I downloaded the 2.6.4rc1 release
candidate and installed it on my x86 iMac running OS X 10.5.8, and tried
to run a Google App Engine app with it. Google App Engine prefers Python
2.5, but so far it has always worked with 2.6 as well, modulo 1-2
warnings. But not 2.6.4rc1! Even on a trivial app I get "RuntimeError:
maximum recursion depth exceeded". I'm attaching a file with the
traceback (repetitive stuff elided).
I'd be happy to provide more details if they are needed to reproduce. I'm
using the Google App Engine SDK 1.2.6.
----------
components: Library (Lib)
files: traceback.txt
messages: 93952
nosy: gvanrossum
severity: normal
status: open
title: 2.6.4rc1 regression
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file15120/traceback.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7120>
_______________________________________
From report at bugs.python.org Wed Oct 14 06:57:09 2009
From: report at bugs.python.org (mike)
Date: Wed, 14 Oct 2009 04:57:09 +0000
Subject: [New-bugs-announce] [issue7121] ImportError of urllib.request &
http.client under PYTHONHOME/Lib
In-Reply-To: <1255496229.06.0.897594759505.issue7121@psf.upfronthosting.co.za>
Message-ID: <1255496229.06.0.897594759505.issue7121@psf.upfronthosting.co.za>
New submission from mike <mikezp59 at gmail.com>:
There's a python program in the attached file http.py, I import
urllib.request in http.py, and urllib.request imports http.client.
When I try to run http.py by command "python http.py", the error is as
below:
Traceback (most recent call last):
File "http.py", line 4, in <module>
import urllib.request
File "C:\Program Files\Python311\lib\urllib\request.py", line 86, in
<module>
import http.client
File "D:\program\python\http.py", line 6, in <module>
response = urllib.request.urlopen('http://python.org/')
AttributeError: 'module' object has no attribute 'request'
However, if I copy http.py to directory PYTHONHOME/Lib and run
command "python http.py" under directory PYTHONHOME/Lib, it works
successfully; if you move it to other directories and run the command,
the error will be returned.
Note: the source code of http.py is copied from python311.chm under
directory PYTHONHOME/Doc.
----------
components: Library (Lib)
files: http.py
messages: 93965
nosy: mikezp59
severity: normal
status: open
title: ImportError of urllib.request & http.client under PYTHONHOME/Lib
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file15121/http.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7121>
_______________________________________
From report at bugs.python.org Wed Oct 14 13:42:49 2009
From: report at bugs.python.org (Alex)
Date: Wed, 14 Oct 2009 11:42:49 +0000
Subject: [New-bugs-announce] [issue7122] multiprocessing.Pool() problem in
windows
In-Reply-To: <1255520569.54.0.664062974628.issue7122@psf.upfronthosting.co.za>
Message-ID: <1255520569.54.0.664062974628.issue7122@psf.upfronthosting.co.za>
New submission from Alex <nabrozidhs at gmail.com>:
Maybe I didn't understand how multiprocessing works but when running the
test code below I get 200+ processes in Windows and it never finishes.
It works fine on Linux.
----------
components: Library (Lib)
files: prueba.py
messages: 93975
nosy: SirLalala
severity: normal
status: open
title: multiprocessing.Pool() problem in windows
versions: Python 2.6
Added file: http://bugs.python.org/file15123/prueba.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7122>
_______________________________________
From report at bugs.python.org Wed Oct 14 14:14:52 2009
From: report at bugs.python.org (Peter Saunders)
Date: Wed, 14 Oct 2009 12:14:52 +0000
Subject: [New-bugs-announce] [issue7123] Multiprocess Process does not
always exit when run from a thread.
In-Reply-To: <1255522492.52.0.0352108851469.issue7123@psf.upfronthosting.co.za>
Message-ID: <1255522492.52.0.0352108851469.issue7123@psf.upfronthosting.co.za>
New submission from Peter Saunders <pajs at fodder.org.uk>:
I have an example code that works fine on Python 2.6.3, but when run in
Python 3.1.1 - after a very short period of time, will go wrong.
Summary:
We have a queue, and when the queue has something in it (a list), we
start a thread to deal with that entry.
The thread then runs a Process for every entry in the list we popped off
the queue. The Process target takes a Pipe, and it sends "True" back
down the pipe, and then exits. However, this Process never goes defunct,
and thus the Thread that started the Process never reaps it. When doing
a truss on the Process, it sits there in:
lwp_park(0x00000000, 0) (sleeping...)
----------
files: testing.py
messages: 93978
nosy: pajs at fodder.org.uk
severity: normal
status: open
title: Multiprocess Process does not always exit when run from a thread.
versions: Python 3.1
Added file: http://bugs.python.org/file15124/testing.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7123>
_______________________________________
From report at bugs.python.org Wed Oct 14 14:34:05 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Wed, 14 Oct 2009 12:34:05 +0000
Subject: [New-bugs-announce] [issue7124] idle.py -n : help() doesn't work in
a reopened shell window
In-Reply-To: <1255523645.12.0.980684749685.issue7124@psf.upfronthosting.co.za>
Message-ID: <1255523645.12.0.980684749685.issue7124@psf.upfronthosting.co.za>
New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:
The following procedure reveals a problem with help:
1) Start IDLE with -n option (no subprocess)
2) Create a script (e. g. helloworld one-liner
3) Run script
4) Close Shell Window
5) Via Menu: Run | Python Shell reopen Shell window
6) >>> help(print)
Help on ...
...
end: string appended after the last value, default a newline.
Traceback (most recent call last):
File "<pyshell#0>", line 1, in <module>
help(print)
File "C:\Python31\lib\site.py", line 429, in __call__
return pydoc.help(*args, **kwds)
File "C:\Python31\lib\pydoc.py", line 1710, in __call__
self.help(request)
File "C:\Python31\lib\pydoc.py", line 1758, in help
self.output.write('\n')
File "C:\Python31\lib\idlelib\PyShell.py", line 1231, in write
self.shell.write(s, self.tags)
File "C:\Python31\lib\idlelib\PyShell.py", line 1212, in write
self.text.mark_gravity("iomark", "right")
AttributeError: 'NoneType' object has no attribute 'mark_gravity'
>>>
So in a re-opened Shell-Window in an IDLE in -n mode, help() doesn't
work correctly.
Regards,
Gregor
----------
components: IDLE
messages: 93980
nosy: gregorlingl
severity: normal
status: open
title: idle.py -n : help() doesn't work in a reopened shell window
type: behavior
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7124>
_______________________________________
From report at bugs.python.org Wed Oct 14 16:18:45 2009
From: report at bugs.python.org (Yinon Ehrlich)
Date: Wed, 14 Oct 2009 14:18:45 +0000
Subject: [New-bugs-announce] [issue7125] typo (English) in threading.py
In-Reply-To: <1255529925.22.0.614824582196.issue7125@psf.upfronthosting.co.za>
Message-ID: <1255529925.22.0.614824582196.issue7125@psf.upfronthosting.co.za>
New submission from Yinon Ehrlich <yinoneh at users.sourceforge.net>:
threading.py line 122:
"cannot release un-aquired lock" --> "cannot release un-acquired lock"
----------
components: Library (Lib)
messages: 93989
nosy: Yinon
severity: normal
status: open
title: typo (English) in threading.py
versions: Python 2.4, Python 2.5, 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/issue7125>
_______________________________________
From report at bugs.python.org Wed Oct 14 17:09:38 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 14 Oct 2009 15:09:38 +0000
Subject: [New-bugs-announce] [issue7126] Contradictory documentation for
os.putenv and os.system
In-Reply-To: <1255532978.01.0.913860500332.issue7126@psf.upfronthosting.co.za>
Message-ID: <1255532978.01.0.913860500332.issue7126@psf.upfronthosting.co.za>
New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:
The documentation for os.putenv states that "changes to the environment
affect subprocesses started with os.system(), popen() or fork() and
execv()" and "assignments to items in os.environ are automatically
translated into corresponding calls to putenv()".
However, the documentation for os.system() states "Changes to os.environ
... are not reflected in the environment of the executed command."
A simple test confirms that the os.putenv documentation is the correct one:
Python 2.6
>>> import os
>>> os.environ['foo'] = 'bar'
>>> os.system('echo $foo')
bar
0
>>>
----------
assignee: georg.brandl
components: Documentation
messages: 93994
nosy: georg.brandl, stutzbach
severity: normal
status: open
title: Contradictory documentation for os.putenv and os.system
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/issue7126>
_______________________________________
From report at bugs.python.org Wed Oct 14 18:07:03 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 14 Oct 2009 16:07:03 +0000
Subject: [New-bugs-announce] [issue7127] regrtest -j fails when tests write
to stderr
In-Reply-To: <1255536423.67.0.1834189118.issue7127@psf.upfronthosting.co.za>
Message-ID: <1255536423.67.0.1834189118.issue7127@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
If a test writes to stderr, then the -j (multiprocessing) support in
regrtest fails to correctly extract the JSON data from the test output,
resulting in a JSON traceback followed by a failure of the worker
thread. Antoine has suggested tagging the JSON result string with a
prefix and looking for that prefix, instead of the current method (which
assumes that the JSON result string is at the end of the output from the
test).
----------
components: Tests
keywords: easy
messages: 94003
nosy: pitrou, r.david.murray
priority: low
severity: normal
stage: needs patch
status: open
title: regrtest -j fails when tests write to stderr
type: behavior
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7127>
_______________________________________
From report at bugs.python.org Wed Oct 14 18:12:34 2009
From: report at bugs.python.org (Joseph C Wang)
Date: Wed, 14 Oct 2009 16:12:34 +0000
Subject: [New-bugs-announce] [issue7128] cPickle looking for non-existent
package copyreg
In-Reply-To: <1255536754.55.0.971036296539.issue7128@psf.upfronthosting.co.za>
Message-ID: <1255536754.55.0.971036296539.issue7128@psf.upfronthosting.co.za>
New submission from Joseph C Wang <joequant at gmail.com>:
When running cPickle in restricted mode, the module tries to import
copyreg which does not appear to exist anywhere. The problem is in
cPickle.c
2980 if (PyEval_GetRestricted()) {
2981 /* Restricted execution, get private tables */
2982 PyObject *m = PyImport_Import(copyreg_str);
2983
2984 if (m == NULL)
2985 goto err;
2986 self->dispatch_table = PyObject_GetAttr(m, dispatch_table_str);
2987 Py_DECREF(m);
2988 if (self->dispatch_table == NULL)
2989 goto err;
2990 }
2991 else {
2992 self->dispatch_table = dispatch_table;
2993 Py_INCREF(dispatch_table);
2994 }
copyreg_str should probably be copy_reg_str
----------
components: Interpreter Core
messages: 94004
nosy: joequant
severity: normal
status: open
title: cPickle looking for non-existent package copyreg
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7128>
_______________________________________
From report at bugs.python.org Wed Oct 14 20:33:01 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Wed, 14 Oct 2009 18:33:01 +0000
Subject: [New-bugs-announce] [issue7129] 'filling' missing in __all__
In-Reply-To: <1255545181.33.0.710014899763.issue7129@psf.upfronthosting.co.za>
Message-ID: <1255545181.33.0.710014899763.issue7129@psf.upfronthosting.co.za>
New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:
By oversight the turtle graphics function filling is missing in the
__all__ list which is composed by several parts, among them
_tg_turtle_functions.
So 'filling' has to be added to _tg_turtle_functions
a path is attached
----------
components: Library (Lib)
files: filling-bug.diff
keywords: patch
messages: 94007
nosy: georg.brandl, gregorlingl, loewis
severity: normal
status: open
title: 'filling' missing in __all__
type: resource usage
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15128/filling-bug.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7129>
_______________________________________
From report at bugs.python.org Wed Oct 14 20:54:04 2009
From: report at bugs.python.org (Dino Viehland)
Date: Wed, 14 Oct 2009 18:54:04 +0000
Subject: [New-bugs-announce] [issue7130] json uses sre_* modules which may
not work on alternate implemenations
In-Reply-To: <1255546444.41.0.18277225487.issue7130@psf.upfronthosting.co.za>
Message-ID: <1255546444.41.0.18277225487.issue7130@psf.upfronthosting.co.za>
New submission from Dino Viehland <dinov at microsoft.com>:
Currently the json module is using the sre_* modules to construct it's
regular expressions instead of just using the re module directly.
Because of this it's taking a dependency on what would appear to be
CPython specific implementation details (sre_* appear to be
undocumented) and a deprecated module. The end result is that json
decoding doesn't work on IronPython and may not work on other Python
implementations.
----------
components: Library (Lib)
messages: 94010
nosy: DinoV
severity: normal
status: open
title: json uses sre_* modules which may not work on alternate implemenations
type: behavior
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7130>
_______________________________________
From report at bugs.python.org Wed Oct 14 21:18:43 2009
From: report at bugs.python.org (Dieter Verfaillie)
Date: Wed, 14 Oct 2009 19:18:43 +0000
Subject: [New-bugs-announce] [issue7131] Extension module build fails for
MinGW: missing vcvarsall.bat
In-Reply-To: <1255547923.17.0.905503258872.issue7131@psf.upfronthosting.co.za>
Message-ID: <1255547923.17.0.905503258872.issue7131@psf.upfronthosting.co.za>
New submission from Dieter Verfaillie <dieterv at optionexplicit.be>:
Using Python 2.6.3 on Windows XP, distutils fails building an extension
module when mingw32 is specified as the compiler. Distutils fails with
the error message "Unable to find vcvarsall.bat".
Looking back in the subversion history for the distutils build_ext
command
(http://svn.python.org/view/python/tags/r263/Lib/distutils/command/build_ext.py?view=log)
I've found that line 306 has been changed in revision 72594 to read:
self.compiler = new_compiler(compiler=None,
reverting back to revision 72586, so the code reads:
self.compiler = new_compiler(compiler=self.compiler,
seems to fix the problem.
----------
assignee: tarek
components: Distutils, Windows
messages: 94014
nosy: dieterv, tarek
severity: normal
status: open
title: Extension module build fails for MinGW: missing vcvarsall.bat
type: compile error
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7131>
_______________________________________
From report at bugs.python.org Wed Oct 14 22:08:16 2009
From: report at bugs.python.org (Philippe Verdy)
Date: Wed, 14 Oct 2009 20:08:16 +0000
Subject: [New-bugs-announce] [issue7132] Regexp: capturing groups in
repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
New submission from Philippe Verdy <verdy_p at wanadoo.fr>:
For now, when capturing groups are used within repetitions, it is impossible to capure what they match
individually within the list of matched repetitions.
E.g. the following regular expression:
(0|1[0-9]{0,2}|2(?:[0-4][0-9]?|5[0-5]?)?)(?:\.(0|1[0-9]{0,2}|2(?:[0-4][0-9]?|5[0-5]?)?)){3}
is a regexp that contains two capturing groups (\1 and \2), but whose the second one is repeated (3 times) to
match an IPv4 address in dotted decimal format. We'd like to be able to get the individual multiple matchs
for the second group.
For now, capturing groups don't record the full list of matches, but just override the last occurence of the
capturing group (or just the first if the repetition is not greedy, which is not the case here because the
repetition "{3}" is not followed by a "?"). So \1 will effectively return the first decimal component of the
IPv4 address, but \2 will just return the last (fourth) decimal component.
I'd like to have the possibility to have a compilation flag "R" that would indicate that capturing groups
will not just return a single occurence, but all occurences of the same group. If this "R" flag is enabled,
then:
- the Match.group(index) will not just return a single string but a list of strings, with as many occurences
as the number of effective repetitions of the same capturing group. The last element in that list will be the
one equal to the current behavior
- the Match.start(index) and Match.end(index) will also both return a list of positions, those lists having
the same length as the list returned by Match.group(index).
- for consistency, the returned values as lists of strings (instead of just single strings) will apply to all
capturing groups, even if they are not repeated.
Effectively, with the same regexp above, we will be able to retreive (and possibily substitute):
- the first decimal component of the IPv4 address with "{\1:1}" (or "{\1:}" or "{\1}" or "\1" as before),
i.e. the 1st (and last) occurence of capturing group 1, or in Match.group(1)[1], or between string positions Match.start(1)[1] and Match.end(1)[1] ;
- the second decimal component of the IPv4 address with "{\2:1}", i.e. the 1st occurence of capturing group
2, or in Match.group(2)[1], or between string positions Match.start(2)[1] and Match.end(2)[1] ;
- the third decimal component of the IPv4 address with "{\2:2}", i.e. the 2nd occurence of capturing group 2,
or in Match.group(2)[2], or between string positions Match.start(2)[2] and Match.end(2)[2] ;
- the fourth decimal component of the IPv4 address with "{\2:3}" (or "{\2:}" or "{\2}" or "\2"), i.e. the 3rd
(and last) occurence of capturing group 2, or in Match.group(2)[2], or between string positions
Match.start(2)[3] and Match.end(2)[3] ;
This should work with all repetition patterns (both greedy and not greedy, atomic or not, or possessive), in
which the repeated pattern contains any capturing group.
This idea should also be submitted to the developers of the PCRE library (and Perl from which they originate,
and PHP where PCRE is also used), so that they adopt a similar behavior in their regular expressions.
If there's already a candidate syntax or compilation flag in those libraries, this syntax should be used for
repeated capturing groups.
----------
components: Library (Lib)
messages: 94022
nosy: verdy_p
severity: normal
status: open
title: Regexp: capturing groups in repetitions
type: feature request
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________
From report at bugs.python.org Thu Oct 15 00:41:12 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Oct 2009 22:41:12 +0000
Subject: [New-bugs-announce] [issue7133] test_ssl failure
In-Reply-To: <1255560072.28.0.0342134369979.issue7133@psf.upfronthosting.co.za>
Message-ID: <1255560072.28.0.0342134369979.issue7133@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
This is due to r75412 (yes, mine). The proper fix would be to add
support for the new buffer API to the _ssl module.
testSocketServer (test.test_ssl.ThreadedTests) ...
server (('127.0.0.1', 52011):52011 ('AES256-SHA', 'TLSv1/SSLv3', 256)):
[15/Oct/2009 00:42:18] "GET /keycert.pem HTTP/1.0" 200 -
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 48099)
Traceback (most recent call last):
File "/home/antoine/cpython/__svn__/Lib/SocketServer.py", line 282, in
_handle_request_noblock
self.process_request(request, client_address)
File "/home/antoine/cpython/__svn__/Lib/SocketServer.py", line 308, in
process_request
self.finish_request(request, client_address)
File "/home/antoine/cpython/__svn__/Lib/SocketServer.py", line 321, in
finish_request
self.RequestHandlerClass(request, client_address, self)
File "/home/antoine/cpython/__svn__/Lib/SocketServer.py", line 639, in
__init__
self.finish()
File "/home/antoine/cpython/__svn__/Lib/SocketServer.py", line 692, in
finish
self.wfile.flush()
File "/home/antoine/cpython/__svn__/Lib/socket.py", line 300, in flush
self._sock.sendall(view[write_offset:write_offset+buffer_size])
File "/home/antoine/cpython/__svn__/Lib/ssl.py", line 203, in sendall
v = self.send(data[count:])
File "/home/antoine/cpython/__svn__/Lib/ssl.py", line 94, in <lambda>
self.send = lambda data, flags=0: SSLSocket.send(self, data, flags)
File "/home/antoine/cpython/__svn__/Lib/ssl.py", line 174, in send
v = self._sslobj.write(data)
TypeError: must be string or read-only buffer, not memoryview
----------------------------------------
Traceback (most recent call last):
File "/home/antoine/cpython/__svn__/Lib/test/test_ssl.py", line 972,
in testSocketServer
f = urllib.urlopen(url)
File "/home/antoine/cpython/__svn__/Lib/urllib.py", line 87, in urlopen
return opener.open(url)
File "/home/antoine/cpython/__svn__/Lib/urllib.py", line 206, in open
return getattr(self, name)(url)
File "/home/antoine/cpython/__svn__/Lib/urllib.py", line 445, in
open_https
'got a bad status line', None)
IOError: ('http protocol error', 0, 'got a bad status line', None)
ERROR
----------
assignee: pitrou
components: Extension Modules, Tests
messages: 94044
nosy: janssen, pitrou
severity: normal
stage: needs patch
status: open
title: test_ssl failure
type: behavior
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7133>
_______________________________________
From report at bugs.python.org Thu Oct 15 01:40:04 2009
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 14 Oct 2009 23:40:04 +0000
Subject: [New-bugs-announce] [issue7134] Add looping capability to regrtest
In-Reply-To: <1255563604.05.0.373635467839.issue7134@psf.upfronthosting.co.za>
Message-ID: <1255563604.05.0.373635467839.issue7134@psf.upfronthosting.co.za>
New submission from Jesse Noller <jnoller at gmail.com>:
We should add "loop this test" capabilities to regrtest - running tests in
a tight loop can help debug issues which don't appear with a one-off run.
See:
http://mail.python.org/pipermail/python-dev/2009-June/090238.html
----------
assignee: jnoller
components: Tests
messages: 94052
nosy: jnoller
priority: normal
severity: normal
status: open
title: Add looping capability to regrtest
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7134>
_______________________________________
From report at bugs.python.org Thu Oct 15 01:49:32 2009
From: report at bugs.python.org (Andi Welch)
Date: Wed, 14 Oct 2009 23:49:32 +0000
Subject: [New-bugs-announce] [issue7135] AttributeError: 'module' object has
no attribute 'HTTPSConnection'
In-Reply-To: <1255564172.76.0.168636291219.issue7135@psf.upfronthosting.co.za>
Message-ID: <1255564172.76.0.168636291219.issue7135@psf.upfronthosting.co.za>
New submission from Andi Welch <andiwelch at gmail.com>:
I received a working script created with Active Python 2.6.2 for
Windows 32 bit. I downloaded the Active Python 64 bit Windows version
for my 64 bit Windows Vista OS and have attempted to run the script. I
get the following error:
Traceback (most recent call last):
File "ofx-ba-tfb-auto.py", line 212, in
client.doQuery(query, argv[1]+"_acct.ofx")
File "ofx-ba-tfb-auto.py", line 178, in doQuery
h = httplib.HTTPSConnection(host)
AttributeError: 'module' object has no attribute 'HTTPSConnection'
I see a few references (not on this site) to the error, but none seem
to fit exactly and being a Python novice I wasn't sure what direction
to turn. Most suggest that my Python installation is missing a needed
library to support SSL. I also tried using the 2.6.3.7 version of
Active Python for WIN 64 and get the same exact error.
Would appreciate any and all assistance. Thank you.
----------
components: Library (Lib)
messages: 94055
nosy: awelch
severity: normal
status: open
title: AttributeError: 'module' object has no attribute 'HTTPSConnection'
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7135>
_______________________________________
From report at bugs.python.org Thu Oct 15 02:40:44 2009
From: report at bugs.python.org (Toby Donaldson)
Date: Thu, 15 Oct 2009 00:40:44 +0000
Subject: [New-bugs-announce] [issue7136] Idle File Menu Option Improvement
In-Reply-To: <1255567244.32.0.288243785856.issue7136@psf.upfronthosting.co.za>
Message-ID: <1255567244.32.0.288243785856.issue7136@psf.upfronthosting.co.za>
New submission from Toby Donaldson <tjdonaldson at gmail.com>:
I've been using Idle to teach beginning programming to university
students for the last 6 or 7 years. I've taught hundreds and hundreds of
students, and the single biggest confusion with Idle is this:
"New Window" in the file menu is ambiguous
Proposed fix: change "New Window" to "New File", or "New Program"
Many beginners don't get the difference between a shell window and
program window. I spend some time explaining the difference, and yet
they see "New Window" and don't know if this means a shell window or
program window.
Obviously this is not an issue for non-beginners, or even for anyone
willing to experiment for a minute or two, but it seems to me this is a
small change that could be useful to beginners.
Plus more precise menu options are usually a good thing in general.
----------
components: IDLE
messages: 94064
nosy: tjd
severity: normal
status: open
title: Idle File Menu Option Improvement
type: feature request
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7136>
_______________________________________
From report at bugs.python.org Thu Oct 15 05:25:56 2009
From: report at bugs.python.org (Yang Zhang)
Date: Thu, 15 Oct 2009 03:25:56 +0000
Subject: [New-bugs-announce] [issue7137] Socket documentation not updated
In-Reply-To: <1255577156.35.0.86012229105.issue7137@psf.upfronthosting.co.za>
Message-ID: <1255577156.35.0.86012229105.issue7137@psf.upfronthosting.co.za>
New submission from Yang Zhang <yaaang at gmail.com>:
e.g., the doc still says socket.makefile([mode[, bufsize]]), which aren't
the actual python3 params.
----------
assignee: georg.brandl
components: Documentation
messages: 94070
nosy: georg.brandl, yang
severity: normal
status: open
title: Socket documentation not updated
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7137>
_______________________________________
From report at bugs.python.org Thu Oct 15 07:37:32 2009
From: report at bugs.python.org (Ryan Williams)
Date: Thu, 15 Oct 2009 05:37:32 +0000
Subject: [New-bugs-announce] [issue7138] elementtree segfaults on invalid
xml declaration
In-Reply-To: <1255585052.13.0.483709817013.issue7138@psf.upfronthosting.co.za>
Message-ID: <1255585052.13.0.483709817013.issue7138@psf.upfronthosting.co.za>
New submission from Ryan Williams <rdw at lindenlab.com>:
This crash is surprisingly consistent across versions, operating
systems, and whether the c module is used or not:
Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree.cElementTree import fromstring
>>> fromstring('<?xml \xcb\x8c ?>')
Segmentation fault
Python 2.5.4 (r254:67916, Jun 3 2009, 14:22:10)
[GCC 4.0.1 (Apple Inc. build 5488)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree.ElementTree import fromstring
>>> fromstring('<?xml \xcb\x8c ?>')
Segmentation fault
Python 2.4.4 (#2, Oct 22 2008, 20:20:22)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from elementtree.ElementTree import fromstring
>>> fromstring('<?xml \xcb\x8c ?>')
Segmentation fault
Python 2.5 (release25-maint, Jul 23 2008, 18:15:29)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree.ElementTree import fromstring
>>> fromstring('<?xml \xcb\x8c ?>')
Segmentation fault
Python 2.5.2 (r252:60911, Jan 4 2009, 17:40:26)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree.ElementTree import fromstring
>>> fromstring('<?xml \xcb\x8c ?>')
Segmentation fault
I'm a little fuzzy on who's responsible for elementtree, so if there's a
more appropriate venue to file this bug, please let me know.
----------
components: Library (Lib)
messages: 94073
nosy: whichlinden
severity: normal
status: open
title: elementtree segfaults on invalid xml declaration
type: crash
versions: Python 2.4, Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7138>
_______________________________________
From report at bugs.python.org Thu Oct 15 08:21:30 2009
From: report at bugs.python.org (Moriyoshi Koizumi)
Date: Thu, 15 Oct 2009 06:21:30 +0000
Subject: [New-bugs-announce] [issue7139] Incorrect serialization of
end-of-line characters in attribute values
In-Reply-To: <1255587690.83.0.0369111720877.issue7139@psf.upfronthosting.co.za>
Message-ID: <1255587690.83.0.0369111720877.issue7139@psf.upfronthosting.co.za>
New submission from Moriyoshi Koizumi <mozo+python at mozo.jp>:
ElementTree doesn't correctly serialize end-of-line characters (#xa,
#xd) in attribute values. Since bare end-of-line characters are
converted to #x20 by the parser according to the specification [1], such
characters that are represented as character references in the original
document must be serialized in the same form.
[1] http://www.w3.org/TR/xml11/#AVNormalize
### sample code
from xml.etree.ElementTree import ElementTree
from cStringIO import StringIO
# builder = ElementTree(file=StringIO("<foo>\x0d</foo>"))
# out = StringIO()
# builder.write(out)
# print out.getvalue()
out = StringIO()
ElementTree(file=StringIO(
'''<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE foo [
<!ELEMENT foo (#PCDATA)>
<!ATTLIST foo attr CDATA "">
]>
<foo attr=" test
test  test a "> </foo>
''')).write(out)
# should be "<foo attr=" test test test a ">\x0a</foo>
print out.getvalue()
out = StringIO()
ElementTree(file=StringIO(
'''<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE foo [
<!ELEMENT foo (#PCDATA)>
<!ATTLIST foo attr NMTOKENS "">
]>
<foo attr=" test
test  test a "> </foo>
''')).write(out)
# should be "<foo attr="test test test a">\x0a</foo>
print out.getvalue()
----------
components: XML
messages: 94074
nosy: moriyoshi
severity: normal
status: open
title: Incorrect serialization of end-of-line characters in attribute values
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7139>
_______________________________________
From report at bugs.python.org Thu Oct 15 13:24:52 2009
From: report at bugs.python.org (Jamie Kirkpatrick)
Date: Thu, 15 Oct 2009 11:24:52 +0000
Subject: [New-bugs-announce] [issue7140] imp.new_module does not function
correctly if the module is returned from a function and used
directly
In-Reply-To: <1255605892.23.0.543488610886.issue7140@psf.upfronthosting.co.za>
Message-ID: <1255605892.23.0.543488610886.issue7140@psf.upfronthosting.co.za>
New submission from Jamie Kirkpatrick <jkp at kirkconsulting.co.uk>:
See the testcase included. If you instead assign the result of the
get_module() call to a variable and then make the call to the function
defined in that module it works as expected.
----------
components: Library (Lib)
files: testcase.py
messages: 94082
nosy: jkp
severity: normal
status: open
title: imp.new_module does not function correctly if the module is returned from a function and used directly
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file15133/testcase.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7140>
_______________________________________
From report at bugs.python.org Thu Oct 15 17:28:34 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 15 Oct 2009 15:28:34 +0000
Subject: [New-bugs-announce] [issue7141] 2to3 should add from __future__
import print_statement
In-Reply-To: <1255620514.04.0.970254237923.issue7141@psf.upfronthosting.co.za>
Message-ID: <1255620514.04.0.970254237923.issue7141@psf.upfronthosting.co.za>
New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:
I'm in the process of converting several Python scripts so that they
work under both Python 2.6 and 3.1. For the most part, 2to3 does an
amazing job. Great tool.
One little feature request: could we make it add "from __future__ import
print_statement" to the top of files?
That one change is enough to make >95% of my converted scripts work fine
under 2.6 and 3.1 instead of just 3.1.
----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 94093
nosy: stutzbach
severity: normal
status: open
title: 2to3 should add from __future__ import print_statement
type: feature request
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7141>
_______________________________________
From report at bugs.python.org Thu Oct 15 17:44:00 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Oct 2009 15:44:00 +0000
Subject: [New-bugs-announce] [issue7142] __repr__ of memoryview object has
type unicode; should be str.
In-Reply-To: <1255621440.88.0.911779957841.issue7142@psf.upfronthosting.co.za>
Message-ID: <1255621440.88.0.911779957841.issue7142@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
Objects/memoryobject.c makes calls to PyUnicode_FromString and
PyUnicode_FromFormat. This prevents building of Python with the --
disable-unicode option.
Here's a patch.
----------
assignee: pitrou
components: Interpreter Core
files: memoryview.patch
keywords: patch
messages: 94094
nosy: mark.dickinson, pitrou
severity: normal
stage: patch review
status: open
title: __repr__ of memoryview object has type unicode; should be str.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file15138/memoryview.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7142>
_______________________________________
From report at bugs.python.org Thu Oct 15 20:06:49 2009
From: report at bugs.python.org (Andreas Thomas)
Date: Thu, 15 Oct 2009 18:06:49 +0000
Subject: [New-bugs-announce] [issue7143] get_payload(decode=True) eats last
newline
In-Reply-To: <1255630009.17.0.724034195968.issue7143@psf.upfronthosting.co.za>
Message-ID: <1255630009.17.0.724034195968.issue7143@psf.upfronthosting.co.za>
New submission from Andreas Thomas <raednas at gmail.com>:
The attachment of my sample email contains '123\n', but get_payload
(decode=True) returns '123'.
The source of this error is the function _bdecode from the email.utils
module, which gets called for decoding base64 encoded payloads. Here
the last \n gets stripped away, because (comment in the function):
# We can't quite use base64.encodestring() since it tacks on a "courtesy
# newline". Blech!
I don't think that's true. At least not for Python 2.5.4 and upwards.
Also note the "encodestring" instead of "decodestring".
In fact calling
base64.decodestring(part.get_payload())
returns the correct value, so I propose to remove this function
completely and just use the standard decoding method.
Please note that base64.encodestring really tacks on a \n.
----------
components: Library (Lib)
files: test.eml
messages: 94100
nosy: athomas
severity: normal
status: open
title: get_payload(decode=True) eats last newline
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15139/test.eml
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7143>
_______________________________________
From report at bugs.python.org Thu Oct 15 21:35:21 2009
From: report at bugs.python.org (Pete Hunt)
Date: Thu, 15 Oct 2009 19:35:21 +0000
Subject: [New-bugs-announce] [issue7144] imp.load_module in thread causes
core dump on OSX 10.6
In-Reply-To: <1255635321.71.0.461133930779.issue7144@psf.upfronthosting.co.za>
Message-ID: <1255635321.71.0.461133930779.issue7144@psf.upfronthosting.co.za>
New submission from Pete Hunt <floydophone at gmail.com>:
Apologies if I mess up the formatting - my first bug report submitted.
Steps to reproduce (OSX Snow Leopard, 2.6.3)
>>> import threading, imp
>>> def doit():
... print imp.load_module("cherrypy", None,
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-
packages/CherryPy-3.1.2-py2.6.egg/cherrypy", ('', '', 5))
...
>>> threading.Thread(target=doit).start()
>>> Trace/BPT trap
----------
assignee: ronaldoussoren
components: Extension Modules, Interpreter Core, Macintosh
messages: 94106
nosy: peterhunt, ronaldoussoren
severity: normal
status: open
title: imp.load_module in thread causes core dump on OSX 10.6
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7144>
_______________________________________
From report at bugs.python.org Thu Oct 15 22:55:41 2009
From: report at bugs.python.org (Yang Zhang)
Date: Thu, 15 Oct 2009 20:55:41 +0000
Subject: [New-bugs-announce] [issue7145] UTF-16 BOM is not written by
socket.makefile (but is expected by read)
In-Reply-To: <1255640141.97.0.741235595608.issue7145@psf.upfronthosting.co.za>
Message-ID: <1255640141.97.0.741235595608.issue7145@psf.upfronthosting.co.za>
New submission from Yang Zhang <yaaang at gmail.com>:
When I call s.makefile('r',encoding='utf-16').read(), this expects a BOM,
but s.makefile('w',encoding='utf-16').write('hello') doesn't produce it.
This is asymmetric.
BTW is there a way to prevent the reading file from expecting a BOM?
----------
components: Library (Lib)
messages: 94108
nosy: yang
severity: normal
status: open
title: UTF-16 BOM is not written by socket.makefile (but is expected by read)
type: behavior
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7145>
_______________________________________
From report at bugs.python.org Fri Oct 16 01:40:52 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Thu, 15 Oct 2009 23:40:52 +0000
Subject: [New-bugs-announce] [issue7146] [PATCH] platform.uname()[4] returns
'amd64' on Windows and 'x86-64' on Linux
In-Reply-To: <1255650052.62.0.822964382584.issue7146@psf.upfronthosting.co.za>
Message-ID: <1255650052.62.0.822964382584.issue7146@psf.upfronthosting.co.za>
New submission from Zooko O'Whielacronx <zooko at zooko.com>:
Looking at http://bugs.python.org/setuptools/issue1 and reading the
source of Lib/platform.py, it appears to me that uname() returns
different strings identifying the amd64 architecture depending on what
operating system is running. It would seem to me that it would be
better to report the same arch with the same string on all platforms.
Could someone with win64 report the output of:
python -c 'import platform;print platform.uname()[4]'
Here is a patch against trunk that just replaces any 'x86_64' with 'amd64':
HACK yukyuk:~/playground/python/trunk$ svn diff
Index: Lib/platform.py
===================================================================
--- Lib/platform.py (revision 75443)
+++ Lib/platform.py (working copy)
@@ -1225,6 +1225,9 @@
system = 'Windows'
release = 'Vista'
+ # normalize 'amd64' arch
+ if machine == 'x86_64':
+ machine = 'amd64'
_uname_cache = system,node,release,version,machine,processor
return _uname_cache
----------
components: Library (Lib)
messages: 94112
nosy: zooko
severity: normal
status: open
title: [PATCH] platform.uname()[4] returns 'amd64' on Windows and 'x86-64' on Linux
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7146>
_______________________________________
From report at bugs.python.org Fri Oct 16 01:45:04 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 15 Oct 2009 23:45:04 +0000
Subject: [New-bugs-announce] [issue7147] Remove WITHOUT_COMPLEX from 3.x
trunk
In-Reply-To: <1255650304.9.0.743144101896.issue7147@psf.upfronthosting.co.za>
Message-ID: <1255650304.9.0.743144101896.issue7147@psf.upfronthosting.co.za>
New submission from Skip Montanaro <skip at pobox.com>:
I raised the topic of the use of WITHOUT_COMPLEX in python-dev. Here's
a patch to remove it from the 3.x trunk.
----------
components: Interpreter Core
files: nocomplex.diff
keywords: easy, needs review, patch, patch
messages: 94113
nosy: skip.montanaro
priority: normal
severity: normal
stage: patch review
status: open
title: Remove WITHOUT_COMPLEX from 3.x trunk
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file15144/nocomplex.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7147>
_______________________________________
From report at bugs.python.org Fri Oct 16 03:24:21 2009
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Fri, 16 Oct 2009 01:24:21 +0000
Subject: [New-bugs-announce] [issue7148] socket.py: r75412 broke build
In-Reply-To: <1255656261.81.0.427894588269.issue7148@psf.upfronthosting.co.za>
Message-ID: <1255656261.81.0.427894588269.issue7148@psf.upfronthosting.co.za>
New submission from Kurt B. Kaiser <kbk at shore.net>:
buildbots failing since r75412:
testSocketServer (test.test_ssl.ThreadedTests) ... Traceback (most
recent call last):
File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/
SocketServer.py", line 282, in _handle_request_noblock
self.process_request(request, client_address)
File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/
SocketServer.py", line 308, in process_request
self.finish_request(request, client_address)
File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/
SocketServer.py", line 321, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/
SocketServer.py", line 639, in __init__
self.finish()
File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/
SocketServer.py", line 692, in finish
self.wfile.flush()
File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/
socket.py", line 300, in flush
self._sock.sendall(view[write_offset:write_offset+buffer_size])
File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/
ssl.py", line 203, in sendall
v = self.send(data[count:])
File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/
ssl.py", line 94, in <lambda>
self.send = lambda data, flags=0: SSLSocket.send(self, data, flags)
File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/
ssl.py", line 174, in send
v = self._sslobj.write(data)
TypeError: must be string or read-only buffer, not memoryview
----------
assignee: pitrou
components: Library (Lib)
messages: 94118
nosy: kbk, pitrou
priority: high
severity: normal
status: open
title: socket.py: r75412 broke build
type: behavior
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7148>
_______________________________________
From report at bugs.python.org Fri Oct 16 06:49:57 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Oct 2009 04:49:57 +0000
Subject: [New-bugs-announce] [issue7149] 2.6.4rc1 regression: test_urllib2
fails on OS X with UnboundLocalError
In-Reply-To: <1255668597.22.0.497467299088.issue7149@psf.upfronthosting.co.za>
Message-ID: <1255668597.22.0.497467299088.issue7149@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
Possible Release Blocker
A number of proxy test cases in test_urllib2 are now failing with:
ERROR: test_proxy (test.test_urllib2.HandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/test/te
st_urllib2.py", line 940, in test_proxy
r = o.open(req)
File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib2
.py", line 389, in open
response = self._open(req, data)
File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib2
.py", line 407, in _open
'_open', req)
File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib2
.py", line 367, in _call_chain
result = func(*args)
File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib2
.py", line 696, in <lambda>
meth(r, proxy, type))
File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib2
.py", line 705, in proxy_open
if req.host and proxy_bypass(req.host):
File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib.
py", line 1398, in proxy_bypass
return proxy_bypass_macosx_sysconf(host)
File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib.
py", line 1367, in proxy_bypass_macosx_sysconf
if hostIP is None:
UnboundLocalError: local variable 'hostIP' referenced before assignment
The root cause is the problem identified in Issue7044. This is now
showing up in test_urllib2 because of the changes in urllib2 introduced
by Issue6894 which was checked into the release-26maint branch during
the window between the release of 2.6.3 and the freezing for 2.6.4.
----------
assignee: ronaldoussoren
components: Library (Lib), Macintosh
messages: 94124
nosy: barry, ned.deily, orsenthil, ronaldoussoren
severity: normal
status: open
title: 2.6.4rc1 regression: test_urllib2 fails on OS X with UnboundLocalError
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7149>
_______________________________________
From report at bugs.python.org Fri Oct 16 11:45:29 2009
From: report at bugs.python.org (mark.leander)
Date: Fri, 16 Oct 2009 09:45:29 +0000
Subject: [New-bugs-announce] [issue7150] datetime operations spanning
MINYEAR give bad results
In-Reply-To: <1255686329.97.0.65785065346.issue7150@psf.upfronthosting.co.za>
Message-ID: <1255686329.97.0.65785065346.issue7150@psf.upfronthosting.co.za>
New submission from mark.leander <mark.leander at oikku.net>:
The datetime module documentation would imply that operations that cause
dates to fall outside the MINYEAR--MAXYEAR range should raise
OverflowError. The interpreter session below shows that this is not
always the case, and that such operations may cause bogus and
inconsistent results.
Python 2.6.3 (r263rc1:75186, Oct 2 2009, 20:40:30) [MSC v.1500 32 bit
(Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> t0=datetime.datetime(1,1,1)
>>> d1, d2, d3 = map(datetime.timedelta, range(1,4))
# The following is expected and accoring to the docs:
>>> t0-d1
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OverflowError: date value out of range
# The following is completely bogus:
>>> t0-d2
datetime.datetime(1, 0, 255, 0, 0)
# The two following behaving differently may be very confusing,
# the second one is correct
>>> t0-d2+d3
datetime.datetime(1, 8, 15, 0, 0)
>>> t0+d3-d2
datetime.datetime(1, 1, 2, 0, 0)
>>>
----------
components: Library (Lib)
messages: 94132
nosy: mark.leander
severity: normal
status: open
title: datetime operations spanning MINYEAR give bad results
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7150>
_______________________________________
From report at bugs.python.org Fri Oct 16 20:51:16 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Oct 2009 18:51:16 +0000
Subject: [New-bugs-announce] [issue7151] regrtest -j sometimes fails if
output gets written to stderr by a test
In-Reply-To: <1255719076.69.0.751832436592.issue7151@psf.upfronthosting.co.za>
Message-ID: <1255719076.69.0.751832436592.issue7151@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
In certain circumstances output written to stderr during a test comes
after the json result string the -j code is expecting to see at the end
of the returned subprocess output. This causes that regrtest worker
thread to fail. This problem is more acute on py3k; perhaps the new io
library is more likely to delay output of stderr.
Attached is a patch that avoids the problem by capturing stderr
separately. This means that all stderr output will be after all regular
output, which changes the output of the test suite slightly (eg: in a
debug build all the refcount messages come after the output from
test_subprocess). This seems like a small enough issue that it isn't
worth the code complexity required to code around it, especially since
the ordering of the interleaving of the two streams isn't guaranteed
even without -j.
----------
assignee: pitrou
components: Tests
files: regrtestj3stderr.patch
keywords: patch, patch
messages: 94143
nosy: pitrou, r.david.murray
priority: low
severity: normal
stage: patch review
status: open
title: regrtest -j sometimes fails if output gets written to stderr by a test
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15148/regrtestj3stderr.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7151>
_______________________________________
From report at bugs.python.org Fri Oct 16 21:06:44 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 16 Oct 2009 19:06:44 +0000
Subject: [New-bugs-announce] [issue7152] urllib2.build_opener() skips
ProxyHandler
In-Reply-To: <1255720004.18.0.991850721386.issue7152@psf.upfronthosting.co.za>
Message-ID: <1255720004.18.0.991850721386.issue7152@psf.upfronthosting.co.za>
New submission from Barry A. Warsaw <barry at python.org>:
Try this:
>>> from urllib2 import build_opener
>>> build_opener().handlers
In Python 2.4, you will see ProxyHandler as the first handler, but this
handler is missing from the list in Python 2.5, 2.6, and 2.7, despite this
text in the documentation:
urllib2.build_opener([handler, ...])
Return an OpenerDirector instance, which chains the handlers in the
order
given. handlers can be either instances of BaseHandler, or subclasses of
BaseHandler (in which case it must be possible to call the constructor
without any parameters). Instances of the following classes will be in
front of the handlers, unless the handlers contain them, instances
of them
or subclasses of them: ProxyHandler, UnknownHandler, HTTPHandler,
HTTPDefaultErrorHandler, HTTPRedirectHandler, FTPHandler, FileHandler,
HTTPErrorProcessor.
In fact, there is no way to add a ProxyHandler at all using the public API.
This is because the following code was added to Python 2.5, purportedly as a
fix for bug 972322:
http://bugs.python.org/issue972322
# urllib2.py:307
if meth in ["redirect_request", "do_open", "proxy_open"]:
# oops, coincidental match
continue
Because of this, the following are not a workarounds:
>>> opener.add_handler(ProxyHandler)
>>> build_opener(ProxyHandler())
In fact, as near as I can tell, the only way to get a ProxyHandler in
there is
to do an end-run around .add_handler():
>>> proxy_handler = ProxyHandler()
>>> opener.handlers.insert(0, proxy_handler)
>>> proxy_handler.add_parent(opener)
I'm actually quite shocked this has never been reported before.
ISTM that the right fix is what was originally suggested in bug 972322:
http://bugs.python.org/msg46172
"The alternative would be to rename do_open and proxy_open, and leave the
redirect_request case unchanged (see below for why)."
The intent of this patch could not have been to completely prevent
ProxyHandler from being included in the list of handlers, otherwise why keep
ProxyHandler at all? If that was the case, then the documentation for
urllib2
is broken, and it should have described this change as occurring in Python
2.5.
----------
components: Library (Lib)
messages: 94144
nosy: barry
priority: high
severity: normal
stage: needs patch
status: open
title: urllib2.build_opener() skips ProxyHandler
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7152>
_______________________________________
From report at bugs.python.org Fri Oct 16 21:24:03 2009
From: report at bugs.python.org (paul rubin)
Date: Fri, 16 Oct 2009 19:24:03 +0000
Subject: [New-bugs-announce] [issue7153] add "start" arg to max and min
functions
In-Reply-To: <1255721043.52.0.906494418992.issue7153@psf.upfronthosting.co.za>
Message-ID: <1255721043.52.0.906494418992.issue7153@psf.upfronthosting.co.za>
New submission from paul rubin <phr at users.sourceforge.net>:
Lots of times I want to find the largest element of a list or sequence,
defaulting to 0 if the list or sequence is empty. max(seq) throws an
exception if seq is empty, so I end up using reduce(max, seq, 0). That
is a standard functional programming idiom but can be a bit confusing to
imperative-style Python programmers.
max with multiple args is already overloaded to mean the maximum of the
args, so I think it would be a good fix to add a keyword arg to accept
an optional initial value: max(seq, start=0). For symmetry, min should
accept the same arg.
The alternatives to using reduce aren't so attractive. If seq happens
to be a list, there might be a temptation to conditionalize on
len(seq)==0, but that is poor style since it will break if seq later
changes to an arbitrary sequence. And trying to test it by calling
.next() and saving the value and/or trapping StopIteration gets awfully
messy.
----------
components: Library (Lib)
messages: 94145
nosy: phr
severity: normal
status: open
title: add "start" arg to max and min functions
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7153>
_______________________________________
From report at bugs.python.org Sat Oct 17 00:46:48 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Oct 2009 22:46:48 +0000
Subject: [New-bugs-announce] [issue7154] urllib.request system proxy
configuration lookup broken for OS X in Python 3
In-Reply-To: <1255733208.5.0.407244004895.issue7154@psf.upfronthosting.co.za>
Message-ID: <1255733208.5.0.407244004895.issue7154@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
On OS X, urllib.request in Python 3 is supposed to use the operating
system's proxy configuration by default, unless overridden by
environment variables or by the caller providing an explicit proxy
configuration.
In Python 2, urllib (and, indirectly, urllib2) were modified to use the
OS X SystemConfiguration framework API instead of the obsolete classic
MacOS Internet Configuration via the deprecated Macintosh ic library
module, which was removed in Python 3.
However, in the transition from Python 2 urllib/urllib2 to Python 3
urllib.request, the changes to the darwin-specific getproxies functions
were not made. So, at the moment, Python 3 urllib.request tries to
import the non-existant ic module and silently fails, effectively
ignoring the system proxy configuration. The solution is to forward
port the corresponding code from Python 2 urllib along with the helper
module _scproxy.c.
----------
assignee: ronaldoussoren
components: Library (Lib), Macintosh
messages: 94153
nosy: ned.deily, ronaldoussoren
severity: normal
status: open
title: urllib.request system proxy configuration lookup broken for OS X in Python 3
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7154>
_______________________________________
From report at bugs.python.org Sat Oct 17 01:45:27 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Oct 2009 23:45:27 +0000
Subject: [New-bugs-announce] [issue7155] urllib2 and python 3 urllib do not
document default use of system proxy configuration
In-Reply-To: <1255736727.77.0.830573740037.issue7155@psf.upfronthosting.co.za>
Message-ID: <1255736727.77.0.830573740037.issue7155@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
Several issues with urllib/urllib2 documentation regarding proxy usage:
1. The Macintosh proxy description in section 21.5.1 is out-of-date:
"In a Macintosh environment, urlopen() will retrieve
proxy information from Internet Config."
Suggest something like:
"In a Mac OS X environment, urlopen() will retrieve
proxy information from the OS X System Configuration
framework, which can be managed with the Network system
preference panel."
2. In general, urllib/urllib2 on Python 2 and urllib.request on Python 3
are supposed to default to using the OS's proxy configuration on
Windows and OS X if not overridden by environment variables or
if not supplied as an argument. This is described in python 2 docs
section 21.5.1. urllib2 has the same default behavior since under the
covers it uses urllib's proxy functions. But that behavior is not
documented in 21.6 for urllib2 in the various spots where proxy is
mentioned.
3. Likewise, the corresponding sections of the Python 3 documentation
for urllib.request (section 20.5) do not mention the default system
proxy configuration behavior and should since that code was carried
over from Python 2 (although, at the moment, the OS X code is broken
- see Issue7154).
----------
assignee: georg.brandl
components: Documentation
messages: 94155
nosy: georg.brandl, ned.deily
severity: normal
status: open
title: urllib2 and python 3 urllib do not document default use of system proxy configuration
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7155>
_______________________________________
From report at bugs.python.org Sat Oct 17 02:28:56 2009
From: report at bugs.python.org (Archon)
Date: Sat, 17 Oct 2009 00:28:56 +0000
Subject: [New-bugs-announce] [issue7156] curses can't find _curses
Message-ID: <1255739336.81.0.0557140731973.issue7156@psf.upfronthosting.co.za>
Changes by Archon <mddekock at bendbroadband.com>:
----------
components: Library (Lib)
nosy: Archon
severity: normal
status: open
title: curses can't find _curses
type: crash
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7156>
_______________________________________
From report at bugs.python.org Sat Oct 17 02:40:19 2009
From: report at bugs.python.org (Ryan Leslie)
Date: Sat, 17 Oct 2009 00:40:19 +0000
Subject: [New-bugs-announce] [issue7157] Fix Download Current Documentation
link
In-Reply-To: <1255740019.91.0.5088264353.issue7157@psf.upfronthosting.co.za>
Message-ID: <1255740019.91.0.5088264353.issue7157@psf.upfronthosting.co.za>
New submission from Ryan Leslie <rylesny at gmail.com>:
http://docs.python.org/download.html shows this:
----
Download Python 2.6.4c1 Documentation
We don't package the documentation for development releases for
download. Downloads will be available for the final release.
----
This is not really acceptable for someone navigating through python.org
to the Documentation page. The latest 2.6 reference, tutorial, etc, are
all available, and so the archives with the latest PDF versions should
be too.
----------
assignee: georg.brandl
components: Documentation
messages: 94158
nosy: georg.brandl, ryles
severity: normal
status: open
title: Fix Download Current Documentation link
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7157>
_______________________________________
From report at bugs.python.org Sat Oct 17 07:36:57 2009
From: report at bugs.python.org (Tom Kuiper)
Date: Sat, 17 Oct 2009 05:36:57 +0000
Subject: [New-bugs-announce] [issue7158] os.path.basename/split fails
In-Reply-To: <1255757817.87.0.79246409428.issue7158@psf.upfronthosting.co.za>
Message-ID: <1255757817.87.0.79246409428.issue7158@psf.upfronthosting.co.za>
New submission from Tom Kuiper <kuiper at jpl.nasa.gov>:
Normal behavior:
>>> from os import path
>>> filename
= "/home/kuiper/Projects/microdischarges/Observing/2009-09-01/STATS_NP2000_VSR1A.1W1.09-244-193632"
>>> print filename
/home/kuiper/Projects/microdischarges/Observing/2009-09-01/STATS_NP2000_VSR1A.1W1.09-244-193632
>>> print path.basename(filename)
STATS_NP2000_VSR1A.1W1.09-244-193632
Abnormal behavior in class method:
from os import path
...
def openDataFile(self):
filename = QFileDialog.getOpenFileName(self, 'Open file','.')
self.datafile.setTextpath.basename(filename))
...
Traceback (most recent call last):
File "newWF.py", line 277, in openDataFile
self.datafile.setText(os.path.basename(filename))
File "/usr/lib/python2.5/posixpath.py", line 112, in basename
return split(p)[1]
File "/usr/lib/python2.5/posixpath.py", line 77, in split
i = p.rfind('/') + 1
AttributeError: rfind
----------
files: newWF.py
messages: 94167
nosy: kuiper
severity: normal
status: open
title: os.path.basename/split fails
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file15153/newWF.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7158>
_______________________________________
From report at bugs.python.org Sat Oct 17 17:32:39 2009
From: report at bugs.python.org (Brad Olson)
Date: Sat, 17 Oct 2009 15:32:39 +0000
Subject: [New-bugs-announce] [issue7159] Urllib2 authentication memory.
In-Reply-To: <1255793559.46.0.185389780208.issue7159@psf.upfronthosting.co.za>
Message-ID: <1255793559.46.0.185389780208.issue7159@psf.upfronthosting.co.za>
New submission from Brad Olson <brado at movedbylight.com>:
For each request requiring HTTP authentication, urllib2 submits the
request without authentication, receives the server's 401
error/challenge, then re-submits the request with authentication.
This is compliant behavior. The problem comes in that urllib2 repeats
this for every ensuing request to the same namespace.
At times this is just an inefficiency--every request gets sent twice,
often with POST data (which can be sizeable).
Sometimes, especially with large POST bodies, this causes a connection
failure.
(Mercurial suffers greatly from this (and I have suggested workaround to
that team.)
This isn't non-compliant behavior, but RFC2617 (sections 2, 3.3)
suggests that once an HTTP client authenticates, it pre-emptively send
authentication with ensuing requests.
More analysis and fix suggestions at
bitbucket.org/bradobro/liquidhg/wiki/Home.
----------
components: Library (Lib)
messages: 94180
nosy: bradobro
severity: normal
status: open
title: Urllib2 authentication memory.
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7159>
_______________________________________
From report at bugs.python.org Sat Oct 17 18:31:04 2009
From: report at bugs.python.org (Michael J. Fromberger)
Date: Sat, 17 Oct 2009 16:31:04 +0000
Subject: [New-bugs-announce] [issue7160] Crash when returning a 64-bit char
pointer in Python 2.6.3 ctypes
In-Reply-To: <1255797064.79.0.0899403156454.issue7160@psf.upfronthosting.co.za>
Message-ID: <1255797064.79.0.0899403156454.issue7160@psf.upfronthosting.co.za>
New submission from Michael J. Fromberger <michael.j.fromberger at gmail.com>:
A segmentation fault is generated in _ctypes.so when calling a function that returns a char pointer on a system
with 64-bit pointer types. The attached crash dump is from a Python 2.6.3 built from MacPorts ("port install
python26 +no_tkinter"), but the same behaviour occurs with the Python 2.6.1 installed by Apple.
To reproduce, build the attached sample program ("testlib.c"):
% gcc -Wall -c testlib.o
% ld -dylib -o testlib.so testlib.o
Then, in Python:
# Common setup for each of the cases below.
>>> from ctypes import *
>>> lib = CDLL('testlib.so')
# Case 1: Integer return value (no crash).
>>> get_value = CFUNCTYPE(c_int)(lib.get_value)
>>> get_value()
12345
# Case 2: Pointer argument value (no crash).
>>> buf = create_string_buffer(256)
>>> copy_message = CFUNCTYPE(None, c_char_p)(lib.copy_message)
>>> copy_message(buf)
# Case 3: Pointer return value (crash).
>>> get_message = CFUNCTYPE(c_char_p)(lib.get_message)
>>> get_message()
Segmentation fault
-- System information:
% uname -a
MacOS 10.6.1
Darwin gorion.local 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-
1456.1.25~1/RELEASE_I386 i386
% python
Python 2.6.3 (r263:75183, Oct 17 2009, 01:49:30)
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
% gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) (dot 1)
----------
assignee: theller
components: ctypes
files: testlib.c
messages: 94181
nosy: creachadair, theller
severity: normal
status: open
title: Crash when returning a 64-bit char pointer in Python 2.6.3 ctypes
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file15154/testlib.c
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7160>
_______________________________________
From report at bugs.python.org Sat Oct 17 21:25:50 2009
From: report at bugs.python.org (Trundle)
Date: Sat, 17 Oct 2009 19:25:50 +0000
Subject: [New-bugs-announce] [issue7161] raise of SyntaxError in codeop was
ported incorrectly to Py3
In-Reply-To: <1255807550.69.0.197783974238.issue7161@psf.upfronthosting.co.za>
Message-ID: <1255807550.69.0.197783974238.issue7161@psf.upfronthosting.co.za>
New submission from Trundle <andy-python at hammerhartes.de>:
The original lines in Lib/codeop.py under Python 2.6:
raise SyntaxError, err1
Those lines were ported to Python 3 as:
raise SyntaxError(err1)
Which is wrong because `err1` is in both cases an instance of
`SyntaxError`. Quote from the language reference: "If the first object
is a class, it becomes the type of the exception. The second object is
used to determine the exception value: If it is an instance of the
class, the instance becomes the exception value." Therefore, the correct
translation of that code is: "raise err1".
The attached patch fixes the issue.
----------
components: Library (Lib)
files: codeop_raise_syntaxerror.patch
keywords: patch
messages: 94185
nosy: Trundle
severity: normal
status: open
title: raise of SyntaxError in codeop was ported incorrectly to Py3
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15157/codeop_raise_syntaxerror.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7161>
_______________________________________
From report at bugs.python.org Sat Oct 17 23:29:39 2009
From: report at bugs.python.org (Joe Amenta)
Date: Sat, 17 Oct 2009 21:29:39 +0000
Subject: [New-bugs-announce] [issue7162] 2to3 does not convert
__builtins__.file
In-Reply-To: <1255814979.41.0.0993610579435.issue7162@psf.upfronthosting.co.za>
Message-ID: <1255814979.41.0.0993610579435.issue7162@psf.upfronthosting.co.za>
New submission from Joe Amenta <amentajo at msu.edu>:
Step to reproduce:
$ echo 'file("/some/file")' | python `which 2to3` -
(replace python with whichever python executable version you wish to
use, e.g. ~/python-trunk/python or /usr/local/bin/python3.2 )
Expected result:
Anything referring to the fact that the "file" type no longer exists in
python 3.x, whether it be a warning or a refactoring.
Actual result:
RefactoringTool: No files need to be modified.
Just a report for now, I don't have the time to write a patch.
----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 94190
nosy: joe.amenta
severity: normal
status: open
title: 2to3 does not convert __builtins__.file
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/issue7162>
_______________________________________
From report at bugs.python.org Sun Oct 18 00:38:03 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Oct 2009 22:38:03 +0000
Subject: [New-bugs-announce] [issue7163] IDLE suppresses sys.stdout.write()
return value
In-Reply-To: <1255819083.11.0.568760312973.issue7163@psf.upfronthosting.co.za>
Message-ID: <1255819083.11.0.568760312973.issue7163@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
IDLE
Python 3.1 (r31:73574, Jun 26 2009, 20:21:35) [MSC v.1500 32 bit
(Intel)] on win32
>>> import sys
>>> sys.stdout.write('abc')
abc
whereas
Command Window
Python 3.1 (r31:73574, Jun 26 2009, 20:21:35) [MSC v.1500 32 bit
(Intel)] on win32
>>> import sys
>>> sys.stdout.write('abc')
abc3
----------
components: IDLE
messages: 94191
nosy: tjreedy
severity: normal
status: open
title: IDLE suppresses sys.stdout.write() return value
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7163>
_______________________________________
From report at bugs.python.org Sun Oct 18 03:14:23 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 18 Oct 2009 01:14:23 +0000
Subject: [New-bugs-announce] [issue7164] pickle test failure after
test_imp/test_import (_make_stat_result is not the same
object as os._make_stat_result)
In-Reply-To: <1255828463.78.0.430609801319.issue7164@psf.upfronthosting.co.za>
Message-ID: <1255828463.78.0.430609801319.issue7164@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
After r75467, which changed test_imp and test_import to use CleanImport,
the various pickle tests fail (all in the same common test, I believe).
The error looks like this:
Traceback (most recent call last):
File "/home/rdmurray/python/trunk/Lib/test/pickletester.py", line 623,
in test_structseq
s = self.dumps(t, proto)
File "/home/rdmurray/python/trunk/Lib/test/test_pickle.py", line 33,
in dumps
p.dump(arg)
File "/home/rdmurray/python/trunk/Lib/pickle.py", line 224, in dump
self.save(obj)
File "/home/rdmurray/python/trunk/Lib/pickle.py", line 331, in save
self.save_reduce(obj=obj, *rv)
File "/home/rdmurray/python/trunk/Lib/pickle.py", line 400, in save_reduce
save(func)
File "/home/rdmurray/python/trunk/Lib/pickle.py", line 286, in save
f(self, obj) # Call unbound method with explicit self
File "/home/rdmurray/python/trunk/Lib/pickle.py", line 753, in save_global
(obj, module, name))
PicklingError: Can't pickle <function _make_stat_result at 0xb7a09494>:
it's not the same object as os._make_stat_result
I don't have enough pickle-foo to understand what it is trying to do
here or what about CleanImport is messing it up.
----------
components: Tests
messages: 94195
nosy: brett.cannon, ncoghlan, r.david.murray
priority: normal
severity: normal
status: open
title: pickle test failure after test_imp/test_import (_make_stat_result is not the same object as os._make_stat_result)
type: behavior
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7164>
_______________________________________
From report at bugs.python.org Sun Oct 18 14:40:49 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 18 Oct 2009 12:40:49 +0000
Subject: [New-bugs-announce] [issue7165] xmlrpc.server assumes sys.stdout
will have a buffer attribute
In-Reply-To: <1255869649.48.0.335653342383.issue7165@psf.upfronthosting.co.za>
Message-ID: <1255869649.48.0.335653342383.issue7165@psf.upfronthosting.co.za>
New submission from Nick Coghlan <ncoghlan at gmail.com>:
The xmlrpc tests were changed to use a StringIO object instead of a
temporary file (this change reflects the corresponding change made on
the 2.x trunk).
The tests then started failing, since xmlrpc.server assumes sys.stdout
will provide the buffer attribute, which is not a valid assumption. From
the io.TestIOBase documentation:
buffer
The underlying binary buffer (a BufferedIOBase instance) that
TextIOBase deals with. This is not part of the TextIOBase API and may
not exist on some implementations.
Assuming this attribute exists is a bug in xmlrpc.server that should be
fixed.
----------
components: Library (Lib)
messages: 94212
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: xmlrpc.server assumes sys.stdout will have a buffer attribute
type: behavior
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7165>
_______________________________________
From report at bugs.python.org Sun Oct 18 21:34:28 2009
From: report at bugs.python.org (Lie Ryan)
Date: Sun, 18 Oct 2009 19:34:28 +0000
Subject: [New-bugs-announce] [issue7166] IDLE (python 3.1.1) syntax coloring
for b'bytestring' and u'unicode' string literal
In-Reply-To: <1255894468.82.0.699463762919.issue7166@psf.upfronthosting.co.za>
Message-ID: <1255894468.82.0.699463762919.issue7166@psf.upfronthosting.co.za>
New submission from Lie Ryan <lie.1296 at gmail.com>:
On python trunk and 3.2 IDLE, the b in b'' is not green colored.
On python 3.1 IDLE, the u in u'' is still colored, despite a SyntaxError.
(sorry, I don't have diff installed on my Windows machine)
Change on python trunk:
/Lib/idlelib/ColorDelegator.py
def make_pat():
....
sqstring = r"(\b[rRuUbB])?'[^'\\\n]*(\\.[^'\\\n]*)*'?"
dqstring = r'(\b[rRuUbB])?"[^"\\\n]*(\\.[^"\\\n]*)*"?'
sq3string = r"(\b[rRuUbB])?'''[^'\\]*((\\.|'(?!''))[^'\\]*)*(''')?"
dq3string = r'(\b[rRuUbB])?"""[^"\\]*((\\.|"(?!""))[^"\\]*)*(""")?'
....
And on py3k branch:
/Lib/idlelib/ColorDelegator.py
def make_pat():
....
sqstring = r"(\b[rRbB])?'[^'\\\n]*(\\.[^'\\\n]*)*'?"
dqstring = r'(\b[rRbB])?"[^"\\\n]*(\\.[^"\\\n]*)*"?'
sq3string = r"(\b[rRbB])?'''[^'\\]*((\\.|'(?!''))[^'\\]*)*(''')?"
dq3string = r'(\b[rRbB])?"""[^"\\]*((\\.|"(?!""))[^"\\]*)*(""")?'
....
----------
components: IDLE
messages: 94222
nosy: lieryan
severity: normal
status: open
title: IDLE (python 3.1.1) syntax coloring for b'bytestring' and u'unicode' string literal
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7166>
_______________________________________
From report at bugs.python.org Sun Oct 18 23:22:25 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Oct 2009 21:22:25 +0000
Subject: [New-bugs-announce] [issue7167] Smarter FTP passive mode
In-Reply-To: <1255900945.2.0.567216991168.issue7167@psf.upfronthosting.co.za>
Message-ID: <1255900945.2.0.567216991168.issue7167@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
I have come accross an FTP server which lftp (an Unix command-line
client) handles well but ftplib doesn't. Both ftplib and lftp are
configured to use passive mode (this server apparently doesn't handle
non-passive), but the address sent in response by the server is a
private IP. Here is a wireshark transcript of the FTP conversation done
by lftp:
220 172.29.AAA.BBB FTP server ready
FEAT
211-Features:
LANG en
MDTM
UTF8
AUTH TLS
PBSZ
PROT
REST STREAM
SIZE
211 End
LANG
200 Using default language en
OPTS UTF8 ON
200 UTF8 set to on
USER XXXX
331 Password required for ftth_rdvph
PASS XXXX
230 Connexion reussie pour ftth_rdvph
PWD
257 "/" is the current directory
PASV
227 Entering Passive Mode (172,29,AAA,BBB,195,84).
LIST
150 Opening ASCII mode data connection for file list
226 Transfer complete
As you see, lftp had no problem opening a data connection. It probably
notices that the address advertised in response to PASV doesn't respond
(after e.g. a 2s. timeout), and falls back on the host's known address
instead. In contrast, ftplib simply sits while the connection is
attempted and bails out at the end with a connection error.
----------
components: Library (Lib)
messages: 94226
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: Smarter FTP passive mode
type: feature request
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7167>
_______________________________________
From report at bugs.python.org Mon Oct 19 03:00:00 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 19 Oct 2009 01:00:00 +0000
Subject: [New-bugs-announce] [issue7168] Document PyFloat_AsString and
PyFloat_AsReprString as deprecated and unsafe
In-Reply-To: <1255914000.67.0.0340372687957.issue7168@psf.upfronthosting.co.za>
Message-ID: <1255914000.67.0.0340372687957.issue7168@psf.upfronthosting.co.za>
New submission from Eric Smith <eric at trueblade.com>:
These functions are unsafe and I'd like to delete them. They've already
been deleted in py3k, per PEP 3100. They are no longer used internally
to the interpreter.
They should be documented as deprecated and as unsafe. They write to a
char* parameter, but don't take a length, so they could overwrite the
passed-in buffer.
There's some argument to be made that we should also document
PyFloat_AsStringEx, which is also deprecated and unsafe. But it is not
in a .h file in 2.4, 2.5, or 2.6, so I'd like to just delete it for 2.7.
----------
assignee: georg.brandl
components: Documentation
messages: 94230
nosy: eric.smith, georg.brandl
priority: normal
severity: normal
status: open
title: Document PyFloat_AsString and PyFloat_AsReprString as deprecated and unsafe
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7168>
_______________________________________
From report at bugs.python.org Mon Oct 19 15:33:48 2009
From: report at bugs.python.org (skelker)
Date: Mon, 19 Oct 2009 13:33:48 +0000
Subject: [New-bugs-announce] [issue7169] zipfile leaves a file handle open
if file is zero size
In-Reply-To: <1255959228.67.0.513383976461.issue7169@psf.upfronthosting.co.za>
Message-ID: <1255959228.67.0.513383976461.issue7169@psf.upfronthosting.co.za>
New submission from skelker <steve.kelker at dtn.com>:
I noticed today if I attempt to create a ZipFile object for read access,
and the zip file is zero bytes, the ZipFile object throws an exception,
but there is still an open handle to the file. So if I catch that
exception, and then try to delete the file, the delete then fails. I
have attached a script that replicates the issue.
----------
components: Windows
files: zipfileCrash.py
messages: 94236
nosy: skelker
severity: normal
status: open
title: zipfile leaves a file handle open if file is zero size
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file15165/zipfileCrash.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7169>
_______________________________________
From report at bugs.python.org Mon Oct 19 23:48:08 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 19 Oct 2009 21:48:08 +0000
Subject: [New-bugs-announce] [issue7170] subclasses of (some) built-in types
are not weakref-able
In-Reply-To: <1255988888.99.0.764366839405.issue7170@psf.upfronthosting.co.za>
Message-ID: <1255988888.99.0.764366839405.issue7170@psf.upfronthosting.co.za>
New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:
The documentation for weakref contains the following example:
http://docs.python.org/3.1/library/weakref.html
----------------------------------------------
Several built-in types such as list and dict do not directly support
weak references but can add support through subclassing:
class Dict(dict):
pass
obj = Dict(red=1, green=2, blue=3) # this object is weak referenceable
----------------------------------------------
While this works fine for list and dict, it does not work for tuple or int:
>>> class Tuple(tuple):
... pass
...
>>> obj = Tuple()
>>> weakref.ref(obj)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: cannot create weak reference to 'Tuple' object
I've tried it in Python 2.5, 2.6, and 3.1.
----------
components: Interpreter Core
messages: 94260
nosy: stutzbach
severity: normal
status: open
title: subclasses of (some) built-in types are not weakref-able
type: behavior
versions: Python 2.5, 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/issue7170>
_______________________________________
From report at bugs.python.org Tue Oct 20 01:20:26 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 19 Oct 2009 23:20:26 +0000
Subject: [New-bugs-announce] [issue7171] Add inet_ntop and inet_pton support
for Windows
In-Reply-To: <1255994426.45.0.89635983538.issue7171@psf.upfronthosting.co.za>
Message-ID: <1255994426.45.0.89635983538.issue7171@psf.upfronthosting.co.za>
New submission from Jason R. Coombs <jaraco at jaraco.com>:
According to the documentation, Microsoft now supports inet_ntop and
inet_pton
(http://msdn.microsoft.com/en-us/library/cc805843%28VS.85%29.aspx). This
capability should be integrated into the socket module so it is
supported cross-platform.
----------
components: IO
messages: 94261
nosy: jaraco
severity: normal
status: open
title: Add inet_ntop and inet_pton support for Windows
type: feature request
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7171>
_______________________________________
From report at bugs.python.org Tue Oct 20 01:40:17 2009
From: report at bugs.python.org (Andrew Dalke)
Date: Mon, 19 Oct 2009 23:40:17 +0000
Subject: [New-bugs-announce] [issue7172]
BaseHTTPServer.BaseHTTPRequestHandler.responses[405] has a
small mistake
In-Reply-To: <1255995617.49.0.338501065571.issue7172@psf.upfronthosting.co.za>
Message-ID: <1255995617.49.0.338501065571.issue7172@psf.upfronthosting.co.za>
New submission from Andrew Dalke <dalke at dalkescientific.com>:
BaseHTTPServer.BaseHTTPRequestHandler.responses contains a mapping from
HTTP status codes to the 2-ple (shortmessage, longmessage), based on RFC
2616.
The 2-ple for 405 is ('Method Not Allowed','Specified method is invalid
for this server.'),
RFC 405 says "An origin server SHOULD return the status code 405 (Method
Not Allowed) if the method is known by the origin server but not allowed
for the requested resource.
I think the message should be "Specified method is invalid for this
resource". That is, change "server" to "resource".
----------
components: Library (Lib)
messages: 94262
nosy: dalke
severity: normal
status: open
title: BaseHTTPServer.BaseHTTPRequestHandler.responses[405] has a small mistake
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7172>
_______________________________________
From report at bugs.python.org Tue Oct 20 11:21:17 2009
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 20 Oct 2009 09:21:17 +0000
Subject: [New-bugs-announce] [issue7173] Cython compiler run crashes CPython
3.1.1 and 3.2
In-Reply-To: <1256030477.33.0.0599886113888.issue7173@psf.upfronthosting.co.za>
Message-ID: <1256030477.33.0.0599886113888.issue7173@psf.upfronthosting.co.za>
New submission from Stefan Behnel <scoder at users.sourceforge.net>:
Running the Cython compiler under Python 3.1.1 and 3.2 (SVN) corrupts
PyThreadState->exc_value by leaving a dead reference. Printing the value
then leads to a crash.
This bug is about plain Python code, no Cython built extension modules
involved.
Steps to reproduce the problem:
- get Cython from http://hg.cython.org/cython-devel (see the bz2/zip/gz
links on the left to get an archive without doing a checkout)
- apply the attached patch, which simply prints sys.exc_info() during
the compiler run at a place where it's known to be corrupted
- execute the following to run a single test in the test suite:
python3.1 runtests.py --no-cpp --no-pyregr --no-doctest -vv \
'compile\.first_assignment'
- expect a crash after printing "HERE1"
Before exc_info gets corrupted, we make heavy use of generators to
traverse the parse tree (see Cython/Compiler/TreePath.py), while being
inside of a recursive traversal of the tree already (see the
"VisitorTransform" class and its base class in
Cython/Compiler/Visitor.py). The code section that links the two is in
the class "TreeAssertVisitor" at the end of Cython/TestUtils.py, where
the patch applies. As exc_info doesn't get corrupted during the normal
recursive tree transformation traversals before that, the generator
usage in TreePath.py is likely related to the crash.
The crash was found and reproduced under two different Linux x86 systems.
----------
components: Interpreter Core
files: crash-patch.patch
keywords: patch
messages: 94268
nosy: scoder
severity: normal
status: open
title: Cython compiler run crashes CPython 3.1.1 and 3.2
type: crash
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15168/crash-patch.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7173>
_______________________________________
From report at bugs.python.org Tue Oct 20 12:21:51 2009
From: report at bugs.python.org (Andrew Shuiu)
Date: Tue, 20 Oct 2009 10:21:51 +0000
Subject: [New-bugs-announce] [issue7174] modeule: queue class: PriorityQueue
In-Reply-To: <1256034111.78.0.486242664983.issue7174@psf.upfronthosting.co.za>
Message-ID: <1256034111.78.0.486242664983.issue7174@psf.upfronthosting.co.za>
New submission from Andrew Shuiu <asuiu at bitdefender.com>:
Puting 2 tuples like (100, data1), (100, data2) in a PriorityQueue
generates an builtins.TypeError: unorderable types: data1 < data2
Code which generates error:
theQueue.put((100, object1()),True)
theQueue.put((100, object1()),True)
Snippet from error:
builtins.TypeError: unorderable types: Crawler() < Crawler()
File "d:\work\python\gglcrwl.py", line 89, in <module>
crawlGroup.Process()
File "d:\work\python\GglCrwLib.py", line 1056, in Process
globs.linksQueue.put((globs.cDefLinkPriority,
Crawler(u.title_url,ca)),True)
File "C:\Program Files\Python31\Lib\queue.py", line 153, in put
self._put(item)
File "C:\Program Files\Python31\Lib\queue.py", line 242, in _put
heappush(self.queue, item)
----------
components: Library (Lib)
messages: 94270
nosy: asuiu
severity: normal
status: open
title: modeule: queue class: PriorityQueue
type: crash
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7174>
_______________________________________
From report at bugs.python.org Tue Oct 20 13:21:17 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 20 Oct 2009 11:21:17 +0000
Subject: [New-bugs-announce] [issue7175] unify pydistutils.cfg and
distutils.cfg and use .local
In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
Message-ID: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
[.]pydistutils.cfg will be deprecated in favor of a single
"distutils.cfg", located in .local/ alongside the files added for
example by the per user-site packages.
----------
assignee: tarek
components: Distutils
messages: 94272
nosy: tarek
priority: normal
severity: normal
status: open
title: unify pydistutils.cfg and distutils.cfg and use .local
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________
From report at bugs.python.org Tue Oct 20 15:48:56 2009
From: report at bugs.python.org (=?utf-8?q?Bj=C3=B6rn_Augustsson?=)
Date: Tue, 20 Oct 2009 13:48:56 +0000
Subject: [New-bugs-announce] [issue7176] sum() doesn't work for lists.
In-Reply-To: <1256046536.74.0.518761053354.issue7176@psf.upfronthosting.co.za>
Message-ID: <1256046536.74.0.518761053354.issue7176@psf.upfronthosting.co.za>
New submission from Bj?rn Augustsson <oggust at gmail.com>:
Summary: "sum()" doesn't work on lists, even though the docs says it
should.
The docs say:
"Note that sum(range(n), m) is equivalent to reduce(operator.add,
range(n), m)"
That's not true.
--------------------------------
import operator
a=[1,2]
b=["x","y"]
reduce(operator.add, [a,b])
# Works, gives "[1, 2, 'x', 'y']" as expected.
sum ([a,b])
# Does not work, gives: "TypeError: unsupported operand type(s) for +:
'int' and 'list'"
--------------------------------
(And "a + b" obviously works too.)
/August.
----------
components: None
messages: 94275
nosy: oggust
severity: normal
status: open
title: sum() doesn't work for lists.
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7176>
_______________________________________
From report at bugs.python.org Tue Oct 20 22:20:05 2009
From: report at bugs.python.org (Christopher Jefferson)
Date: Tue, 20 Oct 2009 20:20:05 +0000
Subject: [New-bugs-announce] [issue7177] Unclear warning for subprocess.call
In-Reply-To: <1256070005.74.0.0266256477403.issue7177@psf.upfronthosting.co.za>
Message-ID: <1256070005.74.0.0266256477403.issue7177@psf.upfronthosting.co.za>
New submission from Christopher Jefferson <chris at bubblescope.net>:
I wandered across subprocess.call as it was mentioned as a replacement for os.system. The
following large warning is attached to it:
Warning Like Popen.wait(), this will deadlock if the child process generates enough output to a
stdout or stderr pipe such that it blocks waiting for the OS pipe buffer to accept more data.
This scared my off completely, and I assumed the function was simply broken, as I assumed
"stdout pipe" just meant that wherever stdout was sent by default.
I now believe this warning only applies if 'stdout=PIPE', or similar, is used explicitally.
Could this warning be better worded, perhaps adding "if stdout or stderr are explicitly
redirected", as in:
Warning Like Popen.wait(), if stdout or stderr are explicitly redirected this will deadlock if
the child process generates enough output to a stdout or stderr pipe such that it blocks
waiting for the OS pipe buffer to accept more data.
----------
assignee: georg.brandl
components: Documentation
messages: 94297
nosy: azumanga, georg.brandl
severity: normal
status: open
title: Unclear warning for subprocess.call
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7177>
_______________________________________
From report at bugs.python.org Tue Oct 20 23:13:08 2009
From: report at bugs.python.org (kuhnsjohn)
Date: Tue, 20 Oct 2009 21:13:08 +0000
Subject: [New-bugs-announce] [issue7178] open function's buffering parameter
is not completely doc'ed
In-Reply-To: <1256073188.35.0.768583079115.issue7178@psf.upfronthosting.co.za>
Message-ID: <1256073188.35.0.768583079115.issue7178@psf.upfronthosting.co.za>
New submission from kuhnsjohn <kuhnsjohn at gmail.com>:
it says: "Pass 0 to switch buffering off (only allowed in binary mode),
1 to set line buffering, and an integer > 1 for full buffering."
The last section should say something like: "and an integer > 1 to
specify the buffer size for full buffering."
----------
assignee: georg.brandl
components: Documentation
messages: 94300
nosy: georg.brandl, kuhnsjohn
severity: normal
status: open
title: open function's buffering parameter is not completely doc'ed
type: feature request
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7178>
_______________________________________
From report at bugs.python.org Wed Oct 21 02:41:27 2009
From: report at bugs.python.org (Thomas Klausner)
Date: Wed, 21 Oct 2009 00:41:27 +0000
Subject: [New-bugs-announce] [issue7179] Unportable test(1) construct
In-Reply-To: <1256085687.72.0.300279109357.issue7179@psf.upfronthosting.co.za>
Message-ID: <1256085687.72.0.300279109357.issue7179@psf.upfronthosting.co.za>
New submission from Thomas Klausner <tk at giga.or.at>:
Mac/BuildScript/scripts/postflight.patch-profile and Misc/build.sh
contain the unportable bash(1) "==" comparison operator for test(1). It
is not supported by most other shells or even test(1) from GNU
coreutils. Please use "=" instead.
----------
components: Build
files: test.1.patch
keywords: patch
messages: 94305
nosy: wiz
severity: normal
status: open
title: Unportable test(1) construct
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15170/test.1.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7179>
_______________________________________
From report at bugs.python.org Wed Oct 21 08:43:17 2009
From: report at bugs.python.org (Kevin Grant)
Date: Wed, 21 Oct 2009 06:43:17 +0000
Subject: [New-bugs-announce] [issue7180] "pydoc -k" can generate
AttributeError on Mac OS X
In-Reply-To: <1256107397.12.0.192527244395.issue7180@psf.upfronthosting.co.za>
Message-ID: <1256107397.12.0.192527244395.issue7180@psf.upfronthosting.co.za>
New submission from Kevin Grant <kmg at mac.com>:
Running "pydoc -k ..." with a query string will end with a Python AttributeError while looking for Carbon.File.FSSpecType.
I was using /usr/bin/pydoc on Mac OS X Snow Leopard, which is from Python 2.6.1.
It appears that any query will produce a similar error, but here is one case:
% pydoc -k example
xxsubtype - xxsubtype is an example module showing how to subtype builtin types from C.
doctest - Module doctest -- a framework for running examples in docstrings.
Traceback (most recent call last):
File "/usr/bin/pydoc2.6", line 7, in <module>
pydoc.cli()
File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/pydoc.py", line 2216, in cli
apropos(val)
File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/pydoc.py", line 1911, in apropos
ModuleScanner().run(callback, key)
File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/pydoc.py", line 1876, in run
for importer, modname, ispkg in pkgutil.walk_packages(onerror=onerror):
File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/pkgutil.py", line 110, in walk_packages
__import__(name)
File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/lib-
scriptpackages/CodeWarrior/__init__.py", line 8, in <module>
import aetools
File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/aetools.py", line 36, in <module>
from aepack import packkey, pack, unpack, coerce, AEDescType
File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/aepack.py", line 61, in <module>
FSSType = Carbon.File.FSSpecType
AttributeError: 'module' object has no attribute 'FSSpecType'
A solution would appear to be as follows:
Since Carbon.File no longer defines FSSpecType, perhaps aepack.py should no longer support it. This would require removing
the definition from aepack.py:61, as well as the case in the pack() routine (at aepack.py:88-89) that uses FSSType.
----------
assignee: ronaldoussoren
components: Macintosh
messages: 94307
nosy: kmgrant, ronaldoussoren
severity: normal
status: open
title: "pydoc -k" can generate AttributeError on Mac OS X
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7180>
_______________________________________
From report at bugs.python.org Wed Oct 21 14:50:22 2009
From: report at bugs.python.org (Cristian Romanescu)
Date: Wed, 21 Oct 2009 12:50:22 +0000
Subject: [New-bugs-announce] [issue7181] No logging when two loggers with
same qualname
In-Reply-To: <1256129422.09.0.787842545127.issue7181@psf.upfronthosting.co.za>
Message-ID: <1256129422.09.0.787842545127.issue7181@psf.upfronthosting.co.za>
New submission from Cristian Romanescu <cristiroma at yahoo.com>:
Hello, everyone. I think I have found a bug in the python logging module
when configured via fileConfig
Scenario 1:
When using the configuration file attached to this ticket and test case
below, there should be logging in three places:
* console (info and error)
* 'butterfly.log' (info and error)
* 'butterfly-error (error)
In third no output is ever written.
Scenario 2:
Another odd thing is that when using
keys=root,errorLogger,normalLogger - root and normalLogger works
correct, errorLogger not,
but if I use keys=root,normalLogger,errorLogger - root and errorLogger
works fine, normalLogger not. So there is a link between order of logger
definition?
Scenarion 3:
If I change to one of the loggers qualname=butterfly.test then both
loggers works fine.
Platform: Windows XP + SP2
Python: 2.5.4
Test case:
import logging
from logging import config
config.fileConfig('logging.cristiroma.config')
log = logging.getLogger('butterfly.test')
log.info('info')
log.error('error')
Output:
Console:
2009-10-21 15:38:48 INFO butterfly.test info
2009-10-21 15:38:48 ERROR butterfly.test error
butterfly.log:
2009-10-21 15:40:32 INFO butterfly.test test.py:<module>:7 info
2009-10-21 15:40:32 ERROR butterfly.test test.py:<module>:8 error
butterfly-error.log:
Nothing
P.S. This is my first bug submission, tried to google about it. Please
don't shoot.
Regards,
Cristian.
----------
components: Library (Lib), Windows
files: logging.cristiroma.config
messages: 94310
nosy: cristiroma
severity: normal
status: open
title: No logging when two loggers with same qualname
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file15172/logging.cristiroma.config
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7181>
_______________________________________
From report at bugs.python.org Wed Oct 21 19:49:02 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 21 Oct 2009 17:49:02 +0000
Subject: [New-bugs-announce] [issue7182] For non-debug builds,
the cygwinccompiler.py should define NDEBUG
In-Reply-To: <1256147342.16.0.0286188762329.issue7182@psf.upfronthosting.co.za>
Message-ID: <1256147342.16.0.0286188762329.issue7182@psf.upfronthosting.co.za>
New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:
Currently, msvccompiler.py defines NDEBUG for non-debug builds. Unix
builds do as well, via python-config. However, cygwinccompiler.py does not.
----------
assignee: tarek
components: Distutils
messages: 94315
nosy: stutzbach, tarek
severity: normal
status: open
title: For non-debug builds, the cygwinccompiler.py should define NDEBUG
versions: Python 2.5, 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/issue7182>
_______________________________________
From report at bugs.python.org Thu Oct 22 01:22:37 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Wed, 21 Oct 2009 23:22:37 +0000
Subject: [New-bugs-announce] [issue7183] did 2.6.3 regress for some uses of
the __doc__ property?
In-Reply-To: <1256167357.49.0.413782567423.issue7183@psf.upfronthosting.co.za>
Message-ID: <1256167357.49.0.413782567423.issue7183@psf.upfronthosting.co.za>
New submission from Zooko O'Whielacronx <zooko at zooko.com>:
According to
https://bugs.edge.launchpad.net/ubuntu/+source/boost1.38/+bug/457688 ,
Python 2.6.3 stopped working for something that Python 2.6.2 worked for,
involving Boost.
Andrew Mitchell looked at the Python 2.6.3 release notes, saw
http://bugs.python.org/issue5890 which was fixed by
http://svn.python.org/view/python/branches/release26-
maint/Objects/descrobject.c?r1=71756&r2=72302&pathrev=72302 . Could this
patch be causing this problem?
----------
components: Interpreter Core
messages: 94329
nosy: zooko
severity: normal
status: open
title: did 2.6.3 regress for some uses of the __doc__ property?
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7183>
_______________________________________
From report at bugs.python.org Thu Oct 22 02:16:20 2009
From: report at bugs.python.org (Richard Jones)
Date: Thu, 22 Oct 2009 00:16:20 +0000
Subject: [New-bugs-announce] [issue7184] build failures on Snow Leopard
In-Reply-To: <1256170580.09.0.19194872492.issue7184@psf.upfronthosting.co.za>
Message-ID: <1256170580.09.0.19194872492.issue7184@psf.upfronthosting.co.za>
New submission from Richard Jones <richardjones at optushome.com.au>:
I'm using python 2.6 maint SVN r75588 and get the attached build log
when I run:
configure --enable-framework
make
Failed to build these modules:
_curses _curses_panel _tkinter
readline
----------
components: Build
files: python-r75588-build.log
messages: 94331
nosy: richard
severity: normal
status: open
title: build failures on Snow Leopard
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file15178/python-r75588-build.log
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7184>
_______________________________________
From report at bugs.python.org Thu Oct 22 12:46:06 2009
From: report at bugs.python.org (Istvan Szirtes)
Date: Thu, 22 Oct 2009 10:46:06 +0000
Subject: [New-bugs-announce] [issue7185] csv reader utf-8 BOM error
In-Reply-To: <1256208366.7.0.205796618954.issue7185@psf.upfronthosting.co.za>
Message-ID: <1256208366.7.0.205796618954.issue7185@psf.upfronthosting.co.za>
New submission from Istvan Szirtes <istvan.szirtes at gmail.com>:
The CSV module try to read a .csv file which is coded in utf-8 with utf-
8 BOM.
The first row in the csv file is
["value","vocal","vocal","vocal","vocal"]
in hex:
???"value","vocal","vocal","vocal","vocal"
the reader can not read corectly the first row and if I try to seek up
to 0 somewhere in the file I got an error like this:
['\ufeff"value"', 'vocal', 'vocal', 'vocal', 'vocal']
I think the csv reader is not seekable correctly.
I attached a test file for the bug and here is my code:
import codecs
import csv
InDistancesFile = codecs.open( '..\\distances.csv', 'r', encoding='utf-
8' )
InDistancesObj = csv.reader( InDistancesFile )
for Row in InDistancesObj:
if Row[0] == '20':
print(Row)
break
InDistancesFile.seek(0)
for Row in InDistancesObj:
print(Row)
----------
components: Unicode
files: distances.csv
messages: 94340
nosy: W00D00
severity: normal
status: open
title: csv reader utf-8 BOM error
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file15182/distances.csv
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7185>
_______________________________________
From report at bugs.python.org Thu Oct 22 21:47:35 2009
From: report at bugs.python.org (steve steiner)
Date: Thu, 22 Oct 2009 19:47:35 +0000
Subject: [New-bugs-announce] [issue7186] Document specialness of __doc__,
and possibly other "special" attributes
In-Reply-To: <1256240855.61.0.550470965616.issue7186@psf.upfronthosting.co.za>
Message-ID: <1256240855.61.0.550470965616.issue7186@psf.upfronthosting.co.za>
New submission from steve steiner <ssteiner at users.sourceforge.net>:
Around the time of the 2.6.4 release, it was suggested that Python 2.6.3
changed the __doc__ attribute to read-only. See:
http://bugs.python.org/issue7183
When asked whether this read-only behaviour was intentional, Guido
answered, simply "Yes" and also wrote:
On Oct 22, 2009, at 1:58 PM, Guido van Rossum wrote:
Well __doc__ isn't a normal attribute -- it doesn't follow inheritance
rules.
I suggested that it might be helpful to document this "special"
behaviour and also any other attributes that are "special" though which
ones they might be are unknown at this time.
----------
assignee: georg.brandl
components: Documentation
messages: 94369
nosy: georg.brandl, ssteiner
severity: normal
status: open
title: Document specialness of __doc__, and possibly other "special" attributes
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7186>
_______________________________________
From report at bugs.python.org Thu Oct 22 22:37:07 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 22 Oct 2009 20:37:07 +0000
Subject: [New-bugs-announce] [issue7187] importlib/_bootstrap.py
write_bytecode fails if it can't open the .pyc file for writing
In-Reply-To: <1256243827.37.0.0884595993995.issue7187@psf.upfronthosting.co.za>
Message-ID: <1256243827.37.0.0884595993995.issue7187@psf.upfronthosting.co.za>
New submission from Dave Malcolm <dmalcolm at redhat.com>:
I'm working on an RPM package of Python 3.1.1 for Fedora [1]. Within my RPMs are
precompiled .pyc and .pyo files that are not writable by users, and are hardlinked
together if they have equal content. For example:
$ ls -al /usr/lib/python3.1/tkinter/__init__.*
-rw-r--r--. 1 root root 157859 2009-10-22 15:43
/usr/lib/python3.1/tkinter/__init__.py
-rw-r--r--. 2 root root 226817 2009-10-22 15:42
/usr/lib/python3.1/tkinter/__init__.pyc
-rw-r--r--. 2 root root 226817 2009-10-22 15:42
/usr/lib/python3.1/tkinter/__init__.pyo
I see numerous IOError permission errors running the regression test suite, with
importlib/_bootstrap.py trying and failing to open the .pyc files for writing.
The IOError bubbles up each time and causes the test to fail.
Here's a minimal reproducer (assuming such an install as above)
>>> from tkinter import Tcl
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.1/importlib/_bootstrap.py", line 151, in decorated
return fxn(self, module)
File "/usr/lib/python3.1/importlib/_bootstrap.py", line 399, in load_module
return self._load_module(module)
File "/usr/lib/python3.1/importlib/_bootstrap.py", line 324, in _load_module
code_object = self.get_code(module.__name__)
File "/usr/lib/python3.1/importlib/_bootstrap.py", line 443, in get_code
self.write_bytecode(fullname, data)
File "/usr/lib/python3.1/importlib/_bootstrap.py", line 171, in inner
return method(self, name, *args, **kwargs)
File "/usr/lib/python3.1/importlib/_bootstrap.py", line 525, in write_bytecode
file = _io.FileIO(bytecode_path, 'w') # Assuming bytes.
IOError: [Errno 13] Permission denied: '/usr/lib/python3.1/tkinter/__init__.pyc'
Upon investigating Lib/importlib/_bootstrap.py, the logic for handling permission
errors in "write_bytecode" appears to be wrong:
- the initializer for _io.FileIO can raise an "IOError" if it can't open the
.pyc file for writing
- see Modules/_io/fileio.c:fileio_init, the exception is indeed raised if the
call to:
self->fd = open(name, flags, 0666);
fails.
So it looks like the try/except clause needs to be extended to also cover opening
the file for writing, as well as writing the bytes to it.
I'm attaching a patch that makes this change.
With this change, the above failing import succeeds, and an invocation of
/usr/lib/python3.1/test/regrtest.py improves from:
276 tests OK.
39 tests failed:
test_cmd_line test_codeccallbacks test_codecencodings_cn
test_codecencodings_hk test_codecencodings_jp
test_codecencodings_kr test_codecencodings_tw test_cprofile
test_distutils test_docxmlrpc test_email test_heapq
test_htmlparser test_httpservers test_imp test_lib2to3
test_linecache test_modulefinder test_multiprocessing test_osx_env
test_plistlib test_pyclbr test_pydoc test_runpy test_socket
test_sqlite test_sundry test_tcl test_threading_local test_tk
test_ttk_guionly test_ttk_textonly test_uuid test_warnings
test_wsgiref test_xml_etree_c test_xmlrpc test_xmlrpc_net
test_zipfile
to:
304 tests OK.
10 tests failed:
test_email test_httpservers test_imp test_lib2to3 test_linecache
test_socket test_tk test_ttk_guionly test_ttk_textonly
test_zipfile
(I'm working on these other failures; some of them are due to errors in my
packaging)
FWIW the initial checkin of py3k/Lib/importlib/_bootstrap.py appears to have the
initialization of the FileIO outside the try/except block:
http://svn.python.org/view/python/branches/py3k/Lib/importlib/_bootstrap.py?
view=markup&pathrev=68698
though at that time it was _fileio._FileIO, rather than _io.FileIO. (did FileIO
only test for perms upon writing, and change behavior to test upon opening? or
has this case always led to this failure? or am I misreading this?)
Thanks
Dave
[1] https://bugzilla.redhat.com/show_bug.cgi?id=526126
----------
components: Library (Lib)
files: python-3.1.1-importlib-fix-handling-of-readonly-pyc-files.patch
keywords: patch
messages: 94371
nosy: dmalcolm
severity: normal
status: open
title: importlib/_bootstrap.py write_bytecode fails if it can't open the .pyc file for writing
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file15185/python-3.1.1-importlib-fix-handling-of-readonly-pyc-files.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7187>
_______________________________________
From report at bugs.python.org Fri Oct 23 09:36:23 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 23 Oct 2009 07:36:23 +0000
Subject: [New-bugs-announce] [issue7188] optionxform documentation confusing
In-Reply-To: <1256283382.97.0.071138181483.issue7188@psf.upfronthosting.co.za>
Message-ID: <1256283382.97.0.071138181483.issue7188@psf.upfronthosting.co.za>
New submission from Martin v. L?wis <martin at v.loewis.de>:
In
http://stackoverflow.com/questions/1611799/preserve-case-in-configparser, somebody
is confused about adjusting ConfigParser.optionxform. The documentation
is indeed confusing, in particular by claiming that you should "set" it
to "str()". Even if you get what is meant by "setting" (i.e. not
"calling"), it's still nonsensical to suggest that it should be set to
an empty string.
----------
assignee: georg.brandl
components: Documentation
messages: 94375
nosy: georg.brandl, loewis
severity: normal
status: open
title: optionxform documentation confusing
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7188>
_______________________________________
From report at bugs.python.org Fri Oct 23 12:24:28 2009
From: report at bugs.python.org (Igor Mikushkin)
Date: Fri, 23 Oct 2009 10:24:28 +0000
Subject: [New-bugs-announce] [issue7189] struct.calcsize returns strange size
In-Reply-To: <1256293468.22.0.147558321508.issue7189@psf.upfronthosting.co.za>
Message-ID: <1256293468.22.0.147558321508.issue7189@psf.upfronthosting.co.za>
New submission from Igor Mikushkin <igor.mikushkin at gmail.com>:
I think in second case struct size should be 53.
In [31]: struct.calcsize('ihhi35scc')
Out[31]: 49
In [32]: struct.calcsize('ihhi35scci')
Out[32]: 56
----------
components: Library (Lib)
messages: 94379
nosy: igor.mikushkin
severity: normal
status: open
title: struct.calcsize returns strange size
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7189>
_______________________________________
From report at bugs.python.org Fri Oct 23 15:25:35 2009
From: report at bugs.python.org (Justin)
Date: Fri, 23 Oct 2009 13:25:35 +0000
Subject: [New-bugs-announce] [issue7190] TCP/IP?
In-Reply-To: <1256304335.58.0.401726660666.issue7190@psf.upfronthosting.co.za>
Message-ID: <1256304335.58.0.401726660666.issue7190@psf.upfronthosting.co.za>
New submission from Justin <shmee8000 at yahoo.com>:
Mac OS X
IBook G4 PowerPC
when running target.py it works fine until i close the app without
ending the process. (before 'q' is entered by the user). sometimes
python will not allow the user to click in the window and have the
ability to type after running the target window. sometimes the mouse
clicks affect a part of IDLE up and left of where the actual click was.
when i ignore this error (this is the only thing i have open in IDLE) i
must fist close out of python and reopen target.py i have used this
approach to test and find that there are no bugs in my program (at least
it works above and beyond the specifications of my class assignment),
but every once in while i will get an error when trying to use 'q' to
end the program and python will state that win.getMouse() is not a
viable term to use, because (win) is already closed yet when 'q' is used
the if statement has the close command right underneath the get mouse
command.
*note* i have coded another program specifically from John Zelle's
"Python Programming: An Introduction to Computer Science" p.160
programming exercise #1 and my get display text, get mouse, then close
window is verbatim from that in target.py and it never showed an error
in the #1's program
IDLE can't bind TCP/IP port 8833, which is necessary to communicate with
its Python execution server. Either no networking is installed on this
computer or another process (another IDLE?) is using the port. Run IDLE
with the -n command line switch to start without a subprocess and refer
to Help/IDLE Help 'Running without a subprocess' for further details.
----------
assignee: ronaldoussoren
components: Macintosh
files: target.py
messages: 94385
nosy: jlr2383, ronaldoussoren
severity: normal
status: open
title: TCP/IP?
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file15187/target.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7190>
_______________________________________
From report at bugs.python.org Fri Oct 23 15:40:57 2009
From: report at bugs.python.org (Anand B Pillai)
Date: Fri, 23 Oct 2009 13:40:57 +0000
Subject: [New-bugs-announce] [issue7191] Odd behaviour with
zlib.decompressobj optional parameter "wbits"
In-Reply-To: <1256305257.34.0.885450394278.issue7191@psf.upfronthosting.co.za>
Message-ID: <1256305257.34.0.885450394278.issue7191@psf.upfronthosting.co.za>
New submission from Anand B Pillai <abpillai at gmail.com>:
>>> import zlib
>>> help(zlib.decompressobj)
Help on built-in function decompressobj in module zlib:
decompressobj(...)
decompressobj([wbits]) -- Return a decompressor object.
Optional arg wbits is the window buffer size.
I experimented with this parameter and by trial and
error found out that it accepts only values from 8 to
15 inclusive.
>>> z=zlib.decompressobj(1)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: Invalid initialization option
>>> z=zlib.decompressobj(7)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: Invalid initialization option
>>> z=zlib.decompressobj(16)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: Invalid initialization option
>>> z1=zlib.decompressobj(8)
>>> z2=zlib.decompressobj(15)
Now to the odd part. Let us create another decompressobj without any
parameter.
>>> z3=zlib.decompressobj()
Now compress some data.
>>> c=zlib.compress("This is a medium line of text")
Decompress with z2 works fine.
>>> z3.decompress(c)
b'This is a medium line of text'
Decompress with z2 is also fine.
>>> z2.decompress(c)
b'This is a medium line of text'
However with z1 it fails.
>>> z1.decompress(c)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
zlib.error: Error -3 while decompressing: invalid window size
In fact, only the optional value of 15 seems to work
for wbits, every other legal value (8-14) fails giving
the same error. I tried this with other random strings
with same effect.
Either there is no need to expose this as a parameter
or there could be a bug with how this parameter is used,
which has to be fixed. In either case, documentation
on this parameter has to be improved and legal range
of values should be provided.
----------
components: Library (Lib)
messages: 94386
nosy: pythonhacker
severity: normal
status: open
title: Odd behaviour with zlib.decompressobj optional parameter "wbits"
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7191>
_______________________________________
From report at bugs.python.org Fri Oct 23 16:07:37 2009
From: report at bugs.python.org (Andrew Dalke)
Date: Fri, 23 Oct 2009 14:07:37 +0000
Subject: [New-bugs-announce] [issue7192] webbrowser.get("firefox") does not
work on Mac with installed Firefox
In-Reply-To: <1256306857.19.0.981560840081.issue7192@psf.upfronthosting.co.za>
Message-ID: <1256306857.19.0.981560840081.issue7192@psf.upfronthosting.co.za>
New submission from Andrew Dalke <dalke at dalkescientific.com>:
I have Firefox and Safari installed on my Mac. Safari is the default.
I wanted to try out Crunchy (http://code.google.com/p/crunchy/). It's
developed under Firefox and does not work under Safari. I tried. ;)
It starts the web browser with the following.
try:
client = webbrowser.get("firefox")
client.open(url)
return
except:
try:
client = webbrowser.get()
client.open(url)
return
except:
print('Please open %s in Firefox.' % url)
On my Mac, webbrowser.get("firefox") fails, so this ends up opening in
Safari. Which does not work to view the code.
Thing is, I have Firefox installed, so it should work. But the Mac code in
webbrowser appears to only open in the default browser.
The following bit of code works well enough to get crunchy to work
class MacOSXFirefox(BaseBrowser):
def open(self, url, new=0, autoraise=True):
subprocess.check_call(["/usr/bin/open", "-b",
"org.mozilla.firefox", url])
register("firefox", None, MacOSXFirefox('firefox'), -1)
but I don't know enough about the Mac nor about webbrowser to know if I'm
the right path. For example, I don't know if there are ways to support
'new' and 'autoraise' through /usr/bin/open or if there's a better
solution.
Attached is the full diff.
----------
components: Library (Lib)
files: webbrowser.py.diff
keywords: patch
messages: 94387
nosy: dalke
severity: normal
status: open
title: webbrowser.get("firefox") does not work on Mac with installed Firefox
type: feature request
Added file: http://bugs.python.org/file15188/webbrowser.py.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7192>
_______________________________________
From report at bugs.python.org Fri Oct 23 17:47:38 2009
From: report at bugs.python.org (Dan Griffin)
Date: Fri, 23 Oct 2009 15:47:38 +0000
Subject: [New-bugs-announce] [issue7193] Popen blocks program from another
thread
In-Reply-To: <1256312858.52.0.307226158644.issue7193@psf.upfronthosting.co.za>
Message-ID: <1256312858.52.0.307226158644.issue7193@psf.upfronthosting.co.za>
New submission from Dan Griffin <dgriff1 at gmail.com>:
When I create a thread that does a Popen it blocks the entire program. I
have attached a simple sample program. Whether I do Popen.wait or
Popen.poll the program blocks. I have done this on OSX 10.5 and 10.6. I
have not yet tried ussing the multiprocessing module.
----------
components: Library (Lib)
files: subproc.py
messages: 94389
nosy: dgriff1
severity: normal
status: open
title: Popen blocks program from another thread
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15189/subproc.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7193>
_______________________________________
From report at bugs.python.org Fri Oct 23 20:20:47 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Oct 2009 18:20:47 +0000
Subject: [New-bugs-announce] [issue7194] test_thread is flaky
In-Reply-To: <1256322047.39.0.394218490419.issue7194@psf.upfronthosting.co.za>
Message-ID: <1256322047.39.0.394218490419.issue7194@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
test_thread sometimes tries to release an unacquired mutex. It is easier
to reproduce when using the "-j" option (on trunk and py3k, since the
option doesn't exist on 2.6/3.1):
./python -m test.regrtest -j4 test_thread test_thread test_thread
test_thread
test_thread
test_thread
test_thread
Unhandled exception in thread started by <bound method
ThreadRunningTests.task of <test.test_thread.ThreadRunningTests
testMethod=test_stack_size>>
Traceback (most recent call last):
File "/home/antoine/py3k/__svn__/Lib/test/test_thread.py", line 49, in
task
self.done_mutex.release()
_thread.error: release unlocked lock
test_thread
----------
components: Library (Lib), Tests
messages: 94392
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_thread is flaky
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/issue7194>
_______________________________________
From report at bugs.python.org Fri Oct 23 23:39:23 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 23 Oct 2009 21:39:23 +0000
Subject: [New-bugs-announce] [issue7195] Value error 'path is on drive c:
start on drive d:' in os.path.relpath
In-Reply-To: <1256333963.61.0.85026079779.issue7195@psf.upfronthosting.co.za>
Message-ID: <1256333963.61.0.85026079779.issue7195@psf.upfronthosting.co.za>
New submission from Jason R. Coombs <jaraco at jaraco.com>:
A simple test fails:
Python 2.6.3 (r263rc1:75186, Oct 2, 2009, 20:40:30) [MSC v.1500 32 bit
(Intel)] on win32
>>> import os
>>> os.path.relpath('\\bar', 'd:\\')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\python\lib\ntpath.py", line 487, in relpath
% (path_list[0], start_list[0]))
ValueError: path is on drive C:, start on drive d:
If I change the current directory to 'E:\', the error changes to "path
is on drive E:, start on drive d:".
Clearly, relpath is doing some calculations based on the current
directory, although the documentation states that it should be
performing a relative path calculation based on the supplied start
("D:\" in this case).
In Python 3.1.1, the error is "path is on mount 'C:', start on mount 'd:'"
os.path.relpath should be able to perform relative path calculations
regardless of the current directory, or the documentation should explain
why the current directory is relevant when start is supplied.
----------
components: Windows
messages: 94394
nosy: jaraco
severity: normal
status: open
title: Value error 'path is on drive c: start on drive d:' in os.path.relpath
type: behavior
versions: Python 2.6, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7195>
_______________________________________
From report at bugs.python.org Sat Oct 24 06:33:44 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 24 Oct 2009 04:33:44 +0000
Subject: [New-bugs-announce] [issue7196] Clarify str.split() behavior
In-Reply-To: <1256358824.27.0.552818467808.issue7196@psf.upfronthosting.co.za>
Message-ID: <1256358824.27.0.552818467808.issue7196@psf.upfronthosting.co.za>
New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:
Clarify str.split() behavior; see discussion at http://
comments.gmane.org/gmane.comp.python.general/641120
----------
assignee: georg.brandl
components: Documentation
files: stdtypes.diff
keywords: patch
messages: 94401
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: Clarify str.split() behavior
versions: Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15191/stdtypes.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7196>
_______________________________________
From report at bugs.python.org Sat Oct 24 13:13:45 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Oct 2009 11:13:45 +0000
Subject: [New-bugs-announce] [issue7197] test_multiprocessing crashes under
Windows when run in verbose mode
In-Reply-To: <1256382825.55.0.179199170316.issue7197@psf.upfronthosting.co.za>
Message-ID: <1256382825.55.0.179199170316.issue7197@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
When run under Windows in verbose mode ("python -m test.regrtest -v
test_multiprocessing"), most tests in test_multiprocessing fail with a
recursion limit error.
The explanation is that most tests are written in the following manner:
class _TestArray(BaseTestCase):
[...]
def test_array(self, raw=False):
[...]
p = self.Process(target=self.f, args=(arr,))
Running a Process under Windows involved pickling it to send it to the
child process. This also pickles the `target` function, which here is a
method of an unittest instance. This consequently pickles the unittest
instance, which has a reference to the unittest runner, which has a
reference to a unittest.runner._WritelnDecorator instance.
The infinite recursion occurs when unpickling the _WritelnDecorator
instance, because the `stream` attribute is not restored when calling
__new__, and the __getattr__ method then recurses when trying to return
`getattr(self.stream,attr)`.
I see two possible resolutions:
- make unittest.runner._WritelnDecorator properly (un)pickleable
- change all tests in test_multiprocessing to avoid pickling instances
of unittest.TestCase
The former is simpler and probably more future-proof than the latter.
(NB: in non-verbose mode, test.support uses a custom test runner which
doesn't involve the _WritelnDecorator)
Appendix: here is a traceback example (noticed on the newgil branch but
it really happens on stock trunk and py3k):
test_notify (test.test_multiprocessing.WithProcessesTestCondition) ...
Traceback
(most recent call last):
File "<string>", line 1, in <module>
File "Z:\py3k\newgil\lib\multiprocessing\forking.py", line 339, in main
self = load(from_parent)
File "Z:\py3k\newgil\lib\pickle.py", line 1365, in load
encoding=encoding, errors=errors).load()
File "Z:\py3k\newgil\lib\unittest\runner.py", line 21, in __getattr__
return getattr(self.stream,attr)
File "Z:\py3k\newgil\lib\unittest\runner.py", line 21, in __getattr__
return getattr(self.stream,attr)
File "Z:\py3k\newgil\lib\unittest\runner.py", line 21, in __getattr__
return getattr(self.stream,attr)
[... snipped ...]
RuntimeError: maximum recursion depth exceeded while calling a Python
object
----------
components: Library (Lib), Tests
messages: 94406
nosy: jnoller, michael.foord, pitrou
priority: high
severity: normal
status: open
title: test_multiprocessing crashes under Windows when run in verbose mode
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/issue7197>
_______________________________________
From report at bugs.python.org Sun Oct 25 00:07:03 2009
From: report at bugs.python.org (Bob Cannon)
Date: Sat, 24 Oct 2009 22:07:03 +0000
Subject: [New-bugs-announce] [issue7198] csv.writer
Message-ID: <1256422023.94.0.440310821765.issue7198@psf.upfronthosting.co.za>
Changes by Bob Cannon <bob at neqn.net>:
----------
nosy: zacktu
severity: normal
status: open
title: csv.writer
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7198>
_______________________________________
From report at bugs.python.org Sun Oct 25 00:58:51 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Oct 2009 22:58:51 +0000
Subject: [New-bugs-announce] [issue7199] Doc: Logging level order seems
inconsistent
In-Reply-To: <1256425131.73.0.619062754292.issue7199@psf.upfronthosting.co.za>
Message-ID: <1256425131.73.0.619062754292.issue7199@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
LibRef 15.6, Logging module:
<Assigned to Vinay because I understand you to be the current maintainer
of logging. If wrong, please reassign.>
Intro start with "The default levels provided are DEBUG, INFO, WARNING,
ERROR and CRITICAL." which seems like the proper ordering. Then
15.6.1.1. Simple examples
"Another useful feature of the logging API is the ability to produce
different messages at different log levels. This allows you to
instrument your code with debug messages, for example, but turning the
log level down so that those debug messages are not written for your
production system. The default levels are CRITICAL, ERROR, WARNING,
INFO, DEBUG and NOTSET.
The logger, handler, and log message call each specify a level. The log
message is only emitted if the handler and logger are configured to emit
messages of that level or lower. "
Ie, the order is reversed and the level specified is the highest level
emitted, which struck me as backwards, versus
15.6.1.2. Loggers
"Logger.setLevel() specifies the lowest-severity log message a logger
will handle, where debug is the lowest built-in severity level and
critical is the highest built-in severity. "
so that it emits the that level or *higher*.
(although notset is the actual lowest built-in.)
Reading further, I see that the builtin levels range for NOTSET=0 to
CRITICAL=50 (15.6.2. Logging Levels), so I think the first quote should
be changed to
"Another useful feature of the logging API is the ability to produce
different messages at different log levels. This allows you to
instrument your code with debug messages, for example, but turning the
log level up so that those debug messages are not written for your
production system. The default levels are NOTSET, DEBUG, INFO, WARNING,
ERROR, and CRITICAL.
The logger, handler, and log message call each specify a level. The log
message is only emitted if the handler and logger are configured to emit
messages of that level or higher. "
I have not checked the rest of the doc for other backwards passages.
----------
assignee: vinay.sajip
components: Library (Lib)
messages: 94439
nosy: tjreedy, vinay.sajip
severity: normal
status: open
title: Doc: Logging level order seems inconsistent
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7199>
_______________________________________
From report at bugs.python.org Sun Oct 25 01:10:37 2009
From: report at bugs.python.org (Brian Quinlan)
Date: Sat, 24 Oct 2009 23:10:37 +0000
Subject: [New-bugs-announce] [issue7200] multiprocessing deadlock on Mac OS
X when queue collected before process terminates
In-Reply-To: <1256425837.07.0.628633816678.issue7200@psf.upfronthosting.co.za>
Message-ID: <1256425837.07.0.628633816678.issue7200@psf.upfronthosting.co.za>
New submission from Brian Quinlan <brian at sweetapp.com>:
This code:
import multiprocessing
import queue
def _process_worker(q):
while True:
try:
something = q.get(block=True, timeout=0.1)
except queue.Empty:
return
else:
pass
# print('Grabbed item from queue:', something)
def _make_some_processes(q):
processes = []
for _ in range(10):
p = multiprocessing.Process(target=_process_worker, args=(q,))
p.start()
processes.append(p)
return processes
#p = []
def _do(i):
print('Run:', i)
q = multiprocessing.Queue()
# p.append(q)
print('Created queue')
for j in range(30):
q.put(i*30+j)
processes = _make_some_processes(q)
print('Created processes')
while not q.empty():
pass
print('Q is empty')
for i in range(100):
_do(i)
Produces this output on Mac OS X (it produces the expected output on
Linux and Windows):
Run: 0
Created queue
Grabbed item from queue: 0
...
Grabbed item from queue: 29
Created processes
Q is empty
Run: 1
Created queue
Grabbed item from queue: 30
...
Grabbed item from queue: 59
Created processes
Q is empty
Run: 2
Created queue
Created processes
<no further output>
Changing the code as follows:
+ p = []
def _do(i):
print('Run:', i)
q = multiprocessing.Queue()
+ p.append(q)
print('Created queue')
for j in range(30):
q.put(i*30+j)
processes = _make_some_processes(q)
print('Created processes')
while not q.empty():
pass
print('Q is empty')
fixes the deadlock. So it looks like if a multiprocessing.Queue is
collected with sub-processes still using it then calling some methods on
other multiprocessing.Queues with deadlock.
----------
components: Library (Lib)
messages: 94440
nosy: bquinlan
severity: normal
status: open
title: multiprocessing deadlock on Mac OS X when queue collected before process terminates
type: behavior
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7200>
_______________________________________
From report at bugs.python.org Sun Oct 25 01:52:40 2009
From: report at bugs.python.org (Mancausoft)
Date: Sat, 24 Oct 2009 23:52:40 +0000
Subject: [New-bugs-announce] [issue7201] double Endian problem and more on
arm
In-Reply-To: <1256428360.64.0.458398001505.issue7201@psf.upfronthosting.co.za>
Message-ID: <1256428360.64.0.458398001505.issue7201@psf.upfronthosting.co.za>
New submission from Mancausoft <bug at mancausoft.org>:
I compile python for arm (on debian etch) but it don't pass ctype
test:
======================================================================
FAIL: test_struct_return_2H
(ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/mnt/root/stackless-2.6.3/Lib/ctypes/test/test_as_parameter.py", line
171, in test_struct_return_2H
self.failUnlessEqual((s2h.x, s2h.y), (99*2, 88*3))
AssertionError: (99, 88) != (198, 264)
======================================================================
FAIL: test_struct_return_2H
(ctypes.test.test_as_parameter.AsParamWrapperTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/mnt/root/stackless-2.6.3/Lib/ctypes/test/test_as_parameter.py", line
171, in test_struct_return_2H
self.failUnlessEqual((s2h.x, s2h.y), (99*2, 88*3))
AssertionError: (99, 88) != (198, 264)
======================================================================
FAIL: test_struct_return_2H
(ctypes.test.test_as_parameter.BasicWrapTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/mnt/root/stackless-2.6.3/Lib/ctypes/test/test_as_parameter.py", line
171, in test_struct_return_2H
self.failUnlessEqual((s2h.x, s2h.y), (99*2, 88*3))
AssertionError: (99, 88) != (198, 264)
======================================================================
FAIL: test_endian_double (ctypes.test.test_byteswap.Test)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/mnt/root/stackless-2.6.3/Lib/ctypes/test/test_byteswap.py",
line 137, in test_endian_double
self.failUnlessEqual(bin(struct.pack("<d", math.pi)), bin(s))
AssertionError: '182D4454FB210940' != 'FB210940182D4454'
======================================================================
FAIL: test_unaligned_native_struct_fields
(ctypes.test.test_byteswap.Test)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/mnt/root/stackless-2.6.3/Lib/ctypes/test/test_byteswap.py",
line 277, in test_unaligned_native_struct_fields
self.failUnlessEqual(bin(s1), bin(s2))
AssertionError: '123412007856341200B81E09401F85EB51' !=
'1234120078563412001F85EB51B81E0940'
----------
assignee: theller
components: ctypes
messages: 94444
nosy: mancausoft, theller
severity: normal
status: open
title: double Endian problem and more on arm
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7201>
_______________________________________
From report at bugs.python.org Sun Oct 25 15:37:08 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Sun, 25 Oct 2009 14:37:08 +0000
Subject: [New-bugs-announce] [issue7202] "python setup.py MYCOMMAND
--verbose" does not yield an unrecognized option error but
also does not set the verbosity
In-Reply-To: <1256481428.97.0.691214379627.issue7202@psf.upfronthosting.co.za>
Message-ID: <1256481428.97.0.691214379627.issue7202@psf.upfronthosting.co.za>
New submission from Zooko O'Whielacronx <zooko at zooko.com>:
This command:
python setup.py --verbose darcsver
works as expected -- the presence of '--verbose' increases the verbosity
of logging.
This command:
python setup.py darcsver --verbose
does not increase the verbosity, nor does it tell me that the
"--verbose" option is an option unknown to the "darcsver" command.
This command:
python setup.py darcsver --quux
gives this helpful output:
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
or: setup.py --help [cmd1 cmd2 ...] or: setup.py --help-commands or:
setup.py cmd --help
error: option --quux not recognized
I think that the middle command ("python setup.py darcsver --verbose")
ought to behave either like the first command by increasing the
verbosity, or like the last command by telling the user that "--verbose"
is not a known option in that position.
This is also http://bitbucket.org/tarek/distribute/issue/78/
----------
assignee: tarek
components: Distutils
messages: 94453
nosy: tarek, zooko
severity: normal
status: open
title: "python setup.py MYCOMMAND --verbose" does not yield an unrecognized option error but also does not set the verbosity
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7202>
_______________________________________
From report at bugs.python.org Sun Oct 25 18:53:26 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 25 Oct 2009 17:53:26 +0000
Subject: [New-bugs-announce] [issue7203] fixer for map(None,
...) needs to consider multi-argument case
In-Reply-To: <1256493206.19.0.96806885999.issue7203@psf.upfronthosting.co.za>
Message-ID: <1256493206.19.0.96806885999.issue7203@psf.upfronthosting.co.za>
New submission from Georg Brandl <georg at python.org>:
Currently, ``map(None, a)`` is recognized and converted to ``list(a)``
which is correct but quite useless.
``map(None, a, b, ...)`` is not treated specially. An approximate
translation would be ``map(lambda *xs: xs, a, b, ...)`` which however
doesn't take into account that the new map cuts after the shortest
sequence instead of "filling up" the shorter ones with Nones.
That should probably produce a warning.
----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 94455
nosy: georg.brandl
priority: high
severity: normal
stage: needs patch
status: open
title: fixer for map(None, ...) needs to consider multi-argument case
type: behavior
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7203>
_______________________________________
From report at bugs.python.org Sun Oct 25 21:01:49 2009
From: report at bugs.python.org (Thomas Klausner)
Date: Sun, 25 Oct 2009 20:01:49 +0000
Subject: [New-bugs-announce] [issue7204] Strange shebang line in test_pep263
In-Reply-To: <1256500909.23.0.301695923413.issue7204@psf.upfronthosting.co.za>
Message-ID: <1256500909.23.0.301695923413.issue7204@psf.upfronthosting.co.za>
New submission from Thomas Klausner <tk at giga.or.at>:
In Python-2.6.3, test_pep263.py starts with the following line:
#! -*- coding: koi8-r -*-
When this is executed by a shell, it looks for the interpreter "-*-".
I guess the '!' is superfluous there, or it should be something like
#! /usr/bin/env python
# -*- coding: koi8-r -*-
instead.
----------
components: Tests
messages: 94458
nosy: wiz
severity: normal
status: open
title: Strange shebang line in test_pep263
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7204>
_______________________________________
From report at bugs.python.org Sun Oct 25 22:55:54 2009
From: report at bugs.python.org (Robert Collins)
Date: Sun, 25 Oct 2009 21:55:54 +0000
Subject: [New-bugs-announce] [issue7205] bz2file deadlock
In-Reply-To: <1256507754.86.0.545134749943.issue7205@psf.upfronthosting.co.za>
Message-ID: <1256507754.86.0.545134749943.issue7205@psf.upfronthosting.co.za>
New submission from Robert Collins <robertc at robertcollins.net>:
There is a systemic bug in BZ2File where the GIL is released to perform
compression work, and any other thread calling into BZ2File will
deadlock. We noticed in the write method, but inspection of the code
makes it clear that its systemic.
The problem is pretty simple. Say you have two threads and one bz2file
object. One calls write(), the other calls (say) seek(), but it could be
write() or other methods too. Now, its pretty clear that the question
'should these two threads get serialised' could be contentious. So lets
put that aside by saying 'raising an exception or serialising in
arbitrary order would be ok'.
What happens today is:
t1:bz2file.write
bz2file.lock.acquire
gil-release
bz2compression starts
t2:gil-acquired
bz2file.seek
bz2file.lock.acquire(wait=1) <- this thread is stuck now, and has
the GIL
t1:bz2compression finishes
gil.acquire <- this thread is stuck now, waiting for the GIL
If any owner of the bz2file object lock will release the GIL, *all*
routines that attempt to lock the bz2file object have to release the GIL
if they can't get the lock - blocking won't work. I'm not familiar
enough with the python threading API to know whether its safe to call
without the GIL. If its not then clearly it can't be used to work with
getting the GIL, and lower layer locks should be used.
----------
components: Extension Modules
files: bz2fail.py
messages: 94462
nosy: barry, rbcollins, statik
severity: normal
status: open
title: bz2file deadlock
type: crash
Added file: http://bugs.python.org/file15196/bz2fail.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7205>
_______________________________________
From report at bugs.python.org Mon Oct 26 00:29:17 2009
From: report at bugs.python.org (Rich Healey)
Date: Sun, 25 Oct 2009 23:29:17 +0000
Subject: [New-bugs-announce] [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
New submission from Rich Healey <richo at psych0tik.net>:
64 bit pythons fail on 64 bit Windows 7.
The crash happens with python 2.6 and 3.1 in 64 bit mode. 3.1 was a
clean install after the issue presented itself.
I'm not 100% sure how best to help with the problem, I've attached the
dump from windows debugger, please let me know if there's anything else
I can do to help.
It used to work but I'm not sure what changed, as near as I can tell
nothing system wide did, except perhaps the installation of new
compilers, my thought is that it could alter some dll search path?
Thanks in advance
richo
----------
components: Interpreter Core
files: failedPython.log
messages: 94467
nosy: richo
severity: normal
status: open
title: 64 bit python fails on Windows 7
type: crash
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file15197/failedPython.log
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7206>
_______________________________________
From report at bugs.python.org Mon Oct 26 10:15:12 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 26 Oct 2009 09:15:12 +0000
Subject: [New-bugs-announce] [issue7207] test_telnetlib fails on OS X 10.6
In-Reply-To: <1256548512.29.0.936699598359.issue7207@psf.upfronthosting.co.za>
Message-ID: <1256548512.29.0.936699598359.issue7207@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
test_telnetlib fails consistently on OS X 10.6, for a default (64-bit)
build of py3k. Test output below.
It looks to me as though this is just a race condition in the test
(possibly combined with socket-related peculiarities of OS X) rather
than a problem with telnetlib itself. I suspect that the 'server'
function in test_telnetlib.py is getting to the 'serv.close()' line
prematurely, before all the test data from the 'test_write' test have
been written.
Jack, I notice you've worked on these tests recently. Any ideas?
testBasic (__main__.GeneralTests) ... ok
testTimeoutDefault (__main__.GeneralTests) ... ok
testTimeoutNone (__main__.GeneralTests) ... ok
testTimeoutOpen (__main__.GeneralTests) ... ok
testTimeoutValue (__main__.GeneralTests) ... ok
test_read_all_A (__main__.ReadTests) ... ok
test_read_all_B (__main__.ReadTests) ... ok
test_read_all_C (__main__.ReadTests) ... ok
test_read_eager_A (__main__.ReadTests) ... ok
test_read_eager_B (__main__.ReadTests) ... ok
test_read_lazy_A (__main__.ReadTests) ... ok
test_read_lazy_B (__main__.ReadTests) ... ok
test_read_some_A (__main__.ReadTests) ... ok
test_read_some_B (__main__.ReadTests) ... ok
test_read_some_C (__main__.ReadTests) ... ok
test_read_until_A (__main__.ReadTests) ... ok
test_read_until_B (__main__.ReadTests) ... ok
test_read_very_eager_A (__main__.ReadTests) ... ok
test_read_very_eager_B (__main__.ReadTests) ... ok
test_read_very_lazy_A (__main__.ReadTests) ... ok
test_read_very_lazy_B (__main__.ReadTests) ... ok
test_write (__main__.WriteTests) ... ERROR
test_IAC_commands (__main__.OptionTests) ... ok
test_SB_commands (__main__.OptionTests) ... ok
test_debuglevel_reads (__main__.OptionTests) ... ok
test_debuglevel_write (__main__.OptionTests) ... ok
======================================================================
ERROR: test_write (__main__.WriteTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "Lib/test/test_telnetlib.py", line 347, in test_write
self._test_write(d)
File "Lib/test/test_telnetlib.py", line 332, in _test_write
self.telnet.write(data)
File "/Users/dickinsm/python/svn/py3k/Lib/telnetlib.py", line 280, in
write
self.sock.sendall(buffer)
File "Lib/test/test_telnetlib.py", line 317, in sendall
self.socket.sendall(data)
socket.error: [Errno 32] Broken pipe
----------------------------------------------------------------------
Ran 26 tests in 10.179s
FAILED (errors=1)
Traceback (most recent call last):
File "Lib/test/test_telnetlib.py", line 470, in <module>
test_main()
File "Lib/test/test_telnetlib.py", line 467, in test_main
support.run_unittest(GeneralTests, ReadTests, WriteTests,
OptionTests)
File "/Users/dickinsm/python/svn/py3k/Lib/test/support.py", line 911,
in run_unittest
_run_suite(suite)
File "/Users/dickinsm/python/svn/py3k/Lib/test/support.py", line 894,
in _run_suite
raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
File "Lib/test/test_telnetlib.py", line 347, in test_write
self._test_write(d)
File "Lib/test/test_telnetlib.py", line 332, in _test_write
self.telnet.write(data)
File "/Users/dickinsm/python/svn/py3k/Lib/telnetlib.py", line 280, in
write
self.sock.sendall(buffer)
File "Lib/test/test_telnetlib.py", line 317, in sendall
self.socket.sendall(data)
socket.error: [Errno 32] Broken pipe
----------
components: Tests
messages: 94481
nosy: jackdied, mark.dickinson
severity: normal
stage: needs patch
status: open
title: test_telnetlib fails on OS X 10.6
type: behavior
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7207>
_______________________________________
From report at bugs.python.org Mon Oct 26 15:39:39 2009
From: report at bugs.python.org (Peter Saunders)
Date: Mon, 26 Oct 2009 14:39:39 +0000
Subject: [New-bugs-announce] [issue7208] Getpass echo's password to screen
on 2.6, but not on 2.5 or 3.1
In-Reply-To: <1256567979.01.0.00205480055698.issue7208@psf.upfronthosting.co.za>
Message-ID: <1256567979.01.0.00205480055698.issue7208@psf.upfronthosting.co.za>
New submission from Peter Saunders <pajs at fodder.org.uk>:
Only sucessfully replicated on solaris.
When running getpass() - it goes into non echo mode, however, once enter
is pressed, the password is echoed to the screen. E.g.
> /opt/python/2.6.3/bin/python -c 'import getpass; x=getpass.getpass()'
Password: bob
This does NOT happen on older versions:
> /opt/IBpython/2.5.1/bin/python -c 'import getpass; x=getpass.getpass()'
Password:
/opt/python/2.3.3/bin/python -c 'import getpass; x=getpass.getpass()'
Password:
To stop this occuring for me, simply adding a stream.flush() line
straight after the
finally:
termios.tcsetattr(fd, termios.TCSADRAIN, old)
line fixes the issue:
saundep at ln8u3494inx:[/tmp]> /opt/IBpython/2.6.3/bin/python -c 'import
gp; gp.getpass()'
Password:
----------
components: Library (Lib)
messages: 94488
nosy: pajs at fodder.org.uk
severity: normal
status: open
title: Getpass echo's password to screen on 2.6, but not on 2.5 or 3.1
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7208>
_______________________________________
From report at bugs.python.org Mon Oct 26 17:59:35 2009
From: report at bugs.python.org (Matt Kraai)
Date: Mon, 26 Oct 2009 16:59:35 +0000
Subject: [New-bugs-announce] [issue7209] Prevents uint_t from being used on
QNX
In-Reply-To: <1256576375.9.0.147496102309.issue7209@psf.upfronthosting.co.za>
Message-ID: <1256576375.9.0.147496102309.issue7209@psf.upfronthosting.co.za>
New submission from Matt Kraai <kraai at ftbfs.org>:
pyconfig.h defines _POSIX_C_SOURCE to 200112L, which prevents QNX's
sys/types.h from defining uint_t. Samba 4 uses this type, so it fails
to compile if Python.h is included first (cf.
https://bugzilla.samba.org/show_bug.cgi?id=6842).
The attached patch fixes this issue by defining _QNX_SOURCE.
----------
components: Build
files: define-_QNX_SOURCE.patch
keywords: patch
messages: 94493
nosy: kraai
severity: normal
status: open
title: Prevents uint_t from being used on QNX
versions: Python 2.7
Added file: http://bugs.python.org/file15202/define-_QNX_SOURCE.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7209>
_______________________________________
From report at bugs.python.org Mon Oct 26 20:40:20 2009
From: report at bugs.python.org (Chuck Rhode)
Date: Mon, 26 Oct 2009 19:40:20 +0000
Subject: [New-bugs-announce] [issue7210] Proposed Syntax Checks in Test Suite
In-Reply-To: <1256586020.55.0.428319346967.issue7210@psf.upfronthosting.co.za>
Message-ID: <1256586020.55.0.428319346967.issue7210@psf.upfronthosting.co.za>
New submission from Chuck Rhode <CRhode at LacusVeris.com>:
PythonTidy is a code beautifier written three years ago and downloaded
numerous times.
o http://lacusveris.com/PythonTidy/PythonTidy.python
It suffers a bug, which has only recently come to light. It considers
the following lines equivalent:
if False is (2 is 3): pass
if False is 2 is 3: pass
They're not. PythonTidy handles other non-associative operators such as
division correctly. I was unable to generalize from arithmetic
operators to comparison operators because the Abstract Syntax Tree (AST)
generated by the *compiler* module returns a different structure for them.
I tested PythonTidy by running the Python Test Suite (the *test* module
scripts) through it and executing the results, thought I had all my
bases covered because most tests succeeded, and missed this case, so I
am suggesting an amplification of the Python Test Suite for developers
who may be using it for purposes other than testing Python.
I wish to add these lines to the foot of *test_grammar.py*.
verify(16 // (4 // 2) == 8, '16 // (4 // 2) == 8')
verify((16 // 4) // 2 == 2, '(16 // 4) // 2 == 2')
verify(16 // 4 // 2 == 2, '16 // 4 // 2 == 2')
verify((False is (2 is 3)) == True, '(False is (2 is 3)) == True')
verify(((False is 2) is 3) == False, '(((False is 2) is 3) == False')
verify((False is 2 is 3) == False, '(False is 2 is 3) == False')
----------
components: Tests
files: test_grammar.patch
keywords: patch
messages: 94501
nosy: ChuckRhode
severity: normal
status: open
title: Proposed Syntax Checks in Test Suite
type: feature request
versions: Python 2.5
Added file: http://bugs.python.org/file15206/test_grammar.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7210>
_______________________________________
From report at bugs.python.org Mon Oct 26 20:54:43 2009
From: report at bugs.python.org (Michael Broghton)
Date: Mon, 26 Oct 2009 19:54:43 +0000
Subject: [New-bugs-announce] [issue7211] select module - kevent ident field
64 bit issue
In-Reply-To: <1256586883.91.0.341415015996.issue7211@psf.upfronthosting.co.za>
Message-ID: <1256586883.91.0.341415015996.issue7211@psf.upfronthosting.co.za>
New submission from Michael Broghton <mbroughton at advanis.ca>:
On FreeBSD and MacOS 64-bit systems the ident field of a kevent is big
enough to hold a 64-bit integer (uintptr_t). Looks like Python is
casting it to an unsigned 32-bit integer.
This is inconvenient for implementing kqueue timers, where id(timer_obj)
is a natural choice for an ident.
----------
components: Library (Lib)
messages: 94502
nosy: mbroughton
severity: normal
status: open
title: select module - kevent ident field 64 bit issue
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7211>
_______________________________________
From report at bugs.python.org Mon Oct 26 22:07:19 2009
From: report at bugs.python.org (Willi Richert)
Date: Mon, 26 Oct 2009 21:07:19 +0000
Subject: [New-bugs-announce] [issue7212] Retrieve an arbitrary element from
a set without removing it
In-Reply-To: <1256591239.7.0.409642892772.issue7212@psf.upfronthosting.co.za>
Message-ID: <1256591239.7.0.409642892772.issue7212@psf.upfronthosting.co.za>
New submission from Willi Richert <w.richert at gmx.net>:
Sometimes, a non-removing pop() is needed. In current Python versions,
it can achieved by one of the following ways:
1.
x = some_set.pop()
some_set.add(x)
2.
for x in some_set:
break
3.
x = iter(some_set).next()
More native and clean would, however, be
some_set.get()
The attached patch does this for set(). If this is accepted by the
community, frozenset should be extended as well.
----------
components: Library (Lib)
files: setobject_get.patch
keywords: patch
messages: 94508
nosy: wrichert
severity: normal
status: open
title: Retrieve an arbitrary element from a set without removing it
type: feature request
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15207/setobject_get.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7212>
_______________________________________
From report at bugs.python.org Tue Oct 27 00:14:02 2009
From: report at bugs.python.org (Milko Krachounov)
Date: Mon, 26 Oct 2009 23:14:02 +0000
Subject: [New-bugs-announce] [issue7213] Popen.subprocess change close_fds
default to True
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
New submission from Milko Krachounov <python at milko.3mhz.net>:
Currently, close_fds defaults to False. The are few cases in which one
would want to leave the fds open, in all the rest leaving them open can
lead to unpleasant side effects. For example, the following doesn't work:
>>> p1 = Popen(['cat'], stdin=PIPE, stdout=PIPE)
>>> p2 = Popen(['grep', 'a'], stdin=p1.stdout, stdout=PIPE)
>>> p1.stdin.write("aaaaaaaaaaaaaaaa\n")
>>> p1.stdin.close()
>>> p2.stdout.read()
It would block forever, and it is not obvious that p1.stdin remains
open, because p2 was created without close_fds=True. On the other hand,
in each and every case where close_fds=True is required, the programmer
is aware that he needs to leave some fds open (and usually knows which fds).
The current default is harmful, because in each case where the file
descriptors are not explicitly needed in the child process, they can
cause problems hard to debug. It seems that only about 10% of the
current uses of Popen have close_fds=True.
I propose that the close_fds default is changed to True. Alternatively,
this could be combined with bug #6559 by completely removing the
close_fds argument, and leaving only pass_fds, which could accept
subprocess.ALL_FDS as a value.
There are two issues with my proposal:
1. close_fds would have to be changed to give a warning each time it is
not specified before the change of the default can be adopted. Otherwise
it would break any programs relying on close_fds being False by default.
2. Closing fds has a slight performance impact.
However, I think that close_fds=True is much more sensible default. I
think it will be a good idea if at least py3k adopts the change.
----------
components: Library (Lib)
messages: 94538
nosy: milko.krachounov
severity: normal
status: open
title: Popen.subprocess change close_fds default to True
type: behavior
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________
From report at bugs.python.org Tue Oct 27 00:32:30 2009
From: report at bugs.python.org (Brian)
Date: Mon, 26 Oct 2009 23:32:30 +0000
Subject: [New-bugs-announce] [issue7214] TreeBuilder.end(tag) differs
between cElementTree and ElementTree
In-Reply-To: <1256599950.66.0.903450683949.issue7214@psf.upfronthosting.co.za>
Message-ID: <1256599950.66.0.903450683949.issue7214@psf.upfronthosting.co.za>
New submission from Brian <brian at merrells.org>:
In the pure python ElementTree, the tag passed to the end() tag is
verified to be closing the last tag opened (self._last).
This cElementTree performs no such validation and closes the last tag
regardless of what tag is passed to the method.
In my mind this raises a couple questions beyond simply fixing this
discrepancy.
1) Why make this tag mandatory if it has no effect in the cElementTree
version (and in the pure python version is only used to verify the user
isn't confused what tag they are closing)
2) Could the argument be removed, simply closing the last tag if not
present?
3) Or could the behavior be changed to actually influence which tag is
closed, allowing one to close all tags out to a specific
outer/encompassing tag (much like close(), closes all tags)?
-brian
----------
components: Library (Lib)
messages: 94542
nosy: merrellb
severity: normal
status: open
title: TreeBuilder.end(tag) differs between cElementTree and ElementTree
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7214>
_______________________________________
From report at bugs.python.org Tue Oct 27 00:32:33 2009
From: report at bugs.python.org (Brian)
Date: Mon, 26 Oct 2009 23:32:33 +0000
Subject: [New-bugs-announce] [issue7215] TreeBuilder.end(tag) differs
between cElementTree and ElementTree
In-Reply-To: <1256599953.85.0.50468157726.issue7215@psf.upfronthosting.co.za>
Message-ID: <1256599953.85.0.50468157726.issue7215@psf.upfronthosting.co.za>
New submission from Brian <brian at merrells.org>:
In the pure python ElementTree, the tag passed to the end() tag is
verified to be closing the last tag opened (self._last).
This cElementTree performs no such validation and closes the last tag
regardless of what tag is passed to the method.
In my mind this raises a couple questions beyond simply fixing this
discrepancy.
1) Why make this tag mandatory if it has no effect in the cElementTree
version (and in the pure python version is only used to verify the user
isn't confused what tag they are closing)
2) Could the argument be removed, simply closing the last tag if not
present?
3) Or could the behavior be changed to actually influence which tag is
closed, allowing one to close all tags out to a specific
outer/encompassing tag (much like close(), closes all tags)?
-brian
----------
components: Library (Lib)
messages: 94543
nosy: merrellb
severity: normal
status: open
title: TreeBuilder.end(tag) differs between cElementTree and ElementTree
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7215>
_______________________________________
From report at bugs.python.org Tue Oct 27 08:13:51 2009
From: report at bugs.python.org (Volker Siepmann)
Date: Tue, 27 Oct 2009 07:13:51 +0000
Subject: [New-bugs-announce] [issue7216] low performance of zipfile
readline()
In-Reply-To: <1256627631.57.0.724869251337.issue7216@psf.upfronthosting.co.za>
Message-ID: <1256627631.57.0.724869251337.issue7216@psf.upfronthosting.co.za>
New submission from Volker Siepmann <newsgroups at vsiep.de>:
The readline() function in zipfile (in ZipExtFile) reads chunks of max
100 bytes (zipfile.py, line 525) into the linebuffer. A file of 500
MBytes therefore yields 5 million chunks.
Changing the value 100 to 10000 bytes boosts performance by magnitudes,
while it only requires 10k of memory.
My fix in zipfile.py, line 525:
buf = self.read(min(size, 10000)) # was 100 before
Best regards / Volker Siepmann
----------
components: Library (Lib)
messages: 94545
nosy: volker_siepmann
severity: normal
status: open
title: low performance of zipfile readline()
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7216>
_______________________________________
From report at bugs.python.org Tue Oct 27 08:57:05 2009
From: report at bugs.python.org (ali)
Date: Tue, 27 Oct 2009 07:57:05 +0000
Subject: [New-bugs-announce] [issue7217] IDLE Subprocess Startup Error
In-Reply-To: <1256630225.32.0.706380843912.issue7217@psf.upfronthosting.co.za>
Message-ID: <1256630225.32.0.706380843912.issue7217@psf.upfronthosting.co.za>
New submission from ali <mr.dalba at gmail.com>:
Hi
After trying to install another IDE for python (Eric4.3.8 and sciTE201)
I'm not able to launch IDLE directly anymore. (I not sure if this is
really relevant)
I can right click on the .py files and choose "edit with IDLE" and
everything works fine.
Also, I can run python under cmd without any problem.
But when I try to open IDLE using start menu icon, this error massage
appears:
Subprocess Startup Error
IDLE's subprocess didn't make connection. either idle can't start a
subprocess or personal firewall software is blocking the connection.
I tried to disable my anti-virus and windows firewall (I don't use any
other firewalls), but the problem still exists.
I uninstalled python 2.6.2 and then installed python 3.1.1. IDLE worked
fine but I had a little problem with the new syntax in python 3 so I
installed python 2.6.4 and guess what, the same error message again!
When I try to run IDLE from cmd this error message is displayed:
hi
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "C:\Python26\lib\idlelib\run.py", line 13, in <module>
import RemoteDebugger
File "C:\Python26\lib\idlelib\RemoteDebugger.py", line 24, in <module>
import rpc
File "C:\Python26\lib\idlelib\rpc.py", line 120, in <module>
request_queue = Queue.Queue(0)
TypeError: __init__() takes exactly 1 argument (2 given)
Can anyone help?
Thanks in advance
----------
components: IDLE
messages: 94546
nosy: mr.dalba
severity: normal
status: open
title: IDLE Subprocess Startup Error
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7217>
_______________________________________
From report at bugs.python.org Tue Oct 27 11:15:53 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Oct 2009 10:15:53 +0000
Subject: [New-bugs-announce] [issue7218] test_site failure under Windows
In-Reply-To: <1256638553.58.0.546981327124.issue7218@psf.upfronthosting.co.za>
Message-ID: <1256638553.58.0.546981327124.issue7218@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
This fails quite reliably on Windows buildbots:
======================================================================
FAIL: test_getsitepackages (test.test_site.HelperFunctionsTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_site.py",
line 173, in test_getsitepackages
self.assertEquals(dirs[1], wanted)
AssertionError: 'xoxo\\lib\\site-packages' != 'xoxo\\Lib\\site-packages'
----------
assignee: tarek
components: Tests
messages: 94549
nosy: pitrou, tarek
priority: high
severity: normal
status: open
title: test_site failure under Windows
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/issue7218>
_______________________________________
From report at bugs.python.org Tue Oct 27 13:37:51 2009
From: report at bugs.python.org (Michael Foord)
Date: Tue, 27 Oct 2009 12:37:51 +0000
Subject: [New-bugs-announce] [issue7219] Unhelpful error message when a
distutils package install fails due to a permissions error
In-Reply-To: <1256647071.1.0.815334810123.issue7219@psf.upfronthosting.co.za>
Message-ID: <1256647071.1.0.815334810123.issue7219@psf.upfronthosting.co.za>
New submission from Michael Foord <michael at voidspace.org.uk>:
This problem showed up when installing a package with IronPython, where
the site-packages folder requires admin privileges to write to (which
*should* be true with CPython Windows but isn't).
If you perform a 'python setup.py install' without admin privileges the
install fails (as it should) but with a very cryptic error message:
C:\compile\test\foo-1.0>"C:\Program Files\IronPython 2.6\ipy.exe"
setup.py install
running install
running build
running build_py
creating build
creating build\lib
copying foo.py -> build\lib
running install_lib
copying build\lib\foo.py -> C:\Program Files\IronPython
2.6\Lib\site-packages
error: C:\Program Files\IronPython 2.6\Lib\site-packages\foo.py: None
----------
assignee: tarek
keywords: 26backport
messages: 94554
nosy: michael.foord, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: Unhelpful error message when a distutils package install fails due to a permissions error
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7219>
_______________________________________
From report at bugs.python.org Tue Oct 27 13:48:17 2009
From: report at bugs.python.org (Martijn Ras)
Date: Tue, 27 Oct 2009 12:48:17 +0000
Subject: [New-bugs-announce] [issue7220] python -m no longer executes
packages directly
In-Reply-To: <1256647697.94.0.0863288338635.issue7220@psf.upfronthosting.co.za>
Message-ID: <1256647697.94.0.0863288338635.issue7220@psf.upfronthosting.co.za>
New submission from Martijn Ras <Martijn.Ras at GMail.com>:
Heya Folks,
I've just started moving some of my projects from Python 2.5 to Python 2.6.
I used to start some of these packages using python -m <packagename>.
In Python 2.6 this results in the following error:
/usr/bin/python: <packagename> is a package and cannot be directly executed
I got everything running again, by using the following command:
python -m <packagename>.__init__
This strikes me as awkward, since every package should still have the
__init__.py file. Can this be fixed so running python -m <packagename>
will once more be equal to python -m <packagename>.__init__?
Mazzel,
Martijn.
----------
components: None
messages: 94555
nosy: Martijn
severity: normal
status: open
title: python -m no longer executes packages directly
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7220>
_______________________________________
From report at bugs.python.org Tue Oct 27 19:27:02 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Oct 2009 18:27:02 +0000
Subject: [New-bugs-announce] [issue7221] DispatcherWithSendTests_UsePoll
with test_asyncore does nothing
In-Reply-To: <1256668022.66.0.873968126347.issue7221@psf.upfronthosting.co.za>
Message-ID: <1256668022.66.0.873968126347.issue7221@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
It changes the class variable `usepoll` from its parent to True, but
that variable isn't used anywhere.
----------
assignee: facundobatista
components: Library (Lib), Tests
messages: 94570
nosy: alanmcintyre, facundobatista, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: DispatcherWithSendTests_UsePoll with test_asyncore does nothing
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/issue7221>
_______________________________________
From report at bugs.python.org Tue Oct 27 22:24:24 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Oct 2009 21:24:24 +0000
Subject: [New-bugs-announce] [issue7222] thread reaping is imperfect
In-Reply-To: <1256678664.51.0.053160185007.issue7222@psf.upfronthosting.co.za>
Message-ID: <1256678664.51.0.053160185007.issue7222@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
Thread reaping in test_support is imperfect because, even when a thread
has a disappeared from _active and _limbo, the Thread object might still
be hanging somewhere in memory (leaving its last instants). This problem
manifests itself when trying to fix the transient refleaks in
test_socketserver.
One solution I've found is to add a _count() method to the thread
module, which returns the number of running threads from the point of
view of the C extension. When _count() is decremented, we can be sure
the Python method has finished running and the Thread object is not
hanging around.
----------
components: Tests
files: threading_setup.patch
keywords: patch
messages: 94582
nosy: nnorwitz, pitrou, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: thread reaping is imperfect
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15215/threading_setup.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7222>
_______________________________________
From report at bugs.python.org Wed Oct 28 00:30:55 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Oct 2009 23:30:55 +0000
Subject: [New-bugs-announce] [issue7223] Simplify and improve Thread.join()
In-Reply-To: <1256686255.23.0.543755679339.issue7223@psf.upfronthosting.co.za>
Message-ID: <1256686255.23.0.543755679339.issue7223@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
This patch improves and simplifies Thread.join() by making sure that the
__bootstrap() method is finished before join() returns. While it does
improve the resource deallocation behaviour, it is still enough for
solving all refleak detection hazards (see #7222).
----------
components: Library (Lib)
files: join.patch
keywords: patch
messages: 94587
nosy: gregory.p.smith, jyasskin, pitrou
priority: low
severity: normal
stage: patch review
status: open
title: Simplify and improve Thread.join()
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15216/join.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7223>
_______________________________________
From report at bugs.python.org Wed Oct 28 02:05:29 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 28 Oct 2009 01:05:29 +0000
Subject: [New-bugs-announce] [issue7224] One obvious way to do interning
In-Reply-To: <1256691929.12.0.04518648136.issue7224@psf.upfronthosting.co.za>
Message-ID: <1256691929.12.0.04518648136.issue7224@psf.upfronthosting.co.za>
New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:
Attached patch implements python-ideas proposal to return added or
existing element from set.add(). See
http://mail.python.org/pipermail/python-ideas/2009-October/006491.html .
In addition this patch contains a reimplementation of issue1507011 using
new behavior of set_add.
The two changes are independent an I would submit them separately if I
was more optimistic that any would be accepted. :-)
This submission is mostly for the benefit of users with applications
that create huge number of interned strings. Since the patch saves 8
bytes for each interned string, such application can see appreciable
memory savings.
I don't have such application and my tests show no difference between
patched and stock python. (For a data point, on start up stock python
creates about 2,000 interned strings.)
My own motivation for writing this patch was the same as for issue1507011: the code that uses a set to store interned strings is more
straightforward than code that uses a dict that stores strings twice,
both as key and value.
----------
components: Interpreter Core
files: set-add.diff
keywords: patch
messages: 94595
nosy: belopolsky
severity: normal
status: open
title: One obvious way to do interning
type: feature request
Added file: http://bugs.python.org/file15218/set-add.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7224>
_______________________________________
From report at bugs.python.org Wed Oct 28 02:16:20 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 28 Oct 2009 01:16:20 +0000
Subject: [New-bugs-announce] [issue7225] fwrite() compiler warnings
In-Reply-To: <1256692580.97.0.277746602553.issue7225@psf.upfronthosting.co.za>
Message-ID: <1256692580.97.0.277746602553.issue7225@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <benjamin at python.org>:
gcc 4.3.2 is currently coughing up warnings like this:
Objects/object.c: In function 'internal_print':
Objects/object.c:301: warning: ignoring return value of 'fwrite',
declared with attribute warn_unused_result
Objects/object.c:310: warning: ignoring return value of 'fwrite',
declared with attribute warn_unused_result
Python/marshal.c: In function 'w_string':
Python/marshal.c:97: warning: ignoring return value of 'fwrite',
declared with attribute warn_unused_result
./Modules/signalmodule.c: In function 'signal_handler':
./Modules/signalmodule.c:182: warning: ignoring return value of 'write',
declared with attribute warn_unused_result
----------
components: Build
messages: 94597
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: fwrite() compiler warnings
type: compile error
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7225>
_______________________________________
From report at bugs.python.org Wed Oct 28 02:35:18 2009
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 28 Oct 2009 01:35:18 +0000
Subject: [New-bugs-announce] [issue7226] IDLE right-clicks don't work on Mac
OS 10.5
In-Reply-To: <1256693718.71.0.813168523679.issue7226@psf.upfronthosting.co.za>
Message-ID: <1256693718.71.0.813168523679.issue7226@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
I'm sure this has been reported before, by I can't find it. Right button
clicks do nothing on Mac OS X -- they don't go to the line of a
traceback, and in debug mode they don't pop up the breakpoint menu.
----------
assignee: ronaldoussoren
components: IDLE, Macintosh
messages: 94598
nosy: MLModel, ronaldoussoren
severity: normal
status: open
title: IDLE right-clicks don't work on Mac OS 10.5
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/issue7226>
_______________________________________
From report at bugs.python.org Wed Oct 28 06:27:23 2009
From: report at bugs.python.org (David Lyon)
Date: Wed, 28 Oct 2009 05:27:23 +0000
Subject: [New-bugs-announce] [issue7227] Shell Support for installation of
Python Packages (.EGG)
In-Reply-To: <1256707642.83.0.00840383945529.issue7227@psf.upfronthosting.co.za>
Message-ID: <1256707642.83.0.00840383945529.issue7227@psf.upfronthosting.co.za>
New submission from David Lyon <david.lyon at preisshare.net>:
Under Windows, it would be very handy to have shell support for
installing .EGG packages.
To implement this would require the addition of some registry keys into
the cpython installation to associate the .EGG extension as being a
python package.
Then a new script would be assigned to process the .EGG file if called
from explorer.
This would provide the user with the ability to easily install packages
from web sites such as pypi.
----------
components: Demos and Tools, Installation, Windows
messages: 94600
nosy: djlyon
severity: normal
status: open
title: Shell Support for installation of Python Packages (.EGG)
type: feature request
versions: Python 2.4, Python 2.5, 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/issue7227>
_______________________________________
From report at bugs.python.org Wed Oct 28 07:49:41 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 28 Oct 2009 06:49:41 +0000
Subject: [New-bugs-announce] [issue7228] %lld for PyErr_Format
(Modules/_io/bufferedio.c)
In-Reply-To: <1256712581.76.0.435920152498.issue7228@psf.upfronthosting.co.za>
Message-ID: <1256712581.76.0.435920152498.issue7228@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
Hello. There is following sentence in Modules/_io/bufferedio.c,
PyErr_Format(PyExc_IOError,
"Raw stream returned invalid position %" PY_PRIdOFF,
(PY_OFF_T_COMPAT)n);
and PY_PRIdOFF == "lld" when sizeof(off_t) == sizeof(long long).
But it seems that PyErr_Format doesn't support lld as specifier.
I noticed this because
# define PY_OFF_T_COMPAT long long
caused compile error on my good old VC6. ;-) (VC6 doesn't have it)
----------
messages: 94601
nosy: mark.dickinson, ocean-city
severity: normal
status: open
title: %lld for PyErr_Format (Modules/_io/bufferedio.c)
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7228>
_______________________________________
From report at bugs.python.org Wed Oct 28 10:44:12 2009
From: report at bugs.python.org (Tomas Kubes)
Date: Wed, 28 Oct 2009 09:44:12 +0000
Subject: [New-bugs-announce] [issue7229] Manual entry for time.daylight can
be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
New submission from Tomas Kubes <mr_napik at centrum.cz>:
Hello,
it is not obvious that the time.daylight data item reports nonzero
values even when DST is currently not being used (ie. in winter) but the
active timezone has DST defined for some other parts of the year.
Current manual entry can be misleadingly interpreted that time.daylight
acts as a current DST idicator (which it does not).
Suggested FIX: Add a sentence:
This value does not idicate that DST is currently active, but rather
describes that current timezone can have DST. Use localtime() dst flag
to determine if DST applies to the given time.
Tomas
----------
assignee: georg.brandl
components: Documentation
messages: 94621
nosy: georg.brandl, napik
severity: normal
status: open
title: Manual entry for time.daylight can be misleading
type: feature request
versions: Python 2.4, Python 2.5, 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/issue7229>
_______________________________________
From report at bugs.python.org Wed Oct 28 15:06:07 2009
From: report at bugs.python.org (Zsolt Cserna)
Date: Wed, 28 Oct 2009 14:06:07 +0000
Subject: [New-bugs-announce] [issue7230] test_hotshot fails on solaris
In-Reply-To: <1256738767.32.0.166548042812.issue7230@psf.upfronthosting.co.za>
Message-ID: <1256738767.32.0.166548042812.issue7230@psf.upfronthosting.co.za>
New submission from Zsolt Cserna <zsolt.cserna at morganstanley.com>:
On sparc/solaris 5.8, test_hotshot fails:
csernazs at localhost:/tmp/python2.6$ LD_LIBRARY_PATH=/tmp/python2.6
./python -E -tt ./Lib/test/regrtest.py -v -l test_hotshot
test_hotshot
test_addinfo (test.test_hotshot.HotShotTestCase) ... ok
test_bad_sys_path (test.test_hotshot.HotShotTestCase) ... ok
test_line_numbers (test.test_hotshot.HotShotTestCase) ... ok
test_logreader_eof_error (test.test_hotshot.HotShotTestCase) ... FAIL
test_start_stop (test.test_hotshot.HotShotTestCase) ... ok
======================================================================
FAIL: test_logreader_eof_error (test.test_hotshot.HotShotTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/tmp/python2.6/Lib/test/test_hotshot.py", line 130, in
test_logreader_eof_error
self.assertRaises((IOError, EOFError), _hotshot.logreader, ".")
AssertionError: (<type 'exceptions.IOError'>, <type
'exceptions.EOFError'>) not raised
----------------------------------------------------------------------
Ran 5 tests in 0.037s
FAILED (failures=1)
test test_hotshot failed -- Traceback (most recent call last):
File "/tmp/python2.6/Lib/test/test_hotshot.py", line 130, in
test_logreader_eof_error
self.assertRaises((IOError, EOFError), _hotshot.logreader, ".")
AssertionError: (<type 'exceptions.IOError'>, <type
'exceptions.EOFError'>) not raised
1 test failed:
test_hotshot
>From test_hotshot.py:
def test_logreader_eof_error(self):
self.assertRaises((IOError, EOFError), _hotshot.logreader, ".")
gc.collect()
If I run python command-line interpreter, it doesn't raise exception:
>>> import _hotshot
>>> _hotshot.logreader(".")
<_hotshot.LogReaderType object at 0x3f260>
>>>
On intel/linux, this test passes.
----------
components: Library (Lib)
messages: 94628
nosy: csernazs
severity: normal
status: open
title: test_hotshot fails on solaris
type: compile error
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7230>
_______________________________________
From report at bugs.python.org Wed Oct 28 17:59:12 2009
From: report at bugs.python.org (sorin)
Date: Wed, 28 Oct 2009 16:59:12 +0000
Subject: [New-bugs-announce] [issue7231] Windows installer does not add
\Scripts folder to the path
In-Reply-To: <1256749152.57.0.801313448944.issue7231@psf.upfronthosting.co.za>
Message-ID: <1256749152.57.0.801313448944.issue7231@psf.upfronthosting.co.za>
New submission from sorin <sorin.sbarnea at gmail.com>:
I observed that Windows installer is able to add only the Python
installation folder to the path.
In addition to this it should add the Scrips folder because many python
tools are installing scripts inside it, scripts that the user cannot us
unless he add this directory to the path.
This is very annoying because if you modify the PATH you need to
logout/login in order to be able to use the new PATH value.
----------
components: Installation
messages: 94633
nosy: sorin
severity: normal
status: open
title: Windows installer does not add \Scripts folder to the path
type: behavior
versions: Python 2.4, Python 2.5, 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/issue7231>
_______________________________________
From report at bugs.python.org Thu Oct 29 08:29:40 2009
From: report at bugs.python.org (Jaime Buelta)
Date: Thu, 29 Oct 2009 07:29:40 +0000
Subject: [New-bugs-announce] [issue7232] Support of 'with' statement fo
TarFile class
In-Reply-To: <1256801380.63.0.851981428593.issue7232@psf.upfronthosting.co.za>
Message-ID: <1256801380.63.0.851981428593.issue7232@psf.upfronthosting.co.za>
New submission from Jaime Buelta <jaime.buelta at gmail.com>:
Currently, the TarFile is not supporting the 'with' statement, which I
think it should for coherence with other file classes.
I've already created a patch including it for consideration.
----------
components: Library (Lib)
files: tarfileWithSupport.patch
keywords: patch
messages: 94645
nosy: jaime.buelta
severity: normal
status: open
title: Support of 'with' statement fo TarFile class
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file15220/tarfileWithSupport.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7232>
_______________________________________
From report at bugs.python.org Thu Oct 29 10:21:03 2009
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 29 Oct 2009 09:21:03 +0000
Subject: [New-bugs-announce] [issue7233] decimal.py: two rotate() issues
In-Reply-To: <1256808063.4.0.75529666771.issue7233@psf.upfronthosting.co.za>
Message-ID: <1256808063.4.0.75529666771.issue7233@psf.upfronthosting.co.za>
New submission from Stefan Krah <stefan-usenet at bytereef.org>:
Hi,
I got two issues with the all-important function rotate():
1. It should probably convert an integer argument:
>>> from decimal import *
>>> c = getcontext()
>>> c.prec = 4
>>> Decimal("1000000000").rotate(1)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.7/decimal.py", line 3411, in rotate
ans = self._check_nans(other, context)
File "/usr/lib/python2.7/decimal.py", line 738, in _check_nans
other_is_nan = other._isnan()
2. When the coefficient size is greater than prec, the most significant
digits should be truncated before rotating:
>>> c.prec = 4
>>> Decimal("1000000000").rotate(Decimal(1))
Decimal('1')
The result should be 0 (checked against decNumber).
----------
messages: 94649
nosy: mark.dickinson, skrah
severity: normal
status: open
title: decimal.py: two rotate() issues
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7233>
_______________________________________
From report at bugs.python.org Thu Oct 29 14:09:29 2009
From: report at bugs.python.org (lpp1985)
Date: Thu, 29 Oct 2009 13:09:29 +0000
Subject: [New-bugs-announce] [issue7234] Complete your registration to
Python tracker -- keyRVZuTYMju0LifnIK60WPnidSrLQIHXI7
In-Reply-To: <200910292109153190232@yahoo.com.cn>
Message-ID: <200910292109153190232@yahoo.com.cn>
New submission from lpp1985 <lpp1985 at yahoo.com.cn>:
the
reply's additional "Re:" is ok
2009-10-29
?????????
???????????? Python tracker
??????????????? 2009-10-29 21:07:41
???????????? lpp1985
?????????
????????? Complete your registration to Python tracker -- keyRVZuTYMju0LifnIK60WPnidSrLQIHXI7
To complete your registration of the user "kaka" with
Python tracker, please do one of the following:
- send a reply to report at bugs.python.org and maintain the subject line as is (the
reply's additional "Re:" is ok),
- or visit the following URL:
http://bugs.python.org/?@action=confrego&otk=RVZuTYMju0LifnIK60WPnidSrLQIHXI7
----------
files: unnamed, unnamed
messages: 94662
nosy: kaka
severity: normal
status: open
title: Complete your registration to Python tracker -- keyRVZuTYMju0LifnIK60WPnidSrLQIHXI7
Added file: http://bugs.python.org/file15222/unnamed
Added file: http://bugs.python.org/file15223/unnamed
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7234>
_______________________________________
-------------- next part --------------
???<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=utf-8">
<META content="MSHTML 6.00.2900.5880" name=GENERATOR>
<STYLE>@font-face {
font-family: ??????;
}
@font-face {
font-family: Verdana;
}
@font-face {
font-family: @??????;
}
@page Section1 {size: 595.3pt 841.9pt; margin: 72.0pt 90.0pt 72.0pt 90.0pt; layout-grid: 15.6pt; }
P.MsoNormal {
TEXT-JUSTIFY: inter-ideograph; FONT-SIZE: 10.5pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
LI.MsoNormal {
TEXT-JUSTIFY: inter-ideograph; FONT-SIZE: 10.5pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
DIV.MsoNormal {
TEXT-JUSTIFY: inter-ideograph; FONT-SIZE: 10.5pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
A:link {
COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
FONT-WEIGHT: normal; COLOR: windowtext; FONT-STYLE: normal; FONT-FAMILY: Verdana; TEXT-DECORATION: none; mso-style-type: personal-compose
}
DIV.Section1 {
page: Section1
}
UNKNOWN {
FONT-SIZE: 10pt
}
BLOCKQUOTE {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px; MARGIN-LEFT: 2em
}
OL {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
UL {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</STYLE>
</HEAD>
<BODY style="FONT-SIZE: 10pt; MARGIN: 10px; FONT-FAMILY: verdana">
<DIV><FONT face=Verdana color=#000080 size=2>
<DIV>the</DIV>
<DIV>reply's additional "Re:" is ok</DIV></FONT></DIV>
<DIV><FONT face=Verdana color=#000080 size=2></FONT> </DIV>
<DIV><FONT face=Verdana color=#000080 size=2></FONT> </DIV>
<DIV><FONT face=Verdana color=#c0c0c0 size=2>2009-10-29 </FONT></DIV><FONT
face=Verdana color=#000080 size=2>
<HR style="WIDTH: 100px" align=left color=#b5c4df SIZE=1>
</FONT>
<DIV><FONT face=Verdana color=#c0c0c0 size=2><SPAN>?????????</SPAN> </FONT></DIV>
<HR color=#b5c4df SIZE=1>
<DIV><FONT face=Verdana size=2><STRONG>????????????</STRONG> Python tracker
</FONT></DIV>
<DIV><FONT face=Verdana size=2><STRONG>???????????????</STRONG> 2009-10-29 21:07:41
</FONT></DIV>
<DIV><FONT face=Verdana size=2><STRONG>????????????</STRONG> lpp1985 </FONT></DIV>
<DIV><FONT face=Verdana size=2><STRONG>?????????</STRONG> </FONT></DIV>
<DIV><FONT face=Verdana size=2><STRONG>?????????</STRONG> Complete your registration
to Python tracker -- keyRVZuTYMju0LifnIK60WPnidSrLQIHXI7 </FONT></DIV>
<DIV><FONT face=Verdana size=2></FONT> </DIV>
<DIV><FONT face=Verdana size=2>
<DIV>To complete your registration of the user "kaka" with</DIV>
<DIV>Python tracker, please do one of the following:</DIV>
<DIV></DIV>
<DIV>- send a reply to report at bugs.python.org and maintain the subject line as is (the</DIV>
<DIV>reply's additional "Re:" is ok),</DIV>
<DIV></DIV>
<DIV>- or visit the following URL:</DIV>
<DIV></DIV>
<DIV>http://bugs.python.org/?@action=confrego&otk=RVZuTYMju0LifnIK60WPnidSrLQIHXI7</DIV>
<DIV></DIV></FONT></DIV></BODY></HTML>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unnamed
Type: application/octet-stream
Size: 106 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20091029/91acb57c/attachment.obj>
From report at bugs.python.org Thu Oct 29 14:15:50 2009
From: report at bugs.python.org (lpp1985)
Date: Thu, 29 Oct 2009 13:15:50 +0000
Subject: [New-bugs-announce] [issue7235] IO libary have some error
In-Reply-To: <1256822150.5.0.9072293037.issue7235@psf.upfronthosting.co.za>
Message-ID: <1256822150.5.0.9072293037.issue7235@psf.upfronthosting.co.za>
New submission from lpp1985 <lpp1985 at yahoo.com.cn>:
The parameter 'newline' in os.open() functiion in the condition of
input could ought to be set to any character.But if I set anythin
else '','\n','\r\n',and '\r',there will be a error raise.This is maybe
a bug in this libary.
----------
components: Library (Lib)
messages: 94663
nosy: kaka
severity: normal
status: open
title: IO libary have some error
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7235>
_______________________________________
From report at bugs.python.org Thu Oct 29 14:18:29 2009
From: report at bugs.python.org (lpp1985)
Date: Thu, 29 Oct 2009 13:18:29 +0000
Subject: [New-bugs-announce] [issue7236] the reply's additional "Re:" is ok
In-Reply-To: <200910292118222109920@yahoo.com.cn>
Message-ID: <200910292118222109920@yahoo.com.cn>
New submission from lpp1985 <lpp1985 at yahoo.com.cn>:
2009-10-29
?????????
???????????? Python tracker
??????????????? 2009-10-29 21:07:41
???????????? lpp1985
?????????
????????? Complete your registration to Python tracker -- keyRVZuTYMju0LifnIK60WPnidSrLQIHXI7
To complete your registration of the user "kaka" with
Python tracker, please do one of the following:
- send a reply to report at bugs.python.org and maintain the subject line as is (the
reply's additional "Re:" is ok),
- or visit the following URL:
http://bugs.python.org/?@action=confrego&otk=RVZuTYMju0LifnIK60WPnidSrLQIHXI7
----------
files: unnamed, unnamed
messages: 94665
nosy: kaka
severity: normal
status: open
title: the reply's additional "Re:" is ok
Added file: http://bugs.python.org/file15224/unnamed
Added file: http://bugs.python.org/file15225/unnamed
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7236>
_______________________________________
-------------- next part --------------
???<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=utf-8">
<META content="MSHTML 6.00.2900.5880" name=GENERATOR>
<STYLE>@font-face {
font-family: ??????;
}
@font-face {
font-family: Verdana;
}
@font-face {
font-family: @??????;
}
@page Section1 {size: 595.3pt 841.9pt; margin: 72.0pt 90.0pt 72.0pt 90.0pt; layout-grid: 15.6pt; }
P.MsoNormal {
TEXT-JUSTIFY: inter-ideograph; FONT-SIZE: 10.5pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
LI.MsoNormal {
TEXT-JUSTIFY: inter-ideograph; FONT-SIZE: 10.5pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
DIV.MsoNormal {
TEXT-JUSTIFY: inter-ideograph; FONT-SIZE: 10.5pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
A:link {
COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
FONT-WEIGHT: normal; COLOR: windowtext; FONT-STYLE: normal; FONT-FAMILY: Verdana; TEXT-DECORATION: none; mso-style-type: personal-compose
}
DIV.Section1 {
page: Section1
}
UNKNOWN {
FONT-SIZE: 10pt
}
BLOCKQUOTE {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px; MARGIN-LEFT: 2em
}
OL {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
UL {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</STYLE>
</HEAD>
<BODY style="FONT-SIZE: 10pt; MARGIN: 10px; FONT-FAMILY: verdana">
<DIV><FONT face=Verdana color=#000080 size=2></FONT> </DIV>
<DIV><FONT face=Verdana color=#000080 size=2></FONT> </DIV>
<DIV><FONT face=Verdana color=#000080 size=2></FONT> </DIV>
<DIV><FONT face=Verdana color=#c0c0c0 size=2>2009-10-29 </FONT></DIV><FONT
face=Verdana color=#000080 size=2>
<HR style="WIDTH: 100px" align=left color=#b5c4df SIZE=1>
</FONT>
<DIV><FONT face=Verdana color=#c0c0c0 size=2><SPAN>?????????</SPAN> </FONT></DIV>
<HR color=#b5c4df SIZE=1>
<DIV><FONT face=Verdana size=2><STRONG>????????????</STRONG> Python tracker
</FONT></DIV>
<DIV><FONT face=Verdana size=2><STRONG>???????????????</STRONG> 2009-10-29 21:07:41
</FONT></DIV>
<DIV><FONT face=Verdana size=2><STRONG>????????????</STRONG> lpp1985 </FONT></DIV>
<DIV><FONT face=Verdana size=2><STRONG>?????????</STRONG> </FONT></DIV>
<DIV><FONT face=Verdana size=2><STRONG>?????????</STRONG> Complete your registration
to Python tracker -- keyRVZuTYMju0LifnIK60WPnidSrLQIHXI7 </FONT></DIV>
<DIV><FONT face=Verdana size=2></FONT> </DIV>
<DIV><FONT face=Verdana size=2>
<DIV>To complete your registration of the user "kaka" with</DIV>
<DIV>Python tracker, please do one of the following:</DIV>
<DIV></DIV>
<DIV>- send a reply to report at bugs.python.org and maintain the subject line as is (the</DIV>
<DIV>reply's additional "Re:" is ok),</DIV>
<DIV></DIV>
<DIV>- or visit the following URL:</DIV>
<DIV></DIV>
<DIV>http://bugs.python.org/?@action=confrego&otk=RVZuTYMju0LifnIK60WPnidSrLQIHXI7</DIV>
<DIV></DIV></FONT></DIV></BODY></HTML>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unnamed
Type: application/octet-stream
Size: 106 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20091029/4cea5e3d/attachment.obj>
From report at bugs.python.org Thu Oct 29 16:56:27 2009
From: report at bugs.python.org (David W. Lambert)
Date: Thu, 29 Oct 2009 15:56:27 +0000
Subject: [New-bugs-announce] [issue7237] Syntax error with not
In-Reply-To: <1256831787.46.0.18384779387.issue7237@psf.upfronthosting.co.za>
Message-ID: <1256831787.46.0.18384779387.issue7237@psf.upfronthosting.co.za>
New submission from David W. Lambert <b49P23TIvg at stny.rr.com>:
lambertdw$ p3
Python 3.1.1 (r311:74480, Oct 2 2009, 12:29:57)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> not 23
False
>>> not(23&1)
False
>>> 1+not(23&1)
File "<stdin>", line 1
1+not(23&1)
^
SyntaxError: invalid syntax
>>>
----------
components: Interpreter Core
messages: 94675
nosy: LambertDW
severity: normal
status: open
title: Syntax error with not
type: compile error
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7237>
_______________________________________
From report at bugs.python.org Thu Oct 29 18:16:58 2009
From: report at bugs.python.org (Mark Florisson)
Date: Thu, 29 Oct 2009 17:16:58 +0000
Subject: [New-bugs-announce] [issue7238] frame.f_lineno doesn't get updated
after local trace function assigned to it
In-Reply-To: <1256836618.71.0.0275056583438.issue7238@psf.upfronthosting.co.za>
Message-ID: <1256836618.71.0.0275056583438.issue7238@psf.upfronthosting.co.za>
New submission from Mark Florisson <markflorisson88 at gmail.com>:
As you can see, when a local trace function sets f_lineno, f_lineno
doesn't get updated on subsequent lines. Otherwise it works fine.
$ python tracer_testcase.py
12
12
12
13
14
15
The reference manual (for python 2.6) states the following: "f_lineno is
the current line number of the frame ? writing to this from within a
trace function jumps to the given line (only for the bottom-most frame).
A debugger can implement a Jump command (aka Set Next Statement) by
writing to f_lineno.". This is contradictory with the shown results,
because apparently it doesn't always represent the current line number.
----------
components: Interpreter Core
files: tracer_testcase.py
messages: 94681
nosy: eggy
severity: normal
status: open
title: frame.f_lineno doesn't get updated after local trace function assigned to it
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/file15229/tracer_testcase.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7238>
_______________________________________
From report at bugs.python.org Thu Oct 29 20:07:30 2009
From: report at bugs.python.org (MN)
Date: Thu, 29 Oct 2009 19:07:30 +0000
Subject: [New-bugs-announce] [issue7239] Error when running a code
In-Reply-To: <1256843250.15.0.0510719700355.issue7239@psf.upfronthosting.co.za>
Message-ID: <1256843250.15.0.0510719700355.issue7239@psf.upfronthosting.co.za>
New submission from MN <mauronilson at gmail.com>:
Process: Python [12980]
Path:
/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python
Identifier: org.python.python
Version: 2.6.4 (2.6.4)
Code Type: X86 (Native)
Parent Process: Python [12768]
Date/Time: 2009-10-29 18:54:32.502 +0000
OS Version: Mac OS X 10.6.1 (10B504)
Report Version: 6
Interval Since Last Report: 67916 sec
Crashes Since Last Report: 8
Per-App Interval Since Last Report: 10 sec
Per-App Crashes Since Last Report: 2
Anonymous UUID: 2FD60074-C28B-48E1-AB01-5A5B2E3B28D3
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread: 4
Application Specific Information:
abort() called
Thread 0: Dispatch queue: com.apple.main-thread
0 libSystem.B.dylib 0x948df822 semaphore_wait_signal_trap
+ 10
1 libSystem.B.dylib 0x9490d3d8 _pthread_cond_wait + 1089
2 libSystem.B.dylib 0x9495670f pthread_cond_wait + 48
3 org.python.python 0x000f6a1c PyThread_acquire_lock + 172
4 org.python.python 0x000fb473 lock_PyThread_acquire_lock
+ 83
5 org.python.python 0x000c0165 PyEval_EvalFrameEx + 19429
6 org.python.python 0x000c22dd PyEval_EvalCodeEx + 2109
7 org.python.python 0x000c034c PyEval_EvalFrameEx + 19916
8 org.python.python 0x000c22dd PyEval_EvalCodeEx + 2109
9 org.python.python 0x000c034c PyEval_EvalFrameEx + 19916
10 org.python.python 0x000c22dd PyEval_EvalCodeEx + 2109
11 org.python.python 0x000c034c PyEval_EvalFrameEx + 19916
12 org.python.python 0x000c22dd PyEval_EvalCodeEx + 2109
13 org.python.python 0x0003f746 function_call + 166
14 org.python.python 0x0000ed35 PyObject_Call + 85
15 org.python.python 0x00020b36 instancemethod_call + 422
16 org.python.python 0x0000ed35 PyObject_Call + 85
17 org.python.python 0x000ba5be
PyEval_CallObjectWithKeywords + 78
18 org.python.python 0x00023a02 PyInstance_New + 114
19 org.python.python 0x0000ed35 PyObject_Call + 85
20 org.python.python 0x000beab7 PyEval_EvalFrameEx + 13623
21 org.python.python 0x000c0ae6 PyEval_EvalFrameEx + 21862
22 org.python.python 0x000c22dd PyEval_EvalCodeEx + 2109
23 org.python.python 0x000c0a25 PyEval_EvalFrameEx + 21669
24 org.python.python 0x000c22dd PyEval_EvalCodeEx + 2109
25 org.python.python 0x0003f746 function_call + 166
26 org.python.python 0x0000ed35 PyObject_Call + 85
27 org.python.python 0x000bdf2c PyEval_EvalFrameEx + 10668
28 org.python.python 0x000c22dd PyEval_EvalCodeEx + 2109
29 org.python.python 0x000c034c PyEval_EvalFrameEx + 19916
30 org.python.python 0x000c22dd PyEval_EvalCodeEx + 2109
31 org.python.python 0x000c23f7 PyEval_EvalCode + 87
32 org.python.python 0x000e888f PyRun_StringFlags + 287
33 org.python.python 0x000e898e PyRun_SimpleStringFlags + 78
34 org.python.python 0x000f929e Py_Main + 1486
35 org.python.python 0x00001f82 0x1000 + 3970
36 org.python.python 0x00001ea9 0x1000 + 3753
Thread 1: Dispatch queue: com.apple.libdispatch-manager
0 libSystem.B.dylib 0x9490603a kevent + 10
1 libSystem.B.dylib 0x94906768 _dispatch_mgr_invoke + 215
2 libSystem.B.dylib 0x94905bf9 _dispatch_queue_invoke + 183
3 libSystem.B.dylib 0x9490598a _dispatch_worker_thread2 + 234
4 libSystem.B.dylib 0x94905401 _pthread_wqthread + 390
5 libSystem.B.dylib 0x94905246 start_wqthread + 30
Thread 2:
0 libSystem.B.dylib 0x94905092 __workq_kernreturn + 10
1 libSystem.B.dylib 0x94905628 _pthread_wqthread + 941
2 libSystem.B.dylib 0x94905246 start_wqthread + 30
Thread 3:
0 libSystem.B.dylib 0x948df822 semaphore_wait_signal_trap
+ 10
1 libSystem.B.dylib 0x9490d3d8 _pthread_cond_wait + 1089
2 libSystem.B.dylib 0x9495670f pthread_cond_wait + 48
3 org.python.python 0x000f6a1c PyThread_acquire_lock + 172
4 org.python.python 0x000ba2e3 PyEval_RestoreThread + 67
5 select.so 0x007dd6ea select_select + 490
6 org.python.python 0x000c0165 PyEval_EvalFrameEx + 19429
7 org.python.python 0x000c0ae6 PyEval_EvalFrameEx + 21862
8 org.python.python 0x000c0ae6 PyEval_EvalFrameEx + 21862
9 org.python.python 0x000c0ae6 PyEval_EvalFrameEx + 21862
10 org.python.python 0x000c0ae6 PyEval_EvalFrameEx + 21862
11 org.python.python 0x000c22dd PyEval_EvalCodeEx + 2109
12 org.python.python 0x0003f746 function_call + 166
13 org.python.python 0x0000ed35 PyObject_Call + 85
14 org.python.python 0x00020b36 instancemethod_call + 422
15 org.python.python 0x0000ed35 PyObject_Call + 85
16 org.python.python 0x000beab7 PyEval_EvalFrameEx + 13623
17 org.python.python 0x000c0ae6 PyEval_EvalFrameEx + 21862
18 org.python.python 0x000c22dd PyEval_EvalCodeEx + 2109
19 org.python.python 0x0003f746 function_call + 166
20 org.python.python 0x0000ed35 PyObject_Call + 85
21 org.python.python 0x00020b36 instancemethod_call + 422
22 org.python.python 0x0000ed35 PyObject_Call + 85
23 org.python.python 0x000beab7 PyEval_EvalFrameEx + 13623
24 org.python.python 0x000c22dd PyEval_EvalCodeEx + 2109
25 org.python.python 0x0003f746 function_call + 166
26 org.python.python 0x0000ed35 PyObject_Call + 85
27 org.python.python 0x00020b36 instancemethod_call + 422
28 org.python.python 0x0000ed35 PyObject_Call + 85
29 org.python.python 0x00075897 slot_tp_init + 87
30 org.python.python 0x000742c0 type_call + 176
31 org.python.python 0x0000ed35 PyObject_Call + 85
32 org.python.python 0x000beab7 PyEval_EvalFrameEx + 13623
33 org.python.python 0x000c0ae6 PyEval_EvalFrameEx + 21862
34 org.python.python 0x000c0ae6 PyEval_EvalFrameEx + 21862
35 org.python.python 0x000c0ae6 PyEval_EvalFrameEx + 21862
36 org.python.python 0x000c0ae6 PyEval_EvalFrameEx + 21862
37 org.python.python 0x000c22dd PyEval_EvalCodeEx + 2109
38 org.python.python 0x0003f746 function_call + 166
39 org.python.python 0x0000ed35 PyObject_Call + 85
40 org.python.python 0x000bdf2c PyEval_EvalFrameEx + 10668
41 org.python.python 0x000c0ae6 PyEval_EvalFrameEx + 21862
42 org.python.python 0x000c0ae6 PyEval_EvalFrameEx + 21862
43 org.python.python 0x000c22dd PyEval_EvalCodeEx + 2109
44 org.python.python 0x0003f746 function_call + 166
45 org.python.python 0x0000ed35 PyObject_Call + 85
46 org.python.python 0x00020b36 instancemethod_call + 422
47 org.python.python 0x0000ed35 PyObject_Call + 85
48 org.python.python 0x000ba5be
PyEval_CallObjectWithKeywords + 78
49 org.python.python 0x000fbaef t_bootstrap + 63
50 libSystem.B.dylib 0x9490cf39 _pthread_start + 345
51 libSystem.B.dylib 0x9490cdbe thread_start + 34
Thread 4 Crashed:
0 libSystem.B.dylib 0x9494cc2e __semwait_signal_nocancel + 10
1 libSystem.B.dylib 0x9494cb12
nanosleep$NOCANCEL$UNIX2003 + 166
2 libSystem.B.dylib 0x949c85a6 usleep$NOCANCEL$UNIX2003 + 61
3 libSystem.B.dylib 0x949e9c5c abort + 105
4 com.tcltk.tcllibrary 0x0065d4a3 Tcl_Panic + 0
5 com.tcltk.tcllibrary 0x0065d4be Tcl_Panic + 27
6 com.tcltk.tklibrary 0x00753215 Tk_MacOSXSetupTkNotifier + 120
7 com.tcltk.tklibrary 0x007496f0 TkpInit + 45
8 com.tcltk.tklibrary 0x006dd67a Initialize + 2173
9 _tkinter.so 0x005fa83c Tcl_AppInit + 140
10 _tkinter.so 0x005f8738 Tkinter_Create + 968
11 org.python.python 0x000c0165 PyEval_EvalFrameEx + 19429
12 org.python.python 0x000c22dd PyEval_EvalCodeEx + 2109
13 org.python.python 0x0003f746 function_call + 166
14 org.python.python 0x0000ed35 PyObject_Call + 85
15 org.python.python 0x00020b36 instancemethod_call + 422
16 org.python.python 0x0000ed35 PyObject_Call + 85
17 org.python.python 0x000ba5be
PyEval_CallObjectWithKeywords + 78
18 org.python.python 0x00023a02 PyInstance_New + 114
19 org.python.python 0x0000ed35 PyObject_Call + 85
20 org.python.python 0x000beab7 PyEval_EvalFrameEx + 13623
21 org.python.python 0x000c22dd PyEval_EvalCodeEx + 2109
22 org.python.python 0x0003f746 function_call + 166
23 org.python.python 0x0000ed35 PyObject_Call + 85
24 org.python.python 0x000ba5be
PyEval_CallObjectWithKeywords + 78
25 org.python.python 0x000fbaef t_bootstrap + 63
26 libSystem.B.dylib 0x9490cf39 _pthread_start + 345
27 libSystem.B.dylib 0x9490cdbe thread_start + 34
Thread 4 crashed with X86 Thread State (32-bit):
eax: 0x0000003c ebx: 0x9494ca79 ecx: 0xb02055fc edx: 0x9494cc2e
edi: 0x2f317e35 esi: 0xb0205658 ebp: 0xb0205638 esp: 0xb02055fc
ss: 0x0000001f efl: 0x00000247 eip: 0x9494cc2e cs: 0x00000007
ds: 0x0000001f es: 0x0000001f fs: 0x0000001f gs: 0x00000037
cr2: 0xb0207c58
Binary Images:
0x1000 - 0x1ff5 +org.python.python 2.6.4 (2.6.4)
<4037E992-5FF7-89F8-C547-77DF78B19D35>
/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python
0x5000 - 0x130fe3 +org.python.python 2.6.4, (c) 2004-2008 Python
Software Foundation. (2.6.4) <74126CA0-A482-4EDB-B195-CE276F49DA9E>
/Library/Frameworks/Python.framework/Versions/2.6/Python
0x1f5000 - 0x1f6fff +time.so ??? (???)
<CE38317A-468D-F3F1-D021-0360AD0CAF4A>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/time.so
0x3c0000 - 0x3c7fff +_socket.so ??? (???)
<C1B22680-310E-C1E5-8BFE-4A7CB8E454ED>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_socket.so
0x3d0000 - 0x3d3ff7 +_ssl.so ??? (???)
<4CB670AF-33F3-41BD-769C-F28FC27BB467>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_ssl.so
0x3d9000 - 0x3fffff libssl.0.9.7.dylib ??? (???)
<8BF98B2F-0F55-40CA-C082-43C76707BD24> /usr/lib/libssl.0.9.7.dylib
0x40e000 - 0x4c3fe7 libcrypto.0.9.7.dylib ??? (???)
<4917E4F2-817F-5AC4-3FBE-54BC96360448> /usr/lib/libcrypto.0.9.7.dylib
0x509000 - 0x50aff9 +cStringIO.so ??? (???)
<4C6A1DF3-FC4E-3E99-EB62-D9F4B455D23C>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/cStringIO.so
0x50f000 - 0x50fffc +_functools.so ??? (???)
<F84F4FEF-3FB0-C7D5-DB89-E8419D70D30A>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_functools.so
0x513000 - 0x516ff3 +_collections.so ??? (???)
<78B59DC9-8C1C-FD7F-1CA1-AAA38F6F70B3>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_collections.so
0x51c000 - 0x51ffff +operator.so ??? (???)
<06B2B012-039B-F139-56A8-AEB0E9B94056>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/operator.so
0x526000 - 0x52affe +itertools.so ??? (???)
<59707961-1A72-58D1-CAFA-C6A533F0FC87>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/itertools.so
0x533000 - 0x533ff5 +_bisect.so ??? (???)
<B0BA9213-688E-F914-30A0-E0E57FC01B4E>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_bisect.so
0x537000 - 0x538ff9 +_heapq.so ??? (???)
<D6155E99-1427-0DA4-80AC-B3E898C66AED>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_heapq.so
0x5f4000 - 0x5faff5 +_tkinter.so ??? (???)
<F69893FD-D21D-24B9-2D85-979EBF155695>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_tkinter.so
0x601000 - 0x692fe7 com.tcltk.tcllibrary 8.4.19 (8.4.19)
<6FF5C975-96BA-3370-AD5D-AAE625BE5D9A>
/System/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl
0x6b0000 - 0x77afe7 com.tcltk.tklibrary 8.4.19 (8.4.19)
<4F15559E-41DD-54A7-81DC-216B5B743401>
/System/Library/Frameworks/Tk.framework/Versions/8.4/Tk
0x7d2000 - 0x7d5ffc +strop.so ??? (???)
<E2AD56A2-4C71-DDA9-D714-553270C062EE>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/strop.so
0x7db000 - 0x7ddfff +select.so ??? (???)
<06E5920F-2F6A-B301-E6AA-A22A9F9F2A9D>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/select.so
0x7e3000 - 0x7e6ff7 +_struct.so ??? (???)
<1D6CFA30-A56B-C2F2-42AD-AF363C54B793>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_struct.so
0x7ed000 - 0x7effff +math.so ??? (???)
<06E35D7B-2246-9698-B12B-CC112597523B>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/math.so
0x7f5000 - 0x7fafff +binascii.so ??? (???)
<F0A84DF3-E036-B7CA-C5CF-B7AE66F412CF>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/binascii.so
0x1340000 - 0x134efff +cPickle.so ??? (???)
<440E0C46-62CF-5C05-15AF-17F94C922F9D>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/cPickle.so
0x13f6000 - 0x13f7fff +_random.so ??? (???)
<D19D89FC-872B-6A7B-F936-886275F9D8ED>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_random.so
0x13fb000 - 0x13fcff0 +fcntl.so ??? (???)
<21B2B1EE-58CF-E74F-B145-30EF50FB8D64>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/fcntl.so
0x1400000 - 0x1401ffe +_locale.so ??? (???)
<D7A81337-6283-5088-4E05-CE9DE1EA845A>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_locale.so
0x8fe00000 - 0x8fe4162b dyld 132.1 (???)
<211AF0DD-42D9-79C8-BB6A-1F4BEEF4B4AB> /usr/lib/dyld
0x90114000 - 0x9011dff7 com.apple.DiskArbitration 2.3 (2.3)
<E9C40767-DA6A-6CCB-8B00-2D5706753000>
/System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
0x9011e000 - 0x90164ff7 libauto.dylib ??? (???)
<FAB17F30-A28B-E33D-6E21-C7119C9C83ED> /usr/lib/libauto.dylib
0x90165000 - 0x901a8ff7 com.apple.NavigationServices 3.5.3 (181)
<28CDD978-030E-7D4A-5334-874A8EBE6C29>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/NavigationServices.framework/Versions/A/NavigationServices
0x90717000 - 0x9077bffb com.apple.htmlrendering 72 (1.1.4)
<4D451A35-FAB6-1288-71F6-F24A4B6E2371>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering
0x907c6000 - 0x907d3ff7 com.apple.NetFS 3.2 (3.2)
<E6FD80B0-0238-0C42-A3EC-EBDEC107A1C3>
/System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
0x907d4000 - 0x907deff7 libCSync.A.dylib ??? (???)
<A05BB12D-CD51-DE43-323B-3A3E99A3EED5>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib
0x907df000 - 0x907e0ff7 com.apple.TrustEvaluationAgent 1.0 (1)
<71E2DA16-83EC-6056-FFEE-862A04B5599F>
/System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent
0x90838000 - 0x908d5ff3 com.apple.LaunchServices 360.3 (360.3)
<C8590D53-E46A-F58A-7CF2-03A8159D8569>
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
0x90cf5000 - 0x90cf5ff7 com.apple.Accelerate.vecLib 3.5 (vecLib 3.5)
<3E039E14-2A15-56CC-0074-EE59F9FBB913>
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
0x90cf6000 - 0x90d07ff7 com.apple.LangAnalysis 1.6.5 (1.6.5)
<E77440D0-76EE-EB4C-3D00-9EDE417F13CF>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
0x90d08000 - 0x90d77ff7 libvMisc.dylib ??? (???)
<59243A8C-2B98-3E71-8032-884D4853E79F>
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
0x90de7000 - 0x90e30fe7 libTIFF.dylib ??? (???)
<6EF87001-6FB4-1405-C588-F6D8042D3534>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
0x90e31000 - 0x90eeafe7 libsqlite3.dylib ??? (???)
<16CEF8E8-8C9A-94CD-EF5D-05477844C005> /usr/lib/libsqlite3.dylib
0x90eeb000 - 0x90f3bfe7 libGLU.dylib ??? (???)
<55A69DCE-1237-341E-F239-CDFE1F5B19BB>
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
0x90f3f000 - 0x90f5dff7 com.apple.CoreVideo 1.6.0 (43.0)
<3A853574-DD9E-08D8-FD2C-6221B55C3E08>
/System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
0x90fa7000 - 0x913dcff7 libLAPACK.dylib ??? (???)
<5E2D2283-57DE-9A49-1DB0-CD027FEFA6C2>
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
0x913dd000 - 0x913e1ff7 libGFXShared.dylib ??? (???)
<ED62E870-E219-C873-88AA-9CE08108F811>
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib
0x913e2000 - 0x913e4ff7 libRadiance.dylib ??? (???)
<0E03CF64-0931-7B9A-F617-4387B809D6D8>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
0x91426000 - 0x91527fe7 libxml2.2.dylib ??? (???)
<C242A74D-280A-90C3-3F79-891624AA45D2> /usr/lib/libxml2.2.dylib
0x91688000 - 0x916e8fe7 com.apple.CoreText 3.0.0 (???)
<8F4FCAE2-8E6F-F0DE-A6AA-15D0228B7F13>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText
0x916e9000 - 0x916f9ff7 libsasl2.2.dylib ??? (???)
<C8744EA3-0AB7-CD03-E639-C4F2B910BE5D> /usr/lib/libsasl2.2.dylib
0x916fa000 - 0x916fdff7 libCoreVMClient.dylib ??? (???)
<16BB2178-B32D-E57E-F1E4-D177F7754232>
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib
0x916fe000 - 0x91703ff7 com.apple.OpenDirectory 10.6 (10.6)
<92582807-E8F3-3DD9-EB42-4195CFB754A1>
/System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
0x91717000 - 0x91809ff7 libcrypto.0.9.8.dylib ??? (???)
<792B8722-3091-5E9F-E25F-67499CFE0599> /usr/lib/libcrypto.0.9.8.dylib
0x92802000 - 0x92c18ff7 libBLAS.dylib ??? (???)
<C4FB303A-DB4D-F9E8-181C-129585E59603>
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
0x92f14000 - 0x92f18ff7 libGIF.dylib ??? (???)
<51848EBF-27D4-0F85-C22A-D1AE10D328F3>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
0x92f19000 - 0x92f31ff7 com.apple.CFOpenDirectory 10.6 (10.6)
<1537FB4F-C112-5D12-1E5D-3B1002A4038F>
/System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
0x92f51000 - 0x9302eff7 com.apple.vImage 4.0 (4.0)
<64597E4B-F144-DBB3-F428-0EC3D9A1219E>
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
0x930ce000 - 0x930cfff7 com.apple.audio.units.AudioUnit 1.6 (1.6)
<68180B96-381C-A09D-5576-606A134FD953>
/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
0x930d0000 - 0x931aafff com.apple.DesktopServices 1.5.1 (1.5.1)
<D9C18268-699B-A996-1035-4EA3695F4074>
/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
0x93b8b000 - 0x93c23fe7 edu.mit.Kerberos 6.5.8 (6.5.8)
<BA9BD282-FF56-3BFD-E78C-7DBE73B48480>
/System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
0x93c24000 - 0x93ceefef com.apple.CoreServices.OSServices 352 (352)
<D9F21CA4-EED0-705F-8F3C-F1322D114B52>
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
0x93fc7000 - 0x94237ffb com.apple.Foundation 6.6 (751)
<A61B645E-1A15-5BCA-3043-C8AB85C6AD30>
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x94238000 - 0x94238ff7 com.apple.CoreServices 44 (44)
<AC35D112-5FB9-9C8C-6189-5F5945072375>
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
0x94239000 - 0x9423bff7 com.apple.securityhi 4.0 (36638)
<962C66FB-5BE9-634E-0810-036CB340C059>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
0x9437c000 - 0x943c0fe7 com.apple.Metadata 10.6.0 (507.1)
<CBD1B22B-5F10-C784-03A2-35106B97DF3F>
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
0x943c1000 - 0x9442bfe7 libstdc++.6.dylib ??? (???)
<411D87F4-B7E1-44EB-F201-F8B4F9227213> /usr/lib/libstdc++.6.dylib
0x945fe000 - 0x94780fe7 libicucore.A.dylib ??? (???)
<FBB66376-CBA9-8149-A1AA-10AB8578C3B3> /usr/lib/libicucore.A.dylib
0x9488f000 - 0x948c2ff7 com.apple.AE 496 (496)
<B638FDD4-7322-F0E4-ACEB-777D8A1399E1>
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
0x948c3000 - 0x948deff7 libPng.dylib ??? (???)
<38DD4AA1-0643-85A0-F2F5-EE9269729975>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
0x948df000 - 0x94a83feb libSystem.B.dylib ??? (???)
<E58B649F-FFDC-AB09-2028-8B706BEF7C0F> /usr/lib/libSystem.B.dylib
0x94a86000 - 0x94aa6fe7 libresolv.9.dylib ??? (???)
<A48921CB-3FA7-3071-AF9C-2D86FB493A3A> /usr/lib/libresolv.9.dylib
0x94aa7000 - 0x94ae9fe7 libvDSP.dylib ??? (???)
<8F8FFFB3-81E3-2969-5688-D5B0979182E6>
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
0x952d0000 - 0x953f9fe7 com.apple.audio.toolbox.AudioToolbox 1.6 (1.6)
<62BEEBE6-68FC-4A48-91CF-39DA2BD793F1>
/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
0x95523000 - 0x9552afff com.apple.print.framework.Print 6.0 (237)
<7A06B15C-B835-096E-7D96-C2FE8F0D21E1>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
0x9552b000 - 0x956a2fef com.apple.CoreFoundation 6.6 (550)
<193E33D6-2E92-3452-773B-60A1A9CCC573>
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x956c1000 - 0x95712ff7 com.apple.HIServices 1.8.0 (???)
<B8EC13DB-A81A-91BF-8C82-66E840C64C91>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
0x95752000 - 0x957f9fe7 com.apple.CFNetwork 454.4 (454.4)
<7C563385-9893-3B48-8607-5BC81DA2C4CF>
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
0x95805000 - 0x95b24fe7 com.apple.CoreServices.CarbonCore 859.1 (859.1)
<2E72AF56-4BE6-294A-7372-19C360688B8B>
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
0x95b25000 - 0x95bd4fef com.apple.ColorSync 4.6.0 (4.6.0)
<66ABAE86-B0EC-D641-913D-08ACA965F9FA>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync
0x95bd5000 - 0x95c09ff7 libcups.2.dylib ??? (???)
<9078BA07-DEE1-6597-D15D-7BE3A20CB5A0> /usr/lib/libcups.2.dylib
0x95c0a000 - 0x95c8afeb com.apple.SearchKit 1.3.0 (1.3.0)
<9E18AEA5-F4B4-8BE5-EEA9-818FC4F46FD9>
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
0x95ce5000 - 0x95d3fff7 com.apple.framework.IOKit 2.0 (???)
<7618DDEC-2E3B-9C6E-FDC9-15169E24B4FB>
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
0x95d40000 - 0x95de8ff7 com.apple.QD 3.31 (???)
<40FCAC85-4E4F-2290-90D4-F66D550ADFDC>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
0x95de9000 - 0x95de9ff7 com.apple.vecLib 3.5 (vecLib 3.5)
<17BEEF92-DF30-CD52-FD65-0B7B43B93617>
/System/Library/Frameworks/vecLib.framework/Versions/A/vecLib
0x95e6a000 - 0x95e70fff com.apple.CommonPanels 1.2.4 (91)
<2438AF5D-067B-B9FD-1248-2C9987F360BA>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
0x95f33000 - 0x95f47ffb com.apple.speech.synthesis.framework 3.10.35
(3.10.35) <57DD5458-4F24-DA7D-0927-C3321A65D743>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
0x95f48000 - 0x95f52fe7 com.apple.audio.SoundManager 3.9.3 (3.9.3)
<5F494955-7290-2D91-DA94-44B590191771>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/A/CarbonSound
0x96277000 - 0x96281ff7 libGL.dylib ??? (???)
<B375A3B6-2983-A4E4-50FB-9087FD606FD6>
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
0x96282000 - 0x96294ff7 com.apple.MultitouchSupport.framework 200.20
(200.20) <1D7EE15B-ADDD-1F57-F1FB-FB5252910D5A>
/System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport
0x9638b000 - 0x963cfff3 com.apple.coreui 0.2 (112)
<A810DFFD-6314-5E2B-93A4-D5626634B1EE>
/System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
0x964ca000 - 0x96686fef com.apple.ImageIO.framework 3.0.0 (3.0.0)
<A37E541F-3D6A-2BE9-AB32-F60CCDE13608>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO
0x96687000 - 0x966d4feb
com.apple.DirectoryService.PasswordServerFramework 6.0 (6.0)
<BF66BA5D-BBC8-78A5-DBE2-F9DE3DD1D775>
/System/Library/PrivateFrameworks/PasswordServer.framework/Versions/A/PasswordServer
0x966d5000 - 0x966d5ff7 com.apple.Carbon 150 (152)
<608A04AB-F35D-D2EB-6629-16B88FB32074>
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
0x9677f000 - 0x9681bfe7 com.apple.ApplicationServices.ATS 4.0 (???)
<81700C90-2614-F7E2-CC6A-B01C24A2BD75>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
0x9681c000 - 0x96859ff7 com.apple.SystemConfiguration 1.10 (1.10)
<897AEEAF-CF5D-2843-C33B-31A0A7C98A6A>
/System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
0x9685a000 - 0x968dcffb SecurityFoundation ??? (???)
<29C27E0E-B2B3-BF6B-B1F8-5783B8B01535>
/System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
0x968dd000 - 0x96b3fff3 com.apple.security 6.0 (36910)
<F045B57C-054F-F06F-EF7E-EABEC2700274>
/System/Library/Frameworks/Security.framework/Versions/A/Security
0x96b40000 - 0x96b4efe7 libz.1.dylib ??? (???)
<7B7A02AB-DA99-6180-880E-D28E4F9AA8EB> /usr/lib/libz.1.dylib
0x96c52000 - 0x97433497 com.apple.CoreGraphics 1.535.5 (???)
<0B93D29C-D957-AD00-10F3-94112D75D6D9>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
0x97434000 - 0x97434ff7 com.apple.Accelerate 1.5 (Accelerate 1.5)
<F642E7A0-3720-FA19-0190-E6DBD9EF2D9B>
/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
0x9754c000 - 0x97556ffb com.apple.speech.recognition.framework 3.10.10
(3.10.10) <E106CC3A-7633-5587-0B29-64E19FCBC613>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
0x97557000 - 0x9757bff7 libJPEG.dylib ??? (???)
<265DBF67-994E-E320-4CB1-9C3DE792C3B2>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
0x97763000 - 0x977dcff3 com.apple.audio.CoreAudio 3.2.0 (3.2)
<91AE891E-6015-AABE-3512-2D5EBCA0937B>
/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
0x977ee000 - 0x977f1ffb com.apple.help 1.3.1 (41)
<67F1F424-3983-7A2A-EC21-867BE838E90B>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
0x97b07000 - 0x97b57ff7 com.apple.framework.familycontrols 2.0 (2.0)
<50617342-E578-4C1C-938A-19A37ECA91CA>
/System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls
0x97b58000 - 0x97b58ff7 com.apple.ApplicationServices 38 (38)
<8012B504-3D83-BFBB-DA65-065E061CFE03>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
0x97b72000 - 0x97c68ff7 libGLProgrammability.dylib ??? (???)
<B8E40851-3A01-7D01-2F96-537BF7FA63B5>
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib
0x97c69000 - 0x97d1bffb libFontParser.dylib ??? (???)
<EB089832-660F-0B34-3AC8-CCDA937987D9>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib
0x97d27000 - 0x97d58ff7 libGLImage.dylib ??? (???)
<0FB347C7-A579-4E51-4733-39AB28064554>
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
0x97d59000 - 0x97d6efff com.apple.ImageCapture 6.0 (6.0)
<3F31833A-38A9-444E-02B7-17619CA6F2A0>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
0x97d7a000 - 0x97e29ff3 com.apple.ink.framework 1.3 (104)
<8526D880-D367-3EF9-DBFD-9A6AB240F57A>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
0x97ea5000 - 0x97f36fe3 com.apple.print.framework.PrintCore 6.0 (312)
<C588530A-0F2C-DD72-E308-3B8735125189>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
0x981e4000 - 0x981f8fe7 libbsm.0.dylib ??? (???)
<14CB053A-7C47-96DA-E415-0906BA1B78C9> /usr/lib/libbsm.0.dylib
0x983f3000 - 0x98412fe7 com.apple.opencl 11 (11)
<372A42E7-FB10-B74D-E1A0-980E94D07021>
/System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
0x98413000 - 0x98439fff com.apple.DictionaryServices 1.1 (1.1)
<07694B30-56A9-5C98-B8BC-DA0628715FA8>
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
0x9843a000 - 0x98447ff7 com.apple.opengl 1.6.3 (1.6.3)
<59D86286-B46F-B0E4-68F8-E5CDCADE393E>
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
0x988f7000 - 0x98c5bff7 com.apple.QuartzCore 1.6.0 (226.0)
<7E29DD09-BE04-AA06-5C81-5C093F16901B>
/System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
0x98c5f000 - 0x98f82fef com.apple.HIToolbox 1.6.0 (???)
<6F95AF67-678A-D8BC-FFC2-029C9AA2F44A>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
0x99181000 - 0x9922efe7 libobjc.A.dylib ??? (???)
<410DD065-A18F-F054-0457-65525F4D1039> /usr/lib/libobjc.A.dylib
0x992f9000 - 0x99315fe3 com.apple.openscripting 1.3 (???)
<D2FF4419-FD71-5D4A-F397-B03E82085232>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
0x9932c000 - 0x9932ffe7 libmathCommon.A.dylib ??? (???)
<1622A54F-1A98-2CBE-B6A4-2122981A500E> /usr/lib/system/libmathCommon.A.dylib
0x99330000 - 0x99358ff7 libxslt.1.dylib ??? (???)
<769EF4B2-C1AD-73D5-AAAD-1564DAEA77AF> /usr/lib/libxslt.1.dylib
0x993d4000 - 0x993d8ff7 IOSurface ??? (???)
<C11D3FF3-EB51-A07D-EF24-9C2004115724>
/System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
0x993d9000 - 0x993fbff3 com.apple.DirectoryService.Framework 3.6 (621)
<61569C79-6567-BE8F-4F76-BAC04E5FBF79>
/System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryService
0x993fc000 - 0x99408ff7 libkxld.dylib ??? (???)
<152C8DBB-0149-5827-3240-E57CA85CFE5F> /usr/lib/system/libkxld.dylib
0xffff0000 - 0xffff1fff libSystem.B.dylib ??? (???)
<E58B649F-FFDC-AB09-2028-8B706BEF7C0F> /usr/lib/libSystem.B.dylib
Model: MacBookPro5,4, BootROM MBP53.00AC.B03, 2 processors, Intel Core 2
Duo, 2.53 GHz, 4 GB, SMC 1.49f2
Graphics: NVIDIA GeForce 9400M, NVIDIA GeForce 9400M, PCI, 256 MB
Memory Module: global_name
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x8D),
Broadcom BCM43xx 1.0 (5.10.91.19)
Bluetooth: Version 2.2.1f7, 2 service, 1 devices, 1 incoming serial ports
Network Service: AirPort, AirPort, en1
Serial ATA Device: Hitachi HTS545025B9SA02, 232,89 GB
Serial ATA Device: MATSHITADVD-R UJ-868
USB Device: iPod, 0x05ac (Apple Inc.), 0x1261, 0x24100000
USB Device: Built-in iSight, 0x05ac (Apple Inc.), 0x8507, 0x24400000
USB Device: Internal Memory Card Reader, 0x05ac (Apple Inc.), 0x8403,
0x26500000
USB Device: IR Receiver, 0x05ac (Apple Inc.), 0x8242, 0x04500000
USB Device: Apple Internal Keyboard / Trackpad, 0x05ac (Apple Inc.),
0x0237, 0x04600000
USB Device: USB Receiver, 0x046d (Logitech Inc.), 0xc526, 0x06200000
USB Device: BRCM2046 Hub, 0x0a5c (Broadcom Corp.), 0x4500, 0x06100000
USB Device: Bluetooth USB Host Controller, 0x05ac (Apple Inc.), 0x8213,
0x06110000
----------
components: IDLE
messages: 94682
nosy: MNilson
severity: normal
status: open
title: Error when running a code
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7239>
_______________________________________
From report at bugs.python.org Fri Oct 30 06:15:49 2009
From: report at bugs.python.org (Peter Gibson)
Date: Fri, 30 Oct 2009 05:15:49 +0000
Subject: [New-bugs-announce] [issue7240] subprocess.Popen.stdout.flush fails
os OS-X 10.6.1
In-Reply-To: <1256879749.75.0.623795302461.issue7240@psf.upfronthosting.co.za>
Message-ID: <1256879749.75.0.623795302461.issue7240@psf.upfronthosting.co.za>
New submission from Peter Gibson <petehere at gmail.com>:
subprocess.Popen.stdout.flush() fails on OS-X 10.6.1 under the bundled
Python 2.6.1 and 2.6.3 from Macports.
>>> from subprocess import Popen, PIPE
>>> p = Popen('cat', stdin=PIPE, stdout=PIPE)
>>> p.stdout.flush()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
IOError: [Errno 9] Bad file descriptor
However it works on Python 2.6.2 on Linux.
----------
components: Library (Lib)
messages: 94694
nosy: petegibson
severity: normal
status: open
title: subprocess.Popen.stdout.flush fails os OS-X 10.6.1
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7240>
_______________________________________
From report at bugs.python.org Fri Oct 30 07:30:57 2009
From: report at bugs.python.org (Jebagnanadasa)
Date: Fri, 30 Oct 2009 06:30:57 +0000
Subject: [New-bugs-announce] [issue7241] tkinter fails to import
In-Reply-To: <1256884257.03.0.484810031338.issue7241@psf.upfronthosting.co.za>
Message-ID: <1256884257.03.0.484810031338.issue7241@psf.upfronthosting.co.za>
New submission from Jebagnanadasa <jebagnanadas at gmail.com>:
import _tkinter # If this fails your Python may not be configured for Tk
I'm using python3 in linux. In windows tkinter is working fine but in
mandriva linux spring 2009 it fails to import. Can you please tell me
step-by-step on how to fix this issue? In python3.1 home page the
description is not clear or it can't be understood by the beginner. As
i'm a beginner for programming python in linux please help me out. I
want to know what is the thing i missed during installation. I've done
the things correctly as mentioned in the python readme text inside the
python3.1 tarball file. While searching the net i found out that if i
want to fix this issue i've to uninstall and install it again. what
should i do now?
----------
components: Tkinter
messages: 94697
nosy: python.noob
severity: normal
status: open
title: tkinter fails to import
type: resource usage
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7241>
_______________________________________
From report at bugs.python.org Fri Oct 30 11:58:02 2009
From: report at bugs.python.org (Zsolt Cserna)
Date: Fri, 30 Oct 2009 10:58:02 +0000
Subject: [New-bugs-announce] [issue7242] Forking in a thread raises
RuntimeError
In-Reply-To: <1256900282.72.0.764098234436.issue7242@psf.upfronthosting.co.za>
Message-ID: <1256900282.72.0.764098234436.issue7242@psf.upfronthosting.co.za>
New submission from Zsolt Cserna <zsolt.cserna at morganstanley.com>:
Python 2.6.4 (r264:75706, Oct 29 2009, 12:00:12) [C] on sunos5
On my sunos5 system if I call os.fork() in a thread created by
thread.start_new_thread(), it raises RuntimeError with the message 'not
holding the import lock'. It's a vanilla python compiled on sunos5 with
suncc. In 2.6.3 it's ok, I think this issue is caused by patch located
at http://codereview.appspot.com/96125/show.
The problem can be re-produced by running the script attached.
I've looked into the source and it seems to me the following:
Based on the the change above, it calls fork1() system call between a
lock-release calls:
3635 ? _PyImport_AcquireLock();
3636 ? pid = fork1();
3637 ? result = _PyImport_ReleaseLock();
_PyImport_ReleaseLock is called in both the child and parent. Digging
more into the code, _PyImport_ReleaseLock starts with the following:
long me = PyThread_get_thread_ident();
if (me == -1 || import_lock == NULL)
return 0; /* Too bad */
if (import_lock_thread != me)
return -1;
In the above code, if I interpret correctly, it compares the result of
the current thread id returned by PyThread_get_thread_ident call with
the thread id of the thread holding the lock - if it's different then
the current thread cannot release the lock because it's not owned by it.
Based on my results on solaris the 'me' variable will be different in
the parent and in the child (in parent it remains the same) - resulting
that the child thinks that it's not holding the release lock.
I'm using pthreads on both linux and solaris. On linux the code above is
working fine, but on solaris it behaves differently.
----------
components: Library (Lib)
files: thread_test.py
messages: 94701
nosy: csernazs
severity: normal
status: open
title: Forking in a thread raises RuntimeError
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15232/thread_test.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7242>
_______________________________________
From report at bugs.python.org Fri Oct 30 16:29:56 2009
From: report at bugs.python.org (Jonathan Beard)
Date: Fri, 30 Oct 2009 15:29:56 +0000
Subject: [New-bugs-announce] [issue7243] mac binary download link for 2.6.4
broken
In-Reply-To: <1256916596.04.0.335232385652.issue7243@psf.upfronthosting.co.za>
Message-ID: <1256916596.04.0.335232385652.issue7243@psf.upfronthosting.co.za>
New submission from Jonathan Beard <jt.beard at gmail.com>:
the mac binary download link for python 2.6.4 is broken:
http://python.org/ftp/python/2.6.4/python-2.6.4-macosx.dmg
----------
components: Installation
messages: 94708
nosy: beard
severity: normal
status: open
title: mac binary download link for 2.6.4 broken
type: resource usage
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7243>
_______________________________________
From report at bugs.python.org Sat Oct 31 10:07:59 2009
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 31 Oct 2009 09:07:59 +0000
Subject: [New-bugs-announce] [issue7244] itertools.zip_longest behaves
strangely with an iterable class
In-Reply-To: <1256980079.18.0.534636064924.issue7244@psf.upfronthosting.co.za>
Message-ID: <1256980079.18.0.534636064924.issue7244@psf.upfronthosting.co.za>
New submission from Daniel Urban <urban.dani+py at gmail.com>:
I'm trying to write an iterable class, and it behaves strangely with
itertools.zip_longest. The following example demonstrates this:
class Repeater: # this class is similar to itertools.repeat
def __init__(self, o, t):
self.o = o
self.t = int(t)
def __iter__(self): # its iterator is itself
return self
def __next__(self):
if self.t > 0:
self.t -= 1
return self.o
else:
raise StopIteration
(Of course this is a trivial class, which could be substituted with
itertools.repeat, but I wanted to keep it simple for this example.)
The following code shows my problem:
>>> r1 = Repeater(1, 3)
>>> r2 = Repeater(2, 4)
>>> for i, j in zip_longest(r1, r2, fillvalue=0):
... print(i, j)
...
1 2
1 2
1 2
0Traceback (most recent call last):
File "<stdin>", line 2, in <module>
File "zip_longest_test_case.py", line 30, in __next__
raise StopIteration
StopIteration
>>>
It seems, that zip_longest lets through the StopIteration exception,
which it shouldn't.
The strange thing is, that if I use the python implementation of
zip_longest, as it is in the documentation [1], I get the expected
result:
# zip_longest as it is in the documentation:
def zip_longest(*args, fillvalue=None):
# zip_longest('ABCD', 'xy', fillvalue='-') --> Ax By C- D-
def sentinel(counter = ([fillvalue]*(len(args)-1)).pop):
yield counter() # yields the fillvalue, or raises IndexError
fillers = repeat(fillvalue)
iters = [chain(it, sentinel(), fillers) for it in args]
try:
for tup in zip(*iters):
yield tup
except IndexError:
pass
Test code again:
>>> r1 = Repeater(1, 3)
>>> r2 = Repeater(2, 4)
>>> for i, j in zip_longest(r1, r2, fillvalue=0):
... print(i, j)
...
1 2
1 2
1 2
0 2
I would think, that this is the expected behaviour.
Also, Matthew Dixon Cowles discovered, that if using list(), the C
implementation of itertools.zip_longest also works fine:
>>> r1=Repeater(1,3)
>>> r2=Repeater(2,5)
>>> list(itertools.zip_longest(r1,r2,fillvalue=0))
[(1, 2), (1, 2), (1, 2), (0, 2), (0, 2)]
This is strange, and I think it really shouldn't work this way.
(Thanks for Matthew Dixon Cowles' help on the python-help mailing list.)
I'm attaching a test script, which tries all 4 variations (library
zip_longest with and without list(), and the documentation's zip_longest
impplementation with and without list()).
And another thing: it works fine in 2.6.4 (with izip_longest).
----------
components: Extension Modules
files: zip_longest_test_case.py
messages: 94746
nosy: durban
severity: normal
status: open
title: itertools.zip_longest behaves strangely with an iterable class
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file15238/zip_longest_test_case.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7244>
_______________________________________
From report at bugs.python.org Sat Oct 31 20:37:57 2009
From: report at bugs.python.org (Ilya Sandler)
Date: Sat, 31 Oct 2009 19:37:57 +0000
Subject: [New-bugs-announce] [issue7245] better Ctrl-C support in pdb
(program can be resumed)
In-Reply-To: <1257017877.16.0.972733875092.issue7245@psf.upfronthosting.co.za>
Message-ID: <1257017877.16.0.972733875092.issue7245@psf.upfronthosting.co.za>
New submission from Ilya Sandler <ilya.sandler at gmail.com>:
Currently, pressing Ctrl-C in pdb will terminate the program and throw
the user into post-mortem debugging.
Other debuggers (e.g gdb and pydb) treat Ctrl-C differently: Ctrl-C only
stops the program and the user can resume it if needed.
I believe current pdb behavior is user-unfriendly (as wanting to stop
and then resume the execution is a very common use case which is not
supported by pdb at all (I think)).
The attached patch changes pdb's Ctrl-C behavior to match
gdb's: Ctrl-C will stop the program and the user can resume the
execution later.
----------
components: Library (Lib)
files: sig.patch.v0
messages: 94764
nosy: isandler
severity: normal
status: open
title: better Ctrl-C support in pdb (program can be resumed)
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file15241/sig.patch.v0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7245>
_______________________________________