From report at bugs.python.org Sat Aug 1 18:09:06 2009
From: report at bugs.python.org (OG7)
Date: Sat, 01 Aug 2009 16:09:06 +0000
Subject: [New-bugs-announce] [issue6615] multiprocessing logging support test
In-Reply-To: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
Message-ID: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
New submission from OG7 <onyxg7 at users.sourceforge.net>:
There is an additional test for multiprocessing's logging support here:
http://code.google.com/p/python-multiprocessing/issues/detail?id=18
(disregard the fix, it is only needed for the backport).
----------
components: Library (Lib)
messages: 91163
nosy: OG7, jnoller
severity: normal
status: open
title: multiprocessing logging support test
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________
From report at bugs.python.org Sat Aug 1 22:43:47 2009
From: report at bugs.python.org (Campbell Barton)
Date: Sat, 01 Aug 2009 20:43:47 +0000
Subject: [New-bugs-announce] [issue6616] PyList_APPEND (append without
incref)
In-Reply-To: <1249159427.67.0.400493436196.issue6616@psf.upfronthosting.co.za>
Message-ID: <1249159427.67.0.400493436196.issue6616@psf.upfronthosting.co.za>
New submission from Campbell Barton <ideasman42 at gmail.com>:
This patch was made on python r74276
Often when writing in C/Python I want to append to a list within a C
loop of an unknown length.
When this is done for newly created PyObject (which is quite common) -
you need to assign each item to a variable and then decref it.
eg:
PyObject *item= PyFloat_FromDouble(x);
PyList_Append(list, item);
Py_DECREF(item);
I have seen people make mistakes with this (in pygame code and
blender3d), and run PyList_Append(list, PyFloat_FromDouble(x)),
ofcourse this is not the fault of python/c api that devs do not read
docs properly but I think it would be very convenient to have an append
that works in a similar way to PyList_SET_ITEM
This simple patch allows...
PyList_APPEND(list, PyFloat_FromDouble(x))
doc included.
----------
files: py3_APPEND.diff
keywords: patch
messages: 91167
nosy: ideasman42
severity: normal
status: open
title: PyList_APPEND (append without incref)
versions: Python 3.2
Added file: http://bugs.python.org/file14619/py3_APPEND.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6616>
_______________________________________
From report at bugs.python.org Sat Aug 1 23:37:57 2009
From: report at bugs.python.org (Sandip Thorat)
Date: Sat, 01 Aug 2009 21:37:57 +0000
Subject: [New-bugs-announce] [issue6617] During compiling python 3.1 getting
error Undefined symbol libintl_bind_textdomain_codeset
In-Reply-To: <1249162677.96.0.181878890277.issue6617@psf.upfronthosting.co.za>
Message-ID: <1249162677.96.0.181878890277.issue6617@psf.upfronthosting.co.za>
New submission from Sandip Thorat <thoratsandip at gmail.com>:
Hi
I am installing Python-3.1 on "SunOS sunx7qa 5.10 Generic_127112-06
i86pc i386 i86pc".
./configure done without any error.
But 'make' throwing folloing error:
gcc -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-
prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -
DSVNVERSION="\"`LC_ALL=C echo Unversioned directory`\"" -o
Modules/getbuildinfo.o ./Modules/getbuildinfo.c
rm -f libpython3.1.a
ar rc libpython3.1.a Modules/getbuildinfo.o
ar rc libpython3.1.a Parser/acceler.o Parser/grammar1.o
Parser/listnode.o Parser/node.o Parser/parser.o Parser/parsetok.o
Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o
Parser/grammar.o Parser/pgen.o Parser/myreadline.o Parser/tokenizer.o
ar rc libpython3.1.a Objects/abstract.o Objects/boolobject.o
Objects/bytes_methods.o Objects/bytearrayobject.o
Objects/bytesobject.o Objects/cellobject.o Objects/classobject.o
Objects/cobject.o Objects/codeobject.o Objects/complexobject.o
Objects/descrobject.o Objects/enumobject.o Objects/exceptions.o
Objects/genobject.o Objects/fileobject.o Objects/floatobject.o
Objects/frameobject.o Objects/funcobject.o Objects/iterobject.o
Objects/listobject.o Objects/longobject.o Objects/dictobject.o
Objects/memoryobject.o Objects/methodobject.o Objects/moduleobject.o
Objects/object.o Objects/obmalloc.o Objects/capsule.o
Objects/rangeobject.o Objects/setobject.o Objects/sliceobject.o
Objects/structseq.o Objects/tupleobject.o Objects/typeobject.o
Objects/unicodeobject.o Objects/unicodectype.o Objects/weakrefobject.o
ar rc libpython3.1.a Python/_warnings.o Python/Python-ast.o
Python/asdl.o Python/ast.o Python/bltinmodule.o Python/ceval.o
Python/compile.o Python/codecs.o Python/errors.o Python/frozen.o
Python/frozenmain.o Python/future.o Python/getargs.o
Python/getcompiler.o Python/getcopyright.o Python/getplatform.o
Python/getversion.o Python/graminit.o Python/import.o
Python/importdl.o Python/marshal.o Python/modsupport.o
Python/mystrtoul.o Python/mysnprintf.o Python/peephole.o
Python/pyarena.o Python/pyctype.o Python/pyfpe.o Python/pymath.o
Python/pystate.o Python/pythonrun.o Python/structmember.o
Python/symtable.o Python/sysmodule.o Python/traceback.o
Python/getopt.o Python/pystrcmp.o Python/pystrtod.o Python/dtoa.o
Python/formatter_unicode.o Python/dynload_shlib.o Python/thread.o
ar rc libpython3.1.a Modules/config.o Modules/getpath.o
Modules/main.o Modules/gcmodule.o
ar rc libpython3.1.a Modules/_threadmodule.o Modules/signalmodule.o
Modules/posixmodule.o Modules/errnomodule.o Modules/pwdmodule.o
Modules/_sre.o Modules/_codecsmodule.o Modules/_weakref.o
Modules/_functoolsmodule.o Modules/_localemodule.o
Modules/_iomodule.o Modules/iobase.o Modules/fileio.o Modules/bytesio.o
Modules/bufferedio.o Modules/textio.o Modules/stringio.o
Modules/zipimport.o Modules/symtablemodule.o Modules/xxsubtype.o
ranlib libpython3.1.a
gcc -o python \
Modules/python.o \
libpython3.1.a -lresolv -lsocket -lnsl -lrt -ldl -lm
Undefined first referenced
symbol in file
libintl_bind_textdomain_codeset libpython3.1.a(_localemodule.o)
libintl_gettext libpython3.1.a(_localemodule.o)
libintl_textdomain libpython3.1.a(_localemodule.o)
libintl_dcgettext libpython3.1.a(_localemodule.o)
libintl_bindtextdomain libpython3.1.a(_localemodule.o)
libintl_dgettext libpython3.1.a(_localemodule.o)
ld: fatal: Symbol referencing errors. No output written to python
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `python'
bash-3.00$ pwd
Need your help to resolve this issue.
----------
components: Installation
messages: 91170
nosy: thoratsandip
severity: normal
status: open
title: During compiling python 3.1 getting error Undefined symbol libintl_bind_textdomain_codeset
type: compile error
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6617>
_______________________________________
From report at bugs.python.org Sat Aug 1 23:55:16 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Sat, 01 Aug 2009 21:55:16 +0000
Subject: [New-bugs-announce] [issue6618] Typo in a listing in 5.2.9 of
language reference
In-Reply-To: <1249163716.22.0.790124274674.issue6618@psf.upfronthosting.co.za>
Message-ID: <1249163716.22.0.790124274674.issue6618@psf.upfronthosting.co.za>
New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:
Error in:
Python v3.1 documentation >> The Python language reference >>
In the listing at the end of section 5.2.9 Yield expressions,
line 7:
... except Exception, e:
is syntactically incorrect and consequently raises a Syntax Error.
Should read:
... except Exception as e:
----------
assignee: georg.brandl
components: Documentation
messages: 91171
nosy: georg.brandl, gregorlingl
severity: normal
status: open
title: Typo in a listing in 5.2.9 of language reference
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6618>
_______________________________________
From report at bugs.python.org Sun Aug 2 00:13:55 2009
From: report at bugs.python.org (Vincent Legoll)
Date: Sat, 01 Aug 2009 22:13:55 +0000
Subject: [New-bugs-announce] [issue6619] Remove duplicated function in
Lib/inspect.py
In-Reply-To: <1249164835.58.0.202112743442.issue6619@psf.upfronthosting.co.za>
Message-ID: <1249164835.58.0.202112743442.issue6619@psf.upfronthosting.co.za>
New submission from Vincent Legoll <vincent.legoll at gmail.com>:
The isgenerator() function looks duplicated, remove the one with the
shortest docstring
----------
components: Library (Lib)
files: py3k-inspect.py-remove-duplicated-func.patch
keywords: patch
messages: 91172
nosy: vincele
severity: normal
status: open
title: Remove duplicated function in Lib/inspect.py
versions: Python 3.2
Added file: http://bugs.python.org/file14621/py3k-inspect.py-remove-duplicated-func.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6619>
_______________________________________
From report at bugs.python.org Sun Aug 2 00:18:37 2009
From: report at bugs.python.org (Vincent Legoll)
Date: Sat, 01 Aug 2009 22:18:37 +0000
Subject: [New-bugs-announce] [issue6620] Variable may be used before first
being assigned to in Lib/locale.py
In-Reply-To: <1249165117.85.0.22004101137.issue6620@psf.upfronthosting.co.za>
Message-ID: <1249165117.85.0.22004101137.issue6620@psf.upfronthosting.co.za>
New submission from Vincent Legoll <vincent.legoll at gmail.com>:
The last_interval variable could potentially be used before being first
assigned a value.
----------
components: Library (Lib)
files: py3k-locale.py-use-before-assignment.patch
keywords: patch
messages: 91173
nosy: vincele
severity: normal
status: open
title: Variable may be used before first being assigned to in Lib/locale.py
versions: Python 3.2
Added file: http://bugs.python.org/file14622/py3k-locale.py-use-before-assignment.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6620>
_______________________________________
From report at bugs.python.org Sun Aug 2 00:22:06 2009
From: report at bugs.python.org (Vincent Legoll)
Date: Sat, 01 Aug 2009 22:22:06 +0000
Subject: [New-bugs-announce] [issue6621] [RFC] Remove leftover use of Carbon
module from Lib/binhex.py
In-Reply-To: <1249165326.88.0.231668096917.issue6621@psf.upfronthosting.co.za>
Message-ID: <1249165326.88.0.231668096917.issue6621@psf.upfronthosting.co.za>
New submission from Vincent Legoll <vincent.legoll at gmail.com>:
The binhex module still has uses of the deprecated and now now removed
Carbon module.
The attached patch 'fix' this by removing the code, something else may
be required, but I don't know what.
So this is only a RFC to start discussion
----------
components: Library (Lib)
files: py3k-binhex.py-remove-carbon-module-use.patch
keywords: patch
messages: 91174
nosy: vincele
severity: normal
status: open
title: [RFC] Remove leftover use of Carbon module from Lib/binhex.py
versions: Python 3.2
Added file: http://bugs.python.org/file14623/py3k-binhex.py-remove-carbon-module-use.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6621>
_______________________________________
From report at bugs.python.org Sun Aug 2 00:24:47 2009
From: report at bugs.python.org (Vincent Legoll)
Date: Sat, 01 Aug 2009 22:24:47 +0000
Subject: [New-bugs-announce] [issue6622] [RFC] wrong variable used in
Lib/poplib.py
In-Reply-To: <1249165487.21.0.506053747681.issue6622@psf.upfronthosting.co.za>
Message-ID: <1249165487.21.0.506053747681.issue6622@psf.upfronthosting.co.za>
New submission from Vincent Legoll <vincent.legoll at gmail.com>:
The poplib modules use the 'secret' variable during its creation, this
may be a mistake. Perhaps the intention was to use the 'password' instead...
----------
components: Library (Lib)
files: py3k-poplib.py-use-wrong-variable.patch
keywords: patch
messages: 91175
nosy: vincele
severity: normal
status: open
title: [RFC] wrong variable used in Lib/poplib.py
versions: Python 3.2
Added file: http://bugs.python.org/file14624/py3k-poplib.py-use-wrong-variable.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6622>
_______________________________________
From report at bugs.python.org Sun Aug 2 00:25:35 2009
From: report at bugs.python.org (Vincent Legoll)
Date: Sat, 01 Aug 2009 22:25:35 +0000
Subject: [New-bugs-announce] [issue6623] Lib/ftplib.py
Message-ID: <1249165535.5.0.936372690866.issue6623@psf.upfronthosting.co.za>
Changes by Vincent Legoll <vincent.legoll at gmail.com>:
----------
components: Library (Lib)
nosy: vincele
severity: normal
status: open
title: Lib/ftplib.py
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6623>
_______________________________________
From report at bugs.python.org Sun Aug 2 01:53:44 2009
From: report at bugs.python.org (Sean Reifschneider)
Date: Sat, 01 Aug 2009 23:53:44 +0000
Subject: [New-bugs-announce] [issue6624] PyArg_ParseTuple with "s" format
and NUL: Bogus TypeError detail string.
In-Reply-To: <1249170824.71.0.297411055704.issue6624@psf.upfronthosting.co.za>
Message-ID: <1249170824.71.0.297411055704.issue6624@psf.upfronthosting.co.za>
New submission from Sean Reifschneider <jafo at tummy.com>:
As detailed in the python-dev post:
http://mail.python.org/pipermail/python-dev/2009-July/090791.html
I have found a bug in the handling of PyArg_ParseTuple where a NUL in an
argument causes a message like this:
syslog.syslog('hello\0there')
TypeError: [priority,] message string
Instead of:
TypeError: must be string without null bytes, not str
This seems to be a thinko in Python/getargs.c at line 331:
msg = convertitem(PyTuple_GET_ITEM(args, i), &format, p_va,
flags, levels, msgbuf,
sizeof(msgbuf), &freelist);
if (msg) {
seterror(i+1, msg, levels, fname, message); <<< Line 331
return cleanreturn(0, freelist);
}
This also applies to Python 3 trunk in line 390.
I think that's supposed to be "msg" instead of "message" in the last
argument.
I have made this change and "make test" for both python and py3k trunks
is clean.
----------
assignee: jafo
components: Interpreter Core
messages: 91177
nosy: jafo
priority: normal
severity: normal
stage: committed/rejected
status: open
title: PyArg_ParseTuple with "s" format and NUL: Bogus TypeError detail string.
type: behavior
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6624>
_______________________________________
From report at bugs.python.org Sun Aug 2 15:00:48 2009
From: report at bugs.python.org (Christoph Burgmer)
Date: Sun, 02 Aug 2009 13:00:48 +0000
Subject: [New-bugs-announce] [issue6625] UnicodeEncodeError on pydoc's CLI
In-Reply-To: <1249218048.23.0.0483172452601.issue6625@psf.upfronthosting.co.za>
Message-ID: <1249218048.23.0.0483172452601.issue6625@psf.upfronthosting.co.za>
New submission from Christoph Burgmer <cburgmer at ira.uka.de>:
pydoc fails with a UnicodeEncodeError for properly specified Unicode
docstrings (u"""...""") on the command line interface.
See attached patch that encodes the output with the system's encoding.
----------
components: Extension Modules
files: unicode.patch
keywords: patch
messages: 91182
nosy: christoph
severity: normal
status: open
title: UnicodeEncodeError on pydoc's CLI
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14626/unicode.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6625>
_______________________________________
From report at bugs.python.org Sun Aug 2 21:19:23 2009
From: report at bugs.python.org (Jacob Rus)
Date: Sun, 02 Aug 2009 19:19:23 +0000
Subject: [New-bugs-announce] [issue6626] show Python mimetypes module some
love
In-Reply-To: <1249240763.95.0.402656374782.issue6626@psf.upfronthosting.co.za>
Message-ID: <1249240763.95.0.402656374782.issue6626@psf.upfronthosting.co.za>
New submission from Jacob Rus <jacobolus at gmail.com>:
See discussion started right at the end of the month at
http://mail.python.org/pipermail/python-dev/2009-July/090928.html
And continued at
http://mail.python.org/pipermail/python-dev/2009-August/thread.html
Basically, the mimetypes module is fragile and very confusing code,
built up over years of feature creep without refactoring or careful
overall design. I'd like to cut it down to a more manageable code size,
fix some bugs, update the included list of mime types, and use some nice
Python features of versions 2.2+. Ideally someone reading the module
once through would be able to understand what it does.
Patches to be attached shortly.
----------
components: Library (Lib)
messages: 91196
nosy: jrus
severity: normal
status: open
title: show Python mimetypes module some love
type: behavior
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6626>
_______________________________________
From report at bugs.python.org Sun Aug 2 22:02:44 2009
From: report at bugs.python.org (Nikolaus Rath)
Date: Sun, 02 Aug 2009 20:02:44 +0000
Subject: [New-bugs-announce] [issue6627] threading.local() does not work
with C-created threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
New submission from Nikolaus Rath <Nikolaus at rath.org>:
When threads are created by a C extension loaded with ctypes,
threading.local() objects are always empty. If one uses
_threading_local.local() instead of threading.local(), the problem does
not occur.
More information and example program showing the behaviour:
http://code.google.com/p/fusepy/issues/detail?id=15
----------
components: Library (Lib)
messages: 91198
nosy: Nikratio
severity: normal
status: open
title: threading.local() does not work with C-created threads
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6627>
_______________________________________
From report at bugs.python.org Mon Aug 3 01:15:46 2009
From: report at bugs.python.org (brian)
Date: Sun, 02 Aug 2009 23:15:46 +0000
Subject: [New-bugs-announce] [issue6628] IDLE freezes after encountering a
syntax error
In-Reply-To: <1249254946.68.0.209899290876.issue6628@psf.upfronthosting.co.za>
Message-ID: <1249254946.68.0.209899290876.issue6628@psf.upfronthosting.co.za>
New submission from brian <omniscient.brian at gmail.com>:
Running Python 3.1/ IDLE, which was installed on top of a Python 2.5.4
install, Mac OSX 10.4
This seems like such an obvious bug, but I can't find it in the current
list of issues - so I suspect that it may not be reproducible on other
computers, but it's certainly reproducible on my laptop.
If I run a module with (any?) syntax error (for example,
for i in range(10) #missing semicolon
print i
the interpreter will catch it and send you to fix it. Then, any
subsequent attempts to run that same module will freeze IDLE. The
problem doesn't occur if you run a different module.
----------
components: IDLE
messages: 91210
nosy: brian89
severity: normal
status: open
title: IDLE freezes after encountering a syntax error
type: crash
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6628>
_______________________________________
From report at bugs.python.org Mon Aug 3 08:47:41 2009
From: report at bugs.python.org (Javier)
Date: Mon, 03 Aug 2009 06:47:41 +0000
Subject: [New-bugs-announce] [issue6630] string.Template custom pattern not
working
In-Reply-To: <1249282061.67.0.26692722483.issue6630@psf.upfronthosting.co.za>
Message-ID: <1249282061.67.0.26692722483.issue6630@psf.upfronthosting.co.za>
New submission from Javier <javier.collado at gmail.com>:
In the string.Template documentation
(http://docs.python.org/library/string.html) it's explained that if a
custom regular expression for pattern substitution is needed, it's
possible to override idpattern class attribute (whose default value is
[_a-z][_a-z0-9]*).
However, if the custom pattern that is needed is just uppercase
letters, something like [A-Z]+ won't work because of the following line
in the _TemplateMetaclass class __init__ method:
cls.pattern = _re.compile(pattern, _re.IGNORECASE | _re.VERBOSE)
I would say that this is an error (IGNORECASE just shouldn't be there)
and that the line above should be:
cls.pattern = _re.compile(pattern, _re.VERBOSE)
and the default value for idpattern:
[_a-zA-Z][_a-zA-Z0-9]*
Do you agree on this? Is there any reason for the IGNORECASE option to
be passed to re.compile?
----------
components: IO, Regular Expressions
messages: 91217
nosy: jcollado
severity: normal
status: open
title: string.Template custom pattern not working
type: behavior
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6630>
_______________________________________
From report at bugs.python.org Mon Aug 3 15:33:03 2009
From: report at bugs.python.org (albert Mietus)
Date: Mon, 03 Aug 2009 13:33:03 +0000
Subject: [New-bugs-announce] [issue6631] urlparse.urlunsplit() can't handle
relative files (for urllib*.open()
In-Reply-To: <1249306383.87.0.829314243328.issue6631@psf.upfronthosting.co.za>
Message-ID: <1249306383.87.0.829314243328.issue6631@psf.upfronthosting.co.za>
New submission from albert Mietus <albert at mietus.nl>:
The functions urlparse.url{,un}split() and urllib{,2}.open() do not work
together for relative, local files, due a bug in urlunsplit.
Given a file f='./rel/path/to/file.html' it can be open directly by
urllib.open(f), but not in urllib2! as the later needs a scheme.
We can create a sound url with spilt/unspilt and a default scheme:
f2=urlparse.urlunsplit(urlparse.urlsplit(f,'file')); which works most
cases, HOWEVER a bogus netloc is added for relative filepaths.
If have isolated this "buggy" function, added some local testcode and
made patch/workaround in my file 'unsplit.py' Which is included. Hope
this will contribute to a real patch.
--Groetjes, Albert
ALbert Mietus
Don't send spam mail!
Mijn missie: http://SoftwareBeterMaken.nl product, proces & imago.
Mijn leven in het kort:
http://albert.mietus.nl/Doc/CV_ALbert.html
----------
components: Library (Lib)
files: unsplit.py
messages: 91222
nosy: albert
severity: normal
status: open
title: urlparse.urlunsplit() can't handle relative files (for urllib*.open()
type: performance
Added file: http://bugs.python.org/file14637/unsplit.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6631>
_______________________________________
From report at bugs.python.org Mon Aug 3 04:00:41 2009
From: report at bugs.python.org (Karoly Lorentey)
Date: Mon, 03 Aug 2009 02:00:41 +0000
Subject: [New-bugs-announce] [issue6629] seek doesn't properly handle file
buffer, leads to silent data corruption
In-Reply-To: <1249264841.18.0.232875994092.issue6629@psf.upfronthosting.co.za>
Message-ID: <1249264841.18.0.232875994092.issue6629@psf.upfronthosting.co.za>
New submission from Karoly Lorentey <karoly at lorentey.hu>:
The new io.BufferedRandom implementation in Python 3.1 has a broken seek
that seems not to properly handle the case when the target of the seek
lies inside the contents of the file buffer. It leaves the file object
in a confused state, such that the next write operation applies after
the end of the buffer(!) instead of the specified target.
I could reproduce the following symptoms on both Debian Lenny and Mac OS
X Leopard. I downloaded the Python 3.1 tarball from python.org, and
built it by hand using './configure && make'.
$ ./python.exe
Python 3.1 (r31:73572, Aug 3 2009, 02:32:10)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> open("test", "wb").write(b"A" * 10000)
10000
>>> file = open("test", "rb+")
>>> file.read(10) # Reads 4096 bytes into file buffer
b'AAAAAAAAAA'
>>> file.tell()
10
>>> file.seek(0)
0
>>> file.tell()
0
>>> file.write(b"B" * 10000) # This should overwrite the whole file
10000
>>> file.tell()
14096 # Hmm, 0 + 10000 == 14096?
>>> file.close()
>>> d = open("test", "rb").read()
>>> len(d)
14096 # ?!
>>> d[0:10] # The file should now consist of 10000 Bs...
b'AAAAAAAAAA'
>>> d[4090:4100]
b'AAAAAABBBB' # ... but the Bs only start after a buffer's worth of
As.
This bug has actually caused me some subtle, silent data corruption that
went undetected for quite a while. Hurray for backups!
The above code works fine in Python 3.0, and its Python 2.5 port also
produces correct results.
A workaround for 3.1 is to call flush before every seek.
----------
components: IO
messages: 91211
nosy: lorentey
severity: normal
status: open
title: seek doesn't properly handle file buffer, leads to silent data corruption
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6629>
_______________________________________
From report at bugs.python.org Mon Aug 3 18:34:45 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 03 Aug 2009 16:34:45 +0000
Subject: [New-bugs-announce] [issue6632] Include more fullwidth chars in the
decimal codec
In-Reply-To: <1249317285.35.0.709481915004.issue6632@psf.upfronthosting.co.za>
Message-ID: <1249317285.35.0.709481915004.issue6632@psf.upfronthosting.co.za>
New submission from Ezio Melotti <ezio.melotti at gmail.com>:
The decimal codec only handles characters in the Nd (Number, decimal)
Unicode category and whitespaces [a]. It is used by int(), float(),
complex() and indirectly by Decimal(), Fraction() and possibly others.
This works well only for plain digits (e.g. int(u'???')) but it
doesn't work for all the other characters used to represent numbers, like:
1. plus or minus sign, e.g. int(u'????') or int(u'????')
2. decimal point, e.g. float(u'????')
2.1 some languages/alphabets use other chars (e.g. a comma or other
symbols) instead of the decimal point.
3. exponential notation, e.g. float(u'???')
4. the 'j' in complex numbers, e.g. complex(u'??')
5. the 'x' and 'p' in hexadecimal floats, e.g.
float.fromhex(u'???????')
5.1 hex floats also uses hexadecimal digits, see 6.3
6. digits > 9 for numbers with a base > 10, e.g. int(u'??', 16)
6.1 not all the alphabets have the equivalent of the letters a-z
6.2 afaik there are no standards that specify how to deal with
digits >9
6.3 in the Unicode FAQ [b] there's a link to a table [c] that says
"Code points not listed in this file are not hexadecimal
digits." This is not a standard though, and even if in the
UCD [d] there's a file [e] where the numbers with the Hex_Digit
property are defined, it doesn't say that *only* these numbers
are valid hex digits. Also it doesn't say anything about
different bases.
Python currently accepts int(u'??', 16), int(u'?', 16)
(U+096D - DEVANAGARI DIGIT SEVEN) and even int(u'?F', 16)
(with a normal F it works, with a fullwidth ? it fails).
6.4 UTS #18 [f] includes in the property 'xdigit' [g] (hexadecimal
digit) all the chars defined in [c] and also all the chars with
a Nd category. This also is not a standard, and it doesn't
give indications about the valid hex digits and how int()
should behave.
6.5 if possible re and int() should agree. Any string that matches
/^[[:xdigit:]]+$/ should work fine with int(s, 16) and vice
versa. See also #6561 [h] and #2636 [i].
7. possibly others
For all the chars listed in the points 1-5 there's no way, AFAIK, to
know their equivalents in other alphabets (if they exist at all) and
since (apparently) there's no standard that specifies how to handle
them, they should be kept out.
This will also avoid a number of problems, e.g. 2.1.
The fullwidth forms are an exception though: they seem to be the only
set of characters with a direct equivalent for all these chars, and they
are also the only non-ascii chars included in the list of chars with the
Unicode Hex_Digits property.
Including all the necessary chars from this range in the decimal codec
seems to me the best thing to do. The chars listed in the points 1-5
should all be implemented and they should work everywhere. The regex
used by Decimal/Fraction should be updated as well, since the decimal
codec is not accessible from Python (maybe it should be accessible, but
this is another issue).
Point 6 is a slightly different issue, even if it can be partially
solved if the fullwidth forms will be included. One of the possible
options is to limit the valid chars used by int() with bases > 10 only
to the characters listed in [c], but this won't be backward-compatible
with existing code and forward-compatible with [[:xdigit:]].
OTOH if we keep the current behavior it will be possible to express the
digits from 0 to 9 using several alphabets, but all the digits > 9 will
be limited to [a-fA-F] (and possibly [??????]).
For example, '7F' in the devanagari alphabet will result in a mix of
devanagari numbers and ascii letters, i.e. int(u'?F', 16) (this already
works in Python).
[a]:
http://svn.python.org/view/python/trunk/Objects/unicodeobject.c?view=markup
under 'Decimal Encoder'
[b]: http://unicode.org/faq/casemap_charprop.html#13
[c]: http://unicode.org/faq/hex-digit-values.txt - [0-9a-fA-
F?????????]
[d]: http://unicode.org/Public/UNIDATA/UCD.html#UCD_Files - PropList.txt
section
[e]: http://unicode.org/Public/UNIDATA/PropList.txt
[f]: http://unicode.org/reports/tr18/ - UTS #18: Unicode Regular Expressions
[g]: http://unicode.org/reports/tr18/#Compatibility_Properties - xdigit row
[h]: http://bugs.python.org/issue6561#msg90878 point (1) about int() and re
[i]: http://bugs.python.org/issue2636#msg65513 point 8) will introduce
[[:xdigit:]]
(Thanks to Mark Dickinson and Adam Olsen for pointing out some of these
issues.)
----------
components: Interpreter Core, Unicode
messages: 91225
nosy: ezio.melotti
priority: normal
severity: normal
status: open
title: Include more fullwidth chars in the decimal codec
type: feature request
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6632>
_______________________________________
From report at bugs.python.org Mon Aug 3 19:04:11 2009
From: report at bugs.python.org (James)
Date: Mon, 03 Aug 2009 17:04:11 +0000
Subject: [New-bugs-announce] [issue6633] No handlers could be found for
logger
In-Reply-To: <1249319051.14.0.476850462848.issue6633@psf.upfronthosting.co.za>
Message-ID: <1249319051.14.0.476850462848.issue6633@psf.upfronthosting.co.za>
New submission from James <purpleidea at gmail.com>:
I was trying to suppress the error message as shown in the title, when I
found out (by searching through the source) that there is a NullHandler
for precisely this purpose.
http://svn.python.org/view/python/trunk/Lib/logging/__init__.py?r1=66211&r2=67511
do you think that:
1) this could be documented maybe here (
http://docs.python.org/library/logging.html#handler-objects ) i suppose?
and:
2) this null handler doesn't seem to exist in:
Python 2.5.2 (r252:60911, Oct 5 2008, 19:24:49)
[GCC 4.3.2] on linux2
is this likely to get backported to 2.5? at the moment i've just
included the simple NullHandler class into my code.
3) also not my business really, but should it belong in the handlers.py
file?
thanks for all your hard work, i hope the comments are useful!
----------
components: Library (Lib)
messages: 91231
nosy: purpleidea
severity: normal
status: open
title: No handlers could be found for logger
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6633>
_______________________________________
From report at bugs.python.org Mon Aug 3 21:21:51 2009
From: report at bugs.python.org (Jan-Philip Gehrcke)
Date: Mon, 03 Aug 2009 19:21:51 +0000
Subject: [New-bugs-announce] [issue6634] sys.exit() called from threads
other than the main one: undocumented behaviour
In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za>
Message-ID: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za>
New submission from Jan-Philip Gehrcke <jgehrcke at gmail.com>:
Hey there,
hopefully I fill out this form in an adequate way!
I ran into some problems while using sys.exit('msg') together with
threads, which could have been avoided with slightly more information in
the docs here: http://docs.python.org/library/sys.html#sys.exit
Maybe the following two statements should not stay as they are:
(1) "Exit from Python."
-----------------------
This is not true when called from a thread other than the main one. We
could add a hint, saying that sys.exit() then actually behaves like
thread.exit(), which causes only the calling thread to exit, but not the
main program.
2) "[...] and any other object is printed to sys.stderr"
--------------------------------------------------------
This is also not true when called from a thread other than the main one.
Calling sys.exit('msg') then doesn't print anything to stderr. That was
annoying in my case and required debugging a bug that would have
discovered itself via stderr, if the message would have been printed..
:-) After some research, I think this behaviour is described in the
documentation for thread.exit(): "[...] this will cause the thread to
exit *silently*."
Okay, now that I am aware of this behaviour, I won't run into these
problems again. But the next one?
I think (1) is clearly a documentation thing. Regarding (2): first of
all, the documentation should say that the message is suppressed in
special cases (child threads). But: what argues against printing to
stderr here? I don't get the point and only see a lost feature,
affording a quick way to kill a thread while dropping an error message.
Was this kicked out intentionally? Maybe someone could help me with a
good argument here :-)
Thank you for your work,
Jan-Philip Gehrcke
----------
assignee: georg.brandl
components: Documentation
messages: 91237
nosy: georg.brandl, jgehrcke
severity: normal
status: open
title: sys.exit() called from threads other than the main one: undocumented behaviour
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/issue6634>
_______________________________________
From report at bugs.python.org Mon Aug 3 22:32:40 2009
From: report at bugs.python.org (Francesco Del Degan)
Date: Mon, 03 Aug 2009 20:32:40 +0000
Subject: [New-bugs-announce] [issue6635] Profiler doesn't print usage
(indexError instead)
In-Reply-To: <1249331560.84.0.146355793731.issue6635@psf.upfronthosting.co.za>
Message-ID: <1249331560.84.0.146355793731.issue6635@psf.upfronthosting.co.za>
New submission from Francesco Del Degan <f.deldegan at ngi.it>:
$ python -m profile
Usage: profile.py [-o output_file_path] [-s sort] scriptfile [arg] ...
$ python -m profile -s calls
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/runpy.py", line 122, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/runpy.py", line 34, in _run_code
exec code in run_globals
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/profile.py", line 619, in <module>
main()
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/profile.py", line 614, in main
parser.print_usage()
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/optparse.py", line 1584, in print_usage
print >>file, self.get_usage()
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/optparse.py", line 1570, in get_usage
self.expand_prog_name(self.usage))
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/optparse.py", line 1547, in expand_prog_name
return s.replace("%prog", self.get_prog_name())
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/optparse.py", line 1542, in get_prog_name
return os.path.basename(sys.argv[0])
IndexError: list index out of range
This is triggered by an early override of sys.argv when usage() is called (Lib/profile.py:603):
if not sys.argv[1:]:
parser.print_usage()
sys.exit(2)
(options, args) = parser.parse_args()
sys.argv[:] = args
if (len(sys.argv) > 0):
sys.path.insert(0, os.path.dirname(sys.argv[0]))
run('execfile(%r)' % (sys.argv[0],), options.outfile, options.sort)
else:
parser.print_usage()
return parser
In the "else" branch it tries to print usage but sys.argv[] were already overwritten.
Attached is the proposed patch (tested with 2.5, 2.6, 3.1).
----------
components: Library (Lib)
files: python-profile-sysargv.patch
keywords: patch
messages: 91240
nosy: pr0gg3d
severity: normal
status: open
title: Profiler doesn't print usage (indexError instead)
type: behavior
versions: Python 2.5, Python 2.6, Python 3.1
Added file: http://bugs.python.org/file14639/python-profile-sysargv.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6635>
_______________________________________
From report at bugs.python.org Mon Aug 3 22:36:13 2009
From: report at bugs.python.org (Charles Mason)
Date: Mon, 03 Aug 2009 20:36:13 +0000
Subject: [New-bugs-announce] [issue6636] Non-existant directory in sys.path
prevents further imports
In-Reply-To: <1249331773.17.0.57338899812.issue6636@psf.upfronthosting.co.za>
Message-ID: <1249331773.17.0.57338899812.issue6636@psf.upfronthosting.co.za>
New submission from Charles Mason <cemasoniv at gmail.com>:
Steps to reproduce:
1) Add to sys.path a path that does not exist
2) Import a module, any module. This invokes get_path_importer over
every element of sys.path. The NullImporter __init__ method is called
and an instance created for each non-existing path element in sys.path.
3) Create the path and put a valid module in said path
4) Try to import that module.
Behavior is that the interpreter fails to import. This behavior seems
local to import.c only.
Attached a test case that shows "failed" for 2.5, 2.6, 3.0. 3.1rc1+. I
have yet to test on the trunk but I can/will do that if necessary.
I believe I can fix this myself but I want to verify this is incorrect
behavior (a bug) and not an "Undocumented Feature" (or hell, maybe it
*is* documented somewhere). I've skimmed over PEP 302 and didn't see
any relevant information.
If someone gives me the go ahead (or at least doesn't give me reason not
to), I'll get a patch put together, perhaps for several different "fixes".
----------
components: Interpreter Core
files: test.py
messages: 91241
nosy: cemasoniv
severity: normal
status: open
title: Non-existant directory in sys.path prevents further imports
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file14640/test.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6636>
_______________________________________
From report at bugs.python.org Mon Aug 3 23:25:52 2009
From: report at bugs.python.org (Tom Clarke)
Date: Mon, 03 Aug 2009 21:25:52 +0000
Subject: [New-bugs-announce] [issue6637] non-empty defaultdict .copy() fails
returning empty dict
In-Reply-To: <1249334752.4.0.485254518119.issue6637@psf.upfronthosting.co.za>
Message-ID: <1249334752.4.0.485254518119.issue6637@psf.upfronthosting.co.za>
New submission from Tom Clarke <t.clarke at ic.ac.uk>:
The enclosed script when run under 2.6.2 IDLE standard distribution on
x86 shows that shallow copy (.copy()) of a non-empty defaultdict object
returns an empty defaultdict!
Other ways to copy, e.g. defaultdict(none, d.items()), work fine.
Bug appears under:
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on win32
I have tested it on two different computers. They both also have the
visual installed from a v2.6 binary - but I can't see why this would
change standard libraries.
Hope I am not being stupid - this seems to big a bug to be real!
**Documentation on defaultdict states (nearly all) methods are same as
dict, and on dict defines copy() as returning a shallow copy.
**replace defaultdict by dict and this example works as expected
Best wishes, Tom
PS - I am new to python so forgive any stupidity!
----------
components: Library (Lib)
messages: 91242
nosy: tomcl
severity: normal
status: open
title: non-empty defaultdict .copy() fails returning empty dict
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6637>
_______________________________________
From report at bugs.python.org Tue Aug 4 02:02:24 2009
From: report at bugs.python.org (Kevin Quick)
Date: Tue, 04 Aug 2009 00:02:24 +0000
Subject: [New-bugs-announce] [issue6638] optparse parse_args argument
references wrong
In-Reply-To: <1249344144.51.0.386987314322.issue6638@psf.upfronthosting.co.za>
Message-ID: <1249344144.51.0.386987314322.issue6638@psf.upfronthosting.co.za>
New submission from Kevin Quick <kq1quick at gmail.com>:
In optparse description of "16.4.3.7. Parsing arguments" (http://
docs.python.org/library/optparse.html#parsing-arguments) the keyword
argument to parse_args is "values=None" but in the description of the
"options" return value and in the second sentence of the "Most common
usage..." paragraph following, it is referred to as the "options"
argument.
----------
assignee: georg.brandl
components: Documentation
messages: 91247
nosy: georg.brandl, kq1quick
severity: normal
status: open
title: optparse parse_args argument references wrong
type: resource usage
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6638>
_______________________________________
From report at bugs.python.org Tue Aug 4 02:09:25 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 04 Aug 2009 00:09:25 +0000
Subject: [New-bugs-announce] [issue6639] turtle: _tkinter.TclError: invalid
command name ".10170160"
In-Reply-To: <1249344565.24.0.634557720335.issue6639@psf.upfronthosting.co.za>
Message-ID: <1249344565.24.0.634557720335.issue6639@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
I tried the following turtle program; it was taking some time to
draw .. so I pressed C-c after which I saw the exception traceback.
> cat play.py
from turtle import *
def f(length, depth):
if depth == 0:
forward(length)
else:
f(length/3, depth-1)
right(60)
f(length/3, depth-1)
left(120)
f(length/3, depth-1)
right(60)
f(length/3, depth-1)
f(500, 4)
> python play.py
Traceback (most recent call last):
File "/Users/sridharr/as/pypm/bin/python", line 41, in <module>
execfile(sys.argv[0])
File "play.py", line 15, in <module>
f(500, 4)
File "play.py", line 11, in f
f(length/3, depth-1)
File "play.py", line 7, in f
f(length/3, depth-1)
File "play.py", line 9, in f
f(length/3, depth-1)
File "play.py", line 10, in f
left(120)
File "<string>", line 1, in left
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
lib-tk/turtle.py", line 1612, in left
self._rotate(angle)
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
lib-tk/turtle.py", line 3107, in _rotate
self._update()
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
lib-tk/turtle.py", line 2562, in _update
self._update_data()
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
lib-tk/turtle.py", line 2553, in _update_data
self._pencolor, self._pensize)
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
lib-tk/turtle.py", line 569, in _drawline
self.cv.coords(lineitem, *cl)
File "<string>", line 1, in coords
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
lib-tk/Tkinter.py", line 2136, in coords
self.tk.call((self._w, 'coords') + args)))
_tkinter.TclError: invalid command name ".10170160"
>
----------
components: Library (Lib)
messages: 91248
nosy: srid
severity: normal
status: open
title: turtle: _tkinter.TclError: invalid command name ".10170160"
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6639>
_______________________________________
From report at bugs.python.org Tue Aug 4 02:42:34 2009
From: report at bugs.python.org (Myk Melez)
Date: Tue, 04 Aug 2009 00:42:34 +0000
Subject: [New-bugs-announce] [issue6640] urlparse should parse mailto: URL
headers as query parameters
In-Reply-To: <1249346554.96.0.279967945769.issue6640@psf.upfronthosting.co.za>
Message-ID: <1249346554.96.0.279967945769.issue6640@psf.upfronthosting.co.za>
New submission from Myk Melez <myk at mozilla.org>:
RFC 2368 <http://www.ietf.org/rfc/rfc2368.txt> specifies mailto: URLs as
having the following syntax:
mailtoURL = "mailto:" [ to ] [ headers ]
to = #mailbox
headers = "?" header *( "&" header )
header = hname "=" hvalue
hname = *urlc
hvalue = *urlc
The header fields in these URLs are roughly analogous to query
parameters in other URLs, but urlparse treats them as part of the path
(along with the email address):
>>> import urlparse
>>> urlparse.urlparse("mailto:foo at example.com?subject=hi")
ParseResult(scheme='mailto', netloc='',
path='foo at example.com?subject=hi', params='', query='', fragment='')
It should treat them as query parameters instead, which would not only
make it easier to access them but would also make it easier to access
the email address, since one would no longer have to parse headers, if
any, out of the path first.
----------
components: Library (Lib)
messages: 91249
nosy: mykmelez
severity: normal
status: open
title: urlparse should parse mailto: URL headers as query parameters
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6640>
_______________________________________
From report at bugs.python.org Tue Aug 4 16:04:37 2009
From: report at bugs.python.org (Esteban Feldman)
Date: Tue, 04 Aug 2009 14:04:37 +0000
Subject: [New-bugs-announce] [issue6641] strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
New submission from Esteban Feldman <esteban.feldman at gmail.com>:
When trying to use datetime.strptime %z directive got an unexpected error.
>>> from datetime import datetime
>>>
>>> fecha = u'Sun Aug 02 19:01:25 +0000 2009'
>>> datetime.strptime(fecha, '%a %b %d %H:%M:%S %z %Y')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.6/_strptime.py", line 317, in _strptime
(bad_directive, format))
ValueError: 'z' is a bad directive in format '%a %b %d %H:%M:%S %z %Y'
----------
components: None
messages: 91256
nosy: Eka
severity: normal
status: open
title: strptime doesn't support %z format ?
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________
From report at bugs.python.org Tue Aug 4 20:21:50 2009
From: report at bugs.python.org (Reid Kleckner)
Date: Tue, 04 Aug 2009 18:21:50 +0000
Subject: [New-bugs-announce] [issue6642] returning after forking a child
thread doesn't call Py_Finalize
In-Reply-To: <1249410110.52.0.861898541816.issue6642@psf.upfronthosting.co.za>
Message-ID: <1249410110.52.0.861898541816.issue6642@psf.upfronthosting.co.za>
New submission from Reid Kleckner <rnk at mit.edu>:
I attached a test case to reproduce.
Here is what it does:
- The main thread in the parent process starts a new thread and waits
for it.
- The child thread forks.
- The child process creates a daemon thread, and returns.
- The parent process (in the thread that forked) calls os.waitpid(childpid).
What should happen is that the forked child process should terminate
because it shouldn't wait for the daemon thread, and
os.waitpid(childpid) should return after that, and then the main thread
should return from thread.join().
What happens is that because it was a child thread that forked, the C
stack starts inside of the pthread wrapper (or equivalent) instead of
main. So when child process returns, it doesn't know that it is now the
main thread, and it doesn't execute Py_Finalize. Furthermore, pthreads
doesn't call sys_exit_group because it thinks that it is a lone thread
returning, and it doesn't want to terminate the entire process group.
When you look at it with 'ps f', this is what it looks like:
24325 pts/3 Ss 0:01 bash
4453 pts/3 Sl 0:00 \_ ./python thread_fork_hang.py
4459 pts/3 Zl 0:07 | \_ [python] <defunct>
4467 pts/3 R+ 0:00 \_ ps f
Here's the stack traces from the parent process:
(gdb) bt
#0 0x00007ffff7bd0991 in sem_wait () from /lib/libpthread.so.0
#1 0x0000000000587abd in PyThread_acquire_lock (lock=0x12bb680,
waitflag=1) at ../../unladen2/Python/thread_pthread.h:349
#2 0x00000000005b1660 in lock_PyThread_acquire_lock
(self=0x7ffff7f37150, args=<value optimized out>)
at ../../unladen2/Modules/threadmodule.c:46
#3 0x000000000055b89d in _PyEval_CallFunction (stack_pointer=0x128ff20,
na=<value optimized out>, nk=0) at ../../unladen2/Python/eval.cc:4046
#4 0x000000000055644c in PyEval_EvalFrame (f=0x128fd60) at
../../unladen2/Python/eval.cc:2518
#5 0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7ef9670,
globals=0x1, locals=0x2, args=0x123bbd8, argcount=1, kws=0x123bbe0,
kwcount=0,
defs=0x7ffff7e540e8, defcount=1, closure=0x0) at
../../unladen2/Python/eval.cc:3093
#6 0x000000000055b7b0 in _PyEval_CallFunction (stack_pointer=0x123bbe0,
na=1, nk=0) at ../../unladen2/Python/eval.cc:4188
#7 0x000000000055644c in PyEval_EvalFrame (f=0x123ba40) at
../../unladen2/Python/eval.cc:2518
#8 0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7efea30,
globals=0x1, locals=0x2, args=0x12038c8, argcount=1, kws=0x12038d0,
kwcount=0,
defs=0x7ffff7e54368, defcount=1, closure=0x0) at
../../unladen2/Python/eval.cc:3093
#9 0x000000000055b7b0 in _PyEval_CallFunction (stack_pointer=0x12038d0,
na=1, nk=0) at ../../unladen2/Python/eval.cc:4188
#10 0x000000000055644c in PyEval_EvalFrame (f=0x1203750) at
../../unladen2/Python/eval.cc:2518
#11 0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7f55d50,
globals=0x0, locals=0x0, args=0x0, argcount=0, kws=0x0, kwcount=0,
defs=0x0,
defcount=0, closure=0x0) at ../../unladen2/Python/eval.cc:3093
#12 0x000000000055bc02 in PyEval_EvalCode (co=0x12bb680, globals=0x80,
locals=0x0) at ../../unladen2/Python/eval.cc:552
#13 0x000000000057deb1 in PyRun_FileExFlags (fp=0x1121260,
filename=0x7fffffffe6be "thread_fork_hang.py", start=<value optimized out>,
globals=0x10fa010, locals=0x10fa010, closeit=1,
flags=0x7fffffffe290) at ../../unladen2/Python/pythonrun.c:1359
#14 0x000000000057e167 in PyRun_SimpleFileExFlags (fp=0x1121260,
filename=0x7fffffffe6be "thread_fork_hang.py", closeit=1,
flags=0x7fffffffe290)
at ../../unladen2/Python/pythonrun.c:955
#15 0x00000000004d8954 in Py_Main (argc=-134459232, argv=<value
optimized out>) at ../../unladen2/Modules/main.c:695
#16 0x00007ffff6cdf1c4 in __libc_start_main () from /lib/libc.so.6
#17 0x00000000004d7ae9 in _start ()
(gdb) thread 2
[Switching to thread 2 (Thread 0x40800950 (LWP 4458))]#0
0x00007ffff7bd234f in waitpid () from /lib/libpthread.so.0
(gdb) bt
#0 0x00007ffff7bd234f in waitpid () from /lib/libpthread.so.0
#1 0x00000000005b6adf in posix_waitpid (self=<value optimized out>,
args=<value optimized out>) at ../../unladen2/Modules/posixmodule.c:5797
#2 0x000000000055b89d in _PyEval_CallFunction (stack_pointer=0x129cff8,
na=<value optimized out>, nk=0) at ../../unladen2/Python/eval.cc:4046
#3 0x000000000055644c in PyEval_EvalFrame (f=0x129ce60) at
../../unladen2/Python/eval.cc:2518
#4 0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7f558f0,
globals=0x0, locals=0x0, args=0x7ffff7f98068, argcount=0, kws=0x1239f70,
kwcount=0, defs=0x0, defcount=0, closure=0x0) at
../../unladen2/Python/eval.cc:3093
#5 0x00000000005d98fc in function_call (func=0x7ffff7eefc80,
arg=0x7ffff7f98050, kw=0x1286d20) at ../../unladen2/Objects/funcobject.c:524
#6 0x00000000004dc68d in PyObject_Call (func=0x7ffff7eefc80,
arg=0x7ffff7f98050, kw=0x1286d20) at ../../unladen2/Objects/abstract.c:2487
#7 0x00000000005549d0 in _PyEval_CallFunctionVarKw
(stack_pointer=0x129ce08, num_posargs=<value optimized out>, num_kwargs=0,
flags=<value optimized out>) at ../../unladen2/Python/eval.cc:45
#8 0x0000000000559de2 in PyEval_EvalFrame (f=0x129cc80) at
../../unladen2/Python/eval.cc:2560
#9 0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7efe710,
globals=0x1, locals=0x1, args=0x11f1478, argcount=1, kws=0x11f1480,
kwcount=0,
defs=0x0, defcount=0, closure=0x0) at ../../unladen2/Python/eval.cc:3093
#10 0x000000000055b7b0 in _PyEval_CallFunction (stack_pointer=0x11f1480,
na=1, nk=0) at ../../unladen2/Python/eval.cc:4188
#11 0x000000000055644c in PyEval_EvalFrame (f=0x11f12e0) at
../../unladen2/Python/eval.cc:2518
#12 0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7efe850,
globals=0x1, locals=0x1, args=0x11f1290, argcount=1, kws=0x11f1298,
kwcount=0,
defs=0x0, defcount=0, closure=0x0) at ../../unladen2/Python/eval.cc:3093
#13 0x000000000055b7b0 in _PyEval_CallFunction (stack_pointer=0x11f1298,
na=1, nk=0) at ../../unladen2/Python/eval.cc:4188
#14 0x000000000055644c in PyEval_EvalFrame (f=0x11f1110) at
../../unladen2/Python/eval.cc:2518
#15 0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7efe7b0,
globals=0x1, locals=0x1, args=0x7ffff7ee9fe8, argcount=1, kws=0x0,
kwcount=0,
defs=0x0, defcount=0, closure=0x0) at ../../unladen2/Python/eval.cc:3093
#16 0x00000000005d97fd in function_call (func=0x7ffff7e55ed8,
arg=0x7ffff7ee9fd0, kw=0x0) at ../../unladen2/Objects/funcobject.c:524
#17 0x00000000004dc68d in PyObject_Call (func=0x7ffff7e55ed8,
arg=0x7ffff7ee9fd0, kw=0x0) at ../../unladen2/Objects/abstract.c:2487
#18 0x00000000004e3bff in instancemethod_call (func=0x7ffff7e55ed8,
arg=0x7ffff7ee9fd0, kw=0x0) at ../../unladen2/Objects/classobject.c:2579
#19 0x00000000004dc68d in PyObject_Call (func=0x7ffff7f3c640,
arg=0x7ffff7f98050, kw=0x0) at ../../unladen2/Objects/abstract.c:2487
#20 0x0000000000553530 in PyEval_CallObjectWithKeywords
(func=0x7ffff7f3c640, arg=0x7ffff7f98050, kw=0x0) at
../../unladen2/Python/eval.cc:45
#21 0x00000000005b1a6d in t_bootstrap (boot_raw=0x125b300) at
../../unladen2/Modules/threadmodule.c:425
#22 0x00007ffff7bca3f7 in start_thread () from /lib/libpthread.so.0
#23 0x00007ffff6d98b3d in clone () from /lib/libc.so.6
#24 0x0000000000000000 in ?? ()
The child process is defunct, but you can still trace the left over
thread with and attach to that with GDB if you guess the process id. I
couldn't figure out how to get ps to tell it to me, though. Here's that
trace:
(gdb) bt
#0 0x0000000000558412 in PyEval_EvalFrame (f=0x1245190) at
../../unladen2/Python/eval.cc:2336
#1 0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7fce7b0,
globals=0x0, locals=0x0, args=0x7ffff7f98068, argcount=0, kws=0x10eb600,
kwcount=0, defs=0x0, defcount=0, closure=0x0) at
../../unladen2/Python/eval.cc:3093
#2 0x00000000005d98fc in function_call (func=0x7ffff7e56d70,
arg=0x7ffff7f98050, kw=0x123ba90) at ../../unladen2/Objects/funcobject.c:524
#3 0x00000000004dc68d in PyObject_Call (func=0x7ffff7e56d70,
arg=0x7ffff7f98050, kw=0x123ba90) at ../../unladen2/Objects/abstract.c:2487
#4 0x00000000005549d0 in _PyEval_CallFunctionVarKw
(stack_pointer=0x1245138, num_posargs=<value optimized out>, num_kwargs=0,
flags=<value optimized out>) at ../../unladen2/Python/eval.cc:45
#5 0x0000000000559de2 in PyEval_EvalFrame (f=0x1244fb0) at
../../unladen2/Python/eval.cc:2560
#6 0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7efe710,
globals=0x1, locals=0x1, args=0x1244ee8, argcount=1, kws=0x1244ef0,
kwcount=0,
defs=0x0, defcount=0, closure=0x0) at ../../unladen2/Python/eval.cc:3093
#7 0x000000000055b7b0 in _PyEval_CallFunction (stack_pointer=0x1244ef0,
na=1, nk=0) at ../../unladen2/Python/eval.cc:4188
#8 0x000000000055644c in PyEval_EvalFrame (f=0x1244d50) at
../../unladen2/Python/eval.cc:2518
#9 0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7efe850,
globals=0x1, locals=0x1, args=0x1247c00, argcount=1, kws=0x1247c08,
kwcount=0,
defs=0x0, defcount=0, closure=0x0) at ../../unladen2/Python/eval.cc:3093
#10 0x000000000055b7b0 in _PyEval_CallFunction (stack_pointer=0x1247c08,
na=1, nk=0) at ../../unladen2/Python/eval.cc:4188
#11 0x000000000055644c in PyEval_EvalFrame (f=0x1247a80) at
../../unladen2/Python/eval.cc:2518
#12 0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7efe7b0,
globals=0x1, locals=0x1, args=0x7ffff7ef0528, argcount=1, kws=0x0,
kwcount=0,
defs=0x0, defcount=0, closure=0x0) at ../../unladen2/Python/eval.cc:3093
#13 0x00000000005d97fd in function_call (func=0x7ffff7e55ed8,
arg=0x7ffff7ef0510, kw=0x0) at ../../unladen2/Objects/funcobject.c:524
#14 0x00000000004dc68d in PyObject_Call (func=0x7ffff7e55ed8,
arg=0x7ffff7ef0510, kw=0x0) at ../../unladen2/Objects/abstract.c:2487
#15 0x00000000004e3bff in instancemethod_call (func=0x7ffff7e55ed8,
arg=0x7ffff7ef0510, kw=0x0) at ../../unladen2/Objects/classobject.c:2579
#16 0x00000000004dc68d in PyObject_Call (func=0x7ffff7f53230,
arg=0x7ffff7f98050, kw=0x0) at ../../unladen2/Objects/abstract.c:2487
#17 0x0000000000553530 in PyEval_CallObjectWithKeywords
(func=0x7ffff7f53230, arg=0x7ffff7f98050, kw=0x0) at
../../unladen2/Python/eval.cc:45
#18 0x00000000005b1a6d in t_bootstrap (boot_raw=0x1273e60) at
../../unladen2/Modules/threadmodule.c:425
#19 0x00007ffff7bca3f7 in start_thread () from /lib/libpthread.so.0
#20 0x00007ffff6d98b3d in clone () from /lib/libc.so.6
#21 0x0000000000000000 in ?? ()
(gdb) pystack
thread_fork_hang.py (15): daemon
Current language: auto; currently c
Current language: auto; currently c++
/home/rnk/unladen2/Lib/threading.py (481): run
/home/rnk/unladen2/Lib/threading.py (523): __bootstrap_inner
/home/rnk/unladen2/Lib/threading.py (498): __bootstrap
Current language: auto; currently c
Current language: auto; currently c++
Current language: auto; currently c
You can see that it's stuck in the daemon's busy loop from the test case.
So what's the right way to fix this? Should Py_Finalize be called for
the child? The problem is that if the parent process registers cleanup
code via the atexit module or something, it might be run twice, once in
the parent and once in the child. However, it's closer to the semantics
of fork, and I'd say that's what you get for using it. Most people
still using fork are probably just turning around and exec'ing anyway.
I'm willing to write the fix if we can agree on a solution.
----------
components: Library (Lib)
files: thread_fork_hang.py
messages: 91263
nosy: rnk
severity: normal
status: open
title: returning after forking a child thread doesn't call Py_Finalize
versions: Python 3.2
Added file: http://bugs.python.org/file14646/thread_fork_hang.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6642>
_______________________________________
From report at bugs.python.org Tue Aug 4 20:56:49 2009
From: report at bugs.python.org (Reid Kleckner)
Date: Tue, 04 Aug 2009 18:56:49 +0000
Subject: [New-bugs-announce] [issue6643] joining a child that forks can
deadlock in the forked child process
In-Reply-To: <1249412209.9.0.200329347238.issue6643@psf.upfronthosting.co.za>
Message-ID: <1249412209.9.0.200329347238.issue6643@psf.upfronthosting.co.za>
New submission from Reid Kleckner <rnk at mit.edu>:
This bug is similar to the importlock deadlock, and it's really part of
a larger problem that you should release all locks before you fork.
However, we can fix this in the threading module directly by freeing and
resetting the locks on the main thread after a fork.
I've attached a test case that inserts calls to sleep at the right
places to make the following occur:
- Main thread spawns a worker thread.
- Main thread joins worker thread.
- To join, the main thread acquires the lock on the condition variable
(worker.__block.acquire()).
== switch to worker ==
- Worker thread forks.
== switch to child process ==
- Worker thread, which is now the only thread in the process, returns.
- __bootstrap_inner calls self.__stop() to notify any other threads
waiting for it that it returned.
- __stop() tries to acquire self.__block, which has been left in an
acquired state, so the child process hangs here.
== switch to worker in parent process ==
- Worker thread calls os.waitpid(), which hangs, since the child never
returns.
So there's the deadlock.
I think I should be able to fix it just by resetting the condition
variable lock and any other locks hanging off the only thread left
standing after the fork.
----------
components: Library (Lib)
files: forkjoindeadlock.py
messages: 91265
nosy: rnk
severity: normal
status: open
title: joining a child that forks can deadlock in the forked child process
versions: Python 2.6
Added file: http://bugs.python.org/file14647/forkjoindeadlock.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6643>
_______________________________________
From report at bugs.python.org Tue Aug 4 21:19:56 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 04 Aug 2009 19:19:56 +0000
Subject: [New-bugs-announce] [issue6644] cmathmodule.c: Extra comma in enum
- fails on AIX
In-Reply-To: <1249413596.71.0.0983950331585.issue6644@psf.upfronthosting.co.za>
Message-ID: <1249413596.71.0.0983950331585.issue6644@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
Please the remove extra comma in Modules/cmathmodule.c
64 : eimes enum special_types {
65 : eimes ST_NINF, /* 0, negative infinity
*/
66 : eimes ST_NEG, /* 1, negative finite
number (nonzero) */
67 : eimes ST_NZERO, /* 2, -0. */
68 : eimes ST_PZERO, /* 3, +0. */
69 : eimes ST_POS, /* 4, positive finite
number (nonzero) */
70 : eimes ST_PINF, /* 5, positive infinity
*/
71 : eimes ST_NAN, /* 6, Not a Number */
72 : eimes };
To see why this is necessary, peruse a similar issue reported earlier:
http://bugs.python.org/issue5889
----------
components: Build, Extension Modules
messages: 91267
nosy: christian.heimes, srid
severity: normal
status: open
title: cmathmodule.c: Extra comma in enum - fails on AIX
type: compile error
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6644>
_______________________________________
From report at bugs.python.org Tue Aug 4 21:27:33 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 04 Aug 2009 19:27:33 +0000
Subject: [New-bugs-announce] [issue6645] multiprocessing build fails on AIX
- /dev/urandom (or equivalent) not found
In-Reply-To: <1249414053.16.0.904107656211.issue6645@psf.upfronthosting.co.za>
Message-ID: <1249414053.16.0.904107656211.issue6645@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
./Modules/ld_so_aix cc_r -qlanglvl=ansi -bI:Modules/python.exp build/
temp.aix-5.1-2.6/home/apy/rrun/build/activ
epython-DEV/build/py2_6_2-aix-powerpc-apyee26-rrun/python/Modules/
_multiprocessing/multiprocessing.o build/temp
.aix-5.1-2.6/home/apy/rrun/build/activepython-DEV/build/py2_6_2-aix-
powerpc-apyee26-rrun/python/Modules/_multip
rocessing/socket_connection.o build/temp.aix-5.1-2.6/home/apy/rrun/
build/activepython-DEV/build/py2_6_2-aix-pow
erpc-apyee26-rrun/python/Modules/_multiprocessing/semaphore.o -o build/
lib.aix-5.1-2.6/_multiprocessing.so
*** WARNING: importing extension "_multiprocessing" failed with <type
'exceptions.NotImplementedError'>: /dev/u
random (or equivalent) not found
----------
components: Build, Extension Modules
messages: 91270
nosy: srid
severity: normal
status: open
title: multiprocessing build fails on AIX - /dev/urandom (or equivalent) not found
type: compile error
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6645>
_______________________________________
From report at bugs.python.org Wed Aug 5 03:42:45 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 05 Aug 2009 01:42:45 +0000
Subject: [New-bugs-announce] [issue6646] test_pickle fails on AIX --
6.9999999999999994e-308 != 6.9999999999999984e-308
In-Reply-To: <1249436565.63.0.933597089559.issue6646@psf.upfronthosting.co.za>
Message-ID: <1249436565.63.0.933597089559.issue6646@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
test test_pickle failed -- errors occurred; run in verbose mode for
details
test_pickletools
test test_pickletools failed -- Traceback (most recent call last):
File "/home/apy/rrun/tmp/autotest/apy/lib/python2.6/test/
pickletester.py", line 546, in test_float
self.assertEqual(value, got)
AssertionError: 6.9999999999999994e-308 != 6.9999999999999984e-308
----------
components: Tests
messages: 91292
nosy: srid
severity: normal
status: open
title: test_pickle fails on AIX -- 6.9999999999999994e-308 != 6.9999999999999984e-308
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6646>
_______________________________________
From report at bugs.python.org Wed Aug 5 06:53:01 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 05 Aug 2009 04:53:01 +0000
Subject: [New-bugs-announce] [issue6647] warnings.catch_warnings is not
thread-safe
In-Reply-To: <1249447980.99.0.321429613778.issue6647@psf.upfronthosting.co.za>
Message-ID: <1249447980.99.0.321429613778.issue6647@psf.upfronthosting.co.za>
New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:
warnings.catch_warnings is a context manager supposed to save and
restore warnings filters, and optionally record all warnings issued.
But it does so in a completely thread-unsafe way, by replacing the
module's "showwarning" and "filters" attributes on enter, and restoring
them on exit. If the __enter__ / __exit__ calls of two threads overlap,
after leaving the last block the warnings state is not the same as the
original state, as it should be.
I don't know how to fix this, other than using locks (that could block
indefinitely) or severely restricting how catch_warnings may be used.
At least, this issue should be documented.
----------
components: Library (Lib)
files: error-warnings.py
messages: 91301
nosy: gagenellina
severity: normal
status: open
title: warnings.catch_warnings is not thread-safe
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14654/error-warnings.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6647>
_______________________________________
From report at bugs.python.org Wed Aug 5 17:48:49 2009
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 05 Aug 2009 15:48:49 +0000
Subject: [New-bugs-announce] [issue6648] codecs documentation does not
mention surrogateescape
In-Reply-To: <1249487329.19.0.991009276368.issue6648@psf.upfronthosting.co.za>
Message-ID: <1249487329.19.0.991009276368.issue6648@psf.upfronthosting.co.za>
New submission from Nikolaus Rath <Nikolaus at rath.org>:
On http://docs.python.org/3.1/library/codecs.html it says that
----
Possible values for errors are 'strict' (raise an exception in case of
an encoding error), 'replace' (replace malformed data with a suitable
replacement marker, such as '?'), 'ignore' (ignore malformed data and
continue without further notice), 'xmlcharrefreplace' (replace with the
appropriate XML character reference (for encoding only)) and
'backslashreplace' (replace with backslashed escape sequences (for
encoding only)) as well as any other error handling name defined via
register_error().
-----
shouldn't the 'surrogateescape' error handler from
http://docs.python.org/3.1/library/os.html#file-names-command-line-arguments-and-environment-variables
be mentioned here as well?
----------
assignee: georg.brandl
components: Documentation
messages: 91321
nosy: Nikratio, georg.brandl
severity: normal
status: open
title: codecs documentation does not mention surrogateescape
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6648>
_______________________________________
From report at bugs.python.org Wed Aug 5 18:21:09 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 05 Aug 2009 16:21:09 +0000
Subject: [New-bugs-announce] [issue6649] idlelib/rpc.py missing exit status
on exithook
In-Reply-To: <1249489269.49.0.307291234061.issue6649@psf.upfronthosting.co.za>
Message-ID: <1249489269.49.0.307291234061.issue6649@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
SocketIO.exithook on idlelib/rpc.py is missing the exit status, this is
a minor issue since both client and server used on IDLE override this
method to do something else.
----------
components: IDLE
files: missing_exitstatus.diff
keywords: patch
messages: 91322
nosy: gpolo
priority: low
severity: normal
status: open
title: idlelib/rpc.py missing exit status on exithook
versions: Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14658/missing_exitstatus.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6649>
_______________________________________
From report at bugs.python.org Wed Aug 5 19:14:39 2009
From: report at bugs.python.org (Torne Wuff)
Date: Wed, 05 Aug 2009 17:14:39 +0000
Subject: [New-bugs-announce] [issue6650] sre_parse contains a confusing
generic error message
In-Reply-To: <1249492479.55.0.250174703511.issue6650@psf.upfronthosting.co.za>
Message-ID: <1249492479.55.0.250174703511.issue6650@psf.upfronthosting.co.za>
New submission from Torne Wuff <torne-pythonbugs at wolfpuppy.org.uk>:
sre_parse raises an exception with the message "syntax error" - very
generic and confusing - in the case where something that looks like a
lookbehind assertion is invalid.
>>> import re
>>> re.match('(?<foo>.*)', 'foo')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.5/re.py", line 137, in match
return _compile(pattern, flags).match(string)
File "/usr/lib/python2.5/re.py", line 241, in _compile
raise error, v # invalid expression
sre_constants.error: syntax error
This example is a typo for '(?P<foo>.*)' :)
This is the only case in sre_parse where the message "syntax error" is
used - the others are much more descriptive. Attached patch changes it
to "bad lookbehind assertion type: %s" for python 2.x head; should be
applied to 3.x also.
----------
components: Regular Expressions
files: sre_error_msg.diff
keywords: patch
messages: 91324
nosy: torne
severity: normal
status: open
title: sre_parse contains a confusing generic error message
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14659/sre_error_msg.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6650>
_______________________________________
From report at bugs.python.org Wed Aug 5 21:23:12 2009
From: report at bugs.python.org (Erick Tryzelaar)
Date: Wed, 05 Aug 2009 19:23:12 +0000
Subject: [New-bugs-announce] [issue6651] Py3k's posixpath.relpath not
compatible with ntpath.relpath
In-Reply-To: <1249500192.85.0.26357988262.issue6651@psf.upfronthosting.co.za>
Message-ID: <1249500192.85.0.26357988262.issue6651@psf.upfronthosting.co.za>
New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:
It looks like Python 3.x's relpath isn't compatible between posixpath
and ntpath. In posixpath.relpath, the start keyword defaults to None,
but ntpath.relpath, the start keyword defaults to curdir.
Interestingly enough, 2.6 and 2.7 have a different implementation of
posixpath.relpath, where it explicitly sets the start to equal curdir,
just like ntpath does.
----------
components: Library (Lib)
messages: 91327
nosy: erickt
severity: normal
status: open
title: Py3k's posixpath.relpath not compatible with ntpath.relpath
type: performance
versions: Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6651>
_______________________________________
From report at bugs.python.org Wed Aug 5 21:47:09 2009
From: report at bugs.python.org (Phillip M. Feldman)
Date: Wed, 05 Aug 2009 19:47:09 +0000
Subject: [New-bugs-announce] [issue6652] missing cmath functions
In-Reply-To: <1249501629.27.0.648462584075.issue6652@psf.upfronthosting.co.za>
Message-ID: <1249501629.27.0.648462584075.issue6652@psf.upfronthosting.co.za>
New submission from Phillip M. Feldman <pfeldman at verizon.net>:
The online documentation describes functions cmath.phase and
cmath.polar, but when I try to import these, I get "cannot import name"
errors.
----------
assignee: georg.brandl
components: Documentation
messages: 91330
nosy: georg.brandl, pfeldman at verizon.net
severity: normal
status: open
title: missing cmath functions
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6652>
_______________________________________
From report at bugs.python.org Wed Aug 5 22:23:52 2009
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 05 Aug 2009 20:23:52 +0000
Subject: [New-bugs-announce] [issue6653] Potential memory leak in
multiprocessing
In-Reply-To: <1249503832.66.0.0114205396453.issue6653@psf.upfronthosting.co.za>
Message-ID: <1249503832.66.0.0114205396453.issue6653@psf.upfronthosting.co.za>
New submission from Jesse Noller <jnoller at gmail.com>:
I have example code to show this. It creates a system-wide memory leak
on Linux/Unix (present until the next reboot), unless the last statement
in the target of mp.Process ensures a manual clean up of the globals.
The problem is line 353 in multiprocessing/forking.py. The function
exit() is defined as os._exit on Linux and ExitProcess on Windows, none
of which allows normal clean up.
>>> help(os._exit)
Help on built-in function _exit in module nt:
_exit(...)
_exit(status)
Exit to the system with specified status, without normal exit
processing.
The problem is fixed if line 353 in forking.py is changed from
exit(exitcode)
to
sys.exit(exitcode)
Test run without bugfix:
G:\DEVELO~1\SHARED~2>python test.py
open handle to 569f439b24e24fc8a547b81932616066
[[ 0. 0. 0. 0.]
[ 0. 0. 0. 0.]]
open handle to 0582d4b161c546f582c1c96e7bd0c39d
open handle to 569f439b24e24fc8a547b81932616066
modified array
closed handle to 569f439b24e24fc8a547b81932616066
[[ 1. 1. 1. 0.]
[ 1. 1. 1. 0.]]
closed handle to 569f439b24e24fc8a547b81932616066
You can see here that opening and closing of handles are unmatched. This
is on Windows, where the kernel ensures the clean-up, so it may not
matter. But on Unix this would have created a permament (system wide)
memory leak! What is happening here is globals not being cleaned up due
to the use of os._exit instead of sys.exit.
Test run with bugfix:
G:\DEVELO~1\SHARED~2>python test.py
open handle to 930778d27b414253bc329f2b70adaa05
[[ 0. 0. 0. 0.]
[ 0. 0. 0. 0.]]
open handle to 3f6cebf8c5de413685bb770d02ae9666
open handle to 930778d27b414253bc329f2b70adaa05
modified array
closed handle to 930778d27b414253bc329f2b70adaa05
closed handle to 3f6cebf8c5de413685bb770d02ae9666
[[ 1. 1. 1. 0.]
[ 1. 1. 1. 0.]]
closed handle to 930778d27b414253bc329f2b70adaa05
Now all allocations and deallocations are matched.
Regards,
Sturla Molden
----------
files: test.zip
messages: 91332
nosy: jnoller
severity: normal
status: open
title: Potential memory leak in multiprocessing
Added file: http://bugs.python.org/file14660/test.zip
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6653>
_______________________________________
From report at bugs.python.org Wed Aug 5 23:16:40 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 05 Aug 2009 21:16:40 +0000
Subject: [New-bugs-announce] [issue6654] Add "path" to the xmrlpc dispatcher
method
In-Reply-To: <1249507000.5.0.428139109569.issue6654@psf.upfronthosting.co.za>
Message-ID: <1249507000.5.0.428139109569.issue6654@psf.upfronthosting.co.za>
New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:
I've created http://codereview.appspot.com/100046 on Rietveld:
by passing the "path" component of the xmlrpc request to the dispatch
method, it
becomes possible to dispatch differently according to this. This patch
provides
that addition. Additionally, it provides an MultiPathXMLRPCDispatcher
mixin
class and a MultiPathXMLRPCServer that uses it, to have multiple
dispatchers for
different paths.
This allows a single server port to serve different XMLRPC servers as
differentiated by the HTTP path. A test is also preovided.
I've also prophylacticly emailed this to phython-ideas.
----------
components: Library (Lib)
messages: 91337
nosy: krisvale
severity: normal
status: open
title: Add "path" to the xmrlpc dispatcher method
type: feature request
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6654>
_______________________________________
From report at bugs.python.org Thu Aug 6 05:35:20 2009
From: report at bugs.python.org (Dj Gilcrease)
Date: Thu, 06 Aug 2009 03:35:20 +0000
Subject: [New-bugs-announce] [issue6655] etree iterative find[text]
In-Reply-To: <1249529720.45.0.62463367335.issue6655@psf.upfronthosting.co.za>
Message-ID: <1249529720.45.0.62463367335.issue6655@psf.upfronthosting.co.za>
New submission from Dj Gilcrease <digitalxero at gmail.com>:
I recently converted a project from using a custom implementation of
xml.dom.minidom to using EelemntTree that comes with python2.5+ and
found myself wishing for a find(tag_or_path) method that would do so iteratively instead of just on the current elements direct children.
This is possible with the code as written;
looking_for = None
for el in etree.getiterator(tag_or_path):
looking_for = el
break
I have to do this type of action so often in my code that I just decided
to grab the python implementation of etree that came with py2.6 and
include it with my app and patch in an iter_find method as the instant
break for loop is just asking for maintenance issues down the road what
I forget why I was breaking on the first loop no matter what.
----------
components: XML
files: ElementTree.py.patch
keywords: patch
messages: 91348
nosy: Digitalxero
severity: normal
status: open
title: etree iterative find[text]
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file14663/ElementTree.py.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6655>
_______________________________________
From report at bugs.python.org Thu Aug 6 13:09:38 2009
From: report at bugs.python.org (Christoph Burgmer)
Date: Thu, 06 Aug 2009 11:09:38 +0000
Subject: [New-bugs-announce] [issue6656] locale.format_string fails on
escaped percentage
In-Reply-To: <1249556978.14.0.317265689402.issue6656@psf.upfronthosting.co.za>
Message-ID: <1249556978.14.0.317265689402.issue6656@psf.upfronthosting.co.za>
New submission from Christoph Burgmer <cburgmer at ira.uka.de>:
locale.format_string doesn't return same result as a normal
"string" % format
directive, but raises a TypeError. See attached test case for Python
2.6.
>>> locale.format_string('%f%%', 1.0)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.5/locale.py", line 195, in format_string
return new_f % val
TypeError: not enough arguments for format string
>>> '%f%%' % 1.0
'1.000000%'
----------
components: Library (Lib)
files: locale_percents_test.diff
keywords: patch
messages: 91352
nosy: christoph
severity: normal
status: open
title: locale.format_string fails on escaped percentage
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14665/locale_percents_test.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6656>
_______________________________________
From report at bugs.python.org Thu Aug 6 13:18:55 2009
From: report at bugs.python.org (Sheepherd)
Date: Thu, 06 Aug 2009 11:18:55 +0000
Subject: [New-bugs-announce] [issue6657] Copy documentation section
In-Reply-To: <1249557535.14.0.530083384684.issue6657@psf.upfronthosting.co.za>
Message-ID: <1249557535.14.0.530083384684.issue6657@psf.upfronthosting.co.za>
New submission from Sheepherd <sheepherd2k at hotmail.com>:
The enumerated part in about the exact usage of the conversion specifier
in "String Formatting Operations"
http://docs.python.org/library/stdtypes.html#string-formatting should be
copied to http://docs.python.org/library/string.html#formatspec to make
the usage of the specifier clear.
----------
assignee: georg.brandl
components: Documentation
messages: 91354
nosy: Sheepherd, georg.brandl
severity: normal
status: open
title: Copy documentation section
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6657>
_______________________________________
From report at bugs.python.org Thu Aug 6 13:47:47 2009
From: report at bugs.python.org (Alexey Shamrin)
Date: Thu, 06 Aug 2009 11:47:47 +0000
Subject: [New-bugs-announce] [issue6658] typo in buffer api docs
In-Reply-To: <1249559267.03.0.842450307551.issue6658@psf.upfronthosting.co.za>
Message-ID: <1249559267.03.0.842450307551.issue6658@psf.upfronthosting.co.za>
New submission from Alexey Shamrin <shamrin at gmail.com>:
Typo in PyObject_GetBuffer docs: "...handle all the complexibity..."
Links:
http://docs.python.org/c-api/buffer.html#buffer-related-functions
http://docs.python.org/dev/c-api/buffer.html#buffer-related-functions
http://docs.python.org/3.1/c-api/buffer.html#buffer-related-functions
http://docs.python.org/dev/py3k/c-api/buffer.html#buffer-related-functions
----------
assignee: georg.brandl
components: Documentation
messages: 91355
nosy: ash, georg.brandl
severity: normal
status: open
title: typo in buffer api docs
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6658>
_______________________________________
From report at bugs.python.org Thu Aug 6 14:07:36 2009
From: report at bugs.python.org (Alexey Shamrin)
Date: Thu, 06 Aug 2009 12:07:36 +0000
Subject: [New-bugs-announce] [issue6659] buffer c-api: memoryview object
documentation
In-Reply-To: <1249560456.01.0.11537088321.issue6659@psf.upfronthosting.co.za>
Message-ID: <1249560456.01.0.11537088321.issue6659@psf.upfronthosting.co.za>
New submission from Alexey Shamrin <shamrin at gmail.com>:
"A memoryview object is an extended buffer object that could replace the
buffer object (but doesn?t have to as that could be kept as a simple 1-d
memoryview object)."
Well, buffer object was dropped Python 3, wasn't it?
http://docs.python.org/dev/py3k/c-api/buffer.html#memoryview-objects
http://docs.python.org/3.1/c-api/buffer.html#memoryview-objects
----------
assignee: georg.brandl
components: Documentation
messages: 91357
nosy: ash, georg.brandl
severity: normal
status: open
title: buffer c-api: memoryview object documentation
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6659>
_______________________________________
From report at bugs.python.org Thu Aug 6 19:49:44 2009
From: report at bugs.python.org (kee nethery)
Date: Thu, 06 Aug 2009 17:49:44 +0000
Subject: [New-bugs-announce] [issue6660] Desire python.org documentation
link to user contribution wiki (per function)
In-Reply-To: <1249580984.63.0.922866340136.issue6660@psf.upfronthosting.co.za>
Message-ID: <1249580984.63.0.922866340136.issue6660@psf.upfronthosting.co.za>
New submission from kee nethery <kee at kagi.com>:
Proposal: For each permalink headline in the official documentation,
link to a wiki page specific to that headline. Allow users to easily
view and contribute comments and examples around that specific
documentation headline. For example:
http://docs.python.org/reference/lexical_analysis.html#string-literal-
concatenation
would have an auto-generated link in the main docs of (for example):
http://wiki.docs.python.org/2.6.2#reference#lexical_analysis.html#string
-literal-concatenation
Easy to create, self administering, perhaps valuable to new users,
completely unofficial.
Newbies need examples, lots of examples. Newbies have noob questions
about things they are stumbling across that experienced users have
forgotten was once confusing. For experienced users that knowledge is
now part of their Python DNA. According to people on the "python-list"
other languages have wiki style user contribution areas that allow
newbies to document the things they found confusing (and the answers)
and to provide lots of code examples. Periodically this newbie
information is rolled back into the official mainline docs. Requiring
newbies to join this tracking system and to submit bugs is just way to
complex for something that is now trivial to do with a wiki and it
obviously causes the new user contributions to be pretty non-existent.
Python would be a much easier language to learn if newbies could easily
contribute through the main documentation web site.
----------
assignee: georg.brandl
components: Documentation
messages: 91373
nosy: georg.brandl, keenethery, nnorwitz
severity: normal
status: open
title: Desire python.org documentation link to user contribution wiki (per function)
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6660>
_______________________________________
From report at bugs.python.org Thu Aug 6 22:10:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Aug 2009 20:10:48 +0000
Subject: [New-bugs-announce] [issue6661] Transient test_multiprocessing
failure
In-Reply-To: <1249589448.92.0.976190766506.issue6661@psf.upfronthosting.co.za>
Message-ID: <1249589448.92.0.976190766506.issue6661@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
I just got the following test_multiprocessing error (cannot reproduce,
though):
test test_multiprocessing failed -- Traceback (most recent call last):
File
"/home/antoine/cpython/seek-6629/Lib/test/test_multiprocessing.py", line
232, in test_active_children
self.assertTrue(p in self.active_children())
AssertionError: False is not True
----------
assignee: jnoller
components: Library (Lib), Tests
messages: 91383
nosy: jnoller, pitrou
priority: normal
severity: normal
status: open
title: Transient test_multiprocessing failure
type: behavior
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6661>
_______________________________________
From report at bugs.python.org Fri Aug 7 03:25:10 2009
From: report at bugs.python.org (Dave Day)
Date: Fri, 07 Aug 2009 01:25:10 +0000
Subject: [New-bugs-announce] [issue6662] HTMLParser.HTMLParser doesn't
handle malformed charrefs
In-Reply-To: <1249608310.39.0.325559183765.issue6662@psf.upfronthosting.co.za>
Message-ID: <1249608310.39.0.325559183765.issue6662@psf.upfronthosting.co.za>
New submission from Dave Day <dayveday at gmail.com>:
When HTMLParser.HTMLParser encounters a malformed charref (for example
&#bad;) it no longer parsers the following HTML correctly.
For example:
<p>&#bad;</p>
Recognises the starttag "p" but considers the rest to be data.
To reproduce:
class MyParser(HTMLParser.HTMLParser):
def handle_starttag(self, tag, attrs):
print 'Start "%s"' % tag
def handle_endtag(self,tag):
print 'End "%s"' % tag
def handle_charref(self, ref):
print 'Charref "%s"' % ref
def handle_data(self, data):
print 'Data "%s"' % data
parser = MyParser()
parser.feed('<p>&#bad;</p>')
parser.close()
Expected output:
Start "p"
Data "&#bad;"
End "p"
Actual output:
Start "p"
Data "&#bad;</p>"
----------
components: Library (Lib)
messages: 91392
nosy: dayveday
severity: normal
status: open
title: HTMLParser.HTMLParser doesn't handle malformed charrefs
type: behavior
versions: Python 2.4, Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6662>
_______________________________________
From report at bugs.python.org Fri Aug 7 08:00:14 2009
From: report at bugs.python.org (Phillip M. Feldman)
Date: Fri, 07 Aug 2009 06:00:14 +0000
Subject: [New-bugs-announce] [issue6663] re.findall does not always return a
list of strings
In-Reply-To: <1249624814.45.0.837975483748.issue6663@psf.upfronthosting.co.za>
Message-ID: <1249624814.45.0.837975483748.issue6663@psf.upfronthosting.co.za>
New submission from Phillip M. Feldman <pfeldman at verizon.net>:
As per the Python documentation, the following regular expression should
produce a list containing the strings '6.7', 7.33', and '9':
re.findall('(-?\d+[.]\d+)|(-?\d+[.]?)|(-?[.]\d+)', 'asdf6.7jjjj7.33ff9')
Instead, it generates a list of tuples. Either the documentation should
be changed to make it consistent with what re.findall is actually doing,
or, better yet, re.findall should be fixed.
----------
components: Regular Expressions
messages: 91393
nosy: pfeldman at verizon.net
severity: normal
status: open
title: re.findall does not always return a list of strings
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6663>
_______________________________________
From report at bugs.python.org Fri Aug 7 11:14:15 2009
From: report at bugs.python.org (Neil Hodgson)
Date: Fri, 07 Aug 2009 09:14:15 +0000
Subject: [New-bugs-announce] [issue6664] readlines should understand Line
Separator and Paragraph Separator characters
In-Reply-To: <1249636455.06.0.336549280075.issue6664@psf.upfronthosting.co.za>
Message-ID: <1249636455.06.0.336549280075.issue6664@psf.upfronthosting.co.za>
New submission from Neil Hodgson <nyamatongwe at users.sourceforge.net>:
Unicode includes Line Separator U+2028 and Paragraph Separator U+2029
line ending characters. The readlines method of the file object returned
by the built-in open does not treat these characters as line ends
although the object returned by codecs.open(..., encoding='utf-8') does.
The attached program creates a UTF-8 file containing three lines with
the second line ended with a Paragraph Separator. The program then reads
this file back in as a text file. Only two lines are seen when reading
the file back in.
The desired behaviour is for the file to be read in as three lines.
----------
components: IO
files: lineends.py
messages: 91397
nosy: nyamatongwe
severity: normal
status: open
title: readlines should understand Line Separator and Paragraph Separator characters
versions: Python 3.1
Added file: http://bugs.python.org/file14671/lineends.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6664>
_______________________________________
From report at bugs.python.org Fri Aug 7 11:49:19 2009
From: report at bugs.python.org (Josef Skladanka)
Date: Fri, 07 Aug 2009 09:49:19 +0000
Subject: [New-bugs-announce] [issue6665] fnmatch fails on filenames
containing \n character
In-Reply-To: <1249638559.7.0.0574356115412.issue6665@psf.upfronthosting.co.za>
Message-ID: <1249638559.7.0.0574356115412.issue6665@psf.upfronthosting.co.za>
New submission from Josef Skladanka <jskladan at redhat.com>:
Hello,
at the moment, fnmatch.fnmatch() will fail to match any string, which
has \n character. This of course breaks glob as well.
Example
> import fnmatch
> fnmatch.fnmatch("foo\nbar", "foo*")
False
> import glob
> open("foobar", "w").close()
> open("foo\nbar", "w").close()
> glob.glob("foo*")
['foobar']
while the expected result is ['foobar', 'foo\nbar']. The standard C
fnmatch function from fnmatch.h is behaving correctly i.e. this code
will print out "match!"
#include <fnmatch.h>
#include <stdio.h>
int main()
{
if (fnmatch("foo*", "foo\nbar", FNM_NOESCAPE) == 0)
printf("match!\n");
else
printf("fail!\n");
return 0;
}
This misbehaviour is caused by the fnmatch.translate() which adds $ to
the end of the regexp. Without the ending $ the fnmatch function works OK.
----------
components: Library (Lib)
messages: 91398
nosy: rajcze
severity: normal
status: open
title: fnmatch fails on filenames containing \n character
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6665>
_______________________________________
From report at bugs.python.org Fri Aug 7 11:50:15 2009
From: report at bugs.python.org (Bogdan Opanchuk)
Date: Fri, 07 Aug 2009 09:50:15 +0000
Subject: [New-bugs-announce] [issue6666] List of dirs to ignore in trace.py
is applied only for the first file
In-Reply-To: <1249638615.65.0.163009414102.issue6666@psf.upfronthosting.co.za>
Message-ID: <1249638615.65.0.163009414102.issue6666@psf.upfronthosting.co.za>
New submission from Bogdan Opanchuk <bg at bk.ru>:
When creating a trace.Trace object or running trace.py one can specify
list of directories to ignore (ignoredirs or --ignore-dir
correspondingly). It is passed to trace.Ignore constructor, which stores
iterator to map(), applied to this list, in self._dirs. So, when
Ignore.names() execution passes to the block "for d in self._dirs:" for
the first time, iterator saves its state (in the end of the list) and
next times the code in this block is completely ignored. The result is
that 'ignoredirs' parameter does not actually work (except for the one
lucky file).
Proposed patch is attached.
----------
components: Library (Lib)
files: trace.diff
keywords: patch
messages: 91399
nosy: bogdan.opanchuk
severity: normal
status: open
title: List of dirs to ignore in trace.py is applied only for the first file
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file14672/trace.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6666>
_______________________________________
From report at bugs.python.org Fri Aug 7 11:53:29 2009
From: report at bugs.python.org (maro)
Date: Fri, 07 Aug 2009 09:53:29 +0000
Subject: [New-bugs-announce] [issue6667] logging config - using
FileHandler's delay argument?
In-Reply-To: <1249638809.81.0.11088299207.issue6667@psf.upfronthosting.co.za>
Message-ID: <1249638809.81.0.11088299207.issue6667@psf.upfronthosting.co.za>
New submission from maro <misgis at gmail.com>:
I'm not sure, if it's an issue. I don't know how to use argument 'delay'
of FileHandler in my logging.conf file.
[handler_tarFileHandler]
class=FileHandler
level=DEBUG
formatter=simpleFormatter
args=('/tmp/_tar2ncConverter.log','a+')
delay=True # file is created only when first message is emited (delay =
True), not working, empty file is always created...
If I put delay to FileHandler's constructor args
('/tmp/_tar2ncConverter.log','a+',None,True) I get error message about
missing arguments. It is an issue, or just my wrong arranged args?
regards
maro
----------
components: None
messages: 91400
nosy: maro
severity: normal
status: open
title: logging config - using FileHandler's delay argument?
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6667>
_______________________________________
From report at bugs.python.org Fri Aug 7 16:34:34 2009
From: report at bugs.python.org (Vlada Peric)
Date: Fri, 07 Aug 2009 14:34:34 +0000
Subject: [New-bugs-announce] [issue6668] locale.py: can't parse sr_RS@latin
locale
In-Reply-To: <1249655674.35.0.635015975428.issue6668@psf.upfronthosting.co.za>
Message-ID: <1249655674.35.0.635015975428.issue6668@psf.upfronthosting.co.za>
New submission from Vlada Peric <vlada.peric at gmail.com>:
The sr_RS locale in glibc corresponds to the Cyrillic script, while the
agreed upon locale for the Latin alphabet is sr_RS at latin. Unfortunately,
the locale python module crashes when trying to parse this locale. Here
is the traceback:
File "/usr/lib/python2.6/locale.py", line 497, in get locale
return _parse_localename(localename)
File "usr/lib/python2.6/locale.py", line 410, in _parse_localename
raise ValueError, 'unknown locale: %s' % localename
Looking at the code, it only checks for the @euro modifier and ignores
all other modifiers (including @latin). This is all when I set
LANG=sr_RS at latin. If I use LANG=sr_RS.UTF8 at latin (also allowed by
glibc), Python interprets this as the sr_RS locale (which is wrong, as
that is for Cyrillic).
----------
components: Unicode
messages: 91404
nosy: VPeric
severity: normal
status: open
title: locale.py: can't parse sr_RS at latin locale
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6668>
_______________________________________
From report at bugs.python.org Fri Aug 7 23:11:16 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 07 Aug 2009 21:11:16 +0000
Subject: [New-bugs-announce] [issue6669] TarFile.getmembers fails at
struct.unpack: unpack requires a string argument of length 4
In-Reply-To: <1249679476.65.0.0604043126333.issue6669@psf.upfronthosting.co.za>
Message-ID: <1249679476.65.0.0604043126333.issue6669@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
Perhaps this must be wrapped under a programmer-expected custom
exception class (TarError maybe)
for tarinfo in tarfileobj.getmembers():
File "/home/apy/ActivePython-2.6/lib/python2.6/tarfile.py", line
1791, in getmembers
self._load() # all members, we first have to
File "/home/apy/ActivePython-2.6/lib/python2.6/tarfile.py", line
2352, in _load
tarinfo = self.next()
File "/home/apy/ActivePython-2.6/lib/python2.6/tarfile.py", line
2307, in next
self.fileobj.seek(self.offset)
File "/home/apy/ActivePython-2.6/lib/python2.6/gzip.py", line 382, in
seek
self.read(1024)
File "/home/apy/ActivePython-2.6/lib/python2.6/gzip.py", line 219, in
read
self._read(readsize)
File "/home/apy/ActivePython-2.6/lib/python2.6/gzip.py", line 267, in
_read
self._read_eof()
File "/home/apy/ActivePython-2.6/lib/python2.6/gzip.py", line 300, in
_read_eof
crc32 = read32(self.fileobj)
File "/home/apy/ActivePython-2.6/lib/python2.6/gzip.py", line 24, in
read32
return struct.unpack("<I", input.read(4))[0]
error: unpack requires a string argument of length 4
----------
components: Library (Lib)
messages: 91412
nosy: srid
severity: normal
status: open
title: TarFile.getmembers fails at struct.unpack: unpack requires a string argument of length 4
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6669>
_______________________________________
From report at bugs.python.org Sat Aug 8 21:50:06 2009
From: report at bugs.python.org (brimac)
Date: Sat, 08 Aug 2009 19:50:06 +0000
Subject: [New-bugs-announce] [issue6670] Printing the 'The Python Tutorial'
In-Reply-To: <1249761006.45.0.422242383232.issue6670@psf.upfronthosting.co.za>
Message-ID: <1249761006.45.0.422242383232.issue6670@psf.upfronthosting.co.za>
New submission from brimac <brimac at bcs.org>:
I am having a problem when printing 'The Python Tutorial' at
http://docs.python.org/tutorial/
I am using XP and Firefox and an HP Laserjet.
The page displays OK but the printout has a 68 mm margin on the left.
The margin on the right is 18 mm but the text is cut off, sometimes
mid-letter. The other 14 pages in the tutorial have the same problem.
I've tried changing from Portrait to Landscape. The text gets wider, the
margins are the same size, and the text is still cut off.
I have not noticed this with any other documents, on this website or
elsewhere. I'm sure if you print/preview you will see the problem.
My guess is that there is a fault with the printout file at python.org
----------
assignee: georg.brandl
components: Documentation
messages: 91422
nosy: brimac, georg.brandl
severity: normal
status: open
title: Printing the 'The Python Tutorial'
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6670>
_______________________________________
From report at bugs.python.org Sun Aug 9 12:35:25 2009
From: report at bugs.python.org (Aliaksandr Stelmachonak)
Date: Sun, 09 Aug 2009 10:35:25 +0000
Subject: [New-bugs-announce] [issue6671] webbrowser.py doesn't respect xfce
default browser
In-Reply-To: <1249814125.92.0.530552321419.issue6671@psf.upfronthosting.co.za>
Message-ID: <1249814125.92.0.530552321419.issue6671@psf.upfronthosting.co.za>
New submission from Aliaksandr Stelmachonak <mail.avatar at gmail.com>:
Currently webbrowser.py only trying to use GNOME and KDE default browser
setting. This patch adds launching Xfce default browser if xfce environment detected.
----------
components: Library (Lib)
files: webbrowser.py.patch
keywords: patch
messages: 91426
nosy: ava1ar
severity: normal
status: open
title: webbrowser.py doesn't respect xfce default browser
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14678/webbrowser.py.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6671>
_______________________________________
From report at bugs.python.org Sun Aug 9 14:24:50 2009
From: report at bugs.python.org (=?utf-8?q?Jan_Schl=C3=BCter?=)
Date: Sun, 09 Aug 2009 12:24:50 +0000
Subject: [New-bugs-announce] [issue6672] Add Mingw recognition to pyport.h
to allow building extensions
In-Reply-To: <1249820690.51.0.767085753138.issue6672@psf.upfronthosting.co.za>
Message-ID: <1249820690.51.0.767085753138.issue6672@psf.upfronthosting.co.za>
New submission from Jan Schl?ter <python-bugs at jan-schlueter.de>:
This addresses missing statements for recognizing the Mingw compiler in
pyport.h, needed to build several extension modules on Windows using
Mingw. I will first explain the background, then indicate what needs to
be changed and end with some pointers to "related work".
Pyport.h of Python 2.5 and 2.6 (I do not have other versions to check)
addresses an issue with Cygwin's gcc by preventing the declaration of
"__declspec(dllimport)" for function definitions (using the PyAPI_FUNC
(RTYPE) makro), relying on the compiler's auto-import definition
instead, because the compiler would not otherwise throw an "initializer
element is not constant" error when using e.g. PyObject_GenericGetAttr
in a PyTypeObject declaration of a C/C++ extension module (more
generally, whenever an imported Python API function is used as a
constant).
Python 2.6.2 (r262:71605) and Python 2.5.4 (r254:67916) do not check
for the Mingw compiler in pyport.h, although Mingw behaves the same as
the Cygwin version, at least regarding the "__declspec" declaration.
To fix that, each check for __CYGWIN__ in pyport.h should also check
for __MINGW32___ to behave the same way. svn.python.org currently does
not reply, so I can not create a patch against the trunk nor check
whether this issue has already been addressed.
Issue 5046 included a patch to pyport.h fixing this, but it has been
rejected due to other suggested changes that were not mature.
http://recipes.gobolinux.org/r/?list=Python&ver=3.1-
r1&file=arm/20061116160247-
bf48b-7db78fe2f80b3137ce349cf4314364768555ff50.gz.diff suggests the
same change.
http://www.indashpc.org/vbullettin/viewtopic.php?p=5003#5003 gives some
more background information on how I found and fixed the problem.
An internet search for "python initializer element is not constant"
shows that numerous people have been encountering this problem when
trying to build a python extension module.
----------
components: Build
messages: 91427
nosy: f0k
severity: normal
status: open
title: Add Mingw recognition to pyport.h to allow building extensions
versions: Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6672>
_______________________________________
From report at bugs.python.org Sun Aug 9 16:09:45 2009
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 09 Aug 2009 14:09:45 +0000
Subject: [New-bugs-announce] [issue6673] Py3.1 hangs in coroutine and eats
up all memory
In-Reply-To: <1249826985.41.0.2934011008.issue6673@psf.upfronthosting.co.za>
Message-ID: <1249826985.41.0.2934011008.issue6673@psf.upfronthosting.co.za>
New submission from Stefan Behnel <scoder at users.sourceforge.net>:
Here's a simple coroutine that works perfectly in Python 2.6 but seems
to let Py3.1 enter an infinite loop that ends up eating all memory.
-----------------
def printing_sink():
"A simple sink that prints the received values."
while True:
print( (yield) )
def chunker(chunk_size, target):
"""Receives single items and forwards chunks of a fixed size.
Usage example:
>>> sink = printing_sink()
>>> next(sink)
>>> cr = chunker(4, sink)
>>> next(cr)
>>> for i in range(8):
... cr.send(i)
[0, 1, 2, 3]
[4, 5, 6, 7]
>>> cr.close()
"""
while True:
target.send([ (yield) for i in range(chunk_size) ])
if __name__ == '__main__':
import doctest
doctest.testmod()
-----------------
Fails on:
Python 3.1 (r31:73572, Jun 28 2009, 21:07:35)
[GCC 4.3.2] on linux2
Works on:
Python 2.6.2 (r262:71600, Apr 17 2009, 11:29:30)
[GCC 4.3.2] on linux2
The problem seems to be the list comprehension. When I replace it with a
normal for-loop, it works perfectly.
----------
components: Interpreter Core
messages: 91428
nosy: scoder
severity: normal
status: open
title: Py3.1 hangs in coroutine and eats up all memory
type: crash
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6673>
_______________________________________
From report at bugs.python.org Mon Aug 10 12:35:16 2009
From: report at bugs.python.org (Shashi Gowda)
Date: Mon, 10 Aug 2009 10:35:16 +0000
Subject: [New-bugs-announce] [issue6674] Fatal error: deallocating None
In-Reply-To: <1249900516.3.0.450252107319.issue6674@psf.upfronthosting.co.za>
Message-ID: <1249900516.3.0.450252107319.issue6674@psf.upfronthosting.co.za>
New submission from Shashi Gowda <connect2shashi at gmail.com>:
I'm using the megahal mh_python module to make a bot instance learn from
a several 100 files. The code works as it should for 4-6 files before
crashing with this error message "Fatal error: deallocating None" There
isn't much documentation on this anywhere.
----------
components: Interpreter Core
files: learn.py
messages: 91438
nosy: shashi
severity: normal
status: open
title: Fatal error: deallocating None
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file14681/learn.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6674>
_______________________________________
From report at bugs.python.org Mon Aug 10 15:44:25 2009
From: report at bugs.python.org (D Hardy)
Date: Mon, 10 Aug 2009 13:44:25 +0000
Subject: [New-bugs-announce] [issue6675] inf == inf (wrong IEEE 754
behaviour)
In-Reply-To: <1249911865.84.0.497315252674.issue6675@psf.upfronthosting.co.za>
Message-ID: <1249911865.84.0.497315252674.issue6675@psf.upfronthosting.co.za>
New submission from D Hardy <diggory.hardy at gmail.com>:
Currently python evaluates infinity as equal to itself in my tests (2.6.2 and 3.0.1+
from ubuntu). I'm not entirely sure whether the behaviour of 'inf == inf' is specified
by IEEE 754, but it leads to results like:
>>> 1e400
inf
>>> 1e400 == 1e500
True
And hence unittests which use tests like
if not (math.fabs(value1 - value2) <= 0.00000001 *
max(math.fabs(value1),math.fabs(value2))):
fail
don't always fail when they should (when a value is inf).
This is a specific example (and probably not the recommended way of testing
values in any case), but I think "inf != inf" is generally considered the correct
behaviour. (Although maybe this is left over from the PEP 42 / PEP 754 mess; I
wasn't able to find the current status of implementing IEEE 754 behaviour in
python.)
----------
components: None
messages: 91443
nosy: Cyborg16
severity: normal
status: open
title: inf == inf (wrong IEEE 754 behaviour)
type: behavior
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6675>
_______________________________________
From report at bugs.python.org Mon Aug 10 18:23:25 2009
From: report at bugs.python.org (Matthew)
Date: Mon, 10 Aug 2009 16:23:25 +0000
Subject: [New-bugs-announce] [issue6676] expat parser throws Memory Error
when parsing multiple files
In-Reply-To: <1249921405.95.0.689815480815.issue6676@psf.upfronthosting.co.za>
Message-ID: <1249921405.95.0.689815480815.issue6676@psf.upfronthosting.co.za>
New submission from Matthew <webmaster at adurosolutions.com>:
I'm using the Expat python interface to parse multiple XML files in an
application and have found that it throws a "Memory Error" exception if
multiple calls are made to xmlparser.ParseFile(file) on the same
xmlparser object. This occurs even with a vanilla xmlparser object
created with xml.parsers.expat.ParserCreate().
Python Version: 2.6.2
Operating System: Ubuntu
----------
components: XML
files: expat-error.py
messages: 91452
nosy: realpolitik
severity: normal
status: open
title: expat parser throws Memory Error when parsing multiple files
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14684/expat-error.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6676>
_______________________________________
From report at bugs.python.org Mon Aug 10 19:09:52 2009
From: report at bugs.python.org (Mike Cowperthwaite)
Date: Mon, 10 Aug 2009 17:09:52 +0000
Subject: [New-bugs-announce] [issue6677] Place the term "delete" within the
documentation for os.remove() and os.rmdir()
In-Reply-To: <1249924192.93.0.340979032094.issue6677@psf.upfronthosting.co.za>
Message-ID: <1249924192.93.0.340979032094.issue6677@psf.upfronthosting.co.za>
New submission from Mike Cowperthwaite <mikec at lathropengineering.com>:
"Remove" and "unlink" are not the most widely-known verbs that come
to mind when thinking about deleting objects from the filesystem.
A recent Google search for "python delete file" led to the documentation
for the 'os' module:
http://docs.python.org/library/os.html
but searching within that page for "delet" completely misses
os.remove(), os.unlink(), and os.rmdir().
Suggest simply expanding the first sentence of os.remove()'s paragraph to:
Remove the file /path/ (delete the file).
Similarly for os.rmdir():
Remove the directory /path/ (delete the directory).
Also regarding os.rmdir(), it would be nice to add a mention here of
this information from os.walk(): "rmdir() doesn?t allow deleting a
directory before the directory is empty."
The URL above is for the 2.6 version (chapter 16.1.4); also seen in the
3.1 documentation (15.1.5); presumably it's also in the development
versions. Patching backwards as far as feasible would be appreciated.
----------
assignee: georg.brandl
components: Documentation
messages: 91456
nosy: georg.brandl, mcow
severity: normal
status: open
title: Place the term "delete" within the documentation for os.remove() and os.rmdir()
versions: Python 2.6, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6677>
_______________________________________
From report at bugs.python.org Mon Aug 10 20:25:01 2009
From: report at bugs.python.org (William Mill)
Date: Mon, 10 Aug 2009 18:25:01 +0000
Subject: [New-bugs-announce] [issue6678] inspect.currentframe documentation
omits optional depth parameter
In-Reply-To: <1249928701.73.0.0206445902812.issue6678@psf.upfronthosting.co.za>
Message-ID: <1249928701.73.0.0206445902812.issue6678@psf.upfronthosting.co.za>
New submission from William Mill <bill.mill at gmail.com>:
help(inspect.currentframe) reads:
---------------------------------
_getframe(...)
_getframe([depth]) -> frameobject
Return a frame object from the call stack. If optional integer depth is
given, return the frame object that many calls below the top of the
stack. If that is deeper than the call stack, ValueError is raised. The
default for depth is zero, returning the frame at the top of the call stack.
This function should be used for internal and specialized
purposes only.
-------------------------------
The python library documentation, however, doesn't mention the optional
depth parameter:
-------------------------------
inspect.currentframe()
Return the frame object for the caller?s stack frame.
-------------------------------
I think substituting the help() text for the library documentation's
text would be an improvement.
----------
assignee: georg.brandl
components: Documentation
messages: 91459
nosy: georg.brandl, llimllib
severity: normal
status: open
title: inspect.currentframe documentation omits optional depth parameter
type: feature request
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6678>
_______________________________________
From report at bugs.python.org Mon Aug 10 22:10:38 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 10 Aug 2009 20:10:38 +0000
Subject: [New-bugs-announce] [issue6679] obsolete paragraph in re doc for
re.sub
In-Reply-To: <1249935038.17.0.324286013964.issue6679@psf.upfronthosting.co.za>
Message-ID: <1249935038.17.0.324286013964.issue6679@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
The documentation of re.sub states:
"The pattern may be a string or an RE object; if you need to specify
regular expression flags, you must use a RE object, or use embedded
modifiers in a pattern; for example, sub("(?i)b+", "x", "bbbb BBBB")
returns 'x x'."
but there is now a flags argument so that paragraph should be deleted.
----------
assignee: georg.brandl
components: Documentation
messages: 91461
nosy: MLModel, georg.brandl
severity: normal
status: open
title: obsolete paragraph in re doc for re.sub
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6679>
_______________________________________
From report at bugs.python.org Tue Aug 11 00:47:23 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 10 Aug 2009 22:47:23 +0000
Subject: [New-bugs-announce] [issue6680] Python 3.1 fails to build when db.h
contains non-UTF-8 characters
In-Reply-To: <1249944443.54.0.496415697007.issue6680@psf.upfronthosting.co.za>
Message-ID: <1249944443.54.0.496415697007.issue6680@psf.upfronthosting.co.za>
New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:
Python 3.1 fails to build when db.h contains non-UTF-8 characters.
Python 3.1 checks for db.h even though Python 3 doesn't contain bsddb
module.
See also https://bugs.gentoo.org/show_bug.cgi?id=280001
Please at least apply the attached patch, or completely remove check
for db.h.
----------
components: Build
files: python-3.1-setup.py.patch
keywords: patch
messages: 91465
nosy: Arfrever
severity: normal
status: open
title: Python 3.1 fails to build when db.h contains non-UTF-8 characters
versions: Python 3.1
Added file: http://bugs.python.org/file14688/python-3.1-setup.py.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6680>
_______________________________________
From report at bugs.python.org Tue Aug 11 00:58:34 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 10 Aug 2009 22:58:34 +0000
Subject: [New-bugs-announce] [issue6681] email.parser clips trailing \n of
multipart/mixed part if part ends in \r\n
In-Reply-To: <1249945114.19.0.529736934099.issue6681@psf.upfronthosting.co.za>
Message-ID: <1249945114.19.0.529736934099.issue6681@psf.upfronthosting.co.za>
New submission from Guido van Rossum <guido at python.org>:
I am using an edge case of multipart/mixed and find that the
multipart/mix parser in the email package is broken. See attached
example. Similar code using cgi.FieldStorage (!) works fine.
The problem happens through the following combination of factors:
1. Content-Length given
2. Content-Transfer-Encoding: 8bit
3. Last two bytes of the part body are '\r\n'
In this case, the final '\n' is removed from the part body, leaving it a
byte short. Note that interior occurrences of '\r\n' work fine, as does
any other binary data -- it's only a trailing '\r\n' that breaks.
Note that technically perhaps the use of 8bit is invalid; but the same
problem happens when using binary instead.
The problem can be reproduced in Python 3.x using nearly the same demo
by change the cStringIO import to "import io".
----------
components: Library (Lib)
files: barry.py
messages: 91466
nosy: gvanrossum
severity: normal
status: open
title: email.parser clips trailing \n of multipart/mixed part if part ends in \r\n
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14689/barry.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6681>
_______________________________________
From report at bugs.python.org Tue Aug 11 16:26:31 2009
From: report at bugs.python.org (Anders Blomdell)
Date: Tue, 11 Aug 2009 14:26:31 +0000
Subject: [New-bugs-announce] [issue6682] Default traceback does not handle
PEP302 loaded modules
In-Reply-To: <1250000791.92.0.10910978351.issue6682@psf.upfronthosting.co.za>
Message-ID: <1250000791.92.0.10910978351.issue6682@psf.upfronthosting.co.za>
New submission from Anders Blomdell <anders.blomdell at control.lth.se>:
While trying to get a PEP302 import hook to function properly, I found
that the default traceback picks up the wrong sourcecode for PEP302
loaded modules.
The testcase pep302_traceback.py tries to emulate the behavior of the
files in ordinary, which generates the following output when run:
(cd ordinary ; python2.6.2 main.py )
A.__name__= a
B.__name__ a.b
Traceback (most recent call last):
File "main.py", line 6, in <module>
a.A()
File "/tmp/ordinary/a/__init__.py", line 6, in __init__
b.B()
File "/tmp/ordinary/a/b/__init__.py", line 4, in __init__
raise Exception()
Exception
But when i run the testcase, I get the following:
python2.6.2 pep302_traceback.py
### Show possible bug in default linecache (works in 2.6.2)
A.__name__= a
B.__name__= a.b
Traceback (most recent call last):
File "pep302_traceback.py", line 82, in <module>
i.load_module("__main__")
File "pep302_traceback.py", line 58, in load_module
exec(code, mod.__dict__)
File "<__main__.Importer>/main.py", line 6, in <module>
a.A()
File "<__main__.Importer>/a/__init__.py", line 6, in __init__
b.B()
File "<__main__.Importer>/a/b/__init__.py", line 4, in __init__
raise Exception()
Exception
### Show possible bug in default traceback (does not work in 2.6.2)
A.__name__= a
B.__name__= a.b
Traceback (most recent call last):
File "pep302_traceback.py", line 88, in <module>
i.load_module("__main__")
File "pep302_traceback.py", line 58, in load_module
exec(code, mod.__dict__)
File "<__main__.Importer>/main.py", line 6, in <module>
# main.py picked up from somewhere in sys.path
File "<__main__.Importer>/a/__init__.py", line 6, in __init__
# __init__.py picked up from somewhere in sys.path
File "<__main__.Importer>/a/b/__init__.py", line 4, in __init__
# __init__.py picked up from somewhere in sys.path
Exception
I.e. in python 2.6 the linecache module correctly picks up PEP302 loaded
code, while the default traceback picks up any source file from sys.path
that happens to match the name of the file that generated the exception.
When run with python2.5.2, the linecache module also locates the wrong
file from sys.path.
----------
components: Interpreter Core
files: bug.tar
messages: 91475
nosy: anders.blomdell at control.lth.se
severity: normal
status: open
title: Default traceback does not handle PEP302 loaded modules
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14692/bug.tar
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6682>
_______________________________________
From report at bugs.python.org Tue Aug 11 18:17:16 2009
From: report at bugs.python.org (Eric Shubert)
Date: Tue, 11 Aug 2009 16:17:16 +0000
Subject: [New-bugs-announce] [issue6683] smtplib authentication - try all
mechanisms
In-Reply-To: <1250007436.58.0.446313092376.issue6683@psf.upfronthosting.co.za>
Message-ID: <1250007436.58.0.446313092376.issue6683@psf.upfronthosting.co.za>
New submission from Eric Shubert <python at shubes.net>:
The login method in smtplib.py tries only one authentication mechanism.
There are legitimate situations where cram-md5 might fail, yet plain or
login would succeed.
RFC2554 states:
If an AUTH command fails, the client may try another authentication
mechanism by issuing another AUTH command.
The login method should attempt all mechanisms in preferred_auths before
returning a failure. This will make the code more robust, returning a
failure only when absolutely no authentication is possible.
----------
messages: 91478
nosy: shubes
severity: normal
status: open
title: smtplib authentication - try all mechanisms
type: behavior
versions: Python 2.4
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6683>
_______________________________________
From report at bugs.python.org Tue Aug 11 18:44:30 2009
From: report at bugs.python.org (mrjbq7)
Date: Tue, 11 Aug 2009 16:44:30 +0000
Subject: [New-bugs-announce] [issue6684] "x / 1" and "x * 1" should return x
In-Reply-To: <1250009070.48.0.664173919374.issue6684@psf.upfronthosting.co.za>
Message-ID: <1250009070.48.0.664173919374.issue6684@psf.upfronthosting.co.za>
New submission from mrjbq7 <mrjbq7 at users.sourceforge.net>:
There are a couple arithmetic operations that idempotent, where the
returned python object is the same python object as the input.
For example, given a number:
>>> x = 12345
The abs() builtin returns the same number object if it is already a
positive value:
>>> id(x)
17124964
>>> id(abs(x))
17124964
The "multiply by zero" operation returns a single "zero" object:
>>> id(x * 0)
16794004
>>> id(x * 0)
16794004
But, the "multiply by 1" or "divide by 1" does not:
>>> id(x * 1)
17124928
>>> id(x * 1)
17124880
>>> id(x / 1)
17203652
>>> id(x / 1)
17124952
----------
messages: 91479
nosy: mrjbq7
severity: normal
status: open
title: "x / 1" and "x * 1" should return x
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6684>
_______________________________________
From report at bugs.python.org Tue Aug 11 19:56:37 2009
From: report at bugs.python.org (Troy J. Farrell)
Date: Tue, 11 Aug 2009 17:56:37 +0000
Subject: [New-bugs-announce] [issue6685] CGI module documentation references
method 'toupper'; should be 'upper'
In-Reply-To: <1250013397.33.0.441269604909.issue6685@psf.upfronthosting.co.za>
Message-ID: <1250013397.33.0.441269604909.issue6685@psf.upfronthosting.co.za>
New submission from Troy J. Farrell <troy at entheossoft.com>:
The cgi module references a method 'toupper' on strings which should
really reference 'upper'. The line is around 211 of cgi.txt, depending
on the version of the documentation. Search for "`toupper`", (include
the backticks.)
----------
assignee: georg.brandl
components: Documentation
messages: 91481
nosy: georg.brandl, troy
severity: normal
status: open
title: CGI module documentation references method 'toupper'; should be 'upper'
type: feature request
versions: Python 2.6, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6685>
_______________________________________
From report at bugs.python.org Tue Aug 11 21:19:53 2009
From: report at bugs.python.org (Colin Stewart)
Date: Tue, 11 Aug 2009 19:19:53 +0000
Subject: [New-bugs-announce] [issue6686]
xml.sax.xmlreader.XMLReader.getProperty (xml.sax.handler.property_xml_string)
returns bytes
In-Reply-To: <1250018393.94.0.435666063731.issue6686@psf.upfronthosting.co.za>
Message-ID: <1250018393.94.0.435666063731.issue6686@psf.upfronthosting.co.za>
New submission from Colin Stewart <colin at owlfish.com>:
The documentation for the xml.sax.handler.property_xml_string SAX
property states that it should be "data type: String". However when
retrieving this value in Python 3.1 it returns a bytes object instead.
This makes handling the returned value very difficult because there is
no method for retrieving the character set encoding that the XML was
originally encoded with.
This is currently blocking the port of SimpleTAL to Python 3 achieving
feature parity with Python 2.
----------
components: XML
messages: 91482
nosy: cms103
severity: normal
status: open
title: xml.sax.xmlreader.XMLReader.getProperty (xml.sax.handler.property_xml_string) returns bytes
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6686>
_______________________________________
From report at bugs.python.org Tue Aug 11 23:15:32 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 11 Aug 2009 21:15:32 +0000
Subject: [New-bugs-announce] [issue6687] Move the special-case for integer
objects out of PyBytes_FromObject.
In-Reply-To: <1250025332.91.0.596662376204.issue6687@psf.upfronthosting.co.za>
Message-ID: <1250025332.91.0.596662376204.issue6687@psf.upfronthosting.co.za>
New submission from Alexandre Vassalotti <alexandre at peadrop.com>:
The documentation for PyBytes_FromObject states:
.. cfunction:: PyObject* PyBytes_FromObject(PyObject *o)
Return the bytes representation of object *o* that implements
the buffer protocol.
However, there exists a special-case for integer object in
PyBytes_FromObject that makes the function return a null-initialized
bytes object. Currently, this is only used for handling `bytes(10)'.
I don't like changing APIs after a stable release, but I believe this
behaviour is error-prone and surprising (and darn right annoying even).
So, I believe the special-case should be made specific to the bytes
constructor.
Thus, here is the fine patch.
----------
components: Interpreter Core
files: move_int_special_case.diff
keywords: 26backport, patch
messages: 91483
nosy: alexandre.vassalotti
priority: normal
severity: normal
stage: patch review
status: open
title: Move the special-case for integer objects out of PyBytes_FromObject.
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file14693/move_int_special_case.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6687>
_______________________________________
From report at bugs.python.org Tue Aug 11 23:34:37 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 11 Aug 2009 21:34:37 +0000
Subject: [New-bugs-announce] [issue6688] Optimize PyBytes_FromObject.
In-Reply-To: <1250026477.34.0.625583102893.issue6688@psf.upfronthosting.co.za>
Message-ID: <1250026477.34.0.625583102893.issue6688@psf.upfronthosting.co.za>
New submission from Alexandre Vassalotti <alexandre at peadrop.com>:
Optimize PyBytes_FromObject by adding special-cases for list and tuple
objects and by using _PyObject_LengthHint() instead of an arbitrary
value for the size of the initial buffer.
[Without the patch]
./python -m timeit -s "x = list(range(256))" "bytes(x)"
100000 loops, best of 3: 7.19 usec per loop
./python -m timeit -s "x = tuple(range(256))" "bytes(x)"
100000 loops, best of 3: 7.14 usec per loop
./python -m timeit -s "x = list(range(256))*100" "bytes(x)"
1000 loops, best of 3: 591 usec per loop
./python -m timeit -s "x = range(256)" "bytes(x)"
100000 loops, best of 3: 8.45 usec per loop
[With the patch]
./python -m timeit -s "x = list(range(256))" "bytes(x)"
100000 loops, best of 3: 4.43 usec per loop
./python -m timeit -s "x = tuple(range(256))" "bytes(x)"
100000 loops, best of 3: 4.53 usec per loop
./python -m timeit -s "x = list(range(256))*100" "bytes(x)"
1000 loops, best of 3: 335 usec per loop
./python -m timeit -s "x = range(256)" "bytes(x)"
100000 loops, best of 3: 7.56 usec per loop
----------
components: Interpreter Core
files: optimize_bytes_from_object.diff
keywords: patch
messages: 91486
nosy: alexandre.vassalotti
priority: normal
severity: normal
stage: patch review
status: open
title: Optimize PyBytes_FromObject.
type: performance
Added file: http://bugs.python.org/file14694/optimize_bytes_from_object.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6688>
_______________________________________
From report at bugs.python.org Wed Aug 12 10:33:58 2009
From: report at bugs.python.org (David Fraser)
Date: Wed, 12 Aug 2009 08:33:58 +0000
Subject: [New-bugs-announce] [issue6689] subprocess doesn't pass arguments
correctly on Linux when shell=True
In-Reply-To: <1250066038.48.0.373766477997.issue6689@psf.upfronthosting.co.za>
Message-ID: <1250066038.48.0.373766477997.issue6689@psf.upfronthosting.co.za>
New submission from David Fraser <davidf at sjsoft.com>:
(from
http://stackoverflow.com/questions/1253122/why-does-subprocess-popen-with-shelltrue-work-differently-on-linux-vs-windows/1254322)
When using subprocess.Popen(args, shell=True) to run "gcc --version"
(just as an example), on Windows we get this:
>>> from subprocess import Popen
>>> Popen(['gcc', '--version'], shell=True)
gcc (GCC) 3.4.5 (mingw-vista special r3) ...
So it's nicely printing out the version as I expect. But on Linux we get
this:
>>> from subprocess import Popen
>>> Popen(['gcc', '--version'], shell=True)
gcc: no input files
Because gcc hasn't received the --version option.
The docs don't specify exactly what should happen to the args under
Windows, but it does say, on Unix, "If args is a sequence, the first
item specifies the command string, and any additional items will be
treated as additional shell arguments." IMHO the Windows way is better,
because it allows you to treat Popen(arglist) calls the same as
Popen(arglist, shell=True) ones.
The strange implementation is actually the UNIX one, which does the
following (where each space separates a different argument):
/bin/sh -c gcc --version
It looks like the correct implementation (at least on Linux) would be:
/bin/sh -c "gcc --version" gcc --version
Since this would set the command string from the quoted parameters, and
pass the other parameters successfully.
>From the sh man page section for -c:
Read commands from the command_string operand instead of from the
standard input. Special parameter 0 will be set from the command_name
operand and the positional parameters ($1, $2, etc.) set from the
remaining argument operands.
This patch seems to fairly simply do the trick, as well as testing it.
----------
components: Library (Lib)
files: current-2.6.patch
keywords: patch
messages: 91492
nosy: davidfraser
severity: normal
status: open
title: subprocess doesn't pass arguments correctly on Linux when shell=True
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14697/current-2.6.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6689>
_______________________________________
From report at bugs.python.org Wed Aug 12 23:32:08 2009
From: report at bugs.python.org (Alex)
Date: Wed, 12 Aug 2009 21:32:08 +0000
Subject: [New-bugs-announce] [issue6690] BUILD_SET followed by COMPARE_OP
(in) can be optimized if all items are consts
In-Reply-To: <1250112728.26.0.437991636315.issue6690@psf.upfronthosting.co.za>
Message-ID: <1250112728.26.0.437991636315.issue6690@psf.upfronthosting.co.za>
New submission from Alex <alex.gaynor at gmail.com>:
Just like we turn BUILD_LIST; COMPARE_OP (in) into a LOAD_CONST if all
the members are consts, we can do the same for BUILD_SET, instead
turning it into a LOAD_CONST of a frozenset. The following is the
bytecode that is current produced for each datastructure.
>>> dis.dis(lambda o: o in (1,2,3))
1 0 LOAD_FAST 0 (o)
3 LOAD_CONST 3 ((1, 2, 3))
6 COMPARE_OP 6 (in)
9 RETURN_VALUE
>>> dis.dis(lambda o: o in [1,2,3])
1 0 LOAD_FAST 0 (o)
3 LOAD_CONST 3 ((1, 2, 3))
6 COMPARE_OP 6 (in)
9 RETURN_VALUE
>>> dis.dis(lambda o: o in {1,2,3})
1 0 LOAD_FAST 0 (o)
3 LOAD_CONST 0 (1)
6 LOAD_CONST 1 (2)
9 LOAD_CONST 2 (3)
12 BUILD_SET 3
15 COMPARE_OP 6 (in)
18 RETURN_VALUE
----------
components: Interpreter Core
messages: 91506
nosy: alex
severity: normal
status: open
title: BUILD_SET followed by COMPARE_OP (in) can be optimized if all items are consts
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6690>
_______________________________________
From report at bugs.python.org Thu Aug 13 00:47:42 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 12 Aug 2009 22:47:42 +0000
Subject: [New-bugs-announce] [issue6691] Support for nested classes and
function for pyclbr
In-Reply-To: <1250117262.14.0.353515413158.issue6691@psf.upfronthosting.co.za>
Message-ID: <1250117262.14.0.353515413158.issue6691@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
I have worked on a patch for adding support for nested classes and
nested functions in pyclbr. I believe this might be useful for some
applications, and also for issue1612262.
The patch attached also contains a test and updated documentation.
----------
components: Library (Lib)
files: pyclbr_nested_objects.diff
keywords: patch
messages: 91508
nosy: gpolo
severity: normal
status: open
title: Support for nested classes and function for pyclbr
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file14703/pyclbr_nested_objects.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6691>
_______________________________________
From report at bugs.python.org Thu Aug 13 03:34:09 2009
From: report at bugs.python.org (Andrew Azarov)
Date: Thu, 13 Aug 2009 01:34:09 +0000
Subject: [New-bugs-announce] [issue6692] asyncore kqueue support
In-Reply-To: <1250127249.77.0.440620100529.issue6692@psf.upfronthosting.co.za>
Message-ID: <1250127249.77.0.440620100529.issue6692@psf.upfronthosting.co.za>
New submission from Andrew Azarov <equand at gmail.com>:
Is there a possibility of such feature in the future releases of Python?
Currently I see only select and epoll available, but on FreeBSD 7.2 with
a lot of connections asyncore (1600+ active HTTP connections) has
problems (not giving complete response) with epoll (select is
problematic after 250+ connections (not enough descriptors)).
----------
components: Library (Lib)
messages: 91512
nosy: Ikinoki
severity: normal
status: open
title: asyncore kqueue support
type: feature request
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6692>
_______________________________________
From report at bugs.python.org Thu Aug 13 10:31:58 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 13 Aug 2009 08:31:58 +0000
Subject: [New-bugs-announce] [issue6693] New functions in site.py to get
user/global site packages paths
In-Reply-To: <1250152318.06.0.31085221368.issue6693@psf.upfronthosting.co.za>
Message-ID: <1250152318.06.0.31085221368.issue6693@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
As discussed in Distutils-SIG.
Here's a patch for site.py that adds:
- getsitepackages : Returns a list containing all global site-packages
directories (and possibly site-python).
- getusersitepackages: Returns the user-specific site-packages directory
path.
- getuserbase: Returns the `user base` directory path.
----------
assignee: tarek
components: Library (Lib)
files: site.patch
keywords: patch
messages: 91516
nosy: tarek
priority: normal
severity: normal
status: open
title: New functions in site.py to get user/global site packages paths
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file14707/site.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6693>
_______________________________________
From report at bugs.python.org Thu Aug 13 11:04:09 2009
From: report at bugs.python.org (Alex Morega)
Date: Thu, 13 Aug 2009 09:04:09 +0000
Subject: [New-bugs-announce] [issue6694] itertools documentation still
contains references to ifilterfalse and izip_longest
In-Reply-To: <1250154249.26.0.325655481188.issue6694@psf.upfronthosting.co.za>
Message-ID: <1250154249.26.0.325655481188.issue6694@psf.upfronthosting.co.za>
New submission from Alex Morega <alex at grep.ro>:
The pages http://docs.python.org/dev/py3k/library/itertools.html and
http://docs.python.org/3.1/library/itertools.html contain the names
"ifilterfalse" and "izip_longest" in code examples for the "filterfalse"
and "zip_longest" functions.
----------
assignee: georg.brandl
components: Documentation
messages: 91518
nosy: alex.morega, georg.brandl
severity: normal
status: open
title: itertools documentation still contains references to ifilterfalse and izip_longest
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6694>
_______________________________________
From report at bugs.python.org Thu Aug 13 18:45:31 2009
From: report at bugs.python.org (Matthias Troffaes)
Date: Thu, 13 Aug 2009 16:45:31 +0000
Subject: [New-bugs-announce] [issue6695] PyXXX_ClearFreeList for dict, set,
and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
New submission from Matthias Troffaes <matthias.troffaes at gmail.com>:
The Python C API provides PyXXX_ClearFreeList functions to allow the
float, int, etc... freelists to be freed, potentially releasing memory
to the OS earlier. Currently, there is no such API for the dict, set,
and list freelists.
The attached patch adds PyXXX_ClearFreeList functions to the C API, so
the dict, set, and list freelists can be freed as well.
----------
components: Interpreter Core
files: py3k-clearfreelist-dict_set_list.patch
keywords: patch
messages: 91520
nosy: matthiastroffaes
severity: normal
status: open
title: PyXXX_ClearFreeList for dict, set, and list
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file14708/py3k-clearfreelist-dict_set_list.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________
From report at bugs.python.org Thu Aug 13 18:57:17 2009
From: report at bugs.python.org (Alexander Myodov)
Date: Thu, 13 Aug 2009 16:57:17 +0000
Subject: [New-bugs-announce] [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
New submission from Alexander Myodov <amyodov at gmail.com>:
Seems like a minor documentation issue in 2.x became more significant
one in 3.x.
In Python 2.6 (and lower), the documentation on Profile objects
discussed them as a part of hotshot module, while omitting the fact
that any profiler module, either of profile/cProfile/hotshot, supports
them (though in fact, hotshot Profile objects have an api a bit
different from profile/cProfile Profile objects). Note http://
docs.python.org/2.6/library/hotshot.html#profile-objects - there is no
separate documentation of non-hotshot Profile objects, though they are
largely similar. This is a minor issue which could probably be fixed in
2.7 as a separate problem - otherwise it is pretty unclear from the
documentation, what methods do cProfile Profile objects support (eg,
they support enable()/disable() and runcall() methods, which is pretty
useful for profiling, but impossible to find in documentation).
In Python 3.1, looks like everything related to hotshot was removed
from the documents, including the documentation on Profile objects -
which should not have been. This means, that now the documentation on
profilers does not cover any Profile classes at all - see http://
docs.python.org/3.1/library/profile.html . For example, the official
documentation doesn't say any way to profile a function passing
arguments to it and receiving its result - while profile/cProfile
Profile objects still do support runcall() method.
----------
assignee: georg.brandl
components: Documentation
messages: 91522
nosy: georg.brandl, honeyman
severity: normal
status: open
title: Profile objects should be documented
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6696>
_______________________________________
From report at bugs.python.org Thu Aug 13 22:07:32 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 13 Aug 2009 20:07:32 +0000
Subject: [New-bugs-announce] [issue6697] Python 3.1 segfaults when invalid
UTF-8 characters are passed from command line
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:
Python 3.1 segfaults when invalid UTF-8 characters are passed from
command line.
In BASH shell you can run:
$ python3.1 -c $'print("\x80")'
Segmentation fault
In other POSIX-compatible shells you can save the attached test.py
files in current directory and run:
$ python3.1 -c "$(<test.py)"
Segmentation fault
----------
components: Unicode
files: test.py
messages: 91533
nosy: Arfrever
severity: normal
status: open
title: Python 3.1 segfaults when invalid UTF-8 characters are passed from command line
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14711/test.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________
From report at bugs.python.org Fri Aug 14 00:03:11 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 13 Aug 2009 22:03:11 +0000
Subject: [New-bugs-announce] [issue6698] IDLE no longer opens only an edit
window when configured to do so
In-Reply-To: <1250200991.43.0.141209205867.issue6698@psf.upfronthosting.co.za>
Message-ID: <1250200991.43.0.141209205867.issue6698@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
If someone configure IDLE to start a edit window by default, I believe
it should open only an edit window without starting shell window. This
has been the behaviour in previous version, but it is acting different now.
I looked into r71126 and I think this behaviour was changed there
unintentionally. Its log message doesn't seem to mention this change,
that is why I'm thinking this.
----------
components: IDLE
messages: 91536
nosy: gpolo
severity: normal
status: open
title: IDLE no longer opens only an edit window when configured to do so
versions: Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6698>
_______________________________________
From report at bugs.python.org Fri Aug 14 01:58:50 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 13 Aug 2009 23:58:50 +0000
Subject: [New-bugs-announce] [issue6699] IDLE: Warn user about overwriting a
file that has a newer version on filesystem
In-Reply-To: <1250207930.18.0.223468874802.issue6699@psf.upfronthosting.co.za>
Message-ID: <1250207930.18.0.223468874802.issue6699@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
Creating this issue to address a suggestion of a new IDLE feature
pointed out on issue 1721083.
The feature in question is about warning the user about a newer version
of the file before overwriting it.
----------
components: IDLE
files: check_stmtime.diff
keywords: patch
messages: 91537
nosy: gpolo
severity: normal
status: open
title: IDLE: Warn user about overwriting a file that has a newer version on filesystem
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file14714/check_stmtime.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6699>
_______________________________________
From report at bugs.python.org Fri Aug 14 06:19:22 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 14 Aug 2009 04:19:22 +0000
Subject: [New-bugs-announce] [issue6700] inspect.getsource() returns
incorrect source lines
In-Reply-To: <1250223562.74.0.274098839265.issue6700@psf.upfronthosting.co.za>
Message-ID: <1250223562.74.0.274098839265.issue6700@psf.upfronthosting.co.za>
New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:
inspect.getsource(obj) returns incorrect results when obj is a
traceback or frame object outside any function (that is, at the module
level).
This demo script shows the problem. The correct output should contain
all source lines in the module, but it only returns the first two:
D:\temp>type show_inspect_bug.py
def foo(x):
return y + z
import inspect
frame = inspect.currentframe()
print inspect.getsource(frame)
D:\temp>python show_inspect_bug.py
def foo(x):
return y + z
The attached patch fixes the problem and adds some missing test cases.
Originally reported by Juanjo Conti at the local Python group.
----------
components: Library (Lib)
files: inspect.diff
keywords: patch
messages: 91541
nosy: gagenellina
severity: normal
status: open
title: inspect.getsource() returns incorrect source lines
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14716/inspect.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6700>
_______________________________________
From report at bugs.python.org Fri Aug 14 11:03:48 2009
From: report at bugs.python.org (Bogdan Opanchuk)
Date: Fri, 14 Aug 2009 09:03:48 +0000
Subject: [New-bugs-announce] [issue6701] Make custom xmlrpc extension easier
In-Reply-To: <1250240628.37.0.491365957246.issue6701@psf.upfronthosting.co.za>
Message-ID: <1250240628.37.0.491365957246.issue6701@psf.upfronthosting.co.za>
New submission from Bogdan Opanchuk <bg at bk.ru>:
I am sorry if the same issue was already considered and rejected for
some reason; quick search did not show any traces of it.
What I am going to write here is just a proof of concept, but if the
idea of the patch is acceptable, I am eager to prepare proper patches
for lib, documentation and so on.
So, my aim was to make xmlrpc module frendlier to those who want to
extend its functionality locally in their own projects. Currently there
are several problems with it:
1. Marshaller, unmarshaller and parser cannot be substituted by custom
versions easily.
2. Custom version of marshaller will look ugly (i.e., because it may
need to call Marshaller.__dump)
3. Transport, parser and unmarshaller are coupled now, though they are
completely independent.
My patch seem to eliminate these problems (see attach). Briefly, it
contains the following changes:
1. Transport, parser and unmarshaller are decoupled
2. Custom masrshaller, parser and unmarshaller classes can be passed to
client and server classes as parameters
3. Made Marshaller class easier to extend:
- __dump() renamed to _dump()
- added _add_memo() and _del_memo() (and hid .memo field)
- memo is now a set() (instead of dictionary with None values)
- dispatch table was made private
Results:
(good) This patch does not invalidate any part of documentation (but it
needs to be extended, according to new marshaller/unmarshaller/parser
parameters)
(good) test_xmlrpc still passes (with one little change to it, patch is
attached)
(good) Extension is easy now - see xmlrpc_overload.py as an example
(added bytes(), tuple() and dict() with non-string keys support)
(bad) Programs which use exported, but undocumented parts of xmlrpc can
break (though most of them can be easily fixed)
----------
components: Library (Lib)
messages: 91546
nosy: bogdan.opanchuk
severity: normal
status: open
title: Make custom xmlrpc extension easier
type: feature request
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6701>
_______________________________________
From report at bugs.python.org Fri Aug 14 14:28:17 2009
From: report at bugs.python.org (paolo)
Date: Fri, 14 Aug 2009 12:28:17 +0000
Subject: [New-bugs-announce] [issue6702] Tkinter: modify xview of entry
widget
In-Reply-To: <1250252897.03.0.863989377891.issue6702@psf.upfronthosting.co.za>
Message-ID: <1250252897.03.0.863989377891.issue6702@psf.upfronthosting.co.za>
New submission from paolo <paolo.fragu at libero.it>:
I wish to propose a useful and smart method modify in Tkinter Library:
Previously to scroll this widget we had to write an external function
(recalling xview_moveto and xview_scroll).
With my method this operation is cleared and the same as all other
widgets (just have to call xview).
----------------------------------------------------------
Modify Proposal:
----------------------------------------------------------
Change the method xview of entry so it works as all widget scrollable,
and it's compatible with 'old' xview.
So to scroll entry widget:
entry_widget['xscrollcommand']=scroll_widget.set
scroll_widget['command']=entry_widget.xview
The change in module Tkinter is:
def xview(self,*args):
"""Query and change horizontal position of the view."""
#modify
if not args:
return self._getdoubles(self.tk.call(self._w, 'xview'))
#old code
index=args[0]
self.tk.call(self._w, 'xview', index)
----------------------------------------------------------
+
It's call the tk interpreter passing entry and xview without arguments;
returns a list containing two elements to pass to scrollbars via the
xscrollcommand option
If an argument (index) is passing, then display the character given by
index at the left edge of the window; it work as the original xview
With 'old' methon is impossible call xview without arguments, the change
has made possible this.
-----------------------------------------------------------------
To scroll entry without modify:
-------------------------------
import Tkinter as tk
root=tk.Tk()
def scollEntry(*args):
if args[0]=='scroll':
e.xview_scroll(args[1],args[2])
if args[0]=='moveto':
e.xview_moveto(args[1])
e=tk.Entry(width=10)
e.grid(row=0, sticky='e'+'w')
s=tk.Scrollbar(orient='horizontal')
s.grid(row=1, sticky='e'+'w')
e['xscrollcommand']=s.set
s['command']=scollEntry
root.mainloop()
--------------------------------------------------------------------
With modify:
------------
import Tkinter as tk
root=tk.Tk()
e=tk.Entry(width=10)
e.grid(row=0, sticky='e'+'w')
s=tk.Scrollbar(orient='horizontal')
s.grid(row=1, sticky='e'+'w')
e['xscrollcommand']=s.set
s['command']=e.xview
root.mainloop()
-----------------------------------------------------------------
It's work also with tk-8.5 and ttk
----------------------------------
import Tkinter as tk
import ttk
root=tk.Tk()
e=ttk.Entry(width=10)
e.grid(row=0, sticky='e'+'w')
s=ttk.Scrollbar(orient='horizontal')
s.grid(row=1, sticky='e'+'w')
e['xscrollcommand']=s.set
s['command']=e.xview
root.mainloop()
---------------------------------------------------------
I tested with Python 2.5 and tk 8.4 and also tk 8.5 and module ttk
----------
components: Tkinter
messages: 91547
nosy: paolo
severity: normal
status: open
title: Tkinter: modify xview of entry widget
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6702>
_______________________________________
From report at bugs.python.org Fri Aug 14 18:18:17 2009
From: report at bugs.python.org (Chris Withers)
Date: Fri, 14 Aug 2009 16:18:17 +0000
Subject: [New-bugs-announce] [issue6703] cross platform failure and silly
test in doctest
In-Reply-To: <1250266697.36.0.481264395332.issue6703@psf.upfronthosting.co.za>
Message-ID: <1250266697.36.0.481264395332.issue6703@psf.upfronthosting.co.za>
New submission from Chris Withers <chris at simplistix.co.uk>:
Hi All,
Line 355 of this code on the 2.6 branch and trunk:
http://svn.python.org/view/python/branches/release26-
maint/Lib/doctest.py?view=annotate
http://svn.python.org/view/python/trunk/Lib/doctest.py?annotate=69012
...contain a check that doesn't work cross platform.
I'd argue that the check is worthless and should be removed.
I'm happy to do this, but is this code tested?
If not, do I need to add a test when I remove those two lines?
cheers,
Chris
----------
assignee: cjw296
messages: 91557
nosy: cjw296
severity: normal
status: open
title: cross platform failure and silly test in doctest
versions: Python 2.6, Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6703>
_______________________________________
From report at bugs.python.org Fri Aug 14 20:55:47 2009
From: report at bugs.python.org (Frank Wierzbicki)
Date: Fri, 14 Aug 2009 18:55:47 +0000
Subject: [New-bugs-announce] [issue6704] better col_offset for AST in
statements like "for a, b in ..."
In-Reply-To: <1250276147.3.0.975792717277.issue6704@psf.upfronthosting.co.za>
Message-ID: <1250276147.3.0.975792717277.issue6704@psf.upfronthosting.co.za>
New submission from Frank Wierzbicki <fwierzbicki at gmail.com>:
For statements like:
for a,b in c:
pass
The Tuple node "a,b" ends up with a col_offset of 0 (the position of the
"for"), but the col_offset should probably be 4 (the position of "a").
This is more consistent with other Tuple node col_offset results.
----------
components: Interpreter Core
files: ast.diff
keywords: patch
messages: 91566
nosy: fwierzbicki
severity: normal
status: open
title: better col_offset for AST in statements like "for a,b in ..."
versions: Python 2.7
Added file: http://bugs.python.org/file14727/ast.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6704>
_______________________________________
From report at bugs.python.org Fri Aug 14 23:36:38 2009
From: report at bugs.python.org (Michael Gruen)
Date: Fri, 14 Aug 2009 21:36:38 +0000
Subject: [New-bugs-announce] [issue6705] '''3, 5'''.strip(r''',
''') does not strip comma, returns '3, 5'
In-Reply-To: <1250285798.29.0.625956146612.issue6705@psf.upfronthosting.co.za>
Message-ID: <1250285798.29.0.625956146612.issue6705@psf.upfronthosting.co.za>
New submission from Michael Gruen <gruenm at gmail.com>:
I am new, I apologize if this is a trivial or non-problem. I have
researched for hours, tried every variant but cannot understand why this
doesn't work.
----------
components: None
messages: 91572
nosy: mgruen
severity: normal
status: open
title: '''3,5'''.strip(r''',''') does not strip comma, returns '3,5'
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6705>
_______________________________________
From report at bugs.python.org Sat Aug 15 01:03:37 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 14 Aug 2009 23:03:37 +0000
Subject: [New-bugs-announce] [issue6706] asyncore's accept() is broken
In-Reply-To: <1250291017.2.0.719693187742.issue6706@psf.upfronthosting.co.za>
Message-ID: <1250291017.2.0.719693187742.issue6706@psf.upfronthosting.co.za>
New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:
An old bad design choice in asyncore is how it forces the user to
override handle_accept() and then call self.accept() to obtain a socket
pair.
def handle_accept(self):
conn, addr = self.accept()
The documentation itself shows the code above as an example of how an
asyncore-based server should handle an incoming connection.
What the doc doesn't say is that the user calling self.accept() is
exposed to different risks:
- self.accept() can return None instead of a socket pair in which case
TypeError is raised (see pyftpdlib bug:
http://code.google.com/p/pyftpdlib/issues/detail?id=91)
- ECONNABORTED can be raised. This is reproducible on Linux by hammering
the server with nmap (see pyftpdlib bug:
http://code.google.com/p/pyftpdlib/issues/detail?id=105)
- EAGAIN can be raised too. I never experienced this error condition
myself in pyftpdlib but by looking at twisted/internet/tcp.py it seems
reasonable to catch EAGAIN too.
- The resulting address can be None, which means that the connection
didn't take place.
This is reproducible by hammering the server with nmap (see pyftpdlib
bug http://code.google.com/p/pyftpdlib/issues/detail?id=104).
The right thing to do when one of such events occur is to "return" as no
connection has really been established between client and server.
Now, altough handling these kind of conditions is quite easy, the API
design remains fundamentally wrong, as it forces the user to call
accept().
As asyncore.py is structured right now the only chance the user has to
properly accepting a connection is manually handling all these cases in
his subclass.
My patch in attachment tries to solve this problem by defining a new
"handle_accept_event()" method which takes care of all the error
conditions described above resulting in handle_accept() be called *only
when a connection really took place*.
When the connection is established handle_accept_event() stores the
socket pair as an attribute and the next call to accept() returns that
pair.
This preserves the current implementation without breaking any code as
the user will have to override handle_accept() and then call accept() in
the same manner [1], with the difference that self.accept() will always
return a valid socket pair.
[1]
def handle_accept(self):
conn, addr = self.accept()
----------
components: Library (Lib)
messages: 91579
nosy: giampaolo.rodola, josiahcarlson
severity: normal
status: open
title: asyncore's accept() is broken
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6706>
_______________________________________
From report at bugs.python.org Sat Aug 15 01:06:42 2009
From: report at bugs.python.org (Dino Viehland)
Date: Fri, 14 Aug 2009 23:06:42 +0000
Subject: [New-bugs-announce] [issue6707] dir() on __new__'d module w/o dict
crashes 2.6.2
In-Reply-To: <1250291202.25.0.109335007546.issue6707@psf.upfronthosting.co.za>
Message-ID: <1250291202.25.0.109335007546.issue6707@psf.upfronthosting.co.za>
New submission from Dino Viehland <dinov at microsoft.com>:
from types import ModuleType as M
m = M.__new__(M)
dir(m)
In 2.5 this raises an exception about not having __dict__, 2.6.2
crashes out right.
----------
components: Interpreter Core
messages: 91580
nosy: DinoV
severity: normal
status: open
title: dir() on __new__'d module w/o dict crashes 2.6.2
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6707>
_______________________________________
From report at bugs.python.org Sat Aug 15 04:21:10 2009
From: report at bugs.python.org (starz)
Date: Sat, 15 Aug 2009 02:21:10 +0000
Subject: [New-bugs-announce] [issue6708] raw_input() calls generate compile
errors.
In-Reply-To: <1250302870.91.0.18677691598.issue6708@psf.upfronthosting.co.za>
Message-ID: <1250302870.91.0.18677691598.issue6708@psf.upfronthosting.co.za>
New submission from starz <b_lynch1 at yahoo.com>:
# ------ SOURCE -------
# cheerleading program
word = raw_input("Who do you go for? ")
for letter in word:
call = "Gimme a " + letter + "!"
print (call)
print (letter) + "!"
print( "What does that spell?")
print( word + "!")
# ------- end source -------
## within python.help()
## --------------------
help> raw_input()
no Python documentation found for 'raw_input()'
help>
### --- run from O/S ---
C:\Program Files\OpenOffice.org 2.0\program\python3.1>python
PYsource\test3.py
Traceback (most recent call last):
File "PYsource\test3.py", line 22, in <module>
word = raw_input("Who do you go for? ")
NameError: name 'raw_input' is not defined
C:\Program Files\OpenOffice.org 2.0\program\python3.1>
----------
components: Library (Lib)
files: test3.py
messages: 91584
nosy: starz
severity: normal
status: open
title: raw_input() calls generate compile errors.
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file14732/test3.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6708>
_______________________________________
From report at bugs.python.org Sat Aug 15 04:39:54 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 15 Aug 2009 02:39:54 +0000
Subject: [New-bugs-announce] [issue6709] It's possible to create TryExcept
with no handlers
In-Reply-To: <1250303994.53.0.2741455605.issue6709@psf.upfronthosting.co.za>
Message-ID: <1250303994.53.0.2741455605.issue6709@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <benjamin at python.org>:
I think we might need to devise some way to add custom validation when
AST is being compiled. For example, you can also pass a level to
ImportFrom which is < -1.
>>> x = ast.parse("try: x\nexcept y: pass")
>>> del x.body[0].handlers[:]
>>> compile(x, "<string>", "exec")
<code object <module> at 0x7f0a92aed918, file "<string>", line 1>
>>> from dis import dis
>>> dis(x)
>>> dis(compile(x, "<string>", "exec"))
1 0 SETUP_EXCEPT 8 (to 11)
3 LOAD_NAME 0 (x)
6 POP_TOP
7 POP_BLOCK
8 JUMP_FORWARD 1 (to 12)
>> 11 END_FINALLY
>> 12 LOAD_CONST 0 (None)
15 RETURN_VALUE
----------
components: Extension Modules, Interpreter Core
messages: 91587
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: It's possible to create TryExcept with no handlers
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6709>
_______________________________________
From report at bugs.python.org Sun Aug 16 00:12:18 2009
From: report at bugs.python.org (Jim Fulton)
Date: Sat, 15 Aug 2009 22:12:18 +0000
Subject: [New-bugs-announce] [issue6710] hotshot stats load causes TypeError
when multiple files are loaded
In-Reply-To: <1250374338.11.0.481034078931.issue6710@psf.upfronthosting.co.za>
Message-ID: <1250374338.11.0.481034078931.issue6710@psf.upfronthosting.co.za>
New submission from Jim Fulton <jim at zope.com>:
I've attached a script that demonstrates the problem. When run with
Python 2.5, it outputs statistics. When run with Python 2.6.2 it
generates a TypeError:
python2.6 hotshotbug.py
Traceback (most recent call last):
File "hotshotbug.py", line 5, in <module>
stats.add(hotshot.stats.load('p2'))
File "/usr/local/python/2.6/lib/python2.6/pstats.py", line 171, in add
self.stats[func] = add_func_stats(old_func_stat, stat)
File "/usr/local/python/2.6/lib/python2.6/pstats.py", line 516, in
add_func_stats
add_callers(t_callers, callers))
File "/usr/local/python/2.6/lib/python2.6/pstats.py", line 526, in
add_callers
zip(caller, new_callers[func])])
TypeError: zip argument #1 must support iteration
----------
components: Library (Lib)
files: hotshotbug.py
messages: 91619
nosy: j1m
severity: normal
status: open
title: hotshot stats load causes TypeError when multiple files are loaded
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14734/hotshotbug.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6710>
_______________________________________
From report at bugs.python.org Sun Aug 16 08:25:40 2009
From: report at bugs.python.org (Joe Amenta)
Date: Sun, 16 Aug 2009 06:25:40 +0000
Subject: [New-bugs-announce] [issue6711] macurl2path has typos that raise
AttributeError
In-Reply-To: <1250403940.35.0.572726504822.issue6711@psf.upfronthosting.co.za>
Message-ID: <1250403940.35.0.572726504822.issue6711@psf.upfronthosting.co.za>
New submission from Joe Amenta <amentajo at msu.edu>:
In a few spots, "urllib.parse" misses a "." after the package name.
e.g., "urllib.parse.quote" is spelled "urllib.parsequote", which
generates an AttributeError when run.
To reproduce, open up a python3.x interpreter and execute:
from macurl2path import *
url2pathname('doesnt_matter_what')
pathname2url('some_string')
_pncomp2url('something_else')
Attaching a patch that will fix the issue.
----------
components: Library (Lib)
files: py3k_url2path.patch
keywords: patch
messages: 91627
nosy: joe.amenta
severity: normal
status: open
title: macurl2path has typos that raise AttributeError
type: crash
versions: Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14735/py3k_url2path.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6711>
_______________________________________
From report at bugs.python.org Sun Aug 16 12:44:21 2009
From: report at bugs.python.org (Johannes Janssen)
Date: Sun, 16 Aug 2009 10:44:21 +0000
Subject: [New-bugs-announce] [issue6712] sys._getframe is not available on
all Python implementations
In-Reply-To: <1250419461.12.0.110179836515.issue6712@psf.upfronthosting.co.za>
Message-ID: <1250419461.12.0.110179836515.issue6712@psf.upfronthosting.co.za>
New submission from Johannes Janssen <mail at johannes-janssen.de>:
As I learned on the mailing list the function sys._getframe() is not
available on all Python implementations (e.g. jython). This information
should be added to the documentation.
----------
assignee: georg.brandl
components: Documentation
messages: 91629
nosy: georg.brandl, johannes.janssen
severity: normal
status: open
title: sys._getframe is not available on all Python implementations
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6712>
_______________________________________
From report at bugs.python.org Sun Aug 16 19:45:49 2009
From: report at bugs.python.org (Gawain Bolton)
Date: Sun, 16 Aug 2009 17:45:49 +0000
Subject: [New-bugs-announce] [issue6713] Integer & Long types: Performance
improvement of 1.6x to 2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
New submission from Gawain Bolton <gp.bolton at computer.org>:
Converting integer & long types to their ASCII representation is a task
which can be quite CPU intensive due to the division & modulo
operations. For long integers having hundreds or thousands of digits,
this can take a truly significant amount of CPU time.
I have written a special case for base 10 conversions which allows for
two improvements.
1) Two digits can be converted at a time, thus reducing the number of
div/mod operations by two.
2) An optimizing compiler can avoid performing a division operation when
the divisor is hardcoded. The expensive division operation can be
replaced by a much faster multiplication operation.
My tests show an improvement of 1.6x to 1.8x improvement for integer
types and 2x improvement for longs.
Note that because integers are displayed using fprintf(), the
performance improvement is only seen when __repr__() is called.
Patch is provided against trunk. It is somewhat difficult to read the
patch in one or two places due to the use of tabs.
----------
components: Interpreter Core
files: base10_conversion_performance_patch.txt
messages: 91636
nosy: gawain
severity: normal
status: open
title: Integer & Long types: Performance improvement of 1.6x to 2x for base 10 conversions
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file14736/base10_conversion_performance_patch.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6713>
_______________________________________
From report at bugs.python.org Sun Aug 16 23:32:53 2009
From: report at bugs.python.org (Giorgos Verigakis)
Date: Sun, 16 Aug 2009 21:32:53 +0000
Subject: [New-bugs-announce] [issue6714] memmove fails with unicode strings
In-Reply-To: <1250458373.38.0.665694741005.issue6714@psf.upfronthosting.co.za>
Message-ID: <1250458373.38.0.665694741005.issue6714@psf.upfronthosting.co.za>
New submission from Giorgos Verigakis <verigak at gmail.com>:
A demonstration:
>>> buf = create_string_buffer('______')
>>> memmove(buf, 'SPAM', 4)
614584
>>> buf.raw
'SPAM__\x00'
>>> buf = create_string_buffer('______')
>>> memmove(buf, u'SPAM', 4)
614672
>>> buf.raw
'S\x00\x00\x00__\x00'
FWIW memmove fails in Python 3.0 too.
----------
assignee: theller
components: ctypes
messages: 91644
nosy: theller, verigak
severity: normal
status: open
title: memmove fails with unicode strings
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6714>
_______________________________________
From report at bugs.python.org Mon Aug 17 11:47:24 2009
From: report at bugs.python.org (devurandom)
Date: Mon, 17 Aug 2009 09:47:24 +0000
Subject: [New-bugs-announce] [issue6715] xz compression support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
New submission from devurandom <devurandom at gmx.net>:
Python currently supports zlib, gzip and bzip2 compressors. What is missing is support
for xz (http://tukaani.org/xz/). It comes with a C library.
----------
components: Library (Lib)
messages: 91657
nosy: devurandom
severity: normal
status: open
title: xz compression support
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________
From report at bugs.python.org Mon Aug 17 15:05:09 2009
From: report at bugs.python.org (pds)
Date: Mon, 17 Aug 2009 13:05:09 +0000
Subject: [New-bugs-announce] [issue6716] Windows install error when choosing
to compile .py files
In-Reply-To: <1250514309.72.0.0787236734451.issue6716@psf.upfronthosting.co.za>
Message-ID: <1250514309.72.0.0787236734451.issue6716@psf.upfronthosting.co.za>
New submission from pds <pirdirsir at gmail.com>:
There seem to be 3 problems in Python 3.1.1rc1 Windows installer package.
1. Command line argument of compileall.py seems wrong.
2. UnicodeEncodeError occurs depending on code page.
3. Syntax errors.
First, I tried to install Python 3.1.1rc1 just by double-clicking the
Windows msi installer package file, python-3.1.1rc1.msi, as an
administrator account, with the following environment and settings.
Operating System version: Windows XP Professional SP3 (Japanese version)
Install options: Install for all users
Destination directory: C:\Python31
Advanced options: Enable "Compile .py files to byte code after installation"
Then the following dialog message appeared during installation.
There is a problem with this Windows Installer package. A program run as
part of the setup did not finish as expected. Contact your support
personnel or package vendor.
Despite the message, installation of Python interpreter seemed completed
because the programs were registered in Windows start menu.
So I uninstalled Python 3.1.1rc1 to make sure the system to be clean,
and retried installation with the following command from command prompt
so I could see the log file later.
msiexec /i python-3.1.1rc1.msi /L*v python-3.1.1rc1.log
Installation failed again, and the following is the part of the log file
(python-3.1.1rc1.log).
MSI (s) (18:50) [15:08:25:096]: Note: 1: 1722 2: CompilePyc 3:
C:\Python31\python.exe 4: -Wi "C:\Python31\Lib\compileall.py" -f -x
bad_coding|badsyntax|site-packages|py2_ "C:\Python31\Lib"
MSI (s) (18:50) [15:08:25:096]: Note: 1: 2262 2: Error 3: -2147287038
Error 1722. There is a problem with this Windows Installer package. A
program run as part of the setup did not finish as expected. Contact
your support personnel or package vendor. Action CompilePyc, location:
C:\Python31\python.exe, command: -Wi "C:\Python31\Lib\compileall.py" -f
-x bad_coding|badsyntax|site-packages|py2_ "C:\Python31\Lib"
MSI (s) (18:50) [15:10:58:677]: Note: 1: 2262 2: Error 3: -2147287038
MSI (s) (18:50) [15:10:58:677]: Product: Python 3.1.1rc1 -- Error 1722.
There is a problem with this Windows Installer package. A program run as
part of the setup did not finish as expected. Contact your support
personnel or package vendor. Action CompilePyc, location:
C:\Python31\python.exe, command: -Wi "C:\Python31\Lib\compileall.py" -f
-x bad_coding|badsyntax|site-packages|py2_ "C:\Python31\Lib"
Also, installation completes normally if I choose not to compile .py
files in advanced options setting during the installer's setup dialog.
------
Problem 1: Command line argument of compileall.py seems wrong.
Because installation fails if I choose to compile .py files during
installation, I tried to compile .py files manually after installation
(without compilation) completes.
After finishing installation without compiling .py files, I did the
following command from Windows command prompt.
C:\Python31\python.exe "C:\Python31\Lib\compileall.py" -f -x
bad_coding|badsyntax|site-packages|py2_ "C:\Python31\Lib"
And I got the following error message.
(My Windows is Japanese version.)
'badsyntax' ??????????????????????????????
???? ?????????????????
This means, in English,
'badsyntax' is not recognized as an internal or external command,
operable program or batch file.
So I thought the command would be interpreted correctly if I embrace the
following part of the command with "".
bad_coding|badsyntax|site-packages|py2_
So I did the following from command prompt.
C:\Python31\python.exe "C:\Python31\Lib\compileall.py" -f -x
"bad_coding|badsyntax|site-packages|py2_" "C:\Python31\Lib"
And the compilation seemed to proceed.
However, the log file above (python-3.1.1rc1.log) says the argument is
not embraced with "" when compileall.py script is invoked during
installation process.
I suppose the argument not embraced with "" is one of the reasons why
installation process is interrupted.
Is this a bug of the installer package?
------
Problem 2: UnicodeEncodeError occurs depending on code page.
Compiling .py files seems to proceed by double-quoting the argument
discussed above when manually invoking compileall.py script, but the
following error occurs.
Listing C:\Python31\Lib\lib2to3\tests\data ...
Compiling C:\Python31\Lib\lib2to3\tests\data\crlf.py ...
*** File "C:\Python31\Lib\lib2to3\tests\data\crlf.py", line 1
print "hi"
^
SyntaxError: invalid syntax
Compiling C:\Python31\Lib\lib2to3\tests\data\different_encoding.py ...
*** Traceback (most recent call last):
File "C:\Python31\Lib\py_compile.py", line 142, in compile
codeobject = builtins.compile(codestring, dfile or file,'exec')
File "C:\Python31\Lib\lib2to3\tests\data\different_encoding.py", line 3
print
u'\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd8\xd9\xda\xdb\xdc\xdd\xde'
^
SyntaxError: invalid syntax
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\Python31\Lib\compileall.py", line 72, in compile_dir
ok = py_compile.compile(fullname, None, dfile, True)
File "C:\Python31\Lib\py_compile.py", line 146, in compile
raise py_exc
py_compile.PyCompileError: File
"C:\Python31\Lib\lib2to3\tests\data\different_encoding.py", line 3
print
u'\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd8\xd9\xda\xdb\xdc\xdd\xde'
^
SyntaxError: invalid syntax
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\Python31\Lib\compileall.py", line 170, in <module>
exit_status = int(not main())
File "C:\Python31\Lib\compileall.py", line 160, in main
force, rx, quiet):
File "C:\Python31\Lib\compileall.py", line 97, in compile_dir
quiet):
File "C:\Python31\Lib\compileall.py", line 97, in compile_dir
quiet):
File "C:\Python31\Lib\compileall.py", line 97, in compile_dir
quiet):
File "C:\Python31\Lib\compileall.py", line 80, in compile_dir
print(err.msg)
UnicodeEncodeError: 'cp932' codec can't encode character '\xdf' in
position 86: illegal multibyte sequence
'cp932' is the default code page of Japanese version of Windows.
So I tried the following command to change the current code page of the
command prompt window to 850 (Latin-1) before running compileall.py
script, aiming to avoid the seemingly code-page specific problem.
chcp 850
By doing so, the UnicodeEncodeError seemed to be avoided as expected.
------
Problem 3: Syntax errors.
After changing the code page to 850, the UnicodeEncodeError doesn't seem
to occur.
However, the syntax errors still occur as follows.
Compiling C:\Python31\Lib\lib2to3\tests\data\crlf.py ...
*** File "C:\Python31\Lib\lib2to3\tests\data\crlf.py", line 1
print "hi"
^
SyntaxError: invalid syntax
Compiling C:\Python31\Lib\lib2to3\tests\data\different_encoding.py ...
*** File "C:\Python31\Lib\lib2to3\tests\data\different_encoding.py",
line 3
print u'??????????????????????????????????????????????????????????????'
^
SyntaxError: invalid syntax
I don't know about how these script files (crlf.py and
different_encoding.py) are used, but isn't it necessary for those lines
of print function to be written like print("hi") because the interpreter
version is 3.x?
----------
components: Installation
messages: 91662
nosy: pds
severity: normal
status: open
title: Windows install error when choosing to compile .py files
type: compile error
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6716>
_______________________________________
From report at bugs.python.org Mon Aug 17 16:16:01 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Mon, 17 Aug 2009 14:16:01 +0000
Subject: [New-bugs-announce] [issue6717] Some problem with recursion handling
In-Reply-To: <1250518561.04.0.421053701967.issue6717@psf.upfronthosting.co.za>
Message-ID: <1250518561.04.0.421053701967.issue6717@psf.upfronthosting.co.za>
New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:
I suspect that there is some deeper (more severe) issue behind the
problem I describe below. I've observed the following on Windows only.
Didn't try it with different OSs
running dragbug.py shows different behaviour with Python 3.1 compared to
Python 2.6:
Running it with Python 3.1 and performing heavy turtle dragging with the
mouse results in:
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
-- As I do at the moment ;-)
Running the same script from Python 2.6: The error is much harder to
reproduce (only with very excessive dragging). It's a bit easier to
reproduce when running the program from a console and if it occurs one
gets a conventional Python error message:
First a long sequence of:
Exception in Tkinter callback
Traceback (most recent call last):
Exception RuntimeError: 'maximum recursion depth exceeded while ....
ignored
Followed by:
Traceback (most recent call last):
File "dragbug.py", line 10, in <module>
mainloop()
....
File "c:\Python26\lib\traceback.py", line 57, in print_tb
if hasattr(sys, 'tracebacklimit'):
AttributeError: 'module' object has no attribute 'tracebacklimit'
This problem can be overcome by setting a higher recurson limit. But I
think one should require that it doesn't produce a Fatal Error like in
Python 3.1
Regards,
Gregor
----------
components: Library (Lib)
files: dragbug.py
messages: 91664
nosy: gregorlingl
severity: normal
status: open
title: Some problem with recursion handling
versions: Python 3.1
Added file: http://bugs.python.org/file14738/dragbug.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6717>
_______________________________________
From report at bugs.python.org Mon Aug 17 18:48:24 2009
From: report at bugs.python.org (Eric Pope)
Date: Mon, 17 Aug 2009 16:48:24 +0000
Subject: [New-bugs-announce] [issue6718] ValueError in 21.17.4.2.
SocketServer.UDPServer Example
In-Reply-To: <1250527704.81.0.852484951369.issue6718@psf.upfronthosting.co.za>
Message-ID: <1250527704.81.0.852484951369.issue6718@psf.upfronthosting.co.za>
New submission from Eric Pope <slotterkey_privateer at yahoo.co.jp>:
In the client side example under
21.17.4.2. SocketServer.UDPServer Example:
at:
http://docs.python.org/dev/library/socketserver.html
<<<<raises ValueError:
HOST, PORT = "localhost"
>>>>should have been:
HOST, PORT = "localhost", 9999
----------
assignee: georg.brandl
components: Documentation
messages: 91666
nosy: ericpope, georg.brandl
severity: normal
status: open
title: ValueError in 21.17.4.2. SocketServer.UDPServer Example
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6718>
_______________________________________
From report at bugs.python.org Mon Aug 17 18:50:11 2009
From: report at bugs.python.org (samuel de framond)
Date: Mon, 17 Aug 2009 16:50:11 +0000
Subject: [New-bugs-announce] [issue6719] pdb messes up when debugging an
non-ascii program
In-Reply-To: <1250527811.0.0.14372124674.issue6719@psf.upfronthosting.co.za>
Message-ID: <1250527811.0.0.14372124674.issue6719@psf.upfronthosting.co.za>
New submission from samuel de framond <samuel43 at laposte.net>:
consider a program like this one:
---- File: ./test.py ----
#/usr/bin/env python
#coding: utf8
print 'qwerty'
-------------------------
Here is a shell (e.g. bash) session:
$ python -m pdb ./test.py
--Return--
> /usr/lib/python2.6/encodings/__init__.py(69)normalize_encoding()->'latin1'
-> return '_'.join(encoding.translate(_norm_encoding_map).split())
(Pdb)
While for a file without the line #2, the output would be:
$ python -m pdb ./test.py
> /home/.../test.py(3)<module>()
-> print 'qwerty'
(Pdb)
Here is the thing: the normal behaviour of pdb in this case is to pause
before executing the first line of the program. Instead of this, it
pauses at line #69 in .../encodings/__init__.py, which makes pdb almost
unusable.
Plus, pdb's inline command "q" (or "quit") does not work anymore. Here,
the first line should close the program but it does not:
(Pdb) q
Traceback (most recent call last):
File "/usr/lib/python2.6/pdb.py", line 1283, in main
pdb._runscript(mainpyfile)
File "/usr/lib/python2.6/pdb.py", line 1202, in _runscript
self.run(statement)
File "/usr/lib/python2.6/bdb.py", line 368, in run
exec cmd in globals, locals
File "<string>", line 1, in <module>
File "./test.py", line 2
SyntaxError: encoding problem: with BOM (test.py, line 2)
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> <string>(1)<module>()
(Pdb)
if 'q' is types a second time in a row, it goes like this and we are
back to starting point:
(Pdb) q
Post mortem debugger finished. The ./test.py will be restarted
--Return--
> /usr/lib/python2.6/encodings/__init__.py(69)normalize_encoding()->'latin1'
-> return '_'.join(encoding.translate(_norm_encoding_map).split())
(Pdb)
----------
components: Library (Lib)
messages: 91667
nosy: smu
severity: normal
status: open
title: pdb messes up when debugging an non-ascii program
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6719>
_______________________________________
From report at bugs.python.org Mon Aug 17 22:23:21 2009
From: report at bugs.python.org (Benjamin Liles)
Date: Mon, 17 Aug 2009 20:23:21 +0000
Subject: [New-bugs-announce] [issue6720] multiprocessing logging
In-Reply-To: <1250540601.66.0.070668154898.issue6720@psf.upfronthosting.co.za>
Message-ID: <1250540601.66.0.070668154898.issue6720@psf.upfronthosting.co.za>
New submission from Benjamin Liles <benliles at gmail.com>:
In the backport package of the multiprocessing library. A bug was
introduced in version 2.6.2.1 when the logging module was modified. If
you use logging in the backport, you get the following:
Traceback (most recent call last):
File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/logging/__init__.py",
line 744, in emit
msg = self.format(record)
File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/logging/__init__.py",
line 630, in format
return fmt.format(record)
File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/logging/__init__.py",
line 421, in format
s = self._fmt % record.__dict__
KeyError: 'processName'
----------
components: Library (Lib)
messages: 91670
nosy: benliles
severity: normal
status: open
title: multiprocessing logging
type: crash
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6720>
_______________________________________
From report at bugs.python.org Tue Aug 18 01:06:18 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 17 Aug 2009 23:06:18 +0000
Subject: [New-bugs-announce] [issue6721] Locks in python standard library
should be sanitized on fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
New submission from Gregory P. Smith <greg at krypto.org>:
The python logging module uses a lock to surround many operations, in
particular. This causes deadlocks in programs that use logging, fork
and threading simultaneously.
1) spawn one or more threads in your program
2) have at least one of those threads make logging calls that will be
emitted.
3) have your main thread or another thread use os.fork() to run some
python code in a child process.
4) If the fork happened while one of your threads was within the
logging.Handler.handle() critical section (or anywhere else where
handler.lock is acquired), your child process will deadlock as soon as
it tries to log anything. It inherited a held lock.
The deadlock is more likely to happen on a highly loaded system which
tends to widen the deadlock opportunity window due to context switching.
A demo of the problem simplified into one file is attached.
The Python standard library should not be the cause of these deadlocks.
We need a way for all standard library locks to be cleaned up when
forking. By doing one of the following:
A) acquire all locks before forking, release them immediately after.
B) forceably release all standard library locks after forking in the
child process.
Code was added to call some cleanups after forking in
http://bugs.python.org/issue874900 but there are more things that also
need this same sort of cleanup (logging for example).
Rather than having to manually add after fork code hooks into every file
in the standard library that uses locks, a more general solution to
track and manage locks across fork would be a good idea.
----------
assignee: gregory.p.smith
files: lock_fork_thread_deadlock_demo.py
messages: 91674
nosy: gregory.p.smith
priority: high
severity: normal
status: open
title: Locks in python standard library should be sanitized on fork
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14740/lock_fork_thread_deadlock_demo.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________
From report at bugs.python.org Tue Aug 18 12:38:45 2009
From: report at bugs.python.org (Alexey Shamrin)
Date: Tue, 18 Aug 2009 10:38:45 +0000
Subject: [New-bugs-announce] [issue6722] collections.namedtuple: confusing
example
In-Reply-To: <1250591925.23.0.269848636465.issue6722@psf.upfronthosting.co.za>
Message-ID: <1250591925.23.0.269848636465.issue6722@psf.upfronthosting.co.za>
New submission from Alexey Shamrin <shamrin at gmail.com>:
Maybe it's just me, but it took me several attempts to understand
namedtuple example in the documentation [1]. The problem is that the
first example uses verbose=True. It's very unusual to get Python source
as the output in Python shell. At first I thought there's some syntax
error in documentation source.
I know that several lines above one can read: "If verbose is true, the
class definition is printed just before being built." But during first
several attempts to understand namedtuple, I skipped it and directly
scrolled to the first example.
I think the first example on namedtuple usage shouldn't use verbose=True.
You could argue I had to try using namedtuple inside Python shell. I
agree. But unfortunately Python 2.6 was not installed on the computer I
was at.
[1]: http://docs.python.org/library/collections.html#collections.namedtuple
----------
assignee: georg.brandl
components: Documentation
messages: 91680
nosy: ash, georg.brandl
severity: normal
status: open
title: collections.namedtuple: confusing example
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6722>
_______________________________________
From report at bugs.python.org Tue Aug 18 14:38:34 2009
From: report at bugs.python.org (Nicolas Goutte)
Date: Tue, 18 Aug 2009 12:38:34 +0000
Subject: [New-bugs-announce] [issue6723] csv.writer: example does not work
In-Reply-To: <1250599114.63.0.456902579657.issue6723@psf.upfronthosting.co.za>
Message-ID: <1250599114.63.0.456902579657.issue6723@psf.upfronthosting.co.za>
New submission from Nicolas Goutte <nicolas.goutte at extragroup.de>:
In the documentation for csv.writer, the example
spamWriter = csv.writer(open('eggs.csv', 'w'), delimiter=' ',
quotechar='|', quoting=QUOTE_MINIMAL)
does not work, as Python complains about "SyntaxError: invalid syntax",
as QUOTE_MINIMAL is not a global identifier.
By replacing QUOTE_MINIMAL by csv.QUOTE_MINIMAL there is no syntax error
anymore.
I have discovered the issue with python 2.6.2. All online documentation
version (2.6, 2.7, 3.1, 3.2) seem to have the same documentation (e.g.
http://docs.python.org/library/csv.html )
----------
assignee: georg.brandl
components: Documentation
messages: 91682
nosy: georg.brandl, nicolasg
severity: normal
status: open
title: csv.writer: example does not work
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6723>
_______________________________________
From report at bugs.python.org Tue Aug 18 14:49:44 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 18 Aug 2009 12:49:44 +0000
Subject: [New-bugs-announce] [issue6724] r74463 causes failures in
test_xmlrpc
In-Reply-To: <1250599784.86.0.0936114935604.issue6724@psf.upfronthosting.co.za>
Message-ID: <1250599784.86.0.0936114935604.issue6724@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
The title says it all.
----------
assignee: gregory.p.smith
components: Library (Lib), Tests
messages: 91685
nosy: gregory.p.smith, r.david.murray
priority: high
severity: normal
stage: needs patch
status: open
title: r74463 causes failures in test_xmlrpc
type: behavior
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6724>
_______________________________________
From report at bugs.python.org Tue Aug 18 16:48:10 2009
From: report at bugs.python.org (CarGuy37)
Date: Tue, 18 Aug 2009 14:48:10 +0000
Subject: [New-bugs-announce] [issue6725] Inconsistency in Documentation:
"Name Spaces" vs "Namespaces"
In-Reply-To: <1250606890.78.0.538914735097.issue6725@psf.upfronthosting.co.za>
Message-ID: <1250606890.78.0.538914735097.issue6725@psf.upfronthosting.co.za>
New submission from CarGuy37 <tom.macleod at analog.com>:
Why is there an inconsistency in the usage of "Name Spaces" vs "Namespaces"?
After "import this", Python returns "...Namespaces are ..."
I would suggest conjoining the two words and being consistent (9.2 Title
and beginning sentence of the 6th paragraph thereof).
----------
assignee: georg.brandl
components: Documentation
messages: 91696
nosy: CarGuy37, georg.brandl
severity: normal
status: open
title: Inconsistency in Documentation: "Name Spaces" vs "Namespaces"
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6725>
_______________________________________
From report at bugs.python.org Tue Aug 18 16:58:40 2009
From: report at bugs.python.org (Marcin)
Date: Tue, 18 Aug 2009 14:58:40 +0000
Subject: [New-bugs-announce] [issue6726] pyuic4.bat has bad path to
python.exe and pyuic.py
In-Reply-To: <1250607520.51.0.355882528054.issue6726@psf.upfronthosting.co.za>
Message-ID: <1250607520.51.0.355882528054.issue6726@psf.upfronthosting.co.za>
New submission from Marcin <maar.cz at gmail.com>:
I have found bug in pyuic4.bat. I have installed python to directory
c:\programs. The path to 'python.exe' is c:\programs\python.exe. Content
of file pyuic4.bat is:
@"C:\Python25\python.exe"
"C:\Python25\Lib\site-packages\PyQt4\uic\pyuic.py" %1 %2 %3 %4 %5 %6 %7
%8 %9
In this file, during installation process it must be changed path to
python.exe.
In my example it must be done like that:
@"C:\programs\Python25\python.exe"
"C:\programs\Python25\Lib\site-packages\PyQt4\uic\pyuic.py" %1 %2 %3 %4
%5 %6 %7 %8 %9
----------
components: Demos and Tools
messages: 91697
nosy: maar
severity: normal
status: open
title: pyuic4.bat has bad path to python.exe and pyuic.py
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6726>
_______________________________________
From report at bugs.python.org Tue Aug 18 17:13:03 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 18 Aug 2009 15:13:03 +0000
Subject: [New-bugs-announce] [issue6727] ImportError when package is
symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
New submission from Jason R. Coombs <jaraco at jaraco.com>:
Python reports an import error, even when a valid package exists on
sys.path, if that package is a symlink directory and would otherwise be
importable.
The attached test script demonstrates the limitation on Python 2.6.2 and
3.1.0.
I suspect that the underlying import routines have some assumptions
about the file system that exclude symlinked directories.
----------
components: Interpreter Core, Windows
files: test_import_symlink_package.py
messages: 91699
nosy: jaraco
severity: normal
status: open
title: ImportError when package is symlinked on Windows
type: behavior
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file14741/test_import_symlink_package.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________
From report at bugs.python.org Tue Aug 18 17:58:08 2009
From: report at bugs.python.org (Yang)
Date: Tue, 18 Aug 2009 15:58:08 +0000
Subject: [New-bugs-announce] [issue6728] To avoid hang up in using
CGIXMLRPCRequestHandler under IIS 7.x
In-Reply-To: <1250611088.83.0.579376687228.issue6728@psf.upfronthosting.co.za>
Message-ID: <1250611088.83.0.579376687228.issue6728@psf.upfronthosting.co.za>
New submission from Yang <student at live.cn>:
The mismatched content length will cause hang up in sys.stdin.read().
The reason is probably described in Issue 1214 as well as 1725295.
length = int(os.environ.get('CONTENT_LENGTH', None))
"""Length fix for IIS 7.x to avoid hang up"""
length=length-2
I would appreciate if someone can create a diff or patch file for the
code above.
----------
components: Library (Lib)
messages: 91707
nosy: sjtuer
severity: normal
status: open
title: To avoid hang up in using CGIXMLRPCRequestHandler under IIS 7.x
type: feature request
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6728>
_______________________________________
From report at bugs.python.org Tue Aug 18 22:16:41 2009
From: report at bugs.python.org (Nikolaus Rath)
Date: Tue, 18 Aug 2009 20:16:41 +0000
Subject: [New-bugs-announce] [issue6729] Add support for ssize_t
In-Reply-To: <1250626601.03.0.294570676817.issue6729@psf.upfronthosting.co.za>
Message-ID: <1250626601.03.0.294570676817.issue6729@psf.upfronthosting.co.za>
New submission from Nikolaus Rath <Nikolaus at rath.org>:
ctypes currently has a datatype c_size_t which corresponds to size_t in
C, but there is no datatype for the C ssize_t.
----------
assignee: theller
components: ctypes
messages: 91713
nosy: Nikratio, theller
severity: normal
status: open
title: Add support for ssize_t
type: feature request
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6729>
_______________________________________
From report at bugs.python.org Tue Aug 18 22:28:55 2009
From: report at bugs.python.org (Maxime Lemonnier)
Date: Tue, 18 Aug 2009 20:28:55 +0000
Subject: [New-bugs-announce] [issue6730] dict.fromkeys() should not cross
reference mutable value by default
In-Reply-To: <1250627335.2.0.623159685079.issue6730@psf.upfronthosting.co.za>
Message-ID: <1250627335.2.0.623159685079.issue6730@psf.upfronthosting.co.za>
New submission from Maxime Lemonnier <maxime.lemonnier at gmail.com>:
Consider the following code sample :
keys = ['x', 'y', 'z']
d = dict.fromkeys(keys, [])
d['x'].append('dont')
d['y'].append('mix')
d['z'].append('me!')
print d['x']
>>> ['dont', 'mix', 'me!']
It is very unatural and dangerous to have all dict keys poining to the
same mutable object reference.
The way it should behave :
if value is mutable, create a new copy of value for each keys
else, it doesn't matter
----------
components: Interpreter Core
messages: 91714
nosy: maxlem
severity: normal
status: open
title: dict.fromkeys() should not cross reference mutable value by default
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6730>
_______________________________________
From report at bugs.python.org Wed Aug 19 00:25:22 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 18 Aug 2009 22:25:22 +0000
Subject: [New-bugs-announce] [issue6731] Non-zero exit status of setup.py
when building of extensions has failed
In-Reply-To: <1250634322.79.0.224296931911.issue6731@psf.upfronthosting.co.za>
Message-ID: <1250634322.79.0.224296931911.issue6731@psf.upfronthosting.co.za>
New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:
sharedmods rule of Makefile calls setup.py which doesn't fail even
building of extensions has failed.
----------
components: Build
files: python-non-zero_exit_status_on_failure.patch
keywords: patch
messages: 91719
nosy: Arfrever
severity: normal
status: open
title: Non-zero exit status of setup.py when building of extensions has failed
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14742/python-non-zero_exit_status_on_failure.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6731>
_______________________________________
From report at bugs.python.org Wed Aug 19 01:48:29 2009
From: report at bugs.python.org (KAJIYAMA, Tamito)
Date: Tue, 18 Aug 2009 23:48:29 +0000
Subject: [New-bugs-announce] [issue6732] PyInit_shoddy() in shoddy.c does
not return anything on success
In-Reply-To: <1250639309.85.0.383557872806.issue6732@psf.upfronthosting.co.za>
Message-ID: <1250639309.85.0.383557872806.issue6732@psf.upfronthosting.co.za>
New submission from KAJIYAMA, Tamito <rd6t-kjym at asahi-net.or.jp>:
Section 2.1.4, "Subclassing other types", of "Extending and Embedding
the Python Interpreter" (Release: 3.1, Date: June 26, 2009) has a
complete list of shoddy.c, in which PyInit_shoddy() does not have a
return statement at the end to return a pointer to the created "shoddy"
module on success. Simply adding the missing "return m;" statement
would be fine.
----------
assignee: georg.brandl
components: Documentation
messages: 91720
nosy: georg.brandl, kajiyama
severity: normal
status: open
title: PyInit_shoddy() in shoddy.c does not return anything on success
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6732>
_______________________________________
From report at bugs.python.org Wed Aug 19 02:43:22 2009
From: report at bugs.python.org (fugounashi)
Date: Wed, 19 Aug 2009 00:43:22 +0000
Subject: [New-bugs-announce] [issue6733] curses line wrap broken when mixing
full- and half-width unicode characters
In-Reply-To: <1250642602.2.0.807698027943.issue6733@psf.upfronthosting.co.za>
Message-ID: <1250642602.2.0.807698027943.issue6733@psf.upfronthosting.co.za>
New submission from fugounashi <fugounashi+python at gmail.com>:
when printing a full width unicode character near the end of a line when
only a single (half-width) space remains, the character is printed at
the start of the current line rather than the start of the next line.
the following character is printed in the following space on the next
line as it should be. same behaviour in both mlterm and xterm
thanks!
python deb 2.5.2-3
----------
messages: 91721
nosy: fugounashi
severity: normal
status: open
title: curses line wrap broken when mixing full- and half-width unicode characters
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6733>
_______________________________________
From report at bugs.python.org Wed Aug 19 15:18:00 2009
From: report at bugs.python.org (Eric)
Date: Wed, 19 Aug 2009 13:18:00 +0000
Subject: [New-bugs-announce] [issue6734] Imap lib implicit conversion from
bytes to string
In-Reply-To: <1250687880.61.0.0161540410601.issue6734@psf.upfronthosting.co.za>
Message-ID: <1250687880.61.0.0161540410601.issue6734@psf.upfronthosting.co.za>
New submission from Eric <surprising42 at gmail.com>:
using imaplib IMAP4_SSL, would fail at login due to TypeError, implicit
conversion from bytes object to string around line 1068 involving
function "_quote".
My fix:
def _quote(self, arg):
#Could not implicitly convert to bytes object to string
arg = arg.encode('utf-8') #added this line to solve problem
arg = arg.replace(b'\\', b'\\\\')
arg = arg.replace(b'"', b'\\"')
return b'"' + arg + b'"'
----------
components: Library (Lib)
files: imaplib.py
messages: 91729
nosy: surprising42
severity: normal
status: open
title: Imap lib implicit conversion from bytes to string
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file14743/imaplib.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6734>
_______________________________________
From report at bugs.python.org Wed Aug 19 20:59:18 2009
From: report at bugs.python.org (dontbugme)
Date: Wed, 19 Aug 2009 18:59:18 +0000
Subject: [New-bugs-announce] [issue6735] restype pointer to Structure
subclass never initialized
In-Reply-To: <1250708358.54.0.249958641719.issue6735@psf.upfronthosting.co.za>
Message-ID: <1250708358.54.0.249958641719.issue6735@psf.upfronthosting.co.za>
New submission from dontbugme <pythonbugsbugmenot at spamavert.com>:
So, say I'm sub-classing ctypes.Structure with a class: MyClass.
I define __init__() in MyClass..
If I explicitly instantiate MyClass(), then the __init__() is properly
executed as expected.
But say I have a CFUNCTYPE where I set it's restype member to a POINTER
to MyClass.. A python MyClass object is obviously instantiated at one
point in time, but it's __init__ is never called. Seems odd to me?
----------
assignee: theller
components: ctypes
messages: 91736
nosy: dontbugme, theller
severity: normal
status: open
title: restype pointer to Structure subclass never initialized
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6735>
_______________________________________
From report at bugs.python.org Thu Aug 20 00:27:58 2009
From: report at bugs.python.org (Salebona)
Date: Wed, 19 Aug 2009 22:27:58 +0000
Subject: [New-bugs-announce] [issue6736] File handling in Python
In-Reply-To: <1250720878.56.0.299301851986.issue6736@psf.upfronthosting.co.za>
Message-ID: <1250720878.56.0.299301851986.issue6736@psf.upfronthosting.co.za>
New submission from Salebona <sallas07 at gmail.com>:
How can I make read a text file from a normal text editor lik
emicrosoft word or word pad?
----------
components: Windows
messages: 91751
nosy: SallaS07
severity: normal
status: open
title: File handling in Python
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6736>
_______________________________________
From report at bugs.python.org Thu Aug 20 00:29:15 2009
From: report at bugs.python.org (Christopher Egner)
Date: Wed, 19 Aug 2009 22:29:15 +0000
Subject: [New-bugs-announce] [issue6737] PEP 372 odict.__eq__ behaves
incorrectly
In-Reply-To: <1250720955.06.0.955952600398.issue6737@psf.upfronthosting.co.za>
Message-ID: <1250720955.06.0.955952600398.issue6737@psf.upfronthosting.co.za>
New submission from Christopher Egner <cegner at yahoo-inc.com>:
The current definition for odict.__eq__ is
def __eq__(self, other):
if isinstance(other, OrderedDict):
return all(p==q for p, q in _zip_longest(self.items(),
other.items()))
return dict.__eq__(self, other)
The current behavior of NotImplemented is:
>>> if( NotImplemented ):
... print 'foo'
foo
>>> dict.__eq__( {}, None )
NotImplemented
>>> if ( dict.__eq__( {}, None ) ):
... print 'oops'
oops
The surprising behavior is:
>>> if ( OrderedDict() != None ):
... print 'okie'
... else:
... print 'gah!'
gah!
As best I understand it, normally other (in this case None) would be
given the chance to evaluate other.__eq__( OrderedDict() ), but this
doesn't seem to be happening.
----------
components: None
messages: 91752
nosy: cegner
severity: normal
status: open
title: PEP 372 odict.__eq__ behaves incorrectly
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6737>
_______________________________________
From report at bugs.python.org Thu Aug 20 09:32:12 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Thu, 20 Aug 2009 07:32:12 +0000
Subject: [New-bugs-announce] [issue6738] Wrong doc strings in itertools
In-Reply-To: <1250753532.16.0.563820931893.issue6738@psf.upfronthosting.co.za>
Message-ID: <1250753532.16.0.563820931893.issue6738@psf.upfronthosting.co.za>
New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:
The doc strings of itertools.combinations and
itertools.combinations_with_replacement are wrong: The parameter "r" is
not optional here (like it is for itertools.permutations).
Attached trivial patch.
----------
components: Library (Lib)
files: docstring.patch
keywords: patch
messages: 91761
nosy: hagen
severity: normal
status: open
title: Wrong doc strings in itertools
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14746/docstring.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6738>
_______________________________________
From report at bugs.python.org Thu Aug 20 10:31:20 2009
From: report at bugs.python.org (CaribbeanCruise)
Date: Thu, 20 Aug 2009 08:31:20 +0000
Subject: [New-bugs-announce] [issue6739] IDLE window won't start or show up
after assgining new key in options v2.5.2 and 3.1.1
In-Reply-To: <1250757080.7.0.965993936336.issue6739@psf.upfronthosting.co.za>
Message-ID: <1250757080.7.0.965993936336.issue6739@psf.upfronthosting.co.za>
New submission from CaribbeanCruise <caribbeancruise123 at gmail.com>:
I tried to assign a new key(lctrl+lshift instead of lctrl+F5) for run-
mode in option in v.2.5.2. I tried the new key and it didn't work. And
then I got lots of messages.
So I killed the IDLE and the rest of python. And run IDLE again,
background process indicates some activity for 5secs. And then it was
gone. No IDLE window showed up.
So I uninstalled the 2.5.2. and installed the v.3.1.1. The installation
process went ok, but when I starts IDLE. Nothing happens.
I tried and run idle.py in cmd, while I'm a vista user and got this:
Traceback (most recent call last):
File "C:\Python31\Lib\idlelib\idle.py", line 11, in <module>
idlelib.PyShell.main()
File "C:\Python31\Lib\idlelib\PyShell.py", line 1388, in main
shell = flist.open_shell()
File "C:\Python31\Lib\idlelib\PyShell.py", line 277, in open_shell
self.pyshell = PyShell(self)
File "C:\Python31\Lib\idlelib\PyShell.py", line 813, in __init__
OutputWindow.__init__(self, flist, None, None)
File "C:\Python31\Lib\idlelib\OutputWindow.py", line 16, in __init__
EditorWindow.__init__(self, *args)
File "C:\Python31\Lib\idlelib\EditorWindow.py", line 135, in __init__
self.apply_bindings()
File "C:\Python31\Lib\idlelib\EditorWindow.py", line 961, in
apply_bindings
text.event_add(event, *keylist)
File "C:\Python31\Lib\idlelib\MultiCall.py", line 359, in event_add
widget.event_add(self, virtual, seq)
File "C:\Python31\Lib\tkinter\__init__.py", line 1353, in event_add
self.tk.call(args)
_tkinter.TclError: bad event type or keysym "Shift"
What do I do to get this up and running?
----------
components: IDLE
messages: 91762
nosy: CaribbeanCruise
severity: normal
status: open
title: IDLE window won't start or show up after assgining new key in options v2.5.2 and 3.1.1
type: performance
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6739>
_______________________________________
From report at bugs.python.org Thu Aug 20 12:27:17 2009
From: report at bugs.python.org (Michal Vyskocil)
Date: Thu, 20 Aug 2009 10:27:17 +0000
Subject: [New-bugs-announce] [issue6740] Compounded expressions with lambda
functions are evaluated incorrectly
In-Reply-To: <1250764037.64.0.603658762072.issue6740@psf.upfronthosting.co.za>
Message-ID: <1250764037.64.0.603658762072.issue6740@psf.upfronthosting.co.za>
New submission from Michal Vyskocil <mvyskocil at suse.cz>:
The compounded expressions with lambda functions are evaluated
incorrectly. The simple expressions, or a named functions are evaluated
good. The problem is only in the evaluation of compounded expressions.
It seems that after evaluate of the first lambda function the
evaluation of whole expression is stopped and not continue (see
cond_error, which may raises the exception during evaluation).
Python 3.1 (r31:73572, Aug 15 2009, 22:04:19)
[GCC 4.4.1 [gcc-4_4-branch revision 149935]] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> cond = (lambda x : x == 'foo') or (lambda x : x == 'bar')
>>> cond('foo')
True
>>> cond('bar')
False
>>> c1 = lambda x : x == 'foo'
>>> c1('foo')
True
>>> c2 = lambda x : x == 'bar'
>>> c2('bar')
True
>>> def ham(x): return x == 'foo'
...
>>> def spam(x): return x == 'bar'
...
>>> cond2 = lambda x : ham(x) or spam(x)
>>> cond2('foo')
True
>>> cond2('bar')
True
>>> cond2('ham')
False
>>> cond_error = (lambda x : x == 'foo') or (lambda x : y == 'bar')
>>> cond_error('d')
False
BTW: the same problem exists in Python 2.6.2
Python 2.6.2 (r262:71600, Aug 15 2009, 18:37:04)
[GCC 4.4.1 [gcc-4_4-branch revision 149935]] on linux2
Type "help", "copyright", "credits" or "license" for more information.
----------
messages: 91766
nosy: mvyskocil
severity: normal
status: open
title: Compounded expressions with lambda functions are evaluated incorrectly
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6740>
_______________________________________
From report at bugs.python.org Thu Aug 20 14:38:32 2009
From: report at bugs.python.org (Lev)
Date: Thu, 20 Aug 2009 12:38:32 +0000
Subject: [New-bugs-announce] [issue6741] Garbage collector release method
In-Reply-To: <1250771912.15.0.32080385055.issue6741@psf.upfronthosting.co.za>
Message-ID: <1250771912.15.0.32080385055.issue6741@psf.upfronthosting.co.za>
New submission from Lev <lgardster at gmail.com>:
WinCRT debug detects several memory leaks after calling py_Initialize
(); py_Finalize(); functions. Most of them are garbage collector
visible python's objects. I suggest to create "release" method in
garbage collector which will distruct all objects in GC list without
reference count checking, and call this method at the end of py_Finalize
() function. I think, that it will help to avoid memory leaks after
calling py_Finalize() function.
----------
components: Interpreter Core
messages: 91772
nosy: gardster
severity: normal
status: open
title: Garbage collector release method
type: feature request
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6741>
_______________________________________
From report at bugs.python.org Thu Aug 20 15:32:02 2009
From: report at bugs.python.org (damahay123)
Date: Thu, 20 Aug 2009 13:32:02 +0000
Subject: [New-bugs-announce] [issue6742] Embedding python into shared
library crash on AIX
In-Reply-To: <1250775122.87.0.638132535261.issue6742@psf.upfronthosting.co.za>
Message-ID: <1250775122.87.0.638132535261.issue6742@psf.upfronthosting.co.za>
New submission from damahay123 <hong.zhu at algorithmics.com>:
Hi there,
I'm trying to embedding my python code into a .so on AIX and load it
with my main application. Since there is no libpython2.6.so available on
AIX, I have to link my .so with libpython2.6.a. I have to make some
twist to make it compile. And so far so good until I run my main. My
embedding python .so give me error like the following
Fatal Python error: Interpreter not initialized (version mismatch?)
I check the initialization status by calling Py_IsInitialized and it
said yes. So I'm wondering if this embedding python into .so ever work
on AIX.
I have no problem to do the same thing on linux, solaris since python
has libpython2.6.so on both system. But our system needs the supoort on
AIX. My embedding python is very simple like the following
#include <Python.h>
#include <iostream>
extern "C"
void allocate()
{
std::cout << " am i ok = " << Py_IsInitialized() << std::endl;
Py_InitializeEx(0);
std::cout << " am i ok 1 = " << Py_IsInitialized() << std::endl;
PyRun_SimpleString("from time import time, datetime, ctime\n"
"print 'Today is',ctime(time())\n");
Py_Finalize();
}
my main application is also very simple
#include <iostream>
#include <iomanip>
#include <dlfcn.h>
//#include <link.h>
#include <Python.h>
typedef void (*ALLOCATE)();
int main (int argc, char ** argv)
{
// parse params to load shared object
if (argc < 2)
{
std::cerr << "Usage: " << argv[0] << " sharedObject(s)" << std::endl;
return 0;
}
// Py_Initialize();
for (int i = 1; i < argc; ++i)
{
void * handle = ::dlopen(argv[i], RTLD_LAZY);
if (!handle)
{
std::cerr << dlerror() << argv[i] << std::endl;
return 0;
}
// Use that handle to locate the symbol. The symbol must be
// demangled so it has to be compiled with extern "C".
ALLOCATE dlmAllocate = (ALLOCATE) ::dlsym(handle, "allocate");
if (!dlmAllocate)
{
std::cerr << dlerror() << std::endl;
return 0;
}
dlmAllocate();
}
return 0;
}
here is my makefile
CXX := g++
default: DLOpenTest mypython.so
DLOpenTest: DLOpen.C
$(CXX) -o DLOpenTest DLOpen.C -ldl
-Wl,-bE:/mnts/cdstools/Python-2.6.2/aix-ppc-5.3/lib/python2.6/config/python.exp
-lld -I/mnts/cdstools/Python-2.6.2/aix-ppc-5.3/include/python2.6
-L/mnts/cdstools/Python-2.6.2/aix-ppc-5.3/lib/ -lpython2.6 -lpthread
mypython.so: mypython.C
$(CXX) -shared -nostartfiles
-I/mnts/cdstools/Python-2.6.2/aix-ppc-5.3/include/python2.6
-L/mnts/cdstools/Python-2.6.2/aix-ppc-5.3/lib/ -lpython2.6 -lpthread -o
mypython.so mypython.C
clean:
rm *.o DLOpenTest mypython.so
Can someone help me out? Or has anyone even tried same thing on AIX?
NOTE, the issue is not like issue 4434 or 1332869. Please don't reply
this issue with those two number. I've seen them already. It's not helpful
Thanks a log
----------
components: Interpreter Core
messages: 91773
nosy: damahay123
severity: normal
status: open
title: Embedding python into shared library crash on AIX
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6742>
_______________________________________
From report at bugs.python.org Thu Aug 20 16:21:06 2009
From: report at bugs.python.org (Mary Stern)
Date: Thu, 20 Aug 2009 14:21:06 +0000
Subject: [New-bugs-announce] [issue6743] pprint.pprint should support no
objects to print blank lines & allow args
In-Reply-To: <1250778066.89.0.880851114314.issue6743@psf.upfronthosting.co.za>
Message-ID: <1250778066.89.0.880851114314.issue6743@psf.upfronthosting.co.za>
New submission from Mary Stern <marystern at yahoo.com>:
Using print in python 3 I would like to simple "replace" print with
pprint.pprint. However pprint cannot be called with no arguments, so
this cannot currently be done (the error is "TypeError: pprint() takes
at least 1 positional argument (0 given)").
A simple improvement is to allow no object to be passed in and pprint
would then print a newline rather than fail.
Another problem is that if you try this:
print('hello', True)
and replace print with print, the second arg gets interpreted as the
"stream" parameter.
Both of the above can be fixed (I think) by changing pprint.py as follows:
instead of the current code:
def pprint(object, stream=None, indent=1, width=80, depth=None):
change to this:
def pprint(object='\n', *args, stream=None, indent=1, width=80, depth=None)
----------
messages: 91774
nosy: marystern
severity: normal
status: open
title: pprint.pprint should support no objects to print blank lines & allow args
type: feature request
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6743>
_______________________________________
From report at bugs.python.org Thu Aug 20 22:41:29 2009
From: report at bugs.python.org (Jessica McKellar)
Date: Thu, 20 Aug 2009 20:41:29 +0000
Subject: [New-bugs-announce] [issue6744] calling kevent repr raises a
TypeError
In-Reply-To: <1250800889.41.0.974799993123.issue6744@psf.upfronthosting.co.za>
Message-ID: <1250800889.41.0.974799993123.issue6744@psf.upfronthosting.co.za>
New submission from Jessica McKellar <jessica.mckellar at gmail.com>:
kqueue_event_repr uses PyBytes_FromString when every other repr uses
PyUnicode_FromString, and this gets you a "TypeError: __repr__ returned
non-string (type bytes)". The patch swaps in PyUnicode_FromString and
adds a very simple unittest to test_kqueue.
----------
components: Extension Modules
files: kqueue-event-repr.patch
keywords: patch
messages: 91782
nosy: jesstess
severity: normal
status: open
title: calling kevent repr raises a TypeError
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14749/kqueue-event-repr.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6744>
_______________________________________
From report at bugs.python.org Thu Aug 20 23:54:53 2009
From: report at bugs.python.org (Trundle)
Date: Thu, 20 Aug 2009 21:54:53 +0000
Subject: [New-bugs-announce] [issue6745] (curses) addstr() takes str in
Python 3
In-Reply-To: <1250805293.93.0.390407784339.issue6745@psf.upfronthosting.co.za>
Message-ID: <1250805293.93.0.390407784339.issue6745@psf.upfronthosting.co.za>
New submission from Trundle <andy-python at hammerhartes.de>:
In Python 3, curses requires a str for addstr() where I think it should
take bytes instead. Otherwise it is impossible to output anything other
than ASCII (which is even more or less stated on top of curses'
documentation).
See the attached script "umlaut2x.py" for Python 2.6: Outputting
umlauts works fine, both in single-byte and multi-byte environments.
The attached script "umlaut3x.py" is the same script translated to
Python 3. Note that the output here always seems to be utf-8, which is
plain wrong.
A quick test where I changed addstr() to take bytes instead of str
confirmed that outputting other characters than ASCII would work then
in Python 3, too. There are perhaps more places where the types are
wrong. If someone confirms this issue and it is desired, I could
provide a patch.
----------
components: Library (Lib)
files: umlaut2x.py
messages: 91786
nosy: Trundle
severity: normal
status: open
title: (curses) addstr() takes str in Python 3
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file14750/umlaut2x.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6745>
_______________________________________
From report at bugs.python.org Fri Aug 21 01:05:00 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 20 Aug 2009 23:05:00 +0000
Subject: [New-bugs-announce] [issue6746] ValueError raised by IDLE during
tooltip open on 64-bit Centos 5.3
In-Reply-To: <1250809500.9.0.805893080789.issue6746@psf.upfronthosting.co.za>
Message-ID: <1250809500.9.0.805893080789.issue6746@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
Linux (Centos 5.3) 32-bit with Python 2.5.4
1. Start an idle session.
2. enter "help(" at the prompt
The open bracket triggers a traceback in the console:
Exception in Tkinter callback
Traceback (most recent call last):
File "/home/qatest/APyE/lib/python2.5/lib-tk/Tkinter.py", line 1414,
in
__call__
return self.func(*args)
File "/home/qatest/APyE/lib/python2.5/idlelib/MultiCall.py", line
151, in
handler
r = l[i](event)
File "/home/qatest/APyE/lib/python2.5/idlelib/CallTips.py", line 55,
in
try_open_calltip_event
self.open_calltip(False)
File "/home/qatest/APyE/lib/python2.5/idlelib/CallTips.py", line 79,
in
open_calltip
self.calltip.showtip(arg_text, sur_paren[0], sur_paren[1])
File "/home/qatest/APyE/lib/python2.5/idlelib/CallTipWindow.py", line
66, in
showtip
self.position_window()
File "/home/qatest/APyE/lib/python2.5/idlelib/CallTipWindow.py", line
35, in
position_window
self.parencol))
File "/home/qatest/APyE/lib/python2.5/lib-tk/Tkinter.py", line 2857,
in bbox
self.tk.call((self._w, 'bbox') + args)) or None
File "/home/qatest/APyE/lib/python2.5/lib-tk/Tkinter.py", line 1030,
in
_getints
return tuple(map(getint, self.tk.splitlist(string)))
ValueError: invalid literal for int() with base 10: '(71,'
Upon closing the bracket, another exception is thrown:
Exception in Tkinter callback
Traceback (most recent call last):
File "/home/qatest/APy/lib/python2.5/lib-tk/Tkinter.py", line 1414,
in __call__
return self.func(*args)
File "/home/qatest/APy/lib/python2.5/idlelib/MultiCall.py", line 151,
in handler
r = l[i](event)
File "/home/qatest/APy/lib/python2.5/idlelib/CallTips.py", line 55,
in try_open_calltip_event
self.open_calltip(False)
File "/home/qatest/APy/lib/python2.5/idlelib/CallTips.py", line 65,
in open_calltip
self._remove_calltip_window()
File "/home/qatest/APy/lib/python2.5/idlelib/CallTips.py", line 41,
in _remove_calltip_window
self.calltip.hidetip()
File "/home/qatest/APy/lib/python2.5/idlelib/CallTipWindow.py", line
126, in hidetip
self.label.destroy()
AttributeError: 'NoneType' object has no attribute 'destroy'
Exception in Tkinter callback
Traceback (most recent call last):
File "/home/qatest/APy/lib/python2.5/lib-tk/Tkinter.py", line 1414,
in __call__
return self.func(*args)
File "/home/qatest/APy/lib/python2.5/idlelib/MultiCall.py", line 151,
in handler
r = l[i](event)
File "/home/qatest/APy/lib/python2.5/idlelib/CallTips.py", line 62,
in refresh_calltip_event
self.open_calltip(False)
File "/home/qatest/APy/lib/python2.5/idlelib/CallTips.py", line 65,
in open_calltip
self._remove_calltip_window()
File "/home/qatest/APy/lib/python2.5/idlelib/CallTips.py", line 41,
in _remove_calltip_window
self.calltip.hidetip()
File "/home/qatest/APy/lib/python2.5/idlelib/CallTipWindow.py", line
126, in hidetip
self.label.destroy()
AttributeError: 'NoneType' object has no attribute 'destroy'
Tix version = 8.4.3
Tcl/Tk version = 8.5.7
This happens only on 64-bit (not 32-bit).
----------
components: IDLE
messages: 91793
nosy: srid
severity: normal
status: open
title: ValueError raised by IDLE during tooltip open on 64-bit Centos 5.3
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6746>
_______________________________________
From report at bugs.python.org Fri Aug 21 02:09:46 2009
From: report at bugs.python.org (Thomas Kowaliczek)
Date: Fri, 21 Aug 2009 00:09:46 +0000
Subject: [New-bugs-announce] [issue6747] test test_multiprocessing failed
In-Reply-To: <1250813386.91.0.61030699326.issue6747@psf.upfronthosting.co.za>
Message-ID: <1250813386.91.0.61030699326.issue6747@psf.upfronthosting.co.za>
New submission from Thomas Kowaliczek <linuxdonald at linuxdonald.de>:
test test_multiprocessing failed -- Traceback (most recent call last):
File
"/home/LinuxDonald/Downloads/Python-3.1.1/Lib/test/test_multiprocessing.py",
line 1077, in test_number_of_objects
self.assertEqual(refs, EXPECTED_NUMBER)
AssertionError: 4 != 1
----------
components: Tests
messages: 91797
nosy: LinuxDonald
severity: normal
status: open
title: test test_multiprocessing failed
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6747>
_______________________________________
From report at bugs.python.org Fri Aug 21 02:10:35 2009
From: report at bugs.python.org (Thomas Kowaliczek)
Date: Fri, 21 Aug 2009 00:10:35 +0000
Subject: [New-bugs-announce] [issue6748] test test_telnetlib failed
In-Reply-To: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
Message-ID: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
New submission from Thomas Kowaliczek <linuxdonald at linuxdonald.de>:
test test_telnetlib failed -- Traceback (most recent call last):
File
"/home/LinuxDonald/Downloads/Python-3.1.1/Lib/test/test_telnetlib.py",
line 409, in test_debuglevel
self._test_debuglevel([a, EOF_sigil], b)
File
"/home/LinuxDonald/Downloads/Python-3.1.1/Lib/test/test_telnetlib.py",
line 389, in _test_debuglevel
txt = telnet.read_all()
File "/home/LinuxDonald/Downloads/Python-3.1.1/Lib/telnetlib.py", line
325, in read_all
self.fill_rawq()
File "/home/LinuxDonald/Downloads/Python-3.1.1/Lib/telnetlib.py", line
516, in fill_rawq
buf = self.sock.recv(50)
socket.error: [Errno 104] Connection reset by peer
----------
components: Tests
messages: 91798
nosy: LinuxDonald
severity: normal
status: open
title: test test_telnetlib failed
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6748>
_______________________________________
From report at bugs.python.org Fri Aug 21 06:51:43 2009
From: report at bugs.python.org (Peter Manis)
Date: Fri, 21 Aug 2009 04:51:43 +0000
Subject: [New-bugs-announce] [issue6749] Support for encrypted zipfiles when
interpreting zipfile as script
In-Reply-To: <1250830303.29.0.377270089004.issue6749@psf.upfronthosting.co.za>
Message-ID: <1250830303.29.0.377270089004.issue6749@psf.upfronthosting.co.za>
New submission from Peter Manis <peter.manis at gmail.com>:
The zipfile support in 2.6 that allows you pass a zipfile(with __main__.py
inside) as the "script", does not support encrypted zipfiles. I view this
as being a feature that could be useful to some.
----------
components: Library (Lib)
messages: 91800
nosy: manis
severity: normal
status: open
title: Support for encrypted zipfiles when interpreting zipfile as script
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6749>
_______________________________________
From report at bugs.python.org Fri Aug 21 09:28:29 2009
From: report at bugs.python.org (Jackson Yang)
Date: Fri, 21 Aug 2009 07:28:29 +0000
Subject: [New-bugs-announce] [issue6750] threading issue in
__builtins__.print
In-Reply-To: <1250839709.71.0.595068140402.issue6750@psf.upfronthosting.co.za>
Message-ID: <1250839709.71.0.595068140402.issue6750@psf.upfronthosting.co.za>
New submission from Jackson Yang <jackson.yang at augmentum.com>:
# Bug Description
In a multi-threaded environment, the Win32 Python3000 built-in function
"print" may give the output several times.
# How to Reproduce:
import threading
event = threading.Event()
class Test(threading.Thread):
def __init__(self, ord):
super().__init__()
self.ord = ord
def run(self):
event.wait()
print('Hello, world!', self.ord)
threads = tuple(map(Test, range(8)))
tuple(map(lambda thread: thread.start(), threads))
event.set()
tuple(map(lambda thread: thread.join(), threads))
# EOF
# Problem Observed
[The first run, 0 is doubled]
Hello, world! 0
Hello, world! 0
Hello, world! 1
Hello, world! 2
Hello, world! 3
Hello, world! 4
Hello, world! 5
Hello, world! 6
Hello, world! 7
[the second run, 1 and 7 are doubled]
Hello, world! 1
Hello, world! 1
Hello, world! 2
Hello, world! 3
Hello, world! 4
Hello, world! 5
Hello, world! 6
Hello, world! 7
Hello, world! 7
Hello, world! 0
# Expected Result
Each thread gives ONE AND ONLY ONE output.
OR
State this as The Expected Behavior, document it and ask the user to
write something such as critical section.
----------
components: IO
messages: 91807
nosy: nullnil
severity: normal
status: open
title: threading issue in __builtins__.print
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6750>
_______________________________________
From report at bugs.python.org Fri Aug 21 10:57:57 2009
From: report at bugs.python.org (Juan Javier)
Date: Fri, 21 Aug 2009 08:57:57 +0000
Subject: [New-bugs-announce] [issue6751] Default return value in ConfigParser
In-Reply-To: <1250845077.86.0.224640008074.issue6751@psf.upfronthosting.co.za>
Message-ID: <1250845077.86.0.224640008074.issue6751@psf.upfronthosting.co.za>
New submission from Juan Javier <jjdominguezm at yahoo.com>:
I think it is useful, at least for me, to add an argument, default, to
[Safe,Raw]ConfigParser.get that, if present, will be returned if the
methid fails to return the value.
That is, instead of rasing an exception, return default, if present.
It could be done overriding the get method in SafeConfigParser,
something like this:
class SafeConfigParser(ConfigParser):
def get(self, section, option, raw=False, vars=None, **kwds):
try:
return super().get(section, option, raw, vars)
except Exception as exc:
if "default" in kwds:
return kwds["default"]
raise exc
----------
components: Library (Lib)
messages: 91808
nosy: jjdominguezm
severity: normal
status: open
title: Default return value in ConfigParser
type: feature request
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6751>
_______________________________________
From report at bugs.python.org Fri Aug 21 10:58:57 2009
From: report at bugs.python.org (rahul)
Date: Fri, 21 Aug 2009 08:58:57 +0000
Subject: [New-bugs-announce] [issue6752] -1**2=-1
In-Reply-To: <1250845137.04.0.311672819223.issue6752@psf.upfronthosting.co.za>
Message-ID: <1250845137.04.0.311672819223.issue6752@psf.upfronthosting.co.za>
New submission from rahul <rahulalone1618 at gmail.com>:
what is the reason for this ????
----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 91809
nosy: rahul1618
severity: normal
status: open
title: -1**2=-1
type: compile error
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6752>
_______________________________________
From report at bugs.python.org Fri Aug 21 12:11:11 2009
From: report at bugs.python.org (Guillaume Delcourt-Petetin)
Date: Fri, 21 Aug 2009 10:11:11 +0000
Subject: [New-bugs-announce] [issue6753] Python 3.1.1 test_cmd_line fails on
Fedora 11
In-Reply-To: <1250849471.77.0.183054552926.issue6753@psf.upfronthosting.co.za>
Message-ID: <1250849471.77.0.183054552926.issue6753@psf.upfronthosting.co.za>
New submission from Guillaume Delcourt-Petetin <gpetetin at gmail.com>:
Just what it says on the label :
[...]
Traceback (most recent call last):
File "./Lib/test/regrtest.py", line 618, in runtest_inner
indirect_test()
File
"/home/Pif/T?l?chargement/Python-3.1.1/Python-3.1.1/Lib/test/test_cmd_l
test.support.run_unittest(CmdLineTest)
File
"/home/Pif/T?l?chargement/Python-3.1.1/Python-3.1.1/Lib/test/support.py
_run_suite(suite)
File
"/home/Pif/T?l?chargement/Python-3.1.1/Python-3.1.1/Lib/test/support.py
raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
File
"/home/Pif/T?l?chargement/Python-3.1.1/Python-3.1.1/Lib/test/test_cmd_l
self.assertTrue(path1.encode('ascii') in stdout)
AssertionError: False is not True
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "./Lib/test/regrtest.py", line 1222, in <module>
main()
File "./Lib/test/regrtest.py", line 425, in main
testdir, huntrleaks)
File "./Lib/test/regrtest.py", line 584, in runtest
testdir, huntrleaks)
File "./Lib/test/regrtest.py", line 638, in runtest_inner
print("test", test, "failed --", msg)
UnicodeEncodeError: 'ascii' codec can't encode character '\xe9' in
position 54: ordinal not in range(128)
test test_cmd_line failed -- make: *** [test] Erreur 1
[...]
In my search for similar bugs, I only found a mac OSX/Python 3.0 issue
(http://bugs.python.org/issue4388)
----------
components: Tests
messages: 91813
nosy: Pif
severity: normal
status: open
title: Python 3.1.1 test_cmd_line fails on Fedora 11
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6753>
_______________________________________
From report at bugs.python.org Fri Aug 21 12:53:16 2009
From: report at bugs.python.org (KAJIYAMA, Tamito)
Date: Fri, 21 Aug 2009 10:53:16 +0000
Subject: [New-bugs-announce] [issue6754] Non-existent member
'nb_inplace_divide' in PyNumberMethods
In-Reply-To: <1250851996.63.0.670347243231.issue6754@psf.upfronthosting.co.za>
Message-ID: <1250851996.63.0.670347243231.issue6754@psf.upfronthosting.co.za>
New submission from KAJIYAMA, Tamito <rd6t-kjym at asahi-net.or.jp>:
In the "Python/C API Reference Manual", Section "Object Implementation
Support", Subsection "Number Object Structures"
(http://docs.python.org/3.1/c-api/typeobj.html#number-object-
structures), the definition of the PyNumberMethods structure has a non-
existent member 'nb_inplace_divide'. This should be simply omitted.
----------
assignee: georg.brandl
components: Documentation
messages: 91814
nosy: georg.brandl, kajiyama
severity: normal
status: open
title: Non-existent member 'nb_inplace_divide' in PyNumberMethods
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6754>
_______________________________________
From report at bugs.python.org Fri Aug 21 13:43:32 2009
From: report at bugs.python.org (=?utf-8?q?I=C3=B1igo_Serna?=)
Date: Fri, 21 Aug 2009 11:43:32 +0000
Subject: [New-bugs-announce] [issue6755] Patch: new method get_wch for
ncurses bindings: accept wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
New submission from I?igo Serna <inigoserna at gmail.com>:
Currently,there is no a simple way in curses bindings to get the code
associated with a key press of non ascii keystroke (f.e. ?) in terminals
configured with UTF-8 encoding.
getch returns the code for a wide character byte a byte.
But ncurses library has a proper function to do it: get_wch.
Patch against Python v2.6.2 to provide this missing get_wch method
in the ncurses bindings.
Include a test example and a patch to the documentation as well.
More info and a partial solution without patching python curses module
on this thread:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/67dce30f0a2742a6?fwc=2
----------
components: Extension Modules
messages: 91816
nosy: inigoserna
severity: normal
status: open
title: Patch: new method get_wch for ncurses bindings: accept wide characters (unicode)
type: feature request
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________
From report at bugs.python.org Fri Aug 21 14:17:01 2009
From: report at bugs.python.org (Tarjei Huse)
Date: Fri, 21 Aug 2009 12:17:01 +0000
Subject: [New-bugs-announce] [issue6756] ftplib documentation does not
document what the acct parameter is used for
Message-ID: <1250857021.21.0.232003333024.issue6756@psf.upfronthosting.co.za>
Changes by Tarjei Huse <tarjei at scanmine.com>:
----------
assignee: georg.brandl
components: Documentation
nosy: georg.brandl, tarjei
severity: normal
status: open
title: ftplib documentation does not document what the acct parameter is used for
type: feature request
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6756>
_______________________________________
From report at bugs.python.org Fri Aug 21 17:48:55 2009
From: report at bugs.python.org (Demur Rumed)
Date: Fri, 21 Aug 2009 15:48:55 +0000
Subject: [New-bugs-announce] [issue6757] Marshal's documentation incomplete
In-Reply-To: <1250869735.91.0.499827102331.issue6757@psf.upfronthosting.co.za>
Message-ID: <1250869735.91.0.499827102331.issue6757@psf.upfronthosting.co.za>
New submission from Demur Rumed <junkmute at hotmail.com>:
"The following types are supported: None, integers, floating point
numbers, strings, bytes, bytearrays, tuples, lists, sets, dictionaries,
and code objects"
It fails to list bools: True and False
While it states "Not all Python object types are supported; in general,
only objects whose value is independent from a particular invocation of
Python can be written and read by this module." beforehand, it seems
proper to include bools in the list of accepted types
----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 91831
nosy: georg.brandl, serprex
severity: normal
status: open
title: Marshal's documentation incomplete
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6757>
_______________________________________
From report at bugs.python.org Fri Aug 21 20:49:37 2009
From: report at bugs.python.org (Travis H.)
Date: Fri, 21 Aug 2009 18:49:37 +0000
Subject: [New-bugs-announce] [issue6758] implement new setuid-related calls
and a standard way to drop all privileges
In-Reply-To: <1250880577.62.0.941118593261.issue6758@psf.upfronthosting.co.za>
Message-ID: <1250880577.62.0.941118593261.issue6758@psf.upfronthosting.co.za>
New submission from Travis H. <travis+w-python.org at subspacefield.org>:
It should be easier to write network servers and setuid programs in
python. One of the troublesome issues is that the semantics of the
setuid/getuid-related calls are quite complicated.
There are two papers on this subject that form the background of this
feature request:
http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf
http://www.cs.berkeley.edu/~daw/papers/setuid-login08b.pdf
In general, then, the end goal is a safe (portable, secure) way to drop
privileges either temporarily or permanently.
Wagner et. al. have proposed a decent interface, but it's unclear to me
where it should be implemented.
Furthermore, it makes use of the getresuid/setresuid calls (among many
others), which don't appear from their manpages to be standardized by
POSIX, but are available in most modern Unix OSes. So this leaves me
with two questions; have these functions been standardized, and if not,
where should they be implemented?
I'm willing to do the coding, but need some guidance on where to put the
code.
----------
messages: 91835
nosy: solinym
severity: normal
status: open
title: implement new setuid-related calls and a standard way to drop all privileges
type: feature request
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6758>
_______________________________________
From report at bugs.python.org Sat Aug 22 08:22:02 2009
From: report at bugs.python.org (Ryan Leslie)
Date: Sat, 22 Aug 2009 06:22:02 +0000
Subject: [New-bugs-announce] [issue6759] zipfile.ZipExtFile.read() is
missing universal newline support
In-Reply-To: <1250922122.86.0.650490470964.issue6759@psf.upfronthosting.co.za>
Message-ID: <1250922122.86.0.650490470964.issue6759@psf.upfronthosting.co.za>
New submission from Ryan Leslie <rylesny at gmail.com>:
The zipfile.ZipFile.open() behavior with mode 'U' or 'rU' is not quite
as advertised in
http://docs.python.org/library/zipfile.html#zipfile.ZipFile.open
Here is an example:
$ echo -ne "This is an example\r\nWhich demonstrates a problem\r\nwith
ZipFile.open(..., 'U')\r\n" > foo.txt
$ cat -v foo.txt
This is an example^M
Which demonstrates a problem^M
with ZipFile.open(..., 'U')^M
$ zip foo.zip foo.txt
adding: foo.txt (deflated 1%)
$ python
Python 2.6.2 (r262:71600, Aug 21 2009, 17:52:12)
[GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> open("foo.txt", 'U').read()
"This is an example\nWhich demonstrates a problem\nwith
ZipFile.open(..., 'U')\n"
>>> from zipfile import ZipFile
>>> ZipFile("foo.zip").open("foo.txt", 'U').read()
"This is an example\r\nWhich demonstrates a problem\r\nwith
ZipFile.open(..., 'U')\r\n"
>>>
The open() method was added here:
http://bugs.python.org/issue1121142
The cause is that the universal newline implementation is specific to
readline(), which also implements readlines() and next() as well.
Support was never added for read(), which is independent.
Note that test_zipfile.UniversalNewlineTests.readTest() passes. This is
suspect because it's explicitly coded to *not* expect translation of new
line sequences.
----------
components: Library (Lib)
messages: 91854
nosy: ryles
severity: normal
status: open
title: zipfile.ZipExtFile.read() is missing universal newline support
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6759>
_______________________________________
From report at bugs.python.org Sat Aug 22 12:40:33 2009
From: report at bugs.python.org (Chris Rebert)
Date: Sat, 22 Aug 2009 10:40:33 +0000
Subject: [New-bugs-announce] [issue6760] patch to subprocess docs to better
explain Popen's 'args' argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
New submission from Chris Rebert <pybugs at rebertia.com>:
>From what I've seen on several c.l.p threads, some people have a tough
time figuring the correct 'args' argument to subprocess.Popen's
constructor. In an effort to cut down on such discussions in the future,
I've written the attached docs patch to better explain the subject.
I'm not an rst/Sphinx guru and thus was unable to actually test the
patch, so there might be some (hopefully minor) formatting errors.
----------
assignee: georg.brandl
components: Documentation
files: subprocess.rst.patch
keywords: patch
messages: 91859
nosy: cvrebert, georg.brandl
severity: normal
status: open
title: patch to subprocess docs to better explain Popen's 'args' argument
versions: Python 2.6
Added file: http://bugs.python.org/file14770/subprocess.rst.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6760>
_______________________________________
From report at bugs.python.org Sat Aug 22 19:13:59 2009
From: report at bugs.python.org (Stephen Fairchild)
Date: Sat, 22 Aug 2009 17:13:59 +0000
Subject: [New-bugs-announce] [issue6761] Class calling
In-Reply-To: <1250961239.16.0.126736964049.issue6761@psf.upfronthosting.co.za>
Message-ID: <1250961239.16.0.126736964049.issue6761@psf.upfronthosting.co.za>
New submission from Stephen Fairchild <signupaddress at bethere.co.uk>:
From:
http://docs.python.org/reference/datamodel.html#the-standard-type-hierarchy
"Class instances
Class instances are described below. Class instances are callable
only when the class has a __call__() method; x(arguments) is a shorthand
for x.__call__(arguments)."
The following program demonstrates otherwise regarding that last statement.
def call(self):
print "inserted __call__ in object of class A"
class A(object):
def __call__(self):
print "__call__ method in class A"
x = A() # Equates: x = type(A).__call__(A)
x.__call__ = call
x() # Calls the method of class A.
x.__call__(x) # Calls function "call".
type(x).__call__(x) # The correct longhand of x() IMHO
If I were to rephrase the documentation:
"Class instances
Class instances are described below. Class instances are callable
only when the class has a __call__() method; x(arguments) is a shorthand
for type(x).__call__(x, arguments)."
----------
assignee: georg.brandl
components: Documentation
messages: 91864
nosy: georg.brandl, onlyme
severity: normal
status: open
title: Class calling
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6761>
_______________________________________
From report at bugs.python.org Sat Aug 22 21:12:20 2009
From: report at bugs.python.org (Mintaka)
Date: Sat, 22 Aug 2009 19:12:20 +0000
Subject: [New-bugs-announce] [issue6762] strange string representation of
xrange in print
In-Reply-To: <1250968340.58.0.478477907223.issue6762@psf.upfronthosting.co.za>
Message-ID: <1250968340.58.0.478477907223.issue6762@psf.upfronthosting.co.za>
New submission from Mintaka <mintaka at post.cz>:
String representation of xrange return keyword with value.
foo = xrange(5)
print foo
>>> xrange(5)
foo.__str__()
>>> xrange(5)
I think, that expected result should be somethink like this:
>>> <xrange object at 0x00AFB970>
----------
components: Interpreter Core
messages: 91871
nosy: mintaka
severity: normal
status: open
title: strange string representation of xrange in print
versions: Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6762>
_______________________________________
From report at bugs.python.org Sat Aug 22 23:26:36 2009
From: report at bugs.python.org (Leonardo Santagada)
Date: Sat, 22 Aug 2009 21:26:36 +0000
Subject: [New-bugs-announce] [issue6763] Crash on mac os x leopard in
mimetypes.guess_type (or PyObject_Malloc)
In-Reply-To: <1250976396.98.0.596987057251.issue6763@psf.upfronthosting.co.za>
Message-ID: <1250976396.98.0.596987057251.issue6763@psf.upfronthosting.co.za>
New submission from Leonardo Santagada <santagada at gmail.com>:
Python 2.6.2 (and the maint branch if using old mimetypes.py) crash
(with a bus error) on mac os x (10.5.7 & 10.5.8) with the file I posted.
The problem appears to be in the allocation of memory by the GC.
What I do is I call mimetypes.guess_type in more than one thread at the
same time, then I guess what is happening is this:
1. The first thread to run notices mimetypes.inited is false so it call
its init funtion.
2. Somehow the first thread loses the gil while still executing the init
3. Another thread tries to execute guess_type as it is already inited it
calls itself, in vain as the init still hasn't exchanged it value for
the new function so it goes into recursion
4. Somehow the allocator fails during the recursion
here is the final pieces of my stack trace (its a very long sequence of
recursions into guess_type):
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0xb0000ffc
[Switching to process 61544 thread 0x117]
0x96912122 in szone_malloc ()
#0 0x96912122 in szone_malloc ()
#1 0x969120d8 in malloc_zone_malloc ()
#2 0x9691206c in malloc ()
#3 0x0006f32c in PyObject_Malloc (nbytes=376) at Objects/obmalloc.c:913
913 return (void *)malloc(nbytes);
#4 0x0006fe61 in _PyObject_DebugMalloc (nbytes=360) at
Objects/obmalloc.c:1347
1347 p = (uchar *)PyObject_Malloc(total);
#5 0x00149b13 in _PyObject_GC_Malloc (basicsize=344) at
Modules/gcmodule.c:1351
1351 g = (PyGC_Head *)PyObject_MALLOC(
#6 0x00149c24 in _PyObject_GC_NewVar (tp=0x193500, nitems=5) at
Modules/gcmodule.c:1383
1383 PyVarObject *op = (PyVarObject *) _PyObject_GC_Malloc(size);
#7 0x00048a06 in PyFrame_New (tstate=0x33df30, code=0x473148,
globals=0x48e380, locals=0x0) at Objects/frameobject.c:642
642 f = PyObject_GC_NewVar(PyFrameObject,
&PyFrame_Type,
#8 0x00100816 in PyEval_EvalCodeEx (co=0x473148, globals=0x48e380,
locals=0x0, args=0x374fb4, argcount=2, kws=0x374fbc, kwcount=0,
defs=0x4a6f9c, defcount=1, closure=0x0) at Python/ceval.c:2755
2755 f = PyFrame_New(tstate, co, globals, locals);
----------
components: Interpreter Core
messages: 91876
nosy: santagada
severity: normal
status: open
title: Crash on mac os x leopard in mimetypes.guess_type (or PyObject_Malloc)
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6763>
_______________________________________
From report at bugs.python.org Sat Aug 22 23:58:20 2009
From: report at bugs.python.org (Michael Foord)
Date: Sat, 22 Aug 2009 21:58:20 +0000
Subject: [New-bugs-announce] [issue6764] os.path.join should call
os.path.normpath on result
In-Reply-To: <1250978300.82.0.388700146975.issue6764@psf.upfronthosting.co.za>
Message-ID: <1250978300.82.0.388700146975.issue6764@psf.upfronthosting.co.za>
New submission from Michael Foord <michael at voidspace.org.uk>:
os.path.join has very basic behavior in the handling of '..'
>>> import os
>>> os.path.join('/foo', '..')
'/foo/..'
For some usecases (comparing paths for example) this is not useful and
you have to manually call normpath on the results:
>>> os.path.normpath(os.path.join('/foo', '..'))
'/'
Because of this code gets littered with annoyingly long chained calls
which are a pain to both read and write.
Is there any problem with join always calling normpath on it's result?
----------
components: Library (Lib)
keywords: easy
messages: 91877
nosy: michael.foord
severity: normal
status: open
title: os.path.join should call os.path.normpath on result
type: behavior
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6764>
_______________________________________
From report at bugs.python.org Sun Aug 23 13:56:17 2009
From: report at bugs.python.org (steve21)
Date: Sun, 23 Aug 2009 11:56:17 +0000
Subject: [New-bugs-announce] [issue6765] math.log, log10 inconsistency
In-Reply-To: <1251028577.65.0.346592203273.issue6765@psf.upfronthosting.co.za>
Message-ID: <1251028577.65.0.346592203273.issue6765@psf.upfronthosting.co.za>
New submission from steve21 <steve872929-bv at yahoo.com.au>:
$ python3.1
Python 3.1 (r31:73572, Jul 6 2009, 21:21:12)
[GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> math.log10(1000)
3.0
>>> math.log(1000, 10)
2.9999999999999996
You would expect the results to be the same.
Internally math.log() could call math.log10() when base==10. That would
ensure they are consistent.
----------
components: Library (Lib)
messages: 91886
nosy: steve21
severity: normal
status: open
title: math.log, log10 inconsistency
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6765>
_______________________________________
From report at bugs.python.org Sun Aug 23 19:46:30 2009
From: report at bugs.python.org (Carlos)
Date: Sun, 23 Aug 2009 17:46:30 +0000
Subject: [New-bugs-announce] [issue6766] Cannot modify dictionaries inside
dictionaries using Managers from multiprocessing
In-Reply-To: <1251049590.58.0.809281249474.issue6766@psf.upfronthosting.co.za>
Message-ID: <1251049590.58.0.809281249474.issue6766@psf.upfronthosting.co.za>
New submission from Carlos <carlosdf at gmail.com>:
It's not possible to modify a dict inside a dict using a manager from
multiprocessing.
Ex:
from multiprocessing import Process,Manager
def f(d):
d['1'] = '1'
d['2']['1'] = 'Try To Write'
if __name__ == '__main__':
manager = Manager()
d = manager.dict()
d['2'] = manager.dict()
print d
p = Process(target=f, args=(d,))
p.start()
p.join()
print d
d['2'] = 5
print d
The output Under Windows 7 (32 Bits) / Python 2.6.2 (32 Bits) is:
{'2': {}}
{'1': '1', '2': {}}
{'1': '1', '2': 5}
The output is the same if you change "d['2'] = manager.dict()" to
"d['2'] = dict()"
----------
messages: 91889
nosy: carlosdf
severity: normal
status: open
title: Cannot modify dictionaries inside dictionaries using Managers from multiprocessing
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6766>
_______________________________________
From report at bugs.python.org Sun Aug 23 21:18:04 2009
From: report at bugs.python.org (Joe)
Date: Sun, 23 Aug 2009 19:18:04 +0000
Subject: [New-bugs-announce] [issue6767] Python as zip package
In-Reply-To: <1251055084.86.0.380611427173.issue6767@psf.upfronthosting.co.za>
Message-ID: <1251055084.86.0.380611427173.issue6767@psf.upfronthosting.co.za>
New submission from Joe <us3r07 at web.de>:
It would be nice, if you could offer the Windows version also as a zi
package, besides the msi installer.
----------
components: Windows
messages: 91890
nosy: Joe
severity: normal
status: open
title: Python as zip package
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6767>
_______________________________________
From report at bugs.python.org Sun Aug 23 23:02:35 2009
From: report at bugs.python.org (Daniel Keysers)
Date: Sun, 23 Aug 2009 21:02:35 +0000
Subject: [New-bugs-announce] [issue6768] asyncore file_wrapper leaking file
descriptors?
In-Reply-To: <1251061355.88.0.439878311774.issue6768@psf.upfronthosting.co.za>
Message-ID: <1251061355.88.0.439878311774.issue6768@psf.upfronthosting.co.za>
New submission from Daniel Keysers <dkeysers at gmail.com>:
I'm not very experienced in Python, but while tracking down an issue
with a "too many open files" error I think I found a missing resource
release in asyncore's file_wrapper. Since Rev. 64062 added the os.dup()
in __init__ this class reads as follows:
if os.name == 'posix':
import fcntl
class file_wrapper:
# Here we override just enough to make a file
# look like a socket for the purposes of asyncore.
# The passed fd is automatically os.dup()'d
def __init__(self, fd):
self.fd = os.dup(fd)
def recv(self, *args):
return os.read(self.fd, *args)
def send(self, *args):
return os.write(self.fd, *args)
read = recv
write = send
def close(self):
os.close(self.fd)
def fileno(self):
return self.fd
I think that a "def __del__(self): self.close()" or a variant thereof
would solve the problem I was seeing since it would release the file
descriptor acquired in __init__ by os.dup(). But since I don't know why
the os.dup() was added in the first place I'm not sure if there aren't
any arguments against this release. Any comment appreciated!
----------
components: Library (Lib)
messages: 91892
nosy: keysers
severity: normal
status: open
title: asyncore file_wrapper leaking file descriptors?
type: resource usage
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6768>
_______________________________________
From report at bugs.python.org Mon Aug 24 00:20:13 2009
From: report at bugs.python.org (ivank)
Date: Sun, 23 Aug 2009 22:20:13 +0000
Subject: [New-bugs-announce] [issue6769] in xmlrpclib.py: NameError: global
name 'HTTPSConnection' is not defined
In-Reply-To: <1251066013.49.0.537044412879.issue6769@psf.upfronthosting.co.za>
Message-ID: <1251066013.49.0.537044412879.issue6769@psf.upfronthosting.co.za>
New submission from ivank <ivan at ludios.org>:
Line 1491 of xmlrpclib.py should be
self._connection = host, httplib.HTTPSConnection(chost, None, **(x509 or
{}))
instead of
self._connection = host, HTTPSConnection(chost, None, **(x509 or {}))
File
"/opt/Python-latest/lib/python2.7/site-packages/bzrlib/plugins/launchpad/lp_registration.py",
line 166, in send_request
result = method(*method_params)
File "/opt/Python-latest/lib/python2.7/xmlrpclib.py", line 1224, in
__call__
return self.__send(self.__name, args)
File "/opt/Python-latest/lib/python2.7/xmlrpclib.py", line 1570, in
__request
verbose=self.__verbose
File "/opt/Python-latest/lib/python2.7/xmlrpclib.py", line 1264, in
request
return self.single_request(host, handler, request_body, verbose)
File "/opt/Python-latest/lib/python2.7/xmlrpclib.py", line 1284, in
single_request
h = self.make_connection(host)
File "/opt/Python-latest/lib/python2.7/xmlrpclib.py", line 1491, in
make_connection
self._connection = host, HTTPSConnection(chost, None, **(x509 or {}))
NameError: global name 'HTTPSConnection' is not defined
bzr 1.15 on python 2.7a0 (linux2)
I think this has been broken for around two weeks, maybe more. I don't
know if this is broken in 3.x.
----------
components: Library (Lib)
messages: 91895
nosy: ivank
severity: normal
status: open
title: in xmlrpclib.py: NameError: global name 'HTTPSConnection' is not defined
type: crash
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6769>
_______________________________________
From report at bugs.python.org Mon Aug 24 03:18:43 2009
From: report at bugs.python.org (Radiant)
Date: Mon, 24 Aug 2009 01:18:43 +0000
Subject: [New-bugs-announce] [issue6770] PDF download links of docs for
3.1.1 are broken
In-Reply-To: <1251076723.7.0.569922214039.issue6770@psf.upfronthosting.co.za>
Message-ID: <1251076723.7.0.569922214039.issue6770@psf.upfronthosting.co.za>
New submission from Radiant <newyorkdude999 at yahoo.com>:
At this time I cannot download any of the PDF documentation files for
Python 3.1.1 because I get the "Not Found" error for all four of them.
I'm referring to the files linked at
http://docs.python.org/3.1/download.html
----------
assignee: georg.brandl
components: Documentation
messages: 91898
nosy: Radiant, georg.brandl
severity: normal
status: open
title: PDF download links of docs for 3.1.1 are broken
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6770>
_______________________________________
From report at bugs.python.org Mon Aug 24 09:33:56 2009
From: report at bugs.python.org (steve21)
Date: Mon, 24 Aug 2009 07:33:56 +0000
Subject: [New-bugs-announce] [issue6771] documentation/implementation error
In-Reply-To: <1251099236.05.0.0799674766136.issue6771@psf.upfronthosting.co.za>
Message-ID: <1251099236.05.0.0799674766136.issue6771@psf.upfronthosting.co.za>
New submission from steve21 <steve872929-bv at yahoo.com.au>:
The documentation and implementation disagree.
Documentation:
"Module curses.wrapper
Convenience function to ensure proper terminal setup and resetting
on application entry and exit.
...
15.10. curses.wrapper ? Terminal handler for curses programs
This module supplies one function, wrapper() ...
curses.wrapper.wrapper(func, ...)
Wrapper function that initializes curses ..
"
Implementation:
$ python3.1
Python 3.1.1 (r311:74480, Aug 24 2009, 14:50:57)
[GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import curses.wrapper as cw
>>> cw.wrapper
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'function' object has no attribute 'wrapper'
The 'curses.wrapper.wrapper' function no longer exists.
The 'curses.wrapper' module no longer exists, the module is now a function.
The problem is the line
from curses.wrapper import wrapper
in curses/__init__.py - curses has clobbered its own namespace and made
the curses.wrapper module inaccessible.
Instead of this tortuous sequence of module hiding and namespace
clobbering it would be simpler to just place the curses.wrapper.wrapper
function in curses/__init__.py and do away with the need for the
curses.wrapper single-function-module.
And update the docs so:
references to the curses.wrapper module are removed
the function curses.wrapper.wrapper(func, ...) becomes
curses.wrapper.(func, ...)
----------
components: Library (Lib)
messages: 91903
nosy: steve21
severity: normal
status: open
title: documentation/implementation error
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6771>
_______________________________________
From report at bugs.python.org Mon Aug 24 09:40:39 2009
From: report at bugs.python.org (Mintaka)
Date: Mon, 24 Aug 2009 07:40:39 +0000
Subject: [New-bugs-announce] [issue6772] Missing alias utf-8 in Standard
Encodings list.
In-Reply-To: <1251099639.65.0.386311489493.issue6772@psf.upfronthosting.co.za>
Message-ID: <1251099639.65.0.386311489493.issue6772@psf.upfronthosting.co.za>
New submission from Mintaka <mintaka at post.cz>:
On page
http://docs.python.org/dev/3.0/library/codecs.html#standard-encodings
(and on the pages for older versions too)
in the table with review, is missing higly used alias "utf-8"
On that row is only:
Codec Aliases Languages
utf_8 U8, UTF, utf8 all languages
And probably there should be:
utf_8 U8, UTF, utf8, utf-8 all languages
----------
assignee: georg.brandl
components: Documentation
messages: 91904
nosy: georg.brandl, mintaka
severity: normal
status: open
title: Missing alias utf-8 in Standard Encodings list.
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6772>
_______________________________________
From report at bugs.python.org Mon Aug 24 10:36:05 2009
From: report at bugs.python.org (Piotr Foltyn)
Date: Mon, 24 Aug 2009 08:36:05 +0000
Subject: [New-bugs-announce] [issue6773] subprocess issue on Win 7 x64
In-Reply-To: <1251102965.83.0.35212908562.issue6773@psf.upfronthosting.co.za>
Message-ID: <1251102965.83.0.35212908562.issue6773@psf.upfronthosting.co.za>
New submission from Piotr Foltyn <piotr.foltyn at displaylink.com>:
The sample code presented below produces error (screenshot available in
attachment) on Windows 7 RC x64 with latest version of Python 2.6
installed. Both 32bit and 64bit versions of Python 2.6 are affected by
this issue. Python 3 executes this code flawlessly.
The problem seems to be related to stdout redirection. If the "stdout =
PIPE" is omitted in the first statement of main() function, code
executes properly but we don't have access to the processes output. If
the line "Popen(["dir"], stdout = PIPE, shell = True)" is changed to
"sin, sout = os.popen2(["dir"])" and os module is imported everything
works fine. It doesn't matter what command is executed ("dir", "bcedit",
"mspaint" etc)
import sys
from subprocess import Popen, PIPE
from multiprocessing import Process
def myProcess():
Popen(["dir"], shell = True) # ERROR :(
def main():
Popen(["dir"], stdout = PIPE, shell = True)
Process(target = myProcess).start()
return 0
if __name__ == "__main__":
sys.exit(main())
----------
components: Library (Lib), Windows
files: Win7RCx64.jpg
messages: 91910
nosy: tesla
severity: normal
status: open
title: subprocess issue on Win 7 x64
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14777/Win7RCx64.jpg
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6773>
_______________________________________
From report at bugs.python.org Mon Aug 24 10:45:21 2009
From: report at bugs.python.org (Nicolas Dumazet)
Date: Mon, 24 Aug 2009 08:45:21 +0000
Subject: [New-bugs-announce] [issue6774] socket.shudown documentation: on
some platforms, closing one half closes the other half
In-Reply-To: <1251103521.34.0.917057608479.issue6774@psf.upfronthosting.co.za>
Message-ID: <1251103521.34.0.917057608479.issue6774@psf.upfronthosting.co.za>
New submission from Nicolas Dumazet <nicdumz at gmail.com>:
I had a bad time understanding what happens in Mac OS X after a shutdown
call: after calling shutdown(SH_WR) on side A, a corresponding
shutdown(SH_RD) on side B would raise a socket.error: socket is not
connected.
It is quite surprising when you are used to sockets in Linux, which
expect you to shut one end, and then the other one.
It turns out that under Mac OS X, a shutdown call closes the connection
on the other half. And the only mention I could find of this behavior
was here, r68611 :
http://svn.python.org/view/python/trunk/Lib/test/test_socket.py?r1=64125&r2=68611&pathrev=68611
I think that the documentation should specify that (surprising)
behavior: I attached a patch explaining that detail.
Thanks!
----------
assignee: georg.brandl
components: Documentation
files: socketshutdown.patch
keywords: patch
messages: 91912
nosy: georg.brandl, nicdumz
severity: normal
status: open
title: socket.shudown documentation: on some platforms, closing one half closes the other half
type: behavior
Added file: http://bugs.python.org/file14778/socketshutdown.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6774>
_______________________________________
From report at bugs.python.org Mon Aug 24 11:02:18 2009
From: report at bugs.python.org (Nicolas Dumazet)
Date: Mon, 24 Aug 2009 09:02:18 +0000
Subject: [New-bugs-announce] [issue6775] readme: correct
python.org/community/lists url
In-Reply-To: <1251104538.03.0.409360254575.issue6775@psf.upfronthosting.co.za>
Message-ID: <1251104538.03.0.409360254575.issue6775@psf.upfronthosting.co.za>
New submission from Nicolas Dumazet <nicdumz at gmail.com>:
README shows http://www.python.org/community/lists.html as an URL for
mailing list details, but it should be
http://www.python.org/community/lists/
Attaching a patch.
----------
assignee: georg.brandl
components: Documentation
files: readme-url-mls.patch
keywords: patch
messages: 91913
nosy: georg.brandl, nicdumz
severity: normal
status: open
title: readme: correct python.org/community/lists url
Added file: http://bugs.python.org/file14779/readme-url-mls.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6775>
_______________________________________
From report at bugs.python.org Mon Aug 24 17:13:45 2009
From: report at bugs.python.org (Nicolas Dumazet)
Date: Mon, 24 Aug 2009 15:13:45 +0000
Subject: [New-bugs-announce] [issue6776] A few tests are failing when zlib
is not supported
In-Reply-To: <1251126825.28.0.687144384207.issue6776@psf.upfronthosting.co.za>
Message-ID: <1251126825.28.0.687144384207.issue6776@psf.upfronthosting.co.za>
New submission from Nicolas Dumazet <nicdumz at gmail.com>:
test_distutils, test_zipfile, test_gzip and test_zimport are not
completely safe when zlib module is not available.
I've uploaded a patch on Rietveld which solves the issue here:
http://codereview.appspot.com/111041
Those are my first steps with Rietveld, please let me know if I can
improve something :)
Thanks,
Nicolas.
----------
components: Tests
messages: 91923
nosy: nicdumz
severity: normal
status: open
title: A few tests are failing when zlib is not supported
type: behavior
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6776>
_______________________________________
From report at bugs.python.org Mon Aug 24 21:50:34 2009
From: report at bugs.python.org (Christoph Zwerschke)
Date: Mon, 24 Aug 2009 19:50:34 +0000
Subject: [New-bugs-announce] [issue6777] Python 2.6 tutorial still
recommends using Exception.message attribute
In-Reply-To: <1251143434.18.0.260436581702.issue6777@psf.upfronthosting.co.za>
Message-ID: <1251143434.18.0.260436581702.issue6777@psf.upfronthosting.co.za>
New submission from Christoph Zwerschke <cito at online.de>:
The Python 2.6.2 tutorial says at the end of secton 8.3
(http://docs.python.org/tutorial/errors.html#handling-exceptions):
"But use of .args is discouraged. Instead, the preferred use is to pass
a single argument to an exception (which can be a tuple if multiple
arguments are needed) and have it bound to the message attribute."
It seems this is not true any more, the idea has been retracted so that
it's now the other way around again: .args can still be used,
but .message is deprecated (see http://www.python.org/dev/peps/pep-
0352/#retracted-ideas).
The examples classes in section 8.5 of the Tutorial, using the .message
attribute should be also adapted because they raise a
DeprecationWarning in Python 2.6.2.
----------
assignee: georg.brandl
components: Documentation
messages: 91937
nosy: cito, georg.brandl
severity: normal
status: open
title: Python 2.6 tutorial still recommends using Exception.message attribute
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6777>
_______________________________________
From report at bugs.python.org Mon Aug 24 22:59:18 2009
From: report at bugs.python.org (kaashif)
Date: Mon, 24 Aug 2009 20:59:18 +0000
Subject: [New-bugs-announce] [issue6778] False positives given through
bisect module (binary search)
In-Reply-To: <1251147558.19.0.488929549089.issue6778@psf.upfronthosting.co.za>
Message-ID: <1251147558.19.0.488929549089.issue6778@psf.upfronthosting.co.za>
New submission from kaashif <musharraf.azeem at gmail.com>:
I tried Python's bisect module on a large word list (words.txt contained
in http://www.greenteapress.com/thinkpython/swampy/swampy.1.1.zip)
If I search for something like 'musefully', 'museful' will come up as a
match. Maybe that's a feature... but seems to me like a bug.
Too much optimization going on here it seems, to such an extent that
false positives are given.
Here's the code I tried:
import bisect
fin = open('words.txt')
t = []
for line in fin:
t.append(line.strip())
print(bisect.bisect(t,'musefully'))
----------
components: Extension Modules
files: words.txt
messages: 91940
nosy: kaashif
severity: normal
status: open
title: False positives given through bisect module (binary search)
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file14780/words.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6778>
_______________________________________
From report at bugs.python.org Mon Aug 24 23:25:11 2009
From: report at bugs.python.org (Samuel Quiring)
Date: Mon, 24 Aug 2009 21:25:11 +0000
Subject: [New-bugs-announce] [issue6779] NotImplementedError on for statement
In-Reply-To: <1251149111.84.0.211191712144.issue6779@psf.upfronthosting.co.za>
Message-ID: <1251149111.84.0.211191712144.issue6779@psf.upfronthosting.co.za>
New submission from Samuel Quiring <sam.quiring at windriver.com>:
I have the following for statement:
lenc = len(children)
for ic in range(lenc):
print "ic: ", ic
child = children[ic]
print " -", ic, child.__class__.__name__
print "XXX"
except:
try:
exctype, value = sys.exc_info()[:2]
print "exception", exctype, value
traceback.print_exc()
print range(lenc)
except:
print "exception X"
print "loop done"
When I execute it, I get the following output:
- count changed, old: -1 new: 4
ic: 0
- 0 XGRect
XXX
ic: 1
- 1 PanelEntry
XXX
ic: 2
- 2 ScrollView
XXX
ic: 3
- 3 CloseButton
XXX
exception <type 'exceptions.NotImplementedError'> method not implemented
Traceback (most recent call last):
File "/home/stpuser/prizm/lib/python2.6/libprizm/pui/atspi.py", line
187, in _get_n_children
for ic in range(lenc):
NotImplementedError: method not implemented
[0, 1, 2, 3]
loop done
Why am I getting the NotImplementedError exception? This looks like a
bug to me (I am pretty new to Python).
----------
components: None
messages: 91941
nosy: sbq
severity: normal
status: open
title: NotImplementedError on for statement
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6779>
_______________________________________
From report at bugs.python.org Mon Aug 24 23:33:13 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 24 Aug 2009 21:33:13 +0000
Subject: [New-bugs-announce] [issue6780] startswith error message is
incomplete
In-Reply-To: <1251149593.57.0.654081758843.issue6780@psf.upfronthosting.co.za>
Message-ID: <1251149593.57.0.654081758843.issue6780@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
The `startswith` method accepts both string and tuple (not list). Yet
the error message suggests that it expects (only) a character buffer
object.
In Python-2.6:
>>> "foo".startswith(['fo', 'df'])
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: expected a character buffer object
In Python-3.x, the error message is different:
>>> "foo".startswith(["fo"])
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: Can't convert 'list' object to str implicitly
Aside: why not try to convert 'list' object to tuple?
----------
components: Library (Lib)
messages: 91942
nosy: srid
severity: normal
status: open
title: startswith error message is incomplete
type: behavior
versions: Python 2.6, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6780>
_______________________________________
From report at bugs.python.org Tue Aug 25 14:29:25 2009
From: report at bugs.python.org (benlbroussard)
Date: Tue, 25 Aug 2009 12:29:25 +0000
Subject: [New-bugs-announce] [issue6781] even exponentiation of negative
numbers
In-Reply-To: <1251203365.27.0.467156127603.issue6781@psf.upfronthosting.co.za>
Message-ID: <1251203365.27.0.467156127603.issue6781@psf.upfronthosting.co.za>
New submission from benlbroussard <benlbroussard at gmail.com>:
Negative one squared should be one, but is negative one sometimes.
pow(-1, 2) = 1
-1 ** 2 = -1
-1 ^ 2 = -1
The ** and ^ operators aren't working like expected, and the pow()
documentation is incorrect since it says "The two-argument form pow(x,
y) is equivalent to using the power operator: x**y."
----------
components: None
messages: 91951
nosy: benlbroussard
severity: normal
status: open
title: even exponentiation of negative numbers
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6781>
_______________________________________
From report at bugs.python.org Tue Aug 25 17:29:11 2009
From: report at bugs.python.org (victor)
Date: Tue, 25 Aug 2009 15:29:11 +0000
Subject: [New-bugs-announce] [issue6782] Scoping of variables in closures
In-Reply-To: <1251214151.84.0.540608749633.issue6782@psf.upfronthosting.co.za>
Message-ID: <1251214151.84.0.540608749633.issue6782@psf.upfronthosting.co.za>
New submission from victor <bitto001 at uwp.edu>:
I can't tell if this is "feature" or a "bug" but either way this
behavior struck me as strange.
"""
def func():
x = 5
def inc():
temp = x + 1 # when inc() is execute, this line fails
x = temp
return x
return inc
i = func()
i() # will raise error
"""
It says that x referenced before defined (when computing x + 1). It
seems that the fact that x is assigned in the local inc() that it
shadows the outer x.
Even stranger is that if you remove the the assignment of "x = temp"
there is no error; suggesting the assignment to x anywhere in the inner
function shadows the entire function.
This is not the expected behavior, so I thought it may be bug.
----------
components: Interpreter Core
messages: 91954
nosy: bitfort
severity: normal
status: open
title: Scoping of variables in closures
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6782>
_______________________________________
From report at bugs.python.org Tue Aug 25 21:35:41 2009
From: report at bugs.python.org (Yuv Gre)
Date: Tue, 25 Aug 2009 19:35:41 +0000
Subject: [New-bugs-announce] [issue6783] Add a builtin method to 'int' for
base/radix conversion
In-Reply-To: <1251228941.52.0.551451692653.issue6783@psf.upfronthosting.co.za>
Message-ID: <1251228941.52.0.551451692653.issue6783@psf.upfronthosting.co.za>
New submission from Yuv Gre <ubershmekel at gmail.com>:
In javascript and java each number has a toString method which allows
for easy string representation in different bases. If the function int(x[, base]) exists as a builtin, the inverse should at least be
somewhere in the standard library. Personally I believe a "to_string"
method would work but would defeat "There should be one way to do it".
Perhaps a method called "radix" or "base_convert" which requires a base
to convert parameter won't take the place of str(number).
Here are a few possible implementations:
http://code.activestate.com/recipes/222109/
http://code.activestate.com/recipes/111286/
http://pastebin.com/f54dd69d6
----------
components: Interpreter Core, Library (Lib)
messages: 91958
nosy: ubershmekel
severity: normal
status: open
title: Add a builtin method to 'int' for base/radix conversion
type: feature request
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6783>
_______________________________________
From report at bugs.python.org Wed Aug 26 13:56:13 2009
From: report at bugs.python.org (RonnyPfannschmidt)
Date: Wed, 26 Aug 2009 11:56:13 +0000
Subject: [New-bugs-announce] [issue6784] bytw/unicode string
incompatibilities between python2 and and python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
New submission from RonnyPfannschmidt <Ronny.Pfannschmidt at gmx.de>:
i just noticed that there are some slight differences of the
bytestring/unicodestring pickles between python2/3 using the protocols
0, 1 and 2
the first things i noticed are:
a str from python2 is unpickled as unicode in python3
(fails for byte strings that don't fit whats expected for unicode)
a bytes instance from python3 is pickled as custom class in protocols <3
i'll write a script to try all combinations of protocols and string
variations and transfer directions
----------
components: None
messages: 91966
nosy: RonnyPfannschmidt
severity: normal
status: open
title: bytw/unicode string incompatibilities between python2 and and python3
type: behavior
versions: Python 2.6, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________
From report at bugs.python.org Wed Aug 26 15:51:33 2009
From: report at bugs.python.org (Evan)
Date: Wed, 26 Aug 2009 13:51:33 +0000
Subject: [New-bugs-announce] [issue6785] IncompleteRead / BadStatus when
parsing http://peakoil.mobi
In-Reply-To: <1251294693.63.0.748199046509.issue6785@psf.upfronthosting.co.za>
Message-ID: <1251294693.63.0.748199046509.issue6785@psf.upfronthosting.co.za>
New submission from Evan <evanphelan at gmail.com>:
(I'm brand new to Python.org, apologies in advance if this has been
recorded elsewhere or is not a bug)
I've a simple script which fetching a url using httplib/urllib2 and then
simply searches the HTML for a string. Works on every URL I've tried
apart from the url http://peakoil.mobi where, for some reason, I get the
following:
Traceback (most recent call last):
File "C:\Python26\lib\threading.py", line 524, in __bootstrap_inner
self.run()
File "test.py", line 59, in run
html = response.read()
File "C:\Python26\lib\socket.py", line 327, in read
data = self._sock.recv(rbufsize)
File "C:\Python26\lib\httplib.py", line 518, in read
return self._read_chunked(amt)
File "C:\Python26\lib\httplib.py", line 564, in _read_chunked
raise IncompleteRead(value)
IncompleteRead: <html><head>
<title></title></head>
<!-- Redirection Services ASH01WRED02 H1 -->
<frameset rows='100%, *' frameborder=no framespacing=0 border=0>
<frame src="http://peakoil.com/modules.php?name=AvantGo" name=mainwindow
framebo
rder=no framespacing=0 marginheight=0 marginwidth=0></frame>
</frameset>
<noframes>
<h2>Your browser does not support frames. We recommend upgrading your
browser.<
/h2><br><br>
<center>Click <a
href="http://peakoil.com/modules.php?name=AvantGo">here</a> to
enter the site.</center>
</noframes></html>
Exception in thread 1:
Traceback (most recent call last):
File "C:\Python26\lib\threading.py", line 524, in __bootstrap_inner
self.run()
File "test.py", line 51, in run
response = urllib2.urlopen(req)
File "C:\Python26\lib\urllib2.py", line 124, in urlopen
return _opener.open(url, data, timeout)
File "C:\Python26\lib\urllib2.py", line 383, in open
response = self._open(req, data)
File "C:\Python26\lib\urllib2.py", line 401, in _open
'_open', req)
File "C:\Python26\lib\urllib2.py", line 361, in _call_chain
result = func(*args)
File "C:\Python26\lib\urllib2.py", line 1130, in http_open
return self.do_open(httplib.HTTPConnection, req)
File "C:\Python26\lib\urllib2.py", line 1103, in do_open
r = h.getresponse()
File "C:\Python26\lib\httplib.py", line 951, in getresponse
response.begin()
File "C:\Python26\lib\httplib.py", line 391, in begin
version, status, reason = self._read_status()
File "C:\Python26\lib\httplib.py", line 355, in _read_status
raise BadStatusLine(line)
BadStatusLine
----------
messages: 91972
nosy: kmoon
severity: normal
status: open
title: IncompleteRead / BadStatus when parsing http://peakoil.mobi
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6785>
_______________________________________
From report at bugs.python.org Wed Aug 26 20:17:36 2009
From: report at bugs.python.org (James)
Date: Wed, 26 Aug 2009 18:17:36 +0000
Subject: [New-bugs-announce] [issue6786] readline and zero based indexing
In-Reply-To: <1251310656.11.0.667090107201.issue6786@psf.upfronthosting.co.za>
Message-ID: <1251310656.11.0.667090107201.issue6786@psf.upfronthosting.co.za>
New submission from James <purpleidea at gmail.com>:
why is it that the zeroth readline history item is seemingly always
none. I would expect this to support zero-based indexing in python, but
perhaps I have missed some detail in readline somewhere. Cheers,
_J
james at work:~$ python
Python 2.5.2 (r252:60911, Oct 5 2008, 19:24:49)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline
>>> readline.get_history_item(0)
>>> readline.get_history_item(0) is None
True
>>>
james at work:~$
----------
components: Extension Modules
messages: 91979
nosy: purpleidea
severity: normal
status: open
title: readline and zero based indexing
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6786>
_______________________________________
From report at bugs.python.org Thu Aug 27 03:12:30 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 27 Aug 2009 01:12:30 +0000
Subject: [New-bugs-announce] [issue6787] thread docs contain an incorrect
link in a reference to the 'exit' method
In-Reply-To: <1251335550.97.0.247554365962.issue6787@psf.upfronthosting.co.za>
Message-ID: <1251335550.97.0.247554365962.issue6787@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
In the Caveats section of the thread docs reference is made to the
'exit' method. The link generated, instead of being to the exit method
in the thread module, is to the exit 'constant' section 4.
----------
assignee: georg.brandl
components: Documentation
messages: 91992
nosy: georg.brandl, r.david.murray
priority: low
severity: normal
stage: needs patch
status: open
title: thread docs contain an incorrect link in a reference to the 'exit' method
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6787>
_______________________________________
From report at bugs.python.org Thu Aug 27 06:17:09 2009
From: report at bugs.python.org (Ryan McGuire)
Date: Thu, 27 Aug 2009 04:17:09 +0000
Subject: [New-bugs-announce] [issue6788] codecs.open on Win32 does not force
binary mode
In-Reply-To: <1251346629.44.0.734409123127.issue6788@psf.upfronthosting.co.za>
Message-ID: <1251346629.44.0.734409123127.issue6788@psf.upfronthosting.co.za>
New submission from Ryan McGuire <python.org at enigmacurry.com>:
Opening a UTF-8 encoded file with unix newlines ("\n") on Win32:
codecs.open("whatever.txt","r","utf-8").read()
replaces the newlines ("\n") with CR+LF ("\r\n").
The docs specifically say that :
"Files are always opened in binary mode, even if no binary mode was
specified. This is done to avoid data loss due to encodings using 8-bit
values. This means that no automatic conversion of '\n' is done on
reading and writing."
And yet, opening the file with an explicit binary mode resolves the
situation:
codecs.open("whatever.txt","rb","utf-8").read()
This reads the file with the original newlines unmodified.
The implementation of codecs.open and the documentation are out of sync.
----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 91995
nosy: EnigmaCurry, georg.brandl
severity: normal
status: open
title: codecs.open on Win32 does not force binary mode
type: behavior
versions: Python 2.6, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6788>
_______________________________________
From report at bugs.python.org Thu Aug 27 09:18:18 2009
From: report at bugs.python.org (Ayman)
Date: Thu, 27 Aug 2009 07:18:18 +0000
Subject: [New-bugs-announce] [issue6789] ftplib storelines does not honor
strings returned in fp.readline
In-Reply-To: <1251357498.06.0.267830127898.issue6789@psf.upfronthosting.co.za>
Message-ID: <1251357498.06.0.267830127898.issue6789@psf.upfronthosting.co.za>
New submission from Ayman <ayman.alsairafi at gmail.com>:
in ftplibs.storlines, a call is done on what should be a Text stream:
fp.readline()
This would work in pre 3.x as it returns bytes but now that readlines
returns a string, the call at lines 477 would fail:
File "C:\Python31\lib\ftplib.py", line 477, in storlines
if buf[-1] in B_CRLF: buf = buf[:-1]
TypeError: Type str doesn't support the buffer API
The readline call should then be encoded().
----------
components: Library (Lib)
messages: 91997
nosy: aymanhs
severity: normal
status: open
title: ftplib storelines does not honor strings returned in fp.readline
type: crash
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6789>
_______________________________________
From report at bugs.python.org Thu Aug 27 23:08:19 2009
From: report at bugs.python.org (Jake McGuire)
Date: Thu, 27 Aug 2009 21:08:19 +0000
Subject: [New-bugs-announce] [issue6790] httplib and array do not play
together well
In-Reply-To: <1251407299.25.0.631458654442.issue6790@psf.upfronthosting.co.za>
Message-ID: <1251407299.25.0.631458654442.issue6790@psf.upfronthosting.co.za>
New submission from Jake McGuire <jake at youtube.com>:
As of Python 2.6 you can no longer pass an array to
httplib.HTTPConnection.send.
Issue1065257 added code to httplib to attempt to determine whether a
file-like object was passed to certain methods (e.g. send), and to
stream the data if so.
The patch uses "hasattr(obj, 'read')" as a proxy for "is a file-like
object".
array.array objects have a method called "read" that is almost entirely
disanalogous to the "read" method on a file-like object.
Hilarity ensues.
----------
messages: 92015
nosy: jakemcguire
severity: normal
status: open
title: httplib and array do not play together well
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6790>
_______________________________________
From report at bugs.python.org Fri Aug 28 10:32:52 2009
From: report at bugs.python.org (sumar)
Date: Fri, 28 Aug 2009 08:32:52 +0000
Subject: [New-bugs-announce] [issue6791] httplib read status memory usage
In-Reply-To: <1251448372.35.0.316865122555.issue6791@psf.upfronthosting.co.za>
Message-ID: <1251448372.35.0.316865122555.issue6791@psf.upfronthosting.co.za>
New submission from sumar <m.sucajtys at gmail.com>:
During writing some code I discovered some behaviour of httplib. When we
connect to host, which doesn?t respond with status line, but it just
sending data, httplib may consume more and more memory, becouce when we
execute
h = httplib.HTTPConnection(?host?)
h.conect()
h.request(?GET?, ?/?)
r = h.getresponse()
httplib tries to read one line from host. If host doesn?t send new line
character (?\n?), httplib reads more and more data. On my tests httplib
could consume all of 4GB of memory and the python process was killed by
oom_killer.
The resolution is to limit maximum amount of data read on getting
response. I have performed some test:
I received 3438293 from hosts located in the network. The longest valid
response line is
HTTP/1.1 500 ( The specified Secure Sockets Layer (SSL) port is not
allowed. ISA Server is not configured to allow SSL requests from this
port. Most Web browsers use port 443 for SSL requests. )\r\n
and it has 197 characters.
In RFC2616 in section 6.1 we have:
?The first line of a Response message is the Status-Line, consisting of
the protocol version followed by a numeric status code and its
associated textual phrase, with each element separated by SP characters.
No CR or LF is allowed except in the final CRLF sequence.
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
(..)The Reason-Phrase is intended to give a short textual description of
the Status-Code.?
So limiting maximum status line length to 256 characters is a solution
of this problem. It doesn?t break compatibility withc RFC 2616.
My patch was written originally on python2.4, but I?ve tested it on
python2.6:
[ms at host python2.6]$ patch --dry-run -i /home/ms/httplib.patch
patching file httplib.py
Hunk #1 succeeded at 209 (offset 54 lines).
----------
components: Library (Lib)
files: httplib.patch
keywords: patch
messages: 92027
nosy: m.sucajtys
severity: normal
status: open
title: httplib read status memory usage
type: resource usage
versions: Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14795/httplib.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6791>
_______________________________________
From report at bugs.python.org Fri Aug 28 10:52:20 2009
From: report at bugs.python.org (erluk)
Date: Fri, 28 Aug 2009 08:52:20 +0000
Subject: [New-bugs-announce] [issue6792] Distutils-based installer does not
detect 64bit versions of Python
In-Reply-To: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>
Message-ID: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>
New submission from erluk <erluk at pargalaxy.de>:
An installer for source-only modules created using distutils
(bdist_wininst) will only detect 32bit installations of Python on 64bit
Windows machines.
Expected behaviour:
The installer lists 32bit and 64bit installations of Python on the machine.
----------
assignee: tarek
components: Distutils
messages: 92028
nosy: erluk, tarek
severity: normal
status: open
title: Distutils-based installer does not detect 64bit versions of Python
type: behavior
versions: Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6792>
_______________________________________
From report at bugs.python.org Fri Aug 28 11:59:54 2009
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 28 Aug 2009 09:59:54 +0000
Subject: [New-bugs-announce] [issue6793] decimal.py: div_nearest ==>
_div_nearest
In-Reply-To: <1251453594.44.0.819159397261.issue6793@psf.upfronthosting.co.za>
Message-ID: <1251453594.44.0.819159397261.issue6793@psf.upfronthosting.co.za>
New submission from Stefan Krah <stefan-usenet at bytereef.org>:
--- a-decimal.py 2009-08-28 11:48:45.000000000 +0200
+++ b-decimal.py 2009-08-28 11:49:47.000000000 +0200
@@ -4845,7 +4845,7 @@
log_tenpower = f*M # exact
else:
log_d = 0 # error < 2.31
- log_tenpower = div_nearest(f, 10**-p) # error < 0.5
+ log_tenpower = _div_nearest(f, 10**-p) # error < 0.5
return _div_nearest(log_tenpower+log_d, 100)
----------
components: Library (Lib)
messages: 92031
nosy: skrah
severity: normal
status: open
title: decimal.py: div_nearest ==> _div_nearest
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6793>
_______________________________________
From report at bugs.python.org Fri Aug 28 12:15:04 2009
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 28 Aug 2009 10:15:04 +0000
Subject: [New-bugs-announce] [issue6794] decimal.py: incorrect results in
NaN comparisons
In-Reply-To: <1251454504.69.0.93743560426.issue6794@psf.upfronthosting.co.za>
Message-ID: <1251454504.69.0.93743560426.issue6794@psf.upfronthosting.co.za>
New submission from Stefan Krah <stefan-usenet at bytereef.org>:
Hi,
I believe the following comparisons aren't correct:
1:
Decimal("-sNaN63450748854172416").compare_total(Decimal("-sNaN911993"))
==> Decimal('1')
Should be: Decimal('-1') (checked against decNumber)
2:
Decimal("NaN1222222222222").compare_total_mag(Decimal("-NaN999999"))
==> Decimal('-1')
Should be: Decimal('1') (checked against decNumber)
----------
components: Library (Lib)
messages: 92032
nosy: skrah
severity: normal
status: open
title: decimal.py: incorrect results in NaN comparisons
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6794>
_______________________________________
From report at bugs.python.org Fri Aug 28 12:28:27 2009
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 28 Aug 2009 10:28:27 +0000
Subject: [New-bugs-announce] [issue6795] decimal.py: minor issues &&
usability
In-Reply-To: <1251455307.6.0.293968499648.issue6795@psf.upfronthosting.co.za>
Message-ID: <1251455307.6.0.293968499648.issue6795@psf.upfronthosting.co.za>
New submission from Stefan Krah <stefan-usenet at bytereef.org>:
Hi,
a couple of minor issues:
1:
>>> c = getcontext()
>>> c.traps[InvalidOperation] = False
>>> Decimal("NaN").__int__()
Decimal('NaN')
I think the return value should be None.
2:
>>> c = getcontext()
>>> c.traps[InvalidOperation] = False
>>> Decimal("NaN").__long__()
Traceback (most recent call last):
...
RuntimeError: maximum recursion depth exceeded in cmp
3:
>>> setcontext(8)
>>> getcontext()
8
This is just a usability issue, perhaps a type check could be performed.
----------
components: Library (Lib)
messages: 92034
nosy: skrah
severity: normal
status: open
title: decimal.py: minor issues && usability
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6795>
_______________________________________
From report at bugs.python.org Fri Aug 28 20:04:53 2009
From: report at bugs.python.org (Keith Campbell)
Date: Fri, 28 Aug 2009 18:04:53 +0000
Subject: [New-bugs-announce] [issue6796] invalid print in
tkinter\test\test_ttk\test_widgets.py
In-Reply-To: <1251482693.78.0.0973789349285.issue6796@psf.upfronthosting.co.za>
Message-ID: <1251482693.78.0.0973789349285.issue6796@psf.upfronthosting.co.za>
New submission from Keith Campbell <keithc at mitre.org>:
Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit
(Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> ================================ RESTART
================================
>>>
>>> ================================ RESTART
================================
>>>
Traceback (most recent call last):
File "C:\Python31\Lib\tkinter\test\test_ttk\test_widgets.py", line 4,
in <module>
from test.support import requires, run_unittest
File "c:\spring2000\o7python\lib\test.py", line 33
print 'Main process exiting.'
^
SyntaxError: invalid syntax
----------
components: Tkinter
messages: 92040
nosy: keithc
severity: normal
status: open
title: invalid print in tkinter\test\test_ttk\test_widgets.py
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6796>
_______________________________________
From report at bugs.python.org Fri Aug 28 23:49:58 2009
From: report at bugs.python.org (Jonathan Windle)
Date: Fri, 28 Aug 2009 21:49:58 +0000
Subject: [New-bugs-announce] [issue6797] When Beginning Expression with
Lookahead Assertion I get no Matches
In-Reply-To: <1251496198.81.0.453692564995.issue6797@psf.upfronthosting.co.za>
Message-ID: <1251496198.81.0.453692564995.issue6797@psf.upfronthosting.co.za>
New submission from Jonathan Windle <jonathanwindle at gmail.com>:
Example Code:
import re
re.findall(r"(?![a-z0-9])0(?![a-z0-9])", "a0a 0 0 b0b")
The above code returns an empty list. I expect to get ['0', '0'] returned.
If I remove "(?![a-z0-9])" from the beginning of the expression string
findall returns values as expected.
----------
components: Regular Expressions
messages: 92046
nosy: jwindle
severity: normal
status: open
title: When Beginning Expression with Lookahead Assertion I get no Matches
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6797>
_______________________________________
From report at bugs.python.org Sat Aug 29 01:52:05 2009
From: report at bugs.python.org (Robert Kern)
Date: Fri, 28 Aug 2009 23:52:05 +0000
Subject: [New-bugs-announce] [issue6798] Argument for sys.settrace()
callbacks documented incorrectly
In-Reply-To: <1251503525.6.0.896923124912.issue6798@psf.upfronthosting.co.za>
Message-ID: <1251503525.6.0.896923124912.issue6798@psf.upfronthosting.co.za>
New submission from Robert Kern <robert.kern at gmail.com>:
The final 'arg' argument of the sys.settrace() callback is documented to
be None for the 'c_return' and 'c_exception' events, but it appears to
be the function object itself. Additionally, the 'return' event's
argument may be None if the 'return' event is being generated because of
an exception. These errors also exist in the Py_tracefunc documentation
in the C API. The latter error is not particularly important for the
Python API, but in the C API the argument may be a NULL pointer.
I am happy to make the corrections if someone will confirm that my
analysis is correct.
----------
assignee: georg.brandl
components: Documentation
messages: 92050
nosy: georg.brandl, robert.kern
severity: normal
status: open
title: Argument for sys.settrace() callbacks documented incorrectly
type: behavior
versions: Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6798>
_______________________________________
From report at bugs.python.org Sat Aug 29 02:10:11 2009
From: report at bugs.python.org (Paul Tarjan)
Date: Sat, 29 Aug 2009 00:10:11 +0000
Subject: [New-bugs-announce] [issue6799] mimetypes does not give cannonical
extension for guess_extension with text/plain
In-Reply-To: <1251504611.25.0.614751141151.issue6799@psf.upfronthosting.co.za>
Message-ID: <1251504611.25.0.614751141151.issue6799@psf.upfronthosting.co.za>
New submission from Paul Tarjan <python at paulisageek.com>:
>>> import mimetypes
>>> mimetypes.guess_extension("text/plain")
'.ksh'
most others are correct, it is just this one is quite wrong. I would
recommend changing it to .txt .
>>> mimetypes.guess_all_extensions("text/plain")
['.ksh', '.pl', '.c', '.bat', '.h', '.txt', '.asc', '.text', '.pot', '.brf']
----------
components: Library (Lib)
messages: 92051
nosy: ptarjan
severity: normal
status: open
title: mimetypes does not give cannonical extension for guess_extension with text/plain
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6799>
_______________________________________
From report at bugs.python.org Sat Aug 29 05:19:48 2009
From: report at bugs.python.org (Reid Kleckner)
Date: Sat, 29 Aug 2009 03:19:48 +0000
Subject: [New-bugs-announce] [issue6800] os.exec* raises "OSError: [Errno
45] Operation not supported" in a multithreaded application
In-Reply-To: <1251515988.29.0.608870203555.issue6800@psf.upfronthosting.co.za>
Message-ID: <1251515988.29.0.608870203555.issue6800@psf.upfronthosting.co.za>
New submission from Reid Kleckner <rnk at mit.edu>:
The test case is attached. On Mac OS X (and presumably FreeBSD, which
has the same behavior) when you try to exec from a process that has any
other threads in it, you get an OSError, "Operation not supported".
Here's the output on my MacBook:
Traceback (most recent call last):
File "daemon_exec.py", line 16, in <module>
main()
File "daemon_exec.py", line 13, in main
os.execl('echo', 'hello world')
File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/os.py",
line 312, in execl
execv(file, args)
OSError: [Errno 45] Operation not supported
And on my Linux box:
hello world
Here's a similar bug that OCaml had to deal with:
http://caml.inria.fr/mantis/view.php?id=4666
I think it's reasonable for Python to declare this to be a limitation of
the OS, but considering that the other thread could be a daemon thread
that the user doesn't really care about, I think it would be reasonable
for Python to kill the other threads in the process before execing.
That's what happens on Linux, anyway.
I ran into this problem while trying to add a persistent background
compilation thread to unladen swallow, and wondered if having any other
threads would trigger the same exception.
It's tempting to just write this off, but I figured it should be
documented or left open as a low priority defect.
----------
assignee: ronaldoussoren
components: Macintosh
files: daemon_exec.py
messages: 92054
nosy: rnk, ronaldoussoren
severity: normal
status: open
title: os.exec* raises "OSError: [Errno 45] Operation not supported" in a multithreaded application
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14798/daemon_exec.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6800>
_______________________________________
From report at bugs.python.org Sat Aug 29 15:31:02 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 29 Aug 2009 13:31:02 +0000
Subject: [New-bugs-announce] [issue6801] symmetric_difference_update
documentation fix
In-Reply-To: <1251552662.92.0.431748034273.issue6801@psf.upfronthosting.co.za>
Message-ID: <1251552662.92.0.431748034273.issue6801@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
the symmetric_difference_update also accepts |
----------
assignee: tarek
components: Documentation
messages: 92065
nosy: tarek
severity: normal
status: open
title: symmetric_difference_update documentation fix
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6801>
_______________________________________
From report at bugs.python.org Sat Aug 29 22:30:58 2009
From: report at bugs.python.org (Joshua Root)
Date: Sat, 29 Aug 2009 20:30:58 +0000
Subject: [New-bugs-announce] [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
New submission from Joshua Root <josh+python at root.id.au>:
Building Python 2.6.2 on Mac OS X 10.6 (final version, 10A432) fails. Full
build transcript is attached.
Other system details: Xcode 3.2, hardware is MacPro1,1
----------
assignee: ronaldoussoren
components: Build, Macintosh
files: py26-snowleopard.log
messages: 92067
nosy: jmr, ronaldoussoren
severity: normal
status: open
title: build fails on Snow Leopard
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file14801/py26-snowleopard.log
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6802>
_______________________________________
From report at bugs.python.org Sat Aug 29 22:44:00 2009
From: report at bugs.python.org (Dan Haffey)
Date: Sat, 29 Aug 2009 20:44:00 +0000
Subject: [New-bugs-announce] [issue6803] Context manager docs refer to
contextlib.contextmanager as contextlib.contextfactory
In-Reply-To: <1251578640.37.0.48672021847.issue6803@psf.upfronthosting.co.za>
Message-ID: <1251578640.37.0.48672021847.issue6803@psf.upfronthosting.co.za>
New submission from Dan Haffey <dhaffey at gmail.com>:
The documentation at
http://docs.python.org/library/stdtypes.html#context-manager-types
refers to the contextlib.contextmanager decorator as
contextlib.contextfactory.
----------
assignee: georg.brandl
components: Documentation
files: doc-stdtypes-contextmanagement.patch
keywords: patch
messages: 92068
nosy: dhaffey, georg.brandl
severity: normal
status: open
title: Context manager docs refer to contextlib.contextmanager as contextlib.contextfactory
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file14802/doc-stdtypes-contextmanagement.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6803>
_______________________________________
From report at bugs.python.org Sat Aug 29 23:44:40 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 29 Aug 2009 21:44:40 +0000
Subject: [New-bugs-announce] [issue6804] IDLE: Detect Python files even if
name doesn't end in .py
In-Reply-To: <1251582280.35.0.0143459273436.issue6804@psf.upfronthosting.co.za>
Message-ID: <1251582280.35.0.0143459273436.issue6804@psf.upfronthosting.co.za>
New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:
A Python source file name doesn't necesarily end
in .py/.pyw; on Linux, scripts usually have no
extension but are recognized by its shebang line.
Windows uses file type associations: .py files are of
type Python.File, and .pyc files are Python.NoConFile.
This patch makes IDLE recognize as a Python source
(and colorize) any file of those types, regardless of
extension.
http://permalink.gmane.org/
gmane.comp.python.general/636011
----------
components: IDLE
files: EditorWindow.diff
keywords: patch
messages: 92071
nosy: gagenellina
severity: normal
status: open
title: IDLE: Detect Python files even if name doesn't end in .py
type: feature request
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14803/EditorWindow.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6804>
_______________________________________
From report at bugs.python.org Sun Aug 30 04:35:19 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sun, 30 Aug 2009 02:35:19 +0000
Subject: [New-bugs-announce] [issue6805] Should be URL for documentation of
current release of Python 3 (without version)
In-Reply-To: <1251599719.58.0.439749940017.issue6805@psf.upfronthosting.co.za>
Message-ID: <1251599719.58.0.439749940017.issue6805@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
There should be a standard URL on the web site to reach the
documentation of the current stable release of Python 3.
http://docs.python.org leads to the documentation for Python 2.
I can get to Python 3.1 documentation, but I have to specify 3.1 in the
URL: http://docs.python.org/3.1
That means that I cannot publish material on the web or in hardcopy that
refers generically to the documentation of a particular module via URL
without specifying a version, and that version will be obsolete before
long. I don't know what the URL should be -- perhaps docs.python.org/3/
would be sufficient.
This is one level up from the current arrangement in which specifying
3.1 actually currently gives me the 3.1.1 documentation.
----------
assignee: georg.brandl
components: Documentation
messages: 92078
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Should be URL for documentation of current release of Python 3 (without version)
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6805>
_______________________________________
From report at bugs.python.org Sun Aug 30 06:35:07 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 30 Aug 2009 04:35:07 +0000
Subject: [New-bugs-announce] [issue6806] test_platform fails under Snow
Leopard
In-Reply-To: <1251606907.25.0.605162883353.issue6806@psf.upfronthosting.co.za>
Message-ID: <1251606907.25.0.605162883353.issue6806@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
test.platform fails under Snow Leopard because the golden input for the OS
version, sw_vers, reports Snow Leopard as '10.6' while
platform.mac_ver()[0] (which uses gestalt.gestalt()) return '10.6.0'.
Best solution might be to tweak the test to append a '0' when sw_vers
returns a value that is short a micro version.
----------
components: Library (Lib)
keywords: easy
messages: 92079
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: test_platform fails under Snow Leopard
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6806>
_______________________________________
From report at bugs.python.org Sun Aug 30 12:59:16 2009
From: report at bugs.python.org (pds)
Date: Sun, 30 Aug 2009 10:59:16 +0000
Subject: [New-bugs-announce] [issue6807] No such file or directory:
'msisupport.dll' in msi.py
In-Reply-To: <1251629956.22.0.252677555531.issue6807@psf.upfronthosting.co.za>
Message-ID: <1251629956.22.0.252677555531.issue6807@psf.upfronthosting.co.za>
New submission from pds <pirdirsir at gmail.com>:
Investigating the issue #6716 I reported earlier, I've been trying to
build Windows MSI installer package of Python 3.1 on my own.
I checked out the svn source, built things with Visual C++ 2008 Express
Edition, and tried to make MSI package in Tools\msi directory.
When I run Tools\msi\msi.py in Tools\msi directory, the following error
occurs:
Traceback (most recent call last):
File "msi.py", line 178, in <module>
if msilib.pe_type(dll_path) != msilib.pe_type("msisupport.dll"):
File "E:\python31svnbuild\Tools\msi\msilib.py", line 665, in pe_type
header = open(path, "rb").read(1000)
IOError: [Errno 2] No such file or directory: 'msisupport.dll'
It seems that msilib.pe_type("msisupport.dll") is called before
msisupport.dll is created.
I read msi.py and learned that msilib.pe_type("msisupport.dll") (line
178) is executed before os.system("nmake /nologo /c /f msisupport.mak")
(line 372) is executed in add_ui(), which is called at line 1299.
So I made a patch to make msi.py to see if the file "msisupport.dll"
exists, and if it does, check if the dll is for the correct architecture.
----------
components: Installation
files: patch.txt
messages: 92086
nosy: pds
severity: normal
status: open
title: No such file or directory: 'msisupport.dll' in msi.py
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file14806/patch.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6807>
_______________________________________
From report at bugs.python.org Sun Aug 30 17:40:58 2009
From: report at bugs.python.org (Tom Morse)
Date: Sun, 30 Aug 2009 15:40:58 +0000
Subject: [New-bugs-announce] [issue6808] python 3.1 documentation tutorial
classes
In-Reply-To: <1251646858.69.0.964592229296.issue6808@psf.upfronthosting.co.za>
Message-ID: <1251646858.69.0.964592229296.issue6808@psf.upfronthosting.co.za>
New submission from Tom Morse <thomas.morse at snet.net>:
Thank you for the most excellent documentation and notes on classes in
python:
http://docs.python.org/3.1/tutorial/classes.html
I found the following minor typos and provide feedback on the above web
page:
1. Where "unpacked again" occurs there is no reference to any first
unpacking so that was confusing to me. I had the impression that if
"again" was omitted it was vaguely understandable.
2. Typo: where "of instances of c" occurs, "of c" should be "of C"
----------
assignee: georg.brandl
components: Documentation
messages: 92091
nosy: georg.brandl, tom_morse
severity: normal
status: open
title: python 3.1 documentation tutorial classes
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6808>
_______________________________________
From report at bugs.python.org Mon Aug 31 08:38:48 2009
From: report at bugs.python.org (Andrew Liu)
Date: Mon, 31 Aug 2009 06:38:48 +0000
Subject: [New-bugs-announce] [issue6809] Python string.lstrip bug?
In-Reply-To: <1251700728.18.0.0769627143448.issue6809@psf.upfronthosting.co.za>
Message-ID: <1251700728.18.0.0769627143448.issue6809@psf.upfronthosting.co.za>
New submission from Andrew Liu <mushywushy at gmail.com>:
A simple lstrip on the following causes an extra character to be
stripped, as per the below. Tried on 2.6.1 and on 2.4.3, as below.
Python 2.6.1 (r261:67515, Feb 27 2009, 02:54:13)
[GCC 4.3.2 20081105 (Red Hat 4.3.2-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = "contact_work_phone_no"
>>> a.lstrip("contact")
'_work_phone_no'
>>> a.lstrip("contact_")
'work_phone_no'
>>> a = "contact_city"
>>> a.lstrip("contact_")
'ity'
>>> a.lstrip("con")
'tact_city'
>>> a.lstrip("contact")
'_city'
>>> a.lstrip("contact_")
'ity'
>>>
Python 2.4.3 (#1, Mar 14 2007, 19:01:42)
[GCC 4.1.1 20070105 (Red Hat 4.1.1-52)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = "contact_city"
>>> a.lstrip("contact_")
'ity'
>>>
----------
components: Build
messages: 92102
nosy: mushywushy
severity: normal
status: open
title: Python string.lstrip bug?
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6809>
_______________________________________
From report at bugs.python.org Mon Aug 31 09:32:03 2009
From: report at bugs.python.org (Yinon Ehrlich)
Date: Mon, 31 Aug 2009 07:32:03 +0000
Subject: [New-bugs-announce] [issue6810] add link to the documentation of
signal.signal
In-Reply-To: <1251703923.28.0.662509969708.issue6810@psf.upfronthosting.co.za>
Message-ID: <1251703923.28.0.662509969708.issue6810@psf.upfronthosting.co.za>
New submission from Yinon Ehrlich <yinoneh at users.sourceforge.net>:
in http://docs.python.org/library/signal.html#signal.signal the reader
is referred to "see the reference manual section on the standard type
hierarchy". It would be generous if we will supply a link like
"http://docs.python.org/reference/datamodel.html"
BTW: it would be even more generous if the page
http://docs.python.org/reference/datamodel.html will include anchors to
specific paragraphs/items, so we could even refer to
http://docs.python.org/reference/datamodel.html#frame, for example (the
#frame anchor doesn't exist now)
Thanks in advance !
----------
assignee: georg.brandl
components: Documentation
messages: 92106
nosy: Yinon, georg.brandl
severity: normal
status: open
title: add link to the documentation of signal.signal
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6810>
_______________________________________
From report at bugs.python.org Mon Aug 31 20:58:53 2009
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 31 Aug 2009 18:58:53 +0000
Subject: [New-bugs-announce] [issue6811] add a filename argument to
marshal.load*
In-Reply-To: <1251745133.13.0.463652094911.issue6811@psf.upfronthosting.co.za>
Message-ID: <1251745133.13.0.463652094911.issue6811@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
For compatibility w/ import, importlib needs the ability to set
code.co_filename to the actual location of the bytecode used to create a
module and not the path embedded in the marshal data. But since
co_filename is read-only it can't be done at the moment.
The idea is to add an optional argument to marshal.load* that takes a
string representing the file path that co_filename should be set to,
overriding what is in the marshal data.
A long-term perk of this is that eventually this argument can become
required for marshal.loads() and the file path embedded in the marshal
data can be removed entirely. marshal.load() would infer its path from
file.name.
This was all discussed on python-dev;
http://mail.python.org/pipermail/python-dev/2009-August/091460.html
----------
assignee: brett.cannon
components: Extension Modules
messages: 92113
nosy: brett.cannon
priority: low
severity: normal
stage: test needed
status: open
title: add a filename argument to marshal.load*
type: feature request
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6811>
_______________________________________