From report at bugs.python.org Wed Apr 1 01:22:10 2009
From: report at bugs.python.org (David Christian)
Date: Tue, 31 Mar 2009 23:22:10 +0000
Subject: [New-bugs-announce] [issue5635] test_sys reference counting fails
while tracing
In-Reply-To: <1238541730.73.0.292702158526.issue5635@psf.upfronthosting.co.za>
Message-ID: <1238541730.73.0.292702158526.issue5635@psf.upfronthosting.co.za>
New submission from David Christian <dbc at rpath.com>:
test_sys refcount test checks that assigning None to a local variable n
increases the references to None by exactly 1.
However sys.settrace is set, then the frame object must be instantiated
to be passed to the trace object. This increments the reference count
to None again. Since the locals are not then removed from the frame
object after the sys.settrace call, the number of references remains
increased after the settrace function is exited.
This problem can be avoided by making n a global.
----------
files: refcount.patch
keywords: patch
messages: 84946
nosy: dugan
severity: normal
status: open
title: test_sys reference counting fails while tracing
Added file: http://bugs.python.org/file13530/refcount.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5635>
_______________________________________
From report at bugs.python.org Wed Apr 1 03:14:36 2009
From: report at bugs.python.org (Tony Joblin)
Date: Wed, 01 Apr 2009 01:14:36 +0000
Subject: [New-bugs-announce] [issue5636] csv.reader next() method missing
In-Reply-To: <1238548476.16.0.332919263338.issue5636@psf.upfronthosting.co.za>
Message-ID: <1238548476.16.0.332919263338.issue5636@psf.upfronthosting.co.za>
New submission from Tony Joblin <tonyjoblin at yahoo.com.au>:
On windows using 3.0.1 the csv.reader.next() public method is missing.
The documentation says that this method should exist and it does exist
in previous versions. There is a __next__ method available and
constructs like:
for row in reader
print(row)
still work.
----------
components: Windows
messages: 84954
nosy: tonyjoblin
severity: normal
status: open
title: csv.reader next() method missing
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5636>
_______________________________________
From report at bugs.python.org Wed Apr 1 03:57:02 2009
From: report at bugs.python.org (Senthil)
Date: Wed, 01 Apr 2009 01:57:02 +0000
Subject: [New-bugs-announce] [issue5637] 2to3 does not convert
urllib.urlopen to urllib.request.urlopen
In-Reply-To: <1238551022.24.0.463432313749.issue5637@psf.upfronthosting.co.za>
Message-ID: <1238551022.24.0.463432313749.issue5637@psf.upfronthosting.co.za>
New submission from Senthil <orsenthil at gmail.com>:
In Py2x, have this code:
import urllib
s = urllib.urlopen('http://www.python.org')
print s
Run 2to3, on this, refactoring works only on import urllib and print
statements.
@@ -1,3 +1,3 @@
-import urllib
+import urllib.request, urllib.parse, urllib.error
s = urllib.urlopen('http://www.python.org')
-print s
+print(s)
There urllib.urlopen, needs to be refactored into urllib.request.urlopen
----------
messages: 84956
nosy: orsenthil
severity: normal
status: open
title: 2to3 does not convert urllib.urlopen to urllib.request.urlopen
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5637>
_______________________________________
From report at bugs.python.org Wed Apr 1 05:11:19 2009
From: report at bugs.python.org (Tony Nelson)
Date: Wed, 01 Apr 2009 03:11:19 +0000
Subject: [New-bugs-announce] [issue5638] test_httpservers fails CGI tests if
--enable-shared
In-Reply-To: <1238555479.53.0.0126068485544.issue5638@psf.upfronthosting.co.za>
Message-ID: <1238555479.53.0.0126068485544.issue5638@psf.upfronthosting.co.za>
New submission from Tony Nelson <tony_nelson at users.sourceforge.net>:
test_httpservers fails the CGI tests if Python was built as a shared
library (./config --enable-shared) and not yet installed. To run such a
Python without installing it, the command line must define
LD_LIBRARY_PATH to point to the build directory. I see that the new
environment for the child CGI process still has LD_LIBRARY_PATH set.
The child process is not using that when the CGI is invoked.
After the new shared Python (or one like it) is installed, the test
passes, but the CGIs aren't using the correct copy of Python.
I'm doing this with Python 2.6.1, but the version probably doesn't matter.
----------
components: Tests
messages: 84969
nosy: tony_nelson
severity: normal
status: open
title: test_httpservers fails CGI tests if --enable-shared
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5638>
_______________________________________
From report at bugs.python.org Wed Apr 1 08:38:25 2009
From: report at bugs.python.org (Phil Pennock)
Date: Wed, 01 Apr 2009 06:38:25 +0000
Subject: [New-bugs-announce] [issue5639] Support TLS SNI extension in ssl
module
In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za>
Message-ID: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za>
New submission from Phil Pennock <python-dev at spodhuis.org>:
With TLS it is possible to have the client use an extension (defined in
RFC 4366, and RFC 3546 before that) to indicate to the server which
hostname it believes it is talking to. The server can then choose TLS
certificates accordingly. This makes virtual-hosting possible. Most
modern GUI web-browsers support making use of this extension, Server
Name Indication (SNI).
OpenSSL 0.9.8f onwards have optional support for this; OpenSSL needs to
have been built with "enable-tlsext" in EXTRACONFIGURE. If that is not
present, then there's a guard macro defined to say it's absent.
This patch, against Python 2.6.1, adds to the standard ssl module the
ability to set the extension, using server_hostname as a arg in relevant
places. This is only set for client connections and will silently be
ignored if the OpenSSL library does not support it.
I have tested this on FreeBSD 7.0/amd64 with OpenSSL 0.9.8k when talking
to Apache 2.2.x with the SNI patches from https://sni.velox.ch/. Below
is my simple test program, to dump raw HTTP results back. With this, I
can connect to various local https vhosts and get the correct content back.
I am not a Python core dev and not too enthusiastic at the thought of
grabbing latest svn to port this across; I hope that it's still of use.
=============
import socket
import ssl
import sys
def dump_https_page(hostname, uri='/'):
sock = socket.socket(socket.AF_INET)
s = ssl.SSLSocket(sock=sock,
ca_certs='/etc/ssl/certs',
server_hostname=hostname)
print 'have socket'
s.connect((hostname, 443))
print 'connected'
print >>s, 'GET %s HTTP/1.0\r\nHost: %s\r\nConnection: close\r\n\r\n' % (
uri, hostname),
t = s.read()
while t:
print t,
t = s.read()
if __name__ == '__main__':
for x in sys.argv[1:]:
dump_https_page(hostname=x)
----------
components: Library (Lib)
files: python-2.6.1-tlssni.patch
keywords: patch
messages: 84984
nosy: pdp
severity: normal
status: open
title: Support TLS SNI extension in ssl module
versions: Python 2.6
Added file: http://bugs.python.org/file13534/python-2.6.1-tlssni.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5639>
_______________________________________
From report at bugs.python.org Wed Apr 1 09:35:03 2009
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Wed, 01 Apr 2009 07:35:03 +0000
Subject: [New-bugs-announce] [issue5640] Wrong print() result when unicode
error handler is not 'strict'
In-Reply-To: <1238571303.14.0.143713902199.issue5640@psf.upfronthosting.co.za>
Message-ID: <1238571303.14.0.143713902199.issue5640@psf.upfronthosting.co.za>
New submission from Atsuo Ishimoto <ishimoto at gembook.org>:
In Python 3(both 3.0.1 and SVN repo), if I set
PYTHONIOENCODING=ShiftJIS:backslashreplace, print()
outputs wrong result.
>>> print("\xff")
\xff\xff
Obviously, '\xff' should be printed instead of '\xff\xff'.
Following is what io module does to print string.
>>> import codecs
>>> e=codecs.getincrementalencoder("ShiftJIS")("backslashreplace")
>>> e.encode("\xff")
b'\\xff'
>>> e.encode("\n")
b'\\xff\n'
io module never supply final=True to the encoder.
----------
components: Unicode
messages: 84987
nosy: ishimoto
severity: normal
status: open
title: Wrong print() result when unicode error handler is not 'strict'
type: behavior
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5640>
_______________________________________
From report at bugs.python.org Wed Apr 1 10:49:38 2009
From: report at bugs.python.org (Glin)
Date: Wed, 01 Apr 2009 08:49:38 +0000
Subject: [New-bugs-announce] [issue5641] Local variables not freed when
Exception raises in function called from cycle
In-Reply-To: <1238575778.52.0.687578256719.issue5641@psf.upfronthosting.co.za>
Message-ID: <1238575778.52.0.687578256719.issue5641@psf.upfronthosting.co.za>
New submission from Glin <glin at seznam.cz>:
Situation:
You have a while cycle. inside of it a try-except block and in this
try-except block calling a function. Inside of this function raises an
exception, with is caught in the try-except block.
What happens:
Local variables of the function are not freed. (OK, they are freed when
the program leaves a function inside of which is the while cycle, or
when another exception raises and is caught, but it's not helpful when
you have some server program based on infinite while loop or working
with a large amount of data).
Example:
Example program is attached.
Output of the example program:
While start
job() start
Creating 1
Catched AttributeError
While end
While start
job() start
Creating 2
job() end
Deleting 2
While end
While start
job() start
Creating 3
job() end
Deleting 3
While end
...
As you can see, a variable 'a' created in the first call (which throws
an exception) of the 'job' function will never get freed.
Imagine that in 'job' function you create a large amount of data, or
worse you create a database connection, which will be opened forever.
Tested on Python 2.5.2 and 2.7(svn). On the contrary, Python 3.0 does
not have this issue (it frees variables of the 'job' function at the end
of except: block.)
As Python 2.X will be another long time with us, I think it should be
fixed to behave correctly (that is as in Python 3.)
----------
components: Interpreter Core
files: notfreed.py
messages: 84989
nosy: Glin
severity: normal
status: open
title: Local variables not freed when Exception raises in function called from cycle
type: resource usage
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file13535/notfreed.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5641>
_______________________________________
From report at bugs.python.org Wed Apr 1 11:49:48 2009
From: report at bugs.python.org (James McDermott)
Date: Wed, 01 Apr 2009 09:49:48 +0000
Subject: [New-bugs-announce] [issue5642] multiprocessing.Pool.map() docs
slightly misleading
In-Reply-To: <1238579388.2.0.737750854681.issue5642@psf.upfronthosting.co.za>
Message-ID: <1238579388.2.0.737750854681.issue5642@psf.upfronthosting.co.za>
New submission from James McDermott <jamesmichaelmcdermott at gmail.com>:
I found the documentation for the multiprocessing.Pool.map() method to
be a little misleading, because it claims to be equivalent to the built-
in map(), but it's not quite.
When the function to be applied takes just one argument, both map()s
behave the same. But built-in map() allows the function to take multiple
arguments (taking them from multiple iterables) whereas
multiprocessing.Pool.map() requires it to have only a single argument,
and if necessary its iterable argument must be composed of tuples to be
unpacked inside the function.
From
http://docs.python.org/library/multiprocessing.html#multiprocessing.pool
.multiprocessing.Pool.map
map(func, iterable[, chunksize])
A parallel equivalent of the map() builtin function.
>From http://docs.python.org/library/functions.html#map
map(function, iterable, ...)
Apply function to every item of iterable and return a list of the
results. If additional iterable arguments are passed, function must take
that many arguments and is applied to the items from all iterables in
parallel.
----------
assignee: georg.brandl
components: Documentation
messages: 84991
nosy: georg.brandl, jmmcd
severity: normal
status: open
title: multiprocessing.Pool.map() docs slightly misleading
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5642>
_______________________________________
From report at bugs.python.org Wed Apr 1 15:43:22 2009
From: report at bugs.python.org (Matteo Dell'Amico)
Date: Wed, 01 Apr 2009 13:43:22 +0000
Subject: [New-bugs-announce] [issue5647] MutableSet.__iand__ implementation
calls self.discard while iterating on self
In-Reply-To: <1238593402.02.0.427774935909.issue5647@psf.upfronthosting.co.za>
Message-ID: <1238593402.02.0.427774935909.issue5647@psf.upfronthosting.co.za>
New submission from Matteo Dell'Amico <della at linux.it>:
The current MutableSet.__iand__ implementation calls self.discard while
iterating on self. This creates strange problems while implementing
MutableSet with simple choices. For example, consider the attached file
which implements set by delegating either to a set or a list. In the
first cases, an exception is raised; in the second, the result is not
what is expected.
Python 2.6+ (r26:66714, Oct 22 2008, 09:21:39)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from simpleset import WithSet, WithList
>>> s = WithSet([1,2])
>>> s &= ()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.6/_abcoll.py", line 290, in __iand__
for value in self:
RuntimeError: Set changed size during iteration
>>> s = WithList([1,2])
>>> s &= ()
>>> list(s)
[2]
----------
components: Library (Lib)
files: simpleset.py
messages: 85006
nosy: della
severity: normal
status: open
title: MutableSet.__iand__ implementation calls self.discard while iterating on self
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13538/simpleset.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5647>
_______________________________________
From report at bugs.python.org Wed Apr 1 16:37:27 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 01 Apr 2009 14:37:27 +0000
Subject: [New-bugs-announce] [issue5648] OS X Installer: do not install
obsolete documentation within Python.app bundle
In-Reply-To: <1238596647.54.0.611757278193.issue5648@psf.upfronthosting.co.za>
Message-ID: <1238596647.54.0.611757278193.issue5648@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
Prevent "hidden" obsolete and unused MacPython documentation
files from being installed within framework Python.app bundle.
(The current documentation continues to be installed elsewhere.)
----------
components: Build
files: patch-nad0010-py3k-30.txt
messages: 85016
nosy: nad, ronaldoussoren
severity: normal
status: open
title: OS X Installer: do not install obsolete documentation within Python.app bundle
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13540/patch-nad0010-py3k-30.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5648>
_______________________________________
From report at bugs.python.org Wed Apr 1 17:40:45 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 01 Apr 2009 15:40:45 +0000
Subject: [New-bugs-announce] [issue5649] OS X Installer: only include
PythonSystemFixes package if target includes 10.3
In-Reply-To: <1238600445.94.0.804009523794.issue5649@psf.upfronthosting.co.za>
Message-ID: <1238600445.94.0.804009523794.issue5649@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
The PythonSystemFixes package of the OS X installer fixes a specific
compatibility problem with the Apple-supplied Python 2.3 on OS X 10.3. The
attached patches changes the build installer script to include that
package in the installer only if the installer image includes 10.3 as a
targeted system.
----------
components: Installation
files: patch-nad0008-py3k-30.txt
messages: 85022
nosy: nad, ronaldoussoren
severity: normal
status: open
title: OS X Installer: only include PythonSystemFixes package if target includes 10.3
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13543/patch-nad0008-py3k-30.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5649>
_______________________________________
From report at bugs.python.org Wed Apr 1 18:14:18 2009
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 01 Apr 2009 16:14:18 +0000
Subject: [New-bugs-announce] [issue5650] Obsolete RFC's should be removed
from doc of urllib.urlparse
In-Reply-To: <1238602458.06.0.807356829134.issue5650@psf.upfronthosting.co.za>
Message-ID: <1238602458.06.0.807356829134.issue5650@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
The documentation of urlparse in Python2 and urllib.urlparse in Python3
refers to three RFC's, the last of which (RFC 2396) says that it
supersedes the other two and, in fact, clicking on the links to the other
two doesn't work; the link and description for the two obsolete RFCs
should be removed.
----------
assignee: georg.brandl
components: Documentation
messages: 85032
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Obsolete RFC's should be removed from doc of urllib.urlparse
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5650>
_______________________________________
From report at bugs.python.org Wed Apr 1 18:16:52 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 01 Apr 2009 16:16:52 +0000
Subject: [New-bugs-announce] [issue5651] OS X Installer: add checks to
ensure proper Tcl configuration during build
In-Reply-To: <1238602612.52.0.800890790819.issue5651@psf.upfronthosting.co.za>
Message-ID: <1238602612.52.0.800890790819.issue5651@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
Because OS X 10.4 and 10.5 ship with an old 8.4 version of Aqua Tcl and
Tk frameworks, current practice is to build the installer image on a
machine with user-installed newer 8.4 Tcl/Tk frameworks in /Library.
This ensures the correct dylib search sequence is built into the Python
image so that users can install a newer 8.4 on their own systems and, if
not, Python will fallback to the Apple-supplied versions in
/System/Library. It is easy to overlook this step in the build process,
however, and some installer images in the past inadvertently did not
include this capability.
This patch adds checks to the build-installer script to ensure that the
newer frameworks are installed on the build machine so that the magic
happens.
Note, Python tkinter currently only supports linking with one
major/minor version of Tcl and Tk so this magic does not allow the
Python installer image to use a major/minor version other than the
current system version.
----------
components: Build
files: patch-nad0012.txt
messages: 85033
nosy: nad, ronaldoussoren
severity: normal
status: open
title: OS X Installer: add checks to ensure proper Tcl configuration during build
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13545/patch-nad0012.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5651>
_______________________________________
From report at bugs.python.org Wed Apr 1 18:29:46 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 01 Apr 2009 16:29:46 +0000
Subject: [New-bugs-announce] [issue5652] OS X Installer: remove references
to Mac/Tools which no longer exists
In-Reply-To: <1238603386.16.0.0582109660822.issue5652@psf.upfronthosting.co.za>
Message-ID: <1238603386.16.0.0582109660822.issue5652@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
The OS X Installer postflight script still tries to compileall scripts in
the framework Mac/Tools directory even though it no longer exists.
----------
components: Installation
files: patch-nad0009-trunk-26.txt
messages: 85044
nosy: nad, ronaldoussoren
severity: normal
status: open
title: OS X Installer: remove references to Mac/Tools which no longer exists
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13546/patch-nad0009-trunk-26.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5652>
_______________________________________
From report at bugs.python.org Wed Apr 1 18:52:56 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 01 Apr 2009 16:52:56 +0000
Subject: [New-bugs-announce] [issue5653] OS X Installer: by default install
versioned-only links in /usr/local/bin for 3.x
In-Reply-To: <1238604776.11.0.0788260895322.issue5653@psf.upfronthosting.co.za>
Message-ID: <1238604776.11.0.0788260895322.issue5653@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
For 3.0, the OS X installer was changed to disable the default
installation of the Unix Command Line Tools package, the package that
installs links in /usr/local/bin to the corresponding entries in the
framework bin directory. The intent was to follow the practice of other
Python 3.x installers to ensure that python 2.x and python 3.x could co-
exist. However, with the framework structure of OS X python, each
python version has its own bin directory and the lack of 3.x links in
/usr/local/bin has led to some user confusion.
This patch modifies the OS X installer for 3.x to again re-enable the
Unix Command Line Tools package by default but to only install versioned
links into /usr/local/bin (i.e. /usr/local/bin/python3.1) but not
disturbed any unversioned links (i.e. /usr/local/bin/python will
continue to point to an installed python2.x). The only exception is
that 3.x will install a /usr/local/bin link to its 2to3, which is
currently not versioned. The framework bin directory is unchanged and
contains both versioned and unversioned links.
----------
components: Installation
files: patch-nad0022-py3k.txt
messages: 85049
nosy: nad, ronaldoussoren
severity: normal
status: open
title: OS X Installer: by default install versioned-only links in /usr/local/bin for 3.x
versions: Python 3.1
Added file: http://bugs.python.org/file13548/patch-nad0022-py3k.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5653>
_______________________________________
From report at bugs.python.org Wed Apr 1 18:55:05 2009
From: report at bugs.python.org (John Ehresman)
Date: Wed, 01 Apr 2009 16:55:05 +0000
Subject: [New-bugs-announce] [issue5654] Add C hook in PyDict_SetItem for
debuggers
In-Reply-To: <1238604905.42.0.578461685574.issue5654@psf.upfronthosting.co.za>
Message-ID: <1238604905.42.0.578461685574.issue5654@psf.upfronthosting.co.za>
New submission from John Ehresman <jpe at wingware.com>:
I'm interested in adding support for debugger watchpoint's in the core.
A watchpoint would cause the debugger to stop when a value in a
namespace changes. This hook would be called when PyDict_SetItem &
PyDict_DelItem is invoked. I realize that this does not cover function
local variables, but I'm more interested in instance attributes and globals.
This is a proof of concept patch; I wanted to see if it would work and
get some initial feedback. I think the performance implications are
minimal in the case where nothing is watched, though the performance of
sample callback in _debuggerhooks can be improved. An issue may be if
this is used outside a debugger implementation to implement an observer
pattern -- I'd like to discourage it, but worry that it will be used
since it's there, rather like how the settrace tracer gets used.
If there's interest in this, I will clean this up and add watchpoints to
pdb.
----------
components: Interpreter Core
files: dicthook.diff
keywords: patch
messages: 85051
nosy: jpe
severity: normal
status: open
title: Add C hook in PyDict_SetItem for debuggers
versions: Python 2.7
Added file: http://bugs.python.org/file13549/dicthook.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5654>
_______________________________________
From report at bugs.python.org Wed Apr 1 19:24:18 2009
From: report at bugs.python.org (DSM)
Date: Wed, 01 Apr 2009 17:24:18 +0000
Subject: [New-bugs-announce] [issue5655] fix glob.iglob docstring
In-Reply-To: <1238606658.05.0.0385441814822.issue5655@psf.upfronthosting.co.za>
Message-ID: <1238606658.05.0.0385441814822.issue5655@psf.upfronthosting.co.za>
New submission from DSM <dsm001 at users.sourceforge.net>:
glob.iglob's docstring claims it returns a list, but as the name
suggests it returns an iterator. Looks like a cut 'n paste oversight.
glob.rst is correct.
Patch attached against mainline trunk r70961. Should also apply cleanly
to py3k trunk.
----------
assignee: georg.brandl
components: Documentation
files: iglob_main.patch
keywords: patch
messages: 85054
nosy: dsm001, georg.brandl
severity: normal
status: open
title: fix glob.iglob docstring
versions: Python 2.7
Added file: http://bugs.python.org/file13551/iglob_main.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5655>
_______________________________________
From report at bugs.python.org Wed Apr 1 20:25:42 2009
From: report at bugs.python.org (Maru Newby)
Date: Wed, 01 Apr 2009 18:25:42 +0000
Subject: [New-bugs-announce] [issue5656] Coverage execution fails for files
not encoded with utf-8
In-Reply-To: <1238610342.6.0.926080137435.issue5656@psf.upfronthosting.co.za>
Message-ID: <1238610342.6.0.926080137435.issue5656@psf.upfronthosting.co.za>
New submission from Maru Newby <mnewby at thesprawl.net>:
Running the tests with coverage against files using non-utf8 encoding
was raising an exception that prevented coverage output from being
displayed (patch is attached).
The coverage output was also being polluted with failed attempts to
display modules that were created during the testing in temporary paths.
A patch is attached that prevents coverage output from being attempted
for such files.
----------
components: Tests
files: trace_detect_encoding.patch
keywords: patch
messages: 85065
nosy: maru
severity: normal
status: open
title: Coverage execution fails for files not encoded with utf-8
type: crash
versions: Python 3.1
Added file: http://bugs.python.org/file13553/trace_detect_encoding.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5656>
_______________________________________
From report at bugs.python.org Wed Apr 1 21:30:28 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 01 Apr 2009 19:30:28 +0000
Subject: [New-bugs-announce] [issue5657] bad repr of itertools.count object
with negative value on OS X 10.4 with 10.5 build
In-Reply-To: <1238614228.92.0.740866649828.issue5657@psf.upfronthosting.co.za>
Message-ID: <1238614228.92.0.740866649828.issue5657@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
Observed failure of regression test:
======================================================================
FAIL: test_count (test.test_itertools.TestBasicOps)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/test/te
st_itertools.py", line 215, in test_count
self.assertEqual(repr(c), 'count(-9)')
AssertionError: 'count(4294967287)' != 'count(-9)'
Problem can be reproduced using the python.org 3.0.1 OS X installer on a
PPC (G3) system running 10.4:
/Library/Frameworks/Python.framework/Versions/3.0$ bin/python3.0
Python 3.0.1 (r301:69597, Feb 14 2009, 19:03:52)
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from itertools import count
>>> x = count(-2)
>>> x
count(4294967294)
>>> next(x)
-2
>>> x
count(4294967295)
>>> next(x)
-1
>>> x
count(0)
>>> next(x)
0
>>> x
count(1)
>>>
nad at pbg3:/Library/Frameworks/Python.framework/Versions/3.0$ uname -a
Darwin pbg3.baybryj.net 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10
18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh
powerpc
But the same installer on another PPC (G4) system running 10.5 works
fine:
/Library/Frameworks/Python.framework/Versions/3.0$ bin/python3.0
Python 3.0.1 (r301:69597, Feb 14 2009, 19:03:52)
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from itertools import count
>>> x = count(-2)
>>> x
count(-2)
>>> next(x)
-2
>>>
nad at pbg4:/Library/Frameworks/Python.framework/Versions/3.0$ uname -a
Darwin pbg4.local 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:39:01
PST 2008; root:xnu-1228.9.59~1/RELEASE_PPC Power Macintosh
Further analysis shows that the problem is reproducible on the 10.4
system with any current build (2.x/3.x) if the installer build is made
on a 10.5 system with the default deployment target of 10.3; the correct
results are seen if the image is installed on a 10.5 system. If the
same source snapshot is used to build an installer image on the 10.4
system, the resulting image does not exhibit this bug, either on the
10.4 or on 10.5 systems.
More analysis is needed.
It would be helpful if anyone with access to another 10.4 PPC or Intel
system could try the above code snippet using the 3.0.1 OS X from
python.org.
----------
components: Macintosh
messages: 85081
nosy: nad, ronaldoussoren
severity: normal
status: open
title: bad repr of itertools.count object with negative value on OS X 10.4 with 10.5 build
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5657>
_______________________________________
From report at bugs.python.org Wed Apr 1 23:09:54 2009
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 01 Apr 2009 21:09:54 +0000
Subject: [New-bugs-announce] [issue5658] make html in doc fails because
Makefile assigns python to PYTHON
In-Reply-To: <1238620194.29.0.802372876082.issue5658@psf.upfronthosting.co.za>
Message-ID: <1238620194.29.0.802372876082.issue5658@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
Mac OSX, py3k 70991
cd doc; make html
fails due to an old style except clause in Doc/tools/sphinx/__init__.py
The make works in release30-maint.
The difference is that the generated doc/Makefile in release30-maint
assigns python2.5 to PYTHON, but the py3k doc/Makefile assigns python. I
have things set up so that 'python' is Python 3.
I understand how to set the variable from the command line, and I can
build the html doc, but this should be fixed, either by continuing to
specify python2.5 in the sphinx Makefile or by changing __init__.py and
whatever other code uses exception binding to the new syntax.
----------
components: Build
messages: 85094
nosy: MLModel
severity: normal
status: open
title: make html in doc fails because Makefile assigns python to PYTHON
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5658>
_______________________________________
From report at bugs.python.org Thu Apr 2 00:50:45 2009
From: report at bugs.python.org (Kuno)
Date: Wed, 01 Apr 2009 22:50:45 +0000
Subject: [New-bugs-announce] [issue5659] logging.FileHandler encoding
parameter does not work as expected
In-Reply-To: <1238626245.67.0.948477208489.issue5659@psf.upfronthosting.co.za>
Message-ID: <1238626245.67.0.948477208489.issue5659@psf.upfronthosting.co.za>
New submission from Kuno <kuno at frob.nl>:
When attempting to use the encoding="" parameter of logging.FileHandler
I always get a UnicodeError. This looks like a bug to me (otherwise I
am seriously misunderstanding what the parameter is supposed to do). The
attached file contains the code to reproduce this error.
Traceback (most recent call last):
File "/usr/local/stow/Python-2.6.1/lib/python2.6/logging/__init__.py",
line 765, in emit
self.stream.write(fs % msg.encode("UTF-8"))
File "/usr/local/stow/Python-2.6.1/lib/python2.6/codecs.py", line 686,
in write
return self.writer.write(data)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xec in position 0:
ordinal not in range(128)
For completeness: I am running a self-compiled Python 2.6.1 on the
current Debian GNU/Linux testing release.
----------
components: Library (Lib)
files: l.py
messages: 85106
nosy: warp
severity: normal
status: open
title: logging.FileHandler encoding parameter does not work as expected
versions: Python 2.6
Added file: http://bugs.python.org/file13562/l.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5659>
_______________________________________
From report at bugs.python.org Thu Apr 2 02:27:54 2009
From: report at bugs.python.org (Andrew Bennetts)
Date: Thu, 02 Apr 2009 00:27:54 +0000
Subject: [New-bugs-announce] [issue5660] Cannot deepcopy unittest.TestCase
instances
In-Reply-To: <1238632074.64.0.545150493098.issue5660@psf.upfronthosting.co.za>
Message-ID: <1238632074.64.0.545150493098.issue5660@psf.upfronthosting.co.za>
New submission from Andrew Bennetts <spiv at users.sourceforge.net>:
Here's a demonstration of the bug:
>>> from unittest import TestCase
>>> class MyTest(TestCase):
... def test_foo(self): pass
...
>>> tc = MyTest('test_foo')
>>> import copy
>>> copy.deepcopy(tc)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/stow/py2.7/lib/python2.7/copy.py", line 189, in deepcopy
y = _reconstruct(x, rv, 1, memo)
File "/usr/local/stow/py2.7/lib/python2.7/copy.py", line 338, in
_reconstruct
state = deepcopy(state, memo)
File "/usr/local/stow/py2.7/lib/python2.7/copy.py", line 162, in deepcopy
y = copier(x, memo)
File "/usr/local/stow/py2.7/lib/python2.7/copy.py", line 255, in
_deepcopy_dict
y[deepcopy(key, memo)] = deepcopy(value, memo)
File "/usr/local/stow/py2.7/lib/python2.7/copy.py", line 162, in deepcopy
y = copier(x, memo)
File "/usr/local/stow/py2.7/lib/python2.7/copy.py", line 255, in
_deepcopy_dict
y[deepcopy(key, memo)] = deepcopy(value, memo)
File "/usr/local/stow/py2.7/lib/python2.7/copy.py", line 189, in deepcopy
y = _reconstruct(x, rv, 1, memo)
File "/usr/local/stow/py2.7/lib/python2.7/copy.py", line 323, in
_reconstruct
y = callable(*args)
File "/usr/local/bin/../stow/py2.7/lib/python2.7/copy_reg.py", line
93, in __newobj__
return cls.__new__(cls, *args)
TypeError: instancemethod expected at least 2 arguments, got 0
This regression breaks bzr's test suite, which copies test objects to
run the same test against multiple scenarios (e.g. to run all the same
tests against all the implementations of bzrlib.transport.Transport,
such as HTTPTransport and SFTPTransport.)
<https://launchpad.net/testtools> also implements test parameterisation
in this way, and it is extremely useful.
I suspect the __test_equality_funcs on TestCase is the problem:
>>> tc.__dict__
{'_testMethodDoc': None, '_TestCase__type_equality_funcs': {<type
'dict'>: <bound method MyTest.assertDictEqual of <__main__.MyTest
testMethod=test_foo>>, <type 'tuple'>: <bound method
MyTest.assertTupleEqual of <__main__.MyTest testMethod=test_foo>>, <type
'frozenset'>: <bound method MyTest.assertSetEqual of <__main__.MyTest
testMethod=test_foo>>, <type 'list'>: <bound method
MyTest.assertListEqual of <__main__.MyTest testMethod=test_foo>>, <type
'set'>: <bound method MyTest.assertSetEqual of <__main__.MyTest
testMethod=test_foo>>}, '_testMethodName': 'test_foo'}
copy.deepcopy can't deepcopy bound methods, reasonably enough.
----------
components: Library (Lib)
messages: 85123
nosy: spiv
severity: normal
status: open
title: Cannot deepcopy unittest.TestCase instances
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5660>
_______________________________________
From report at bugs.python.org Thu Apr 2 03:03:27 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 02 Apr 2009 01:03:27 +0000
Subject: [New-bugs-announce] [issue5661] asyncore should catch EPIPE while
sending() and receiving()
In-Reply-To: <1238634207.37.0.10074614667.issue5661@psf.upfronthosting.co.za>
Message-ID: <1238634207.37.0.10074614667.issue5661@psf.upfronthosting.co.za>
New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:
I received a report from a pyftpdlib user:
http://code.google.com/p/pyftpdlib/issues/detail?id=104
...complaining that an unhandled EPIPE error might be thrown by
asyncore.py on OS X in certain circumstances which are hardly reproducible.
By googling a little about it it seems that he's not the first one who
got this problem:
http://mail.python.org/pipermail/medusa-dev/2003/000852.html
https://bugs.launchpad.net/zope2/+bug/142654
I think it makes sense modifying dispatcher.send() and dispatcher.recv()
to include EPIPE as error condition to indicate that the connection has
been closed and call handle_close() as consequence.
The patch in attachment does that.
----------
components: Library (Lib)
files: asyncore.patch
keywords: patch
messages: 85125
nosy: giampaolo.rodola, josiah.carlson, josiahcarlson
severity: normal
status: open
title: asyncore should catch EPIPE while sending() and receiving()
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13566/asyncore.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5661>
_______________________________________
From report at bugs.python.org Thu Apr 2 03:30:57 2009
From: report at bugs.python.org (George Yoshida)
Date: Thu, 02 Apr 2009 01:30:57 +0000
Subject: [New-bugs-announce] [issue5662] py3k interpreter leak
In-Reply-To: <1238635857.67.0.0527294444116.issue5662@psf.upfronthosting.co.za>
Message-ID: <1238635857.67.0.0527294444116.issue5662@psf.upfronthosting.co.za>
New submission from George Yoshida <quiver at users.sourceforge.net>:
In py3k interpreter, every time you hit enter,
refcount is incremented one by one.
It looks like r70823 is the culprit.
(tested with py3k:70823 and release30-maint:70831)
Python 3.1a1+ (py3k:70823, Apr 2 2009, 10:21:55)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
[36297 refs]
>>>
[36298 refs]
>>>
[36299 refs]
>>>
[36300 refs]
>>>
[36301 refs]
>>>
[36302 refs]
>>>
[36303 refs]
----------
messages: 85129
nosy: quiver
severity: normal
status: open
title: py3k interpreter leak
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5662>
_______________________________________
From report at bugs.python.org Thu Apr 2 03:58:40 2009
From: report at bugs.python.org (Michael Foord)
Date: Thu, 02 Apr 2009 01:58:40 +0000
Subject: [New-bugs-announce] [issue5663] Better failure messages for
unittest assertions
In-Reply-To: <1238637520.24.0.827171540397.issue5663@psf.upfronthosting.co.za>
Message-ID: <1238637520.24.0.827171540397.issue5663@psf.upfronthosting.co.za>
New submission from Michael Foord <michael at voidspace.org.uk>:
Patch for unittest on trunk.
It provides better default failure messages for assertTrue and
assertFalse (current is "AssertionError: None").
It also provides a new class attribute for TestCase: longMessage
This defaults to False. If set to True, passing in an explicit custom
message does *not* override the helpful default failure message in
asserts which tell you which objects were involved in the failure.
Even if set to True or False in a TestCase then longMessage can still be
overridden in individual tests by setting an instance attribute.
Needs docs.
Could longMessage default to True in 3.1.
----------
components: Library (Lib)
files: unittest-messages.diff
keywords: patch
messages: 85136
nosy: mfoord
severity: normal
status: open
title: Better failure messages for unittest assertions
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file13567/unittest-messages.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5663>
_______________________________________
From report at bugs.python.org Thu Apr 2 05:22:48 2009
From: report at bugs.python.org (Senthil)
Date: Thu, 02 Apr 2009 03:22:48 +0000
Subject: [New-bugs-announce] [issue5664] 2to3 wont convert Cookie.Cookie
properly
In-Reply-To: <1238642568.2.0.229238012255.issue5664@psf.upfronthosting.co.za>
Message-ID: <1238642568.2.0.229238012255.issue5664@psf.upfronthosting.co.za>
New submission from Senthil <orsenthil at gmail.com>:
In 2.7 code have:
import Cookie
c = Cookie.Cookie('abc')
2to3 would do:
c = http.cookies.Cookie('abc')
This is wrong as there is no class as Cookie in http.cookies. It should
translated to be http.cookies.SimpleCookie.
----------
assignee: benjamin.peterson
components: 2to3 (2.x to 3.0 conversion tool)
messages: 85151
nosy: benjamin.peterson, orsenthil
severity: normal
status: open
title: 2to3 wont convert Cookie.Cookie properly
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5664>
_______________________________________
From report at bugs.python.org Thu Apr 2 06:45:49 2009
From: report at bugs.python.org (Collin Winter)
Date: Thu, 02 Apr 2009 04:45:49 +0000
Subject: [New-bugs-announce] [issue5665] Add more pickling tests
In-Reply-To: <1238647549.17.0.666638819326.issue5665@psf.upfronthosting.co.za>
Message-ID: <1238647549.17.0.666638819326.issue5665@psf.upfronthosting.co.za>
New submission from Collin Winter <collinw at gmail.com>:
The attached patch adds more tests for pickling:
- Add tests for the module-level load() and dump() functions.
- Add tests for cPickle's internal data structures, stressing workloads
with many gets/puts.
- Add tests for the Pickler and Unpickler classes, in particular the
memo attribute.
- test_xpickle is extended to test backwards compatibility with Python
2.4, 2.5 and 2.6 by round-tripping pickled objects through a worker
process. 2.3 was too difficult to support.
I'll port to py3k after reviewed for trunk.
----------
components: Tests
files: pickle_tests.patch
keywords: needs review, patch
messages: 85162
nosy: collinwinter
severity: normal
status: open
title: Add more pickling tests
type: behavior
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file13571/pickle_tests.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5665>
_______________________________________
From report at bugs.python.org Thu Apr 2 11:04:54 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 02 Apr 2009 09:04:54 +0000
Subject: [New-bugs-announce] [issue5666] Py_BuildValue("c") should return
bytes?
In-Reply-To: <1238663094.93.0.570643835814.issue5666@psf.upfronthosting.co.za>
Message-ID: <1238663094.93.0.570643835814.issue5666@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
This is related to #5499. PyArg_ParseTuple treats "c" as bytes of 1
length now, but Py_BuildValue still treats "c" as unicode of 1 length.
----------
components: Interpreter Core
files: py3k_build_value.patch
keywords: patch
messages: 85184
nosy: ocean-city
priority: release blocker
severity: normal
status: open
title: Py_BuildValue("c") should return bytes?
versions: Python 3.1
Added file: http://bugs.python.org/file13574/py3k_build_value.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5666>
_______________________________________
From report at bugs.python.org Thu Apr 2 11:25:39 2009
From: report at bugs.python.org (Hyeshik Chang)
Date: Thu, 02 Apr 2009 09:25:39 +0000
Subject: [New-bugs-announce] [issue5667] Interpreter fails to initialize
when IO encoding is one of CJK on build dir
In-Reply-To: <1238664339.95.0.0471411238024.issue5667@psf.upfronthosting.co.za>
Message-ID: <1238664339.95.0.0471411238024.issue5667@psf.upfronthosting.co.za>
New submission from Hyeshik Chang <hyeshik at gmail.com>:
When a developer uses one of CJK encodings, interpreter crashes while
its initialization on build dir (not on installed base).
% LC_ALL=ko_KR.eucKR ./python
Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: euc_kr
zsh: abort (core dumped) LC_ALL=ko_KR.eucKR ./python
The problem is that codec lookup function fails to import a relevant
codec module because path to dynamic modules is added by site.py, which
is a later step than standard I/O object initializations.
----------
components: Interpreter Core
messages: 85187
nosy: hyeshik.chang
priority: low
severity: normal
status: open
title: Interpreter fails to initialize when IO encoding is one of CJK on build dir
type: crash
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5667>
_______________________________________
From report at bugs.python.org Thu Apr 2 12:31:20 2009
From: report at bugs.python.org (Zbyszek Szmek)
Date: Thu, 02 Apr 2009 10:31:20 +0000
Subject: [New-bugs-announce] [issue5668] file "<stdin>" on disk creates
garbage output in stack trace
In-Reply-To: <1238668280.27.0.69442728469.issue5668@psf.upfronthosting.co.za>
Message-ID: <1238668280.27.0.69442728469.issue5668@psf.upfronthosting.co.za>
New submission from Zbyszek Szmek <zbyszek at in.waw.pl>:
When running interactively, python checks for existence of file
"<stdin>" when trying to display a stack trace with code input from stdin.
# cat >> "<stdin>"
asdf asdf asdf
# python
Python 2.5.2 (r252:60911, Jun 25 2008, 17:58:32)
[GCC 4.3.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> asdf
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
asdf asdf asdf
NameError: name 'asdf' is not defined
# strace -efile python
...
open("<stdin>", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("<stdin>", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/home13/zbyszek/pm/<stdin>", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("/usr/lib/python25.zip/<stdin>", O_RDONLY) = -1 ENOENT (No such
file or directory)
open("/usr/lib64/python2.5/<stdin>", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("/usr/lib64/python2.5/plat-linux2/<stdin>", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/lib64/python2.5/lib-tk/<stdin>", O_RDONLY) = -1 ENOENT (No
such file or directory)
open("/usr/lib64/python2.5/lib-dynload/<stdin>", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/lib64/python2.5/site-packages/<stdin>", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/lib64/python2.5/site-packages/Numeric/<stdin>", O_RDONLY) =
-1 ENOENT (No such file or directory)
open("/usr/lib64/python2.5/site-packages/PIL/<stdin>", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/lib64/python2.5/site-packages/gtk-2.0/<stdin>", O_RDONLY) =
-1 ENOENT (No such file or directory)
open("/usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/<stdin>",
O_RDONLY) = -1 ENOENT (No such file or directory)
This is exactly the same in python 2.4, 2.5 and 3.0. I haven't tested
other versions.
----------
components: Interpreter Core
messages: 85192
nosy: zbysz
severity: normal
status: open
title: file "<stdin>" on disk creates garbage output in stack trace
versions: Python 2.4, Python 2.5, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5668>
_______________________________________
From report at bugs.python.org Thu Apr 2 18:43:18 2009
From: report at bugs.python.org (George Sakkis)
Date: Thu, 02 Apr 2009 16:43:18 +0000
Subject: [New-bugs-announce] [issue5669] Extra heap nlargest/nsmallest
option for including ties
In-Reply-To: <1238690598.13.0.569229974695.issue5669@psf.upfronthosting.co.za>
Message-ID: <1238690598.13.0.569229974695.issue5669@psf.upfronthosting.co.za>
New submission from George Sakkis <george.sakkis at gmail.com>:
It would be useful in many cases if heapq.nlargest and heapq.nsmallest
grew an optional boolean parameter, say `ties` (defaulting to False)
that when True, it would return more than `n` items if there are ties.
To illustrate:
>>> s = [4,3,5,7,4,7,4,3]
>>> for i in xrange(1,len(s)+1): print i,heapq.nsmallest(i,s)
...
1 [3]
2 [3, 3]
3 [3, 3, 4]
4 [3, 3, 4, 4]
5 [3, 3, 4, 4, 4]
6 [3, 3, 4, 4, 4, 5]
7 [3, 3, 4, 4, 4, 5, 7]
8 [3, 3, 4, 4, 4, 5, 7, 7]
>>> for i in xrange(1,len(s)+1): print i,heapq.nsmallest(i,s)
...
1 [3, 3]
2 [3, 3]
3 [3, 3, 4, 4, 4]
4 [3, 3, 4, 4, 4]
5 [3, 3, 4, 4, 4]
6 [3, 3, 4, 4, 4, 5]
7 [3, 3, 4, 4, 4, 5, 7, 7]
8 [3, 3, 4, 4, 4, 5, 7, 7]
----------
components: Library (Lib)
messages: 85222
nosy: gsakkis
severity: normal
status: open
title: Extra heap nlargest/nsmallest option for including ties
type: feature request
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5669>
_______________________________________
From report at bugs.python.org Thu Apr 2 20:53:51 2009
From: report at bugs.python.org (Collin Winter)
Date: Thu, 02 Apr 2009 18:53:51 +0000
Subject: [New-bugs-announce] [issue5670] Speed up pickling of dicts in
cPickle
In-Reply-To: <1238698431.18.0.108052594941.issue5670@psf.upfronthosting.co.za>
Message-ID: <1238698431.18.0.108052594941.issue5670@psf.upfronthosting.co.za>
New submission from Collin Winter <collinw at gmail.com>:
The attached patch adds another version of cPickle.c's batch_dict(),
batch_dict_exact(), which is specialized for "type(x) is dict". This
provides a nice performance boost when pickling objects that use
dictionaries:
Pickle:
Min: 2.216 -> 1.858: 19.24% faster
Avg: 2.238 -> 1.889: 18.50% faster
Significant (t=106.874099, a=0.95)
Benchmark is at
http://code.google.com/p/unladen-swallow/source/browse/tests/performance/macro_pickle.py
(driver is ../perf.py; perf.py was run with "--rigorous -b pickle").
This patch passes all the tests added in issue 5665. I would recommend
reviewing that patch first. I'll port to py3k once this is reviewed for
trunk.
----------
components: Extension Modules
files: cpickle_dict.patch
keywords: needs review, patch
messages: 85239
nosy: collinwinter
severity: normal
status: open
title: Speed up pickling of dicts in cPickle
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file13584/cpickle_dict.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5670>
_______________________________________
From report at bugs.python.org Thu Apr 2 21:28:17 2009
From: report at bugs.python.org (Collin Winter)
Date: Thu, 02 Apr 2009 19:28:17 +0000
Subject: [New-bugs-announce] [issue5671] Speed up pickling of lists in
cPickle
In-Reply-To: <1238700497.01.0.638889592432.issue5671@psf.upfronthosting.co.za>
Message-ID: <1238700497.01.0.638889592432.issue5671@psf.upfronthosting.co.za>
New submission from Collin Winter <collinw at gmail.com>:
The attached patch adds another version of cPickle.c's batch_list(),
batch_list_exact(), which is specialized for "type(x) is list". This
provides a nice performance boost when pickling objects that use
lists. This is similar to the approach taken in issue 5670, though the
performance boost on our benchmark is smaller:
Pickle:
Min: 2.231 -> 2.200: 1.39% faster
Avg: 2.266 -> 2.227: 1.72% faster
Significant (t=10.994064, a=0.95)
Benchmark is at
http://code.google.com/p/unladen-swallow/source/browse/tests/performance/macro_pickle.py
(driver is ../perf.py; perf.py was run with "--rigorous -b pickle").
Workloads involving more lists will benefit more.
This patch passes all the tests added in issue 5665. I would recommend
reviewing that patch first. I'll port to py3k once this is reviewed for
trunk.
----------
components: Extension Modules
files: cpickle_list.patch
keywords: needs review, patch
messages: 85250
nosy: collinwinter
severity: normal
status: open
title: Speed up pickling of lists in cPickle
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file13585/cpickle_list.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5671>
_______________________________________
From =?utf-8?q?Marcelo_Fern=C3=A1ndez_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za Thu Apr 2 21:38:04 2009
From: =?utf-8?q?Marcelo_Fern=C3=A1ndez_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za (=?utf-8?q?Marcelo_Fern=C3=A1ndez_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za)
Date: Thu, 02 Apr 2009 19:38:04 +0000
Subject: [New-bugs-announce] [issue5672] Implement a way to change the
python process name
In-Reply-To: <1238701084.1.0.0781987214897.issue5672@psf.upfronthosting.co.za>
Message-ID: <1238701084.1.0.0781987214897.issue5672@psf.upfronthosting.co.za>
New submission from Marcelo Fern?ndez <fernandezm22 at yahoo.com.ar>:
As python gains more popularity, more and more applications run under
CPython in a common user desktop. The problem is that if a user has 2 or
more python apps running there is no way to identify them correctly from
the generic "Task/Process Manager Application" (in Windows/Linux/OSX/any
OS), because all appear as a "python" process. Take Ubuntu for an example.
There are more cases when this is annoying:
- Imagine two python process (doing different things, of course) sending
messages to syslog: looks like all coming from "python" process.
- A bash script which wants to "killall" one application: how can it
identify a given python script between two or more "python" processes?
There are some methods [1][2] to work around it, but there are not just
Linux/BSD only, moreover, there are not included in the python standard
modules.
[1] http://davyd.livejournal.com/166352.html
[2] http://code.google.com/p/procname/
I hope this issue gets considered in the community to fix it, I really
think this is important... :-)
Regards,
Marcelo
----------
components: Extension Modules
messages: 85252
nosy: marcelo_fernandez
severity: normal
status: open
title: Implement a way to change the python process name
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5672>
_______________________________________
From report at bugs.python.org Thu Apr 2 21:41:16 2009
From: report at bugs.python.org (Reid Kleckner)
Date: Thu, 02 Apr 2009 19:41:16 +0000
Subject: [New-bugs-announce] [issue5673] Add timeout option to
subprocess.Popen
In-Reply-To: <1238701276.41.0.515283298202.issue5673@psf.upfronthosting.co.za>
Message-ID: <1238701276.41.0.515283298202.issue5673@psf.upfronthosting.co.za>
New submission from Reid Kleckner <rnk at mit.edu>:
I was looking for a way to run a subprocess with a timeout. While there
are a variety of solutions on Google, I feel like this functionality
should live in the standard library module. Apparently Guido thought
this would be good in 2005 but no one did it:
http://mail.python.org/pipermail/python-dev/2005-December/058784.html
I'd be willing to implement it, but I'm not a core dev and I'd need
someone to review it. I'll start working on a patch now, and if people
think this is a good idea I'll submit it for review.
My plan was to add a 'timeout' optional keyword argument to wait() and
propagate that backwards through communicate(), call(), and
check_call(). Does anyone object to this approach?
----------
components: Library (Lib)
messages: 85256
nosy: rnk
severity: normal
status: open
title: Add timeout option to subprocess.Popen
type: feature request
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5673>
_______________________________________
From report at bugs.python.org Thu Apr 2 23:22:36 2009
From: report at bugs.python.org (Jim Garrison)
Date: Thu, 02 Apr 2009 21:22:36 +0000
Subject: [New-bugs-announce] [issue5674] distutils fails to find Linux libs
(lib.....so.n)
In-Reply-To: <1238707356.06.0.784964091736.issue5674@psf.upfronthosting.co.za>
Message-ID: <1238707356.06.0.784964091736.issue5674@psf.upfronthosting.co.za>
New submission from Jim Garrison <jgarrison at troux.com>:
Trying to build 3.1a1 on Fedora 9, the following extensions get skipped
even though the requisite packages are installed
_dbm
_gdbm
_hashlib
_sqlite3
_ssl
bz2
readline
zlib
After looking at the code in distutils I *think* the problem is because
setup.py isn't coping with library filenames such as "libreadline.so.5"
and "libgdm.so.2" (with the .n) second extension.
It looks like ccompiler.py#library_filename() just appends the
extension, which is .so for unix, and then
unixccompiler.py#find_library_file() does a simple os.path.exists() on
the name, not allowing for the additional numeric extension.
Note that some library filenames in Linux have two or even three such
extensions, as in libreadline.so.5.2, and some extensions are not
all-numeric, as in libssl.so.0.9.8g.
----------
assignee: tarek
components: Distutils
messages: 85268
nosy: jgarrison, tarek
severity: normal
status: open
title: distutils fails to find Linux libs (lib.....so.n)
type: compile error
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5674>
_______________________________________
From report at bugs.python.org Fri Apr 3 01:54:36 2009
From: report at bugs.python.org (MechPaul)
Date: Thu, 02 Apr 2009 23:54:36 +0000
Subject: [New-bugs-announce] [issue5675] string module requires bytes type
for maketrans, but calling method on regular string does not
In-Reply-To: <1238716476.0.0.609350611694.issue5675@psf.upfronthosting.co.za>
Message-ID: <1238716476.0.0.609350611694.issue5675@psf.upfronthosting.co.za>
New submission from MechPaul <mechpaul at gmail.com>:
I was making a simple Caesarian cipher when this issue came up.
#Following code here
>>> import string
>>> CAESER_SHIFT = 13
>>> TranslationTableUpper = [string.ascii_uppercase[(index +
CAESER_SHIFT) % 26] for index in range(26)]
>>> TranslationTableLower = [string.ascii_lowercase[(index +
CAESER_SHIFT) % 26] for index in range(26)]
>>> TranslationTableCipher = ''.join(TranslationTableUpper +
TranslationTableLower)
>>> TranslationTableRegular = string.ascii_uppercase[0:27] +
string.ascii_lowercase[0:27]
>>> Trans = ''.maketrans(TranslationTableCipher, TranslationTableRegular)
>>> print(Trans)
{65: 78, 66: 79, 67: 80, 68: 81, 69: 82, 70: 83, 71: 84, 72: 85, 73: 86,
74: 87, 75: 88, 76: 89, 77: 90, 78: 65, 79: 66, 80: 67, 81: 68, 82: 69,
83: 70, 84: 71, 85: 72, 86: 73, 87: 74, 88: 75, 89: 76, 90: 77, 97: 110,
98: 111, 99: 112, 100: 113, 101: 114, 102: 115, 103: 116, 104: 117, 105:
118, 106: 119, 107: 120, 108: 121, 109: 122, 110: 97, 111: 98, 112: 99,
113: 100, 114: 101, 115: 102, 116: 103, 117: 104, 118: 105, 119: 106,
120: 107, 121: 108, 122: 109}
>>> #Okay... so maketrans() is working okay when calling it on an empty
string, buuuut if called from the string module...
>>> Trans = string.maketrans(TranslationTableCipher,
TranslationTableRegular)
Trans = string.maketrans(TranslationTableCipher,
TranslationTableRegular)
File "D:\Python31\lib\string.py", line 55, in maketrans
raise TypeError("maketrans arguments must be bytes objects")
TypeError: maketrans arguments must be bytes objects
----------
components: Interpreter Core
messages: 85280
nosy: MechPaul
severity: normal
status: open
title: string module requires bytes type for maketrans, but calling method on regular string does not
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5675>
_______________________________________
From report at bugs.python.org Fri Apr 3 02:46:57 2009
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 03 Apr 2009 00:46:57 +0000
Subject: [New-bugs-announce] [issue5676] Fix "make clean" in py3k/trunk
In-Reply-To: <1238719617.07.0.390323030603.issue5676@psf.upfronthosting.co.za>
Message-ID: <1238719617.07.0.390323030603.issue5676@psf.upfronthosting.co.za>
New submission from Larry Hastings <larry at hastings.org>:
"make clean" fails in my tree. There's an inscrutable new directory,
"@test", which is chmod 400, and therefore "find" isn't allowed to
descend into it, so it fails and aborts the clean early. I don't know
what the deal is here, but I patched the rules for "clean" and
"pycremoval" so they chmod "@test" temporarily to 755 before running and
back to "400" afterwards.
A better fix: get rid of this "chmod 400 @test" nonsense. But I'm too
lazy to investigate why it was done in the first place. Or tell me what
I'm doing wrong in the first place...
----------
components: Build
files: lch.make.clean.diff
keywords: patch
messages: 85285
nosy: lhastings
severity: normal
status: open
title: Fix "make clean" in py3k/trunk
versions: Python 3.1
Added file: http://bugs.python.org/file13591/lch.make.clean.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5676>
_______________________________________
From report at bugs.python.org Fri Apr 3 03:24:44 2009
From: report at bugs.python.org (Robert Xiao)
Date: Fri, 03 Apr 2009 01:24:44 +0000
Subject: [New-bugs-announce] [issue5677] Serious interpreter crash and/or
arbitrary memory leak using .read() on writable file
In-Reply-To: <1238721884.54.0.371516304831.issue5677@psf.upfronthosting.co.za>
Message-ID: <1238721884.54.0.371516304831.issue5677@psf.upfronthosting.co.za>
New submission from Robert Xiao <nneonneo at gmail.com>:
(tested and verified on Windows and Solaris SPARC)
Running this code in Python 2.4, 2.5 or 2.6 (all minor versions)
produces garbage.
f=open("anyfile","w")
f.write("garbage")
f.readline()
Mac OS X and Linux appear to simply throw an "IOError: [Errno 9] Bad
file descriptor" exception, while using a read method without writing
first produces the same exception on Windows and certain versions under
Solaris.
Under Solaris, it is further possible to segfault the interpreter with
this code:
f=open("anyfile","w")
f.read()
In the former case, it appears as if the data is simply read from the
disk block containing the file. In the latter, I have no clue what is
going on.
In Python 3.0, file objects opened with "w" don't even support any .read
methods, so this does not affect Py3k.
----------
components: Interpreter Core
messages: 85286
nosy: nneonneo
severity: normal
status: open
title: Serious interpreter crash and/or arbitrary memory leak using .read() on writable file
type: crash
versions: Python 2.4, Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5677>
_______________________________________
From report at bugs.python.org Fri Apr 3 15:44:16 2009
From: report at bugs.python.org (Friedrich Weber)
Date: Fri, 03 Apr 2009 13:44:16 +0000
Subject: [New-bugs-announce] [issue5678] typo in future_builtins
documentation
In-Reply-To: <1238766256.3.0.595291754287.issue5678@psf.upfronthosting.co.za>
Message-ID: <1238766256.3.0.595291754287.issue5678@psf.upfronthosting.co.za>
New submission from Friedrich Weber <fred at reichbier.de>:
Hi,
from http://docs.python.org/library/future_builtins.html:
.. function:: oct(object)
Works like the builtin :func:`oct`, but instead of :meth:`__oct__` it
will
use the :meth:`__index__` method on its argument to get an integer
that is
then converted to hexadecimal.
should rather be something like '... that is then converted to octal.'
----------
assignee: georg.brandl
components: Documentation
messages: 85304
nosy: fredreichbier, georg.brandl
severity: normal
status: open
title: typo in future_builtins documentation
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5678>
_______________________________________
From report at bugs.python.org Fri Apr 3 21:56:47 2009
From: report at bugs.python.org (Michael Foord)
Date: Fri, 03 Apr 2009 19:56:47 +0000
Subject: [New-bugs-announce] [issue5679] cleanUp stack for unittest
In-Reply-To: <1238788607.78.0.0557494613751.issue5679@psf.upfronthosting.co.za>
Message-ID: <1238788607.78.0.0557494613751.issue5679@psf.upfronthosting.co.za>
New submission from Michael Foord <michael at voidspace.org.uk>:
Proposal to add a cleanUp stack to unittest.TestCase. This is a list of
callables to be called (LIFO) to cleanup resources. If there are items
on the stack it should be called even if setUp fails. Otherwise it
should be called after tearDown.
Similar functionality is in the testing frameworks used by bzr, Twisted,
and Zope.
I will create a patch similar to the bzr implementation.
The public API is via a new method:
def addCleanUpItem(self, callable, *args, **kwargs):
Usage is:
self.db = self.createDB()
self.addCleanUpItem(self.db.close)
----------
assignee: michael.foord
components: Library (Lib)
messages: 85321
nosy: michael.foord
severity: normal
status: open
title: cleanUp stack for unittest
type: behavior
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5679>
_______________________________________
From report at bugs.python.org Sat Apr 4 00:42:36 2009
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 03 Apr 2009 22:42:36 +0000
Subject: [New-bugs-announce] [issue5680] Command-line arguments when running
in IDLE
In-Reply-To: <1238798556.38.0.28468201552.issue5680@psf.upfronthosting.co.za>
Message-ID: <1238798556.38.0.28468201552.issue5680@psf.upfronthosting.co.za>
New submission from Matthew Barnett <python at mrabarnett.plus.com>:
Patch idle-args.diff adds a dialog for entering command-line arguments
for a script from within IDLE itself.
----------
components: IDLE
files: idle-args.diff
keywords: patch
messages: 85341
nosy: mrabarnett
severity: normal
status: open
title: Command-line arguments when running in IDLE
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file13600/idle-args.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5680>
_______________________________________
From report at bugs.python.org Sat Apr 4 01:09:16 2009
From: report at bugs.python.org (Collin Winter)
Date: Fri, 03 Apr 2009 23:09:16 +0000
Subject: [New-bugs-announce] [issue5681] Add a simple pickle optimizer to
cPickle
Message-ID: <1238800156.56.0.0582072136327.issue5681@psf.upfronthosting.co.za>
Changes by Collin Winter <collinw at gmail.com>:
----------
components: Extension Modules
files: cpickle_writes.patch
keywords: needs review, patch
nosy: alexandre.vassalotti, collinwinter
severity: normal
status: open
title: Add a simple pickle optimizer to cPickle
type: performance
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file13601/cpickle_writes.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5681>
_______________________________________
From report at bugs.python.org Sat Apr 4 01:55:42 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 03 Apr 2009 23:55:42 +0000
Subject: [New-bugs-announce] [issue5682] Move io-in-c modules into a
subdirectory of Modules/
In-Reply-To: <1238802942.81.0.198764911967.issue5682@psf.upfronthosting.co.za>
Message-ID: <1238802942.81.0.198764911967.issue5682@psf.upfronthosting.co.za>
New submission from Alexandre Vassalotti <alexandre at peadrop.com>:
Here is a patch that moves the source files of the _io module (and
closely related modules) into subdirectory of Modules. The new file
hierarchy proposed is the following:
Modules/
_io/
_iomodule.h
_iomodule.c
iobase.c
fileio.c
bufferedio.c
textio.c
bytesio.c
stringio.c
I believe that moving the io module into its own subdirectory will make
clear whether the different I/O implementations share common bugs.
Currently, it is quite easy to miss a module when doing a bug fix.
The patch was not tested on Windows. I tried my best to configure by
hand PCbuild and PC/{VC, VS7.1, VS8.0}. However, I would be surprised if
my changes were flawless.
----------
components: Build
keywords: needs review, patch
messages: 85346
nosy: alexandre.vassalotti, benjamin.peterson
priority: normal
severity: normal
status: open
title: Move io-in-c modules into a subdirectory of Modules/
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5682>
_______________________________________
From report at bugs.python.org Sat Apr 4 02:02:18 2009
From: report at bugs.python.org (Collin Winter)
Date: Sat, 04 Apr 2009 00:02:18 +0000
Subject: [New-bugs-announce] [issue5683] Speed up cPickle's pickling
generally
In-Reply-To: <1238803338.21.0.932870288543.issue5683@psf.upfronthosting.co.za>
Message-ID: <1238803338.21.0.932870288543.issue5683@psf.upfronthosting.co.za>
New submission from Collin Winter <collinw at gmail.com>:
This patch simplifies cPickle's complicated internal buffering system.
The new version uses a single buffer closer to the Pickler object,
flushing to a file object only when necessary. This avoids the overhead
of several indirection layers for what are frequently very small writes.
Benchmarked against virgin trunk r71058 using "perf.py -r -b
pickle,pickle_list,pickle_dict":
pickle:
Min: 2.225 -> 1.962: 13.37% faster
Avg: 2.254 -> 1.994: 13.03% faster
Significant (t=70.763434, a=0.95)
pickle_dict:
Min: 2.097 -> 1.418: 47.83% faster
Avg: 2.136 -> 1.446: 47.75% faster
Significant (t=214.900146, a=0.95)
pickle_list:
Min: 1.128 -> 0.777: 45.22% faster
Avg: 1.152 -> 0.807: 42.65% faster
Significant (t=169.789433, a=0.95)
A similar patch for unpickling will follow. As issue 5670 and 5671 are
committed, I'll update this patch to support them.
This patch passes all the tests added in issue 5665. I would recommend
reviewing that patch first. I'll port to py3k once this is reviewed for
trunk. This patch is available on Rietveld at
http://codereview.appspot.com/33070.
----------
components: Extension Modules
files: cpickle_writes.patch
keywords: needs review, patch
messages: 85349
nosy: alexandre.vassalotti, collinwinter
severity: normal
stage: patch review
status: open
title: Speed up cPickle's pickling generally
type: performance
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file13603/cpickle_writes.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5683>
_______________________________________
From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za Sat Apr 4 10:19:50 2009
From: =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za (=?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za)
Date: Sat, 04 Apr 2009 08:19:50 +0000
Subject: [New-bugs-announce] [issue5684] test_zipfile writes in its test
directory
In-Reply-To: <1238833190.77.0.866792563675.issue5684@psf.upfronthosting.co.za>
Message-ID: <1238833190.77.0.866792563675.issue5684@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
test_zipfile writes in its test directory, which can be a problem if
this directory is read-only in some installations.
----------
messages: 85382
nosy: tarek
priority: low
severity: normal
status: open
title: test_zipfile writes in its test directory
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/issue5684>
_______________________________________
From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za Sat Apr 4 10:31:40 2009
From: =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za (=?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za)
Date: Sat, 04 Apr 2009 08:31:40 +0000
Subject: [New-bugs-announce] [issue5685] use tarinfo module in distutils
In-Reply-To: <1238833900.11.0.222660239752.issue5685@psf.upfronthosting.co.za>
Message-ID: <1238833900.11.0.222660239752.issue5685@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
Currently, Distutils makes a system call to tar files, using the tar
command. Let's use Python's tarinfo module, so we don't rely on the tar
program anymore.
----------
assignee: tarek
components: Distutils
messages: 85384
nosy: tarek
priority: high
severity: normal
status: open
title: use tarinfo module in distutils
type: behavior
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5685>
_______________________________________
From report at bugs.python.org Sat Apr 4 14:20:17 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 04 Apr 2009 12:20:17 +0000
Subject: [New-bugs-announce] [issue5686] Float formatting with no type code
produces incorrect output for exponential notation
In-Reply-To: <1238847617.81.0.331181634269.issue5686@psf.upfronthosting.co.za>
Message-ID: <1238847617.81.0.331181634269.issue5686@psf.upfronthosting.co.za>
New submission from Eric Smith <eric at trueblade.com>:
If no format specifier is supplied to a float, it's supposed to work
like 'g', but with at least one digit after the decimal. This works for
non-exponential notation:
>>> format(1., '')
'1.0'
>>> format(1., 'g')
'1'
But for exponential notation, it does not:
>>> format(1e200, '')
'1e+200'
>>>
>>> format(1e200, 'g')
'1e+200'
----------
assignee: eric.smith
components: Interpreter Core
messages: 85386
nosy: eric.smith
severity: normal
status: open
title: Float formatting with no type code produces incorrect output for exponential notation
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5686>
_______________________________________
From report at bugs.python.org Sat Apr 4 15:34:26 2009
From: report at bugs.python.org (Brian Quinlan)
Date: Sat, 04 Apr 2009 13:34:26 +0000
Subject: [New-bugs-announce] [issue5687] Docstring typo in _io
Message-ID: <1238852066.0.0.111619925707.issue5687@psf.upfronthosting.co.za>
Changes by Brian Quinlan <brian at sweetapp.com>:
----------
components: Extension Modules
files: docstring.diff
keywords: patch
nosy: bquinlan
severity: normal
status: open
title: Docstring typo in _io
versions: Python 3.1
Added file: http://bugs.python.org/file13611/docstring.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5687>
_______________________________________
From report at bugs.python.org Sat Apr 4 17:29:21 2009
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 04 Apr 2009 15:29:21 +0000
Subject: [New-bugs-announce] [issue5688] inability to ignore multiline
warnings -- request to add re.DOTALL to re.compile
In-Reply-To: <1238858961.61.0.698895898394.issue5688@psf.upfronthosting.co.za>
Message-ID: <1238858961.61.0.698895898394.issue5688@psf.upfronthosting.co.za>
New submission from Matthias Klose <doko at debian.org>:
[forwarded from http://bugs.debian.org/519454]
"""
As of now, warnings.py provides only re.I flag to re.compile on
warnings.py:160. Recent python-numpy issues way too many warnings, I
was trying to filter them out using warnings.filterwarnings, but was
unable to filter out multiline warning (numpy.histogram). Adding
re.DOTALL to re.I should help to resolve the problem and allow users to
match also multiline warning messages.
"""
----------
messages: 85402
nosy: doko
severity: normal
status: open
title: inability to ignore multiline warnings -- request to add re.DOTALL to re.compile
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5688>
_______________________________________
From report at bugs.python.org Sat Apr 4 18:08:35 2009
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 04 Apr 2009 16:08:35 +0000
Subject: [New-bugs-announce] [issue5689] please support lzma compression as
an extension and in the tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
New submission from Matthias Klose <doko at debian.org>:
GNU tar now supports lzma compression as a compression method. Please
consider adding lzma support to the tarfile module (either by using the
external lzma program or by adding a lzma extension to the standard
library).
lzma extension at http://svn.fancycode.com/repos/python/pylzma/trunk/
lzma is used in many tools (7zip, dpkg, rpm), offers faster
decompression than bzip2, slower compression than gzip and bzip2.
----------
components: Extension Modules
messages: 85403
nosy: doko
severity: normal
status: open
title: please support lzma compression as an extension and in the tarfile module
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________
From report at bugs.python.org Sat Apr 4 18:54:38 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Apr 2009 16:54:38 +0000
Subject: [New-bugs-announce] [issue5690] test_types fails under Windows
In-Reply-To: <1238864078.6.0.552957987991.issue5690@psf.upfronthosting.co.za>
Message-ID: <1238864078.6.0.552957987991.issue5690@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
Compiled with VS 2008 Express:
test test_types failed -- Traceback (most recent call last):
File "Z:\py3k\__svn__\lib\test\test_types.py", line 343, in
test_int__format__
test(1234, ',', '1,234')
File "Z:\py3k\__svn__\lib\test\test_types.py", line 235, in test
self.assertEqual(i.__format__(format_spec), result)
AssertionError: '1234\x00' != '1,234'
----------
components: Tests
messages: 85409
nosy: benjamin.peterson, pitrou
priority: release blocker
severity: normal
stage: needs patch
status: open
title: test_types fails under Windows
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5690>
_______________________________________
From report at bugs.python.org Sat Apr 4 19:07:25 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Apr 2009 17:07:25 +0000
Subject: [New-bugs-announce] [issue5691] test_collections fails under Windows
In-Reply-To: <1238864845.26.0.288121922542.issue5691@psf.upfronthosting.co.za>
Message-ID: <1238864845.26.0.288121922542.issue5691@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
This is under Windows XP with VS 2008 Express:
test test_collections failed -- Traceback (most recent call last):
File "Z:\py3k\__svn__\lib\test\test_collections.py", line 714, in
test_equalit
y
self.assertNotEqual(od1, od2) # different order implies inequality
AssertionError: OrderedDict([('f', 6), ('e', 5), ('a', 3), ('b', 2),
('c', 1), (
'd', 4)]) == OrderedDict([('a', 3), ('b', 2), ('c', 1), ('d', 4), ('f',
6), ('e'
, 5)])
----------
components: Tests
messages: 85411
nosy: pitrou, rhettinger
priority: release blocker
severity: normal
stage: needs patch
status: open
title: test_collections fails under Windows
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5691>
_______________________________________
From report at bugs.python.org Sat Apr 4 19:17:13 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Apr 2009 17:17:13 +0000
Subject: [New-bugs-announce] [issue5692] test_zipfile fails under Windows
In-Reply-To: <1238865433.18.0.587625961619.issue5692@psf.upfronthosting.co.za>
Message-ID: <1238865433.18.0.587625961619.issue5692@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
Under Windows XP with VS 2008 Express:
test test_zipfile failed -- Traceback (most recent call last):
File "Z:\py3k\__svn__\lib\test\test_zipfile.py", line 334, in testExtract
self.assertEqual(writtenfile, correctfile)
AssertionError: 'c:_ziptest1' != 'c:\\_ziptest1'
----------
components: Tests
messages: 85414
nosy: pitrou
priority: release blocker
severity: normal
status: open
title: test_zipfile fails under Windows
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5692>
_______________________________________
From report at bugs.python.org Sun Apr 5 00:01:06 2009
From: report at bugs.python.org (Robert Collins)
Date: Sat, 04 Apr 2009 22:01:06 +0000
Subject: [New-bugs-announce] [issue5693] TestSuite.__iter__ is not hookable.
In-Reply-To: <1238882466.94.0.961337180903.issue5693@psf.upfronthosting.co.za>
Message-ID: <1238882466.94.0.961337180903.issue5693@psf.upfronthosting.co.za>
New submission from Robert Collins <robertc at robertcollins.net>:
Currently if you alter the way TestSuite iterates one must always
implement countTestCases, run, debug etc. The attached patch would make
this simpler.
If this looks ok I'll write up a test for it.
----------
components: Library (Lib)
files: testsuite.patch
keywords: patch
messages: 85435
nosy: rbcollins
severity: normal
status: open
title: TestSuite.__iter__ is not hookable.
type: feature request
Added file: http://bugs.python.org/file13615/testsuite.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5693>
_______________________________________
From report at bugs.python.org Sun Apr 5 02:16:23 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 05 Apr 2009 00:16:23 +0000
Subject: [New-bugs-announce] [issue5694] spurious output in test_distutils
In-Reply-To: <1238890583.06.0.607271052329.issue5694@psf.upfronthosting.co.za>
Message-ID: <1238890583.06.0.607271052329.issue5694@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
test_distutils produces the following kind of output. It doesn't make it
fail, but is a bit distracting.
test_distutils
removing '/tmp/tmpY0RHnV/foo/build_temp' (and everything under it)
removing '/tmp/tmpY0RHnV/foo/build_lib' (and everything under it)
removing '/tmp/tmpY0RHnV/foo/bdist_base' (and everything under it)
removing '/tmp/tmpY0RHnV/foo/build_scripts' (and everything under it)
removing '/tmp/tmpY0RHnV/foo/build_base'
'/tmp/tmpY0RHnV/foo/build_lib' does not exist -- can't clean it
'/tmp/tmpY0RHnV/foo/bdist_base' does not exist -- can't clean it
'/tmp/tmpY0RHnV/foo/build_scripts' does not exist -- can't clean it
----------
components: Tests
messages: 85453
nosy: pitrou, tarek
priority: low
severity: normal
stage: needs patch
status: open
title: spurious output in test_distutils
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5694>
_______________________________________
From report at bugs.python.org Sun Apr 5 02:30:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 05 Apr 2009 00:30:51 +0000
Subject: [New-bugs-announce] [issue5695] test_logging fails when run twice
in a row
In-Reply-To: <1238891451.8.0.0993541274648.issue5695@psf.upfronthosting.co.za>
Message-ID: <1238891451.8.0.0993541274648.issue5695@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
This happens e.g. when searching for refleaks (the -R option to regrtest).
./python -m test.regrtest test_logging test_logging
Could not find '/home/antoine/py3k/debug/Lib/test' in sys.path to remove it
test_logging
test_logging
test test_logging failed -- Traceback (most recent call last):
File "/home/antoine/py3k/debug/Lib/test/test_logging.py", line 932, in
test_warnings
file, "Dummy line")
File "/home/antoine/py3k/debug/Lib/logging/__init__.py", line 1534, in
_showwarning
_warnings_showwarning(message, category, filename, lineno, file, line)
File "/home/antoine/py3k/debug/Lib/logging/__init__.py", line 1534, in
_showwarning
_warnings_showwarning(message, category, filename, lineno, file, line)
[...]
File "/home/antoine/py3k/debug/Lib/logging/__init__.py", line 1534, in
_showwarning
_warnings_showwarning(message, category, filename, lineno, file, line)
RuntimeError: maximum recursion depth exceeded
----------
assignee: vsajip
components: Library (Lib), Tests
messages: 85454
nosy: pitrou, vsajip
priority: normal
severity: normal
stage: needs patch
status: open
title: test_logging fails when run twice in a row
type: crash
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5695>
_______________________________________
From report at bugs.python.org Sun Apr 5 03:46:02 2009
From: report at bugs.python.org (Jack Diederich)
Date: Sun, 05 Apr 2009 01:46:02 +0000
Subject: [New-bugs-announce] [issue5696] test_telnetlib augmentation
In-Reply-To: <1238895962.87.0.497816781262.issue5696@psf.upfronthosting.co.za>
Message-ID: <1238895962.87.0.497816781262.issue5696@psf.upfronthosting.co.za>
New submission from Jack Diederich <jackdied at gmail.com>:
The first part of my telnetlib work is testing what already is.
Attached is a patch to test_telnetlib that tests mosts of the guarantees
of the telnetlib.Telnet.read_* methods (as guaranteed by the docs, at
least).
Theoretically every test I added has a race condition.
ReadTests.blocking_timeout is currently set to 0.1 seconds and works on
my platform (it also works at 0.0 seconds). Is this acceptable or do I
need to include semaphores will 100% predictable behavior?
TIA
----------
assignee: jackdied
files: test_telnetlib.patch
keywords: patch
messages: 85460
nosy: jackdied
severity: normal
status: open
title: test_telnetlib augmentation
Added file: http://bugs.python.org/file13617/test_telnetlib.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5696>
_______________________________________
From report at bugs.python.org Sun Apr 5 16:55:18 2009
From: report at bugs.python.org (George Sakkis)
Date: Sun, 05 Apr 2009 14:55:18 +0000
Subject: [New-bugs-announce] [issue5697] heapq.nlargest does not perform
stable sort
In-Reply-To: <1238943318.15.0.801467733966.issue5697@psf.upfronthosting.co.za>
Message-ID: <1238943318.15.0.801467733966.issue5697@psf.upfronthosting.co.za>
New submission from George Sakkis <george.sakkis at gmail.com>:
According to the docs, heapq.nlargest should be equivalent to
sorted(iterable, key=key, reverse=True)[:n], and since sorted() is
stable, so should heapq.nlargest be. This is not the case:
>>> s =[
('Mike', -1),
('John', 3),
('George', 2),
('Adam', 3),
('Paul', -3),
('Peter', -2),
('Mary', -1)
]
>>> heapq.nlargest(2, s, key=lambda x:abs(x[1]))
[('Paul', -3), ('Adam', 3)]
>>> sorted(s, key=lambda x:abs(x[1]), reverse=True)[:2]
[('John', 3), ('Adam', 3)]
The fix should be easy:
--- heapq.py 2009-04-04 23:27:53.125000000 -0400
+++ heapq2.py 2009-04-05 10:51:32.187500000 -0400
@@ -133 +133 @@
-from operator import itemgetter
+from operator import itemgetter, neg
@@ -334 +334 @@
- it = izip(imap(key, in1), count(), in2) # decorate
+ it = izip(imap(key, in1), imap(neg, count()), in2) # decorate
----------
components: Library (Lib)
messages: 85508
nosy: gsakkis
severity: normal
status: open
title: heapq.nlargest does not perform stable sort
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5697>
_______________________________________
From report at bugs.python.org Sun Apr 5 17:03:35 2009
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 05 Apr 2009 15:03:35 +0000
Subject: [New-bugs-announce] [issue5698] pydoc -w doesn't produce proper HTML
In-Reply-To: <1238943815.07.0.410392153276.issue5698@psf.upfronthosting.co.za>
Message-ID: <1238943815.07.0.410392153276.issue5698@psf.upfronthosting.co.za>
New submission from Matthias Klose <doko at debian.org>:
[forwarded from http://bugs.debian.org/411524]
"""
If you feed the output of pydoc -w [some module] to the w3 validator, it
complains about two issues:
firstly, the doctype is wrong. It should be:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
not
<!doctype...
[note case]
Secondly, no charset is specified. Just doing
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" > in
the head
would probably do.
"""
----------
assignee: georg.brandl
components: Documentation
files: pydoc.diff
keywords: needs review, patch, patch
messages: 85509
nosy: doko, georg.brandl
severity: normal
status: open
title: pydoc -w doesn't produce proper HTML
type: behavior
Added file: http://bugs.python.org/file13619/pydoc.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5698>
_______________________________________
From report at bugs.python.org Sun Apr 5 17:08:18 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 05 Apr 2009 15:08:18 +0000
Subject: [New-bugs-announce] [issue5699] Strange interaction between -m and
pydoc
In-Reply-To: <1238944098.24.0.423048107372.issue5699@psf.upfronthosting.co.za>
Message-ID: <1238944098.24.0.423048107372.issue5699@psf.upfronthosting.co.za>
New submission from Georg Brandl <georg at python.org>:
If you use "python -m pydoc", pydoc will not find standard modules
written in Python. This leads to a traceback for example using "python
-m pydoc -k sys". Somehow, sys.path gets modified in a strange way,
which can be seen from
$ python -i -m pydoc
(...)
>>> import sys
>>> sys.path
[... does not include /lib/python2.6 or /Lib ...]
----------
assignee: ncoghlan
messages: 85512
nosy: georg.brandl, ncoghlan
priority: normal
severity: normal
status: open
title: Strange interaction between -m and pydoc
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5699>
_______________________________________
From report at bugs.python.org Sun Apr 5 17:35:58 2009
From: report at bugs.python.org (Brian Quinlan)
Date: Sun, 05 Apr 2009 15:35:58 +0000
Subject: [New-bugs-announce] [issue5700] io.FileIO calls flush() after file
closed
In-Reply-To: <1238945758.46.0.01809197792.issue5700@psf.upfronthosting.co.za>
Message-ID: <1238945758.46.0.01809197792.issue5700@psf.upfronthosting.co.za>
New submission from Brian Quinlan <brian at sweetapp.com>:
>>> import io
>>> class MyIO(io.FileIO):
... def flush(self):
... print('closed:', self.closed)
...
>>> f = MyIO('test.out', 'wb')
>>> f.close()
closed: True
IMHO, calling flush() after the file has already been closed is
incorrect behaviour. Search for "Possible py3k io wierdness" on
python-dev for discussion.
----------
components: Library (Lib)
files: remove_flush.diff
keywords: patch
messages: 85521
nosy: bquinlan
severity: normal
status: open
title: io.FileIO calls flush() after file closed
versions: Python 3.1
Added file: http://bugs.python.org/file13620/remove_flush.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5700>
_______________________________________
From report at bugs.python.org Sun Apr 5 17:57:31 2009
From: report at bugs.python.org (Yngve AAdlandsvik)
Date: Sun, 05 Apr 2009 15:57:31 +0000
Subject: [New-bugs-announce] [issue5701] ZipFile returns compressed data
stream when encountering unsupported compression method
In-Reply-To: <1238947051.8.0.105309388943.issue5701@psf.upfronthosting.co.za>
Message-ID: <1238947051.8.0.105309388943.issue5701@psf.upfronthosting.co.za>
New submission from Yngve AAdlandsvik <ymgve at start.no>:
The attached .zip archive contains two uncompressed files (2!
SCHEME.Z64, 3!SCHEME.Z64) and two files compressed with IMPLODE (1!
SCHEME.Z64, 4!SCHEME.Z64), a compression method not currently supported
in ZipFile.
When using ZipFile.read() on the latter files, the compressed data
stream is returned, while I assume the proper response would be to
throw an exception of some kind to signal that the method is
unsupported.
----------
components: Library (Lib)
files: Scheme.zip
messages: 85522
nosy: ymgve
severity: normal
status: open
title: ZipFile returns compressed data stream when encountering unsupported compression method
versions: Python 2.6
Added file: http://bugs.python.org/file13621/Scheme.zip
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5701>
_______________________________________
From report at bugs.python.org Sun Apr 5 23:50:34 2009
From: report at bugs.python.org (Retro)
Date: Sun, 05 Apr 2009 21:50:34 +0000
Subject: [New-bugs-announce] [issue5702] str.isprintable() ->
str.is_printable()
In-Reply-To: <1238968234.72.0.0648337520499.issue5702@psf.upfronthosting.co.za>
Message-ID: <1238968234.72.0.0648337520499.issue5702@psf.upfronthosting.co.za>
New submission from Retro <vinetouu at gmail.com>:
Please consider of making the descriptor isprintable() of the str object
be named with an underscore as is_printable().
----------
components: Demos and Tools
messages: 85571
nosy: Retro
severity: normal
status: open
title: str.isprintable() -> str.is_printable()
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5702>
_______________________________________
From report at bugs.python.org Mon Apr 6 00:24:00 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 05 Apr 2009 22:24:00 +0000
Subject: [New-bugs-announce] [issue5703] inside *currentmodule* some links
is disabled
In-Reply-To: <1238970240.42.0.00430283210892.issue5703@psf.upfronthosting.co.za>
Message-ID: <1238970240.42.0.00430283210892.issue5703@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
See http://docs.python.org/library/email.mime.html
Inside MIMEApplication documentation, link to MIMEApplication is enabled
but link to MIMENonMultipart is disabled. This happens because
MIMENonMultipart is not in email.mime.application (specified by
currentmodule directive). Is this sphinx bug? Or should MIMENonMultipart
be written in full name like email.mime.nonmultipart.MIMENonMultipart?
----------
assignee: georg.brandl
components: Documentation
messages: 85579
nosy: georg.brandl, ocean-city
severity: normal
status: open
title: inside *currentmodule* some links is disabled
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5703>
_______________________________________
From report at bugs.python.org Mon Apr 6 00:24:49 2009
From: report at bugs.python.org (Simon Anders)
Date: Sun, 05 Apr 2009 22:24:49 +0000
Subject: [New-bugs-announce] [issue5704] Command line option '-3' should
imply '-t'
In-Reply-To: <1238970289.11.0.298374772869.issue5704@psf.upfronthosting.co.za>
Message-ID: <1238970289.11.0.298374772869.issue5704@psf.upfronthosting.co.za>
New submission from Simon Anders <sanders at fs.tum.de>:
The '-3' command line option in Python 2.6 is supposed to warn whenever
encountering something that would throw an error in Python 3. Mixing of
tabs and spaces has become illegal in Python 3. However, Python 2.6,
called with '-3', passes silently over this unless '-t' was given, too.
Would it not be more consistent to let '-3' imply '-t'?
----------
components: Interpreter Core
messages: 85581
nosy: sanders_muc
severity: normal
status: open
title: Command line option '-3' should imply '-t'
type: behavior
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5704>
_______________________________________
From report at bugs.python.org Mon Apr 6 00:37:56 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 05 Apr 2009 22:37:56 +0000
Subject: [New-bugs-announce] [issue5705] os.getpwent returns unsigned 32bit
value, os.setuid refuses it
In-Reply-To: <1238971076.18.0.458968995084.issue5705@psf.upfronthosting.co.za>
Message-ID: <1238971076.18.0.458968995084.issue5705@psf.upfronthosting.co.za>
New submission from Gregory P. Smith <greg at krypto.org>:
Running test_httpservers on a 64-bit build of Python 2.7 trunk on OS X
10.5: (I added a print "nobody=", nobody)
test_authorization (__main__.CGIHTTPServerTestCase) ... nobody= 4294967294
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 55322)
Traceback (most recent call last):
File "/Users/greg/sandbox/python/trunk/Lib/CGIHTTPServer.py", line
251, in run_cgi
os.setuid(nobody)
OverflowError: signed integer is greater than maximum
----------
assignee: gregory.p.smith
keywords: 64bit
messages: 85582
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: os.getpwent returns unsigned 32bit value, os.setuid refuses it
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/issue5705>
_______________________________________
From report at bugs.python.org Mon Apr 6 06:39:59 2009
From: report at bugs.python.org (Garrett Cooper)
Date: Mon, 06 Apr 2009 04:39:59 +0000
Subject: [New-bugs-announce] [issue5706] setuptools doesn't honor standard
compiler variables
In-Reply-To: <1238992798.79.0.661202545175.issue5706@psf.upfronthosting.co.za>
Message-ID: <1238992798.79.0.661202545175.issue5706@psf.upfronthosting.co.za>
New submission from Garrett Cooper <yanegomi at gmail.com>:
I realize that cross-compilation isn't supported yet, _but_ setuptools
needs to be modified such that standard compilation variables are
supported, e.g. CC, CFLAGS, CPPFLAGS, LD, LDFLAGS, LDLIBS.
The -i, -l, and -L flags with setup.py with build_ext provide a basic
level of support, but unfortunately it doesn't match what these
environment variables provide.
----------
components: Installation
messages: 85611
nosy: yaneurabeya
severity: normal
status: open
title: setuptools doesn't honor standard compiler variables
type: feature request
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5706>
_______________________________________
From report at bugs.python.org Mon Apr 6 09:40:20 2009
From: report at bugs.python.org (epitome83)
Date: Mon, 06 Apr 2009 07:40:20 +0000
Subject: [New-bugs-announce] [issue5707] IDLE will not load
In-Reply-To: <1239003620.62.0.108807854341.issue5707@psf.upfronthosting.co.za>
Message-ID: <1239003620.62.0.108807854341.issue5707@psf.upfronthosting.co.za>
New submission from epitome83 <schadenfreudian at gmail.com>:
I downloaded Python 3.0.1 and installed on Vista. I opened IDLE and it
worked fine. I went into the Preferences to change the keybindings on
the history scrollers. I changed history-next to Ctrl+Down Arrow,
though when I pressed OK it listed only Control as the binding. I then
tried to change history-prev to Ctrl+Up Arrow, but when I pressed OK,
it gave an error that that binding was already taken. The program then
crashed. Since then whenever I try to open IDLE, the pythonw.exe
process appears in my Task Manager briefly, but then it exits, and I
never see any other evidence the program has opened. The command line
still works fine. I tried repairing the installation, uninstalling,
restarting the computer, and removing the leftover registry keys for a
completely clean install, but nothing has worked to be able to reopen
the program.
----------
components: IDLE
messages: 85618
nosy: epitome83
severity: normal
status: open
title: IDLE will not load
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5707>
_______________________________________
From report at bugs.python.org Mon Apr 6 10:41:45 2009
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 06 Apr 2009 08:41:45 +0000
Subject: [New-bugs-announce] [issue5708] Tiny code polishing to
unicode_repeat
In-Reply-To: <1239007305.41.0.910418406517.issue5708@psf.upfronthosting.co.za>
Message-ID: <1239007305.41.0.910418406517.issue5708@psf.upfronthosting.co.za>
New submission from Larry Hastings <larry at hastings.org>:
Two minor tweaks to unicode_repeat:
* If the number of repeats (len) is < 1, we're always going to return
the empty Unicode string. So I incr and return unicode_empty.
* The current code has "if (done < nchars)" around the first copy. A
little data-flow analysis of the code will show you that done is always
0 and nchars is always >= str->length. So the check is
unnecessary--we're always going to do that first copy. I removed the if
and set done to str->length directly.
Hope I got it right!
----------
components: Interpreter Core
files: lch.unicoderepeat.r71304.diff
keywords: patch
messages: 85620
nosy: lhastings
severity: normal
status: open
title: Tiny code polishing to unicode_repeat
versions: Python 3.1
Added file: http://bugs.python.org/file13627/lch.unicoderepeat.r71304.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5708>
_______________________________________
From =?utf-8?b?VGUtasOpIFJvZGdlcnMgPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za Mon Apr 6 18:21:16 2009
From: =?utf-8?b?VGUtasOpIFJvZGdlcnMgPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za (=?utf-8?b?VGUtasOpIFJvZGdlcnMgPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za)
Date: Mon, 06 Apr 2009 16:21:16 +0000
Subject: [New-bugs-announce] [issue5709] PyObject_TypeCheck crashes the
intepreter on extension callback functions
In-Reply-To: <1239034876.99.0.902251790448.issue5709@psf.upfronthosting.co.za>
Message-ID: <1239034876.99.0.902251790448.issue5709@psf.upfronthosting.co.za>
New submission from Te-j? Rodgers <contact at tejerodgers.com>:
When a python callable is called from an extension module using
PyEval_CallObjectWithKeywords, and that callable calls a function in the
extension module that uses PyObject_TypeCheck (or *ParseTuple with
"O!"), the interpreter crashes.
----------
components: Extension Modules
messages: 85651
nosy: trodgers
severity: normal
status: open
title: PyObject_TypeCheck crashes the intepreter on extension callback functions
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5709>
_______________________________________
From report at bugs.python.org Mon Apr 6 19:28:46 2009
From: report at bugs.python.org (Greg Holling)
Date: Mon, 06 Apr 2009 17:28:46 +0000
Subject: [New-bugs-announce] [issue5710] ctypes should return composite
types from callbacks
In-Reply-To: <1239038926.27.0.792638874347.issue5710@psf.upfronthosting.co.za>
Message-ID: <1239038926.27.0.792638874347.issue5710@psf.upfronthosting.co.za>
New submission from Greg Holling <gholling at vni.com>:
We have an application that calls a 3rd party library that returns a
structure (by value) from a callback. I'm including some sample code
that duplicates the behavior. The problem is that return types from
callbacks cannot be anything other than simple datatypes (c_int,
c_float, ..., c_void_p). For other datatypes (STRUCTURE, POINTER, ...),
ctypes returns the following error:
"invalid result type for callback function"
The error message comes from callback.c, in function AllocFunctionCallback.
I think this may be a duplicate of issue #1574584.
I've tested this on Windows and linux; I'm including a Makefile and
source code that works on Windows/cygwin.
------ file: Makefile ----
all: hello.dll hello.exe hello_dll.exe
clean:
rm *.exe *.dll
hello.exe: hello.h hello.c hello_main.c
gcc hello.c hello_main.c -o hello.exe --save-temps
hello.dll: hello.h hello.c
gcc -mno-cygwin -shared hello.c -o hello.dll --save-temps
hello_dll.exe: hello.h hello.c
gcc hello_main.c -L. -lhello -o hello_main.exe
------ file: hello.h ----
struct helloStruct {
int i;
float f;
int i2;
int i3;
};
float fxn (struct helloStruct callback());
------ file: hello.c ----
#include <stdio.h>
#include "hello.h"
float fxn (struct helloStruct callback()) {
struct helloStruct result = callback();
printf ("i: %d\n", result.i);
printf ("f: %f\n", result.f);
return result.f * result.i;
}
------ file: hello_main.c ----
#include <stdio.h>
#include "hello.h"
struct helloStruct callback();
int main (int argc, char **argv) {
float f;
struct helloStruct result;
printf ("Hello world\n");
f = fxn (callback);
printf ("Callback result: %f\n", f);
}
struct helloStruct callback () {
struct helloStruct result;
result.i = 10;
result.f = 3.14159;
return result;
}
int int_callback () {
return 42;
}
------ file: hello.py ----
from ctypes import cdll, c_char, c_int, c_float, Structure, CFUNCTYPE,
POINTER, c_char_p
class helloStruct (Structure):
pass
helloStruct._fields_ = [
('i', c_int),
('f', c_float) ]
def callback():
print ("callback()")
hs = helloStruct()
hs.i = 10
hs.f = 25.5
return hs
libc = cdll.msvcrt
#helloLib = libc.load_library("hello")
#helloLib = libc.hello
helloLib = cdll.hello
helloLib.fxn.restype = helloStruct
# It looks like only simple return types are supported for
# callback functions. simple = c_int, c_float, ...
# Python bug # 1574584 - status: closed.
# Suggests posting to ctypes-users, but I don't see any recent activity.
#
TMP_FCN = CFUNCTYPE (POINTER(c_char)) # Error message
#TMP_FCN = CFUNCTYPE (c_char_p) # Runs, but invalid result
#TMP_FCN = CFUNCTYPE (c_void_p) # Runs, but invalid result
#TMP_FCN = CFUNCTYPE (c_int) # Runs, but invalid result
#TMP_FCN = CFUNCTYPE (POINTER(c_int)) # Error message
#TMP_FCN = CFUNCTYPE (POINTER(helloStruct)) # Error message
#TMP_FCN = CFUNCTYPE (helloStruct) # Error message
callback_fcn = TMP_FCN (callback)
result = helloLib.fxn (callback_fcn)
# 2.5
#print "result: ", result
# 3.0
print ("result: ", result)
----------
assignee: theller
components: ctypes
messages: 85654
nosy: gholling, theller
severity: normal
status: open
title: ctypes should return composite types from callbacks
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5710>
_______________________________________
From report at bugs.python.org Mon Apr 6 19:31:27 2009
From: report at bugs.python.org (Kevin Watters)
Date: Mon, 06 Apr 2009 17:31:27 +0000
Subject: [New-bugs-announce] [issue5711] socket.create_connection not in
__all__
In-Reply-To: <1239039087.86.0.623299496867.issue5711@psf.upfronthosting.co.za>
Message-ID: <1239039087.86.0.623299496867.issue5711@psf.upfronthosting.co.za>
New submission from Kevin Watters <kevinwatters at gmail.com>:
socket.create_connection was added in 2.6, but does not get exposed in
socket's __all__.
Attached is the simple fix against 2.6's socket.py.
----------
components: Library (Lib)
files: socket-all-26.diff
keywords: patch
messages: 85656
nosy: kevinwatters
severity: normal
status: open
title: socket.create_connection not in __all__
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13636/socket-all-26.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5711>
_______________________________________
From report at bugs.python.org Mon Apr 6 19:45:11 2009
From: report at bugs.python.org (daku9999)
Date: Mon, 06 Apr 2009 17:45:11 +0000
Subject: [New-bugs-announce] [issue5712] tkinter - askopenfilenames returns
string instead of tuple in windows 2.6.1 release
In-Reply-To: <1239039911.64.0.172824576559.issue5712@psf.upfronthosting.co.za>
Message-ID: <1239039911.64.0.172824576559.issue5712@psf.upfronthosting.co.za>
New submission from daku9999 <daku9999 at gmail.com>:
from tkFileDialog import askopenfilenames
a = askopenfilenames()
print a
print type(a)
'''
--output--
J:/PortablePython_1.1_py2.6.1/Aatest26/tk_new/rgb2hex.py
J:/PortablePython_1.1_py2.6.1/Aatest26/tk_new/bluebtn.jpg
J:/PortablePython_1.1_py2.6.1/Aatest26/tk_new/redbtn.jpg
<type 'unicode'>
'''
---- behaviour seen on windows xp 2.6.1 python release. Linux
distributions seem fine.
---- parsing above string (as it's not a tuple anymore) is difficult as
it is a list of filenames separated by a space but spaces can be in the
middle of filenames.
----------
components: Tkinter
messages: 85658
nosy: daku9999
severity: normal
status: open
title: tkinter - askopenfilenames returns string instead of tuple in windows 2.6.1 release
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5712>
_______________________________________
From report at bugs.python.org Mon Apr 6 22:30:25 2009
From: report at bugs.python.org (Mark Sapiro)
Date: Mon, 06 Apr 2009 20:30:25 +0000
Subject: [New-bugs-announce] [issue5713] smtplib gets out of sync if server
returns a 421 status
In-Reply-To: <1239049825.43.0.457403750239.issue5713@psf.upfronthosting.co.za>
Message-ID: <1239049825.43.0.457403750239.issue5713@psf.upfronthosting.co.za>
New submission from Mark Sapiro <mark at msapiro.net>:
RFC821 upon which smtplib was originally based does not define a 421
status code and implies the server should only disconnect in response to
a QUIT command.
Subsequent extensions in RFC2821 (and now RFC5321) define situations
under which the server may return a 421 status and disconnect. This
leads to the following problem.
An smtplib.SMTP() instance is created and its sendmail() method is
called with a list of recipients which contains several invalid, local
addresses. sendmail() processes the recipient list, calling the rcpt()
method for each. Some of these may be accepted with a 250 or 251 status
and some may be rejected with a 550 or other status. The rejects are
kept in a dictionary to be eventually returned as the sendmail() result.
However, with the Postfix server at least, after 20 rejects, the server
sends a 421 Too many errors reply and disconnects, but sendmail
continues to process and this results in raising
SMTPServerDisconnected("Connection unexpectedly closed") and the
response dictionary containing the invalid addresses and their responses
is lost.
The caller may see the exception as retryable and may retry the send
after some delay, but since the caller has received no information about
the invalid addresses, it sends the same recipient list and the scenario
repeats.
----------
components: Library (Lib)
messages: 85666
nosy: msapiro
severity: normal
status: open
title: smtplib gets out of sync if server returns a 421 status
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5713>
_______________________________________
From report at bugs.python.org Tue Apr 7 02:24:06 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 07 Apr 2009 00:24:06 +0000
Subject: [New-bugs-announce] [issue5714]
CGIHTTPServer._url_collapse_path_split should live elsewhere
In-Reply-To: <1239063845.81.0.120232947257.issue5714@psf.upfronthosting.co.za>
Message-ID: <1239063845.81.0.120232947257.issue5714@psf.upfronthosting.co.za>
New submission from Gregory P. Smith <greg at krypto.org>:
CGIHTTPServer._url_collapse_path_split should probably live in a more
general library and become a documented API. Perhaps in urlparse?
----------
keywords: easy
messages: 85679
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: CGIHTTPServer._url_collapse_path_split should live elsewhere
type: feature request
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5714>
_______________________________________
From report at bugs.python.org Tue Apr 7 02:30:50 2009
From: report at bugs.python.org (Donghyun Kim)
Date: Tue, 07 Apr 2009 00:30:50 +0000
Subject: [New-bugs-announce] [issue5715] listen socket close
in SocketServer.ForkingMixIn.process_request()
In-Reply-To: <1239064250.04.0.401358738839.issue5715@psf.upfronthosting.co.za>
Message-ID: <1239064250.04.0.401358738839.issue5715@psf.upfronthosting.co.za>
New submission from Donghyun Kim <uryan003 at gmail.com>:
During implement simple forking TCP server, I got the hang-up child
process binding listen socket which caused parent(listen/accept)
restarting failed. (port in use)
Because child process does something with connected socket, there's no
need to bind listen socket in child process.
(finish_request() calls RequestHandlerClass with connected socket(=request))
Simply add self.socket.close() in the beginning of forked child process.
SocketServer.ForkingMixIn :
def process_request(self, request, client_address):
"""Fork a new subprocess to process the request."""
self.collect_children()
pid = os.fork()
if pid:
# Parent process
if self.active_children is None:
self.active_children = []
self.active_children.append(pid)
self.close_request(request)
return
else:
# Child process.
# This must never return, hence os._exit()!
self.socket.close() # close parent's listen socket in child
try:
self.finish_request(request, client_address)
os._exit(0)
except:
try:
self.handle_error(request, client_address)
finally:
os._exit(1)
----------
components: Library (Lib)
messages: 85680
nosy: ryan003
severity: normal
status: open
title: listen socket close in SocketServer.ForkingMixIn.process_request()
type: behavior
versions: Python 2.4, Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5715>
_______________________________________
From report at bugs.python.org Tue Apr 7 14:07:06 2009
From: report at bugs.python.org (Tres Seaver)
Date: Tue, 07 Apr 2009 12:07:06 +0000
Subject: [New-bugs-announce] [issue5716] Overzealous deprecation of
BaseException.message
In-Reply-To: <1239106026.05.0.616331762443.issue5716@psf.upfronthosting.co.za>
Message-ID: <1239106026.05.0.616331762443.issue5716@psf.upfronthosting.co.za>
New submission from Tres Seaver <tseaver at agendaless.com>:
I'm working on cleaning up deprecations for Zope and related
packages under Python 2.6. The irony here is that I'm receiving
deprecation warnings for custom exception classes which had a 'message'
attribute long before the abortive attempt to add them to the
BaseException type, which hardly seems reasonable.
For instance, docutils.parsers.rst defines a DirectiveError which takes
two arguments, 'level' and 'message', and therefore gets hit with the
deprecation (even though it never used the new signature). Likewise,
ZODB.POSException defines a ConflictError type which takes 'message' as
one of several arguments, all optional, and has since at least 2002.
I don't think either of these classes should be subject to a deprecation
warning for a feature they never used or depended on.
----------
components: Library (Lib)
messages: 85695
nosy: tseaver
severity: normal
status: open
title: Overzealous deprecation of BaseException.message
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5716>
_______________________________________
From report at bugs.python.org Tue Apr 7 17:03:50 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 07 Apr 2009 15:03:50 +0000
Subject: [New-bugs-announce] [issue5717] os.defpath includes unix /bin on
windows
In-Reply-To: <1239116630.78.0.64068842306.issue5717@psf.upfronthosting.co.za>
Message-ID: <1239116630.78.0.64068842306.issue5717@psf.upfronthosting.co.za>
New submission from anatoly techtonik <techtonik at gmail.com>:
>>> import os
>>> os.defpath
'.;C:\\bin'
>>> os.path.defpath
'.;C:\\bin'
>>>
These are invalid paths on windows.
----------
components: Library (Lib)
messages: 85708
nosy: techtonik
severity: normal
status: open
title: os.defpath includes unix /bin on windows
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5717>
_______________________________________
From report at bugs.python.org Tue Apr 7 17:15:42 2009
From: report at bugs.python.org (David Byrne)
Date: Tue, 07 Apr 2009 15:15:42 +0000
Subject: [New-bugs-announce] [issue5718] Problem compiling ffi part of build
on AIX 5.3.
In-Reply-To: <1239117342.9.0.186105014374.issue5718@psf.upfronthosting.co.za>
Message-ID: <1239117342.9.0.186105014374.issue5718@psf.upfronthosting.co.za>
New submission from David Byrne <David.Byrne at cambridge-na.com>:
I am using AIX 5.3 xlc 9.0. I am unable to get the libffi section to
build. It also happens with the separate libffi code, so I will try to
report there as well. I get the following:
cc_r -qlanglvl=extc89 -DNDEBUG -O -I.
-I/appl/bwc/src/Python-2.6.1/./Include
-Ibuild/temp.aix-5.3-2.6/libffi/include -Ibuild/temp.aix-5.3-2.6/libffi
-I/appl/bwc/src/Python-2.6.1/Modules/_ctypes/libffi/src
-I/appl/bwc/local2/include -I. -IInclude -I./Include
-I/usr/local/include -I/appl/bwc/src/Python-2.6.1/Include
-I/appl/bwc/src/Python-2.6.1 -c
/appl/bwc/src/Python-2.6.1/Modules/_ctypes/libffi/src/powerpc/aix_closure.S
-o
build/temp.aix-5.3-2.6/appl/bwc/src/Python-2.6.1/Modules/_ctypes/libffi/src/powerpc/aix_closure.o
Assembler:
/tmp/xlcS00-Mgqd.s: line 111: undefined symbol ".ffi_closure_helper_DARWIN"
/tmp/xlcS00-Mgqd.s: line 111: illegal expression type for branch address
----------
assignee: theller
components: ctypes
messages: 85714
nosy: dbyrne, theller
severity: normal
status: open
title: Problem compiling ffi part of build on AIX 5.3.
type: compile error
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5718>
_______________________________________
From report at bugs.python.org Tue Apr 7 18:01:27 2009
From: report at bugs.python.org (Marius Gedminas)
Date: Tue, 07 Apr 2009 16:01:27 +0000
Subject: [New-bugs-announce] [issue5719] optparse: please provide a usage
example in the module docstring
In-Reply-To: <1239120087.77.0.885148880477.issue5719@psf.upfronthosting.co.za>
Message-ID: <1239120087.77.0.885148880477.issue5719@psf.upfronthosting.co.za>
New submission from Marius Gedminas <marius at gedmin.as>:
Please add a simple usage example to the module docstring in
optparse.py. The example available in the Python library reference
would suffice (see http://python.org/doc/current/library/optparse.html).
Rationale: optparse is convenient, but a bit unintuitive. As a single
data point, it took me a couple of years until I started remembering the
syntax without having to refer to the documentation (compare this with,
e.g. the csv module which you'll remember how to use after reading the
docs once). Intuitively I always typed pydoc optparse in a terminal
window and was disappointed with the lack of examples. The online docs
are good, but not as easy to reach as pydoc.
In my experience, it's quite often that when you reach for optparse
you're alreay shaving a yak (solving a problem needed to solve the real
problem), and the five extra mouse clicks needed to find optparse's docs
in the browser are rather disruptive.
----------
assignee: georg.brandl
components: Documentation
messages: 85722
nosy: georg.brandl, mgedmin
severity: normal
status: open
title: optparse: please provide a usage example in the module docstring
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5719>
_______________________________________
From report at bugs.python.org Tue Apr 7 23:57:49 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Tue, 07 Apr 2009 21:57:49 +0000
Subject: [New-bugs-announce] [issue5720] ctime: I don't think that word
means what you think it means.
In-Reply-To: <1239141469.77.0.706973197517.issue5720@psf.upfronthosting.co.za>
Message-ID: <1239141469.77.0.706973197517.issue5720@psf.upfronthosting.co.za>
New submission from Zooko O'Whielacronx <zooko at zooko.com>:
The stat module currently uses the "st_ctime" slot to hold two kinds
values which are semantically different but which are frequently
confused with one another. It chooses which kind of value to put in
there based on platform -- Windows gets the file creation time and all
other platforms get the "ctime". The only sane way to use this API is
then to switch on platform:
if platform.system() == "Windows":
metadata["creation time"] = s.st_ctime
else:
metadata["unix ctime"] = s.st_ctime
(That is an actual code snippet from the Allmydata-Tahoe project.)
Many or even most programmers incorrectly think that unix ctime is file
creation time, so instead of using the sane idiom above, they write the
following:
metadata["ctime"] = s.st_ctime
thus passing on the confusion to the users of their metadata, who may
not know on which platform this metadata was created. This is the
situation we have found ourselves in for the Allmydata-Tahoe project --
we now have a bunch of "ctime" values stored in our filesystem and no
way to tell which kind they were.
More and more filesystems such as ZFS and Macintosh apparently offer
creation time nowadays.
I propose the following changes:
1. Add a "st_crtime" field which gets populated on filesystems
(Windows, ZFS, Mac) which can do so.
That is hopefully not too controversial and we could proceed to do so
even if the next proposal gets bogged down:
2. Add a "st_unixctime" field which gets populated *only* by the unix
ctime and never by any other value (even on Windows, where the unix
ctime *is* available even though nobody cares about it), and deprecate
the hopelessly ambiguous "st_ctime" field.
You may be interested in http://allmydata.org/trac/tahoe/ticket/628
("mtime" and "ctime": I don't think that word means what you think it
means.) where the Allmydata-Tahoe project is carefully unpicking the
mess we made for ourselves by confusing ctime with file-creation time.
----------
components: Library (Lib)
messages: 85750
nosy: zooko
severity: normal
status: open
title: ctime: I don't think that word means what you think it means.
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5720>
_______________________________________
From report at bugs.python.org Wed Apr 8 11:23:05 2009
From: report at bugs.python.org (Tim Golden)
Date: Wed, 08 Apr 2009 09:23:05 +0000
Subject: [New-bugs-announce] [issue5721] msi.py still tries to copy
non-existent test/README
In-Reply-To: <1239182585.76.0.888462056491.issue5721@psf.upfronthosting.co.za>
Message-ID: <1239182585.76.0.888462056491.issue5721@psf.upfronthosting.co.za>
New submission from Tim Golden <mail at timgolden.me.uk>:
tools/msi/msi.py is still trying to copy the README file from the
lib/test directory. This file was removed in r70872. Patch attached
against r71393 of msi.py.
----------
components: Build, Demos and Tools, Windows
files: msi.r71393.patch
keywords: patch
messages: 85764
nosy: loewis, tim.golden
severity: normal
status: open
title: msi.py still tries to copy non-existent test/README
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file13650/msi.r71393.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5721>
_______________________________________
From report at bugs.python.org Wed Apr 8 12:49:04 2009
From: report at bugs.python.org (Tennessee Leeuwenburg)
Date: Wed, 08 Apr 2009 10:49:04 +0000
Subject: [New-bugs-announce] [issue5722] settimer / gettimer functionality
on FreeBSD 6.3 (not 7.x)
In-Reply-To: <1239187744.6.0.565034475162.issue5722@psf.upfronthosting.co.za>
Message-ID: <1239187744.6.0.565034475162.issue5722@psf.upfronthosting.co.za>
New submission from Tennessee Leeuwenburg <tleeuwenburg at gmail.com>:
Tests fail on FreeBSD 6.3
http://www.python.org/dev/buildbot/trunk/x86%20FreeBSD%203%20trunk/build
s/77/step-test/0
Relevant extract from parent issue, post by Guilherme Polo:
-----------------------------------------------------------
Trent Nelson kindly gave me access to his FreeBSD 6.2 buildbot so I had
chance to do some tests. The problem happens when Python is built
against or libc_r, or if you are using libmap you won't need to
recompile but the problem still happens when using libc_r.
I started searching in the FreeBSD bug tracker and found this issue:
http://www.freebsd.org/cgi/query-pr.cgi?pr=threads/49087 which seems
very similar to the problem related here.
I've also done a very simple "test" in C, just to demonstrate that this
issue isn't related to Python at all:
#include <stdio.h>
#include <signal.h>
#include <sys/time.h>
void h(int signo)
{
struct itimerval t;
getitimer(ITIMER_PROF, &t);
printf("%d %d\n", t.it_value.tv_sec, t.it_value.tv_usec);
printf("deactive ITIMER_PROF\n");
t.it_value.tv_sec = 0;
t.it_value.tv_usec = 0;
setitimer(ITIMER_PROF, &t, &t);
}
int main(void)
{
struct itimerval ival;
ival.it_value.tv_sec = 1;
ival.it_value.tv_usec = 0;
ival.it_interval.tv_sec = 1;
ival.it_interval.tv_usec = 0;
signal(SIGPROF, h);
printf("%d\n", setitimer(ITIMER_PROF, &ival, NULL));
alarm(2);
while (1) {
getitimer(ITIMER_PROF, &ival);
if (ival.it_value.tv_sec == 0 && ival.it_value.tv_usec == 0)
break;
}
return 0;
}
When I compile this using -lc_r then the callback "h" is never called
and then the alarm is fired. Compiling against pthread, thr or nothing
(since this example doesn't need any threading library) doesn't
demonstrate this problem and all is fine (callback "h" is invoked,
infinite loop finishes and test returns 0).
Should further discussion be moved to python-dev ? I'm somewhat stuck on
how to resolve this, besides saying to upgrade to FreeBSD 7 which uses
libthr by default.
----------
messages: 85765
nosy: tleeuwenburg at gmail.com
severity: normal
status: open
title: settimer / gettimer functionality on FreeBSD 6.3 (not 7.x)
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5722>
_______________________________________
From report at bugs.python.org Wed Apr 8 17:43:26 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Apr 2009 15:43:26 +0000
Subject: [New-bugs-announce] [issue5723] Incomplete json tests
In-Reply-To: <1239205406.15.0.353111609778.issue5723@psf.upfronthosting.co.za>
Message-ID: <1239205406.15.0.353111609778.issue5723@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
Looking at the tests it seems that the pure-Python paths of json are
partly untested. In particular, py_make_scanner (as oppose to
c_make_scanner).
----------
assignee: bob.ippolito
components: Tests
messages: 85770
nosy: benjamin.peterson, bob.ippolito, pitrou
priority: high
severity: normal
stage: test needed
status: open
title: Incomplete json tests
type: behavior
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5723>
_______________________________________
From report at bugs.python.org Wed Apr 8 23:28:14 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 08 Apr 2009 21:28:14 +0000
Subject: [New-bugs-announce] [issue5724] 2.6.2c1 fails to pass test_cmath on
Solaris10
In-Reply-To: <1239226094.42.0.345959405343.issue5724@psf.upfronthosting.co.za>
Message-ID: <1239226094.42.0.345959405343.issue5724@psf.upfronthosting.co.za>
New submission from Skip Montanaro <skip at pobox.com>:
I configured and built Python 2.6.2c1 on Solaris 10 using gcc 4.2.
All tests pass except cmath:
% LD_LIBRARY_PATH=. ./python Lib/test/regrtest.py -v test_cmath
test_cmath
test_abs (test.test_cmath.CMathTests) ... ok
test_cmath_matches_math (test.test_cmath.CMathTests) ... ok
test_constants (test.test_cmath.CMathTests) ... ok
test_input_type (test.test_cmath.CMathTests) ... ok
test_isinf (test.test_cmath.CMathTests) ... ok
test_isnan (test.test_cmath.CMathTests) ... ok
test_phase (test.test_cmath.CMathTests) ... ok
test_polar (test.test_cmath.CMathTests) ... ok
test_rect (test.test_cmath.CMathTests) ... ok
test_specific_values (test.test_cmath.CMathTests) ... FAIL
test_user_object (test.test_cmath.CMathTests) ... ok
======================================================================
FAIL: test_specific_values (test.test_cmath.CMathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/tuba/skipm/src/Python-2.6.2c1/Lib/test/test_cmath.py",
line 338, in test_specific_values
self.fail('OverflowError not raised in test %s' % test_str)
AssertionError: OverflowError not raised in test exp0052:
exp(complex(710.0, 1.5))
----------------------------------------------------------------------
Ran 11 tests in 0.048s
FAILED (failures=1)
test test_cmath failed -- Traceback (most recent call last):
File "/home/tuba/skipm/src/Python-2.6.2c1/Lib/test/test_cmath.py",
line 338, in test_specific_values
self.fail('OverflowError not raised in test %s' % test_str)
AssertionError: OverflowError not raised in test exp0052:
exp(complex(710.0, 1.5))
1 test failed:
test_cmath
Since we are so close to release I'm assigning it to Barry, though
Mark Dickinson is probably the best person to look at this problem. I
think this is a long-standing Solaris/cmath issue. I'm sorry Mark and
I didn't connect long enough at PyCon to dig into this. It may not be
serious enough to hold up a final release, but I wanted to mention the
problem so it's recognized.
----------
assignee: barry
components: Tests
messages: 85784
nosy: barry, skip.montanaro
severity: normal
status: open
title: 2.6.2c1 fails to pass test_cmath on Solaris10
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5724>
_______________________________________
From report at bugs.python.org Thu Apr 9 07:20:56 2009
From: report at bugs.python.org (jvdias)
Date: Thu, 09 Apr 2009 05:20:56 +0000
Subject: [New-bugs-announce] [issue5725] process SysV-Semaphore support
In-Reply-To: <1239254455.57.0.547868960031.issue5725@psf.upfronthosting.co.za>
Message-ID: <1239254455.57.0.547868960031.issue5725@psf.upfronthosting.co.za>
New submission from jvdias <jason.vas.dias at gmail.com>:
Please could we have an API in the Python Core for PROCESS
as opposed to THREAD Semaphores , to enable facilities such
as I have done in the attached example "psempy.so" compiled
"C" python module.
ie. I'd like to be able to :
'
import sys.semget sys.semop sys.semctl
'
Because of being un-able to do this, the attached "psem.*"
module provides a workaround for my application.
Should I expand this into a Python Add-On or will full
support for SysV PROCESS Semaphores be coming to Python core soon ?
----------
files: psempy.c
messages: 85791
nosy: jvdias
severity: normal
status: open
title: process SysV-Semaphore support
type: feature request
Added file: http://bugs.python.org/file13655/psempy.c
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5725>
_______________________________________
From report at bugs.python.org Thu Apr 9 11:54:44 2009
From: report at bugs.python.org (Floris Bruynooghe)
Date: Thu, 09 Apr 2009 09:54:44 +0000
Subject: [New-bugs-announce] [issue5726] ld_so_aix does exit successfully
even in case of failure
In-Reply-To: <1239270884.66.0.724599515484.issue5726@psf.upfronthosting.co.za>
Message-ID: <1239270884.66.0.724599515484.issue5726@psf.upfronthosting.co.za>
New submission from Floris Bruynooghe <floris.bruynooghe at gmail.com>:
ld_so_aix is used to invoke the linker correctly on AIX. However when
the linking fails the script happily returns 0 and a Makefile using it
will assume all went well.
See the trivial patch attached.
----------
components: Build
files: ld_so_aix.diff
keywords: patch
messages: 85807
nosy: flub
severity: normal
status: open
title: ld_so_aix does exit successfully even in case of failure
type: compile error
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13661/ld_so_aix.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5726>
_______________________________________
From report at bugs.python.org Thu Apr 9 13:25:05 2009
From: report at bugs.python.org (Wolfgang Schnerring)
Date: Thu, 09 Apr 2009 11:25:05 +0000
Subject: [New-bugs-announce] [issue5727] doctest pdb readline broken
In-Reply-To: <1239276305.19.0.526867750163.issue5727@psf.upfronthosting.co.za>
Message-ID: <1239276305.19.0.526867750163.issue5727@psf.upfronthosting.co.za>
New submission from Wolfgang Schnerring <wosc+python at wosc.de>:
When pdb is called from inside a doctest under python2.5, the readline
keys do not work anymore -- like they did just fine in 2.4.
Steps to reproduce:
1. Create two files, foo.txt and foo.py, like so:
$ cat > foo.txt
>>> import pdb; pdb.set_trace()
$ cat > foo.py
import doctest; doctest.testfile('foo.txt')
2. run it
$ python2.5 foo.py
3. If I now press Ctrl-P, I get "^P" printed on the prompt, instead of
going back in the readline history. Likewise, the arrow keys print
escape sequences instead of moving the cursor.
----------
components: Library (Lib)
messages: 85808
nosy: wosc
severity: normal
status: open
title: doctest pdb readline broken
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5727>
_______________________________________
From report at bugs.python.org Thu Apr 9 14:15:24 2009
From: report at bugs.python.org (Robert Collins)
Date: Thu, 09 Apr 2009 12:15:24 +0000
Subject: [New-bugs-announce] [issue5728] Support telling TestResult objects
a test run has finished
In-Reply-To: <1239279324.74.0.826216289254.issue5728@psf.upfronthosting.co.za>
Message-ID: <1239279324.74.0.826216289254.issue5728@psf.upfronthosting.co.za>
New submission from Robert Collins <robertc at robertcollins.net>:
Original mail:
JML's testtools has a TestResult subclass with a done() method. The
reason for this method is to allow doing things after the last test has
run. While a result can infer 'first test' it can't infer 'last test'
without ugliness like __del__.
Some uses for this are:
- reporting summary data
- closing external resources like log files, sockets to remote machines
etc
- <your idea here>
This can be added quite safely I think - check for the attribute, and if
present call it.
done() could be spelt differently - I don't think anyone would care.
testsFinished()
finished()
etc.
----------
components: Library (Lib)
messages: 85812
nosy: michael.foord, olemis, rbcollins
severity: normal
status: open
title: Support telling TestResult objects a test run has finished
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5728>
_______________________________________
From =?utf-8?q?Walter_D=C3=B6rwald_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za Thu Apr 9 19:15:30 2009
From: =?utf-8?q?Walter_D=C3=B6rwald_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za (=?utf-8?q?Walter_D=C3=B6rwald_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za)
Date: Thu, 09 Apr 2009 17:15:30 +0000
Subject: [New-bugs-announce] [issue5729] Allows tabs for indenting JSON
output
In-Reply-To: <1239297330.19.0.24635332127.issue5729@psf.upfronthosting.co.za>
Message-ID: <1239297330.19.0.24635332127.issue5729@psf.upfronthosting.co.za>
New submission from Walter D?rwald <walter at livinglogic.de>:
This patchs makes it possible to use tabs for indenting the output of
json.dumps(). With this patch the indent argument can now be either an
integer specifying the number of spaces per indent level or a string
specifying the indent string directly::
json.dumps(list(range(10), indent=3) # three spaces per indent
json.dumps(list(range(10), indent="\t") # one tab per indent
----------
components: Library (Lib)
files: json.diff
keywords: patch
messages: 85821
nosy: doerwalter
severity: normal
status: open
title: Allows tabs for indenting JSON output
type: feature request
versions: Python 3.1
Added file: http://bugs.python.org/file13664/json.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5729>
_______________________________________
From report at bugs.python.org Thu Apr 9 21:35:30 2009
From: report at bugs.python.org (Dan Schult)
Date: Thu, 09 Apr 2009 19:35:30 +0000
Subject: [New-bugs-announce] [issue5730] setdefault speedup
In-Reply-To: <1239305730.8.0.484085764135.issue5730@psf.upfronthosting.co.za>
Message-ID: <1239305730.8.0.484085764135.issue5730@psf.upfronthosting.co.za>
New submission from Dan Schult <dschult at colgate.edu>:
In the depths of dictobject.c one can see that dict_setdefault uses two
identical calls to PyObject_Hash and ma_lookup. The first to see if the
item is in the dict, the second (only if key is not present) to add the
item to the dict.
This second lookup (and hash) are not needed and can be avoided by
inlining a portion of PyDict_SetItem instead of calling the entire
subroutine.
----------
components: Interpreter Core
messages: 85824
nosy: dschult
severity: normal
status: open
title: setdefault speedup
type: performance
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5730>
_______________________________________
From report at bugs.python.org Thu Apr 9 22:51:24 2009
From: report at bugs.python.org (Paul Moore)
Date: Thu, 09 Apr 2009 20:51:24 +0000
Subject: [New-bugs-announce] [issue5731] bdist_wininst no longer works on
non-Windows platforms
In-Reply-To: <1239310284.73.0.299420830333.issue5731@psf.upfronthosting.co.za>
Message-ID: <1239310284.73.0.299420830333.issue5731@psf.upfronthosting.co.za>
New submission from Paul Moore <p.f.moore at gmail.com>:
In revision 62197, Mon Apr 7 01:53:39 2008 UTC, Mark Hammond added code
to Lib/distutils/command/bdist_wininst.py which was intended to select
an architecture-specific installer executable.
In doing so, the code appears to have broken the ability to build
installers on non-Windows platforms.
The current code is
if self.plat_name == 'win32':
sfix = ''
else:
sfix = self.plat_name[3:] # strip 'win' - leaves eg '-amd64'
filename = os.path.join(directory, "wininst-%.1f%s.exe" % (bv, sfix))
return open(filename, "rb").read()
This says "strip 'win'", but in practice strips the first 3 characters
from any plat_name other than win32.
I've attached an untested patch to fix this, by setting sfix to '' if
self.plat_name doesn't start with 'win'.
----------
assignee: tarek
components: Distutils
files: bdist_wininst.patch
keywords: patch
messages: 85825
nosy: mhammond, pmoore, tarek
priority: normal
severity: normal
status: open
title: bdist_wininst no longer works on non-Windows platforms
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file13666/bdist_wininst.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5731>
_______________________________________
From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za Fri Apr 10 01:15:36 2009
From: =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za (=?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za)
Date: Thu, 09 Apr 2009 23:15:36 +0000
Subject: [New-bugs-announce] [issue5732] add a new command called "check"
into Distutils
In-Reply-To: <1239318936.64.0.115245902927.issue5732@psf.upfronthosting.co.za>
Message-ID: <1239318936.64.0.115245902927.issue5732@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
Right now, both register and sdist commands are implementing a
check_metadata function to check that the metadata are complete enough.
check will refactor this and also add a test to validate that the
long_description is/is not reST compliant (if asked *and* if docutils is
present)
of course distutils will not introduce a hard dependency on docutils and
both register and sdist wil continue to work the same way (but use check
underneath)
----------
assignee: tarek
messages: 85835
nosy: tarek
severity: normal
status: open
title: add a new command called "check" into Distutils
type: feature request
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5732>
_______________________________________
From report at bugs.python.org Fri Apr 10 08:08:20 2009
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Fri, 10 Apr 2009 06:08:20 +0000
Subject: [New-bugs-announce] [issue5733] py3_test_grammar.py syntax error
In-Reply-To: <1239343700.07.0.933756737051.issue5733@psf.upfronthosting.co.za>
Message-ID: <1239343700.07.0.933756737051.issue5733@psf.upfronthosting.co.za>
New submission from Kurt B. Kaiser <kbk at shore.net>:
Try running it as a script:
File "Lib/lib2to3/tests/data/py3_test_grammar.py", line 130
x = ...
^
SyntaxError: invalid syntax
Furthermore, testEllipsis seems invalid. What is intended?
>>> class C:
def __getitem__(self, x): return x
>>> c[...]
Ellipsis
>>> c[. . .]
Ellipsis
>>> eval(...)
SyntaxError: invalid syntax
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 85840
nosy: collinwinter, kbk
priority: normal
severity: normal
status: open
title: py3_test_grammar.py syntax error
type: compile error
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5733>
_______________________________________
From report at bugs.python.org Sat Apr 11 12:41:09 2009
From: report at bugs.python.org (Brian Quinlan)
Date: Sat, 11 Apr 2009 10:41:09 +0000
Subject: [New-bugs-announce] [issue5734] BufferedRWPair broken
In-Reply-To: <1239446469.87.0.208856663223.issue5734@psf.upfronthosting.co.za>
Message-ID: <1239446469.87.0.208856663223.issue5734@psf.upfronthosting.co.za>
New submission from Brian Quinlan <brian at sweetapp.com>:
The C implementation:
- doesn't correctly initialize its reader and writer instances
- incorrectly maps its "readinto" method to another class
- incorrectly delegates its "closed" property to its base class
i.e. this class can't be used at all
The Python implementation:
- Calls internal methods of its constructor arguments that aren't
part of the IOBase interface to determine if its streams are
readable/writable
There aren't any useful tests for either.
----------
files: rwpair.diff
keywords: patch
messages: 85849
nosy: bquinlan
severity: normal
status: open
title: BufferedRWPair broken
versions: Python 3.1
Added file: http://bugs.python.org/file13671/rwpair.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5734>
_______________________________________
From report at bugs.python.org Sat Apr 11 13:08:42 2009
From: report at bugs.python.org (Leonid Vasilev)
Date: Sat, 11 Apr 2009 11:08:42 +0000
Subject: [New-bugs-announce] [issue5735] Segfault when loading not
recompiled module
In-Reply-To: <1239448122.29.0.383715698899.issue5735@psf.upfronthosting.co.za>
Message-ID: <1239448122.29.0.383715698899.issue5735@psf.upfronthosting.co.za>
New submission from Leonid Vasilev <vsleonid at gmail.com>:
I compiled two versions of python(both from main trunk)
Here's what I do:
$cd /usr/local/src/Python-3.0.1/
$./configure
$make && make install
...
$cd ~/pyext/
$python3.0 setup.py install
...
"run python3.0 and import ext1 -- it worked ok"
...
$cd /usr/local/src/Python-3.0.1
$mkdir debug
$cd debug
$./../configure --with-pydebug
$make
$./python
...
Try to import a ext1, and got a Segfault
Backtrace from gdb:
(gdb) backtrace
#0 0xb7e9b1cb in strlen () from /lib/i686/cmov/libc.so.6
#1 0x0807c06d in PyUnicodeUCS2_FromString (u=0xffffffff <Address
0xffffffff out of bounds>) at ./../Objects/unicodeobject.c:553
#2 0x0816251a in PyModule_New (name=0xffffffff <Address 0xffffffff out
of bounds>) at ./../Objects/moduleobject.c:39
#3 0x0816282d in PyModule_Create2 (module=0xb7fd26a0,
module_api_version=1013) at ./../Objects/moduleobject.c:106
#4 0xb7fd14b8 in PyInit_ext1 () at ext1.c:40
#5 0x080cfda0 in _PyImport_LoadDynamicModule (name=0xbf9f8a17 "ext1",
pathname=0xbf9f798f "/usr/local/lib/python3.0/site-packages/ext1.so",
fp=0x9a18ef8)
at ./../Python/importdl.c:57
#6 0x080cc226 in load_module (name=0xbf9f8a17 "ext1", fp=0x9a18ef8,
buf=0xbf9f798f "/usr/local/lib/python3.0/site-packages/ext1.so", type=3,
loader=0x0)
at ./../Python/import.c:1807
#7 0x080ce236 in import_submodule (mod=0x81b8d4c, subname=0xbf9f8a17
"ext1", fullname=0xbf9f8a17 "ext1") at ./../Python/import.c:2601
#8 0x080cd7b6 in load_next (mod=0x81b8d4c, altmod=0x81b8d4c,
p_name=0xbf9f9a30, buf=0xbf9f8a17 "ext1", p_buflen=0xbf9f8a10) at
./../Python/import.c:2406
#9 0x080ccbdf in import_module_level (name=0x0, globals=0xb7e10714,
locals=0xb7e10714, fromlist=0x81b8d4c, level=0) at ./../Python/import.c:2123
#10 0x080ccfc7 in PyImport_ImportModuleLevel (name=0x9a057f0 "ext1",
globals=0xb7e10714, locals=0xb7e10714, fromlist=0x81b8d4c, level=0)
at ./../Python/import.c:2174
#11 0x0809f65f in builtin___import__ (self=0xb7df6ce4, args=0xb7df7a9c,
kwds=0x0) at ./../Python/bltinmodule.c:173
#12 0x08161e56 in PyCFunction_Call (func=0xb7df6dfc, arg=0xb7df7a9c,
kw=0x0) at ./../Objects/methodobject.c:84
#13 0x081179c1 in PyObject_Call (func=0xb7df6dfc, arg=0xb7df7a9c,
kw=0x0) at ./../Objects/abstract.c:2161
#14 0x080b1806 in PyEval_CallObjectWithKeywords (func=0xb7df6dfc,
arg=0xb7df7a9c, kw=0x0) at ./../Python/ceval.c:3313
#15 0x080ac71c in PyEval_EvalFrameEx (f=0x9a3105c, throwflag=0) at
./../Python/ceval.c:1995
#16 0x080b03fa in PyEval_EvalCodeEx (co=0x9983ec8, globals=0xb7e10714,
locals=0xb7e10714, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
defcount=0,
kwdefs=0x0, closure=0x0) at ./../Python/ceval.c:2869
#17 0x080a562b in PyEval_EvalCode (co=0x9983ec8, globals=0xb7e10714,
locals=0xb7e10714) at ./../Python/ceval.c:526
#18 0x080dcb68 in run_mod (mod=0x9a78d68, filename=0x819ff60 "<stdin>",
globals=0xb7e10714, locals=0xb7e10714, flags=0xbf9faf70, arena=0x99126d8)
at ./../Python/pythonrun.c:1686
#19 0x080dadf1 in PyRun_InteractiveOneFlags (fp=0xb7f81420,
filename=0x819ff60 "<stdin>", flags=0xbf9faf70) at
./../Python/pythonrun.c:1081
#20 0x080da953 in PyRun_InteractiveLoopFlags (fp=0xb7f81420,
filename=0x819ff60 "<stdin>", flags=0xbf9faf70) at
./../Python/pythonrun.c:993
#21 0x080da7ab in PyRun_AnyFileExFlags (fp=0xb7f81420,
filename=0x819ff60 "<stdin>", closeit=0, flags=0xbf9faf70) at
./../Python/pythonrun.c:962
#22 0x080ec7a7 in Py_Main (argc=1, argv=0xb7de3028) at
./../Modules/main.c:625
#23 0x0805a75b in main (argc=1, argv=0xbf9fb0b4) at ./../Modules/python.c:70
----------
assignee: tarek
components: Build, Distutils, Installation
files: ext1.c
messages: 85853
nosy: chin, tarek
severity: normal
status: open
title: Segfault when loading not recompiled module
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file13672/ext1.c
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5735>
_______________________________________
From report at bugs.python.org Sat Apr 11 15:47:53 2009
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 11 Apr 2009 13:47:53 +0000
Subject: [New-bugs-announce] [issue5736] Add the iterator protocol to dbm
modules
In-Reply-To: <1239457673.6.0.50765651359.issue5736@psf.upfronthosting.co.za>
Message-ID: <1239457673.6.0.50765651359.issue5736@psf.upfronthosting.co.za>
New submission from Akira Kitada <akitada at gmail.com>:
In Python 2.6, dbm modules othar than bsddb don't support the iterator
protocol.
>>> import dbm
>>> d = dbm.open('spam.dbm', 'c')
>>> for k in range(5): d["key%d" % k] = "value%d" % k
...
>>> for k in d: print k, d[k]
...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'dbm.dbm' object is not iterable
Adding iterator support would make dbm modules more convenient and
easier to use.
----------
components: Extension Modules
messages: 85856
nosy: akitada
severity: normal
status: open
title: Add the iterator protocol to dbm modules
type: feature request
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5736>
_______________________________________
From report at bugs.python.org Sat Apr 11 19:05:49 2009
From: report at bugs.python.org (Matthew Ahrens)
Date: Sat, 11 Apr 2009 17:05:49 +0000
Subject: [New-bugs-announce] [issue5737] add Solaris errnos
In-Reply-To: <1239469549.92.0.788554665966.issue5737@psf.upfronthosting.co.za>
Message-ID: <1239469549.92.0.788554665966.issue5737@psf.upfronthosting.co.za>
New submission from Matthew Ahrens <matt at mahrens.org>:
The "errno" module does not contain some error names/numbers that are
used on Solaris. Please add them.
from /usr/include/sys/errno.h:
#define ECANCELED 47 /* Operation canceled */
#define ENOTSUP 48 /* Operation not supported */
/* Interprocess Robust Locks */
#define EOWNERDEAD 58 /* process died with the lock */
#define ENOTRECOVERABLE 59 /* lock is not recoverable */
#define ELOCKUNMAPPED 72 /* locked lock was unmapped */
#define ENOTACTIVE 73 /* Facility is not active */
----------
components: Library (Lib)
messages: 85868
nosy: mahrens
severity: normal
status: open
title: add Solaris errnos
type: feature request
versions: Python 2.4, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5737>
_______________________________________
From report at bugs.python.org Sat Apr 11 22:53:57 2009
From: report at bugs.python.org (Garrett Cooper)
Date: Sat, 11 Apr 2009 20:53:57 +0000
Subject: [New-bugs-announce] [issue5738] multiprocessing example wrong
In-Reply-To: <1239483237.04.0.0741779763922.issue5738@psf.upfronthosting.co.za>
Message-ID: <1239483237.04.0.0741779763922.issue5738@psf.upfronthosting.co.za>
New submission from Garrett Cooper <yanegomi at gmail.com>:
The last example on the multiprocessing documentation page is clearly
wrong. It references a lot of renamed / deprecated API's from processing
that are no longer in multiprocessing.
I'll try and come up with a comparable working example on all platforms
(I use FreeBSD).
----------
assignee: georg.brandl
components: Documentation
messages: 85874
nosy: georg.brandl, yaneurabeya
severity: normal
status: open
title: multiprocessing example wrong
type: feature request
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5738>
_______________________________________
From report at bugs.python.org Sun Apr 12 02:58:27 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 12 Apr 2009 00:58:27 +0000
Subject: [New-bugs-announce] [issue5739] Language reference is ambiguous
regarding next() method lookup
In-Reply-To: <1239497907.46.0.481458734082.issue5739@psf.upfronthosting.co.za>
Message-ID: <1239497907.46.0.481458734082.issue5739@psf.upfronthosting.co.za>
New submission from Nick Coghlan <ncoghlan at gmail.com>:
The language reference is currently silent as to whether or not an
iterator's next() method is looked up on every pass around a for loop,
or whether it is OK for an implementation to look the method up once at
the start of the loop, cache the result and call it again each time
around the loop without doing the lookup again.
The language reference should require implementations to follow
CPython's behaviour in this respect: the method should be looked up
again on each pass around the loop.
As per this email on python-ideas:
http://mail.python.org/pipermail/python-ideas/2009-April/004083.html
----------
assignee: georg.brandl
components: Documentation
messages: 85883
nosy: georg.brandl, ncoghlan
priority: normal
severity: normal
status: open
title: Language reference is ambiguous regarding next() method lookup
type: behavior
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5739>
_______________________________________
From report at bugs.python.org Sun Apr 12 11:45:27 2009
From: report at bugs.python.org (Garrett Cooper)
Date: Sun, 12 Apr 2009 09:45:27 +0000
Subject: [New-bugs-announce] [issue5740] multiprocessing.connection.Client
API documentation incorrect
In-Reply-To: <1239529527.71.0.759387601738.issue5740@psf.upfronthosting.co.za>
Message-ID: <1239529527.71.0.759387601738.issue5740@psf.upfronthosting.co.za>
New submission from Garrett Cooper <yanegomi at gmail.com>:
In the API for connections.Client, it says:
multiprocessing.connection.Client(address[, family[, authenticate[,
authkey]]])
In the final paragraph is says:
`If authentication is True or authkey '
As per the API provided it should be:
`If authenticate is True or authkey '
This is true for the 2.6.1 and 3.1 documentation, so I assume it's
incorrect for the 2.7 and 3.0 documentation as well.
----------
assignee: georg.brandl
components: Documentation
messages: 85887
nosy: georg.brandl, jnoller, yaneurabeya
severity: normal
status: open
title: multiprocessing.connection.Client API documentation incorrect
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5740>
_______________________________________
From =?utf-8?q?M=C3=A1rcio_Faustino_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za Sun Apr 12 14:35:10 2009
From: =?utf-8?q?M=C3=A1rcio_Faustino_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za (=?utf-8?q?M=C3=A1rcio_Faustino_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za)
Date: Sun, 12 Apr 2009 12:35:10 +0000
Subject: [New-bugs-announce] [issue5741] SafeConfigParser incorrectly
detects lone percent signs
In-Reply-To: <1239539710.2.0.0497586832683.issue5741@psf.upfronthosting.co.za>
Message-ID: <1239539710.2.0.0497586832683.issue5741@psf.upfronthosting.co.za>
New submission from M?rcio Faustino <m.faustino at gmail.com>:
The SafeConfigParser class incorrectly detects lone percent signs,
for example, it doesn't accept "100%%" as a valid value. The cause of
this is the "_badpercent_re" regular expression:
- The first alternative "%[^%]" fails with the string "%%_", because it
matches "%_".
- The second alternative "%$" fails with the string "%%", because it
matches "%".
---
from ConfigParser import *
SafeConfigParser().set('DEFAULT', 'test', '100%%')
----------
components: Library (Lib)
messages: 85899
nosy: marcio
severity: normal
status: open
title: SafeConfigParser incorrectly detects lone percent signs
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5741>
_______________________________________
From report at bugs.python.org Sun Apr 12 20:29:13 2009
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Sun, 12 Apr 2009 18:29:13 +0000
Subject: [New-bugs-announce] [issue5742] inspect.findsource() should look
only for sources
In-Reply-To: <1239560953.4.0.0140518593947.issue5742@psf.upfronthosting.co.za>
Message-ID: <1239560953.4.0.0140518593947.issue5742@psf.upfronthosting.co.za>
New submission from Dmitry Vasiliev <dima at hlabs.spb.ru>:
Currently help(zlib) gives the following traceback:
Python 3.1a2+ (py3k:71538M, Apr 12 2009, 21:54:44)
>>> import zlib
>>> help(zlib)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "Lib/site.py", line 429, in __call__
return pydoc.help(*args, **kwds)
File "Lib/pydoc.py", line 1709, in __call__
self.help(request)
File "Lib/pydoc.py", line 1755, in help
else: doc(request, 'Help on %s:')
File "Lib/pydoc.py", line 1505, in doc
pager(render_doc(thing, title, forceload))
File "Lib/pydoc.py", line 1500, in render_doc
return title % desc + '\n\n' + text.document(object, name)
File "Lib/pydoc.py", line 320, in document
if inspect.ismodule(object): return self.docmodule(*args)
File "Lib/pydoc.py", line 1086, in docmodule
contents.append(self.document(value, key, name))
File "Lib/pydoc.py", line 321, in document
if inspect.isclass(object): return self.docclass(*args)
File "Lib/pydoc.py", line 1131, in docclass
doc = getdoc(object)
File "Lib/pydoc.py", line 81, in getdoc
result = inspect.getdoc(object) or inspect.getcomments(object)
File "Lib/inspect.py", line 581, in getcomments
lines, lnum = findsource(object)
File "Lib/inspect.py", line 524, in findsource
lines = linecache.getlines(file, module.__dict__)
File "Lib/linecache.py", line 41, in getlines
return updatecache(filename, module_globals)
File "Lib/linecache.py", line 127, in updatecache
lines = fp.readlines()
File "Lib/codecs.py", line 300, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 41-42:
invalid data
After some investigation I've found that inspect.findsource() try to use
getfile() if getsourcefile() fail to find the source file. I don't see
why findsource() should return lines from a compiled file so I think
it's a bug. The same bug also exists in Python 2.7 although it's not so
critical. I've attached the patch which fixes the problem.
----------
components: Library (Lib)
files: inspect.patch
keywords: patch
messages: 85916
nosy: hdima
severity: normal
status: open
title: inspect.findsource() should look only for sources
type: crash
versions: Python 3.1
Added file: http://bugs.python.org/file13678/inspect.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5742>
_______________________________________
From report at bugs.python.org Mon Apr 13 00:42:03 2009
From: report at bugs.python.org (Garrett Cooper)
Date: Sun, 12 Apr 2009 22:42:03 +0000
Subject: [New-bugs-announce] [issue5743] multiprocessing.managers not
accessible even though docs say so
In-Reply-To: <1239576123.32.0.939139207248.issue5743@psf.upfronthosting.co.za>
Message-ID: <1239576123.32.0.939139207248.issue5743@psf.upfronthosting.co.za>
New submission from Garrett Cooper <yanegomi at gmail.com>:
I'm not sure why but my copy doesn't have a managers module. I'm really
confused because multiprocessing.managers exists in
Lib/multiprocessing/managers.py and it should have been installed with
easy_install...
Please see the attached testcase (it shows the details verifying that I
don't have support). I ran it against all copies of python I have
besides 3.x (nose doesn't support 3.x because setuptools isn't there yet
for 3.x support).
-bash-3.00$ python2.4 `which nosetests` ~/test_managers_support.py
Python version:
2.4.5 (#1, Mar 28 2009, 14:54:51)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-9)]F
======================================================================
FAIL: test_managers_support.test_has_managers
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/ws/garrcoop-sjc/tools/lib/python2.4/site-packages/nose-0.10.4-py2.4.egg/nose/case.py",
line 182, in runTest
self.test(*self.arg)
File "/users/garrcoop/test_managers_support.py", line 9, in
test_has_managers
assert hasattr(multiprocessing, 'managers')
AssertionError
----------------------------------------------------------------------
Ran 1 test in 0.050s
FAILED (failures=1)
-bash-3.00$ python2.5 `which nosetests` ~/test_managers_support.py
/ws/garrcoop-sjc/tools/lib/python2.4/site-packages/multiprocessing-2.6.1.1-py2.4-linux-i686.egg/multiprocessing/__init__.py:86:
RuntimeWarning: Python C API version mismatch for module
_multiprocessing: This Python has API version 1013, module
_multiprocessing has version 1012.
import _multiprocessing
Python version:
2.5.4 (r254:67916, Mar 28 2009, 15:01:19)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-9)]F
======================================================================
FAIL: test_managers_support.test_has_managers
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/ws/garrcoop-sjc/tools/lib/python2.4/site-packages/nose-0.10.4-py2.4.egg/nose/case.py",
line 182, in runTest
self.test(*self.arg)
File "/users/garrcoop/test_managers_support.py", line 9, in
test_has_managers
assert hasattr(multiprocessing, 'managers')
AssertionError
----------------------------------------------------------------------
Ran 1 test in 0.159s
FAILED (failures=1)
-bash-3.00$ python2.6 `which nosetests` ~/test_managers_support.py
F
======================================================================
FAIL: test_managers_support.test_has_managers
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/ws/garrcoop-sjc/tools/lib/python2.4/site-packages/nose-0.10.4-py2.4.egg/nose/case.py",
line 182, in runTest
self.test(*self.arg)
File "/users/garrcoop/test_managers_support.py", line 7, in
test_has_managers
assert hasattr(multiprocessing, 'managers')
AssertionError
----------------------------------------------------------------------
Ran 1 test in 0.029s
FAILED (failures=1)
----------
components: Extension Modules, Installation
files: test_managers_support.py
messages: 85921
nosy: jnoller, yaneurabeya
severity: normal
status: open
title: multiprocessing.managers not accessible even though docs say so
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file13679/test_managers_support.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5743>
_______________________________________
From report at bugs.python.org Mon Apr 13 01:08:14 2009
From: report at bugs.python.org (Garrett Cooper)
Date: Sun, 12 Apr 2009 23:08:14 +0000
Subject: [New-bugs-announce] [issue5744]
multiprocessing.managers.BaseManager.connect example typos
In-Reply-To: <1239577694.3.0.661337704355.issue5744@psf.upfronthosting.co.za>
Message-ID: <1239577694.3.0.661337704355.issue5744@psf.upfronthosting.co.za>
New submission from Garrett Cooper <yanegomi at gmail.com>:
The example under multiprocessing.managers.BaseManager.connect has 2 typos:
>>> from multiprocessing.managers import BaseManager
>>> m = BaseManager(address='127.0.0.1', authkey='abc))>>>
m.connect()
Here's a corrected example:
>>> from multiprocessing.managers import BaseManager
>>> m = BaseManager(address='127.0.0.1', authkey='abc')
>>> m.connect()
----------
assignee: georg.brandl
components: Documentation
messages: 85924
nosy: georg.brandl, jnoller, yaneurabeya
severity: normal
status: open
title: multiprocessing.managers.BaseManager.connect example typos
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5744>
_______________________________________
From report at bugs.python.org Mon Apr 13 03:42:27 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 13 Apr 2009 01:42:27 +0000
Subject: [New-bugs-announce] [issue5745] email document update (more links)
In-Reply-To: <1239586947.93.0.97954757869.issue5745@psf.upfronthosting.co.za>
Message-ID: <1239586947.93.0.97954757869.issue5745@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
I added more links to email documantation. (I changed only :class: not
:meth:)
----------
assignee: georg.brandl
components: Documentation
files: email_doc_link.patch
keywords: patch
messages: 85932
nosy: georg.brandl, ocean-city
severity: normal
status: open
title: email document update (more links)
versions: Python 2.7
Added file: http://bugs.python.org/file13680/email_doc_link.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5745>
_______________________________________
From report at bugs.python.org Mon Apr 13 06:31:04 2009
From: report at bugs.python.org (Eric Blond)
Date: Mon, 13 Apr 2009 04:31:04 +0000
Subject: [New-bugs-announce] [issue5746] socketserver problem upon
disconnection (undefined member)
In-Reply-To: <1239597064.27.0.0905916009568.issue5746@psf.upfronthosting.co.za>
Message-ID: <1239597064.27.0.0905916009568.issue5746@psf.upfronthosting.co.za>
New submission from Eric Blond <eblond at tiscali.co.uk>:
Here's the traceback I got:
===
>>> s.serve_forever()
----------------------------------------
Exception happened during processing of request from ('127.0.0.1',
54611)
Traceback (most recent call last):
File "C:\Python30\lib\socketserver.py", line 281, in
_handle_request_noblock
self.process_request(request, client_address)
File "C:\Python30\lib\socketserver.py", line 307, in process_request
self.finish_request(request, client_address)
File "C:\Python30\lib\socketserver.py", line 320, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "C:\Python30\lib\socketserver.py", line 615, in __init__
self.finish()
File "C:\Python30\lib\socketserver.py", line 655, in finish
if not self.wfile.closed:
AttributeError: 'RequestHandler' object has no attribute 'wfile'
----------------------------------------
===
's' is an instance of socketserver.TCPServer and the handler passed is
an instance of socketserver.StreamRequestHandler.
I believe this must be a simple typo, so I didn't feel that more
details is needed at that point.
Let me know if you have any question.
----------
components: Library (Lib)
messages: 85936
nosy: eblond
severity: normal
status: open
title: socketserver problem upon disconnection (undefined member)
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5746>
_______________________________________
From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za Mon Apr 13 17:16:41 2009
From: =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za (=?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za)
Date: Mon, 13 Apr 2009 15:16:41 +0000
Subject: [New-bugs-announce] [issue5747] knowing the parent command
In-Reply-To: <1239635801.31.0.779200404785.issue5747@psf.upfronthosting.co.za>
Message-ID: <1239635801.31.0.779200404785.issue5747@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
Right now there's no way in a command to know that it was launched as a
subcommand from another command.
For instance every install_* command knows explicitely that it is
launched as a subcommand of 'install' and takes back its options in
finalize_options() using set_undefined_options().
For commands that might be used as subcommands of several commands, we
need to pass the name of the parent command to finalize_options() so
we can call set_undefined_options() without knowing explicitely the name
of the parent command.
This will be done by adding an optional parameter called
'parent_command', to run_command(), then to ensure_finalized() and to
finalized_options().
The first use case of this will be the check command, that will be used
by "register" and "sdist".
This change will be backward compatible with the existing commands and
ths new parameter optional
----------
assignee: tarek
components: Distutils
messages: 85950
nosy: tarek
priority: normal
severity: normal
status: open
title: knowing the parent command
type: feature request
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5747>
_______________________________________
From report at bugs.python.org Mon Apr 13 23:15:09 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 13 Apr 2009 21:15:09 +0000
Subject: [New-bugs-announce] [issue5748] Objects/bytesobject.c should
include stringdefs.h, instead of defining its own macros
In-Reply-To: <1239657309.78.0.97481273251.issue5748@psf.upfronthosting.co.za>
Message-ID: <1239657309.78.0.97481273251.issue5748@psf.upfronthosting.co.za>
New submission from Eric Smith <eric at trueblade.com>:
All of the macros it defines around line 565 should either already be in
stringdefs.h, or they should be added there.
The same issue exists in Objects/bytearrayobject.c. I haven't looked in
2.7, but I assume the same problem exists there.
----------
assignee: eric.smith
components: Interpreter Core
keywords: easy
messages: 85954
nosy: eric.smith
priority: normal
severity: normal
status: open
title: Objects/bytesobject.c should include stringdefs.h, instead of defining its own macros
type: behavior
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5748>
_______________________________________
From report at bugs.python.org Tue Apr 14 03:01:19 2009
From: report at bugs.python.org (MechPaul)
Date: Tue, 14 Apr 2009 01:01:19 +0000
Subject: [New-bugs-announce] [issue5749] Allow bin() to have an optional
"Total Bits" argument.
In-Reply-To: <1239670879.87.0.226370263961.issue5749@psf.upfronthosting.co.za>
Message-ID: <1239670879.87.0.226370263961.issue5749@psf.upfronthosting.co.za>
New submission from MechPaul <mechpaul at gmail.com>:
As it stands right now, bin() only shows the minimum number of bits to
display the number, however I think having a "Total Bits" argument would
be very, very useful for bin().
bin(value, [Total bits to display])
"Total bits to display" is an integer.
Here's how it should work:
>>> bin(0x7F)
'0b1111111'
>>> #Note, there are seven 1's there to represent the value 127
>>> bin(0x7F, 8)
'0b01111111'
>>> #Now there are eight bits displayed.
>>> bin(0xFF, 16)
'0b0000000011111111'
>>> #This makes it a lot easier to read and compare binary numbers!
----------
components: Interpreter Core
messages: 85956
nosy: MechPaul
severity: normal
status: open
title: Allow bin() to have an optional "Total Bits" argument.
type: feature request
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5749>
_______________________________________
From report at bugs.python.org Tue Apr 14 08:43:43 2009
From: report at bugs.python.org (utilitarian)
Date: Tue, 14 Apr 2009 06:43:43 +0000
Subject: [New-bugs-announce] [issue5750] weird seg fault
In-Reply-To: <1239691423.14.0.930263157901.issue5750@psf.upfronthosting.co.za>
Message-ID: <1239691423.14.0.930263157901.issue5750@psf.upfronthosting.co.za>
New submission from utilitarian <plonjers at cs.ucr.edu>:
In python 2.5.2 on ubuntu Ibex. If your run the command python
round_robin_seg.py smallest_tomog. Using the files provided.
There is a segfault. It happens in the core interpreter. It happened
when I added line 35 to the python code. Sorry I do not have time at the
moment to pin it down better.
----------
components: Interpreter Core
files: python_crash.tar.gz
messages: 85960
nosy: utilitarian
severity: normal
status: open
title: weird seg fault
versions: Python 2.5
Added file: http://bugs.python.org/file13684/python_crash.tar.gz
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5750>
_______________________________________
From report at bugs.python.org Tue Apr 14 11:26:15 2009
From: report at bugs.python.org (Nicolas Goutte)
Date: Tue, 14 Apr 2009 09:26:15 +0000
Subject: [New-bugs-announce] [issue5751] Typo in documentation of print
function parameters
In-Reply-To: <1239701175.13.0.88945528483.issue5751@psf.upfronthosting.co.za>
Message-ID: <1239701175.13.0.88945528483.issue5751@psf.upfronthosting.co.za>
New submission from Nicolas Goutte <nicolas.goutte at extragroup.de>:
In http://docs.python.org/library/functions.html#print the print function
is documented to have a parameter named end with a default 'n'. However
the default should be '\n' as documented in Python 3 ( http://docs.python.org/3.0/library/functions.html#print )
----------
assignee: georg.brandl
components: Documentation
messages: 85962
nosy: georg.brandl, nicolasg
severity: normal
status: open
title: Typo in documentation of print function parameters
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5751>
_______________________________________
From report at bugs.python.org Tue Apr 14 13:13:08 2009
From: report at bugs.python.org (Tomalak)
Date: Tue, 14 Apr 2009 11:13:08 +0000
Subject: [New-bugs-announce] [issue5752] xml.dom.minidom does not handle
newline characters in attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
New submission from Tomalak <M8R-t1tut01 at mailinator.com>:
Current behavior upon toxml() is:
<foo attribute="multiline
value" />
Upon reading the document again, the new line is normalized and
collapsed into a space (according to the XML spec, section 3.3.3), which
means that it is lost.
Better behavior would be something like this (within attribute values only):
<foo attribute="multiline
value" />
----------
components: XML
messages: 85964
nosy: Tomalak
severity: normal
status: open
title: xml.dom.minidom does not handle newline characters in attribute values
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________
From report at bugs.python.org Tue Apr 14 13:39:39 2009
From: report at bugs.python.org (Jan Lieskovsky)
Date: Tue, 14 Apr 2009 11:39:39 +0000
Subject: [New-bugs-announce] [issue5753] CVE-2008-5983 python: untrusted
python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
New submission from Jan Lieskovsky <iankko at seznam.cz>:
Common Vulnerabilities and Exposures assigned an identifier
CVE-2008-5983 (and related CVE ids) to the following vulnerability:
Untrusted search path vulnerability in the PySys_SetArgv API function in
Python 2.6 and earlier, and possibly later versions, prepends an empty
string to sys.path when the argv[0] argument does not contain a path
separator, which might allow local users to execute arbitrary code via a
Trojan horse Python file in the current working directory.
References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5983
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2008-5983
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5984
https://bugzilla.redhat.com/show_bug.cgi?id=481551
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5985
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5986
https://bugzilla.redhat.com/show_bug.cgi?id=481550
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5987
https://bugzilla.redhat.com/show_bug.cgi?id=481553
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0314
http://bugzilla.gnome.org/show_bug.cgi?id=569214
https://bugzilla.redhat.com/show_bug.cgi?id=481556
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0315
https://bugzilla.redhat.com/show_bug.cgi?id=481560
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0316
https://bugzilla.redhat.com/show_bug.cgi?id=481565
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0317
https://bugzilla.redhat.com/show_bug.cgi?id=481570
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0318
https://bugzilla.redhat.com/show_bug.cgi?id=481572
----------
components: Interpreter Core
files: python-CVE-2009-5983.patch
keywords: patch
messages: 85965
nosy: iankko
severity: normal
status: open
title: CVE-2008-5983 python: untrusted python modules search path
type: security
versions: Python 3.1
Added file: http://bugs.python.org/file13685/python-CVE-2009-5983.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________
From report at bugs.python.org Tue Apr 14 19:03:25 2009
From: report at bugs.python.org (Jorge Herskovic)
Date: Tue, 14 Apr 2009 17:03:25 +0000
Subject: [New-bugs-announce] [issue5754] Shelve module writeback parameter
does not act as advertised
In-Reply-To: <1239728605.41.0.419145925815.issue5754@psf.upfronthosting.co.za>
Message-ID: <1239728605.41.0.419145925815.issue5754@psf.upfronthosting.co.za>
New submission from Jorge Herskovic <jorge.r.herskovic at uth.tmc.edu>:
The shelve module documentation states that "by default, mutations to
persistent-dictionary mutable entries are not automatically written
back. If the optional writeback parameter is set to True, all entries
accessed are cached in memory, and written back at close time..."
however the implementation's __setitem__ is the following:
def __setitem__(self, key, value):
if self.writeback:
self.cache[key] = value
f = StringIO()
p = Pickler(f, self._protocol)
p.dump(value)
self.dict[key] = f.getvalue()
which maintains the cache correctly but writes back to the disk on every
operation, violating the writeback documentation. Changing it to
def __setitem__(self, key, value):
if self.writeback:
self.cache[key] = value
else:
f = StringIO()
p = Pickler(f, self._protocol)
p.dump(value)
self.dict[key] = f.getvalue()
seems to match the documentation's intent.
(First report, sorry for any formatting/style issues!)
----------
components: Extension Modules
messages: 85971
nosy: jherskovic
severity: normal
status: open
title: Shelve module writeback parameter does not act as advertised
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5754>
_______________________________________
From report at bugs.python.org Tue Apr 14 19:22:51 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Tue, 14 Apr 2009 17:22:51 +0000
Subject: [New-bugs-announce] [issue5755] "-Wstrict-prototypes" is valid for
Ada/C/ObjC but not for C++"
In-Reply-To: <1239729771.84.0.97828652099.issue5755@psf.upfronthosting.co.za>
Message-ID: <1239729771.84.0.97828652099.issue5755@psf.upfronthosting.co.za>
New submission from Zooko O'Whielacronx <zooko at zooko.com>:
A user of the Tahoe-LAFS project submitted a bug report to us, saying:
"""
I get lots of "cc1plus: warning: command line option "-Wstrict-
prototypes" is valid for Ada/C/ObjC but not for C++" when compiling
"""
A little googling shows that this gets reported frequently to other
Python projects that have C++ code:
http://trac.sagemath.org/sage_trac/ticket/425
http://www.mail-archive.com/matplotlib-
users at lists.sourceforge.net/msg03947.html
Those other projects seem to think that this is distutils's problem, but
I don't see evidence that any of them opened a ticket for distutils yet.
----------
assignee: tarek
components: Distutils
messages: 85972
nosy: tarek, zooko
severity: normal
status: open
title: "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++"
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5755>
_______________________________________
From report at bugs.python.org Tue Apr 14 22:24:20 2009
From: report at bugs.python.org (Ned Deily)
Date: Tue, 14 Apr 2009 20:24:20 +0000
Subject: [New-bugs-announce] [issue5756] idle pydoc et al removed from 3.1
without versioned replacements
In-Reply-To: <1239740660.49.0.649614984791.issue5756@psf.upfronthosting.co.za>
Message-ID: <1239740660.49.0.649614984791.issue5756@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
RELEASE BLOCKER
r71400 and r71401 changed py3k setup.py to comment out the installation
of the scripts for pydoc, idle, 2to5, and smtpd.py. This was in
response to issue1590 noting that python3 should not overwrite python2
versions of the scripts. However, unless I'm missing something, this
now means that *no* versions of these scripts are ever installed for
python3; that's not a solution. (Note, this breaks Mac installer builds
and probably breaks downstream unix packages as well.)
As hinted at in issue1590, the most consistent option would be to
install each of the scripts with a version number as is done with python
itself.
Whatever solution is chosen, some additional work will likely be needed
in the Mac Makefile to do the right thing in the framework bin directory
and in the Mac BuildScript/build-installer.py for the /usr/local/bin
links. No idea about the effects on other platform builds.
This also seems to be a change worthy of a NEWS item and doc changes.
----------
components: Build
messages: 85973
nosy: nad
severity: normal
status: open
title: idle pydoc et al removed from 3.1 without versioned replacements
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5756>
_______________________________________
From report at bugs.python.org Tue Apr 14 22:56:50 2009
From: report at bugs.python.org (Piet van Oostrum)
Date: Tue, 14 Apr 2009 20:56:50 +0000
Subject: [New-bugs-announce] [issue5757] Documentation error for
Condition.notify()
In-Reply-To: <1239742610.61.0.843225535898.issue5757@psf.upfronthosting.co.za>
Message-ID: <1239742610.61.0.843225535898.issue5757@psf.upfronthosting.co.za>
New submission from Piet van Oostrum <piet at cs.uu.nl>:
The documentation for Condition.notify() in module threading (Library
Reference) contains an error:
The second sentence (Wait until notified or until a timeout occurs.)
shouldn't be there. Apparently it was copied and pasted from wait().
----------
assignee: georg.brandl
components: Documentation
messages: 85977
nosy: georg.brandl, pietvo
severity: normal
status: open
title: Documentation error for Condition.notify()
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5757>
_______________________________________
From report at bugs.python.org Wed Apr 15 01:48:02 2009
From: report at bugs.python.org (Michael Newman)
Date: Tue, 14 Apr 2009 23:48:02 +0000
Subject: [New-bugs-announce] [issue5758] fileinput.hook_compressed returning
bytes from gz file
In-Reply-To: <1239752882.45.0.853698903963.issue5758@psf.upfronthosting.co.za>
Message-ID: <1239752882.45.0.853698903963.issue5758@psf.upfronthosting.co.za>
New submission from Michael Newman <michael.b.newman at gmail.com>:
The attached ZIP file contains "test.bat" which runs "test.py" with
Python 2.6 and Python 3.0.
Python 2.6 behaves as expected (see "py26.out"), since it returns
strings from both "mike.txt" and "mike.txt.gz". However, the same test
with Python 3.0 returns bytes from "mike.txt.gz", as shown in "py30.out":
Output: Hello from Mike.
Output: This is the second line.
Output: Why did the robot cross the road?
Output: b'Hello from Mike.'
Output: b'This is the second line.'
Output: b'Why did the robot cross the road?'
For reference, I tested this on Python versions:
Python 2.6.1 (r261:67517, Dec 4 2008, 16:51:00) [MSC v.1500 32 bit
(Intel)] on win32
Python 3.0.1 (r301:69561, Feb 13 2009, 20:04:18) [MSC v.1500 32 bit
(Intel)] on win32
----------
components: Library (Lib)
files: example.zip
messages: 85978
nosy: mnewman
severity: normal
status: open
title: fileinput.hook_compressed returning bytes from gz file
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file13688/example.zip
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5758>
_______________________________________
From report at bugs.python.org Wed Apr 15 05:41:02 2009
From: report at bugs.python.org (Alexandr Zamaraev)
Date: Wed, 15 Apr 2009 03:41:02 +0000
Subject: [New-bugs-announce] [issue5759] Do not call __float__ to classec
derived from str
In-Reply-To: <1239766862.72.0.608424365256.issue5759@psf.upfronthosting.co.za>
Message-ID: <1239766862.72.0.608424365256.issue5759@psf.upfronthosting.co.za>
New submission from Alexandr Zamaraev <shura_zam at users.sourceforge.net>:
Test case:
[code]
class S:
def __init__(self, v):
self.data = v
def __int__(self):
print("S.INT called")
return int(str(self.data))
def __float__(self):
print("S.FLOAT called")
return float(str(self.data))
class T(str):
def __int__(self):
print("T.INT called")
return int(str(self))
def __float__(self):
print("T.FLOAT called")
return float(str(self))
class U(unicode):
def __int__(self):
print("U.INT called")
return int(unicode(self))
def __float__(self):
print("U.FLOAT called")
return float(unicode(self))
i = S("123")
print(type(int(i)))
print(type(float(i)))
i = T("123")
print(type(int(i)))
print(type(float(i))) # <<< CALLS __float__ NOTHING
i = U("123")
print(type(int(i)))
print(type(float(i)))
[/code]
Output:
[code]
S.INT called
<type 'int'>
S.FLOAT called
<type 'float'>
T.INT called
<type 'int'>
<type 'float'>
U.INT called
<type 'int'>
U.FLOAT called
<type 'float'>
[/code]
----------
components: None
messages: 85979
nosy: shura_zam
severity: normal
status: open
title: Do not call __float__ to classec derived from str
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5759>
_______________________________________
From report at bugs.python.org Wed Apr 15 08:32:11 2009
From: report at bugs.python.org (Chris Rebert)
Date: Wed, 15 Apr 2009 06:32:11 +0000
Subject: [New-bugs-announce] [issue5760] __getitem__ error message hard to
understand
In-Reply-To: <1239777131.98.0.31222273519.issue5760@psf.upfronthosting.co.za>
Message-ID: <1239777131.98.0.31222273519.issue5760@psf.upfronthosting.co.za>
New submission from Chris Rebert <pybugs at rebertia.com>:
Prompted by
http://mail.python.org/pipermail/python-ideas/2009-April/004048.html
The current error message issued when trying to use the get item ([])
operator on an object that does not define __getitem__ can be hard to
understand:
>>> class A(object): pass
...
>>> A()['a']
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'A' object is unsubscriptable
Problems observed:
- "unsubscriptable" is easily misread in haste as "unscriptable", which
can be quite confusing, especially to newbies
- "subscripting" is not frequently used to describe the [] operator,
making the message more difficult to decipher (again, esp. for newbies)
- the underlying lack of a __getitem__ method is not mentioned, thus not
making it obvious how to remedy the error
Suggestion:
Use exception chaining and rephrase the error message to get something like:
AttributeError: class 'A' has no attribute '__getitem__'
The above exception was the direct cause of the following exception:
TypeError: 'A' object does not support the 'get item' operator
Similar changes should be made to __setitem__ & __delitem__.
----------
components: Interpreter Core
messages: 85983
nosy: cvrebert
severity: normal
status: open
title: __getitem__ error message hard to understand
type: behavior
versions: Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5760>
_______________________________________
From report at bugs.python.org Wed Apr 15 12:45:47 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Apr 2009 10:45:47 +0000
Subject: [New-bugs-announce] [issue5761] add file name to py3k IO objects
repr()
In-Reply-To: <1239792347.2.0.639213233478.issue5761@psf.upfronthosting.co.za>
Message-ID: <1239792347.2.0.639213233478.issue5761@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
>>> f = open("py3k/__svn__/LICENSE")
>>> f
<TextIOWrapper encoding=UTF-8>
>>> f.buffer
<_io.BufferedReader object at 0x7f4b67569f68>
>>> f.buffer.raw
io.FileIO(3, 'rb')
>>> f.name
'py3k/__svn__/LICENSE'
It would probably be nice if f.name were reused for f's repr().
----------
components: Library (Lib)
messages: 85989
nosy: benjamin.peterson, pitrou
priority: normal
severity: normal
stage: test needed
status: open
title: add file name to py3k IO objects repr()
type: feature request
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5761>
_______________________________________
From report at bugs.python.org Wed Apr 15 14:34:34 2009
From: report at bugs.python.org (Husen daudi)
Date: Wed, 15 Apr 2009 12:34:34 +0000
Subject: [New-bugs-announce] [issue5762] AttributeError: 'NoneType' object
has no attribute 'replace'
In-Reply-To: <1239798874.6.0.325655580097.issue5762@psf.upfronthosting.co.za>
Message-ID: <1239798874.6.0.325655580097.issue5762@psf.upfronthosting.co.za>
New submission from Husen daudi <hda at openerp.co.in>:
[2009-04-15 17:53:10,198] ERROR:web-services:[19]:
_write_data(writer, attrs[a_name].value)
[2009-04-15 17:53:10,198] ERROR:web-services:[20]: File
"/usr/lib/python2.5/site-packages/oldxml/_xmlplus/dom/minidom.py", line
305, in _write_data
[2009-04-15 17:53:10,199] ERROR:web-services:[21]: data =
data.replace("&", "&").replace("<", "<")
[2009-04-15 17:53:10,199] ERROR:web-services:[22]: AttributeError:
'NoneType' object has no attribute 'replace'
_write_data dunction should be something like this
def _write_data(writer, data):
"Writes datachars to writer."
if data:
data = data.replace("&", "&").replace("<", "<")
data = data.replace("\"", """).replace(">", ">")
writer.write(data)
----------
components: XML
messages: 85990
nosy: hda
severity: normal
status: open
title: AttributeError: 'NoneType' object has no attribute 'replace'
type: crash
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5762>
_______________________________________
From report at bugs.python.org Wed Apr 15 17:10:47 2009
From: report at bugs.python.org (vid podpecan)
Date: Wed, 15 Apr 2009 15:10:47 +0000
Subject: [New-bugs-announce] [issue5763] scope resolving error
In-Reply-To: <1239808247.23.0.84220378754.issue5763@psf.upfronthosting.co.za>
Message-ID: <1239808247.23.0.84220378754.issue5763@psf.upfronthosting.co.za>
New submission from vid podpecan <vid.podpecan at gmail.com>:
Consider the following two functions:
def outer():
a = 1
def inner():
print a
inner()
#end outer()
def outer_BUG():
a = 1
def inner():
print a
a = 2
inner()
#end outer_BUG()
The first function outer() works as expected (it prints 1), but the
second function ends with an UnboundLocalError, which says that the
"print a" statement inside inner() function references a variable before
assignment. Somehow, the interpreter gets to this conclusion by looking
at the next statement (a = 2) and forgets the already present variable a
from outer function.
This was observed with python 2.5.4 and older 2.5.2. Other releases were
not inspected.
Best regards,
Vid
----------
messages: 85992
nosy: vpodpecan
severity: normal
status: open
title: scope resolving error
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5763>
_______________________________________
From report at bugs.python.org Wed Apr 15 17:58:28 2009
From: report at bugs.python.org (Ding Xuan)
Date: Wed, 15 Apr 2009 15:58:28 +0000
Subject: [New-bugs-announce] [issue5764] 2.6.2 Python Manuals CHM file seems
broken
In-Reply-To: <1239811108.5.0.558563747483.issue5764@psf.upfronthosting.co.za>
Message-ID: <1239811108.5.0.558563747483.issue5764@psf.upfronthosting.co.za>
New submission from Ding Xuan <dx617 at 163.com>:
e.g. "The Python Tutorial" menu cannot be unfolded, so as "Using
Python", etc.
----------
assignee: georg.brandl
components: Documentation
messages: 85998
nosy: dx617, georg.brandl
severity: normal
status: open
title: 2.6.2 Python Manuals CHM file seems broken
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5764>
_______________________________________
From report at bugs.python.org Thu Apr 16 01:37:37 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 15 Apr 2009 23:37:37 +0000
Subject: [New-bugs-announce] [issue5765] stack overflow evaluating eval("()"
* 30000)
In-Reply-To: <1239838657.22.0.326859227165.issue5765@psf.upfronthosting.co.za>
Message-ID: <1239838657.22.0.326859227165.issue5765@psf.upfronthosting.co.za>
New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:
Originally reported by Juanjo Conti at PyAr:
http://blog.gmane.org/gmane.org.user-groups.python.argentina/
day=20090415
Evaluating this expression causes a stack overflow, and the Python
interpreter exits abnormally:
eval("()" * 30000)
3.0.1, 2.6, 2.5 and current 2.x trunk all fail on Windows; the original
reporter was likely using Linux. Some versions may require a larger
constant instead of 30000.
2.4 isn't affected; it raises a "TypeError: 'tuple' object is not
callable" as expected, even for extremely long sequences.
Alberto Bertogli said: inside eval, symtable_visit_expr() (Python/
symtable.c) is called recursively (thru the VISIT/VISIT_SEQ macros),
eventually taking all stack space.
----------
components: Interpreter Core
messages: 86006
nosy: gagenellina
severity: normal
status: open
title: stack overflow evaluating eval("()" * 30000)
type: crash
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5765>
_______________________________________
From report at bugs.python.org Thu Apr 16 02:12:19 2009
From: report at bugs.python.org (Bryan Blackburn)
Date: Thu, 16 Apr 2009 00:12:19 +0000
Subject: [New-bugs-announce] [issue5766] Mac/scripts/BuildApplet.py reset of
sys.executable during install can cause it to use wrong modules
In-Reply-To: <1239840739.74.0.413438515887.issue5766@psf.upfronthosting.co.za>
Message-ID: <1239840739.74.0.413438515887.issue5766@psf.upfronthosting.co.za>
New submission from Bryan Blackburn <blb at users.sourceforge.net>:
With Python 2.6.1 currently installed and attempting to install 2.6.2 into
a DESTDIR location, and having a different configuration for the new one
(2.6.1 built with default Unicode settings, 2.6.2 with UCS4),
BuildApplet.py fails because of symbol not found.
Full output (building with MacPorts, hence the sometimes-funky paths)
attached as a text file.
----------
components: Installation, Macintosh
files: python262_error.txt
messages: 86009
nosy: blb
severity: normal
status: open
title: Mac/scripts/BuildApplet.py reset of sys.executable during install can cause it to use wrong modules
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file13695/python262_error.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5766>
_______________________________________
From report at bugs.python.org Thu Apr 16 02:19:59 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 16 Apr 2009 00:19:59 +0000
Subject: [New-bugs-announce] [issue5767] xmlrpclib loads invalid documents
In-Reply-To: <1239841199.24.0.504542013197.issue5767@psf.upfronthosting.co.za>
Message-ID: <1239841199.24.0.504542013197.issue5767@psf.upfronthosting.co.za>
New submission from Jean-Paul Calderone <exarkun at divmod.com>:
Prior versions of xmlrpclib.loads would raise an exception when passed
malformed documents:
exarkun at bigdog24:~/_trial_temp$ python2.4 -c 'from xmlrpclib import
loads; loads("\x00\n<methodResponse>\n <params>\n <param>\n </param>\n
</params>\n</methodResponse>\n")'
Traceback (most recent call last):
File "<string>", line 1, in ?
File "/usr/lib/python2.4/xmlrpclib.py", line 1079, in loads
p.feed(data)
File "/usr/lib/python2.4/xmlrpclib.py", line 527, in feed
self._parser.Parse(data, 0)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 2,
column 0
However, as of the most recent Python 2.5 and Python 2.6 point releases,
this is no longer the case:
exarkun at bigdog24:~/_trial_temp$ python2.5 -c 'from xmlrpclib import
loads; loads("\x00\n<methodResponse>\n <params>\n <param>\n </param>\n
</params>\n</methodResponse>\n")'
exarkun at bigdog24:~/_trial_temp$ python2.6 -c 'from xmlrpclib import
loads; loads("\x00\n<methodResponse>\n <params>\n <param>\n </param>\n
</params>\n</methodResponse>\n")'
exarkun at bigdog24:~/_trial_temp$
Previous versions of Python 2.5 and Python 2.6 did not exhibit this
misbehavior.
----------
components: Library (Lib)
messages: 86010
nosy: exarkun
severity: normal
status: open
title: xmlrpclib loads invalid documents
type: behavior
versions: Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5767>
_______________________________________
From report at bugs.python.org Thu Apr 16 08:46:36 2009
From: report at bugs.python.org (Naoki INADA)
Date: Thu, 16 Apr 2009 06:46:36 +0000
Subject: [New-bugs-announce] [issue5768] logging don't encode Unicode
message correctly.
In-Reply-To: <1239864394.45.0.809519102245.issue5768@psf.upfronthosting.co.za>
Message-ID: <1239864394.45.0.809519102245.issue5768@psf.upfronthosting.co.za>
New submission from Naoki INADA <songofacandy at gmail.com>:
>>> logging.error(u'?')
ERROR:root:??
>>> sys.stderr.encoding
'cp932'
This bug is introduced by following commit.
http://svn.python.org/view/python/branches/release26-
maint/Lib/logging/__init__.py?r1=68830&r2=69448
----------
components: Library (Lib)
files: logging_init.diff
keywords: patch
messages: 86015
nosy: naoki
severity: normal
status: open
title: logging don't encode Unicode message correctly.
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file13697/logging_init.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5768>
_______________________________________
From report at bugs.python.org Thu Apr 16 08:49:00 2009
From: report at bugs.python.org (Ned Deily)
Date: Thu, 16 Apr 2009 06:49:00 +0000
Subject: [New-bugs-announce] [issue5769] OS X Installer: new make of
documentation installs at wrong location
In-Reply-To: <1239864540.13.0.520124833397.issue5769@psf.upfronthosting.co.za>
Message-ID: <1239864540.13.0.520124833397.issue5769@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
r70727 and related merges changed the OS X build-installer script to
build documentation from scratch using sphinx rather than the previous
error-prone downloading. However, it appears the documentation is
ending up at a different location in the framework, i.e. there is one
extra directory now "python-docs-html":
old:
file:///Library/Frameworks/Python.framework/Versions/2.6/Resources/Engli
sh.lproj/Documentation/index.html
new:
file:///Library/Frameworks/Python.framework/Versions/2.6/Resources/Engli
sh.lproj/Documentation/python-docs-html/index.html
Besides breaking users' bookmarks, it also causes IDLE to not find the
on-disk documentation and forces doc web page loads from python.org.
----------
components: Build, Macintosh
messages: 86016
nosy: nad, ronaldoussoren
severity: normal
status: open
title: OS X Installer: new make of documentation installs at wrong location
versions: Python 2.6, Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5769>
_______________________________________
From report at bugs.python.org Thu Apr 16 11:47:32 2009
From: report at bugs.python.org (Garrett Cooper)
Date: Thu, 16 Apr 2009 09:47:32 +0000
Subject: [New-bugs-announce] [issue5770] SA bugs with unittest.py
In-Reply-To: <1239875252.02.0.167158761739.issue5770@psf.upfronthosting.co.za>
Message-ID: <1239875252.02.0.167158761739.issue5770@psf.upfronthosting.co.za>
New submission from Garrett Cooper <yanegomi at gmail.com>:
A handful of valid bugs were reported with pylint when I was backporting
unittest.py r71263 to 2.4/2.5 from HEAD. The attached diff fixes them.
----------
components: Extension Modules, Tests
files: unittest-sa_fix-r71263.diff
keywords: patch
messages: 86018
nosy: yaneurabeya
severity: normal
status: open
title: SA bugs with unittest.py
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file13700/unittest-sa_fix-r71263.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5770>
_______________________________________
From report at bugs.python.org Thu Apr 16 11:53:14 2009
From: report at bugs.python.org (Garrett Cooper)
Date: Thu, 16 Apr 2009 09:53:14 +0000
Subject: [New-bugs-announce] [issue5771] SA bugs with unittest.py@r71263
In-Reply-To: <1239875594.79.0.0374770932255.issue5771@psf.upfronthosting.co.za>
Message-ID: <1239875594.79.0.0374770932255.issue5771@psf.upfronthosting.co.za>
New submission from Garrett Cooper <yanegomi at gmail.com>:
A handful of valid bugs were reported with pylint when I was backporting
unittest.py r71263 to 2.4/2.5 from HEAD for
<http://code.google.com/p/python-unittest-backport>. The attached diff
fixes them.
----------
components: Extension Modules, Tests
files: unittest-sa_fix-r71263.diff
keywords: patch
messages: 86019
nosy: benjamin.peterson, gregory.p.smith, michael.foord, yaneurabeya
severity: normal
status: open
title: SA bugs with unittest.py at r71263
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file13701/unittest-sa_fix-r71263.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5771>
_______________________________________
From report at bugs.python.org Thu Apr 16 12:57:21 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 16 Apr 2009 10:57:21 +0000
Subject: [New-bugs-announce] [issue5772] For float.__format__,
don't add a trailing ".0" if we're using no type code and we have
an exponent
In-Reply-To: <1239879441.22.0.242976004703.issue5772@psf.upfronthosting.co.za>
Message-ID: <1239879441.22.0.242976004703.issue5772@psf.upfronthosting.co.za>
New submission from Eric Smith <eric at trueblade.com>:
The point of the empty type code is to make sure a number looks like a
float (so as to avoid formatting 2.0 as "2"). But if we have an
exponent, the result already looks like a float, so there's no need to
modify the number further.
----------
assignee: eric.smith
components: Interpreter Core
keywords: easy
messages: 86021
nosy: eric.smith, marketdickinson
priority: normal
severity: normal
status: open
title: For float.__format__, don't add a trailing ".0" if we're using no type code and we have an exponent
type: behavior
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5772>
_______________________________________
From report at bugs.python.org Thu Apr 16 14:39:09 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 16 Apr 2009 12:39:09 +0000
Subject: [New-bugs-announce] [issue5773] Crash on shutdown after
os.fdopen(2) in debug builds
In-Reply-To: <1239885549.06.0.444041706295.issue5773@psf.upfronthosting.co.za>
Message-ID: <1239885549.06.0.444041706295.issue5773@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:
With a 2.6 or 2.7 debug build:
python_d -c "import os; os.fdopen(2)"
Displays the famous Debug Assertion Failure:
...
Expression: (_osfile(fh) & FOPEN)
...
The error occurs when closing pyhon, in call_ll_exitfuncs() there is a
call to fflush(stderr)
----------
assignee: krisvale
components: Windows
messages: 86026
nosy: amaury.forgeotdarc, krisvale
severity: normal
status: open
title: Crash on shutdown after os.fdopen(2) in debug builds
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5773>
_______________________________________
From report at bugs.python.org Thu Apr 16 21:06:13 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 16 Apr 2009 19:06:13 +0000
Subject: [New-bugs-announce] [issue5774] _winreg.OpenKey() is documented
with keyword arguments, but doesn't take them
In-Reply-To: <1239908773.0.0.157202779439.issue5774@psf.upfronthosting.co.za>
Message-ID: <1239908773.0.0.157202779439.issue5774@psf.upfronthosting.co.za>
New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:
I noticed this in 2.6, but I imagine it affects 2.7, and 3.x as well.
The documentation for _winreg.OpenKey reads in part:
_winreg.OpenKey(key, sub_key[, res=0][, sam=KEY_READ])
However:
>>> import _winreg
>>> _winreg.OpenKey(_winreg.HKEY_CURRENT_USER, 'Software',
sam=_winreg.KEY_ALL_ACCESS)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: OpenKey() takes no keyword arguments
Probably the OpenKey implementation should be updated to use
PyArg_ParseTupleAndKeywords instead of PyArg_ParseTuple?
----------
components: Library (Lib)
messages: 86038
nosy: stutzbach
severity: normal
status: open
title: _winreg.OpenKey() is documented with keyword arguments, but doesn't take them
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5774>
_______________________________________
From report at bugs.python.org Fri Apr 17 00:07:51 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 16 Apr 2009 22:07:51 +0000
Subject: [New-bugs-announce] [issue5775] marshal.c needs to be checked for
out of memory errors
In-Reply-To: <1239919671.05.0.969461869754.issue5775@psf.upfronthosting.co.za>
Message-ID: <1239919671.05.0.969461869754.issue5775@psf.upfronthosting.co.za>
New submission from Eric Smith <eric at trueblade.com>:
With the changes in r71665, w_object() in marshal.c needs to be checked
for out of memory errors when converting floats to strings. I'm not
convinced the existing error checking was correct, but I haven't spent a
lot of time looking at it.
The fact that w_object() is recursive makes the problem that much tougher.
I'll get to this before the next 3.1 release.
----------
assignee: eric.smith
components: Interpreter Core
messages: 86049
nosy: eric.smith
priority: release blocker
severity: normal
status: open
title: marshal.c needs to be checked for out of memory errors
type: resource usage
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5775>
_______________________________________
From report at bugs.python.org Fri Apr 17 09:49:50 2009
From: report at bugs.python.org (Yasushi Iwata)
Date: Fri, 17 Apr 2009 07:49:50 +0000
Subject: [New-bugs-announce] [issue5776] RPM build error with python-2.6.spec
In-Reply-To: <1239954590.57.0.776112423275.issue5776@psf.upfronthosting.co.za>
Message-ID: <1239954590.57.0.776112423275.issue5776@psf.upfronthosting.co.za>
New submission from Yasushi Iwata <yasusii at lowlife.jp>:
I found some typo and mistakes in python-2.6.spec.
----------
components: Demos and Tools
files: python-2.6.spec.patch
keywords: patch
messages: 86056
nosy: yasusii
severity: normal
status: open
title: RPM build error with python-2.6.spec
versions: Python 2.6
Added file: http://bugs.python.org/file13710/python-2.6.spec.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5776>
_______________________________________
From report at bugs.python.org Fri Apr 17 10:29:57 2009
From: report at bugs.python.org (Andreas Otto)
Date: Fri, 17 Apr 2009 08:29:57 +0000
Subject: [New-bugs-announce] [issue5777] unable to search in python V3
documentation
In-Reply-To: <1239956997.02.0.510545849385.issue5777@psf.upfronthosting.co.za>
Message-ID: <1239956997.02.0.510545849385.issue5777@psf.upfronthosting.co.za>
New submission from Andreas Otto <aotto1968 at users.sourceforge.net>:
Hi,
if I search for "sys.argv" I get
Your search did not match any documents. Please make sure that all words
are spelled correctly and that you've selected enough categories.
but its available at: http://docs.python.org/3.0/library/sys.html
----------
assignee: georg.brandl
components: Documentation
messages: 86057
nosy: aotto1968, georg.brandl
severity: normal
status: open
title: unable to search in python V3 documentation
type: resource usage
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5777>
_______________________________________
From report at bugs.python.org Fri Apr 17 11:00:08 2009
From: report at bugs.python.org (Toshihiro Kamiya)
Date: Fri, 17 Apr 2009 09:00:08 +0000
Subject: [New-bugs-announce] [issue5778] sys.version format differs between
MSC and GCC
In-Reply-To: <1239958808.78.0.447380255755.issue5778@psf.upfronthosting.co.za>
Message-ID: <1239958808.78.0.447380255755.issue5778@psf.upfronthosting.co.za>
New submission from Toshihiro Kamiya <t-kamiya at aist.go.jp>:
The value of sys.version includes a new-line char in GCC build.
'2.5.2 (r252:60911, Oct 5 2008, 19:24:49) \n[GCC 4.3.2]'
MSC build doesn't.
'2.6.2 (r262:71605, Apr 14 2009, 22:46:50) [MSC v.1500 64 bit (AMD64)]'
This seems a kind of pitfall for the developers who use this variable.
----------
components: Build
messages: 86060
nosy: t-kamiya
severity: normal
status: open
title: sys.version format differs between MSC and GCC
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5778>
_______________________________________
From report at bugs.python.org Fri Apr 17 11:35:10 2009
From: report at bugs.python.org (Matteo Bertini)
Date: Fri, 17 Apr 2009 09:35:10 +0000
Subject: [New-bugs-announce] [issue5779] _elementtree import can fail
silently
In-Reply-To: <1239960910.01.0.399059984648.issue5779@psf.upfronthosting.co.za>
Message-ID: <1239960910.01.0.399059984648.issue5779@psf.upfronthosting.co.za>
New submission from Matteo Bertini <matteob at naufraghi.net>:
(the patch is old, I forwarded it to Fredrik but I forgot to open the bug)
Playing with PyInstaller I have found that the final part of _elementtree.c:
Index: Modules/_elementtree.c
===================================================================
--- Modules/_elementtree.c (revisione 59540)
+++ Modules/_elementtree.c (copia locale)
@@ -2780,7 +2780,10 @@
);
- PyRun_String(bootstrap, Py_file_input, g, NULL);
+ if (PyRun_String(bootstrap, Py_file_input, g, NULL) == NULL) {
+ m = PyErr_Occurred();
+ return;
+ }
elementpath_obj = PyDict_GetItemString(g, "ElementPath");
executes a bit of python code without checking the return value.
That can lead to weird things playing with import hooks,
for example an assert like this can fail:
Index: Lib/test/test_elemettree.py
===================================================================
--- Lib/test/test_elemettree.py (revisione 0)
+++ Lib/test/test_elemettree.py (revisione 0)
@@ -0,0 +1,21 @@
+#! /usr/bin/env python
+
+def importHook(*args, **kwargs):
+ if 'xml.etree' in args:
+ raise ImportError
+ else:
+ return __real__import__(*args, **kwargs)
+
+import os
+import __builtin__
+__real__import__ = __builtin__.__import__
+__builtin__.__import__ = importHook
+
+try:
+ import xml.etree.cElementTree as cET
+except ImportError:
+ pass
+else:
+ out = os.popen("python -c 'import xml.etree.cElementTree as cET;
print dir(cET)'").read().strip()
+ assert str(dir(cET)) == out, (str(dir(cET)), out)
+
Quite a novice with python internals, so comments are welcome.
Matteo Bertini
----------
components: XML
messages: 86062
nosy: naufraghi
severity: normal
status: open
title: _elementtree import can fail silently
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5779>
_______________________________________
From report at bugs.python.org Fri Apr 17 12:32:54 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 17 Apr 2009 10:32:54 +0000
Subject: [New-bugs-announce] [issue5780] test_float fails for 'legacy' float
repr style
In-Reply-To: <1239964374.11.0.815428814709.issue5780@psf.upfronthosting.co.za>
Message-ID: <1239964374.11.0.815428814709.issue5780@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
After:
CC="gcc -DPY_NO_SHORT_FLOAT_REPR" ./configure && make
test_format_testfile in test_float fails with:
test.support.TestFailed: Traceback (most recent call last):
File "Lib/test/test_float.py", line 341, in test_format_testfile
self.assertEqual(fmt % float(arg), rhs)
AssertionError: '100000000000.0' != '1e+11'
The problem is that for str(float), the new formatting code switches to
exponential notation at 1e11, not 1e12; the legacy code does not.
A similar issue exists for repr: repr(1e16) should now produce '1e+16'.
----------
assignee: marketdickinson
components: Interpreter Core
messages: 86066
nosy: eric.smith, marketdickinson
priority: normal
severity: normal
stage: patch review
status: open
title: test_float fails for 'legacy' float repr style
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5780>
_______________________________________
From report at bugs.python.org Fri Apr 17 15:16:18 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 17 Apr 2009 13:16:18 +0000
Subject: [New-bugs-announce] [issue5781] Legacy float repr is used
unnecessarily on some platforms
In-Reply-To: <1239974178.12.0.90656789268.issue5781@psf.upfronthosting.co.za>
Message-ID: <1239974178.12.0.90656789268.issue5781@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
The current defines in pyport.h mean that we don't use Gay's code
for short float repr if there's evidence of double rounding.
However, there's one situation where double rounding occurs and we can
still use Gay's code: namely, when the configure script has worked out how
to get and set the x87 control word.
The pyport.h code should be fixed so that we use Gay's code in that
situation.
----------
assignee: marketdickinson
components: Interpreter Core
keywords: easy
messages: 86073
nosy: eric.smith, marketdickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: Legacy float repr is used unnecessarily on some platforms
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5781>
_______________________________________
From report at bugs.python.org Fri Apr 17 16:38:03 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 17 Apr 2009 14:38:03 +0000
Subject: [New-bugs-announce] [issue5782] ',
' formatting with empty format type '' (PEP 378)
In-Reply-To: <1239979083.96.0.980921047478.issue5782@psf.upfronthosting.co.za>
Message-ID: <1239979083.96.0.980921047478.issue5782@psf.upfronthosting.co.za>
New submission from Eric Smith <eric at trueblade.com>:
PEP 378 says that the ',' format option applies to types 'd', 'e', 'f',
'g', 'E', 'G', '%' and 'F'. I think this should also be extended to
include the empty type ''.
This only makes a difference for floats. For ints, '' is the same as
'd', but for floats '' is distinct. In 3.1 we get this behavior:
>>> format(1.2, '010.2')
'00000001.2'
>>> format(1.2, '010,.2')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: Cannot specify ',' with ''.
I think the second example should be valid.
----------
assignee: eric.smith
components: Interpreter Core
keywords: easy
messages: 86075
nosy: eric.smith, marketdickinson, rhettinger
priority: normal
severity: normal
status: open
title: ',' formatting with empty format type '' (PEP 378)
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5782>
_______________________________________
From report at bugs.python.org Fri Apr 17 21:11:55 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 17 Apr 2009 19:11:55 +0000
Subject: [New-bugs-announce] [issue5783] IDLE cannot find windows chm file
In-Reply-To: <1239995515.37.0.798086990952.issue5783@psf.upfronthosting.co.za>
Message-ID: <1239995515.37.0.798086990952.issue5783@psf.upfronthosting.co.za>
New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:
The Doc/Python262.chm file needs to be named Doc/Python26.chm so that
IDLE can find it. The current release cannot find the chm file at all
so it falls back to the on-line docs at http://www.python.org/doc/current .
----------
assignee: benjamin.peterson
components: Build
messages: 86082
nosy: benjamin.peterson, rhettinger
priority: critical
severity: normal
status: open
title: IDLE cannot find windows chm file
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5783>
_______________________________________
From report at bugs.python.org Sat Apr 18 00:10:21 2009
From: report at bugs.python.org (paul rubin)
Date: Fri, 17 Apr 2009 22:10:21 +0000
Subject: [New-bugs-announce] [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
New submission from paul rubin <phr at users.sourceforge.net>:
The zlib module doesn't support raw deflate format, so it doesn't
completely interoperate with php's "gzdeflate" function and fails to
decompress some strings that web browsers can decompress.
A workaround is to use a special zlib feature and pass the value -15 as
the "wbits" arg:
plaintext = zlib.deflate(compressed_text, wbits=-15)
I don't know if it's appropriate to mess with the code, but at minimum I
urge that the workaround be mentioned in the docs. We had a tremendous
distruption where I work because of a malicious raw-deflated PHP script
that we couldn't decompress with Python for analysis. We had to resort
to decompressing in a PHP container that (through my slipping up) it
proceeded to escape from.
Help us Python-Kenobi, save us from PHP ;-)
----------
messages: 86094
nosy: phr
severity: normal
status: open
title: raw deflate format and zlib module
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5784>
_______________________________________
From =?utf-8?q?St=C3=A9phane_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za Sat Apr 18 15:53:48 2009
From: =?utf-8?q?St=C3=A9phane_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za (=?utf-8?q?St=C3=A9phane_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za)
Date: Sat, 18 Apr 2009 13:53:48 +0000
Subject: [New-bugs-announce] [issue5785] Condition.wait() does not respect
its timeout
In-Reply-To: <1240062828.56.0.381280263985.issue5785@psf.upfronthosting.co.za>
Message-ID: <1240062828.56.0.381280263985.issue5785@psf.upfronthosting.co.za>
New submission from St?phane <stephane.bisinger at gmail.com>:
I have an issue with the wait() method of Condition which doesn't seem
to respect the timeout it is given: I couldn't create a simple example
to reproduce the bug, because if I try to do something small and simple
everything works as expected, but in the actual code it doesn't work,
so here's the link to the code:
http://github.com/Kjir/amsn2/blob/
bda6829d0c7d50a1cbf1188cdfa3789c4b7967c5/amsn2/gui/front_ends/curses/
contact_list.py
The most interesting function is the last one, where there is a wait
with timeout of 1 second. If I have a look at the logs, after the
initial download of the list there is nothing happening, while I'd
expect to see a "check" cycle every second or so. If there is a
notification arriving, the whole thing fires up and updates the contact
list as expected, but the timeout itself doesn't work.
I don't know if there could be a problem with other modules, for
instance gobject, but if there is then you should update the
documentation to point out such incompatibilities.
If you could help me to create a simpler program to test this issue I
would happy to provide you a test case, but I am out of ideas right now
on how to narrow down the issue.
If you want to download the code and test it, here are the instructions:
git clone git://github.com/Kjir/amsn2.git
cd amsn2
git checkout -b curses_cl origin/curs_cl
python amsn2.py -f curses 2>> run.log
Log in with an msn account, tail -f run.log in another terminal to
watch the logs
If you want to se what happens on a notify, one of your contacts should
change status.
And here are a very brief explanation on how the code is called, if you
need it:
the whole code is divided in basically three areas, core, protocol and
gui. I am working on the gui side and the methods contactListUpdated,
groupUpdated and contactUpdated are called by the core through a
gobject signal.
My python version is 2.5.2 on gentoo amd64, use flags:
berkdb gdbm ipv6 ncurses readline ssl threads tk xml
-build -doc -elibc_uclibc -examples -sqlite -ucs2 -wininst
If you need anything else, just ask!
Oh and here's the link to the posts on comp.lang.python:
http://groups.google.com/group/comp.lang.python/browse_thread/
thread/7fc388c30304bf22#
----------
components: Library (Lib)
messages: 86118
nosy: Kjir
severity: normal
status: open
title: Condition.wait() does not respect its timeout
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5785>
_______________________________________
From report at bugs.python.org Sat Apr 18 18:00:28 2009
From: report at bugs.python.org (seesee)
Date: Sat, 18 Apr 2009 16:00:28 +0000
Subject: [New-bugs-announce] [issue5786] len(reversed([1, 2,
3])) does not work anymore in 2.6.2
In-Reply-To: <1240070428.04.0.628652917462.issue5786@psf.upfronthosting.co.za>
Message-ID: <1240070428.04.0.628652917462.issue5786@psf.upfronthosting.co.za>
New submission from seesee <cthedot at gmail.com>:
It seems python 2.6.2 (at least under Windows, I have not tested other
platforms) does break the len function on the reversed iterator:
Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> len(reversed([1,2,3]))
3
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.
>>> len(reversed([1,2,3]))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: object of type 'listreverseiterator' has no len()
I don't think it was meant to work but it did in Python 2.6.1 (and 2.5
as shown above). I guess it has something to do with Issue #3689 and
guess __len__ was simply removed.
Problem really is that Python 2.6.2 breaks backwards compatibility.
----------
components: Windows
messages: 86122
nosy: seesee
severity: normal
status: open
title: len(reversed([1,2,3])) does not work anymore in 2.6.2
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5786>
_______________________________________
From report at bugs.python.org Sat Apr 18 19:45:18 2009
From: report at bugs.python.org (Aleksi Torhamo)
Date: Sat, 18 Apr 2009 17:45:18 +0000
Subject: [New-bugs-announce] [issue5787] object.__getattribute__(super,
'__bases__') crashes the interpreter.
In-Reply-To: <1240076718.56.0.20381278649.issue5787@psf.upfronthosting.co.za>
Message-ID: <1240076718.56.0.20381278649.issue5787@psf.upfronthosting.co.za>
New submission from Aleksi Torhamo <alexerion+pythonbugs at gmail.com>:
object.__getattribute__(super, '__bases__') crashes the interpreter.
It seems to happen at Objects/typeobject.c in type_get_bases(), when
tp_bases is NULL.
Crashing types in __builtins__ per version would seem to be:
python2.4: slice frozenset super staticmethod float enumerate long
xrange tuple reversed property complex buffer classmethod
python2.5: slice frozenset super staticmethod float enumerate long
xrange reversed property complex buffer classmethod
python2.6: slice super staticmethod float enumerate long xrange reversed
python3.0: memoryview slice super filter range staticmethod float
enumerate reversed map
2.7 and 3.1 not tested since i don't have them installed.
----------
components: Interpreter Core
messages: 86126
nosy: alexer
severity: normal
status: open
title: object.__getattribute__(super, '__bases__') crashes the interpreter.
type: crash
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5787>
_______________________________________
From report at bugs.python.org Sat Apr 18 20:37:40 2009
From: report at bugs.python.org (Brian Quinlan)
Date: Sat, 18 Apr 2009 18:37:40 +0000
Subject: [New-bugs-announce] [issue5788] datetime.timedelta is inconvenient
to use...
In-Reply-To: <1240079860.62.0.329216013715.issue5788@psf.upfronthosting.co.za>
Message-ID: <1240079860.62.0.329216013715.issue5788@psf.upfronthosting.co.za>
New submission from Brian Quinlan <brian at sweetapp.com>:
...in seconds-based library functions (e.g. time.sleep) and calculations
(e.g. distance = velocity * ?).
----------
components: Library (Lib)
messages: 86132
nosy: bquinlan
severity: normal
status: open
title: datetime.timedelta is inconvenient to use...
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5788>
_______________________________________
From report at bugs.python.org Sun Apr 19 04:53:09 2009
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 19 Apr 2009 02:53:09 +0000
Subject: [New-bugs-announce] [issue5789] powerset recipe listed twice in
itertools docs
In-Reply-To: <1240109589.15.0.0305049263162.issue5789@psf.upfronthosting.co.za>
Message-ID: <1240109589.15.0.0305049263162.issue5789@psf.upfronthosting.co.za>
New submission from Steven D'Aprano <steve at pearwood.info>:
In the itertools recipes section of the docs, powerset() is listed
twice.
http://docs.python.org/library/itertools.html#recipes
----------
assignee: georg.brandl
components: Documentation
messages: 86155
nosy: georg.brandl, stevenjd
severity: normal
status: open
title: powerset recipe listed twice in itertools docs
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5789>
_______________________________________
From report at bugs.python.org Sun Apr 19 04:56:44 2009
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 19 Apr 2009 02:56:44 +0000
Subject: [New-bugs-announce] [issue5790] itertools.izip python code has a
typo
In-Reply-To: <1240109804.52.0.172902644967.issue5790@psf.upfronthosting.co.za>
Message-ID: <1240109804.52.0.172902644967.issue5790@psf.upfronthosting.co.za>
New submission from Steven D'Aprano <steve at pearwood.info>:
In the documentation for itertools, the Python equivalent to izip has
a typo:
yield yield tuple(map(next, iterables))
Obviously should only have a single yield.
http://docs.python.org/library/itertools.html#itertools.izip
----------
assignee: georg.brandl
components: Documentation
messages: 86156
nosy: georg.brandl, stevenjd
severity: normal
status: open
title: itertools.izip python code has a typo
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5790>
_______________________________________
From report at bugs.python.org Sun Apr 19 12:57:48 2009
From: report at bugs.python.org (Carl Friedrich Bolz)
Date: Sun, 19 Apr 2009 10:57:48 +0000
Subject: [New-bugs-announce] [issue5791] title information of unicodedata is
wrong in some cases
In-Reply-To: <1240138668.81.0.556481056778.issue5791@psf.upfronthosting.co.za>
Message-ID: <1240138668.81.0.556481056778.issue5791@psf.upfronthosting.co.za>
New submission from Carl Friedrich Bolz <cfbolz at gmx.de>:
There seems to be a problem with some unicode character's title information:
$ python2.6
Python 2.6.2c1 (release26-maint, Apr 14 2009, 08:02:48)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> unichr(453)
u'\u01c5'
>>> unichr(453).title()
u'\u01c4'
But the title should return the same character, according to this:
http://www.fileformat.info/info/unicode/char/01c5/index.htm
(I also checked the files that unicode.org provides). I tried to follow
the problem a bit, it seems to come from _PyUnicode_ToTitlecase in
unicodetype.c. The unicode record contains the offset of the character
to its titled version. If the character is its own titled version, then
the offset is zero. But zero is also used for when there is no
information available, so the offset to the upper-case version of the
character is used. If this is a different character (as for the example
above), the result of .title() is wrong.
----------
components: Interpreter Core
messages: 86163
nosy: cfbolz
severity: normal
status: open
title: title information of unicodedata is wrong in some cases
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5791>
_______________________________________
From report at bugs.python.org Sun Apr 19 14:33:20 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 19 Apr 2009 12:33:20 +0000
Subject: [New-bugs-announce] [issue5792] Enable short float repr() on
Solaris/x86
In-Reply-To: <1240144400.05.0.462557167881.issue5792@psf.upfronthosting.co.za>
Message-ID: <1240144400.05.0.462557167881.issue5792@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
The short float repr() that's in 3.1 (probably) doesn't work on
Solaris/x86 when using Sun's compiler to build. It would be nice to
fix this.
It probably works on Solaris/x86/gcc, though confirmation of that would be
appreciated.
Marking as easy, because this should be an easy task for someone who has
access to the appropriate setup. I can probably do all the
autoconf/define stuff required, but I need help from someone who has
access to Solaris/x86 and who can be available to do testing.
----------
components: Interpreter Core
keywords: easy
messages: 86168
nosy: marketdickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: Enable short float repr() on Solaris/x86
type: feature request
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5792>
_______________________________________
From report at bugs.python.org Sun Apr 19 14:57:47 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 19 Apr 2009 12:57:47 +0000
Subject: [New-bugs-announce] [issue5793] Rationalize isdigit / isalpha /
tolower / ... uses throughout Python source
In-Reply-To: <1240145867.12.0.0306505871305.issue5793@psf.upfronthosting.co.za>
Message-ID: <1240145867.12.0.0306505871305.issue5793@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
Problem: the standard C character handling functions from ctype.h
(isalpha, isdigit, isxdigit, isspace, toupper, tolower, etc.) are locale
aware, but for almost all uses CPython needs locale-unaware versions of
these.
There are various solutions in the current source:
- there's a file Include/bytes_methods.h which provides suitable
ISDIGIT/ISALPHA/... macros, but also undefines the standard functions.
As it is, it can't be included in Python.h since that would break
3rd party code that includes Python.h and also uses isdigit.
- some files have their own solution: Python/pystrtod.c defines
its own (probably inefficient) ISDIGIT and ISSPACE macros.
- in some places the standard C functions are just used directly (and
possibly incorrectly). A gotcha here is that one has to remember to use
Py_CHARMASK to avoid errors on some platforms. (See issue 3633 for an
example.)
It would be nice to clean all this up, and have one central, efficient,
easy-to-use set of Py_ISDIGIT/Py_ISALPHA ... locale-independent macros (or
functions) that could be used safely throughout the Python source.
----------
components: Interpreter Core
keywords: easy
messages: 86170
nosy: eric.smith, marketdickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: Rationalize isdigit / isalpha / tolower / ... uses throughout Python source
type: feature request
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5793>
_______________________________________
From report at bugs.python.org Sun Apr 19 21:53:00 2009
From: report at bugs.python.org (Carl Witty)
Date: Sun, 19 Apr 2009 19:53:00 +0000
Subject: [New-bugs-announce] [issue5794] pickle/cPickle of recursive tuples
create pickles that cPickle can't load
In-Reply-To: <1240170780.68.0.204813353535.issue5794@psf.upfronthosting.co.za>
Message-ID: <1240170780.68.0.204813353535.issue5794@psf.upfronthosting.co.za>
New submission from Carl Witty <Carl.Witty at gmail.com>:
When I try to pickle a recursive tuple (that recurses through a list),
pickle can load the result but cPickle fails with "unpickling stack
overflow".
(I just downloaded and built Python 2.6.2 on 64-bit x86 Debian testing
to verify this bug; it also fails on Python 2.5.2 on 32-bit x86 Debian
testing. I think that probably it doesn't depend on the architecture or
operating system at all.)
Here is the test case. At the end, cPickle.loads raises an exception;
instead, it should produce an object equivalent to v, like pickle.loads
does. (I didn't show it in the test case, but pickles produced by
pickle.dumps have the same behavior -- they work with pickle.loads but
not cPickle.loads.)
>>> v = ([],)
>>> v[0].append(v)
>>> import pickle
>>> import cPickle
>>> v
([([...],)],)
>>> vp = cPickle.dumps(v)
>>> pickle.loads(vp)
([([...],)],)
>>> cPickle.loads(vp)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
cPickle.UnpicklingError: unpickling stack underflow
----------
components: Library (Lib)
messages: 86177
nosy: cwitty
severity: normal
status: open
title: pickle/cPickle of recursive tuples create pickles that cPickle can't load
type: behavior
versions: Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5794>
_______________________________________
From report at bugs.python.org Mon Apr 20 00:18:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Apr 2009 22:18:43 +0000
Subject: [New-bugs-announce] [issue5795] test_distutils failure on the ppc
Debian buildbot
In-Reply-To: <1240179523.09.0.84546813194.issue5795@psf.upfronthosting.co.za>
Message-ID: <1240179523.09.0.84546813194.issue5795@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
The following test fails on the ppc Debian buildbot (trunk and py3k):
test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase) ...
gcc-4.3: x86_64: No such file or directory
cc1: error: unrecognized command line option "-arch"
ERROR
======================================================================
ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/home/pybot/buildarea/trunk.klose-debian-ppc/build/Lib/distutils/tests/test_build_ext.py",
line 64, in test_build_ext
cmd.run()
File
"/home/pybot/buildarea/trunk.klose-debian-ppc/build/Lib/distutils/command/build_ext.py",
line 353, in run
self.build_extensions()
File
"/home/pybot/buildarea/trunk.klose-debian-ppc/build/Lib/distutils/command/build_ext.py",
line 480, in build_extensions
self.build_extension(ext)
File
"/home/pybot/buildarea/trunk.klose-debian-ppc/build/Lib/distutils/command/build_ext.py",
line 550, in build_extension
depends=ext.depends)
File
"/home/pybot/buildarea/trunk.klose-debian-ppc/build/Lib/distutils/ccompiler.py",
line 695, in compile
self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts)
File
"/home/pybot/buildarea/trunk.klose-debian-ppc/build/Lib/distutils/unixccompiler.py",
line 180, in _compile
raise CompileError, msg
CompileError: command 'gcc' failed with exit status 1
Here are links to the log files:
http://www.python.org/dev/buildbot/trunk.stable/ppc%20Debian%20unstable%20trunk/builds/388/step-test/0
http://www.python.org/dev/buildbot/3.x.stable/ppc%20Debian%20unstable%203.x/builds/654/step-test/0
----------
assignee: tarek
components: Distutils
messages: 86183
nosy: pitrou, tarek
priority: normal
severity: normal
status: open
title: test_distutils failure on the ppc Debian buildbot
type: behavior
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5795>
_______________________________________
From report at bugs.python.org Mon Apr 20 01:08:38 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Apr 2009 23:08:38 +0000
Subject: [New-bugs-announce] [issue5796] test_posix,
test_pty crash under Windows
In-Reply-To: <1240182518.87.0.621846990716.issue5796@psf.upfronthosting.co.za>
Message-ID: <1240182518.87.0.621846990716.issue5796@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
This seems related to the import behaviour changes in regrtest.
Re-running test 'test_posix' in verbose mode
test test_posix crashed -- <type 'exceptions.ImportError'>: No module
named pwd
Traceback (most recent call last):
File "../lib/test/regrtest.py", line 569, in runtest_inner
the_package = __import__(abstest, globals(), locals(), [])
File
"E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_posix.py",
line 8, in <module>
import pwd
ImportError: No module named pwd
Re-running test 'test_pty' in verbose mode
test test_pty crashed -- <type 'exceptions.ImportError'>: No module
named fcntl
Traceback (most recent call last):
File "../lib/test/regrtest.py", line 569, in runtest_inner
the_package = __import__(abstest, globals(), locals(), [])
File
"E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_pty.py",
line 2, in <module>
import fcntl
ImportError: No module named fcntl
http://www.python.org/dev/buildbot/trunk.stable/x86%20XP-4%20trunk/builds/2056/step-test/0
----------
assignee: r.david.murray
components: Tests, Windows
messages: 86186
nosy: pitrou, r.david.murray
priority: high
severity: normal
stage: needs patch
status: open
title: test_posix, test_pty crash under Windows
type: crash
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5796>
_______________________________________
From report at bugs.python.org Mon Apr 20 06:01:24 2009
From: report at bugs.python.org (nabeel)
Date: Mon, 20 Apr 2009 04:01:24 +0000
Subject: [New-bugs-announce] [issue5797] there is en exception om Create
User page
In-Reply-To: <1240200084.56.0.449706089015.issue5797@psf.upfronthosting.co.za>
Message-ID: <1240200084.56.0.449706089015.issue5797@psf.upfronthosting.co.za>
New submission from nabeel <iamravian at gmail.com>:
there is en exception om Create User page
----------
messages: 86189
nosy: nabeel
severity: normal
status: open
title: there is en exception om Create User page
type: crash
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5797>
_______________________________________
From report at bugs.python.org Mon Apr 20 13:02:12 2009
From: report at bugs.python.org (Ismail Donmez)
Date: Mon, 20 Apr 2009 11:02:12 +0000
Subject: [New-bugs-announce] [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
New submission from Ismail Donmez <ismail at namtrac.org>:
Using latest python 2.6 branch; test_asynchat fails with the following
error:
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x1689238> (<class
'socket.error'>:[Errno 9] Bad file descriptor
[/Users/cartman/Sources/python-2.6/Lib/asyncore.py|readwrite|107]
[/Users/cartman/Sources/python-2.6/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1]
[/Users/cartman/Sources/python-2.6/Lib/socket.py|_dummy|165])
Using Mac OSX 10.5.6.
----------
components: Tests
messages: 86193
nosy: cartman
severity: normal
status: open
title: test_asynchat fails on Mac OSX
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________
From report at bugs.python.org Mon Apr 20 13:07:14 2009
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 20 Apr 2009 11:07:14 +0000
Subject: [New-bugs-announce] [issue5799] Change ntpath functions to
implicitly support UNC paths
In-Reply-To: <1240225634.02.0.80774698084.issue5799@psf.upfronthosting.co.za>
Message-ID: <1240225634.02.0.80774698084.issue5799@psf.upfronthosting.co.za>
New submission from Larry Hastings <larry at hastings.org>:
This patch changes "ntpath" so all functions handle UNC paths.
In a Windows path string, a UNC path functions *exactly* like a drive
letter. This patch means that the Python path split/join functions
treats them as if they were.
For instance:
>>> splitdrive("A:\\FOO\\BAR.TXT")
("A:", "\\FOO\\BAR.TXT")
With this patch applied:
>>> splitdrive("\\\\HOSTNAME\\SHARE\\FOO\\BAR.TXT")
("\\\\HOSTNAME\\SHARE", "\\FOO\\BAR.TXT")
This methodology only breaks down in one place: there is no "default
directory" for a UNC share point. E.g. you can say
>>> os.chdir("c:")
or
>>> os.chdir("c:foo\\bar")
but you can't say
>>> os.chdir("\\\\hostname\\share")
The attached patch changes:
* Modify join, split, splitdrive, and ismount to add explicit support
for UNC paths. (The other functions pick up support from these four.)
* Simplify isabs and normpath, now that they don't need to be delicate
about UNC paths.
* Modify existing unit tests and add new ones.
* Document the changes to the API.
* Deprecate splitunc, with a warning and a documentation remark.
This patch adds one subtle change I hadn't expected. If you call
split() with a drive letter followed by a trailing slash, it returns the
trailing slash as part of the "head" returned. E.g.
>>> os.path.split("\\")
("\\", "")
>>> os.path.split("A:\\")
("A:\\", "")
This is mentioned in the documentation, as follows:
Trailing slashes are stripped from head unless it is the root
(one or more slashes only).
For some reason, when os.path.split was called with a UNC path with only
a trailing slash, it stripped the trailing slash:
>>> os.path.split("\\\\hostname\\share\\")
("\\\\hostname\\share", "")
My patch changes this behavior; you would now see:
>>> os.path.split("\\\\hostname\\share\\")
("\\\\hostname\\share\\", "")
I think it's an improvement--this is more consistent. Note that this
does *not* break the documented requirement that
os.path.join(os.path.split(path)) == path; that continues to work fine.
In the interests of full disclosure: I submitted a patch providing this
exact behavior just over ten years ago. GvR accepted it into Python
1.5.2b2 (marked "*EXPERIMENTAL*") and removed it from 1.5.2c1.
You can read GvR's commentary upon removing it; see comments in
Misc/HISTORY dated "Tue Apr 6 19:38:18 1999". If memory serves
correctly, the "problems" cited were only on Cygwin. At the time Cygwin
used "ntpath", and it supported "//a/foo" as an alias for "A:\\FOO".
You can see how this would cause Cygwin problems.
In the intervening decade, two highly relevant things have happened:
* Python no longer uses ntpath for os.path on Cygwin. It instead uses
posixpath.
* Cygwin removed the "//a/foo" drive letter hack. In fact, I believe it
now support UNC paths.
Therefore this patch will have no effect on Cygwin users.
p.s. I discussed this patch with Mark Hammond at the CPython sprint at
PyCon 2008. I therefore added him to the nosy list. I have no idea if
this is proper etiquette; I apologize in advance if it is not.
----------
components: Windows
files: lch.ntpath.r71757.diff
keywords: patch
messages: 86195
nosy: lhastings, mhammond
severity: normal
status: open
title: Change ntpath functions to implicitly support UNC paths
type: feature request
versions: Python 3.1
Added file: http://bugs.python.org/file13723/lch.ntpath.r71757.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5799>
_______________________________________
From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za Mon Apr 20 18:01:05 2009
From: =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za (=?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za)
Date: Mon, 20 Apr 2009 16:01:05 +0000
Subject: [New-bugs-announce] [issue5800] make wsgiref.headers.Headers accept
empty constructor
In-Reply-To: <1240243265.38.0.0946630520568.issue5800@psf.upfronthosting.co.za>
Message-ID: <1240243265.38.0.0946630520568.issue5800@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
wsgiref.headers.Headers will let you manage a collection of HTTP
response headers, but the constructor forces you to provide a list:
>>> from wsgiref.headers import Headers
>>> headers = Headers([])
>>> headers.add_header('Content-Type', 'text/plain')
A logical change would be to allowed creating an empty Headers instance:
>>> from wsgiref.headers import Headers
>>> headers = Headers()
>>> headers.add_header('Content-Type', 'text/plain')
----------
components: Library (Lib)
messages: 86199
nosy: pje, tarek
severity: normal
status: open
title: make wsgiref.headers.Headers accept empty constructor
type: feature request
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5800>
_______________________________________
From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za Mon Apr 20 18:03:57 2009
From: =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za (=?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za)
Date: Mon, 20 Apr 2009 16:03:57 +0000
Subject: [New-bugs-announce] [issue5801] spurious empty lines in wsgiref code
In-Reply-To: <1240243437.89.0.00300959182441.issue5801@psf.upfronthosting.co.za>
Message-ID: <1240243437.89.0.00300959182441.issue5801@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
the wsgiref package is hard to read, there are blocs of empty lines.
Can I pep8-fy it ?
----------
components: Library (Lib)
messages: 86200
nosy: pje, tarek
severity: normal
status: open
title: spurious empty lines in wsgiref code
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5801>
_______________________________________
From report at bugs.python.org Mon Apr 20 18:42:30 2009
From: report at bugs.python.org (Hong Chen)
Date: Mon, 20 Apr 2009 16:42:30 +0000
Subject: [New-bugs-announce] [issue5802] The security descriptors of python
binaries in Windows are not strict enough
In-Reply-To: <1240245750.84.0.391245943129.issue5802@psf.upfronthosting.co.za>
Message-ID: <1240245750.84.0.391245943129.issue5802@psf.upfronthosting.co.za>
New submission from Hong Chen <cn.hongchen at gmail.com>:
The security descriptors of python binaries (like python.exe,
pythonw.exe, etc) allow any Authenticated Users to modify these
binaries. This may cause a privilege-escalation problem since
administrators may use python binaries when performing administrative
tasks. A normal unprivileged user may turn a python binary into a
trojan and acquire administrator's sids.
Test environment: windows vista, python 2.6
----------
components: Windows
messages: 86201
nosy: kindloaf
severity: normal
status: open
title: The security descriptors of python binaries in Windows are not strict enough
type: security
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5802>
_______________________________________
From report at bugs.python.org Mon Apr 20 21:01:31 2009
From: report at bugs.python.org (Dave Baggett)
Date: Mon, 20 Apr 2009 19:01:31 +0000
Subject: [New-bugs-announce] [issue5803] email/quoprimime: encode and decode
are very slow on large messages
In-Reply-To: <1240254091.33.0.632025917195.issue5803@psf.upfronthosting.co.za>
Message-ID: <1240254091.33.0.632025917195.issue5803@psf.upfronthosting.co.za>
New submission from Dave Baggett <jython at baggett.org>:
The implementation of encode and decode are slow, and scale nonlinearly
in the size of the message to be encoded/decoded.
A simple fix is to use an array.array('c') and append to it, rather
than using string concatenation. This change makes the code more than an
order of magnitude faster.
----------
components: Library (Lib)
messages: 86203
nosy: dmbaggett
severity: normal
status: open
title: email/quoprimime: encode and decode are very slow on large messages
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5803>
_______________________________________
From report at bugs.python.org Tue Apr 21 16:30:40 2009
From: report at bugs.python.org (Vah Rashim)
Date: Tue, 21 Apr 2009 14:30:40 +0000
Subject: [New-bugs-announce] [issue5805] Distutils (or py2exe) error with
DistributionMetaData
In-Reply-To: <1240324240.34.0.236937269756.issue5805@psf.upfronthosting.co.za>
Message-ID: <1240324240.34.0.236937269756.issue5805@psf.upfronthosting.co.za>
New submission from Vah Rashim <d233858 at bsnow.net>:
I'find issue http://bugs.python.org/issue708320. It's closed, but in
python 2.6 this problem are yet exists.
I'm fix it, but don't know, is this good solution.
quote this my message from above issue without changes^
"""
I'm running py2exe on python 2.6 and have this error, too. I'm look
through distutils/dist.py and read following:
self.metadata = DistributionMetadata()
method_basenames = dir(self.metadata) + \
['fullname', 'contact', 'contact_email']
for basename in method_basenames:
method_name = "get_" + basename
setattr(self, method_name, getattr(self.metadata, method_name))
I'm printing dir(self.metadata) and get this lines:
['__doc__', '__init__', '__module__', 'author', 'author_email',
'description', 'get_author', 'get_author_email', 'get_co
ntact', 'get_contact_email', 'get_description', 'get_fullname',
'get_keywords', 'get_licence', 'get_long_description', '
get_maintainer', 'get_maintainer_email', 'get_name', 'get_platforms',
'get_url', 'get_version', 'keywords', 'licence', '
long_description', 'maintainer', 'maintainer_email', 'name',
'platforms', 'url', 'version', 'write_pkg_info']
code in dist.py trying add all methods from metadata to self, even
'magic' and getters. I think, that's wrong, because no method like
get___doc, get_get_contact and other.
I'm solve this problem by adding regexp for checking is this method
allow for adding to self.
this is my (ugly, i think) code:
for basename in method_basenames:
if re.match(r'(__|get_|write_)\w+', basename) is None: #MY FIXES!
method_name = "get_" + basename
setattr(self, method_name, getattr(self.metadata, method_name))
With this change, all py2exe works work correctly (and i don't try
distutils in other cases).
P.S. i don't know, is this python or py2exe problem: maybe py2exe
replcae nature python distutils module.
"""
----------
assignee: tarek
components: Distutils
messages: 86230
nosy: tarek, varash
severity: normal
status: open
title: Distutils (or py2exe) error with DistributionMetaData
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5805>
_______________________________________
From report at bugs.python.org Tue Apr 21 16:41:32 2009
From: report at bugs.python.org (Dave Fliger)
Date: Tue, 21 Apr 2009 14:41:32 +0000
Subject: [New-bugs-announce] [issue5806] MySQL crash on machine startup....
In-Reply-To: <1240324892.81.0.865146510595.issue5806@psf.upfronthosting.co.za>
Message-ID: <1240324892.81.0.865146510595.issue5806@psf.upfronthosting.co.za>
New submission from Dave Fliger <plattecountyducks at yahoo.com>:
I recently (in the last 5 days) downloaded and installed Python 2.6.x.
Upon startup of this machine I noticed a Windows warning
that "mysqld.exe could not start...". I really didn't pay attention to
it until today since I had no plans to use MySQL or any other app that
might use it.
I also use XAMPP, which does rely on MySQL. This morning when I started
XAMPP, the MySQL server crashed on startup of XAMPP. I removed Python
by uninstalling it, set XAMPP to start on startup and rebooted.
Bingo!!!! No problem.
Seems like the install process does not check for other applications
using MySQL and appropriates the db for itself. Is this correct? If
that is correct, then the install process needs to be altered.
Is this an issue? I don't know. You tell me.
----------
components: Installation
messages: 86231
nosy: plattecoducks
severity: normal
status: open
title: MySQL crash on machine startup....
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5806>
_______________________________________
From report at bugs.python.org Tue Apr 21 17:12:43 2009
From: report at bugs.python.org (Vito De Tullio)
Date: Tue, 21 Apr 2009 15:12:43 +0000
Subject: [New-bugs-announce] [issue5807] ConfigParser.RawConfigParser it's
an "old-style" class
In-Reply-To: <1240326763.95.0.709769411309.issue5807@psf.upfronthosting.co.za>
Message-ID: <1240326763.95.0.709769411309.issue5807@psf.upfronthosting.co.za>
New submission from Vito De Tullio <vito.detullio at gmail.com>:
RawConfigParser does not inherit from object, so using (to make an
example) super() it's impossible.
Python 2.6 (r26:66714, Feb 3 2009, 20:52:03)
[GCC 4.3.2 [gcc-4_3-branch revision 141291]] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from ConfigParser import RawConfigParser
>>> class MyConfigParser(RawConfigParser):
... def __init__(self):
... super(MyConfigParser, self).__init__()
...
>>> mcp = MyConfigParser()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in __init__
TypeError: super() argument 1 must be type, not classobj
>>>
----------
components: Library (Lib)
messages: 86232
nosy: ZeD
severity: normal
status: open
title: ConfigParser.RawConfigParser it's an "old-style" class
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5807>
_______________________________________
From report at bugs.python.org Tue Apr 21 17:49:34 2009
From: report at bugs.python.org (Lawrence Allan Jones)
Date: Tue, 21 Apr 2009 15:49:34 +0000
Subject: [New-bugs-announce] [issue5808] Subprocess.getstatusoutput Fails
Executing 'dir' Command on Windows
In-Reply-To: <1240328974.09.0.446818382044.issue5808@psf.upfronthosting.co.za>
Message-ID: <1240328974.09.0.446818382044.issue5808@psf.upfronthosting.co.za>
New submission from Lawrence Allan Jones <mrwizard82d1 at earthlink.net>:
When attempting to use the subprocess.getstatusoutput() function on
Windows, I noticed an unusual error message:
"'{' is not recognized as an internal or external command,
operable program or batch file."
When the output contained this message, the status was always 256.
>From the interactive prompt, I performed the following:
Python 3.0.1 (r301:69561, Feb 13 2009, 20:04:18) [MSC v.1500 32 bit
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> cmdline = 'dir'
>>> (status, output) = subprocess.getstatusoutput(cmdline)
>>> status
256
>>> output
"'{' is not recognized as an internal or external command,\noperable
program or
batch file."
>>>
I think this is an error (but it is possible I misunderstand the
documentation for the function :) .)
----------
messages: 86242
nosy: mrwizard82d1
severity: normal
status: open
title: Subprocess.getstatusoutput Fails Executing 'dir' Command on Windows
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5808>
_______________________________________
From report at bugs.python.org Tue Apr 21 18:01:52 2009
From: report at bugs.python.org (Michael J. Fromberger)
Date: Tue, 21 Apr 2009 16:01:52 +0000
Subject: [New-bugs-announce] [issue5809] "No such file or directory" with
framework build under MacOS 10.4.11
In-Reply-To: <1240329712.27.0.0341104214309.issue5809@psf.upfronthosting.co.za>
Message-ID: <1240329712.27.0.0341104214309.issue5809@psf.upfronthosting.co.za>
New submission from Michael J. Fromberger <michael.j.fromberger at gmail.com>:
Checkout:
<http://svn.python.org/projects/python/tags/r262>
Configure:
env CFLAGS="-I/opt/local/include" LDFLAGS="-L/opt/local/lib" sh
./configure --enable-framework --enable-shared --enable-readline
Build:
make
The configuration step completes successfully, and the build proceeds;
however, the following error occurs:
gcc -L/opt/local/lib -u _PyMac_Error
Python.framework/Versions/2.6/Python -o python.exe \
Modules/python.o \
-L. -lpython2.6 -ldl
This appears to be a problem in the definition of the LINKFORSHARED
variable in the Makefile, but I am not sure what the intended meaning of
that variable is, so I'm not sure what the fix should be.
A complete make trace is attached.
----------
components: Build
files: makedump.txt
messages: 86245
nosy: creachadair
severity: normal
status: open
title: "No such file or directory" with framework build under MacOS 10.4.11
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file13728/makedump.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5809>
_______________________________________
From report at bugs.python.org Wed Apr 22 03:00:42 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 22 Apr 2009 01:00:42 +0000
Subject: [New-bugs-announce] [issue5810] test_distutils fails -
sysconfig._config_vars is None
In-Reply-To: <1240362042.52.0.447474592558.issue5810@psf.upfronthosting.co.za>
Message-ID: <1240362042.52.0.447474592558.issue5810@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
Sorry, but the commit r69598 (due to Issue4524) has a problem. On
Windows and Linux (although not on MacOSX), test_distutils fails:
test_distutils
test test_distutils failed -- Traceback (most recent call last):
File "C:\Python26\lib\distutils\tests\test_build_scripts.py", line 93,
in test_version_int
old = sysconfig._config_vars.get('VERSION')
AttributeError: 'NoneType' object has no attribute 'get'
Using the documented API (`sysconfig.get_config_vars()`) instead of an
uninitialized private variable (`sysconfig._config_vars.get('VERSION')`)
may fix it.
The following session is from my a Windows machine:
>>> from distutils import sysconfig
>>> print sysconfig._config_vars
None
>>> s = sysconfig.get_config_vars()
>>> s
{'EXE': '.exe', ...}
>>> sysconfig._config_vars
{'EXE': '.exe', ...}
>>>
We face this failure while testing the ActivePython builds based on
Python 2.6.2.
----------
assignee: tarek
components: Distutils
messages: 86266
nosy: srid, tarek, trentm
severity: normal
status: open
title: test_distutils fails - sysconfig._config_vars is None
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5810>
_______________________________________
From report at bugs.python.org Wed Apr 22 08:15:53 2009
From: report at bugs.python.org (Torsten Rottmann)
Date: Wed, 22 Apr 2009 06:15:53 +0000
Subject: [New-bugs-announce] [issue5811] io.BufferedReader.peek():
Documentation differs from Implementation
In-Reply-To: <1240380953.7.0.732520909261.issue5811@psf.upfronthosting.co.za>
Message-ID: <1240380953.7.0.732520909261.issue5811@psf.upfronthosting.co.za>
New submission from Torsten Rottmann <trott at meditec-gmbh.com>:
The documented behavior of io.BufferedReader.peek([n]) states:
peek([n])
Return 1 (or n if specified) bytes from a buffer without advancing the
position.
Thereas the parameter n is the _max_ length of returned bytes.
Implementation is:
def _peek_unlocked(self, n=0):
want = min(n, self.buffer_size)
have = len(self._read_buf) - self._read_pos
if have < want:
to_read = self.buffer_size - have
current = self.raw.read(to_read)
if current:
self._read_buf = self._read_buf[self._read_pos:] +
current
self._read_pos = 0
return self._read_buf[self._read_pos:]
Where you may see that the parameter n is the _min_ length
of returned bytes. So peek(1) will return _not_ just 1 Byte, but the
remaining bytes in the buffer.
----------
components: Library (Lib)
messages: 86274
nosy: trott
severity: normal
status: open
title: io.BufferedReader.peek(): Documentation differs from Implementation
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5811>
_______________________________________
From report at bugs.python.org Wed Apr 22 12:04:27 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 22 Apr 2009 10:04:27 +0000
Subject: [New-bugs-announce] [issue5812] Fraction('1e6') should be valid.
In-Reply-To: <1240394667.14.0.711650033948.issue5812@psf.upfronthosting.co.za>
Message-ID: <1240394667.14.0.711650033948.issue5812@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
When the Fractions module was first added to Python, it was decided that
when constructing from a string, decimal strings should be allowed, but
not those including an exponent. For example, Fraction('1.1') is
currently valid, but Fraction('1.1e6') is not.
I think exponents should be permitted, for a couple of reasons:
(1) consistency: there's a clearly-defined notion of a numeric string
of the form ([sign] integer_part [fractional_part] [exponent]); the
float and Decimal constructors both accept all numeric strings.
Fraction currently accepts some, but not all of these.
(2) Easy interactions with floats: with this addition, a Fraction can
always be constructed from the str() or repr() of a finite float or
finite Decimal; without it, only some of those strings can be converted.
(3) Ease of parsing files containing numeric strings.
(4) It's a very simple change! See attached patch.
Jeffrey, any thoughts?
----------
assignee: marketdickinson
components: Library (Lib)
files: fraction_from_exp.patch
keywords: patch
messages: 86283
nosy: jyasskin, marketdickinson
priority: normal
severity: normal
stage: patch review
status: open
title: Fraction('1e6') should be valid.
type: feature request
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file13735/fraction_from_exp.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5812>
_______________________________________
From report at bugs.python.org Wed Apr 22 14:08:21 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 22 Apr 2009 12:08:21 +0000
Subject: [New-bugs-announce] [issue5813] Pointer into language reference
from __future__ module documentation
In-Reply-To: <1240402101.01.0.458823769963.issue5813@psf.upfronthosting.co.za>
Message-ID: <1240402101.01.0.458823769963.issue5813@psf.upfronthosting.co.za>
New submission from Nick Coghlan <ncoghlan at gmail.com>:
I was explaining __future__ to someone and it occurred to me that it
would be handy to have a "see also" in that module's documentation that
pointed readers to the relevant section on future statements in the
language reference
(http://docs.python.org/reference/simple_stmts.html#future-statements)
A "see also" pointer back to PEP 326 from one of those two locations
might also be worthwhile.
----------
assignee: georg.brandl
components: Documentation
messages: 86289
nosy: georg.brandl, ncoghlan
priority: low
severity: normal
status: open
title: Pointer into language reference from __future__ module documentation
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5813>
_______________________________________
From report at bugs.python.org Wed Apr 22 14:15:46 2009
From: report at bugs.python.org (Arkadiusz Miskiewicz Arkadiusz Miskiewicz)
Date: Wed, 22 Apr 2009 12:15:46 +0000
Subject: [New-bugs-announce] [issue5814] SocketServer: TypeError: waitpid()
takes no keyword arguments
In-Reply-To: <1240402546.97.0.496265243234.issue5814@psf.upfronthosting.co.za>
Message-ID: <1240402546.97.0.496265243234.issue5814@psf.upfronthosting.co.za>
New submission from Arkadiusz Miskiewicz Arkadiusz Miskiewicz <arekm at maven.pl>:
SocketServer.py contains call os.waitpid(0, options=0)
but os.waitpid doesn't accept keyword arguments.
I guess the best fix is to make waitpid accept such arguments.
Traceback (most recent call
last):
File "/usr/share/python2.6/SocketServer.py", line 281, in
_handle_request_noblock
self.process_request(request,
client_address)
File "/usr/share/python2.6/SocketServer.py", line 522, in
process_request
self.collect_children
()
File "/usr/share/python2.6/SocketServer.py", line 490, in
collect_children
pid, status = os.waitpid(0,
options=0)
TypeError: waitpid() takes no keyword arguments
----------
components: Library (Lib)
messages: 86292
nosy: arekm
severity: normal
status: open
title: SocketServer: TypeError: waitpid() takes no keyword arguments
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5814>
_______________________________________
From report at bugs.python.org Wed Apr 22 20:20:46 2009
From: report at bugs.python.org (rg3)
Date: Wed, 22 Apr 2009 18:20:46 +0000
Subject: [New-bugs-announce] [issue5815] locale.getdefaultlocale() missing
corner case
In-Reply-To: <1240424446.58.0.284100987299.issue5815@psf.upfronthosting.co.za>
Message-ID: <1240424446.58.0.284100987299.issue5815@psf.upfronthosting.co.za>
New submission from rg3 <sarbalap+freshmeat at gmail.com>:
A recent issue with one of my programs has shown that
locale.getdefaultlocale() does not handle correctly a corner case. The
issue URL is this one:
http://bitbucket.org/rg3/youtube-dl/issue/7/
Essentially, some users have LANG set to something like
es_CA.UTF-8 at valencia. In that case, locale.getdefaultlocale() returns,
as the encoding, the string "utf_8_valencia", which cannot be used as an
argument to the string encode() function. The obvious correct encoding
in this case is UTF-8.
I have traced the problem and it seems that it could be fixed by the
attached patch. It checks if the encoding, at that point, contains the
'@' symbol and, in that case, removes everything starting at that point,
leaving only "UTF-8".
I am not sure if this patch or a similar one should be applied to other
Python versions. My system has Python 2.5.2 and that's what I have patched.
Explanation as to why I put the code there:
* The simple case, es_CA.UTF-8 goes through that point too and enters
the "if".
* I wanted to remove what goes after the '@' symbol at that point, so it
either needed to be removed before the call to the normalizing function
or inside the normalization.
* As this is not what I would consider a normalization, I put the code
before the function call.
Thanks for your hard work. I hope my patch is valid.
Regards.
----------
components: Library (Lib)
files: locale.diff
keywords: patch
messages: 86312
nosy: rg3
severity: normal
status: open
title: locale.getdefaultlocale() missing corner case
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file13737/locale.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5815>
_______________________________________
From report at bugs.python.org Wed Apr 22 22:27:20 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 22 Apr 2009 20:27:20 +0000
Subject: [New-bugs-announce] [issue5816] Simplify parsing of complex numbers
and make complex('inf') valid.
In-Reply-To: <1240432040.03.0.737640809301.issue5816@psf.upfronthosting.co.za>
Message-ID: <1240432040.03.0.737640809301.issue5816@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
Here's a patch that:
1. greatly simplifies the complex parsing code in Objects/complexobject.c
2. allows nans and infinities in constructing a complex number from
a string
3. fixes missing out-of-memory checks (PyOS_ascii_strtod can fail due to
lack of memory).
Note that part 2. comes entirely for free with the parsing simplification.
But it seems to me that if float('inf') is valid, then complex('inf')
should be valid too. There are potential uses for being able to create a
complex infinity when working with the complex projective plane (a natural
domain for rational functions over the complex numbers).
----------
files: simplify_complex_parsing.patch
keywords: patch
messages: 86328
nosy: marketdickinson
severity: normal
status: open
title: Simplify parsing of complex numbers and make complex('inf') valid.
Added file: http://bugs.python.org/file13738/simplify_complex_parsing.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5816>
_______________________________________
From report at bugs.python.org Thu Apr 23 02:38:04 2009
From: report at bugs.python.org (Michael Kopinsky)
Date: Thu, 23 Apr 2009 00:38:04 +0000
Subject: [New-bugs-announce] [issue5817] Right-click behavior from Windows
Explorer
In-Reply-To: <1240447084.05.0.414854633538.issue5817@psf.upfronthosting.co.za>
Message-ID: <1240447084.05.0.414854633538.issue5817@psf.upfronthosting.co.za>
New submission from Michael Kopinsky <mkopinsky at gmail.com>:
When I right-click on a .py file in Windows Explorer and click Edit with
IDLE, it currently opens a completely new instance of IDLE (with two
windows, one for shell and one for editing the file). It would be better
if it just opened the file as an additional window in the already
running IDLE instance (assuming IDLE is already running).
----------
components: IDLE
messages: 86346
nosy: Mkop
severity: normal
status: open
title: Right-click behavior from Windows Explorer
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5817>
_______________________________________
From report at bugs.python.org Thu Apr 23 08:28:52 2009
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 23 Apr 2009 06:28:52 +0000
Subject: [New-bugs-announce] [issue5818] Fix five small bugs in the
bininstall and altbininstall pseudotargets
In-Reply-To: <1240468129.84.0.275945341066.issue5818@psf.upfronthosting.co.za>
Message-ID: <1240468129.84.0.275945341066.issue5818@psf.upfronthosting.co.za>
New submission from Larry Hastings <larry at hastings.org>:
Makefile.pre.in as checked in has several small bugs:
First, the altbininstall target runs "ln -s" without first ensuring the
destination doesn't exist. If you run "make install" twice, without
manually deleting $prefix/bin/python3 between the runs, the "ln" fails
and "make" aborts. This happens pretty early in the install process, so
for example this means you can't edit a module in Lib and re-install it.
Second, the bininstall target no longer installs a "python" executable.
It should hard-link "python" to "python3.1"--as indeed is the entire
point of having the bininstall target--but it doesn't. (I was quite
surprised by this. I would have asked the person who removed it--but
"svn blame" doesn't show you who *removed* a line, and I didn't have the
inclination to go bisecting to sleuth it out on my own.)
Third, when altbininstall and bininstall write the "python3.1" and
"python" executables in the prefix directory, they also create
corresponding "python3.1-config" and "python-config" configuration
reporting scripts. But altbininstall doesn't create a "python3-config"
to go with "python3".
Fourth, maninstall is only run as part of bininstall, not altbininstall.
This means that you only got the "python3.1" man page if you ran
bininstall, and we all know running bininstall is not recommended.
Fifth, bininstall and altbininstall don't properly honor $EXE; sometimes
they specify it and sometimes they don't. To be honest I'm not sure
this matters in the slightest. $EXE is only non-empty for Windows
builds, and Windows has a completely separate build process. And even
if you used the Makefile to build, I cannot imagine you using it to
install. Still, a foolish consistency is the hobgoblin of my little mind.
My patch fixes all of the above. While I was staring at it, I also
touched up some comments.
One final question: why do we use soft-links to "python3.1-config" but
hard links to "python3.1"?
----------
components: Build
files: lch.makefile.r71812.diff
keywords: patch
messages: 86350
nosy: lhastings
severity: normal
status: open
title: Fix five small bugs in the bininstall and altbininstall pseudotargets
versions: Python 3.1
Added file: http://bugs.python.org/file13744/lch.makefile.r71812.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5818>
_______________________________________
From report at bugs.python.org Thu Apr 23 10:25:42 2009
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 23 Apr 2009 08:25:42 +0000
Subject: [New-bugs-announce] [issue5819] Add PYTHONPREFIXES environment
variable
In-Reply-To: <1240475142.53.0.423262271042.issue5819@psf.upfronthosting.co.za>
Message-ID: <1240475142.53.0.423262271042.issue5819@psf.upfronthosting.co.za>
New submission from Larry Hastings <larry at hastings.org>:
The attached patch adds support for a new environment variable,
PYTHONPREFIXES. PYTHONPREFIXES is similar to PYTHONUSERBASE: it lets
you add "prefix directories" to be culled for site packages. It differs
from PYTHONUSERBASE in three ways:
* PYTHONPREFIXES has an empty default value. PYTHONUSERBASE has a
default, e.g. ~/.local on UNIX-like systems.
* PYTHONPREFIXES supports multiple directories, separated by the
site-specific directory separator character (os.pathsep). Earlier
directories take precedence. PYTHONUSERBASE supports specifying
at most one directory.
* PYTHONPREFIXES adds its directories to site.PREFIXES, so it reuses
the existing mechanisms for site package directories, exactly
simulating a real prefix directory. PYTHONUSERBASE only adds a
single directory, using its own custom code path.
This last point bears further discussion. PYTHONUSERBASE's custom code
to inspect only a single directory has resulted in at least one bug, if
not more, as follows:
* The bona-fide known bug: the Debian package mantainer for Python
decided to change "site-packages" to "dist-packages" in 2.6,
for reasons I still don't quite understand. He made this change in
site.addsitepackages and distutils.sysconfig.get_python_lib, and
similarly in setuptools, but he missed changing it in
site.addusersitepackages. This meant that if you used setup.py to
install a package to a private prefix directory, PYTHONUSERBASE had
no hope of ever finding the package. (Happily this bug is fixed.)
* I suspect there's a similar bug with PYTHONUSERBASE on the "os2emx"
and "riscos" platforms. site.addsitepackages on those platforms
looks in "{prefix}/Lib/site-packages", but
site.addusersitepackages looks in
"{prefix}/lib/python{version}/site-packages" as it does
on any non-Windows platform. Presumably setup.py on those two
platforms installs site packages to the directory site.addsitepackages
inspects, which means that PYTHONUSERBASE doesn't work on those
two platforms.
PYTHONUSERBASE's custom code path to add site package directories is a
source of unnecessary complexity and bugs. I cannot fathom why its
implementors chose this approach; in any case I think reusing
site.addsitepackages is a clear win. I suspect it's too late to change
the semantics of PYTHONUSERBASE to simply call site.addsitepackages,
though if that idea found support I'd be happy to contribute a patch.
A few more notes on PYTHONPREFIXES:
* PYTHONPREFIXES is gated by the exact same mechanisms that shut off
PYTHONUSERBASE.
* Specifying "-s" on the Python command line shuts it off.
* Setting the environment variable PYTHONNOUSERSITE to a non-empty
string shuts it off.
* If the effective uid / gid doesn't match the actual uid / gid it
automatically shuts off.
* I'm not enormously happy with the name. Until about an hour or two
ago I was calling it "PYTHONUSERBASES". I'm open to other
suggestions.
* I'm not sure that PYTHONPREFIX should literally modify site.PREFIXES.
If that's a bad idea I'd be happy to amend the patch so it didn't
touch site.PREFIXES.
* Reaction in python-ideas has been reasonably positive, though I gather
Nick Coughlan and Scott David Daniels think it's unnecessary. (To
read the discussion, search for the old name: "PYTHONUSERBASES".)
* Ben Finney prefers a counter-proposal he made in the python-ideas
discussion: change the existing PYTHONUSERBASE to support multiple
directories. I don't like this approach, because:
a) it means you have to explicitly add the local default if you
want to use it, and
b) PYTHONUSERBASE only inspects one directory, whereas PYTHONPREFIX
inspects all the directories Python might use for site packages.
I do admit this approach would be preferable to no change at all.
The attached patch is thrillingly simple and works fine. However it's
not ready to be merged because I haven't touched the documentation. I
figured I'd hold off until I see which way the wind blows.
I'd also be happy to whip out a PEP if that's what is called for.
----------
files: lch.pythonprefixes.r71812.diff
keywords: patch
messages: 86352
nosy: lhastings
severity: normal
status: open
title: Add PYTHONPREFIXES environment variable
Added file: http://bugs.python.org/file13745/lch.pythonprefixes.r71812.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5819>
_______________________________________
From report at bugs.python.org Thu Apr 23 10:42:51 2009
From: report at bugs.python.org (P.C. Shyamshankar)
Date: Thu, 23 Apr 2009 08:42:51 +0000
Subject: [New-bugs-announce] [issue5820] Very small bug in documentation of
json.load()
In-Reply-To: <1240476171.88.0.291496090362.issue5820@psf.upfronthosting.co.za>
Message-ID: <1240476171.88.0.291496090362.issue5820@psf.upfronthosting.co.za>
New submission from P.C. Shyamshankar <sykora at lucentbeing.com>:
The suggestion that non-ASCII based encodings should be wrapped in a
codecs.getreader instance has a small bug, ie instead of
codecs.getreader(fp)(encoding), it should be the other way around,
codecs.getreader(encoding)(fp).
It's a very small bug, and I've got a very small patch for it.
It's my first bug report/patch, so please tell me if I've done
something stupid :)
----------
assignee: georg.brandl
components: Documentation
files: json_patch.diff
keywords: patch
messages: 86355
nosy: georg.brandl, sykora
severity: normal
status: open
title: Very small bug in documentation of json.load()
versions: Python 3.1
Added file: http://bugs.python.org/file13747/json_patch.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5820>
_______________________________________
From report at bugs.python.org Thu Apr 23 15:03:09 2009
From: report at bugs.python.org (Ben North)
Date: Thu, 23 Apr 2009 13:03:09 +0000
Subject: [New-bugs-announce] [issue5821] Documentation: mention 'close' and
iteration for tarfile.TarFile.extractfile()
In-Reply-To: <1240491789.45.0.177840065777.issue5821@psf.upfronthosting.co.za>
Message-ID: <1240491789.45.0.177840065777.issue5821@psf.upfronthosting.co.za>
New submission from Ben North <bennorth at users.sourceforge.net>:
The current documentation for tarfile.TarFile.extractfile() does not
mention that the returned 'file-like object' supports close() and also
iteration. The attached patch (against svn trunk) fixes this.
(Background: I was wondering whether I could write
def process_and_close_file(f_in):
with closing(f_in) as f:
# Do stuff with f.
and have it work whether f_in was a true file or the return value of
extractfile(), and thought from the documentation that I couldn't. Of
course, I could have just tried it, but I think fixing the documentation
wouldn't hurt.)
----------
assignee: georg.brandl
components: Documentation
files: tarfile.rst.patch
keywords: patch
messages: 86366
nosy: bennorth, georg.brandl
severity: normal
status: open
title: Documentation: mention 'close' and iteration for tarfile.TarFile.extractfile()
type: feature request
Added file: http://bugs.python.org/file13749/tarfile.rst.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5821>
_______________________________________
From report at bugs.python.org Thu Apr 23 21:15:33 2009
From: report at bugs.python.org (Michael Gilbert)
Date: Thu, 23 Apr 2009 19:15:33 +0000
Subject: [New-bugs-announce] [issue5822] inconsistent behavior of range when
used in combination with remove
In-Reply-To: <1240514133.74.0.0123263268481.issue5822@psf.upfronthosting.co.za>
Message-ID: <1240514133.74.0.0123263268481.issue5822@psf.upfronthosting.co.za>
New submission from Michael Gilbert <michael.s.gilbert at gmail.com>:
using range in combination with remove is inconsistent. for example in
python 2.x:
>>> x = range(0,3)
>>> x.remove(1)
>>> x
[0, 2]
>>> x = range(0,3).remove(1)
>>> x
>>>
and in python 3.x:
>>> x = list(range(0,3))
>>> x.remove(1)
>>> x
[0, 2]
>>> x = list(range(0,3)).remove(1)
>>> x
>>>
why does the second approach remove all items from the list?
----------
components: Interpreter Core
messages: 86372
nosy: zero79
severity: normal
status: open
title: inconsistent behavior of range when used in combination with remove
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5822>
_______________________________________
From report at bugs.python.org Fri Apr 24 00:10:04 2009
From: report at bugs.python.org (Michael Gilbert)
Date: Thu, 23 Apr 2009 22:10:04 +0000
Subject: [New-bugs-announce] [issue5823] feature request: a conditional
"for" statement
In-Reply-To: <1240524604.94.0.135132223816.issue5823@psf.upfronthosting.co.za>
Message-ID: <1240524604.94.0.135132223816.issue5823@psf.upfronthosting.co.za>
New submission from Michael Gilbert <michael.s.gilbert at gmail.com>:
hello, i've recently been working on some code where i am processing a
list, but excluding certain items. the solution is to use a list
comprehension in the for statement, which for example looks like:
for m in [n for n in range( 0 , 5 ) if n != 2]
determining what's going on here isn't immediately obvious (i.e. what's
this new variable n doing?). it would be nice to have a more
streamlined syntax such as:
for m in range( 0 , 5 ) with m != 2
which is much cleaner and obvious. the statements following "with"
could be any conditional expression.
this is just a wishlist item, and i understand that it wouldn't have
much priority in the grand scheme of things. thank you for your
consideration.
----------
components: Interpreter Core
messages: 86377
nosy: zero79
severity: normal
status: open
title: feature request: a conditional "for" statement
type: feature request
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5823>
_______________________________________
From report at bugs.python.org Fri Apr 24 00:20:38 2009
From: report at bugs.python.org (Jim Dennis)
Date: Thu, 23 Apr 2009 22:20:38 +0000
Subject: [New-bugs-announce] [issue5824] SocketServer.DatagramRequestHandler
Broken under Linux
In-Reply-To: <1240525238.53.0.858571250541.issue5824@psf.upfronthosting.co.za>
Message-ID: <1240525238.53.0.858571250541.issue5824@psf.upfronthosting.co.za>
New submission from Jim Dennis <answrguy at gmail.com>:
.../lib/python2.*/SocketServer.py in class DatagramRequestHandler
contains the following comment:
# XXX Regrettably, I cannot get this working on Linux;
# s.recvfrom() doesn't return a meaningful client address.
This is a poor way to document the limitation. Someone writing code and
carefully adhering to the documentation will be presented with an
exception that stems from this and forced to read source code for the
standard libraries to understand why it's not behaving as documented.
In Issue1767511 it was recommended that the finish() method only call
sendto() if wfile.getvalue() returns a meaningful value. (The bug here
is that this returns None under Linux and the default handler calls
sendto on it anyway).
Perhaps it would be better to raise an exception with a clear error
message ("Not supported on this platform") and to update the standard
documentation to clarify the need to over-ride the .finish() method if
one does NOT want a response automatically sent back.
(The fact that finish() does a sendto() seems like a poor default for a
UNIX domain socket --- for use with the UnixDatagramServer class --- in
any event. That leads to a loop in .server_forever() where the instance
is reading its own response).
In fact the whole question of whether the DatagramRequestHandler should
be used with a UnixDatagramServer is reasonable. If it's a nonsensical
combination then perhaps some sort of check could be implemented to
raise an exception ... or at least a sensible alternative should be
added to the standard documentation.
Example:
#!/usr/bin/env python
import SocketServer
usock = '/var/tmp/pong'
class PongHandler(SocketServer.DatagramRequestHandler):
'''Play ping pong over datagram sockets
'''
def handle(self):
'''Respond to any request with "Pong"
'''
pass
def finish(self):
'''Necessary under Linux to prevent:
Exception:
File "/usr/lib/python2.5/SocketServer.py", line 588, in finish
self.socket.sendto(self.wfile.getvalue(), self.client_address)
TypeError: argument must be string or read-only character
buffer, not
'''
if self.wfile.getvalue():
SocketServer.DatagramRequestHandler.finish(self)
if __name__ == '__main__':
SocketServer.UnixDatagramServer(usock, PongHandler).serve_forever()
... and testing this with:
#!/usr/bin/env python
import socket
USOCK = "/var/tmp/pong"
if __name__ == '__main__':
sock = socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM)
sock.sendto("Ping", USOCK)
----------
components: Library (Lib)
messages: 86380
nosy: jimd
severity: normal
status: open
title: SocketServer.DatagramRequestHandler Broken under Linux
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5824>
_______________________________________
From report at bugs.python.org Fri Apr 24 02:16:01 2009
From: report at bugs.python.org (Miki Tebeka)
Date: Fri, 24 Apr 2009 00:16:01 +0000
Subject: [New-bugs-announce] [issue5825] Patch to add "remove" method
to tempfile.NamedTemporaryFile
In-Reply-To: <1240532161.78.0.907773696305.issue5825@psf.upfronthosting.co.za>
Message-ID: <1240532161.78.0.907773696305.issue5825@psf.upfronthosting.co.za>
New submission from Miki Tebeka <miki.tebeka at gmail.com>:
Adding "remove" method to NamedTemporaryFile will reduce the need to
import os.unlink when creating a NamedTemporaryFile with delete=False.
----------
components: Library (Lib)
files: tempfile.diff
keywords: patch
messages: 86387
nosy: tebeka
severity: normal
status: open
title: Patch to add "remove" method to tempfile.NamedTemporaryFile
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file13752/tempfile.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5825>
_______________________________________
From report at bugs.python.org Fri Apr 24 03:41:59 2009
From: report at bugs.python.org (Mike Rooney)
Date: Fri, 24 Apr 2009 01:41:59 +0000
Subject: [New-bugs-announce] [issue5826] new unittest function listed as
assertIsNotNot() instead of assertIsNotNone()
In-Reply-To: <1240537319.32.0.0325995706555.issue5826@psf.upfronthosting.co.za>
Message-ID: <1240537319.32.0.0325995706555.issue5826@psf.upfronthosting.co.za>
New submission from Mike Rooney <mrooney at gmail.com>:
On http://docs.python.org/dev/py3k/whatsnew/3.1.html under unittest
changes, you will find the last new function listed is assertIsNotNot()
instead of assertIsNotNone()
----------
assignee: georg.brandl
components: Documentation
messages: 86388
nosy: georg.brandl, mrooney
severity: normal
status: open
title: new unittest function listed as assertIsNotNot() instead of assertIsNotNone()
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5826>
_______________________________________
From report at bugs.python.org Fri Apr 24 06:23:59 2009
From: report at bugs.python.org (Matt Giuca)
Date: Fri, 24 Apr 2009 04:23:59 +0000
Subject: [New-bugs-announce] [issue5827] os.path.normpath doesn't preserve
unicode
In-Reply-To: <1240547039.35.0.461990786151.issue5827@psf.upfronthosting.co.za>
Message-ID: <1240547039.35.0.461990786151.issue5827@psf.upfronthosting.co.za>
New submission from Matt Giuca <matt.giuca at gmail.com>:
In the Python 2.x branch, os.path.normpath will sometimes return a str
even if given a unicode. This is not an issue in the Python 3.0 branch.
This happens specifically when it throws away all string data and
constructs its own:
>>> os.path.normpath(u'')
'.'
>>> os.path.normpath(u'.')
'.'
>>> os.path.normpath(u'/')
'/'
This is a problem if working with code which expects all strings to be
unicode strings (sometimes, functions raise exceptions if given a str,
when expecting a unicode).
I have attached patches (with test cases) for posixpath and ntpath which
correctly preserve the unicode-ness of the input string, such that the
new behaviour is:
>>> os.path.normpath(u'')
u'.'
>>> os.path.normpath(u'.')
u'.'
>>> os.path.normpath(u'/')
u'/'
I tried it on os2emxpath and plat-riscos/riscospath (the other two
OS-specific path modules), and it already worked fine for them.
Therefore, this patch fixes all necessary OS-specific versions of os.path.
----------
components: Library (Lib), Unicode
files: normpath.patch
keywords: patch
messages: 86395
nosy: mgiuca
severity: normal
status: open
title: os.path.normpath doesn't preserve unicode
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file13757/normpath.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5827>
_______________________________________
From report at bugs.python.org Fri Apr 24 12:39:59 2009
From: report at bugs.python.org (Jarek Sobieszek)
Date: Fri, 24 Apr 2009 10:39:59 +0000
Subject: [New-bugs-announce] [issue5828] Invalid behavior of unicode.lower
In-Reply-To: <1240569599.97.0.671806264573.issue5828@psf.upfronthosting.co.za>
Message-ID: <1240569599.97.0.671806264573.issue5828@psf.upfronthosting.co.za>
New submission from Jarek Sobieszek <j.sobieszek at neo.pl>:
u'\u1d79'.lower() returns u'\x00'
I think it should return u'\u1d79', at least according to my
understanding of UnicodeData.txt (the lowercase field is empty).
----------
components: Unicode
messages: 86400
nosy: jarek
severity: normal
status: open
title: Invalid behavior of unicode.lower
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5828>
_______________________________________
From report at bugs.python.org Fri Apr 24 14:26:21 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 24 Apr 2009 12:26:21 +0000
Subject: [New-bugs-announce] [issue5829] float('1e500') -> inf,
complex('1e500') -> ValueError
In-Reply-To: <1240575981.53.0.816378591256.issue5829@psf.upfronthosting.co.za>
Message-ID: <1240575981.53.0.816378591256.issue5829@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
In (for example) Python 2.6:
>>> float('1e500')
inf
>>> complex('1e500')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: float() out of range: 1e500
I'd say that one of these is a bug, but I'm not sure which one.
Ideally, float('1e500') would raise OverflowError (not ValueError). But
it's quite likely that there are people who depend on the current
behaviour, and the current behaviour also agrees with what happens for
float literals:
>>> 1e500
inf
For 2.7 and 3.1, I propose fixing the complex constructor so that
complex('1e500') produces (inf+0j). For 2.6 and 3.0, I propose leaving
the current behaviour as it is.
----------
messages: 86402
nosy: marketdickinson
severity: normal
stage: test needed
status: open
title: float('1e500') -> inf, complex('1e500') -> ValueError
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/issue5829>
_______________________________________
From report at bugs.python.org Fri Apr 24 15:35:06 2009
From: report at bugs.python.org (Kay F. Jahnke)
Date: Fri, 24 Apr 2009 13:35:06 +0000
Subject: [New-bugs-announce] [issue5830] heapq item comparison problematic
with sched's events
In-Reply-To: <1240580106.04.0.721938894312.issue5830@psf.upfronthosting.co.za>
Message-ID: <1240580106.04.0.721938894312.issue5830@psf.upfronthosting.co.za>
New submission from Kay F. Jahnke <k_f_j at web.de>:
scheduler uses heapq to schedule it's events. Heapq uses plain >/<
comparisons on the events. Now that comparisons of incomparable data
are no longer valid, the comparison fails if two events are scheduled
for the same time with the same priority, since the comparison
continues with comparing the 'action' components ov the event's tuple.
I suppose this behaviour is unwanted - at least I did not expect it and
it took me some time to figure out what it was due to. I worked around
it by assigning comparison functions to the event data type - since
this is part of the standard library, maybe a general fix should be
considered? Here's my humble snippet of code:
def evtlt ( self , other ):
if self.time < other.time:
return True
elif self.time == other.time:
return self.priority < other.priority
return False
sched.Event.__lt__ = evtlt
def evtgt ( self , other ):
if self.time > other.time:
return True
elif self.time == other.time:
return self.priority > other.priority
return False
sched.Event.__gt__ = evtgt
If anyone would care to reproduce the (?)bug, try:
import sched
def foo():
pass
def bar():
pass
s = sched.scheduler(None, None)
s.enterabs ( 0 , 0 , foo , () )
s.enterabs ( 0 , 0 , bar , () )
this produces the following output:
Traceback (most recent call last):
File "./schedbug.py", line 12, in <module>
s.enterabs ( 0 , 0 , bar , () )
File "c:\Programme\Python3.0\lib\sched.py", line 54, in enterabs
heapq.heappush(self._queue, event)
TypeError: unorderable types: function() < function()
----------
components: Library (Lib)
messages: 86408
nosy: kfj
severity: normal
status: open
title: heapq item comparison problematic with sched's events
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5830>
_______________________________________
From report at bugs.python.org Fri Apr 24 15:42:37 2009
From: report at bugs.python.org (Maxence)
Date: Fri, 24 Apr 2009 13:42:37 +0000
Subject: [New-bugs-announce] [issue5831] Doc mistake : threading.Timer is
*not* a class
In-Reply-To: <1240580557.82.0.551397939271.issue5831@psf.upfronthosting.co.za>
Message-ID: <1240580557.82.0.551397939271.issue5831@psf.upfronthosting.co.za>
New submission from Maxence <maxence at dunnewind.net>:
In the documentation, the Timer() function of the threading class is
described as a class. however, it's a function :
>>> import threading
>>> threading.Timer
<function Timer at 0x967495c>
Cheers
Maxence
----------
assignee: georg.brandl
components: Documentation
messages: 86409
nosy: georg.brandl, maxenced
severity: normal
status: open
title: Doc mistake : threading.Timer is *not* a class
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5831>
_______________________________________
From report at bugs.python.org Fri Apr 24 19:36:35 2009
From: report at bugs.python.org (Stephen Gilbert)
Date: Fri, 24 Apr 2009 17:36:35 +0000
Subject: [New-bugs-announce] [issue5832] os.path.walk fails to descend into
a directory whose name ends with a space
In-Reply-To: <1240594595.2.0.684236338423.issue5832@psf.upfronthosting.co.za>
Message-ID: <1240594595.2.0.684236338423.issue5832@psf.upfronthosting.co.za>
New submission from Stephen Gilbert <linuxelf at gmail.com>:
I just ran into this using os.path.walk. I noticed it wouldn't find
files inside a particular directory. In debugging, I found that the
name of the directory was 'BBDO Atlanta ' os.path.walk would find the
directory, but wouldn't enter it. I added a check inside my CallBack
function:
if file[-1:] == ' ' and os.path.isdir(file):
os.path.walk(file,CallBack,None)
and the script now traverses into the directory.
----------
messages: 86418
nosy: linuxelf
severity: normal
status: open
title: os.path.walk fails to descend into a directory whose name ends with a space
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5832>
_______________________________________
From report at bugs.python.org Fri Apr 24 22:46:33 2009
From: report at bugs.python.org (J. Evans)
Date: Fri, 24 Apr 2009 20:46:33 +0000
Subject: [New-bugs-announce] [issue5833] readline update
In-Reply-To: <1240605993.87.0.323265568101.issue5833@psf.upfronthosting.co.za>
Message-ID: <1240605993.87.0.323265568101.issue5833@psf.upfronthosting.co.za>
New submission from J. Evans <jrevans1 at earthlink.net>:
Attached is a patch file that will update the readline functionality of
python in the following ways:
-- makes the tab-expand module be compatible with readline v6.x (fixes
the annoying extra-space bug)
-- removes '~$-/' from the completer chars list to make the next item work
-- adds filename completion to the completer, this is useful whenever a
filename/path is used
-- allows expansion to work properly on ClassType objects
----------
components: Extension Modules
files: Python.patch
keywords: patch
messages: 86432
nosy: jrevans1
severity: normal
status: open
title: readline update
versions: Python 2.6
Added file: http://bugs.python.org/file13760/Python.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5833>
_______________________________________
From report at bugs.python.org Sat Apr 25 06:49:09 2009
From: report at bugs.python.org (Kurt McKee)
Date: Sat, 25 Apr 2009 04:49:09 +0000
Subject: [New-bugs-announce] [issue5834] The word "error" used instead of
"failure"
In-Reply-To: <1240634948.79.0.121409956692.issue5834@psf.upfronthosting.co.za>
Message-ID: <1240634948.79.0.121409956692.issue5834@psf.upfronthosting.co.za>
New submission from Kurt McKee <contactme at kurtmckee.org>:
In the unittest documentation a distinction is made between the word
"error" and "failure". However, the description for the
TestCase.assertTrue() function reads:
"Signal a test failure if expr is false; the explanation for the error..."
The word "error" should instead read "failure" in order to maintain
consistency with the words' uses throughout the rest of the documentation.
----------
assignee: georg.brandl
components: Documentation
messages: 86444
nosy: georg.brandl, kurtmckee
severity: normal
status: open
title: The word "error" used instead of "failure"
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5834>
_______________________________________
From report at bugs.python.org Sat Apr 25 09:44:55 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 25 Apr 2009 07:44:55 +0000
Subject: [New-bugs-announce] [issue5835] Deprecate PyOS_ascii_formatd
In-Reply-To: <1240645495.72.0.214739361632.issue5835@psf.upfronthosting.co.za>
Message-ID: <1240645495.72.0.214739361632.issue5835@psf.upfronthosting.co.za>
New submission from Eric Smith <eric at trueblade.com>:
PyOS_ascii_formatd is no longer needed, now that we have
PyOS_double_to_string. PyOS_ascii_formatd has a horrible interface,
requiring a format string to be composed and then parsed. The format
string is a very limited printf-like format string.
In 2.7 and 3.1 I'm going to deprecate this function. As a temporary
measure I'm going to create a similar function _PyOS_ascii_formatd (with
a leading underscore) that does not raise a DeprecationWarning and that
takes discrete parameters.
In 2.8 (if it exists) and 3.2 I'll remove PyOS_ascii_formatd.
----------
assignee: eric.smith
components: Interpreter Core
messages: 86446
nosy: eric.smith, marketdickinson
priority: release blocker
severity: normal
status: open
title: Deprecate PyOS_ascii_formatd
type: behavior
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5835>
_______________________________________
From report at bugs.python.org Sat Apr 25 13:02:27 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 25 Apr 2009 11:02:27 +0000
Subject: [New-bugs-announce] [issue5836] Clean up float parsing code for
nans and infs
In-Reply-To: <1240657347.19.0.452411210539.issue5836@psf.upfronthosting.co.za>
Message-ID: <1240657347.19.0.452411210539.issue5836@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
The special-case code that parses infs and nans should be moved from
Objects/floatobject.c to Python/pystrtod.c, so that it's available
for other places that want to parse nans and infs.
The fallback version of PyOS_ascii_strtod needs to recognize nans and
infinities in a platform-independent manner.
----------
assignee: marketdickinson
components: Interpreter Core
messages: 86464
nosy: eric.smith, marketdickinson
priority: normal
severity: normal
status: open
title: Clean up float parsing code for nans and infs
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5836>
_______________________________________
From =?utf-8?q?Walter_D=C3=B6rwald_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za Sat Apr 25 13:07:12 2009
From: =?utf-8?q?Walter_D=C3=B6rwald_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za (=?utf-8?q?Walter_D=C3=B6rwald_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za)
Date: Sat, 25 Apr 2009 11:07:12 +0000
Subject: [New-bugs-announce] [issue5837] support.EnvironmentVarGuard broken
In-Reply-To: <1240657632.78.0.864909019945.issue5837@psf.upfronthosting.co.za>
Message-ID: <1240657632.78.0.864909019945.issue5837@psf.upfronthosting.co.za>
New submission from Walter D?rwald <walter at livinglogic.de>:
support.EnvironmentVarGuard seems to be broken:
import os
from test import support
print(os.environ.get("HOME"))
with support.EnvironmentVarGuard() as env:
env.unset("HOME")
env.set("HOME", "foo")
print(os.environ.get("HOME"))
The output I get is:
/Users/walter
None
However I would have expected:
/Users/walter
/Users/walter
One solution would be to simply copy the exiting environment dictionary
in __enter__(), which would have the added advantage that code in the
with block could manipulate os.environ directly without going through
the EnvironmentGuardVariable.
----------
components: Tests
keywords: easy
messages: 86465
nosy: doerwalter
priority: low
severity: normal
stage: needs patch
status: open
title: support.EnvironmentVarGuard broken
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5837>
_______________________________________
From report at bugs.python.org Sat Apr 25 13:35:19 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 25 Apr 2009 11:35:19 +0000
Subject: [New-bugs-announce] [issue5838] Test issue
In-Reply-To: <1240659319.87.0.233285656335.issue5838@psf.upfronthosting.co.za>
Message-ID: <1240659319.87.0.233285656335.issue5838@psf.upfronthosting.co.za>
New submission from Daniel Diniz <ajaksu at gmail.com>:
Seems like submitting is broken?
----------
messages: 86472
nosy: ajaksu2
severity: normal
status: open
title: Test issue
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5838>
_______________________________________
From report at bugs.python.org Sat Apr 25 14:50:38 2009
From: report at bugs.python.org (Makursi)
Date: Sat, 25 Apr 2009 12:50:38 +0000
Subject: [New-bugs-announce] [issue5839] RegOpenKeyEx key failed on Vista
64Bit with return 2
In-Reply-To: <1240663838.43.0.625551571341.issue5839@psf.upfronthosting.co.za>
Message-ID: <1240663838.43.0.625551571341.issue5839@psf.upfronthosting.co.za>
New submission from Makursi <mak at aitag.com>:
I have installed 2.6.2 source(32bit) on Vista 64 bit.
The function RegOpenKeyEx fails with returns "2".
If I change the function to
rc=RegOpenKeyEx(keyBase,
keyBuf, /* subkey */
0, /* reserved */
KEY_READ | KEY_WOW64_64KEY,
&newKey);
it works fine. I have checked this in the debug build with my 32 bit
C++ application. UAC is not enabled on my machine.
I hope the issue is fixed with the next version of python.
Regards
Manfred
----------
messages: 86497
nosy: makursi
severity: normal
status: open
title: RegOpenKeyEx key failed on Vista 64Bit with return 2
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5839>
_______________________________________
From report at bugs.python.org Sat Apr 25 14:58:38 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 25 Apr 2009 12:58:38 +0000
Subject: [New-bugs-announce] [issue5840] "Thread State and the Global
Interpreter Lock" section of the docs doesn't cover TLS APIs
In-Reply-To: <1240664318.91.0.855784600353.issue5840@psf.upfronthosting.co.za>
Message-ID: <1240664318.91.0.855784600353.issue5840@psf.upfronthosting.co.za>
New submission from Jean-Paul Calderone <exarkun at divmod.com>:
Python includes several APIs for manipulating TLS:
PyAPI_FUNC(int) PyThread_create_key(void);
PyAPI_FUNC(void) PyThread_delete_key(int);
PyAPI_FUNC(int) PyThread_set_key_value(int, void *);
PyAPI_FUNC(void *) PyThread_get_key_value(int);
PyAPI_FUNC(void) PyThread_delete_key_value(int key);
These are not covered in the threading documentation, though. In fact,
the threading documentation goes so far as to claim that they /don't/ exist:
While most thread packages have a way to store ?per-thread global
data,? Python?s internal platform independent thread abstraction doesn?t
support this yet.
It would be great to have these APIs covered in the documentation. One
subtlety in particular tripped me up and took a long time to track down
by reading various parts of the CPython source - when a thread exits,
its TLS values are not destroyed or reclaimed in any way. On top of
this, the keys used by the TLS APIs are thread IDs, and thread IDs can
be re-used. This means that a newer thread can see values from an older
thread in TLS, which was extremely surprising to me, led to a very
obscure threading bug.
----------
assignee: georg.brandl
components: Documentation
messages: 86501
nosy: exarkun, georg.brandl
severity: normal
status: open
title: "Thread State and the Global Interpreter Lock" section of the docs doesn't cover TLS APIs
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5840>
_______________________________________
From report at bugs.python.org Sat Apr 25 15:59:47 2009
From: report at bugs.python.org (DSM)
Date: Sat, 25 Apr 2009 13:59:47 +0000
Subject: [New-bugs-announce] [issue5841] add py3k warnings to commands
In-Reply-To: <1240667987.1.0.449932138583.issue5841@psf.upfronthosting.co.za>
Message-ID: <1240667987.1.0.449932138583.issue5841@psf.upfronthosting.co.za>
New submission from DSM <dsm001 at users.sourceforge.net>:
The commands module is absent in 3.0 but isn't py3k-warned in trunk.
getstatus was deprecated and mkarg/mk2arg were py3k deprecated, but not
the module or getoutput and getstatusoutput, which now live in
subprocess in 3.x.
This patch adds a module-level py3k warning with subprocess
recommendation, removes the function-level py3k warnings, and adds
deprecation tag to commands.rst.
Made this a new issue rather than adding to 2775 (the PEP3108
implementation issue) because its nosy list is pretty long and this is
pretty minor..
----------
components: Library (Lib)
files: commands_py3k_warn.patch
keywords: patch
messages: 86508
nosy: dsm001
severity: normal
status: open
title: add py3k warnings to commands
versions: Python 2.7
Added file: http://bugs.python.org/file13769/commands_py3k_warn.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5841>
_______________________________________
From =?utf-8?q?=C3=89ric_Araujo_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za Sat Apr 25 21:01:14 2009
From: =?utf-8?q?=C3=89ric_Araujo_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za (=?utf-8?q?=C3=89ric_Araujo_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za)
Date: Sat, 25 Apr 2009 19:01:14 +0000
Subject: [New-bugs-announce] [issue5842] Move test outside of urlparse module
In-Reply-To: <1240686074.24.0.993637087915.issue5842@psf.upfronthosting.co.za>
Message-ID: <1240686074.24.0.993637087915.issue5842@psf.upfronthosting.co.za>
New submission from ?ric Araujo <merwok at netwok.org>:
urlparse contains a small self-test. I think it should be integrated
into test_urlparse or removed, for easier maintenance.
----------
components: Library (Lib), Tests
messages: 86537
nosy: Merwok
severity: normal
status: open
title: Move test outside of urlparse module
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5842>
_______________________________________
From =?utf-8?q?=C3=89ric_Araujo_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za Sat Apr 25 21:12:39 2009
From: =?utf-8?q?=C3=89ric_Araujo_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za (=?utf-8?q?=C3=89ric_Araujo_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za)
Date: Sat, 25 Apr 2009 19:12:39 +0000
Subject: [New-bugs-announce] [issue5843] Possible normalization error in
urlparse.urlunparse
In-Reply-To: <1240686759.57.0.0410680082249.issue5843@psf.upfronthosting.co.za>
Message-ID: <1240686759.57.0.0410680082249.issue5843@psf.upfronthosting.co.za>
New submission from ?ric Araujo <merwok at netwok.org>:
Docstring for urlunparse says:
"""Put a parsed URI back together again. This may result in a
slightly different, but equivalent URI, if the URI that was parsed
originally had redundant delimiters, e.g. a ? with an empty query
(the draft states that these are equivalent)."""
?Draft? here refers to RFC?1808, superseded by 3986. However, RFC?3986
(section 6.2.3) states:
?Normalization should not remove delimiters when their associated
component is empty unless licensed to do so by the scheme
specification. For example, the URI "http://example.com/?" cannot be
assumed to be equivalent to any of the examples above. Likewise, the
presence or absence of delimiters within a userinfo subcomponent is
usually significant to its interpretation. The fragment component is
not subject to any scheme-based normalization; thus, two URIs that
differ only by the suffix "#" are considered different regardless of
the scheme.?
I guess we need some tests here to check compliance.
----------
messages: 86538
nosy: Merwok
severity: normal
status: open
title: Possible normalization error in urlparse.urlunparse
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5843>
_______________________________________
From report at bugs.python.org Sun Apr 26 00:45:25 2009
From: report at bugs.python.org (DSM)
Date: Sat, 25 Apr 2009 22:45:25 +0000
Subject: [New-bugs-announce] [issue5844] internal error on write while
reading
In-Reply-To: <1240699525.42.0.125859784134.issue5844@psf.upfronthosting.co.za>
Message-ID: <1240699525.42.0.125859784134.issue5844@psf.upfronthosting.co.za>
New submission from DSM <dsm001 at users.sourceforge.net>:
Inspired by http://bugs.python.org/issue1653416 , I tried writing to a
file opened for reading in 3.1 trunk, and found:
Python 3.1a2+ (py3k:71900M, Apr 25 2009, 16:12:31)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> fp = open('/etc/passwd')
>>> fp.write('test')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
SystemError: null argument to internal routine
>>> print('test',file=fp)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
SystemError: null argument to internal routine
but binary mode gives:
>>> fp = open('/etc/passwd','rb')
>>> fp.write(b'test')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
io.UnsupportedOperation: write
>>> print(b'test',file=fp)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
io.UnsupportedOperation: write
----------
components: Interpreter Core
messages: 86562
nosy: dsm001
severity: normal
status: open
title: internal error on write while reading
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5844>
_______________________________________
From report at bugs.python.org Sun Apr 26 01:27:19 2009
From: report at bugs.python.org (Cherniavsky Beni)
Date: Sat, 25 Apr 2009 23:27:19 +0000
Subject: [New-bugs-announce] [issue5845] rlcompleter should be enabled
automatically
In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za>
Message-ID: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za>
New submission from Cherniavsky Beni <cben at users.sf.net>:
An interactive prompt should offer working completion out-of-the-box,
without requiring every Python user on earth to create a $PYTHONSTARTUP
with '''import readline; readline.parse_and_bind("tab: complete")'''.
Note that it should work not only when Python is run without arguments,
but also when running with the -i option.
And ideally, it should only install the completion function when
dropping to the interpreter, not from the start, so that code that runs
before dropping to the interpreter is not affected. But this is really
not important.
Safety: if 'rlcompleter' or 'readline' are not availiable (e.g. broken
python install), the user must still get a working interpreter, just
without completion.
Portability: there won't be completion on windows (as long as pyreadline
or similar is not part of Python). But that shouldn't delay unix support!
----------
messages: 86570
nosy: cben
severity: normal
status: open
title: rlcompleter should be enabled automatically
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5845>
_______________________________________
From report at bugs.python.org Sun Apr 26 01:45:00 2009
From: report at bugs.python.org (Michael Foord)
Date: Sat, 25 Apr 2009 23:45:00 +0000
Subject: [New-bugs-announce] [issue5846] Deprecate obsolete functions in
unittest
In-Reply-To: <1240703100.05.0.329458142097.issue5846@psf.upfronthosting.co.za>
Message-ID: <1240703100.05.0.329458142097.issue5846@psf.upfronthosting.co.za>
New submission from Michael Foord <michael at voidspace.org.uk>:
_makeLoader, getTestCaseNames, makeSuite and findTestCases have all had
the comment "these functions should be considered obsolete" for a long time.
Is is ok to go straight to deprecation or should they be marked with
PendingDeprecationWarning first?
----------
assignee: michael.foord
components: Library (Lib)
messages: 86574
nosy: michael.foord
severity: normal
status: open
title: Deprecate obsolete functions in unittest
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5846>
_______________________________________
From report at bugs.python.org Sun Apr 26 05:08:25 2009
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Sun, 26 Apr 2009 03:08:25 +0000
Subject: [New-bugs-announce] [issue5847] IDLE/Win Installer: drop -n switch
for 2.7/3.1; install 3.1 as idle3
In-Reply-To: <1240715305.76.0.471826786959.issue5847@psf.upfronthosting.co.za>
Message-ID: <1240715305.76.0.471826786959.issue5847@psf.upfronthosting.co.za>
New submission from Kurt B. Kaiser <kbk at shore.net>:
1. On 2.7/3.1 multiple copies of IDLE can be
run
simultaneously, so the -n switch used in the
Windows Start menu shortcut with "Edit with
IDLE" should be eliminated.
2. On 3.1, the idle script has been renamed
idle3.
This may interact with the Win installer
shortcut
configuration.
These changes shouldn't be backported to 26-maint
or 30-maint.
I'd offer a patch, but, though I see suspects,
I'm not sure exactly where this lives.
----------
assignee: loewis
components: IDLE, Windows
messages: 86596
nosy: benjamin.peterson, gpolo, kbk, loewis, taleinat, weeble
priority: release blocker
severity: normal
status: open
title: IDLE/Win Installer: drop -n switch for 2.7/3.1; install 3.1 as idle3
type: behavior
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5847>
_______________________________________
From report at bugs.python.org Sun Apr 26 23:21:35 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 26 Apr 2009 21:21:35 +0000
Subject: [New-bugs-announce] [issue5848] Minor unittest doc patch
In-Reply-To: <1240780895.83.0.749653079855.issue5848@psf.upfronthosting.co.za>
Message-ID: <1240780895.83.0.749653079855.issue5848@psf.upfronthosting.co.za>
New submission from Michael Foord <michael at voidspace.org.uk>:
Removes some blank lines from unittest.rst that were suppressing some
version changed messages from appearing in output.
Also added documentation for TestSuite.__iter__ and
TextTestRunner._makeResult as they are unittest extensibility points.
I see _makeResult as 'protected' rather than 'private'. Subclasses
override this method to use a custom test result.
----------
assignee: michael.foord
components: Documentation, Library (Lib)
files: unittest-doc.patch
keywords: easy, needs review, patch, patch
messages: 86608
nosy: michael.foord
severity: normal
status: open
title: Minor unittest doc patch
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file13792/unittest-doc.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5848>
_______________________________________
From report at bugs.python.org Sun Apr 26 23:52:18 2009
From: report at bugs.python.org (R.D. floyd)
Date: Sun, 26 Apr 2009 21:52:18 +0000
Subject: [New-bugs-announce] [issue5849] Idle 3.01 - invalid syntec error
In-Reply-To: <1240782738.97.0.216163234524.issue5849@psf.upfronthosting.co.za>
Message-ID: <1240782738.97.0.216163234524.issue5849@psf.upfronthosting.co.za>
New submission from R.D. floyd <r2d2floyd at mac.com>:
Recently upgraded to OS 10.5, Experienced Fortran, Basic, et. al.
programmer learning Python. IDLE 3.01 give invalid syntec error when
running program below. IDLE from MacPython 2.xx runs it ok!
----------
components: IDLE
files: odbchelper.py
messages: 86609
nosy: r2d2floyd
severity: normal
status: open
title: Idle 3.01 - invalid syntec error
type: compile error
versions: Python 3.0
Added file: http://bugs.python.org/file13793/odbchelper.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5849>
_______________________________________
From report at bugs.python.org Mon Apr 27 03:20:38 2009
From: report at bugs.python.org (Garrett Cooper)
Date: Mon, 27 Apr 2009 01:20:38 +0000
Subject: [New-bugs-announce] [issue5850] Full example for emulating a
container type
In-Reply-To: <1240795238.51.0.123083578346.issue5850@psf.upfronthosting.co.za>
Message-ID: <1240795238.51.0.123083578346.issue5850@psf.upfronthosting.co.za>
New submission from Garrett Cooper <yanegomi at gmail.com>:
This is just an example that I want to offer to the community to help
improve overall documentation in the handbook.
I've attached the example file, but it's also available on my journal
post with example output: http://yaneurabeya.livejournal.com/3437.html
----------
assignee: georg.brandl
components: Documentation
files: somecontainerclass.py
messages: 86637
nosy: georg.brandl, yaneurabeya
severity: normal
status: open
title: Full example for emulating a container type
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file13794/somecontainerclass.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5850>
_______________________________________
From report at bugs.python.org Mon Apr 27 08:24:03 2009
From: report at bugs.python.org (Nicolas Dumazet)
Date: Mon, 27 Apr 2009 06:24:03 +0000
Subject: [New-bugs-announce] [issue5851] Add a stream parameter to
gc.set_debug
In-Reply-To: <1240813443.12.0.48308121403.issue5851@psf.upfronthosting.co.za>
Message-ID: <1240813443.12.0.48308121403.issue5851@psf.upfronthosting.co.za>
New submission from Nicolas Dumazet <nicdumz at gmail.com>:
Hello!
gc.set_debug is provided to help debugging a leaking program. That tool
can be very useful indeed.
Debugging information, however, is written to sys.stderr, and there are
cases where this behavior can be a problem: chances are that stderr can
be already used to output other information.
Currently, to debug a verbose program writing to stderr, one has to
either first reduce/suppress the stderr output noise from its program
before activating set_debug, OR has to redirect the whole mixed stderr
output, and filter it afterwards.
I'd like very much the possibility to configure myself where the gc
debugger will write its output.
My suggestion would be to have set_debug converted from set_debug(flags)
to set_debug(flags, stream=sys.stderr), stream being any valid file
object, but any solution allowing me to customize the output target of
the gc debugger would be welcome.
Thanks!
----------
components: Extension Modules
messages: 86647
nosy: nicdumz
severity: normal
status: open
title: Add a stream parameter to gc.set_debug
type: feature request
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5851>
_______________________________________
From report at bugs.python.org Mon Apr 27 09:55:13 2009
From: report at bugs.python.org (winterTTr)
Date: Mon, 27 Apr 2009 07:55:13 +0000
Subject: [New-bugs-announce] [issue5852] can't use "glog" to find the path
with square bracket
In-Reply-To: <1240818913.82.0.493883494313.issue5852@psf.upfronthosting.co.za>
Message-ID: <1240818913.82.0.493883494313.issue5852@psf.upfronthosting.co.za>
New submission from winterTTr <winterTTr at gmail.com>:
I want to list the file with glob .
The path( which is a directory ) is contain square bracket as "[ab]xxx"
. However , i can't find how to do it rightly with glob .
with the coding :
{{{
import glob
glob.glob('[ab]xxx' )
}}}
and with the path "[ab]xxx" really exits.
result : []
Is there a way to do it rightly ?
Or it is a bug ?
----------
components: Library (Lib), Regular Expressions, Windows
messages: 86648
nosy: winterTTr
severity: normal
status: open
title: can't use "glog" to find the path with square bracket
type: resource usage
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5852>
_______________________________________
From report at bugs.python.org Mon Apr 27 10:57:07 2009
From: report at bugs.python.org (djc)
Date: Mon, 27 Apr 2009 08:57:07 +0000
Subject: [New-bugs-announce] [issue5853] mimetypes.guess_type() hits
recursion limit
In-Reply-To: <1240822627.31.0.362059681673.issue5853@psf.upfronthosting.co.za>
Message-ID: <1240822627.31.0.362059681673.issue5853@psf.upfronthosting.co.za>
New submission from djc <dirkjan at ochtman.nl>:
I've got hgweb (the Mercurial web app) crashing on guess_type() in
2.6.2, but not in 2.5.4. I'm passing in a filename like
'/home/djc/src/hg/crew/templates/static/hglogo.png'. Doesn't happen on
the REPL, but happens in side the hg serve web server.
Traceback (most recent call last):
File "/home/djc/src/hg/crew/mercurial/hgweb/server.py", line 67, in
do_POST
self.do_write()
File "/home/djc/src/hg/crew/mercurial/hgweb/server.py", line 60, in
do_write
self.do_hgweb()
File "/home/djc/src/hg/crew/mercurial/hgweb/server.py", line 124, in
do_hgweb
for chunk in self.server.application(env, self._start_response):
File "/home/djc/src/hg/crew/mercurial/hgweb/hgwebdir_mod.py", line 91,
in __call__
return self.run_wsgi(req)
File "/home/djc/src/hg/crew/mercurial/hgweb/hgwebdir_mod.py", line
132, in run_wsgi
return (staticfile(static, fname, req),)
File "/home/djc/src/hg/crew/mercurial/hgweb/common.py", line 73, in
staticfile
ct = mimetypes.guess_type(path)[0] or "text/plain"
File "/usr/lib/python2.6/mimetypes.py", line 244, in guess_type
return guess_type(url, strict)
(... snip ...)
File "/usr/lib/python2.6/mimetypes.py", line 244, in guess_type
return guess_type(url, strict)
RuntimeError: maximum recursion depth exceeded
----------
components: Library (Lib)
messages: 86649
nosy: djc, georg.brandl
severity: normal
status: open
title: mimetypes.guess_type() hits recursion limit
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5853>
_______________________________________
From report at bugs.python.org Mon Apr 27 12:49:18 2009
From: report at bugs.python.org (Floris Bruynooghe)
Date: Mon, 27 Apr 2009 10:49:18 +0000
Subject: [New-bugs-announce] [issue5854] logging module's __all__ attribute
not in sync with documentation
In-Reply-To: <1240829358.99.0.408012338245.issue5854@psf.upfronthosting.co.za>
Message-ID: <1240829358.99.0.408012338245.issue5854@psf.upfronthosting.co.za>
New submission from Floris Bruynooghe <floris.bruynooghe at gmail.com>:
The logging module in Python 2.6 has started to use the __all__ method.
However it does not list all the symbols that are described in the
documentation. Most notably the getLogger function is not in the
__all__ list, but there are others like addLevelName, getLoggerClass,
setLoggerClass, ...
This does break code that does "from logging import *" which suddenly
can't use getLogger etc anymore.
----------
components: Library (Lib)
messages: 86653
nosy: flub
severity: normal
status: open
title: logging module's __all__ attribute not in sync with documentation
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5854>
_______________________________________
From report at bugs.python.org Mon Apr 27 14:10:47 2009
From: report at bugs.python.org (sjohn)
Date: Mon, 27 Apr 2009 12:10:47 +0000
Subject: [New-bugs-announce] [issue5855] Perhaps exponential performance of
sum(listoflists, [])
In-Reply-To: <1240834247.59.0.00160840317188.issue5855@psf.upfronthosting.co.za>
Message-ID: <1240834247.59.0.00160840317188.issue5855@psf.upfronthosting.co.za>
New submission from sjohn <sebastianjohn at gmx.net>:
To flatten lists of lists, e.g. [[0], [1], [2], ...], I found the short
and quite python-like one-liner "sum(listoflists, [])". This, however,
has absolutely awful performance: while the equivalent way of iterating
by hand and extending a flat list is longer and uglier, it performs fast
and in linear time. The sum() variant takes unacceptably long. I do not
know why this should behave worse-than-linear...
----------
components: Interpreter Core
files: testsumflat.py
messages: 86658
nosy: sjohn
severity: normal
status: open
title: Perhaps exponential performance of sum(listoflists, [])
type: performance
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file13795/testsumflat.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5855>
_______________________________________
From report at bugs.python.org Mon Apr 27 15:10:24 2009
From: report at bugs.python.org (Niels de Vos)
Date: Mon, 27 Apr 2009 13:10:24 +0000
Subject: [New-bugs-announce] [issue5856] Minor typo in traceback example
In-Reply-To: <1240837824.79.0.829030678078.issue5856@psf.upfronthosting.co.za>
Message-ID: <1240837824.79.0.829030678078.issue5856@psf.upfronthosting.co.za>
New submission from Niels de Vos <niels.devos at wincor-nixdorf.com>:
The last example of traceback (found on
<http://docs.python.org/library/traceback.html> release 2.6.2) contains
a typo.
>>> theError = IndexError('tuple indx out of range')
>>> traceback.format_exception_only(type(theError), theError)
['IndexError: tuple index out of range\n']
IndexError('tuple indx out of range') should be IndexError('tuple index
out of range').
----------
assignee: georg.brandl
components: Documentation
messages: 86662
nosy: georg.brandl, nielsdevos
severity: normal
status: open
title: Minor typo in traceback example
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5856>
_______________________________________
From report at bugs.python.org Mon Apr 27 22:26:56 2009
From: report at bugs.python.org (Vaibhav Mallya)
Date: Mon, 27 Apr 2009 20:26:56 +0000
Subject: [New-bugs-announce] [issue5857] Return namedtuples from tokenize
token generator
In-Reply-To: <1240864016.41.0.600109014145.issue5857@psf.upfronthosting.co.za>
Message-ID: <1240864016.41.0.600109014145.issue5857@psf.upfronthosting.co.za>
New submission from Vaibhav Mallya <mallyvai at umich.edu>:
Returning an anonymous 5-tuple seems like a suboptimal interface since
it's so easy to accidentally confuse, for example, the indices of start
and end. I've used tokenize.py for several scripts in the past few weeks
and I've always ended up writing some sort of wrapper function for
generate_tokens that names the returned tuple's fields to help me avoid
mistakes like this.
I'd like to propose the following patch that simply decorates the
generate_token function and names its return values' fields. Since it's
a namedtuple, it should be fully backwards compatible with the existing
interface, but also allow member access via
next_token.type
next_token.string
next_token.start.row, next_token.start.col
next_token.end.row, next_token.end.col
next_token.line
If this seems like a reasonable way to do things, I'd be happy to submit
relevant doc patches as well as the corresponding patch for 3.0.
----------
components: Library (Lib)
files: mallyvai_tokenize.patch
keywords: patch
messages: 86691
nosy: mallyvai
severity: normal
status: open
title: Return namedtuples from tokenize token generator
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13797/mallyvai_tokenize.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5857>
_______________________________________
From report at bugs.python.org Mon Apr 27 22:45:08 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 27 Apr 2009 20:45:08 +0000
Subject: [New-bugs-announce] [issue5858] Make complex repr and str more like
float repr and str
In-Reply-To: <1240865108.11.0.174510817411.issue5858@psf.upfronthosting.co.za>
Message-ID: <1240865108.11.0.174510817411.issue5858@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
In all current versions of Python, the str or repr of a float always
includes *either* an exponent, or a decimal point and at least one digit
after the decimal point.
I propose making the str or repr of a complex number behave in the same
way. That is, instead of
>>> 2+4j
(2+4j)
we'd have:
>>> 2+4j
(2.0+4.0j)
The aims are to make complex representation more consistent with float
representation, retain the visual reminder that the pieces of a complex
number are floats (to me, 2+4j looks like a Gaussian integer rather than
a complex number), simplify the implementation a little, and remove the
ugliness where floats switch from normal to exponential notation at
1e11, but complex numbers switch at 1e12.
See
http://mail.python.org/pipermail/python-dev/2009-April/089030.html
for some additional discussion.
----------
assignee: marketdickinson
components: Interpreter Core
messages: 86692
nosy: eric.smith, marketdickinson
priority: high
severity: normal
stage: needs patch
status: open
title: Make complex repr and str more like float repr and str
type: feature request
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5858>
_______________________________________
From report at bugs.python.org Mon Apr 27 22:50:04 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 27 Apr 2009 20:50:04 +0000
Subject: [New-bugs-announce] [issue5859] Remove implicit '%f' -> '%g' switch
from float formatting.
In-Reply-To: <1240865404.22.0.619023104879.issue5859@psf.upfronthosting.co.za>
Message-ID: <1240865404.22.0.619023104879.issue5859@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
Currently, Python switches from %f to %g formatting at 1e50. This
applies both to the old-style percent formatting, and to the newer PEP
3101-style formatting:
>>> '%f' % 2.**166
'93536104789177786765035829293842113257979682750464.000000'
>>> '%f' % 2.**167
'1.87072e+50'
>>> format(2.**166, 'f')
'93536104789177786765035829293842113257979682750464.000000'
>>> format(2.**167, 'f')
'1.87072e+50'
The main reason for the switch seems to have been implementation
convenience: it makes it possible to use a fixed-size buffer in
the float formatting routines.
I propose removing this feature for Python 3.1, but leaving it in place
for 2.7.
See
http://mail.python.org/pipermail/python-dev/2009-April/089030.html
for additional discussion.
----------
assignee: marketdickinson
components: Interpreter Core
messages: 86693
nosy: eric.smith, marketdickinson
priority: high
severity: normal
stage: needs patch
status: open
title: Remove implicit '%f' -> '%g' switch from float formatting.
type: feature request
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5859>
_______________________________________
From report at bugs.python.org Mon Apr 27 23:36:56 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 27 Apr 2009 21:36:56 +0000
Subject: [New-bugs-announce] [issue5860] TextIOWrapper: bad error reporting
when write() is forbidden
In-Reply-To: <1240868216.12.0.495676026515.issue5860@psf.upfronthosting.co.za>
Message-ID: <1240868216.12.0.495676026515.issue5860@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
Opening an existing file in read-only text mode and trying to write to it:
>>> f = open("LICENSE")
>>> f.write("")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
SystemError: null argument to internal routine
Binary files get it right though:
>>> f = open("LICENSE", "rb")
>>> f.write("")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
io.UnsupportedOperation: write
----------
components: IO
messages: 86700
nosy: pitrou
priority: critical
severity: normal
status: open
title: TextIOWrapper: bad error reporting when write() is forbidden
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5860>
_______________________________________
From report at bugs.python.org Tue Apr 28 03:43:23 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 28 Apr 2009 01:43:23 +0000
Subject: [New-bugs-announce] [issue5861] test_urllib fails on windows
In-Reply-To: <1240883003.46.0.843478025116.issue5861@psf.upfronthosting.co.za>
Message-ID: <1240883003.46.0.843478025116.issue5861@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
Hello. I noticed test_urllib fails on windows.
======================================================================
ERROR: test_copy (__main__.urlretrieve_FileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_urllib.py", line 241, in test_copy
test_support.TESTFN), second_temp)
File "e:\python-dev\trunk\lib\urllib.py", line 94, in urlretrieve
return _urlopener.retrieve(url, filename, reporthook, data)
File "e:\python-dev\trunk\lib\urllib.py", line 238, in retrieve
fp = self.open(url, data)
File "e:\python-dev\trunk\lib\urllib.py", line 206, in open
return getattr(self, name)(url)
File "e:\python-dev\trunk\lib\urllib.py", line 464, in open_file
return self.open_local_file(url)
File "e:\python-dev\trunk\lib\urllib.py", line 478, in open_local_file
raise IOError(e.errno, e.strerror, e.filename)
IOError: [Errno 22] ??????????????????????????
????
?????????Windows ?????????????:
'\\\\\\E|\\python-dev\\tru
nk\\Lib\\test\\@test'
(snip)
This happens since r71780. Workaround is to add "|" to safe list of
fullurl = quote(fullurl, safe="%/:=&?~#+!$,;'@()*[]")
# I don't know "|" is really safe.
----------
components: Library (Lib)
messages: 86713
nosy: ocean-city
severity: normal
status: open
title: test_urllib fails on windows
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5861>
_______________________________________
From report at bugs.python.org Tue Apr 28 03:55:02 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 28 Apr 2009 01:55:02 +0000
Subject: [New-bugs-announce] [issue5862] multiprocessing 'using a remote
manager' example errors and possible 'from_address' code leftover
In-Reply-To: <1240883702.69.0.562256281063.issue5862@psf.upfronthosting.co.za>
Message-ID: <1240883702.69.0.562256281063.issue5862@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
The 'Using a remote manager' section of the multiprocessing docs has an
example of calling the (documented) 'from_address' class method of
BaseManager. However, no such method appears to exist. I don't know if
this is a doc bug or a code bug. The __reduce__ method of BaseManager
calls type(self).from_address, and that and a similar pickle-related
call in sharedctypes are the only places it is mentioned in the module.
It is not mentioned in the test suite.
In any case, the example does not work as written, and there appear to
be multiple errors in the "another client" (the read client) example. I
haven't played with the "local client" example at all.
----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 86715
nosy: georg.brandl, jnoller, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: multiprocessing 'using a remote manager' example errors and possible 'from_address' code leftover
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/issue5862>
_______________________________________
From report at bugs.python.org Tue Apr 28 07:57:49 2009
From: report at bugs.python.org (MizardX)
Date: Tue, 28 Apr 2009 05:57:49 +0000
Subject: [New-bugs-announce] [issue5863] bz2.BZ2File should accept other
file-like objects.
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
New submission from MizardX <mizardx at gmail.com>:
bz2.BZ2File should, like gzip.GzipFile, accept a fileobj argument.
If implemented, you could much more easily pipe BZ2-data from other
sources, such as stdin or a socket.
----------
components: IO, Library (Lib)
messages: 86716
nosy: MizardX
severity: normal
status: open
title: bz2.BZ2File should accept other file-like objects.
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5863>
_______________________________________
From report at bugs.python.org Tue Apr 28 13:38:21 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 28 Apr 2009 11:38:21 +0000
Subject: [New-bugs-announce] [issue5864] format(1234.5,
'.4') gives misleading result
In-Reply-To: <1240918701.29.0.448631018547.issue5864@psf.upfronthosting.co.za>
Message-ID: <1240918701.29.0.448631018547.issue5864@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
In all versions of Python from 2.6 up, I get the following behaviour:
>>> format(123.456, '.4')
'123.5'
>>> format(1234.56, '.4')
'1235.0'
>>> format(12345.6, '.4')
'1.235e+04'
The first and third results are as I expect, but the second is somewhat
misleading: it gives 5 significant digits when only 4 were requested,
and moreover the last digit is incorrect.
I propose that Python 2.7 and Python 3.1 be changed so that the output
for the second line above is '1.235e+03'.
Note that in both Python and C, '%.<precision>g' formatting switches to
exponential notation at 1e<precision> precisely to avoid the problem of
producing more significant digits than were requested; I'm proposing
that the same solution be applied for '' formatting, except that since
the empty format code is always required to produce at least one digit
after the decimal point, the switch should happen at 1e<precision-1>
instead of 1e<precision>.
This change should not be backported to 2.6 or 3.0 since there's a small
risk of breakage (particular in doctests).
----------
components: Interpreter Core
messages: 86728
nosy: eric.smith, marketdickinson
severity: normal
stage: needs patch
status: open
title: format(1234.5, '.4') gives misleading result
type: behavior
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5864>
_______________________________________
From report at bugs.python.org Tue Apr 28 15:01:44 2009
From: report at bugs.python.org (Alan Hourihane)
Date: Tue, 28 Apr 2009 13:01:44 +0000
Subject: [New-bugs-announce] [issue5865] mathmodule.c fails to compile due
to missing math_log1p() function
In-Reply-To: <1240923704.81.0.766001456268.issue5865@psf.upfronthosting.co.za>
Message-ID: <1240923704.81.0.766001456268.issue5865@psf.upfronthosting.co.za>
New submission from Alan Hourihane <alanh at fairlite.co.uk>:
mathmodule.c fails to compile because math_log1p() is missing in
mathmodule.c...
gcc -fno-strict-aliasing -DNDEBUG -O2 -pipe -fomit-frame-pointer -I.
-IInclude -I./Include -DPy_BUILD_CORE -c ./Modules/mathmodule.c -o
Modules/mathmodule.o
./Modules/mathmodule.c: In function 'math_log1p':
./Modules/mathmodule.c:353: error: 'log1p' undeclared (first use in this
function)
./Modules/mathmodule.c:353: error: (Each undeclared identifier is
reported only once
./Modules/mathmodule.c:353: error: for each function it appears in.)
./Modules/mathmodule.c: In function 'math_fsum':
./Modules/mathmodule.c:574: warning: passing argument 1 of 'PyFPE_dummy'
discards qualifiers from pointer target type
----------
components: Extension Modules
messages: 86733
nosy: alanh
severity: normal
status: open
title: mathmodule.c fails to compile due to missing math_log1p() function
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5865>
_______________________________________
From report at bugs.python.org Tue Apr 28 16:06:04 2009
From: report at bugs.python.org (Jelle)
Date: Tue, 28 Apr 2009 14:06:04 +0000
Subject: [New-bugs-announce] [issue5866] cPickle defect with tuples and
different from pickle output
In-Reply-To: <1240927564.03.0.455606352259.issue5866@psf.upfronthosting.co.za>
Message-ID: <1240927564.03.0.455606352259.issue5866@psf.upfronthosting.co.za>
New submission from Jelle <jelleroozenburg at gmail.com>:
Python 2.5.2 (r252:60911, Oct 5 2008, 19:24:49)
[GCC 4.3.2] on linux2
>>> print cPickle.dumps(('a','b')) == cPickle.dumps(('a', str('b')))
False
>>> print pickle.dumps(('a','b')) == pickle.dumps(('a', str('b')))
True
>>> print pickle.dumps(('a','b')) == cPickle.dumps(('a', str('b')))
False
>>> print pickle.dumps(('a','b')) == cPickle.dumps(('a', 'b'))
False
----------
components: Library (Lib)
messages: 86741
nosy: jelle
severity: normal
status: open
title: cPickle defect with tuples and different from pickle output
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5866>
_______________________________________
From report at bugs.python.org Tue Apr 28 16:24:12 2009
From: report at bugs.python.org (Matteo Dell'Amico)
Date: Tue, 28 Apr 2009 14:24:12 +0000
Subject: [New-bugs-announce] [issue5867] No way to create an abstract
classmethod
In-Reply-To: <1240928652.35.0.147355180867.issue5867@psf.upfronthosting.co.za>
Message-ID: <1240928652.35.0.147355180867.issue5867@psf.upfronthosting.co.za>
New submission from Matteo Dell'Amico <della at linux.it>:
Is there a way to define an abstract classmethod? The two obvious ways
don't seem to work properly.
Python 3.0.1+ (r301:69556, Apr 15 2009, 17:25:52)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import abc
>>> class C(metaclass=abc.ABCMeta):
... @abc.abstractmethod
... @classmethod
... def f(cls): print(42)
...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in C
File "/usr/lib/python3.0/abc.py", line 24, in abstractmethod
funcobj.__isabstractmethod__ = True
AttributeError: 'classmethod' object has no attribute '__isabstractmethod__'
>>> class C(metaclass=abc.ABCMeta):
... @classmethod
... @abc.abstractmethod
... def f(cls): print(42)
...
>>> class D(C): pass
...
>>> D.f()
42
----------
components: Library (Lib)
messages: 86744
nosy: della
severity: normal
status: open
title: No way to create an abstract classmethod
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5867>
_______________________________________
From report at bugs.python.org Tue Apr 28 16:51:57 2009
From: report at bugs.python.org (Alain Poirier)
Date: Tue, 28 Apr 2009 14:51:57 +0000
Subject: [New-bugs-announce] [issue5868] mimetypes.MAGIC_FUNCTION
initialization not thread-safe in Python 2.6.2
In-Reply-To: <1240930317.8.0.75459471021.issue5868@psf.upfronthosting.co.za>
Message-ID: <1240930317.8.0.75459471021.issue5868@psf.upfronthosting.co.za>
New submission from Alain Poirier <alain.poirier at net-ng.com>:
In Python 2.6.2, the fix for the issue 5401 changed the way the
mimetypes module is initialized.
But now the initialization is not thread-safe : a thread can set
``inited`` to ``True`` and then be preempted before to overwrite the
functions guess_type(), guess_extension() ...
With such a partial initialization, the next thread will raise an
excessive recursion exception when calling one of this functions.
A fix could be to wrap ``mimetypes.init()`` with a thread lock.
----------
components: Library (Lib)
messages: 86747
nosy: apoirier, benjamin.peterson
severity: normal
status: open
title: mimetypes.MAGIC_FUNCTION initialization not thread-safe in Python 2.6.2
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5868>
_______________________________________
From report at bugs.python.org Tue Apr 28 20:53:40 2009
From: report at bugs.python.org (Neville Bagnall)
Date: Tue, 28 Apr 2009 18:53:40 +0000
Subject: [New-bugs-announce] [issue5869] 100th character truncation in 2.4
tarfile.py
In-Reply-To: <1240944820.11.0.0114272634034.issue5869@psf.upfronthosting.co.za>
Message-ID: <1240944820.11.0.0114272634034.issue5869@psf.upfronthosting.co.za>
New submission from Neville Bagnall <neville.bagnall at propylon.com>:
When tarinfo.name is exactly 100 characters long, the last character is
truncated in the tarfile
Attached patch contains the extremely simple fix.
----------
components: Library (Lib)
files: tarfile.patch
keywords: patch
messages: 86759
nosy: neville.bagnall
severity: normal
status: open
title: 100th character truncation in 2.4 tarfile.py
type: behavior
versions: Python 2.4
Added file: http://bugs.python.org/file13806/tarfile.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5869>
_______________________________________
From report at bugs.python.org Tue Apr 28 21:24:04 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Tue, 28 Apr 2009 19:24:04 +0000
Subject: [New-bugs-announce] [issue5870] subprocess.DEVNULL
In-Reply-To: <1240946644.39.0.609275389725.issue5870@psf.upfronthosting.co.za>
Message-ID: <1240946644.39.0.609275389725.issue5870@psf.upfronthosting.co.za>
New submission from Jean Brouwers <MrJean1 at Gmail.com>:
The subprocess module exposes the PIPE and STDOUT constants to be used
for the stdin, stdout or stderr keyword arguments.
Often, stderr needs to be redirected to /dev/null (on posix). It would
nice if another constant was available for that purpose, e.g.
subprocess.DEVNULL.
Perhaps, that might be as simple as
DEVNULL = os.open(os.devnull, os.OS_RDWR)
and re-use the same, single file descriptor.
----------
components: Extension Modules
messages: 86761
nosy: MrJean1
severity: normal
status: open
title: subprocess.DEVNULL
type: feature request
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5870>
_______________________________________
From report at bugs.python.org Tue Apr 28 23:25:37 2009
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 28 Apr 2009 21:25:37 +0000
Subject: [New-bugs-announce] [issue5871] email.header.Header allow to embed
raw newlines into a message
In-Reply-To: <1240953937.2.0.828159818097.issue5871@psf.upfronthosting.co.za>
Message-ID: <1240953937.2.0.828159818097.issue5871@psf.upfronthosting.co.za>
New submission from Jakub Wilk <ubanus at users.sf.net>:
>>> from email.mime.text import MIMEText
>>> from email.header import Header
>>> msg = MIMEText('dummy')
>>> h = Header('dummy\nX-Injected-Header: yes')
>>> msg['Subject'] = h
>>> print msg.as_string()
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: dummy
X-Injected-Header: yes
dummy
----------
components: Library (Lib)
messages: 86767
nosy: jwilk, pl
severity: normal
status: open
title: email.header.Header allow to embed raw newlines into a message
versions: Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5871>
_______________________________________
From report at bugs.python.org Wed Apr 29 04:59:44 2009
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 29 Apr 2009 02:59:44 +0000
Subject: [New-bugs-announce] [issue5872] New C API for declaring Python types
In-Reply-To: <1240973984.42.0.154845882855.issue5872@psf.upfronthosting.co.za>
Message-ID: <1240973984.42.0.154845882855.issue5872@psf.upfronthosting.co.za>
New submission from Larry Hastings <larry at hastings.org>:
EXECUTIVE SUMMARY
I've written a patch against py3k trunk creating a new function-based
API for creating extension types in C. This allows PyTypeObject to
become a (mostly) private structure.
THE PROBLEM
Here's how you create an extension type using the current API.
* First, find some code that already has a working type declaration.
Copy and paste their fifty-line PyTypeObject declaration, then
hack it up until it looks like what you need.
* Next--hey! There *is* no next, you're done. You can immediately
create an object using your type and pass it into the Python
interpreter and it would work fine. You are encouraged to call
PyType_Ready(), but this isn't required and it's often skipped.
This approach causes two problems.
1) The Python interpreter *must support* and *cannot change*
the PyTypeObject structure, forever. Any meaningful change to
the structure will break every extension. This has many
consequences:
a) Fields that are no longer used must be left in place,
forever, as ignored placeholders if need be. Py3k cleaned
up a lot of these, but it's already picked up a new one
("tp_compare" is now "tp_reserved").
b) Internal implementation details of the type system must
be public.
c) The interpreter can't even use a different structure
internally, because extensions are free to pass in objects
using PyTypeObjects the interpreter has never seen before.
2) As a programming interface this lacks a certain gentility. It
clearly *works*, but it requires programmers to copy and paste
with a large structure mostly containing NULLs, which they must
pick carefully through to change just a few fields.
THE SOLUTION
My patch creates a new function-based extension type definition API.
You create a type by calling PyType_New(), then call various accessor
functions on the type (PyType_SetString and the like), and when your
type has been completely populated you must call PyType_Activate()
to enable it for use.
With this API available, extension authors no longer need to directly
see the innards of the PyTypeObject structure. Well, most of the
fields anyway. There are a few shortcut macros in CPython that need
to continue working for performance reasons, so the "tp_flags" and
"tp_dealloc" fields need to remain publically visible.
One feature worth mentioning is that the API is type-safe. Many such
APIs would have had one generic "PyType_SetPointer", taking an
identifier for the field and a void * for its value, but this would
have lost type safety. Another approach would have been to have one
accessor per field ("PyType_SetAddFunction"), but this would have
exploded the number of functions in the API. My API splits the
difference: each distinct *type* has its own set of accessors
("PyType_GetSSizeT") which takes an identifier specifying which
field you wish to get or set.
SIDE-EFFECTS OF THE API
The major change resulting from this API: all PyTypeObjects must now
be *pointers* rather than static instances. For example, the external
declaration of PyType_Type itself changes from this:
PyAPI_DATA(PyTypeObject) PyType_Type;
to this:
PyAPI_DATA(PyTypeObject *) PyType_Type;
This gives rise to the first headache caused by the API: type casts
on type objects. It took me a day and a half to realize that this,
from Modules/_weakref.c:
PyModule_AddObject(m, "ref",
(PyObject *) &_PyWeakref_RefType);
really needed to be this:
PyModule_AddObject(m, "ref",
(PyObject *) _PyWeakref_RefType);
Hopefully I've already found most of these in CPython itself, but
this sort of code surely lurks in extensions yet to be touched.
(Pro-tip: if you're working with this patch, and you see a crash,
and gdb shows you something like this at the top of the stack:
#0 0x081056d8 in visit_decref (op=0x8247aa0, data=0x0)
at Modules/gcmodule.c:323
323 if (PyObject_IS_GC(op)) {
your problem is an errant &, likely on a type object you're passing
in to the interpreter. Think--what did you touch recently? Or debug
it by salting your code with calls to collect(NUM_GENERATIONS-1).)
Another irksome side-effect of the API: because of "tp_flags" and
"tp_dealloc", I now have two declarations of PyTypeObject. There's
the externally-visible one in Include/object.h, which lets external
parties see "tp_dealloc" and "tp_flags". Then there's the internal
one in Objects/typeprivate.h which is the real structure. Since
declaring a type twice is a no-no, the external one is gated on
#ifndef PY_TYPEPRIVATE
If you're a normal Python extension programmer, you'd include Python.h
as normal:
#include "Python.h"
Python implementation files that need to see the real PyTypeObject
structure now look like this:
#define PY_TYPEPRIVATE
#include "Python.h"
#include "../Objects/typeprivate.h"
Also, since the structure of PyTypeObject hasn't yet changed, there
are a bunch of fields in PyTypeObject that are externally visible that
I don't want to be visible. To ensure no one was using them, I renamed
them to "mysterious_object_0" and "mysterious_object_1" and the like.
Before this patch gets accepted, I want to reorder the fields in
PyTypeObject (which we can! because it's private!) so that these public
fields are at the top of the both the external and internal structures.
THE UPGRADE PATH
Python internally declares a great many types, and I haven't attempted
to convert them all. Instead there's an conversion header file that
does most of the work for you. Here's how one would apply it to an
existing type.
1. Where your file currently has this:
#include "Python.h"
change it to this:
#define PY_TYPEPRIVATE
#include "Python.h"
#include "pytypeconvert.h"
2. Whenever you declare a type, change it from this:
static PyTypeObject YourExtension_Type = {
to this:
static PyTypeObject *YourExtension_Type;
static PyTypeObject _YourExtension_Type = {
Use NULL for your metaclass. For example, change this:
PyObject_HEAD_INIT(&PyType_Type),
to this:
PyObject_HEAD_INIT(NULL),
Also use NULL for your baseclass. For example, change this:
&PyDict_Type, /* tp_base */
to this:
NULL, /* tp_base */
setting it to NULL instead.
3. In your module's init function, add this:
CONVERT_TYPE(YourExtension_Type,
metaclass, baseclass, "description of type");
"metaclass" and "baseclass" should be the metaclass and baseclass
for your type, the ones you just set to NULL in step 3. If you
had NULL before the baseclass, use NULL here too.
4. If you have any static object declarations, set their ob_type to
NULL in the static declaration, then set it explicitly in your
init function. If your object uses a locally-defined type,
be sure to do this *after* the CONVERT_TYPE line for that type.
(See _Py_EllipsisObject for an example.)
5. Anywhere you're using existing Python type declarations
you must remove the & from the front.
The conversion header file *also* redefines PyTypeObject. But this
time it redefines it to the existing definition, and that definition
will stay the same forever. That's the whole point: if you have an
existing Python 3.0 extension, it won't have to change if we change
the internal definition of PyTypeObject.
(Why bother with this conversion process, with few py3k extensions
in the wild? This patch was started quite a while ago, when it
seemed plausible the API would get backported to 2.x. Now I'm not
so sure that will happen.)
THE CURRENT PATCH
The patch below applies cleanly to py3k/trunk (r72081). But the
code is awfully grubby.
* I haven't dealt with any types I can't build, and I can't build
a lot of the extensions. I'm using Linux, and I don't have the
dev headers for many libraries on my laptop, and I haven't touched
Windows or Mac stuff.
* I created some new build warnings which should obviously be fixed.
* With the patch installed, py3k trunk builds and installs. It does
*not* pass the regression test suite. (It crashes.) I don't think
this'll be too bad, it's just taken me this long to get it as far
as I have.
* There are some internal scaffolds and hacks that should be purged
by the final patch.
* There's no documentation. If you'd like to see how you'd use the
new API, currently the best way to learn is to read
Include/pytypeconvert.h.
* I don't like the PY_TYPEPRIVATE hack. I only used it 'cause it
sucks less than the other approaches I've thought of. I welcome
your suggestions.
The second-best approach I've come up with: make PyTypeObject
genuinely private, and declare a different structure containing just
the head of PyTypeObject. Let's call it PyTypeObjectHead. Then,
for the convenience macros that use "dealloc" and "flags", cast the
object to PyTypeObjectHead before dereferencing. This abandons type
safety, and given my longing for type safety while developing this
patch I'd prefer to not make loss of type safety an official API.
My thanks to Neal Norwitz for suggesting this project, and Brett Cannon
for some recent encouragement. (And another person who I discussed it
with so long ago I forgot who it was... maybe Fredik Lundh?)
----------
components: Interpreter Core
files: lch.type.r72081.diff
keywords: patch
messages: 86775
nosy: larry
severity: normal
status: open
title: New C API for declaring Python types
type: feature request
versions: Python 3.1
Added file: http://bugs.python.org/file13809/lch.type.r72081.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5872>
_______________________________________
From report at bugs.python.org Wed Apr 29 06:44:13 2009
From: report at bugs.python.org (Nicolas Frantzen)
Date: Wed, 29 Apr 2009 04:44:13 +0000
Subject: [New-bugs-announce] [issue5873] Minidom: parsestring() error
In-Reply-To: <1240980253.13.0.487290174361.issue5873@psf.upfronthosting.co.za>
Message-ID: <1240980253.13.0.487290174361.issue5873@psf.upfronthosting.co.za>
New submission from Nicolas Frantzen <n.frantzen at gmail.com>:
Hi,
I'm pretty new to the community but I get an error using the minidom
parseString() method. Here is my code (ulta simple!):
import xml.dom.minidom
xml = "<tag>hello</tag>"
doc = xml.dom.minidom.parsString(xml)
And here is my error trace:
Traceback (most recent call last):
File "C:\test.py", line 6, in <module>
doc = xml.dom.minidom.parsString(xml)
AttributeError: 'str' object has no attribute 'dom'
I get this error no what string I gave it. I use python 2.6 (latest
stable release).
Can someone point in the right direction...google has not been very helpful.
Thanks!
Nico
----------
components: XML
messages: 86776
nosy: naf305
severity: normal
status: open
title: Minidom: parsestring() error
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5873>
_______________________________________
From report at bugs.python.org Wed Apr 29 09:38:30 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 29 Apr 2009 07:38:30 +0000
Subject: [New-bugs-announce] [issue5874] distutils.tests.test_config_cmd is
locale-sensitive
In-Reply-To: <1240990710.39.0.833817630745.issue5874@psf.upfronthosting.co.za>
Message-ID: <1240990710.39.0.833817630745.issue5874@psf.upfronthosting.co.za>
New submission from Georg Brandl <georg at python.org>:
If your locale isn't C, the preprocessor may not put "<command-line>" in
its output; test_search_cpp() will then fail.
----------
assignee: tarek
components: Distutils
messages: 86780
nosy: georg.brandl, tarek
severity: normal
status: open
title: distutils.tests.test_config_cmd is locale-sensitive
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5874>
_______________________________________
From report at bugs.python.org Wed Apr 29 09:49:32 2009
From: report at bugs.python.org (M. Shuaib Khan)
Date: Wed, 29 Apr 2009 07:49:32 +0000
Subject: [New-bugs-announce] [issue5875] test_distutils failing on OpenSUSE
10.3, Py3k
In-Reply-To: <1240991372.08.0.469372196929.issue5875@psf.upfronthosting.co.za>
Message-ID: <1240991372.08.0.469372196929.issue5875@psf.upfronthosting.co.za>
New submission from M. Shuaib Khan <aries.shuaib at gmail.com>:
Hi,
Running test_distutils as a non root user fails for me. Running it as a
root user works.
System information:
uname -a
Linux Matrix 2.6.22.5-31-default #1 SMP 2007/09/21 22:29:00 UTC i686
i686 i386 GNU/Linux
./python --version
Python 3.1a2+
======================================================================
ERROR: test_no_optimize_flag
(distutils.tests.test_bdist_rpm.BuildRpmTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/home/shuaib/Tools/GSoC2009/py3k/Lib/distutils/tests/test_bdist_rpm.py",
line 114, in test_no_optimize_flag
cmd.run()
File
"/home/shuaib/Tools/GSoC2009/py3k/Lib/distutils/command/bdist_rpm.py",
line 363, in run
self.spawn(rpm_cmd)
File "/home/shuaib/Tools/GSoC2009/py3k/Lib/distutils/cmd.py", line
368, in spawn
spawn(cmd, search_path, dry_run=self.dry_run)
File "/home/shuaib/Tools/GSoC2009/py3k/Lib/distutils/spawn.py", line
31, in spawn
_spawn_posix(cmd, search_path, dry_run=dry_run)
File "/home/shuaib/Tools/GSoC2009/py3k/Lib/distutils/spawn.py", line
139, in _spawn_posix
% (cmd[0], exit_status))
distutils.errors.DistutilsExecError: command 'rpmbuild' failed with exit
status 1
======================================================================
ERROR: test_quiet (distutils.tests.test_bdist_rpm.BuildRpmTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/home/shuaib/Tools/GSoC2009/py3k/Lib/distutils/tests/test_bdist_rpm.py",
line 74, in test_quiet
cmd.run()
File
"/home/shuaib/Tools/GSoC2009/py3k/Lib/distutils/command/bdist_rpm.py",
line 363, in run
self.spawn(rpm_cmd)
File "/home/shuaib/Tools/GSoC2009/py3k/Lib/distutils/cmd.py", line
368, in spawn
spawn(cmd, search_path, dry_run=self.dry_run)
File "/home/shuaib/Tools/GSoC2009/py3k/Lib/distutils/spawn.py", line
31, in spawn
_spawn_posix(cmd, search_path, dry_run=dry_run)
File "/home/shuaib/Tools/GSoC2009/py3k/Lib/distutils/spawn.py", line
139, in _spawn_posix
% (cmd[0], exit_status))
distutils.errors.DistutilsExecError: command 'rpmbuild' failed with exit
status 1
----------------------------------------------------------------------
----------
assignee: tarek
components: Distutils, Tests
files: output.txt
messages: 86781
nosy: ShuaibKhan, tarek
severity: normal
status: open
title: test_distutils failing on OpenSUSE 10.3, Py3k
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file13810/output.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5875>
_______________________________________
From report at bugs.python.org Wed Apr 29 13:58:33 2009
From: report at bugs.python.org (Tomasz Melcer)
Date: Wed, 29 Apr 2009 11:58:33 +0000
Subject: [New-bugs-announce] [issue5876] __repr__ returning unicode doesn't
work when called implicitly
In-Reply-To: <1241006313.4.0.792016858663.issue5876@psf.upfronthosting.co.za>
Message-ID: <1241006313.4.0.792016858663.issue5876@psf.upfronthosting.co.za>
New submission from Tomasz Melcer <liori at o2.pl>:
Invitation... (Debian Sid, gnome-terminal with pl_PL.UTF8 locales)
Python 2.5.4 (r254:67916, Feb 17 2009, 20:16:45)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Lets create some class...
>>> class T(object):
... def __repr__(self): return u'???'
...
Does its repr() work?
>>> T().__repr__()
u'\u3042\u307f\u3054'
>>> print T().__repr__()
???
But when it is implicitly called, it doesnt?!
>>> T()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode characters in position
0-2: ordinal not in range(128)
>>> print T()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode characters in position
0-2: ordinal not in range(128)
Encoding:
>>> import sys
>>> sys.stdin.encoding
'UTF-8'
>>> sys.stdout.encoding
'UTF-8'
Workaround for now:
>>> class T(object):
... def __repr__(self): return u'???'.encode('utf-8')
...
----------
components: Extension Modules
messages: 86798
nosy: liori
severity: normal
status: open
title: __repr__ returning unicode doesn't work when called implicitly
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5876>
_______________________________________
From =?utf-8?b?TWFydCBTw7VtZXJtYWEgPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za Wed Apr 29 15:32:15 2009
From: =?utf-8?b?TWFydCBTw7VtZXJtYWEgPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za (=?utf-8?b?TWFydCBTw7VtZXJtYWEgPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za)
Date: Wed, 29 Apr 2009 13:32:15 +0000
Subject: [New-bugs-announce] [issue5877] Add a function for updating URL
query parameters
In-Reply-To: <1241011935.05.0.388851858626.issue5877@psf.upfronthosting.co.za>
Message-ID: <1241011935.05.0.388851858626.issue5877@psf.upfronthosting.co.za>
New submission from Mart S?mermaa <mrts at mrts.pri.ee>:
Proposal
--------
Add update_query_params() for updating or adding URL query parameters to
urllib.parse and urlparse.
Discussion
----------
Python-dev:
http://mail.python.org/pipermail/python-dev/2009-April/088675.html
Previously in Python-ideas:
http://mail.python.org/pipermail/python-ideas/2009-March/003728.html
The consensus seems to be that this is needed, opinions on how the API
should look like vary.
Behaviour
---------
The following features were requested by different people:
- ability to order parameters (by passing them in a ordered data structure)
- "plain" behaviour that would keep the existing parameters as is and
add passed in parameters, retaining duplicates
- behaviour that removes duplicated values
- dict.update()-like behaviour that would not allow duplicate keys
(updating values for existing keys)
- removal of existing parameters
Implementation
--------------
http://github.com/mrts/qparams/tree/master
in particular
http://github.com/mrts/qparams/blob/bf1b29ad46f9d848d5609de6de0bfac1200da310/qparams.py
See the docstring in qparams.py for
Currently, positional arguments are used to avoid name collisions in
keyword arguments that were initially devised as the default, easy way
to pass parameters. As the function signature has grown quite complex,
this looks suboptimal.
Also, the general sentiment was that the current three-valued logic for
choosing key update strategy is also suboptimal. Instead, the strategy
should be passed via a function and the strategies listed above should
be provided in the module.
Finally, removing keys is currently missing. It was proposed that
passing foo=None would remove the parameter foo. Currently, None is used
to mark parameters that do not take values, another marker is needed for
that if removal is to be marked with None.
Following on Nick Coghlan's suggestion in
http://mail.python.org/pipermail/python-dev/2009-April/088866.html and
considering the preference for a strategy function, the API could look
as follows:
def add_query_params(url, params, strategy=allow_dulicates, sep='&')
I.e. keyword arguments would not be supported and the "default" use
would be as follows:
>>> add_query_params('foo', dict(bar='baz'))
'foo?bar=baz'
----------
components: Library (Lib)
messages: 86802
nosy: mrts
severity: normal
status: open
title: Add a function for updating URL query parameters
type: feature request
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5877>
_______________________________________
From report at bugs.python.org Wed Apr 29 15:39:36 2009
From: report at bugs.python.org (Emilio)
Date: Wed, 29 Apr 2009 13:39:36 +0000
Subject: [New-bugs-announce] [issue5878] Regular Expression instances
In-Reply-To: <1241012376.36.0.626535664464.issue5878@psf.upfronthosting.co.za>
Message-ID: <1241012376.36.0.626535664464.issue5878@psf.upfronthosting.co.za>
New submission from Emilio <ecasbasj at yahoo.es>:
Following the example from
http://docs.python.org/3.0/howto/regex.html
If I execute the following code on the python shell (3.1a1):
>>> import re
>>> p = re.compile('ab*')
>>> p
I get the msg:
<_sre.SRE_Pattern object at 0x013A3440>
instead of the msg from the example:
<re.RegexObject instance at 80b4150>
Why I get an SRE_Patterns object instead of a RegexObject instance?
Confirmed with another users
http://www.mail-archive.com/tutor at python.org/msg35017.html
Thanks
----------
assignee: georg.brandl
components: Documentation
messages: 86803
nosy: ecasbas, georg.brandl
severity: normal
status: open
title: Regular Expression instances
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5878>
_______________________________________
From report at bugs.python.org Wed Apr 29 17:38:02 2009
From: report at bugs.python.org (Harald Armin Massa)
Date: Wed, 29 Apr 2009 15:38:02 +0000
Subject: [New-bugs-announce] [issue5879] multiprocessing - example "pool of
http servers " fails on windows "socket has no attribute fromfd"
In-Reply-To: <1241019482.48.0.575158847578.issue5879@psf.upfronthosting.co.za>
Message-ID: <1241019482.48.0.575158847578.issue5879@psf.upfronthosting.co.za>
New submission from Harald Armin Massa <chef at ghum.de>:
the example from
http://docs.python.org/library/multiprocessing.html?highlight=multiprocessing#module-multiprocessing
named "
# Example where a pool of http servers share a single listening socket
#
"
does not work on windows.
Reason:
s = socket.fromfd(fd, family, type_, proto)
in line 156 of reduction.py
fails, because fromfd is not available on windows. Sad thing:
reduction.py was put into processing.py exactly to solve that problem
(i.e. reduction.py is provided as workaround for socket.fromfd not
available on windows, from the documentation:
if sys.platform == 'win32':
import multiprocessing.reduction
# make sockets pickable/inheritable
the solution within processing was:
try:
fromfd = socket.fromfd
except AttributeError:
def fromfd(fd, family, type, proto=0):
s = socket._socket.socket()
_processing.changeFd(s, fd, family, type, proto)
return s
but: _multiprocessing has no longer a method changeFd.
Harald
----------
components: Library (Lib)
messages: 86810
nosy: ghum
severity: normal
status: open
title: multiprocessing - example "pool of http servers " fails on windows "socket has no attribute fromfd"
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5879>
_______________________________________
From report at bugs.python.org Wed Apr 29 18:15:24 2009
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 29 Apr 2009 16:15:24 +0000
Subject: [New-bugs-announce] [issue5880] Remove unneeded "context" pointer
from getters and setters
In-Reply-To: <1241021724.62.0.808491876443.issue5880@psf.upfronthosting.co.za>
Message-ID: <1241021724.62.0.808491876443.issue5880@psf.upfronthosting.co.za>
New submission from Larry Hastings <larry at hastings.org>:
PyGetSetDef has a "void *context" field. This field is passed in to the
get and set functions implementing the property. The field is almost
never used, so it adds unnecessary complexity. Clearly, YAGNI.
There are two places in CPython where it got used: both in PyLongObject,
both using long_getN(), where it's used to store an integer constant
(not a pointer!) that is converted to a Long object and returned. Since
there are only two of these, this was easy to fix: split long_getN()
into two functions returning a hard-coded number, long_get0() and
long_get1().
The attached patch removes the "void *context" field of PyGetSetDef,
removes the almost universally ignored context arguments to the getters
and setters, and removes the data declarations for the context pointer
in static PyGetSetDef structs. With the patch applied py3k/trunk passes
all expected regression tests.
Martin: I added you to the nosy list 'cause we looked in to this at the
sprints, so I figured you'd be interested.
----------
files: lch.getset.r72081.diff
keywords: patch
messages: 86812
nosy: larry, loewis
severity: normal
status: open
title: Remove unneeded "context" pointer from getters and setters
Added file: http://bugs.python.org/file13817/lch.getset.r72081.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5880>
_______________________________________
From report at bugs.python.org Wed Apr 29 18:50:05 2009
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 29 Apr 2009 16:50:05 +0000
Subject: [New-bugs-announce] [issue5881] Remove extraneous
backwards-compatibility attributes from some modules
In-Reply-To: <1241023805.22.0.886564039533.issue5881@psf.upfronthosting.co.za>
Message-ID: <1241023805.22.0.886564039533.issue5881@psf.upfronthosting.co.za>
New submission from Larry Hastings <larry at hastings.org>:
While hacking on CPython I noticed a couple of attributes that were
there strictly for backwards compatibility with ancient modules or pure
mistakes. They are:
_hashlib.hash.digestsize
pwd.struct_pwent
_sha224.digestsize
_sha256.digestsize
_sha384.digestsize
_sha512.digestsize
None of these are part of the documented interface, and all of them are
redundant with documented interfaces. I suggest that they can all go.
The attached patch removes all of the above. With the patch applied
Python passes all expected unit tests.
----------
components: Extension Modules
files: lch.modulecleanup.r72081.diff
keywords: patch
messages: 86815
nosy: larry
severity: normal
status: open
title: Remove extraneous backwards-compatibility attributes from some modules
type: feature request
versions: Python 3.1
Added file: http://bugs.python.org/file13818/lch.modulecleanup.r72081.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5881>
_______________________________________
From report at bugs.python.org Wed Apr 29 23:36:17 2009
From: report at bugs.python.org (Jonathan Ellis)
Date: Wed, 29 Apr 2009 21:36:17 +0000
Subject: [New-bugs-announce] [issue5882] __repr__ is ignored when formatting
exceptions
In-Reply-To: <1241040977.95.0.976724243821.issue5882@psf.upfronthosting.co.za>
Message-ID: <1241040977.95.0.976724243821.issue5882@psf.upfronthosting.co.za>
New submission from Jonathan Ellis <ellisj at users.sourceforge.net>:
The docs say that "If a class defines __repr__() but not __str__(), then
__repr__() is also used when an ?informal? string representation of
instances of that class is required."
but, repr is ignored:
>>> class E(Exception):
... def __repr__(self):
... return 'fancy!'
...
>>> raise E()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
__main__.E
only str is respected:
>>> class E(Exception):
... def __str__(self):
... return 'fancy!'
...
>>> raise E()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
__main__.E: fancy!
----------
components: Interpreter Core
messages: 86826
nosy: ellisj
severity: normal
status: open
title: __repr__ is ignored when formatting exceptions
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5882>
_______________________________________
From report at bugs.python.org Thu Apr 30 00:19:49 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 29 Apr 2009 22:19:49 +0000
Subject: [New-bugs-announce] [issue5883] detach() implementation
In-Reply-To: <1241043589.42.0.224421532781.issue5883@psf.upfronthosting.co.za>
Message-ID: <1241043589.42.0.224421532781.issue5883@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <benjamin at python.org>:
Here's the detach() implementation for BufferedIOBase and TextIOBase.
----------
assignee: benjamin.peterson
components: IO
files: detach.patch
keywords: patch
messages: 86830
nosy: benjamin.peterson, pitrou
severity: normal
status: open
title: detach() implementation
type: feature request
versions: Python 3.1
Added file: http://bugs.python.org/file13819/detach.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5883>
_______________________________________
From report at bugs.python.org Thu Apr 30 03:06:32 2009
From: report at bugs.python.org (Mike Miller)
Date: Thu, 30 Apr 2009 01:06:32 +0000
Subject: [New-bugs-announce] [issue5884] pydoc to return error status code
In-Reply-To: <1241053592.21.0.872598622661.issue5884@psf.upfronthosting.co.za>
Message-ID: <1241053592.21.0.872598622661.issue5884@psf.upfronthosting.co.za>
New submission from Mike Miller <python.org at mgmiller.net>:
When pydoc is run from the command line and unable to write a file for a
module because of a syntax error, it would be helpful to return a
non-zero status code as a result.
What it does currently:
C:\>C:\python26\Lib\pydoc.py -w mymod
problem in .\mymod.py - <type 'exceptions.SyntaxError'>: invalid
syntax (mymod.py, line 1)
C:\>echo %ERRORLEVEL%
0
What it should do if an error is found:
C:\>type doesnt_exist.txt
The system cannot find the file specified.
C:\>echo %ERRORLEVEL%
1
This would allow us to make our build scripts able to react to error
conditions, etc without having to use another script. Thanks.
----------
components: Library (Lib)
messages: 86837
nosy: mixmastamyk
severity: normal
status: open
title: pydoc to return error status code
type: feature request
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5884>
_______________________________________
From report at bugs.python.org Thu Apr 30 12:13:36 2009
From: report at bugs.python.org (Wang Chun)
Date: Thu, 30 Apr 2009 10:13:36 +0000
Subject: [New-bugs-announce] [issue5885] uuid.uuid1() is too slow
In-Reply-To: <1241086416.5.0.850110966894.issue5885@psf.upfronthosting.co.za>
Message-ID: <1241086416.5.0.850110966894.issue5885@psf.upfronthosting.co.za>
New submission from Wang Chun <yaohua2000 at gmail.com>:
uuid.uuid1() currently uses two different ways to generate a uuid. If
the system call "uuid_generate_time" is available, uuid1() uses the
system call via the ctypes interface, otherwise, it uses pure Python
code to generate a uuid. The problem is, the C interface
"uuid_generate_time" is even slower than the Python code. The ctypes
interface is too slow. According to my test, it took 55 microseconds to
generate a uuid via ctypes interface but only 45 microseconds via the
Python code. I also tried to test the performance of the
"uuid_generate_time" C API itself. It takes C code 12 microseconds. Most
of the time were wasted on ctypes. I believe we need to drop ctypes and
write a Python extensions in C for this job.
----------
components: Library (Lib)
messages: 86840
nosy: wangchun
severity: normal
status: open
title: uuid.uuid1() is too slow
type: performance
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5885>
_______________________________________
From report at bugs.python.org Thu Apr 30 19:11:30 2009
From: report at bugs.python.org (Andres Moreira)
Date: Thu, 30 Apr 2009 17:11:30 +0000
Subject: [New-bugs-announce] [issue5886] curses/__init__.py: global name
'_os' is not defined
In-Reply-To: <1241111490.69.0.852332227934.issue5886@psf.upfronthosting.co.za>
Message-ID: <1241111490.69.0.852332227934.issue5886@psf.upfronthosting.co.za>
New submission from Andres Moreira <elkpichico at gmail.com>:
Hi,
using ipython2.5 in Ubuntu 9.04. I've get this traceback:
In [1]: max?
---------------------------------------------------------------------------
NameError Traceback (most recent call last)
/var/lib/python-support/python2.5/IPython/iplib.py in
multiline_prefilter(self, line, continue_prompt)
2272 out = []
2273 for l in line.rstrip('\n').split('\n'):
-> 2274 out.append(self._prefilter(l, continue_prompt))
2275 return '\n'.join(out)
2276
/var/lib/python-support/python2.5/IPython/iplib.py in _prefilter(self,
line, continue_prompt)
2254 #print 'pre <%s> iFun <%s> rest <%s>' %
(pre,iFun,theRest) # dbg
2255
-> 2256 return prefilter.prefilter(line_info, self)
2257
2258
/var/lib/python-support/python2.5/IPython/prefilter.py in
prefilter(line_info, ip)
149 handler = check(line_info, ip)
150 if handler:
--> 151 return handler(line_info)
152
153 return ip.handle_normal(line_info)
/var/lib/python-support/python2.5/IPython/iplib.py in handle_help(self,
line_info)
2443 if line:
2444 #print 'line:<%r>' % line # dbg
-> 2445 self.magic_pinfo(line)
2446 else:
2447 page(self.usage,screen_lines=self.rc.screen_length)
/var/lib/python-support/python2.5/IPython/Magic.py in magic_pinfo(self,
parameter_s, namespaces)
661 else:
662 self._inspect('pinfo', oname, detail_level=detail_level,
--> 663 namespaces=namespaces)
664
665 def magic_pdef(self, parameter_s='', namespaces=None):
/var/lib/python-support/python2.5/IPython/Magic.py in _inspect(self,
meth, oname, namespaces, **kw)
746 pmethod(info.obj,oname,formatter)
747 elif meth == 'pinfo':
--> 748 pmethod(info.obj,oname,formatter,info,**kw)
749 else:
750 pmethod(info.obj,oname)
/var/lib/python-support/python2.5/IPython/OInspect.py in pinfo(self,
obj, oname, formatter, info, detail_level)
553 output = out.getvalue()
554 if output:
--> 555 page(output)
556 # end pinfo
557
/var/lib/python-support/python2.5/IPython/genutils.pyc in page(strng,
start, screen_lines, pager_cmd)
1663 # the checks.
1664 term_flags = termios.tcgetattr(sys.stdout)
-> 1665 scr = curses.initscr()
1666 screen_lines_real,screen_cols = scr.getmaxyx()
1667 curses.endwin()
/usr/lib/python2.5/curses/__init__.py in initscr()
28 # we call setupterm() here because it raises an error
29 # instead of calling exit() in error cases.
---> 30 setupterm(term=_os.environ.get("TERM", "unknown"),
31 fd=_sys.__stdout__.fileno())
32 stdscr = _curses.initscr()
NameError: global name '_os' is not defined
I have python2.6 and python2.5 working together. I've attached a patch
to the code that make ipython2.5 working correctly.
----------
components: Library (Lib)
files: curses_init_patch.patch
keywords: patch
messages: 86846
nosy: andrix
severity: normal
status: open
title: curses/__init__.py: global name '_os' is not defined
type: compile error
versions: Python 2.5
Added file: http://bugs.python.org/file13822/curses_init_patch.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5886>
_______________________________________
From report at bugs.python.org Thu Apr 30 20:28:20 2009
From: report at bugs.python.org (Brian Mearns)
Date: Thu, 30 Apr 2009 18:28:20 +0000
Subject: [New-bugs-announce] [issue5887] mmap.write_byte out of bounds - no
error, position gets screwed up
In-Reply-To: <1241116100.06.0.276322653454.issue5887@psf.upfronthosting.co.za>
Message-ID: <1241116100.06.0.276322653454.issue5887@psf.upfronthosting.co.za>
New submission from Brian Mearns <bmearns at ieee.org>:
Created an mmap for a file in update mode, seek to end of file, and
invoke write_byte. The file is not updated (as expected), but did not
get any error indicating the write was out of bounds, and when I invoke
tell(), it reports a position that is out of bounds. I check size(), and
it still reports the correct size (less than the value reported by
tell()). If I do seek(0, os.SEEK_END), it correctly returns to the end
of the map, instead of this bizarre no-mans land beyond the end.
This is on Windows XP.
Here's an example from the shell. (note that write() works as I would
expect, it raises an exception and doesn't modify the position):
>>> map.tell()
0
>>> map.size()
8
>>> map.seek(0, os.SEEK_END)
>>> map.tell()
8
>>> map.write("foo")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: data out of range
>>> map.tell()
8
>>> map.size()
8
>>> map.write_byte('x')
>>> map.tell()
9
>>> map.size()
8
>>> print "WTF?"
WTF?
>>> map.write_byte('x')
>>> map.tell()
10
>>> map.size()
8
>>> map.flush()
1
>>> map.size()
8
>>> map.tell()
10
>>> map.seek(0, os.SEEK_END)
>>> map.tell()
8
>>> map.size()
8
>>>
----------
messages: 86848
nosy: bmearns
severity: normal
status: open
title: mmap.write_byte out of bounds - no error, position gets screwed up
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5887>
_______________________________________
From report at bugs.python.org Thu Apr 30 20:34:11 2009
From: report at bugs.python.org (Brian Mearns)
Date: Thu, 30 Apr 2009 18:34:11 +0000
Subject: [New-bugs-announce] [issue5888] mmap ehancement - resize with
sequence notation
In-Reply-To: <1241116451.53.0.52928290171.issue5888@psf.upfronthosting.co.za>
Message-ID: <1241116451.53.0.52928290171.issue5888@psf.upfronthosting.co.za>
New submission from Brian Mearns <bmearns at ieee.org>:
I thought it would be nice if mmaps could generally look a little more
like sequences. Specifically, being able to resize+write using
square-bracket notation as with lists:
>>> x = [1,2,3,4,5]
>>> x
[1, 2, 3, 4, 5]
>>> x[2:2] = [6,7,8,9]
>>> x
[1, 2, 6, 7, 8, 9, 3, 4, 5]
>>>
If that could be done when x is an mmap.mmap, it'd be great.
alternatively, if mmap had an insert or an extend method that work like
with lists, the same behavior could be achieved without relying on mmap
specific method-names.
----------
messages: 86849
nosy: bmearns
severity: normal
status: open
title: mmap ehancement - resize with sequence notation
type: feature request
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5888>
_______________________________________
From report at bugs.python.org Thu Apr 30 20:44:38 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 30 Apr 2009 18:44:38 +0000
Subject: [New-bugs-announce] [issue5889] Extra comma in enum - fails on AIX
In-Reply-To: <1241117078.61.0.563622380824.issue5889@psf.upfronthosting.co.za>
Message-ID: <1241117078.61.0.563622380824.issue5889@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
cc_r -qlanglvl=ansi -c -DNDEBUG -O -I. -IInclude -I./Include
-DPy_BUILD_CORE -o Objects/unicodeobject.o Objects/unicodeobject.c
"Objects/stringlib/string_format.h", line 37.15: 1506-275 (S) Unexpected
text ',' encountered.
make: *** [Objects/unicodeobject.o] Error 1
Not sure why the extra comma is required in the last enumeration.
----------
components: Build
messages: 86851
nosy: srid, trentm
severity: normal
status: open
title: Extra comma in enum - fails on AIX
type: compile error
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5889>
_______________________________________