From report at bugs.python.org Tue Dec 1 03:03:01 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 01 Dec 2009 02:03:01 +0000
Subject: [New-bugs-announce] [issue7413] datetime.datetime.isoformat
truncation problem
In-Reply-To: <1259632981.58.0.493446472024.issue7413@psf.upfronthosting.co.za>
Message-ID: <1259632981.58.0.493446472024.issue7413@psf.upfronthosting.co.za>
New submission from Jean-Paul Calderone <exarkun at divmod.com>:
Passing NUL as the separator to isoformat drops the time part of the
result entirely:
>>> import datetime
>>> datetime.datetime.today().isoformat()
'2009-11-30T20:57:37.918750'
>>> datetime.datetime.today().isoformat('x')
'2009-11-30x20:57:39.902573'
>>> datetime.datetime.today().isoformat('\0')
'2009-11-30'
>>>
----------
messages: 95845
nosy: exarkun
severity: normal
status: open
title: datetime.datetime.isoformat truncation problem
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7413>
_______________________________________
From report at bugs.python.org Tue Dec 1 06:08:36 2009
From: report at bugs.python.org (Case Van Horsen)
Date: Tue, 01 Dec 2009 05:08:36 +0000
Subject: [New-bugs-announce] [issue7414] Format code "C" is missing from
skipitem() in getargs.c
In-Reply-To: <1259644116.32.0.35772934709.issue7414@psf.upfronthosting.co.za>
Message-ID: <1259644116.32.0.35772934709.issue7414@psf.upfronthosting.co.za>
New submission from Case Van Horsen <casevh at gmail.com>:
An error was reported on c.l.py. The following code in a Python 3
extension module generated an error:
=====================================
If I use the following C code
static PyObject* foo(PyObject *self, PyObject *args, PyObject *kwrds)
{
char a, b;
char *kwlist[] = {"a", "b", NULL};
if (!PyArg_ParseTupleAndKeywords(args, kwrds, "|CC", kwlist, &a,
&b))
return NULL;
...
then the following works:
>>> foo('a')
>>> foo('a','b')
>>> foo(a='a',b='b')
but the following fails:
>>> foo(b='b')
RuntimeError: impossible<bad format char>: 'CC'
======================================
I traced it down to missing case statement for "C" in skipitem() in
getargs.c. The attached patch seems to fix the issue.
----------
components: Extension Modules
files: getargs.patch
keywords: patch
messages: 95846
nosy: casevh
severity: normal
status: open
title: Format code "C" is missing from skipitem() in getargs.c
versions: Python 3.1
Added file: http://bugs.python.org/file15421/getargs.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7414>
_______________________________________
From report at bugs.python.org Tue Dec 1 07:19:14 2009
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 01 Dec 2009 06:19:14 +0000
Subject: [New-bugs-announce] [issue7415] PyUnicode_FromEncodedObject() uses
PyObject_AsCharBuffer()
In-Reply-To: <1259648354.78.0.66746814248.issue7415@psf.upfronthosting.co.za>
Message-ID: <1259648354.78.0.66746814248.issue7415@psf.upfronthosting.co.za>
New submission from Stefan Behnel <scoder at users.sourceforge.net>:
PyUnicode_FromEncodedObject() currently calls PyObject_AsCharBuffer() to
get the buffer pointer and length of a buffer supporting object. It
should be changed to support the buffer protocol correctly instead.
I filed this as a crash bug as the buffer protocol allows a buffer
supporting object to discard its buffer when the release function is
called. The decode function uses the buffer only *after* releasing it,
thus provoking a crash for objects that implement the buffer protocol
correctly in that they do not allow access to the buffer after the release.
----------
components: Interpreter Core
messages: 95847
nosy: scoder
severity: normal
status: open
title: PyUnicode_FromEncodedObject() uses PyObject_AsCharBuffer()
type: crash
versions: Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7415>
_______________________________________
From report at bugs.python.org Tue Dec 1 10:03:10 2009
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Dec 2009 09:03:10 +0000
Subject: [New-bugs-announce] [issue7416] select module compile errors breaks
OS X multi-architecture builds
In-Reply-To: <1259658190.83.0.917094385944.issue7416@psf.upfronthosting.co.za>
Message-ID: <1259658190.83.0.917094385944.issue7416@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
Release blocker
The changes for Issue7211 to support 64-bit kevent ident fields
in 64-bit builds cause compile errors on those OS X multi-arch
builds which include both 32-bit and 64-bit variants.
Problem is reproducible by this simplified build config:
configure --with-universal-archs=intel --enable-universalsdk=/
make
To support C data types which vary between 32-bit and 64-bit builds,
Include/pymacconfig.h does some magic conditional type definitions
overriding the standard values derived from autoconf configure
processing. Previously, SIZEOF_UINTPTR_T was not referenced in
the Python source; now that selectmodule.c uses it, it needs
to be added to pymacconfig.h. The attached patch does that.
Although the select changes were only added to trunk (r76108)
and py3k (r76111), it would be better to apply this patch to the
maintenance branches as well in the event something else gets
added or backported to them.
----------
assignee: ronaldoussoren
components: Library (Lib), Macintosh
files: issue-select-kevent-osx.txt
messages: 95851
nosy: ned.deily, pitrou, ronaldoussoren
severity: normal
status: open
title: select module compile errors breaks OS X multi-architecture builds
type: compile error
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15425/issue-select-kevent-osx.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7416>
_______________________________________
From report at bugs.python.org Tue Dec 1 14:41:42 2009
From: report at bugs.python.org (ulrik)
Date: Tue, 01 Dec 2009 13:41:42 +0000
Subject: [New-bugs-announce] [issue7417] open builtin has no signature in
docstring
In-Reply-To: <1259674902.72.0.145233253757.issue7417@psf.upfronthosting.co.za>
Message-ID: <1259674902.72.0.145233253757.issue7417@psf.upfronthosting.co.za>
New submission from ulrik <ulrik.sverdrup at gmail.com>:
Python 3.1.1's open has no signature in the docstring so the
documentation for this builtin function is unfortunately very confusing
(IMO is missing the most important part).
>>> help(open)
open(...)
Open file and return a stream. Raise IOError upon failure.
...
----
This must be a regression from the C port of the io module.
I'm keeping my eyes open for more issues like this. Python must be more
friendly to newcomers, but I have seen tendencies of confusing
documentation in Python 3.
----------
components: Library (Lib)
messages: 95856
nosy: englabenny
severity: normal
status: open
title: open builtin has no signature in docstring
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7417>
_______________________________________
From report at bugs.python.org Tue Dec 1 15:04:28 2009
From: report at bugs.python.org (Carl Chenet)
Date: Tue, 01 Dec 2009 14:04:28 +0000
Subject: [New-bugs-announce] [issue7418] hashlib : the names of the
different hash algorithms
In-Reply-To: <1259676268.37.0.504298003404.issue7418@psf.upfronthosting.co.za>
Message-ID: <1259676268.37.0.504298003404.issue7418@psf.upfronthosting.co.za>
New submission from Carl Chenet <chaica at ohmytux.com>:
Hi,
The hashlib module could provide a tuple offering the names of the
different hash algorithms which are guaranteed to be supported.
The expected result:
>>> import hashlib
>>> hashlib.algorithms
('md5', 'sha1', 'sha224', 'sha256', 'sha384', 'sha512')
Here is a patch to do so. It also provides an update for the hashlib
documentation and a test case.
Bye,
Carl Chenet
----------
components: Library (Lib)
files: algorithms_constant_attribute_in_hashlib_module.diff
keywords: patch
messages: 95857
nosy: chaica_
severity: normal
status: open
title: hashlib : the names of the different hash algorithms
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file15427/algorithms_constant_attribute_in_hashlib_module.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7418>
_______________________________________
From report at bugs.python.org Tue Dec 1 16:36:39 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 01 Dec 2009 15:36:39 +0000
Subject: [New-bugs-announce] [issue7419] Crash in _locale.setlocale on
windows
In-Reply-To: <1259681799.96.0.766009696643.issue7419@psf.upfronthosting.co.za>
Message-ID: <1259681799.96.0.766009696643.issue7419@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:
import _locale
_locale.setlocale(12345)
Crashes on Windows with exit code 0xc0000417, a.k.a
STATUS_INVALID_CRUNTIME_PARAMETER.
2.6 and 3.0 are not affected.
setlocale should check the category before passing it to the C runtime:
LC_MIN <= category && category <= LC_MAX
----------
components: Windows
messages: 95863
nosy: amaury.forgeotdarc
severity: normal
status: open
title: Crash in _locale.setlocale on windows
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7419>
_______________________________________
From report at bugs.python.org Tue Dec 1 18:52:14 2009
From: report at bugs.python.org ("Dragon" Dave McKee)
Date: Tue, 01 Dec 2009 17:52:14 +0000
Subject: [New-bugs-announce] [issue7420] turtle - turtle.update() doesn't
override turtle.tracer()
In-Reply-To: <1259689934.3.0.386654946546.issue7420@psf.upfronthosting.co.za>
Message-ID: <1259689934.3.0.386654946546.issue7420@psf.upfronthosting.co.za>
New submission from "Dragon" Dave McKee <dave.mckee at gmail.com>:
Problem:
Using the following code gives different behaviour on versions 2.6.4 and
3.0.1: nothing will be drawn under 3.0.1, but turtle.update() will force
the line to be drawn under 2.6.4. 2.6.4's behaviour is compatible with
the documentation: "turtle.update() - Perform a TurtleScreen update. To
be used when tracer is turned off."
import turtle
from time import sleep
turtle.tracer(100,0) # update screen after 100 drawings
turtle.fd(100)
turtle.update() # force update
sleep(100) # so you can see what's on the screen.
workaround:
use turtle.tracer(1) after drawing instead of turtle.update()
----------
components: Extension Modules
messages: 95868
nosy: dragon
severity: normal
status: open
title: turtle - turtle.update() doesn't override turtle.tracer()
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7420>
_______________________________________
From report at bugs.python.org Tue Dec 1 21:38:20 2009
From: report at bugs.python.org (Angel)
Date: Tue, 01 Dec 2009 20:38:20 +0000
Subject: [New-bugs-announce] [issue7421] Given
In-Reply-To: <1259699900.65.0.917773052949.issue7421@psf.upfronthosting.co.za>
Message-ID: <1259699900.65.0.917773052949.issue7421@psf.upfronthosting.co.za>
New submission from Angel <AngelAssasin187 at hotmail.com>:
# Area calculation program
print "Show Area"
print "----------------------"
print
# Print out the menu:
print "Please select a shape:"
print "1 Rectangle"
print "2 Circle"
# Get the user's choice:
shape = input ("> ")
# Calculate the area:
if shape == 1:
height = input ("Please enter the height: ")
width = input ("Please enter the width: ")
area = height*width
print "The area is", area
else:
radius = input ("Please enter the radius: ")
area = 3.14* (radius**2)
print "The area is", area
----------
components: Windows
messages: 95871
nosy: Fallen
severity: normal
status: open
title: Given
versions: 3rd party
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7421>
_______________________________________
From report at bugs.python.org Tue Dec 1 22:38:14 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 01 Dec 2009 21:38:14 +0000
Subject: [New-bugs-announce] [issue7422] Document inspect.get(full)argspec
limitation to Python function
In-Reply-To: <1259703494.2.0.925283786633.issue7422@psf.upfronthosting.co.za>
Message-ID: <1259703494.2.0.925283786633.issue7422@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
"inspect.getargspec(func)
Get the names and default values of a function?s arguments. "
"inspect.getfullargspec(func)
Get the names and default values of a function?s arguments."
'Function' must be a Python function (or a bound method wrapper
thereof). (Some posted this 'discovery' on python-list today, so it is
not obvious to everyone.)
Suggestion: insert 'Python' before "function's"
or rewrite as
"Get the names and default values of the arguments of a Python function
or bound method."
This is a different request from #1748064, which requested that the
limitation be removed.
----------
assignee: georg.brandl
components: Documentation
messages: 95879
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Document inspect.get(full)argspec limitation to Python function
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7422>
_______________________________________
From report at bugs.python.org Wed Dec 2 02:34:25 2009
From: report at bugs.python.org (bogklug)
Date: Wed, 02 Dec 2009 01:34:25 +0000
Subject: [New-bugs-announce] [issue7423] nested generator expression
produces strange results
In-Reply-To: <1259717665.75.0.392103948854.issue7423@psf.upfronthosting.co.za>
Message-ID: <1259717665.75.0.392103948854.issue7423@psf.upfronthosting.co.za>
New submission from bogklug <bogklug at gmail.com>:
The first of the two maps below gives strange result due to the nested
generator expression (I guess it should give the same result as the
second map).
In [1]: map(list, [(x+y for y in 'c') for x in 'ab'])
Out[1]: [['bc'], ['bc']]
In [2]: map(list, [[x+y for y in 'c'] for x in 'ab'])
Out[2]: [['ac'], ['bc']]
----------
components: Interpreter Core
messages: 95890
nosy: bogklug
severity: normal
status: open
title: nested generator expression produces strange results
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7423>
_______________________________________
From report at bugs.python.org Wed Dec 2 05:57:18 2009
From: report at bugs.python.org (Jon Buller)
Date: Wed, 02 Dec 2009 04:57:18 +0000
Subject: [New-bugs-announce] [issue7424] segmentation fault in listextend
during install
In-Reply-To: <1259729838.45.0.563962594728.issue7424@psf.upfronthosting.co.za>
Message-ID: <1259729838.45.0.563962594728.issue7424@psf.upfronthosting.co.za>
New submission from Jon Buller <jon at bullers.net>:
On a NetBSD/sparc-current system building from the 2.6.4.tgz file...
Compiling /usr/pkg/lib/python2.6/test/test_bool.py ...
Compiling /usr/pkg/lib/python2.6/test/test_bsddb.py ...
Compiling /usr/pkg/lib/python2.6/test/test_bsddb185.py ...
Compiling /usr/pkg/lib/python2.6/test/test_bsddb3.py ...
Compiling /usr/pkg/lib/python2.6/test/test_buffer.py ...
Compiling /usr/pkg/lib/python2.6/test/test_bufio.py ...
Compiling /usr/pkg/lib/python2.6/test/test_builtin.py ...
[1] Segmentation fault (core dumped) PYTHONPATH=/usr/...
*** Error code 139
Stop.
and GDB says...
Reading symbols from /usr/lib/libc.so.12...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libc.so.12
Reading symbols from
/usr/pkgsrc/lang/python26/work/Python-2.6.4/build/lib.netbsd-5.99.15-sparc-2.6/unicodedata.so...
(no debugging symbols found)...done.
Loaded symbols for
/usr/pkgsrc/lang/python26/work/Python-2.6.4/build/lib.netbsd-5.99.15-sparc-2.6/unicodedata.so
Reading symbols from /usr/libexec/ld.elf_so...(no debugging symbols
found)...done.
Loaded symbols for /usr/libexec/ld.elf_so
Core was generated by `python'.
Program terminated with signal 11, Segmentation fault.
#0 0x200b7bac in listextend ()
from /usr/pkgsrc/lang/python26/work/Python-2.6.4/libpython2.6.so.1.0
(gdb) where
#0 0x200b7bac in listextend ()
from /usr/pkgsrc/lang/python26/work/Python-2.6.4/libpython2.6.so.1.0
#1 0x20087b00 in PySequence_List ()
from /usr/pkgsrc/lang/python26/work/Python-2.6.4/libpython2.6.so.1.0
#2 0x20129760 in assemble ()
from /usr/pkgsrc/lang/python26/work/Python-2.6.4/libpython2.6..so.1.0
#3 0x2012e12c in compiler_function ()
from /usr/pkgsrc/lang/python26/work/Python-2.6.4/libpython2.6.so.1.0
#4 0x2012e288 in compiler_body ()
from /usr/pkgsrc/lang/python26/work/Python-2.6.4/libpython2.6.so.1.0
#5 0x2012e498 in compiler_class ()
from /usr/pkgsrc/lang/python26/work/Python-2.6.4/libpython2.6.so.1.0
#6 0x2012e288 in compiler_body ()
from /usr/pkgsrc/lang/python26/work/Python-2.6.4/libpython2.6.so.1.0
#7 0x2012e958 in PyAST_Compile ()
from /usr/pkgsrc/lang/python26/work/Python-2.6.4/libpython2.6.so.1.0
#8 0x20142a48 in Py_CompileStringFlags ()
from /usr/pkgsrc/lang/python26/work/Python-2.6.4/libpython2.6.so.1.0
...
----------
components: Installation
messages: 95895
nosy: jon at bullers.net
severity: normal
status: open
title: segmentation fault in listextend during install
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7424>
_______________________________________
From report at bugs.python.org Wed Dec 2 21:49:32 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 02 Dec 2009 20:49:32 +0000
Subject: [New-bugs-announce] [issue7425] [PATCH] Improve the robustness of
"pydoc -k" in the face of broken modules
In-Reply-To: <1259786972.24.0.35920903506.issue7425@psf.upfronthosting.co.za>
Message-ID: <1259786972.24.0.35920903506.issue7425@psf.upfronthosting.co.za>
New submission from Dave Malcolm <dmalcolm at redhat.com>:
I see occasional failures where a broken module prevents "pydoc -k" ("apropos") from working.
Examples of failures (from our downstream bug tracker) are:
https://bugzilla.redhat.com/show_bug.cgi?id=461419 : "pydoc -k" yields "NameError: name 'wglUseFontBitmapsW' is not
defined"
(a broken OpenGL/WGL/__init__.py module)
https://bugzilla.redhat.com/show_bug.cgi?id=447779 : "pydoc turbogears" doesn't work
(broken TurboGears module)
https://bugzilla.redhat.com/show_bug.cgi?id=246212 : "pydoc -k searchterm" MemoryError. permission denied.
(module only intended to be importable as "root" user)
In each case one or more of the many modules on the system are broken, and importing them leads to an exception being
raised that isn't ImportError.
In each case, the exception bubbles up through the pydoc call ands leads to it exiting.
Obviously the broken modules should be fixed, but it seems to me that pydoc could be more robust against this situation.
I'm attaching a simple patch which makes "pydoc -k" more robust against this situation, by silently discarding all
exceptions raised by imported modules.
How does this look?
One downstream bug report requested taking it further:
> Running "pydoc -k" should catch all exceptions while importing modules, and
> display failed modules _after_ all positive keyword matches (not in between).
> It also should redirect stdout/stderr while importing so error message e.a.
> don't clutter up the list of hits.
to deal with broken modules that spew error messages (this was in https://bugzilla.redhat.com/show_bug.cgi?id=461419#c3
); I've seen some do it to stdout and some to stderr.
How does this sound? I can try to update the patch for this too, if this sounds sane to you.
----------
components: Demos and Tools
files: make-pydoc-more-robust-001.patch
keywords: patch
messages: 95918
nosy: dmalcolm
severity: normal
status: open
title: [PATCH] Improve the robustness of "pydoc -k" in the face of broken modules
versions: Python 2.6
Added file: http://bugs.python.org/file15443/make-pydoc-more-robust-001.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7425>
_______________________________________
From report at bugs.python.org Thu Dec 3 11:12:53 2009
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Thu, 03 Dec 2009 10:12:53 +0000
Subject: [New-bugs-announce] [issue7426] StringIO and with statement
In-Reply-To: <1259835173.72.0.00703663082921.issue7426@psf.upfronthosting.co.za>
Message-ID: <1259835173.72.0.00703663082921.issue7426@psf.upfronthosting.co.za>
New submission from Jean-Michel Fauth <wxjmfauth at gmail.com>:
When toying with the "with" statement, I fell on this:
Python 2.6.4
>>> with open('abc.txt', 'r') as f:
for line in f:
print line.rstrip()
abc
def
>>>
>>> import StringIO
>>> fo = StringIO.StringIO('abc\ndef\n')
>>> fo.seek(0)
>>> with fo as f2:
for line in f2:
print line.rstrip()
Traceback (most recent call last):
File "<psi last command>", line 2, in <module>
AttributeError: StringIO instance has no attribute '__exit__'
>>>
>>>
Same result with cStringIO
-----
Python 3.1.1
>>> fo = io.StringIO('abc\ndef\n')
>>> fo.seek(0)
0
>>> with fo as f:
for line in f:
print(line.rstrip())
abc
def
>>>
----------
components: None
messages: 95924
nosy: jmfauth
severity: normal
status: open
title: StringIO and with statement
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7426>
_______________________________________
From report at bugs.python.org Thu Dec 3 16:52:44 2009
From: report at bugs.python.org (djc)
Date: Thu, 03 Dec 2009 15:52:44 +0000
Subject: [New-bugs-announce] [issue7427] BadStatusLine is hell to debug
In-Reply-To: <1259855564.36.0.140869506599.issue7427@psf.upfronthosting.co.za>
Message-ID: <1259855564.36.0.140869506599.issue7427@psf.upfronthosting.co.za>
New submission from djc <dirkjan at ochtman.nl>:
For whatever reason, BadStatusLine tracebacks often don't show the line
passed into them. Given the errr, heavy architecture of httplib, this
makes it pretty bad to debug. It's not clear to me why this is:
Traceback (most recent call last):
File "/home/djc/src/couchdb-python/couchdb/tests/client.py", line 138,
in test_attachment_crud_with_files
doc = self.db['foo']
File "/home/djc/src/couchdb-python/couchdb/client.py", line 293, in
__getitem__
_, _, data = self.resource.get(id)
File "/home/djc/src/couchdb-python/couchdb/http.py", line 333, in get
return self._request('GET', path, headers=headers, **params)
File "/home/djc/src/couchdb-python/couchdb/http.py", line 350, in _request
credentials=self.credentials)
File "/home/djc/src/couchdb-python/couchdb/http.py", line 179, in request
resp = _try_request()
File "/home/djc/src/couchdb-python/couchdb/http.py", line 167, in
_try_request
return conn.getresponse()
File "/usr/lib/python2.6/httplib.py", line 950, in getresponse
File "/usr/lib/python2.6/httplib.py", line 390, in begin
File "/usr/lib/python2.6/httplib.py", line 354, in _read_status
BadStatusLine
However, some interactive testing shows that this should work:
djc at enrai couchdb-python $ python
Python 2.6.2 (r262:71600, Oct 5 2009, 12:18:48)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class CrapShoot(Exception):
... def __init__(self, a):
... self.args = a,
...
>>> raise CrapShoot('a')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
__main__.CrapShoot: a
>>> class ParentExc(Exception):
... pass
...
>>> class CrapShoot(ParentExc):
... def __init__(self, a):
... self.args = a,
...
>>> raise CrapShoot('a')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
__main__.CrapShoot: a
>>>
Definition of BadStatusLine:
class BadStatusLine(HTTPException):
def __init__(self, line):
self.args = line,
self.line = line
class HTTPException(Exception):
# Subclasses that define an __init__ must call Exception.__init__
# or define self.args. Otherwise, str() will fail.
pass
The note here seems like a cautionary but insufficient tale...
----------
components: Library (Lib)
messages: 95934
nosy: djc
severity: normal
status: open
title: BadStatusLine is hell to debug
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7427>
_______________________________________
From report at bugs.python.org Thu Dec 3 17:47:28 2009
From: report at bugs.python.org (Bill Spotz)
Date: Thu, 03 Dec 2009 16:47:28 +0000
Subject: [New-bugs-announce] [issue7428] Possible memory issue with optparse
In-Reply-To: <1259858848.42.0.339728371454.issue7428@psf.upfronthosting.co.za>
Message-ID: <1259858848.42.0.339728371454.issue7428@psf.upfronthosting.co.za>
New submission from Bill Spotz <wfspotz at sandia.gov>:
I develop python extension modules for Trilinos, a large scientific
computing project:
http://trilinos.sandia.gov
Unit testing my extension modules under Mac OS X, I came across the
following error messages after upgrading from gcc 4.0 to basically any
higher version:
python(65587) malloc: *** error for object 0x1715674: Non-aligned
pointer being freed
Debugging the problem (which occurs for me in several places in several
test scripts), the error was always being raised in the built-in C++
method
ostream::operator<<(int)
which indicated to me that the problem was really probably somewhere
else, and just being triggered in the ostream operator.
Trying to isolate the problem in a smaller script, I was unable to
reproduce the error until I added
import optparse
By the same token, I was able to eliminate the problem in my test
scripts by getting rid of "import optparse". I have changed these
scripts now to use getopt, and they are running without error, but I
thought I would report this strange behavior.
I realize after all of this that the problem might not actually be with
optparse, but it sure seems like a likely culprit. I would be happy to
work with someone to try to reproduce the error, and then hopefully
such a python expert would be able to find the actual issue.
----------
components: Extension Modules
messages: 95936
nosy: wfspotz
severity: normal
status: open
title: Possible memory issue with optparse
type: resource usage
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7428>
_______________________________________
From report at bugs.python.org Thu Dec 3 19:30:48 2009
From: report at bugs.python.org (Martin Altmayer)
Date: Thu, 03 Dec 2009 18:30:48 +0000
Subject: [New-bugs-announce] [issue7429] PrettyPrinter cannot print dicts
with unsortable keys
In-Reply-To: <1259865048.21.0.71561189105.issue7429@psf.upfronthosting.co.za>
Message-ID: <1259865048.21.0.71561189105.issue7429@psf.upfronthosting.co.za>
New submission from Martin Altmayer <martin.altmayer at web.de>:
In the following code I use a class for dictionary-keys that has a
__hash__-function but cannot be ordered and try to print that dictionary
with a PrettyPrinter.
import pprint
pp = pprint.PrettyPrinter()
# A class that supports hashing and comparison for equality but cannot
be ordered
class KeyClass:
def __init__(self,id):
self.id = id
def __eq__(self,other):
return self.id == other.id
def __ne__(self,other):
return self.id != other.id
def __hash__(self):
return self.id
dictionary = dict.fromkeys([KeyClass(i) for i in range(10)])
pp.pprint(dictionary)
The script crashes with the following errors:
Traceback (most recent call last):
File "/usr/local/lib/python3.1/pprint.py", line 272, in _safe_repr
items = sorted(items)
TypeError: unorderable types: KeyClass() < KeyClass()
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "bug.py", line 20, in <module>
pp.pprint(dictionary)
File "/usr/local/lib/python3.1/pprint.py", line 106, in pprint
self._format(object, self._stream, 0, 0, {}, 0)
File "/usr/local/lib/python3.1/pprint.py", line 129, in _format
rep = self._repr(object, context, level - 1)
File "/usr/local/lib/python3.1/pprint.py", line 216, in _repr
self._depth, level)
File "/usr/local/lib/python3.1/pprint.py", line 228, in format
return _safe_repr(object, context, maxlevels, level)
File "/usr/local/lib/python3.1/pprint.py", line 277, in _safe_repr
items = sorted(items, key=sortkey)
TypeError: unorderable types: KeyClass() < KeyClass()
----------
components: None
messages: 95939
nosy: maranos
severity: normal
status: open
title: PrettyPrinter cannot print dicts with unsortable keys
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7429>
_______________________________________
From report at bugs.python.org Thu Dec 3 20:58:45 2009
From: report at bugs.python.org (David W. Lambert)
Date: Thu, 03 Dec 2009 19:58:45 +0000
Subject: [New-bugs-announce] [issue7430] "cmp" still sends messages
In-Reply-To: <1259870325.93.0.208726118911.issue7430@psf.upfronthosting.co.za>
Message-ID: <1259870325.93.0.208726118911.issue7430@psf.upfronthosting.co.za>
New submission from David W. Lambert <b49P23TIvg at stny.rr.com>:
'''
RuntimeError: maximum recursion depth exceeded in cmp
Python 3.1.1 (r311:74480, Oct 2 2009, 12:29:57)
[GCC 4.3.3] on linux2
'''
import itertools,pprint
combos = itertools.combinations
def connect(nodes,a,b):
nodes[a].append(b)
nodes[b].append(a)
def insert(nodes,components):
if components == 0:
pprint.pprint(nodes)
for (i,node,) in enumerate(nodes):
if not node:
break
i += 2
for joints in combos(range(i),2):
connect(nodes,*joints)
nest = [node[:]for node in nodes]
insert(nest,components-1)
def e155(components):
if components < 1:
return 0
network = [[]for i in range((components+1)*2)]
insert(network,components)
return network
e155(2)
----------
messages: 95943
nosy: LambertDW
severity: normal
status: open
title: "cmp" still sends messages
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7430>
_______________________________________
From report at bugs.python.org Thu Dec 3 23:12:25 2009
From: report at bugs.python.org (ivank)
Date: Thu, 03 Dec 2009 22:12:25 +0000
Subject: [New-bugs-announce] [issue7431] UnboundLocalError
during test.test_linecache.LineCacheTests
In-Reply-To: <1259878345.7.0.0592735556458.issue7431@psf.upfronthosting.co.za>
Message-ID: <1259878345.7.0.0592735556458.issue7431@psf.upfronthosting.co.za>
New submission from ivank <ivan at ludios.org>:
Python 2.7, svn r76655.
I ran the tests with
python2.7 Lib/test/testall.py > test-results.txt
test_linecache
test_checkcache (test.test_linecache.LineCacheTests) ... ERROR
test_clearcache (test.test_linecache.LineCacheTests) ... ok
test_getline (test.test_linecache.LineCacheTests) ... ok
======================================================================
ERROR: test_checkcache (test.test_linecache.LineCacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/opt/Python-latest/lib/python2.7/test/test_linecache.py", line
121, in test_checkcache
source.close()
UnboundLocalError: local variable 'source' referenced before assignment
----------------------------------------------------------------------
Ran 3 tests in 0.022s
FAILED (errors=1)
test test_linecache failed -- Traceback (most recent call last):
File "/opt/Python-latest/lib/python2.7/test/test_linecache.py", line
121, in test_checkcache
source.close()
UnboundLocalError: local variable 'source' referenced before assignment
----------
components: Library (Lib)
messages: 95948
nosy: ivank
severity: normal
status: open
title: UnboundLocalError during test.test_linecache.LineCacheTests
type: behavior
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7431>
_______________________________________
From report at bugs.python.org Thu Dec 3 23:30:33 2009
From: report at bugs.python.org (Jared Grubb)
Date: Thu, 03 Dec 2009 22:30:33 +0000
Subject: [New-bugs-announce] [issue7432] Py3k doc: "from __future__ import
division" not necessary
In-Reply-To: <1259879433.31.0.759735104554.issue7432@psf.upfronthosting.co.za>
Message-ID: <1259879433.31.0.759735104554.issue7432@psf.upfronthosting.co.za>
New submission from Jared Grubb <python at jaredgrubb.com>:
In the Python 3.1 docs for the 'dis' module, the following appears:
( http://docs.python.org/3.1/library/dis.html )
BINARY_TRUE_DIVIDE()?
Implements TOS = TOS1 / TOS when from __future__ import division is
in effect.
There is always true in 3k, correct? The "when" clause should be removed.
----------
assignee: georg.brandl
components: Documentation
messages: 95950
nosy: georg.brandl, jaredgrubb
severity: normal
status: open
title: Py3k doc: "from __future__ import division" not necessary
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7432>
_______________________________________
From report at bugs.python.org Thu Dec 3 23:40:29 2009
From: report at bugs.python.org (Pauli Virtanen)
Date: Thu, 03 Dec 2009 22:40:29 +0000
Subject: [New-bugs-announce] [issue7433] MemoryView memory_getbuf causes
segfaults, double call to tp_releasebuffer
In-Reply-To: <1259880029.03.0.2026580728.issue7433@psf.upfronthosting.co.za>
Message-ID: <1259880029.03.0.2026580728.issue7433@psf.upfronthosting.co.za>
New submission from Pauli Virtanen <pav at iki.fi>:
The following code causes a segmentation fault (or glibc error, or other
problems):
>>> x = someobject()
>>> y = memoryview(x)
>>> z = memoryview(y)
The problem is that someobject.bf_releasebuffer will be called two times
with an identical Py_buffer structure.
This can be seen in memoryobject.c:
static int
memory_getbuf(PyMemoryViewObject *self, Py_buffer *view, int flags)
{
int res = 0;
/* XXX for whatever reason fixing the flags seems necessary */
if (self->view.readonly)
flags &= ~PyBUF_WRITABLE;
if (self->view.obj != NULL)
res = PyObject_GetBuffer(self->view.obj, view, flags);
if (view)
dup_buffer(view, &self->view);
return res;
}
At the end of the call, view and self->view contain identical data
because of the call to dup_buffer.
static void
memory_releasebuf(PyMemoryViewObject *self, Py_buffer *view)
{
PyBuffer_Release(view);
}
But when the outer memoryview is destroyed, memory_releasebuf calls
PyBuffer_Release for the original object once.
And when the inner memoryview is destroyed, PyBuffer_Release is called
by memory_dealloc the second time. Both calls supply an identical
Py_buffer structure.
Now, if the original object's bf_getbuffer and bf_releasebuffer allocate
some memory dynamically, this will likely cause a double-free of memory,
usually leading to a segmentation fault.
There is no feasible way the bf_releasebuffer can keep track of how many
calls to it have been made. So probably the code in memory_getbuf is
wrong -- at least the dup_buffer function looks wrong.
----------
components: Interpreter Core
messages: 95952
nosy: pv
severity: normal
status: open
title: MemoryView memory_getbuf causes segfaults, double call to tp_releasebuffer
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7433>
_______________________________________
From report at bugs.python.org Fri Dec 4 17:32:43 2009
From: report at bugs.python.org (Anthony Foglia)
Date: Fri, 04 Dec 2009 16:32:43 +0000
Subject: [New-bugs-announce] [issue7434] pprint doesn't know how to print a
namedtuple
In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za>
Message-ID: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za>
New submission from Anthony Foglia <afoglia at gmail.com>:
It would be nice if pprint could format namedtuples wrapping lines as it
does with tuples.
Looking at the code, this does not look like an easy task. Completely
rewriting pprint to allow it to be extensible to user-created classes
would be best, but involve a ton of work. Simple making all named
tuples derive from a named tuple base class (itself derived from tuple)
would be simpler, albeit more of a hack.
----------
components: Library (Lib)
messages: 95968
nosy: afoglia
severity: normal
status: open
title: pprint doesn't know how to print a namedtuple
type: feature request
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7434>
_______________________________________
From report at bugs.python.org Fri Dec 4 21:55:17 2009
From: report at bugs.python.org (flox)
Date: Fri, 04 Dec 2009 20:55:17 +0000
Subject: [New-bugs-announce] [issue7435] Int/Long: some tests are duplicate
and error messages refer to "long"
In-Reply-To: <1259960117.54.0.630253268501.issue7435@psf.upfronthosting.co.za>
Message-ID: <1259960117.54.0.630253268501.issue7435@psf.upfronthosting.co.za>
New submission from flox <laxyf at yahoo.fr>:
In python 3.x there's a single type for integer: int.
The automatic conversion of the test suite has created many tests which
are duplicate of each other.
The attached patch removes duplication of tests, and fix the strings for
these modules:
Lib/random.py
Lib/test/mapping_tests.py
Lib/test/pickletester.py
Lib/test/string_tests.py
Lib/test/test_binop.py
Lib/test/test_builtin.py
Lib/test/test_datetime.py
Lib/test/test_decimal.py
Lib/test/test_descr.py
Lib/test/test_dict.py
Lib/test/test_getargs2.py
Lib/test/test_int.py
Lib/test/test_long.py
Lib/test/test_types.py
----------
components: Tests
messages: 95971
nosy: flox
severity: normal
status: open
title: Int/Long: some tests are duplicate and error messages refer to "long"
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7435>
_______________________________________
From report at bugs.python.org Fri Dec 4 22:23:01 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Dec 2009 21:23:01 +0000
Subject: [New-bugs-announce] [issue7436] Define 'object with assignable
attributes'
In-Reply-To: <1259961781.03.0.33355289278.issue7436@psf.upfronthosting.co.za>
Message-ID: <1259961781.03.0.33355289278.issue7436@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
On Python list, someone asked what guarantees that functions have and
will continue to have assignable attributes. I started to say 'the docs'
but failed to find anything specific in 7.6. Function definitions or
LibRef 5.12.3. Functions (all references to 3.1/2a docs).
5.3.1 Attribute references says "The primary must evaluate to an object
of a type that supports attribute references, which most objects do."
That is true for reading/getting but not for writing/setting.
6.2. Assignment statements says "If the target is an attribute
reference: The primary expression in the reference is evaluated. It
should yield an object with assignable attributes;" But which are those?
I propose to add a sentence like "Objects with assignable attributes
include modules, user-defined (Python-coded) functions and classes, and
instances of such classes."
If this leaves anything out, it can be expanded.
I tested and was somewhat surprised to modules based on C code (_socket,
_tkinter) allowed attribute setting. I use 'user'defined' because the
docs do in several places. I added 'Python-coded' because that is the
real relevant characteristic. C-coded user-defined functions in
user-written extension modules do not have settable attributes (I
presume), whereas imported Python-coded functions, in stdlib or 3-rd
party modules do. LibRef 5.12.3 "There are really two flavors of
function objects: built-in functions and user-defined functions." could
leave a reader wondering about imported functions.
A sentence could also be added there "User-defined (Python-coded)
functions have assignable attributes."
----------
assignee: georg.brandl
components: Documentation
messages: 95972
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Define 'object with assignable attributes'
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7436>
_______________________________________
From report at bugs.python.org Sat Dec 5 02:40:22 2009
From: report at bugs.python.org (Ned Deily)
Date: Sat, 05 Dec 2009 01:40:22 +0000
Subject: [New-bugs-announce] [issue7437] OS X 2.6.4 installer fails on 10.3
with two corrupted file names, ignored on 10.4
In-Reply-To: <1259977222.8.0.535522735801.issue7437@psf.upfronthosting.co.za>
Message-ID: <1259977222.8.0.535522735801.issue7437@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
See the thread starting at http://mail.python.org/pipermail/pythonmac-
sig/2009-December/021907.html for full details.
It appears two vestigial gif files included in the 2.6.4 OS installer
are being installed under corrupted file names by the OS X Installer.app
under 10.3 and 10.4. While the error is silently ignored on 10.4, it
apparently causes the whole install to fail on 10.3. The problem does
not seem to occur when installing on 10.5 or 10.6. It is also not
limited to that installer image: I was able to reproduce the problem
with an installer I built on 10.5. However, an installer built on 10.4
from the same source snapshot seems to have the correct file names.
Without knowing exactly why those two file names, and only those two,
are corrupted, it seems risky to let this seemingly minor problem go
unresolved. And it apparently prevents 2.6.4 from being installed on
10.3, a more serious problem.
----------
assignee: ronaldoussoren
components: Macintosh
messages: 95978
nosy: ned.deily, ronaldoussoren
severity: normal
status: open
title: OS X 2.6.4 installer fails on 10.3 with two corrupted file names, ignored on 10.4
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7437>
_______________________________________
From report at bugs.python.org Sat Dec 5 05:34:44 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 05 Dec 2009 04:34:44 +0000
Subject: [New-bugs-announce] [issue7438] Allow to use a part of subprocess
module during building Python
In-Reply-To: <1259987684.71.0.162752431193.issue7438@psf.upfronthosting.co.za>
Message-ID: <1259987684.71.0.162752431193.issue7438@psf.upfronthosting.co.za>
New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:
It is sometimes useful to call subprocess.Popen() in setup.py of
Python. Currently it would fail, because subprocess module tries to
import some modules, which not always are used. I suggest to delay some
imports.
----------
components: Library (Lib)
files: subprocess.py-2.7.patch
keywords: patch
messages: 95980
nosy: Arfrever
severity: normal
status: open
title: Allow to use a part of subprocess module during building Python
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15451/subprocess.py-2.7.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7438>
_______________________________________
From report at bugs.python.org Sat Dec 5 07:08:23 2009
From: report at bugs.python.org (David W. Lambert)
Date: Sat, 05 Dec 2009 06:08:23 +0000
Subject: [New-bugs-announce] [issue7439] Bug or expected behavior? I cannot
tell.
In-Reply-To: <1259993303.11.0.648697393695.issue7439@psf.upfronthosting.co.za>
Message-ID: <1259993303.11.0.648697393695.issue7439@psf.upfronthosting.co.za>
New submission from David W. Lambert <b49P23TIvg at stny.rr.com>:
Raymond Hettinger posted clever Hamming number generator,
http://code.activestate.com/recipes/576961/
which I tried to modify. The function gives incorrect output when
called as hamming_numbers(shorthand = True). It seemed reasonable to
expect the two arrangements of statements controlled by the shorthand
boolean to be functionally equivalent.
http://docs.python.org/3.1/reference/executionmodel.html is relevant,
and makes me think this is not a bug, but I wish it were. I'd
appreciate your determination. Thanks, Dave.
from itertools import tee, chain, islice, groupby
from heapq import merge
def hamming_numbers(shorthand = False):
def deferred_output():
for i in output:
yield i
result, p2, p3, p5 = tee(deferred_output(), 4)
if shorthand: # Lambert modification
m = [(a*x for x in p) for (a,p,) in ((2,p2),(3,p3),(5,p5))]
assert m[0] is not m[2]
merged = merge(*m)
else: # original
m2 = (2*x for x in p2)
m3 = (3*x for x in p3)
m5 = (5*x for x in p5)
merged = merge(m2, m3, m5)
combined = chain([1], merged)
output = (k for k, v in groupby(combined))
return result
if __name__ == '__main__':
print(list(islice(hamming_numbers(), 10)))
print(list(islice(hamming_numbers(True), 10)))
----------
components: Interpreter Core
messages: 95981
nosy: LambertDW
severity: normal
status: open
title: Bug or expected behavior? I cannot tell.
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7439>
_______________________________________
From report at bugs.python.org Sat Dec 5 08:49:24 2009
From: report at bugs.python.org (Mario Vilas)
Date: Sat, 05 Dec 2009 07:49:24 +0000
Subject: [New-bugs-announce] [issue7440] distutils shows incorrect Python
version in MSI installers
In-Reply-To: <1259999364.02.0.642066187222.issue7440@psf.upfronthosting.co.za>
Message-ID: <1259999364.02.0.642066187222.issue7440@psf.upfronthosting.co.za>
New submission from Mario Vilas <mvilas at gmail.com>:
I just hit this silly bug in distutils, should be quite easy to fix.
When building MSI installers for a target_version other than the current
Python version, the target directory selection dialog shows a wrong message.
For example, here is a screen capture of an installer built using Python
2.6, but setting the target as Python 2.5. The message says:
"The destination directory should contain a Python 2.6 installation"
when it should be:
"The destination directory should contain a Python 2.5 installation".
----------
assignee: tarek
components: Distutils
files: msi_installer_wrong_message.png
messages: 95984
nosy: MarioVilas, tarek
severity: normal
status: open
title: distutils shows incorrect Python version in MSI installers
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15453/msi_installer_wrong_message.png
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7440>
_______________________________________
From report at bugs.python.org Sat Dec 5 11:40:58 2009
From: report at bugs.python.org (Lie Ryan)
Date: Sat, 05 Dec 2009 10:40:58 +0000
Subject: [New-bugs-announce] [issue7441] Py3.1: Fatal Python Error:
Py_Initialize...unknown encoding: chcp 65001.
In-Reply-To: <1260009658.59.0.0106753931217.issue7441@psf.upfronthosting.co.za>
Message-ID: <1260009658.59.0.0106753931217.issue7441@psf.upfronthosting.co.za>
New submission from Lie Ryan <lie.1296 at gmail.com>:
maybe related to #6501
Vista 32-bit SP1, Python 3.1:
"""
Microsoft Windows [Version 6.0.6000]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.
D:\>chcp 65001
Active code page: 65001
D:\>python -c 'print("")'
Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: cp65001
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
D:\>python
Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>
"""
Expected, either:
1. print nothing (""), or
2. python exception about unknown encoding, or
3. python exception about cannot encode to the encoding
cp65001 is supposed to be an alias for utf-8. Because of the error,
there is AFAICT no way to set the command prompt to accept utf-8 output
even for pipe redirection.
A workaround is to use sys.stdout.buffer.write() to write raw byte
strings, encoding manually. But this takes us back to python 2.
----------
components: IO, Interpreter Core, Unicode, Windows
messages: 95987
nosy: lieryan
severity: normal
status: open
title: Py3.1: Fatal Python Error: Py_Initialize...unknown encoding: chcp 65001.
type: crash
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7441>
_______________________________________
From report at bugs.python.org Sat Dec 5 11:44:19 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 05 Dec 2009 10:44:19 +0000
Subject: [New-bugs-announce] [issue7442] decimal.py: format failure with
locale specifier
In-Reply-To: <1260009859.57.0.721297634888.issue7442@psf.upfronthosting.co.za>
Message-ID: <1260009859.57.0.721297634888.issue7442@psf.upfronthosting.co.za>
New submission from Stefan Krah <stefan-usenet at bytereef.org>:
Hi, the following works in 2.7 but not in 3.x:
>>> import locale
>>> from decimal import *
>>> locale.setlocale(locale.LC_NUMERIC, 'fi_FI')
'fi_FI'
>>> format(Decimal('1000'), 'n')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.2/decimal.py", line 3632, in __format__
spec = _parse_format_specifier(specifier, _localeconv=_localeconv)
File "/usr/lib/python3.2/decimal.py", line 5628, in
_parse_format_specifier
_localeconv = _locale.localeconv()
File "/usr/lib/python3.2/locale.py", line 111, in localeconv
d = _localeconv()
ValueError: Cannot convert byte to string
----------
messages: 95988
nosy: mark.dickinson, skrah
severity: normal
status: open
title: decimal.py: format failure with locale specifier
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7442>
_______________________________________
From report at bugs.python.org Sat Dec 5 16:20:04 2009
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 05 Dec 2009 15:20:04 +0000
Subject: [New-bugs-announce] [issue7443] test.support.unlink issue on
Windows platform
In-Reply-To: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za>
Message-ID: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za>
New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:
On Windows there are tiny delay between call to os.unlink and real file
removing. Periodically it leads to unittest crashes in cases like this:
test.support.unlink(filename)
f = open(filename, 'wb')
Proposed solution: wait in support.unlink for end of deletion asking
os.stat for removed file (only if os.name == 'nt', of course).
Also test.test_linecache:LineCacheTests.test_checkcache should be fixed
- this one miss to close last opened file and Windows cannot remove it.
Both patches for trunk and py3k is attached.
----------
components: Tests, Windows
files: python3.patch
keywords: patch
messages: 95991
nosy: asvetlov
severity: normal
status: open
title: test.support.unlink issue on Windows platform
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15454/python3.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7443>
_______________________________________
From report at bugs.python.org Sat Dec 5 17:15:10 2009
From: report at bugs.python.org (Daniel Goldman)
Date: Sat, 05 Dec 2009 16:15:10 +0000
Subject: [New-bugs-announce] [issue7444] Allow for a default method in the
JSON decoder
In-Reply-To: <1260029710.19.0.37768452228.issue7444@psf.upfronthosting.co.za>
Message-ID: <1260029710.19.0.37768452228.issue7444@psf.upfronthosting.co.za>
New submission from Daniel Goldman <goldman.inbox at gmail.com>:
I encountered JavaScript-style Date objects in a JSON document that I
wanted to parse, and these objects were causing the Python JSON decoder
to raise an error with a message that said "Expecting object," followed
by the line and column numbers. Here is an example of how such an object
appeared in the document:
"someDate": new Date(1207568200000),
I went looking in the documentation for a way to plug in a "fall-back"
method, to be used when the module's standard conversion methods fail,
but none of the supplied hooks seemed appropriate.
It would be enormously helpful to provide a hook for such a method in
the JSON decoder in a future release of Python. I believe this would
parallel the JSON encoder's "default" keyword argument. In this way,
developers could provide their own method of handling non-standard
values in JSON documents.
Ultimately, to parse the Date objects, I created a function similar to
those in the json.decoder module, added the function to the
json.decoder.ANYTHING list, and assigned a new Scanner object with this
updated list to json.decoder.JSONScanner.
I couldn't find a similar issue in the issues list, but my apologies if
this has already been suggested.
----------
components: Library (Lib)
messages: 95994
nosy: dhgoldman
severity: normal
status: open
title: Allow for a default method in the JSON decoder
type: feature request
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7444>
_______________________________________
From report at bugs.python.org Sat Dec 5 17:58:46 2009
From: report at bugs.python.org (Chris Lasher)
Date: Sat, 05 Dec 2009 16:58:46 +0000
Subject: [New-bugs-announce] [issue7445] urllib2 (and urllib) should raise
error for incomplete response
In-Reply-To: <1260032326.17.0.135874327566.issue7445@psf.upfronthosting.co.za>
Message-ID: <1260032326.17.0.135874327566.issue7445@psf.upfronthosting.co.za>
New submission from Chris Lasher <chris.lasher at gmail.com>:
This question is motivated by a question on Stack Overflow:
http://stackoverflow.com/questions/1824069/urllib2-not-retrieving-entire-http-response
In the event the user receives an incomplete response when using urllib2
(and urllib), the library should raise an error to indicate the response
is incomplete. This is a matter of checking if the Content-Length
defined in the header matches the size of the retrieved response. While
this can be done by the user, an exception will help alert the more
unwitting, such as myself, by failing early.
----------
components: Library (Lib)
messages: 95995
nosy: gotgenes
severity: normal
status: open
title: urllib2 (and urllib) should raise error for incomplete response
type: behavior
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7445>
_______________________________________
From report at bugs.python.org Sat Dec 5 21:36:54 2009
From: report at bugs.python.org (Thomas Courbon)
Date: Sat, 05 Dec 2009 20:36:54 +0000
Subject: [New-bugs-announce] [issue7446] http.cookies.BaseCookie (and
SimpleCookie) can't be load from dict
In-Reply-To: <1260045414.09.0.536880658138.issue7446@psf.upfronthosting.co.za>
Message-ID: <1260045414.09.0.536880658138.issue7446@psf.upfronthosting.co.za>
New submission from Thomas Courbon <harthie at yahoo.fr>:
Hi there !
According the documentation [1], the following code should work :
>>> from http.cookies import SimpleCookie
>>> c = SimpleCookie({'field1': 'value1', 'field2': 'value2'})
>>> print(c)
'Set-Cookie: field1=value1\r\nSet-Cookie: field2=value2'
But an exception is raised :
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "c:\python31\lib\http\cookies.py", line 507, in output
result.append( V.output(attrs, header) )
AttributeError: 'str' object has no attribute 'output'
in BaseCookie.load(...) the call to BaseCookie.update(rawdata) seem to
use dict.__setitem__ instead of BaseCookie.__setitem__.
Despite it's weird (I believe that the __setitem__ of the child class
should be used) I don't know why.
I don't have a solution to this underlying issue so I propose to define
an update method for BaseCookie:
def update(self, other=None, **kwargs):
if other is None:
other = kwargs
elif not hasattr(other, 'items'):
other = dict(other)
for k, v in other.items():
self[k] = v
This method behave like the dict one.
Hope it help and it's not a duplicate.
Regards,
Thomas
[1] :
http://docs.python.org/3.1/library/http.cookies.html#http.cookies.BaseCookie.load
----------
components: Library (Lib)
messages: 96007
nosy: tcourbon
severity: normal
status: open
title: http.cookies.BaseCookie (and SimpleCookie) can't be load from dict
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7446>
_______________________________________
From report at bugs.python.org Sun Dec 6 01:50:40 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 06 Dec 2009 00:50:40 +0000
Subject: [New-bugs-announce] [issue7447] Sum() doc and behavior mismatch
In-Reply-To: <1260060640.85.0.12368990118.issue7447@psf.upfronthosting.co.za>
Message-ID: <1260060640.85.0.12368990118.issue7447@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
"sum(iterable[, start])
Sums start and the items of an iterable from left to right and returns
the total. start defaults to 0. The iterable?s items are normally
numbers, and are not allowed to be strings."
The last sentence is not currently true (3.1, assume also others).
It is the start value that cannot be a string.
>>> sum([1,2],'')
TypeError: sum() can't sum strings [use ''.join(seq) instead]
>>>sum(['xyz', 'pdq'], Zero()) # R Hettinger's universal zero class
'xyzpdq'
works because start is not a string
>>> sum(['a','b'])
TypeError: unsupported operand type(s) for +: 'int' and 'str'
passes type(start) != str and only fails because + fails.
I am filing this as a doc issue as the easiest fix for the discrepancy
between doc and behavior. But the fix could be a behavior change, though
certain to be controversial. Given that, my suggested revision is:
"The iterable?s items are normally numbers. The start value is not
allowed to be a string."
I think this fits the followup sentence: "The fast, correct way to
concatenate a sequence of strings..."
----------
assignee: georg.brandl
components: Documentation
messages: 96013
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Sum() doc and behavior mismatch
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7447>
_______________________________________
From report at bugs.python.org Sun Dec 6 18:07:46 2009
From: report at bugs.python.org (Clovis Fabricio)
Date: Sun, 06 Dec 2009 17:07:46 +0000
Subject: [New-bugs-announce] [issue7448] when piping output between
subprocesses some fd is left open blocking forever
In-Reply-To: <1260119266.95.0.336121928677.issue7448@psf.upfronthosting.co.za>
Message-ID: <1260119266.95.0.336121928677.issue7448@psf.upfronthosting.co.za>
New submission from Clovis Fabricio <nosklo+python at gmail.com>:
Suppose I want to simulate the following shell pipe using the subprocess
module:
`grep -v not | cut -c 1-10`
The documentation example here
http://docs.python.org/library/subprocess.html#replacing-shell-pipeline
Implies that I want to run this:
grep_process = Popen(["grep", "-v", "not"], stdin=PIPE, stdout=PIPE)
cut_process = Popen(["cut", "-c", "1-10"], stdin=p1.stdout, stdout=PIPE)
grep_process.stdin.write('Hello World\n')
grep_process.stdin.close()
result = cut_process.stdout.read() # blocks forever here
assert result == "Hello Worl\n"
When grep_prcoess starts, two file descriptors are created, one
for each end of the pipe. Lets call those `grep-stdin-w` and
`grep-stdout-r`.
When I run cut_process, `grep-stdout-r` gets passed as cut_process sdtin.
Since `close_fds=False` by default, The effect of that is that
cut_process also
inherits `grep-stdin-w`. So `grep` can't die even if I explicty run
`grep_process.stdin.close()`
because `grep-stdin-w` stdin is still inside cut_process (`cut` ignores
the extra open fd).
Passing `close_fds=True` to the second Popen call makes the code work
perfectly.
`close_fds=True` should be the default on unix systems, because it
closes files descriptors that have nothing to do with the process, leaving
stdin, stdout and stderr working, which is the intended behaviour of
most code.
----------
components: Library (Lib)
messages: 96032
nosy: nosklo
severity: normal
status: open
title: when piping output between subprocesses some fd is left open blocking forever
type: behavior
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7448>
_______________________________________
From report at bugs.python.org Sun Dec 6 18:35:32 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 06 Dec 2009 17:35:32 +0000
Subject: [New-bugs-announce] [issue7449] A number tests "crash" if python is
compiled --without-threads
In-Reply-To: <1260120932.34.0.0390001299533.issue7449@psf.upfronthosting.co.za>
Message-ID: <1260120932.34.0.0390001299533.issue7449@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
In the past (<= 2.6) regrtest skipped a test if any import failure
happened, which masked various real test failures. This was fixed, and
tests that should be skipped if certain modules are not available were
changed to use (test_)support.import_module, which causes a skip if that
particular module cannot be imported.
If python is compiled --without-threads, then the following tests
currently 'crash' because they cannot import thread and/or threading:
test_hashlib test_asyncore test_wait3 test_threading test_socket
test_wait4 test_capi test_xmlrpc test_ctypes
test_zipimport_support test_threading_local test_multiprocessing
test_file2k test_smtplib test_threadedtempfile test_threadsignals
test_thread test_queue test_asynchat test_contextlib
test_bz2 test_ftplib test_cmd test_pdb test_io test_doctest
test_sqlite test_logging test_telnetlib test_threaded_import
test_httpservers test_fork1 test_docxmlrpc test_urllib2_localnet
test_poplib test_socketserver
All of these tests should either be changed to use import_module when
importing thread/threading, or changed so that the tests requiring
thread support are skipped if thread support is not available.
Note that test_bsddb3 also fails, but it is not an import error crash.
----------
components: Tests
keywords: easy
messages: 96035
nosy: r.david.murray
priority: low
severity: normal
stage: needs patch
status: open
title: A number tests "crash" if python is compiled --without-threads
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7449>
_______________________________________
From report at bugs.python.org Mon Dec 7 16:54:20 2009
From: report at bugs.python.org (clutchski)
Date: Mon, 07 Dec 2009 15:54:20 +0000
Subject: [New-bugs-announce] [issue7450] document that os.chmod accepts an
octal digit mode
In-Reply-To: <1260201260.24.0.734078851389.issue7450@psf.upfronthosting.co.za>
Message-ID: <1260201260.24.0.734078851389.issue7450@psf.upfronthosting.co.za>
New submission from clutchski <clutchski at gmail.com>:
It would be helpful to explicitly document that os.chmod accepts octal
digit modes e.g. os.chmod(path, 0755). This is much more user friendly
than saying you must OR bit constants kept in a completely different module.
It could be argued that this change would be make the abstraction leaky,
since the values of the stat.S_I* constants could change, but in
practice, this seems unlikely.
----------
assignee: georg.brandl
components: Documentation
messages: 96060
nosy: clutchski, georg.brandl
severity: normal
status: open
title: document that os.chmod accepts an octal digit mode
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7450>
_______________________________________
From report at bugs.python.org Tue Dec 8 00:08:21 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Dec 2009 23:08:21 +0000
Subject: [New-bugs-announce] [issue7451] improve json decoding performance
In-Reply-To: <1260227301.79.0.395664550525.issue7451@psf.upfronthosting.co.za>
Message-ID: <1260227301.79.0.395664550525.issue7451@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
This patch does two things:
- it speeds up decoding of JSON objects by doing fewer temporary allocations
- it reduces memory use of decoded JSON objects by reusing key strings
when they appear several times in a JSON string
----------
components: Library (Lib)
files: json-opts2.patch
keywords: patch
messages: 96082
nosy: bob.ippolito, pitrou, rhettinger, vkuznet
priority: normal
severity: normal
stage: patch review
status: open
title: improve json decoding performance
type: performance
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15478/json-opts2.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7451>
_______________________________________
From report at bugs.python.org Tue Dec 8 00:33:34 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 07 Dec 2009 23:33:34 +0000
Subject: [New-bugs-announce] [issue7452] Invalid mnemonic 'fnstcw'
In-Reply-To: <1260228814.04.0.00170758422827.issue7452@psf.upfronthosting.co.za>
Message-ID: <1260228814.04.0.00170758422827.issue7452@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
When trying to build 2.7a1 I ran into the following problem on MacOSX
10.4 (Tiger):
$ ./configure --enable-framework --enable-universalsdk
[...]
$ make
[...]
gcc -c -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -
fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -
I. -IInclude -I./Include -DPy_BUILD_CORE -o Python/pymath.o
Python/pymath.c
/var/tmp//ccGDYNCp.s:36:Invalid mnemonic 'fnstcw'
/var/tmp//ccGDYNCp.s:56:Invalid mnemonic 'fldcw'
lipo: can't open input file: /var/tmp//cc4UBrqs.out (No such file or
directory)
make: *** [Python/pymath.o] Error 1
----------
assignee: ronaldoussoren
components: Build, Macintosh
files: config.log
messages: 96085
nosy: ronaldoussoren, srid
severity: normal
status: open
title: Invalid mnemonic 'fnstcw'
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file15481/config.log
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7452>
_______________________________________
From report at bugs.python.org Tue Dec 8 01:00:17 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 08 Dec 2009 00:00:17 +0000
Subject: [New-bugs-announce] [issue7453] HPUX: socketmodule.c -- error 1588:
"AI_PASSIVE" undefined.
In-Reply-To: <1260230417.68.0.353556130353.issue7453@psf.upfronthosting.co.za>
Message-ID: <1260230417.68.0.353556130353.issue7453@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
At line 790, the constant AI_PASSIVE is used without doing a ifdef check
(like done at around 5235).
building '_socket' extension
cc +DAportable -Ae -D_REENTRANT +Z +z -DNDEBUG -O -I. -I./Include -
IInclude -I/home/apy/rrun/build/activepython-DEV/build/py2_7a1-
hpux11_00-parisc-apy27-rrun/python -c /home/apy/rrun/build/activepython-
DEV/build/py2_7a1-hpux11_00-parisc-apy27-
rrun/python/Modules/socketmodule.c -o build/temp.hp-ux-B.11.00-9000-800-
2.7/home/apy/rrun/build/activepython-DEV/build/py2_7a1-hpux11_00-parisc-
apy27-rrun/python/Modules/socketmodule.o
cc: "/home/apy/rrun/build/activepython-DEV/build/py2_7a1-hpux11_00-
parisc-apy27-rrun/python/Modules/socketmodule.c", line 790: error 1588:
"AI_PASSIVE" undefined.
----------
components: Build, Library (Lib)
messages: 96092
nosy: srid
severity: normal
status: open
title: HPUX: socketmodule.c -- error 1588: "AI_PASSIVE" undefined.
type: compile error
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7453>
_______________________________________
From report at bugs.python.org Tue Dec 8 01:12:40 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 08 Dec 2009 00:12:40 +0000
Subject: [New-bugs-announce] [issue7454] Solaris SPARC: _multiprocessing.so:
symbol sem_timedwait: referenced symbol not found
In-Reply-To: <1260231160.36.0.952031207978.issue7454@psf.upfronthosting.co.za>
Message-ID: <1260231160.36.0.952031207978.issue7454@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
[...]
cc -xcode=pic32 -DNDEBUG -O -DHAVE_SEM_TIMEDWAIT=0 -
IModules/_multiprocessing -I. -I./Include -IInclude -
I/export/home/apy/rrun/build/activepython-DEV/build/py2_7a1-solaris8-
sparc-apy27-rrun/python -c /export/home/apy/rrun/build/activepython-
DEV/build/py2_7a1-solaris8-sparc-apy27-
rrun/python/Modules/_multiprocessing/semaphore.c -o build/temp.solaris-
2.8-sun4u-2.7/export/home/apy/rrun/build/activepython-DEV/build/py2_7a1-
solaris8-sparc-apy27-rrun/python/Modules/_multiprocessing/semaphore.o
"/export/home/apy/rrun/build/activepython-DEV/build/py2_7a1-solaris8-
sparc-apy27-rrun/python/Modules/_multiprocessing/semaphore.c", line 318:
warning: implicit function declaration: sem_timedwait
cc -G build/temp.solaris-2.8-sun4u-
2.7/export/home/apy/rrun/build/activepython-DEV/build/py2_7a1-solaris8-
sparc-apy27-rrun/python/Modules/_multiprocessing/multiprocessing.o
build/temp.solaris-2.8-sun4u-
2.7/export/home/apy/rrun/build/activepython-DEV/build/py2_7a1-solaris8-
sparc-apy27-rrun/python/Modules/_multiprocessing/socket_connection.o
build/temp.solaris-2.8-sun4u-
2.7/export/home/apy/rrun/build/activepython-DEV/build/py2_7a1-solaris8-
sparc-apy27-rrun/python/Modules/_multiprocessing/semaphore.o -o
build/lib.solaris-2.8-sun4u-2.7/_multiprocessing.so
*** WARNING: renaming "_multiprocessing" since importing it failed:
ld.so.1: python: fatal: relocation error: file build/lib.solaris-2.8-
sun4u-2.7/_multiprocessing.so: symbol sem_timedwait: referenced symbol
not found
$ uname -a
SunOS nail 5.8 Generic_117350-55 sun4u sparc SUNW,Sun-Fire-280R
----------
components: Build, Library (Lib)
files: config.log
messages: 96094
nosy: srid
severity: normal
status: open
title: Solaris SPARC: _multiprocessing.so: symbol sem_timedwait: referenced symbol not found
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file15483/config.log
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7454>
_______________________________________
From report at bugs.python.org Tue Dec 8 03:59:19 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2009 02:59:19 +0000
Subject: [New-bugs-announce] [issue7455] cPickle: stack underflow in
load_pop()
In-Reply-To: <1260241159.34.0.385504670934.issue7455@psf.upfronthosting.co.za>
Message-ID: <1260241159.34.0.385504670934.issue7455@psf.upfronthosting.co.za>
New submission from STINNER Victor <victor.stinner at haypocalc.com>:
load_pop() pops a value if the stack length is >= 0. The test is wrong:
if the length is zero, the stack is empty and stackUnderflow() have to
be called.
Example:
$ ../../python -c "import cPickle; cPickle.loads('0')"
Erreur de segmentation
----------
components: Extension Modules
files: cpickle_load_pop.patch
keywords: patch
messages: 96106
nosy: haypo
severity: normal
status: open
title: cPickle: stack underflow in load_pop()
versions: Python 2.7
Added file: http://bugs.python.org/file15487/cpickle_load_pop.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7455>
_______________________________________
From report at bugs.python.org Tue Dec 8 08:46:24 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 08 Dec 2009 07:46:24 +0000
Subject: [New-bugs-announce] [issue7456] rfc822.Message.getheaders
undocumented
In-Reply-To: <1260258384.35.0.620529013187.issue7456@psf.upfronthosting.co.za>
Message-ID: <1260258384.35.0.620529013187.issue7456@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
rfc822 misses a doc about getheaders.
Also, I am wondering why getheaders can't take a default value like
getheader.
----------
assignee: georg.brandl
components: Documentation
messages: 96112
nosy: georg.brandl, tarek
severity: normal
status: open
title: rfc822.Message.getheaders undocumented
versions: Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7456>
_______________________________________
From report at bugs.python.org Tue Dec 8 09:32:54 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 08 Dec 2009 08:32:54 +0000
Subject: [New-bugs-announce] [issue7457] Adding a read_pkg_file to
DistributionMetadata
In-Reply-To: <1260261174.05.0.469810624752.issue7457@psf.upfronthosting.co.za>
Message-ID: <1260261174.05.0.469810624752.issue7457@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
This API will allow readong back static PKG-INFO files.
----------
assignee: tarek
components: Distutils
messages: 96113
nosy: tarek
priority: normal
severity: normal
status: open
title: Adding a read_pkg_file to DistributionMetadata
versions: Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7457>
_______________________________________
From report at bugs.python.org Tue Dec 8 11:21:10 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2009 10:21:10 +0000
Subject: [New-bugs-announce] [issue7458] crash in str.find() and str.rfind()
with invalid start value
In-Reply-To: <1260267670.29.0.0996792135992.issue7458@psf.upfronthosting.co.za>
Message-ID: <1260267670.29.0.0996792135992.issue7458@psf.upfronthosting.co.za>
New submission from STINNER Victor <victor.stinner at haypocalc.com>:
str.find() and str.rfind() reads non initialized memory (using
memcmp()) if start is bigger than end.
Attached patch fixes the issue and includes a patch.
----------
components: Interpreter Core
messages: 96117
nosy: haypo
severity: normal
status: open
title: crash in str.find() and str.rfind() with invalid start value
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7458>
_______________________________________
From report at bugs.python.org Tue Dec 8 17:43:41 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 08 Dec 2009 16:43:41 +0000
Subject: [New-bugs-announce] [issue7459] Magic word incorrect in Python 3
In-Reply-To: <1260290620.85.0.183191555328.issue7459@psf.upfronthosting.co.za>
Message-ID: <1260290620.85.0.183191555328.issue7459@psf.upfronthosting.co.za>
New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:
Python/import.c defines magic word which is used in the beginning of
.pyc files to verify if .pyc files have been generated by compatible
version of Python.
Python 2 supports undocumented -U option increases magic word by 1.
Python 3 uses unicode strings by default and doesn't support -U option,
but seemingly incorrect change was committed in r55013, which causes
that magic word is always increased by 1 in Python 3 in contrary to
documentation, which says that it could only happen with some command
line options.
This problem cannot be fixed in Python 3.1.2 for compatibility with
e.g. 3.1.1, but it can be fixed in 3.2. Additionally documentation in
3.1.2 can be fixed.
----------
components: Interpreter Core
files: python-3.2-fix_magic_word.patch
keywords: patch
messages: 96138
nosy: Arfrever, gvanrossum
severity: normal
status: open
title: Magic word incorrect in Python 3
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15498/python-3.2-fix_magic_word.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7459>
_______________________________________
From report at bugs.python.org Tue Dec 8 18:20:57 2009
From: report at bugs.python.org (Lorenz Quack)
Date: Tue, 08 Dec 2009 17:20:57 +0000
Subject: [New-bugs-announce] [issue7460] extended slicing not sufficiently
covered in docs
In-Reply-To: <1260292857.39.0.569709796057.issue7460@psf.upfronthosting.co.za>
Message-ID: <1260292857.39.0.569709796057.issue7460@psf.upfronthosting.co.za>
New submission from Lorenz Quack <don at amberfisharts.com>:
I find the documentation regarding extended slicing to be lacking.
To be honest I couldn't find any documentation about it.
The only - and quite good - source of information I found was [1].
Maybe I didn't search enough. If so I would appreciate a link to the
relevant section.
In fact I didn't really know about extended slicing (except for the
start, stop, step notation) until I implemented a C extension and got a
TypeError in Python 3 because I was only supporting simple slicing. And
this is despite the fact that I don't consider myself a python n00b.
As I am still learning about this protocol at the time of writing. I
might have some things backwards and I don't feel qualified to improve
the docs myself. Instead I would like to point out where I would have
expected some information about this topic:
To begin improvement a hint around "PySequence_GetSlice" that this is a
more or less deprecated API and "tp_as_mapping->mp_subscript" should be
used instead would be useful.
In addition "PyObject_GetItem/tp_as_mapping->mp_subscript" could say
that a slice object is passed when extended slicing is used.
sincerely yours
//Lorenz
PS: I marked this Python 3.x even though the documentation of 2.x lacks
as well because I only got the TypeError in 3.x whereas in 2.x
everything works fine with simple slicing.
[1] http://mail.python.org/pipermail/python-3000/2007-August/009851.html
----------
assignee: georg.brandl
components: Documentation
messages: 96141
nosy: donlorenzo, georg.brandl
severity: normal
status: open
title: extended slicing not sufficiently covered in docs
type: feature request
versions: Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7460>
_______________________________________
From report at bugs.python.org Tue Dec 8 20:52:32 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Dec 2009 19:52:32 +0000
Subject: [New-bugs-announce] [issue7461] os.popen() objects don't support
the context manager protocol
In-Reply-To: <1260301952.86.0.775558943909.issue7461@psf.upfronthosting.co.za>
Message-ID: <1260301952.86.0.775558943909.issue7461@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
This works under trunk but fails under py3k:
>>> import os
>>> with os.popen("ls", "r") as f:
... print(f.read())
...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: __exit__
----------
components: Library (Lib)
messages: 96151
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: os.popen() objects don't support the context manager protocol
type: behavior
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7461>
_______________________________________
From report at bugs.python.org Tue Dec 8 23:46:44 2009
From: report at bugs.python.org (flox)
Date: Tue, 08 Dec 2009 22:46:44 +0000
Subject: [New-bugs-announce] [issue7462] Implement fastsearch algorithm for
rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
New submission from flox <laxyf at yahoo.fr>:
While looking at issue7458 I stopped on:
/* XXX - create reversefastsearch helper! */
Here is the patch which is just the translation of the same algorithm
already implemented for "find/index".
http://effbot.org/zone/stringlib.htm
Note: it supersedes patch for 7458.
----------
components: Interpreter Core
files: fastsearch_rfind.patch
keywords: patch
messages: 96157
nosy: flox
severity: normal
status: open
title: Implement fastsearch algorithm for rfind/rindex
type: performance
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15505/fastsearch_rfind.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________
From report at bugs.python.org Wed Dec 9 11:01:51 2009
From: report at bugs.python.org (Murray Cumming)
Date: Wed, 09 Dec 2009 10:01:51 +0000
Subject: [New-bugs-announce] [issue7463] PyDateTime_IMPORT() causes compiler
warnings
In-Reply-To: <1260352911.97.0.550126067946.issue7463@psf.upfronthosting.co.za>
Message-ID: <1260352911.97.0.550126067946.issue7463@psf.upfronthosting.co.za>
New submission from Murray Cumming <murrayc at murrayc.com>:
At least in Python 2.5 and 2.6 (I haven't checked newer versions), the
PyDateTime_IMPORT() macro passes string literals to a function that
takes non-const char* parameters:
#define PyDateTime_IMPORT \
PyDateTimeAPI = (PyDateTime_CAPI*) PyCObject_Import("datetime", \
"datetime_CAPI")
This makes it impossible to build code with warnings as errors, when
using that macro.
----------
components: None
messages: 96166
nosy: murrayc
severity: normal
status: open
title: PyDateTime_IMPORT() causes compiler warnings
type: compile error
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7463>
_______________________________________
From report at bugs.python.org Wed Dec 9 18:27:13 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 09 Dec 2009 17:27:13 +0000
Subject: [New-bugs-announce] [issue7464] circular reference in HTTPResponse
by urllib2
In-Reply-To: <1260379633.84.0.693013946466.issue7464@psf.upfronthosting.co.za>
Message-ID: <1260379633.84.0.693013946466.issue7464@psf.upfronthosting.co.za>
New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:
in urllib2, you will find these lines:
# Wrap the HTTPResponse object in socket's file object adapter
# for Windows. That adapter calls recv(), so delegate recv()
# to read(). This weird wrapping allows the returned object to
# have readline() and readlines() methods.
# XXX It might be better to extract the read buffering code
# out of socket._fileobject() and into a base class.
r.recv = r.read
fp = socket._fileobject(r, close=True)
This, storing a bound method in the instance, will cause a reference
cycle that the user knows nothing about.
I propose creating a wrapper instance with a recv() method instead. Or,
is there a standard way of storing bound methods on instances? A
'weakmethod', perhaps?
----------
components: Library (Lib)
messages: 96175
nosy: krisvale
severity: normal
stage: needs patch
status: open
title: circular reference in HTTPResponse by urllib2
type: resource usage
versions: Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7464>
_______________________________________
From report at bugs.python.org Thu Dec 10 03:20:56 2009
From: report at bugs.python.org (Aaron Altman)
Date: Thu, 10 Dec 2009 02:20:56 +0000
Subject: [New-bugs-announce] [issue7465] Call to another class's constructor
in unittest.TestCase.setUp returns the same instance
In-Reply-To: <1260411656.89.0.306552268984.issue7465@psf.upfronthosting.co.za>
Message-ID: <1260411656.89.0.306552268984.issue7465@psf.upfronthosting.co.za>
New submission from Aaron Altman <aaron at tomorrowsfunction.com>:
Not sure if this is intended behavior. I have a baseClass I'm writing
tests for. My test architecture has an instance of this baseClass
assigned as a member of TestBaseClass(unittest.TestCase) in
TestBaseClass.setUp.
The problem occurs when tests in TestBaseClass modify state within the
member baseClass instance. I think there should be a fresh new instance
of baseClass for every test that gets run, but the old state from the
last test is still there.
Example code and output from Python 2.6.2 attached.
----------
components: Library (Lib), Tests
files: unittest_doesnt_reinstantiate_members.txt
messages: 96189
nosy: awaltman
severity: normal
status: open
title: Call to another class's constructor in unittest.TestCase.setUp returns the same instance
versions: Python 2.6
Added file: http://bugs.python.org/file15514/unittest_doesnt_reinstantiate_members.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7465>
_______________________________________
From report at bugs.python.org Thu Dec 10 03:21:10 2009
From: report at bugs.python.org (David W. Lambert)
Date: Thu, 10 Dec 2009 02:21:10 +0000
Subject: [New-bugs-announce] [issue7466] Segmentation fault after about 20
seconds on lenovo T500
In-Reply-To: <1260411670.47.0.11581679094.issue7466@psf.upfronthosting.co.za>
Message-ID: <1260411670.47.0.11581679094.issue7466@psf.upfronthosting.co.za>
New submission from David W. Lambert <b49P23TIvg at stny.rr.com>:
'''
This brute [possibly a] solution to
http://projecteuler.net/index.php?section=problems&id=159
causes segmentation fault.
$ p3 # an AMD 64 bit build.
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.
>>>
The block between "load_primes" and "print(result)" can be written
as a single statement using various comprehensions. sum(max(...))
The program does not seg-fault this way, but the result was wrong.
I unrolled the code to fix my algorithm, disclosing the segmentation
fault.
'''
import functools
import operator
import itertools
import array
PrimeQ = Primes = 'use load_primes(n) function'
def load_primes(n):
global PrimeQ,Primes
PrimeQ = sieve(1+n)
Primes = array.array('L',(i for (i,Q,) in enumerate(PrimeQ) if Q))
def sieve(n):
a = array.array('b',(True,))*n
a[0] = a[1] = False
for (i,j) in enumerate(a):
if j:
for k in range(i**2,n,i):
a[k] = False
return a
def PrimeRange(a):
'''
see "load_primes"
'''
n = 1+int(a**(1/2))
for p in Primes:
if n < p:
raise StopIteration
yield p
def PrimeFactor(a):
'''
see "load_primes"
>>> load_primes(30)
>>> print([PrimeFactor(x)for x in (6,7,)])
[[2, 3], [7]]
'''
if (a < len(PrimeQ)) and PrimeQ[a]:
return [a]
for p in PrimeRange(a):
(q,r,) = divmod(a,p)
if not r:
return [p]+PrimeFactor(q)
return [a]
def product(a):
return functools.reduce(operator.mul,a,1)
def digital_root(n):
while 9 < n:
n = sum(map(int,str(n)))
return n
def partition(L, chain=itertools.chain):
'''
python recipe by Ray Hettinger
'''
s = L
n = len(s)
first, middle, last = [0], range(1, n), [n]
return [[L[a:b] for (a,b) in zip(chain(first, div), chain(div,
last))]
for i in range(n) for div in itertools.combinations(middle,
i)]
load_primes(1000)
s = 0
for n in range(2,10**6):
factorizations = [
[product(p)for p in group]for group in
partition(PrimeFactor(n))]
mx = 0
for factorization in factorizations:
digital_roots = tuple(map(digital_root,factorization))
sdr = sum(digital_roots)
mx = max(mx,sdr)
s += mx
print('result!',s)
----------
messages: 96190
nosy: LambertDW
severity: normal
status: open
title: Segmentation fault after about 20 seconds on lenovo T500
type: crash
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7466>
_______________________________________
From report at bugs.python.org Thu Dec 10 07:59:31 2009
From: report at bugs.python.org (Douglas Turk)
Date: Thu, 10 Dec 2009 06:59:31 +0000
Subject: [New-bugs-announce] [issue7467] The zipfile module does not check
files' CRCs, including in ZipFile.testzip
In-Reply-To: <1260428371.84.0.68619284631.issue7467@psf.upfronthosting.co.za>
Message-ID: <1260428371.84.0.68619284631.issue7467@psf.upfronthosting.co.za>
New submission from Douglas Turk <douglas.turk at depthanalysis.com>:
The zipfile module does not calculate the CRC of files in a zipfile as
they are read as of Python 2.6. The old ZipFile.read function in Python
2.5 used to do this, and ZipFile.testzip appears to rely on ZipFile.read
to check the CRC. This means that ZipFile.testzip does not check the CRC
as it is documented to.
It would be useful if ZipExtFile could check the CRC once it had read
all the data, because this would mean that e.g. ZipFile.extract would
also automatically check the CRC. Perhaps ZipExtFile.read could raise a
BadZipFile exception if it reaches EOF and the CRC is wrong.
Steps to reproduce:
-Create a zip file, then change a byte in a file's contents (easiest if
files are stored, not deflated).
-Run ZipFile.testzip on the edited file. Note that it does not report a
CRC failure, but other zip tools do.
I can provide a patch in a couple of days if that's useful.
----------
components: Library (Lib)
files: test.zip
messages: 96194
nosy: dougturk
severity: normal
status: open
title: The zipfile module does not check files' CRCs, including in ZipFile.testzip
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15515/test.zip
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7467>
_______________________________________
From report at bugs.python.org Thu Dec 10 12:22:50 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 10 Dec 2009 11:22:50 +0000
Subject: [New-bugs-announce] [issue7468] PyErr_Format documentation doesn't
mention all format codes
In-Reply-To: <1260444170.83.0.494210811062.issue7468@psf.upfronthosting.co.za>
Message-ID: <1260444170.83.0.494210811062.issue7468@psf.upfronthosting.co.za>
New submission from Ronald Oussoren <ronaldoussoren at mac.com>:
I haven't checked the 3.1, 2.7 and 2.6 documentation, but at least for 3.2
the documentation of PyErr_Format lists a very small number of supported
format characters compared to PyUnicode_FromFormat even though
PyErr_Format calls PyUnicode_FromFormatV to do the actual formatting.
----------
assignee: georg.brandl
components: Documentation
messages: 96198
nosy: georg.brandl, ronaldoussoren
severity: normal
status: open
title: PyErr_Format documentation doesn't mention all format codes
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7468>
_______________________________________
From report at bugs.python.org Thu Dec 10 12:55:44 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 10 Dec 2009 11:55:44 +0000
Subject: [New-bugs-announce] [issue7469] Design and History FAQ entry on
Floating Point does not mention short repr.
In-Reply-To: <1260446144.09.0.566145697146.issue7469@psf.upfronthosting.co.za>
Message-ID: <1260446144.09.0.566145697146.issue7469@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
See
http://docs.python.org/dev/faq/design.html#why-are-floating-point-calculations-so-inaccurate.
The 3.1 version is the same, so it also needs to be updated. The entry
links to the tutorial, which has the correct information for 3.1/3.2,
but not for trunk.
----------
keywords: easy
messages: 96200
nosy: eric.smith, mark.dickinson, r.david.murray, rhettinger
priority: low
severity: normal
stage: needs patch
status: open
title: Design and History FAQ entry on Floating Point does not mention short repr.
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7469>
_______________________________________
From report at bugs.python.org Thu Dec 10 14:14:35 2009
From: report at bugs.python.org (Christian Boos)
Date: Thu, 10 Dec 2009 13:14:35 +0000
Subject: [New-bugs-announce] [issue7470] logger.StreamHandler emit encoding
fallback is wrong
In-Reply-To: <1260450875.81.0.20769448713.issue7470@psf.upfronthosting.co.za>
Message-ID: <1260450875.81.0.20769448713.issue7470@psf.upfronthosting.co.za>
New submission from Christian Boos <cboos at neuf.fr>:
For a stream with a "poor" encoding, such as sys.stderr on Windows where
encoding is cp437, the encoding of an unicode message will fail
(expected) and then a fallback encoding to UTF-8 will be done:
(in
http://code.python.org/hg/trunk/file/bd98b2c097fe/Lib/logging/__init__.p
y#l837):
837 except UnicodeError:
838 stream.write(fs % msg.encode("UTF-8"))
However, that fallback won't work, as at this point, fs was already
converted to unicode and is now u'%s\n', so the (msg.encode("UTF-8"))
str will be decoded to unicode again using the default encoding, which
will likely fail with a UnicodeDecodeError if msg contains non-ascii
characters.
The solution would be to keep using fs as "%s\n" in this line.
This is similar to issue6991, but not exactly the same and it only
happens for Python 2.7. Using logging_error.py, I've tested Python 2.3
to Python 2.6 (works) and Python 2.7a1 (fails), current trunk must have
the same issue as 2.7a1. Patch follows.
----------
components: Library (Lib)
files: logging_error.py
messages: 96201
nosy: cboos, vinay.sajip
severity: normal
status: open
title: logger.StreamHandler emit encoding fallback is wrong
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file15518/logging_error.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7470>
_______________________________________
From report at bugs.python.org Thu Dec 10 17:11:25 2009
From: report at bugs.python.org (asnakelover)
Date: Thu, 10 Dec 2009 16:11:25 +0000
Subject: [New-bugs-announce] [issue7471] gzip module too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
New submission from asnakelover <a3277638 at uggsrock.com>:
It's not a big problem because we can just shell to zcat but compare
these two:
$ time python ./b.py >/dev/null
real 0m10.977s
user 0m7.128s
sys 0m0.888s
$ time python ./a.py >/dev/null
real 1m19.015s
user 1m18.185s
sys 0m0.072s
$ # Notice that the gzip module (a.py) had the benefit of the files
being in a disk cache by too now...
$ cat a.py
import gzip
import os
apt_cache_dir = "/var/cache/apt/apt-file"
for apt_cache_file in os.listdir(apt_cache_dir):
if not apt_cache_file.endswith(".gz"):
continue
f = gzip.open(os.path.join(apt_cache_dir, apt_cache_file))
for line in f:
print line
$ cat b.py
import os
import subprocess
from cStringIO import StringIO
apt_cache_dir = "/var/cache/apt/apt-file"
for apt_cache_file in os.listdir(apt_cache_dir):
if not apt_cache_file.endswith(".gz"):
continue
p = subprocess.Popen(["zcat", os.path.join(apt_cache_dir,
apt_cache_file)],
stdout = subprocess.PIPE)
f = StringIO(p.communicate()[0])
assert p.returncode == 0
for line in f:
print line
Also tried this one just for "completeness":
$ cat c.py
import gzip
import os
from cStringIO import StringIO
apt_cache_dir = "/var/cache/apt/apt-file"
for apt_cache_file in os.listdir(apt_cache_dir):
if not apt_cache_file.endswith(".gz"):
continue
f = gzip.open(os.path.join(apt_cache_dir, apt_cache_file))
f = StringIO(f.read())
for line in f:
print line
But after it had ran (with some thrashing) for 3 and a half minutes I
killed it.
----------
components: Library (Lib)
messages: 96204
nosy: asnakelover
severity: normal
status: open
title: gzip module too slow
type: performance
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7471>
_______________________________________
From report at bugs.python.org Thu Dec 10 18:43:02 2009
From: report at bugs.python.org (Yukihiro Nakadaira)
Date: Thu, 10 Dec 2009 17:43:02 +0000
Subject: [New-bugs-announce] [issue7472] email.encoders.encode_7or8bit():
typo "iso-2202". "iso-2022" is correct.
In-Reply-To: <1260466982.74.0.0519719914389.issue7472@psf.upfronthosting.co.za>
Message-ID: <1260466982.74.0.0519719914389.issue7472@psf.upfronthosting.co.za>
New submission from Yukihiro Nakadaira <yukihiro.nakadaira at gmail.com>:
email.encoders.encode_7or8bit(): typo "iso-2202". "iso-2022" is correct.
Index: Lib/email/encoders.py
===================================================================
--- Lib/email/encoders.py (revision 76749)
+++ Lib/email/encoders.py (working copy)
@@ -62,7 +62,7 @@
# iso-2022-* is non-ASCII but still 7-bit
charset = msg.get_charset()
output_cset = charset and charset.output_charset
- if output_cset and output_cset.lower().startswith('iso-2202-'):
+ if output_cset and output_cset.lower().startswith('iso-2022-'):
msg['Content-Transfer-Encoding'] = '7bit'
else:
msg['Content-Transfer-Encoding'] = '8bit'
----------
components: Library (Lib)
messages: 96211
nosy: ynkdir
severity: normal
status: open
title: email.encoders.encode_7or8bit(): typo "iso-2202". "iso-2022" is correct.
type: behavior
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7472>
_______________________________________
From report at bugs.python.org Thu Dec 10 19:43:42 2009
From: report at bugs.python.org (Paul Nelson)
Date: Thu, 10 Dec 2009 18:43:42 +0000
Subject: [New-bugs-announce] [issue7473] x84_64 arch Missing from 2.6.4 Mac
universal binaries - Cripples building embedded 64-bit
In-Reply-To: <1260470622.19.0.0787488117432.issue7473@psf.upfronthosting.co.za>
Message-ID: <1260470622.19.0.0787488117432.issue7473@psf.upfronthosting.co.za>
New submission from Paul Nelson <Paul.Nelson at jmp.com>:
By excluding the x86_64 architecture from the supplied MacOS install,
you are crippling the ability to build an 64-bit application that embeds
python. The Apple supplied universal binary includes all 3 architectures
ppc, i386, and x86_64. If you are going to supply a Mac build you need to
do the same. A 64-bit app has to link against 64-bit libraries, so the
64-bit build IS NECESSARY. You give no warning that you are excluding 1/3
of the architectures from your build. It also forces the unlucky
downloader to circumvent the install, or rebuild from source.
----------
assignee: ronaldoussoren
components: Macintosh
messages: 96213
nosy: prniii, ronaldoussoren
severity: normal
status: open
title: x84_64 arch Missing from 2.6.4 Mac universal binaries - Cripples building embedded 64-bit
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7473>
_______________________________________
From report at bugs.python.org Thu Dec 10 21:33:04 2009
From: report at bugs.python.org (Eric)
Date: Thu, 10 Dec 2009 20:33:04 +0000
Subject: [New-bugs-announce] [issue7474]
multiprocessing.managers.SyncManager managed object creation
fails when started outside of invoked file
In-Reply-To: <1260477184.12.0.729093197155.issue7474@psf.upfronthosting.co.za>
Message-ID: <1260477184.12.0.729093197155.issue7474@psf.upfronthosting.co.za>
New submission from Eric <etzool at hotmail.com>:
I am attempting to create a multiprocessing.SyncManager subclass
instance, register a test class with it, start the manager, and
instantiate the test class. The example I'm providing here is basically
equivalent, and illustrates the same problem (example code is at the
bottom of this message).
This works without issue as long as the manager is started in the file
you actually invoke from the command line. Handled in exactly the same
way, however, with the call to the SyncManager instance's start method
made in an included file, attempting to instantiate anything, including
built-in list() and dict() objects, via the manager causes script to
hang indefinitely.
Output on ctrl+c breaking seems to indicate the call may be hanging in
the challenge process.
Invocation and output (starting/started are wrapped around the start()
call; creating/created are wrapped around the manager's registered
object instantiation):
$ python test.py
starting...
...started
creating...
^CTraceback (most recent call last):
File "test.py", line 6, in <module>
obj = test_manager.TC()
File "/usr/lib64/python2.6/multiprocessing/managers.py", line 634, in temp
token, exp = self._create(typeid, *args, **kwds)
File "/usr/lib64/python2.6/multiprocessing/managers.py", line 532, in
_create
conn = self._Client(self._address, authkey=self._authkey)
File "/usr/lib64/python2.6/multiprocessing/connection.py", line 140,
in Client
answer_challenge(c, authkey)
File "/usr/lib64/python2.6/multiprocessing/connection.py", line 372,
in answer_challenge
message = connection.recv_bytes(256) # reject large message
KeyboardInterrupt
test.py:
from test_inc import test_manager
print "creating..."
obj = test_manager.dict()
print "...created"
test_inc.py:
from multiprocessing.managers import SyncManager
test_manager = SyncManager()
print "starting..."
test_manager.start()
print "...started"
Environment: Linux 2.6.28-gentoo-r5 #4 SMP x86_64 Intel(R) Core(TM)2 Duo
CPU T5470 @ 1.60GHz GenuineIntel GNU/Linux
Version: Python 2.6.4
Apologies if this is my failure to understand how the library (or even
Python) works, but it seems quite odd that this would be expected behavior.
----------
components: Extension Modules
messages: 96215
nosy: etzool
severity: normal
status: open
title: multiprocessing.managers.SyncManager managed object creation fails when started outside of invoked file
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7474>
_______________________________________
From report at bugs.python.org Thu Dec 10 23:27:40 2009
From: report at bugs.python.org (flox)
Date: Thu, 10 Dec 2009 22:27:40 +0000
Subject: [New-bugs-announce] [issue7475] codecs missing: base64 bz2 hex zlib
...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
New submission from flox <laxyf at yahoo.fr>:
AFAIK these codecs were not ported to Python 3.
1. I found no hint in documentation on this matter.
2. Is it possible to contribute some of them, or there's a good reason
to look elsewhere?
----------
components: Library (Lib)
messages: 96218
nosy: flox
severity: normal
status: open
title: codecs missing: base64 bz2 hex zlib ...
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________
From report at bugs.python.org Fri Dec 11 00:19:06 2009
From: report at bugs.python.org (John Wiseman)
Date: Thu, 10 Dec 2009 23:19:06 +0000
Subject: [New-bugs-announce] [issue7476] pipes.quote does not handle
zero-length args correctly
In-Reply-To: <1260487146.66.0.443499521552.issue7476@psf.upfronthosting.co.za>
Message-ID: <1260487146.66.0.443499521552.issue7476@psf.upfronthosting.co.za>
New submission from John Wiseman <jjwiseman at gmail.com>:
In python 2.5.2, I believe pipes.quote gives the wrong result for zero-
length arguments.
>>> from pipes import quote
>>> args = ['arg1', '', 'arg3']
>>> print 'mycommand %s' % (' '.join(quote(arg) for arg in args))
mycommand arg1 arg3
I think the result should be something like
mycommand arg1 '' arg3
----------
components: Library (Lib)
messages: 96225
nosy: jjwiseman
severity: normal
status: open
title: pipes.quote does not handle zero-length args correctly
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7476>
_______________________________________
From report at bugs.python.org Fri Dec 11 13:08:52 2009
From: report at bugs.python.org (Hasan)
Date: Fri, 11 Dec 2009 12:08:52 +0000
Subject: [New-bugs-announce] [issue7477] kqueue timers don't work properly
In-Reply-To: <1260533332.03.0.937259620365.issue7477@psf.upfronthosting.co.za>
Message-ID: <1260533332.03.0.937259620365.issue7477@psf.upfronthosting.co.za>
New submission from Hasan <halayli at gmail.com>:
kqueue timers are not working at all on Mac OSX 10.6.1 (probably not
working on other BSDs as well but haven't tested it).
Here's a simply repro:
from select import *
kq = kqueue()
e = kevent(10000, flags=KQ_EV_ENABLE|KQ_EV_ONESHOT,
filter=KQ_FILTER_TIMER)
e
<select.kevent ident=10000 filter=-7 flags=0x14 fflags=0x0 data=0x0
udata=0x0>
new_e = f.control([e], 1, 0)
This should block 10s before it returns control with new_e having a timer
event returned. However, it isn't the case.
control returns immediately returning a busted event:
[<select.kevent ident=10000 filter=-7 flags=0x4000 fflags=0x0 data=0x2
udata=0x0>]
Am I missing something?
----------
components: Library (Lib)
messages: 96247
nosy: hasan
severity: normal
status: open
title: kqueue timers don't work properly
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7477>
_______________________________________
From report at bugs.python.org Fri Dec 11 13:11:19 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Dec 2009 12:11:19 +0000
Subject: [New-bugs-announce] [issue7478] _sqlite3 doesn't catch
PyDict_SetItem error
In-Reply-To: <1260533479.81.0.324820101165.issue7478@psf.upfronthosting.co.za>
Message-ID: <1260533479.81.0.324820101165.issue7478@psf.upfronthosting.co.za>
New submission from STINNER Victor <victor.stinner at haypocalc.com>:
Methods create_function, create_aggregate, set_authorizer,
set_progress_handler, create_collation of the _sqlite3.Connection class
doesn't catch PyDict_SetItem/PyDict_DelItem errors. The error will be
catched by next opcode/function call.
The error occurs if the callback argument is not hashable.
Attached patch adds the missing tests, and add unit tests.
There is not unit test for Connection.create_collation() because I don't
know how to test it. The call to PyDict_SetItem() is different, because
the callback is not the dictionary key but the value (so it's not a
problem if the callback is not hashable).
----------
components: Extension Modules
messages: 96248
nosy: haypo
severity: normal
status: open
title: _sqlite3 doesn't catch PyDict_SetItem error
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7478>
_______________________________________
From report at bugs.python.org Fri Dec 11 13:33:40 2009
From: report at bugs.python.org (steve)
Date: Fri, 11 Dec 2009 12:33:40 +0000
Subject: [New-bugs-announce] [issue7479] os.lchmod is not present
In-Reply-To: <1260534820.94.0.148252550457.issue7479@psf.upfronthosting.co.za>
Message-ID: <1260534820.94.0.148252550457.issue7479@psf.upfronthosting.co.za>
New submission from steve <eyebootleg at gmail.com>:
Reason for opening this bug:
============================
I am opening a bug because the documentation here:
http://docs.python.org/library/os.html#os.lchmod
Says that in python 2.6 there is a method os.lchmod() for changing the
permissions of unix symbolic links,
I am running Python 2.6 on several flavors of Linux, and non of them
have os.lchmod(). My understanding is that one can not change the
permissions of a sybolic link on Linux because the symlink basically
'inherits' the permissions of the file if points to.
Is this ment to be used on other flavors of UNIX other than Linux?
I am only really familiar with Linux, and have not played with man y
other flavors on UNIX. Can other flavor change the permission of
symbolic links?
What I am Looking for from this bug report:
===========================================
I would like to know what is happening with os.lchmod. If it is not
suppose to be there, I would like it removed from the documentation. If
it is mena for other flavors of unix, but not linux. I think it should
be implemented as just a function that passes.
Let me know what you think.
Peace,
Steve
----------
assignee: georg.brandl
components: Documentation
messages: 96249
nosy: bluegeek, georg.brandl
severity: normal
status: open
title: os.lchmod is not present
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7479>
_______________________________________
From report at bugs.python.org Fri Dec 11 19:09:00 2009
From: report at bugs.python.org (David W. Lambert)
Date: Fri, 11 Dec 2009 18:09:00 +0000
Subject: [New-bugs-announce] [issue7480] trite documentation issue.
In-Reply-To: <1260554940.07.0.376480280758.issue7480@psf.upfronthosting.co.za>
Message-ID: <1260554940.07.0.376480280758.issue7480@psf.upfronthosting.co.za>
New submission from David W. Lambert <b49P23TIvg at stny.rr.com>:
http://docs.python.org/dev/py3k/library/stdtypes.html#index-559
Proposal: remove last sentence from
"class.__bases__
The tuple of base classes of a class object. If there are no base
classes, this will be an empty tuple."
Reason: Sentence is a python 2 relic. The only case is this---
>>> object.__bases__
()
Point being that documentation should be clear, puzzles left as a
comprehension test.
----------
assignee: georg.brandl
components: Documentation
messages: 96269
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: trite documentation issue.
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7480>
_______________________________________
From report at bugs.python.org Fri Dec 11 20:15:40 2009
From: report at bugs.python.org (John Mark Schofield)
Date: Fri, 11 Dec 2009 19:15:40 +0000
Subject: [New-bugs-announce] [issue7481] Failing to start a thread leaves
"zombie" thread in "initial" state
In-Reply-To: <1260558940.42.0.95708502928.issue7481@psf.upfronthosting.co.za>
Message-ID: <1260558940.42.0.95708502928.issue7481@psf.upfronthosting.co.za>
New submission from John Mark Schofield <jschofield at gmail.com>:
SUMMARY: When you attempt to start a thread, and you're unable to (you
get thread.error) it leaves a thread stuck in an "initial" state that
never exits. (threading.enumerate() shows the threads and lists their
status as "initial.")
REPRODUCTION STEPS: See attached file.
EXPECTED RESULT: Failing to start a thread should not leave the thread
in an un-executable state. I would expect the thread start to either
succeed or result in the thread being closed and GC'd.
VERIFIED ON:
Python 2.5.2 on OS X 10.5.8
Python 2.5.2 on Ubuntu 8.04
Python 2.5.4 on Windows XP Professional (Version 2002) SP3
Python 2.6.1 on OS X 10.6.2
----------
files: repro_case.py
messages: 96271
nosy: schof
severity: normal
status: open
title: Failing to start a thread leaves "zombie" thread in "initial" state
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file15527/repro_case.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7481>
_______________________________________
From report at bugs.python.org Fri Dec 11 23:17:28 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 11 Dec 2009 22:17:28 +0000
Subject: [New-bugs-announce] [issue7482] Improve ZeroDivisionError message
for float and complex object
In-Reply-To: <1260569848.94.0.64759795971.issue7482@psf.upfronthosting.co.za>
Message-ID: <1260569848.94.0.64759795971.issue7482@psf.upfronthosting.co.za>
New submission from Ezio Melotti <ezio.melotti at gmail.com>:
The current error messages for divisions by 0 of float and complex
object say "float/complex division", whereas for int and long is
"integer/long division by zero":
>>> 5/0
ZeroDivisionError: integer division or modulo by zero
>>> 5.0/0
ZeroDivisionError: float division
The attached patch adds "by zero" to the error messages of float and
complex in case of division, modulo or divmod by zero.
(Should I add tests to check the error message too?)
----------
assignee: ezio.melotti
components: Interpreter Core
files: issue7482.patch
keywords: needs review, patch, patch
messages: 96275
nosy: ezio.melotti, mark.dickinson
priority: normal
severity: normal
stage: patch review
status: open
title: Improve ZeroDivisionError message for float and complex object
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15528/issue7482.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7482>
_______________________________________
From report at bugs.python.org Sat Dec 12 04:49:37 2009
From: report at bugs.python.org (Jeong-Min Lee)
Date: Sat, 12 Dec 2009 03:49:37 +0000
Subject: [New-bugs-announce] [issue7483] str.format behaviour changed from
Python 2.6
In-Reply-To: <1260589777.59.0.256814428179.issue7483@psf.upfronthosting.co.za>
Message-ID: <1260589777.59.0.256814428179.issue7483@psf.upfronthosting.co.za>
New submission from Jeong-Min Lee <falsetru at gmail.com>:
In Python 2.6,
>>> '{0:0<30}'.format(1)
'100000000000000000000000000000'
>>> '{0:-<30}'.format(1)
'1-----------------------------'
In Python 2.7a / 3.1,
>>> '{0:0<30}'.format(1)
'000000000000000000000000000001'
>>> '{0:-<30}'.format(1)
'1-----------------------------'
----------
components: Interpreter Core
messages: 96282
nosy: falsetru
severity: normal
status: open
title: str.format behaviour changed from Python 2.6
type: behavior
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7483>
_______________________________________
From report at bugs.python.org Sat Dec 12 07:55:56 2009
From: report at bugs.python.org (=?utf-8?q?Manuel_P=C3=A9gouri=C3=A9-Gonnard?=)
Date: Sat, 12 Dec 2009 06:55:56 +0000
Subject: [New-bugs-announce] [issue7484] smtplib: verify breaks with Postfix
servers
In-Reply-To: <1260600956.23.0.0101749869854.issue7484@psf.upfronthosting.co.za>
Message-ID: <1260600956.23.0.0101749869854.issue7484@psf.upfronthosting.co.za>
New submission from Manuel P?gouri?-Gonnard <mpg at elzevir.fr>:
Hi,
The verify method of SMTP objects created with smtplib doesn't work
properly with servers running Postfix, due to quoting problems: the
address is enclosed in pointed brackets by the method, which changes the
way it is interpreted by the server.
The attached demo file uses the mx1.nic.fr server, which runs Postfix
and exhibits the problem at the time of the writing.
RFC 5321 says the argument of VRFY is a string representing a "user
name", without saying much about what a "user name" is, but nothing
suggests it should be quoted in pointed brackets. Moreover, the example
in D.4 doens't use any quoting.
Anyway, even if Postfix was wrong, I think it would be worth trying to
support it, since it is quite widely used.
Thanks!
----------
components: Library (Lib)
files: bsl.py
messages: 96284
nosy: mpg
severity: normal
status: open
title: smtplib: verify breaks with Postfix servers
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file15530/bsl.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7484>
_______________________________________
From report at bugs.python.org Sat Dec 12 13:16:37 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 12 Dec 2009 12:16:37 +0000
Subject: [New-bugs-announce] [issue7485] Error in FAQ entry '4.25 Why
doesn't Python have a "with" statement for attribute assignments?'
In-Reply-To: <1260620197.76.0.962971657783.issue7485@psf.upfronthosting.co.za>
Message-ID: <1260620197.76.0.962971657783.issue7485@psf.upfronthosting.co.za>
New submission from Eric Smith <eric at trueblade.com>:
The documentation says: "If the referenced object does not have a, b and
c attributes, of course, the end result is still a run-time exception."
For the given example, this is likely not true. Since the attributes are
being assigned to, they will be created. The example is equivalent to:
>>> class a(object): pass
...
>>> ref = a()
>>> ref.a = 21
>>> ref.b = 42
>>> ref.c = 63
----------
assignee: georg.brandl
components: Documentation
messages: 96291
nosy: eric.smith, georg.brandl
severity: normal
status: open
title: Error in FAQ entry '4.25 Why doesn't Python have a "with" statement for attribute assignments?'
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7485>
_______________________________________
From report at bugs.python.org Sat Dec 12 16:22:49 2009
From: report at bugs.python.org (flox)
Date: Sat, 12 Dec 2009 15:22:49 +0000
Subject: [New-bugs-announce] [issue7486] doc: Built-in Functions,
exec statement is obsolete
In-Reply-To: <1260631369.85.0.334138201017.issue7486@psf.upfronthosting.co.za>
Message-ID: <1260631369.85.0.334138201017.issue7486@psf.upfronthosting.co.za>
New submission from flox <laxyf at yahoo.fr>:
In the documentation of "compile(...)", there's a mention of the "exec
statement".
----------
assignee: georg.brandl
components: Documentation
messages: 96293
nosy: flox, georg.brandl
severity: normal
status: open
title: doc: Built-in Functions, exec statement is obsolete
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7486>
_______________________________________
From report at bugs.python.org Sat Dec 12 21:43:38 2009
From: report at bugs.python.org (flox)
Date: Sat, 12 Dec 2009 20:43:38 +0000
Subject: [New-bugs-announce] [issue7487] doc: Code is not always colored
In-Reply-To: <1260650618.54.0.0150574477038.issue7487@psf.upfronthosting.co.za>
Message-ID: <1260650618.54.0.0150574477038.issue7487@psf.upfronthosting.co.za>
New submission from flox <laxyf at yahoo.fr>:
Some code samples are not syntax colored in the doc for Python 3.
In the documentation for Python 2, it is OK.
Example:
http://docs.python.org/dev/py3k/library/stdtypes.html#methods
http://docs.python.org/dev/library/stdtypes.html#methods
----------
assignee: georg.brandl
components: Documentation
messages: 96306
nosy: flox, georg.brandl
severity: normal
status: open
title: doc: Code is not always colored
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7487>
_______________________________________
From report at bugs.python.org Sun Dec 13 05:10:49 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sun, 13 Dec 2009 04:10:49 +0000
Subject: [New-bugs-announce] [issue7488] Mac/README continues to refer to
2.6, not 3
In-Reply-To: <1260677449.44.0.892649378192.issue7488@psf.upfronthosting.co.za>
Message-ID: <1260677449.44.0.892649378192.issue7488@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
The file Mac/README in the Subversion source continues to refer to 2.6,
not the appropriate version of 3.
----------
components: Build
messages: 96316
nosy: MLModel
severity: normal
status: open
title: Mac/README continues to refer to 2.6, not 3
versions: Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7488>
_______________________________________
From report at bugs.python.org Sun Dec 13 05:18:53 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sun, 13 Dec 2009 04:18:53 +0000
Subject: [New-bugs-announce] [issue7489] OS X binary installer for 3.1.1
missing from http://www.python.org/download/
In-Reply-To: <1260677933.36.0.449137371401.issue7489@psf.upfronthosting.co.za>
Message-ID: <1260677933.36.0.449137371401.issue7489@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
Is there some reason the OS X installer is missing from
http://www.python.org/download/ but present on
http://www.python.org/download/releases/3.1.1/? Seems it should be in
both places.
----------
components: None
messages: 96317
nosy: MLModel
severity: normal
status: open
title: OS X binary installer for 3.1.1 missing from http://www.python.org/download/
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7489>
_______________________________________
From report at bugs.python.org Sun Dec 13 12:11:42 2009
From: report at bugs.python.org (Lennart Regebro)
Date: Sun, 13 Dec 2009 11:11:42 +0000
Subject: [New-bugs-announce] [issue7490] IGNORE_EXCEPTION_DETAIL should
ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
New submission from Lennart Regebro <regebro at gmail.com>:
In Python 3.x [1] the exception formatting prints the module path, while
under 2.x it prints only the exception class name. This makes it very
tricky to make doctests that pass under both Python 2 and Python 3
without resorting to ugly tricks.
Since IGNORE_EXCEPTION_DETAIL was implemented to hide differences
between exception messages in 2.3 and 2.4, it was suggested on
python-dev [2] that IGNORE_EXCEPTION_DETAIL should be extended to also
ignore the module name, so that `module.name.ExceptionClass` and
`ExceptionClass` would match each other. This is easily done by just
changing the regexp that is done for matching.
I'll attach diffs both for trunk and for py3k-branch, so that both forms
can be used on both versions. The diffs include tests and suggested
documentation changes (although I reserve the right to be useless at
writing documentation).
[1] And possibly in some cases under Python 2.7 according to reports in
the thread on python-dev about this issue, although I haven't been able
to confirm this. I'll include a 2.7 diff anyway, as it would be good if
both syntaxes work under both versions, if people start using 3to2, for
example.
[2] http://mail.python.org/pipermail/python-dev/2009-December/094460.html
----------
components: Tests
files: python-py3k-exception-detail.diff
keywords: patch
messages: 96329
nosy: lregebro
severity: normal
status: open
title: IGNORE_EXCEPTION_DETAIL should ignore the module name
type: behavior
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file15537/python-py3k-exception-detail.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________
From report at bugs.python.org Sun Dec 13 16:58:47 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sun, 13 Dec 2009 15:58:47 +0000
Subject: [New-bugs-announce] [issue7491] metaclass __cmp__ is ignored
In-Reply-To: <1260719927.85.0.160252441292.issue7491@psf.upfronthosting.co.za>
Message-ID: <1260719927.85.0.160252441292.issue7491@psf.upfronthosting.co.za>
New submission from Jean-Paul Calderone <exarkun at divmod.com>:
Here's an example of a metaclass with a __cmp__ special:
exarkun at boson:/tmp$ cat metacmp.py
class X(type):
def __cmp__(self, other):
return -1
class Y:
__metaclass__ = X
print Y < Y
exarkun at boson:/tmp$ python2.5 metacmp.py
True
exarkun at boson:/tmp$ python2.6 metacmp.py
False
exarkun at boson:/tmp$
In Python 2.6 and Python 2.7a1, the __cmp__ isn't even invoked, as it
was in Python 2.5.
This breaks the ordering of item types in Axiom. A brief search reveals
that sympy also ran into the problem, but they may have since worked
around it.
----------
components: Interpreter Core
messages: 96334
nosy: exarkun
severity: normal
status: open
title: metaclass __cmp__ is ignored
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7491>
_______________________________________
From report at bugs.python.org Sun Dec 13 19:07:53 2009
From: report at bugs.python.org (flox)
Date: Sun, 13 Dec 2009 18:07:53 +0000
Subject: [New-bugs-announce] [issue7492] doc: cPickle is really gone
In-Reply-To: <1260727673.98.0.893225016776.issue7492@psf.upfronthosting.co.za>
Message-ID: <1260727673.98.0.893225016776.issue7492@psf.upfronthosting.co.za>
New submission from flox <laxyf at yahoo.fr>:
Word "cPickle" is still used on these pages.
http://docs.python.org/dev/py3k/library/shelve.html
http://docs.python.org/dev/py3k/library/copyreg.html
----------
assignee: georg.brandl
components: Documentation
messages: 96342
nosy: flox, georg.brandl
severity: normal
status: open
title: doc: cPickle is really gone
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7492>
_______________________________________
From report at bugs.python.org Sun Dec 13 20:05:19 2009
From: report at bugs.python.org (flox)
Date: Sun, 13 Dec 2009 19:05:19 +0000
Subject: [New-bugs-announce] [issue7493] doc: patch for
py3k/Doc/faq/design.rst
In-Reply-To: <1260731119.97.0.226497507074.issue7493@psf.upfronthosting.co.za>
Message-ID: <1260731119.97.0.226497507074.issue7493@psf.upfronthosting.co.za>
New submission from flox <laxyf at yahoo.fr>:
I reviewed the documentation and tested the examples with Python 3.
I found many parts which are changed or irrelevant.
Here is the patch.
----------
assignee: georg.brandl
components: Documentation
files: py3k_doc_faq_design.diff
keywords: patch
messages: 96345
nosy: flox, georg.brandl
severity: normal
status: open
title: doc: patch for py3k/Doc/faq/design.rst
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15542/py3k_doc_faq_design.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7493>
_______________________________________
From report at bugs.python.org Sun Dec 13 20:05:42 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 13 Dec 2009 19:05:42 +0000
Subject: [New-bugs-announce] [issue7494] _lsprof (cProfile):
Profiler.clear() keeps references to detroyed nodes
In-Reply-To: <1260731142.01.0.0589092375643.issue7494@psf.upfronthosting.co.za>
Message-ID: <1260731142.01.0.0589092375643.issue7494@psf.upfronthosting.co.za>
New submission from STINNER Victor <victor.stinner at haypocalc.com>:
clearEntries() delete all nodes of the profiler tree, but
currentProfilerContext keeps a reference to a tree node
(currentProfilerContext->previous->header attribute).
The patch fixes clearEntries() to delete all references (destroy
currentProfilerContext and set it to NULL).
----------
components: Extension Modules
files: _lsprof.patch
keywords: patch
messages: 96346
nosy: haypo
severity: normal
status: open
title: _lsprof (cProfile): Profiler.clear() keeps references to detroyed nodes
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file15543/_lsprof.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7494>
_______________________________________
From report at bugs.python.org Sun Dec 13 20:18:27 2009
From: report at bugs.python.org (flox)
Date: Sun, 13 Dec 2009 19:18:27 +0000
Subject: [New-bugs-announce] [issue7495] doc: patch for
py3k/Doc/faq/programming.rst
In-Reply-To: <1260731907.1.0.727952495517.issue7495@psf.upfronthosting.co.za>
Message-ID: <1260731907.1.0.727952495517.issue7495@psf.upfronthosting.co.za>
New submission from flox <laxyf at yahoo.fr>:
I reviewed the documentation and tested the examples with Python 3.
I found some parts which are changed or irrelevant.
Here is the patch.
The examples for Mandelbrot and Fibonacci work fine.
----------
assignee: georg.brandl
components: Documentation
files: py3k_doc_faq_programming.diff
keywords: patch
messages: 96349
nosy: flox, georg.brandl
severity: normal
status: open
title: doc: patch for py3k/Doc/faq/programming.rst
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15544/py3k_doc_faq_programming.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7495>
_______________________________________
From report at bugs.python.org Sun Dec 13 21:35:47 2009
From: report at bugs.python.org (mohammad)
Date: Sun, 13 Dec 2009 20:35:47 +0000
Subject: [New-bugs-announce] [issue7496] python does not work in command
prompt
In-Reply-To: <1260736547.88.0.745783181187.issue7496@psf.upfronthosting.co.za>
Message-ID: <1260736547.88.0.745783181187.issue7496@psf.upfronthosting.co.za>
New submission from mohammad <mohammad.madani63 at gmail.com>:
when i type python in my command promp this message is shown :
C:\Documents and Settings\X>python
Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: cp720
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
what's the problem ?!
----------
components: Windows
messages: 96351
nosy: memol_jpn
severity: normal
status: open
title: python does not work in command prompt
type: crash
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7496>
_______________________________________
From report at bugs.python.org Sun Dec 13 21:53:15 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 13 Dec 2009 20:53:15 +0000
Subject: [New-bugs-announce] [issue7497] configure test for posix_semaphore
capability leaves semaphore behind,
on linux causing test to fail for other users
In-Reply-To: <1260737595.26.0.117181393119.issue7497@psf.upfronthosting.co.za>
Message-ID: <1260737595.26.0.117181393119.issue7497@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
autoconf tries to open a semaphore (/autoconf) to find out if posix
semaphores are available and working. On linux, a file 'sem.autoconf'
is left behind in /dev/shm, owned by the user running autoconf. If any
other user on the system compiles python, the autoconf tests will fail
to open this file (which is rw to the owner only), and the resulting
python will claim that the system has a broken semaphore implementation.
----------
components: Interpreter Core
keywords: easy
messages: 96352
nosy: mark.dickinson, r.david.murray
priority: high
severity: normal
stage: needs patch
status: open
title: configure test for posix_semaphore capability leaves semaphore behind, on linux causing test to fail for other users
type: compile error
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7497>
_______________________________________
From report at bugs.python.org Sun Dec 13 22:22:15 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 13 Dec 2009 21:22:15 +0000
Subject: [New-bugs-announce] [issue7498] test_multiprocessing
test_rapid_restart fails if port 9999 already in use
In-Reply-To: <1260739335.32.0.700170561891.issue7498@psf.upfronthosting.co.za>
Message-ID: <1260739335.32.0.700170561891.issue7498@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
test_rapid_restart has a hardcoded port. Patch updates it to use
test_support.find_unused_port. Discovered on a buildbot with a hung
test_multiprocessing run and confirmed to fix the subsequent failures of
other test_multiprocessing runs.
----------
components: Tests
files: test_multiprocessing_find_unused_port.patch
keywords: buildbot, patch
messages: 96358
nosy: jnoller, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: test_multiprocessing test_rapid_restart fails if port 9999 already in use
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15545/test_multiprocessing_find_unused_port.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7498>
_______________________________________
From report at bugs.python.org Sun Dec 13 22:41:24 2009
From: report at bugs.python.org (flox)
Date: Sun, 13 Dec 2009 21:41:24 +0000
Subject: [New-bugs-announce] [issue7499] doc: patch for
py3k/Doc/faq/library.rst
In-Reply-To: <1260740484.19.0.91493820793.issue7499@psf.upfronthosting.co.za>
Message-ID: <1260740484.19.0.91493820793.issue7499@psf.upfronthosting.co.za>
New submission from flox <laxyf at yahoo.fr>:
I reviewed the documentation and tested the examples with Python 3.
I found some import and print statements to change.
Here is the patch.
Note: I added a warning for the question "How do I get a single
keypress" (without curses). The solution may not work as expected.
----------
assignee: georg.brandl
components: Documentation
files: py3k_doc_faq_library.diff
keywords: patch
messages: 96359
nosy: flox, georg.brandl
severity: normal
status: open
title: doc: patch for py3k/Doc/faq/library.rst
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15546/py3k_doc_faq_library.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7499>
_______________________________________
From report at bugs.python.org Sun Dec 13 22:52:47 2009
From: report at bugs.python.org (flox)
Date: Sun, 13 Dec 2009 21:52:47 +0000
Subject: [New-bugs-announce] [issue7500] doc: add warnings for FAQ which may
not be accurate
In-Reply-To: <1260741167.1.0.029992508259.issue7500@psf.upfronthosting.co.za>
Message-ID: <1260741167.1.0.029992508259.issue7500@psf.upfronthosting.co.za>
New submission from flox <laxyf at yahoo.fr>:
I reviewed some FAQ documents: issue7493, issue7495 and issue7499
But other documents may be inaccurate.
We may add a warning at the top of these documents, until someone
volunteer to review them.
Patch attached.
----------
assignee: georg.brandl
components: Documentation
files: py3k_doc_faq_warnings.diff
keywords: patch
messages: 96360
nosy: flox, georg.brandl
severity: normal
status: open
title: doc: add warnings for FAQ which may not be accurate
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15547/py3k_doc_faq_warnings.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7500>
_______________________________________
From report at bugs.python.org Sun Dec 13 23:19:52 2009
From: report at bugs.python.org (Robert Collins)
Date: Sun, 13 Dec 2009 22:19:52 +0000
Subject: [New-bugs-announce] [issue7501] python -m unittest
path_to_suite_function errors
In-Reply-To: <1260742792.63.0.561457576654.issue7501@psf.upfronthosting.co.za>
Message-ID: <1260742792.63.0.561457576654.issue7501@psf.upfronthosting.co.za>
New submission from Robert Collins <robertc at robertcollins.net>:
:!python -m unittest foo.test_suite
Traceback (most recent call last):
File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
exec code in run_globals
File "/usr/lib/python2.6/unittest.py", line 875, in <module>
main(module=None)
File "/usr/lib/python2.6/unittest.py", line 816, in __init__
self.parseArgs(argv)
File "/usr/lib/python2.6/unittest.py", line 843, in parseArgs
self.createTests()
File "/usr/lib/python2.6/unittest.py", line 849, in createTests
self.module)
File "/usr/lib/python2.6/unittest.py", line 613, in loadTestsFromNames
suites = [self.loadTestsFromName(name, module) for name in names]
File "/usr/lib/python2.6/unittest.py", line 605, in loadTestsFromName
(obj, test))
TypeError: calling <function test_suite at 0x7f748dd6d7d0> returned
<unittest.TestSuite tests=[<foo.TestTask testMethod=test_can_construct>,
<foo.TestTask testMethod=test_can_construct>]>, not a test
where foo.py:
def test_suite():
loader = unittest.TestLoader()
tests = loader.loadTestsFromName(__name__)
result = loader.suiteClass()
result.addTests(generate_scenarios(tests))
return result
----------
components: Library (Lib)
messages: 96364
nosy: rbcollins
severity: normal
status: open
title: python -m unittest path_to_suite_function errors
type: crash
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/issue7501>
_______________________________________
From report at bugs.python.org Mon Dec 14 03:23:38 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 14 Dec 2009 02:23:38 +0000
Subject: [New-bugs-announce] [issue7502] All DocTestCase instances compare
and hash equal to each other
In-Reply-To: <1260757418.81.0.639344471031.issue7502@psf.upfronthosting.co.za>
Message-ID: <1260757418.81.0.639344471031.issue7502@psf.upfronthosting.co.za>
New submission from Jean-Paul Calderone <exarkun at divmod.com>:
Consider this example, based on two doctests from Twisted:
from doctest import DocTestSuite
import twisted.web2.stream
docTestOne = DocTestSuite(twisted.web2.stream)._tests[0]
import twisted.web2.test.test_stream
docTestTwo = DocTestSuite(twisted.web2.test.test_stream)._tests[0]
print docTestOne.id(), '==', docTestTwo.id(), '?'
print docTestOne == docTestTwo
One might reasonably expect a false result, since the two DocTestCase
instances represent two different doctests. One will meet with
surprise, though.
----------
components: Library (Lib)
messages: 96368
nosy: exarkun
severity: normal
status: open
title: All DocTestCase instances compare and hash equal to each other
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7502>
_______________________________________
From report at bugs.python.org Mon Dec 14 08:53:54 2009
From: report at bugs.python.org (Pete Hunt)
Date: Mon, 14 Dec 2009 07:53:54 +0000
Subject: [New-bugs-announce] [issue7503] multiprocessing AuthenticationError
"digest sent was rejected" when pickling proxy
In-Reply-To: <1260777234.55.0.247151929734.issue7503@psf.upfronthosting.co.za>
Message-ID: <1260777234.55.0.247151929734.issue7503@psf.upfronthosting.co.za>
New submission from Pete Hunt <floydophone at gmail.com>:
When pickling a proxy object (such as a list) created on a client, an
exception is thrown. Example attached.
Python 2.6.4 Mac OS X 10.6
p
----------
components: Library (Lib)
files: multiprocessing_bug.py
messages: 96371
nosy: peterhunt
severity: normal
status: open
title: multiprocessing AuthenticationError "digest sent was rejected" when pickling proxy
versions: Python 2.6
Added file: http://bugs.python.org/file15551/multiprocessing_bug.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7503>
_______________________________________
From report at bugs.python.org Mon Dec 14 14:54:29 2009
From: report at bugs.python.org (Andrey Chichak)
Date: Mon, 14 Dec 2009 13:54:29 +0000
Subject: [New-bugs-announce] [issue7504] Same name cookies
In-Reply-To: <1260798869.28.0.314761148717.issue7504@psf.upfronthosting.co.za>
Message-ID: <1260798869.28.0.314761148717.issue7504@psf.upfronthosting.co.za>
New submission from Andrey Chichak <chch at kit.tomsk.ru>:
After setting cookies with same name and different path only nearest to
root cookie is available.
Attached patch:
1. Set Cookie to nearest value.
2. Collects all same name values in Cookie._multi['<cookie name>'] in
order.
----------
components: Library (Lib)
files: Cookie.py.diff
keywords: patch
messages: 96375
nosy: chch
severity: normal
status: open
title: Same name cookies
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file15554/Cookie.py.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7504>
_______________________________________
From report at bugs.python.org Mon Dec 14 18:10:41 2009
From: report at bugs.python.org (Venkateswaran)
Date: Mon, 14 Dec 2009 17:10:41 +0000
Subject: [New-bugs-announce] [issue7505] ctypes not converting None to Null
in 64-bit system
In-Reply-To: <1260810641.87.0.854694050504.issue7505@psf.upfronthosting.co.za>
Message-ID: <1260810641.87.0.854694050504.issue7505@psf.upfronthosting.co.za>
New submission from Venkateswaran <wenkat.s at gmail.com>:
The attached code is failing to convert None to Null. It is successful
if the int* is shifted towards the beginning of argument list. The bug
is actually in 32/64 bit pointers as the code works on a 32 bit system.
The bug disappears if I reduce the number of arguments to less than 10.
I created the so using the command - "gcc -shared -fPIC -o libtest.so
libtest.c", (gcc (Debian 4.3.2-1.1) 4.3.2)
The c file is as follows:
libtest.c
#include <stdint.h>
#include <stdio.h>
int32_t where ( int32_t a, int32_t c, int32_t d, int32_t e, int32_t f,
int32_t g, int32_t h, int32_t *b, int32_t i, int32_t j, int32_t k,
int32_t l)
{
printf("b = %p\n", (void *)b);
printf("a = %d, c = %d, d = %d, e = %d, f = %d, g = %d, h = %d, i =
%d, j = %d, k = %d, l = %d", a,c,d,e,f,g,h,i,j,k,l);
return 100;
} /* where() */
Python Code:
import ctypes
libtest = ctypes.CDLL('./libtest.so')
where = libtest.where
where.restype = ctypes.c_int
where.argtypes = [
ctypes.c_int32, ctypes.c_int32, ctypes.c_int32,
ctypes.c_int32, ctypes.c_int32, ctypes.c_int32, ctypes.c_int32,
ctypes.POINTER(ctypes.c_int32),
ctypes.c_int32, ctypes.c_int32, ctypes.c_int32,
ctypes.c_int32,
]
a = 7
b = None
status = where(a,a,a,a,a,a,a,b,a,a,a,a)
----------
assignee: theller
components: ctypes
files: test.py
messages: 96385
nosy: theller, wenkat_s
severity: normal
status: open
title: ctypes not converting None to Null in 64-bit system
type: crash
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file15557/test.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7505>
_______________________________________
From report at bugs.python.org Mon Dec 14 19:48:56 2009
From: report at bugs.python.org (Pete Hunt)
Date: Mon, 14 Dec 2009 18:48:56 +0000
Subject: [New-bugs-announce] [issue7506]
multiprocessing.managers.BaseManager.__reduce__ references
BaseManager.from_address
In-Reply-To: <1260816536.82.0.305544247154.issue7506@psf.upfronthosting.co.za>
Message-ID: <1260816536.82.0.305544247154.issue7506@psf.upfronthosting.co.za>
New submission from Pete Hunt <floydophone at gmail.com>:
BaseManager.__reduce__ references from_address, which, to my knowledge,
has been eliminated from the package.
----------
components: Library (Lib)
messages: 96392
nosy: peterhunt
severity: normal
status: open
title: multiprocessing.managers.BaseManager.__reduce__ references BaseManager.from_address
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7506>
_______________________________________
From report at bugs.python.org Mon Dec 14 22:48:30 2009
From: report at bugs.python.org (Ben Gertzfield)
Date: Mon, 14 Dec 2009 21:48:30 +0000
Subject: [New-bugs-announce] [issue7507] pipes.quote does not correctly
escape !
In-Reply-To: <1260827310.19.0.583545445855.issue7507@psf.upfronthosting.co.za>
Message-ID: <1260827310.19.0.583545445855.issue7507@psf.upfronthosting.co.za>
New submission from Ben Gertzfield <bgertzfield at gmail.com>:
The undocumented (but unit tested!) pipes.quote does not correctly
escape '!', which cannot be passed to the shell outside of single-
quotes:
sh-3.2$ python
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.
>>> import pipes
>>> pipes.quote("omgshoes!")
'omgshoes!'
sh-3.2$ echo "omgshoes!"
sh: !": event not found
bash-3.2$ echo "omgshoes!"
bash: !": event not found
zsh-4.3.9% echo "omgshoes!"
dquote>
This needs to be single-quoted for safety:
sh-3.2$ echo 'omgshoes!'
omgshoes!
bash-3.2$ echo 'omgshoes!'
omgshoes!
zsh-4.3.9% echo 'omgshoes!'
omgshoes!
----------
components: Library (Lib)
messages: 96405
nosy: bgertzfield, eric.smith, jjwiseman, tim_one
severity: normal
status: open
title: pipes.quote does not correctly escape !
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7507>
_______________________________________
From report at bugs.python.org Tue Dec 15 05:43:44 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 15 Dec 2009 04:43:44 +0000
Subject: [New-bugs-announce] [issue7508] Update 'file object' doc
In-Reply-To: <1260852224.61.0.450781946067.issue7508@psf.upfronthosting.co.za>
Message-ID: <1260852224.61.0.450781946067.issue7508@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
"5.9. File Objects?
File objects are implemented using C?s stdio package and can be created
with the built-in open() function."
As I understand, the part about stdio is no longer true.
Also, as I understand, there is no longer a class <file> object.
Rather there are various io (or _io) classes returned by open depending
on the args, especially the mode. This should be made clear. Something like
"File objects are created by the built-in open function and others.
There are instances of various classes exposed in the io module. The
following discusses the methods common to various file objects."
Maybe even retitle the section "IO objects" and use 'io' instead of
'file' as the prefix for method names.
Maybe whoever wrote the new io system could check this section for accuracy.
----------
assignee: georg.brandl
components: Documentation
messages: 96419
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Update 'file object' doc
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7508>
_______________________________________
From report at bugs.python.org Tue Dec 15 07:24:49 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 15 Dec 2009 06:24:49 +0000
Subject: [New-bugs-announce] [issue7509] AttributeError: MSVCCompiler
instance has no attribute '_MSVCCompiler__root'
In-Reply-To: <1260858289.28.0.0186938090611.issue7509@psf.upfronthosting.co.za>
Message-ID: <1260858289.28.0.0186938090611.issue7509@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
This error happened while installing pycrypto 2.0.1 on XP 64-bit with VS
2008 express installed using Python 2.6.4 64-bit (via buildout).
Getting distribution for 'pycrypto>=1.9'.
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "build\bdist.win32\egg\setuptools\command\easy_install.py", line
1714, in main
File "build\bdist.win32\egg\setuptools\command\easy_install.py", line
1695, in with_ei_usage
File "build\bdist.win32\egg\setuptools\command\easy_install.py", line
1718, in <lambda>
File "C:\Python25\lib\distutils\core.py", line 151, in setup
dist.run_commands()
File "C:\Python25\lib\distutils\dist.py", line 974, in run_commands
self.run_command(cmd)
File "C:\Python25\lib\distutils\dist.py", line 994, in run_command
cmd_obj.run()
File "build\bdist.win32\egg\setuptools\command\easy_install.py", line
236, in run
File "build\bdist.win32\egg\setuptools\command\easy_install.py", line
452, in easy_install
File "build\bdist.win32\egg\setuptools\command\easy_install.py", line
501, in install_item
File "build\bdist.win32\egg\setuptools\command\easy_install.py", line
680, in install_eggs
File "build\bdist.win32\egg\setuptools\command\easy_install.py", line
957, in build_and_install
File "build\bdist.win32\egg\setuptools\command\easy_install.py", line
946, in run_setup
File "build\bdist.win32\egg\setuptools\sandbox.py", line 29, in
run_setup
File "build\bdist.win32\egg\setuptools\sandbox.py", line 70, in run
File "build\bdist.win32\egg\setuptools\sandbox.py", line 31, in
<lambda>
File "setup.py", line 163, in <module>
File "C:\Python25\lib\distutils\core.py", line 151, in setup
dist.run_commands()
File "C:\Python25\lib\distutils\dist.py", line 974, in run_commands
self.run_command(cmd)
File "C:\Python25\lib\distutils\dist.py", line 994, in run_command
cmd_obj.run()
File "build\bdist.win32\egg\setuptools\command\bdist_egg.py", line
174, in run
File "build\bdist.win32\egg\setuptools\command\bdist_egg.py", line
161, in call_command
File "C:\Python25\lib\distutils\cmd.py", line 333, in run_command
self.distribution.run_command(command)
File "C:\Python25\lib\distutils\dist.py", line 994, in run_command
cmd_obj.run()
File "build\bdist.win32\egg\setuptools\command\install_lib.py", line
20, in run
File "C:\Python25\lib\distutils\command\install_lib.py", line 112, in
build
self.run_command('build_ext')
File "C:\Python25\lib\distutils\cmd.py", line 333, in run_command
self.distribution.run_command(command)
File "C:\Python25\lib\distutils\dist.py", line 994, in run_command
cmd_obj.run()
File "C:\Python25\lib\distutils\command\build_ext.py", line 299, in
run
self.build_extensions()
File "setup.py", line 116, in build_extensions
File "C:\Python25\lib\distutils\command\build_ext.py", line 425, in
build_extensions
self.build_extension(ext)
File "C:\Python25\lib\distutils\command\build_ext.py", line 490, in
build_extension
depends=ext.depends)
File "C:\Python25\lib\distutils\msvccompiler.py", line 354, in compile
if not self.initialized: self.initialize()
File "C:\Python25\lib\distutils\msvccompiler.py", line 264, in
initialize
self.__paths = self.get_msvc_paths("path")
File "C:\Python25\lib\distutils\msvccompiler.py", line 616, in
get_msvc_paths
% (self.__root, self.__version))
AttributeError: MSVCCompiler instance has no attribute
'_MSVCCompiler__root'
An error occured when trying to install pycrypto 2.0.1. Look above this
message for any errors that were output by easy_
install.
While:
Installing python.
Getting distribution for 'pycrypto>=1.9'.
Error: Couldn't install: pycrypto 2.0.1
----------
assignee: tarek
components: Distutils
messages: 96420
nosy: srid, tarek
severity: normal
status: open
title: AttributeError: MSVCCompiler instance has no attribute '_MSVCCompiler__root'
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7509>
_______________________________________
From report at bugs.python.org Tue Dec 15 07:26:49 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 15 Dec 2009 06:26:49 +0000
Subject: [New-bugs-announce] [issue7510] AttributeError: MSVCCompiler
instance has no attribute '_MSVCCompiler__root'
In-Reply-To: <1260858409.37.0.0719386096256.issue7510@psf.upfronthosting.co.za>
Message-ID: <1260858409.37.0.0719386096256.issue7510@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
This error happened while installing pycrypto 2.0.1 on XP 64-bit with VS
2008 express installed using Python 2.5.4 64-bit (via buildout).
See also: http://twistedmatrix.com/trac/ticket/3352
Getting distribution for 'pycrypto>=1.9'.
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "build\bdist.win32\egg\setuptools\command\easy_install.py", line
1714, in main
File "build\bdist.win32\egg\setuptools\command\easy_install.py", line
1695, in with_ei_usage
File "build\bdist.win32\egg\setuptools\command\easy_install.py", line
1718, in <lambda>
File "C:\Python25\lib\distutils\core.py", line 151, in setup
dist.run_commands()
File "C:\Python25\lib\distutils\dist.py", line 974, in run_commands
self.run_command(cmd)
File "C:\Python25\lib\distutils\dist.py", line 994, in run_command
cmd_obj.run()
File "build\bdist.win32\egg\setuptools\command\easy_install.py", line
236, in run
File "build\bdist.win32\egg\setuptools\command\easy_install.py", line
452, in easy_install
File "build\bdist.win32\egg\setuptools\command\easy_install.py", line
501, in install_item
File "build\bdist.win32\egg\setuptools\command\easy_install.py", line
680, in install_eggs
File "build\bdist.win32\egg\setuptools\command\easy_install.py", line
957, in build_and_install
File "build\bdist.win32\egg\setuptools\command\easy_install.py", line
946, in run_setup
File "build\bdist.win32\egg\setuptools\sandbox.py", line 29, in
run_setup
File "build\bdist.win32\egg\setuptools\sandbox.py", line 70, in run
File "build\bdist.win32\egg\setuptools\sandbox.py", line 31, in
<lambda>
File "setup.py", line 163, in <module>
File "C:\Python25\lib\distutils\core.py", line 151, in setup
dist.run_commands()
File "C:\Python25\lib\distutils\dist.py", line 974, in run_commands
self.run_command(cmd)
File "C:\Python25\lib\distutils\dist.py", line 994, in run_command
cmd_obj.run()
File "build\bdist.win32\egg\setuptools\command\bdist_egg.py", line
174, in run
File "build\bdist.win32\egg\setuptools\command\bdist_egg.py", line
161, in call_command
File "C:\Python25\lib\distutils\cmd.py", line 333, in run_command
self.distribution.run_command(command)
File "C:\Python25\lib\distutils\dist.py", line 994, in run_command
cmd_obj.run()
File "build\bdist.win32\egg\setuptools\command\install_lib.py", line
20, in run
File "C:\Python25\lib\distutils\command\install_lib.py", line 112, in
build
self.run_command('build_ext')
File "C:\Python25\lib\distutils\cmd.py", line 333, in run_command
self.distribution.run_command(command)
File "C:\Python25\lib\distutils\dist.py", line 994, in run_command
cmd_obj.run()
File "C:\Python25\lib\distutils\command\build_ext.py", line 299, in
run
self.build_extensions()
File "setup.py", line 116, in build_extensions
File "C:\Python25\lib\distutils\command\build_ext.py", line 425, in
build_extensions
self.build_extension(ext)
File "C:\Python25\lib\distutils\command\build_ext.py", line 490, in
build_extension
depends=ext.depends)
File "C:\Python25\lib\distutils\msvccompiler.py", line 354, in compile
if not self.initialized: self.initialize()
File "C:\Python25\lib\distutils\msvccompiler.py", line 264, in
initialize
self.__paths = self.get_msvc_paths("path")
File "C:\Python25\lib\distutils\msvccompiler.py", line 616, in
get_msvc_paths
% (self.__root, self.__version))
AttributeError: MSVCCompiler instance has no attribute
'_MSVCCompiler__root'
An error occured when trying to install pycrypto 2.0.1. Look above this
message for any errors that were output by easy_
install.
While:
Installing python.
Getting distribution for 'pycrypto>=1.9'.
Error: Couldn't install: pycrypto 2.0.1
----------
assignee: tarek
components: Distutils
messages: 96421
nosy: srid, tarek
severity: normal
status: open
title: AttributeError: MSVCCompiler instance has no attribute '_MSVCCompiler__root'
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7510>
_______________________________________
From report at bugs.python.org Tue Dec 15 07:27:58 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 15 Dec 2009 06:27:58 +0000
Subject: [New-bugs-announce] [issue7511] msvc9compiler.py: ValueError:
[u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
Win XP 64-bit
Python 2.6.4 64-bit
Getting distribution for 'pycrypto>=1.9'.
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py",
line 1714, in main
File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py",
line 1695, in with_ei_usage
File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py",
line 1718, in <lambda>
File "C:\Python26\lib\distutils\core.py", line 152, in setup
dist.run_commands()
File "C:\Python26\lib\distutils\dist.py", line 975, in run_commands
self.run_command(cmd)
File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
cmd_obj.run()
File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py",
line 236, in run
File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py",
line 452, in easy_install
File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py",
line 501, in install_item
File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py",
line 680, in install_eggs
File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py",
line 957, in build_and_install
File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py",
line 946, in run_setup
File "build\bdist.win-amd64\egg\setuptools\sandbox.py", line 29, in
run_setup
File "build\bdist.win-amd64\egg\setuptools\sandbox.py", line 70, in
run
File "build\bdist.win-amd64\egg\setuptools\sandbox.py", line 31, in
<lambda>
File "setup.py", line 163, in <module>
File "C:\Python26\lib\distutils\core.py", line 152, in setup
dist.run_commands()
File "C:\Python26\lib\distutils\dist.py", line 975, in run_commands
self.run_command(cmd)
File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
cmd_obj.run()
File "build\bdist.win-amd64\egg\setuptools\command\bdist_egg.py", line
174, in run
File "build\bdist.win-amd64\egg\setuptools\command\bdist_egg.py", line
161, in call_command
File "C:\Python26\lib\distutils\cmd.py", line 333, in run_command
self.distribution.run_command(command)
File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
cmd_obj.run()
File "build\bdist.win-amd64\egg\setuptools\command\install_lib.py",
line 20, in run
File "C:\Python26\lib\distutils\command\install_lib.py", line 113, in
build
self.run_command('build_ext')
File "C:\Python26\lib\distutils\cmd.py", line 333, in run_command
self.distribution.run_command(command)
File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
cmd_obj.run()
File "C:\Python26\lib\distutils\command\build_ext.py", line 340, in
run
self.build_extensions()
File "setup.py", line 116, in build_extensions
File "C:\Python26\lib\distutils\command\build_ext.py", line 449, in
build_extensions
self.build_extension(ext)
File "C:\Python26\lib\distutils\command\build_ext.py", line 499, in
build_extension
depends=ext.depends)
File "C:\Python26\lib\distutils\msvc9compiler.py", line 448, in
compile
self.initialize()
File "C:\Python26\lib\distutils\msvc9compiler.py", line 358, in
initialize
vc_env = query_vcvarsall(VERSION, plat_spec)
File "C:\Python26\lib\distutils\msvc9compiler.py", line 274, in
query_vcvarsall
raise ValueError(str(list(result.keys())))
ValueError: [u'path']
An error occured when trying to install pycrypto 2.0.1. Look above this
message for any errors that were output by easy_
install.
While:
Installing python.
Getting distribution for 'pycrypto>=1.9'.
Error: Couldn't install: pycrypto 2.0.1
----------
assignee: tarek
components: Distutils
messages: 96422
nosy: srid, tarek
severity: normal
status: open
title: msvc9compiler.py: ValueError: [u'path']
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________
From report at bugs.python.org Tue Dec 15 08:33:13 2009
From: report at bugs.python.org (Kuang-che Wu)
Date: Tue, 15 Dec 2009 07:33:13 +0000
Subject: [New-bugs-announce] [issue7512] shutil.copystat may fail EOPNOTSUPP
In-Reply-To: <1260862393.85.0.15479395745.issue7512@psf.upfronthosting.co.za>
Message-ID: <1260862393.85.0.15479395745.issue7512@psf.upfronthosting.co.za>
New submission from Kuang-che Wu <kcwu at csie.org>:
"flags" is only supported on certain OS. FreeBSD is one of them.
FreeBSD itself support chflags but not all of its file systems do.
On FreeBSD, copystat() will fail on zfs. The exception is OSError and
errno is EOPNOTSUPP. According to manpage chflags(2), the errno means
"The underlying file system does not support file flags"
If the file system doesn't support flags, we should not call
os.chflags() at first or should not raise exception.
In my patch, I just ignore EOPNOTSUPP exception.
----------
components: Library (Lib)
files: copystat.diff
keywords: patch
messages: 96427
nosy: kcwu
severity: normal
status: open
title: shutil.copystat may fail EOPNOTSUPP
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15564/copystat.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7512>
_______________________________________
From report at bugs.python.org Tue Dec 15 13:04:13 2009
From: report at bugs.python.org (ivank)
Date: Tue, 15 Dec 2009 12:04:13 +0000
Subject: [New-bugs-announce] [issue7513] many source files contaminated with
form feed (\f) characters
In-Reply-To: <1260878653.08.0.0862176638007.issue7513@psf.upfronthosting.co.za>
Message-ID: <1260878653.08.0.0862176638007.issue7513@psf.upfronthosting.co.za>
New submission from ivank <ivan at ludios.org>:
In a checkout of Python 2.7 r76831, a large amount of files contain the
form feed character (\f, \x0C, octal \014)
$ grep --binary-files=without-match -P '\f' **/* | sort | uniq
build/scripts-2.7/smtpd.py:
Lib/base64.py:
Lib/email/base64mime.py:
Lib/email/charset.py:
Lib/email/encoders.py:
Lib/email/errors.py:
Lib/email/feedparser.py:
Lib/email/generator.py:
Lib/email/header.py:
Lib/email/__init__.py:
Lib/email/iterators.py:
Lib/email/message.py:
Lib/email/mime/audio.py:
Lib/email/mime/base.py:
Lib/email/mime/image.py:
Lib/email/mime/message.py:
Lib/email/mime/multipart.py:
Lib/email/mime/nonmultipart.py:
Lib/email/mime/text.py:
Lib/email/parser.py:
Lib/email/quoprimime.py:
Lib/email/test/test_email_codecs.py:
Lib/email/test/test_email_codecs_renamed.py:
Lib/email/test/test_email.py:
Lib/email/test/test_email_renamed.py:
Lib/email/test/test_email_torture.py:
Lib/email/utils.py:
Lib/smtpd.py:
Lib/test/test_base64.py:
Lib/test/test_isinstance.py:
Misc/python-mode.el:
Modules/_ctypes/cfield.c:
Modules/_ctypes/_ctypes.c:
Modules/_io/bufferedio.c:
Modules/_io/_iomodule.c:
Modules/puremodule.c:
Modules/_tkinter.c:
Tools/audiopy/audiopy:
Tools/audiopy/README:
Tools/i18n/msgfmt.py:
Tools/i18n/pygettext.py:
Tools/pynche/ChipViewer.py:
Tools/pynche/ColorDB.py:
Tools/pynche/DetailsViewer.py:
Tools/pynche/Main.py:
Tools/pynche/pyColorChooser.py:
Tools/pynche/PyncheWidget.py:
Tools/pynche/README:
Tools/pynche/StripViewer.py:
Tools/pynche/Switchboard.py:
Tools/pynche/TextViewer.py:
Tools/pynche/TypeinViewer.py:
Tools/world/README:
Tools/world/world:
----------
components: None
messages: 96434
nosy: ivank
severity: normal
status: open
title: many source files contaminated with form feed (\f) characters
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7513>
_______________________________________
From report at bugs.python.org Tue Dec 15 16:57:19 2009
From: report at bugs.python.org (flox)
Date: Tue, 15 Dec 2009 15:57:19 +0000
Subject: [New-bugs-announce] [issue7514] doc: documentation for "sys.flags"
is obsolete.
In-Reply-To: <1260892639.52.0.821475780434.issue7514@psf.upfronthosting.co.za>
Message-ID: <1260892639.52.0.821475780434.issue7514@psf.upfronthosting.co.za>
New submission from flox <laxyf at yahoo.fr>:
Patch attached.
----------
assignee: georg.brandl
components: Documentation
files: py3k_doc_sys_flags.diff
keywords: patch
messages: 96441
nosy: flox, georg.brandl
severity: normal
status: open
title: doc: documentation for "sys.flags" is obsolete.
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15565/py3k_doc_sys_flags.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7514>
_______________________________________
From report at bugs.python.org Tue Dec 15 18:01:55 2009
From: report at bugs.python.org (flox)
Date: Tue, 15 Dec 2009 17:01:55 +0000
Subject: [New-bugs-announce] [issue7515] Lib/test/regrtest.py -ulib2to3
yield "Invalid -u option"
In-Reply-To: <1260896515.31.0.944958562968.issue7515@psf.upfronthosting.co.za>
Message-ID: <1260896515.31.0.944958562968.issue7515@psf.upfronthosting.co.za>
New submission from flox <laxyf at yahoo.fr>:
~ $ ./python Lib/test/regrtest.py --help
(...)
lib2to3 - Run the tests for 2to3 (They take a while.)
(...)
~ $ ./python Lib/test/regrtest.py -ulib2to3
Invalid -u/--use option: lib2to3
Use --help for usage
----------
components: Tests
messages: 96448
nosy: flox
severity: normal
status: open
title: Lib/test/regrtest.py -ulib2to3 yield "Invalid -u option"
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7515>
_______________________________________
From report at bugs.python.org Tue Dec 15 18:47:51 2009
From: report at bugs.python.org (flox)
Date: Tue, 15 Dec 2009 17:47:51 +0000
Subject: [New-bugs-announce] [issue7516] Flag "-3" is silently ignored when
running "regrtest.py -j2"
In-Reply-To: <1260899271.72.0.110257290528.issue7516@psf.upfronthosting.co.za>
Message-ID: <1260899271.72.0.110257290528.issue7516@psf.upfronthosting.co.za>
New submission from flox <laxyf at yahoo.fr>:
~ $ ./python -3 Lib/test/regrtest.py -j2 test_py3kwarn
./Lib/encodings/__init__.py:100: DeprecationWarning:
the 'hex' codec has been removed in Python 3.0
level=0)
test_py3kwarn
test_py3kwarn skipped -- test.test_py3kwarn must be run with the -3 flag
1 test skipped:
test_py3kwarn
1 skip unexpected on linux2:
test_py3kwarn
----------
components: Tests
messages: 96452
nosy: flox
severity: normal
status: open
title: Flag "-3" is silently ignored when running "regrtest.py -j2"
type: behavior
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7516>
_______________________________________
From report at bugs.python.org Tue Dec 15 19:56:19 2009
From: report at bugs.python.org (Patrick Stinson)
Date: Tue, 15 Dec 2009 18:56:19 +0000
Subject: [New-bugs-announce] [issue7517] freeze.py not ported to python3
In-Reply-To: <1260903379.83.0.360315644527.issue7517@psf.upfronthosting.co.za>
Message-ID: <1260903379.83.0.360315644527.issue7517@psf.upfronthosting.co.za>
New submission from Patrick Stinson <patrickkidd at gmail.com>:
Tools/Freeze/freeze.py is still producing C code that expects the old-
style module initialization functions, causing link errors.
The simple example in Tools/Freeze/hello.py easily demonstrates this
behavior.
----------
components: Library (Lib)
messages: 96454
nosy: patrickkidd
severity: normal
status: open
title: freeze.py not ported to python3
type: compile error
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7517>
_______________________________________
From report at bugs.python.org Tue Dec 15 20:19:48 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 15 Dec 2009 19:19:48 +0000
Subject: [New-bugs-announce] [issue7518] Some functions in pymath.c should
be moved elsewhere.
In-Reply-To: <1260904788.96.0.184476026521.issue7518@psf.upfronthosting.co.za>
Message-ID: <1260904788.96.0.184476026521.issue7518@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
The Python/pymath.c file currently defines substitutes for some C99 libm
functions (e.g., log1p), for the benefit of platforms that don't implement
those functions.
It's compiled into the main Python executable.
There are (at least) two problems with this approach:
(1) on a platform that doesn't have (for example) log1p, we end up
exporting the symbol _log1p from the main Python executable. At the very
least, this should have a _Py prefix. Moreover, since log1p is only
needed by the math and cmath modules, and not by the Python interpreter
itself, python.exe shouldn't really be exporting it in the first place.
(2) It may not work! As an experiment, I tried adding a new function
expm1_alt to pymath.c, declaring it in Include/pymath.h with PyAPI_FUNC,
and using it in Modules/mathmodule.c; but the function ended up not being
visible to the math module: the math module failed to build, with an
error message:
dlopen(build/lib.macosx-10.4-i386-2.7/math.so, 2): Symbol not found:
_expm1_alt
When I moved the function to a different source file (I picked
Objects/longobject.c, for no particularly good reason) the new function
became visible and the build succeeded.
The reason for the above behaviour appears to be (I'm guessing a little
bit) that on my platform (OS X 10.6), none of the functions from pymath.c
is needed in the main python executable, so when creating python.exe the
linker ignores *all* the symbols from pymath.c. So while libpython2.7.a
exports _expm1_alt, python.exe does not.
I'm not sure what the best way to reorganize this setup is.
----------
components: Build
messages: 96455
nosy: mark.dickinson
severity: normal
status: open
title: Some functions in pymath.c should be moved elsewhere.
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7518>
_______________________________________
From report at bugs.python.org Tue Dec 15 20:29:17 2009
From: report at bugs.python.org (grego87)
Date: Tue, 15 Dec 2009 19:29:17 +0000
Subject: [New-bugs-announce] [issue7519] CompileParser can't read files with
BOM markers
In-Reply-To: <1260905357.88.0.211998340765.issue7519@psf.upfronthosting.co.za>
Message-ID: <1260905357.88.0.211998340765.issue7519@psf.upfronthosting.co.za>
New submission from grego87 <grego87 at gmail.com>:
If config.ini file is encoded with utf-8 with bom markers this code
import ConfigParser
config = ConfigParser.ConfigParser()
config.read("config.ini")
config.sections()
throws:
ConfigParser.MissingSectionHeaderError: File contains no section headers.
file: config.ini, line: 1
'\xef\xbb\xbf[section]\n'
ConfigParser should be able to read such files.
----------
components: Library (Lib), Unicode
files: config.ini
messages: 96457
nosy: grego87
severity: normal
status: open
title: CompileParser can't read files with BOM markers
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15569/config.ini
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7519>
_______________________________________
From report at bugs.python.org Tue Dec 15 22:16:07 2009
From: report at bugs.python.org (=?utf-8?q?C=C3=A9sar_Izurieta?=)
Date: Tue, 15 Dec 2009 21:16:07 +0000
Subject: [New-bugs-announce] [issue7520] Incorrect handling of nested calss
In-Reply-To: <1260911767.95.0.303023073707.issue7520@psf.upfronthosting.co.za>
Message-ID: <1260911767.95.0.303023073707.issue7520@psf.upfronthosting.co.za>
New submission from C?sar Izurieta <cesar at caih.org>:
I was using a function that has a nested urllib.quote. I need to double
quote a value. When running this through the 2to3 tool, the nested call
never got substituted.
Initial: urllib.quote(urllib.quote(s))
2to3 ouput: urllib.parse.quote(urllib.quote(s))
Expected: urllib.parse.quote(urllib.parse.quote(s))
----------
components: 2to3 (2.x to 3.0 conversion tool)
files: doublequote.py
messages: 96465
nosy: cesarizu
severity: normal
status: open
title: Incorrect handling of nested calss
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file15571/doublequote.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7520>
_______________________________________
From report at bugs.python.org Wed Dec 16 01:27:51 2009
From: report at bugs.python.org (John Millikin)
Date: Wed, 16 Dec 2009 00:27:51 +0000
Subject: [New-bugs-announce] [issue7521] PyEval_GetRestricted should be
removed from C API reference
In-Reply-To: <1260923271.26.0.677511613973.issue7521@psf.upfronthosting.co.za>
Message-ID: <1260923271.26.0.677511613973.issue7521@psf.upfronthosting.co.za>
New submission from John Millikin <jmillikin at gmail.com>:
In
<http://docs.python.org/3.1/c-api/reflection.html#PyEval_GetRestricted>,
the PyEval_GetRestricted() procedure does not exist. HISTORY indicates
it was removed during the 3.0 development cycle. It ought to be removed
from the docs as well.
----------
assignee: georg.brandl
components: Documentation
messages: 96471
nosy: georg.brandl, jmillikin
severity: normal
status: open
title: PyEval_GetRestricted should be removed from C API reference
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7521>
_______________________________________
From report at bugs.python.org Wed Dec 16 08:52:42 2009
From: report at bugs.python.org (Leo)
Date: Wed, 16 Dec 2009 07:52:42 +0000
Subject: [New-bugs-announce] [issue7522] random.choice should accept a set
as input
In-Reply-To: <1260949962.37.0.861133458828.issue7522@psf.upfronthosting.co.za>
Message-ID: <1260949962.37.0.861133458828.issue7522@psf.upfronthosting.co.za>
New submission from Leo <dontsendleospam at gmail.com>:
The following code should just work:
import random
random.choice(set(range(5)))
instead the output is TypeError:
TypeError: 'set' object does not support indexing
The algorithm in random.choice requires a sequence, but the semantics of
choice do not, and should not, require a sequence.
The code should be changed to convert the input to a sequence instead.
Cheers,
Leo.
----------
components: Library (Lib)
messages: 96480
nosy: lleeoo
severity: normal
status: open
title: random.choice should accept a set as input
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7522>
_______________________________________
From report at bugs.python.org Wed Dec 16 12:00:39 2009
From: report at bugs.python.org (lekma)
Date: Wed, 16 Dec 2009 11:00:39 +0000
Subject: [New-bugs-announce] [issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC
to socket module
In-Reply-To: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
Message-ID: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
New submission from lekma <lekmalek at gmail.com>:
It would be nice to have those.
See http://udrepper.livejournal.com/20407.html for background.
----------
components: Library (Lib)
messages: 96482
nosy: lekma
severity: normal
status: open
title: add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
type: feature request
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7523>
_______________________________________
From report at bugs.python.org Wed Dec 16 15:26:41 2009
From: report at bugs.python.org (Gnep)
Date: Wed, 16 Dec 2009 14:26:41 +0000
Subject: [New-bugs-announce] [issue7524] Freeze bug with xml.dom
In-Reply-To: <1260973601.45.0.672751383374.issue7524@psf.upfronthosting.co.za>
Message-ID: <1260973601.45.0.672751383374.issue7524@psf.upfronthosting.co.za>
New submission from Gnep <jass.zhao at gmail.com>:
I'm using python 2.4.3 on centos5.3.
A simple py script contains only one line of?
[karen at gnep:~/test]$ cat dom.py
from xml.dom import minidom
Then freeze this script and run the binary:
[karen at gnep:~/test]$ ./dom
Traceback (most recent call last):
File "dom.py", line 1, in ?
from xml.dom import minidom
ImportError: No module named dom
----------
components: Demos and Tools
messages: 96488
nosy: Gnep
severity: normal
status: open
title: Freeze bug with xml.dom
type: compile error
versions: Python 2.4
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7524>
_______________________________________
From report at bugs.python.org Wed Dec 16 16:09:24 2009
From: report at bugs.python.org (xiscu)
Date: Wed, 16 Dec 2009 15:09:24 +0000
Subject: [New-bugs-announce] [issue7525] Yield example doesn't work as is
explained in the documentation
In-Reply-To: <1260976164.25.0.0113295033016.issue7525@psf.upfronthosting.co.za>
Message-ID: <1260976164.25.0.0113295033016.issue7525@psf.upfronthosting.co.za>
New submission from xiscu <xiscu at email.de>:
In the documentation the is:
...
>>>generator.throw(TypeError, "spam")
TypeError('spam',)
>>> generator.close()
Don't forget to clean up when 'close()' is called.
...
I'm getting:
>>>generator.throw(TypeError, "spam")
TypeError('spam',)
>>> generator.close()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: generator ignored GeneratorExit
...
My proposal here is yield_example_1.py
Thanks
----------
assignee: georg.brandl
components: Documentation
files: yield_example_1.py
messages: 96489
nosy: georg.brandl, xiscu
severity: normal
status: open
title: Yield example doesn't work as is explained in the documentation
type: resource usage
versions: Python 2.6
Added file: http://bugs.python.org/file15576/yield_example_1.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7525>
_______________________________________
From report at bugs.python.org Wed Dec 16 17:43:19 2009
From: report at bugs.python.org (kurt)
Date: Wed, 16 Dec 2009 16:43:19 +0000
Subject: [New-bugs-announce] [issue7526] tkinter menubutton underline
behaviour varies between tkinter * and tkinter.ttk *
In-Reply-To: <1260981799.48.0.698138003814.issue7526@psf.upfronthosting.co.za>
Message-ID: <1260981799.48.0.698138003814.issue7526@psf.upfronthosting.co.za>
New submission from kurt <kurt.forrester.fec at gmail.com>:
I am using the Menubutton to provide an accelerator effect via the
underline option.
When I import the basic widget via from tkinter import * the widget
performs as expected (F_ile) is activated on pressing Alt+F and the menu
is presented.
Conversely when using the ttk widget via "from tkinter.ttk import *" the
Alt+F key combination does not activate the Menubutton widget. In
addition to this pressing F10 does not activate the menubar.
This is on Ubuntu Karmic, Python 3.1.1+ (r311:74480, Nov 2 2009,
14:49:22) [GCC 4.4.1] on linux2
By commenting out the import of the Menubutton at the top of the script
you can hopefully see the behaviour I have described. This
ApplicationMenu class is called in another script (self.root.MenuBar =
ApplicationMenu(self.root)).
----------
components: Tkinter
files: __init__.py
messages: 96491
nosy: kurtforrester
severity: normal
status: open
title: tkinter menubutton underline behaviour varies between tkinter * and tkinter.ttk *
versions: Python 3.1
Added file: http://bugs.python.org/file15577/__init__.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7526>
_______________________________________
From report at bugs.python.org Wed Dec 16 20:14:51 2009
From: report at bugs.python.org (Forest Bond)
Date: Wed, 16 Dec 2009 19:14:51 +0000
Subject: [New-bugs-announce] [issue7527] Standard Library documentation
fails to mention that string.Formatter, etc. are new in Python 2.6
In-Reply-To: <1260990891.99.0.271858942367.issue7527@psf.upfronthosting.co.za>
Message-ID: <1260990891.99.0.271858942367.issue7527@psf.upfronthosting.co.za>
New submission from Forest Bond <forest at alittletooquiet.net>:
This page:
http://docs.python.org/library/string.html
... should mention that the Formatter class and any associated functions
are new in Python 2.6.
----------
assignee: georg.brandl
components: Documentation
messages: 96493
nosy: forest_atq, georg.brandl
severity: normal
status: open
title: Standard Library documentation fails to mention that string.Formatter, etc. are new in Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7527>
_______________________________________
From report at bugs.python.org Thu Dec 17 09:35:37 2009
From: report at bugs.python.org (Case Van Horsen)
Date: Thu, 17 Dec 2009 08:35:37 +0000
Subject: [New-bugs-announce] [issue7528] Provide PyLong_AsLongAndOverflow
compatibility to Python 2.x
In-Reply-To: <1261038937.25.0.365277054713.issue7528@psf.upfronthosting.co.za>
Message-ID: <1261038937.25.0.365277054713.issue7528@psf.upfronthosting.co.za>
New submission from Case Van Horsen <casevh at gmail.com>:
When I ported gmpy to Python 3.x, I began to use
PyLong_AsLongAndOverflow frequently. I found the code to slightly faster
and cleaner than using PyLong_AsLong and checking for overflow. I had
several code fragments that looked like:
#if PY_MAJOR_VERSION == 2
if(PyInt_Check(b)) {
temp = PyInt_AS_LONG(b));
Do stuff with temp.
}
#endif
if(PyLong_Check(b)) {
#if PY_MAJOR_VERSION == 3
temp = PyLong_AsLongAndOverflow(b, &overflow);
if(overflow) {
#else
temp = PyLong_AsLong(b);
if(PyErr_Occurred()) {
PyErr_Clear();
#endif
Convert b to an mpz.
} else {
Do stuff with temp.
}
}
I wanted to use the PyLong_AsLongAndOverflow method with Python 2.x so I
extracted the code for PyLong_AsLongAndOverflow, tweeked it to accept
either PyInt or PyLong, and called it PyIntOrLong_AsLongAndOverflow. I
also defined PyIntOrLong_Check.
The same code fragment now looks like:
if(PyIntOrLong_Check(b)) {
temp = PyIntOrLong_AsLongAndOverflow(b, &overflow);
if(overflow) {
Convert b to an mpz.
} else {
Do stuff with temp.
}
}
Is it possible to include a py3intcompat.c file with Python 2.7 that
provides this function (and possibly others) for extension authors to
include with their extension? A previous example is pymemcompat.h which
was made available in the Misc directory.
I'm specifically not in favor of adding it to the Python 2.7 API but
just in providing a file for extension authors to use. I've attached a
initial version that compiles successfully with Python 2.4+.
I'm willing to add additional functions, documentation, etc.
----------
components: Extension Modules
messages: 96505
nosy: casevh
severity: normal
status: open
title: Provide PyLong_AsLongAndOverflow compatibility to Python 2.x
type: feature request
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7528>
_______________________________________
From report at bugs.python.org Thu Dec 17 10:05:03 2009
From: report at bugs.python.org (Chris Withers)
Date: Thu, 17 Dec 2009 09:05:03 +0000
Subject: [New-bugs-announce] [issue7529] StreamHandler does not live in
logging.Handlers
In-Reply-To: <1261040703.92.0.519271037741.issue7529@psf.upfronthosting.co.za>
Message-ID: <1261040703.92.0.519271037741.issue7529@psf.upfronthosting.co.za>
New submission from Chris Withers <chris at simplistix.co.uk>:
http://docs.python.org/library/logging.html#module-logging.handlers
...explains that StreamHandler lives in logging but then the class docs
say logging.handlers.
Georg, if this isn't trivial for you to fix, re-assign it to me and I'll
make the changes when I get a chance :-)
cheers,
Chris
----------
assignee: georg.brandl
components: Documentation
messages: 96508
nosy: cjw296, georg.brandl
severity: normal
status: open
title: StreamHandler does not live in logging.Handlers
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7529>
_______________________________________
From report at bugs.python.org Thu Dec 17 13:40:49 2009
From: report at bugs.python.org (Stefan Schwarzburg)
Date: Thu, 17 Dec 2009 12:40:49 +0000
Subject: [New-bugs-announce] [issue7530] doc of multiprocessing.managers is
wrong (server_forever)
In-Reply-To: <1261053649.05.0.856911963743.issue7530@psf.upfronthosting.co.za>
Message-ID: <1261053649.05.0.856911963743.issue7530@psf.upfronthosting.co.za>
New submission from Stefan Schwarzburg <stefan.schwarzburg at googlemail.com>:
The documentation of multiprocessing.managers.BaseManager
(http://docs.python.org/library/multiprocessing.html#module-multiprocessing.managers)
refers to a method "serve_forever". This method is only available at the
server object inside BaseManager (e.g.
manager.get_server().serve_forever() ).
I would rephrase the text to:
"Once created one should call start() or get_server().serve_forever()"
instead of the current phrase:
"Once created one should call start() or serve_forever()"
The method description for "serve_forever()" should be removed from
BaseManager, instead there should be an additional section about the
server object returned by get_server().
----------
assignee: georg.brandl
components: Documentation
messages: 96512
nosy: georg.brandl, schwarz
severity: normal
status: open
title: doc of multiprocessing.managers is wrong (server_forever)
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7530>
_______________________________________
From report at bugs.python.org Thu Dec 17 15:32:21 2009
From: report at bugs.python.org (John Gardner)
Date: Thu, 17 Dec 2009 14:32:21 +0000
Subject: [New-bugs-announce] [issue7531] datetime.timedelta doc has
incorrect output
In-Reply-To: <1261060341.46.0.00177327866162.issue7531@psf.upfronthosting.co.za>
Message-ID: <1261060341.46.0.00177327866162.issue7531@psf.upfronthosting.co.za>
New submission from John Gardner <python.20.huxoll at spamgourmet.com>:
The output example for timedelta in datetime package has the wrong
output for the supplied commands.
For example:
>>> ten_years, ten_years.days // 365
(datetime.timedelta(3650), 10)
should be:
>>> ten_years, ten_years.days
(datetime.timedelta(3650), 3650)
(or perhaps, days changed to years.
It's very misleading to have these strange numbers as output.
Also, the comments to the right don't seem to be relevant.
----------
assignee: georg.brandl
components: Documentation
messages: 96514
nosy: georg.brandl, huxoll
severity: normal
status: open
title: datetime.timedelta doc has incorrect output
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/issue7531>
_______________________________________
From report at bugs.python.org Thu Dec 17 17:54:09 2009
From: report at bugs.python.org (flox)
Date: Thu, 17 Dec 2009 16:54:09 +0000
Subject: [New-bugs-announce] [issue7532] Extended slicing with classic class
behaves strangely
In-Reply-To: <1261068849.95.0.141869907153.issue7532@psf.upfronthosting.co.za>
Message-ID: <1261068849.95.0.141869907153.issue7532@psf.upfronthosting.co.za>
New submission from flox <laxyf at yahoo.fr>:
See attached example.
The Classic class should behave like the New-style class.
----------
components: Interpreter Core
files: case_slice.py
messages: 96520
nosy: flox
severity: normal
status: open
title: Extended slicing with classic class behaves strangely
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15582/case_slice.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7532>
_______________________________________
From report at bugs.python.org Thu Dec 17 18:15:52 2009
From: report at bugs.python.org (iamraprap)
Date: Thu, 17 Dec 2009 17:15:52 +0000
Subject: [New-bugs-announce] [issue7533] unable to install pycurl in 2.6.4
In-Reply-To: <1261070152.74.0.648717964415.issue7533@psf.upfronthosting.co.za>
Message-ID: <1261070152.74.0.648717964415.issue7533@psf.upfronthosting.co.za>
New submission from iamraprap <rapsys_eacit at yahoo.com>:
first i tried using easy_install pycurl, also set a path to CURL_DIR and
i had error:
File "setup.py", line 69, in <module>
assert os.path.isdir(CURL_DIR), "please check CURL_DIR in setup.py"
AssertionError: please check CURL_DIR in setup.py
second attempt, downloaded the 7.19.7 pycurl and built the libcurl.lib
too... but upon installing, i had error again:
[C:\src\build\pycurl\7.19.7]setup.py install
Using curl directory: C:\src\build\pycurl\7.19.7
running install
running build
running build_py
running build_ext
building 'pycurl' extension
error: Unable to find vcvarsall.bat
please help... :(
----------
components: Build
messages: 96521
nosy: iamraprap
severity: normal
status: open
title: unable to install pycurl in 2.6.4
type: compile error
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7533>
_______________________________________
From report at bugs.python.org Thu Dec 17 19:42:56 2009
From: report at bugs.python.org (Marcos Donolo)
Date: Thu, 17 Dec 2009 18:42:56 +0000
Subject: [New-bugs-announce] [issue7534] float('nan')**2 != nan.
float('nan')**2 error 33 on windows
In-Reply-To: <1261075376.97.0.838897228999.issue7534@psf.upfronthosting.co.za>
Message-ID: <1261075376.97.0.838897228999.issue7534@psf.upfronthosting.co.za>
New submission from Marcos Donolo <mdonolo at vt.edu>:
I am not getting the expected result for the ** operator on windows,
python 2.6
I do...
a=float('nan')
b=a*a
then b is nan which is right but if I do
b = a**2 I get.
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: (33, 'Domain error')
If I do a**2 on ubuntu, python 2.6 I get nan again.
----------
components: Interpreter Core
messages: 96523
nosy: mdonolo at vt.edu, tim_one
severity: normal
status: open
title: float('nan')**2 != nan. float('nan')**2 error 33 on windows
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7534>
_______________________________________
From report at bugs.python.org Thu Dec 17 19:52:15 2009
From: report at bugs.python.org (Leonardo Rochael Almeida)
Date: Thu, 17 Dec 2009 18:52:15 +0000
Subject: [New-bugs-announce] [issue7535] logging: Filters on Loggers can't
actually filter messages on lower levels of the logging hierarchy
In-Reply-To: <1261075935.27.0.779288069051.issue7535@psf.upfronthosting.co.za>
Message-ID: <1261075935.27.0.779288069051.issue7535@psf.upfronthosting.co.za>
New submission from Leonardo Rochael Almeida <leorochael at gmail.com>:
A filter added to, say, logging.getLogger('a').addFilter() never gets
the chance to filter messages logged into logging.getLogger('a.b').
On logging.Logger.handle() the current logger filters are called to
check if the message should be processed or not, but the logger parent
filters are not consulted (and this is ok, IMHO, more generic filters
shouldn't clobber messages of more specific loggers).
However, if none of the current filters block the message,
Logger.handle() then calls Logger.callHandlers(), which calls the
handlers of the current logger and of all the parent loggers as long as
each logger in the hierarchy allows the message to propagate. This is
done without consulting the parent loggers filters.
This means parent handlers get called to process log records even if the
parent logger filters would have otherwise blocked them.
Attached is a very crude patch that allows the parent loggers to filter
events before handling them. I'd prefer to simply call the "handle()"
or "callHandler()" method of the parent loggers recursively, but
couldn't find a way to do this while still preserving the method
signatures AND properly reporting when no handler could be found.
My preference would be to have callHandlers() do the filtering AND
return a number of handlers invoked, including the parent handlers, so
that handle() could report if no handlers could be found.
----------
components: Library (Lib)
files: logging-allow-parent-filtering.diff
keywords: patch
messages: 96524
nosy: leorochael
severity: normal
status: open
title: logging: Filters on Loggers can't actually filter messages on lower levels of the logging hierarchy
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15583/logging-allow-parent-filtering.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7535>
_______________________________________
From report at bugs.python.org Thu Dec 17 20:27:47 2009
From: report at bugs.python.org (Marcos Donolo)
Date: Thu, 17 Dec 2009 19:27:47 +0000
Subject: [New-bugs-announce] [issue7536] float('inf')**2 != inf
In-Reply-To: <1261078067.84.0.65935543936.issue7536@psf.upfronthosting.co.za>
Message-ID: <1261078067.84.0.65935543936.issue7536@psf.upfronthosting.co.za>
New submission from Marcos Donolo <mdonolo at vt.edu>:
The ** operator produces an error when it gets inf as an argument.
if I try.
>>>a=float('inf')
>>>a*a
inf
-but if I try
>>>a**2
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OverflowError: (34, 'Result too large')
I should get inf too.
----------
components: Interpreter Core
messages: 96527
nosy: mdonolo, tim_one
severity: normal
status: open
title: float('inf')**2 != inf
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7536>
_______________________________________
From report at bugs.python.org Fri Dec 18 04:42:15 2009
From: report at bugs.python.org (James G. sack (jim))
Date: Fri, 18 Dec 2009 03:42:15 +0000
Subject: [New-bugs-announce] [issue7537] test_format
In-Reply-To: <1261107735.71.0.830554169199.issue7537@psf.upfronthosting.co.za>
Message-ID: <1261107735.71.0.830554169199.issue7537@psf.upfronthosting.co.za>
New submission from James G. sack (jim) <jgsack at users.sourceforge.net>:
With -r 76870, on Fedora 11, amd x80_64, regrtest of test_format fails
when the -j option is combined with the -v option. It happens whether
testing everything or just the one test.
./python -Ebb Lib/test/regrtest -j3 -vv
or
./python -Ebb Lib/test/regrtest -j3 -vv test_format
The error report is like
"""
FAILED (errors=1)
test test_format failed -- Traceback (most recent call last):
File "/home/jbase/checkouts/py/py32/Lib/test/test_format.py", line
221, in test_format
testformat("%r", "\u0374", "'\u0374'") # printable
File "/home/jbase/checkouts/py/py32/Lib/test/test_format.py", line 20,
in testformat
(formatstr, args, output), end=' ')
UnicodeEncodeError: 'ascii' codec can't encode character '\u0374' in
position 8: ordinal not in range(128)
1 test failed:
test_format
"""
~jim
----------
components: Tests
messages: 96547
nosy: jgsack
severity: normal
status: open
title: test_format
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7537>
_______________________________________
From report at bugs.python.org Fri Dec 18 09:34:19 2009
From: report at bugs.python.org (River Tarnell)
Date: Fri, 18 Dec 2009 08:34:19 +0000
Subject: [New-bugs-announce] [issue7538] HP-UX 11.11 GCC build fails to
build modules
In-Reply-To: <1261125259.67.0.0629730876932.issue7538@psf.upfronthosting.co.za>
Message-ID: <1261125259.67.0.0629730876932.issue7538@psf.upfronthosting.co.za>
New submission from River Tarnell <river at flyingparchment.org.uk>:
2.6.4 fails to build on HP-UX 11.11 using GCC, when linking modules:
building '_struct' extension
gcc -pthread -shared build/temp.hp-ux-B.11.11-9000-785-2.6/home/river/
Python-2.6.4/Modules/_struct.o -L/opt/rt/lib -L/usr/local/lib -
lpython2.6 -o build/lib.hp-ux-B.11.11-9000-785-2.6/_struct.sl
/usr/ccs/bin/ld: Can't find library: "python2.6"
collect2: ld returned 1 exit status
(This happens for all modules.)
The problem is that libpython2.6.sl is in the root directory, but -L.
is not passed to gcc, so the linker can't find the library.
----------
components: Build
messages: 96552
nosy: rtarnell
severity: normal
status: open
title: HP-UX 11.11 GCC build fails to build modules
type: compile error
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7538>
_______________________________________
From report at bugs.python.org Fri Dec 18 12:55:39 2009
From: report at bugs.python.org (Marius Gedminas)
Date: Fri, 18 Dec 2009 11:55:39 +0000
Subject: [New-bugs-announce] [issue7539] unicode exceptions terminate
pdb.pm() loop
In-Reply-To: <1261137339.47.0.500431932871.issue7539@psf.upfronthosting.co.za>
Message-ID: <1261137339.47.0.500431932871.issue7539@psf.upfronthosting.co.za>
New submission from Marius Gedminas <marius at gedmin.as>:
$ python2.6
Python 2.6.4 (r264:75706, Dec 7 2009, 18:45:15)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> None()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'NoneType' object is not callable
>>> import pdb; pdb.pm()
> <stdin>(1)<module>()
(Pdb) raise Exception(u'\xff')
*** Exception: Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.6/pdb.py", line 1239, in pm
post_mortem(sys.last_traceback)
File "/usr/lib/python2.6/pdb.py", line 1236, in post_mortem
p.interaction(None, t)
File "/usr/lib/python2.6/pdb.py", line 194, in interaction
self.cmdloop()
File "/usr/lib/python2.6/cmd.py", line 142, in cmdloop
stop = self.onecmd(line)
File "/usr/lib/python2.6/pdb.py", line 261, in onecmd
return cmd.Cmd.onecmd(self, line)
File "/usr/lib/python2.6/cmd.py", line 218, in onecmd
return self.default(line)
File "/usr/lib/python2.6/pdb.py", line 226, in default
print >>self.stdout, '***', exc_type_name + ':', v
UnicodeEncodeError: 'ascii' codec can't encode character u'\xff' in
position 0: ordinal not in range(128)
>>>
Note that the post-mortem loop is terminated (if you do pdb.set_trace()
instead of pdb.pm(), that doesn't happen).
This is rather irritating then you're trying to post-mortem debug a
failed test with expensive setup, when leaving the postmortem pdb
session exits the process.
Python 3.1 is not affected. I don't have 2.7 handy.
----------
components: Library (Lib), Unicode
messages: 96560
nosy: mgedmin
severity: normal
status: open
title: unicode exceptions terminate pdb.pm() loop
type: behavior
versions: Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7539>
_______________________________________
From report at bugs.python.org Fri Dec 18 16:24:02 2009
From: report at bugs.python.org (Till Maas)
Date: Fri, 18 Dec 2009 15:24:02 +0000
Subject: [New-bugs-announce] [issue7540] urllib2 request does not update
content length after new add_data
In-Reply-To: <1261149842.32.0.235270861363.issue7540@psf.upfronthosting.co.za>
Message-ID: <1261149842.32.0.235270861363.issue7540@psf.upfronthosting.co.za>
New submission from Till Maas <opensource at till.name>:
When I try to reuse a urllib2.Request object with different post data,
the data itself is updated, but the content length is not. Here is a
simple script to reproduce it on Python 2.5 on Fedora 10 and 2.6 on Arch
Linux:
#!/usr/bin/python
# vim: fileencoding=utf8
# test with: echo | socat - tcp4-listen:1111,fork
# Demonstrates bad content length of second request, which should be 2
import urllib2
req = urllib2.Request('http://localhost:1111')
req.add_data("1")
urllib2.urlopen(req)
req.add_data("10")
urllib2.urlopen(req)
----------
components: Library (Lib)
messages: 96567
nosy: till
severity: normal
status: open
title: urllib2 request does not update content length after new add_data
type: behavior
versions: Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7540>
_______________________________________
From report at bugs.python.org Fri Dec 18 17:28:08 2009
From: report at bugs.python.org (Robin)
Date: Fri, 18 Dec 2009 16:28:08 +0000
Subject: [New-bugs-announce] [issue7541] python-config --ldflags doesn't
pick up libpython2.5.a
In-Reply-To: <1261153688.5.0.917977427633.issue7541@psf.upfronthosting.co.za>
Message-ID: <1261153688.5.0.917977427633.issue7541@psf.upfronthosting.co.za>
New submission from Robin <robince at gmail.com>:
Using my python.org install:
robin-mbp:~ robince$ which python-config
/Library/Frameworks/Python.framework/Versions/2.5/bin/python-config
robin-mbp:~ robince$ python-config --ldflags
-L/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/config
-ldl -lpython2.5
But if I build a C file with python embedded, the above linker flags
result it in it embedding the system python. Obviously the -lpython2.5
is picking up the system one in preference to the one on the -L path.
>From Ronald Oussoren on pythonmac-sig:
The easiest workaround is to open a terminal window and execute the
following commands:
cd
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/config
ln -s libpython2.5.a libpython2.5.dylib
This will ensure that the OSX linker knows that libpython is a shared
library and links to this library. By default the OSX linker searches
for a .dylib on the entire linker path and only then looks for .a files.
----------
assignee: ronaldoussoren
components: Macintosh
messages: 96569
nosy: robince, ronaldoussoren
severity: normal
status: open
title: python-config --ldflags doesn't pick up libpython2.5.a
versions: Python 2.5, Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7541>
_______________________________________
From report at bugs.python.org Fri Dec 18 20:54:01 2009
From: report at bugs.python.org (Anthony Foglia)
Date: Fri, 18 Dec 2009 19:54:01 +0000
Subject: [New-bugs-announce] [issue7542] segfault on cPickle.loads("0.")
In-Reply-To: <1261166041.47.0.835794497653.issue7542@psf.upfronthosting.co.za>
Message-ID: <1261166041.47.0.835794497653.issue7542@psf.upfronthosting.co.za>
New submission from Anthony Foglia <afoglia at gmail.com>:
cPickle in Python 2.6.4 segfaults when trying to load the string "0.".
pickle throws an error. cPickle should at the least not segfault.
$ python
Python 2.6.4 (r264:75706, Nov 2 2009, 14:44:17)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle, cPickle
>>> pickle.loads("0.")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.6/pickle.py", line 1374, in loads
return Unpickler(file).load()
File "/usr/lib/python2.6/pickle.py", line 858, in load
dispatch[key](self)
File "/usr/lib/python2.6/pickle.py", line 1138, in load_pop
del self.stack[-1]
IndexError: list assignment index out of range
>>> cPickle.loads("0.")
Segmentation fault (core dumped)
----------
components: Library (Lib)
messages: 96580
nosy: afoglia
severity: normal
status: open
title: segfault on cPickle.loads("0.")
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7542>
_______________________________________
From report at bugs.python.org Sat Dec 19 00:06:46 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 18 Dec 2009 23:06:46 +0000
Subject: [New-bugs-announce] [issue7543] RFE: introduce "enum Py_Opcode"
In-Reply-To: <1261177606.42.0.69169668441.issue7543@psf.upfronthosting.co.za>
Message-ID: <1261177606.42.0.69169668441.issue7543@psf.upfronthosting.co.za>
New submission from Dave Malcolm <dmalcolm at redhat.com>:
Currently, Python's opcodes are defined as preprocessor #defines. This means that they are
invisible to the debugger.
I'm attaching:
(i) a simple script (fixup-opcode-header.py) which converts Include/opcode.h to use an
anonymous enum for the values
(ii) a diff containing the results of running the script on trunk's Include/opcode.h
(iii) a patch that converts usage of "int opcode" to "enum Py_Opcode opcode" in a few
places
(Is the usage of an anonymous enum acceptable on all compilers that Python supports? Is it
going to generate equal machinecode on all compilers, relative to an int?)
With this patch, if I break into PyEval_EvalFrameEx in gdb, the debugger is able to emit
symbolic values for "opcode":
(gdb) p opcode
$2 = LOAD_CONST
----------
components: Interpreter Core
messages: 96587
nosy: dmalcolm
severity: normal
status: open
title: RFE: introduce "enum Py_Opcode"
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7543>
_______________________________________
From report at bugs.python.org Sat Dec 19 13:49:33 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 19 Dec 2009 12:49:33 +0000
Subject: [New-bugs-announce] [issue7544] multiprocessing.Pool(): Fatal
Python error: PyEval_AcquireThread: NULL new thread state
In-Reply-To: <1261226973.79.0.247580976393.issue7544@psf.upfronthosting.co.za>
Message-ID: <1261226973.79.0.247580976393.issue7544@psf.upfronthosting.co.za>
New submission from STINNER Victor <victor.stinner at haypocalc.com>:
Using my fuzzer (Fusil) on Python trunk, I got sometimes errors on
multiprocessing.Pool():
Fatal Python error: PyEval_AcquireThread: NULL new thread state
I'm sorry but I don't have example script to reproduce the bug. I
suppose that the error depends on the system load. I have the error on
an Intel Core2 Quad Core Q9300 (CPU able to run 4 processes/threads at
the time same).
How can I get more information on the bug? How can I reproduce it?
----------
components: Extension Modules
messages: 96602
nosy: haypo
severity: normal
status: open
title: multiprocessing.Pool(): Fatal Python error: PyEval_AcquireThread: NULL new thread state
type: crash
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7544>
_______________________________________
From report at bugs.python.org Sat Dec 19 16:59:11 2009
From: report at bugs.python.org (Pascal Chambon)
Date: Sat, 19 Dec 2009 15:59:11 +0000
Subject: [New-bugs-announce] [issue7545] IO buffering behaviour not properly
documented
In-Reply-To: <1261238351.34.0.64888213085.issue7545@psf.upfronthosting.co.za>
Message-ID: <1261238351.34.0.64888213085.issue7545@psf.upfronthosting.co.za>
New submission from Pascal Chambon <chambon.pascal at gmail.com>:
Hello,
It seems there is an important difference between the doc of the IO
module, and its implementation so far (until todcay trunk revision 76805)
"buffering is an optional integer used to set the buffering policy. By
default full buffering is on. Pass 0 to switch buffering off (only
allowed in binary mode), 1 to set line buffering, and an integer > 1 for
full buffering."
--> actually full buffering only occurs if a negative buffering
parameter is given, else it seems th current value i kept as the buffer
size - eg. if we give "3", buffering will be 3 bytes...
This seems a fine behaviour to me, so this implementation could just be
documented as is.
-----------
Only case of full buffering in the C iomodule :
if (buffering < 0) {
buffering = DEFAULT_BUFFER_SIZE;
#ifdef HAVE_STRUCT_STAT_ST_BLKSIZE
{
struct stat st;
long fileno;
PyObject *res = PyObject_CallMethod(raw, "fileno", NULL);
if (res == NULL)
goto error;
fileno = PyInt_AsLong(res);
Py_DECREF(res);
if (fileno == -1 && PyErr_Occurred())
goto error;
if (fstat(fileno, &st) >= 0)
buffering = st.st_blksize;
}
#endif
}
----------
assignee: georg.brandl
components: Documentation, IO
messages: 96607
nosy: georg.brandl, pakal
severity: normal
status: open
title: IO buffering behaviour not properly documented
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7545>
_______________________________________
From report at bugs.python.org Sat Dec 19 17:44:05 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 19 Dec 2009 16:44:05 +0000
Subject: [New-bugs-announce] [issue7546] msvc9compiler.py: add .asm extension
In-Reply-To: <1261241045.73.0.563579401037.issue7546@psf.upfronthosting.co.za>
Message-ID: <1261241045.73.0.563579401037.issue7546@psf.upfronthosting.co.za>
New submission from Stefan Krah <stefan-usenet at bytereef.org>:
Hi,
would it be possible to add .asm to the extensions? I attach a diff that
I have tested with VS Express.
----------
files: vcasm.diff
keywords: patch
messages: 96614
nosy: skrah
severity: normal
status: open
title: msvc9compiler.py: add .asm extension
type: feature request
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15609/vcasm.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7546>
_______________________________________
From report at bugs.python.org Sat Dec 19 17:45:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Dec 2009 16:45:04 +0000
Subject: [New-bugs-announce] [issue7547] test_timeout should skip, not fail,
when the remote host is not available
In-Reply-To: <1261241104.77.0.599570179128.issue7547@psf.upfronthosting.co.za>
Message-ID: <1261241104.77.0.599570179128.issue7547@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
test_timeout uses www.python.org as a Guinea pig for its socket tests.
Unfortunately sometimes www.python.org is down, which gives the
following kind of failures (seen on a buildbot recently):
test test_timeout failed -- Traceback (most recent call last):
File "C:\buildslave\3.x.moore-windows\build\lib\test\test_timeout.py",
line 133, in testRecvTimeout
self.sock.connect(self.addr_remote)
socket.error: [Errno 10060] A connection attempt failed because the
connected party did not properly respond after a period of time, or
established connection failed because connected host has failed to respond
test_timeout should catch the error and simply skip the test with an
appropriate message.
There's a similar problem with test_smtpnet which uses gmail as its
remote SMTP-SSL provider.
----------
components: Tests
messages: 96615
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_timeout should skip, not fail, when the remote host is not available
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/issue7547>
_______________________________________
From report at bugs.python.org Sat Dec 19 20:26:13 2009
From: report at bugs.python.org (Mark Florisson)
Date: Sat, 19 Dec 2009 19:26:13 +0000
Subject: [New-bugs-announce] [issue7548] If a generator raises TypeError
when being unpacked, an unrelated error message is shown
In-Reply-To: <1261250773.36.0.925954913531.issue7548@psf.upfronthosting.co.za>
Message-ID: <1261250773.36.0.925954913531.issue7548@psf.upfronthosting.co.za>
New submission from Mark Florisson <markflorisson88 at gmail.com>:
>>> list(*('boo' for x in [1]))
['b', 'o', 'o']
>>> list(*(range('error') for x in [1])) # notice the erroneous error
message
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: type object argument after * must be a sequence, not
generator
>>> list(*[range('error') for x in [1]])
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: range() integer end argument expected, got str.
>>> list(*(int('error') for x in [1])) # does work correctly for
ValueError
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 1, in <genexpr>
ValueError: invalid literal for int() with base 10: 'error'
----------
components: Interpreter Core
messages: 96642
nosy: eggy
severity: normal
status: open
title: If a generator raises TypeError when being unpacked, an unrelated error message is shown
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/issue7548>
_______________________________________
From report at bugs.python.org Sun Dec 20 01:05:23 2009
From: report at bugs.python.org (John Wells)
Date: Sun, 20 Dec 2009 00:05:23 +0000
Subject: [New-bugs-announce] [issue7549] 2.6.4 Win32 linked to debug DLLs?
In-Reply-To: <1261267523.81.0.700619941365.issue7549@psf.upfronthosting.co.za>
Message-ID: <1261267523.81.0.700619941365.issue7549@psf.upfronthosting.co.za>
New submission from John Wells <johnx.ca at gmail.com>:
I installed 2.6.4 x86 on Win7 x64. My Python app runs fine, but I get
daily errors in the event app log:
SOURCE: SideBySide
EVENT ID: 33
MESSAGE: Activation context generation failed for
"C:\WinUtils\Python26\Lib\distutils\command\wininst-8_d.exe". Dependent
Assembly
Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50608.0"
could not be found. Please use sxstrace.exe for detailed diagnosis.
I'm not a developer, but Google suggests to me that the reference to
"Microsoft.VC80.DebugCRT" indicates that some part of Python 2.6.4 was
linked to the debug version of the VC++ 2005 DLLs. Apparently this
shouldn't have been done, since the debug DLLs can't be redistributed.
Or is there some other fix for this?
----------
components: Windows
messages: 96655
nosy: jw113
severity: normal
status: open
title: 2.6.4 Win32 linked to debug DLLs?
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7549>
_______________________________________
From report at bugs.python.org Sun Dec 20 11:31:14 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 20 Dec 2009 10:31:14 +0000
Subject: [New-bugs-announce] [issue7550] PyLong_As* methods should not call
nb_int.
In-Reply-To: <1261305073.97.0.212369475826.issue7550@psf.upfronthosting.co.za>
Message-ID: <1261305073.97.0.212369475826.issue7550@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
The following C-API functions:
PyLong_AsLongAndOverflow
PyLong_AsUnsignedLongMask
PyLong_AsLongLong
PyLong_AsUnsignedLongLongMask
call nb_int for inputs that don't satisfy PyLong_Check. They thus accept
floats, Decimal instances, etc. They should probably call nb_index
instead (or perhaps accept only instances of int).
The uses of these functions within the Python source should be checked, to
see what consequences (if any) this change would have for Python
semantics; it's possible that some of these consequences would fall under
the moratorium (PEP 3003). In any case, this change probably requires a
1-release deprecation period.
----------
components: Interpreter Core
messages: 96670
nosy: mark.dickinson
severity: normal
status: open
title: PyLong_As* methods should not call nb_int.
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7550>
_______________________________________
From report at bugs.python.org Sun Dec 20 17:39:52 2009
From: report at bugs.python.org (Andreas Jung)
Date: Sun, 20 Dec 2009 16:39:52 +0000
Subject: [New-bugs-announce] [issue7551]
SystemError/MemoryError/OverflowErrors on encode() a unicode string
In-Reply-To: <1261327192.12.0.403194301804.issue7551@psf.upfronthosting.co.za>
Message-ID: <1261327192.12.0.403194301804.issue7551@psf.upfronthosting.co.za>
New submission from Andreas Jung <ajung at users.sourceforge.net>:
We encountered a pretty bizarre behavior of Python 2.4.6 while decoding a 600MB long unicode string
'data':
Python 2.4.6 (8GB RAM, 64 bit)
(Pdb) type(data)
<type 'unicode'>
(Pdb) len(data)
601794657
(Pdb) data2=data.encode('utf-8')
*** SystemError: Negative size passed to PyString_FromStringAndSize
Assuming that this has something to do with a 512MB limit:
(Pdb) data2=data[:512*1024*1024].encode('utf-8')
*** SystemError: Negative size passed to PyString_FromStringAndSize
Same bug...now with 512MB - 1 byte:
(Pdb) data2=data[:(256*1024*1024)-1].encode('utf-8')
OverflowError
Cross-check on a different Linux box (4GB RAM, 4 GB Swap, 64 bit)
ajung at blackmoon:~> python2.4
Python 2.4.5 (#1, Jun 9 2008, 10:35:12)
[GCC 4.2.1 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> data = u'x'*601794657
>>> data2= data.encode('utf-8')
Traceback (most recent call last):
File "<stdin>", line 1, in ?
MemoryError
Where is this different behavior coming from?
----------
messages: 96695
nosy: ajung
severity: normal
status: open
title: SystemError/MemoryError/OverflowErrors on encode() a unicode string
versions: Python 2.4
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7551>
_______________________________________
From report at bugs.python.org Sun Dec 20 19:15:45 2009
From: report at bugs.python.org (JP St. Pierre)
Date: Sun, 20 Dec 2009 18:15:45 +0000
Subject: [New-bugs-announce] [issue7552] uploading fails on long passwords
In-Reply-To: <1261332945.8.0.343157479139.issue7552@psf.upfronthosting.co.za>
Message-ID: <1261332945.8.0.343157479139.issue7552@psf.upfronthosting.co.za>
New submission from JP St. Pierre <jstpierre at mecheye.net>:
Uploading a file to PyPI fails when a user has a long password, as
base64.encodestring linewraps data. Either replace '\n' with '', or use
base64.standard_b64encode
----------
assignee: tarek
components: Distutils
messages: 96709
nosy: magcius, tarek
severity: normal
status: open
title: uploading fails on long passwords
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7552>
_______________________________________
From report at bugs.python.org Sun Dec 20 19:27:00 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 18:27:00 +0000
Subject: [New-bugs-announce] [issue7553] test_long_future is faulty
In-Reply-To: <1261333620.36.0.215143298483.issue7553@psf.upfronthosting.co.za>
Message-ID: <1261333620.36.0.215143298483.issue7553@psf.upfronthosting.co.za>
New submission from Florent Xicluna <laxyf at yahoo.fr>:
This test do not test "true division" contrary to what is claimed.
for zero in ["huge / 0", "huge / 0L", "mhuge / 0", "mhuge / 0L"]:
self.assertRaises(ZeroDivisionError, eval, zero, namespace)
Because it uses the module "unittest" to eval the expression.
And __future__.division is not active in unittest module.
Other tests were OK.
----------
components: Tests
messages: 96710
nosy: flox
priority: low
severity: normal
status: open
title: test_long_future is faulty
type: behavior
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7553>
_______________________________________
From report at bugs.python.org Sun Dec 20 20:37:59 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 19:37:59 +0000
Subject: [New-bugs-announce] [issue7554] Some tests in test_cmath should use
rAssertAlmostEqual incorrectly
In-Reply-To: <1261337879.76.0.460831338952.issue7554@psf.upfronthosting.co.za>
Message-ID: <1261337879.76.0.460831338952.issue7554@psf.upfronthosting.co.za>
New submission from Florent Xicluna <laxyf at yahoo.fr>:
These tests do not pass the right arguments to rAssertAlmostEqual.
They should use assertAlmostEqual instead.
(around line 123)
self.rAssertAlmostEqual(cmath.pi, pi_expected, 9,
"cmath.pi is %s; should be %s" % (cmath.pi, pi_expected))
self.rAssertAlmostEqual(cmath.e, e_expected, 9,
"cmath.e is %s; should be %s" % (cmath.e, e_expected))
----------
components: Tests
messages: 96718
nosy: flox
severity: normal
status: open
title: Some tests in test_cmath should use rAssertAlmostEqual incorrectly
type: behavior
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7554>
_______________________________________
From report at bugs.python.org Mon Dec 21 11:25:58 2009
From: report at bugs.python.org (Leo Spidian)
Date: Mon, 21 Dec 2009 10:25:58 +0000
Subject: [New-bugs-announce] [issue7555] Wrong return value of isinstance()
function
In-Reply-To: <1261391158.3.0.901615130384.issue7555@psf.upfronthosting.co.za>
Message-ID: <1261391158.3.0.901615130384.issue7555@psf.upfronthosting.co.za>
New submission from Leo Spidian <zhangdongying1986 at gmail.com>:
isinstance() function returns False while surpposed to return True
============ tt.py =================
import ss
class tt:
def __init__(self, s):
if not isinstance(s, ss.ss):
raise Exception("s is not an instance of ss.ss")
====================================
============ ss.py =================
import tt
class sss:
pass
class ss(sss):
pass
if __name__ == '__main__':
s = ss()
print isinstance(s, ss)
t = tt.tt(s)
====================================
Run ss.py:
True
Traceback (most recent call last):
File "D:\workspace\PostDocs\ss.py", line 11, in <module>
t = tt.tt(s)
File "D:\workspace\PostDocs\tt.py", line 6, in __init__
raise Exception("s is not an instance of ss.ss")
Exception: s is not an instance of ss.ss
----------
components: None
files: ss.py
messages: 96733
nosy: leospidian
severity: normal
status: open
title: Wrong return value of isinstance() function
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15641/ss.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7555>
_______________________________________
From report at bugs.python.org Mon Dec 21 19:59:18 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 21 Dec 2009 18:59:18 +0000
Subject: [New-bugs-announce] [issue7556] msvc9compiler.py: TypeError: can't
use a string pattern on a bytes-like object
In-Reply-To: <1261421958.47.0.722908019254.issue7556@psf.upfronthosting.co.za>
Message-ID: <1261421958.47.0.722908019254.issue7556@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
While building pywin32 with Py3k trunk (not release version), I get this
traceback:
Creating library build\temp.win32-
3.1\Release\win32\src\pywintypes31.lib and object buil
d\temp.win32-3.1\Release\win32\src\pywintypes31.exp
Traceback (most recent call last):
File "setup3.py", line 16, in <module>
exec(str(got))
...skipping...
File "<string>", line 2194, in <module>
File
"C:\HOME\as\apy\branches\nightly\build\pyhg_branches_release3_1_maint-
win32-x86-hgti
\core.py", line 149, in setup
dist.run_commands()
File
"C:\HOME\as\apy\branches\nightly\build\pyhg_branches_release3_1_maint-
win32-x86-hgti
\dist.py", line 919, in run_commands
self.run_command(cmd)
File
"C:\HOME\as\apy\branches\nightly\build\pyhg_branches_release3_1_maint-
win32-x86-hgti
\dist.py", line 938, in run_command
cmd_obj.run()
File "<string>", line 619, in run
File
"C:\HOME\as\apy\branches\nightly\build\pyhg_branches_release3_1_maint-
win32-x86-hgti
\command\build.py", line 128, in run
self.run_command(cmd_name)
File
"C:\HOME\as\apy\branches\nightly\build\pyhg_branches_release3_1_maint-
win32-x86-hgti
\cmd.py", line 315, in run_command
self.distribution.run_command(command)
File
"C:\HOME\as\apy\branches\nightly\build\pyhg_branches_release3_1_maint-
win32-x86-hgti
\dist.py", line 938, in run_command
cmd_obj.run()
File
"C:\HOME\as\apy\branches\nightly\build\pyhg_branches_release3_1_maint-
win32-x86-hgti
\command\build_ext.py", line 347, in run
p31-rrun\python\lib\distutils\ccompiler.py", line 791, in
link_shared_object
extra_preargs, extra_postargs, build_temp, target_lang)
File "<string>", line 1384, in link
p31-rrun\python\lib\distutils\msvc9compiler.py", line 663, in link
manifest_buf = re.sub(pattern, "", manifest_buf)
p31-rrun\python\lib\re.py", line 166, in sub
return _compile(pattern, flags).sub(repl, string, count)
TypeError: can't use a string pattern on a bytes-like object
----------
assignee: tarek
components: Distutils
messages: 96763
nosy: srid, tarek
severity: normal
status: open
title: msvc9compiler.py: TypeError: can't use a string pattern on a bytes-like object
type: behavior
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7556>
_______________________________________
From report at bugs.python.org Mon Dec 21 21:11:43 2009
From: report at bugs.python.org (Jacques Lemire)
Date: Mon, 21 Dec 2009 20:11:43 +0000
Subject: [New-bugs-announce] [issue7557] Imprecise description for the
fire.read() method
In-Reply-To: <1261426303.17.0.403576961756.issue7557@psf.upfronthosting.co.za>
Message-ID: <1261426303.17.0.403576961756.issue7557@psf.upfronthosting.co.za>
New submission from Jacques Lemire <jaclemire at gmail.com>:
see this web page:
http://docs.python.org/3.1/library/stdtypes.html?
highlight=read#file.read
The description should say:
for Python 3.1 the method reads characters, for instance utf-8
characters.
if the mode is 'rb', then it reads bytes (i.e. byte == 8 bits).
Context: Linux Ubuntu 9.10, 64 bit, compiled locally.
----------
assignee: georg.brandl
components: Documentation
messages: 96767
nosy: georg.brandl, jlp
severity: normal
status: open
title: Imprecise description for the fire.read() method
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7557>
_______________________________________
From report at bugs.python.org Mon Dec 21 21:15:27 2009
From: report at bugs.python.org (John Nagle)
Date: Mon, 21 Dec 2009 20:15:27 +0000
Subject: [New-bugs-announce] [issue7558] Python 3.1.1 installer botches
upgrade when installation is not on C drive.
In-Reply-To: <1261426527.41.0.844327197724.issue7558@psf.upfronthosting.co.za>
Message-ID: <1261426527.41.0.844327197724.issue7558@psf.upfronthosting.co.za>
New submission from John Nagle <nagle at users.sourceforge.net>:
I just installed "python3.1.1.msi" on a system that had "python3.1.msi"
installed in "D:/python31". In this situation, the installer does not
ask the user for a destination directory. The installer found the old
installation in "D:/python31", removed most but not all of the files
there, and then installed the new version in "C:/python31".
I uninstalled the failed install, and reinstalled.
On a new install, the installer prompts for the destination dir, and
that works. Upgrade installs, though, are botched.
John Nagle
----------
components: Installation
messages: 96768
nosy: nagle
severity: normal
status: open
title: Python 3.1.1 installer botches upgrade when installation is not on C drive.
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7558>
_______________________________________
From report at bugs.python.org Mon Dec 21 22:07:17 2009
From: report at bugs.python.org (Robert Collins)
Date: Mon, 21 Dec 2009 21:07:17 +0000
Subject: [New-bugs-announce] [issue7559] TestLoader.loadTestsFromName
swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
New submission from Robert Collins <robertc at robertcollins.net>:
Say I have a test module test_foo, which fails to import with
ImportError. A reason for this might be a misspelt import in that module.
TestLoader().loadTestsFromName swallows the import error and instead
crashes with:
File "/usr/lib/python2.6/unittest.py", line 584, in loadTestsFromName
parent, obj = obj, getattr(obj, part)
AttributeError: 'module' object has no attribute 'test_foo'
A better thing to do would be to keep the import error and if the next
probe is an Attribute error, reraise the import error.
An alternative would be to return a test which would then reraise the
import error permitting the test suite to be constructed and execute but
still reporting the error.
----------
components: Library (Lib)
messages: 96770
nosy: rbcollins
severity: normal
status: open
title: TestLoader.loadTestsFromName swallows import errors
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7559>
_______________________________________
From report at bugs.python.org Tue Dec 22 06:07:42 2009
From: report at bugs.python.org (Sebastian Hagen)
Date: Tue, 22 Dec 2009 05:07:42 +0000
Subject: [New-bugs-announce] [issue7560] Various filename-taking posix
methods don't like bytes / buffer objects.
In-Reply-To: <1261458462.16.0.0100952896884.issue7560@psf.upfronthosting.co.za>
Message-ID: <1261458462.16.0.0100952896884.issue7560@psf.upfronthosting.co.za>
New submission from Sebastian Hagen <sh_pybugs at memespace.net>:
Most of the functions in Python's stdlib that take filename parameters
allow for those parameters to be buffer (such as bytes, bytearray,
memoryview) objects. This is useful for various reasons, among them that
on Posix-likes, file- and pathnames ultimately *are* sequences of bytes.
A number of functions in the posix (and thus, os) module break this
convention:
mkfifo()
mknod()
statvfs()
pathconf()
E.g.:
>>> os.statvfs(b'/')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: statvfs() argument 1 must be string, not bytes
I'm attaching a patch that modifies the abovementioned functions to make
them accept buffer-like objects in addition to string objects; I've
never contributed code to the stdlib, so any general problems with that
patch can be ascribed to my ignorance about established practice (or
inability to program, in the case of downright bugs).
I'm a bit off a loss as what to do about posix.system(). IMO, that one
should also take bytes - at least on posix-like OSes - since it
specifies a commandline, and both the name and the arguments in such
lines are, on posix-likes, sequences of bytes.
I'm not sure how to best reconcile that with the MS Windows version of
that function, however; advice would be welcome.
----------
components: Library (Lib)
files: posix_fn_bytes_01.patch
keywords: patch
messages: 96792
nosy: sh
severity: normal
status: open
title: Various filename-taking posix methods don't like bytes / buffer objects.
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15659/posix_fn_bytes_01.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7560>
_______________________________________
From report at bugs.python.org Tue Dec 22 08:31:43 2009
From: report at bugs.python.org (Sebastian Hagen)
Date: Tue, 22 Dec 2009 07:31:43 +0000
Subject: [New-bugs-announce] [issue7561] Filename-taking functions in posix
segfault when called with a bytearray arg.
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
New submission from Sebastian Hagen <sh_pybugs at memespace.net>:
Various functions in the 'posix' module that take filename arguments
accept bytearray values for those arguments, and mishandle those objects
in a way that leads to segfaults.
Python 3.1 (r31:73572, Jul 23 2009, 23:41:26)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.mkdir(bytearray(b'/'))
Segmentation fault
There's at least two seperate problems with the way posixmodule handles
these objects. The first is that the code isn't set up to handle NULL
retvals from PyByteArray_AS_STRING(), which occur for zero-byte
bytearray objects. This causes a NULL-pointer dereference in
PyUnicode_FSConverter() if you pass a zero-length bytearray.
The second issue is that release_bytes() calls bytearray_releasebuffer()
with NULL for the first argument, which directly leads to a NULL-pointer
dereference.
I'm attaching a patch against SVN 77001 which should fix both of these
issues.
----------
components: Library (Lib)
files: posixmodule_fn_bytearray_fix_01.patch
keywords: patch
messages: 96795
nosy: sh
severity: normal
status: open
title: Filename-taking functions in posix segfault when called with a bytearray arg.
type: crash
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15660/posixmodule_fn_bytearray_fix_01.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________
From report at bugs.python.org Tue Dec 22 15:35:13 2009
From: report at bugs.python.org (Jari Pennanen)
Date: Tue, 22 Dec 2009 14:35:13 +0000
Subject: [New-bugs-announce] [issue7562] Custom order for the subcommands of
build
In-Reply-To: <1261492513.72.0.435888181618.issue7562@psf.upfronthosting.co.za>
Message-ID: <1261492513.72.0.435888181618.issue7562@psf.upfronthosting.co.za>
New submission from Jari Pennanen <jari.pennanen at gmail.com>:
Long story short: Sometimes build_ext should be run before build_py, or
something similar.
As an example when using SWIG and setup.py the build order is incorrect:
During build_ext the SWIG generates .py files that should be used during
build_py, but since build_py was already ran this doesn't work.
It would be useful if one could for example define custom order for
subcommands in setup, in this case like:
setup(..., build_order=['build_ext', 'build_py'])
If adding a new keyword argument to setup is not an option, some other
way to specify custom build order should be considered.
This is common problem especially using SWIG. Discussion about this
issue was in here http://mail.python.org/pipermail/distutils-sig/2009-
December/015010.html the workaround for SWIG case is to use following
setup.py:
#!/usr/bin/env python
from distutils.core import setup, Extension
from distutils.command.build_py import build_py
dist = setup(...)
# Rerun the build_py
build_py = build_py(dist)
build_py.ensure_finalized()
build_py.run()
----------
assignee: tarek
components: Distutils
messages: 96798
nosy: ciantic, tarek
severity: normal
status: open
title: Custom order for the subcommands of build
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7562>
_______________________________________
From report at bugs.python.org Tue Dec 22 20:48:38 2009
From: report at bugs.python.org (Ronnie Maor)
Date: Tue, 22 Dec 2009 19:48:38 +0000
Subject: [New-bugs-announce] [issue7563] yield in except clause causes
exception context to be lost
In-Reply-To: <1261511318.07.0.56759832135.issue7563@psf.upfronthosting.co.za>
Message-ID: <1261511318.07.0.56759832135.issue7563@psf.upfronthosting.co.za>
New submission from Ronnie Maor <ronnie.maor at gmail.com>:
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> def coroutine():
... try:
... raise Exception('bla')
... except:
... yield 'foo'
... raise
...
>>> for _ in coroutine():
... pass
...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 6, in coroutine
TypeError: exceptions must be classes or instances, not NoneType
Seems that yielding in the except clause makes python forget the current
exception, so a bar "raise" statement raises None, instead of the
original exception.
changing except to except Exception,e: and raise to raise e throws the
original exception, but then the original stack trace is lost.
----------
components: Interpreter Core
messages: 96812
nosy: ronniemaor
severity: normal
status: open
title: yield in except clause causes exception context to be lost
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7563>
_______________________________________
From report at bugs.python.org Wed Dec 23 00:39:15 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 22 Dec 2009 23:39:15 +0000
Subject: [New-bugs-announce] [issue7564] test_ioctl fails sometimes
In-Reply-To: <1261525155.67.0.425847513735.issue7564@psf.upfronthosting.co.za>
Message-ID: <1261525155.67.0.425847513735.issue7564@psf.upfronthosting.co.za>
New submission from Florent Xicluna <laxyf at yahoo.fr>:
I got it to fail sometimes on trunk, when run with "-r -uall".
Debian 64bits, Python 2.7a r77004
test_ioctl
test_ioctl (test.test_ioctl.IoctlTests) ... FAIL
test_ioctl_mutate (test.test_ioctl.IoctlTests) ... FAIL
test_ioctl_signed_unsigned_code_param (test.test_ioctl.IoctlTests) ... ok
======================================================================
FAIL: test_ioctl (test.test_ioctl.IoctlTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "./Lib/test/test_ioctl.py", line 27, in test_ioctl
self.assertTrue(rpgrp in ids, "%s not in %s" % (rpgrp, ids))
AssertionError: 9165 not in (2334, 15696)
======================================================================
FAIL: test_ioctl_mutate (test.test_ioctl.IoctlTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "./Lib/test/test_ioctl.py", line 37, in test_ioctl_mutate
self.assertTrue(rpgrp in ids, "%s not in %s" % (rpgrp, ids))
AssertionError: 9165 not in (2334, 15696)
----------------------------------------------------------------------
Ran 3 tests in 0.001s
FAILED (failures=2)
test test_ioctl failed -- multiple errors occurred
----------
components: Tests
messages: 96820
nosy: flox
severity: normal
status: open
title: test_ioctl fails sometimes
type: behavior
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7564>
_______________________________________
From report at bugs.python.org Wed Dec 23 01:25:35 2009
From: report at bugs.python.org (George King)
Date: Wed, 23 Dec 2009 00:25:35 +0000
Subject: [New-bugs-announce] [issue7565] Increasing resource.RLIMIT_NOFILE
has no effect
In-Reply-To: <1261527935.68.0.0855643074362.issue7565@psf.upfronthosting.co.za>
Message-ID: <1261527935.68.0.0855643074362.issue7565@psf.upfronthosting.co.za>
New submission from George King <gkbox at arboreality.net>:
My builds from trunk fail to open a number of files greater than the
default 2660, even when I increase the limit using:
resource.setrlimit(resource.RLIMIT_NOFILE, (test_limit, -1))
Attached is a script that doubles the default limit, sets it, queries it
to make sure that it is set, and then opens the expected number of
files. The script succeeds when run on the python2.6 that apples ships
with 10.6, and it succeeds when run on my build of python3.2 trunk
(updated today). However, it fails on python2.7 trunk (also built
today).
here is sample output:
gk > python2.6 ./file_limits_bug.py
default file limits: (2560, 9223372036854775807)
new file limits: (5120, 9223372036854775807)
gk > python2.7 ./file_limits_bug.py
default file limits: (2560, 9223372036854775807)
new file limits: (5120, 9223372036854775807)
Traceback (most recent call last):
File "./file_limits_bug.py", line 34, in <module>
IOError: [Errno 24] Too many open files: 'testfiles/testfile2557'
----------
components: Library (Lib)
files: file_limits_bug.py
messages: 96821
nosy: george.king
severity: normal
status: open
title: Increasing resource.RLIMIT_NOFILE has no effect
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file15664/file_limits_bug.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7565>
_______________________________________
From report at bugs.python.org Wed Dec 23 01:56:47 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 23 Dec 2009 00:56:47 +0000
Subject: [New-bugs-announce] [issue7566] Add ntpath.sameopenfile support for
Windows
In-Reply-To: <1261529807.86.0.672662668527.issue7566@psf.upfronthosting.co.za>
Message-ID: <1261529807.86.0.672662668527.issue7566@psf.upfronthosting.co.za>
New submission from Jason R. Coombs <jaraco at jaraco.com>:
In issue1578269, asvetlov suggests adding an implementation of
os.sameopenfile to ntpath.py:
---
Jason, as I see you implemented os.samefile (actually ntpath.samefile)
but os.sameopenfile is still not implemented.
Looks like it's easy to do: while GetFinalPathNameByHandle already
accept file handle you can use CRT function _get_osfhandle(fd) to
convert file descriptors (arguments for sameopenfile) to file handles
and pass it to GetFinalPathNameByHandle.
For me samefile and sameopenfile has very close semantic and I like to
see both if it's possible.
---
This seems entirely reasonable, but I would like to track and tackle
this as a separate issue.
----------
components: Windows
messages: 96822
nosy: jaraco
severity: normal
status: open
title: Add ntpath.sameopenfile support for Windows
type: feature request
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7566>
_______________________________________
From report at bugs.python.org Wed Dec 23 02:46:18 2009
From: report at bugs.python.org (Yury)
Date: Wed, 23 Dec 2009 01:46:18 +0000
Subject: [New-bugs-announce] [issue7567] Messed up terminal after calling
curses.initscr() twice.
In-Reply-To: <1261532778.06.0.257601342471.issue7567@psf.upfronthosting.co.za>
Message-ID: <1261532778.06.0.257601342471.issue7567@psf.upfronthosting.co.za>
New submission from Yury <yury.sobolev at gmail.com>:
Calling curses.initscr after curses.endwin() results in a messed up
terminal the second time curses.endwind() is called. For example:
import curses
curses.initscr(); curses.endwin(); curses.initscr(); curses.endwin()
This behaves correctly in python 2.5. It does not work in python 2.6.
----------
components: Library (Lib)
messages: 96826
nosy: yury
severity: normal
status: open
title: Messed up terminal after calling curses.initscr() twice.
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7567>
_______________________________________
From report at bugs.python.org Wed Dec 23 16:04:01 2009
From: report at bugs.python.org (Mike Putnam)
Date: Wed, 23 Dec 2009 15:04:01 +0000
Subject: [New-bugs-announce] [issue7568] Spelling error in imaplib module
docs
In-Reply-To: <1261580641.6.0.189966780235.issue7568@psf.upfronthosting.co.za>
Message-ID: <1261580641.6.0.189966780235.issue7568@psf.upfronthosting.co.za>
New submission from Mike Putnam <mike at theputnams.net>:
The documentation string within the IMAP4.thread function incorrectly
spells the "threading_algorithm" arg as "threading_alogrithm"
Appears to affect imaplib.py ver. 2.55 & 2.58 Could not find other
versions to examine.
Starting in:
/release24-maint/Lib/imaplib.py
__version__ = "2.55" 3 occurences of "threading_alogrithm"
/release25-maint/Lib/imaplib.py
__version__ = "2.58" 1 occurence of "threading_alogrithm"
/release26-maint/Lib/imaplib.py
__version__ = "2.58" 1 occurence of "threading_alogrithm"
/release30-maint/Lib/imaplib.py
__version__ = "2.58" 1 occurence of "threading_alogrithm"
/release31-maint/Lib/imaplib.py
__version__ = "2.58" 1 occurence of "threading_alogrithm"
----------
components: Library (Lib)
messages: 96839
nosy: mikeputnam
severity: normal
status: open
title: Spelling error in imaplib module docs
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7568>
_______________________________________
From report at bugs.python.org Wed Dec 23 20:15:47 2009
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 23 Dec 2009 19:15:47 +0000
Subject: [New-bugs-announce] [issue7569] ctypes doc improvement: c_char_p
In-Reply-To: <1261595747.14.0.140020920323.issue7569@psf.upfronthosting.co.za>
Message-ID: <1261595747.14.0.140020920323.issue7569@psf.upfronthosting.co.za>
New submission from Nikolaus Rath <Nikolaus at rath.org>:
It would be great if the documentation of c_char_p
(http://docs.python.org/library/ctypes.html#ctypes.c_char_p) could be
reformulated as follows (would have saved me quite some time):
class ctypes.c_char_p?
Represents the C char * datatype when it points a zero-terminated
string. For a general character pointer that may also point to binary
data, POINTER(c_char) must be used. The constructor accepts an integer
address, or a string.
----------
assignee: georg.brandl
components: Documentation
messages: 96842
nosy: Nikratio, georg.brandl
severity: normal
status: open
title: ctypes doc improvement: c_char_p
type: feature request
versions: 3rd party, Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7569>
_______________________________________
From report at bugs.python.org Wed Dec 23 22:11:58 2009
From: report at bugs.python.org (=?utf-8?q?Manuel_Murad=C3=A1s?=)
Date: Wed, 23 Dec 2009 21:11:58 +0000
Subject: [New-bugs-announce] [issue7570] Error in urllib2 example
In-Reply-To: <1261602718.38.0.18447814559.issue7570@psf.upfronthosting.co.za>
Message-ID: <1261602718.38.0.18447814559.issue7570@psf.upfronthosting.co.za>
New submission from Manuel Murad?s <mmuradas at dieresys.com.ar>:
We've found an error in an urllib2 example with Proxy Basic
authentication. This is the example with the error:
{{{
This example replaces the default ProxyHandler with one that uses
programmatically-supplied proxy URLs, and adds proxy authorization
support with ProxyBasicAuthHandler.
proxy_handler = urllib2.ProxyHandler({'http':
'http://www.example.com:3128/'})
proxy_auth_handler = urllib2.HTTPBasicAuthHandler()
proxy_auth_handler.add_password('realm', 'host', 'username', 'password')
opener = build_opener(proxy_handler, proxy_auth_handler)
# This time, rather than install the OpenerDirector, we use it directly:
opener.open('http://www.example.com/login.html')
}}}
Attached you will find a patch with the fix.
----------
assignee: georg.brandl
components: Documentation
files: urllib2.patch
keywords: patch
messages: 96843
nosy: dieresys, georg.brandl
severity: normal
status: open
title: Error in urllib2 example
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15668/urllib2.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7570>
_______________________________________
From report at bugs.python.org Thu Dec 24 07:48:42 2009
From: report at bugs.python.org (Frank Millman)
Date: Thu, 24 Dec 2009 06:48:42 +0000
Subject: [New-bugs-announce] [issue7571] Change 'name' of Process -
assertion failure if Unicode
In-Reply-To: <1261637322.52.0.734915496426.issue7571@psf.upfronthosting.co.za>
Message-ID: <1261637322.52.0.734915496426.issue7571@psf.upfronthosting.co.za>
New submission from Frank Millman <frank at chagford.com>:
At the top of my program, I have 'from __future__ import
unicode_literals'.
I subclassed Process, and passed "name='test'" as an argument. I got
the following traceback.
Traceback (most recent call last):
File "F:\junk\multiprocess\mp5.py", line 37, in <module>
p = Frank(name='test')
File "F:\junk\multiprocess\mp5.py", line 18, in __init__
self.name = name
File "C:\Python26\lib\multiprocessing\process.py", line 141, in name
assert isinstance(name, str), 'name must be a string'
AssertionError: name must be a string
If I change the argument to "name=str('test')" there is no error.
For Python 2.x I think the assertion should be "isinstance(name,
basestring)" to prevent this from happening.
----------
components: Library (Lib)
messages: 96849
nosy: frankmillman
severity: normal
status: open
title: Change 'name' of Process - assertion failure if Unicode
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7571>
_______________________________________
From report at bugs.python.org Thu Dec 24 11:18:38 2009
From: report at bugs.python.org (lakshmipathi)
Date: Thu, 24 Dec 2009 10:18:38 +0000
Subject: [New-bugs-announce] [issue7572] Strabge issue : cursor.commit()
with sqlite
In-Reply-To: <1261649918.23.0.144063644038.issue7572@psf.upfronthosting.co.za>
Message-ID: <1261649918.23.0.144063644038.issue7572@psf.upfronthosting.co.za>
New submission from lakshmipathi <lakshmipathi.g at gmail.com>:
Hi all,
I'm new user to python and sqlite, let me know if i'm wrong or it's
sqlite issue.When I uncomment the line from below program it works -as
expected. But even when it's commented It works for first time.-As per
doc,without commit -all changes will be lost- am i right?
Issue : Running the program once without commit works for the first time
but not the next time.
Try changing the return value from 'OSS' to 'GNU' and comment/uncomment
the commit line.
----------------------------------
Here is my program:
-------------------------------------
import sqlite3
def loopy():
return 'OSS'
#get connection object
conn = sqlite3.connect("/tmp/example")
#get curson obj. and invoke execute
cur = conn.cursor()
conn.create_function("loopy",0,loopy)
cur.execute("insert into stk values (loopy())""")
#commit changes.
#conn.commit() # ******Uncomment this line and run again*******
# read values
cur.execute("select * from stk")
for row in cur:
print row
cur.close()
-------------------------
----------
messages: 96851
nosy: lakshmipathi
severity: normal
status: open
title: Strabge issue : cursor.commit() with sqlite
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7572>
_______________________________________
From report at bugs.python.org Thu Dec 24 12:26:21 2009
From: report at bugs.python.org (instigate_team)
Date: Thu, 24 Dec 2009 11:26:21 +0000
Subject: [New-bugs-announce] [issue7573] Python build issue on Ubuntu 9.10
In-Reply-To: <1261653981.05.0.861950270955.issue7573@psf.upfronthosting.co.za>
Message-ID: <1261653981.05.0.861950270955.issue7573@psf.upfronthosting.co.za>
New submission from instigate_team <narine_martirosyan at instigatedesign.com>:
Hello Python development team!
We encountered problem concerning Python 3.1 usage.
Platform info:
Ubuntu 9.10 32/64bit, glibc v. 2.10.1, gcc v. 4.4.0, Python 3.1.
Problem description:
Below is given the C++ program text causing the warning:
#include <string>
#include <Python.h>
int main()
{
return 0;
}
Compilation result is the following:
In file included from /usr/include/python3.1/Python.h:8,
from main.cpp:3:
/usr/include/python3.1/pyconfig.h:1108:1: warning: "_POSIX_C_SOURCE"
redefined
In file included from
/usr/include/c++/4.4/i486-linux-gnu/bits/os_defines.h:39,
from
/usr/include/c++/4.4/i486-linux-gnu/bits/c++config.h:243,
from /usr/include/c++/4.4/string:40,
from main.cpp:2:
/usr/include/features.h:158:1: warning: this is the location of the
previous definition
In file included from /usr/include/python3.1/Python.h:8,
from main.cpp:3:
/usr/include/python3.1/pyconfig.h:1130:1: warning: "_XOPEN_SOURCE" redefined
In file included from
/usr/include/c++/4.4/i486-linux-gnu/bits/os_defines.h:39,
from
/usr/include/c++/4.4/i486-linux-gnu/bits/c++config.h:243,
from /usr/include/c++/4.4/string:40,
from main.cpp:2:
/usr/include/features.h:160:1: warning: this is the location of the
previous definition
Analyzing the error:
We find out that the includes sequence influences on the application
build. We have no problem in case if Python header is included before
"string" file.
The problem is concerning the conflict of pyconfig.h and features.h
(/usr/include/features.h, which is the part of glibc), which is included
in string header file. We have the same result with any header file,
which includes features.h file.
File features.h defines _POSIX_C_SOURCE in case of some conditions are true.
In its turn pyconfig.h contains the following code in line 1108
#define _POSIX_C_SOURCE 200112L
And we get redefinition warning. Our projects are working with gcc
-Werror flags, so this is the blocking problem.
The same happened with _XOPEN_SOURCE.
Any help from your side will be very much appreciated.
----------
components: Build
messages: 96852
nosy: instigate_team
severity: normal
status: open
title: Python build issue on Ubuntu 9.10
type: compile error
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7573>
_______________________________________
From report at bugs.python.org Thu Dec 24 12:54:41 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 24 Dec 2009 11:54:41 +0000
Subject: [New-bugs-announce] [issue7574] PyUnicode_FromFormat broken and not
documented for 2.x
In-Reply-To: <1261655681.25.0.454963458841.issue7574@psf.upfronthosting.co.za>
Message-ID: <1261655681.25.0.454963458841.issue7574@psf.upfronthosting.co.za>
New submission from Ronald Oussoren <ronaldoussoren at mac.com>:
Include/unicodeobject.h includes prototypes for PyUnicode_FromFormat and
PyUnicode_FromFormatV in both 2.6 and 2.7, but those functions are not
included in the documention.
And worse, the implementation contains bugs: the %R format code tries to
include the repr() of an object and blindly assumes that the result of
PyObject_Repr is a unicode string. In the 2.x tree PyObject_Repr usually
(but not allways) returns a regular string (str instead of unicode).
The same problem is present in the implementation of %S.
For the %U and %V formats the code does typechecking in an assert
statement rather than always testing and bailing out using a NULL result
from the function.
----------
assignee: georg.brandl
components: Documentation, Interpreter Core
messages: 96853
nosy: georg.brandl, ronaldoussoren
severity: normal
stage: needs patch
status: open
title: PyUnicode_FromFormat broken and not documented for 2.x
type: crash
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7574>
_______________________________________
From report at bugs.python.org Thu Dec 24 17:03:00 2009
From: report at bugs.python.org (Salman Haq)
Date: Thu, 24 Dec 2009 16:03:00 +0000
Subject: [New-bugs-announce] [issue7575] tes_math fails Mac OS X 10.4 due to
OverflowError in test_mtestfile
In-Reply-To: <1261670580.8.0.882101850319.issue7575@psf.upfronthosting.co.za>
Message-ID: <1261670580.8.0.882101850319.issue7575@psf.upfronthosting.co.za>
New submission from Salman Haq <salman.haq at gmail.com>:
See output of regrtest below. It was run on an Intel Mac OS X 10.4
A similar failure is observed on the py3k branch.
./python.exe Lib/test/regrtest.py -v test_math
test_math
testAcos (test.test_math.MathTests) ... ok
testAcosh (test.test_math.MathTests) ... ok
testAsin (test.test_math.MathTests) ... ok
testAsinh (test.test_math.MathTests) ... ok
testAtan (test.test_math.MathTests) ... ok
testAtan2 (test.test_math.MathTests) ... ok
testAtanh (test.test_math.MathTests) ... ok
testCeil (test.test_math.MathTests) ... ok
testConstants (test.test_math.MathTests) ... ok
testCopysign (test.test_math.MathTests) ... ok
testCos (test.test_math.MathTests) ... ok
testCosh (test.test_math.MathTests) ... ok
testDegrees (test.test_math.MathTests) ... ok
testExp (test.test_math.MathTests) ... ok
testFabs (test.test_math.MathTests) ... ok
testFactorial (test.test_math.MathTests) ... ok
testFloor (test.test_math.MathTests) ... ok
testFmod (test.test_math.MathTests) ... ok
testFrexp (test.test_math.MathTests) ... ok
testFsum (test.test_math.MathTests) ... ok
testHypot (test.test_math.MathTests) ... ok
testIsinf (test.test_math.MathTests) ... ok
testIsnan (test.test_math.MathTests) ... ok
testLdexp (test.test_math.MathTests) ... ok
testLog (test.test_math.MathTests) ... ok
testLog10 (test.test_math.MathTests) ... ok
testLog1p (test.test_math.MathTests) ... ok
testModf (test.test_math.MathTests) ... ok
testPow (test.test_math.MathTests) ... ok
testRadians (test.test_math.MathTests) ... ok
testSin (test.test_math.MathTests) ... ok
testSinh (test.test_math.MathTests) ... ok
testSqrt (test.test_math.MathTests) ... ok
testTan (test.test_math.MathTests) ... ok
testTanh (test.test_math.MathTests) ... ok
test_exceptions (test.test_math.MathTests) ... ok
test_mtestfile (test.test_math.MathTests) ... FAIL
test_testfile (test.test_math.MathTests) ... ok
test_trunc (test.test_math.MathTests) ... ok
Doctest: ieee754.txt ... ok
======================================================================
FAIL: test_mtestfile (test.test_math.MathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/salman/svn/python/trunk/Lib/test/test_math.py", line
1016, in test_mtestfile
'\n '.join(failures))
AssertionError: Failures in test_mtestfile:
expm10302:expm1(709.7827128932839): expected 1.797693134682424e+308,
got 'OverflowError'
----------------------------------------------------------------------
Ran 40 tests in 2.273s
FAILED (failures=1)
test test_math failed -- Traceback (most recent call last):
File "/Users/salman/svn/python/trunk/Lib/test/test_math.py", line
1016, in test_mtestfile
'\n '.join(failures))
AssertionError: Failures in test_mtestfile:
expm10302:expm1(709.7827128932839): expected 1.797693134682424e+308,
got 'OverflowError'
1 test failed:
test_math
----------
components: Tests
messages: 96860
nosy: slmnhq
severity: normal
status: open
title: tes_math fails Mac OS X 10.4 due to OverflowError in test_mtestfile
type: performance
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7575>
_______________________________________
From report at bugs.python.org Fri Dec 25 13:40:19 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 25 Dec 2009 12:40:19 +0000
Subject: [New-bugs-announce] [issue7576] Avoid warnings in
PyModuleDef_HEAD_INIT
In-Reply-To: <1261744819.66.0.987087888755.issue7576@psf.upfronthosting.co.za>
Message-ID: <1261744819.66.0.987087888755.issue7576@psf.upfronthosting.co.za>
New submission from Ronald Oussoren <ronaldoussoren at mac.com>:
When running GCC with warnings the compiler can warn about incomplete
structure initializers. This gives spurious warnings when initializing a
PyModuleDef structure using PyModuleDef_HEAD_INIT
The attached patchs changes PyModuleDef_HEAD_INIT to explicitly
initialize all fields in PyModuleDef_Base.
An example warning that is silenced by this patch:
Modules/objc/test/structpointer2.m:19: warning: missing initializer
Modules/objc/test/structpointer2.m:19: warning: (near initialization for
?mod_module.m_base.m_init?)
----------
files: moduleobject-init-warnings.patch
keywords: needs review, patch, patch
messages: 96881
nosy: ronaldoussoren
priority: normal
severity: normal
stage: patch review
status: open
title: Avoid warnings in PyModuleDef_HEAD_INIT
type: compile error
versions: Python 3.2
Added file: http://bugs.python.org/file15672/moduleobject-init-warnings.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7576>
_______________________________________
From report at bugs.python.org Sat Dec 26 16:11:56 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 26 Dec 2009 15:11:56 +0000
Subject: [New-bugs-announce] [issue7577] documention buglet
In-Reply-To: <1261840316.44.0.384020679104.issue7577@psf.upfronthosting.co.za>
Message-ID: <1261840316.44.0.384020679104.issue7577@psf.upfronthosting.co.za>
New submission from Ronald Oussoren <ronaldoussoren at mac.com>:
The documentation for bf_getbuffer at <http://www.python.org/doc/3.1/c-
api/typeobj.html#buffer-object-structures> claims:
<quote>
The signature of getbufferproc is int (PyObject *obj, PyObject *view,
int flags). obj is the object to export, view is the Py_buffer struct to
fill
</quote>
This is incorrect, the 'view' argument has type 'Py_buffer*'.
The same issue is also present in the 3.2 documentation (and I haven't
checked the 2.6/2.7 docs yet)
----------
assignee: georg.brandl
components: Documentation
keywords: easy
messages: 96889
nosy: georg.brandl, ronaldoussoren
severity: normal
status: open
title: documention buglet
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7577>
_______________________________________
From report at bugs.python.org Sat Dec 26 21:48:36 2009
From: report at bugs.python.org (Baptiste Lepilleur)
Date: Sat, 26 Dec 2009 20:48:36 +0000
Subject: [New-bugs-announce] [issue7578] Behavio of operations on a closed
file object is not documented correctly
In-Reply-To: <1261860516.82.0.572008344206.issue7578@psf.upfronthosting.co.za>
Message-ID: <1261860516.82.0.572008344206.issue7578@psf.upfronthosting.co.za>
New submission from Baptiste Lepilleur <blep at users.sourceforge.net>:
The io.IOBase class doc says:
"""Note that calling any method (even inquiries) on a closed stream is
undefined. Implementations may raise IOError in this case."""
But the io.IOBase.close() method document says:
"""Once the file is closed, any operation on the file (e.g. reading or
writing) will raise an IOError."""
which unlike the class doc is not conditional about the behavior...
Experimentation (see below) show that I get a ValueError in practice
(python 3.1, but also true for 2.6) with io.BufferedWriter and
io.StringIO objects.
>>> with open( 'dummy', 'wb') as f:
... pass
...
>>> f.write( b'' )
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: write to closed file
>>> f.writable()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: I/O operation on closed file
>>> import io
>>> s = io.StringIO()
>>> s.close()
>>> s.read()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: I/O operation on closed file
----------
assignee: georg.brandl
components: Documentation
messages: 96892
nosy: blep, georg.brandl
severity: normal
status: open
title: Behavio of operations on a closed file object is not documented correctly
versions: Python 2.6, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7578>
_______________________________________
From report at bugs.python.org Sat Dec 26 22:29:29 2009
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 26 Dec 2009 21:29:29 +0000
Subject: [New-bugs-announce] [issue7579] Patch to add docstrings to msvcrt
In-Reply-To: <1261862969.81.0.926821098705.issue7579@psf.upfronthosting.co.za>
Message-ID: <1261862969.81.0.926821098705.issue7579@psf.upfronthosting.co.za>
New submission from Brian Curtin <curtin at acm.org>:
Patch to provide docstrings throughout the msvcrt module.
----------
assignee: georg.brandl
components: Documentation, Windows
files: msvcrt_docstrings.diff
keywords: patch
messages: 96893
nosy: brian.curtin, georg.brandl
severity: normal
status: open
title: Patch to add docstrings to msvcrt
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15676/msvcrt_docstrings.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7579>
_______________________________________
From report at bugs.python.org Sun Dec 27 05:02:05 2009
From: report at bugs.python.org (Ben Kaplan)
Date: Sun, 27 Dec 2009 04:02:05 +0000
Subject: [New-bugs-announce] [issue7580] distutils makefile from python.org
installer doesn't work on OS X Snow Leopard
In-Reply-To: <1261886525.19.0.539991282646.issue7580@psf.upfronthosting.co.za>
Message-ID: <1261886525.19.0.539991282646.issue7580@psf.upfronthosting.co.za>
New submission from Ben Kaplan <benjamin.kaplan at case.edu>:
Comes from this thread on comp.lang.python:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/e15915df2e9cdd9/
The Makefile for distutils in the Mac binary for Python 3.1 specifies
the use of the OS X 10.4u SDK. However, XCode only includes the SDK for
the newest two versions of OS X, currently 10.5 and 10.6. This causes
build problems with gmpy on OS X Snow Leopard and the newest XCode. It
probably will also cause problems on other libraries that are compiled
using distutils but I've seen no other reports of issues. I don't know
enough about makefiles to come up with a patch that would work on all
supported versions of OS X.
The offending code is line 118 in the Makefile, which installs itself in
/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/config/Makefile.
The line is
UNIVERSALSDK=/Developer/SDKs/MacOSX10.4u.sdk
Here's a copy of Mensanator's errors:
$ /Library/Frameworks/Python.framework/Versions/3.1/bin/python3
setup.py install
running install
running build
running build_ext
building 'gmpy' extension
creating build/temp.macosx-10.3-fat-3.1
creating build/temp.macosx-10.3-fat-3.1/src
Compiling with an SDK that doesn't seem to exist: /Developer/SDKs/
MacOSX10.4u.sdk
Please check your Xcode installation
gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -
fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 -I./src -I/
opt/local/include -I/Library/Frameworks/Python.framework/Versions/3.1/
include/python3.1 -c src/gmpy.c -o build/temp.macosx-10.3-fat-3.1/src/
gmpy.o
In file included from src/gmpy.c:206:
/Library/Frameworks/Python.framework/Versions/3.1/include/python3.1/
Python.h:11:20: error: limits.h: No such file or directory
/Library/Frameworks/Python.framework/Versions/3.1/include/python3.1/
Python.h:14:2: error: #error "Something's broken. UCHAR_MAX should be
defined in limits.h."
/Library/Frameworks/Python.framework/Versions/3.1/include/python3.1/
Python.h:18:
----------
assignee: tarek
components: Distutils, Installation, Macintosh
messages: 96896
nosy: bskaplan, tarek
severity: normal
status: open
title: distutils makefile from python.org installer doesn't work on OS X Snow Leopard
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7580>
_______________________________________
From report at bugs.python.org Sun Dec 27 12:43:47 2009
From: report at bugs.python.org (WANG Lu)
Date: Sun, 27 Dec 2009 11:43:47 +0000
Subject: [New-bugs-announce] [issue7581] incomplete doc of zlib
In-Reply-To: <1261914227.57.0.480854340776.issue7581@psf.upfronthosting.co.za>
Message-ID: <1261914227.57.0.480854340776.issue7581@psf.upfronthosting.co.za>
New submission from WANG Lu <coolwanglu at gmail.com>:
Python version: 2.6.4 r264:75706 (ubuntu 9.10)
I'm working on zlib, and have been busy in finding a way of specify the
window size of compression.
After wasting minutes in python online doc, I google and find the way:
zlib.compressobj(level, method, window_size, mem_level)
However, in both online doc and build-in doc, only the first parameter
'level' is mentioned. This is too bad.
And I wonder if there are more missing ones.
----------
assignee: georg.brandl
components: Documentation
messages: 96906
nosy: coolwanglu, georg.brandl
severity: normal
status: open
title: incomplete doc of zlib
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7581>
_______________________________________
From report at bugs.python.org Sun Dec 27 16:57:58 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 27 Dec 2009 15:57:58 +0000
Subject: [New-bugs-announce] [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
New submission from anatoly techtonik <techtonik at gmail.com>:
make diff.py produce unified diffs with ISO 8601 timestamps
Currently generated timestamps are difficult to separate from filename
when parsing if you don't know that the diff was generated by diff.by
This patch make diff.py output more standard compliant by including ISO
8601 timestamps that also conform to RFC 3339 profile for timestamp format
on the internet.
----------
components: Demos and Tools
files: diff.py_iso_timestamps.diff
keywords: patch
messages: 96912
nosy: techtonik
severity: normal
status: open
title: [patch] diff.py to use iso timestamp
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15678/diff.py_iso_timestamps.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7582>
_______________________________________
From report at bugs.python.org Sun Dec 27 17:50:32 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 27 Dec 2009 16:50:32 +0000
Subject: [New-bugs-announce] [issue7583] doctest should normalize tabs when
comparing output
In-Reply-To: <1261932632.12.0.972907709846.issue7583@psf.upfronthosting.co.za>
Message-ID: <1261932632.12.0.972907709846.issue7583@psf.upfronthosting.co.za>
New submission from anatoly techtonik <techtonik at gmail.com>:
Since 2.4 doctest converts all tabs to 8-space sequences in test source.
It should do the same with output it receives for comparison. Right now
there is no way to write a correct doctest if the output includes tab
character. See attached doctabtest.py
This change would be backwards compatible, because all tests with tabs are
either fail or run with doctest.NORMALIZE_WHITESPACE flag, which is
usually inappropriate for doctest cases that involve tab formatting.
----------
components: Tests
files: doctabtest.py
messages: 96914
nosy: techtonik
severity: normal
status: open
title: doctest should normalize tabs when comparing output
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15679/doctabtest.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7583>
_______________________________________
From report at bugs.python.org Sun Dec 27 20:18:08 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 27 Dec 2009 19:18:08 +0000
Subject: [New-bugs-announce] [issue7584] datetime.rfcformat() for Date and
Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
New submission from anatoly techtonik <techtonik at gmail.com>:
RFC 3339 defines a standard for Date and Time on the Internet.
http://www.ietf.org/rfc/rfc3339.txt Given that Python is increasingly
popular on the Internet is should include convenience function to
generate RFC 3339 timestamps in standard library.
It is impossible to generate RFC 3339 timestamps (that are also valid
ISO 8601 timestamps) with datetime.strftime() alone, so the following
code should be used:
import datetime
def rfcformat(dt):
""" Output datetime in RFC 3339 format that is also valid ISO 8601
timestamp representation"""
if dt.tzinfo is None:
suffix = "-00:00"
else:
suffix = dt.strftime("%z")
suffix = suffix[:-2] + ":" + suffix[-2:]
return dt.strftime("%Y-%m-%dT%H:%M:%S") + suffix
----------
components: Library (Lib)
messages: 96917
nosy: techtonik
severity: normal
status: open
title: datetime.rfcformat() for Date and Time on the Internet
versions: Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7584>
_______________________________________
From report at bugs.python.org Sun Dec 27 21:57:38 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 27 Dec 2009 20:57:38 +0000
Subject: [New-bugs-announce] [issue7585] [patch] difflib should separate
filename from timestamp with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
New submission from anatoly techtonik <techtonik at gmail.com>:
The patch inserts \t character between filename and timestamp in unified
and context diff headers.
According to specification by Guido Van Rossum =)
http://www.artima.com/weblogs/viewpost.jsp?thread=164293
And de-facto output from various tools
http://code.google.com/p/python-patch/source/browse/#svn/trunk/doc
And the common sense
--- that it is easier to split this stuff
+++ than this one into filename + timestamp
--- diff.py Sun Dec 27 16:08:28 2009
+++ trunk/diff.py Sun Dec 27 15:46:58 2009
----------
components: Library (Lib)
files: difflib.tab_separated_filename.diff
keywords: patch
messages: 96924
nosy: techtonik
severity: normal
status: open
title: [patch] difflib should separate filename from timestamp with tab
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15682/difflib.tab_separated_filename.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7585>
_______________________________________
From report at bugs.python.org Mon Dec 28 01:34:21 2009
From: report at bugs.python.org (Robert Xiao)
Date: Mon, 28 Dec 2009 00:34:21 +0000
Subject: [New-bugs-announce] [issue7586] Typo in collections documentation
In-Reply-To: <1261960461.08.0.700949009831.issue7586@psf.upfronthosting.co.za>
Message-ID: <1261960461.08.0.700949009831.issue7586@psf.upfronthosting.co.za>
New submission from Robert Xiao <nneonneo at gmail.com>:
In the documentation for the namedtuple
(http://docs.python.org/3.1/library/collections.html), the following
phrase is incorrect:
The subclass shown above sets __slots__ to an empty tuple. This keeps
keep memory requirements low by preventing the creation of instance
dictionaries.
It should read
The subclass shown above sets __slots__ to an empty tuple. This helps
keep memory requirements low by preventing the creation of instance
dictionaries.
or
The subclass shown above sets __slots__ to an empty tuple. This keeps
memory requirements low by preventing the creation of instance dictionaries.
(either change "keeps" to "helps", or delete the next "keep").
----------
assignee: georg.brandl
components: Documentation
messages: 96931
nosy: georg.brandl, nneonneo
severity: normal
status: open
title: Typo in collections documentation
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7586>
_______________________________________
From report at bugs.python.org Mon Dec 28 15:25:57 2009
From: report at bugs.python.org (Anurag)
Date: Mon, 28 Dec 2009 14:25:57 +0000
Subject: [New-bugs-announce] [issue7587] Python 3.1.1 source build issues
In-Reply-To: <1262010357.46.0.74375888558.issue7587@psf.upfronthosting.co.za>
Message-ID: <1262010357.46.0.74375888558.issue7587@psf.upfronthosting.co.za>
New submission from Anurag <anurag.sharma.101 at gmail.com>:
Hi
I downloaded the source for Python-3.1.1 for windows x86. I followed the
instructions in the PCbuild\Readme.txt file to build python
Basically, all I did was
1. Open the ?PCbuild\pcbuild.sln? in VS2008.
2. Select the ?Win32? as Solution Platform and ?Release? as Solution
Configuration
3. Build Solution (F6)
I got the following error messages
Error 1 fatal error C1083: Cannot open source file:
'..\..\sqlite-3.5.9\sqlite3.c': No such file or directory c1
sqlite3
Error 11 fatal error C1083: Cannot open include file:
'bzlib.h': No such file or directory
Desktop\Python-3.1.1__\Python-3.1.1\Modules\bz2module.c 12 bz2
Error 12 fatal error C1083: Cannot open include file:
'tcl.h': No such file or directory
Desktop\Python-3.1.1__\Python-3.1.1\Modules\_tkinter.c 66
_tkinter
Error 13 fatal error C1083: Cannot open include file:
'tcl.h': No such file or directory
Desktop\Python-3.1.1__\Python-3.1.1\Modules\tkappinit.c 16
_tkinter
Error 14 fatal error C1083: Cannot open include file:
'sqlite3.h': No such file or directory
desktop\python-3.1.1__\python-3.1.1\modules\_sqlite\connection.h 33
_sqlite3
Error 15 error PRJ0019: A tool returned an error code
from "Performing Pre-Build Event..." _ssl _ssl
Error 16 fatal error C1083: Cannot open include file:
'sqlite3.h': No such file or directory
desktop\python-3.1.1__\python-3.1.1\modules\_sqlite\connection.h 33
_sqlite3
Error 17 fatal error C1083: Cannot open include file:
'sqlite3.h': No such file or directory
desktop\python-3.1.1__\python-3.1.1\modules\_sqlite\connection.h 33
_sqlite3
Error 18 fatal error C1083: Cannot open include file:
'sqlite3.h': No such file or directory
desktop\python-3.1.1__\python-3.1.1\modules\_sqlite\connection.h 33
_sqlite3
Error 19 fatal error C1083: Cannot open include file:
'sqlite3.h': No such file or directory
desktop\python-3.1.1__\python-3.1.1\modules\_sqlite\connection.h 33
_sqlite3
Error 20 fatal error C1083: Cannot open include file:
'sqlite3.h': No such file or directory
desktop\python-3.1.1__\python-3.1.1\modules\_sqlite\connection.h 33
_sqlite3
Error 21 fatal error C1083: Cannot open include file:
'sqlite3.h': No such file or directory
desktop\python-3.1.1__\python-3.1.1\modules\_sqlite\connection.h 33
_sqlite3
Error 23 error PRJ0019: A tool returned an error code
from "Performing Pre-Build Event..." _hashlib
_hashlib
To fix the missing sqllite code issue, I did the following
1. I created a folder named "sqlite-3.5.9" under "Modules".
2. I downloaded the code for sqlite-3.5.9 (This code is attached).
3. I copied the downlaoded code for sqlite-3.5.9 under the following
directory
Desktop\Python-3.1.1\Python-3.1.1\Modules\sqlite-3.5.9
4. From the newly copied files, I copied the "sqlite3.h" file to the
following folder
Desktop\Python-3.1.1\Python-3.1.1\Modules\_sqlite
After this I tried cleaned and build again.
Errors reduced. I got the following errors this time.
Error 1 fatal error C1083: Cannot open source file:
'..\..\sqlite-3.5.9\sqlite3.c': No such file or directory c1 sqlite3
Error 2 fatal error C1083: Cannot open include file: 'bzlib.h': No such
file or directory
Desktop\Python-3.1.1\Python-3.1.1\Modules\bz2module.c 12 bz2
Error 3 fatal error C1083: Cannot open include file: 'tcl.h': No such
file or directory
Desktop\Python-3.1.1\Python-3.1.1\Modules\_tkinter.c 66 _tkinter
Error 4 fatal error C1083: Cannot open include file: 'tcl.h': No such
file or directory
Desktop\Python-3.1.1\Python-3.1.1\Modules\tkappinit.c 16 _tkinter
Error 5 error PRJ0019: A tool returned an error code from "Performing
Pre-Build Event..." _ssl _ssl
Error 6 fatal error LNK1181: cannot open input file '.\sqlite3.lib'
_sqlite3 _sqlite3
Error 7 error PRJ0019: A tool returned an error code from "Performing
Pre-Build Event..." _hashlib _hashlib
Can someone help me fix these errors.
Thanks in advance
Thanks
Anurag
----------
components: Build
files: sqlite-source-3_5_9.zip
messages: 96947
nosy: sharmaag
severity: normal
status: open
title: Python 3.1.1 source build issues
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file15683/sqlite-source-3_5_9.zip
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7587>
_______________________________________
From report at bugs.python.org Mon Dec 28 15:30:41 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 28 Dec 2009 14:30:41 +0000
Subject: [New-bugs-announce] [issue7588] unittest.TestCase.shortDescription
isn't short anymore
In-Reply-To: <1262010641.75.0.70494250568.issue7588@psf.upfronthosting.co.za>
Message-ID: <1262010641.75.0.70494250568.issue7588@psf.upfronthosting.co.za>
New submission from Jean-Paul Calderone <exarkun at divmod.com>:
Sometime between Python 2.6 and 2.7a1, the
unittest.TestCase.shortDescription method changed from returning just
the test method name to the test method name, in parentheses, the fully
qualified Python name of the test case.
This breaks several Twisted unit tests and, I think, goes against the
expectations users have of the "shortDescription" method.
----------
components: Library (Lib)
messages: 96948
nosy: exarkun
severity: normal
status: open
title: unittest.TestCase.shortDescription isn't short anymore
type: behavior
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7588>
_______________________________________
From report at bugs.python.org Mon Dec 28 16:14:51 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 28 Dec 2009 15:14:51 +0000
Subject: [New-bugs-announce] [issue7589] setup.py shouldn't try to build nis
module when nis headers aren't available
In-Reply-To: <1262013291.35.0.301750948413.issue7589@psf.upfronthosting.co.za>
Message-ID: <1262013291.35.0.301750948413.issue7589@psf.upfronthosting.co.za>
New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:
setup.py shouldn't try to build nis module when nis headers aren't
available (e.g. on uclibc systems). I'm attaching the patch for
setup.py.
----------
components: Build
files: python-nis.patch
keywords: patch
messages: 96954
nosy: Arfrever
severity: normal
status: open
title: setup.py shouldn't try to build nis module when nis headers aren't available
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15685/python-nis.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7589>
_______________________________________
From report at bugs.python.org Mon Dec 28 21:06:49 2009
From: report at bugs.python.org (July Tikhonov)
Date: Mon, 28 Dec 2009 20:06:49 +0000
Subject: [New-bugs-announce] [issue7590] 'exceptions' module mentioned in
documentation
In-Reply-To: <1262030809.1.0.0623559052096.issue7590@psf.upfronthosting.co.za>
Message-ID: <1262030809.1.0.0623559052096.issue7590@psf.upfronthosting.co.za>
New submission from July Tikhonov <july.tikh at gmail.com>:
As I can see, 'exceptions' module does not exist in py3k.
But it is mentioned in documentation
http://docs.python.org/dev/py3k/library/exceptions.html
"The exceptions are defined in the module exceptions. This module never
needs to be imported explicitly: the exceptions are provided in the
built-in namespace as well as the exceptions module."
----------
assignee: georg.brandl
components: Documentation
messages: 96965
nosy: July, georg.brandl
severity: normal
status: open
title: 'exceptions' module mentioned in documentation
type: behavior
versions: 3rd party
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7590>
_______________________________________
From report at bugs.python.org Mon Dec 28 23:00:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Dec 2009 22:00:46 +0000
Subject: [New-bugs-announce] [issue7591] test_get_platform fails on 3.1
In-Reply-To: <1262037646.69.0.736815129849.issue7591@psf.upfronthosting.co.za>
Message-ID: <1262037646.69.0.736815129849.issue7591@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
This started happening recently on some 3.1 buildbots:
======================================================================
FAIL: test_get_platform (distutils.tests.test_util.UtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/home/doko/buildarea/3.1.klose-debian-alpha/build/Lib/distutils/tests/test_util.py",
line 99, in test_get_platform
self.assertEquals(get_platform(), 'macosx-10.3-i386')
AssertionError: 'macosx-10.3-x86_64' != 'macosx-10.3-i386'
----------------------------------------------------------------------
----------
assignee: tarek
components: Distutils, Tests
messages: 96969
nosy: pitrou, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_get_platform fails on 3.1
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7591>
_______________________________________
From report at bugs.python.org Tue Dec 29 00:55:24 2009
From: report at bugs.python.org (Michael Newman)
Date: Mon, 28 Dec 2009 23:55:24 +0000
Subject: [New-bugs-announce] [issue7592] ssl module documentation:
SSLSocket.unwrap description shown twice
In-Reply-To: <1262044524.74.0.400601888714.issue7592@psf.upfronthosting.co.za>
Message-ID: <1262044524.74.0.400601888714.issue7592@psf.upfronthosting.co.za>
New submission from Michael Newman <michael.b.newman at gmail.com>:
For the "ssl" module documentation at:
http://docs.python.org/3.1/library/ssl.html
I noticed that "SSLSocket.unwrap()" description is listed twice in the
"17.3.2. SSLSocket Objects" section.
----------
assignee: georg.brandl
components: Documentation
messages: 96977
nosy: georg.brandl, mnewman
severity: normal
status: open
title: ssl module documentation: SSLSocket.unwrap description shown twice
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7592>
_______________________________________
From report at bugs.python.org Tue Dec 29 03:11:31 2009
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 29 Dec 2009 02:11:31 +0000
Subject: [New-bugs-announce] [issue7593] Computed-goto patch
In-Reply-To: <1262052691.46.0.772398622751.issue7593@psf.upfronthosting.co.za>
Message-ID: <1262052691.46.0.772398622751.issue7593@psf.upfronthosting.co.za>
New submission from A.M. Kuchling <lists at amk.ca>:
Part of Unladen Swallow's roadmap is to use a threaded-interpreter
technique for the regular expression engine. That sounded like an
interesting idea, so I went ahead and tried to implement it.
The current patch is attached. To try it: run configure
--with-computed-gotos; apply the patch; and compile Python.
Still to do:
* Benchmarking, to determine if it's actually an improvement.
* Possibly integrate construction of the Modules/re_opcodes.h file into
the build process. The current file is supplied; to rebuild it, run
"python Modules/makereopcodes.py > Modules/re_opcodes.h". (But it only
needs rebuilding if you add new regex opcodes, which is rarely done --
maybe it's sufficient to include a reminder to update it plus the script).
----------
components: Regular Expressions
messages: 96984
nosy: akuchling
severity: normal
status: open
title: Computed-goto patch
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7593>
_______________________________________
From report at bugs.python.org Tue Dec 29 09:07:41 2009
From: report at bugs.python.org (Brian Harring)
Date: Tue, 29 Dec 2009 08:07:41 +0000
Subject: [New-bugs-announce] [issue7594] shlex refactoring
In-Reply-To: <1262074061.97.0.349318449782.issue7594@psf.upfronthosting.co.za>
Message-ID: <1262074061.97.0.349318449782.issue7594@psf.upfronthosting.co.za>
New submission from Brian Harring <ferringb at gmail.com>:
Currently, shlex.shlex's internal read_token is a bit of a nasty mess to
follow and pretty poorly performant.
The refactoring I'll be attaching essentially inverts the state machine
approach read_token uses- instead, converting it over to a more
procedural set of loops. The benefits of this is that it's far, far
easier to track what the code is actually doing and the performance goes
up fairly drastically via tightening the various for loops (for example,
if doing quoting, you only care about escapes and the terminating quote-
thus a loop there).
End result, the refactored code actually has whitespace in it and still
is shorter- specifically the tokenenizer was converted into a generator
to preserve state internally, thus simplifying the code flow immensely.
Beyond that, this should still be api compatible... and is 2x faster,
passing tests.
Note this patch is cut against 2.6.4; assuming folks are happy w/ the
general approach, I'll rebase it to py3k trunk.
>From there, I'd be willing to tackle the other shlex issues where
applicable, but personally... not w/out the refactoring base, since that
state machine is a pita to trace out.
----------
components: Library (Lib)
files: shlex-py2.6.4-20091229.patch
keywords: patch
messages: 96987
nosy: ferringb
severity: normal
status: open
title: shlex refactoring
type: performance
versions: Python 2.6, Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15692/shlex-py2.6.4-20091229.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7594>
_______________________________________
From report at bugs.python.org Tue Dec 29 16:28:06 2009
From: report at bugs.python.org (Chad Whitacre)
Date: Tue, 29 Dec 2009 15:28:06 +0000
Subject: [New-bugs-announce] [issue7595] Doc typo for select.kevent()
In-Reply-To: <1262100486.01.0.362584684262.issue7595@psf.upfronthosting.co.za>
Message-ID: <1262100486.01.0.362584684262.issue7595@psf.upfronthosting.co.za>
New submission from Chad Whitacre <chad at zetaweb.com>:
I believe the default "flags" argument to select.kevent() should be given
as KQ_EV_ADD, not KQ_ADD.
http://docs.python.org/dev/py3k/library/select.html
----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 96996
nosy: georg.brandl, whit537
severity: normal
status: open
title: Doc typo for select.kevent()
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7595>
_______________________________________
From report at bugs.python.org Tue Dec 29 22:18:03 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Dec 2009 21:18:03 +0000
Subject: [New-bugs-announce] [issue7596] test_logging sometimes fails
In-Reply-To: <1262121483.71.0.771852703011.issue7596@psf.upfronthosting.co.za>
Message-ID: <1262121483.71.0.771852703011.issue7596@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
test_logging sometimes fails with the following error, e.g. on the
buildbots (*):
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
File
"/home/buildbot/cpython-ucs4/trunk.pitrou-ubuntu-wide/build/Lib/atexit.py",
line 24, in _run_exitfuncs
func(*targs, **kargs)
File
"/home/buildbot/cpython-ucs4/trunk.pitrou-ubuntu-wide/build/Lib/logging/__init__.py",
line 1556, in shutdown
h.flush()
AttributeError: 'NoneType' object has no attribute 'flush'
Error in sys.exitfunc:
Traceback (most recent call last):
File
"/home/buildbot/cpython-ucs4/trunk.pitrou-ubuntu-wide/build/Lib/atexit.py",
line 24, in _run_exitfuncs
func(*targs, **kargs)
File
"/home/buildbot/cpython-ucs4/trunk.pitrou-ubuntu-wide/build/Lib/logging/__init__.py",
line 1556, in shutdown
h.flush()
AttributeError: 'NoneType' object has no attribute 'flush'
[874213 refs]
(*)
http://www.python.org/dev/buildbot/all/builders/AMD64%20Ubuntu%20wide%20trunk/builds/185/steps/test/logs/stdio
----------
assignee: vinay.sajip
components: Library (Lib), Tests
messages: 97005
nosy: pitrou, vinay.sajip
priority: high
severity: normal
stage: needs patch
status: open
title: test_logging sometimes fails
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/issue7596>
_______________________________________
From report at bugs.python.org Wed Dec 30 11:12:23 2009
From: report at bugs.python.org (Kan-Ru Chen)
Date: Wed, 30 Dec 2009 10:12:23 +0000
Subject: [New-bugs-announce] [issue7597] curses.use_env implementation error
In-Reply-To: <1262167943.14.0.464762801223.issue7597@psf.upfronthosting.co.za>
Message-ID: <1262167943.14.0.464762801223.issue7597@psf.upfronthosting.co.za>
New submission from Kan-Ru Chen <kanru at kanru.info>:
According to doc:
http://docs.python.org/library/curses.html#curses.use_env
curses.use_env() must be called before initscr(), curses man page also
says so.
But python gives error: _curses.error: must call initscr() first
test.py is the test program, the output should change if your term
size changed
test_ctypes.py shows the desired behavior.
ps. curses.COLS and curses.LINES doesn't change, but that's another
story.
----------
components: Extension Modules
files: test.py
messages: 97024
nosy: kanru
severity: normal
status: open
title: curses.use_env implementation error
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15698/test.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7597>
_______________________________________
From report at bugs.python.org Wed Dec 30 11:38:49 2009
From: report at bugs.python.org (sh.00)
Date: Wed, 30 Dec 2009 10:38:49 +0000
Subject: [New-bugs-announce] [issue7598] Cannot install,
problems with assembly?
In-Reply-To: <1262169529.95.0.0672707986414.issue7598@psf.upfronthosting.co.za>
Message-ID: <1262169529.95.0.0672707986414.issue7598@psf.upfronthosting.co.za>
New submission from sh.00 <sh96films at yahoo.it>:
When the installation is near the end, suddently I get the error message.
Python is not the only program that cannot be installed correctly,and the
error message is absolutely the same. Can anybody help me?
----------
files: SH_scr^001 Dec. 30 02.35.jpg
messages: 97025
nosy: sh.00
severity: normal
status: open
title: Cannot install, problems with assembly?
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file15701/SH_scr^001 Dec. 30 02.35.jpg
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7598>
_______________________________________
From report at bugs.python.org Wed Dec 30 15:01:35 2009
From: report at bugs.python.org (Jakub Wilk)
Date: Wed, 30 Dec 2009 14:01:35 +0000
Subject: [New-bugs-announce] [issue7599] (c)ElementTree can produce invalid
XML
In-Reply-To: <1262181695.14.0.680778590248.issue7599@psf.upfronthosting.co.za>
Message-ID: <1262181695.14.0.680778590248.issue7599@psf.upfronthosting.co.za>
New submission from Jakub Wilk <ubanus at users.sf.net>:
$ cat buggy.py
import sys
from xml.etree import ElementTree as et
root = et.Element('root')
root.text = u'\x07'
et.ElementTree(root).write(sys.stdout)
$ python buggy.py | xmllint -
-:1: parser error : PCDATA invalid Char value 7
<root></root>
^
----------
components: Library (Lib)
messages: 97032
nosy: jwilk
severity: normal
status: open
title: (c)ElementTree can produce invalid XML
type: behavior
versions: Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7599>
_______________________________________
From report at bugs.python.org Wed Dec 30 15:39:36 2009
From: report at bugs.python.org (mhh91)
Date: Wed, 30 Dec 2009 14:39:36 +0000
Subject: [New-bugs-announce] [issue7600] interpreter crashes before start
In-Reply-To: <1262183976.04.0.961463499173.issue7600@psf.upfronthosting.co.za>
Message-ID: <1262183976.04.0.961463499173.issue7600@psf.upfronthosting.co.za>
New submission from mhh91 <mhh91 at hotmail.com>:
when I set my Locale to "Arabic(Egypt)" on Windows 7,Python does not
start,giving this Error :
Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: cp720
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
----------
components: Interpreter Core
messages: 97033
nosy: mhh91
severity: normal
status: open
title: interpreter crashes before start
type: crash
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7600>
_______________________________________
From report at bugs.python.org Wed Dec 30 17:41:24 2009
From: report at bugs.python.org (=?utf-8?b?Sm96ZWYgR8OhYm9yw61r?=)
Date: Wed, 30 Dec 2009 16:41:24 +0000
Subject: [New-bugs-announce] [issue7601] Installation - 2 tests failed:
test_cmd_line test_xmlrpc
In-Reply-To: <1262191284.36.0.167842926616.issue7601@psf.upfronthosting.co.za>
Message-ID: <1262191284.36.0.167842926616.issue7601@psf.upfronthosting.co.za>
New submission from Jozef G?bor?k <jozef.gaborik at gmail.com>:
I installed python 3.1.1 on Ubuntu 9.10. When I wrote "make test" I got:
...
test_cmd
test_cmd_line
test test_cmd_line failed -- Traceback (most recent call last):
File "/home/gaborik/Stiahnut?/Python-3.1.1/Lib/test/
test_cmd_line.py", line 181, in test_large_PYTHONPATH
self.assertTrue(path1.encode('ascii') in stdout)
AssertionError: False is not True
test_cmd_line_script
...
AND:
...
test_xml_etree
test_xml_etree_c
test_xmlrpc
Traceback (most recent call last):
File "/home/gaborik/Stiahnut?/Python-3.1.1/Lib/xmlrpc/server.py",
line 448, in do_POST
size_remaining = int(self.headers["content-length"])
ValueError: invalid literal for int() with base 10: 'I am broken'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/gaborik/Stiahnut?/Python-3.1.1/Lib/socketserver.py", line
281, in _handle_request_noblock
self.process_request(request, client_address)
File "/home/gaborik/Stiahnut?/Python-3.1.1/Lib/socketserver.py", line
307, in process_request
self.finish_request(request, client_address)
File "/home/gaborik/Stiahnut?/Python-3.1.1/Lib/socketserver.py", line
320, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "/home/gaborik/Stiahnut?/Python-3.1.1/Lib/socketserver.py", line
614, in __init__
self.handle()
File "/home/gaborik/Stiahnut?/Python-3.1.1/Lib/http/server.py", line
352, in handle
self.handle_one_request()
File "/home/gaborik/Stiahnut?/Python-3.1.1/Lib/http/server.py", line
346, in handle_one_request
method()
File "/home/gaborik/Stiahnut?/Python-3.1.1/Lib/xmlrpc/server.py",
line 472, in do_POST
self.send_header("X-traceback", traceback.format_exc())
File "/home/gaborik/Stiahnut?/Python-3.1.1/Lib/http/server.py", line
410, in send_header
self.wfile.write(("%s: %s\r\n" % (keyword, value)).encode('ASCII',
'strict'))
UnicodeEncodeError: 'ascii' codec can't encode character '\xe9' in
position 78: ordinal not in range(128)
test test_xmlrpc failed -- Traceback (most recent call last):
File "/home/gaborik/Stiahnut?/Python-3.1.1/Lib/test/test_xmlrpc.py",
line 555, in test_fail_with_info
p.pow(6,8)
xmlrpc.client.ProtocolError: <ProtocolError for 127.0.0.1:47884/RPC2:
500 Internal Server Error>
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/gaborik/Stiahnut?/Python-3.1.1/Lib/test/test_xmlrpc.py",
line 562, in test_fail_with_info
self.assertTrue(e.headers.get("X-traceback") is not None)
AssertionError: False is not True
test_xmlrpc_net
test_xmlrpc_net skipped -- Use of the `network' resource not enabled
test_zipfile
test_zipfile64
test_zipfile64 skipped -- test requires loads of disk-space bytes and a
long time to run
test_zipimport
test_zipimport_support
test_zlib
310 tests OK.
2 tests failed:
test_cmd_line test_xmlrpc
23 tests skipped:
test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
test_codecmaps_kr test_codecmaps_tw test_curses test_kqueue
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 linux2.
----------
components: Installation
messages: 97040
nosy: sadhak
severity: normal
status: open
title: Installation - 2 tests failed: test_cmd_line test_xmlrpc
type: compile error
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7601>
_______________________________________
From report at bugs.python.org Wed Dec 30 18:26:18 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 30 Dec 2009 17:26:18 +0000
Subject: [New-bugs-announce] [issue7602] Doc: make clean and make update do
not delete or update Doc/tools
In-Reply-To: <1262193978.06.0.511943108668.issue7602@psf.upfronthosting.co.za>
Message-ID: <1262193978.06.0.511943108668.issue7602@psf.upfronthosting.co.za>
New submission from Florent Xicluna <laxyf at yahoo.fr>:
In the Doc/ directory, the "make ..." commands do not behave as expected.
*make clean*
It should remove all tools in "tools" directory: docutils, jinja2,
pygments, sphinx.
Currently it removes only "tools/sphinx"
*make update*
It is supposed to "update the Subversion checkouts in `tools/`".
Basically, it does "svn update" for each 4 external tools.
But it is pointless, since these directory are sticked to tag versions.
IMHO, it should be an alias for:
"make clean && make checkout" (if *make clean* is fixed)
----------
assignee: georg.brandl
components: Build, Documentation
messages: 97046
nosy: flox, georg.brandl
severity: normal
status: open
title: Doc: make clean and make update do not delete or update Doc/tools
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/issue7602>
_______________________________________
From report at bugs.python.org Wed Dec 30 19:44:09 2009
From: report at bugs.python.org (Thomas Oldbury)
Date: Wed, 30 Dec 2009 18:44:09 +0000
Subject: [New-bugs-announce] [issue7603] There is no 'seq' type
In-Reply-To: <1262198649.61.0.804746779448.issue7603@psf.upfronthosting.co.za>
Message-ID: <1262198649.61.0.804746779448.issue7603@psf.upfronthosting.co.za>
New submission from Thomas Oldbury <thomas at tgohome.com>:
I find myself often writing the following code:
if isinstance(var, (tuple, list, basestring)):
to determine if a var is indexable and iterable.
It would be simpler if there were a 'seq' type which is subclassed into
mutableseq and immutableseq (or something like that). Tuples and strings
would be children of immutableseq. Lists would be children of
mutableseq. Then I can do:
if isinstance(var, seq):
Or to determine if I can edit values I can:
if isinstance(var, mutableseq):
Actually this should probably not be a bug, maybe a PEP... or something.
This is the only thing I can presently think I would really like to
correct in Python, because so far Python is the best language I've ever
had the pleasure to write programs for. Thanks to everyone involved. :)
----------
messages: 97050
nosy: tom66
severity: normal
status: open
title: There is no 'seq' type
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7603>
_______________________________________
From report at bugs.python.org Wed Dec 30 19:46:49 2009
From: report at bugs.python.org (Brian Harring)
Date: Wed, 30 Dec 2009 18:46:49 +0000
Subject: [New-bugs-announce] [issue7604] delattr __slots__ inconsistancy
In-Reply-To: <1262198809.47.0.401971406829.issue7604@psf.upfronthosting.co.za>
Message-ID: <1262198809.47.0.401971406829.issue7604@psf.upfronthosting.co.za>
New submission from Brian Harring <ferringb at gmail.com>:
Everything I've read about __slots__, seen w/ them, etc, they're
effectively just a change in the underlying allocation- yes they can
limit the attributes, but that's about it.
Specifically, for general attribute access/mangling, best I can tell,
they're *supposed* to be exactly equivalent when manipulating the
object- the only difference being the backing store.
That said, delattr against slotted objects vs non slotted differs in a
rather buggy way- even worse, the behaviour differs on slotted classes
dependant on if you're delattr'ing a slotted attr or a nonslotted-
consider the following code.
class nonslotted(object):
pass
class slotted(object):
__slots__ = ("monkeys",)
try:
ns = nonslotted()
assert not hasattr(ns, 'monkeys')
del ns.monkeys
raise AssertionError("this is unreachable")
except AttributeError:
pass
try:
s = slotted()
assert not hasattr(s, 'monkeys')
del s.monkeys
print "slotting causes delattr to not throw an AttributeError"
# and now for the kicker
del s.some_attr_that_is_not_slotted
except AttributeError:
print "so... delattr results in AttributeError on a non-slotted attr,
but throws no AttributeError on a slotted attr..."
I'm guessing this isn't intentional/desired?
Confirmed on py2.6/py3.1 also; that said, I'd assume it affects all
versions of python that support __slots__...
----------
components: Interpreter Core
messages: 97051
nosy: ferringb
severity: normal
status: open
title: delattr __slots__ inconsistancy
versions: Python 2.6, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7604>
_______________________________________
From report at bugs.python.org Wed Dec 30 22:44:36 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Dec 2009 21:44:36 +0000
Subject: [New-bugs-announce] [issue7605] test_cmd_line fails with non-ascii
path
In-Reply-To: <1262209476.63.0.735770885688.issue7605@psf.upfronthosting.co.za>
Message-ID: <1262209476.63.0.735770885688.issue7605@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
I configured my buildbot to use a non-ascii path to the interpreter and
test_cmd_line fails as follows:
======================================================================
FAIL: test_large_PYTHONPATH (test.test_cmd_line.CmdLineTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/home/buildbot/cpython-ucs4-nonascii-???/3.1.pitrou-ubuntu-wide/build/Lib/test/test_cmd_line.py",
line 181, in test_large_PYTHONPATH
self.assertTrue(path1.encode('ascii') in stdout)
AssertionError: False is not True
----------------------------------------------------------------------
----------
components: Library (Lib), Tests
messages: 97062
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_cmd_line fails with non-ascii path
type: behavior
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7605>
_______________________________________
From report at bugs.python.org Wed Dec 30 22:46:36 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Dec 2009 21:46:36 +0000
Subject: [New-bugs-announce] [issue7606] test_xmlrpc fails with non-ascii
path
In-Reply-To: <1262209596.84.0.138157640556.issue7606@psf.upfronthosting.co.za>
Message-ID: <1262209596.84.0.138157640556.issue7606@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
I configured my buildbot to use a non-ascii path to the interpreter and
test_xmlrpc fails as follows:
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 59091)
Traceback (most recent call last):
File
"/home/buildbot/cpython-ucs4-nonascii-???/3.1.pitrou-ubuntu-wide/build/Lib/xmlrpc/server.py",
line 448, in do_POST
size_remaining = int(self.headers["content-length"])
ValueError: invalid literal for int() with base 10: 'I am broken'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File
"/home/buildbot/cpython-ucs4-nonascii-???/3.1.pitrou-ubuntu-wide/build/Lib/socketserver.py",
line 281, in _handle_request_noblock
self.process_request(request, client_address)
File
"/home/buildbot/cpython-ucs4-nonascii-???/3.1.pitrou-ubuntu-wide/build/Lib/socketserver.py",
line 307, in process_request
self.finish_request(request, client_address)
File
"/home/buildbot/cpython-ucs4-nonascii-???/3.1.pitrou-ubuntu-wide/build/Lib/socketserver.py",
line 320, in finish_request
self.RequestHandlerClass(request, client_address, self)
File
"/home/buildbot/cpython-ucs4-nonascii-???/3.1.pitrou-ubuntu-wide/build/Lib/socketserver.py",
line 614, in __init__
self.handle()
File
"/home/buildbot/cpython-ucs4-nonascii-???/3.1.pitrou-ubuntu-wide/build/Lib/http/server.py",
line 352, in handle
self.handle_one_request()
File
"/home/buildbot/cpython-ucs4-nonascii-???/3.1.pitrou-ubuntu-wide/build/Lib/http/server.py",
line 346, in handle_one_request
method()
File
"/home/buildbot/cpython-ucs4-nonascii-???/3.1.pitrou-ubuntu-wide/build/Lib/xmlrpc/server.py",
line 472, in do_POST
self.send_header("X-traceback", traceback.format_exc())
File
"/home/buildbot/cpython-ucs4-nonascii-???/3.1.pitrou-ubuntu-wide/build/Lib/http/server.py",
line 410, in send_header
self.wfile.write(("%s: %s\r\n" % (keyword, value)).encode('ASCII',
'strict'))
UnicodeEncodeError: 'ascii' codec can't encode character '\u20ac' in
position 93: ordinal not in range(128)
----------------------------------------
======================================================================
FAIL: test_fail_with_info (test.test_xmlrpc.FailingServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/home/buildbot/cpython-ucs4-nonascii-???/3.1.pitrou-ubuntu-wide/build/Lib/test/test_xmlrpc.py",
line 555, in test_fail_with_info
p.pow(6,8)
xmlrpc.client.ProtocolError: <ProtocolError for 127.0.0.1:57828/RPC2:
500 Internal Server Error>
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File
"/home/buildbot/cpython-ucs4-nonascii-???/3.1.pitrou-ubuntu-wide/build/Lib/test/test_xmlrpc.py",
line 562, in test_fail_with_info
self.assertTrue(e.headers.get("X-traceback") is not None)
AssertionError: False is not True
----------------------------------------------------------------------
----------
components: Library (Lib), Tests
messages: 97063
nosy: loewis, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_xmlrpc fails with non-ascii path
type: behavior
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7606>
_______________________________________
From report at bugs.python.org Wed Dec 30 23:23:19 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Dec 2009 22:23:19 +0000
Subject: [New-bugs-announce] [issue7607] stringlib fastsearch could be
improved on 64-bit builds
In-Reply-To: <1262211799.19.0.0827970391862.issue7607@psf.upfronthosting.co.za>
Message-ID: <1262211799.19.0.0827970391862.issue7607@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
The fastsearch algorithm uses a 32-bit mask for the boyer-moore
compression table but stores it as a long.
Since longs can be wider than 32 bits on some platforms (especially,
most 64-bit Unixes), the actual mask width could be platform-dependant
so as to improve the efficiency of the algorithm. Using the SIZEOF_LONG
constant would probably do the trick.
----------
components: Interpreter Core
messages: 97065
nosy: flox, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: stringlib fastsearch could be improved on 64-bit builds
type: performance
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7607>
_______________________________________
From report at bugs.python.org Thu Dec 31 00:16:54 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 30 Dec 2009 23:16:54 +0000
Subject: [New-bugs-announce] [issue7608] PyUnicode_FromFormatV handles %R
and %S incorrectly.
In-Reply-To: <1262215014.59.0.531536027959.issue7608@psf.upfronthosting.co.za>
Message-ID: <1262215014.59.0.531536027959.issue7608@psf.upfronthosting.co.za>
New submission from Alexandre Vassalotti <alexandre at peadrop.com>:
It seems PyUnicode_FromFormatV wrongly assumes that the return value of
PyObject_Str and PyObject_Repr is a unicode object. It looks like the
%S and %R feature was backported from 3.x without updating the code for 2.x.
PyObject *
PyUnicode_FromFormatV(const char *format, va_list vargs)
{
...
case 'S':
{
PyObject *obj = va_arg(count, PyObject *);
PyObject *str;
assert(obj);
str = PyObject_Str(obj);
if (!str)
goto fail;
n += PyUnicode_GET_SIZE(str);
/* Remember the str and switch to the next slot */
*callresult++ = str;
break;
}
case 'R':
{
PyObject *obj = va_arg(count, PyObject *);
PyObject *repr;
assert(obj);
repr = PyObject_Repr(obj);
if (!repr)
goto fail;
n += PyUnicode_GET_SIZE(repr);
/* Remember the repr and switch to the next slot */
*callresult++ = repr;
break;
}
...
}
----------
components: Interpreter Core, Library (Lib)
messages: 97067
nosy: alexandre.vassalotti
severity: normal
stage: test needed
status: open
title: PyUnicode_FromFormatV handles %R and %S incorrectly.
type: behavior
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7608>
_______________________________________
From report at bugs.python.org Thu Dec 31 03:05:47 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 31 Dec 2009 02:05:47 +0000
Subject: [New-bugs-announce] [issue7609] Add --with-system-expat option
In-Reply-To: <1262225147.39.0.152461484795.issue7609@psf.upfronthosting.co.za>
Message-ID: <1262225147.39.0.152461484795.issue7609@psf.upfronthosting.co.za>
New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:
`configure` should support --with-system-expat option (similarly to --
internal copy of expat. It will be useful for some distributions (e.g.
Gentoo), which prefer to use system libraries instead internal copies.
----------
components: Build
files: python-system-expat.patch
keywords: patch
messages: 97074
nosy: Arfrever
severity: normal
status: open
title: Add --with-system-expat option
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15707/python-system-expat.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7609>
_______________________________________
From report at bugs.python.org Thu Dec 31 09:03:35 2009
From: report at bugs.python.org (lucifer)
Date: Thu, 31 Dec 2009 08:03:35 +0000
Subject: [New-bugs-announce] [issue7610] Cannot use both read and readline
method in same ZipExtFile object
Message-ID: <1262246615.05.0.213512245217.issue7610@psf.upfronthosting.co.za>
Changes by lucifer <luyuntao at yahoo.com.cn>:
----------
components: Extension Modules
nosy: lucifer
severity: normal
status: open
title: Cannot use both read and readline method in same ZipExtFile object
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7610>
_______________________________________
From report at bugs.python.org Thu Dec 31 09:42:43 2009
From: report at bugs.python.org (Jan David Mol)
Date: Thu, 31 Dec 2009 08:42:43 +0000
Subject: [New-bugs-announce] [issue7611] shlex not posix compliant when
parsing "foo#bar"
In-Reply-To: <1262248963.08.0.673944744724.issue7611@psf.upfronthosting.co.za>
Message-ID: <1262248963.08.0.673944744724.issue7611@psf.upfronthosting.co.za>
New submission from Jan David Mol <jjdmol at gmail.com>:
The shlex parser parses "foo#bar" as "foo", discarding the rest as a
comment. This is actually one of the test cases, even in POSIX mode.
However, POSIX (see below) only allows comments to start at the
beginning of a token, so "foo#bar" has to result in a "foo#bar" token.
To easily see this, do "echo foo#bar" in bash, versus "echo foo #bar".
Fixing this might break some applications that rely on this broken
behaviour, even though they're not strictly POSIX compliant.
POSIX 2008, Rationale C.2.3 (which refers to Shell & Utilities 2.3(10)):
The (10) rule about '#' as the current character is the first in the
sequence in which a new token is being assembled. The '#' starts a
comment only when it is at the beginning of a token. This rule is also
written to indicate that the search for the end-of-comment does not
consider escaped <newline> specially, so that a comment cannot be
continued to the next line.
----------
components: Library (Lib)
messages: 97081
nosy: jjdmol2
severity: normal
status: open
title: shlex not posix compliant when parsing "foo#bar"
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7611>
_______________________________________
From report at bugs.python.org Thu Dec 31 13:16:47 2009
From: report at bugs.python.org (Yitz Gale)
Date: Thu, 31 Dec 2009 12:16:47 +0000
Subject: [New-bugs-announce] [issue7612] Fix "pass and object" typo in
Library Reference / Built-in Types / Sequence Types
In-Reply-To: <1262261807.24.0.177394158823.issue7612@psf.upfronthosting.co.za>
Message-ID: <1262261807.24.0.177394158823.issue7612@psf.upfronthosting.co.za>
New submission from Yitz Gale <gale at sefer.org>:
Change "if you pass and object of the wrong type"
to "if you pass an object of the wrong type"
in stdtypes.rst.
----------
assignee: georg.brandl
components: Documentation
files: typo_pass_and_object.patch
keywords: patch
messages: 97086
nosy: georg.brandl, ygale
severity: normal
status: open
title: Fix "pass and object" typo in Library Reference / Built-in Types / Sequence Types
versions: Python 3.1
Added file: http://bugs.python.org/file15710/typo_pass_and_object.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7612>
_______________________________________
From report at bugs.python.org Thu Dec 31 13:51:27 2009
From: report at bugs.python.org (Ettl Martin)
Date: Thu, 31 Dec 2009 12:51:27 +0000
Subject: [New-bugs-announce] [issue7613] [cppcheck] found a regression :
Invalid number of character ((). Can't process file.
In-Reply-To: <1262263887.86.0.671145516418.issue7613@psf.upfronthosting.co.za>
Message-ID: <1262263887.86.0.671145516418.issue7613@psf.upfronthosting.co.za>
New submission from Ettl Martin <ettl.martin at gmx.de>:
during a check with the static code analysis tool cppcheck
(http://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=Main_Page)
the tool found a missing ')' in python-svn/Modules/flmodule.c that leads
to a regression.
Please refer the attached patch that fixes the issue.
Best regards
Ettl Martin
----------
components: None
files: regression1.patch
keywords: patch
messages: 97089
nosy: ettl.martin
severity: normal
status: open
title: [cppcheck] found a regression : Invalid number of character ((). Can't process file.
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file15711/regression1.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7613>
_______________________________________
From report at bugs.python.org Thu Dec 31 22:33:14 2009
From: report at bugs.python.org (ttsiod)
Date: Thu, 31 Dec 2009 21:33:14 +0000
Subject: [New-bugs-announce] [issue7614] Python 2.6.4 segfaults
In-Reply-To: <1262295194.3.0.0100824369598.issue7614@psf.upfronthosting.co.za>
Message-ID: <1262295194.3.0.0100824369598.issue7614@psf.upfronthosting.co.za>
New submission from ttsiod <ttsiodras at gmail.com>:
I found a nice yield-based implementation of the sieve of Eratosthenes.
I tried to find the last prime number less than 1.000.000 (1M) - so I
had to increase the recursion limit (via sys.setrecursionlimit).
It seemed to work - but after running for about 3 minutes, the
Python interpreter (2.6.4) crashed with a segmentation fault.
I am attaching the code - it uses no libraries except for "sys"
(it needs it to set the recursionlimit).
----------
components: None
files: sieve.py
messages: 97109
nosy: ttsiod
severity: normal
status: open
title: Python 2.6.4 segfaults
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file15714/sieve.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7614>
_______________________________________
From Anurag.Sharma at amd.com Mon Dec 28 15:23:06 2009
From: Anurag.Sharma at amd.com (Sharma, Anurag)
Date: Mon, 28 Dec 2009 14:23:06 -0000
Subject: [New-bugs-announce] Python doesn't compile on MS VS2008
Message-ID: <9598614C04487C469A28BE03EA094CBEBF6840@safsexmb1.amd.com>
Hi
I downloaded the source for Python-3.1.1 for windows x86. I followed the
instructions in the PCbuild\Readme.txt file to build python
Basically, all I did was
1. Open the "PCbuild\pcbuild.sln" in VS2008.
2. Select the "Win32" as Solution Platform and "Release" as
Solution Configuration
3. Build Solution (F6)
I got the following error messages
Error 1 fatal error C1083: Cannot open source file:
'..\..\sqlite-3.5.9\sqlite3.c': No such file or directory c1
sqlite3
Error 11 fatal error C1083: Cannot open include file:
'bzlib.h': No such file or directory
Desktop\Python-3.1.1__\Python-3.1.1\Modules\bz2module.c 12
bz2
Error 12 fatal error C1083: Cannot open include file:
'tcl.h': No such file or directory
Desktop\Python-3.1.1__\Python-3.1.1\Modules\_tkinter.c 66
_tkinter
Error 13 fatal error C1083: Cannot open include file:
'tcl.h': No such file or directory
Desktop\Python-3.1.1__\Python-3.1.1\Modules\tkappinit.c 16
_tkinter
Error 14 fatal error C1083: Cannot open include file:
'sqlite3.h': No such file or directory
desktop\python-3.1.1__\python-3.1.1\modules\_sqlite\connection.h 33
_sqlite3
Error 15 error PRJ0019: A tool returned an error code
from "Performing Pre-Build Event..." _ssl _ssl
Error 16 fatal error C1083: Cannot open include file:
'sqlite3.h': No such file or directory
desktop\python-3.1.1__\python-3.1.1\modules\_sqlite\connection.h 33
_sqlite3
Error 17 fatal error C1083: Cannot open include file:
'sqlite3.h': No such file or directory
desktop\python-3.1.1__\python-3.1.1\modules\_sqlite\connection.h 33
_sqlite3
Error 18 fatal error C1083: Cannot open include file:
'sqlite3.h': No such file or directory
desktop\python-3.1.1__\python-3.1.1\modules\_sqlite\connection.h 33
_sqlite3
Error 19 fatal error C1083: Cannot open include file:
'sqlite3.h': No such file or directory
desktop\python-3.1.1__\python-3.1.1\modules\_sqlite\connection.h 33
_sqlite3
Error 20 fatal error C1083: Cannot open include file:
'sqlite3.h': No such file or directory
desktop\python-3.1.1__\python-3.1.1\modules\_sqlite\connection.h 33
_sqlite3
Error 21 fatal error C1083: Cannot open include file:
'sqlite3.h': No such file or directory
desktop\python-3.1.1__\python-3.1.1\modules\_sqlite\connection.h 33
_sqlite3
Error 23 error PRJ0019: A tool returned an error code
from "Performing Pre-Build Event..." _hashlib
_hashlib
Can someone help me fix these errors.
Thanks in advance
Thanks
Anurag
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20091228/a14ce576/attachment-0001.html>