From report at bugs.python.org Tue Jul 1 02:10:51 2008
From: report at bugs.python.org (vizcayno)
Date: Tue, 01 Jul 2008 00:10:51 +0000
Subject: [New-bugs-announce] [issue3247] dir of an "_sre.SRE_Match" object
not working
In-Reply-To: <1214871051.34.0.403559137594.issue3247@psf.upfronthosting.co.za>
Message-ID: <1214871051.34.0.403559137594.issue3247@psf.upfronthosting.co.za>
New submission from vizcayno <vizcaynot at gmail.com>:
For Windows XP SP3:
v = 'add 1 to 4.56'
import re
r=re.search("([0-9]+)\D+(\d+\.\d+)","add 1 to 4.56")
r
<_sre.SRE_Match object at 0x00BED920>
r.groups()
('1', '4.56')
dir(r)
[]
in pyhton 2.5 it shows:
['__copy__', '__deepcopy__', 'end', 'expand', 'group', 'groupdict', 'gro
ups', 'span', 'start']
----------
components: Regular Expressions
messages: 69031
nosy: vizcayno
severity: normal
status: open
title: dir of an "_sre.SRE_Match" object not working
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3247>
_______________________________________
From report at bugs.python.org Tue Jul 1 02:46:14 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 01 Jul 2008 00:46:14 +0000
Subject: [New-bugs-announce] [issue3248] ScrolledText can't be placed in a
PanedWindow
In-Reply-To: <1214873174.02.0.0621752990515.issue3248@psf.upfronthosting.co.za>
Message-ID: <1214873174.02.0.0621752990515.issue3248@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
Right now ScrolledText can't be added to a Tkinter.PanedWindow, also
can't be added to a ttk.Notebook (which is not part of the stdlib),
because it is a lacking a proper __str__ method.
Run the following sample code to check how it fails:
import Tkinter
import ScrolledText
paned = Tkinter.PanedWindow()
stext = ScrolledText.ScrolledText(paned)
paned.add(stext)
----------
components: Tkinter
files: scrolledtext_masterstr.diff
keywords: patch
messages: 69037
nosy: gpolo
severity: normal
status: open
title: ScrolledText can't be placed in a PanedWindow
versions: Python 2.6
Added file: http://bugs.python.org/file10787/scrolledtext_masterstr.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3248>
_______________________________________
From report at bugs.python.org Tue Jul 1 11:19:14 2008
From: report at bugs.python.org (Chris Withers)
Date: Tue, 01 Jul 2008 09:19:14 +0000
Subject: [New-bugs-announce] [issue3249] bug adding datetime.timedelta to
datetime.date
In-Reply-To: <1214903954.23.0.462888022865.issue3249@psf.upfronthosting.co.za>
Message-ID: <1214903954.23.0.462888022865.issue3249@psf.upfronthosting.co.za>
New submission from Chris Withers <chris at simplistix.co.uk>:
The following demonstrates the problem:
>>> from datetime import datetime,timedelta
>>> datetime.now().date()+timedelta(hours=1)
datetime.date(2008, 7, 1)
I'd expect the above to either result in a TypeError or (preferably)
datetime.datetime(2008, 7, 1, 1, 0)
----------
components: Library (Lib)
messages: 69041
nosy: cjw296
severity: normal
status: open
title: bug adding datetime.timedelta to datetime.date
versions: Python 2.4, Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3249>
_______________________________________
From report at bugs.python.org Tue Jul 1 11:49:00 2008
From: report at bugs.python.org (Chris Withers)
Date: Tue, 01 Jul 2008 09:49:00 +0000
Subject: [New-bugs-announce] [issue3250] datetime.time does not support
arithmetic
In-Reply-To: <1214905740.54.0.833672968887.issue3250@psf.upfronthosting.co.za>
Message-ID: <1214905740.54.0.833672968887.issue3250@psf.upfronthosting.co.za>
New submission from Chris Withers <chris at simplistix.co.uk>:
>>> from datetime import time
>>> time(9,0)-time(8,0)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for -: 'datetime.time' and
'datetime.time'
I'd expect a datetime.timedelta(0,3600)
----------
components: Library (Lib)
messages: 69042
nosy: cjw296
severity: normal
status: open
title: datetime.time does not support arithmetic
versions: Python 2.4, Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3250>
_______________________________________
From report at bugs.python.org Tue Jul 1 15:55:15 2008
From: report at bugs.python.org (Wolfgang Langner)
Date: Tue, 01 Jul 2008 13:55:15 +0000
Subject: [New-bugs-announce] [issue3251] references are case insensitive
In-Reply-To: <1214920515.1.0.0323158580641.issue3251@psf.upfronthosting.co.za>
Message-ID: <1214920515.1.0.0323158580641.issue3251@psf.upfronthosting.co.za>
New submission from Wolfgang Langner <tds333 at gmail.com>:
References can be added case sensitive as .. _myRef:
but only used case insensitive with :ref:`myref`
usage of :ref:`myRef` doesn't generate a working reference.
Make this behavior consistent please, always case insensitive or always
case sensitive.
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 69045
nosy: georg.brandl, tds333
severity: normal
status: open
title: references are case insensitive
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3251>
_______________________________________
From report at bugs.python.org Tue Jul 1 17:39:12 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 01 Jul 2008 15:39:12 +0000
Subject: [New-bugs-announce] [issue3252] str.tobytes() and
bytes/bytearray.tostr()
In-Reply-To: <1214926752.5.0.120483296731.issue3252@psf.upfronthosting.co.za>
Message-ID: <1214926752.5.0.120483296731.issue3252@psf.upfronthosting.co.za>
New submission from Mark Summerfield <mark at qtrac.eu>:
I know it is almost certainly too late, but I think a lot of people will
be confused by str.decode() and bytes.encode() (or was that the other
way around)?
Calling the methods str.tobytes() and bytes.tostr() (or nicer,
str.to_bytes() and bytes.to_str()) would be hard to confuse and IMO will
lead to fewer bug reports and complaints once Python 3.0 final comes out.
And there is a kind of precedent in that threading.isDaemon() became
threading.is_daemon() between 30a5 and 30b1.
----------
components: Interpreter Core
messages: 69047
nosy: mark
severity: normal
status: open
title: str.tobytes() and bytes/bytearray.tostr()
type: feature request
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3252>
_______________________________________
From report at bugs.python.org Tue Jul 1 19:35:09 2008
From: report at bugs.python.org (grissiom)
Date: Tue, 01 Jul 2008 17:35:09 +0000
Subject: [New-bugs-announce] [issue3253] shutil.move bahave unexpected in
fat32
In-Reply-To: <1214933709.34.0.0595495782723.issue3253@psf.upfronthosting.co.za>
Message-ID: <1214933709.34.0.0595495782723.issue3253@psf.upfronthosting.co.za>
New submission from grissiom <chaos.proton at gmail.com>:
Build the environment in a fat32 file system:
$echo test > test_move
$mkdir testmove
If I shutil.move('test_move', 'testmove'), it will raise:
Traceback (most recent call last):
File "testmove.py", line 5, in <module>
shutil.move('test_move', 'test_python')
File "/usr/lib/python2.5/shutil.py", line 199, in move
copy2(src,dst)
File "/usr/lib/python2.5/shutil.py", line 92, in copy2
copystat(src, dst)
File "/usr/lib/python2.5/shutil.py", line 69, in copystat
os.chmod(dst, mode)
OSError: [Errno 1] Operation not permitted: 'test_python/test_move'
If I shutil.move('test_move', 'testmove/testmove'), it will succeed
quietly. This problem doesn't happen in an ext3 file system.
----------
components: Library (Lib)
messages: 69053
nosy: grissiom
severity: normal
status: open
title: shutil.move bahave unexpected in fat32
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3253>
_______________________________________
From report at bugs.python.org Tue Jul 1 23:36:18 2008
From: report at bugs.python.org (cvp)
Date: Tue, 01 Jul 2008 21:36:18 +0000
Subject: [New-bugs-announce] [issue3254] Suggestion: change default behavior
of __ne__
In-Reply-To: <1214948178.75.0.219769334273.issue3254@psf.upfronthosting.co.za>
Message-ID: <1214948178.75.0.219769334273.issue3254@psf.upfronthosting.co.za>
New submission from cvp <cperepelitsa at gmail.com>:
After defining my own __eq__ method for a class that judged equality
based on a 'name' variable, imagine my surprise to see this:
In [20]: my_graph.edges[-1].end == my_graph.vertices[-1]
Out [20]: True
In [21]: my_graph.edges[-1].end != my_graph.vertices[-1]
Out [21]: True
...all because I forgot to modify __ne__ as well.
I think __ne__ should be changed to 'not __eq__' for the sake of
consistency.
----------
messages: 69078
nosy: cvp
severity: normal
status: open
title: Suggestion: change default behavior of __ne__
type: behavior
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3254>
_______________________________________
From report at bugs.python.org Wed Jul 2 10:43:13 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 02 Jul 2008 08:43:13 +0000
Subject: [New-bugs-announce] [issue3255] [proposal] alternative for re.sub
In-Reply-To: <1214988192.81.0.533532272888.issue3255@psf.upfronthosting.co.za>
Message-ID: <1214988192.81.0.533532272888.issue3255@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:
I often do same mistake again and again. Most of re module's method
takes optional argument "flags" like this.
finditer( pattern, string[, flags])
But, sub() takes optional argument "count" not "flags".
sub( pattern, repl, string[, count])
So, when I write this code, it doesn't behave like what I want.
re.sub("<[^>]+>", "", content, re.S)
I think it would be nice if the method which takes optional argument
"flags" and do same behavior with re.compile(pattern[, flags]).sub(repl,
string). Thank you.
----------
components: Regular Expressions
messages: 69087
nosy: ocean-city
severity: normal
status: open
title: [proposal] alternative for re.sub
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3255>
_______________________________________
From report at bugs.python.org Wed Jul 2 15:32:19 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Wed, 02 Jul 2008 13:32:19 +0000
Subject: [New-bugs-announce] [issue3256] Multiprocessing docs are not
3.0-ready
In-Reply-To: <1215005539.48.0.894176779867.issue3256@psf.upfronthosting.co.za>
Message-ID: <1215005539.48.0.894176779867.issue3256@psf.upfronthosting.co.za>
New submission from Andrii V. Mishkovskyi <mishok13 at gmail.com>:
Multiprocessing docs contain examples, that are not valid py3k code,
mostly because of print used as a statement. Example (taken from
multiprocessing.rst):
from multiprocessing import Process
def f(name):
print 'hello', name
if __name__ == '__main__':
p = Process(target=f, args=('bob',))
p.start()
p.join()
If no one is working on this already, than I'll start fixing this and
will present a patch in 2 or 3 days.
----------
assignee: georg.brandl
components: Documentation
messages: 69090
nosy: georg.brandl, jnoller, mishok13, roudkerk
severity: normal
status: open
title: Multiprocessing docs are not 3.0-ready
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3256>
_______________________________________
From report at bugs.python.org Wed Jul 2 16:42:43 2008
From: report at bugs.python.org (fgoujeon)
Date: Wed, 02 Jul 2008 14:42:43 +0000
Subject: [New-bugs-announce] [issue3257] "#define socklen_t int" in
pyconfig.h
In-Reply-To: <1215009763.56.0.986428726612.issue3257@psf.upfronthosting.co.za>
Message-ID: <1215009763.56.0.986428726612.issue3257@psf.upfronthosting.co.za>
New submission from fgoujeon <flog2 at wanadoo.fr>:
Hello all,
I'm using MinGW 4.2.1 and was unable to compile my code when including
pyconfig.h.
The culpables are these lines (from line 428):
/* Define to `int' if <sys/types.h> doesn't define. */
#if 1 //_MSC_VER + 0 >= 1300
/* VC.NET typedefs socklen_t in ws2tcpip.h. */
#else
#define socklen_t int
#endif
MinGW (at least the version I use) typedefs socklen_t too, in ws2tcpip.h
(at line 272):
typedef int socklen_t;
When the #define takes effect, code becomes:
typedef socklen_t socklen_t;
...which leads to a compile error (really hard to understand):
C:/MinGW/include/ws2tcpip.h:272: error: multiple types in one declaration
I hope these details will be useful for you. I'm available for another
questions.
Thanks!
----------
components: Library (Lib)
messages: 69097
nosy: fgoujeon
severity: normal
status: open
title: "#define socklen_t int" in pyconfig.h
type: compile error
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3257>
_______________________________________
From report at bugs.python.org Wed Jul 2 18:28:05 2008
From: report at bugs.python.org (Tim Golden)
Date: Wed, 02 Jul 2008 16:28:05 +0000
Subject: [New-bugs-announce] [issue3258] ctypes assertion failure in trunk
In-Reply-To: <1215016085.03.0.206242811608.issue3258@psf.upfronthosting.co.za>
Message-ID: <1215016085.03.0.206242811608.issue3258@psf.upfronthosting.co.za>
New submission from Tim Golden <mail at timgolden.me.uk>:
The following code raises an Assertion Failure under debug in r64518
running on Windows XP SP2:
<code>
import ctypes
class X (ctypes.Structure): pass
ctypes.POINTER (X)
</code>
Assertion failed: PyErr_Occurred(), file ..\Modules\_ctypes\_ctypes.c,
line 309
----------
assignee: theller
components: ctypes
messages: 69102
nosy: theller, tim.golden
severity: normal
status: open
title: ctypes assertion failure in trunk
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3258>
_______________________________________
From report at bugs.python.org Wed Jul 2 21:54:08 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 02 Jul 2008 19:54:08 +0000
Subject: [New-bugs-announce] [issue3259] fix_imports needs to be using the
'as' keyword
In-Reply-To: <1215028447.57.0.637458413942.issue3259@psf.upfronthosting.co.za>
Message-ID: <1215028447.57.0.637458413942.issue3259@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
If you run ``echo "import commands" | ./2to3 -f imports -``, you end up
with ``import subprocess``. That's bad as the code in the module works
off of 'commands'. The fix really should be ``import subprocess as
commands``.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 69113
nosy: brett.cannon, collinwinter
priority: critical
severity: normal
status: open
title: fix_imports needs to be using the 'as' keyword
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3259>
_______________________________________
From report at bugs.python.org Wed Jul 2 22:02:15 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 02 Jul 2008 20:02:15 +0000
Subject: [New-bugs-announce] [issue3260] fix_imports does not handle
intra-package renames
In-Reply-To: <1215028935.08.0.401449015598.issue3260@psf.upfronthosting.co.za>
Message-ID: <1215028935.08.0.401449015598.issue3260@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
``from test import test_support`` should lead to ``from test import
support as test_support``. Also does not work for ``from
test.test_support import Error``.
There is also no good way to handle ``import test.test_support`` since
``import test.test_support as test.support`` is an error. Perhaps
``import test.support; test.test_support = support``?
At the moment test.support is the only rename like this, so it is not
critical that this be fixed immediately as probably few people use the
module outside of the stdlib.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 69114
nosy: brett.cannon, collinwinter
priority: high
severity: normal
status: open
title: fix_imports does not handle intra-package renames
type: behavior
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3260>
_______________________________________
From report at bugs.python.org Wed Jul 2 22:06:54 2008
From: report at bugs.python.org (Leonardo Soto)
Date: Wed, 02 Jul 2008 20:06:54 +0000
Subject: [New-bugs-announce] [issue3261] Lib/test/test_cookielib declares
utf-8 encoding, but contains non-valid bytes
In-Reply-To: <1215029214.12.0.399957478898.issue3261@psf.upfronthosting.co.za>
Message-ID: <1215029214.12.0.399957478898.issue3261@psf.upfronthosting.co.za>
New submission from Leonardo Soto <leo.soto at gmail.com>:
http://svn.python.org/projects/python/branches/release25-maint/Lib/test/test_cookielib.py
contains non-utf8 bytes.
Currently, That confuses Jython.
----------
messages: 69115
nosy: leosoto
severity: normal
status: open
title: Lib/test/test_cookielib declares utf-8 encoding, but contains non-valid bytes
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3261>
_______________________________________
From report at bugs.python.org Thu Jul 3 00:07:49 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 02 Jul 2008 22:07:49 +0000
Subject: [New-bugs-announce] [issue3262] re.split doesn't split with
zero-width regex
In-Reply-To: <1215036469.9.0.581701421463.issue3262@psf.upfronthosting.co.za>
Message-ID: <1215036469.9.0.581701421463.issue3262@psf.upfronthosting.co.za>
New submission from Matthew Barnett <python at mrabarnett.plus.com>:
re.split doesn't split a string when the regex matches a zero characters.
For example:
re.split(r'\b', 'a b') returns ['a b'] instead of ['', 'a', ' ', 'b', ''].
re.split(r'(?<!\w)(?=\w)', 'a b') returns ['a b'] instead of ['', 'a ',
'b'].
----------
components: Regular Expressions
messages: 69134
nosy: mrabarnett
severity: normal
status: open
title: re.split doesn't split with zero-width regex
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3262>
_______________________________________
From report at bugs.python.org Thu Jul 3 01:06:54 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 02 Jul 2008 23:06:54 +0000
Subject: [New-bugs-announce] [issue3263] Odd code fragment in ABC definitions
In-Reply-To: <1215040014.35.0.00933223845259.issue3263@psf.upfronthosting.co.za>
Message-ID: <1215040014.35.0.00933223845259.issue3263@psf.upfronthosting.co.za>
New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:
In the Hashable ABC, there is a peculiar code fragment:
if "__hash__" in B.__dict__:
if B.__dict__["__hash__"]:
return True
break
When would the innermost if-statement ever be False? Is there a reason
to define __hash__ to be something that evaluates to False?
----------
assignee: gvanrossum
messages: 69140
nosy: gvanrossum, rhettinger
severity: normal
status: open
title: Odd code fragment in ABC definitions
versions: Python 2.5, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3263>
_______________________________________
From report at bugs.python.org Thu Jul 3 01:12:02 2008
From: report at bugs.python.org (Martin Mokrejs)
Date: Wed, 02 Jul 2008 23:12:02 +0000
Subject: [New-bugs-announce] [issue3264] Use -lcrypto instead of -lcrypt on
Solaris 2.6 when available
In-Reply-To: <1215040322.48.0.501787907219.issue3264@psf.upfronthosting.co.za>
Message-ID: <1215040322.48.0.501787907219.issue3264@psf.upfronthosting.co.za>
New submission from Martin Mokrejs <mmokrejs at users.sourceforge.net>:
Hi,
although the issues libraries to be created with -fpic are known I
still do believe ./config could do something here:
building 'crypt' extension
gcc -shared -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes
build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/cryptmodule.o
-L/usr/local/lib -lcrypt -o build/lib.solaris-2.6-sun4u-2.5/crypt.so
Text relocation remains referenced
against symbol offset in file
_des_setkey 0x4 /usr/lib/libcrypt.a(crypt.o)
_des_encrypt 0x10 /usr/lib/libcrypt.a(crypt.o)
_des_crypt 0x1c /usr/lib/libcrypt.a(crypt.o)
<unknown> 0x4
/usr/lib/libcrypt.a(des_crypt.o)
<unknown> 0x8
/usr/lib/libcrypt.a(des_crypt.o)
...
ld: fatal: relocations remain against allocatable but non-writable sections
collect2: ld returned 1 exit status
# gcc -shared -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes
build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/cryptmodule.o
-L/usr/local/lib -lcrypto -o build/lib.solaris-2.6-sun4u-2.5/crypt.so
#
----------
components: Build
messages: 69144
nosy: mmokrejs
severity: normal
status: open
title: Use -lcrypto instead of -lcrypt on Solaris 2.6 when available
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3264>
_______________________________________
From report at bugs.python.org Thu Jul 3 02:07:46 2008
From: report at bugs.python.org (Martin Mokrejs)
Date: Thu, 03 Jul 2008 00:07:46 +0000
Subject: [New-bugs-announce] [issue3265]
Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error:
`MAP_ANONYMOUS' undeclared
In-Reply-To: <1215043666.75.0.766151712273.issue3265@psf.upfronthosting.co.za>
Message-ID: <1215043666.75.0.766151712273.issue3265@psf.upfronthosting.co.za>
New submission from Martin Mokrejs <mmokrejs at users.sourceforge.net>:
Hi,
when building on Solaris 2.6 with gcc I get the following error:
building '_ctypes' extension
gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include
-Ibuild/temp.solaris-2.6-sun4u-2.5/libffi/include
-Ibuild/temp.solaris-2.6-sun4u-2.5/libffi
-I/usr/scratch/Python-2.5.2/Modules/_ctypes/libffi/src -I. -IInclude
-I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include
-I/usr/scratch/Python-2.5.2 -c
/usr/scratch/Python-2.5.2/Modules/_ctypes/_ctypes.c -o
build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/_ctypes.o
gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include
-Ibuild/temp.solaris-2.6-sun4u-2.5/libffi/include
-Ibuild/temp.solaris-2.6-sun4u-2.5/libffi
-I/usr/scratch/Python-2.5.2/Modules/_ctypes/libffi/src -I. -IInclude
-I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include
-I/usr/scratch/Python-2.5.2 -c
/usr/scratch/Python-2.5.2/Modules/_ctypes/callbacks.c -o
build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/callbacks.o
gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include
-Ibuild/temp.solaris-2.6-sun4u-2.5/libffi/include
-Ibuild/temp.solaris-2.6-sun4u-2.5/libffi
-I/usr/scratch/Python-2.5.2/Modules/_ctypes/libffi/src -I. -IInclude
-I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include
-I/usr/scratch/Python-2.5.2 -c
/usr/scratch/Python-2.5.2/Modules/_ctypes/callproc.c -o
build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/callproc.o
/usr/scratch/Python-2.5.2/Modules/_ctypes/callproc.c: In function
`_CallProc':
/usr/scratch/Python-2.5.2/Modules/_ctypes/callproc.c:921: warning:
implicit declaration of function `alloca'
gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include
-Ibuild/temp.solaris-2.6-sun4u-2.5/libffi/include
-Ibuild/temp.solaris-2.6-sun4u-2.5/libffi
-I/usr/scratch/Python-2.5.2/Modules/_ctypes/libffi/src -I. -IInclude
-I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include
-I/usr/scratch/Python-2.5.2 -c
/usr/scratch/Python-2.5.2/Modules/_ctypes/stgdict.c -o
build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/stgdict.o
gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include
-Ibuild/temp.solaris-2.6-sun4u-2.5/libffi/include
-Ibuild/temp.solaris-2.6-sun4u-2.5/libffi
-I/usr/scratch/Python-2.5.2/Modules/_ctypes/libffi/src -I. -IInclude
-I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include
-I/usr/scratch/Python-2.5.2 -c
/usr/scratch/Python-2.5.2/Modules/_ctypes/cfield.c -o
build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/cfield.o
gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include
-Ibuild/temp.solaris-2.6-sun4u-2.5/libffi/include
-Ibuild/temp.solaris-2.6-sun4u-2.5/libffi
-I/usr/scratch/Python-2.5.2/Modules/_ctypes/libffi/src -I. -IInclude
-I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include
-I/usr/scratch/Python-2.5.2 -c
/usr/scratch/Python-2.5.2/Modules/_ctypes/malloc_closure.c -o
build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/malloc_closure.o
/usr/scratch/Python-2.5.2/Modules/_ctypes/malloc_closure.c: In function
`more_core':
/usr/scratch/Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error:
`MAP_ANONYMOUS' undeclared (first use in this function)
/usr/scratch/Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error:
(Each undeclared identifier is reported only once
/usr/scratch/Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error:
for each function it appears in.)
building '_ctypes_test' extension
gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include -I.
-IInclude -I./Include -I/usr/local/include
-I/usr/scratch/Python-2.5.2/Include -I/usr/scratch/Python-2.5.2 -c
/usr/scratch/Python-2.5.2/Modules/_ctypes/_ctypes_test.c -o
build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/_ctypes_test.o
gcc -shared -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes
build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/_ctypes_test.o
-L/usr/local/lib -o build/lib.solaris-2.6-sun4u-2.5/_ctypes_test.so
Let me add that I see -fPIC in the top-level Makefile but do not know
why -static is not in the same variable as well. Anyway, it is not
a shared library problem I think as I already recompiled my bzip2,
openssl and ncurses libs with "-shared -fpic". ;-)
----------
messages: 69152
nosy: mmokrejs
severity: normal
status: open
title: Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error: `MAP_ANONYMOUS' undeclared
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3265>
_______________________________________
From report at bugs.python.org Thu Jul 3 02:14:14 2008
From: report at bugs.python.org (Martin Mokrejs)
Date: Thu, 03 Jul 2008 00:14:14 +0000
Subject: [New-bugs-announce] [issue3266]
Python-2.5.2/Modules/mmapmodule.c:915: error: `O_RDWR' undeclared
In-Reply-To: <1215044054.48.0.722645405249.issue3266@psf.upfronthosting.co.za>
Message-ID: <1215044054.48.0.722645405249.issue3266@psf.upfronthosting.co.za>
New submission from Martin Mokrejs <mmokrejs at users.sourceforge.net>:
Some typo in the sources showing up on Solaris 2.6 only?
building 'mmap' extension
gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include -I.
-IInclude -I./Include -I/usr/local/include
-I/usr/scratch/Python-2.5.2/Include -I/usr/scratch/Python-2.5.2 -c
/usr/scratch/Python-2.5.2/Modules/mmapmodule.c -o
build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/mmapmodule.o
/usr/scratch/Python-2.5.2/Modules/mmapmodule.c: In function
`new_mmap_object':
/usr/scratch/Python-2.5.2/Modules/mmapmodule.c:915: warning: implicit
declaration of function `open'
/usr/scratch/Python-2.5.2/Modules/mmapmodule.c:915: error: `O_RDWR'
undeclared (first use in this function)
/usr/scratch/Python-2.5.2/Modules/mmapmodule.c:915: error: (Each
undeclared identifier is reported only once
/usr/scratch/Python-2.5.2/Modules/mmapmodule.c:915: error: for each
function it appears in.)
----------
components: Build
messages: 69153
nosy: mmokrejs
severity: normal
status: open
title: Python-2.5.2/Modules/mmapmodule.c:915: error: `O_RDWR' undeclared
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3266>
_______________________________________
From report at bugs.python.org Thu Jul 3 08:28:19 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Thu, 03 Jul 2008 06:28:19 +0000
Subject: [New-bugs-announce] [issue3267] yield in list comprehensions
possibly broken in 3.0
In-Reply-To: <1215066499.8.0.630576860475.issue3267@psf.upfronthosting.co.za>
Message-ID: <1215066499.8.0.630576860475.issue3267@psf.upfronthosting.co.za>
New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:
This may be a known consequence of python 3.0, but I couldn't find any
reference to it, nor a test case that covers it. Here's a valid use of yield
in 2.5.1:
>>> def foo():
... x=[(yield x) for x in 1,2,3]
... yield 5
... yield x
>>> x=foo()
>>> x.next()
1
>>> x.send(6)
2
>>> x.send(7)
3
>>> x.send(8)
5
>>> x.send(9)
[6, 7, 8]
>>> x.send(10)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
StopIteration
But in python 3.0, this code results in:
>>> def foo():
... x=[(yield x) for x in (1,2,3)]
... yield 5
... yield x
>>> x=foo()
>>> next(x)
5
>>> x.send(6)
<generator object <listcomp> at 0x3678f0>
>>> x.send(7)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
StopIteration
Looking further, it seems that this is a comprehension:
>>> def foo(): [(yield 5)]
>>> type(foo())
<class 'generator'>
Whereas this is not:
>>> def foo(): [(yield 5) for x in range(3)]
>>> type(foo())
<class 'NoneType'>
Is this expected behavior?
----------
components: Interpreter Core
messages: 69168
nosy: erickt
severity: normal
status: open
title: yield in list comprehensions possibly broken in 3.0
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3267>
_______________________________________
From report at bugs.python.org Thu Jul 3 08:31:39 2008
From: report at bugs.python.org (Adam Olsen)
Date: Thu, 03 Jul 2008 06:31:39 +0000
Subject: [New-bugs-announce] [issue3268] Cleanup of tp_basicsize inheritance
In-Reply-To: <1215066698.99.0.380668265624.issue3268@psf.upfronthosting.co.za>
Message-ID: <1215066698.99.0.380668265624.issue3268@psf.upfronthosting.co.za>
New submission from Adam Olsen <rhamph at gmail.com>:
inherit_special contains logic to inherit the base type's tp_basicsize
if the new type doesn't have it set. The logic was spread over several
lines, but actually does almost nothing (presumably an artifact of
previous versions), so here's a patch to clean it up.
There was also an incorrect comment which I've removed. A new one
should perhaps be added explaining what the other code there does, but
it's not affected by what I'm changing, and I'm not sure why it's doing
what it's doing anyway, so I'll leave that to someone else.
----------
files: python-inheritsize.diff
keywords: patch
messages: 69169
nosy: Rhamphoryncus, nnorwitz
severity: normal
status: open
title: Cleanup of tp_basicsize inheritance
Added file: http://bugs.python.org/file10798/python-inheritsize.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3268>
_______________________________________
From report at bugs.python.org Thu Jul 3 13:47:36 2008
From: report at bugs.python.org (=?utf-8?q?Neven_Gor=C5=A1i=C4=87?=)
Date: Thu, 03 Jul 2008 11:47:36 +0000
Subject: [New-bugs-announce] [issue3269] strptime() makes an error
concerning second in arg
In-Reply-To: <1215085656.87.0.45612671084.issue3269@psf.upfronthosting.co.za>
Message-ID: <1215085656.87.0.45612671084.issue3269@psf.upfronthosting.co.za>
New submission from Neven Gor?i? <neven.gorsic at gmail.com>:
strptime() allows 60 and 61 sec, but not 62 sec in arg. string
>>> s='02/28/2000 12:33:61 AM'
>>> time.strptime(s,'%m/%d/%Y %I:%M:%S %p')
(2000, 2, 28, 0, 33, 61, 0, 59, -1)
>>> s='02/28/2000 12:33:62 AM'
>>> time.strptime(s,'%m/%d/%Y %I:%M:%S %p')
Traceback (most recent call last):
File "<pyshell#12>", line 1, in <module>
time.strptime(s,'%m/%d/%Y %I:%M:%S %p')
File "C:\Python25\lib\_strptime.py", line 330, in strptime
(data_string, format))
ValueError: time data did not match format: data=02/28/2000 12:33:62 AM
fmt=%m/%d/%Y %I:%M:%S %p
----------
components: None
messages: 69192
nosy: nevgor
severity: normal
status: open
title: strptime() makes an error concerning second in arg
type: compile error
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3269>
_______________________________________
From report at bugs.python.org Thu Jul 3 14:58:44 2008
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 03 Jul 2008 12:58:44 +0000
Subject: [New-bugs-announce] [issue3270] test_multiprocessing:
test_listener_client flakiness
In-Reply-To: <1215089924.76.0.76828097682.issue3270@psf.upfronthosting.co.za>
Message-ID: <1215089924.76.0.76828097682.issue3270@psf.upfronthosting.co.za>
New submission from Jesse Noller <jnoller at gmail.com>:
Per mail thread:
http://mail.python.org/pipermail/python-dev/2008-June/080497.html
Attached is the patch to connection.py to drop the fqdn call.
Final suggestion from Trent:
> This is a common problem. Binding to '127.0.0.1' will bind to *only*
> that address;
Indeed.
> binding to "" will bind to *all* addresses the machine
> is known by.
Agreed again. I believe what we're dealing with here though is a lack
of clarity regarding what role the 'address' attribute exposed by
multiprocess.connection.Listener should play. The way
test_listener_client() is written, it effectively treats 'address' as an
end-point that can be connected to directly (irrespective of the
underlying family (i.e. AF_INET, AF_UNIX, AF_PIPE)).
I believe the problems we've run into stem from the fact that the API
doesn't provide any guarantees as to what 'address' represents. The
test suite assumes it always reflects a connectable end-point, which I
think is more than reasonable. Unfortunately, nothing stops us from
breaking this invariant by constructing the object as
Listener(family='AF_INET', address=('0.0.0.0', 0)).
How do I connect to an AF_INET Listener (i.e. SocketListener) instance
whose 'address' attribute reports '0.0.0.0' as the host? I can't.
So, for now, I think we should enforce this invariant by raising an
exception in Listener.__init__() if self._socket.getsockbyname()[0]
returns '0.0.0.0'. In effect, tightening up the API such that we can
guarantee Listener.address will always represent a connectable end-
point. We can look at how to service 'listen on all available
interfaces' semantics at a later date -- that adds far less value IMO
than being able to depend on the said guarantee.
----------
assignee: jnoller
components: Library (Lib)
files: connection.patch
keywords: patch
messages: 69197
nosy: jnoller, roudkerk
priority: high
severity: normal
status: open
title: test_multiprocessing: test_listener_client flakiness
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10801/connection.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3270>
_______________________________________
From report at bugs.python.org Thu Jul 3 17:10:00 2008
From: report at bugs.python.org (vizcayno)
Date: Thu, 03 Jul 2008 15:10:00 +0000
Subject: [New-bugs-announce] [issue3271] iter.next() or iter.__next__() ?
In-Reply-To: <1215097800.56.0.268941545187.issue3271@psf.upfronthosting.co.za>
Message-ID: <1215097800.56.0.268941545187.issue3271@psf.upfronthosting.co.za>
New submission from vizcayno <vizcaynot at gmail.com>:
For Win XP SP3 I do next in py30.b1:
a=[9,8,1,2]
it=iter(a)
it.next()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'list_iterator' object has no attribute 'next'
but doing:
it.__next__()
9
it.__next__()
8
it is ok.
However, manual of Py3.0 indicates iter.next() as valid.
Python 25 does not accept "it.__next__()" but "it.next()"
Regards.
----------
assignee: georg.brandl
components: Documentation
messages: 69205
nosy: georg.brandl, vizcayno
severity: normal
status: open
title: iter.next() or iter.__next__() ?
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3271>
_______________________________________
From report at bugs.python.org Thu Jul 3 18:48:38 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Thu, 03 Jul 2008 16:48:38 +0000
Subject: [New-bugs-announce] [issue3272] Multiprocessing hangs when
multiprocessing.Pool methods are called
In-Reply-To: <1215103718.59.0.127699249536.issue3272@psf.upfronthosting.co.za>
Message-ID: <1215103718.59.0.127699249536.issue3272@psf.upfronthosting.co.za>
New submission from Andrii V. Mishkovskyi <mishok13 at gmail.com>:
`multiprocessing` hangs, when `multiprocessing.Pool` methods `map`,
`imap`, `imap_unordered`, `apply`, `apply_async`, `map_async` are called.
Here is an example:
Python 3.0b1+ (py3k:64686M, Jul 3 2008, 13:06:13)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from multiprocessing import Pool
>>> Pool(processes=4).imap(lambda x: x, range(10))
<multiprocessing.pool.IMapIterator object at 0x83bcc8c>
>>> Pool(processes=4).map(lambda x: x, range(10))
Exception in thread Thread-13:
Traceback (most recent call last):
File "/usr/local/lib/python3.0/threading.py", line 492, in
_bootstrap_inner
self.run()
File "/usr/local/lib/python3.0/threading.py", line 447, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/lib/python3.0/multiprocessing/pool.py", line 225, in
_handle_tasks
put(task)
File "/usr/local/lib/python3.0/pickle.py", line 1319, in dumps
Pickler(f, protocol).dump(obj)
File "/usr/local/lib/python3.0/multiprocessing/util.py", line 311, in
_reduce_method
if m.__self__ is None:
AttributeError: 'function' object has no attribute '__self__'
Process PoolWorker-28:
Traceback (most recent call last):
File "/usr/local/lib/python3.0/multiprocessing/process.py", line 232,
in _bootstrap
self.run()
File "/usr/local/lib/python3.0/multiprocessing/process.py", line 88,
in run
self._target(*self._args, **self._kwargs)
File "/usr/local/lib/python3.0/multiprocessing/pool.py", line 57, in
worker
task = get()
File "/usr/local/lib/python3.0/multiprocessing/queues.py", line 337,
in get
Process PoolWorker-27:
Traceback (most recent call last):
File "/usr/local/lib/python3.0/multiprocessing/process.py", line 232,
in _bootstrap
self.run()
File "/usr/local/lib/python3.0/multiprocessing/process.py", line 88,
in run
self._target(*self._args, **self._kwargs)
File "/usr/local/lib/python3.0/multiprocessing/pool.py", line 57, in
worker
task = get()
File "/usr/local/lib/python3.0/multiprocessing/queues.py", line 337,
in get
Process PoolWorker-26:
Traceback (most recent call last):
File "/usr/local/lib/python3.0/multiprocessing/process.py", line 232,
in _bootstrap
Process PoolWorker-25:
Traceback (most recent call last):
File "/usr/local/lib/python3.0/multiprocessing/process.py", line 232,
in _bootstrap
self.run()
File "/usr/local/lib/python3.0/multiprocessing/process.py", line 88,
in run
self._target(*self._args, **self._kwargs)
File "/usr/local/lib/python3.0/multiprocessing/pool.py", line 57, in
worker
task = get()
File "/usr/local/lib/python3.0/multiprocessing/queues.py", line 337,
in get
self.run()
File "/usr/local/lib/python3.0/multiprocessing/process.py", line 88,
in run
self._target(*self._args, **self._kwargs)
File "/usr/local/lib/python3.0/multiprocessing/pool.py", line 57, in
worker
task = get()
File "/usr/local/lib/python3.0/multiprocessing/queues.py", line 339,
in get
return recv()
KeyboardInterrupt
racquire()
KeyboardInterrupt
racquire()
KeyboardInterrupt
racquire()
KeyboardInterrupt
Terminated
The same happens on latest trunk of Python 2.6.
Note, `map` and `apply` methods hang Python interpreter completely, so I
have to use `kill` utility to exit Python.
----------
components: Library (Lib)
messages: 69207
nosy: jnoller, mishok13, roudkerk
severity: normal
status: open
title: Multiprocessing hangs when multiprocessing.Pool methods are called
type: crash
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3272>
_______________________________________
From report at bugs.python.org Thu Jul 3 19:03:29 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Thu, 03 Jul 2008 17:03:29 +0000
Subject: [New-bugs-announce] [issue3273] multiprocessing and meaningful
errors
In-Reply-To: <1215104608.98.0.798137013067.issue3273@psf.upfronthosting.co.za>
Message-ID: <1215104608.98.0.798137013067.issue3273@psf.upfronthosting.co.za>
New submission from Andrii V. Mishkovskyi <mishok13 at gmail.com>:
multiprocessing uses a lot of `assert` statements all over the code. I
propose to change this way to a more readable and understandable. For
example:
Lib/multiprocessing/managers.py, line 136:
assert isinstance(authkey, bytes)
>From my point of view, raising an AssertionError is not enough in this
case. I propose changing this one to more intuitive:
if not isinstance(authkey, bytes):
raise TypeError("'authkey' argument should be an instance of 'bytes'")
(Well, maybe message could be more descriptive. :) )
And this goes for all of the multiprocessing code base.
Should I consider writing a patch for this?
----------
components: Library (Lib)
messages: 69208
nosy: jnoller, mishok13, roudkerk
severity: normal
status: open
title: multiprocessing and meaningful errors
type: feature request
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3273>
_______________________________________
From report at bugs.python.org Thu Jul 3 19:54:09 2008
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 03 Jul 2008 17:54:09 +0000
Subject: [New-bugs-announce] [issue3274] Py_CLEAR(tmp) seg faults
In-Reply-To: <1215107649.04.0.488182300536.issue3274@psf.upfronthosting.co.za>
Message-ID: <1215107649.04.0.488182300536.issue3274@psf.upfronthosting.co.za>
New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:
I'm writing a C extension module and discovered that Py_CLEAR() causes a
crash if the programmer happened to name their variable "tmp". The
Py_CLEAR() macro internally uses the name "tmp" in a new scope, hiding
the callers "tmp", and calling Py_DECREF() on an essentially random bit
of memory.
I suggest changing Py_CLEAR() to use something a little less common than
"tmp". Perhaps "_py_tmp".
For easy reference, here's how Py_CLEAR() is defined now:
#define Py_CLEAR(op) \
do { \
if (op) { \
PyObject *tmp = (PyObject *)(op); \
(op) = NULL; \
Py_DECREF(tmp); \
} \
} while (0)
----------
components: Interpreter Core
messages: 69213
nosy: stutzbach
severity: normal
status: open
title: Py_CLEAR(tmp) seg faults
type: crash
versions: Python 2.5, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3274>
_______________________________________
From report at bugs.python.org Thu Jul 3 22:43:13 2008
From: report at bugs.python.org (Daniel Colascione)
Date: Thu, 03 Jul 2008 20:43:13 +0000
Subject: [New-bugs-announce] [issue3275] Control flow not optimized
In-Reply-To: <1215117793.84.0.876575778362.issue3275@psf.upfronthosting.co.za>
Message-ID: <1215117793.84.0.876575778362.issue3275@psf.upfronthosting.co.za>
New submission from Daniel Colascione <dan.colascione at gmail.com>:
Consider:
import dis
def foo():
if 0 and 1: return "hi"
dis.dis(foo)
What I get is
2 0 LOAD_CONST 1 (0)
3 JUMP_IF_FALSE 15 (to 21)
6 POP_TOP
7 LOAD_CONST 2 (1)
10 JUMP_IF_FALSE 8 (to 21)
13 POP_TOP
14 LOAD_CONST 3 ('hi')
17 RETURN_VALUE
18 JUMP_FORWARD 1 (to 22)
>> 21 POP_TOP
>> 22 LOAD_CONST 0 (None)
25 RETURN_VALUE
What I'd expect to see is:
1 0 LOAD_CONST 0 (None)
3 RETURN_VALUE
----------
components: Interpreter Core
messages: 69230
nosy: quotemstr
severity: normal
status: open
title: Control flow not optimized
type: performance
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3275>
_______________________________________
From report at bugs.python.org Fri Jul 4 02:19:29 2008
From: report at bugs.python.org (toxik)
Date: Fri, 04 Jul 2008 00:19:29 +0000
Subject: [New-bugs-announce] [issue3276]
httplib.HTTPConnection._send_request should not blindly
assume dicts for headers
In-Reply-To: <1215130769.47.0.0230905543783.issue3276@psf.upfronthosting.co.za>
Message-ID: <1215130769.47.0.0230905543783.issue3276@psf.upfronthosting.co.za>
New submission from toxik <ludvig.ericson at users.sourceforge.net>:
Presently it's impossible to use httplib.HTTPConnection.request and send
the several headers with the same name. This is because _send_request
assumes a dict is passed in, or a dict-like interface. Obviously one could
make a list subclass or some such and give it an iteritems that returns
itself, but IMHO the solution is to fix httplib.
Attached patch changes the current behavior to using iteritems only if it
exists, otherwise iterate directly (which would fit with sequences of two-
tuples).
----------
components: Library (Lib)
files: httplib.py.diff
keywords: patch
messages: 69234
nosy: ludvig.ericson
severity: normal
status: open
title: httplib.HTTPConnection._send_request should not blindly assume dicts for headers
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
Added file: http://bugs.python.org/file10807/httplib.py.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3276>
_______________________________________
From report at bugs.python.org Fri Jul 4 03:51:20 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 04 Jul 2008 01:51:20 +0000
Subject: [New-bugs-announce] [issue3277] socket's OOB data management is
broken on FreeBSD
In-Reply-To: <1215136280.08.0.736342433953.issue3277@psf.upfronthosting.co.za>
Message-ID: <1215136280.08.0.736342433953.issue3277@psf.upfronthosting.co.za>
New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:
I've tried to run the code below on Windows XP and Linux Ubuntu and it
works as expected. Here is the output:
expt -> o
read -> fo
On FreeBSD 7.0 it raises the following exception:
expt -> o
read -> fo
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/local/lib/python2.5/threading.py", line 460, in __bootstrap
self.run()
File "/usr/local/lib/python2.5/threading.py", line 440, in run
self.__target(*self.__args, **self.__kwargs)
File "_test2.py", line 13, in server
data = conn.recv(1024, socket.MSG_OOB)
error: (22, 'Invalid argument')
--- code ---
import socket, select, threading, time, os
def server():
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind(('', 1024))
s.listen(1)
conn, addr = s.accept()
conn.setblocking(0)
while 1:
r, w, e = select.select([conn], [conn], [conn], 0.01)
if e:
data = conn.recv(1024, socket.MSG_OOB)
print "expt -> " + data
if r:
data = conn.recv(1024)
print "read -> " + data
threading.Thread(target=server).start()
time.sleep(0.1)
s = socket.socket()
s.connect(('127.0.0.1', 1024))
s.sendall('foo', socket.MSG_OOB)
--- /code ---
----------
messages: 69236
nosy: giampaolo.rodola
severity: normal
status: open
title: socket's OOB data management is broken on FreeBSD
versions: Python 2.5, Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3277>
_______________________________________
From report at bugs.python.org Fri Jul 4 04:18:01 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 04 Jul 2008 02:18:01 +0000
Subject: [New-bugs-announce] [issue3278] socket's SO_REUSEADDR option does
not work on FreeBSD
In-Reply-To: <1215137881.67.0.331390936209.issue3278@psf.upfronthosting.co.za>
Message-ID: <1215137881.67.0.331390936209.issue3278@psf.upfronthosting.co.za>
New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:
When the SO_OOBINLINE option is used against a socket, out-of-band data
should be placed in the normal data input stream as it is received.
In fact this is what happens on Windows and Linux by using the script below.
On FreeBSD this does not happen. select instead of returning a
"readable" file descriptor returns an "exceptional" file descriptor.
Later, when we try to read some data from the socket, the following
exception is raised:
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/local/lib/python2.5/threading.py", line 460, in __bootstrap
self.run()
File "/usr/local/lib/python2.5/threading.py", line 440, in run
self.__target(*self.__args, **self.__kwargs)
File "_test2.py", line 14, in server
data = conn.recv(1024, socket.MSG_OOB)
error: (22, 'Invalid argument')
--- code ---
import socket, select, threading, time, os
def server():
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind(('', 1024))
s.listen(1)
conn, addr = s.accept()
conn.setblocking(0)
conn.setsockopt(socket.SOL_SOCKET, socket.SO_OOBINLINE, 1)
while 1:
r, w, e = select.select([conn], [conn], [conn], 0.01)
if r:
# the socket is supposed to be in the "readable" list
data = conn.recv(1024)
print "read -> " + data
if e:
# ...but not in the "exception" list
data = conn.recv(1024, socket.MSG_OOB)
print "expt -> " + data
threading.Thread(target=server).start()
time.sleep(0.1)
s = socket.socket()
s.connect(('127.0.0.1', 1024))
s.sendall('x', socket.MSG_OOB)
--- /code ---
----------
components: Library (Lib)
messages: 69237
nosy: giampaolo.rodola
severity: normal
status: open
title: socket's SO_REUSEADDR option does not work on FreeBSD
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3278>
_______________________________________
From report at bugs.python.org Fri Jul 4 05:40:27 2008
From: report at bugs.python.org (Roger Upole)
Date: Fri, 04 Jul 2008 03:40:27 +0000
Subject: [New-bugs-announce] [issue3279] import of site.py fails on startup
In-Reply-To: <1215142827.44.0.225986561599.issue3279@psf.upfronthosting.co.za>
Message-ID: <1215142827.44.0.225986561599.issue3279@psf.upfronthosting.co.za>
New submission from Roger Upole <rupole at hotmail.com>:
In pythonrun.c, initstdio injects 'open' into builtins. However,
initsite is called before initstdio and site.py uses open.
Running with -v, this traceback is printed:
Traceback (most recent call last):
File "j:\python30\lib\site.py", line 518, in <module>
main()
File "j:\python30\lib\site.py", line 501, in main
known_paths = addsitepackages(known_paths)
File "j:\python30\lib\site.py", line 281, in addsitepackages
addsitedir(sitedir, known_paths)
File "j:\python30\lib\site.py", line 178, in addsitedir
addpackage(sitedir, name, known_paths)
File "j:\python30\lib\site.py", line 141, in addpackage
f = open(fullname, "rU")
NameError: global name 'open' is not defined
----------
messages: 69240
nosy: rupole
severity: normal
status: open
title: import of site.py fails on startup
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3279>
_______________________________________
From report at bugs.python.org Fri Jul 4 11:02:04 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 04 Jul 2008 09:02:04 +0000
Subject: [New-bugs-announce] [issue3280] %c format does not accept large
numbers on ucs-2 builds
In-Reply-To: <1215162124.14.0.169970018317.issue3280@psf.upfronthosting.co.za>
Message-ID: <1215162124.14.0.169970018317.issue3280@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:
Since python3.0, chr(0x2f81a) works even on narrow Unicode builds, but
>>> "%c" % 0x2f81a
OverflowError: %c arg not in range(0x10000) (narrow Python build)
Likewise, Py_BuildValue("C") should accept codes outside the BMP.
----------
components: Unicode
messages: 69247
nosy: amaury.forgeotdarc
severity: normal
status: open
title: %c format does not accept large numbers on ucs-2 builds
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3280>
_______________________________________
From report at bugs.python.org Fri Jul 4 13:00:31 2008
From: report at bugs.python.org (LI Daobing)
Date: Fri, 04 Jul 2008 11:00:31 +0000
Subject: [New-bugs-announce] [issue3281] support r"\"
In-Reply-To: <1215169231.64.0.700296369871.issue3281@psf.upfronthosting.co.za>
Message-ID: <1215169231.64.0.700296369871.issue3281@psf.upfronthosting.co.za>
New submission from LI Daobing <lidaobing at gmail.com>:
currently r"\" or r'\' is not a valid string literal and it is already
documented.
but this exception is not simple enough, it make users confused when
they found that r'C:\Program\Python\' does not work as expected.
please consider support this, thanks.
----------
components: None
messages: 69249
nosy: lidaobing
severity: normal
status: open
title: support r"\"
type: feature request
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3281>
_______________________________________
From report at bugs.python.org Fri Jul 4 15:30:06 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 04 Jul 2008 13:30:06 +0000
Subject: [New-bugs-announce] [issue3282] Undefined unicode characters should
be non-printable
In-Reply-To: <1215178206.2.0.370394116016.issue3282@psf.upfronthosting.co.za>
Message-ID: <1215178206.2.0.370394116016.issue3282@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:
str.isprintable() returns True for undefined unicode code points:
>>> c = "\ufffe"
>>> unicodedata.category(c)
'Cn' # (Other, Not Assigned)
>>> c.isprintable()
True
Same for "\u0242", "\ufb12"...
The cause is probably in unicodectype.c: _PyUnicode_IsPrintable():
return (ctype->flags & NONPRINTABLE_MASK) == 0;
but ctype->flags is 0 for undefined chars.
----------
components: Unicode
messages: 69254
nosy: amaury.forgeotdarc
severity: normal
status: open
title: Undefined unicode characters should be non-printable
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3282>
_______________________________________
From report at bugs.python.org Fri Jul 4 15:45:11 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Fri, 04 Jul 2008 13:45:11 +0000
Subject: [New-bugs-announce] [issue3283] multiprocessing.connection doesn't
import AuthenticationError, while using it
In-Reply-To: <1215179111.5.0.100147287247.issue3283@psf.upfronthosting.co.za>
Message-ID: <1215179111.5.0.100147287247.issue3283@psf.upfronthosting.co.za>
New submission from Andrii V. Mishkovskyi <mishok13 at gmail.com>:
Lib/multiprocessing/connection.py contains two uses of
AuthenticationError, while it's not imported from multiprocessing
package. This exception is used in deliver_challenge() and
answer_challenge() functions. I've attached a small patch that fixes
possible NameError while calling any of these two functions.
----------
components: Library (Lib)
files: multiprocessing.connection.py.diff
keywords: patch
messages: 69255
nosy: jnoller, mishok13, roudkerk
severity: normal
status: open
title: multiprocessing.connection doesn't import AuthenticationError, while using it
versions: Python 3.0
Added file: http://bugs.python.org/file10809/multiprocessing.connection.py.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3283>
_______________________________________
From report at bugs.python.org Fri Jul 4 21:26:09 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Jul 2008 19:26:09 +0000
Subject: [New-bugs-announce] [issue3284] Delete obsolete 'Unicode' in Py3
str docstrings; related fixes
In-Reply-To: <1215199569.07.0.941434192746.issue3284@psf.upfronthosting.co.za>
Message-ID: <1215199569.07.0.941434192746.issue3284@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
In 3.0b1, several str methods have 'Unicode' in their docstrings
leftover from 2.x when str *was* unicode.
For
center
count
ljust
rjust
translate
'Unicode' should be deleted before 'string'.
For 'translate', I presume 'Unicode ordinal' should be left as is as was
done for 'maketrans'.
For
lstrip
rstrip
strip
"If chars is a str, it will be converted to unicode before stripping"
should be deleted. Bytes (which replace old str) and bytearrays are not
automatically converted.
Other fixes
For
maketrans
the word 'then' should be removed from 'will then be' in the fourth line
since it only confuses. The conversion is the first and only thing done
in the one-argument case.
For
lstrip
rstrip
strip
remove ', Unicode' from
"TypeError: <x>strip arg must be None, unicode or str"
For
ljust
rjust
"TypeError: The fill character cannot be converted to Unicode"
should be changed to
TypeError: The fill character cannot be implicitly converted to str"
or even, copying from several other method error messages
TypeError: Can't convert 'bytes' object to str implicitly"
or perhaps best would be
"TypeError: For the fill char, can't convert 'bytes' object to str
implicitly"
The other methods taking str args seem to have been updated already.
----------
assignee: georg.brandl
components: Documentation
keywords: easy
messages: 69263
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Delete obsolete 'Unicode' in Py3 str docstrings; related fixes
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3284>
_______________________________________
From report at bugs.python.org Fri Jul 4 21:36:27 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 04 Jul 2008 19:36:27 +0000
Subject: [New-bugs-announce] [issue3285] Fraction.from_any()
In-Reply-To: <1215200187.54.0.0352827858842.issue3285@psf.upfronthosting.co.za>
Message-ID: <1215200187.54.0.0352827858842.issue3285@psf.upfronthosting.co.za>
New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:
After exercising the fractions module, I've found it problematic that
there isn't a unified constructor to handle mixed data input types.
For example, when updating the accurate summation recipe at
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/393090 to show
how it could be done with rational arithmetic. Handling mixed-type
inputs required writing a factory function:
def makefrac(x):
if isinstance(x, Decimal):
return Fraction.from_decimal(x)
if isinstance(x, float):
return Fraction.from_float(x)
return Fraction(x)
That function supported a clean version of the recipe:
def frsum(iterable):
return float(sum(map(makefrac, iterable)))
It would have been much better if that functionality were built into
the class definition. See attached patch.
----------
components: Library (Lib)
files: from_any.diff
keywords: patch
messages: 69264
nosy: rhettinger
severity: normal
status: open
title: Fraction.from_any()
type: feature request
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10810/from_any.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3285>
_______________________________________
From report at bugs.python.org Fri Jul 4 21:45:25 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Jul 2008 19:45:25 +0000
Subject: [New-bugs-announce] [issue3286] IDLE opens window too low on Windows
In-Reply-To: <1215200725.85.0.436129810041.issue3286@psf.upfronthosting.co.za>
Message-ID: <1215200725.85.0.436129810041.issue3286@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
On my Windows XP system, IDLE opens windows too low, even the first, so
that the bottom is behind the task bar. When I move the window up,
close, and reopen, it occasionally remembers the position but usually
forgets. Always remembering would be nicer.
It also seems to me that the default should at least be centered, but
preferably even higher since new windows are cascaded down.
Or Configure/General could have an initial position for first window
entry just below or above the initial size.
----------
components: IDLE
messages: 69265
nosy: tjreedy
severity: normal
status: open
title: IDLE opens window too low on Windows
type: behavior
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3286>
_______________________________________
From report at bugs.python.org Fri Jul 4 21:57:23 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 04 Jul 2008 19:57:23 +0000
Subject: [New-bugs-announce] [issue3287] Fraction constructor should raise
TypeError instead of AttributeError
In-Reply-To: <1215201443.11.0.460100125282.issue3287@psf.upfronthosting.co.za>
Message-ID: <1215201443.11.0.460100125282.issue3287@psf.upfronthosting.co.za>
New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:
>>> from fractions import *
>>> Fraction(3.1)
Traceback (most recent call last):
File "<pyshell#14>", line 1, in <module>
Fraction(3.1)
File "C:\Python26\lib\fractions.py", line 100, in __new__
numerator = numerator.__index__()
AttributeError: 'float' object has no attribute '__index__'
----------
assignee: jyasskin
components: Library (Lib)
messages: 69267
nosy: jyasskin, rhettinger
severity: normal
status: open
title: Fraction constructor should raise TypeError instead of AttributeError
type: behavior
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3287>
_______________________________________
From report at bugs.python.org Sat Jul 5 12:41:18 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 05 Jul 2008 10:41:18 +0000
Subject: [New-bugs-announce] [issue3288] float.as_integer_ratio method is
not documented
In-Reply-To: <1215254478.03.0.190528446429.issue3288@psf.upfronthosting.co.za>
Message-ID: <1215254478.03.0.190528446429.issue3288@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
The float.as_integer_ratio method needs to be documented somewhere other
than whatsnew/2.6.rst.
----------
assignee: georg.brandl
components: Documentation
messages: 69277
nosy: georg.brandl, marketdickinson
severity: normal
status: open
title: float.as_integer_ratio method is not documented
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3288>
_______________________________________
From report at bugs.python.org Sat Jul 5 18:13:29 2008
From: report at bugs.python.org (Jon Nelson)
Date: Sat, 05 Jul 2008 16:13:29 +0000
Subject: [New-bugs-announce] [issue3289] unnecessary call to time and
localtime slows time.mktime
In-Reply-To: <1215274409.55.0.482276845315.issue3289@psf.upfronthosting.co.za>
Message-ID: <1215274409.55.0.482276845315.issue3289@psf.upfronthosting.co.za>
New submission from Jon Nelson <jnelson+python at jamponi.net>:
Basically, time.mktime calls time and localtime, and then overwrites
those results. Removing these unnecessary calls results in a fairly
noticeable speedup, lower double-digit percentile improvements for
applications that do time parsing, for example.
The patch below is for 2.5, but should apply to more recent versions.
diff --git a/Modules/timemodule.c b/Modules/timemodule.c
index be02ec2..dad235a 100644
--- a/Modules/timemodule.c
+++ b/Modules/timemodule.c
@@ -599,8 +599,6 @@ time_mktime(PyObject *self, PyObject *tup)
{
struct tm buf;
time_t tt;
- tt = time(&tt);
- buf = *localtime(&tt);
if (!gettmarg(tup, &buf))
return NULL;
tt = mktime(&buf);
----------
components: Extension Modules
messages: 69283
nosy: nother_jnelson
severity: normal
status: open
title: unnecessary call to time and localtime slows time.mktime
type: performance
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3289>
_______________________________________
From report at bugs.python.org Sat Jul 5 21:09:07 2008
From: report at bugs.python.org (Sacha Varma)
Date: Sat, 05 Jul 2008 19:09:07 +0000
Subject: [New-bugs-announce] [issue3290] python-config --cflags includes
irrelevant flags
In-Reply-To: <1215284947.23.0.370691849564.issue3290@psf.upfronthosting.co.za>
Message-ID: <1215284947.23.0.370691849564.issue3290@psf.upfronthosting.co.za>
New submission from Sacha Varma <sacha-python at ssl.co.uk>:
As I understand it, python-config --cflags is intended to yield the C
compiler flags needed to compile a program that uses Python headers and
libraries (as opposed to the C flags needed to compile python itself).
However, it seems to include irrelevant options such as -Wall and -O3,
which interfere with the build (for example, by enabling optimisation in
a debug build):
$ python-config --cflags
-I/opt/Python-2.5.1/include/python2.5
-I/opt/Python-2.5.1/include/python2.5 -fno-strict-aliasing
-Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes
----------
components: Build
messages: 69289
nosy: sacha
severity: normal
status: open
title: python-config --cflags includes irrelevant flags
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3290>
_______________________________________
From report at bugs.python.org Sat Jul 5 22:29:43 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Jul 2008 20:29:43 +0000
Subject: [New-bugs-announce] [issue3291] rlcompleter doesn't work anymore
In-Reply-To: <1215289783.17.0.918141616629.issue3291@psf.upfronthosting.co.za>
Message-ID: <1215289783.17.0.918141616629.issue3291@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
In the latest py3k versions, rlcompleter doesn't work anymore. Pressing
the tab key (with tab-completion enabled) doesn't produce anything on
screen.
----------
components: Library (Lib)
messages: 69293
nosy: pitrou
severity: normal
status: open
title: rlcompleter doesn't work anymore
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3291>
_______________________________________
From report at bugs.python.org Sat Jul 5 23:37:34 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Jul 2008 21:37:34 +0000
Subject: [New-bugs-announce] [issue3292] Position index limit;
s.insert(i,x) not same as s[i:i]=[x]
In-Reply-To: <1215293854.95.0.622305572735.issue3292@psf.upfronthosting.co.za>
Message-ID: <1215293854.95.0.622305572735.issue3292@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
Suggested changes to Lib Ref Manual: Sequence Types --...(3.6 for 2.5)
(These are mostly based on an issue posted on c.l.p. The Plone
Archetypes package (which I know nothing of) was reported as suggesting
that users pass sys.maxint, to indicate 'insert at end', to one of their
functions that uses .insert. A user with an AMD64 did that ... and I
could not find doc proof that the crash was not a Python bug.)
Main section:
Before the operation list, change "n, i and j are integers:" to "n, i,
j, and k are integers:"
After the above, add "An implementation may limit the range of position
indexes (some uses of i below)." I do not know if this limitation,
actual for CPython is documented elsewhere, but it should be here. In
particular, i is used as both position and slice index.
Consider using i only as a magnitude-limited position index (an
'index-sized integer' as one error message puts it) and j,k,l for
unlimited slice and other integers. This would slightly change the
suggestions above and entail replacements in the table here and in
following subsections.
Mutable Sequence Types
In 3.0, .count and .index are general sequence methods and should be
moved up to that section. (For .index, parameters i & j are not
(limited) position indexes but simply integers for comparison. The
notation change suggested above would make this clear without one having
to experiment or infer from the comparison rule.)
The line "s.insert(i, x) same as s[i:i] = [x]" is not true when i is
outside the range of allow position indexes. If i is not defined as a
limited range integer (and the implementation not changed ;-) add a
footnote "only when i is within the range of allowed position indexes."
Is there a policy on documenting possible operation-specific exceptions?
I consider them part of the interface. Or should I bring this up on pydev?
For 3.0, footnotes 3 and 7 (in this subsection) document 2, for 4
different operations. Here are a couple more related to this issue.
In the main section, for s[i]:
2.x IndexError: cannot fit 'long' into an index-sized integer
3.0 IndexError: cannot fit 'int' into an index-sized integer
In the subsection, for s.insert(i,x):
2.x OverflowError: long int too large to convert to int
3.0 OverflowError: Python int too large to convert to C ssize_t
I actually think the OverflowError should be changed to IndexError since
the problem is the same in both cases, but that is a different issue.
----------
assignee: georg.brandl
components: Documentation
messages: 69302
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Position index limit; s.insert(i,x) not same as s[i:i]=[x]
versions: Python 2.5, Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3292>
_______________________________________
From report at bugs.python.org Sun Jul 6 00:05:03 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Jul 2008 22:05:03 +0000
Subject: [New-bugs-announce] [issue3293] incorrect comments for
PyObject_ReleaseBuffer
In-Reply-To: <1215295503.07.0.531699971785.issue3293@psf.upfronthosting.co.za>
Message-ID: <1215295503.07.0.531699971785.issue3293@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
The declaration for PyObject_ReleaseBuffer (in Include/abstract.h) has
the following comments attached to it. But the part about the return
value is wrong since the function is defined as returning void. Also,
PEP 3118 says it always succeeds so it can't return an error code.
By the way, may I suggest that having the buffer API declared in
abstract.h but the Py_buffer struct declared in object.h (and why not in
bufferobject.h?) is slightly confusing.
/* C-API version of the releasebuffer function call. It
checks to make sure the object has the required function
pointer and issues the call. The obj must have the buffer
interface or this function will cause a segfault (i.e. it
is assumed to be called only after a corresponding
getbuffer which already verified the existence of the
tp_as_buffer pointer).
Returns 0 on success and -1 (with an error raised) on
failure. This function always succeeds (as a NO-OP) if
there is no releasebuffer function for the object so that
it can always be called when the consumer is done with the
buffer
*/
----------
components: Interpreter Core
messages: 69303
nosy: pitrou
severity: normal
status: open
title: incorrect comments for PyObject_ReleaseBuffer
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3293>
_______________________________________
From report at bugs.python.org Sun Jul 6 00:27:06 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Jul 2008 22:27:06 +0000
Subject: [New-bugs-announce] [issue3294] SVN repository contains an
incorrect symbolic link
In-Reply-To: <1215296826.02.0.0693304727833.issue3294@psf.upfronthosting.co.za>
Message-ID: <1215296826.02.0.0693304727833.issue3294@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
In the py3k SVN branch I can see the following link. I suppose it is a
mistake?
$ ls -la Mac/IDLE/IDLE.app/Contents/MacOS/Python
lrwxrwxrwx 1 antoine antoine 92 2008-07-01 22:33
Mac/IDLE/IDLE.app/Contents/MacOS/Python ->
/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python
----------
components: Build, Macintosh
messages: 69305
nosy: pitrou
severity: normal
status: open
title: SVN repository contains an incorrect symbolic link
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3294>
_______________________________________
From report at bugs.python.org Sun Jul 6 00:29:39 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Jul 2008 22:29:39 +0000
Subject: [New-bugs-announce] [issue3295] PyExc_BufferError is declared but
nowhere defined
In-Reply-To: <1215296979.37.0.223488731028.issue3295@psf.upfronthosting.co.za>
Message-ID: <1215296979.37.0.223488731028.issue3295@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
Astonishingly, PyExc_BufferError is defined in pyerrors.h but it is
defined nowhere. Consequently, any piece of code raising a
PyExc_BufferError will cause the interpreter to crash as soon as it
tries to do something with the exception...
----------
components: Interpreter Core
messages: 69306
nosy: pitrou
severity: normal
status: open
title: PyExc_BufferError is declared but nowhere defined
type: crash
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3295>
_______________________________________
From report at bugs.python.org Sun Jul 6 01:31:08 2008
From: report at bugs.python.org (Florian Mayer)
Date: Sat, 05 Jul 2008 23:31:08 +0000
Subject: [New-bugs-announce] [issue3296] print function not executed in
python 3.0 tutorial
In-Reply-To: <1215300668.3.0.525831221198.issue3296@psf.upfronthosting.co.za>
Message-ID: <1215300668.3.0.525831221198.issue3296@psf.upfronthosting.co.za>
New submission from Florian Mayer <flormayer at aim.com>:
It is for sure only a minor issue, but the new tutorial should not
confuse readers as the print function is not executed here and does not
do anything at all. Patch is attached.
----------
assignee: georg.brandl
components: Documentation
files: doc-patch
messages: 69311
nosy: georg.brandl, segfaulthunter
severity: normal
status: open
title: print function not executed in python 3.0 tutorial
versions: Python 3.0
Added file: http://bugs.python.org/file10824/doc-patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3296>
_______________________________________
From report at bugs.python.org Sun Jul 6 08:58:44 2008
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 06 Jul 2008 06:58:44 +0000
Subject: [New-bugs-announce] [issue3297] Python interpreter uses Unicode
surrogate pairs only before the pyc is created
In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
Message-ID: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
New submission from Ezio Melotti <ezio.melotti at gmail.com>:
Problem: when you have Unicode characters with a code point greater than
U+FFFF written directly in the source file (that is, not in the form
u'\Uxxxxxxxx' but as normal chars in a u'' string) the interpreter uses
surrogate pairs for representing these characters only if the pyc
doesn't exist. When the pyc is created it uses a "normal" character
(\Uxxxxxxxx instead of the pair \uxxxx\uxxxx). This could lead to an
unexpected behavior while comparing Unicode strings or in other
situations (even if it could be solved without problems in different
ways - using u'\Uxxxxxxx' or u'\uxxx' instead of the characters,
encoding them before comparing - there shouldn't be differences between
a py and its pyc).
Tested on:
Ubuntu 8.04 with python 2.4: Uses a surrogate pair.
Ubuntu 8.04 with python 2.5: Uses a surrogate pair.
Windows XP SP2 with python 2.4: Uses a "normal" character.
Steps to reproduce the problem:
1a. download the attached file or create it following the next step;
1b. in a UTF-8-aware console write `print
unichr(int('10123', 16))` (or any codepoint >= 10000), copy the printed
character (depending on the console it could be a box, two box or a
character) in a file with the lines `# -*- coding: utf-8 -*-`, `print
'Result:', u'<paste here the char>' == u'\U00010123'` and `print
'Repr:', repr(u'<paste here the char>'), repr(u'\U00010123')`. Save the
file in UTF-8;
2. open a python interpreter and import the file (`import
unicodetest`). It should print `Result: False` and `Repr:
u'\ud800\udd23' u'\U00010123'` (the character is represented as a
surrogate pair). During this step the pyc file is created.
3. from the python interpreter write `reload(unicodetest)`. Now it
should print `Result: True` and `Repr: u'\U00010123' u'\U00010123'` (the
char is represented as a "normal" character). Any other reload will
print True. If you delete the pyc and reload again it will print False.
(Instead of using reload() is also possible to create a function and
call it from the module when it's loaded and again with
unicodetest.func(), the result will be the same.)
Expected behavior:
The interpreter should use the same representation in both the situation
(and print True in both the tests).
Another solution could be to change the behavior of == to return True if
a normal char is compared with its surrogate pair (if it makes sense).
Further informations:
The character used for the test is part of the "Unicode Plane 1" (see
http://en.wikipedia.org/wiki/Basic_Multilingual_Plane).
More information about the surrogate pairs can be found here:
http://en.wikipedia.org/wiki/Surrogate_pair#Encoding_of_characters_outside_the_BMP
----------
components: Unicode
files: unicodetest.py
messages: 69321
nosy: ezio.melotti, lemburg
severity: normal
status: open
title: Python interpreter uses Unicode surrogate pairs only before the pyc is created
type: behavior
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file10826/unicodetest.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3297>
_______________________________________
From report at bugs.python.org Sun Jul 6 15:09:49 2008
From: report at bugs.python.org (Stavros Korokithakis)
Date: Sun, 06 Jul 2008 13:09:49 +0000
Subject: [New-bugs-announce] [issue3298] Multiline string with quotes is not
parsed correctly.
In-Reply-To: <1215349788.94.0.987157911353.issue3298@psf.upfronthosting.co.za>
Message-ID: <1215349788.94.0.987157911353.issue3298@psf.upfronthosting.co.za>
New submission from Stavros Korokithakis <stavros at korokithakis.net>:
A multiline string with quotes next to the ending quote is not parsed
correctly:
In [1]: """A "test""""
------------------------------------------------------------
File "<ipython console>", line 1
"""A "test""""
^
<type 'exceptions.SyntaxError'>: EOL while scanning single-quoted string
Is this normal behaviour? It seems to me like the parser should parse
everything inside the triple double quotes (there is no ambiguity).
----------
components: Interpreter Core
messages: 69326
nosy: Stavros
severity: normal
status: open
title: Multiline string with quotes is not parsed correctly.
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3298>
_______________________________________
From report at bugs.python.org Sun Jul 6 16:20:44 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jul 2008 14:20:44 +0000
Subject: [New-bugs-announce] [issue3299] invalid object destruction in
re.finditer()
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
New submission from STINNER Victor <haypo at users.sourceforge.net>:
"import re: re.finditer("a", {})" crash on Python 2.x (tested with svn
trunk) because of an invalid use of PyObject_NEW/PyObject_DEL. The
error is in pattern_scanner(), in block "if (!string) { ... }".
- scanner_dealloc() calls Py_DECREF(self->pattern); whereas pattern
attribute is not initialized
- scanner_dealloc() calls PyObject_DEL(self); whereas
scanner_dealloc() is already the destructor of self object!
I wrote a patch to fix these errors. Please review my patch, I don't
know C API very well.
I also patched _compile(): replace PyObject_DEL() by Py_DECREF(). Is
it really needed?
----------
components: Library (Lib)
files: re_finditer.patch
keywords: patch
messages: 69331
nosy: haypo
severity: normal
status: open
title: invalid object destruction in re.finditer()
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file10828/re_finditer.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________
From report at bugs.python.org Sun Jul 6 16:52:10 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 06 Jul 2008 14:52:10 +0000
Subject: [New-bugs-announce] [issue3300] urllib.quote and unquote - Unicode
issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
New submission from Matt Giuca <matt.giuca at gmail.com>:
Three Unicode-related problems with urllib.parse.quote and
urllib.parse.unquote in Python 3.0. (Patch attached).
Firstly, unquote appears not to have been modified from Python 2, where
it is designed to output a byte string. In Python 3, it outputs a
unicode string, implicitly decoded as ISO-8859-1 (the code points are
the same as the bytes). RFC 3986 states that the percent-encoded byte
values should be decoded as UTF-8.
http://tools.ietf.org/html/rfc3986 section 2.5.
Current behaviour:
>>> urllib.parse.unquote("%CE%A3")
'??'
(or '\u00ce\u00a3')
Desired behaviour:
>>> urllib.parse.unquote("%CE%A3")
'?'
(or '\u03a3')
Secondly, while quote *has* been modified to encode to UTF-8 before
percent-encoding, it does not work correctly for characters in
range(128, 256), due to a special case in the code which again treats
the code point values as byte values.
Current behaviour:
>>> urllib.parse.quote('\u00e9')
'%E9'
Desired behaviour:
>>> urllib.parse.quote('\u00e9')
'%C3%A9'
Note that currently, quoting characters less than 256 will use
ISO-8859-1, while quoting characters 256 or higher will use UTF-8!
Thirdly, the "safe" argument to quote does not work for characters above
256, since these are excluded from the special case. I thought I would
fix this at the same time, but it's really a separate issue.
Current behaviour:
>>> urllib.parse.quote('??', safe='?')
'%CE%A3%CF%B0'
Desired behaviour:
>>> urllib.parse.quote('??', safe='?')
'?%CF%B0'
A patch which fixes all three issues is attached. Note that unquote now
needs to handle the case where the UTF-8 sequence is invalid. This is
currently handled by "replace" (invalid sequences are replaced by
'\ufffd'). I would like to add an optional "errors" argument to unquote,
defaulting to "replace", to allow the user to override this behaviour,
but I didn't put that in because it would change the interface.
Note I also changed one of the test cases, which had the wrong expected
output. (String literal was manually UTF-8 encoded, designed for Python
2; nonsensical when viewed as a Python 3 Unicode string).
All urllib test cases pass.
Patch is for branch /branches/py3k, revision 64752.
Note: The above unquote issue also manifests itself in Python 2 for
Unicode strings, but it's hazy as to what the behaviour should be, and
would break existing programs, so I'm just patching the Py3k branch.
Commit log:
urllib.parse.unquote: Fixed percent-encoded octets being implicitly
decoded as ISO-8859-1; now decode as UTF-8, as per RFC 3986.
urllib.parse.quote: Fixed characters in range(128, 256) being implicitly
encoded as ISO-8859-1; now encode as UTF-8. Also fixed characters
greater than 256 not responding to "safe", and also not being cached.
Lib/test/test_urllib.py: Updated one test case for unquote which
expected the wrong output. The new version of unquote passes the new
test case.
----------
components: Library (Lib)
files: parse.py.patch
keywords: patch
messages: 69333
nosy: mgiuca
severity: normal
status: open
title: urllib.quote and unquote - Unicode issues
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file10829/parse.py.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________
From report at bugs.python.org Sun Jul 6 17:12:30 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jul 2008 15:12:30 +0000
Subject: [New-bugs-announce] [issue3301] DoS when lo is negative in
bisect.insort_right() / _left()
In-Reply-To: <1215357141.61.0.853561189902.issue3301@psf.upfronthosting.co.za>
Message-ID: <1215357141.61.0.853561189902.issue3301@psf.upfronthosting.co.za>
New submission from STINNER Victor <haypo at users.sourceforge.net>:
"import bisect; bisect.insort(range(4), -1, -1)" goes into an
unlimited loop. Workaround: replace negative lo value by zero. The
function may raise an exception.
----------
components: Library (Lib)
files: bisect_lo.patch
keywords: patch
messages: 69334
nosy: haypo
severity: normal
status: open
title: DoS when lo is negative in bisect.insort_right() / _left()
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file10830/bisect_lo.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3301>
_______________________________________
From report at bugs.python.org Sun Jul 6 17:46:48 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jul 2008 15:46:48 +0000
Subject: [New-bugs-announce] [issue3302] segfault on gettext(None)
In-Reply-To: <1215359208.89.0.118295330664.issue3302@psf.upfronthosting.co.za>
Message-ID: <1215359208.89.0.118295330664.issue3302@psf.upfronthosting.co.za>
New submission from STINNER Victor <haypo at users.sourceforge.net>:
msgid of gettext(), dgettext(), dcgettext() C functions can not be
NULL (domainname can be NULL): "import locale; locale.gettext(None)"
generates a segfault.
domainname argument of bindtextdomain() have to be a non empty
string: "locale.bindtextdomain(NULL, NULL)" or
locale.bindtextdomain('', NULL)" generates an OSError(0).
Attached patch fixes the two bugs.
----------
components: Extension Modules
files: locale_none.patch
keywords: patch
messages: 69335
nosy: haypo
severity: normal
status: open
title: segfault on gettext(None)
versions: Python 2.6
Added file: http://bugs.python.org/file10831/locale_none.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3302>
_______________________________________
From report at bugs.python.org Sun Jul 6 18:06:10 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jul 2008 16:06:10 +0000
Subject: [New-bugs-announce] [issue3303] invalid ref count on
locale.strcoll() error
In-Reply-To: <1215360370.12.0.415668125666.issue3303@psf.upfronthosting.co.za>
Message-ID: <1215360370.12.0.415668125666.issue3303@psf.upfronthosting.co.za>
New submission from STINNER Victor <haypo at users.sourceforge.net>:
If locale.strcoll(a, b) fails because PyUnicode_FromObject(b) fails,
refcount of a is wrong. Attached patch fixes the problem.
----------
components: Library (Lib)
files: locale_strcoll_rel1.patch
keywords: patch
messages: 69336
nosy: haypo
severity: normal
status: open
title: invalid ref count on locale.strcoll() error
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file10832/locale_strcoll_rel1.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3303>
_______________________________________
From report at bugs.python.org Sun Jul 6 18:30:22 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jul 2008 16:30:22 +0000
Subject: [New-bugs-announce] [issue3304] invalid call to PyMem_Free() in
fileio_init()
In-Reply-To: <1215361822.52.0.122745729251.issue3304@psf.upfronthosting.co.za>
Message-ID: <1215361822.52.0.122745729251.issue3304@psf.upfronthosting.co.za>
New submission from STINNER Victor <haypo at users.sourceforge.net>:
fileio_init() calls PyMem_Free(name); whereas name comes from
PyArg_ParseTupleAndKeywords().
Attached patch removes this invalid call.
The bug may also affect Python3.0.
----------
components: Library (Lib)
files: fileio_pymem_free.patch
keywords: patch
messages: 69338
nosy: haypo
severity: normal
status: open
title: invalid call to PyMem_Free() in fileio_init()
versions: Python 2.6
Added file: http://bugs.python.org/file10833/fileio_pymem_free.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3304>
_______________________________________
From report at bugs.python.org Sun Jul 6 20:27:40 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jul 2008 18:27:40 +0000
Subject: [New-bugs-announce] [issue3305] Use Py_XDECREF() instead of
Py_DECREF() in MultibyteCodec and MultibyteStreamReader
In-Reply-To: <1215368860.06.0.0616450486424.issue3305@psf.upfronthosting.co.za>
Message-ID: <1215368860.06.0.0616450486424.issue3305@psf.upfronthosting.co.za>
New submission from STINNER Victor <haypo at users.sourceforge.net>:
Functions mbstreamwriter_dealloc() and mbstreamreader_dealloc() of
Modules/cjkcodecs/multibytecodec.c uses Py_DECREF() to free stream
attribute memory, but this attribute may be NULL if MultibyteCodec or
MultibyteStreamReader constructor fails.
Simple fix: use Py_XDECREF().
Example:
>>> import _multibytecodec
>>> _multibytecodec.MultibyteStreamReader(None)
Erreur de segmentation (core dumped)
----------
components: Library (Lib)
files: multibytecodec_py_xdecref.patch
keywords: patch
messages: 69347
nosy: haypo
severity: normal
status: open
title: Use Py_XDECREF() instead of Py_DECREF() in MultibyteCodec and MultibyteStreamReader
versions: Python 2.6
Added file: http://bugs.python.org/file10834/multibytecodec_py_xdecref.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3305>
_______________________________________
From report at bugs.python.org Sun Jul 6 23:57:59 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jul 2008 21:57:59 +0000
Subject: [New-bugs-announce] [issue3306] audioop.findmax() crashs with
negative length
In-Reply-To: <1215381479.48.0.0542422679202.issue3306@psf.upfronthosting.co.za>
Message-ID: <1215381479.48.0.0542422679202.issue3306@psf.upfronthosting.co.za>
New submission from STINNER Victor <haypo at users.sourceforge.net>:
Example:
>>> import audioop
>>> audioop.findmax(''.join( chr(x) for x in xrange(256)), -2392392)
Erreur de segmentation (core dumped)
The problem is that audioop_findmax() doesn't check len2 for negative
value. Here is a patch ;-)
----------
components: Library (Lib)
files: audioop_findmax.patch
keywords: patch
messages: 69356
nosy: haypo
severity: normal
status: open
title: audioop.findmax() crashs with negative length
versions: Python 2.6
Added file: http://bugs.python.org/file10835/audioop_findmax.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3306>
_______________________________________
From report at bugs.python.org Mon Jul 7 00:56:01 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jul 2008 22:56:01 +0000
Subject: [New-bugs-announce] [issue3307] invalid check of _bsddb creation
failure
In-Reply-To: <1215384961.05.0.023038653338.issue3307@psf.upfronthosting.co.za>
Message-ID: <1215384961.05.0.023038653338.issue3307@psf.upfronthosting.co.za>
New submission from STINNER Victor <haypo at users.sourceforge.net>:
newDBObject(), called by DB_construct(), doesn't check correctly the
result of all to the external function db_create(). It checks if
self->db is NULL, but db_create() doesn't change self->db value on
error. So if self->db is uninitialized, the error is not catched.
Two ideas to fix the bug:
- check "if (err)" instead of "if (self->db != NULL)"
- set self->db=NULL before calling db_create()
I implemented the second proposition in the attached patch.
Note: The bug occurs with PYDEBUG, I don't know if PyObject_New()
fills new allocate memory to zero (I think no, but I'm not sure).
----------
components: Library (Lib)
files: bsddb_create.patch
keywords: patch
messages: 69358
nosy: haypo
severity: normal
status: open
title: invalid check of _bsddb creation failure
versions: Python 2.6
Added file: http://bugs.python.org/file10836/bsddb_create.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3307>
_______________________________________
From report at bugs.python.org Mon Jul 7 02:16:21 2008
From: report at bugs.python.org (Roger Binns)
Date: Mon, 07 Jul 2008 00:16:21 +0000
Subject: [New-bugs-announce] [issue3308] MinGW built extensions do not load
(specified procedure cannot be found)
In-Reply-To: <1215389781.12.0.716617737168.issue3308@psf.upfronthosting.co.za>
Message-ID: <1215389781.12.0.716617737168.issue3308@psf.upfronthosting.co.za>
New submission from Roger Binns <python at rogerbinns.com>:
My extension (apsw) builds and runs just fine on Linux, Mac and Windows
for Python 2.3, 2.4 and 2.5. For Linux and Mac Python 2.6 beta 1 and
Python 3.0 beta 1 also work just fine. However on Windows using MinGW
and Python 2.6 beta 1 and Python 3.0 beta 1 the pyd fails to load
claiming the "specified procedure cannot be found". The compile/link is
just fine and pexports shows the procedure is present.
# Compile lines
c:/python26/python setup.py build --compile=mingw32 install
c:\mingw\bin\gcc.exe -mno-cygwin -mdll -O -Wall -DSQLITE_THREADSAFE=1
-DNDEBUG=1 -DEXPERIMENTAL=1
-DAPSW_USE_SQLITE_AMALGAMATION=\"C:\apsw\sqlite3.c\"
-Ic:\python26\include -Ic:\python26\PC -c apsw.c -o
build\temp.win32-2.6\Release\apsw.o
writing build\temp.win32-2.6\Release\apsw.def
c:\mingw\bin\gcc.exe -mno-cygwin -shared -s
build\temp.win32-2.6\Release\apsw.o
build\temp.win32-2.6\Release\apsw.def -Lc:\python26\libs
-Lc:\python26\PCbuild -lpython26 -lmsvcr90 -o build\lib.win32-2.6\apsw.pyd
# Running
ImportError: DLL load failed: The specified procedure could not be found.
# Pexports
C:\apsw>pexports build\lib.win32-2.6\apsw.pyd
LIBRARY apsw.pyd
EXPORTS
initapsw
When using Python 3.0 things are substantially the same except the init
function is PyInit_apsw.
MinGW was installed using the default configuration with the automated
installer http://sourceforge.net/forum/forum.php?forum_id=817299 The
libmsvcr90.a is part of MinGW found in c:\MinGW\lib
----------
components: Distutils
messages: 69361
nosy: rogerbinns
severity: normal
status: open
title: MinGW built extensions do not load (specified procedure cannot be found)
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3308>
_______________________________________
From report at bugs.python.org Mon Jul 7 02:46:01 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jul 2008 00:46:01 +0000
Subject: [New-bugs-announce] [issue3309] missing lock release in
BZ2File_iternext()
In-Reply-To: <1215391561.36.0.549542846727.issue3309@psf.upfronthosting.co.za>
Message-ID: <1215391561.36.0.549542846727.issue3309@psf.upfronthosting.co.za>
New submission from STINNER Victor <haypo at users.sourceforge.net>:
Call BZ2File_iternext() on closed file doesn't release the lock.
Example:
-----------
import bz2
obj = bz2.BZ2File('/etc/issue')
obj.close()
try:
#?acquire the lock
obj.next()
except ValueError, err:
#?but don't release the lock
print err
# DEAD LOCK here
obj.readlines()
-----------
Attached patch fixes this bug.
----------
components: Library (Lib)
files: bz2_lock.patch
keywords: patch
messages: 69362
nosy: haypo
severity: normal
status: open
title: missing lock release in BZ2File_iternext()
versions: Python 2.6
Added file: http://bugs.python.org/file10837/bz2_lock.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3309>
_______________________________________
From report at bugs.python.org Mon Jul 7 03:00:53 2008
From: report at bugs.python.org (Alexis Layton)
Date: Mon, 07 Jul 2008 01:00:53 +0000
Subject: [New-bugs-announce] [issue3310] Out-of-date example 3.0b1 Tutorial
Classes page, 'issubclass'
In-Reply-To: <1215392453.51.0.124729172537.issue3310@psf.upfronthosting.co.za>
Message-ID: <1215392453.51.0.124729172537.issue3310@psf.upfronthosting.co.za>
New submission from Alexis Layton <alex at permabit.com>:
The bullet example for 'issubclass' should be updated since neither
'unicode' or 'basestring' are valid anymore.
----------
assignee: georg.brandl
components: Documentation
messages: 69363
nosy: alexis.layton, georg.brandl
severity: normal
status: open
title: Out-of-date example 3.0b1 Tutorial Classes page, 'issubclass'
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3310>
_______________________________________
From report at bugs.python.org Mon Jul 7 03:18:40 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jul 2008 01:18:40 +0000
Subject: [New-bugs-announce] [issue3311] block operation on closed
socket/pipe for multiprocessing
In-Reply-To: <1215393520.85.0.811591651843.issue3311@psf.upfronthosting.co.za>
Message-ID: <1215393520.85.0.811591651843.issue3311@psf.upfronthosting.co.za>
New submission from STINNER Victor <haypo at users.sourceforge.net>:
_multiprocessing Connection methods don't check if handle is valid or
not. If you close the socket/pipe, Python may crash on operations,
especially in poll() on FD_SET(...handle, &rdfs).
Example of crash:
----------------------
import _multiprocessing
obj = _multiprocessing.Connection(755)
obj.close()
obj.poll()
----------------------
Attached patch is a proposition of fix to check handle in all
Connection methods using the handle.
----------
components: Library (Lib)
files: multiprocessing_closed.patch
keywords: patch
messages: 69365
nosy: haypo
severity: normal
status: open
title: block operation on closed socket/pipe for multiprocessing
versions: Python 2.6
Added file: http://bugs.python.org/file10838/multiprocessing_closed.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3311>
_______________________________________
From report at bugs.python.org Mon Jul 7 15:16:52 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jul 2008 13:16:52 +0000
Subject: [New-bugs-announce] [issue3312] bugs in _sqlite module
In-Reply-To: <1215436611.84.0.797718972528.issue3312@psf.upfronthosting.co.za>
Message-ID: <1215436611.84.0.797718972528.issue3312@psf.upfronthosting.co.za>
New submission from STINNER Victor <haypo at users.sourceforge.net>:
(A) module_register_adapter() doesn't check microprotocols_add()
result, whereas it can fails (eg. dict setitem error).
Example: "import _sqlite3; _sqlite3.register_adapter({}, None)" =>
should raise a TypeError (unhashable type: 'dict').
(B) Connection.set_isolation_level() tries to create the
string "BEGIN "+isolation_level and the store it as PyString in
begin_statement. But if the result can not be converted to string,
Python crashs. Example:
>>> import _sqlite3
>>> c=_sqlite3.Connection("a")
>>> c.isolation_level = u"\xe9"
Erreur de segmentation (core dumped)
Attached patch fix the two bugs.
----------
components: Library (Lib)
files: _sqlite.patch
keywords: patch
messages: 69387
nosy: haypo
severity: normal
status: open
title: bugs in _sqlite module
versions: Python 2.6
Added file: http://bugs.python.org/file10841/_sqlite.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3312>
_______________________________________
From report at bugs.python.org Mon Jul 7 15:24:33 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jul 2008 13:24:33 +0000
Subject: [New-bugs-announce] [issue3313] dlopen() error with no error
message from dlerror()
In-Reply-To: <1215437073.22.0.670628810168.issue3313@psf.upfronthosting.co.za>
Message-ID: <1215437073.22.0.670628810168.issue3313@psf.upfronthosting.co.za>
New submission from STINNER Victor <haypo at users.sourceforge.net>:
Python dl_open() function (from dl module) calls dlopen() and check
its result: if it's NULL, it's an error. This is correct if I read the
man page. But with an invalid flag value (-1), dlopen() returns NULL
but dlerror() also gives a NULL pointer. Example:
>>> import dl
>>> dl.open("/usr/lib/libm.so", -1)
Erreur de segmentation (core dumped)
Workaround: use a static error message if dlerror() returns NULL.
I wrote a patch for dl_open() but other functions (in ctypes module?)
should also call dlerror().
----------
components: Library (Lib)
files: dl_open.patch
keywords: patch
messages: 69388
nosy: haypo
severity: normal
status: open
title: dlopen() error with no error message from dlerror()
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file10842/dl_open.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3313>
_______________________________________
From report at bugs.python.org Mon Jul 7 16:50:30 2008
From: report at bugs.python.org (Matt Giuca)
Date: Mon, 07 Jul 2008 14:50:30 +0000
Subject: [New-bugs-announce] [issue3314] urllib.parse doesn't import sys
In-Reply-To: <1215442230.29.0.593652627296.issue3314@psf.upfronthosting.co.za>
Message-ID: <1215442230.29.0.593652627296.issue3314@psf.upfronthosting.co.za>
New submission from Matt Giuca <matt.giuca at gmail.com>:
urllib.parse doesn't import sys, which is needed on line 368, in an
error condition for urlencode. This is only a problem when urlencode has
a TypeError.
Current behaviour:
>>> urllib.parse.urlencode("foo")
NameError: global name 'sys' is not defined
Desired behaviour:
>>> urllib.parse.urlencode("foo")
TypeError: not a valid non-string sequence or mapping object
Only affects Python 3.0. (After urllib module was split up).
Patch attached, for revision 64772.
Commit log:
urllib/parse.py: Added missing "import sys".
----------
components: Library (Lib)
files: parse.py.patch
keywords: patch
messages: 69389
nosy: mgiuca
severity: normal
status: open
title: urllib.parse doesn't import sys
type: compile error
versions: Python 3.0
Added file: http://bugs.python.org/file10843/parse.py.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3314>
_______________________________________
From report at bugs.python.org Mon Jul 7 16:57:43 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Mon, 07 Jul 2008 14:57:43 +0000
Subject: [New-bugs-announce] [issue3315] abc.rst little error
In-Reply-To: <1215442663.49.0.883181790002.issue3315@psf.upfronthosting.co.za>
Message-ID: <1215442663.49.0.883181790002.issue3315@psf.upfronthosting.co.za>
New submission from Andrii V. Mishkovskyi <mishok13 at gmail.com>:
'make html' with latest py3k sources produces this warning:
WARNING: /home/mishok/doc/python/abc-doc-bug/Doc/library/abc.rst:11:
term not in glossary: abstract base classes
I've applied little patch that fixes this.
----------
assignee: georg.brandl
components: Documentation
files: abc.rst.diff
keywords: patch
messages: 69390
nosy: georg.brandl, mishok13
severity: normal
status: open
title: abc.rst little error
versions: Python 3.0
Added file: http://bugs.python.org/file10844/abc.rst.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3315>
_______________________________________
From report at bugs.python.org Mon Jul 7 22:36:54 2008
From: report at bugs.python.org (Nick Edds)
Date: Mon, 07 Jul 2008 20:36:54 +0000
Subject: [New-bugs-announce] [issue3316] Proposal for fix_urllib
In-Reply-To: <1215463014.46.0.808311046124.issue3316@psf.upfronthosting.co.za>
Message-ID: <1215463014.46.0.808311046124.issue3316@psf.upfronthosting.co.za>
New submission from Nick Edds <nedds at uchicago.edu>:
Here is my proposed fix_urllib. The transform function is massive
because there are a lot of cases, so maybe I should break it into
separate functions for each case, and it could maybe do with some more
documentation as well. I also use FromImport from fixer_util.py even
though it warns against doing so for dotted imports because it appears
to work. The temp.py file is a dummy python file that you can test it on
to get an idea of what it does. I think it's got all the desired
functionality, but I'm not an expert on the urllib changes so let me
know if I missed anything. I haven't written tests for it yet, but
assuming it looks reasonable, I can do that later today or tomorrow.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: fix_urllib.diff
keywords: patch
messages: 69395
nosy: brett.cannon, collinwinter, nedds
severity: normal
status: open
title: Proposal for fix_urllib
Added file: http://bugs.python.org/file10845/fix_urllib.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3316>
_______________________________________
From report at bugs.python.org Mon Jul 7 22:57:49 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 07 Jul 2008 20:57:49 +0000
Subject: [New-bugs-announce] [issue3317] duplicate lines in zipfile.py
In-Reply-To: <1215464269.75.0.951317701658.issue3317@psf.upfronthosting.co.za>
Message-ID: <1215464269.75.0.951317701658.issue3317@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:
Since r64688, zipfile.py contains duplicated definitions. The attached
patch removes them.
Also, Twisted uses a zipfile item that have been renamed by this change:
zipfile.stringFileHeader (now magicFileHeader).
This makes some tests fail on the community buildbots. See the rightmost
column on
http://www.python.org/dev/buildbot/community/trunk/
I suggest to rename all magicXXX variables back to stringXXX.
----------
assignee: loewis
components: Library (Lib)
messages: 69398
nosy: amaury.forgeotdarc, loewis
severity: normal
status: open
title: duplicate lines in zipfile.py
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3317>
_______________________________________
From report at bugs.python.org Tue Jul 8 03:43:13 2008
From: report at bugs.python.org (unutbu)
Date: Tue, 08 Jul 2008 01:43:13 +0000
Subject: [New-bugs-announce] [issue3318] Documentation: timeit: "lower
bound" should read "upper bound"
In-Reply-To: <1215481393.4.0.322080093727.issue3318@psf.upfronthosting.co.za>
Message-ID: <1215481393.4.0.322080093727.issue3318@psf.upfronthosting.co.za>
New submission from unutbu <driabslg at yahoo.com>:
Re: http://docs.python.org/lib/module-timeit.html
Where the documentation says "In a typical case, the lowest value gives
a lower bound for how fast your machine can run the given code snippet",
it should read instead,
"In a typical case, the lowest value gives an upper bound for how fast
your machine can run the given code snippet".
Clearly, if a machine can run a code snippet in x seconds with
background processes, then the fastest the machine can run the code
snippet (without background processes) should be <= x seconds. Therefore
x is an upper bound rather than a lower bound.
----------
assignee: georg.brandl
components: Documentation
messages: 69405
nosy: georg.brandl, unutbu
severity: normal
status: open
title: Documentation: timeit: "lower bound" should read "upper bound"
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3318>
_______________________________________
From report at bugs.python.org Tue Jul 8 10:44:06 2008
From: report at bugs.python.org (Michael Patrick O'Keefe)
Date: Tue, 08 Jul 2008 08:44:06 +0000
Subject: [New-bugs-announce] [issue3319] pystone.main(10) causes
ZeroDivisionError
In-Reply-To: <1215506646.09.0.809082477748.issue3319@psf.upfronthosting.co.za>
Message-ID: <1215506646.09.0.809082477748.issue3319@psf.upfronthosting.co.za>
New submission from Michael Patrick O'Keefe <michael.p.okeefe at gmail.com>:
The following call results in a ZeroDivisionError in python 2.5.2 and
python 3.0 alpha 3 (I presume this is also an issue for Python 2.6 but I
can't explicitly confirm):
>>> from test import pystone
>>> pystone.main(10)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/test/pystone.py",
line 61, in main
benchtime, stones = pystones(loops)
File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/test/pystone.py",
line 68, in pystones
return Proc0(loops)
File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/test/pystone.py",
line 131, in Proc0
return benchtime, (loops / benchtime)
ZeroDivisionError: float division
Note the patch I submitted checks if the benchtime is equal to 0.0
(which apparently happens on my Mac OS 10.5 PPC). If this is the case I
arbitrarily set the benchtime to 1e-6. I'm not sure what the units of
the benchtime variable is (seconds?). Anyhow, this fixes the issue but
can someone review to confirm this is the correct behavior?
Thanks!
-Michael
----------
components: Library (Lib), Tests
files: pystone_patch.txt
messages: 69418
nosy: mokeefe
severity: normal
status: open
title: pystone.main(10) causes ZeroDivisionError
type: behavior
versions: Python 2.5, Python 3.0
Added file: http://bugs.python.org/file10853/pystone_patch.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3319>
_______________________________________
From report at bugs.python.org Tue Jul 8 15:31:24 2008
From: report at bugs.python.org (DSM)
Date: Tue, 08 Jul 2008 13:31:24 +0000
Subject: [New-bugs-announce] [issue3320] various doc typos
In-Reply-To: <1215523884.32.0.11626417694.issue3320@psf.upfronthosting.co.za>
Message-ID: <1215523884.32.0.11626417694.issue3320@psf.upfronthosting.co.za>
New submission from DSM <dsm001 at users.sourceforge.net>:
Boredom resulted in a handful of doc copyedits against 64789.
One error I did note in the doc tree but didn't correct because it's in
code: includes/mp_distributing.py contains the typo
_logger.propogate = 0
which ISTM will leave the logger's propagate flag on. I can't imagine
this has any real consequence but I've never used either module.
----------
assignee: georg.brandl
components: Documentation
files: typos1.diff
keywords: patch
messages: 69428
nosy: dsm001, georg.brandl
severity: normal
status: open
title: various doc typos
versions: Python 2.6
Added file: http://bugs.python.org/file10857/typos1.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3320>
_______________________________________
From report at bugs.python.org Wed Jul 9 00:45:10 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jul 2008 22:45:10 +0000
Subject: [New-bugs-announce] [issue3321] _multiprocessing.Connection()
doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
New submission from STINNER Victor <haypo at users.sourceforge.net>:
_multiprocessing.Connection() allows to use any positive (or nul)
number has socket handle. If you use an invalid file descriptor,
poll() method may crash (especially for big positive integer).
Example:
>>> import _multiprocessing
>>> obj = _multiprocessing.Connection(44977608)
>>> obj.poll()
Erreur de segmentation (core dumped)
Fix: use fstat() to make sure that the handle is valid. Attached patch
implements this feature.
Another solution would be to reuse code from Modules/selectmodule.c.
----------
components: Library (Lib)
files: _multiprocessing_connection.patch
keywords: patch
messages: 69446
nosy: haypo
severity: normal
status: open
title: _multiprocessing.Connection() doesn't check handle
versions: Python 2.6
Added file: http://bugs.python.org/file10860/_multiprocessing_connection.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________
From report at bugs.python.org Wed Jul 9 00:58:10 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jul 2008 22:58:10 +0000
Subject: [New-bugs-announce] [issue3322] bugs in scanstring_str() and
scanstring_unicode() of _json module
In-Reply-To: <1215557890.28.0.315205708793.issue3322@psf.upfronthosting.co.za>
Message-ID: <1215557890.28.0.315205708793.issue3322@psf.upfronthosting.co.za>
New submission from STINNER Victor <haypo at users.sourceforge.net>:
scanstring_str() and scanstring_unicode() functions don't end value
whereas it can be outside input string range. A check like this is
needed:
if (end < 0 || len <= end) {
PyErr_SetString(PyExc_ValueError, "xxx");
return NULL;
}
next is set to begin but few lines later (before first use of next),
it's set to end: for (next = end; ...).
In error message, eg. "Invalid control character at (...)", begin is
used as character position but I think that the right position is in
the variable "end" (or maybe "next"?).
I'm unable to fix these functions because I don't understand the code.
----------
components: Library (Lib)
messages: 69447
nosy: haypo
severity: normal
status: open
title: bugs in scanstring_str() and scanstring_unicode() of _json module
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3322>
_______________________________________
From report at bugs.python.org Wed Jul 9 09:22:59 2008
From: report at bugs.python.org (Andy)
Date: Wed, 09 Jul 2008 07:22:59 +0000
Subject: [New-bugs-announce] [issue3323] Clarify __slots__ behaviour when
inheriting
In-Reply-To: <1215588179.05.0.980604972121.issue3323@psf.upfronthosting.co.za>
Message-ID: <1215588179.05.0.980604972121.issue3323@psf.upfronthosting.co.za>
New submission from Andy <strangefeatures at users.sourceforge.net>:
Suggest clarification on behaviour of the __slots__ attribute when
inheriting from classes that don't have __slots__ defined. Obviously the
superclass automatically creates __dict__, and it seems the subclass
inherits this. I presume this is expected behaviour, but I think it
would be worth clarifying in the 'Notes on using __slots__' section -
perhaps add something like:
"If you define __slots__ on a subclass when its superclass doesn't have
__slots__ defined, the superclass will automatically create a __dict__
instance which will be inherited by the subclass (as will other instance
attributes). Defining __slots__ on the subclass doesn't block this
inheritance."
----------
assignee: georg.brandl
components: Documentation
messages: 69460
nosy: georg.brandl, strangefeatures
severity: normal
status: open
title: Clarify __slots__ behaviour when inheriting
type: feature request
versions: 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 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3323>
_______________________________________
From report at bugs.python.org Wed Jul 9 13:32:14 2008
From: report at bugs.python.org (ThomasH)
Date: Wed, 09 Jul 2008 11:32:14 +0000
Subject: [New-bugs-announce] [issue3324] Broken link in online doc
In-Reply-To: <1215603134.48.0.502276263753.issue3324@psf.upfronthosting.co.za>
Message-ID: <1215603134.48.0.502276263753.issue3324@psf.upfronthosting.co.za>
New submission from ThomasH <thomas.bugzilla at gmx.net>:
The page http://docs.python.org/inst/search-path.html
contains a broken link to site module documentation.
Is: http://www.python.org/doc/devel/lib/module-site.html
Should be: http://docs.python.org/lib/module-site.html
----------
assignee: georg.brandl
components: Documentation
messages: 69462
nosy: ThomasH, georg.brandl
severity: normal
status: open
title: Broken link in online doc
type: behavior
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3324>
_______________________________________
From report at bugs.python.org Wed Jul 9 14:01:24 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Wed, 09 Jul 2008 12:01:24 +0000
Subject: [New-bugs-announce] [issue3325] use of cPickle in multiprocessing
In-Reply-To: <1215604884.64.0.41728166922.issue3325@psf.upfronthosting.co.za>
Message-ID: <1215604884.64.0.41728166922.issue3325@psf.upfronthosting.co.za>
New submission from Andrii V. Mishkovskyi <mishok13 at gmail.com>:
There are two places in multiprocessing where cPickle (gone from py3k
already) is used.
Both of them are in try .. except, so they don't break code.
Here is a patch that removes these uses.
----------
components: Library (Lib)
messages: 69463
nosy: jnoller, mishok13, roudkerk
severity: normal
status: open
title: use of cPickle in multiprocessing
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3325>
_______________________________________
From report at bugs.python.org Wed Jul 9 14:11:20 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Wed, 09 Jul 2008 12:11:20 +0000
Subject: [New-bugs-announce] [issue3326] py3k shouldn't use
-fno-strict-aliasing anymore
In-Reply-To: <1215605479.82.0.766368773223.issue3326@psf.upfronthosting.co.za>
Message-ID: <1215605479.82.0.766368773223.issue3326@psf.upfronthosting.co.za>
New submission from Ismail Donmez <ismail at namtrac.org>:
py3k branch is still using -fno-strict-aliasing but I tested with gcc
4.3.1 and there are no strict aliasing warnings when this flag is removed.
Attached patch for py3k branch removes this flag. After applying the
patch configure should be regenerated with autoconf.
----------
components: Interpreter Core
files: strict-aliasing.patch
keywords: patch
messages: 69465
nosy: cartman
severity: normal
status: open
title: py3k shouldn't use -fno-strict-aliasing anymore
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file10868/strict-aliasing.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3326>
_______________________________________
From report at bugs.python.org Wed Jul 9 15:33:42 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 09 Jul 2008 13:33:42 +0000
Subject: [New-bugs-announce] [issue3327] NULL member in modules_by_index
In-Reply-To: <1215610422.7.0.838989499254.issue3327@psf.upfronthosting.co.za>
Message-ID: <1215610422.7.0.838989499254.issue3327@psf.upfronthosting.co.za>
New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:
In _PyState_AddModule(), a list of (initially) 20 elements is created,
but there is no guarantee that all elements are initialized. In
particular, it appears that element 0 is always NULL. This is bad
since this list is accessible through introspection, e.g. by
gc.get_objects()
----------
components: Interpreter Core
messages: 69469
nosy: krisvale
severity: normal
status: open
title: NULL member in modules_by_index
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3327>
_______________________________________
From report at bugs.python.org Wed Jul 9 18:48:52 2008
From: report at bugs.python.org (Dominic Lavoie)
Date: Wed, 09 Jul 2008 16:48:52 +0000
Subject: [New-bugs-announce] [issue3328] When PyObject_CallMethod fails,
refcount is incorrect
In-Reply-To: <1215622132.38.0.408050175684.issue3328@psf.upfronthosting.co.za>
Message-ID: <1215622132.38.0.408050175684.issue3328@psf.upfronthosting.co.za>
New submission from Dominic Lavoie <dominic.lavoie at paraxip.com>:
This issue is similar to issue 1229429. In the called Python method, a
regular expression fails to compile & PyEval_CallMethod() returns 0.
However, the reference count is incremented by 1 which prevents the
object from being destroyed.
Could the problem be in classobject.c, in instancemethod_call() ?
if (newarg == NULL)
return NULL;
Py_INCREF(self);
PyTuple_SET_ITEM(newarg, 0, self);
for (i = 0; i < argcount; i++) {
PyObject *v = PyTuple_GET_ITEM(arg, i);
Py_XINCREF(v);
PyTuple_SET_ITEM(newarg, i+1, v);
}
arg = newarg;
}
result = PyObject_Call((PyObject *)func, arg, kw);
Py_DECREF(arg);
return result;
}
If result is null, should Py_DECREF(self) be called in the case where
self was non-null ?
----------
components: Interpreter Core
messages: 69474
nosy: dominic.lavoie
severity: normal
status: open
title: When PyObject_CallMethod fails, refcount is incorrect
type: resource usage
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3328>
_______________________________________
From report at bugs.python.org Wed Jul 9 21:48:53 2008
From: report at bugs.python.org (Jukka Laurila)
Date: Wed, 09 Jul 2008 19:48:53 +0000
Subject: [New-bugs-announce] [issue3329] API for setting the memory
allocator used by Python
In-Reply-To: <1215632933.18.0.0332019532518.issue3329@psf.upfronthosting.co.za>
Message-ID: <1215632933.18.0.0332019532518.issue3329@psf.upfronthosting.co.za>
New submission from Jukka Laurila <jukka.p.laurila at nokia.com>:
Currently Python always uses the C library malloc/realloc/free as the
underlying mechanism for requesting memory from the OS, but especially
on memory-limited platforms it is often desirable to be able to override
the allocator and to redirect all Python's allocations to use a special
heap. This will make it possible to free memory back to the operating
system without restarting the process, and to reduce fragmentation by
separating Python's allocations from the rest of the program.
The proposal is to make it possible to set the allocator used by the
Python interpreter by calling the following function before Py_Initialize():
void Py_SetAllocator(void* (*alloc)(size_t), void* (*realloc)(void*,
size_t), void (*free)(void*))
Direct function calls to malloc/realloc/free in obmalloc.c must be
replaced with calls through the function pointers set through this
function. By default these would of course point to the C stdlib
malloc/realloc/free.
----------
components: Interpreter Core
messages: 69482
nosy: jlaurila
severity: normal
status: open
title: API for setting the memory allocator used by Python
type: feature request
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3329>
_______________________________________
From report at bugs.python.org Wed Jul 9 23:37:00 2008
From: report at bugs.python.org (Adrian Petrescu)
Date: Wed, 09 Jul 2008 21:37:00 +0000
Subject: [New-bugs-announce] [issue3330] webbrowser module doesn't correctly
handle '|' character.
In-Reply-To: <1215639420.18.0.00968952650069.issue3330@psf.upfronthosting.co.za>
Message-ID: <1215639420.18.0.00968952650069.issue3330@psf.upfronthosting.co.za>
New submission from Adrian Petrescu <apetresc at gmail.com>:
The webbrowser module seems to treat URLs containing the "|" character
differently based on whether the browser is already running or not.
For instance, consider the following python script:
import webbrowser
url = "http://foo.com/bar.html?var=x|y|z"
webbrowser.open(url)
If you run this script while the browser is already running (so that
webbrowser.open creates a new tab) this behaves as you would expect,
with the given URL as an address.
However, if a browser is not already running, when webbrowser.open
creates it, it seems to interpret the "|" as a seperator character, so
that the browser will open with THREE tabs, one open to
"http://foo.com/bar.html?var=x", one to "http://y" and one to "http://z".
This is clearly a bug, webbrowser module should be smart enough to
escape the "|" character if the browser is interpreting that line
differently.
This happens in Linux with Python 2.5 and Firefox 3.0. Not sure if it
happens with anything else.
----------
components: Library (Lib)
messages: 69488
nosy: AdrianP
severity: normal
status: open
title: webbrowser module doesn't correctly handle '|' character.
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3330>
_______________________________________
From report at bugs.python.org Thu Jul 10 11:38:22 2008
From: report at bugs.python.org (Carl Johnson)
Date: Thu, 10 Jul 2008 09:38:22 +0000
Subject: [New-bugs-announce] [issue3331] Possible inconsistency in behavior
of list comprehensions vs. generator expressions
In-Reply-To: <1215682702.48.0.892529833903.issue3331@psf.upfronthosting.co.za>
Message-ID: <1215682702.48.0.892529833903.issue3331@psf.upfronthosting.co.za>
New submission from Carl Johnson <carl at carlsensei.com>:
Compare the following behaviors:
Python 3.0a5 (r30a5:62856, May 10 2008, 10:34:28)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.
>>> def f(x):
... if x > 5: raise StopIteration
...
>>> [x for x in range(100) if not f(x)]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 1, in <listcomp>
File "<stdin>", line 2, in f
StopIteration
>>> list(x for x in range(100) if not f(x))
[0, 1, 2, 3, 4, 5]
One might object that the behavior of the list comprehension is
identical to that of a for-loop:
>>> r = []
>>> for x in range(100):
... if not f(x):
... r.append(x)
...
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
File "<stdin>", line 2, in f
StopIteration
However, it can be argued that in Python 3 list comprehensions should be
thought of as "syntatic sugar" for ``list(generator expression)`` not a
for-loop with an accumulator. (This seems to be the motivation for no
longer "leaking" variables from list comprehensions into their enclosing
namespace.)
One interesting question that this raises (for me at least) is whether
the for-loop should also behave like a generator expression. Of course,
the behavior of the generator expression can already be simulated by
writing:
>>> r = []
>>> for x in range(100):
... try:
... if f(x):
... r.append(x)
... except StopIteration:
... break
...
>>> r
[0, 1, 2, 3, 4, 5]
This raises the question, do we need both a ``break`` statement and
``raise StopIteration``? Can the former just be made into syntatic sugar
for the later?
----------
components: Interpreter Core
messages: 69496
nosy: carlj
severity: normal
status: open
title: Possible inconsistency in behavior of list comprehensions vs. generator expressions
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3331>
_______________________________________
From report at bugs.python.org Thu Jul 10 15:59:54 2008
From: report at bugs.python.org (Jens Diemer)
Date: Thu, 10 Jul 2008 13:59:54 +0000
Subject: [New-bugs-announce] [issue3332] DocTest and dict sort.
In-Reply-To: <1215698394.53.0.241298622742.issue3332@psf.upfronthosting.co.za>
Message-ID: <1215698394.53.0.241298622742.issue3332@psf.upfronthosting.co.za>
New submission from Jens Diemer <bugs.python.org at jensdiemer.de>:
The doctest doesn't work good, if a function returns a dict.
Here a simple example:
def test(d):
"""
This works:
>>> test({"A":1, "B":2, "C":3})
{'A': 1, 'C': 3, 'B': 2}
This failed, because of different dict sort:
>>> test({"A":1, "B":2, "C":3})
{'A': 1, 'B': 2, 'C': 3}
The Error messages:
Failed example:
test({"A":1, "B":2, "C":3})
Expected:
{'A': 1, 'B': 2, 'C': 3}
Got:
{'A': 1, 'C': 3, 'B': 2}
"""
return d
The problem is IMHO that doctest.py [1] OutputChecker.check_output()
does compare the repr() of the dict and not the real dict as data.
One solution: Use eval() to convert the string repr. of the dict into
the real dict:
...
#-----<add>-----
try:
if eval(got) == eval(want):
return True
except:
pass #*pfeif* kein schoener stil, aber pragmatisch
#-----</add>----
# We didn't find any match; return false.
return False
German discuss can be found here:
http://www.python-forum.de/topic-15321.html
[1] http://svn.python.org/view/python/trunk/Lib/doctest.py?view=markup
----------
components: Extension Modules
messages: 69501
nosy: jedie
severity: normal
status: open
title: DocTest and dict sort.
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3332>
_______________________________________
From report at bugs.python.org Thu Jul 10 17:06:25 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 10 Jul 2008 15:06:25 +0000
Subject: [New-bugs-announce] [issue3333] Need -3 warning for exec statement
becoming a function
Message-ID: <1215702385.26.0.978692514818.issue3333@psf.upfronthosting.co.za>
Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:
----------
nosy: rhettinger
priority: high
severity: normal
status: open
title: Need -3 warning for exec statement becoming a function
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3333>
_______________________________________
From report at bugs.python.org Thu Jul 10 18:55:13 2008
From: report at bugs.python.org (Christian Theune)
Date: Thu, 10 Jul 2008 16:55:13 +0000
Subject: [New-bugs-announce] [issue3334] 2to3 looses indentation on import
fix
In-Reply-To: <1215708913.27.0.554899314818.issue3334@psf.upfronthosting.co.za>
Message-ID: <1215708913.27.0.554899314818.issue3334@psf.upfronthosting.co.za>
New submission from Christian Theune <ct at gocept.com>:
I got this output from 2to3:
(This is from setuptools egg_info.py)
- import bdist_egg; bdist_egg.write_safety_flag(cmd.egg_info, safe)
+from . import bdist_egg; bdist_egg.write_safety_flag(cmd.egg_info, safe)
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 69510
nosy: collinwinter, ctheune
severity: normal
status: open
title: 2to3 looses indentation on import fix
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3334>
_______________________________________
From report at bugs.python.org Thu Jul 10 20:21:49 2008
From: report at bugs.python.org (Justin Harper)
Date: Thu, 10 Jul 2008 18:21:49 +0000
Subject: [New-bugs-announce] [issue3335] subprocess lib - opening same
command fails
In-Reply-To: <1215714109.54.0.694073882859.issue3335@psf.upfronthosting.co.za>
Message-ID: <1215714109.54.0.694073882859.issue3335@psf.upfronthosting.co.za>
New submission from Justin Harper <justin.harper at gmail.com>:
When I make the same shell call a second time, a weird error occurs.
It appears that the system is caching the call and then returning the
same object the second time, which causes a problem because the stream
is at EOF and there is no way to seek on this sort of file object.
Code:
fout = subprocess.Popen("owplaces -silent -multi", shell=True,
stdout=subprocess.PIPE).stdout
self.output = fout.read()
if self.output != []:
for line in self.output:
print line
fout.close()
Error:
Traceback (most recent call last):
File "./saveSettings.py", line 30, in next_page
func()
File "./saveSettings.py", line 62, in save_startup
fout = subprocess.Popen("owplaces -silent -multi", shell=True,
stdout=subprocess.PIPE).stdout
File "/opt/app/g++lib6/python-2.4/lib/python2.4/warnings.py", line
61, in warn
warn_explicit(message, category, filename, lineno, module, registry)
File "/opt/app/g++lib6/python-2.4/lib/python2.4/warnings.py", line
82, in warn_explicit
for item in filters:
TypeError: an integer is required
The first time the code works time. The second (and subsequent times)
the cryptic error msg is displayed.
Python 2.4.5 running on a Solaris machine.
----------
components: Library (Lib)
messages: 69514
nosy: gtg944q
severity: normal
status: open
title: subprocess lib - opening same command fails
versions: Python 2.4
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3335>
_______________________________________
From report at bugs.python.org Thu Jul 10 21:39:49 2008
From: report at bugs.python.org (ryanboesch)
Date: Thu, 10 Jul 2008 19:39:49 +0000
Subject: [New-bugs-announce] [issue3336] datetime weekday() function
In-Reply-To: <1215718789.31.0.810628437344.issue3336@psf.upfronthosting.co.za>
Message-ID: <1215718789.31.0.810628437344.issue3336@psf.upfronthosting.co.za>
New submission from ryanboesch <ryanboesch at gmail.com>:
Leap year ignored each century (2100, 2200, 2300, etc.) except 2000 for
the weekday() function. This code reproduces the error:
import datetime
datetime.date(2100,2,29).weekday()
Error message:
ValueError: day is out of range for the month
Also, this causes the weekday to be 1 day off from March 1st, 2100 to
February 28th 2200 and 2 days off...
----------
messages: 69517
nosy: ryanboesch
severity: normal
status: open
title: datetime weekday() function
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3336>
_______________________________________
From report at bugs.python.org Fri Jul 11 03:51:44 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 11 Jul 2008 01:51:44 +0000
Subject: [New-bugs-announce] [issue3337] Fixer for dbm is failing
In-Reply-To: <1215741104.01.0.138500186451.issue3337@psf.upfronthosting.co.za>
Message-ID: <1215741104.01.0.138500186451.issue3337@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
The fixer for dbm to dbm.ndbm fails test_fixers.Test_imports .
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 69526
nosy: brett.cannon, collinwinter
priority: critical
severity: normal
status: open
title: Fixer for dbm is failing
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3337>
_______________________________________
From report at bugs.python.org Fri Jul 11 06:54:22 2008
From: report at bugs.python.org (Darryl Dixon)
Date: Fri, 11 Jul 2008 04:54:22 +0000
Subject: [New-bugs-announce] [issue3338] cPickle segfault with deep recursion
In-Reply-To: <1215752062.17.0.76482457949.issue3338@psf.upfronthosting.co.za>
Message-ID: <1215752062.17.0.76482457949.issue3338@psf.upfronthosting.co.za>
New submission from Darryl Dixon <esrever_otua at winterhouseconsulting.com>:
In at least Python 2.4, using cPickle.Pickler to try and pickle a nested
chain of objects more than about 2590 objects deep causes the Python
interpreter to segfault. This doesn't seem to happen when using the pure
Python pickle module.
It is not memory related (witness that the pure Python module can
achieve depths much greater than this just fine), and does not seem to
be directly related to system architecture (happens on both i386 and on
x86_64 (32bit and 64bit)).
Sample interpreter session to replicate:
>>> # Let's cause cPickle to segfault:
>>> from cPickle import Pickler as cPickler
>>> class rec:
... child = None
... def __init__(self, counter):
... if counter > 0:
... self.child = rec(counter-1)
...
>>> import sys
>>> sys.setrecursionlimit(10000)
>>> mychain = rec(2600)
>>> from cStringIO import StringIO
>>> stream = StringIO()
>>> p = cPickler(stream, 1)
>>> res = p.dump(mychain)
Segmentation fault
And now the same steps again using the pure Python Pickler:
>>> import sys
>>> from pickle import Pickler as pPickler
>>> from cStringIO import StringIO
>>> class rec:
... child = None
... def __init__(self, counter):
... if counter > 0:
... self.child = rec(counter-1)
...
>>> sys.setrecursionlimit(20000)
>>> mychain = rec(2600)
>>> stream = StringIO()
>>> p = pPickler(stream, 1)
>>> p.dump(mychain)
>>> len(stream.getvalue())
48676
>>>
----------
components: Library (Lib)
messages: 69532
nosy: esrever_otua
severity: normal
status: open
title: cPickle segfault with deep recursion
type: crash
versions: Python 2.4
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3338>
_______________________________________
From report at bugs.python.org Fri Jul 11 09:52:35 2008
From: report at bugs.python.org (Henk Punt)
Date: Fri, 11 Jul 2008 07:52:35 +0000
Subject: [New-bugs-announce] [issue3339] dummy_thread LockType.acquire()
always returns None, should be True or False
In-Reply-To: <1215762755.01.0.797304698673.issue3339@psf.upfronthosting.co.za>
Message-ID: <1215762755.01.0.797304698673.issue3339@psf.upfronthosting.co.za>
New submission from Henk Punt <henkpunt at gmail.com>:
Class LockType always seems to be returning None if waitflag is not
specified.
If you look up the documentation for the non dummy lock in lib ref
15.3.1 , none of the possible
results should be ?None?, in fact it would always return True, except
when non-block is specified
And another thread is already holding the lock then it would return False
>From the docs on acquire():
Acquire a lock, blocking or non-blocking.
When invoked without arguments, block until the lock is unlocked, then
set it to locked, and return true.
When invoked with the blocking argument set to true, do the same thing
as when called without arguments, and return true.
When invoked with the blocking argument set to false, do not block. If a
call without an argument would block, return false immediately;
otherwise, do the same thing as when called without arguments, and
return true.
----------
components: Library (Lib)
messages: 69539
nosy: toymachine
severity: normal
status: open
title: dummy_thread LockType.acquire() always returns None, should be True or False
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3339>
_______________________________________
From report at bugs.python.org Fri Jul 11 12:46:00 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 11 Jul 2008 10:46:00 +0000
Subject: [New-bugs-announce] [issue3340] optparse print_usage(),
.. methods are not documented
In-Reply-To: <1215773160.32.0.150230480074.issue3340@psf.upfronthosting.co.za>
Message-ID: <1215773160.32.0.150230480074.issue3340@psf.upfronthosting.co.za>
New submission from anatoly techtonik <techtonik at gmail.com>:
optparse API documentation is incomplete. It doesn't mention at least
some useful functions such as print_usage(), get_usage(),
get/print_version() present in optparse.py docstrings.
----------
assignee: georg.brandl
components: Documentation
messages: 69543
nosy: georg.brandl, techtonik
severity: normal
status: open
title: optparse print_usage(),.. methods are not documented
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3340>
_______________________________________
From report at bugs.python.org Fri Jul 11 13:10:09 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 11 Jul 2008 11:10:09 +0000
Subject: [New-bugs-announce] [issue3341] "Suggest a change" link
In-Reply-To: <1215774609.12.0.768814080421.issue3341@psf.upfronthosting.co.za>
Message-ID: <1215774609.12.0.768814080421.issue3341@psf.upfronthosting.co.za>
New submission from anatoly techtonik <techtonik at gmail.com>:
It would be convenient to have "Suggest a change" link in the bottom of
documentation pages to allow people propose fixes and additions.
This can be a simple feedback form with an optional "patch" field that
submits mail to a list or simply adds documentation comment.
More complex approach would be construct patch right in the browser.
Then add it for review into "documentation queue". "documentation queue"
is a part of documentation system to automatically submit patches after
review (and optionally incrementally-recompile existing output formats).
In case of page comments review status can be displayed in place
together with comments and patches. The whole edit/review process may
require single sign on system described in issue #2837
----------
assignee: georg.brandl
components: Documentation
messages: 69544
nosy: georg.brandl, techtonik
severity: normal
status: open
title: "Suggest a change" link
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3341>
_______________________________________
From report at bugs.python.org Fri Jul 11 14:03:12 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 11 Jul 2008 12:03:12 +0000
Subject: [New-bugs-announce] [issue3342] Tracebacks are not properly indented
In-Reply-To: <1215777792.78.0.290652492508.issue3342@psf.upfronthosting.co.za>
Message-ID: <1215777792.78.0.290652492508.issue3342@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:
r62555 has the unfortunate effect that source lines are no more indented
in tracebacks, as in:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "C:\python\trunk\lib\re.py", line 150, in sub
return _compile(pattern, 0).sub(repl, string, count)
File "C:\python\trunk\lib\re.py", line 276, in filter
return sre_parse.expand_template(template, match)
File "c:\python\trunk\lib\sre_parse.py", line 793, in expand_template
raise error, "unmatched group"
sre_constants.error: unmatched group
And IMO, test_traceback.test_traceback_indentation() tests the wrong
behaviour :-(
I join a tentative patch to correct the problem.
----------
files: traceback.patch
keywords: patch
messages: 69546
nosy: amaury.forgeotdarc
severity: normal
status: open
title: Tracebacks are not properly indented
Added file: http://bugs.python.org/file10877/traceback.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3342>
_______________________________________
From report at bugs.python.org Fri Jul 11 14:20:49 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 11 Jul 2008 12:20:49 +0000
Subject: [New-bugs-announce] [issue3343] Py_DisplaySourceLine is not
documented
In-Reply-To: <1215778849.22.0.645711118374.issue3343@psf.upfronthosting.co.za>
Message-ID: <1215778849.22.0.645711118374.issue3343@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:
This new function is not documented at all.
And I find the error handling not consistent: when filename is NULL, -1
is returned, but no exception is set.
IMO the return code should be as follow:
- return 1 if a line was printed
- return 0 if the line cannot be found
- return -1 in case of error (when calling PyFile_WriteString); an
exception is set.
----------
components: Interpreter Core
messages: 69548
nosy: amaury.forgeotdarc
severity: normal
status: open
title: Py_DisplaySourceLine is not documented
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3343>
_______________________________________
From report at bugs.python.org Sat Jul 12 00:41:53 2008
From: report at bugs.python.org (Tal Einat)
Date: Fri, 11 Jul 2008 22:41:53 +0000
Subject: [New-bugs-announce] [issue3344] IDLE - use enumerate instead of
zip(count(), ...)
In-Reply-To: <1215816113.04.0.292496585151.issue3344@psf.upfronthosting.co.za>
Message-ID: <1215816113.04.0.292496585151.issue3344@psf.upfronthosting.co.za>
New submission from Tal Einat <taleinat at users.sourceforge.net>:
Just minor code cleanup.
Only one instance of zip(count(), ...) in EditorWindow.py, where I also
changed 'file' to 'file_name' to avoid overriding the built-in 'file' class.
----------
files: IDLE_EditorWindow_minor.patch
keywords: patch
messages: 69571
nosy: kbk, taleinat
severity: normal
status: open
title: IDLE - use enumerate instead of zip(count(), ...)
Added file: http://bugs.python.org/file10878/IDLE_EditorWindow_minor.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3344>
_______________________________________
From report at bugs.python.org Sat Jul 12 01:30:06 2008
From: report at bugs.python.org (Miki Tebeka)
Date: Fri, 11 Jul 2008 23:30:06 +0000
Subject: [New-bugs-announce] [issue3345] Patch for CGIHTTPServer.is_cgi
function documentation
In-Reply-To: <1215819006.82.0.818103685798.issue3345@psf.upfronthosting.co.za>
Message-ID: <1215819006.82.0.818103685798.issue3345@psf.upfronthosting.co.za>
New submission from Miki Tebeka <miki.tebeka at gmail.com>:
The current documentation is wrong and does not specify the fact that
this functions sets "cgi_info" (maybe also rename the function?)
----------
assignee: georg.brandl
components: Documentation
files: CGIHTTPServer.py.diff
keywords: patch
messages: 69574
nosy: georg.brandl, tebeka
severity: normal
status: open
title: Patch for CGIHTTPServer.is_cgi function documentation
versions: Python 2.6
Added file: http://bugs.python.org/file10879/CGIHTTPServer.py.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3345>
_______________________________________
From report at bugs.python.org Sat Jul 12 12:24:51 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Sat, 12 Jul 2008 10:24:51 +0000
Subject: [New-bugs-announce] [issue3346] test_ossaudiodev fails
In-Reply-To: <1215858291.72.0.125159107057.issue3346@psf.upfronthosting.co.za>
Message-ID: <1215858291.72.0.125159107057.issue3346@psf.upfronthosting.co.za>
New submission from Ismail Donmez <ismail at namtrac.org>:
This is a rather new regression:
test_ossaudiodev
test test_ossaudiodev failed -- Traceback (most recent call last):
File "/home/cartman/Sources/py3k/Lib/test/test_ossaudiodev.py", line
146, in test_playback
self.play_sound_file(*sound_info)
File "/home/cartman/Sources/py3k/Lib/test/test_ossaudiodev.py", line
66, in play_sound_file
setattr(dsp, attr, 42)
AttributeError: 'ossaudiodev.oss_audio_device' object has no attribute
'closed'
----------
components: Tests
messages: 69582
nosy: cartman
severity: normal
status: open
title: test_ossaudiodev fails
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3346>
_______________________________________
From report at bugs.python.org Sat Jul 12 15:46:17 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sat, 12 Jul 2008 13:46:17 +0000
Subject: [New-bugs-announce] [issue3347] urllib.robotparser doesn't work in
Py3k
In-Reply-To: <1215870377.1.0.267386206374.issue3347@psf.upfronthosting.co.za>
Message-ID: <1215870377.1.0.267386206374.issue3347@psf.upfronthosting.co.za>
New submission from Matt Giuca <matt.giuca at gmail.com>:
urllib.robotparser is broken in Python 3.0, due to a bytes object
appearing where a str is expected.
Example:
>>> import urllib.robotparser
>>> r =
urllib.robotparser.RobotFileParser('http://www.python.org/robots.txt')
>>> r.read()
TypeError: expected an object with the buffer interface
This is because the variable f in RobotFileParser.read is opened by
urlopen as a binary file, so f.read() returns a bytes object.
I've included a patch, which checks if it's a bytes, and if so, decodes
it with 'utf-8'. A more thorough fix might figure out what the charset
of the document is (in f.headers['Content-Type']), but at least this
works, and will be sufficient in almost all cases.
Also there are no test cases for urllib.robotparser.
Patch (robotparser.py.patch) is for branch /branches/py3k, revision 64891.
Commit log:
Lib/urllib/robotparser.py: Fixed robotparser for Python 3.0. urlopen
returns bytes objects where str expected. Decode the bytes using UTF-8.
----------
components: Library (Lib)
files: robotparser.py.patch
keywords: patch
messages: 69586
nosy: mgiuca
severity: normal
status: open
title: urllib.robotparser doesn't work in Py3k
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file10885/robotparser.py.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3347>
_______________________________________
From report at bugs.python.org Sat Jul 12 18:19:28 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sat, 12 Jul 2008 16:19:28 +0000
Subject: [New-bugs-announce] [issue3348] Cannot start wsgiref simple server
in Py3k
In-Reply-To: <1215879568.13.0.955436276561.issue3348@psf.upfronthosting.co.za>
Message-ID: <1215879568.13.0.955436276561.issue3348@psf.upfronthosting.co.za>
New submission from Matt Giuca <matt.giuca at gmail.com>:
The wsgiref "simple server" module has a demo server, which fails to
start in Python 3.0 for a bunch of reasons.
To verify this, just go into the Lib/wsgiref directory, and run:
python3.0 ./simple_server.py
(which launches the demo server).
This opens your web browser and points it at the server, and you get the
following error:
ValueError: need more than 1 value to unpack
I fixed a number of issues which simply killed the server:
* In get_environ, it did not iterate over the headers mapping properly
at all (was expecting a sequence of strings, it actually is a mapping).
I think the email.message.Message class changed. Fixed.
* In demo_app, it calls sort on the output of dict.items() - a list in
Python 2, but an iterator in Python 3, so it fails. Fixed (using "sorted").
Unfortunately, the final issue is a bit harder to fix. It seems when I
run the demo server, it opens a binary stream, but handlers.py sends
strings to be written, giving the error
TypeError: send() argument 1 must be bytes or read-only buffer, not str
However in the test case, it opens a text stream, so handlers.py works fine.
The following *HACK* fixes it so the demo server works, but breaks the
test suite (it is NOT included in the attached patch):
--- Lib/wsgiref/handlers.py (revision 64895)
+++ Lib/wsgiref/handlers.py (working copy)
@@ -382,8 +382,8 @@
self.environ.update(self.base_env)
def _write(self,data):
- self.stdout.write(data)
- self._write = self.stdout.write
+ self.stdout.write(data.encode('utf-8'))
+ #self._write = self.stdout.write
I can't figure out right away what to do about this, but the best
solution would be to get the demo server to open the socket in text mode.
In any case, the patch is attached for branch /branches/py3k, revision
64895.
Commit log:
* Lib/wsgiref/simple_server.py: Fixed two fatal errors which prevent the
demo server from running (broken due to Python 3.0).
Note: Demo server may still not run due to an issue between strings and
bytes.
----------
components: Library (Lib)
files: simple_server.py.patch
keywords: patch
messages: 69587
nosy: mgiuca
severity: normal
status: open
title: Cannot start wsgiref simple server in Py3k
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file10886/simple_server.py.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3348>
_______________________________________
From report at bugs.python.org Sat Jul 12 18:40:22 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 12 Jul 2008 16:40:22 +0000
Subject: [New-bugs-announce] [issue3349] search for 'patch' produces roundup
error
In-Reply-To: <1215880822.27.0.821032673893.issue3349@psf.upfronthosting.co.za>
Message-ID: <1215880822.27.0.821032673893.issue3349@psf.upfronthosting.co.za>
New submission from anatoly techtonik <techtonik at gmail.com>:
If you'll try to search 'patch' word in this bugtracker, you will likely
to get the error saved in attached file.
----------
files: bugs.python.org.txt
messages: 69588
nosy: techtonik
severity: normal
status: open
title: search for 'patch' produces roundup error
Added file: http://bugs.python.org/file10887/bugs.python.org.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3349>
_______________________________________
From report at bugs.python.org Sun Jul 13 20:20:42 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 13 Jul 2008 18:20:42 +0000
Subject: [New-bugs-announce] [issue3350] multiprocessing adds built-in types
to the global copyreg.dispatch_table
In-Reply-To: <1215973242.49.0.0824567359746.issue3350@psf.upfronthosting.co.za>
Message-ID: <1215973242.49.0.0824567359746.issue3350@psf.upfronthosting.co.za>
New submission from Alexandre Vassalotti <alexandre at peadrop.com>:
The multiprocessing module modifies the global copyreg.dispatch_table to
extend pickling to several built-in types (mostly callable types). In my
humble opinion, this is unacceptable for a standard library module.
Here is an example of a behaviour change made by multiprocessing:
>>> import pickle
>>> pickle.dumps(str.isalpha)
Traceback (most recent call last):
...
_pickle.PicklingError: Can't pickle <class 'method_descriptor'>:
attribute lookup builtins.method_descriptor failed
>>> import multiprocessing.util
>>> pickle.dumps(str.isalpha)
b'\x80\x03cbuiltins\ngetattr\nq\x00cbuiltins\nstr\nq\x01X\x07\x00\x00\x00isalphaq\x02\x86q\x03Rq\x04.'
There was some discussion in issue 558238 about allowing methods to be
pickled. However, no consensus was reached.
In addition, there is a bug in the method pickling support added by
multiprocessing in Python 3.0:
Python 2.6b1+ (trunk:64899:64900, Jul 13 2008, 13:33:02)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing.util, pickle
>>> class A(object):
... def foo(self): pass
...
>>> pickle.dumps(A().foo, 2)
'\x80\x02c__builtin__\ngetattr\nq\x00c__main__\nA\nq\x01)\x81q\x02}q\x03bU\x03fooq\x04\x86q\x05Rq\x06.'
>>> pickle.dumps(A.foo, 2)
'\x80\x02c__builtin__\ngetattr\nq\x00c__main__\nA\nq\x01U\x03fooq\x02\x86q\x03Rq\x04.'
Python 3.0b1+ (py3k:64876M, Jul 11 2008, 12:20:51)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing.util, pickle
>>> class A(object):
... def foo(self): pass
...
>>> pickle.dumps(A().foo, 2)
Traceback (most recent call last):
...
pickle.PicklingError: Can't pickle <class 'method'>: it's not found as
builtins.method
>>> pickle.dumps(A.foo, 2)
Traceback (most recent call last):
...
pickle.PicklingError: Can't pickle <function foo at 0xb7b1392c>: it's
not found as __main__.foo
A better solution for the interprocess communication needs of
multiprocessing would be to define custom subclass of Pickler with
extended support for built-in types. If needed, I am willing to extend
the _pickle module in Python 3.0 to support modification to its
"dispatch table", like the undocumented dispatch_table attribute in
pickle.Pickler.
----------
components: Library (Lib)
messages: 69615
nosy: alexandre.vassalotti
priority: normal
severity: normal
status: open
title: multiprocessing adds built-in types to the global copyreg.dispatch_table
type: behavior
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3350>
_______________________________________
From report at bugs.python.org Mon Jul 14 05:07:33 2008
From: report at bugs.python.org (yiyuan)
Date: Mon, 14 Jul 2008 03:07:33 +0000
Subject: [New-bugs-announce] [issue3351] Python crashed
In-Reply-To: <1216004853.72.0.816849271152.issue3351@psf.upfronthosting.co.za>
Message-ID: <1216004853.72.0.816849271152.issue3351@psf.upfronthosting.co.za>
New submission from yiyuan <support at proxyshell.com>:
Hi,
I'm new here and I'm not sure whether this should be reported here.
OS: CentOS 2.6.9-67.0.15.EL
Memory: 512M
Python Version: 2.5.1
The crash happened after our web program writen with python running for
many days (maybe 20 days).
Here are the logs I found in /var/log/messages
Jul 14 04:30:38 kernel: Unable to handle kernel NULL pointer
dereference at virtual address 00000002
Jul 14 04:30:38 kernel: printing eip:
Jul 14 04:30:38 kernel: 00000002
Jul 14 04:30:38 kernel: *pde = 0c223067
Jul 14 04:30:38 kernel: Oops: 0000 [#1]
Jul 14 04:30:38 kernel: Modules linked in: ipt_state ipt_TOS
iptable_mangle ip_conntrack_ftp ip_conntrack_irc ip_conntrack ipt_REJECT
ipt_LOG ipt_limit iptable_filter ipt_multiport ip_tables autofs4 sunrpc
loop dm_mirror dm_mod ohci_hcd ehci_hcd k8_edac edac_mc snd_atiixp
snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore
snd_page_alloc tg3 floppy ext3 jbd sata_sil libata sd_mod scsi_mod
Jul 14 04:30:38 kernel: CPU: 0
Jul 14 04:30:38 kernel: EIP: 0060:[<00000002>] Not tainted VLI
Jul 14 04:30:38 kernel: EFLAGS: 00010202 (2.6.9-67.0.15.EL)
Jul 14 04:30:38 kernel: EIP is at 0x2
Jul 14 04:30:38 kernel: eax: c11bf760 ebx: c11bf760 ecx: c11bf760
edx: 00000002
Jul 14 04:30:38 kernel: esi: 00000000 edi: 0000c000 ebp: c5a2e1a8
esp: c7198ecc
Jul 14 04:30:38 kernel: ds: 007b es: 007b ss: 0068
Jul 14 04:30:38 kernel: Process python (pid: 16598, threadinfo=c7198000
task=c8cccbd0)
Jul 14 04:30:38 kernel: Stack: c01514ee c015ab59 0dfbb067 00080000
1ec5e000 c0411074 1ec5e000 1ecde000
Jul 14 04:30:38 kernel: d3a2e1f0 c0411074 c015ac29 00080000
00000000 1ec5e000 d3a2e1f0 1ecde000
Jul 14 04:30:38 kernel: c0411074 c015ac88 00080000 00000000
c7198f7c 1ec5e000 cd708b4c 1edac000
Jul 14 04:30:38 kernel: Call Trace:
Jul 14 04:30:38 kernel: [<c01514ee>] set_page_dirty+0x2c/0x41
Jul 14 04:30:38 kernel: [<c015ab59>] zap_pte_range+0x191/0x21f
Jul 14 04:30:38 kernel: [<c015ac29>] zap_pmd_range+0x42/0x65
Jul 14 04:30:38 kernel: [<c015ac88>] unmap_page_range+0x3c/0x5f
Jul 14 04:30:38 kernel: [<c015ad9c>] unmap_vmas+0xf1/0x1df
Jul 14 04:30:38 kernel: [<c015f5d0>] unmap_region+0x61/0xc6
Jul 14 04:30:38 kernel: [<c015f8a8>] do_munmap+0x144/0x1b1
Jul 14 04:30:38 kernel: [<c015f966>] sys_munmap+0x51/0x68
Jul 14 04:30:38 kernel: [<c031dfc3>] syscall_call+0x7/0xb
Jul 14 04:30:38 kernel: Code: Bad EIP value.
Jul 14 04:30:38 kernel: <0>Fatal exception: panic in 5 seconds
Jul 14 04:30:38 kernel: bad: scheduling while atomic!
Jul 14 04:30:38 kernel: [<c031b251>] schedule+0x2d/0x606
Jul 14 04:30:38 kernel: [<c031c921>] schedule_timeout+0x158/0x17c
Jul 14 04:30:38 kernel: [<c012e839>] process_timeout+0x0/0x13
Jul 14 04:30:38 kernel: [<c012491b>] printk+0xe/0x11
Jul 14 04:30:38 kernel: [<c0106938>] die+0x21a/0x22b
Jul 14 04:30:38 kernel: [<c011db6d>] do_page_fault+0x380/0x4dc
Jul 14 04:30:38 kernel: [<c014fcf9>] buffered_rmqueue+0x1c4/0x1e7
Jul 14 04:30:38 kernel: [<c014fdd0>] __alloc_pages+0xb4/0x2a6
Jul 14 04:30:38 kernel: [<c011d7ed>] do_page_fault+0x0/0x4dc
Jul 14 04:30:38 kernel: [<c031ea5b>] error_code+0x2f/0x38
Jul 14 04:30:38 kernel: [<c01514ee>] set_page_dirty+0x2c/0x41
Jul 14 04:30:38 kernel: [<c015ab59>] zap_pte_range+0x191/0x21f
Jul 14 04:30:38 kernel: [<c015ac29>] zap_pmd_range+0x42/0x65
Jul 14 04:30:38 kernel: [<c015ac88>] unmap_page_range+0x3c/0x5f
Jul 14 04:30:38 kernel: [<c015ad9c>] unmap_vmas+0xf1/0x1df
Jul 14 04:30:38 kernel: [<c015f5d0>] unmap_region+0x61/0xc6
Jul 14 04:30:38 kernel: [<c015f8a8>] do_munmap+0x144/0x1b1
Jul 14 04:30:38 kernel: [<c015f966>] sys_munmap+0x51/0x68
Jul 14 04:30:38 kernel: [<c031dfc3>] syscall_call+0x7/0xb
What caused this problem? Run out of memory? Please tell me what I can do.
Regards
YiYuan
----------
components: Interpreter Core
messages: 69640
nosy: yiyuan
severity: normal
status: open
title: Python crashed
type: crash
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3351>
_______________________________________
From report at bugs.python.org Mon Jul 14 11:57:56 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 14 Jul 2008 09:57:56 +0000
Subject: [New-bugs-announce] [issue3352] Deficiencies in
multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
New submission from Nick Coghlan <ncoghlan at gmail.com>:
The "PEP 8 compliant" API for multiprocessing and threading needs to be
cleaned up before release as per the thread on python-dev. The release
manager gave approval for this change during that discussion [1].
Changes needed:
- remove Py3k warnings from the threading module (old API is going to be
kept around even in Py3k)
- change get_name/set_name into a "name" property
- change is_daemon/set_daemon into a "daemon" property
(Note that changing "is_alive" to be a property is not on that list -
that can be a fairly expensive thing to check for the multiprocessing
library. I also left out active_count(), as I think the underscore adds
clarity in that case)
[1] http://mail.python.org/pipermail/python-dev/2008-June/080285.html
----------
components: Library (Lib)
messages: 69647
nosy: ncoghlan
priority: release blocker
severity: normal
status: open
title: Deficiencies in multiprocessing/threading API
type: behavior
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________
From report at bugs.python.org Mon Jul 14 13:33:16 2008
From: report at bugs.python.org (Fredrik Lundh)
Date: Mon, 14 Jul 2008 11:33:16 +0000
Subject: [New-bugs-announce] [issue3353] make built-in tokenizer available
via Python C API
In-Reply-To: <1216035196.11.0.15913194841.issue3353@psf.upfronthosting.co.za>
Message-ID: <1216035196.11.0.15913194841.issue3353@psf.upfronthosting.co.za>
New submission from Fredrik Lundh <effbot at users.sourceforge.net>:
CPython provides a Python-level API to the parser, but not to the
tokenizer itself. Somewhat annoyingly, it does provide a nice C API,
but that's not properly exposed for external modules.
To fix this, the tokenizer.h file should be moved from the Parser
directory to the Include directory, and the (semi-public) functions that
already available must be flagged with PyAPI_FUNC, as shown below.
The PyAPI_FUNC fix should be non-intrusive enough to go into 2.6 and
3.0; moving stuff around is perhaps better left for a later release
(which could also include a Python binding).
Index: tokenizer.h
===================================================================
--- tokenizer.h (revision 514)
+++ tokenizer.h (working copy)
@@ -54,10 +54,10 @@
const char* str;
};
-extern struct tok_state *PyTokenizer_FromString(const char *);
-extern struct tok_state *PyTokenizer_FromFile(FILE *, char *, char *);
-extern void PyTokenizer_Free(struct tok_state *);
-extern int PyTokenizer_Get(struct tok_state *, char **, char **);
+PyAPI_FUNC(struct tok_state *) PyTokenizer_FromString(const char *);
+PyAPI_FUNC(struct tok_state *) PyTokenizer_FromFile(FILE *, char *,
char *);
+PyAPI_FUNC(void) PyTokenizer_Free(struct tok_state *);
+PyAPI_FUNC(int) PyTokenizer_Get(struct tok_state *, char **, char **);
#ifdef __cplusplus
}
----------
components: Interpreter Core
messages: 69650
nosy: effbot
severity: normal
status: open
title: make built-in tokenizer available via Python C API
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3353>
_______________________________________
From report at bugs.python.org Mon Jul 14 14:54:23 2008
From: report at bugs.python.org (Christoph Zwerschke)
Date: Mon, 14 Jul 2008 12:54:23 +0000
Subject: [New-bugs-announce] [issue3354] sort(reverse=None) prints
misleading error message
In-Reply-To: <1216040063.73.0.634067891199.issue3354@psf.upfronthosting.co.za>
Message-ID: <1216040063.73.0.634067891199.issue3354@psf.upfronthosting.co.za>
New submission from Christoph Zwerschke <cito at online.de>:
When you sort a list with list.sort() or sorted(list), and set the
reverse parameter to None, then you get the following misleading error
message:
TypeError: an integer is required
I would expect a more proper error message for the reverse parameter,
such as "reverse must be a boolean", and maybe reverse=None also
accepted as default value, i.e. False.
----------
components: Interpreter Core
messages: 69651
nosy: cito
severity: normal
status: open
title: sort(reverse=None) prints misleading error message
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3354>
_______________________________________
From report at bugs.python.org Mon Jul 14 21:31:42 2008
From: report at bugs.python.org (Kumar McMillan)
Date: Mon, 14 Jul 2008 19:31:42 +0000
Subject: [New-bugs-announce] [issue3355] Display bug in :show-inheritance:
for class with standard docstring
In-Reply-To: <1216063902.37.0.436580561453.issue3355@psf.upfronthosting.co.za>
Message-ID: <1216063902.37.0.436580561453.issue3355@psf.upfronthosting.co.za>
New submission from Kumar McMillan <kumar.mcmillan at gmail.com>:
Using Sphinx 0.4.1 I noticed a slight display bug in rendering
:show-inheritance: for a class with a PEP 8 / PEP 257 style docstring.
i.e. multi-line docstrings are recommended by the PEPs to look like:
class Foo(SomeFoo):
"""Return a foobang
Optional plotz says to frobnicate the bizbaz first.
"""
Using Sphinx autodoc extension, the default skin, and...
.. autoclass:: path.to.Foo
:show-inheritance:
...will show a link to bases but immediately after it (no line break) is
the first line of the doc. This is confusing to read. However,
changing the docstring of the class to add a break like:
class Foo(SomeFoo):
"""
Return a foobang
Optional plotz says to frobnicate the bizbaz first.
"""
fixes the problem.
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 69660
nosy: georg.brandl, kumar303
severity: normal
status: open
title: Display bug in :show-inheritance: for class with standard docstring
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3355>
_______________________________________
From report at bugs.python.org Mon Jul 14 23:15:29 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Jul 2008 21:15:29 +0000
Subject: [New-bugs-announce] [issue3356] some tests fail in debug mode
(test_distutils, test_set)
In-Reply-To: <1216070128.91.0.762620118024.issue3356@psf.upfronthosting.co.za>
Message-ID: <1216070128.91.0.762620118024.issue3356@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
With the latest py3k, some tests fail when run in debug mode:
- test_distutils fails with the following message:
FAILED (errors=1)
Traceback (most recent call last):
File "Lib/test/test_distutils.py", line 17, in <module>
test_main()
File "Lib/test/test_distutils.py", line 13, in test_main
test.support.run_unittest(distutils.tests.test_suite())
File "/home/antoine/py3k/pristine/Lib/test/support.py", line 717, in
run_unittest
_run_suite(suite)
File "/home/antoine/py3k/pristine/Lib/test/support.py", line 700, in
_run_suite
raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
File
"/home/antoine/py3k/pristine/Lib/distutils/tests/test_build_ext.py",
line 48, in test_build_ext
import xx
AttributeError: mro
- test_set crashes with the following message:
./python Lib/test/test_set.py
test_add (__main__.TestSet) ... ok
test_and (__main__.TestSet) ... ok
test_badcmp (__main__.TestSet) ... ok
test_c_api (__main__.TestSet) ... Fatal Python error:
Objects/setobject.c:2429 object at 0xb797ce04 has negative ref count -1
Abandon
----------
components: Tests
messages: 69661
nosy: pitrou
severity: normal
status: open
title: some tests fail in debug mode (test_distutils, test_set)
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3356>
_______________________________________
From report at bugs.python.org Tue Jul 15 01:37:51 2008
From: report at bugs.python.org (Chester)
Date: Mon, 14 Jul 2008 23:37:51 +0000
Subject: [New-bugs-announce] [issue3357] A bug in the __doc__ string of the
sys module
In-Reply-To: <1216078670.93.0.80327541443.issue3357@psf.upfronthosting.co.za>
Message-ID: <1216078670.93.0.80327541443.issue3357@psf.upfronthosting.co.za>
New submission from Chester <wxpythoner at gmail.com>:
This relates to Python 3.x. Do this please:
import sys; print(sys.__doc__)
Please fix the following line of text in that __doc__ file of the sys
module:
stdin -- standard input file object; used by raw_input() and input()
This line of text should just be
stdin -- standard input file object; used by input()
because raw_input() does not exist anymore in Python 3.x.
----------
assignee: georg.brandl
components: Documentation
messages: 69668
nosy: cheDu, georg.brandl
severity: normal
status: open
title: A bug in the __doc__ string of the sys module
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3357>
_______________________________________
From report at bugs.python.org Tue Jul 15 06:12:29 2008
From: report at bugs.python.org (Nick Edds)
Date: Tue, 15 Jul 2008 04:12:29 +0000
Subject: [New-bugs-announce] [issue3358] 2to3 Iterative Wildcard Matching
In-Reply-To: <1216095149.85.0.174459482366.issue3358@psf.upfronthosting.co.za>
Message-ID: <1216095149.85.0.174459482366.issue3358@psf.upfronthosting.co.za>
New submission from Nick Edds <nedds at uchicago.edu>:
Here is an iterative replacement to _recursive_matches for Wildcard
Patterns. It's not really much faster now, although I think there is
some room to improve it. It's doesn't seem like the most elegant
solution, but it works. It passes all of the tests, although I had to
rewrite one because it was generating the same matches but in a
different order.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: iterative.diff
keywords: patch
messages: 69672
nosy: collinwinter, nedds
severity: normal
status: open
title: 2to3 Iterative Wildcard Matching
Added file: http://bugs.python.org/file10896/iterative.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3358>
_______________________________________
From report at bugs.python.org Tue Jul 15 07:21:49 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 15 Jul 2008 05:21:49 +0000
Subject: [New-bugs-announce] [issue3359] add 'rbU' mode to open()
In-Reply-To: <1216099309.77.0.222118246424.issue3359@psf.upfronthosting.co.za>
Message-ID: <1216099309.77.0.222118246424.issue3359@psf.upfronthosting.co.za>
New submission from anatoly techtonik <techtonik at gmail.com>:
'rU' universal newline support is useless, because read lines end with
'\n' regardless of actual line end in the source file. Applications that
care about line ends still open file in binary mode and gather the stats
manually.
So, to make this mode useful - the 'rbU' should be addded. Otherwise it
doesn't worth complication both in C code and in documentation.
----------
components: Library (Lib)
messages: 69673
nosy: techtonik
severity: normal
status: open
title: add 'rbU' mode to open()
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3359>
_______________________________________
From report at bugs.python.org Tue Jul 15 12:45:38 2008
From: report at bugs.python.org (Richard B. Kreckel)
Date: Tue, 15 Jul 2008 10:45:38 +0000
Subject: [New-bugs-announce] [issue3360] Inconsistent type-deduction of
decimal floating-point
In-Reply-To: <1216118738.54.0.735219671466.issue3360@psf.upfronthosting.co.za>
Message-ID: <1216118738.54.0.735219671466.issue3360@psf.upfronthosting.co.za>
New submission from Richard B. Kreckel <richyk at users.sourceforge.net>:
When constructing a floating-point value, literals are apparently
sometimes interpreted as octal integral types, although they contain
exponent marker or/and decimal point. The presence of exponent marker
or/and decimal point should suffice to identify it as floating-point.
Example:
>>> x = 02120246124e0
>>> x = 02120246124.0
>>> x = 021202461241e0
ValueError: invalid literal for long() with base 8: '021202461241e0'
>>> x = 021202461241.0
ValueError: invalid literal for long() with base 8: '021202461241.0'
I am using Python 2.5.1 from openSuSE 10.3.
----------
components: Interpreter Core
messages: 69677
nosy: richyk
severity: normal
status: open
title: Inconsistent type-deduction of decimal floating-point
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3360>
_______________________________________
From report at bugs.python.org Tue Jul 15 13:54:55 2008
From: report at bugs.python.org (Wolfgang Langner)
Date: Tue, 15 Jul 2008 11:54:55 +0000
Subject: [New-bugs-announce] [issue3361] pypi issue tracker link (python.org)
In-Reply-To: <1216122895.94.0.048597402598.issue3361@psf.upfronthosting.co.za>
Message-ID: <1216122895.94.0.048597402598.issue3361@psf.upfronthosting.co.za>
New submission from Wolfgang Langner <tds333 at gmail.com>:
Some links still point to the sourceforge bug tracker.
(one from http://pypi.python.org/pypi bug reports).
Check if there are others and let them point to the new bug tracker.
----------
components: None
messages: 69680
nosy: tds333
severity: normal
status: open
title: pypi issue tracker link (python.org)
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3361>
_______________________________________
From report at bugs.python.org Tue Jul 15 16:22:30 2008
From: report at bugs.python.org (cfr)
Date: Tue, 15 Jul 2008 14:22:30 +0000
Subject: [New-bugs-announce] [issue3362] locale.getpreferredencoding() gives
bus error on Mac OS X 10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
New submission from cfr <margali at imapmail.org>:
Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007;
root:xnu-792.24.17~1/RELEASE_PPC
Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, sys, locale
>>> locale.getpreferredencoding()
Bus error
Sample crash report excerpt follows (plenty more available on request!).
Note that the version of python given in the crash report is *not* the
same as the version of python actually in use. I have never had an alpha
version of python installed. The current version is the standard version
of 2.5.2 available as a dmg download from python.org i.e. the universal
framework build for 10.4.
OS Version: 10.4.11 (Build 8S165)
Report Version: 4
Command: Python
Path:
/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python
Parent: bash [27154]
Version: 2.5a0 (2.5alpha0)
PID: 4692
Thread: 0
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000
Thread 0 Crashed:
0 com.apple.CoreFoundation 0x907beac0 CFStringGetCStringPtr + 408
1 _locale.so 0x000f1cd8 PyLocale_getdefaultlocale + 328
(_localemodule.c:435)
2 org.python.python 0x002b393c PyEval_EvalFrameEx + 17036
(ceval.c:3557)
3 org.python.python 0x002b5e50 PyEval_EvalCodeEx + 2096
(ceval.c:2836)
4 org.python.python 0x002b3f48 PyEval_EvalFrameEx + 18584
(ceval.c:3669)
5 org.python.python 0x002b5e50 PyEval_EvalCodeEx + 2096
(ceval.c:2836)
6 org.python.python 0x002b5ff0 PyEval_EvalCode + 48 (ceval.c:500)
7 org.python.python 0x002dbb24 PyRun_InteractiveOneFlags + 772
(pythonrun.c:1274)
8 org.python.python 0x002dbd30 PyRun_InteractiveLoopFlags +
288 (pythonrun.c:725)
9 org.python.python 0x002dc3f0 PyRun_AnyFileExFlags + 176
(pythonrun.c:693)
10 org.python.python 0x002eba9c Py_Main + 3052 (main.c:523)
11 org.python.python 0x000019bc 0x1000 + 2492
12 org.python.python 0x000016c0 0x1000 + 1728
Thread 0 crashed with PPC Thread State 64:
srr0: 0x00000000907beac0 srr1: 0x000000000000d030
vrsave: 0x0000000000000000
cr: 0x84244224 xer: 0x0000000020000004 lr:
0x00000000907be930 ctr: 0x00000000907be928
r0: 0x00000000a07bb678 r1: 0x00000000bfffd3a0 r2:
0x00000000a07bb278 r3: 0x0000000000000000
r4: 0x0000000000000000 r5: 0x00000000bfffd2e0 r6:
0x0000000000000005 r7: 0x0000000000000007
r8: 0x0000000000702333 r9: 0x000000000000001c r10:
0x0000000090bb4bb8 r11: 0x00000000000f33d8
r12: 0x00000000907be928 r13: 0x0000000000058b24 r14:
0x0000000000071e40 r15: 0x000000000006aa20
r16: 0x0000000000000000 r17: 0x0000000000000001 r18:
0x00000000000732a8 r19: 0x0000000000619410
r20: 0x0000000000000000 r21: 0x000000000006a9b0 r22:
0x0000000000000000 r23: 0x0000000000058b39
r24: 0x00000000000f1b90 r25: 0x00000000006001d0 r26:
0x000000000007e300 r27: 0x0000000000000000
r28: 0x0000000000000000 r29: 0x00000000a07bbb6c r30:
0x0000000000000000 r31: 0x00000000907be930
Binary Images Description:
0x1000 - 0x1fff org.python.python 2.5a0 (2.5alpha0)
/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python
0xa2000 - 0xd9fff readline.so
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/readline.so
0xf0000 - 0xf2fff _locale.so
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_locale.so
0x205000 - 0x323fff org.python.python 2.5a0 (2.5)
/Library/Frameworks/Python.framework/Versions/2.5/Python
0x705000 - 0x74afff libncurses.5.dylib
/Library/Frameworks/Python.framework/Versions/2.5/lib/libncurses.5.dylib
0x7de000 - 0x7e1fff operator.so
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/operator.so
0x8fe00000 - 0x8fe52fff dyld 46.16 /usr/lib/dyld
0x90000000 - 0x901bcfff libSystem.B.dylib /usr/lib/libSystem.B.dylib
0x90214000 - 0x90219fff libmathCommon.A.dylib
/usr/lib/system/libmathCommon.A.dylib
0x907bb000 - 0x90895fff com.apple.CoreFoundation 6.4.11 (368.35)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x908e0000 - 0x909e2fff libicucore.A.dylib /usr/lib/libicucore.A.dylib
0x90a3c000 - 0x90ac0fff libobjc.A.dylib /usr/lib/libobjc.A.dylib
0x90aea000 - 0x90b5afff com.apple.framework.IOKit 1.4 (???)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
0x90b70000 - 0x90b82fff libauto.dylib /usr/lib/libauto.dylib
0x90b89000 - 0x90e60fff com.apple.CoreServices.CarbonCore 681.17
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
0x91111000 - 0x9111ffff libz.1.dylib /usr/lib/libz.1.dylib
0x91122000 - 0x912ddfff com.apple.security 4.6 (29770)
/System/Library/Frameworks/Security.framework/Versions/A/Security
0x913dc000 - 0x913e5fff com.apple.DiskArbitration 2.1.2
/System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
0x913ec000 - 0x913f4fff libbsm.dylib /usr/lib/libbsm.dylib
0x913f8000 - 0x91420fff com.apple.SystemConfiguration 1.8.3
/System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
0x91433000 - 0x9143efff libgcc_s.1.dylib /usr/lib/libgcc_s.1.dylib
0x945e4000 - 0x94604fff libmx.A.dylib /usr/lib/libmx.A.dylib
I have got as far as I can tracking this issue down but would be happy
to provide further information if somebody would give me (a pointer to)
instructions or a hint.
----------
messages: 69683
nosy: cfr
severity: normal
status: open
title: locale.getpreferredencoding() gives bus error on Mac OS X 10.4.11 PPC
type: crash
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________
From report at bugs.python.org Tue Jul 15 16:36:51 2008
From: report at bugs.python.org (cfr)
Date: Tue, 15 Jul 2008 14:36:51 +0000
Subject: [New-bugs-announce] [issue3363] python version incorrectly reported
in crash reports on Mac OS X 10.4.11 PPC
In-Reply-To: <1216132611.85.0.270586001312.issue3363@psf.upfronthosting.co.za>
Message-ID: <1216132611.85.0.270586001312.issue3363@psf.upfronthosting.co.za>
New submission from cfr <margali at imapmail.org>:
Although the active version of python on my machine is 2.5.2 and I have
never had an alpha version installed, crash reports for python report
the version as "2.5a0 (2.5alpha0)".
Version details: active version of python is from the current python.org
dmg download for Mac OS X 10.4 i.e. the universal framework build. When
starting python, I get:
Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
but in crash reports, I get:
Command: Python
Path:
/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python
Parent: bash [27154]
Version: 2.5a0 (2.5alpha0)
and python is given as version 2.5a0 in the binary image listing which
follows.
Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007;
root:xnu-792.24.17~1/RELEASE_PPC
I think I did have 2.5.1 installed prior to installing 2.5.2 and I also
have two older versions of python installed - 2.4 (also the python.org
build) and 2.3 (as pre-installed by Apple) - but I never installed 2.5.0
or any version/candidate in the 2.5 line prior to 2.5.1.
I'm not sure what further information might be helpful but would be
happy to provide it on request.
----------
components: None
messages: 69686
nosy: cfr
severity: normal
status: open
title: python version incorrectly reported in crash reports on Mac OS X 10.4.11 PPC
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3363>
_______________________________________
From report at bugs.python.org Tue Jul 15 17:23:58 2008
From: report at bugs.python.org (Chester)
Date: Tue, 15 Jul 2008 15:23:58 +0000
Subject: [New-bugs-announce] [issue3364] An ortographical typo in Zen of
Python text
In-Reply-To: <1216135438.83.0.733910076537.issue3364@psf.upfronthosting.co.za>
Message-ID: <1216135438.83.0.733910076537.issue3364@psf.upfronthosting.co.za>
New submission from Chester <wxpythoner at gmail.com>:
I hope I chose the correct component type for this issue report. Anyway,
if you do import this in the Python 3.x interactive interpreter, you
get the Zen of Python by Tim Peters. This text has a line which has an
ortographical typo in it. Please look at this line of text from the Zen
of Python:
There should be one-- and preferably only one --obvious way to do it.
Now this line has the typo I am talking about, and the typo is the lack
of a space before the first dash (actually before the double-hyphen) and
the space after the second dash (or double-hyphen).
Please note that the dash punctuation mark is by ortographical rules
separated from the words, so there are two spaces separating a dash from
the surrounding words. By writing the dashes in the way that are in the
above sentence from the Zen of Python, we don't achieve any effect as
sometimes ortographical rules can be broken to create some special
effect in the sentence (like in a line that uses the asteriskes to
emphasize the word 'right' with writing it as *right*), but here in the
above line it is clearly a normal sentence, not needing any special
effect, which is also incorrect from this point of view. So please fix
the above line like this:
There should be one -- and preferably only one -- obvious way to do it.
Consider the fact that the last sentence is written correctly and that
the dash in it is separated from the surrounding words as the
ortographic rules demand. So having one line of text with an incorrectly
used dash and some other line with the correctly used dash, makes the
whole text either inconsistent or just bad. Okay, it isn't *really* bad
but it's incorrect and it needs a little fix. And it's not too much
trouble to add two missing spaces in that line of text.
I think that ortography is our friend in the Python world. ;)
----------
assignee: georg.brandl
components: Documentation
messages: 69688
nosy: cheDu, georg.brandl
severity: normal
status: open
title: An ortographical typo in Zen of Python text
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3364>
_______________________________________
From report at bugs.python.org Tue Jul 15 18:13:45 2008
From: report at bugs.python.org (TanaT)
Date: Tue, 15 Jul 2008 16:13:45 +0000
Subject: [New-bugs-announce] [issue3365] in module math,
PI value seems to be wrong after digit 17th
In-Reply-To: <1216138425.08.0.91328396117.issue3365@psf.upfronthosting.co.za>
Message-ID: <1216138425.08.0.91328396117.issue3365@psf.upfronthosting.co.za>
New submission from TanaT <anatole.ng at free.fr>:
Hello,
This is my first Issue creation (I looked for "PI" in issue tracker and
found nothing): Please forgive any mistake.
Here is the point :
I typed the following commands :
>>> import math
>>> print '%1.26f' % math.pi
3.14159265358979311599796347
In fact, PI value is
3,14159265358979323846264338327950288...
^
I don't know if PI value is computed in Python : If it is, this issue is
probably already dead ! But if PI is just saved in math library, there
could be an improvement.
----------
components: None
messages: 69693
nosy: TanaT
severity: normal
status: open
title: in module math, PI value seems to be wrong after digit 17th
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3365>
_______________________________________
From report at bugs.python.org Tue Jul 15 19:37:54 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 15 Jul 2008 17:37:54 +0000
Subject: [New-bugs-announce] [issue3366] Add gamma and error functions to
math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
>From Py3000 list: in C99 standard math library, but need code when not
yet in particular implementation.
Dickinson: open and assign to me
Stutzbach: I suggest using the versions from newlib's libm. They contain
extensive comments explaining the math and have a generous license,
e.g.,:
http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/newlib/libm/math/s_erf.c?rev=1.1.1.1&cvsroot=src
----------
assignee: marketdickinson
components: Library (Lib)
messages: 69698
nosy: marketdickinson, tjreedy
severity: normal
status: open
title: Add gamma and error functions to math module
type: feature request
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________
From report at bugs.python.org Tue Jul 15 22:21:04 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 15 Jul 2008 20:21:04 +0000
Subject: [New-bugs-announce] [issue3367] Uninitialized value read in
parsetok.c
In-Reply-To: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za>
Message-ID: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za>
New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:
If a PyTokenizer_FromString() is called with an empty string, the
tokenizer's line_start member never gets initialized. Later, it is
compared with the token pointer 'a' in parsetok.c:193 and that behavior
can result in undefined behavior.
Found using Rational Purify for windows.
A patch is provided.
----------
files: tmp1.patch
keywords: easy, patch, patch
messages: 69714
nosy: krisvale
severity: normal
status: open
title: Uninitialized value read in parsetok.c
type: crash
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file10898/tmp1.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3367>
_______________________________________
From report at bugs.python.org Tue Jul 15 23:18:36 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 15 Jul 2008 21:18:36 +0000
Subject: [New-bugs-announce] [issue3368] Memory leak in import.c
In-Reply-To: <1216156715.63.0.327674060431.issue3368@psf.upfronthosting.co.za>
Message-ID: <1216156715.63.0.327674060431.issue3368@psf.upfronthosting.co.za>
New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:
Failure to deallocate a buffer returned by PyArg_ParseTuple. Patch is
attached.
Found using purify while running the testsuite.
----------
components: Interpreter Core
files: tmp3.patch
keywords: easy, patch, patch
messages: 69719
nosy: krisvale
severity: normal
status: open
title: Memory leak in import.c
type: resource usage
versions: Python 3.0
Added file: http://bugs.python.org/file10900/tmp3.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3368>
_______________________________________
From report at bugs.python.org Tue Jul 15 23:42:26 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 15 Jul 2008 21:42:26 +0000
Subject: [New-bugs-announce] [issue3369] memory leak in floatobject.c
In-Reply-To: <1216158146.44.0.605906648697.issue3369@psf.upfronthosting.co.za>
Message-ID: <1216158146.44.0.605906648697.issue3369@psf.upfronthosting.co.za>
New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:
When a nan or inf is generated in PyFloat_FromString(), a temporary
buffer may be left behind.
Patch attached.
Found using Purify
----------
components: Interpreter Core
files: tmp4.patch
keywords: easy, patch, patch
messages: 69721
nosy: krisvale
severity: normal
status: open
title: memory leak in floatobject.c
versions: Python 3.0
Added file: http://bugs.python.org/file10901/tmp4.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3369>
_______________________________________
From report at bugs.python.org Wed Jul 16 00:20:35 2008
From: report at bugs.python.org (Matt McCredie)
Date: Tue, 15 Jul 2008 22:20:35 +0000
Subject: [New-bugs-announce] [issue3370] importing with_statement causes
exec to raise syntax error on block that doesn't end with a newline
In-Reply-To: <1216160435.89.0.00837821764809.issue3370@psf.upfronthosting.co.za>
Message-ID: <1216160435.89.0.00837821764809.issue3370@psf.upfronthosting.co.za>
New submission from Matt McCredie <mccredie at gmail.com>:
The following session demonstrates the issue:
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> exec "def foo():\n return 0" # no ending newline works fine
>>> foo()
0
>>> exec "def foo():\n return 1\n" # with an ending newline works fine
>>> foo()
1
>>> from __future__ import with_statement
>>> exec "def foo():\n return 2\n" # with an ending newline works fine
>>> foo()
2
>>> exec "def foo():\n return 3" # without an ending new line... breaks
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<string>", line 2
return 3
^
Possibly related to http://bugs.python.org/issue1184112, and/or
http://bugs.python.org/issue501622?
----------
components: Interpreter Core
messages: 69723
nosy: mccredie
severity: normal
status: open
title: importing with_statement causes exec to raise syntax error on block that doesn't end with a newline
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3370>
_______________________________________
From report at bugs.python.org Wed Jul 16 02:43:21 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 16 Jul 2008 00:43:21 +0000
Subject: [New-bugs-announce] [issue3371] 2to3 fails in 3.0
In-Reply-To: <1216169000.89.0.760925627097.issue3371@psf.upfronthosting.co.za>
Message-ID: <1216169000.89.0.760925627097.issue3371@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
I'm disabling lib2to3 in the trunk because it fails just for Python 2.6.
(Python 2.5 and 3.0 are fine.)
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 69739
nosy: benjamin.peterson, collinwinter
priority: deferred blocker
severity: normal
status: open
title: 2to3 fails in 3.0
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3371>
_______________________________________
From report at bugs.python.org Wed Jul 16 03:38:52 2008
From: report at bugs.python.org (Niall O'Higgins)
Date: Wed, 16 Jul 2008 01:38:52 +0000
Subject: [New-bugs-announce] [issue3372] socket.setsockopt() is broken for
multicast TTL and Loop options
In-Reply-To: <1216172332.9.0.582364259682.issue3372@psf.upfronthosting.co.za>
Message-ID: <1216172332.9.0.582364259682.issue3372@psf.upfronthosting.co.za>
New submission from Niall O'Higgins <niallo at unworkable.org>:
socket.setsockopt() sets an optlen of '4' in the setsockopt system call
for options IP_MULTICAST_TTL and IP_MULTICAST_LOOP. On OpenBSD, this
causes the kernel to hit an error condition and set errno 22 when these
options are set:
socket.error: (22, 'Invalid argument')
Yielded by e.g. socket.setsockopt(socket.IPPROTO_IP,
socket.IP_MULTICAST_TTL, 1)
According to both FreeBSD and OpenBSD manual pages (see e.g.
http://www.freebsd.org/cgi/man.cgi?query=ip&apropos=0&sektion=0&manpath=FreeBSD+7.0-RELEASE&format=html),
these fields are in fact both 8 bit unsigned, and the manuals suggest
the following:
u_char ttl; /* range: 0 to 255, default = 1 */
setsockopt(s, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, sizeof(ttl));
While '4' (sizeof int) is correct for many options, special casing is
needed in Modules/socketmodule.c. The following diff fixes the issue
for me on OpenBSD:
@@ -1716,12 +1719,8 @@ sock_setsockopt(PySocketSockObject *s, PyObject
*args)
if (PyArg_ParseTuple(args, "iii:setsockopt",
&level, &optname, &flag)) {
- buflen = sizeof flag;
- /* Multi cast options take shorter arguments */
- if (optname == IP_MULTICAST_TTL
- || optname == IP_MULTICAST_LOOP)
- buflen = sizeof(u_char);
buf = (char *) &flag;
+ buflen = sizeof flag;
}
else {
PyErr_Clear();
----------
components: Library (Lib)
messages: 69741
nosy: niallo
severity: normal
status: open
title: socket.setsockopt() is broken for multicast TTL and Loop options
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3372>
_______________________________________
From report at bugs.python.org Wed Jul 16 06:01:53 2008
From: report at bugs.python.org (Darryl Dixon)
Date: Wed, 16 Jul 2008 04:01:53 +0000
Subject: [New-bugs-announce] [issue3373] sys recursion limit a lot shorter
on trunk?
In-Reply-To: <1216180913.45.0.197012518683.issue3373@psf.upfronthosting.co.za>
Message-ID: <1216180913.45.0.197012518683.issue3373@psf.upfronthosting.co.za>
New submission from Darryl Dixon <esrever_otua at winterhouseconsulting.com>:
The system recursion limit seems to be wildly different in its behaviour
on 2.6/trunk versus, for example, 2.5 or 2.4, EG:
On Python 2.4:
Python 2.4.3 (#1, Dec 11 2006, 11:38:52)
[GCC 4.1.1 20061130 (Red Hat 4.1.1-43)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class rec(object):
... child = None
... def __init__(self, counter):
... if counter > 0:
... self.child = rec(counter-1)
...
>>> mychain = rec(998)
>>>
On Python 2.6/trunk:
Python 2.6b1+ (trunk:64998, Jul 16 2008, 15:50:22)
[GCC 4.1.1 20070105 (Red Hat 4.1.1-52)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class rec(object):
... child = None
... def __init__(self, counter):
... if counter > 0:
... self.child = rec(counter-1)
...
>>> mychain = rec(249)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 5, in __init__
[...snip...]
File "<stdin>", line 5, in __init__
RuntimeError: maximum recursion depth exceeded
>>>
In both cases sys.getrecursionlimit() shows 1000.
Is this behaviour intentional? It looks a lot like a regression of some
sort. It appears to be effectively 4x shorter when creating the nested
object graph.
----------
components: Interpreter Core
messages: 69758
nosy: esrever_otua
severity: normal
status: open
title: sys recursion limit a lot shorter on trunk?
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3373>
_______________________________________
From report at bugs.python.org Wed Jul 16 14:21:36 2008
From: report at bugs.python.org (Dan Uznanski)
Date: Wed, 16 Jul 2008 12:21:36 +0000
Subject: [New-bugs-announce] [issue3374] Bisect upgrades: key/cmp/reverse,
parameterized handedness
In-Reply-To: <1216210896.71.0.891255870146.issue3374@psf.upfronthosting.co.za>
Message-ID: <1216210896.71.0.891255870146.issue3374@psf.upfronthosting.co.za>
New submission from Dan Uznanski <duznanski at gmail.com>:
Attached find a unified diff that upgrades the bisect module in two
important ways:
1. bisect and friends now understand cmp, key, and reverse, the same way
that list.sort does.
2. bisect and insort now have parameterized handedness: instead of using
two different functions depending on whether you want new items to show
up before or after existing ones, bisect and insort now take a flag
called 'right' which can change the handedness on the fly.
Currently this code fails two existing regression tests:
test_backcompatibility, because bisect is no longer the same as
bisect_right; and test_non_sequence, because insort now raises
AttributeError instead of TypeError when called on an int.
Still to do, in order of priority as perceived by me:
1. A C version of the code needs to be written.
2. The error handling should be worked over by somebody with more
knowledge than I - the regression tests assume that particular failures
(len-only, get-only, and non-sequence) will happen with one of TypeError
or AttributeError when in reality they may raise the other.
3. The tests for new functionality should be made more exhaustive.
4. The in-module documentation probably needs cleaning; the rst
documentation needs my name added to it (a good deal of the existing
writing is still Fred L Drake's, so I won't replace) and needs to have
the "section 3.6.4" part linked to Mutable Sequence Types; I couldn't
find an actual example of that linkage.
5. The godawful conditions in bisect should probably get cleaned up.
----------
components: Library (Lib)
files: bisect-2.7.diff
keywords: patch
messages: 69773
nosy: dan.uznanski
severity: normal
status: open
title: Bisect upgrades: key/cmp/reverse, parameterized handedness
versions: Python 2.7
Added file: http://bugs.python.org/file10904/bisect-2.7.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3374>
_______________________________________
From report at bugs.python.org Wed Jul 16 14:57:16 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 16 Jul 2008 12:57:16 +0000
Subject: [New-bugs-announce] [issue3375] _multiprocessing.so build problems
In-Reply-To: <1216213036.27.0.498692237494.issue3375@psf.upfronthosting.co.za>
Message-ID: <1216213036.27.0.498692237494.issue3375@psf.upfronthosting.co.za>
New submission from Barry A. Warsaw <barry at python.org>:
_multiprocessing.so has build problems on both OS X 10.5 and Ubuntu
Linux 8.04. It's very strange though because there are no apparent
errors in compilation, however when the build process tries to import
the module, that fails and it gets moved to _multiprocessing_failed.so.
Interestingly enough, a subsequent 'make' succeeds, as does just
renaming the lib back to _multiprocessing.so.
Sorry, I have no more clues than that, but see also but 3088.
----------
components: Build
messages: 69777
nosy: barry
priority: release blocker
severity: normal
status: open
title: _multiprocessing.so build problems
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3375>
_______________________________________
From report at bugs.python.org Wed Jul 16 15:27:39 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Jul 2008 13:27:39 +0000
Subject: [New-bugs-announce] [issue3376] Use Python 3 lexer for 3.0 docs
Message-ID: <1216214859.34.0.300378511478.issue3376@psf.upfronthosting.co.za>
Changes by Georg Brandl <georg at python.org>:
----------
assignee: georg.brandl
components: Documentation, Documentation tools (Sphinx)
nosy: georg.brandl
priority: low
severity: normal
status: open
title: Use Python 3 lexer for 3.0 docs
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3376>
_______________________________________
From report at bugs.python.org Wed Jul 16 15:44:27 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 16 Jul 2008 13:44:27 +0000
Subject: [New-bugs-announce] [issue3377] Invalid child node access in ast.c
In-Reply-To: <1216215867.69.0.0669187139493.issue3377@psf.upfronthosting.co.za>
Message-ID: <1216215867.69.0.0669187139493.issue3377@psf.upfronthosting.co.za>
New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:
Purify complained about reading uninitialized memory in ast.c:752 of
two bytes which corresponds to the type field. Looking into this, line
750 increments i without checking that there are in fact this many
children.
If you add the line:
assert(i < NCH(n));
after line 750 you get an assertion failure when you run
test_keywordonlyarg in the testsuite
----------
components: Interpreter Core
messages: 69787
nosy: krisvale
severity: normal
status: open
title: Invalid child node access in ast.c
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3377>
_______________________________________
From report at bugs.python.org Wed Jul 16 16:07:12 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 16 Jul 2008 14:07:12 +0000
Subject: [New-bugs-announce] [issue3378] Memory leak in pythonrun.c
In-Reply-To: <1216217232.24.0.010900807633.issue3378@psf.upfronthosting.co.za>
Message-ID: <1216217232.24.0.010900807633.issue3378@psf.upfronthosting.co.za>
New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:
In some cases, an error string generated by parsetok.c is not cleared
by err_input(). A patch is provided.
----------
components: Interpreter Core
files: tmp5.patch
keywords: patch, patch
messages: 69788
nosy: krisvale
severity: normal
status: open
title: Memory leak in pythonrun.c
type: resource usage
versions: Python 3.0
Added file: http://bugs.python.org/file10905/tmp5.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3378>
_______________________________________
From report at bugs.python.org Wed Jul 16 17:13:22 2008
From: report at bugs.python.org (=?utf-8?q?J._Pablo_Fern=C3=A1ndez?=)
Date: Wed, 16 Jul 2008 15:13:22 +0000
Subject: [New-bugs-announce] [issue3379] Option to not-exit on test
In-Reply-To: <1216221202.34.0.503221708594.issue3379@psf.upfronthosting.co.za>
Message-ID: <1216221202.34.0.503221708594.issue3379@psf.upfronthosting.co.za>
New submission from J. Pablo Fern?ndez <pupeno at pupeno.com>:
Added an option, called exit, that when set to false, will make the
tests not exit at the end. This is useful when you are doing Lisp-like
development having a REPL (interpreter/prompt) opened in Emacs and
running the tests over and over on it.
Currently, the tests will exit the interpreter, causing the in-Emacs
interpreter to close as well.
It is by default set to false, so the default behavior is still the
same. When set to true the default behavior shouldn't change much
because at the end of the tests you are going to exit anyway. The only
difference is that no exit code will be provided. There's actually
something else, because the Python test suite hangs in a test case when
this is set to true, but this should be of no concern, as default is false.
----------
components: Library (Lib)
files: add_avoid_exit_option.diff
keywords: patch
messages: 69791
nosy: pupeno
severity: normal
status: open
title: Option to not-exit on test
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file10906/add_avoid_exit_option.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3379>
_______________________________________
From report at bugs.python.org Wed Jul 16 18:20:56 2008
From: report at bugs.python.org (John Williams)
Date: Wed, 16 Jul 2008 16:20:56 +0000
Subject: [New-bugs-announce] [issue3380] documentation for ElementTree is
unusable
In-Reply-To: <1216225256.86.0.640649586019.issue3380@psf.upfronthosting.co.za>
Message-ID: <1216225256.86.0.640649586019.issue3380@psf.upfronthosting.co.za>
New submission from John Williams <jrw at pobox.com>:
The documentation for the xml.etree.ElementTree package
(http://www.python.org/doc/2.5/lib/module-xml.etree.ElementTree.html)
does not include the Element type (http://effbot.org/zone/element.htm),
making it impossible to use this package without referring to external
documentation.
----------
assignee: georg.brandl
components: Documentation
messages: 69796
nosy: georg.brandl, jrw at pobox.com
severity: normal
status: open
title: documentation for ElementTree is unusable
type: feature request
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3380>
_______________________________________
From report at bugs.python.org Wed Jul 16 19:37:37 2008
From: report at bugs.python.org (Trent Mick)
Date: Wed, 16 Jul 2008 17:37:37 +0000
Subject: [New-bugs-announce] [issue3381] `./configure --enable-framework
--enable-universalsdk` fails because of change in r63997
In-Reply-To: <1216229857.74.0.0779741633434.issue3381@psf.upfronthosting.co.za>
Message-ID: <1216229857.74.0.0779741633434.issue3381@psf.upfronthosting.co.za>
New submission from Trent Mick <trentm at gmail.com>:
Configuring with "--enable-universalsdk" fails on Mac OS X 10.4/x86
because of a change in r63997. This in the python trunk (i.e. the 2.6 tree).
The failure looks like this:
----------------------------
$ ./configure --enable-framework --enable-universalsdk
...
checking for log1p... no
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking for wchar_t... yes
checking size of wchar_t... configure: error: cannot compute sizeof
(wchar_t)
See `config.log' for more details.
----------------------------
And the appropriate details in config.log are:
----------------------------
...
configure:21540: checking size of wchar_t
configure:21875: gcc -o conftest -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -g -O2 -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk conftest.c >&5
/usr/bin/ld: -syslibroot: multiply specified
collect2: ld returned 1 exit status
/usr/bin/ld: -syslibroot: multiply specified
collect2: ld returned 1 exit status
lipo: can't open input file: /var/tmp//cctmsJ7u.out (No such file or
directory)
configure:21878: $? = 1
configure: program exited with status 1
configure: failed program was:
...
----------------------------
The command being run:
gcc -o conftest -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -g -O2 -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk conftest.c
is "$ac_link". Here is a dump of relevant variables at that point in
"configure":
------------------
LDFLAGS is "-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk "
CFLAGS is "-arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -g -O2"
CPPFLAGS is ""
CC is "gcc"
ac_link is "$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS
conftest.$ac_ext $LIBS >&5"
------------------
The problem is that r63997
(http://mail.python.org/pipermail/python-checkins/2008-June/070612.html)
added this line to "configure.in" for Mac OS X:
CFLAGS="${UNIVERSAL_ARCH_FLAGS} -isysroot ${UNIVERSALSDK} ${CFLAGS}"
That results in the failure above: "ld" complaining about
-isysroot/-syslibroot being specified twice on the command line.
Ronald,
What was the "build issue on OSX 10.4" that the was meant to be fixed.
Can it be fixed without that "configure" change to "CFLAGS"?
----------
components: Build
messages: 69805
nosy: ronaldoussoren, trentm
severity: normal
status: open
title: `./configure --enable-framework --enable-universalsdk` fails because of change in r63997
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3381>
_______________________________________
From report at bugs.python.org Wed Jul 16 20:28:15 2008
From: report at bugs.python.org (Eric Smith)
Date: Wed, 16 Jul 2008 18:28:15 +0000
Subject: [New-bugs-announce] [issue3382] Make '%F' and float.__format__('F')
convert results to upper case.
In-Reply-To: <1216232895.09.0.0435300563375.issue3382@psf.upfronthosting.co.za>
Message-ID: <1216232895.09.0.0435300563375.issue3382@psf.upfronthosting.co.za>
New submission from Eric Smith <eric at trueblade.com>:
See http://mail.python.org/pipermail/python-dev/2008-July/081242.html
for the discussion. Basically, 'F' did the same as 'f' because it was
assumed that neither would ever produce an exponent. But they do, for
numbers greater than about 1e50. Also, 'F' should produce 'NAN' for
cases where 'f' produces 'nan'.
----------
assignee: eric.smith
components: Interpreter Core
keywords: easy
messages: 69811
nosy: eric.smith
severity: normal
status: open
title: Make '%F' and float.__format__('F') convert results to upper case.
type: feature request
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3382>
_______________________________________
From report at bugs.python.org Wed Jul 16 20:31:53 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 16 Jul 2008 18:31:53 +0000
Subject: [New-bugs-announce] [issue3383] ctypes.util fails to find libc in
some environments
In-Reply-To: <1216233113.79.0.266532127913.issue3383@psf.upfronthosting.co.za>
Message-ID: <1216233113.79.0.266532127913.issue3383@psf.upfronthosting.co.za>
New submission from Jean-Paul Calderone <exarkun at divmod.com>:
ctypes.util assumes several things of its environment which sometimes
don't hold:
* It depends on objdump being in $PATH. If it isn't, it will fail to
read the SONAME from a library, even if it has determined the path to it.
* If it uses ldconfig (which, unlike objdumb, it assumes it knows the
full path to and doesn't rely on $PATH to find), it fails to interpret
the results because the regular expression it applies doesn't define any
groups.
The attached patch is what I used to work around these issues in one
particular environment. I don't claim the fixes to be general, and the
patch includes no unit tests.
----------
assignee: theller
components: ctypes
files: ctypes-util.patch
keywords: patch
messages: 69814
nosy: exarkun, theller
severity: normal
status: open
title: ctypes.util fails to find libc in some environments
versions: Python 2.5
Added file: http://bugs.python.org/file10910/ctypes-util.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3383>
_______________________________________
From report at bugs.python.org Wed Jul 16 20:31:55 2008
From: report at bugs.python.org (Joshua Kugler)
Date: Wed, 16 Jul 2008 18:31:55 +0000
Subject: [New-bugs-announce] [issue3384] Documentation for re.findall and
re.finditer lacks "ordering" information
In-Reply-To: <1216233115.47.0.391774668688.issue3384@psf.upfronthosting.co.za>
Message-ID: <1216233115.47.0.391774668688.issue3384@psf.upfronthosting.co.za>
New submission from Joshua Kugler <jkugler at bigfoot.com>:
According to a discussion on comp.lang.python, re.findall and
re.finditer scan strings from left to right, and returns them in the
order it found them. It would be nice to note that in documentation.
----------
assignee: georg.brandl
components: Documentation
messages: 69815
nosy: georg.brandl, jkugler
severity: normal
status: open
title: Documentation for re.findall and re.finditer lacks "ordering" information
type: feature request
versions: Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3384>
_______________________________________
From report at bugs.python.org Wed Jul 16 21:01:37 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 16 Jul 2008 19:01:37 +0000
Subject: [New-bugs-announce] [issue3385] cPickle to pickle conversion in
py3k missing methods
In-Reply-To: <1216234897.3.0.336444541402.issue3385@psf.upfronthosting.co.za>
Message-ID: <1216234897.3.0.336444541402.issue3385@psf.upfronthosting.co.za>
New submission from Jesse Noller <jnoller at gmail.com>:
I was attempting the patch for issue3125 to py3k, and in it Amaury
defines a new ForkingPickler:
from pickle import Pickler
class ForkingPickler(Pickler):
dispatch = Pickler.dispatch.copy()
This is also related to issue3350 I suspect. However, using the
pickle.Pickler module under py3k, there is no dispatch() method on the
class:
Trunk:
Python 2.6b1+ (trunk:65015M, Jul 16 2008, 10:15:51)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
>>> dir(pickle.Pickler)
['_BATCHSIZE', '__doc__', '__init__', '__module__', '_batch_appends',
'_batch_setitems', 'clear_memo', 'dispatch', 'dump', 'get', 'memoize',
'persistent_id', 'put', 'save', 'save_bool', 'save_dict',
'save_empty_tuple', 'save_float', 'save_global', 'save_inst',
'save_int', 'save_list', 'save_long', 'save_none', 'save_pers',
'save_reduce', 'save_string', 'save_tuple', 'save_unicode']
>>>
py3k:
Python 3.0b1+ (py3k:65011M, Jul 16 2008, 11:50:11)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
>>> dir(Pickler)
['__class__', '__delattr__', '__doc__', '__eq__', '__format__',
'__ge__', '__getattribute__', '__gt__', '__hash__', '__init__',
'__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__',
'__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__',
'bin', 'clear_memo', 'dump', 'fast', 'memo', 'persistent_id']
I think the fix for 3125 resolves your complaint in 3350, but is the
lack of the dispatch method intentional?
----------
assignee: alexandre.vassalotti
components: Extension Modules
messages: 69816
nosy: alexandre.vassalotti, jnoller
severity: normal
status: open
title: cPickle to pickle conversion in py3k missing methods
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3385>
_______________________________________
From report at bugs.python.org Wed Jul 16 23:10:53 2008
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 16 Jul 2008 21:10:53 +0000
Subject: [New-bugs-announce] [issue3386] distutils.sysconfig.get_python_lib
prefix argument broken
In-Reply-To: <1216242653.79.0.3968685363.issue3386@psf.upfronthosting.co.za>
Message-ID: <1216242653.79.0.3968685363.issue3386@psf.upfronthosting.co.za>
New submission from Philip Jenvey <pjenvey at users.sourceforge.net>:
get_python_lib supports an optional prefix argument:
If 'prefix' is supplied, use it instead of sys.prefix or
sys.exec_prefix -- i.e., ignore 'plat_specific'.
However the NT and OS2 platforms don't use the prefix argument when
specified.
This problem was brought up a while ago here: http://mail.python.org/pipermail/distutils-sig/2002-November/003099.html
Andrew (the OS2 maintainer) claimed in the thread that fixing this would
break OS2, but I don't see how. All callers of get_python_lib in the
stdlib don't specify a prefix anyway. Anyone calling it with a prefix
and expecting it not to be used is broken.
----------
components: Distutils
files: get_python_lib-r65033.diff
keywords: patch
messages: 69836
nosy: pjenvey
severity: normal
status: open
title: distutils.sysconfig.get_python_lib prefix argument broken
type: behavior
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10917/get_python_lib-r65033.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3386>
_______________________________________
From report at bugs.python.org Thu Jul 17 00:59:42 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 16 Jul 2008 22:59:42 +0000
Subject: [New-bugs-announce] [issue3387] undefined array passed to
CryptGenRandomBytes
In-Reply-To: <1216249182.9.0.569778250674.issue3387@psf.upfronthosting.co.za>
Message-ID: <1216249182.9.0.569778250674.issue3387@psf.upfronthosting.co.za>
New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:
The CryptGenRandomBytes uses whatever data is already in the buffer as
seed for the output. So, the buffer is effectively an in/out buffer.
Now, since we are generating random data anyway, the fact that we are
using an undefined seed for the data shouldn't matter. However, this
does create a bunch of false positives for analysis tools such as
Purify, that track the copying and usage of uninitialized data.
An easy patch is to clear the buffer before submitting it to
CryptGenRandomBytes, and is attached.
----------
components: Interpreter Core
files: tmp6.patch
keywords: easy, patch, patch
messages: 69853
nosy: krisvale
severity: normal
status: open
title: undefined array passed to CryptGenRandomBytes
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10919/tmp6.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3387>
_______________________________________
From report at bugs.python.org Thu Jul 17 01:10:45 2008
From: report at bugs.python.org (Florian Mayer)
Date: Wed, 16 Jul 2008 23:10:45 +0000
Subject: [New-bugs-announce] [issue3388] With keyword not mentioned in Input
Output tutorial
In-Reply-To: <1216249845.47.0.203384807378.issue3388@psf.upfronthosting.co.za>
Message-ID: <1216249845.47.0.203384807378.issue3388@psf.upfronthosting.co.za>
New submission from Florian Mayer <flormayer at aim.com>:
I think that the Python 3.0 Tutorial should show the reader that the
with keyword is an excellent way of reading data from a file and closing
it afterwards, even if exceptions occur.
----------
assignee: georg.brandl
components: Documentation
files: with_tutorial.patch
keywords: patch
messages: 69854
nosy: georg.brandl, segfaulthunter
severity: normal
status: open
title: With keyword not mentioned in Input Output tutorial
versions: Python 3.0
Added file: http://bugs.python.org/file10920/with_tutorial.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3388>
_______________________________________
From report at bugs.python.org Thu Jul 17 01:38:49 2008
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 16 Jul 2008 23:38:49 +0000
Subject: [New-bugs-announce] [issue3389] [PATCH] Allow custom logging
Handlers in logging config files
In-Reply-To: <1216251529.63.0.522616011962.issue3389@psf.upfronthosting.co.za>
Message-ID: <1216251529.63.0.522616011962.issue3389@psf.upfronthosting.co.za>
New submission from Philip Jenvey <pjenvey at users.sourceforge.net>:
Python 2.5 added support for specifying a custom logging Formatter class
in logging configuration files. Handler classes can also be specified,
but your choice is limited to classes that live in the logging module.
A current workaround this is to manually add your custom Handler class
to the logging module prior to loading the logging config file, but then
you're no longer driving logging configuration purely from a config file
(which is the entire point). This is particularly important for apps
that are driven entirely from a config file that also includes logging
information (such as Pylons applications)
The following patch will cause Handler classes to be resolved just like
Formatter classes if the check for the Handler class in the logging
module fails.
FYI this patch has been used in Paste (in particular for Pylons apps)
for over a year so I consider it stable
----------
components: Library (Lib)
files: logging-custom-Handler_r65033.diff
keywords: patch
messages: 69858
nosy: pjenvey, vsajip
severity: normal
status: open
title: [PATCH] Allow custom logging Handlers in logging config files
type: feature request
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10921/logging-custom-Handler_r65033.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3389>
_______________________________________
From report at bugs.python.org Thu Jul 17 09:41:41 2008
From: report at bugs.python.org (engelbert gruber)
Date: Thu, 17 Jul 2008 07:41:41 +0000
Subject: [New-bugs-announce] [issue3390] [PATCH] replace last has_key in
unittest by in operator
In-Reply-To: <1216280501.05.0.916682798552.issue3390@psf.upfronthosting.co.za>
Message-ID: <1216280501.05.0.916682798552.issue3390@psf.upfronthosting.co.za>
New submission from engelbert gruber <grubert at users.sourceforge.net>:
take the line from python-3
----------
components: Library (Lib)
files: lib_unittest-r65058
messages: 69877
nosy: grubert
severity: normal
status: open
title: [PATCH] replace last has_key in unittest by in operator
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file10925/lib_unittest-r65058
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3390>
_______________________________________
From report at bugs.python.org Thu Jul 17 11:51:55 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Thu, 17 Jul 2008 09:51:55 +0000
Subject: [New-bugs-announce] [issue3391] Idle uses old showwarning signature
In-Reply-To: <1216288315.21.0.418563087868.issue3391@psf.upfronthosting.co.za>
Message-ID: <1216288315.21.0.418563087868.issue3391@psf.upfronthosting.co.za>
New submission from Robert Schuppenies <okkotonushi at googlemail.com>:
Idle does not use the 'line' argument for its showwarning function. This
results in the DeprecationWarning "functions overriding
warnings.showwarning() must support the 'line' argument", or, when
called from within Idle "TypeError: idle_formatwarning_subproc() takes
exactly 4 arguments (5 given)".
The error can be reproduced from within Idle as well as demonstrated
with verify.py.
The attached patch applies the behavior of the default warnings
implementation.
----------
components: IDLE
files: idle.patch
keywords: patch
messages: 69879
nosy: brett.cannon, schuppenies
priority: normal
severity: normal
status: open
title: Idle uses old showwarning signature
type: behavior
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10926/idle.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3391>
_______________________________________
From report at bugs.python.org Thu Jul 17 13:25:40 2008
From: report at bugs.python.org (=?utf-8?q?Mattias_Engdeg=C3=A5rd?=)
Date: Thu, 17 Jul 2008 11:25:40 +0000
Subject: [New-bugs-announce] [issue3392] subprocess fails in select when
descriptors are large
In-Reply-To: <1216293940.59.0.136491841956.issue3392@psf.upfronthosting.co.za>
Message-ID: <1216293940.59.0.136491841956.issue3392@psf.upfronthosting.co.za>
New submission from Mattias Engdeg?rd <yorick at users.sourceforge.net>:
If the stdin/out file descriptors are too large to be used with
select(), subprocess will fail in .communicate(). Example:
# raise the fd limit to something like 2048 before running this
import subprocess
somefiles = [open("/etc/passwd") for i in xrange(2000)]
print subprocess.Popen(["date"], stdout=subprocess.PIPE).communicate()
The solution would be to use select.poll() in subprocess instead.
----------
components: Library (Lib)
messages: 69880
nosy: yorick
severity: normal
status: open
title: subprocess fails in select when descriptors are large
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3392>
_______________________________________
From report at bugs.python.org Thu Jul 17 19:02:48 2008
From: report at bugs.python.org (Trent Mick)
Date: Thu, 17 Jul 2008 17:02:48 +0000
Subject: [New-bugs-announce] [issue3393] `cd Mac && make installmacsubtree`
fails on Mac OS X < 10.5 because of r63955
In-Reply-To: <1216314168.41.0.164548516306.issue3393@psf.upfronthosting.co.za>
Message-ID: <1216314168.41.0.164548516306.issue3393@psf.upfronthosting.co.za>
New submission from Trent Mick <trentm at gmail.com>:
http://svn.python.org/view?rev=63955&view=rev
"MacOS X: Enable 4-way universal builds ..."
This revision made the following change to Mac/Makefile.in:
http://svn.python.org/view/python/trunk/Mac/Makefile.in?rev=63955&view=diff&r1=63955&r2=63954&p1=python/trunk/Mac/Makefile.in&p2=/python/trunk/Mac/Makefile.in
The last hunk (part of the "installmacsubtree" target) and a bit of the
preceding hunk uses `arch` with arguments:
---------------------------------
install_BuildApplet:
- $(RUNSHARED) $(BUILDPYTHON) $(srcdir)/scripts/BuildApplet.py \
+ $(RUNSHARED) arch -ppc -i386 $(BUILDPYTHON)
$(srcdir)/scripts/BuildApplet.py \
--destroot "$(DESTDIR)" \
- --python $(INSTALLED_PYTHONAPP) \
+
--python=$(prefix)/Resources/Python.app/Contents/MacOS/$(PYTHONFRAMEWORK)`test
-f
"$(DESTDIR)$(prefix)/Resources/Python.app/Contents/MacOS/$(PYTHONFRAMEWORK)-32"
&& echo "-32"` \
--output "$(DESTDIR)$(PYTHONAPPSDIR)/Build Applet.app" \
$(srcdir)/scripts/BuildApplet.py
@@ -225,7 +279,7 @@
done
- $(RUNSHARED) $(BUILDPYTHON) $(CACHERSRC) -v $(DESTDIR)$(MACLIBDEST)
$(DESTDIR)$(MACTOOLSDEST)
+ $(RUNSHARED) arch -ppc -i386 $(BUILDPYTHON) $(CACHERSRC) -v
$(DESTDIR)$(MACLIBDEST) $(DESTDIR)$(MACTOOLSDEST)
$(RUNSHARED) $(BUILDPYTHON) -Wi -tt $(compileall) -d $(MACTOOLSDEST)
-x badsyntax $(DESTDIR)$(MACTOOLSDEST)
$(RUNSHARED) $(BUILDPYTHON) -O -Wi -tt $(compileall) -d
$(MACTOOLSDEST) -x badsyntax $(DESTDIR)$(MACTOOLSDEST)
---------------------------------
That form of calling `arch` is only supported on Mac OS X 10.5
(Leopard), I believe.
----------------------------------
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.4.11
BuildVersion: 8S2167
$ man arch | cat
ARCH(1) BSD General Commands Manual
ARCH(1)
NAME
arch -- print architecture type
SYNOPSIS
arch
DESCRIPTION
The arch command displays the machine's architecture type.
SEE ALSO
machine(1)
Mac OS August 20, 1997
Mac OS
----------------------------------
Here is the current man page for arch (I had to look to try to see what
Ronald was trying to do with the Makefile change) :)
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/arch.1.html
I don't fully understand why the "arch -ppc -i386" is necessary for
"$(BUILDPYTHON)".
I'm not sure what the easiest solution to this would be... or if
supporting "make frameworkinstallframework" (which eventually calls this
target) on Mac OS X <10.5 is considered important enough.
Perhaps a new
RUNARCH=@RUNARCH@
could be added to Mac/Makefile.in with the associated configure support
to have that be blank unless `--with-universal-archs=all` was specified?
----------
components: Build
messages: 69890
nosy: ronaldoussoren, trentm
severity: normal
status: open
title: `cd Mac && make installmacsubtree` fails on Mac OS X < 10.5 because of r63955
type: compile error
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3393>
_______________________________________
From report at bugs.python.org Thu Jul 17 21:01:33 2008
From: report at bugs.python.org (Stephen Warren)
Date: Thu, 17 Jul 2008 19:01:33 +0000
Subject: [New-bugs-announce] [issue3394] zipfile.writestr doesn't set
external attributes, so files are extracted mode 000 on Unix
In-Reply-To: <1216321293.73.0.655472661841.issue3394@psf.upfronthosting.co.za>
Message-ID: <1216321293.73.0.655472661841.issue3394@psf.upfronthosting.co.za>
New submission from Stephen Warren <s-t-pybugs at wwwdotorg.org>:
Run the following Python script, on Unix/Linux:
==========
import zipfile
z = zipfile.ZipFile('zipbad.zip', 'w')
z.writestr('filebad.txt', 'Some content')
z.close()
z = zipfile.ZipFile('zipgood.zip', 'w')
zi = zipfile.ZipInfo('filegood.txt')
zi.external_attr = 0660 << 16L
z.writestr(zi, 'Some content')
z.close()
==========
Like this:
python testzip.py && unzip zipbad.zip && unzip zipgood.zip && ls -l
file*.txt
You'll see:
---------- 1 swarren swarren 12 2008-07-17 12:54 filebad.txt
-rw-rw---- 1 swarren swarren 12 1980-01-01 00:00 filegood.txt
Note that filebad.txt is extracted with mode 000.
The WAR (used for filegood.txt) is to pass writestr a ZipInfo class with
external_attr pre-initialized. However, writestr should perform this
assignment itself, to be consistent with write. I haven't checked, but
there's probably a bunch of other stuff in write that writestr should do
too.
----------
components: Extension Modules
messages: 69898
nosy: swarren
severity: normal
status: open
title: zipfile.writestr doesn't set external attributes, so files are extracted mode 000 on Unix
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3394>
_______________________________________
From report at bugs.python.org Thu Jul 17 22:29:07 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jul 2008 20:29:07 +0000
Subject: [New-bugs-announce] [issue3395] typo in test_multiprocessing.py:
should _debugInfo be _debug_info ?
In-Reply-To: <1216326547.53.0.561012238896.issue3395@psf.upfronthosting.co.za>
Message-ID: <1216326547.53.0.561012238896.issue3395@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
In _TestZZZNumberOfObjects in test_multiprocessing.py, at around line 1040
(this is r65075 on the trunk), there's a line:
print self.manager._debugInfo()
Should this be
print self.manager._debug_info()
?
While running test_multiprocessing directly (./python.exe
Lib/test/test_multiprocessing) I got the following traceback:
Macintosh-3:trunk dickinsm$ ./python.exe Lib/test/test_multiprocessing.py
test_array (__main__.WithProcessesTestArray) ... ok
test_getobj_getlock_obj (__main__.WithProcessesTestArray) ... ok
...
[snip lots of passing tests]
...
test_rawvalue (__main__.WithManagerTestValue) ... ok
test_value (__main__.WithManagerTestValue) ... ok
test_number_of_objects (__main__.WithManagerTestZZZNumberOfObjects) ...
ERROR
======================================================================
ERROR: test_number_of_objects (__main__.WithManagerTestZZZNumberOfObjects)
----------------------------------------------------------------------
Traceback (most recent call last):
File "Lib/test/test_multiprocessing.py", line 1040, in
test_number_of_objects
print self.manager._debugInfo()
AttributeError: 'SyncManager' object has no attribute '_debugInfo'
----------------------------------------------------------------------
Ran 121 tests in 10.446s
FAILED (errors=1)
[53431 refs]
----------
assignee: jnoller
keywords: easy
messages: 69904
nosy: jnoller, marketdickinson
severity: normal
status: open
title: typo in test_multiprocessing.py: should _debugInfo be _debug_info ?
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3395>
_______________________________________
From report at bugs.python.org Thu Jul 17 22:42:09 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Jul 2008 20:42:09 +0000
Subject: [New-bugs-announce] [issue3396] rlcompleter can't autocomplete
members of callable objects
In-Reply-To: <1216327329.3.0.446547765597.issue3396@psf.upfronthosting.co.za>
Message-ID: <1216327329.3.0.446547765597.issue3396@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
This is a regression caused by #449227. When typing e.g. "int." and then
pressing tab, none of the int members is proposed. It worked until just
before r64664.
----------
components: Library (Lib)
messages: 69905
nosy: facundobatista, pitrou
priority: normal
severity: normal
status: open
title: rlcompleter can't autocomplete members of callable objects
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3396>
_______________________________________
From report at bugs.python.org Thu Jul 17 23:31:19 2008
From: report at bugs.python.org (Barry Alan Scott)
Date: Thu, 17 Jul 2008 21:31:19 +0000
Subject: [New-bugs-announce] [issue3397] Mac 3.0 build cannot find
cachersrc.py
In-Reply-To: <1216330279.07.0.869556013571.issue3397@psf.upfronthosting.co.za>
Message-ID: <1216330279.07.0.869556013571.issue3397@psf.upfronthosting.co.za>
New submission from Barry Alan Scott <barry-scott at users.sourceforge.net>:
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.4.11
BuildVersion: 8S165
./configure --enable-framework
make
...
make install
Creating directory
/Library/Frameworks/Python.framework/Versions/3.0/Mac/Tools
DYLD_FRAMEWORK_PATH=/Users/barry/Work/Python-3.0b1: ../python.exe
./scripts/cachersrc.py -v
/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/plat-mac
/Library/Frameworks/Python.framework/Versions/3.0/Mac/Tools
../python.exe: can't open file './scripts/cachersrc.py': [Errno 2] No
such file or directory
make[1]: *** [installmacsubtree] Error 2
make: *** [frameworkinstallmaclib] Error 2
----------
components: Build
messages: 69909
nosy: barry-scott
severity: normal
status: open
title: Mac 3.0 build cannot find cachersrc.py
type: compile error
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3397>
_______________________________________
From report at bugs.python.org Thu Jul 17 23:52:22 2008
From: report at bugs.python.org (Barry Alan Scott)
Date: Thu, 17 Jul 2008 21:52:22 +0000
Subject: [New-bugs-announce] [issue3398] mac build 3.0 no MacOS module
In-Reply-To: <1216331542.61.0.235815305559.issue3398@psf.upfronthosting.co.za>
Message-ID: <1216331542.61.0.235815305559.issue3398@psf.upfronthosting.co.za>
New submission from Barry Alan Scott <barry-scott at users.sourceforge.net>:
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.4.11
BuildVersion: 8S165
./configure --enable-framework
make
...
make install
...
DYLD_FRAMEWORK_PATH=/Users/barry/Work/Python-3.0b1: ../python.exe
./scripts/BuildApplet.py \
--destroot "" \
--python
/Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app/Contents/MacOS/Python
\
--output "/Applications/Python 3.0/Build Applet.app" \
./scripts/BuildApplet.py
Traceback (most recent call last):
File "./scripts/BuildApplet.py", line 14, in <module>
import MacOS
ImportError: No module named MacOS
make[1]: *** [install_BuildApplet] Error 1
make: *** [frameworkinstallapps] Error 2
----------
components: Build
messages: 69910
nosy: barry-scott
severity: normal
status: open
title: mac build 3.0 no MacOS module
type: compile error
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3398>
_______________________________________
From report at bugs.python.org Fri Jul 18 00:22:25 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jul 2008 22:22:25 +0000
Subject: [New-bugs-announce] [issue3399] Memory corruption in
multiprocessing module, OS X 10.5.4
In-Reply-To: <1216333345.76.0.451426062448.issue3399@psf.upfronthosting.co.za>
Message-ID: <1216333345.76.0.451426062448.issue3399@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
As of revision 65077 of the trunk, I'm getting errors in
test_multiprocessing that seem to point to memory corruption in object
allocation/deallocation. The failures are intermittent, and of a
similar nature to the errors I was seeing previously, outlined in issue
3088.
The platform is OS X 10.5.4 (not a fresh install---it was an upgrade
from OS X 10.4, in case this makes any difference), running on a MacBook
Pro. I'm running a freshly checked out debug build of the trunk.
Here's what I did:
(1) make a fresh svn+ssh checkout of the trunk
(2) ./configure --with-pydebug && make
(3) ./python.exe Lib/test/test_multiprocessing.py
(4) repeat step (3) until something nasty happens.
The results vary from run to run, and 80-90% of the runs of
test_multiprocessing pass. Here are 3 of the failures I've seen,
occurring on three separate runs of test_multiprocessing.
Failure 1:
test_notify_all (__main__.WithManagerTestCondition) ... Assertion
failed: (pool->ref.count > 0), function PyObject_Free, file
Objects/obmalloc.c, line 1100.
Failure 2:
test_imap_unordered (__main__.WithManagerTestPool) ...
python.exe(32381,0xb0513000) malloc: *** error for object 0xdbdbdbdb:
pointer being reallocated was not allocated
*** set a breakpoint in malloc_error_break to debug
python.exe(32381,0xb0513000) malloc: *** error for object 0xdbdbdbdb:
Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
Fatal Python error: UNREF invalid object
ERROR
Failure 3:
test_imap_unordered (__main__.WithManagerTestPool) ... Fatal Python
error: UNREF invalid object
ERROR
I have very little (i.e. no) experience of debugging this kind of
failure, and little understanding of how the multiprocessing module
works. But I can and will follow instructions and suggestions about how
to debug this.
Stupid question: it appears from reading the comments in that file that
obmalloc.c is (intentionally) not thread-safe. Could this have anything
to do with the failures above?
----------
assignee: jnoller
components: Extension Modules
messages: 69917
nosy: jnoller, marketdickinson
severity: normal
status: open
title: Memory corruption in multiprocessing module, OS X 10.5.4
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3399>
_______________________________________
From report at bugs.python.org Fri Jul 18 00:24:17 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jul 2008 22:24:17 +0000
Subject: [New-bugs-announce] [issue3400] dis module: undocumented new
bytecodes
In-Reply-To: <1216333457.94.0.303934316374.issue3400@psf.upfronthosting.co.za>
Message-ID: <1216333457.94.0.303934316374.issue3400@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
dis / Python Bytecode Instructions is missing
UNPACK_EX
STORE_LOCALS
LOAD_BUILD_CLASS
MAKE_BYTES
which appear in dis.opname (3.0 version).
Suggestion: After entry for UNPACK_SEQUENCE(count), add
UNPACK_EX(bytepair)
Used for starred assignment. Similar to UNPACK_SEQUENCE except 1) the
lo and hi bytes of the argument are the number of unstarred targets
before and after the starred target and 2) the values between the first
lo and last hi are collected into a list for the starred target.
I deduced this because *a,b; a,*b; *a,b,c; a,*b,c; and a,b,*c as targets
produce byte pairs of 0,1; 1,0; 0,2; 1,1; and 2,0 (arguments 256, 1,
512, 257, and 2).
The other three are new since 2.5 but do not make much sense to me. I
will ask on pydev for clarification. I do not have 2.6 to check its
version of .opname to determine which of these belong there too.
----------
assignee: georg.brandl
components: Documentation
messages: 69918
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: dis module: undocumented new bytecodes
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3400>
_______________________________________
From report at bugs.python.org Fri Jul 18 01:53:34 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 17 Jul 2008 23:53:34 +0000
Subject: [New-bugs-announce] [issue3401] wsgiref can't handle unicode
environments
In-Reply-To: <1216338814.66.0.0698084133409.issue3401@psf.upfronthosting.co.za>
Message-ID: <1216338814.66.0.0698084133409.issue3401@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <benjamin.peterson at usfamily.net>:
The following errors pop up on the Windows trunk build bot because the
LIB environmental variable is unicode not str. This causes the
validation to fail.
Re-running test 'test_wsgiref' in verbose mode
testAbstractMethods (test.test_wsgiref.HandlerTests) ... ok
testBasicErrorOutput (test.test_wsgiref.HandlerTests) ... ok
testCGIEnviron (test.test_wsgiref.HandlerTests) ... ok
testContentLength (test.test_wsgiref.HandlerTests) ... ok
testEnviron (test.test_wsgiref.HandlerTests) ... ERROR
testErrorAfterOutput (test.test_wsgiref.HandlerTests) ... ok
testHeaderFormats (test.test_wsgiref.HandlerTests) ... ok
testScheme (test.test_wsgiref.HandlerTests) ... ok
testExtras (test.test_wsgiref.HeaderTests) ... ok
testMappingInterface (test.test_wsgiref.HeaderTests) ... ok
testRequireList (test.test_wsgiref.HeaderTests) ... ok
test_plain_hello (test.test_wsgiref.IntegrationTests) ... ok
test_simple_validation_error (test.test_wsgiref.IntegrationTests) ... FAIL
test_validated_hello (test.test_wsgiref.IntegrationTests) ... FAIL
testAppURIs (test.test_wsgiref.UtilityTests) ... ok
testCrossDefaults (test.test_wsgiref.UtilityTests) ... ok
testDefaults (test.test_wsgiref.UtilityTests) ... ok
testFileWrapper (test.test_wsgiref.UtilityTests) ... ok
testGuessScheme (test.test_wsgiref.UtilityTests) ... ok
testHopByHop (test.test_wsgiref.UtilityTests) ... ok
testNormalizedShifts (test.test_wsgiref.UtilityTests) ... ok
testReqURIs (test.test_wsgiref.UtilityTests) ... ok
testSimpleShifts (test.test_wsgiref.UtilityTests) ... ok
======================================================================
ERROR: testEnviron (test.test_wsgiref.HandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_wsgiref.py",
line 437, in testEnviron
self.checkOSEnviron(h)
File
"E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_wsgiref.py",
line 429, in checkOSEnviron
self.assertEqual(env[k],v)
KeyError: 'AUTH_TYPE'
======================================================================
FAIL: test_simple_validation_error (test.test_wsgiref.IntegrationTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_wsgiref.py",
line 157, in test_simple_validation_error
"AssertionError: Headers (('Content-Type', 'text/plain')) must"
AssertionError: "AssertionError: Environmental variable LIB is not a
string: <type 'unicode'> (value: u'C:\\\\Program Files\\\\Microsoft
Visual Studio 9.0\\\\VC\\\\LIB;C:\\\\Program Files\\\\Microsoft
SDKs\\\\Windows\\\\v6.0A\\\\lib;c:\\\\program files\\\\microsoft visual
studio .NET 2003\\\\vc7\\\\atlmfc\\\\lib;c:\\\\program
files\\\\microsoft visual studio .NET 2003\\\\vc7\\\\lib;c:\\\\program
files\\\\microsoft visual studio .NET
2003\\\\vc7\\\\PlatformSDK\\\\lib;C:\\\\Program Files\\\\Microsoft
Visual Studio .NET 2003\\\\SDK\\\\v1.1\\\\Lib\\\\')" != "AssertionError:
Headers (('Content-Type', 'text/plain')) must be of type list: <type
'tuple'>"
======================================================================
FAIL: test_validated_hello (test.test_wsgiref.IntegrationTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_wsgiref.py",
line 145, in test_validated_hello
self.check_hello(out, has_length=False)
File
"E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_wsgiref.py",
line 134, in check_hello
"\r\n"
AssertionError: 'HTTP/1.0 500 Dude, this is whack!\r\nDate: Thu, 17 Jul
2008 22:45:20 GMT\r\nServer: WSGIServer/0.1
Python/2.6b1+\r\nContent-Type: text/plain\r\nContent-Length: 59\r\n\r\nA
server error occurred. Please contact the administrator.' != 'HTTP/1.0
200 OK\r\nServer: WSGIServer/0.1 Python/2.6b1+\r\nContent-Type:
text/plain\r\nDate: Mon, 05 Jun 2006 18:49:54 GMT\r\n\r\nHello, world!'
----------
messages: 69929
nosy: benjamin.peterson
severity: normal
status: open
title: wsgiref can't handle unicode environments
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3401>
_______________________________________
From report at bugs.python.org Fri Jul 18 03:56:33 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 18 Jul 2008 01:56:33 +0000
Subject: [New-bugs-announce] [issue3402] test_nis is hanging on Solaris
In-Reply-To: <1216346193.57.0.216784355152.issue3402@psf.upfronthosting.co.za>
Message-ID: <1216346193.57.0.216784355152.issue3402@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <benjamin.peterson at usfamily.net>:
The 3.0 Solaris buildbot keeps hanging on test_nis.
----------
components: Tests
messages: 69931
nosy: benjamin.peterson
priority: deferred blocker
severity: normal
status: open
title: test_nis is hanging on Solaris
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3402>
_______________________________________
From report at bugs.python.org Fri Jul 18 10:41:36 2008
From: report at bugs.python.org (SukkoPera)
Date: Fri, 18 Jul 2008 08:41:36 +0000
Subject: [New-bugs-announce] [issue3403] Unexpected default arguments
behaviour
In-Reply-To: <1216370496.76.0.890911123017.issue3403@psf.upfronthosting.co.za>
Message-ID: <1216370496.76.0.890911123017.issue3403@psf.upfronthosting.co.za>
New submission from SukkoPera <sr at sukkology.net>:
I have just encountered a Python behaviour I wouldn't expect. Take
the following code:
------------------------------------------------------------------------
class Parent:
a = 1
def m (self, param = a):
print "param = %d" % param
class Child (Parent):
a = 2
p = Parent ()
p.m ()
c = Child ()
c.m ()
------------------------------------------------------------------------
I would expect to receive the following output:
param = 1
param = 2
But actually I get:
param = 1
param = 1
Is this the correct behaviour, and then why, or is it a bug? For
reference, I am using Python 2.5.1 on GNU/Linux.
There has been a short discussion about this at
http://groups.google.it/group/comp.lang.python/browse_thread/thread/9f740eea131e7ef2/56fd4e120a069a1d#56fd4e120a069a1d.
----------
components: None
messages: 69943
nosy: SukkoPera
severity: normal
status: open
title: Unexpected default arguments behaviour
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3403>
_______________________________________
From report at bugs.python.org Fri Jul 18 12:40:27 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Fri, 18 Jul 2008 10:40:27 +0000
Subject: [New-bugs-announce] [issue3404] wrong precision in float formatting
In-Reply-To: <1216377626.86.0.147099766494.issue3404@psf.upfronthosting.co.za>
Message-ID: <1216377626.86.0.147099766494.issue3404@psf.upfronthosting.co.za>
New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:
This seems to be wrong:
>>> "{0:.2}".format(1.2345)
'1.2'
The same happens for format specifiers "g" and "n", but not for "f":
>>> "{0:.2f}".format(1.2345)
'1.23'
With empty format specifier it can even get really wrong:
>>> "{0:.1}".format(1.2345)
'1.0'
----------
components: Interpreter Core
messages: 69947
nosy: hagen
severity: normal
status: open
title: wrong precision in float formatting
type: behavior
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3404>
_______________________________________
From report at bugs.python.org Fri Jul 18 14:52:46 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 18 Jul 2008 12:52:46 +0000
Subject: [New-bugs-announce] [issue3405] Add support for the new data option
supported by event generate (Tk 8.5)
In-Reply-To: <1216385566.01.0.7972232454.issue3405@psf.upfronthosting.co.za>
Message-ID: <1216385566.01.0.7972232454.issue3405@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
Follows a patch that adds support for the new data option supported
event generate. It allows virtual events to pass a tcl object.
This patch is only intended to correctly support tcl objects, trying to
pass other objects (like a dict) will result in None being returned. If
you want to correctly pass and receive a dict, make it an attribute of
the tcl object being passed.
E.g.:
import Tkinter
def handle_it(event):
print event.data.something
root = Tkinter.Tk()
root.something = {1: 2}
root.after(1, lambda: root.event_generate('<<Test>>', data=root))
root.bind('<<Test>>', handle_it)
root.mainloop()
----------
components: Tkinter
files: event_generate__data.diff
keywords: patch
messages: 69951
nosy: gpolo
severity: normal
status: open
title: Add support for the new data option supported by event generate (Tk 8.5)
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10934/event_generate__data.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3405>
_______________________________________
From report at bugs.python.org Fri Jul 18 15:02:51 2008
From: report at bugs.python.org (WoLpH)
Date: Fri, 18 Jul 2008 13:02:51 +0000
Subject: [New-bugs-announce] [issue3406] LocaleTextCalendar and
LocaleHTMLCalendar break without a locale
In-Reply-To: <1216386171.9.0.435364597231.issue3406@psf.upfronthosting.co.za>
Message-ID: <1216386171.9.0.435364597231.issue3406@psf.upfronthosting.co.za>
New submission from WoLpH <Rick.van.Hattem at Fawo.nl>:
Steps to reproduce:
>>> import calendar
>>> calendar.LocaleHTMLCalendar()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.5/calendar.py", line 540, in __init__
locale = locale.getdefaultlocale()
AttributeError: 'NoneType' object has no attribute 'getdefaultlocale'
The same goes for LocaleTextCalendar, the problem is caused by this
code which obviously would never work:
if locale is None:
locale = locale.getdefaultlocale()
The fix should be quite easy, rename the local variable and it will
work again :)
----------
components: Extension Modules
messages: 69952
nosy: WoLpH
severity: normal
status: open
title: LocaleTextCalendar and LocaleHTMLCalendar break without a locale
type: crash
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3406>
_______________________________________
From report at bugs.python.org Fri Jul 18 20:47:54 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Fri, 18 Jul 2008 18:47:54 +0000
Subject: [New-bugs-announce] [issue3407] test_urllib2_localnet fails on
MacOS X 10.4.11 (Intel)
In-Reply-To: <1216406874.33.0.238022254592.issue3407@psf.upfronthosting.co.za>
Message-ID: <1216406874.33.0.238022254592.issue3407@psf.upfronthosting.co.za>
New submission from Jean Brouwers <MrJean1 at Gmail.com>:
The test_urllib2_localnet fails on MacOS X 10.4.11 (Intel) with Python 2.6b2 (and 3.0b2), see
below.
The same test also failed for Python 2.6b1 but was not reported as a test failure.
% ./python.exe
Python 2.6b2 (r26b2:65082, Jul 18 2008, 09:00:40)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
% ./python.exe Lib/test/test_urllib2_localnet.py
test_proxy_qop_auth_int_works_or_throws_urlerror (__main__.ProxyAuthTests) ... ok
test_proxy_qop_auth_works (__main__.ProxyAuthTests) ... ok
test_proxy_with_bad_password_raises_httperror (__main__.ProxyAuthTests) ... ok
test_proxy_with_no_password_raises_httperror (__main__.ProxyAuthTests) ... ok
----------------------------------------------------------------------
Ran 4 tests in 4.233s
OK
test_200 (__main__.TestUrlopen) ... ok
test_200_with_parameters (__main__.TestUrlopen) ... ok
test_404 (__main__.TestUrlopen) ... ok
test_bad_address (__main__.TestUrlopen) ... FAIL
test_basic (__main__.TestUrlopen) ... ok
test_geturl (__main__.TestUrlopen) ... ok
test_info (__main__.TestUrlopen) ... ok
test_redirection (__main__.TestUrlopen) ... ok
test_sending_headers (__main__.TestUrlopen) ... ok
======================================================================
FAIL: test_bad_address (__main__.TestUrlopen)
----------------------------------------------------------------------
Traceback (most recent call last):
File "Lib/test/test_urllib2_localnet.py", line 477, in test_bad_address
urllib2.urlopen, "http://www.python.invalid./")
AssertionError: IOError not raised
----------------------------------------------------------------------
Ran 9 tests in 9.486s
FAILED (failures=1)
Traceback (most recent call last):
File "Lib/test/test_urllib2_localnet.py", line 491, in <module>
test_main()
File "Lib/test/test_urllib2_localnet.py", line 488, in test_main
test_support.run_unittest(TestUrlopen)
File ".../Python-2.6b2/Lib/test/test_support.py", line 731, in run_unittest
_run_suite(suite)
File ".../Python-2.6b2/Lib/test/test_support.py", line 714, in _run_suite
raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
File "Lib/test/test_urllib2_localnet.py", line 477, in test_bad_address
urllib2.urlopen, "http://www.python.invalid./")
AssertionError: IOError not raised
----------
components: Tests
messages: 69971
nosy: MrJean1
severity: normal
status: open
title: test_urllib2_localnet fails on MacOS X 10.4.11 (Intel)
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3407>
_______________________________________
From report at bugs.python.org Fri Jul 18 20:53:38 2008
From: report at bugs.python.org (vizcayno)
Date: Fri, 18 Jul 2008 18:53:38 +0000
Subject: [New-bugs-announce] [issue3408] urllib incomplete and urllib2 does
not exist
In-Reply-To: <1216407218.4.0.726593337894.issue3408@psf.upfronthosting.co.za>
Message-ID: <1216407218.4.0.726593337894.issue3408@psf.upfronthosting.co.za>
New submission from vizcayno <vizcaynot at gmail.com>:
I am under Win XP sp 3:
After importing urllib it only shows a few objects when using dir()
urllib2 module does not exist.
.python
Python 3.0b2 (r30b2:65106, Jul 18 2008, 18:44:17) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib
>>> dir(urllib)
['__builtins__', '__doc__', '__file__', '__name__', '__package__', '__pa
th__']
>>> import urllib2
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named urllib2
>>>
----------
components: Windows
messages: 69974
nosy: vizcayno
severity: normal
status: open
title: urllib incomplete and urllib2 does not exist
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3408>
_______________________________________
From report at bugs.python.org Fri Jul 18 21:45:25 2008
From: report at bugs.python.org (Uwe Hoffmann)
Date: Fri, 18 Jul 2008 19:45:25 +0000
Subject: [New-bugs-announce] [issue3409] ElementPath.Path.findall problem
with unicode input
In-Reply-To: <1216410325.02.0.112420594064.issue3409@psf.upfronthosting.co.za>
Message-ID: <1216410325.02.0.112420594064.issue3409@psf.upfronthosting.co.za>
New submission from Uwe Hoffmann <qual at tiscali.de>:
if you call Element.findall(u".......") some silent errors can
occure because of the isinstance(....,type("")) check. I'm
not sure if it is even allowed to call findall with a unicode parameter.
The attached diff solves *my* problem.
----------
components: Library (Lib), Unicode
files: ElementPath.diff
keywords: patch
messages: 69986
nosy: qual
severity: normal
status: open
title: ElementPath.Path.findall problem with unicode input
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file10940/ElementPath.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3409>
_______________________________________
From report at bugs.python.org Fri Jul 18 21:49:55 2008
From: report at bugs.python.org (Felipe Portella)
Date: Fri, 18 Jul 2008 19:49:55 +0000
Subject: [New-bugs-announce] [issue3410] platform.version() don't work as
expected in Vista in portuguese
In-Reply-To: <1216410595.08.0.936182141358.issue3410@psf.upfronthosting.co.za>
Message-ID: <1216410595.08.0.936182141358.issue3410@psf.upfronthosting.co.za>
New submission from Felipe Portella <felipe at portella.com.br>:
Using Vista in Portuguese platform.version is returning "32bits"
instead of "6.0.6001". This is because in file platform.py line 379
thee regular expression try to search for the word "Version" in
english, while in Portuguese the command ver will return "Vers?o".
To solve this issue simple change:
'Version ([\d.]+))')
for
'\S+ ([\d.]+))')
----------
components: Library (Lib)
messages: 69987
nosy: portella
severity: normal
status: open
title: platform.version() don't work as expected in Vista in portuguese
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3410>
_______________________________________
From report at bugs.python.org Fri Jul 18 22:09:21 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Fri, 18 Jul 2008 20:09:21 +0000
Subject: [New-bugs-announce] [issue3411] str.format() on negative floats
In-Reply-To: <1216411761.22.0.510174949199.issue3411@psf.upfronthosting.co.za>
Message-ID: <1216411761.22.0.510174949199.issue3411@psf.upfronthosting.co.za>
New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:
This happens with an empty type field in the format specification:
>>> "{0:1}".format(-1.23)
'.0-1.23'
With type "g" it's ok:
>>> "{0:1g}".format(-1.23)
'-1.23'
----------
components: Library (Lib)
messages: 69988
nosy: hagen
severity: normal
status: open
title: str.format() on negative floats
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3411>
_______________________________________
From report at bugs.python.org Fri Jul 18 23:36:09 2008
From: report at bugs.python.org (Florian Mayer)
Date: Fri, 18 Jul 2008 21:36:09 +0000
Subject: [New-bugs-announce] [issue3412] Fraction and Decimal in the Tutorial
In-Reply-To: <1216416969.62.0.493735551433.issue3412@psf.upfronthosting.co.za>
Message-ID: <1216416969.62.0.493735551433.issue3412@psf.upfronthosting.co.za>
New submission from Florian Mayer <flormayer at aim.com>:
I think that when floating point number limitations are mentioned we
should also tell that there are alternatives for processing numbers with
decimal extensions. I wrote a text that introduces the Decimal and the
Fraction type to the reader.
----------
assignee: georg.brandl
components: Documentation
files: floating
messages: 69992
nosy: georg.brandl, segfaulthunter
severity: normal
status: open
title: Fraction and Decimal in the Tutorial
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10941/floating
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3412>
_______________________________________
From report at bugs.python.org Sat Jul 19 04:48:34 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Sat, 19 Jul 2008 02:48:34 +0000
Subject: [New-bugs-announce] [issue3413] typo in Mac/Makefile.in breaks
installing IDLE
In-Reply-To: <1216435714.49.0.10489106373.issue3413@psf.upfronthosting.co.za>
Message-ID: <1216435714.49.0.10489106373.issue3413@psf.upfronthosting.co.za>
New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:
There's a slight typo in Mac/Makefile.in, where DESDIR was used instead of DESTDIR. This
patch fixes it:
--- /tmp/Makefile.in 2008-07-18 19:42:29.000000000 -0700
+++ Mac/Makefile.in 2008-07-18 19:42:33.000000000 -0700
@@ -216,7 +216,7 @@
test -d "$(DESTDIR)$(PYTHONAPPSDIR)" || mkdir -p "$(DESTDIR)$(PYTHONAPPSDIR)"
-test -d "$(DESTDIR)$(PYTHONAPPSDIR)/IDLE.app" && rm -r
"$(DESTDIR)$(PYTHONAPPSDIR)/IDLE.app"
cp -PR IDLE/IDLE.app "$(DESTDIR)$(PYTHONAPPSDIR)"
- ln -sf $(INSTALLED_PYTHONAPP)
"$(DESDIR)$(PYTHONAPPSDIR)/IDLE.app/Contents/MacOS/Python"
+ ln -sf $(INSTALLED_PYTHONAPP)
"$(DESTDIR)$(PYTHONAPPSDIR)/IDLE.app/Contents/MacOS/Python"
touch "$(DESTDIR)$(PYTHONAPPSDIR)/IDLE.app"
$(INSTALLED_PYTHONAPP): install_Python
----------
components: Build
messages: 70001
nosy: erickt
severity: normal
status: open
title: typo in Mac/Makefile.in breaks installing IDLE
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3413>
_______________________________________
From report at bugs.python.org Sat Jul 19 06:07:32 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Sat, 19 Jul 2008 04:07:32 +0000
Subject: [New-bugs-announce] [issue3414] frameworkinstall doesn't create
Python.app, which breaks python
In-Reply-To: <1216440452.24.0.507220813764.issue3414@psf.upfronthosting.co.za>
Message-ID: <1216440452.24.0.507220813764.issue3414@psf.upfronthosting.co.za>
New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:
Hello again!
It looks like doing "make frameworkinstall maninstall" isn't creating
"Python.framework/Versions/3.0/Resources/Python.app", so when I try to
run python it errors out with: "python3.0: execv:
/opt/local/Library/Frameworks/Python.framework/Versions/3.0/Resources/Py
thon.app/Contents/MacOS/Python: No such file or directory". In order to
get that file created, I need to manually run "cd Mac && make
install_Python".
This patch fixes it, but I'm not sure if this is the proper fix:
--- Mac/Makefile.in.old 2008-07-18 20:59:44.000000000 -0700
+++ Mac/Makefile.in 2008-07-18 20:57:44.000000000 -0700
@@ -46,7 +46,7 @@
compileall=$(srcdir)/../Lib/compileall.py
installapps: install_PythonLauncher install_IDLE checkapplepython
install_pythonw \
- install_versionedtools
+ install_versionedtools install_Python
installapps4way: install_Python4way install_BuildApplet
install_PythonLauncher install_IDLE install_pythonw4way
install_versionedtools
----------
components: Build
messages: 70004
nosy: erickt
severity: normal
status: open
title: frameworkinstall doesn't create Python.app, which breaks python
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3414>
_______________________________________
From report at bugs.python.org Sat Jul 19 07:32:35 2008
From: report at bugs.python.org (Nir)
Date: Sat, 19 Jul 2008 05:32:35 +0000
Subject: [New-bugs-announce] [issue3415] Interpreter error when running a
script under debugger control
In-Reply-To: <1216445555.64.0.192664487066.issue3415@psf.upfronthosting.co.za>
Message-ID: <1216445555.64.0.192664487066.issue3415@psf.upfronthosting.co.za>
New submission from Nir <nir at winpdb.org>:
Interpreter error results in erroneous exception when running a script
under debugger control.
Full repro description:
On Windows System, try to run idle.py under the inspection of pdb.py.
Note that you must set a breakpoint somewhere otherwise pdb will not
trace the script and the issue will not surface.
You should get the bad exception in line 295 of multicall.py
Python complains that a local variable has been used before being
declared while in effect it has been a couple of lines before that point.
Nir
----------
components: Interpreter Core
messages: 70005
nosy: nirai
severity: normal
status: open
title: Interpreter error when running a script under debugger control
type: behavior
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3415>
_______________________________________
From report at bugs.python.org Sat Jul 19 13:57:13 2008
From: report at bugs.python.org (Yu Xin)
Date: Sat, 19 Jul 2008 11:57:13 +0000
Subject: [New-bugs-announce] [issue3416] Wrong inherit in PickleHTMLBuilder
In-Reply-To: <1216468633.06.0.823893160306.issue3416@psf.upfronthosting.co.za>
Message-ID: <1216468633.06.0.823893160306.issue3416@psf.upfronthosting.co.za>
New submission from Yu Xin <scaner at gmail.com>:
I use sphinx-0.4.1. When I make pickle, I saw the error message:
Traceback (most recent call last):
File
"/is/app/grows/lib/python2.5/site-packages/Sphinx-0.4.1-py2.5.egg/sphinx/__init__.py",
line 135, in main
app.builder.build_update()
File
"/is/app/grows/lib/python2.5/site-packages/Sphinx-0.4.1-py2.5.egg/sphinx/builder.py",
line 202, in build_update
'out of date' % len(to_build))
File
"/is/app/grows/lib/python2.5/site-packages/Sphinx-0.4.1-py2.5.egg/sphinx/builder.py",
line 241, in build
self.write(docnames, updated_docnames, method)
File
"/is/app/grows/lib/python2.5/site-packages/Sphinx-0.4.1-py2.5.egg/sphinx/builder.py",
line 277, in write
self.write_doc(docname, doctree)
File
"/is/app/grows/lib/python2.5/site-packages/Sphinx-0.4.1-py2.5.egg/sphinx/builder.py",
line 459, in write_doc
self.handle_page(docname, ctx, event_arg=doctree)
TypeError: handle_page() got an unexpected keyword argument 'event_arg'.
I inspect the class in sphinx/builder.py.
handle_page in StandaloneHTMLBuilder is defined as "def ndle_page(self,
pagename, addctx, templatename='page.html', outfilename=None,
event_arg=None):
but handle_page in PickleHTMLBuilder is defined as "def
handle_page(self, pagename, ctx, templatename='page.html',
outfilename=None):"
the last param event_arg is missing.
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 70015
nosy: georg.brandl, is
severity: normal
status: open
title: Wrong inherit in PickleHTMLBuilder
type: crash
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3416>
_______________________________________
From report at bugs.python.org Sat Jul 19 15:51:59 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 19 Jul 2008 13:51:59 +0000
Subject: [New-bugs-announce] [issue3417] make the fix_dict fixer explicit
In-Reply-To: <1216475519.86.0.701774626864.issue3417@psf.upfronthosting.co.za>
Message-ID: <1216475519.86.0.701774626864.issue3417@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <benjamin.peterson at usfamily.net>:
Can we make the part of fix_dict that converts d.items/values/keys to
list(d.items) explicit? Most of the time, it's fine if the method
returns a view and can be a bit of a performance hit to convert it to a
list.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 70031
nosy: benjamin.peterson, collinwinter
severity: normal
status: open
title: make the fix_dict fixer explicit
type: behavior
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3417>
_______________________________________
From report at bugs.python.org Sat Jul 19 16:02:50 2008
From: report at bugs.python.org (mgogoulos)
Date: Sat, 19 Jul 2008 14:02:50 +0000
Subject: [New-bugs-announce] [issue3418] heavy resource usage with string
functions
In-Reply-To: <1216476170.57.0.358582553384.issue3418@psf.upfronthosting.co.za>
Message-ID: <1216476170.57.0.358582553384.issue3418@psf.upfronthosting.co.za>
New submission from mgogoulos <mgogoulos at abiss.gr>:
Not sure if this is a bug, however the following string functions when
called with very big numbers as the padding arguments consume great
system resources. My estimation is that it would help to exist a limit
on what can be specified as width.
Check (center, ljust, rjust, zfill)
eg.
import string
string.center('..', 2147483647)
Tested on python versions: 2.5.1 and 2.5.2
----------
components: Library (Lib)
messages: 70034
nosy: mgogoulos
severity: normal
status: open
title: heavy resource usage with string functions
type: resource usage
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3418>
_______________________________________
From report at bugs.python.org Sat Jul 19 22:00:42 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Sat, 19 Jul 2008 20:00:42 +0000
Subject: [New-bugs-announce] [issue3419] multiprocessing module is racy
In-Reply-To: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>
Message-ID: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>
New submission from Ismail Donmez <ismail at namtrac.org>:
Tested on MacOSX 10.5.4, running test_multiprocessing in a tight loop :
[~/Sources/py3k]> while true;do ./python ./Lib/test/regrtest.py
test_multiprocessing;done
test_multiprocessing
1 test OK.
test_multiprocessing
1 test OK.
test_multiprocessing
1 test OK.
test_multiprocessing
Process Process-48:
Traceback (most recent call last):
File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py",
line 720, in _callmethod
conn = self._tls.connection
AttributeError: 'ForkAwareLocal' object has no attribute 'connection'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Users/cartman/Sources/py3k/Lib/multiprocessing/process.py",
line 232, in _bootstrap
self.run()
File "/Users/cartman/Sources/py3k/Lib/multiprocessing/process.py",
line 88, in run
self._target(*self._args, **self._kwargs)
File "/Users/cartman/Sources/py3k/Lib/test/test_multiprocessing.py",
line 601, in f
cond.acquire()
File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py",
line 949, in acquire
return self._callmethod('acquire', (blocking,))
File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py",
line 724, in _callmethod
self._connect()
File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py",
line 711, in _connect
conn = self._Client(self._token.address, authkey=self._authkey)
File "/Users/cartman/Sources/py3k/Lib/multiprocessing/connection.py",
line 133, in Client
c = SocketClient(address)
File "/Users/cartman/Sources/py3k/Lib/multiprocessing/connection.py",
line 254, in SocketClient
s.connect(address)
socket.error: [Errno 61] Connection refused
Exception in thread Thread-58:
Traceback (most recent call last):
File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py",
line 720, in _callmethod
conn = self._tls.connection
AttributeError: 'ForkAwareLocal' object has no attribute 'connection'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Users/cartman/Sources/py3k/Lib/threading.py", line 492, in
_bootstrap_inner
self.run()
File "/Users/cartman/Sources/py3k/Lib/threading.py", line 447, in run
self._target(*self._args, **self._kwargs)
File "/Users/cartman/Sources/py3k/Lib/test/test_multiprocessing.py",
line 601, in f
cond.acquire()
File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py",
line 949, in acquire
return self._callmethod('acquire', (blocking,))
File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py",
line 724, in _callmethod
self._connect()
File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py",
line 711, in _connect
conn = self._Client(self._token.address, authkey=self._authkey)
File "/Users/cartman/Sources/py3k/Lib/multiprocessing/connection.py",
line 133, in Client
c = SocketClient(address)
File "/Users/cartman/Sources/py3k/Lib/multiprocessing/connection.py",
line 254, in SocketClient
s.connect(address)
socket.error: [Errno 61] Connection refused
----------
components: Tests
messages: 70053
nosy: cartman
severity: normal
status: open
title: multiprocessing module is racy
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3419>
_______________________________________
From report at bugs.python.org Sun Jul 20 10:07:07 2008
From: report at bugs.python.org (Barry Alan Scott)
Date: Sun, 20 Jul 2008 08:07:07 +0000
Subject: [New-bugs-announce] [issue3420] 2to3 fails to run on Mac OS X 10.4
PPC 3.0b2
In-Reply-To: <1216541227.58.0.862613379472.issue3420@psf.upfronthosting.co.za>
Message-ID: <1216541227.58.0.862613379472.issue3420@psf.upfronthosting.co.za>
New submission from Barry Alan Scott <barry-scott at users.sourceforge.net>:
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.4.11
BuildVersion: 8S165
$ python3.0
Python 3.0b2 (r30b2:65080, Jul 20 2008, 08:46:13)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
$ /Library/Frameworks/Python.framework//Versions/3.0/bin/2to3 a.py
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework//Versions/3.0/bin/2to3",
line 5, in <module>
sys.exit(refactor.main("lib2to3/fixes"))
File
"/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/lib2to3/refactor.py",
line 81, in main
rt = RefactoringTool(fixer_dir, options)
File
"/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/lib2to3/refactor.py",
line 160, in __init__
self.pre_order, self.post_order = self.get_fixers()
File
"/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/lib2to3/refactor.py",
line 182, in get_fixers
fix_names = get_all_fix_names(self.fixer_dir)
File
"/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/lib2to3/refactor.py",
line 95, in get_all_fix_names
names = os.listdir(fixer_dir)
OSError: [Errno 2] No such file or directory: 'lib2to3/fixes'
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 70065
nosy: barry-scott, collinwinter
severity: normal
status: open
title: 2to3 fails to run on Mac OS X 10.4 PPC 3.0b2
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3420>
_______________________________________
From report at bugs.python.org Mon Jul 21 00:36:53 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 22:36:53 +0000
Subject: [New-bugs-announce] [issue3421] Test failure in test_math::testSum
In-Reply-To: <1216593413.69.0.163323698649.issue3421@psf.upfronthosting.co.za>
Message-ID: <1216593413.69.0.163323698649.issue3421@psf.upfronthosting.co.za>
New submission from Georg Brandl <georg at python.org>:
In Py3k, but not in trunk:
======================================================================
FAIL: testSum (test.test_math.MathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/gbr/devel/python3k/Lib/test/test_math.py", line 769, in
testSum
self.assertEqual(math.sum(vals), s)
OverflowError: math range error
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/gbr/devel/python3k/Lib/test/test_math.py", line 772, in
testSum
"for math.sum(%.100r)" % (i, s, vals))
AssertionError: test 13 failed: got OverflowError, expected
1.7976931348623157e+308 for math.sum([1.7976931348623157e+308,
9.979201547673598e+291])
System info: linux x86, glibc 2.8
----------
assignee: marketdickinson
components: Extension Modules, Tests
messages: 70094
nosy: georg.brandl, marketdickinson
severity: normal
status: open
title: Test failure in test_math::testSum
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3421>
_______________________________________
From report at bugs.python.org Mon Jul 21 01:08:35 2008
From: report at bugs.python.org (Pauli Virtanen)
Date: Sun, 20 Jul 2008 23:08:35 +0000
Subject: [New-bugs-announce] [issue3422] sphinx.doc.autodoc: Hook for
changing argspec
In-Reply-To: <1216595315.74.0.23412143047.issue3422@psf.upfronthosting.co.za>
Message-ID: <1216595315.74.0.23412143047.issue3422@psf.upfronthosting.co.za>
New submission from Pauli Virtanen <pav at iki.fi>:
It would be useful if the
autodoc-process-docstring
event from sphinx.ext.autodoc allowed to change the argspec of the
function being documented. Some other hook for changing the function
signature would also do.
We are using Sphinx for generating a reference guide for Numpy, where
many of the functions are from extension modules for which
inspect.getargspec does not work. Instead, the function signature is
contained within the object's docstring. Right now I'm simply
monkeypatching sphinx.ext.autodoc.format_signature, but a cleaner
approach would be better.
It seems that this would be fairly easy to implement in generate_rst.
Perhaps a .signature attribute to the Options passed to the hook would
be an acceptable solution?
I can write a patch doing this, if someone doesn't do this faster.
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 70096
nosy: georg.brandl, pv
severity: normal
status: open
title: sphinx.doc.autodoc: Hook for changing argspec
type: feature request
versions: 3rd party
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3422>
_______________________________________
From report at bugs.python.org Tue Jul 22 02:40:42 2008
From: report at bugs.python.org (Greg Hazel)
Date: Tue, 22 Jul 2008 00:40:42 +0000
Subject: [New-bugs-announce] [issue3423] DeprecationWarning message applies
to wrong context with exec()
In-Reply-To: <1216687242.26.0.837867299264.issue3423@psf.upfronthosting.co.za>
Message-ID: <1216687242.26.0.837867299264.issue3423@psf.upfronthosting.co.za>
New submission from Greg Hazel <ghazel at users.sourceforge.net>:
exec()ing a line which causes a DeprecationWarning causes the warning
to quote the file exec() occurs in instead of the string.
Demonstration of the issue:
http://codepad.org/aMTYQgN5
----------
components: None
messages: 70129
nosy: ghazel
severity: normal
status: open
title: DeprecationWarning message applies to wrong context with exec()
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3423>
_______________________________________
From report at bugs.python.org Tue Jul 22 11:30:39 2008
From: report at bugs.python.org (=?utf-8?q?Ilpo_Nyyss=C3=B6nen?=)
Date: Tue, 22 Jul 2008 09:30:39 +0000
Subject: [New-bugs-announce] [issue3424] imghdr test order makes it slow
In-Reply-To: <1216719039.65.0.915247754712.issue3424@psf.upfronthosting.co.za>
Message-ID: <1216719039.65.0.915247754712.issue3424@psf.upfronthosting.co.za>
New submission from Ilpo Nyyss?nen <iny at iki.fi>:
The order of tests in imghdr makes it slow in common cases. Even without
any statistics it is quite easy to see that jpeg is the most common
format. In imghdr only bmp and png are after it. Also, should png really
be the last one?
Nearly all digital cameras produce jpegs and handling such images is one
big use case for this module.
Changing the test order should be easy and have big effect in common use
cases.
----------
components: Library (Lib)
messages: 70142
nosy: biny
severity: normal
status: open
title: imghdr test order makes it slow
type: performance
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3424>
_______________________________________
From report at bugs.python.org Tue Jul 22 15:56:33 2008
From: report at bugs.python.org (Oskar Andersson)
Date: Tue, 22 Jul 2008 13:56:33 +0000
Subject: [New-bugs-announce] [issue3425] posixmodule.c always using res =
utime(path, NULL)
In-Reply-To: <1216734993.32.0.611530331004.issue3425@psf.upfronthosting.co.za>
Message-ID: <1216734993.32.0.611530331004.issue3425@psf.upfronthosting.co.za>
New submission from Oskar Andersson <oskar.andersson at gmail.com>:
I'm porting, embedding and extending Python in a very limited environment.
This environment does not have utime.h and have not defined the
following function:
int utime(const char *, const struct utimbuf *);
Although the function called utimes, defined in sys/time.h exist.
int utimes(const char *path, const struct timeval times[2]);
In the method, in posixmodule.c:
static PyObject *
posix_utime(PyObject *self, PyObject *args);
usage of these methods are used. If a time is specified in args, a
define determines which of the two methods to use, utime or utimes
depending if these exist or not.
If Py_None is sent instead utime is always used, the solution to solve
this is to use #ifdef with HAVE_UTIMES.
Line number 2835 in
http://svn.python.org/projects/python/trunk/Modules/posixmodule.c
I have not checked if this is solved in future versions.
----------
components: Extension Modules
messages: 70147
nosy: oskar86
severity: normal
status: open
title: posixmodule.c always using res = utime(path, NULL)
type: compile error
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3425>
_______________________________________
From report at bugs.python.org Tue Jul 22 16:32:13 2008
From: report at bugs.python.org (=?utf-8?q?Christian_H=C3=A4ggstr=C3=B6m?=)
Date: Tue, 22 Jul 2008 14:32:13 +0000
Subject: [New-bugs-announce] [issue3426] os.path.abspath with unicode
argument should call os.getcwdu
In-Reply-To: <1216737133.71.0.70086601319.issue3426@psf.upfronthosting.co.za>
Message-ID: <1216737133.71.0.70086601319.issue3426@psf.upfronthosting.co.za>
New submission from Christian H?ggstr?m <chn at virtutech.com>:
If current working directory contains non-ascii characters, calling
os.path.abspath(u".") will result in an error. I expect it to call the
underlying os.getcwdu() in this case.
>>> import os
>>> os.path.abspath(u".")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File
"/home/packages/python-2.5.1/x86-linux/lib/python2.5/posixpath.py", line
403, in abspath
path = join(os.getcwd(), path)
File
"/home/packages/python-2.5.1/x86-linux/lib/python2.5/posixpath.py", line
65, in join
path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe4 in position 29:
ordinal not in range(128)
It works if I do it manually, using os.getcwdu():
>>> os.path.join(os.getcwdu(), u".")
u'/disk1/chn_local/work/test/sk\xe4rg\xe5rds\xf6-latin1/.'
----------
components: Unicode
messages: 70148
nosy: saturn_mimas
severity: normal
status: open
title: os.path.abspath with unicode argument should call os.getcwdu
type: behavior
versions: Python 2.4, Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3426>
_______________________________________
From report at bugs.python.org Tue Jul 22 19:05:35 2008
From: report at bugs.python.org (ThomasH)
Date: Tue, 22 Jul 2008 17:05:35 +0000
Subject: [New-bugs-announce] [issue3427] urllib documentation:
urlopen().info() return type
In-Reply-To: <1216746335.31.0.451776222673.issue3427@psf.upfronthosting.co.za>
Message-ID: <1216746335.31.0.451776222673.issue3427@psf.upfronthosting.co.za>
New submission from ThomasH <thomas.bugzilla at gmx.net>:
http://docs.python.org/lib/module-urllib.html
The page says that the return type of urlopen().info() is a
mimetools.Message object, which is not quite true; it is a
httplib.HTTPMessage object, which is a class derived from
mimetools.Message, but with additional features.
The httplib.HTTPMessage class is not documented at all, for which I will
file a separate bug.
----------
assignee: georg.brandl
components: Documentation
messages: 70154
nosy: ThomasH, georg.brandl
severity: normal
status: open
title: urllib documentation: urlopen().info() return type
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3427>
_______________________________________
From report at bugs.python.org Tue Jul 22 19:09:01 2008
From: report at bugs.python.org (ThomasH)
Date: Tue, 22 Jul 2008 17:09:01 +0000
Subject: [New-bugs-announce] [issue3428] httplib.HTTPMessage undocumented
In-Reply-To: <1216746541.05.0.162492292768.issue3428@psf.upfronthosting.co.za>
Message-ID: <1216746541.05.0.162492292768.issue3428@psf.upfronthosting.co.za>
New submission from ThomasH <thomas.bugzilla at gmx.net>:
The httplib.HTTPMessage class needs documentation; it is missing from
the package documentation entirely. Instances of this class are e.g.
returned by the urllib.urlopen().info() method.
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 70155
nosy: ThomasH, georg.brandl
severity: normal
status: open
title: httplib.HTTPMessage undocumented
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3428>
_______________________________________
From report at bugs.python.org Tue Jul 22 19:17:09 2008
From: report at bugs.python.org (ThomasH)
Date: Tue, 22 Jul 2008 17:17:09 +0000
Subject: [New-bugs-announce] [issue3429] urllib.urlopen() return type
In-Reply-To: <1216747029.56.0.0682740128013.issue3429@psf.upfronthosting.co.za>
Message-ID: <1216747029.56.0.0682740128013.issue3429@psf.upfronthosting.co.za>
New submission from ThomasH <thomas.bugzilla at gmx.net>:
The file-like object returned by urllib.urlopen() should be documented
like a proper class. The textual description under the urlopen() method
is less approachable and breaks the usual format of a class documentation.
Maybe the return type should be changed to be a httplib.HTTPResponse
object (but that's a separate issue).
----------
assignee: georg.brandl
components: Documentation
messages: 70156
nosy: ThomasH, georg.brandl
severity: normal
status: open
title: urllib.urlopen() return type
type: feature request
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3429>
_______________________________________
From report at bugs.python.org Tue Jul 22 19:31:20 2008
From: report at bugs.python.org (ThomasH)
Date: Tue, 22 Jul 2008 17:31:20 +0000
Subject: [New-bugs-announce] [issue3430] httplib.HTTPResponse documentations
inconsistent
In-Reply-To: <1216747880.73.0.0581734704537.issue3430@psf.upfronthosting.co.za>
Message-ID: <1216747880.73.0.0581734704537.issue3430@psf.upfronthosting.co.za>
New submission from ThomasH <thomas.bugzilla at gmx.net>:
The library reference documentation of httplib.HTTPResponse does not
match up with the online help documentation, or with the dir()
information of a particular instance.
E.g. the list of public features in the library reference
(http://docs.python.org/lib/httpresponse-objects.html) is:
- read
- getheader
- getheaders
- msg
- version
- status
- reason
>From the online documentation (with 'help(httplib.HTTPResponse)'):
- begin
- close
- getheader
- getheaders
- isclosed
- read
And from a class instance (via 'dir(httpResponseInstance)'):
- 'begin',
- 'chunk_left',
- 'chunked',
- 'close',
- 'debuglevel',
- 'fp',
- 'getheader',
- 'getheaders',
- 'isclosed',
- 'length',
- 'msg',
- 'read',
- 'reason',
- 'status',
- 'strict',
- 'version',
- 'will_close'
----------
assignee: georg.brandl
components: Documentation
messages: 70158
nosy: ThomasH, georg.brandl
severity: normal
status: open
title: httplib.HTTPResponse documentations inconsistent
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3430>
_______________________________________
From report at bugs.python.org Wed Jul 23 17:48:19 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 23 Jul 2008 15:48:19 +0000
Subject: [New-bugs-announce] [issue3431] multiprocessing uses
Pickler.dispatch which isn't in 3.0 _pickle
In-Reply-To: <1216828098.95.0.494752132051.issue3431@psf.upfronthosting.co.za>
Message-ID: <1216828098.95.0.494752132051.issue3431@psf.upfronthosting.co.za>
New submission from Georg Brandl <georg at python.org>:
multiprocessing's new ForkingPickler uses Pickler's dispatch attribute
which is only present in the Python version, not the C one. As a result,
a straightforward merge isn't possible.
----------
assignee: jnoller
components: Library (Lib)
messages: 70176
nosy: alexandre.vassalotti, georg.brandl, jnoller
severity: normal
status: open
title: multiprocessing uses Pickler.dispatch which isn't in 3.0 _pickle
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3431>
_______________________________________
From report at bugs.python.org Thu Jul 24 04:42:54 2008
From: report at bugs.python.org (Robin Dunn)
Date: Thu, 24 Jul 2008 02:42:54 +0000
Subject: [New-bugs-announce] [issue3432] Mac, 2.6 framework install error
In-Reply-To: <1216867374.16.0.0480249561855.issue3432@psf.upfronthosting.co.za>
Message-ID: <1216867374.16.0.0480249561855.issue3432@psf.upfronthosting.co.za>
New submission from Robin Dunn <robin at alldunn.com>:
OSX Leopard (10.5.4)
Python-2.6b2 tarball
./configure --enable-universalsdk --enable-framework
make
sudo make install
Ends with this error:
cd Mac && make installmacsubtree DESTDIR=""
Creating directory
/Library/Frameworks/Python.framework/Versions/2.6/Mac/Tools
DYLD_FRAMEWORK_PATH=/projects/Python-2.6b2: arch -ppc -i386
../python.exe ./scripts/cachersrc.py -v
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac
/Library/Frameworks/Python.framework/Versions/2.6/Mac/Tools
Traceback (most recent call last):
File "./scripts/cachersrc.py", line 7, in <module>
import macresource
File "/projects/Python-2.6b2/Lib/plat-mac/macresource.py", line 6, in
<module>
from Carbon import Res
File "/projects/Python-2.6b2/Lib/plat-mac/Carbon/Res.py", line 4, in
<module>
from _Res import *
ImportError: No module named _Res
make[1]: *** [installmacsubtree] Error 1
make: *** [frameworkinstallmaclib] Error 2
Since by this time in the install process the _Res module has already
been installed I was able to work around this issue by hacking the
generated Mac/Makefile and setting RUNSHARED to nothing. The same
problem happens in Mac/IDLE/Makefile as well.
----------
components: Macintosh
messages: 70189
nosy: robind
severity: normal
status: open
title: Mac, 2.6 framework install error
type: compile error
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3432>
_______________________________________
From report at bugs.python.org Thu Jul 24 04:43:30 2008
From: report at bugs.python.org (Robin Dunn)
Date: Thu, 24 Jul 2008 02:43:30 +0000
Subject: [New-bugs-announce] [issue3433] Mac,
3.0 framework install error with fink cp
In-Reply-To: <1216867410.47.0.735334999055.issue3433@psf.upfronthosting.co.za>
Message-ID: <1216867410.47.0.735334999055.issue3433@psf.upfronthosting.co.za>
New submission from Robin Dunn <robin at alldunn.com>:
OSX Leopard (10.5.4)
Python-3.0b2 tarball
./configure --enable-universalsdk --enable-framework
make
sudo make install
Ends with this error:
cd PythonLauncher && make install DESTDIR=
test -d "/Applications/Python 3.0" || mkdir -p "/Applications/Python 3.0"
test -d "/Applications/Python 3.0/Python Launcher.app" && rm -r
"/Applications/Python 3.0/Python Launcher.app"
cp -r "Python Launcher.app" "/Applications/Python 3.0"
touch "/Applications/Python 3.0/Python Launcher.app"
test -d "/Applications/Python 3.0" || mkdir -p "/Applications/Python 3.0"
test -d "/Applications/Python 3.0/IDLE.app" && rm -r
"/Applications/Python 3.0/IDLE.app"
make[1]: [install_IDLE] Error 1 (ignored)
cp -PR IDLE/IDLE.app "/Applications/Python 3.0"
cp: Warning: the meaning of `-P' will change in the future to conform to
POSIX.
Use `--parents' for the old meaning, and `--no-dereference' for the new one.
ln -sf
/Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app/Contents/MacOS/Python
"/Applications/Python 3.0/IDLE.app/Contents/MacOS/Python"
ln: creating symbolic link `/Applications/Python
3.0/IDLE.app/Contents/MacOS/Python' to
`/Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app/Contents/MacOS/Python':
No such file or directory
make[1]: *** [install_IDLE] Error 1
make: *** [frameworkinstallapps] Error 2
It looks like this is due to fink's cp being found first on the PATH.
Temporarily disabling /sw/bin/cp so /bin/cp would be found first then
the install finished.
----------
components: Macintosh
messages: 70190
nosy: robind
severity: normal
status: open
title: Mac, 3.0 framework install error with fink cp
type: compile error
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3433>
_______________________________________
From report at bugs.python.org Thu Jul 24 04:45:34 2008
From: report at bugs.python.org (Robin Dunn)
Date: Thu, 24 Jul 2008 02:45:34 +0000
Subject: [New-bugs-announce] [issue3434] Mac, 3.0 framework install,
Python.app not created
In-Reply-To: <1216867534.32.0.650772799481.issue3434@psf.upfronthosting.co.za>
Message-ID: <1216867534.32.0.650772799481.issue3434@psf.upfronthosting.co.za>
New submission from Robin Dunn <robin at alldunn.com>:
OS X Leopard (10.5.4)
Python-3.0b2 tarball
./configure --enable-universalsdk --enable-framework
make
sudo make install
/Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app
is not created by the install step, but it is needed for running python3.0:
$ python3.0
python3.0: execv:
/Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app/Contents/MacOS/Python:
No such file or directory
----------
components: Macintosh
messages: 70191
nosy: robind
severity: normal
status: open
title: Mac, 3.0 framework install, Python.app not created
type: compile error
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3434>
_______________________________________
From report at bugs.python.org Thu Jul 24 12:39:01 2008
From: report at bugs.python.org (Gustavo Narea)
Date: Thu, 24 Jul 2008 10:39:01 +0000
Subject: [New-bugs-announce] [issue3435] trace.py tries to get coverage data
from non Python files
In-Reply-To: <1216895941.29.0.346900095215.issue3435@psf.upfronthosting.co.za>
Message-ID: <1216895941.29.0.346900095215.issue3435@psf.upfronthosting.co.za>
New submission from Gustavo Narea <me at gustavonarea.net>:
trace.py tries to get coverage information from non Python files, which raises a
SyntaxError because the file doesn't contain valid Python code.
I've attached a path that fixes this problem in Python 2.5.
----------
components: Library (Lib)
files: trace.diff
keywords: patch
messages: 70197
nosy: Gustavo
severity: normal
status: open
title: trace.py tries to get coverage data from non Python files
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10964/trace.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3435>
_______________________________________
From report at bugs.python.org Thu Jul 24 17:30:36 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Thu, 24 Jul 2008 15:30:36 +0000
Subject: [New-bugs-announce] [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
New submission from Andrii V. Mishkovskyi <mishok13 at gmail.com>:
I had to use csv module recently and ran into a "problem" with
DictReader. I had to get headers of CSV file and only after that iterate
throgh each row. But AFAIU there is no way to do it, other then
subclassing. So, basically, right now we have this:
Python 3.0b2+ (unknown, Jul 24 2008, 12:15:52)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> r = csv.DictReader(open('test.csv'))
>>> r.fieldnames
>>> next(r)
{'baz': '13', 'foo': '42', 'bar': '27'}
>>> r.fieldnames
['foo', 'bar', 'baz']
I think it would be much more useful, if DictReader got 'fieldnames' on
calling __init__ method, so this would look like this:
>>> r = csv.DictReader(open('test.csv'))
>>> r.fieldnames
['foo', 'bar', 'baz']
The easy way to do this is to subclass csv.DictReader.
The hard way to do this is to apply the patches I'm attaching. :)
These patches also remove redundant check for self.fieldnames being None
for each next()/__next__() call
----------
files: py3k.csv.py.diff
keywords: patch
messages: 70207
nosy: mishok13
severity: normal
status: open
title: csv.DictReader inconsistency
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10965/py3k.csv.py.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________
From report at bugs.python.org Thu Jul 24 17:50:26 2008
From: report at bugs.python.org (mARK)
Date: Thu, 24 Jul 2008 15:50:26 +0000
Subject: [New-bugs-announce] [issue3437] robotparser.py missing one line
In-Reply-To: <1216914625.92.0.56196072599.issue3437@psf.upfronthosting.co.za>
Message-ID: <1216914625.92.0.56196072599.issue3437@psf.upfronthosting.co.za>
New submission from mARK <python.mbloore at xoxy.net>:
RobotFileParser.parse() contains the lines
elif line[0] == "disallow":
if state != 0:
entry.rulelines.append(RuleLine(line[1], False))
state = 2
elif line[0] == "allow":
if state != 0:
entry.rulelines.append(RuleLine(line[1], True))
with no 'state = 2' in the 'allow' part.
This causes different behaviour depending on whether the file ends with
'allow' or 'disallow', or an empty line.
Those lines were taken from revision 65118. My Python 2.5 sources are
similar. I have not checked others.
----------
components: Library (Lib)
messages: 70209
nosy: mbloore
severity: normal
status: open
title: robotparser.py missing one line
type: behavior
versions: Python 2.5, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3437>
_______________________________________
From report at bugs.python.org Thu Jul 24 17:59:00 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 24 Jul 2008 15:59:00 +0000
Subject: [New-bugs-announce] [issue3438] PyCF_DONT_IMPLY_DEDENT can be used
to activate the with statement
In-Reply-To: <1216915140.34.0.387873405525.issue3438@psf.upfronthosting.co.za>
Message-ID: <1216915140.34.0.387873405525.issue3438@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
Yesterday I read at a maillist about IDLE being able to use the "with"
statement in python 2.5 without needing to explicitly doing "from
__future__ import with_statement", then today I started tracing the
origin of this. It starts at the use of the InteractiveInterpreter from
the code module (so this report affects any custom shells based on it),
which uses the codeop module to compile lines.
The Compile class of the codeop module, innocently compiles the passed
source with a PyCF_DONT_IMPLY_DEDENT flag by default (I'm not going to
enter in the other details done by Compile).
This flag is then converted to PyPARSE_DONT_IMPLY_DEDENT (defined at
parsetok.py with a value of 0x0002) by a PARSER_FLAGS macro at
pythonrun.c. Later on the function parsertok at Parser/parsetok.c is
called and it performs this check "if (flags &
PyPARSE_WITH_IS_KEYWORD)", but PyPARSE_WITH_IS_KEYWORD right now has a
value of 0x0003, so this check ends up working for both
PyPARSE_WITH_IS_KEYWORD and PyPARSE_DONT_IMPLY_DEDENT, causing the
with_statement to be enabled if the PyCF_DONT_IMPLY_DEDENT flag is
passed to the compile builtin.
To test this, start the interpreter (python 2.5) and:
>>> a = compile('with open("something") as x: pass\n', '-', 'single', 0x200)
>>> import __future__
>>> a = compile('with open("something") as x: pass\n', '-', 'single',
__future__.with_statement.compiler_flag)
Notice how it works in both cases.
The patch added is deadly (!) simple (make clean is needed).
----------
components: Interpreter Core
files: new_PyPARSE_WITH_IS_KEYWORD.diff
keywords: patch
messages: 70210
nosy: gpolo
severity: normal
status: open
title: PyCF_DONT_IMPLY_DEDENT can be used to activate the with statement
versions: Python 2.5
Added file: http://bugs.python.org/file10968/new_PyPARSE_WITH_IS_KEYWORD.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3438>
_______________________________________
From report at bugs.python.org Thu Jul 24 19:20:44 2008
From: report at bugs.python.org (Fredrik Johansson)
Date: Thu, 24 Jul 2008 17:20:44 +0000
Subject: [New-bugs-announce] [issue3439] math.frexp and obtaining the bit
size of a large integer
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
New submission from Fredrik Johansson <fredrik.johansson at gmail.com>:
Python 3.0b2 (r30b2:65106, Jul 18 2008, 18:44:17) [MSC v.1500 32 bit
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> math.frexp(10**100)
(0.5714936956411375, 333)
>>> math.frexp(10**1000)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C double
>>>
(Same behavior in Python 2.5.2, and presumably 2.6 although I haven't
checked the latter.)
I think it should be easy to make frexp work for large integers by
calling PyLong_AsScaledDouble and adding the exponents. It would be
logical to fix this since math.log(n) already works for large integers.
My reason for requesting this change is that math.frexp is the fastest
way I know of to accurately count the number of bits in a Python integer
(it is more robust than math.log(n,2) and makes it easy to verify that
the computed size is exact) and this is something I need to do a lot.
Actually, it would be even more useful to have a standard function to
directly obtain the bit size of an integer. If I'm not mistaken,
PyLong_NumBits does precisely this, and would just have to be wrapped.
Aside from my own needs (which don't reflect those of the Python
community), there is at least one place in the standard library where
this would be useful: decimal.py contains an inefficient implementation
(_nbits) that could removed.
----------
components: Library (Lib)
messages: 70216
nosy: fredrikj
severity: normal
status: open
title: math.frexp and obtaining the bit size of a large integer
type: feature request
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________
From report at bugs.python.org Thu Jul 24 22:58:55 2008
From: report at bugs.python.org (Lenard Lindstrom)
Date: Thu, 24 Jul 2008 20:58:55 +0000
Subject: [New-bugs-announce] [issue3440] Starting Python as a subprocess
fails when subprocess.Popen has env argument
In-Reply-To: <1216933135.87.0.837899480676.issue3440@psf.upfronthosting.co.za>
Message-ID: <1216933135.87.0.837899480676.issue3440@psf.upfronthosting.co.za>
New submission from Lenard Lindstrom <len-l at telus.net>:
Python 2.6b2 (r26b2:65106, Jul 18 2008, 18:22:27) [MSC v.1500 32 bit
(Intel)] on win32
Windows XP Professional, SP 2
Library class subprocess.Popen
When subprocess.Popen is used to start the python interpreter as a
subprocess with a custom environment, env is set to a mapping, the
subprocess terminates with the following pop-up error dialog:
"The application failed to initialize properly (0xc0150004). Click on OK
to terminate the application."
The attached fail.py program reproduces the bug. It should print "ABCDE"
if successful. It does for Pythons 2.4 and 2.5.
The reason is that Python 2.6 on Windows requires the environment
variable SystemRoot, which it cannot find. This is demonstrated by
modifying fail.py to include SystemRoot in the environment. This works:
import sys
import os
import subprocess
command = ('''%s -c "import os; print os.environ['YAHOO']"''' %
sys.executable)
env = {"YAHOO": "ABCDE", "SystemRoot": os.environ["SystemRoot"]}
subprocess.Popen(command, env=env).wait()
----------
components: Library (Lib), Windows
files: fail.py
messages: 70225
nosy: kermode
severity: normal
status: open
title: Starting Python as a subprocess fails when subprocess.Popen has env argument
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file10970/fail.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3440>
_______________________________________
From report at bugs.python.org Fri Jul 25 06:09:07 2008
From: report at bugs.python.org (Richard Jones)
Date: Fri, 25 Jul 2008 04:09:07 +0000
Subject: [New-bugs-announce] [issue3441] Regression in "module as a script"
command-line option
In-Reply-To: <1216958947.84.0.328980880705.issue3441@psf.upfronthosting.co.za>
Message-ID: <1216958947.84.0.328980880705.issue3441@psf.upfronthosting.co.za>
New submission from Richard Jones <richardjones at optushome.com.au>:
The Python 2.5 "-m" command-line option allowed execution of a package
directly, by invoking the __init__.py module.
Python 2.6 no longer allows this.
This is a quite unfortunate regression, and I would urge the decision to
hobble it to be reconsidered.
----------
messages: 70240
nosy: richard
severity: normal
status: open
title: Regression in "module as a script" command-line option
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3441>
_______________________________________
From report at bugs.python.org Fri Jul 25 13:38:07 2008
From: report at bugs.python.org (Pavel Strashkin)
Date: Fri, 25 Jul 2008 11:38:07 +0000
Subject: [New-bugs-announce] [issue3442]
wsgiref.validate.InputWrapper.readline does not accept
optional "length" argument
In-Reply-To: <1216985887.33.0.844888743388.issue3442@psf.upfronthosting.co.za>
Message-ID: <1216985887.33.0.844888743388.issue3442@psf.upfronthosting.co.za>
New submission from Pavel Strashkin <xaka2004 at gmail.com>:
All file/stream-like objects in Python have "readline" method with
optional "length" argument, but wsgiref.validate.InputWrapper doest not
have. Some 3rd party modules/packages use this argument. As result there
is exception:
<type 'exceptions.TypeError'>: readline() takes exactly 1 argument (2 given)
I think wsgiref.validate.InputWrapper.readline must be implemented same
to wsgiref.validate.InputWrapper.read:
def readline(self, *args, **kwargs):
v = self.input.readline(*args, **kwargs)
assert_(type(v) is type(""))
return v
----------
components: Library (Lib)
messages: 70248
nosy: xaka
severity: normal
status: open
title: wsgiref.validate.InputWrapper.readline does not accept optional "length" argument
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3442>
_______________________________________
From report at bugs.python.org Fri Jul 25 14:55:50 2008
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 25 Jul 2008 12:55:50 +0000
Subject: [New-bugs-announce] [issue3443] crash on badly initialised
AttributeError
In-Reply-To: <1216990549.95.0.558600790355.issue3443@psf.upfronthosting.co.za>
Message-ID: <1216990549.95.0.558600790355.issue3443@psf.upfronthosting.co.za>
New submission from Stefan Behnel <scoder at users.sourceforge.net>:
I get a reproducible crash under Linux when running the test cases of
lxml's trunk in Py3b2. As usual with these things, it's not reproducible
when running the crashing test by itself, only when it hits the test
during the usual test run (which makes it look like somethings's leaking
between tests here).
Here is what gdb gives me so far.
----------------------
[...]
test_namespace_lookup (lxml.tests.test_classlookup.ClassLookupTestCase)
... ok
test_parser_based_lookup
(lxml.tests.test_classlookup.ClassLookupTestCase) ... ok
Doctest: test_css_select.txt ...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210656576 (LWP 938)]
0x080f3b89 in BaseException_str (self=0x8d747d4) at Objects/exceptions.c:88
88 switch (PyTuple_GET_SIZE(self->args)) {
(gdb) pyo self
object : AttributeError<NULL>
type : AttributeError
refcount: 10
address : 0x8d747d4
$1 = void
(gdb) print self->args
$2 = (PyObject *) 0x0
(gdb) bt
#0 0x080f3b89 in BaseException_str (self=0x8d747d4) at
Objects/exceptions.c:88
#1 0x0805b158 in PyObject_Str (v=0x8d747d4) at Objects/object.c:414
#2 0x0807951a in unicode_new (type=0x81523a0, args=0x8de77ac, kwds=0x0)
at Objects/unicodeobject.c:9247
#3 0x0806068d in type_call (type=0x81523a0, args=0x8de77ac, kwds=0x0)
at Objects/typeobject.c:636
#4 0x080d83a9 in PyObject_Call (func=0x81523a0, arg=0x8de77ac, kw=0x0)
at Objects/abstract.c:2178
#5 0x0808de50 in PyEval_EvalFrameEx (f=0x8e2d07c, throwflag=0) at
Python/ceval.c:3606
#6 0x0808fccd in PyEval_EvalFrameEx (f=0x8e2bf14, throwflag=0) at
Python/ceval.c:3481
#7 0x0808fccd in PyEval_EvalFrameEx (f=0x8e2cef4, throwflag=0) at
Python/ceval.c:3481
#8 0x0808fccd in PyEval_EvalFrameEx (f=0x8e2d4ec, throwflag=0) at
Python/ceval.c:3481
#9 0x08090f6b in PyEval_EvalCodeEx (co=0x8268458, globals=0xb7b772d4,
locals=0x0, args=0x8e2cea4, argcount=3, kws=0x8e2ceb0, kwcount=1,
defs=0x826c678, defcount=3, kwdefs=0x0,
closure=0x0) at Python/ceval.c:2830
#10 0x0808f63e in PyEval_EvalFrameEx (f=0x8e2cd54, throwflag=0) at
Python/ceval.c:3491
#11 0x0808fccd in PyEval_EvalFrameEx (f=0x8dc37a4, throwflag=0) at
Python/ceval.c:3481
#12 0x0808fccd in PyEval_EvalFrameEx (f=0x8da1d7c, throwflag=0) at
Python/ceval.c:3481
#13 0x08090f6b in PyEval_EvalCodeEx (co=0x84b21d0, globals=0x847d79c,
locals=0x0, args=0x8da0dbc, argcount=2, kws=0x8da0dc4, kwcount=2,
defs=0x8591b78, defcount=3, kwdefs=0x0,
closure=0x0) at Python/ceval.c:2830
#14 0x0808f63e in PyEval_EvalFrameEx (f=0x8da0c64, throwflag=0) at
Python/ceval.c:3491
#15 0x0808fccd in PyEval_EvalFrameEx (f=0x8da00ec, throwflag=0) at
Python/ceval.c:3481
#16 0x08090f6b in PyEval_EvalCodeEx (co=0xb7b80410, globals=0xb7b75824,
locals=0x0, args=0x8d6ee98, argcount=2, kws=0x89e8058, kwcount=0,
defs=0x826a518, defcount=1,
kwdefs=0x0, closure=0x0) at Python/ceval.c:2830
#17 0x080fe855 in function_call (func=0x8267e6c, arg=0x8d6ee8c,
kw=0x8ccee84) at Objects/funcobject.c:628
#18 0x080d83a9 in PyObject_Call (func=0x8267e6c, arg=0x8d6ee8c,
kw=0x8ccee84) at Objects/abstract.c:2178
#19 0x0808d73f in PyEval_EvalFrameEx (f=0x8d9ff84, throwflag=0) at
Python/ceval.c:3694
#20 0x08090f6b in PyEval_EvalCodeEx (co=0xb7b80458, globals=0xb7b75824,
locals=0x0, args=0x8d7f078, argcount=2, kws=0x0, kwcount=0, defs=0x0,
defcount=0, kwdefs=0x0,
closure=0x0) at Python/ceval.c:2830
[...]
(gdb) pyo 0x8268458
object : <code object print_exception at 0x8268458, file
"/usr/local/python3.0b2/lib/python3.0/traceback.py", line 136>
type : code
refcount: 2
address : 0x8268458
$3 = void
----------------------
When I call "pystack", gdb seems to lock up using 100% CPU, so I'm not
sure what else I can provide. The crash happening in a non-trivial
doctest makes is somewhat tricky to figure out what gets executed here.
At least, there is no anticipated AttributeError in the doctest, and it
doesn't seem to get raised when I run the test just by itself.
----------
components: Interpreter Core
messages: 70253
nosy: scoder
severity: normal
status: open
title: crash on badly initialised AttributeError
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3443>
_______________________________________
From report at bugs.python.org Fri Jul 25 16:48:11 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 25 Jul 2008 14:48:11 +0000
Subject: [New-bugs-announce] [issue3444] add warnings for intra-package
imports
In-Reply-To: <1216997291.25.0.564093390831.issue3444@psf.upfronthosting.co.za>
Message-ID: <1216997291.25.0.564093390831.issue3444@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
Non-absolute or relative imports in 2.6 should give a Py3k warning.
----------
components: Interpreter Core
messages: 70254
nosy: benjamin.peterson
priority: release blocker
severity: normal
status: open
title: add warnings for intra-package imports
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3444>
_______________________________________
From report at bugs.python.org Fri Jul 25 17:26:55 2008
From: report at bugs.python.org (Antoine d'Otreppe)
Date: Fri, 25 Jul 2008 15:26:55 +0000
Subject: [New-bugs-announce] [issue3445] functools.update_wrapper bug
In-Reply-To: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za>
Message-ID: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za>
New submission from Antoine d'Otreppe <a.dotreppe at gmail.com>:
When trying to do something like
"functools.update_wrapper(myWrapper, str.split)"
I got this error message:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "Aspyct.py", line 175, in beforeCall
_stickAdvice(function, theAdvice)
File "Aspyct.py", line 90, in _stickAdvice
functools.update_wrapper(theAdvice, function)
File "/usr/lib/python2.5/functools.py", line 33, in update_wrapper
setattr(wrapper, attr, getattr(wrapped, attr))
AttributeError: 'method_descriptor' object has no attribute '__module__'
----------
components: Library (Lib)
messages: 70256
nosy: Antoine d'Otreppe
severity: normal
status: open
title: functools.update_wrapper bug
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3445>
_______________________________________
From report at bugs.python.org Fri Jul 25 17:59:23 2008
From: report at bugs.python.org (=?utf-8?q?Ignas_Mikalaj=C5=ABnas?=)
Date: Fri, 25 Jul 2008 15:59:23 +0000
Subject: [New-bugs-announce] [issue3446] center,
ljust and rjust are inconsistent with unicode parameters
In-Reply-To: <1217001563.39.0.568934696199.issue3446@psf.upfronthosting.co.za>
Message-ID: <1217001563.39.0.568934696199.issue3446@psf.upfronthosting.co.za>
New submission from Ignas Mikalaj?nas <ignas at pov.lt>:
Not all combinations of unicode/non-unicode parameters work for ljust,
center and rjust. Passing a unicode character to them as a parameter
when the string is ascii fails with an error.
This doctest fails in 3 places. Though I would expect it to be passing.
def doctest_strings():
"""
>>> uni = u"a"
>>> ascii = "a"
>>> uni.center(5, ascii)
u'aaaaa'
>>> uni.center(5, uni)
u'aaaaa'
>>> ascii.center(5, ascii)
'aaaaa'
>>> ascii.center(5, uni)
u'aaaaa'
>>> uni.ljust(5, ascii)
u'aaaaa'
>>> uni.ljust(5, uni)
u'aaaaa'
>>> ascii.ljust(5, ascii)
'aaaaa'
>>> ascii.ljust(5, uni)
u'aaaaa'
>>> uni.rjust(5, ascii)
u'aaaaa'
>>> uni.rjust(5, uni)
u'aaaaa'
>>> ascii.rjust(5, ascii)
'aaaaa'
>>> ascii.rjust(5, uni)
u'aaaaa'
"""
----------
components: Library (Lib), Unicode
messages: 70258
nosy: ignas
severity: normal
status: open
title: center, ljust and rjust are inconsistent with unicode parameters
type: behavior
versions: Python 2.4, Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3446>
_______________________________________
From report at bugs.python.org Fri Jul 25 18:51:15 2008
From: report at bugs.python.org (Alejandro J. Cura)
Date: Fri, 25 Jul 2008 16:51:15 +0000
Subject: [New-bugs-announce] [issue3447] itertools.izip_longest docs don't
specify default fillvalue
In-Reply-To: <1217004675.67.0.084485803306.issue3447@psf.upfronthosting.co.za>
Message-ID: <1217004675.67.0.084485803306.issue3447@psf.upfronthosting.co.za>
New submission from Alejandro J. Cura <alecu at vortech.com.ar>:
izip_longest default fillvalue is None, but the docs don't specify it.
I'm attaching a diff that fixes this.
----------
assignee: georg.brandl
components: Documentation
files: itertools.izip_longest-default-fillvalue.diff
keywords: patch
messages: 70259
nosy: alecu, georg.brandl
severity: normal
status: open
title: itertools.izip_longest docs don't specify default fillvalue
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file10980/itertools.izip_longest-default-fillvalue.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3447>
_______________________________________
From report at bugs.python.org Fri Jul 25 23:06:38 2008
From: report at bugs.python.org (Nick Edds)
Date: Fri, 25 Jul 2008 21:06:38 +0000
Subject: [New-bugs-announce] [issue3448] Multi-process 2to3
In-Reply-To: <1217019998.69.0.231122552254.issue3448@psf.upfronthosting.co.za>
Message-ID: <1217019998.69.0.231122552254.issue3448@psf.upfronthosting.co.za>
New submission from Nick Edds <nedds at uchicago.edu>:
Here is a working, multiprocess version of 2to3 with a few caveats.
First, you need to already have the processing module installed for this
to work. If we don't want to include processing in some way, I think I
can modify this to only import processing and use the Process method if
the user wants to run it with more than one process. Also, I know that
logger is supposed to be thread safe, so I am correct in assuming that
this means it is also multi-process safe? This fix delegates the fixing
of files to a designated number of processes, so on a multi-core
machine, it is significantly faster. It may be appropriate to add a test
suite for it, but I have not yet done so. I've tested it on my dual-core
laptop running Ubuntu and a quad-core mac and it appears to be working
fine. I don't know if the use of tempfile was the right choice, but it
seemed reasonable. Another possibility is to instead using a processing
Queue and pass it the output, filename, and input rather than calling
write_file. Also, the join timeout I used is completely arbitrary
because I don't really have a sense of what a reasonable value for it
should be.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: multiProcess.diff
keywords: patch
messages: 70277
nosy: collinwinter, nedds
severity: normal
status: open
title: Multi-process 2to3
type: performance
Added file: http://bugs.python.org/file10985/multiProcess.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3448>
_______________________________________
From report at bugs.python.org Sat Jul 26 00:16:13 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 25 Jul 2008 22:16:13 +0000
Subject: [New-bugs-announce] [issue3449] Update decimal module to version
1.68 of the IBM specification
In-Reply-To: <1217024173.73.0.509387399597.issue3449@psf.upfronthosting.co.za>
Message-ID: <1217024173.73.0.509387399597.issue3449@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
The IBM General Decimal Arithmetic Specification, on which the decimal
module is based, has recently been updated to version 1.68; the
testcases from IBM have also been updated.
The comments in the decimal module clearly state that the decimal module
should be kept in sync with the IBM specification, and that deviation
from the spec is considered a bug. So it seems to me that the decimal
module should be updated, preferably before 2.6 and 3.0 come out.
As far as I can tell the required changes should be minimal: max-
magnitude and min-magnitude definitely need changing, and there may be
other minor changes necessary to make the new tests pass; I haven't
looked properly yet. I'll try to get to this in the next few days.
----------
assignee: marketdickinson
components: Library (Lib)
messages: 70284
nosy: facundobatista, marketdickinson, rhettinger
priority: critical
severity: normal
status: open
title: Update decimal module to version 1.68 of the IBM specification
type: behavior
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3449>
_______________________________________
From report at bugs.python.org Sat Jul 26 13:40:21 2008
From: report at bugs.python.org (Nobody/Anonymous)
Date: Sat, 26 Jul 2008 11:40:21 +0000
Subject: [New-bugs-announce] [issue3450] Buy stocks now to make money
In-Reply-To: <000601c8ef14$6216e0b0$fdfea37a@San>
Message-ID: <000601c8ef14$6216e0b0$fdfea37a@San>
New submission from Nobody/Anonymous:
Your wife says his bed skills are better than yours http://kwhgs.ca/topnews.html
----------
files: unnamed
messages: 70297
nosy: nobody
severity: normal
status: open
title: Buy stocks now to make money
Added file: http://bugs.python.org/file10989/unnamed
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3450>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20080726/8f9e9f76/attachment.txt>
From report at bugs.python.org Sun Jul 27 03:11:05 2008
From: report at bugs.python.org (Fredrik Johansson)
Date: Sun, 27 Jul 2008 01:11:05 +0000
Subject: [New-bugs-announce] [issue3451] Asymptotically faster divmod and
str(long)
In-Reply-To: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za>
Message-ID: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za>
New submission from Fredrik Johansson <fredrik.johansson at gmail.com>:
A few weeks ago, I blogged about taking advantage of Karatsuba
multiplication and Newton's method to divide big integers quickly (some
of you may have read it, as it was posted to Daily Python-URL among
other places):
http://fredrik-j.blogspot.com/2008/07/making-division-in-python-faster.html
To summarize, this method blows the builtin division out of the water
already at ~(2000 digits)/(1000 digits).
The primary catch is that the result of the Newton division may be
slightly wrong (typically 1 ulp). However, a single extra multiplication
and a subtraction at the end allows one to compute a remainder, and
since the remainder must satisfy 0 <= r < q, the error is easily
corrected. From a quick test, the cost of the extra multiplication seems
to move the break-even point with the builtin division up to around
5000/2500 digits.
A pure Python implementation of divmod, with error correction based on
the remainder, can be found in this file:
http://www.dd.chalmers.se/~frejohl/code/libarith/libarith.py
(See the function idivmod)
Of particular note is that fast divmod gives a fast way to do radix
conversion, by recursively splitting the number in half. The function
numeral (see same .py file) does this, e.g:
>>> from time import clock
>>> a = 2**1257787-1
>>> t1=clock(); s1=str(a); t2=clock(); t2-t1
109.08065159119386
>>> t1=clock(); s2=numeral(a); t2=clock(); t2-t1
7.1394886780303182
>>> s1 == s2
True
(This recursive algorithm, by the way, is actually faster than str()
even with the slow builtin divmod.)
Would there be any interest in porting these algorithms to C and using
them in the standard Python long implementation?
There are likely some problems that I have overlooked. A critical review
will be most welcome.
----------
components: Interpreter Core
messages: 70309
nosy: fredrikj
severity: normal
status: open
title: Asymptotically faster divmod and str(long)
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3451>
_______________________________________
From report at bugs.python.org Sun Jul 27 16:39:39 2008
From: report at bugs.python.org (lregebro)
Date: Sun, 27 Jul 2008 14:39:39 +0000
Subject: [New-bugs-announce] [issue3452] subprocess.Popen description
unclear.
In-Reply-To: <1217169579.5.0.521766841599.issue3452@psf.upfronthosting.co.za>
Message-ID: <1217169579.5.0.521766841599.issue3452@psf.upfronthosting.co.za>
New submission from lregebro <regebro at gmail.com>:
In the documentation of subprocess.Popen the docs say:
"args should be a string, or a sequence of program arguments. The
program to execute is normally the first item in the args sequence or
string, but can be explicitly set by using the executable argument. "
The statement that the program to exectute is the "first item in the
args sequence or string" indicates that the first item in a string like
"ls -l", i.e. the "ls" will be the program. The next paragraph however
makes it clear that this is not the case, but by then the damage is
done, and you think that passing in "ls -l" will work.
Rewording this, perhaps by saying "The program to execute is normally
the first item in the args sequence, or the string if a string a given",
would make this clear.
----------
assignee: georg.brandl
components: Documentation
messages: 70321
nosy: georg.brandl, lregebro
severity: normal
status: open
title: subprocess.Popen description unclear.
versions: Python 2.5, Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3452>
_______________________________________
From report at bugs.python.org Sun Jul 27 17:14:05 2008
From: report at bugs.python.org (Roger Upole)
Date: Sun, 27 Jul 2008 15:14:05 +0000
Subject: [New-bugs-announce] [issue3453] PyType_Ready doesn't ensure that
all bases are ready
In-Reply-To: <1217171645.31.0.486361917431.issue3453@psf.upfronthosting.co.za>
Message-ID: <1217171645.31.0.486361917431.issue3453@psf.upfronthosting.co.za>
New submission from Roger Upole <rupole at hotmail.com>:
If a type's tp_base has not been initialized yet, PyType_Ready calls
itself for tp_base. However, it doesn't do the same for members of
tp_bases. The inheritance determinations assume that all bases are
ready, in particular that tp_mro is not null.
----------
components: Interpreter Core
messages: 70322
nosy: rupole
severity: normal
status: open
title: PyType_Ready doesn't ensure that all bases are ready
versions: Python 2.4, Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3453>
_______________________________________
From report at bugs.python.org Sun Jul 27 21:58:01 2008
From: report at bugs.python.org (John Firestone)
Date: Sun, 27 Jul 2008 19:58:01 +0000
Subject: [New-bugs-announce] [issue3454] __getitem__() doesn't capture all
slices if class inherits from list, tuple or str
Message-ID: <1217188681.81.0.529319728995.issue3454@psf.upfronthosting.co.za>
Changes by John Firestone <johnf at freenet.de>:
----------
components: Interpreter Core
files: getitem_problem.py
nosy: johnf
severity: normal
status: open
title: __getitem__() doesn't capture all slices if class inherits from list, tuple or str
type: performance
versions: Python 2.5
Added file: http://bugs.python.org/file10992/getitem_problem.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3454>
_______________________________________
From report at bugs.python.org Mon Jul 28 02:40:09 2008
From: report at bugs.python.org (=?utf-8?q?=E9=A6=99=E6=A7=9F=E9=85=92?=)
Date: Mon, 28 Jul 2008 00:40:09 +0000
Subject: [New-bugs-announce] [issue3455] os.remove()method document error
In-Reply-To: <1217205609.34.0.035982890049.issue3455@psf.upfronthosting.co.za>
Message-ID: <1217205609.34.0.035982890049.issue3455@psf.upfronthosting.co.za>
New submission from ??? <zkfarmer at gmail.com>:
in Python 2.5 document, os.remove() explain: On Windows, attempting to
remove a file that is in use causes an exception to be raised. but, i
run it in IDLE.it deletes my file that in use without any exception.
----------
assignee: georg.brandl
components: Documentation
messages: 70334
nosy: georg.brandl, zkfarmer
severity: normal
status: open
title: os.remove()method document error
type: performance
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3455>
_______________________________________
From report at bugs.python.org Mon Jul 28 09:46:48 2008
From: report at bugs.python.org (Xue Can)
Date: Mon, 28 Jul 2008 07:46:48 +0000
Subject: [New-bugs-announce] [issue3456] compile python using MinGW
In-Reply-To: <1217231208.12.0.680278518143.issue3456@psf.upfronthosting.co.za>
Message-ID: <1217231208.12.0.680278518143.issue3456@psf.upfronthosting.co.za>
New submission from Xue Can <xuecan at gmail.com>:
I hope the official source release can add support for MinGW
to compile python under Win32 platform. And layout built files
like python in Unix-like paltforms.
----------
components: Build
messages: 70338
nosy: xuecan
severity: normal
status: open
title: compile python using MinGW
type: feature request
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3456>
_______________________________________
From report at bugs.python.org Mon Jul 28 14:49:40 2008
From: report at bugs.python.org (Cliff Dyer)
Date: Mon, 28 Jul 2008 12:49:40 +0000
Subject: [New-bugs-announce] [issue3457] Release notes for 2.6b2 call it an
alpha release
In-Reply-To: <1217249380.52.0.254772841824.issue3457@psf.upfronthosting.co.za>
Message-ID: <1217249380.52.0.254772841824.issue3457@psf.upfronthosting.co.za>
New submission from Cliff Dyer <jcd at sdf.lonestar.org>:
The release notes for python 2.6b2 at
http://www.python.org/download/releases/2.6/ identify the release as an
alpha release. I'm not sure, but the disclaimer regarding who should
use it might need changing too.
alpha != beta
----------
assignee: georg.brandl
components: Documentation
messages: 70345
nosy: georg.brandl, jcd
severity: normal
status: open
title: Release notes for 2.6b2 call it an alpha release
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3457>
_______________________________________
From report at bugs.python.org Mon Jul 28 18:24:27 2008
From: report at bugs.python.org (David Farrar)
Date: Mon, 28 Jul 2008 16:24:27 +0000
Subject: [New-bugs-announce] [issue3458] dict.update() optimisation gives
unexpected/invalid results when passed a subclass of DictType
In-Reply-To: <1217262267.3.0.619120390948.issue3458@psf.upfronthosting.co.za>
Message-ID: <1217262267.3.0.619120390948.issue3458@psf.upfronthosting.co.za>
New submission from David Farrar <pythonbugs at spam.decafbad.co.uk>:
Using a python module that expected me to pass a dictionary as a
parameter to a function, I found that I was getting unexpected results
when using a class which inherits from types.DictType.
The module was passing the instance I had supplied as a parameter to
update() on a newly created dictionary. I wanted my class to present its
methods as items of the dictionary it was pretending to be. Even though
I could see that __getattribute__ had been called to get 'keys', keys()
was not called and I ended up with an empty dictionary.
Trying to find the cause of the problem, I downloaded the python source
package and found that in PyDict_Merge (in Objects/dictobject.c, line
1359), there is an optimisation that is run if PyDict_Check determines
that the parameter we passed is itself a dictionary. The optimisation
takes advantage of the fact that we know how data is stored in the
dictionary and accesses whatever it needs directly.
I had overridden keys() to provide the result I wanted but this
optimisation prevented the code from ever being run, leading to code
that seems like it should work failing with no apparent cause. The only
way I could find around this was to raise AttributeError in
__getattribute__ when getting 'keys', causing dict_update_common to call
PyDict_MergeFromSeq2 in place of PyDict_Merge.
Should the call to PyDict_Check in PyDict_Merge not be replaced with
PyDict_CheckExact ? This would keep the optimisation in place in most
cases, where we know that it is safe, still allowing keys() to be
overridden as you expect.
----------
components: Interpreter Core
files: dictionary.patch
keywords: patch
messages: 70353
nosy: david
severity: normal
status: open
title: dict.update() optimisation gives unexpected/invalid results when passed a subclass of DictType
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file10997/dictionary.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3458>
_______________________________________
From report at bugs.python.org Mon Jul 28 20:51:27 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Jul 2008 18:51:27 +0000
Subject: [New-bugs-announce] [issue3459] optimize bytes.join()
In-Reply-To: <1217271087.67.0.340515094657.issue3459@psf.upfronthosting.co.za>
Message-ID: <1217271087.67.0.340515094657.issue3459@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
When the separator is empty and the sequence only contains one non-empty
item, it is possible to optimize b"".join([...]) by simply returning the
non-empty item.
Since b"".join() is the recommended idiom to join large strings
together, I think it can be useful. I encountered this when trying to
optimize io.BufferedReader.
./python -m timeit -s "l=[b'', b'a' * 10000]" "b''.join(l)"
before the patch:
100000 loops, best of 3: 2.35 usec per loop
after the patch:
1000000 loops, best of 3: 0.335 usec per loop
----------
components: Interpreter Core
files: bytesjoin.patch
keywords: patch
messages: 70365
nosy: pitrou
severity: normal
status: open
title: optimize bytes.join()
type: performance
versions: Python 3.0
Added file: http://bugs.python.org/file10999/bytesjoin.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3459>
_______________________________________
From report at bugs.python.org Mon Jul 28 21:04:38 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Jul 2008 19:04:38 +0000
Subject: [New-bugs-announce] [issue3460] PyUnicode_Join could perhaps be
simpler
In-Reply-To: <1217271878.68.0.784852839744.issue3460@psf.upfronthosting.co.za>
Message-ID: <1217271878.68.0.784852839744.issue3460@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
In py3k, PyUnicode_Join inherits some complexity from the 2.x days.
However, it seems some of the precautions taken there may not be needed
anymore. Witness the following comment:
/* Grrrr. A codec may be invoked to convert str objects to
* Unicode, and so it's possible to call back into Python code
* during PyUnicode_FromObject(), and so it's possible for a sick
* codec to change the size of fseq (if seq is a list). Therefore
* we have to keep refetching the size -- can't assume seqlen
* is invariant.
*/
Perhaps it would also allow to preallocate the target buffer all at once
(like bytes.join does) rather than resize it incrementally.
Marc-Andre, what do you think?
----------
components: Unicode
messages: 70367
nosy: lemburg, pitrou
priority: normal
severity: normal
status: open
title: PyUnicode_Join could perhaps be simpler
type: performance
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3460>
_______________________________________
From report at bugs.python.org Tue Jul 29 00:08:45 2008
From: report at bugs.python.org (Derek Morr)
Date: Mon, 28 Jul 2008 22:08:45 +0000
Subject: [New-bugs-announce] [issue3461] smtplib does not fully support IPv6
in EHLO
In-Reply-To: <1217282925.26.0.916204427354.issue3461@psf.upfronthosting.co.za>
Message-ID: <1217282925.26.0.916204427354.issue3461@psf.upfronthosting.co.za>
New submission from Derek Morr <derekmorr at psu.edu>:
On an IPv6-only machine, smtplib does not send an IPv6 address in the
EHLO. It sends "EHLO [0.0.0.0]" instead. For example, on a v6-only
network with stateless autoconfiguration enabled (a common
configuration), smtplib will show this error.
Further, SMTP's __init__() method tries to determine the value of EHLO
parameter before the socket is established. But it can't know what
value to use before the socket is setup (e.g., should it use a
hostname, a v4 address literal, or a v6 address literal).
The attached patch moves the self.local_hostname processing into the
connect() method, and updates it to use IPv6-aware resolver interfaces.
----------
components: Library (Lib)
files: python_smtplib.patch
keywords: patch
messages: 70372
nosy: dmorr
severity: normal
status: open
title: smtplib does not fully support IPv6 in EHLO
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file11000/python_smtplib.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3461>
_______________________________________
From report at bugs.python.org Tue Jul 29 04:06:35 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 29 Jul 2008 02:06:35 +0000
Subject: [New-bugs-announce] [issue3462] test_builtin fails after
test_decimal
In-Reply-To: <1217297195.52.0.306735068068.issue3462@psf.upfronthosting.co.za>
Message-ID: <1217297195.52.0.306735068068.issue3462@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
In Py3k:
$ ./python Lib/test/regrtest.py test_decimal test_builtin
test_decimal
test_builtin
test test_builtin failed -- Traceback (most recent call last):
File "Lib/test/regrtest.py", line 603, in runtest_inner
indirect_test()
File "/temp/python/py3k/Lib/test/test_builtin.py", line 1252, in test_main
run_unittest(*test_classes)
File "/temp/python/py3k/Lib/test/support.py", line 717, in run_unittest
_run_suite(suite)
File "/temp/python/py3k/Lib/test/support.py", line 700, in _run_suite
raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
File "/temp/python/py3k/Lib/test/test_builtin.py", line 390, in
test_general_eval
self.assertEqual(eval('globals()', g, m), g)
AssertionError: {'unittest': <module 'unittest' from
'/temp/python/py3k/Lib/unittest.py'>, 'random': <module 'random' from
'/temp/python/py3k/Lib/random.py'>, 'test_conv_no_sign': [('0', 0),
('1', 1), ('9', 9), ('10', 10), ('99', 99), ('100', 100), ('314', 314),
(' 314', 314), ('314 ', 314), (' \t\t 314 \t\t ', 314),
('2147483647', 2147483647), (' 1x', <class 'ValueError'>), (' 1 ',
1), (' 1\x02 ', <class 'ValueError'>), ('', <class 'ValueError'>), ('
', <class 'ValueError'>), (' \t\t ', <class 'ValueError'>),
('\u0663\u0661\u0664 ', 314), ('\u0200', <class 'ValueError'>)],
'test_conv_sign': [('0', 0), ('1', 1), ('9', 9), ('10', 10), ('99', 99),
('100', 100), ('314', 314), (' 314', <class 'ValueError'>), ('314 ',
314), (' \t\t 314 \t\t ', <class 'ValueError'>), ('2147483647',
2147483647), (' 1x', <class 'ValueError'>), (' 1 ', <class
'ValueError'>), (' 1\x02 ', <class 'ValueError'>), ('', <class
'ValueError'>), (' ', <class 'ValueError'>), (' \t\t ', <class
'ValueError'>), ('\u0663\u0661\u0664 ', 314), ('\u0200', <class
'ValueError'>)], 'run_with_locale': <function run_with_locale at
0x10b0390>, 'io': <module 'io' from '/temp/python/py3k/Lib/io.py'>,
'Squares': <class 'test.test_builtin.Squares'>, 'neg': <built-in
function neg>, '__package__': None, 'collections': <module 'collections'
from '/temp/python/py3k/Lib/collections.py'>, 'TestFailingIter': <class
'test.test_builtin.TestFailingIter'>, 'run_unittest': <function
run_unittest at 0x10b0540>, '__doc__': None, 'test_main': <function
test_main at 0x1474390>, 'fractions': <module 'fractions' from
'/temp/python/py3k/Lib/fractions.py'>, 'StrSquares': <class
'test.test_builtin.StrSquares'>, 'warnings': <module 'warnings' from
'/temp/python/py3k/Lib/warnings.py'>, '__builtins__': {'bytearray':
<class 'bytearray'>, 'IndexError': <class 'IndexError'>, 'all':
<built-in function all>, 'help': Type help() for interactive help, or
help(object) for help about object., 'vars': <built-in function vars>,
'SyntaxError': <class 'SyntaxError'>, 'UnicodeDecodeError': <class
'UnicodeDecodeError'>, 'memoryview': <class 'memoryview'>, 'isinstance':
<built-in function isinstance>, '__build_class__': <built-in function
__build_class__>, 'copyright': Copyright (c) 2001-2008 Python Software
Foundation.
All Rights Reserved.
Copyright (c) 2000 BeOpen.com.
All Rights Reserved.
Copyright (c) 1995-2001 Corporation for National Research Initiatives.
All Rights Reserved.
Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam.
All Rights Reserved., 'NameError': <class 'NameError'>, 'BytesWarning':
<class 'BytesWarning'>, 'dict': <class 'dict'>, 'IOError': <class
'IOError'>, 'oct': <built-in function oct>, 'bin': <built-in function
bin>, 'SystemExit': <class 'SystemExit'>, 'format': <built-in function
format>, 'repr': <built-in function repr>, 'sorted': <built-in function
sorted>, 'False': False, 'RuntimeWarning': <class 'RuntimeWarning'>,
'list': <class 'list'>, 'iter': <built-in function iter>, 'Warning':
<class 'Warning'>, '__package__': None, 'round': <built-in function
round>, 'dir': <built-in function dir>, 'cmp': <built-in function cmp>,
'set': <class 'set'>, 'bytes': <class 'bytes'>, 'UnicodeTranslateError':
<class 'UnicodeTranslateError'>, 'issubclass': <built-in function
issubclass>, 'EOFError': <class 'EOFError'>, 'locals': <built-in
function locals>, 'BufferError': <class 'BufferError'>, 'slice': <class
'slice'>, 'FloatingPointError': <class 'FloatingPointError'>, 'sum':
<built-in function sum>, 'getattr': <built-in function getattr>, 'abs':
<built-in function abs>, 'exit': Use exit() or Ctrl-D (i.e. EOF) to
exit, 'print': <built-in function print>, 'True': True, 'FutureWarning':
<class 'FutureWarning'>, 'ImportWarning': <class 'ImportWarning'>,
'None': None, 'hash': <built-in function hash>, 'ReferenceError': <class
'ReferenceError'>, 'len': <built-in function len>, 'credits': Thanks
to CWI, CNRI, BeOpen.com, Zope Corporation and a cast of thousands
for supporting Python development. See www.python.org for more
information., 'frozenset': <class 'frozenset'>, '__name__': 'builtins',
'ord': <built-in function ord>, 'super': <class 'super'>, '_':
Decimal('NaN123'), 'TypeError': <class 'TypeError'>, 'license': Type
license() to see the full license text, 'KeyboardInterrupt': <class
'KeyboardInterrupt'>, 'UserWarning': <class 'UserWarning'>, 'filter':
<class 'filter'>, 'range': <class 'range'>, 'staticmethod': <class
'staticmethod'>, 'SystemError': <class 'SystemError'>, 'BaseException':
<class 'BaseException'>, 'pow': <built-in function pow>, 'RuntimeError':
<class 'RuntimeError'>, 'float': <class 'float'>, 'MemoryError': <class
'MemoryError'>, 'StopIteration': <class 'StopIteration'>, 'globals':
<built-in function globals>, 'divmod': <built-in function divmod>,
'enumerate': <class 'enumerate'>, 'Ellipsis': Ellipsis, 'LookupError':
<class 'LookupError'>, 'open': <class 'io.OpenWrapper'>, 'quit': Use
quit() or Ctrl-D (i.e. EOF) to exit, 'UnicodeError': <class
'UnicodeError'>, 'zip': <class 'zip'>, 'hex': <built-in function hex>,
'next': <built-in function next>, 'ImportError': <class 'ImportError'>,
'chr': <built-in function chr>, 'type': <class 'type'>, '__doc__':
"Built-in functions, exceptions, and other objects.\n\nNoteworthy: None
is the `nil' object; Ellipsis represents `...' in slices.", 'Exception':
<class 'Exception'>, 'tuple': <class 'tuple'>, 'reversed': <class
'reversed'>, 'UnicodeEncodeError': <class 'UnicodeEncodeError'>,
'input': <built-in function input>, 'hasattr': <built-in function
hasattr>, 'delattr': <built-in function delattr>, 'setattr': <built-in
function setattr>, 'SyntaxWarning': <class 'SyntaxWarning'>, 'compile':
<built-in function compile>, 'ArithmeticError': <class
'ArithmeticError'>, 'str': <class 'str'>, 'property': <class
'property'>, 'GeneratorExit': <class 'GeneratorExit'>, 'int': <class
'int'>, '__import__': <built-in function __import__>, 'KeyError': <class
'KeyError'>, 'PendingDeprecationWarning': <class
'PendingDeprecationWarning'>, 'EnvironmentError': <class
'EnvironmentError'>, 'ascii': <built-in function ascii>, 'id': <built-in
function id>, 'OSError': <class 'OSError'>, 'DeprecationWarning': <class
'DeprecationWarning'>, 'min': <built-in function min>, 'UnicodeWarning':
<class 'UnicodeWarning'>, 'any': <built-in function any>, 'complex':
<class 'complex'>, 'bool': <class 'bool'>, 'ValueError': <class
'ValueError'>, 'NotImplemented': NotImplemented, 'map': <class 'map'>,
'exec': <built-in function exec>, 'max': <built-in function max>,
'object': <class 'object'>, 'TabError': <class 'TabError'>,
'ZeroDivisionError': <class 'ZeroDivisionError'>, 'eval': <built-in
function eval>, '__debug__': True, 'IndentationError': <class
'IndentationError'>, 'AssertionError': <class 'AssertionError'>,
'classmethod': <class 'classmethod'>, 'UnboundLocalError': <class
'UnboundLocalError'>, 'NotImplementedError': <class
'NotImplementedError'>, 'AttributeError': <class 'AttributeError'>,
'OverflowError': <class 'OverflowError'>}, '__file__':
'/temp/python/py3k/Lib/test/test_builtin.py', 'BuiltinTest': <class
'test.test_builtin.BuiltinTest'>, 'TestFailingBool': <class
'test.test_builtin.TestFailingBool'>, 'sys': <module 'sys' (built-in)>,
'test': <module 'test' from '/temp/python/py3k/Lib/test/__init__.py'>,
'__name__': 'test.test_builtin', 'unlink': <function unlink at
0x7a5540>, 'TESTFN': '@test', 'TestSorted': <class
'test.test_builtin.TestSorted'>, 'BitBucket': <class
'test.test_builtin.BitBucket'>, 'fcmp': <function fcmp at 0x7ad540>} !=
{'unittest': <module 'unittest' from
'/temp/python/py3k/Lib/unittest.py'>, 'random': <module 'random' from
'/temp/python/py3k/Lib/random.py'>, 'test_conv_no_sign': [('0', 0),
('1', 1), ('9', 9), ('10', 10), ('99', 99), ('100', 100), ('314', 314),
(' 314', 314), ('314 ', 314), (' \t\t 314 \t\t ', 314),
('2147483647', 2147483647), (' 1x', <class 'ValueError'>), (' 1 ',
1), (' 1\x02 ', <class 'ValueError'>), ('', <class 'ValueError'>), ('
', <class 'ValueError'>), (' \t\t ', <class 'ValueError'>),
('\u0663\u0661\u0664 ', 314), ('\u0200', <class 'ValueError'>)],
'test_conv_sign': [('0', 0), ('1', 1), ('9', 9), ('10', 10), ('99', 99),
('100', 100), ('314', 314), (' 314', <class 'ValueError'>), ('314 ',
314), (' \t\t 314 \t\t ', <class 'ValueError'>), ('2147483647',
2147483647), (' 1x', <class 'ValueError'>), (' 1 ', <class
'ValueError'>), (' 1\x02 ', <class 'ValueError'>), ('', <class
'ValueError'>), (' ', <class 'ValueError'>), (' \t\t ', <class
'ValueError'>), ('\u0663\u0661\u0664 ', 314), ('\u0200', <class
'ValueError'>)], 'run_with_locale': <function run_with_locale at
0x10b0390>, 'io': <module 'io' from '/temp/python/py3k/Lib/io.py'>,
'Squares': <class 'test.test_builtin.Squares'>, 'neg': <built-in
function neg>, '__package__': None, 'collections': <module 'collections'
from '/temp/python/py3k/Lib/collections.py'>, 'TestFailingIter': <class
'test.test_builtin.TestFailingIter'>, 'run_unittest': <function
run_unittest at 0x10b0540>, '__doc__': None, 'test_main': <function
test_main at 0x1474390>, 'fractions': <module 'fractions' from
'/temp/python/py3k/Lib/fractions.py'>, 'StrSquares': <class
'test.test_builtin.StrSquares'>, 'warnings': <module 'warnings' from
'/temp/python/py3k/Lib/warnings.py'>, '__builtins__': {'bytearray':
<class 'bytearray'>, 'IndexError': <class 'IndexError'>, 'all':
<built-in function all>, 'help': Type help() for interactive help, or
help(object) for help about object., 'vars': <built-in function vars>,
'SyntaxError': <class 'SyntaxError'>, 'UnicodeDecodeError': <class
'UnicodeDecodeError'>, 'memoryview': <class 'memoryview'>, 'isinstance':
<built-in function isinstance>, '__build_class__': <built-in function
__build_class__>, 'copyright': Copyright (c) 2001-2008 Python Software
Foundation.
All Rights Reserved.
Copyright (c) 2000 BeOpen.com.
All Rights Reserved.
Copyright (c) 1995-2001 Corporation for National Research Initiatives.
All Rights Reserved.
Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam.
All Rights Reserved., 'NameError': <class 'NameError'>, 'BytesWarning':
<class 'BytesWarning'>, 'dict': <class 'dict'>, 'IOError': <class
'IOError'>, 'oct': <built-in function oct>, 'bin': <built-in function
bin>, 'SystemExit': <class 'SystemExit'>, 'format': <built-in function
format>, 'repr': <built-in function repr>, 'sorted': <built-in function
sorted>, 'False': False, 'RuntimeWarning': <class 'RuntimeWarning'>,
'list': <class 'list'>, 'iter': <built-in function iter>, 'Warning':
<class 'Warning'>, '__package__': None, 'round': <built-in function
round>, 'dir': <built-in function dir>, 'cmp': <built-in function cmp>,
'set': <class 'set'>, 'bytes': <class 'bytes'>, 'UnicodeTranslateError':
<class 'UnicodeTranslateError'>, 'issubclass': <built-in function
issubclass>, 'EOFError': <class 'EOFError'>, 'locals': <built-in
function locals>, 'BufferError': <class 'BufferError'>, 'slice': <class
'slice'>, 'FloatingPointError': <class 'FloatingPointError'>, 'sum':
<built-in function sum>, 'getattr': <built-in function getattr>, 'abs':
<built-in function abs>, 'exit': Use exit() or Ctrl-D (i.e. EOF) to
exit, 'print': <built-in function print>, 'True': True, 'FutureWarning':
<class 'FutureWarning'>, 'ImportWarning': <class 'ImportWarning'>,
'None': None, 'hash': <built-in function hash>, 'ReferenceError': <class
'ReferenceError'>, 'len': <built-in function len>, 'credits': Thanks
to CWI, CNRI, BeOpen.com, Zope Corporation and a cast of thousands
for supporting Python development. See www.python.org for more
information., 'frozenset': <class 'frozenset'>, '__name__': 'builtins',
'ord': <built-in function ord>, 'super': <class 'super'>, '_':
Decimal('NaN123'), 'TypeError': <class 'TypeError'>, 'license': Type
license() to see the full license text, 'KeyboardInterrupt': <class
'KeyboardInterrupt'>, 'UserWarning': <class 'UserWarning'>, 'filter':
<class 'filter'>, 'range': <class 'range'>, 'staticmethod': <class
'staticmethod'>, 'SystemError': <class 'SystemError'>, 'BaseException':
<class 'BaseException'>, 'pow': <built-in function pow>, 'RuntimeError':
<class 'RuntimeError'>, 'float': <class 'float'>, 'MemoryError': <class
'MemoryError'>, 'StopIteration': <class 'StopIteration'>, 'globals':
<built-in function globals>, 'divmod': <built-in function divmod>,
'enumerate': <class 'enumerate'>, 'Ellipsis': Ellipsis, 'LookupError':
<class 'LookupError'>, 'open': <class 'io.OpenWrapper'>, 'quit': Use
quit() or Ctrl-D (i.e. EOF) to exit, 'UnicodeError': <class
'UnicodeError'>, 'zip': <class 'zip'>, 'hex': <built-in function hex>,
'next': <built-in function next>, 'ImportError': <class 'ImportError'>,
'chr': <built-in function chr>, 'type': <class 'type'>, '__doc__':
"Built-in functions, exceptions, and other objects.\n\nNoteworthy: None
is the `nil' object; Ellipsis represents `...' in slices.", 'Exception':
<class 'Exception'>, 'tuple': <class 'tuple'>, 'reversed': <class
'reversed'>, 'UnicodeEncodeError': <class 'UnicodeEncodeError'>,
'input': <built-in function input>, 'hasattr': <built-in function
hasattr>, 'delattr': <built-in function delattr>, 'setattr': <built-in
function setattr>, 'SyntaxWarning': <class 'SyntaxWarning'>, 'compile':
<built-in function compile>, 'ArithmeticError': <class
'ArithmeticError'>, 'str': <class 'str'>, 'property': <class
'property'>, 'GeneratorExit': <class 'GeneratorExit'>, 'int': <class
'int'>, '__import__': <built-in function __import__>, 'KeyError': <class
'KeyError'>, 'PendingDeprecationWarning': <class
'PendingDeprecationWarning'>, 'EnvironmentError': <class
'EnvironmentError'>, 'ascii': <built-in function ascii>, 'id': <built-in
function id>, 'OSError': <class 'OSError'>, 'DeprecationWarning': <class
'DeprecationWarning'>, 'min': <built-in function min>, 'UnicodeWarning':
<class 'UnicodeWarning'>, 'any': <built-in function any>, 'complex':
<class 'complex'>, 'bool': <class 'bool'>, 'ValueError': <class
'ValueError'>, 'NotImplemented': NotImplemented, 'map': <class 'map'>,
'exec': <built-in function exec>, 'max': <built-in function max>,
'object': <class 'object'>, 'TabError': <class 'TabError'>,
'ZeroDivisionError': <class 'ZeroDivisionError'>, 'eval': <built-in
function eval>, '__debug__': True, 'IndentationError': <class
'IndentationError'>, 'AssertionError': <class 'AssertionError'>,
'classmethod': <class 'classmethod'>, 'UnboundLocalError': <class
'UnboundLocalError'>, 'NotImplementedError': <class
'NotImplementedError'>, 'AttributeError': <class 'AttributeError'>,
'OverflowError': <class 'OverflowError'>}, '__file__':
'/temp/python/py3k/Lib/test/test_builtin.py', 'BuiltinTest': <class
'test.test_builtin.BuiltinTest'>, 'TestFailingBool': <class
'test.test_builtin.TestFailingBool'>, 'sys': <module 'sys' (built-in)>,
'test': <module 'test' from '/temp/python/py3k/Lib/test/__init__.py'>,
'__name__': 'test.test_builtin', 'unlink': <function unlink at
0x7a5540>, 'TESTFN': '@test', 'TestSorted': <class
'test.test_builtin.TestSorted'>, 'BitBucket': <class
'test.test_builtin.BitBucket'>, 'fcmp': <function fcmp at 0x7ad540>}
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "Lib/test/regrtest.py", line 1197, in <module>
main()
File "Lib/test/regrtest.py", line 411, in main
testdir, huntrleaks)
File "Lib/test/regrtest.py", line 570, in runtest
testdir, huntrleaks)
File "Lib/test/regrtest.py", line 623, in runtest_inner
print("test", test, "failed --", msg)
File "/temp/python/py3k/Lib/io.py", line 1459, in write
b = encoder.encode(s)
File "/temp/python/py3k/Lib/encodings/ascii.py", line 22, in encode
return codecs.ascii_encode(input, self.errors)[0]
UnicodeEncodeError: 'ascii' codec can't encode characters in position
697-699: ordinal not in range(128)
----------
messages: 70374
nosy: benjamin.peterson
priority: critical
severity: normal
status: open
title: test_builtin fails after test_decimal
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3462>
_______________________________________
From report at bugs.python.org Tue Jul 29 04:29:34 2008
From: report at bugs.python.org (mvngu)
Date: Tue, 29 Jul 2008 02:29:34 +0000
Subject: [New-bugs-announce] [issue3463] make life.py use more rendering
characters
In-Reply-To: <1217298574.14.0.239193777363.issue3463@psf.upfronthosting.co.za>
Message-ID: <1217298574.14.0.239193777363.issue3463@psf.upfronthosting.co.za>
New submission from mvngu <nguyenminh2 at gmail.com>:
Allows life.py to use other characters for rendering (alphanumeric plus
punctuation characters), apart from the default asterisk "*". The
rendering character can be specified from the command line.
----------
components: Demos and Tools
files: life.py.diff
keywords: patch
messages: 70375
nosy: mvngu
severity: normal
status: open
title: make life.py use more rendering characters
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11001/life.py.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3463>
_______________________________________
From report at bugs.python.org Tue Jul 29 08:49:56 2008
From: report at bugs.python.org (nandhakumar)
Date: Tue, 29 Jul 2008 06:49:56 +0000
Subject: [New-bugs-announce] [issue3464] Python & NCURSES
In-Reply-To: <1217314196.04.0.889704905921.issue3464@psf.upfronthosting.co.za>
Message-ID: <1217314196.04.0.889704905921.issue3464@psf.upfronthosting.co.za>
New submission from nandhakumar <nandhakumar at inteleants.com>:
i have installed python 2.4 and ncurses 5.4 in my linux server.
Python script is working fine but when i tried using thread function in
my script(which also uses ncurses) it gives the following error:
Traceback (most recent call last):
File "xxxx.py", line 199, in ?
curses.wrapper(AnDoRun)
File "/usr/local/lib/python2.4/curses/wrapper.py", line 44, in wrapper
return func(stdscr, *args, **kwds)
File "xxxx.py", line 182, in AnDoRun
ando.start()
File "xxxx.py", line 136, in start
self.proxyManagerThread.start()
File "/usr/local/lib/python2.4/threading.py", line 416, in start
_start_new_thread(self.__bootstrap, ())
thread.error: can't start new thread
help me how can i solve this problem ASAP
----------
components: None
messages: 70377
nosy: nandha
severity: normal
status: open
title: Python & NCURSES
type: compile error
versions: Python 2.4
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3464>
_______________________________________
From report at bugs.python.org Tue Jul 29 11:24:53 2008
From: report at bugs.python.org (Piotr Wysocki)
Date: Tue, 29 Jul 2008 09:24:53 +0000
Subject: [New-bugs-announce] [issue3465] doctest unable to use '...' for
unicode literals
In-Reply-To: <1217323493.76.0.249081508484.issue3465@psf.upfronthosting.co.za>
Message-ID: <1217323493.76.0.249081508484.issue3465@psf.upfronthosting.co.za>
New submission from Piotr Wysocki <piotr.wysocki at gmail.com>:
Might be related to 2811
----------
components: Library (Lib)
files: doctest_problem.py
messages: 70382
nosy: wysek
severity: normal
status: open
title: doctest unable to use '...' for unicode literals
versions: Python 2.5
Added file: http://bugs.python.org/file11002/doctest_problem.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3465>
_______________________________________
From report at bugs.python.org Tue Jul 29 16:53:35 2008
From: report at bugs.python.org (=?utf-8?q?Marcelo_Fern=C3=A1ndez?=)
Date: Tue, 29 Jul 2008 14:53:35 +0000
Subject: [New-bugs-announce] [issue3466] urllib2 should support HTTPS
connections with client keys
In-Reply-To: <1217343215.63.0.226404809794.issue3466@psf.upfronthosting.co.za>
Message-ID: <1217343215.63.0.226404809794.issue3466@psf.upfronthosting.co.za>
New submission from Marcelo Fern?ndez <fernandezm22 at yahoo.com.ar>:
Despite httplib does have support for HTTPS with client keys[1], urllib2
should support them too, because of the added value that urllib2 has,
like cookielib automatic handling.
[1]: http://code.activestate.com/recipes/117004/
However, I made a workaround:
#-*- coding: utf-8 -*-
import httplib
import urllib2
key_file = None
cert_file = None
class HTTPSClientAuthConnection(httplib.HTTPSConnection):
def __init__(self, host):
httplib.HTTPSConnection.__init__(self, host, key_file=key_file,
cert_file=cert_file)
class HTTPSClientAuthHandler(urllib2.HTTPSHandler):
def https_open(self, req):
return self.do_open(HTTPSClientAuthConnection, req)
Regards,
Marcelo
----------
components: Library (Lib)
messages: 70397
nosy: marcelo_fernandez
severity: normal
status: open
title: urllib2 should support HTTPS connections with client keys
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3466>
_______________________________________
From report at bugs.python.org Tue Jul 29 22:42:59 2008
From: report at bugs.python.org (Eric L. Frederich)
Date: Tue, 29 Jul 2008 20:42:59 +0000
Subject: [New-bugs-announce] [issue3467] sqlite3 path is hard coded in
setup.py
In-Reply-To: <1217364179.14.0.826018983626.issue3467@psf.upfronthosting.co.za>
Message-ID: <1217364179.14.0.826018983626.issue3467@psf.upfronthosting.co.za>
New submission from Eric L. Frederich <eric.frederich at gmail.com>:
In setup.py, the paths that it searches for sqlite in is hard coded in a
list sqlite_inc_paths.
This should also search any path in either $PATH or $LD_LIBRARY_PATH.
This is necessary for non-default installations of sqlite for users
without root access, or for those with root access that have multiple
versions installed in different locations.
----------
components: Installation
messages: 70411
nosy: ericfrederich
severity: normal
status: open
title: sqlite3 path is hard coded in setup.py
type: compile error
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3467>
_______________________________________
From report at bugs.python.org Wed Jul 30 02:43:27 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 30 Jul 2008 00:43:27 +0000
Subject: [New-bugs-announce] [issue3468] Satisfy her lovemaking desire
In-Reply-To: <94BD5636.5B0F346F@aaiworldmarket.com>
Message-ID: <94BD5636.5B0F346F@aaiworldmarket.com>
New submission from Guido van Rossum <guido at python.org>:
Give your lady only the very best, find out how here http://www.pinehelp.com/
----------
messages: 70414
nosy: gvanrossum
severity: normal
status: open
title: Satisfy her lovemaking desire
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3468>
_______________________________________
From report at bugs.python.org Wed Jul 30 10:30:43 2008
From: report at bugs.python.org (=?utf-8?q?Berthold_H=C3=B6llmann?=)
Date: Wed, 30 Jul 2008 08:30:43 +0000
Subject: [New-bugs-announce] [issue3469] Umlauts make conf.latex_documents
fail
In-Reply-To: <1217406643.63.0.573094659018.issue3469@psf.upfronthosting.co.za>
Message-ID: <1217406643.63.0.573094659018.issue3469@psf.upfronthosting.co.za>
New submission from Berthold H?llmann <hoel at users.sourceforge.net>:
For a Project of mine I have set latex_documents to something like
latex_documents = [
('index', 'doc.tex', 'Documentation', 'Berthold H?llmann', 'manual'),
]
With this processing fails with:
LANG=C make latex
mkdir -p build/latex build/doctrees
sphinx-build -b latex -d build/doctrees -D latex_paper_size=a4 -N source
build/latex
Sphinx v0.4.2, building latex
trying to load pickled env... done
building [latex]: all documents
updating environment: 0 added, 1 changed, 0 removed
reading... index
pickling the env... done
checking consistency...
processing CrossSolverTests.tex... index
resolving references...
writing... Exception occurred:
File
"/usr/software/gltools/python/Python-2.5/lib/python2.5/site-packages/Sphinx-0.4.2-py2.5.egg/sphinx/latexwriter.py",
line 162, in astext
'\\renewcommand{\\indexname}{Index}\n' or '') + \
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position
206: ordinal not in range(128)
The full traceback has been saved in /tmp/sphinx-err-l_u8H4.log, if you
want to report the issue to the author.
Please also report this if it was a user error, so that a better error
message can be provided next time.
Send reports to sphinx-dev at googlegroups.com. Thanks!
make: *** [latex] Error 1
changing ? to \"o does work.
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: sphinx-err-l_u8H4.log
messages: 70419
nosy: georg.brandl, hoel
severity: normal
status: open
title: Umlauts make conf.latex_documents fail
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file11006/sphinx-err-l_u8H4.log
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3469>
_______________________________________
From report at bugs.python.org Wed Jul 30 12:43:26 2008
From: report at bugs.python.org (Fredrik Johansson)
Date: Wed, 30 Jul 2008 10:43:26 +0000
Subject: [New-bugs-announce] [issue3470] Wrong name for getrandbits in
docstring and documentation
In-Reply-To: <1217414606.28.0.183215077466.issue3470@psf.upfronthosting.co.za>
Message-ID: <1217414606.28.0.183215077466.issue3470@psf.upfronthosting.co.za>
New submission from Fredrik Johansson <fredrik.johansson at gmail.com>:
The docstring for random.Random mentions a method getrandombits().
Surely this should be getrandbits()?
This ghost method is also mentioned in the Library Reference page for
the random module.
----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 70421
nosy: fredrikj, georg.brandl
severity: normal
status: open
title: Wrong name for getrandbits in docstring and documentation
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3470>
_______________________________________
From report at bugs.python.org Wed Jul 30 18:38:34 2008
From: report at bugs.python.org (Armin Rigo)
Date: Wed, 30 Jul 2008 16:38:34 +0000
Subject: [New-bugs-announce] [issue3471] PyObject_GetAttr() to get special
methods
In-Reply-To: <1217435914.82.0.412658814842.issue3471@psf.upfronthosting.co.za>
Message-ID: <1217435914.82.0.412658814842.issue3471@psf.upfronthosting.co.za>
New submission from Armin Rigo <arigo at users.sourceforge.net>:
There is a bunch of obscure behavior caused by the use of
PyObject_GetAttr() to get special method from objects. This is wrong
because special methods should only be looked up in object types, not on
the objects themselves (i.e. with PyType_Lookup()).
Here is one example caused by the PyObject_GetAttr() found in
PyObject_IsInstance():
import abc
>>> isinstance(5, abc.ABCMeta)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: maximum recursion depth exceeded while calling a
Python object
This occurs because it ends up trying to call the unbound method
abc.ABCMeta.__instancecheck__(5). But this first requires checking if
"5" is indeed an instance of abc.ABCMeta... cycle.
Obviously this is just an example; all PyObject_GetAttr() would
potentially need to be reviewed.
----------
messages: 70431
nosy: arigo
severity: normal
status: open
title: PyObject_GetAttr() to get special methods
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3471>
_______________________________________
From report at bugs.python.org Wed Jul 30 21:42:24 2008
From: report at bugs.python.org (Jeff Rodman)
Date: Wed, 30 Jul 2008 19:42:24 +0000
Subject: [New-bugs-announce] [issue3472] Updates to "Macintosh Library
Modules" Section 1.1
In-Reply-To: <1217446944.11.0.813308740394.issue3472@psf.upfronthosting.co.za>
Message-ID: <1217446944.11.0.813308740394.issue3472@psf.upfronthosting.co.za>
New submission from Jeff Rodman <jrodman at mindspring.com>:
Change current introduction in 1.1
WAS:
Mac OS X 10.4 comes with Python 2.3 pre-installed by Apple. However, you are
encouraged to install the most recent version of Python from the Python website
(http://www.python.org). A ``universal binary'' build of Python 2.5, which runs natively
on the Mac's new Intel and legacy PPC CPU's, is available there.
IS:
Mac OS X 10.5 comes with Python 2.5.1 pre-installed by Apple. If you wish, you are
invited to install the most recent version (currently 2.5.2) of Python from the Python website
(http://www.python.org). A current "universal binary'' build of Python, which runs natively
on the Mac's new Intel and legacy PPC CPU's, is available there.
And then, to line:
The Apple-provided build of Python is installed in
/System/Library/Frameworks/Python.framework and /usr/bin/python, respectively. You
should never modify or delete these, as they are Apple-controlled and are used by Apple-
or third-party software.
ADD:
Remember that if you choose to install a newer Python version like this, you will have two
different but functional Python installations on your computer, so it will be important that
your paths and usages are consistent with what you want to do.
----------
assignee: georg.brandl
components: Documentation
messages: 70437
nosy: georg.brandl, jrodman
severity: normal
status: open
title: Updates to "Macintosh Library Modules" Section 1.1
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3472>
_______________________________________
From report at bugs.python.org Thu Jul 31 03:16:31 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 31 Jul 2008 01:16:31 +0000
Subject: [New-bugs-announce] [issue3473] In function call,
keyword arguments could follow *args
In-Reply-To: <1217466991.08.0.845897736513.issue3473@psf.upfronthosting.co.za>
Message-ID: <1217466991.08.0.845897736513.issue3473@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:
functions with keyword-only arguments have this form:
def f(x, *args, y):
pass
parameters can appear after the *arg, they are required to be passed by
keyword.
It would be more consistent to allow this function call:
f(X, *ARGS, y=Y)
This is invalid syntax, *ARGS is required to be at the end of the
arguments, together with an eventual **KWARGS. This restriction should
be lifted.
See the use case in
http://mail.python.org/pipermail/python-3000/2008-July/014437.html
----------
assignee: amaury.forgeotdarc
messages: 70449
nosy: amaury.forgeotdarc
severity: normal
status: open
title: In function call, keyword arguments could follow *args
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3473>
_______________________________________
From report at bugs.python.org Thu Jul 31 05:40:55 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 31 Jul 2008 03:40:55 +0000
Subject: [New-bugs-announce] [issue3474] Using functools.reduce() does not
stop DeprecationWarning when using -3
In-Reply-To: <1217475655.54.0.410069385822.issue3474@psf.upfronthosting.co.za>
Message-ID: <1217475655.54.0.410069385822.issue3474@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
It turns out that functools.reduce() is simply __builtins__.reduce().
That does not stop the DeprecationWarning from using reduce() from being
raised even though the message says to use functools.reduce()!
Easiest solution is to create a wrapper for __builtin__.reduce() that
silences the warning when called.
----------
assignee: brett.cannon
components: Library (Lib)
messages: 70484
nosy: brett.cannon
priority: critical
severity: normal
status: open
title: Using functools.reduce() does not stop DeprecationWarning when using -3
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3474>
_______________________________________
From report at bugs.python.org Thu Jul 31 09:13:10 2008
From: report at bugs.python.org (Matteo Bertini)
Date: Thu, 31 Jul 2008 07:13:10 +0000
Subject: [New-bugs-announce] [issue3475] _elementtree.c import can fail
silently
In-Reply-To: <1217488390.82.0.966024621847.issue3475@psf.upfronthosting.co.za>
Message-ID: <1217488390.82.0.966024621847.issue3475@psf.upfronthosting.co.za>
New submission from Matteo Bertini <matteob at naufraghi.net>:
Playing with PyInstaller I have found that the final part of
_elementtree.c:
Index: Modules/_elementtree.c
===================================================================
--- Modules/_elementtree.c (revisione 59540)
+++ Modules/_elementtree.c (copia locale)
@@ -2780,7 +2780,10 @@
);
- PyRun_String(bootstrap, Py_file_input, g, NULL);
+ if (PyRun_String(bootstrap, Py_file_input, g, NULL) == NULL)
+ return;
elementpath_obj = PyDict_GetItemString(g, "ElementPath");
execute a bit of python code without checking the return value.
That can lead to weird things playing with import hooks,
for example an assert like this can fail:
Index: Lib/test/test_elemettree.py
===================================================================
--- Lib/test/test_elemettree.py (revisione 0)
+++ Lib/test/test_elemettree.py (revisione 0)
@@ -0,0 +1,21 @@
+#! /usr/bin/env python
+
+def importHook(*args, **kwargs):
+ if 'xml.etree' in args:
+ raise ImportError
+ else:
+ return __real__import__(*args, **kwargs)
+
+import os
+import __builtin__
+__real__import__ = __builtin__.__import__
+__builtin__.__import__ = importHook
+
+try:
+ import xml.etree.cElementTree as cET
+except ImportError:
+ pass
+else:
+ out = os.popen("python -c 'import xml.etree.cElementTree as cET;
print dir(cET)'").read().strip()
+ assert str(dir(cET)) == out, (str(dir(cET)), out)
+
----------
components: XML
messages: 70488
nosy: naufraghi
severity: normal
status: open
title: _elementtree.c import can fail silently
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3475>
_______________________________________
From report at bugs.python.org Thu Jul 31 11:03:12 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 31 Jul 2008 09:03:12 +0000
Subject: [New-bugs-announce] [issue3476] BufferedWriter not thread-safe
In-Reply-To: <1217494992.05.0.604288591509.issue3476@psf.upfronthosting.co.za>
Message-ID: <1217494992.05.0.604288591509.issue3476@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
As discovered in #3139, io.BufferedWriter mutates the size of its
internal bytearray object. Consequently, invocations of write() from
multiple threads can produce exceptions when one thread gets a buffer to
the bytearray while the other thread tries to resize it. This especially
affects calling print() from multiple threads.
A solution is to use a fixed-size (preallocated) bytearray object.
Another solution is to get rid of the bytearray approach and replace it
with a growing list of immutable bytes objects.
Here is the test script provided by Amaury:
import sys, io, threading
stdout2 = io.open(sys.stdout.fileno(), mode="w")
def f(i):
for i in range(10):
stdout2.write(unicode((x, i)) + '\n')
for x in range(10):
t = threading.Thread(target=f, args=(x,))
t.start()
(with py3k, replace "stdout2.write" with a simple "print")
----------
components: Library (Lib)
messages: 70494
nosy: amaury.forgeotdarc, pitrou
priority: high
severity: normal
status: open
title: BufferedWriter not thread-safe
type: behavior
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3476>
_______________________________________
From report at bugs.python.org Thu Jul 31 13:37:55 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 31 Jul 2008 11:37:55 +0000
Subject: [New-bugs-announce] [issue3477] grammar productionlist are not
properly indented
In-Reply-To: <1217504275.9.0.818427276788.issue3477@psf.upfronthosting.co.za>
Message-ID: <1217504275.9.0.818427276788.issue3477@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:
See http://docs.python.org/dev/reference/expressions.html#id9
the production rule for "argument_list" is not properly indented.
It seems that the first line is indented up to the widest name of the
list, but subsequent lines only add 6 to the length of the defined name.
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 70498
nosy: amaury.forgeotdarc, georg.brandl
severity: normal
status: open
title: grammar productionlist are not properly indented
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3477>
_______________________________________
From report at bugs.python.org Thu Jul 31 16:26:31 2008
From: report at bugs.python.org (Matt Giuca)
Date: Thu, 31 Jul 2008 14:26:31 +0000
Subject: [New-bugs-announce] [issue3478] Documentation for struct module is
out of date in 3.0
In-Reply-To: <1217514391.83.0.200271369945.issue3478@psf.upfronthosting.co.za>
Message-ID: <1217514391.83.0.200271369945.issue3478@psf.upfronthosting.co.za>
New submission from Matt Giuca <matt.giuca at gmail.com>:
The documentation for the "struct" module still uses the term "string"
even though the struct module itself deals entirely in bytes objects in
Python 3.0.
I propose updating the documentation to reflect the 3.0 terminology.
I've attached a patch for the Docs/library/struct.rst file. It mostly
renames "string" to "bytes". It also notes that pack for 'c', 's' and
'p' accepts either string or bytes, but unpack spits out a bytes.
One important point: If you pass a str to 'c', 's' or 'p', it will get
encoded with UTF-8 before being packed. I've described this behaviour in
the documentation. I'm not sure if this should be described as the
"official" behaviour, or just informatively.
I've traced this behaviour to Modules/_struct.c lines 607, 1650 and 1676
(for 'c', 's' and 'p' respectively), which calls
_PyUnicode_AsDefaultEncodedString. This is found in
Object/unicodeobject.c:1410, which directly calls PyUnicode_EncodeUTF8.
Hence the UTF-8 encoding is not system or locale specific - it will
always happen. However, perhaps we should loosen the documentation to
say "which are encoded using a default encoding scheme".
It would be good if the authors of the struct module read over these
changes first, to make sure I am describing it correctly.
I have also updated Modules/_struct.c's doc strings and exception
messages to reflect this new terminology. (I've changed nothing besides
the contents of these strings - test case passes, just to be safe).
Patch is for /python/branches/py3k/, revision 65324.
Commit Log:
Docs/library/struct.rst: Updated documentation to Python 3.0 terminology
(bytes instead of strings). Added note that packing 'c', 's' or 'p'
accepts either str or bytes.
Modules/_struct.c: Updated doc strings and exception messages to the same.
----------
assignee: georg.brandl
components: Documentation
files: struct-doc.patch
keywords: patch
messages: 70506
nosy: georg.brandl, mgiuca
severity: normal
status: open
title: Documentation for struct module is out of date in 3.0
versions: Python 3.0
Added file: http://bugs.python.org/file11013/struct-doc.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3478>
_______________________________________
From report at bugs.python.org Thu Jul 31 16:53:45 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Thu, 31 Jul 2008 14:53:45 +0000
Subject: [New-bugs-announce] [issue3479] unichr integer overflow
In-Reply-To: <1217516025.33.0.943431479482.issue3479@psf.upfronthosting.co.za>
Message-ID: <1217516025.33.0.943431479482.issue3479@psf.upfronthosting.co.za>
New submission from Ralf Schmitt <schmir at gmail.com>:
unichr(2**32) results in a unicode string containing a 0 byte:
{{{
~/mwlib.hg/tests/ python
Python 2.5.2 (r252:60911, Apr 21 2008, 11:17:30)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> unichr(2**32)
u'\x00'
>>> unichr(2**32+1)
u'\x01'
>>> unichr(2**32+2)
u'\x02'
}}}
2.6 shows the same behaviour.
----------
components: Unicode
messages: 70513
nosy: schmir
severity: normal
status: open
title: unichr integer overflow
type: behavior
versions: Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3479>
_______________________________________
From report at bugs.python.org Thu Jul 31 22:00:05 2008
From: report at bugs.python.org (Nick Edds)
Date: Thu, 31 Jul 2008 20:00:05 +0000
Subject: [New-bugs-announce] [issue3480] Fix_imports pattern optimization
In-Reply-To: <1217534405.3.0.224427460631.issue3480@psf.upfronthosting.co.za>
Message-ID: <1217534405.3.0.224427460631.issue3480@psf.upfronthosting.co.za>
New submission from Nick Edds <nedds at uchicago.edu>:
Here is a substantial improvement to the pattern for fix_imports. It
significantly reduces the size of the previous pattern and represents it
in a more reasonable way. It still passes all of the tests and it also
makes 2to3 roughly two to three times as fast based on the results of
some basic testing.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: fix_imports_pattern.diff
keywords: patch
messages: 70528
nosy: collinwinter, nedds
severity: normal
status: open
title: Fix_imports pattern optimization
type: performance
Added file: http://bugs.python.org/file11019/fix_imports_pattern.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3480>
_______________________________________