From report at bugs.python.org Sat Mar 1 01:35:42 2008
From: report at bugs.python.org (Joseph Armbruster)
Date: Sat, 01 Mar 2008 00:35:42 -0000
Subject: [New-bugs-announce] [issue2213] build_tkinter.py does not handle
paths with spaces
In-Reply-To: <1204331742.92.0.0412981555519.issue2213@psf.upfronthosting.co.za>
Message-ID: <1204331742.92.0.0412981555519.issue2213@psf.upfronthosting.co.za>
New submission from Joseph Armbruster:
http://svn.python.org/projects/python/trunk/PCbuild/build_tkinter.py
rev 61127
Is it still in python-devs interest to support building the tree in a
path that contains spaces? I (pretty much always) do, so if a patch for
this is desired, I can put one together.
----------
components: Build, Windows
messages: 63152
nosy: JosephArmbruster, tiran
severity: normal
status: open
title: build_tkinter.py does not handle paths with spaces
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2213>
__________________________________
From report at bugs.python.org Sat Mar 1 22:55:32 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 01 Mar 2008 21:55:32 -0000
Subject: [New-bugs-announce] [issue2214] make htmlhelp raises
non-reproducable exception
In-Reply-To: <1204408532.2.0.853592374746.issue2214@psf.upfronthosting.co.za>
Message-ID: <1204408532.2.0.853592374746.issue2214@psf.upfronthosting.co.za>
New submission from Martin v. L?wis:
Sometimes, when I run "make htmlhelp", I get a traceback of
writing additional files...
Traceback (most recent call last):
File "tools/sphinx-build.py", line 24, in <module>
sys.exit(main(sys.argv))
File "/cygdrive/c/loewis/3k/python/Doc/tools/sphinx/__init__.py", line
141, in
main
builderobj.build_update()
File "/cygdrive/c/loewis/3k/python/Doc/tools/sphinx/builder.py", line
202, in
build_update
summary='%d source files that are out of date' % len(to_build))
File "/cygdrive/c/loewis/3k/python/Doc/tools/sphinx/builder.py", line
235, in
build
self.finish()
File "/cygdrive/c/loewis/3k/python/Doc/tools/sphinx/builder.py", line
449, in
finish
download_base_url = self.config['download_base_url'],
KeyError: 'download_base_url'
make: *** [build] Fehler 1
When redoing "make htmlhelp", it immediately completes without error.
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 63171
nosy: georg.brandl, loewis
severity: normal
status: open
title: make htmlhelp raises non-reproducable exception
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2214>
__________________________________
From report at bugs.python.org Sun Mar 2 02:42:19 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Sun, 02 Mar 2008 01:42:19 -0000
Subject: [New-bugs-announce] [issue2215] test_sqlite fails in 2.6a1 on MacOS
X
In-Reply-To: <1204422139.64.0.558749633793.issue2215@psf.upfronthosting.co.za>
Message-ID: <1204422139.64.0.558749633793.issue2215@psf.upfronthosting.co.za>
New submission from Jean Brouwers:
One test fails on MacOS X 10.4.11 (Intel) after building 2.6a1 from
source.
test_sqlite
test test_sqlite failed -- Traceback (most recent call last):
File "/Users/jean/Tools/Python-2.6a1/Lib/sqlite3/test/regression.py",
line 118, in CheckWorkaroundForBuggySqliteTransfer
Bindings
self.con.execute("create table if not exists foo(bar)")
OperationalError: near "not": syntax error
29 tests are skipped (as expected) and 312 pass.
----------
components: Tests
messages: 63175
nosy: MrJean1
severity: normal
status: open
title: test_sqlite fails in 2.6a1 on MacOS X
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2215>
__________________________________
From report at bugs.python.org Sun Mar 2 14:55:49 2008
From: report at bugs.python.org (Andrea Griffini)
Date: Sun, 02 Mar 2008 13:55:49 -0000
Subject: [New-bugs-announce] [issue2216] Problems using logging module with
idle
In-Reply-To: <1204466149.08.0.371697565628.issue2216@psf.upfronthosting.co.za>
Message-ID: <1204466149.08.0.371697565628.issue2216@psf.upfronthosting.co.za>
New submission from Andrea Griffini:
I'm not a user of idle, but when asked about a strange behaviour of the
logging module I digged a bit and found what I think is indeed a problem
in the module itself.
The problem is visible if the module is used from idle (or any other IDE
that keeps the same python instance running for multiple execution of
user code); if you call basicConfig(filename="foo.txt"), do some logging
and call shutdown() the handler is closed (correctly closing the file)
but remains attached to the root logger, and gets called again at next
run (giving an error for invalid I/O on a closed file).
This can also be reproduced in a single run with
import logging
logging.basicConfig(filename="logtest.txt")
logging.warning("This is a test")
logging.shutdown()
logging.basicConfig(filename="logtest2.txt")
logging.warning("This is a test (2)")
logging.shutdown()
I think that it is not correct to close the handler but leave it in
place, so I tried patching the module so that every handler keeps a list
of all loggers it is attached to, and removes itself from loggers at
close() time. This way the above code runs correctly (creating two
files) and the logging module still passes the test suite.
I must however admit that logging logic is a bit beyond my grasp
(including a close() call commented out, some uses of lock/release I
don't understand) so may be the attached patch is not correct even if
passes the test.
----------
components: Library (Lib)
files: logging.patch
keywords: patch
messages: 63179
nosy: ag6502
severity: normal
status: open
title: Problems using logging module with idle
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9583/logging.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2216>
__________________________________
From report at bugs.python.org Sun Mar 2 18:43:37 2008
From: report at bugs.python.org (Christoph Zwerschke)
Date: Sun, 02 Mar 2008 17:43:37 -0000
Subject: [New-bugs-announce] [issue2217] Problem with if clause in generator
expression on class level
In-Reply-To: <1204479817.59.0.844396901804.issue2217@psf.upfronthosting.co.za>
Message-ID: <1204479817.59.0.844396901804.issue2217@psf.upfronthosting.co.za>
New submission from Christoph Zwerschke:
The following code throws a NameError which seems to be a bug existing
since Python 2.4 up to the current 2.5.2.
class A:
a = 'test'
[c for c in a]
(c for c in a)
tuple(c for c in a)
[c for c in a if c in a]
(c for c in a if c in a)
tuple(c for c in a if c in a) # --> NameError
----------
components: Interpreter Core, Library (Lib), Macintosh, Regular Expressions, Tests, Tkinter, Unicode, Windows, XML
messages: 63182
nosy: cito
severity: normal
status: open
title: Problem with if clause in generator expression on class level
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2217>
__________________________________
From report at bugs.python.org Mon Mar 3 00:45:11 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Sun, 02 Mar 2008 23:45:11 -0000
Subject: [New-bugs-announce] [issue2218] Enhanced hotshot profiler with
high-resolution timer
In-Reply-To: <1204501511.28.0.993763550383.issue2218@psf.upfronthosting.co.za>
Message-ID: <1204501511.28.0.993763550383.issue2218@psf.upfronthosting.co.za>
New submission from Jean Brouwers:
The _hotshot module uses the gettimeofday function to profile the run
time.
I enhanced the hotshot module in Python 2.5.2 to use a high resolution
timer where available (RDTSC on x86/_64, MFTB/U on PowerPC and gethrtime
on Solaris).
The improved hotshot module has been tested on 32-bit MacOS X 10.4.11
Tiger (Intel) and 10.3.9 Panther (PPC), on 64-bit RHEL 3u7 (Opteron) and
on 64-bit Solaris 10.
The 3 modified files are Modules/_hotshot.c, Lib/hotshot/log.py and
Lib/hotshot/stats.py are attached.
----------
components: Extension Modules
files: hires_hotshot.tgz
messages: 63194
nosy: MrJean1
severity: normal
status: open
title: Enhanced hotshot profiler with high-resolution timer
type: feature request
versions: Python 2.5
Added file: http://bugs.python.org/file9588/hires_hotshot.tgz
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2218>
__________________________________
From report at bugs.python.org Mon Mar 3 09:12:37 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Mon, 03 Mar 2008 08:12:37 -0000
Subject: [New-bugs-announce] [issue2219] Py30a3: Possibly confusing message
when module detection fails
In-Reply-To: <1204531957.41.0.514268836397.issue2219@psf.upfronthosting.co.za>
Message-ID: <1204531957.41.0.514268836397.issue2219@psf.upfronthosting.co.za>
New submission from Mark Summerfield:
On Fedora 8 I get this message:
Failed to find the necessary bits to build these modules:
_bsddb
To find the necessary bits, look in setup.py in detect_modules() for the
module's name.
On Kubuntu 6.06 LTS I get the same message, but about different modules:
_hashlib _ssl bz2
In previous versions when headers or libraries couldn't be found I
thought the correct file to change was Modules/Setup or
Modules/Setup.local. If this is still the case then the above error
message should perhaps be changed?
BTW For Fedora 8, bsddb won't work since according to Modules/Setup the
most recent version supported is 4.0 while Fedora 8 has 4.4.
----------
components: Build
messages: 63202
nosy: mark
severity: normal
status: open
title: Py30a3: Possibly confusing message when module detection fails
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2219>
__________________________________
From report at bugs.python.org Mon Mar 3 11:49:39 2008
From: report at bugs.python.org (Lorenz Quack)
Date: Mon, 03 Mar 2008 10:49:39 -0000
Subject: [New-bugs-announce] [issue2220] bug in rlcompleter
In-Reply-To: <1204541379.7.0.080847401337.issue2220@psf.upfronthosting.co.za>
Message-ID: <1204541379.7.0.080847401337.issue2220@psf.upfronthosting.co.za>
New submission from Lorenz Quack:
The following code would raise a TypeError:
>>> rlcompleter.Completer().complete("print self.foo", 0)
with this fix it will just return None
----------
components: Library (Lib)
files: rlcompleter.patch
keywords: patch
messages: 63208
nosy: donlorenzo
severity: normal
status: open
title: bug in rlcompleter
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file9591/rlcompleter.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2220>
__________________________________
From report at bugs.python.org Mon Mar 3 12:34:29 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Mon, 03 Mar 2008 11:34:29 -0000
Subject: [New-bugs-announce] [issue2221] Py30a3: calltip produces error
output to stderr
In-Reply-To: <1204544069.74.0.858936575145.issue2221@psf.upfronthosting.co.za>
Message-ID: <1204544069.74.0.858936575145.issue2221@psf.upfronthosting.co.za>
New submission from Mark Summerfield:
In IDLE for Py30a3 if you enter:
>>> class A(
as soon as you type the ( you get the following output to stderr (on
Fedora 8 with Tcl/Tk 8.4):
: *** Internal Error: rpc.py:SocketIO.localcall()
Object: exec
Method: <bound method Executive.get_the_calltip of
<idlelib.run.Executive object at 0xb70f2b4c>>
Args: ('A',)
Traceback (most recent call last):
File "/home/mark/opt/python30a3/lib/python3.0/idlelib/rpc.py", line
188, in localcall
ret = method(*args, **kwargs)
File "/home/mark/opt/python30a3/lib/python3.0/idlelib/run.py", line
316, in get_the_calltip
return self.calltip.fetch_tip(name)
File "/home/mark/opt/python30a3/lib/python3.0/idlelib/CallTips.py",
line 103, in fetch_tip
entity = self.get_entity(name)
File "/home/mark/opt/python30a3/lib/python3.0/idlelib/CallTips.py",
line 112, in get_entity
return eval(name, namespace)
SystemError: error return without exception set
It does not appear to affect IDLE's functionality.
----------
components: IDLE
messages: 63209
nosy: mark
severity: minor
status: open
title: Py30a3: calltip produces error output to stderr
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2221>
__________________________________
From report at bugs.python.org Mon Mar 3 14:05:34 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 03 Mar 2008 13:05:34 -0000
Subject: [New-bugs-announce] [issue2222] Memory leak in os.rename?
In-Reply-To: <1204549533.94.0.102574866059.issue2222@psf.upfronthosting.co.za>
Message-ID: <1204549533.94.0.102574866059.issue2222@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto:
Hello. Probably I found memory leak.
When first convert_to_unicode succeeds and second one
fails, first unicode object is not freed.
# ex: os.rename("a", 3)
Thank you.
----------
components: Extension Modules
files: fix_leak.patch
keywords: patch
messages: 63211
nosy: ocean-city
severity: normal
status: open
title: Memory leak in os.rename?
type: resource usage
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9592/fix_leak.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2222>
__________________________________
From report at bugs.python.org Mon Mar 3 17:27:09 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 03 Mar 2008 16:27:09 -0000
Subject: [New-bugs-announce] [issue2223] regrtest.py -R not working
In-Reply-To: <1204561629.27.0.900195264283.issue2223@psf.upfronthosting.co.za>
Message-ID: <1204561629.27.0.900195264283.issue2223@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto:
Sorry, I don't have patch, but regrtest.py -R not working now.
E:\python-dev\trunk\Lib\test>py25 regrtest.py -R ::
test_grammar
test_grammar skipped -- No module named _abcoll
E:\python-dev\trunk\Lib\test>py regrtest.py -R ::
test_grammar
test_grammar skipped -- cannot import name _Abstract
E:\python-dev\trunk\Lib\test>py3k regrtest.py -R ::
File "regrtest.py", line 174
print __doc__
^
SyntaxError: invalid syntax
----------
components: Tests
messages: 63215
nosy: ocean-city
severity: normal
status: open
title: regrtest.py -R not working
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2223>
__________________________________
From report at bugs.python.org Mon Mar 3 18:31:27 2008
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 03 Mar 2008 17:31:27 -0000
Subject: [New-bugs-announce] [issue2224] branches/trunk-math patch
In-Reply-To: <1204565487.81.0.141440413352.issue2224@psf.upfronthosting.co.za>
Message-ID: <1204565487.81.0.141440413352.issue2224@psf.upfronthosting.co.za>
New submission from Christian Heimes:
"svnmerge.py merge" integration patch of Mark and my trunk-math branch.
I created the patch to make the review process easier.
Name: svnmerge-integrated
- /python/branches/trunk-math:1-60195
+ /python/branches/trunk-math:1-61203
----------
components: Interpreter Core
files: trunk-math.patch
keywords: patch
messages: 63218
nosy: marketdickinson, tiran
priority: high
severity: normal
status: open
title: branches/trunk-math patch
type: feature request
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9594/trunk-math.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2224>
__________________________________
From report at bugs.python.org Mon Mar 3 20:15:09 2008
From: report at bugs.python.org (Chris AtLee)
Date: Mon, 03 Mar 2008 19:15:09 -0000
Subject: [New-bugs-announce] [issue2225] py_compile.main() does not return
error code
In-Reply-To: <1204571709.66.0.797996976518.issue2225@psf.upfronthosting.co.za>
Message-ID: <1204571709.66.0.797996976518.issue2225@psf.upfronthosting.co.za>
New submission from Chris AtLee:
When using the py_compile module from the command line, and a
SyntaxError is encountered, python still exits with a 0 return code.
This usually indicates that the process completely successfully.
Could py_compile.main() be modified to return a non-zero return code if
an exception was raised?
----------
components: Library (Lib)
messages: 63226
nosy: catlee
severity: normal
status: open
title: py_compile.main() does not return error code
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2225>
__________________________________
From report at bugs.python.org Mon Mar 3 22:22:10 2008
From: report at bugs.python.org (Armin Ronacher)
Date: Mon, 03 Mar 2008 21:22:10 -0000
Subject: [New-bugs-announce] [issue2226] Small _abcoll Bugs / Oddities
Message-ID: <1204579330.81.0.211644715466.issue2226@psf.upfronthosting.co.za>
Changes by Armin Ronacher:
----------
components: Library (Lib)
nosy: aronacher
severity: normal
status: open
title: Small _abcoll Bugs / Oddities
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2226>
__________________________________
From report at bugs.python.org Mon Mar 3 22:41:26 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 03 Mar 2008 21:41:26 -0000
Subject: [New-bugs-announce] [issue2227] time.strptime too strict? should it
assume current year?
In-Reply-To: <1204580486.17.0.196786227347.issue2227@psf.upfronthosting.co.za>
Message-ID: <1204580486.17.0.196786227347.issue2227@psf.upfronthosting.co.za>
New submission from Gregory P. Smith:
Some common python utilities had problems on Feb 29 this year when
parsing dates using format strings that did not include a year in them.
>>> time.strptime('Feb 29', '%b %d')
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/python2.4/_strptime.py", line 425, in strptime
julian = datetime_date(year, month, day).toordinal() - \
ValueError: day is out of range for month
This is apparently because python assumes the year is 1900 unless it
explicitly parses another year out of the string.
Applications can work around this by always adding a year and a %Y to
the string they are parsing.
But not all date manipulating applications care about years. In this
case the application was fail2ban, bug report and patches to it here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468382
Should the year default to 1900 (the equivalent of what the much more
forgiving C API does by leaving struct tm tm_year = 0) or should this
error be raised? If the answer is yes, works as is this is easy and
just turns into us adding a note in the documentation to mention the
behavior.
I do believe this was a valid bug in fail2ban as assuming the current
year for date parsing is a bad idea and will do the wrong thing when
parsing across a year change.
Python's strptime is much more strict than C strptime (glibc's C
strptime is happy to return tm_mon 2 tm_mday 31. Its range checking is
minimal.
here's a C test case to play with its behavior:
#include <assert.h>
#include <stdio.h>
#include <time.h>
int main(int argc, char *argv[]) {
unsigned long ret, parsed;
assert(argc == 2);
struct tm tm = { 0 };
ret = strptime(argv[1], "%b %d", &tm);
parsed = ret - (unsigned long)(argv[1]);
printf("ret 0x%x parsed %d tm_mon %d tm_mday %d tm_year %d\n",
ret, parsed,
tm.tm_mon, tm.tm_mday, tm.tm_year);
}
% ./foo 'Feb 28'
ret 0xffffda8a parsed 6 tm_mon 1 tm_mday 28 tm_year 0
% ./foo 'Feb 29'
ret 0xffffda8a parsed 6 tm_mon 1 tm_mday 29 tm_year 0
% ./foo 'Feb 31'
ret 0xffffda8a parsed 6 tm_mon 1 tm_mday 31 tm_year 0
% ./foo 'Feb 32'
ret 0x0 parsed 9596 tm_mon 1 tm_mday 0 tm_year 0
----------
components: Library (Lib)
keywords: easy
messages: 63236
nosy: gregory.p.smith
priority: low
severity: minor
status: open
title: time.strptime too strict? should it assume current year?
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2227>
__________________________________
From report at bugs.python.org Mon Mar 3 22:42:06 2008
From: report at bugs.python.org (Aaron Kaplan)
Date: Mon, 03 Mar 2008 21:42:06 -0000
Subject: [New-bugs-announce] [issue2228] Imaplib speedup patch
In-Reply-To: <1204580526.67.0.16390655339.issue2228@psf.upfronthosting.co.za>
Message-ID: <1204580526.67.0.16390655339.issue2228@psf.upfronthosting.co.za>
New submission from Aaron Kaplan:
In some versions of John Goergen's program offlineimap, he includes a
copy of imaplib.py with the attached changes. It results in a speedup
of more than 50% compared to using the stock imaplib.py.
----------
files: imaplib-patch
messages: 63237
nosy: aaronkaplan
severity: normal
status: open
title: Imaplib speedup patch
type: resource usage
Added file: http://bugs.python.org/file9597/imaplib-patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2228>
__________________________________
From report at bugs.python.org Tue Mar 4 01:33:00 2008
From: report at bugs.python.org (Miki Tebeka)
Date: Tue, 04 Mar 2008 00:33:00 -0000
Subject: [New-bugs-announce] [issue2229] Search in 2.6 docs does not work
In-Reply-To: <1204590780.07.0.631438682332.issue2229@psf.upfronthosting.co.za>
Message-ID: <1204590780.07.0.631438682332.issue2229@psf.upfronthosting.co.za>
New submission from Miki Tebeka:
Try searching for anything on http://docs.python.org/dev/search.html
No result is shown (at least on FireFox and IE7).
----------
components: Documentation
messages: 63242
nosy: tebeka
severity: normal
status: open
title: Search in 2.6 docs does not work
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2229>
__________________________________
From report at bugs.python.org Tue Mar 4 03:22:25 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 04 Mar 2008 02:22:25 -0000
Subject: [New-bugs-announce] [issue2230] Document PyArg_Parse* behavior on
failed conversion
In-Reply-To: <1204597345.35.0.8894806646.issue2230@psf.upfronthosting.co.za>
Message-ID: <1204597345.35.0.8894806646.issue2230@psf.upfronthosting.co.za>
New submission from Alexander Belopolsky:
Much of existing code relies on PyArg_Parse* leaving C variables
unmodified when conversion failed. Attached patch documents that
behavior.
----------
files: doc-arg.diff
keywords: patch
messages: 63243
nosy: belopolsky
severity: normal
status: open
title: Document PyArg_Parse* behavior on failed conversion
Added file: http://bugs.python.org/file9598/doc-arg.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2230>
__________________________________
From report at bugs.python.org Tue Mar 4 14:10:44 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 04 Mar 2008 13:10:44 -0000
Subject: [New-bugs-announce] [issue2231] Memory leak in itertools.chain()
In-Reply-To: <1204636244.39.0.268718353736.issue2231@psf.upfronthosting.co.za>
Message-ID: <1204636244.39.0.268718353736.issue2231@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto:
Fixed memory leak in itertools.chain().
This fixes following refleak errors shown in issue2223.
test_deque test_heapq test_itertools test_list test_set test_userlist
----------
components: Extension Modules
files: fix_leak.patch
keywords: patch
messages: 63252
nosy: ocean-city
severity: normal
status: open
title: Memory leak in itertools.chain()
type: resource usage
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9602/fix_leak.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2231>
__________________________________
From report at bugs.python.org Tue Mar 4 18:01:21 2008
From: report at bugs.python.org (Trent Nelson)
Date: Tue, 04 Mar 2008 17:01:21 -0000
Subject: [New-bugs-announce] [issue2232] Current os.tmpfile() implementation
requires admin privs on Vista/2k8.
In-Reply-To: <1204650081.4.0.741104668485.issue2232@psf.upfronthosting.co.za>
Message-ID: <1204650081.4.0.741104668485.issue2232@psf.upfronthosting.co.za>
New submission from Trent Nelson:
posix_tmpfile() needs to be reworked such that tmpfile() isn't used if
MS_WINDOWS is defined, as it requires administrative privileges to run
(it creates the file in the root directory) on Vista/2k8 (although
there are reports of this not working on XP w/ 2.5:
http://www.thescripts.com/forum/thread600423.html).
The recommended approach in MSDN is to use, quote, "tmpname or tempnam
in conjunction with fopen": http://msdn2.microsoft.com/en-
us/library/x8x7sakw(VS.80).aspx
Assuming no one beats me to it, I'll look at creating a patch in the
next day or two when I get some spare time.
----------
components: Windows
messages: 63254
nosy: Trent.Nelson
severity: normal
status: open
title: Current os.tmpfile() implementation requires admin privs on Vista/2k8.
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2232>
__________________________________
From report at bugs.python.org Tue Mar 4 18:47:50 2008
From: report at bugs.python.org (Jason Tishler)
Date: Tue, 04 Mar 2008 17:47:50 -0000
Subject: [New-bugs-announce] [issue2233] Makefile.pre.in contains extra
slash before $(DESTDIR) which can cause Cygwin build to fail
In-Reply-To: <1204652870.95.0.330326965123.issue2233@psf.upfronthosting.co.za>
Message-ID: <1204652870.95.0.330326965123.issue2233@psf.upfronthosting.co.za>
New submission from Jason Tishler:
Makefile.pre.in contains extra slash before $(DESTDIR) in two locations
as in the following:
sharedinstall:
$(RUNSHARED) ./$(BUILDPYTHON) -E $(srcdir)/setup.py install \
--prefix=$(prefix) \
--install-scripts=$(BINDIR) \
--install-platlib=$(DESTSHARED) \
--root=/$(DESTDIR)
This causes Cygwin builds to fail if DESTDIR is set as follows:
creating //tmp
error: could not create '//tmp': No such host or network path
The following Open Group Specification:
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html
indicates the following:
4.11 Pathanme Resolution
[snip]
A pathname that begins with two successive slashes may be interpreted
in an implementation-defined manner,...
IMO, these extra slashes should be removed as indicated in the
attached patch. OK to commit? If so, to which branches?
----------
assignee: jlt63
components: Build
files: python.patch
keywords: patch, patch
messages: 63256
nosy: jlt63
priority: low
severity: normal
status: open
title: Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail
type: compile error
versions: Python 2.5
Added file: http://bugs.python.org/file9603/python.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2233>
__________________________________
From report at bugs.python.org Tue Mar 4 19:43:39 2008
From: report at bugs.python.org (Lenard Lindstrom)
Date: Tue, 04 Mar 2008 18:43:39 -0000
Subject: [New-bugs-announce] [issue2234] cygwinccompiler.py fails for latest
MinGW releases.
In-Reply-To: <1204656219.89.0.991339984516.issue2234@psf.upfronthosting.co.za>
Message-ID: <1204656219.89.0.991339984516.issue2234@psf.upfronthosting.co.za>
New submission from Lenard Lindstrom:
The cygwinccompiler.py module for distutils on Pythons 2.5 and 2.4 fails
with an exception for the latest MinGW tools.
running build_ext
Traceback (most recent call last):
File "setup.py", line 224, in <module>
setup(**PACKAGEDATA)
File "C:\PRG\PYTHON25\lib\distutils\core.py", line 151, in setup
dist.run_commands()
File "C:\PRG\PYTHON25\lib\distutils\dist.py", line 974, in run_commands
self.run_command(cmd)
File "C:\PRG\PYTHON25\lib\distutils\dist.py", line 994, in run_command
cmd_obj.run()
File "C:\PRG\PYTHON25\lib\distutils\command\build.py", line 112, in run
self.run_command(cmd_name)
File "C:\PRG\PYTHON25\lib\distutils\cmd.py", line 333, in run_command
self.distribution.run_command(command)
File "C:\PRG\PYTHON25\lib\distutils\dist.py", line 994, in run_command
cmd_obj.run()
File "setup.py", line 186, in run
build_ext.run(self)
File "C:\PRG\PYTHON25\lib\distutils\command\build_ext.py", line 264,
in run
force=self.force)
File "C:\prg\pygame\trunk_\mingw32distutils.py", line 31, in new_compiler
return Mingw32DefaultCCompiler (None, dry_run, force)
File "C:\PRG\PYTHON25\lib\distutils\cygwinccompiler.py", line 292, in
__init__
CygwinCCompiler.__init__ (self, verbose, dry_run, force)
File "C:\PRG\PYTHON25\lib\distutils\cygwinccompiler.py", line 84, in
__init__
get_versions()
File "C:\PRG\PYTHON25\lib\distutils\cygwinccompiler.py", line 424, in
get_vers
ions
ld_version = StrictVersion(result.group(1))
File "C:\PRG\PYTHON25\lib\distutils\version.py", line 40, in __init__
self.parse(vstring)
File "C:\PRG\PYTHON25\lib\distutils\version.py", line 107, in parse
raise ValueError, "invalid version number '%s'" % vstring
ValueError: invalid version number '2.18.50.20080109'
For instance "ld -v" now returns "GNU ld (GNU Binutils)
2.18.50.20080109", not "GNU ld version 2.17.50 20060824". The extra
period between the version number and date causes class StrictVersion to
raise a ValueError. A fix is to alter the regular expressions in
cygwinccompiler.get_versions().
This enclosed patch to cygwinccompiler.py has been tested with the
current and previous linker as well as gcc 4.2.1 and gcc 3.4.5.
----------
components: Distutils
files: cygwinccompiler.patch
keywords: patch
messages: 63257
nosy: kermode
severity: normal
status: open
title: cygwinccompiler.py fails for latest MinGW releases.
versions: Python 2.5
Added file: http://bugs.python.org/file9604/cygwinccompiler.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2234>
__________________________________
From report at bugs.python.org Tue Mar 4 20:49:24 2008
From: report at bugs.python.org (jason kirtland)
Date: Tue, 04 Mar 2008 19:49:24 -0000
Subject: [New-bugs-announce] [issue2235] __eq__ / __hash__ check doesn't
take inheritance into account
In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za>
Message-ID: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za>
New submission from jason kirtland:
In 2.6a, seems like the __hash__ implementation and __eq__ must be
defined together, in the same class. See also #1549. Ensuring that a
__hash__ implementation isn't being pulled from a builtin type is
probably a sufficient check...?
>>> class Base(object):
... def __init__(self, name):
... self.name = name
... def __eq__(self, other):
... return self.name == other.name
... def __hash__(self):
... return hash(self.name)
...
>>> class Extended(Base):
... def __eq__(self, other):
... print "trace: __eq__ called"
... return Base.__eq__(self, other)
...
>>> hash(Base('b1'))
603887253
>>> hash(Extended('e1'))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'Extended'
----------
components: Interpreter Core
messages: 63258
nosy: jek
severity: normal
status: open
title: __eq__ / __hash__ check doesn't take inheritance into account
type: crash
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2235>
__________________________________
From report at bugs.python.org Tue Mar 4 21:56:48 2008
From: report at bugs.python.org (Henrique Romano)
Date: Tue, 04 Mar 2008 20:56:48 -0000
Subject: [New-bugs-announce] [issue2236] Distutils' mkpath implementation
ignoring the "mode" parameter
In-Reply-To: <1204664208.81.0.312695054648.issue2236@psf.upfronthosting.co.za>
Message-ID: <1204664208.81.0.312695054648.issue2236@psf.upfronthosting.co.za>
New submission from Henrique Romano:
The default value for mkpath's mode parameter is 0777 but it isn't used
at any place; attached is a patch that just pass the parameter to
os.mkdir call, this seems to fix the problem.
----------
components: Library (Lib)
files: python2.5-distutils_mkpath_filemode.v1.diff
keywords: patch
messages: 63259
nosy: henrique
severity: normal
status: open
title: Distutils' mkpath implementation ignoring the "mode" parameter
type: resource usage
versions: Python 2.5
Added file: http://bugs.python.org/file9605/python2.5-distutils_mkpath_filemode.v1.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2236>
__________________________________
From report at bugs.python.org Tue Mar 4 22:37:08 2008
From: report at bugs.python.org (Sylwester Warecki)
Date: Tue, 04 Mar 2008 21:37:08 -0000
Subject: [New-bugs-announce] [issue2237] Inconsistent variable lookup
In-Reply-To: <1204666628.06.0.657463410912.issue2237@psf.upfronthosting.co.za>
Message-ID: <1204666628.06.0.657463410912.issue2237@psf.upfronthosting.co.za>
New submission from Sylwester Warecki:
Hi!
An example below shows how differently local variables are treated in
case of simple variables and classes. In case of objects the variable
refers to global object, in case of simple number - it refers to a local.
Example 2 shows worse case scenario.
>From the text alone of the test2() function it is impossible to forsee
its behavior (!). If there is no global variable 'a' then it crashes
although without declaration of 'a' as a global it runs fine with the
'+' operator on 'a'. However that will not be the case IF test3() is
invoked.
That is illogical.
Example 3 shows the worst case scenario.
functions z0 and z1 differ only by the variable name on the left side of
the equation. In first case a is understood as global in second as
local. What makes no sense is that the right side of equation does not
change, however its interpretation is based on the left side of the
equation.
Example 4
This is an alteration of example 3 that shows the problem in full swing.
2 functions differ only by 2 last lines and yet they interpret the
variables in completely different way. In other words, adding a line to
end the code AFFECTS its beginning. That is least to say bizzaare.
..................
I tried to keep examples simple - hopefully that will help.
Regards,
Sylwester
=================================================================
class cheat:
def __init__( self ):
self.q = 4
a = cheat( )
b = 3
def test():
a.q = 22
b = 65
print "test a=", a.q
print "test b=", b
print "a=", a.q
print "b=", b
test()
print "a=", a.q
print "b=", b
=================================
example 2
class cheat2:
def __init__( self ):
self.q = 4
def __add__( self, val ):
self.q += val
a=cheat2()
def test2():
c = a + 4
print a.q
def test3():
a += 4
test2()
test3()
===================================================
example 3
def z0():
c = a + 2
def z1():
a = a + 2
a = 10
z0()
z1()
=================================================================
example 4
def t1():
print a
x=a+2
print x
An example below shows how differently local variables are treated in
case of simple variables and classes. In case of objects the variable
refers to global object, in case of simple number - it refers to a local.
Example 2 shows worse case scenario.
>From the text alone of the test2() function it is impossible to forsee
its behavior (!). If there is no global variable 'a' then it crashes
although without declaration of 'a' as a global it runs fine with the
'+' operator on 'a'. However that will not be the case IF test3() is
invoked.
That is illogical.
Example 3 shows the worst case scenario.
functions z0 and z1 differ only by the variable name on the left side of
the equation. In first case a is understood as global in second as
local. What makes no sense is that the right side of equation does not
change, however its interpretation is based on the left side of the
equation.
Example 4
This is an alteration of example 3 that shows the problem in full swing.
2 functions differ only by 2 last lines and yet they interpret the
variables in completely different way. In other words, adding a line to
end the code AFFECTS its beginning. That is least to say bizzaare.
..................
I tried to keep examples simple - hopefully that will help.
Regards,
Sylwester
=================================================================
class cheat:
def __init__( self ):
self.q = 4
a = cheat( )
b = 3
def test():
a.q = 22
b = 65
print "test a=", a.q
print "test b=", b
print "a=", a.q
print "b=", b
test()
print "a=", a.q
print "b=", b
=================================
example 2
class cheat2:
def __init__( self ):
self.q = 4
def __add__( self, val ):
self.q += val
a=cheat2()
def test2():
c = a + 4
print a.q
def test3():
a += 4
test2()
test3()
===================================================
example 3
def z0():
c = a + 2
def z1():
a = a + 2 # crash will happen here
a = 10
z0()
z1()
=================================================================
example 4
def t1():
print a
x=a+2
print x
def t2():
print a #crash will happen here
x=a+2
print x
a=a+4
print a
t1()
t2() # this one will crash!
----------
components: Interpreter Core
messages: 63261
nosy: swarecki
severity: normal
status: open
title: Inconsistent variable lookup
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2237>
__________________________________
From report at bugs.python.org Wed Mar 5 01:53:16 2008
From: report at bugs.python.org (Nathan Collins)
Date: Wed, 05 Mar 2008 00:53:16 -0000
Subject: [New-bugs-announce] [issue2238] TypeError instead of SyntaxError
for syntactically invalid gen exp
In-Reply-To: <1204678396.78.0.214556638013.issue2238@psf.upfronthosting.co.za>
Message-ID: <1204678396.78.0.214556638013.issue2238@psf.upfronthosting.co.za>
New submission from Nathan Collins:
I have a file f1.py
$ cat f1.py
import os
(lambda **x:x)(**dict(y,y for y in ()))
and when I run it
$ python f1.py
Traceback (most recent call last):
File "f1.py", line 1, in <module>
import os
TypeError: 'int' object is not iterable
Notice that the TypeError exception is from the import os on line 1.
But the import isn't the problem. The problem is the illegal
generator expression on line 2. I.e. if
$ cat f2.py
#import os
dict(y,y for y in ())
then
$ python f2.py
File "f2.py", line 2
dict(y,y for y in ())
SyntaxError: Generator expression must be parenthesized if not sole argument
The mess
(lambda **x:x)(**dict(y,y for y in ()))
is a simplified version of something I had about 100 lines into a
file, but the resulting TypeError still complains about an import on
line 1, which is really confusing.
I'm using
Python 2.5.2 (r252:60911, Mar 4 2008, 14:33:51)
[GCC 3.4.4] on linux2
for python.
################################################################################
The above is probably a good enough description, but here's some more
weirdness in case it's helpful:
Some variations of f1.py cause the same error, but others don't.
E.g. if f4.py is
for c in [1]: pass
(lambda **x:x)(**dict(y,y for y in ()))
I get
Traceback (most recent call last):
File "f4.py", line 1, in <module>
for c in [1]: pass
TypeError: 'int' object is not iterable
as before. But if f5.py is
for c in "1": pass
(lambda **x:x)(**dict(y,y for y in ()))
running the script results in no output and a successful run
$ echo $?
0
Finally, if f6.py is just the single line
(lambda **x:x)(**dict(y,y for y in ()))
then my 2.5.2 python has the same successful with no output result as
for f5.py, but if I run f6.py in an older
Python 2.5 (r25:51908, Oct 30 2006, 16:20:39)
[GCC 3.4.4] on linux2
python I get
Exception exceptions.SyntaxError: ('Generator expression must be
parenthesized if not sole argument', 1) in 'garbage collection' ignored
Fatal Python error: unexpected exception during garbage collection
zsh: abort (core dumped) python f6.py
The older 2.5 python runs f5.py successfully with no output like 2.5.2 does.
I searched the bug tracker for "TypeError: 'int' object is not
iterable" and didn't find anything, so I'm assuming this bug is
unknown. I'm sure someone will let me know if I'm mistaken =)
I'd guess the problem has to do with a bad parse.
----------
components: None
messages: 63273
nosy: NathanCollins
severity: normal
status: open
title: TypeError instead of SyntaxError for syntactically invalid gen exp
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2238>
__________________________________
From report at bugs.python.org Wed Mar 5 15:31:31 2008
From: report at bugs.python.org (Tim Golden)
Date: Wed, 05 Mar 2008 14:31:31 -0000
Subject: [New-bugs-announce] [issue2239] Tiny patch to cmdline docs
In-Reply-To: <1204727491.16.0.495455810446.issue2239@psf.upfronthosting.co.za>
Message-ID: <1204727491.16.0.495455810446.issue2239@psf.upfronthosting.co.za>
New submission from Tim Golden:
The docs for the PYTHONPATH var indicate that its items are separated by
colons. In fact they're separated by whatever's customary for the O/S.
Patch attached.
----------
components: Documentation
files: doc-using-cmdline-r61249.patch
keywords: patch
messages: 63276
nosy: georg.brandl, tim.golden
severity: normal
status: open
title: Tiny patch to cmdline docs
versions: Python 2.6
Added file: http://bugs.python.org/file9609/doc-using-cmdline-r61249.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2239>
__________________________________
From report at bugs.python.org Wed Mar 5 15:42:13 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 05 Mar 2008 14:42:13 -0000
Subject: [New-bugs-announce] [issue2240] setitimer, getitimer wrapper
In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za>
Message-ID: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za>
New submission from Guilherme Polo:
Right now Python misses a wrapper for setitimer and getitimer and I
believe it would be interesting to include them. I'm (almost) sure some
other people may find it useful too.
I'm attaching a standalone module, but if it gets to be included in
Python, I think it would be better to create a patch against signal
module. Also, its tests are pretty poor.
Improvements are welcomed.
----------
files: py-itimer-0.1.1.tar.gz
messages: 63277
nosy: gpolo
severity: normal
status: open
title: setitimer, getitimer wrapper
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file9610/py-itimer-0.1.1.tar.gz
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2240>
__________________________________
From report at bugs.python.org Wed Mar 5 17:24:32 2008
From: report at bugs.python.org (Brian White)
Date: Wed, 05 Mar 2008 16:24:32 -0000
Subject: [New-bugs-announce] [issue2241] Additional Flag For Unit-Test
Module: There Can Be Only One (Error)
In-Reply-To: <1204734272.92.0.489101809074.issue2241@psf.upfronthosting.co.za>
Message-ID: <1204734272.92.0.489101809074.issue2241@psf.upfronthosting.co.za>
New submission from Brian White:
The attached diff adds a "-o" ("--one") option to the "unittest" module
that causes the run to abort on the first error encountered. I name my
tests so that the lowest-level tests get run first so stopping at the
first error tends to prevent a lot of dependent errors and speed
debugging. During development, I typically run the tests I'm writing
with "-ov". During a full test run, I omit both those flags.
----------
components: Library (Lib)
files: unittest-diff25.py
messages: 63285
nosy: bcwhite
severity: normal
status: open
title: Additional Flag For Unit-Test Module: There Can Be Only One (Error)
type: feature request
versions: Python 2.5
Added file: http://bugs.python.org/file9612/unittest-diff25.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2241>
__________________________________
From report at bugs.python.org Thu Mar 6 03:31:03 2008
From: report at bugs.python.org (Chris Palmer)
Date: Thu, 06 Mar 2008 02:31:03 -0000
Subject: [New-bugs-announce] [issue2242] Decoding UTF-7 with "ignore
warnings" crashes Python on Windows Vista
In-Reply-To: <1204770663.59.0.831409423961.issue2242@psf.upfronthosting.co.za>
Message-ID: <1204770663.59.0.831409423961.issue2242@psf.upfronthosting.co.za>
New submission from Chris Palmer:
When decoding some data as UTF-7 with the optional "ignore" argument,
Python (I am using 2.5.2) crashes. This happens only on Windows Vista (I
also tried Py 2.5.1 on Windows XP, Ubuntu 7, and FreeBSD 6). To
reproduce, set WinDbg as your post-mortem debugger and run this code:
import os
while True:
a = os.urandom(16).decode("utf7", "ignore")
In WinDbg, you will see that Python died in isalnum with a bad pointer
dereference:
(f64.13b0): Access violation - code c0000005 (!!! second chance !!!)
eax=7c39a550 ebx=018e6837 ecx=0000ffe3 edx=00000003 esi=018edd66
edi=0000ffe3
eip=7c373977 esp=0021fc40 ebp=0000ffe3 iopl=0 nv up ei pl zr na
pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00010246
*** ERROR: Symbol file could not be found. Defaulted to export symbols
for C:\Windows\system32\MSVCR71.dll -
MSVCR71!isalnum+0x35:
7c373977 0fb70448 movzx eax,word ptr [eax+ecx*2]
ds:0023:7c3ba516=????
0:000> kb
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be
wrong.
0021fc3c 1e0dd81e 0000ffe3 00ff1030 0000012e MSVCR71!isalnum+0x35
00000000 00000000 00000000 00000000 00000000
python25!PyUnicode_DecodeUTF7+0x10e
It seems that a sanity check present in other Windows versions is
missing in Vista. The simplest possible test program:
#include "stdafx.h"
#include <ctype.h>
int _tmain(int argc, _TCHAR* argv[])
{
isalnum(0xff8b);
return 0;
}
causes Visual Studio 2005 to raise a debug assertion failure warning. I
guess that the assert is missing in the release build, and Python can be
tricked into providing the unsafe input to isalnum.
----------
components: Interpreter Core
messages: 63303
nosy: cpalmer
severity: normal
status: open
title: Decoding UTF-7 with "ignore warnings" crashes Python on Windows Vista
type: crash
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2242>
__________________________________
From report at bugs.python.org Thu Mar 6 11:17:05 2008
From: report at bugs.python.org (begemoth)
Date: Thu, 06 Mar 2008 10:17:05 -0000
Subject: [New-bugs-announce] [issue2243] urllib2. strange behavior for
getting chuncked transfer-ecnoded data
In-Reply-To: <1204798625.87.0.148151937521.issue2243@psf.upfronthosting.co.za>
Message-ID: <1204798625.87.0.148151937521.issue2243@psf.upfronthosting.co.za>
New submission from begemoth:
Through urllib2 open web pages from some sites (www.rbc.ru, www.rambler.ru, www.yandex.ru). Their servers send data in chuncked transfer-encoding. httplib (which is used by urllib2) "unchunk" data but I recieve "transfer-encoding: chuncked" in response header nevertheless. It seems to me that this key in header need to be removed from the header if httplib "unchuncked" the data.
----------
components: Library (Lib)
messages: 63316
nosy: begemoth
severity: normal
status: open
title: urllib2. strange behavior for getting chuncked transfer-ecnoded data
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2243>
__________________________________
From report at bugs.python.org Thu Mar 6 17:10:10 2008
From: report at bugs.python.org (Carl Meyer)
Date: Thu, 06 Mar 2008 16:10:10 -0000
Subject: [New-bugs-announce] [issue2244] urllib and urllib2 decode userinfo
multiple times
In-Reply-To: <1204819810.33.0.413464262118.issue2244@psf.upfronthosting.co.za>
Message-ID: <1204819810.33.0.413464262118.issue2244@psf.upfronthosting.co.za>
New submission from Carl Meyer:
Both urllib and urllib2 call urllib.unquote() multiple times on data in
the userinfo section of an FTP URL. One call occurs at the end of the
urllib.splituser() function. In urllib, the other call appears in
URLOpener.open_ftp(). In urllib2, the other two occur in
FTPHandler.ftp_open() and Request.get_host().
The effect of this is that if the userinfo section of an FTP url should
need to contain a literal % sign followed by two digits, the % sign must
be double-encoded as %2525 (for urllib) or triple-encoded as %252525
(for urllib2) in order for the URL to be accessed.
The proper behavior would be to only ever unquote a given data segment
once. The W3's URI: Generic Syntax RFC
(http://gbiv.com/protocols/uri/rfc/rfc3986.html) addresses this very
issue in section 2.4 (When to Encode or Decode): "Implementations must
not percent-encode or decode the same string more than once, as decoding
an already decoded string might lead to misinterpreting a percent data
octet as the beginning of a percent-encoding, or vice versa in the case
of percent-encoding an already percent-encoded string."
The solution would be to standardize where in urllib and urllib2 the
unquoting happens, and then make sure it happens nowhere else. I'm not
familiar enough with the libraries to know where it should be removed
without possibly breaking other behavior. It seems that just removing
the map/unquote call in urllib.splituser() would fix the problem in
urllib. I would guess the call in urllib2 Request.get_host() should
also be removed, as the RFC referenced above says clearly that only
individual data segments of the URL should be decoded, not larger
portions that might contain delimiters (: and @).
I've attached a patchset for these suggested changes. Very superficial
testing suggests that the patch doesn't break anything obvious, but I
make no guarantees.
----------
components: Library (Lib)
files: urllib-issue.patch
keywords: patch
messages: 63324
nosy: carljm
severity: normal
status: open
title: urllib and urllib2 decode userinfo multiple times
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9621/urllib-issue.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2244>
__________________________________
From report at bugs.python.org Thu Mar 6 17:52:24 2008
From: report at bugs.python.org (Oki Mikito)
Date: Thu, 06 Mar 2008 16:52:24 -0000
Subject: [New-bugs-announce] [issue2245] aifc cannot handle unrecognised
chunk type "CHAN"
In-Reply-To: <1204822344.2.0.466596380411.issue2245@psf.upfronthosting.co.za>
Message-ID: <1204822344.2.0.466596380411.issue2245@psf.upfronthosting.co.za>
New submission from Oki Mikito:
When aifc tries to open an AIFF audio file, it collects the file's chunk
information. Apparently some AIFF files contain a chunk type string "CHAN",
and the module just won't open the files...
Here's a captured error message:
------------
>>> import os
>>> os.getcwd()
'C:??Documents and Settings??loki'
>>> import aifc
>>> f=aifc.open('tr_04.aif','r')
Traceback (most recent call last):
File "<interactive input>", line 1, in <module>
File "C:?Python25?lib?aifc.py", line 928, in open
return Aifc_read(f)
File "C:?Python25?lib?aifc.py", line 341, in __init__
self.initfp(f)
File "C:?Python25?lib?aifc.py", line 320, in initfp
raise Error, 'unrecognized chunk type '+chunk.chunkname
Error: unrecognized chunk type CHAN
>>>
------------
Solution: Add 'CHAN' in the list of _skiplist item, in lib/aifc.py, line 147
----------
components: Library (Lib)
messages: 63326
nosy: loki_dePlume
severity: normal
status: open
title: aifc cannot handle unrecognised chunk type "CHAN"
type: feature request
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2245>
__________________________________
From report at bugs.python.org Thu Mar 6 20:39:29 2008
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Thu, 06 Mar 2008 19:39:29 -0000
Subject: [New-bugs-announce] [issue2246] itertools.groupby() leaks memory
with circular reference
In-Reply-To: <1204832369.47.0.680636098879.issue2246@psf.upfronthosting.co.za>
Message-ID: <1204832369.47.0.680636098879.issue2246@psf.upfronthosting.co.za>
New submission from Jeroen Ruigrok van der Werven:
Quoting from my email to Raymond:
In the Trac/Genshi community we've been tracking a bit obscure memory
leak that causes us a lot of problems.
Please see http://trac.edgewall.org/ticket/6614 and then
http://genshi.edgewall.org/ticket/190 for background.
We reduced the case to the following Python only code and believe it is
a bug within itertool's groupby. As Armin Ronacher explains in Genshi
ticket 190:
"Looks like genshi is not to blame. itertools.groupby has a grouper
with a reference to the groupby type but no traverse func. As soon as a
circular reference ends up in the groupby (which happens thanks to the
func_globals in our lambda) genshi leaks."
This can be demonstrated with the following code (testcase attachment
present with this issue):
import gc
from itertools import groupby
def run():
keyfunc = lambda x: x
for i, j in groupby(range(100), key=keyfunc):
keyfunc.x = j
for x in xrange(20):
gc.collect()
run()
print len(gc.get_objects())
On executing this in will show numerical output of the garbage
collector, but every iteration will be +4 from the previous, as Armin
specifies:
"a frame, a grouper, a keyfunc and a groupby object"
We have been unable to come up with a decent patch and thus I am
logging this issue now.
----------
files: testcase.py
messages: 63332
nosy: asmodai, rhettinger
severity: normal
status: open
title: itertools.groupby() leaks memory with circular reference
type: resource usage
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9624/testcase.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2246>
__________________________________
From report at bugs.python.org Thu Mar 6 21:29:04 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 06 Mar 2008 20:29:04 -0000
Subject: [New-bugs-announce] [issue2247] Test auto-assignment
Message-ID: <1204835344.33.0.569915653385.issue2247@psf.upfronthosting.co.za>
Changes by Martin v. L?wis:
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
nosy: georg.brandl, loewis
severity: normal
status: open
title: Test auto-assignment
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2247>
__________________________________
From report at bugs.python.org Fri Mar 7 08:42:58 2008
From: report at bugs.python.org (Kei Funagayama)
Date: Fri, 07 Mar 2008 07:42:58 -0000
Subject: [New-bugs-announce] [issue2248] quit() method of SMTP instance (of
smtplib) doesn't return it's result
In-Reply-To: <1204875778.72.0.769426067571.issue2248@psf.upfronthosting.co.za>
Message-ID: <1204875778.72.0.769426067571.issue2248@psf.upfronthosting.co.za>
New submission from Kei Funagayama:
Hi,
I've found that the quit() method of SMTP instance (of smtplib) doesn't
return it's result (such as '221 2.0.0 Bye') .
Other methods such as helo(), ehlo(), verify() etc.. returns it's result
correctly so I suppose it's a kind of bug.
I've made a small patch for this so please take a look at it (It looks
like someone just forgot to return the value of docmd()).
below is the code piece to represent the problem.
>>> import smtplib
>>> s = smtplib.SMTP('localhost')
>>> s.helo() #<---- returns result code
(250, 'localhost')
>>> s.vrfy('user at example.com') #<---- returns result code
(554, '5.7.1 <<user at example.com>>: Relay access denied')
>>> s.quit() #<----- doesn't return anything
>>>
Thanks,
Kei
----------
components: Library (Lib)
files: smtplib.py.patch
keywords: patch
messages: 63346
nosy: funagayama
severity: normal
status: open
title: quit() method of SMTP instance (of smtplib) doesn't return it's result
versions: Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9626/smtplib.py.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2248>
__________________________________
From report at bugs.python.org Fri Mar 7 09:39:25 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Fri, 07 Mar 2008 08:39:25 -0000
Subject: [New-bugs-announce] [issue2249] To document "assertTrue" in unittest
In-Reply-To: <1204879165.33.0.589242853874.issue2249@psf.upfronthosting.co.za>
Message-ID: <1204879165.33.0.589242853874.issue2249@psf.upfronthosting.co.za>
New submission from Jes?s Cea Avi?n:
Python 2.4 and 2.5 unittest includes a "assertTrue" method undocumented.
Document it.
It is the same method as "assert_" and "failUnless", but the name seems
clearer.
----------
assignee: georg.brandl
components: Documentation
messages: 63347
nosy: georg.brandl, jcea
severity: minor
status: open
title: To document "assertTrue" in unittest
versions: Python 2.5, Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2249>
__________________________________
From report at bugs.python.org Fri Mar 7 11:49:57 2008
From: report at bugs.python.org (Lorenz Quack)
Date: Fri, 07 Mar 2008 10:49:57 -0000
Subject: [New-bugs-announce] [issue2250] rlcompleter raises Exception on bad
input
In-Reply-To: <1204886997.65.0.75088007868.issue2250@psf.upfronthosting.co.za>
Message-ID: <1204886997.65.0.75088007868.issue2250@psf.upfronthosting.co.za>
New submission from Lorenz Quack:
in line 130 rlcompleter calls eval on the first part (before the last
dot) of the input text.
if that part is not valid it will raise an exception which is likely to
crash a calling application.
example 1:
==========
import rlcompleter
rlcompleter.Completer().complete("foo.", 0) -> raises NameError
example 2:
==========
import rlcompleter
foo = 5
rlcompleter.Completer().complete("foo.bar.", 0) -> raises AttributeError
the patch puts the eval call in a try-except block and catches Name- and
AttributeErrors and returns an empty list (the behavior when no matches
are found).
----------
components: Library (Lib)
files: rlcompleter.patch
keywords: patch
messages: 63349
nosy: donlorenzo
severity: normal
status: open
title: rlcompleter raises Exception on bad input
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9627/rlcompleter.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2250>
__________________________________
From report at bugs.python.org Fri Mar 7 12:17:51 2008
From: report at bugs.python.org (Goten Xiao)
Date: Fri, 07 Mar 2008 11:17:51 -0000
Subject: [New-bugs-announce] [issue2251] tarfile using nonexistent function
In-Reply-To: <1204888671.17.0.924407894486.issue2251@psf.upfronthosting.co.za>
Message-ID: <1204888671.17.0.924407894486.issue2251@psf.upfronthosting.co.za>
New submission from Goten Xiao:
Steps to reproduce:
Create test.py with the following contents:
tar = tarfile.open("test.tar", "w")
tar.addfile("testdir")
tar.close()
Run the following commands (or equivalent on alternative platforms):
mkdir testdir
touch testdir/testfile
python test.py
Resultant output:
Traceback (most recent call last):
File "test.py", line 4, in <module>
tar.addfile("testdir")
File "/usr/lib/python2.5/tarfile.py", line 1492, in addfile
buf = tarinfo.tobuf(self.posix)
AttributeError: 'str' object has no attribute 'tobuf'
Tested on Python 2.5.1 and 2.5.2 from slackware-current packages.
----------
components: Library (Lib)
messages: 63351
nosy: GotenXiao
severity: major
status: open
title: tarfile using nonexistent function
type: crash
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2251>
__________________________________
From report at bugs.python.org Fri Mar 7 19:10:12 2008
From: report at bugs.python.org (Ben Pfaff)
Date: Fri, 07 Mar 2008 18:10:12 -0000
Subject: [New-bugs-announce] [issue2252] "continue" documentation
Message-ID: <1204913412.29.0.439518703627.issue2252@psf.upfronthosting.co.za>
Changes by Ben Pfaff:
----------
assignee: georg.brandl
components: Documentation
nosy: blp, georg.brandl
severity: normal
status: open
title: "continue" documentation
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2252>
__________________________________
From report at bugs.python.org Fri Mar 7 19:12:29 2008
From: report at bugs.python.org (Ben Pfaff)
Date: Fri, 07 Mar 2008 18:12:29 -0000
Subject: [New-bugs-announce] [issue2253] "continue" documentation internally
inconsistent
In-Reply-To: <1204913549.67.0.904198445457.issue2253@psf.upfronthosting.co.za>
Message-ID: <1204913549.67.0.904198445457.issue2253@psf.upfronthosting.co.za>
New submission from Ben Pfaff:
The "continue" documentation says: "continue may only occur
syntactically nested in a for or while loop, but not nested in a
function or class definition or finally statement within that loop."
In a footnote to that documentation, it says: "The restriction on
occurring in the try clause is implementor's laziness and will
eventually be lifted."
But the documentation doesn't say that continue may not occur in the try
clause. So there is an internal inconsistency here. Either the
sentence in the footnote is wrong and should be removed, or the main
documentation for continue should say that continue may not occur in a
try clause.
----------
assignee: georg.brandl
components: Documentation
messages: 63358
nosy: blp, georg.brandl
severity: minor
status: open
title: "continue" documentation internally inconsistent
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2253>
__________________________________
From report at bugs.python.org Fri Mar 7 20:59:45 2008
From: report at bugs.python.org (sumar)
Date: Fri, 07 Mar 2008 19:59:45 -0000
Subject: [New-bugs-announce] [issue2254] Python CGIHTTPServer information
disclosure
In-Reply-To: <1204919985.1.0.220899639338.issue2254@psf.upfronthosting.co.za>
Message-ID: <1204919985.1.0.220899639338.issue2254@psf.upfronthosting.co.za>
New submission from sumar:
================================================================================
Summary:
================================================================================
An information disclosure flaw exists in standard python CGIHTTPServer
module.
Bug is confirmed in python 2.5 @ fedora 7 (python-2.5-15.fc7).
================================================================================
Description:
================================================================================
Requesting cgi script (in example test.py) without / in the beginnig of URL
cause return script content/code instead of script execution.
It could lead to disclose some secret information eg. password.
================================================================================
Exploit code:
================================================================================
Connected to localhost.
Escape character is '^]'.
GET cgi-bin/test.py HTTP/1.0
HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/2.5
Date: Fri, 07 Mar 2008 14:55:30 GMT
Content-type: text/plain
Content-Length: 150
Last-Modified: Fri, 07 Mar 2008 14:55:04 GMT
#!/usr/bin/env python
print 'Content-Type: text/html'
print 'Cache-Control: no-cache'
print
print 'Hello'
passwd='secret'
path=/opt/myapp/secretpath
Connection closed by foreign host.
================================================================================
correct request:
================================================================================
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /cgi-bin/test.py HTTP/1.0
HTTP/1.0 200 Script output follows
Server: SimpleHTTP/0.6 Python/2.5
Date: Fri, 07 Mar 2008 15:01:03 GMT
Content-Type: text/html
Cache-Control: no-cache
Hello
Connection closed by foreign host.
================================================================================
----------
components: Library (Lib)
messages: 63361
nosy: m.sucajtys
severity: normal
status: open
title: Python CGIHTTPServer information disclosure
type: security
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2254>
__________________________________
From report at bugs.python.org Fri Mar 7 23:14:23 2008
From: report at bugs.python.org (=?utf-8?q?Nicolas_L=C3=A9cureuil?=)
Date: Fri, 07 Mar 2008 22:14:23 -0000
Subject: [New-bugs-announce] [issue2255] Change Mandrake by Mandriva for
platform.dist()
In-Reply-To: <1204928063.97.0.960198270628.issue2255@psf.upfronthosting.co.za>
Message-ID: <1204928063.97.0.960198270628.issue2255@psf.upfronthosting.co.za>
New submission from Nicolas L?cureuil:
here is a patch fixing the issue by changing mandrake to mandriva
----------
components: Library (Lib)
files: python-2.5-change-mandrake.patch
keywords: patch
messages: 63370
nosy: neoclust
severity: normal
status: open
title: Change Mandrake by Mandriva for platform.dist()
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9633/python-2.5-change-mandrake.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2255>
__________________________________
From report at bugs.python.org Sat Mar 8 00:33:46 2008
From: report at bugs.python.org (Jim Kleckner)
Date: Fri, 07 Mar 2008 23:33:46 -0000
Subject: [New-bugs-announce] [issue2256] Install failure of 2.6a1 on Windows
XP without VS8 installed
In-Reply-To: <1204932826.89.0.672189283054.issue2256@psf.upfronthosting.co.za>
Message-ID: <1204932826.89.0.672189283054.issue2256@psf.upfronthosting.co.za>
New submission from Jim Kleckner:
When I install 2.6a1 onto a Windoze machine I get a dialog:
There is a problem with this Windows Installer package.
A program run as part of the setup did not finish as expected.
Contact your support personnel or package vendor.
Note that it didn't have VS2008 or any other new code installed.
The problem appears related to Tkinter but that isn't clear.
When running the Python console, running
import Tkinter
results in an error saying that _tkinter can't be loaded.
DLL load failed. The system can't find _tkinter.pyd
_tkinter.pyd and tcl84.dll and tk84.dll are in DLLs and
appear to have reasonable permissions.
I suspect something in the install failed to set something
in the registry.
This is on a current-patch XP
system and that I also tried python-2.6.13944.msi
from the buildbot just in case after uninstalling/reinstalling
with no difference.
Attached is a compressed log of the install.
Perhaps this "PROPERTY CHANGE: Deleting SECONDSEQUENCE"
is the problem?
Here is an excerpt from the log file:
Property(S): Privileged = 1
Property(S): DATABASE = C:\WINDOWS\Installer\5f5ad0.msi
Property(S): OriginalDatabase = C:\cygwin\tmp\python-2.6a1.msi
Property(S): UILevel = 5
Property(S): Preselected = 1
Property(S): CostingComplete = 1
Property(S): OutOfDiskSpace = 0
Property(S): OutOfNoRbDiskSpace = 0
Property(S): PrimaryVolumeSpaceAvailable = 0
Property(S): PrimaryVolumeSpaceRequired = 0
Property(S): PrimaryVolumeSpaceRemaining = 0
Property(S): SOURCEDIR = C:\cygwin\tmp\
Property(S): SourcedirProduct = {0BA82E1B-52FD-4E03-8610-A6C76238E8A8}
Property(S): ProductToBeRegistered = 1
MSI (s) (FC:D0) [16:38:30:939]: MainEngineThread is returning 1603
MSI (s) (FC:C0) [16:38:30:939]: Destroying RemoteAPI object.
MSI (s) (FC:54) [16:38:30:939]: Custom Action Manager thread ending.
MSI (c) (E0:54) [16:38:30:954]: Back from server. Return value: 1603
MSI (c) (E0:54) [16:38:30:954]: Decrementing counter to disable
shutdown. If counter >= 0, shutdown will be denied. Counter after
decrement: -1
MSI (c) (E0:54) [16:38:30:954]: PROPERTY CHANGE: Deleting SECONDSEQUENCE
property. Its current value is '1'.
Action ended 16:38:30: ExecuteAction. Return value 3.
MSI (c) (E0:54) [16:38:30:954]: Doing action: FatalError
Action 16:38:30: FatalError.
Action start 16:38:30: FatalError.
Action 16:38:30: FatalError. Dialog created
Action ended 16:38:32: FatalError. Return value 2.
Action ended 16:38:32: INSTALL. Return value 3.
MSI (c) (E0:54) [16:38:32:375]: Destroying RemoteAPI object.
MSI (c) (E0:2C) [16:38:32:375]: Custom Action Manager thread ending.
Property(C): X = C:\Python26\Tools\pynche\X\
Property(C): UpgradeCode = {65E6DE48-A358-434D-AA4F-4AF72DB4718F}
Property(C): ProductName = Python 2.6a1
Property(C): ProductCode = {0BA82E1B-52FD-4E03-8610-A6C76238E8A8}
Property(C): ProductVersion = 2.6.101
Property(C): Manufacturer = Python Software Foundation
----------
components: Installation
files: debuglog.txt.zip
messages: 63371
nosy: jkleckner
severity: normal
status: open
title: Install failure of 2.6a1 on Windows XP without VS8 installed
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9634/debuglog.txt.zip
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2256>
__________________________________
From report at bugs.python.org Sat Mar 8 01:40:09 2008
From: report at bugs.python.org (k-e-n)
Date: Sat, 08 Mar 2008 00:40:09 -0000
Subject: [New-bugs-announce] [issue2257] typo in tutorial section 4.4 -
final break statement is missing
In-Reply-To: <1204936809.05.0.981645183837.issue2257@psf.upfronthosting.co.za>
Message-ID: <1204936809.05.0.981645183837.issue2257@psf.upfronthosting.co.za>
New submission from k-e-n:
The code from section 4.4 of the tutorial follows.
This code does not produce the output shown.
Adding a final break statement will fix this.
>>> for n in range(2, 10):
... for x in range(2, n):
... if n % x == 0:
... print n, 'equals', x, '*', n/x
... break
... else:
... # loop fell through without finding a factor
... print n, 'is a prime number'
...
2 is a prime number
3 is a prime number
4 equals 2 * 2
5 is a prime number
6 equals 2 * 3
7 is a prime number
8 equals 2 * 4
9 equals 3 * 3
----------
assignee: georg.brandl
components: Documentation
messages: 63374
nosy: Kyte999, georg.brandl
severity: minor
status: open
title: typo in tutorial section 4.4 - final break statement is missing
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2257>
__________________________________
From report at bugs.python.org Sun Mar 9 11:55:18 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 09 Mar 2008 10:55:18 +0000
Subject: [New-bugs-announce] [issue2258] Update command line docs for issue
1739468
In-Reply-To: <1205060118.8.0.321135862814.issue2258@psf.upfronthosting.co.za>
Message-ID: <1205060118.8.0.321135862814.issue2258@psf.upfronthosting.co.za>
New submission from Nick Coghlan <ncoghlan at gmail.com>:
The ability to execute zip files and directories containing a
__main__.py file needs to be covered in the documentation of the command
line options.
----------
assignee: ncoghlan
components: Documentation
keywords: easy
messages: 63412
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Update command line docs for issue 1739468
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2258>
__________________________________
From report at bugs.python.org Sun Mar 9 16:06:47 2008
From: report at bugs.python.org (Oki Mikito)
Date: Sun, 09 Mar 2008 15:06:47 +0000
Subject: [New-bugs-announce] [issue2259] Poor support other than 44.1khz,
16bit audio files?
In-Reply-To: <1205075207.56.0.203597492215.issue2259@psf.upfronthosting.co.za>
Message-ID: <1205075207.56.0.203597492215.issue2259@psf.upfronthosting.co.za>
New submission from Oki Mikito <moki at u01.gate01.com>:
It appears that aifc, as well as wave, does not support audio files other
than 44100 hz 16-bit format.
--
>>> f = aifc.open('Track 06')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/aifc.py",
line 928, in open
return Aifc_read(f)
File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/aifc.py",
line 341, in __init__
self.initfp(f)
File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/aifc.py",
line 321, in initfp
chunk.skip()
File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/chunk.py",
line 158, in skip
self.file.seek(n, 1)
File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/chunk.py",
line 111, in seek
raise RuntimeError
RuntimeError
--
Could it be that the 'Chunk' class in chunk module may be returning improper
values...? In any case, aifc refuses to open a 24bit 44100hz audio file.
Does anyone have insights on this?
----------
components: Library (Lib)
messages: 63419
nosy: loki_dePlume
severity: major
status: open
title: Poor support other than 44.1khz, 16bit audio files?
type: feature request
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2259>
__________________________________
From report at bugs.python.org Sun Mar 9 16:36:00 2008
From: report at bugs.python.org (Paul Pogonyshev)
Date: Sun, 09 Mar 2008 15:36:00 +0000
Subject: [New-bugs-announce] [issue2260] conditional jump to a POP_TOP
optimization
In-Reply-To: <1205076960.06.0.224700727301.issue2260@psf.upfronthosting.co.za>
Message-ID: <1205076960.06.0.224700727301.issue2260@psf.upfronthosting.co.za>
New submission from Paul Pogonyshev <pogonyshev at gmx.net>:
This optimization targets a common case of functions like this:
def foo(a, b):
if a:
if b:
return 'true'
Before the optimization:
6 0 LOAD_FAST 0 (a)
3 JUMP_IF_FALSE 16 (to 22)
6 POP_TOP
7 7 LOAD_FAST 1 (b)
10 JUMP_IF_FALSE 5 (to 18)
13 POP_TOP
8 14 LOAD_CONST 1 ('true')
17 RETURN_VALUE
>> 18 POP_TOP
19 JUMP_FORWARD 1 (to 23)
>> 22 POP_TOP
>> 23 LOAD_CONST 0 (None)
26 RETURN_VALUE
After:
6 0 LOAD_FAST 0 (a)
3 JUMP_IF_FALSE 16 (to 22)
6 POP_TOP
7 7 LOAD_FAST 1 (b)
10 JUMP_IF_FALSE 9 (to 22)
13 POP_TOP
8 14 LOAD_CONST 1 ('true')
17 RETURN_VALUE
18 POP_TOP
19 JUMP_FORWARD 1 (to 23)
>> 22 POP_TOP
>> 23 LOAD_CONST 0 (None)
26 RETURN_VALUE
Note that size of bytecode doesn't become smaller, however one execution
branch (jump from offset 10) becomes shorter by one JUMP_FORWARD.
Additionally, two commands at offset 18 become unreachable. However,
they will not be removed by the patch in issue1394 currently, because
there is a basic-block change at 18, where JUMP_IF_FALSE previously had
its target. If we want unreachable code be removed in such cases, we
need to make peepholer make two passes with recomputing blocks[] in
between. This would enable more optimizations.
----------
components: Interpreter Core
files: jump-to-pop-optimization.diff
keywords: patch
messages: 63422
nosy: _doublep
severity: minor
status: open
title: conditional jump to a POP_TOP optimization
Added file: http://bugs.python.org/file9640/jump-to-pop-optimization.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2260>
__________________________________
From report at bugs.python.org Sun Mar 9 16:36:40 2008
From: report at bugs.python.org (Paul Molodowitch)
Date: Sun, 09 Mar 2008 15:36:40 +0000
Subject: [New-bugs-announce] [issue2261] Warning: could not send message for
past 4 hours
In-Reply-To: <200803091056.m29AshJ3018916@gourmet.spamgourmet.com>
Message-ID: <200803091056.m29AshJ3018916@gourmet.spamgourmet.com>
New submission from Paul Molodowitch <python.calin79 at neverbox.com>:
**********************************************
** THIS IS A WARNING MESSAGE ONLY **
** YOU DO NOT NEED TO RESEND YOUR MESSAGE **
**********************************************
The original message was received at Sun, 9 Mar 2008 05:01:30 GMT
from jqh1 at localhost
----- Transcript of session follows -----
451 spamgourmet.com: Name server timeout
451 spamgourmet.com: Name server timeout
451 gmail.com: Name server timeout
Warning: message still undelivered after 4 hours
Will keep trying until message is 5 days old
451 spamgourmet.com: Name server timeout
----------
files: unnamed, unnamed
messages: 63423
nosy: barnabas79
severity: normal
status: open
title: Warning: could not send message for past 4 hours
Added file: http://bugs.python.org/file9641/unnamed
Added file: http://bugs.python.org/file9642/unnamed
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2261>
__________________________________
-------------- next part --------------
An embedded message was scrubbed...
From: unknown sender
Subject: no subject
Date: no date
Size: 3013
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20080309/71519144/attachment.eml
From report at bugs.python.org Sun Mar 9 18:38:52 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sun, 09 Mar 2008 17:38:52 +0000
Subject: [New-bugs-announce] [issue2262] Helping the compiler avoid memory
references in PyEval_EvalFrameEx
In-Reply-To: <1205084332.03.0.568369699233.issue2262@psf.upfronthosting.co.za>
Message-ID: <1205084332.03.0.568369699233.issue2262@psf.upfronthosting.co.za>
New submission from Jeffrey Yasskin <jyasskin at gmail.com>:
I'm using Apple's gcc-4.0.1 on a 2.33GHz Intel Core 2 Duo to test this.
Measurements from other compilers or other chips would be cool.
Specifically, this patch:
1) Moves the declarations of most of the local variables inside the
for(;;) loop. That shortens their lifetimes so that the compiler can
skip spilling them to memory in some cases. Pushing them further down
into the individual case statements didn't change the generated assembly
in most cases, although there are probably a few opcodes where it would.
2) Eliminates the initialization of w, and fixes the "possibly used
uninitialized" warning by changing how the PRINT opcodes initialize it
from stream. That lets my compiler avoid using its stack entry most of
the time.
3) In two hot opcodes, LOAD_FAST and LOAD_CONST, changes the 'x' to a
'w'. 'x' is always written to memory because it's used for error
detection, while 'w' can stay on the stack.
4) Changes --_Py_Ticker in the periodic things check to _Py_Ticker--.
Because _Py_Ticker is volatile, predecrement (at least on my compiler)
needs 3 memory accesses, while postdecrement gets away with 2.
Together, these changes are worth about 3% on pybench on my machine.
----------
components: Interpreter Core
files: elim_mem_refs.patch
keywords: patch, patch
messages: 63426
nosy: jyasskin
severity: normal
status: open
title: Helping the compiler avoid memory references in PyEval_EvalFrameEx
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9643/elim_mem_refs.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2262>
__________________________________
From report at bugs.python.org Mon Mar 10 08:39:24 2008
From: report at bugs.python.org (Just van Rossum)
Date: Mon, 10 Mar 2008 07:39:24 +0000
Subject: [New-bugs-announce] [issue2263] struct.pack() + numpy int raises
SystemError
In-Reply-To: <1205134764.8.0.415620235375.issue2263@psf.upfronthosting.co.za>
Message-ID: <1205134764.8.0.415620235375.issue2263@psf.upfronthosting.co.za>
New submission from Just van Rossum <just at letterror.com>:
struct.pack() raises SystemError when fed a numpy integer in some cases.
The following was run on MacOSX 10.4, little endian (I can only
reproduce the error if I specify big endian for the struct format). Not
sure if this could be a numpy bug.
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 struct
>>> import numpy
>>> i = numpy.int16(1)
>>> struct.pack(">B", i)
__main__:1: DeprecationWarning: struct integer overflow masking is
deprecated
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/struct.
py", line 63, in pack
return o.pack(*args)
SystemError: /Users/ronald/r252/Objects/longobject.c:322: bad argument
to internal function
>>> struct.pack(">H", i)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/struct.
py", line 63, in pack
return o.pack(*args)
SystemError: /Users/ronald/r252/Objects/longobject.c:322: bad argument
to internal function
>>> struct.pack(">h", i)
'\x00\x01'
>>> struct.pack(">b", i)
'\x01'
>>> struct.pack("B", i)
'\x01'
>>> struct.pack("h", i)
'\x01\x00'
>>> numpy.__version__
'1.0.4'
>>>
----------
components: Library (Lib)
messages: 63435
nosy: jvr
severity: normal
status: open
title: struct.pack() + numpy int raises SystemError
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2263>
__________________________________
From report at bugs.python.org Mon Mar 10 12:05:24 2008
From: report at bugs.python.org (Eric Smith)
Date: Mon, 10 Mar 2008 11:05:24 +0000
Subject: [New-bugs-announce] [issue2264] empty specifier for
float.__format__ does not always print at least one decimal digit
In-Reply-To: <1205147124.28.0.679572132371.issue2264@psf.upfronthosting.co.za>
Message-ID: <1205147124.28.0.679572132371.issue2264@psf.upfronthosting.co.za>
New submission from Eric Smith <eric at trueblade.com>:
PEP 3101 specifies that the empty format presentation type for float
will always print at least one digit after the decimal point, but it
does not do that if the number is output with an exponent:
works:
>>> format(3.0, '')
'3.0'
fails:
>>> format(3e200, '')
'3e+200'
As currently implemented, the code just maps the empty format specifier
to 'g', and does not add the additional behavior specfied in the PEP.
----------
assignee: eric.smith
components: Interpreter Core
messages: 63438
nosy: eric.smith
priority: normal
severity: normal
status: open
title: empty specifier for float.__format__ does not always print at least one decimal digit
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2264>
__________________________________
From report at bugs.python.org Mon Mar 10 14:55:37 2008
From: report at bugs.python.org (Kazuyoshi Furutaka)
Date: Mon, 10 Mar 2008 13:55:37 +0000
Subject: [New-bugs-announce] [issue2265] A line in the second example of
"7.3.5 Examples" in "Python Library Reference" seems to be
incorrect.
In-Reply-To: <1205157337.33.0.156583580671.issue2265@psf.upfronthosting.co.za>
Message-ID: <1205157337.33.0.156583580671.issue2265@psf.upfronthosting.co.za>
New submission from Kazuyoshi Furutaka <furutaka at jb3.so-net.ne.jp>:
The line
destination.add(MHMessage(message))
should read
destination.add(mailbox.MHMessage(message))
----------
assignee: georg.brandl
components: Documentation
messages: 63442
nosy: furutaka, georg.brandl
severity: minor
status: open
title: A line in the second example of "7.3.5 Examples" in "Python Library Reference" seems to be incorrect.
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2265>
__________________________________
From report at bugs.python.org Mon Mar 10 17:45:05 2008
From: report at bugs.python.org (Yinon Ehrlich)
Date: Mon, 10 Mar 2008 16:45:05 +0000
Subject: [New-bugs-announce] [issue2266] Missing documentation about
old/new-style classes
In-Reply-To: <1205167505.81.0.00833692461216.issue2266@psf.upfronthosting.co.za>
Message-ID: <1205167505.81.0.00833692461216.issue2266@psf.upfronthosting.co.za>
New submission from Yinon Ehrlich <yinoneh at users.sourceforge.net>:
http://docs.python.org/tut/node11.html talks about old/new style
classes. But there is no any explanation what it is. The same for
http://docs.python.org/ref/node33.html
My suggestion: refer to http://wiki.python.org/moin/NewClassVsClassicClass
----------
assignee: georg.brandl
components: Documentation
messages: 63445
nosy: Yinon, georg.brandl
severity: minor
status: open
title: Missing documentation about old/new-style classes
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2266>
__________________________________
From report at bugs.python.org Mon Mar 10 20:09:55 2008
From: report at bugs.python.org (Paul Komkoff)
Date: Mon, 10 Mar 2008 19:09:55 +0000
Subject: [New-bugs-announce] [issue2267] datetime.datetime operator methods
are not subclass-friendly
In-Reply-To: <1205176194.96.0.747568659994.issue2267@psf.upfronthosting.co.za>
Message-ID: <1205176194.96.0.747568659994.issue2267@psf.upfronthosting.co.za>
New submission from Paul Komkoff <theraphim at gmail.com>:
The datetime.datetime class overrides some arithmetic operations for it
to be able to add or subtract timedeltas. However, the result of A + B
operation, where A is instance of a subclass of datetime and B is
timedelta instance will be always the instance of base datetime.
This is extremely annoying and requires to override arithmetic operators
and writing a lots of rubbish to replace the datetime base object with
type(self)
----------
components: Library (Lib)
messages: 63446
nosy: stingray
severity: normal
status: open
title: datetime.datetime operator methods are not subclass-friendly
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2267>
__________________________________
From report at bugs.python.org Mon Mar 10 20:12:37 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 10 Mar 2008 19:12:37 +0000
Subject: [New-bugs-announce] [issue2268] Fold slice constants
In-Reply-To: <1205176357.46.0.777488164944.issue2268@psf.upfronthosting.co.za>
Message-ID: <1205176357.46.0.777488164944.issue2268@psf.upfronthosting.co.za>
New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:
I am attaching a proof-of-concept patch which would optimize bytecode
generated from constant slices as follows:
Before patch:
>>> dis(lambda:x[1:2:3])
1 0 LOAD_GLOBAL 0 (x)
3 LOAD_CONST 0 (1)
6 LOAD_CONST 1 (2)
9 LOAD_CONST 2 (3)
12 BUILD_SLICE 3
15 BINARY_SUBSCR
16 RETURN_VALUE
After the patch:
>>> dis(lambda:x[1:2:3])
1 0 LOAD_GLOBAL 0 (x)
3 LOAD_CONST 3 (slice(1, 2, 3))
6 BINARY_SUBSCR
7 RETURN_VALUE
While the peephole optimizer changes are straightforward, the
optimization does not work unless slice objects gain hash and marshal
support.
While I don't see any problem with adding slice marshaling, the idea of
making slices hashable has recently been rejected (see issue1733184) and
I was supporting the rejection myself.
With this patch, however, I would like to reopen the discussion of
hash(slice(..)) issue.
Allowing constant folding for slices may tip the balance towards
allowing hash(slice(..)) assuming that {}[:] can still be prohibited.
One possible approach to this problem would be to emit a new bytecode
instead of BINARY_SUBSCR from slice syntax and have it reject mapping
objects. This should be easy for objects implemented in C, but for user
defined classes with custom __(get|set)item__ it may not be easy to
distinguish between a mapping and a sequence. However, I don't much of
a problem for always allowing x[:] for such types (user code can reject
slices if necessary).
If extra bytecode approach is taken, it is likely that d[slice(a,b)]
will end up being supported even if d[a:b] is not. Some may think it
would be a good feature, though.
A possible advantage of that approach would be a better error message
from an attempt to slice a dictionary. The current "unhashable type"
diagnostic is somewhat cryptic. "Cannot slice a dictionary" would be
much friendlier.
It is possible to work around unhashability of slices and still
implement folding, but the ideas that come to mind such as placing a
hashable subclass of slice into constants seem too artificial.
I am copying the "nosy" list from issue1733184 to start the discussion.
----------
components: Interpreter Core
files: const-slice-folding.diff
keywords: patch
messages: 63447
nosy: belopolsky, exarkun, gvanrossum, lpd, rhettinger
severity: normal
status: open
title: Fold slice constants
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file9650/const-slice-folding.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2268>
__________________________________
From report at bugs.python.org Mon Mar 10 21:29:39 2008
From: report at bugs.python.org (Isaac Morland)
Date: Mon, 10 Mar 2008 20:29:39 +0000
Subject: [New-bugs-announce] [issue2269] Problem reporting non-keyword arg
after keyword arg syntax error
In-Reply-To: <1205180979.73.0.892316132999.issue2269@psf.upfronthosting.co.za>
Message-ID: <1205180979.73.0.892316132999.issue2269@psf.upfronthosting.co.za>
New submission from Isaac Morland <ijmorlan at uwaterloo.ca>:
$ cat bug_fine.py
if True:
max (a='a', 'b')
#elif True:
# pass
else:
pass
$ python bug_fine.py
File "bug_fine.py", line 2
max (a='a', 'b')
SyntaxError: non-keyword arg after keyword arg
$ cat bug_show.py
if True:
max (a='a', 'b')
elif True:
pass
else:
pass
$ python bug_show.py
Exception exceptions.SyntaxError: ('non-keyword arg after keyword arg',
2) in 'garbage collection' ignored
Fatal Python error: unexpected exception during garbage collection
Abort trap
$
----------
components: Interpreter Core
messages: 63448
nosy: ijmorlan
severity: normal
status: open
title: Problem reporting non-keyword arg after keyword arg syntax error
type: compile error
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2269>
__________________________________
From report at bugs.python.org Mon Mar 10 21:51:33 2008
From: report at bugs.python.org (T.G.M.)
Date: Mon, 10 Mar 2008 20:51:33 +0000
Subject: [New-bugs-announce] [issue2270] Typo on 8.6.2.5 Document Objects
page
In-Reply-To: <1205182293.42.0.895316772426.issue2270@psf.upfronthosting.co.za>
Message-ID: <1205182293.42.0.895316772426.issue2270@psf.upfronthosting.co.za>
New submission from T.G.M. <throw6617 at gmail.com>:
The Python 2.5.2 online docs,
"http://docs.python.org/lib/dom-document-objects.html"
(http://docs.python.org/lib/dom-document-objects.html) has the following
2nd sentence:
Remeber that it inherits properties from Node.
Remeber should be Remember.
----------
assignee: georg.brandl
components: Documentation
messages: 63450
nosy: georg.brandl, throw6617
severity: normal
status: open
title: Typo on 8.6.2.5 Document Objects page
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2270>
__________________________________
From report at bugs.python.org Tue Mar 11 00:33:51 2008
From: report at bugs.python.org (Ross)
Date: Mon, 10 Mar 2008 23:33:51 +0000
Subject: [New-bugs-announce] [issue2271] msi installs to the incorrect
location (C drive)
In-Reply-To: <1205192031.56.0.450495581231.issue2271@psf.upfronthosting.co.za>
Message-ID: <1205192031.56.0.450495581231.issue2271@psf.upfronthosting.co.za>
New submission from Ross <rossmclendon at tamu.edu>:
When installing Python using any of the following stand-alone installers:
python-2.5.2.amd64.msi
python-2.5.1.amd64.msi
python-2.5.2.msi
all the files and folders are installed in C:\ instead of C:\Python25\
as specified in the installer. Creating C:\Python25\ before
installation, changing the folder name, and rebooting the machine did
not solve the problem. The installation is being performed on Windows
Vista Enterprise 64 bit with an Intel Q6600 processor machine.
----------
components: Installation, Windows
messages: 63455
nosy: rossmclendon
severity: normal
status: open
title: msi installs to the incorrect location (C drive)
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2271>
__________________________________
From report at bugs.python.org Tue Mar 11 12:21:02 2008
From: report at bugs.python.org (David Harel)
Date: Tue, 11 Mar 2008 11:21:02 +0000
Subject: [New-bugs-announce] [issue2272] Segment Violation when using smtp
with tls
In-Reply-To: <1205234462.3.0.712730558489.issue2272@psf.upfronthosting.co.za>
Message-ID: <1205234462.3.0.712730558489.issue2272@psf.upfronthosting.co.za>
New submission from David Harel <hareldvd at gmail.com>:
Using Linux (Gentoo), when closing the socket of an smtp connection
using tls (you can use the example at:
http://snippets.dzone.com/posts/show/757).
Attached code example with my e-mail data. (I don't mind).
Also tested on Debian with Python 2.3.5 where everything seems OK.
----------
components: Library (Lib)
files: t2.py
messages: 63460
nosy: hareldvd
severity: normal
status: open
title: Segment Violation when using smtp with tls
type: crash
versions: Python 2.4
Added file: http://bugs.python.org/file9654/t2.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2272>
__________________________________
From report at bugs.python.org Tue Mar 11 17:46:15 2008
From: report at bugs.python.org (Jared Grubb)
Date: Tue, 11 Mar 2008 16:46:15 +0000
Subject: [New-bugs-announce] [issue2273] test_decimal: possible thread
lockup in test case
In-Reply-To: <1205253975.75.0.189662720786.issue2273@psf.upfronthosting.co.za>
Message-ID: <1205253975.75.0.189662720786.issue2273@psf.upfronthosting.co.za>
New submission from Jared Grubb <python at jaredgrubb.com>:
In Lib\test\test_decimal.py, attached is a bugfix for two bugs:
1) If the thfunc2 actually fails, then its thread will throw an
exception and never set the Events that thfunc1 is waiting for; thus,
thfunc1 never returns, causing the whole unittest to hang.
2) DecimalUseOfContextTest.test_threading should wait on both finish1
and finish2 (instead of waiting on finish1 twice).
----------
components: Library (Lib)
files: test_decimal.patch
keywords: patch
messages: 63463
nosy: jaredgrubb
severity: normal
status: open
title: test_decimal: possible thread lockup in test case
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file9656/test_decimal.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2273>
__________________________________
From report at bugs.python.org Tue Mar 11 22:00:34 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 11 Mar 2008 21:00:34 +0000
Subject: [New-bugs-announce] [issue2274] heapq API
In-Reply-To: <1205269233.64.0.52511417166.issue2274@psf.upfronthosting.co.za>
Message-ID: <1205269233.64.0.52511417166.issue2274@psf.upfronthosting.co.za>
New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:
The heapreplace() function has an irritating API. Since the replacement
is unconditional, it usually obligates the caller to examine the top of
the heap to see if it is smaller or larger than the candidate
replacement item. Typical calls look like this:
if item > heap[0]:
item = heapreplace(heap, item)
Instead of the current design "x=heappop(h); heappush(h, item); return
x", it would be better to have a function equivalent to
"heappush(h,item); return heappop(h)". The above fragment then
simplifies to:
item = heappushpop(heap, item)
I propose to add heappushpop() to Py2.6 and to remove heapreplace() from
Py3.0:
def heappushpop(heap, item):
"""Fast version of a heappush followed by a heappop."""
if item > heap[0]:
item, heap[0] = heap[0], item
_siftup(heap, 0)
return item
----------
components: Library (Lib)
messages: 63465
nosy: rhettinger
severity: normal
status: open
title: heapq API
type: feature request
versions: Python 2.5, Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2274>
__________________________________
From report at bugs.python.org Tue Mar 11 22:22:20 2008
From: report at bugs.python.org (Hans-Peter Jansen)
Date: Tue, 11 Mar 2008 21:22:20 +0000
Subject: [New-bugs-announce] [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
New submission from Hans-Peter Jansen <hpj at urpla.net>:
The urllib2 behavior related to headers is - hmm - improvable.
It simply capitalize() the key, which leads to funny results like:
Accept-charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
while this is seemingly conforming to the specs, it's simply different
to every other implementation of such things..
And we can do better. How about:
--- /usr/lib/python/urllib2.py 2008-01-10 19:03:55.000000000 +0100
+++ urllib2.py 2008-03-11 21:25:33.523890670 +0100
@@ -261,13 +261,16 @@ class Request:
def is_unverifiable(self):
return self.unverifiable
+ def _cap_header_key(self, key):
+ return '-'.join((ck.capitalize() for ck in key.split('-')))
+
def add_header(self, key, val):
# useful for something like authentication
- self.headers[key.capitalize()] = val
+ self.headers[self._cap_header_key(key)] = val
def add_unredirected_header(self, key, val):
# will not be added to a redirected request
- self.unredirected_hdrs[key.capitalize()] = val
+ self.unredirected_hdrs[self._cap_header_key(key)] = val
def has_header(self, header_name):
return (header_name in self.headers or
I'm not happy with the _cap_header_key name, but you get the idea.
The patch is optimized to operate with maximum locality. It's also
attached.
I would be very grateful, if something similar could be applied.
Opinions?
----------
components: Library (Lib)
files: urllib2-cap-headers.diff
keywords: patch
messages: 63466
nosy: frispete
severity: minor
status: open
title: urllib2 header capitalization
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9658/urllib2-cap-headers.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
__________________________________
From report at bugs.python.org Wed Mar 12 03:50:03 2008
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 12 Mar 2008 02:50:03 +0000
Subject: [New-bugs-announce] [issue2276] distutils out-of-date for
runtime_library_dirs flag on OS X
In-Reply-To: <1205290203.53.0.517851484238.issue2276@psf.upfronthosting.co.za>
Message-ID: <1205290203.53.0.517851484238.issue2276@psf.upfronthosting.co.za>
New submission from Bill Janssen <bill.janssen at gmail.com>:
The OS X linker now understands -R, but distutils continues to pass the
wrong flags back in
distutils.unixccompiler.runtime_library_dir_option(). I'm checking with
the Apple folks as to exactly what the right flag is.
----------
assignee: janssen
components: Distutils
keywords: easy
messages: 63469
nosy: janssen
priority: normal
severity: normal
status: open
title: distutils out-of-date for runtime_library_dirs flag on OS X
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2276>
__________________________________
From report at bugs.python.org Wed Mar 12 09:35:56 2008
From: report at bugs.python.org (thekorn)
Date: Wed, 12 Mar 2008 08:35:56 +0000
Subject: [New-bugs-announce] [issue2277] MozillaCookieJar does not support
Firefox3 cookie files
In-Reply-To: <1205310956.06.0.761612370729.issue2277@psf.upfronthosting.co.za>
Message-ID: <1205310956.06.0.761612370729.issue2277@psf.upfronthosting.co.za>
New submission from thekorn <thekorn at gmx.de>:
In Firefox 3 the cookies are stored in a sqlite database instead of a
txt-file. It would be nice if cookielib.MozillaCookieJar().load() could
support this.
Markus
----------
messages: 63470
nosy: thekorn
severity: normal
status: open
title: MozillaCookieJar does not support Firefox3 cookie files
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2277>
__________________________________
From report at bugs.python.org Wed Mar 12 12:04:03 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Wed, 12 Mar 2008 11:04:03 +0000
Subject: [New-bugs-announce] [issue2278] [Py30a3] xml.parsers.expat
recognizes encoding="utf-8" but not encoding="utf8"
In-Reply-To: <1205319843.23.0.2378782834.issue2278@psf.upfronthosting.co.za>
Message-ID: <1205319843.23.0.2378782834.issue2278@psf.upfronthosting.co.za>
New submission from Mark Summerfield <mark at qtrac.eu>:
Here is how to reproduce the bug:
from xml.etree.ElementTree import parse
import io
xml1 = """<?xml version="1.0" encoding="utf8"?>
<test>text</test>"""
xml2 = """<?xml version="1.0" encoding="utf-8"?>
<test>text</test>"""
f1 = io.StringIO(xml1)
f2 = io.StringIO(xml2)
tree2 = parse(f2) # this uses "utf-8" and works fine
tree1 = parse(f1)
Traceback (most recent call last):
File "<pyshell#20>", line 1, in <module>
tree1 = parse(f1)
File
"/home/mark/opt/python30a3/lib/python3.0/xml/etree/ElementTree.py", line
823, in parse
tree.parse(source, parser)
File
"/home/mark/opt/python30a3/lib/python3.0/xml/etree/ElementTree.py", line
561, in parse
parser.feed(data)
File
"/home/mark/opt/python30a3/lib/python3.0/xml/etree/ElementTree.py", line
1201, in feed
self._parser.Parse(data, 0)
xml.parsers.expat.ExpatError: unknown encoding: line 1, column 30
----------
messages: 63471
nosy: mark
severity: normal
status: open
title: [Py30a3] xml.parsers.expat recognizes encoding="utf-8" but not encoding="utf8"
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2278>
__________________________________
From report at bugs.python.org Wed Mar 12 15:53:32 2008
From: report at bugs.python.org (David Ripton)
Date: Wed, 12 Mar 2008 14:53:32 +0000
Subject: [New-bugs-announce] [issue2279] distutils sdist add_defaults does
not add data_files
In-Reply-To: <1205333612.66.0.693918609529.issue2279@psf.upfronthosting.co.za>
Message-ID: <1205333612.66.0.693918609529.issue2279@psf.upfronthosting.co.za>
New submission from David Ripton <d+python at ripton.net>:
distutils.sdist.add_defaults adds the Python modules and scripts and C
extensions found in setup.py to the MANIFEST. It does *not* add
data_files mentioned in setup.py to the MANIFEST.
This is non-orthogonal and confusing, because it means that a
MANIFEST.in is required if you have data_files, optional if you do not.
If you have data_files and do not have MANIFEST.in, you get a broken
package but no error.
----------
components: Distutils
messages: 63475
nosy: dripton
severity: normal
status: open
title: distutils sdist add_defaults does not add data_files
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2279>
__________________________________
From report at bugs.python.org Wed Mar 12 19:33:05 2008
From: report at bugs.python.org (David Binger)
Date: Wed, 12 Mar 2008 18:33:05 +0000
Subject: [New-bugs-announce] [issue2280] parser module chokes on unusual
characters
In-Reply-To: <1205346785.26.0.563823122087.issue2280@psf.upfronthosting.co.za>
Message-ID: <1205346785.26.0.563823122087.issue2280@psf.upfronthosting.co.za>
New submission from David Binger <davidbinger at mac.com>:
This is with the current revision of py3k: 61353.
parser.suite('"\u1234"') fails with a TypeError.
Changing the argument format from "s" to "s#" works around this problem.
I added a unit test for this. After fixing the "s#", another
bug is exposed by the same test: a string literal containing
\u1234 is mangled by sequence2st().
The last section of the patch seems to correct the second bug.
(I think getarg.c's handling of "s" has a problem
handling a unicode string containing a character whose
encoding is not 1 byte. It has a test for null bytes
at the end that does not work correctly.)
----------
components: Library (Lib)
files: parsermodule.patch
keywords: patch
messages: 63482
nosy: dbinger
severity: normal
status: open
title: parser module chokes on unusual characters
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file9662/parsermodule.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2280>
__________________________________
From report at bugs.python.org Wed Mar 12 22:56:48 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Wed, 12 Mar 2008 21:56:48 +0000
Subject: [New-bugs-announce] [issue2281] Enhanced cPython profiler with
high-resolution timer
In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za>
Message-ID: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za>
New submission from Jean Brouwers <MrJean1 at Gmail.com>:
Attached is a modified version of the cPython profiler file
Modules/_lsprof.c using a high-resolution timer where available.
The enhancement has been tested on 32- and 64-bit Linux (x86 and x86_64)
and on 32-bit MacOS X Tiger (Intel) and Panther (PPC).
No other platforms have been tested but as before the profiler will
fallback to using gettimeofday() on non-Windows version, except the 64-
bit PPC build will issue a compile-time warning.
----------
files: hires_lsprof.tgz
messages: 63486
nosy: MrJean1
severity: normal
status: open
title: Enhanced cPython profiler with high-resolution timer
Added file: http://bugs.python.org/file9665/hires_lsprof.tgz
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2281>
__________________________________
From report at bugs.python.org Thu Mar 13 05:32:31 2008
From: report at bugs.python.org (zhen)
Date: Thu, 13 Mar 2008 04:32:31 +0000
Subject: [New-bugs-announce] [issue2282] TextIOWrapper.seekable() always
returns False
In-Reply-To: <1205382751.6.0.0963204550732.issue2282@psf.upfronthosting.co.za>
Message-ID: <1205382751.6.0.0963204550732.issue2282@psf.upfronthosting.co.za>
New submission from zhen <netzhen at gmail.com>:
The seekable() method of TextIOWrapper always returns False, for it
does't override the seekable method of IOBase class in which just
returns False. But, there is a method named _seekable(self) in
TextIOWrapper(in io.py line 1211):
def _seekable(self):
return self._seekable
which should be seekable(self), and _seekable method is overwrited by
line 1190 in the __init__ method as a bool object:
self._seekable = self._telling = self.buffer.seekable()
----------
components: Library (Lib)
messages: 63494
nosy: netzhen
severity: normal
status: open
title: TextIOWrapper.seekable() always returns False
type: feature request
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2282>
__________________________________
From report at bugs.python.org Thu Mar 13 09:14:47 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 13 Mar 2008 08:14:47 +0000
Subject: [New-bugs-announce] [issue2283] lambda *a, **k: a, k # does not work
In-Reply-To: <1205396087.42.0.232121283205.issue2283@psf.upfronthosting.co.za>
Message-ID: <1205396087.42.0.232121283205.issue2283@psf.upfronthosting.co.za>
New submission from Mark Summerfield <mark at qtrac.eu>:
According to the docs lambda can handle the same parameter list as can
def. But this does not appear to be the case as the following (both
2.5.1 and 30a3) shows:
>>> def f(*a, **kw): return a, kw
>>> f(1,2,a=3,b=4)
((1, 2), {'a': 3, 'b': 4})
>>> A = lambda *a: a
>>> A(1,2)
(1, 2)
>>> K = lambda **k: k
>>> K(a=1,b=2)
{'a': 1, 'b': 2}
>>> X = lambda *a, **k: a, k
Traceback (most recent call last):
File "<pyshell#17>", line 1, in <module>
X = lambda *a, **k: a, k
NameError: name 'k' is not defined
So either this is an interpreter bug, or a doc bug.
----------
components: Interpreter Core
messages: 63499
nosy: mark
severity: normal
status: open
title: lambda *a, **k: a, k # does not work
versions: Python 2.5, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2283>
__________________________________
From report at bugs.python.org Fri Mar 14 04:45:58 2008
From: report at bugs.python.org (Trent Nelson)
Date: Fri, 14 Mar 2008 03:45:58 +0000
Subject: [New-bugs-announce] [issue2284] [PATCH] -x64 option added to
pcbuild/rt.bat to facilitate testing of amd64\python[_d].exe.
In-Reply-To: <1205466358.32.0.414062205186.issue2284@psf.upfronthosting.co.za>
Message-ID: <1205466358.32.0.414062205186.issue2284@psf.upfronthosting.co.za>
New submission from Trent Nelson <tnelson at onresolve.com>:
Looks like there's been a recent change to trunk such that x64 Windows
builds now get placed in pcbuild\amd64 instead of just pcbuild (thanks
to whoever added it). The attached patch against rt.bat allows it to
be called with an -x64 arg, which invokes the 64-bit Python build,
instead of the 32-bit one.
(tools/buildbot/test-amd64.bat should eventually be created to call
this as well, once we've ironed out all the Windows x64 issues.)
----------
components: Build
files: rt.bat.patch
keywords: patch
messages: 63520
nosy: Trent.Nelson
severity: normal
status: open
title: [PATCH] -x64 option added to pcbuild/rt.bat to facilitate testing of amd64\python[_d].exe.
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file9670/rt.bat.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2284>
__________________________________
From report at bugs.python.org Fri Mar 14 12:11:58 2008
From: report at bugs.python.org (David Binger)
Date: Fri, 14 Mar 2008 11:11:58 +0000
Subject: [New-bugs-announce] [issue2285] list.sort.__doc__ says "cmp" is a
keyword, but it isn't.
In-Reply-To: <1205493118.81.0.272184135771.issue2285@psf.upfronthosting.co.za>
Message-ID: <1205493118.81.0.272184135771.issue2285@psf.upfronthosting.co.za>
New submission from David Binger <davidbinger at mac.com>:
(at revision 61376)
It looks like this docstring needs to be updated.
----------
assignee: georg.brandl
components: Documentation
messages: 63521
nosy: dbinger, georg.brandl
severity: minor
status: open
title: list.sort.__doc__ says "cmp" is a keyword, but it isn't.
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2285>
__________________________________
From report at bugs.python.org Fri Mar 14 13:57:55 2008
From: report at bugs.python.org (Trent Nelson)
Date: Fri, 14 Mar 2008 12:57:55 +0000
Subject: [New-bugs-announce] [issue2286] Stack overflow exception caused by
test_marshal on Windows x64
In-Reply-To: <1205499475.78.0.0465561571315.issue2286@psf.upfronthosting.co.za>
Message-ID: <1205499475.78.0.0465561571315.issue2286@psf.upfronthosting.co.za>
New submission from Trent Nelson <tnelson at onresolve.com>:
S:\src\svn\svn.python.org\projects\python\trunk.x64\PCbuild>amd64\python_d
..\lib\test\test_marshal.py
test_bool (__main__.IntTestCase) ... ok
test_int64 (__main__.IntTestCase) ... ok
test_ints (__main__.IntTestCase) ... ok
test_floats (__main__.FloatTestCase) ... ok
test_buffer (__main__.StringTestCase) ... ok
test_string (__main__.StringTestCase) ... ok
test_unicode (__main__.StringTestCase) ... ok
test_code (__main__.CodeTestCase) ... ok
test_dict (__main__.ContainerTestCase) ... ok
test_list (__main__.ContainerTestCase) ... ok
test_sets (__main__.ContainerTestCase) ... ok
test_tuple (__main__.ContainerTestCase) ... ok
test_exceptions (__main__.ExceptionTestCase) ... ok
test_bug_5888452 (__main__.BugsTestCase) ... ok
test_exact_type_match (__main__.BugsTestCase) ... ok
test_fuzz (__main__.BugsTestCase) ... ok
test_loads_recursion (__main__.BugsTestCase) ...
^^^
python_d.exe crashes at this point with a stack overflow. Just
capturing the issue for now. Will investigate shortly and hopefully
provide a patch.
----------
components: Tests
messages: 63523
nosy: Trent.Nelson
severity: normal
status: open
title: Stack overflow exception caused by test_marshal on Windows x64
type: crash
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2286>
__________________________________
From report at bugs.python.org Fri Mar 14 14:57:07 2008
From: report at bugs.python.org (panhudie)
Date: Fri, 14 Mar 2008 13:57:07 +0000
Subject: [New-bugs-announce] [issue2287] Problems using logging module with
logging.basicConfig(level=logging.NOTSET)
In-Reply-To: <1205503027.6.0.969200887551.issue2287@psf.upfronthosting.co.za>
Message-ID: <1205503027.6.0.969200887551.issue2287@psf.upfronthosting.co.za>
New submission from panhudie <panhudie at gmail.com>:
The problem is in the logging.basicConfig(**kwargs):
<...>
level = kwargs.get("level")
if level:
root.setLevel(level)
So you can not set the level like this, this logger will log WARNING(and
above) instead of all the level:
logging.basicConfig(level=logging.NOTSET)
#logging.NOTSET == 0, root default level is WARNING
I have seen this problem was fixed in the trunk, but not in python25 branch:
level = kwargs.get("level")
if level is not None:
root.setLevel(level)
----------
components: Library (Lib)
messages: 63527
nosy: panhudie
severity: minor
status: open
title: Problems using logging module with logging.basicConfig(level=logging.NOTSET)
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2287>
__________________________________
From report at bugs.python.org Fri Mar 14 16:47:47 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 14 Mar 2008 15:47:47 +0000
Subject: [New-bugs-announce] [issue2288] Confusing documentation for
urllip.urlopen
In-Reply-To: <1205509667.67.0.822182010256.issue2288@psf.upfronthosting.co.za>
Message-ID: <1205509667.67.0.822182010256.issue2288@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
Grant Edwards pointed out in a comp.lang.python posting that the
documentation for urlopen in the urllib module appears to be self-
contradictory: at http://docs.python.org/dev/library/urllib.html
in the third-to-last paragraph for the urllib function, it says:
"Alternatively, the optional proxies argument may be used to explicitly
specify proxies..."
and goes on to give examples. Then the second-to-last paragraph seems
to directly contradict this:
"The urlopen() function does not support explicit proxy specification.
If you need to override environmental proxy settings, use URLopener, or
a subclass such as FancyURLopener."
I suspect that this second paragraph should just be deleted in its
entirety.
----------
assignee: georg.brandl
components: Documentation
messages: 63529
nosy: georg.brandl, marketdickinson
severity: normal
status: open
title: Confusing documentation for urllip.urlopen
versions: Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2288>
__________________________________
From report at bugs.python.org Fri Mar 14 19:43:45 2008
From: report at bugs.python.org (John Love-Jensen)
Date: Fri, 14 Mar 2008 18:43:45 +0000
Subject: [New-bugs-announce] [issue2289] os.path.normpath over-normalizes
In-Reply-To: <1205520225.21.0.16693669718.issue2289@psf.upfronthosting.co.za>
Message-ID: <1205520225.21.0.16693669718.issue2289@psf.upfronthosting.co.za>
New submission from John Love-Jensen <eljay at adobe.com>:
I found a bug (or at least a shortcoming) in Python's os.path.normpath routine.
It overly normalizes, at least for Unix and Unix-like systems (including Mac), and
Windows.
Example:
x = os.path.join(".", "dog", "..", "cupcake.txt")
print x
x = os.path.normpath(x)
print x
If say "dog" is a symlink (any flavor of Unix (including OS X), or Win), there is a
difference between ./dog/../cupcake.txt and ./cupcake.txt.
In the OS, if dog is a symlink to fire/fly, the .. resolves relative to fire/fly.
It should be safe to normalize this:
././././././././cupcake.txt --> ./cupcake.txt
It should be safe to normalize this:
.////////////////cupcake.txt --> ./cupcake.txt
But this is not safe to normalize:
./x/../x/../x/../cupcake.txt --> ./cupcake.txt
For example, if the directories look like this:
./cupcake.txt
./over/yonder/back/cupcake.txt
./x --> over/there
./over/there
./over/x --> yonder/aways
./over/yonder/aways
./over/yonder/x --> back/again
./over/yonder/back/again
./cupcake.txt refers to first cupcake.
./x/../x/../x/../cupcake.txt refers to the second cupcake.
The os.path.realpath does the resolve, but sometimes the path-in-hand is for some
arbitrary path, and not necessarily one on the local system, or if on the local
files system may be relative based off from a different cwd.
----------
messages: 63533
nosy: eljay451
severity: minor
status: open
title: os.path.normpath over-normalizes
type: behavior
versions: Python 2.4
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2289>
__________________________________
From report at bugs.python.org Fri Mar 14 23:12:27 2008
From: report at bugs.python.org (Trent Nelson)
Date: Fri, 14 Mar 2008 22:12:27 +0000
Subject: [New-bugs-announce] [issue2290] [PATCH] Update
Lib/distutils/sysconfig.py to handle x64 Windows builds
living in pcbuild/amd64.
In-Reply-To: <1205532747.41.0.216781617297.issue2290@psf.upfronthosting.co.za>
Message-ID: <1205532747.41.0.216781617297.issue2290@psf.upfronthosting.co.za>
New submission from Trent Nelson <tnelson at onresolve.com>:
This patch is required in order to support x64 Windows builds that live
in pcbuild/amd64. Without it, sysutils._python_build() returns the
wrong directory, which causes the test_get_config_h_filename method in
Lib/distutils/tests/test_sysconfig.py to fail.
----------
components: Library (Lib)
files: sysconfig.py.patch
keywords: patch
messages: 63537
nosy: Trent.Nelson
severity: normal
status: open
title: [PATCH] Update Lib/distutils/sysconfig.py to handle x64 Windows builds living in pcbuild/amd64.
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9671/sysconfig.py.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2290>
__________________________________
From report at bugs.python.org Fri Mar 14 23:19:15 2008
From: report at bugs.python.org (Igor)
Date: Fri, 14 Mar 2008 22:19:15 +0000
Subject: [New-bugs-announce] [issue2291] Catching all exceptions with
'object'
In-Reply-To: <1205533155.39.0.576388305845.issue2291@psf.upfronthosting.co.za>
Message-ID: <1205533155.39.0.576388305845.issue2291@psf.upfronthosting.co.za>
New submission from Igor <zotbar1234 at hotmail.com>:
I have discovered the following behaviour in 2.5, which I cannot explain:
>>> try:
... raise ValueError("foo")
... except object:
... print "aiee!"
...
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
ValueError: foo
>>> sys.version
'2.5.1 (r251:54863, Jan 23 2008, 16:53:41) \n[GCC 4.2.2 (Gentoo 4.2.2
p1.0)]'
>>> isinstance(ValueError("foo"), object)
True
At first I thought I misunderstood something about exceptions, but the
wording of the try-statement leads me to believe that this should work.
ValueError is a subclass of object and thus, I think, should be a match,
thus catching the exception.
I realize that all exceptions should inherit from Exception
(BaseException?), but for the sake of consistence, shouldn't "except
object" catch *anything* in python 2.5? I.e. be the equivalent of "except:".
Is this a bug? If so, should this be fixed?
----------
components: None
messages: 63538
nosy: zotbar1234
severity: normal
status: open
title: Catching all exceptions with 'object'
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2291>
__________________________________
From report at bugs.python.org Sat Mar 15 16:41:20 2008
From: report at bugs.python.org (Thomas Wouters)
Date: Sat, 15 Mar 2008 15:41:20 +0000
Subject: [New-bugs-announce] [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
New submission from Thomas Wouters <thomas at python.org>:
The attached patch adds the missing *-unpacking generalizations.
Specifically:
>>> a, b, *c = range(5)
>>> *a, b, c = a, b, *c
>>> a, b, c
([0, 1, 2], 3, 4)
>>> [ *a, b, c ]
[0, 1, 2, 3, 4]
>>> L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ]
>>> [ *item for item in L ]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
Also, yielding everything from an iterator:
>>> def flatten(iterables):
... for it in iterables:
... yield *it
...
>>> L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ]
>>> flatten(L)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
----------
assignee: gvanrossum
components: Interpreter Core
files: morestar.diff
keywords: patch, patch
messages: 63548
nosy: gvanrossum, twouters
severity: normal
status: open
title: Missing *-unpacking generalizations
versions: Python 3.0
Added file: http://bugs.python.org/file9673/morestar.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2292>
__________________________________
From report at bugs.python.org Sat Mar 15 17:41:09 2008
From: report at bugs.python.org (BODIN)
Date: Sat, 15 Mar 2008 16:41:09 +0000
Subject: [New-bugs-announce] [issue2293] Missing case / switch / evaluate
In-Reply-To: <1205599269.05.0.609261957531.issue2293@psf.upfronthosting.co.za>
Message-ID: <1205599269.05.0.609261957531.issue2293@psf.upfronthosting.co.za>
New submission from BODIN <didierbodin at neuf.fr>:
I am not the code :
if toto == 1:
...
elsif toto == 2:
...
elsif
In ADA for example :
case C is -- 4 Start a case
statement
when Red => Result := 1;
when Blue =>Result := 2;
when Black .. Brown => Result := 3;
when Orange | Indigo => Result := 4;
when others => Result := 5;required for unspecified cases.
end case;
Is it not better?
----------
components: Interpreter Core
messages: 63555
nosy: dbodin
severity: normal
status: open
title: Missing case / switch / evaluate
versions: 3rd party
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2293>
__________________________________
From report at bugs.python.org Sat Mar 15 19:58:35 2008
From: report at bugs.python.org (Greg Kochanski)
Date: Sat, 15 Mar 2008 18:58:35 +0000
Subject: [New-bugs-announce] [issue2294] Bug in Pickle protocol involving
__setstate__
In-Reply-To: <1205607515.59.0.862171292483.issue2294@psf.upfronthosting.co.za>
Message-ID: <1205607515.59.0.862171292483.issue2294@psf.upfronthosting.co.za>
New submission from Greg Kochanski <gpk at users.sourceforge.net>:
If we have a hierarchy of classes, and we use
__getstate__/__setstate__, the wrong class'
__setstate__ gets called.
Possibly, this is a documentation problem, but here goes:
Take two classes, A and B, where B is the child of A.
Construct a B. Pickle it. Unpickle it, and you find
that the __setstate__ function for A is called with the result
produced by B.__getstate__().
This is wrong.
An example follows:
import pickle as P
class A(object):
def __init__(self, a):
print 'A.__init__'
self.a = a
def __getstate__(self):
print 'A.__getstate'
return self.a
def __setstate__(self, upstate):
print 'A.__setstate', upstate
self.a = upstate
class B(A):
def __init__(self, a, b):
print 'B.__init__'
A.__init__(self, a)
self.b = b
def __getstate__(self):
print 'B.__getstate'
return (A.__getstate__(self), self.b)
def __setstate(self, upstate):
# This never gets called!
print 'B.__setstate', upstate
A.__setstate__(self, upstate[0])
self.b = upstate[1]
def __repr__(self):
return '<B a=%d b=%d>' % (self.a, self.b)
q = B(1,2)
print '---'
r = P.loads(P.dumps(q, 0))
print 'q=', q
print 'r=', r
Now, run it:
$ python foo.py
B.__init__
A.__init__
---
B.__getstate
A.__getstate
A.__setstate (1, 2)
q= <B a=1 b=2, h=46912504218064>
r= Traceback (most recent call last):
File "foo.py", line 44, in <module>
print 'r=', r
File "foo.py", line 37, in __repr__
return '<B a=%d b=%d>' % (self.a, self.b)
AttributeError: 'B' object has no attribute 'b'
$
Note that this problem doesn't get noticed in the
common case where you simply pass __dict__ around
from __getstate__ to __setstate__. However, it
exists in many other use cases.
----------
components: Library (Lib)
messages: 63559
nosy: gpk
severity: normal
status: open
title: Bug in Pickle protocol involving __setstate__
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2294>
__________________________________
From report at bugs.python.org Sat Mar 15 20:18:46 2008
From: report at bugs.python.org (Greg Kochanski)
Date: Sat, 15 Mar 2008 19:18:46 +0000
Subject: [New-bugs-announce] [issue2295] cPickle corner case - docs or bug?
In-Reply-To: <1205608726.73.0.310899298914.issue2295@psf.upfronthosting.co.za>
Message-ID: <1205608726.73.0.310899298914.issue2295@psf.upfronthosting.co.za>
New submission from Greg Kochanski <gpk at users.sourceforge.net>:
If you attempt to cPickle a class, cPickle checks
that it can get the identical class by importing it.
If that check fails, it reports:
Traceback (most recent call last):
...
"/usr/local/lib/python2.5/site-packages/newstem2-0.12.3-py2.5-linux-i686.egg/newstem2/stepperclient.py",
line 41, in send
s = cPickle.dumps( args, cPickle.HIGHEST_PROTOCOL)
cPickle.PicklingError: Can't pickle <class 'test_simple2.aModel'>: it's
not the same object as test_simple2.aModel
$
Normally, this is probably a good thing. However, if you do
an import using the "imp" module, via
imp.load_module(name, fd, pn, desc), you get the "same" module
containing the "same" classes, but everything is duplicated at
different addresses. In other words, you get distinct class
objects from what cPickle
will find. Consequently, the when cPickle makes the
"is" comparison between what you gave it and what it can find,
it will fail and cause an error.
In this case, the error is wrong. I know that the aModel classes
come from the same file and are member-for-member the same.
This may well be a documentation
error: it needs to mention this test and note that classes in modules
imported
via imp are not picklable. Or, imp needs to note that its results
are not picklable. Or both.
Or, maybe it's something that should be fixed, though I'm not
sure if there is a general solution that will always behave
well.
----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 63560
nosy: georg.brandl, gpk
severity: normal
status: open
title: cPickle corner case - docs or bug?
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2295>
__________________________________
From report at bugs.python.org Sat Mar 15 23:35:33 2008
From: report at bugs.python.org (Trent Nelson)
Date: Sat, 15 Mar 2008 22:35:33 +0000
Subject: [New-bugs-announce] [issue2296] [PATCH] Tcl/Tk 8.4.16 patches
needed to get an x64 Windows build
In-Reply-To: <1205620533.13.0.0700129427319.issue2296@psf.upfronthosting.co.za>
Message-ID: <1205620533.13.0.0700129427319.issue2296@psf.upfronthosting.co.za>
New submission from Trent Nelson <tnelson at onresolve.com>:
Martin, I've attached two patches required in order to get Tcl/Tk 8.4.16
to successfully compile on Windows x64. I haven't included the patch to
external-amd64.bat (and pcbuild/readme.txt with updated build
instructions) yet as I wanted to confirm how you apply updates to the
external/ branch such that the buildbots can pick it up as well.
Note that I also dropped a generic standalone sed.exe into
tk-8.4.16/win, which is required for reasons that I couldn't be bothered
digging into in makefile.vc. You can grab it from
http://svn.onresolve.com/external/tags/tcl-8.4.18.1/win/sed.exe.
Also, wanted to query the role of 'COMPILERFLAGS=-DWINVER=0x0500' in
your recommended nmake flags; do we still need it? I used the following
for x64 debug builds:
..\tcl8.4.16\win>nmake -f makefile.vc DEBUG=1 MACHINE=AMD64
INSTALLDIR=../../tcltk64 clean all install
And for tk:
..\tk8.4.16\win>nmake -f makefile.vc DEBUG=1 MACHINE=AMD64
TCLDIR=../../tcl8.4.16 INSTALLDIR=../../tcltk64 clean all install
Let me know how you want to deal with the tcl/tk patches and then we can
look at fixing external-amd64.bat and updating pcbuild/readme.txt.
----------
components: Tkinter
files: tk-8.4.16.patch
keywords: patch
messages: 63566
nosy: Trent.Nelson, loewis
severity: normal
status: open
title: [PATCH] Tcl/Tk 8.4.16 patches needed to get an x64 Windows build
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9676/tk-8.4.16.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2296>
__________________________________
From report at bugs.python.org Sun Mar 16 06:24:46 2008
From: report at bugs.python.org (Douglas Greiman)
Date: Sun, 16 Mar 2008 05:24:46 +0000
Subject: [New-bugs-announce] [issue2297] Patch for fatal stack overflow in
Windows caused by -v
In-Reply-To: <1205645085.91.0.398085675156.issue2297@psf.upfronthosting.co.za>
Message-ID: <1205645085.91.0.398085675156.issue2297@psf.upfronthosting.co.za>
New submission from Douglas Greiman <dgreiman at users.sourceforge.net>:
When python is invoked with -v or -vv under Windows, the process of
importing the codec for sys.stderr causes a message to be written to
stderr, which in turn causes the codec to be recursively imported.
Sometimes the stack overflow exception is swallowed, other times it is
not. The bug depends on the particular locale settings of the Windows
machine.
To reproduce: python_d.exe -v
and look for many repeated imports of encodings.<some codec>
Patch is attached.
----------
components: Interpreter Core
files: py3k-win-codec-recursion-20080315.diff
keywords: patch
messages: 63570
nosy: dgreiman
severity: normal
status: open
title: Patch for fatal stack overflow in Windows caused by -v
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file9678/py3k-win-codec-recursion-20080315.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2297>
__________________________________
From report at bugs.python.org Sun Mar 16 07:00:40 2008
From: report at bugs.python.org (Douglas Greiman)
Date: Sun, 16 Mar 2008 06:00:40 +0000
Subject: [New-bugs-announce] [issue2298] Patch for "string without null
bytes" check in getargs.c
In-Reply-To: <1205647240.0.0.304059938651.issue2298@psf.upfronthosting.co.za>
Message-ID: <1205647240.0.0.304059938651.issue2298@psf.upfronthosting.co.za>
New submission from Douglas Greiman <dgreiman at users.sourceforge.net>:
Code in getargs.c:convertsimple incorrectly uses PyUnicode_GetSize
instead of PyString_GET_SIZE when checking whether a bytes object
(encoded string) contains a null byte.
To reproduce: __import__('\u0080')
Incorrect behavior:
TypeError: __import__() argument 1 must be string without null bytes,
not str
Correct behavior:
ImportError
Note the lack of null bytes:
>>> '\u0080'.encode('utf-8')
b'\xc2\x80'
----------
components: Interpreter Core
files: py3k-getargs-null-bytes-20080315.diff
keywords: patch
messages: 63571
nosy: dgreiman
severity: normal
status: open
title: Patch for "string without null bytes" check in getargs.c
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file9679/py3k-getargs-null-bytes-20080315.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2298>
__________________________________
From report at bugs.python.org Sun Mar 16 07:11:08 2008
From: report at bugs.python.org (Douglas Greiman)
Date: Sun, 16 Mar 2008 06:11:08 +0000
Subject: [New-bugs-announce] [issue2299] Minor typos in newtypes.rst
In-Reply-To: <1205647868.72.0.36374739864.issue2299@psf.upfronthosting.co.za>
Message-ID: <1205647868.72.0.36374739864.issue2299@psf.upfronthosting.co.za>
New submission from Douglas Greiman <dgreiman at users.sourceforge.net>:
Fix three minor typos in Doc/extending/newtypes.rst
----------
assignee: georg.brandl
components: Documentation
files: Doc-newtypes-typos-20080315.diff
keywords: patch
messages: 63572
nosy: dgreiman, georg.brandl
severity: minor
status: open
title: Minor typos in newtypes.rst
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9680/Doc-newtypes-typos-20080315.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2299>
__________________________________
From report at bugs.python.org Sun Mar 16 13:33:58 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 16 Mar 2008 12:33:58 +0000
Subject: [New-bugs-announce] [issue2300] make html fails
In-Reply-To: <1205670838.75.0.758086838639.issue2300@psf.upfronthosting.co.za>
Message-ID: <1205670838.75.0.758086838639.issue2300@psf.upfronthosting.co.za>
New submission from Christian Heimes <lists at cheimes.de>:
File "/home/heimes/dev/python/trunk/Doc/tools/sphinx/builder.py", line
236, in write
self.prepare_writing(docnames)
File "/home/heimes/dev/python/trunk/Doc/tools/sphinx/builder.py", line
301, in prepare_writing
self.load_indexer(docnames)
File "/home/heimes/dev/python/trunk/Doc/tools/sphinx/builder.py", line
489, in load_indexer
self.indexer.load(f, 'json')
File "/home/heimes/dev/python/trunk/Doc/tools/sphinx/search.py", line
70, in load
for (k, v) in frozen[2].iteritems())
AttributeError: 'list' object has no attribute 'iteritems'
make: *** [build] Fehler 1
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 63574
nosy: georg.brandl, tiran
priority: high
severity: normal
status: open
title: make html fails
type: crash
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2300>
__________________________________
From report at bugs.python.org Sun Mar 16 14:37:33 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 16 Mar 2008 13:37:33 +0000
Subject: [New-bugs-announce] [issue2301] [Py3k]
In-Reply-To: <1205674653.18.0.28557522559.issue2301@psf.upfronthosting.co.za>
Message-ID: <1205674653.18.0.28557522559.issue2301@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:
Following code
# coding: utf-8
print "?"
outputs
C:\Documents and Settings\WhiteRabbit>py3k b.py
File "b.py", line 3
print "?"
as expected, but following code
# coding: cp932
print "?"
outputs
C:\Documents and Settings\WhiteRabbit>py3k a.py
File "a.py", line 4
[22605 refs]
Probably this happens because PyUnicode_DecodeUTF8 at
Python/pythonrun.c(1757) assumes err->text to be UTF8, but this is not
true when source file is not encoded with UTF8.
# Sorry there is no patch.
----------
components: None
messages: 63576
nosy: ocean-city
severity: normal
status: open
title: [Py3k]
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2301>
__________________________________
From report at bugs.python.org Sun Mar 16 16:15:57 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sun, 16 Mar 2008 15:15:57 +0000
Subject: [New-bugs-announce] [issue2302] Uses of
SocketServer.BaseServer.shutdown have a race
In-Reply-To: <1205680557.19.0.19509352533.issue2302@psf.upfronthosting.co.za>
Message-ID: <1205680557.19.0.19509352533.issue2302@psf.upfronthosting.co.za>
New submission from Jeffrey Yasskin <jyasskin at gmail.com>:
With the code as it stands, calls to shutdown that happen before
serve_forever enters its loop will deadlock, and there's no simple way
for the user to avoid this. The attached patch prevents the deadlock and
allows multiple serve_forever..shutdown cycles, but it's pretty
complicated. I could make it a lot simpler by making shutdown permanent:
any later serve_forever calls would return immediately.
A third choice would be to add a .serve_in_thread function that returns
a token that can be used to shut down exactly that loop, instead of
putting .shutdown() on the server. Any opinions?
----------
components: Library (Lib)
files: race_free_shutdown.patch
keywords: patch, patch
messages: 63579
nosy: jyasskin
severity: normal
status: open
title: Uses of SocketServer.BaseServer.shutdown have a race
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9681/race_free_shutdown.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2302>
__________________________________
From report at bugs.python.org Sun Mar 16 16:45:42 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sun, 16 Mar 2008 15:45:42 +0000
Subject: [New-bugs-announce] [issue2303] isinstance is 4x as slow as in 2.5
because the common case raises
In-Reply-To: <1205682342.69.0.872031501346.issue2303@psf.upfronthosting.co.za>
Message-ID: <1205682342.69.0.872031501346.issue2303@psf.upfronthosting.co.za>
New submission from Jeffrey Yasskin <jyasskin at gmail.com>:
r58099 added an exception to the common case of PyObject_IsInstance(),
when the class has no __instancecheck__ attribute. This makes
isinstance(3, int) take 4x as long as in python 2.5.
----------
assignee: gvanrossum
components: Interpreter Core
messages: 63580
nosy: gvanrossum, jyasskin
severity: normal
status: open
title: isinstance is 4x as slow as in 2.5 because the common case raises
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2303>
__________________________________
From report at bugs.python.org Sun Mar 16 17:32:19 2008
From: report at bugs.python.org (Tim Golden)
Date: Sun, 16 Mar 2008 16:32:19 +0000
Subject: [New-bugs-announce] [issue2304] subprocess under windows fails to
quote properly under Windows when shell=True
In-Reply-To: <1205685138.96.0.183811169845.issue2304@psf.upfronthosting.co.za>
Message-ID: <1205685138.96.0.183811169845.issue2304@psf.upfronthosting.co.za>
New submission from Tim Golden <mail at timgolden.me.uk>:
The subprocess.Popen function reorganises the command line for process
creation when shell=True is passed in under Windows. It runs the
existing executable & arguments as arguments to %COMSPEC% /c. However
this fails when a second parameter (typically a filename) has an
embedded space. The patch attached adds extra parameters in this case
and adds appropriate unit tests.
Frankly I'm new to unittests and I more-or-less cloned an existing one
to make this work. Happy to be corrected if there's things done wrong &c.
----------
components: Library (Lib)
files: subprocess-r61420.patch
keywords: patch
messages: 63583
nosy: tim.golden
severity: normal
status: open
title: subprocess under windows fails to quote properly under Windows when shell=True
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9682/subprocess-r61420.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2304>
__________________________________
From report at bugs.python.org Sun Mar 16 22:06:10 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 21:06:10 +0000
Subject: [New-bugs-announce] [issue2305] Update What's new in 2.6
In-Reply-To: <1205701570.77.0.602719062541.issue2305@psf.upfronthosting.co.za>
Message-ID: <1205701570.77.0.602719062541.issue2305@psf.upfronthosting.co.za>
New submission from Guido van Rossum <guido at python.org>:
Somebody will have to write the "What's new in 2.6" document. I'm doing
3.0 but I'm not doing 2.6 as well.
----------
assignee: georg.brandl
components: Documentation
messages: 63591
nosy: georg.brandl, gvanrossum
severity: normal
status: open
title: Update What's new in 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2305>
__________________________________
From report at bugs.python.org Sun Mar 16 22:06:43 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 21:06:43 +0000
Subject: [New-bugs-announce] [issue2306] Update What's new in 3.0
In-Reply-To: <1205701603.67.0.309619584416.issue2306@psf.upfronthosting.co.za>
Message-ID: <1205701603.67.0.309619584416.issue2306@psf.upfronthosting.co.za>
New submission from Guido van Rossum <guido at python.org>:
I will be working on this.
----------
assignee: gvanrossum
components: Documentation
messages: 63592
nosy: gvanrossum
priority: high
severity: normal
status: open
title: Update What's new in 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2306>
__________________________________
From report at bugs.python.org Sun Mar 16 22:16:02 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 21:16:02 +0000
Subject: [New-bugs-announce] [issue2307] Decide what to do with bytes/str
when transferring pickles between 2.6 and 3.0
In-Reply-To: <1205702162.93.0.846570819567.issue2307@psf.upfronthosting.co.za>
Message-ID: <1205702162.93.0.846570819567.issue2307@psf.upfronthosting.co.za>
New submission from Guido van Rossum <guido at python.org>:
A pickled str instance written by 2.6 currently unpickles under 3.0 as a
bytes instance. That would be correct if the intended use is binary
data, but it's wrong if the intended use is text. My hunch is that
there's more pickled text than binary data. (E.g. a dict containing
instance variables uses (8-bit) str instances for the keys; these *must*
be unpacked as (Unicode) str instances in 3.0.)
The inverse issue also exists.
We need to DECIDE this before starting to code (coding is probably
minimal). I'm assigning the task to DECIDE (after discussion on the
list) to myself.
----------
assignee: gvanrossum
components: Library (Lib)
messages: 63593
nosy: gvanrossum
priority: high
severity: normal
status: open
title: Decide what to do with bytes/str when transferring pickles between 2.6 and 3.0
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2307>
__________________________________
From report at bugs.python.org Sun Mar 16 22:19:31 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 21:19:31 +0000
Subject: [New-bugs-announce] [issue2308] Make structseq more like
collections.namedtuple
In-Reply-To: <1205702371.36.0.516999386883.issue2308@psf.upfronthosting.co.za>
Message-ID: <1205702371.36.0.516999386883.issue2308@psf.upfronthosting.co.za>
New submission from Guido van Rossum <guido at python.org>:
The built-in type structseq (used by e.g. os.stat() for the stat
structure and by the time module for a time tuple) resembles the new
namedtuple type added to the collections module in 2.6.
It would be nice if these had at least a common ABC if not a shared
implementation.
At the same time I think that in 3.0 we should remove the feature of
"hidden fields" which is used to have structs that behave like
fixed-size tuples even though they have a variable number of named
fields (the list of names varies per platform). We should deprecate the
use of tuple-unpacking for these (except for the first 6 fields of a
timetuple, perhaps).
----------
components: Interpreter Core, Library (Lib)
messages: 63594
nosy: gvanrossum
priority: high
severity: normal
status: open
title: Make structseq more like collections.namedtuple
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2308>
__________________________________
From report at bugs.python.org Sun Mar 16 22:22:45 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 21:22:45 +0000
Subject: [New-bugs-announce] [issue2309] Add xturtle to the standard library?
In-Reply-To: <1205702565.16.0.164147436209.issue2309@psf.upfronthosting.co.za>
Message-ID: <1205702565.16.0.164147436209.issue2309@psf.upfronthosting.co.za>
New submission from Guido van Rossum <guido at python.org>:
Georg Lingl has offered his xturtle for the standard library. Barring
showstopping problems with dependencies or code qualitiy I think this is
a good thing to add to 3.0 as a replacement for turtle, and to add to
2.6 while keeping the old turtle module.
----------
messages: 63595
nosy: gvanrossum
severity: normal
status: open
title: Add xturtle to the standard library?
type: feature request
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2309>
__________________________________
From report at bugs.python.org Sun Mar 16 22:25:58 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 21:25:58 +0000
Subject: [New-bugs-announce] [issue2310] Reorganize the 3.0 Misc/NEWS file
In-Reply-To: <1205702758.46.0.979295500245.issue2310@psf.upfronthosting.co.za>
Message-ID: <1205702758.46.0.979295500245.issue2310@psf.upfronthosting.co.za>
New submission from Guido van Rossum <guido at python.org>:
The 3.0 Misc/NEWS file is a mess. It is vastly incomplete because it
usually gets skipped during merges rather than resolving the conflicts.
----------
assignee: georg.brandl
components: Documentation
messages: 63597
nosy: georg.brandl, gvanrossum
severity: normal
status: open
title: Reorganize the 3.0 Misc/NEWS file
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2310>
__________________________________
From report at bugs.python.org Sun Mar 16 22:27:01 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 21:27:01 +0000
Subject: [New-bugs-announce] [issue2311] Update the ACKS file
In-Reply-To: <1205702821.59.0.0634295065395.issue2311@psf.upfronthosting.co.za>
Message-ID: <1205702821.59.0.0634295065395.issue2311@psf.upfronthosting.co.za>
New submission from Guido van Rossum <guido at python.org>:
We should keep the ACKS files up to date. Have all the GHOP contributors
been added?
----------
assignee: georg.brandl
components: Documentation
messages: 63598
nosy: georg.brandl, gvanrossum
priority: normal
severity: normal
status: open
title: Update the ACKS file
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2311>
__________________________________
From report at bugs.python.org Sun Mar 16 22:38:57 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 21:38:57 +0000
Subject: [New-bugs-announce] [issue2312] Update PEP 3135 (super())
In-Reply-To: <1205703537.32.0.106170069939.issue2312@psf.upfronthosting.co.za>
Message-ID: <1205703537.32.0.106170069939.issue2312@psf.upfronthosting.co.za>
New submission from Guido van Rossum <guido at python.org>:
The super() PEP currently is completely wrong w.r.t. reality. The
implementation is solid and won't change. The PEP just needs to be
rewritten to match reality.
----------
assignee: georg.brandl
components: Documentation
messages: 63600
nosy: georg.brandl, gvanrossum
severity: normal
status: open
title: Update PEP 3135 (super())
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2312>
__________________________________
From report at bugs.python.org Mon Mar 17 00:18:22 2008
From: report at bugs.python.org (Joseph Armbruster)
Date: Sun, 16 Mar 2008 23:18:22 +0000
Subject: [New-bugs-announce] [issue2313] correct longobject.c type cast
In-Reply-To: <1205709502.77.0.893498330113.issue2313@psf.upfronthosting.co.za>
Message-ID: <1205709502.77.0.893498330113.issue2313@psf.upfronthosting.co.za>
New submission from Joseph Armbruster <JosephArmbruster at gmail.com>:
longobject.c has a type cast that should be different to take
HAVE_UINTPTR_T into account.
ps: noticed this as i'm merging trunk -> PythonCE to get this working on
my new cellphone, the Wing!
----------
components: Interpreter Core
files: longobject.patch
keywords: patch
messages: 63607
nosy: JosephArmbruster, jyasskin
severity: normal
status: open
title: correct longobject.c type cast
versions: Python 2.6
Added file: http://bugs.python.org/file9683/longobject.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2313>
__________________________________
From report at bugs.python.org Mon Mar 17 00:32:48 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 16 Mar 2008 23:32:48 +0000
Subject: [New-bugs-announce] [issue2314] Test issue
In-Reply-To: <47DDAE1C.6070704@v.loewis.de>
Message-ID: <47DDAE1C.6070704@v.loewis.de>
New submission from Martin v. L?wis <martin at v.loewis.de>:
Let's see whether email submission works.
----------
assignee: gvanrossum
messages: 63609
nosy: gvanrossum, loewis
severity: normal
status: open
title: Test issue
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2314>
__________________________________
From report at bugs.python.org Mon Mar 17 09:00:09 2008
From: report at bugs.python.org (Per Cederqvist)
Date: Mon, 17 Mar 2008 08:00:09 +0000
Subject: [New-bugs-announce] [issue2315] TimedRotatingFileHandler does not
account for daylight savings time
In-Reply-To: <1205740809.7.0.649649150956.issue2315@psf.upfronthosting.co.za>
Message-ID: <1205740809.7.0.649649150956.issue2315@psf.upfronthosting.co.za>
New submission from Per Cederqvist <ceder at lysator.liu.se>:
If TimedRotatingFileHandler is instructed to roll over the log at
midnight or on a certain weekday, it needs to consider when daylight
savings time starts and ends. The current code just blindly adds
self.interval to self.rolloverAt, totally ignoring that sometimes it
should add 23 or 25 hours instead of 24 hours.
(I suspect that the implementation would be simpler if you use the
datetime module, rather than attempt to patch the existing code.)
----------
components: Library (Lib)
messages: 63622
nosy: ceder
severity: normal
status: open
title: TimedRotatingFileHandler does not account for daylight savings time
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2315>
__________________________________
From report at bugs.python.org Mon Mar 17 09:17:55 2008
From: report at bugs.python.org (Per Cederqvist)
Date: Mon, 17 Mar 2008 08:17:55 +0000
Subject: [New-bugs-announce] [issue2316] TimedRotatingFileHandler names
files incorrectly if nothing is logged during an interval
In-Reply-To: <1205741875.35.0.669932771172.issue2316@psf.upfronthosting.co.za>
Message-ID: <1205741875.35.0.669932771172.issue2316@psf.upfronthosting.co.za>
New submission from Per Cederqvist <ceder at lysator.liu.se>:
If nothing is logged during an interval, the TimedRotatingFileHandler
will give bad names to future log files.
The enclosed example program sets up a logger that rotates the log every
second. It then logs a few messages with sleep of 1, 2, 4, 1 and 1
seconds between the messages. The log files will have names that
increase with one second per log file, but the content for the last file
will be generated a different second.
An example run produced the message
2008-03-17 09:16:06: 1 sec later
in a log file named badlogdir/logfile.2008-03-17_09-16-02.
This problem was likely introduced in revision 42066. The root cause is
that self.rolloverAt is increased by self.interval in doRollover - but
if nothing was logged for a while, it should be increased by a multiple
of self.interval.
----------
messages: 63624
nosy: ceder
severity: normal
status: open
title: TimedRotatingFileHandler names files incorrectly if nothing is logged during an interval
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2316>
__________________________________
From report at bugs.python.org Mon Mar 17 09:29:36 2008
From: report at bugs.python.org (Per Cederqvist)
Date: Mon, 17 Mar 2008 08:29:36 +0000
Subject: [New-bugs-announce] [issue2317] TimedRotatingFileHandler logic for
removing files wrong
In-Reply-To: <1205742576.84.0.607022841001.issue2317@psf.upfronthosting.co.za>
Message-ID: <1205742576.84.0.607022841001.issue2317@psf.upfronthosting.co.za>
New submission from Per Cederqvist <ceder at lysator.liu.se>:
There are three issues with log file removal in the
TimedRotatingFileHandler class:
- Removal will stop working in the year 2100, as the code assumes that
timestamps start with ".20".
- If you run an application with backupCount set to a high number, and
then restarts it with a lower number, the code will still not remove
as many log files as you expect. It will never remove more than one
file when it rotates the log.
- It assumes that no other files matches baseFilename + ".20*", so
make sure that you don't log to both "log" and
"log.20th.century.fox" in the same directory!
Suggested fix: use os.listdir() instead of glob.glob(), filter all
file names using a proper regexp, sort the result, and use a while
loop to remove files until the result is small enough. To reduce the
risk of accidentally removing an unrelated file, the filter regexp
should be based on the logging interval, just as the filename is.
My suggested fix means that old files may not be removed if you change
the interval. I think that is an acceptable behavior, but it should
probably be documented to avoid future bug reports on this subject. :-)
----------
components: Library (Lib)
messages: 63626
nosy: ceder
severity: normal
status: open
title: TimedRotatingFileHandler logic for removing files wrong
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2317>
__________________________________
From report at bugs.python.org Mon Mar 17 09:32:59 2008
From: report at bugs.python.org (Per Cederqvist)
Date: Mon, 17 Mar 2008 08:32:59 +0000
Subject: [New-bugs-announce] [issue2318] TimedRotatingFileHandler: rotate
every month, or every year
In-Reply-To: <1205742779.64.0.634680353877.issue2318@psf.upfronthosting.co.za>
Message-ID: <1205742779.64.0.634680353877.issue2318@psf.upfronthosting.co.za>
New submission from Per Cederqvist <ceder at lysator.liu.se>:
In my curent project, I would like to rotate log files on the 1st of
every month. The TimedRotatingFileHandler class cannot do this, even
though it tries to be very generic.
I imagine that other projects would like to rotate the log file every
year. That can also not be done.
----------
components: Library (Lib)
messages: 63627
nosy: ceder
severity: normal
status: open
title: TimedRotatingFileHandler: rotate every month, or every year
type: feature request
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2318>
__________________________________
From report at bugs.python.org Mon Mar 17 11:49:27 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 17 Mar 2008 10:49:27 +0000
Subject: [New-bugs-announce] [issue2319] abc.py:ABCMeta.__instancecheck__
broken for old style classes
In-Reply-To: <1205750967.32.0.985818553342.issue2319@psf.upfronthosting.co.za>
Message-ID: <1205750967.32.0.985818553342.issue2319@psf.upfronthosting.co.za>
New submission from Ralf Schmitt <schmir at gmail.com>:
The following short program raises an exception:
import UserList
class C:
pass
print isinstance(C, UserList.UserList)
---------
exception:
Traceback (most recent call last):
File "t.py", line 6, in <module>
print isinstance(C, UserList.UserList)
File "/home/ralf/py26/lib/python2.6/abc.py", line 120, in
__instancecheck__
subclass = instance.__class__
AttributeError: class C has no attribute '__class__'
If I use a new style class it works.
----------
components: Interpreter Core
messages: 63630
nosy: schmir
severity: normal
status: open
title: abc.py:ABCMeta.__instancecheck__ broken for old style classes
type: crash
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2319>
__________________________________
From report at bugs.python.org Mon Mar 17 14:31:52 2008
From: report at bugs.python.org (=?utf-8?q?Ludwig_H=C3=A4hne?=)
Date: Mon, 17 Mar 2008 13:31:52 +0000
Subject: [New-bugs-announce] [issue2320] Race condition in subprocess using
stdin
In-Reply-To: <1205760712.39.0.906940637593.issue2320@psf.upfronthosting.co.za>
Message-ID: <1205760712.39.0.906940637593.issue2320@psf.upfronthosting.co.za>
New submission from Ludwig H?hne <wkx at gmx.li>:
Pythons subprocess module has a race condition when stdin is used. The
problem can be reproduced with the following script (based on the script
in issue "#1731717"/"msg32210" (slightly changed to use stdin):
----
import sys, os, threading, subprocess, time
class X(threading.Thread):
def __init__(self, *args, **kwargs):
super(X, self).__init__(*args, **kwargs)
self.start()
def tt():
s = subprocess.Popen(("cat"), stdin=subprocess.PIPE)
s.communicate(input = '#')
for i in xrange(20):
X(target = tt)
----
On multi-processor (or multi-core) machines the script hangs fairly
reliably.
Protecting the Popen call with a lock solves the problem. I searched the
documentation if using stdin with subprocess.Popen was not thread-safe,
but found no indication.
Tested with Python 2.5.1, 2.5.2 and 2.6a1. The problem can be reproduced
with all mentioned versions.
----------
components: Library (Lib)
messages: 63637
nosy: Pankrat
severity: normal
status: open
title: Race condition in subprocess using stdin
versions: Python 2.5, Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2320>
__________________________________
From report at bugs.python.org Mon Mar 17 16:48:22 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Mon, 17 Mar 2008 15:48:22 +0000
Subject: [New-bugs-announce] [issue2321] return more memory from unicode
objects to system
In-Reply-To: <1205768902.73.0.245115475399.issue2321@psf.upfronthosting.co.za>
Message-ID: <1205768902.73.0.245115475399.issue2321@psf.upfronthosting.co.za>
New submission from Neal Norwitz <nnorwitz at gmail.com>:
This patch returns more memory to the system when doing:
>>> x = [unicode(i) for i in xrange(1000000)]
>>> del x
If the above code is done, the memory before and after is quite
different. After this patch, the memory of the process as reported by
the system (like top/ps) should be approximately the same
----------
components: Interpreter Core
files: uni.diff
keywords: patch, patch
messages: 63654
nosy: nnorwitz
severity: normal
status: open
title: return more memory from unicode objects to system
type: resource usage
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9689/uni.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2321>
__________________________________
From report at bugs.python.org Mon Mar 17 17:27:50 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 16:27:50 +0000
Subject: [New-bugs-announce] [issue2322] Clean up getargs.c and its
formatting possibilities
In-Reply-To: <1205771270.76.0.30305062324.issue2322@psf.upfronthosting.co.za>
Message-ID: <1205771270.76.0.30305062324.issue2322@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
It was mentioned by Georg on python-3000 that getargs.c needs to be
cleaned up and worked on before Python 3.0 goes out the door.
----------
assignee: georg.brandl
components: Interpreter Core
messages: 63665
nosy: brett.cannon, georg.brandl
priority: immediate
severity: normal
status: open
title: Clean up getargs.c and its formatting possibilities
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2322>
__________________________________
From report at bugs.python.org Mon Mar 17 17:34:27 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 16:34:27 +0000
Subject: [New-bugs-announce] [issue2323] Unify structseq and namedtuple's API
In-Reply-To: <1205771667.83.0.681502782029.issue2323@psf.upfronthosting.co.za>
Message-ID: <1205771667.83.0.681502782029.issue2323@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
structseq and namedtuple should end up with a uniformed API.
----------
components: Extension Modules
messages: 63667
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Unify structseq and namedtuple's API
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2323>
__________________________________
From report at bugs.python.org Mon Mar 17 17:36:42 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 16:36:42 +0000
Subject: [New-bugs-announce] [issue2324] Document that 2.6 pickles of
strings turn into pickles of unicode in 3.0
In-Reply-To: <1205771802.78.0.509532879675.issue2324@psf.upfronthosting.co.za>
Message-ID: <1205771802.78.0.509532879675.issue2324@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
It turns out that unpickling a string from 2.6 leads to a Unicode string
in 3.0. That might fail since the encoding was never specified. This
should be documented probably in both 2.6 and 3.0.
----------
assignee: georg.brandl
components: Documentation
messages: 63669
nosy: brett.cannon, georg.brandl
priority: immediate
severity: normal
status: open
title: Document that 2.6 pickles of strings turn into pickles of unicode in 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2324>
__________________________________
From report at bugs.python.org Mon Mar 17 17:45:06 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Mon, 17 Mar 2008 16:45:06 +0000
Subject: [New-bugs-announce] [issue2325] isinstance(anything,
MetaclassThatDefinesInstancecheck) raises instead of returning False
In-Reply-To: <1205772306.86.0.317312162506.issue2325@psf.upfronthosting.co.za>
Message-ID: <1205772306.86.0.317312162506.issue2325@psf.upfronthosting.co.za>
New submission from Jeffrey Yasskin <jyasskin at gmail.com>:
>>> class Meta(type):
... def __instancecheck__(self, other):
... return False
>>> isinstance(3, Meta)
In 2.6, this results in:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: maximum recursion depth exceeded while calling a Python object
(That's a recursion in C, through PyObject_IsInstance and
instancemethod_call)
In 3.0, I get:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: __instancecheck__() takes exactly 2 positional arguments (1
given)
----------
components: Interpreter Core
messages: 63671
nosy: jyasskin
severity: normal
status: open
title: isinstance(anything, MetaclassThatDefinesInstancecheck) raises instead of returning False
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2325>
__________________________________
From report at bugs.python.org Mon Mar 17 17:48:40 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 16:48:40 +0000
Subject: [New-bugs-announce] [issue2326] Doc isnumeric and isdecimal for the
unicode object
In-Reply-To: <1205772520.65.0.452257175762.issue2326@psf.upfronthosting.co.za>
Message-ID: <1205772520.65.0.452257175762.issue2326@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Both the isnumeric and isdecimal methods on the unicode object need to
be documented.
----------
assignee: georg.brandl
components: Documentation
messages: 63672
nosy: brett.cannon, georg.brandl
priority: immediate
severity: normal
status: open
title: Doc isnumeric and isdecimal for the unicode object
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2326>
__________________________________
From report at bugs.python.org Mon Mar 17 18:18:56 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 17:18:56 +0000
Subject: [New-bugs-announce] [issue2327] Backport keyword-only arguments to
2.6
In-Reply-To: <1205774336.48.0.251602118658.issue2327@psf.upfronthosting.co.za>
Message-ID: <1205774336.48.0.251602118658.issue2327@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Keyword-only arguments have not been backported to 2.6 from 3.0.
----------
components: Interpreter Core
keywords: 26backport
messages: 63679
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Backport keyword-only arguments to 2.6
type: behavior
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2327>
__________________________________
From report at bugs.python.org Mon Mar 17 18:24:20 2008
From: report at bugs.python.org (Jack Diederich)
Date: Mon, 17 Mar 2008 17:24:20 +0000
Subject: [New-bugs-announce] [issue2328] Class **kwds broken (PEP 3115)
In-Reply-To: <1205774660.42.0.856799226329.issue2328@psf.upfronthosting.co.za>
Message-ID: <1205774660.42.0.856799226329.issue2328@psf.upfronthosting.co.za>
New submission from Jack Diederich <jackdied at gmail.com>:
typeobject.c:type_new only allows 0 or 1 keyword arg in class creation
instead of an arbitrary number as per PEP3115.
I'm working on a patch.
----------
assignee: jackdied
components: Interpreter Core
messages: 63681
nosy: jackdied
priority: normal
severity: normal
status: open
title: Class **kwds broken (PEP 3115)
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2328>
__________________________________
From report at bugs.python.org Mon Mar 17 18:25:42 2008
From: report at bugs.python.org (dd)
Date: Mon, 17 Mar 2008 17:25:42 +0000
Subject: [New-bugs-announce] [issue2329] ImportError: No module named _bsddb
In-Reply-To: <1205774742.16.0.265427731372.issue2329@psf.upfronthosting.co.za>
Message-ID: <1205774742.16.0.265427731372.issue2329@psf.upfronthosting.co.za>
New submission from dd <didier.damien at gmail.com>:
Installation from source, python.2.4.5.tgz.
It seems that severals *.so from bsddb are missing:
>>> import bsddb
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/tmp/Python-2.4.5/Lib/bsddb/__init__.py", line 47, in ?
import _bsddb
ImportError: No module named _bsddb
----------
components: Library (Lib)
messages: 63682
nosy: ddk
severity: normal
status: open
title: ImportError: No module named _bsddb
versions: Python 2.4
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2329>
__________________________________
From report at bugs.python.org Mon Mar 17 18:32:03 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 17 Mar 2008 17:32:03 +0000
Subject: [New-bugs-announce] [issue2330] Update PEP 3000 with new release
schedule
In-Reply-To: <1205775123.38.0.0848585015118.issue2330@psf.upfronthosting.co.za>
Message-ID: <1205775123.38.0.0848585015118.issue2330@psf.upfronthosting.co.za>
New submission from Guido van Rossum <guido at python.org>:
Barry, can you update the PEP with a discussion of the schedule, so we
can refer to it?
----------
assignee: barry
components: Documentation
messages: 63686
nosy: barry, gvanrossum
priority: urgent
severity: normal
status: open
title: Update PEP 3000 with new release schedule
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2330>
__________________________________
From report at bugs.python.org Mon Mar 17 18:34:30 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 17:34:30 +0000
Subject: [New-bugs-announce] [issue2331] Backport parameter annotations
In-Reply-To: <1205775270.85.0.593709274943.issue2331@psf.upfronthosting.co.za>
Message-ID: <1205775270.85.0.593709274943.issue2331@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Parameter annotations (e.g., ``def fxn(a:int) -> str: pass`` need to be
backported.
----------
components: Interpreter Core
keywords: 26backport
messages: 63688
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Backport parameter annotations
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2331>
__________________________________
From report at bugs.python.org Mon Mar 17 18:36:04 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 17:36:04 +0000
Subject: [New-bugs-announce] [issue2332] Renaming of attributes on functions
need to be backported.
In-Reply-To: <1205775364.33.0.962245412201.issue2332@psf.upfronthosting.co.za>
Message-ID: <1205775364.33.0.962245412201.issue2332@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
It should be double-checked that the renaming of attributes from
functions has been completed.
----------
assignee: nnorwitz
components: Interpreter Core
keywords: 26backport
messages: 63689
nosy: brett.cannon, nnorwitz
priority: immediate
severity: normal
status: open
title: Renaming of attributes on functions need to be backported.
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2332>
__________________________________
From report at bugs.python.org Mon Mar 17 18:37:33 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 17:37:33 +0000
Subject: [New-bugs-announce] [issue2333] Backport dict comprehensions
In-Reply-To: <1205775453.72.0.387864116054.issue2333@psf.upfronthosting.co.za>
Message-ID: <1205775453.72.0.387864116054.issue2333@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Dict comprehensions need to be backported.
----------
components: Interpreter Core
keywords: 26backport
messages: 63690
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Backport dict comprehensions
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2333>
__________________________________
From report at bugs.python.org Mon Mar 17 18:38:17 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 17:38:17 +0000
Subject: [New-bugs-announce] [issue2334] Backport set comprehensions
In-Reply-To: <1205775496.96.0.230528149509.issue2334@psf.upfronthosting.co.za>
Message-ID: <1205775496.96.0.230528149509.issue2334@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Set comprehensions need to be backported.
----------
components: Interpreter Core
keywords: 26backport
messages: 63691
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Backport set comprehensions
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2334>
__________________________________
From report at bugs.python.org Mon Mar 17 18:38:47 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 17:38:47 +0000
Subject: [New-bugs-announce] [issue2335] Backport set literals
In-Reply-To: <1205775527.12.0.350527481128.issue2335@psf.upfronthosting.co.za>
Message-ID: <1205775527.12.0.350527481128.issue2335@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Set literals need to be backported.
----------
components: Interpreter Core
keywords: 26backport
messages: 63692
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Backport set literals
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2335>
__________________________________
From report at bugs.python.org Mon Mar 17 18:49:24 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 17:49:24 +0000
Subject: [New-bugs-announce] [issue2336] Backport PEP 3114 (__next__)
In-Reply-To: <1205776164.44.0.568084726055.issue2336@psf.upfronthosting.co.za>
Message-ID: <1205776164.44.0.568084726055.issue2336@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
PEP 3114 needs to be backported. Most likely the best approach is to
backport the next() built-in but to have it call next() on the iterator
instead of __next__(). That should hopefully minimize breakage while
allowing for moving over to the new built-in.
----------
keywords: 26backport
messages: 63694
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Backport PEP 3114 (__next__)
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2336>
__________________________________
From report at bugs.python.org Mon Mar 17 18:51:06 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 17:51:06 +0000
Subject: [New-bugs-announce] [issue2337] Backport oct() and hex() to use
__index__
In-Reply-To: <1205776266.64.0.297851457778.issue2337@psf.upfronthosting.co.za>
Message-ID: <1205776266.64.0.297851457778.issue2337@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
oct() and hex() need to use __index__ when available and then emit a
Py3K warning when they fall back on __oct__ and __hex__.
----------
components: Interpreter Core
keywords: 26backport
messages: 63695
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Backport oct() and hex() to use __index__
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2337>
__________________________________
From report at bugs.python.org Mon Mar 17 18:53:00 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 17:53:00 +0000
Subject: [New-bugs-announce] [issue2338] Backport reload() moving to
imp.reload()
In-Reply-To: <1205776379.99.0.615033547761.issue2338@psf.upfronthosting.co.za>
Message-ID: <1205776379.99.0.615033547761.issue2338@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
A fixer to change calls from reload() to imp.reload() needs to happen.
Plus imp.reload() should come into existence.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
keywords: 26backport
messages: 63697
nosy: brett.cannon, collinwinter
priority: immediate
severity: normal
status: open
title: Backport reload() moving to imp.reload()
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2338>
__________________________________
From report at bugs.python.org Mon Mar 17 18:55:49 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 17:55:49 +0000
Subject: [New-bugs-announce] [issue2339] Backport intern() -> sys.intern()
In-Reply-To: <1205776549.43.0.234152621457.issue2339@psf.upfronthosting.co.za>
Message-ID: <1205776549.43.0.234152621457.issue2339@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
intern() needs to be added as sys.intern(). Then a 2to3 fixer needs to
be written.
----------
components: Interpreter Core
keywords: 26backport
messages: 63698
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Backport intern() -> sys.intern()
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2339>
__________________________________
From report at bugs.python.org Mon Mar 17 18:58:35 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 17:58:35 +0000
Subject: [New-bugs-announce] [issue2340] Backport PEP 3132 (extended
iterable unpacking)
In-Reply-To: <1205776715.68.0.275061992416.issue2340@psf.upfronthosting.co.za>
Message-ID: <1205776715.68.0.275061992416.issue2340@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
PEP 3132 (extended iterable unpacking) needs to be backported.
----------
components: Interpreter Core
keywords: 26backport
messages: 63699
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Backport PEP 3132 (extended iterable unpacking)
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2340>
__________________________________
From report at bugs.python.org Mon Mar 17 19:10:56 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 18:10:56 +0000
Subject: [New-bugs-announce] [issue2341] Raise a Py3K warning when raise
non-BaseException exceptions
In-Reply-To: <1205777456.01.0.538815512793.issue2341@psf.upfronthosting.co.za>
Message-ID: <1205777456.01.0.538815512793.issue2341@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Raising exceptions that do not inherit from BaseException (e.g., classic
classes) should raise a Py3K warning.
----------
components: Interpreter Core
keywords: 26backport
messages: 63700
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Raise a Py3K warning when raise non-BaseException exceptions
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2341>
__________________________________
From report at bugs.python.org Mon Mar 17 19:12:55 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 18:12:55 +0000
Subject: [New-bugs-announce] [issue2342] Comparing between disparate types
should raise a Py3K warning
In-Reply-To: <1205777575.3.0.830443648256.issue2342@psf.upfronthosting.co.za>
Message-ID: <1205777575.3.0.830443648256.issue2342@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
When you compare disparate types through something other than == and !=
a Py3K warning should be raised.
----------
components: Interpreter Core
keywords: 26backport
messages: 63702
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Comparing between disparate types should raise a Py3K warning
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2342>
__________________________________
From report at bugs.python.org Mon Mar 17 19:16:18 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 18:16:18 +0000
Subject: [New-bugs-announce] [issue2343] Raise a Py3K warning when using a
float where an int is expected
In-Reply-To: <1205777778.13.0.206701956987.issue2343@psf.upfronthosting.co.za>
Message-ID: <1205777778.13.0.206701956987.issue2343@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Using a float where an int should only be used (e.g., ``[].insert(.5,
0)``) should raise a Py3K warning.
----------
components: Interpreter Core
keywords: 26backport
messages: 63704
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Raise a Py3K warning when using a float where an int is expected
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2343>
__________________________________
From report at bugs.python.org Mon Mar 17 19:20:04 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 18:20:04 +0000
Subject: [New-bugs-announce] [issue2344] Using an iteration variable outside
a list comprehension needs a Py3K warning
In-Reply-To: <1205778004.51.0.0647688258878.issue2344@psf.upfronthosting.co.za>
Message-ID: <1205778004.51.0.0647688258878.issue2344@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
If you use a iteration variable from a list comprehension from outside
the list comprehension itself should raise a Py3K warning.
----------
components: Interpreter Core
keywords: 26backport
messages: 63706
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Using an iteration variable outside a list comprehension needs a Py3K warning
type: behavior
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2344>
__________________________________
From report at bugs.python.org Mon Mar 17 19:29:09 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 18:29:09 +0000
Subject: [New-bugs-announce] [issue2345] Using an exception variable outside
an 'except' clause should raise a Py3K warning
In-Reply-To: <1205778549.05.0.340690581025.issue2345@psf.upfronthosting.co.za>
Message-ID: <1205778549.05.0.340690581025.issue2345@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
If one tries to use an exception bound to a variable in an 'except'
clause it should raise a Py3K warning.
----------
components: Interpreter Core
keywords: 26backport
messages: 63708
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Using an exception variable outside an 'except' clause should raise a Py3K warning
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2345>
__________________________________
From report at bugs.python.org Mon Mar 17 20:15:55 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 19:15:55 +0000
Subject: [New-bugs-announce] [issue2346] Py3K warn against using __members__
In-Reply-To: <1205781355.97.0.143101300316.issue2346@psf.upfronthosting.co.za>
Message-ID: <1205781355.97.0.143101300316.issue2346@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Using __members__ should raise a Py3K warning.
----------
components: Interpreter Core
keywords: 26backport
messages: 63713
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Py3K warn against using __members__
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2346>
__________________________________
From report at bugs.python.org Mon Mar 17 20:16:35 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 19:16:35 +0000
Subject: [New-bugs-announce] [issue2347] Py3K warn for using __methods__
In-Reply-To: <1205781395.77.0.22785481066.issue2347@psf.upfronthosting.co.za>
Message-ID: <1205781395.77.0.22785481066.issue2347@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Using __methods__ should trigger a Py3K warning.
----------
components: Interpreter Core
keywords: 26backport
messages: 63715
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Py3K warn for using __methods__
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2347>
__________________________________
From report at bugs.python.org Mon Mar 17 20:17:34 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 19:17:34 +0000
Subject: [New-bugs-announce] [issue2348] Py3K warn using file.whitespace
In-Reply-To: <1205781454.44.0.267838748773.issue2348@psf.upfronthosting.co.za>
Message-ID: <1205781454.44.0.267838748773.issue2348@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
A Py3K warning should be raised if file.whitespace is used in any way.
----------
components: Interpreter Core
keywords: 26backport
messages: 63716
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Py3K warn using file.whitespace
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2348>
__________________________________
From report at bugs.python.org Mon Mar 17 20:19:18 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 19:19:18 +0000
Subject: [New-bugs-announce] [issue2349] Py3K warn against assigning to
True/False
In-Reply-To: <1205781558.49.0.8223061173.issue2349@psf.upfronthosting.co.za>
Message-ID: <1205781558.49.0.8223061173.issue2349@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Assigning to True of False should raise at least a Py3K warning (maybe
something more severe?).
----------
components: Interpreter Core
keywords: 26backport
messages: 63717
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Py3K warn against assigning to True/False
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2349>
__________________________________
From report at bugs.python.org Mon Mar 17 20:22:08 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 19:22:08 +0000
Subject: [New-bugs-announce] [issue2350] Warn against importing 'exceptions'
In-Reply-To: <1205781728.94.0.172904523331.issue2350@psf.upfronthosting.co.za>
Message-ID: <1205781728.94.0.172904523331.issue2350@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Importing 'exceptions' should raise at least a Py3K warning, if not a
full DeprecationWarning.
----------
keywords: 26backport
messages: 63718
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Warn against importing 'exceptions'
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2350>
__________________________________
From report at bugs.python.org Mon Mar 17 20:25:50 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 19:25:50 +0000
Subject: [New-bugs-announce] [issue2351] Using __(get|set|del)slice__ needs
a Py3K warning
In-Reply-To: <1205781950.27.0.373262403041.issue2351@psf.upfronthosting.co.za>
Message-ID: <1205781950.27.0.373262403041.issue2351@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Using any of the slicing methods (e.g., __getslice__) should raise a
Py3K warning.
----------
components: Interpreter Core
keywords: 26backport
messages: 63721
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Using __(get|set|del)slice__ needs a Py3K warning
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2351>
__________________________________
From report at bugs.python.org Mon Mar 17 20:27:14 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 19:27:14 +0000
Subject: [New-bugs-announce] [issue2352] Use of __oct__/__hex__ should raise
a Py3K warning
In-Reply-To: <1205782034.73.0.229035988217.issue2352@psf.upfronthosting.co.za>
Message-ID: <1205782034.73.0.229035988217.issue2352@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Use of __hex__ and __oct__ should raise a Py3K warning.
----------
components: Interpreter Core
keywords: 26backport
messages: 63722
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Use of __oct__/__hex__ should raise a Py3K warning
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2352>
__________________________________
From report at bugs.python.org Mon Mar 17 20:29:00 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 19:29:00 +0000
Subject: [New-bugs-announce] [issue2353] Use of file.xreadlines() should
raise a Py3K warning
In-Reply-To: <1205782140.75.0.577448630615.issue2353@psf.upfronthosting.co.za>
Message-ID: <1205782140.75.0.577448630615.issue2353@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Using file.xreadlines() should raise a Py3K warning.
----------
components: Interpreter Core
keywords: 26backport
messages: 63724
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Use of file.xreadlines() should raise a Py3K warning
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2353>
__________________________________
From report at bugs.python.org Mon Mar 17 20:30:11 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 19:30:11 +0000
Subject: [New-bugs-announce] [issue2354] cmp argument to
list.sort()/sorted() should raise a Py3K warning
In-Reply-To: <1205782211.6.0.934088370296.issue2354@psf.upfronthosting.co.za>
Message-ID: <1205782211.6.0.934088370296.issue2354@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
The cmp argument for list.sort() and sorted() should raise a Py3K warning.
----------
keywords: 26backport
messages: 63725
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: cmp argument to list.sort()/sorted() should raise a Py3K warning
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2354>
__________________________________
From report at bugs.python.org Mon Mar 17 20:30:56 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 19:30:56 +0000
Subject: [New-bugs-announce] [issue2355] Using buffer() should raise a Py3K
warning
In-Reply-To: <1205782256.14.0.33369210051.issue2355@psf.upfronthosting.co.za>
Message-ID: <1205782256.14.0.33369210051.issue2355@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Using buffer() should raise a Py3K warning.
----------
components: Interpreter Core
keywords: 26backport
messages: 63726
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Using buffer() should raise a Py3K warning
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2355>
__________________________________
From report at bugs.python.org Mon Mar 17 20:37:32 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 19:37:32 +0000
Subject: [New-bugs-announce] [issue2356] sys.exitfunc should raise a Py3K
warning
In-Reply-To: <1205782652.14.0.516090878435.issue2356@psf.upfronthosting.co.za>
Message-ID: <1205782652.14.0.516090878435.issue2356@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
sys.exitfunc should raise a Py3K warning when set/used.
----------
components: Interpreter Core
keywords: 26backport
messages: 63731
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: sys.exitfunc should raise a Py3K warning
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2356>
__________________________________
From report at bugs.python.org Mon Mar 17 20:38:46 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 19:38:46 +0000
Subject: [New-bugs-announce] [issue2357] sys.exc_{type, values,
traceback} should raise a Py3K warning
In-Reply-To: <1205782726.96.0.925182629024.issue2357@psf.upfronthosting.co.za>
Message-ID: <1205782726.96.0.925182629024.issue2357@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Using sys.exc_{type,values,traceback} should raise a Py3K warning.
----------
components: Interpreter Core
keywords: 26backport
messages: 63732
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: sys.exc_{type,values,traceback} should raise a Py3K warning
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2357>
__________________________________
From report at bugs.python.org Mon Mar 17 20:39:31 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 19:39:31 +0000
Subject: [New-bugs-announce] [issue2358] Using sys.exc_clear should raise a
Py3K warning
In-Reply-To: <1205782771.08.0.305016984378.issue2358@psf.upfronthosting.co.za>
Message-ID: <1205782771.08.0.305016984378.issue2358@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Using sys.exc_clear should raise a Py3K warning.
----------
components: Interpreter Core
keywords: 26backport
messages: 63733
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Using sys.exc_clear should raise a Py3K warning
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2358>
__________________________________
From report at bugs.python.org Mon Mar 17 20:41:23 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 19:41:23 +0000
Subject: [New-bugs-announce] [issue2359] A Py3K warning for
array.array.{read, write} is needed
In-Reply-To: <1205782883.21.0.134767238935.issue2359@psf.upfronthosting.co.za>
Message-ID: <1205782883.21.0.134767238935.issue2359@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
array.{read,write} from the array module should raise at least a Py3K
warning, if not a DeprecationWarning.
----------
components: Interpreter Core
keywords: 26backport
messages: 63735
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: A Py3K warning for array.array.{read,write} is needed
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2359>
__________________________________
From report at bugs.python.org Mon Mar 17 20:46:01 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 19:46:01 +0000
Subject: [New-bugs-announce] [issue2360] Fixer for itertools.imap() -> map()
In-Reply-To: <1205783160.99.0.976261842944.issue2360@psf.upfronthosting.co.za>
Message-ID: <1205783160.99.0.976261842944.issue2360@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
A fixer for converting itertools.imap() to -> map() is needed.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
keywords: 26backport
messages: 63736
nosy: brett.cannon, collinwinter
priority: immediate
severity: normal
status: open
title: Fixer for itertools.imap() -> map()
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2360>
__________________________________
From report at bugs.python.org Mon Mar 17 20:47:30 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 19:47:30 +0000
Subject: [New-bugs-announce] [issue2361] Fixer for itertools.ifilter() ->
filter()
In-Reply-To: <1205783250.41.0.363081316458.issue2361@psf.upfronthosting.co.za>
Message-ID: <1205783250.41.0.363081316458.issue2361@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
A fixer to go from itertools.ifilter() to filter() is needed.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
keywords: 26backport
messages: 63737
nosy: brett.cannon, collinwinter
priority: immediate
severity: normal
status: open
title: Fixer for itertools.ifilter() -> filter()
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2361>
__________________________________
From report at bugs.python.org Mon Mar 17 20:48:07 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 19:48:07 +0000
Subject: [New-bugs-announce] [issue2362] Fixer for itertools.izip() -> zip()
In-Reply-To: <1205783287.8.0.394861371785.issue2362@psf.upfronthosting.co.za>
Message-ID: <1205783287.8.0.394861371785.issue2362@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
A fixer for itertools.izip() to zip() is needed.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
keywords: 26backport
messages: 63738
nosy: brett.cannon, collinwinter
priority: immediate
severity: normal
status: open
title: Fixer for itertools.izip() -> zip()
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2362>
__________________________________
From report at bugs.python.org Mon Mar 17 20:50:15 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 19:50:15 +0000
Subject: [New-bugs-announce] [issue2363] Fixer for itertools.ifilterfalse()
-> itertools.filterfalse()
In-Reply-To: <1205783415.62.0.638293283176.issue2363@psf.upfronthosting.co.za>
Message-ID: <1205783415.62.0.638293283176.issue2363@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
A fixer is needed to go from itertools.ifilterfalse() to
itertools.filterfalse().
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
keywords: 26backport
messages: 63739
nosy: brett.cannon, collinwinter
priority: immediate
severity: normal
status: open
title: Fixer for itertools.ifilterfalse() -> itertools.filterfalse()
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2363>
__________________________________
From report at bugs.python.org Mon Mar 17 20:50:39 2008
From: report at bugs.python.org (David Wolever)
Date: Mon, 17 Mar 2008 19:50:39 +0000
Subject: [New-bugs-announce] [issue2364] Patch to make 2to3 testing easier
In-Reply-To: <1205783439.73.0.272179327902.issue2364@psf.upfronthosting.co.za>
Message-ID: <1205783439.73.0.272179327902.issue2364@psf.upfronthosting.co.za>
New submission from David Wolever <wolever at cs.toronto.edu>:
This patch makes it easier to run tests in the 2to3 suite.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: 2to3tester.patch
keywords: patch
messages: 63740
nosy: David Wolever, collinwinter
severity: normal
status: open
title: Patch to make 2to3 testing easier
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file9696/2to3tester.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2364>
__________________________________
From report at bugs.python.org Mon Mar 17 20:53:15 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 19:53:15 +0000
Subject: [New-bugs-announce] [issue2365] Fixer for filter(None,
...) -> filter(bool, ...)
In-Reply-To: <1205783595.14.0.905564952624.issue2365@psf.upfronthosting.co.za>
Message-ID: <1205783595.14.0.905564952624.issue2365@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
A fixer to go from filter(None, ..) to filter(bool, ..) is needed.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
keywords: 26backport
messages: 63742
nosy: brett.cannon, collinwinter
priority: immediate
severity: normal
status: open
title: Fixer for filter(None, ...) -> filter(bool, ...)
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2365>
__________________________________
From report at bugs.python.org Mon Mar 17 20:54:32 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 19:54:32 +0000
Subject: [New-bugs-announce] [issue2366] Fixer for new metaclass syntax is
needed
In-Reply-To: <1205783672.52.0.982802083184.issue2366@psf.upfronthosting.co.za>
Message-ID: <1205783672.52.0.982802083184.issue2366@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
* new metaclass syntax (removing __metaclass__?)
- __metaclass__ = type at global level disappear
- __metaclass__ = <anything else> should generate warning
- __metaclass__ = <something> within a class should use new syntax
- class __metaclass__ should be warned about
- any other use of __metaclass__ should be warned about
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
keywords: 26backport
messages: 63743
nosy: brett.cannon, collinwinter
priority: immediate
severity: normal
status: open
title: Fixer for new metaclass syntax is needed
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2366>
__________________________________
From report at bugs.python.org Mon Mar 17 20:55:54 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 19:55:54 +0000
Subject: [New-bugs-announce] [issue2367] Fixer to handle new places where
parentheses are needed
In-Reply-To: <1205783754.65.0.365050189029.issue2367@psf.upfronthosting.co.za>
Message-ID: <1205783754.65.0.365050189029.issue2367@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Py3K has some places where parentheses are now required (e.g., ``[x for
x in 1, 2]`` to ``[x for x in (1, 2)``). A fixer is needed to handle the
conversion.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
keywords: 26backport
messages: 63744
nosy: brett.cannon, collinwinter
priority: immediate
severity: normal
status: open
title: Fixer to handle new places where parentheses are needed
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2367>
__________________________________
From report at bugs.python.org Mon Mar 17 20:57:05 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 19:57:05 +0000
Subject: [New-bugs-announce] [issue2368] Backport __builtin__ to 'builtins'
In-Reply-To: <1205783825.31.0.623855463927.issue2368@psf.upfronthosting.co.za>
Message-ID: <1205783825.31.0.623855463927.issue2368@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
'builtins' needs to be added as a module for __builtin__. A fixer will
also be needed.
----------
components: Interpreter Core
keywords: 26backport
messages: 63745
nosy: brett.cannon
priority: immediate
severity: normal
status: open
title: Backport __builtin__ to 'builtins'
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2368>
__________________________________
From report at bugs.python.org Mon Mar 17 21:00:32 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 20:00:32 +0000
Subject: [New-bugs-announce] [issue2369] Fixer for new integer literals are
needed
In-Reply-To: <1205784031.99.0.585423038669.issue2369@psf.upfronthosting.co.za>
Message-ID: <1205784031.99.0.585423038669.issue2369@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
A fixer(s) to handle the new integer literals are needed.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
keywords: 26backport
messages: 63749
nosy: brett.cannon, collinwinter
priority: immediate
severity: normal
status: open
title: Fixer for new integer literals are needed
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2369>
__________________________________
From report at bugs.python.org Mon Mar 17 21:04:32 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Mar 2008 20:04:32 +0000
Subject: [New-bugs-announce] [issue2370] operator.{isCallable,
sequenceIncludes} needs a fixer
In-Reply-To: <1205784272.93.0.866002228926.issue2370@psf.upfronthosting.co.za>
Message-ID: <1205784272.93.0.866002228926.issue2370@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
A fixer for operator.{isCallable,sequenceIncludes} similar to the one
for callable() is needed.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
keywords: 26backport
messages: 63751
nosy: brett.cannon, collinwinter
priority: immediate
severity: normal
status: open
title: operator.{isCallable,sequenceIncludes} needs a fixer
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2370>
__________________________________
From report at bugs.python.org Mon Mar 17 21:35:49 2008
From: report at bugs.python.org (Taek Joo Kim)
Date: Mon, 17 Mar 2008 20:35:49 +0000
Subject: [New-bugs-announce] [issue2371] Patch for catching exceptions that
do not inherit from BaseException
In-Reply-To: <1205786149.24.0.883514368484.issue2371@psf.upfronthosting.co.za>
Message-ID: <1205786149.24.0.883514368484.issue2371@psf.upfronthosting.co.za>
New submission from Taek Joo Kim <taicki at gmail.com>:
With this patch it prints warning message for catching exceptions that
don't inherit from BaseException when -3 flag is used.
----------
components: Interpreter Core
files: catchexc.patch
keywords: patch
messages: 63761
nosy: taicki
severity: normal
status: open
title: Patch for catching exceptions that do not inherit from BaseException
versions: Python 2.6
Added file: http://bugs.python.org/file9701/catchexc.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2371>
__________________________________
From report at bugs.python.org Mon Mar 17 22:49:54 2008
From: report at bugs.python.org (David Wolever)
Date: Mon, 17 Mar 2008 21:49:54 +0000
Subject: [New-bugs-announce] [issue2372] Pubkey
In-Reply-To: <A9FD7A99-E6EE-484A-BF0A-5AA9E60662D7@cs.toronto.edu>
Message-ID: <A9FD7A99-E6EE-484A-BF0A-5AA9E60662D7@cs.toronto.edu>
New submission from David Wolever <wolever at cs.toronto.edu>:
ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAIEAvyZUU3zNsAoETLN8kDgTmm6qPeWMqUno3KkxcayPSVzT
U2pBLlMet/LVtLpHwqARTo4d5/g9vmjwPluQO7LgyIsH88GlJYRgPwV08rpzBTDR+/
0ZQWt82J7loB1z6mhxMS+YS0Oe2UOEXxYTCKfwwyTXDKVRk8wjlneyI9JZfB8=
wolever at wolever.net
----------
messages: 63789
nosy: David Wolever
severity: normal
status: open
title: Pubkey
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2372>
__________________________________
From report at bugs.python.org Mon Mar 17 23:10:34 2008
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 17 Mar 2008 22:10:34 +0000
Subject: [New-bugs-announce] [issue2373] Raise Py3K warnings for comparisons
that changed
In-Reply-To: <1205791834.41.0.508035363827.issue2373@psf.upfronthosting.co.za>
Message-ID: <1205791834.41.0.508035363827.issue2373@psf.upfronthosting.co.za>
New submission from Steven Bethard <steven.bethard at gmail.com>:
Some comparisons were changed or removed in Python 3.0. In 2.6 you could
compare types (e.g. ``str < int``) and dicts supported more than just
equality. These comparisons should produce Py3K warnings.
----------
assignee: bethard
components: Interpreter Core
keywords: 26backport
messages: 63792
nosy: bethard
priority: urgent
severity: normal
status: open
title: Raise Py3K warnings for comparisons that changed
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2373>
__________________________________
From report at bugs.python.org Tue Mar 18 01:13:53 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 18 Mar 2008 00:13:53 +0000
Subject: [New-bugs-announce] [issue2374] Use of builtin file should give
Py3k warning
In-Reply-To: <1205799233.33.0.666545260865.issue2374@psf.upfronthosting.co.za>
Message-ID: <1205799233.33.0.666545260865.issue2374@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
This patch causes the use of builtin file to give a Py3k warning.
When Python starts up, distutils.text_file gives a warning because it
uses a variable named file. I imagine there are places like this all
over in the stdlib, which should be renamed fp or something similar.
----------
components: Interpreter Core
files: file_warning.patch
keywords: patch
messages: 63814
nosy: benjamin.peterson
severity: normal
status: open
title: Use of builtin file should give Py3k warning
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9710/file_warning.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2374>
__________________________________
From report at bugs.python.org Tue Mar 18 01:34:55 2008
From: report at bugs.python.org (Glyph Lefkowitz)
Date: Tue, 18 Mar 2008 00:34:55 +0000
Subject: [New-bugs-announce] [issue2375] PYTHON3PATH environment variable to
supersede PYTHONPATH for multi-Python environments
In-Reply-To: <1205800495.39.0.697300117462.issue2375@psf.upfronthosting.co.za>
Message-ID: <1205800495.39.0.697300117462.issue2375@psf.upfronthosting.co.za>
New submission from Glyph Lefkowitz <glyph at divmod.com>:
Currently if you have both Python 3 and Python 2 installed, there's no
way to indicate that ".py" files in one area are Python 2 syntax and in
another area are Python 3 syntax. Being able to distinguish between
these would be nice for heterogeneous deployment environments, but is
particularly important for developers who are working on Python 3
conversions.
It would be good to have a PYTHON3PATH which, if present, would be
honored instead of PYTHONPATH. PYTHONPATH could still be honored if
PYTHON3PATH was not present, so this is purely a new feature and
shouldn't have much impact on compatibility.
----------
components: Interpreter Core
messages: 63820
nosy: glyph
severity: normal
status: open
title: PYTHON3PATH environment variable to supersede PYTHONPATH for multi-Python environments
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2375>
__________________________________
From report at bugs.python.org Tue Mar 18 02:00:29 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 18 Mar 2008 01:00:29 +0000
Subject: [New-bugs-announce] [issue2376] Set up "supported"-only buildbot
waterfall view
In-Reply-To: <1205802028.97.0.321014582059.issue2376@psf.upfronthosting.co.za>
Message-ID: <1205802028.97.0.321014582059.issue2376@psf.upfronthosting.co.za>
New submission from Jean-Paul Calderone <exarkun at divmod.com>:
The Python buildbot's waterfall view currently shows all builders. Not
all of these are expected to work currently. This can be confusing to
people trying to understand the current state of Python on various
platforms. Buildbot can be configured to present limited views, for
example only including builders for platforms where all the tests are
expected to be passing (and expected to remain passing).
The way to place a builder in a particular category is with the
"category" keyword in its dict:
builders.append({
'name': 'foo',
'factory': bar
'category': 'unsupported'})
With 0.7.5, adding a "category" query argument will restrict the view to
include only builders from the specified category.
With 0.7.6, you can construct a custom
buildbot.status.web.waterfall.WaterfallStatusResource and pass a list
for the categories initializer argument which will restrict the builders
it displays. You can make several of these for different categories and
put them at various places in the resource hierarchy.
----------
components: None
messages: 63832
nosy: exarkun
severity: normal
status: open
title: Set up "supported"-only buildbot waterfall view
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2376>
__________________________________
From report at bugs.python.org Tue Mar 18 03:40:13 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 18 Mar 2008 02:40:13 +0000
Subject: [New-bugs-announce] [issue2377] Replace import.c with a pure Python
implementation
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
Python/import.c should be replaced by the implementation under
development contained in the py3k-importlib branch.
----------
assignee: brett.cannon
components: Interpreter Core
messages: 63851
nosy: brett.cannon
priority: critical
severity: normal
status: open
title: Replace import.c with a pure Python implementation
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
__________________________________
From report at bugs.python.org Tue Mar 18 03:55:45 2008
From: report at bugs.python.org (Jerry Seutter)
Date: Tue, 18 Mar 2008 02:55:45 +0000
Subject: [New-bugs-announce] [issue2378] UnboundLocalError when trying to
raise exceptions inside execfile
In-Reply-To: <1205808945.1.0.883835206976.issue2378@psf.upfronthosting.co.za>
Message-ID: <1205808945.1.0.883835206976.issue2378@psf.upfronthosting.co.za>
New submission from Jerry Seutter <jseutter at gmail.com>:
Found a bug when trying to integrate figleaf coverage into trunk. I
have ripped the code down to the smallest subset that still causes the
behaviour. The code works on the latest release of Python 2.5 but is
broken on trunk. It comes in two files. The first is the caller (figleaf):
import os
import sys
def foo(f, e, o):
pass
sys.settrace(foo)
import __main__
execfile('test_broken.py', __main__.__dict__)
The second file is the test (test_broken.py):
# This code breaks on trunk
def test_foo():
class CustomException(Exception):
pass
class SomeClass:
def foo(self):
raise CustomException
# The error only appears with enough nested blocks.
if (True == True):
try:
raise IOError
except CustomException:
pass
It should raise IOError. When run, it gives the following output:
jerry-seutters-computer:~/code/python/core_wierd_bug_minimal jseutter$
../core/python.exe figleaf
Traceback (most recent call last):
File "figleaf", line 10, in <module>
execfile('test_broken.py', __main__.__dict__)
File "test_broken.py", line 18, in <module>
test_foo()
File "test_broken.py", line 15, in test_foo
except CustomException:
UnboundLocalError: local variable 'CustomException' referenced before
assignment
[10019 refs]
----------
files: core_wierd_bug_minimal.zip
messages: 63856
nosy: jseutter
severity: normal
status: open
title: UnboundLocalError when trying to raise exceptions inside execfile
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9716/core_wierd_bug_minimal.zip
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2378>
__________________________________
From report at bugs.python.org Tue Mar 18 04:15:38 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 18 Mar 2008 03:15:38 +0000
Subject: [New-bugs-announce] [issue2379] Raise a Py3K warning for
__getitem__ or __getslice__ on exception instances
In-Reply-To: <1205810138.46.0.535450979934.issue2379@psf.upfronthosting.co.za>
Message-ID: <1205810138.46.0.535450979934.issue2379@psf.upfronthosting.co.za>
New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:
As requested by Guido at msg63858. Will create a patch.
----------
components: Interpreter Core
messages: 63864
nosy: belopolsky
severity: normal
status: open
title: Raise a Py3K warning for __getitem__ or __getslice__ on exception instances
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2379>
__________________________________
From report at bugs.python.org Tue Mar 18 04:51:03 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 18 Mar 2008 03:51:03 +0000
Subject: [New-bugs-announce] [issue2380] Raise a Py3K warning for catching
nested tuples with non-BaseException exceptions
In-Reply-To: <1205812263.49.0.840453912449.issue2380@psf.upfronthosting.co.za>
Message-ID: <1205812263.49.0.840453912449.issue2380@psf.upfronthosting.co.za>
New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:
As of r61478, the following code fails to produce a py3k warning:
try:
raise ValueError
except ((ValueError,object),):
pass
which is an error for in py3k:
Traceback (most recent call last):
File "x.py", line 3, in <module>
except ((ValueError,object),):
TypeError: catching classes that do not inherit from BaseException is
not allowed
----------
components: Interpreter Core
messages: 63875
nosy: belopolsky
severity: normal
status: open
title: Raise a Py3K warning for catching nested tuples with non-BaseException exceptions
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2380>
__________________________________
From report at bugs.python.org Tue Mar 18 05:19:15 2008
From: report at bugs.python.org (Alan Brooks)
Date: Tue, 18 Mar 2008 04:19:15 +0000
Subject: [New-bugs-announce] [issue2381] test_subprocess fails if your
sys.executable is on a path with a space in it
In-Reply-To: <1205813955.12.0.0111122307325.issue2381@psf.upfronthosting.co.za>
Message-ID: <1205813955.12.0.0111122307325.issue2381@psf.upfronthosting.co.za>
New submission from Alan Brooks <alancbrooks at gmail.com>:
Patch attached that escapes the executable name so this test doesn't fail.
----------
components: Tests
files: test_subprocess-r61479.patch
keywords: patch
messages: 63883
nosy: lanny
severity: normal
status: open
title: test_subprocess fails if your sys.executable is on a path with a space in it
versions: Python 2.6
Added file: http://bugs.python.org/file9719/test_subprocess-r61479.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2381>
__________________________________
From report at bugs.python.org Tue Mar 18 06:22:32 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 18 Mar 2008 05:22:32 +0000
Subject: [New-bugs-announce] [issue2382] [Py3k] SyntaxError cursor shifted
if multibyte character is in line.
In-Reply-To: <1205817752.04.0.892564898323.issue2382@psf.upfronthosting.co.za>
Message-ID: <1205817752.04.0.892564898323.issue2382@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:
Hello. I found another problem related to issue2301.
SyntaxError cursor "^" is shifted when multibyte
characters are in line (before "^").
I think this is because err->text is stored as UTF-8
which requires 3 bytes for multibyte character,
but actually cp932 (my console encoding) requires only 2 bytes for it.
So "^" is shited to right 5 bytes because there is 5 multibyte chars.
C:\Documents and Settings\WhiteRabbit>py3k x.py
push any key....
File "x.py", line 3
print "?????"
^
SyntaxError: invalid syntax
[22567 refs]
Sorry, I didn't know what PyTokenizer_RestoreEncoding really doing.
That function adjusted err_ret->offset for this encoding conversion.
So, Python2.5 can output cursor in right place. (Of course, if source
encoding is not compatible for console encoding, broken string is printed
though. Anyway, cursor is right)
C:\Documents and Settings\WhiteRabbit>py a.py
File "a.py", line 2
x "??????????"
^
SyntaxError: invalid syntax
[8728 refs]
I tried to fix this problem, but I'm not sure how to fix this.
----------
components: None
messages: 63895
nosy: ocean-city
severity: normal
status: open
title: [Py3k] SyntaxError cursor shifted if multibyte character is in line.
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2382>
__________________________________
From report at bugs.python.org Tue Mar 18 07:40:22 2008
From: report at bugs.python.org (Jerry Seutter)
Date: Tue, 18 Mar 2008 06:40:22 +0000
Subject: [New-bugs-announce] [issue2383] Remove old XXX comment in stat.py
In-Reply-To: <1205822422.49.0.9184745501.issue2383@psf.upfronthosting.co.za>
Message-ID: <1205822422.49.0.9184745501.issue2383@psf.upfronthosting.co.za>
New submission from Jerry Seutter <jseutter at gmail.com>:
The comment about constants has been unmodified since 1994 (14 years)
and we have yet to support a system that has non-standard constants for
stat(). It can safely be removed.
This patch contains changes to comments only.
----------
components: Library (Lib)
files: stat_remove_stale_comment.patch
keywords: patch
messages: 63900
nosy: jseutter
severity: normal
status: open
title: Remove old XXX comment in stat.py
versions: Python 2.6
Added file: http://bugs.python.org/file9721/stat_remove_stale_comment.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2383>
__________________________________
From report at bugs.python.org Tue Mar 18 08:28:39 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 18 Mar 2008 07:28:39 +0000
Subject: [New-bugs-announce] [issue2384] [Py3k] line number is wrong after
encoding declaration
In-Reply-To: <1205825319.07.0.115749100037.issue2384@psf.upfronthosting.co.za>
Message-ID: <1205825319.07.0.115749100037.issue2384@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:
# This issue inherits from issue2301.
If there is "# coding: ????" is in source code and
coding is neigher utf-8 nor iso-8859-1, line number (tok->lineno)
becomes wrong.
Please look into Parser/tokenizer.c. In this case,
tok->decoding_state becomes STATE_NORMAL, so fp_setreadl
newly opens file but *doesn't* seek to current position.
(Or maybe can we reuse already opened file?)
So
# coding: ascii
# 1
# 2
# 3
raise RuntimeError("a")
# 4
# 5
# 6
outputs
C:\Documents and Settings\WhiteRabbit>py3k ascii.py
Traceback (most recent call last):
File "ascii.py", line 6, in <module>
# 4
RuntimeError: a
[22821 refs]
One line shifted because line number wrongly +1
And
# dummy
# coding: ascii
# 1
# 2
# 3
raise RuntimeError("a")
# 4
# 5
# 6
outputs
C:\Documents and Settings\WhiteRabbit>py3k ascii.py
Traceback (most recent call last):
File "ascii.py", line 8, in <module>
# 5
RuntimeError: a
[22821 refs]
Two lines shifted because line number wrongly +2
----------
components: None
messages: 63905
nosy: ocean-city
severity: normal
status: open
title: [Py3k] line number is wrong after encoding declaration
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2384>
__________________________________
From report at bugs.python.org Tue Mar 18 11:24:34 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 18 Mar 2008 10:24:34 +0000
Subject: [New-bugs-announce] [issue2385] run_setup can fail if the setup
script uses __file__
In-Reply-To: <1205835874.17.0.090976046813.issue2385@psf.upfronthosting.co.za>
Message-ID: <1205835874.17.0.090976046813.issue2385@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
When calling run_setup, the execfile does not set the __file__ global
variable, that is often used in setup.py modules (for instance to load a
text file from the package to be used in the long_description)
This patch adds this global variable so it does not fail.
No test provided (distutils would need a test_core.py).
I could work on some tests, but the previous test_* files I have added
are not in yet, so i'd rather wait for that before proposing new tests
modules.
----------
components: Distutils
files: distutils.core.patch
keywords: patch
messages: 63906
nosy: tarek
severity: normal
status: open
title: run_setup can fail if the setup script uses __file__
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file9724/distutils.core.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2385>
__________________________________
From report at bugs.python.org Tue Mar 18 13:28:04 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 18 Mar 2008 12:28:04 +0000
Subject: [New-bugs-announce] [issue2386] os.strerror missing/HAVE_STRERROR
not defined
In-Reply-To: <1205843284.03.0.546398560804.issue2386@psf.upfronthosting.co.za>
Message-ID: <1205843284.03.0.546398560804.issue2386@psf.upfronthosting.co.za>
New submission from Ralf Schmitt <schmir at gmail.com>:
os.strerror is missing on my 64 bit linux.
HAVE_STRERROR is not defined in pyconfig.h.
This has been broken in r61483.
----------
messages: 63908
nosy: brett.cannon, schmir
severity: normal
status: open
title: os.strerror missing/HAVE_STRERROR not defined
type: compile error
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2386>
__________________________________
From report at bugs.python.org Tue Mar 18 14:27:59 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Tue, 18 Mar 2008 13:27:59 +0000
Subject: [New-bugs-announce] [issue2387] cStringIO and unicode
In-Reply-To: <1205846879.92.0.0083654313835.issue2387@psf.upfronthosting.co.za>
Message-ID: <1205846879.92.0.0083654313835.issue2387@psf.upfronthosting.co.za>
New submission from Virgil Dupras <hsoft at hardcoded.net>:
hsoft-dev:python hsoft$ python
Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from cStringIO import StringIO
>>> StringIO(u'foo').read()
'foo'
>>>
hsoft-dev:python hsoft$ ./python.exe
Python 2.6a1+ (trunk:61515, Mar 18 2008, 13:38:47)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from cStringIO import StringIO
>>> StringIO(u'foo').read()
'f\x00o\x00o\x00'
>>>
The documentation says:
Unlike the memory files implemented by the StringIO module, those provided by
this module are not able to accept Unicode strings that cannot be encoded as
plain ASCII strings.
Attached a patch to test_StringIO.
----------
components: Library (Lib)
files: cStringIO_unicode_test.diff
keywords: patch
messages: 63911
nosy: vdupras
severity: normal
status: open
title: cStringIO and unicode
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9726/cStringIO_unicode_test.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2387>
__________________________________
From report at bugs.python.org Tue Mar 18 15:00:12 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 18 Mar 2008 14:00:12 +0000
Subject: [New-bugs-announce] [issue2388] Compiler warnings when using UCS4
In-Reply-To: <1205848812.38.0.436275134314.issue2388@psf.upfronthosting.co.za>
Message-ID: <1205848812.38.0.436275134314.issue2388@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
Compiling Python with --enable-unicode=ucs4 yields some compiler
warnings for unicodeobject.c:
In file included from Objects/unicodeobject.c:7807:
Objects/stringlib/string_format.h: In function 'do_conversion':
Objects/stringlib/string_format.h:745: warning: format '%c' expects type
'int', but argument 3 has type 'Py_UNICODE'
In file included from Objects/unicodeobject.c:7807:
Objects/stringlib/string_format.h: In function 'do_conversion':
Objects/stringlib/string_format.h:745: warning: format '%c' expects type
'int', but argument 3 has type 'Py_UNICODE'
Objects/unicodeobject.c: In function 'PyUnicodeUCS4_Format':
Objects/unicodeobject.c:8603: warning: format '%c' expects type 'int',
but argument 3 has type 'Py_UNICODE'
Objects/unicodeobject.c: In function 'PyUnicodeUCS4_Format':
Objects/unicodeobject.c:8603: warning: format '%c' expects type 'int',
but argument 3 has type 'Py_UNICODE'
----------
components: Unicode
messages: 63913
nosy: benjamin.peterson
severity: normal
status: open
title: Compiler warnings when using UCS4
type: compile error
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2388>
__________________________________
From report at bugs.python.org Tue Mar 18 15:38:12 2008
From: report at bugs.python.org (=?utf-8?q?Hrvoje_Nik=C5=A1i=C4=87?=)
Date: Tue, 18 Mar 2008 14:38:12 +0000
Subject: [New-bugs-announce] [issue2389] Array pickling exposes internal
memory representation of elements
In-Reply-To: <1205851091.96.0.575523128038.issue2389@psf.upfronthosting.co.za>
Message-ID: <1205851091.96.0.575523128038.issue2389@psf.upfronthosting.co.za>
New submission from Hrvoje Nik?i? <hniksic at gmail.com>:
It would seem that pickling arrays directly exposes the underlying
machine words, making the pickle non-portable to platforms with
different layout of array elements. The guts of array.__reduce__ look
like this:
if (array->ob_size > 0) {
result = Py_BuildValue("O(cs#)O",
array->ob_type,
array->ob_descr->typecode,
array->ob_item,
array->ob_size * array->ob_descr->itemsize,
dict);
}
The byte string that is pickled is directly created from the array's
contents. Unpickling calls array_new which in turn calls
array_fromstring, which ends up memcpying the string data to the new array.
As far as I can tell, array pickles created on one platform cannot be
unpickled on a platform with different endianness (in case of integer
arrays), wchar_t size (in case of unicode arrays) or floating-point
representation (rare in practice, but possible). If pickles are
supposed to be platform-independent, this should be fixed.
Maybe the "typecode" field when used with the constructor could be
augmented to include information about the elements, such as endianness
and floating-point format. Or we should simply punt and pickle the
array as a list of Python objects that comprise it...?
----------
components: Extension Modules
messages: 63915
nosy: hniksic
severity: normal
status: open
title: Array pickling exposes internal memory representation of elements
type: behavior
versions: Python 2.5, Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2389>
__________________________________
From report at bugs.python.org Tue Mar 18 16:38:27 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 18 Mar 2008 15:38:27 +0000
Subject: [New-bugs-announce] [issue2390] Merge 2.6 ACKS with 3.0 ACKS
In-Reply-To: <1205854707.75.0.657591820184.issue2390@psf.upfronthosting.co.za>
Message-ID: <1205854707.75.0.657591820184.issue2390@psf.upfronthosting.co.za>
New submission from Guido van Rossum <guido at python.org>:
Due to blocked merges etc. I expect that some names appearing in the 2.6
ACKS file aren't in the 3.0 ACKS file. And possible the other way
around where backports are involved. I like this file to be as
inclusive as possible (hey, my dad is in it :-) so perhaps the best
approach is to just make them both the union of what they currently are.
----------
keywords: easy
messages: 63921
nosy: gvanrossum
severity: normal
status: open
title: Merge 2.6 ACKS with 3.0 ACKS
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2390>
__________________________________
From report at bugs.python.org Tue Mar 18 16:52:00 2008
From: report at bugs.python.org (Sean Reifschneider)
Date: Tue, 18 Mar 2008 15:52:00 +0000
Subject: [New-bugs-announce] [issue2392] Sean is testing tracker bug.
In-Reply-To: <1205855520.08.0.383762884514.issue2392@psf.upfronthosting.co.za>
Message-ID: <1205855520.08.0.383762884514.issue2392@psf.upfronthosting.co.za>
New submission from Sean Reifschneider <jafo at tummy.com>:
Foo
----------
components: Demos and Tools
messages: 63922
nosy: jafo
severity: normal
status: open
title: Sean is testing tracker bug.
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2392>
__________________________________
From report at bugs.python.org Tue Mar 18 16:54:58 2008
From: report at bugs.python.org (Travis Oliphant)
Date: Tue, 18 Mar 2008 15:54:58 +0000
Subject: [New-bugs-announce] [issue2393] Backport buffer interface in Python
3.0 to Python 2.6
In-Reply-To: <1205855698.81.0.786586368885.issue2393@psf.upfronthosting.co.za>
Message-ID: <1205855698.81.0.786586368885.issue2393@psf.upfronthosting.co.za>
New submission from Travis Oliphant <oliphant at enthought.com>:
Some (or all) of PEP 3118 should be backported to Python 2.6 because it
does not require backward-incompatible changes and can assist in the
transition to 3.0.
This issue is to be sure that the buffer-interface portion of PEP 3118
is backported. This does not mean that any objects in Python will
necessarily use the new buffer interface. Any such changes would be
entered as separate issues.
----------
components: Interpreter Core
messages: 63923
nosy: teoliphant
severity: normal
status: open
title: Backport buffer interface in Python 3.0 to Python 2.6
type: feature request
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2393>
__________________________________
From report at bugs.python.org Tue Mar 18 16:59:48 2008
From: report at bugs.python.org (Travis Oliphant)
Date: Tue, 18 Mar 2008 15:59:48 +0000
Subject: [New-bugs-announce] [issue2394] Finish the memoryview object
implementation
In-Reply-To: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za>
Message-ID: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za>
New submission from Travis Oliphant <oliphant at enthought.com>:
The memoryview object in Python 3.0 needs to be finished. There are a
few methods that are not complete. In particular, the __getitem__ and
__setitem__ functionality needs to be finished as well as the tolist()
method.
----------
components: Interpreter Core
messages: 63928
nosy: teoliphant
severity: normal
status: open
title: Finish the memoryview object implementation
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2394>
__________________________________
From report at bugs.python.org Tue Mar 18 17:01:00 2008
From: report at bugs.python.org (Travis Oliphant)
Date: Tue, 18 Mar 2008 16:01:00 +0000
Subject: [New-bugs-announce] [issue2395] struct module changes of PEP 3118
In-Reply-To: <1205856060.67.0.357097820084.issue2395@psf.upfronthosting.co.za>
Message-ID: <1205856060.67.0.357097820084.issue2395@psf.upfronthosting.co.za>
New submission from Travis Oliphant <oliphant at enthought.com>:
The additions to the struct module spelled out in PEP 3118 need to be
implemented for Python 3.0
----------
components: Library (Lib)
messages: 63929
nosy: teoliphant
severity: normal
status: open
title: struct module changes of PEP 3118
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2395>
__________________________________
From report at bugs.python.org Tue Mar 18 17:02:43 2008
From: report at bugs.python.org (Travis Oliphant)
Date: Tue, 18 Mar 2008 16:02:43 +0000
Subject: [New-bugs-announce] [issue2396] Backport memoryview object to
Python 2.6
In-Reply-To: <1205856163.49.0.847674946563.issue2396@psf.upfronthosting.co.za>
Message-ID: <1205856163.49.0.847674946563.issue2396@psf.upfronthosting.co.za>
New submission from Travis Oliphant <oliphant at enthought.com>:
The memoryview object in Python 2.6 would help in the transition to
Python 3.0. It is a lower-priority and could wait until 2.7 if it
doesn't get finished.
----------
components: Interpreter Core
messages: 63930
nosy: teoliphant
severity: normal
status: open
title: Backport memoryview object to Python 2.6
type: feature request
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2396>
__________________________________
From report at bugs.python.org Tue Mar 18 17:04:59 2008
From: report at bugs.python.org (Travis Oliphant)
Date: Tue, 18 Mar 2008 16:04:59 +0000
Subject: [New-bugs-announce] [issue2397] Backport 3.0 struct module changes
to 2.6
In-Reply-To: <1205856299.38.0.249134952512.issue2397@psf.upfronthosting.co.za>
Message-ID: <1205856299.38.0.249134952512.issue2397@psf.upfronthosting.co.za>
New submission from Travis Oliphant <oliphant at enthought.com>:
The changes to the struct module in PEP 3118 should be backported to 2.6
as it is backward compatible and would smooth the transition to 3.0. It
is lower priority and could wait until 2.7
----------
components: Library (Lib)
messages: 63931
nosy: teoliphant
severity: normal
status: open
title: Backport 3.0 struct module changes to 2.6
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2397>
__________________________________
From report at bugs.python.org Tue Mar 18 17:16:40 2008
From: report at bugs.python.org (Andy Balaam)
Date: Tue, 18 Mar 2008 16:16:40 +0000
Subject: [New-bugs-announce] [issue2398] test_errno fails with unexpected
error value EREMOTEIO
In-Reply-To: <1205857000.67.0.280910583762.issue2398@psf.upfronthosting.co.za>
Message-ID: <1205857000.67.0.280910583762.issue2398@psf.upfronthosting.co.za>
New submission from Andy Balaam <mail at artificialworlds.net>:
Running test_errno on my 32-bit Ubuntu Gutsy machine gives me this:
$ ./python Lib/test/test_errno.py
test_for_improper_attributes (__main__.ErrnoAttributeTests) ... FAIL
test_using_errorcode (__main__.ErrnoAttributeTests) ... ok
test_attributes_in_errorcode (__main__.ErrorcodeTests) ... ok
======================================================================
FAIL: test_for_improper_attributes (__main__.ErrnoAttributeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "Lib/test/test_errno.py", line 46, in test_for_improper_attributes
"%s is an unexpected error value" % attribute)
AssertionError: EREMOTEIO is an unexpected error value
----------------------------------------------------------------------
Ran 3 tests in 0.001s
FAILED (failures=1)
Traceback (most recent call last):
File "Lib/test/test_errno.py", line 68, in <module>
test_main()
File "Lib/test/test_errno.py", line 64, in test_main
test_support.run_unittest(ErrnoAttributeTests, ErrorcodeTests)
File "/home/andy/cvs/python/Lib/test/test_support.py", line 573, in
run_unittest
_run_suite(suite)
File "/home/andy/cvs/python/Lib/test/test_support.py", line 556, in
_run_suite
raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
File "Lib/test/test_errno.py", line 46, in test_for_improper_attributes
"%s is an unexpected error value" % attribute)
AssertionError: EREMOTEIO is an unexpected error value
I've attached a patch which changes test_errno.py so that its list of
expected errors exactly matches the possible errors listed in
Modules/errnomodule.c in the latest SVN trunk.
I don't know whether this is the right solution, but the patch is there
if it is :)
Apologies if I've misunderstood something, or formatted the patch wrong
etc. This is my first Python patch.
----------
components: Tests
files: add_more_error_values_to_test_errno.patch
keywords: patch
messages: 63934
nosy: andybalaam
severity: normal
status: open
title: test_errno fails with unexpected error value EREMOTEIO
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file9730/add_more_error_values_to_test_errno.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2398>
__________________________________
From report at bugs.python.org Tue Mar 18 17:45:38 2008
From: report at bugs.python.org (Travis Oliphant)
Date: Tue, 18 Mar 2008 16:45:38 +0000
Subject: [New-bugs-announce] [issue2399] Patches for Tools/msi
In-Reply-To: <1205858738.04.0.681248681608.issue2399@psf.upfronthosting.co.za>
Message-ID: <1205858738.04.0.681248681608.issue2399@psf.upfronthosting.co.za>
New submission from Travis Oliphant <oliphant at enthought.com>:
The attached patches add the following features to MSI building:
* allow splitting into multiple CABs
* prevent problem when data-base commits grow beyond a certain number
* fix to handle all file names
* change the way unique keys are created in the File and Directory
tables by adding a globally-incrementing number to the file name (unless
it is a keyfile. This prevents the repeated searching of a large set
(important when you are packaing 47k files...)
* fix so that the file id that goes into the HashFileTable is never
larger than 72 characters.
----------
components: Windows
files: msilib_patch.diff
keywords: patch
messages: 63940
nosy: teoliphant
severity: normal
status: open
title: Patches for Tools/msi
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9733/msilib_patch.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2399>
__________________________________
From report at bugs.python.org Tue Mar 18 17:53:45 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Tue, 18 Mar 2008 16:53:45 +0000
Subject: [New-bugs-announce] [issue2400] from .foo import * should work
In-Reply-To: <1205859225.17.0.832455218755.issue2400@psf.upfronthosting.co.za>
Message-ID: <1205859225.17.0.832455218755.issue2400@psf.upfronthosting.co.za>
New submission from Neal Norwitz <nnorwitz at gmail.com>:
Explicit relative imports using from .foo import * should work.
http://mail.python.org/pipermail/python-3000/2008-March/012564.html
----------
components: Interpreter Core
messages: 63942
nosy: nnorwitz
priority: critical
severity: normal
status: open
title: from .foo import * should work
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2400>
__________________________________
From report at bugs.python.org Tue Mar 18 20:11:31 2008
From: report at bugs.python.org (Sean Reifschneider)
Date: Tue, 18 Mar 2008 19:11:31 +0000
Subject: [New-bugs-announce] [issue2401] Solaris: ctypes tests being skipped
despite following #1516
In-Reply-To: <1205867491.87.0.489555231909.issue2401@psf.upfronthosting.co.za>
Message-ID: <1205867491.87.0.489555231909.issue2401@psf.upfronthosting.co.za>
New submission from Sean Reifschneider <jafo at tummy.com>:
This is a break-out of the multi-issue #2048.
Original poster Atro Tossavainen (atossava) reports:Building and testing
on Solaris 8 on SPARC with Sun compilers:
cc: Sun C 5.8 2005/10/13
CC: Sun C++ 5.8 2005/10/13
281 tests OK.
40 tests skipped:
test_aepack test_al test_applesingle test_bsddb test_bsddb185
test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk
test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_ctypes
test_curses test_gdbm test_gl test_imgfile test_linuxaudiodev
test_macfs test_macostools test_nis test_normalization
test_ossaudiodev test_pep277 test_plistlib test_scriptpackages
test_socket_ssl test_socketserver test_sqlite test_startfile
test_sunaudiodev test_tcl test_timeout test_unicode_file
test_urllib2net test_urllibnet test_winreg test_winsound
test_zipfile64
4 skips unexpected on sunos5:
test_tcl test_sunaudiodev test_ctypes test_nis
...
test_tcl skipped -- No module named _tkinter
...
I have applied the _ctypes patch in #1516, however. What gives?
----------
assignee: loewis
components: Build
messages: 63965
nosy: atossava, jafo, loewis
priority: normal
severity: normal
status: open
title: Solaris: ctypes tests being skipped despite following #1516
type: compile error
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2401>
__________________________________
From report at bugs.python.org Tue Mar 18 20:42:58 2008
From: report at bugs.python.org (Jerry Seutter)
Date: Tue, 18 Mar 2008 19:42:58 +0000
Subject: [New-bugs-announce] [issue2403] Add figleaf coverage metrics
In-Reply-To: <1205869378.43.0.216108511876.issue2403@psf.upfronthosting.co.za>
Message-ID: <1205869378.43.0.216108511876.issue2403@psf.upfronthosting.co.za>
New submission from Jerry Seutter <jseutter at gmail.com>:
This issue adds support for figleaf unit test coverage information. The
diffs apply against trunk
----------
components: Tests
files: README.patch
keywords: patch, patch
messages: 63975
nosy: jseutter
priority: low
severity: normal
status: open
title: Add figleaf coverage metrics
versions: Python 2.6
Added file: http://bugs.python.org/file9737/README.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2403>
__________________________________
From report at bugs.python.org Tue Mar 18 20:53:07 2008
From: report at bugs.python.org (Travis Oliphant)
Date: Tue, 18 Mar 2008 19:53:07 +0000
Subject: [New-bugs-announce] [issue2404] Backport ctypes support for buffer
protocol to Python 2.6 (ref issue1971)
In-Reply-To: <1205869987.72.0.778621175658.issue2404@psf.upfronthosting.co.za>
Message-ID: <1205869987.72.0.778621175658.issue2404@psf.upfronthosting.co.za>
New submission from Travis Oliphant <oliphant at enthought.com>:
The ctypes object will support the PEP 3118 buffer protocol. This
support can be back-ported to Python 2.6
----------
messages: 63977
nosy: teoliphant
severity: normal
status: open
title: Backport ctypes support for buffer protocol to Python 2.6 (ref issue1971)
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2404>
__________________________________
From report at bugs.python.org Tue Mar 18 21:09:29 2008
From: report at bugs.python.org (Trent Nelson)
Date: Tue, 18 Mar 2008 20:09:29 +0000
Subject: [New-bugs-announce] [issue2405] Drop w9xpopen and all dependencies
In-Reply-To: <1205870969.55.0.774025556957.issue2405@psf.upfronthosting.co.za>
Message-ID: <1205870969.55.0.774025556957.issue2405@psf.upfronthosting.co.za>
New submission from Trent Nelson <tnelson at onresolve.com>:
Python 2.6+ drops support for Windows 95/98, which removes the need for
w9xpopen. Get rid of the module and all dependencies (such as in the .msi).
----------
assignee: Trent.Nelson
components: Build
messages: 63978
nosy: Trent.Nelson
severity: normal
status: open
title: Drop w9xpopen and all dependencies
type: feature request
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2405>
__________________________________
From report at bugs.python.org Tue Mar 18 21:29:43 2008
From: report at bugs.python.org (M.-A. DARCHE)
Date: Tue, 18 Mar 2008 20:29:43 +0000
Subject: [New-bugs-announce] [issue2406] Improvement suggestions for the
gzip module documentation
In-Reply-To: <1205872183.57.0.209526870399.issue2406@psf.upfronthosting.co.za>
Message-ID: <1205872183.57.0.209526870399.issue2406@psf.upfronthosting.co.za>
New submission from M.-A. DARCHE <madarche at users.sourceforge.net>:
The documentation for the gzip python module as found at
http://docs.python.org/lib/module-gzip.html could be improved by code
examples. Those examples are really lacking.
Here below are the code snippets I propose. This is inspired by
http://xahlee.org/perl-python/python_doc_gzip.html but done with respect
and with another useful (I think) example.
# Example of how to decompress a file
import gzip
file_obj = gzip.GzipFile('/home/joe/file.txt.gz', 'rb');
file_content = file_obj.read()
file_obj.close()
# Example of how to create a compressed GZIP file
import gzip
file_content = "Lots of content here"
file_obj = gzip.GzipFile('/home/joe/file.txt.gz', 'wb');
file_obj.write(file_content)
file_content.close()
# Example of how to compress an existing file
import shutil
import gzip
file_obj_in = file('/home/joe/file.txt', 'rb')
file_obj_out = gzip.GzipFile('/home/joe/file.txt.gz', 'wb');
shutil.copyfileobj(file_obj_in, file_obj_out)
file_obj_out.close()
Best regards.
----------
assignee: georg.brandl
components: Documentation
messages: 63981
nosy: georg.brandl, madarche
severity: normal
status: open
title: Improvement suggestions for the gzip module documentation
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2406>
__________________________________
From report at bugs.python.org Tue Mar 18 21:56:44 2008
From: report at bugs.python.org (Jerry Seutter)
Date: Tue, 18 Mar 2008 20:56:44 +0000
Subject: [New-bugs-announce] [issue2407] warnings.filterwarnings() not
isolated between tests
In-Reply-To: <1205873804.14.0.137963727485.issue2407@psf.upfronthosting.co.za>
Message-ID: <1205873804.14.0.137963727485.issue2407@psf.upfronthosting.co.za>
New submission from Jerry Seutter <jseutter at gmail.com>:
Some tests were not cleaning up warning filters. Fixed the problem by
making regrtest.py restore default filters before each module is executed.
This exposed other errors which are also fixed in the patch.
The patch only affects test files.
----------
components: Tests
files: warnings_fix.patch
keywords: patch, patch
messages: 63984
nosy: jseutter
priority: low
severity: normal
status: open
title: warnings.filterwarnings() not isolated between tests
versions: Python 2.6
Added file: http://bugs.python.org/file9739/warnings_fix.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2407>
__________________________________
From report at bugs.python.org Tue Mar 18 22:09:30 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 18 Mar 2008 21:09:30 +0000
Subject: [New-bugs-announce] [issue2408] types should expose cell object
In-Reply-To: <1205874570.2.0.410256172712.issue2408@psf.upfronthosting.co.za>
Message-ID: <1205874570.2.0.410256172712.issue2408@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
types currently exposes all types used by the interpreter except cell
objects. This patch adds support for that and adds to the docs. I
couldn't find a way to access the cell type through Python, so I added
it to the _types module.
----------
components: Interpreter Core, Library (Lib)
files: expose_cell.patch
keywords: patch
messages: 63988
nosy: benjamin.peterson
severity: normal
status: open
title: types should expose cell object
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file9740/expose_cell.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2408>
__________________________________
From report at bugs.python.org Tue Mar 18 22:22:28 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Tue, 18 Mar 2008 21:22:28 +0000
Subject: [New-bugs-announce] [issue2409] regrtest should not just skip
imports that fail
In-Reply-To: <1205875348.54.0.487257679211.issue2409@psf.upfronthosting.co.za>
Message-ID: <1205875348.54.0.487257679211.issue2409@psf.upfronthosting.co.za>
New submission from Neal Norwitz <nnorwitz at gmail.com>:
Guido mentioned this in python-3000-checkins. I agree the problem
should be fixed.
"""
I think the automatic skip on ImportError is harmful.
We should add a helper function to test_support so that you can write
foobar = test_support.import_optional('foobar')
and it will skip the test if foobar cannot be imported; all other
failing imports should cause the test to *fail*.
This should be an easy two-part task.
"""
----------
components: Tests
messages: 63992
nosy: nnorwitz
priority: high
severity: normal
status: open
title: regrtest should not just skip imports that fail
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2409>
__________________________________
From report at bugs.python.org Tue Mar 18 22:27:56 2008
From: report at bugs.python.org (Bruce Frederiksen)
Date: Tue, 18 Mar 2008 21:27:56 +0000
Subject: [New-bugs-announce] [issue2410] absolute import doesn't work for
standard python modules
In-Reply-To: <1205875676.38.0.76467063797.issue2410@psf.upfronthosting.co.za>
Message-ID: <1205875676.38.0.76467063797.issue2410@psf.upfronthosting.co.za>
New submission from Bruce Frederiksen <dangyogi at gmail.com>:
Try this to reproduce error:
$ mkdir -p test/email
$ cd test
$ touch __init__.py email/__init__.py
$ cat <<! > foo.py
from __future__ import absolute_import
import smtplib
!
$ python
>>> import foo
...
File "/usr/lib/python2.6/smtplib.py", line 46, in <module>
import email.utils
ImportError: No module named utils
If you rename the email subdirectory, it will find email.utils where it
should find it.
Strangely, this doesn't happen if you have an 'os' subdirectory and try
to import shlex, which does: import os.path ??
----------
components: Interpreter Core
messages: 63993
nosy: dangyogi
severity: normal
status: open
title: absolute import doesn't work for standard python modules
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2410>
__________________________________
From report at bugs.python.org Wed Mar 19 00:40:20 2008
From: report at bugs.python.org (Michael Bishop)
Date: Tue, 18 Mar 2008 23:40:20 +0000
Subject: [New-bugs-announce] [issue2411] test_nis.py fails if NIS is not
configured or used
In-Reply-To: <1205883619.98.0.282650884339.issue2411@psf.upfronthosting.co.za>
Message-ID: <1205883619.98.0.282650884339.issue2411@psf.upfronthosting.co.za>
New submission from Michael Bishop <michaelsplace at gmail.com>:
Instead of failing the test which is inaccurate, the test will return
that it was skipped and what the msg is.
----------
components: Tests
files: test_nis.patch
keywords: patch
messages: 64016
nosy: MichaelBishop
severity: normal
status: open
title: test_nis.py fails if NIS is not configured or used
type: behavior
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9750/test_nis.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2411>
__________________________________
From report at bugs.python.org Wed Mar 19 00:42:18 2008
From: report at bugs.python.org (Eric Smith)
Date: Tue, 18 Mar 2008 23:42:18 +0000
Subject: [New-bugs-announce] [issue2412] Check 2to3 for support of print
function.
In-Reply-To: <1205883738.38.0.0352891857591.issue2412@psf.upfronthosting.co.za>
Message-ID: <1205883738.38.0.0352891857591.issue2412@psf.upfronthosting.co.za>
New submission from Eric Smith <eric at trueblade.com>:
Issue 1633807 is a backport of the print function to 2.6, using a
__future__ import. Once it is committed, we need to ensure that 2to3
does the right thing (namely, nothing) with print functions in modules
that have the __future__ import.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 64017
nosy: collinwinter, eric.smith
priority: normal
severity: normal
status: open
title: Check 2to3 for support of print function.
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2412>
__________________________________
From report at bugs.python.org Wed Mar 19 02:24:55 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 19 Mar 2008 01:24:55 +0000
Subject: [New-bugs-announce] [issue2413] os.strerror does not check for out
of range argument
In-Reply-To: <1205889895.08.0.168690164912.issue2413@psf.upfronthosting.co.za>
Message-ID: <1205889895.08.0.168690164912.issue2413@psf.upfronthosting.co.za>
New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:
ISO/ANSI C strerror indicates out of range error by setting errno, but
existing code incorrectly checks for NULL return value. Attached patch
(tested n Mac OS X) makes os.strerror raise ValueError for out of range
argument.
----------
files: posix-strerror.diff
keywords: patch
messages: 64023
nosy: belopolsky
severity: normal
status: open
title: os.strerror does not check for out of range argument
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9754/posix-strerror.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2413>
__________________________________
From report at bugs.python.org Wed Mar 19 03:22:32 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 19 Mar 2008 02:22:32 +0000
Subject: [New-bugs-announce] [issue2414] Fix implicit relative imports
In-Reply-To: <1205893352.87.0.586984604405.issue2414@psf.upfronthosting.co.za>
Message-ID: <1205893352.87.0.586984604405.issue2414@psf.upfronthosting.co.za>
New submission from Martin v. L?wis <martin at v.loewis.de>:
There should be a fixer that changes
from foo import bar
into
from .foo import bar
if the import occurs in a package and foo is in the very same package.
Likewise, it should change
import foo
to
from . import foo
----------
assignee: David Wolever
components: 2to3 (2.x to 3.0 conversion tool)
messages: 64026
nosy: David Wolever, loewis
severity: normal
status: open
title: Fix implicit relative imports
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2414>
__________________________________
From report at bugs.python.org Wed Mar 19 04:04:14 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 19 Mar 2008 03:04:14 +0000
Subject: [New-bugs-announce] [issue2415] bytes() should respect __bytes__
In-Reply-To: <1205895854.9.0.402459814747.issue2415@psf.upfronthosting.co.za>
Message-ID: <1205895854.9.0.402459814747.issue2415@psf.upfronthosting.co.za>
New submission from Barry A. Warsaw <barry at python.org>:
The bytes() builtin should respect an __bytes__() converter if it exists.
E.g. instead of
>>> class Foo:
... def __bytes__(self): return b'foo'
...
>>> bytes(Foo())
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'Foo' object is not iterable
>>>
bytes(Foo()) should return b'foo'
Here's one use case. email.header.Header instances represent email headers
(naturally) that conceptually are bytes, but also have a string
representation. Say for example, a Subject header comes across the wire in
RFC 2033 encoded utf-8. The unicode representation would be the value
of the
header decoded according to the RFC. The bytes representation would be the
raw bytes seen on the wire.
The most natural way to retrieve each representation would be
>>> header = msg['subject']
>>> str(header)
'some string with non-ascii'
>>> bytes(header)
b'the rfc 2033 encoded raw header value'
----------
components: Interpreter Core
messages: 64027
nosy: barry
priority: normal
severity: normal
status: open
title: bytes() should respect __bytes__
type: feature request
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2415>
__________________________________
From report at bugs.python.org Wed Mar 19 04:53:30 2008
From: report at bugs.python.org (Eric Smith)
Date: Wed, 19 Mar 2008 03:53:30 +0000
Subject: [New-bugs-announce] [issue2416] % string formatting does not
support %b
In-Reply-To: <1205898810.27.0.827801711663.issue2416@psf.upfronthosting.co.za>
Message-ID: <1205898810.27.0.827801711663.issue2416@psf.upfronthosting.co.za>
New submission from Eric Smith <eric at trueblade.com>:
PEP 3127 "Integer Literal Support and Syntax" says that % string
formatting should support %b. This needs to be added to both 2.6 and
3.0. It needs to support the forms %b and %#b.
----------
assignee: eric.smith
components: Interpreter Core
messages: 64031
nosy: eric.smith
priority: normal
severity: normal
status: open
title: % string formatting does not support %b
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2416>
__________________________________
From report at bugs.python.org Wed Mar 19 05:45:57 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 19 Mar 2008 04:45:57 +0000
Subject: [New-bugs-announce] [issue2417] Integer floor division (//): small
int check omitted
In-Reply-To: <1205901957.73.0.828809494878.issue2417@psf.upfronthosting.co.za>
Message-ID: <1205901957.73.0.828809494878.issue2417@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
Python 3.0a3 (r30a3:61161, Mar 1 2008, 22:51:17) [MSC v.1500 32 bit
(Intel)] on win32
>>> a,b=1,1//1
>>> a is b
False
IDLE 3.0a3
>>> a,b=1,1//1
>>> a is b
True
ditto for 2.5.2 interpreter
On c.l.p, Duncan Booth wrote
I've had a look to see why this happens: long division (and in Python 3
all integers are longs) allocates a new long to hold the result of the
division so it will never use one of the preallocated 'small int' values.
That maybe explains the change from 2.5 but not the difference from
IDLE. More important, the small int checks are present with the other
operations:
>>> 1*1 is 1
True
>>> 1+1 is 2
True
>>> 1-1 is 0
True
>>> 1**1 is 1
True
so the omission with // is plausibly a bug.
----------
components: Interpreter Core
messages: 64037
nosy: tjreedy
severity: normal
status: open
title: Integer floor division (//): small int check omitted
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2417>
__________________________________
From report at bugs.python.org Wed Mar 19 07:26:23 2008
From: report at bugs.python.org (Vincent Manis)
Date: Wed, 19 Mar 2008 06:26:23 +0000
Subject: [New-bugs-announce] [issue2418] Incorrect LaTeX generated (Python
2.6a1)
Message-ID: <1205907983.57.0.995961213991.issue2418@psf.upfronthosting.co.za>
Changes by Vincent Manis <vmanis at telus.net>:
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
nosy: georg.brandl, vmanis1
severity: normal
status: open
title: Incorrect LaTeX generated (Python 2.6a1)
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2418>
__________________________________
From report at bugs.python.org Wed Mar 19 08:20:54 2008
From: report at bugs.python.org (Michael Bishop)
Date: Wed, 19 Mar 2008 07:20:54 +0000
Subject: [New-bugs-announce] [issue2419] Remove all IRIX dependant modules
from aifc module
In-Reply-To: <1205911254.5.0.0435748947591.issue2419@psf.upfronthosting.co.za>
Message-ID: <1205911254.5.0.0435748947591.issue2419@psf.upfronthosting.co.za>
New submission from Michael Bishop <michaelsplace at gmail.com>:
Docs say that there are IRIX only modules which are dependant on the cl
module which has been removed from Py3K.
----------
components: Library (Lib)
messages: 64045
nosy: MichaelBishop
severity: normal
status: open
title: Remove all IRIX dependant modules from aifc module
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2419>
__________________________________
From report at bugs.python.org Wed Mar 19 09:50:47 2008
From: report at bugs.python.org (Leszek Dubiel)
Date: Wed, 19 Mar 2008 08:50:47 +0000
Subject: [New-bugs-announce] [issue2420] Faq 4.28 -- Trailing comas
In-Reply-To: <1205916647.4.0.701365283019.issue2420@psf.upfronthosting.co.za>
Message-ID: <1205916647.4.0.701365283019.issue2420@psf.upfronthosting.co.za>
New submission from Leszek Dubiel <leszek at dubiel.pl>:
This is after discussion on python-ideas:
http://mail.python.org/pipermail/python-ideas/2008-March/001488.html
I would suggest to add question 4.28 to faq. Everybody who learns Python
reads that and will not ask questions about "one-element tuples". I have
compiled answer from responses to my last question about one-element tuple.
Question: Why python allows to put comma at the end of list? This looks
ugly and seems to break common rules...
Answer: There are may reasons that follow.
1. If you defined multiline dictionary
d = {
"A": [1, 5],
"B": [6, 7], # last trailing comma is optional but good style
}
it would be easier to add more elements, because you don't have to care
about colons -- you always put colon at the end of line and don't have
to reedit other lines. It eases sorting of such lines too -- just cut
line and paste above.
2. Missing comma can lead to errors that are hard to diagnose. For example:
x = [
"fee",
"fie"
"foo",
"fum"
]
contains tree elements "fee", "fiefoo" and "fum". So if programmer puts
comma always at the end of line he saves lots of trouble in a future.
2. Nearly all reasonable programming languages (C, C++, Java) allow for an
extra trailing comma in a comma-delimited list, for consistency and to
make programmatic code generation easier. So for example [1,2,3,] is
intentionally correct.
3. Creating one-element tuples using tuple(['hello']) syntax is much much
slower (a factor of 20x here) then writing just ('hello', ). Trailing
commas
when you only have one item are how python tuple syntax is defined
allowing them to use commas instead of needing other tokens. If python
didn't allow comma at the end of tuple, you will have to use such slow
syntax.
4. The same rule applies to other type of lists, where delimiter can occur
at the end. For example both strings "alfa\nbeta\n" and "alfa\nbeta" contain
two lines.
Sources:
-- http://mail.python.org/pipermail/python-list/2003-October/231419.html
-- http://mail.python.org/pipermail/python-ideas/2008-March/001478.html
-- http://mail.python.org/pipermail/python-ideas/2008-March/001475.html
----------
assignee: georg.brandl
components: Documentation
messages: 64050
nosy: dubiel, georg.brandl
severity: normal
status: open
title: Faq 4.28 -- Trailing comas
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2420>
__________________________________
From report at bugs.python.org Wed Mar 19 11:11:49 2008
From: report at bugs.python.org (Tim Golden)
Date: Wed, 19 Mar 2008 10:11:49 +0000
Subject: [New-bugs-announce] [issue2421] doc\make.bat fails for htmlhelp
because of hardcoded filename
In-Reply-To: <1205921508.97.0.101247618577.issue2421@psf.upfronthosting.co.za>
Message-ID: <1205921508.97.0.101247618577.issue2421@psf.upfronthosting.co.za>
New submission from Tim Golden <mail at timgolden.me.uk>:
doc\make.bat, used to build the docs under Windows, retains the
hardcoded pydoc.hhp name when building htmlhelp. Now that the help files
are built as <release>.chm this file no longer exists and the build fails.
The attached patch to make.bat builds the htmlhelp from within a
temporary Python session which picks the correct filename up from conf.py.
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: doc-make-r61620.patch
keywords: patch
messages: 64051
nosy: georg.brandl, tim.golden
severity: normal
status: open
title: doc\make.bat fails for htmlhelp because of hardcoded filename
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9764/doc-make-r61620.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2421>
__________________________________
From report at bugs.python.org Wed Mar 19 12:11:09 2008
From: report at bugs.python.org (James Henstridge)
Date: Wed, 19 Mar 2008 11:11:09 +0000
Subject: [New-bugs-announce] [issue2422] Automatically disable pymalloc when
running under valgrind
In-Reply-To: <1205925069.41.0.603933745456.issue2422@psf.upfronthosting.co.za>
Message-ID: <1205925069.41.0.603933745456.issue2422@psf.upfronthosting.co.za>
New submission from James Henstridge <james at jamesh.id.au>:
When I want to use valgrind to check for leaks in a Python program (or
test suite), I generally want pymalloc disabled. When not running
valgrind I generally want it enabled.
Attached is a patch that automatically bypasses the pymalloc code when
running under valgrind but leaves it enabled overwise.
It is controlled by a WITH_VALGRIND #define, but I haven't updated the
configure script to allow turning it on. I also haven't done much in
the way of profiling to see what the overhead is when not running under
valgrind.
----------
components: Interpreter Core
files: disable-pymalloc-on-valgrind.patch
keywords: patch
messages: 64052
nosy: jamesh
severity: normal
status: open
title: Automatically disable pymalloc when running under valgrind
type: feature request
versions: Python 2.5
Added file: http://bugs.python.org/file9765/disable-pymalloc-on-valgrind.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2422>
__________________________________
From report at bugs.python.org Wed Mar 19 15:50:49 2008
From: report at bugs.python.org (Jerry Seutter)
Date: Wed, 19 Mar 2008 14:50:49 +0000
Subject: [New-bugs-announce] [issue2423] test_smtplib.py no longer butt slow
In-Reply-To: <1205938249.95.0.187788140387.issue2423@psf.upfronthosting.co.za>
Message-ID: <1205938249.95.0.187788140387.issue2423@psf.upfronthosting.co.za>
New submission from Jerry Seutter <jseutter at gmail.com>:
Changes only affect test files.
test_smtplib.py before: 39.7s
test_smtplib.py after: 0.8s
socket.getfqdn() calls were causing all the slowness. Added a
mock_socket.py file to handle some tests. For other tests that tested
both server side and client side of the smtp libraries, mocked out
socket.getfqdn() only.
----------
components: Tests
files: test_smtplib_speedup.patch
keywords: patch, patch
messages: 64058
nosy: jseutter
priority: low
severity: normal
status: open
title: test_smtplib.py no longer butt slow
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file9766/test_smtplib_speedup.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2423>
__________________________________
From report at bugs.python.org Wed Mar 19 17:55:27 2008
From: report at bugs.python.org (Brad Allen)
Date: Wed, 19 Mar 2008 16:55:27 +0000
Subject: [New-bugs-announce] [issue2424] Logging module hides user code
errors (bare except)
In-Reply-To: <1205945727.95.0.106408430921.issue2424@psf.upfronthosting.co.za>
Message-ID: <1205945727.95.0.106408430921.issue2424@psf.upfronthosting.co.za>
New submission from Brad Allen <brad at allendev.com>:
The logging module contains several bare except statements. It's
understandable that the logging module should be completely silent, but
in the case of logging.config, the bare except can make it very
difficult to identify when there is a problem with a customer handler or
even with configuration.
These are the offending lines (lines 133-134):
except: #if an error occurs when instantiating a handler, too bad
pass #this could happen e.g. because of lack of privileges
Maybe this should only catch OSError, so that other problems will
generate a failure at this point and show the correct traceback. My
experience is that there is usually a failure anyway when there is a
configuration problem, but the error is usually misleading.
By the way, exceptions generated here seem to mainly occur when a Python
script is first starting up, as it involves the initial configuration. I
am not convinced that the logging module should be silent at that stage.
----------
components: Library (Lib)
messages: 64069
nosy: bradallen
severity: normal
status: open
title: Logging module hides user code errors (bare except)
type: behavior
versions: Python 2.4
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2424>
__________________________________
From report at bugs.python.org Wed Mar 19 18:18:33 2008
From: report at bugs.python.org (Jeff Balogh)
Date: Wed, 19 Mar 2008 17:18:33 +0000
Subject: [New-bugs-announce] [issue2425] test_py3kwarn doesn't use
sys.py3kwarning
In-Reply-To: <1205947113.11.0.403203872341.issue2425@psf.upfronthosting.co.za>
Message-ID: <1205947113.11.0.403203872341.issue2425@psf.upfronthosting.co.za>
New submission from Jeff Balogh <its.jeff.balogh at gmail.com>:
This patch fixes the TODO in test_py3kwarn
----------
components: Tests
files: py3kwarn-refactor.diff
keywords: patch
messages: 64073
nosy: brett.cannon, jeff.balogh
severity: normal
status: open
title: test_py3kwarn doesn't use sys.py3kwarning
versions: Python 2.6
Added file: http://bugs.python.org/file9770/py3kwarn-refactor.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2425>
__________________________________
From report at bugs.python.org Wed Mar 19 18:26:21 2008
From: report at bugs.python.org (Paul Kippes)
Date: Wed, 19 Mar 2008 17:26:21 +0000
Subject: [New-bugs-announce] [issue2426] pysqlite provides no interface for
database SQL dump
In-Reply-To: <1205947581.08.0.648809036566.issue2426@psf.upfronthosting.co.za>
Message-ID: <1205947581.08.0.648809036566.issue2426@psf.upfronthosting.co.za>
New submission from Paul Kippes <kippesp+python at gmail.com>:
Without the command line interface to sqlite3, there is no easy method
of extracting a database into an SQL dump file. This creates a problem
should a user want to create an in-memory database (which is useful for
a performance boost) and then save the data for later use. It also
would be useful should the sqlite3 command not be installed.
The attached patch implements this feature as a method of the Connection
class.
----------
components: Extension Modules, Library (Lib)
files: sqlite_dump_addition.r61630.patch
keywords: patch
messages: 64074
nosy: kippesp
severity: normal
status: open
title: pysqlite provides no interface for database SQL dump
type: feature request
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9771/sqlite_dump_addition.r61630.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2426>
__________________________________
From report at bugs.python.org Wed Mar 19 20:34:54 2008
From: report at bugs.python.org (Bruce Frederiksen)
Date: Wed, 19 Mar 2008 19:34:54 +0000
Subject: [New-bugs-announce] [issue2427] 2to3 should translate
itertools.imap into generator expression, not list comprehension
In-Reply-To: <1205955294.72.0.717480464196.issue2427@psf.upfronthosting.co.za>
Message-ID: <1205955294.72.0.717480464196.issue2427@psf.upfronthosting.co.za>
New submission from Bruce Frederiksen <dangyogi at gmail.com>:
2to3, svn rev 61623 translates itertools.imap(lambda x: ..., ...) into a
list comprehension. This should be translated instead into a generator
expression so that doing itertools.imap on infinite iterators still works.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 64092
nosy: collinwinter, dangyogi
severity: normal
status: open
title: 2to3 should translate itertools.imap into generator expression, not list comprehension
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2427>
__________________________________
From report at bugs.python.org Wed Mar 19 22:00:03 2008
From: report at bugs.python.org (Bruce Frederiksen)
Date: Wed, 19 Mar 2008 21:00:03 +0000
Subject: [New-bugs-announce] [issue2428] 2to3 deletes # comments before
"from __future__ import with_statement"
In-Reply-To: <1205960403.35.0.278186384366.issue2428@psf.upfronthosting.co.za>
Message-ID: <1205960403.35.0.278186384366.issue2428@psf.upfronthosting.co.za>
New submission from Bruce Frederiksen <dangyogi at gmail.com>:
2to3, svn rev 61623. To reproduce this error:
$ cat <<! > foobar.py
# line 1
# line 2
from __future__ import with_statement
import sys
!
$ 2to3 -w foobar.py
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: ws_comma
--- foobar.py (original)
+++ foobar.py (refactored)
@@ -1,5 +1,2 @@
-# line 1
-# line 2
-from __future__ import with_statement
import sys
RefactoringTool: Files that were modified:
RefactoringTool: foobar.py
$ cat foobar.py
import sys
$
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 64098
nosy: collinwinter, dangyogi
severity: normal
status: open
title: 2to3 deletes # comments before "from __future__ import with_statement"
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2428>
__________________________________
From report at bugs.python.org Thu Mar 20 00:22:35 2008
From: report at bugs.python.org (Michael Foord)
Date: Wed, 19 Mar 2008 23:22:35 +0000
Subject: [New-bugs-announce] [issue2429] Patch for test_urllib2_net moving
tests to use a local server
In-Reply-To: <1205968955.73.0.744201305439.issue2429@psf.upfronthosting.co.za>
Message-ID: <1205968955.73.0.744201305439.issue2429@psf.upfronthosting.co.za>
New submission from Michael Foord <fuzzyman at voidspace.org.uk>:
This patch moves some tests from test_urllib2_net to
test_urllib2_localnet. The moved tests now use a local server rather
than going out to external servers.
Mainly the work of Jerry Seutter - so blame him. ;-)
----------
components: Tests
files: network_tests.patch
keywords: patch
messages: 64121
nosy: fuzzyman
severity: normal
status: open
title: Patch for test_urllib2_net moving tests to use a local server
versions: Python 2.6
Added file: http://bugs.python.org/file9777/network_tests.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2429>
__________________________________
From report at bugs.python.org Thu Mar 20 05:29:12 2008
From: report at bugs.python.org (Jerry Seutter)
Date: Thu, 20 Mar 2008 04:29:12 +0000
Subject: [New-bugs-announce] [issue2430] Stop test_format.py from executing
as side effect of import
In-Reply-To: <1205987352.7.0.846357959052.issue2430@psf.upfronthosting.co.za>
Message-ID: <1205987352.7.0.846357959052.issue2430@psf.upfronthosting.co.za>
New submission from Jerry Seutter <jseutter at gmail.com>:
Changes to test file only, no other changes.
----------
components: Tests
files: test_format_to_unittest.patch
keywords: patch, patch
messages: 64148
nosy: jseutter
priority: low
severity: normal
status: open
title: Stop test_format.py from executing as side effect of import
versions: Python 2.6
Added file: http://bugs.python.org/file9784/test_format_to_unittest.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2430>
__________________________________
From report at bugs.python.org Thu Mar 20 06:30:54 2008
From: report at bugs.python.org (David Wolever)
Date: Thu, 20 Mar 2008 05:30:54 +0000
Subject: [New-bugs-announce] [issue2431] 2to3 is rather slow
In-Reply-To: <1205991054.16.0.327808127723.issue2431@psf.upfronthosting.co.za>
Message-ID: <1205991054.16.0.327808127723.issue2431@psf.upfronthosting.co.za>
New submission from David Wolever <wolever at cs.toronto.edu>:
It takes me 10 seconds to run 2to3 on the example file.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 64152
nosy: David Wolever, collinwinter
severity: normal
status: open
title: 2to3 is rather slow
type: performance
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2431>
__________________________________
From report at bugs.python.org Thu Mar 20 09:47:00 2008
From: report at bugs.python.org (ivanoe)
Date: Thu, 20 Mar 2008 08:47:00 +0000
Subject: [New-bugs-announce] [issue2432] DictReader does not suport line_num
In-Reply-To: <1206002820.55.0.716931876955.issue2432@psf.upfronthosting.co.za>
Message-ID: <1206002820.55.0.716931876955.issue2432@psf.upfronthosting.co.za>
New submission from ivanoe <ivanoe at ivanoe.net>:
Documentation http://docs.python.org/lib/node264.html mentions that both
'reader' and 'DictReader' support 'line_num' fields.
But in fact in version 2.5.2 of the library line_num is not in
'DictReader' class. (looking at csv.py)
For the moment I created little wrapper class to handle the issue, but
it should be done in the original 'DictReader' to support uniform
'interface' of the reader.
{{{
import csv
class DictReader(csv.DictReader):
""" DictReader that supports line_num field. """
def __init__(self, f, fieldnames=None, restkey=None, restval=None,
dialect="excel", *args, **kwds):
csv.DictReader.__init__(self, f, fieldnames, restkey, restval,
dialect)
self.line_num = 0
def next(self):
res = csv.DictReader.next(self)
self.line_num+=1
return res
}}}
(sorry, no tests)
I suggest that line_num gets implemented, rather then documentation changed.
----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 64160
nosy: georg.brandl, ivanoe
severity: normal
status: open
title: DictReader does not suport line_num
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2432>
__________________________________
From report at bugs.python.org Thu Mar 20 18:20:47 2008
From: report at bugs.python.org (Michael Bishop)
Date: Thu, 20 Mar 2008 17:20:47 +0000
Subject: [New-bugs-announce] [issue2433] Merge audio modules
In-Reply-To: <1206033647.05.0.831244595628.issue2433@psf.upfronthosting.co.za>
Message-ID: <1206033647.05.0.831244595628.issue2433@psf.upfronthosting.co.za>
New submission from Michael Bishop <michaelsplace at gmail.com>:
There are many duplicate functions throughout the many audio modules. I
plan to merge relevant functions into 2 modules; a C module and a py
module. Once I go through the audio modules in detail, I'll post my plan
here.
Reference:
http://www.python.org/dev/peps/pep-3108/
http://mail.python.org/pipermail/python-3000/2007-January/005295.html
----------
components: Library (Lib)
messages: 64182
nosy: MichaelBishop, brett.cannon
severity: normal
status: open
title: Merge audio modules
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2433>
__________________________________
From report at bugs.python.org Thu Mar 20 19:01:48 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 20 Mar 2008 18:01:48 +0000
Subject: [New-bugs-announce] [issue2434] Improve platform.win32_ver()
support for Python installations without win32all installed
In-Reply-To: <1206036108.55.0.836121588011.issue2434@psf.upfronthosting.co.za>
Message-ID: <1206036108.55.0.836121588011.issue2434@psf.upfronthosting.co.za>
New submission from Marc-Andre Lemburg <mal at egenix.com>:
platform should use _winreg and sys.getwindowsversion() to emulate the
missing win32all APIs.
----------
assignee: lemburg
components: Library (Lib)
messages: 64187
nosy: lemburg
severity: normal
status: open
title: Improve platform.win32_ver() support for Python installations without win32all installed
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2434>
__________________________________
From report at bugs.python.org Thu Mar 20 19:45:18 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Mar 2008 18:45:18 +0000
Subject: [New-bugs-announce] [issue2435] pybench does not run anymore
In-Reply-To: <1206038718.43.0.678632564965.issue2435@psf.upfronthosting.co.za>
Message-ID: <1206038718.43.0.678632564965.issue2435@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
I get this on py3k:
$ ./python Tools/pybench/pybench.py
Traceback (most recent call last):
File "Tools/pybench/pybench.py", line 391, in <module>
import Setup
File "/home/antoine/py3k/unialloc/Tools/pybench/Setup.py", line 34, in
<module>
from With import *
ImportError: No module named With
It seems like the With.py file in Tools/pybench was not added as part of
an SVN merge from the 2.x trunk.
----------
components: Demos and Tools
messages: 64190
nosy: pitrou
severity: normal
status: open
title: pybench does not run anymore
type: crash
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2435>
__________________________________
From report at bugs.python.org Thu Mar 20 20:08:19 2008
From: report at bugs.python.org (Eric Smith)
Date: Thu, 20 Mar 2008 19:08:19 +0000
Subject: [New-bugs-announce] [issue2436] Should __future__ print_function be
valid in 3.0?
In-Reply-To: <1206040099.45.0.826679091629.issue2436@psf.upfronthosting.co.za>
Message-ID: <1206040099.45.0.826679091629.issue2436@psf.upfronthosting.co.za>
New submission from Eric Smith <eric at trueblade.com>:
Should this be accepted in 3.0, and become a no-op:
from __future__ import print_function
?
It might make using code in 2.6 and 3.0 easier, since you would not have
to delete this line.
I note that:
from __future__ import with_statement
is already valid in 3.0.
----------
assignee: eric.smith
components: Interpreter Core
messages: 64193
nosy: eric.smith
priority: normal
severity: normal
status: open
title: Should __future__ print_function be valid in 3.0?
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2436>
__________________________________
From report at bugs.python.org Thu Mar 20 21:23:15 2008
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 20 Mar 2008 20:23:15 +0000
Subject: [New-bugs-announce] [issue2437] Distutils runtime_library_dirs
broken on Windows
In-Reply-To: <1206044595.46.0.100105317073.issue2437@psf.upfronthosting.co.za>
Message-ID: <1206044595.46.0.100105317073.issue2437@psf.upfronthosting.co.za>
New submission from Bill Janssen <bill.janssen at gmail.com>:
The distutils.unixcompiler.runtime_library_dirs() function, used when
compiling with MinGW or Cygwin on Windows, fails catastrophically
because the return result of sysconfig.get_config_var("CC") returns
None. It should probably be prepared for that eventuality.
----------
messages: 64200
nosy: janssen
severity: normal
status: open
title: Distutils runtime_library_dirs broken on Windows
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2437>
__________________________________
From report at bugs.python.org Thu Mar 20 21:38:32 2008
From: report at bugs.python.org (Patrick)
Date: Thu, 20 Mar 2008 20:38:32 +0000
Subject: [New-bugs-announce] [issue2438] subprocess.Popen with wildcard
arguments
In-Reply-To: <1206045512.59.0.667907711794.issue2438@psf.upfronthosting.co.za>
Message-ID: <1206045512.59.0.667907711794.issue2438@psf.upfronthosting.co.za>
New submission from Patrick <pbrandt at nrao.edu>:
When using wildcards as arguments to the processes being spawned by
Popen, it seems to interpret them as hard literals.
IE, when doing something like:
>>> import subprocess
>>> output = subprocess.Popen(['ls', '*'],
stdout=subprocess.PIPE).communicate()[0]
ls: *: No such file or directory
>>>
----------
components: Library (Lib)
messages: 64204
nosy: pbrandt
severity: normal
status: open
title: subprocess.Popen with wildcard arguments
type: behavior
versions: Python 2.4
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2438>
__________________________________
From report at bugs.python.org Thu Mar 20 21:58:33 2008
From: report at bugs.python.org (Paul Moore)
Date: Thu, 20 Mar 2008 20:58:33 +0000
Subject: [New-bugs-announce] [issue2439] Patch to add a get_data function to
pkgutil
In-Reply-To: <1206046713.54.0.393035413153.issue2439@psf.upfronthosting.co.za>
Message-ID: <1206046713.54.0.393035413153.issue2439@psf.upfronthosting.co.za>
New submission from Paul Moore <p.f.moore at gmail.com>:
This patch adds a new get_data function to the pkgutil module, allowing
access to data stored in the package directory. It wraps the PEP 302
loader "get_data" function, so that it works with such loaders (for
example, zipimport).
The patch includes documentation and tests (I created a new test_pkgutil
test module, but did not add tests for the existing pkgutil functionality).
All tests pass on Windows against svn rev 61679 (except test_tcl, which
was skipped as I didn't build TCL support).
----------
components: Library (Lib)
files: pkgutil.patch
keywords: patch
messages: 64208
nosy: pmoore
severity: normal
status: open
title: Patch to add a get_data function to pkgutil
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file9792/pkgutil.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2439>
__________________________________
From report at bugs.python.org Thu Mar 20 23:00:42 2008
From: report at bugs.python.org (Trent Nelson)
Date: Thu, 20 Mar 2008 22:00:42 +0000
Subject: [New-bugs-announce] [issue2440] Issues with getargs_n(),
PyNumber_Index and PyLong_AsSize_t.
In-Reply-To: <1206050442.67.0.496216797611.issue2440@psf.upfronthosting.co.za>
Message-ID: <1206050442.67.0.496216797611.issue2440@psf.upfronthosting.co.za>
New submission from Trent Nelson <tnelson at onresolve.com>:
test_getargs2 fails on Win x64:
test_getargs2 is failing on Windows x64:
test test_getargs2 failed -- Traceback (most recent call last):
File
"S:\buildbots\python.x64\3.0.nelson-win64\build\lib\test\test_getargs2.py",
line 190, in test_n
self.failUnlessEqual(99, getargs_n(Long()))
TypeError: 'Long' object cannot be interpreted as an integer
The problem is twofold: case 'n' on Win x64 (where SIZEOF_SIZE_T !=
SIZEOF_LONG) had a broken code path and needed updating. Also, the
fallback to 'l' for systems where SIZEOF_SIZE_T == SIZEOF_LONG wasn't
correct -- it should still do a PyNumber_Index() check, and then use
PyLong_AsSize_t() to extract the value.
The attached patch corrects the behaviour on 32-bit and 64-bit systems,
including Windows. However, it has now uncovered another bug in Windows
x64:
>>> from _testcapi import getargs_n
>>> getargs_n(sys.maxsize)
9223372036854775807
>>> getargs_n(-sys.maxsize)
1
>>> getargs_n(-sys.maxsize-1)
0
After a bit of investigation with Martin, the logic in PyLong_AsSize_t()
is incorrect and needs to be reworked to handle negative maximums properly.
----------
components: Interpreter Core
files: getargs_and_abstract.patch
keywords: patch, patch
messages: 64212
nosy: Trent.Nelson, loewis
severity: normal
status: open
title: Issues with getargs_n(), PyNumber_Index and PyLong_AsSize_t.
versions: Python 3.0
Added file: http://bugs.python.org/file9793/getargs_and_abstract.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2440>
__________________________________
From report at bugs.python.org Thu Mar 20 23:37:27 2008
From: report at bugs.python.org (Carlos Eduardo de Paula)
Date: Thu, 20 Mar 2008 22:37:27 +0000
Subject: [New-bugs-announce] [issue2441] Mac build_install.py script fetches
unavailable SQLite version
In-Reply-To: <1206052647.34.0.885320572694.issue2441@psf.upfronthosting.co.za>
Message-ID: <1206052647.34.0.885320572694.issue2441@psf.upfronthosting.co.za>
New submission from Carlos Eduardo de Paula <carlosedp at gmail.com>:
The build_installer.py script, used to create MacPython installers tries
to fetch a SQLite version that is not available anymore. I provided a
patch with an updated version and its corresponding hash.
Maybe this should be backported to 2.5 and 2.6 branches.
----------
components: Installation
files: build_installer.diff
keywords: patch
messages: 64218
nosy: carlosedp
severity: normal
status: open
title: Mac build_install.py script fetches unavailable SQLite version
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file9796/build_installer.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2441>
__________________________________
From report at bugs.python.org Fri Mar 21 03:05:29 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 21 Mar 2008 02:05:29 +0000
Subject: [New-bugs-announce] [issue2442] Undocumented features added to 2.6
In-Reply-To: <1206065129.51.0.279261412991.issue2442@psf.upfronthosting.co.za>
Message-ID: <1206065129.51.0.279261412991.issue2442@psf.upfronthosting.co.za>
New submission from A.M. Kuchling <lists at amk.ca>:
The following modules or features aren't documented: future_builtins,
__self__ and __func__ on method objects, the print() function.
----------
assignee: georg.brandl
components: Documentation
messages: 64230
nosy: akuchling, georg.brandl
severity: normal
status: open
title: Undocumented features added to 2.6
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2442>
__________________________________
From report at bugs.python.org Fri Mar 21 11:27:38 2008
From: report at bugs.python.org (Rolland Dudemaine)
Date: Fri, 21 Mar 2008 10:27:38 +0000
Subject: [New-bugs-announce] [issue2443] uninitialized access to va_list
In-Reply-To: <1206095258.5.0.538024401904.issue2443@psf.upfronthosting.co.za>
Message-ID: <1206095258.5.0.538024401904.issue2443@psf.upfronthosting.co.za>
New submission from Rolland Dudemaine <rolland at ghs.com>:
In many files, the following code is present (with slight variations,
but the important part is there) :
static PyObject *
objargs_mktuple(va_list va)
{
int i, n = 0;
va_list countva;
PyObject *result, *tmp;
#ifdef VA_LIST_IS_ARRAY
memcpy(countva, va, sizeof(va_list));
#else
#ifdef __va_copy
__va_copy(countva, va);
#else
countva = va;
#endif
#endif
...
memcpy() is accessing va_list before it is initialized.
Before the first access to a va_list type variable, and after the last
access to that variable, calls to va_start() and va_end() must be made
to initialize and free the variable.
Such behaviour should be corrected in the following files :
- Objects/abstract.c, line 1901
- Objects/stringobject.c, line 162
- getargs.c, line 66
- getargs.c, line 1188
- modsupport.c, line 479
----------
components: Build
messages: 64234
nosy: rolland
severity: normal
status: open
title: uninitialized access to va_list
type: compile error
versions: Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2443>
__________________________________
From report at bugs.python.org Fri Mar 21 16:41:37 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 21 Mar 2008 15:41:37 +0000
Subject: [New-bugs-announce] [issue2444] Adding __iter__ to class Values of
module optparse
In-Reply-To: <1206114097.48.0.657635538411.issue2444@psf.upfronthosting.co.za>
Message-ID: <1206114097.48.0.657635538411.issue2444@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
Hi,
Doing (opts, args) = parser.parse_args(), supposing parser is an
OptionParser instance, gets you an instance of class Values into opts.
This patch adds the __iter__ method to the class Values so it is
possible to iterate over the options you could have received. This is
useful when all your options are required and you don't want to use a
lot of if's to check if they are all there (for example).
Right now it is possible to do this but you would have to iterate over
opts.__dict__, an ugly way as I see.
----------
components: Library (Lib)
files: optparse__iter__.diff
keywords: patch
messages: 64244
nosy: gpolo
severity: normal
status: open
title: Adding __iter__ to class Values of module optparse
versions: Python 2.6
Added file: http://bugs.python.org/file9801/optparse__iter__.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2444>
__________________________________
From report at bugs.python.org Fri Mar 21 17:41:38 2008
From: report at bugs.python.org (David Stanek)
Date: Fri, 21 Mar 2008 16:41:38 +0000
Subject: [New-bugs-announce] [issue2445] Use The CygwinCCompiler Under Cygwin
In-Reply-To: <1206117698.01.0.240143600903.issue2445@psf.upfronthosting.co.za>
Message-ID: <1206117698.01.0.240143600903.issue2445@psf.upfronthosting.co.za>
New submission from David Stanek <dstanek at dstanek.com>:
I was having an issue building extension with a fresh checkout of
revision 61699. distutils was using the UnixCCompiler. This is not able
to find thec correct libraries to link against. I made a few changes in
this patch:
* distutils now uses the CygwinCCompiler when building extensions on the
Cygwin platform
* CygwinCCompiler.static_lib_extension needed to be .lib.a instead of
just .a
* Added some files to the svn:ignore property on a handful of directories.
----------
components: Distutils
files: cygwin.diff
keywords: patch
messages: 64245
nosy: dstanek
severity: normal
status: open
title: Use The CygwinCCompiler Under Cygwin
versions: Python 2.6
Added file: http://bugs.python.org/file9803/cygwin.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2445>
__________________________________
From report at bugs.python.org Fri Mar 21 18:59:42 2008
From: report at bugs.python.org (Bruce Frederiksen)
Date: Fri, 21 Mar 2008 17:59:42 +0000
Subject: [New-bugs-announce] [issue2446] 2to3 translates "import foobar" to
"import .foobar" rather than "from . import foobar"
In-Reply-To: <1206122382.01.0.177794619684.issue2446@psf.upfronthosting.co.za>
Message-ID: <1206122382.01.0.177794619684.issue2446@psf.upfronthosting.co.za>
New submission from Bruce Frederiksen <dangyogi at gmail.com>:
2to3 svn rev 61696 translates "import local_module" into "import
.local_module" which isn't legal syntax.
Should be "from . import local_module".
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 64247
nosy: collinwinter, dangyogi
severity: normal
status: open
title: 2to3 translates "import foobar" to "import .foobar" rather than "from . import foobar"
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2446>
__________________________________
From report at bugs.python.org Fri Mar 21 19:52:00 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 21 Mar 2008 18:52:00 +0000
Subject: [New-bugs-announce] [issue2447] Python 2.6 refleak test issues
In-Reply-To: <1206125520.14.0.711672473194.issue2447@psf.upfronthosting.co.za>
Message-ID: <1206125520.14.0.711672473194.issue2447@psf.upfronthosting.co.za>
New submission from Christian Heimes <lists at cheimes.de>:
linux-i686-2.6
Revision 61704.
Ubuntu 7.10 on i586 machine
gcc-Version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
trunk$ ./python Lib/test/regrtest.py -ubsddb,network -R::
[...]
311 tests OK.
7 tests failed:
test_collections test_cprofile test_frozen test_logging test_pkg
test_profile test_tcl
27 tests skipped:
test_aepack test_al test_applesingle test_bsddb185 test_cd test_cl
test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
test_codecmaps_kr test_codecmaps_tw test_curses test_gl
test_imageop test_imgfile test_linuxaudiodev test_macostools
test_normalization test_ossaudiodev test_pep277 test_py3kwarn
test_scriptpackages test_startfile test_sunaudiodev test_winreg
test_winsound test_zipfile64
Those skips are all expected on linux2.
trunk$ cat reflog.txt
test_smtplib leaked [86, -86, 80, -80] references, sum=0
test_socket_ssl leaked [0, 123, -123, 0] references, sum=0
test_threading leaked [0, 0, 0, -86] references, sum=-86
test_urllib2_localnet leaked [3, 171, -165, 3] references, sum=12
----------
components: Tests
messages: 64257
nosy: tiran
priority: high
severity: normal
status: open
title: Python 2.6 refleak test issues
type: crash
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2447>
__________________________________
From report at bugs.python.org Fri Mar 21 19:54:50 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 21 Mar 2008 18:54:50 +0000
Subject: [New-bugs-announce] [issue2448] namedtuple breaks refleak tests
In-Reply-To: <1206125690.78.0.550983870823.issue2448@psf.upfronthosting.co.za>
Message-ID: <1206125690.78.0.550983870823.issue2448@psf.upfronthosting.co.za>
New submission from Christian Heimes <lists at cheimes.de>:
trunk$ ./python Lib/test/regrtest.py -ubsddb,network -R::
test_collections
test_collections
beginning 9 repetitions
123456789
test test_collections failed -- Traceback (most recent call last):
File "/home/heimes/dev/python/trunk/Lib/doctest.py", line 2131, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for collections.namedtuple
File "/home/heimes/dev/python/trunk/Lib/collections.py", line 13, in
namedtuple
----------------------------------------------------------------------
File "/home/heimes/dev/python/trunk/Lib/collections.py", line 16, in
collections.namedtuple
Failed example:
Point = namedtuple('Point', 'x y')
Exception raised:
Traceback (most recent call last):
File "/home/heimes/dev/python/trunk/Lib/doctest.py", line 1231, in
__run
compileflags, 1) in test.globs
File "<doctest collections.namedtuple[0]>", line 1, in <module>
Point = namedtuple('Point', 'x y')
NameError: name 'namedtuple' is not defined
----------
assignee: rhettinger
components: Library (Lib), Tests
messages: 64258
nosy: rhettinger, tiran
priority: high
severity: normal
status: open
title: namedtuple breaks refleak tests
type: crash
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2448>
__________________________________
From report at bugs.python.org Fri Mar 21 21:39:48 2008
From: report at bugs.python.org (Christopher Blunck)
Date: Fri, 21 Mar 2008 20:39:48 +0000
Subject: [New-bugs-announce] [issue2449] Improved serialization error
logging in xmlrpclib
In-Reply-To: <1206131988.04.0.901893858067.issue2449@psf.upfronthosting.co.za>
Message-ID: <1206131988.04.0.901893858067.issue2449@psf.upfronthosting.co.za>
New submission from Christopher Blunck <blunck2 at users.sourceforge.net>:
When xmlrpclib fails to serialize objects into XML a generic "failed to
serialize output" error is returned to the client and no log messages
are produced to give insight into the true cause of the problem. In
real-world scenarios where lots of data moves along the wire it can be
difficult to determine the cause of the serialization problem.
I propose the attached patch as an initial cut at improving xmlrpclib
under circumstances where serialization fails.
----------
components: Library (Lib)
files: Python-2.4.4.all.patch04
messages: 64274
nosy: blunck2
severity: normal
status: open
title: Improved serialization error logging in xmlrpclib
type: feature request
versions: Python 2.4
Added file: http://bugs.python.org/file9805/Python-2.4.4.all.patch04
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2449>
__________________________________
From report at bugs.python.org Fri Mar 21 23:58:09 2008
From: report at bugs.python.org (John J Lee)
Date: Fri, 21 Mar 2008 22:58:09 +0000
Subject: [New-bugs-announce] [issue2450] urllib2.Request constructor has no
timeout parameter
In-Reply-To: <1206140289.07.0.166217155748.issue2450@psf.upfronthosting.co.za>
Message-ID: <1206140289.07.0.166217155748.issue2450@psf.upfronthosting.co.za>
New submission from John J Lee <jjlee at users.sourceforge.net>:
r55792 added timeout support to urllib2. A timeout parameter was added
to urllib2.OpenerDirector.open(), but there is no corresponding Request
constructor parameter. timeout is unique in that respect. Instead,
OpenerDirector.open() sets req.timeout on request instances. The
parameter "timeout" should behave in the same way as existing parameter
"data".
----------
components: Library (Lib)
messages: 64291
nosy: jjlee
severity: normal
status: open
title: urllib2.Request constructor has no timeout parameter
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2450>
__________________________________
From report at bugs.python.org Sat Mar 22 00:16:18 2008
From: report at bugs.python.org (John J Lee)
Date: Fri, 21 Mar 2008 23:16:18 +0000
Subject: [New-bugs-announce] [issue2451] No way to disable socket timeouts
in httplib, etc.
In-Reply-To: <1206141378.11.0.857343736887.issue2451@psf.upfronthosting.co.za>
Message-ID: <1206141378.11.0.857343736887.issue2451@psf.upfronthosting.co.za>
New submission from John J Lee <jjlee at users.sourceforge.net>:
The new timeout support in 2.6 makes use of new function
socket.create_connection(). socket.create_connection() provides no way
to disable timeouts, other than by relying on socket.getdefaulttimeout()
returning None. This is unfortunate, because it was the purpose of the
new timeout support to allow control of timeouts without reliance on
global state.
setdefaultsocket.create_connection() should always call
sock.settimeout() with the timeout passed to create_connection(), unless
a special non-None value is passed indicating that the global default is
to be used. Specific modules may then use that special non-None value
where required, to preserve backwards-compatibility.
----------
components: Library (Lib)
messages: 64293
nosy: jjlee
severity: normal
status: open
title: No way to disable socket timeouts in httplib, etc.
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2451>
__________________________________
From report at bugs.python.org Sat Mar 22 00:23:27 2008
From: report at bugs.python.org (John J Lee)
Date: Fri, 21 Mar 2008 23:23:27 +0000
Subject: [New-bugs-announce] [issue2452] inaccuracy in httplib timeout
documentation
In-Reply-To: <1206141807.24.0.299665473683.issue2452@psf.upfronthosting.co.za>
Message-ID: <1206141807.24.0.299665473683.issue2452@psf.upfronthosting.co.za>
New submission from John J Lee <jjlee at users.sourceforge.net>:
The documentation for the new timeout support in 2.6 states that "If the
optional timeout parameter is given, connection attempts will timeout
after that many seconds". In fact, other non-blocking. The only
operation that might block for longer than the requested timeout is the
getaddrinfo() in socket.create_connection().
There may be similar inaccuracies in the docs of other modules to which
timeout support was added.
----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 64295
nosy: georg.brandl, jjlee
severity: normal
status: open
title: inaccuracy in httplib timeout documentation
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2452>
__________________________________
From report at bugs.python.org Sat Mar 22 01:49:33 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 22 Mar 2008 00:49:33 +0000
Subject: [New-bugs-announce] [issue2453] fix_except needs to allow for empty
excepts
In-Reply-To: <1206146973.79.0.293123214296.issue2453@psf.upfronthosting.co.za>
Message-ID: <1206146973.79.0.293123214296.issue2453@psf.upfronthosting.co.za>
New submission from Martin v. L?wis <martin at v.loewis.de>:
The code
try:
f()
except X,a:
g()
except:
h()
currently doesn't get changed, but should be converted to
try:
f()
except X as a:
g()
except:
h()
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 64303
nosy: collinwinter, loewis
severity: normal
status: open
title: fix_except needs to allow for empty excepts
type: behavior
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2453>
__________________________________
From report at bugs.python.org Sat Mar 22 02:00:44 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 22 Mar 2008 01:00:44 +0000
Subject: [New-bugs-announce] [issue2454] md5 fixer
In-Reply-To: <1206147643.89.0.60936055638.issue2454@psf.upfronthosting.co.za>
Message-ID: <1206147643.89.0.60936055638.issue2454@psf.upfronthosting.co.za>
New submission from Martin v. L?wis <martin at v.loewis.de>:
Usages of the md5 module could be fixed, as it's unavailable in 3k.
In particular:
import md5 -> import hashlib
md5.new(...) -> hashlib.md5(...)
md5.md5(...) -> hashlib.md5(...)
Notice that users could already change this manually in 2.6, since
hashlib is available since 2.5, so the fixer is not strictly needed, but
would be convenient.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 64305
nosy: collinwinter, loewis
severity: normal
status: open
title: md5 fixer
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2454>
__________________________________
From report at bugs.python.org Sat Mar 22 03:25:16 2008
From: report at bugs.python.org (Andrey Skvortsov)
Date: Sat, 22 Mar 2008 02:25:16 +0000
Subject: [New-bugs-announce] [issue2455] stat.ST_CTIME and stat.ST_ATIME
problem
In-Reply-To: <1206152716.81.0.392707028584.issue2455@psf.upfronthosting.co.za>
Message-ID: <1206152716.81.0.392707028584.issue2455@psf.upfronthosting.co.za>
New submission from Andrey Skvortsov <stingo000 at yahoo.ca>:
stat.ST_CTIME and stat.ST_ATIME are mixed up.
ST_CTIME gives access time and should be ST_ATIME and vice versa
ST_ATIME gives creation time. Linux.
----------
components: Library (Lib)
messages: 64310
nosy: sassas
severity: normal
status: open
title: stat.ST_CTIME and stat.ST_ATIME problem
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2455>
__________________________________
From report at bugs.python.org Sat Mar 22 15:53:27 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 22 Mar 2008 14:53:27 +0000
Subject: [New-bugs-announce] [issue2456] Make sysmodule.c compatible with
Bazaar
In-Reply-To: <1206197607.7.0.946463718632.issue2456@psf.upfronthosting.co.za>
Message-ID: <1206197607.7.0.946463718632.issue2456@psf.upfronthosting.co.za>
New submission from Barry A. Warsaw <barry at python.org>:
For the Bazaar experiment <http://www.python.org/dev/bazaar>,
sysmodule.c needs to be made compatible with Bazaar, for build number
display.
----------
assignee: barry
components: Interpreter Core
messages: 64327
nosy: barry
priority: normal
severity: normal
status: open
title: Make sysmodule.c compatible with Bazaar
type: crash
versions: Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2456>
__________________________________
From report at bugs.python.org Sat Mar 22 20:41:12 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 22 Mar 2008 19:41:12 +0000
Subject: [New-bugs-announce] [issue2457] add --help and -h options to pdb
In-Reply-To: <1206214872.65.0.48935135608.issue2457@psf.upfronthosting.co.za>
Message-ID: <1206214872.65.0.48935135608.issue2457@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
If --help or -h are used as options for pdb, pdb unhelpfully exits with
"file -h cannot be found." This makes it more user friendly and prints
the usage if those options are passed.
----------
components: Demos and Tools, Library (Lib)
files: pdb_help.patch
keywords: patch
messages: 64336
nosy: benjamin.peterson
severity: normal
status: open
title: add --help and -h options to pdb
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file9816/pdb_help.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2457>
__________________________________
From report at bugs.python.org Sat Mar 22 22:29:05 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 22 Mar 2008 21:29:05 +0000
Subject: [New-bugs-announce] [issue2458] Allow Python code to change Py3k
warning flag
In-Reply-To: <1206221345.67.0.966605700107.issue2458@psf.upfronthosting.co.za>
Message-ID: <1206221345.67.0.966605700107.issue2458@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
This patch removed sys.py3kwarning and adds sys.getpy3kwarn,
sys.enablepy3kwarn, and sys.disablepy3kwarn with docs. I also changed
the places in the Lib which used sys.py3kwarning.
----------
files: change_py3kwarning.patch
keywords: patch
messages: 64339
nosy: benjamin.peterson
severity: normal
status: open
title: Allow Python code to change Py3k warning flag
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file9818/change_py3kwarning.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2458>
__________________________________
From report at bugs.python.org Sat Mar 22 23:25:05 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 22 Mar 2008 22:25:05 +0000
Subject: [New-bugs-announce] [issue2459] speedup loops with better bytecode
In-Reply-To: <1206224705.13.0.0890165071291.issue2459@psf.upfronthosting.co.za>
Message-ID: <1206224705.13.0.0890165071291.issue2459@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
This is a preliminary patch to speedup for and while loops (it will also
be able to speedup list comps and gen comps, if I get to do it).
The patch works by putting the loop condition test at the end of loop,
which allows removing one JUMP_ABSOLUTE byte code out of the critical path.
For this two new opcodes are introduced:
- FOR_ITER2 is the same as FOR_ITER except that it does an /absolute/
jump if the iterator is /not/ exhausted (when other uses of FOR_ITER are
replaced with FOR_ITER2, we can of course restore the original naming)
- JUMP_ABS_IF_TRUE /pops/ the top of the stack and does an absolute jump
if its value is true
Some micro-benchmarks:
./python -m timeit "for x in xrange(10000): pass"
Before: 1000 loops, best of 3: 782 usec per loop
After: 1000 loops, best of 3: 412 usec per loop
./python -m timeit -s "x=10000" "while x: x -= 1"
Before: 1000000 loops, best of 3: 0.237 usec per loop
After: 10000000 loops, best of 3: 0.176 usec per loop
./python Tools/pybench/pybench.py -t ForLoops
Before: 365ms per round
After: 234ms per round
Also, pystone gets 5% faster (from 43300 to 45800).
Now for the less shiny things:
1. I'm having problems modifying the pure Python compiler module. For
some reasons it seems to have stricter requirements than compile.c
itself does (!); I get some assertion error in
compiler.pyassem.FlowGraph.fixupOrderHonorNext as soon as a loop gets
non-trivial.
2. Line numbers probably need to be fixed. The lnotab format may even
have to be adapted in order to accomodate non-monotonically increasing
line numbers.
Is there some interest in this patch? If yes, I'd like to have your
input on the two bullet points above :)
----------
components: Interpreter Core
files: loops.patch
keywords: patch
messages: 64342
nosy: pitrou
severity: normal
status: open
title: speedup loops with better bytecode
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file9820/loops.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2459>
__________________________________
From report at bugs.python.org Sun Mar 23 00:32:55 2008
From: report at bugs.python.org (Armin Ronacher)
Date: Sat, 22 Mar 2008 23:32:55 +0000
Subject: [New-bugs-announce] [issue2460] Ellipsis not copyable
In-Reply-To: <1206228775.23.0.695866830268.issue2460@psf.upfronthosting.co.za>
Message-ID: <1206228775.23.0.695866830268.issue2460@psf.upfronthosting.co.za>
New submission from Armin Ronacher <armin.ronacher at active-4.com>:
Currently python raises an exception if one tries to copy or deepcopy
Ellpisis. The former is usually no problem but if an ellipsis ends up
on an object and becomes deepcopied this is pretty annoying.
The patch provided adds Ellipsis to the copy.py registry with the same
treatment None and other immutable types get.
----------
components: Library (Lib)
files: ellipsis.diff
keywords: patch
messages: 64347
nosy: aronacher
severity: normal
status: open
title: Ellipsis not copyable
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9821/ellipsis.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2460>
__________________________________
From report at bugs.python.org Sun Mar 23 12:16:47 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 23 Mar 2008 11:16:47 +0000
Subject: [New-bugs-announce] [issue2461] test_util.py for distutils
In-Reply-To: <1206271007.7.0.519259374853.issue2461@psf.upfronthosting.co.za>
Message-ID: <1206271007.7.0.519259374853.issue2461@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
this patch adds a test module for util, to improve distutils test
coverage. It does not yet test byte_compile, but the other ones are covered.
----------
components: Distutils
files: 2008-03-23.distutils.util.patch
keywords: patch
messages: 64354
nosy: tarek
severity: normal
status: open
title: test_util.py for distutils
versions: Python 2.6
Added file: http://bugs.python.org/file9826/2008-03-23.distutils.util.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2461>
__________________________________
From report at bugs.python.org Sun Mar 23 15:00:40 2008
From: report at bugs.python.org (ryan)
Date: Sun, 23 Mar 2008 14:00:40 +0000
Subject: [New-bugs-announce] [issue2462] python.exe slowing my system
In-Reply-To: <1206280840.65.0.43552605768.issue2462@psf.upfronthosting.co.za>
Message-ID: <1206280840.65.0.43552605768.issue2462@psf.upfronthosting.co.za>
New submission from ryan <ryanfromnm at yahoo.com>:
Hello!
First of all, i'm not a programmer. I'm running Windows XP Pro. For the
past two/three weeks, every once in a while, my machine runs extremely
slow, and the only strange thing i see in the task manager is a
python.exe. When i stop that process, my machine runs fine again. It's
using 112,000k of memory...i don't know what python is or does, all i
have been able to ascertain is that when it runs, it slows down my
machine. please make it stop. i'm guessing that i'm running an earlier
version of Python, as my computer is older, i'm guessing it's version
2.1.2,2.2, or 2.2.1. I'd really like to trash all python files, yet they
must be in my machine for a reason. Thank you, in advance.
----------
messages: 64357
nosy: FireSnake
severity: normal
status: open
title: python.exe slowing my system
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2462>
__________________________________
From report at bugs.python.org Sun Mar 23 15:33:36 2008
From: report at bugs.python.org (ryan)
Date: Sun, 23 Mar 2008 14:33:36 +0000
Subject: [New-bugs-announce] [issue2463] python.exe slowing my system
In-Reply-To: <1206282816.94.0.500091037786.issue2463@psf.upfronthosting.co.za>
Message-ID: <1206282816.94.0.500091037786.issue2463@psf.upfronthosting.co.za>
New submission from ryan <ryanfromnm at yahoo.com>:
Hello!
First of all, I'm nor a programmer.
Running WinXPpro.
Python.exe runs, using 112,000k mem, according to task manager.
This problem started about 3 weeks ago, have had machine for 3 years
without issues like this.
Please help me make this problem go away.
How do i figure out which program is using python, do i even need python
on my machine?
Thank you in advance.
----------
messages: 64361
nosy: FireSnake
severity: normal
status: open
title: python.exe slowing my system
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2463>
__________________________________
From report at bugs.python.org Sun Mar 23 15:41:10 2008
From: report at bugs.python.org (Koh Wei Jie)
Date: Sun, 23 Mar 2008 14:41:10 +0000
Subject: [New-bugs-announce] [issue2464] urllib2 can't handle
http://www.wikispaces.com
In-Reply-To: <1206283270.11.0.221591174332.issue2464@psf.upfronthosting.co.za>
Message-ID: <1206283270.11.0.221591174332.issue2464@psf.upfronthosting.co.za>
New submission from Koh Wei Jie <weijie90 at gmail.com>:
Try the following code:
import urllib2
gmail = urllib2.urlopen("https://www.gmail.com").read()
wikispaces = urllib2.urlopen("http://www.wikispaces.com").read()
Getting the html over HTTPS from gmail.com works, but not over HTTP from
wikispaces. Here's the traceback:
>>> wikispaces = urllib2.urlopen("http://www.wikispaces.com").read()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.5/urllib2.py", line 121, in urlopen
return _opener.open(url, data)
File "/usr/lib/python2.5/urllib2.py", line 380, in open
response = meth(req, response)
File "/usr/lib/python2.5/urllib2.py", line 491, in http_response
'http', request, response, code, msg, hdrs)
File "/usr/lib/python2.5/urllib2.py", line 412, in error
result = self._call_chain(*args)
File "/usr/lib/python2.5/urllib2.py", line 353, in _call_chain
result = func(*args)
File "/usr/lib/python2.5/urllib2.py", line 575, in http_error_302
return self.parent.open(new)
File "/usr/lib/python2.5/urllib2.py", line 380, in open
response = meth(req, response)
File "/usr/lib/python2.5/urllib2.py", line 491, in http_response
'http', request, response, code, msg, hdrs)
File "/usr/lib/python2.5/urllib2.py", line 412, in error
result = self._call_chain(*args)
File "/usr/lib/python2.5/urllib2.py", line 353, in _call_chain
result = func(*args)
File "/usr/lib/python2.5/urllib2.py", line 575, in http_error_302
return self.parent.open(new)
File "/usr/lib/python2.5/urllib2.py", line 374, in open
response = self._open(req, data)
File "/usr/lib/python2.5/urllib2.py", line 392, in _open
'_open', req)
File "/usr/lib/python2.5/urllib2.py", line 353, in _call_chain
result = func(*args)
File "/usr/lib/python2.5/urllib2.py", line 1100, in http_open
return self.do_open(httplib.HTTPConnection, req)
File "/usr/lib/python2.5/urllib2.py", line 1075, in do_open
raise URLError(err)
urllib2.URLError: <urlopen error (104, 'Connection reset by peer')>
Note the two 302 redirects.
I tried accessing wikispaces.com with SSL turned off in Firefox
2.0.0.12, which didn't work because SSL was required, perhaps in between
the redirects that wikispaces uses.
Why doesn't urllib2 handle the "hidden" SSL properly? (Not to be rude,
but httplib2 works.)
Thanks!
WJ
----------
components: Library (Lib)
messages: 64363
nosy: weijie90
severity: normal
status: open
title: urllib2 can't handle http://www.wikispaces.com
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2464>
__________________________________
From report at bugs.python.org Sun Mar 23 17:52:48 2008
From: report at bugs.python.org (Atul Varma)
Date: Sun, 23 Mar 2008 16:52:48 +0000
Subject: [New-bugs-announce] [issue2465] sphinx-quickstart.py still creates
makefile even if user tells it not to
In-Reply-To: <1206291168.51.0.981395069683.issue2465@psf.upfronthosting.co.za>
Message-ID: <1206291168.51.0.981395069683.issue2465@psf.upfronthosting.co.za>
New submission from Atul Varma <varmaa at gmail.com>:
If the user chooses not to have Sphinx create a Makefile, Sphinx still
behaves as though the user wants it to create one. This patch provides
a simple fix.
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: sphinx-quickstart-makefile.patch
keywords: patch
messages: 64369
nosy: georg.brandl, varmaa
severity: normal
status: open
title: sphinx-quickstart.py still creates makefile even if user tells it not to
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9830/sphinx-quickstart-makefile.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2465>
__________________________________
From report at bugs.python.org Sun Mar 23 18:30:28 2008
From: report at bugs.python.org (Ross Burton)
Date: Sun, 23 Mar 2008 17:30:28 +0000
Subject: [New-bugs-announce] [issue2466] os.path.ismount doesn't work for
NTFS mounts
In-Reply-To: <1206293428.96.0.660613140218.issue2466@psf.upfronthosting.co.za>
Message-ID: <1206293428.96.0.660613140218.issue2466@psf.upfronthosting.co.za>
New submission from Ross Burton <ross at burtonini.com>:
I'm not sure why this is, but ismount doesn't always work for me. It
appears to fail on NTFS mounts.
$ mount
...
/dev/sda1 on /media/windows type ntfs (ro,noexec,nosuid,nodev,user=ross)
redbeard.local:/home on /media/home type nfs
(rw,user=ross,noatime,rsize=65536,wsize=65536,retry=1,nfsvers=3,posix,intr,addr=192.168.1.67)
$ python
Python 2.4.5 (#2, Mar 12 2008, 00:15:51)
[GCC 4.2.3 (Debian 4.2.3-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> ismount("/media/windows")
False
>>> ismount("/media/home")
True
----------
components: Library (Lib)
messages: 64370
nosy: rossburton
severity: normal
status: open
title: os.path.ismount doesn't work for NTFS mounts
type: behavior
versions: Python 2.4
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2466>
__________________________________
From report at bugs.python.org Sun Mar 23 18:49:34 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sun, 23 Mar 2008 17:49:34 +0000
Subject: [New-bugs-announce] [issue2467] gc.DEBUG_STATS reports invalid
"elapsed" times
In-Reply-To: <1206294574.77.0.365865271112.issue2467@psf.upfronthosting.co.za>
Message-ID: <1206294574.77.0.365865271112.issue2467@psf.upfronthosting.co.za>
New submission from Jean-Paul Calderone <exarkun at divmod.com>:
If gc.set_debug(gc.DEBUG_STATS) is enabled, collection will report
elapsed time as it progresses through collection. However, the
reporting code clobbers the value it uses to compute the elapsed time,
so the value alternates between an almost correct valid and a completely
incorrect value.
----------
components: Interpreter Core
files: debug-stats.patch
keywords: patch
messages: 64372
nosy: exarkun
severity: normal
status: open
title: gc.DEBUG_STATS reports invalid "elapsed" times
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9831/debug-stats.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2467>
__________________________________
From report at bugs.python.org Sun Mar 23 21:39:02 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 23 Mar 2008 20:39:02 +0000
Subject: [New-bugs-announce] [issue2468] izip fixer generates incorrect
import statement
In-Reply-To: <1206304742.87.0.65595125742.issue2468@psf.upfronthosting.co.za>
Message-ID: <1206304742.87.0.65595125742.issue2468@psf.upfronthosting.co.za>
New submission from Martin v. L?wis <martin at v.loewis.de>:
Currently (r61811), the code
from itertools import izip
gets fixed to
from itertools import
This is incorrect; the import statement should be removed altogether.
----------
assignee: David Wolever
components: 2to3 (2.x to 3.0 conversion tool)
messages: 64375
nosy: David Wolever, loewis
severity: normal
status: open
title: izip fixer generates incorrect import statement
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2468>
__________________________________
From report at bugs.python.org Mon Mar 24 00:50:18 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 23 Mar 2008 23:50:18 +0000
Subject: [New-bugs-announce] [issue2469] Fix build error in unicodeobject.c
UCS4
In-Reply-To: <1206316218.52.0.325688774899.issue2469@psf.upfronthosting.co.za>
Message-ID: <1206316218.52.0.325688774899.issue2469@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
For a time, the USC4 Python build was broken because of a typo in
unicodeobject.c. Here's the simple fix.
----------
components: Unicode
files: unicode_error_fix.patch
keywords: patch
messages: 64384
nosy: benjamin.peterson
severity: normal
status: open
title: Fix build error in unicodeobject.c UCS4
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file9833/unicode_error_fix.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2469>
__________________________________
From report at bugs.python.org Mon Mar 24 07:24:35 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Mon, 24 Mar 2008 06:24:35 +0000
Subject: [New-bugs-announce] [issue2470] Need fixer for dl (removed) ->
ctypes module
In-Reply-To: <1206339875.66.0.189262293555.issue2470@psf.upfronthosting.co.za>
Message-ID: <1206339875.66.0.189262293555.issue2470@psf.upfronthosting.co.za>
New submission from Neal Norwitz <nnorwitz at gmail.com>:
r61837 removed the dl module. It needs a 2to3 fixer written to use ctypes.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 64394
nosy: collinwinter, nnorwitz
priority: critical
severity: normal
status: open
title: Need fixer for dl (removed) -> ctypes module
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2470>
__________________________________
From report at bugs.python.org Mon Mar 24 07:59:37 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 24 Mar 2008 06:59:37 +0000
Subject: [New-bugs-announce] [issue2471] imp.get_magic() should return bytes,
not bytearray
In-Reply-To: <1206341976.98.0.341393013827.issue2471@psf.upfronthosting.co.za>
Message-ID: <1206341976.98.0.341393013827.issue2471@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
The magic cookie as returned by imp.get_magic() should be of the bytes
type, not bytearray as the magic cookie will not ever change during the
execution of the interpreter.
----------
components: Extension Modules
messages: 64395
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: imp.get_magic() should return bytes, not bytearray
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2471>
__________________________________
From report at bugs.python.org Mon Mar 24 13:09:41 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Mar 2008 12:09:41 +0000
Subject: [New-bugs-announce] [issue2472] Fixed block ordering code in
compiler.pyassem
In-Reply-To: <1206360580.92.0.370388118897.issue2472@psf.upfronthosting.co.za>
Message-ID: <1206360580.92.0.370388118897.issue2472@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
This is a rewrite of the block ordering code in the compiler package
(specifically, the flowgraph part). The previous code was littered with
self-admitted "hacks", "fixups" and "XXX" :-) They are all removed and
replaced with a clean ``order_blocks`` function which does the right
thing from the start.
The patch also replaces a wrong startBlock() with a nextBlock() in
compiler.pycodegen (startBlock can only be used when the previous block
does an unconditional transfer to another one, otherwise the two
adjacent blocks may not be emitted in order).
I've run test_compiler a couple of times, and tested execution of
several functions. They all run fine. Unless someone has specific
reasons to reject the patch, I'd recommend applying it even if not many
people use the compiler package :) I needed the fixes for my work on #2459.
----------
components: Library (Lib)
files: fixcompiler.patch
keywords: patch
messages: 64410
nosy: pitrou
severity: normal
status: open
title: Fixed block ordering code in compiler.pyassem
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9838/fixcompiler.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2472>
__________________________________
From report at bugs.python.org Mon Mar 24 14:56:06 2008
From: report at bugs.python.org (Will Maier)
Date: Mon, 24 Mar 2008 13:56:06 +0000
Subject: [New-bugs-announce] [issue2473] logging.LogRecord should know how
to handle dict-like args
In-Reply-To: <1206366966.49.0.127979087555.issue2473@psf.upfronthosting.co.za>
Message-ID: <1206366966.49.0.127979087555.issue2473@psf.upfronthosting.co.za>
New submission from Will Maier <willmaier at ml1.net>:
In (at least) Python 2.5.2, logging.logRecord provides a very useful
facility to interpolate formatted strings. This feature expands an *args
sequence; if that sequence has only one element and that element is a
dictionary, LogRecord uses the dictionary to interpolate keyword
formatted strings. This is incredibly useful, but the LogRecord
__init__() method includes a rather arbitrary type-specific check that
prevents users from passing dict-like objects to the log methods:
logging.__init__.py:204..238
class LogRecord:
[...]
def __init__(self, name, level, pathname, lineno,
msg, args, exc_info, func=None):
[...]
if args and (len(args) == 1) and args[0] and (type(args[0]) ==
types.DictType):
args = args[0]
This restriction prevents the user from passing eg a subclass of
UserDict.DictMixin. Now, __init__() clearly does need to do _some_
checking of args, but it would be nice if that checking accepted
dict-like objects. I haven't come up with a good way to do this myself
yet, but I figured I'd submit the request now.
Thanks!
----------
components: Library (Lib)
messages: 64415
nosy: wcmaier
severity: normal
status: open
title: logging.LogRecord should know how to handle dict-like args
type: feature request
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2473>
__________________________________
From report at bugs.python.org Mon Mar 24 19:27:14 2008
From: report at bugs.python.org (Ryan Sturmer)
Date: Mon, 24 Mar 2008 18:27:14 +0000
Subject: [New-bugs-announce] [issue2474] fset not working
In-Reply-To: <1206383234.11.0.783869540468.issue2474@psf.upfronthosting.co.za>
Message-ID: <1206383234.11.0.783869540468.issue2474@psf.upfronthosting.co.za>
New submission from Ryan Sturmer <ryansturmer at gmail.com>:
Using the attached module, There's an asymmetry between fget and fset in
my properties. fget works fine, but fset isn't getting called. I'm
fairly sure I'm creating the property correctly. Try the following code:
a = EWAssayIntParam('myparam', 4)
a.value
a.value = 10
a.value
I've seen this same issue flare up and die out several times in the
tracker, is this a commonly made programming mistake rather than a bug?
----------
components: None
files: params.py
messages: 64427
nosy: ryansturmer
severity: normal
status: open
title: fset not working
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9840/params.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2474>
__________________________________
From report at bugs.python.org Mon Mar 24 21:59:09 2008
From: report at bugs.python.org (Josh Cogliati)
Date: Mon, 24 Mar 2008 20:59:09 +0000
Subject: [New-bugs-announce] [issue2475] Popen.poll always returns None
In-Reply-To: <1206392349.51.0.854683862843.issue2475@psf.upfronthosting.co.za>
Message-ID: <1206392349.51.0.854683862843.issue2475@psf.upfronthosting.co.za>
New submission from Josh Cogliati <jjcogliati-r1 at yahoo.com>:
I was trying to use subprocess to run multiple processes, and then wait
until one was finished. I was using poll() to do this and created the
following test case:
#BEGIN
import subprocess,os
procs = [subprocess.Popen(["sleep",str(x)]) for x in range(1,11)]
while len(procs) > 0:
os.wait()
print [(p.pid,p.poll()) for p in procs]
procs = [p for p in procs if p.poll() == None]
#END
I would have expected that as this program was run, it would remove the
processes that finished from the procs list, but instead, they stay in
it and I got the following output:
#Output
[(7426, None), (7427, None), (7428, None), (7429, None), (7430, None),
(7431, None), (7432, None), (7433, None), (7434, None), (7435, None)]
#above line repeats 8 more times
[(7426, None), (7427, None), (7428, None), (7429, None), (7430, None),
(7431, None), (7432, None), (7433, None), (7434, None), (7435, None)]
Traceback (most recent call last):
File "./test_poll.py", line 9, in <module>
os.wait()
OSError: [Errno 10] No child processes
#End output
Basically, even for finished processes, poll returns None.
Version of python used:
Python 2.5.1 (r251:54863, Oct 30 2007, 13:45:26)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
Relevant documentation in Library reference manual 17.1.2
poll( ) ... Returns returncode attribute.
... A None value indicates that the process hasn't terminated yet.
----------
messages: 64439
nosy: jjcogliati
severity: normal
status: open
title: Popen.poll always returns None
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2475>
__________________________________
From report at bugs.python.org Tue Mar 25 00:29:59 2008
From: report at bugs.python.org (Brodie Rao)
Date: Mon, 24 Mar 2008 23:29:59 +0000
Subject: [New-bugs-announce] [issue2476] optparse docs should mention
%default being new in 2.4
In-Reply-To: <1206401399.57.0.922863750504.issue2476@psf.upfronthosting.co.za>
Message-ID: <1206401399.57.0.922863750504.issue2476@psf.upfronthosting.co.za>
New submission from Brodie Rao <junk at dackz.net>:
The %default option help string feature doesn't exist in Python 2.3, but
the documentation for Python 2.4 and 2.5 don't mention that it was added
in 2.4. It should mention this so people developing for 2.3 and 2.4/2.5
can be aware of this.
http://docs.python.org/lib/optparse-generating-help.html is the page
describing the %default feature. I would imagine the bullet point about
the feature being prefixed with "New in 2.4: ..."
----------
assignee: georg.brandl
components: Documentation
messages: 64450
nosy: brodierao, georg.brandl
severity: normal
status: open
title: optparse docs should mention %default being new in 2.4
type: feature request
versions: Python 2.4, Python 2.5, Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2476>
__________________________________
From report at bugs.python.org Tue Mar 25 07:15:48 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Tue, 25 Mar 2008 06:15:48 +0000
Subject: [New-bugs-announce] [issue2477] parser support for future import of
unicode_strings
In-Reply-To: <1206425748.68.0.392615437966.issue2477@psf.upfronthosting.co.za>
Message-ID: <1206425748.68.0.392615437966.issue2477@psf.upfronthosting.co.za>
New submission from Neal Norwitz <nnorwitz at gmail.com>:
This is a patch that modifies the parser to allow getting the future
import flags into the AST. There are 2 approaches that are embedded
within the patch. Both approaches can be seen in Python/pythonrun.c.
1) update_flags_from_node() - this pulls the __future__ import out of
the parser nodes. It is not complete, but should give an idea of how
this approach could be generalized.
2) Add APIS such as PyParser_ParseFileFlagsEx that returns the flags
from the parser
The first approach is somewhat fragile and kinda breaks encapsulation.
It's nice that all the changes are internal and localized.
The second approach is probably a better long term solution, but adds
even more APIs where there are already too many.
----------
components: Interpreter Core
files: uni-strs.diff
keywords: patch
messages: 64458
nosy: nnorwitz
priority: critical
severity: normal
status: open
title: parser support for future import of unicode_strings
versions: Python 2.6
Added file: http://bugs.python.org/file9844/uni-strs.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2477>
__________________________________
From report at bugs.python.org Tue Mar 25 11:13:48 2008
From: report at bugs.python.org (glathoud)
Date: Tue, 25 Mar 2008 10:13:48 +0000
Subject: [New-bugs-announce] [issue2478] decimal.Decimal( 0 ).sqrt() fails
Message-ID: <1206440028.99.0.198815518294.issue2478@psf.upfronthosting.co.za>
Changes by glathoud <glathoud at yahoo.fr>:
----------
components: Library (Lib)
nosy: glathoud
severity: normal
status: open
title: decimal.Decimal( 0 ).sqrt() fails
type: crash
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2478>
__________________________________
From report at bugs.python.org Tue Mar 25 12:05:51 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 25 Mar 2008 11:05:51 +0000
Subject: [New-bugs-announce] [issue2479] Bytearray and io backport
In-Reply-To: <1206443150.97.0.809624584179.issue2479@psf.upfronthosting.co.za>
Message-ID: <1206443150.97.0.809624584179.issue2479@psf.upfronthosting.co.za>
New submission from Christian Heimes <lists at cheimes.de>:
Fix the remaining tests and merge the branch into 2.6
svn+ssh://pythondev at svn.python.org/python/branches/trunk-bytearray
So far 5 unit tests are failing. Two are related to pickling/copy and
two to subclassing.
----------
components: Interpreter Core, Library (Lib), Tests
keywords: 26backport
messages: 64475
nosy: tiran
priority: critical
severity: normal
status: open
title: Bytearray and io backport
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2479>
__________________________________
From report at bugs.python.org Tue Mar 25 14:44:46 2008
From: report at bugs.python.org (Daniel Darabos)
Date: Tue, 25 Mar 2008 13:44:46 +0000
Subject: [New-bugs-announce] [issue2480] pickling of recursive sets of
objects fails
In-Reply-To: <1206452686.51.0.217993005172.issue2480@psf.upfronthosting.co.za>
Message-ID: <1206452686.51.0.217993005172.issue2480@psf.upfronthosting.co.za>
New submission from Daniel Darabos <darabos.daniel at gmail.com>:
In the attached demo I create a graph of 250 nodes, all of which are
connected to every other node, and this is represented by a set
attribute of the Node objects.
When I try to pickle this graph, it fails in various ways. In regular
pickle it is always a "maximum recursion depth exceeded" error. In
cPickle it is either a KeyError or a silent termination of the process.
(As tested on Windows XP 32 bits.) It depends on the size of the graph.
For smaller graphs (say 100 nodes) it works fine.
If connections are described using a dictionary or even a list, I get
the same errors.
----------
components: Library (Lib)
files: bugdemo.py
messages: 64481
nosy: cyhawk
severity: normal
status: open
title: pickling of recursive sets of objects fails
versions: Python 2.5
Added file: http://bugs.python.org/file9847/bugdemo.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2480>
__________________________________
From report at bugs.python.org Tue Mar 25 15:33:55 2008
From: report at bugs.python.org (Christoph Zwerschke)
Date: Tue, 25 Mar 2008 14:33:55 +0000
Subject: [New-bugs-announce] [issue2481] locale.strxfrm does not work with
Unicode strings
In-Reply-To: <1206455635.63.0.674389192114.issue2481@psf.upfronthosting.co.za>
Message-ID: <1206455635.63.0.674389192114.issue2481@psf.upfronthosting.co.za>
New submission from Christoph Zwerschke <cito at online.de>:
While locale.strcoll seems to work with Unicode strings, locale.strxfrm
gives a UnicodeError. Example:
###
try:
locale.setlocale(locale.LC_ALL, 'de')
except locale.Error: # Windoof
locale.setlocale(locale.LC_ALL, 'german')
s = ['?gypten', 'Zypern']
print sorted(s, cmp=locale.strcoll) # works
print sorted(s, key=locale.strxfrm) # works
s = [u'?gypten', u'Zypern']
print sorted(s, cmp=locale.strcoll) # works
print sorted(s, key=locale.strxfrm) # UnicodeError
###
Therefore, it is not possible to sort lists of Unicode strings
effectively. If possible, this should be fixed. If not possible, this
problem should at least be mentioned in the documentation. Currently,
the docs do not indicate that strcoll and strxfrm behave differently
concerning Unicode.
----------
components: Unicode
messages: 64484
nosy: cito
severity: normal
status: open
title: locale.strxfrm does not work with Unicode strings
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2481>
__________________________________
From report at bugs.python.org Tue Mar 25 16:37:13 2008
From: report at bugs.python.org (Oleg Broytmann)
Date: Tue, 25 Mar 2008 15:37:13 +0000
Subject: [New-bugs-announce] [issue2482] Decimal(unicode)
In-Reply-To: <1206459433.83.0.00721913185616.issue2482@psf.upfronthosting.co.za>
Message-ID: <1206459433.83.0.00721913185616.issue2482@psf.upfronthosting.co.za>
New submission from Oleg Broytmann <phd at phd.pp.ru>:
Decimal(u'123').to_eng_string() returns unicode in Python 2.5.2. That's
probably due to the optimization in decimal module, after which decimal
stores coefficient (mantissa) as a str, and doesn't coerce input to str.
See the thread at
http://mail.python.org/pipermail/python-dev/2008-March/078189.html
----------
components: Library (Lib)
messages: 64488
nosy: phd
severity: normal
status: open
title: Decimal(unicode)
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2482>
__________________________________
From report at bugs.python.org Tue Mar 25 17:22:00 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 25 Mar 2008 16:22:00 +0000
Subject: [New-bugs-announce] [issue2483] int and float accept bytes,
complex does not
In-Reply-To: <1206462120.7.0.66925954466.issue2483@psf.upfronthosting.co.za>
Message-ID: <1206462120.7.0.66925954466.issue2483@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
In 3.0, the int and float constructors accepts bytes instances as well as
strings:
>>> int(b'1')
1
>>> float(b'1')
1.0
but the complex constructor doesn't:
>>> complex(b'1')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: complex() argument must be a string or a number
I'd suggest that at least one of these three results is a bug,
but I'm not sure which.
>From a purity point of view, I think int() and float() shouldn't accept
bytes. Is this a case of practicality beats purity? What are the
pratical reasons to have int() and float() accept bytes?
Once this is resolved, the behaviors of Decimal and Fraction should also
be considered.
----------
components: Interpreter Core
messages: 64494
nosy: marketdickinson
severity: normal
status: open
title: int and float accept bytes, complex does not
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2483>
__________________________________
From report at bugs.python.org Tue Mar 25 18:00:05 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 25 Mar 2008 17:00:05 +0000
Subject: [New-bugs-announce] [issue2484] Cosmetic patch for warning "unused
variable"
In-Reply-To: <1206464405.54.0.178616668761.issue2484@psf.upfronthosting.co.za>
Message-ID: <1206464405.54.0.178616668761.issue2484@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:
"int i,j;" in inner block is hiding "Py_ssize_t i,j;"
----------
components: Extension Modules
files: fix_warning.patch
keywords: patch, patch
messages: 64499
nosy: ocean-city
severity: normal
status: open
title: Cosmetic patch for warning "unused variable"
versions: Python 3.0
Added file: http://bugs.python.org/file9854/fix_warning.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2484>
__________________________________
From report at bugs.python.org Tue Mar 25 22:28:01 2008
From: report at bugs.python.org (Martin Geisler)
Date: Tue, 25 Mar 2008 21:28:01 +0000
Subject: [New-bugs-announce] [issue2485] Traceback changed in 2.6 for
unhashable objects
In-Reply-To: <1206480481.83.0.917185709948.issue2485@psf.upfronthosting.co.za>
Message-ID: <1206480481.83.0.917185709948.issue2485@psf.upfronthosting.co.za>
New submission from Martin Geisler <mg at daimi.au.dk>:
The traceback message given when trying to hash unhashable objects has
changed from Python 2.5 to 2.6:
Python 2.5.2a0 (r251:54863, Feb 10 2008, 01:31:28)
>>> hash([])
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: list objects are unhashable
Python 2.6a1 (r26a1:61143, Mar 25 2008, 19:41:30)
>>> hash([])
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'
This breaks my Doctests unless I add a somewhat ugly "# doctest:
+IGNORE_EXCEPTION_DETAIL" comment, so if this is not done on purpose, I
would prefer Python 2.6 to output the same as 2.5.
----------
messages: 64517
nosy: mg
severity: normal
status: open
title: Traceback changed in 2.6 for unhashable objects
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2485>
__________________________________
From report at bugs.python.org Tue Mar 25 22:36:15 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 25 Mar 2008 21:36:15 +0000
Subject: [New-bugs-announce] [issue2486] Consider using bytes type instead
of str to store Decimal coefficients
In-Reply-To: <1206480975.35.0.923616350386.issue2486@psf.upfronthosting.co.za>
Message-ID: <1206480975.35.0.923616350386.issue2486@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
The Python 3.0 version of decimal.py currently stores the coefficient of
a Decimal number (or the payload of a NaN) as a string, all of whose
characters are in the range '0' through '9'.
It may be more time-efficient to store the coefficient as a bytes
instance instead, since bytes -> int conversion is likely to be faster
than str -> int conversion. On the other hand, int -> bytes conversion
has to go through str, so may be significantly slower than int -> str
conversion...
Bottom line: this needs testing.
One other option: it may even be worth considering storing the
coefficient directly as a Python integer. I've argued against this
before, on the basis that it makes direct access to the decimal digits
of a number harder, and this direct access is useful for rounding as
well as for some of the more esoteric Decimal operations (logical
operations, shifts and rotations). But it may be worth a look.
(I think it's clear what the *right* option is, given unlimited
developer time and energy: decimal.py should represent the coefficient
using a long integer implementation written in C, with wordsize a power
of 10---probably either 10**4 or 10**9.)
See related discussion at issue 2482 and at
http://mail.python.org/pipermail/python-dev/2008-March/078189.html
----------
components: Library (Lib)
messages: 64521
nosy: facundobatista, marketdickinson, ncoghlan
severity: normal
status: open
title: Consider using bytes type instead of str to store Decimal coefficients
type: performance
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2486>
__________________________________
From report at bugs.python.org Wed Mar 26 00:25:38 2008
From: report at bugs.python.org (Fredrik Johansson)
Date: Tue, 25 Mar 2008 23:25:38 +0000
Subject: [New-bugs-announce] [issue2487] ldexp(x,
n) misbehaves when abs(n) is large
In-Reply-To: <1206487537.98.0.104101200523.issue2487@psf.upfronthosting.co.za>
Message-ID: <1206487537.98.0.104101200523.issue2487@psf.upfronthosting.co.za>
New submission from Fredrik Johansson <fredrik.johansson at gmail.com>:
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.
>>> from math import ldexp
>>> from sys import maxint
>>> ldexp(1.234, maxint//2)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OverflowError: math range error
>>> ldexp(1.234, maxint)
0.0
>>> ldexp(1.234, -maxint)
0.0
>>> ldexp(1.234, -maxint-2)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to int
The first and third cases seem right.
The second is clearly a bug.
In the fourth case, it would be more correct to return 0.0 than to raise
an exception IMHO.
----------
components: Library (Lib)
messages: 64527
nosy: fredrikj
severity: normal
status: open
title: ldexp(x,n) misbehaves when abs(n) is large
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2487>
__________________________________
From report at bugs.python.org Wed Mar 26 00:35:50 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 25 Mar 2008 23:35:50 +0000
Subject: [New-bugs-announce] [issue2488] Backport sys.maxsize to Python 2.6
In-Reply-To: <1206488150.94.0.908333325517.issue2488@psf.upfronthosting.co.za>
Message-ID: <1206488150.94.0.908333325517.issue2488@psf.upfronthosting.co.za>
New submission from Christian Heimes <lists at cheimes.de>:
See topic
----------
components: Extension Modules
keywords: 26backport, easy
messages: 64528
nosy: tiran
priority: high
severity: normal
status: open
title: Backport sys.maxsize to Python 2.6
type: feature request
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2488>
__________________________________
From report at bugs.python.org Wed Mar 26 02:15:49 2008
From: report at bugs.python.org (Fergus Henderson)
Date: Wed, 26 Mar 2008 01:15:49 +0000
Subject: [New-bugs-announce] [issue2489] Patch for bugs in pty.py
In-Reply-To: <1206494149.11.0.607365562092.issue2489@psf.upfronthosting.co.za>
Message-ID: <1206494149.11.0.607365562092.issue2489@psf.upfronthosting.co.za>
New submission from Fergus Henderson <fergus.henderson at gmail.com>:
The attached patch fixes some bugs in the pty.py module:
- spawn() would not wait for the invoked process to finish.
Also, it did not return a meaningful value, so there was no way
to tell if the invoked process failed. After this patch,
spawn() now waits for the invoked process, and returns the value
returned from os.waitpid().
- There was a bug in the _copy() loop that caused it to spin
using 100% CPU rather than blocking after EOF was reached on
one of the two file descriptors that it was waiting for.
----------
components: Library (Lib)
files: pty.py.patch
keywords: patch
messages: 64533
nosy: fergushenderson
severity: normal
status: open
title: Patch for bugs in pty.py
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9861/pty.py.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2489>
__________________________________
From report at bugs.python.org Wed Mar 26 02:52:03 2008
From: report at bugs.python.org (Pierre Metras)
Date: Wed, 26 Mar 2008 01:52:03 +0000
Subject: [New-bugs-announce] [issue2490] Assertion failure in
datetime.strftime()
In-Reply-To: <1206496323.11.0.616426584007.issue2490@psf.upfronthosting.co.za>
Message-ID: <1206496323.11.0.616426584007.issue2490@psf.upfronthosting.co.za>
New submission from Pierre Metras <genepi at sympatico.ca>:
datetime.strftime(pattern) fails in assertion if pattern is big enough (>
100 chars) while time.strftime(pattern) gives the expected result.
This occurs on Python 2.5 (tested on OLPC XO laptop, Fedora 9). Python 2.4
(Debian Etch) does not exhibit this bug.
----------
components: Extension Modules
files: test.py
messages: 64536
nosy: genepi
severity: normal
status: open
title: Assertion failure in datetime.strftime()
versions: Python 2.5
Added file: http://bugs.python.org/file9862/test.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2490>
__________________________________
From report at bugs.python.org Wed Mar 26 05:24:19 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Wed, 26 Mar 2008 04:24:19 +0000
Subject: [New-bugs-announce] [issue2491] io.open() handles errors
differently on different platforms
In-Reply-To: <1206505459.01.0.185425865749.issue2491@psf.upfronthosting.co.za>
Message-ID: <1206505459.01.0.185425865749.issue2491@psf.upfronthosting.co.za>
New submission from Neal Norwitz <nnorwitz at gmail.com>:
The attached file has a snapshot of the python.org homepage that was
causing test_urllibnet to fail on some platforms (2 sparc, and ia64 at
least), but not other platforms. This should be handled consistently.
I don't know if there are really errors in the attached web page or not.
The problem occurs at byte offset 13259:
>>> data[13250:13270]
'r - Journ\xc3\xa9es Python'
I suppose that's invalid for ASCII, but valid UTF-8.
See r61921. There is a problem that the API for fdopen doesn't accept
errors, encoding, etc. so it's problematic to handle this condition.
----------
components: Library (Lib)
files: py-org.html
messages: 64540
nosy: nnorwitz
priority: critical
severity: normal
status: open
title: io.open() handles errors differently on different platforms
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file9864/py-org.html
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2491>
__________________________________
From report at bugs.python.org Wed Mar 26 12:53:57 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 26 Mar 2008 11:53:57 +0000
Subject: [New-bugs-announce] [issue2492] Check implementation of new buffer
interface for PyString in 2.6
In-Reply-To: <1206532437.27.0.353832301396.issue2492@psf.upfronthosting.co.za>
Message-ID: <1206532437.27.0.353832301396.issue2492@psf.upfronthosting.co.za>
New submission from Christian Heimes <lists at cheimes.de>:
I've only implemented (getbufferproc)string_buffer_getbuffer of the new
buffer protocol. Do I have to add "exports" to the PyString struct and
add a releasebufferproc, too?
----------
components: Interpreter Core
keywords: 26backport
messages: 64550
nosy: tiran
priority: high
severity: normal
status: open
title: Check implementation of new buffer interface for PyString in 2.6
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2492>
__________________________________
From report at bugs.python.org Wed Mar 26 15:47:35 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 26 Mar 2008 14:47:35 +0000
Subject: [New-bugs-announce] [issue2493] Remove unused constants from
optimized code objects
In-Reply-To: <1206542855.67.0.168475253552.issue2493@psf.upfronthosting.co.za>
Message-ID: <1206542855.67.0.168475253552.issue2493@psf.upfronthosting.co.za>
New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:
When peephole optimizer folds multiple constants into one, the old
constants remain in co_consts. Attached patch removes such unused
constants.
----------
components: Interpreter Core
files: compress-consts.diff
keywords: patch
messages: 64558
nosy: belopolsky
severity: normal
status: open
title: Remove unused constants from optimized code objects
type: resource usage
versions: Python 2.6
Added file: http://bugs.python.org/file9867/compress-consts.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2493>
__________________________________
From report at bugs.python.org Thu Mar 27 08:27:07 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 27 Mar 2008 07:27:07 +0000
Subject: [New-bugs-announce] [issue2494] Can't round-trip
datetimes<->timestamps prior to 1970 on Windows
In-Reply-To: <1206602826.96.0.687530064019.issue2494@psf.upfronthosting.co.za>
Message-ID: <1206602826.96.0.687530064019.issue2494@psf.upfronthosting.co.za>
New submission from Mark Summerfield <mark at qtrac.eu>:
# If you run the code below on Py30a3 you get the output shown at the end
import calendar, datetime, time
pastdate = datetime.datetime(1969, 12, 31)
print(pastdate)
timestamp = calendar.timegm(pastdate.utctimetuple())
print(timestamp)
try:
pastdate_x = datetime.datetime.utcfromtimestamp(timestamp)
except ValueError as err:
print("FAIL", err)
try:
print(time.strftime("%Y-%m-%dT%H:%M:%S", time.gmtime(timestamp)))
except ValueError as err:
print("FAIL", err)
r"""
Python 30a3
Windows output:
1969-12-31 00:00:00
-86400
FAIL timestamp out of range for platform localtime()/gmtime() function
FAIL (22, 'Invalid argument')
Linux output:
1969-12-31 00:00:00
-86400
1969-12-31T00:00:00
"""
# What this appears to show is that you can't round-trip between
datetimes and timestamps on Windows for dates prior to 1970
----------
components: Library (Lib)
messages: 64578
nosy: mark
severity: normal
status: open
title: Can't round-trip datetimes<->timestamps prior to 1970 on Windows
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2494>
__________________________________
From report at bugs.python.org Thu Mar 27 12:50:03 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 27 Mar 2008 11:50:03 +0000
Subject: [New-bugs-announce] [issue2495] tokenize doesn't handle
__future__.unicode_literals correctly
In-Reply-To: <1206618603.55.0.554342479222.issue2495@psf.upfronthosting.co.za>
Message-ID: <1206618603.55.0.554342479222.issue2495@psf.upfronthosting.co.za>
New submission from Christian Heimes <lists at cheimes.de>:
See r61976
Clear the blacklist and run the test with
./python Lib/test/regrtest.py -uall test_tokenize
to reproduce the issue.
----------
components: Library (Lib)
messages: 64582
nosy: tiran
priority: normal
severity: normal
status: open
title: tokenize doesn't handle __future__.unicode_literals correctly
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2495>
__________________________________
From report at bugs.python.org Thu Mar 27 13:04:35 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Mar 2008 12:04:35 +0000
Subject: [New-bugs-announce] [issue2496] test_no_refcycle_through_target
sometimes fails in test_threading
In-Reply-To: <1206619475.61.0.0373454947155.issue2496@psf.upfronthosting.co.za>
Message-ID: <1206619475.61.0.0373454947155.issue2496@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
This is a reminder for the failing test which is affecting some buildbots.
I can't reproduce it right now (under Linux), even by surrounding the
test code with a pair of gc.disable() / gc.enable().
----------
components: Library (Lib)
messages: 64584
nosy: nnorwitz, pitrou
severity: normal
status: open
title: test_no_refcycle_through_target sometimes fails in test_threading
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2496>
__________________________________
From report at bugs.python.org Thu Mar 27 15:37:12 2008
From: report at bugs.python.org (Rolland Dudemaine)
Date: Thu, 27 Mar 2008 14:37:12 +0000
Subject: [New-bugs-announce] [issue2497] stdbool support
In-Reply-To: <1206628632.31.0.556646353118.issue2497@psf.upfronthosting.co.za>
Message-ID: <1206628632.31.0.556646353118.issue2497@psf.upfronthosting.co.za>
New submission from Rolland Dudemaine <rolland at ghs.com>:
For better portability, it is good to support stdbool.h when it exists.
This prevents a potential issue when compiling asdl.c.
Patch attached.
----------
components: Build
files: python_stdbool_20080327.diff
keywords: patch
messages: 64594
nosy: rolland
severity: normal
status: open
title: stdbool support
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9875/python_stdbool_20080327.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2497>
__________________________________
From report at bugs.python.org Thu Mar 27 22:03:02 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 27 Mar 2008 21:03:02 +0000
Subject: [New-bugs-announce] [issue2498] bdb modernized
In-Reply-To: <1206651782.63.0.136220859042.issue2498@psf.upfronthosting.co.za>
Message-ID: <1206651782.63.0.136220859042.issue2498@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
bdb.py has several places like this:
try:
try: pass
except BdbQuit: pass
finally: pass
These can be modernized to the > 2.5 syntax.
----------
assignee: georg.brandl
components: Library (Lib)
files: bdb_modern.patch
keywords: patch
messages: 64607
nosy: benjamin.peterson, georg.brandl
severity: normal
status: open
title: bdb modernized
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file9879/bdb_modern.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2498>
__________________________________
From report at bugs.python.org Fri Mar 28 05:05:18 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 Mar 2008 04:05:18 +0000
Subject: [New-bugs-announce] [issue2499] Fold unary + and not on constants
In-Reply-To: <1206677118.63.0.142364619401.issue2499@psf.upfronthosting.co.za>
Message-ID: <1206677118.63.0.142364619401.issue2499@psf.upfronthosting.co.za>
New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:
Before:
>>> dis(lambda:+2)
1 0 LOAD_CONST 0 (2)
3 UNARY_POSITIVE
4 RETURN_VALUE
>>> dis(lambda:not 2)
1 0 LOAD_CONST 0 (2)
3 UNARY_NOT
4 RETURN_VALUE
After:
>>> dis(lambda:+2)
1 0 LOAD_CONST 1 (2)
3 RETURN_VALUE
>>> dis(lambda:not 2)
1 0 LOAD_CONST 1 (False)
3 RETURN_VALUE
----------
components: Interpreter Core
files: fold-unary.diff
keywords: patch
messages: 64613
nosy: belopolsky
severity: normal
status: open
title: Fold unary + and not on constants
type: resource usage
versions: Python 2.6
Added file: http://bugs.python.org/file9880/fold-unary.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2499>
__________________________________
From report at bugs.python.org Fri Mar 28 11:04:31 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 28 Mar 2008 10:04:31 +0000
Subject: [New-bugs-announce] [issue2500] Sync _sqlite module code
In-Reply-To: <1206698671.09.0.0786877274007.issue2500@psf.upfronthosting.co.za>
Message-ID: <1206698671.09.0.0786877274007.issue2500@psf.upfronthosting.co.za>
New submission from Christian Heimes <lists at cheimes.de>:
The source code of the _sqlite module in 3.0 is not in sync with the
code from 2.6. Some features and fixes are missing. If I recall
correctly I didn't merge a revision from 2.6 to 3.0 because 2.6a1 and
3.0a3 were released on the same day.
----------
assignee: ghaering
components: Extension Modules
messages: 64623
nosy: ghaering, tiran
priority: critical
severity: normal
status: open
title: Sync _sqlite module code
type: feature request
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2500>
__________________________________
From report at bugs.python.org Fri Mar 28 11:15:13 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Fri, 28 Mar 2008 10:15:13 +0000
Subject: [New-bugs-announce] [issue2501] xml.sax.parser() doesn't terminate
when given a filename
In-Reply-To: <1206699313.91.0.35803015757.issue2501@psf.upfronthosting.co.za>
Message-ID: <1206699313.91.0.35803015757.issue2501@psf.upfronthosting.co.za>
New submission from Mark Summerfield <mark at qtrac.eu>:
The tiny program at the end of this message runs under Python 2.5 &
30a3. Under 2 it gives the following output:
: python sax.py test.xml
('+', u'document')
('+', u'outer')
('+', u'inner')
('-', u'inner')
('-', u'outer')
('-', u'document')
Done
Under 3 it does not terminate:
: python3 sax.py test.xml
+ document
+ outer
+ inner
- inner
- outer
- document
Traceback (most recent call last):
File "sax.py", line 19, in <module>
parser.parse(sys.argv[1])
File "/home/mark/opt/python30a3/lib/python3.0/xml/sax/expatreader.py",
line 107, in parse
xmlreader.IncrementalParser.parse(self, source)
File "/home/mark/opt/python30a3/lib/python3.0/xml/sax/xmlreader.py",
line 124, in parse
buffer = file.read(self._bufsize)
File "/home/mark/opt/python30a3/lib/python3.0/io.py", line 774, in read
current = self.raw.read(to_read)
KeyboardInterrupt
The xml.sax.parser() function seems to work fine if you give it an open
file object and close the file after the call. But the documentation
says you can give it a filename, but if you do that the parser does not
terminate in Python 3 although it works fine in Python 2.
# sax.py
import sys
import xml.sax
BUG = True
class SaxHandler(xml.sax.handler.ContentHandler):
def startElement(self, name, attributes):
print("+", name)
def endElement(self, name):
print("-", name)
handler = SaxHandler()
parser = xml.sax.make_parser()
parser.setContentHandler(handler)
if BUG:
parser.parse(sys.argv[1])
else:
fh = open(sys.argv[1], encoding="utf8")
parser.parse(fh)
fh.close()
print("Done")
# end of sax.py
Here is the test file:
<?xml version="1.0" encoding="UTF-8"?>
<document>
<outer>
<inner>
</inner>
</outer>
</document>
----------
components: XML
messages: 64625
nosy: mark
severity: normal
status: open
title: xml.sax.parser() doesn't terminate when given a filename
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2501>
__________________________________
From report at bugs.python.org Fri Mar 28 12:05:19 2008
From: report at bugs.python.org (Wummel)
Date: Fri, 28 Mar 2008 11:05:19 +0000
Subject: [New-bugs-announce] [issue2502] Add enum() example for named tuples
In-Reply-To: <1206702319.7.0.998063864211.issue2502@psf.upfronthosting.co.za>
Message-ID: <1206702319.7.0.998063864211.issue2502@psf.upfronthosting.co.za>
New submission from Wummel <calvin at users.sourceforge.net>:
Named tuples can also be used to emulate enum datatypes. The patch adds
an example to the documentation.
----------
assignee: georg.brandl
components: Documentation
files: 0001-Add-enum-example-for-named-tuples.patch
keywords: patch
messages: 64627
nosy: calvin, georg.brandl
severity: normal
status: open
title: Add enum() example for named tuples
versions: Python 2.6
Added file: http://bugs.python.org/file9881/0001-Add-enum-example-for-named-tuples.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2502>
__________________________________
From report at bugs.python.org Fri Mar 28 12:06:50 2008
From: report at bugs.python.org (Wummel)
Date: Fri, 28 Mar 2008 11:06:50 +0000
Subject: [New-bugs-announce] [issue2503] Replace "== None/True/False" with
"is"
In-Reply-To: <1206702410.08.0.751356671571.issue2503@psf.upfronthosting.co.za>
Message-ID: <1206702410.08.0.751356671571.issue2503@psf.upfronthosting.co.za>
New submission from Wummel <calvin at users.sourceforge.net>:
Test equality with None/True/False singletons should be done
by "is" rather than "==" to be on the safe side. Otherwise
objects overriding __eq__ could compare equal to one of those
singletons.
----------
components: None
files: 0001-Replace-None-True-False-with-is.patch
keywords: patch
messages: 64628
nosy: calvin
severity: normal
status: open
title: Replace "== None/True/False" with "is"
versions: Python 2.6
Added file: http://bugs.python.org/file9882/0001-Replace-None-True-False-with-is.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2503>
__________________________________
From report at bugs.python.org Sat Mar 29 03:10:24 2008
From: report at bugs.python.org (Pierre Metras)
Date: Sat, 29 Mar 2008 02:10:24 +0000
Subject: [New-bugs-announce] [issue2504] Add gettext.pgettext() and variants
support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
New submission from Pierre Metras <genepi at sympatico.ca>:
Please add support for pgettext(msgctxt, msgid) and variants (dpgettext,
dcpgettext...) in the gettext module.
I will not rephrase the justification for these functions and why
contexts are essential for good localization:
http://www.gnu.org/software/gettext/manual/gettext.html#Contexts
----------
components: Extension Modules
messages: 64675
nosy: genepi
severity: normal
status: open
title: Add gettext.pgettext() and variants support
type: feature request
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
__________________________________
From report at bugs.python.org Sat Mar 29 14:38:10 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 29 Mar 2008 13:38:10 +0000
Subject: [New-bugs-announce] [issue2505] Restrict attributes of _ast nodes
In-Reply-To: <1206797890.8.0.128090233535.issue2505@psf.upfronthosting.co.za>
Message-ID: <1206797890.8.0.128090233535.issue2505@psf.upfronthosting.co.za>
New submission from Georg Brandl <georg at python.org>:
This patch adds two things to the _ast module:
* Nodes can be initialized with keyword arguments:
m = _ast.Module(body=[...])
* Only attributes that are in _fields or _attributes can be set on nodes.
Martin, what do you think?
----------
assignee: loewis
components: Extension Modules
files: ast-attrs.diff
keywords: patch
messages: 64691
nosy: georg.brandl, loewis
severity: normal
status: open
title: Restrict attributes of _ast nodes
type: behavior
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9887/ast-attrs.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2505>
__________________________________
From report at bugs.python.org Sat Mar 29 14:38:41 2008
From: report at bugs.python.org (Ned Batchelder)
Date: Sat, 29 Mar 2008 13:38:41 +0000
Subject: [New-bugs-announce] [issue2506] Line tracing of continue after
always-taken if is incorrect
In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za>
Message-ID: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za>
New submission from Ned Batchelder <nedbat at users.sourceforge.net>:
When tracing line execution with sys.settrace, a particular code
structure fails to report an executed line. The line is a continue
statement after an if condition in which the if condition is true every
time it is executed.
Attached is a file with two copies of the same code, except in the first
the if condition is always true, and in the second it is sometimes true.
In the first, trace.py reports that the continue is never executed,
even though it is (as evidenced from the values of a, b, and c after
execution).
In the second code, the continue is properly reported.
This bug has been present since version 2.3. 2.2 does not exhibit it
(trace.py didn't exist in 2.2, but coverage.py shows the problem also).
To see the problem, execute "trace.py -c -m continue.py". Then
continue.py.cover will show:
1: a = b = c = 0
101: for n in range(100):
100: if n % 2:
50: if n % 4:
50: a += 1
>>>>>> continue
else:
50: b += 1
50: c += 1
1: assert a == 50 and b == 50 and c == 50
1: a = b = c = 0
101: for n in range(100):
100: if n % 2:
50: if n % 3:
33: a += 1
17: continue
else:
50: b += 1
50: c += 1
1: assert a == 33 and b == 50 and c == 50
----------
components: Interpreter Core
files: continue.py
messages: 64692
nosy: nedbat
severity: normal
status: open
title: Line tracing of continue after always-taken if is incorrect
type: behavior
versions: Python 2.3, Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9888/continue.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2506>
__________________________________
From report at bugs.python.org Sat Mar 29 15:28:38 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 Mar 2008 14:28:38 +0000
Subject: [New-bugs-announce] [issue2507] Exception state lives too long in
3.0
In-Reply-To: <1206800918.45.0.478667091266.issue2507@psf.upfronthosting.co.za>
Message-ID: <1206800918.45.0.478667091266.issue2507@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
See http://mail.python.org/pipermail/python-3000/2008-March/012830.html
: the exception state can survive across thread switches if the
enclosing frame is not destroyed immediately.
----------
components: Interpreter Core
messages: 64697
nosy: jyasskin, pitrou
severity: normal
status: open
title: Exception state lives too long in 3.0
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2507>
__________________________________
From report at bugs.python.org Sat Mar 29 16:55:35 2008
From: report at bugs.python.org (kobi)
Date: Sat, 29 Mar 2008 15:55:35 +0000
Subject: [New-bugs-announce] [issue2508] When you create a file using
file(path,
"w") if the filename is illegal it throws an irrelevant error message
Message-ID: <1206806135.36.0.409722603539.issue2508@psf.upfronthosting.co.za>
Changes by kobi <kobipe3 at gmail.com>:
----------
nosy: kobipe3
severity: normal
status: open
title: When you create a file using file(path, "w") if the filename is illegal it throws an irrelevant error message
type: resource usage
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2508>
__________________________________
From report at bugs.python.org Sat Mar 29 18:07:02 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 29 Mar 2008 17:07:02 +0000
Subject: [New-bugs-announce] [issue2509] Bazaar ignore file
In-Reply-To: <1206810422.5.0.478405887603.issue2509@psf.upfronthosting.co.za>
Message-ID: <1206810422.5.0.478405887603.issue2509@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
I basically copied all the svn:ignore props into this file...
----------
components: None
files: bzr-ignore.patch
keywords: easy, patch
messages: 64707
nosy: barry, benjamin.peterson, georg.brandl
severity: normal
status: open
title: Bazaar ignore file
type: feature request
Added file: http://bugs.python.org/file9890/bzr-ignore.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2509>
__________________________________
From report at bugs.python.org Sat Mar 29 18:07:11 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 29 Mar 2008 17:07:11 +0000
Subject: [New-bugs-announce] [issue2510] Bazaar ignore file
In-Reply-To: <1206810431.77.0.422106495964.issue2510@psf.upfronthosting.co.za>
Message-ID: <1206810431.77.0.422106495964.issue2510@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
I basically copied all the svn:ignore props into this file...
----------
components: None
files: bzr-ignore.patch
keywords: easy, patch
messages: 64708
nosy: barry, benjamin.peterson, georg.brandl
severity: normal
status: open
title: Bazaar ignore file
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file9891/bzr-ignore.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2510>
__________________________________
From report at bugs.python.org Sat Mar 29 19:30:08 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 29 Mar 2008 18:30:08 +0000
Subject: [New-bugs-announce] [issue2511] Give AST's excepthandler proper
attributes
In-Reply-To: <1206815408.44.0.121788242529.issue2511@psf.upfronthosting.co.za>
Message-ID: <1206815408.44.0.121788242529.issue2511@psf.upfronthosting.co.za>
New submission from Georg Brandl <georg at python.org>:
The ASDL file has an XXX comment about excepthandler's lineno and
col_offset -- they are not attributes but fields which gets confusing
when this is exported to Python code. I think the only way to solve this
is to make it a "trivial" Sum with one element. This patch does that.
----------
assignee: loewis
components: Interpreter Core
files: ast-except.diff
keywords: patch
messages: 64714
nosy: georg.brandl, loewis
severity: normal
status: open
title: Give AST's excepthandler proper attributes
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9892/ast-except.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2511>
__________________________________
From report at bugs.python.org Sat Mar 29 23:08:32 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 29 Mar 2008 22:08:32 +0000
Subject: [New-bugs-announce] [issue2512] decide what to do with gettext API
In-Reply-To: <1206828512.7.0.626832335532.issue2512@psf.upfronthosting.co.za>
Message-ID: <1206828512.7.0.626832335532.issue2512@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
The gettext module currently has functions and methods beginning with
"u" to designate functions which return unicode objects. The install
function/method also has a "unicode" parameter. These are obviously
useless in Py3k. The attached patch removes the u prefixed functions and
and unicode parameters. Docs updates are included.
PS. If you're interested, the Bazaar branch I developed this on is at
http://code.python.org/python/users/benjamin.peterson/py3k_gettext_api/.
----------
components: Library (Lib)
keywords: patch
messages: 64733
nosy: barry, benjamin.peterson
priority: critical
severity: normal
status: open
title: decide what to do with gettext API
type: feature request
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2512>
__________________________________
From report at bugs.python.org Sun Mar 30 09:01:24 2008
From: report at bugs.python.org (Mark Hammond)
Date: Sun, 30 Mar 2008 07:01:24 +0000
Subject: [New-bugs-announce] [issue2513] 64bit cross compilation on windows
In-Reply-To: <1206860484.75.0.951116061983.issue2513@psf.upfronthosting.co.za>
Message-ID: <1206860484.75.0.951116061983.issue2513@psf.upfronthosting.co.za>
New submission from Mark Hammond <mhammond at users.sourceforge.net>:
I've taken the liberty of adding Trent, Christian and Martin to the nosy
list as I know they are actively, if reluctantly interested in this.
This patch allows the distutils to cross-compile on Windows. It has
been tested on x86 and amd64 platforms, with both platforms successfully
able to natively and cross-compile extension modules and create binary
distributions.
To cross-compile, specify '--plat-name' to the build command (valid
values are 'win32', 'win-amd64' and 'win-ia64'). This option name was
chosen to be consistent with the bdist_dumb command. I've included the
docs I added below (which are also in the patch), but note that as with
native compilation using distutils, it's not necessary to set any
environment variables or do anything else special with your environment
to make this work.
The patch also adds a x64 target for the 'bdist_wininst' target, which
it creates as distutils/command/wininst-9.0-amd64.exe. This executable
is necessary even for bdist_wininst to work natively on x64, but is
still included here for simplicity.
To assist with testing, I've also added a distutils setup.py script to
the PC/example_nt directory. This is capable of creating bdist_wininst
executables for both native and cross platforms; 'setup.py build
--platname=win-amd64 bdist_wininst' will create an amd64 installer on an
x86 machine.
The patch has not been tested with a Visual Studio environment without
cross-compile tools installed - it will obviously fail, but its not
clear how ugly this failure will be.
Below is the text I added to docs/distutils/builtdist.rst:
Cross-compiling on Windows
=====================
Starting with Python 2.6, distutils is capable of cross-compiling
between Windows platforms. In practice, this means that with the
correct tools installed, you can use a 32bit version of Windows to
create 64bit extensions and vice-versa.
To build for an alternate platform, specify the :option:`--plat-name`
option to the build command. Valid values are currently 'win32',
'win-amd64' and 'win-ia64'. For example, on a 32bit version of Windows,
you could execute::
python setup.py build --plat-name=win-amd64
to build a 64bit version of your extension. The Windows Installers
also support this option, so the command::
python setup.py build --plat-name=win-amd64 bdist_wininst
would create a 64bit installation executable on your 32bit version of
Windows.
Note that by default, Visual Studio 2008 does not install 64bit
compilers or tools. You may need to reexecute the Visual Studio setup
process and select these tools.
----------
assignee: mhammond
components: Distutils
files: windows-cross-compile.patch
keywords: 64bit, patch
messages: 64743
nosy: Trent.Nelson, ctheune, loewis, mhammond
severity: normal
status: open
title: 64bit cross compilation on windows
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file9900/windows-cross-compile.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2513>
__________________________________
From report at bugs.python.org Sun Mar 30 12:46:44 2008
From: report at bugs.python.org (Armin Ronacher)
Date: Sun, 30 Mar 2008 10:46:44 +0000
Subject: [New-bugs-announce] [issue2514] new AST init breaks on Store and
other fieldless Nodes
In-Reply-To: <1206874004.35.0.00269760141772.issue2514@psf.upfronthosting.co.za>
Message-ID: <1206874004.35.0.00269760141772.issue2514@psf.upfronthosting.co.za>
New submission from Armin Ronacher <armin.ronacher at active-4.com>:
#2505 adds a new init to the ast nodes that allows initialization of the
fields directory from the constructor. Unfortunately there are nodes
where fields is None (_ast.Store and others) and the constructor didn't
take care of this.
The patch applied adds a test for None to fix the problem.
----------
components: Extension Modules
files: initfix.diff
keywords: patch
messages: 64746
nosy: aronacher
severity: normal
status: open
title: new AST init breaks on Store and other fieldless Nodes
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9901/initfix.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2514>
__________________________________
From report at bugs.python.org Sun Mar 30 18:43:44 2008
From: report at bugs.python.org (Paul Davis)
Date: Sun, 30 Mar 2008 16:43:44 +0000
Subject: [New-bugs-announce] [issue2515] Segfault while operating on closed
sqlite3 cursor.
In-Reply-To: <1206895424.89.0.255529765862.issue2515@psf.upfronthosting.co.za>
Message-ID: <1206895424.89.0.255529765862.issue2515@psf.upfronthosting.co.za>
New submission from Paul Davis <paul.joseph.davis at gmail.com>:
Replicated on:
#Ubuntu 7.0
Python 2.5.1 (r251:54863, Mar 7 2008, 03:39:23)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
#OS 10.4.11
Python 2.5.1 (r251:54863, Oct 26 2007, 16:52:32)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
#OS 10.5.2
Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
----------
components: Library (Lib)
files: sqlite_segfault.py
messages: 64753
nosy: pjdavis
severity: normal
status: open
title: Segfault while operating on closed sqlite3 cursor.
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file9903/sqlite_segfault.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2515>
__________________________________
From report at bugs.python.org Mon Mar 31 00:23:35 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 30 Mar 2008 22:23:35 +0000
Subject: [New-bugs-announce] [issue2516] Instance methods are misreporting
the number of arguments
In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za>
Message-ID: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za>
New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:
Opening a new issue per Raymond's request at msg64764:
"""
It would be *much* more useful to direct effort improving the mis-
reporting of the number of arguments given versus those required for
instance methods:
>>> a.f(1, 2)
TypeError: f() takes exactly 1 argument (3 given)
"""
I would suggest that this misreporting may be dear to old-beards
reminding the time when there was not as much difference between methods
and functions as there is now.
It does not seem to be that hard to change the diagnostic to
>>> a.f(1, 2)
TypeError: f() takes no arguments (2 given)
but the novice users would much rather see "a.f() takes no arguments (2
given)." The later is unfortunately not possible.
Raymond, what would you say to "<class 'A' instance>.f() takes no
arguments (2 given)" diagnostic?
----------
components: Interpreter Core
messages: 64767
nosy: belopolsky, rhettinger
severity: normal
status: open
title: Instance methods are misreporting the number of arguments
type: behavior
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2516>
__________________________________
From report at bugs.python.org Mon Mar 31 01:13:52 2008
From: report at bugs.python.org (Christoph Burgmer)
Date: Sun, 30 Mar 2008 23:13:52 +0000
Subject: [New-bugs-announce] [issue2517] Error when printing an exception
containing a Unicode string
In-Reply-To: <1206918832.8.0.542354120577.issue2517@psf.upfronthosting.co.za>
Message-ID: <1206918832.8.0.542354120577.issue2517@psf.upfronthosting.co.za>
New submission from Christoph Burgmer <cburgmer at ira.uka.de>:
Python seems to have problems when an exception is thrown that
contains non-ASCII text as a message and is converted to a string.
>>> try:
... raise Exception(u'Error when printing ?')
... except Exception, e:
... print e
...
Traceback (most recent call last):
File "", line 4, in ?
UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in
position 20:
ordinal not in range(128)
See
http://www.stud.uni-karlsruhe.de/~uyhc/de/content/python-and-exceptions-containing-unicode-messages
----------
components: Unicode
messages: 64770
nosy: christoph
severity: normal
status: open
title: Error when printing an exception containing a Unicode string
type: behavior
versions: Python 2.4, Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2517>
__________________________________
From report at bugs.python.org Mon Mar 31 07:11:57 2008
From: report at bugs.python.org (HiroakiKawai)
Date: Mon, 31 Mar 2008 05:11:57 +0000
Subject: [New-bugs-announce] [issue2518] smtpd.py to handle huge email
In-Reply-To: <1206940317.15.0.464118270083.issue2518@psf.upfronthosting.co.za>
Message-ID: <1206940317.15.0.464118270083.issue2518@psf.upfronthosting.co.za>
New submission from HiroakiKawai <kawai at apache.org>:
I had some problems when I wanted to do attach a huge data file (such
as mp3, avi, or etc.) to an email. Current smtpd.py in Python2.5 calls
process_message that takes a string for its argument. This cause python
running process to consume too much memory.
I'd like to suggest an alternative method for this purpose
process_message_huge that takes a file-descriptor for its argument. The
patch will use process_message_huge if the method exists, otherwise, it
will call process_message with a string that will consume a huge memory
for backward compatibility.
----------
components: Library (Lib)
files: smtpd.patch
keywords: patch
messages: 64776
nosy: kawai
severity: normal
status: open
title: smtpd.py to handle huge email
type: security
versions: Python 2.5
Added file: http://bugs.python.org/file9909/smtpd.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2518>
__________________________________
From report at bugs.python.org Mon Mar 31 09:39:56 2008
From: report at bugs.python.org (Dennis Kaarsemaker)
Date: Mon, 31 Mar 2008 07:39:56 +0000
Subject: [New-bugs-announce] [issue2519] Typing 'modules' in the interactive
help system fails when imports fail
In-Reply-To: <1206949196.03.0.881908306183.issue2519@psf.upfronthosting.co.za>
Message-ID: <1206949196.03.0.881908306183.issue2519@psf.upfronthosting.co.za>
New submission from Dennis Kaarsemaker <dennis at kaarsemaker.net>:
If a certain module cannot be imported, this error is not caught and
warned about by pydoc, but will cause 'modules' to fail. This could be
considered a bug in the module but it would still be nice if 3rd party
modules cannot break pydoc. Example:
dennis at mirage:~$ python
Python 2.5.2 (r252:60911, Mar 12 2008, 13:36:25)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> help()
Welcome to Python 2.5! This is the online help utility.
[... snip ...]
help> modules
Please wait a moment while I gather a list of all available modules...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.5/site.py", line 342, in __call__
return pydoc.help(*args, **kwds)
File "/usr/lib/python2.5/pydoc.py", line 1649, in __call__
self.interact()
File "/usr/lib/python2.5/pydoc.py", line 1667, in interact
self.help(request)
File "/usr/lib/python2.5/pydoc.py", line 1683, in help
elif request == 'modules': self.listmodules()
File "/usr/lib/python2.5/pydoc.py", line 1804, in listmodules
ModuleScanner().run(callback)
File "/usr/lib/python2.5/pydoc.py", line 1855, in run
for importer, modname, ispkg in pkgutil.walk_packages():
File "/usr/lib/python2.5/pkgutil.py", line 125, in walk_packages
for item in walk_packages(path, name+'.', onerror):
[... snip -- the actual error isn't important ...]
OperationalError: no such table: falcon_configurationkey
>>>
I think it would be relatively easy to work around such bugs in 3rd
party modules by passing a callable to walk_packages that will give a
warning when an import fails instead of breaking.
----------
components: Library (Lib)
messages: 64778
nosy: dennis
severity: normal
status: open
title: Typing 'modules' in the interactive help system fails when imports fail
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2519>
__________________________________
From report at bugs.python.org Mon Mar 31 17:07:22 2008
From: report at bugs.python.org (John Buckley)
Date: Mon, 31 Mar 2008 15:07:22 +0000
Subject: [New-bugs-announce] [issue2520] macerrors.py cannot be imported due
to non-ascii characters in comments
In-Reply-To: <1206976042.0.0.654029091605.issue2520@psf.upfronthosting.co.za>
Message-ID: <1206976042.0.0.654029091605.issue2520@psf.upfronthosting.co.za>
New submission from John Buckley <nhoj.buckley at gmail.com>:
Cannot import macerrors due to non-ascii characters appearing in comments.
Patch attached.
----------
components: Library (Lib), Macintosh
files: macerrors.patch
keywords: patch
messages: 64783
nosy: thecube
severity: normal
status: open
title: macerrors.py cannot be imported due to non-ascii characters in comments
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9911/macerrors.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2520>
__________________________________
From report at bugs.python.org Mon Mar 31 17:12:30 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 31 Mar 2008 15:12:30 +0000
Subject: [New-bugs-announce] [issue2521] ABC caches should use weak refs
In-Reply-To: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za>
Message-ID: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:
The following function seems to 8 references each time it is run:
import io, gc
def f():
class C: pass
c=C()
assert isinstance(c, io.StringIO) is False
gc.collect();gc.collect();gc.collect()
This is because io.StringIO._abc_negative_cache contains a strong
reference to each "class C", as soon as isinstance() is called. These
are never released.
Python3.0 does use WeakSet for these caches, and does not leak.
This is the (deep) reason why test_io.IOTest.test_destructor() leaks in
the following report:
http://mail.python.org/pipermail/python-checkins/2008-March/067918.html
(The test derives from io.FileIO, and it is the call to the base class'
method which calls isinstance() and put the class in the cache)
----------
components: Interpreter Core
keywords: 26backport
messages: 64784
nosy: amaury.forgeotdarc
severity: normal
status: open
title: ABC caches should use weak refs
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2521>
__________________________________
From report at bugs.python.org Mon Mar 31 19:08:09 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Mon, 31 Mar 2008 17:08:09 +0000
Subject: [New-bugs-announce] [issue2522] locale.format() problems with
decimal separator
In-Reply-To: <1206983289.11.0.844443108334.issue2522@psf.upfronthosting.co.za>
Message-ID: <1206983289.11.0.844443108334.issue2522@psf.upfronthosting.co.za>
New submission from Andrii V. Mishkovskyi <mishok13 at gmail.com>:
locale.format() doesn't insert correct decimal separator to string
representation when 'format' argument has '\r' or '\n' symbols in it.
This bug has been reproduced on Python 2.5.2 and svn-trunk.
Python 2.4.5 (#2, Mar 12 2008, 14:42:24)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "ru_RU.UTF-8")
'ru_RU.UTF-8'
>>> a = 1.234
>>> print locale.format("%f", a)
1,234000
>>> print locale.format("%f\n", a)
1,234000
>>> print locale.format("%f\r", a)
1,234000
Python 2.6a1+ (trunk:62083, Mar 31 2008, 19:24:56)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "ru_RU.UTF-8")
'ru_RU.UTF-8'
>>> a = 1.234
>>> print locale.format("%f", a)
1,234000
>>> print locale.format("%f\n", a)
1.234000
>>> print locale.format("%f\r", a)
1.234000
Python 2.5.2 (r252:60911, Mar 12 2008, 13:36:25)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "ru_RU.UTF-8")
'ru_RU.UTF-8'
>>> a = 1.234
>>> print locale.format("%f", a)
1,234000
>>> print locale.format("%f\n", a)
1.234000
>>> print locale.format("%f\r", a)
1.234000
----------
messages: 64787
nosy: mishok13
severity: normal
status: open
title: locale.format() problems with decimal separator
type: behavior
versions: Python 2.5, Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2522>
__________________________________
From report at bugs.python.org Mon Mar 31 20:11:25 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 31 Mar 2008 18:11:25 +0000
Subject: [New-bugs-announce] [issue2523] binary buffered reading is quadratic
In-Reply-To: <1206987085.65.0.944826780657.issue2523@psf.upfronthosting.co.za>
Message-ID: <1206987085.65.0.944826780657.issue2523@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
In py3k, buffered binary IO can be quadratic when e.g. reading a whole file.
This is a small test on 50KB, 100KB and 200KB files:
-> py3k with buffering:
./python -m timeit -s "f = open('50KB', 'rb')" "f.seek(0); f.read()"
1000 loops, best of 3: 286 usec per loop
./python -m timeit -s "f = open('100KB', 'rb')" "f.seek(0); f.read()"
1000 loops, best of 3: 1.07 msec per loop
./python -m timeit -s "f = open('200KB', 'rb')" "f.seek(0); f.read()"
100 loops, best of 3: 4.85 msec per loop
-> py3k without buffering (just the raw FileIO layer):
./python -m timeit -s "f = open('50KB', 'rb', buffering=0)" "f.seek(0);
f.read()"
10000 loops, best of 3: 46 usec per loop
./python -m timeit -s "f = open('100KB', 'rb', buffering=0)" "f.seek(0);
f.read()"
10000 loops, best of 3: 88.7 usec per loop
./python -m timeit -s "f = open('200KB', 'rb', buffering=0)" "f.seek(0);
f.read()"
10000 loops, best of 3: 156 usec per loop
-> for comparison, Python 2.5:
python -m timeit -s "f = open('50KB', 'rb')" "f.seek(0); f.read()"
10000 loops, best of 3: 34.4 usec per loop
python -m timeit -s "f = open('100KB', 'rb')" "f.seek(0); f.read()"
10000 loops, best of 3: 62.3 usec per loop
python -m timeit -s "f = open('200KB', 'rb')" "f.seek(0); f.read()"
10000 loops, best of 3: 119 usec per loop
I'm posting this issue as a reminder, but perhaps someone is already
working on this, or the goal is to translate it to C ultimately?
----------
components: Library (Lib)
messages: 64788
nosy: pitrou
severity: normal
status: open
title: binary buffered reading is quadratic
type: performance
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2523>
__________________________________
From report at bugs.python.org Mon Mar 31 22:36:42 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Mon, 31 Mar 2008 20:36:42 +0000
Subject: [New-bugs-announce] [issue2524] IDLE 3.0
Message-ID: <1206995802.65.0.739781306453.issue2524@psf.upfronthosting.co.za>
Changes by Kurt B. Kaiser <kbk at shore.net>:
----------
components: IDLE
nosy: kbk
severity: normal
status: open
title: IDLE 3.0
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2524>
__________________________________