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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
----------
components: Library (Lib)
nosy: vincele
severity: normal
status: open
title: Lib/ftplib.py
versions: Python 3.2
_______________________________________
Python tracker
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
$ 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
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
execfile(sys.argv[0])
File "play.py", line 15, in
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 "", 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 "", 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
_______________________________________
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 :
RFC 2368 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
_______________________________________
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 :
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 "", line 1, in
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
_______________________________________
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 :
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]
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=)
at ../../unladen2/Modules/threadmodule.c:46
#3 0x000000000055b89d in _PyEval_CallFunction (stack_pointer=0x128ff20,
na=, 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=,
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=) 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=,
args=) at ../../unladen2/Modules/posixmodule.c:5797
#2 0x000000000055b89d in _PyEval_CallFunction (stack_pointer=0x129cff8,
na=, 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=, num_kwargs=0,
flags=) 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=, num_kwargs=0,
flags=) 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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
./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 : /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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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')
Traceback (most recent call last):
File "", line 1, in
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.*)' :)
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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 "", line 1, in
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
"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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
When HTMLParser.HTMLParser encounters a malformed charref (for example
bad;) it no longer parsers the following HTML correctly.
For example:
bad;
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('bad;
')
parser.close()
Expected output:
Start "p"
Data "bad;"
End "p"
Actual output:
Start "p"
Data "bad;
"
----------
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
#include
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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("
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
"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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
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
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
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
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
# 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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
(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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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? :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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 "$(
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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' :
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
_______________________________________
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 :
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
_______________________________________
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 :
# ------ 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
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
_______________________________________
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 :
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, "", "exec")
at 0x7f0a92aed918, file "", line 1>
>>> from dis import dis
>>> dis(x)
>>> dis(compile(x, "", "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
_______________________________________
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 :
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
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
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
_______________________________________
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 :
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
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
_______________________________________
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 :
In the client side example under
21.17.4.2. SocketServer.UDPServer Example:
at:
http://docs.python.org/dev/library/socketserver.html
<<<>>>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
_______________________________________
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 :
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)()
-> 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 "", line 1, in
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
> (1)()
(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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
_______________________________________
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 :
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
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