From report at bugs.python.org  Sat Aug  1 18:09:06 2009
From: report at bugs.python.org (OG7)
Date: Sat, 01 Aug 2009 16:09:06 +0000
Subject: [New-bugs-announce] [issue6615] multiprocessing logging support test
In-Reply-To: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
Message-ID: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>


New submission from OG7 <onyxg7 at users.sourceforge.net>:

There is an additional test for multiprocessing's logging support here:
http://code.google.com/p/python-multiprocessing/issues/detail?id=18
(disregard the fix, it is only needed for the backport).

----------
components: Library (Lib)
messages: 91163
nosy: OG7, jnoller
severity: normal
status: open
title: multiprocessing logging support test
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Sat Aug  1 22:43:47 2009
From: report at bugs.python.org (Campbell Barton)
Date: Sat, 01 Aug 2009 20:43:47 +0000
Subject: [New-bugs-announce] [issue6616] PyList_APPEND (append without
	incref)
In-Reply-To: <1249159427.67.0.400493436196.issue6616@psf.upfronthosting.co.za>
Message-ID: <1249159427.67.0.400493436196.issue6616@psf.upfronthosting.co.za>


New submission from Campbell Barton <ideasman42 at gmail.com>:

This patch was made on python r74276

Often when writing in C/Python I want to append to a list within a C
loop of an unknown length.
When this is done for newly created PyObject (which is quite common) -
you need to assign each item to a variable and then decref it.

eg:
 PyObject *item= PyFloat_FromDouble(x);
 PyList_Append(list, item);
 Py_DECREF(item);

I have seen people make mistakes with this (in pygame code and
blender3d), and run  PyList_Append(list, PyFloat_FromDouble(x)),
ofcourse this is not the fault of python/c api that devs do not read
docs properly but I think it would be very convenient to have an append
that works in a similar way to PyList_SET_ITEM

This simple patch allows...
 PyList_APPEND(list, PyFloat_FromDouble(x))

doc included.

----------
files: py3_APPEND.diff
keywords: patch
messages: 91167
nosy: ideasman42
severity: normal
status: open
title: PyList_APPEND (append without incref)
versions: Python 3.2
Added file: http://bugs.python.org/file14619/py3_APPEND.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6616>
_______________________________________

From report at bugs.python.org  Sat Aug  1 23:37:57 2009
From: report at bugs.python.org (Sandip Thorat)
Date: Sat, 01 Aug 2009 21:37:57 +0000
Subject: [New-bugs-announce] [issue6617] During compiling python 3.1 getting
	error Undefined	symbol libintl_bind_textdomain_codeset
In-Reply-To: <1249162677.96.0.181878890277.issue6617@psf.upfronthosting.co.za>
Message-ID: <1249162677.96.0.181878890277.issue6617@psf.upfronthosting.co.za>


New submission from Sandip Thorat <thoratsandip at gmail.com>:

Hi 

I am installing Python-3.1 on "SunOS sunx7qa 5.10 Generic_127112-06 
i86pc i386 i86pc".

./configure  done without any error.

But 'make' throwing folloing error:



gcc -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-
prototypes  -I. -IInclude -I./Include  -DPy_BUILD_CORE -
DSVNVERSION="\"`LC_ALL=C echo Unversioned directory`\"" -o 
Modules/getbuildinfo.o ./Modules/getbuildinfo.c
rm -f libpython3.1.a
ar rc libpython3.1.a Modules/getbuildinfo.o
ar rc libpython3.1.a Parser/acceler.o  Parser/grammar1.o  
Parser/listnode.o  Parser/node.o  Parser/parser.o  Parser/parsetok.o  
Parser/bitset.o  Parser/metagrammar.o  Parser/firstsets.o  
Parser/grammar.o  Parser/pgen.o Parser/myreadline.o Parser/tokenizer.o
ar rc libpython3.1.a Objects/abstract.o  Objects/boolobject.o  
Objects/bytes_methods.o  Objects/bytearrayobject.o  
Objects/bytesobject.o  Objects/cellobject.o  Objects/classobject.o  
Objects/cobject.o  Objects/codeobject.o  Objects/complexobject.o  
Objects/descrobject.o  Objects/enumobject.o  Objects/exceptions.o  
Objects/genobject.o  Objects/fileobject.o  Objects/floatobject.o  
Objects/frameobject.o  Objects/funcobject.o  Objects/iterobject.o  
Objects/listobject.o  Objects/longobject.o  Objects/dictobject.o  
Objects/memoryobject.o  Objects/methodobject.o  Objects/moduleobject.o  
Objects/object.o  Objects/obmalloc.o  Objects/capsule.o  
Objects/rangeobject.o  Objects/setobject.o  Objects/sliceobject.o  
Objects/structseq.o  Objects/tupleobject.o  Objects/typeobject.o  
Objects/unicodeobject.o  Objects/unicodectype.o  Objects/weakrefobject.o
ar rc libpython3.1.a Python/_warnings.o  Python/Python-ast.o  
Python/asdl.o  Python/ast.o  Python/bltinmodule.o  Python/ceval.o  
Python/compile.o  Python/codecs.o  Python/errors.o  Python/frozen.o  
Python/frozenmain.o  Python/future.o  Python/getargs.o  
Python/getcompiler.o  Python/getcopyright.o  Python/getplatform.o  
Python/getversion.o  Python/graminit.o  Python/import.o  
Python/importdl.o  Python/marshal.o  Python/modsupport.o  
Python/mystrtoul.o  Python/mysnprintf.o  Python/peephole.o  
Python/pyarena.o  Python/pyctype.o  Python/pyfpe.o  Python/pymath.o  
Python/pystate.o  Python/pythonrun.o  Python/structmember.o  
Python/symtable.o  Python/sysmodule.o  Python/traceback.o  
Python/getopt.o  Python/pystrcmp.o  Python/pystrtod.o  Python/dtoa.o  
Python/formatter_unicode.o  Python/dynload_shlib.o      Python/thread.o
ar rc libpython3.1.a Modules/config.o  Modules/getpath.o  
Modules/main.o  Modules/gcmodule.o
ar rc libpython3.1.a Modules/_threadmodule.o  Modules/signalmodule.o  
Modules/posixmodule.o  Modules/errnomodule.o  Modules/pwdmodule.o  
Modules/_sre.o  Modules/_codecsmodule.o  Modules/_weakref.o  
Modules/_functoolsmodule.o  Modules/_localemodule.o  
Modules/_iomodule.o Modules/iobase.o Modules/fileio.o Modules/bytesio.o 
Modules/bufferedio.o Modules/textio.o Modules/stringio.o  
Modules/zipimport.o  Modules/symtablemodule.o  Modules/xxsubtype.o
ranlib libpython3.1.a
gcc   -o python \
                Modules/python.o \
                libpython3.1.a -lresolv -lsocket -lnsl -lrt -ldl   -lm
Undefined                       first referenced
 symbol                             in file
libintl_bind_textdomain_codeset     libpython3.1.a(_localemodule.o)
libintl_gettext                     libpython3.1.a(_localemodule.o)
libintl_textdomain                  libpython3.1.a(_localemodule.o)
libintl_dcgettext                   libpython3.1.a(_localemodule.o)
libintl_bindtextdomain              libpython3.1.a(_localemodule.o)
libintl_dgettext                    libpython3.1.a(_localemodule.o)
ld: fatal: Symbol referencing errors. No output written to python
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `python'
bash-3.00$ pwd


Need your help to resolve this issue.

----------
components: Installation
messages: 91170
nosy: thoratsandip
severity: normal
status: open
title: During compiling python 3.1 getting error Undefined symbol libintl_bind_textdomain_codeset
type: compile error
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6617>
_______________________________________

From report at bugs.python.org  Sat Aug  1 23:55:16 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Sat, 01 Aug 2009 21:55:16 +0000
Subject: [New-bugs-announce] [issue6618] Typo in a listing in 5.2.9 of
	language reference
In-Reply-To: <1249163716.22.0.790124274674.issue6618@psf.upfronthosting.co.za>
Message-ID: <1249163716.22.0.790124274674.issue6618@psf.upfronthosting.co.za>


New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:

Error in:

Python v3.1 documentation >> The Python language reference >>

In the listing at the end of section 5.2.9 Yield expressions,
line 7:

...             except Exception, e:

is syntactically incorrect and consequently raises a Syntax Error.
Should read:

...             except Exception as e:

----------
assignee: georg.brandl
components: Documentation
messages: 91171
nosy: georg.brandl, gregorlingl
severity: normal
status: open
title: Typo in a listing in 5.2.9 of language reference
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6618>
_______________________________________

From report at bugs.python.org  Sun Aug  2 00:13:55 2009
From: report at bugs.python.org (Vincent Legoll)
Date: Sat, 01 Aug 2009 22:13:55 +0000
Subject: [New-bugs-announce] [issue6619] Remove duplicated function in
	Lib/inspect.py
In-Reply-To: <1249164835.58.0.202112743442.issue6619@psf.upfronthosting.co.za>
Message-ID: <1249164835.58.0.202112743442.issue6619@psf.upfronthosting.co.za>


New submission from Vincent Legoll <vincent.legoll at gmail.com>:

The isgenerator() function looks duplicated, remove the one with the
shortest docstring

----------
components: Library (Lib)
files: py3k-inspect.py-remove-duplicated-func.patch
keywords: patch
messages: 91172
nosy: vincele
severity: normal
status: open
title: Remove duplicated function in Lib/inspect.py
versions: Python 3.2
Added file: http://bugs.python.org/file14621/py3k-inspect.py-remove-duplicated-func.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6619>
_______________________________________

From report at bugs.python.org  Sun Aug  2 00:18:37 2009
From: report at bugs.python.org (Vincent Legoll)
Date: Sat, 01 Aug 2009 22:18:37 +0000
Subject: [New-bugs-announce] [issue6620] Variable may be used before first
	being assigned to in	Lib/locale.py
In-Reply-To: <1249165117.85.0.22004101137.issue6620@psf.upfronthosting.co.za>
Message-ID: <1249165117.85.0.22004101137.issue6620@psf.upfronthosting.co.za>


New submission from Vincent Legoll <vincent.legoll at gmail.com>:

The last_interval variable could potentially be used before being first
assigned a value.

----------
components: Library (Lib)
files: py3k-locale.py-use-before-assignment.patch
keywords: patch
messages: 91173
nosy: vincele
severity: normal
status: open
title: Variable may be used before first being assigned to in Lib/locale.py
versions: Python 3.2
Added file: http://bugs.python.org/file14622/py3k-locale.py-use-before-assignment.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6620>
_______________________________________

From report at bugs.python.org  Sun Aug  2 00:22:06 2009
From: report at bugs.python.org (Vincent Legoll)
Date: Sat, 01 Aug 2009 22:22:06 +0000
Subject: [New-bugs-announce] [issue6621] [RFC] Remove leftover use of Carbon
	module from	Lib/binhex.py
In-Reply-To: <1249165326.88.0.231668096917.issue6621@psf.upfronthosting.co.za>
Message-ID: <1249165326.88.0.231668096917.issue6621@psf.upfronthosting.co.za>


New submission from Vincent Legoll <vincent.legoll at gmail.com>:

The binhex module still has uses of the deprecated and now now removed
Carbon module.

The attached patch 'fix' this by removing the code, something else may
be required, but I don't know what.

So this is only a RFC to start discussion

----------
components: Library (Lib)
files: py3k-binhex.py-remove-carbon-module-use.patch
keywords: patch
messages: 91174
nosy: vincele
severity: normal
status: open
title: [RFC] Remove leftover use of Carbon module from Lib/binhex.py
versions: Python 3.2
Added file: http://bugs.python.org/file14623/py3k-binhex.py-remove-carbon-module-use.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6621>
_______________________________________

From report at bugs.python.org  Sun Aug  2 00:24:47 2009
From: report at bugs.python.org (Vincent Legoll)
Date: Sat, 01 Aug 2009 22:24:47 +0000
Subject: [New-bugs-announce] [issue6622] [RFC] wrong variable used in
	Lib/poplib.py
In-Reply-To: <1249165487.21.0.506053747681.issue6622@psf.upfronthosting.co.za>
Message-ID: <1249165487.21.0.506053747681.issue6622@psf.upfronthosting.co.za>


New submission from Vincent Legoll <vincent.legoll at gmail.com>:

The poplib modules use the 'secret' variable during its creation, this
may be a mistake. Perhaps the intention was to use the 'password' instead...

----------
components: Library (Lib)
files: py3k-poplib.py-use-wrong-variable.patch
keywords: patch
messages: 91175
nosy: vincele
severity: normal
status: open
title: [RFC] wrong variable used in Lib/poplib.py
versions: Python 3.2
Added file: http://bugs.python.org/file14624/py3k-poplib.py-use-wrong-variable.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6622>
_______________________________________

From report at bugs.python.org  Sun Aug  2 00:25:35 2009
From: report at bugs.python.org (Vincent Legoll)
Date: Sat, 01 Aug 2009 22:25:35 +0000
Subject: [New-bugs-announce] [issue6623] Lib/ftplib.py
Message-ID: <1249165535.5.0.936372690866.issue6623@psf.upfronthosting.co.za>


Changes by Vincent Legoll <vincent.legoll at gmail.com>:


----------
components: Library (Lib)
nosy: vincele
severity: normal
status: open
title: Lib/ftplib.py
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6623>
_______________________________________

From report at bugs.python.org  Sun Aug  2 01:53:44 2009
From: report at bugs.python.org (Sean Reifschneider)
Date: Sat, 01 Aug 2009 23:53:44 +0000
Subject: [New-bugs-announce] [issue6624] PyArg_ParseTuple with "s" format
	and NUL: Bogus TypeError	detail string.
In-Reply-To: <1249170824.71.0.297411055704.issue6624@psf.upfronthosting.co.za>
Message-ID: <1249170824.71.0.297411055704.issue6624@psf.upfronthosting.co.za>


New submission from Sean Reifschneider <jafo at tummy.com>:

As detailed in the python-dev post:

   http://mail.python.org/pipermail/python-dev/2009-July/090791.html

I have found a bug in the handling of PyArg_ParseTuple where a NUL in an
argument causes a message like this:

   syslog.syslog('hello\0there')
   TypeError: [priority,] message string

Instead of:

   TypeError: must be string without null bytes, not str

This seems to be a thinko in Python/getargs.c at line 331:

   msg = convertitem(PyTuple_GET_ITEM(args, i), &format, p_va,
        flags, levels, msgbuf,
        sizeof(msgbuf), &freelist);
   if (msg) {
      seterror(i+1, msg, levels, fname, message);   <<< Line 331
      return cleanreturn(0, freelist);
   }

This also applies to Python 3 trunk in line 390.

I think that's supposed to be "msg" instead of "message" in the last
argument.

I have made this change and "make test" for both python and py3k trunks
is clean.

----------
assignee: jafo
components: Interpreter Core
messages: 91177
nosy: jafo
priority: normal
severity: normal
stage: committed/rejected
status: open
title: PyArg_ParseTuple with "s" format and NUL: Bogus TypeError detail string.
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6624>
_______________________________________

From report at bugs.python.org  Sun Aug  2 15:00:48 2009
From: report at bugs.python.org (Christoph Burgmer)
Date: Sun, 02 Aug 2009 13:00:48 +0000
Subject: [New-bugs-announce] [issue6625] UnicodeEncodeError on pydoc's CLI
In-Reply-To: <1249218048.23.0.0483172452601.issue6625@psf.upfronthosting.co.za>
Message-ID: <1249218048.23.0.0483172452601.issue6625@psf.upfronthosting.co.za>


New submission from Christoph Burgmer <cburgmer at ira.uka.de>:

pydoc fails with a UnicodeEncodeError for properly specified Unicode
docstrings (u"""...""") on the command line interface.

See attached patch that encodes the output with the system's encoding.

----------
components: Extension Modules
files: unicode.patch
keywords: patch
messages: 91182
nosy: christoph
severity: normal
status: open
title: UnicodeEncodeError on pydoc's CLI
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14626/unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6625>
_______________________________________

From report at bugs.python.org  Sun Aug  2 21:19:23 2009
From: report at bugs.python.org (Jacob Rus)
Date: Sun, 02 Aug 2009 19:19:23 +0000
Subject: [New-bugs-announce] [issue6626] show Python mimetypes module some
	love
In-Reply-To: <1249240763.95.0.402656374782.issue6626@psf.upfronthosting.co.za>
Message-ID: <1249240763.95.0.402656374782.issue6626@psf.upfronthosting.co.za>


New submission from Jacob Rus <jacobolus at gmail.com>:

See discussion started right at the end of the month at
http://mail.python.org/pipermail/python-dev/2009-July/090928.html

And continued at
http://mail.python.org/pipermail/python-dev/2009-August/thread.html

Basically, the mimetypes module is fragile and very confusing code, 
built up over years of feature creep without refactoring or careful 
overall design. I'd like to cut it down to a more manageable code size, 
fix some bugs, update the included list of mime types, and use some nice 
Python features of versions 2.2+. Ideally someone reading the module 
once through would be able to understand what it does.

Patches to be attached shortly.

----------
components: Library (Lib)
messages: 91196
nosy: jrus
severity: normal
status: open
title: show Python mimetypes module some love
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6626>
_______________________________________

From report at bugs.python.org  Sun Aug  2 22:02:44 2009
From: report at bugs.python.org (Nikolaus Rath)
Date: Sun, 02 Aug 2009 20:02:44 +0000
Subject: [New-bugs-announce] [issue6627] threading.local() does not work
	with C-created threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>


New submission from Nikolaus Rath <Nikolaus at rath.org>:

When threads are created by a C extension loaded with ctypes,
threading.local() objects are always empty. If one uses
_threading_local.local() instead of threading.local(), the problem does
not occur. 

More information and example program showing the behaviour:
http://code.google.com/p/fusepy/issues/detail?id=15

----------
components: Library (Lib)
messages: 91198
nosy: Nikratio
severity: normal
status: open
title: threading.local() does not work with C-created threads
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6627>
_______________________________________

From report at bugs.python.org  Mon Aug  3 01:15:46 2009
From: report at bugs.python.org (brian)
Date: Sun, 02 Aug 2009 23:15:46 +0000
Subject: [New-bugs-announce] [issue6628] IDLE freezes after encountering a
	syntax error
In-Reply-To: <1249254946.68.0.209899290876.issue6628@psf.upfronthosting.co.za>
Message-ID: <1249254946.68.0.209899290876.issue6628@psf.upfronthosting.co.za>


New submission from brian <omniscient.brian at gmail.com>:

Running Python 3.1/ IDLE, which was installed on top of a Python 2.5.4
install, Mac OSX 10.4

This seems like such an obvious bug, but I can't find it in the current
list of issues - so I suspect that it may not be reproducible on other
computers, but it's certainly reproducible on my laptop.

If I run a module with (any?) syntax error (for example,

for i in range(10) #missing semicolon
    print i

the interpreter will catch it and send you to fix it. Then, any
subsequent attempts to run that same module will freeze IDLE. The
problem doesn't occur if you run a different module.

----------
components: IDLE
messages: 91210
nosy: brian89
severity: normal
status: open
title: IDLE freezes after encountering a syntax error
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6628>
_______________________________________

From report at bugs.python.org  Mon Aug  3 08:47:41 2009
From: report at bugs.python.org (Javier)
Date: Mon, 03 Aug 2009 06:47:41 +0000
Subject: [New-bugs-announce] [issue6630] string.Template custom pattern not
	working
In-Reply-To: <1249282061.67.0.26692722483.issue6630@psf.upfronthosting.co.za>
Message-ID: <1249282061.67.0.26692722483.issue6630@psf.upfronthosting.co.za>


New submission from Javier <javier.collado at gmail.com>:

In the string.Template documentation
(http://docs.python.org/library/string.html) it's explained that if a
custom regular expression for pattern substitution is needed, it's
possible to override idpattern class attribute (whose default value is
[_a-z][_a-z0-9]*).

However, if the custom pattern that is needed is just uppercase
letters, something like [A-Z]+ won't work because of the following line
in the _TemplateMetaclass class __init__ method:
cls.pattern = _re.compile(pattern, _re.IGNORECASE | _re.VERBOSE)

I would say that this is an error (IGNORECASE just shouldn't be there)
and that the line above should be:
cls.pattern = _re.compile(pattern, _re.VERBOSE)
and the default value for idpattern:
[_a-zA-Z][_a-zA-Z0-9]*

Do you agree on this? Is there any reason for the IGNORECASE option to
be passed to re.compile?

----------
components: IO, Regular Expressions
messages: 91217
nosy: jcollado
severity: normal
status: open
title: string.Template custom pattern not working
type: behavior
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6630>
_______________________________________

From report at bugs.python.org  Mon Aug  3 15:33:03 2009
From: report at bugs.python.org (albert Mietus)
Date: Mon, 03 Aug 2009 13:33:03 +0000
Subject: [New-bugs-announce] [issue6631] urlparse.urlunsplit() can't handle
	relative files (for	urllib*.open()
In-Reply-To: <1249306383.87.0.829314243328.issue6631@psf.upfronthosting.co.za>
Message-ID: <1249306383.87.0.829314243328.issue6631@psf.upfronthosting.co.za>


New submission from albert Mietus <albert at mietus.nl>:

The functions urlparse.url{,un}split() and urllib{,2}.open() do not work 
together for relative, local files, due a bug in urlunsplit.

Given a file f='./rel/path/to/file.html' it can be open directly by 
urllib.open(f), but not in urllib2! as the later needs a scheme.
We can create a sound url with spilt/unspilt and a default scheme:
f2=urlparse.urlunsplit(urlparse.urlsplit(f,'file')); which works most 
cases, HOWEVER a bogus netloc is added for relative filepaths.

If have isolated this  "buggy" function, added some local testcode and 
made patch/workaround in my file 'unsplit.py' Which is included. Hope 
this will contribute to a real patch.


--Groetjes, Albert

ALbert Mietus
                                                Don't send spam mail!
Mijn missie: http://SoftwareBeterMaken.nl      product, proces & imago.
Mijn leven in het kort:        
http://albert.mietus.nl/Doc/CV_ALbert.html

----------
components: Library (Lib)
files: unsplit.py
messages: 91222
nosy: albert
severity: normal
status: open
title: urlparse.urlunsplit() can't handle relative files (for urllib*.open()
type: performance
Added file: http://bugs.python.org/file14637/unsplit.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6631>
_______________________________________

From report at bugs.python.org  Mon Aug  3 04:00:41 2009
From: report at bugs.python.org (Karoly Lorentey)
Date: Mon, 03 Aug 2009 02:00:41 +0000
Subject: [New-bugs-announce] [issue6629] seek doesn't properly handle file
	buffer, leads to silent data corruption
In-Reply-To: <1249264841.18.0.232875994092.issue6629@psf.upfronthosting.co.za>
Message-ID: <1249264841.18.0.232875994092.issue6629@psf.upfronthosting.co.za>


New submission from Karoly Lorentey <karoly at lorentey.hu>:

The new io.BufferedRandom implementation in Python 3.1 has a broken seek 
that seems not to properly handle the case when the target of the seek 
lies inside the contents of the file buffer.  It leaves the file object 
in a confused state, such that the next write operation applies after 
the end of the buffer(!) instead of the specified target.

I could reproduce the following symptoms on both Debian Lenny and Mac OS 
X Leopard.  I downloaded the Python 3.1 tarball from python.org, and 
built it by hand using './configure && make'.

$ ./python.exe
Python 3.1 (r31:73572, Aug  3 2009, 02:32:10) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> open("test", "wb").write(b"A" * 10000)
10000
>>> file = open("test", "rb+")
>>> file.read(10)       # Reads 4096 bytes into file buffer
b'AAAAAAAAAA'
>>> file.tell()
10
>>> file.seek(0)
0
>>> file.tell()
0
>>> file.write(b"B" * 10000)  # This should overwrite the whole file
10000
>>> file.tell()
14096  # Hmm, 0 + 10000 == 14096?
>>> file.close()
>>> d = open("test", "rb").read()
>>> len(d)
14096  # ?!
>>> d[0:10]      # The file should now consist of 10000 Bs...
b'AAAAAAAAAA'
>>> d[4090:4100]
b'AAAAAABBBB'    # ... but the Bs only start after a buffer's worth of 
As.

This bug has actually caused me some subtle, silent data corruption that 
went undetected for quite a while.  Hurray for backups!

The above code works fine in Python 3.0, and its Python 2.5 port also 
produces correct results.

A workaround for 3.1 is to call flush before every seek.

----------
components: IO
messages: 91211
nosy: lorentey
severity: normal
status: open
title: seek doesn't properly handle file buffer, leads to silent data corruption
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6629>
_______________________________________

From report at bugs.python.org  Mon Aug  3 18:34:45 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 03 Aug 2009 16:34:45 +0000
Subject: [New-bugs-announce] [issue6632] Include more fullwidth chars in the
	decimal codec
In-Reply-To: <1249317285.35.0.709481915004.issue6632@psf.upfronthosting.co.za>
Message-ID: <1249317285.35.0.709481915004.issue6632@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

The decimal codec only handles characters in the Nd (Number, decimal)
Unicode category and whitespaces [a]. It is used by int(), float(),
complex() and indirectly by Decimal(), Fraction() and possibly others.
This works well only for plain digits (e.g. int(u'???')) but it
doesn't work for all the other characters used to represent numbers, like:
1. plus or minus sign, e.g. int(u'????') or int(u'????')
2. decimal point, e.g. float(u'????')
   2.1 some languages/alphabets use other chars (e.g. a comma or other
       symbols) instead of the decimal point.
3. exponential notation, e.g. float(u'???')
4. the 'j' in complex numbers, e.g. complex(u'??')
5. the 'x' and 'p' in hexadecimal floats, e.g.
float.fromhex(u'???????')
   5.1 hex floats also uses hexadecimal digits, see 6.3
6. digits > 9 for numbers with a base > 10, e.g. int(u'??', 16)
    6.1 not all the alphabets have the equivalent of the letters a-z
    6.2 afaik there are no standards that specify how to deal with
        digits >9
    6.3 in the Unicode FAQ [b] there's a link to a table [c] that says
        "Code points not listed in this file are not hexadecimal
        digits." This is not a standard though, and even if in the
        UCD [d] there's a file [e] where the numbers with the Hex_Digit
        property are defined, it doesn't say that *only* these numbers
        are valid hex digits. Also it doesn't say anything about
        different bases.
        Python currently accepts int(u'??', 16), int(u'?', 16)
        (U+096D - DEVANAGARI DIGIT SEVEN) and even int(u'?F', 16)
        (with a normal F it works, with a fullwidth ? it fails).
    6.4 UTS #18 [f] includes in the property 'xdigit' [g] (hexadecimal
        digit) all the chars defined in [c] and also all the chars with
        a Nd category. This also is not a standard, and it doesn't
        give indications about the valid hex digits and how int()
        should behave.
    6.5 if possible re and int() should agree. Any string that matches
        /^[[:xdigit:]]+$/ should work fine with int(s, 16) and vice 
        versa. See also #6561 [h] and #2636 [i].
7. possibly others


For all the chars listed in the points 1-5 there's no way, AFAIK, to
know their equivalents in other alphabets (if they exist at all) and
since (apparently) there's no standard that specifies how to handle
them, they should be kept out.
This will also avoid a number of problems, e.g. 2.1.

The fullwidth forms are an exception though: they seem to be the only
set of characters with a direct equivalent for all these chars, and they
are also the only non-ascii chars included in the list of chars with the
Unicode Hex_Digits property.

Including all the necessary chars from this range in the decimal codec
seems to me the best thing to do. The chars listed in the points 1-5
should all be implemented and they should work everywhere. The regex
used by Decimal/Fraction should be updated as well, since the decimal
codec is not accessible from Python (maybe it should be accessible, but
this is another issue).

Point 6 is a slightly different issue, even if it can be partially
solved if the fullwidth forms will be included. One of the possible
options is to limit the valid chars used by int() with bases > 10 only
to the characters listed in [c], but this won't be backward-compatible
with existing code and forward-compatible with [[:xdigit:]].
OTOH if we keep the current behavior it will be possible to express the
digits from 0 to 9 using several alphabets, but all the digits > 9 will
be limited to [a-fA-F] (and possibly [??????]).
For example, '7F' in the devanagari alphabet will result in a mix of
devanagari numbers and ascii letters, i.e. int(u'?F', 16) (this already
works in Python).


[a]:
http://svn.python.org/view/python/trunk/Objects/unicodeobject.c?view=markup
under 'Decimal Encoder'
[b]: http://unicode.org/faq/casemap_charprop.html#13
[c]: http://unicode.org/faq/hex-digit-values.txt - [0-9a-fA-
F?????????]
[d]: http://unicode.org/Public/UNIDATA/UCD.html#UCD_Files - PropList.txt
section
[e]: http://unicode.org/Public/UNIDATA/PropList.txt
[f]: http://unicode.org/reports/tr18/ - UTS #18: Unicode Regular Expressions
[g]: http://unicode.org/reports/tr18/#Compatibility_Properties - xdigit row
[h]: http://bugs.python.org/issue6561#msg90878 point (1) about int() and re
[i]: http://bugs.python.org/issue2636#msg65513 point 8) will introduce
[[:xdigit:]]

(Thanks to Mark Dickinson and Adam Olsen for pointing out some of these
issues.)

----------
components: Interpreter Core, Unicode
messages: 91225
nosy: ezio.melotti
priority: normal
severity: normal
status: open
title: Include more fullwidth chars in the decimal codec
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6632>
_______________________________________

From report at bugs.python.org  Mon Aug  3 19:04:11 2009
From: report at bugs.python.org (James)
Date: Mon, 03 Aug 2009 17:04:11 +0000
Subject: [New-bugs-announce] [issue6633] No handlers could be found for
	logger
In-Reply-To: <1249319051.14.0.476850462848.issue6633@psf.upfronthosting.co.za>
Message-ID: <1249319051.14.0.476850462848.issue6633@psf.upfronthosting.co.za>


New submission from James <purpleidea at gmail.com>:

I was trying to suppress the error message as shown in the title, when I
found out (by searching through the source) that there is a NullHandler
for precisely this purpose.

http://svn.python.org/view/python/trunk/Lib/logging/__init__.py?r1=66211&r2=67511

do you think that:
1) this could be documented maybe here (
http://docs.python.org/library/logging.html#handler-objects ) i suppose?
and:
2) this null handler doesn't seem to exist in:
Python 2.5.2 (r252:60911, Oct  5 2008, 19:24:49) 
[GCC 4.3.2] on linux2
is this likely to get backported to 2.5? at the moment i've just
included the simple NullHandler class into my code.
3) also not my business really, but should it belong in the handlers.py
file?

thanks for all your hard work, i hope the comments are useful!

----------
components: Library (Lib)
messages: 91231
nosy: purpleidea
severity: normal
status: open
title: No handlers could be found for logger
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6633>
_______________________________________

From report at bugs.python.org  Mon Aug  3 21:21:51 2009
From: report at bugs.python.org (Jan-Philip Gehrcke)
Date: Mon, 03 Aug 2009 19:21:51 +0000
Subject: [New-bugs-announce] [issue6634] sys.exit() called from threads
	other than the main one:	undocumented behaviour
In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za>
Message-ID: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za>


New submission from Jan-Philip Gehrcke <jgehrcke at gmail.com>:

Hey there,

hopefully I fill out this form in an adequate way!

I ran into some problems while using sys.exit('msg') together with
threads, which could have been avoided with slightly more information in
the docs here: http://docs.python.org/library/sys.html#sys.exit 

Maybe the following two statements should not stay as they are:

(1) "Exit from Python."
-----------------------
This is not true when called from a thread other than the main one. We
could add a hint, saying that sys.exit() then actually behaves like
thread.exit(), which causes only the calling thread to exit, but not the
main program.

2) "[...] and any other object is printed to sys.stderr"
--------------------------------------------------------
This is also not true when called from a thread other than the main one.
Calling sys.exit('msg') then doesn't print anything to stderr. That was
annoying in my case and required debugging a bug that would have
discovered itself via stderr, if the message would have been printed..
:-) After some research, I think this behaviour is described in the
documentation for thread.exit(): "[...] this will cause the thread to
exit *silently*."


Okay, now that I am aware of this behaviour, I won't run into these
problems again. But the next one?

I think (1) is clearly a documentation thing. Regarding (2): first of
all, the documentation should say that the message is suppressed in
special cases (child threads). But: what argues against printing to
stderr here? I don't get the point and only see a lost feature,
affording a quick way to kill a thread while dropping an error message.
Was this kicked out intentionally? Maybe someone could help me with a
good argument here :-)


Thank you for your work,

Jan-Philip Gehrcke

----------
assignee: georg.brandl
components: Documentation
messages: 91237
nosy: georg.brandl, jgehrcke
severity: normal
status: open
title: sys.exit() called from threads other than the main one: undocumented behaviour
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6634>
_______________________________________

From report at bugs.python.org  Mon Aug  3 22:32:40 2009
From: report at bugs.python.org (Francesco Del Degan)
Date: Mon, 03 Aug 2009 20:32:40 +0000
Subject: [New-bugs-announce] [issue6635] Profiler doesn't print usage
	(indexError instead)
In-Reply-To: <1249331560.84.0.146355793731.issue6635@psf.upfronthosting.co.za>
Message-ID: <1249331560.84.0.146355793731.issue6635@psf.upfronthosting.co.za>


New submission from Francesco Del Degan <f.deldegan at ngi.it>:

$ python -m profile
Usage: profile.py [-o output_file_path] [-s sort] scriptfile [arg] ...

$ python -m profile -s calls
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/runpy.py", line 122, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/runpy.py", line 34, in _run_code
    exec code in run_globals
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/profile.py", line 619, in <module>
    main()
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/profile.py", line 614, in main
    parser.print_usage()
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/optparse.py", line 1584, in print_usage
    print >>file, self.get_usage()
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/optparse.py", line 1570, in get_usage
    self.expand_prog_name(self.usage))
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/optparse.py", line 1547, in expand_prog_name
    return s.replace("%prog", self.get_prog_name())
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/optparse.py", line 1542, in get_prog_name
    return os.path.basename(sys.argv[0])
IndexError: list index out of range


This is triggered by an early override of sys.argv when usage() is called (Lib/profile.py:603):

    if not sys.argv[1:]:
        parser.print_usage()
        sys.exit(2)

    (options, args) = parser.parse_args()
    sys.argv[:] = args

    if (len(sys.argv) > 0):
        sys.path.insert(0, os.path.dirname(sys.argv[0]))
        run('execfile(%r)' % (sys.argv[0],), options.outfile, options.sort)
    else:
        parser.print_usage()
    return parser




In the "else" branch it tries to print usage but sys.argv[] were already overwritten.

Attached is the proposed patch (tested with 2.5, 2.6, 3.1).

----------
components: Library (Lib)
files: python-profile-sysargv.patch
keywords: patch
messages: 91240
nosy: pr0gg3d
severity: normal
status: open
title: Profiler doesn't print usage (indexError instead)
type: behavior
versions: Python 2.5, Python 2.6, Python 3.1
Added file: http://bugs.python.org/file14639/python-profile-sysargv.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6635>
_______________________________________

From report at bugs.python.org  Mon Aug  3 22:36:13 2009
From: report at bugs.python.org (Charles Mason)
Date: Mon, 03 Aug 2009 20:36:13 +0000
Subject: [New-bugs-announce] [issue6636] Non-existant directory in sys.path
	prevents further	imports
In-Reply-To: <1249331773.17.0.57338899812.issue6636@psf.upfronthosting.co.za>
Message-ID: <1249331773.17.0.57338899812.issue6636@psf.upfronthosting.co.za>


New submission from Charles Mason <cemasoniv at gmail.com>:

Steps to reproduce:

1) Add to sys.path a path that does not exist
2) Import a module, any module.  This invokes get_path_importer over
every element of sys.path.  The NullImporter __init__ method is called
and an instance created for each non-existing path element in sys.path.
3) Create the path and put a valid module in said path
4) Try to import that module.

Behavior is that the interpreter fails to import.  This behavior seems
local to import.c only.

Attached a test case that shows "failed" for 2.5, 2.6, 3.0. 3.1rc1+.  I
have yet to test on the trunk but I can/will do that if necessary.

I believe I can fix this myself but I want to verify this is incorrect
behavior (a bug) and not an "Undocumented Feature" (or hell, maybe it
*is* documented somewhere).  I've skimmed over PEP 302 and didn't see
any relevant information.

If someone gives me the go ahead (or at least doesn't give me reason not
to), I'll get a patch put together, perhaps for several different "fixes".

----------
components: Interpreter Core
files: test.py
messages: 91241
nosy: cemasoniv
severity: normal
status: open
title: Non-existant directory in sys.path prevents further imports
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file14640/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6636>
_______________________________________

From report at bugs.python.org  Mon Aug  3 23:25:52 2009
From: report at bugs.python.org (Tom Clarke)
Date: Mon, 03 Aug 2009 21:25:52 +0000
Subject: [New-bugs-announce] [issue6637] non-empty defaultdict .copy() fails
	returning empty dict
In-Reply-To: <1249334752.4.0.485254518119.issue6637@psf.upfronthosting.co.za>
Message-ID: <1249334752.4.0.485254518119.issue6637@psf.upfronthosting.co.za>


New submission from Tom Clarke <t.clarke at ic.ac.uk>:

The enclosed script when run under 2.6.2 IDLE standard distribution on
x86 shows that shallow copy (.copy()) of a non-empty defaultdict object
returns an empty defaultdict!

Other ways to copy, e.g. defaultdict(none, d.items()), work fine.

Bug appears under:
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on win32

I have tested it on two different computers. They both also have the
visual installed from a v2.6 binary - but I can't see why this would
change standard libraries.

Hope I am not being stupid - this seems to big a bug to be real!

**Documentation on defaultdict states (nearly all) methods are same as
dict, and on dict defines copy() as returning a shallow copy.

**replace defaultdict by dict and this example works as expected

Best wishes, Tom

PS - I am new to python so forgive any stupidity!

----------
components: Library (Lib)
messages: 91242
nosy: tomcl
severity: normal
status: open
title: non-empty defaultdict .copy()  fails returning empty dict
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6637>
_______________________________________

From report at bugs.python.org  Tue Aug  4 02:02:24 2009
From: report at bugs.python.org (Kevin Quick)
Date: Tue, 04 Aug 2009 00:02:24 +0000
Subject: [New-bugs-announce] [issue6638] optparse parse_args argument
	references wrong
In-Reply-To: <1249344144.51.0.386987314322.issue6638@psf.upfronthosting.co.za>
Message-ID: <1249344144.51.0.386987314322.issue6638@psf.upfronthosting.co.za>


New submission from Kevin Quick <kq1quick at gmail.com>:

In optparse description of "16.4.3.7. Parsing arguments" (http://
docs.python.org/library/optparse.html#parsing-arguments) the keyword 
argument to parse_args is "values=None" but in the description of the 
"options" return value and in the second sentence of the "Most common 
usage..." paragraph following, it is referred to as the "options" 
argument.

----------
assignee: georg.brandl
components: Documentation
messages: 91247
nosy: georg.brandl, kq1quick
severity: normal
status: open
title: optparse parse_args argument references wrong
type: resource usage
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6638>
_______________________________________

From report at bugs.python.org  Tue Aug  4 02:09:25 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 04 Aug 2009 00:09:25 +0000
Subject: [New-bugs-announce] [issue6639] turtle: _tkinter.TclError: invalid
	command name	".10170160"
In-Reply-To: <1249344565.24.0.634557720335.issue6639@psf.upfronthosting.co.za>
Message-ID: <1249344565.24.0.634557720335.issue6639@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

I tried the following turtle program; it was taking some time to 
draw .. so I pressed C-c after which I saw the exception traceback.

> cat play.py 
from turtle import *

def f(length, depth):
   if depth == 0:
     forward(length)
   else:
     f(length/3, depth-1)
     right(60)
     f(length/3, depth-1)
     left(120)
     f(length/3, depth-1)
     right(60)
     f(length/3, depth-1)

f(500, 4)

> python play.py
Traceback (most recent call last):
  File "/Users/sridharr/as/pypm/bin/python", line 41, in <module>
    execfile(sys.argv[0])
  File "play.py", line 15, in <module>
    f(500, 4)
  File "play.py", line 11, in f
    f(length/3, depth-1)
  File "play.py", line 7, in f
    f(length/3, depth-1)
  File "play.py", line 9, in f
    f(length/3, depth-1)
  File "play.py", line 10, in f
    left(120)
  File "<string>", line 1, in left
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
lib-tk/turtle.py", line 1612, in left
    self._rotate(angle)
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
lib-tk/turtle.py", line 3107, in _rotate
    self._update()
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
lib-tk/turtle.py", line 2562, in _update
    self._update_data()
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
lib-tk/turtle.py", line 2553, in _update_data
    self._pencolor, self._pensize)
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
lib-tk/turtle.py", line 569, in _drawline
    self.cv.coords(lineitem, *cl)
  File "<string>", line 1, in coords
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
lib-tk/Tkinter.py", line 2136, in coords
    self.tk.call((self._w, 'coords') + args)))
_tkinter.TclError: invalid command name ".10170160"
>

----------
components: Library (Lib)
messages: 91248
nosy: srid
severity: normal
status: open
title: turtle: _tkinter.TclError: invalid command name ".10170160"
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6639>
_______________________________________

From report at bugs.python.org  Tue Aug  4 02:42:34 2009
From: report at bugs.python.org (Myk Melez)
Date: Tue, 04 Aug 2009 00:42:34 +0000
Subject: [New-bugs-announce] [issue6640] urlparse should parse mailto: URL
	headers as query	parameters
In-Reply-To: <1249346554.96.0.279967945769.issue6640@psf.upfronthosting.co.za>
Message-ID: <1249346554.96.0.279967945769.issue6640@psf.upfronthosting.co.za>


New submission from Myk Melez <myk at mozilla.org>:

RFC 2368 <http://www.ietf.org/rfc/rfc2368.txt> specifies mailto: URLs as
having the following syntax:

     mailtoURL  =  "mailto:" [ to ] [ headers ]
     to         =  #mailbox
     headers    =  "?" header *( "&" header )
     header     =  hname "=" hvalue
     hname      =  *urlc
     hvalue     =  *urlc

The header fields in these URLs are roughly analogous to query
parameters in other URLs, but urlparse treats them as part of the path
(along with the email address):

>>> import urlparse
>>> urlparse.urlparse("mailto:foo at example.com?subject=hi")
ParseResult(scheme='mailto', netloc='',
path='foo at example.com?subject=hi', params='', query='', fragment='')

It should treat them as query parameters instead, which would not only
make it easier to access them but would also make it easier to access
the email address, since one would no longer have to parse headers, if
any, out of the path first.

----------
components: Library (Lib)
messages: 91249
nosy: mykmelez
severity: normal
status: open
title: urlparse should parse mailto: URL headers as query parameters
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6640>
_______________________________________

From report at bugs.python.org  Tue Aug  4 16:04:37 2009
From: report at bugs.python.org (Esteban Feldman)
Date: Tue, 04 Aug 2009 14:04:37 +0000
Subject: [New-bugs-announce] [issue6641] strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>


New submission from Esteban Feldman <esteban.feldman at gmail.com>:

When trying to use datetime.strptime %z directive got an unexpected error.

>>> from datetime import datetime
>>> 
>>> fecha = u'Sun Aug 02 19:01:25 +0000 2009'
>>> datetime.strptime(fecha, '%a %b %d %H:%M:%S %z %Y')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/_strptime.py", line 317, in _strptime
    (bad_directive, format))
ValueError: 'z' is a bad directive in format '%a %b %d %H:%M:%S %z %Y'

----------
components: None
messages: 91256
nosy: Eka
severity: normal
status: open
title: strptime doesn't support %z format ?
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Tue Aug  4 20:21:50 2009
From: report at bugs.python.org (Reid Kleckner)
Date: Tue, 04 Aug 2009 18:21:50 +0000
Subject: [New-bugs-announce] [issue6642] returning after forking a child
	thread doesn't call	Py_Finalize
In-Reply-To: <1249410110.52.0.861898541816.issue6642@psf.upfronthosting.co.za>
Message-ID: <1249410110.52.0.861898541816.issue6642@psf.upfronthosting.co.za>


New submission from Reid Kleckner <rnk at mit.edu>:

I attached a test case to reproduce.

Here is what it does:
- The main thread in the parent process starts a new thread and waits
for it.
- The child thread forks.
- The child process creates a daemon thread, and returns.
- The parent process (in the thread that forked) calls os.waitpid(childpid).

What should happen is that the forked child process should terminate
because it shouldn't wait for the daemon thread, and
os.waitpid(childpid) should return after that, and then the main thread
should return from thread.join().

What happens is that because it was a child thread that forked, the C
stack starts inside of the pthread wrapper (or equivalent) instead of
main.  So when child process returns, it doesn't know that it is now the
main thread, and it doesn't execute Py_Finalize.  Furthermore, pthreads
doesn't call sys_exit_group because it thinks that it is a lone thread
returning, and it doesn't want to terminate the entire process group. 
When you look at it with 'ps f', this is what it looks like:

24325 pts/3    Ss     0:01 bash
 4453 pts/3    Sl     0:00  \_ ./python thread_fork_hang.py
 4459 pts/3    Zl     0:07  |   \_ [python] <defunct>
 4467 pts/3    R+     0:00  \_ ps f

Here's the stack traces from the parent process:
(gdb) bt 
#0  0x00007ffff7bd0991 in sem_wait () from /lib/libpthread.so.0
#1  0x0000000000587abd in PyThread_acquire_lock (lock=0x12bb680,
waitflag=1) at ../../unladen2/Python/thread_pthread.h:349
#2  0x00000000005b1660 in lock_PyThread_acquire_lock
(self=0x7ffff7f37150, args=<value optimized out>)
    at ../../unladen2/Modules/threadmodule.c:46
#3  0x000000000055b89d in _PyEval_CallFunction (stack_pointer=0x128ff20,
na=<value optimized out>, nk=0) at ../../unladen2/Python/eval.cc:4046
#4  0x000000000055644c in PyEval_EvalFrame (f=0x128fd60) at
../../unladen2/Python/eval.cc:2518
#5  0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7ef9670,
globals=0x1, locals=0x2, args=0x123bbd8, argcount=1, kws=0x123bbe0,
kwcount=0, 
    defs=0x7ffff7e540e8, defcount=1, closure=0x0) at
../../unladen2/Python/eval.cc:3093
#6  0x000000000055b7b0 in _PyEval_CallFunction (stack_pointer=0x123bbe0,
na=1, nk=0) at ../../unladen2/Python/eval.cc:4188
#7  0x000000000055644c in PyEval_EvalFrame (f=0x123ba40) at
../../unladen2/Python/eval.cc:2518
#8  0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7efea30,
globals=0x1, locals=0x2, args=0x12038c8, argcount=1, kws=0x12038d0,
kwcount=0, 
    defs=0x7ffff7e54368, defcount=1, closure=0x0) at
../../unladen2/Python/eval.cc:3093
#9  0x000000000055b7b0 in _PyEval_CallFunction (stack_pointer=0x12038d0,
na=1, nk=0) at ../../unladen2/Python/eval.cc:4188
#10 0x000000000055644c in PyEval_EvalFrame (f=0x1203750) at
../../unladen2/Python/eval.cc:2518
#11 0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7f55d50,
globals=0x0, locals=0x0, args=0x0, argcount=0, kws=0x0, kwcount=0,
defs=0x0, 
    defcount=0, closure=0x0) at ../../unladen2/Python/eval.cc:3093
#12 0x000000000055bc02 in PyEval_EvalCode (co=0x12bb680, globals=0x80,
locals=0x0) at ../../unladen2/Python/eval.cc:552
#13 0x000000000057deb1 in PyRun_FileExFlags (fp=0x1121260,
filename=0x7fffffffe6be "thread_fork_hang.py", start=<value optimized out>, 
    globals=0x10fa010, locals=0x10fa010, closeit=1,
flags=0x7fffffffe290) at ../../unladen2/Python/pythonrun.c:1359
#14 0x000000000057e167 in PyRun_SimpleFileExFlags (fp=0x1121260,
filename=0x7fffffffe6be "thread_fork_hang.py", closeit=1,
flags=0x7fffffffe290)
    at ../../unladen2/Python/pythonrun.c:955
#15 0x00000000004d8954 in Py_Main (argc=-134459232, argv=<value
optimized out>) at ../../unladen2/Modules/main.c:695
#16 0x00007ffff6cdf1c4 in __libc_start_main () from /lib/libc.so.6
#17 0x00000000004d7ae9 in _start ()
(gdb) thread 2
[Switching to thread 2 (Thread 0x40800950 (LWP 4458))]#0 
0x00007ffff7bd234f in waitpid () from /lib/libpthread.so.0
(gdb) bt
#0  0x00007ffff7bd234f in waitpid () from /lib/libpthread.so.0
#1  0x00000000005b6adf in posix_waitpid (self=<value optimized out>,
args=<value optimized out>) at ../../unladen2/Modules/posixmodule.c:5797
#2  0x000000000055b89d in _PyEval_CallFunction (stack_pointer=0x129cff8,
na=<value optimized out>, nk=0) at ../../unladen2/Python/eval.cc:4046
#3  0x000000000055644c in PyEval_EvalFrame (f=0x129ce60) at
../../unladen2/Python/eval.cc:2518
#4  0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7f558f0,
globals=0x0, locals=0x0, args=0x7ffff7f98068, argcount=0, kws=0x1239f70, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at
../../unladen2/Python/eval.cc:3093
#5  0x00000000005d98fc in function_call (func=0x7ffff7eefc80,
arg=0x7ffff7f98050, kw=0x1286d20) at ../../unladen2/Objects/funcobject.c:524
#6  0x00000000004dc68d in PyObject_Call (func=0x7ffff7eefc80,
arg=0x7ffff7f98050, kw=0x1286d20) at ../../unladen2/Objects/abstract.c:2487
#7  0x00000000005549d0 in _PyEval_CallFunctionVarKw
(stack_pointer=0x129ce08, num_posargs=<value optimized out>, num_kwargs=0, 
    flags=<value optimized out>) at ../../unladen2/Python/eval.cc:45
#8  0x0000000000559de2 in PyEval_EvalFrame (f=0x129cc80) at
../../unladen2/Python/eval.cc:2560
#9  0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7efe710,
globals=0x1, locals=0x1, args=0x11f1478, argcount=1, kws=0x11f1480,
kwcount=0, 
    defs=0x0, defcount=0, closure=0x0) at ../../unladen2/Python/eval.cc:3093
#10 0x000000000055b7b0 in _PyEval_CallFunction (stack_pointer=0x11f1480,
na=1, nk=0) at ../../unladen2/Python/eval.cc:4188
#11 0x000000000055644c in PyEval_EvalFrame (f=0x11f12e0) at
../../unladen2/Python/eval.cc:2518
#12 0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7efe850,
globals=0x1, locals=0x1, args=0x11f1290, argcount=1, kws=0x11f1298,
kwcount=0, 
    defs=0x0, defcount=0, closure=0x0) at ../../unladen2/Python/eval.cc:3093
#13 0x000000000055b7b0 in _PyEval_CallFunction (stack_pointer=0x11f1298,
na=1, nk=0) at ../../unladen2/Python/eval.cc:4188
#14 0x000000000055644c in PyEval_EvalFrame (f=0x11f1110) at
../../unladen2/Python/eval.cc:2518
#15 0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7efe7b0,
globals=0x1, locals=0x1, args=0x7ffff7ee9fe8, argcount=1, kws=0x0,
kwcount=0, 
    defs=0x0, defcount=0, closure=0x0) at ../../unladen2/Python/eval.cc:3093
#16 0x00000000005d97fd in function_call (func=0x7ffff7e55ed8,
arg=0x7ffff7ee9fd0, kw=0x0) at ../../unladen2/Objects/funcobject.c:524
#17 0x00000000004dc68d in PyObject_Call (func=0x7ffff7e55ed8,
arg=0x7ffff7ee9fd0, kw=0x0) at ../../unladen2/Objects/abstract.c:2487
#18 0x00000000004e3bff in instancemethod_call (func=0x7ffff7e55ed8,
arg=0x7ffff7ee9fd0, kw=0x0) at ../../unladen2/Objects/classobject.c:2579
#19 0x00000000004dc68d in PyObject_Call (func=0x7ffff7f3c640,
arg=0x7ffff7f98050, kw=0x0) at ../../unladen2/Objects/abstract.c:2487
#20 0x0000000000553530 in PyEval_CallObjectWithKeywords
(func=0x7ffff7f3c640, arg=0x7ffff7f98050, kw=0x0) at
../../unladen2/Python/eval.cc:45
#21 0x00000000005b1a6d in t_bootstrap (boot_raw=0x125b300) at
../../unladen2/Modules/threadmodule.c:425
#22 0x00007ffff7bca3f7 in start_thread () from /lib/libpthread.so.0
#23 0x00007ffff6d98b3d in clone () from /lib/libc.so.6
#24 0x0000000000000000 in ?? ()

The child process is defunct, but you can still trace the left over
thread with and attach to that with GDB if you guess the process id.  I
couldn't figure out how to get ps to tell it to me, though.  Here's that
trace:

(gdb) bt
#0  0x0000000000558412 in PyEval_EvalFrame (f=0x1245190) at
../../unladen2/Python/eval.cc:2336
#1  0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7fce7b0,
globals=0x0, locals=0x0, args=0x7ffff7f98068, argcount=0, kws=0x10eb600, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at
../../unladen2/Python/eval.cc:3093
#2  0x00000000005d98fc in function_call (func=0x7ffff7e56d70,
arg=0x7ffff7f98050, kw=0x123ba90) at ../../unladen2/Objects/funcobject.c:524
#3  0x00000000004dc68d in PyObject_Call (func=0x7ffff7e56d70,
arg=0x7ffff7f98050, kw=0x123ba90) at ../../unladen2/Objects/abstract.c:2487
#4  0x00000000005549d0 in _PyEval_CallFunctionVarKw
(stack_pointer=0x1245138, num_posargs=<value optimized out>, num_kwargs=0, 
    flags=<value optimized out>) at ../../unladen2/Python/eval.cc:45
#5  0x0000000000559de2 in PyEval_EvalFrame (f=0x1244fb0) at
../../unladen2/Python/eval.cc:2560
#6  0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7efe710,
globals=0x1, locals=0x1, args=0x1244ee8, argcount=1, kws=0x1244ef0,
kwcount=0, 
    defs=0x0, defcount=0, closure=0x0) at ../../unladen2/Python/eval.cc:3093
#7  0x000000000055b7b0 in _PyEval_CallFunction (stack_pointer=0x1244ef0,
na=1, nk=0) at ../../unladen2/Python/eval.cc:4188
#8  0x000000000055644c in PyEval_EvalFrame (f=0x1244d50) at
../../unladen2/Python/eval.cc:2518
#9  0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7efe850,
globals=0x1, locals=0x1, args=0x1247c00, argcount=1, kws=0x1247c08,
kwcount=0, 
    defs=0x0, defcount=0, closure=0x0) at ../../unladen2/Python/eval.cc:3093
#10 0x000000000055b7b0 in _PyEval_CallFunction (stack_pointer=0x1247c08,
na=1, nk=0) at ../../unladen2/Python/eval.cc:4188
#11 0x000000000055644c in PyEval_EvalFrame (f=0x1247a80) at
../../unladen2/Python/eval.cc:2518
#12 0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7efe7b0,
globals=0x1, locals=0x1, args=0x7ffff7ef0528, argcount=1, kws=0x0,
kwcount=0, 
    defs=0x0, defcount=0, closure=0x0) at ../../unladen2/Python/eval.cc:3093
#13 0x00000000005d97fd in function_call (func=0x7ffff7e55ed8,
arg=0x7ffff7ef0510, kw=0x0) at ../../unladen2/Objects/funcobject.c:524
#14 0x00000000004dc68d in PyObject_Call (func=0x7ffff7e55ed8,
arg=0x7ffff7ef0510, kw=0x0) at ../../unladen2/Objects/abstract.c:2487
#15 0x00000000004e3bff in instancemethod_call (func=0x7ffff7e55ed8,
arg=0x7ffff7ef0510, kw=0x0) at ../../unladen2/Objects/classobject.c:2579
#16 0x00000000004dc68d in PyObject_Call (func=0x7ffff7f53230,
arg=0x7ffff7f98050, kw=0x0) at ../../unladen2/Objects/abstract.c:2487
#17 0x0000000000553530 in PyEval_CallObjectWithKeywords
(func=0x7ffff7f53230, arg=0x7ffff7f98050, kw=0x0) at
../../unladen2/Python/eval.cc:45
#18 0x00000000005b1a6d in t_bootstrap (boot_raw=0x1273e60) at
../../unladen2/Modules/threadmodule.c:425
#19 0x00007ffff7bca3f7 in start_thread () from /lib/libpthread.so.0
#20 0x00007ffff6d98b3d in clone () from /lib/libc.so.6
#21 0x0000000000000000 in ?? ()
(gdb) pystack
thread_fork_hang.py (15): daemon
Current language:  auto; currently c
Current language:  auto; currently c++
/home/rnk/unladen2/Lib/threading.py (481): run
/home/rnk/unladen2/Lib/threading.py (523): __bootstrap_inner
/home/rnk/unladen2/Lib/threading.py (498): __bootstrap
Current language:  auto; currently c
Current language:  auto; currently c++
Current language:  auto; currently c

You can see that it's stuck in the daemon's busy loop from the test case.

So what's the right way to fix this?  Should Py_Finalize be called for
the child?  The problem is that if the parent process registers cleanup
code via the atexit module or something, it might be run twice, once in
the parent and once in the child.  However, it's closer to the semantics
of fork, and I'd say that's what you get for using it.  Most people
still using fork are probably just turning around and exec'ing anyway.

I'm willing to write the fix if we can agree on a solution.

----------
components: Library (Lib)
files: thread_fork_hang.py
messages: 91263
nosy: rnk
severity: normal
status: open
title: returning after forking a child thread doesn't call Py_Finalize
versions: Python 3.2
Added file: http://bugs.python.org/file14646/thread_fork_hang.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6642>
_______________________________________

From report at bugs.python.org  Tue Aug  4 20:56:49 2009
From: report at bugs.python.org (Reid Kleckner)
Date: Tue, 04 Aug 2009 18:56:49 +0000
Subject: [New-bugs-announce] [issue6643] joining a child that forks can
	deadlock in the forked	child process
In-Reply-To: <1249412209.9.0.200329347238.issue6643@psf.upfronthosting.co.za>
Message-ID: <1249412209.9.0.200329347238.issue6643@psf.upfronthosting.co.za>


New submission from Reid Kleckner <rnk at mit.edu>:

This bug is similar to the importlock deadlock, and it's really part of
a larger problem that you should release all locks before you fork. 
However, we can fix this in the threading module directly by freeing and
resetting the locks on the main thread after a fork.

I've attached a test case that inserts calls to sleep at the right
places to make the following occur:
- Main thread spawns a worker thread.
- Main thread joins worker thread.
- To join, the main thread acquires the lock on the condition variable
(worker.__block.acquire()).
== switch to worker ==
- Worker thread forks.
== switch to child process ==
- Worker thread, which is now the only thread in the process, returns.
- __bootstrap_inner calls self.__stop() to notify any other threads
waiting for it that it returned.
- __stop() tries to acquire self.__block, which has been left in an
acquired state, so the child process hangs here.
== switch to worker in parent process ==
- Worker thread calls os.waitpid(), which hangs, since the child never
returns.

So there's the deadlock.

I think I should be able to fix it just by resetting the condition
variable lock and any other locks hanging off the only thread left
standing after the fork.

----------
components: Library (Lib)
files: forkjoindeadlock.py
messages: 91265
nosy: rnk
severity: normal
status: open
title: joining a child that forks can deadlock in the forked child process
versions: Python 2.6
Added file: http://bugs.python.org/file14647/forkjoindeadlock.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6643>
_______________________________________

From report at bugs.python.org  Tue Aug  4 21:19:56 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 04 Aug 2009 19:19:56 +0000
Subject: [New-bugs-announce] [issue6644] cmathmodule.c: Extra comma in enum
	- fails on AIX
In-Reply-To: <1249413596.71.0.0983950331585.issue6644@psf.upfronthosting.co.za>
Message-ID: <1249413596.71.0.0983950331585.issue6644@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

Please the remove extra comma in Modules/cmathmodule.c

64 :	 	 	eimes enum special_types {
65 :	 	 	eimes 	ST_NINF,	/* 0, negative infinity 
*/
66 :	 	 	eimes 	ST_NEG,		/* 1, negative finite 
number (nonzero) */
67 :	 	 	eimes 	ST_NZERO,	/* 2, -0. */
68 :	 	 	eimes 	ST_PZERO,	/* 3, +0. */
69 :	 	 	eimes 	ST_POS,		/* 4, positive finite 
number (nonzero) */
70 :	 	 	eimes 	ST_PINF,	/* 5, positive infinity 
*/
71 :	 	 	eimes 	ST_NAN,		/* 6, Not a Number */
72 :	 	 	eimes };

To see why this is necessary, peruse a similar issue reported earlier: 
http://bugs.python.org/issue5889

----------
components: Build, Extension Modules
messages: 91267
nosy: christian.heimes, srid
severity: normal
status: open
title: cmathmodule.c: Extra comma in enum - fails on AIX
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6644>
_______________________________________

From report at bugs.python.org  Tue Aug  4 21:27:33 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 04 Aug 2009 19:27:33 +0000
Subject: [New-bugs-announce] [issue6645] multiprocessing build fails on AIX
	- /dev/urandom (or	equivalent) not found
In-Reply-To: <1249414053.16.0.904107656211.issue6645@psf.upfronthosting.co.za>
Message-ID: <1249414053.16.0.904107656211.issue6645@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

./Modules/ld_so_aix cc_r -qlanglvl=ansi -bI:Modules/python.exp build/
temp.aix-5.1-2.6/home/apy/rrun/build/activ
epython-DEV/build/py2_6_2-aix-powerpc-apyee26-rrun/python/Modules/
_multiprocessing/multiprocessing.o build/temp
.aix-5.1-2.6/home/apy/rrun/build/activepython-DEV/build/py2_6_2-aix-
powerpc-apyee26-rrun/python/Modules/_multip
rocessing/socket_connection.o build/temp.aix-5.1-2.6/home/apy/rrun/
build/activepython-DEV/build/py2_6_2-aix-pow
erpc-apyee26-rrun/python/Modules/_multiprocessing/semaphore.o -o build/
lib.aix-5.1-2.6/_multiprocessing.so
*** WARNING: importing extension "_multiprocessing" failed with <type 
'exceptions.NotImplementedError'>: /dev/u
random (or equivalent) not found

----------
components: Build, Extension Modules
messages: 91270
nosy: srid
severity: normal
status: open
title: multiprocessing build fails on AIX - /dev/urandom (or equivalent) not found
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6645>
_______________________________________

From report at bugs.python.org  Wed Aug  5 03:42:45 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 05 Aug 2009 01:42:45 +0000
Subject: [New-bugs-announce] [issue6646] test_pickle fails on AIX --
	6.9999999999999994e-308 !=	6.9999999999999984e-308
In-Reply-To: <1249436565.63.0.933597089559.issue6646@psf.upfronthosting.co.za>
Message-ID: <1249436565.63.0.933597089559.issue6646@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

test test_pickle failed -- errors occurred; run in verbose mode for 
details
test_pickletools
test test_pickletools failed -- Traceback (most recent call last):
  File "/home/apy/rrun/tmp/autotest/apy/lib/python2.6/test/
pickletester.py", line 546, in test_float
    self.assertEqual(value, got)
AssertionError: 6.9999999999999994e-308 != 6.9999999999999984e-308

----------
components: Tests
messages: 91292
nosy: srid
severity: normal
status: open
title: test_pickle fails on AIX -- 6.9999999999999994e-308 != 6.9999999999999984e-308
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6646>
_______________________________________

From report at bugs.python.org  Wed Aug  5 06:53:01 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 05 Aug 2009 04:53:01 +0000
Subject: [New-bugs-announce] [issue6647] warnings.catch_warnings is not
	thread-safe
In-Reply-To: <1249447980.99.0.321429613778.issue6647@psf.upfronthosting.co.za>
Message-ID: <1249447980.99.0.321429613778.issue6647@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

warnings.catch_warnings is a context manager supposed to save and 
restore warnings filters, and optionally record all warnings issued.

But it does so in a completely thread-unsafe way, by replacing the 
module's "showwarning" and "filters" attributes on enter, and restoring 
them on exit. If the __enter__ / __exit__ calls of two threads overlap, 
after leaving the last block the warnings state is not the same as the 
original state, as it should be.

I don't know how to fix this, other than using locks (that could block 
indefinitely) or severely restricting how catch_warnings may be used. 
At least, this issue should be documented.

----------
components: Library (Lib)
files: error-warnings.py
messages: 91301
nosy: gagenellina
severity: normal
status: open
title: warnings.catch_warnings is not thread-safe
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14654/error-warnings.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6647>
_______________________________________

From report at bugs.python.org  Wed Aug  5 17:48:49 2009
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 05 Aug 2009 15:48:49 +0000
Subject: [New-bugs-announce] [issue6648] codecs documentation does not
	mention surrogateescape
In-Reply-To: <1249487329.19.0.991009276368.issue6648@psf.upfronthosting.co.za>
Message-ID: <1249487329.19.0.991009276368.issue6648@psf.upfronthosting.co.za>


New submission from Nikolaus Rath <Nikolaus at rath.org>:

On http://docs.python.org/3.1/library/codecs.html it says that

----
Possible values for errors are 'strict' (raise an exception in case of
an encoding error), 'replace' (replace malformed data with a suitable
replacement marker, such as '?'), 'ignore' (ignore malformed data and
continue without further notice), 'xmlcharrefreplace' (replace with the
appropriate XML character reference (for encoding only)) and
'backslashreplace' (replace with backslashed escape sequences (for
encoding only)) as well as any other error handling name defined via
register_error().
-----

shouldn't the 'surrogateescape' error handler from
http://docs.python.org/3.1/library/os.html#file-names-command-line-arguments-and-environment-variables
be mentioned here as well?

----------
assignee: georg.brandl
components: Documentation
messages: 91321
nosy: Nikratio, georg.brandl
severity: normal
status: open
title: codecs documentation does not mention surrogateescape
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6648>
_______________________________________

From report at bugs.python.org  Wed Aug  5 18:21:09 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 05 Aug 2009 16:21:09 +0000
Subject: [New-bugs-announce] [issue6649] idlelib/rpc.py missing exit status
	on exithook
In-Reply-To: <1249489269.49.0.307291234061.issue6649@psf.upfronthosting.co.za>
Message-ID: <1249489269.49.0.307291234061.issue6649@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

SocketIO.exithook on idlelib/rpc.py is missing the exit status, this is
a minor issue since both client and server used on IDLE override this
method to do something else.

----------
components: IDLE
files: missing_exitstatus.diff
keywords: patch
messages: 91322
nosy: gpolo
priority: low
severity: normal
status: open
title: idlelib/rpc.py missing exit status on exithook
versions: Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14658/missing_exitstatus.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6649>
_______________________________________

From report at bugs.python.org  Wed Aug  5 19:14:39 2009
From: report at bugs.python.org (Torne Wuff)
Date: Wed, 05 Aug 2009 17:14:39 +0000
Subject: [New-bugs-announce] [issue6650] sre_parse contains a confusing
	generic error message
In-Reply-To: <1249492479.55.0.250174703511.issue6650@psf.upfronthosting.co.za>
Message-ID: <1249492479.55.0.250174703511.issue6650@psf.upfronthosting.co.za>


New submission from Torne Wuff <torne-pythonbugs at wolfpuppy.org.uk>:

sre_parse raises an exception with the message "syntax error" - very
generic and confusing - in the case where something that looks like a
lookbehind assertion is invalid.

>>> import re
>>> re.match('(?<foo>.*)', 'foo')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/re.py", line 137, in match
    return _compile(pattern, flags).match(string)
  File "/usr/lib/python2.5/re.py", line 241, in _compile
    raise error, v # invalid expression
sre_constants.error: syntax error

This example is a typo for '(?P<foo>.*)' :)

This is the only case in sre_parse where the message "syntax error" is
used - the others are much more descriptive. Attached patch changes it
to "bad lookbehind assertion type: %s" for python 2.x head; should be
applied to 3.x also.

----------
components: Regular Expressions
files: sre_error_msg.diff
keywords: patch
messages: 91324
nosy: torne
severity: normal
status: open
title: sre_parse contains a confusing generic error message
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14659/sre_error_msg.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6650>
_______________________________________

From report at bugs.python.org  Wed Aug  5 21:23:12 2009
From: report at bugs.python.org (Erick Tryzelaar)
Date: Wed, 05 Aug 2009 19:23:12 +0000
Subject: [New-bugs-announce] [issue6651] Py3k's posixpath.relpath not
	compatible with	ntpath.relpath
In-Reply-To: <1249500192.85.0.26357988262.issue6651@psf.upfronthosting.co.za>
Message-ID: <1249500192.85.0.26357988262.issue6651@psf.upfronthosting.co.za>


New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:

It looks like Python 3.x's relpath isn't compatible between posixpath
and ntpath. In posixpath.relpath, the start keyword defaults to None,
but ntpath.relpath, the start keyword defaults to curdir.

Interestingly enough, 2.6 and 2.7 have a different implementation of
posixpath.relpath, where it explicitly sets the start to equal curdir,
just like ntpath does.

----------
components: Library (Lib)
messages: 91327
nosy: erickt
severity: normal
status: open
title: Py3k's posixpath.relpath not compatible with ntpath.relpath
type: performance
versions: Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6651>
_______________________________________

From report at bugs.python.org  Wed Aug  5 21:47:09 2009
From: report at bugs.python.org (Phillip M. Feldman)
Date: Wed, 05 Aug 2009 19:47:09 +0000
Subject: [New-bugs-announce] [issue6652] missing cmath functions
In-Reply-To: <1249501629.27.0.648462584075.issue6652@psf.upfronthosting.co.za>
Message-ID: <1249501629.27.0.648462584075.issue6652@psf.upfronthosting.co.za>


New submission from Phillip M. Feldman <pfeldman at verizon.net>:

The online documentation describes functions cmath.phase and
cmath.polar, but when I try to import these, I get "cannot import name"
errors.

----------
assignee: georg.brandl
components: Documentation
messages: 91330
nosy: georg.brandl, pfeldman at verizon.net
severity: normal
status: open
title: missing cmath functions
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6652>
_______________________________________

From report at bugs.python.org  Wed Aug  5 22:23:52 2009
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 05 Aug 2009 20:23:52 +0000
Subject: [New-bugs-announce] [issue6653] Potential memory leak in
	multiprocessing
In-Reply-To: <1249503832.66.0.0114205396453.issue6653@psf.upfronthosting.co.za>
Message-ID: <1249503832.66.0.0114205396453.issue6653@psf.upfronthosting.co.za>


New submission from Jesse Noller <jnoller at gmail.com>:

I have example code to show this. It creates a system-wide memory leak 
on Linux/Unix (present until the next reboot), unless the last statement 
in the target of mp.Process ensures a manual clean up of the globals.

The problem is line 353 in multiprocessing/forking.py. The function 
exit() is defined as os._exit on Linux and ExitProcess on Windows, none 
of which allows normal clean up.

>>> help(os._exit)
Help on built-in function _exit in module nt:

_exit(...)
   _exit(status)

   Exit to the system with specified status, without normal exit 
processing.


The problem is fixed if line 353 in forking.py is changed from

exit(exitcode)

to

sys.exit(exitcode)




Test run without bugfix:

G:\DEVELO~1\SHARED~2>python test.py
open handle to 569f439b24e24fc8a547b81932616066
[[ 0.  0.  0.  0.]
 [ 0.  0.  0.  0.]]
open handle to 0582d4b161c546f582c1c96e7bd0c39d
open handle to 569f439b24e24fc8a547b81932616066
modified array
closed handle to 569f439b24e24fc8a547b81932616066
[[ 1.  1.  1.  0.]
 [ 1.  1.  1.  0.]]
closed handle to 569f439b24e24fc8a547b81932616066


You can see here that opening and closing of handles are unmatched. This 
is on Windows, where the kernel ensures the clean-up, so it may not 
matter. But on Unix this would have created a permament (system wide) 
memory leak! What is happening here is globals not being cleaned up due 
to the use of os._exit instead of sys.exit.


Test run with bugfix:

G:\DEVELO~1\SHARED~2>python test.py
open handle to 930778d27b414253bc329f2b70adaa05
[[ 0.  0.  0.  0.]
 [ 0.  0.  0.  0.]]
open handle to 3f6cebf8c5de413685bb770d02ae9666
open handle to 930778d27b414253bc329f2b70adaa05
modified array
closed handle to 930778d27b414253bc329f2b70adaa05
closed handle to 3f6cebf8c5de413685bb770d02ae9666
[[ 1.  1.  1.  0.]
 [ 1.  1.  1.  0.]]
closed handle to 930778d27b414253bc329f2b70adaa05



Now all allocations and deallocations are matched.


Regards,
Sturla Molden

----------
files: test.zip
messages: 91332
nosy: jnoller
severity: normal
status: open
title: Potential memory leak in multiprocessing
Added file: http://bugs.python.org/file14660/test.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6653>
_______________________________________

From report at bugs.python.org  Wed Aug  5 23:16:40 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 05 Aug 2009 21:16:40 +0000
Subject: [New-bugs-announce] [issue6654] Add "path" to the xmrlpc dispatcher
	method
In-Reply-To: <1249507000.5.0.428139109569.issue6654@psf.upfronthosting.co.za>
Message-ID: <1249507000.5.0.428139109569.issue6654@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

I've created http://codereview.appspot.com/100046 on Rietveld:
by passing the "path" component of the xmlrpc request to the dispatch 
method, it
becomes possible to dispatch differently according to this.  This patch 
provides
that addition.  Additionally, it provides an MultiPathXMLRPCDispatcher 
mixin
class and a MultiPathXMLRPCServer that uses it, to have multiple 
dispatchers for
different paths.
This allows a single server port to serve different XMLRPC servers as
differentiated by the HTTP path.  A test is also preovided.

I've also prophylacticly emailed this to phython-ideas.

----------
components: Library (Lib)
messages: 91337
nosy: krisvale
severity: normal
status: open
title: Add "path" to the xmrlpc dispatcher method
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6654>
_______________________________________

From report at bugs.python.org  Thu Aug  6 05:35:20 2009
From: report at bugs.python.org (Dj Gilcrease)
Date: Thu, 06 Aug 2009 03:35:20 +0000
Subject: [New-bugs-announce] [issue6655] etree iterative find[text]
In-Reply-To: <1249529720.45.0.62463367335.issue6655@psf.upfronthosting.co.za>
Message-ID: <1249529720.45.0.62463367335.issue6655@psf.upfronthosting.co.za>


New submission from Dj Gilcrease <digitalxero at gmail.com>:

I recently converted a project from using a custom  implementation of 
xml.dom.minidom to using EelemntTree that comes with python2.5+ and 
found myself wishing for a find(tag_or_path) method that would do so iteratively instead of just on the current elements direct children. 
This is possible with the code as written;

looking_for = None
for el in etree.getiterator(tag_or_path):
    looking_for = el
    break

I have to do this type of action so often in my code that I just decided 
to grab the python implementation of etree that came with py2.6 and 
include it with my app and patch in an iter_find method as the instant 
break for loop is just asking for maintenance issues down the road what 
I forget why I was breaking on the first loop no matter what.

----------
components: XML
files: ElementTree.py.patch
keywords: patch
messages: 91348
nosy: Digitalxero
severity: normal
status: open
title: etree iterative find[text]
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file14663/ElementTree.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6655>
_______________________________________

From report at bugs.python.org  Thu Aug  6 13:09:38 2009
From: report at bugs.python.org (Christoph Burgmer)
Date: Thu, 06 Aug 2009 11:09:38 +0000
Subject: [New-bugs-announce] [issue6656] locale.format_string fails on
	escaped percentage
In-Reply-To: <1249556978.14.0.317265689402.issue6656@psf.upfronthosting.co.za>
Message-ID: <1249556978.14.0.317265689402.issue6656@psf.upfronthosting.co.za>


New submission from Christoph Burgmer <cburgmer at ira.uka.de>:

locale.format_string doesn't return same result as a normal
"string" % format
directive, but raises a TypeError. See attached test case for Python
2.6.

>>> locale.format_string('%f%%', 1.0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/locale.py", line 195, in format_string
    return new_f % val
TypeError: not enough arguments for format string
>>> '%f%%' % 1.0
'1.000000%'

----------
components: Library (Lib)
files: locale_percents_test.diff
keywords: patch
messages: 91352
nosy: christoph
severity: normal
status: open
title: locale.format_string fails on escaped percentage
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14665/locale_percents_test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6656>
_______________________________________

From report at bugs.python.org  Thu Aug  6 13:18:55 2009
From: report at bugs.python.org (Sheepherd)
Date: Thu, 06 Aug 2009 11:18:55 +0000
Subject: [New-bugs-announce] [issue6657] Copy documentation section
In-Reply-To: <1249557535.14.0.530083384684.issue6657@psf.upfronthosting.co.za>
Message-ID: <1249557535.14.0.530083384684.issue6657@psf.upfronthosting.co.za>


New submission from Sheepherd <sheepherd2k at hotmail.com>:

The enumerated part in about the exact usage of the conversion specifier
in "String Formatting Operations"
http://docs.python.org/library/stdtypes.html#string-formatting should be
copied to http://docs.python.org/library/string.html#formatspec to make
the usage of the specifier clear.

----------
assignee: georg.brandl
components: Documentation
messages: 91354
nosy: Sheepherd, georg.brandl
severity: normal
status: open
title: Copy documentation section
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6657>
_______________________________________

From report at bugs.python.org  Thu Aug  6 13:47:47 2009
From: report at bugs.python.org (Alexey Shamrin)
Date: Thu, 06 Aug 2009 11:47:47 +0000
Subject: [New-bugs-announce] [issue6658] typo in buffer api docs
In-Reply-To: <1249559267.03.0.842450307551.issue6658@psf.upfronthosting.co.za>
Message-ID: <1249559267.03.0.842450307551.issue6658@psf.upfronthosting.co.za>


New submission from Alexey Shamrin <shamrin at gmail.com>:

Typo in PyObject_GetBuffer docs: "...handle all the complexibity..."

Links:

http://docs.python.org/c-api/buffer.html#buffer-related-functions
http://docs.python.org/dev/c-api/buffer.html#buffer-related-functions
http://docs.python.org/3.1/c-api/buffer.html#buffer-related-functions
http://docs.python.org/dev/py3k/c-api/buffer.html#buffer-related-functions

----------
assignee: georg.brandl
components: Documentation
messages: 91355
nosy: ash, georg.brandl
severity: normal
status: open
title: typo in buffer api docs
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6658>
_______________________________________

From report at bugs.python.org  Thu Aug  6 14:07:36 2009
From: report at bugs.python.org (Alexey Shamrin)
Date: Thu, 06 Aug 2009 12:07:36 +0000
Subject: [New-bugs-announce] [issue6659] buffer c-api: memoryview object
	documentation
In-Reply-To: <1249560456.01.0.11537088321.issue6659@psf.upfronthosting.co.za>
Message-ID: <1249560456.01.0.11537088321.issue6659@psf.upfronthosting.co.za>


New submission from Alexey Shamrin <shamrin at gmail.com>:

"A memoryview object is an extended buffer object that could replace the
buffer object (but doesn?t have to as that could be kept as a simple 1-d
memoryview object)."

Well, buffer object was dropped Python 3, wasn't it?

http://docs.python.org/dev/py3k/c-api/buffer.html#memoryview-objects
http://docs.python.org/3.1/c-api/buffer.html#memoryview-objects

----------
assignee: georg.brandl
components: Documentation
messages: 91357
nosy: ash, georg.brandl
severity: normal
status: open
title: buffer c-api: memoryview object documentation
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6659>
_______________________________________

From report at bugs.python.org  Thu Aug  6 19:49:44 2009
From: report at bugs.python.org (kee nethery)
Date: Thu, 06 Aug 2009 17:49:44 +0000
Subject: [New-bugs-announce] [issue6660] Desire python.org documentation
	link to user contribution	wiki (per function)
In-Reply-To: <1249580984.63.0.922866340136.issue6660@psf.upfronthosting.co.za>
Message-ID: <1249580984.63.0.922866340136.issue6660@psf.upfronthosting.co.za>


New submission from kee nethery <kee at kagi.com>:

Proposal: For each permalink headline in the official documentation, 
link to a wiki page specific to that headline. Allow users to easily 
view and contribute comments and examples around that specific 
documentation headline. For example:
http://docs.python.org/reference/lexical_analysis.html#string-literal-
concatenation
would have an auto-generated link in the main docs of (for example):
http://wiki.docs.python.org/2.6.2#reference#lexical_analysis.html#string
-literal-concatenation
Easy to create, self administering, perhaps valuable to new users, 
completely unofficial.

Newbies need examples, lots of examples. Newbies have noob questions 
about things they are stumbling across that experienced users have 
forgotten was once confusing. For experienced users that knowledge is 
now part of their Python DNA. According to people on the "python-list" 
other languages have wiki style user contribution areas that allow 
newbies to document the things they found confusing (and the answers) 
and to provide lots of code examples. Periodically this newbie 
information is rolled back into the official mainline docs. Requiring 
newbies to join this tracking system and to submit bugs is just way to 
complex for something that is now trivial to do with a wiki and it 
obviously causes the new user contributions to be pretty non-existent. 
Python would be a much easier language to learn if newbies could easily 
contribute through the main documentation web site.

----------
assignee: georg.brandl
components: Documentation
messages: 91373
nosy: georg.brandl, keenethery, nnorwitz
severity: normal
status: open
title: Desire python.org documentation link to user contribution wiki (per function)
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6660>
_______________________________________

From report at bugs.python.org  Thu Aug  6 22:10:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Aug 2009 20:10:48 +0000
Subject: [New-bugs-announce] [issue6661] Transient test_multiprocessing
	failure
In-Reply-To: <1249589448.92.0.976190766506.issue6661@psf.upfronthosting.co.za>
Message-ID: <1249589448.92.0.976190766506.issue6661@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I just got the following test_multiprocessing error (cannot reproduce,
though):

test test_multiprocessing failed -- Traceback (most recent call last):
  File
"/home/antoine/cpython/seek-6629/Lib/test/test_multiprocessing.py", line
232, in test_active_children
    self.assertTrue(p in self.active_children())
AssertionError: False is not True

----------
assignee: jnoller
components: Library (Lib), Tests
messages: 91383
nosy: jnoller, pitrou
priority: normal
severity: normal
status: open
title: Transient test_multiprocessing failure
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6661>
_______________________________________

From report at bugs.python.org  Fri Aug  7 03:25:10 2009
From: report at bugs.python.org (Dave Day)
Date: Fri, 07 Aug 2009 01:25:10 +0000
Subject: [New-bugs-announce] [issue6662] HTMLParser.HTMLParser doesn't
	handle malformed charrefs
In-Reply-To: <1249608310.39.0.325559183765.issue6662@psf.upfronthosting.co.za>
Message-ID: <1249608310.39.0.325559183765.issue6662@psf.upfronthosting.co.za>


New submission from Dave Day <dayveday at gmail.com>:

When HTMLParser.HTMLParser encounters a malformed charref (for example 
&#bad;) it no longer parsers the following HTML correctly.

For example:
  <p>&#bad;</p>
Recognises the starttag "p" but considers the rest to be data.

To reproduce:
class MyParser(HTMLParser.HTMLParser):
  def handle_starttag(self, tag, attrs):
    print 'Start "%s"' % tag
  def handle_endtag(self,tag):
    print 'End "%s"' % tag
  def handle_charref(self, ref):
    print 'Charref "%s"' % ref
  def handle_data(self, data):
    print 'Data "%s"' % data
parser = MyParser()
parser.feed('<p>&#bad;</p>')
parser.close()

Expected output:
Start "p"
Data "&#bad;"
End "p"

Actual output:
Start "p"
Data "&#bad;</p>"

----------
components: Library (Lib)
messages: 91392
nosy: dayveday
severity: normal
status: open
title: HTMLParser.HTMLParser doesn't handle malformed charrefs
type: behavior
versions: Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6662>
_______________________________________

From report at bugs.python.org  Fri Aug  7 08:00:14 2009
From: report at bugs.python.org (Phillip M. Feldman)
Date: Fri, 07 Aug 2009 06:00:14 +0000
Subject: [New-bugs-announce] [issue6663] re.findall does not always return a
	list of strings
In-Reply-To: <1249624814.45.0.837975483748.issue6663@psf.upfronthosting.co.za>
Message-ID: <1249624814.45.0.837975483748.issue6663@psf.upfronthosting.co.za>


New submission from Phillip M. Feldman <pfeldman at verizon.net>:

As per the Python documentation, the following regular expression should
produce a list containing the strings '6.7', 7.33', and '9':

re.findall('(-?\d+[.]\d+)|(-?\d+[.]?)|(-?[.]\d+)', 'asdf6.7jjjj7.33ff9')

Instead, it generates a list of tuples.  Either the documentation should
be changed to make it consistent with what re.findall is actually doing,
or, better yet, re.findall should be fixed.

----------
components: Regular Expressions
messages: 91393
nosy: pfeldman at verizon.net
severity: normal
status: open
title: re.findall does not always return a list of strings
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6663>
_______________________________________

From report at bugs.python.org  Fri Aug  7 11:14:15 2009
From: report at bugs.python.org (Neil Hodgson)
Date: Fri, 07 Aug 2009 09:14:15 +0000
Subject: [New-bugs-announce] [issue6664] readlines should understand Line
	Separator and Paragraph	Separator characters
In-Reply-To: <1249636455.06.0.336549280075.issue6664@psf.upfronthosting.co.za>
Message-ID: <1249636455.06.0.336549280075.issue6664@psf.upfronthosting.co.za>


New submission from Neil Hodgson <nyamatongwe at users.sourceforge.net>:

Unicode includes Line Separator U+2028 and Paragraph Separator U+2029
line ending characters. The readlines method of the file object returned
by the built-in open does not treat these characters as line ends
although the object returned by codecs.open(..., encoding='utf-8') does.

The attached program creates a UTF-8 file containing three lines with
the second line ended with a Paragraph Separator. The program then reads
this file back in as a text file. Only two lines are seen when reading
the file back in.

The desired behaviour is for the file to be read in as three lines.

----------
components: IO
files: lineends.py
messages: 91397
nosy: nyamatongwe
severity: normal
status: open
title: readlines should understand Line Separator and Paragraph Separator characters
versions: Python 3.1
Added file: http://bugs.python.org/file14671/lineends.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6664>
_______________________________________

From report at bugs.python.org  Fri Aug  7 11:49:19 2009
From: report at bugs.python.org (Josef Skladanka)
Date: Fri, 07 Aug 2009 09:49:19 +0000
Subject: [New-bugs-announce] [issue6665] fnmatch fails on filenames
	containing \n character
In-Reply-To: <1249638559.7.0.0574356115412.issue6665@psf.upfronthosting.co.za>
Message-ID: <1249638559.7.0.0574356115412.issue6665@psf.upfronthosting.co.za>


New submission from Josef Skladanka <jskladan at redhat.com>:

Hello,
at the moment, fnmatch.fnmatch() will fail to match any string, which
has \n character. This of course breaks glob as well.

Example

> import fnmatch
> fnmatch.fnmatch("foo\nbar", "foo*")
False

> import glob
> open("foobar", "w").close()
> open("foo\nbar", "w").close()
> glob.glob("foo*")
['foobar']

while the expected result is ['foobar', 'foo\nbar']. The standard C
fnmatch function from fnmatch.h is behaving correctly i.e. this code
will print out "match!"

#include <fnmatch.h>
#include <stdio.h>

int main()
{
    if (fnmatch("foo*", "foo\nbar", FNM_NOESCAPE) == 0)
        printf("match!\n");
    else
        printf("fail!\n");
    return 0;
}


This misbehaviour is caused by the fnmatch.translate() which adds $ to
the end of the regexp. Without the ending $ the fnmatch function works OK.

----------
components: Library (Lib)
messages: 91398
nosy: rajcze
severity: normal
status: open
title: fnmatch fails on filenames containing \n character
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6665>
_______________________________________

From report at bugs.python.org  Fri Aug  7 11:50:15 2009
From: report at bugs.python.org (Bogdan Opanchuk)
Date: Fri, 07 Aug 2009 09:50:15 +0000
Subject: [New-bugs-announce] [issue6666] List of dirs to ignore in trace.py
	is applied only for	the first file
In-Reply-To: <1249638615.65.0.163009414102.issue6666@psf.upfronthosting.co.za>
Message-ID: <1249638615.65.0.163009414102.issue6666@psf.upfronthosting.co.za>


New submission from Bogdan Opanchuk <bg at bk.ru>:

When creating a trace.Trace object or running trace.py one can specify
list of directories to ignore (ignoredirs or --ignore-dir
correspondingly). It is passed to trace.Ignore constructor, which stores
iterator to map(), applied to this list, in self._dirs. So, when
Ignore.names() execution passes to the block "for d in self._dirs:" for
the first time, iterator saves its state (in the end of the list) and
next times the code in this block is completely ignored. The result is
that 'ignoredirs' parameter does not actually work (except for the one
lucky file).

Proposed patch is attached.

----------
components: Library (Lib)
files: trace.diff
keywords: patch
messages: 91399
nosy: bogdan.opanchuk
severity: normal
status: open
title: List of dirs to ignore in trace.py is applied only for the first file
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file14672/trace.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6666>
_______________________________________

From report at bugs.python.org  Fri Aug  7 11:53:29 2009
From: report at bugs.python.org (maro)
Date: Fri, 07 Aug 2009 09:53:29 +0000
Subject: [New-bugs-announce] [issue6667] logging config - using
	FileHandler's delay argument?
In-Reply-To: <1249638809.81.0.11088299207.issue6667@psf.upfronthosting.co.za>
Message-ID: <1249638809.81.0.11088299207.issue6667@psf.upfronthosting.co.za>


New submission from maro <misgis at gmail.com>:

I'm not sure, if it's an issue. I don't know how to use argument 'delay'
of FileHandler in my logging.conf file.

[handler_tarFileHandler]
class=FileHandler
level=DEBUG
formatter=simpleFormatter
args=('/tmp/_tar2ncConverter.log','a+')
delay=True # file is created only when first message is emited (delay =
True), not working, empty file is always created...

If I put delay to FileHandler's constructor args
('/tmp/_tar2ncConverter.log','a+',None,True) I get error message about
missing arguments. It is an issue, or just my wrong arranged args?

regards 
maro

----------
components: None
messages: 91400
nosy: maro
severity: normal
status: open
title: logging config - using FileHandler's delay argument?
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6667>
_______________________________________

From report at bugs.python.org  Fri Aug  7 16:34:34 2009
From: report at bugs.python.org (Vlada Peric)
Date: Fri, 07 Aug 2009 14:34:34 +0000
Subject: [New-bugs-announce] [issue6668] locale.py: can't parse sr_RS@latin
	locale
In-Reply-To: <1249655674.35.0.635015975428.issue6668@psf.upfronthosting.co.za>
Message-ID: <1249655674.35.0.635015975428.issue6668@psf.upfronthosting.co.za>


New submission from Vlada Peric <vlada.peric at gmail.com>:

The sr_RS locale in glibc corresponds to the Cyrillic script, while the 
agreed upon locale for the Latin alphabet is sr_RS at latin. Unfortunately, 
the locale python module crashes when trying to parse this locale. Here 
is the traceback:

File "/usr/lib/python2.6/locale.py", line 497, in get locale
  return _parse_localename(localename)
File "usr/lib/python2.6/locale.py", line 410, in _parse_localename
  raise ValueError, 'unknown locale: %s' % localename

Looking at the code, it only checks for the @euro modifier and ignores 
all other modifiers (including @latin). This is all when I set 
LANG=sr_RS at latin. If I use LANG=sr_RS.UTF8 at latin (also allowed by 
glibc), Python interprets this as the sr_RS locale (which is wrong, as 
that is for Cyrillic).

----------
components: Unicode
messages: 91404
nosy: VPeric
severity: normal
status: open
title: locale.py: can't parse sr_RS at latin locale
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6668>
_______________________________________

From report at bugs.python.org  Fri Aug  7 23:11:16 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 07 Aug 2009 21:11:16 +0000
Subject: [New-bugs-announce] [issue6669] TarFile.getmembers fails at
	struct.unpack: unpack	requires a string argument of length 4
In-Reply-To: <1249679476.65.0.0604043126333.issue6669@psf.upfronthosting.co.za>
Message-ID: <1249679476.65.0.0604043126333.issue6669@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

Perhaps this must be wrapped under a programmer-expected custom 
exception class (TarError maybe)

    for tarinfo in tarfileobj.getmembers():
  File "/home/apy/ActivePython-2.6/lib/python2.6/tarfile.py", line 
1791, in getmembers
    self._load()        # all members, we first have to
  File "/home/apy/ActivePython-2.6/lib/python2.6/tarfile.py", line 
2352, in _load
    tarinfo = self.next()
  File "/home/apy/ActivePython-2.6/lib/python2.6/tarfile.py", line 
2307, in next
    self.fileobj.seek(self.offset)
  File "/home/apy/ActivePython-2.6/lib/python2.6/gzip.py", line 382, in 
seek
    self.read(1024)
  File "/home/apy/ActivePython-2.6/lib/python2.6/gzip.py", line 219, in 
read
    self._read(readsize)
  File "/home/apy/ActivePython-2.6/lib/python2.6/gzip.py", line 267, in 
_read
    self._read_eof()
  File "/home/apy/ActivePython-2.6/lib/python2.6/gzip.py", line 300, in 
_read_eof
    crc32 = read32(self.fileobj)
  File "/home/apy/ActivePython-2.6/lib/python2.6/gzip.py", line 24, in 
read32
    return struct.unpack("<I", input.read(4))[0]
error: unpack requires a string argument of length 4

----------
components: Library (Lib)
messages: 91412
nosy: srid
severity: normal
status: open
title: TarFile.getmembers fails at struct.unpack: unpack requires a string argument of length 4
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6669>
_______________________________________

From report at bugs.python.org  Sat Aug  8 21:50:06 2009
From: report at bugs.python.org (brimac)
Date: Sat, 08 Aug 2009 19:50:06 +0000
Subject: [New-bugs-announce] [issue6670] Printing the 'The Python Tutorial'
In-Reply-To: <1249761006.45.0.422242383232.issue6670@psf.upfronthosting.co.za>
Message-ID: <1249761006.45.0.422242383232.issue6670@psf.upfronthosting.co.za>


New submission from brimac <brimac at bcs.org>:

I am having a problem when printing 'The Python Tutorial' at
http://docs.python.org/tutorial/
I am using XP and Firefox and an HP Laserjet.
The page displays OK but the printout has a 68 mm margin on the left.
The margin on the right is 18 mm but the text is cut off, sometimes
mid-letter. The other 14 pages in the tutorial have the same problem.
I've tried changing from Portrait to Landscape. The text gets wider, the
margins are the same size, and the text is still cut off.
I have not noticed this with any other documents, on this website or
elsewhere. I'm sure if you print/preview you will see the problem.
My guess is that there is a fault with the printout file at python.org

----------
assignee: georg.brandl
components: Documentation
messages: 91422
nosy: brimac, georg.brandl
severity: normal
status: open
title: Printing the 'The Python Tutorial'
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6670>
_______________________________________

From report at bugs.python.org  Sun Aug  9 12:35:25 2009
From: report at bugs.python.org (Aliaksandr Stelmachonak)
Date: Sun, 09 Aug 2009 10:35:25 +0000
Subject: [New-bugs-announce] [issue6671] webbrowser.py doesn't respect xfce
	default browser
In-Reply-To: <1249814125.92.0.530552321419.issue6671@psf.upfronthosting.co.za>
Message-ID: <1249814125.92.0.530552321419.issue6671@psf.upfronthosting.co.za>


New submission from Aliaksandr Stelmachonak <mail.avatar at gmail.com>:

Currently webbrowser.py only trying to use GNOME and KDE default browser 
setting. This patch adds launching Xfce default browser if xfce environment detected.

----------
components: Library (Lib)
files: webbrowser.py.patch
keywords: patch
messages: 91426
nosy: ava1ar
severity: normal
status: open
title: webbrowser.py doesn't respect xfce default browser
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14678/webbrowser.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6671>
_______________________________________

From report at bugs.python.org  Sun Aug  9 14:24:50 2009
From: report at bugs.python.org (=?utf-8?q?Jan_Schl=C3=BCter?=)
Date: Sun, 09 Aug 2009 12:24:50 +0000
Subject: [New-bugs-announce] [issue6672] Add Mingw recognition to pyport.h
	to allow building	extensions
In-Reply-To: <1249820690.51.0.767085753138.issue6672@psf.upfronthosting.co.za>
Message-ID: <1249820690.51.0.767085753138.issue6672@psf.upfronthosting.co.za>


New submission from Jan Schl?ter <python-bugs at jan-schlueter.de>:

This addresses missing statements for recognizing the Mingw compiler in 
pyport.h, needed to build several extension modules on Windows using 
Mingw. I will first explain the background, then indicate what needs to 
be changed and end with some pointers to "related work".

Pyport.h of Python 2.5 and 2.6 (I do not have other versions to check) 
addresses an issue with Cygwin's gcc by preventing the declaration of 
"__declspec(dllimport)" for function definitions (using the PyAPI_FUNC
(RTYPE) makro), relying on the compiler's auto-import definition 
instead, because the compiler would not otherwise throw an "initializer 
element is not constant" error when using e.g. PyObject_GenericGetAttr 
in a PyTypeObject declaration of a C/C++ extension module (more 
generally, whenever an imported Python API function is used as a 
constant).
Python 2.6.2 (r262:71605) and Python 2.5.4 (r254:67916) do not check 
for the Mingw compiler in pyport.h, although Mingw behaves the same as 
the Cygwin version, at least regarding the "__declspec" declaration.

To fix that, each check for __CYGWIN__ in pyport.h should also check 
for __MINGW32___ to behave the same way. svn.python.org currently does 
not reply, so I can not create a patch against the trunk nor check 
whether this issue has already been addressed.

Issue 5046 included a patch to pyport.h fixing this, but it has been 
rejected due to other suggested changes that were not mature.
http://recipes.gobolinux.org/r/?list=Python&ver=3.1-
r1&file=arm/20061116160247-
bf48b-7db78fe2f80b3137ce349cf4314364768555ff50.gz.diff suggests the 
same change.
http://www.indashpc.org/vbullettin/viewtopic.php?p=5003#5003 gives some 
more background information on how I found and fixed the problem.
An internet search for "python initializer element is not constant" 
shows that numerous people have been encountering this problem when 
trying to build a python extension module.

----------
components: Build
messages: 91427
nosy: f0k
severity: normal
status: open
title: Add Mingw recognition to pyport.h to allow building extensions
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6672>
_______________________________________

From report at bugs.python.org  Sun Aug  9 16:09:45 2009
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 09 Aug 2009 14:09:45 +0000
Subject: [New-bugs-announce] [issue6673] Py3.1 hangs in coroutine and eats
	up all memory
In-Reply-To: <1249826985.41.0.2934011008.issue6673@psf.upfronthosting.co.za>
Message-ID: <1249826985.41.0.2934011008.issue6673@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

Here's a simple coroutine that works perfectly in Python 2.6 but seems
to let Py3.1 enter an infinite loop that ends up eating all memory.

-----------------
def printing_sink():
    "A simple sink that prints the received values."
    while True:
        print( (yield) )

def chunker(chunk_size, target):
    """Receives single items and forwards chunks of a fixed size.

    Usage example:
    >>> sink = printing_sink()
    >>> next(sink)
    >>> cr = chunker(4, sink)
    >>> next(cr)

    >>> for i in range(8):
    ...    cr.send(i)
    [0, 1, 2, 3]
    [4, 5, 6, 7]
    >>> cr.close()
    """
    while True:
        target.send([ (yield) for i in range(chunk_size) ])

if __name__ == '__main__':
    import doctest
    doctest.testmod()
-----------------

Fails on:
Python 3.1 (r31:73572, Jun 28 2009, 21:07:35)
[GCC 4.3.2] on linux2

Works on:
Python 2.6.2 (r262:71600, Apr 17 2009, 11:29:30)
[GCC 4.3.2] on linux2

The problem seems to be the list comprehension. When I replace it with a
normal for-loop, it works perfectly.

----------
components: Interpreter Core
messages: 91428
nosy: scoder
severity: normal
status: open
title: Py3.1 hangs in coroutine and eats up all memory
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6673>
_______________________________________

From report at bugs.python.org  Mon Aug 10 12:35:16 2009
From: report at bugs.python.org (Shashi Gowda)
Date: Mon, 10 Aug 2009 10:35:16 +0000
Subject: [New-bugs-announce] [issue6674] Fatal error: deallocating None
In-Reply-To: <1249900516.3.0.450252107319.issue6674@psf.upfronthosting.co.za>
Message-ID: <1249900516.3.0.450252107319.issue6674@psf.upfronthosting.co.za>


New submission from Shashi Gowda <connect2shashi at gmail.com>:

I'm using the megahal mh_python module to make a bot instance learn from
a several 100 files. The code works as it should for 4-6 files before
crashing with this error message "Fatal error: deallocating None" There
isn't much documentation on this anywhere.

----------
components: Interpreter Core
files: learn.py
messages: 91438
nosy: shashi
severity: normal
status: open
title: Fatal error: deallocating None
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file14681/learn.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6674>
_______________________________________

From report at bugs.python.org  Mon Aug 10 15:44:25 2009
From: report at bugs.python.org (D Hardy)
Date: Mon, 10 Aug 2009 13:44:25 +0000
Subject: [New-bugs-announce] [issue6675] inf == inf (wrong IEEE 754
	behaviour)
In-Reply-To: <1249911865.84.0.497315252674.issue6675@psf.upfronthosting.co.za>
Message-ID: <1249911865.84.0.497315252674.issue6675@psf.upfronthosting.co.za>


New submission from D Hardy <diggory.hardy at gmail.com>:

Currently python evaluates infinity as equal to itself in my tests (2.6.2 and 3.0.1+
from ubuntu). I'm not entirely sure whether the behaviour of 'inf == inf' is specified
by IEEE 754, but it leads to results like:

>>> 1e400
inf
>>> 1e400 == 1e500
True

And hence unittests which use tests like

if not (math.fabs(value1 - value2) <= 0.00000001 *
max(math.fabs(value1),math.fabs(value2))):
    fail

don't always fail when they should (when a value is inf).

This is a specific example (and probably not the recommended way of testing
values in any case), but I think "inf != inf" is generally considered the correct
behaviour. (Although maybe this is left over from the PEP 42 / PEP 754 mess; I
wasn't able to find the current status of implementing IEEE 754 behaviour in
python.)

----------
components: None
messages: 91443
nosy: Cyborg16
severity: normal
status: open
title: inf == inf (wrong IEEE 754 behaviour)
type: behavior
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6675>
_______________________________________

From report at bugs.python.org  Mon Aug 10 18:23:25 2009
From: report at bugs.python.org (Matthew)
Date: Mon, 10 Aug 2009 16:23:25 +0000
Subject: [New-bugs-announce] [issue6676] expat parser throws Memory Error
	when parsing multiple	files
In-Reply-To: <1249921405.95.0.689815480815.issue6676@psf.upfronthosting.co.za>
Message-ID: <1249921405.95.0.689815480815.issue6676@psf.upfronthosting.co.za>


New submission from Matthew <webmaster at adurosolutions.com>:

I'm using the Expat python interface to parse multiple XML files in an
application and have found that it throws a "Memory Error" exception if
multiple calls are made to xmlparser.ParseFile(file) on the same
xmlparser object. This occurs even with a vanilla xmlparser object
created with xml.parsers.expat.ParserCreate().

Python Version: 2.6.2
Operating System: Ubuntu

----------
components: XML
files: expat-error.py
messages: 91452
nosy: realpolitik
severity: normal
status: open
title: expat parser throws Memory Error when parsing multiple files
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14684/expat-error.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6676>
_______________________________________

From report at bugs.python.org  Mon Aug 10 19:09:52 2009
From: report at bugs.python.org (Mike Cowperthwaite)
Date: Mon, 10 Aug 2009 17:09:52 +0000
Subject: [New-bugs-announce] [issue6677] Place the term "delete" within the
	documentation for	os.remove() and os.rmdir()
In-Reply-To: <1249924192.93.0.340979032094.issue6677@psf.upfronthosting.co.za>
Message-ID: <1249924192.93.0.340979032094.issue6677@psf.upfronthosting.co.za>


New submission from Mike Cowperthwaite <mikec at lathropengineering.com>:

"Remove" and "unlink" are not the most widely-known verbs that come
to mind when thinking about deleting objects from the filesystem.
A recent Google search for "python delete file" led to the documentation
for the 'os' module:
  http://docs.python.org/library/os.html
but searching within that page for "delet" completely misses
os.remove(), os.unlink(), and os.rmdir().

Suggest simply expanding the first sentence of os.remove()'s paragraph to:
   Remove the file /path/ (delete the file).

Similarly for os.rmdir():
   Remove the directory /path/ (delete the directory).

Also regarding os.rmdir(), it would be nice to add a mention here of
this information from os.walk(): "rmdir() doesn?t allow deleting a
directory before the directory is empty."

The URL above is for the 2.6 version (chapter 16.1.4); also seen in the
3.1 documentation (15.1.5); presumably it's also in the development
versions.  Patching backwards as far as feasible would be appreciated.

----------
assignee: georg.brandl
components: Documentation
messages: 91456
nosy: georg.brandl, mcow
severity: normal
status: open
title: Place the term "delete" within the documentation for os.remove() and os.rmdir()
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6677>
_______________________________________

From report at bugs.python.org  Mon Aug 10 20:25:01 2009
From: report at bugs.python.org (William Mill)
Date: Mon, 10 Aug 2009 18:25:01 +0000
Subject: [New-bugs-announce] [issue6678] inspect.currentframe documentation
	omits optional depth	parameter
In-Reply-To: <1249928701.73.0.0206445902812.issue6678@psf.upfronthosting.co.za>
Message-ID: <1249928701.73.0.0206445902812.issue6678@psf.upfronthosting.co.za>


New submission from William Mill <bill.mill at gmail.com>:

help(inspect.currentframe) reads:

---------------------------------
_getframe(...)
    _getframe([depth]) -> frameobject

Return a frame object from the call stack.  If optional integer depth is
given, return the frame object that many calls below the top of the
stack. If that is deeper than the call stack, ValueError is raised.  The
default for depth is zero, returning the frame at the top of the call stack.
        
This function should be used for internal and specialized
purposes only.
-------------------------------

The python library documentation, however, doesn't mention the optional
depth parameter:

-------------------------------
inspect.currentframe()
    Return the frame object for the caller?s stack frame.
-------------------------------

I think substituting the help() text for the library documentation's
text would be an improvement.

----------
assignee: georg.brandl
components: Documentation
messages: 91459
nosy: georg.brandl, llimllib
severity: normal
status: open
title: inspect.currentframe documentation omits optional depth parameter
type: feature request
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6678>
_______________________________________

From report at bugs.python.org  Mon Aug 10 22:10:38 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 10 Aug 2009 20:10:38 +0000
Subject: [New-bugs-announce] [issue6679] obsolete paragraph in re doc for
	re.sub
In-Reply-To: <1249935038.17.0.324286013964.issue6679@psf.upfronthosting.co.za>
Message-ID: <1249935038.17.0.324286013964.issue6679@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

The documentation of re.sub states:

"The pattern may be a string or an RE object; if you need to specify
regular expression flags, you must use a RE object, or use embedded
modifiers in a pattern; for example, sub("(?i)b+", "x", "bbbb BBBB")
returns 'x x'."

but there is now a flags argument so that paragraph should be deleted.

----------
assignee: georg.brandl
components: Documentation
messages: 91461
nosy: MLModel, georg.brandl
severity: normal
status: open
title: obsolete paragraph in re doc for re.sub
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6679>
_______________________________________

From report at bugs.python.org  Tue Aug 11 00:47:23 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 10 Aug 2009 22:47:23 +0000
Subject: [New-bugs-announce] [issue6680] Python 3.1 fails to build when db.h
	contains non-UTF-8	characters
In-Reply-To: <1249944443.54.0.496415697007.issue6680@psf.upfronthosting.co.za>
Message-ID: <1249944443.54.0.496415697007.issue6680@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

Python 3.1 fails to build when db.h contains non-UTF-8 characters.
Python 3.1 checks for db.h even though Python 3 doesn't contain bsddb
module.

See also https://bugs.gentoo.org/show_bug.cgi?id=280001

Please at least apply the attached patch, or completely remove check
for db.h.

----------
components: Build
files: python-3.1-setup.py.patch
keywords: patch
messages: 91465
nosy: Arfrever
severity: normal
status: open
title: Python 3.1 fails to build when db.h contains non-UTF-8 characters
versions: Python 3.1
Added file: http://bugs.python.org/file14688/python-3.1-setup.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6680>
_______________________________________

From report at bugs.python.org  Tue Aug 11 00:58:34 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 10 Aug 2009 22:58:34 +0000
Subject: [New-bugs-announce] [issue6681] email.parser clips trailing \n of
	multipart/mixed part if	part ends in \r\n
In-Reply-To: <1249945114.19.0.529736934099.issue6681@psf.upfronthosting.co.za>
Message-ID: <1249945114.19.0.529736934099.issue6681@psf.upfronthosting.co.za>


New submission from Guido van Rossum <guido at python.org>:

I am using an edge case of multipart/mixed and find that the
multipart/mix parser in the email package is broken.  See attached
example.  Similar code using cgi.FieldStorage (!) works fine.

The problem happens through the following combination of factors:

1. Content-Length given
2. Content-Transfer-Encoding: 8bit
3. Last two bytes of the part body are '\r\n'

In this case, the final '\n' is removed from the part body, leaving it a
byte short.  Note that interior occurrences of '\r\n' work fine, as does
any other binary data -- it's only a trailing '\r\n' that breaks.

Note that technically perhaps the use of 8bit is invalid; but the same
problem happens when using binary instead.

The problem can be reproduced in Python 3.x using nearly the same demo
by change the cStringIO import to "import io".

----------
components: Library (Lib)
files: barry.py
messages: 91466
nosy: gvanrossum
severity: normal
status: open
title: email.parser clips trailing \n of multipart/mixed part if part ends in \r\n
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14689/barry.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6681>
_______________________________________

From report at bugs.python.org  Tue Aug 11 16:26:31 2009
From: report at bugs.python.org (Anders Blomdell)
Date: Tue, 11 Aug 2009 14:26:31 +0000
Subject: [New-bugs-announce] [issue6682] Default traceback does not handle
	PEP302 loaded modules
In-Reply-To: <1250000791.92.0.10910978351.issue6682@psf.upfronthosting.co.za>
Message-ID: <1250000791.92.0.10910978351.issue6682@psf.upfronthosting.co.za>


New submission from Anders Blomdell <anders.blomdell at control.lth.se>:

While trying to get a PEP302 import hook to function properly, I found
that the default traceback picks up the wrong sourcecode for PEP302
loaded modules.

The testcase pep302_traceback.py tries to emulate the behavior of the
files in ordinary, which generates the following output when run:

  (cd ordinary ; python2.6.2 main.py )   

  A.__name__= a
  B.__name__ a.b
  Traceback (most recent call last):
    File "main.py", line 6, in <module>
      a.A()
  File "/tmp/ordinary/a/__init__.py", line 6, in __init__
    b.B()
  File "/tmp/ordinary/a/b/__init__.py", line 4, in __init__
    raise Exception()
  Exception

But when i run the testcase, I get the following:

  python2.6.2 pep302_traceback.py 
  ### Show possible bug in default linecache (works in 2.6.2)
  A.__name__= a
  B.__name__= a.b
  Traceback (most recent call last):
    File "pep302_traceback.py", line 82, in <module>
      i.load_module("__main__")
    File "pep302_traceback.py", line 58, in load_module
      exec(code, mod.__dict__)
    File "<__main__.Importer>/main.py", line 6, in <module>
      a.A()
    File "<__main__.Importer>/a/__init__.py", line 6, in __init__
      b.B()
    File "<__main__.Importer>/a/b/__init__.py", line 4, in __init__
      raise Exception()
  Exception
  ### Show possible bug in default traceback (does not work in 2.6.2)
  A.__name__= a
  B.__name__= a.b
  Traceback (most recent call last):
    File "pep302_traceback.py", line 88, in <module>
      i.load_module("__main__")
    File "pep302_traceback.py", line 58, in load_module
      exec(code, mod.__dict__)
    File "<__main__.Importer>/main.py", line 6, in <module>
      # main.py picked up from somewhere in sys.path
    File "<__main__.Importer>/a/__init__.py", line 6, in __init__
      # __init__.py picked up from somewhere in sys.path
    File "<__main__.Importer>/a/b/__init__.py", line 4, in __init__
      # __init__.py picked up from somewhere in sys.path
  Exception

I.e. in python 2.6 the linecache module correctly picks up PEP302 loaded
code, while the default traceback picks up any source file from sys.path
that happens to match the name of the file that generated the exception.
When run with python2.5.2, the linecache module also locates the wrong
file from sys.path.

----------
components: Interpreter Core
files: bug.tar
messages: 91475
nosy: anders.blomdell at control.lth.se
severity: normal
status: open
title: Default traceback does not handle PEP302 loaded modules
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14692/bug.tar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6682>
_______________________________________

From report at bugs.python.org  Tue Aug 11 18:17:16 2009
From: report at bugs.python.org (Eric Shubert)
Date: Tue, 11 Aug 2009 16:17:16 +0000
Subject: [New-bugs-announce] [issue6683] smtplib authentication - try all
	mechanisms
In-Reply-To: <1250007436.58.0.446313092376.issue6683@psf.upfronthosting.co.za>
Message-ID: <1250007436.58.0.446313092376.issue6683@psf.upfronthosting.co.za>


New submission from Eric Shubert <python at shubes.net>:

The login method in smtplib.py tries only one authentication mechanism.
There are legitimate situations where cram-md5 might fail, yet plain or
login would succeed.

RFC2554 states:
  If an AUTH command fails, the client may try another authentication
  mechanism by issuing another AUTH command.

The login method should attempt all mechanisms in preferred_auths before
returning a failure. This will make the code more robust, returning a
failure only when absolutely no authentication is possible.

----------
messages: 91478
nosy: shubes
severity: normal
status: open
title: smtplib authentication - try all mechanisms
type: behavior
versions: Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6683>
_______________________________________

From report at bugs.python.org  Tue Aug 11 18:44:30 2009
From: report at bugs.python.org (mrjbq7)
Date: Tue, 11 Aug 2009 16:44:30 +0000
Subject: [New-bugs-announce] [issue6684] "x / 1" and "x * 1" should return x
In-Reply-To: <1250009070.48.0.664173919374.issue6684@psf.upfronthosting.co.za>
Message-ID: <1250009070.48.0.664173919374.issue6684@psf.upfronthosting.co.za>


New submission from mrjbq7 <mrjbq7 at users.sourceforge.net>:

There are a couple arithmetic operations that idempotent, where the 
returned python object is the same python object as the input.  

For example, given a number:

>>> x = 12345

The abs() builtin returns the same number object if it is already a 
positive value:

>>> id(x)
17124964
>>> id(abs(x))
17124964

The "multiply by zero" operation returns a single "zero" object:

>>> id(x * 0)
16794004
>>> id(x * 0)
16794004

But, the "multiply by 1" or "divide by 1" does not:

>>> id(x * 1)
17124928
>>> id(x * 1)
17124880
>>> id(x / 1)
17203652
>>> id(x / 1)
17124952

----------
messages: 91479
nosy: mrjbq7
severity: normal
status: open
title: "x / 1" and "x * 1" should return x

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6684>
_______________________________________

From report at bugs.python.org  Tue Aug 11 19:56:37 2009
From: report at bugs.python.org (Troy J. Farrell)
Date: Tue, 11 Aug 2009 17:56:37 +0000
Subject: [New-bugs-announce] [issue6685] CGI module documentation references
	method 'toupper'; should be 'upper'
In-Reply-To: <1250013397.33.0.441269604909.issue6685@psf.upfronthosting.co.za>
Message-ID: <1250013397.33.0.441269604909.issue6685@psf.upfronthosting.co.za>


New submission from Troy J. Farrell <troy at entheossoft.com>:

The cgi module references a method 'toupper' on strings which should
really reference 'upper'.  The line is around 211 of cgi.txt, depending
on the version of the documentation.  Search for "`toupper`", (include
the backticks.)

----------
assignee: georg.brandl
components: Documentation
messages: 91481
nosy: georg.brandl, troy
severity: normal
status: open
title: CGI module documentation references method 'toupper'; should be 'upper'
type: feature request
versions: Python 2.6, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6685>
_______________________________________

From report at bugs.python.org  Tue Aug 11 21:19:53 2009
From: report at bugs.python.org (Colin Stewart)
Date: Tue, 11 Aug 2009 19:19:53 +0000
Subject: [New-bugs-announce] [issue6686]
	xml.sax.xmlreader.XMLReader.getProperty	(xml.sax.handler.property_xml_string)
	returns bytes
In-Reply-To: <1250018393.94.0.435666063731.issue6686@psf.upfronthosting.co.za>
Message-ID: <1250018393.94.0.435666063731.issue6686@psf.upfronthosting.co.za>


New submission from Colin Stewart <colin at owlfish.com>:

The documentation for the xml.sax.handler.property_xml_string SAX
property states that it should be "data type: String".  However when
retrieving this value in Python 3.1 it returns a bytes object instead.

This makes handling the returned value very difficult because there is
no method for retrieving the character set encoding that the XML was
originally encoded with.

This is currently blocking the port of SimpleTAL to Python 3 achieving
feature parity with Python 2.

----------
components: XML
messages: 91482
nosy: cms103
severity: normal
status: open
title: xml.sax.xmlreader.XMLReader.getProperty (xml.sax.handler.property_xml_string) returns bytes
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6686>
_______________________________________

From report at bugs.python.org  Tue Aug 11 23:15:32 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 11 Aug 2009 21:15:32 +0000
Subject: [New-bugs-announce] [issue6687] Move the special-case for integer
	objects out of	PyBytes_FromObject.
In-Reply-To: <1250025332.91.0.596662376204.issue6687@psf.upfronthosting.co.za>
Message-ID: <1250025332.91.0.596662376204.issue6687@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti <alexandre at peadrop.com>:

The documentation for PyBytes_FromObject states:

.. cfunction:: PyObject* PyBytes_FromObject(PyObject *o)

   Return the bytes representation of object *o* that implements
   the buffer protocol.

However, there exists a special-case for integer object in
PyBytes_FromObject that makes the function return a null-initialized
bytes object. Currently, this is only used for handling `bytes(10)'.

I don't like changing APIs after a stable release, but I believe this
behaviour is error-prone and surprising (and darn right annoying even).
So, I believe the special-case should be made specific to the bytes
constructor.

Thus, here is the fine patch.

----------
components: Interpreter Core
files: move_int_special_case.diff
keywords: 26backport, patch
messages: 91483
nosy: alexandre.vassalotti
priority: normal
severity: normal
stage: patch review
status: open
title: Move the special-case for integer objects out of PyBytes_FromObject.
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file14693/move_int_special_case.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6687>
_______________________________________

From report at bugs.python.org  Tue Aug 11 23:34:37 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 11 Aug 2009 21:34:37 +0000
Subject: [New-bugs-announce] [issue6688] Optimize PyBytes_FromObject.
In-Reply-To: <1250026477.34.0.625583102893.issue6688@psf.upfronthosting.co.za>
Message-ID: <1250026477.34.0.625583102893.issue6688@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti <alexandre at peadrop.com>:

Optimize PyBytes_FromObject by adding special-cases for list and tuple
objects and by using _PyObject_LengthHint() instead of an arbitrary
value for the size of the initial buffer.

[Without the patch]
./python -m timeit -s "x = list(range(256))" "bytes(x)"
100000 loops, best of 3: 7.19 usec per loop

./python -m timeit -s "x = tuple(range(256))" "bytes(x)"
100000 loops, best of 3: 7.14 usec per loop

./python -m timeit -s "x = list(range(256))*100" "bytes(x)"
1000 loops, best of 3: 591 usec per loop

./python -m timeit -s "x = range(256)" "bytes(x)"
100000 loops, best of 3: 8.45 usec per loop


[With the patch]

./python -m timeit -s "x = list(range(256))" "bytes(x)"
100000 loops, best of 3: 4.43 usec per loop

./python -m timeit -s "x = tuple(range(256))" "bytes(x)"
100000 loops, best of 3: 4.53 usec per loop

./python -m timeit -s "x = list(range(256))*100" "bytes(x)"
1000 loops, best of 3: 335 usec per loop

./python -m timeit -s "x = range(256)" "bytes(x)"
100000 loops, best of 3: 7.56 usec per loop

----------
components: Interpreter Core
files: optimize_bytes_from_object.diff
keywords: patch
messages: 91486
nosy: alexandre.vassalotti
priority: normal
severity: normal
stage: patch review
status: open
title: Optimize PyBytes_FromObject.
type: performance
Added file: http://bugs.python.org/file14694/optimize_bytes_from_object.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6688>
_______________________________________

From report at bugs.python.org  Wed Aug 12 10:33:58 2009
From: report at bugs.python.org (David Fraser)
Date: Wed, 12 Aug 2009 08:33:58 +0000
Subject: [New-bugs-announce] [issue6689] subprocess doesn't pass arguments
	correctly on Linux when	shell=True
In-Reply-To: <1250066038.48.0.373766477997.issue6689@psf.upfronthosting.co.za>
Message-ID: <1250066038.48.0.373766477997.issue6689@psf.upfronthosting.co.za>


New submission from David Fraser <davidf at sjsoft.com>:

(from
http://stackoverflow.com/questions/1253122/why-does-subprocess-popen-with-shelltrue-work-differently-on-linux-vs-windows/1254322)

When using subprocess.Popen(args, shell=True) to run "gcc --version"
(just as an example), on Windows we get this:

>>> from subprocess import Popen
>>> Popen(['gcc', '--version'], shell=True)
gcc (GCC) 3.4.5 (mingw-vista special r3) ...

So it's nicely printing out the version as I expect. But on Linux we get
this:

>>> from subprocess import Popen
>>> Popen(['gcc', '--version'], shell=True)
gcc: no input files

Because gcc hasn't received the --version option.

The docs don't specify exactly what should happen to the args under
Windows, but it does say, on Unix, "If args is a sequence, the first
item specifies the command string, and any additional items will be
treated as additional shell arguments." IMHO the Windows way is better,
because it allows you to treat Popen(arglist) calls the same as
Popen(arglist, shell=True) ones.

The strange implementation is actually the UNIX one, which does the
following (where each space separates a different argument):

/bin/sh -c gcc --version

It looks like the correct implementation (at least on Linux) would be:

/bin/sh -c "gcc --version" gcc --version

Since this would set the command string from the quoted parameters, and
pass the other parameters successfully.

>From the sh man page section for -c:

    Read commands from the command_string operand instead of from the
standard input. Special parameter 0 will be set from the command_name
operand and the positional parameters ($1, $2, etc.) set from the
remaining argument operands.

This patch seems to fairly simply do the trick, as well as testing it.

----------
components: Library (Lib)
files: current-2.6.patch
keywords: patch
messages: 91492
nosy: davidfraser
severity: normal
status: open
title: subprocess doesn't pass arguments correctly on Linux when shell=True
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14697/current-2.6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6689>
_______________________________________

From report at bugs.python.org  Wed Aug 12 23:32:08 2009
From: report at bugs.python.org (Alex)
Date: Wed, 12 Aug 2009 21:32:08 +0000
Subject: [New-bugs-announce] [issue6690] BUILD_SET followed by COMPARE_OP
	(in) can be optimized if	all items are consts
In-Reply-To: <1250112728.26.0.437991636315.issue6690@psf.upfronthosting.co.za>
Message-ID: <1250112728.26.0.437991636315.issue6690@psf.upfronthosting.co.za>


New submission from Alex <alex.gaynor at gmail.com>:

Just like we turn BUILD_LIST; COMPARE_OP (in) into a LOAD_CONST if all
the members are consts, we can do the same for BUILD_SET, instead
turning it into a LOAD_CONST of a frozenset.  The following is the
bytecode that is current produced for each datastructure.

>>> dis.dis(lambda o: o in (1,2,3))
  1           0 LOAD_FAST                0 (o) 
              3 LOAD_CONST               3 ((1, 2, 3)) 
              6 COMPARE_OP               6 (in) 
              9 RETURN_VALUE         
>>> dis.dis(lambda o: o in [1,2,3])
  1           0 LOAD_FAST                0 (o) 
              3 LOAD_CONST               3 ((1, 2, 3)) 
              6 COMPARE_OP               6 (in) 
              9 RETURN_VALUE         
>>> dis.dis(lambda o: o in {1,2,3})
  1           0 LOAD_FAST                0 (o) 
              3 LOAD_CONST               0 (1) 
              6 LOAD_CONST               1 (2) 
              9 LOAD_CONST               2 (3) 
             12 BUILD_SET                3 
             15 COMPARE_OP               6 (in) 
             18 RETURN_VALUE

----------
components: Interpreter Core
messages: 91506
nosy: alex
severity: normal
status: open
title: BUILD_SET followed by COMPARE_OP (in) can be optimized if all items are consts
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6690>
_______________________________________

From report at bugs.python.org  Thu Aug 13 00:47:42 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 12 Aug 2009 22:47:42 +0000
Subject: [New-bugs-announce] [issue6691] Support for nested classes and
	function for pyclbr
In-Reply-To: <1250117262.14.0.353515413158.issue6691@psf.upfronthosting.co.za>
Message-ID: <1250117262.14.0.353515413158.issue6691@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

I have worked on a patch for adding support for nested classes and
nested functions in pyclbr. I believe this might be useful for some
applications, and also for issue1612262.

The patch attached also contains a test and updated documentation.

----------
components: Library (Lib)
files: pyclbr_nested_objects.diff
keywords: patch
messages: 91508
nosy: gpolo
severity: normal
status: open
title: Support for nested classes and function for pyclbr
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file14703/pyclbr_nested_objects.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6691>
_______________________________________

From report at bugs.python.org  Thu Aug 13 03:34:09 2009
From: report at bugs.python.org (Andrew Azarov)
Date: Thu, 13 Aug 2009 01:34:09 +0000
Subject: [New-bugs-announce] [issue6692] asyncore kqueue support
In-Reply-To: <1250127249.77.0.440620100529.issue6692@psf.upfronthosting.co.za>
Message-ID: <1250127249.77.0.440620100529.issue6692@psf.upfronthosting.co.za>


New submission from Andrew Azarov <equand at gmail.com>:

Is there a possibility of such feature in the future releases of Python?
Currently I see only select and epoll available, but on FreeBSD 7.2 with
a lot of connections asyncore (1600+ active HTTP connections) has
problems (not giving complete response) with epoll (select is
problematic after 250+ connections (not enough descriptors)).

----------
components: Library (Lib)
messages: 91512
nosy: Ikinoki
severity: normal
status: open
title: asyncore kqueue support
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6692>
_______________________________________

From report at bugs.python.org  Thu Aug 13 10:31:58 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 13 Aug 2009 08:31:58 +0000
Subject: [New-bugs-announce] [issue6693] New functions in site.py to get
	user/global site packages	paths
In-Reply-To: <1250152318.06.0.31085221368.issue6693@psf.upfronthosting.co.za>
Message-ID: <1250152318.06.0.31085221368.issue6693@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

As discussed in Distutils-SIG.

Here's a patch for site.py that adds:

- getsitepackages : Returns a list containing all global site-packages
directories (and possibly site-python).

- getusersitepackages: Returns the user-specific site-packages directory
path.

- getuserbase: Returns the `user base` directory path.

----------
assignee: tarek
components: Library (Lib)
files: site.patch
keywords: patch
messages: 91516
nosy: tarek
priority: normal
severity: normal
status: open
title: New functions in site.py to get user/global site packages paths
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file14707/site.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6693>
_______________________________________

From report at bugs.python.org  Thu Aug 13 11:04:09 2009
From: report at bugs.python.org (Alex Morega)
Date: Thu, 13 Aug 2009 09:04:09 +0000
Subject: [New-bugs-announce] [issue6694] itertools documentation still
	contains references to	ifilterfalse and izip_longest
In-Reply-To: <1250154249.26.0.325655481188.issue6694@psf.upfronthosting.co.za>
Message-ID: <1250154249.26.0.325655481188.issue6694@psf.upfronthosting.co.za>


New submission from Alex Morega <alex at grep.ro>:

The pages http://docs.python.org/dev/py3k/library/itertools.html and 
http://docs.python.org/3.1/library/itertools.html contain the names 
"ifilterfalse" and "izip_longest" in code examples for the "filterfalse" 
and "zip_longest" functions.

----------
assignee: georg.brandl
components: Documentation
messages: 91518
nosy: alex.morega, georg.brandl
severity: normal
status: open
title: itertools documentation still contains references to ifilterfalse and izip_longest
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6694>
_______________________________________

From report at bugs.python.org  Thu Aug 13 18:45:31 2009
From: report at bugs.python.org (Matthias Troffaes)
Date: Thu, 13 Aug 2009 16:45:31 +0000
Subject: [New-bugs-announce] [issue6695] PyXXX_ClearFreeList for dict, set,
	and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>


New submission from Matthias Troffaes <matthias.troffaes at gmail.com>:

The Python C API provides PyXXX_ClearFreeList functions to allow the
float, int, etc... freelists to be freed, potentially releasing memory
to the OS earlier. Currently, there is no such API for the dict, set,
and list freelists.

The attached patch adds PyXXX_ClearFreeList functions to the C API, so
the dict, set, and list freelists can be freed as well.

----------
components: Interpreter Core
files: py3k-clearfreelist-dict_set_list.patch
keywords: patch
messages: 91520
nosy: matthiastroffaes
severity: normal
status: open
title: PyXXX_ClearFreeList for dict, set, and list
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file14708/py3k-clearfreelist-dict_set_list.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Thu Aug 13 18:57:17 2009
From: report at bugs.python.org (Alexander Myodov)
Date: Thu, 13 Aug 2009 16:57:17 +0000
Subject: [New-bugs-announce] [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>


New submission from Alexander Myodov <amyodov at gmail.com>:

Seems like a minor documentation issue in 2.x became more significant 
one in 3.x.

In Python 2.6 (and lower), the documentation on Profile objects 
discussed them as a part of hotshot module, while omitting the fact 
that any profiler module, either of profile/cProfile/hotshot, supports 
them (though in fact, hotshot Profile objects have an api a bit 
different from profile/cProfile Profile objects). Note http://
docs.python.org/2.6/library/hotshot.html#profile-objects - there is no 
separate documentation of non-hotshot Profile objects, though they are 
largely similar. This is a minor issue which could probably be fixed in 
2.7 as a separate problem - otherwise it is pretty unclear from the 
documentation, what methods do cProfile Profile objects support (eg, 
they support enable()/disable() and runcall() methods, which is pretty 
useful for profiling, but impossible to find in documentation).

In Python 3.1, looks like everything related to hotshot was removed 
from the documents, including the documentation on Profile objects - 
which should not have been. This means, that now the documentation on 
profilers does not cover any Profile classes at all - see http://
docs.python.org/3.1/library/profile.html . For example, the official 
documentation doesn't say any way to profile a function passing 
arguments to it and receiving its result - while profile/cProfile 
Profile objects still do support runcall() method.

----------
assignee: georg.brandl
components: Documentation
messages: 91522
nosy: georg.brandl, honeyman
severity: normal
status: open
title: Profile objects should be documented
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6696>
_______________________________________

From report at bugs.python.org  Thu Aug 13 22:07:32 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 13 Aug 2009 20:07:32 +0000
Subject: [New-bugs-announce] [issue6697] Python 3.1 segfaults when invalid
	UTF-8 characters are	passed from command line
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

Python 3.1 segfaults when invalid UTF-8 characters are passed from
command line.

In BASH shell you can run:
$ python3.1 -c $'print("\x80")'
Segmentation fault

In other POSIX-compatible shells you can save the attached test.py
files in current directory and run:
$ python3.1 -c "$(<test.py)"
Segmentation fault

----------
components: Unicode
files: test.py
messages: 91533
nosy: Arfrever
severity: normal
status: open
title: Python 3.1 segfaults when invalid UTF-8 characters are passed from command line
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14711/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Fri Aug 14 00:03:11 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 13 Aug 2009 22:03:11 +0000
Subject: [New-bugs-announce] [issue6698] IDLE no longer opens only an edit
	window when configured	to do so
In-Reply-To: <1250200991.43.0.141209205867.issue6698@psf.upfronthosting.co.za>
Message-ID: <1250200991.43.0.141209205867.issue6698@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

If someone configure IDLE to start a edit window by default, I believe
it should open only an edit window without starting shell window. This
has been the behaviour in previous version, but it is acting different now.

I looked into r71126 and I think this behaviour was changed there
unintentionally. Its log message doesn't seem to mention this change,
that is why I'm thinking this.

----------
components: IDLE
messages: 91536
nosy: gpolo
severity: normal
status: open
title: IDLE no longer opens only an edit window when configured to do so
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6698>
_______________________________________

From report at bugs.python.org  Fri Aug 14 01:58:50 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 13 Aug 2009 23:58:50 +0000
Subject: [New-bugs-announce] [issue6699] IDLE: Warn user about overwriting a
	file that has a newer	version on filesystem
In-Reply-To: <1250207930.18.0.223468874802.issue6699@psf.upfronthosting.co.za>
Message-ID: <1250207930.18.0.223468874802.issue6699@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

Creating this issue to address a suggestion of a new IDLE feature
pointed out on issue 1721083.

The feature in question is about warning the user about a newer version
of the file before overwriting it.

----------
components: IDLE
files: check_stmtime.diff
keywords: patch
messages: 91537
nosy: gpolo
severity: normal
status: open
title: IDLE: Warn user about overwriting a file that has a newer version on filesystem
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file14714/check_stmtime.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6699>
_______________________________________

From report at bugs.python.org  Fri Aug 14 06:19:22 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 14 Aug 2009 04:19:22 +0000
Subject: [New-bugs-announce] [issue6700] inspect.getsource() returns
	incorrect source lines
In-Reply-To: <1250223562.74.0.274098839265.issue6700@psf.upfronthosting.co.za>
Message-ID: <1250223562.74.0.274098839265.issue6700@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

inspect.getsource(obj) returns incorrect results when obj is a 
traceback or frame object outside any function (that is, at the module 
level).

This demo script shows the problem. The correct output should contain 
all source lines in the module, but it only returns the first two:


D:\temp>type show_inspect_bug.py
def foo(x):
  return y + z

import inspect
frame = inspect.currentframe()
print inspect.getsource(frame)


D:\temp>python show_inspect_bug.py
def foo(x):
  return y + z


The attached patch fixes the problem and adds some missing test cases.
Originally reported by Juanjo Conti at the local Python group.

----------
components: Library (Lib)
files: inspect.diff
keywords: patch
messages: 91541
nosy: gagenellina
severity: normal
status: open
title: inspect.getsource() returns incorrect source lines
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14716/inspect.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6700>
_______________________________________

From report at bugs.python.org  Fri Aug 14 11:03:48 2009
From: report at bugs.python.org (Bogdan Opanchuk)
Date: Fri, 14 Aug 2009 09:03:48 +0000
Subject: [New-bugs-announce] [issue6701] Make custom xmlrpc extension easier
In-Reply-To: <1250240628.37.0.491365957246.issue6701@psf.upfronthosting.co.za>
Message-ID: <1250240628.37.0.491365957246.issue6701@psf.upfronthosting.co.za>


New submission from Bogdan Opanchuk <bg at bk.ru>:

I am sorry if the same issue was already considered and rejected for
some reason; quick search did not show any traces of it.

What I am going to write here is just a proof of concept, but if the
idea of the patch is acceptable, I am eager to prepare proper patches
for lib, documentation and so on.

So, my aim was to make xmlrpc module frendlier to those who want to
extend its functionality locally in their own projects. Currently there
are several problems with it:
1. Marshaller, unmarshaller and parser cannot be substituted by custom
versions easily.
2. Custom version of marshaller will look ugly (i.e., because it may
need to call Marshaller.__dump)
3. Transport, parser and unmarshaller are coupled now, though they are
completely independent.

My patch seem to eliminate these problems (see attach). Briefly, it
contains the following changes:
1. Transport, parser and unmarshaller are decoupled
2. Custom masrshaller, parser and unmarshaller classes can be passed to
client and server classes as parameters
3. Made Marshaller class easier to extend:
- __dump() renamed to _dump()
- added _add_memo() and _del_memo() (and hid .memo field)
- memo is now a set() (instead of dictionary with None values)
- dispatch table was made private

Results:
(good) This patch does not invalidate any part of documentation (but it
needs to be extended, according to new marshaller/unmarshaller/parser
parameters)
(good) test_xmlrpc still passes (with one little change to it, patch is
attached)
(good) Extension is easy now - see xmlrpc_overload.py as an example
(added bytes(), tuple() and dict() with non-string keys support)
(bad) Programs which use exported, but undocumented parts of xmlrpc can
break (though most of them can be easily fixed)

----------
components: Library (Lib)
messages: 91546
nosy: bogdan.opanchuk
severity: normal
status: open
title: Make custom xmlrpc extension easier
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6701>
_______________________________________

From report at bugs.python.org  Fri Aug 14 14:28:17 2009
From: report at bugs.python.org (paolo)
Date: Fri, 14 Aug 2009 12:28:17 +0000
Subject: [New-bugs-announce] [issue6702] Tkinter: modify xview of entry
	widget
In-Reply-To: <1250252897.03.0.863989377891.issue6702@psf.upfronthosting.co.za>
Message-ID: <1250252897.03.0.863989377891.issue6702@psf.upfronthosting.co.za>


New submission from paolo <paolo.fragu at libero.it>:

I wish to propose a useful and smart method modify in Tkinter Library:

Previously to scroll this widget we had to write an external function
(recalling xview_moveto and xview_scroll).

With my method this operation is cleared and the same as all other
widgets (just have to call xview).

----------------------------------------------------------
Modify Proposal:
----------------------------------------------------------
Change the method xview of entry so it works as all widget scrollable,
and it's compatible with 'old' xview.

So to scroll entry widget:

entry_widget['xscrollcommand']=scroll_widget.set
scroll_widget['command']=entry_widget.xview

The change in module Tkinter is:

def xview(self,*args):
    """Query and change horizontal position of the view."""
    #modify
    if not args:
        return self._getdoubles(self.tk.call(self._w, 'xview'))
    #old code
    index=args[0]
    self.tk.call(self._w, 'xview', index)
----------------------------------------------------------
+
It's call the tk interpreter passing entry and xview without arguments;
returns a list containing two elements to pass to scrollbars via the
xscrollcommand option

If an argument (index) is passing, then display the character given by
index at the left edge of the window; it work as the original xview

With 'old' methon is impossible call xview without arguments, the change
has made possible this.

-----------------------------------------------------------------
To scroll entry without modify:
-------------------------------
import Tkinter as tk
root=tk.Tk()

def scollEntry(*args):
   if args[0]=='scroll':
        e.xview_scroll(args[1],args[2])
   if args[0]=='moveto':
        e.xview_moveto(args[1])

e=tk.Entry(width=10)
e.grid(row=0, sticky='e'+'w')

s=tk.Scrollbar(orient='horizontal')
s.grid(row=1, sticky='e'+'w')

e['xscrollcommand']=s.set
s['command']=scollEntry

root.mainloop()

--------------------------------------------------------------------
With modify:
------------
import Tkinter as tk
root=tk.Tk()

e=tk.Entry(width=10)
e.grid(row=0, sticky='e'+'w')

s=tk.Scrollbar(orient='horizontal')
s.grid(row=1, sticky='e'+'w')

e['xscrollcommand']=s.set
s['command']=e.xview

root.mainloop()

-----------------------------------------------------------------
It's work also with tk-8.5 and ttk
----------------------------------
import Tkinter as tk
import ttk
root=tk.Tk()

e=ttk.Entry(width=10)
e.grid(row=0, sticky='e'+'w')

s=ttk.Scrollbar(orient='horizontal')
s.grid(row=1, sticky='e'+'w')

e['xscrollcommand']=s.set
s['command']=e.xview

root.mainloop()
---------------------------------------------------------

I tested with Python 2.5 and tk 8.4 and also tk 8.5 and module ttk

----------
components: Tkinter
messages: 91547
nosy: paolo
severity: normal
status: open
title: Tkinter: modify xview of entry widget
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6702>
_______________________________________

From report at bugs.python.org  Fri Aug 14 18:18:17 2009
From: report at bugs.python.org (Chris Withers)
Date: Fri, 14 Aug 2009 16:18:17 +0000
Subject: [New-bugs-announce] [issue6703] cross platform failure and silly
	test in doctest
In-Reply-To: <1250266697.36.0.481264395332.issue6703@psf.upfronthosting.co.za>
Message-ID: <1250266697.36.0.481264395332.issue6703@psf.upfronthosting.co.za>


New submission from Chris Withers <chris at simplistix.co.uk>:

Hi All,

Line 355 of this code on the 2.6 branch and trunk:

http://svn.python.org/view/python/branches/release26-
maint/Lib/doctest.py?view=annotate
http://svn.python.org/view/python/trunk/Lib/doctest.py?annotate=69012

...contain a check that doesn't work cross platform.

I'd argue that the check is worthless and should be removed.
I'm happy to do this, but is this code tested?
If not, do I need to add a test when I remove those two lines?

cheers,

Chris

----------
assignee: cjw296
messages: 91557
nosy: cjw296
severity: normal
status: open
title: cross platform failure and silly test in doctest
versions: Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6703>
_______________________________________

From report at bugs.python.org  Fri Aug 14 20:55:47 2009
From: report at bugs.python.org (Frank Wierzbicki)
Date: Fri, 14 Aug 2009 18:55:47 +0000
Subject: [New-bugs-announce] [issue6704] better col_offset for AST in
	statements like "for a, b in ..."
In-Reply-To: <1250276147.3.0.975792717277.issue6704@psf.upfronthosting.co.za>
Message-ID: <1250276147.3.0.975792717277.issue6704@psf.upfronthosting.co.za>


New submission from Frank Wierzbicki <fwierzbicki at gmail.com>:

For statements like:

for a,b in c:
   pass

The Tuple node "a,b" ends up with a col_offset of 0 (the position of the
"for"), but the col_offset should probably be 4 (the position of "a").
This is more consistent with other Tuple node col_offset results.

----------
components: Interpreter Core
files: ast.diff
keywords: patch
messages: 91566
nosy: fwierzbicki
severity: normal
status: open
title: better col_offset for AST in statements like "for a,b in ..."
versions: Python 2.7
Added file: http://bugs.python.org/file14727/ast.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6704>
_______________________________________

From report at bugs.python.org  Fri Aug 14 23:36:38 2009
From: report at bugs.python.org (Michael Gruen)
Date: Fri, 14 Aug 2009 21:36:38 +0000
Subject: [New-bugs-announce] [issue6705] '''3, 5'''.strip(r''',
	''') does not strip comma, returns '3, 5'
In-Reply-To: <1250285798.29.0.625956146612.issue6705@psf.upfronthosting.co.za>
Message-ID: <1250285798.29.0.625956146612.issue6705@psf.upfronthosting.co.za>


New submission from Michael Gruen <gruenm at gmail.com>:

I am new, I apologize if this is a trivial or non-problem.  I have
researched for hours, tried every variant but cannot understand why this
doesn't work.

----------
components: None
messages: 91572
nosy: mgruen
severity: normal
status: open
title: '''3,5'''.strip(r''',''') does not strip comma, returns '3,5'
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6705>
_______________________________________

From report at bugs.python.org  Sat Aug 15 01:03:37 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 14 Aug 2009 23:03:37 +0000
Subject: [New-bugs-announce] [issue6706] asyncore's accept() is broken
In-Reply-To: <1250291017.2.0.719693187742.issue6706@psf.upfronthosting.co.za>
Message-ID: <1250291017.2.0.719693187742.issue6706@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:

An old bad design choice in asyncore is how it forces the user to 
override handle_accept() and then call self.accept() to obtain a socket 
pair.

    def handle_accept(self):
        conn, addr = self.accept()

The documentation itself shows the code above as an example of how an 
asyncore-based server should handle an incoming connection.
What the doc doesn't say is that the user calling self.accept() is 
exposed to different risks:

- self.accept() can return None instead of a socket pair in which case 
TypeError is raised (see pyftpdlib bug: 
http://code.google.com/p/pyftpdlib/issues/detail?id=91)

- ECONNABORTED can be raised. This is reproducible on Linux by hammering 
the server with nmap (see pyftpdlib bug: 
http://code.google.com/p/pyftpdlib/issues/detail?id=105)

- EAGAIN can be raised too. I never experienced this error condition 
myself in pyftpdlib but by looking at twisted/internet/tcp.py it seems 
reasonable to catch EAGAIN too.

- The resulting address can be None, which means that the connection 
didn't take place.
This is reproducible by hammering the server with nmap (see pyftpdlib 
bug http://code.google.com/p/pyftpdlib/issues/detail?id=104).


The right thing to do when one of such events occur is to "return" as no 
connection has really been established between client and server.

Now, altough handling these kind of conditions is quite easy, the API 
design remains fundamentally wrong, as it forces the user to call 
accept().
As asyncore.py is structured right now the only chance the user has to 
properly accepting a connection is manually handling all these cases in 
his subclass.


My patch in attachment tries to solve this problem by defining a new 
"handle_accept_event()" method which takes care of all the error 
conditions described above resulting in handle_accept() be called *only 
when a connection really took place*.
When the connection is established handle_accept_event() stores the 
socket pair as an attribute and the next call to accept() returns that 
pair.
This preserves the current implementation without breaking any code as 
the user will have to override handle_accept() and then call accept() in 
the same manner [1], with the difference that self.accept() will always 
return a valid socket pair.

[1] 
    def handle_accept(self):
        conn, addr = self.accept()

----------
components: Library (Lib)
messages: 91579
nosy: giampaolo.rodola, josiahcarlson
severity: normal
status: open
title: asyncore's accept() is broken
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6706>
_______________________________________

From report at bugs.python.org  Sat Aug 15 01:06:42 2009
From: report at bugs.python.org (Dino Viehland)
Date: Fri, 14 Aug 2009 23:06:42 +0000
Subject: [New-bugs-announce] [issue6707] dir() on __new__'d module w/o dict
	crashes 2.6.2
In-Reply-To: <1250291202.25.0.109335007546.issue6707@psf.upfronthosting.co.za>
Message-ID: <1250291202.25.0.109335007546.issue6707@psf.upfronthosting.co.za>


New submission from Dino Viehland <dinov at microsoft.com>:

from types import ModuleType as M
m = M.__new__(M)
dir(m)

In 2.5 this raises an exception about not having __dict__, 2.6.2 
crashes out right.

----------
components: Interpreter Core
messages: 91580
nosy: DinoV
severity: normal
status: open
title: dir() on __new__'d module w/o dict crashes 2.6.2
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6707>
_______________________________________

From report at bugs.python.org  Sat Aug 15 04:21:10 2009
From: report at bugs.python.org (starz)
Date: Sat, 15 Aug 2009 02:21:10 +0000
Subject: [New-bugs-announce] [issue6708] raw_input() calls generate compile
	errors.
In-Reply-To: <1250302870.91.0.18677691598.issue6708@psf.upfronthosting.co.za>
Message-ID: <1250302870.91.0.18677691598.issue6708@psf.upfronthosting.co.za>


New submission from starz <b_lynch1 at yahoo.com>:

# ------ SOURCE -------
# cheerleading program
word = raw_input("Who do you go for? ")

for letter in word:
    call = "Gimme a " + letter + "!"
    print (call)
    print (letter) + "!"

print( "What does that spell?")
print( word + "!")

# ------- end source -------

## within python.help()
## --------------------
help> raw_input()
no Python documentation found for 'raw_input()'

help>

### --- run from O/S ---

C:\Program Files\OpenOffice.org 2.0\program\python3.1>python 
PYsource\test3.py
Traceback (most recent call last):
  File "PYsource\test3.py", line 22, in <module>
    word = raw_input("Who do you go for? ")
NameError: name 'raw_input' is not defined

C:\Program Files\OpenOffice.org 2.0\program\python3.1>

----------
components: Library (Lib)
files: test3.py
messages: 91584
nosy: starz
severity: normal
status: open
title: raw_input() calls generate compile errors.
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file14732/test3.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6708>
_______________________________________

From report at bugs.python.org  Sat Aug 15 04:39:54 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 15 Aug 2009 02:39:54 +0000
Subject: [New-bugs-announce] [issue6709] It's possible to create TryExcept
	with no handlers
In-Reply-To: <1250303994.53.0.2741455605.issue6709@psf.upfronthosting.co.za>
Message-ID: <1250303994.53.0.2741455605.issue6709@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

I think we might need to devise some way to add custom validation when
AST is being compiled. For example, you can also pass a level to
ImportFrom which is < -1.

>>> x = ast.parse("try: x\nexcept y: pass")
>>> del x.body[0].handlers[:]
>>> compile(x, "<string>", "exec")
<code object <module> at 0x7f0a92aed918, file "<string>", line 1>
>>> from dis import dis
>>> dis(x)
>>> dis(compile(x, "<string>", "exec"))
  1           0 SETUP_EXCEPT             8 (to 11)
              3 LOAD_NAME                0 (x)
              6 POP_TOP
              7 POP_BLOCK
              8 JUMP_FORWARD             1 (to 12)
        >>   11 END_FINALLY
        >>   12 LOAD_CONST               0 (None)
             15 RETURN_VALUE

----------
components: Extension Modules, Interpreter Core
messages: 91587
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: It's possible to create TryExcept with no handlers
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6709>
_______________________________________

From report at bugs.python.org  Sun Aug 16 00:12:18 2009
From: report at bugs.python.org (Jim Fulton)
Date: Sat, 15 Aug 2009 22:12:18 +0000
Subject: [New-bugs-announce] [issue6710] hotshot stats load causes TypeError
	when multiple files	are loaded
In-Reply-To: <1250374338.11.0.481034078931.issue6710@psf.upfronthosting.co.za>
Message-ID: <1250374338.11.0.481034078931.issue6710@psf.upfronthosting.co.za>


New submission from Jim Fulton <jim at zope.com>:

I've attached a script that demonstrates the problem.  When run with
Python 2.5, it outputs statistics.  When run with Python 2.6.2 it
generates a TypeError:

python2.6 hotshotbug.py
Traceback (most recent call last):
  File "hotshotbug.py", line 5, in <module>
    stats.add(hotshot.stats.load('p2'))
  File "/usr/local/python/2.6/lib/python2.6/pstats.py", line 171, in add
    self.stats[func] = add_func_stats(old_func_stat, stat)
  File "/usr/local/python/2.6/lib/python2.6/pstats.py", line 516, in
add_func_stats
    add_callers(t_callers, callers))
  File "/usr/local/python/2.6/lib/python2.6/pstats.py", line 526, in
add_callers
    zip(caller, new_callers[func])])
TypeError: zip argument #1 must support iteration

----------
components: Library (Lib)
files: hotshotbug.py
messages: 91619
nosy: j1m
severity: normal
status: open
title: hotshot stats load causes TypeError when multiple files are loaded
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14734/hotshotbug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6710>
_______________________________________

From report at bugs.python.org  Sun Aug 16 08:25:40 2009
From: report at bugs.python.org (Joe Amenta)
Date: Sun, 16 Aug 2009 06:25:40 +0000
Subject: [New-bugs-announce] [issue6711] macurl2path has typos that raise
	AttributeError
In-Reply-To: <1250403940.35.0.572726504822.issue6711@psf.upfronthosting.co.za>
Message-ID: <1250403940.35.0.572726504822.issue6711@psf.upfronthosting.co.za>


New submission from Joe Amenta <amentajo at msu.edu>:

In a few spots, "urllib.parse" misses a "." after the package name.

e.g., "urllib.parse.quote" is spelled "urllib.parsequote", which
generates an AttributeError when run.

To reproduce, open up a python3.x interpreter and execute:
from macurl2path import *
url2pathname('doesnt_matter_what')
pathname2url('some_string')
_pncomp2url('something_else')

Attaching a patch that will fix the issue.

----------
components: Library (Lib)
files: py3k_url2path.patch
keywords: patch
messages: 91627
nosy: joe.amenta
severity: normal
status: open
title: macurl2path has typos that raise AttributeError
type: crash
versions: Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14735/py3k_url2path.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6711>
_______________________________________

From report at bugs.python.org  Sun Aug 16 12:44:21 2009
From: report at bugs.python.org (Johannes Janssen)
Date: Sun, 16 Aug 2009 10:44:21 +0000
Subject: [New-bugs-announce] [issue6712] sys._getframe is not available on
	all Python	implementations
In-Reply-To: <1250419461.12.0.110179836515.issue6712@psf.upfronthosting.co.za>
Message-ID: <1250419461.12.0.110179836515.issue6712@psf.upfronthosting.co.za>


New submission from Johannes Janssen <mail at johannes-janssen.de>:

As I learned on the mailing list the function sys._getframe() is not
available on all Python implementations (e.g. jython). This information
should be added to the documentation.

----------
assignee: georg.brandl
components: Documentation
messages: 91629
nosy: georg.brandl, johannes.janssen
severity: normal
status: open
title: sys._getframe is not available on all Python implementations

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6712>
_______________________________________

From report at bugs.python.org  Sun Aug 16 19:45:49 2009
From: report at bugs.python.org (Gawain Bolton)
Date: Sun, 16 Aug 2009 17:45:49 +0000
Subject: [New-bugs-announce] [issue6713] Integer & Long types: Performance
	improvement of 1.6x to	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>


New submission from Gawain Bolton <gp.bolton at computer.org>:

Converting integer & long types to their ASCII representation is a task
which can be quite CPU intensive due to the division & modulo
operations.  For long integers having hundreds or thousands of digits,
this can take a truly significant amount of CPU time.

I have written a special case for base 10 conversions which allows for
two improvements.
1) Two digits can be converted at a time, thus reducing the number of
div/mod operations by two.
2) An optimizing compiler can avoid performing a division operation when
the divisor is hardcoded.  The expensive division operation can be
replaced by a much faster multiplication operation.

My tests show an improvement of 1.6x to 1.8x improvement for integer
types and 2x improvement for longs.

Note that because integers are displayed using fprintf(), the
performance improvement is only seen when __repr__() is called.

Patch is provided against trunk.  It is somewhat difficult to read the
patch in one or two places due to the use of tabs.

----------
components: Interpreter Core
files: base10_conversion_performance_patch.txt
messages: 91636
nosy: gawain
severity: normal
status: open
title: Integer & Long types:  Performance improvement of 1.6x to 2x for base 10 conversions
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file14736/base10_conversion_performance_patch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6713>
_______________________________________

From report at bugs.python.org  Sun Aug 16 23:32:53 2009
From: report at bugs.python.org (Giorgos Verigakis)
Date: Sun, 16 Aug 2009 21:32:53 +0000
Subject: [New-bugs-announce] [issue6714] memmove fails with unicode strings
In-Reply-To: <1250458373.38.0.665694741005.issue6714@psf.upfronthosting.co.za>
Message-ID: <1250458373.38.0.665694741005.issue6714@psf.upfronthosting.co.za>


New submission from Giorgos Verigakis <verigak at gmail.com>:

A demonstration:

>>> buf = create_string_buffer('______')
>>> memmove(buf, 'SPAM', 4)
614584
>>> buf.raw
'SPAM__\x00'

>>> buf = create_string_buffer('______')
>>> memmove(buf, u'SPAM', 4)
614672
>>> buf.raw
'S\x00\x00\x00__\x00'

FWIW memmove fails in Python 3.0 too.

----------
assignee: theller
components: ctypes
messages: 91644
nosy: theller, verigak
severity: normal
status: open
title: memmove fails with unicode strings
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6714>
_______________________________________

From report at bugs.python.org  Mon Aug 17 11:47:24 2009
From: report at bugs.python.org (devurandom)
Date: Mon, 17 Aug 2009 09:47:24 +0000
Subject: [New-bugs-announce] [issue6715] xz compression support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>


New submission from devurandom <devurandom at gmx.net>:

Python currently supports zlib, gzip and bzip2 compressors. What is missing is support 
for xz (http://tukaani.org/xz/). It comes with a C library.

----------
components: Library (Lib)
messages: 91657
nosy: devurandom
severity: normal
status: open
title: xz compression support
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Mon Aug 17 15:05:09 2009
From: report at bugs.python.org (pds)
Date: Mon, 17 Aug 2009 13:05:09 +0000
Subject: [New-bugs-announce] [issue6716] Windows install error when choosing
	to compile .py files
In-Reply-To: <1250514309.72.0.0787236734451.issue6716@psf.upfronthosting.co.za>
Message-ID: <1250514309.72.0.0787236734451.issue6716@psf.upfronthosting.co.za>


New submission from pds <pirdirsir at gmail.com>:

There seem to be 3 problems in Python 3.1.1rc1 Windows installer package.

1. Command line argument of compileall.py seems wrong.
2. UnicodeEncodeError occurs depending on code page.
3. Syntax errors.

First, I tried to install Python 3.1.1rc1 just by double-clicking the
Windows msi installer package file, python-3.1.1rc1.msi, as an
administrator account, with the following environment and settings.

Operating System version: Windows XP Professional SP3 (Japanese version)
Install options: Install for all users
Destination directory: C:\Python31
Advanced options: Enable "Compile .py files to byte code after installation"

Then the following dialog message appeared during installation.

There is a problem with this Windows Installer package. A program run as
part of the setup did not finish as expected. Contact your support
personnel or package vendor.

Despite the message, installation of Python interpreter seemed completed
because the programs were registered in Windows start menu.
So I uninstalled Python 3.1.1rc1 to make sure the system to be clean,
and retried installation with the following command from command prompt
so I could see the log file later.

msiexec /i python-3.1.1rc1.msi /L*v python-3.1.1rc1.log

Installation failed again, and the following is the part of the log file
(python-3.1.1rc1.log).

MSI (s) (18:50) [15:08:25:096]: Note: 1: 1722 2: CompilePyc 3:
C:\Python31\python.exe 4: -Wi "C:\Python31\Lib\compileall.py" -f -x
bad_coding|badsyntax|site-packages|py2_ "C:\Python31\Lib" 
MSI (s) (18:50) [15:08:25:096]: Note: 1: 2262 2: Error 3: -2147287038 
Error 1722. There is a problem with this Windows Installer package. A
program run as part of the setup did not finish as expected. Contact
your support personnel or package vendor.  Action CompilePyc, location:
C:\Python31\python.exe, command: -Wi "C:\Python31\Lib\compileall.py" -f
-x bad_coding|badsyntax|site-packages|py2_ "C:\Python31\Lib" 
MSI (s) (18:50) [15:10:58:677]: Note: 1: 2262 2: Error 3: -2147287038 
MSI (s) (18:50) [15:10:58:677]: Product: Python 3.1.1rc1 -- Error 1722.
There is a problem with this Windows Installer package. A program run as
part of the setup did not finish as expected. Contact your support
personnel or package vendor.  Action CompilePyc, location:
C:\Python31\python.exe, command: -Wi "C:\Python31\Lib\compileall.py" -f
-x bad_coding|badsyntax|site-packages|py2_ "C:\Python31\Lib" 

Also, installation completes normally if I choose not to compile .py
files in advanced options setting during the installer's setup dialog.

------
Problem 1: Command line argument of compileall.py seems wrong.

Because installation fails if I choose to compile .py files during
installation, I tried to compile .py files manually after installation
(without compilation) completes.

After finishing installation without compiling .py files, I did the
following command from Windows command prompt.

C:\Python31\python.exe "C:\Python31\Lib\compileall.py" -f -x
bad_coding|badsyntax|site-packages|py2_ "C:\Python31\Lib"

And I got the following error message.
(My Windows is Japanese version.)
'badsyntax' ??????????????????????????????
???? ?????????????????

This means, in English,
'badsyntax' is not recognized as an internal or external command,
operable program or batch file.

So I thought the command would be interpreted correctly if I embrace the
following part of the command with "".

bad_coding|badsyntax|site-packages|py2_

So I did the following from command prompt.

C:\Python31\python.exe "C:\Python31\Lib\compileall.py" -f -x
"bad_coding|badsyntax|site-packages|py2_" "C:\Python31\Lib"

And the compilation seemed to proceed.

However, the log file above (python-3.1.1rc1.log) says the argument is
not embraced with "" when compileall.py script is invoked during
installation process.
I suppose the argument not embraced with "" is one of the reasons why
installation process is interrupted.
Is this a bug of the installer package?

------
Problem 2: UnicodeEncodeError occurs depending on code page.

Compiling .py files seems to proceed by double-quoting the argument
discussed above when manually invoking compileall.py script, but the
following error occurs.

Listing C:\Python31\Lib\lib2to3\tests\data ...
Compiling C:\Python31\Lib\lib2to3\tests\data\crlf.py ...
***   File "C:\Python31\Lib\lib2to3\tests\data\crlf.py", line 1
    print "hi"
             ^
SyntaxError: invalid syntax

Compiling C:\Python31\Lib\lib2to3\tests\data\different_encoding.py ...
*** Traceback (most recent call last):
  File "C:\Python31\Lib\py_compile.py", line 142, in compile
    codeobject = builtins.compile(codestring, dfile or file,'exec')
  File "C:\Python31\Lib\lib2to3\tests\data\different_encoding.py", line 3
    print
u'\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd8\xd9\xda\xdb\xdc\xdd\xde'
          ^
SyntaxError: invalid syntax

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Python31\Lib\compileall.py", line 72, in compile_dir
    ok = py_compile.compile(fullname, None, dfile, True)
  File "C:\Python31\Lib\py_compile.py", line 146, in compile
    raise py_exc
py_compile.PyCompileError:   File
"C:\Python31\Lib\lib2to3\tests\data\different_encoding.py", line 3
    print
u'\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd8\xd9\xda\xdb\xdc\xdd\xde'
          ^
SyntaxError: invalid syntax


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Python31\Lib\compileall.py", line 170, in <module>
    exit_status = int(not main())
  File "C:\Python31\Lib\compileall.py", line 160, in main
    force, rx, quiet):
  File "C:\Python31\Lib\compileall.py", line 97, in compile_dir
    quiet):
  File "C:\Python31\Lib\compileall.py", line 97, in compile_dir
    quiet):
  File "C:\Python31\Lib\compileall.py", line 97, in compile_dir
    quiet):
  File "C:\Python31\Lib\compileall.py", line 80, in compile_dir
    print(err.msg)
UnicodeEncodeError: 'cp932' codec can't encode character '\xdf' in
position 86: illegal multibyte sequence

'cp932' is the default code page of Japanese version of Windows.
So I tried the following command to change the current code page of the
command prompt window to 850 (Latin-1) before running compileall.py
script, aiming to avoid the seemingly code-page specific problem.

chcp 850

By doing so, the UnicodeEncodeError seemed to be avoided as expected.

------
Problem 3: Syntax errors.

After changing the code page to 850, the UnicodeEncodeError doesn't seem
to occur.
However, the syntax errors still occur as follows.

Compiling C:\Python31\Lib\lib2to3\tests\data\crlf.py ...
***   File "C:\Python31\Lib\lib2to3\tests\data\crlf.py", line 1
    print "hi"
             ^
SyntaxError: invalid syntax

Compiling C:\Python31\Lib\lib2to3\tests\data\different_encoding.py ...
***   File "C:\Python31\Lib\lib2to3\tests\data\different_encoding.py",
line 3
    print u'??????????????????????????????????????????????????????????????'
          ^
SyntaxError: invalid syntax

I don't know about how these script files (crlf.py and
different_encoding.py) are used, but isn't it necessary for those lines
of print function to be written like print("hi") because the interpreter
version is 3.x?

----------
components: Installation
messages: 91662
nosy: pds
severity: normal
status: open
title: Windows install error when choosing to compile .py files
type: compile error
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6716>
_______________________________________

From report at bugs.python.org  Mon Aug 17 16:16:01 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Mon, 17 Aug 2009 14:16:01 +0000
Subject: [New-bugs-announce] [issue6717] Some problem with recursion handling
In-Reply-To: <1250518561.04.0.421053701967.issue6717@psf.upfronthosting.co.za>
Message-ID: <1250518561.04.0.421053701967.issue6717@psf.upfronthosting.co.za>


New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:

I suspect that there is some deeper (more severe) issue behind the
problem I describe below. I've observed the following on Windows only.
Didn't try it with different OSs

running dragbug.py shows different behaviour with Python 3.1 compared to
Python 2.6:

Running it with Python 3.1 and performing heavy turtle dragging with the
mouse results in:

Fatal Python error: Cannot recover from stack overflow
This application has requested the Runtime to terminate it in an unusual
way. Please contact the application's support team
-- As I do at the moment ;-) 

Running the same script from Python 2.6: The error is much harder to
reproduce (only with very excessive dragging). It's a bit easier to
reproduce when running the program from a console and  if it occurs one
gets a conventional Python error message:

First a long sequence of:
Exception in Tkinter callback
Traceback (most recent call last):
Exception RuntimeError: 'maximum recursion depth exceeded while .... 
ignored

Followed by:

Traceback (most recent call last):
  File "dragbug.py", line 10, in <module>
    mainloop()
  ....
  File "c:\Python26\lib\traceback.py", line 57, in print_tb
    if hasattr(sys, 'tracebacklimit'):
AttributeError: 'module' object has no attribute 'tracebacklimit'

This problem can be overcome by setting a higher recurson limit. But I
think one should require that it doesn't produce a Fatal Error like in
Python 3.1

Regards,
Gregor

----------
components: Library (Lib)
files: dragbug.py
messages: 91664
nosy: gregorlingl
severity: normal
status: open
title: Some problem with recursion handling
versions: Python 3.1
Added file: http://bugs.python.org/file14738/dragbug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6717>
_______________________________________

From report at bugs.python.org  Mon Aug 17 18:48:24 2009
From: report at bugs.python.org (Eric Pope)
Date: Mon, 17 Aug 2009 16:48:24 +0000
Subject: [New-bugs-announce] [issue6718] ValueError in 21.17.4.2.
	SocketServer.UDPServer Example
In-Reply-To: <1250527704.81.0.852484951369.issue6718@psf.upfronthosting.co.za>
Message-ID: <1250527704.81.0.852484951369.issue6718@psf.upfronthosting.co.za>


New submission from Eric Pope <slotterkey_privateer at yahoo.co.jp>:

In the client side example under
21.17.4.2. SocketServer.UDPServer Example:
at: 
http://docs.python.org/dev/library/socketserver.html

<<<<raises ValueError:
HOST, PORT = "localhost"
>>>>should have been:
HOST, PORT = "localhost", 9999

----------
assignee: georg.brandl
components: Documentation
messages: 91666
nosy: ericpope, georg.brandl
severity: normal
status: open
title: ValueError in 21.17.4.2. SocketServer.UDPServer Example
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6718>
_______________________________________

From report at bugs.python.org  Mon Aug 17 18:50:11 2009
From: report at bugs.python.org (samuel de framond)
Date: Mon, 17 Aug 2009 16:50:11 +0000
Subject: [New-bugs-announce] [issue6719] pdb messes up when debugging an
	non-ascii program
In-Reply-To: <1250527811.0.0.14372124674.issue6719@psf.upfronthosting.co.za>
Message-ID: <1250527811.0.0.14372124674.issue6719@psf.upfronthosting.co.za>


New submission from samuel de framond <samuel43 at laposte.net>:

consider a program like this one:

---- File: ./test.py ----
#/usr/bin/env python
#coding: utf8

print 'qwerty'
-------------------------

Here is a shell (e.g. bash) session:

$ python -m pdb ./test.py
--Return--
> /usr/lib/python2.6/encodings/__init__.py(69)normalize_encoding()->'latin1'
-> return '_'.join(encoding.translate(_norm_encoding_map).split())
(Pdb) 

While for a file without the line #2, the output would be:

$ python -m pdb ./test.py
> /home/.../test.py(3)<module>()
-> print 'qwerty'
(Pdb) 

Here is the thing: the normal behaviour of pdb in this case is to pause
before executing the first line of the program. Instead of this, it
pauses at line #69 in .../encodings/__init__.py, which makes pdb almost
unusable.
Plus, pdb's inline command "q" (or "quit") does not work anymore. Here,
the first line should close the program but it does not:

(Pdb) q
Traceback (most recent call last):
  File "/usr/lib/python2.6/pdb.py", line 1283, in main
    pdb._runscript(mainpyfile)
  File "/usr/lib/python2.6/pdb.py", line 1202, in _runscript
    self.run(statement)
  File "/usr/lib/python2.6/bdb.py", line 368, in run
    exec cmd in globals, locals
  File "<string>", line 1, in <module>
  File "./test.py", line 2
 SyntaxError: encoding problem: with BOM (test.py, line 2)
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> <string>(1)<module>()
(Pdb) 

if 'q' is types a second time in a row, it goes like this and we are
back to starting point:

(Pdb) q
Post mortem debugger finished. The ./test.py will be restarted
--Return--
> /usr/lib/python2.6/encodings/__init__.py(69)normalize_encoding()->'latin1'
-> return '_'.join(encoding.translate(_norm_encoding_map).split())
(Pdb)

----------
components: Library (Lib)
messages: 91667
nosy: smu
severity: normal
status: open
title: pdb messes up when debugging an non-ascii program
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6719>
_______________________________________

From report at bugs.python.org  Mon Aug 17 22:23:21 2009
From: report at bugs.python.org (Benjamin Liles)
Date: Mon, 17 Aug 2009 20:23:21 +0000
Subject: [New-bugs-announce] [issue6720] multiprocessing logging
In-Reply-To: <1250540601.66.0.070668154898.issue6720@psf.upfronthosting.co.za>
Message-ID: <1250540601.66.0.070668154898.issue6720@psf.upfronthosting.co.za>


New submission from Benjamin Liles <benliles at gmail.com>:

In the backport package of the multiprocessing library. A bug was
introduced in version 2.6.2.1 when the logging module was modified. If
you use logging in the backport, you get the following:

Traceback (most recent call last):
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/logging/__init__.py",
line 744, in emit
    msg = self.format(record)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/logging/__init__.py",
line 630, in format
    return fmt.format(record)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/logging/__init__.py",
line 421, in format
    s = self._fmt % record.__dict__
KeyError: 'processName'

----------
components: Library (Lib)
messages: 91670
nosy: benliles
severity: normal
status: open
title: multiprocessing logging
type: crash
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6720>
_______________________________________

From report at bugs.python.org  Tue Aug 18 01:06:18 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 17 Aug 2009 23:06:18 +0000
Subject: [New-bugs-announce] [issue6721] Locks in python standard library
	should be sanitized on	fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

The python logging module uses a lock to surround many operations, in 
particular.  This causes deadlocks in programs that use logging, fork 
and threading simultaneously.

1) spawn one or more threads in your program
2) have at least one of those threads make logging calls that will be 
emitted.
3) have your main thread or another thread use os.fork() to run some 
python code in a child process.
4) If the fork happened while one of your threads was within the 
logging.Handler.handle() critical section (or anywhere else where 
handler.lock is acquired), your child process will deadlock as soon as 
it tries to log anything.  It inherited a held lock.

The deadlock is more likely to happen on a highly loaded system which 
tends to widen the deadlock opportunity window due to context switching.

A demo of the problem simplified into one file is attached.

The Python standard library should not be the cause of these deadlocks.  
We need a way for all standard library locks to be cleaned up when 
forking.  By doing one of the following:

A) acquire all locks before forking, release them immediately after.
B) forceably release all standard library locks after forking in the 
child process.

Code was added to call some cleanups after forking in 
http://bugs.python.org/issue874900 but there are more things that also 
need this same sort of cleanup (logging for example).

Rather than having to manually add after fork code hooks into every file 
in the standard library that uses locks, a more general solution to 
track and manage locks across fork would be a good idea.

----------
assignee: gregory.p.smith
files: lock_fork_thread_deadlock_demo.py
messages: 91674
nosy: gregory.p.smith
priority: high
severity: normal
status: open
title: Locks in python standard library should be sanitized on fork
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14740/lock_fork_thread_deadlock_demo.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Tue Aug 18 12:38:45 2009
From: report at bugs.python.org (Alexey Shamrin)
Date: Tue, 18 Aug 2009 10:38:45 +0000
Subject: [New-bugs-announce] [issue6722] collections.namedtuple: confusing
	example
In-Reply-To: <1250591925.23.0.269848636465.issue6722@psf.upfronthosting.co.za>
Message-ID: <1250591925.23.0.269848636465.issue6722@psf.upfronthosting.co.za>


New submission from Alexey Shamrin <shamrin at gmail.com>:

Maybe it's just me, but it took me several attempts  to understand
namedtuple example in the documentation [1]. The problem is that the
first example uses verbose=True. It's very unusual to get Python source
as the output in Python shell. At first I thought there's some syntax
error in documentation source.

I know that several lines above one can read: "If verbose is true, the
class definition is printed just before being built." But during first
several attempts to understand namedtuple, I skipped it and directly
scrolled to the first example.

I think the first example on namedtuple usage shouldn't use verbose=True.

You could argue I had to try using namedtuple inside Python shell. I
agree. But unfortunately Python 2.6 was not installed on the computer I
was at.

[1]: http://docs.python.org/library/collections.html#collections.namedtuple

----------
assignee: georg.brandl
components: Documentation
messages: 91680
nosy: ash, georg.brandl
severity: normal
status: open
title: collections.namedtuple: confusing example
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6722>
_______________________________________

From report at bugs.python.org  Tue Aug 18 14:38:34 2009
From: report at bugs.python.org (Nicolas Goutte)
Date: Tue, 18 Aug 2009 12:38:34 +0000
Subject: [New-bugs-announce] [issue6723] csv.writer: example does not work
In-Reply-To: <1250599114.63.0.456902579657.issue6723@psf.upfronthosting.co.za>
Message-ID: <1250599114.63.0.456902579657.issue6723@psf.upfronthosting.co.za>


New submission from Nicolas Goutte <nicolas.goutte at extragroup.de>:

In the documentation for csv.writer, the example
spamWriter = csv.writer(open('eggs.csv', 'w'), delimiter=' ',
quotechar='|', quoting=QUOTE_MINIMAL)
does not work, as Python complains about "SyntaxError: invalid syntax",
as QUOTE_MINIMAL is not a global identifier.

By replacing QUOTE_MINIMAL by csv.QUOTE_MINIMAL there is no syntax error
anymore.

I have discovered the issue with python 2.6.2. All online documentation
version (2.6, 2.7, 3.1, 3.2) seem to have the same documentation (e.g.
http://docs.python.org/library/csv.html )

----------
assignee: georg.brandl
components: Documentation
messages: 91682
nosy: georg.brandl, nicolasg
severity: normal
status: open
title: csv.writer: example does not work
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6723>
_______________________________________

From report at bugs.python.org  Tue Aug 18 14:49:44 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 18 Aug 2009 12:49:44 +0000
Subject: [New-bugs-announce] [issue6724] r74463 causes failures in
	test_xmlrpc
In-Reply-To: <1250599784.86.0.0936114935604.issue6724@psf.upfronthosting.co.za>
Message-ID: <1250599784.86.0.0936114935604.issue6724@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

The title says it all.

----------
assignee: gregory.p.smith
components: Library (Lib), Tests
messages: 91685
nosy: gregory.p.smith, r.david.murray
priority: high
severity: normal
stage: needs patch
status: open
title: r74463 causes failures in test_xmlrpc
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6724>
_______________________________________

From report at bugs.python.org  Tue Aug 18 16:48:10 2009
From: report at bugs.python.org (CarGuy37)
Date: Tue, 18 Aug 2009 14:48:10 +0000
Subject: [New-bugs-announce] [issue6725] Inconsistency in Documentation:
	"Name Spaces" vs	"Namespaces"
In-Reply-To: <1250606890.78.0.538914735097.issue6725@psf.upfronthosting.co.za>
Message-ID: <1250606890.78.0.538914735097.issue6725@psf.upfronthosting.co.za>


New submission from CarGuy37 <tom.macleod at analog.com>:

Why is there an inconsistency in the usage of "Name Spaces" vs "Namespaces"?

After "import this", Python returns "...Namespaces are ..."

I would suggest conjoining the two words and being consistent (9.2 Title
and beginning sentence of the 6th paragraph thereof).

----------
assignee: georg.brandl
components: Documentation
messages: 91696
nosy: CarGuy37, georg.brandl
severity: normal
status: open
title: Inconsistency in Documentation: "Name Spaces" vs "Namespaces"
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6725>
_______________________________________

From report at bugs.python.org  Tue Aug 18 16:58:40 2009
From: report at bugs.python.org (Marcin)
Date: Tue, 18 Aug 2009 14:58:40 +0000
Subject: [New-bugs-announce] [issue6726] pyuic4.bat has bad path to
	python.exe and pyuic.py
In-Reply-To: <1250607520.51.0.355882528054.issue6726@psf.upfronthosting.co.za>
Message-ID: <1250607520.51.0.355882528054.issue6726@psf.upfronthosting.co.za>


New submission from Marcin <maar.cz at gmail.com>:

I have found bug in pyuic4.bat. I have installed python to directory
c:\programs. The path to 'python.exe' is c:\programs\python.exe. Content
of file pyuic4.bat is:

@"C:\Python25\python.exe"
"C:\Python25\Lib\site-packages\PyQt4\uic\pyuic.py" %1 %2 %3 %4 %5 %6 %7
%8 %9

In this file, during installation process it must be changed path to
python.exe.

In my example it must be done like that:

@"C:\programs\Python25\python.exe"
"C:\programs\Python25\Lib\site-packages\PyQt4\uic\pyuic.py" %1 %2 %3 %4
%5 %6 %7 %8 %9

----------
components: Demos and Tools
messages: 91697
nosy: maar
severity: normal
status: open
title: pyuic4.bat has bad path to python.exe and pyuic.py
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6726>
_______________________________________

From report at bugs.python.org  Tue Aug 18 17:13:03 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 18 Aug 2009 15:13:03 +0000
Subject: [New-bugs-announce] [issue6727] ImportError when package is
	symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

Python reports an import error, even when a valid package exists on
sys.path, if that package is a symlink directory and would otherwise be
importable.

The attached test script demonstrates the limitation on Python 2.6.2 and
3.1.0.

I suspect that the underlying import routines have some assumptions
about the file system that exclude symlinked directories.

----------
components: Interpreter Core, Windows
files: test_import_symlink_package.py
messages: 91699
nosy: jaraco
severity: normal
status: open
title: ImportError when package is symlinked on Windows
type: behavior
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file14741/test_import_symlink_package.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Tue Aug 18 17:58:08 2009
From: report at bugs.python.org (Yang)
Date: Tue, 18 Aug 2009 15:58:08 +0000
Subject: [New-bugs-announce] [issue6728] To avoid hang up in using
	CGIXMLRPCRequestHandler under	IIS 7.x
In-Reply-To: <1250611088.83.0.579376687228.issue6728@psf.upfronthosting.co.za>
Message-ID: <1250611088.83.0.579376687228.issue6728@psf.upfronthosting.co.za>


New submission from Yang <student at live.cn>:

The mismatched content length will cause hang up in sys.stdin.read(). 
The reason is probably described in Issue 1214 as well as 1725295.

length = int(os.environ.get('CONTENT_LENGTH', None))
"""Length fix for IIS 7.x to avoid hang up"""
length=length-2

I would appreciate if someone can create a diff or patch file for the 
code above.

----------
components: Library (Lib)
messages: 91707
nosy: sjtuer
severity: normal
status: open
title: To avoid hang up in using CGIXMLRPCRequestHandler under IIS 7.x
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6728>
_______________________________________

From report at bugs.python.org  Tue Aug 18 22:16:41 2009
From: report at bugs.python.org (Nikolaus Rath)
Date: Tue, 18 Aug 2009 20:16:41 +0000
Subject: [New-bugs-announce] [issue6729] Add support for ssize_t
In-Reply-To: <1250626601.03.0.294570676817.issue6729@psf.upfronthosting.co.za>
Message-ID: <1250626601.03.0.294570676817.issue6729@psf.upfronthosting.co.za>


New submission from Nikolaus Rath <Nikolaus at rath.org>:

ctypes currently has a datatype c_size_t which corresponds to size_t in
C, but there is no datatype for the C ssize_t.

----------
assignee: theller
components: ctypes
messages: 91713
nosy: Nikratio, theller
severity: normal
status: open
title: Add support for ssize_t
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6729>
_______________________________________

From report at bugs.python.org  Tue Aug 18 22:28:55 2009
From: report at bugs.python.org (Maxime Lemonnier)
Date: Tue, 18 Aug 2009 20:28:55 +0000
Subject: [New-bugs-announce] [issue6730] dict.fromkeys() should not cross
	reference mutable value	by default
In-Reply-To: <1250627335.2.0.623159685079.issue6730@psf.upfronthosting.co.za>
Message-ID: <1250627335.2.0.623159685079.issue6730@psf.upfronthosting.co.za>


New submission from Maxime Lemonnier <maxime.lemonnier at gmail.com>:

Consider the following code sample :

keys = ['x', 'y', 'z']
d = dict.fromkeys(keys, [])
d['x'].append('dont')
d['y'].append('mix')
d['z'].append('me!')
print d['x']

>>> ['dont', 'mix', 'me!']

It is very unatural and dangerous to have all dict keys poining to the
same mutable object reference. 

The way it should behave : 
if value is mutable, create a new copy of value for each keys
else, it doesn't matter

----------
components: Interpreter Core
messages: 91714
nosy: maxlem
severity: normal
status: open
title: dict.fromkeys() should not cross reference mutable value by default
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6730>
_______________________________________

From report at bugs.python.org  Wed Aug 19 00:25:22 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 18 Aug 2009 22:25:22 +0000
Subject: [New-bugs-announce] [issue6731] Non-zero exit status of setup.py
	when building of	extensions has failed
In-Reply-To: <1250634322.79.0.224296931911.issue6731@psf.upfronthosting.co.za>
Message-ID: <1250634322.79.0.224296931911.issue6731@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

sharedmods rule of Makefile calls setup.py which doesn't fail even
building of extensions has failed.

----------
components: Build
files: python-non-zero_exit_status_on_failure.patch
keywords: patch
messages: 91719
nosy: Arfrever
severity: normal
status: open
title: Non-zero exit status of setup.py when building of extensions has failed
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14742/python-non-zero_exit_status_on_failure.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6731>
_______________________________________

From report at bugs.python.org  Wed Aug 19 01:48:29 2009
From: report at bugs.python.org (KAJIYAMA, Tamito)
Date: Tue, 18 Aug 2009 23:48:29 +0000
Subject: [New-bugs-announce] [issue6732] PyInit_shoddy() in shoddy.c does
	not return anything on	success
In-Reply-To: <1250639309.85.0.383557872806.issue6732@psf.upfronthosting.co.za>
Message-ID: <1250639309.85.0.383557872806.issue6732@psf.upfronthosting.co.za>


New submission from KAJIYAMA, Tamito <rd6t-kjym at asahi-net.or.jp>:

Section 2.1.4, "Subclassing other types", of "Extending and Embedding 
the Python Interpreter" (Release: 3.1, Date: June 26, 2009) has a 
complete list of shoddy.c, in which PyInit_shoddy() does not have a 
return statement at the end to return a pointer to the created "shoddy" 
module on success.  Simply adding the missing "return m;" statement 
would be fine.

----------
assignee: georg.brandl
components: Documentation
messages: 91720
nosy: georg.brandl, kajiyama
severity: normal
status: open
title: PyInit_shoddy() in shoddy.c does not return anything on success
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6732>
_______________________________________

From report at bugs.python.org  Wed Aug 19 02:43:22 2009
From: report at bugs.python.org (fugounashi)
Date: Wed, 19 Aug 2009 00:43:22 +0000
Subject: [New-bugs-announce] [issue6733] curses line wrap broken when mixing
	full- and half-width	unicode characters
In-Reply-To: <1250642602.2.0.807698027943.issue6733@psf.upfronthosting.co.za>
Message-ID: <1250642602.2.0.807698027943.issue6733@psf.upfronthosting.co.za>


New submission from fugounashi <fugounashi+python at gmail.com>:

when printing a full width unicode character near the end of a line when
only a single (half-width) space remains, the character is printed at
the start of the current line rather than the start of the next line. 
the following character is printed in the following space on the next
line as it should be.  same behaviour in both mlterm and xterm

thanks!

python deb 2.5.2-3

----------
messages: 91721
nosy: fugounashi
severity: normal
status: open
title: curses line wrap broken when mixing full- and half-width unicode characters
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6733>
_______________________________________

From report at bugs.python.org  Wed Aug 19 15:18:00 2009
From: report at bugs.python.org (Eric)
Date: Wed, 19 Aug 2009 13:18:00 +0000
Subject: [New-bugs-announce] [issue6734] Imap lib implicit conversion from
	bytes to string
In-Reply-To: <1250687880.61.0.0161540410601.issue6734@psf.upfronthosting.co.za>
Message-ID: <1250687880.61.0.0161540410601.issue6734@psf.upfronthosting.co.za>


New submission from Eric <surprising42 at gmail.com>:

using imaplib IMAP4_SSL, would fail at login due to TypeError, implicit
conversion from bytes object to string around line 1068 involving
function "_quote".

My fix:  
def _quote(self, arg):
        #Could not implicitly convert to bytes object to string
        arg = arg.encode('utf-8') #added this line to solve problem
        arg = arg.replace(b'\\', b'\\\\')
        arg = arg.replace(b'"', b'\\"')

        return b'"' + arg + b'"'

----------
components: Library (Lib)
files: imaplib.py
messages: 91729
nosy: surprising42
severity: normal
status: open
title: Imap lib implicit conversion from bytes to string
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file14743/imaplib.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6734>
_______________________________________

From report at bugs.python.org  Wed Aug 19 20:59:18 2009
From: report at bugs.python.org (dontbugme)
Date: Wed, 19 Aug 2009 18:59:18 +0000
Subject: [New-bugs-announce] [issue6735] restype pointer to Structure
	subclass never initialized
In-Reply-To: <1250708358.54.0.249958641719.issue6735@psf.upfronthosting.co.za>
Message-ID: <1250708358.54.0.249958641719.issue6735@psf.upfronthosting.co.za>


New submission from dontbugme <pythonbugsbugmenot at spamavert.com>:

So, say I'm sub-classing ctypes.Structure with a class: MyClass.

I define __init__() in MyClass..

If I explicitly instantiate MyClass(), then the __init__() is properly
executed as expected.

But say I have a CFUNCTYPE where I set it's restype member to a POINTER
to MyClass.. A python MyClass object is obviously instantiated at one
point in time, but it's __init__ is never called. Seems odd to me?

----------
assignee: theller
components: ctypes
messages: 91736
nosy: dontbugme, theller
severity: normal
status: open
title: restype pointer to Structure subclass never initialized
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6735>
_______________________________________

From report at bugs.python.org  Thu Aug 20 00:27:58 2009
From: report at bugs.python.org (Salebona)
Date: Wed, 19 Aug 2009 22:27:58 +0000
Subject: [New-bugs-announce] [issue6736] File handling in Python
In-Reply-To: <1250720878.56.0.299301851986.issue6736@psf.upfronthosting.co.za>
Message-ID: <1250720878.56.0.299301851986.issue6736@psf.upfronthosting.co.za>


New submission from Salebona <sallas07 at gmail.com>:

How can I make read a text file from a normal text editor lik 
emicrosoft word or word pad?

----------
components: Windows
messages: 91751
nosy: SallaS07
severity: normal
status: open
title: File handling in Python
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6736>
_______________________________________

From report at bugs.python.org  Thu Aug 20 00:29:15 2009
From: report at bugs.python.org (Christopher Egner)
Date: Wed, 19 Aug 2009 22:29:15 +0000
Subject: [New-bugs-announce] [issue6737] PEP 372 odict.__eq__ behaves
	incorrectly
In-Reply-To: <1250720955.06.0.955952600398.issue6737@psf.upfronthosting.co.za>
Message-ID: <1250720955.06.0.955952600398.issue6737@psf.upfronthosting.co.za>


New submission from Christopher Egner <cegner at yahoo-inc.com>:

The current definition for odict.__eq__ is
    def __eq__(self, other):
        if isinstance(other, OrderedDict):
            return all(p==q for p, q in  _zip_longest(self.items(),
other.items()))
        return dict.__eq__(self, other)

The current behavior of NotImplemented is:
>>> if( NotImplemented ):
...     print 'foo'
foo
>>> dict.__eq__( {}, None )
NotImplemented
>>> if ( dict.__eq__( {}, None ) ):
...     print 'oops'
oops

The surprising behavior is:
>>> if ( OrderedDict() != None ):
...     print 'okie'
... else:
...     print 'gah!'
gah!

As best I understand it, normally other (in this case None) would be
given the chance to evaluate other.__eq__( OrderedDict() ), but this
doesn't seem to be happening.

----------
components: None
messages: 91752
nosy: cegner
severity: normal
status: open
title: PEP 372 odict.__eq__ behaves incorrectly
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6737>
_______________________________________

From report at bugs.python.org  Thu Aug 20 09:32:12 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Thu, 20 Aug 2009 07:32:12 +0000
Subject: [New-bugs-announce] [issue6738] Wrong doc strings in itertools
In-Reply-To: <1250753532.16.0.563820931893.issue6738@psf.upfronthosting.co.za>
Message-ID: <1250753532.16.0.563820931893.issue6738@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

The doc strings of itertools.combinations and
itertools.combinations_with_replacement are wrong: The parameter "r" is
not optional here (like it is for itertools.permutations).

Attached trivial patch.

----------
components: Library (Lib)
files: docstring.patch
keywords: patch
messages: 91761
nosy: hagen
severity: normal
status: open
title: Wrong doc strings in itertools
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14746/docstring.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6738>
_______________________________________

From report at bugs.python.org  Thu Aug 20 10:31:20 2009
From: report at bugs.python.org (CaribbeanCruise)
Date: Thu, 20 Aug 2009 08:31:20 +0000
Subject: [New-bugs-announce] [issue6739] IDLE window won't start or show up
	after assgining new	key in options v2.5.2 and 3.1.1
In-Reply-To: <1250757080.7.0.965993936336.issue6739@psf.upfronthosting.co.za>
Message-ID: <1250757080.7.0.965993936336.issue6739@psf.upfronthosting.co.za>


New submission from CaribbeanCruise <caribbeancruise123 at gmail.com>:

I tried to assign a new key(lctrl+lshift instead of lctrl+F5) for run-
mode in option in v.2.5.2. I tried the new key and it didn't work. And 
then I got lots of messages.
So I killed the IDLE and the rest of python. And run IDLE again, 
background process indicates some activity for 5secs. And then it was 
gone. No IDLE window showed up. 
So I uninstalled the 2.5.2. and installed the v.3.1.1. The installation 
process went ok, but when I starts IDLE. Nothing happens.
I tried and run idle.py in cmd, while I'm a vista user and got this:

Traceback (most recent call last):
  File "C:\Python31\Lib\idlelib\idle.py", line 11, in <module>
    idlelib.PyShell.main()
  File "C:\Python31\Lib\idlelib\PyShell.py", line 1388, in main
    shell = flist.open_shell()
  File "C:\Python31\Lib\idlelib\PyShell.py", line 277, in open_shell
    self.pyshell = PyShell(self)
  File "C:\Python31\Lib\idlelib\PyShell.py", line 813, in __init__
    OutputWindow.__init__(self, flist, None, None)
  File "C:\Python31\Lib\idlelib\OutputWindow.py", line 16, in __init__
    EditorWindow.__init__(self, *args)
  File "C:\Python31\Lib\idlelib\EditorWindow.py", line 135, in __init__
    self.apply_bindings()
  File "C:\Python31\Lib\idlelib\EditorWindow.py", line 961, in 
apply_bindings
    text.event_add(event, *keylist)
  File "C:\Python31\Lib\idlelib\MultiCall.py", line 359, in event_add
    widget.event_add(self, virtual, seq)
  File "C:\Python31\Lib\tkinter\__init__.py", line 1353, in event_add
    self.tk.call(args)
_tkinter.TclError: bad event type or keysym "Shift"

What do I do to get this up and running?

----------
components: IDLE
messages: 91762
nosy: CaribbeanCruise
severity: normal
status: open
title: IDLE window won't start or show up after assgining new key in options v2.5.2 and 3.1.1
type: performance
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6739>
_______________________________________

From report at bugs.python.org  Thu Aug 20 12:27:17 2009
From: report at bugs.python.org (Michal Vyskocil)
Date: Thu, 20 Aug 2009 10:27:17 +0000
Subject: [New-bugs-announce] [issue6740] Compounded expressions with lambda
	functions are	evaluated incorrectly
In-Reply-To: <1250764037.64.0.603658762072.issue6740@psf.upfronthosting.co.za>
Message-ID: <1250764037.64.0.603658762072.issue6740@psf.upfronthosting.co.za>


New submission from Michal Vyskocil <mvyskocil at suse.cz>:

The compounded expressions with lambda functions are evaluated
incorrectly. The simple expressions, or a named functions are evaluated
good. The problem is only in the evaluation of compounded expressions.
It seems that after evaluate of the first lambda function the
evaluation of whole expression is stopped and not continue (see
cond_error, which may raises the exception during evaluation).

Python 3.1 (r31:73572, Aug 15 2009, 22:04:19)
[GCC 4.4.1 [gcc-4_4-branch revision 149935]] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> cond = (lambda x : x == 'foo') or (lambda x : x == 'bar')
>>> cond('foo')
True
>>> cond('bar')
False
>>> c1 = lambda x : x == 'foo'
>>> c1('foo')
True
>>> c2 = lambda x : x == 'bar'
>>> c2('bar')
True
>>> def ham(x): return x == 'foo'
...
>>> def spam(x): return x == 'bar'
...
>>> cond2 = lambda x : ham(x) or spam(x)
>>> cond2('foo')
True
>>> cond2('bar')
True
>>> cond2('ham')
False
>>> cond_error = (lambda x : x == 'foo') or (lambda x : y == 'bar')
>>> cond_error('d')
False

BTW: the same problem exists in Python 2.6.2
Python 2.6.2 (r262:71600, Aug 15 2009, 18:37:04)
[GCC 4.4.1 [gcc-4_4-branch revision 149935]] on linux2
Type "help", "copyright", "credits" or "license" for more information.

----------
messages: 91766
nosy: mvyskocil
severity: normal
status: open
title: Compounded expressions with lambda functions are evaluated incorrectly
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6740>
_______________________________________

From report at bugs.python.org  Thu Aug 20 14:38:32 2009
From: report at bugs.python.org (Lev)
Date: Thu, 20 Aug 2009 12:38:32 +0000
Subject: [New-bugs-announce] [issue6741] Garbage collector release method
In-Reply-To: <1250771912.15.0.32080385055.issue6741@psf.upfronthosting.co.za>
Message-ID: <1250771912.15.0.32080385055.issue6741@psf.upfronthosting.co.za>


New submission from Lev <lgardster at gmail.com>:

WinCRT debug detects several memory leaks after calling py_Initialize
(); py_Finalize(); functions. Most of them are garbage collector 
visible python's objects. I suggest to create "release" method in 
garbage collector which will distruct all objects in GC list without 
reference count checking, and call this method at the end of py_Finalize
() function. I think, that it will help to avoid memory leaks after 
calling py_Finalize() function.

----------
components: Interpreter Core
messages: 91772
nosy: gardster
severity: normal
status: open
title: Garbage collector release method
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6741>
_______________________________________

From report at bugs.python.org  Thu Aug 20 15:32:02 2009
From: report at bugs.python.org (damahay123)
Date: Thu, 20 Aug 2009 13:32:02 +0000
Subject: [New-bugs-announce] [issue6742] Embedding python into shared
	library crash on AIX
In-Reply-To: <1250775122.87.0.638132535261.issue6742@psf.upfronthosting.co.za>
Message-ID: <1250775122.87.0.638132535261.issue6742@psf.upfronthosting.co.za>


New submission from damahay123 <hong.zhu at algorithmics.com>:

Hi there,
I'm trying to embedding my python code into a .so on AIX and load it
with my main application. Since there is no libpython2.6.so available on
AIX, I have to link my .so with libpython2.6.a. I have to make some
twist to make it compile. And so far so good until I run my main. My
embedding python .so give me error like the following
Fatal Python error: Interpreter not initialized (version mismatch?)
I check the initialization status by calling Py_IsInitialized and it
said yes. So I'm wondering if this embedding python into .so ever work
on AIX.
I have no problem to do the same thing on linux, solaris since python
has libpython2.6.so on both system. But our system needs the supoort on
AIX. My embedding python is very simple like the following

#include <Python.h>
#include <iostream>

extern "C"
void allocate()
{
    std::cout << " am i ok = " << Py_IsInitialized() << std::endl;
    
    Py_InitializeEx(0);
    std::cout << " am i ok 1 = " << Py_IsInitialized() << std::endl;
    
    PyRun_SimpleString("from time import time, datetime, ctime\n"
                       "print 'Today is',ctime(time())\n");
    Py_Finalize();
}

my main application is also very simple
#include <iostream>
#include <iomanip>
#include <dlfcn.h>
//#include <link.h>
#include <Python.h>

typedef  void (*ALLOCATE)();

int main (int argc, char ** argv)
{
    // parse params to load shared object
    if (argc < 2)
    {
	std::cerr << "Usage: " << argv[0] << " sharedObject(s)" << std::endl;
	return 0;
    }

    //    Py_Initialize();
    
    for (int i = 1; i < argc; ++i)
    {
	void * handle = ::dlopen(argv[i], RTLD_LAZY);
	if (!handle)
	{
	    std::cerr << dlerror() << argv[i] << std::endl;
	
	    return 0;
	}
	
	// Use that handle to locate the symbol.  The symbol must be 
	// demangled so it has to be compiled with extern "C".
	ALLOCATE dlmAllocate = (ALLOCATE) ::dlsym(handle, "allocate");
	if (!dlmAllocate)
	{
	    std::cerr << dlerror() << std::endl;
	    return 0;
	}
    
	dlmAllocate();
    }


    return 0;
}

here is my makefile

CXX := g++

default: DLOpenTest mypython.so

DLOpenTest: DLOpen.C
	$(CXX) -o DLOpenTest DLOpen.C -ldl
-Wl,-bE:/mnts/cdstools/Python-2.6.2/aix-ppc-5.3/lib/python2.6/config/python.exp
-lld -I/mnts/cdstools/Python-2.6.2/aix-ppc-5.3/include/python2.6
-L/mnts/cdstools/Python-2.6.2/aix-ppc-5.3/lib/ -lpython2.6 -lpthread

mypython.so: mypython.C
	$(CXX) -shared -nostartfiles
-I/mnts/cdstools/Python-2.6.2/aix-ppc-5.3/include/python2.6
-L/mnts/cdstools/Python-2.6.2/aix-ppc-5.3/lib/ -lpython2.6 -lpthread -o
mypython.so mypython.C


clean:
	rm *.o DLOpenTest mypython.so

Can someone help me out? Or has anyone even tried same thing on AIX?

NOTE, the issue is not like issue 4434 or 1332869. Please don't reply
this issue with those two number. I've seen them already. It's not helpful

Thanks a log

----------
components: Interpreter Core
messages: 91773
nosy: damahay123
severity: normal
status: open
title: Embedding python into shared library crash on AIX
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6742>
_______________________________________

From report at bugs.python.org  Thu Aug 20 16:21:06 2009
From: report at bugs.python.org (Mary Stern)
Date: Thu, 20 Aug 2009 14:21:06 +0000
Subject: [New-bugs-announce] [issue6743] pprint.pprint should support no
	objects to print blank	lines & allow args
In-Reply-To: <1250778066.89.0.880851114314.issue6743@psf.upfronthosting.co.za>
Message-ID: <1250778066.89.0.880851114314.issue6743@psf.upfronthosting.co.za>


New submission from Mary Stern <marystern at yahoo.com>:

Using print in python 3 I would like to simple "replace" print with
pprint.pprint. However pprint cannot be called with no arguments, so
this cannot currently be done (the error is "TypeError: pprint() takes
at least 1 positional argument (0 given)").

A simple improvement is to allow no object to be passed in and pprint
would then print a newline rather than fail.

Another problem is that if you try this:

 print('hello', True)

and replace print with print, the second arg gets interpreted as the
"stream" parameter.


Both of the above can be fixed (I think) by changing pprint.py as follows:

instead of the current code:
def pprint(object, stream=None, indent=1, width=80, depth=None):

change to this:
def pprint(object='\n', *args, stream=None, indent=1, width=80, depth=None)

----------
messages: 91774
nosy: marystern
severity: normal
status: open
title: pprint.pprint should support no objects to print blank lines & allow args
type: feature request
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6743>
_______________________________________

From report at bugs.python.org  Thu Aug 20 22:41:29 2009
From: report at bugs.python.org (Jessica McKellar)
Date: Thu, 20 Aug 2009 20:41:29 +0000
Subject: [New-bugs-announce] [issue6744] calling kevent repr raises a
	TypeError
In-Reply-To: <1250800889.41.0.974799993123.issue6744@psf.upfronthosting.co.za>
Message-ID: <1250800889.41.0.974799993123.issue6744@psf.upfronthosting.co.za>


New submission from Jessica McKellar <jessica.mckellar at gmail.com>:

kqueue_event_repr uses PyBytes_FromString when every other repr uses
PyUnicode_FromString, and this gets you a "TypeError: __repr__ returned
non-string (type bytes)". The patch swaps in PyUnicode_FromString and
adds a very simple unittest to test_kqueue.

----------
components: Extension Modules
files: kqueue-event-repr.patch
keywords: patch
messages: 91782
nosy: jesstess
severity: normal
status: open
title: calling kevent repr raises a TypeError
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14749/kqueue-event-repr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6744>
_______________________________________

From report at bugs.python.org  Thu Aug 20 23:54:53 2009
From: report at bugs.python.org (Trundle)
Date: Thu, 20 Aug 2009 21:54:53 +0000
Subject: [New-bugs-announce] [issue6745] (curses) addstr() takes str in
	Python 3
In-Reply-To: <1250805293.93.0.390407784339.issue6745@psf.upfronthosting.co.za>
Message-ID: <1250805293.93.0.390407784339.issue6745@psf.upfronthosting.co.za>


New submission from Trundle <andy-python at hammerhartes.de>:

In Python 3, curses requires a str for addstr() where I think it should
take bytes instead. Otherwise it is impossible to output anything other
than ASCII (which is even more or less stated on top of curses'
documentation).

See the attached script "umlaut2x.py" for Python 2.6: Outputting
umlauts works fine, both in single-byte and multi-byte environments.

The attached script "umlaut3x.py" is the same script translated to
Python 3. Note that the output here always seems to be utf-8, which is
plain wrong.

A quick test where I changed addstr() to take bytes instead of str
confirmed that outputting other characters than ASCII would work then
in Python 3, too. There are perhaps more places where the types are
wrong. If someone confirms this issue and it is desired, I could
provide a patch.

----------
components: Library (Lib)
files: umlaut2x.py
messages: 91786
nosy: Trundle
severity: normal
status: open
title: (curses) addstr() takes str in Python 3
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file14750/umlaut2x.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6745>
_______________________________________

From report at bugs.python.org  Fri Aug 21 01:05:00 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 20 Aug 2009 23:05:00 +0000
Subject: [New-bugs-announce] [issue6746] ValueError raised by IDLE during
	tooltip open on 64-bit	Centos 5.3
In-Reply-To: <1250809500.9.0.805893080789.issue6746@psf.upfronthosting.co.za>
Message-ID: <1250809500.9.0.805893080789.issue6746@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

Linux (Centos 5.3) 32-bit with Python 2.5.4

1. Start an idle session.
2. enter "help(" at the prompt

The open bracket triggers a traceback in the console:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/home/qatest/APyE/lib/python2.5/lib-tk/Tkinter.py", line 1414, 
in
__call__
    return self.func(*args)
  File "/home/qatest/APyE/lib/python2.5/idlelib/MultiCall.py", line 
151, in
handler
    r = l[i](event)
  File "/home/qatest/APyE/lib/python2.5/idlelib/CallTips.py", line 55, 
in
try_open_calltip_event
    self.open_calltip(False)
  File "/home/qatest/APyE/lib/python2.5/idlelib/CallTips.py", line 79, 
in
open_calltip
    self.calltip.showtip(arg_text, sur_paren[0], sur_paren[1])
  File "/home/qatest/APyE/lib/python2.5/idlelib/CallTipWindow.py", line 
66, in
showtip
    self.position_window()
  File "/home/qatest/APyE/lib/python2.5/idlelib/CallTipWindow.py", line 
35, in
position_window
    self.parencol))
  File "/home/qatest/APyE/lib/python2.5/lib-tk/Tkinter.py", line 2857, 
in bbox
    self.tk.call((self._w, 'bbox') + args)) or None
  File "/home/qatest/APyE/lib/python2.5/lib-tk/Tkinter.py", line 1030, 
in
_getints
    return tuple(map(getint, self.tk.splitlist(string)))
ValueError: invalid literal for int() with base 10: '(71,'

Upon closing the bracket, another exception is thrown:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/home/qatest/APy/lib/python2.5/lib-tk/Tkinter.py", line 1414, 
in __call__
    return self.func(*args)
  File "/home/qatest/APy/lib/python2.5/idlelib/MultiCall.py", line 151, 
in handler
    r = l[i](event)
  File "/home/qatest/APy/lib/python2.5/idlelib/CallTips.py", line 55, 
in try_open_calltip_event
    self.open_calltip(False)
  File "/home/qatest/APy/lib/python2.5/idlelib/CallTips.py", line 65, 
in open_calltip
    self._remove_calltip_window()
  File "/home/qatest/APy/lib/python2.5/idlelib/CallTips.py", line 41, 
in _remove_calltip_window
    self.calltip.hidetip()
  File "/home/qatest/APy/lib/python2.5/idlelib/CallTipWindow.py", line 
126, in hidetip
    self.label.destroy()
AttributeError: 'NoneType' object has no attribute 'destroy'
Exception in Tkinter callback
Traceback (most recent call last):
  File "/home/qatest/APy/lib/python2.5/lib-tk/Tkinter.py", line 1414, 
in __call__
    return self.func(*args)
  File "/home/qatest/APy/lib/python2.5/idlelib/MultiCall.py", line 151, 
in handler
    r = l[i](event)
  File "/home/qatest/APy/lib/python2.5/idlelib/CallTips.py", line 62, 
in refresh_calltip_event
    self.open_calltip(False)
  File "/home/qatest/APy/lib/python2.5/idlelib/CallTips.py", line 65, 
in open_calltip
    self._remove_calltip_window()
  File "/home/qatest/APy/lib/python2.5/idlelib/CallTips.py", line 41, 
in _remove_calltip_window
    self.calltip.hidetip()
  File "/home/qatest/APy/lib/python2.5/idlelib/CallTipWindow.py", line 
126, in hidetip
    self.label.destroy()
AttributeError: 'NoneType' object has no attribute 'destroy'
            

Tix version = 8.4.3
Tcl/Tk version = 8.5.7

This happens only on 64-bit (not 32-bit).

----------
components: IDLE
messages: 91793
nosy: srid
severity: normal
status: open
title: ValueError raised by IDLE during tooltip open on 64-bit Centos 5.3
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6746>
_______________________________________

From report at bugs.python.org  Fri Aug 21 02:09:46 2009
From: report at bugs.python.org (Thomas Kowaliczek)
Date: Fri, 21 Aug 2009 00:09:46 +0000
Subject: [New-bugs-announce] [issue6747] test test_multiprocessing failed
In-Reply-To: <1250813386.91.0.61030699326.issue6747@psf.upfronthosting.co.za>
Message-ID: <1250813386.91.0.61030699326.issue6747@psf.upfronthosting.co.za>


New submission from Thomas Kowaliczek <linuxdonald at linuxdonald.de>:

test test_multiprocessing failed -- Traceback (most recent call last):
  File
"/home/LinuxDonald/Downloads/Python-3.1.1/Lib/test/test_multiprocessing.py",
line 1077, in test_number_of_objects
    self.assertEqual(refs, EXPECTED_NUMBER)
AssertionError: 4 != 1

----------
components: Tests
messages: 91797
nosy: LinuxDonald
severity: normal
status: open
title: test test_multiprocessing failed
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6747>
_______________________________________

From report at bugs.python.org  Fri Aug 21 02:10:35 2009
From: report at bugs.python.org (Thomas Kowaliczek)
Date: Fri, 21 Aug 2009 00:10:35 +0000
Subject: [New-bugs-announce] [issue6748] test test_telnetlib failed
In-Reply-To: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
Message-ID: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>


New submission from Thomas Kowaliczek <linuxdonald at linuxdonald.de>:

test test_telnetlib failed -- Traceback (most recent call last):
  File
"/home/LinuxDonald/Downloads/Python-3.1.1/Lib/test/test_telnetlib.py",
line 409, in test_debuglevel
    self._test_debuglevel([a, EOF_sigil], b)
  File
"/home/LinuxDonald/Downloads/Python-3.1.1/Lib/test/test_telnetlib.py",
line 389, in _test_debuglevel
    txt = telnet.read_all()
  File "/home/LinuxDonald/Downloads/Python-3.1.1/Lib/telnetlib.py", line
325, in read_all
    self.fill_rawq()
  File "/home/LinuxDonald/Downloads/Python-3.1.1/Lib/telnetlib.py", line
516, in fill_rawq
    buf = self.sock.recv(50)
socket.error: [Errno 104] Connection reset by peer

----------
components: Tests
messages: 91798
nosy: LinuxDonald
severity: normal
status: open
title: test test_telnetlib failed
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6748>
_______________________________________

From report at bugs.python.org  Fri Aug 21 06:51:43 2009
From: report at bugs.python.org (Peter Manis)
Date: Fri, 21 Aug 2009 04:51:43 +0000
Subject: [New-bugs-announce] [issue6749] Support for encrypted zipfiles when
	interpreting zipfile	as script
In-Reply-To: <1250830303.29.0.377270089004.issue6749@psf.upfronthosting.co.za>
Message-ID: <1250830303.29.0.377270089004.issue6749@psf.upfronthosting.co.za>


New submission from Peter Manis <peter.manis at gmail.com>:

The zipfile support in 2.6 that allows you pass a zipfile(with __main__.py 
inside) as the "script", does not support encrypted zipfiles.  I view this 
as being a feature that could be useful to some.

----------
components: Library (Lib)
messages: 91800
nosy: manis
severity: normal
status: open
title: Support for encrypted zipfiles when interpreting zipfile as script
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6749>
_______________________________________

From report at bugs.python.org  Fri Aug 21 09:28:29 2009
From: report at bugs.python.org (Jackson Yang)
Date: Fri, 21 Aug 2009 07:28:29 +0000
Subject: [New-bugs-announce] [issue6750] threading issue in
	__builtins__.print
In-Reply-To: <1250839709.71.0.595068140402.issue6750@psf.upfronthosting.co.za>
Message-ID: <1250839709.71.0.595068140402.issue6750@psf.upfronthosting.co.za>


New submission from Jackson Yang <jackson.yang at augmentum.com>:

# Bug Description
In a multi-threaded environment, the Win32 Python3000 built-in function
"print" may give the output several times.

# How to Reproduce:
import threading
event = threading.Event()
class Test(threading.Thread):
    def __init__(self, ord):
        super().__init__()
        self.ord = ord
    def run(self):
        event.wait()
        print('Hello, world!', self.ord)
threads = tuple(map(Test, range(8)))
tuple(map(lambda thread: thread.start(), threads))
event.set()
tuple(map(lambda thread: thread.join(), threads))
# EOF

# Problem Observed
[The first run, 0 is doubled]
Hello, world! 0
Hello, world! 0
Hello, world! 1
Hello, world! 2
Hello, world! 3
Hello, world! 4
Hello, world! 5
Hello, world! 6
Hello, world! 7

[the second run, 1 and 7 are doubled]
Hello, world! 1
Hello, world! 1
Hello, world! 2
Hello, world! 3
Hello, world! 4
Hello, world! 5
Hello, world! 6
Hello, world! 7
Hello, world! 7
Hello, world! 0

# Expected Result
Each thread gives ONE AND ONLY ONE output.
OR
State this as The Expected Behavior, document it and ask the user to
write something such as critical section.

----------
components: IO
messages: 91807
nosy: nullnil
severity: normal
status: open
title: threading issue in __builtins__.print
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6750>
_______________________________________

From report at bugs.python.org  Fri Aug 21 10:57:57 2009
From: report at bugs.python.org (Juan Javier)
Date: Fri, 21 Aug 2009 08:57:57 +0000
Subject: [New-bugs-announce] [issue6751] Default return value in ConfigParser
In-Reply-To: <1250845077.86.0.224640008074.issue6751@psf.upfronthosting.co.za>
Message-ID: <1250845077.86.0.224640008074.issue6751@psf.upfronthosting.co.za>


New submission from Juan Javier <jjdominguezm at yahoo.com>:

I think it is useful, at least for me, to add an argument, default, to
[Safe,Raw]ConfigParser.get that, if present, will be returned if the
methid fails to return the value.

That is, instead of rasing an exception, return default, if present.

It could be done overriding the get method in SafeConfigParser,
something like this:

class SafeConfigParser(ConfigParser):
    def get(self, section, option, raw=False, vars=None, **kwds):
        try:
            return super().get(section, option, raw, vars)
        except Exception as exc:
            if "default" in kwds:
                return kwds["default"]
            raise exc

----------
components: Library (Lib)
messages: 91808
nosy: jjdominguezm
severity: normal
status: open
title: Default return value in ConfigParser
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6751>
_______________________________________

From report at bugs.python.org  Fri Aug 21 10:58:57 2009
From: report at bugs.python.org (rahul)
Date: Fri, 21 Aug 2009 08:58:57 +0000
Subject: [New-bugs-announce] [issue6752] -1**2=-1
In-Reply-To: <1250845137.04.0.311672819223.issue6752@psf.upfronthosting.co.za>
Message-ID: <1250845137.04.0.311672819223.issue6752@psf.upfronthosting.co.za>


New submission from rahul <rahulalone1618 at gmail.com>:

what is the reason for this ????

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 91809
nosy: rahul1618
severity: normal
status: open
title: -1**2=-1
type: compile error
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6752>
_______________________________________

From report at bugs.python.org  Fri Aug 21 12:11:11 2009
From: report at bugs.python.org (Guillaume Delcourt-Petetin)
Date: Fri, 21 Aug 2009 10:11:11 +0000
Subject: [New-bugs-announce] [issue6753] Python 3.1.1 test_cmd_line fails on
	Fedora 11
In-Reply-To: <1250849471.77.0.183054552926.issue6753@psf.upfronthosting.co.za>
Message-ID: <1250849471.77.0.183054552926.issue6753@psf.upfronthosting.co.za>


New submission from Guillaume Delcourt-Petetin <gpetetin at gmail.com>:

Just what it says on the label :

[...]
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 618, in runtest_inner
    indirect_test()
  File
"/home/Pif/T?l?chargement/Python-3.1.1/Python-3.1.1/Lib/test/test_cmd_l
    test.support.run_unittest(CmdLineTest)
  File
"/home/Pif/T?l?chargement/Python-3.1.1/Python-3.1.1/Lib/test/support.py
    _run_suite(suite)
  File
"/home/Pif/T?l?chargement/Python-3.1.1/Python-3.1.1/Lib/test/support.py
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File
"/home/Pif/T?l?chargement/Python-3.1.1/Python-3.1.1/Lib/test/test_cmd_l
    self.assertTrue(path1.encode('ascii') in stdout)
AssertionError: False is not True


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 1222, in <module>
    main()
  File "./Lib/test/regrtest.py", line 425, in main
    testdir, huntrleaks)
  File "./Lib/test/regrtest.py", line 584, in runtest
    testdir, huntrleaks)
  File "./Lib/test/regrtest.py", line 638, in runtest_inner
    print("test", test, "failed --", msg)
UnicodeEncodeError: 'ascii' codec can't encode character '\xe9' in
position 54: ordinal not in range(128)
test test_cmd_line failed -- make: *** [test] Erreur 1

[...]


In my search for similar bugs, I only found a mac OSX/Python 3.0 issue
(http://bugs.python.org/issue4388)

----------
components: Tests
messages: 91813
nosy: Pif
severity: normal
status: open
title: Python 3.1.1 test_cmd_line fails on Fedora 11
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6753>
_______________________________________

From report at bugs.python.org  Fri Aug 21 12:53:16 2009
From: report at bugs.python.org (KAJIYAMA, Tamito)
Date: Fri, 21 Aug 2009 10:53:16 +0000
Subject: [New-bugs-announce] [issue6754] Non-existent member
	'nb_inplace_divide' in PyNumberMethods
In-Reply-To: <1250851996.63.0.670347243231.issue6754@psf.upfronthosting.co.za>
Message-ID: <1250851996.63.0.670347243231.issue6754@psf.upfronthosting.co.za>


New submission from KAJIYAMA, Tamito <rd6t-kjym at asahi-net.or.jp>:

In the "Python/C API Reference Manual", Section "Object Implementation 
Support", Subsection "Number Object Structures" 
(http://docs.python.org/3.1/c-api/typeobj.html#number-object-
structures), the definition of the PyNumberMethods structure has a non-
existent member 'nb_inplace_divide'.  This should be simply omitted.

----------
assignee: georg.brandl
components: Documentation
messages: 91814
nosy: georg.brandl, kajiyama
severity: normal
status: open
title: Non-existent member 'nb_inplace_divide' in PyNumberMethods
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6754>
_______________________________________

From report at bugs.python.org  Fri Aug 21 13:43:32 2009
From: report at bugs.python.org (=?utf-8?q?I=C3=B1igo_Serna?=)
Date: Fri, 21 Aug 2009 11:43:32 +0000
Subject: [New-bugs-announce] [issue6755] Patch: new method get_wch for
	ncurses bindings: accept	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>


New submission from I?igo Serna <inigoserna at gmail.com>:

Currently,there is no a simple way in curses bindings to get the code
associated with a key press of non ascii keystroke (f.e. ?) in terminals
configured with UTF-8 encoding. 

getch returns the code for a wide character byte a byte.
But ncurses library has a proper function to do it: get_wch.

Patch against Python v2.6.2 to provide this missing get_wch method
in the ncurses bindings.

Include a test example and a patch to the documentation as well.

More info and a partial solution without patching python curses module
on this thread:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/67dce30f0a2742a6?fwc=2

----------
components: Extension Modules
messages: 91816
nosy: inigoserna
severity: normal
status: open
title: Patch: new method get_wch for ncurses bindings: accept wide characters (unicode)
type: feature request
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Fri Aug 21 14:17:01 2009
From: report at bugs.python.org (Tarjei Huse)
Date: Fri, 21 Aug 2009 12:17:01 +0000
Subject: [New-bugs-announce] [issue6756] ftplib documentation does not
	document what the acct	parameter is used for
Message-ID: <1250857021.21.0.232003333024.issue6756@psf.upfronthosting.co.za>


Changes by Tarjei Huse <tarjei at scanmine.com>:


----------
assignee: georg.brandl
components: Documentation
nosy: georg.brandl, tarjei
severity: normal
status: open
title: ftplib documentation does not document what the acct parameter is used for
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6756>
_______________________________________

From report at bugs.python.org  Fri Aug 21 17:48:55 2009
From: report at bugs.python.org (Demur Rumed)
Date: Fri, 21 Aug 2009 15:48:55 +0000
Subject: [New-bugs-announce] [issue6757] Marshal's documentation incomplete
In-Reply-To: <1250869735.91.0.499827102331.issue6757@psf.upfronthosting.co.za>
Message-ID: <1250869735.91.0.499827102331.issue6757@psf.upfronthosting.co.za>


New submission from Demur Rumed <junkmute at hotmail.com>:

"The following types are supported: None, integers, floating point
numbers, strings, bytes, bytearrays, tuples, lists, sets, dictionaries,
and code objects"

It fails to list bools: True and False

While it states "Not all Python object types are supported; in general,
only objects whose value is independent from a particular invocation of
Python can be written and read by this module." beforehand, it seems
proper to include bools in the list of accepted types

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 91831
nosy: georg.brandl, serprex
severity: normal
status: open
title: Marshal's documentation incomplete
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6757>
_______________________________________

From report at bugs.python.org  Fri Aug 21 20:49:37 2009
From: report at bugs.python.org (Travis H.)
Date: Fri, 21 Aug 2009 18:49:37 +0000
Subject: [New-bugs-announce] [issue6758] implement new setuid-related calls
	and a standard way to	drop all privileges
In-Reply-To: <1250880577.62.0.941118593261.issue6758@psf.upfronthosting.co.za>
Message-ID: <1250880577.62.0.941118593261.issue6758@psf.upfronthosting.co.za>


New submission from Travis H. <travis+w-python.org at subspacefield.org>:

It should be easier to write network servers and setuid programs in
python.  One of the troublesome issues is that the semantics of the
setuid/getuid-related calls are quite complicated.

There are two papers on this subject that form the background of this
feature request:
http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf
http://www.cs.berkeley.edu/~daw/papers/setuid-login08b.pdf

In general, then, the end goal is a safe (portable, secure) way to drop
privileges either temporarily or permanently.

Wagner et. al. have proposed a decent interface, but it's unclear to me
where it should be implemented.

Furthermore, it makes use of the getresuid/setresuid calls (among many
others), which don't appear from their manpages to be standardized by
POSIX, but are available in most modern Unix OSes.  So this leaves me
with two questions; have these functions been standardized, and if not,
where should they be implemented?

I'm willing to do the coding, but need some guidance on where to put the
code.

----------
messages: 91835
nosy: solinym
severity: normal
status: open
title: implement new setuid-related calls and a standard way to drop all privileges
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6758>
_______________________________________

From report at bugs.python.org  Sat Aug 22 08:22:02 2009
From: report at bugs.python.org (Ryan Leslie)
Date: Sat, 22 Aug 2009 06:22:02 +0000
Subject: [New-bugs-announce] [issue6759] zipfile.ZipExtFile.read() is
	missing universal newline	support
In-Reply-To: <1250922122.86.0.650490470964.issue6759@psf.upfronthosting.co.za>
Message-ID: <1250922122.86.0.650490470964.issue6759@psf.upfronthosting.co.za>


New submission from Ryan Leslie <rylesny at gmail.com>:

The zipfile.ZipFile.open() behavior with mode 'U' or 'rU' is not quite
as advertised in

http://docs.python.org/library/zipfile.html#zipfile.ZipFile.open

Here is an example:

$ echo -ne "This is an example\r\nWhich demonstrates a problem\r\nwith
ZipFile.open(..., 'U')\r\n" > foo.txt
$ cat -v foo.txt
This is an example^M
Which demonstrates a problem^M
with ZipFile.open(..., 'U')^M
$ zip foo.zip foo.txt
  adding: foo.txt (deflated 1%)
$ python
Python 2.6.2 (r262:71600, Aug 21 2009, 17:52:12)
[GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> open("foo.txt", 'U').read()
"This is an example\nWhich demonstrates a problem\nwith
ZipFile.open(..., 'U')\n"
>>> from zipfile import ZipFile
>>> ZipFile("foo.zip").open("foo.txt", 'U').read()
"This is an example\r\nWhich demonstrates a problem\r\nwith
ZipFile.open(..., 'U')\r\n"
>>>

The open() method was added here:

http://bugs.python.org/issue1121142

The cause is that the universal newline implementation is specific to
readline(), which also implements readlines() and next() as well.
Support was never added for read(), which is independent.

Note that test_zipfile.UniversalNewlineTests.readTest() passes. This is
suspect because it's explicitly coded to *not* expect translation of new
line sequences.

----------
components: Library (Lib)
messages: 91854
nosy: ryles
severity: normal
status: open
title: zipfile.ZipExtFile.read() is missing universal newline support
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6759>
_______________________________________

From report at bugs.python.org  Sat Aug 22 12:40:33 2009
From: report at bugs.python.org (Chris Rebert)
Date: Sat, 22 Aug 2009 10:40:33 +0000
Subject: [New-bugs-announce] [issue6760] patch to subprocess docs to better
	explain Popen's 'args'	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>


New submission from Chris Rebert <pybugs at rebertia.com>:

>From what I've seen on several c.l.p threads, some people have a tough
time figuring the correct 'args' argument to subprocess.Popen's
constructor. In an effort to cut down on such discussions in the future,
I've written the attached docs patch to better explain the subject.

I'm not an rst/Sphinx guru and thus was unable to actually test the
patch, so there might be some (hopefully minor) formatting errors.

----------
assignee: georg.brandl
components: Documentation
files: subprocess.rst.patch
keywords: patch
messages: 91859
nosy: cvrebert, georg.brandl
severity: normal
status: open
title: patch to subprocess docs to better explain Popen's 'args' argument
versions: Python 2.6
Added file: http://bugs.python.org/file14770/subprocess.rst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6760>
_______________________________________

From report at bugs.python.org  Sat Aug 22 19:13:59 2009
From: report at bugs.python.org (Stephen Fairchild)
Date: Sat, 22 Aug 2009 17:13:59 +0000
Subject: [New-bugs-announce] [issue6761] Class calling
In-Reply-To: <1250961239.16.0.126736964049.issue6761@psf.upfronthosting.co.za>
Message-ID: <1250961239.16.0.126736964049.issue6761@psf.upfronthosting.co.za>


New submission from Stephen Fairchild <signupaddress at bethere.co.uk>:

From:
http://docs.python.org/reference/datamodel.html#the-standard-type-hierarchy

"Class instances
    Class instances are described below. Class instances are callable
only when the class has a __call__() method; x(arguments) is a shorthand
for x.__call__(arguments)."

The following program demonstrates otherwise regarding that last statement. 

def call(self):
    print "inserted __call__ in object of class A"

class A(object):
    def __call__(self):
        print "__call__ method in class A"
        
x = A()               # Equates: x = type(A).__call__(A)
x.__call__ = call

x()                   # Calls the method of class A.
x.__call__(x)         # Calls function "call".
type(x).__call__(x)   # The correct longhand of x() IMHO


If I were to rephrase the documentation:
"Class instances
    Class instances are described below. Class instances are callable
only when the class has a __call__() method; x(arguments) is a shorthand
for type(x).__call__(x, arguments)."

----------
assignee: georg.brandl
components: Documentation
messages: 91864
nosy: georg.brandl, onlyme
severity: normal
status: open
title: Class calling
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6761>
_______________________________________

From report at bugs.python.org  Sat Aug 22 21:12:20 2009
From: report at bugs.python.org (Mintaka)
Date: Sat, 22 Aug 2009 19:12:20 +0000
Subject: [New-bugs-announce] [issue6762] strange string representation of
	xrange in print
In-Reply-To: <1250968340.58.0.478477907223.issue6762@psf.upfronthosting.co.za>
Message-ID: <1250968340.58.0.478477907223.issue6762@psf.upfronthosting.co.za>


New submission from Mintaka <mintaka at post.cz>:

String representation of xrange return keyword with value.

foo = xrange(5)
print foo
>>> xrange(5)
foo.__str__() 
>>> xrange(5)

I think, that expected result should be somethink like this:
>>> <xrange object at 0x00AFB970>

----------
components: Interpreter Core
messages: 91871
nosy: mintaka
severity: normal
status: open
title: strange string representation of  xrange in print
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6762>
_______________________________________

From report at bugs.python.org  Sat Aug 22 23:26:36 2009
From: report at bugs.python.org (Leonardo Santagada)
Date: Sat, 22 Aug 2009 21:26:36 +0000
Subject: [New-bugs-announce] [issue6763] Crash on mac os x leopard in
	mimetypes.guess_type (or	PyObject_Malloc)
In-Reply-To: <1250976396.98.0.596987057251.issue6763@psf.upfronthosting.co.za>
Message-ID: <1250976396.98.0.596987057251.issue6763@psf.upfronthosting.co.za>


New submission from Leonardo Santagada <santagada at gmail.com>:

Python 2.6.2 (and the maint branch if using old mimetypes.py) crash
(with a bus error) on mac os x (10.5.7 & 10.5.8) with the file I posted.
The problem appears to be in the allocation of memory by the GC.

What I do is I call mimetypes.guess_type in more than one thread at the
same time, then I guess what is happening is this:

1. The first thread to run notices mimetypes.inited is false so it call
its init funtion.
2. Somehow the first thread loses the gil while still executing the init
3. Another thread tries to execute guess_type as it is already inited it
calls itself, in vain as the init still hasn't exchanged it value for
the new function so it goes into recursion
4. Somehow the allocator fails during the recursion

here is the final pieces of my stack trace (its a very long sequence of
recursions into guess_type):

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0xb0000ffc
[Switching to process 61544 thread 0x117]
0x96912122 in szone_malloc ()

#0  0x96912122 in szone_malloc ()
#1  0x969120d8 in malloc_zone_malloc ()
#2  0x9691206c in malloc ()
#3  0x0006f32c in PyObject_Malloc (nbytes=376) at Objects/obmalloc.c:913
913             return (void *)malloc(nbytes);
#4  0x0006fe61 in _PyObject_DebugMalloc (nbytes=360) at
Objects/obmalloc.c:1347
1347            p = (uchar *)PyObject_Malloc(total);
#5  0x00149b13 in _PyObject_GC_Malloc (basicsize=344) at
Modules/gcmodule.c:1351
1351            g = (PyGC_Head *)PyObject_MALLOC(
#6  0x00149c24 in _PyObject_GC_NewVar (tp=0x193500, nitems=5) at
Modules/gcmodule.c:1383
1383            PyVarObject *op = (PyVarObject *) _PyObject_GC_Malloc(size);
#7  0x00048a06 in PyFrame_New (tstate=0x33df30, code=0x473148,
globals=0x48e380, locals=0x0) at Objects/frameobject.c:642
642                         f = PyObject_GC_NewVar(PyFrameObject,
&PyFrame_Type,
#8  0x00100816 in PyEval_EvalCodeEx (co=0x473148, globals=0x48e380,
locals=0x0, args=0x374fb4, argcount=2, kws=0x374fbc, kwcount=0,
defs=0x4a6f9c, defcount=1, closure=0x0) at Python/ceval.c:2755
2755            f = PyFrame_New(tstate, co, globals, locals);

----------
components: Interpreter Core
messages: 91876
nosy: santagada
severity: normal
status: open
title: Crash on mac os x leopard in mimetypes.guess_type (or PyObject_Malloc)
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6763>
_______________________________________

From report at bugs.python.org  Sat Aug 22 23:58:20 2009
From: report at bugs.python.org (Michael Foord)
Date: Sat, 22 Aug 2009 21:58:20 +0000
Subject: [New-bugs-announce] [issue6764] os.path.join should call
	os.path.normpath on result
In-Reply-To: <1250978300.82.0.388700146975.issue6764@psf.upfronthosting.co.za>
Message-ID: <1250978300.82.0.388700146975.issue6764@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

os.path.join has very basic behavior in the handling of '..'

>>> import os
>>> os.path.join('/foo', '..')
'/foo/..'

For some usecases (comparing paths for example) this is not useful and
you have to manually call normpath on the results:

>>> os.path.normpath(os.path.join('/foo', '..'))
'/'

Because of this code gets littered with annoyingly long chained calls
which are a pain to both read and write.

Is there any problem with join always calling normpath on it's result?

----------
components: Library (Lib)
keywords: easy
messages: 91877
nosy: michael.foord
severity: normal
status: open
title: os.path.join should call os.path.normpath on result
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6764>
_______________________________________

From report at bugs.python.org  Sun Aug 23 13:56:17 2009
From: report at bugs.python.org (steve21)
Date: Sun, 23 Aug 2009 11:56:17 +0000
Subject: [New-bugs-announce] [issue6765] math.log, log10 inconsistency
In-Reply-To: <1251028577.65.0.346592203273.issue6765@psf.upfronthosting.co.za>
Message-ID: <1251028577.65.0.346592203273.issue6765@psf.upfronthosting.co.za>


New submission from steve21 <steve872929-bv at yahoo.com.au>:

$ python3.1
Python 3.1 (r31:73572, Jul  6 2009, 21:21:12) 
[GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> math.log10(1000)
3.0
>>> math.log(1000, 10)
2.9999999999999996

You would expect the results to be the same.
Internally math.log() could call math.log10() when base==10. That would
ensure they are consistent.

----------
components: Library (Lib)
messages: 91886
nosy: steve21
severity: normal
status: open
title: math.log, log10 inconsistency
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6765>
_______________________________________

From report at bugs.python.org  Sun Aug 23 19:46:30 2009
From: report at bugs.python.org (Carlos)
Date: Sun, 23 Aug 2009 17:46:30 +0000
Subject: [New-bugs-announce] [issue6766] Cannot modify dictionaries inside
	dictionaries using	Managers from multiprocessing
In-Reply-To: <1251049590.58.0.809281249474.issue6766@psf.upfronthosting.co.za>
Message-ID: <1251049590.58.0.809281249474.issue6766@psf.upfronthosting.co.za>


New submission from Carlos <carlosdf at gmail.com>:

It's not possible to modify a dict inside a dict using a manager from 
multiprocessing.

Ex:

from multiprocessing import Process,Manager

def f(d):
    d['1'] = '1'
    d['2']['1'] = 'Try To Write'

if __name__ == '__main__':
    manager = Manager()

    d = manager.dict()

    d['2'] = manager.dict()

    print d

    p = Process(target=f, args=(d,))
    p.start()
    p.join()

    print d

    d['2'] = 5
    print d

The output Under Windows 7 (32 Bits) / Python 2.6.2 (32 Bits) is:

{'2': {}}
{'1': '1', '2': {}}
{'1': '1', '2': 5}

The output is the same if you change "d['2'] = manager.dict()" to 
"d['2'] = dict()"

----------
messages: 91889
nosy: carlosdf
severity: normal
status: open
title: Cannot modify dictionaries inside dictionaries using Managers from multiprocessing
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6766>
_______________________________________

From report at bugs.python.org  Sun Aug 23 21:18:04 2009
From: report at bugs.python.org (Joe)
Date: Sun, 23 Aug 2009 19:18:04 +0000
Subject: [New-bugs-announce] [issue6767] Python as zip package
In-Reply-To: <1251055084.86.0.380611427173.issue6767@psf.upfronthosting.co.za>
Message-ID: <1251055084.86.0.380611427173.issue6767@psf.upfronthosting.co.za>


New submission from Joe <us3r07 at web.de>:

It would be nice, if you could offer the Windows version also as a zi
package, besides the msi installer.

----------
components: Windows
messages: 91890
nosy: Joe
severity: normal
status: open
title: Python as zip package
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6767>
_______________________________________

From report at bugs.python.org  Sun Aug 23 23:02:35 2009
From: report at bugs.python.org (Daniel Keysers)
Date: Sun, 23 Aug 2009 21:02:35 +0000
Subject: [New-bugs-announce] [issue6768] asyncore file_wrapper leaking file
	descriptors?
In-Reply-To: <1251061355.88.0.439878311774.issue6768@psf.upfronthosting.co.za>
Message-ID: <1251061355.88.0.439878311774.issue6768@psf.upfronthosting.co.za>


New submission from Daniel Keysers <dkeysers at gmail.com>:

I'm not very experienced in Python, but while tracking down an issue 
with a "too many open files" error I think I found a missing resource 
release in asyncore's file_wrapper. Since Rev. 64062 added the os.dup() 
in __init__ this class reads as follows:

if os.name == 'posix':
    import fcntl

    class file_wrapper:
        # Here we override just enough to make a file
        # look like a socket for the purposes of asyncore.
        # The passed fd is automatically os.dup()'d

        def __init__(self, fd):
            self.fd = os.dup(fd)

        def recv(self, *args):
            return os.read(self.fd, *args)

        def send(self, *args):
            return os.write(self.fd, *args)

        read = recv
        write = send

        def close(self):
            os.close(self.fd)

        def fileno(self):
            return self.fd


I think that a "def __del__(self): self.close()" or a variant thereof 
would solve the problem I was seeing since it would release the file 
descriptor acquired in __init__ by os.dup(). But since I don't know why 
the os.dup() was added in the first place I'm not sure if there aren't 
any arguments against this release. Any comment appreciated!

----------
components: Library (Lib)
messages: 91892
nosy: keysers
severity: normal
status: open
title: asyncore file_wrapper leaking file descriptors?
type: resource usage
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6768>
_______________________________________

From report at bugs.python.org  Mon Aug 24 00:20:13 2009
From: report at bugs.python.org (ivank)
Date: Sun, 23 Aug 2009 22:20:13 +0000
Subject: [New-bugs-announce] [issue6769] in xmlrpclib.py: NameError: global
	name 'HTTPSConnection'	is not defined
In-Reply-To: <1251066013.49.0.537044412879.issue6769@psf.upfronthosting.co.za>
Message-ID: <1251066013.49.0.537044412879.issue6769@psf.upfronthosting.co.za>


New submission from ivank <ivan at ludios.org>:

Line 1491 of xmlrpclib.py should be

self._connection = host, httplib.HTTPSConnection(chost, None, **(x509 or
{}))

instead of

self._connection = host, HTTPSConnection(chost, None, **(x509 or {}))

  File
"/opt/Python-latest/lib/python2.7/site-packages/bzrlib/plugins/launchpad/lp_registration.py",
line 166, in send_request
    result = method(*method_params)
  File "/opt/Python-latest/lib/python2.7/xmlrpclib.py", line 1224, in
__call__
    return self.__send(self.__name, args)
  File "/opt/Python-latest/lib/python2.7/xmlrpclib.py", line 1570, in
__request
    verbose=self.__verbose
  File "/opt/Python-latest/lib/python2.7/xmlrpclib.py", line 1264, in
request
    return self.single_request(host, handler, request_body, verbose)
  File "/opt/Python-latest/lib/python2.7/xmlrpclib.py", line 1284, in
single_request
    h = self.make_connection(host)
  File "/opt/Python-latest/lib/python2.7/xmlrpclib.py", line 1491, in
make_connection
    self._connection = host, HTTPSConnection(chost, None, **(x509 or {}))
NameError: global name 'HTTPSConnection' is not defined

bzr 1.15 on python 2.7a0 (linux2)


I think this has been broken for around two weeks, maybe more. I don't
know if this is broken in 3.x.

----------
components: Library (Lib)
messages: 91895
nosy: ivank
severity: normal
status: open
title: in xmlrpclib.py: NameError: global name 'HTTPSConnection' is not defined
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6769>
_______________________________________

From report at bugs.python.org  Mon Aug 24 03:18:43 2009
From: report at bugs.python.org (Radiant)
Date: Mon, 24 Aug 2009 01:18:43 +0000
Subject: [New-bugs-announce] [issue6770] PDF download links of docs for
	3.1.1 are broken
In-Reply-To: <1251076723.7.0.569922214039.issue6770@psf.upfronthosting.co.za>
Message-ID: <1251076723.7.0.569922214039.issue6770@psf.upfronthosting.co.za>


New submission from Radiant <newyorkdude999 at yahoo.com>:

At this time I cannot download any of the PDF documentation files for
Python 3.1.1 because I get the "Not Found" error for all four of them.
I'm referring to the files linked at
http://docs.python.org/3.1/download.html

----------
assignee: georg.brandl
components: Documentation
messages: 91898
nosy: Radiant, georg.brandl
severity: normal
status: open
title: PDF download links of docs for 3.1.1 are broken
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6770>
_______________________________________

From report at bugs.python.org  Mon Aug 24 09:33:56 2009
From: report at bugs.python.org (steve21)
Date: Mon, 24 Aug 2009 07:33:56 +0000
Subject: [New-bugs-announce] [issue6771] documentation/implementation error
In-Reply-To: <1251099236.05.0.0799674766136.issue6771@psf.upfronthosting.co.za>
Message-ID: <1251099236.05.0.0799674766136.issue6771@psf.upfronthosting.co.za>


New submission from steve21 <steve872929-bv at yahoo.com.au>:

The documentation and implementation disagree.

Documentation:
"Module curses.wrapper
    Convenience function to ensure proper terminal setup and resetting
on application entry and exit.
...

15.10. curses.wrapper ? Terminal handler for curses programs

This module supplies one function, wrapper() ...

curses.wrapper.wrapper(func, ...)
    Wrapper function that initializes curses ..
"

Implementation:
$ python3.1
Python 3.1.1 (r311:74480, Aug 24 2009, 14:50:57)
[GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import curses.wrapper as cw
>>> cw.wrapper
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'function' object has no attribute 'wrapper'


The 'curses.wrapper.wrapper' function no longer exists.
The 'curses.wrapper' module no longer exists, the module is now a function.

The problem is the line
  from curses.wrapper import wrapper
in curses/__init__.py - curses has clobbered its own namespace and made
the curses.wrapper module inaccessible.

Instead of this tortuous sequence of module hiding and namespace
clobbering it would be simpler to just place the curses.wrapper.wrapper
function in curses/__init__.py and do away with the need for the
curses.wrapper single-function-module.
And update the docs so:
  references to the curses.wrapper module are removed
  the function curses.wrapper.wrapper(func, ...) becomes
               curses.wrapper.(func, ...)

----------
components: Library (Lib)
messages: 91903
nosy: steve21
severity: normal
status: open
title: documentation/implementation error
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6771>
_______________________________________

From report at bugs.python.org  Mon Aug 24 09:40:39 2009
From: report at bugs.python.org (Mintaka)
Date: Mon, 24 Aug 2009 07:40:39 +0000
Subject: [New-bugs-announce] [issue6772] Missing alias utf-8 in Standard
	Encodings list.
In-Reply-To: <1251099639.65.0.386311489493.issue6772@psf.upfronthosting.co.za>
Message-ID: <1251099639.65.0.386311489493.issue6772@psf.upfronthosting.co.za>


New submission from Mintaka <mintaka at post.cz>:

On page 
http://docs.python.org/dev/3.0/library/codecs.html#standard-encodings
(and on the pages for older versions too)
in the table with review, is missing higly used alias "utf-8"

On that row is only:
Codec 	Aliases 	Languages
utf_8 	U8, UTF, utf8 	all languages
And probably there should be:
utf_8 	U8, UTF, utf8, utf-8 	all languages

----------
assignee: georg.brandl
components: Documentation
messages: 91904
nosy: georg.brandl, mintaka
severity: normal
status: open
title: Missing alias  utf-8 in  Standard Encodings list.
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6772>
_______________________________________

From report at bugs.python.org  Mon Aug 24 10:36:05 2009
From: report at bugs.python.org (Piotr Foltyn)
Date: Mon, 24 Aug 2009 08:36:05 +0000
Subject: [New-bugs-announce] [issue6773] subprocess issue on Win 7 x64
In-Reply-To: <1251102965.83.0.35212908562.issue6773@psf.upfronthosting.co.za>
Message-ID: <1251102965.83.0.35212908562.issue6773@psf.upfronthosting.co.za>


New submission from Piotr Foltyn <piotr.foltyn at displaylink.com>:

The sample code presented below produces error (screenshot available in 
attachment) on Windows 7 RC x64 with latest version of Python 2.6 
installed. Both 32bit and 64bit versions of Python 2.6 are affected by 
this issue. Python 3 executes this code flawlessly.
The problem seems to be related to stdout redirection. If the "stdout = 
PIPE" is omitted in the first statement of main() function, code 
executes properly but we don't have access to the processes output. If 
the line "Popen(["dir"], stdout = PIPE, shell = True)" is changed to 
"sin, sout = os.popen2(["dir"])" and os module is imported everything 
works fine. It doesn't matter what command is executed ("dir", "bcedit", 
"mspaint" etc)


import sys
from subprocess import Popen, PIPE
from multiprocessing import Process

def myProcess():
    Popen(["dir"], shell = True) # ERROR :(

def main():
    Popen(["dir"], stdout = PIPE, shell = True)
    Process(target = myProcess).start()
    return 0

if __name__ == "__main__":
    sys.exit(main())

----------
components: Library (Lib), Windows
files: Win7RCx64.jpg
messages: 91910
nosy: tesla
severity: normal
status: open
title: subprocess issue on Win 7 x64
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14777/Win7RCx64.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6773>
_______________________________________

From report at bugs.python.org  Mon Aug 24 10:45:21 2009
From: report at bugs.python.org (Nicolas Dumazet)
Date: Mon, 24 Aug 2009 08:45:21 +0000
Subject: [New-bugs-announce] [issue6774] socket.shudown documentation: on
	some platforms, closing one half closes the other half
In-Reply-To: <1251103521.34.0.917057608479.issue6774@psf.upfronthosting.co.za>
Message-ID: <1251103521.34.0.917057608479.issue6774@psf.upfronthosting.co.za>


New submission from Nicolas Dumazet <nicdumz at gmail.com>:

I had a bad time understanding what happens in Mac OS X after a shutdown
call: after calling shutdown(SH_WR) on side A, a corresponding
shutdown(SH_RD) on side B would raise a socket.error: socket is not
connected.
It is quite surprising when you are used to sockets in Linux, which
expect you to shut one end, and then the other one.

It turns out that under Mac OS X, a shutdown call closes the connection
on the other half. And the only mention I could find of this behavior
was here, r68611 :
http://svn.python.org/view/python/trunk/Lib/test/test_socket.py?r1=64125&r2=68611&pathrev=68611

I think that the documentation should specify that (surprising)
behavior: I attached a patch explaining that detail.


Thanks!

----------
assignee: georg.brandl
components: Documentation
files: socketshutdown.patch
keywords: patch
messages: 91912
nosy: georg.brandl, nicdumz
severity: normal
status: open
title: socket.shudown documentation: on some platforms, closing one half closes the other half
type: behavior
Added file: http://bugs.python.org/file14778/socketshutdown.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6774>
_______________________________________

From report at bugs.python.org  Mon Aug 24 11:02:18 2009
From: report at bugs.python.org (Nicolas Dumazet)
Date: Mon, 24 Aug 2009 09:02:18 +0000
Subject: [New-bugs-announce] [issue6775] readme: correct
	python.org/community/lists url
In-Reply-To: <1251104538.03.0.409360254575.issue6775@psf.upfronthosting.co.za>
Message-ID: <1251104538.03.0.409360254575.issue6775@psf.upfronthosting.co.za>


New submission from Nicolas Dumazet <nicdumz at gmail.com>:

README shows http://www.python.org/community/lists.html as an URL for
mailing list details, but it should be
http://www.python.org/community/lists/

Attaching a patch.

----------
assignee: georg.brandl
components: Documentation
files: readme-url-mls.patch
keywords: patch
messages: 91913
nosy: georg.brandl, nicdumz
severity: normal
status: open
title: readme: correct python.org/community/lists url
Added file: http://bugs.python.org/file14779/readme-url-mls.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6775>
_______________________________________

From report at bugs.python.org  Mon Aug 24 17:13:45 2009
From: report at bugs.python.org (Nicolas Dumazet)
Date: Mon, 24 Aug 2009 15:13:45 +0000
Subject: [New-bugs-announce] [issue6776] A few tests are failing when zlib
	is not supported
In-Reply-To: <1251126825.28.0.687144384207.issue6776@psf.upfronthosting.co.za>
Message-ID: <1251126825.28.0.687144384207.issue6776@psf.upfronthosting.co.za>


New submission from Nicolas Dumazet <nicdumz at gmail.com>:

test_distutils, test_zipfile, test_gzip and test_zimport are not
completely safe when zlib module is not available.

I've uploaded a patch on Rietveld which solves the issue here:
http://codereview.appspot.com/111041
Those are my first steps with Rietveld, please let me know if I can
improve something :)

Thanks,
Nicolas.

----------
components: Tests
messages: 91923
nosy: nicdumz
severity: normal
status: open
title: A few tests are failing when zlib is not supported
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6776>
_______________________________________

From report at bugs.python.org  Mon Aug 24 21:50:34 2009
From: report at bugs.python.org (Christoph Zwerschke)
Date: Mon, 24 Aug 2009 19:50:34 +0000
Subject: [New-bugs-announce] [issue6777] Python 2.6 tutorial still
	recommends using	Exception.message attribute
In-Reply-To: <1251143434.18.0.260436581702.issue6777@psf.upfronthosting.co.za>
Message-ID: <1251143434.18.0.260436581702.issue6777@psf.upfronthosting.co.za>


New submission from Christoph Zwerschke <cito at online.de>:

The Python 2.6.2 tutorial says at the end of secton 8.3
(http://docs.python.org/tutorial/errors.html#handling-exceptions):

"But use of .args is discouraged. Instead, the preferred use is to pass 
a single argument to an exception (which can be a tuple if multiple 
arguments are needed) and have it bound to the message attribute."

It seems this is not true any more, the idea has been retracted so that 
it's now the other way around again: .args can still be used, 
but .message is deprecated (see http://www.python.org/dev/peps/pep-
0352/#retracted-ideas).

The examples classes in section 8.5 of the Tutorial, using the .message 
attribute should be also adapted because they raise a 
DeprecationWarning in Python 2.6.2.

----------
assignee: georg.brandl
components: Documentation
messages: 91937
nosy: cito, georg.brandl
severity: normal
status: open
title: Python 2.6 tutorial still recommends using Exception.message attribute
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6777>
_______________________________________

From report at bugs.python.org  Mon Aug 24 22:59:18 2009
From: report at bugs.python.org (kaashif)
Date: Mon, 24 Aug 2009 20:59:18 +0000
Subject: [New-bugs-announce] [issue6778] False positives given through
	bisect module (binary	search)
In-Reply-To: <1251147558.19.0.488929549089.issue6778@psf.upfronthosting.co.za>
Message-ID: <1251147558.19.0.488929549089.issue6778@psf.upfronthosting.co.za>


New submission from kaashif <musharraf.azeem at gmail.com>:

I tried Python's bisect module on a large word list (words.txt contained
in http://www.greenteapress.com/thinkpython/swampy/swampy.1.1.zip)

If I search for something like 'musefully', 'museful' will come up as a
match. Maybe that's a feature... but seems to me like a bug.

Too much optimization going on here it seems, to such an extent that
false positives are given.

Here's the code I tried:

import bisect

fin = open('words.txt')
t = []

for line in fin:
    t.append(line.strip())

print(bisect.bisect(t,'musefully'))

----------
components: Extension Modules
files: words.txt
messages: 91940
nosy: kaashif
severity: normal
status: open
title: False positives given through bisect module (binary search)
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file14780/words.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6778>
_______________________________________

From report at bugs.python.org  Mon Aug 24 23:25:11 2009
From: report at bugs.python.org (Samuel Quiring)
Date: Mon, 24 Aug 2009 21:25:11 +0000
Subject: [New-bugs-announce] [issue6779] NotImplementedError on for statement
In-Reply-To: <1251149111.84.0.211191712144.issue6779@psf.upfronthosting.co.za>
Message-ID: <1251149111.84.0.211191712144.issue6779@psf.upfronthosting.co.za>


New submission from Samuel Quiring <sam.quiring at windriver.com>:

I have the following for statement:

                lenc = len(children)
                for ic in range(lenc):
                    print "ic: ", ic
                    child = children[ic]
                    print "  -", ic, child.__class__.__name__
                    print "XXX"
            except:
                try:
                    exctype, value = sys.exc_info()[:2]
                    print "exception", exctype, value
                    traceback.print_exc()
                    print range(lenc)
                except:
                    print "exception X"
            print "loop done"

When I execute it, I get the following output:

  - count changed, old: -1 new: 4
ic:  0
  - 0 XGRect
XXX
ic:  1
  - 1 PanelEntry
XXX
ic:  2
  - 2 ScrollView
XXX
ic:  3
  - 3 CloseButton
XXX
exception <type 'exceptions.NotImplementedError'> method not implemented
Traceback (most recent call last):
  File "/home/stpuser/prizm/lib/python2.6/libprizm/pui/atspi.py", line
187, in _get_n_children
    for ic in range(lenc):
NotImplementedError: method not implemented
[0, 1, 2, 3]
loop done


Why am I getting the NotImplementedError exception?  This looks like a
bug to me (I am pretty new to Python).

----------
components: None
messages: 91941
nosy: sbq
severity: normal
status: open
title: NotImplementedError on for statement
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6779>
_______________________________________

From report at bugs.python.org  Mon Aug 24 23:33:13 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 24 Aug 2009 21:33:13 +0000
Subject: [New-bugs-announce] [issue6780] startswith error message is
	incomplete
In-Reply-To: <1251149593.57.0.654081758843.issue6780@psf.upfronthosting.co.za>
Message-ID: <1251149593.57.0.654081758843.issue6780@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

The `startswith` method accepts both string and tuple (not list). Yet 
the error message suggests that it expects (only) a character buffer 
object.

In Python-2.6:

>>> "foo".startswith(['fo', 'df'])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: expected a character buffer object

In Python-3.x, the error message is different:

>>> "foo".startswith(["fo"])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Can't convert 'list' object to str implicitly

Aside: why not try to convert 'list' object to tuple?

----------
components: Library (Lib)
messages: 91942
nosy: srid
severity: normal
status: open
title: startswith error message is incomplete
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6780>
_______________________________________

From report at bugs.python.org  Tue Aug 25 14:29:25 2009
From: report at bugs.python.org (benlbroussard)
Date: Tue, 25 Aug 2009 12:29:25 +0000
Subject: [New-bugs-announce] [issue6781] even exponentiation of negative
	numbers
In-Reply-To: <1251203365.27.0.467156127603.issue6781@psf.upfronthosting.co.za>
Message-ID: <1251203365.27.0.467156127603.issue6781@psf.upfronthosting.co.za>


New submission from benlbroussard <benlbroussard at gmail.com>:

Negative one squared should be one, but is negative one sometimes.

pow(-1, 2) = 1
-1 ** 2 = -1
-1 ^ 2 = -1

The ** and ^ operators aren't working like expected, and the pow()
documentation is incorrect since it says "The two-argument form pow(x,
y) is equivalent to using the power operator: x**y."

----------
components: None
messages: 91951
nosy: benlbroussard
severity: normal
status: open
title: even exponentiation of negative numbers
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6781>
_______________________________________

From report at bugs.python.org  Tue Aug 25 17:29:11 2009
From: report at bugs.python.org (victor)
Date: Tue, 25 Aug 2009 15:29:11 +0000
Subject: [New-bugs-announce] [issue6782] Scoping of variables in closures
In-Reply-To: <1251214151.84.0.540608749633.issue6782@psf.upfronthosting.co.za>
Message-ID: <1251214151.84.0.540608749633.issue6782@psf.upfronthosting.co.za>


New submission from victor <bitto001 at uwp.edu>:

I can't tell if this is "feature" or a "bug" but either way this
behavior struck me as strange.
"""
def func():
  x = 5
  def inc():
    temp = x + 1 # when inc() is execute, this line fails
    x = temp
    return x
  return inc

i = func()
i() # will raise error
"""
It says that x referenced before defined (when computing x + 1). It
seems that the fact that x is assigned in the local inc() that it
shadows the outer x.
Even stranger is that if you remove the the assignment of "x = temp"
there is no error; suggesting the assignment to x anywhere in the inner
function shadows the entire function. 

This is not the expected behavior, so I thought it may be bug.

----------
components: Interpreter Core
messages: 91954
nosy: bitfort
severity: normal
status: open
title: Scoping of variables in closures
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6782>
_______________________________________

From report at bugs.python.org  Tue Aug 25 21:35:41 2009
From: report at bugs.python.org (Yuv Gre)
Date: Tue, 25 Aug 2009 19:35:41 +0000
Subject: [New-bugs-announce] [issue6783] Add a builtin method to 'int' for
	base/radix conversion
In-Reply-To: <1251228941.52.0.551451692653.issue6783@psf.upfronthosting.co.za>
Message-ID: <1251228941.52.0.551451692653.issue6783@psf.upfronthosting.co.za>


New submission from Yuv Gre <ubershmekel at gmail.com>:

In javascript and java each number has a toString method which allows 
for easy string representation in different bases. If the function int(x[, base]) exists as a builtin, the inverse should at least be 
somewhere in the standard library. Personally I believe a "to_string" 
method would work but would defeat "There should be one way to do it". 
Perhaps a method called "radix" or "base_convert" which requires a base 
to convert parameter won't take the place of str(number).

Here are a few possible implementations:
http://code.activestate.com/recipes/222109/
http://code.activestate.com/recipes/111286/
http://pastebin.com/f54dd69d6

----------
components: Interpreter Core, Library (Lib)
messages: 91958
nosy: ubershmekel
severity: normal
status: open
title: Add a builtin method to 'int' for base/radix conversion
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6783>
_______________________________________

From report at bugs.python.org  Wed Aug 26 13:56:13 2009
From: report at bugs.python.org (RonnyPfannschmidt)
Date: Wed, 26 Aug 2009 11:56:13 +0000
Subject: [New-bugs-announce] [issue6784] bytw/unicode string
	incompatibilities between python2 and	and python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>


New submission from RonnyPfannschmidt <Ronny.Pfannschmidt at gmx.de>:

i just noticed that there are some slight differences of the
bytestring/unicodestring pickles between python2/3 using the protocols
0, 1 and 2

the first things i noticed are:

a str from python2 is unpickled as unicode in python3
(fails for byte strings that don't fit whats expected for unicode)


a bytes instance from python3 is pickled as custom class in protocols <3

i'll write a script to try all combinations of protocols and string
variations and transfer directions

----------
components: None
messages: 91966
nosy: RonnyPfannschmidt
severity: normal
status: open
title: bytw/unicode string incompatibilities between python2 and and python3
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Wed Aug 26 15:51:33 2009
From: report at bugs.python.org (Evan)
Date: Wed, 26 Aug 2009 13:51:33 +0000
Subject: [New-bugs-announce] [issue6785] IncompleteRead / BadStatus when
	parsing	http://peakoil.mobi
In-Reply-To: <1251294693.63.0.748199046509.issue6785@psf.upfronthosting.co.za>
Message-ID: <1251294693.63.0.748199046509.issue6785@psf.upfronthosting.co.za>


New submission from Evan <evanphelan at gmail.com>:

(I'm brand new to Python.org, apologies in advance if this has been
recorded elsewhere or is not a bug)

I've a simple script which fetching a url using httplib/urllib2 and then
simply searches the HTML for a string. Works on every URL I've tried
apart from the url http://peakoil.mobi where, for some reason, I get the
following:

Traceback (most recent call last):
  File "C:\Python26\lib\threading.py", line 524, in __bootstrap_inner
    self.run()
  File "test.py", line 59, in run
    html = response.read()
  File "C:\Python26\lib\socket.py", line 327, in read
    data = self._sock.recv(rbufsize)
  File "C:\Python26\lib\httplib.py", line 518, in read
    return self._read_chunked(amt)
  File "C:\Python26\lib\httplib.py", line 564, in _read_chunked
    raise IncompleteRead(value)
IncompleteRead: <html><head>

<title></title></head>
<!-- Redirection Services ASH01WRED02 H1 -->
<frameset rows='100%, *' frameborder=no framespacing=0 border=0>
<frame src="http://peakoil.com/modules.php?name=AvantGo" name=mainwindow
framebo
rder=no framespacing=0 marginheight=0 marginwidth=0></frame>
</frameset>
<noframes>
<h2>Your browser does not support frames.  We recommend upgrading your
browser.<
/h2><br><br>
<center>Click <a
href="http://peakoil.com/modules.php?name=AvantGo">here</a> to
enter the site.</center>
</noframes></html>

Exception in thread 1:
Traceback (most recent call last):
  File "C:\Python26\lib\threading.py", line 524, in __bootstrap_inner
    self.run()
  File "test.py", line 51, in run
    response = urllib2.urlopen(req)
  File "C:\Python26\lib\urllib2.py", line 124, in urlopen
    return _opener.open(url, data, timeout)
  File "C:\Python26\lib\urllib2.py", line 383, in open
    response = self._open(req, data)
  File "C:\Python26\lib\urllib2.py", line 401, in _open
    '_open', req)
  File "C:\Python26\lib\urllib2.py", line 361, in _call_chain
    result = func(*args)
  File "C:\Python26\lib\urllib2.py", line 1130, in http_open
    return self.do_open(httplib.HTTPConnection, req)
  File "C:\Python26\lib\urllib2.py", line 1103, in do_open
    r = h.getresponse()
  File "C:\Python26\lib\httplib.py", line 951, in getresponse
    response.begin()
  File "C:\Python26\lib\httplib.py", line 391, in begin
    version, status, reason = self._read_status()
  File "C:\Python26\lib\httplib.py", line 355, in _read_status
    raise BadStatusLine(line)
BadStatusLine

----------
messages: 91972
nosy: kmoon
severity: normal
status: open
title: IncompleteRead / BadStatus when parsing http://peakoil.mobi
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6785>
_______________________________________

From report at bugs.python.org  Wed Aug 26 20:17:36 2009
From: report at bugs.python.org (James)
Date: Wed, 26 Aug 2009 18:17:36 +0000
Subject: [New-bugs-announce] [issue6786] readline and zero based indexing
In-Reply-To: <1251310656.11.0.667090107201.issue6786@psf.upfronthosting.co.za>
Message-ID: <1251310656.11.0.667090107201.issue6786@psf.upfronthosting.co.za>


New submission from James <purpleidea at gmail.com>:

why is it that the zeroth readline history item is seemingly always
none. I would expect this to support zero-based indexing in python, but
perhaps I have missed some detail in readline somewhere. Cheers,
_J


james at work:~$ python
Python 2.5.2 (r252:60911, Oct  5 2008, 19:24:49) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline
>>> readline.get_history_item(0)
>>> readline.get_history_item(0) is None
True
>>> 
james at work:~$

----------
components: Extension Modules
messages: 91979
nosy: purpleidea
severity: normal
status: open
title: readline and zero based indexing
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6786>
_______________________________________

From report at bugs.python.org  Thu Aug 27 03:12:30 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 27 Aug 2009 01:12:30 +0000
Subject: [New-bugs-announce] [issue6787] thread docs contain an incorrect
	link in a reference to	the 'exit' method
In-Reply-To: <1251335550.97.0.247554365962.issue6787@psf.upfronthosting.co.za>
Message-ID: <1251335550.97.0.247554365962.issue6787@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

In the Caveats section of the thread docs reference is made to the
'exit' method.  The link generated, instead of being to the exit method
in the thread module, is to the exit 'constant' section 4.

----------
assignee: georg.brandl
components: Documentation
messages: 91992
nosy: georg.brandl, r.david.murray
priority: low
severity: normal
stage: needs patch
status: open
title: thread docs contain an incorrect link in a reference to the 'exit' method
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6787>
_______________________________________

From report at bugs.python.org  Thu Aug 27 06:17:09 2009
From: report at bugs.python.org (Ryan McGuire)
Date: Thu, 27 Aug 2009 04:17:09 +0000
Subject: [New-bugs-announce] [issue6788] codecs.open on Win32 does not force
	binary mode
In-Reply-To: <1251346629.44.0.734409123127.issue6788@psf.upfronthosting.co.za>
Message-ID: <1251346629.44.0.734409123127.issue6788@psf.upfronthosting.co.za>


New submission from Ryan McGuire <python.org at enigmacurry.com>:

Opening a UTF-8 encoded file with unix newlines ("\n") on Win32:

codecs.open("whatever.txt","r","utf-8").read()

replaces the newlines ("\n") with CR+LF ("\r\n").

The docs specifically say that :

"Files are always opened in binary mode, even if no binary mode was
specified. This is done to avoid data loss due to encodings using 8-bit
values. This means that no automatic conversion of '\n' is done on
reading and writing."

And yet, opening the file with an explicit binary mode resolves the
situation:

codecs.open("whatever.txt","rb","utf-8").read()

This reads the file with the original newlines unmodified.

The implementation of codecs.open and the documentation are out of sync.

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 91995
nosy: EnigmaCurry, georg.brandl
severity: normal
status: open
title: codecs.open on Win32 does not force binary mode
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6788>
_______________________________________

From report at bugs.python.org  Thu Aug 27 09:18:18 2009
From: report at bugs.python.org (Ayman)
Date: Thu, 27 Aug 2009 07:18:18 +0000
Subject: [New-bugs-announce] [issue6789] ftplib storelines does not honor
	strings returned in	fp.readline
In-Reply-To: <1251357498.06.0.267830127898.issue6789@psf.upfronthosting.co.za>
Message-ID: <1251357498.06.0.267830127898.issue6789@psf.upfronthosting.co.za>


New submission from Ayman <ayman.alsairafi at gmail.com>:

in ftplibs.storlines, a call is done on what should be a Text stream:
fp.readline()
This would work in pre 3.x as it returns bytes but now that readlines
returns a string, the call at lines 477 would fail:

  File "C:\Python31\lib\ftplib.py", line 477, in storlines
    if buf[-1] in B_CRLF: buf = buf[:-1]
TypeError: Type str doesn't support the buffer API

The readline call should then be encoded().

----------
components: Library (Lib)
messages: 91997
nosy: aymanhs
severity: normal
status: open
title: ftplib storelines does not honor strings returned in fp.readline
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6789>
_______________________________________

From report at bugs.python.org  Thu Aug 27 23:08:19 2009
From: report at bugs.python.org (Jake McGuire)
Date: Thu, 27 Aug 2009 21:08:19 +0000
Subject: [New-bugs-announce] [issue6790] httplib and array do not play
	together well
In-Reply-To: <1251407299.25.0.631458654442.issue6790@psf.upfronthosting.co.za>
Message-ID: <1251407299.25.0.631458654442.issue6790@psf.upfronthosting.co.za>


New submission from Jake McGuire <jake at youtube.com>:

As of Python 2.6 you can no longer pass an array to 
httplib.HTTPConnection.send.

Issue1065257 added code to httplib to attempt to determine whether a 
file-like object was passed to certain methods (e.g. send), and to 
stream the data if so.

The patch uses "hasattr(obj, 'read')" as a proxy for "is a file-like 
object".

array.array objects have a method called "read" that is almost entirely 
disanalogous to the "read" method on a file-like object.

Hilarity ensues.

----------
messages: 92015
nosy: jakemcguire
severity: normal
status: open
title: httplib and array do not play together well
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6790>
_______________________________________

From report at bugs.python.org  Fri Aug 28 10:32:52 2009
From: report at bugs.python.org (sumar)
Date: Fri, 28 Aug 2009 08:32:52 +0000
Subject: [New-bugs-announce] [issue6791] httplib read status memory usage
In-Reply-To: <1251448372.35.0.316865122555.issue6791@psf.upfronthosting.co.za>
Message-ID: <1251448372.35.0.316865122555.issue6791@psf.upfronthosting.co.za>


New submission from sumar <m.sucajtys at gmail.com>:

During writing some code I discovered some behaviour of httplib. When we
connect to host, which doesn?t respond with status line, but it just
sending data, httplib may consume more and more memory, becouce when we
execute
h = httplib.HTTPConnection(?host?)
h.conect()
h.request(?GET?, ?/?)
r = h.getresponse()
httplib tries to read one line from host. If host doesn?t send new line
character (?\n?), httplib reads more and more data. On my tests httplib
could consume all of 4GB of memory and the python process was killed by
oom_killer.
The resolution is to limit maximum amount of data read on getting
response. I have performed some test:
I received 3438293 from hosts located in the network. The longest valid
response line is
HTTP/1.1 500 ( The specified Secure Sockets Layer (SSL) port is not
allowed. ISA Server is not configured to allow SSL requests from this
port. Most Web browsers use port 443 for SSL requests.  )\r\n
and it has 197 characters.
In RFC2616 in section 6.1 we have:
?The first line of a Response message is the Status-Line, consisting of
the protocol version followed by a numeric status code and its
associated textual phrase, with each element separated by SP characters.
No CR or LF is allowed except in the final CRLF sequence.
       Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
(..)The Reason-Phrase is intended to give a short textual description of
the Status-Code.?
So limiting maximum status line length to 256 characters is a solution
of this problem. It doesn?t break compatibility withc RFC 2616.

My patch was written originally on python2.4, but I?ve tested it on
python2.6:
[ms at host python2.6]$ patch --dry-run -i /home/ms/httplib.patch
patching file httplib.py
Hunk #1 succeeded at 209 (offset 54 lines).

----------
components: Library (Lib)
files: httplib.patch
keywords: patch
messages: 92027
nosy: m.sucajtys
severity: normal
status: open
title: httplib read status memory usage
type: resource usage
versions: Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14795/httplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6791>
_______________________________________

From report at bugs.python.org  Fri Aug 28 10:52:20 2009
From: report at bugs.python.org (erluk)
Date: Fri, 28 Aug 2009 08:52:20 +0000
Subject: [New-bugs-announce] [issue6792] Distutils-based installer does not
	detect 64bit versions	of Python
In-Reply-To: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>
Message-ID: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>


New submission from erluk <erluk at pargalaxy.de>:

An installer for source-only modules created using distutils
(bdist_wininst) will only detect 32bit installations of Python on 64bit
Windows machines.

Expected behaviour:
The installer lists 32bit and 64bit installations of Python on the machine.

----------
assignee: tarek
components: Distutils
messages: 92028
nosy: erluk, tarek
severity: normal
status: open
title: Distutils-based installer does not detect 64bit versions of Python
type: behavior
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6792>
_______________________________________

From report at bugs.python.org  Fri Aug 28 11:59:54 2009
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 28 Aug 2009 09:59:54 +0000
Subject: [New-bugs-announce] [issue6793] decimal.py: div_nearest ==>
	_div_nearest
In-Reply-To: <1251453594.44.0.819159397261.issue6793@psf.upfronthosting.co.za>
Message-ID: <1251453594.44.0.819159397261.issue6793@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

--- a-decimal.py        2009-08-28 11:48:45.000000000 +0200
+++ b-decimal.py        2009-08-28 11:49:47.000000000 +0200
@@ -4845,7 +4845,7 @@
         log_tenpower = f*M # exact
     else:
         log_d = 0  # error < 2.31
-        log_tenpower = div_nearest(f, 10**-p) # error < 0.5
+        log_tenpower = _div_nearest(f, 10**-p) # error < 0.5
 
     return _div_nearest(log_tenpower+log_d, 100)

----------
components: Library (Lib)
messages: 92031
nosy: skrah
severity: normal
status: open
title: decimal.py: div_nearest ==> _div_nearest
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6793>
_______________________________________

From report at bugs.python.org  Fri Aug 28 12:15:04 2009
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 28 Aug 2009 10:15:04 +0000
Subject: [New-bugs-announce] [issue6794] decimal.py: incorrect results in
	NaN comparisons
In-Reply-To: <1251454504.69.0.93743560426.issue6794@psf.upfronthosting.co.za>
Message-ID: <1251454504.69.0.93743560426.issue6794@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Hi,

I believe the following comparisons aren't correct:

1:

Decimal("-sNaN63450748854172416").compare_total(Decimal("-sNaN911993"))
==> Decimal('1')

Should be: Decimal('-1') (checked against decNumber)


2:
Decimal("NaN1222222222222").compare_total_mag(Decimal("-NaN999999"))
==> Decimal('-1')

Should be: Decimal('1') (checked against decNumber)

----------
components: Library (Lib)
messages: 92032
nosy: skrah
severity: normal
status: open
title: decimal.py: incorrect results in NaN comparisons

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6794>
_______________________________________

From report at bugs.python.org  Fri Aug 28 12:28:27 2009
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 28 Aug 2009 10:28:27 +0000
Subject: [New-bugs-announce] [issue6795] decimal.py: minor issues &&
	usability
In-Reply-To: <1251455307.6.0.293968499648.issue6795@psf.upfronthosting.co.za>
Message-ID: <1251455307.6.0.293968499648.issue6795@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Hi,

a couple of minor issues:

1:
>>> c = getcontext()
>>> c.traps[InvalidOperation] = False
>>> Decimal("NaN").__int__()
Decimal('NaN')

I think the return value should be None.


2:
>>> c = getcontext()
>>> c.traps[InvalidOperation] = False
>>> Decimal("NaN").__long__()
Traceback (most recent call last):
...
RuntimeError: maximum recursion depth exceeded in cmp


3:
>>> setcontext(8)
>>> getcontext()
8

This is just a usability issue, perhaps a type check could be performed.

----------
components: Library (Lib)
messages: 92034
nosy: skrah
severity: normal
status: open
title: decimal.py: minor issues && usability

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6795>
_______________________________________

From report at bugs.python.org  Fri Aug 28 20:04:53 2009
From: report at bugs.python.org (Keith Campbell)
Date: Fri, 28 Aug 2009 18:04:53 +0000
Subject: [New-bugs-announce] [issue6796] invalid print in
	tkinter\test\test_ttk\test_widgets.py
In-Reply-To: <1251482693.78.0.0973789349285.issue6796@psf.upfronthosting.co.za>
Message-ID: <1251482693.78.0.0973789349285.issue6796@psf.upfronthosting.co.za>


New submission from Keith Campbell <keithc at mitre.org>:

Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> ================================ RESTART 
================================
>>> 
>>> ================================ RESTART 
================================
>>> 
Traceback (most recent call last):
  File "C:\Python31\Lib\tkinter\test\test_ttk\test_widgets.py", line 4, 
in <module>
    from test.support import requires, run_unittest
  File "c:\spring2000\o7python\lib\test.py", line 33
    print 'Main process exiting.'
                                ^
SyntaxError: invalid syntax

----------
components: Tkinter
messages: 92040
nosy: keithc
severity: normal
status: open
title: invalid print in tkinter\test\test_ttk\test_widgets.py
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6796>
_______________________________________

From report at bugs.python.org  Fri Aug 28 23:49:58 2009
From: report at bugs.python.org (Jonathan Windle)
Date: Fri, 28 Aug 2009 21:49:58 +0000
Subject: [New-bugs-announce] [issue6797] When Beginning Expression with
	Lookahead Assertion I get	no Matches
In-Reply-To: <1251496198.81.0.453692564995.issue6797@psf.upfronthosting.co.za>
Message-ID: <1251496198.81.0.453692564995.issue6797@psf.upfronthosting.co.za>


New submission from Jonathan Windle <jonathanwindle at gmail.com>:

Example Code:
import re
re.findall(r"(?![a-z0-9])0(?![a-z0-9])", "a0a 0 0 b0b")

The above code returns an empty list. I expect to get ['0', '0'] returned.

If I remove "(?![a-z0-9])" from the beginning of the expression string 
findall returns values as expected.

----------
components: Regular Expressions
messages: 92046
nosy: jwindle
severity: normal
status: open
title: When Beginning Expression with Lookahead Assertion I get no Matches
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6797>
_______________________________________

From report at bugs.python.org  Sat Aug 29 01:52:05 2009
From: report at bugs.python.org (Robert Kern)
Date: Fri, 28 Aug 2009 23:52:05 +0000
Subject: [New-bugs-announce] [issue6798] Argument for sys.settrace()
	callbacks documented	incorrectly
In-Reply-To: <1251503525.6.0.896923124912.issue6798@psf.upfronthosting.co.za>
Message-ID: <1251503525.6.0.896923124912.issue6798@psf.upfronthosting.co.za>


New submission from Robert Kern <robert.kern at gmail.com>:

The final 'arg' argument of the sys.settrace() callback is documented to
be None for the 'c_return' and 'c_exception' events, but it appears to
be the function object itself. Additionally, the 'return' event's
argument may be None if the 'return' event is being generated because of
an exception. These errors also exist in the Py_tracefunc documentation
in the C API. The latter error is not particularly important for the
Python API, but in the C API the argument may be a NULL pointer.

I am happy to make the corrections if someone will confirm that my
analysis is correct.

----------
assignee: georg.brandl
components: Documentation
messages: 92050
nosy: georg.brandl, robert.kern
severity: normal
status: open
title: Argument for sys.settrace() callbacks documented incorrectly
type: behavior
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6798>
_______________________________________

From report at bugs.python.org  Sat Aug 29 02:10:11 2009
From: report at bugs.python.org (Paul Tarjan)
Date: Sat, 29 Aug 2009 00:10:11 +0000
Subject: [New-bugs-announce] [issue6799] mimetypes does not give cannonical
	extension for	guess_extension with text/plain
In-Reply-To: <1251504611.25.0.614751141151.issue6799@psf.upfronthosting.co.za>
Message-ID: <1251504611.25.0.614751141151.issue6799@psf.upfronthosting.co.za>


New submission from Paul Tarjan <python at paulisageek.com>:

>>> import mimetypes

>>> mimetypes.guess_extension("text/plain")
'.ksh'

most others are correct, it is just this one is quite wrong. I would
recommend changing it to .txt . 

>>> mimetypes.guess_all_extensions("text/plain")
['.ksh', '.pl', '.c', '.bat', '.h', '.txt', '.asc', '.text', '.pot', '.brf']

----------
components: Library (Lib)
messages: 92051
nosy: ptarjan
severity: normal
status: open
title: mimetypes does not give cannonical extension for guess_extension with text/plain
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6799>
_______________________________________

From report at bugs.python.org  Sat Aug 29 05:19:48 2009
From: report at bugs.python.org (Reid Kleckner)
Date: Sat, 29 Aug 2009 03:19:48 +0000
Subject: [New-bugs-announce] [issue6800] os.exec* raises "OSError: [Errno
	45] Operation not	supported" in a multithreaded application
In-Reply-To: <1251515988.29.0.608870203555.issue6800@psf.upfronthosting.co.za>
Message-ID: <1251515988.29.0.608870203555.issue6800@psf.upfronthosting.co.za>


New submission from Reid Kleckner <rnk at mit.edu>:

The test case is attached.  On Mac OS X (and presumably FreeBSD, which
has the same behavior) when you try to exec from a process that has any
other threads in it, you get an OSError, "Operation not supported". 
Here's the output on my MacBook:

Traceback (most recent call last):
  File "daemon_exec.py", line 16, in <module>
    main()
  File "daemon_exec.py", line 13, in main
    os.execl('echo', 'hello world')
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/os.py",
line 312, in execl
    execv(file, args)
OSError: [Errno 45] Operation not supported

And on my Linux box:

hello world

Here's a similar bug that OCaml had to deal with:
http://caml.inria.fr/mantis/view.php?id=4666

I think it's reasonable for Python to declare this to be a limitation of
the OS, but considering that the other thread could be a daemon thread
that the user doesn't really care about, I think it would be reasonable
for Python to kill the other threads in the process before execing. 
That's what happens on Linux, anyway.

I ran into this problem while trying to add a persistent background
compilation thread to unladen swallow, and wondered if having any other
threads would trigger the same exception.

It's tempting to just write this off, but I figured it should be
documented or left open as a low priority defect.

----------
assignee: ronaldoussoren
components: Macintosh
files: daemon_exec.py
messages: 92054
nosy: rnk, ronaldoussoren
severity: normal
status: open
title: os.exec* raises "OSError: [Errno 45] Operation not supported" in a multithreaded application
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14798/daemon_exec.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6800>
_______________________________________

From report at bugs.python.org  Sat Aug 29 15:31:02 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 29 Aug 2009 13:31:02 +0000
Subject: [New-bugs-announce] [issue6801] symmetric_difference_update
	documentation fix
In-Reply-To: <1251552662.92.0.431748034273.issue6801@psf.upfronthosting.co.za>
Message-ID: <1251552662.92.0.431748034273.issue6801@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

the symmetric_difference_update also accepts |

----------
assignee: tarek
components: Documentation
messages: 92065
nosy: tarek
severity: normal
status: open
title: symmetric_difference_update documentation fix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6801>
_______________________________________

From report at bugs.python.org  Sat Aug 29 22:30:58 2009
From: report at bugs.python.org (Joshua Root)
Date: Sat, 29 Aug 2009 20:30:58 +0000
Subject: [New-bugs-announce] [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>


New submission from Joshua Root <josh+python at root.id.au>:

Building Python 2.6.2 on Mac OS X 10.6 (final version, 10A432) fails. Full 
build transcript is attached.

Other system details: Xcode 3.2, hardware is MacPro1,1

----------
assignee: ronaldoussoren
components: Build, Macintosh
files: py26-snowleopard.log
messages: 92067
nosy: jmr, ronaldoussoren
severity: normal
status: open
title: build fails on Snow Leopard
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file14801/py26-snowleopard.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6802>
_______________________________________

From report at bugs.python.org  Sat Aug 29 22:44:00 2009
From: report at bugs.python.org (Dan Haffey)
Date: Sat, 29 Aug 2009 20:44:00 +0000
Subject: [New-bugs-announce] [issue6803] Context manager docs refer to
	contextlib.contextmanager	as contextlib.contextfactory
In-Reply-To: <1251578640.37.0.48672021847.issue6803@psf.upfronthosting.co.za>
Message-ID: <1251578640.37.0.48672021847.issue6803@psf.upfronthosting.co.za>


New submission from Dan Haffey <dhaffey at gmail.com>:

The documentation at
http://docs.python.org/library/stdtypes.html#context-manager-types
refers to the contextlib.contextmanager decorator as
contextlib.contextfactory.

----------
assignee: georg.brandl
components: Documentation
files: doc-stdtypes-contextmanagement.patch
keywords: patch
messages: 92068
nosy: dhaffey, georg.brandl
severity: normal
status: open
title: Context manager docs refer to contextlib.contextmanager as contextlib.contextfactory
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file14802/doc-stdtypes-contextmanagement.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6803>
_______________________________________

From report at bugs.python.org  Sat Aug 29 23:44:40 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 29 Aug 2009 21:44:40 +0000
Subject: [New-bugs-announce] [issue6804] IDLE: Detect Python files even if
	name doesn't end in .py
In-Reply-To: <1251582280.35.0.0143459273436.issue6804@psf.upfronthosting.co.za>
Message-ID: <1251582280.35.0.0143459273436.issue6804@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

A Python source file name doesn't necesarily end 
in .py/.pyw; on Linux, scripts usually have no 
extension but are recognized by its shebang line. 
Windows uses file type associations: .py files are of 
type Python.File, and .pyc files are Python.NoConFile.

This patch makes IDLE recognize as a Python source 
(and colorize) any file of those types, regardless of 
extension.

http://permalink.gmane.org/
gmane.comp.python.general/636011

----------
components: IDLE
files: EditorWindow.diff
keywords: patch
messages: 92071
nosy: gagenellina
severity: normal
status: open
title: IDLE: Detect Python files even if name doesn't end in .py
type: feature request
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14803/EditorWindow.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6804>
_______________________________________

From report at bugs.python.org  Sun Aug 30 04:35:19 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sun, 30 Aug 2009 02:35:19 +0000
Subject: [New-bugs-announce] [issue6805] Should be URL for documentation of
	current release of	Python 3 (without version)
In-Reply-To: <1251599719.58.0.439749940017.issue6805@psf.upfronthosting.co.za>
Message-ID: <1251599719.58.0.439749940017.issue6805@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

There should be a standard URL on the web site to reach the
documentation of the current stable release of Python 3.

http://docs.python.org leads to the documentation for Python 2.
I can get to Python 3.1 documentation, but I have to specify 3.1 in the
URL: http://docs.python.org/3.1
That means that I cannot publish material on the web or in hardcopy that
refers generically to the documentation of a particular module via URL
without specifying a version, and that version will be obsolete before
long. I don't know what the URL should be -- perhaps docs.python.org/3/
would be sufficient.

This is one level up from the current arrangement in which specifying
3.1 actually currently gives me the 3.1.1 documentation.

----------
assignee: georg.brandl
components: Documentation
messages: 92078
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Should be URL for documentation of current release of Python 3 (without version)
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6805>
_______________________________________

From report at bugs.python.org  Sun Aug 30 06:35:07 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 30 Aug 2009 04:35:07 +0000
Subject: [New-bugs-announce] [issue6806] test_platform fails under Snow
	Leopard
In-Reply-To: <1251606907.25.0.605162883353.issue6806@psf.upfronthosting.co.za>
Message-ID: <1251606907.25.0.605162883353.issue6806@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

test.platform fails under Snow Leopard because the golden input for the OS 
version, sw_vers, reports Snow Leopard as '10.6' while 
platform.mac_ver()[0] (which uses gestalt.gestalt()) return '10.6.0'.

Best solution might be to tweak the test to append a '0' when sw_vers 
returns a value that is short a micro version.

----------
components: Library (Lib)
keywords: easy
messages: 92079
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: test_platform fails under Snow Leopard
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6806>
_______________________________________

From report at bugs.python.org  Sun Aug 30 12:59:16 2009
From: report at bugs.python.org (pds)
Date: Sun, 30 Aug 2009 10:59:16 +0000
Subject: [New-bugs-announce] [issue6807] No such file or directory:
	'msisupport.dll' in msi.py
In-Reply-To: <1251629956.22.0.252677555531.issue6807@psf.upfronthosting.co.za>
Message-ID: <1251629956.22.0.252677555531.issue6807@psf.upfronthosting.co.za>


New submission from pds <pirdirsir at gmail.com>:

Investigating the issue #6716 I reported earlier, I've been trying to
build Windows MSI installer package of Python 3.1 on my own.
I checked out the svn source, built things with Visual C++ 2008 Express
Edition, and tried to make MSI package in Tools\msi directory.
When I run Tools\msi\msi.py in Tools\msi directory, the following error
occurs:

Traceback (most recent call last):
  File "msi.py", line 178, in <module>
    if msilib.pe_type(dll_path) != msilib.pe_type("msisupport.dll"):
  File "E:\python31svnbuild\Tools\msi\msilib.py", line 665, in pe_type
    header = open(path, "rb").read(1000)
IOError: [Errno 2] No such file or directory: 'msisupport.dll'

It seems that msilib.pe_type("msisupport.dll") is called before
msisupport.dll is created.
I read msi.py and learned that msilib.pe_type("msisupport.dll") (line
178) is executed before os.system("nmake /nologo /c /f msisupport.mak")
(line 372) is executed in add_ui(), which is called at line 1299.
So I made a patch to make msi.py to see if the file "msisupport.dll"
exists, and if it does, check if the dll is for the correct architecture.

----------
components: Installation
files: patch.txt
messages: 92086
nosy: pds
severity: normal
status: open
title: No such file or directory: 'msisupport.dll' in msi.py
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file14806/patch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6807>
_______________________________________

From report at bugs.python.org  Sun Aug 30 17:40:58 2009
From: report at bugs.python.org (Tom Morse)
Date: Sun, 30 Aug 2009 15:40:58 +0000
Subject: [New-bugs-announce] [issue6808] python 3.1 documentation tutorial
	classes
In-Reply-To: <1251646858.69.0.964592229296.issue6808@psf.upfronthosting.co.za>
Message-ID: <1251646858.69.0.964592229296.issue6808@psf.upfronthosting.co.za>


New submission from Tom Morse <thomas.morse at snet.net>:

Thank you for the most excellent documentation and notes on classes in
python:
http://docs.python.org/3.1/tutorial/classes.html

I found the following minor typos and provide feedback on the above web
page:

1. Where "unpacked again" occurs there is no reference to any first
unpacking so that was confusing to me.  I had the impression that if
"again" was omitted it was vaguely understandable.

2. Typo: where "of instances of c" occurs, "of c" should be "of C"

----------
assignee: georg.brandl
components: Documentation
messages: 92091
nosy: georg.brandl, tom_morse
severity: normal
status: open
title: python 3.1 documentation tutorial classes
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6808>
_______________________________________

From report at bugs.python.org  Mon Aug 31 08:38:48 2009
From: report at bugs.python.org (Andrew Liu)
Date: Mon, 31 Aug 2009 06:38:48 +0000
Subject: [New-bugs-announce] [issue6809] Python string.lstrip bug?
In-Reply-To: <1251700728.18.0.0769627143448.issue6809@psf.upfronthosting.co.za>
Message-ID: <1251700728.18.0.0769627143448.issue6809@psf.upfronthosting.co.za>


New submission from Andrew Liu <mushywushy at gmail.com>:

A simple lstrip on the following causes an extra character to be
stripped, as per the below. Tried on 2.6.1 and on 2.4.3, as below.

Python 2.6.1 (r261:67515, Feb 27 2009, 02:54:13)
[GCC 4.3.2 20081105 (Red Hat 4.3.2-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = "contact_work_phone_no"
>>> a.lstrip("contact")
'_work_phone_no'
>>> a.lstrip("contact_")
'work_phone_no'
>>> a = "contact_city"
>>> a.lstrip("contact_")
'ity'
>>> a.lstrip("con")
'tact_city'
>>> a.lstrip("contact")
'_city'
>>> a.lstrip("contact_")
'ity'
>>>


Python 2.4.3 (#1, Mar 14 2007, 19:01:42)
[GCC 4.1.1 20070105 (Red Hat 4.1.1-52)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = "contact_city"
>>> a.lstrip("contact_")
'ity'
>>>

----------
components: Build
messages: 92102
nosy: mushywushy
severity: normal
status: open
title: Python string.lstrip bug?
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6809>
_______________________________________

From report at bugs.python.org  Mon Aug 31 09:32:03 2009
From: report at bugs.python.org (Yinon Ehrlich)
Date: Mon, 31 Aug 2009 07:32:03 +0000
Subject: [New-bugs-announce] [issue6810] add link to the documentation of
	signal.signal
In-Reply-To: <1251703923.28.0.662509969708.issue6810@psf.upfronthosting.co.za>
Message-ID: <1251703923.28.0.662509969708.issue6810@psf.upfronthosting.co.za>


New submission from Yinon Ehrlich <yinoneh at users.sourceforge.net>:

in http://docs.python.org/library/signal.html#signal.signal the reader
is referred to "see the reference manual section on the standard type
hierarchy". It would be generous if we will supply a link like
"http://docs.python.org/reference/datamodel.html"

BTW: it would be even more generous if the page
http://docs.python.org/reference/datamodel.html will include anchors to
specific paragraphs/items, so we could even refer to 
http://docs.python.org/reference/datamodel.html#frame, for example (the
#frame anchor doesn't exist now)

Thanks in advance !

----------
assignee: georg.brandl
components: Documentation
messages: 92106
nosy: Yinon, georg.brandl
severity: normal
status: open
title: add link to the documentation of signal.signal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6810>
_______________________________________

From report at bugs.python.org  Mon Aug 31 20:58:53 2009
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 31 Aug 2009 18:58:53 +0000
Subject: [New-bugs-announce] [issue6811] add a filename argument to
	marshal.load*
In-Reply-To: <1251745133.13.0.463652094911.issue6811@psf.upfronthosting.co.za>
Message-ID: <1251745133.13.0.463652094911.issue6811@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

For compatibility w/ import, importlib needs the ability to set 
code.co_filename to the actual location of the bytecode used to create a 
module and not the path embedded in the marshal data. But since 
co_filename is read-only it can't be done at the moment.

The idea is to add an optional argument to marshal.load* that takes a 
string representing the file path that co_filename should be set to, 
overriding what is in the marshal data.

A long-term perk of this is that eventually this argument can become 
required for marshal.loads() and the file path embedded in the marshal 
data can be removed entirely. marshal.load() would infer its path from 
file.name.

This was all discussed on python-dev; 
http://mail.python.org/pipermail/python-dev/2009-August/091460.html

----------
assignee: brett.cannon
components: Extension Modules
messages: 92113
nosy: brett.cannon
priority: low
severity: normal
stage: test needed
status: open
title: add a filename argument to marshal.load*
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6811>
_______________________________________