From report at bugs.python.org Sun Feb 1 04:07:01 2009
From: report at bugs.python.org (Ben Kuhn)
Date: Sun, 01 Feb 2009 03:07:01 +0000
Subject: [New-bugs-announce] [issue5121] PyRun_InteractiveLoop disagrees
with documentation?
In-Reply-To: <1233457621.0.0.661616898289.issue5121@psf.upfronthosting.co.za>
Message-ID: <1233457621.0.0.661616898289.issue5121@psf.upfronthosting.co.za>
New submission from Ben Kuhn <ben.s.kuhn at gmail.com>:
The description of PyRun_InteractiveLoop(FILE * file, const char *
filename) states that if filename is NULL, "???" will be used instead.
In actuality, if the method is called with a NULL filename, it will
segfault after the first command is entered.
Example:
//main.c
#include <Python.h>
int main(int argc, char * argv[]) {
Py_Initialize();
PyRun_InteractiveLoop(stdin, NULL);
}
//stdin
>>>import math
results in a segfault.
Python 3.0, Windows 7 beta, MinGW -LC:\Python30\libs -lpython30, 32-bit
Intel.
----------
components: Interpreter Core
messages: 80900
nosy: bkuhn
severity: normal
status: open
title: PyRun_InteractiveLoop disagrees with documentation?
type: behavior
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5121>
_______________________________________
From report at bugs.python.org Sun Feb 1 05:45:09 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 01 Feb 2009 04:45:09 +0000
Subject: [New-bugs-announce] [issue5122] test_tcl and test_ttk_guionly don't
like each other
In-Reply-To: <1233463509.87.0.136338063831.issue5122@psf.upfronthosting.co.za>
Message-ID: <1233463509.87.0.136338063831.issue5122@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
Recently I've added this test named test_ttk_guionly, and I noticed some
buildslaves went red, like amd64 gentoo trunk and x86 FreeBSD trunk (I
though there were others for the reason I'm going to say next, but
didn't found on a quick look).
amd 64 gentoo trunk is failing with:
.
.
test_ttk_guionly
test_ttk_guionly skipped -- ttk not available: no display name and no
$DISPLAY environment variable
.
.
test_tcl
remoteFailed: [Failure instance: Traceback (failure with no frames):
twisted.internet.error.ConnectionLost: Connection to the other side was
lost in a non-clean fashion.
]
When it is not test_tcl, it is test_ttk_guionly.
I tried duplicating the issue here by creating a buildmaster and a
buildslave, used same options to build and to run tests, also tried
enabling and disabling pty (I've found some old emails about problems
involving pty), but couldn't duplicate it.
So I followed a build on this buildslave "amd 64 gentoo trunk" and
noticed it took a long time from the time it started running test_tcl
till when the error appeared, which makes me imagine there is some
problem regarding X server authorization. Now this is when I started
checking how many other slaves were failing with the same error, and
then I found this "x86 FreeBSD trunk" which failed with the following
message:
.
.
test_ttk_guionly
test_ttk_guionly skipped -- ttk not available: can't find package tile
.
.
test_tcl
XIO: fatal IO error 9 (Bad file descriptor) on X server ":0.0"
after 25 requests (23 known processed) with 1 events remaining.
*** Error code 1
This second bot had DISPLAY set, while the first didn't (although its
TERM is set to xterm). I wonder if the first error ends up being the
same as this second one.
I'm asking myself if test_ttk_guionly is so wrong that it should be
disabled everywhere, and even if it gets disabled, what if in the future
another test comes in and "conflicts" with test_tcl ?
----------
components: Tkinter
messages: 80901
nosy: gpolo
severity: normal
status: open
title: test_tcl and test_ttk_guionly don't like each other
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5122>
_______________________________________
From report at bugs.python.org Sun Feb 1 14:29:58 2009
From: report at bugs.python.org (hlqyq)
Date: Sun, 01 Feb 2009 13:29:58 +0000
Subject: [New-bugs-announce] [issue5123] Virus found in python-3.0.msi
Message-ID: <1233494998.76.0.590591282424.issue5123@psf.upfronthosting.co.za>
Changes by hlqyq <hlqyq at yahoo.com.cn>:
----------
components: Windows
nosy: hlqyq
severity: normal
status: open
title: Virus found in python-3.0.msi
type: security
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5123>
_______________________________________
From report at bugs.python.org Sun Feb 1 19:52:14 2009
From: report at bugs.python.org (Weeble)
Date: Sun, 01 Feb 2009 18:52:14 +0000
Subject: [New-bugs-announce] [issue5124] IDLE - pasting text doesn't delete
selection
In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za>
Message-ID: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za>
New submission from Weeble <clockworksaint at gmail.com>:
Steps to reproduce:
1. Start IDLE.
2. Enter some text:
spam
eggs
3. Select the first line ("spam") and press control+c to copy.
4. Select the second line ("eggs") and press control+v to paste.
Expected result:
spam
spam
(With the caret at the end of the second line and no selection.)
Actual result (IDLE 2.6, Tk/Tcl 8.4, Linux):
spam
eggsspam
(With "eggs" selected and the caret at the end of the second line.)
I don't think this happens to me on Windows. It might be deliberate; I
know that Tk has slightly different behaviour on Windows and Linux. But
it doesn't seem to be consistent with other behaviour: for example, if
instead of pasting I start typing, the selected text is erased and the
typed text replaces it.
I can look into this myself, but I would appreciate if someone else can
confirm that this is not the expected behaviour, since perhaps it is
only my Windows background that leads me to expect this.
----------
components: IDLE
messages: 80914
nosy: weeble
severity: normal
status: open
title: IDLE - pasting text doesn't delete selection
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5124>
_______________________________________
From report at bugs.python.org Sun Feb 1 20:48:30 2009
From: report at bugs.python.org (=?utf-8?q?Reto_Sch=C3=BCttel?=)
Date: Sun, 01 Feb 2009 19:48:30 +0000
Subject: [New-bugs-announce] [issue5125] Strange locale problem with Python 3
In-Reply-To: <1233517710.32.0.869509955584.issue5125@psf.upfronthosting.co.za>
Message-ID: <1233517710.32.0.869509955584.issue5125@psf.upfronthosting.co.za>
New submission from Reto Sch?ttel <reto-company-python-bugs at schuettel.ch>:
Hi
While helping Brandon Rhodes to port PyEphem[1] to Python 3 we struggled
over a
strange locale-related problem on OS X. PyEphem is a library which can do
astronomical computations like tracking the position of stars, planets and
earth satellites relative to the earth's position. When testing out the
Python
3 release of PyEphem I noticed that on my OS X laptop a lot of calculations
were wrong (not completely wrong, but clearly not accurate) compared to
Python
2.5. We (well mostly Brandon) were able to track down the problem to the TLE
parser (TLE are data file containing the orbital elements of an object)
which
appears to read most values wrong with python 3. In fact it cut of the
decimal
parts of all floats (1.123232 got 1, etc). Manually setting LANG and
LC_ALL to
C solved the problem.
It turns out that some parts of Python 3 got more locale dependent on some
platforms. The only platform I am aware of is OS X, on Linux Python 3
appears
to behave like Python 2.x did.
In case of PyEphem the problem was in the C extension which got more locale
dependent, for example atof() or scanf() with Python 3 now expected the
german
decimal-delimiter ',' instead of the '.' in floats (3.14 vs. 3,14). On the
other hand the constructor of float still expects '.' all the time. But the
built-in function strptime() honors locales with Python 3 and expects german
week day.
I've written a simple script and a simple C extension which illustrates the
problem. Both the extension and the script run python 2.x and python 3,
so you
can easily compare the result while executing the script in different
environments.
I was only able to reproduce the problem on OS X (10.5) and using a german
locale like "de_CH.UTF-8". When manually setting LC_ALL=C, the differences
disappears.
I can't imagine that his behavior was really intended, and I hope the
test case
helps you guys to identify/fix this problem.
Download the test case from:
http://github.com/retoo/py3k-locale-problem/tarball/master
or get it using git:
git://github.com/retoo/py3k-locale-problem.git
You can use the following steps to build it:
$ python2.5 setup.py build
$ python3.0 setup.py build
To run the tests with python 2.5, enter:
$ (cd build/lib*-2.5; python2.5 py3k_locale_problem.py)
... for 3.0 ...
$ (cd build/lib*-3.0; python3.0 py3k_locale_problem.py)
In the file 'results.txt' you can see the output from my OS X system.
Cheers,
Reto Sch?ttel
[1] http://rhodesmill.org/pyephem/
----------
components: Interpreter Core
messages: 80917
nosy: retoo
severity: normal
status: open
title: Strange locale problem with Python 3
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5125>
_______________________________________
From report at bugs.python.org Sun Feb 1 22:02:09 2009
From: report at bugs.python.org (dlfjessup)
Date: Sun, 01 Feb 2009 21:02:09 +0000
Subject: [New-bugs-announce] [issue5126] Space character returns false from
isprintable() method
In-Reply-To: <1233522128.92.0.321891922918.issue5126@psf.upfronthosting.co.za>
Message-ID: <1233522128.92.0.321891922918.issue5126@psf.upfronthosting.co.za>
New submission from dlfjessup <dljessup at gmail.com>:
I am running IDLE on Windows XP. The version information when IDLE
boots is:
Python 3.0 (r30:67507, Dec 3 2008, 20:14:27) [MSC v.1500 32 bit
(Intel)] on win32
I ran the following test case:
>>> ' '.isprintable()
False
However, according to
http://docs.python.org/3.0/library/stdtypes.htm#str.isprintable, "...the
ASCII space (0x20) ... is considered printable."
This seems pretty broken to me.
----------
messages: 80919
nosy: dlfjessup
severity: normal
status: open
title: Space character returns false from isprintable() method
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5126>
_______________________________________
From report at bugs.python.org Mon Feb 2 02:31:46 2009
From: report at bugs.python.org (Venusaur)
Date: Mon, 02 Feb 2009 01:31:46 +0000
Subject: [New-bugs-announce] [issue5127] UnicodeEncodeError - I can't even
see license
In-Reply-To: <1233538306.69.0.00753244691607.issue5127@psf.upfronthosting.co.za>
Message-ID: <1233538306.69.0.00753244691607.issue5127@psf.upfronthosting.co.za>
New submission from Venusaur <bupjae at hotmail.com>:
>>> license
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Python30\lib\site.py", line 372, in __repr__
self.__setup()
File "C:\Python30\lib\site.py", line 359, in __setup
data = fp.read()
File "C:\Python30\lib\io.py", line 1724, in read
decoder.decode(self.buffer.read(), final=True))
File "C:\Python30\lib\io.py", line 1295, in decode
output = self.decoder.decode(input, final=final)
UnicodeDecodeError: 'cp949' codec can't decode bytes in position 15164-
15165: il
legal multibyte sequence
>>> chr(0x10000)
'\U00010000'
>>> chr(0x11000)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Python30\lib\io.py", line 1491, in write
b = encoder.encode(s)
UnicodeEncodeError: 'cp949' codec can't encode character '\ud804' in
position 1:
illegal multibyte sequence
>>>
I also can't understand why chr(0x10000) and chr(0x11000) has different
behavior
----------
components: Unicode
messages: 80924
nosy: bupjae
severity: normal
status: open
title: UnicodeEncodeError - I can't even see license
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5127>
_______________________________________
From report at bugs.python.org Mon Feb 2 15:19:36 2009
From: report at bugs.python.org (Martin von Gagern)
Date: Mon, 02 Feb 2009 14:19:36 +0000
Subject: [New-bugs-announce] [issue5128] compileall: consider ctime
In-Reply-To: <1233584376.51.0.787053739937.issue5128@psf.upfronthosting.co.za>
Message-ID: <1233584376.51.0.787053739937.issue5128@psf.upfronthosting.co.za>
New submission from Martin von Gagern <Martin.vGagern at gmx.net>:
When trying to decide whether or not a given file needs to be
recompiled, the inode creation time should be taken into account along
with the file modification time.
Scenario: Suppose you have three times, A < B < C < D. At time A, you
package version 1 of foo.py. At time B, you package version 2. At time C
you install version 1 onto some system, and byte-compile it for all
users. Therefore foo.py has mtime A and ctime C, and foo.pyc has both
mtime C. At time D you delete foo.py from version 1 and install version
2. Then you byte-compile it without force. At that time, foo.py has
mtime B (because that was when it was packaged) but ctime D (because
that was when the file was created). foo.pyc has mtime C (because that
was when it was last modified). The current comparison compares only
mtimes, sees C > B, and skips foo.py. With this patch in place, it will
check for C > max(B, D), which is not the case, and thus recompile foo.c.
In other words, max(st_mtime, st_ctime) can be interpreted as the last
time a file at a given path was changed, either through modification of
its contents (mtime) or deletion followed by recreation (ctime).
Installation systems that overwrite files without deleting them before
still are in the same trouble as before, but all others will benefit
from this.
See also: http://bugs.gentoo.org/256953
----------
components: Library (Lib)
messages: 80939
nosy: gagern
severity: normal
status: open
title: compileall: consider ctime
type: feature request
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5128>
_______________________________________
From report at bugs.python.org Mon Feb 2 15:36:16 2009
From: report at bugs.python.org (sy12)
Date: Mon, 02 Feb 2009 14:36:16 +0000
Subject: [New-bugs-announce] [issue5129] indentation in IDLE 2.6 different
from IDLE 2.5, 2.4 or vim
In-Reply-To: <1233585376.12.0.459695435706.issue5129@psf.upfronthosting.co.za>
Message-ID: <1233585376.12.0.459695435706.issue5129@psf.upfronthosting.co.za>
New submission from sy12 <sy12 at club-internet.fr>:
platform: Windows XP
In a file (cf attached file) with mixed tabs and spaces, the line
following "else:" appears at the same level than "else:", while the file
probably still works with Python 2.6. At least, IDLE 2.5 or IDLE 2.4 or
vim don't have this problem.
----------
components: IDLE
files: bug.py
messages: 80941
nosy: sy12
severity: normal
status: open
title: indentation in IDLE 2.6 different from IDLE 2.5, 2.4 or vim
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file12918/bug.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5129>
_______________________________________
From report at bugs.python.org Mon Feb 2 16:43:11 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 02 Feb 2009 15:43:11 +0000
Subject: [New-bugs-announce] [issue5130] Obsolete reference to "unicode" in
glossary
In-Reply-To: <1233589391.96.0.438188518405.issue5130@psf.upfronthosting.co.za>
Message-ID: <1233589391.96.0.438188518405.issue5130@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
The glossary entry for "sequence" mentions the type "unicode", but that's
gone.
----------
assignee: georg.brandl
components: Documentation
messages: 80943
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Obsolete reference to "unicode" in glossary
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5130>
_______________________________________
From report at bugs.python.org Mon Feb 2 17:34:02 2009
From: report at bugs.python.org (Nick Craig-Wood)
Date: Mon, 02 Feb 2009 16:34:02 +0000
Subject: [New-bugs-announce] [issue5131] pprint doesn't know how to print a
set or a defaultdict
In-Reply-To: <1233592442.21.0.0563262599933.issue5131@psf.upfronthosting.co.za>
Message-ID: <1233592442.21.0.0563262599933.issue5131@psf.upfronthosting.co.za>
New submission from Nick Craig-Wood <nick at craig-wood.com>:
I noticed this the other day when debugging a program that neither set()
nor defaultdict() pprint() properly
Same under 3.1 and 2.5 (Not tried 2.6/2.7 but I assume it is the same)
>>> pprint(set(range(100)))
set([0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18,
19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36,
37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54,
55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72,
73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90,
91, 92, 93, 94, 95, 96, 97, 98, 99])
>>> from collections import defaultdict
>>> pprint(defaultdict(int).fromkeys(range(100)))
defaultdict(None, {0: None, 1: None, 2: None, 3: None, 4: None, 5: None,
6: None, 7: None, 8: None, 9: None, 10: None, 11: None, 12: None, 13:
None, 14: None, 15: None, 16: None, 17: None, 18: None, 19: None, 20:
None, 21: None, 22: None, 23: None, 24: None, 25: None, 26: None, 27:
None, 28: None, 29: None, 30: None, 31: None, 32: None, 33: None, 34:
None, 35: None, 36: None, 37: None, 38: None, 39: None, 40: None, 41:
None, 42: None, 43: None, 44: None, 45: None, 46: None, 47: None, 48:
None, 49: None, 50: None, 51: None, 52: None, 53: None, 54: None, 55:
None, 56: None, 57: None, 58: None, 59: None, 60: None, 61: None, 62:
None, 63: None, 64: None, 65: None, 66: None, 67: None, 68: None, 69:
None, 70: None, 71: None, 72: None, 73: None, 74: None, 75: None, 76:
None, 77: None, 78: None, 79: None, 80: None, 81: None, 82: None, 83:
None, 84: None, 85: None, 86: None, 87: None, 88: None, 89: None, 90:
None, 91: None, 92: None, 93: None, 94: None, 95: None, 96: None, 97:
None, 98: None, 99: None})
>>>
----------
components: Library (Lib)
messages: 80948
nosy: ncw
severity: normal
status: open
title: pprint doesn't know how to print a set or a defaultdict
type: feature request
versions: Python 2.5, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5131>
_______________________________________
From report at bugs.python.org Mon Feb 2 19:28:13 2009
From: report at bugs.python.org (Dave Peterson)
Date: Mon, 02 Feb 2009 18:28:13 +0000
Subject: [New-bugs-announce] [issue5132] distutils: libpython not found when
building python extensions on Solaris when Python was built
with --enable-shared
In-Reply-To: <1233599293.13.0.516383193111.issue5132@psf.upfronthosting.co.za>
Message-ID: <1233599293.13.0.516383193111.issue5132@psf.upfronthosting.co.za>
New submission from Dave Peterson <dpeterson at enthought.com>:
I've had trouble building Python extensions on Solaris if the Python
install I'm using was built with the '--enable-shared' option. In
tracking this down, it appears that the code in
'distutils/command/build_ext.py' contains a number of statements to
detect a similar situation for other platforms and explicitly add the
'lib' dir option for the linker, but there is no similar detection for
Solaris.
I've attached a patch that fixes this and solves the problem for me. I
simply extended the checking for 'linux' and 'gnu' platforms to also
apply for 'sunos' platforms.
----------
components: Distutils
files: distutils_command_build_ext.patch
keywords: patch
messages: 80977
nosy: dpeterson
severity: normal
status: open
title: distutils: libpython not found when building python extensions on Solaris when Python was built with --enable-shared
type: compile error
versions: Python 2.5
Added file: http://bugs.python.org/file12920/distutils_command_build_ext.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5132>
_______________________________________
From report at bugs.python.org Mon Feb 2 19:52:32 2009
From: report at bugs.python.org (David Nicol)
Date: Mon, 02 Feb 2009 18:52:32 +0000
Subject: [New-bugs-announce] [issue5133] Error with Eval
In-Reply-To: <1233600751.98.0.0626987723582.issue5133@psf.upfronthosting.co.za>
Message-ID: <1233600751.98.0.0626987723582.issue5133@psf.upfronthosting.co.za>
New submission from David Nicol <david at theNicols.net>:
The single line statements:
eval("08") ; and
eval("09")
both crash; while
eval("07") works fine
----------
components: None
messages: 80982
nosy: davidnicol
severity: normal
status: open
title: Error with Eval
type: compile error
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5133>
_______________________________________
From report at bugs.python.org Mon Feb 2 19:53:00 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 02 Feb 2009 18:53:00 +0000
Subject: [New-bugs-announce] [issue5134] Compiler warnings in sqlite module
In-Reply-To: <1233600780.48.0.187282999033.issue5134@psf.upfronthosting.co.za>
Message-ID: <1233600780.48.0.187282999033.issue5134@psf.upfronthosting.co.za>
New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:
>From a compilation of Py3.1 r69209 :
..\..\..\sqlite-3.5.9\sqlite3.c(9702) : warning C4244: '=' : conversion
from 'double' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(9703) : warning C4244: '=' : conversion
from 'double' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(9813) : warning C4244: '=' : conversion
from 'double' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(9814) : warning C4244: '=' : conversion
from 'double' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(9817) : warning C4244: '=' : conversion
from 'double' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(9818) : warning C4244: '=' : conversion
from 'double' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(9819) : warning C4244: '=' : conversion
from 'double' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(9820) : warning C4244: '=' : conversion
from 'double' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(9835) : warning C4244: '=' : conversion
from 'double' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(9836) : warning C4244: '=' : conversion
from 'double' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(9838) : warning C4244: '=' : conversion
from 'double' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(9881) : warning C4244: 'initializing' :
conversion from 'double' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(9887) : warning C4244: '=' : conversion
from 'double' to 'time_t', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(9903) : warning C4996: 'localtime': This
function or variable may be unsafe. Consider using localtime_s instead.
To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
details.
C:\Program Files\Microsoft Visual Studio
8\VC\include\time.inl(114) : see declaration of 'localtime'
..\..\..\sqlite-3.5.9\sqlite3.c(9998) : warning C4244: '=' : conversion
from 'double' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(10004) : warning C4244: '=' : conversion
from 'double' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(10096) : warning C4244: '+=' :
conversion from 'double' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(10102) : warning C4244: '=' : conversion
from 'double' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(10108) : warning C4244: '+=' :
conversion from 'double' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(10309) : warning C4244: 'function' :
conversion from 'u64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(10340) : warning C4244: '=' : conversion
from 'double' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(11146) : warning C4244: 'return' :
conversion from 'sqlite3_int64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(13798) : warning C4244: '=' : conversion
from 'sqlite3_int64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(14408) : warning C4244: 'initializing' :
conversion from 'sqlite_uint64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(14741) : warning C4244: '=' : conversion
from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(16514) : warning C4244: '=' : conversion
from 'u64' to 'unsigned char', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(16517) : warning C4244: '=' : conversion
from 'u64' to 'unsigned char', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(16524) : warning C4244: '=' : conversion
from 'u64' to 'u8', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(22425) : warning C4244: 'initializing' :
conversion from 'sqlite3_int64' to 'LONG', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(22426) : warning C4244: 'initializing' :
conversion from 'sqlite3_int64' to 'LONG', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(22458) : warning C4244: 'initializing' :
conversion from 'sqlite3_int64' to 'LONG', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(22459) : warning C4244: 'initializing' :
conversion from 'sqlite3_int64' to 'LONG', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(22490) : warning C4244: 'initializing' :
conversion from 'sqlite3_int64' to 'LONG', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(22491) : warning C4244: 'initializing' :
conversion from 'sqlite3_int64' to 'LONG', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(24580) : warning C4018: '>=' :
signed/unsigned mismatch
..\..\..\sqlite-3.5.9\sqlite3.c(24597) : warning C4018: '<' :
signed/unsigned mismatch
..\..\..\sqlite-3.5.9\sqlite3.c(25331) : warning C4244: 'function' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(25337) : warning C4244: 'function' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(25564) : warning C4244: '=' : conversion
from 'i64' to 'u32', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(25577) : warning C4244: '=' : conversion
from 'i64' to 'u32', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(25592) : warning C4018: '<' :
signed/unsigned mismatch
..\..\..\sqlite-3.5.9\sqlite3.c(25696) : warning C4244: '=' : conversion
from 'i64' to 'u32', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(25712) : warning C4244: '=' : conversion
from 'i64' to 'u32', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(25921) : warning C4018: '>' :
signed/unsigned mismatch
..\..\..\sqlite-3.5.9\sqlite3.c(26221) : warning C4244: '=' : conversion
from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(26228) : warning C4244: '=' : conversion
from 'i64' to 'Pgno', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(26230) : warning C4244: 'return' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(26314) : warning C4018: '<=' :
signed/unsigned mismatch
..\..\..\sqlite-3.5.9\sqlite3.c(26743) : warning C4018: '<=' :
signed/unsigned mismatch
..\..\..\sqlite-3.5.9\sqlite3.c(28366) : warning C4018: '<=' :
signed/unsigned mismatch
..\..\..\sqlite-3.5.9\sqlite3.c(30256) : warning C4244: 'function' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(30258) : warning C4244: 'function' :
conversion from 'i64' to 'u32', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(30946) : warning C4244: '=' : conversion
from 'u16' to 'unsigned char', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(31766) : warning C4244: '=' : conversion
from 'u16' to 'unsigned char', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(32268) : warning C4018: '>' :
signed/unsigned mismatch
..\..\..\sqlite-3.5.9\sqlite3.c(32268) : warning C4018: '<=' :
signed/unsigned mismatch
..\..\..\sqlite-3.5.9\sqlite3.c(32933) : warning C4018: '<=' :
signed/unsigned mismatch
..\..\..\sqlite-3.5.9\sqlite3.c(33050) : warning C4244: '=' : conversion
from 'i64' to 'u32', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(33055) : warning C4018: '>' :
signed/unsigned mismatch
..\..\..\sqlite-3.5.9\sqlite3.c(33251) : warning C4244: '=' : conversion
from 'i64' to 'u32', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(33258) : warning C4018: '>' :
signed/unsigned mismatch
..\..\..\sqlite-3.5.9\sqlite3.c(33601) : warning C4244: 'function' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(33651) : warning C4244: 'function' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(33653) : warning C4244: 'function' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(33658) : warning C4244: 'function' :
conversion from 'i64' to 'u32', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(33659) : warning C4244: 'function' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(33918) : warning C4018: '<=' :
signed/unsigned mismatch
..\..\..\sqlite-3.5.9\sqlite3.c(34054) : warning C4018: '>' :
signed/unsigned mismatch
..\..\..\sqlite-3.5.9\sqlite3.c(34237) : warning C4018: '>' :
signed/unsigned mismatch
..\..\..\sqlite-3.5.9\sqlite3.c(34308) : warning C4244: '+=' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(34310) : warning C4244: '=' : conversion
from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(34483) : warning C4244: '=' : conversion
from 'u16' to 'u8', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(34565) : warning C4244: '=' : conversion
from 'u16' to 'u8', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(35959) : warning C4018: '>' :
signed/unsigned mismatch
..\..\..\sqlite-3.5.9\sqlite3.c(36488) : warning C4244: '+=' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(36784) : warning C4244: '=' : conversion
from 'i64' to 'Pgno', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(36833) : warning C4244: 'initializing' :
conversion from 'sqlite3_int64' to 'Pgno', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(36910) : warning C4244: 'initializing' :
conversion from 'i64' to 'Pgno', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(37371) : warning C4244: '=' : conversion
from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(37379) : warning C4244: 'function' :
conversion from 'i64' to 'size_t', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(37380) : warning C4244: '+=' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(37731) : warning C4244: '+=' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(37913) : warning C4244: '=' : conversion
from 'const i64' to 'double', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(37918) : warning C4244: '=' : conversion
from 'const i64' to 'double', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(38257) : warning C4244: 'return' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(40178) : warning C4244: 'return' :
conversion from 'i64' to 'u32', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(40194) : warning C4244: '+=' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(40301) : warning C4244: '=' : conversion
from 'u64' to 'u8', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(40315) : warning C4244: '+=' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(40470) : warning C4018: '<' :
signed/unsigned mismatch
..\..\..\sqlite-3.5.9\sqlite3.c(40554) : warning C4018: '>=' :
signed/unsigned mismatch
..\..\..\sqlite-3.5.9\sqlite3.c(40579) : warning C4018: '<' :
signed/unsigned mismatch
..\..\..\sqlite-3.5.9\sqlite3.c(40627) : warning C4244: 'function' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(40672) : warning C4244: 'function' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(41018) : warning C4244: 'return' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(41198) : warning C4244: '=' : conversion
from 'double' to 'i64', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(41228) : warning C4244: '=' : conversion
from 'double' to 'u64', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(43078) : warning C4244: 'function' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(43088) : warning C4244: '=' : conversion
from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(43183) : warning C4244: '=' : conversion
from 'i64' to 'double', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(43924) : warning C4244: '=' : conversion
from 'i64' to 'u32', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(43945) : warning C4018: '>' :
signed/unsigned mismatch
..\..\..\sqlite-3.5.9\sqlite3.c(43983) : warning C4018: '>=' :
signed/unsigned mismatch
..\..\..\sqlite-3.5.9\sqlite3.c(44001) : warning C4018: '<' :
signed/unsigned mismatch
..\..\..\sqlite-3.5.9\sqlite3.c(44018) : warning C4018: '<' :
signed/unsigned mismatch
..\..\..\sqlite-3.5.9\sqlite3.c(44206) : warning C4244: '+=' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(44229) : warning C4244: 'function' :
conversion from 'u64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(44241) : warning C4244: 'function' :
conversion from 'u64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(44246) : warning C4244: '=' : conversion
from 'u64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(44463) : warning C4244: '=' : conversion
from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(44467) : warning C4244: '=' : conversion
from 'i64' to 'u8', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(44603) : warning C4244: '=' : conversion
from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(45373) : warning C4244: '=' : conversion
from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(45517) : warning C4244: '=' : conversion
from 'i64' to 'u32', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(45520) : warning C4018: '>' :
signed/unsigned mismatch
..\..\..\sqlite-3.5.9\sqlite3.c(46131) : warning C4244: '=' : conversion
from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(46137) : warning C4244: 'function' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(46563) : warning C4244: '=' : conversion
from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(46564) : warning C4244: '=' : conversion
from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(57437) : warning C4244: 'function' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(57473) : warning C4244: 'function' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(58001) : warning C4244: 'function' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(58273) : warning C4244: 'initializing' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(58274) : warning C4244: 'initializing' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(58275) : warning C4244: 'initializing' :
conversion from 'i64' to 'int', possible loss of data
..\..\..\sqlite-3.5.9\sqlite3.c(71347) : warning C4244: '=' : conversion
from 'u16' to 'unsigned char', possible loss of data
----------
assignee: ghaering
components: Extension Modules
messages: 80983
nosy: ghaering, rhettinger
priority: low
severity: normal
status: open
title: Compiler warnings in sqlite module
type: compile error
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5134>
_______________________________________
From report at bugs.python.org Mon Feb 2 20:57:40 2009
From: report at bugs.python.org (Paul Moore)
Date: Mon, 02 Feb 2009 19:57:40 +0000
Subject: [New-bugs-announce] [issue5135] Expose simplegeneric function in
functools module
In-Reply-To: <1233604660.52.0.0984436233806.issue5135@psf.upfronthosting.co.za>
Message-ID: <1233604660.52.0.0984436233806.issue5135@psf.upfronthosting.co.za>
New submission from Paul Moore <p.f.moore at gmail.com>:
This patch takes the existing "simplegeneric" decorator, currently an
internal implementation detail of the pkgutil module, and exposes it as
a feature of the functools module.
Documentation and tests have been added, and the pkgutil code has been
updated to use the functools implementation.
Open issue: The syntax for registering an overload is rather manual:
def xxx_impl(xxx):
pass
generic_fn.register(XXX, xxx_impl)
It might be better to make the registration function a decorator:
@generic_fn.register(XXX)
def xxx_impl(xxx):
pass
However, this would involve changing the existing (working) code, and I
didn't want to do that before there was agreement that the general idea
(of exposing the functionality) was sound.
----------
assignee: ncoghlan
components: Library (Lib)
files: generic.patch
keywords: needs review, patch
messages: 80986
nosy: ncoghlan, pmoore
priority: normal
severity: normal
stage: patch review
status: open
title: Expose simplegeneric function in functools module
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file12921/generic.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5135>
_______________________________________
From report at bugs.python.org Tue Feb 3 02:04:48 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 03 Feb 2009 01:04:48 +0000
Subject: [New-bugs-announce] [issue5136] Deprecating (and removing)
"globalcall", "merge" and "globaleval"
In-Reply-To: <1233623088.62.0.412008570682.issue5136@psf.upfronthosting.co.za>
Message-ID: <1233623088.62.0.412008570682.issue5136@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
Hi, I'm going to try explaining in short why I think each of these
functions in _tkinter could be marked as deprecated and then removed on
2.8 (if it is decided to do it) and 3.1.
globalcall: It is not used anywhere in tkinter. It was abandoned, and
doesn't work in the same situations where "call" would work (with
threads). It doesn't care about converting the result to a proper python
object -- it is always a string (another result of the abandonment).
"call" already works in the Tcl global space, because it needs to do so
(see issue1581476). Even tcl 8.2 says Tcl_GlobalEval (the root of
"globalcall") is old and deprecated.
merge: globalcall depends on merge, but removing globalcall makes merge
obsolete. It is not used by tkinter either. Searching for "tk.merge" on
google codesearch returns a single result dating back python 1.1!
globaleval: Uses Tcl_GlobalEval too. I haven't seen it being used,
instead I always see eval being used.
----------
components: Tkinter
messages: 81021
nosy: gpolo
severity: normal
status: open
title: Deprecating (and removing) "globalcall", "merge" and "globaleval"
versions: Python 2.7, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5136>
_______________________________________
From report at bugs.python.org Tue Feb 3 05:45:17 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 03 Feb 2009 04:45:17 +0000
Subject: [New-bugs-announce] [issue5137] SystemError when __len__ returns a
non-number
In-Reply-To: <1233636317.07.0.926088600598.issue5137@psf.upfronthosting.co.za>
Message-ID: <1233636317.07.0.926088600598.issue5137@psf.upfronthosting.co.za>
New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:
len(obj) is not happy when obj.__len__() returns a non-number.
----------
files: crasher_len.py
messages: 81024
nosy: rhettinger
priority: release blocker
severity: normal
status: open
title: SystemError when __len__ returns a non-number
type: crash
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12927/crasher_len.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5137>
_______________________________________
From report at bugs.python.org Tue Feb 3 05:48:46 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 03 Feb 2009 04:48:46 +0000
Subject: [New-bugs-announce] [issue5138] File Reload for IDLE
In-Reply-To: <1233636526.93.0.952208632145.issue5138@psf.upfronthosting.co.za>
Message-ID: <1233636526.93.0.952208632145.issue5138@psf.upfronthosting.co.za>
New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:
IDLE would be *much* easier to use in conjunction with version control
if there were a reload option that did the equivalent of (close current
with no save, followed by open current file).
----------
assignee: kbk
components: IDLE
messages: 81025
nosy: kbk, rhettinger
priority: normal
severity: normal
status: open
title: File Reload for IDLE
type: feature request
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5138>
_______________________________________
From report at bugs.python.org Tue Feb 3 05:57:47 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 03 Feb 2009 04:57:47 +0000
Subject: [New-bugs-announce] [issue5139] Add combinatoric counting functions
to the math module.
In-Reply-To: <1233637067.11.0.307954732355.issue5139@psf.upfronthosting.co.za>
Message-ID: <1233637067.11.0.307954732355.issue5139@psf.upfronthosting.co.za>
New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:
To parallel the functions in itertools, add:
math.combinations(n,r) --> n! / r! / (n-r)! when 0 <= r <= n or zero
when r > n.
math.permutations(n,r) --> n! / (n-r)! when 0 <= r <= n or zero when
r > n.
math.combinations_with_replacement(n,r) --> (n+r-1)! / r! / (n-1)!
when n > 0. And when n==0, return 0 if r>0 else 1.
These will enable an itertools user to compute the length of those
iterators. It will also serve for general probability computations.
Likewise, it produce binomial coefficients and multiset partitions.
Since, the math module is where we put the factorial() function, it is
the logical place for the combinatoric counting functions.
----------
components: Extension Modules
messages: 81026
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Add combinatoric counting functions to the math module.
type: feature request
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5139>
_______________________________________
From report at bugs.python.org Tue Feb 3 06:48:43 2009
From: report at bugs.python.org (Robert Yodlowski)
Date: Tue, 03 Feb 2009 05:48:43 +0000
Subject: [New-bugs-announce] [issue5140] Some Built-in Functions entries in
Library Manual are missing Permalinks
In-Reply-To: <1233640123.76.0.469214114608.issue5140@psf.upfronthosting.co.za>
Message-ID: <1233640123.76.0.469214114608.issue5140@psf.upfronthosting.co.za>
New submission from Robert Yodlowski <rbtyod at gmail.com>:
In
http://docs.python.org/3.0/library/functions.html
these function entries seem to be missing Permalinks.
dict() frozenset() memoryview() set()
Hope this helps.
The Permalinks are a great idea. I hope you add lots more.
...Bob
----------
assignee: georg.brandl
components: Documentation
messages: 81027
nosy: georg.brandl, rbtyod
severity: normal
status: open
title: Some Built-in Functions entries in Library Manual are missing Permalinks
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5140>
_______________________________________
From report at bugs.python.org Tue Feb 3 10:55:34 2009
From: report at bugs.python.org (=?utf-8?q?Hrvoje_Nik=C5=A1i=C4=87?=)
Date: Tue, 03 Feb 2009 09:55:34 +0000
Subject: [New-bugs-announce] [issue5141] C API for appending to arrays
In-Reply-To: <1233654934.43.0.515749486926.issue5141@psf.upfronthosting.co.za>
Message-ID: <1233654934.43.0.515749486926.issue5141@psf.upfronthosting.co.za>
New submission from Hrvoje Nik?i? <hniksic at gmail.com>:
The array.array type is an excellent type for storing a large amount of
"native" elements, such as integers, chars, doubles, etc., without
involving the heavy machinery of numpy. It's both blazingly fast and
reasonably efficient with memory. The one thing missing from the array
module is the ability to directly access array values from C.
This might seem superfluous, as it's perfectly possible to manipulate
array contents from Python/C using PyObject_CallMethod and friends. The
problem is that it requires the native values to be marshalled to Python
objects, only to be immediately converted back to native values by the
array code. This can be a problem when, for example, a numeric array
needs to be filled with contents, such as in this hypothetical example:
/* error checking and refcounting subtleties omitted for brevity */
PyObject *load_data(Source *src)
{
PyObject *array_type = get_array_type();
PyObject *array = PyObject_CallFunction(array_type, "c", 'd');
PyObject *append = PyObect_GetAttrString(array, "append");
while (!source_done(src)) {
double num = source_next(src);
PyObject *f = PyFloat_FromDouble(num);
PyObject *ret = PyObject_CallFunctionObjArgs(append, f, NULL);
if (!ret)
return NULL;
Py_DECREF(ret);
Py_DECREF(f);
}
Py_DECREF(array_type);
return array;
}
The inner loop must convert each C double to a Python Float, only for
the array to immediately extract the double back from the Float and
store it into the underlying array of C doubles. This may seem like a
nitpick, but it turns out that more than half of the time of this
function is spent creating and deleting those short-lived floating-point
objects.
Float creation is already well-optimized, so opportunities for speedup
lie elsewhere. The array object exposes a writable buffer, which can be
used to store values directly. For test purposes I created a faster
"append" specialized for doubles, defined like this:
int array_append(PyObject *array, PyObject *appendfun, double val)
{
PyObject *ret;
double *buf;
Py_ssize_t bufsize;
static PyObject *zero;
if (!zero)
zero = PyFloat_FromDouble(0);
// append dummy zero value, created only once
ret = PyObject_CallFunctionObjArgs(appendfun, zero, NULL);
if (!ret)
return -1;
Py_DECREF(ret);
// append the element directly at the end of the C buffer
PyObject_AsWriteBuffer(array, (void **) &buf, &bufsize));
buf[bufsize / sizeof(double) - 1] = val;
return 0;
}
This hack actually speeds up array creation by a significant percentage
(30-40% in my case, and that's for code that was producing the values by
parsing a large text file).
It turns out that an even faster method of creating an array is by using
the fromstring() method. fromstring() requires an actual string, not a
buffer, so in C++ I created an std::vector<double> with a contiguous
array of doubles, passed that array to PyString_FromStringAndSize, and
called array.fromstring with the resulting string. Despite all the
unnecessary copying, the result was much faster than either of the
previous versions.
Would it be possible for the array module to define a C interface for
the most frequent operations on array objects, such as appending an
item, and getting/setting an item? Failing that, could we at least make
fromstring() accept an arbitrary read buffer, not just an actual string?
----------
messages: 81039
nosy: hniksic
severity: normal
status: open
title: C API for appending to arrays
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5141>
_______________________________________
From report at bugs.python.org Tue Feb 3 14:51:49 2009
From: report at bugs.python.org (Senthil)
Date: Tue, 03 Feb 2009 13:51:49 +0000
Subject: [New-bugs-announce] [issue5142] pdb feature request: Ability to
skip standard lib modules and other selected packages/modules
In-Reply-To: <1233669109.05.0.519121201366.issue5142@psf.upfronthosting.co.za>
Message-ID: <1233669109.05.0.519121201366.issue5142@psf.upfronthosting.co.za>
New submission from Senthil <orsenthil at gmail.com>:
When using the python debugger, most often I step ('s') through the
code base and I often Call the standard library modules, whichever are
imported in the scripts.
This is often not desirable as I know that errors are within my modules
and not in standard library.
Two things which a developer can do while using pdb is:
1) Be careful as not to 's' into stdlib but use next 'n'.
2) If accidentally stepped into, then use return 'r'.
Instead of doing this repeatedly, how about having method in the
debugger to skip certain modules ( like standard library modules,
certain package's modules etc)
This would save a lot of distraction in call and returns, and developers
can just go ahead with 's' and Enters.
----------
messages: 81058
nosy: orsenthil
severity: normal
status: open
title: pdb feature request: Ability to skip standard lib modules and other selected packages/modules
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5142>
_______________________________________
From report at bugs.python.org Tue Feb 3 17:53:09 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 03 Feb 2009 16:53:09 +0000
Subject: [New-bugs-announce] [issue5143] OS X: Py_SetProgramName argument
has type char*; should be wchar_t*
In-Reply-To: <1233679989.65.0.0874106595792.issue5143@psf.upfronthosting.co.za>
Message-ID: <1233679989.65.0.0874106595792.issue5143@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
When building the py3k branch on OS X, I get the following warning:
gcc -c -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I. -IInclude -
I./Include -DPy_BUILD_CORE -o Modules/main.o Modules/main.c
Modules/main.c: In function ?Py_Main?:
Modules/main.c:491: warning: passing argument 1 of ?Py_SetProgramName?
from incompatible pointer type
This *looks* like it might be a genuine problem. Lines 490-493 of main.c
(which occur inside an #ifdef __APPLE__) look like this:
if ((p = Py_GETENV("PYTHONEXECUTABLE")) && *p != '\0')
Py_SetProgramName(p);
else
Py_SetProgramName(argv[0]);
The return from Py_GETENV (which calls the system getenv) has type char*,
but Py_SetProgramName expects something of type wchar_t*.
However, I don't know enough about this part of Python to tell for sure
whether there's really something wrong here.
Ronald, any ideas?
----------
components: Macintosh
messages: 81066
nosy: marketdickinson, ronaldoussoren
severity: normal
status: open
title: OS X: Py_SetProgramName argument has type char*; should be wchar_t*
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5143>
_______________________________________
From report at bugs.python.org Tue Feb 3 17:56:58 2009
From: report at bugs.python.org (jan matejek)
Date: Tue, 03 Feb 2009 16:56:58 +0000
Subject: [New-bugs-announce] [issue5144] PySys_SetArgv has wrong
documentation
In-Reply-To: <1233680218.31.0.635713677458.issue5144@psf.upfronthosting.co.za>
Message-ID: <1233680218.31.0.635713677458.issue5144@psf.upfronthosting.co.za>
New submission from jan matejek <jmatejek at suse.cz>:
documentation for PySys_SetArgv states that the function sets sys.argv,
but fails to mention that it also resolves script's path and prepends it
to sys.path. Or, in case no script was specified, it prepends empty
string (which in versions <2.6 allowed relative imports from cwd)
----------
assignee: georg.brandl
components: Documentation
messages: 81067
nosy: georg.brandl, matejcik
severity: normal
status: open
title: PySys_SetArgv has wrong documentation
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5144>
_______________________________________
From report at bugs.python.org Tue Feb 3 19:53:43 2009
From: report at bugs.python.org (bob gailer)
Date: Tue, 03 Feb 2009 18:53:43 +0000
Subject: [New-bugs-announce] [issue5145] struct.calcsize('cd') returns 16
instead of 9
In-Reply-To: <1233687223.75.0.372489916628.issue5145@psf.upfronthosting.co.za>
Message-ID: <1233687223.75.0.372489916628.issue5145@psf.upfronthosting.co.za>
New submission from bob gailer <bgailer at gmail.com>:
struct.calcsize('cd') returns 16 instead of 9
struct.calcsize('dc') returns 9 as expected
----------
components: Extension Modules
messages: 81085
nosy: bgailer
severity: normal
status: open
title: struct.calcsize('cd') returns 16 instead of 9
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5145>
_______________________________________
From report at bugs.python.org Tue Feb 3 20:57:36 2009
From: report at bugs.python.org (abhishek)
Date: Tue, 03 Feb 2009 19:57:36 +0000
Subject: [New-bugs-announce] [issue5146] threading via uid method doesn't
work in imaplib
In-Reply-To: <1233691056.73.0.419384658246.issue5146@psf.upfronthosting.co.za>
Message-ID: <1233691056.73.0.419384658246.issue5146@psf.upfronthosting.co.za>
New submission from abhishek <abhishek at synovel.com>:
Hi,
IMAP commands in general can be either called directly or via the UID
command which basically returns the UIDs instead of message IDs.
Consider this example:
02:23.02 > GDJB3 UID THREAD references UTF-8 (SEEN)
02:23.02 < * THREAD (3)(2)(4)(1)
02:23.02 matched r'\* (?P<type>[A-Z-]+)( (?P<data>.*))?' =>
('THREAD', ' (3)(2)(4)(1)', '(3)(2)(4)(1)')
02:23.03 untagged_responses[THREAD] 0 += ["(3)(2)(4)(1)"]
02:23.03 < GDJB3 OK Thread completed.
02:23.03 matched r'(?P<tag>GDJB\d+) (?P<type>[A-Z]+) (?P<data>.*)'
=> ('GDJB3', 'OK', 'Thread completed.')
[None]
...
02:59.22 > CNCF3 THREAD references UTF-8 (SEEN)
02:59.23 < * THREAD (3)(2)(4)(1)
02:59.23 matched r'\* (?P<type>[A-Z-]+)( (?P<data>.*))?' =>
('THREAD', ' (3)(2)(4)(1)', '(3)(2)(4)(1)')
02:59.23 untagged_responses[THREAD] 0 += ["(3)(2)(4)(1)"]
02:59.23 < CNCF3 OK Thread completed.
02:59.23 matched r'(?P<tag>CNCF\d+) (?P<type>[A-Z]+) (?P<data>.*)'
=> ('CNCF3', 'OK', 'Thread completed.')
02:59.23 untagged_responses[THREAD] => ['(3)(2)(4)(1)']
['(3)(2)(4)(1)']
The reason I figured out why UID failed whereas the direct method call
worked lies in this particular line of the method 'uid' in imaplib.py:
if command in ('SEARCH', 'SORT'):
name = command
else:
name = 'FETCH'
which should be :
if command in ('SEARCH', 'SORT', 'THREAD'):
name = command
else:
name = 'FETCH'
I was able to confirm this in both 2.4 and 2.5.
Hope this would be looked upon and fixed.
Regards,
Abhishek
----------
components: Library (Lib)
messages: 81094
nosy: abhishek, piers, pierslauder
severity: normal
status: open
title: threading via uid method doesn't work in imaplib
type: behavior
versions: Python 2.4, Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5146>
_______________________________________
From report at bugs.python.org Tue Feb 3 22:24:00 2009
From: report at bugs.python.org (Ajith Antony)
Date: Tue, 03 Feb 2009 21:24:00 +0000
Subject: [New-bugs-announce] [issue5147] MozillaCookieJar should not store
leading whitespace in Magic header
In-Reply-To: <1233696240.85.0.475858035079.issue5147@psf.upfronthosting.co.za>
Message-ID: <1233696240.85.0.475858035079.issue5147@psf.upfronthosting.co.za>
New submission from Ajith Antony <ajith.antony at gmail.com>:
It seems that in the MozillaCookieJar library, the author accidently
indented
the long string that represents the magic header of the Netscape
compatible
cookie file. This is not a problem for MozillaCookieJar as the regex to
test
the magic header is not bound to the beginning of the line.
Other libraries, however, may bind the pattern match to the beginning of
the
line, such as perl's HTTP::Cookies::Netscape.
For better compatibility of Netscape cookies files, the magic header
must not
be indented.
Index: svn-python-lib/_MozillaCookieJar.py
===================================================================
--- svn-python-lib/_MozillaCookieJar.py (revision 69261)
+++ svn-python-lib/_MozillaCookieJar.py (working copy)
@@ -38,9 +38,9 @@
"""
magic_re = "#( Netscape)? HTTP Cookie File"
header = """\
- # Netscape HTTP Cookie File
- # http://www.netscape.com/newsref/std/cookie_spec.html
- # This is a generated file! Do not edit.
+# Netscape HTTP Cookie File
+# http://www.netscape.com/newsref/std/cookie_spec.html
+# This is a generated file! Do not edit.
"""
----------
components: Library (Lib)
messages: 81100
nosy: aantony
severity: normal
status: open
title: MozillaCookieJar should not store leading whitespace in Magic header
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5147>
_______________________________________
From report at bugs.python.org Wed Feb 4 02:05:42 2009
From: report at bugs.python.org (Christopher Barker)
Date: Wed, 04 Feb 2009 01:05:42 +0000
Subject: [New-bugs-announce] [issue5148] gzip.open breaks with 'U' flag
In-Reply-To: <1233709542.39.0.638969424034.issue5148@psf.upfronthosting.co.za>
Message-ID: <1233709542.39.0.638969424034.issue5148@psf.upfronthosting.co.za>
New submission from Christopher Barker <Chris.Barker at noaa.gov>:
If you pass the 'U' (Universal newlines) flag into gzip.open(), the flag
gets passed into the file open command used to open the gzip file
itself. As the 'U' flag can cause changes in teh data (Lineffed
translation), when it is used with a binary file open, the data is
corrupted, and all can go to heck.
In virtually all of my code that reads text files, I use the 'U' flag to
open files, it really helps not having to deal with newline issues. Yes,
they are fewer now that the Macintosh uses \n, but they can still be a pain.
Anyway, we added such support to some matplotlib methods, and found that
gzip file reading broken We were passing the flags though into either
file() or gzip.open(), and passing 'U' into gzip.open() turns out to be
fatal.
1) It would be nice if the gzip module (and the zip lib module)
supported Universal newlines -- you could read a compressed text file
with "wrong" newlines, and have them handled properly. However, that may
be hard to do, so at least:
2) Passing a 'U' flag in to gzip.open shouldn't break it -- it shuld be
ignored or raise an exeption.
I took a look at the Python SVN (2.5.4 and 2.6.1) for the gzip lib. I
see this:
# guarantee the file is opened in binary mode on platforms
# that care about that sort of thing
if mode and 'b' not in mode:
mode += 'b'
if fileobj is None:
fileobj = self.myfileobj = __builtin__.open(filename, mode
or 'rb')
this is going to break for 'U' == you'll get 'rUb'. I tested
file(filename, 'rUb'), and it looks like it does universal newline
translation.
So:
* Either gzip should be a bit smarter, and remove the 'U' flag (that's
what we did in the MPL code), or force 'rb' or 'wb'.
* Or: file opening should be a bit smarter -- what does 'rUb' mean? a
file can't be both Binary and Universal Text. Should it raise an
exception? Somehow I think it would be better to ignore the 'U', but
maybe that's only because of the issue I happen to be looking at now.
That later seems a better idea -- this issue could certainly come up in
other places than the gzip module, but maybe it would break a bunch of
code -- who knows?
I haven't touched py3 yet, so I have not idea if this issue is different
there.
NOTE: passing in the 'U' flag doesn't guarantee that gzi will break. The
right combination of bytes needs to be there. In fact, when I first
tested this with a small test file, it worked just fine -- I though gzip
was ignoring the flag. However, when tested with a larger (real) gz
file, it did break.
very simple patch:
Add:
mode.replace('U', '')
to the above code before opeing the file
But we may want to do something smarter...
see the (limited) discussion at:
http://mail.python.org/pipermail/python-dev/2009-January/085662.html
----------
components: Library (Lib)
messages: 81121
nosy: Chris.Barker
severity: normal
status: open
title: gzip.open breaks with 'U' flag
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5148>
_______________________________________
From report at bugs.python.org Wed Feb 4 02:20:03 2009
From: report at bugs.python.org (Peter A Silva)
Date: Wed, 04 Feb 2009 01:20:03 +0000
Subject: [New-bugs-announce] [issue5149] syntactic sugar: type coercion on
pointer assignment
In-Reply-To: <1233710403.4.0.267443476473.issue5149@psf.upfronthosting.co.za>
Message-ID: <1233710403.4.0.267443476473.issue5149@psf.upfronthosting.co.za>
New submission from Peter A Silva <Peter.A.Silva at gmail.com>:
tough% cat toy.py
from ctypes import *
class foo(Structure):
_fields_ = [ ( "bar", c_char_p ) ]
foofoo = foo()
babar = create_string_buffer(32)
foofoo.bar = babar
tough% python toy.py
Traceback (most recent call last):
File "toy.py", line 11, in <module>
foofoo.bar = babar
TypeError: incompatible types, c_char_Array_32 instance instead of
c_char_p instance
tough%
would be nice if ctypes automagically turned the assignment into
foofoo.bar = cast(babar,c_char_p)
There doesn't seem to be any other possible intent of this syntax.
Color me stupid, but being new to ctypes, it took me approximately 30
hours to discover a method of such assignment that worked (babar.raw is
not rejected, but not correct, debugging that was fun. I actually fell
upon addressof(babar), which does also works, but is probably
undesirable.)
It would be very friendly if ctypes would just do the right thing.
It doesn't seem like there is any other possible intent of such
a syntax.
----------
assignee: theller
components: ctypes
messages: 81123
nosy: PeterASilva, theller
severity: normal
status: open
title: syntactic sugar: type coercion on pointer assignment
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5149>
_______________________________________
From report at bugs.python.org Wed Feb 4 09:37:44 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 04 Feb 2009 08:37:44 +0000
Subject: [New-bugs-announce] [issue5150] IDLE to support reindent.py
In-Reply-To: <1233736664.4.0.115705275626.issue5150@psf.upfronthosting.co.za>
Message-ID: <1233736664.4.0.115705275626.issue5150@psf.upfronthosting.co.za>
New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:
Add rstrip() to the Format menu.
Python's svn repository no longer accepts files with trailing whitespace
and it is often necessary to run reindent.py before submitting. It
would be nice to have this as a built-in formatting tool.
----------
assignee: kbk
components: IDLE
messages: 81131
nosy: kbk, rhettinger
priority: normal
severity: normal
status: open
title: IDLE to support reindent.py
type: feature request
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5150>
_______________________________________
From report at bugs.python.org Wed Feb 4 17:43:56 2009
From: report at bugs.python.org (Nicholas Patterson)
Date: Wed, 04 Feb 2009 16:43:56 +0000
Subject: [New-bugs-announce] [issue5151] extractall method for TarFile
objects not setting owner:group on directories
In-Reply-To: <1233765836.67.0.207576838338.issue5151@psf.upfronthosting.co.za>
Message-ID: <1233765836.67.0.207576838338.issue5151@psf.upfronthosting.co.za>
New submission from Nicholas Patterson <nicholas_patterson at agilent.com>:
Used the TarFile object to create a bzip2 compressed tar file (seems to
have worked fine). Then used the extractall method to restore the
archive in a new location. All the files appear to have the same
permissions and owner:group as before, but most of the directories
('state' is only exception) have different permissions and the
owner:group are set to the UID that was running the script in this case
root:root.
Partial original location listing
/opt/fallback> ls -l /opt/agilent/ipcore/02.01/config
total 112
drwxrwxrwx 2 agilent agilent 4096 Feb 3 14:07 dist
-rwxrwxrwx 1 agilent agilent 208 Feb 3 14:07 hostnameCache.xml
-rwxrwxrwx 1 agilent agilent 1000 Feb 3 14:07 hostnamecache.xsd
drwxr-xr-x 4 agilent agilent 4096 Feb 3 14:08 inuse
-rwxrwxrwx 1 agilent agilent 4019 Feb 3 14:07 log4cxx.properties
-rwxrwxrwx 1 agilent agilent 9437 Feb 3 14:07 log4cxx.xml_template
drwxrwxrwx 3 agilent agilent 4096 Feb 3 14:07 mebs
-rwxrwxrwx 1 agilent agilent 4283 Feb 3 14:07 protocol.xml
-rwxrwxrwx 1 agilent agilent 8339 Feb 3 14:07 registry.ini
drwxrwxrwx 2 agilent agilent 4096 Feb 3 14:07 state
-rwxrwxrwx 1 agilent agilent 886 Feb 3 14:07 trunknamecache.xsd
Partial new location listing
/opt/fallback> ll config
total 120
drwxr-xr-x 6 root root 4096 Feb 3 16:38 ./
drwxrwxr-x 8 agilent agilent 4096 Feb 3 16:38 ../
drwxr-xr-x 2 root root 4096 Feb 3 16:38 dist/
-rwxrwxrwx 1 agilent agilent 208 Feb 3 14:07 hostnameCache.xml*
-rwxrwxrwx 1 agilent agilent 1000 Feb 3 14:07 hostnamecache.xsd*
drwxr-xr-x 4 root root 4096 Feb 3 16:38 inuse/
-rwxrwxrwx 1 agilent agilent 4019 Feb 3 14:07 log4cxx.properties*
-rwxrwxrwx 1 agilent agilent 9437 Feb 3 14:07 log4cxx.xml_template*
drwxr-xr-x 3 root root 4096 Feb 3 16:38 mebs/
-rwxrwxrwx 1 agilent agilent 4283 Feb 3 14:07 protocol.xml*
-rwxrwxrwx 1 agilent agilent 8339 Feb 3 14:07 registry.ini*
drwxrwxrwx 2 agilent agilent 4096 Feb 3 14:07 state/
----------
components: None
messages: 81143
nosy: npatters
severity: normal
status: open
title: extractall method for TarFile objects not setting owner:group on directories
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5151>
_______________________________________
From report at bugs.python.org Wed Feb 4 21:11:30 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 04 Feb 2009 20:11:30 +0000
Subject: [New-bugs-announce] [issue5152] Add a JSON-RPC module
In-Reply-To: <1233778290.63.0.330214687259.issue5152@psf.upfronthosting.co.za>
Message-ID: <1233778290.63.0.330214687259.issue5152@psf.upfronthosting.co.za>
New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:
Add a JSON analogue to xmlrpclib. See:
http://en.wikipedia.org/wiki/JSON-RPC
In some ways, it is much nicer than its XML cousin with bi-directional
communication, faster/simpler parsing, and ability to use TCP/IP
directly (not requiring HTTP transport).
----------
assignee: rhettinger
messages: 81153
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Add a JSON-RPC module
type: feature request
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5152>
_______________________________________
From report at bugs.python.org Wed Feb 4 21:17:56 2009
From: report at bugs.python.org (Adam Vandenberg)
Date: Wed, 04 Feb 2009 20:17:56 +0000
Subject: [New-bugs-announce] [issue5153] Extra ) in optparse sample
In-Reply-To: <1233778676.16.0.751248384993.issue5153@psf.upfronthosting.co.za>
Message-ID: <1233778676.16.0.751248384993.issue5153@psf.upfronthosting.co.za>
New submission from Adam Vandenberg <flangy at gmail.com>:
In the "Callback example 6: variable arguments" section of the optparse
documentation, the example code has an extra ) at the end of the last
line of the function:
setattr(parser.values, option.dest, value))
----------
assignee: georg.brandl
components: Documentation
messages: 81154
nosy: adamvan, georg.brandl
severity: normal
status: open
title: Extra ) in optparse sample
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5153>
_______________________________________
From report at bugs.python.org Wed Feb 4 23:32:22 2009
From: report at bugs.python.org (Ben Bangert)
Date: Wed, 04 Feb 2009 22:32:22 +0000
Subject: [New-bugs-announce] [issue5154] OSX broken poll testing doesn't work
In-Reply-To: <1233786742.9.0.12404457396.issue5154@psf.upfronthosting.co.za>
Message-ID: <1233786742.9.0.12404457396.issue5154@psf.upfronthosting.co.za>
New submission from Ben Bangert <ben at groovie.org>:
OSX 10.5 has a broken poll, this is an already known issue as I noticed
there's even a HAVE_BROKEN_POLL option that is in the source:
http://mail.python.org/pipermail/python-checkins/2006-April/051710.html
However, this run-time check apparently does not work, as I continue to
get socket errors related to the broken poll (On *any* version of Python
I compile from 2.4 through 2.6) unless I recompile Python and manually
comment out HAVE_POLL like the first line of Apple's Python patch here:
http://www.opensource.apple.com/darwinsource/10.5.6/python-30.1.2/fix/pyconfig.ed
Further, I think its quite likely that other bugs being submitted all
over the place from users running MacPorts on OSX are misdiagnosing this
bug as they believe its related to other software, when it is in fact
specific to custom compiles (MacPorts included) of Python. This bug
usually manifests itself as a Socket 35 error like so:
http://bugs.python.org/issue1085
http://www.cherrypy.org/ticket/598
This issue was diagnosed for me by Phil Jenvey, who believes that all
versions of OSX to date have had a broken poll (which reflects my paste
experience with this socket 35 bug as well).
I'm not sure of the most appropriate fix, I've submitted a bug to
MacPorts as well with the recommendation that for now they apply a patch
to undef HAVE_POLL, as Apple does.
----------
components: Library (Lib)
messages: 81171
nosy: bbangert
severity: normal
status: open
title: OSX broken poll testing doesn't work
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5154>
_______________________________________
From report at bugs.python.org Thu Feb 5 02:52:53 2009
From: report at bugs.python.org (Beau Butler)
Date: Thu, 05 Feb 2009 01:52:53 +0000
Subject: [New-bugs-announce] [issue5155] Multiprocessing.Queue created by
subprocess fails when used in sub-sub-process
In-Reply-To: <1233798773.64.0.357189782395.issue5155@psf.upfronthosting.co.za>
Message-ID: <1233798773.64.0.357189782395.issue5155@psf.upfronthosting.co.za>
New submission from Beau Butler <beau.butler at gmail.com>:
(Note: This issue only happens on linux - on Windows things work fine.)
Please see the attached script.
The script creates a process (TestProcess()). That process runs and
creates a sub-process (TestSubProcess()). When TestSubProcess tries to
access a Queue created by TestProcess, the .get() call fails with the
following stack trace:
Process Process-1:1:
Traceback (most recent call last):
File "/opt/python2.6/lib/python2.6/multiprocessing/process.py", line
231, in _bootstrap
self.run()
File "/opt/python2.6/lib/python2.6/multiprocessing/process.py", line
88, in run
self._target(*self._args, **self._kwargs)
File "queue_test.py", line 7, in TestSubProcess
item = q.get() # Fails with IOError if queue
created in TestProcess
File "/opt/python2.6/lib/python2.6/multiprocessing/queues.py", line
91, in get
res = self._recv()
IOError: [Errno 9] Bad file descriptor
If the same queue is created by main (top level), TestSubProcess
accesses it with no errors. This behavior can be stimulated by
uncommenting the q = multiprocessing.Queue() line in TestProcess.
Tested using:
Python 2.6.1 (r261:67517, Dec 4 2008, 16:51:00) [MSC v.1500 32 bit
(Intel)] on win32
(Installed using binary installer, windows XPSP2)
*No problems*
Python 2.6.1 (r261:67515, Jan 6 2009, 15:23:19) [GCC 4.2.4 (Ubuntu
4.2.4-1ubuntu3)] on linux2
(Compiled from source due to ubuntu 8.04 (Hardy) not having python2.6 yet)
*Fails on q.get() in TestSubProcess*
----------
components: Library (Lib)
files: queue_test.py
messages: 81183
nosy: bbutler
severity: normal
status: open
title: Multiprocessing.Queue created by subprocess fails when used in sub-sub-process
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file12944/queue_test.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5155>
_______________________________________
From report at bugs.python.org Thu Feb 5 11:02:44 2009
From: report at bugs.python.org (Peter Harris)
Date: Thu, 05 Feb 2009 10:02:44 +0000
Subject: [New-bugs-announce] [issue5156] IDLE exits with UnicodeDecodeError
on Ctrl+Space
In-Reply-To: <1233828164.4.0.121104337122.issue5156@psf.upfronthosting.co.za>
Message-ID: <1233828164.4.0.121104337122.issue5156@psf.upfronthosting.co.za>
New submission from Peter Harris <scav at users.sourceforge.net>:
Using Python3.1 built from svn, on RedHat EL4, with Tcl/Tk 8.5 built
from source.
Traceback:
------------------
File "/usr/mlocal/lib/python3.1/runpy.py", line 122, in
_run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/mlocal/lib/python3.1/runpy.py", line 34, in _run_code
exec(code, run_globals)
File "/usr/mlocal/lib/python3.1/idlelib/idle.py", line 22, in <module>
idlelib.PyShell.main()
File "/usr/mlocal/lib/python3.1/idlelib/PyShell.py", line 1407, in main
root.mainloop()
File "/usr/mlocal/lib/python3.1/tkinter/__init__.py", line 1009, in
mainloop
self.tk.mainloop(n)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1:
illegal encoding
----------------
The list of completions appears just before the crash. I can't tell
whether the error occurs within tkinter or IDLE.
If I find out where to put the try/except I'll submit a patch.
----------
components: IDLE
messages: 81190
nosy: scav
severity: normal
status: open
title: IDLE exits with UnicodeDecodeError on Ctrl+Space
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5156>
_______________________________________
From report at bugs.python.org Thu Feb 5 16:02:02 2009
From: report at bugs.python.org (Antoine Calando)
Date: Thu, 05 Feb 2009 15:02:02 +0000
Subject: [New-bugs-announce] [issue5157] os.stat('foo') succeds if 'foo.exe'
exists on cygwin
In-Reply-To: <1233846122.88.0.160860469386.issue5157@psf.upfronthosting.co.za>
Message-ID: <1233846122.88.0.160860469386.issue5157@psf.upfronthosting.co.za>
New submission from Antoine Calando <acalando at free.fr>:
On cygwin platform, with python cygwin package:
Python 2.5.2 (r252:60911, Dec 2 2008, 09:26:14)
When doing an os.stat('file') in a directory where no 'file' exists
but a 'file.exe' do, the function return a stat object, as if the call
was done on os.stat('file.exe').
After a few investigations, the problem come from the posix builtin
library used by python-cygwin.
I guess this is a workaround to have some calls like os.stat('/bin/ls')
not failing, but is a dirty workaround. 'file' and 'file.exe' are two
different files whatever the system you are on.
This problem was found due to a strange behaviour from scons.
I also check with other functions like os.lstat() and os.access() and
it is the same problem.
----------
components: Windows
messages: 81214
nosy: calandoa
severity: normal
status: open
title: os.stat('foo') succeds if 'foo.exe' exists on cygwin
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5157>
_______________________________________
From report at bugs.python.org Thu Feb 5 16:55:34 2009
From: report at bugs.python.org (Manuel Balsera)
Date: Thu, 05 Feb 2009 15:55:34 +0000
Subject: [New-bugs-announce] [issue5158] Document distutils 'depends' option
for extensions
In-Reply-To: <1233849334.58.0.0898669443765.issue5158@psf.upfronthosting.co.za>
Message-ID: <1233849334.58.0.0898669443765.issue5158@psf.upfronthosting.co.za>
New submission from Manuel Balsera <mbalsera at yahoo.com>:
Add a paragraph describing distuils depends option.
Its my first patch, let me know if I messed up formmating, etc.
----------
components: Distutils
files: setupscript.diff
keywords: patch
messages: 81217
nosy: mbalsera
severity: normal
status: open
title: Document distutils 'depends' option for extensions
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file12946/setupscript.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5158>
_______________________________________
From report at bugs.python.org Thu Feb 5 21:08:25 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 05 Feb 2009 20:08:25 +0000
Subject: [New-bugs-announce] [issue5159] Indicating packages to be loaded
when a Tcl interpreter is created in tkinter
In-Reply-To: <1233864505.11.0.366828040714.issue5159@psf.upfronthosting.co.za>
Message-ID: <1233864505.11.0.366828040714.issue5159@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
Hi,
It seems to me that it would be useful to add something to indicate
which packages should be loaded, and how they should be loaded, when a
Tcl interpreter is created through Tkinter.Tk. Right now every extension
has to add some boilerplate code to load a package before starting the
use of extension, and this code tends to be very similar -- like this:
if not required_extension_loaded:
extlib = os.environ.get('OPTIONAL_VAR_THAT_POINTS_TO_EXT')
if extlib:
master.tk.eval('global auto_path; '
'lappend auto_path {%s}' % extlib)
master.tk.call('package', 'require', 'Extlibname')
required_extension_loaded = True
master is an instance of Tkinter.Tk which has to be created before this,
of course. Some extensions do it in different places in their code, but
tend to involve basically the same code.
The patch attached adds a new module in lib-tk named tkdeploader (not
very nice eh) which handles these "indications". Each dependence to be
loaded can define its own preloader callable, but the module adds a
basic one, named basic_preloader, that should be enough for most
situations. The patch also includes the changes necessary in Tkinter.py,
just two lines.
----------
components: Tkinter
files: tkdeploader.diff
keywords: patch
messages: 81223
nosy: gpolo
severity: normal
status: open
title: Indicating packages to be loaded when a Tcl interpreter is created in tkinter
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file12947/tkdeploader.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5159>
_______________________________________
From report at bugs.python.org Thu Feb 5 22:11:52 2009
From: report at bugs.python.org (Corey Goldberg)
Date: Thu, 05 Feb 2009 21:11:52 +0000
Subject: [New-bugs-announce] [issue5160] Intermittant segmentation fault
with ctrl-c (threads and queues)
In-Reply-To: <1233868312.9.0.87638822413.issue5160@psf.upfronthosting.co.za>
Message-ID: <1233868312.9.0.87638822413.issue5160@psf.upfronthosting.co.za>
New submission from Corey Goldberg <cgoldberg at gmail.com>:
I can get the Python interpreter to core dump when running the following
code:
http://pastebin.com/f261f398f
To reproduce:
- run the above code and press ctrl-c to quit while it is running. It
crashes (segfault) the interpreter every few times you stop it like this.
I think it has something to do with the thread launching another thread
containing a queue.
- Tested on Windows XP and Ubuntu Linux 8.10 (both running Python 2.5.2)
----------
components: Interpreter Core
messages: 81228
nosy: cgoldberg
severity: normal
status: open
title: Intermittant segmentation fault with ctrl-c (threads and queues)
type: crash
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5160>
_______________________________________
From report at bugs.python.org Fri Feb 6 01:45:44 2009
From: report at bugs.python.org (Neil Schemenauer)
Date: Fri, 06 Feb 2009 00:45:44 +0000
Subject: [New-bugs-announce] [issue5161] wrong paths for ctypes cleanup
In-Reply-To: <1233881144.37.0.958366280661.issue5161@psf.upfronthosting.co.za>
Message-ID: <1233881144.37.0.958366280661.issue5161@psf.upfronthosting.co.za>
New submission from Neil Schemenauer <nas-python at arctrix.com>:
The following code was added to Makefile.pre.in when ctypes was merged:
find $(srcdir)/build -name 'fficonfig.h' -exec rm -f {} ';' || true
find $(srcdir)/build -name 'fficonfig.py' -exec rm -f {} ';' || true
If Python is compiled in a directory other than the source directory
than $(srcdir)/build does not exist and these commands don't work as
intended. I think that proper path would be simply "build".
----------
assignee: theller
components: Build
messages: 81243
nosy: nascheme, theller
priority: low
severity: normal
status: open
title: wrong paths for ctypes cleanup
type: compile error
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5161>
_______________________________________
From report at bugs.python.org Fri Feb 6 03:00:32 2009
From: report at bugs.python.org (Volodymyr Orlenko)
Date: Fri, 06 Feb 2009 02:00:32 +0000
Subject: [New-bugs-announce] [issue5162] multiprocessing cannot spawn child
from a Windows service
In-Reply-To: <1233885632.9.0.0484597105973.issue5162@psf.upfronthosting.co.za>
Message-ID: <1233885632.9.0.0484597105973.issue5162@psf.upfronthosting.co.za>
New submission from Volodymyr Orlenko <orlenko at gmail.com>:
I think I've found a small bug with multiprocessing package on
Windows. If you try to start a multiprocessing.Process from a Python-
based Windows service, the child process will fail to run. When
running the parent process as a regular Python program, everything
works as expected.
I've tracked the problem down to how main_path is prepared in
multiprocessing.forking.get_preparation_data() (lines 370-377):
def get_preparation_data(name):
[...skipped a few lines...]
if not WINEXE:
main_path = getattr(sys.modules['__main__'], '__file__', None)
if not main_path and sys.argv[0] not in ('', '-c'):
main_path = sys.argv[0]
if main_path is not None:
if not os.path.isabs(main_path) and \
process.ORIGINAL_DIR is not
None:
main_path = os.path.join(process.ORIGINAL_DIR,
main_path)
d['main_path'] = os.path.normpath(main_path)
return d
When the program is running as a Windows service, but is not packaged
into a single executable, main_path will become the path to the
service executable (typically, pythonservice.exe). When this data
makes it to the child process, the prepare() function will treat
main_path as a path to a python module, and will try to import it.
This causes it to fail.
My quick-and-dirty solution was to check in get_preparation_data() if
main_path ends with '.exe', and if it does, to not pass it at all.
This solves the problem in my case, but perhaps there's a better way
to fix this? Here is my version of get_preparation_data():
def get_preparation_data(name):
'''
Return info about parent needed by child to unpickle process
object
'''
from .util import _logger, _log_to_stderr
d = dict(
name=name,
sys_path=sys.path,
sys_argv=sys.argv,
log_to_stderr=_log_to_stderr,
orig_dir=process.ORIGINAL_DIR,
authkey=process.current_process().authkey,
)
if _logger is not None:
d['log_level'] = _logger.getEffectiveLevel()
if not WINEXE:
main_path = getattr(sys.modules['__main__'], '__file__', None)
if not main_path and sys.argv[0] not in ('', '-c'):
main_path = sys.argv[0]
if main_path is not None:
if not os.path.isabs(main_path) and \
process.ORIGINAL_DIR is not
None:
main_path = os.path.join(process.ORIGINAL_DIR,
main_path)
if not main_path.endswith('.exe'):
d['main_path'] = os.path.normpath(main_path)
return d
----------
components: Library (Lib)
files: forking-patch
messages: 81247
nosy: jnoller, orlenko
severity: normal
status: open
title: multiprocessing cannot spawn child from a Windows service
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file12949/forking-patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5162>
_______________________________________
From report at bugs.python.org Fri Feb 6 06:48:51 2009
From: report at bugs.python.org (David Schultz)
Date: Fri, 06 Feb 2009 05:48:51 +0000
Subject: [New-bugs-announce] [issue5163] tkinter.scrolledtext: new text is
hidden after using insert()
In-Reply-To: <1233899331.85.0.574945693305.issue5163@psf.upfronthosting.co.za>
Message-ID: <1233899331.85.0.574945693305.issue5163@psf.upfronthosting.co.za>
New submission from David Schultz <ringhome at cox.net>:
I've added a "keep at bottom" option to the scrolledtext class. This way,
if a user wants to always see the text added via "insert()", it will be
visible.
----------
components: Tkinter
messages: 81248
nosy: ringhome
severity: normal
status: open
title: tkinter.scrolledtext: new text is hidden after using insert()
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5163>
_______________________________________
From report at bugs.python.org Fri Feb 6 10:06:35 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 06 Feb 2009 09:06:35 +0000
Subject: [New-bugs-announce] [issue5164] backport distutils 3.x changes into
2.7 when appliabl
In-Reply-To: <1233911195.36.0.922992904897.issue5164@psf.upfronthosting.co.za>
Message-ID: <1233911195.36.0.922992904897.issue5164@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
It's annoying to get conflicts on changes in distutils in the trunk,
when forward-porting to 3.x, because other changes where made there and
only there.
Things like PEP8-ification and modern syntax changes needs to be
backported to 2.7 when appliable to reduce the gap.
----------
assignee: tarek
components: Distutils
messages: 81253
nosy: tarek
priority: high
severity: normal
status: open
title: backport distutils 3.x changes into 2.7 when appliabl
type: behavior
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5164>
_______________________________________
From report at bugs.python.org Fri Feb 6 11:20:34 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 06 Feb 2009 10:20:34 +0000
Subject: [New-bugs-announce] [issue5165] os.rename and other raise
WindowsError
In-Reply-To: <1233915634.72.0.359575992053.issue5165@psf.upfronthosting.co.za>
Message-ID: <1233915634.72.0.359575992053.issue5165@psf.upfronthosting.co.za>
New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:
in lib/test/test_os.py, there is a test class, Win32ErrorTests, that
tests that certain functions return a WindowsError on failure. And
indeed they do that, but that is in contradiction with the
documentation. From the 2.6 docs:
Note
All functions in this module raise OSError in the case of invalid or
inaccessible file names and paths, or other arguments that have the
correct type, but are not accepted by the operating system.
----------
components: Interpreter Core
messages: 81256
nosy: krisvale
severity: normal
status: open
title: os.rename and other raise WindowsError
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5165>
_______________________________________
From report at bugs.python.org Fri Feb 6 12:13:45 2009
From: report at bugs.python.org (Denis S. Otkidach)
Date: Fri, 06 Feb 2009 11:13:45 +0000
Subject: [New-bugs-announce] [issue5166] ElementTree and minidom don't
prevent creation of not well-formed XML
In-Reply-To: <1233918825.25.0.360851750395.issue5166@psf.upfronthosting.co.za>
Message-ID: <1233918825.25.0.360851750395.issue5166@psf.upfronthosting.co.za>
New submission from Denis S. Otkidach <denis.otkidach at gmail.com>:
ElementTree and minidom allow creation of not well-formed XML, that
can't be parsed:
>>> from xml.etree import ElementTree
>>> element = ElementTree.Element('element')
>>> element.text = u'\0'
>>> xml = ElementTree.tostring(element, encoding='utf-8')
>>> ElementTree.fromstring(xml)
[...]
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 1,
column 9
>>> from xml.dom import minidom
>>> doc = minidom.getDOMImplementation().createDocument(None, None, None)
>>> element = doc.createElement('element')
>>> element.appendChild(doc.createTextNode(u'\0'))
<DOM Text node "">
>>> doc.appendChild(element)
<DOM Element: element at 0xb7ca688c>
>>> xml = doc.toxml(encoding='utf-8')
>>> minidom.parseString(xml)
[...]
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 1, colum
I believe they should raise some exception when there are characters
not allowed in XML (http://www.w3.org/TR/REC-xml/#NT-Char) are used in
attribute values, text nodes and CDATA sections.
----------
components: Library (Lib)
messages: 81259
nosy: ods
severity: normal
status: open
title: ElementTree and minidom don't prevent creation of not well-formed XML
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5166>
_______________________________________
From report at bugs.python.org Fri Feb 6 13:56:38 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 06 Feb 2009 12:56:38 +0000
Subject: [New-bugs-announce] [issue5167] distutils/test_customize_compiler
fails on windows
In-Reply-To: <1233924998.48.0.430995834835.issue5167@psf.upfronthosting.co.za>
Message-ID: <1233924998.48.0.430995834835.issue5167@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
test_customize_compiler fails on windows with following error message.
ERROR: test_customize_compiler
(distutils.tests.test_sysconfig.SysconfigTestCase
)
----------------------------------------------------------------------
Traceback (most recent call last):
File "e:\python-dev\trunk\lib\distutils\tests\test_sysconfig.py", line
54, in
test_customize_compiler
sysconfig.customize_compiler(comp)
File "e:\python-dev\trunk\lib\distutils\sysconfig.py", line 181, in
customize_
compiler
cpp = cc + " -E" # not always
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
I hope attached patch will fix this.
----------
components: Distutils, Tests
files: fix_distutils_test.patch
keywords: patch
messages: 81261
nosy: ocean-city, tarek
severity: normal
stage: patch review
status: open
title: distutils/test_customize_compiler fails on windows
versions: Python 2.7
Added file: http://bugs.python.org/file12951/fix_distutils_test.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5167>
_______________________________________
From report at bugs.python.org Fri Feb 6 14:18:38 2009
From: report at bugs.python.org (=?utf-8?q?Horv=C3=A1th_Istv=C3=A1n_R=C3=B3bert?=)
Date: Fri, 06 Feb 2009 13:18:38 +0000
Subject: [New-bugs-announce] [issue5168] shutil.copystat does not copy the
"hidden" flag on windows
In-Reply-To: <1233926318.17.0.887740362056.issue5168@psf.upfronthosting.co.za>
Message-ID: <1233926318.17.0.887740362056.issue5168@psf.upfronthosting.co.za>
New submission from Horv?th Istv?n R?bert <throbi at gmail.com>:
Hi!
While copying hidden files on windows, the hidden flag is lost
(surprisingly the read-only flag is copied).
Is this a bug or a feature? The documentation only says that flags are
also copied by shutil.copystat, but no details.
See the attached file for an example.
Cheers,
Robert
----------
components: Windows
files: copyHiddenFile.zip
messages: 81263
nosy: throbi
severity: normal
status: open
title: shutil.copystat does not copy the "hidden" flag on windows
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file12952/copyHiddenFile.zip
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5168>
_______________________________________
From report at bugs.python.org Fri Feb 6 15:16:28 2009
From: report at bugs.python.org (=?utf-8?q?Chema_Cort=C3=A9s?=)
Date: Fri, 06 Feb 2009 14:16:28 +0000
Subject: [New-bugs-announce] [issue5169] Default hash not equal to id on AMD
Sempron
In-Reply-To: <1233929788.34.0.870033033845.issue5169@psf.upfronthosting.co.za>
Message-ID: <1233929788.34.0.870033033845.issue5169@psf.upfronthosting.co.za>
New submission from Chema Cort?s <dev.xtrem at gmail.com>:
Sometimes, the default hash for user-defined object is not equal to the
id of the object:
In [1]: class A:
...: pass
In [2]: a=A()
In [3]: id(a),hash(a)
Out[3]: (3082955212L, -1212012084)
The test box has an AMD Sempron, a 64bit CPU archictecture emulating a
32bit one. This following relation can be deduced:
hash(a)=id(a)-2**32
----------
components: Interpreter Core
messages: 81269
nosy: chemacortes, jcea
severity: normal
status: open
title: Default hash not equal to id on AMD Sempron
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5169>
_______________________________________
From report at bugs.python.org Fri Feb 6 17:07:47 2009
From: report at bugs.python.org (shamilbi)
Date: Fri, 06 Feb 2009 16:07:47 +0000
Subject: [New-bugs-announce] [issue5170] logging to file + encoding
In-Reply-To: <1233936467.22.0.152712476213.issue5170@psf.upfronthosting.co.za>
Message-ID: <1233936467.22.0.152712476213.issue5170@psf.upfronthosting.co.za>
New submission from shamilbi <shamilbi at gmail.com>:
if i configure logging into a file with encoding = 'cp1251' and do
logger.debug(u'...') then i get crash with UnicodeError
i suggest reimplementing method FileHandler.emit():
...
if isinstance(msg, unicode):
stream.write(f % msg) # it works!
...
----------
components: Library (Lib)
messages: 81274
nosy: shamilbi
severity: normal
status: open
title: logging to file + encoding
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5170>
_______________________________________
From report at bugs.python.org Fri Feb 6 17:49:05 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 06 Feb 2009 16:49:05 +0000
Subject: [New-bugs-announce] [issue5171] itertools.product docstring missing
'repeat' argument
In-Reply-To: <1233938945.33.0.092220516904.issue5171@psf.upfronthosting.co.za>
Message-ID: <1233938945.33.0.092220516904.issue5171@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
The docstring for itertools.product seems to be missing any mention of the
repeat keyword argument, in both the trunk and py3k, and the maintenance
branches.
(The itertools.rst docs are fine, though.)
----------
assignee: rhettinger
components: Library (Lib)
messages: 81281
nosy: marketdickinson, rhettinger
severity: normal
status: open
title: itertools.product docstring missing 'repeat' argument
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5171>
_______________________________________
From report at bugs.python.org Fri Feb 6 18:21:28 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 06 Feb 2009 17:21:28 +0000
Subject: [New-bugs-announce] [issue5172] python-dev tracker summary emails
contain incorrect "median duration of open issues" information
In-Reply-To: <1233940888.36.0.479497649391.issue5172@psf.upfronthosting.co.za>
Message-ID: <1233940888.36.0.479497649391.issue5172@psf.upfronthosting.co.za>
New submission from Jean-Paul Calderone <exarkun at divmod.com>:
The weekly tracker summary emails sent to python-dev contain incorrect
information. The value for the "median duration of open issues" it
reports has recently wrapped around to 0 and started growing from there.
Looking at older reports, it's clear that there's a bug in the
calculation of this value, since it jumps from a median of several years
to a median of one day in the span of one week.
----------
messages: 81285
nosy: exarkun
severity: normal
status: open
title: python-dev tracker summary emails contain incorrect "median duration of open issues" information
type: behavior
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5172>
_______________________________________
From report at bugs.python.org Fri Feb 6 19:07:58 2009
From: report at bugs.python.org (Matthew Woodcraft)
Date: Fri, 06 Feb 2009 18:07:58 +0000
Subject: [New-bugs-announce] [issue5173] "What's new" claims StandardError
was removed in 2.6
In-Reply-To: <1233943678.15.0.95933788083.issue5173@psf.upfronthosting.co.za>
Message-ID: <1233943678.15.0.95933788083.issue5173@psf.upfronthosting.co.za>
New submission from Matthew Woodcraft <mjw at pearson.co.uk>:
In the current "What's New In Python 3.0" documentation, under "Changes
To Exceptions", it is claimed that the removal of StandardError is "in
2.6 already".
But according to the 2.6.1 documentation, StandardError is still there
in its usual place.
----------
assignee: georg.brandl
components: Documentation
messages: 81288
nosy: georg.brandl, mjwpp
severity: normal
status: open
title: "What's new" claims StandardError was removed in 2.6
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5173>
_______________________________________
From report at bugs.python.org Fri Feb 6 23:19:27 2009
From: report at bugs.python.org (Calvin Spealman)
Date: Fri, 06 Feb 2009 22:19:27 +0000
Subject: [New-bugs-announce] [issue5174] xmlrpclib docs include incorrect
file closing
In-Reply-To: <1233958767.06.0.465205017873.issue5174@psf.upfronthosting.co.za>
Message-ID: <1233958767.06.0.465205017873.issue5174@psf.upfronthosting.co.za>
New submission from Calvin Spealman <ironfroggy at users.sourceforge.net>:
The following example from the xmlrpclib docs has an obviously erronous
call to close() after the actual return.
(http://docs.python.org/library/xmlrpclib.html)
def python_logo():
handle = open("python_logo.jpg")
return xmlrpclib.Binary(handle.read())
handle.close()
The patch included also makes the whitespace PEP-8 compliant.
----------
assignee: georg.brandl
components: Documentation
files: xmlrpc_doc.patch
keywords: patch
messages: 81309
nosy: georg.brandl, ironfroggy
severity: normal
status: open
title: xmlrpclib docs include incorrect file closing
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12961/xmlrpc_doc.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5174>
_______________________________________
From report at bugs.python.org Sat Feb 7 00:37:46 2009
From: report at bugs.python.org (Lisandro Dalcin)
Date: Fri, 06 Feb 2009 23:37:46 +0000
Subject: [New-bugs-announce] [issue5175] negative PyLong -> C unsigned
integral, TypeError or OverflowError?
In-Reply-To: <1233963466.4.0.0489916221286.issue5175@psf.upfronthosting.co.za>
Message-ID: <1233963466.4.0.0489916221286.issue5175@psf.upfronthosting.co.za>
New submission from Lisandro Dalcin <dalcinl at gmail.com>:
At Objects/longobject.c, in almost all cases
OverflowError is raised when a unsigned integral is requested from a
negative PyLong. However, this one breaks the rules:
int
_PyLong_AsByteArray(PyLongObject* v,
unsigned char* bytes, size_t n,
int little_endian, int is_signed)
{
<...>
if (!is_signed) {
PyErr_SetString(PyExc_TypeError,
"can't convert negative long to
unsigned");
return -1;
}
<...>
}
----------
components: Interpreter Core
messages: 81316
nosy: dalcinl
severity: normal
status: open
title: negative PyLong -> C unsigned integral, TypeError or OverflowError?
type: behavior
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5175>
_______________________________________
From report at bugs.python.org Sat Feb 7 00:49:49 2009
From: report at bugs.python.org (Collin Winter)
Date: Fri, 06 Feb 2009 23:49:49 +0000
Subject: [New-bugs-announce] [issue5176] Special-case string formatting in
BINARY_MODULO implementation
In-Reply-To: <1233964189.56.0.504237250684.issue5176@psf.upfronthosting.co.za>
Message-ID: <1233964189.56.0.504237250684.issue5176@psf.upfronthosting.co.za>
New submission from Collin Winter <collinw at gmail.com>:
This patch speeds up the string formatting % operator by avoiding the
unnecessary indirection in PyNumber_Remainder(). This particularly
benefits templating systems that do a lot of string formatting via %.
Performance tested with gcc 4.3.1 x86_64 on Linux 2.6.18:
2to3:
Min: 22.443 -> 22.306: 0.61% faster
Avg: 22.465 -> 22.324: 0.63% faster
Django:
Min: 0.598 -> 0.591: 1.24% faster
Avg: 0.601 -> 0.595: 1.03% faster
Spitfire [1]:
Min: 0.752 -> 0.717: 4.91% faster
Avg: 0.754 -> 0.719: 4.83% faster
The Django test renders a 150x150 cell table 100 times. The Spitfire
test renders a 1000x1000 cell table 100 times. The 2to3 test translates
all of 2to3 with `-f all` five times. There is no significant impact on
PyBench. Less important code like the pure-Python pickle implementation
also shows an improvement:
Pickling:
Min: 6.680 -> 6.535: 2.22% faster
Avg: 6.740 -> 6.576: 2.50% faster
This is pickling a list of 40000 dicts 100 times. This does not impact
unpickling.
About the patch:
I tested various combinations of PyString_Check and PyString_CheckExact
and what you see in the patch demonstrated the best performance across
all benchmarks. I also tested changing the definition of PyString_Check
to include a short-circuit on PyString_CheckExact, but that did not
provide a consistent benefit.
[1] - http://code.google.com/p/spitfire/
----------
assignee: jyasskin
components: Interpreter Core
files: faster_modulo.patch
keywords: needs review, patch, patch
messages: 81319
nosy: collinwinter, jyasskin
severity: normal
status: open
title: Special-case string formatting in BINARY_MODULO implementation
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file12962/faster_modulo.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5176>
_______________________________________
From report at bugs.python.org Sat Feb 7 15:13:04 2009
From: report at bugs.python.org (Jon Dee)
Date: Sat, 07 Feb 2009 14:13:04 +0000
Subject: [New-bugs-announce] [issue5177] multiprocessing: SocketListener
should use SO_REUSEADDR
In-Reply-To: <1234015984.6.0.0454721510443.issue5177@psf.upfronthosting.co.za>
Message-ID: <1234015984.6.0.0454721510443.issue5177@psf.upfronthosting.co.za>
New submission from Jon Dee <j.a.t.dee at gmail.com>:
Without this flag it is necessary to wait for e.g. 120s after closing
down a 'BaseManager' server before restarting, due to the socket being
in the TIME_WAIT state.
Example error, which occurs if a server is started, data transmitted
down the socket, the server shut down, then restarted:
File "/usr/local/lib/python2.6/multiprocessing/connection.py", line
220, in __init__
self._socket.bind(address)
File "<string>", line 1, in bind
error: [Errno 48] Address already in use
I added (locally):
self._socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
to SocketListener.__init__, and it resolves the issue.
----------
components: Library (Lib)
messages: 81336
nosy: jon_dee
severity: normal
status: open
title: multiprocessing: SocketListener should use SO_REUSEADDR
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5177>
_______________________________________
From report at bugs.python.org Sat Feb 7 18:54:21 2009
From: report at bugs.python.org (Neil Schemenauer)
Date: Sat, 07 Feb 2009 17:54:21 +0000
Subject: [New-bugs-announce] [issue5178] Add content manager for temporary
directory
In-Reply-To: <1234029261.42.0.975383428204.issue5178@psf.upfronthosting.co.za>
Message-ID: <1234029261.42.0.975383428204.issue5178@psf.upfronthosting.co.za>
New submission from Neil Schemenauer <nas-python at arctrix.com>:
I noticed that it would be nice to have a temporary directory context
manager while trying to fix a broken unittest. The attached patch
provides a pretty minimal implementation. There appears to be lots of
unit tests that could use such a thing (just search for "rmtree").
I'm not sure if TemporaryDirectory is the best name. Also, perhaps it
should have a __del__ method although that's tricky business.
----------
assignee: ncoghlan
files: tempdir.patch
keywords: patch
messages: 81342
nosy: nascheme, ncoghlan
severity: normal
stage: patch review
status: open
title: Add content manager for temporary directory
type: feature request
Added file: http://bugs.python.org/file12970/tempdir.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5178>
_______________________________________
From report at bugs.python.org Sat Feb 7 21:04:40 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 07 Feb 2009 20:04:40 +0000
Subject: [New-bugs-announce] [issue5179] subprocess leaves open fds on
construction error
In-Reply-To: <1234037080.37.0.0531724857804.issue5179@psf.upfronthosting.co.za>
Message-ID: <1234037080.37.0.0531724857804.issue5179@psf.upfronthosting.co.za>
New submission from Georg Brandl <georg at python.org>:
The test case below will (on Linux here) eventually quit with "OSError:
[Errno 24] Too many open files". I assume that some additional cleaning
up is in order.
-------------------------------------------------------------------
from subprocess import Popen, PIPE
while 1:
try:
Popen(['nonexisting'], stdout=PIPE, stderr=PIPE)
except OSError, err:
if err.errno != 2: # ignore "no such file"
raise
----------
components: Library (Lib)
messages: 81347
nosy: georg.brandl
priority: high
severity: normal
status: open
title: subprocess leaves open fds on construction error
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5179>
_______________________________________
From report at bugs.python.org Sat Feb 7 23:28:55 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Feb 2009 22:28:55 +0000
Subject: [New-bugs-announce] [issue5180] 3.1 cannot unpickle 2.7-created
pickle
In-Reply-To: <1234045735.61.0.752787259691.issue5180@psf.upfronthosting.co.za>
Message-ID: <1234045735.61.0.752787259691.issue5180@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
The pickle was generated by pybench. You can try to display it by running:
./python Tools/pybench/pybench.py --debug -s 27.bench
It fails with the following traceback:
Traceback (most recent call last):
File "Tools/pybench/pybench.py", line 954, in <module>
PyBenchCmdline()
File "/home/antoine/py3k/__svn__/Tools/pybench/CommandLine.py", line
349, in __init__
rc = self.main()
File "Tools/pybench/pybench.py", line 888, in main
bench = pickle.load(f)
File "/home/antoine/py3k/__svn__/Lib/pickle.py", line 1335, in load
return Unpickler(file, encoding=encoding, errors=errors).load()
_pickle.UnpicklingError: bad pickle data
----------
components: Extension Modules
messages: 81351
nosy: alexandre.vassalotti, pitrou
priority: high
severity: normal
status: open
title: 3.1 cannot unpickle 2.7-created pickle
type: behavior
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5180>
_______________________________________
From report at bugs.python.org Sat Feb 7 23:47:39 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Feb 2009 22:47:39 +0000
Subject: [New-bugs-announce] [issue5181] test_urllib failures on the 3.1
buildbots
In-Reply-To: <1234046859.35.0.878327501712.issue5181@psf.upfronthosting.co.za>
Message-ID: <1234046859.35.0.878327501712.issue5181@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
This failure happens on all 3.x buildbots:
======================================================================
ERROR: test_empty_socket (test.test_urllib.urlopen_HttpTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/home/pybot/buildarea/3.x.klose-debian-ppc/build/Lib/test/test_urllib.py",
line 194, in test_empty_socket
self.assertRaises(IOError, urlopen, "http://something")
File
"/home/pybot/buildarea/3.x.klose-debian-ppc/build/Lib/unittest.py", line
344, in failUnlessRaises
callableObj(*args, **kwargs)
File
"/home/pybot/buildarea/3.x.klose-debian-ppc/build/Lib/test/test_urllib.py",
line 33, in urlopen
return opener.open(url)
File
"/home/pybot/buildarea/3.x.klose-debian-ppc/build/Lib/urllib/request.py", line
1444, in open
return getattr(self, name)(url)
File
"/home/pybot/buildarea/3.x.klose-debian-ppc/build/Lib/urllib/request.py", line
1618, in open_http
return self._open_generic_http(http.client.HTTPConnection, url, data)
File
"/home/pybot/buildarea/3.x.klose-debian-ppc/build/Lib/urllib/request.py", line
1601, in _open_generic_http
response = http_conn.getresponse()
File
"/home/pybot/buildarea/3.x.klose-debian-ppc/build/Lib/http/client.py",
line 937, in getresponse
method=self._method)
File
"/home/pybot/buildarea/3.x.klose-debian-ppc/build/Lib/http/client.py",
line 275, in __init__
self.fp = sock.makefile("rb")
TypeError: makefile() takes exactly 3 positional arguments (2 given)
======================================================================
ERROR: test_read (test.test_urllib.urlopen_HttpTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/home/pybot/buildarea/3.x.klose-debian-ppc/build/Lib/test/test_urllib.py",
line 168, in test_read
fp = urlopen("http://python.org/")
File
"/home/pybot/buildarea/3.x.klose-debian-ppc/build/Lib/test/test_urllib.py",
line 33, in urlopen
return opener.open(url)
File
"/home/pybot/buildarea/3.x.klose-debian-ppc/build/Lib/urllib/request.py", line
1444, in open
return getattr(self, name)(url)
File
"/home/pybot/buildarea/3.x.klose-debian-ppc/build/Lib/urllib/request.py", line
1618, in open_http
return self._open_generic_http(http.client.HTTPConnection, url, data)
File
"/home/pybot/buildarea/3.x.klose-debian-ppc/build/Lib/urllib/request.py", line
1601, in _open_generic_http
response = http_conn.getresponse()
File
"/home/pybot/buildarea/3.x.klose-debian-ppc/build/Lib/http/client.py",
line 937, in getresponse
method=self._method)
File
"/home/pybot/buildarea/3.x.klose-debian-ppc/build/Lib/http/client.py",
line 275, in __init__
self.fp = sock.makefile("rb")
TypeError: makefile() takes exactly 3 positional arguments (2 given)
======================================================================
ERROR: test_read_bogus (test.test_urllib.urlopen_HttpTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/home/pybot/buildarea/3.x.klose-debian-ppc/build/Lib/test/test_urllib.py",
line 185, in test_read_bogus
self.assertRaises(IOError, urlopen, "http://python.org/")
File
"/home/pybot/buildarea/3.x.klose-debian-ppc/build/Lib/unittest.py", line
344, in failUnlessRaises
callableObj(*args, **kwargs)
File
"/home/pybot/buildarea/3.x.klose-debian-ppc/build/Lib/test/test_urllib.py",
line 33, in urlopen
return opener.open(url)
File
"/home/pybot/buildarea/3.x.klose-debian-ppc/build/Lib/urllib/request.py", line
1444, in open
return getattr(self, name)(url)
File
"/home/pybot/buildarea/3.x.klose-debian-ppc/build/Lib/urllib/request.py", line
1618, in open_http
return self._open_generic_http(http.client.HTTPConnection, url, data)
File
"/home/pybot/buildarea/3.x.klose-debian-ppc/build/Lib/urllib/request.py", line
1601, in _open_generic_http
response = http_conn.getresponse()
File
"/home/pybot/buildarea/3.x.klose-debian-ppc/build/Lib/http/client.py",
line 937, in getresponse
method=self._method)
File
"/home/pybot/buildarea/3.x.klose-debian-ppc/build/Lib/http/client.py",
line 275, in __init__
self.fp = sock.makefile("rb")
TypeError: makefile() takes exactly 3 positional arguments (2 given)
----------
messages: 81353
nosy: krisvale, pitrou
priority: critical
severity: normal
stage: needs patch
status: open
title: test_urllib failures on the 3.1 buildbots
type: behavior
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5181>
_______________________________________
From report at bugs.python.org Sun Feb 8 04:05:42 2009
From: report at bugs.python.org (Mark Hammond)
Date: Sun, 08 Feb 2009 03:05:42 +0000
Subject: [New-bugs-announce] [issue5182] str() on memoryview of bytearray
failing on py3k
In-Reply-To: <1234062342.43.0.913128436395.issue5182@psf.upfronthosting.co.za>
Message-ID: <1234062342.43.0.913128436395.issue5182@psf.upfronthosting.co.za>
New submission from Mark Hammond <mhammond at users.sourceforge.net>:
% py30 -c "str(memoryview(bytearray((1,2,3))))"
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: __str__ returned non-string (type bytes)
The expected behaviour is that a string representation be returned.
----------
messages: 81363
nosy: mhammond
severity: normal
status: open
title: str() on memoryview of bytearray failing on py3k
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5182>
_______________________________________
From report at bugs.python.org Sun Feb 8 06:24:24 2009
From: report at bugs.python.org (Stephen Day)
Date: Sun, 08 Feb 2009 05:24:24 +0000
Subject: [New-bugs-announce] [issue5183] wsgiref.simple_server not working
In-Reply-To: <1234070664.0.0.314425486198.issue5183@psf.upfronthosting.co.za>
Message-ID: <1234070664.0.0.314425486198.issue5183@psf.upfronthosting.co.za>
New submission from Stephen Day <stephen.h.day at gmail.com>:
The attached application doesn't work. I think the value of self.headers
(see line 114) has a blank line at the end that it did not in Python 2.5
Here is the error message that occurs when it gets a request
(http://127.0.0.1:8080/):
Exception happened during processing of request from ('127.0.0.1',
60549)
Traceback (most recent call last):
File "C:\Python30\lib\socketserver.py", line 281, in
_handle_request_noblock
self.process_request(request, client_address)
File "C:\Python30\lib\socketserver.py", line 307, in process_request
self.finish_request(request, client_address)
File "C:\Python30\lib\socketserver.py", line 320, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "C:\Python30\lib\socketserver.py", line 614, in __init__
self.handle()
File "C:\Python30\lib\wsgiref\simple_server.py", line 136, in handle
self.rfile, self.wfile, self.get_stderr(), self.get_environ()
File "C:\Python30\lib\wsgiref\simple_server.py", line 115, in
get_environ
k,v = h.split(':',1)
ValueError: need more than 1 value to unpack
----------
components: Library (Lib)
files: test_server.py
messages: 81366
nosy: StephenDay
severity: normal
status: open
title: wsgiref.simple_server not working
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file12976/test_server.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5183>
_______________________________________
From report at bugs.python.org Sun Feb 8 11:34:16 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 08 Feb 2009 10:34:16 +0000
Subject: [New-bugs-announce] [issue5184] Add -3 warning for extension types
that implement tp_compare but not tp_richcompare
In-Reply-To: <1234089256.12.0.28890692519.issue5184@psf.upfronthosting.co.za>
Message-ID: <1234089256.12.0.28890692519.issue5184@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
See
http://mail.python.org/pipermail/python-dev/2009-February/085809.html
where Nick Coghlan writes:
"I'm wondering if Mark should add the exception he recently removed back
in as a Deprecation Warning when tp_compare is defined, but
tp_richcompare is not. Such a warning should also be present when
running with -3 in 2.7 (assuming it isn't already there)."
A technical difficulty with adding this warning is that various built-in
types implement tp_compare but not tp_richcompare. For example: int,
long, slice, buffer, instancemethod, cell and bool all do this.
----------
messages: 81371
nosy: marketdickinson, ncoghlan
severity: normal
status: open
title: Add -3 warning for extension types that implement tp_compare but not tp_richcompare
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5184>
_______________________________________
From report at bugs.python.org Sun Feb 8 17:17:30 2009
From: report at bugs.python.org (Jeffery Aubin)
Date: Sun, 08 Feb 2009 16:17:30 +0000
Subject: [New-bugs-announce] [issue5185] Idle doesn't work on 2.6 on Macbook
In-Reply-To: <1234109850.83.0.858099103097.issue5185@psf.upfronthosting.co.za>
Message-ID: <1234109850.83.0.858099103097.issue5185@psf.upfronthosting.co.za>
New submission from Jeffery Aubin <jefferyaubin at oricom.ca>:
I work with IDLE on a PC at the office and now I've installed version 2.6
for mac on my Macbook at home. I wanted to have access to IDLE at home to
read my code and add some things here and there. But, I cannot get it to
work. It opens up on the dock and disapears right away. I've try to open a
.py file using IDLE as a default and it didn't work. I've read some forums
on this issue but nothing that quite fit the description of my problem.
How can I get it to work?
----------
components: IDLE
messages: 81388
nosy: jeaub23
severity: normal
status: open
title: Idle doesn't work on 2.6 on Macbook
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5185>
_______________________________________
From report at bugs.python.org Sun Feb 8 17:36:18 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 08 Feb 2009 16:36:18 +0000
Subject: [New-bugs-announce] [issue5186] Reduce hash collisions for objects
with no __hash__ method
In-Reply-To: <1234110978.24.0.675256166012.issue5186@psf.upfronthosting.co.za>
Message-ID: <1234110978.24.0.675256166012.issue5186@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
In the issue 5169 discussion, Antoine Pitrou suggested that for an object
x without a __hash__ method, id()/8 might be a better hash value than
id(), since dicts use the low order bits of the hash as initial key, and
the 3 lowest bits of an id() will always be zero.
Here's a patch.
----------
components: Interpreter Core
files: pointer_hash.patch
keywords: patch
messages: 81389
nosy: marketdickinson, pitrou, rhettinger
priority: normal
severity: normal
status: open
title: Reduce hash collisions for objects with no __hash__ method
type: performance
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file12977/pointer_hash.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5186>
_______________________________________
From report at bugs.python.org Sun Feb 8 22:27:48 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 08 Feb 2009 21:27:48 +0000
Subject: [New-bugs-announce] [issue5187] distutils upload should prompt for
the user/password too
In-Reply-To: <1234128468.86.0.0554273106388.issue5187@psf.upfronthosting.co.za>
Message-ID: <1234128468.86.0.0554273106388.issue5187@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
finalize_option in upload command should ask for the password, if not
given by pypirc or by a previous register command.
----------
assignee: tarek
components: Distutils
messages: 81420
nosy: tarek
priority: low
severity: normal
status: open
title: distutils upload should prompt for the user/password too
type: feature request
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5187>
_______________________________________
From report at bugs.python.org Sun Feb 8 23:16:12 2009
From: report at bugs.python.org (David Christian)
Date: Sun, 08 Feb 2009 22:16:12 +0000
Subject: [New-bugs-announce] [issue5188] telnetlib process_rawq buffer
handling is confused
In-Reply-To: <1234131372.15.0.372715702734.issue5188@psf.upfronthosting.co.za>
Message-ID: <1234131372.15.0.372715702734.issue5188@psf.upfronthosting.co.za>
New submission from David Christian <dbc at rpath.com>:
in telnetlib's process_rawq, rawq_getchar() returns a bytes object of
length 1.
However, that buffer is then compared directly against the variable IAC,
which is the integer 255. This is always false, as bytes([255]) != 255.
Checked svn and looks like this issue still exists as of 2/8/2009.
----------
messages: 81424
nosy: dugan
severity: normal
status: open
title: telnetlib process_rawq buffer handling is confused
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5188>
_______________________________________
From report at bugs.python.org Mon Feb 9 03:58:27 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Feb 2009 02:58:27 +0000
Subject: [New-bugs-announce] [issue5189] test_cmd_line failure on the OS X
buildbot
In-Reply-To: <1234148307.24.0.286213836725.issue5189@psf.upfronthosting.co.za>
Message-ID: <1234148307.24.0.286213836725.issue5189@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
From
http://www.python.org/dev/buildbot/3.0/OS%20X%20x86%203.0/builds/81/step-test/0:
Re-running test 'test_cmd_line' in verbose mode
test_directories (test.test_cmd_line.CmdLineTest) ... ok
test_optimize (test.test_cmd_line.CmdLineTest) ... ok
test_q (test.test_cmd_line.CmdLineTest) ... ok
test_run_code (test.test_cmd_line.CmdLineTest) ... FAIL
test_run_module (test.test_cmd_line.CmdLineTest) ... ok
test_run_module_bug1764407 (test.test_cmd_line.CmdLineTest) ... ok
test_site_flag (test.test_cmd_line.CmdLineTest) ... ok
test_unbuffered_input (test.test_cmd_line.CmdLineTest) ... ok
test_unbuffered_output (test.test_cmd_line.CmdLineTest) ... ok
test_usage (test.test_cmd_line.CmdLineTest) ... ok
test_verbose (test.test_cmd_line.CmdLineTest) ... ok
test_version (test.test_cmd_line.CmdLineTest) ... ok
======================================================================
FAIL: test_run_code (test.test_cmd_line.CmdLineTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/Users/buildbot/buildarea/3.0.noller-osx86/build/Lib/test/test_cmd_line.py",
line 143, in test_run_code
0)
AssertionError: 1 != 0
----------------------------------------------------------------------
Ran 12 tests in 3.394s
----------
components: Interpreter Core, Tests
messages: 81435
nosy: jnoller, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_cmd_line failure on the OS X buildbot
type: behavior
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5189>
_______________________________________
From report at bugs.python.org Mon Feb 9 14:23:12 2009
From: report at bugs.python.org (Bluebird)
Date: Mon, 09 Feb 2009 13:23:12 +0000
Subject: [New-bugs-announce] [issue5190] optparse doex not export make_option
In-Reply-To: <1234185792.84.0.378540305485.issue5190@psf.upfronthosting.co.za>
Message-ID: <1234185792.84.0.378540305485.issue5190@psf.upfronthosting.co.za>
New submission from Bluebird <phil at freehackers.org>:
The documentation of optparse mentions make_option() as the standard way
to create an option list:
For example, in the doc of python 2.5:
====
14.3.3.2 Populating the parser
[...]
pass it an Option instance (as returned by make_option())
[...]
option_list = [
make_option("-f", "--filename",
action="store", type="string", dest="filename"),
make_option("-q", "--quiet",
action="store_false", dest="verbose"),
]
(make_option() is a factory function for creating Option instances;
currently it is an alias for the Option constructor. A future version of
optparse may split Option into several classes, and make_option() will
pick the right class to instantiate. Do not instantiate Option
directly.)
===============
However, make_option is not part of the function exported in the __all__
list of optparse. Strangely enough, this does not prevent to use
make_option() in regular python scripts, but it does not work when
packaging a python application, for example with pyinstaller.
The problem is also present in python 2.6
The fix is either to update the documentation to use Option() directly
or to add make_option to __all__
----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 81456
nosy: bluebird, georg.brandl
severity: normal
status: open
title: optparse doex not export make_option
type: behavior
versions: Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5190>
_______________________________________
From report at bugs.python.org Mon Feb 9 14:59:20 2009
From: report at bugs.python.org (Ben North)
Date: Mon, 09 Feb 2009 13:59:20 +0000
Subject: [New-bugs-announce] [issue5191] Partial function application 'from
the right'
In-Reply-To: <1234187960.68.0.343533185797.issue5191@psf.upfronthosting.co.za>
Message-ID: <1234187960.68.0.343533185797.issue5191@psf.upfronthosting.co.za>
New submission from Ben North <bennorth at users.sourceforge.net>:
The functools module includes a 'partial' class, which allows partial
function application either by positional arguments or keyword
arguments. However, it cannot be used to create, for example, a
function splitting a string on commas, or a function to extracts logs to
base 10. I posted
http://mail.python.org/pipermail/python-dev/2009-January/085638.html
which suggested a 'partial_right' feature, such that the following would
work:
>>> import functools, math
>>> split_comma = functools.partial_right(str.split, ',')
>>> split_comma('a,b,c')
['a', 'b', 'c']
>>> log_10 = functools.partial_right(math.log, 10.0)
>>> log_10(100.0)
2.0
There was some useful discussion, but generally the feeling was that the
extra complexity outweighed the potential benefits. Also, chained
partial applications were troublesome.
The overlap in functionality between 'partial_right' and an existing
patch (#1706256) to allow skipping of positional arguments was raised.
I think the present issue should probably be closed/rejected, but it was
suggested on the mailing list that having the issue and patch on the
record might be useful. Patches are against 2.6.1 source.
----------
messages: 81457
nosy: bennorth
severity: normal
status: open
title: Partial function application 'from the right'
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5191>
_______________________________________
From report at bugs.python.org Mon Feb 9 17:44:12 2009
From: report at bugs.python.org (David W. Lambert)
Date: Mon, 09 Feb 2009 16:44:12 +0000
Subject: [New-bugs-announce] [issue5192] Update log message formatting.
In-Reply-To: <1234197852.95.0.276908828254.issue5192@psf.upfronthosting.co.za>
Message-ID: <1234197852.95.0.276908828254.issue5192@psf.upfronthosting.co.za>
New submission from David W. Lambert <lambertdw at corning.com>:
Allow logger object log message creation methods using ''.format method.
have:
logger_object.info('%s','lazy is better')
logger_object.debug('{0!s}'.format('wasted effort'))
want:
logger_object.debug('{0}','Lazy')
Work'rounds from pep282:
if log.isEnabledFor(logging.INFO):
hamletStr = hamletDom.toxml()
log.info(hamletStr)
or install custom Formatter.
I presume this is already on the back burner.
Incidentally, BufferingFormatter.format uses string += string instead of
''.join(list_of_strings).
----------
components: Library (Lib)
messages: 81461
nosy: LambertDW
severity: normal
status: open
title: Update log message formatting.
type: feature request
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5192>
_______________________________________
From report at bugs.python.org Mon Feb 9 18:08:57 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 09 Feb 2009 17:08:57 +0000
Subject: [New-bugs-announce] [issue5193] Guarantee that Tkinter.Text.search
returns a string
In-Reply-To: <1234199337.14.0.524717083127.issue5193@psf.upfronthosting.co.za>
Message-ID: <1234199337.14.0.524717083127.issue5193@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
Tkinter.Text.search is supposed to return a string, but this is not
always true. The problem is much more likely to be noticed while using
Tk 8.5.
----------
components: Tkinter
files: ensure_search_returns_str.diff
keywords: patch
messages: 81465
nosy: gpolo
severity: normal
status: open
title: Guarantee that Tkinter.Text.search returns a string
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12993/ensure_search_returns_str.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5193>
_______________________________________
From report at bugs.python.org Tue Feb 10 03:55:07 2009
From: report at bugs.python.org (Ned Deily)
Date: Tue, 10 Feb 2009 02:55:07 +0000
Subject: [New-bugs-announce] [issue5194] OS X IDLE.app and bin/idle:
missing/extra menu options
In-Reply-To: <1234234507.58.0.689231089961.issue5194@psf.upfronthosting.co.za>
Message-ID: <1234234507.58.0.689231089961.issue5194@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
IDLE is supposed to have various menu customizations when running on OS
X. But currently they do not all work and the menus vary if IDLE is
launched via IDLE.app versus via command line bin/idle. The most
noticeable issue is the lack of a Preferences menu item in IDLE.app to
access the IDLE configuration settings.
ANALYSIS There are inconsistent OS X execution checks scattered
throughout idlelib. Also, the bootstrap mechanism
for IDLE.app causes sys.executable to be set incorrectly.
Most importantly, idlemain imports idlelib before it
has fixed up the execution environment. This can cause
the menu fixup in idlelib.Bindings to be skipped.
SOLUTION Change idlemain to set up the execution environment
consistently and defer idlelib imports until it has done so.
Modify several OS X checks in idlelib for consistency.
APPLIES py3k, 3.0 -> patch-nad0014-py3k-30.txt
trunk, 2.6 -> patch-nad0014-trunk-26.txt
DELETE Mac/IDLE/idlemain.py (py3k and 3.0 only!)
NOTE In 3.x idlemain.py was copied down into the app bundle:
2.x -> Mac/IDLE/idlemain.py
3.x -> Mac/IDLE/IDLE.app/Contents/Resources/idlemain.py
3.x -> Mac/IDLE/idlemain.py -> unused / delete
so there are two versions of this patch.
However, the 2.x location was not deleted in 3.x svn
so there are two identical files in 3.x prior to this
patch.
----------
components: IDLE, Macintosh
files: patch-nad0014-trunk-26.txt
messages: 81525
nosy: nad
severity: normal
status: open
title: OS X IDLE.app and bin/idle: missing/extra menu options
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13001/patch-nad0014-trunk-26.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5194>
_______________________________________
From report at bugs.python.org Tue Feb 10 03:59:24 2009
From: report at bugs.python.org (Ned Deily)
Date: Tue, 10 Feb 2009 02:59:24 +0000
Subject: [New-bugs-announce] [issue5195] OS X IDLE.app and bin/idle:
incorrect key defaults in 3.x
In-Reply-To: <1234234764.34.0.510660013878.issue5195@psf.upfronthosting.co.za>
Message-ID: <1234234764.34.0.510660013878.issue5195@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
3.x IDLE uses incorrect default key definitions on OS X
If you have not already customized your IDLE key definitions
(in ~/.idlerc), 3.x IDLE uses Windows defaults in its menus.
ANALYSIS In 2.x, the IDLE Makefile customized the default configs
in Lib/idlelib. In 3.x there is no longer a separate
IDLE Makefile and the customization step is missing.
SOLUTION Add the OS X customization to the Mac/Makefile.
APPLIES py3k, 3.0
----------
components: IDLE, Macintosh
files: patch-nad0015-py3k-30.txt
messages: 81526
nosy: nad
severity: normal
status: open
title: OS X IDLE.app and bin/idle: incorrect key defaults in 3.x
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13003/patch-nad0015-py3k-30.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5195>
_______________________________________
From report at bugs.python.org Tue Feb 10 04:04:46 2009
From: report at bugs.python.org (Ned Deily)
Date: Tue, 10 Feb 2009 03:04:46 +0000
Subject: [New-bugs-announce] [issue5196] OS X IDLE.app: may not launch on 3.x
In-Reply-To: <1234235086.65.0.906288935492.issue5196@psf.upfronthosting.co.za>
Message-ID: <1234235086.65.0.906288935492.issue5196@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
3.x OS X IDLE.app may not launch
ANALYSIS 2.x IDLE.app was built using its own Makefile + bundlebuilder.
For 3.x, these were eliminated by checking in a skeleton app
based on the bundlebuilder model. But the install tailoring
of the app does not quite work in all cases.
SOLUTION Have the Mac/Makefile do the necessary tailoring.
Remove from the IDLE launch script the unnecessary bits left
over from bundlebuilder.
APPLIES py3k, 3.0
SEE ALSO Issue5194 and Issue5195:
patch-nad0014, patch-nad0015 (should be applied first)
----------
components: IDLE, Macintosh
files: patch-nad0016-py3k-30.txt
messages: 81527
nosy: nad
severity: normal
status: open
title: OS X IDLE.app: may not launch on 3.x
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13004/patch-nad0016-py3k-30.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5196>
_______________________________________
From report at bugs.python.org Tue Feb 10 06:14:43 2009
From: report at bugs.python.org (pest)
Date: Tue, 10 Feb 2009 05:14:43 +0000
Subject: [New-bugs-announce] [issue5197] vars() assignment fails silently
when assignments made later
In-Reply-To: <1234242883.43.0.910584647004.issue5197@psf.upfronthosting.co.za>
Message-ID: <1234242883.43.0.910584647004.issue5197@psf.upfronthosting.co.za>
New submission from pest <luke at asterisk.co.nz>:
Assignments to vars() behave incorrectly if those variables are use
later on in a function.
For example, try this:
======
#!/usr/bin/python
def zz():
for i in [1,2,3]:
for j in [4,5,6]:
vars()['fw_%s_%s' % (j,i)] = 'test %s %s' % (j, i)
print vars()['fw_%s_%s' % (j,i)]
fw_4_2 = 'zz'
print fw_4_2
zz()
======
The assignments work fine up till 4_2. At 4_2, the assignment apparently
fails silently, and the print raises a keyError exception.
----------
components: None
messages: 81530
nosy: pest
severity: normal
status: open
title: vars() assignment fails silently when assignments made later
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5197>
_______________________________________
From report at bugs.python.org Tue Feb 10 08:14:48 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Tue, 10 Feb 2009 07:14:48 +0000
Subject: [New-bugs-announce] [issue5198] Strange DeprecationWarning
behaviour in module struct
In-Reply-To: <1234250088.94.0.680929615779.issue5198@psf.upfronthosting.co.za>
Message-ID: <1234250088.94.0.680929615779.issue5198@psf.upfronthosting.co.za>
New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:
struct.pack seems to raise a DeprecationWarning for some structure
formats, but not for others:
Python 2.6.1 (r261:67515, Dec 5 2008, 07:40:41)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> struct.pack(">H", 1.0)
sys:1: DeprecationWarning: integer argument expected, got float
'\x00\x01'
>>> struct.pack("H", 1.0)
'\x01\x00'
In addition the DeprecationWarning message gives a strange location for
the problem. With the attached struct_warning.py it locates the problem
at the function call foo() instead of the problematic call of struct.pack:
$ python2.6 struct_warning.py
struct_warning.py:6: DeprecationWarning: integer argument expected, got
float
foo()
----------
components: Library (Lib)
files: struct_warning.py
messages: 81532
nosy: hagen
severity: normal
status: open
title: Strange DeprecationWarning behaviour in module struct
type: behavior
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file13007/struct_warning.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5198>
_______________________________________
From report at bugs.python.org Tue Feb 10 08:46:07 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 10 Feb 2009 07:46:07 +0000
Subject: [New-bugs-announce] [issue5199] warns vars() assignment as well as
locals()
In-Reply-To: <1234251967.11.0.473034551632.issue5199@psf.upfronthosting.co.za>
Message-ID: <1234251967.11.0.473034551632.issue5199@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
This comes from issue5197. Maybe we can emphasize a behavior of
assignment to vars() is undefined if decorated with red block of
*warning* as well as locals(). This patch is for release26-maint.
----------
assignee: georg.brandl
components: Documentation
files: warn_vars_assignment.patch
keywords: patch
messages: 81534
nosy: georg.brandl, ocean-city
severity: normal
status: open
title: warns vars() assignment as well as locals()
Added file: http://bugs.python.org/file13008/warn_vars_assignment.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5199>
_______________________________________
From report at bugs.python.org Tue Feb 10 11:45:57 2009
From: report at bugs.python.org (Peter Landgren)
Date: Tue, 10 Feb 2009 10:45:57 +0000
Subject: [New-bugs-announce] [issue5200] unicode.normalize gives wrong
result for some characters
In-Reply-To: <1234262757.38.0.115515150702.issue5200@psf.upfronthosting.co.za>
Message-ID: <1234262757.38.0.115515150702.issue5200@psf.upfronthosting.co.za>
New submission from Peter Landgren <peter.talken at telia.com>:
If any of the Swedish characters "??????" are input to
unicode.normalize(form, ustr) with form = "NFD" or "NFKD" the result
will be "aaoAAO". "??????" are normal character and should be the same
after normalize. They are not connected to aaoAAO other than for
historic reasons, but not in modern languages. It's a common
misinterpretation that the dots and circle above them are diacritic
signs, but those letters should behave as the (Danish)
"?" which is normalized correctly.
>From Wikipedia:
? is often perceived as an A with a ring, interpreting the ring as a
diacritical mark. However, in the languages that use it, the ring is not
considered a diacritic but part of the letter.
The letter ? in the Swedish and Icelandic alphabets historically arises
from the Germanic umlaut, but it is considered a separate letter from O.
See http://en.wikipedia.org/wiki/%C3%85
I think this is pobably impossible to solve as it will be mixed up with
"umlaut" and you don't know what language the specific word is connected to.
----------
components: Library (Lib)
messages: 81536
nosy: PeterL
severity: normal
status: open
title: unicode.normalize gives wrong result for some characters
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5200>
_______________________________________
From report at bugs.python.org Tue Feb 10 12:44:52 2009
From: report at bugs.python.org (Floris Bruynooghe)
Date: Tue, 10 Feb 2009 11:44:52 +0000
Subject: [New-bugs-announce] [issue5201] Using
LDFLAGS='-rpath=\$$LIB:/some/other/path' ./configure breaks
the build
In-Reply-To: <1234266292.13.0.602157766238.issue5201@psf.upfronthosting.co.za>
Message-ID: <1234266292.13.0.602157766238.issue5201@psf.upfronthosting.co.za>
New submission from Floris Bruynooghe <floris.bruynooghe at gmail.com>:
When specifying an RPATH with -rpath or -R you can use the special
tokens `$LIB' and `$ORIGIN' which the runtime linker interprets as
"normal search path" and "relative to current sofile" respectively. To
get these correctly to the gcc command line you need to specify this in
LDFLAGS as `\$$LIB' to work around escapes of both the makefile and
shell, so in the Python Makefile this will appear somewhere as (this is
on one line):
CONFIG_ARGS= '--prefix=/opt/example.com/python25'
'LDFLAGS=-Wl,-rpath=\$$LIB:/opt/example.com/lib,--enable-new-dtags'
This works for compiling the main python binary. But when the extension
modules get compiled distutils chokes on this.
distutils.sysconfig.parse_makefile() does think that any value of a
variable that contains `$' in it refers to an other variable in the
makefile. It will fail to find the value and CONFIG_ARGS will not be
defined. This then fails in setup.py for the _ctypes extension:
if not '--with-system-ffi' in sysconfig.get_config_var("CONFIG_ARGS"):
return
Where `None' is returned instead of a list by .get_config_var().
It seems that distutils.sysconfig.parse_makefile() needs to understand
more of the makefile synatax to deal with this.
----------
assignee: tarek
components: Distutils
messages: 81538
nosy: flub, tarek
severity: normal
status: open
title: Using LDFLAGS='-rpath=\$$LIB:/some/other/path' ./configure breaks the build
type: compile error
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5201>
_______________________________________
From report at bugs.python.org Tue Feb 10 12:45:01 2009
From: report at bugs.python.org (David Jones)
Date: Tue, 10 Feb 2009 11:45:01 +0000
Subject: [New-bugs-announce] [issue5202] wave.py cannot write wave files
into a shell pipeline
In-Reply-To: <1234266301.49.0.830035453307.issue5202@psf.upfronthosting.co.za>
Message-ID: <1234266301.49.0.830035453307.issue5202@psf.upfronthosting.co.za>
New submission from David Jones <drj at pobox.com>:
When using the wave module to output wave files, the output file cannot
be a Unix pipeline.
Example. The following program outputs a (trivial) wave file on stdout:
#!/usr/bin/env python
import sys
import wave
w = wave.open(sys.stdout, 'w')
w.setnchannels(1)
w.setsampwidth(1)
w.setframerate(32000)
w.setnframes(0)
w.close()
It can create a wave file like this:
$ ./bugex > foo.wav
When used in a pipeline we get:
$ ./bugex | wc
Traceback (most recent call last):
File "./bugex", line 9, in <module>
w.close()
File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/wave.py
", line 437, in close
self._ensure_header_written(0)
File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/wave.py
", line 458, in _ensure_header_written
self._write_header(datasize)
File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/wave.py
", line 465, in _write_header
self._form_length_pos = self._file.tell()
IOError: [Errno 29] Illegal seek
Exception exceptions.IOError: (29, 'Illegal seek') in <bound method
Wave_write.__del__ of <wave.Wave_write instance at 0x71418>> ignored
0 1 8
The wave module has almost all it needs to work around this problem.
The wave module will only seek the output if it needs to patch the
header. If you use setnframes to write the correct number of frames
before writing them with writeframesraw then the header will not be
patched upon calling close. However...
The problem is that the "tell" method is invoked on the output stream
(to record where the header is, in the event that we need to patch it);
the "tell" method fails with an exception when the output is a pipeline
(see example, above).
Exceptions from "tell" when writing the header initially (in
_write_header) should be ignored. If _patchheader is later invoked it
will fail due to lack of pos.
----------
components: Library (Lib)
messages: 81539
nosy: drj
severity: normal
status: open
title: wave.py cannot write wave files into a shell pipeline
type: behavior
versions: Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5202>
_______________________________________
From report at bugs.python.org Tue Feb 10 13:48:04 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 10 Feb 2009 12:48:04 +0000
Subject: [New-bugs-announce] [issue5203] ctypes segfaults when passing a
unicode string to a function without argtypes
In-Reply-To: <1234270084.65.0.170774259742.issue5203@psf.upfronthosting.co.za>
Message-ID: <1234270084.65.0.170774259742.issue5203@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:
The following code segfaults on platforms where HAVE_USABLE_WCHAR_T is
not defined (for example: narrow unicode build and sizeof(wchar_t)==4)
>>> from ctypes import *
>>> import ctypes.util
>>> CDLL(ctypes.util.find_library('c')).wcslen(u'text')
(it works if the argtypes member is defined)
The reason is a non initialized structure, and the correction is trivial:
--- Modules/_ctypes/callproc.c~ 2007-06-15 19:10:41.000000000 +0200
+++ Modules/_ctypes/callproc.c 2009-02-10 13:28:10.000000000 +0100
@@ -538,6 +538,7 @@
int size = PyUnicode_GET_SIZE(obj);
size += 1; /* terminating NUL */
size *= sizeof(wchar_t);
+ pa->ffi_type = &ffi_type_pointer;
pa->value.p = PyMem_Malloc(size);
if (!pa->value.p) {
PyErr_NoMemory();
----------
assignee: theller
components: ctypes
messages: 81544
nosy: amaury.forgeotdarc, theller
severity: normal
status: open
title: ctypes segfaults when passing a unicode string to a function without argtypes
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5203>
_______________________________________
From report at bugs.python.org Tue Feb 10 15:08:35 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 10 Feb 2009 14:08:35 +0000
Subject: [New-bugs-announce] [issue5204] test.os/TestInvalidFD/test_fdopen
on VC6
In-Reply-To: <1234274915.85.0.510245571983.issue5204@psf.upfronthosting.co.za>
Message-ID: <1234274915.85.0.510245571983.issue5204@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
This comes from issue4804. This simple patch is required to pass
test_fdopen on VC6.
----------
components: Windows
files: test_fdopen_on_vc6.patch
keywords: patch
messages: 81551
nosy: ocean-city
severity: normal
stage: commit review
status: open
title: test.os/TestInvalidFD/test_fdopen on VC6
versions: Python 2.7
Added file: http://bugs.python.org/file13013/test_fdopen_on_vc6.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5204>
_______________________________________
From report at bugs.python.org Tue Feb 10 16:04:25 2009
From: report at bugs.python.org (Lie Ryan)
Date: Tue, 10 Feb 2009 15:04:25 +0000
Subject: [New-bugs-announce] [issue5205] String Formatting with namedtuple
In-Reply-To: <1234278265.2.0.777488862861.issue5205@psf.upfronthosting.co.za>
Message-ID: <1234278265.2.0.777488862861.issue5205@psf.upfronthosting.co.za>
New submission from Lie Ryan <lie.1296 at gmail.com>:
I've been experimenting with namedtuple, it seems that string formatting
doesn't recognize namedtuple as mapping.
from collections import namedtuple
Nt = namedtuple('Nt', ['x', 'y'])
nt = Nt(12, 32)
print 'one = %(x)s, two = %(y)s' % nt
# output should be:
one = 12, two = 32
currently, it is possible to use nt._asdict() as a workaround, but I
think it will be easier and more intuitive to be able to use namedtuple
directly with string interpolation.
I tried this with 2.6 and 2.7a (trunk). Haven't seen 3.0 yet.
PS: Although the following works, it is not the topic of the issue:
print 'one = %s, two = %s' % nt
----------
components: Library (Lib)
messages: 81555
nosy: lieryan
severity: normal
status: open
title: String Formatting with namedtuple
type: feature request
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5205>
_______________________________________
From report at bugs.python.org Tue Feb 10 18:00:32 2009
From: report at bugs.python.org (Martin Blais)
Date: Tue, 10 Feb 2009 17:00:32 +0000
Subject: [New-bugs-announce] [issue5206] with context object for unittest
assertRaises()
In-Reply-To: <1234285232.23.0.329909688935.issue5206@psf.upfronthosting.co.za>
Message-ID: <1234285232.23.0.329909688935.issue5206@psf.upfronthosting.co.za>
New submission from Martin Blais <blais at furius.ca>:
Here is a useful trick to restore the normal call syntax for delayed
evaluation for assertRaises():
from contextlib import contextmanager
@contextmanager
def raised(exctype):
try:
yield
raise AssertionError("Exception %s not raised." %
exctype.__name__)
except exctype, e:
pass
Then you can do this::
with raised(ValueError):
rate = foo(arg1, arg2)
Instead of ::
self.assertRaises(foo, arg1, arg2)
Which means you don't have to break the function from its arguments (it
doesn't look like a function call anymore).
P.S. I know I didn't include self up there in my proposed implementation
but it could be parameterized to get the failureException.
(This is a second issue:)
However, I really think that all the failUnlessXXX methods should be
taken out of the class and made available at module level so that they
can be reused by py.test tests as well, and they are perhaps even worthy
of their own module. I can't remember a single instance where I had to
override that failureException class...
Comments welcome, I'd be happy to fix this one myself if we can restore
my commit privileges (I think they expired because I didn't use them
since the need-for-speed workshop.)
----------
messages: 81564
nosy: blais
severity: normal
status: open
title: with context object for unittest assertRaises()
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5206>
_______________________________________
From report at bugs.python.org Tue Feb 10 18:07:02 2009
From: report at bugs.python.org (Iakov Davydov)
Date: Tue, 10 Feb 2009 17:07:02 +0000
Subject: [New-bugs-announce] [issue5207] extend strftime/strptime format for
RFC3339 and RFC2822
In-Reply-To: <1234285622.79.0.0309055191852.issue5207@psf.upfronthosting.co.za>
Message-ID: <1234285622.79.0.0309055191852.issue5207@psf.upfronthosting.co.za>
New submission from Iakov Davydov <dav01 at myths.ru>:
Currently there is no obvious way to parse time from ISO
8601/W3C/RFC3339 date&time format (http://www.ietf.org/rfc/rfc3339.txt)
or RFC2822. (Actually RFC2822 could be parsed with rfc822 module but
that is not very good way).
I suggest that we should add special directive (let's say %o) for time
offset which is "Z" or ("+" / "-") time-hour ":" time-minute.
Also %O directive will parse zone: ( "+" / "-" ) time-hour time-minute.
(I suppose there is no need to support obsolate time zones but if that
is possible it's also good idea).
----------
components: Library (Lib)
messages: 81565
nosy: davydov
severity: normal
status: open
title: extend strftime/strptime format for RFC3339 and RFC2822
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5207>
_______________________________________
From report at bugs.python.org Tue Feb 10 18:16:26 2009
From: report at bugs.python.org (Max)
Date: Tue, 10 Feb 2009 17:16:26 +0000
Subject: [New-bugs-announce] [issue5208] urllib2.build_opener([handler,
...]) incorrect signature in docs
In-Reply-To: <1234286185.85.0.555213161426.issue5208@psf.upfronthosting.co.za>
Message-ID: <1234286185.85.0.555213161426.issue5208@psf.upfronthosting.co.za>
New submission from Max <mb at research-net.de>:
The build_opener() function of urllib2 is speciofied as:
urllib2.build_opener([handler, ...])
I think it should be:
urllib2.build_opener(handler, ...)
see
http://docs.python.org/library/urllib2.html?highlight=build_opener
----------
assignee: georg.brandl
components: Documentation
messages: 81567
nosy: B?hm, georg.brandl
severity: normal
status: open
title: urllib2.build_opener([handler, ...]) incorrect signature in docs
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5208>
_______________________________________
From report at bugs.python.org Tue Feb 10 20:42:48 2009
From: report at bugs.python.org (Travis Hassloch)
Date: Tue, 10 Feb 2009 19:42:48 +0000
Subject: [New-bugs-announce] [issue5209] nntplib needs updating to RFC 3977
In-Reply-To: <1234294968.88.0.213485994333.issue5209@psf.upfronthosting.co.za>
Message-ID: <1234294968.88.0.213485994333.issue5209@psf.upfronthosting.co.za>
New submission from Travis Hassloch <travis at giganews.com>:
RFC 977 has been obsoleted by RFC 3977
Numerous new commands, standardized extensions, clarifications.
----------
components: Library (Lib)
messages: 81587
nosy: travis
severity: normal
status: open
title: nntplib needs updating to RFC 3977
type: feature request
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5209>
_______________________________________
From report at bugs.python.org Tue Feb 10 20:46:20 2009
From: report at bugs.python.org (Travis Hassloch)
Date: Tue, 10 Feb 2009 19:46:20 +0000
Subject: [New-bugs-announce] [issue5210] zlib does not indicate end of
compressed stream properly
In-Reply-To: <1234295180.57.0.273384677161.issue5210@psf.upfronthosting.co.za>
Message-ID: <1234295180.57.0.273384677161.issue5210@psf.upfronthosting.co.za>
New submission from Travis Hassloch <travis at giganews.com>:
Underlying zlib can determine when it has hit the end of a compressed
stream without reading past the end. Python zlib implementation requires
that one read past the end before it signals the end by putting data in
Decompress.unused_data. This complicates interfacing with mixed
compressed/uncompressed streams.
----------
components: Library (Lib)
messages: 81590
nosy: travis
severity: normal
status: open
title: zlib does not indicate end of compressed stream properly
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5210>
_______________________________________
From report at bugs.python.org Wed Feb 11 00:19:23 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 10 Feb 2009 23:19:23 +0000
Subject: [New-bugs-announce] [issue5211] Fix complex type to avoid coercion
in 2.7.
In-Reply-To: <1234307963.56.0.00813246872741.issue5211@psf.upfronthosting.co.za>
Message-ID: <1234307963.56.0.00813246872741.issue5211@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
In the 'coercion rules' section of the reference manual, at:
http://docs.python.org/dev/reference/datamodel.html#id5
it says:
"""Over time, the type complex may be fixed to avoid coercion."""
In 3.x, the complex type has (necessarily) been fixed to avoid coercion,
and it ought to be a fairly easy task to backport that fix to 2.7, for
someone who wants to get his or her feet wet with some CPython hacking.
As far as I can see, there's no great benefit in such a change, except
that the presence of coercion for the complex type causes confusion
occasionally: see issue 3734 for an example of this.
----------
components: Interpreter Core
keywords: easy
messages: 81612
nosy: marketdickinson
priority: low
severity: normal
status: open
title: Fix complex type to avoid coercion in 2.7.
type: feature request
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________
From report at bugs.python.org Wed Feb 11 01:39:52 2009
From: report at bugs.python.org (.:. brainsik)
Date: Wed, 11 Feb 2009 00:39:52 +0000
Subject: [New-bugs-announce] [issue5212] Incorrect note about md5 in hmac
module documentation
In-Reply-To: <1234312792.25.0.547667950303.issue5212@psf.upfronthosting.co.za>
Message-ID: <1234312792.25.0.547667950303.issue5212@psf.upfronthosting.co.za>
New submission from .:. brainsik <spork-python at theory.org>:
The HMAC module page [1] says:
Note: The md5 hash has known weaknesses but remains the default for
backwards compatibility. Choose a better one for your application.
However, according to the "Hash Collision Q&A" [2] linked to from the
hashlib module [3], md5 is not vulnerable when used in an HMAC:
Q: Do these attacks break HMAC using MD5 or SHA-1?
A: No. Because of the way hash functions are used in the HMAC
construction, the techniques used in these recent attacks do not apply.
It seems like the note is incorrect.
1. http://docs.python.org/library/hmac.html
2. http://www.cryptography.com/cnews/hash.html
3. http://docs.python.org/library/hashlib.html
----------
assignee: georg.brandl
components: Documentation
messages: 81615
nosy: brainsik, georg.brandl
severity: normal
status: open
title: Incorrect note about md5 in hmac module documentation
type: security
versions: Python 2.5, Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5212>
_______________________________________
From report at bugs.python.org Wed Feb 11 05:06:37 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 11 Feb 2009 04:06:37 +0000
Subject: [New-bugs-announce] [issue5213] _resolve_name in
importlib/__init__.py left an index on rindex usage
In-Reply-To: <1234325197.68.0.593462014279.issue5213@psf.upfronthosting.co.za>
Message-ID: <1234325197.68.0.593462014279.issue5213@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
I guess this happened due to the transition from rsplit to rindex.
----------
assignee: brett.cannon
components: Library (Lib)
files: _resolve_name_rindex.diff
keywords: easy, patch
messages: 81621
nosy: brett.cannon, gpolo
severity: normal
status: open
title: _resolve_name in importlib/__init__.py left an index on rindex usage
versions: Python 2.7
Added file: http://bugs.python.org/file13024/_resolve_name_rindex.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5213>
_______________________________________
From report at bugs.python.org Wed Feb 11 08:03:38 2009
From: report at bugs.python.org (Dwayne Bailey)
Date: Wed, 11 Feb 2009 07:03:38 +0000
Subject: [New-bugs-announce] [issue5214] Add KOI8-RU as a known encoding
In-Reply-To: <1234335818.61.0.321610259153.issue5214@psf.upfronthosting.co.za>
Message-ID: <1234335818.61.0.321610259153.issue5214@psf.upfronthosting.co.za>
New submission from Dwayne Bailey <dwayne+pythonbugs at translate.org.za>:
>>> u = unicode("bob", "KOI8-RU")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
LookupError: unknown encoding: KOI8-RU
This could be broadened to see that we support all encodings that are
supported by iconv.
----------
components: Unicode
messages: 81630
nosy: dwayne
severity: normal
status: open
title: Add KOI8-RU as a known encoding
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5214>
_______________________________________
From report at bugs.python.org Wed Feb 11 08:43:02 2009
From: report at bugs.python.org (mproeller)
Date: Wed, 11 Feb 2009 07:43:02 +0000
Subject: [New-bugs-announce] [issue5215] change value of local variable in
debug
In-Reply-To: <1234338182.69.0.0258607971835.issue5215@psf.upfronthosting.co.za>
Message-ID: <1234338182.69.0.0258607971835.issue5215@psf.upfronthosting.co.za>
New submission from mproeller <mproeller at googlemail.com>:
The following code produces problems:
import pdb
def func():
b = 13
pdb.set_trace()
a = b + 2
print a
func()
If I change the value of b (e.g. to 3) everything works fine
(print a => displays 5)
but if I want to change b (e.g. to 3) and display the value,
it is reset to 13
(and print a displays 15)
----------
components: None
messages: 81631
nosy: mproeller
severity: normal
status: open
title: change value of local variable in debug
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5215>
_______________________________________
From report at bugs.python.org Wed Feb 11 15:42:06 2009
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 11 Feb 2009 14:42:06 +0000
Subject: [New-bugs-announce] [issue5216]
distutils.tests.test_build_ext.BuildExtTestCase fails when
srcdir != builddir
In-Reply-To: <1234363326.79.0.666992241975.issue5216@psf.upfronthosting.co.za>
Message-ID: <1234363326.79.0.666992241975.issue5216@psf.upfronthosting.co.za>
New submission from Matthias Klose <doko at debian.org>:
these tests fail, when python is built with builddir != srcdir.
======================================================================
ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/home/packages/python/2.6/python2.6-2.6.1/Lib/distutils/tests/test_build_ext.p
y", line 23, in setUp
shutil.copy(xx_c, self.tmp_dir)
File "/home/packages/python/2.6/python2.6-2.6.1/Lib/shutil.py", line
88, in copy
copyfile(src, dst)
File "/home/packages/python/2.6/python2.6-2.6.1/Lib/shutil.py", line
52, in copyfile
fsrc = open(src, 'rb')
IOError: [Errno 2] No such file or directory:
'/home/packages/python/2.6/python2.6-2.6
.1/build-static/Modules/xxmodule.c'
======================================================================
ERROR: test_solaris_enable_shared
(distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/home/packages/python/2.6/python2.6-2.6.1/Lib/distutils/tests/test_build_ext.py",
line 23, in setUp
shutil.copy(xx_c, self.tmp_dir)
File "/home/packages/python/2.6/python2.6-2.6.1/Lib/shutil.py", line
88, in copy
copyfile(src, dst)
File "/home/packages/python/2.6/python2.6-2.6.1/Lib/shutil.py", line
52, in copyfile
fsrc = open(src, 'rb')
IOError: [Errno 2] No such file or directory:
'/home/packages/python/2.6/python2.6-2.6.1/build-static/Modules/xxmodule.c'
----------
assignee: tarek
components: Distutils, Tests
messages: 81645
nosy: doko, tarek
severity: normal
status: open
title: distutils.tests.test_build_ext.BuildExtTestCase fails when srcdir != builddir
type: compile error
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5216>
_______________________________________
From report at bugs.python.org Wed Feb 11 15:51:24 2009
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 11 Feb 2009 14:51:24 +0000
Subject: [New-bugs-announce] [issue5217] testExtractDir
(test.test_zipfile.TestWithDirectory) fails when python built
with srcdir != builddir
In-Reply-To: <1234363884.6.0.67560680288.issue5217@psf.upfronthosting.co.za>
Message-ID: <1234363884.6.0.67560680288.issue5217@psf.upfronthosting.co.za>
New submission from Matthias Klose <doko at debian.org>:
======================================================================
ERROR: testExtractDir (test.test_zipfile.TestWithDirectory)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/home/packages/python/2.6/python2.6-2.6.1/Lib/test/test_zipfile.py",
line 991, in testExtractDir
zipf = zipfile.ZipFile(findfile("zipdir.zip"))
File "/home/packages/python/2.6/python2.6-2.6.1/Lib/zipfile.py", line
680, in __init__
self.fp = open(file, modeDict[mode])
IOError: [Errno 2] No such file or directory: 'zipdir.zip'
test.test_support.findfile searches in sys.path and in the directory
where test_support.py is located. this seems to be wrong when python is
built with srcdir != builddir. should the test overwrite the optional
second argument when calling findfile?
----------
components: Tests
messages: 81646
nosy: doko
severity: normal
status: open
title: testExtractDir (test.test_zipfile.TestWithDirectory) fails when python built with srcdir != builddir
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5217>
_______________________________________
From report at bugs.python.org Wed Feb 11 20:32:43 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 11 Feb 2009 19:32:43 +0000
Subject: [New-bugs-announce] [issue5218] Check for tp_iter in
ceval:ext_do_call before overriding exception message
In-Reply-To: <1234380763.79.0.974439208897.issue5218@psf.upfronthosting.co.za>
Message-ID: <1234380763.79.0.974439208897.issue5218@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
Hi,
I find it weird that given this sample code:
def g():
yield iter(None)
list(*g())
I get this traceback:
Traceback (most recent call last):
File "a1.py", line 3, in <module>
list(*g())
TypeError: type object argument after * must be a sequence, not generator
At a minimum the exception message looks awkward to me. With the
proposed patch, the new traceback would be:
Traceback (most recent call last):
File "a1.py", line 3, in <module>
list(*g())
File "a1.py", line 2, in g
yield iter(None)
TypeError: 'NoneType' object is not iterable
----------
files: check_tpiter_before_overriding_msg.diff
keywords: patch
messages: 81657
nosy: gpolo
severity: normal
status: open
title: Check for tp_iter in ceval:ext_do_call before overriding exception message
Added file: http://bugs.python.org/file13035/check_tpiter_before_overriding_msg.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5218>
_______________________________________
From report at bugs.python.org Wed Feb 11 20:58:20 2009
From: report at bugs.python.org (John DeLuca)
Date: Wed, 11 Feb 2009 19:58:20 +0000
Subject: [New-bugs-announce] [issue5219] IDLE: slowness,
pauses enter long strings
In-Reply-To: <1234382300.54.0.847679485731.issue5219@psf.upfronthosting.co.za>
Message-ID: <1234382300.54.0.847679485731.issue5219@psf.upfronthosting.co.za>
New submission from John DeLuca <jmjdeluca at comcast.net>:
In Interpreted Mode, when enter long strings, such as ofile.write ("
this is a long string...") or print ("this is a long string..."), the
keyboard entry is delayed - sometimes for 20+ seconds. If one completes
the string (typing blindly as not text is visible) and keys the
closing ')', or one moves the entire shell window, the missing text is
dropped on the entry line and one can continue typing.
This occurs after about 25 characters of the string.
----------
components: IDLE
messages: 81662
nosy: pyJohn
severity: normal
status: open
title: IDLE: slowness, pauses enter long strings
type: performance
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5219>
_______________________________________
From report at bugs.python.org Wed Feb 11 21:36:11 2009
From: report at bugs.python.org (Joshua Bronson)
Date: Wed, 11 Feb 2009 20:36:11 +0000
Subject: [New-bugs-announce] [issue5220] os.makedirs' mode argument has bad
default value
In-Reply-To: <1234384571.02.0.296749790343.issue5220@psf.upfronthosting.co.za>
Message-ID: <1234384571.02.0.296749790343.issue5220@psf.upfronthosting.co.za>
New submission from Joshua Bronson <jabronson at gmail.com>:
os.makedirs' mode argument defaults to a hardcoded value of 511 (0777 in
octal). This forces the caller to either pass in a different hardcoded value
(commonly 0750), or to implement a workaround that calculates the expected
mode based on the process owner's umask:
umask, _ = subprocess.Popen(['sh', '-c', 'umask'],
stdout=subprocess.PIPE).communicate()
umask = int(umask, 8)
mode = 0777 ^ umask
os.makedirs(dir, mode)
Preferred behavior would be to have the mode default to the value which
takes the umask into account rather than the hardcoded value 0777, so that
directories would be created with the same permissions as e.g. files created
via open(..).
N.B. I'm guessing the above workaround won't work on Windows (please excuse
my poor Windows knowledge). All the more reason to have os.makedirs
calculate the mode properly if none is given.
----------
messages: 81666
nosy: jab
severity: normal
status: open
title: os.makedirs' mode argument has bad default value
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5220>
_______________________________________
From report at bugs.python.org Wed Feb 11 21:48:09 2009
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 11 Feb 2009 20:48:09 +0000
Subject: [New-bugs-announce] [issue5221] help related topic doesn't exist
In-Reply-To: <1234385289.6.0.0960868675321.issue5221@psf.upfronthosting.co.za>
Message-ID: <1234385289.6.0.0960868675321.issue5221@psf.upfronthosting.co.za>
New submission from David W. Lambert <lambertdw at corning.com>:
help function is not current, then again, neither is my python3.
Possibly sequencemethods[12] are eradicated.
$ p3
Python 3.0rc1+ (py3k, Nov 5 2008, 14:44:46)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> help('SEQUENCEMETHODS')
...
Related help topics: SEQUENCES, SEQUENCEMETHODS2, SPECIALMETHODS
>>> help('SEQUENCEMETHODS1')
no Python documentation found for 'SEQUENCEMETHODS1'
>>> help('SEQUENCEMETHODS2')
no Python documentation found for 'SEQUENCEMETHODS2'
----------
components: Interpreter Core
messages: 81668
nosy: LambertDW
severity: normal
status: open
title: help related topic doesn't exist
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5221>
_______________________________________
From report at bugs.python.org Thu Feb 12 05:04:10 2009
From: report at bugs.python.org (Don Rozenberg)
Date: Thu, 12 Feb 2009 04:04:10 +0000
Subject: [New-bugs-announce] [issue5222] Please include AutoScroll and
create_container in pyttk and Tkinter support
In-Reply-To: <1234411450.15.0.433002333862.issue5222@psf.upfronthosting.co.za>
Message-ID: <1234411450.15.0.433002333862.issue5222@psf.upfronthosting.co.za>
New submission from Don Rozenberg <rozen at users.sourceforge.net>:
I have just released PAGE, a Python GUI generator utilizing tk and ttk
widgets. It requires the Pyttk extension to Tkinter to support the ttk
widgets. It would be great if Pyttk were included in the Python library
if not into Tkinter. I also suggest that Pyttk be augmented to include
Guilherme Polo's functions AutoScroll and create_container as well as
ScrolledText and ScrolledTreeview. See Pyttk-samples.tar.gz.
----------
components: Tkinter
messages: 81719
nosy: rozen
severity: normal
status: open
title: Please include AutoScroll and create_container in pyttk and Tkinter support
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5222>
_______________________________________
From report at bugs.python.org Thu Feb 12 05:28:35 2009
From: report at bugs.python.org (lplatypus)
Date: Thu, 12 Feb 2009 04:28:35 +0000
Subject: [New-bugs-announce] [issue5223] infinite recursion in
PyErr_WriteUnraisable
In-Reply-To: <1234412915.77.0.527314714811.issue5223@psf.upfronthosting.co.za>
Message-ID: <1234412915.77.0.527314714811.issue5223@psf.upfronthosting.co.za>
New submission from lplatypus <luke at deller.id.au>:
Here is an example of pure Python code which can cause the interpreter
to crash.
I can reproduce the problem in 2.6.0 and 2.6.1 but not in 2.5.2.
The __getattr__ function in this example is interesting in that it
involves infinite recursion, but then the RuntimeError("maximum
recursion depth exceeded") actually causes it to behave correctly. This
is due to the behaviour of hasattr which suppresses any exception caught
when checking for attributes.
Added to the mix we have sys.stderr replaced by an instance with a write
method. The key ingredient here is that getattr(sys.stderr, "write")
invokes Python code. Near the interpreter's recursion limit this python
code can fail. This causes infinite recursion in C.
Here is a snippet of the call stack from gdb showing the recursion cycle
(using 2.6.0 source code):
#9 0x00000000004a442c in PyErr_WriteUnraisable (obj=0x64ae40)
at Python/errors.c:606
#10 0x00000000004a48f5 in PyErr_GivenExceptionMatches (err=0x64ae40,
exc=0x64ae40) at Python/errors.c:115
#11 0x0000000000466056 in slot_tp_getattr_hook (self=0x70a910,
name=0x2b4a94d47e70) at Objects/typeobject.c:5426
#12 0x0000000000449f4d in PyObject_GetAttrString (v=0x70a910,
name=0x7fff155e2fe0 <Address 0x7fff155e2fe0 out of bounds>)
at Objects/object.c:1176
#13 0x000000000042e316 in PyFile_WriteObject (v=0xd02d88, f=0x70a910,
flags=1)
at Objects/fileobject.c:2362
#14 0x000000000042e5c5 in PyFile_WriteString (s=0x51704a "Exception ",
f=0x70a910) at Objects/fileobject.c:2422
#15 0x00000000004a442c in PyErr_WriteUnraisable (obj=0x64ae40)
at Python/errors.c:606
----------
components: Interpreter Core
files: recursebug.py
messages: 81721
nosy: ldeller
severity: normal
status: open
title: infinite recursion in PyErr_WriteUnraisable
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file13044/recursebug.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5223>
_______________________________________
From report at bugs.python.org Thu Feb 12 13:01:09 2009
From: report at bugs.python.org (Ned Deily)
Date: Thu, 12 Feb 2009 12:01:09 +0000
Subject: [New-bugs-announce] [issue5224] OS X installer: "Update Shell
Profile" script is not updated
In-Reply-To: <1234440069.85.0.865907357783.issue5224@psf.upfronthosting.co.za>
Message-ID: <1234440069.85.0.865907357783.issue5224@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
ANALYSIS The script used by the Python installer to update the user's
shell script has a hard-coded version number. This script
is also installed in the "/Applications/Python n.n" directory
as "Update Shell Profile.command". The installer is not
updating the version in the command so the wrong version
of Python may be inserted into the user's shell path.
SOLUTION Ensure that the build major version is auto-updated in both.
APPLIES py3k, 3.0, trunk, 2.6
NOTE Patch is in two parts:
patch-nad0005.txt (this file) py3k, 3.0, trunk, 2.6
and one of:
patch-nad0005-py3k-30.txt py3k, 3.0
patch-nad0005-trunk.txt trunk
patch-nad0005-26.txt 2.6
----------
components: Macintosh
files: patch-nad0005.txt
messages: 81747
nosy: nad
severity: normal
status: open
title: OS X installer: "Update Shell Profile" script is not updated
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13045/patch-nad0005.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5224>
_______________________________________
From report at bugs.python.org Thu Feb 12 13:05:46 2009
From: report at bugs.python.org (Ned Deily)
Date: Thu, 12 Feb 2009 12:05:46 +0000
Subject: [New-bugs-announce] [issue5225] OS X "Update Shell Profile" may not
update $PATH if run more than once
In-Reply-To: <1234440346.58.0.444916712806.issue5225@psf.upfronthosting.co.za>
Message-ID: <1234440346.58.0.444916712806.issue5225@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
An instance of the shell script "Update Shell Profile.command"
is installed in each "/Applications/Python x.x" folder.
Clicking on the script allows the user to change the default
Python version. If the scripts are run more than once - say
first to make 3.0 the default then 2.6 the default then back
to 3.0 again - the script will fail to update the user's $PATH,
forcing users to manually edit their shell profile.
SOLUTION Ensure that $PATH is updated if there are other Python
frameworks already on its head.
(This is not the most elegant solution since it leaves the
previous versions later in the path but it is safer to
only append to the user's profile - and a backup copy
is made.)
APPLIES py3k, 3.0, trunk, 2.6
----------
components: Macintosh
files: patch-nad0020.txt
messages: 81749
nosy: nad
severity: normal
status: open
title: OS X "Update Shell Profile" may not update $PATH if run more than once
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13049/patch-nad0020.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5225>
_______________________________________
From report at bugs.python.org Thu Feb 12 13:09:38 2009
From: report at bugs.python.org (Ned Deily)
Date: Thu, 12 Feb 2009 12:09:38 +0000
Subject: [New-bugs-announce] [issue5226] OS X installer: Welcome and Readme
files are out-of-date
In-Reply-To: <1234440578.91.0.615393071826.issue5226@psf.upfronthosting.co.za>
Message-ID: <1234440578.91.0.615393071826.issue5226@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
The information in the installer Welcome and README is out-of-date.
APPLIES py3k, 3.0, trunk, 2.6
NOTE patch-nad0019-py3k-30.txt py3k, 3.0
patch-nad0019-trunk-26.txt trunk, 2.6
----------
components: Macintosh
files: patch-nad0019-py3k-30.txt
messages: 81752
nosy: nad
severity: normal
status: open
title: OS X installer: Welcome and Readme files are out-of-date
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13051/patch-nad0019-py3k-30.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5226>
_______________________________________
From report at bugs.python.org Thu Feb 12 14:00:48 2009
From: report at bugs.python.org (Rogi)
Date: Thu, 12 Feb 2009 13:00:48 +0000
Subject: [New-bugs-announce] [issue5227] Py_Main() does not return on
sys.exit()
In-Reply-To: <1234443648.41.0.597133870232.issue5227@psf.upfronthosting.co.za>
Message-ID: <1234443648.41.0.597133870232.issue5227@psf.upfronthosting.co.za>
New submission from Rogi <rogi at linuxmail.org>:
>From teh documentation:
http://docs.python.org/c-api/veryhigh.html
int Py_Main(int argc, char **argv)?
The main program for the standard interpreter. This is made
available for programs which embed Python. The argc and argv parameters
should be prepared exactly as those which are passed to a C program?s
main function. It is important to note that the argument list may be
modified (but the contents of the strings pointed to by the argument
list are not). The return value will be the integer passed to the
sys.exit() function, 1 if the interpreter exits due to an exception, or
2 if the parameter list does not represent a valid Python command line.
However, if teh user type sys.exit(whatever), Py_Main() is call exit()
instead of returning, which cause program termination before cleanup and
stuff.
----------
components: None
messages: 81760
nosy: Rogi
severity: normal
status: open
title: Py_Main() does not return on sys.exit()
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5227>
_______________________________________
From report at bugs.python.org Thu Feb 12 15:26:30 2009
From: report at bugs.python.org (ndbecker)
Date: Thu, 12 Feb 2009 14:26:30 +0000
Subject: [New-bugs-announce] [issue5228] multiprocessing not compatible with
functools.partial
In-Reply-To: <1234448790.05.0.305625917638.issue5228@psf.upfronthosting.co.za>
Message-ID: <1234448790.05.0.305625917638.issue5228@psf.upfronthosting.co.za>
New submission from ndbecker <ndbecker2 at gmail.com>:
from multiprocessing import Pool
def power (x, pwr=2):
return x**pwr
import functools
run_test = functools.partial (power, pwr=3)
if __name__ == "__main__":
pool = Pool()
cases = [3,4,5]
results = pool.map (run_test, cases)
TypeError: type 'partial' takes at least one argument
Traceback (most recent call last):
File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.1.1-py2.5-
self.run()
File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.1.1-py2.5-
self._target(*self._args, **self._kwargs)
File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.1.1-py2.5-
task = get()
File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.1.1-py2.5-
return recv()
TypeError: type 'partial' takes at least one argument
----------
components: Library (Lib)
messages: 81766
nosy: jnoller, ndbecker
severity: normal
status: open
title: multiprocessing not compatible with functools.partial
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5228>
_______________________________________
From report at bugs.python.org Thu Feb 12 20:24:05 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 12 Feb 2009 19:24:05 +0000
Subject: [New-bugs-announce] [issue5229] Documentation for super() neglects
to say what super() actually does
In-Reply-To: <1234466645.34.0.103434314376.issue5229@psf.upfronthosting.co.za>
Message-ID: <1234466645.34.0.103434314376.issue5229@psf.upfronthosting.co.za>
New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:
The documentation for super() describes the arguments that can be passed
to super(), use cases for super(), an example, and caveats about what
cannot be done with the returned object. However, the documentation
neglects to mention what super() actually *does*, except for the
circular definition in the first line: "Return a super object that acts
as a proxy to superclasses of type."
Worse still, the definition in the first line is incorrect, since it may
proxy any type in the type hierarchy (not necessarily a superclass).
I found this webpage helpful for understanding what super() actually
does: http://fuhm.net/super-harmful/
I would submit a suggested improvement to the documentation, but I do
not really understand what super() does when the second argument is
omitted or a class.
----------
assignee: georg.brandl
components: Documentation
messages: 81804
nosy: georg.brandl, stutzbach
severity: normal
status: open
title: Documentation for super() neglects to say what super() actually does
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5229>
_______________________________________
From report at bugs.python.org Thu Feb 12 22:16:28 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 12 Feb 2009 21:16:28 +0000
Subject: [New-bugs-announce] [issue5230] pydoc reports misleading failure if
target module raises an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
New submission from Jean-Paul Calderone <exarkun at divmod.com>:
If pydoc is used to try to look up the documentation for a module which
does not exist, this is reported reasonably:
exarkun at charm:~$ pydoc foobarbaz
no Python documentation found for 'foobarbaz'
exarkun at charm:~$
However, if it is used to look up the documentation for a module which
does exist but which itself imports a module which does not exist, then
the same report is made:
exarkun at charm:~$ cat > foobarbaz.py
import barbazquux
exarkun at charm:~$ pydoc foobarbaz
no Python documentation found for 'foobarbaz'
exarkun at charm:~$
This is somewhat misleading, since it suggests that there is no such
module "foobarbaz", when the problem is solved by installing the module
"barbazquux":
exarkun at charm:~$ touch barbazquux.py
exarkun at charm:~$ pydoc foobarbaz
Help on module foobarbaz:
...
exarkun at charm:~$
I'm sure the cause of this is the incautious handling of ImportError by
pydoc, resulting in the mistaken identification of the problem.
----------
messages: 81821
nosy: exarkun
severity: normal
status: open
title: pydoc reports misleading failure if target module raises an ImportError
type: behavior
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5230>
_______________________________________
From report at bugs.python.org Thu Feb 12 22:39:03 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Feb 2009 21:39:03 +0000
Subject: [New-bugs-announce] [issue5231] Change format of a memoryview
In-Reply-To: <1234474743.76.0.794318305676.issue5231@psf.upfronthosting.co.za>
Message-ID: <1234474743.76.0.794318305676.issue5231@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
Memoryview objects provide a structured view over a memory area, meaning
the length, indexing and slicing operations respect the itemsize:
>>> import array
>>> a = array.array('i', [1,2,3])
>>> m = memoryview(a)
>>> len(a)
3
>>> m.itemsize
4
>>> m.format
'i'
However, in some cases, you want the memoryview to behave as a chunk of
pure bytes regardless of the original object *and without making a
copy*. Therefore, it would be handy to be able to change the format of
the memoryview, or ask for a new memoryview with another format.
An example of use could be:
>>> a = array.array('i', [1,2,3])
>>> m = memoryview(a).with_format('B')
>>> len(a), m.itemsize, m.format
(12, 1, 'B')
----------
components: Interpreter Core
messages: 81823
nosy: gregory.p.smith, ncoghlan, pitrou, teoliphant
priority: normal
severity: normal
status: open
title: Change format of a memoryview
type: feature request
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5231>
_______________________________________
From report at bugs.python.org Thu Feb 12 23:08:26 2009
From: report at bugs.python.org (Mitchell Model)
Date: Thu, 12 Feb 2009 22:08:26 +0000
Subject: [New-bugs-announce] [issue5232] Setting font from preference dialog
in IDLE on OS X broken
In-Reply-To: <1234476506.45.0.29629224735.issue5232@psf.upfronthosting.co.za>
Message-ID: <1234476506.45.0.29629224735.issue5232@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
When setting the font in IDLE's Preferences dialog on OSX, having
started IDLE from the command line, the font is changed and the
following is printed:
Exception in Tkinter callback
Traceback (most recent call last):
File
"/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/tkinter
/__init__.py", line 1399, in __call__
return self.func(*args)
File
"/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/idlelib
/configDialog.py", line 1125, in Ok
self.Apply()
File
"/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/idlelib
/configDialog.py", line 1129, in Apply
self.DeactivateCurrentConfig()
File
"/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/idlelib
/configDialog.py", line 1107, in DeactivateCurrentConfig
winInstances = self.parent.instance_dict.keys()
File
"/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/tkinter
/__init__.py", line 1708, in __getattr__
return getattr(self.tk, attr)
AttributeError: 'tkapp' object has no attribute 'instance_dict'
----------
components: IDLE
messages: 81827
nosy: MLModel
severity: normal
status: open
title: Setting font from preference dialog in IDLE on OS X broken
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5232>
_______________________________________
From report at bugs.python.org Thu Feb 12 23:34:42 2009
From: report at bugs.python.org (Mitchell Model)
Date: Thu, 12 Feb 2009 22:34:42 +0000
Subject: [New-bugs-announce] [issue5233] Enhance 2.7 IDLE to exec
IDLESTARTUP/PYTHONSTARTUP on restart
In-Reply-To: <1234478082.8.0.463106292983.issue5233@psf.upfronthosting.co.za>
Message-ID: <1234478082.8.0.463106292983.issue5233@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
The main thing the patch does is:
modify the subprocess restart procedure so that it reloads
whatever file, if any, was loaded when IDLE first started and looked for
IDLESTARTUP then PYTHONSTARTUP environment variables.
In addition:
a -q option is added for starting IDLE on the command line to
mean "quiet", as with Emacs, e.g., to suppress loading of IDLESTARTUP or
PYTHONSTARTUP
The former effect of -s would now be the default, which is
desirable so double-clicking an IDLE icon to start it will cause the
startup file to run.
-s is changed to take an argument that is an alternate startup
file to use
I am a bit concerned about changing -s to have a different meaning.
Perhaps it's better to leave -s as an option that is simplhy superfluous
and use a different letter for the alternate startup.
----------
components: IDLE
files: PyShell-2.7.diff
keywords: patch
messages: 81831
nosy: MLModel
severity: normal
status: open
title: Enhance 2.7 IDLE to exec IDLESTARTUP/PYTHONSTARTUP on restart
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file13058/PyShell-2.7.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5233>
_______________________________________
From report at bugs.python.org Thu Feb 12 23:35:29 2009
From: report at bugs.python.org (Mitchell Model)
Date: Thu, 12 Feb 2009 22:35:29 +0000
Subject: [New-bugs-announce] [issue5234] Enhance 3.1 IDLE to exec
IDLESTARTUP/PYTHONSTARTUP on restart
In-Reply-To: <1234478129.58.0.678019243108.issue5234@psf.upfronthosting.co.za>
Message-ID: <1234478129.58.0.678019243108.issue5234@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
The main thing the patch does is:
modify the subprocess restart procedure so that it reloads
whatever file, if any, was loaded when IDLE first started and looked for
IDLESTARTUP then PYTHONSTARTUP environment variables.
In addition:
a -q option is added for starting IDLE on the command line to
mean "quiet", as with Emacs, e.g., to suppress loading of IDLESTARTUP or
PYTHONSTARTUP
The former effect of -s would now be the default, which is
desirable so double-clicking an IDLE icon to start it will cause the
startup file to run.
-s is changed to take an argument that is an alternate startup
file to use
I am a bit concerned about changing -s to have a different meaning.
Perhaps it's better to leave -s as an option that is simplhy superfluous
and use a different letter for the alternate startup.
----------
components: IDLE
files: PyShell-3.1.diff
keywords: patch
messages: 81832
nosy: MLModel
severity: normal
status: open
title: Enhance 3.1 IDLE to exec IDLESTARTUP/PYTHONSTARTUP on restart
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file13059/PyShell-3.1.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5234>
_______________________________________
From report at bugs.python.org Thu Feb 12 23:43:00 2009
From: report at bugs.python.org (Eric Swenson)
Date: Thu, 12 Feb 2009 22:43:00 +0000
Subject: [New-bugs-announce] [issue5235] distutils seems to only work with
VC++ 2008 (9.0)
In-Reply-To: <1234478580.55.0.077455747153.issue5235@psf.upfronthosting.co.za>
Message-ID: <1234478580.55.0.077455747153.issue5235@psf.upfronthosting.co.za>
New submission from Eric Swenson <eric at swenson.org>:
Building python extensions using distutils in python 2.6 with only VC++
2005 installed no longer works.
distutils appears to require VC++ 2008. The documentation on building
extensions for Python 2.6 seems to suggest that VC++ 2008, while
preferred, is not required and that it should be possible to build
extensions with VC++ 2005.
distutils appears to look for vcvarsall.bat in the VC++ 9.0 directories.
It decides to use 9.0 based on the return value of
distutils.msvc9compiler.find_build_version, which returns 9.0 --
presumably because python 2.6 was built on VC++ 9.0 (2008). Why is does
it no longer search for older versions of VC++ (like 2005)? Is this a
bug in distutils?
If VC++ 2008 (9.0) is required to build extensions, then the python 2.6
web site should make this clear.
----------
assignee: tarek
components: Distutils
messages: 81833
nosy: eswenson, tarek
severity: normal
status: open
title: distutils seems to only work with VC++ 2008 (9.0)
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5235>
_______________________________________
From report at bugs.python.org Thu Feb 12 23:50:34 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 12 Feb 2009 22:50:34 +0000
Subject: [New-bugs-announce] [issue5236] time.strptime should reject bytes
arguments on Py3
In-Reply-To: <1234479034.17.0.353291380083.issue5236@psf.upfronthosting.co.za>
Message-ID: <1234479034.17.0.353291380083.issue5236@psf.upfronthosting.co.za>
New submission from Ezio Melotti <ezio.melotti at gmail.com>:
On Python3 time.strptime(string[, format]) accepts bytes as arguments
and then fails:
>>> strptime(b"2009", "%Y")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Programs\Python30\lib\_strptime.py", line 454, in _strptime_time
return _strptime(data_string, format)[0]
File "C:\Programs\Python30\lib\_strptime.py", line 322, in _strptime
found = format_regex.match(data_string)
TypeError: can't use a string pattern on a bytes-like object
time.strftime already rejects bytes arguments:
>>> strftime(b'%Y')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: strftime() argument 1 must be str, not bytes
time.strptime should do the same and reject bytes for both the arguments
(string and format).
(With Py2.x both str and unicode args work.)
----------
components: Library (Lib), Unicode
messages: 81834
nosy: ezio.melotti
severity: normal
status: open
title: time.strptime should reject bytes arguments on Py3
type: behavior
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5236>
_______________________________________
From report at bugs.python.org Fri Feb 13 00:28:49 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 12 Feb 2009 23:28:49 +0000
Subject: [New-bugs-announce] [issue5237] Allow auto-numbered replacement
fields in str.format() strings
In-Reply-To: <1234481329.65.0.197500970463.issue5237@psf.upfronthosting.co.za>
Message-ID: <1234481329.65.0.197500970463.issue5237@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
3.x str.format() format strings denote replacement fields with braces
{}. Currently, replacement fields *must* contain "either the numeric
index of a positional argument, or the name of a keyword argument". [lib
ref / builtin types / sequence types / string methods /str.format()]
For simple sequential positional replacements, such as:
"{0} is {1} {2}".format('Numbering fields', 'an annoying', 'nuisance')
the writer has to do what computers are so good at, counting, and what
was *not* required with % interpolation, where one could write more simply
"%s is %s %s" % (('Auto-numbering', 'a convenient', 'feature')
.
Proposal: Allow field names to be omitted for all fields in a string and
then default to 0, 1, ... so one could also write
"{} is {} {}".format('Auto-numbering', 'a convenient', 'feature'
This proposal is currently all or nothing for simplicity of description
and presumed ease of implementation. The patch to the doc could then be
"If all replacement fields are left blank, then sequential indexes 0,
1, ... will be automatically inserted."
inserted after the phrase quoted above. Mixing blank and non-blank
specs would then be an error and raise an exception.
This idea was posted today on Python-ideas thread "String formatting and
named tuple". So far, +1 from Aahz, Raymond Hettinger, and Mathias
Panzenbock.
----------
components: Interpreter Core
messages: 81837
nosy: tjreedy
severity: normal
status: open
title: Allow auto-numbered replacement fields in str.format() strings
type: feature request
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5237>
_______________________________________
From report at bugs.python.org Fri Feb 13 01:34:38 2009
From: report at bugs.python.org (David Christian)
Date: Fri, 13 Feb 2009 00:34:38 +0000
Subject: [New-bugs-announce] [issue5238] ssl makefile never closes socket
In-Reply-To: <1234485278.29.0.554185864263.issue5238@psf.upfronthosting.co.za>
Message-ID: <1234485278.29.0.554185864263.issue5238@psf.upfronthosting.co.za>
New submission from David Christian <dbc at rpath.com>:
The ssl.py makefile function returns a socket._fileobject object with a
reference to itself, and also increments the makefile_refs variable.
However, the _fileobject is created with the parameter close=False,
which means that when you call _fileobject.close, it does not call close
on the ssl socket!
>>> import socket, ssl
>>> s = socket.create_connection(('www.rpath.com', 443))
>>> sslSocket = ssl.wrap_socket(s)
>>> f1 = sslSocket.makefile()
>>> f2 = sslSocket.makefile()
>>> f3 = sslSocket.makefile()
>>> sslSocket._makefile_refs
3
>>> sslSocket._sock
<socket object, fd=3, family=2, type=1, protocol=6>
>>> sslSocket.close()
>>> f1.close()
>>> f2.close()
>>> f3.close()
>>> sslSocket._makefile_refs
2
The quick fix is to add close=True on the _fileobject call in ssl.py.
Note that this close=True is _not_ needed in the socket.py makefile call
as that makefile does not do reference counting.
----------
messages: 81842
nosy: dugan
severity: normal
status: open
title: ssl makefile never closes socket
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5238>
_______________________________________
From report at bugs.python.org Fri Feb 13 02:46:35 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Feb 2009 01:46:35 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue5239=5D_time=2Estrptime=28?=
=?utf-8?b?Iu+8ku+8kO+8kO+8mSIsICIlWSIpIHJhaXNlcyBhIHZhbHVlIGVycm9y?=
In-Reply-To: <1234489595.64.0.741014433527.issue5239@psf.upfronthosting.co.za>
Message-ID: <1234489595.64.0.741014433527.issue5239@psf.upfronthosting.co.za>
New submission from Ezio Melotti <ezio.melotti at gmail.com>:
On Py3 strptime("????", "%Y") fails:
>>> strptime("????", "%Y")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python3.0/_strptime.py", line 454, in _strptime_time
return _strptime(data_string, format)[0]
File "/usr/local/lib/python3.0/_strptime.py", line 325, in _strptime
(data_string, format))
ValueError: time data '????' does not match format '%Y'
but non-ascii numbers are supported elsewhere:
>>> int("????")
2009
>>> re.match("^\d{4}$", "????").group()
'????'
The problem seems to be at the line 265 of _strptime.py:
return re_compile(self.pattern(format), IGNORECASE | ASCII)
The ASCII flag prevent the regex to work properly with '????':
>>> re.match("^\d{4}$", "????", re.ASCII)
>>>
I tried to remove the ASCII flag and it worked fine.
On Py2.x the problem is the same:
>>> strptime(u"????", "%Y")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.5/_strptime.py", line 330, in strptime
(data_string, format))
ValueError>>>
>>> int(u"????")
2009
>>> re.match("^\d{4}$", u"????")
Here there's probably to add the re.UNICODE flag at the line 265 (untested):
return re_compile(self.pattern(format), IGNORECASE | UNICODE)
in order to make it work:
>>> re.match("^\d{4}$", u"????", re.U).group()
u'\uff12\uff10\uff10\uff19'
----------
messages: 81847
nosy: ezio.melotti
severity: normal
status: open
title: time.strptime("????", "%Y") raises a value error
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5239>
_______________________________________
From report at bugs.python.org Fri Feb 13 04:16:39 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Feb 2009 03:16:39 +0000
Subject: [New-bugs-announce] [issue5240] time.strptime fails to match data
and format with Unicode whitespaces (Py3)
In-Reply-To: <1234494999.4.0.610886804768.issue5240@psf.upfronthosting.co.za>
Message-ID: <1234494999.4.0.610886804768.issue5240@psf.upfronthosting.co.za>
New submission from Ezio Melotti <ezio.melotti at gmail.com>:
On Python3, strptime raises a ValueError with some "Unicode whitespaces"
even if they are present both in the 'string' and 'format' args in the
same position:
>>> strptime("Thu\x20Feb", "%a\x20%b") # normal space, works fine
time.struct_time(tm_year=1900, tm_mon=2, tm_mday=1, tm_hour=0, tm_min=0,
tm_sec=0, tm_wday=3, tm_yday=32, tm_isdst=-1)
>>> strptime("Thu\xa0Feb", "%a\xa0%b") # no-break space, fails
ValueError: time data 'Thu\xa0Feb' does not match format '%a\xa0%b'
I wrote a small script to find out other chars where it fails (it needs
~5 minutes to run):
>>> l = []
>>> for char in map(chr, range(0xFFFF)):
... try: x = strptime('Thu{0}Feb'.format(char), '%a{0}%b'.format(char))
... except ValueError: l.append(char)
...
>>> l
['\x1c', '\x1d', '\x1e', '\x1f', '%', '\x85', '\xa0', '\u1680',
'\u2000', '\u2001', '\u2002', '\u2003', '\u2004', '\u2005', '\u2006',
'\u2007', '\u2008', '\u2009', '\u200a', '\u200b', '\u2028', '\u2029',
'\u202f', '\u205f', '\u3000']
>>> [char.strip() for char in l]
['', '', '', '', '%', '', '', '', '', '', '', '', '', '', '', '', '',
'', '', '', '', '', '', '', '']
>>> [unicodedata.category(char) for char in l]
['Cc', 'Cc', 'Cc', 'Cc', 'Po', 'Cc', 'Zs', 'Zs', 'Zs', 'Zs', 'Zs', 'Zs',
'Zs', 'Zs', 'Zs', 'Zs', 'Zs', 'Zs', 'Zs', 'Cf', 'Zl', 'Zp', 'Zs', 'Zs',
'Zs']
>>> [unicodedata.name(char, '???') for char in l]
['???', '???', '???', '???', 'PERCENT SIGN', '???', 'NO-BREAK SPACE',
'OGHAM SPACE MARK', 'EN QUAD', 'EM QUAD', 'EN SPACE', 'EM SPACE',
'THREE-PER-EM SPACE', 'FOUR-PER-EM SPACE', 'SIX-PER-EM SPACE', 'FIGURE
SPACE', 'PUNCTUATION SPACE', 'THIN SPACE', 'HAIR SPACE', 'ZERO WIDTH
SPACE', 'LINE SEPARATOR', 'PARAGRAPH SEPARATOR', 'NARROW NO-BREAK
SPACE', 'MEDIUM MATHEMATICAL SPACE', 'IDEOGRAPHIC SPACE']
All these chars (except % and some control chars) are whitespace and
they are removed by the .strip() method, so I guess that something
similar happens in strptime too.
The Unicode categories are:
"Cc" = "Other, Control"
"Zs" = "Separator, Space"
"Cf" = "Other, Format"
"Zl" = "Separator, Line"
"Zp" = "Separator, Paragraph"
Everything seems to work fine on Py2.x (tested on 2.4 and 2.6)
----------
components: Library (Lib), Unicode
messages: 81859
nosy: ezio.melotti
severity: normal
status: open
title: time.strptime fails to match data and format with Unicode whitespaces (Py3)
type: behavior
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5240>
_______________________________________
From report at bugs.python.org Fri Feb 13 04:46:03 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Feb 2009 03:46:03 +0000
Subject: [New-bugs-announce] [issue5241] Missing flags in the Regex howto
In-Reply-To: <1234496763.66.0.0120470676401.issue5241@psf.upfronthosting.co.za>
Message-ID: <1234496763.66.0.0120470676401.issue5241@psf.upfronthosting.co.za>
New submission from Ezio Melotti <ezio.melotti at gmail.com>:
The Regex howto for Py2.x doesn't include re.U/re.UNICODE
(http://docs.python.org/library/re.html#re.U):
http://docs.python.org/dev/howto/regex.html#compilation-flags (Py2.7)
http://docs.python.org/howto/regex.html#compilation-flags (Py2.6)
...
The Regex howto for Py3.x doesn't include re.A/re.ASCII
(http://docs.python.org/3.0/library/re.html#re.A):
http://docs.python.org/3.0/howto/regex.html#compilation-flags (Py3.0)
http://docs.python.org/dev/py3k/howto/regex.html#compilation-flags (Py3.1)
----------
assignee: georg.brandl
components: Documentation, Regular Expressions
messages: 81868
nosy: akuchling, ezio.melotti, georg.brandl
severity: normal
status: open
title: Missing flags in the Regex howto
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5241>
_______________________________________
From report at bugs.python.org Fri Feb 13 10:42:05 2009
From: report at bugs.python.org (Jiafei Peng)
Date: Fri, 13 Feb 2009 09:42:05 +0000
Subject: [New-bugs-announce] [issue5242] eval() function in List
Comprehension doesn't work
In-Reply-To: <1234518125.96.0.444530348539.issue5242@psf.upfronthosting.co.za>
Message-ID: <1234518125.96.0.444530348539.issue5242@psf.upfronthosting.co.za>
New submission from Jiafei Peng <jiafei.peng at iav.de>:
eval() function in List Comprehension doesn't work.
please see the under codes:
canBusType = 'CANdiag'
result = [eval('canBusType') for i in range(3)]
NameError: name 'canBusType' is not defined
It did work in Python2.5 or 2.6. The expected result is
['CANdiag', 'CANdiag', 'CANdiag'].
----------
messages: 81890
nosy: JiafeiPeng
severity: normal
status: open
title: eval() function in List Comprehension doesn't work
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5242>
_______________________________________
From report at bugs.python.org Fri Feb 13 10:57:09 2009
From: report at bugs.python.org (Patrick Gerken)
Date: Fri, 13 Feb 2009 09:57:09 +0000
Subject: [New-bugs-announce] [issue5243] Missing dependency in distutils
build
In-Reply-To: <1234519029.27.0.18013582736.issue5243@psf.upfronthosting.co.za>
Message-ID: <1234519029.27.0.18013582736.issue5243@psf.upfronthosting.co.za>
New submission from Patrick Gerken <patrick.gerken at computer.org>:
When running the command install_lib, the command build_clib is not run.
If a package contains clibs they can be dependencies for extension libs,
at least that is stated in the module docstring of build_clib.
In real life you can see it when trying to run the command install_lib
on the current reportlab2.3.
The patch provided needs do be applied in the distutils dir directly with
patch install_lib.py dependency.patch
As requested, I asked on the mailing list first, whether this really is
a bug.
http://mail.python.org/pipermail/distutils-sig/2009-February/010974.html
I am half finished writing a test case, that I'll append to this ticket
later.
----------
assignee: tarek
components: Distutils
files: dependency.patch
keywords: patch
messages: 81892
nosy: do3cc, tarek
severity: normal
status: open
title: Missing dependency in distutils build
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file13064/dependency.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5243>
_______________________________________
From report at bugs.python.org Fri Feb 13 11:23:29 2009
From: report at bugs.python.org (Jiafei Peng)
Date: Fri, 13 Feb 2009 10:23:29 +0000
Subject: [New-bugs-announce] [issue5244] Python 3.0 eval() function in List
Comprehension doesn't work
In-Reply-To: <1234520609.89.0.033915777183.issue5244@psf.upfronthosting.co.za>
Message-ID: <1234520609.89.0.033915777183.issue5244@psf.upfronthosting.co.za>
New submission from Jiafei Peng <jiafei.peng at iav.de>:
Jiafei Peng <jiafei.peng at iav.de> added the comment:
Yes
it does work properly outside listcomps.
canBusType = 'CANdiag'
result1 = eval('canBusType')
result2 = [eval('canBusType'), eval('canBusType'), eval(
'canBusType')]
result3 = [eval('canBusType') for i in range(3)]
result1 = 'CANdiag'
result2 =['CANdiag' 'CANdiag' 'CANdiag']
for result3:
NameError: name 'canBusType' is not defined
Best regards, mit freundlichen Gr??en,
Jiafei Peng
IAV GmbH
Nordhoffstr. 5
38518 Gifhorn
GERMANY
Phone: +49 5371 805-2817
Fax:+49 5371 805-1330
Ezio Melotti <report at bugs.python.org>
13.02.2009 11:04
Bitte antworten an
Python tracker <report at bugs.python.org>
An
jiafei.peng at iav.de
Kopie
Thema
[issue5242] eval() function in List Comprehension doesn't work
Ezio Melotti <ezio.melotti at gmail.com> added the comment:
I can't reproduce it either, tested with Py3 (on Linux and Windows) and
with Py2.[456], it worked fine everywhere.
Does your eval() work properly outside listcomps?
----------
messages: 81899
nosy: JiafeiPeng
severity: normal
status: open
title: Python 3.0 eval() function in List Comprehension doesn't work
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5244>
_______________________________________
From report at bugs.python.org Fri Feb 13 13:03:03 2009
From: report at bugs.python.org (Rogi)
Date: Fri, 13 Feb 2009 12:03:03 +0000
Subject: [New-bugs-announce] [issue5245] PyRun_SimpleStringFlags()
documentation
In-Reply-To: <1234526583.65.0.906444250771.issue5245@psf.upfronthosting.co.za>
Message-ID: <1234526583.65.0.906444250771.issue5245@psf.upfronthosting.co.za>
New submission from Rogi <rogi at linuxmail.org>:
>From teh docs:
http://docs.python.org/c-api/veryhigh.html
int PyRun_SimpleStringFlags(const char *command, PyCompilerFlags *flags)?
Executes the Python source code from command in the __main__ module
according to the flags argument. If __main__ does not already exist, it
is created. Returns 0 on success or -1 if an exception was raised. If
there was an error, there is no way to get the exception information.
For the meaning of flags, see below.
In case of a SystemExit it will not return. This detail, along another
issue with Py_Main() and SystemExit, made me google around for a while.
----------
assignee: georg.brandl
components: Documentation
messages: 81912
nosy: Rogi, georg.brandl
severity: normal
status: open
title: PyRun_SimpleStringFlags() documentation
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5245>
_______________________________________
From report at bugs.python.org Fri Feb 13 14:43:25 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 13 Feb 2009 13:43:25 +0000
Subject: [New-bugs-announce] [issue5246] test.test_hashlib.HashLibTestCase
fails on darwin
In-Reply-To: <1234532605.63.0.116912869658.issue5246@psf.upfronthosting.co.za>
Message-ID: <1234532605.63.0.116912869658.issue5246@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
The check_no_unicode('md5') fails under darwin (in the trunk)
(Pdb) hashlib.md5(u'spam') <--- suppose to raise a TypeError here
<md5 HASH object @ 0x6926b8>
(Pdb) hashlib.md5('spam')
<md5 HASH object @ 0x692610>
traceback :
======================================================================
FAIL: test_no_unicode (test.test_hashlib.HashLibTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/Volumes/MacDev/svn.python.org/python-trunk2/Lib/test/test_hashlib.py",
line 75, in test_no_unicode
self.check_no_unicode('md5')
File
"/Volumes/MacDev/svn.python.org/python-trunk2/Lib/test/test_hashlib.py",
line 71, in check_no_unicode
self.assertRaises(TypeError, getattr(hashlib, algorithm_name), u'spam')
AssertionError: TypeError not raised
----------
components: Library (Lib)
messages: 81925
nosy: tarek
severity: normal
status: open
title: test.test_hashlib.HashLibTestCase fails on darwin
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5246>
_______________________________________
From report at bugs.python.org Fri Feb 13 15:12:55 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Feb 2009 14:12:55 +0000
Subject: [New-bugs-announce] [issue5247] Unhelpful error message with
str.format()
In-Reply-To: <1234534375.72.0.877493256836.issue5247@psf.upfronthosting.co.za>
Message-ID: <1234534375.72.0.877493256836.issue5247@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
>>> "{0:f}".format(2.5)
'2.500000'
>>> "{0:f}".format("spam")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: Unknown conversion type f
The error message should mention the type of the argument that doesn't
support the given conversion type (e.g. "Unknown conversion type f for
object of type 'float'"). Otherwise it can be very confusing.
----------
components: Interpreter Core
messages: 81931
nosy: pitrou
priority: normal
severity: normal
status: open
title: Unhelpful error message with str.format()
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5247>
_______________________________________
From report at bugs.python.org Fri Feb 13 16:42:11 2009
From: report at bugs.python.org (Lisandro Dalcin)
Date: Fri, 13 Feb 2009 15:42:11 +0000
Subject: [New-bugs-announce] [issue5248] Adding T_SIZET to structmember.h
In-Reply-To: <1234539731.32.0.475254376781.issue5248@psf.upfronthosting.co.za>
Message-ID: <1234539731.32.0.475254376781.issue5248@psf.upfronthosting.co.za>
New submission from Lisandro Dalcin <dalcinl at gmail.com>:
structmember.h lacks a 'T_SIZET' define in order to properly support
struct fields of type 'size_t' within PyMemberDef.
If this feature request is accepted, I can provide the patches.
For 2.7, It would be nice to do:
#define T_SIZET 20 /* size_t */
However, this value is already used in 3.0 for 'T_NONE'. Perhaps T_NONE
should be backported to 2.7?
To avoid future merge conflicts, I would vote for this definition:
#define T_SIZET 21 /* size_t */
----------
components: Interpreter Core
messages: 81942
nosy: dalcinl, marketdickinson
severity: normal
status: open
title: Adding T_SIZET to structmember.h
type: feature request
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5248>
_______________________________________
From report at bugs.python.org Fri Feb 13 17:24:08 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 13 Feb 2009 16:24:08 +0000
Subject: [New-bugs-announce] [issue5249] Fix strftime on windows.
In-Reply-To: <1234542248.51.0.455809582678.issue5249@psf.upfronthosting.co.za>
Message-ID: <1234542248.51.0.455809582678.issue5249@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
On windows, format string should be encoded as mbcs. Otherwise, result
of strftime would be broken. Here is the patch.
----------
components: Extension Modules, Windows
files: fix_strftime_on_windows.patch
keywords: patch
messages: 81946
nosy: ocean-city
severity: normal
stage: commit review
status: open
title: Fix strftime on windows.
type: behavior
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13072/fix_strftime_on_windows.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5249>
_______________________________________
From report at bugs.python.org Fri Feb 13 19:03:39 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Feb 2009 18:03:39 +0000
Subject: [New-bugs-announce] [issue5250] Document __instancecheck__ and
__subclasscheck__
In-Reply-To: <1234548219.84.0.437841096999.issue5250@psf.upfronthosting.co.za>
Message-ID: <1234548219.84.0.437841096999.issue5250@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
http://www.python.org/dev/peps/pep-3119/#overloading-isinstance-and-issubclass
(GvR and Talin)
"The primary mechanism proposed here is to allow overloading the
built-in functions isinstance() and issubclass(). The overloading works
as follows: The call isinstance(x, C) first checks whether
C.__instancecheck__ exists, and if so, calls C.__instancecheck__(x)
instead of its normal implementation. Similarly, the call issubclass(D,
C) first checks whether C.__subclasscheck__ exists, and if so, calls
C.__subclasscheck__(D) instead of its normal implementation."
These two new special methods are not documented (for 3.x at least. A
post on python-list today verifies that at least .__instancecheck__ was
implemented (version not specified). I assume .__subclasscheck__ was
also. This issue perhaps applies to 2.6/2.7 also.
I suggest either adding "Customizing instance and subclass checks" after
"Customizing class creation" or add to that section and rename it to
"Customizing class creation and checks" since the needed addition seems
too small for its own section. Something like
The result of isinstance(object, class) can be modified by giving the
*class* a .__instancecheck__(object) method. The result of
issubclass(sub,super) can be modified by giving the *superclass* a
.__subclasscheck__(sub) method.
----------
assignee: georg.brandl
components: Documentation
messages: 81956
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Document __instancecheck__ and __subclasscheck__
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5250>
_______________________________________
From report at bugs.python.org Fri Feb 13 19:09:30 2009
From: report at bugs.python.org (James William Pye)
Date: Fri, 13 Feb 2009 18:09:30 +0000
Subject: [New-bugs-announce] [issue5251] contextlib.nested inconsistent with,
well, nested with statements due exceptions raised in __enter__
In-Reply-To: <1234548570.86.0.145574171135.issue5251@psf.upfronthosting.co.za>
Message-ID: <1234548570.86.0.145574171135.issue5251@psf.upfronthosting.co.za>
New submission from James William Pye <python at jwp.name>:
Basically, nested() doesn't seem to be consistent with explicitly nested
with-statements when an exception is thrown in a CM's __enter__.
Consider a pair of nested CMs, the inner __enter__ raises an exception
trapped by the outer. In the situation of explicitly nested
with-statements, the inner's block will not be ran as an exception was
raised prior to the block. The outer traps the exception and code
continues to flow after the outer's block because the exception was
*not* raised.
Currently, if contextlib.nested() is used in such a situation, it blows
up with a RuntimeError("generator didn't yield").
See the attached file for a set of naive variations and their resulting
exceptions or lack thereof in the situation of explicitly nested CMs.
Despite the RuntimeError raised by nested(), I'm not sure it's
*currently* possible for an implementation of nested() to be *totally*
consistent with explicitly nested with-statements. It would seem that an
additional facility(AbortBlock exception?) would be needed to
communicate that the block should not actually be ran, and that no
exception should be raised as it was consumed by an "outer" CM.
If this is considered to be the intended behavior, I would think the
doc-string on contextlib.nested should be updated to document the
inconsistency as it currently states that nested() and nested with
statements are equivalent. Based on the results of the attached file in
Python 3.0, they are clearly not.
Cheers folks; lovin' CMs. And, of course, apologies if this has already
been discussed. :P
----------
components: None
files: nested_issue.py
messages: 81957
nosy: jwp
severity: normal
status: open
title: contextlib.nested inconsistent with, well, nested with statements due exceptions raised in __enter__
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13075/nested_issue.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5251>
_______________________________________
From report at bugs.python.org Fri Feb 13 19:27:06 2009
From: report at bugs.python.org (Stephen J. Turnbull)
Date: Fri, 13 Feb 2009 18:27:06 +0000
Subject: [New-bugs-announce] [issue5252] 2to3 should detect and delete
import of removed statvfs module
In-Reply-To: <1234549626.49.0.319241033357.issue5252@psf.upfronthosting.co.za>
Message-ID: <1234549626.49.0.319241033357.issue5252@psf.upfronthosting.co.za>
New submission from Stephen J. Turnbull <stephen at xemacs.org>:
It should also try to convert stuff like
from statvfs import F_BAVAIL, F_FRSIZE
status = os.statvfs(directory)
available = status[F_BAVAIL]/((1024*1024)/status[F_FRSIZE]
----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 81959
nosy: sjt
severity: normal
status: open
title: 2to3 should detect and delete import of removed statvfs module
type: feature request
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5252>
_______________________________________
From report at bugs.python.org Fri Feb 13 19:55:00 2009
From: report at bugs.python.org (Mary Stern)
Date: Fri, 13 Feb 2009 18:55:00 +0000
Subject: [New-bugs-announce] [issue5253] os.environ.get() doesn't handle
default value
In-Reply-To: <1234551300.69.0.752467323752.issue5253@psf.upfronthosting.co.za>
Message-ID: <1234551300.69.0.752467323752.issue5253@psf.upfronthosting.co.za>
New submission from Mary Stern <marystern at yahoo.com>:
os.environ.get('ENV_VAR, 'mydefault')
returns '' rather than 'mydefault' if not set.
It would be nice if this standard dict-style behavior was supported.
----------
messages: 81963
nosy: marystern
severity: normal
status: open
title: os.environ.get() doesn't handle default value
type: feature request
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5253>
_______________________________________
From report at bugs.python.org Fri Feb 13 22:18:25 2009
From: report at bugs.python.org (Adam Vandenberg)
Date: Fri, 13 Feb 2009 21:18:25 +0000
Subject: [New-bugs-announce] [issue5254] Formatting error in "findertools"
header
In-Reply-To: <1234559905.46.0.79171819004.issue5254@psf.upfronthosting.co.za>
Message-ID: <1234559905.46.0.79171819004.issue5254@psf.upfronthosting.co.za>
New submission from Adam Vandenberg <flangy at gmail.com>:
There is a formatting error in the "findertools" header:
http://docs.python.org/library/macostools.html#module-findertools
"The finder's Apple Events interface" as rendered uses the
wrong-direction single quote.
----------
assignee: georg.brandl
components: Documentation
messages: 81972
nosy: adamvan, georg.brandl
severity: normal
status: open
title: Formatting error in "findertools" header
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5254>
_______________________________________
From report at bugs.python.org Sat Feb 14 00:43:48 2009
From: report at bugs.python.org (scudeete)
Date: Fri, 13 Feb 2009 23:43:48 +0000
Subject: [New-bugs-announce] [issue5255] unicode support with os.readlink()
In-Reply-To: <1234568628.13.0.435223332986.issue5255@psf.upfronthosting.co.za>
Message-ID: <1234568628.13.0.435223332986.issue5255@psf.upfronthosting.co.za>
New submission from scudeete <scudette at gmail.com>:
Python 2.5.2 has a bug in os.readlink() accepting unicode objects.
Although it appears that other os functions can handle unicode fine:
os.listdir("???")
Works fine (in that it raises an OS.Error if the dir is not there), but:
os.readlink("???")
Raises:
<type 'exceptions.UnicodeEncodeError'>: 'ascii' codec can't encode
characters in position 0-9: ordinal not in range(128)
----------
components: Library (Lib)
messages: 81977
nosy: scudette
severity: normal
status: open
title: unicode support with os.readlink()
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5255>
_______________________________________
From report at bugs.python.org Sat Feb 14 01:04:20 2009
From: report at bugs.python.org (Armandas)
Date: Sat, 14 Feb 2009 00:04:20 +0000
Subject: [New-bugs-announce] [issue5256] rlcompleter adds builtins when
custom dict is used
In-Reply-To: <1234569860.16.0.0783224890959.issue5256@psf.upfronthosting.co.za>
Message-ID: <1234569860.16.0.0783224890959.issue5256@psf.upfronthosting.co.za>
New submission from Armandas <jarusauskas at gmail.com>:
When custom dictionary is used to create a completer, rlcompleter still
uses __builtins__.__dict__ to search for completions (rlcompleter.py,
global_matches()):
for nspace in [builtins.__dict__, self.namespace]:
...
This behaviour may sometimes be unwanted. It would be nice to have an
option, which when set would tell completer to only use provided dictionary.
----------
components: None
messages: 81979
nosy: armandas
severity: normal
status: open
title: rlcompleter adds builtins when custom dict is used
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5256>
_______________________________________
From report at bugs.python.org Sat Feb 14 12:20:32 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 14 Feb 2009 11:20:32 +0000
Subject: [New-bugs-announce] [issue5257] test_zipfle and test_distutils
write in the test directories
In-Reply-To: <1234610432.5.0.115375457394.issue5257@psf.upfronthosting.co.za>
Message-ID: <1234610432.5.0.115375457394.issue5257@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
Those tests are writing in the test directories (Lib/test and
Lib/distutils/tests).
The tests will be changed to use temporary directory;
----------
assignee: tarek
components: Distutils, Library (Lib)
messages: 82008
nosy: tarek
priority: high
severity: normal
status: open
title: test_zipfle and test_distutils write in the test directories
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5257>
_______________________________________
From report at bugs.python.org Sat Feb 14 13:36:04 2009
From: report at bugs.python.org (James Wheare)
Date: Sat, 14 Feb 2009 12:36:04 +0000
Subject: [New-bugs-announce] [issue5258] addpackage in site.py fails hard on
badly formed .pth files
In-Reply-To: <1234614964.94.0.514404315884.issue5258@psf.upfronthosting.co.za>
Message-ID: <1234614964.94.0.514404315884.issue5258@psf.upfronthosting.co.za>
New submission from James Wheare <james at wheare.org>:
As described here: http://james.wheare.org/notes/2009/02/import-site-
failed-use-v-for-traceback.php
The addpackage function will result in a TypeError being raised from os.path.exists(dir) -> from os.stat(path) if the contents of an
inspected .pth file contain binary data.
This can happen in OS X network environments where ._ AppleDouble files
are created to store resource forks and file metadata.
As this function is run whenever the interpreter is initialised, Python
should be robust enough to ignore invalid data in these files, either by
catching the TypeError in os.path.exists, or by detecting them at a
higher level, but should be careful of false positives.
Another alternative is to raise a different exception and use it to
display more helpful debugging info for those not familiar with pdb.
----------
messages: 82032
nosy: jwheare
severity: normal
status: open
title: addpackage in site.py fails hard on badly formed .pth files
type: behavior
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5258>
_______________________________________
From report at bugs.python.org Sat Feb 14 15:19:18 2009
From: report at bugs.python.org (Musashi Tamura)
Date: Sat, 14 Feb 2009 14:19:18 +0000
Subject: [New-bugs-announce] [issue5259] smtplib is broken in Python3
In-Reply-To: <1234621158.53.0.153253851523.issue5259@psf.upfronthosting.co.za>
Message-ID: <1234621158.53.0.153253851523.issue5259@psf.upfronthosting.co.za>
New submission from Musashi Tamura <yuri.musashi.miwa.tamura at gmail.com>:
Issue #<3921> may be the same problem.
Sending Gmail by smtplib fails on Python 3.0 and 3.0.1.
It seems to be exist two problems in encode_plain function in smtplib.py:
* parameter of encode_base64 must be bytes, not str,
* by default, encode_base64 adds extra newline.
The following is an example of patch.
# original version
def encode_plain(user, password):
return encode_base64("\0%s\0%s" % (user, password))
# fixed version. Note that "eol=''" is given in Python 2.6's smtplib.
def encode_plain(user, password):
s = "\0%s\0%s" % (user, password)
return encode_base64(s.encode('ascii'), eol='')
----------
components: Library (Lib)
messages: 82064
nosy: miwa
severity: normal
status: open
title: smtplib is broken in Python3
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5259>
_______________________________________
From report at bugs.python.org Sat Feb 14 18:44:50 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 14 Feb 2009 17:44:50 +0000
Subject: [New-bugs-announce] [issue5260] longobject.c: minor fixes,
cleanups and optimizations
In-Reply-To: <1234633490.48.0.538074848497.issue5260@psf.upfronthosting.co.za>
Message-ID: <1234633490.48.0.538074848497.issue5260@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
Here are various minor portability and standards-compliance fixes,
optimizations and cleanups for the trunk version of
Objects/longobject.c. Most of these also apply to py3k.
I'll admit to an ulterior motive here: the aim is to extract all
the trivial, non-behaviour-changing pieces of the 30-bit longdigit
patch (issue 4258), in order to make that patch easier to review.
A good few of the changes here are designed to weaken the assumptions
about the relative sizes of digit, int and long.
Detailed contents of this patch:
- make longs smaller by being more careful about tp_basicsize: it's
defined as offsetof(PyLongObject, ob_digit) instead of the previous
sizeof(PyLongObject) - sizeof(digit). On average, this saves 2
bytes per long on 32-bit platforms and 6 bytes per
long on 64-bit platforms. This is similar to the fix that's already
in py3k, but more portable since it doesn't make assumptions about
the amount of padding between the PyVarObject head and the long
digits.
- add overflow check in _PyLong_New
- replace double cast (double -> long -> digit) in PyLong_FromDouble
with a single double -> digit cast.
- int -> Py_ssize_t fixes in _PyLong_FromByteArray.
- fix bogus overflow check in _PyLong_FromByteArray.
- inline muladd1 into mul1
- simplify long_hash (without changing its semantics in any way):
there's no need for the masking when rotating x; everything in
sight is unsigned and unambiguous.
- make PyLong_MASK unsigned (of type digit); this is safer, since
it's used in many bitwise operations.
- remove wdigit from Include/longintrepr.h; it's no longer used
- remove some unnecessary forward declarations
- add a few extra casts to silence compiler warnings from gcc -Wextra
----------
assignee: marketdickinson
components: Interpreter Core
files: trunk_long_cleanup.patch
keywords: patch
messages: 82095
nosy: marketdickinson
priority: normal
severity: normal
stage: patch review
status: open
title: longobject.c: minor fixes, cleanups and optimizations
type: behavior
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file13086/trunk_long_cleanup.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5260>
_______________________________________
From report at bugs.python.org Sat Feb 14 19:52:14 2009
From: report at bugs.python.org (Stephen Lynch)
Date: Sat, 14 Feb 2009 18:52:14 +0000
Subject: [New-bugs-announce] [issue5261] with lock fails on multiprocessing
In-Reply-To: <1234637534.63.0.0578864534082.issue5261@psf.upfronthosting.co.za>
Message-ID: <1234637534.63.0.0578864534082.issue5261@psf.upfronthosting.co.za>
New submission from Stephen Lynch <stepheng.lynch at gmail.com>:
the following code gives a system error under python 2.6.1
import multiprocessing
with multiprocessing.Lock(): pass
SystemError: ..\Python\getargs.c:1413: bad argument to internal function
----------
components: Library (Lib)
messages: 82106
nosy: stepheng.lynch
severity: normal
status: open
title: with lock fails on multiprocessing
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5261>
_______________________________________
From report at bugs.python.org Sat Feb 14 20:08:25 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 14 Feb 2009 19:08:25 +0000
Subject: [New-bugs-announce] [issue5262] PythonLauncher considered harmfull
In-Reply-To: <1234638505.38.0.029039550018.issue5262@psf.upfronthosting.co.za>
Message-ID: <1234638505.38.0.029039550018.issue5262@psf.upfronthosting.co.za>
New submission from Ronald Oussoren <ronaldoussoren at mac.com>:
The Mac port of Python contains a binary named "PythonLauncher" which
can be used as the association of ".py" and ".pyw" files. This program
will launch the script (either in a Terminal window or without a
window).
In hindsight adding this tool was not a good idea: this makes it way to
easy to accidently launch python script downloaded from the Internet.
Removing PythonLauncher would still allow running the scripts through
IDLE (which also has an association to ".py" and ".pyw" files in it
Info.plist).
In my experience most ".py" files are modules instead of standalone
scripts, opening the file in an editor would therefore be a better
action in the majority of use-cases.
----------
assignee: ronaldoussoren
components: Macintosh
messages: 82108
nosy: ronaldoussoren
severity: normal
status: open
title: PythonLauncher considered harmfull
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5262>
_______________________________________
From report at bugs.python.org Sat Feb 14 22:33:35 2009
From: report at bugs.python.org (Lovely Grace)
Date: Sat, 14 Feb 2009 21:33:35 +0000
Subject: [New-bugs-announce] [issue5263] Error printing UTF-8 decoded text
In-Reply-To: <1234647215.76.0.528170813842.issue5263@psf.upfronthosting.co.za>
Message-ID: <1234647215.76.0.528170813842.issue5263@psf.upfronthosting.co.za>
New submission from Lovely Grace <lovelygrace26 at hotmail.com>:
The following code fails on the print command (see error message bellow
the code). I use windows and run the code under command prompt env.
import urllib.request
if __name__ == "__main__":
sock =
urllib.request.urlopen("http://docs.python.org/3.0/library/html.parser.html#html.parser.HTMLParser.handle_startendtag")
htmlSource = sock.read()
sock.close()
htmlSource = htmlSource.decode("utf-8", "strict")
print(htmlSource)
Error message:
Traceback (most recent call last):
File "parsehomeless.py", line 68, in <module>
print(htmlSource[0:281])
File "C:\Python30\lib\io.py", line 1494, in write
b = encoder.encode(s)
File "C:\Python30\lib\encodings\cp862.py", line 19, in encode
return codecs.charmap_encode(input,self.errors,encoding_map)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\u2014' in
position 280: character maps to <undefined>
----------
components: Interpreter Core
messages: 82120
nosy: grace
severity: normal
status: open
title: Error printing UTF-8 decoded text
type: crash
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5263>
_______________________________________
From report at bugs.python.org Sat Feb 14 23:31:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 14 Feb 2009 22:31:51 +0000
Subject: [New-bugs-announce] [issue5264] StringIO failure when reading a
chunk of text without newlines
In-Reply-To: <1234650711.9.0.239815315496.issue5264@psf.upfronthosting.co.za>
Message-ID: <1234650711.9.0.239815315496.issue5264@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
>>> f = io.StringIO("a\r\n", newline=None)
>>> f.read(1)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/antoine/py3k/__svn__/Lib/io.py", line 2007, in read
res = self._decode_newlines(self._read(n), True)
File "/home/antoine/py3k/__svn__/Lib/io.py", line 1953, in
_decode_newlines
return output
UnboundLocalError: local variable 'output' referenced before assignment
----------
components: Library (Lib)
messages: 82131
nosy: alexandre.vassalotti, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: StringIO failure when reading a chunk of text without newlines
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5264>
_______________________________________
From report at bugs.python.org Sat Feb 14 23:36:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 14 Feb 2009 22:36:18 +0000
Subject: [New-bugs-announce] [issue5265] StringIO can duplicate newlines in
universal newlines mode
In-Reply-To: <1234650978.85.0.656093494146.issue5265@psf.upfronthosting.co.za>
Message-ID: <1234650978.85.0.656093494146.issue5265@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
This one is a bit strange:
>>> f = io.StringIO("a\r\nb\r\n", newline=None)
>>> f.read()
'a\nb\n'
>>> f = io.StringIO("a\r\nb\r\n", newline=None)
>>> f.read(6)
'a\nb\n'
>>> f = io.StringIO("a\r\nb\r\n", newline=None)
>>> f.read(5)
'a\n\nb\n'
----------
messages: 82132
nosy: alexandre.vassalotti, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: StringIO can duplicate newlines in universal newlines mode
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5265>
_______________________________________
From report at bugs.python.org Sat Feb 14 23:50:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 14 Feb 2009 22:50:08 +0000
Subject: [New-bugs-announce] [issue5266] StringIO.read(n) does not enforce
requested size in newline mode
In-Reply-To: <1234651808.93.0.485366406394.issue5266@psf.upfronthosting.co.za>
Message-ID: <1234651808.93.0.485366406394.issue5266@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
Or, more precisely, it returns less than the requested number of
characters because characters are counted before translating newlines:
>>> f = io.StringIO("a\r\nb\r\n", newline=None)
>>> f.read(3)
'a\n'
TextIOWrapper gets it right:
>>> g = io.TextIOWrapper(io.BytesIO(b"a\r\nb\r\n"), newline=None)
>>> g.read(3)
'a\nb'
----------
components: Library (Lib)
messages: 82134
nosy: alexandre.vassalotti, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: StringIO.read(n) does not enforce requested size in newline mode
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5266>
_______________________________________
From report at bugs.python.org Sun Feb 15 01:33:12 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sun, 15 Feb 2009 00:33:12 +0000
Subject: [New-bugs-announce] [issue5267] Subversion problem with
PythonLauncher after building 3.0 or 3.1 on Mac
In-Reply-To: <1234657992.73.0.432074420703.issue5267@psf.upfronthosting.co.za>
Message-ID: <1234657992.73.0.432074420703.issue5267@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
After checking out 3.0 and 3.1 and building them on a Mac (Leopard,
Intel) when I subsequently try to do "svn update" I get the error:
svn: Directory 'Mac/PythonLauncher/Python Launcher.app/.svn' containing
working copy admin area is missing
As a result, "svn update" fails. Removing PythonLauncher.app fixes.
This problem does NOT happen in Python2.6 even though there's no
PythonLauncher.app/.svn there either. I don't know enough about
subversion to disentangle this.
And in fact there is a .svn directory in Mac/IDLE/Idle.app but none in
PythonLauncher.app. "make clean" doesn't remove the .app's; perhaps it
should.
[Am I mistaken in building my subversion directories?]
----------
components: Build
messages: 82135
nosy: MLModel
severity: normal
status: open
title: Subversion problem with PythonLauncher after building 3.0 or 3.1 on Mac
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5267>
_______________________________________
From report at bugs.python.org Sun Feb 15 02:08:38 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sun, 15 Feb 2009 01:08:38 +0000
Subject: [New-bugs-announce] [issue5268] VMSError not documented in
Doc/library/exceptions.rst
In-Reply-To: <1234660118.75.0.126976795951.issue5268@psf.upfronthosting.co.za>
Message-ID: <1234660118.75.0.126976795951.issue5268@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
Lib/test/exception_hierarchy.txt shows VMSError but it is not mentioned in
Doc/library/exceptions.rst
----------
assignee: georg.brandl
components: Documentation
messages: 82137
nosy: MLModel, georg.brandl
severity: normal
status: open
title: VMSError not documented in Doc/library/exceptions.rst
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5268>
_______________________________________
From report at bugs.python.org Sun Feb 15 09:51:14 2009
From: report at bugs.python.org (Ned Deily)
Date: Sun, 15 Feb 2009 08:51:14 +0000
Subject: [New-bugs-announce] [issue5269] OS X Installer: add options to
specify universal build type and deployment target
In-Reply-To: <1234687874.34.0.561795974463.issue5269@psf.upfronthosting.co.za>
Message-ID: <1234687874.34.0.561795974463.issue5269@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
The current OS X installer builder has no provision for changing the
architecture type or deployment target to allow different installer
types, such as 4-way universal, to be built. The attached patch
allows for builds on systems other than 10.4 and adds two new
arguments to build-installer.py:
--dep-target=10.n, [default 10.3]
--universal-archs=x
where x =
'32-bit' -> 2-way 32-bit (intel|ppc) [default]
'64-bit' -> 2-way 64-bit (intel|ppc)
'all' -> 4-way universal
The default values are the current hard-coded ones.
----------
components: Macintosh
files: patch-nad0006.txt
messages: 82142
nosy: nad
severity: normal
status: open
title: OS X Installer: add options to specify universal build type and deployment target
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13093/patch-nad0006.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5269>
_______________________________________
From report at bugs.python.org Sun Feb 15 09:57:54 2009
From: report at bugs.python.org (Ned Deily)
Date: Sun, 15 Feb 2009 08:57:54 +0000
Subject: [New-bugs-announce] [issue5270] OS X installer: faulty Python.app
bundle inside of framework
In-Reply-To: <1234688274.05.0.10424234912.issue5270@psf.upfronthosting.co.za>
Message-ID: <1234688274.05.0.10424234912.issue5270@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
The Finder shows no version number and displays a generic icon.
ANALYSIS Previous changes to Mac/Makefile removed configure processing
which used to edit Info.plist.in into Info.plist.
SOLUTION Add tailoring to Mac/Makefile.
APPLIES py3k, 3.0, trunk, 2.6
----------
components: Macintosh
files: patch-nad0004.txt
messages: 82143
nosy: nad
severity: normal
status: open
title: OS X installer: faulty Python.app bundle inside of framework
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13094/patch-nad0004.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5270>
_______________________________________
From report at bugs.python.org Sun Feb 15 10:05:10 2009
From: report at bugs.python.org (Ned Deily)
Date: Sun, 15 Feb 2009 09:05:10 +0000
Subject: [New-bugs-announce] [issue5271] OS X installer: build can fail on
import checks
In-Reply-To: <1234688710.61.0.976389854663.issue5271@psf.upfronthosting.co.za>
Message-ID: <1234688710.61.0.976389854663.issue5271@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
ANALYSIS The OS X installer build include several third-party libraries
which will be installed as shared libs in the framework.
During the build, setup.py tries to import built extensions to
catch import problems. Currently, the import check attempts to
load the shared libs from their installed location. If the
version being built is not installed on the build machine, the
build fails; if present, the imports are checked against the
old libraries. Problems seen with _curses_panel on all builds
and, for 4-way universal, _curses and readlines.
SOLUTION add the newly built extra libs into the DYLD_LIBRARY_PATH of
the interpreter during the build phase
APPLIES 2.6, 2.7, 3.0, 3.1
----------
components: Build, Macintosh
files: patch-nad0011.txt
messages: 82144
nosy: nad
severity: normal
status: open
title: OS X installer: build can fail on import checks
type: compile error
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13095/patch-nad0011.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5271>
_______________________________________
From report at bugs.python.org Sun Feb 15 10:08:34 2009
From: report at bugs.python.org (Ned Deily)
Date: Sun, 15 Feb 2009 09:08:34 +0000
Subject: [New-bugs-announce] [issue5272] OS X installer: fix makefile target
changed for 3.x
In-Reply-To: <1234688914.68.0.888662727097.issue5272@psf.upfronthosting.co.za>
Message-ID: <1234688914.68.0.888662727097.issue5272@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
2.x "make install" is equivalent to 3.x "make fullinstall"
Update Mac/BuildScript/build-installer.py accordingly.
This prevents spurious warning messages in the installer build.
----------
components: Build, Macintosh
files: patch-nad0003-py3k-30.txt
messages: 82145
nosy: nad
severity: normal
status: open
title: OS X installer: fix makefile target changed for 3.x
type: crash
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13096/patch-nad0003-py3k-30.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5272>
_______________________________________
From report at bugs.python.org Sun Feb 15 12:26:13 2009
From: report at bugs.python.org (Musashi Tamura)
Date: Sun, 15 Feb 2009 11:26:13 +0000
Subject: [New-bugs-announce] [issue5273] 3.0.1 crashes in unicode path
In-Reply-To: <1234697173.89.0.607307713692.issue5273@psf.upfronthosting.co.za>
Message-ID: <1234697173.89.0.607307713692.issue5273@psf.upfronthosting.co.za>
New submission from Musashi Tamura <yuri.musashi.miwa.tamura at gmail.com>:
In unicode path Python 3.0.1 crashes when importing compiled module.
This does not happen on Python 3.0, new in 3.0.1.
Detailed Situation:
OS: win2000
current pathname contains Japanese characters.
./a.py contains only a statement "import b".
./b.py is empty.
> python a.py
(nothing is happen but b.pyc is created)
> python a.py
Traceback (most recent call last):
File "a.py", line 1, in <module>
import b
UnicodeDecodeError: 'utf8' codec can't decode byte 0x82 in position 3:
unexpected code byte
----------
components: Windows
messages: 82150
nosy: miwa
severity: normal
status: open
title: 3.0.1 crashes in unicode path
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5273>
_______________________________________
From report at bugs.python.org Sun Feb 15 23:49:51 2009
From: report at bugs.python.org (Mark Florisson)
Date: Sun, 15 Feb 2009 22:49:51 +0000
Subject: [New-bugs-announce] [issue5275] BaseCookie.load doesn't create
Morsel objects for mappings
In-Reply-To: <1234738191.23.0.342275234869.issue5275@psf.upfronthosting.co.za>
Message-ID: <1234738191.23.0.342275234869.issue5275@psf.upfronthosting.co.za>
New submission from Mark Florisson <markflorisson88 at gmail.com>:
The load method, which is also called from the initializer if input is
provided, doesn't create Morsel objects for things other than strs,
because it calls self.update(rawdata), which does not invoke the custom
__setitem__.
The documentation states that when rawdata is not a string, it must be a
dictionary and providing that will be equivalent to doing
for k, v in rawdata.items():
cookie[k] = v
So that is what it should do :)
----------
messages: 82177
nosy: eggy
severity: normal
status: open
title: BaseCookie.load doesn't create Morsel objects for mappings
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5275>
_______________________________________
From report at bugs.python.org Mon Feb 16 00:41:57 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sun, 15 Feb 2009 23:41:57 +0000
Subject: [New-bugs-announce] [issue5276] IDLE startup file .Idle.py not
documented
In-Reply-To: <1234741317.8.0.0064983097243.issue5276@psf.upfronthosting.co.za>
Message-ID: <1234741317.8.0.0064983097243.issue5276@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
The following behavior should be documented but it is not:
If the user has a .Idle.py file IDLE will run it when it starts up. This
is independent of running IDLESTARTUP or PYTHONSTARTUP when the -s
switch is given. It is run by Tk.readprofile as called from Tk.__init__.
The "Idle" comes from the name passed to TK() when PyShell.py creates
its Tk root. In fact, not only is it independent, but it works
differently: any imports done in .Idle.py go into Tk's name space,
whereas IDLESTARTUP/PYTHONSTARTUP is exec'd and imports go into the
interpreter's namespace.
Note that the 'I' in '.Idle.py' is really uppercase, which will matter
on case-sensitive platforms.
----------
assignee: georg.brandl
components: Documentation, IDLE
messages: 82186
nosy: MLModel, georg.brandl
severity: normal
status: open
title: IDLE startup file .Idle.py not documented
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5276>
_______________________________________
From report at bugs.python.org Mon Feb 16 05:35:15 2009
From: report at bugs.python.org (Mark Sapiro)
Date: Mon, 16 Feb 2009 04:35:15 +0000
Subject: [New-bugs-announce] [issue5277] email message.get_params() and
related methods sometimes fail.
In-Reply-To: <1234758915.75.0.150242965655.issue5277@psf.upfronthosting.co.za>
Message-ID: <1234758915.75.0.150242965655.issue5277@psf.upfronthosting.co.za>
New submission from Mark Sapiro <mark at msapiro.net>:
The message method get_params() and the related get_param() and
get_filename() do not properly decode an RFC 2231 encoded parameter such
as the following:
Content-Disposition: inline;
filename*0="Re: [Mailman-Users] Messages shunted with \"TypeError: ";
filename*1="decodingUnicode is not supported\".eml"
This is because the message helper function _parseparams() mistakenly
thinks the second semicolon is inside a quoted string because it counts
the quoted (escaped) quote and sees an odd number.
The attached patch will fix this.
----------
components: Library (Lib)
files: message.patch
keywords: patch
messages: 82215
nosy: barry, msapiro
severity: normal
status: open
title: email message.get_params() and related methods sometimes fail.
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13105/message.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5277>
_______________________________________
From report at bugs.python.org Mon Feb 16 11:17:55 2009
From: report at bugs.python.org (Senthil)
Date: Mon, 16 Feb 2009 10:17:55 +0000
Subject: [New-bugs-announce] [issue5278] optparse documentation example
In-Reply-To: <1234779475.55.0.947626870782.issue5278@psf.upfronthosting.co.za>
Message-ID: <1234779475.55.0.947626870782.issue5278@psf.upfronthosting.co.za>
New submission from Senthil <orsenthil at gmail.com>:
In the Document, : Doc/library/optparse.rst,
The first usage example is given with an '=' sign for the options. This
is a mistake.
- <yourscript> --file=outfile -q
+ <yourscript> --file outfile -q
----------
assignee: georg.brandl
components: Documentation
messages: 82229
nosy: georg.brandl, orsenthil
severity: normal
status: open
title: optparse documentation example
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5278>
_______________________________________
From report at bugs.python.org Mon Feb 16 13:52:25 2009
From: report at bugs.python.org (Jakub Wilk)
Date: Mon, 16 Feb 2009 12:52:25 +0000
Subject: [New-bugs-announce] [issue5279] 2to3 mishandles some imports
In-Reply-To: <1234788745.08.0.00798731971981.issue5279@psf.upfronthosting.co.za>
Message-ID: <1234788745.08.0.00798731971981.issue5279@psf.upfronthosting.co.za>
New submission from Jakub Wilk <ubanus at users.sf.net>:
$ cat test.py
from itertools import imap as _map
$ ./2to3 test.py 2>/dev/null
--- test.py (original)
+++ test.py (refactored)
@@ -1,1 +1,1 @@
-from itertools import imap as _map
+from itertools import as _map
----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 82236
nosy: jwilk, pl
severity: normal
status: open
title: 2to3 mishandles some imports
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5279>
_______________________________________
From report at bugs.python.org Mon Feb 16 14:22:20 2009
From: report at bugs.python.org (Rasmus Andersson)
Date: Mon, 16 Feb 2009 13:22:20 +0000
Subject: [New-bugs-announce] [issue5280] PyBytes_InternInPlace is missing in
bytesobject.h
In-Reply-To: <1234790540.98.0.305505951807.issue5280@psf.upfronthosting.co.za>
Message-ID: <1234790540.98.0.305505951807.issue5280@psf.upfronthosting.co.za>
New submission from Rasmus Andersson <rasmus at flajm.com>:
The PyBytes_InternInPlace 2-to-3 transition macro is missing in
include/bytesobject.h
Alternatively, the documentation[1] is missing some details. At the top
there's a note saying "These functions have been renamed to PyBytes_* in
Python 3.x. The PyBytes names are also available in 2.6.".
[1] http://docs.python.org/c-api/string.html
Confirmed with version 2.6.1 (original release from python.org)
----------
components: Interpreter Core
messages: 82238
nosy: rsms
severity: normal
status: open
title: PyBytes_InternInPlace is missing in bytesobject.h
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5280>
_______________________________________
From report at bugs.python.org Mon Feb 16 15:47:57 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 16 Feb 2009 14:47:57 +0000
Subject: [New-bugs-announce] [issue5281] Slight inconsistency in
documentation appearances of RuntimeError
In-Reply-To: <1234795677.12.0.834283197791.issue5281@psf.upfronthosting.co.za>
Message-ID: <1234795677.12.0.834283197791.issue5281@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
The Library Exceptions documentation describes RuntimeException as "mostly
a relic from a previous version of the interpreter; it is not used very
much any more." Yet, the Reference in describing the raise statement uses
RuntimeException as an example:
raise RuntimeError("foo occurred").with_traceback(tracebackobj)
This seems slightly misleading. It might be better to just use Exception
as the example there.
----------
assignee: georg.brandl
components: Documentation
messages: 82241
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Slight inconsistency in documentation appearances of RuntimeError
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5281>
_______________________________________
From report at bugs.python.org Mon Feb 16 18:22:56 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 16 Feb 2009 17:22:56 +0000
Subject: [New-bugs-announce] [issue5282] mmap.resize and offset
In-Reply-To: <1234804976.91.0.251339540511.issue5282@psf.upfronthosting.co.za>
Message-ID: <1234804976.91.0.251339540511.issue5282@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
This is first time to look at mmap module, so sorry if I'm saying
totally wrong thing. (I noticed this when I saw issue2733) I think the
behavior of mmap_resize_method is unclear when mapping object is created
with offset > 0.
>From view of other functions, it seems that self->offset is offset from
beginning of the file, and self->size is the size of mapped area from
self->offset. If so,
#if SIZEOF_SIZE_T > 4
newSizeHigh = (DWORD)((self->offset + new_size) >> 32);
newSizeLow = (DWORD)((self->offset + new_size) & 0xFFFFFFFF);
#else
newSizeHigh = 0;
newSizeLow = (DWORD)new_size; /* shouldn't add self->offset? this is
not doing same thing as SIZEOF_SIZE_T > 4 */
#endif
And on unix part,
newmap = mremap(self->data, self->size, new_size, MREMAP_MAYMOVE);
self->offset is totally ignored. I think when self->offset > 0,
something wrong happens.
And comment above function definition saids,
/ Is this really necessary? This could easily be done
/ from python by just closing and re-opening with the
/ new size?
I think this function is not tested well. There is no test about
resize+offset in test_mmap.py.
----------
components: Extension Modules
messages: 82253
nosy: ocean-city
severity: normal
status: open
title: mmap.resize and offset
type: behavior
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5282>
_______________________________________
From report at bugs.python.org Mon Feb 16 22:24:35 2009
From: report at bugs.python.org (James William Pye)
Date: Mon, 16 Feb 2009 21:24:35 +0000
Subject: [New-bugs-announce] [issue5283] setting __class__ in __del__ is
bad. mmkay. negative ref count! kaboom!
In-Reply-To: <1234819475.16.0.132337680587.issue5283@psf.upfronthosting.co.za>
Message-ID: <1234819475.16.0.132337680587.issue5283@psf.upfronthosting.co.za>
New submission from James William Pye <x at jwp.name>:
I found this bug by misplacing a line of a code. Yes, I was doing
naughty things, but in the case of the class that led to the discovery,
it was inadvertent. :P
class something_else(object):
pass
class foo(object):
def __del__(self):
self.__class__ = something_else
for _ in range(1000):
foo()
That results in a fatal python error due to a negative reference
count(on the foo class object) in 3.0.
3.0.1 (release30-maint:69593M, Feb 13 2009, 14:48:10) -> kaboom
jwp at torch[]:org/pgfoundry/python 134% /src/build/py30/bin/python3.0
./kaboom.py
Fatal Python error: Objects/descrobject.c:10 object at 0x5221b8 has
negative ref count -1
zsh: abort /src/build/py30/bin/python3.0 ./kaboom.py
2.6 (r26:66714, Dec 21 2008, 21:17:32) -> kaboom
jwp at torch[]:org/pgfoundry/python 0% /sw/bin/python2.6 ./kaboom.py
Fatal Python error: GC object already tracked
zsh: abort /sw/bin/python2.6 ./kaboom.py
2.5.2 (r252:60911, Jun 15 2008, 18:55:39) -> no kaboom (no asserts? eh..)
...
2.5.1 (r251:54863, Apr 15 2008, 22:57:26) -> kaboom (/usr/bin/python2.5)
jwp at torch[]:org/pgfoundry/python 0% /usr/bin/python2.5 ./kaboom.py
Assertion failed: (PyType_Check(base)), function _PyType_Lookup, file
Objects/typeobject.c, line 2035.
zsh: abort /usr/bin/python2.5 ./kaboom.py
----------
components: Interpreter Core
files: kaboom.py
messages: 82272
nosy: jwp
severity: normal
status: open
title: setting __class__ in __del__ is bad. mmkay. negative ref count! kaboom!
type: crash
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file13110/kaboom.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5283>
_______________________________________
From report at bugs.python.org Mon Feb 16 22:42:13 2009
From: report at bugs.python.org (Armin Ronacher)
Date: Mon, 16 Feb 2009 21:42:13 +0000
Subject: [New-bugs-announce] [issue5284] platform.linux_distribution()
improperly documented
In-Reply-To: <1234820533.21.0.662174152251.issue5284@psf.upfronthosting.co.za>
Message-ID: <1234820533.21.0.662174152251.issue5284@psf.upfronthosting.co.za>
New submission from Armin Ronacher <armin.ronacher at active-4.com>:
platform.linux_distribution() was added in 2.6 as an alias for
platform.dist(). However the documentation lists platform.dist() as an
alias for platform.linux_distribution() and there is no information that
the latter appered in 2.6 whereas the former exists since 2.4 I think.
Not sure what the fix is, but it should be documented properly with "..
versionadded:: 2.6".
----------
assignee: lemburg
components: Documentation
keywords: easy
messages: 82273
nosy: aronacher, lemburg
priority: normal
severity: normal
status: open
title: platform.linux_distribution() improperly documented
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5284>
_______________________________________
From report at bugs.python.org Tue Feb 17 05:33:26 2009
From: report at bugs.python.org (James Henstridge)
Date: Tue, 17 Feb 2009 04:33:26 +0000
Subject: [New-bugs-announce] [issue5288] tzinfo objects with sub-minute
offsets are not supported (e.g. UTC+05:53:28)
In-Reply-To: <1234845206.93.0.372909555036.issue5288@psf.upfronthosting.co.za>
Message-ID: <1234845206.93.0.372909555036.issue5288@psf.upfronthosting.co.za>
New submission from James Henstridge <james at jamesh.id.au>:
The datetime module does not support time zones whose offset from UTC is
not an integer number of minutes.
The Olson time zone database (used by most UNIX systems and Mac OS X)
has a number of time zones with historic offsets that use second
resolution (from before those locations switched to a rounded offset
from GMT).
If you are working purely with the Python date time module, you can
round these offsets to whole numbers of minutes and get consistent
results (this is what the pytz module does), there are problems if you
want to interact with other programs using the Olson database.
As an example, PostgreSQL can return dates with sub-minute UTC offsets
and it would be nice to be able to represent them exactly.
The documentation doesn't explain why offsets need to be a whole number
of minutes, and the interface (returning timedeltas) doesn't look like
it'd need changing to support second offsets. I wouldn't expect any
more complexity in the code to support them either.
----------
components: Extension Modules
messages: 82299
nosy: jamesh
severity: normal
status: open
title: tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5288>
_______________________________________
From report at bugs.python.org Tue Feb 17 09:17:15 2009
From: report at bugs.python.org (Ke Wang)
Date: Tue, 17 Feb 2009 08:17:15 +0000
Subject: [New-bugs-announce] [issue5289] ctypes.util.find_library does not
work under Solaris
In-Reply-To: <1234858635.81.0.426092533899.issue5289@psf.upfronthosting.co.za>
Message-ID: <1234858635.81.0.426092533899.issue5289@psf.upfronthosting.co.za>
New submission from Ke Wang <ke.wang at sun.com>:
Under Solaris, find_library can not give the correct path.
Solaris does not have /sbin/ldconfig, so _findLib_gcc is used.
def _findLib_gcc(name):
expr = r'[^\(\)\s]*lib%s\.[^\(\)\s]*' % re.escape(name)
fdout, ccout = tempfile.mkstemp()
os.close(fdout)
cmd = 'if type gcc >/dev/null 2>&1; then CC=gcc; else CC=cc; fi;' \
'$CC -Wl,-t -o ' + ccout + ' 2>&1 -l' + name
try:
f = os.popen(cmd)
trace = f.read()
f.close()
finally:
try:
os.unlink(ccout)
except OSError, e:
if e.errno != errno.ENOENT:
raise
res = re.search(expr, trace)
if not res:
return None
return res.group(0)
I executed these code manually, and after ?trace = f.read()?, I printed
the content of 'trace', which was just as following:
Undefined first referenced
symbol in file
main /usr/lib/crt1.o
ld: fatal: symbol referencing errors. No output written to /tmp/tmpYN85Fm
collect2: ld returned 1 exit status
----------
assignee: theller
components: ctypes
messages: 82303
nosy: kewang, theller
severity: normal
status: open
title: ctypes.util.find_library does not work under Solaris
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5289>
_______________________________________
From report at bugs.python.org Tue Feb 17 09:25:44 2009
From: report at bugs.python.org (Beda Kosata)
Date: Tue, 17 Feb 2009 08:25:44 +0000
Subject: [New-bugs-announce] [issue5290] subprocess.Popen.communicate does
not encode unicode strings
In-Reply-To: <1234859144.87.0.49854960463.issue5290@psf.upfronthosting.co.za>
Message-ID: <1234859144.87.0.49854960463.issue5290@psf.upfronthosting.co.za>
New submission from Beda Kosata <beda at zirael.org>:
The method subprocess.Popen.communicate (more the underlying
_communicate) writes the input to the stdin stream without encoding,
regardless of it being a unicode string. The result is incorrect
behavior of the running program as it receives 4 bytes for each character.
As simple text program is here:
import subprocess
from base64 import b16encode
command = ["cat"]
p = subprocess.Popen(command, stdin=subprocess.PIPE,
stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
data = u"test text"
o, er = p.communicate(data)
print b16encode(o)
I believe that this issue is closely related to Issue2683 where this was
fixed for Python 3.0.
----------
components: Library (Lib)
messages: 82304
nosy: beda
severity: normal
status: open
title: subprocess.Popen.communicate does not encode unicode strings
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5290>
_______________________________________
From report at bugs.python.org Tue Feb 17 10:09:16 2009
From: report at bugs.python.org (Michael Kesper)
Date: Tue, 17 Feb 2009 09:09:16 +0000
Subject: [New-bugs-announce] [issue5291] Windows upgrade to 2.6.1 requires
2.6 installer to be present
In-Reply-To: <1234861756.46.0.69901675612.issue5291@psf.upfronthosting.co.za>
Message-ID: <1234861756.46.0.69901675612.issue5291@psf.upfronthosting.co.za>
New submission from Michael Kesper <mkesper at schokokeks.org>:
When upgrading to 2.6.1, an error occurs if the old installer is not
found. I needed to open it several times until I read _what_ was needed.
Finding old installers on python.org requires too much search, too.
----------
components: Installation
files: python_261.png
messages: 82305
nosy: mkesper
severity: normal
status: open
title: Windows upgrade to 2.6.1 requires 2.6 installer to be present
versions: Python 2.6
Added file: http://bugs.python.org/file13114/python_261.png
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5291>
_______________________________________
From report at bugs.python.org Tue Feb 17 10:35:57 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 17 Feb 2009 09:35:57 +0000
Subject: [New-bugs-announce] [issue5292] mmap crashes just on boundary.
In-Reply-To: <1234863357.35.0.195202793383.issue5292@psf.upfronthosting.co.za>
Message-ID: <1234863357.35.0.195202793383.issue5292@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
I noticed following code crashes. I'll post fix soon.
import mmap
import os
def main():
align = mmap.ALLOCATIONGRANULARITY
path = os.path.splitext(__file__)[0] + ".txt"
with open(path, "w") as f:
f.write("0" * align)
f.write("1" * align)
f.write("2" * align)
with open(path, "r+") as f:
m = mmap.mmap(f.fileno(), align)
m[align] # crash
m[align] = '1' # crash too
if __name__ == '__main__':
main()
----------
components: Extension Modules
messages: 82307
nosy: ocean-city
severity: normal
status: open
title: mmap crashes just on boundary.
type: crash
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5292>
_______________________________________
From report at bugs.python.org Tue Feb 17 11:06:34 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 17 Feb 2009 10:06:34 +0000
Subject: [New-bugs-announce] [issue5293] socket timeouts even in blocking
mode
In-Reply-To: <1234865194.48.0.771054694385.issue5293@psf.upfronthosting.co.za>
Message-ID: <1234865194.48.0.771054694385.issue5293@psf.upfronthosting.co.za>
New submission from anatoly techtonik <techtonik at gmail.com>:
The code below exits with timeout after about 20 secs on Windows +
Python 2.5.4
import socket
# address of server routable, but offline
server = "192.168.1.2"
s = socket.socket()
s.setblocking(1)
s.connect((server, 139))
s.close()
The output is:
Traceback (most recent call last):
File "D:\.env\test.py", line 6, in <module>
s.connect((server, 139))
File "<string>", line 1, in connect
socket.error: (10060, 'Operation timed out')
If timeout is set to 1 it exits almost immediately. If timeout is large
it waits for about 20 seconds and exits.
I use socket to wait for the network service to appear. The target
machine 192.168.1.2 belongs to local network, but offline.
----------
components: Library (Lib), Windows
messages: 82311
nosy: techtonik
severity: normal
status: open
title: socket timeouts even in blocking mode
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5293>
_______________________________________
From report at bugs.python.org Tue Feb 17 12:51:45 2009
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 17 Feb 2009 11:51:45 +0000
Subject: [New-bugs-announce] [issue5294] pdb "break" command messes up
"continue"
In-Reply-To: <1234871505.48.0.0380268951532.issue5294@psf.upfronthosting.co.za>
Message-ID: <1234871505.48.0.0380268951532.issue5294@psf.upfronthosting.co.za>
New submission from Petr Viktorin <encukou at gmail.com>:
Consider this program:
import pdb
pdb.set_trace()
print ("At line 5")
print ("At line 6")
print ("At line 7")
print ("At line 8")
print ("At line 9")
When set_trace starts the debugger, I set a breakpoint at line 8. When I
do that, the continue command starts single-stepping instead of what it
usually does.
Also, the module will appear twice on the call stack (although pdb won't
show this).
Here is the pdb session:
$ python pdbfail.py
> /home/petr/tmp/pdbfail.py(5)<module>()
-> print ("At line 5")
(Pdb) break 8
Breakpoint 1 at /home/petr/tmp/pdbfail.py:8
(Pdb) continue
At line 5
> /home/petr/tmp/pdbfail.py(6)<module>()
-> print ("At line 6")
(Pdb) continue
At line 6
> /home/petr/tmp/pdbfail.py(7)<module>()
-> print ("At line 7")
(Pdb) where
> /home/petr/tmp/pdbfail.py(7)<module>()
-> print ("At line 7")
(Pdb) quit
Traceback (most recent call last):
File "pdbfail.py", line 7, in <module>
print ("At line 7")
File "pdbfail.py", line 7, in <module>
print ("At line 7")
File "/usr/lib/python2.5/bdb.py", line 48, in trace_dispatch
return self.dispatch_line(frame)
File "/usr/lib/python2.5/bdb.py", line 67, in dispatch_line
if self.quitting: raise BdbQuit
bdb.BdbQuit
----------
components: Library (Lib)
messages: 82322
nosy: En-Cu-Kou
severity: normal
status: open
title: pdb "break" command messes up "continue"
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5294>
_______________________________________
From report at bugs.python.org Tue Feb 17 17:34:22 2009
From: report at bugs.python.org (David W. Lambert)
Date: Tue, 17 Feb 2009 16:34:22 +0000
Subject: [New-bugs-announce] [issue5295] turtle.py "dicionary" spelling patch
In-Reply-To: <1234888462.64.0.860042232767.issue5295@psf.upfronthosting.co.za>
Message-ID: <1234888462.64.0.860042232767.issue5295@psf.upfronthosting.co.za>
New submission from David W. Lambert <lambertdw at corning.com>:
x/lib/python3.0$ diff --unified turtle.py.bak turtle.py
--- turtle.py.bak 2009-02-17 11:29:15.000000000 -0500
+++ turtle.py 2009-02-17 11:29:37.000000000 -0500
@@ -2265,7 +2265,7 @@
"outline" : positive number
"tilt" : number
- This dicionary can be used as argument for a subsequent
+ This dictionary can be used as argument for a subsequent
pen()-call to restore the former pen-state. Moreover one
or more of these attributes can be provided as keyword-arguments.
This can be used to set several pen attributes in one statement.
----------
components: Library (Lib)
messages: 82341
nosy: LambertDW
severity: normal
status: open
title: turtle.py "dicionary" spelling patch
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5295>
_______________________________________
From report at bugs.python.org Tue Feb 17 20:19:25 2009
From: report at bugs.python.org (bob gailer)
Date: Tue, 17 Feb 2009 19:19:25 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue5296=5D_Use_of_term_sequenc?=
=?utf-8?q?e_in_Reference_6=2E3=09Assignment=09Statements?=
In-Reply-To: <1234898365.36.0.574422214894.issue5296@psf.upfronthosting.co.za>
Message-ID: <1234898365.36.0.574422214894.issue5296@psf.upfronthosting.co.za>
New submission from bob gailer <bgailer at gmail.com>:
Currently reads, in part, "If the target list is a comma-separated list
of targets: The object must be a sequence ..."
Change "a sequence" to "an iterable".
Also consider removing references to versions earlier than 1.5.
----------
assignee: georg.brandl
components: Documentation
messages: 82357
nosy: bgailer, georg.brandl
severity: normal
status: open
title: Use of term sequence in Reference 6.3 Assignment Statements
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5296>
_______________________________________
From report at bugs.python.org Tue Feb 17 21:25:29 2009
From: report at bugs.python.org (Zach Dwiel)
Date: Tue, 17 Feb 2009 20:25:29 +0000
Subject: [New-bugs-announce] [issue5297] Bug in SocketServer Example
In-Reply-To: <1234902329.49.0.0568937669385.issue5297@psf.upfronthosting.co.za>
Message-ID: <1234902329.49.0.0568937669385.issue5297@psf.upfronthosting.co.za>
New submission from Zach Dwiel <zdwiel at gmail.com>:
There is a bug in the example code:
http://docs.python.org/library/socketserver.html
The very last example has the line:
print "Server loop running in thread:", t.getName()
should be:
print "Server loop running in thread:", server_thread.getName()
Should I post this somewhere else or is this the right place?
----------
assignee: georg.brandl
components: Documentation
messages: 82363
nosy: georg.brandl, zdwiel
severity: normal
status: open
title: Bug in SocketServer Example
type: compile error
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5297>
_______________________________________
From report at bugs.python.org Tue Feb 17 21:42:11 2009
From: report at bugs.python.org (Philip Semanchuk)
Date: Tue, 17 Feb 2009 20:42:11 +0000
Subject: [New-bugs-announce] [issue5298] Inconsistency in C-API thread docs
In-Reply-To: <1234903331.05.0.935638170242.issue5298@psf.upfronthosting.co.za>
Message-ID: <1234903331.05.0.935638170242.issue5298@psf.upfronthosting.co.za>
New submission from Philip Semanchuk <osvenskan at users.sourceforge.net>:
The language in the threading API documentation is a little
inconsistent. The section I'm talking about is here:
http://docs.python.org/c-api/init.html#thread-state-and-the-global-interpreter-lock
The GIL is variously referred to as "global lock", "interpreter lock",
"global interpreter lock", "GIL", and simply "the lock". Given the
infamy of the GIL, one might expect all of these to be equally clear.
But as someone coding to this API for the first time, I had plenty to
learn already and the need to ensure that all of these referred to the
same singleton was distracting.
This documentation begins, "The Python interpreter is not fully thread
safe. In order to support multi-threaded Python programs, there's a
global lock that must be held by the current thread before it can safely
access Python objects. Without the lock..."
My suggestion is to alter the second sentence to the following:
"Without this lock (called the global interpreter lock, or GIL for
short)...."
All subsequent documentation references to "interpreter lock", "global
interpreter lock", and "lock" should be changed to "GIL". It would be
nice if the API referred to it consistently (e.g. PyEval_AcquireLock()
versus PyGILState_Ensure()) but that would require an interface change
which is obviously out of the question.
----------
assignee: georg.brandl
components: Documentation
messages: 82365
nosy: georg.brandl, osvenskan
severity: normal
status: open
title: Inconsistency in C-API thread docs
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5298>
_______________________________________
From report at bugs.python.org Tue Feb 17 21:43:34 2009
From: report at bugs.python.org (Philip Semanchuk)
Date: Tue, 17 Feb 2009 20:43:34 +0000
Subject: [New-bugs-announce] [issue5299]
PyGILState_Ensure()/PyGILState_Release() documentation incomplete?
In-Reply-To: <1234903414.06.0.277492478089.issue5299@psf.upfronthosting.co.za>
Message-ID: <1234903414.06.0.277492478089.issue5299@psf.upfronthosting.co.za>
New submission from Philip Semanchuk <osvenskan at users.sourceforge.net>:
The threading API documentation might omit out some important
information about the GIL.
The GIL can be acquired by explicitly calling PyEval_AcquireLock(). One
can also acquire the GIL by calling PyGILState_Ensure(). The latter
differs from the former in that calling PyGILState_Ensure() when one
already has the GIL will not create deadlock. This is implied; it would
be helpful if this was explicitly stated.
Likewise, I assume that the Nth call to PyGILState_Release() releases
the GIL, where N = the number of calls made previously to
PyGILState_Ensure(). But I don't know this and the documentation doesn't
make it clear.
As a first-time user of the API, it makes me nervous to call
PyGILState_Ensure() which acquires the GIL without knowing for sure that
PyGILState_Release() releases it. I can't evaluate my code for logical
correctness, and when dealing with threads and the GIL, neither can I be
sure that timing-dependent bugs will show up in testing. As a result, my
code feels fragile.
I don't understand how the code works well enough to suggest better
documentation. If nothing else, it would be useful to see something that
promises that as long as each call to PyGILState_Ensure() is matched
with a call to PyGILState_Release(), the GIL will take care of itself.
----------
assignee: georg.brandl
components: Documentation
messages: 82366
nosy: georg.brandl, osvenskan
severity: normal
status: open
title: PyGILState_Ensure()/PyGILState_Release() documentation incomplete?
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5299>
_______________________________________
From report at bugs.python.org Tue Feb 17 22:54:54 2009
From: report at bugs.python.org (George Sakkis)
Date: Tue, 17 Feb 2009 21:54:54 +0000
Subject: [New-bugs-announce] [issue5300] Distutils ignores file permissions
In-Reply-To: <1234907694.25.0.317480697226.issue5300@psf.upfronthosting.co.za>
Message-ID: <1234907694.25.0.317480697226.issue5300@psf.upfronthosting.co.za>
New submission from George Sakkis <george.sakkis at gmail.com>:
Distutils ignores file permissions when copying modules and package_data
files to the build directory, and consequently to the installation
directory too. According to an XXX comment at
distutils/command/build_py.py, this is deliberate so that the built
files are not read-only, which would be a nuisance when rebuilding. This
problem though could be solved by just setting the write flag for the
user (chmod u+w) instead of overwriting all the flags. In my case, some
executable files ceased to be executable after installation.
I believe that the default behavior should be changed to preserve all
permissions, with the possible exception of setting u+w. Even that might
be unnecessary; AFAIK to delete a file you need write permissions only
to its parent directory, not to the file itself.
Even if the current behavior is deemed correct, at the very least the
code should be refactored to allow easy overriding. Currently
build_module and build_package_data pass preserve_mode=False in their
body, so I had to copy and paste the whole methods just to set
preserve_mode=True.
----------
assignee: tarek
components: Distutils
messages: 82372
nosy: gsakkis, tarek
severity: normal
status: open
title: Distutils ignores file permissions
type: behavior
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5300>
_______________________________________
From report at bugs.python.org Tue Feb 17 22:56:32 2009
From: report at bugs.python.org (Drew Hintz)
Date: Tue, 17 Feb 2009 21:56:32 +0000
Subject: [New-bugs-announce] [issue5301] add mimetype for
image/vnd.microsoft.icon (patch)
In-Reply-To: <1234907792.31.0.00254559526039.issue5301@psf.upfronthosting.co.za>
Message-ID: <1234907792.31.0.00254559526039.issue5301@psf.upfronthosting.co.za>
New submission from Drew Hintz <drew at overt.org>:
Adds a mimetype entry for image/vnd.microsoft.icon
This mimetype is commonly used for favicon.ico files and is registered
with IANA.
----------
components: Library (Lib)
files: mimetypes.py.diff
keywords: patch
messages: 82373
nosy: adhintz
severity: normal
status: open
title: add mimetype for image/vnd.microsoft.icon (patch)
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file13125/mimetypes.py.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5301>
_______________________________________
From report at bugs.python.org Tue Feb 17 23:32:14 2009
From: report at bugs.python.org (George Sakkis)
Date: Tue, 17 Feb 2009 22:32:14 +0000
Subject: [New-bugs-announce] [issue5302] Allow package_data globs match
directories
In-Reply-To: <1234909934.56.0.127417684931.issue5302@psf.upfronthosting.co.za>
Message-ID: <1234909934.56.0.127417684931.issue5302@psf.upfronthosting.co.za>
New submission from George Sakkis <george.sakkis at gmail.com>:
Currently each glob defined in package_data must match files only; if it
matches a directory, it raises an exception later when calling
copy_file(). This means that a glob like 'mydata/*' will fail if there
is any subdirectory under 'mydata'. One simple useful change would be to
allow a glob match a directory and interpret it as a recursive inclusion
of the directory.
A more general feature request (perhaps a separate ticket) would be to
port to setup() the logic currently expressed in MANIFEST.in. In the
long term, MF.in should IMO be deprecated because (a) it's a second file
one has to remember to write and maintain in addition to setup.py (b)
has its own ad-hoc syntax instead of python and (c) overlaps in scope
with package_data and data_files of setup.py. The exact API exposing
MF.in's functionality can be decided after (and if) there is consensus
on deprecating/replacing it.
----------
assignee: tarek
components: Distutils
messages: 82378
nosy: gsakkis, tarek
severity: normal
status: open
title: Allow package_data globs match directories
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5302>
_______________________________________
From report at bugs.python.org Tue Feb 17 23:39:21 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 17 Feb 2009 22:39:21 +0000
Subject: [New-bugs-announce] [issue5303] Use base 2**30 for Python longs,
when possible
In-Reply-To: <0016e643449239839d046324f941@google.com>
Message-ID: <0016e643449239839d046324f941@google.com>
New submission from Martin v. L?wis <martin at v.loewis.de>:
http://codereview.appspot.com/14105/diff/1/11
File Doc/library/sys.rst (right):
http://codereview.appspot.com/14105/diff/1/11#newcode418
Line 418: A struct sequence that holds information about Python's
I don't think the sequence interface is really important here. There
should be a way to easily define regular struct-like classes (with no
sequence interface). Perhaps structseq could be modified to drop
sequence interface, and new structseqs should turn it off usually.
http://codereview.appspot.com/14105/diff/1/6
File Include/longintrepr.h (right):
http://codereview.appspot.com/14105/diff/1/6#newcode24
Line 24: Furthermore, NSMALLNEGINTS and NSMALLPOSINTS should fit in a
digit. */
Merge the comments into a single on. There is no need to preserve the
evolution of the code in the comment structure.
http://codereview.appspot.com/14105/diff/1/9
File Objects/longobject.c (right):
http://codereview.appspot.com/14105/diff/1/9#newcode2872
Line 2872: /* XXX benchmark this! Is is worth keeping? */
Why not PyLong_FromLongLong if available (no special case if not)?
http://codereview.appspot.com/14105/diff/1/10
File PC/pyconfig.h (right):
http://codereview.appspot.com/14105/diff/1/10#newcode318
Line 318: #define PY_UINT64_T unsigned __int64
I think this should use PY_LONG_LONG, to support MingW32; likewise,
__int32 shouldn't be used, as it is MSC specific
http://codereview.appspot.com/14105/diff/1/2
File Python/marshal.c (right):
http://codereview.appspot.com/14105/diff/1/2#newcode160
Line 160: w_long((long)(Py_SIZE(ob) > 0 ? l : -l), p);
This needs to deal with overflow (sizeof(size_t) > sizeof(long))
http://codereview.appspot.com/14105/diff/1/2#newcode540
Line 540: if (n < -INT_MAX || n > INT_MAX)
I think this is obsolete now; longs can have up to ssize_t_max digits.
http://codereview.appspot.com/14105/diff/1/8
File configure.in (right):
http://codereview.appspot.com/14105/diff/1/8#newcode3132
Line 3132: # determine what size digit to use for Python's longs
I'm skeptical (-0) that we really need to have such a configure option.
http://codereview.appspot.com/14105/diff/1/14
File pyconfig.h.in (left):
http://codereview.appspot.com/14105/diff/1/14#oldcode9
Line 9: #undef AC_APPLE_UNIVERSAL_BUILD
We should find out why this is gone.
http://codereview.appspot.com/14105/diff/1/14#oldcode958
Line 958: /* Enable extensions on AIX 3, Interix. */
Likewise, this needs to be preserved.
http://codereview.appspot.com/14105/diff/1/14#oldcode1017
Line 1017: /* Define WORDS_BIGENDIAN to 1 if your processor stores words
with the most
This also needs to be preserved.
http://codereview.appspot.com/14105
----------
messages: 82381
nosy: loewis, marketdickinson
severity: normal
status: open
title: Use base 2**30 for Python longs, when possible
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5303>
_______________________________________
From report at bugs.python.org Wed Feb 18 02:36:07 2009
From: report at bugs.python.org (l5g)
Date: Wed, 18 Feb 2009 01:36:07 +0000
Subject: [New-bugs-announce] [issue5304] email/base64mime.py cannot work
In-Reply-To: <1234920967.72.0.68808055681.issue5304@psf.upfronthosting.co.za>
Message-ID: <1234920967.72.0.68808055681.issue5304@psf.upfronthosting.co.za>
New submission from l5g <80723567 at qq.com>:
When using smtplib to send mail, I meet this bug. Maybe the line
""" enc = b2a_base64(s[i:i +
max_unencoded]).decode("ascii")"""
should be changed to
""" enc = b2a_base64((s[i:i +
max_unencoded]).encode()).decode("ascii")
File "/usr/local/lib/python3.0/smtplib.py", line 580, in login
AUTH_PLAIN + " " + encode_plain(user, password))
File "/usr/local/lib/python3.0/smtplib.py", line 545, in encode_plain
return encode_base64("\0%s\0%s" % (user, password))
File "/usr/local/lib/python3.0/email/base64mime.py", line 97, in
body_encode
enc = b2a_base64(s[i:i + max_unencoded]).decode("ascii")
TypeError: b2a_base64() argument 1 must be bytes or buffer, not str
----------
messages: 82400
nosy: l5g
severity: normal
status: open
title: email/base64mime.py cannot work
type: compile error
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5304>
_______________________________________
From report at bugs.python.org Wed Feb 18 06:36:11 2009
From: report at bugs.python.org (James Henstridge)
Date: Wed, 18 Feb 2009 05:36:11 +0000
Subject: [New-bugs-announce] [issue5305] imaplib should support
international mailbox names
In-Reply-To: <1234935371.11.0.35650041724.issue5305@psf.upfronthosting.co.za>
Message-ID: <1234935371.11.0.35650041724.issue5305@psf.upfronthosting.co.za>
New submission from James Henstridge <james at jamesh.id.au>:
The IMAP4rev1 specification allows for non-ASCII mailbox names using a
modified UTF-7 encoding (section 5.1.3 of RFC 2060 or 3501). However,
the imaplib routines taking a mailbox name just pass the string straight
through without any encoding.
It would be useful if Python provided an encoder/decoder for the
modified UTF-7 encoding, and optionally if imaplib would perform the
encoding and decoding at the appropriate points.
----------
components: Library (Lib)
messages: 82408
nosy: jamesh
severity: normal
status: open
title: imaplib should support international mailbox names
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5305>
_______________________________________
From report at bugs.python.org Wed Feb 18 23:30:08 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 18 Feb 2009 22:30:08 +0000
Subject: [New-bugs-announce] [issue5306] Python 3.1 won't compile under
Visual Studio 2005
In-Reply-To: <1234996208.64.0.318927789684.issue5306@psf.upfronthosting.co.za>
Message-ID: <1234996208.64.0.318927789684.issue5306@psf.upfronthosting.co.za>
New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:
This started happening a few days ago, about when Benjamin forward
ported r69560 . There is an #ifdef in fileobject.h that makes a header
for int _PyVerify_fd(int fd) but does not define it. It is likely
related to r69495 .
_fileio.obj : error LNK2019: unresolved external symbol __PyVerify_fd
referenced in function _check_fd
C:\py31\PC\VS8.0\\python31_d.dll : fatal error LNK1120: 1 unresolved
externals
----------
assignee: loewis
components: Interpreter Core
messages: 82435
nosy: loewis, rhettinger
priority: high
severity: normal
status: open
title: Python 3.1 won't compile under Visual Studio 2005
type: compile error
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5306>
_______________________________________
From report at bugs.python.org Wed Feb 18 23:32:50 2009
From: report at bugs.python.org (Peter Rowat)
Date: Wed, 18 Feb 2009 22:32:50 +0000
Subject: [New-bugs-announce] [issue5307] Python-3.0.1 install fails on
Solaris
In-Reply-To: <1234996370.91.0.814051223395.issue5307@psf.upfronthosting.co.za>
Message-ID: <1234996370.91.0.814051223395.issue5307@psf.upfronthosting.co.za>
New submission from Peter Rowat <peter at pelican.ucsd.edu>:
My sysadmin tried to install Python-3.0.1 on Solaris,
using Python-3.0.1.tgz, and reports:
=====
can't configure it, got an error, even before the compile...
probably buggy and won't work on solaris.
======
Any ideas?
Thanks.
----------
components: Installation
messages: 82436
nosy: prowat
severity: normal
status: open
title: Python-3.0.1 install fails on Solaris
type: compile error
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5307>
_______________________________________
From report at bugs.python.org Wed Feb 18 23:45:06 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 18 Feb 2009 22:45:06 +0000
Subject: [New-bugs-announce] [issue5308] cannot marshal objects with more
than 2**31 elements
In-Reply-To: <1234997106.01.0.558053875674.issue5308@psf.upfronthosting.co.za>
Message-ID: <1234997106.01.0.558053875674.issue5308@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
Two closely related issues in Python/marshal.c, involving writing and
reading of variable-length objects (lists, strings, long integers, ...)
(1) The w_object function in marshal contains many instances of code
like the following:
else if (PyList_CheckExact(v)) {
w_byte(TYPE_LIST, p);
n = PyList_GET_SIZE(v);
w_long((long)n, p);
for (i = 0; i < n; i++) {
w_object(PyList_GET_ITEM(v, i), p);
}
}
On a 64-bit platform there's potential loss of information here
either in the cast "(long)n" (if sizeof(long) is 4), or in
w_long itself (if sizeof(long) is 8). Note that w_long, despite
its name, always writes exactly 4 bytes.
There should at least be an exception raised here if n is not
in the range [-2**31, 2**31). This would make marshalling of
large objects illegal (rather than just wrong).
A more involved fix would allow marshalling of objects of size >= 2**31.
This would obviously involve changing the marshal format, and would make
it impossible to marshal a large object on a 64-bit platform and then
unmarshal it on a 32-bit platform. The latter may not really be a
problem, since memory considerations ought to rule that out anyway.
(2) In r_object (and possibly elsewhere) there are corresponding checks
of the form:
case TYPE_LIST:
n = r_long(p);
if (n < 0 || n > INT_MAX) {
PyErr_SetString(PyExc_ValueError, "bad marshal data");
retval = NULL;
break;
}
...
if we allow marshalling of objects with more than 2**31-1 elements then
these error checks can be relaxed. (And as a matter of principle,
INT_MAX isn't really right here: an int might be only 16 bits long on
some strange platforms...).
----------
components: Interpreter Core
messages: 82437
nosy: marketdickinson
severity: normal
status: open
title: cannot marshal objects with more than 2**31 elements
type: behavior
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5308>
_______________________________________
From report at bugs.python.org Thu Feb 19 02:39:52 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Feb 2009 01:39:52 +0000
Subject: [New-bugs-announce] [issue5309] setup.py doesn't parallelize
extension module compilation
In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za>
Message-ID: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
When run with "make -jN", the Python compilation process is able to
parallelize across N concurrent processes for the interpreter core, but
extension modules are still compiled sequentially.
----------
assignee: tarek
components: Distutils
messages: 82447
nosy: pitrou, tarek
priority: low
severity: normal
status: open
title: setup.py doesn't parallelize extension module compilation
type: feature request
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5309>
_______________________________________
From report at bugs.python.org Thu Feb 19 04:51:08 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Thu, 19 Feb 2009 03:51:08 +0000
Subject: [New-bugs-announce] [issue5310] operator precedence table is wrong
In-Reply-To: <1235015468.16.0.2806325305.issue5310@psf.upfronthosting.co.za>
Message-ID: <1235015468.16.0.2806325305.issue5310@psf.upfronthosting.co.za>
New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:
The operator precedence table is wrong.
<http://docs.python.org/reference/
expressions.html#summary>
shows "in"/"not in" having less priority than
comparisons like "==", but that's not true:
py> 2 in (1,2) == True
False
The .rst file is wrong, as well as all the
generated .html files since version 2.1 at least.
But the original Latex source lists them in the
same group.
Looks like the latex->html and latex->rst tools
both had the same problem with this kind of
table construct.
The attached patch is based on the ref5.tex file
included in Python 2.5
----------
assignee: georg.brandl
components: Documentation
messages: 82451
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: operator precedence table is wrong
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5310>
_______________________________________
From report at bugs.python.org Thu Feb 19 05:16:09 2009
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 19 Feb 2009 04:16:09 +0000
Subject: [New-bugs-announce] [issue5311] bdist_msi generates version number
for pure Python packages
In-Reply-To: <1235016969.03.0.818386696301.issue5311@psf.upfronthosting.co.za>
Message-ID: <1235016969.03.0.818386696301.issue5311@psf.upfronthosting.co.za>
New submission from Steven Bethard <steven.bethard at gmail.com>:
I just ran "setup.py bdist_msi" with NLTK which is a pure Python
package. You can see the setup.py here:
http://code.google.com/p/nltk/source/browse/trunk/nltk/setup.py. Despite
the fact that NLTK is pure Python, the generated .msi's look like
nltk-0.9.8.win32-py2.5.msi and nltk-0.9.8.win32-py2.6.msi (built with
Python 2.5 and 2.6 respectively).
So, two questions: (1) are the version numbers supposed to be there? and
(2) if so, does that mean a .msi for a pure Python package built by
Python 2.6 won't work on any other version?
----------
assignee: tarek
components: Distutils
messages: 82455
nosy: bethard, tarek
severity: normal
status: open
title: bdist_msi generates version number for pure Python packages
type: behavior
versions: Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5311>
_______________________________________
From report at bugs.python.org Thu Feb 19 05:16:24 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 19 Feb 2009 04:16:24 +0000
Subject: [New-bugs-announce] [issue5312] errno not being set
In-Reply-To: <1235016984.63.0.365921412426.issue5312@psf.upfronthosting.co.za>
Message-ID: <1235016984.63.0.365921412426.issue5312@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <benjamin at python.org>:
def test_leaking_fds_on_error(self):
# see bug #5179: Popen leaks file descriptors to PIPEs if
# the child fails to execute; this will eventually exhaust
# the maximum number of open fds. 1024 seems a very common
# value for that limit, but Windows has 2048, so we loop
# 1024 times (each call leaked two fds).
for i in range(1024):
try:
subprocess.Popen(['nonexisting_i_hope'],
stdout=subprocess.PIPE,
stderr=subprocess.PIPE)
# Windows raises IOError
except (IOError, OSError) as err:
self.assertEqual(err.errno, 2)
This test is failing in py3k because errno is not being set on the
exception and is None. I don't have time to investigate more at the moment.
----------
messages: 82456
nosy: benjamin.peterson, georg.brandl
priority: high
severity: normal
status: open
title: errno not being set
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5312>
_______________________________________
From report at bugs.python.org Thu Feb 19 06:21:12 2009
From: report at bugs.python.org (Graham Dumpleton)
Date: Thu, 19 Feb 2009 05:21:12 +0000
Subject: [New-bugs-announce] [issue5313] multiprocessing.process using
os.close(sys.stdin.fileno) instead of sys.stdin.close()
In-Reply-To: <1235020872.08.0.0158488308351.issue5313@psf.upfronthosting.co.za>
Message-ID: <1235020872.08.0.0158488308351.issue5313@psf.upfronthosting.co.za>
New submission from Graham Dumpleton <Graham.Dumpleton at gmail.com>:
In multiprocessing.process it contains the code:
def _bootstrap(self):
....
if sys.stdin is not None:
try:
os.close(sys.stdin.fileno())
except (OSError, ValueError):
pass
This code should probably be calling sys.stdin.close() and not
os.close(sys.stdin.fileno()).
The code as is will fail if sys.stdin had been replaced with an alternate
file like object, such as StringIO, which doesn't have a fileno() method.
----------
messages: 82457
nosy: grahamd, jnoller
severity: normal
status: open
title: multiprocessing.process using os.close(sys.stdin.fileno) instead of sys.stdin.close()
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5313>
_______________________________________
From martin at v.loewis.de Thu Feb 19 07:45:21 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 19 Feb 2009 07:45:21 +0100
Subject: [New-bugs-announce] [issue5311] bdist_msi generates version
number for pure Python packages
In-Reply-To: <1235016969.03.0.818386696301.issue5311@psf.upfronthosting.co.za>
References: <1235016969.03.0.818386696301.issue5311@psf.upfronthosting.co.za>
Message-ID: <499D0001.4000604@v.loewis.de>
> So, two questions: (1) are the version numbers supposed to be there?
Yes.
> (2) if so, does that mean a .msi for a pure Python package built by
> Python 2.6 won't work on any other version?
Yes.
From report at bugs.python.org Thu Feb 19 10:05:02 2009
From: report at bugs.python.org (cober J)
Date: Thu, 19 Feb 2009 09:05:02 +0000
Subject: [New-bugs-announce] [issue5314] http client error
In-Reply-To: <1235034302.73.0.497047240099.issue5314@psf.upfronthosting.co.za>
Message-ID: <1235034302.73.0.497047240099.issue5314@psf.upfronthosting.co.za>
New submission from cober J <jiaqiubo at gmail.com>:
Try to use http to send multi-byte utf8 data.
File "E:\DEVELOP\python\lib\http\client.py", line 904, in _send_request
self.endheaders(body.encode('ascii'))
UnicodeEncodeError: 'ascii' codec can't encode character '\u7231' in
position 119: ordinal not in range(128)
I modified the lib/http/client.py document, and fix this problem.
----------
components: Library (Lib)
files: client.py
messages: 82465
nosy: cober
severity: normal
status: open
title: http client error
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file13136/client.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5314>
_______________________________________
From report at bugs.python.org Thu Feb 19 14:47:08 2009
From: report at bugs.python.org (=?utf-8?q?P=C3=A9ter_Szab=C3=B3?=)
Date: Thu, 19 Feb 2009 13:47:08 +0000
Subject: [New-bugs-announce] [issue5315] signal handler never gets called
In-Reply-To: <1235051228.14.0.0909837566577.issue5315@psf.upfronthosting.co.za>
Message-ID: <1235051228.14.0.0909837566577.issue5315@psf.upfronthosting.co.za>
New submission from P?ter Szab? <ptspts at gmail.com>:
According to http://docs.python.org/dev/library/signal.html , if I set
up a signal handler in the main thread, and then have the signal
delivered to the process, then the signal handler will be called in the
main thread. The attached Python script I've written, however, doesn't
work that way: sometimes the signal is completely lost, and the signal
handler is not called.
Here is how it should work. The code has two threads: the main thread
and the subthread. There is also a signal handler installed. The main
thread is running select.select(), waiting for a filehandle to become
readable. Then the subthread sends a signal to the process. The signal
handler writes a byte to the pipe. The select wakes up raising
'Interrupted system call' because of the signal.
I'm running Ubuntu Hardy on x86_64. With Python 2.4.5 and Python 2.5.2,
sometimes the signal handler is not called, and the select continues
waiting indefinitely. This is what I get on stdout in Python 2.4.5:
main pid=8555
--- 0
A
B
S
T
U
handler arg1=10 arg2=<frame object at 0x79ab40>
select got="(4, 'Interrupted system call')"
read str='W'
--- 1
A
B
S
T
U
This means that iteration 0 completed successfully: the signal handler
got called, and the select raised 'Interrupted system call'. However,
iteration 1 was stuck: the signal handler was never called, and the
select waits indefinitely.
The script seems to work in Python 2.4.3, but it hangs in iteration
about 60000.
----------
components: Interpreter Core, Library (Lib)
files: tsig.py
messages: 82472
nosy: pts
severity: normal
status: open
title: signal handler never gets called
type: behavior
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file13138/tsig.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5315>
_______________________________________
From report at bugs.python.org Thu Feb 19 16:37:21 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Feb 2009 15:37:21 +0000
Subject: [New-bugs-announce] [issue5316] Buildbot failures in test_site
In-Reply-To: <1235057841.41.0.664492545645.issue5316@psf.upfronthosting.co.za>
Message-ID: <1235057841.41.0.664492545645.issue5316@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
Recently, some buildbot failures have started appearing on trunk and
py3k with the following error:
======================================================================
FAIL: test_s_option (test.test_site.HelperFunctionsTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/home/pybot/buildarea/3.x.klose-ubuntu-i386/build/Lib/test/test_site.py",
line 105, in test_s_option
self.assertEqual(rc, 1)
AssertionError: 0 != 1
make: *** [buildbottest] Error 1
----------
components: Library (Lib), Tests
messages: 82477
nosy: pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: Buildbot failures in test_site
type: behavior
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5316>
_______________________________________
From report at bugs.python.org Thu Feb 19 17:31:03 2009
From: report at bugs.python.org (David Fugate)
Date: Thu, 19 Feb 2009 16:31:03 +0000
Subject: [New-bugs-announce] [issue5317] URL given for IronPython in CPython
documentation incorrect
In-Reply-To: <1235061063.62.0.930168396958.issue5317@psf.upfronthosting.co.za>
Message-ID: <1235061063.62.0.930168396958.issue5317@psf.upfronthosting.co.za>
New submission from David Fugate <midnightdf at yahoo.com>:
http://docs.python.org/reference/introduction.html#alternate-
implementations states that the IronPython project's website URL is
http://workspaces.gotdotnet.com/ironpython. This site has actually
been dead for quite some time and our official project page is
http://www.ironpython.com/ which we plan on revamping shortly.
Thanks,
Dave
----------
assignee: georg.brandl
components: Documentation
messages: 82478
nosy: dfugate, georg.brandl
severity: normal
status: open
title: URL given for IronPython in CPython documentation incorrect
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5317>
_______________________________________
From report at bugs.python.org Thu Feb 19 18:21:30 2009
From: report at bugs.python.org (alexlc)
Date: Thu, 19 Feb 2009 17:21:30 +0000
Subject: [New-bugs-announce] [issue5318] strip, rstrip & lstrip bug
In-Reply-To: <1235064090.02.0.287381769922.issue5318@psf.upfronthosting.co.za>
Message-ID: <1235064090.02.0.287381769922.issue5318@psf.upfronthosting.co.za>
New submission from alexlc <alc at niebla.co.uk>:
Examples of bad behaviour:
>>> 'abacde'.lstrip('ab')
'cde'
>>> 'abaaacde'.lstrip('ab')
'cde'
>>> 'aabacde'.lstrip('aab')
'cde'
>>> 'abcede'.rstrip( 'de' )
'abc'
>>> 'abacdeaab'.strip('ab')
'cde'
Probably a few more similar to these will fail as well.
I have tested this with a fairly recent 2.5 (maybe 2.53 maybe 2.54), and
with 2.6.1. I have commented this to a friend and he recalls problems
similar to these with lstrip and rstrip a few years ago, so it might
have been an early 2.4 version or a late 2.3.
Thanks.
----------
components: Library (Lib)
messages: 82480
nosy: alexlc
severity: normal
status: open
title: strip, rstrip & lstrip bug
type: behavior
versions: Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5318>
_______________________________________
From report at bugs.python.org Thu Feb 19 18:38:01 2009
From: report at bugs.python.org (Mike Coleman)
Date: Thu, 19 Feb 2009 17:38:01 +0000
Subject: [New-bugs-announce] [issue5319] I/O error during one-liner fails to
return OS error status
In-Reply-To: <1235065081.04.0.732738239861.issue5319@psf.upfronthosting.co.za>
Message-ID: <1235065081.04.0.732738239861.issue5319@psf.upfronthosting.co.za>
New submission from Mike Coleman <mkc at users.sourceforge.net>:
$ python2.5 -c 'print((1, 2, 3))' > /dev/full || echo error status
close failed: [Errno 28] No space left on device
$
The above sequence should also output 'error status' before the next
prompt. That is, python should not be returning EXIT_SUCCESS in this
situation.
----------
messages: 82482
nosy: mkc
severity: normal
status: open
title: I/O error during one-liner fails to return OS error status
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5319>
_______________________________________
From report at bugs.python.org Thu Feb 19 18:45:15 2009
From: report at bugs.python.org (Mike Coleman)
Date: Thu, 19 Feb 2009 17:45:15 +0000
Subject: [New-bugs-announce] [issue5320] I/O error during one-liner gives
bad diagnostic (and fails to return OS error status)
In-Reply-To: <1235065515.6.0.55320178575.issue5320@psf.upfronthosting.co.za>
Message-ID: <1235065515.6.0.55320178575.issue5320@psf.upfronthosting.co.za>
New submission from Mike Coleman <mkc at users.sourceforge.net>:
$ python2.6 -c 'print 1, 2, 3' > /dev/full || echo error status
close failed in file object destructor:
Error in sys.excepthook:
Original exception was:
$
It seems like something other than blank lines should be printed here.
----------
components: Interpreter Core
messages: 82485
nosy: mkc
severity: normal
status: open
title: I/O error during one-liner gives bad diagnostic (and fails to return OS error status)
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5320>
_______________________________________
From report at bugs.python.org Thu Feb 19 18:50:04 2009
From: report at bugs.python.org (Mike Coleman)
Date: Thu, 19 Feb 2009 17:50:04 +0000
Subject: [New-bugs-announce] [issue5321] I/O error during one-liner gives no
(!) diagnostic (and fails to return OS error status)
In-Reply-To: <1235065804.66.0.913102056215.issue5321@psf.upfronthosting.co.za>
Message-ID: <1235065804.66.0.913102056215.issue5321@psf.upfronthosting.co.za>
New submission from Mike Coleman <mkc at users.sourceforge.net>:
$ python3.0 -c 'print((1, 2, 3))' > /dev/full || echo error status
$
This command gives no indication whatsoever that anything has gone
wrong. Following this with strace demonstrates that the interpreter is
in fact ignoring these errors:
2589 write(1, "(1, 2, 3)\n"..., 10) = -1 ENOSPC (No space left on
device)
2589 rt_sigaction(SIGINT, {SIG_DFL}, {0x47aa49, [], SA_RESTORER,
0x7fd5aa9da080}, 8) = 0
2589 write(1, "(1, 2, 3)\n"..., 10) = -1 ENOSPC (No space left on
device)
2589 write(1, "(1, 2, 3)\n"..., 10) = -1 ENOSPC (No space left on
device)
2589 write(1, "(1, 2, 3)\n"..., 10) = -1 ENOSPC (No space left on
device)
2589 exit_group(0) = ?
----------
components: Interpreter Core
messages: 82486
nosy: mkc
severity: normal
status: open
title: I/O error during one-liner gives no (!) diagnostic (and fails to return OS error status)
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5321>
_______________________________________
From report at bugs.python.org Thu Feb 19 21:34:25 2009
From: report at bugs.python.org (Armin Ronacher)
Date: Thu, 19 Feb 2009 20:34:25 +0000
Subject: [New-bugs-announce] [issue5322] Python 2.6 object.__new__ argument
calling autodetection faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
New submission from Armin Ronacher <armin.ronacher at active-4.com>:
In 2.6 a deprecation warning was added if `object.__new__` was called
with arguments. Per se this is fine, but the detection seems to be faulty.
The following code shows the problem:
>>> class A(object):
... def __new__(self):
... raise TypeError('i do not exist')
...
>>> class B(A):
... __new__ = object.__new__
... def __init__(self, x):
... self.x = x
...
>>> B(1)
__main__:1: DeprecationWarning: object.__new__() takes no parameters
<__main__.B object at 0x88dd0>
In the `B` case `__new__` is not overridden (in the sense that it
differs from object.__new__) but `__init__` is. Which is the default
behaviour. Nonetheless a warning is raised.
I used the pattern with the "__new__ switch" to achieve a
cStringIO.StringIO behavior that supports typechecks: IterIO() returns
either a IterI or IterO object, both instances of IterIO so that
typechecks can be performed.
Real-world use case here:
http://dev.pocoo.org/projects/werkzeug/browser/werkzeug/contrib/iterio.py
----------
messages: 82497
nosy: aronacher
severity: normal
status: open
title: Python 2.6 object.__new__ argument calling autodetection faulty
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5322>
_______________________________________
From report at bugs.python.org Thu Feb 19 22:36:10 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 19 Feb 2009 21:36:10 +0000
Subject: [New-bugs-announce] [issue5323] document expected/required behavior
of 3.x io subsystem with respect to buffering
In-Reply-To: <1235079370.71.0.9273857922.issue5323@psf.upfronthosting.co.za>
Message-ID: <1235079370.71.0.9273857922.issue5323@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
The python 3.x io library appears to allow mixing calls to __next__ and
calls to readline. As another consequence, where previously it was
necessary to use 'readline' to read single lines from a pipe without
blocking waiting for a buffer fill, now one can apparently use 'for'.
Reading the code in io.py, it seems as though this is intentional:
readline and __next__ use the same buffer, and the method on
TextIOWrapper that fills the buffer calls 'read1', which in the one
place where it has a docstring says that only as much data as is
available is read, in contrast to 'read', which reads exactly n bytes
(to EOF).
Assuming this is the intended behavior, it should be documented, and if
they do not exist (I didn't see any) tests should be added to confirm
the behavior. If this behavior is an implementation artifact, then this
should be documented so that code is less likely to depend on it.
Once I know whether or not this behavior _should_ be part of the test
suite, I'll be happy to work on doc and test patches.
----------
components: Library (Lib)
messages: 82499
nosy: bitdancer
severity: normal
status: open
title: document expected/required behavior of 3.x io subsystem with respect to buffering
type: behavior
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5323>
_______________________________________
From report at bugs.python.org Thu Feb 19 23:38:46 2009
From: report at bugs.python.org (Michael Foord)
Date: Thu, 19 Feb 2009 22:38:46 +0000
Subject: [New-bugs-announce] [issue5324] __subclasses__ undocumented
In-Reply-To: <1235083126.41.0.90704738838.issue5324@psf.upfronthosting.co.za>
Message-ID: <1235083126.41.0.90704738838.issue5324@psf.upfronthosting.co.za>
New submission from Michael Foord <michael at voidspace.org.uk>:
I can't find any documentation for the __subclasses__ magic method. At
the very least needed for language implementors.
----------
assignee: georg.brandl
components: Documentation
messages: 82504
nosy: georg.brandl, mfoord
severity: normal
status: open
title: __subclasses__ undocumented
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5324>
_______________________________________
From report at bugs.python.org Fri Feb 20 06:17:14 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 20 Feb 2009 05:17:14 +0000
Subject: [New-bugs-announce] [issue5325] "SyntaxError: None" when the name
of the dir contains non-ascii chars
In-Reply-To: <1235107034.92.0.375060629759.issue5325@psf.upfronthosting.co.za>
Message-ID: <1235107034.92.0.375060629759.issue5325@psf.upfronthosting.co.za>
New submission from Ezio Melotti <ezio.melotti at gmail.com>:
Step to reproduce:
1) create a directory with non-ascii chars in the name
2) create a python module with a syntax error (I used an unclosed '(')
3) execute the module.py directly ('module.py', not 'python module.py')
I tested this only on Windows, with Python3 as the default interpreter
used to execute *.py files, this is the output:
# ascii dir, works fine
D:\>module1.py
File "D:\module1.py", line 21
^
SyntaxError: invalid syntax
# moving to non-ascii dir
D:\>cd ???
# non ascii-dir, fails
D:\???>module1.py
SyntaxError: None
# here is using py2.6, but with 'python module1.py' it doesn't print the
dir name
D:\???>python module1.py
File "module1.py", line 21
^
SyntaxError: invalid syntax
# same as before but with py3
D:\???>python3 module1.py
File "module1.py", line 21
^
SyntaxError: invalid syntax
# with print(sys.version) in module1.py
D:\???>module1.py
3.0 (r30:67507, Dec 3 2008, 20:14:27) [MSC v.1500 32 bit (Intel)]
D:\???>python module1.py
2.6 (r26:66721, Oct 2 2008, 11:35:03) [MSC v.1500 32 bit (Intel)]
D:\???>python3 module1.py
3.0 (r30:67507, Dec 3 2008, 20:14:27) [MSC v.1500 32 bit (Intel)]
This seems to happen only with SyntaxErrors, I tested a couple of other
errors and it seems to work:
# with print(sys.version) and 5/0 in module1
# here it prints the dir name without problems (but it doesn't show '5/0')
D:\???>module1.py
3.0 (r30:67507, Dec 3 2008, 20:14:27) [MSC v.1500 32 bit (Intel)]
Traceback (most recent call last):
File "D:\???\module1.py", line 3, in <module>
ZeroDivisionError: int division or modulo by zero
D:\???>python module1.py
2.6 (r26:66721, Oct 2 2008, 11:35:03) [MSC v.1500 32 bit (Intel)]
Traceback (most recent call last):
File "module1.py", line 3, in <module>
5/0
ZeroDivisionError: integer division or modulo by zero
D:\???>python3 module1.py
3.0 (r30:67507, Dec 3 2008, 20:14:27) [MSC v.1500 32 bit (Intel)]
Traceback (most recent call last):
File "module1.py", line 3, in <module>
5/0
ZeroDivisionError: int division or modulo by zero
----------
components: Unicode
messages: 82513
nosy: ezio.melotti
severity: normal
status: open
title: "SyntaxError: None" when the name of the dir contains non-ascii chars
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5325>
_______________________________________
From report at bugs.python.org Fri Feb 20 07:54:34 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 20 Feb 2009 06:54:34 +0000
Subject: [New-bugs-announce] [issue5326] Wrong anchors in "What's New in
Python 2.5"
In-Reply-To: <1235112874.03.0.0364315281312.issue5326@psf.upfronthosting.co.za>
Message-ID: <1235112874.03.0.0364315281312.issue5326@psf.upfronthosting.co.za>
New submission from Ezio Melotti <ezio.melotti at gmail.com>:
Some anchors of the "What's New in Python 2.5" page [1] are wrong (both
in the table of contents and on the titles):
<li><a href="#module-ctypes">New, Improved, and Removed Modules</a><ul>
<li><a href="#module-etree">The ctypes package</a></li>
<li><a href="#module-hashlib">The ElementTree package</a></li>
<li><a href="#module-sqlite">The hashlib package</a></li>
<li><a href="#module-wsgiref">The sqlite3 package</a></li>
<li><a href="#the-wsgiref-package">The wsgiref package</a></li>
[1]: http://docs.python.org/whatsnew/2.5.html
----------
assignee: georg.brandl
components: Documentation
messages: 82516
nosy: ezio.melotti, georg.brandl
severity: normal
status: open
title: Wrong anchors in "What's New in Python 2.5"
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5326>
_______________________________________
From report at bugs.python.org Fri Feb 20 07:58:00 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 20 Feb 2009 06:58:00 +0000
Subject: [New-bugs-announce] [issue5327] Broken link in "What's New in
Python 2.5"
In-Reply-To: <1235113080.33.0.690725205717.issue5327@psf.upfronthosting.co.za>
Message-ID: <1235113080.33.0.690725205717.issue5327@psf.upfronthosting.co.za>
New submission from Ezio Melotti <ezio.melotti at gmail.com>:
The link in the second paragraph of "The ElementTree package" [1]
section of the "What's New in Python 2.5" page is broken.
[1]: http://docs.python.org/whatsnew/2.5.html#module-hashlib (the name
of this anchor is also wrong, see #5326)
----------
assignee: georg.brandl
components: Documentation
messages: 82517
nosy: ezio.melotti, georg.brandl
severity: normal
status: open
title: Broken link in "What's New in Python 2.5"
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5327>
_______________________________________
From report at bugs.python.org Fri Feb 20 09:49:52 2009
From: report at bugs.python.org (qwjqwj)
Date: Fri, 20 Feb 2009 08:49:52 +0000
Subject: [New-bugs-announce] [issue5328] Crash when doing some list iteration
In-Reply-To: <1235119792.92.0.916571758809.issue5328@psf.upfronthosting.co.za>
Message-ID: <1235119792.92.0.916571758809.issue5328@psf.upfronthosting.co.za>
New submission from qwjqwj <qwj at papayamobile.com>:
I am using the python 2.5.4 in redhat enterprise.
My project is a big one with turbogears and sqlobject. The python core
dumped sometime when iterating list. It occurs randomly and cannot be
reproduced.
After using gdb, I found python core dumped at this line in the lambda
unnamed function:
newsfeeds = filter(lambda x: not(x.activity==0 and
x.value.get('uid')==sess.user.id),n)[:5]
The core dump info is as followed:
#0 listiter_next (it=0xa2988ecc) at Objects/listobject.c:2819
#1 0x08079e56 in listextend (self=0xa91f90c, b=<value optimized out>)
at Objects/listobject.c:823
#2 0x0807a370 in list_init (self=0xa91f90c, args=0xb64c6ec, kw=0x0) at
Objects/listobject.c:2391
#3 0x0809bfe3 in type_call (type=0x8140220, args=0xb64c6ec, kwds=0x0)
at Objects/typeobject.c:436
#4 0x0805a5f7 in PyObject_Call (func=0xb47cc6c, arg=0xb64c6ec, kw=0x0)
at Objects/abstract.c:1861
#5 0x080c16a2 in PyEval_EvalFrameEx (f=0xa2649aec, throwflag=0) at
Python/ceval.c:3823
#6 0x080c7765 in PyEval_EvalCodeEx (co=0x9929a88, globals=0x9907b54,
locals=0x0, args=0xb52fe58,
argcount=1, kws=0x9f98ae0, kwcount=2, defs=0x991ed38, defcount=2,
closure=0x0) at Python/ceval.c:2875
#7 0x0810f0ba in function_call (func=0x9f32b54, arg=0xb52fe4c,
kw=0xa27b679c)
at Objects/funcobject.c:517
#8 0x0805a5f7 in PyObject_Call (func=0xb47cc6c, arg=0xb52fe4c,
kw=0xa27b679c) at Objects/abstract.c:1861
#9 0x080c46dd in PyEval_EvalFrameEx (f=0xac6737c, throwflag=0) at
Python/ceval.c:3892
#10 0x080c7765 in PyEval_EvalCodeEx (co=0x89bce30, globals=0x8ac702c,
locals=0x0, args=0xa14d6418,
argcount=2, kws=0xa3c2ba0, kwcount=2, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2875
#11 0x0810f0ba in function_call (func=0x8acf144, arg=0xa14d640c,
kw=0xa27b69bc)
at Objects/funcobject.c:517
#12 0x0805a5f7 in PyObject_Call (func=0xb47cc6c, arg=0xa14d640c,
kw=0xa27b69bc)
at Objects/abstract.c:1861
#13 0x080c46dd in PyEval_EvalFrameEx (f=0xac671ec, throwflag=0) at
Python/ceval.c:3892
#14 0x080c6410 in PyEval_EvalFrameEx (f=0xacf7c1c, throwflag=0) at
Python/ceval.c:3698
#15 0x080c7765 in PyEval_EvalCodeEx (co=0x84e1da0, globals=0x84d8acc,
locals=0x0, args=0xa0d144e8,
argcount=4, kws=0x9d850e8, kwcount=2, defs=0x0, defcount=0,
closure=0x9f3944c) at Python/ceval.c:2875
#16 0x0810f0ba in function_call (func=0x9f32cdc, arg=0xa0d144dc,
kw=0x9a22824)
at Objects/funcobject.c:517
#17 0x0805a5f7 in PyObject_Call (func=0xb47cc6c, arg=0xa0d144dc,
kw=0x9a22824) at Objects/abstract.c:1861
#18 0x080c46dd in PyEval_EvalFrameEx (f=0xa2304ba4, throwflag=0) at
Python/ceval.c:3892
#19 0x080c7765 in PyEval_EvalCodeEx (co=0x9dcf890, globals=0x857ebdc,
locals=0x0, args=0xbb7b5b0,
argcount=4, kws=0x9b82858, kwcount=2, defs=0x0, defcount=0,
closure=0x9ebf10c) at Python/ceval.c:2875
#20 0x0810f0ba in function_call (func=0xa40de64, arg=0xbb7b5a4,
kw=0xa27b6604)
at Objects/funcobject.c:517
#21 0x0805a5f7 in PyObject_Call (func=0xb47cc6c, arg=0xbb7b5a4,
kw=0xa27b6604) at Objects/abstract.c:1861
#22 0x080c46dd in PyEval_EvalFrameEx (f=0x9c7b0d4, throwflag=0) at
Python/ceval.c:3892
#23 0x080c7765 in PyEval_EvalCodeEx (co=0x89ade30, globals=0x89b7acc,
locals=0x0, args=0xa275a248,
argcount=5, kws=0x9c8e838, kwcount=2, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2875
----------
components: None
messages: 82522
nosy: qwjqwj
severity: normal
status: open
title: Crash when doing some list iteration
type: crash
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5328>
_______________________________________
From report at bugs.python.org Fri Feb 20 10:14:05 2009
From: report at bugs.python.org (Jani Hakala)
Date: Fri, 20 Feb 2009 09:14:05 +0000
Subject: [New-bugs-announce] [issue5329] os.popen2 and os.popen3 in python
2.6 incompatible with os.popen* in python 2.5
In-Reply-To: <1235121245.47.0.613044216429.issue5329@psf.upfronthosting.co.za>
Message-ID: <1235121245.47.0.613044216429.issue5329@psf.upfronthosting.co.za>
New submission from Jani Hakala <jahakala at iki.fi>:
The implementation in python 2.6 expects the cmd argument to be a string.
The documentation - help(os.popen3) - states that the cmd argument can
be a sequence on Unix.
This difference may cause programs that work with python 2.5 to fail
with python 2.6
I have tested the patch attached with one of my scripts that failed with
python 2.6 and the fix appears to work.
----------
components: Library (Lib)
files: os-popen.diff
keywords: patch
messages: 82523
nosy: jahakala
severity: normal
status: open
title: os.popen2 and os.popen3 in python 2.6 incompatible with os.popen* in python 2.5
versions: Python 2.6
Added file: http://bugs.python.org/file13140/os-popen.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5329>
_______________________________________
From report at bugs.python.org Fri Feb 20 14:10:20 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Fri, 20 Feb 2009 13:10:20 +0000
Subject: [New-bugs-announce] [issue5330] profile and cProfile do not report
C functions called with keyword arguments
In-Reply-To: <1235135420.93.0.617344393794.issue5330@psf.upfronthosting.co.za>
Message-ID: <1235135420.93.0.617344393794.issue5330@psf.upfronthosting.co.za>
New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:
A C function or method call without keyword arguments gets reported by
the profiler as expected (in the line with "{method 'sort' of 'list'
object}"):
>>> cProfile.run("[].sort()")
4 function calls in 0.000 CPU seconds
Ordered by: standard name
ncalls tottime percall cumtime percall filename:lineno(function)
1 0.000 0.000 0.000 0.000 <string>:1(<module>)
1 0.000 0.000 0.000 0.000 {built-in method exec}
1 0.000 0.000 0.000 0.000 {method 'disable' of
'_lsprof.Profiler' objects}
1 0.000 0.000 0.000 0.000 {method 'sort' of 'list'
objects}
However, once a keyword argument is given, the relevant line is missing:
>>> cProfile.run("[].sort(reverse=True)")
3 function calls in 0.000 CPU seconds
Ordered by: standard name
ncalls tottime percall cumtime percall filename:lineno(function)
1 0.000 0.000 0.000 0.000 <string>:1(<module>)
1 0.000 0.000 0.000 0.000 {built-in method exec}
1 0.000 0.000 0.000 0.000 {method 'disable' of
'_lsprof.Profiler' objects}
This happens with profile and cProfile in 2.6 and 3.0.
----------
components: Library (Lib)
messages: 82530
nosy: hagen
severity: normal
status: open
title: profile and cProfile do not report C functions called with keyword arguments
type: behavior
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5330>
_______________________________________
From report at bugs.python.org Fri Feb 20 17:07:08 2009
From: report at bugs.python.org (mike bayer)
Date: Fri, 20 Feb 2009 16:07:08 +0000
Subject: [New-bugs-announce] [issue5331] multiprocessing hangs when Pool
used within Process
In-Reply-To: <1235146028.47.0.682929217877.issue5331@psf.upfronthosting.co.za>
Message-ID: <1235146028.47.0.682929217877.issue5331@psf.upfronthosting.co.za>
New submission from mike bayer <mike_mp at zzzcomputing.com>:
this occurs for me running on Mac OSX Leopard. The equivalent code
using "processing" in python 2.5 works fine, which is how I found this
bug - my code hung when upgraded to 2.6. Basically initiating a
multiprocessing.Pool inside of multiprocessing.Process hangs the
application. Below is code which illustrates the issue on both py2.6
and py3.0:
from multiprocessing import Pool, Process
import sys
def f(x):
return x*x
def go():
pool = Pool(processes=4)
x = pool.map(f, [1, 2, 3, 4, 5, 6, 7])
sys.stdout.write("result: %s\n" % x)
def go2():
x = map(f, [1,2,3,4,5,6,7])
sys.stdout.write("result: %s\n" % x)
# pool alone, fine
go()
# process alone, fine
p = Process(target=go2)
p.start()
p.join()
# use both, hangs
p = Process(target=go)
p.start()
p.join()
----------
components: Library (Lib)
messages: 82534
nosy: zzzeek
severity: normal
status: open
title: multiprocessing hangs when Pool used within Process
type: crash
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5331>
_______________________________________
From report at bugs.python.org Fri Feb 20 21:45:33 2009
From: report at bugs.python.org (David W. Lambert)
Date: Fri, 20 Feb 2009 20:45:33 +0000
Subject: [New-bugs-announce] [issue5332] csv sniffer
In-Reply-To: <1235162733.25.0.482513842524.issue5332@psf.upfronthosting.co.za>
Message-ID: <1235162733.25.0.482513842524.issue5332@psf.upfronthosting.co.za>
New submission from David W. Lambert <lambertdw at corning.com>:
Following instructions in
http://docs.python.org/dev/3.0/library/csv.html#module-csv
I opened file in binary mode. This might be simply a documentation
problem or it may run deeper. Text mode works on red hat linux system.
Here's the use:
>>> stream=open('csv','rb')
>>> dialect=csv.Sniffer().sniff(stream.read(1024))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/users/lambert/bin/python/lib/python3.0/csv.py", line 169,
in sniff
self._guess_quote_and_delimiter(sample, delimiters)
File "/usr/users/lambert/bin/python/lib/python3.0/csv.py", line 210,
in _guess_quote_and_delimiter
matches = regexp.findall(data)
TypeError: can't use a string pattern on a bytes-like object
Here's the conflicting documentation statement:
"If csvfile is a file object, it must be opened with the ?b? flag on
platforms where that makes a difference. ... see section Dialects and
Formatting Parameters.
All data read are returned as strings. No automatic data type conversion
is performed."
(Problem is that the binary file returnd data of type bytes.)
Thanks, Dave.
----------
components: Library (Lib)
messages: 82546
nosy: LambertDW
severity: normal
status: open
title: csv sniffer
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5332>
_______________________________________
From report at bugs.python.org Fri Feb 20 22:51:51 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 20 Feb 2009 21:51:51 +0000
Subject: [New-bugs-announce] [issue5333] os.kill() inconsistency
In-Reply-To: <1235166711.41.0.166565157131.issue5333@psf.upfronthosting.co.za>
Message-ID: <1235166711.41.0.166565157131.issue5333@psf.upfronthosting.co.za>
New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:
On Linux Ubuntu equipped with Python 2.6.1 I get this:
>>> os.kill(99999, 0)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
OSError: [Errno 3] No such process
>>> print os.kill(-1, 0)
None
>>>
IMHO the latter case should raise "No such process" for consistency or,
at least ValueError, but surely not returning None.
----------
messages: 82549
nosy: giampaolo.rodola
severity: normal
status: open
title: os.kill() inconsistency
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5333>
_______________________________________
From report at bugs.python.org Sat Feb 21 05:08:13 2009
From: report at bugs.python.org (Zac Medico)
Date: Sat, 21 Feb 2009 04:08:13 +0000
Subject: [New-bugs-announce] [issue5334] array.fromfile() fails to insert
values when EOFError is raised
In-Reply-To: <1235189293.4.0.0829880938906.issue5334@psf.upfronthosting.co.za>
Message-ID: <1235189293.4.0.0829880938906.issue5334@psf.upfronthosting.co.za>
New submission from Zac Medico <zmedico at gentoo.org>:
With python-3.0, array.fromfile() fails to insert values when EOFError
is raised. I ran the attached test case with python-3.0.1 and got the
same result on both linux and windows. With python-2.x, the values are
properly inserted despite an EOFError, as the documentation states it
should:
array.fromfile(f, n)
Read n items (as machine values) from the file object f and append them
to the end of the array. If less than n items are available, EOFError is
raised, but the items that were available are still inserted into the
array. f must be a real built-in file object; something else with a
read() method won?t do.
----------
components: Library (Lib)
files: fromfile_eof.py
messages: 82558
nosy: zmedico
severity: normal
status: open
title: array.fromfile() fails to insert values when EOFError is raised
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file13143/fromfile_eof.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5334>
_______________________________________
From report at bugs.python.org Sat Feb 21 07:24:57 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 21 Feb 2009 06:24:57 +0000
Subject: [New-bugs-announce] [issue5335] mmap can crash with tagname (on
windows)
In-Reply-To: <1235197497.51.0.948926672219.issue5335@psf.upfronthosting.co.za>
Message-ID: <1235197497.51.0.948926672219.issue5335@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
I noticed following code crashes on windows. Attached patch will fix this.
/////////////////////////////////////
// Crash code
import mmap, tempfile
f = tempfile.TemporaryFile()
m1 = mmap.mmap(f.fileno(), 1000, tagname="foo")
m2 = mmap.mmap(f.fileno(), 5000, tagname="foo") # use same tagname, but
larger size
print len(m2[:]) # crash
/////////////////////////////////////
// After patch applied
Traceback (most recent call last):
File "b.py", line 4, in <module>
m2 = mmap.mmap(f.fileno(), 5000, tagname="foo")
WindowsError: [Error 5] ?????????????(Access Denied)
[15495 refs]
/////////////////////////////////////
Calling MapViewOfFile with size 0 means "map entire file", so
m2 = mmap.mmap(f.fileno(), 5000, tagname="foo")
maps existing memory region sized 1000. But mmap thinks its size is
5000, no IndexError raised, and accessed illegal memory area and crashes.
----------
components: Extension Modules, Windows
files: fix_tagname_crash.patch
keywords: patch
messages: 82561
nosy: ocean-city
severity: normal
status: open
title: mmap can crash with tagname (on windows)
type: crash
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13145/fix_tagname_crash.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5335>
_______________________________________
From report at bugs.python.org Sat Feb 21 10:24:53 2009
From: report at bugs.python.org (Mikhail Bessonov)
Date: Sat, 21 Feb 2009 09:24:53 +0000
Subject: [New-bugs-announce] [issue5336] collections.namedtuple generates
code causing PyChecker warnings
In-Reply-To: <1235208293.75.0.0186544029799.issue5336@psf.upfronthosting.co.za>
Message-ID: <1235208293.75.0.0186544029799.issue5336@psf.upfronthosting.co.za>
New submission from Mikhail Bessonov <zahoo at mail.ru>:
The first argument of some methods generated by collections.namedtuple
differs from 'self'. It upsets a number of code checkers, notably
PyChecker, because in most cases it is indeed an error. As a result,
the code using collections.namedtuple does not pass PyChecker, which is
a commit or release requirement in many projects.
The solution would be to rename the first argument of each method to
'self'.
A sample 2-line program demonstrating the error is provided below.
import collections
DocRecord = collections.namedtuple('DocRecord', 'id, date, name, desc',
verbose = True)
Here's the PyChecker output. Methods that cause trouble are 'def _asdict
(t):', etc.
E:\src\mini-crawler>E:\Python26\python.exe E:\Python26\Lib\site-packages
\pychecker\checker.py test.py
class DocRecord(tuple):
'DocRecord(id, date, name, desc)'
__slots__ = ()
_fields = ('id', 'date', 'name', 'desc')
def __new__(cls, id, date, name, desc):
return tuple.__new__(cls, (id, date, name, desc))
@classmethod
def _make(cls, iterable, new=tuple.__new__, len=len):
'Make a new DocRecord object from a sequence or iterable'
result = new(cls, iterable)
if len(result) != 4:
raise TypeError('Expected 4 arguments, got %d' % len
(result))
return result
def __repr__(self):
return 'DocRecord(id=%r, date=%r, name=%r, desc=%r)' % self
def _asdict(t):
'Return a new dict which maps field names to their values'
return {'id': t[0], 'date': t[1], 'name': t[2], 'desc': t
[3]}
def _replace(self, **kwds):
'Return a new DocRecord object replacing specified fields
with new values'
result = self._make(map(kwds.pop, ('id', 'date', 'name',
'desc'), self))
if kwds:
raise ValueError('Got unexpected field names: %r' %
kwds.keys())
return result
def __getnewargs__(self):
return tuple(self)
id = property(itemgetter(0))
date = property(itemgetter(1))
name = property(itemgetter(2))
desc = property(itemgetter(3))
Warnings...
<string>:22: self is not first method argument
----------
components: Library (Lib)
messages: 82562
nosy: mbessonov
severity: normal
status: open
title: collections.namedtuple generates code causing PyChecker warnings
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5336>
_______________________________________
From report at bugs.python.org Sat Feb 21 17:56:06 2009
From: report at bugs.python.org (Michael Foord)
Date: Sat, 21 Feb 2009 16:56:06 +0000
Subject: [New-bugs-announce] [issue5337] Scanner class in re module
undocumented
In-Reply-To: <1235235366.45.0.579114073683.issue5337@psf.upfronthosting.co.za>
Message-ID: <1235235366.45.0.579114073683.issue5337@psf.upfronthosting.co.za>
New submission from Michael Foord <michael at voidspace.org.uk>:
There is a useful Scanner class in the re module which is undocumented.
See:
http://mail.python.org/pipermail/python-dev/2003-April/035075.html
http://www.evanfosmark.com/2009/02/sexy-lexing-with-python/
----------
assignee: georg.brandl
components: Documentation
messages: 82569
nosy: georg.brandl, mfoord
severity: normal
status: open
title: Scanner class in re module undocumented
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5337>
_______________________________________
From report at bugs.python.org Sat Feb 21 18:52:18 2009
From: report at bugs.python.org (Ruth Aydt)
Date: Sat, 21 Feb 2009 17:52:18 +0000
Subject: [New-bugs-announce] [issue5338] Typo in Python/C API sect 1.2.1
In-Reply-To: <1235238738.44.0.78137346389.issue5338@psf.upfronthosting.co.za>
Message-ID: <1235238738.44.0.78137346389.issue5338@psf.upfronthosting.co.za>
New submission from Ruth Aydt <aydt at hdfgroup.org>:
In Section 1.2.1 of the 2.6.1 Python/C API documentation, I believe
there is a typo.
First sentence in second paragraph in "Reference Count Details" subsection.
"... function passes it a reference..." should be
"... function passes in a reference..."
----------
assignee: georg.brandl
components: Documentation
messages: 82571
nosy: aydt, georg.brandl
severity: normal
status: open
title: Typo in Python/C API sect 1.2.1
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5338>
_______________________________________
From report at bugs.python.org Sat Feb 21 20:04:31 2009
From: report at bugs.python.org (Ruth Aydt)
Date: Sat, 21 Feb 2009 19:04:31 +0000
Subject: [New-bugs-announce] [issue5339] Typo in Python/C API Chapter 2
In-Reply-To: <1235243071.29.0.696481689221.issue5339@psf.upfronthosting.co.za>
Message-ID: <1235243071.29.0.696481689221.issue5339@psf.upfronthosting.co.za>
New submission from Ruth Aydt <aydt at hdfgroup.org>:
Python/C API Documentation for 2.6.1
Chapter 2, 3rd paragraph.
"On particular issue..." should be "One particular issue..."
----------
assignee: georg.brandl
components: Documentation
messages: 82572
nosy: aydt, georg.brandl
severity: normal
status: open
title: Typo in Python/C API Chapter 2
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5339>
_______________________________________
From report at bugs.python.org Sat Feb 21 20:11:52 2009
From: report at bugs.python.org (Bob Kline)
Date: Sat, 21 Feb 2009 19:11:52 +0000
Subject: [New-bugs-announce] [issue5340] Change in cgi behavior breaks
existing software
In-Reply-To: <1235243512.17.0.731468064037.issue5340@psf.upfronthosting.co.za>
Message-ID: <1235243512.17.0.731468064037.issue5340@psf.upfronthosting.co.za>
New submission from Bob Kline <bkline at rksystems.com>:
We just upgraded Python to 2.6 on some of our servers and a number of
our CGI scripts broke because the cgi module has changed the way it
handles POST requests. When the 'action' attribute was not present in
the form element on an HTML page the module behaved as if the value of
the attribute was the URL which brought the user to the page with the
form, but without the query (?x=y...) part. Now FieldStorage.getvalue()
is giving the script a list of two copies of the value for some of the
parameters (folding in the parameters from the previous request) instead
of the single string it used to return for each. I searched the python
mailing list looking for a discussion of the proposal to impose this
change of behavior, and perhaps I wasn't using the right phrases in my
search, but I didn't find anything. I didn't get many responses when I
asked for pointers to this discussion, but the few I did get were from
people who were as surprised as we were. It's not clear to us (or to
those who responded on the mailing list) that the applicable RFCs
provide completely clear and unambiguous guidance as to which behavior
is correct, but even if the new behavior is correct, it is unusual to
have changes to the library which break existing code introduced without
any discussion of the impact, or transition period, or options to
preserve the previous behavior. For what it's worth, it appears that
Perl and PHP (which probably account for the bulk of non-Python CGI
scripts in the wild) both behave the way the pre-2.6 cgi module did. We
have a workaround (modify all our CGI scripts to explicitly set the
action attribute without the parameter suffix), but I was asked by one
of the regulars on the mailing list to file a bug report here, so I'm
complying with that request.
It appears that the breaking change was introduced with
http://svn.python.org/view?rev=64447&view=rev in connection with
http://bugs.python.org/issue1817.
See
http://mail.python.org/pipermail/python-list/2009-February/529130.html
for repro instructions.
----------
components: Library (Lib)
messages: 82575
nosy: bkline
severity: normal
status: open
title: Change in cgi behavior breaks existing software
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5340>
_______________________________________
From report at bugs.python.org Sat Feb 21 20:24:10 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 21 Feb 2009 19:24:10 +0000
Subject: [New-bugs-announce] [issue5341] A selection of spelling errors and
typos throughout source
In-Reply-To: <1235244250.3.0.963079671793.issue5341@psf.upfronthosting.co.za>
Message-ID: <1235244250.3.0.963079671793.issue5341@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
Here's a patch that represents the result of grepping through the source
for some of my favo(u)rite spelling errors.
Georg, I reali(z/s)e that most of these fixes are outside the Doc/
directory, but are you interested in taking a look at these? Please
unassign if not.
Two notes:
- I'm pretty sure that all of these are genuine errors. The only one
that may be controversial is 'builtin -> built-in' (when used as an
adjective). The 'Apple Publications Style Guide' seems to use built-in in
preference to builtin. I also think I missed a few of these.
- My (American English) spell-checker complains about 'signalled', but it
looks fine when I put my British English eyes in. The docs contain
instances of both 'signalled' *and* 'signaled'. Is there any consensus on
whether American English or British English should be used for Python's
documentation? (Should also check for 'signalling' versus 'signaling'.)
----------
assignee: georg.brandl
components: Documentation
files: spellings.patch
keywords: patch
messages: 82577
nosy: georg.brandl, marketdickinson
priority: low
severity: normal
status: open
title: A selection of spelling errors and typos throughout source
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13147/spellings.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5341>
_______________________________________
From report at bugs.python.org Sat Feb 21 23:43:50 2009
From: report at bugs.python.org (Rene Dudfield)
Date: Sat, 21 Feb 2009 22:43:50 +0000
Subject: [New-bugs-announce] [issue5342] distutils removing old files,
deleting unneeded old files from installed location.
In-Reply-To: <1235256230.9.0.667035234316.issue5342@psf.upfronthosting.co.za>
Message-ID: <1235256230.9.0.667035234316.issue5342@psf.upfronthosting.co.za>
New submission from Rene Dudfield <illume at users.sourceforge.net>:
A common problem is removing old files from the installed location.
eg.
version 1 installs.
site-packages/packagename/bla.so
version 2 installs.
site-packages/packagename/_bla.so
site-packages/packagename/bla.py
However, in version 2 if we install over the top of version 1, distutils
does not remove bla.so. Which causes the package to break because
bla.so will be used instead of bla.py
distutils should be able to be given a list of old files to make sure
are removed from the package.
It should work with the various installers... msi, dmg etc, as well as
when using setup.py install.
I've seen this cause breakage with numerous packages. The solution is
to hack some old file detection into each package, or tell users 'delete
the old install first'. Neither of which is really nice.
Specifying an old_files meta data should be able to help.
----------
assignee: tarek
components: Distutils
messages: 82586
nosy: illume, tarek
severity: normal
status: open
title: distutils removing old files, deleting unneeded old files from installed location.
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5342>
_______________________________________
From report at bugs.python.org Sun Feb 22 03:34:06 2009
From: report at bugs.python.org (rocky bernstein)
Date: Sun, 22 Feb 2009 02:34:06 +0000
Subject: [New-bugs-announce] [issue5343] remove or make work pdb retval and
rv
In-Reply-To: <1235270046.51.0.683603570643.issue5343@psf.upfronthosting.co.za>
Message-ID: <1235270046.51.0.683603570643.issue5343@psf.upfronthosting.co.za>
New submission from rocky bernstein <rocky at gnu.org>:
Remove pdb's undocumented"retval"/"rv" debugger commands.
It is conceivable this may have once worked on a version of Python long
ago, but not in recent releases. If it's of interest to make this work,
one approach would be to use the arg parameter passed into
trace_dispatch when the event type is "return".
----------
components: Library (Lib)
messages: 82591
nosy: rocky
severity: normal
status: open
title: remove or make work pdb retval and rv
type: behavior
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5343>
_______________________________________
From report at bugs.python.org Sun Feb 22 06:33:03 2009
From: report at bugs.python.org (George Yoshida)
Date: Sun, 22 Feb 2009 05:33:03 +0000
Subject: [New-bugs-announce] [issue5344] typo in what's new in 2.6
In-Reply-To: <1235280783.4.0.127684733188.issue5344@psf.upfronthosting.co.za>
Message-ID: <1235280783.4.0.127684733188.issue5344@psf.upfronthosting.co.za>
New submission from George Yoshida <quiver at users.sourceforge.net>:
In "What's new in 2.6" PEP 343 section, the following sentence lacks a
closing parenthesis:
> The expression is evaluated, and it should result in an object that
supports the context management protocol (that is, has __enter__() and
__exit__() methods.
http://docs.python.org/whatsnew/2.6.html#pep-343-the-with-statement
Patch attached
----------
assignee: georg.brandl
components: Documentation
files: whatsnew.diff
keywords: patch, patch
messages: 82593
nosy: georg.brandl, quiver
priority: low
severity: normal
status: open
title: typo in what's new in 2.6
versions: Python 2.6
Added file: http://bugs.python.org/file13148/whatsnew.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5344>
_______________________________________
From report at bugs.python.org Sun Feb 22 08:09:37 2009
From: report at bugs.python.org (qwjqwj)
Date: Sun, 22 Feb 2009 07:09:37 +0000
Subject: [New-bugs-announce] [issue5345] cStringIO class name typo
In-Reply-To: <1235286577.45.0.856937584355.issue5345@psf.upfronthosting.co.za>
Message-ID: <1235286577.45.0.856937584355.issue5345@psf.upfronthosting.co.za>
New submission from qwjqwj <qwj at papayamobile.com>:
It has a typo error in cStringIO.StringIO's class name "StringO":
>>> import cStringIO
>>> a=cStringIO.StringIO()
>>> a
<cStringIO.StringO object at 0xb7eef240>
>>> a.__class__.__name__
'StringO'
So we can't unpickle the object correctly with Python 2.5.4:
>>> import pickle
>>> pickle.loads(pickle.dumps(a))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python2.5/pickle.py", line 1366, in dumps
Pickler(file, protocol).dump(obj)
File "/usr/local/lib/python2.5/pickle.py", line 224, in dump
self.save(obj)
File "/usr/local/lib/python2.5/pickle.py", line 306, in save
rv = reduce(self.proto)
File "/usr/local/lib/python2.5/copy_reg.py", line 69, in _reduce_ex
raise TypeError, "can't pickle %s objects" % base.__name__
TypeError: can't pickle StringO objects
When using multiprocess library, it also use the pickling and unpickling
of cStringIO.StringIO object
----------
components: Library (Lib)
messages: 82595
nosy: qwjqwj
severity: normal
status: open
title: cStringIO class name typo
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5345>
_______________________________________
From report at bugs.python.org Sun Feb 22 16:48:41 2009
From: report at bugs.python.org (Andrey Rahmatullin)
Date: Sun, 22 Feb 2009 15:48:41 +0000
Subject: [New-bugs-announce] [issue5346] mailbox._singlefileMailbox.flush
doesn't preserve file rights
In-Reply-To: <1235317721.52.0.542523133974.issue5346@psf.upfronthosting.co.za>
Message-ID: <1235317721.52.0.542523133974.issue5346@psf.upfronthosting.co.za>
New submission from Andrey Rahmatullin <wrar at altlinux.org>:
Mbox file is recreated during flush(), so the new file has access
rights according to umask, which is not necessarily the same as of the
old file.
----------
components: Library (Lib)
messages: 82604
nosy: wRAR
severity: normal
status: open
title: mailbox._singlefileMailbox.flush doesn't preserve file rights
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5346>
_______________________________________
From report at bugs.python.org Sun Feb 22 21:48:57 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Feb 2009 20:48:57 +0000
Subject: [New-bugs-announce] [issue5347] SocketIO redefines RawIOBase.__del__
In-Reply-To: <1235335737.36.0.938814537211.issue5347@psf.upfronthosting.co.za>
Message-ID: <1235335737.36.0.938814537211.issue5347@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
SocketIO defines its own __del__ while it could simply rely on
IOBase.__del__ to do the right thing.
I'm saying this because in the C version of the io lib, there is no
__del__ anymore, so that SocketIO objects caught in a ref cycle wouldn't
block the GC from collecting the objects.
----------
components: Library (Lib)
messages: 82609
nosy: pitrou
priority: normal
severity: normal
status: open
title: SocketIO redefines RawIOBase.__del__
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5347>
_______________________________________
From report at bugs.python.org Mon Feb 23 03:17:04 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 23 Feb 2009 02:17:04 +0000
Subject: [New-bugs-announce] [issue5348] Documentation of format implies
only strings and numbers are acceptable arguments
In-Reply-To: <1235355424.94.0.761283405587.issue5348@psf.upfronthosting.co.za>
Message-ID: <1235355424.94.0.761283405587.issue5348@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
The documentation of format on the builtin functions page should be
changed from "Convert a string or a number" to "Convert a value".
The documentation begins "Convert a string or a number". This is
misleading in that format can be called on any value, since there is an
Object.__format__ and classes can define their own __format__ method.
PEP 3101 is explicit about all of this and the documentation of
__format__ ends by noting that "format(value, format_spec) merely calls
value.__format__(format_spec)". typeobject.c implements
Object.__format__ with a note about PEP 3101.
Given all of that I don't see why format should be explained as taking a
string or a number as its first argument.
----------
assignee: georg.brandl
components: Documentation
messages: 82616
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Documentation of format implies only strings and numbers are acceptable arguments
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5348>
_______________________________________
From report at bugs.python.org Mon Feb 23 06:11:38 2009
From: report at bugs.python.org (Jared Grubb)
Date: Mon, 23 Feb 2009 05:11:38 +0000
Subject: [New-bugs-announce] [issue5349] abstractmethod vs C++ pure virtual
In-Reply-To: <1235365898.93.0.530994283024.issue5349@psf.upfronthosting.co.za>
Message-ID: <1235365898.93.0.530994283024.issue5349@psf.upfronthosting.co.za>
New submission from Jared Grubb <python at jaredgrubb.com>:
On page library/abc.html documenting abc.abstractmethod, the following
text about C++ is placed in a note:
"Note: Unlike C++?s pure virtual functions, or Java abstract methods,
these abstract methods may have an implementation. This implementation
can be called via the super() mechanism from the class that overrides
it. This could be useful as an end-point for a super-call in a framework
that uses cooperative multiple-inheritance."
This is not an accurate description of C++'s pure virtual functions.
Pure virtual functions CAN have an implementation, which can be called
from derived classes; this makes them behave just like Python's
abstractmethod.
Example:
struct Abstract {
virtual void foo() = 0;
};
void Abstract::foo() {
std::cout << "pure virtual function called";
}
struct Derived : public Abstract {
virtual void foo() {
Abstract::foo(); // call the abstract impl
}
};
----------
assignee: georg.brandl
components: Documentation
messages: 82618
nosy: georg.brandl, jaredgrubb
severity: normal
status: open
title: abstractmethod vs C++ pure virtual
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5349>
_______________________________________
From report at bugs.python.org Mon Feb 23 14:37:12 2009
From: report at bugs.python.org (Matteo Dell'Amico)
Date: Mon, 23 Feb 2009 13:37:12 +0000
Subject: [New-bugs-announce] [issue5350] Modification to "pairwise" in
itertools recipes
In-Reply-To: <1235396232.5.0.669256244116.issue5350@psf.upfronthosting.co.za>
Message-ID: <1235396232.5.0.669256244116.issue5350@psf.upfronthosting.co.za>
New submission from Matteo Dell'Amico <della at linux.it>:
I feel that the "pairwise" recipe could be slightly more elegant if "for
elem in b: break" became a simpler next(b) (or b.next() for Python 2.x).
It is also more natural to modify the recipes to suit one's needs (e.g.,
returning items with a given gap between them, or convert the recipe to
k-wise iteration).
----------
assignee: georg.brandl
components: Documentation
messages: 82626
nosy: della, georg.brandl
severity: normal
status: open
title: Modification to "pairwise" in itertools recipes
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5350>
_______________________________________
From report at bugs.python.org Mon Feb 23 14:45:35 2009
From: report at bugs.python.org (Tsue)
Date: Mon, 23 Feb 2009 13:45:35 +0000
Subject: [New-bugs-announce] [issue5351] Python tutorial error
In-Reply-To: <1235396735.05.0.192999547844.issue5351@psf.upfronthosting.co.za>
Message-ID: <1235396735.05.0.192999547844.issue5351@psf.upfronthosting.co.za>
New submission from Tsue <tsuedesu at gmail.com>:
Hi,
Dont know if this is the right place for this kind of bug report. I just
started with python last week, so I've been using the Built in tutorial.
However, I came across a major issue, and though it took me a while, I
figured it out.
The excersise on Reading and Writing Files isnt very clear on the object
f. And it isnt even stated, that the use of 'w' in the code will
actually over right the file, not append to it. Which didnt seem
logical, but I guess thats why 'r+' is there.
Please correct this in the docs, its a bit frustrating for a nooob.
----------
components: None
messages: 82628
nosy: Tsuedesu
severity: normal
status: open
title: Python tutorial error
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5351>
_______________________________________
From report at bugs.python.org Mon Feb 23 16:47:09 2009
From: report at bugs.python.org (Matteo Dell'Amico)
Date: Mon, 23 Feb 2009 15:47:09 +0000
Subject: [New-bugs-announce] [issue5352] Missing 'non overlapping' clause in
str.count documentation
In-Reply-To: <1235404029.66.0.0650710952765.issue5352@psf.upfronthosting.co.za>
Message-ID: <1235404029.66.0.0650710952765.issue5352@psf.upfronthosting.co.za>
New submission from Matteo Dell'Amico <della at linux.it>:
The str.count (http://docs.python.org/dev/py3k/library/stdtypes.html)
documentation does not report that it returns the number of
*non-overlapping* instances. For example, I expected 'aaa'.count('aa')
to be 2 and not 1. Compare this with the string module documentation,
where the non-overlapping clause is reported.
----------
assignee: georg.brandl
components: Documentation
messages: 82632
nosy: della, georg.brandl
severity: normal
status: open
title: Missing 'non overlapping' clause in str.count documentation
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5352>
_______________________________________
From report at bugs.python.org Mon Feb 23 19:38:31 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 23 Feb 2009 18:38:31 +0000
Subject: [New-bugs-announce] [issue5353] Improve IndexError messages with
actual values
In-Reply-To: <1235414311.83.0.833112713041.issue5353@psf.upfronthosting.co.za>
Message-ID: <1235414311.83.0.833112713041.issue5353@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
Currently: >>> l=[]; l[1] # 3.0.1
...
IndexError: list index out of range
Assuming that negative indexes are converted before the range test is
made, I would like to see
"IndexError: list index 1 not in range(0)", ie,
"IndexError: list index {0} not in range({1})".format(<index>,
len(<sequence>)).
The 'in' operator still works with Py3 range objects, so the suggested
Python-level check is still valid.
I did not add 2.6/3.0 only because I don't know if improved error
messages are acceptable in bug-fix releases.
Same request for other sequence IndexError messages:
>>> t=(); t[0]
IndexError: tuple index out of range
>>> s=''; s[0] # 3.0
IndexError: string index out of range
>>> b=b''; b[0]
IndexError: index out of range # *** 'bytes' uniquely missing here ***
>>> ba=bytearray(b); ba[0]
IndexError: bytearray index out of range
Is the check factored out as a macro (or function) so one change would
change all of these?
Similar errors with dict (tersely) give the bad key already:
>>> d={}; d[1]
...
KeyError: 1
-------------------------
The may be superficially similar to request #654558, but that was vague
and was closed as a duplicate of #569574, which is definitely about a
different issue. I did not see anything else in the search results.
----------
components: Interpreter Core
messages: 82634
nosy: tjreedy
severity: normal
status: open
title: Improve IndexError messages with actual values
type: feature request
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5353>
_______________________________________
From report at bugs.python.org Mon Feb 23 22:19:34 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 23 Feb 2009 21:19:34 +0000
Subject: [New-bugs-announce] [issue5354] Add test.support.import_python_only
In-Reply-To: <1235423974.71.0.0926342206599.issue5354@psf.upfronthosting.co.za>
Message-ID: <1235423974.71.0.0926342206599.issue5354@psf.upfronthosting.co.za>
New submission from Nick Coghlan <ncoghlan at gmail.com>:
Add test.support.import_python_only as per
http://mail.python.org/pipermail/python-dev/2009-February/086387.html
Also add an equivalent to test.test_support in 2.x (I haven't checked
yet if importlib is available in 2.x, so the implementation may need to
be a little different)
----------
assignee: ncoghlan
messages: 82643
nosy: brett.cannon, ncoghlan
priority: normal
severity: normal
status: open
title: Add test.support.import_python_only
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5354>
_______________________________________
From report at bugs.python.org Tue Feb 24 00:40:45 2009
From: report at bugs.python.org (Suraj Barkale)
Date: Mon, 23 Feb 2009 23:40:45 +0000
Subject: [New-bugs-announce] [issue5355] Expat parser error constants are
string descriptions
In-Reply-To: <1235432445.32.0.505326147132.issue5355@psf.upfronthosting.co.za>
Message-ID: <1235432445.32.0.505326147132.issue5355@psf.upfronthosting.co.za>
New submission from Suraj Barkale <suraj+python at barkale.com>:
All the error constants in `xml.parsers.expat.errors` are strings.
However, when expat raises an ExpatError exception, ExpatError.code
attribute is a number. There seems to be no way of associating
ExpatError with a corresponding error code from `xml.parsers.expat.errors.
Following code snippet should print "Ignore empty file" but in Python
2.6 it raises ExpatError.
from xml.etree import ElementTree
from xml.parsers import expat
try:
ElementTree.parse('')
except expat.ExpatError as e:
if e.code == expat.errors.XML_ERROR_NO_ELEMENTS:
print "Ignore empty file"
else:
raise
----------
components: XML
messages: 82648
nosy: suraj
severity: normal
status: open
title: Expat parser error constants are string descriptions
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5355>
_______________________________________
From report at bugs.python.org Tue Feb 24 01:49:29 2009
From: report at bugs.python.org (Steve Owens)
Date: Tue, 24 Feb 2009 00:49:29 +0000
Subject: [New-bugs-announce] [issue5356] Use of the `curses' resource not
enabled
In-Reply-To: <1235436569.34.0.315805305661.issue5356@psf.upfronthosting.co.za>
Message-ID: <1235436569.34.0.315805305661.issue5356@psf.upfronthosting.co.za>
New submission from Steve Owens <steve at integrityintegrators.net>:
I just did an SVN checkout of the 2.7 source, ran the following in order:
configure
make
make test
When I run make test it gets to the lines:
test_curses
test_curses skipped -- Use of the `curses' resource not enabled
but I have ncurses installed and enabled. In fact I was using the
python curses library on my machine when I was running the latest Fedora
YUM install of Python.
So I am not sure if anyone knows what might be responsible for this message.
----------
components: Build
messages: 82650
nosy: steve at integrityintegrators.net
severity: normal
status: open
title: Use of the `curses' resource not enabled
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5356>
_______________________________________
From report at bugs.python.org Tue Feb 24 02:08:20 2009
From: report at bugs.python.org (Mitchell Model)
Date: Tue, 24 Feb 2009 01:08:20 +0000
Subject: [New-bugs-announce] [issue5357] Last paragraph of
urllib.request.urlopen documentation is garbled
In-Reply-To: <1235437700.71.0.10154464666.issue5357@psf.upfronthosting.co.za>
Message-ID: <1235437700.71.0.10154464666.issue5357@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
The last two sentences of the last paragraph of the documentation of
urllib.request.urlopen are shown below. I have broken up the text to
comment on places where it appears to be garbled. It might be easier to
just rewrite the two sentences rather than trying to make the
corrections I'm suggesting.
The urlopen function from the previous version,
"the previous version" --> "previous versions"
Python 2.6 and earlier, of the module urllib has been discontinued as
urlopen can return the file-object as the previous.
either one or more words are missing from the end of the
sentence or the last part of the sentence starting with "as" needs
repair
The proxy handling,
"handling" --> "handler"?
which in earlier
"earlier" --> "earlier versions"?
was passed as a dict parameter to urlopen can be availed
need comma after "urlopen"
"availed" --> "obtained"
or better, perhaps: "can be obtained by using ProxyHandler
objects" instead of "by the use of...."
by the use of ProxyHandler objects.
----------
assignee: georg.brandl
components: Documentation
messages: 82652
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Last paragraph of urllib.request.urlopen documentation is garbled
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5357>
_______________________________________
From report at bugs.python.org Tue Feb 24 12:53:52 2009
From: report at bugs.python.org (Baiju M)
Date: Tue, 24 Feb 2009 11:53:52 +0000
Subject: [New-bugs-announce] [issue5358] Unicode control characters are not
allowed as identifiers
In-Reply-To: <1235476432.19.0.732411111445.issue5358@psf.upfronthosting.co.za>
Message-ID: <1235476432.19.0.732411111445.issue5358@psf.upfronthosting.co.za>
New submission from Baiju M <baiju.m.mail at gmail.com>:
I tried to use Zero-width joiner (U+200D) as part of an identifier.
It produce an exception like this:
SyntaxError: invalid character in identifier
I have attached the Python file which produce this error.
Zero-width joiner (U+200D) is a Unicode control character:
http://en.wikipedia.org/wiki/Unicode_control_characters
----------
components: Unicode
files: identifier.py
messages: 82664
nosy: baijum
severity: normal
status: open
title: Unicode control characters are not allowed as identifiers
type: behavior
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13162/identifier.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5358>
_______________________________________
From report at bugs.python.org Tue Feb 24 14:02:53 2009
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 24 Feb 2009 13:02:53 +0000
Subject: [New-bugs-announce] [issue5359] _dbm extension only built using
gdbm on linux
In-Reply-To: <1235480573.33.0.45188459471.issue5359@psf.upfronthosting.co.za>
Message-ID: <1235480573.33.0.45188459471.issue5359@psf.upfronthosting.co.za>
New submission from Matthias Klose <doko at debian.org>:
in 3.x the _dbm extension can only be built with gdbm as the backend
library. gdbm is licensed under the GPL, so some people/projects like
Debian may have objections to build _dbm with the gdbm backend. It gets
difficult to determine, which code then uses _dbm/anydbm/... and then
check if it is compatible with the GPL.
Unless there is an alternative like dbm.sqlite (issue 3783), I would
like to re-add the detection of the BerkleyDB headers and libs, such
that _dbm can be built again without depending on gdbm. Adding a
configure flag to explicitely select one implementation (issue 4587)
would be helpful.
Ok to go ahead?
----------
components: Build
messages: 82665
nosy: doko
severity: normal
status: open
title: _dbm extension only built using gdbm on linux
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5359>
_______________________________________
From report at bugs.python.org Tue Feb 24 20:09:36 2009
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Koenig?=)
Date: Tue, 24 Feb 2009 19:09:36 +0000
Subject: [New-bugs-announce] [issue5360] RO (shorthand for READONLY) gone,
not in documentation
In-Reply-To: <1235502576.75.0.520800544088.issue5360@psf.upfronthosting.co.za>
Message-ID: <1235502576.75.0.520800544088.issue5360@psf.upfronthosting.co.za>
New submission from R?mi Koenig <remi.k2620 at gmail.com>:
The Defining New Types document for python3
(http://docs.python.org/3.0/extending/newtypes.html) cites the RO macro
(which existed in versions < 3). However, it has been removed in py3k
(cf http://wiki.python.org/moin/Py3kExtensionModules or
python3.0/structmember.h).
----------
assignee: georg.brandl
components: Documentation
messages: 82670
nosy: R?mi, georg.brandl
severity: normal
status: open
title: RO (shorthand for READONLY) gone, not in documentation
type: compile error
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5360>
_______________________________________
From report at bugs.python.org Tue Feb 24 23:04:05 2009
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 24 Feb 2009 22:04:05 +0000
Subject: [New-bugs-announce] [issue5361] Obsolete mispelled in string
formatting docs
In-Reply-To: <1235513045.71.0.677338168976.issue5361@psf.upfronthosting.co.za>
Message-ID: <1235513045.71.0.677338168976.issue5361@psf.upfronthosting.co.za>
New submission from Steven D'Aprano <steve at pearwood.info>:
The table of string formatting conversions has a mispelling:
http://docs.python.org/library/stdtypes.html#string-formatting
'u' Obselete type ? it is identical to 'd'.
Should be "Obsolete".
----------
assignee: georg.brandl
components: Documentation
messages: 82680
nosy: georg.brandl, stevenjd
severity: normal
status: open
title: Obsolete mispelled in string formatting docs
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5361>
_______________________________________
From report at bugs.python.org Tue Feb 24 23:55:16 2009
From: report at bugs.python.org (Collin Winter)
Date: Tue, 24 Feb 2009 22:55:16 +0000
Subject: [New-bugs-announce] [issue5362] Add configure option to disable
Py3k warnings
In-Reply-To: <1235516116.64.0.427185955219.issue5362@psf.upfronthosting.co.za>
Message-ID: <1235516116.64.0.427185955219.issue5362@psf.upfronthosting.co.za>
New submission from Collin Winter <collinw at gmail.com>:
The attached patch adds a --with-py3k-warnings option to configure.
Passing --without-py3k-warnings disables all Py3k compatibility warnings
(the default is to keep the warnings). For production deployments where
performance is more important than warnings no-one will see, this can
provide a useful performance improvement:
2to3 (translate 2to3's source tree five times):
Min: 22.406 -> 22.114: 1.32% faster
Avg: 22.439 -> 22.158: 1.27% faster
Django (render a 150x150 table 100 times):
Min: 0.595 -> 0.586: 1.58% faster
Avg: 0.598 -> 0.588: 1.76% faster
Spitfire (render a 1000x1000 table 100 times):
Min: 0.752 -> 0.743: 1.29% faster
Avg: 0.754 -> 0.745: 1.25% faster
Unpickle (unpickling a list of 8000 dicts 100 times):
Min: 0.305 -> 0.301: 1.41% faster
Avg: 0.307 -> 0.302: 1.49% faster
Build env: gcc 4.3.1 x86_64 on Linux 2.6.18 (Core2 Duo)
----------
assignee: jyasskin
components: Interpreter Core
files: no_py3k_warning.patch
keywords: needs review, patch, patch
messages: 82683
nosy: brett.cannon, collinwinter, jyasskin, pitrou
severity: normal
status: open
title: Add configure option to disable Py3k warnings
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file13168/no_py3k_warning.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5362>
_______________________________________
From report at bugs.python.org Wed Feb 25 06:52:04 2009
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 25 Feb 2009 05:52:04 +0000
Subject: [New-bugs-announce] [issue5363] Documentation of filecmp.compfiles
missing word & possible explanation
In-Reply-To: <1235541124.5.0.22213829606.issue5363@psf.upfronthosting.co.za>
Message-ID: <1235541124.5.0.22213829606.issue5363@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
"contains the list of files match in both directories," should have
"that" before "match"
In addition I couldn't figure out from the documentation what "common"
was supposed to be doing -- it sounded more like something that should
be part of the result not a parameter. I had to look at the code to
realize that this function ONLY compares the files listed in common --
that it doesn't compare two directories completely, but rather dir1 and
dir2 are merely prefixes for the files listed in common that are to be
compared.
One thing that would help would be to move the paragraph about common
first. Another would be to "a list of file names found in both
directories" to "a list of the names of files to be compared, which must
be in both directories" or something like that.
----------
assignee: tarek
components: Distutils
messages: 82696
nosy: MLModel, tarek
severity: normal
status: open
title: Documentation of filecmp.compfiles missing word & possible explanation
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5363>
_______________________________________
From report at bugs.python.org Wed Feb 25 11:19:38 2009
From: report at bugs.python.org (wrobell)
Date: Wed, 25 Feb 2009 10:19:38 +0000
Subject: [New-bugs-announce] [issue5364] documentation in epub format
In-Reply-To: <1235557178.12.0.454366670328.issue5364@psf.upfronthosting.co.za>
Message-ID: <1235557178.12.0.454366670328.issue5364@psf.upfronthosting.co.za>
New submission from wrobell <wrobell at pld-linux.org>:
python documentation can be downloaded in pdf format (a4, us letter),
html and text plain. they are useful for printing and computer based
viewing, but not so good to read on ebook hardware/software
(i.e. sony prs-{505,700} or stanza ebook reader).
it would be nice if python documentation could be downloaded in epub
format, which is open format for ebooks
http://wiki.mobileread.com/wiki/EPUB
http://en.wikipedia.org/wiki/Epub#IDPF.2FEPUB
http://en.wikipedia.org/wiki/OEBPS
i believe that major publishers are providing ebooks in epub format
as well
http://newsbreaks.infotoday.com/wndReader.asp?ArticleId=52615
----------
assignee: georg.brandl
components: Documentation
messages: 82698
nosy: georg.brandl, wrobell
severity: normal
status: open
title: documentation in epub format
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5364>
_______________________________________
From report at bugs.python.org Wed Feb 25 12:24:03 2009
From: report at bugs.python.org (Chris Rebert)
Date: Wed, 25 Feb 2009 11:24:03 +0000
Subject: [New-bugs-announce] [issue5365] add conversion table to time module
docs
In-Reply-To: <1235561043.91.0.296999855786.issue5365@psf.upfronthosting.co.za>
Message-ID: <1235561043.91.0.296999855786.issue5365@psf.upfronthosting.co.za>
New submission from Chris Rebert <pybugs at rebertia.com>:
I would like the offer the table in the attached file for addition to
the 'time' module documentation so as to provide a quick overview of how
to convert between the various time representations. As it currently
stands (at least on the current public version of the docs), to find the
same information, one must read through several nonadjacent prose
function descriptions, which can get tiring when one has to look up the
conversions repeatedly when writing a time-intensive program.
I'm new at the documentation format, but I think my submission is
reasonably correctly formatted; however, I don't have Sphinx to test
with, so I can't be 100% sure.
----------
assignee: georg.brandl
components: Documentation
files: table.rst
messages: 82700
nosy: cvrebert, georg.brandl
severity: normal
status: open
title: add conversion table to time module docs
type: feature request
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file13172/table.rst
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5365>
_______________________________________
From report at bugs.python.org Wed Feb 25 16:41:53 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 25 Feb 2009 15:41:53 +0000
Subject: [New-bugs-announce] [issue5366] examples for dependency keywords in
setup.py
In-Reply-To: <1235576513.9.0.725143372807.issue5366@psf.upfronthosting.co.za>
Message-ID: <1235576513.9.0.725143372807.issue5366@psf.upfronthosting.co.za>
New submission from anatoly techtonik <techtonik at gmail.com>:
When documentation grows too large it is nice to have clear examples
that stand out of text. Explanation is important to get the idea, but
for a reference cookbook examples work better.
Here is a patch to clarify the usage of *requires* and *provides*
keywords in setup.py on the documentation page
http://docs.python.org/distutils/setupscript.html#relationships-between-distributions-and-packages
--- setupscript_old.txt Wed Feb 25 17:09:41 2009
+++ setupscript.txt Wed Feb 25 17:34:00 2009
@@ -423,6 +423,14 @@
distribution being described. If no qualifiers are given, all versions
of the
named module or package are understood to be obsoleted.
+Example of using *requires* and *provides* keywords ::
+
+ setup(...,
+ requires=['dbm', 'foo=>1.1.0'],
+ provides=['myapi (1.1)'],
+ )
+
+
Installing Scripts
==================
----------
assignee: tarek
components: Distutils, Documentation
files: setupscript.diff
keywords: patch
messages: 82706
nosy: tarek, techtonik
severity: normal
status: open
title: examples for dependency keywords in setup.py
Added file: http://bugs.python.org/file13173/setupscript.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5366>
_______________________________________
From report at bugs.python.org Wed Feb 25 17:08:10 2009
From: report at bugs.python.org (Joachim Ott)
Date: Wed, 25 Feb 2009 16:08:10 +0000
Subject: [New-bugs-announce] [issue5367] typo in subprocess.py
In-Reply-To: <1235578090.41.0.726164136752.issue5367@psf.upfronthosting.co.za>
Message-ID: <1235578090.41.0.726164136752.issue5367@psf.upfronthosting.co.za>
New submission from Joachim Ott <Joachim.Ott at gmail.com>:
I saw it first in /usr/lib/python2.5/subprocess.py on two different
systems, line 12 reads:
r"""subprocess - Subprocesses with accessible I/O streams
It's still there in 3.0.1. Is a single "r" a valid python statement?
----------
components: Library (Lib)
messages: 82707
nosy: ott--
severity: normal
status: open
title: typo in subprocess.py
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5367>
_______________________________________
From report at bugs.python.org Wed Feb 25 18:30:30 2009
From: report at bugs.python.org (Steve Owens)
Date: Wed, 25 Feb 2009 17:30:30 +0000
Subject: [New-bugs-announce] [issue5368] curses patch add color_set and
wcolor_set functions
In-Reply-To: <1235583031.0.0.493464972804.issue5368@psf.upfronthosting.co.za>
Message-ID: <1235583031.0.0.493464972804.issue5368@psf.upfronthosting.co.za>
New submission from Steve Owens <steve at integrityintegrators.net>:
Not sure what to set theType field to, this is my first patch
submission. The attached files are a unit test
test_curses_color_set.py and the diff color_set_diff, apparently I can
only attach one fo thetwo files.
----------
assignee: georg.brandl
components: Documentation
files: color_set_patch.diff
keywords: patch
messages: 82709
nosy: georg.brandl, steve at integrityintegrators.net
severity: normal
status: open
title: curses patch add color_set and wcolor_set functions
versions: Python 2.7
Added file: http://bugs.python.org/file13174/color_set_patch.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5368>
_______________________________________
From report at bugs.python.org Wed Feb 25 20:26:08 2009
From: report at bugs.python.org (=?utf-8?q?Arkadiusz_Miskiewicz=09=09=09=09Arkadiusz_Miskiewicz?=)
Date: Wed, 25 Feb 2009 19:26:08 +0000
Subject: [New-bugs-announce] [issue5369] __ppc__ macro checking is incorrect
In-Reply-To: <1235589968.39.0.392818865305.issue5369@psf.upfronthosting.co.za>
Message-ID: <1235589968.39.0.392818865305.issue5369@psf.upfronthosting.co.za>
New submission from Arkadiusz Miskiewicz Arkadiusz Miskiewicz <arekm at users.sourceforge.net>:
Python/ceval.c and many other places rely on __ppc__ (and __ppc64__)
symbol defined like below.
Unfortunately on my Linux ppc __ppc__ is never defined while
__powerpc__ is. Build fortunately failed so the problem was noticed.
The fix is to check for __powerpc__ and __powerpc64__ as for example
glibc does.
#if defined(__ppc__) /* <- Don't know if this is the correct symbol;
this
section should work for GCC on any PowerPC
platform, irrespective of OS.
POWER? Who knows :-) */
----------
messages: 82712
nosy: arekm
severity: normal
status: open
title: __ppc__ macro checking is incorrect
type: compile error
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5369>
_______________________________________
From report at bugs.python.org Wed Feb 25 22:26:16 2009
From: report at bugs.python.org (Mike Meyer)
Date: Wed, 25 Feb 2009 21:26:16 +0000
Subject: [New-bugs-announce] [issue5370] unpickling vs. __getattr__
In-Reply-To: <1235597176.48.0.557535954175.issue5370@psf.upfronthosting.co.za>
Message-ID: <1235597176.48.0.557535954175.issue5370@psf.upfronthosting.co.za>
New submission from Mike Meyer <mwm at users.sourceforge.net>:
The attached short file causes all of python 2.5, 2.6 and 3.0 to drop
into infinite recursion trying to unpickle the created object, but the
2.5 version has the cleanest The problem appears to be that the unpickle
code (C in 3.0; Python in 2.5 - I assume the others are similar) uses
getattr to try and get the __setstate__ method (if any) of the opject
being built before it's dictionary is populated. This causes the
invocation of the __getattr__ method, which tries to use the
non-existent "attrs" attribute, thus starting the recursion.
A simple workaround is to provide this:
def __setstate__(self, data):
self.__dict__.update(data)
but methinks that either 1) the interpreter shouldn't be falling into
the infinite loop in this case, or 2) the pickle code should be using
hasattr to check for the attribute (which won't trigger this problem)
before trying getattr on it.
----------
files: pickletest.py
messages: 82721
nosy: mwm
severity: normal
status: open
title: unpickling vs. __getattr__
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file13179/pickletest.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5370>
_______________________________________
From report at bugs.python.org Wed Feb 25 22:49:03 2009
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 25 Feb 2009 21:49:03 +0000
Subject: [New-bugs-announce] [issue5371] Documentation of str.format in
library/stdtypes shows incorrect first parameter
In-Reply-To: <1235598543.9.0.464602972066.issue5371@psf.upfronthosting.co.za>
Message-ID: <1235598543.9.0.464602972066.issue5371@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
In the library documentation of standard types, the instance method
str.format is shown as taking a format-specification as its first
argument. I'm pretty sure that this is incorrect. When format is called
through a string, it is that string that is the format specification.
That is, shouldn't
format(format-specification-string, arg....) be equivalent to
format-specification-string.format(arg....)
?
----------
assignee: georg.brandl
components: Documentation
messages: 82722
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Documentation of str.format in library/stdtypes shows incorrect first parameter
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5371>
_______________________________________
From report at bugs.python.org Thu Feb 26 01:05:27 2009
From: report at bugs.python.org (Collin Winter)
Date: Thu, 26 Feb 2009 00:05:27 +0000
Subject: [New-bugs-announce] [issue5372] Distutils inappropriately reuses .o
files between extension modules
In-Reply-To: <1235606727.67.0.443849487538.issue5372@psf.upfronthosting.co.za>
Message-ID: <1235606727.67.0.443849487538.issue5372@psf.upfronthosting.co.za>
New submission from Collin Winter <collinw at gmail.com>:
(Tarek, I've been told you're the new distutils maintainer. Feel free to
unassign this if that isn't the case.)
The test distutils uses to decide whether it needs to recompile an
existing .o file when building extension modules is too simplistic,
merely comparing the modification time of the .o and .c files. If you
have two extension modules like so
Extension('foo', ['foo.c', 'bar.c'],
define_macros=[('NO_STATIC_MEMOTABLE', 1)])
Extension('bar', ['bar.c'])
even if defining NO_STATIC_MEMOTABLE=1 radically changes the code of
bar.c, distutils will use the same bar.o for both the foo and bar
extension modules. This was a real problem for me at work today.
The attached patch removes the modtime comparison entirely, preferring
to rebuild all .o files a given extension module needs. Note that while
_prep_compiler() isn't used anywhere in the stdlib, Google Code Search
turns up uses.
----------
assignee: tarek
components: Distutils
files: ccompiler.patch
keywords: needs review, patch, patch
messages: 82734
nosy: collinwinter, jyasskin, tarek
severity: normal
stage: patch review
status: open
title: Distutils inappropriately reuses .o files between extension modules
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file13180/ccompiler.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5372>
_______________________________________
From report at bugs.python.org Thu Feb 26 10:42:26 2009
From: report at bugs.python.org (Noel Cuillandre)
Date: Thu, 26 Feb 2009 09:42:26 +0000
Subject: [New-bugs-announce] [issue5373] TypeError when '\x00' in docstring
In-Reply-To: <1235641346.54.0.44421310191.issue5373@psf.upfronthosting.co.za>
Message-ID: <1235641346.54.0.44421310191.issue5373@psf.upfronthosting.co.za>
New submission from Noel Cuillandre <noel.cuillandre at gmail.com>:
The following code raises 'TypeError: __doc__ contains null-bytes'::
Python 3.1a0 (py3k, Jan 27 2009, 18:02:26)
[GCC 4.1.1 (Gentoo 4.1.1-r1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class Foo:
... """'\x00'"""
...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: __doc__ contains null-bytes
----------
messages: 82747
nosy: noel.cuillandre
severity: normal
status: open
title: TypeError when '\x00' in docstring
type: compile error
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5373>
_______________________________________
From report at bugs.python.org Thu Feb 26 15:08:21 2009
From: report at bugs.python.org (Andy Buckley)
Date: Thu, 26 Feb 2009 14:08:21 +0000
Subject: [New-bugs-announce] [issue5374] optparse special usage tokens
conflict with formatting characters
In-Reply-To: <1235657301.0.0.570372518506.issue5374@psf.upfronthosting.co.za>
Message-ID: <1235657301.0.0.570372518506.issue5374@psf.upfronthosting.co.za>
New submission from Andy Buckley <andy at insectnation.org>:
optparse's OptionParser takes a usage string as a constructor argument,
in which a "%prog" token is replaced with the executable name. Nice
idea, but the choice of a percent sign for token delimiter is
troublesome since it means that attempting to substitute any variables
into the usage string, e.g.
usage = """
%prog [options] foo bar ...
Some computed info: %s""" % myinfo
gives a ValueError:
ValueError: unsupported format character 'p' (0x70) at index 2
Maybe this ceases to be a problem with what I've heard about the
formatting re-design in Python 3.x, but it will probably continue to be
awkward for the 2.x series where the "%" operator still applies. Maybe
optparse could also use a safer token ("@prog", say), so that those of
use who would like to substitute variables into usage strings don't have
to artificially break our strings apart every time we use the program name?
----------
components: Library (Lib)
messages: 82755
nosy: andybuckley
severity: normal
status: open
title: optparse special usage tokens conflict with formatting characters
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5374>
_______________________________________
From report at bugs.python.org Thu Feb 26 15:08:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 26 Feb 2009 14:08:54 +0000
Subject: [New-bugs-announce] [issue5375] Unified locals/consts array +
register-based instructions
In-Reply-To: <1235657334.5.0.583024676615.issue5375@psf.upfronthosting.co.za>
Message-ID: <1235657334.5.0.583024676615.issue5375@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
There is no patch here, this entry is just a reminder of some of the
ideas that have been suggested to experiment with ways to speedup the
Python VM (djc, who is nosied, has said he'd be willing to try working
on it):
- unify the local variables and constants arrays (this costs a copy of
the constants array at each frame creation, but it should be negligible
since frames are reused and the copy can probably be a dumb memcpy)
- devise new instructions, or a whole new instruction set, which takes
its arguments from this array
As a simple way to experiment, one could start with a new instruction
named e.g. BINARY_ADD_FAST which would take one 16-bit arg, whose 8
upper bits would be the index of the first argument, and whose 8 lower
bits would be the index of the second argument. The result would be
pushed on top of the stack.
It could also be measured whether having a special value (255) to mean
"pop the argument off the pop of the stack" gives negative (because of
overhead) or positive (because of less bytecode) results.
----------
components: Interpreter Core
messages: 82756
nosy: collinwinter, djc, jyasskin, pitrou
priority: normal
severity: normal
status: open
title: Unified locals/consts array + register-based instructions
type: performance
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5375>
_______________________________________
From report at bugs.python.org Thu Feb 26 16:56:33 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 Feb 2009 15:56:33 +0000
Subject: [New-bugs-announce] [issue5376] Wrong ImportError message if module
is not readable
In-Reply-To: <1235663793.95.0.193952339163.issue5376@psf.upfronthosting.co.za>
Message-ID: <1235663793.95.0.193952339163.issue5376@psf.upfronthosting.co.za>
New submission from STINNER Victor <victor.stinner at haypocalc.com>:
__import__() raises an ImportError "No module named ..." if the module
file is not readable or module directory is not executable. The
expected message is something like "Module named ... is not readable".
Directory tree for the test:
------------------------------
marge$ ls -lRF .
.:
drwxrwxrwx 2 haypo haypo 4096 2009-02-26 16:51 module/
-rw-rw-rw- 1 haypo haypo 9 2009-02-26 16:48 module2.py
-rw-r--r-- 1 haypo haypo 414 2009-02-26 16:50 test.py
./module:
-rw-r--r-- 1 haypo haypo 10 2009-02-26 16:45 __init__.py
------------------------------
Success with correct file permissions:
------------------------------
$ python test.py
__import__('/home/haypo/xxx/module') ...
PI = 3.14
__import__('/home/haypo/xxx/module2') ...
E = 2.72
------------------------------
Change module/ and module2.py permissions to 000 (no read, no write,
no execute):
------------------------------
__import__('/home/haypo/xxx/module') ...
No module named /home/haypo/xxx/module
__import__('/home/haypo/xxx/module2') ...
No module named /home/haypo/xxx/module2
------------------------------
----------
components: Interpreter Core
files: test.tar.gz
messages: 82766
nosy: haypo
severity: normal
status: open
title: Wrong ImportError message if module is not readable
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13190/test.tar.gz
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5376>
_______________________________________
From report at bugs.python.org Thu Feb 26 21:24:29 2009
From: report at bugs.python.org (Gregory Golberg)
Date: Thu, 26 Feb 2009 20:24:29 +0000
Subject: [New-bugs-announce] [issue5377] Strange behavior when performing
int on a Decimal made from -sys.maxint-1
In-Reply-To: <1235679869.5.0.97489087981.issue5377@psf.upfronthosting.co.za>
Message-ID: <1235679869.5.0.97489087981.issue5377@psf.upfronthosting.co.za>
New submission from Gregory Golberg <grisha at alum.mit.edu>:
On some Python builds (2.5.2 and 2.6.1) the following program:
import sys
from decimal import Decimal
def show(n):
print type(n)
d = Decimal(str(n))
i = int(d)
t = type(i)
print t
i2 = int(i)
t2 = type(i2)
print t2
n = - sys.maxint - 1
show(n)
prints
<type 'int'>
<type 'long'>
<type 'int'>
While on 2.4 and 2.5.1 it prints:
<type 'int'>
<type 'int'>
<type 'int'>
This seems to happen only with -sys.maxint-1 number!
This has been tested with the following builds:
*** "Strange" result (with long): ***
2.6.1 (r261:67515, Feb 26 2009, 12:21:28) [GCC 4.2.4 (Ubuntu
4.2.4-1ubuntu3)]
2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)]
2.5.2 (r252:60911, Jul 31 2008, 17:28:52) [GCC 4.2.3 (Ubuntu
4.2.3-2ubuntu7)]
2.5.2 and 2.6.1 on Windows Server 2003
*** "Expected" result (all int): ***
2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)]
2.5.1 (r251:54863, Oct 15 2007, 13:50:22) [GCC 3.4.6 20060404 (Red Hat
3.4.6-3)]
2.5.1 (r251:54863, Jul 31 2008, 23:17:40) [GCC 4.1.3 20070929
(prerelease) (Ubuntu 4.1.2-16ubuntu2)]
2.4.5 (#2, Aug 1 2008, 02:20:59) [GCC 4.3.1]
2.4.5 (#1, Jul 22 2008, 08:30:02) [GCC 3.4.3 (csl-sol210-3_4-20050802)]
2.4.3 (#1, Sep 21 2007, 20:05:43) [GCC 3.4.6 20060404 (Red Hat 3.4.6-8)]
----------
assignee: theller
components: Interpreter Core, ctypes
files: negmaxintbug.py
messages: 82773
nosy: debedb, theller
severity: normal
status: open
title: Strange behavior when performing int on a Decimal made from -sys.maxint-1
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file13191/negmaxintbug.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5377>
_______________________________________
From report at bugs.python.org Fri Feb 27 00:50:58 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 26 Feb 2009 23:50:58 +0000
Subject: [New-bugs-announce] [issue5378] adding --quiet to bdist_rpm
In-Reply-To: <1235692258.75.0.847586462269.issue5378@psf.upfronthosting.co.za>
Message-ID: <1235692258.75.0.847586462269.issue5378@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
rmp and rpmbuild has a --quiet option that lowers down the output to
stdout and stderr.
Having it in Distutils is useful to cut down the output when bdist_rpm
calls these commands
----------
assignee: tarek
components: Distutils
messages: 82790
nosy: tarek
priority: normal
severity: normal
status: open
title: adding --quiet to bdist_rpm
type: feature request
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5378>
_______________________________________
From report at bugs.python.org Fri Feb 27 02:50:01 2009
From: report at bugs.python.org (Philipp Hagemeister)
Date: Fri, 27 Feb 2009 01:50:01 +0000
Subject: [New-bugs-announce] [issue5379] Multicast example mcast.py is
outdated and ugly
In-Reply-To: <1235699401.83.0.959623868909.issue5379@psf.upfronthosting.co.za>
Message-ID: <1235699401.83.0.959623868909.issue5379@psf.upfronthosting.co.za>
New submission from Philipp Hagemeister <phihag at phihag.de>:
The multicast example Demo/sockets/mcast.py
1. mentions that multicast is only implemented on SGI (and optional on
other systems). That is not the case anymore.
2. Includes completely unrelated code for broadcast transmission. There
is already an example for that, suitably named broadcast.py (in the same
directory).
3. Does only support IPv4.
4. Is borderline buggy. Line 85 only works by accident. Similarly, line
37 fails if the TTL would be increased to >127.
5. Is ugly. Line 79-81 are an example of how not to write python code,
line 62 can be deleted without changing the program's semantics.
(All line numbers refer to rev70006)
The attached patch removes broadcast support in mcast.py, adds IPv6
support and fixes all other problems mentioned above.
----------
components: Demos and Tools
files: mcast-example.diff
keywords: patch
messages: 82810
nosy: phihag
severity: normal
status: open
title: Multicast example mcast.py is outdated and ugly
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13198/mcast-example.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5379>
_______________________________________
From report at bugs.python.org Fri Feb 27 09:03:34 2009
From: report at bugs.python.org (Zac Medico)
Date: Fri, 27 Feb 2009 08:03:34 +0000
Subject: [New-bugs-announce] [issue5380] array.fromfile() on master pty
raises IOError when slave pty device is closed
In-Reply-To: <1235721814.23.0.522352333065.issue5380@psf.upfronthosting.co.za>
Message-ID: <1235721814.23.0.522352333065.issue5380@psf.upfronthosting.co.za>
New submission from Zac Medico <zmedico at gentoo.org>:
With python-3.0, array.fromfile() raises an IOError when reading from a
master pty device after the slave device has been closed. This causes
remaining data that had been written to the slave device to be lost. I
have observed this problem with python-3.0.1 on linux (I get the same
result with or without the patch from issue 5334). The traceback
produced by the attached test case looks like this:
Traceback (most recent call last):
File "./fromfile_pty_ioerror.py", line 26, in <module>
buf.fromfile(master_file, bufsize)
File "/usr/lib/python3.0/io.py", line 918, in read
return self._read_unlocked(n)
File "/usr/lib/python3.0/io.py", line 952, in _read_unlocked
chunk = self.raw.read(wanted)
IOError: [Errno 5] Input/output error
With python-2.x, the remaining data is appended to the array and an
EOFError is raised like one would expect.
----------
components: Library (Lib)
files: fromfile_pty_ioerror.py
messages: 82824
nosy: zmedico
severity: normal
status: open
title: array.fromfile() on master pty raises IOError when slave pty device is closed
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file13200/fromfile_pty_ioerror.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5380>
_______________________________________
From report at bugs.python.org Fri Feb 27 09:37:56 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 27 Feb 2009 08:37:56 +0000
Subject: [New-bugs-announce] [issue5381] json need object_pairs_hook
In-Reply-To: <1235723876.26.0.796036500228.issue5381@psf.upfronthosting.co.za>
Message-ID: <1235723876.26.0.796036500228.issue5381@psf.upfronthosting.co.za>
New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:
If PEP372 goes through, Python is going to gain an ordered dict soon.
The json module's encoder works well with it:
>>> items = [('one', 1), ('two', 2), ('three',3), ('four',4), ('five',5)]
>>> json.dumps(OrderedDict(items))
'{"one": 1, "two": 2, "three": 3, "four": 4, "five": 5}'
But the decoder doesn't fare so well. The existing object_hook for the
decoder passes in a dictionary instead of a list of pairs. So, all the
ordering information is lost:
>>> jtext = '{"one": 1, "two": 2, "three": 3, "four": 4, "five": 5}'
>>> json.loads(jtext, object_hook=OrderedDict)
OrderedDict({u'four': 4, u'three': 3, u'five': 5, u'two': 2, u'one': 1})
A solution is to provide an alternate hook that emits a sequence of
pairs. If present, that hook should run instead of object_hook. A
rough proof-of-concept patch is attached.
FWIW, sample ordered dict code is at:
http://code.activestate.com/recipes/576669/
----------
assignee: bob.ippolito
components: Library (Lib)
files: json_hook.diff
keywords: patch
messages: 82825
nosy: bob.ippolito, rhettinger
priority: normal
severity: normal
status: open
title: json need object_pairs_hook
type: feature request
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file13201/json_hook.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5381>
_______________________________________
From report at bugs.python.org Fri Feb 27 17:25:38 2009
From: report at bugs.python.org (David Kerkeslager)
Date: Fri, 27 Feb 2009 16:25:38 +0000
Subject: [New-bugs-announce] [issue5382] Allow Python keywords as keyword
arguments for functions.
In-Reply-To: <1235751938.62.0.212144531806.issue5382@psf.upfronthosting.co.za>
Message-ID: <1235751938.62.0.212144531806.issue5382@psf.upfronthosting.co.za>
New submission from David Kerkeslager <david.kerkeslager at gmail.com>:
This problem arose in this thread:
http://www.python-forum.org/pythonforum/viewtopic.php?f=2&t=11606
Basically, we have the following function which will generate an XHTML
node:
def xhtmlNode(tag, **attr):...
If we call:
xhtmlNode('div',class='sidebar')
... it should generate the xhtml:
<div class='sidebar'></div>
However, this isn't possible because the 'class' keyword in Python
blocks it. Since this is a key in a dictionary (attr['class']) this
shouldn't be a problem. As far as I know, there is no parsing issue
with this either.
Could we allow Python keywords to be keyword arguments? The use case
above shows that this is useful in a real-life situation.
----------
components: Interpreter Core
messages: 82837
nosy: Imagist
severity: normal
status: open
title: Allow Python keywords as keyword arguments for functions.
type: feature request
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5382>
_______________________________________
From report at bugs.python.org Fri Feb 27 17:45:52 2009
From: report at bugs.python.org (David Kerkeslager)
Date: Fri, 27 Feb 2009 16:45:52 +0000
Subject: [New-bugs-announce] [issue5383] Allow intermixing of keyword
arguments and vargarg arguments
In-Reply-To: <1235753152.03.0.131983429775.issue5383@psf.upfronthosting.co.za>
Message-ID: <1235753152.03.0.131983429775.issue5383@psf.upfronthosting.co.za>
New submission from David Kerkeslager <david.kerkeslager at gmail.com>:
This problem arose in this thread:
http://www.python-forum.org/pythonforum/viewtopic.php?f=2&t=11606
Basically, we have the following function which will generate an XHTML
node:
def xhtmlNode(tag, *content, **attr):...
If we call:
xhtmlNode('div',id='sidebar','Hello, world')
... it should generate the xhtml:
<div id='sidebar'>Hello, world</div>
However, this isn't possible because the keyword argument isn't allowed
to come before the 'vararg' argument. We could do this:
xhtmlNode('div','Hello, world',id='sidebar')
... but this would not have symmetry with the generated xhtml and
therefore complicates the code. The solution, in my opinion, is to
allow varargs to be intermixed with keyword args. The above real-world
example shows a use-case for this more flexible functionality.
If the following rules apply, there shouldn't be any issues:
1. Positional arguments must be in their position (positional arguments
must come before all 'vararg' arguments and keyword arguments).
2. Varargs come in the order in which they are received, ignoring any
keyword arguments that are intermixed.
3. Keyword arguments order doesn't matter (a dictionary isn't ordered).
They can be intermixed with varargs.
Thus the following call:
xhtmlNode('div',id='sidebar',style='width:100px;float:left;','Hello,worl
d',xhtmlNode('p','Hello, world'))
... would result in the following html:
<div id='sidebar' style='width:100px;float:left;'> Hello, world
<p>Hello, world</p></div>
----------
messages: 82839
nosy: Imagist
severity: normal
status: open
title: Allow intermixing of keyword arguments and vargarg arguments
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5383>
_______________________________________
From report at bugs.python.org Fri Feb 27 18:23:17 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 27 Feb 2009 17:23:17 +0000
Subject: [New-bugs-announce] [issue5384] mmap and exception type
In-Reply-To: <1235755397.37.0.107266248804.issue5384@psf.upfronthosting.co.za>
Message-ID: <1235755397.37.0.107266248804.issue5384@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
It seems mmap module is using inappropriate exception types. For example,
if (! (PyString_Check(v)) ) {
PyErr_SetString(PyExc_IndexError,
"mmap slice assignment must be a string");
return -1;
}
I think this should be PyExc_TypeError.
if (self->size >= pos && count > self->size - pos) {
PyErr_SetString(PyExc_ValueError,
"source or destination out of range");
return NULL;
I think this is out of range, so PyExc_IndexError.
Of course, there is the case difficult to determine which exception is
suitable. For example, if Py_ssize_t is negative value, OverflowError or
IndexError?
----------
messages: 82849
nosy: ocean-city
severity: normal
status: open
title: mmap and exception type
type: behavior
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5384>
_______________________________________
From report at bugs.python.org Fri Feb 27 18:33:44 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 27 Feb 2009 17:33:44 +0000
Subject: [New-bugs-announce] [issue5385] mmap can crash after resize failure
(windows)
In-Reply-To: <1235756024.86.0.438154708422.issue5385@psf.upfronthosting.co.za>
Message-ID: <1235756024.86.0.438154708422.issue5385@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
On windows, after mmap.resize fails, self->map_handle
becomes NULL, but it should become INVALID_HANDLE_VALUE otherwise
CHECK_VALID is passed through, it can cause crash like bellow.
import mmap
m = mmap.mmap(-1, 5)
try:
m.resize(-1)
except WindowsError:
pass
m[0] = '1' # crash
The patch is in r69942.
----------
components: Extension Modules
messages: 82852
nosy: ocean-city
severity: normal
status: open
title: mmap can crash after resize failure (windows)
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5385>
_______________________________________
From report at bugs.python.org Fri Feb 27 18:40:15 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 27 Feb 2009 17:40:15 +0000
Subject: [New-bugs-announce] [issue5386] mmap can crash with write_byte
In-Reply-To: <1235756415.33.0.41505595652.issue5386@psf.upfronthosting.co.za>
Message-ID: <1235756415.33.0.41505595652.issue5386@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
mmap.write_byte doesn't check buffer size, so it can cause crash like
bellow.
import mmap
m = mmap.mmap(-1, 1)
for i in xrange(10000): # enough?
print i
m.write_byte('1') # crash
The patch is in r69945.
----------
components: Extension Modules
messages: 82853
nosy: ocean-city
severity: normal
status: open
title: mmap can crash with write_byte
type: crash
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5386>
_______________________________________
From report at bugs.python.org Fri Feb 27 18:45:18 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 27 Feb 2009 17:45:18 +0000
Subject: [New-bugs-announce] [issue5387] mmap.move crashes by integer
overflow
In-Reply-To: <1235756718.87.0.0651298987866.issue5387@psf.upfronthosting.co.za>
Message-ID: <1235756718.87.0.0651298987866.issue5387@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
mmap.move crashes by integer overflow. See
http://www.nabble.com/Segv-in-mmap.move()-td18617044.html
import mmap
data = mmap.mmap(-1, 1)
data.move(1,1,-1) # crash
Maybe mmap.move should use Py_ssize_t and raise
IndexError(OverflowError?) for negative value.
The patch is in r69943.
----------
components: Extension Modules
messages: 82854
nosy: ocean-city
severity: normal
status: open
title: mmap.move crashes by integer overflow
type: crash
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5387>
_______________________________________
From report at bugs.python.org Fri Feb 27 20:45:54 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Feb 2009 19:45:54 +0000
Subject: [New-bugs-announce] [issue5388] Green-box doc glitch: winhelp
version only
In-Reply-To: <1235763954.97.0.134032530958.issue5388@psf.upfronthosting.co.za>
Message-ID: <1235763954.97.0.134032530958.issue5388@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
Example: LangRef / LexAnalysis / Identifiers
Green-shaded grammar section has 3 lines, 2 very long:
identifier ::= id_start id_continue*
id_start ::= <all characters in general categories Lu, ...
id_continue ::= <all characters in id_start, plus character ...
so both online html and winhelp versions have a horizontal scroll bar
underneath.
The 3.0.1 Windows Help version only displays 2 lines and adds a mini
vertical scroll bar at the far right to see the third. If possible, it
would be better if it simply displayed 3 lines like the html version.
Experimentation indicates the following for all the green boxes: if the
type size is increased or the window narrowed so that a horizontal
scroll bar is needed, html (at least as rendered by FireFox) adds it
*underneath* the green box, while Winhelp adds it *in* the green box,
taking up one line and thus hiding the last line of text, thus requiring
a vertical scroll to see that line, which then hides the top line (ugh).
Assuming that there is no configuration option or formatting directive
that can be put in the file to tell winhelp to act differently, a
partial fix would be to add an extra blank line, if possible, to every
green box on conversion to the winhelp version so that all lines would
be visible even when an (now irrelevant) vscroll appears.
----------
assignee: georg.brandl
components: Documentation
messages: 82863
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Green-box doc glitch: winhelp version only
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5388>
_______________________________________
From report at bugs.python.org Fri Feb 27 23:13:14 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 27 Feb 2009 22:13:14 +0000
Subject: [New-bugs-announce] [issue5389] Uninitialized variable may be used
in PyUnicode_DecodeUTF7Stateful()
In-Reply-To: <1235772794.07.0.300454209619.issue5389@psf.upfronthosting.co.za>
Message-ID: <1235772794.07.0.300454209619.issue5389@psf.upfronthosting.co.za>
New submission from Guido van Rossum <guido at python.org>:
[Found by a Googler who prefers to remain anonymous]
This might be easier to trigger on a 64-bit:
PyObject *PyUnicode_DecodeUTF7Stateful(...)
{
...
Py_ssize_t startinpos;
...
while (s < e) {
...
utf7Error:
outpos = p-PyUnicode_AS_UNICODE(unicode);
endinpos = s-starts;
if (unicode_decode_call_errorhandler(
errors, &errorHandler,
"utf7", errmsg,
starts, size, &startinpos, &endinpos, &exc, &s,
&unicode, &outpos, &p))
...
}
...
}
The lack of initialization of startinpos will lead to the likelihood of
the value being >= INT_MAX with a 64-bit value, leading to the
subsequent assert [somewhere in unicode_decode_call_errorhandler()]. In
theory the assert could trigger in 32-bit if the uninitialized value
happened to get set to INT_MAX.
The other similar variable also probably need to be initialized.
Furthermore, the function PyUnicode_DecodeUTF8Stateful also has the same
uninitialized variables.
----------
messages: 82881
nosy: gvanrossum
severity: normal
status: open
title: Uninitialized variable may be used in PyUnicode_DecodeUTF7Stateful()
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5389>
_______________________________________
From report at bugs.python.org Sat Feb 28 08:26:55 2009
From: report at bugs.python.org (Retro)
Date: Sat, 28 Feb 2009 07:26:55 +0000
Subject: [New-bugs-announce] [issue5390] Item 'Python x.x.x' in Add/Remove
Programs list still lacks an icon
In-Reply-To: <1235806015.04.0.902011396347.issue5390@psf.upfronthosting.co.za>
Message-ID: <1235806015.04.0.902011396347.issue5390@psf.upfronthosting.co.za>
New submission from Retro <vinetouu at gmail.com>:
I am reporting a bug which was not fixed in the closed issue #4389.
Martin v. L?wis, the fix you've made didn't fix the issue. Please open
your Add/Remove Programs list (hopefully your running Windows and have
Python installed there) and check whether your Python interpreters in
this list use Python's icon. Your fix was made before Python 2.5.4,
Python 2.6.1, and Python 3.0.1 were out. I don't know why these new
interpreters (installed on my Windows Vista Business 64-bit machine)
don't show Python's icon in the Add/Remove Programs list. Is this an
issue on my side or on Python's side?
----------
messages: 82890
nosy: Retro, loewis
severity: normal
status: open
title: Item 'Python x.x.x' in Add/Remove Programs list still lacks an icon
versions: 3rd party, Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5390>
_______________________________________
From report at bugs.python.org Sat Feb 28 12:02:29 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 28 Feb 2009 11:02:29 +0000
Subject: [New-bugs-announce] [issue5391] mmap: read_byte/write_byte and
object type
In-Reply-To: <1235818949.96.0.83052759976.issue5391@psf.upfronthosting.co.za>
Message-ID: <1235818949.96.0.83052759976.issue5391@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
On Python3000, mmap.read_byte returns str not bytes, and mmap.write_byte
accepts str. Is this intended behavior?
>>> import mmap
>>> m = mmap.mmap(-1, 10)
>>> type(m.read_byte())
<class 'str'>
>>> m.write_byte("a")
>>> m.write_byte(b"a")
Maybe another possibility. read_byte() returns int which represents
byte, write_byte accepts int which represents byte. (Like b"abc"[0]
returns int not 1-length bytes)
----------
components: Extension Modules
messages: 82903
nosy: ocean-city
severity: normal
status: open
title: mmap: read_byte/write_byte and object type
type: behavior
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5391>
_______________________________________
From report at bugs.python.org Sat Feb 28 12:26:44 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 28 Feb 2009 11:26:44 +0000
Subject: [New-bugs-announce] [issue5392] stack overflow after hitting
recursion limit twice
In-Reply-To: <1235820404.86.0.303625232795.issue5392@psf.upfronthosting.co.za>
Message-ID: <1235820404.86.0.303625232795.issue5392@psf.upfronthosting.co.za>
New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:
Set sys.setrecursionlimit to 50 or lower. Then, the second time the
recursion limit is reached, the interpreter crashes with a stack
overflow.
This happens both with released 3.0.1 and the py3k branch, on Windows.
At least on my PC, 51 appears to be the minimum acceptable value for
sys.setrecursionlimit.
Python 3.1a0 (py3k, Feb 28 2009, 04:16:04) [MSC v.1500 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
p3> import sys
p3> sys.setrecursionlimit(20)
p3> def g(): g()
...
p3> g()
Traceback (most recent call last):
...
RuntimeError: maximum recursion depth exceeded
p3> g()
Fatal Python error: Cannot recover from stack overflow.
This application has requested the Runtime to terminate it in an
unusual way.
Please contact the application's support team for more information.
C:\APPS\python\py3k\PCbuild>
----------
components: Interpreter Core
messages: 82906
nosy: gagenellina
severity: normal
status: open
title: stack overflow after hitting recursion limit twice
type: crash
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5392>
_______________________________________
From report at bugs.python.org Sat Feb 28 16:29:52 2009
From: report at bugs.python.org (Michael Newman)
Date: Sat, 28 Feb 2009 15:29:52 +0000
Subject: [New-bugs-announce] [issue5393] cmath.cos and cmath.cosh have
"nResult" typo in help
In-Reply-To: <1235834992.19.0.175086711499.issue5393@psf.upfronthosting.co.za>
Message-ID: <1235834992.19.0.175086711499.issue5393@psf.upfronthosting.co.za>
New submission from Michael Newman <michael.b.newman at gmail.com>:
cmath.cos and cmath.cosh have "nResult" typo in their help text.
"""
Python 3.0.1 (r301:69561, Feb 13 2009, 20:04:18) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import cmath
>>> help(cmath.cos)
Help on built-in function cos in module cmath:
cos(...)
cos(x)
nReturn the cosine of x.
>>> help(cmath.cosh)
Help on built-in function cosh in module cmath:
cosh(...)
cosh(x)
nReturn the hyperbolic cosine of x.
"""
Likewise in Py26, Py25, and Py24...
"""
Python 2.6.1 (r261:67517, Dec 4 2008, 16:51:00) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import cmath
>>> help(cmath.cos)
Help on built-in function cos in module cmath:
cos(...)
cos(x)
nReturn the cosine of x.
>>> help(cmath.cosh)
Help on built-in function cosh in module cmath:
cosh(...)
cosh(x)
nReturn the hyperbolic cosine of x.
"""
"""
Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import cmath
>>> help(cmath.cos)
Help on built-in function cos in module cmath:
cos(...)
cos(x)
nReturn the cosine of x.
>>> help(cmath.cosh)
Help on built-in function cosh in module cmath:
cosh(...)
cosh(x)
nReturn the hyperbolic cosine of x.
"""
"""
Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import cmath
>>> help(cmath.cos)
Help on built-in function cos in module cmath:
cos(...)
cos(x)
nReturn the cosine of x.
>>> help(cmath.cosh)
Help on built-in function cosh in module cmath:
cosh(...)
cosh(x)
nReturn the hyperbolic cosine of x.
"""
----------
assignee: georg.brandl
components: Documentation
messages: 82915
nosy: georg.brandl, mnewman
severity: normal
status: open
title: cmath.cos and cmath.cosh have "nResult" typo in help
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5393>
_______________________________________
From report at bugs.python.org Sat Feb 28 17:57:06 2009
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 28 Feb 2009 16:57:06 +0000
Subject: [New-bugs-announce] [issue5394] Distutils in trunk does not work
with old Python (2.3 - 2.5)
In-Reply-To: <1235840226.43.0.117116762922.issue5394@psf.upfronthosting.co.za>
Message-ID: <1235840226.43.0.117116762922.issue5394@psf.upfronthosting.co.za>
New submission from Akira Kitada <akitada at gmail.com>:
As written in its README, "Distutils must remain compatible with 2.3",
but it isn't. Attached patch fixes this.
----------
assignee: tarek
components: Distutils
files: python23_compat.diff
keywords: patch
messages: 82920
nosy: akitada, tarek
severity: normal
status: open
title: Distutils in trunk does not work with old Python (2.3 - 2.5)
type: compile error
Added file: http://bugs.python.org/file13211/python23_compat.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5394>
_______________________________________
From report at bugs.python.org Sat Feb 28 19:30:24 2009
From: report at bugs.python.org (Eduardo Aguiar)
Date: Sat, 28 Feb 2009 18:30:24 +0000
Subject: [New-bugs-announce] [issue5395] array.fromfile not checking I/O
errors
In-Reply-To: <1235845824.28.0.0746931050705.issue5395@psf.upfronthosting.co.za>
Message-ID: <1235845824.28.0.0746931050705.issue5395@psf.upfronthosting.co.za>
New submission from Eduardo Aguiar <aguiar at users.sourceforge.net>:
At arraymodule.c (line 1258):
nread = fread(item + (Py_SIZE(self) - n) * itemsize,
itemsize, n, fp);
if (nread < (size_t)n) {
Py_SIZE(self) -= (n - nread);
PyMem_RESIZE(item, char, Py_SIZE(self)*itemsize);
self->ob_item = item;
self->allocated = Py_SIZE(self);
PyErr_SetString(PyExc_EOFError,
"not enough items in file");
return NULL;
}
When fread returns 0, ferror should be called to check if it was an EOF
or an error condition. It is not handling OSErrors, such as I/O errors,
raising always "not enough items in file".
----------
components: Library (Lib)
messages: 82936
nosy: aguiar
severity: normal
status: open
title: array.fromfile not checking I/O errors
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5395>
_______________________________________
From report at bugs.python.org Sat Feb 28 20:02:31 2009
From: report at bugs.python.org (Eduardo Aguiar)
Date: Sat, 28 Feb 2009 19:02:31 +0000
Subject: [New-bugs-announce] [issue5396] os.read not handling O_DIRECT flag
In-Reply-To: <1235847751.77.0.558509867366.issue5396@psf.upfronthosting.co.za>
Message-ID: <1235847751.77.0.558509867366.issue5396@psf.upfronthosting.co.za>
New submission from Eduardo Aguiar <aguiar at users.sourceforge.net>:
At posixmodule.c (line 6306)
static PyObject *
posix_read(PyObject *self, PyObject *args)
{
int fd, size, n;
PyObject *buffer;
if (!PyArg_ParseTuple(args, "ii:read", &fd, &size))
return NULL;
if (size < 0) {
errno = EINVAL;
return posix_error();
}
buffer = PyString_FromStringAndSize((char *)NULL, size);
if (buffer == NULL)
return NULL;
Py_BEGIN_ALLOW_THREADS
n = read(fd, PyString_AsString(buffer), size);
Py_END_ALLOW_THREADS
if (n < 0) {
Py_DECREF(buffer);
return posix_error();
}
if (n != size)
_PyString_Resize(&buffer, n);
return buffer;
}
os.read does not work with O_DIRECT flag. It fails with errno = EINVAL.
>From read(2) man page:
EINVAL fd is attached to an object which is unsuitable for
reading; or
the file was opened with the O_DIRECT flag, and
either the
address specified in buf, the value specified in count,
or the
current file offset is not suitably aligned.
if os.open is called with O_DIRECT flag enabled, the buffer used in
"read" must be page aligned and "size" must be multiple of pagesize also.
----------
components: Library (Lib)
messages: 82938
nosy: aguiar
severity: normal
status: open
title: os.read not handling O_DIRECT flag
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5396>
_______________________________________