From report at bugs.python.org Thu May 1 12:35:03 2008
From: report at bugs.python.org (tempname)
Date: Thu, 01 May 2008 10:35:03 +0000
Subject: [New-bugs-announce] [issue2730] file readline w+ memory dumps
In-Reply-To: <1209638102.99.0.899973997265.issue2730@psf.upfronthosting.co.za>
Message-ID: <1209638102.99.0.899973997265.issue2730@psf.upfronthosting.co.za>
New submission from tempname <partner55296497 at aravensoft.com>:
the following code actually dumps the heap into the temp file... very
strange. Make sure the file doesn't exist before running the script.
Only the list of numbers should be written to the file, but alot of junk
is added.
x = str(range(10))
f = open('c:\\temp.txt', 'w+')
f.write(x)
for i in range(10):
y = f.readline()
print repr(y)
f.close()
----------
components: None
messages: 66032
nosy: tempname1234
severity: normal
status: open
title: file readline w+ memory dumps
type: security
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2730>
__________________________________
From report at bugs.python.org Thu May 1 18:08:51 2008
From: report at bugs.python.org (=?utf-8?q?Gerald_Schl=C3=BCter?=)
Date: Thu, 01 May 2008 16:08:51 +0000
Subject: [New-bugs-announce] [issue2731] Documentation error on prime
example in tutorial
In-Reply-To: <1209658131.12.0.892080432215.issue2731@psf.upfronthosting.co.za>
Message-ID: <1209658131.12.0.892080432215.issue2731@psf.upfronthosting.co.za>
New submission from Gerald Schl?ter <gls at trillke.net>:
Hi there,
on the page "controlflow.html" in chapter "break and continue
Statements..." the line:
print(n, 'equals', x, '*', n/x)
should be changed to:
print(n, 'equals', x, '*', n//x)
or else the shown output should be modified.
Thank you,
Gerry
----------
assignee: georg.brandl
components: Documentation
messages: 66034
nosy: georg.brandl, gls
severity: normal
status: open
title: Documentation error on prime example in tutorial
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2731>
__________________________________
From report at bugs.python.org Thu May 1 18:39:41 2008
From: report at bugs.python.org (Shish)
Date: Thu, 01 May 2008 16:39:41 +0000
Subject: [New-bugs-announce] [issue2732] curses.textpad loses characters at
the end of lines
In-Reply-To: <1209659981.45.0.724290161206.issue2732@psf.upfronthosting.co.za>
Message-ID: <1209659981.45.0.724290161206.issue2732@psf.upfronthosting.co.za>
New submission from Shish <shish+python at shishnet.org>:
Even in the self-test suite, the bug appears, run:
python /usr/lib/python2.4/curses/textpad.py
then type so that the line wraps, eg 123456789123456789 to fill two
lines, and then ctrl-g to return -- the result has had the end
characters of each line removed, so the return value is
12345678\n12345678\n
As a quick hack on my local install I changed line 56 from:
last = min(self.maxx, last+1)
to
last = min(self.maxx, last)+1
and it seems to work, but I have no idea if this is the right way to
fix it (ie, this might have side effects, or this off-by-one might
happen in several places and need a global fix, not just one local one)
----------
components: Extension Modules
messages: 66035
nosy: shish
severity: normal
status: open
title: curses.textpad loses characters at the end of lines
versions: Python 2.4
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2732>
__________________________________
From report at bugs.python.org Thu May 1 19:04:17 2008
From: report at bugs.python.org (Kathryn M Kowalski)
Date: Thu, 01 May 2008 17:04:17 +0000
Subject: [New-bugs-announce] [issue2733] mmap resize fails on anonymous
memory (Windows)
In-Reply-To: <1209661457.64.0.989081565875.issue2733@psf.upfronthosting.co.za>
Message-ID: <1209661457.64.0.989081565875.issue2733@psf.upfronthosting.co.za>
New submission from Kathryn M Kowalski <kathy.kowalski at ae.ge.com>:
We have a shared memory module that has been running fine on Windows
with Active State Python 2.4.3 Build 12. On machines with 2.5.1.1
mmap.resize fails on an existing anonymous shared memory. The attached
file is a stripped down version of the code to illustrate the problem.
Start it running in one window to create the shared memory, then in
another window run it again to hook into existing shared memory. Result:
Testing SharedMemory
open -self.memory_size 336
Traceback (most recent call last):
File "C:/home/weather/TESTOF~1.PY", line 164, in <module>
example()
File "C:/home/weather/TESTOF~1.PY", line 147, in example
sm = SharedMemory( 'my_shared_memory')
File "C:/home/weather/TESTOF~1.PY", line 31, in __init__
self.__open()
File "C:/home/weather/TESTOF~1.PY", line 94, in __open
self.memory.resize(self.memory_size)
WindowsError: [Error 8] Not enough storage is available to process this
command
----------
components: Library (Lib)
files: testofResizeB.txt
messages: 66036
nosy: kmk
severity: normal
status: open
title: mmap resize fails on anonymous memory (Windows)
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file10151/testofResizeB.txt
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2733>
__________________________________
From report at bugs.python.org Thu May 1 21:21:01 2008
From: report at bugs.python.org (Charles McCreary)
Date: Thu, 01 May 2008 19:21:01 +0000
Subject: [New-bugs-announce] [issue2734] 2to3 converts long(itude) argument
to int
In-Reply-To: <1209669660.53.0.857681626906.issue2734@psf.upfronthosting.co.za>
Message-ID: <1209669660.53.0.857681626906.issue2734@psf.upfronthosting.co.za>
New submission from Charles McCreary <charles.mccreary at crmeng.com>:
The 2to3 converter converts variables named "long" to "int".
Original:
long is an argument (longitude)
def add_test_qtrmin(tdb, lat, long, area_id, call_center=""):
Converted:
def add_test_qtrmin(tdb, lat, int, area_id, call_center=""):
I can see what it is trying to do, but I definitely don't want this
behavior!
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 66038
nosy: collinwinter, crmccreary
severity: normal
status: open
title: 2to3 converts long(itude) argument to int
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2734>
__________________________________
From report at bugs.python.org Thu May 1 22:48:57 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 01 May 2008 20:48:57 +0000
Subject: [New-bugs-announce] [issue2735] range: lean and mean
In-Reply-To: <1209674937.13.0.531177729301.issue2735@psf.upfronthosting.co.za>
Message-ID: <1209674937.13.0.531177729301.issue2735@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
Per discussions on Python-3000, I've stipped range down to a bare
minimum. Here's an overview of the patch:
1. No slicing.
2. Length is computed in constructor and is a PyLong in the object's
struct. __len__ simply tries to convert it to a Py_ssize_t.
3. start, stop, and, step are exposed as attributes
----------
assignee: gvanrossum
components: Interpreter Core
files: range_lean_and_mean.patch
keywords: patch
messages: 66042
nosy: benjamin.peterson, gvanrossum
severity: normal
status: open
title: range: lean and mean
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file10152/range_lean_and_mean.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2735>
__________________________________
From report at bugs.python.org Thu May 1 23:03:28 2008
From: report at bugs.python.org (Miki Tebeka)
Date: Thu, 01 May 2008 21:03:28 +0000
Subject: [New-bugs-announce] [issue2736] datetime needs and "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
New submission from Miki Tebeka <miki.tebeka at gmail.com>:
If you try to convert datetime objects to seconds since epoch and back
it will not work since the microseconds get lost:
>>> dt = datetime(2008, 5, 1, 13, 35, 41, 567777)
>>> seconds = mktime(dt.timetuple())
>>> datetime.fromtimestamp(seconds) == dt
False
Current fix is to do
>>> seconds += (dt.microsecond / 1000000.0)
>>> datetime.fromtimestamp(seconds) == dt
True
----------
components: Library (Lib)
messages: 66045
nosy: tebeka
severity: normal
status: open
title: datetime needs and "epoch" method
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
__________________________________
From report at bugs.python.org Fri May 2 20:05:40 2008
From: report at bugs.python.org (Ruben Kerkhof)
Date: Fri, 02 May 2008 18:05:40 +0000
Subject: [New-bugs-announce] [issue2740] Cmd module doesn't support readline
completion on OSX Leopard
In-Reply-To: <1209751540.52.0.644222816573.issue2740@psf.upfronthosting.co.za>
Message-ID: <1209751540.52.0.644222816573.issue2740@psf.upfronthosting.co.za>
New submission from Ruben Kerkhof <ruben at rubenkerkhof.com>:
Hi,
Leopard ships with libedit, which is almost the same as readline, but
has another way to configure completion keys. To enable tab completion
you have to use rl.parse_and_bind("bind ^I complete") instead of rl.parse_and_bind("bind ^I rl_complete") instead of rl.parse_and_bind("tab: complete").
The guys from IPython patched around it, see http://ipython.scipy.org/moin/InstallationOSXLeopard/LeopardPythonReadli
ne, but is seems to me this is better solved in the python readline
module itself.
----------
components: Library (Lib)
messages: 66101
nosy: ruben
severity: normal
status: open
title: Cmd module doesn't support readline completion on OSX Leopard
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2740>
__________________________________
From report at bugs.python.org Fri May 2 20:53:13 2008
From: report at bugs.python.org (Mike MacFaden)
Date: Fri, 02 May 2008 18:53:13 +0000
Subject: [New-bugs-announce] [issue2741] documentation -- do serversockets
work with ipv6
In-Reply-To: <1209754393.92.0.50120862505.issue2741@psf.upfronthosting.co.za>
Message-ID: <1209754393.92.0.50120862505.issue2741@psf.upfronthosting.co.za>
New submission from Mike MacFaden <mrm at vmware.com>:
the url
http://docs.python.org/lib/node633.html
states
1) address_family
The family of protocols to which the server's socket belongs.
socket.AF_INET and socket.AF_UNIX are two possible values.
would suggest including socket.AF_INET6 as well if it is supported
or what criteria makes a socket not usable with this class.
----------
assignee: georg.brandl
components: Documentation
messages: 66102
nosy: georg.brandl, mrm
severity: normal
status: open
title: documentation -- do serversockets work with ipv6
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2741>
__________________________________
From report at bugs.python.org Fri May 2 20:57:59 2008
From: report at bugs.python.org (Mike MacFaden)
Date: Fri, 02 May 2008 18:57:59 +0000
Subject: [New-bugs-announce] [issue2742] example code does not work
In-Reply-To: <1209754679.55.0.840137197769.issue2742@psf.upfronthosting.co.za>
Message-ID: <1209754679.55.0.840137197769.issue2742@psf.upfronthosting.co.za>
New submission from Mike MacFaden <mrm at vmware.com>:
the url
http://docs.python.org/lib/socket-example.html
gives an example that uses socket.getaddrinfo that has this code
HOST=''
...
for res in socket.getaddrinfo(HOST, PORT, socket.AF_UNSPEC,
socket.SOCK_STREAM, 0, socket.AI_PASSIVE)
but this fails on freebsd 6.1/python 2.5 as follows
> /usr/home/mrm/s2.py(30)<module>()
-> for res in socket.getaddrinfo(HOST, PORT, socket.AF_UNSPEC,
socket.SOCK_STREAM, 0, socket.AI_PASSIVE):
(Pdb) p HOST
''
(Pdb) n
gaierror: (8, 'hostname nor servname provided, or not known')
> /usr/home/mrm/s2.py(30)<module>()
but setting
HOST=None
works fine.
either this is a doc bug or a code bug, your pick.
----------
assignee: georg.brandl
components: Documentation
messages: 66103
nosy: georg.brandl, mrm
severity: normal
status: open
title: example code does not work
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2742>
__________________________________
From report at bugs.python.org Fri May 2 23:26:49 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 02 May 2008 21:26:49 +0000
Subject: [New-bugs-announce] [issue2743] Fix module output for warnings from
the interpreter
In-Reply-To: <1209763609.26.0.692932361871.issue2743@psf.upfronthosting.co.za>
Message-ID: <1209763609.26.0.692932361871.issue2743@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
In svn, the module name is lost if you raise an exception at the
interpreter::
>>> import warnings
>>> warnings.warn("foo")
:1: UserWarning: foo
It should be::
>>> import warnings
>>> warnings.warn("foo")
__main__:1: UserWarning: foo
Notice how '__main__' is missing in svn.
----------
assignee: brett.cannon
components: Interpreter Core
messages: 66112
nosy: brett.cannon
priority: critical
severity: normal
status: open
title: Fix module output for warnings from the interpreter
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2743>
__________________________________
From report at bugs.python.org Sat May 3 01:15:10 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 02 May 2008 23:15:10 +0000
Subject: [New-bugs-announce] [issue2744] Fix test_cProfile
In-Reply-To: <1209770110.61.0.304892387875.issue2744@psf.upfronthosting.co.za>
Message-ID: <1209770110.61.0.304892387875.issue2744@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
test_cProfile has been disabled in Py3k for a while now. It should be
fixed before release.
----------
messages: 66131
nosy: benjamin.peterson
priority: critical
severity: normal
status: open
title: Fix test_cProfile
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2744>
__________________________________
From report at bugs.python.org Sat May 3 02:22:45 2008
From: report at bugs.python.org (Mark Hammond)
Date: Sat, 03 May 2008 00:22:45 +0000
Subject: [New-bugs-announce] [issue2745] Add support for IsWow64Process
In-Reply-To: <1209774164.99.0.662005480368.issue2745@psf.upfronthosting.co.za>
Message-ID: <1209774164.99.0.662005480368.issue2745@psf.upfronthosting.co.za>
New submission from Mark Hammond <mhammond at users.sourceforge.net>:
As per a thread on python-dev, I offered to add sys.iswow64process. I'm
attaching a patch that does this (including news, docs and tests). I'm
adding Martin to the nosy list as he has expressed reservations ("It
sounds like clutter of the sys module to me"), so I expect this to be
rejected.
----------
assignee: mhammond
components: Windows
files: iswow64process.patch
keywords: patch
messages: 66137
nosy: loewis, mhammond
severity: normal
status: open
title: Add support for IsWow64Process
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10175/iswow64process.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2745>
__________________________________
From report at bugs.python.org Sat May 3 17:12:26 2008
From: report at bugs.python.org (Dave Hughes)
Date: Sat, 03 May 2008 15:12:26 +0000
Subject: [New-bugs-announce] [issue2746] ElementTree ProcessingInstruction
uses character entities in content
In-Reply-To: <1209827546.16.0.534568490293.issue2746@psf.upfronthosting.co.za>
Message-ID: <1209827546.16.0.534568490293.issue2746@psf.upfronthosting.co.za>
New submission from Dave Hughes <dave at waveform.plus.com>:
In the ElementTree and cElementTree implementations in Python 2.5 (and
possibly Python 2.6 as I also found this issue when testing an SVN
checkout of ElementTree 1.3), the conversion of a ProcessingInstruction
to a string converts XML reserved characters (<, >, &) to character
entities:
>>> from xml.etree.ElementTree import *
>>> tostring(ProcessingInstruction('test', '<testing&>'))
'<?test <testing&>?>'
>>> from xml.etree.cElementTree import *
>>> tostring(ProcessingInstruction('test', '<testing&>'))
'<?test <testing&>?>'
The XML 1.0 spec is rather vague on whether character entities are
permitted in PIs (it explicitly states parameter entities are not
parsed in PIs, but says nothing about parsing character entities).
However, it does have this to say in section 2.4 "Character Data and
Markup":
"The ampersand character (&) and the left angle bracket (<) MUST NOT
appear in their literal form, except when used as markup delimiters, or
within a comment, a processing instruction, or a CDATA section."
So, XML reserved chars don't need converting in PIs (the only string
not permitted in a PI's content according to the spec, section 2.6, is
'?>'), which sort of implies that they shouldn't be. As for practical
reasons why they shouldn't be:
Breaks generated PHP:
>>> from xml.etree.cElementTree import *
>>> doc = Element('html')
>>> SubElement(doc, 'head')
<Element 'head' at 0x2af4e3b8a9f0>
>>> SubElement(doc, 'body')
<Element 'body' at 0x2af4e3b922a0>
>>> doc[1].append(ProcessingInstruction('php', 'if (2 < 1) print
"<p>Something has gone horribly wrong!</p>";'))
>>> tostring(doc)
'<html><head /><body><?php if (2 < 1) print "<p>Something has
gone horribly wrong!</p>";?></body></html>'
Different from xml.dom:
>>> from xml.dom.minidom import *
>>> i = getDOMImplementation()
>>> doc = i.createDocument(None, 'html', None)
>>> doc.documentElement.appendChild(doc.createElement('head'))
<DOM Element: head at 0x8c6170>
>>> doc.documentElement.appendChild(doc.createElement('body'))
<DOM Element: body at 0x8c6290>
>>>
doc.documentElement.lastChild.appendChild(doc.createProcessingInstruction('test',
'<testing&>'))
<xml.dom.minidom.ProcessingInstruction instance at 0x8c63b0>
>>> doc.toxml()
'<?xml version="1.0" ?>\n<html><head/><body><?test <testing&>?></body></
html>'
Different from lxml:
>>> from lxml.etree import *
>>> tostring(ProcessingInstruction('test', '<testing&>'))
'<?test <testing&>?>'
I suspect the only change necessary to fix this is to replace the
_escape_cdata() call for ProcessingInstruction (and possibly Comment
too given the spec quote above) in ElementTree._write() with an
_encode() call, as shown in this patch (which includes the Comment
change as well):
Index: elementtree/ElementTree.py
===================================================================
--- elementtree/ElementTree.py (revision 511)
+++ elementtree/ElementTree.py (working copy)
@@ -663,9 +663,9 @@
# write XML to file
tag = node.tag
if tag is Comment:
- file.write("<!-- %s -->" % _escape_cdata(node.text,
encoding))
+ file.write("<!-- %s -->" % _encode(node.text, encoding))
elif tag is ProcessingInstruction:
- file.write("<?%s?>" % _escape_cdata(node.text, encoding))
+ file.write("<?%s?>" % _encode(node.text, encoding))
else:
items = node.items()
xmlns_items = [] # new namespaces in this scope
Sorry I haven't got a similar patch for cElementTree. I've had a quick
look through the source, but haven't yet figured out where the change
should be made (unless it's not required - does cElementTree reuse that
bit of ElementTree?).
----------
components: XML
messages: 66154
nosy: waveform
severity: normal
status: open
title: ElementTree ProcessingInstruction uses character entities in content
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2746>
__________________________________
From report at bugs.python.org Sat May 3 19:18:54 2008
From: report at bugs.python.org (Ali Afshar)
Date: Sat, 03 May 2008 17:18:54 +0000
Subject: [New-bugs-announce] [issue2747] Documentation of new gobject types
fails
In-Reply-To: <1209835134.72.0.0778910402245.issue2747@psf.upfronthosting.co.za>
Message-ID: <1209835134.72.0.0778910402245.issue2747@psf.upfronthosting.co.za>
New submission from Ali Afshar <aafshar at gmail.com>:
When using the automodule directive on a module that creates new Gobject
types (eg custom PyGTK widget), the implicit registration of the
imported types fail. (Normally any GObject subclass which has a
__gtype_name__ attribute is automatically registered as a new GType
using a metaclass.
I have had a dig around some of the code of gobject, and pygobject, but
not really any help to me.
http://svn.gnome.org/viewvc/pygobject/trunk/gobject/gobjectmodule.c?revision=777&view=markup
http://svn.gnome.org/viewvc/glib/trunk/gobject/gtype.c?revision=6454&view=markup
If anyone wants a quick look.
The directive I am using is:
.. automodule:: pygtkdock
:members:
I have also attached the exception I am getting.
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: sphinx-err-FK4s9A.log
messages: 66158
nosy: aafshar, georg.brandl
severity: normal
status: open
title: Documentation of new gobject types fails
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file10182/sphinx-err-FK4s9A.log
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2747>
__________________________________
From report at bugs.python.org Sat May 3 21:10:52 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 May 2008 19:10:52 +0000
Subject: [New-bugs-announce] [issue2748] ceil(),
floor() and round() broken in Decimal
In-Reply-To: <1209841852.4.0.852706642988.issue2748@psf.upfronthosting.co.za>
Message-ID: <1209841852.4.0.852706642988.issue2748@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
In Python 3.0, the Decimal __round__, __ceil__ and __floor__ functions
don't work as intended: they all return 1, 0, or -1.
This is easy to fix. The only reason I'm making an issue (literally) of
it is that I remember some discussion of whether these functions should
be implemented at all for Decimal, but I don't remember what the outcome
of that discussion was. Adding Jeffrey to the nosy list in case he
remembers.
Either all three functions should be removed, or they should be
corrected and tests should be added for them.
----------
assignee: facundobatista
components: Library (Lib)
messages: 66164
nosy: facundobatista, jyasskin, marketdickinson
severity: normal
status: open
title: ceil(), floor() and round() broken in Decimal
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2748>
__________________________________
From report at bugs.python.org Sat May 3 22:45:56 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 03 May 2008 20:45:56 +0000
Subject: [New-bugs-announce] [issue2749] Raise a DeprecationWarning for
warnings.showwarning(.., line)
In-Reply-To: <1209847556.68.0.658997115031.issue2749@psf.upfronthosting.co.za>
Message-ID: <1209847556.68.0.658997115031.issue2749@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
In order to move the warnings.showwarning() API forward to support the new
'line' argument, a DeprecationWarning is needed for implementations that
lack support for it.
>From the Python side a simple check for the 'line' argument using
'inspect' will work. For the C side, a check that there is more than 1
default argument should suffice, although a quick check of what other ways
to introspect Python function objects from C code should be done first
before settling on this solution.
----------
assignee: brett.cannon
components: Interpreter Core
keywords: easy
messages: 66172
nosy: brett.cannon
priority: critical
severity: normal
status: open
title: Raise a DeprecationWarning for warnings.showwarning(.., line)
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2749>
__________________________________
From report at bugs.python.org Sat May 3 23:52:55 2008
From: report at bugs.python.org (Bob Ippolito)
Date: Sat, 03 May 2008 21:52:55 +0000
Subject: [New-bugs-announce] [issue2750] Add simplejson to Python 2.6/3.0
standard library
In-Reply-To: <1209851575.56.0.265185398375.issue2750@psf.upfronthosting.co.za>
Message-ID: <1209851575.56.0.265185398375.issue2750@psf.upfronthosting.co.za>
New submission from Bob Ippolito <bob at redivi.com>:
Attached is the tarball for simplejson 1.9, the proposed version to be
included in the stdlib.
Estimated work remaining:
* Rename simplejson to json
* Build simplejson/_speedups.c from Modules/Setup and Windows projects
* Convert documentation to Python docs
* Port to Python 3.0
----------
components: Library (Lib)
files: simplejson-1.9.tar.gz
messages: 66176
nosy: bob.ippolito
severity: normal
status: open
title: Add simplejson to Python 2.6/3.0 standard library
type: feature request
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10185/simplejson-1.9.tar.gz
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2750>
__________________________________
From report at bugs.python.org Sun May 4 02:36:18 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 04 May 2008 00:36:18 +0000
Subject: [New-bugs-announce] [issue2751] Regression for executing packages
In-Reply-To: <1209861378.3.0.693402002548.issue2751@psf.upfronthosting.co.za>
Message-ID: <1209861378.3.0.693402002548.issue2751@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
If I have a package like this:
pack/
__init__.py
and __init__.py looks like this
if __name__ == "__main__":
print "Spam"
python -m pack gives
one is a package and cannot be directly executed
This is regression from 2.5 where "Spam" would be printed.
----------
components: Interpreter Core
messages: 66184
nosy: benjamin.peterson
priority: critical
severity: normal
status: open
title: Regression for executing packages
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2751>
__________________________________
From report at bugs.python.org Sun May 4 07:08:30 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 04 May 2008 05:08:30 +0000
Subject: [New-bugs-announce] [issue2752] Wrong comment in socket
documentation
In-Reply-To: <1209877709.98.0.739134633667.issue2752@psf.upfronthosting.co.za>
Message-ID: <1209877709.98.0.739134633667.issue2752@psf.upfronthosting.co.za>
New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:
In the example section of socket module I see:
HOST = '' # Symbolic name meaning the local host
PORT = 50007 # Arbitrary non-privileged port
'', at least on Windows, is an alias for telling the socket to listen on
all available interfaces while 'localhost' is used for referencing the
local interface (usually '127.0.0.1').
----------
assignee: georg.brandl
components: Documentation
messages: 66191
nosy: georg.brandl, giampaolo.rodola
severity: normal
status: open
title: Wrong comment in socket documentation
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2752>
__________________________________
From report at bugs.python.org Sun May 4 07:38:37 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 04 May 2008 05:38:37 +0000
Subject: [New-bugs-announce] [issue2753] Test issue
In-Reply-To: <1209879517.54.0.220389917163.issue2753@psf.upfronthosting.co.za>
Message-ID: <1209879517.54.0.220389917163.issue2753@psf.upfronthosting.co.za>
New submission from Martin v. L?wis <martin at v.loewis.de>:
Testing the integration with the review tool.
----------
files: regrtest.diff
keywords: patch
messages: 66192
nosy: loewis
severity: normal
status: open
title: Test issue
Added file: http://bugs.python.org/file10187/regrtest.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2753>
__________________________________
From report at bugs.python.org Sun May 4 14:26:16 2008
From: report at bugs.python.org (Alex Robinson)
Date: Sun, 04 May 2008 12:26:16 +0000
Subject: [New-bugs-announce] [issue2754] Mac version of IDLE doesn't scroll
as expected
In-Reply-To: <1209903976.71.0.763172048838.issue2754@psf.upfronthosting.co.za>
Message-ID: <1209903976.71.0.763172048838.issue2754@psf.upfronthosting.co.za>
New submission from Alex Robinson <alextrob at gmail.com>:
On a Mac running 10.5.2 in IDLE 1.2.1, the scroll bars don't move as
expected & track pad/mouse scrolling is not enabled. I believe this is
also the case on Tiger (10.4)
When using the scroll bar to scroll up through code, the scroll bar
moves much faster than the mouse pointer. When scrolling down, the mouse
pointer moves slightly faster.
Unlike Terminal, scrolling using a scroll wheel on a mouse or the two
fingers on the trackpad doesn't work with IDLE.
I realize these are fairly minor UI issues, but they're still
frustrating and slow down my workflow.
----------
components: IDLE, Macintosh
messages: 66202
nosy: alextrob
severity: normal
status: open
title: Mac version of IDLE doesn't scroll as expected
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2754>
__________________________________
From report at bugs.python.org Sun May 4 15:55:21 2008
From: report at bugs.python.org (Mark Veldhuis)
Date: Sun, 04 May 2008 13:55:21 +0000
Subject: [New-bugs-announce] [issue2755] IDLE ignores module change before
restart
In-Reply-To: <1209909321.12.0.0383863642875.issue2755@psf.upfronthosting.co.za>
Message-ID: <1209909321.12.0.0383863642875.issue2755@psf.upfronthosting.co.za>
New submission from Mark Veldhuis <mv at marvelid.com>:
I changed module A, and then tested module B that imported module A. it
took a while to realise that what went wrong was that the change had not
registered in module B, even when I closed and reopened the window, the
shell etc. I had to quit IDLE and restart before module B imported the
changed module A. In the file enclosed is a step by step version that
isolates the problem.
At the moment I am working through a Python course using IDLE on UBUNTU
Hardy, and it could be this is a beginners error and no bug after all.
----------
components: IDLE
files: idleupdatebug.odt
messages: 66210
nosy: mooz123
severity: normal
status: open
title: IDLE ignores module change before restart
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10190/idleupdatebug.odt
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2755>
__________________________________
From report at bugs.python.org Sun May 4 17:11:38 2008
From: report at bugs.python.org (david reid)
Date: Sun, 04 May 2008 15:11:38 +0000
Subject: [New-bugs-announce] [issue2756] urllib2 add_header fails with
existing unredirected_header
In-Reply-To: <1209913898.38.0.175541514636.issue2756@psf.upfronthosting.co.za>
Message-ID: <1209913898.38.0.175541514636.issue2756@psf.upfronthosting.co.za>
New submission from david reid <mail at david-reid.com>:
In urllib2 when using reusing a Request calling add_header doesn't work
when an unredirected_header has been added.
A good example (and the one that caught me out) is content-type. When
making a POST request with no content-type set the current code sets the
content-type as an unredirected_header to
'application/x-www-form-urlencoded' (line 1034 of urllib2.py) but in a
subsequent request, setting the content type via add_header will see
this ignored as unredirected_headers are appended after the headers.
A possible solution is to check whether the header being added already
exists in the requests undredirected_headers and remove it if it does.
----------
components: Library (Lib)
messages: 66213
nosy: zathras
severity: normal
status: open
title: urllib2 add_header fails with existing unredirected_header
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2756>
__________________________________
From report at bugs.python.org Sun May 4 17:29:49 2008
From: report at bugs.python.org (Manuel Kaufmann)
Date: Sun, 04 May 2008 15:29:49 +0000
Subject: [New-bugs-announce] [issue2757] Little error in unittest
documentation
In-Reply-To: <1209914989.11.0.259264141747.issue2757@psf.upfronthosting.co.za>
Message-ID: <1209914989.11.0.259264141747.issue2757@psf.upfronthosting.co.za>
New submission from Manuel Kaufmann <humitos at gmail.com>:
I found a more Enter
----------
assignee: georg.brandl
components: Documentation
files: unittest.diff
keywords: patch
messages: 66214
nosy: georg.brandl, humitos
severity: normal
status: open
title: Little error in unittest documentation
versions: Python 2.6
Added file: http://bugs.python.org/file10192/unittest.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2757>
__________________________________
From report at bugs.python.org Sun May 4 19:42:09 2008
From: report at bugs.python.org (=?utf-8?q?Uwe_Kleine-K=C3=B6nig?=)
Date: Sun, 04 May 2008 17:42:09 +0000
Subject: [New-bugs-announce] [issue2758] arg 2 of
PyErr_SetFromErrnoWithFilename should be const
In-Reply-To: <1209922929.05.0.442409778711.issue2758@psf.upfronthosting.co.za>
Message-ID: <1209922929.05.0.442409778711.issue2758@psf.upfronthosting.co.za>
New submission from Uwe Kleine-K?nig <ukleinek at informatik.uni-freiburg.de>:
Compiling an extension I get the warning:
warning: passing argument 2 of ?PyErr_SetFromErrnoWithFilename?
discards qualifiers from pointer target type
I passed a const char *, which should be OK from looking at the
implementation of PyErr_SetFromErrnoWithFilename.
Attached is a patch. I don't expect this to break any API or ABI, but
you might know better.
----------
components: Interpreter Core
files: make_PyErr_SetFromErrnoWithFilename_filename_const
messages: 66220
nosy: ukleinek
severity: normal
status: open
title: arg 2 of PyErr_SetFromErrnoWithFilename should be const
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10194/make_PyErr_SetFromErrnoWithFilename_filename_const
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2758>
__________________________________
From report at bugs.python.org Sun May 4 19:42:07 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 04 May 2008 17:42:07 +0000
Subject: [New-bugs-announce] [issue2759] Bool makes filter(None,it)
redundant; remove None option?
In-Reply-To: <1209922927.71.0.76492509118.issue2759@psf.upfronthosting.co.za>
Message-ID: <1209922927.71.0.76492509118.issue2759@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
Filter() allows None as a stand-in for either the still-nonexistent
identity() or the now existent bool(). Removing the now redundant
option would slightly simplify the language. It is certainly a glitch
for newcomers. Would this option be included if filter were being added
now?
Fixer: I should think filter(None,it) => filter(bool,it) should be
sufficient as I expect filter(f_f_exp, it), where f_f_exp is a filter
function expression that sometimes gives None, should be fairly rare.
Efficiency: filter() could (if it does not now) avoid calling bool twice
internally by checking for bool instead of None). Even if removing None
is rejected, filter should also check for bool (if it does not now) to
not penalize those who write the obvious filter(bool,it).
If this item is rejected, turn it into a doc item for PEP3099.
----------
components: Interpreter Core
messages: 66219
nosy: tjreedy
severity: normal
status: open
title: Bool makes filter(None,it) redundant; remove None option?
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2759>
__________________________________
From report at bugs.python.org Sun May 4 19:57:29 2008
From: report at bugs.python.org (Thomas Herve)
Date: Sun, 04 May 2008 17:57:29 +0000
Subject: [New-bugs-announce] [issue2760] Recent change in socket.py breaks
urllib2
In-Reply-To: <1209923849.77.0.999973042575.issue2760@psf.upfronthosting.co.za>
Message-ID: <1209923849.77.0.999973042575.issue2760@psf.upfronthosting.co.za>
New submission from Thomas Herve <therve at free.fr>:
The problematic change is here:
http://svn.python.org/view/python/trunk/Lib/socket.py?rev=62627&r1=61008&r2=62627
The following script shows the problem:
Python 2.6a2+ (trunk:62707, May 4 2008, 19:13:44)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib2
>>> r = urllib2.Request('http://pypi.python.org/simple')
>>> f = urllib2.urlopen(r)
>>> f.read()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/therve/.local/lib/python2.6/socket.py", line 326, in read
data = self._sock.recv(rbufsize)
File "/home/therve/.local/lib/python2.6/httplib.py", line 512, in read
return self._read_chunked(amt)
File "/home/therve/.local/lib/python2.6/httplib.py", line 548, in
_read_chunked
line = self.fp.readline()
File "/home/therve/.local/lib/python2.6/socket.py", line 391, in readline
assert buf.tell() == 0
AssertionError
>>>
----------
components: Library (Lib)
messages: 66222
nosy: therve
severity: normal
status: open
title: Recent change in socket.py breaks urllib2
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2760>
__________________________________
From report at bugs.python.org Sun May 4 20:12:08 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 04 May 2008 18:12:08 +0000
Subject: [New-bugs-announce] [issue2761] Doc: built-in callables and map
In-Reply-To: <1209924728.67.0.122763475397.issue2761@psf.upfronthosting.co.za>
Message-ID: <1209924728.67.0.122763475397.issue2761@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
StdLibMan Built-in Functions
I believe that at one time this section only contained functions.
But this has not been true since at least 2.2.
Please add "and Classes" to the title and first sentence.
Possibly add "('callables')" after "and classes" in the sentence to
introduce the generic term. This would at least slightly help the
sometimes confusion between 'function' as specific class and as generic
callable.
This change also applies to 2.6 (and earlier, but oh, well...).
3.0 entry for map() (now a class!) in this section. Please add
"With multiple iterables, stops when the shortest iterable is exhausted"
. (Copied from map.__doc__.)
What's New in 3.0: Stumbling Blocks: map entry: Add same sentence or
similar. I only checked help(map) and discovered the change because of
reading about itertools.imap and knowing that 3.0 map was derived?
copied? from that.
----------
assignee: georg.brandl
components: Documentation
messages: 66228
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Doc: built-in callables and map
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2761>
__________________________________
From report at bugs.python.org Sun May 4 22:14:37 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 04 May 2008 20:14:37 +0000
Subject: [New-bugs-announce] [issue2762] Language Reference: obsolute 2.x
notes
In-Reply-To: <1209932077.37.0.181467307786.issue2762@psf.upfronthosting.co.za>
Message-ID: <1209932077.37.0.181467307786.issue2762@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
The 3.0a4 docs have various obsolete references to 2.x not yet removed.
I found these and other items by searching for '2.' in each section
Lexical Analysis: Identifiers and Keywords
Please specify the legal ascii chars rather than referring back to the
2.5 doc! I would delete the second sentence and add the reference to
PEP3131 to the end of the third. As it is, 'additional characters' and
'other characters' seem like possibly two different sets.
Data Model: instance methods: 'changed in 2.6' delete
Data Model: New Style and Classic Classes
Probably this whole section should go. I hope that the last sentence is
no longer true ;-)
Data Model: footnote 1 (which I believe came from above): delete
Simple Statements: Raise: several changes suggested.
The grammar is wrong. There is only one optional expression.
PEP3131 does not mention .with_traceback. It should if people are
referred to it. But I would leave out the note and reference. PEP3131
is irrelevant to anyone just learning Py3 and not useful to non-expert
Py2 users. Anyway, those who need it will find the reference in What's
New.
The .with_traceback method has no doc string. I presume it should say
"Sets the __traceback__ attribute and returns self."
The manual should also mention that the method returns the exception
instance (self) Suggestion: "method (which returns the exception
instance), like so:" (There stuff in parens is suggested addition.) I
think this is worth mentioning because mutators, including setters,
typically do *not* return 'self'.
Compound statements: Try
Given my opinion that 3.0 documents (other that What's New and other
explicit transition docs) should stand on their own, I would also remove
the reference to PEP3110. But at least it applies to most users. But
again, I am not sure it adds very much.
The What's New/Exception Stuff entry for PEP3110 could usefully add "You
must now use except SomeException as identifier: instead of except
Exception,identifier" in parallel to the note for 3109 above it
(including the shading of code).
Compound statements: With: remove last two sentences
The Library Reference needs similar treatment. There are several "2."
references just in Built-in Functions.
----------
assignee: georg.brandl
components: Documentation
messages: 66237
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Language Reference: obsolute 2.x notes
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2762>
__________________________________
From report at bugs.python.org Sun May 4 23:51:53 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 04 May 2008 21:51:53 +0000
Subject: [New-bugs-announce] [issue2763] A socket example code shown in doc
doesn't work on FreeBSD
In-Reply-To: <1209937912.94.0.0729718790941.issue2763@psf.upfronthosting.co.za>
Message-ID: <1209937912.94.0.0729718790941.issue2763@psf.upfronthosting.co.za>
New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:
This is the result from executing the second IPv4/IPv6 server example
shown in socket module documentation on a FreeBSD-7 system.
http://docs.python.org/dev/library/socket.html#example
dhcppc1# cat server.py
# Echo server program
import socket
import sys
HOST = '' # Symbolic name meaning the local host
PORT = 50007 # Arbitrary non-privileged port
s = None
for res in socket.getaddrinfo(HOST, PORT, socket.AF_UNSPEC,
socket.SOCK_STREAM, 0, socket.AI_PASSIVE):
af, socktype, proto, canonname, sa = res
try:
s = socket.socket(af, socktype, proto)
except socket.error, msg:
s = None
continue
try:
s.bind(sa)
s.listen(1)
except socket.error, msg:
s.close()
s = None
continue
break
if s is None:
print 'could not open socket'
sys.exit(1)
conn, addr = s.accept()
print 'Connected by', addr
while 1:
data = conn.recv(1024)
if not data: break
conn.send(data)
conn.close()
dhcppc1#
dhcppc1# uname -a
FreeBSD dhcppc1# 7.0-RC1 FreeBSD 7.0-RC1 #0 Mon Dec 24 12:18:24 UTC 2007
root at logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC o386
dhcppc1#
dhcppc1# python2.5 server.py
Traceback (most recent call last):
File "server.py", line 8 in <module>
for res in socket.getaddrinfo(HOST, PORT, socket.AF_UNSPEC,
socket.SOCK_STREAM, 0, socket.AI_PASSIVE):
socket.gaierror: (8, 'hostname nor servname provided, or not known')
dhcppc1#
----------
assignee: georg.brandl
components: Documentation
messages: 66244
nosy: georg.brandl, giampaolo.rodola
severity: normal
status: open
title: A socket example code shown in doc doesn't work on FreeBSD
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2763>
__________________________________
From report at bugs.python.org Mon May 5 00:35:05 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 04 May 2008 22:35:05 +0000
Subject: [New-bugs-announce] [issue2764] c_char doesn't implement py3k
buffer interface
In-Reply-To: <1209940505.31.0.9485811448.issue2764@psf.upfronthosting.co.za>
Message-ID: <1209940505.31.0.9485811448.issue2764@psf.upfronthosting.co.za>
New submission from Christian Heimes <lists at cheimes.de>:
I'm currently merging changes from trunk to 3.0. One unit test is failing:
test test_ctypes failed -- Traceback (most recent call last):
File "Lib/ctypes/test/test_frombuffer.py", line 67, in
test_from_buffer_copy
x = (c_char * 16).from_buffer_copy("a" * 16)
TypeError: expected an object with a buffer interface
----------
assignee: theller
components: ctypes
messages: 66252
nosy: christian.heimes, theller
priority: critical
severity: normal
status: open
title: c_char doesn't implement py3k buffer interface
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2764>
__________________________________
From report at bugs.python.org Mon May 5 00:38:16 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 04 May 2008 22:38:16 +0000
Subject: [New-bugs-announce] [issue2765] warnings: error in
test_missing_filename_main_with_argv_empty_string
In-Reply-To: <1209940696.14.0.256326344641.issue2765@psf.upfronthosting.co.za>
Message-ID: <1209940696.14.0.256326344641.issue2765@psf.upfronthosting.co.za>
New submission from Christian Heimes <lists at cheimes.de>:
I'm currently merging code from the trunk into 3.0. One warnings test is
failing:
test test_warnings failed -- Traceback (most recent call last):
File "/home/heimes/dev/python/py3k/Lib/test/test_warnings.py", line
296, in test_missing_filename_main_with_argv_empty_stringt
self.assertEqual(w.filename, '__main__')
AssertionError: b'__main__' != '__main__'
----------
assignee: brett.cannon
components: Extension Modules
messages: 66254
nosy: brett.cannon, christian.heimes
priority: critical
severity: normal
status: open
title: warnings: error in test_missing_filename_main_with_argv_empty_string
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2765>
__________________________________
From report at bugs.python.org Mon May 5 08:48:31 2008
From: report at bugs.python.org (Dieter Maurer)
Date: Mon, 05 May 2008 06:48:31 +0000
Subject: [New-bugs-announce] [issue2766] Doubtfull code in
'doctest.DocTestSuite'
In-Reply-To: <1209970110.99.0.739838799558.issue2766@psf.upfronthosting.co.za>
Message-ID: <1209970110.99.0.739838799558.issue2766@psf.upfronthosting.co.za>
New submission from Dieter Maurer <dieter at handshake.de>:
"doctest.DocTestSuite" has parameter "globs=None".
It uses "globs" in the call to "test_finder.call".
After this use, it potentually modifies "globs" but no longer uses it.
Either the "globs" modification is irrelevant (then it should be removed)
or it should happen before the "test_finder.find" call.
----------
components: Library (Lib)
messages: 66259
nosy: dmaurer
severity: normal
status: open
title: Doubtfull code in 'doctest.DocTestSuite'
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2766>
__________________________________
From report at bugs.python.org Mon May 5 11:32:26 2008
From: report at bugs.python.org (Dieter Maurer)
Date: Mon, 05 May 2008 09:32:26 +0000
Subject: [New-bugs-announce] [issue2767] "doctest.DocTestCase.debug" clears
"test.globs" too early
In-Reply-To: <1209979946.64.0.074102110802.issue2767@psf.upfronthosting.co.za>
Message-ID: <1209979946.64.0.074102110802.issue2767@psf.upfronthosting.co.za>
New submission from Dieter Maurer <dieter at handshake.de>:
"doctest.DocTestCase.debug" calls "DebugRunner.run" without
"clear_globs=False". As a consequence, already the runner clears
"test.globs" and it is no longer available to "tearDown" (where
is it cleared again).
----------
components: Library (Lib)
messages: 66262
nosy: dmaurer
severity: normal
status: open
title: "doctest.DocTestCase.debug" clears "test.globs" too early
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2767>
__________________________________
From report at bugs.python.org Mon May 5 13:27:46 2008
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 05 May 2008 11:27:46 +0000
Subject: [New-bugs-announce] [issue2768] os.fstat and other os.f* methods
should use PyObject_AsFileDescriptor
In-Reply-To: <1209986866.69.0.462896858511.issue2768@psf.upfronthosting.co.za>
Message-ID: <1209986866.69.0.462896858511.issue2768@psf.upfronthosting.co.za>
New submission from Christian Heimes <lists at cheimes.de>:
os.fstat doesn't accept a file object with a fileno() method. This can
easily be fixed by using PyObject_AsFileDescriptor(). Other os.f*
methods may suffer from the same issue.
----------
components: Extension Modules
keywords: easy
messages: 66266
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: os.fstat and other os.f* methods should use PyObject_AsFileDescriptor
type: feature request
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2768>
__________________________________
From report at bugs.python.org Mon May 5 15:27:58 2008
From: report at bugs.python.org (Quentin Gallet-Gilles)
Date: Mon, 05 May 2008 13:27:58 +0000
Subject: [New-bugs-announce] [issue2769] Small typo in whatsnew/2.6.rst
In-Reply-To: <1209994077.95.0.123254037587.issue2769@psf.upfronthosting.co.za>
Message-ID: <1209994077.95.0.123254037587.issue2769@psf.upfronthosting.co.za>
New submission from Quentin Gallet-Gilles <qgallet at gmail.com>:
In the "What's new" documentation for 2.6, a code marker is missing in
the paragraph about itertools.permutations.
Attached patch corrects this.
----------
assignee: georg.brandl
components: Documentation
files: whatsnew_2.6.patch
keywords: patch
messages: 66268
nosy: georg.brandl, quentin.gallet-gilles
severity: normal
status: open
title: Small typo in whatsnew/2.6.rst
versions: Python 2.6
Added file: http://bugs.python.org/file10197/whatsnew_2.6.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2769>
__________________________________
From report at bugs.python.org Mon May 5 16:06:39 2008
From: report at bugs.python.org (Augie Fackler)
Date: Mon, 05 May 2008 14:06:39 +0000
Subject: [New-bugs-announce] [issue2770] Subversion 1.5 Working Copies Break
Setuptools
In-Reply-To: <1209996399.45.0.153432540456.issue2770@psf.upfronthosting.co.za>
Message-ID: <1209996399.45.0.153432540456.issue2770@psf.upfronthosting.co.za>
New submission from Augie Fackler <lists at durin42.com>:
Subversion 1.5 adds some fields to the entries file in the working copy
administrative area. As a result of this, the way in which setuptools
checks the entries files results in a raised exception. Having read the
spec for the entries file, the issue can be fixed simply by looking for
version 8 or version 9 in the opening of the entries file. I've attached a
patch that does this. I've tested it extensively locally (been using it
for months).
----------
components: Distutils
files: setuptools_patch.txt
messages: 66271
nosy: durin42
severity: normal
status: open
title: Subversion 1.5 Working Copies Break Setuptools
versions: Python 2.5
Added file: http://bugs.python.org/file10198/setuptools_patch.txt
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2770>
__________________________________
From report at bugs.python.org Mon May 5 18:40:46 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 05 May 2008 16:40:46 +0000
Subject: [New-bugs-announce] [issue2771] test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
New submission from Guido van Rossum <guido at python.org>:
This is a very long line. I am wondering how it will be wrapped. What
will happen to this exceedingly long line? Will it be wrapped? Will it?
Really? What will happen?
Here's an example:
def fact(n):
if n > 1:
return n * fact(n-1)
else:
assert n in (0, 1)
return 1
What do you think of that?
----------
messages: 66272
nosy: gvanrossum
severity: normal
status: open
title: test issue
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
__________________________________
From report at bugs.python.org Tue May 6 16:14:11 2008
From: report at bugs.python.org (Eric Smith)
Date: Tue, 06 May 2008 14:14:11 +0000
Subject: [New-bugs-announce] [issue2772] Add PendingDeprecationWarning for %
formatting
In-Reply-To: <1210083250.98.0.889504486731.issue2772@psf.upfronthosting.co.za>
Message-ID: <1210083250.98.0.889504486731.issue2772@psf.upfronthosting.co.za>
New submission from Eric Smith <eric at trueblade.com>:
Per http://mail.python.org/pipermail/python-3000/2008-April/013094.html,
add a PendingDeprecationWarning to 3.0 for % formatting.
The attached patch implements this for 3.0. For 2.6, it should only be
a PendingDeprecationWarning if -3 warnings are turned on. I'll work on
that after the 3.0 patch is accepted.
I'm not wild about using a global variable to disallow recursion, but
it's probably the way to go. Question: Do I need to acquire the GIL here?
Another issue is that the interpreter should probably at least start up
without triggering these warnings. I'll add an issue for that at a
later date.
----------
assignee: eric.smith
components: Interpreter Core
files: percent_formatting_pending_deprecation.diff
keywords: easy, patch, patch
messages: 66313
nosy: eric.smith
priority: normal
severity: normal
status: open
title: Add PendingDeprecationWarning for % formatting
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10202/percent_formatting_pending_deprecation.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2772>
__________________________________
From report at bugs.python.org Tue May 6 18:28:46 2008
From: report at bugs.python.org (=?utf-8?q?Artur_Zaprza=C5=82a?=)
Date: Tue, 06 May 2008 16:28:46 +0000
Subject: [New-bugs-announce] [issue2773] Wrong description of 'g' conversion
type of string formatting operator %
In-Reply-To: <1210091326.8.0.357572062479.issue2773@psf.upfronthosting.co.za>
Message-ID: <1210091326.8.0.357572062479.issue2773@psf.upfronthosting.co.za>
New submission from Artur Zaprza?a <arturz at ownmail.net>:
Description of 'g' and 'G' conversion types of string formatting
operator at http://www.python.org/doc/2.5.2/lib/typesseq-strings.html is:
Floating point format. Uses exponential format if exponent is greater
than -4 or less than precision, decimal format otherwise.
Should be:
Floating point format. Uses exponential format if exponent is less
than -4 or not less than precision, decimal format otherwise.
----------
assignee: georg.brandl
components: Documentation
messages: 66318
nosy: georg.brandl, zybi
severity: normal
status: open
title: Wrong description of 'g' conversion type of string formatting operator %
versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2773>
__________________________________
From report at bugs.python.org Tue May 6 18:38:38 2008
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 06 May 2008 16:38:38 +0000
Subject: [New-bugs-announce] [issue2774] ctypes documentation not effective
In-Reply-To: <1210091918.21.0.990068864292.issue2774@psf.upfronthosting.co.za>
Message-ID: <1210091918.21.0.990068864292.issue2774@psf.upfronthosting.co.za>
New submission from Bill Janssen <bill.janssen at gmail.com>:
Once again I'm reading through the ctypes documentation and finding it
wildly confusing/contradictory. For instance, there's no discussion of
how ctypes types interact with malloc and free. The tutorial section is
discursive and rambling. The type "c_size_t" isn't mentioned in the
section labelled "Fundamental Data Types", but does show up in another
section also labelled "Fundamental Data Types". The "reference" doesn't
document the use of pointers or arrays. I find it hard to see how
anyone who doesn't read the ctypes code (several times) could find out
how to use it from the documentation.
I'd suggest getting rid of the Tutorial section, moving it to a
standalone document somewhere, and finishing the writing of the
Reference section. Adding a chapter discussing when to use ctypes and
when to use the C API might also be a good idea.
----------
assignee: georg.brandl
components: Documentation
messages: 66319
nosy: georg.brandl, janssen
priority: normal
severity: normal
status: open
title: ctypes documentation not effective
type: performance
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2774>
__________________________________
From report at bugs.python.org Tue May 6 20:11:09 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 06 May 2008 18:11:09 +0000
Subject: [New-bugs-announce] [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
This is to keep track of who is working on what for PEP 3108
(http://www.python.org/dev/peps/pep-3108/). Once something is complete it
should be denoted in the PEP itself, so always check the PEP to see what
is left to be done (for both 2.6 and 3.0).
----------
components: Library (Lib)
messages: 66326
nosy: brett.cannon
priority: critical
severity: normal
status: open
title: Implement PEP 3108
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
__________________________________
From report at bugs.python.org Tue May 6 23:30:16 2008
From: report at bugs.python.org (Ambarish Malpani)
Date: Tue, 06 May 2008 21:30:16 +0000
Subject: [New-bugs-announce] [issue2776] urllib2.urlopen() gets confused
with path with // in it
In-Reply-To: <1210109415.44.0.221361539235.issue2776@psf.upfronthosting.co.za>
Message-ID: <1210109415.44.0.221361539235.issue2776@psf.upfronthosting.co.za>
New submission from Ambarish Malpani <ambarish at yahoo.com>:
Try the following code:
import urllib
import urllib2
url =
'http://features.us.reuters.com//autos/news/95ED98EE-A837-11DC-BCB3-4F218271.html'
data = urllib.urlopen(url).read()
data2 = urllib2.urlopen(url).read()
The attempt to get it with urllib works fine. With urllib2, the request
is malformed and I get back a HTTP 404
Request in the 2nd case is:
GET //autos/news/95ED98EE-A837-11DC-BCB3-4F218271.html HTTP/1.1\r\n
Accept-Encoding: identity\r\n
Host: autos\r\n
Connection: close\r\n
....
The host line seems to be looking for the last // rather than the first.
----------
components: Extension Modules
messages: 66334
nosy: ambarish
severity: normal
status: open
title: urllib2.urlopen() gets confused with path with // in it
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2776>
__________________________________
From report at bugs.python.org Wed May 7 01:40:55 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 06 May 2008 23:40:55 +0000
Subject: [New-bugs-announce] [issue2777] subprocess unit tests for kill,
term and send_signal flaky
In-Reply-To: <1210117255.49.0.763796854564.issue2777@psf.upfronthosting.co.za>
Message-ID: <1210117255.49.0.763796854564.issue2777@psf.upfronthosting.co.za>
New submission from Christian Heimes <lists at cheimes.de>:
The unit tests for the kill, term and send_signal methods of the
subprocess.Popen object are still flaky and sometimes cause the test
suite to hang. I'm going to disable them for the upcoming alpha until
I've found a better solution.
----------
assignee: christian.heimes
components: Tests
messages: 66347
nosy: christian.heimes
priority: critical
severity: normal
status: open
title: subprocess unit tests for kill, term and send_signal flaky
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2777>
__________________________________
From report at bugs.python.org Wed May 7 04:19:32 2008
From: report at bugs.python.org (Adam Olsen)
Date: Wed, 07 May 2008 02:19:32 +0000
Subject: [New-bugs-announce] [issue2778] set_swap_bodies is unsafe
In-Reply-To: <1210126771.92.0.606864994525.issue2778@psf.upfronthosting.co.za>
Message-ID: <1210126771.92.0.606864994525.issue2778@psf.upfronthosting.co.za>
New submission from Adam Olsen <rhamph at gmail.com>:
set_swap_bodies() is used to cheaply create a frozenset from a set,
which is then used for lookups within a set. It does this by creating a
temporary empty frozenset, swapping its contents with the original set,
doing the lookup using the frozenset, then swapping the contents back
and releasing the temporary frozenset.
Unfortunately, the lookup can invoke arbitrary code, which may examine
the original set and find it empty (until the lookup completes). The
lookup may also save a reference to the temporary frozenset, which
mutates to being empty after the lookup completes.
The purpose seems to be allowing "someset in someotherset" to
automatically convert someset to a frozenset. A brief search didn't
reveal a rationale for this, and in fact PEP 218's history section
claims the opposite: "Auto-conversion between mutable and immutable sets
was dropped." Perhaps this is a forgotten vestige of that?
set_intersection_update uses set_swap_bodies for a different purpose and
it may be safe. It depends on whether subclasses of set may retain a
reference to the tmp set somehow.
----------
files: brokensetswap.py
messages: 66349
nosy: Rhamphoryncus
severity: normal
status: open
title: set_swap_bodies is unsafe
type: behavior
Added file: http://bugs.python.org/file10204/brokensetswap.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2778>
__________________________________
From report at bugs.python.org Wed May 7 13:58:44 2008
From: report at bugs.python.org (Tim Pietzcker)
Date: Wed, 07 May 2008 11:58:44 +0000
Subject: [New-bugs-announce] [issue2779] Python 3.0a4 crashes on script in a
path with non-ASCII characters (Windows)
In-Reply-To: <1210161524.54.0.447554475094.issue2779@psf.upfronthosting.co.za>
Message-ID: <1210161524.54.0.447554475094.issue2779@psf.upfronthosting.co.za>
New submission from Tim Pietzcker <tim.pietzcker at web.de>:
When I try to run a script that is contained in a directory whose path
contains non-ASCII characters (e. g. Umlauts), Python 3.0a4 crashes with
the following error message:
(Windows cmd console):
E:\Eigene Dateien\Klinikum\Qualit?tsmanagement\Qualit?tsbericht
2007>c:\programme\python30\python zaehle_aerzte.py
Fatal Python error: no mem for sys.path insertion
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 33-35:
invalid data
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
Moving the script to a directory without Umlauts in the path "solves"
the problem
----------
components: Windows
messages: 66354
nosy: pietzcker
severity: normal
status: open
title: Python 3.0a4 crashes on script in a path with non-ASCII characters (Windows)
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2779>
__________________________________
From report at bugs.python.org Wed May 7 13:59:08 2008
From: report at bugs.python.org (Tim Pietzcker)
Date: Wed, 07 May 2008 11:59:08 +0000
Subject: [New-bugs-announce] [issue2780] Python 3.0a4 crashes on script in a
path with non-ASCII characters (Windows)
In-Reply-To: <1210161548.39.0.205186069105.issue2780@psf.upfronthosting.co.za>
Message-ID: <1210161548.39.0.205186069105.issue2780@psf.upfronthosting.co.za>
New submission from Tim Pietzcker <tim.pietzcker at web.de>:
Apologies if this has been reported before; I couldn#T find it on a
search but maybe I used the wrong search terms.
When I try to run a script that is contained in a directory whose path
contains non-ASCII characters (e. g. Umlauts), Python 3.0a4 crashes with
the following error message:
(Windows cmd console):
E:\Eigene Dateien\Klinikum\Qualit?tsmanagement\Qualit?tsbericht
2007>c:\programme\python30\python zaehle_aerzte.py
Fatal Python error: no mem for sys.path insertion
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 33-35:
invalid data
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
Moving the script to a directory without Umlauts in the path "solves"
the problem.
Best regards,
Tim
----------
components: Windows
messages: 66355
nosy: pietzcker
severity: normal
status: open
title: Python 3.0a4 crashes on script in a path with non-ASCII characters (Windows)
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2780>
__________________________________
From report at bugs.python.org Wed May 7 16:35:13 2008
From: report at bugs.python.org (Tim Golden)
Date: Wed, 07 May 2008 14:35:13 +0000
Subject: [New-bugs-announce] [issue2781] Tiny patch to _winreg docs
In-Reply-To: <1210170913.28.0.4675266514.issue2781@psf.upfronthosting.co.za>
Message-ID: <1210170913.28.0.4675266514.issue2781@psf.upfronthosting.co.za>
New submission from Tim Golden <mail at timgolden.me.uk>:
The docs for _winreg refer to RegLoadKey, which is the underlying API.
The function is actually exposed as LoadKey. Patch attached.
----------
assignee: georg.brandl
components: Documentation
files: _winreg.patch
keywords: patch
messages: 66359
nosy: georg.brandl, tim.golden
severity: normal
status: open
title: Tiny patch to _winreg docs
versions: Python 2.6
Added file: http://bugs.python.org/file10207/_winreg.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2781>
__________________________________
From report at bugs.python.org Wed May 7 16:45:43 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Wed, 07 May 2008 14:45:43 +0000
Subject: [New-bugs-announce] [issue2782] datetime/date strftime() method and
time.strftime() inconsistency
In-Reply-To: <1210171543.31.0.364893974178.issue2782@psf.upfronthosting.co.za>
Message-ID: <1210171543.31.0.364893974178.issue2782@psf.upfronthosting.co.za>
New submission from Andrii V. Mishkovskyi <mishok13 at gmail.com>:
datetime and date strftime() method does additional check on input
format, thus being completely different from time's module
time.strftime() method behavior.
There are two ways to fix this:
1. Add an explicit note about this behavior (e.g., "only 'str' objects
are allowed for format strings") in docs (section 5.1.7).
2. Allow 'unicode' objects for format strings (backport time.strftime()
from 3.0?).
Here is a traceback for a more complete overview:
Python 2.6a2+ (trunk:62762, May 6 2008, 14:37:27)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import datetime, date
>>> import time
>>> uformat = u'%Y-%m-%D %H-%M-%S'
>>> format = '%Y-%m-%D %H-%M-%S'
>>> datetime.today().strftime(uformat)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: strftime() argument 1 must be str, not unicode
>>> datetime.today().strftime(format)
'2008-05-05/07/08 17-19-03'
>>> time.strftime(uformat)
'2008-05-05/07/08 17-19-10'
>>> time.strftime(format)
'2008-05-05/07/08 17-19-16'
>>> date.today()
datetime.date(2008, 5, 7)
>>> date.today().strftime(format)
'2008-05-05/07/08 00-00-00'
>>> date.today().strftime(uformat)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: strftime() argument 1 must be str, not unicode
----------
components: Library (Lib)
messages: 66360
nosy: mishok13
severity: normal
status: open
title: datetime/date strftime() method and time.strftime() inconsistency
type: behavior
versions: Python 2.5, Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2782>
__________________________________
From report at bugs.python.org Wed May 7 18:47:15 2008
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 07 May 2008 16:47:15 +0000
Subject: [New-bugs-announce] [issue2783] ctypes.util.find_library() doesn't
find OS X .bundle or .so libraries
In-Reply-To: <1210178835.82.0.184035684731.issue2783@psf.upfronthosting.co.za>
Message-ID: <1210178835.82.0.184035684731.issue2783@psf.upfronthosting.co.za>
New submission from Bill Janssen <bill.janssen at gmail.com>:
On OS X, dynamically loadable libraries come in several flavors:
.bundle (or, often, .so) a standard dynamically loadable module; .dylib,
a dynamically loadable module that is also a library that can be linked
against like a .a file; .framework, a collection of modules similar to a
Python package. find_library() currently looks for .dylib and
.framework libraries, but not for .bundle or .so libraries.
----------
assignee: theller
components: Library (Lib)
keywords: easy
messages: 66362
nosy: janssen, theller
priority: normal
severity: normal
status: open
title: ctypes.util.find_library() doesn't find OS X .bundle or .so libraries
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2783>
__________________________________
From report at bugs.python.org Wed May 7 21:45:39 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Wed, 07 May 2008 19:45:39 +0000
Subject: [New-bugs-announce] [issue2784] fast builtin sum may leak
In-Reply-To: <1210189539.52.0.670446684288.issue2784@psf.upfronthosting.co.za>
Message-ID: <1210189539.52.0.670446684288.issue2784@psf.upfronthosting.co.za>
New submission from Jean Brouwers <MrJean1 at Gmail.com>:
The new, fast builtin sum implementation may cause a memory leak in the
float loop. Both lines
PyFPE_START_PROTECT("add", return 0)
should be changed to
PyFPE_START_PROTECT("add", Py_DECREF(item); Py_DECREF(iter); return
0)
The attached file bltinmodule1.c.diff contain a patch to that extent.
/Jean Brouwers
----------
components: Interpreter Core
files: bltinmodule1.c.diff
keywords: patch
messages: 66368
nosy: MrJean1
severity: normal
status: open
title: fast builtin sum may leak
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file10209/bltinmodule1.c.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2784>
__________________________________
From report at bugs.python.org Wed May 7 21:53:43 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Wed, 07 May 2008 19:53:43 +0000
Subject: [New-bugs-announce] [issue2785] alternate fast builtin sum
In-Reply-To: <1210190023.19.0.40382803719.issue2785@psf.upfronthosting.co.za>
Message-ID: <1210190023.19.0.40382803719.issue2785@psf.upfronthosting.co.za>
New submission from Jean Brouwers <MrJean1 at Gmail.com>:
The attached patch bltmodule2.c.diff is a different implementation of
the fast summation code for your consideration.
It uses three separate sums to add ints, floats and other objects. All
ints are accumulated into a C long, reset even after overflow. All
floats are added into a C double without mixing ints. Other objects are
handled as before.
This version has been tested with Python 2.5.2 as well and passed the
existing regressions.
/Jean Brouwers
----------
components: Interpreter Core
files: bltinmodule2.c.diff
keywords: patch
messages: 66369
nosy: MrJean1
severity: normal
status: open
title: alternate fast builtin sum
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file10210/bltinmodule2.c.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2785>
__________________________________
From report at bugs.python.org Wed May 7 22:25:58 2008
From: report at bugs.python.org (Matthias Urlichs)
Date: Wed, 07 May 2008 20:25:58 +0000
Subject: [New-bugs-announce] [issue2786] Names in traceback should have
class names, if they're methods
In-Reply-To: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za>
Message-ID: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za>
New submission from Matthias Urlichs <smurf at smurf.noris.de>:
Consider this simple error:
>>> class foo(object):
... def __init__(self,bar):
... pass
...
>>> foo()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: __init__() takes exactly 2 positional arguments (1 given)
>>>
The problem is that if that "foo" call is through a variable (or
anything else that obscures which class I'm actually calling) there's no
good way to figure this from the traceback.
The last line should read
TypeError: foo.__init__() takes exactly 2 positional arguments (1 given)
or similar.
----------
messages: 66373
nosy: smurfix
severity: normal
status: open
title: Names in traceback should have class names, if they're methods
type: behavior
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2786>
__________________________________
From report at bugs.python.org Wed May 7 23:27:26 2008
From: report at bugs.python.org (Adam Olsen)
Date: Wed, 07 May 2008 21:27:26 +0000
Subject: [New-bugs-announce] [issue2787] Patch to flush unittest output
In-Reply-To: <1210195645.66.0.390222470388.issue2787@psf.upfronthosting.co.za>
Message-ID: <1210195645.66.0.390222470388.issue2787@psf.upfronthosting.co.za>
New submission from Adam Olsen <rhamph at gmail.com>:
In 3.0, unittest's output has become line buffered. Instead of printing
the test name when it starts a test, then "ok" when it finishes, the
test name is delayed until the "ok" is printed. This makes it
unnecessarily hard to determine which test is hanging or segfaulted.
The attached patch adds explicit flushes.
An alternative approach would be to force stdout to be unbuffered
somehow. I don't know how difficult that would be.
----------
files: python-unittest_flush.diff
keywords: patch
messages: 66375
nosy: Rhamphoryncus
severity: normal
status: open
title: Patch to flush unittest output
versions: Python 3.0
Added file: http://bugs.python.org/file10211/python-unittest_flush.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2787>
__________________________________
From report at bugs.python.org Thu May 8 00:07:35 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 May 2008 22:07:35 +0000
Subject: [New-bugs-announce] [issue2788] ignore file for Mercurial
In-Reply-To: <1210198055.49.0.340334928408.issue2788@psf.upfronthosting.co.za>
Message-ID: <1210198055.49.0.340334928408.issue2788@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
Here is an .hgignore file to put in the base directory of both the trunk
and the py3k branch.
----------
components: Build
files: .hgignore
messages: 66377
nosy: pitrou
severity: normal
status: open
title: ignore file for Mercurial
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10212/.hgignore
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2788>
__________________________________
From report at bugs.python.org Thu May 8 06:17:17 2008
From: report at bugs.python.org (Alexandr Zamaraev)
Date: Thu, 08 May 2008 04:17:17 +0000
Subject: [New-bugs-announce] [issue2789] Comparsion datetime objects with
None
In-Reply-To: <1210220237.26.0.0391645804782.issue2789@psf.upfronthosting.co.za>
Message-ID: <1210220237.26.0.0391645804782.issue2789@psf.upfronthosting.co.za>
New submission from Alexandr Zamaraev <shura_zam at users.sourceforge.net>:
When comparing any standard objects with None returned True or False.
When comparing the object of the module datetime with None raised
exception TypeError.
Example Python session:
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.
>>> import datetime as dt
>>> import decimal as dc
>>> None == 1
False
>>> None == "s"
False
>>> None == [1, 2, 3]
False
>>> None == (1, 2, 3)
False
>>> None == dc.Decimal()
False
>>> None == dt.date.today()
False
>>> None == dt.datetime.today()
False
>>> None == dt.time()
False
>>> None == dt.timedelta()
False
>>> None < 1
True
>>> None < "s"
True
>>> None < [1, 2, 3]
True
>>> None < (1, 2, 3)
True
>>> None < dc.Decimal()
True
>>> None < dt.date.today()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: can't compare datetime.date to NoneType
>>> None < dt.datetime.today()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: can't compare datetime.datetime to NoneType
>>> None < dt.time()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: can't compare datetime.time to NoneType
>>> None < dt.timedelta()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: can't compare datetime.timedelta to NoneType
----------
components: Library (Lib)
files: datetimemodule.diff
keywords: patch
messages: 66402
nosy: shura_zam
severity: normal
status: open
title: Comparsion datetime objects with None
versions: Python 2.5
Added file: http://bugs.python.org/file10219/datetimemodule.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2789>
__________________________________
From report at bugs.python.org Thu May 8 12:20:00 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Thu, 08 May 2008 10:20:00 +0000
Subject: [New-bugs-announce] [issue2790] sys.flags is missing bytes_warning
In-Reply-To: <1210242000.56.0.446699742835.issue2790@psf.upfronthosting.co.za>
Message-ID: <1210242000.56.0.446699742835.issue2790@psf.upfronthosting.co.za>
New submission from Ralf Schmitt <schmir at gmail.com>:
sys.flags is missing bytes_warning:
Python 2.6a2+ (trunk, May 8 2008, 12:09:50)
[GCC 4.2.3 (Debian 4.2.3-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> sys.flags
sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0,
inspect=0, interactive=0, optimize=0, dont_write_bytecode=0,
no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0,
unicode=0)
This is only used from warnings.py currently:
~/pydev/trunk/ ack bytes_warning
Lib/warnings.py
311: bytes_warning = sys.flags.bytes_warning
312: if bytes_warning > 1:
314: elif bytes_warning:
Python/sysmodule.c
1172: {"bytes_warning", "-b"},
(I only see an attribute error in frozen programs).
The attached patch fixes it by not using the sizeof operator to compute
the size of the array.
This gives:
>>> sys.flags
sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0,
inspect=0, interactive=0, optimize=0, dont_write_bytecode=0,
no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0,
unicode=0, bytes_warning=0)
----------
files: bytes_warning.patch
keywords: patch
messages: 66411
nosy: schmir
severity: normal
status: open
title: sys.flags is missing bytes_warning
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file10220/bytes_warning.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2790>
__________________________________
From report at bugs.python.org Thu May 8 14:22:45 2008
From: report at bugs.python.org (Joel Rosdahl)
Date: Thu, 08 May 2008 12:22:45 +0000
Subject: [New-bugs-announce] [issue2791] subprocess.py leaks fd in
communicate
In-Reply-To: <1210249364.92.0.977353677692.issue2791@psf.upfronthosting.co.za>
Message-ID: <1210249364.92.0.977353677692.issue2791@psf.upfronthosting.co.za>
New submission from Joel Rosdahl <python-bugs at joel.rosdahl.net>:
The optimization in SVN rev 38556 seems to have changed
Popen.communicate's behavior when stdout is subprocess.PIPE (and maybe
for other cases as well).
See the attached file. In Python 2.4.5, all three counts are the same.
In Python 2.5.2, the middle count has increased by 1. In other words: A
file descriptor is leaked until the last reference to the Popen instance
is dropped.
----------
components: Library (Lib)
files: subprocess-fd-problem.py
messages: 66415
nosy: jrosdahl
severity: normal
status: open
title: subprocess.py leaks fd in communicate
type: resource usage
versions: Python 2.5
Added file: http://bugs.python.org/file10221/subprocess-fd-problem.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2791>
__________________________________
From report at bugs.python.org Thu May 8 21:53:20 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Thu, 08 May 2008 19:53:20 +0000
Subject: [New-bugs-announce] [issue2792] alternate fast builtin sum, rev'd
In-Reply-To: <1210276400.51.0.762850955818.issue2792@psf.upfronthosting.co.za>
Message-ID: <1210276400.51.0.762850955818.issue2792@psf.upfronthosting.co.za>
New submission from Jean Brouwers <MrJean1 at Gmail.com>:
Here is one more, final attempt to improve fast summation, somewhat.
This version inspects the type of both the sum and the first item and
adds all ints and floats without any PyNumber_Add() call and in order.
Also, the results for this test case are compatible:
>>> d = [1000000000000000, -1000000000000000.0, .0000000000000001,
.0000000000000001]
>>> sum(d)
2e-16
>>> d[0] + sum(d[1:])
0.0
/Jean Brouwers
----------
components: Interpreter Core
files: bltinmodule3.c.diff
keywords: patch
messages: 66434
nosy: MrJean1
severity: normal
status: open
title: alternate fast builtin sum, rev'd
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file10223/bltinmodule3.c.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2792>
__________________________________
From report at bugs.python.org Thu May 8 22:02:45 2008
From: report at bugs.python.org (James Nadir)
Date: Thu, 08 May 2008 20:02:45 +0000
Subject: [New-bugs-announce] [issue2793] Dictionary fails to index when
adding list when in a deeply nested loop
In-Reply-To: <1210276965.56.0.576720171368.issue2793@psf.upfronthosting.co.za>
Message-ID: <1210276965.56.0.576720171368.issue2793@psf.upfronthosting.co.za>
New submission from James Nadir <jnadir at ix.netcom.com>:
Python fails to correctly add 'lists' into a 'dictionary' in nested
loop. The attached py file has two examples; the first is the failing
example, the seond is the passing example.
This might be a known issue. If so, please accept my apologies, I
couldn't find it. Or it could be operator error. Again, my apolgies if
it is.
----------
files: play parser.py
messages: 66436
nosy: jreadon
severity: normal
status: open
title: Dictionary fails to index when adding list when in a deeply nested loop
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10224/play parser.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2793>
__________________________________
From report at bugs.python.org Thu May 8 22:11:26 2008
From: report at bugs.python.org (Ali Afshar)
Date: Thu, 08 May 2008 20:11:26 +0000
Subject: [New-bugs-announce] [issue2794] Figure directive not handled for
latex writing in Sphinx
In-Reply-To: <1210277486.1.0.0867984749288.issue2794@psf.upfronthosting.co.za>
Message-ID: <1210277486.1.0.0867984749288.issue2794@psf.upfronthosting.co.za>
New submission from Ali Afshar <aafshar at gmail.com>:
.. figure:: directive is not handled when writing to latex, and this
directive seems the only way to have a captioned image in rst.
I have added a patch that simply handles the figure, and captions.
Note that figures have an additional component of "legends" but I can't
seem to work out what these are.
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: latex-figure.diff
keywords: patch
messages: 66437
nosy: aafshar, georg.brandl
severity: normal
status: open
title: Figure directive not handled for latex writing in Sphinx
versions: Python 2.5
Added file: http://bugs.python.org/file10225/latex-figure.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2794>
__________________________________
From report at bugs.python.org Fri May 9 02:31:54 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 09 May 2008 00:31:54 +0000
Subject: [New-bugs-announce] [issue2795] rename "Caveat" to "Warning"
In-Reply-To: <1210293113.69.0.486539736073.issue2795@psf.upfronthosting.co.za>
Message-ID: <1210293113.69.0.486539736073.issue2795@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
The reST directive "warning" gives a orange box with "Caveat" in bold
letters. I think this makes assumptions about the contents of the box
(Warning is broader than caveat). Could it be changed to just "Warning?"
----------
assignee: georg.brandl
components: Documentation
messages: 66450
nosy: benjamin.peterson, georg.brandl
priority: low
severity: normal
status: open
title: rename "Caveat" to "Warning"
type: feature request
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2795>
__________________________________
From report at bugs.python.org Fri May 9 09:07:58 2008
From: report at bugs.python.org (Hasso Tepper)
Date: Fri, 09 May 2008 07:07:58 +0000
Subject: [New-bugs-announce] [issue2796] Build issues in DragonFly BSD
In-Reply-To: <1210316878.4.0.717885872695.issue2796@psf.upfronthosting.co.za>
Message-ID: <1210316878.4.0.717885872695.issue2796@psf.upfronthosting.co.za>
New submission from Hasso Tepper <hasso at estpak.ee>:
The attached patch fixes obvious problems with build in DragonFly BSD
platform.
Modules/socketmodule.c part adds NetBSD to the blacklist as well -
both OS'es use the same Bluetooth stack. Although the code seems to
have support for NetBSD stack, the code is stub and it doesn't build.
----------
components: Build
files: dragonfly-python25.patch
keywords: patch
messages: 66457
nosy: hasso
severity: normal
status: open
title: Build issues in DragonFly BSD
type: compile error
versions: Python 2.5
Added file: http://bugs.python.org/file10227/dragonfly-python25.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2796>
__________________________________
From report at bugs.python.org Fri May 9 09:51:46 2008
From: report at bugs.python.org (Hasso Tepper)
Date: Fri, 09 May 2008 07:51:46 +0000
Subject: [New-bugs-announce] [issue2797] Trunk build issues in DragonFly BSD
In-Reply-To: <1210319505.91.0.659015772153.issue2797@psf.upfronthosting.co.za>
Message-ID: <1210319505.91.0.659015772153.issue2797@psf.upfronthosting.co.za>
New submission from Hasso Tepper <hasso at estpak.ee>:
The attached patch fixes trunk build problems in DragonFly BSD.
It's trunk version of the issue #2796, but adds one (not DragonFly
specific) fix to the Modules/mmapmodule.c - in case of
(!HAVE_SYSCONF || !_SC_PAGESIZE) my_getallocationgranularity will not
be defined.
----------
components: Build
files: dragonfly-python-trunk.patch
keywords: patch
messages: 66458
nosy: hasso
severity: normal
status: open
title: Trunk build issues in DragonFly BSD
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file10229/dragonfly-python-trunk.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2797>
__________________________________
From report at bugs.python.org Fri May 9 12:05:00 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 May 2008 10:05:00 +0000
Subject: [New-bugs-announce] [issue2798] Crash on non-Windows if Python runs
from a non-ASCII directory
In-Reply-To: <1210327500.09.0.609692873362.issue2798@psf.upfronthosting.co.za>
Message-ID: <1210327500.09.0.609692873362.issue2798@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
(Note: I'm splitting this from #1342 because the fix is much simpler in
the non-Windows case)
py3k does not accept running from a path with non-ascii characters.
$ pwd
/home/antoine/py3k/h?h?
$ ./python
Fatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
File "/home/antoine/py3k/pristine/Lib/encodings/__init__.py", line 32,
in <module>
TypeError: zipimporter() argument 1 must be string without null bytes,
not str
Abandon
The following patch solves the problem by fixing a bug in getargs.c
where the "no null bytes" check for non-ASCII strings was wrong.
There is still a failing test, test_xmlrpc, apparently because xmlrpc
wants to output its path in an HTTP header using the "ascii" encoding...
I'd say this is an xmlrpc issue and not an issue with the patch.
----------
components: Interpreter Core
files: getargs.patch
keywords: patch
messages: 66461
nosy: christian.heimes, pitrou
severity: normal
status: open
title: Crash on non-Windows if Python runs from a non-ASCII directory
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file10230/getargs.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2798>
__________________________________
From report at bugs.python.org Fri May 9 12:31:52 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 09 May 2008 10:31:52 +0000
Subject: [New-bugs-announce] [issue2799] Remove PyUnicode_AsString(),
rework PyUnicode_AsStringAndSize(), add PyUnicode_AsChar()
In-Reply-To: <1210329112.66.0.505096173761.issue2799@psf.upfronthosting.co.za>
Message-ID: <1210329112.66.0.505096173761.issue2799@psf.upfronthosting.co.za>
New submission from Marc-Andre Lemburg <mal at egenix.com>:
The API PyUnicode_AsString() is pretty useless by itself - there's
no way to access the size information of the returned string without
again going to the Unicode object.
I'd suggest to remove the API altogether and not only deprecating it.
Furthermore, the API PyUnicode_AsStringAndSize() does not follow the API
signature of PyString_AsStringAndSize() in that it passes back the
pointer to the string as output parameter. That should be changed as
well. Note that PyString_AsStringAndSize() already does this for both
8-bit strings and Unicode, so the special Unicode API is not really
needed at all or you may want to rename PyString_AsStringAndSize() to
PyUnicode_AsStringAndSize().
Finally, since there are many cases where the string buffer contents are
copied to a new buffer, it's probably worthwhile to add a new API which
does the copying straight away and also deals with the overflow cases in
a central place. I'd suggest PyUnicode_AsChar() (with an API like
PyUnicode_AsWideChar()).
(this was taken from a comment on #1950)
----------
components: Unicode
messages: 66463
nosy: lemburg
severity: normal
status: open
title: Remove PyUnicode_AsString(), rework PyUnicode_AsStringAndSize(), add PyUnicode_AsChar()
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2799>
__________________________________
From report at bugs.python.org Fri May 9 13:24:16 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 09 May 2008 11:24:16 +0000
Subject: [New-bugs-announce] [issue2800] make htmlhelp creates
python30a5.chm but msi.py expects pydoc.chm
In-Reply-To: <1210332256.72.0.89374241257.issue2800@psf.upfronthosting.co.za>
Message-ID: <1210332256.72.0.89374241257.issue2800@psf.upfronthosting.co.za>
New submission from Christian Heimes <lists at cheimes.de>:
The sphinx tool chain now creates the htmlhelp files as python30a5.* but
the MSI installer packages expects pydoc.chm. Either msi.py or the doc
tool chain must be altered.
By the way Martin:
Should the RM set snapshot to 0 in Tools/msi/msi.py before tagging a
release?
----------
assignee: georg.brandl
components: Windows
messages: 66464
nosy: christian.heimes, georg.brandl, loewis
priority: high
severity: normal
status: open
title: make htmlhelp creates python30a5.chm but msi.py expects pydoc.chm
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2800>
__________________________________
From report at bugs.python.org Fri May 9 13:28:51 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Fri, 09 May 2008 11:28:51 +0000
Subject: [New-bugs-announce] [issue2801] Py30a5 float.is_integer() raises
ValueError
In-Reply-To: <1210332530.82.0.122312238822.issue2801@psf.upfronthosting.co.za>
Message-ID: <1210332530.82.0.122312238822.issue2801@psf.upfronthosting.co.za>
New submission from Mark Summerfield <mark at qtrac.eu>:
The new method float.is_integer() introduced in Py30a5 behaves unexpectedly:
>>> x = 5.0
>>> x.as_integer_ratio()
(5, 1)
>>> x.is_integer()
Traceback (most recent call last):
File "<pyshell#20>", line 1, in <module>
x.is_integer()
ValueError: (11, 'Resource temporarily unavailable')
I was expecting True.
----------
messages: 66465
nosy: mark
severity: normal
status: open
title: Py30a5 float.is_integer() raises ValueError
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2801>
__________________________________
From report at bugs.python.org Fri May 9 16:08:08 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Fri, 09 May 2008 14:08:08 +0000
Subject: [New-bugs-announce] [issue2802] str.format() :n integer output
In-Reply-To: <1210342088.28.0.24987613161.issue2802@psf.upfronthosting.co.za>
Message-ID: <1210342088.28.0.24987613161.issue2802@psf.upfronthosting.co.za>
New submission from Mark Summerfield <mark at qtrac.eu>:
In Py30a5 the 'n' format option is not v. useful for integers:
>>> for x in range(8):
print("{0:n} ".format(10**x), end="")
1 10 100 1,000 10,000 100,000 1e+06 1e+07
This is because it behaves like g once a number grows large. That makes
sense for floats, but since Python has unlimited size integers there is
currently no built-in way to get, 10**6 to output as 1,000,000 (or using
whatever the user's locale-dependent separator is). (It is easy to write
a suitable function for this, but it just seems that n is a bit of a
teaser in this regard.)
I think that n should stay the same for floats, but for integers should
never switch to g, but just use as many separators as needed.
----------
messages: 66471
nosy: mark
severity: normal
status: open
title: str.format() :n integer output
type: feature request
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2802>
__________________________________
From report at bugs.python.org Fri May 9 17:27:04 2008
From: report at bugs.python.org (Matt Harden)
Date: Fri, 09 May 2008 15:27:04 +0000
Subject: [New-bugs-announce] [issue2803] heapq.heappush called with too few
arguments in sched.py
In-Reply-To: <1210346823.98.0.261501835489.issue2803@psf.upfronthosting.co.za>
Message-ID: <1210346823.98.0.261501835489.issue2803@psf.upfronthosting.co.za>
New submission from Matt Harden <mthard at monsanto.com>:
In the method scheduler.run in the sched module, heapq.heappush is
called with single argument (event). It's a two argument function. The
correct call would be heapq.heappush(q, event).
This problem is probably not frequently experienced because it only
occurs if the delay function modifies the queue, deleting the top entry
while sched.run() is waiting to execute it.
A patch is attached based on the trunk.
----------
components: Library (Lib)
files: sched.py.patch
keywords: patch
messages: 66480
nosy: mthard
severity: normal
status: open
title: heapq.heappush called with too few arguments in sched.py
type: crash
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10233/sched.py.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2803>
__________________________________
From report at bugs.python.org Fri May 9 20:17:56 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 09 May 2008 18:17:56 +0000
Subject: [New-bugs-announce] [issue2804] Integer right shift raises
OverflowError when second operand is large
In-Reply-To: <1210357076.66.0.280536518135.issue2804@psf.upfronthosting.co.za>
Message-ID: <1210357076.66.0.280536518135.issue2804@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
In Python 2.6a3:
>>> 1 >> (2**31) # unexpected exception
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to int
>>> 1 >> (2**31-1) # works as expected
0L
It might make more sense for the first expression to return 0 instead.
Similarly, perhaps 0 << (2**31) should also return 0.
----------
components: Interpreter Core
messages: 66484
nosy: marketdickinson
severity: normal
status: open
title: Integer right shift raises OverflowError when second operand is large
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2804>
__________________________________
From report at bugs.python.org Fri May 9 22:51:51 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 09 May 2008 20:51:51 +0000
Subject: [New-bugs-announce] [issue2805] 2to3 doesn't correct divisions
In-Reply-To: <1210366311.62.0.240931801365.issue2805@psf.upfronthosting.co.za>
Message-ID: <1210366311.62.0.240931801365.issue2805@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
Given the sample code:
for i in range(len([1, 2]) / 2): pass
print 2 / 3
2to3 tells no files need to be modified after running it over this code,
but range doesn't accept float values and the print result will differ.
Would it be too expensive for 2to3 to suggest changing '/' to '//' ?
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 66486
nosy: collinwinter, gpolo
severity: normal
status: open
title: 2to3 doesn't correct divisions
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2805>
__________________________________
From report at bugs.python.org Fri May 9 23:51:56 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Fri, 09 May 2008 21:51:56 +0000
Subject: [New-bugs-announce] [issue2806] Py30a5: Tk Menu Alt-f behaves
differently Linux vs Windows
In-Reply-To: <1210369916.39.0.944355148013.issue2806@psf.upfronthosting.co.za>
Message-ID: <1210369916.39.0.944355148013.issue2806@psf.upfronthosting.co.za>
New submission from Mark Summerfield <mark at qtrac.eu>:
#Python 3.0a5 (py3k:62932M, May 9 2008, 16:23:11) [MSC v.1500 32 bit
#(Intel)] on win32
#
# If you run this tiny program on Linux and press Alt+F (Alt-f in Tk
# terminology) the File menu pops up as expected. But run it on
# Windows Home XP and nothing happens when you press Alt+F.
# The problem may be with the code below since IDLE works fine on
# Windows, in which case sorry!
# However, Grayson's AppB/menu.py example (with suitably fixed print
# statements since it was writtend for Py2) is exactly the same:
# works fine on Linux but Alt+key does not invoke the menus on Windows.
from Tkinter import *
class MainWindow:
def __init__(self, parent):
self.parent = parent
menuBar = Frame(self.parent, relief=RAISED, borderwidth=2)
menuBar.pack(anchor=N, fill=X)
fileMenu = Menubutton(menuBar, text="File", underline=0)
fileMenu.pack(side=LEFT)
fileMenu.menu = Menu(fileMenu, tearoff=False)
for label, command in (
("New...", self.fileNew),
("Open...", self.fileOpen),
("Quit", self.fileQuit)):
fileMenu.menu.add_command(label=label, command=command)
fileMenu["menu"] = fileMenu.menu
menuBar.tk_menuBar(fileMenu)
def fileNew(self, *args):
print("fileNew", args)
def fileOpen(self, *args):
print("fileOpen", args)
def fileQuit(self, *args):
self.parent.destroy()
root = Tk()
window = MainWindow(root)
root.protocol("WM_DELETE_WINDOW", window.parent.destroy)
root.mainloop()
----------
messages: 66492
nosy: mark
severity: normal
status: open
title: Py30a5: Tk Menu Alt-f behaves differently Linux vs Windows
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2806>
__________________________________
From report at bugs.python.org Sat May 10 00:31:28 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 09 May 2008 22:31:28 +0000
Subject: [New-bugs-announce] [issue2807] Remove the API PyUnicode_AsString()
In-Reply-To: <1210372288.18.0.0163444160616.issue2807@psf.upfronthosting.co.za>
Message-ID: <1210372288.18.0.0163444160616.issue2807@psf.upfronthosting.co.za>
New submission from Alexandre Vassalotti <alexandre at peadrop.com>:
Marc-Andre Lemburg noted:
BTW: The API PyUnicode_AsString() is pretty useless by itself - there's
no way to access the size information of the returned string without
again going to the Unicode object.
I'd suggest to remove the API altogether and not only deprecating it.
Furthermore, the API PyUnicode_AsStringAndSize() does not follow the API
signature of PyString_AsStringAndSize() in that it passes back the
pointer to the string as output parameter. That should be changed as
well. Note that PyString_AsStringAndSize() already does this for both
8-bit strings and Unicode, so the special Unicode API is not really
needed at all or you may want to rename PyString_AsStringAndSize() to
PyUnicode_AsStringAndSize().
Finally, since there are many cases where the string buffer contents are
copied to a new buffer, it's probably worthwhile to add a new API which
does the copying straight away and also deals with the overflow cases in
a central place. I'd suggest PyUnicode_AsChar() (with an API like
PyUnicode_AsWideChar()).
----------
components: Interpreter Core, Unicode
messages: 66495
nosy: alexandre.vassalotti, lemburg
priority: normal
severity: normal
status: open
title: Remove the API PyUnicode_AsString()
type: feature request
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2807>
__________________________________
From report at bugs.python.org Sat May 10 13:00:26 2008
From: report at bugs.python.org (xix xeaon)
Date: Sat, 10 May 2008 11:00:26 +0000
Subject: [New-bugs-announce] [issue2808] asynchat forgets packets when push
is called from a thread
In-Reply-To: <1210417225.64.0.883655852515.issue2808@psf.upfronthosting.co.za>
Message-ID: <1210417225.64.0.883655852515.issue2808@psf.upfronthosting.co.za>
New submission from xix xeaon <xix.xeaon at gmail.com>:
okay, my first bug post, hope I do it right.
if you push more than 512 bytes (issue2073) from a thread then only the
first packet will be sent, all other packets will be forgotten.
the remaining packets will be sent when something else happens, like a
new connection is opened, or more input data is read. it's also sent
when the select times out (default 30 seconds) and starts over.
if push is called twice then the first two packets will be sent but the
rest will be forgotten.
if this problem arises in your code then you can easily fix it with a 0
second timeout for loop(), or preferably something like 0.0001 so that
the cpu stays calm ;)
you should be able to reproduce this bug with the attached file, just
run it and then connect with netcat like:
echo "\n" | nc localhost 1100
netcat will print almost 6 and a half lines of x and then the rest after
5 seconds (30 seconds is boring..) or if you have wireshark up then
you'll see it easily.
and would someone please apply all the patches for this module! =)
----------
components: Library (Lib)
files: asyn-delay.py
messages: 66510
nosy: xix xeaon
severity: normal
status: open
title: asynchat forgets packets when push is called from a thread
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file10236/asyn-delay.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2808>
__________________________________
From report at bugs.python.org Sat May 10 17:48:14 2008
From: report at bugs.python.org (Neil Muller)
Date: Sat, 10 May 2008 15:48:14 +0000
Subject: [New-bugs-announce] [issue2809] string docstring doesn't mention
that ' '.split() != ' '.split(' ')
In-Reply-To: <1210434494.63.0.105776836693.issue2809@psf.upfronthosting.co.za>
Message-ID: <1210434494.63.0.105776836693.issue2809@psf.upfronthosting.co.za>
New submission from Neil Muller <drnlmuller+bugs at gmail.com>:
split with no sep specified will not return an empty string, whereas
split with sep specified will.
The attached patch updates the docstring to reflect this for str.split
and unicode.split.
----------
files: split_docstring.diff
keywords: patch
messages: 66536
nosy: Neil Muller
severity: normal
status: open
title: string docstring doesn't mention that ' '.split() != ' '.split(' ')
Added file: http://bugs.python.org/file10254/split_docstring.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2809>
__________________________________
From report at bugs.python.org Sat May 10 19:37:34 2008
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 10 May 2008 17:37:34 +0000
Subject: [New-bugs-announce] [issue2810] _winreg.EnumValue fails when the
registry data includes multibyte unicode characters
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:
_winreg.EnumValue raises a WindowsError ("More data is available") if
the registry data includes multibyte unicode characters.
Inspecting PyEnumValue in _winreg.c, I believe I see the problem. The
function uses RegQueryInfoKey to determine the maximum data and key name
sizes to pass to RegEnumValue.
Unfortunately, RegQueryInfoKey returns the size in number of unicode
characters, while RegEnumValue expects a size in bytes. This is OK if
all the values are ASCII, but it fails if there are any multibyte
unicode characters.
I believe it would be sufficient to multiply the sizes by 4, since
that's the maximum width of a unicode character.
The bug exists in at least Python 2.5 and Python 3.0 (based on source
code inspection).
References:
RegEnumValue: http://msdn.microsoft.com/en-us/library/ms724865(VS.85).aspx
RegQueryInfoKey:
http://msdn.microsoft.com/en-us/library/ms724902(VS.85).aspx
----------
components: Windows
messages: 66542
nosy: stutzbach
severity: normal
status: open
title: _winreg.EnumValue fails when the registry data includes multibyte unicode characters
type: behavior
versions: Python 2.5, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2810>
__________________________________
From report at bugs.python.org Sat May 10 20:47:11 2008
From: report at bugs.python.org (Paulo Eduardo Neves)
Date: Sat, 10 May 2008 18:47:11 +0000
Subject: [New-bugs-announce] [issue2811] doctest doesn't treat unicode
literals as specified by the file declared encoding
In-Reply-To: <1210445230.87.0.512222933205.issue2811@psf.upfronthosting.co.za>
Message-ID: <1210445230.87.0.512222933205.issue2811@psf.upfronthosting.co.za>
New submission from Paulo Eduardo Neves <pauloneves at gmail.com>:
Doctest doesn't obey the specified file encoding for unicode literals.
I've put the minimum test case that demonstrate the error in the
attached file.
The program has the ?# -*- coding: utf-8 -*- as the first line and is
saved in this encoding. My computer environment is configured as
iso8859-1. Doctest ignores the file encoding specification and
interprets the u'?' as u'??' (the utf-8 text decoded as iso8859-1 )
I've reproduced this error in python 2.5 in linux and windows.
This is the output of the program below that runs the function normalize
from inside doctest and directly from python. They show different results.
**********************************************************************
File "doctesteerror.py", line 7, in __main__.normalize
Failed example:
normalize(u'??')
Expected:
u'b'
Got:
u'\xc3\xa1'
**********************************************************************
1 items had failures:
1 of 1 in __main__.normalize
***Test Failed*** 1 failures.
without doctest ===>>> b
----------
components: Library (Lib)
files: doctesteerror.py
messages: 66559
nosy: neves
severity: normal
status: open
title: doctest doesn't treat unicode literals as specified by the file declared encoding
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10265/doctesteerror.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2811>
__________________________________
From report at bugs.python.org Sat May 10 21:10:58 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 10 May 2008 19:10:58 +0000
Subject: [New-bugs-announce] [issue2812] Document
property.getter/setter/deleter etc
Message-ID: <1210446658.24.0.980613599001.issue2812@psf.upfronthosting.co.za>
Changes by Benjamin Peterson <musiccomposition at gmail.com>:
----------
assignee: georg.brandl
components: Documentation
files: getter_setter_deleter_doc.patch
keywords: patch
nosy: benjamin.peterson, georg.brandl
severity: normal
status: open
title: Document property.getter/setter/deleter etc
Added file: http://bugs.python.org/file10268/getter_setter_deleter_doc.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2812>
__________________________________
From report at bugs.python.org Sat May 10 23:09:07 2008
From: report at bugs.python.org (duane Bailey)
Date: Sat, 10 May 2008 21:09:07 +0000
Subject: [New-bugs-announce] [issue2813] No float formatting in
PyString_FromFormat
In-Reply-To: <1210453747.33.0.971608840544.issue2813@psf.upfronthosting.co.za>
Message-ID: <1210453747.33.0.971608840544.issue2813@psf.upfronthosting.co.za>
New submission from duane Bailey <bailey.d.r at gmail.com>:
There appears to be most of the formatting options in the *printf
family... except for the obvious %f. Why is this crucial option missing?
----------
components: Extension Modules, Interpreter Core
messages: 66586
nosy: duaneb
severity: normal
status: open
title: No float formatting in PyString_FromFormat
type: feature request
versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2813>
__________________________________
From report at bugs.python.org Sun May 11 04:49:33 2008
From: report at bugs.python.org (Humberto Diogenes)
Date: Sun, 11 May 2008 02:49:33 +0000
Subject: [New-bugs-announce] [issue2814] Remove old classes from mailbox
module
In-Reply-To: <1210474172.02.0.543540826671.issue2814@psf.upfronthosting.co.za>
Message-ID: <1210474172.02.0.543540826671.issue2814@psf.upfronthosting.co.za>
New submission from Humberto Diogenes <humberto at digi.com.br>:
mailbox.py has one section marked as "classes from the original
module (for backward compatibility)", which are all listed as deprecated
in the module documentation.
In issue 756982, A. M. Kuchling agreed that "removing those old classes in
3.0 would be very sensible." I've attached a patch to do that, removing
the only test that broke (test_unix_mbox).
----------
components: Library (Lib)
files: mailbox-remove_deprecated_classes.patch
keywords: patch
messages: 66596
nosy: akuchling, hdiogenes
severity: normal
status: open
title: Remove old classes from mailbox module
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10276/mailbox-remove_deprecated_classes.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2814>
__________________________________
From report at bugs.python.org Sun May 11 06:57:51 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 11 May 2008 04:57:51 +0000
Subject: [New-bugs-announce] [issue2815] Python Manuals: horizontal
scrolling broken
In-Reply-To: <1210481871.75.0.331980790719.issue2815@psf.upfronthosting.co.za>
Message-ID: <1210481871.75.0.331980790719.issue2815@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
3.0a5, Windows, Python Manuals window opened from Start menu
Ordinary text wraps and adjusts to window width.
Text in green boxes does not. If too long to fit window, given the font
size, horizontal scroll bar at bottom gives access to overflow.
Example: LibMan.StringServices.CommonOps.FormatSyntax.FormatSpecMiniLang
type ::= "b" | .... | "%"
However, when I move the bar right, moving the text left, the newly
visible part of the window coming in from the right is dark blue green
instead of white and the text is a barely distinguishable dark gray
instead of black. I can only read the result with a magnifying glass.
----------
assignee: georg.brandl
components: Documentation
messages: 66600
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Python Manuals: horizontal scrolling broken
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2815>
__________________________________
From report at bugs.python.org Sun May 11 09:26:24 2008
From: report at bugs.python.org (Chester)
Date: Sun, 11 May 2008 07:26:24 +0000
Subject: [New-bugs-announce] [issue2816] Quote-type recognition bug
In-Reply-To: <1210490784.68.0.252907160598.issue2816@psf.upfronthosting.co.za>
Message-ID: <1210490784.68.0.252907160598.issue2816@psf.upfronthosting.co.za>
New submission from Chester <wxpythoner at gmail.com>:
Let's make an intentional syntax error...
>>> print "Testing\"
SyntaxError: EOL while scanning single-quoted string
Please focus on the part of the error message that states "while
scanning single-quoted string". How can Python claim it scanned a
single-quoted string when I fed it with a double-quoted string? That is
a quote type recognition bug in Python which should be fixed.
The error message in this case should, however, be:
SyntaxError: EOL while scanning double-quoted string
----------
messages: 66607
nosy: chester
severity: normal
status: open
title: Quote-type recognition bug
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2816>
__________________________________
From report at bugs.python.org Sun May 11 15:16:17 2008
From: report at bugs.python.org (Chester)
Date: Sun, 11 May 2008 13:16:17 +0000
Subject: [New-bugs-announce] [issue2817] Make Python create a tuple with one
element in a clean way
In-Reply-To: <1210511777.56.0.156447158974.issue2817@psf.upfronthosting.co.za>
Message-ID: <1210511777.56.0.156447158974.issue2817@psf.upfronthosting.co.za>
New submission from Chester <wxpythoner at gmail.com>:
To create a tuple with one element, you need to do this:
>>> my_tuple = (1,) # Note the trailing comma after the value 1
>>> type(my_tuple)
<type 'tuple'>
But if you do this
>>> my_tuple = (1)
>>> type(my_tuple)
<type 'int'>
you don't get a tuple. I thought that just putting a value inside ( )
would make a tuple. Apparently that is not the case. I hate ugly code
so it would be clean if Python would convert anything put into ( ) to
be a tuple, even if just one value was put in (without having to use
that ugly looking comma with no value after it).
----------
messages: 66626
nosy: chester
severity: normal
status: open
title: Make Python create a tuple with one element in a clean way
type: feature request
versions: 3rd party, Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2817>
__________________________________
From report at bugs.python.org Sun May 11 15:32:18 2008
From: report at bugs.python.org (Luyang Han)
Date: Sun, 11 May 2008 13:32:18 +0000
Subject: [New-bugs-announce] [issue2818] pulldom cannot handle xml file with
large external entity properly
In-Reply-To: <1210512738.34.0.315015103661.issue2818@psf.upfronthosting.co.za>
Message-ID: <1210512738.34.0.315015103661.issue2818@psf.upfronthosting.co.za>
New submission from Luyang Han <luyang.han at gmail.com>:
when use xml.dom.pulldom module to parse a large xml file, if all the
information is saved in one xml file, the module can handle it in the
following way without construction the whole DOM:
events = xml.dom.pulldom.parse('file.xml')
for (event, node) in events:
process(event, node)
But if 'file.xml' contains some large external entities, for example:
<!ENTITY file_external SYSTEM "others.xml">
<body>&file_external;</body>
Then using the same python snippet above leads to enormous memory
usage. I did not perform a concrete benchmark, in one case a 3M
external xml file drained about 1 GB memory. I think in this case it
might be the whole DOM structure is constructed.
----------
components: XML
messages: 66628
nosy: hanselda
severity: normal
status: open
title: pulldom cannot handle xml file with large external entity properly
type: resource usage
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2818>
__________________________________
From report at bugs.python.org Sun May 11 18:16:53 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Sun, 11 May 2008 16:16:53 +0000
Subject: [New-bugs-announce] [issue2819] Full precision summation
In-Reply-To: <1210522613.21.0.870124531367.issue2819@psf.upfronthosting.co.za>
Message-ID: <1210522613.21.0.870124531367.issue2819@psf.upfronthosting.co.za>
New submission from Jean Brouwers <MrJean1 at Gmail.com>:
Attached are 2 patches and a test script adding a function sum to the
math and cmath modules of Python 2.6a3. The sum is calculated using a
full precision summation method.
The test script compares the result of the functions with the original
implementation in Python. All tests pass with 4 different builds of
Python 2.6a3:
- GNU gcc 4.0.1 on MacOS X 10.4.11 (Intel Core Duo), 32-bit
- GNU gcc 4.1.2 on RHEL 3 update 7 (Opteron), 64-bit
- Sun C 5.8 on Solaris 10 (Opteron), both 32- and 64-bit
----------
components: Extension Modules
files: cmathmodule.c.2.6a3.diff
keywords: patch
messages: 66641
nosy: MrJean1, rhettinger
severity: normal
status: open
title: Full precision summation
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file10285/cmathmodule.c.2.6a3.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2819>
__________________________________
From report at bugs.python.org Sun May 11 20:25:56 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 11 May 2008 18:25:56 +0000
Subject: [New-bugs-announce] [issue2820] Remove mac modules
In-Reply-To: <1210530356.32.0.928311104716.issue2820@psf.upfronthosting.co.za>
Message-ID: <1210530356.32.0.928311104716.issue2820@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
I've removed the Mac modules. The Bazaar branch is at
http://code.python.org/python/users/benjamin.peterson/mac_module_removal/.
----------
assignee: brett.cannon
components: Extension Modules
messages: 66648
nosy: benjamin.peterson, brett.cannon
priority: critical
severity: normal
status: open
title: Remove mac modules
type: feature request
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2820>
__________________________________
From report at bugs.python.org Sun May 11 21:00:57 2008
From: report at bugs.python.org (Adam Getchell)
Date: Sun, 11 May 2008 19:00:57 +0000
Subject: [New-bugs-announce] [issue2821] unittest.py sys.exit error
In-Reply-To: <1210532457.78.0.053406582463.issue2821@psf.upfronthosting.co.za>
Message-ID: <1210532457.78.0.053406582463.issue2821@psf.upfronthosting.co.za>
New submission from Adam Getchell <acgetchell at ucdavis.edu>:
Picking the canonical example of unit test:
import random
import unittest
class TestSequenceFunctions(unittest.TestCase):
def setUp(self):
self.seq = range(10)
def testshuffle(self):
# make sure the shuffled sequence does not lose any elements
random.shuffle(self.seq)
self.seq.sort()
self.assertEqual(self.seq, range(10))
def testchoice(self):
element = random.choice(self.seq)
self.assert_(element in self.seq)
def testsample(self):
self.assertRaises(ValueError, random.sample, self.seq, 20)
for element in random.sample(self.seq, 5):
self.assert_(element in self.seq)
if __name__ == '__main__':
unittest.main()
Gives the following error:
>>>
...
----------------------------------------------------------------------
Ran 3 tests in 0.003s
OK
Traceback (most recent call last):
File "C:\Projects\Python\randomunittest.py", line 25, in <module>
unittest.main()
File "C:\Python25\lib\unittest.py", line 768, in __init__
self.runTests()
File "C:\Python25\lib\unittest.py", line 806, in runTests
sys.exit(not result.wasSuccessful())
SystemExit: False
The error lies in the following code snippet:
def runTests(self):
if self.testRunner is None:
self.testRunner = TextTestRunner(verbosity=self.verbosity)
result = self.testRunner.run(self.test)
sys.exit(not result.wasSuccessful())
----------
components: Library (Lib)
files: unittest.py
messages: 66651
nosy: acgetchell
severity: normal
status: open
title: unittest.py sys.exit error
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10289/unittest.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2821>
__________________________________
From report at bugs.python.org Sun May 11 21:17:19 2008
From: report at bugs.python.org (Chester)
Date: Sun, 11 May 2008 19:17:19 +0000
Subject: [New-bugs-announce] [issue2822] Quote-type recognition bug [badly
fixed last time]
In-Reply-To: <1210533439.19.0.489814447289.issue2822@psf.upfronthosting.co.za>
Message-ID: <1210533439.19.0.489814447289.issue2822@psf.upfronthosting.co.za>
New submission from Chester <wxpythoner at gmail.com>:
I have a suggestion that would make the
http://svn.python.org/view?rev=63068&view=rev look ever more clear. It
would be better to have this kind of error messages:
expect = "End of line while scanning string (<string>, line 1)"
and
expect "End of f... while scanning multi-line string (<string>, line 1)"
These messages really need to be clear, so putting EOF for example
(which I really don't know what it stands for) is really mind-bending.
But if changing EOL and EOF to their actual meaning would cause some
problems, then this look nice as well:
expect = "EOL while scanning string (<string>, line 1)"
and
expect "EOF while scanning multi-line string (<string>, line 1)"
The first two proposals look more readable because I think that many
people don't know what EOF stands for (they can guess for EOL though,
but EOF is just mind-bending and wild guessing). I Googled and found no
answer, so I actually don't know what that error message is saying to me.
Also, it would be good, however, to remove the 'triple-quoted string
literal' and name that simply as 'multi-line string'. Simple is better
than complex. :)
Mister Rossum, please give a go on that. I kindly ask you to choose from
the above two options. Your proposal on that was made, yes... but I find
the 'multi-line string' even better than 'triple-quoted string literal'.
I would love to provide a patch but I don't know how it's made.
----------
messages: 66652
nosy: chester, gvanrossum
severity: normal
status: open
title: Quote-type recognition bug [badly fixed last time]
versions: 3rd party, Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2822>
__________________________________
From report at bugs.python.org Sun May 11 21:42:08 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 11 May 2008 19:42:08 +0000
Subject: [New-bugs-announce] [issue2823] "Report bug" links
In-Reply-To: <1210534928.44.0.636090674533.issue2823@psf.upfronthosting.co.za>
Message-ID: <1210534928.44.0.636090674533.issue2823@psf.upfronthosting.co.za>
New submission from anatoly techtonik <techtonik at gmail.com>:
It would be convenient to use links in the bottom of documentation pages
for bugreporting that directly connect to bugtracker search form. I.e.
"Report bug on this page" and "Report bug in this module".
----------
assignee: georg.brandl
components: Documentation, Documentation tools (Sphinx)
messages: 66657
nosy: georg.brandl, techtonik
severity: normal
status: open
title: "Report bug" links
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2823>
__________________________________
From report at bugs.python.org Sun May 11 22:17:50 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 11 May 2008 20:17:50 +0000
Subject: [New-bugs-announce] [issue2824] zipfile to handle duplicate files
in archive
In-Reply-To: <1210537070.35.0.0613996133193.issue2824@psf.upfronthosting.co.za>
Message-ID: <1210537070.35.0.0613996133193.issue2824@psf.upfronthosting.co.za>
New submission from anatoly techtonik <techtonik at gmail.com>:
ZipFile allows to add the same file to archive twice. I bet it is not
intended behavior for many users who would like to either replace file
inside of archive or get runtime warning about duplicate file to be
added. http://code.google.com/p/gvn/issues/detail?id=63
from zipfile import ZipFile
zt=ZipFile("ziptest.zip","w")
zt.write("ziptest.py")
zt.write("ziptest.py")
zt.close()
----------
components: Extension Modules
messages: 66661
nosy: techtonik
severity: normal
status: open
title: zipfile to handle duplicate files in archive
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2824>
__________________________________
From report at bugs.python.org Sun May 11 22:42:25 2008
From: report at bugs.python.org (Chester)
Date: Sun, 11 May 2008 20:42:25 +0000
Subject: [New-bugs-announce] [issue2825] Quote-type recognition bug [got a
patch!]
In-Reply-To: <1210538545.7.0.805693015391.issue2825@psf.upfronthosting.co.za>
Message-ID: <1210538545.7.0.805693015391.issue2825@psf.upfronthosting.co.za>
New submission from Chester <wxpythoner at gmail.com>:
This is a patch I made to make this messages clear now. I hope you like it.
----------
files: test_eof.patch
keywords: patch
messages: 66664
nosy: chester
severity: normal
status: open
title: Quote-type recognition bug [got a patch!]
Added file: http://bugs.python.org/file10291/test_eof.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2825>
__________________________________
From report at bugs.python.org Sun May 11 23:34:08 2008
From: report at bugs.python.org (Chester)
Date: Sun, 11 May 2008 21:34:08 +0000
Subject: [New-bugs-announce] [issue2826] safe_substitute() and substitute()
In-Reply-To: <1210541648.51.0.130829748422.issue2826@psf.upfronthosting.co.za>
Message-ID: <1210541648.51.0.130829748422.issue2826@psf.upfronthosting.co.za>
New submission from Chester <wxpythoner at gmail.com>:
Please consider of removing safe_substitute() method and make the
current substitute() method act like safe_substitute() method but being
named substitute().
----------
messages: 66675
nosy: chester, gvanrossum
severity: normal
status: open
title: safe_substitute() and substitute()
versions: 3rd party, Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2826>
__________________________________
From report at bugs.python.org Mon May 12 00:49:49 2008
From: report at bugs.python.org (Sven Siegmund)
Date: Sun, 11 May 2008 22:49:49 +0000
Subject: [New-bugs-announce] [issue2827] IDLE 3.0a5 cannot handle UTF-8
In-Reply-To: <1210546189.14.0.555715055472.issue2827@psf.upfronthosting.co.za>
Message-ID: <1210546189.14.0.555715055472.issue2827@psf.upfronthosting.co.za>
New submission from Sven Siegmund <sven.siegmund at gmail.com>:
I have a source code which IDLE 3.0a5 cannot parse, but Python 3.0a5
can (also attached):
#!/usr/bin/python
# -*- coding: utf-8 -*-
def na?tiSlovn?k(zdroj='slovn?k.txt'):
soubor = open(zdroj, mode='r', encoding='utf_8')
??dky = soubor.readlines()
for ??dek in ??dky:
print(??dek, end='')
na?tiSlovn?k()
# End of source code
I have set up Default Source Encoding to UTF-8 in IDLE's general
configuration. Still, when I open that source code and try to run it,
IDLE complains about "invalid character in identifier" and highlights
"zdroj" red in the first line (sic!).
However, when I run the source code from command line (by "python
<filename>"), it gets executed well and does what it shall do.
I should probably add, that I have installed py3k:62932M, May 9 2008,
16:23:11 [MSC v.1500 32 bit (Intel)] on win32. I use Windows XP SP 3.
IDLE uses Tk version 8.4
----------
components: IDLE
files: czech-it.py
messages: 66689
nosy: sven.siegmund
severity: normal
status: open
title: IDLE 3.0a5 cannot handle UTF-8
type: compile error
versions: Python 3.0
Added file: http://bugs.python.org/file10293/czech-it.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2827>
__________________________________
From report at bugs.python.org Mon May 12 03:19:49 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 12 May 2008 01:19:49 +0000
Subject: [New-bugs-announce] [issue2828] Clean up undoc.rst
In-Reply-To: <1210555189.34.0.375488614509.issue2828@psf.upfronthosting.co.za>
Message-ID: <1210555189.34.0.375488614509.issue2828@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Doc/library/undoc.rst needs to be cleaned up once PEP 3108 has been
implemented.
----------
assignee: brett.cannon
components: Documentation
keywords: easy
messages: 66694
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Clean up undoc.rst
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2828>
__________________________________
From report at bugs.python.org Mon May 12 05:37:40 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 12 May 2008 03:37:40 +0000
Subject: [New-bugs-announce] [issue2829] Copy cgi.parse_qs() to urllib.parse
In-Reply-To: <1210563460.47.0.22388264935.issue2829@psf.upfronthosting.co.za>
Message-ID: <1210563460.47.0.22388264935.issue2829@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
cgi.parse_qs() really belongs more in urllib.parse. Move it so that people
no longer have to import cgi just for that one function.
----------
assignee: brett.cannon
components: Library (Lib)
messages: 66703
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Copy cgi.parse_qs() to urllib.parse
type: feature request
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2829>
__________________________________
From report at bugs.python.org Mon May 12 05:41:33 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 12 May 2008 03:41:33 +0000
Subject: [New-bugs-announce] [issue2830] Copy cgi.escape() to html
In-Reply-To: <1210563693.47.0.635782576194.issue2830@psf.upfronthosting.co.za>
Message-ID: <1210563693.47.0.635782576194.issue2830@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
cgi.escape() really belong in the new 'html' package.
----------
components: Library (Lib)
messages: 66704
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Copy cgi.escape() to html
type: feature request
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2830>
__________________________________
From report at bugs.python.org Mon May 12 05:49:35 2008
From: report at bugs.python.org (Scott Dial)
Date: Mon, 12 May 2008 03:49:35 +0000
Subject: [New-bugs-announce] [issue2831] Adding start to enumerate()
In-Reply-To: <1210564174.93.0.918851730075.issue2831@psf.upfronthosting.co.za>
Message-ID: <1210564174.93.0.918851730075.issue2831@psf.upfronthosting.co.za>
New submission from Scott Dial <scott at scottdial.com>:
Georg Brandel suggested enumerate() should have the ability to start on
an arbitrary number (instead of always starting at 0). I suggest such a
parameter should be keyword-only. Attached is a patch to add such a
feature along with added test cases. Documentation still needs to be
updated, but I wasn't sure how best to handle that anyways.
I wasn't sure how best to handle a keyword-only argument, so I'd be
interested to know if there is a better way.
----------
components: Interpreter Core
files: enumerate.diff
keywords: patch
messages: 66705
nosy: scottdial
severity: normal
status: open
title: Adding start to enumerate()
type: feature request
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10299/enumerate.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2831>
__________________________________
From report at bugs.python.org Mon May 12 06:52:05 2008
From: report at bugs.python.org (Dmitry Dvoinikov)
Date: Mon, 12 May 2008 04:52:05 +0000
Subject: [New-bugs-announce] [issue2832] Line numbers reported by
extract_stack are offset by the #-*- encoding line
In-Reply-To: <1210567925.19.0.359554733284.issue2832@psf.upfronthosting.co.za>
Message-ID: <1210567925.19.0.359554733284.issue2832@psf.upfronthosting.co.za>
New submission from Dmitry Dvoinikov <dmitry at targeted.org>:
Stack trace information extracted with traceback.extract_stack is
incorrect in that the #-*- line causes double counting. For example:
#comment
from traceback import extract_stack
print("this is line", extract_stack()[-1][1])
prints 'this is line 3', but
#comment
#-*- coding: windows-1251 -*-
from traceback import extract_stack
print("this is line", extract_stack()[-1][1])
prints 'this is line 6'
----------
components: Library (Lib)
messages: 66708
nosy: ddvoinikov
severity: normal
status: open
title: Line numbers reported by extract_stack are offset by the #-*- encoding line
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2832>
__________________________________
From report at bugs.python.org Mon May 12 09:06:54 2008
From: report at bugs.python.org (Dmitry Dvoinikov)
Date: Mon, 12 May 2008 07:06:54 +0000
Subject: [New-bugs-announce] [issue2833] __exit__ silences the active
exception
In-Reply-To: <1210576013.94.0.462684443177.issue2833@psf.upfronthosting.co.za>
Message-ID: <1210576013.94.0.462684443177.issue2833@psf.upfronthosting.co.za>
New submission from Dmitry Dvoinikov <dmitry at targeted.org>:
If a context manager is used within exception handling block, the active
exception is silenced after the context block completes and __exit__ exits.
try:
raise Exception("foo")
except:
with SomeContextManager():
pass
raise # in Py2.5 throws 'foo', in Py3.0 fails with RuntimeError
----------
components: Interpreter Core
messages: 66713
nosy: ddvoinikov
severity: normal
status: open
title: __exit__ silences the active exception
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2833>
__________________________________
From report at bugs.python.org Mon May 12 10:44:10 2008
From: report at bugs.python.org (Sven Siegmund)
Date: Mon, 12 May 2008 08:44:10 +0000
Subject: [New-bugs-announce] [issue2834] re.IGNORECASE not Unicode-ready
In-Reply-To: <1210581845.07.0.550614143529.issue2834@psf.upfronthosting.co.za>
Message-ID: <1210581845.07.0.550614143529.issue2834@psf.upfronthosting.co.za>
New submission from Sven Siegmund <sven.siegmund at gmail.com>:
re cannot ignore case of special latin characters:
Python 3.0a5 (py3k:62932M, May 9 2008, 16:23:11) [MSC v.1500 32 bit
(Intel)] on win32
>>> '?'.lower() == '?' and '?'.upper() == '?'
True
>>> import re
>>> rx = re.compile('?', re.IGNORECASE)
>>> rx.match('?') # should match but won't
>>> rx.match('?') # will match
<_sre.SRE_Match object at 0x014B08A8>
>>> rx = re.compile('?', re.IGNORECASE)
>>> rx.match('?') # should match but won't
>>> rx.match('?') # will match
<_sre.SRE_Match object at 0x014B08A8>
----------
components: Regular Expressions
messages: 66715
nosy: sven.siegmund
severity: normal
status: open
title: re.IGNORECASE not Unicode-ready
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2834>
__________________________________
From report at bugs.python.org Mon May 12 11:39:31 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Mon, 12 May 2008 09:39:31 +0000
Subject: [New-bugs-announce] [issue2835] Py30a5: webbrowser.open() inf
recursion
In-Reply-To: <1210585171.47.0.115273460477.issue2835@psf.upfronthosting.co.za>
Message-ID: <1210585171.47.0.115273460477.issue2835@psf.upfronthosting.co.za>
New submission from Mark Summerfield <mark at qtrac.eu>:
There appears to be an infinite recursion in Py30a5 (doing the same
thing in Py2.5.1 works fine):
Python 3.0a5 (r30a5:62856, May 9 2008, 11:23:06)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
Type "copyright", "credits" or "license()" for more information.
IDLE 3.0a5
>>> import webbrowser
>>> url = "http://www.python.org"
>>> webbrowser.open(url)
Traceback (most recent call last):
File "<pyshell#9>", line 1, in <module>
webbrowser.open(url)
File "/home/mark/opt/python30a5/lib/python3.0/webbrowser.py", line 61,
in open
if browser.open(url, new, autoraise):
File "/home/mark/opt/python30a5/lib/python3.0/webbrowser.py", line
350, in open
devnull = open(os.devnull, "r+")
File "/home/mark/opt/python30a5/lib/python3.0/webbrowser.py", line 61,
in open
if browser.open(url, new, autoraise):
File "/home/mark/opt/python30a5/lib/python3.0/webbrowser.py", line
350, in open
...
devnull = open(os.devnull, "r+")
File "/home/mark/opt/python30a5/lib/python3.0/webbrowser.py", line 61,
in open
if browser.open(url, new, autoraise):
----------
components: Library (Lib)
messages: 66716
nosy: mark
severity: normal
status: open
title: Py30a5: webbrowser.open() inf recursion
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2835>
__________________________________
From report at bugs.python.org Mon May 12 12:42:50 2008
From: report at bugs.python.org (Eric Smith)
Date: Mon, 12 May 2008 10:42:50 +0000
Subject: [New-bugs-announce] [issue2836] str.format() documentation needs to
be backported to 2.6
In-Reply-To: <1210588970.37.0.914447928942.issue2836@psf.upfronthosting.co.za>
Message-ID: <1210588970.37.0.914447928942.issue2836@psf.upfronthosting.co.za>
New submission from Eric Smith <eric at trueblade.com>:
3.0 has documentation for str.format(), but that documentation is
missing in 2.6. The 2.6 what's new document:
http://docs.python.org/dev/whatsnew/2.6.html also has an XXX reference
to this:
"Consult the 2.6 documentation for a complete list (XXX add link, once
it?s in the 2.6 docs), but here?s a sample:"
----------
assignee: georg.brandl
components: Documentation
keywords: 26backport
messages: 66717
nosy: eric.smith, georg.brandl
priority: high
severity: normal
status: open
title: str.format() documentation needs to be backported to 2.6
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2836>
__________________________________
From report at bugs.python.org Mon May 12 17:37:42 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 12 May 2008 15:37:42 +0000
Subject: [New-bugs-announce] [issue2837] OpenID wannabe
In-Reply-To: <1210606658.94.0.916012162383.issue2837@psf.upfronthosting.co.za>
Message-ID: <1210606658.94.0.916012162383.issue2837@psf.upfronthosting.co.za>
New submission from anatoly techtonik <techtonik at gmail.com>:
I haven't found any traces of requests to add OpenID URLs for
authentication into account details for registered users, so I take the
privilege to be the first one to say that it will be handy.
----------
components: None
messages: 66729
nosy: techtonik
severity: normal
status: open
title: OpenID wannabe
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2837>
__________________________________
From report at bugs.python.org Mon May 12 20:00:02 2008
From: report at bugs.python.org (Ruben Kerkhof)
Date: Mon, 12 May 2008 18:00:02 +0000
Subject: [New-bugs-announce] [issue2838] Verify callback for SSL
In-Reply-To: <1210615202.55.0.632345790803.issue2838@psf.upfronthosting.co.za>
Message-ID: <1210615202.55.0.632345790803.issue2838@psf.upfronthosting.co.za>
New submission from Ruben Kerkhof <ruben at rubenkerkhof.com>:
I've been playing with the new SSL module, and so far it works great.
However, when using it to connect to a host with a self signed
certificate, verification fails when I specify ssl.CERT_REQUIRED (as
expected).
I know that I'm connecting to a host with a self signed certificate, so
I want to be able to ignore that error. At the moment, the only option I
see is to specify ssl.CERT_NONE and verify the DER certificate by hand.
It would be great if I could specify a callback function that can ignore
certain errors, and does additional checking.
----------
components: Library (Lib)
messages: 66746
nosy: ruben
severity: normal
status: open
title: Verify callback for SSL
type: feature request
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2838>
__________________________________
From report at bugs.python.org Mon May 12 20:00:39 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 12 May 2008 18:00:39 +0000
Subject: [New-bugs-announce] [issue2839] Moving lib-tk to tkinter package
In-Reply-To: <1210615239.35.0.359819643531.issue2839@psf.upfronthosting.co.za>
Message-ID: <1210615239.35.0.359819643531.issue2839@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
I'm moving lib-tk to a tkinter package, I've sent a patch for this which
can be found at issue 2775 but I started wrong (did a patch against py3k
directly).
----------
components: Library (Lib)
messages: 66747
nosy: gpolo
severity: normal
status: open
title: Moving lib-tk to tkinter package
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2839>
__________________________________
From report at bugs.python.org Mon May 12 21:44:34 2008
From: report at bugs.python.org (Craig Holmquist)
Date: Mon, 12 May 2008 19:44:34 +0000
Subject: [New-bugs-announce] [issue2840] Expat parser locks XML source file
if ContentHandler raises an exception
In-Reply-To: <1210621474.39.0.327877522239.issue2840@psf.upfronthosting.co.za>
Message-ID: <1210621474.39.0.327877522239.issue2840@psf.upfronthosting.co.za>
New submission from Craig Holmquist <craig at neurotronics.com>:
This was observed in Python 2.5.2 on Windows XP. Run this code in IDLE:
import xml.sax
from xml.sax.handler import ContentHandler
class C(ContentHandler):
def startElement(self, name, attrs):
assert False
xml.sax.parse(xml_path, C())
Where "xml_path" points to a well-formed XML file. This will raise an
AssertionError. Then, attempt to modify or delete the XML file that was
specified; it's still locked by the Python process.
Deleting the ContentHandler does not unlock it. There doesn't seem any
way to unlock it aside from terminating the Python process.
If the ContentHandler doesn't raise an exception or error, the file is
unlocked properly.
----------
components: XML
messages: 66754
nosy: craigneuro
severity: normal
status: open
title: Expat parser locks XML source file if ContentHandler raises an exception
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2840>
__________________________________
From report at bugs.python.org Mon May 12 22:55:24 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 12 May 2008 20:55:24 +0000
Subject: [New-bugs-announce] [issue2841] Windows: "Runtime Error!" crash
from pythonw.exe (3.0a5)
In-Reply-To: <1210625724.53.0.096647435573.issue2841@psf.upfronthosting.co.za>
Message-ID: <1210625724.53.0.096647435573.issue2841@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
Specific instance: I edit a file with IDLE, hit F5, and Windows pops up
a box with a white X in a red circle followed by "Runtime Error!" and an
explanation that the application requested to be closed in an 'unusual'
way.
Clicking OK on that bring up a similar box. For the current incident,
this has title "t1.py - C:\Program Files\Python30\misc\t1.py:
pythonw.exe - Application Error" and contents "The exception unknown
software exception (0x40000015) occurred in the application at location
0x00d88cef. Click on OK to terminate the program"
This has happened about three times in the last week since installing
a5. I am not sure if it happened before but it is only occasional (1 in
20 runs?) and I did not use a4 much. It is possible that this only
happens after sleep or hibernation -- I will watch more carefully. I
only run pythonw as a side-effect of running IDLE, so I do not know if
that is necessary or not.
As previously, when I reopened IDLE and the the file and ran it
unchanged, I got the appropriate output in the Shell window, as if
nothing were ever amiss.
----------
messages: 66757
nosy: tjreedy
severity: normal
status: open
title: Windows: "Runtime Error!" crash from pythonw.exe (3.0a5)
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2841>
__________________________________
From report at bugs.python.org Mon May 12 23:11:54 2008
From: report at bugs.python.org (Chester)
Date: Mon, 12 May 2008 21:11:54 +0000
Subject: [New-bugs-announce] [issue2842] Dictionary methods: inconsistency
In-Reply-To: <1210626714.02.0.133296907813.issue2842@psf.upfronthosting.co.za>
Message-ID: <1210626714.02.0.133296907813.issue2842@psf.upfronthosting.co.za>
New submission from Chester <wxpythoner at gmail.com>:
Names of dictionary methods are not consistent with Python's coding
style. Please fix the following method names:
1) fix deepcopy to be deep_copy
2) fix fromkeys to be from_keys
3) fix popitem to be pop_item
4) fix setdefault to be set_default
Please consider of renaming the method copy to shallow_copy. If you find
any other inconsistently named method, please fix it. Thank you.
----------
messages: 66758
nosy: aaronsw, admin, akuchling, anonymous, barry, chester, doerwalter, effbot, fdrake, gvanrossum, jhylton, lemburg, loewis, memaul, mhammond, moshez, mpmak, mwh, nobody, ping, sjoerd, skip.montanaro, tim_one, tmick, twouters, viznut
severity: normal
status: open
title: Dictionary methods: inconsistency
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2842>
__________________________________
From report at bugs.python.org Tue May 13 05:16:02 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 13 May 2008 03:16:02 +0000
Subject: [New-bugs-announce] [issue2843] New methods for existing Tkinter
widgets
In-Reply-To: <1210648562.38.0.607141778412.issue2843@psf.upfronthosting.co.za>
Message-ID: <1210648562.38.0.607141778412.issue2843@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
Attached patch adds the following new methods:
Misc: grid_anchor
Menu: xposition
Text: count, peer_create, peer_names, replace
Wm: wm_iconphoto, wm_manage, wm_forget
These are supported by Tk 8.5 and newer.
----------
components: Tkinter
files: tk8.5_newmeths.py
messages: 66768
nosy: gpolo
severity: normal
status: open
title: New methods for existing Tkinter widgets
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10314/tk8.5_newmeths.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2843>
__________________________________
From report at bugs.python.org Tue May 13 12:03:55 2008
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 13 May 2008 10:03:55 +0000
Subject: [New-bugs-announce] [issue2844] int() lies about base parameter
In-Reply-To: <1210673035.74.0.555246822521.issue2844@psf.upfronthosting.co.za>
Message-ID: <1210673035.74.0.555246822521.issue2844@psf.upfronthosting.co.za>
New submission from Jakub Wilk <ubanus at users.sf.net>:
>>> int('42', 42)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: int() base must be >= 2 and <= 36
>>> int('42', -909)
42
----------
components: Library (Lib)
messages: 66777
nosy: jwilk
severity: normal
status: open
title: int() lies about base parameter
type: behavior
versions: Python 2.4, Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2844>
__________________________________
From report at bugs.python.org Tue May 13 23:28:51 2008
From: report at bugs.python.org (igs)
Date: Tue, 13 May 2008 21:28:51 +0000
Subject: [New-bugs-announce] [issue2845] shutil.copy2() copies permission
bits
In-Reply-To: <1210714130.89.0.107453943261.issue2845@psf.upfronthosting.co.za>
Message-ID: <1210714130.89.0.107453943261.issue2845@psf.upfronthosting.co.za>
New submission from igs <marko at von-oppen.com>:
At least in Python 2.4 shutil.copy2() not only copies content and
access times of a files like stated in the documentation but also the
access bits.
That behaviour I would not expect because in other functions from
shutil it is explicitly stated if the access bits are copied.
In fact I used
shutil.copy2(src, dest)
shutil.copystat(src, dest)
up to now. What does not work if the read-only attribute is set and
what is completely nonsense after having a look into the implementation.
----------
components: Windows
messages: 66803
nosy: igs
severity: normal
status: open
title: shutil.copy2() copies permission bits
type: behavior
versions: Python 2.4
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2845>
__________________________________
From report at bugs.python.org Wed May 14 00:16:23 2008
From: report at bugs.python.org (Tadek Pietraszek)
Date: Tue, 13 May 2008 22:16:23 +0000
Subject: [New-bugs-announce] [issue2846] Gzip cannot handle zero-padded
output + patch
In-Reply-To: <1210716983.8.0.306490627236.issue2846@psf.upfronthosting.co.za>
Message-ID: <1210716983.8.0.306490627236.issue2846@psf.upfronthosting.co.za>
New submission from Tadek Pietraszek <tadek at pietraszek.org>:
There are cases when gzip produces/receives a zero-padded output, for
example when creating a compressed tar archive with a pipe:
tar cz /dev/null > foo.tgz
ls -la foo.tgz
-rw-r----- 1 tadek tadek 10240 May 13 23:40 foo.tgz
tar tvfz foo.tgz
crw-rw-rw- root/root 1,3 2007-10-18 18:27:25 dev/null
This is a known behavior (http://www.gzip.org/#faq8) and recent versions
of gzip handle it gracefully by skipping all zero bytes after the end of
the file (see gzip.c:1394-1406 in the version 1.3.12).
The Python gzip module crashes on those files:
#:~/python2.5/py2.5$ tar cz /dev/null > foo.tgz
tar: Removing leading `/' from member names
#:~/python2.5/py2.5$ bin/python
Python 2.5.2 (r252:60911, May 14 2008, 00:02:24)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gzip
>>> f=gzip.open("foo.tgz")
>>> f.read()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/tadek/python2.5/py2.5/lib/python2.5/gzip.py", line 220, in
read
self._read(readsize)
File "/home/tadek/python2.5/py2.5/lib/python2.5/gzip.py", line 263, in
_read
self._read_gzip_header()
File "/home/tadek/python2.5/py2.5/lib/python2.5/gzip.py", line 164, in
_read_gzip_header
raise IOError, 'Not a gzipped file'
IOError: Not a gzipped file
>>>
The proposed patch fixes this behavior by reading all zero characters at
the end of the file. I tested that it works with: regular archives,
zero-padded archives, concatenated archives and concatenated zero-padded
archives.
Regards,
Tadek
----------
components: Extension Modules
files: python2.5.2-gzip.patch
keywords: patch
messages: 66806
nosy: tadek
severity: normal
status: open
title: Gzip cannot handle zero-padded output + patch
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10320/python2.5.2-gzip.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2846>
__________________________________
From report at bugs.python.org Wed May 14 02:57:15 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 14 May 2008 00:57:15 +0000
Subject: [New-bugs-announce] [issue2847] Remove cl usage from aifc
In-Reply-To: <1210726634.74.0.297516553516.issue2847@psf.upfronthosting.co.za>
Message-ID: <1210726634.74.0.297516553516.issue2847@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
The cl module has been removed from Python 3.0, but the aifc module still
imports it in multiple locations. The module needs to be updated (with
tests hopefully) so as to not use the cl module.
----------
components: Library (Lib)
messages: 66808
nosy: brett.cannon
priority: critical
severity: normal
status: open
title: Remove cl usage from aifc
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2847>
__________________________________
From report at bugs.python.org Wed May 14 02:59:35 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 14 May 2008 00:59:35 +0000
Subject: [New-bugs-announce] [issue2848] Remove mimetools usage from the
stdlib
In-Reply-To: <1210726775.09.0.0627957766628.issue2848@psf.upfronthosting.co.za>
Message-ID: <1210726775.09.0.0627957766628.issue2848@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
The mimetools module has been deprecated for ages, but it is still used in
multiple places (a quick grep lists ``cgi``, ``httplib``, ``urllib``,
``urllib2``, ``test_cookielib``, ``test_multifile``, ``test_urllib``,
``test_urllib2``, ``test_urllib2net``, ``test_urllib_localnet``,
``test_urllibnet``, ``test_xmlrpc``). All uses need to be removed before
the module can go from Py3K.
----------
components: Library (Lib)
messages: 66809
nosy: brett.cannon
priority: critical
severity: normal
status: open
title: Remove mimetools usage from the stdlib
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2848>
__________________________________
From report at bugs.python.org Wed May 14 03:02:04 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 14 May 2008 01:02:04 +0000
Subject: [New-bugs-announce] [issue2849] Remove usage of rfc822 from the
stdlib
In-Reply-To: <1210726924.82.0.902490265063.issue2849@psf.upfronthosting.co.za>
Message-ID: <1210726924.82.0.902490265063.issue2849@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
The rfc822 module has been deprecated for a while but is still used in the
stdlib (at least in 'cgi' and 'test_urllib2'). All uses need to go before
the module can be removed.
----------
components: Library (Lib)
messages: 66810
nosy: brett.cannon
priority: critical
severity: normal
status: open
title: Remove usage of rfc822 from the stdlib
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2849>
__________________________________
From report at bugs.python.org Wed May 14 13:02:50 2008
From: report at bugs.python.org (Trent Nelson)
Date: Wed, 14 May 2008 11:02:50 +0000
Subject: [New-bugs-announce] [issue2850] Augmenting the Windows build to
support code signing.
In-Reply-To: <1210762970.34.0.566906557535.issue2850@psf.upfronthosting.co.za>
Message-ID: <1210762970.34.0.566906557535.issue2850@psf.upfronthosting.co.za>
New submission from Trent Nelson <tnelson at onresolve.com>:
Now that we've finally got a VeriSign code-signing certificate
(hurrah!), we can look at how we want to integrate the aspect of code
signing into our build process.
I'd like to propose augmenting the build process such that as a post-
link step for .exe|.pyd targets, a little helper Python code signing
script will be run (i.e. trunk/pcbuild/signfile.py). The first thing
that this script will check is whether or not the environment variable
PYTHON_CODESIGNING_CERT_NAME is defined. If it is not defined or is
empty, the script will simply exit. This will be the case for the vast
majority of users.
However, if the environment variable exists, it indicates to the
signfile.py script that the target .exe|.pyd should be signed, using
the identifier specified by the environment variable, with Microsoft's
code-signing facilities (signtool.exe etc).
The net effect is that if a user has a valid code-signing certificate
installed, they can get the standard Python build system to
automatically sign all binaries by setting this environment variable.
I think this approach is more useful than, say, having Martin manually
sign each binary when it comes to release time, as it is automated (and
as such, less error prone), and can be leveraged by anyone wishing to
create signed Python distributions, not just the PSF (i.e. ActiveState,
Enthought, etc).
Assuming there are no objections to this proposal, a couple of other
things I'll provide:
a) documentation on both what's required in order to produce a
signed distribution, as well as guidelines for other companies
wishing to obtain code-signing certificates for the purposes of
signing their custom Python distributions (perhaps better suited
to a wiki entry)
b) a helper script in pcbuild/ that can a) augment existing .vcprojs
and add the post-link signing step, and b) be run in such a way
that it checks all existing .vcprojs for .exe|.pyd targets have
the post-link event correctly configured
Comments/objections?
Trent.
----------
assignee: Trent.Nelson
components: Build
messages: 66814
nosy: Trent.Nelson, loewis, tmick
priority: normal
severity: normal
status: open
title: Augmenting the Windows build to support code signing.
type: feature request
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2850>
__________________________________
From report at bugs.python.org Wed May 14 14:40:50 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Wed, 14 May 2008 12:40:50 +0000
Subject: [New-bugs-announce] [issue2851] Eliminate Perl legacy in re flag
names
In-Reply-To: <1210768849.77.0.700773765733.issue2851@psf.upfronthosting.co.za>
Message-ID: <1210768849.77.0.700773765733.issue2851@psf.upfronthosting.co.za>
New submission from Mark Summerfield <mark at qtrac.eu>:
The re module has the following flags (amongst others):
re.X == re.VERBOSE
re.S == re.DOTALL
The short forms of both these flags are clearly taken from Perl, but
they don't seem necessary for Python and are confusing since all the
other short names start with the same letter as the long name, e.g.,
re.I == re.IGNORECASE and re.M == re.MULTILINE.
Why not add re.V for re.VERBOSE and re.D for re.DOTALL and kill re.X and
re.S and say a final farewell to Perl?
----------
components: Library (Lib)
messages: 66817
nosy: mark
severity: normal
status: open
title: Eliminate Perl legacy in re flag names
type: feature request
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2851>
__________________________________
From report at bugs.python.org Wed May 14 18:10:31 2008
From: report at bugs.python.org (Noah Kantrowitz)
Date: Wed, 14 May 2008 16:10:31 +0000
Subject: [New-bugs-announce] [issue2852] sidebar directive fails
In-Reply-To: <1210781431.12.0.00746405494641.issue2852@psf.upfronthosting.co.za>
Message-ID: <1210781431.12.0.00746405494641.issue2852@psf.upfronthosting.co.za>
New submission from Noah Kantrowitz <noah+bugs.python.org at coderanger.net>:
The normal ReST sidebar directive creates a div with the same class as the
HTML sidebar. This makes it not render its contents correctly. Perhaps the
default template/CSS should match on div#sphinxsidebar or similar?
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 66821
nosy: coderanger, georg.brandl
severity: normal
status: open
title: sidebar directive fails
type: feature request
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2852>
__________________________________
From report at bugs.python.org Wed May 14 19:08:13 2008
From: report at bugs.python.org (Michael Lang)
Date: Wed, 14 May 2008 17:08:13 +0000
Subject: [New-bugs-announce] [issue2853] *** glibc detected *** python:
double free or corruption
In-Reply-To: <1210784892.85.0.853831073509.issue2853@psf.upfronthosting.co.za>
Message-ID: <1210784892.85.0.853831073509.issue2853@psf.upfronthosting.co.za>
New submission from Michael Lang <michael.lang at jackal-net.at>:
Hi,
i am trying to solve some problems we encounter, when locking files on a
NFS Storage using fcntl.
since this is a security related problem i just add some pseudo code
here that was used to create the problem
fh = os.open('filename')
fcntl.lockf(fh, fcntl.LOCK_EX)
fhw = os.fdopen(fh)
fhw....
fcntl.lockf(fh, fcntl.LOCK_UN)
...
when using threads, it's possible to create following problems when
using a Solaris (openSolaris) NFS server:
*** glibc detected *** python: double free or corruption (!prev):
0x000000001bdbfb20 ***
======= Backtrace: =========
/lib64/libc.so.6[0x32b086f4f4]
/lib64/libc.so.6(cfree+0x8c)[0x32b0872b1c]
/lib64/libc.so.6(fclose+0x14b)[0x32b085e75b]
/usr/lib64/libpython2.4.so.1.0[0x32c3e447ce]
/usr/lib64/libpython2.4.so.1.0(PyEval_EvalFrame+0x47c7)[0x32c3e947a7]
/usr/lib64/libpython2.4.so.1.0(PyEval_EvalFrame+0x44a6)[0x32c3e94486]
/usr/lib64/libpython2.4.so.1.0(PyEval_EvalCodeEx+0x925)[0x32c3e95905]
/usr/lib64/libpython2.4.so.1.0[0x32c3e4c263]
/usr/lib64/libpython2.4.so.1.0(PyObject_Call+0x10)[0x32c3e35f90]
/usr/lib64/libpython2.4.so.1.0[0x32c3e3c01f]
/usr/lib64/libpython2.4.so.1.0(PyObject_Call+0x10)[0x32c3e35f90]
/usr/lib64/libpython2.4.so.1.0(PyEval_CallObjectWithKeywords+0x6d)[0x32c3e8f55d]
/usr/lib64/libpython2.4.so.1.0[0x32c3ebb33d]
/lib64/libpthread.so.0[0x32b14062f7]
/lib64/libc.so.6(clone+0x6d)[0x32b08ce85d]
======= Memory map: ========
00400000-00401000 r-xp 00000000 fd:01 845448
/usr/bin/python
00600000-00601000 rw-p 00000000 fd:01 845448
/usr/bin/python
1bd4d000-1bdd0000 rw-p 1bd4d000 00:00 0
40000000-40001000 ---p 40000000 00:00 0
40001000-40a01000 rw-p 40001000 00:00 0
40a01000-40a02000 ---p 40a01000 00:00 0
40a02000-41402000 rw-p 40a02000 00:00 0
41402000-41403000 ---p 41402000 00:00 0
41403000-41e03000 rw-p 41403000 00:00 0
41e03000-41e04000 ---p 41e03000 00:00 0
41e04000-42804000 rw-p 41e04000 00:00 0
42804000-42805000 ---p 42804000 00:00 0
42805000-43205000 rw-p 42805000 00:00 0
43205000-43206000 ---p 43205000 00:00 0
43206000-43c06000 rw-p 43206000 00:00 0
43c06000-43c07000 ---p 43c06000 00:00 0
43c07000-44607000 rw-p 43c07000 00:00 0
44607000-44608000 ---p 44607000 00:00 0
44608000-45008000 rw-p 44608000 00:00 0
45008000-45009000 ---p 45008000 00:00 0
45009000-45a09000 rw-p 45009000 00:00 0
45a09000-45a0a000 ---p 45a09000 00:00 0
45a0a000-4640a000 rw-p 45a0a000 00:00 0
32b0400000-32b041a000 r-xp 00000000 fd:00 127400
/lib64/ld-2.5.so
32b0619000-32b061a000 r--p 00019000 fd:00 127400
/lib64/ld-2.5.so
32b061a000-32b061b000 rw-p 0001a000 fd:00 127400
/lib64/ld-2.5.so
32b0800000-32b0946000 r-xp 00000000 fd:00 127417
/lib64/libc-2.5.so
32b0946000-32b0b46000 ---p 00146000 fd:00 127417
/lib64/libc-2.5.so
32b0b46000-32b0b4a000 r--p 00146000 fd:00 127417
/lib64/libc-2.5.so
32b0b4a000-32b0b4b000 rw-p 0014a000 fd:00 127417
/lib64/libc-2.5.so
32b0b4b000-32b0b50000 rw-p 32b0b4b000 00:00 0
32b0c00000-32b0c82000 r-xp 00000000 fd:00 127423
/lib64/libm-2.5.so
32b0c82000-32b0e81000 ---p 00082000 fd:00 127423
/lib64/libm-2.5.so
32b0e81000-32b0e82000 r--p 00081000 fd:00 127423
/lib64/libm-2.5.so
32b0e82000-32b0e83000 rw-p 00082000 fd:00 127423
/lib64/libm-2.5.so
32b1000000-32b1002000 r-xp 00000000 fd:00 127455
/lib64/libdl-2.5.so
32b1002000-32b1202000 ---p 00002000 fd:00 127455
/lib64/libdl-2.5.so
32b1202000-32b1203000 r--p 00002000 fd:00 127455
/lib64/libdl-2.5.so
32b1203000-32b1204000 rw-p 00003000 fd:00 127455
/lib64/libdl-2.5.so
32b1400000-32b1415000 r-xp 00000000 fd:00 127463
/lib64/libpthread-2.5.so
32b1415000-32b1614000 ---p 00015000 fd:00 127463
/lib64/libpthread-2.5.so
32b1614000-32b1615000 r--p 00014000 fd:00 127463
/lib64/libpthread-2.5.so
32b1615000-32b1616000 rw-p 00015000 fd:00 127463
/lib64/libpthread-2.5.so
32b1616000-32b161a000 rw-p 32b1616000 00:00 0
32b6400000-32b640d000 r-xp 00000000 fd:00 127465
/lib64/libgcc_s-4.1.2-20070626.so.1
32b640d000-32b660d000 ---p 0000d000 fd:00 127465
/lib64/libgcc_s-4.1.2-2Segmentation fault
python imported modules/functions
from threading import Thread
import fcntl
from os import O_APPEND, O_CREAT, O_EXCL, O_LARGEFILE, O_NDELAY, ...
from time import asctime, localtime, sleep
from os import open as oopen
from os import fdopen
import sys
is this a "python" bug ? or am i doing something wrong ... the real code
will be available to troubleshoot the problem on request
regards
>>> import sys
>>> sys.version
'2.4.3 (#1, Mar 14 2007, 19:01:42) \n[GCC 4.1.1 20070105 (Red Hat
4.1.1-52)]'
----------
components: Interpreter Core
messages: 66825
nosy: nuddelaug
severity: normal
status: open
title: *** glibc detected *** python: double free or corruption
type: crash
versions: Python 2.4
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2853>
__________________________________
From report at bugs.python.org Wed May 14 22:09:39 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 14 May 2008 20:09:39 +0000
Subject: [New-bugs-announce] [issue2854] Add gestalt back into Python 3.0
In-Reply-To: <1210795778.91.0.672202960486.issue2854@psf.upfronthosting.co.za>
Message-ID: <1210795778.91.0.672202960486.issue2854@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
gestalt was removed as part of the stdlib cleanup for Mac code. But it
turns out that gestalt is one of those modules that is just needed. Either
the original version needs to be added back in or a ctypes version needs
to be implemented. Either way, something to get system info needs to be
added back into the stdlib (and probably go into plat-darwin).
----------
components: Library (Lib)
messages: 66828
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Add gestalt back into Python 3.0
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2854>
__________________________________
From report at bugs.python.org Wed May 14 22:09:57 2008
From: report at bugs.python.org (Adam Olsen)
Date: Wed, 14 May 2008 20:09:57 +0000
Subject: [New-bugs-announce] [issue2855] lookkey should INCREF/DECREF
startkey around PyObject_RichCompareBool
In-Reply-To: <1210795797.23.0.868433377408.issue2855@psf.upfronthosting.co.za>
Message-ID: <1210795797.23.0.868433377408.issue2855@psf.upfronthosting.co.za>
New submission from Adam Olsen <rhamph at gmail.com>:
sets are based on dicts' code, so they have the same problem as bug
1517. Patch attached.
----------
files: python-lookkeycompare.diff
keywords: patch
messages: 66829
nosy: Rhamphoryncus
severity: normal
status: open
title: lookkey should INCREF/DECREF startkey around PyObject_RichCompareBool
Added file: http://bugs.python.org/file10322/python-lookkeycompare.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2855>
__________________________________
From report at bugs.python.org Thu May 15 03:16:48 2008
From: report at bugs.python.org (Brodie Rao)
Date: Thu, 15 May 2008 01:16:48 +0000
Subject: [New-bugs-announce] [issue2856] os.listdir doc should mention that
Unicode decoding can fail
In-Reply-To: <1210814208.45.0.272157928062.issue2856@psf.upfronthosting.co.za>
Message-ID: <1210814208.45.0.272157928062.issue2856@psf.upfronthosting.co.za>
New submission from Brodie Rao <junk at dackz.net>:
The documentation for os.listdir should mention that there's a
possibility that it can fail to decode paths to unicode objects and that
it returns str objects for those paths it couldn't decode.
The documentation should also explain when this might happen, and
perhaps how to deal with it. The cases that this could happen or how to
work around it are beyond my knowledge, but #683592 does mention
something about resetting the locale. I don't know if that comment is
still relevant, or if it applies to all cases of decoding failure,
however.
I don't know if this behavior still exists in Python 2.6. If it does,
the documentation for 2.6 should be amended as well.
----------
assignee: georg.brandl
components: Documentation
messages: 66839
nosy: brodierao, georg.brandl
severity: normal
status: open
title: os.listdir doc should mention that Unicode decoding can fail
type: behavior
versions: Python 2.3, Python 2.4, Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2856>
__________________________________
From report at bugs.python.org Thu May 15 05:08:40 2008
From: report at bugs.python.org (paul rubin)
Date: Thu, 15 May 2008 03:08:40 +0000
Subject: [New-bugs-announce] [issue2857] add coded for java modified utf-8
In-Reply-To: <1210820919.45.0.733381289954.issue2857@psf.upfronthosting.co.za>
Message-ID: <1210820919.45.0.733381289954.issue2857@psf.upfronthosting.co.za>
New submission from paul rubin <phr at users.sourceforge.net>:
For object serialization and some other purposes, Java encodes unicode
strings with a modified version of utf-8:
http://en.wikipedia.org/wiki/UTF-8#Java
http://java.sun.com/javase/6/docs/api/java/io/DataInput.html#modified-utf-8
It is used in Lucene index files among other places.
It would be useful if Python had a codec for this, maybe called "UTF-8J"
or something like that.
----------
components: Library (Lib)
messages: 66843
nosy: phr
severity: normal
status: open
title: add coded for java modified utf-8
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2857>
__________________________________
From report at bugs.python.org Thu May 15 07:10:09 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 15 May 2008 05:10:09 +0000
Subject: [New-bugs-announce] [issue2858] bsddb.db.DBEnv.lock_get
test_lock.test03_set_timeout crashes
In-Reply-To: <1210828209.22.0.850566546074.issue2858@psf.upfronthosting.co.za>
Message-ID: <1210828209.22.0.850566546074.issue2858@psf.upfronthosting.co.za>
New submission from Gregory P. Smith <greg at krypto.org>:
I disabled the Lib/bsddb/test/test_lock.py test03_set_timeout test as it
crashes the interpreter when compiled in debug mode with an UNREF test.
It appears to happen on all platforms according to the buildbots.
This is not a new problem, it exists in 2.5 if a backport the recent
updates to this test.
I did a little bit of debugging and it looks like the UNREF failure
occurs when the call to DBEnv.lock_get is has exited and Python is
freeing the internal callargs tuple passed as arguments to the method.
A pointer in the callargs._ob_prev structure had the 0xdbdbdbdb value
which I believe is a sign of BerkeleyDB overwriting the memory.
Jesus, can you look into this one?
----------
components: Extension Modules
messages: 66845
nosy: gregory.p.smith, jcea
priority: high
severity: normal
status: open
title: bsddb.db.DBEnv.lock_get test_lock.test03_set_timeout crashes
type: crash
versions: Python 2.5, Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2858>
__________________________________
From report at bugs.python.org Thu May 15 08:12:32 2008
From: report at bugs.python.org (Peter)
Date: Thu, 15 May 2008 06:12:32 +0000
Subject: [New-bugs-announce] [issue2859] sphinx and virtualenv
In-Reply-To: <1210831952.05.0.738382267541.issue2859@psf.upfronthosting.co.za>
Message-ID: <1210831952.05.0.738382267541.issue2859@psf.upfronthosting.co.za>
New submission from Peter <pkoppatz at web.de>:
I tried to install sphinx with virtualenv.The error message is showing a
missing file:
...
INFORMATION
the speedup extension could not be compiled, Jinja will
fall back to the native python classes.
===============================================================================
error: Setup script exited with error: can't copy
'Jinja.egg-info/native_libs.txt': doesn't exist or not a regular file
[@|] (todo_sphinx)peter at zuse03 ~/_kurse/zope3/todo_sphinx $
./bin/sphinx-quickstart --help
Traceback (most recent call last):
File "./bin/sphinx-quickstart", line 5, in ?
from pkg_resources import load_entry_point
File
"/home/peter/_kurse/zope3/todo_sphinx/lib/python2.4/site-packages/setuptools-0.6c7-py2.4.egg/pkg_resources.py",
line 2561, in ?
working_set.require(__requires__)
File
"/home/peter/_kurse/zope3/todo_sphinx/lib/python2.4/site-packages/setuptools-0.6c7-py2.4.egg/pkg_resources.py",
line 626, in require
needed = self.resolve(parse_requirements(requirements))
File
"/home/peter/_kurse/zope3/todo_sphinx/lib/python2.4/site-packages/setuptools-0.6c7-py2.4.egg/pkg_resources.py",
line 524, in resolve
raise DistributionNotFound(req) # XXX put more info here
pkg_resources.DistributionNotFound: Jinja>=1.1
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 66846
nosy: georg.brandl, peterK
severity: normal
status: open
title: sphinx and virtualenv
versions: Python 2.4
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2859>
__________________________________
From report at bugs.python.org Thu May 15 10:08:23 2008
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 15 May 2008 08:08:23 +0000
Subject: [New-bugs-announce] [issue2860] re module fails to handle digits in
byte strings
In-Reply-To: <1210838903.44.0.718972367839.issue2860@psf.upfronthosting.co.za>
Message-ID: <1210838903.44.0.718972367839.issue2860@psf.upfronthosting.co.za>
New submission from Stefan Behnel <scoder at users.sourceforge.net>:
The following fails in Py3.0a5:
>>> import re
>>> re.search(b'(\d+)', b'-2.80 98\n')
I get a TypeError: "Can't convert 'int' object to str implicitly" in
line 204 of file "sre_parse.py", code being "char = char + c".
----------
components: Library (Lib)
messages: 66848
nosy: scoder
severity: normal
status: open
title: re module fails to handle digits in byte strings
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2860>
__________________________________
From report at bugs.python.org Thu May 15 11:42:41 2008
From: report at bugs.python.org (Quentin Gallet-Gilles)
Date: Thu, 15 May 2008 09:42:41 +0000
Subject: [New-bugs-announce] [issue2861] Patch to rename markupbase to
_markupbase
In-Reply-To: <1210844561.67.0.674925614552.issue2861@psf.upfronthosting.co.za>
Message-ID: <1210844561.67.0.674925614552.issue2861@psf.upfronthosting.co.za>
New submission from Quentin Gallet-Gilles <qgallet at gmail.com>:
Before applying the attached patch, the command 'svn move
Lib/markupbase.py Lib/_markupbase.py" must be invoked.
Little reminder : since the changes are already applied in the 3.0
codebase, the patch should also be blocked from the py3k branch.
I'll also add another patch with the 2to3 import fixer.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool), Library (Lib)
files: markupbase_renaming_2.6.patch
keywords: patch
messages: 66850
nosy: collinwinter, quentin.gallet-gilles
severity: normal
status: open
title: Patch to rename markupbase to _markupbase
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file10327/markupbase_renaming_2.6.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2861>
__________________________________
From report at bugs.python.org Thu May 15 15:46:21 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Thu, 15 May 2008 13:46:21 +0000
Subject: [New-bugs-announce] [issue2862] cleanup of freelist management
In-Reply-To: <1210859181.3.0.311974356319.issue2862@psf.upfronthosting.co.za>
Message-ID: <1210859181.3.0.311974356319.issue2862@psf.upfronthosting.co.za>
New submission from Andrew I MacIntyre <aimacintyre at users.sourceforge.net>:
In r60567, support for compacting the int & float freelists was added
with a function in the sys module to call the compaction routines.
Since then, other freelist clearing routines have been added to other
types and are called from the collect() function in the gc module.
The attached patch harmonises the in/float freelist compaction with the
other freelist clearing mechanisms. It does away with the function in
the sys module in favour of running the freelist clearing from gc.collect().
The signatures of the type specific freelist clearing routines have been
brought into line with the other type freelist clearing routines, with
the exception that they return the number of items _not_ free()ed,
rather than the number of items free()ed. I took this approach to try
and highlight the fact the current int/float freelist implementations
don't use pymalloc and not all items will always be free()ed when the
routine is called. This return is ignored when called from gc.collect()
in any case.
The patch includes doc updates and test updates to reflect the changes.
It has been tested on FreeBSD 6.3, surviving a default test run with no
unusual test failures as far as I can tell. It is not otherwise
rigorously tested.
The patch is against a trunk checkout that seems to be at r63156.
Ideally this patch, or similar modifications, should be applied before
the feature freeze for 2.6, so that freelist management is rationalised
to one way to do it.
----------
assignee: christian.heimes
components: Documentation, Interpreter Core, Tests
files: freelist_mgt_cleanup.patch
keywords: patch, patch
messages: 66858
nosy: aimacintyre, christian.heimes
priority: high
severity: normal
status: open
title: cleanup of freelist management
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file10331/freelist_mgt_cleanup.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2862>
__________________________________
From report at bugs.python.org Thu May 15 16:25:12 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 15 May 2008 14:25:12 +0000
Subject: [New-bugs-announce] [issue2863] Generator __name__ and better repr()
In-Reply-To: <1210861511.93.0.62534649214.issue2863@psf.upfronthosting.co.za>
Message-ID: <1210861511.93.0.62534649214.issue2863@psf.upfronthosting.co.za>
New submission from Georg Brandl <georg at python.org>:
As discussed on python-ideas:
http://mail.python.org/pipermail/python-ideas/2008-May/001570.html
----------
assignee: gvanrossum
components: Interpreter Core
files: gen-name.diff
keywords: patch, patch
messages: 66859
nosy: georg.brandl, gvanrossum
priority: normal
severity: normal
status: open
title: Generator __name__ and better repr()
type: feature request
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10332/gen-name.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2863>
__________________________________
From report at bugs.python.org Thu May 15 16:50:13 2008
From: report at bugs.python.org (Thomas Guettler)
Date: Thu, 15 May 2008 14:50:13 +0000
Subject: [New-bugs-announce] [issue2864] etree: Add XPath documentation
In-Reply-To: <1210863012.97.0.696135529968.issue2864@psf.upfronthosting.co.za>
Message-ID: <1210863012.97.0.696135529968.issue2864@psf.upfronthosting.co.za>
New submission from Thomas Guettler <guettli at thomas-guettler.de>:
The current documentation of etree [1] does not explain the
syntax of the supported xpaths.
[1] current documation:
http://docs.python.org/lib/elementtree-elementtree-objects.html
[2] ElementTree supported XPath:
http://effbot.org/zone/element-xpath.htm
It would be very nice to have some simple examples for myetree.find(xpath).
----------
assignee: georg.brandl
components: Documentation
messages: 66863
nosy: georg.brandl, guettli
severity: normal
status: open
title: etree: Add XPath documentation
type: feature request
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2864>
__________________________________
From report at bugs.python.org Thu May 15 17:14:14 2008
From: report at bugs.python.org (Stijn van Drongelen)
Date: Thu, 15 May 2008 15:14:14 +0000
Subject: [New-bugs-announce] [issue2865] syntax error in fix_imports.py
In-Reply-To: <1210864454.67.0.912563715467.issue2865@psf.upfronthosting.co.za>
Message-ID: <1210864454.67.0.912563715467.issue2865@psf.upfronthosting.co.za>
New submission from Stijn van Drongelen <S.vanDrongelen at students.uu.nl>:
In the current revision of 2to3 (63319), somebody forgot a comma at the
end of line 27 of lib2to3/fix_imports.py, resulting in a syntax error.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: fix_imports-syntaxerror-63319.patch
keywords: patch
messages: 66867
nosy: Tinctorius, collinwinter
severity: normal
status: open
title: syntax error in fix_imports.py
type: compile error
Added file: http://bugs.python.org/file10333/fix_imports-syntaxerror-63319.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2865>
__________________________________
From report at bugs.python.org Thu May 15 17:14:34 2008
From: report at bugs.python.org (Stijn van Drongelen)
Date: Thu, 15 May 2008 15:14:34 +0000
Subject: [New-bugs-announce] [issue2866] syntax error in fix_imports.py
In-Reply-To: <1210864474.73.0.391554702591.issue2866@psf.upfronthosting.co.za>
Message-ID: <1210864474.73.0.391554702591.issue2866@psf.upfronthosting.co.za>
New submission from Stijn van Drongelen <S.vanDrongelen at students.uu.nl>:
In the current revision of 2to3 (63319), somebody forgot a comma at the
end of line 27 of lib2to3/fix_imports.py, resulting in a syntax error.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: fix_imports-syntaxerror-63319.patch
keywords: patch
messages: 66869
nosy: Tinctorius, collinwinter
severity: normal
status: open
title: syntax error in fix_imports.py
type: compile error
Added file: http://bugs.python.org/file10334/fix_imports-syntaxerror-63319.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2866>
__________________________________
From report at bugs.python.org Thu May 15 19:03:11 2008
From: report at bugs.python.org (Devin Jeanpierre)
Date: Thu, 15 May 2008 17:03:11 +0000
Subject: [New-bugs-announce] [issue2867] curses-howto link in curses module
documentation gives a 404
In-Reply-To: <1210870990.17.0.248799344481.issue2867@psf.upfronthosting.co.za>
Message-ID: <1210870990.17.0.248799344481.issue2867@psf.upfronthosting.co.za>
New submission from Devin Jeanpierre <jeanpierreda at gmail.com>:
In the curses module documentation < http://docs.python.org/lib/module-
curses.html >, there is a link to a curses-howto, at <
http://www.python.org/doc/howto/curses/curses.html >. That page doesn't
exist: it gives an HTTP 404.
I am aware that the last time I reported a documentation error it was
actually fixed in the unreleased most recent version of the docs. I am
not sure where that was meant-- I can't find anything but the 2.6 alpha
docs < http://docs.python.org/dev/ >, where the error is indeed
corrected (< http://docs.python.org/dev/library/curses.html >, <
http://docs.python.org/dev/howto/curses.html >). If was what was meant
(I'd always thought that errors would get corrected right away (in the
same version), so it doesn't fit with my expectations), then I
apologize for making a wasteful report. I figured that it would be
better to risk a bit of time wasted than leave an error until later.
----------
assignee: georg.brandl
components: Documentation
messages: 66871
nosy: Devin Jeanpierre, georg.brandl
severity: normal
status: open
title: curses-howto link in curses module documentation gives a 404
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2867>
__________________________________
From report at bugs.python.org Thu May 15 19:35:18 2008
From: report at bugs.python.org (Ambarish Malpani)
Date: Thu, 15 May 2008 17:35:18 +0000
Subject: [New-bugs-announce] [issue2868] Problem with urllib and urllib2 in
urlopen?
In-Reply-To: <1210872918.44.0.781386707742.issue2868@psf.upfronthosting.co.za>
Message-ID: <1210872918.44.0.781386707742.issue2868@psf.upfronthosting.co.za>
New submission from Ambarish Malpani <ambarish at yahoo.com>:
I have the following code:
import urllib
u = 'http://www.mercurynews.com/ci_9216417'
h = urllib.urlopen(u).read()
print h
# Get an empty string
#(can use urllib2 also - get the same behavior)
If I visit the same page with my browser, get the contents of the page
(after some redirects...)
----------
components: Extension Modules
messages: 66872
nosy: ambarish
severity: normal
status: open
title: Problem with urllib and urllib2 in urlopen?
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2868>
__________________________________
From report at bugs.python.org Thu May 15 20:14:18 2008
From: report at bugs.python.org (Jochen Kupperschmidt)
Date: Thu, 15 May 2008 18:14:18 +0000
Subject: [New-bugs-announce] [issue2869] Wrong doc for
`calendar.Calendar.iterweekdays`
In-Reply-To: <1210875257.46.0.726174573952.issue2869@psf.upfronthosting.co.za>
Message-ID: <1210875257.46.0.726174573952.issue2869@psf.upfronthosting.co.za>
New submission from Jochen Kupperschmidt <yo.gi at nwsnet.de>:
The documentation for `calendar.Calendar.iterweekdays` (both 2.5 and
2.6a3 online) states that the method would take an argument `weekday`.
However, testing it and looking at the module source reveals that it
takes no arguments.
----------
assignee: georg.brandl
components: Documentation
messages: 66874
nosy: georg.brandl, yogi
severity: normal
status: open
title: Wrong doc for `calendar.Calendar.iterweekdays`
versions: Python 2.5, Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2869>
__________________________________
From report at bugs.python.org Thu May 15 23:43:10 2008
From: report at bugs.python.org (Juno)
Date: Thu, 15 May 2008 21:43:10 +0000
Subject: [New-bugs-announce] [issue2870] cmathmodule.c compile error
In-Reply-To: <1210887790.81.0.134090801256.issue2870@psf.upfronthosting.co.za>
Message-ID: <1210887790.81.0.134090801256.issue2870@psf.upfronthosting.co.za>
New submission from Juno <stephane.jeannenot at orange.fr>:
Building on Linux Debian Etch 2.6.18-6-k7 #1 SMP Thu May 8 08:09:57 UTC
2008 i686 GNU/Linux
Python version 2.6 svn trunk:63321
Compiler : GCC 4.1.2
Compile error in Modules/cmathmodule.c
Detailled error message follows :
building 'cmath' extension
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/data/User/AppSVN/Python/./Include -I.
-IInclude -I./Include -I/usr/local/include
-I/data/User/AppSVN/Python/Include -I/data/User/AppSVN/Python -c
/data/User/AppSVN/Python/Modules/cmathmodule.c -o
build/temp.linux-i686-2.6/data/User/AppSVN/Python/Modules/cmathmodule.o
/data/User/AppSVN/Python/Modules/cmathmodule.c: In function 'cmath_phase':
/data/User/AppSVN/Python/Modules/cmathmodule.c:923: error: 'r'
undeclared (first use in this function)
/data/User/AppSVN/Python/Modules/cmathmodule.c:923: error: (Each
undeclared identifier is reported only once
/data/User/AppSVN/Python/Modules/cmathmodule.c:923: error: for each
function it appears in.)
Checking previous function in the file cmathmodule.c, it seems that you
have to declare line 916 :
Py_complex z,r;
After this correction the compilation is ok. I do not test the function
itself, I just try to have the code compiling.
----------
components: Extension Modules
messages: 66880
nosy: Juno
severity: normal
status: open
title: cmathmodule.c compile error
type: compile error
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2870>
__________________________________
From report at bugs.python.org Thu May 15 23:50:55 2008
From: report at bugs.python.org (Irmen de Jong)
Date: Thu, 15 May 2008 21:50:55 +0000
Subject: [New-bugs-announce] [issue2871] store thread.get_ident() thread
identifier inside threading.Thread objects
In-Reply-To: <1210888254.97.0.197047518827.issue2871@psf.upfronthosting.co.za>
Message-ID: <1210888254.97.0.197047518827.issue2871@psf.upfronthosting.co.za>
New submission from Irmen de Jong <irmen at users.sourceforge.net>:
I've ran into a problem where it would be very nice to be able to tell
the tread.get_ident() of a given threading.Thread object.
Currently, when creating a new Thread object, there is no good way of
getting that thread's get_ident() value.
I propose adding the get_ident() value as a publicly accessible field of
every threading.Thread object.
----------
components: Extension Modules
messages: 66882
nosy: irmen
severity: normal
status: open
title: store thread.get_ident() thread identifier inside threading.Thread objects
type: feature request
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2871>
__________________________________
From report at bugs.python.org Fri May 16 06:37:28 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 May 2008 04:37:28 +0000
Subject: [New-bugs-announce] [issue2872] Remove commands for PEP 3108
In-Reply-To: <1210912647.86.0.565995912638.issue2872@psf.upfronthosting.co.za>
Message-ID: <1210912647.86.0.565995912638.issue2872@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
The commands module is slated to go. The getstatus() function needs to be
deprecated, with the rest of the module moving into subprocess (and thus
adding commands to the 2to3 fix_import fixer).
----------
components: Library (Lib)
messages: 66894
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Remove commands for PEP 3108
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2872>
__________________________________
From report at bugs.python.org Fri May 16 06:44:05 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 May 2008 04:44:05 +0000
Subject: [New-bugs-announce] [issue2873] Remove htmllib use in the stdlib
In-Reply-To: <1210913045.12.0.944933316665.issue2873@psf.upfronthosting.co.za>
Message-ID: <1210913045.12.0.944933316665.issue2873@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
htmllib cannot be removed from 3.0 until its use is removed from pydoc.
----------
components: Library (Lib)
messages: 66897
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Remove htmllib use in the stdlib
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2873>
__________________________________
From report at bugs.python.org Fri May 16 06:45:45 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 May 2008 04:45:45 +0000
Subject: [New-bugs-announce] [issue2874] Remove use of the stat module in
the stdlib
In-Reply-To: <1210913145.44.0.456986373707.issue2874@psf.upfronthosting.co.za>
Message-ID: <1210913145.44.0.456986373707.issue2874@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
The stat module is slated to go in Python 3.0, but that can't happen until
all uses of the module are gone. This will require moving over to using
the named tuple features of os.stat() along with adding methods to the
object that the stat module has as functions.
----------
components: Library (Lib)
messages: 66898
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Remove use of the stat module in the stdlib
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2874>
__________________________________
From report at bugs.python.org Fri May 16 06:46:45 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 May 2008 04:46:45 +0000
Subject: [New-bugs-announce] [issue2875] Rename the thread module to _thread
In-Reply-To: <1210913205.44.0.787741913156.issue2875@psf.upfronthosting.co.za>
Message-ID: <1210913205.44.0.787741913156.issue2875@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
PEP 3108 has thread slated to be renamed _thread (along with dummy_thread
to _dummy_thread).
----------
components: Library (Lib)
messages: 66899
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Rename the thread module to _thread
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2875>
__________________________________
From report at bugs.python.org Fri May 16 06:49:08 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 May 2008 04:49:08 +0000
Subject: [New-bugs-announce] [issue2876] Backport UserDict move in 3.0
In-Reply-To: <1210913348.4.0.543107843307.issue2876@psf.upfronthosting.co.za>
Message-ID: <1210913348.4.0.543107843307.issue2876@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
In Python 3.0, the UserDict module was removed and the UserDict class was
moved to the collections module. That change-over needs to be backported
to 2.6 so that the UserDict module can be deprecated.
----------
components: Library (Lib)
messages: 66900
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Backport UserDict move in 3.0
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2876>
__________________________________
From report at bugs.python.org Fri May 16 06:50:06 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 May 2008 04:50:06 +0000
Subject: [New-bugs-announce] [issue2877] Backport UserString move from 3.0
In-Reply-To: <1210913405.95.0.573859631329.issue2877@psf.upfronthosting.co.za>
Message-ID: <1210913405.95.0.573859631329.issue2877@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
The UserString class was moved from its own module to the collections
module. That change needs to be backported.
----------
components: Library (Lib)
messages: 66901
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Backport UserString move from 3.0
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2877>
__________________________________
From report at bugs.python.org Fri May 16 06:51:10 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 May 2008 04:51:10 +0000
Subject: [New-bugs-announce] [issue2878] Backport UserList move in 3.0
In-Reply-To: <1210913470.53.0.764611269723.issue2878@psf.upfronthosting.co.za>
Message-ID: <1210913470.53.0.764611269723.issue2878@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
The UserList class was moved from the UserList module to the collections
module. That move along with the stdlib update needs to be backported to
2.6.
----------
components: Library (Lib)
messages: 66902
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Backport UserList move in 3.0
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2878>
__________________________________
From report at bugs.python.org Fri May 16 06:52:06 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 May 2008 04:52:06 +0000
Subject: [New-bugs-announce] [issue2879] Rename _winreg to winreg
In-Reply-To: <1210913526.61.0.164470356579.issue2879@psf.upfronthosting.co.za>
Message-ID: <1210913526.61.0.164470356579.issue2879@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
The _winreg module needs to be renamed winreg for PEP 3108.
----------
components: Library (Lib)
messages: 66903
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Rename _winreg to winreg
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2879>
__________________________________
From report at bugs.python.org Fri May 16 07:03:20 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 May 2008 05:03:20 +0000
Subject: [New-bugs-announce] [issue2880] Rename repr to reprlib
In-Reply-To: <1210914200.71.0.373705833301.issue2880@psf.upfronthosting.co.za>
Message-ID: <1210914200.71.0.373705833301.issue2880@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
The repr module is slated to be renamed reprlib in PEP 3108.
----------
components: Library (Lib)
messages: 66907
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Rename repr to reprlib
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2880>
__________________________________
From report at bugs.python.org Fri May 16 07:05:27 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 May 2008 05:05:27 +0000
Subject: [New-bugs-announce] [issue2881] Create the dbm package
In-Reply-To: <1210914327.93.0.813244927721.issue2881@psf.upfronthosting.co.za>
Message-ID: <1210914327.93.0.813244927721.issue2881@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
The dbm package as outlined in PEP 3108 needs to be created.
----------
components: Library (Lib)
messages: 66908
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Create the dbm package
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2881>
__________________________________
From report at bugs.python.org Fri May 16 07:06:17 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 May 2008 05:06:17 +0000
Subject: [New-bugs-announce] [issue2882] Create the html package
In-Reply-To: <1210914377.14.0.176353307506.issue2882@psf.upfronthosting.co.za>
Message-ID: <1210914377.14.0.176353307506.issue2882@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
The html package as outlined in PEP 3108 needs to be created.
----------
components: Library (Lib)
messages: 66909
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Create the html package
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2882>
__________________________________
From report at bugs.python.org Fri May 16 07:07:26 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 May 2008 05:07:26 +0000
Subject: [New-bugs-announce] [issue2883] Create the http package
In-Reply-To: <1210914446.04.0.852197194543.issue2883@psf.upfronthosting.co.za>
Message-ID: <1210914446.04.0.852197194543.issue2883@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Create the http package as outlined in PEP 3108.
Initial patches exist in issue 2775.
----------
components: Library (Lib)
messages: 66910
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Create the http package
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2883>
__________________________________
From report at bugs.python.org Fri May 16 07:10:08 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 May 2008 05:10:08 +0000
Subject: [New-bugs-announce] [issue2884] Create the tkinter package
In-Reply-To: <1210914608.62.0.531820285886.issue2884@psf.upfronthosting.co.za>
Message-ID: <1210914608.62.0.531820285886.issue2884@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
The tkinter package as outlined in PEP 3108 needs to be created.
See issue 2775 for initial patches.
----------
components: Library (Lib)
keywords: patch
messages: 66912
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Create the tkinter package
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2884>
__________________________________
From report at bugs.python.org Fri May 16 07:11:31 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 May 2008 05:11:31 +0000
Subject: [New-bugs-announce] [issue2885] Create the urllib package
In-Reply-To: <1210914691.08.0.848288242706.issue2885@psf.upfronthosting.co.za>
Message-ID: <1210914691.08.0.848288242706.issue2885@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
The urllib package as outlined in PEP 3108 needs to be created.
----------
assignee: jhylton
components: Library (Lib)
messages: 66913
nosy: brett.cannon, jhylton
priority: release blocker
severity: normal
status: open
title: Create the urllib package
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2885>
__________________________________
From report at bugs.python.org Fri May 16 07:13:41 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 May 2008 05:13:41 +0000
Subject: [New-bugs-announce] [issue2886] Create the xmlrpc package
In-Reply-To: <1210914821.89.0.572470213845.issue2886@psf.upfronthosting.co.za>
Message-ID: <1210914821.89.0.572470213845.issue2886@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
The xmlrpc package as outlined in PEP 3108 needs to be created.
----------
components: Library (Lib)
messages: 66916
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Create the xmlrpc package
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2886>
__________________________________
From report at bugs.python.org Fri May 16 07:27:42 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 16 May 2008 05:27:42 +0000
Subject: [New-bugs-announce] [issue2887] bsddb 4.6.4 needs to be ported to
Python 3.0
In-Reply-To: <1210915662.48.0.494614370174.issue2887@psf.upfronthosting.co.za>
Message-ID: <1210915662.48.0.494614370174.issue2887@psf.upfronthosting.co.za>
New submission from Alexandre Vassalotti <alexandre at peadrop.com>:
The recent updates to bsddb (r63207, r63210 and r63218) needs to
forward-ported to the py3k branch.
At first glance, here is the things that needs to be done in the test suite:
- Change the import:
from test_all import ...
into a relative import:
from .test_all import ...
- Replace code incompatible with 3.0, such as changing
``dict.has_key(key)`` to ``key in dict``.
- Change str literals to bytes literals where appropriate.
- Optional: change code like ``type([])`` or ``type(())`` to
respectively ``list`` and ``tuple``.
- Change print statements into print() calls.
- Change ``x != None`` to ``x is not None``.
In the modules:
- Change PyInt__* to PyLong_*.
- Update the PyTypeObject declaration:
statichere PyTypeObject DB_Type = {
PyObject_HEAD_INIT(NULL)
0, /*ob_size*/
"DB", /*tp_name*/
sizeof(DBObject), /*tp_basicsize*/
...
to:
static PyTypeObject DB_Type = {
PyVarObject_HEAD_INIT(NULL, 0)
"DB", /*tp_name*/
sizeof(DBObject), /*tp_basicsize*/
...
- Update module init declaration:
DL_EXPORT(void) init_bsddb(void)
{
...
to:
PyMODINIT_FUNC init_bsddb(void)
{
...
- Remove Py_TPFLAGS_HAVE_WEAKREFS.
- Change PyString_* calls to PyUnicode_* where appropriate.
There probably other things that I missed, but that should give you a
good start.
----------
components: Extension Modules, Library (Lib), Tests
messages: 66918
nosy: alexandre.vassalotti, gregory.p.smith, jcea
priority: normal
severity: normal
status: open
title: bsddb 4.6.4 needs to be ported to Python 3.0
type: feature request
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2887>
__________________________________
From report at bugs.python.org Fri May 16 08:10:56 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 16 May 2008 06:10:56 +0000
Subject: [New-bugs-announce] [issue2888] pprint produces different output in
2.6 and 3.0
In-Reply-To: <1210918255.72.0.267363953828.issue2888@psf.upfronthosting.co.za>
Message-ID: <1210918255.72.0.267363953828.issue2888@psf.upfronthosting.co.za>
New submission from Alexandre Vassalotti <alexandre at peadrop.com>:
The indent argument produces different output in Python 2.6 and 3.0:
Python 3.0a5+ (py3k:63349:63350M, May 16 2008, 00:37:17)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pprint
>>> stuff = ['spam', 'eggs', 'lumberjack', 'knights', 'ni']
>>> stuff.insert(0, stuff[:])
>>> pprint.pprint(stuff, indent=4)
[ ['spam', 'eggs', 'lumberjack', 'knights', 'ni'],
'spam',
'eggs',
'lumberjack',
'knights',
'ni']
Python 2.6a3+ (trunk:63323, May 15 2008, 16:09:01)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pprint
>>> stuff = ['spam', 'eggs', 'lumberjack', 'knights', 'ni']
>>> stuff.insert(0, stuff[:])
>>> pprint.pprint(stuff, indent=4)
[ [ 'spam', 'eggs', 'lumberjack', 'knights', 'ni'],
'spam',
'eggs',
'lumberjack',
'knights',
'ni']
----------
components: Library (Lib)
messages: 66919
nosy: alexandre.vassalotti
priority: low
severity: normal
status: open
title: pprint produces different output in 2.6 and 3.0
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2888>
__________________________________
From report at bugs.python.org Fri May 16 08:38:27 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 16 May 2008 06:38:27 +0000
Subject: [New-bugs-announce] [issue2889] curses for windows (alternative
patch)
In-Reply-To: <1210919907.42.0.842256015219.issue2889@psf.upfronthosting.co.za>
Message-ID: <1210919907.42.0.842256015219.issue2889@psf.upfronthosting.co.za>
New submission from anatoly techtonik <techtonik at gmail.com>:
Make curses available on Windows by using PDCurses library. Alternative
patch for issue 1005895 using current trunk.
Attached .bat file is used to compile it under MinGW, but I'd be glad to
know how to integrate the patch into Python build system.
PDCurses includes support for mouse functions compatible with ncurses,
but to turn it on if requires to define NCURSES_MOUSE_VERSION to 2
before <curses.h> is included. I am not familiar with configure.* stuff,
so I've just pasted required definitions into _cursesmodule.c
With attached .bat file it works by external definition.
Some functions, such as initterm are not available on Windows platform
and were defined out.
I hope that curses module will be included in next Python 2.6
----------
components: Extension Modules
files: curses_win_port.patch.txt
messages: 66920
nosy: techtonik
severity: normal
status: open
title: curses for windows (alternative patch)
versions: Python 2.6
Added file: http://bugs.python.org/file10339/curses_win_port.patch.txt
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2889>
__________________________________
From report at bugs.python.org Fri May 16 09:25:08 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Fri, 16 May 2008 07:25:08 +0000
Subject: [New-bugs-announce] [issue2890] O_ASYNC and FASYNC should be
defined for *nix systems
In-Reply-To: <1210922705.9.0.115557259504.issue2890@psf.upfronthosting.co.za>
Message-ID: <1210922705.9.0.115557259504.issue2890@psf.upfronthosting.co.za>
New submission from Ismail Donmez <ismail at namtrac.org>:
os module have varios O_ declerations but it doesn't define O_ASYNC.
Same for fcntl module which doesn't define FASYNC.
Simply defining
O_ASYNC = 020000
works fine but its not as elegant as saying os.O_ASYNC.
----------
components: Library (Lib)
messages: 66921
nosy: cartman
severity: normal
status: open
title: O_ASYNC and FASYNC should be defined for *nix systems
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2890>
__________________________________
From report at bugs.python.org Fri May 16 12:18:49 2008
From: report at bugs.python.org (daggett)
Date: Fri, 16 May 2008 10:18:49 +0000
Subject: [New-bugs-announce] [issue2891] urllib not handling ftp servers
that do not support REST
In-Reply-To: <1210933128.84.0.447091600093.issue2891@psf.upfronthosting.co.za>
Message-ID: <1210933128.84.0.447091600093.issue2891@psf.upfronthosting.co.za>
New submission from daggett <den.mail at free.fr>:
I reported a bug in fedora bugzilla :
https://bugzilla.redhat.com/show_bug.cgi?id=443033
I thought this was an Anaconda (Fedora installer written in Python)
error, but someone wrote this is a Python urllib error, so I post it
here to be sure this is a Python error or not.
The bug is:
When downloading a file from an FTP server, it uses the REST command
everytime and don't bother to check if the FTP server supports this command.
So if the FTP server does not support the REST command, the download
just fails and there is no alternative: no mean to download a file.
But it should have detected that the FTP server does not support the
REST command and try to download using the GET command instead.
It happened when net-installing Fedora8 from ftp://ftp.proxad.net which
does not support the REST command (for more information, see the URL to
the bug I submitted to Fedora Bugzilla).
regards,
Dag
----------
components: Build
messages: 66928
nosy: daggett
severity: normal
status: open
title: urllib not handling ftp servers that do not support REST
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2891>
__________________________________
From report at bugs.python.org Fri May 16 14:20:35 2008
From: report at bugs.python.org (=?utf-8?q?Hrvoje_Nik=C5=A1i=C4=87?=)
Date: Fri, 16 May 2008 12:20:35 +0000
Subject: [New-bugs-announce] [issue2892] improve cElementTree iterparse
error handling
In-Reply-To: <1210940435.5.0.243679200602.issue2892@psf.upfronthosting.co.za>
Message-ID: <1210940435.5.0.243679200602.issue2892@psf.upfronthosting.co.za>
New submission from Hrvoje Nik?i? <hniksic at gmail.com>:
In some cases it is unfortunate that any error in the XML chunk seen by
the buffer prevents the events generated before the error from being
delivered. For example, in some cases valid XML is embedded in a larger
file or stream, and it is useful to be able to ignore text that follows
the root tag, if any.
The iterparse API and expat itself make this possible, but it doesn't
work because in case of a parsing exception, iterparse doesn't deliver
the events generated before the exception. A simple change to iterparse
makes this possible, however. I would like to share the change with you
for possible inclusion in a future release. Note that this change
shouldn't affect the semantics of iterparse: the exception is still
delivered to the caller, the only difference is that the events
generated by expat before the exception are not forgotten.
I am attaching a diff between the current implementation of iterparse,
and a modified one that fixes this problem.
----------
components: Extension Modules
files: patch
messages: 66935
nosy: hniksic
severity: normal
status: open
title: improve cElementTree iterparse error handling
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10343/patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2892>
__________________________________
From report at bugs.python.org Fri May 16 16:13:25 2008
From: report at bugs.python.org (David Binger)
Date: Fri, 16 May 2008 14:13:25 +0000
Subject: [New-bugs-announce] [issue2893] dict.has_key() expected in h2py.py.
In-Reply-To: <1210947204.94.0.6947477076.issue2893@psf.upfronthosting.co.za>
Message-ID: <1210947204.94.0.6947477076.issue2893@psf.upfronthosting.co.za>
New submission from David Binger <davidbinger at mac.com>:
The h2py.py script is invoked at the end of "make install" on OS X.
It raises an exception on the line where dict.has_key() is called.
(There seem to be many calls to has_key() in the current 3.0 tree.
I bet there are other cases like this one.)
----------
components: Installation
messages: 66946
nosy: dbinger
severity: normal
status: open
title: dict.has_key() expected in h2py.py.
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2893>
__________________________________
From report at bugs.python.org Fri May 16 17:37:44 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 16 May 2008 15:37:44 +0000
Subject: [New-bugs-announce] [issue2894] 2to3 discards comments before
import statements
In-Reply-To: <1210952262.85.0.552260999958.issue2894@psf.upfronthosting.co.za>
Message-ID: <1210952262.85.0.552260999958.issue2894@psf.upfronthosting.co.za>
New submission from Georg Brandl <georg at python.org>:
I got this diff from Tools/freeze/freeze.py:
-
-
-# Import the freeze-private modules
-
-import checkextensions
-import makeconfig
-import makefreeze
-import makemakefile
-import parsesetup
-import bkfile
+from . import checkextensions
+from . import makeconfig
+from . import makefreeze
+from . import makemakefile
+from . import parsesetup
+from . import bkfile
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 66950
nosy: collinwinter, georg.brandl
severity: normal
status: open
title: 2to3 discards comments before import statements
type: behavior
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2894>
__________________________________
From report at bugs.python.org Fri May 16 19:19:22 2008
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 16 May 2008 17:19:22 +0000
Subject: [New-bugs-announce] [issue2895] Crash in ParseTupleAndKeywords when
passing byte string keywords
In-Reply-To: <1210958362.57.0.837653467098.issue2895@psf.upfronthosting.co.za>
Message-ID: <1210958362.57.0.837653467098.issue2895@psf.upfronthosting.co.za>
New submission from Stefan Behnel <scoder at users.sourceforge.net>:
Using 3.0a5, the following code crashes in vgetargskeywords (getargs.c:1542)
>>> d = {b"encoding": "abc"}
>>> str(b"abc", **d)
It should raise a TypeError instead, i.e. line 1535 should read
if (!PyUnicode_Check(key)) {
instead of
if (!PyString_Check(key) && !PyUnicode_Check(key)) {
----------
components: Interpreter Core
messages: 66958
nosy: scoder
severity: normal
status: open
title: Crash in ParseTupleAndKeywords when passing byte string keywords
type: crash
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2895>
__________________________________
From report at bugs.python.org Fri May 16 20:15:47 2008
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_JEANNENOT?=)
Date: Fri, 16 May 2008 18:15:47 +0000
Subject: [New-bugs-announce] [issue2896] cmathmodule.c compilation error
In-Reply-To: <1210961747.58.0.40976494617.issue2896@psf.upfronthosting.co.za>
Message-ID: <1210961747.58.0.40976494617.issue2896@psf.upfronthosting.co.za>
New submission from St?phane JEANNENOT <stephane.jeannenot at orange.fr>:
Build infos :
Python 3.0a5+ (py3k:63383, May 16 2008, 19:58:25)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Build options :
./configure --with-fpectl --with-wctype-functions --with-pymalloc
--with-doc-strings --with-threads --with-signal-module --with-system-ffi
Same bug as issue 2870, certainly same correction !
----------
components: Extension Modules
messages: 66962
nosy: Juno, christian.heimes
severity: normal
status: open
title: cmathmodule.c compilation error
type: compile error
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2896>
__________________________________
From report at bugs.python.org Sat May 17 00:45:13 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 16 May 2008 22:45:13 +0000
Subject: [New-bugs-announce] [issue2897] include structmember.h in Python.h
In-Reply-To: <1210977912.97.0.641461512834.issue2897@psf.upfronthosting.co.za>
Message-ID: <1210977912.97.0.641461512834.issue2897@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
As the comment in descrobject.c says:
/* Why is this not included in Python.h? */
----------
messages: 66972
nosy: benjamin.peterson
severity: normal
status: open
title: include structmember.h in Python.h
type: feature request
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2897>
__________________________________
From report at bugs.python.org Sat May 17 12:44:31 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Sat, 17 May 2008 10:44:31 +0000
Subject: [New-bugs-announce] [issue2898] Add memory footprint query
In-Reply-To: <1211021071.55.0.0441674888284.issue2898@psf.upfronthosting.co.za>
Message-ID: <1211021071.55.0.0441674888284.issue2898@psf.upfronthosting.co.za>
New submission from Robert Schuppenies <okkotonushi at googlemail.com>:
I propose a patch which allows to query the memory footprint of an
object. Calling 'footprint(o)', a python developer can retrieve the
size of any python object. Only the size of the object itself will be
returned, the size of any referenced objects will be ignored.
The patch implements a generic function to compute the object
size. This works in most, but a few cases. One of these exceptions is
the dictionary with its particular table implementation. Such cases
can be handled by implementing an optional method in C. This would
also be the case for third-party implementations with unusual type
definitions.
One advantage with this approach is that the object size can be
computed at the level an object is allocated, not requiring complex
computations and considerations on higher levels.
I am not completely happy with the name 'footprint', but think using
'sizeof' would be confused with plain 'size', and 'memory_usage' was
somewhat too long to be typed conveniently.
Current test pass on linux32 and linux64, but the test suite is not
complete, yet.
This patch is part of my Google Summer of Code project on Python
memory profiling
(http://code.google.com/soc/2008/psf/appinfo.html?csaid=13F0E9C8B6E064EF).
Also, this is my first patch, so please let me know where missed
something, did not follow coding conventions, or made wrong
assumptions.
----------
components: Interpreter Core
files: footprint.patch
keywords: patch
messages: 66989
nosy: okkoto
severity: normal
status: open
title: Add memory footprint query
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10353/footprint.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2898>
__________________________________
From report at bugs.python.org Sat May 17 14:30:17 2008
From: report at bugs.python.org (Haoyu Bai)
Date: Sat, 17 May 2008 12:30:17 +0000
Subject: [New-bugs-announce] [issue2899] Fixes find, rfind,
etc in 'string' module
In-Reply-To: <1211027417.56.0.456898655973.issue2899@psf.upfronthosting.co.za>
Message-ID: <1211027417.56.0.456898655973.issue2899@psf.upfronthosting.co.za>
New submission from Haoyu Bai <divinekid at gmail.com>:
Functions like find() rfind() index() rindex() has been removed in
Python 3.0. So there should be a 2to3 fix for it.
Eg. fix
if string.find(s, "hello") >= 0:
to
if str.find(s, "hello") >= 0:
Thank you!
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 66993
nosy: bhy, collinwinter
severity: normal
status: open
title: Fixes find, rfind, etc in 'string' module
type: feature request
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2899>
__________________________________
From report at bugs.python.org Sat May 17 16:39:16 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 17 May 2008 14:39:16 +0000
Subject: [New-bugs-announce] [issue2900] math.copysign(1, float('nan'))
In-Reply-To: <1211035155.03.0.494078567366.issue2900@psf.upfronthosting.co.za>
Message-ID: <1211035155.03.0.494078567366.issue2900@psf.upfronthosting.co.za>
New submission from Christian Heimes <lists at cheimes.de>:
What's your opinion on the edge case
>>> math.copysign(1, float('nan'))
1.0
Is 1.0 the correct answer? IMHO Nan would be better ...
----------
assignee: marketdickinson
components: Extension Modules
messages: 66997
nosy: christian.heimes, marketdickinson
priority: normal
severity: normal
status: open
title: math.copysign(1, float('nan'))
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2900>
__________________________________
From report at bugs.python.org Sun May 18 02:16:56 2008
From: report at bugs.python.org (=?utf-8?q?H=C3=A5kan_Waara?=)
Date: Sun, 18 May 2008 00:16:56 +0000
Subject: [New-bugs-announce] [issue2901] "error: can't allocate region" from
mmap() when receiving big chunk of data
In-Reply-To: <1211069816.05.0.311102248623.issue2901@psf.upfronthosting.co.za>
Message-ID: <1211069816.05.0.311102248623.issue2901@psf.upfronthosting.co.za>
New submission from H?kan Waara <hwaara at users.sourceforge.net>:
I'm using the standard lib SimpleXMLRPCServer to receive a file from a
client. The file is sent using an instance of the xmlrpclib.Binary class.
Whenever the file is bigger than a few MB, the server reports spews out
an internal error to stderr:
Python(13950) malloc: *** mmap(size=9916416) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
This *only* happens if the client and server are not the same machine;
i.e., connecting and sending to "localhost" always works.
Attached testcase:
* test_server.py opens a server on port 8001 waiting to receive a blob
of data over HTTP.
* Modify test_client.py to point at a big file, and then connect to the
server machine, and you will ses the error.
I'm running OS X-bundled Python 2.5.1 on OS X 10.5.2
----------
messages: 67018
nosy: hwaara
severity: normal
status: open
title: "error: can't allocate region" from mmap() when receiving big chunk of data
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2901>
__________________________________
From report at bugs.python.org Sun May 18 02:56:43 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 18 May 2008 00:56:43 +0000
Subject: [New-bugs-announce] [issue2902] tkinter uses MacOS
In-Reply-To: <1211072203.77.0.284787779391.issue2902@psf.upfronthosting.co.za>
Message-ID: <1211072203.77.0.284787779391.issue2902@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
A few days ago I removed the MacOS module. I didn't realize that it was
used in Tkinter until today. It seems the module is only used in one spot:
if _MacOS and hasattr(_MacOS, 'SchedParams'):
# Disable event scanning except for Command-Period
_MacOS.SchedParams(1, 0)
# Work around nasty MacTk bug
# XXX Is this one still needed?
self.update()
Is this still needed? If so, this check will have to integrated into
_tkinter.
----------
messages: 67020
nosy: benjamin.peterson
priority: critical
severity: normal
status: open
title: tkinter uses MacOS
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2902>
__________________________________
From report at bugs.python.org Sun May 18 05:12:32 2008
From: report at bugs.python.org (Guillaume Knispel)
Date: Sun, 18 May 2008 03:12:32 +0000
Subject: [New-bugs-announce] [issue2903] Add __name__ in globals of
generated namedtuple namespace
In-Reply-To: <1211080350.94.0.662865007097.issue2903@psf.upfronthosting.co.za>
Message-ID: <1211080350.94.0.662865007097.issue2903@psf.upfronthosting.co.za>
New submission from Guillaume Knispel <gknispel at proformatique.com>:
Some 3rd party tracers rely on frame.f_globals["__name__"] to be set to
the module name that contains the code currently executed.
frame.f_globals["__name__"] is not defined when some code has been
generated with exec, which is the way namedtuples are created.
The attached patch set __name__ to '__generated_%s__' % typename in the
generated namespace, which is quite handy to see where the code comes
from. Indeed if sys._getframe is available it sets __name__ to
'__generated_%s__%s__' % (typename, result.__module__) which is even
more useful.
----------
components: Library (Lib)
files: collections.r59898.patch
keywords: patch
messages: 67022
nosy: xilun
severity: normal
status: open
title: Add __name__ in globals of generated namedtuple namespace
versions: Python 2.6
Added file: http://bugs.python.org/file10361/collections.r59898.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2903>
__________________________________
From report at bugs.python.org Sun May 18 07:03:11 2008
From: report at bugs.python.org (Leandro Lucarella)
Date: Sun, 18 May 2008 05:03:11 +0000
Subject: [New-bugs-announce] [issue2904] Cross-referencing to a method using
an alternate title don't work with add_function_parentheses=True
In-Reply-To: <1211086991.24.0.536909381187.issue2904@psf.upfronthosting.co.za>
Message-ID: <1211086991.24.0.536909381187.issue2904@psf.upfronthosting.co.za>
New submission from Leandro Lucarella <llucax at gmail.com>:
When using cross-references to a method using an alternate title, like
:meth:`some title <some_method>` and configuration option
add_function_parentheses is True, the link is not generated (if this
option is False, it works fine.
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 67023
nosy: georg.brandl, llucax
severity: normal
status: open
title: Cross-referencing to a method using an alternate title don't work with add_function_parentheses=True
type: behavior
versions: 3rd party
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2904>
__________________________________
From report at bugs.python.org Sun May 18 11:56:48 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Sun, 18 May 2008 09:56:48 +0000
Subject: [New-bugs-announce] [issue2905] test_urllib.py crashes with bus
error on Darwin
In-Reply-To: <1211104607.9.0.755526483675.issue2905@psf.upfronthosting.co.za>
Message-ID: <1211104607.9.0.755526483675.issue2905@psf.upfronthosting.co.za>
New submission from Ismail Donmez <ismail at namtrac.org>:
Using latest py3k SVN on MacOSX 10.5.2 :
[~/Sources/py3k/Lib/test]> ../../python regrtest.py test_urllib.py
test_urllib
zsh: bus error ../../python regrtest.py test_urllib.py
Backtrace:
#0 _CallProc (pProc=0x904e95f0 <CFStringCreateWithCString>,
argtuple=0x5e7bc0, flags=4353, argtypes=0x0, restype=0x2637b0,
checker=0x0) at
/Users/cartman/Sources/py3k/Modules/_ctypes/callproc.c:984
#1 0x00662352 in CFuncPtr_call (self=0x5c9738, inargs=0x5e7bc0,
kwds=0x0) at /Users/cartman/Sources/py3k/Modules/_ctypes/_ctypes.c:3767
#2 0x00008229 in PyObject_Call (func=0x5c9738, arg=0x5e7bc0, kw=0x0) at
Objects/abstract.c:2184
#3 0x0009e9f4 in <unknown function> [inlined] () at :0
#4 0x0009e9f4 in PyEval_EvalFrameEx (f=0x2615e0, throwflag=0) at
Python/ceval.c:0
#5 0x0009ffc8 in PyEval_EvalFrameEx (f=0x23f6d0, throwflag=0) at
Python/ceval.c:3536
#6 0x0009ffc8 in PyEval_EvalFrameEx (f=0x260d70, throwflag=0) at
Python/ceval.c:3536
#7 0x000a1133 in PyEval_EvalCodeEx (co=0x3cfcc8, globals=0x3c60c0,
locals=0x0, args=0x5eb6dc, argcount=1, kws=0x2576d0, kwcount=0,
defs=0x54d9bc, defcount=1, kwdefs=0x0, closure=0x0) at
Python/ceval.c:2743
#8 0x0002b055 in function_call (func=0x54cd68, arg=0x5eb6d0,
kw=0x5ecb70) at Objects/funcobject.c:628
#9 0x00008229 in PyObject_Call (func=0x54cd68, arg=0x5eb6d0,
kw=0x5ecb70) at Objects/abstract.c:2184
#10 0x0009d418 in PyEval_EvalFrameEx (f=0x260c00, throwflag=0) at
Python/ceval.c:3749
#11 0x000a1133 in PyEval_EvalCodeEx (co=0x3d53c8, globals=0x3c60c0,
locals=0x0, args=0x5eb6bc, argcount=1, kws=0x0, kwcount=0, defs=0x0,
defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:2743
#12 0x0002b055 in function_call (func=0x5321e0, arg=0x5eb6b0, kw=0x0) at
Objects/funcobject.c:628
#13 0x00008229 in PyObject_Call (func=0x5321e0, arg=0x5eb6b0, kw=0x0) at
Objects/abstract.c:2184
#14 0x0001715e in method_call (func=0x5321e0, arg=0x1ac030, kw=0x0) at
Objects/classobject.c:323
#15 0x00008229 in PyObject_Call (func=0x5230a8, arg=0x1ac030, kw=0x0) at
Objects/abstract.c:2184
#16 0x000579c7 in slot_tp_init (self=0x0, args=0x1ac030, kwds=0x0) at
Objects/typeobject.c:5187
#17 0x00053be2 in type_call (type=0x24f8f0, args=0x1ac030, kwds=0x0) at
Objects/typeobject.c:651
#18 0x00008229 in PyObject_Call (func=0x24f8f0, arg=0x1ac030, kw=0x0) at
Objects/abstract.c:2184
#19 0x0009e9f4 in <unknown function> [inlined] () at :0
#20 0x0009e9f4 in PyEval_EvalFrameEx (f=0x260a90, throwflag=0) at
Python/ceval.c:0
#21 0x000a1133 in PyEval_EvalCodeEx (co=0x3cfb60, globals=0x3c60c0,
locals=0x0, args=0x2608e4, argcount=1, kws=0x2608e8, kwcount=0,
defs=0x3cbeec, defcount=2, kwdefs=0x0, closure=0x0) at
Python/ceval.c:2743
#22 0x0009f874 in <unknown function> [inlined] () at :0
#23 0x0009f874 in PyEval_EvalFrameEx (f=0x2607a0, throwflag=0) at
Python/ceval.c:0
#24 0x0009ffc8 in PyEval_EvalFrameEx (f=0x25f3d0, throwflag=0) at
Python/ceval.c:3536
#25 0x000a1133 in PyEval_EvalCodeEx (co=0x538848, globals=0x5330c0,
locals=0x0, args=0x5de67c, argcount=2, kws=0x258880, kwcount=0,
defs=0x5b569c, defcount=1, kwdefs=0x0, closure=0x0) at
Python/ceval.c:2743
#26 0x0002b055 in function_call (func=0x5b68e8, arg=0x5de670,
kw=0x5ec930) at Objects/funcobject.c:628
#27 0x00008229 in PyObject_Call (func=0x5b68e8, arg=0x5de670,
kw=0x5ec930) at Objects/abstract.c:2184
#28 0x0009d418 in PyEval_EvalFrameEx (f=0x25f260, throwflag=0) at
Python/ceval.c:3749
#29 0x000a1133 in PyEval_EvalCodeEx (co=0x538890, globals=0x5330c0,
locals=0x0, args=0x5dedfc, argcount=2, kws=0x0, kwcount=0, defs=0x0,
defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:2743
#30 0x0002b055 in function_call (func=0x5b6930, arg=0x5dedf0, kw=0x0) at
Objects/funcobject.c:628
#31 0x00008229 in PyObject_Call (func=0x5b6930, arg=0x5dedf0, kw=0x0) at
Objects/abstract.c:2184
#32 0x0001715e in method_call (func=0x5b6930, arg=0x5eb650, kw=0x0) at
Objects/classobject.c:323
#33 0x00008229 in PyObject_Call (func=0x523198, arg=0x5eb650, kw=0x0) at
Objects/abstract.c:2184
#34 0x00057d97 in slot_tp_call (self=0x0, args=0x5eb650, kwds=0x0) at
Objects/typeobject.c:4960
#35 0x00008229 in PyObject_Call (func=0x5e3e50, arg=0x5eb650, kw=0x0) at
Objects/abstract.c:2184
#36 0x0009e9f4 in <unknown function> [inlined] () at :0
#37 0x0009e9f4 in PyEval_EvalFrameEx (f=0x25f0f0, throwflag=0) at
Python/ceval.c:0
#38 0x000a1133 in PyEval_EvalCodeEx (co=0x538f50, globals=0x5330c0,
locals=0x0, args=0x5de6a4, argcount=2, kws=0x258870, kwcount=0,
defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:2743
#39 0x0002b055 in function_call (func=0x5b6e88, arg=0x5de698,
kw=0x5ec8a0) at Objects/funcobject.c:628
#40 0x00008229 in PyObject_Call (func=0x5b6e88, arg=0x5de698,
kw=0x5ec8a0) at Objects/abstract.c:2184
#41 0x0009d418 in PyEval_EvalFrameEx (f=0x25ef80, throwflag=0) at
Python/ceval.c:3749
#42 0x000a1133 in PyEval_EvalCodeEx (co=0x538f98, globals=0x5330c0,
locals=0x0, args=0x5de744, argcount=2, kws=0x0, kwcount=0, defs=0x0,
defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:2743
#43 0x0002b055 in function_call (func=0x5b6ed0, arg=0x5de738, kw=0x0) at
Objects/funcobject.c:628
#44 0x00008229 in PyObject_Call (func=0x5b6ed0, arg=0x5de738, kw=0x0) at
Objects/abstract.c:2184
#45 0x0001715e in method_call (func=0x5b6ed0, arg=0x5eb5b0, kw=0x0) at
Objects/classobject.c:323
#46 0x00008229 in PyObject_Call (func=0x5230d0, arg=0x5eb5b0, kw=0x0) at
Objects/abstract.c:2184
#47 0x00057d97 in slot_tp_call (self=0x0, args=0x5eb5b0, kwds=0x0) at
Objects/typeobject.c:4960
#48 0x00008229 in PyObject_Call (func=0x5e3eb0, arg=0x5eb5b0, kw=0x0) at
Objects/abstract.c:2184
#49 0x0009e9f4 in <unknown function> [inlined] () at :0
#50 0x0009e9f4 in PyEval_EvalFrameEx (f=0x25ee10, throwflag=0) at
Python/ceval.c:0
#51 0x000a1133 in PyEval_EvalCodeEx (co=0x538f50, globals=0x5330c0,
locals=0x0, args=0x5de5b4, argcount=2, kws=0x254b40, kwcount=0,
defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:2743
#52 0x0002b055 in function_call (func=0x5b6e88, arg=0x5de5a8,
kw=0x5ec810) at Objects/funcobject.c:628
#53 0x00008229 in PyObject_Call (func=0x5b6e88, arg=0x5de5a8,
kw=0x5ec810) at Objects/abstract.c:2184
#54 0x0009d418 in PyEval_EvalFrameEx (f=0x25eca0, throwflag=0) at
Python/ceval.c:3749
#55 0x000a1133 in PyEval_EvalCodeEx (co=0x538f98, globals=0x5330c0,
locals=0x0, args=0x53a924, argcount=2, kws=0x0, kwcount=0, defs=0x0,
defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:2743
#56 0x0002b055 in function_call (func=0x5b6ed0, arg=0x53a918, kw=0x0) at
Objects/funcobject.c:628
#57 0x00008229 in PyObject_Call (func=0x5b6ed0, arg=0x53a918, kw=0x0) at
Objects/abstract.c:2184
#58 0x0001715e in method_call (func=0x5b6ed0, arg=0x5eb450, kw=0x0) at
Objects/classobject.c:323
#59 0x00008229 in PyObject_Call (func=0x578e18, arg=0x5eb450, kw=0x0) at
Objects/abstract.c:2184
#60 0x00057d97 in slot_tp_call (self=0x0, args=0x5eb450, kwds=0x0) at
Objects/typeobject.c:4960
#61 0x00008229 in PyObject_Call (func=0x53f8f0, arg=0x5eb450, kw=0x0) at
Objects/abstract.c:2184
#62 0x0009e9f4 in <unknown function> [inlined] () at :0
#63 0x0009e9f4 in PyEval_EvalFrameEx (f=0x25e560, throwflag=0) at
Python/ceval.c:0
#64 0x0009ffc8 in PyEval_EvalFrameEx (f=0x25e120, throwflag=0) at
Python/ceval.c:3536
#65 0x0009ffc8 in PyEval_EvalFrameEx (f=0x25b070, throwflag=0) at
Python/ceval.c:3536
#66 0x000a1133 in PyEval_EvalCodeEx (co=0x5bca40, globals=0x533c90,
locals=0x0, args=0x25074c, argcount=7, kws=0x250768, kwcount=0,
defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:2743
#67 0x0009f874 in <unknown function> [inlined] () at :0
#68 0x0009f874 in PyEval_EvalFrameEx (f=0x250610, throwflag=0) at
Python/ceval.c:0
#69 0x0009ffc8 in PyEval_EvalFrameEx (f=0x233530, throwflag=0) at
Python/ceval.c:3536
#70 0x000a1133 in PyEval_EvalCodeEx (co=0x3cfa88, globals=0x1d50c0,
locals=0x1d50c0, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:2743
#71 0x000a12ef in PyEval_EvalCode (co=0x0, globals=0x0, locals=0x0) at
Python/ceval.c:500
#72 0x000c7691 in <unknown function> [inlined] () at :0
#73 0x000c7691 in PyRun_FileExFlags (fp=0xa0670de0, filename=0xbffff2dc
"test_urllib.py", start=257, globals=0x1d50c0, locals=0x1d50c0,
closeit=1, flags=0xbffff73c) at Python/pythonrun.c:0
#74 0x000c7b23 in PyRun_SimpleFileExFlags (fp=<value temporarily
unavailable, due to optimizations>, filename=0xbffff2dc
"test_urllib.py", closeit=1, flags=0xbffff73c) at
Python/pythonrun.c:1040
#75 0x000d4da9 in Py_Main (argc=2, argv=0x2000f0) at Modules/main.c:592
#76 0x000024c0 in main (argc=2, argv=0xbffff808) at python.c:57
----------
components: Library (Lib)
messages: 67026
nosy: cartman
severity: normal
status: open
title: test_urllib.py crashes with bus error on Darwin
type: crash
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2905>
__________________________________
From report at bugs.python.org Sun May 18 17:38:58 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 18 May 2008 15:38:58 +0000
Subject: [New-bugs-announce] [issue2906] tkinter, assorted fixes
In-Reply-To: <1211125137.99.0.839625810587.issue2906@psf.upfronthosting.co.za>
Message-ID: <1211125137.99.0.839625810587.issue2906@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
This patch adds support for Tk options that could be passed as a list or
tuple, for example. I didn't investigate if there are any of these in tk
8.4, but tk 8.5 has this (the padding option for Ttk Label, for example).
Note that this should, if possible, be backported to python 2.5 at
least, since it segfaults here when I pass a list as an option value.
It also aligns some docstrings; documents the support for the 'in_'
option for grid, place and pack, actually all options may end with an
"_", but it is good to document 'in_' specifically because the option
'in' can't be passed "naturally". Lastly it removes the duplicate code
in class Place that checks for the 'in_' option.
----------
components: Tkinter
files: fixes_tkinter.diff
keywords: patch, patch
messages: 67029
nosy: gpolo
severity: normal
status: open
title: tkinter, assorted fixes
versions: Python 3.0
Added file: http://bugs.python.org/file10362/fixes_tkinter.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2906>
__________________________________
From report at bugs.python.org Sun May 18 20:06:35 2008
From: report at bugs.python.org (Chester)
Date: Sun, 18 May 2008 18:06:35 +0000
Subject: [New-bugs-announce] [issue2907] ZeroDivisionError error message
needs clarification
In-Reply-To: <1211133995.44.0.708041484383.issue2907@psf.upfronthosting.co.za>
Message-ID: <1211133995.44.0.708041484383.issue2907@psf.upfronthosting.co.za>
New submission from Chester <wxpythoner at gmail.com>:
Please fix the ZeroDivisionError error message string literal to clarify
the error message:
from
if (y == 0) {
PyErr_SetString(PyExc_ZeroDivisionError,
"integer division or modulo by zero");
return DIVMOD_ERROR;
to
if (y == 0) {
PyErr_SetString(PyExc_ZeroDivisionError,
"integer division by zero or modulo by zero");
return DIVMOD_ERROR;
This code is located here:
http://svn.python.org/view/python/trunk/Objects/intobject.c?rev=62380&view=markup
----------
messages: 67033
nosy: chester
severity: normal
status: open
title: ZeroDivisionError error message needs clarification
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2907>
__________________________________
From report at bugs.python.org Sun May 18 21:49:39 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 18 May 2008 19:49:39 +0000
Subject: [New-bugs-announce] [issue2908] fix_imports new entries for tkinter
rename
In-Reply-To: <1211140179.6.0.751466797927.issue2908@psf.upfronthosting.co.za>
Message-ID: <1211140179.6.0.751466797927.issue2908@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
Added entries on fix_imports to deal with the tkinter renaming.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: tkinter_imports_fix.diff
keywords: patch
messages: 67036
nosy: collinwinter, gpolo
severity: normal
status: open
title: fix_imports new entries for tkinter rename
Added file: http://bugs.python.org/file10367/tkinter_imports_fix.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2908>
__________________________________
From report at bugs.python.org Sun May 18 22:13:20 2008
From: report at bugs.python.org (Aaron Gallagher)
Date: Sun, 18 May 2008 20:13:20 +0000
Subject: [New-bugs-announce] [issue2909] struct.Struct.unpack to return a
namedtuple for easier attribute access
In-Reply-To: <1211141600.93.0.483393592548.issue2909@psf.upfronthosting.co.za>
Message-ID: <1211141600.93.0.483393592548.issue2909@psf.upfronthosting.co.za>
New submission from Aaron Gallagher <habnabit at gmail.com>:
With the advent of collections.namedtuple, I thought that having a
counterpart in the struct module would make having to deal with unpacked
data much easier. Per suggestion, this extends the behavior of
_struct.Struct rather than a separate NamedStruct class.
The regexp might not be immediately obvious as to what the format
required is. The format string is represented like this:
"attribute_name1(attribute_format) attribute_name2(attribute_format2)"
and so on. Formats given in parentheses without an attribute name are
allowed, so that byte order and pad bytes can be specified. For example:
"(!) x1(h) x2(h) (2x) y1(h) y2(h)"
Suggestions and criticism are welcome. I think it would simplify using
the struct module a lot to be able to have named attributes like this.
----------
components: Library (Lib)
files: named-struct.patch
keywords: patch
messages: 67038
nosy: habnabit
severity: normal
status: open
title: struct.Struct.unpack to return a namedtuple for easier attribute access
versions: Python 3.0
Added file: http://bugs.python.org/file10368/named-struct.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2909>
__________________________________
From report at bugs.python.org Sun May 18 23:04:27 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 18 May 2008 21:04:27 +0000
Subject: [New-bugs-announce] [issue2910] Remove plat-mac from 3.0
In-Reply-To: <1211144667.58.0.62394748766.issue2910@psf.upfronthosting.co.za>
Message-ID: <1211144667.58.0.62394748766.issue2910@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
The plat-mac directory is empty in 3.0, but is still there. Plus there are
still references in Makefile.pre.in to the package as well.
----------
components: Library (Lib)
messages: 67042
nosy: brett.cannon
priority: critical
severity: normal
status: open
title: Remove plat-mac from 3.0
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2910>
__________________________________
From report at bugs.python.org Mon May 19 00:23:32 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 18 May 2008 22:23:32 +0000
Subject: [New-bugs-announce] [issue2911] rewrite test_struct as a unittest
In-Reply-To: <1211149411.88.0.00220562909175.issue2911@psf.upfronthosting.co.za>
Message-ID: <1211149411.88.0.00220562909175.issue2911@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
Perhaps a bigger bug day task?
----------
components: Tests
keywords: easy
messages: 67051
nosy: benjamin.peterson
priority: low
severity: normal
status: open
title: rewrite test_struct as a unittest
type: feature request
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2911>
__________________________________
From report at bugs.python.org Mon May 19 02:16:12 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 19 May 2008 00:16:12 +0000
Subject: [New-bugs-announce] [issue2912] let platform.uname try harder
In-Reply-To: <1211156171.95.0.0218034569692.issue2912@psf.upfronthosting.co.za>
Message-ID: <1211156171.95.0.0218034569692.issue2912@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
Sometimes os.uname (which is used to bootstrap platform.uname) can
return 'unknown' for some items. The fallback code in platform.uname can
usually fill these blanks in. However, this is only used when os.uname
is not present. It would be useful if platform tried to fill these
unknowns in.
----------
keywords: easy
messages: 67052
nosy: benjamin.peterson
severity: normal
status: open
title: let platform.uname try harder
type: feature request
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2912>
__________________________________
From report at bugs.python.org Mon May 19 13:49:46 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Mon, 19 May 2008 11:49:46 +0000
Subject: [New-bugs-announce] [issue2913] idlelib/EditorWindow.py uses
xrange()
In-Reply-To: <1211197785.96.0.212094869578.issue2913@psf.upfronthosting.co.za>
Message-ID: <1211197785.96.0.212094869578.issue2913@psf.upfronthosting.co.za>
New submission from Mark Summerfield <mark at qtrac.eu>:
In Py30a5 idlelib/EditorWindow.py line 292 uses xrange() when it should
use range().
----------
components: IDLE
messages: 67060
nosy: mark
severity: normal
status: open
title: idlelib/EditorWindow.py uses xrange()
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2913>
__________________________________
From report at bugs.python.org Mon May 19 14:54:12 2008
From: report at bugs.python.org (Val Schmidt)
Date: Mon, 19 May 2008 12:54:12 +0000
Subject: [New-bugs-announce] [issue2914] Logging TimedRotatingFileHandler
Feature Request
In-Reply-To: <1211201651.81.0.243384558767.issue2914@psf.upfronthosting.co.za>
Message-ID: <1211201651.81.0.243384558767.issue2914@psf.upfronthosting.co.za>
New submission from Val Schmidt <vschmidt at ccom.unh.edu>:
I would like the TimedRotatingFileHandler in the logging package to
optionally rotate on UTC time rather than local time. In my world
(oceanographic research ships) important things like log files must
always use UTC time rather than relative local time because local time
changes alot!
Also it would be helpful to be able to configure the end-of-line
termination explicitly for logging. For example, if one echos log
entries out a serial port using the StreamHandler, one might want to
specify \r, \n or some other such thing because of the funny gear on the
other side of the serial line. The formatter method seems to default to
\n (which I generally like) but there's no way to change it.
----------
messages: 67061
nosy: vschmidt
severity: normal
status: open
title: Logging TimedRotatingFileHandler Feature Request
type: feature request
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2914>
__________________________________
From report at bugs.python.org Mon May 19 17:44:51 2008
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 19 May 2008 15:44:51 +0000
Subject: [New-bugs-announce] [issue2915] PyObject_IsInstance() doesn't find
bases named in type(name, bases, dict)
In-Reply-To: <1211211891.23.0.800845105801.issue2915@psf.upfronthosting.co.za>
Message-ID: <1211211891.23.0.800845105801.issue2915@psf.upfronthosting.co.za>
New submission from Stefan Behnel <scoder at users.sourceforge.net>:
While porting the code that Cython generates to Py3a5 (almost completed,
BTW), I noticed a problem with class creation. We are currently using
this call to create a new class in Py3:
PyObject_CallFunctionObjArgs((PyObject *)&PyType_Type,
name, bases, dict, NULL);
As an example, I subtype the built-in "list" type like this (Cython code!):
class B(list):
def append(self, *args):
for arg in args:
list.append(self, arg)
which calls type() as shown above with name="B" and bases=(PyList_Type,).
Surprisingly to me, the call to .append() then fails in the method
descriptor code with a type error on "self". I tried calling super(...)
instead, and it gives a similar error. I read through the descriptor
code and the thing that fails here is
PyObject_IsInstance(self, (PyObject *)(descr->d_type))
in line 229 of descrobject.c, which internally calls
PyObject_TypeCheck(inst, (PyTypeObject *)cls)
in line 2543 of abstract.c. The problem here is that this checks the
ob_type, which holds a "type" and not a "B", so it doesn't find the base
type "list" of the "B" type and instead looks through the base types of
"type". The result is that PyObject_IsInstance() does not consider the
result of the above call to type(name, bases, dict) an instance of the
types that were named in "bases".
As this works in Python 2.5.1 and also for equivalent Python code in the
interpreter of Python 3.0a5, I assume that this is a bug in the alpha
version.
----------
components: Interpreter Core
messages: 67065
nosy: scoder
severity: normal
status: open
title: PyObject_IsInstance() doesn't find bases named in type(name, bases, dict)
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2915>
__________________________________
From report at bugs.python.org Mon May 19 17:52:12 2008
From: report at bugs.python.org (Mads Kiilerich)
Date: Mon, 19 May 2008 15:52:12 +0000
Subject: [New-bugs-announce] [issue2916] urlgrabber.grabber calls
setdefaulttimeout
In-Reply-To: <1211212331.88.0.0515887247336.issue2916@psf.upfronthosting.co.za>
Message-ID: <1211212331.88.0.0515887247336.issue2916@psf.upfronthosting.co.za>
New submission from Mads Kiilerich <mads at kiilerich.com>:
Module docstring says """Setting this option causes urlgrabber to call
the settimeout method on the Socket object used for the request.""" But
actually it temporarily changes the global default timeout.
If other threads are creating sockets in this short timespan they might
fail in unexpected ways.
There might not be any other easy way to set a timeout. The long term
solution should be to provide a way to do it right. A short term
workaround it to update the documentation to describe current behaviour.
----------
components: Library (Lib)
messages: 67066
nosy: kiilerix
severity: normal
status: open
title: urlgrabber.grabber calls setdefaulttimeout
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2916>
__________________________________
From report at bugs.python.org Mon May 19 21:59:22 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 19 May 2008 19:59:22 +0000
Subject: [New-bugs-announce] [issue2917] merge pickle and cPickle in 3.0
In-Reply-To: <1211227162.29.0.0642317760161.issue2917@psf.upfronthosting.co.za>
Message-ID: <1211227162.29.0.0642317760161.issue2917@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
cPickle should be gone in 3.0 and pickle should have an accelerated
version behind it, when available.
Alexandre has been working on this (might even be checked in), so
assigning to him to help track for PEP 3108 work.
----------
assignee: alexandre.vassalotti
components: Library (Lib)
messages: 67071
nosy: alexandre.vassalotti, brett.cannon
priority: release blocker
severity: normal
status: open
title: merge pickle and cPickle in 3.0
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2917>
__________________________________
From report at bugs.python.org Mon May 19 22:01:02 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 19 May 2008 20:01:02 +0000
Subject: [New-bugs-announce] [issue2918] Merge StringIO/cStringIO in 3.0
In-Reply-To: <1211227262.27.0.176120683389.issue2918@psf.upfronthosting.co.za>
Message-ID: <1211227262.27.0.176120683389.issue2918@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
PEP 3108 calls for StringIO (which is io.StringIO in 3.0) to have an
accelerated version behind it when available. Alexandre has been working
on this so assigning to him.
----------
assignee: alexandre.vassalotti
components: Library (Lib)
messages: 67072
nosy: alexandre.vassalotti, brett.cannon
priority: release blocker
severity: normal
status: open
title: Merge StringIO/cStringIO in 3.0
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2918>
__________________________________
From report at bugs.python.org Mon May 19 22:02:14 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 19 May 2008 20:02:14 +0000
Subject: [New-bugs-announce] [issue2919] Merge profile/cProfile in 3.0
In-Reply-To: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za>
Message-ID: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
cProfile should go away in 3.0 (as a public module) and just be what
profile uses when available.
----------
components: Library (Lib)
messages: 67073
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Merge profile/cProfile in 3.0
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2919>
__________________________________
From report at bugs.python.org Mon May 19 22:14:37 2008
From: report at bugs.python.org (Yannick Gingras)
Date: Mon, 19 May 2008 20:14:37 +0000
Subject: [New-bugs-announce] [issue2920] Patch to print symbolic value or
errno in EnvironmentError.__str__()
In-Reply-To: <1211228076.96.0.534347381118.issue2920@psf.upfronthosting.co.za>
Message-ID: <1211228076.96.0.534347381118.issue2920@psf.upfronthosting.co.za>
New submission from Yannick Gingras <ygingras at ygingras.net>:
EnvironmentError and its subclass OSError add the value of errno in
their error message. This value is an integer but the specific value
in an implementation detail and the C runtime recommends that
programmers use the symbolic values instead. Ex: one should use
ENODATA instead of 61. For the same reason, the Python interpreter
should try to return the symbolic value or errno when possible.
The attached patch replaces errno in EnvironmentError.__str__() by its
symbolic value when possible.
----------
components: Interpreter Core
files: python-26-sympolic-errno.diff
keywords: patch
messages: 67074
nosy: ygingras
severity: normal
status: open
title: Patch to print symbolic value or errno in EnvironmentError.__str__()
versions: Python 2.6
Added file: http://bugs.python.org/file10377/python-26-sympolic-errno.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2920>
__________________________________
From report at bugs.python.org Mon May 19 23:29:23 2008
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Mon, 19 May 2008 21:29:23 +0000
Subject: [New-bugs-announce] [issue2921] enable embedding: declare/#define
only py* symbols in #includes
In-Reply-To: <1211232563.03.0.480695098403.issue2921@psf.upfronthosting.co.za>
Message-ID: <1211232563.03.0.480695098403.issue2921@psf.upfronthosting.co.za>
New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:
It can be cumbersome to embed Python in a program which also #includes
a config.h from autoconf, because Python's and the program's autoconf
macros may interfere with each other. Assuming it compiles at all,
both could define the same features, sometimes the same way and
sometimes differently. Or one could be compiled with a feature macro
undefined and another with it defined, resulting in binary
incompatibility with the library which was compiled with the macro
undefined.
So one has to do something like: put the Python calls in one set of
files, the calls to the embedding program in another set, and make
them communicate via some glue code.
For this reason, please do not declare/#define symbols other than
those starting with 'py' in the include files that an embedded program
needs. Thus, do not #include at least pyconfig.h, pymath.h and
pyport.h as they are today.
Or to keep backwards compatibility, wrap such definitions in
#ifndef PYTHON_NAMESPACE_ONLY
which an application can #define before #including Python files.
Instead, you can #define/declare symbols that match the current
autoconf symbols but are prefixed with PY_, and make use of those in
#ifdefs in the include files. The files defining this can hopefully
be autogenerated, e.g. generate a .c file like
#include "pyconfig.h"
int main() {
#ifdef HAVE_WHATEVER
puts("PY_HAVE_WHATEVER");
#endif
...
}
Things like acosh() from pymath.h which you define if the system lacks
it, could become something like this:
#include <math.h> /* get acosh etc */
...
extern double py_acosh(double); /* always present in python */
#if !defined(PYTHON_NAMESPACE_ONLY) && !defined(HAVE_ACOSH)
/* an other package's autoconf might do the same, so hide this
* if requested */
extern double acosh(double);
#endif
#if !defined(PYTHON_NAMESPACE_ONLY) || defined(HAVE_ACOSH)
#define py_acosh acosh /* optimization - hide wrapper function */
#endif
----------
components: None
messages: 67078
nosy: hfuru
severity: normal
status: open
title: enable embedding: declare/#define only py* symbols in #includes
type: feature request
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2921>
__________________________________
From report at bugs.python.org Mon May 19 23:29:59 2008
From: report at bugs.python.org (John Burnett)
Date: Mon, 19 May 2008 21:29:59 +0000
Subject: [New-bugs-announce] [issue2922] "No windows home dir" doc error
In-Reply-To: <1211232599.63.0.873438869576.issue2922@psf.upfronthosting.co.za>
Message-ID: <1211232599.63.0.873438869576.issue2922@psf.upfronthosting.co.za>
New submission from John Burnett <python at johnburnett.com>:
http://docs.python.org/inst/alt-install-windows.html
The above says "Windows has no concept of a user's home directory, and
since the standard Python installation under Windows is simpler than
under Unix, the --prefix option has traditionally been used to install
additional packages in separate locations on Windows."
However, any modern Windows OS does have that concept (i.e. see the
%USERPROFILE% env variable). Not sure how to best change the above, but...
----------
assignee: georg.brandl
components: Documentation
messages: 67079
nosy: georg.brandl, python at johnburnett.com
severity: normal
status: open
title: "No windows home dir" doc error
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2922>
__________________________________
From report at bugs.python.org Tue May 20 06:31:22 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 20 May 2008 04:31:22 +0000
Subject: [New-bugs-announce] [issue2923] Revert ConfigParser rename in 2.6
In-Reply-To: <1211257882.61.0.790616237846.issue2923@psf.upfronthosting.co.za>
Message-ID: <1211257882.61.0.790616237846.issue2923@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
The rename of ConfigParser in 2.6 needs to be reverted. Only a note in the
docs should remain.
----------
components: Library (Lib)
messages: 67093
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Revert ConfigParser rename in 2.6
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2923>
__________________________________
From report at bugs.python.org Tue May 20 06:32:55 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 20 May 2008 04:32:55 +0000
Subject: [New-bugs-announce] [issue2924] Revert copy_reg rename in 2.6
In-Reply-To: <1211257975.76.0.263377086511.issue2924@psf.upfronthosting.co.za>
Message-ID: <1211257975.76.0.263377086511.issue2924@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
The rename of copy_reg in 2.6 needs to reverted, leaving on a note in the
docs.
----------
components: Library (Lib)
messages: 67094
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Revert copy_reg rename in 2.6
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2924>
__________________________________
From report at bugs.python.org Tue May 20 06:34:09 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 20 May 2008 04:34:09 +0000
Subject: [New-bugs-announce] [issue2925] Revert Queue rename in 2.6
In-Reply-To: <1211258049.35.0.372468669832.issue2925@psf.upfronthosting.co.za>
Message-ID: <1211258049.35.0.372468669832.issue2925@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
The rename of Queue in 2.6 needs to be reverted with only a note in the
docs to remain.
----------
components: Library (Lib)
messages: 67095
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Revert Queue rename in 2.6
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2925>
__________________________________
From report at bugs.python.org Tue May 20 06:35:30 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 20 May 2008 04:35:30 +0000
Subject: [New-bugs-announce] [issue2926] Revert SocketServer rename in 2.6
In-Reply-To: <1211258129.96.0.233519101848.issue2926@psf.upfronthosting.co.za>
Message-ID: <1211258129.96.0.233519101848.issue2926@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
The rename of SocketServer in 2.6 needs to be reverted; only a note in the
docs should remain.
----------
components: Library (Lib)
messages: 67096
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Revert SocketServer rename in 2.6
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2926>
__________________________________
From report at bugs.python.org Tue May 20 07:43:55 2008
From: report at bugs.python.org (Tom Pinckney)
Date: Tue, 20 May 2008 05:43:55 +0000
Subject: [New-bugs-announce] [issue2927] expose html.parser.unescape
In-Reply-To: <1211262235.18.0.705526453605.issue2927@psf.upfronthosting.co.za>
Message-ID: <1211262235.18.0.705526453605.issue2927@psf.upfronthosting.co.za>
New submission from Tom Pinckney <thomaspinckney3 at gmail.com>:
There is currently a private method inside of html.parser.HTMLParser to
unescape HTML &...; style escapes. This would be useful to expose for
other users who want to unescape a piece of HTML.
Additionally, many websites don't use proper unicode or iso-8859-1
encodings and accidentally use Microsoft Code Page 1252 extensions. I
added code to map these to their appropriate unicode values.
The unescaping logic was slightly simplified too.
This is my first Python patch submission, so please let me know if I've
done anything wrong.
A new test case was also added for this functionality.
----------
components: Library (Lib)
files: unescape.diff
keywords: patch
messages: 67102
nosy: thomaspinckney3
severity: normal
status: open
title: expose html.parser.unescape
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10383/unescape.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2927>
__________________________________
From report at bugs.python.org Tue May 20 08:01:40 2008
From: report at bugs.python.org (Adam Olsen)
Date: Tue, 20 May 2008 06:01:40 +0000
Subject: [New-bugs-announce] [issue2928] Allow set/frozenset for __all__
In-Reply-To: <1211263300.31.0.206885021428.issue2928@psf.upfronthosting.co.za>
Message-ID: <1211263300.31.0.206885021428.issue2928@psf.upfronthosting.co.za>
New submission from Adam Olsen <rhamph at gmail.com>:
Patch allows any iterable (such as set and frozenset) to be used for
__all__.
I also add some blank lines, making it more readable.
----------
files: python-importall.diff
keywords: patch
messages: 67104
nosy: Rhamphoryncus
severity: normal
status: open
title: Allow set/frozenset for __all__
Added file: http://bugs.python.org/file10384/python-importall.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2928>
__________________________________
From report at bugs.python.org Tue May 20 14:34:12 2008
From: report at bugs.python.org (Stephan Blietz)
Date: Tue, 20 May 2008 12:34:12 +0000
Subject: [New-bugs-announce] [issue2929] TimedRotatingFileHandler crashes on
backup file deletion attempt
In-Reply-To: <1211286852.1.0.356571953075.issue2929@psf.upfronthosting.co.za>
Message-ID: <1211286852.1.0.356571953075.issue2929@psf.upfronthosting.co.za>
New submission from Stephan Blietz <sblietz at gmx.de>:
Hello,
when the maximum number of backup files is reached
TimedRotatingFileHandler can't delete the oldest existing file. I got
the following error message:
Traceback (most recent call last):
File "D:\Python25\lib\logging\handlers.py", line 75, in emit
self.doRollover()
File "D:\Python25\lib\logging\handlers.py", line 319, in doRollover
os.remove(s)
WindowsError: [Error 2] The system cannot find the file specified:
'assyst.log.2008-05-20_12-49'
The reason for this error is located in the getFilesToDelete method of
the TimedRotatingFileHandler class. The result sequence of this method
contains filenames but a complete filepath is needed.
After replacing
result.append(fileName)
with
result.append(os.path.join(dirName, fileName))
the problem seems to be solved
Regards
Stephan
----------
components: Library (Lib)
messages: 67125
nosy: blocki
severity: normal
status: open
title: TimedRotatingFileHandler crashes on backup file deletion attempt
type: crash
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2929>
__________________________________
From report at bugs.python.org Tue May 20 17:16:38 2008
From: report at bugs.python.org (=?utf-8?q?J=C3=B6rg_Rebenstorf?=)
Date: Tue, 20 May 2008 15:16:38 +0000
Subject: [New-bugs-announce] [issue2930] Cannot change variable definied in
__init_.py after importing
In-Reply-To: <1211296598.61.0.428174810235.issue2930@psf.upfronthosting.co.za>
Message-ID: <1211296598.61.0.428174810235.issue2930@psf.upfronthosting.co.za>
New submission from J?rg Rebenstorf <joerg.rebenstorf at tesbv.com>:
How can I change a variable that I defined in "__init__.py" of a
package called "common" from inside the .py file that imported the
package? I think there is no way to do this, in contrast to when the
variable is defined any other module of the same package but not in the
specific "__init__.py" module.
Example:
If there is a variable named let's say "fileList" in the
module "var.py" of the package "common" then I could modify the
variable "fileList" from within the importing file like this:
from common.var import *
var.fileList = [ "bla", "blub" ]
So that the change of the value of "fileList" is seen when reading it
inside a function of "var.py" after this modification.
But when the variable is defined inside "__init_.py" then the importing
script cannot access it by writing:
from common import *
fileList = [ "bla", "blub" ]
And it cannot access it by writing:
from common import *
common.fileList = [ "bla", "blub" ]
Why are variables of "__init__.py" module non-modifyable this way and
all others of submodules of the same package are modifyable? Maybe
there is this conceptional problem of the python language here or did I
miss something?
----------
components: Interpreter Core
messages: 67128
nosy: crayor
severity: normal
status: open
title: Cannot change variable definied in __init_.py after importing
type: behavior
versions: Python 2.3
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2930>
__________________________________
From report at bugs.python.org Tue May 20 17:31:19 2008
From: report at bugs.python.org (Alexey Shamrin)
Date: Tue, 20 May 2008 15:31:19 +0000
Subject: [New-bugs-announce] [issue2931] optparse: various problems with
unicode and gettext
In-Reply-To: <1211297479.44.0.970954846769.issue2931@psf.upfronthosting.co.za>
Message-ID: <1211297479.44.0.970954846769.issue2931@psf.upfronthosting.co.za>
New submission from Alexey Shamrin <shamrin at gmail.com>:
In the process of trying to use optparse with russian messages, I found
several problems with gettext and unicode handling:
1. optparse.OptionParser.error function doesn't work with unicode argument
2. optparse doesn't work when its error messages are gettext-translated
3. optparse fails running 'prog.py --help > out.txt' with unicode help
(at least on my system: Windows XP, Russian)
I have attached a file demonstrating these problems: test_optparse.py.
You can run it either using nose[1] or directly, manually uncommenting
test_* functions one-by-one.
[1]: http://www.somethingaboutorange.com/mrl/projects/nose/
Here's the result of running `nosetests test_optparse.py`:
EEF
======================================================================
ERROR: OptionParser.error function doesn't work with unicode argument
----------------------------------------------------------------------
Traceback (most recent call last):
File
"c:\python25\lib\site-packages\nose-0.10.2-py2.5.egg\nose\case.py", line
182, in runTest
self.test(*self.arg)
File "C:\work\test_optparse.py", line 10, in test_unicode_error
optparse.OptionParser().error(russian_text)
File "C:\Python25\lib\optparse.py", line 1562, in error
self.exit(2, "%s: error: %s\n" % (self.get_prog_name(), msg))
File "C:\Python25\lib\optparse.py", line 1551, in exit
sys.stderr.write(msg)
UnicodeEncodeError: 'ascii' codec can't encode characters in position
28-34: ordinal not in range(128)
======================================================================
ERROR: optparse doesn't work when its error messages are gettext-translated
----------------------------------------------------------------------
Traceback (most recent call last):
File
"c:\python25\lib\site-packages\nose-0.10.2-py2.5.egg\nose\case.py", line
182, in runTest
self.test(*self.arg)
File "C:\work\test_optparse.py", line 25, in
test_translated_unicode_error_message
optparse.OptionParser().parse_args(["--unknown"])
File "C:\Python25\lib\optparse.py", line 1380, in parse_args
self.error(str(err))
UnicodeEncodeError: 'ascii' codec can't encode characters in position
0-6: ordinal not in range(128)
======================================================================
FAIL: optparse fails running 'prog.py --help > out.txt' with unicode help
----------------------------------------------------------------------
Traceback (most recent call last):
File
"c:\python25\lib\site-packages\nose-0.10.2-py2.5.egg\nose\case.py", line
182, in runTest
self.test(*self.arg)
File "C:\work\test_optparse.py", line 42, in test_redirected_unicode_help
assert '?????' not in dummy_stdout.getvalue()
AssertionError
----------------------------------------------------------------------
Ran 3 tests in 0.000s
FAILED (errors=2, failures=1)
----------
components: Library (Lib)
files: test_optparse.py
messages: 67129
nosy: ash, gward
severity: normal
status: open
title: optparse: various problems with unicode and gettext
Added file: http://bugs.python.org/file10386/test_optparse.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2931>
__________________________________
From report at bugs.python.org Wed May 21 03:12:07 2008
From: report at bugs.python.org (Wallace Owen)
Date: Wed, 21 May 2008 01:12:07 +0000
Subject: [New-bugs-announce] [issue2932] Documenting Python: Syntax"
In-Reply-To: <1211332326.77.0.550241856436.issue2932@psf.upfronthosting.co.za>
Message-ID: <1211332326.77.0.550241856436.issue2932@psf.upfronthosting.co.za>
New submission from Wallace Owen <owen at metamachine.com>:
http://docs.python.org/doc/latex-syntax.html
----------
messages: 67142
nosy: owen
severity: normal
status: open
title: Documenting Python: Syntax"
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2932>
__________________________________
From report at bugs.python.org Wed May 21 03:21:18 2008
From: report at bugs.python.org (Wallace Owen)
Date: Wed, 21 May 2008 01:21:18 +0000
Subject: [New-bugs-announce] [issue2933] "Documenting Python: Syntax" bug
In-Reply-To: <1211332877.88.0.94252582936.issue2933@psf.upfronthosting.co.za>
Message-ID: <1211332877.88.0.94252582936.issue2933@psf.upfronthosting.co.za>
New submission from Wallace Owen <owen at metamachine.com>:
The 'documenting Python' document, section 4.1, at this url:
http://docs.python.org/doc/latex-syntax.html
has an incorrect (but correctly spelled) word in one of it's sentences:
----
Macros which take no parameters but which should not be followed by a
word space do not need special treatment if the following character in
the document source if not a name character (such as punctuation).
----
The phrase "source if not a name" should be "source is not a name".
By the way, in attempting to classify this bug within the parameters
allowed, I observe that there is no correct 'Type' for this bug: none of
the allowed choices seem to apply. It's not a "crash", "compile error",
"resource usage", "security", "behavior", "performance" or "feature
request". I figured "feature request" would ring the fewest alarm
bells, so I used that.
----------
assignee: georg.brandl
components: Documentation
messages: 67143
nosy: georg.brandl, owen
severity: normal
status: open
title: "Documenting Python: Syntax" bug
type: feature request
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2933>
__________________________________
From report at bugs.python.org Wed May 21 15:19:22 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 21 May 2008 13:19:22 +0000
Subject: [New-bugs-announce] [issue2934] set() comparisons do not play well
with others
In-Reply-To: <1211375962.7.0.591442558325.issue2934@psf.upfronthosting.co.za>
Message-ID: <1211375962.7.0.591442558325.issue2934@psf.upfronthosting.co.za>
New submission from Nick Coghlan <ncoghlan at gmail.com>:
The rich compare implementation for set objects raises TypeError
directly instead of returning NotImplemented to allow the other type
involved in the comparison a chance at handling the operation.
----------
messages: 67152
nosy: ncoghlan
severity: normal
status: open
title: set() comparisons do not play well with others
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2934>
__________________________________
From report at bugs.python.org Wed May 21 16:44:40 2008
From: report at bugs.python.org (Erez Bibi)
Date: Wed, 21 May 2008 14:44:40 +0000
Subject: [New-bugs-announce] [issue2935] rfc822.py line 395 strings
connection
In-Reply-To: <1211381079.94.0.309829253424.issue2935@psf.upfronthosting.co.za>
Message-ID: <1211381079.94.0.309829253424.issue2935@psf.upfronthosting.co.za>
New submission from Erez Bibi <erezbibi at users.sourceforge.net>:
Python 2.5 on Windows
rfc822.py line 395
text = name + ": " + value
if 'value' is not a string python will generate an exception. It might
be due to a broken website, but it is not a reason to crash.
I'm using ClientCookie with a Request object (but I don't know the
faulty URL)
>>> req = urllib2.Request (url)
>>> page = ClientCookie.urlopen (req)
Traceback (most recent call last):
...
File "build\bdist.win32\egg\ClientCookie\_urllib2_support.py", line
824, in urlopen
return _opener.open(url, data)
File "C:\Python25\lib\urllib2.py", line 380, in open
response = meth(req, response)
File "build\bdist.win32\egg\ClientCookie\_urllib2_support.py", line
412, in http_response
headers[hdr] = val
File "C:\Python25\lib\rfc822.py", line 395, in __setitem__
text = name + ": " + value
TypeError: cannot concatenate 'str' and 'NoneType' objects
A simple fix is to replace
text = name + ": " + value
with
text = ("%s: %s" % (name, value))
In rfc822.py line 395
----------
components: Library (Lib)
files: rfc822.py
messages: 67157
nosy: erezbibi
severity: normal
status: open
title: rfc822.py line 395 strings connection
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file10391/rfc822.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2935>
__________________________________
From report at bugs.python.org Wed May 21 21:35:20 2008
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 21 May 2008 19:35:20 +0000
Subject: [New-bugs-announce] [issue2936] ctypes.util.find_library() doesn't
consult LD_LIBRARY_PATH
In-Reply-To: <1211398520.2.0.251558881651.issue2936@psf.upfronthosting.co.za>
Message-ID: <1211398520.2.0.251558881651.issue2936@psf.upfronthosting.co.za>
New submission from Bill Janssen <bill.janssen at gmail.com>:
The "find_library()" function in ctypes.util doesn't look in
LD_LIBRARY_PATH on Solaris or Linux or most other UNIX variants that use
that convention. This means that find_library() doesn't find libraries
that dlopen() would, and makes development with ctypes much harder than
it should be.
----------
components: Library (Lib)
messages: 67170
nosy: janssen
priority: normal
severity: normal
status: open
title: ctypes.util.find_library() doesn't consult LD_LIBRARY_PATH
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2936>
__________________________________
From report at bugs.python.org Wed May 21 22:36:57 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 21 May 2008 20:36:57 +0000
Subject: [New-bugs-announce] [issue2937] Incorrect rounding in
floating-point operations with gcc/x87
In-Reply-To: <1211402217.78.0.330998218554.issue2937@psf.upfronthosting.co.za>
Message-ID: <1211402217.78.0.330998218554.issue2937@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
On some older Intel 32-bit hardware, under Linux, floating-point
operations don't always give correctly rounded results. Here's an
example involving addition, on SuSE Linux 10.2/Xeon.
Python 2.6a3+ (trunk:63521, May 21 2008, 15:40:39)
[GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 1e16 + 2.999
10000000000000002.0
>>> 1e16 + 2.9999
10000000000000004.0
The second result should really be 1e16+2., not 1e16+4. This appears to
be related to this GCC issue:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
Various fixes are possible. One possible fix is to add the -ffloat-
store flag to the gcc options. Another is to use the information in
fpu_control.h, if available, to set the precision control. Yet another
is to sprinkle some 'volatile' modifiers throughout floatobject.c.
It's not clear to me that this *should* be fixed, but I think the
problem should at least be documented. Hence this bug report.
----------
components: Interpreter Core
messages: 67174
nosy: marketdickinson
priority: normal
severity: normal
status: open
title: Incorrect rounding in floating-point operations with gcc/x87
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2937>
__________________________________
From report at bugs.python.org Thu May 22 06:59:36 2008
From: report at bugs.python.org (Fan Decheng)
Date: Thu, 22 May 2008 04:59:36 +0000
Subject: [New-bugs-announce] [issue2938] Interactive help writes to the
python install destination directory
In-Reply-To: <1211432376.31.0.60210310996.issue2938@psf.upfronthosting.co.za>
Message-ID: <1211432376.31.0.60210310996.issue2938@psf.upfronthosting.co.za>
New submission from Fan Decheng <fandecheng at gmail.com>:
Python 3.0a5 on Windows Vista SP1
I installed it to C:\Python30, and used NTFS permissions to protect the
files in the directory from being changed, also making the whole
directory read-only. Thus, new files can't be created inside the directory.
Then:
1. Type help() in python. Python goes into interactive help mode.
2. Type "modules fnmatch" in python.
Result:
Help quits with the following error:
IOError: [Errno 13] Permission denied:
'C:\\Python30\\lib\\lib2to3\\tests\\..\\G
rammar3.0.0.alpha.5.pickle'
For detailed error info please see the attached text file.
----------
components: Library (Lib)
files: py3help_error.txt
messages: 67179
nosy: r_mosaic
severity: normal
status: open
title: Interactive help writes to the python install destination directory
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file10395/py3help_error.txt
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2938>
__________________________________
From report at bugs.python.org Thu May 22 09:45:06 2008
From: report at bugs.python.org (Sabine Nitsch)
Date: Thu, 22 May 2008 07:45:06 +0000
Subject: [New-bugs-announce] [issue2939] Apache mod_python python-func
strftime
In-Reply-To: <1211442305.92.0.687824708378.issue2939@psf.upfronthosting.co.za>
Message-ID: <1211442305.92.0.687824708378.issue2939@psf.upfronthosting.co.za>
New submission from Sabine Nitsch <snitsch at kuhnke.de>:
If you use the python-function strftime unter apache within mod_python
the function delivers as date the last startdate of apache and not the
current date.
----------
assignee: theller
components: ctypes
messages: 67182
nosy: raisachrisgun, theller
severity: normal
status: open
title: Apache mod_python python-func strftime
type: behavior
versions: Python 2.4
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2939>
__________________________________
From report at bugs.python.org Thu May 22 11:16:54 2008
From: report at bugs.python.org (Adrian M)
Date: Thu, 22 May 2008 09:16:54 +0000
Subject: [New-bugs-announce] [issue2940] Building Python fails on SunOS
In-Reply-To: <1211447814.19.0.559318035687.issue2940@psf.upfronthosting.co.za>
Message-ID: <1211447814.19.0.559318035687.issue2940@psf.upfronthosting.co.za>
New submission from Adrian M <syraxes at gmail.com>:
$ uname -a
SunOS ro1estw 5.9 Generic_117171-12 sun4u sparc SUNW,Sun-Fire-880
gcc 2.6.3
When running ./configure I'm getting warnings like:
configure: WARNING: curses.h: present but cannot be compiled
configure: WARNING: curses.h: check for missing prerequisite headers?
configure: WARNING: curses.h: see the Autoconf documentation
configure: WARNING: curses.h: section "Present But Cannot Be Compiled"
configure: WARNING: curses.h: proceeding with the preprocessor's result
configure: WARNING: curses.h: in the future, the compiler will take
precedence
This happens for many other headers as well (dlfcn.h, fcntl.h, and many
others - i'll attach the whole list of messages).
Then, the ./configure step ends with the following message :
checking size of int... configure: error: cannot compute sizeof (int)
----------
components: Build
files: config_logs.zip
messages: 67183
nosy: syraxes
severity: normal
status: open
title: Building Python fails on SunOS
type: compile error
versions: Python 2.5
Added file: http://bugs.python.org/file10397/config_logs.zip
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2940>
__________________________________
From report at bugs.python.org Thu May 22 12:18:26 2008
From: report at bugs.python.org (Alexandr Zamaraev)
Date: Thu, 22 May 2008 10:18:26 +0000
Subject: [New-bugs-announce] [issue2941] Propagate define to resurce mingw32
compile
In-Reply-To: <1211451506.25.0.765395098834.issue2941@psf.upfronthosting.co.za>
Message-ID: <1211451506.25.0.765395098834.issue2941@psf.upfronthosting.co.za>
New submission from Alexandr Zamaraev <shura_zam at users.sourceforge.net>:
If resource source file depend from macros definition passing from
define_macros parametr setup crash.
----------
components: Distutils
files: cygwinccompiler.diff
keywords: patch
messages: 67184
nosy: shura_zam
severity: normal
status: open
title: Propagate define to resurce mingw32 compile
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file10398/cygwinccompiler.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2941>
__________________________________
From report at bugs.python.org Thu May 22 12:24:41 2008
From: report at bugs.python.org (Alexandr Zamaraev)
Date: Thu, 22 May 2008 10:24:41 +0000
Subject: [New-bugs-announce] [issue2942] mingw/cygwin do not accept asm file
as extension source
In-Reply-To: <1211451880.92.0.894703588073.issue2942@psf.upfronthosting.co.za>
Message-ID: <1211451880.92.0.894703588073.issue2942@psf.upfronthosting.co.za>
New submission from Alexandr Zamaraev <shura_zam at users.sourceforge.net>:
mingw/cygwin do not accept asm file as extension source
----------
components: Distutils
files: cygwinccompiler.diff
keywords: patch
messages: 67185
nosy: shura_zam
severity: normal
status: open
title: mingw/cygwin do not accept asm file as extension source
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file10399/cygwinccompiler.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2942>
__________________________________
From report at bugs.python.org Thu May 22 13:33:02 2008
From: report at bugs.python.org (Cournapeau David)
Date: Thu, 22 May 2008 11:33:02 +0000
Subject: [New-bugs-announce] [issue2943] Distutils should generate a better
error message when the SDK is not installed
In-Reply-To: <1211455981.94.0.404413935613.issue2943@psf.upfronthosting.co.za>
Message-ID: <1211455981.94.0.404413935613.issue2943@psf.upfronthosting.co.za>
New submission from Cournapeau David <david at ar.media.kyoto-u.ac.jp>:
I tried to build some extensions with python 2.6 (built from sources
with VS 2008 express), and got some errors in the function
query_vcvarsall. The offending lines are:
if len(result) != len(interesting):
raise ValueError(str(list(result.keys())))
I got a value error here. After some investigation, I realized that it
was because I did not install the SDK. I think the error message could
be isgnificantly improved if installing the SDK was suggested in the
exception message.
----------
components: Distutils
messages: 67187
nosy: cdavid
severity: normal
status: open
title: Distutils should generate a better error message when the SDK is not installed
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2943>
__________________________________
From report at bugs.python.org Thu May 22 15:24:01 2008
From: report at bugs.python.org (Alexander Shigin)
Date: Thu, 22 May 2008 13:24:01 +0000
Subject: [New-bugs-announce] [issue2944] asyncore doesn't handle connection
refused correctly
In-Reply-To: <1211462641.02.0.497686644895.issue2944@psf.upfronthosting.co.za>
Message-ID: <1211462641.02.0.497686644895.issue2944@psf.upfronthosting.co.za>
New submission from Alexander Shigin <shigin at rambler-co.ru>:
Unix select returns socket in read fd set and write fd set if
nonblocking socket attempts to connect to unaviable address.
asyncore should check this case by calling getsockopt with SO_ERROR
optname. If return value is 0 it should call handle_connect_event,
otherwise if should call handle_expt_event.
Attached file prints "get exception" if asyncore can't connect to
remote side, not "uncaptured python exception"
Patches from Issue1736190 do not fix this case.
----------
components: Library (Lib)
files: test_async_connect.py
messages: 67188
nosy: shigin
severity: normal
status: open
title: asyncore doesn't handle connection refused correctly
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file10400/test_async_connect.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2944>
__________________________________
From report at bugs.python.org Thu May 22 16:34:32 2008
From: report at bugs.python.org (Hartmut Goebel)
Date: Thu, 22 May 2008 14:34:32 +0000
Subject: [New-bugs-announce] [issue2945] bdist_rpm does not list dist files
(should effect upload)
In-Reply-To: <1211466871.95.0.658180804984.issue2945@psf.upfronthosting.co.za>
Message-ID: <1211466871.95.0.658180804984.issue2945@psf.upfronthosting.co.za>
New submission from Hartmut Goebel <htgoebel at users.sourceforge.net>:
In Python 2.5 distutils has a bug in bdist_rpm:
Generated distribution files are not listed in
``distribution.dist_files``. Thus .rpms can not be handled by other
tools, eg. ``upload``.
I need this bug fixed for automated upload of files using
<http://origo-submit.origo.ethz.ch>.
Enclosed please find a simple package to show the bug. Just run
python setup.py bdist_rpm
and watch the (missing) output. In contrast see the output of
python setup.py sdist
Additionally:
While untested, this should effect distutils ``upload`` command. RPMs
are not in the dist_files list and when looking at the source, there
seams to be no 'trick' to add them later.
----------
components: Distutils
files: simple-0.0.0.0.1.tar.gz
messages: 67192
nosy: htgoebel
severity: normal
status: open
title: bdist_rpm does not list dist files (should effect upload)
versions: Python 2.5
Added file: http://bugs.python.org/file10403/simple-0.0.0.0.1.tar.gz
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2945>
__________________________________
From report at bugs.python.org Thu May 22 17:00:58 2008
From: report at bugs.python.org (Hartmut Goebel)
Date: Thu, 22 May 2008 15:00:58 +0000
Subject: [New-bugs-announce] [issue2946] setuptools: bdist_wininst adds
duplicate entry to dist_files
In-Reply-To: <1211468458.47.0.0516095652943.issue2946@psf.upfronthosting.co.za>
Message-ID: <1211468458.47.0.0516095652943.issue2946@psf.upfronthosting.co.za>
New submission from Hartmut Goebel <htgoebel at users.sourceforge.net>:
In setuptools 0.6c8 has a bug in bdist_wininst:
Distribution files are listed twice
``distribution.dist_files``. This hinders developing tools which use
this data. In addition ``upload`` will upload the file twice to pypi.
I need this bug fixed for automated upload of files using
<http://origo-submit.origo.ethz.ch>;.
Enclosed please find a simple package to show the bug. Just run
python setup.py bdist_wininst
this shows one entry. Now run
python setup-setuptools.py bdist_wininst
this shows two entires.
The only difference between both setup files is wherefrom setup() is
imported.
----------
components: Distutils
files: simple-0.0.0.0.1.tar.gz
messages: 67193
nosy: htgoebel
severity: normal
status: open
title: setuptools: bdist_wininst adds duplicate entry to dist_files
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10404/simple-0.0.0.0.1.tar.gz
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2946>
__________________________________
From report at bugs.python.org Thu May 22 17:18:06 2008
From: report at bugs.python.org (Helmut Jarausch)
Date: Thu, 22 May 2008 15:18:06 +0000
Subject: [New-bugs-announce] [issue2947] subprocess (Replacing popen) - add
a warning / hint
In-Reply-To: <1211469479.53.0.83820029984.issue2947@psf.upfronthosting.co.za>
Message-ID: <1211469479.53.0.83820029984.issue2947@psf.upfronthosting.co.za>
New submission from Helmut Jarausch <jarausch at skynet.be>:
Background:
I (as many others, too) have used the following code in the past
ARC='MyDumpFile'
tar_inp= os.popen('/bin/tar cjf '+ARC+' -T -','w')
....
tar_exit_code= tar_inp.close()
if tar_exit_code != None and tar_exit_code % 256 :
print "some error messages"
When replacing this - as suggested - by
TAR= Popen(('/bin/tar','cjf',ARC,'-T','-'),stdin=PIPE)
tar_inp= TAR.stdin
....
tar_inp.close() always returns None which was an indication
of NO ERROR when used together with popen.
So this has proabaly to be replaced by
tar_inp.close()
tar_exit_code= TAR.wait()
if tar_exit_code != 0 :
print "some error messages"
I suggest a warning / hint to change checking for errors
when upgrading to subprocess.Popen
----------
assignee: georg.brandl
components: Documentation
messages: 67195
nosy: HWJ, georg.brandl
severity: normal
status: open
title: subprocess (Replacing popen) - add a warning / hint
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2947>
__________________________________
From report at bugs.python.org Fri May 23 05:22:51 2008
From: report at bugs.python.org (Vasco Rodrigues)
Date: Fri, 23 May 2008 03:22:51 +0000
Subject: [New-bugs-announce] [issue2948] Unicode support for hashing
algorithms
In-Reply-To: <1211512970.98.0.439490076144.issue2948@psf.upfronthosting.co.za>
Message-ID: <1211512970.98.0.439490076144.issue2948@psf.upfronthosting.co.za>
New submission from Vasco Rodrigues <a29192 at ualg.pt>:
The hashing algorithms don't support Unicode. Any Unicode text given to
them is first tried to convert ascii and then hashed. Not all strings
are convertible to ascii.
Now that Unicode is becoming the default encoding, specially for the web
side of python, where a lot of this hashing algorithms are used.
There should be some kind of Unicode support in them.
Example:
from hashlib import md5
md5(u'jo?o')
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe3' in
position 2: ordinal not in range(128)
----------
components: Unicode
messages: 67214
nosy: vvro
severity: normal
status: open
title: Unicode support for hashing algorithms
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2948>
__________________________________
From report at bugs.python.org Fri May 23 13:22:49 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 23 May 2008 11:22:49 +0000
Subject: [New-bugs-announce] [issue2949] Windows installer doesn't include
OpenSSL license and notice
In-Reply-To: <1211541769.18.0.393592583867.issue2949@psf.upfronthosting.co.za>
Message-ID: <1211541769.18.0.393592583867.issue2949@psf.upfronthosting.co.za>
New submission from Marc-Andre Lemburg <mal at egenix.com>:
The _ssl module is built against OpenSSL.
Since I couldn't find any OpenSSL DLLs in my Python install dir and due
to the size of the _ssl.pyd, I assume that it is statically linked
against OpenSSL.
That's all fine, but then I'm missing the OpenSSL license and
attribution notice somewhere in the installer, the README of the
installation or elsewhere.
The download page should also include a hint that the Windows installer
does include crypto software, since in some countries it is illegal to
download and/or use crypto software, see e.g.
http://rechten.uvt.nl/koops/cryptolaw/cls-sum.htm
----------
components: Build, Installation, Windows
messages: 67228
nosy: lemburg
severity: normal
status: open
title: Windows installer doesn't include OpenSSL license and notice
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2949>
__________________________________
From report at bugs.python.org Fri May 23 15:39:28 2008
From: report at bugs.python.org (Andy Novocin)
Date: Fri, 23 May 2008 13:39:28 +0000
Subject: [New-bugs-announce] [issue2950] silly readline module problem
In-Reply-To: <1211549968.03.0.808725881847.issue2950@psf.upfronthosting.co.za>
Message-ID: <1211549968.03.0.808725881847.issue2950@psf.upfronthosting.co.za>
New submission from Andy Novocin <anovocin at math.fsu.edu>:
I installed python 2.5.2 on my SUSE 10.3 system which came with 2.4.4
and when you type
import readline
it returns No module named readline.
When installing I just unzipped, ./configure, make, sudo make install.
Im brand new to Linux and Python (probably clearly).
----------
components: Extension Modules
messages: 67236
nosy: AndyNovo
severity: normal
status: open
title: silly readline module problem
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2950>
__________________________________
From report at bugs.python.org Fri May 23 19:59:39 2008
From: report at bugs.python.org (Kathy Van Stone)
Date: Fri, 23 May 2008 17:59:39 +0000
Subject: [New-bugs-announce] [issue2951] ElementTree parsing bus error (but
only from mod_python)
In-Reply-To: <1211565579.45.0.763330988931.issue2951@psf.upfronthosting.co.za>
Message-ID: <1211565579.45.0.763330988931.issue2951@psf.upfronthosting.co.za>
New submission from Kathy Van Stone <kvs at acm.org>:
The follow code works fine when run directly. It crashes (with a bus
error) if used as a mod_python handler. It doesn't crash if ElementTree
is replaced with cElementTree.
from xml.etree import ElementTree as eltree
def handler(req):
body = """<?xml version='1.0' encoding='utf-8'?>
<collection uuid="~01edc22c1628e711ddb20220296b032019"
href="http://localhost:8888/ws/dataset/~01edc22c1628e711ddb20220296b032019">
<name>Service_offerings query at 2008-05-23 12:47:28.038233</name>
</collection>"""
response_elem = eltree.XML(body)
return 0
I don't know if this a mod_python or ElementTree issue, but it looks
more like an ElementTree problem.
----------
components: Library (Lib), Macintosh
messages: 67259
nosy: kathyvs
severity: normal
status: open
title: ElementTree parsing bus error (but only from mod_python)
type: crash
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2951>
__________________________________
From report at bugs.python.org Fri May 23 21:09:30 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Fri, 23 May 2008 19:09:30 +0000
Subject: [New-bugs-announce] [issue2952] List comprehensions are leaking
variables
In-Reply-To: <1211569769.38.0.125136210909.issue2952@psf.upfronthosting.co.za>
Message-ID: <1211569769.38.0.125136210909.issue2952@psf.upfronthosting.co.za>
New submission from Ismail Donmez <ismail at namtrac.org>:
Originally found at http://www.randombit.net/weblog/programming/variable_leak_in_list_compre
hensions.html
First example :
[~]> python
Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> x=1
>>> [x for x in [1,2,3]]
[1, 2, 3]
>>> x
3
whoops x changed.
Another example from original post:
$ python
Python 2.4.4 (#1, Mar 7 2008, 14:54:19)
[GCC 4.1.2 (Gentoo 4.1.2 p1.0.2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> x = { 1:2, 3:4 }
>>> nothere
Traceback (most recent call last):
File "", line 1, in ?
NameError: name 'nothere' is not defined
>>> [nothere for nothere in x.keys()]
[1, 3]
>>> nothere
3
This bug doesn't seem to affect py3k but it does python 2.4/2.5. Either
this should be fixed or documented as a caveat.
----------
components: Library (Lib)
messages: 67261
nosy: cartman
severity: normal
status: open
title: List comprehensions are leaking variables
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2952>
__________________________________
From report at bugs.python.org Fri May 23 22:26:05 2008
From: report at bugs.python.org (Maciek Fijalkowski)
Date: Fri, 23 May 2008 20:26:05 +0000
Subject: [New-bugs-announce] [issue2953] _zip_directory_cache untested and
undocumented
In-Reply-To: <1211574365.23.0.256921758457.issue2953@psf.upfronthosting.co.za>
Message-ID: <1211574365.23.0.256921758457.issue2953@psf.upfronthosting.co.za>
New submission from Maciek Fijalkowski <fijal at genesilico.pl>:
_zip_directory_cache has no single test nor piece of documentation. The
only place where it's mentioned is a call to method .clear() on it in
tests. Besides, it can be whatever. Despite _ prefix, which I would
consider to be private, distutils crash obscurely if it's not there or
does not contain sequences as keys.
----------
assignee: georg.brandl
components: Distutils, Documentation, Extension Modules
messages: 67267
nosy: fijal, georg.brandl
severity: normal
status: open
title: _zip_directory_cache untested and undocumented
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2953>
__________________________________
From report at bugs.python.org Fri May 23 23:53:07 2008
From: report at bugs.python.org (Leandro Lucarella)
Date: Fri, 23 May 2008 21:53:07 +0000
Subject: [New-bugs-announce] [issue2954] [PATCH] Make bisect module
functions accept an optional comparison callable
In-Reply-To: <1211579587.7.0.195890795343.issue2954@psf.upfronthosting.co.za>
Message-ID: <1211579587.7.0.195890795343.issue2954@psf.upfronthosting.co.za>
New submission from Leandro Lucarella <llucax at gmail.com>:
bisect module functions should accept a comparison callable to customize
the way items are compared to do the binary search.
Attached is a patch to the Python implementation of bisect module.
----------
components: Library (Lib)
files: bisect.py.cmp.patch
keywords: patch
messages: 67271
nosy: llucax
severity: normal
status: open
title: [PATCH] Make bisect module functions accept an optional comparison callable
type: feature request
versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file10420/bisect.py.cmp.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2954>
__________________________________
From report at bugs.python.org Sat May 24 05:08:18 2008
From: report at bugs.python.org (Daniel Crowley-Wilson)
Date: Sat, 24 May 2008 03:08:18 +0000
Subject: [New-bugs-announce] [issue2955] Python 2.5 Documentation error in
Tutorial section 8.3
In-Reply-To: <1211598495.79.0.572068175443.issue2955@psf.upfronthosting.co.za>
Message-ID: <1211598495.79.0.572068175443.issue2955@psf.upfronthosting.co.za>
New submission from Daniel Crowley-Wilson <daniel.crowley.wilson at gmail.com>:
The code sample in Tutorial section 8.3 (Handling Exceptions) doesn't
match the description. Removing the "break" line from the code sample
would make the sample perform according to the description. Found in the
windows doc\python25.chm file.
Original text is below:
***
It is possible to write programs that handle selected exceptions. Look
at the following example, which asks the user for input until a valid
integer has been entered, but allows the user to interrupt the program
(using Control-C or whatever the operating system supports); note that a
user-generated interruption is signalled by raising the
KeyboardInterrupt exception.
>>> while True:
... try:
... x = int(raw_input("Please enter a number: "))
... break
... except ValueError:
... print "Oops! That was no valid number. Try again..."
...
----------
assignee: georg.brandl
components: Documentation
messages: 67281
nosy: dcw303, georg.brandl
severity: normal
status: open
title: Python 2.5 Documentation error in Tutorial section 8.3
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2955>
__________________________________
From report at bugs.python.org Sat May 24 12:28:47 2008
From: report at bugs.python.org (Haoyu Bai)
Date: Sat, 24 May 2008 10:28:47 +0000
Subject: [New-bugs-announce] [issue2956] 2to3 should have a way to disable
some fixers
In-Reply-To: <1211624926.75.0.230496362406.issue2956@psf.upfronthosting.co.za>
Message-ID: <1211624926.75.0.230496362406.issue2956@psf.upfronthosting.co.za>
New submission from Haoyu Bai <divinekid at gmail.com>:
Sometime we need to enable all fixers but one or two, eg. the 'import'
fixer. So it would be fine if there's a way to do that.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 67289
nosy: bhy, collinwinter
severity: normal
status: open
title: 2to3 should have a way to disable some fixers
type: feature request
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2956>
__________________________________
From report at bugs.python.org Sat May 24 12:50:10 2008
From: report at bugs.python.org (Haoyu Bai)
Date: Sat, 24 May 2008 10:50:10 +0000
Subject: [New-bugs-announce] [issue2957] recursion limit exceeded when
importing .pyc module
In-Reply-To: <1211626208.53.0.435870200974.issue2957@psf.upfronthosting.co.za>
Message-ID: <1211626208.53.0.435870200974.issue2957@psf.upfronthosting.co.za>
New submission from Haoyu Bai <divinekid at gmail.com>:
To reproduce the bug, save the uploaded huge.py, then import the module
twice:
$ python3 -c 'import huge'
$ python3 -c 'import huge'
Traceback (most recent call last):
File "<string>", line 1, in <module>
ValueError: recursion limit exceeded
But there's no such problem in Python 2.5.2.
----------
components: Interpreter Core
files: huge.py
messages: 67290
nosy: bhy
severity: normal
status: open
title: recursion limit exceeded when importing .pyc module
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file10423/huge.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2957>
__________________________________
From report at bugs.python.org Sat May 24 15:55:44 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 24 May 2008 13:55:44 +0000
Subject: [New-bugs-announce] [issue2958] update Lib/test/README
In-Reply-To: <1211637344.19.0.700206389482.issue2958@psf.upfronthosting.co.za>
Message-ID: <1211637344.19.0.700206389482.issue2958@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
A good bug day task:
Lib/test/README is a bit dated. It still talks about old-style Python
tests which have been almost completely removed in 2.6 (and none more
should be written.) The assert* methods of unittest should also be
stressed instead of test_support.verify etc.
----------
components: Tests
keywords: easy
messages: 67300
nosy: benjamin.peterson
priority: low
severity: normal
status: open
title: update Lib/test/README
type: feature request
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2958>
__________________________________
From report at bugs.python.org Sun May 25 01:26:13 2008
From: report at bugs.python.org (Michael Magin)
Date: Sat, 24 May 2008 23:26:13 +0000
Subject: [New-bugs-announce] [issue2959] calling GzipFile close() more than
once causes exception
In-Reply-To: <1211671572.76.0.880996454775.issue2959@psf.upfronthosting.co.za>
Message-ID: <1211671572.76.0.880996454775.issue2959@psf.upfronthosting.co.za>
New submission from Michael Magin <mmagin at lowerarchy.com>:
Built-in file objects allow repeated calls to .close(), even the
documentation states, "Calling close() more than once is allowed."
(http://docs.python.org/lib/bltin-file-objects.html)
GzipFile does not obey this aspect of the file interface:
>>> import gzip
>>> f = gzip.GzipFile('testfile1.gz', 'ab')
>>> f.close()
>>> f.close()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File
"/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/gzip.py",
line 315, in close
self.fileobj.write(self.compress.flush())
AttributeError: 'NoneType' object has no attribute 'write'
The gzip documentation does not document this (mis-)behavior.
(Trivial) patch against 2.4.3 gzip.py attached.
----------
components: Library (Lib)
files: gzip.py.patch
keywords: patch
messages: 67313
nosy: mmagin
severity: normal
status: open
title: calling GzipFile close() more than once causes exception
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file10431/gzip.py.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2959>
__________________________________
From report at bugs.python.org Sun May 25 05:18:03 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 25 May 2008 03:18:03 +0000
Subject: [New-bugs-announce] [issue2960] bsddb/test/test_replication.py bus
error, segfault, assertion error, pass
In-Reply-To: <1211685483.73.0.203518027491.issue2960@psf.upfronthosting.co.za>
Message-ID: <1211685483.73.0.203518027491.issue2960@psf.upfronthosting.co.za>
New submission from Gregory P. Smith <greg at krypto.org>:
Using Linux with BerkeleyDB 4.7.25 the bsddb/test/test_replication.py
test is very flaky. It alternately passes, raises an AssertionError
because of the timeout or gets a segmentation fault or bus error.
(side note: i updated test_replication to not use hard coded port numbers)
I have not tried this test using other BerkeleyDB versions.
----------
assignee: jcea
components: Extension Modules
messages: 67318
nosy: gregory.p.smith, jcea
priority: high
severity: normal
status: open
title: bsddb/test/test_replication.py bus error, segfault, assertion error, pass
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2960>
__________________________________
From report at bugs.python.org Sun May 25 07:56:50 2008
From: report at bugs.python.org (Chester)
Date: Sun, 25 May 2008 05:56:50 +0000
Subject: [New-bugs-announce] [issue2961] Two error messages inconsistent
In-Reply-To: <1211695010.07.0.381155349233.issue2961@psf.upfronthosting.co.za>
Message-ID: <1211695010.07.0.381155349233.issue2961@psf.upfronthosting.co.za>
New submission from Chester <wxpythoner at gmail.com>:
Hello,
I would like to report that two error messages of the Python parser are
not consistent. Please take a look at this:
>>> a = "hello"
>>> a + 1
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: cannot concatenate 'str' and 'int' objects
>>> 1 + a
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'
When the order of the objects is changed, that should only change the
order of the 'str' and 'int' words in the message.
So if a+1, then
TypeError: cannot concatenate 'str' and 'int' objects
and if 1+a, then
TypeError: cannot concatenate 'int' and 'str' objects
----------
messages: 67319
nosy: chester
severity: normal
status: open
title: Two error messages inconsistent
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2961>
__________________________________
From report at bugs.python.org Sun May 25 08:54:36 2008
From: report at bugs.python.org (Chester)
Date: Sun, 25 May 2008 06:54:36 +0000
Subject: [New-bugs-announce] [issue2962] Goodbye, 'global' statement!
In-Reply-To: <1211698476.24.0.0646576377448.issue2962@psf.upfronthosting.co.za>
Message-ID: <1211698476.24.0.0646576377448.issue2962@psf.upfronthosting.co.za>
New submission from Chester <wxpythoner at gmail.com>:
The 'global' statement is used to mark a variable as global. It is
used in functions to allow statements in the function body to rebind
global variables. Using the 'global' statement is generally
considered poor style and should be avoided whenever possible.
Example:
count = 1
def inc():
global count
count = count + 1
Since the use of the 'global' statement is frowned upon, it should be
removed from Python 3.0.
----------
components: Interpreter Core
messages: 67322
nosy: chester
severity: normal
status: open
title: Goodbye, 'global' statement!
type: feature request
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2962>
__________________________________
From report at bugs.python.org Sun May 25 10:05:49 2008
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 25 May 2008 08:05:49 +0000
Subject: [New-bugs-announce] [issue2963] Method cache is broken in Py3
In-Reply-To: <1211702749.69.0.15718735899.issue2963@psf.upfronthosting.co.za>
Message-ID: <1211702749.69.0.15718735899.issue2963@psf.upfronthosting.co.za>
New submission from Stefan Behnel <scoder at users.sourceforge.net>:
The method cache is deactivated in current Py3. As Lisandro Dalc?n
noticed, the following code in typeobject.c always returns false for a
Py3 identifier:
#define MCACHE_CACHEABLE_NAME(name) \
PyString_CheckExact(name) && \
PyString_GET_SIZE(name) <= MCACHE_MAX_ATTR_SIZE
----------
components: Interpreter Core
messages: 67328
nosy: scoder
severity: normal
status: open
title: Method cache is broken in Py3
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2963>
__________________________________
From report at bugs.python.org Sun May 25 11:09:30 2008
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 25 May 2008 09:09:30 +0000
Subject: [New-bugs-announce] [issue2964] instancemethod_descr_get() lacks an
INCREF
In-Reply-To: <1211706570.33.0.362667787125.issue2964@psf.upfronthosting.co.za>
Message-ID: <1211706570.33.0.362667787125.issue2964@psf.upfronthosting.co.za>
New submission from Stefan Behnel <scoder at users.sourceforge.net>:
Here is a fix for Objects/classobject.c in Py3.0a5 that fixes a ref
count crash for classmethods.
----------
components: Interpreter Core
files: instancemethod-fix.patch
keywords: patch
messages: 67334
nosy: scoder
severity: normal
status: open
title: instancemethod_descr_get() lacks an INCREF
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file10434/instancemethod-fix.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2964>
__________________________________
From report at bugs.python.org Sun May 25 11:46:24 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 25 May 2008 09:46:24 +0000
Subject: [New-bugs-announce] [issue2965] Update interface of weakref
dictionaries
In-Reply-To: <1211708783.58.0.883984457478.issue2965@psf.upfronthosting.co.za>
Message-ID: <1211708783.58.0.883984457478.issue2965@psf.upfronthosting.co.za>
New submission from Georg Brandl <georg at python.org>:
The weak dictionaries in the weakref module still present the 2.x
dictionary methods (iter*). This should be fixed for consistency with 3k
dicts.
----------
components: Library (Lib)
messages: 67339
nosy: georg.brandl
priority: critical
severity: normal
status: open
title: Update interface of weakref dictionaries
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2965>
__________________________________
From report at bugs.python.org Sun May 25 12:21:42 2008
From: report at bugs.python.org (Peter Puk)
Date: Sun, 25 May 2008 10:21:42 +0000
Subject: [New-bugs-announce] [issue2966] pydoc doesnt show 'from module
import identifier' in the docs
In-Reply-To: <1211710902.46.0.335827912868.issue2966@psf.upfronthosting.co.za>
Message-ID: <1211710902.46.0.335827912868.issue2966@psf.upfronthosting.co.za>
New submission from Peter Puk <peter.puk at gmail.com>:
When you try to make a doc from your programm woth pydoc, it doesnt show
the the identifiers in the modules section. when i put 'from module
import identifier' in my code
----------
components: Extension Modules
messages: 67340
nosy: peter.puk
severity: normal
status: open
title: pydoc doesnt show 'from module import identifier' in the docs
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2966>
__________________________________
From report at bugs.python.org Sun May 25 13:35:57 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Sun, 25 May 2008 11:35:57 +0000
Subject: [New-bugs-announce] [issue2967] [PATCH] Rename Tkinter to tkinter
in test_tcl
In-Reply-To: <1211715357.08.0.700119566525.issue2967@psf.upfronthosting.co.za>
Message-ID: <1211715357.08.0.700119566525.issue2967@psf.upfronthosting.co.za>
New submission from Ismail Donmez <ismail at namtrac.org>:
Tkinter module is renamed to tkinter. test_tcl should be updated for this.
Patch attached.
----------
components: Tests
files: tcl.patch
keywords: patch
messages: 67341
nosy: cartman
severity: normal
status: open
title: [PATCH] Rename Tkinter to tkinter in test_tcl
versions: Python 3.0
Added file: http://bugs.python.org/file10436/tcl.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2967>
__________________________________
From report at bugs.python.org Sun May 25 17:14:18 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 25 May 2008 15:14:18 +0000
Subject: [New-bugs-announce] [issue2968] Test_imports takes a long time to
run
In-Reply-To: <1211728458.35.0.22936057327.issue2968@psf.upfronthosting.co.za>
Message-ID: <1211728458.35.0.22936057327.issue2968@psf.upfronthosting.co.za>
New submission from Martin v. L?wis <martin at v.loewis.de>:
Test_imports takes a very long time to complete. I believe this is due
to the individual refactorings taking such a long time, even though they
apply to small pieces of code only.
----------
messages: 67348
nosy: loewis
severity: normal
status: open
title: Test_imports takes a long time to run
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2968>
__________________________________
From report at bugs.python.org Sun May 25 17:19:11 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 25 May 2008 15:19:11 +0000
Subject: [New-bugs-announce] [issue2969] Test_imports fails in 2.6
In-Reply-To: <1211728751.03.0.714435224741.issue2969@psf.upfronthosting.co.za>
Message-ID: <1211728751.03.0.714435224741.issue2969@psf.upfronthosting.co.za>
New submission from Martin v. L?wis <martin at v.loewis.de>:
Test_imports fails for selected cases, when run under Python 2.6.
E.g. from_import_usage fails for rewriting __builtin__ print, and also
for __builtin__ zip.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 67349
nosy: collinwinter, loewis
severity: normal
status: open
title: Test_imports fails in 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2969>
__________________________________
From report at bugs.python.org Mon May 26 07:02:25 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Mon, 26 May 2008 05:02:25 +0000
Subject: [New-bugs-announce] [issue2970] test_distutils fails on Linux
In-Reply-To: <1211778144.81.0.940040536081.issue2970@psf.upfronthosting.co.za>
Message-ID: <1211778144.81.0.940040536081.issue2970@psf.upfronthosting.co.za>
New submission from Ismail Donmez <ismail at namtrac.org>:
This is on Ubuntu 8.04 :
test_distutils
Using PyPI login from /home/cartman/Sources/py3k/Lib/distutils/tests/.pypirc
Using PyPI login from /home/cartman/Sources/py3k/Lib/distutils/tests/.pypirc
Using PyPI login from /home/cartman/Sources/py3k/Lib/distutils/tests/.pypirc
test test_distutils produced unexpected output:
**********************************************************************
*** lines 2-3 of actual output doesn't appear in expected output after
line 1:
+ Using PyPI login from
/home/cartman/Sources/py3k/Lib/distutils/tests/.pypirc
+ Using PyPI login from
/home/cartman/Sources/py3k/Lib/distutils/tests/.pypirc
**********************************************************************
Same test passes on Darwin and outputs 5 lines so it might be a bug in
the expected output instead.
----------
components: Tests
messages: 67364
nosy: cartman
severity: normal
status: open
title: test_distutils fails on Linux
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2970>
__________________________________
From report at bugs.python.org Mon May 26 07:13:25 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Mon, 26 May 2008 05:13:25 +0000
Subject: [New-bugs-announce] [issue2971] test_zipfile64 fails
In-Reply-To: <1211778804.81.0.308743565458.issue2971@psf.upfronthosting.co.za>
Message-ID: <1211778804.81.0.308743565458.issue2971@psf.upfronthosting.co.za>
New submission from Ismail Donmez <ismail at namtrac.org>:
test_zipfile64
testDeflated (test.test_zipfile64.TestsWithSourceFile) ... ERROR
testStored (test.test_zipfile64.TestsWithSourceFile) ... ERROR
======================================================================
ERROR: testDeflated (test.test_zipfile64.TestsWithSourceFile)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/cartman/Sources/py3k/Lib/test/test_zipfile64.py", line 41,
in setUp
fp.write(self.data)
File "/home/cartman/Sources/py3k/Lib/io.py", line 987, in write
raise TypeError("can't write str to binary stream")
TypeError: can't write str to binary stream
======================================================================
ERROR: testStored (test.test_zipfile64.TestsWithSourceFile)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/cartman/Sources/py3k/Lib/test/test_zipfile64.py", line 41,
in setUp
fp.write(self.data)
File "/home/cartman/Sources/py3k/Lib/io.py", line 987, in write
raise TypeError("can't write str to binary stream")
TypeError: can't write str to binary stream
----------------------------------------------------------------------
Ran 2 tests in 2.151s
FAILED (errors=2)
test test_zipfile64 failed -- errors occurred; run in verbose mode for
details
'test_zipfile64' left behind file '@test'
1 test failed:
test_zipfile64
----------
components: Tests
messages: 67365
nosy: cartman
severity: normal
status: open
title: test_zipfile64 fails
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2971>
__________________________________
From report at bugs.python.org Mon May 26 18:17:16 2008
From: report at bugs.python.org (Henrik Vendelbo)
Date: Mon, 26 May 2008 16:17:16 +0000
Subject: [New-bugs-announce] [issue2972] arguments and default path not set
in site.py and sitecustomize.py
In-Reply-To: <1211818636.32.0.584139114136.issue2972@psf.upfronthosting.co.za>
Message-ID: <1211818636.32.0.584139114136.issue2972@psf.upfronthosting.co.za>
New submission from Henrik Vendelbo <hvendelbo.dev at googlemail.com>:
If you want to use site.py/sitecustomize.py as a regular python script,
altering behaviour of calling the python exe, there is a significant
problem.
sys.argv isn't assigned until after site.py completes, and the directory
of the script to execute is added to sys.path after site.py completes as
well.
If it cannot be introduced for backwards compatibility, there should at
least be a way to access the information
----------
components: None
messages: 67372
nosy: hvendelbo
severity: normal
status: open
title: arguments and default path not set in site.py and sitecustomize.py
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2972>
__________________________________
From report at bugs.python.org Mon May 26 19:15:22 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 26 May 2008 17:15:22 +0000
Subject: [New-bugs-announce] [issue2973] _ssl compiler warnings
In-Reply-To: <1211822122.76.0.619319801709.issue2973@psf.upfronthosting.co.za>
Message-ID: <1211822122.76.0.619319801709.issue2973@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
When compiling the _ssl extension on MacOS 10.4, I get these warnings:
/users/benjamin/python/trunk/Modules/_ssl.c: In function
'_get_peer_alt_names':
/users/benjamin/python/trunk/Modules/_ssl.c:694 warning: passing
argument 2 of 'ASN1_item_d2i' from incompatible pointer type
/users/benjamin/python/trunk/Modules/_ssl.c:698: warning: passing
argument 2 of 'method->d2i' from incompatible pointer type
----------
components: Extension Modules
messages: 67376
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: _ssl compiler warnings
type: compile error
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2973>
__________________________________
From report at bugs.python.org Mon May 26 20:26:39 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Mon, 26 May 2008 18:26:39 +0000
Subject: [New-bugs-announce] [issue2974] test_subprocess fails on Darwin
In-Reply-To: <1211826399.44.0.0384568842407.issue2974@psf.upfronthosting.co.za>
Message-ID: <1211826399.44.0.0384568842407.issue2974@psf.upfronthosting.co.za>
New submission from Ismail Donmez <ismail at namtrac.org>:
./python -E -tt -bb ./Lib/test/regrtest.py -l -uall
[...]
test_subprocess
.
this bit of output is from a test of stdout in a different process
...
test test_subprocess failed -- Traceback (most recent call last):
File "/Users/cartman/Sources/py3k/Lib/test/test_subprocess.py", line
407, in test_no_leaking
data = p.communicate("lime")[0]
File "/Users/cartman/Sources/py3k/Lib/subprocess.py", line 599, in
communicate
return self._communicate(input)
File "/Users/cartman/Sources/py3k/Lib/subprocess.py", line 1086, in
_communicate
rlist, wlist, xlist = select.select(read_set, write_set, [])
select.error: (4, 'Interrupted system call')
----------
components: Tests
messages: 67381
nosy: cartman
severity: normal
status: open
title: test_subprocess fails on Darwin
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2974>
__________________________________
From report at bugs.python.org Mon May 26 21:56:36 2008
From: report at bugs.python.org (Jim Kleckner)
Date: Mon, 26 May 2008 19:56:36 +0000
Subject: [New-bugs-announce] [issue2975] VS8 include dirs grow without bound
In-Reply-To: <1211831796.1.0.811493312376.issue2975@psf.upfronthosting.co.za>
Message-ID: <1211831796.1.0.811493312376.issue2975@psf.upfronthosting.co.za>
New submission from Jim Kleckner <jek-python at kleckner.net>:
I tracked down a testing failure for Cython tests
on the Windows platform to be the result of how the
Visual C environment variables are being detected.
In the function, query_vcvarsall, the .bat file:
"C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat"
is being run with the arguments:
x86 & set
This in turn calls the platform-specific file vcvars32.bat (or other).
In this file, the PATH, INCLUDE, and LIBPATH environment variables are
simply being appended/prepended with their values.
initialize() then just overrides the os.environ values with these
monotonically growing variables.
It seems that duplicate names should be filtered out from these paths
to prevent overflow.
The attached patch seems to fix this issue, if a bit brute force.
Please review as a candidate.
=====
@set
PATH=%DevEnvDir%;%VCINSTALLDIR%\BIN;%VSINSTALLDIR%\Common7\Tools;%VSINSTALLDIR%\Common7\Tools\bin;%FrameworkDir%\%Framework35Version%;%FrameworkDir%\%Framework35Version%\Microsoft
.NET Framework 3.5 (Pre-Release
Version);%FrameworkDir%\%FrameworkVersion%;%VCINSTALLDIR%\VCPackages;%PATH%
@set INCLUDE=%VCINSTALLDIR%\ATLMFC\INCLUDE;%VCINSTALLDIR%\INCLUDE;%INCLUDE%
@set LIB=%VCINSTALLDIR%\ATLMFC\LIB;%VCINSTALLDIR%\LIB;%LIB%
@set
LIBPATH=%FrameworkDir%\%Framework35Version%;%FrameworkDir%\%FrameworkVersion%;%VCINSTALLDIR%\ATLMFC\LIB;%VCINSTALLDIR%\LIB;%LIBPATH%
=====
----------
components: Distutils
files: dist.patch
keywords: patch
messages: 67387
nosy: jkleckner
severity: normal
status: open
title: VS8 include dirs grow without bound
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file10442/dist.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2975>
__________________________________
From report at bugs.python.org Mon May 26 22:23:01 2008
From: report at bugs.python.org (Thomas Heller)
Date: Mon, 26 May 2008 20:23:01 +0000
Subject: [New-bugs-announce] [issue2976] test_pydoc fails in trunk
In-Reply-To: <1211833381.06.0.61569848147.issue2976@psf.upfronthosting.co.za>
Message-ID: <1211833381.06.0.61569848147.issue2976@psf.upfronthosting.co.za>
New submission from Thomas Heller <theller at ctypes.org>:
Would be nice if this is fixed, since it is currently the only failing
test on some windows buildbots.
----------
messages: 67390
nosy: theller
severity: normal
status: open
title: test_pydoc fails in trunk
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2976>
__________________________________
From report at bugs.python.org Mon May 26 22:37:49 2008
From: report at bugs.python.org (Hugh Myers)
Date: Mon, 26 May 2008 20:37:49 +0000
Subject: [New-bugs-announce] [issue2977] truncation of text in tables in
Library Reference PDF
In-Reply-To: <1211834269.04.0.0744383580947.issue2977@psf.upfronthosting.co.za>
Message-ID: <1211834269.04.0.0744383580947.issue2977@psf.upfronthosting.co.za>
New submission from Hugh Myers <hsmyers at gmail.com>:
Pages: 81, 87, 88 and 89 all have tables that truncate the last column.
----------
assignee: georg.brandl
components: Documentation
messages: 67392
nosy: georg.brandl, hsmyers
severity: normal
status: open
title: truncation of text in tables in Library Reference PDF
type: performance
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2977>
__________________________________
From report at bugs.python.org Mon May 26 22:39:52 2008
From: report at bugs.python.org (Hugh Myers)
Date: Mon, 26 May 2008 20:39:52 +0000
Subject: [New-bugs-announce] [issue2978] typo in text of page 80 of Library
Reference PDF
In-Reply-To: <1211834392.64.0.398728350153.issue2978@psf.upfronthosting.co.za>
Message-ID: <1211834392.64.0.398728350153.issue2978@psf.upfronthosting.co.za>
New submission from Hugh Myers <hsmyers at gmail.com>:
Page 80 of the 2.5 Library Reference has the text "easily write you
own"; should be "easily write your own".
----------
assignee: georg.brandl
components: Documentation
messages: 67393
nosy: georg.brandl, hsmyers
severity: normal
status: open
title: typo in text of page 80 of Library Reference PDF
type: performance
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2978>
__________________________________
From report at bugs.python.org Tue May 27 02:09:50 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Tue, 27 May 2008 00:09:50 +0000
Subject: [New-bugs-announce] [issue2979] use_datetime in SimpleXMLRPCServer
In-Reply-To: <1211846989.94.0.031553096454.issue2979@psf.upfronthosting.co.za>
Message-ID: <1211846989.94.0.031553096454.issue2979@psf.upfronthosting.co.za>
New submission from Virgil Dupras <hsoft at hardcoded.net>:
It seems strange to me that xmlrpclib.ServerProxy has a use_datetime
argument, but not SimpleXMLRPCServer or CGIXMLRPCRequestHandler.
I'm hereby submitting a patch to fix this.
Sorry for the shaky testing (I only really test SimpleXMLRPCDispatcher),
but trying to test at the SimpleXMLRPCServer level using the current http_server() scheme quickly became dirty, so I backed off.
----------
components: Library (Lib)
files: SimpleXMLRPCServer_use_datetime.diff
keywords: patch
messages: 67400
nosy: vdupras
severity: normal
status: open
title: use_datetime in SimpleXMLRPCServer
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10445/SimpleXMLRPCServer_use_datetime.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2979>
__________________________________
From report at bugs.python.org Tue May 27 17:38:15 2008
From: report at bugs.python.org (Haukur Hreinsson)
Date: Tue, 27 May 2008 15:38:15 +0000
Subject: [New-bugs-announce] [issue2980] Pickle stream for unicode object
may contain non-ASCII characters.
In-Reply-To: <1211902695.6.0.958731947697.issue2980@psf.upfronthosting.co.za>
Message-ID: <1211902695.6.0.958731947697.issue2980@psf.upfronthosting.co.za>
New submission from Haukur Hreinsson <python at mawbid.com>:
I'm not sure if this is a functionality or documentation bug.
The docs say in section 13.1.2, Data stream format
(http://docs.python.org/lib/node315.html):
"By default, the pickle data format uses a printable ASCII representation."
I took that to mean that only ASCII characters ever appear in the pickle
output, but that's not true.
>>> print [ord(c) for c in pickle.dumps(u'?')]
[86, 225, 10, 112, 48, 10, 46]
----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 67410
nosy: Mawbid, georg.brandl
severity: normal
status: open
title: Pickle stream for unicode object may contain non-ASCII characters.
type: feature request
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2980>
__________________________________
From report at bugs.python.org Tue May 27 17:56:10 2008
From: report at bugs.python.org (Yu LI)
Date: Tue, 27 May 2008 15:56:10 +0000
Subject: [New-bugs-announce] [issue2981] confusing action of struct.pack and
struct.unpack with fmt 'p'
In-Reply-To: <1211903770.4.0.523120419892.issue2981@psf.upfronthosting.co.za>
Message-ID: <1211903770.4.0.523120419892.issue2981@psf.upfronthosting.co.za>
New submission from Yu LI <liyu1981 at gmail.com>:
As documented, build in module struct has two format for string objects,
such as 's' 'p'. They suggest following actions
>>> struct.pack('5s', 'hello')
'hello'
>>> struct.pack('6p', 'hello')
'\x05hello'
However, the second action really confuses people. In the documentation:
the "p" format character encodes a "Pascal string", meaning a short
variable-length string stored in a fixed number of bytes. So people
naturally assumes following action
>>> struct.pack('p', 'hello')
'\x05hello'
which makes more sense. Otherwise, why people should use format 'p'?
Either when you struct.pack or struct.unpack you have to know the size
of string at first, why not turn to format 's'? Also the the bigger
number (6) before 'p' makes people confuse. Why should it be string size
+ 1? If we know there is a padding character and the string size, why
not struct.unpack('x5s', abuf) instead?
So the suggestion is to modify the behavior of format string 'p' to be
the same as people's intuition. In detail, the actions should be
>>> s = struct.pack('p', 'hello')
'\x05hello'
>>> struct.unpack('p', s)
('hello',)
And also these actions should be consist with struct.pack_into and
struct.unpack_from
----------
components: Library (Lib)
messages: 67411
nosy: liyu
severity: normal
status: open
title: confusing action of struct.pack and struct.unpack with fmt 'p'
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2981>
__________________________________
From report at bugs.python.org Tue May 27 18:27:08 2008
From: report at bugs.python.org (Maciek Fijalkowski)
Date: Tue, 27 May 2008 16:27:08 +0000
Subject: [New-bugs-announce] [issue2982] more tests for pyexpat
In-Reply-To: <1211905628.44.0.670797216201.issue2982@psf.upfronthosting.co.za>
Message-ID: <1211905628.44.0.670797216201.issue2982@psf.upfronthosting.co.za>
New submission from Maciek Fijalkowski <fijal at genesilico.pl>:
pyexpat tests are a bit erratic. For example, there is no single test
for handlers for:
NotStandalone, StartDoctypeDecl, EndDoctypeDecl, EntityDecl, XmlDecl,
ElementDecl, AttlistDecl, SkippedEntity.
There is also not a single test for error handling working correctly.
Cheers,
fijal
----------
components: Tests
messages: 67412
nosy: fijal, therve
severity: normal
status: open
title: more tests for pyexpat
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2982>
__________________________________
From report at bugs.python.org Tue May 27 19:57:12 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 27 May 2008 17:57:12 +0000
Subject: [New-bugs-announce] [issue2983] Ttk support for Tkinter
In-Reply-To: <1211911032.63.0.360625687085.issue2983@psf.upfronthosting.co.za>
Message-ID: <1211911032.63.0.360625687085.issue2983@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
Hello, this issue could be considered an extension of issue2618 and
maybe I should have continued there but.. continuing,
I'm proposing the inclusion of a ttk module (should be renamed to Ttk
for python 2.x) that would fit inside lib-tk or the new tkinter package.
This is a wrapper for the new themed widget set included with Tk 8.5,
which will also work if you have the tile package installed and an older
Tk version (I tested with Tk 8.4 only).
The code and docs are at:
http://svn.python.org/view/sandbox/trunk/ttk-gsoc/
----------
components: Tkinter
messages: 67419
nosy: gpolo
severity: normal
status: open
title: Ttk support for Tkinter
versions: Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2983>
__________________________________
From report at bugs.python.org Tue May 27 20:31:59 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Tue, 27 May 2008 18:31:59 +0000
Subject: [New-bugs-announce] [issue2984] test_dbm fails on Darwin
In-Reply-To: <1211913119.29.0.969619534727.issue2984@psf.upfronthosting.co.za>
Message-ID: <1211913119.29.0.969619534727.issue2984@psf.upfronthosting.co.za>
New submission from Ismail Donmez <ismail at namtrac.org>:
test test_dbm failed -- Traceback (most recent call last):
File "/Users/cartman/Sources/py3k/Lib/test/test_dbm.py", line 121, in
test_whichdb
self.assertEqual(name, dbm.whichdb(_fname))
AssertionError: 'dbm.gnu' != 'dbm.ndbm'
This happened after the dbm unification that happened due to stdlib re-
organization.
----------
components: Tests
messages: 67423
nosy: cartman
severity: normal
status: open
title: test_dbm fails on Darwin
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2984>
__________________________________
From report at bugs.python.org Tue May 27 21:26:50 2008
From: report at bugs.python.org (Riku Lindblad)
Date: Tue, 27 May 2008 19:26:50 +0000
Subject: [New-bugs-announce] [issue2985] xmlrpclib doesn't support 64bit
integer replies
In-Reply-To: <1211916410.6.0.0284106941576.issue2985@psf.upfronthosting.co.za>
Message-ID: <1211916410.6.0.0284106941576.issue2985@psf.upfronthosting.co.za>
New submission from Riku Lindblad <riku.lindblad at gmail.com>:
When querying a XML-RPC server that returns a 64 bit integer, the python
interface always returns an empty tuple.
When running with verbose=True the response is still intact, the library
just can't parse the result between the <i8></i8> tags.
Example response:
body: '<?xml version="1.0"
encoding="UTF-8"?>\r\n<methodResponse>\r\n<params>\r\n<param><value><i8>1157</i8></value></param>\r\n</params>\r\n</methodResponse>\r\n'
----------
components: Library (Lib)
messages: 67426
nosy: shrike
severity: normal
status: open
title: xmlrpclib doesn't support 64bit integer replies
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2985>
__________________________________
From report at bugs.python.org Tue May 27 22:29:59 2008
From: report at bugs.python.org (Nate)
Date: Tue, 27 May 2008 20:29:59 +0000
Subject: [New-bugs-announce] [issue2986] difflib.SequenceMatcher not
matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
New submission from Nate <natester at gmail.com>:
The following code shows no matches though the strings clearly match.
from difflib import *
a =
'''3904320338155955662857322172779218727992471109386112515279452352973279311752006856588512503244702012502812653160306927721351031250270279878152125021081471125246894603319162986283456469448293252335442814953964029718671705515246437056879456095915444174665464026255415736754542680178373675412998898571410483714801783736754144828361714801783736754133068408714801783736754140859665714801783736754153851004471480178373675415715864371410690714801783736754147488890714801783736205957668017837367545448801783104170539154677705102536314736754477780178373675415217103227148017837367541737811137714801783736754172791151671480178373675417692995271480178373675417575983571480178373675417398965871480178310417055026467770551235573705687945609591544562532964082675415736300610425832914520311514810301595721999571547897879113780178373618951021983280377781981989237498913678981414213198924949892679989164882577810944751102884217048258978791137801783104170511836542073627327981801279360326159714801783736171798080178310415420736447510213871790638471586131412631592131012571210126718031314200414571314893700123874777987006697747115770067074789312578013869801783104120529166337056879456095918495136604565251349544838956219513495753741344870733943253617458316356794745831634651172458316348316144586052838244151360641656349118903581890331689038658903263218549028909605134957536316060'''
b =
'''4634320338155955662857322172779218727992471109386112515279452352973279311752006856588512503244702012502812653160306927721351031250270279878152125021081471125246894603319162986283456469448293252335442814953964029718671705515246437056879456095915444174665464026255415736754542680178373675412998898571410483714801783736754144828361714801783736754133068408714801783736754140859665714801783736754153851004471480178373675415715864371410690714801783736754147488890714801783736205957668017837367545448801783104170539154677705102536314736754477780178373675413182108117148017837367541737811137714801783736754172791151671480178373675417692995271480178373675417575983571480178373675417398965871480178310417055026467770551235573705687945609591544562532964082675415736300610425832914520311514810301595721999571547897879113780178373618951021983280377781981989237498913678981414213198924949892679989164882577810944751102884217048258978791137801783104170511836542073627327981801279360326159714801783736171798080178310415420736447510213871790638471412131420041457131485122165131466702097131466731723131466741536131466751581131466771649131466761975131467212090131467261974131467231858131467201556131467212538131467221553131467221943131467231748131466711452131467271787131412578013869801783104154307361718482280178373638585436251621338931320893185072980138084820801545115716861861152948618615002682261422349251058108327767521397977810837298017831041205291663370568794560959184951366045652513495448389562195134957537413448707339432536174583163'''
lst = [(a,b)]
for a, b in lst:
print "---------------------------"
s = SequenceMatcher(None, a, b)
print "length of a is %d" % len(a)
print "length of b is %d" % len(b)
print s.find_longest_match(0, len(a), 0, len(b))
print s.ratio()
for block in s.get_matching_blocks():
m = a[block[0]:block[0]+block[2]]
print "a[%d] and b[%d] match for %d elements and it is \"%s\"" %
(block[0], block[1], block[2], m)
----------
components: Extension Modules
messages: 67428
nosy: hagna
severity: normal
status: open
title: difflib.SequenceMatcher not matching long sequences
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2986>
__________________________________
From report at bugs.python.org Tue May 27 22:40:37 2008
From: report at bugs.python.org (Hans Ulrich Niedermann)
Date: Tue, 27 May 2008 20:40:37 +0000
Subject: [New-bugs-announce] [issue2987] RFC2732 support for urlparse (e.g.
http://[::1]:80/)
In-Reply-To: <1211920837.73.0.839643919886.issue2987@psf.upfronthosting.co.za>
Message-ID: <1211920837.73.0.839643919886.issue2987@psf.upfronthosting.co.za>
New submission from Hans Ulrich Niedermann <hun at n-dimensional.de>:
The urlparse module's ways of splitting the location into hostname and
port breaks with RFC2732 style URIs with IPv6 addresses in them:
>>> import urlparse
>>> urlparse.urlparse('http://[::1]:80/').hostname
'['
>>> urlparse.urlparse('http://[::1]:80/').port
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.5/urlparse.py", line 116, in port
return int(port, 10)
ValueError: invalid literal for int() with base 10: ':1]:80'
>>>
A simple fix is attached, but probably requires a little more thought.
----------
components: Library (Lib)
files: python-urlparse-rfc2732-fix.patch
keywords: patch
messages: 67430
nosy: ndim
severity: normal
status: open
title: RFC2732 support for urlparse (e.g. http://[::1]:80/)
type: feature request
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file10451/python-urlparse-rfc2732-fix.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
__________________________________
From report at bugs.python.org Wed May 28 10:31:24 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 28 May 2008 08:31:24 +0000
Subject: [New-bugs-announce] [issue2988] Invalid cookies crash web
applications
In-Reply-To: <1211963484.7.0.388679808819.issue2988@psf.upfronthosting.co.za>
Message-ID: <1211963484.7.0.388679808819.issue2988@psf.upfronthosting.co.za>
New submission from anatoly techtonik <techtonik at gmail.com>:
Current BaseCookie and SimpleCookie may crash web-application when
running on the same domain with other scripts. Other scripts may create
invalid cookies that lead to Cookie.CookieError: Illegal key value in
Python.
This created problems in:
trac: http://trac.edgewall.org/ticket/2256
mailman: http://bugs.python.org/issue472646
roundup:
http://svn.python.org/view/tracker/roundup-src/roundup/cgi/client.py?rev=61320&r1=61200&r2=61320
Test case consists of two scripts - one in PHP and one in Python where
the former crashes the latter when run on the same domain through IE6:
------[cookie.php]
<?php
setcookie("cook:test", "php set", time()+60*60);
print_r($_COOKIE);
?>
------------------
------[cookie.py]-
#!/usr/bin/env python
import Cookie
from os import environ as env
C = Cookie.SimpleCookie()
C["CUX2"] = 123
C["CUX2"]['expires'] = 60*60*60
print "Content-Type: text/html"
print C
print # blank line, end of headers
print env["HTTP_COOKIE"]
G = Cookie.SimpleCookie(env["HTTP_COOKIE"])
print "<br/>Next: "
print G
------------------
What would be the pythonic way to avoid people making their own wrappers
when stumbling upon the problem?
1. Patch *Cookie classes to display warning about invalid Cookie and
continue instead of crashing with CookieError
2. Add SilentCookie that ignores invalid Cookies
3. Patch BaseCookie.load method to include optional attribute to ignore
errors. Should it be turned on by default (like in roundup code above)
4. Add warning to BaseCookie.load documentation about the pitfall and
the need to catch CookieError here
http://docs.python.org/dev/library/cookie.html#Cookie.BaseCookie.load
----------
components: Extension Modules
messages: 67443
nosy: techtonik
severity: normal
status: open
title: Invalid cookies crash web applications
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2988>
_______________________________________
From report at bugs.python.org Wed May 28 12:52:39 2008
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 28 May 2008 10:52:39 +0000
Subject: [New-bugs-announce] [issue2989] type_modified() in typeobject.c
should be public
In-Reply-To: <1211971959.25.0.491588550226.issue2989@psf.upfronthosting.co.za>
Message-ID: <1211971959.25.0.491588550226.issue2989@psf.upfronthosting.co.za>
New submission from Stefan Behnel <scoder at users.sourceforge.net>:
Here is a patch that makes this function public. This allows C code to
correctly taint a type after updating its attributes or base classes.
----------
components: Interpreter Core
files: pytype_modified.patch
keywords: patch
messages: 67444
nosy: scoder
severity: normal
status: open
title: type_modified() in typeobject.c should be public
type: feature request
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10457/pytype_modified.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2989>
_______________________________________
From report at bugs.python.org Wed May 28 13:07:18 2008
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 28 May 2008 11:07:18 +0000
Subject: [New-bugs-announce] [issue2990] type cache updates might run
cleanup code in an inconsistent state
In-Reply-To: <1211972838.31.0.400694776413.issue2990@psf.upfronthosting.co.za>
Message-ID: <1211972838.31.0.400694776413.issue2990@psf.upfronthosting.co.za>
New submission from Stefan Behnel <scoder at users.sourceforge.net>:
Similar to the "decref before set" issue solved by Py_CLEAR(), the code
in typeobject.c calls DECREF in the middle of a cache update. This
leaves one cache entry in an invalid state during the DECREF call, which
might result in running cleanup code in this state. If this code depends
on an attribute lookup, this might lead to a cache lookup, which in turn
can access the infected part of the cache. In the worst case, such a
scenario can lead to a crash as it accesses an already cleaned-up object.
Here is a patch that fixes this.
----------
components: Interpreter Core
files: possible-decref-before-set-fix.patch
keywords: patch
messages: 67445
nosy: scoder
severity: normal
status: open
title: type cache updates might run cleanup code in an inconsistent state
type: behavior
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10458/possible-decref-before-set-fix.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2990>
_______________________________________
From report at bugs.python.org Wed May 28 18:26:21 2008
From: report at bugs.python.org (Hugh Myers)
Date: Wed, 28 May 2008 16:26:21 +0000
Subject: [New-bugs-announce] [issue2991] Bad behavior in PythonWin
In-Reply-To: <1211991981.32.0.0267592863248.issue2991@psf.upfronthosting.co.za>
Message-ID: <1211991981.32.0.0267592863248.issue2991@psf.upfronthosting.co.za>
New submission from Hugh Myers <hsmyers at gmail.com>:
Got this just now:
C:\Python25\Lib\site-packages\pythonwin\pywin\scintilla\view.py:641:
DeprecationWarning: 'L' format requires 0 <= number <= 4294967295
fr = struct.pack('LLIIIIIIIIll', hdcRender, hdcFormat, rc[0], rc[1],
rc[2], rc[3], rc[0], rc[1], rc[2], rc[3], pageStart, lengthDoc)
Can't be good...
----------
components: Windows
messages: 67451
nosy: hsmyers
severity: normal
status: open
title: Bad behavior in PythonWin
type: behavior
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2991>
_______________________________________
From report at bugs.python.org Wed May 28 18:29:45 2008
From: report at bugs.python.org (Hugh Myers)
Date: Wed, 28 May 2008 16:29:45 +0000
Subject: [New-bugs-announce] [issue2992] Bad behavior in PythonWin
In-Reply-To: <1211992185.54.0.00393701483526.issue2992@psf.upfronthosting.co.za>
Message-ID: <1211992185.54.0.00393701483526.issue2992@psf.upfronthosting.co.za>
New submission from Hugh Myers <hsmyers at gmail.com>:
View Whitespace started up enabled when file loaded. Had I left it on
when I shut down the editor I would understand(somewhat) the
persistence. However I turned it off before I left. This now happens
every time I load the file. Shouldn't.
----------
components: Windows
messages: 67452
nosy: hsmyers
severity: normal
status: open
title: Bad behavior in PythonWin
type: behavior
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2992>
_______________________________________
From report at bugs.python.org Wed May 28 18:31:01 2008
From: report at bugs.python.org (Hugh Myers)
Date: Wed, 28 May 2008 16:31:01 +0000
Subject: [New-bugs-announce] [issue2993] Bad behavior in PythonWin
In-Reply-To: <1211992261.04.0.186034891848.issue2993@psf.upfronthosting.co.za>
Message-ID: <1211992261.04.0.186034891848.issue2993@psf.upfronthosting.co.za>
New submission from Hugh Myers <hsmyers at gmail.com>:
Use of column guides can cause bogus indentation errors. Pattern yet to
be determined.
----------
components: Windows
messages: 67453
nosy: hsmyers
severity: normal
status: open
title: Bad behavior in PythonWin
type: behavior
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2993>
_______________________________________
From report at bugs.python.org Wed May 28 18:33:57 2008
From: report at bugs.python.org (Hugh Myers)
Date: Wed, 28 May 2008 16:33:57 +0000
Subject: [New-bugs-announce] [issue2994] Bad behavior in PythonWin
In-Reply-To: <1211992437.76.0.620587625462.issue2994@psf.upfronthosting.co.za>
Message-ID: <1211992437.76.0.620587625462.issue2994@psf.upfronthosting.co.za>
New submission from Hugh Myers <hsmyers at gmail.com>:
On a 43 line file, printer printed 29 pages, mostly blank(occasional
page and title info across top--- somewhat random). Good news is printer
performance is consistent with print preview!
----------
components: Windows
messages: 67454
nosy: hsmyers
severity: normal
status: open
title: Bad behavior in PythonWin
type: behavior
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2994>
_______________________________________
From report at bugs.python.org Wed May 28 19:19:40 2008
From: report at bugs.python.org (Matthias Sommer)
Date: Wed, 28 May 2008 17:19:40 +0000
Subject: [New-bugs-announce] [issue2995] Idle, some Linuxes,
cannot position Cursor by mouseclick
In-Reply-To: <1211995180.72.0.174580651078.issue2995@psf.upfronthosting.co.za>
Message-ID: <1211995180.72.0.174580651078.issue2995@psf.upfronthosting.co.za>
New submission from Matthias Sommer <sunny0815 at gmxpro.de>:
I'm used to be able to position the cursor by clicking on the desired
position. When running Idle (1.2.2 with Python 2.5.2) under Mandriva
Linux 2008 (or under Arch Linux 64 or i686 as well as FaunOS a Arch
based live distro) this does not work.
Running under windows it works, running under Xandros linux on my eee pc
it works too, so it's not linux specific.
I already asked on the german python ng. There have been reports that it
works too on Suse and Ubuntu. But as of yet no hint where to look to
make it working under Arch oder Mandriva.
Strange enough, i can position the Cursor by Ctrl-clicking.
I tried with a tiny Tk program with a single text field - there the
positioning does work too.
So it seems to be a bug in the distro(s) and regarding only Idle not
Tkinter in total.
----------
components: IDLE
messages: 67460
nosy: Sunny0815
severity: normal
status: open
title: Idle, some Linuxes, cannot position Cursor by mouseclick
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2995>
_______________________________________
From report at bugs.python.org Wed May 28 23:09:06 2008
From: report at bugs.python.org (Russell Blau)
Date: Wed, 28 May 2008 21:09:06 +0000
Subject: [New-bugs-announce] [issue2996] IDLE "find in files" output not
formatted optimally
In-Reply-To: <1212008945.94.0.774872087064.issue2996@psf.upfronthosting.co.za>
Message-ID: <1212008945.94.0.774872087064.issue2996@psf.upfronthosting.co.za>
New submission from Russell Blau <russblau at hotmail.com>:
Using the very handy "Find in files" dialog produces an output window
that ends with the line "(Hint: right-click to open locations.)" The
only problem is, right-clicking on that window currently doesn't work
because the output isn't formatted in the way that the right-click
action is looking for. Here is a patch that makes the right-click
functionality work.
----------
components: Library (Lib)
files: grepdialog.diff
keywords: patch
messages: 67464
nosy: russell.blau
severity: normal
status: open
title: IDLE "find in files" output not formatted optimally
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10459/grepdialog.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2996>
_______________________________________
From report at bugs.python.org Thu May 29 09:55:58 2008
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 29 May 2008 07:55:58 +0000
Subject: [New-bugs-announce] [issue2997] PyNumberMethods has left-over
fields in Py3
In-Reply-To: <1212047758.76.0.831845847254.issue2997@psf.upfronthosting.co.za>
Message-ID: <1212047758.76.0.831845847254.issue2997@psf.upfronthosting.co.za>
New submission from Stefan Behnel <scoder at users.sourceforge.net>:
Here is a patch that removes three unused fields from the
PyNumberMethods struct in Py3. Since two fields were already removed
(one even before the ones this patch removes), there is no way existing
Py2 C code that uses this struct can work in Py3 without changes, so it
doesn't add any problems.
----------
components: Interpreter Core
files: pynumbermethods-cleanup.patch
keywords: patch
messages: 67477
nosy: scoder
severity: normal
status: open
title: PyNumberMethods has left-over fields in Py3
versions: Python 3.0
Added file: http://bugs.python.org/file10461/pynumbermethods-cleanup.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2997>
_______________________________________
From report at bugs.python.org Thu May 29 09:58:43 2008
From: report at bugs.python.org (Rahman)
Date: Thu, 29 May 2008 07:58:43 +0000
Subject: [New-bugs-announce] [issue2998] UnicodeEncodeError: 'ascii' codec
can't encode character
In-Reply-To: <1212047923.66.0.22448326673.issue2998@psf.upfronthosting.co.za>
Message-ID: <1212047923.66.0.22448326673.issue2998@psf.upfronthosting.co.za>
New submission from Rahman <muallim-i_ali at hotmail.com>:
Hi i Rahman Yazgan. I live in Turkey. I am pyhton(pyqt) programmer.
I found a bug :
UnicodeEncodeError: 'ascii' codec can't encode character
QLineEdit.text(),... UnicodeEncodeError so ascii codecs, can't encoding.
python version 2.5(windows) python25/lib/site.py line 381-383 :
if encoding != "ascii":
# On Non-Unicode builds this will raise an AttributeError...
sys.setdefaultencoding(encoding) # Needs Python Unicode build !
UnicodeEncodeError: 'ascii' codec can't encode character so resoluble:
if encoding != "ascii":
# On Non-Unicode builds this will raise an AttributeError...
sys.setdefaultencoding(encoding) # Needs Python Unicode build !
if encoding == "ascii":
sys.setdefaultencoding("utf-8")
----------
components: Unicode
files: site.py
messages: 67478
nosy: Muallim-i ?li
severity: normal
status: open
title: UnicodeEncodeError: 'ascii' codec can't encode character
versions: Python 2.5
Added file: http://bugs.python.org/file10462/site.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2998>
_______________________________________
From report at bugs.python.org Thu May 29 16:08:44 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 29 May 2008 14:08:44 +0000
Subject: [New-bugs-announce] [issue2999] Py30a5: str.replace() tiny doc error
In-Reply-To: <1212070124.26.0.110608739832.issue2999@psf.upfronthosting.co.za>
Message-ID: <1212070124.26.0.110608739832.issue2999@psf.upfronthosting.co.za>
New submission from Mark Summerfield <mark at qtrac.eu>:
>>> help(str.replace)
Help on method_descriptor:
replace(...)
S.replace (old, new[, maxsplit]) -> unicode
Return a copy of S with all occurrences of substring
old replaced by new. If the optional argument maxsplit is
given, only the first maxsplit occurrences are replaced.
The variable name maxsplit should be "maxreplacements" or similar.
Also "-> unicode" should be "-> str"
----------
assignee: georg.brandl
components: Documentation
messages: 67491
nosy: georg.brandl, mark
severity: normal
status: open
title: Py30a5: str.replace() tiny doc error
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2999>
_______________________________________
From report at bugs.python.org Thu May 29 16:21:31 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 29 May 2008 14:21:31 +0000
Subject: [New-bugs-announce] [issue3000] 2to3 doesn't handle print(whatever);
print nor string.* functions
In-Reply-To: <1212070891.46.0.168640128737.issue3000@psf.upfronthosting.co.za>
Message-ID: <1212070891.46.0.168640128737.issue3000@psf.upfronthosting.co.za>
New submission from Mark Summerfield <mark at qtrac.eu>:
Py30a5
2to3 currently does not cope correctly with this:
print whatever; print
which it converts to:
print(whatever); print
This is a subtle error since "print" on its own is valid.
Nor does it replace the deprecated string functions,
string.capitalize(), string.count(), string.join(), string.lower(),
string.replace(), string.split(), and string.strip().
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 67493
nosy: collinwinter, mark
severity: normal
status: open
title: 2to3 doesn't handle print(whatever); print nor string.* functions
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3000>
_______________________________________
From report at bugs.python.org Thu May 29 17:28:11 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Thu, 29 May 2008 15:28:11 +0000
Subject: [New-bugs-announce] [issue3001] RLock's are SLOW
In-Reply-To: <1212074891.45.0.23606216758.issue3001@psf.upfronthosting.co.za>
Message-ID: <1212074891.45.0.23606216758.issue3001@psf.upfronthosting.co.za>
New submission from Jes?s Cea Avi?n <jcea at jcea.es>:
threading.RLock acquire/release is very slow. A order of magnitude
higher than no reentrant threading.Lock:
"""
def RLockSpeed() :
import time, threading
t=time.time()
result={}
for i in xrange(1000000) :
pass
result["empty loop"]=time.time()-t
l=threading.Lock()
t=time.time()
for i in xrange(1000000) :
l.acquire()
l.release()
result["Lock"]=time.time()-t
l=threading.RLock()
t=time.time()
for i in xrange(1000000) :
l.acquire()
l.release()
result["RLock"]=time.time()-t
return result
if __name__=="__main__" :
print RLockSpeed()
"""
Result:
{'empty loop': 0.074212074279785156, 'RLock': 10.144084215164185,
'Lock': 1.2489800453186035}
----------
messages: 67497
nosy: jcea
severity: normal
status: open
title: RLock's are SLOW
type: performance
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3001>
_______________________________________
From report at bugs.python.org Thu May 29 17:32:30 2008
From: report at bugs.python.org (albert hofkamp)
Date: Thu, 29 May 2008 15:32:30 +0000
Subject: [New-bugs-announce] [issue3002] shutil.copyfile blocks indefinitely
on named pipes
In-Reply-To: <1212075150.42.0.761610345558.issue3002@psf.upfronthosting.co.za>
Message-ID: <1212075150.42.0.761610345558.issue3002@psf.upfronthosting.co.za>
New submission from albert hofkamp <a.t.hofkamp at tue.nl>:
shutil.copytree() uses shutil.copyfile() to copy files recursively.
shutil.copyfile() opens the source file for reading, and the destination
file for writing, followed by a call to shutil.copyfileobj().
If the file happens to be a named pipe rather than a normal file,
opening for read blocks the copying function, since the Unix OS needs a
writer process to attach to the same named pipe before the open-for-read
succeeds.
Rather than opening the file for reading, the correct action would
probably be to simply create a new named pipe with the same name at the
destination.
Looking at the Python2.3 code, the same type of problem seem to exist
for other non-normal file-types other than symlinks (eg device files,
sockets, and possibly a few others).
----------
components: Library (Lib)
messages: 67498
nosy: aioryi
severity: normal
status: open
title: shutil.copyfile blocks indefinitely on named pipes
type: behavior
versions: Python 2.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3002>
_______________________________________
From report at bugs.python.org Thu May 29 18:43:56 2008
From: report at bugs.python.org (Mark Veldhuis)
Date: Thu, 29 May 2008 16:43:56 +0000
Subject: [New-bugs-announce] [issue3003] sys.stdin.fileno() gives attribute
error in IDLE
In-Reply-To: <1212079435.96.0.611621924039.issue3003@psf.upfronthosting.co.za>
Message-ID: <1212079435.96.0.611621924039.issue3003@psf.upfronthosting.co.za>
New submission from Mark Veldhuis <mv at marvelid.com>:
I am using IDLE on Ubuntu Hardy (8.04) and all in all very content to
use it. Today I got an AttributeError using sys.stdin.fileno(). A closer
look revealed this:
in IDLE:
Python 2.5.2 (r252:60911, Apr 21 2008, 11:12:42)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "copyright", "credits" or "license()" for more information.
****************************************************************
Personal firewall software may warn about the connection IDLE
makes to its subprocess using this computer's internal loopback
interface. This connection is not visible on any external
interface and no data is sent to or received from the Internet.
****************************************************************
IDLE 1.2.2
>>> import sys
>>> dir(sys.stdin)
['_RPCProxy__attributes', '_RPCProxy__getattributes',
'_RPCProxy__getmethods', '_RPCProxy__methods', '__class__',
'__delattr__', '__dict__', '__doc__', '__getattr__', '__getattribute__',
'__hash__', '__init__', '__module__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__setattr__', '__str__', '__weakref__',
'encoding', 'oid', 'sockio']
>>>
in terminal:
:~$ python
Python 2.5.2 (r252:60911, Apr 21 2008, 11:12:42)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> dir(sys.stdin)
['__class__', '__delattr__', '__doc__', '__enter__', '__exit__',
'__getattribute__', '__hash__', '__init__', '__iter__', '__new__',
'__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__',
'close', 'closed', 'encoding', 'fileno', 'flush', 'isatty', 'mode',
'name', 'newlines', 'next', 'read', 'readinto', 'readline', 'readlines',
'seek', 'softspace', 'tell', 'truncate', 'write', 'writelines',
'xreadlines']
>>>
I expected to see more or less the same output, is that right? I could
not find information on this online, so I report it as a bug.
greetings, Mark
----------
components: IDLE
messages: 67503
nosy: mooz123
severity: normal
status: open
title: sys.stdin.fileno() gives attribute error in IDLE
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3003>
_______________________________________
From report at bugs.python.org Thu May 29 20:35:55 2008
From: report at bugs.python.org (Arnaud Bergeron)
Date: Thu, 29 May 2008 18:35:55 +0000
Subject: [New-bugs-announce] [issue3004] Bug in slice.indices()
In-Reply-To: <1212086155.65.0.0693111742843.issue3004@psf.upfronthosting.co.za>
Message-ID: <1212086155.65.0.0693111742843.issue3004@psf.upfronthosting.co.za>
New submission from Arnaud Bergeron <abergeron at gmail.com>:
When calling the indices method of a slice object with a negative stop
larger in absolute value than the length passed, the returned stop value
is always -1. It should be 0 when the step is positive.
Current behavior:
>>> slice(-10).indices(11)
(0, 1, 1)
>>> slice(-10).indices(10)
(0, 0, 1)
>>> slice(-10).indices(9)
(0, -1, 1)
>>> slice(-10).indices(8)
(0, -1, 1)
Expected behavior:
>>> slice(-10).indices(11)
(0, 1, 1)
>>> slice(-10).indices(10)
(0, 0, 1)
>>> slice(-10).indices(9)
(0, 0, 1)
>>> slice(-10).indices(8)
(0, 0, 1)
The patch I submit trivially fixes this while preserving the expected -1
when the step is negative like in:
>>> slice(None, -10, -1).indices(8)
(7, -1, -1)
This issue affects python 2.5 and 2.6 at least. I did not test with
other versions.
----------
components: Interpreter Core
files: slice.patch
keywords: patch
messages: 67506
nosy: anakha
severity: normal
status: open
title: Bug in slice.indices()
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file10466/slice.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3004>
_______________________________________
From report at bugs.python.org Thu May 29 20:43:46 2008
From: report at bugs.python.org (kee nethery)
Date: Thu, 29 May 2008 18:43:46 +0000
Subject: [New-bugs-announce] [issue3005] EasyDialogs - documentation
enhancement
In-Reply-To: <1212086626.42.0.0907184132146.issue3005@psf.upfronthosting.co.za>
Message-ID: <1212086626.42.0.0907184132146.issue3005@psf.upfronthosting.co.za>
New submission from kee nethery <kee at kagi.com>:
issue: We spent quite a bit of time trying to figure out why EasyDialogs
was not working, no dialogs were appearing. Eventually I had to check an
AIM and noticed several icons bouncing in the dock. Scrolled over one
and it claimed it was Python, and when selected, displayed the dialog we
had been trying to get to appear. A simple sentence explaining how to
make the dialog appear would be a useful addition to the documentation.
URL for the docs shown below. Existing intro paragraph shown below.
Suggested additional sentence shown below.
url: http://docs.python.org/mac/module-EasyDialogs.html
existing: The EasyDialogs module contains some simple dialogs for the
Macintosh. All routines take an optional resource ID parameter id with
which one can override the DLOG resource used for the dialog, provided
that the dialog items correspond (both type and item number) to those in
the default DLOG resource. See source code for details.
suggested: The EasyDialogs module contains some simple dialogs for the
Macintosh. The dialogs get launched in a separate application which
appears in the dock and must be clicked on for the dialogs be displayed.
All routines take an optional resource ID parameter id with which one
can override the DLOG resource used for the dialog, provided that the
dialog items correspond (both type and item number) to those in the
default DLOG resource. See source code for details.
Thanks, kee nethery
----------
assignee: georg.brandl
components: Documentation
messages: 67507
nosy: georg.brandl, keenethery
severity: normal
status: open
title: EasyDialogs - documentation enhancement
type: feature request
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3005>
_______________________________________
From report at bugs.python.org Thu May 29 23:02:39 2008
From: report at bugs.python.org (Matt Mulsow)
Date: Thu, 29 May 2008 21:02:39 +0000
Subject: [New-bugs-announce] [issue3006] subprocess.Popen causes socket to
remain open after close
In-Reply-To: <1212094958.77.0.0391223554576.issue3006@psf.upfronthosting.co.za>
Message-ID: <1212094958.77.0.0391223554576.issue3006@psf.upfronthosting.co.za>
New submission from Matt Mulsow <matt.mulsow at gmail.com>:
On Windows, when a suprocess.Popen command is issued while
a socket connection is being handled the socket connection
will not close until the output of the subprocess is consumed.
The connection remains open even though the request.close()
command returns successfully and the program starts listening
for the next connection.
On Windows, the request.close() call translates to the C function
closesocket. The closesocket function by default attempts to do
a graceful close in the background. By changing the linger structure,
the closesocket function can be made to do a hard close. That fixes
my problem, but then queued data may not be flushed before the
socket closes. I cannot figure out why the closesocket's graceful
shutdown is waiting for the Popen command to complete.
This problem does not show up with the equivalent os.popen command.
To reproduce:
run socketTest.py
use telnet to connect on port 6288
watch for connection to close or not
----------
components: Library (Lib)
files: socketTest.py
messages: 67511
nosy: mamulsow
severity: normal
status: open
title: subprocess.Popen causes socket to remain open after close
type: resource usage
versions: Python 2.5
Added file: http://bugs.python.org/file10471/socketTest.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3006>
_______________________________________
From report at bugs.python.org Fri May 30 00:26:33 2008
From: report at bugs.python.org (Humberto Diogenes)
Date: Thu, 29 May 2008 22:26:33 +0000
Subject: [New-bugs-announce] [issue3007] Remove old StringIO docs
In-Reply-To: <1212099992.88.0.316581826794.issue3007@psf.upfronthosting.co.za>
Message-ID: <1212099992.88.0.316581826794.issue3007@psf.upfronthosting.co.za>
New submission from Humberto Diogenes <humberto at digi.com.br>:
StringIO was merged into the `io` module, but the old stringio.rst docs
are still there.
----------
assignee: georg.brandl
components: Documentation
files: io.stringio-docs.patch
keywords: patch
messages: 67515
nosy: georg.brandl, hdiogenes
severity: normal
status: open
title: Remove old StringIO docs
versions: Python 3.0
Added file: http://bugs.python.org/file10472/io.stringio-docs.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3007>
_______________________________________
From report at bugs.python.org Fri May 30 09:47:45 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 30 May 2008 07:47:45 +0000
Subject: [New-bugs-announce] [issue3008] Let bin() show floats
In-Reply-To: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
Message-ID: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:
Let bin() show floating point values. This would contribute quite a
bit to people's understanding of floating point arithmetic. It has a
nice education value and it makes it easier to diagnose floating point
mysteries.
def vis(f):
""" Show binary representation of a floating point number:
>>> vis(math.pi)
'0b11.001001000011111101101010100010001000010110100011'
>>> vis(-0.375)
'-0b0.011'
"""
f, sign = (f, '') if f >= 0 else (-f, '-')
n, d = f.as_integer_ratio() if isinstance(f, float) else (f, 1)
n, d = map(lambda x: bin(x)[2:], (n, d))
n = n.rjust(len(d), '0')
s = list(n)
s.insert(len(n) - len(d) + 1, '.')
return sign + '0b' + ''.join(s)
----------
components: Interpreter Core
messages: 67525
nosy: rhettinger
severity: normal
status: open
title: Let bin() show floats
type: feature request
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________
From report at bugs.python.org Fri May 30 14:13:53 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 30 May 2008 12:13:53 +0000
Subject: [New-bugs-announce] [issue3009] 3.0a5 tarballs contain the code
twice
In-Reply-To: <1212149632.97.0.414084166273.issue3009@psf.upfronthosting.co.za>
Message-ID: <1212149632.97.0.414084166273.issue3009@psf.upfronthosting.co.za>
New submission from Barry A. Warsaw <barry at python.org>:
As reported by Matthias Klose, the 3.0a5 tarball contains an extra py3k
ssubdir with the whole source included again. He says a4 was okay.
Check the release scripts before 3.0b1.
----------
assignee: barry
components: Installation
messages: 67530
nosy: barry
priority: release blocker
severity: normal
status: open
title: 3.0a5 tarballs contain the code twice
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3009>
_______________________________________
From report at bugs.python.org Fri May 30 15:56:57 2008
From: report at bugs.python.org (Diez B. Roggisch)
Date: Fri, 30 May 2008 13:56:57 +0000
Subject: [New-bugs-announce] [issue3010] Module cmd documentation enhancement
In-Reply-To: <1212155817.24.0.228459769095.issue3010@psf.upfronthosting.co.za>
Message-ID: <1212155817.24.0.228459769095.issue3010@psf.upfronthosting.co.za>
New submission from Diez B. Roggisch <deets at web.de>:
Please consider applying the attached patch - it should prevent some
confusion because the semantics of a passed stdin aren't clear otherwise.
----------
assignee: georg.brandl
components: Documentation
files: python2.5-libcmd.patch
keywords: patch
messages: 67534
nosy: deets, georg.brandl
severity: normal
status: open
title: Module cmd documentation enhancement
versions: Python 2.5
Added file: http://bugs.python.org/file10479/python2.5-libcmd.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3010>
_______________________________________
From report at bugs.python.org Fri May 30 22:43:51 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 30 May 2008 20:43:51 +0000
Subject: [New-bugs-announce] [issue3011] locale module alias table needs to
be updated
In-Reply-To: <1212180231.64.0.423770380897.issue3011@psf.upfronthosting.co.za>
Message-ID: <1212180231.64.0.423770380897.issue3011@psf.upfronthosting.co.za>
New submission from Marc-Andre Lemburg <mal at egenix.com>:
It's missing a lot of entries of the type "de_DE.utf at euro" and was last
updated in 2004.
----------
assignee: lemburg
components: Library (Lib)
messages: 67551
nosy: lemburg
severity: normal
status: open
title: locale module alias table needs to be updated
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3011>
_______________________________________
From report at bugs.python.org Fri May 30 23:33:52 2008
From: report at bugs.python.org (John Arbash Meinel)
Date: Fri, 30 May 2008 21:33:52 +0000
Subject: [New-bugs-announce] [issue3012] disutils fails with GNU ld (GNU
Binutils) 2.18.50.20080523
In-Reply-To: <1212183232.04.0.848357706047.issue3012@psf.upfronthosting.co.za>
Message-ID: <1212183232.04.0.848357706047.issue3012@psf.upfronthosting.co.za>
New submission from John Arbash Meinel <john at arbash-meinel.com>:
I just upgraded my cygwin installation to the latest versions. Which
seems to include
GNU ld (GNU Binutils) 2.18.50.20080523
and
GNU dllwrap (GNU Binutils) 2.18.50.20080523
It seems that their version notation is now Major.Minor.Micro.Date
The problem is that in 'cygwincompiler.py' it does:
result = re.search('(\d+\.\d+(\.\d+)*)',out_string)
if result:
ld_version = StrictVersion(result.group(1))
Which matches the full version string. However "StrictVersion" only
supports A.B.CdE formats. So the .Date breaks the parser.
My workaround was to change the regex to be:
result = re.search('(\d+\.\d+(\.\d+)?)(\.\d+)*',out_string)
So it will still match an unlimited number of '.DDD' as it used to, but
now it only preserves the first 3 to pass to StrictVersion.
This may not be the correct fix, as a better fix might be to use
something else instead of StrictVersion (since these version numbers
explicitly *don't* match what StrictVersion expects.)
----------
messages: 67556
nosy: jameinel
severity: normal
status: open
title: disutils fails with GNU ld (GNU Binutils) 2.18.50.20080523
type: compile error
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3012>
_______________________________________
From report at bugs.python.org Fri May 30 23:33:54 2008
From: report at bugs.python.org (John Arbash Meinel)
Date: Fri, 30 May 2008 21:33:54 +0000
Subject: [New-bugs-announce] [issue3013] disutils fails with GNU ld (GNU
Binutils) 2.18.50.20080523
In-Reply-To: <1212183234.85.0.030546530082.issue3013@psf.upfronthosting.co.za>
Message-ID: <1212183234.85.0.030546530082.issue3013@psf.upfronthosting.co.za>
New submission from John Arbash Meinel <john at arbash-meinel.com>:
I just upgraded my cygwin installation to the latest versions. Which
seems to include
GNU ld (GNU Binutils) 2.18.50.20080523
and
GNU dllwrap (GNU Binutils) 2.18.50.20080523
It seems that their version notation is now Major.Minor.Micro.Date
The problem is that in 'cygwincompiler.py' it does:
result = re.search('(\d+\.\d+(\.\d+)*)',out_string)
if result:
ld_version = StrictVersion(result.group(1))
Which matches the full version string. However "StrictVersion" only
supports A.B.CdE formats. So the .Date breaks the parser.
My workaround was to change the regex to be:
result = re.search('(\d+\.\d+(\.\d+)?)(\.\d+)*',out_string)
So it will still match an unlimited number of '.DDD' as it used to, but
now it only preserves the first 3 to pass to StrictVersion.
This may not be the correct fix, as a better fix might be to use
something else instead of StrictVersion (since these version numbers
explicitly *don't* match what StrictVersion expects.)
----------
messages: 67557
nosy: jameinel
severity: normal
status: open
title: disutils fails with GNU ld (GNU Binutils) 2.18.50.20080523
type: compile error
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3013>
_______________________________________
From report at bugs.python.org Fri May 30 23:54:11 2008
From: report at bugs.python.org (johansen)
Date: Fri, 30 May 2008 21:54:11 +0000
Subject: [New-bugs-announce] [issue3014] file_dealloc() assumes errno is set
when EOF is returned
In-Reply-To: <1212184451.2.0.27521352304.issue3014@psf.upfronthosting.co.za>
Message-ID: <1212184451.2.0.27521352304.issue3014@psf.upfronthosting.co.za>
New submission from johansen <johansen at sun.com>:
We're using Python to build the new packaging system for OpenSolaris.
Yesterday, a user reported that when they ran the pkg command, piped the
output to grep, and then typed ^C, sometimes they'd get this error:
$ pkg list | grep office
^Cclose failed: [Errno 11] Resource temporarily unavailable
We assumed that this might be a problem in the signal handling we've
employed to catch SIGPIPE; however, it turns out that the problem is in
the file_dealloc() code.
For the perversely curious, additional details may be found in the
original bug located here:
http://defect.opensolaris.org/bz/show_bug.cgi?id=2083
Essentially we found the following:
The error message is emitted from fileobject.c: file_dealloc()
The relevant portion of the routine looks like this:
static void
file_dealloc(PyFileObject *f)
{
int sts = 0;
if (f->weakreflist != NULL)
PyObject_ClearWeakRefs((PyObject *) f);
if (f->f_fp != NULL && f->f_close != NULL) {
Py_BEGIN_ALLOW_THREADS
sts = (*f->f_close)(f->f_fp);
Py_END_ALLOW_THREADS
if (sts == EOF)
#ifdef HAVE_STRERROR
PySys_WriteStderr("close failed: [Errno %d] %s\n",
errno, strerror(errno));
In the cases we encountered, the function pointer f_close is actually a
call to sysmodule.c: _check_and_flush()
That routine looks like this:
static int
_check_and_flush (FILE *stream)
{
int prev_fail = ferror (stream);
return fflush (stream) || prev_fail ? EOF : 0;
}
check_and_flush calls ferror(3C) and then fflush(3C) on the FILE stream
associated with the file object. There's just one problem here. If it
finds an error that was previously encountered on the file stream,
there's no guarantee that errno will be valid. Should an error be
encountered in fflush(3C), errno will get set; however, the contents of
errno are undefined should fflush() return successfully.
Here's what happens in the code I observed:
I set a write watchpoint on errno and observed the different times it
was accessed. After sifting through a bunch of red-herrings, I found
that a call to PyThread_acquire_lock() that sets errno to 11 (EAGAIN).
This occurs when PyThread_acquire_lock() calls sem_trywait(3C) and finds
the semaphore already locked. Errno doesn't get accessed again until a
call to libc.so.1`isseekable() that simply saves and restores the
existing errno.
Since we've taken a ^C (SIGINT), the interpreter begins the finalization
process and eventually calls file_dealloc(). This routine calls
_check_and_flush(). In the case that I observed, ferror(3C)
returns a non-zero value but fflush(3C) completes successfully. This
causes the routine to return EOF to the caller. file_dealloc() assumes
that since it received an EOF an error occurred and it should call
strerror(errno). However, since this is just returning the state of a
previous error, errno is invalid.
This is what causes the spurious EAGAIN message. Just to be sure, I
traced the return value and errno of failed syscalls that were invoked
by the interpreter. I was unable to observe any syscalls returning
EAGAIN. This is because (at least on OpenSolaris) sem_trywait(3C) calls
sema_trywait(3C). The sema_trywait returns EBUSY if the semaphore is
held and sem_trywait converts this to EAGAIN. None of these errors are
passed out of the kernel.
It's not clear to me whether _check_and_flush(), file_dealloc(), or both
need modification. At a minimum, it's not safe for file_dealloc() to
assume that errno is set correctly if the function underneath it is
using ferror(3C) to find the presence of an error on the stream.
----------
components: Interpreter Core
messages: 67560
nosy: johansen
severity: normal
status: open
title: file_dealloc() assumes errno is set when EOF is returned
type: behavior
versions: Python 2.4
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3014>
_______________________________________
From report at bugs.python.org Sat May 31 00:51:38 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 30 May 2008 22:51:38 +0000
Subject: [New-bugs-announce] [issue3015] tkinter with wantobjects=False has
been broken for some time
In-Reply-To: <1212187898.67.0.391803496997.issue3015@psf.upfronthosting.co.za>
Message-ID: <1212187898.67.0.391803496997.issue3015@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
This affects only py3k, but apparently tkinter has been in this
situation for more than 9 months now.
I see these lines at _tkinter.c:
const char *s = Tcl_GetStringResult(self->interp);
const char *p = s;
res = PyUnicode_FromStringAndSize(s, (int)(p-s));
and I was wondering how could res not end up being an empty string
always ? Then I did some quick tests here and the return is always an
empty string, when wantobjects is set to False. Maybe the second line
should be:
const char *p = strchr(s, '\0');
I've attached this correction. Not sure if it is the best way to solve
the problem.
----------
components: Tkinter
files: tkinter_wantobjects.diff
keywords: patch
messages: 67562
nosy: gpolo
severity: normal
status: open
title: tkinter with wantobjects=False has been broken for some time
versions: Python 3.0
Added file: http://bugs.python.org/file10482/tkinter_wantobjects.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3015>
_______________________________________
From report at bugs.python.org Sat May 31 00:54:54 2008
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Fri, 30 May 2008 22:54:54 +0000
Subject: [New-bugs-announce] [issue3016] tarfile.py incurs exception from
self.chmod() when tarball has g+s
In-Reply-To: <1212188094.34.0.115070485446.issue3016@psf.upfronthosting.co.za>
Message-ID: <1212188094.34.0.115070485446.issue3016@psf.upfronthosting.co.za>
New submission from Zooko O'Whielacronx <zooko at zooko.com>:
As reported at https://bugs.launchpad.net/pyopenssl/+bug/236190 ,
tarfile.py incurs an "Operation not permitted" exception (on Mac OS
10.4) when it tries to untar the pyOpenSSL-0.6.tar.gz tarball, because
that tarball has directories in it marked as having the "g+s" bit.
(Why this leads to an "Operation not permitted" exception, I don't know.)
----------
messages: 67563
nosy: zooko
severity: normal
status: open
title: tarfile.py incurs exception from self.chmod() when tarball has g+s
type: behavior
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3016>
_______________________________________
From report at bugs.python.org Sat May 31 14:29:28 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 31 May 2008 12:29:28 +0000
Subject: [New-bugs-announce] [issue3017] Verify doc updates for the decimal
module
In-Reply-To: <1212236968.69.0.449256777548.issue3017@psf.upfronthosting.co.za>
Message-ID: <1212236968.69.0.449256777548.issue3017@psf.upfronthosting.co.za>
New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:
Some of the doc updates were inaccurate. For instance, r58154 adds
documentation for a trim() method, but there is no such method in
decimal.py.
----------
assignee: facundobatista
components: Documentation
messages: 67576
nosy: facundobatista, rhettinger
priority: high
severity: normal
status: open
title: Verify doc updates for the decimal module
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3017>
_______________________________________
From report at bugs.python.org Sat May 31 15:49:20 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 31 May 2008 13:49:20 +0000
Subject: [New-bugs-announce] [issue3018] tkinter demos fixed
In-Reply-To: <1212241760.64.0.0978196091903.issue3018@psf.upfronthosting.co.za>
Message-ID: <1212241760.64.0.0978196091903.issue3018@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
I've fixed the tkinter demos at py3k. And excluding the import fixes,
most of these could be backported to python 2.x too.
----------
components: Tkinter
files: tkinter_demo_fixes.diff
keywords: patch
messages: 67579
nosy: gpolo
severity: normal
status: open
title: tkinter demos fixed
versions: Python 3.0
Added file: http://bugs.python.org/file10486/tkinter_demo_fixes.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3018>
_______________________________________
From report at bugs.python.org Sat May 31 20:32:50 2008
From: report at bugs.python.org (Florian Mayer)
Date: Sat, 31 May 2008 18:32:50 +0000
Subject: [New-bugs-announce] [issue3019] Python3a5 compile failing due to
high memory usage
In-Reply-To: <1212258770.12.0.665769337301.issue3019@psf.upfronthosting.co.za>
Message-ID: <1212258770.12.0.665769337301.issue3019@psf.upfronthosting.co.za>
New submission from Florian Mayer <flormayer at aim.com>:
I have tried building Python3a5 today using the tarball offered on your
internet site.
The process './python -E setup.py build' keeps on allocating my memory
using more than 80% of my RAM, I am certain that it would have used more
if I had not cancelled it.
When I use ltrace to track the system calls and put it into the
Makefile, the resource usage still raises but much slower, if I use
ltrace and supply it a PID, the memory usage raises as fast as normal. I
think this is due to something in ltrace, it's understandable because it
produced a file of more than 600MB.
I attached an excerpt of the output of ltrace, showing you how the
system calls seem to repeat, and the output of './configure', 'make',
'uname -a', 'lspci' and 'lsmod' so you have some data about my system.
I also got a screenshot showing the output of htop, make and strace
together: http://img516.imageshack.us/img516/2275/screenshot1ab8.png.
Maybe the output of two different programs(ltrace and strace) will help
you too.
I tried out building the current SVN py3k branch, resulting in a similar
problem.
PS: It would help if you allowed uploading of multiple files to bug reports
----------
components: Build
files: output
messages: 67585
nosy: segfaulthunter
severity: normal
status: open
title: Python3a5 compile failing due to high memory usage
type: compile error
versions: Python 3.0
Added file: http://bugs.python.org/file10488/output
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3019>
_______________________________________