From report at bugs.python.org  Mon Jun  1 00:32:16 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 May 2009 22:32:16 +0000
Subject: [New-bugs-announce] [issue6158] test_aifc failing on 32bit windows
	in python 3.1 rc 1
In-Reply-To: <1243809136.07.0.631093381949.issue6158@psf.upfronthosting.co.za>
Message-ID: <1243809136.07.0.631093381949.issue6158@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

Martin, the test is failing because the dist is missing the file: 
Lib/test/Sine-1000Hz-300ms.aif .  That file is in SVN and was included
in the rc1 tarball.

----------
assignee: loewis
components: Tests
messages: 88616
nosy: loewis, rhettinger
priority: high
severity: normal
status: open
title: test_aifc failing on 32bit windows in python 3.1 rc 1
versions: Python 3.1

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

From report at bugs.python.org  Mon Jun  1 01:28:02 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 31 May 2009 23:28:02 +0000
Subject: [New-bugs-announce] [issue6159] Tkinter.PanedWindow: docstring
	fixes, change in paneconfigure and removed some returns
In-Reply-To: <1243812482.01.0.481805459937.issue6159@psf.upfronthosting.co.za>
Message-ID: <1243812482.01.0.481805459937.issue6159@psf.upfronthosting.co.za>


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

The attached patch removes the return statements from proxy_forget and
proxy_place since these methods aren't supposed to return anything.

It also fixes the docstring for the identify and paneconfigure methods.
While fixing the docstring in paneconfigure I considered as important to
rename "tagOrId" to "window", so the documentation and the method
signature get in agreement and also makes sense.

----------
components: Tkinter
files: PanedWindow_docstring_and_return_fixes.diff
keywords: patch
messages: 88620
nosy: gpolo
severity: normal
status: open
title: Tkinter.PanedWindow: docstring fixes, change in paneconfigure and removed some returns
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14133/PanedWindow_docstring_and_return_fixes.diff

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

From report at bugs.python.org  Mon Jun  1 05:22:10 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 01 Jun 2009 03:22:10 +0000
Subject: [New-bugs-announce] [issue6160] Tkinter.Spinbox: fix for bbox and
	removed some	uninteresting returns
In-Reply-To: <1243826530.3.0.945381049334.issue6160@psf.upfronthosting.co.za>
Message-ID: <1243826530.3.0.945381049334.issue6160@psf.upfronthosting.co.za>


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

The current bbox method for Tkinter.Spinbox is very likely to never
return a tuple. The attached patch uses _getints to always return a
tuple of integers.

The other changes in the patch are about removing unneeded return
statements.

----------
components: Tkinter
files: Spinbox_fixes.diff
keywords: patch
messages: 88634
nosy: gpolo
severity: normal
status: open
title: Tkinter.Spinbox: fix for bbox and removed some uninteresting returns
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14139/Spinbox_fixes.diff

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

From report at bugs.python.org  Mon Jun  1 17:59:28 2009
From: report at bugs.python.org (Guthur)
Date: Mon, 01 Jun 2009 15:59:28 +0000
Subject: [New-bugs-announce] [issue6161] HTTPResponse not storing response
	body
In-Reply-To: <1243871968.86.0.721781511059.issue6161@psf.upfronthosting.co.za>
Message-ID: <1243871968.86.0.721781511059.issue6161@psf.upfronthosting.co.za>


New submission from Guthur <guthur at hotmail.com>:

HTTPResponse does not store the HTTP response body while it does store 
the response headers, which in my opinion makes it rather useless as a 
HTTP response abstraction object. 

The only way to obtain the response body is to call HTTPResponse.Read
([amt]) and store the body seperately, this must also be carried out 
before the connection is closed, which makes no sense as the server 
serves both HEADERs and BODY together.

I can think of no real reason why this should be the case HTTP already 
provides a method for receiving just the headers with the HEAD request 
type.

Keynotes: HTTPResponse should store the body, if received, as well as 
the headers.

----------
components: Library (Lib)
messages: 88648
nosy: Guthur
severity: normal
status: open
title: HTTPResponse not storing response body
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Jun  1 18:01:33 2009
From: report at bugs.python.org (Mark Florisson)
Date: Mon, 01 Jun 2009 16:01:33 +0000
Subject: [New-bugs-announce] [issue6162] What should happen to signals when
	the main thread dies?
In-Reply-To: <1243872093.9.0.639774045025.issue6162@psf.upfronthosting.co.za>
Message-ID: <1243872093.9.0.639774045025.issue6162@psf.upfronthosting.co.za>


New submission from Mark Florisson <markflorisson88 at gmail.com>:

As signals are only delivered to the main thread, what should happen
when the main thread dies? Currently, the signal mask is not unset in
any other thread, so when the main thread dies, all signals set in the
mask are simply ignored. Perhaps an other thread could be selected as
the main thread?

The accompanied file demonstrates this behavior.

----------
components: Interpreter Core
files: ignore_signals.py
messages: 88650
nosy: eggy
severity: normal
status: open
title: What should happen to signals when the main thread dies?
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
Added file: http://bugs.python.org/file14143/ignore_signals.py

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

From report at bugs.python.org  Mon Jun  1 19:20:59 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 01 Jun 2009 17:20:59 +0000
Subject: [New-bugs-announce] [issue6163] [HP-UX] ld: Unrecognized argument:
	+s -L<dir>
In-Reply-To: <1243876859.78.0.253879711884.issue6163@psf.upfronthosting.co.za>
Message-ID: <1243876859.78.0.253879711884.issue6163@psf.upfronthosting.co.za>


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

this is also applicable to 3.1 (albeit the source is slightly changed)

Return a *list* of options otherwise these may be improperly interpreted as
one option with an embedded space. On /usr/bin/ld on a HP-UX/IA64 box this
results in:
    ld: Unrecognized argument: +s -L<dir>

----------
assignee: tarek
components: Distutils
files: distutils_hpux_libdir_option.patch
keywords: patch
messages: 88657
nosy: srid, tarek, trentm
severity: normal
status: open
title: [HP-UX] ld: Unrecognized argument: +s -L<dir>
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14144/distutils_hpux_libdir_option.patch

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

From report at bugs.python.org  Mon Jun  1 19:22:37 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 01 Jun 2009 17:22:37 +0000
Subject: [New-bugs-announce] [issue6164] [AIX] Patch to correct the AIX
	C/C++ linker argument used	for 'runtime_library_dirs'
In-Reply-To: <1243876957.94.0.533443517724.issue6164@psf.upfronthosting.co.za>
Message-ID: <1243876957.94.0.533443517724.issue6164@psf.upfronthosting.co.za>


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

This is being successfully used in ActivePython.

----------
assignee: tarek
components: Distutils
files: distutils_aix_blibpath.patch
keywords: patch
messages: 88658
nosy: srid, tarek, trentm
severity: normal
status: open
title: [AIX] Patch to correct the AIX C/C++ linker argument used for 'runtime_library_dirs'
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14145/distutils_aix_blibpath.patch

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

From report at bugs.python.org  Mon Jun  1 19:38:21 2009
From: report at bugs.python.org (Jonathan)
Date: Mon, 01 Jun 2009 17:38:21 +0000
Subject: [New-bugs-announce] [issue6165] strftime incorrectly processes DST
	flag when passed time	touples
In-Reply-To: <1243877901.36.0.141304844828.issue6165@psf.upfronthosting.co.za>
Message-ID: <1243877901.36.0.141304844828.issue6165@psf.upfronthosting.co.za>


New submission from Jonathan <jonathan.cervidae at gmail.com>:

>>> import time
>>> time.strftime("%FT%T%z")
'2009-06-01T18:35:42+0100'
>>> # Expect to see +0100
>>> time.strftime("%FT%T%z",time.localtime())
'2009-06-01T18:35:42+0000'
>>> time.strftime("%FT%T%Z",time.localtime())
'2009-06-01T18:35:42BST'
>>> made_up_time = list(time.localtime())
>>> made_up_time
[2009, 6, 1, 18, 35, 48, 0, 152, 1]
>>> made_up_time[1] = 2
>>> made_up_time=tuple(made_up_time)
>>> time.strftime("%FT%T%z",made_up_time)
'2009-02-01T18:35:48+0000'
>>> # Expect to see GMT or UTC, whatever strftime wants to call it.
>>> time.strftime("%FT%T%Z",made_up_time)
'2009-02-01T18:35:48BST'
>>>

----------
components: Extension Modules
messages: 88659
nosy: jonathan.cervidae
severity: normal
status: open
title: strftime incorrectly processes DST flag when passed time touples
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Mon Jun  1 20:32:27 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 01 Jun 2009 18:32:27 +0000
Subject: [New-bugs-announce] [issue6166] encoding error for 'setup.py
	--author' when read via	subprocess pipe
In-Reply-To: <1243881147.82.0.337721955444.issue6166@psf.upfronthosting.co.za>
Message-ID: <1243881147.82.0.337721955444.issue6166@psf.upfronthosting.co.za>


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

I ran 'python setup.py --author' for the pypi package "ll-orasql-0.6"
(whose author name has non-ascii characters) under subprocess.Popen and
this is what I get:

Traceback (most recent call last):
  File "/home/sridharr/as/pypm/bin/python", line 39, in <module>
    execfile(sys.argv[0])
  File "setup.py", line 50, in <module>
    package_dir={"ll": ""}
  File "/opt/ActivePython-2.6/lib/python2.6/distutils/core.py", line
138, in setup
    ok = dist.parse_command_line()
  File "/opt/ActivePython-2.6/lib/python2.6/distutils/dist.py", line
456, in parse_command_line
    if self.handle_display_options(option_order):
  File "/opt/ActivePython-2.6/lib/python2.6/distutils/dist.py", line
704, in handle_display_options
    print value
UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in
position 8: ordinal not in range(128)

When ran under the console, this exception is not seen. Otherwise, the
return code is 1 and nothing (apart from the above exception) is printed.

How to reproduce?
=================

Download `ll-orasql-0.6` from PyPI and run the following in the Python
shell:

>>> subprocess.Popen('python setup.py --author', stdout=subprocess.PIPE,
shell=True).stdout.read()

----------
assignee: tarek
components: Distutils
messages: 88664
nosy: srid, tarek
severity: normal
status: open
title: encoding error for 'setup.py --author' when read via subprocess pipe
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Jun  1 22:11:32 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 01 Jun 2009 20:11:32 +0000
Subject: [New-bugs-announce] [issue6167] Tkinter.Scrollbar: the activate
	method needs to return a	value, and set should take only two args
In-Reply-To: <1243887092.8.0.492821608561.issue6167@psf.upfronthosting.co.za>
Message-ID: <1243887092.8.0.492821608561.issue6167@psf.upfronthosting.co.za>


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

Hi,

I've noticed some minor problems in Tkinter.Scrollbar that would be good
to be addressed. The activate method never returns a value and it also
doesn't accept to be called without an element -- which is accepted by
tcl. When an element is not especified, the current active element
should be returned. It's signature is also a bit strange, I don't see
why it has a parameter named "index" while it never takes an index but
an element.

The second problem is about the set method. It accepts any amount of
arguments, but it only needs to accept two. Passing a tuple in the form
of (number, number) to it isn't accepted, so I don't see much reason to
continue with an *args there.

----------
components: Tkinter
files: Scrollbar_fixes.diff
keywords: patch
messages: 88670
nosy: gpolo
severity: normal
status: open
title: Tkinter.Scrollbar: the activate method needs to return a value, and set should take only two args
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14147/Scrollbar_fixes.diff

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

From report at bugs.python.org  Mon Jun  1 22:59:44 2009
From: report at bugs.python.org (Jason Gervich)
Date: Mon, 01 Jun 2009 20:59:44 +0000
Subject: [New-bugs-announce] [issue6168] Missing Shell menu in Linux IDLE
In-Reply-To: <1243889984.38.0.346185167721.issue6168@psf.upfronthosting.co.za>
Message-ID: <1243889984.38.0.346185167721.issue6168@psf.upfronthosting.co.za>


New submission from Jason Gervich <gervich at sbcglobal.net>:

The Shell menu is missing from the menu bar in the Edit Window of Ubuntu
Linux IDLE. It is described in the help but is not implemented. It is
there is the various windows versions I've seen.

Why is this missing and will it be fixed?

----------
components: IDLE
messages: 88677
nosy: sirgimp
severity: normal
status: open
title: Missing Shell menu in Linux IDLE
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0

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

From report at bugs.python.org  Tue Jun  2 01:18:25 2009
From: report at bugs.python.org (Michael Shields)
Date: Mon, 01 Jun 2009 23:18:25 +0000
Subject: [New-bugs-announce] [issue6169] Important comparison bug in ipaddr
In-Reply-To: <1243898305.94.0.945300464283.issue6169@psf.upfronthosting.co.za>
Message-ID: <1243898305.94.0.945300464283.issue6169@psf.upfronthosting.co.za>


New submission from Michael Shields <shields at msrl.com>:

The open source version of ipaddr had an important comparison bug in 
which it was possible for x > y and x < y.  The fix for this should be 
applied to the Python standard library version as well.

http://code.google.com/p/ipaddr-py/source/detail?r=77

----------
components: Library (Lib)
messages: 88685
nosy: shields
severity: normal
status: open
title: Important comparison bug in ipaddr
type: behavior
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Tue Jun  2 02:00:41 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 02 Jun 2009 00:00:41 +0000
Subject: [New-bugs-announce] [issue6170] Mac 'make frameworkinstall'
	error:	[...]/Python.framework/Versions/3.1/bin/2to3: Too many
	levels	of symbolic links
In-Reply-To: <1243900841.29.0.115602903603.issue6170@psf.upfronthosting.co.za>
Message-ID: <1243900841.29.0.115602903603.issue6170@psf.upfronthosting.co.za>


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

$ make frameworkinstall DESTDIR=[...]/py3_1rc1-macosx-apy31-rrun/image
running install_scripts
[...]
copying build/scripts-3.1/2to3 ->
//Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image/Library/Frameworks/Python.framework/Versions/3.1/bin
error:
//Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image/Library/Frameworks/Python.framework/Versions/3.1/bin/2to3:
Too many levels of symbolic links
make: *** [sharedinstall] Error 1


!
!

this appears to be a regression in 3.1rc1 (used to work with 3.1b2).
need to investigate further. will update this bug if I find anything
useful. (quick observation .. 'install_scripts' seem to be run twice)

----------
assignee: tarek
components: Distutils
files: apy31-anole.log
messages: 88689
nosy: srid, tarek
severity: normal
status: open
title: Mac 'make frameworkinstall' error: [...]/Python.framework/Versions/3.1/bin/2to3: Too many levels of symbolic links
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file14151/apy31-anole.log

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

From report at bugs.python.org  Tue Jun  2 02:46:52 2009
From: report at bugs.python.org (Jason Gervich)
Date: Tue, 02 Jun 2009 00:46:52 +0000
Subject: [New-bugs-announce] [issue6171] Class Browser selection in Ubuntu
In-Reply-To: <1243903612.81.0.195499978214.issue6171@psf.upfronthosting.co.za>
Message-ID: <1243903612.81.0.195499978214.issue6171@psf.upfronthosting.co.za>


New submission from Jason Gervich <gervich at sbcglobal.net>:

When sing IDLE in Ubuntu (Jaunty) if you open the Class Browser and
double click on a class or function name, the corresponding section is
highlighted in the code in the Editor Window. 

If you again double click on another class or function name, the new
code section should be highlighted in the Editor Window but isn't.
Nothing happens. You have to first close the Class Browser window,
reopen it and double click on another name to select it the Editor Window.

In the Windows versions, successive double clicking will highlight the
desired selection in the Class Browser window.

----------
messages: 88699
nosy: sirgimp
severity: normal
status: open
title: Class Browser selection in Ubuntu
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0

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

From report at bugs.python.org  Tue Jun  2 02:53:32 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 02 Jun 2009 00:53:32 +0000
Subject: [New-bugs-announce] [issue6172] 'make framework...' fails on Mac
	([...]/bin/pythonw3.1:	No such file or directory)
In-Reply-To: <1243904012.22.0.551945189195.issue6172@psf.upfronthosting.co.za>
Message-ID: <1243904012.22.0.551945189195.issue6172@psf.upfronthosting.co.za>


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

This happens with 3.1rc1

$ make frameworkinstallframework DESTDIR=image1
[...]
cc  -o pythonw ./Tools/pythonw.c \
               
-DPYTHONWEXECUTABLE='"/Library/Frameworks/Python.framework/Versions/3.1/Resources/Python.app/Contents/MacOS/Python"'
/usr/bin/install -c -s pythonw
"image1/Library/Frameworks/Python.framework/Versions/3.1/bin/pythonw3.1"
install:
image1/Library/Frameworks/Python.framework/Versions/3.1/bin/pythonw3.1:
No such file or directory
make[1]: *** [install_pythonw] Error 71
make: *** [frameworkinstallapps] Error 2
$

----------
components: Build, Macintosh
messages: 88701
nosy: srid
severity: normal
status: open
title: 'make framework...' fails on Mac ([...]/bin/pythonw3.1: No such file or directory)
versions: Python 3.1

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

From report at bugs.python.org  Tue Jun  2 07:51:32 2009
From: report at bugs.python.org (Pablo Torres Navarrete)
Date: Tue, 02 Jun 2009 05:51:32 +0000
Subject: [New-bugs-announce] [issue6173] Minor typo in socket.py
In-Reply-To: <1243921892.02.0.394666822319.issue6173@psf.upfronthosting.co.za>
Message-ID: <1243921892.02.0.394666822319.issue6173@psf.upfronthosting.co.za>


New submission from Pablo Torres Navarrete <tn.pablo at gmail.com>:

Index: socket.py
===================================================================
--- socket.py	(revision 73134)
+++ socket.py	(working copy)
@@ -16,7 +16,7 @@
 gethostbyname() -- map a hostname to its IP number
 gethostbyaddr() -- map an IP number or hostname to DNS info
 getservbyname() -- map a service name and a protocol name to a port number
-getprotobyname() -- mape a protocol name (e.g. 'tcp') to a number
+getprotobyname() -- map a protocol name (e.g. 'tcp') to a number
 ntohs(), ntohl() -- convert 16, 32 bit int from network to host byte order
 htons(), htonl() -- convert 16, 32 bit int from host to network byte order
 inet_aton() -- convert IP addr string (123.45.67.89) to 32-bit packed
format

----------
components: Library (Lib)
files: socket.patch
keywords: patch
messages: 88715
nosy: ptn
severity: normal
status: open
title: Minor typo in socket.py
versions: Python 2.6
Added file: http://bugs.python.org/file14153/socket.patch

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

From report at bugs.python.org  Tue Jun  2 07:53:45 2009
From: report at bugs.python.org (Joe Amenta)
Date: Tue, 02 Jun 2009 05:53:45 +0000
Subject: [New-bugs-announce] [issue6174] What's new in 2.6,
	wrong indentation in code sample
In-Reply-To: <1243922024.28.0.772489700519.issue6174@psf.upfronthosting.co.za>
Message-ID: <1243922024.28.0.772489700519.issue6174@psf.upfronthosting.co.za>


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

In the final example in the multiprocessing package on
http://docs.python.org/3.0/whatsnew/2.6.html#pep-371-the-multiprocessing-package
a part of the code is not properly indented.  There should be one more
level of indentation starting at "#Mark pool as closed".

Patch adds that level of indentation.

----------
assignee: georg.brandl
components: Documentation
files: docdiff.patch
keywords: patch
messages: 88716
nosy: georg.brandl, joe.amenta
severity: normal
status: open
title: What's new in 2.6, wrong indentation in code sample
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14154/docdiff.patch

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

From report at bugs.python.org  Tue Jun  2 10:06:07 2009
From: report at bugs.python.org (Daniel Svensson)
Date: Tue, 02 Jun 2009 08:06:07 +0000
Subject: [New-bugs-announce] [issue6175] inet_aton documentation kind of lies
In-Reply-To: <1243929967.67.0.34945506806.issue6175@psf.upfronthosting.co.za>
Message-ID: <1243929967.67.0.34945506806.issue6175@psf.upfronthosting.co.za>


New submission from Daniel Svensson <dsvensson at gmail.com>:

The documentation for inet_aton specifically says that it's used to
"Convert an IPv4 address from dotted-quad string format". This however
is not really true, it does accept dotted-quad, but not dotted-quad
alone, but also these forms from inet(3) man page:

       a.b.c.d   Each of the four numeric parts specifies a byte of the
address; the bytes are assigned in left-to-right order to produce the
binary address.

       a.b.c     Parts a and b specify the first two bytes of the binary
address.  Part c is interpreted as a 16-bit value that defines the
rightmost two bytes of the binary address.  This notation is suitable
for specifying (outmoded) Class B network addresses.

       a.b       Part a specifies the first byte of the binary address.
 Part b is interpreted as a 24-bit value that defines the rightmost
three bytes of the binary address.  This notation is suitable for
specifying (outmoded) Class C network addresses.

       a         The value a is interpreted as a 32-bit value that is
stored directly into the binary address without any byte rearrangement.

Sure, it references the man-page, but if anything it should say among
the formats it supports, dotted-quad is *one* of them.

http://docs.python.org/library/socket.html#socket.inet_aton

----------
assignee: georg.brandl
components: Documentation
messages: 88725
nosy: dsvensson, georg.brandl
severity: normal
status: open
title: inet_aton documentation kind of lies
versions: Python 2.6

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

From report at bugs.python.org  Tue Jun  2 11:51:20 2009
From: report at bugs.python.org (Pascal Chambon)
Date: Tue, 02 Jun 2009 09:51:20 +0000
Subject: [New-bugs-announce] [issue6176] Reference to a wrong version of
	flock's documentation
In-Reply-To: <1243936280.77.0.510370484524.issue6176@psf.upfronthosting.co.za>
Message-ID: <1243936280.77.0.510370484524.issue6176@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

It seems that the "flock" wrapped by the fcntl module is the one
descriebd in "flock(2)", not "flock(3)" (just in case this might confuse
people...)

Quote : 
"""
fcntl.flock(fd, op)
Perform the lock operation op on file descriptor fd (file objects
providing a fileno() method are accepted as well). See the Unix manual
flock(3) for details. (On some systems, this function is emulated using
fcntl.)
"""

Regards, 
Pascal

----------
assignee: georg.brandl
components: Documentation
messages: 88735
nosy: georg.brandl, pakal
severity: normal
status: open
title: Reference to a wrong version of flock's documentation
versions: Python 2.6

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

From report at bugs.python.org  Tue Jun  2 16:38:17 2009
From: report at bugs.python.org (Michael Foord)
Date: Tue, 02 Jun 2009 14:38:17 +0000
Subject: [New-bugs-announce] [issue6177] unittest.main testRunner default
	argument changed from	None
In-Reply-To: <1243953497.61.0.923685301175.issue6177@psf.upfronthosting.co.za>
Message-ID: <1243953497.61.0.923685301175.issue6177@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

In Python 2.6 the testRunner keyword argument to unittest.main
(TestProgram) changed from None to TextTestRunner.

This breaks test suites (like the setuptools tests) which pass in None
when not wanting to override the default.

This is easy to fix without breaking anything (but hard to test). I will
be fixing this and backporting to 2.6-maint unless there are objections.

----------
assignee: michael.foord
components: Library (Lib)
keywords: easy
messages: 88747
nosy: michael.foord
severity: normal
status: open
title: unittest.main testRunner default argument changed from None
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/issue6177>
_______________________________________

From report at bugs.python.org  Tue Jun  2 17:36:12 2009
From: report at bugs.python.org (Tim Savannah)
Date: Tue, 02 Jun 2009 15:36:12 +0000
Subject: [New-bugs-announce] [issue6178] Core error in Py_EvalFrameEx 2.6.2
In-Reply-To: <1243956972.97.0.133216910206.issue6178@psf.upfronthosting.co.za>
Message-ID: <1243956972.97.0.133216910206.issue6178@psf.upfronthosting.co.za>


New submission from Tim Savannah <tsavanna at arinc.com>:

I'm getting many segmentation faults (about 1 per half hour) from within
the core of python 2.6.2 on 64-bit machines.

(examples from dmesg:
pythonLaunch.py[13307]: segfault at 0000000000000058 rip
00002b845cfb3550 rsp 0000000041809930 error 4
pythonLaunch.py[27589]: segfault at 0000000000000058 rip
00002b4112287906 rsp 0000000042dab930 error 4
pythonLaunch.py[14436]: segfault at 0000000000000058 rip
00002ae0a4f68550 rsp 0000000042cd9930 error 4
pythonLaunch.py[10374]: segfault at 0000000000000058 rip
00002af43f966906 rsp 000000004214b930 error 4
pythonLaunch.py[17656]: segfault at 0000000000000058 rip
00002aed0cfe8906 rsp 00000000417f0930 error 4
)
pythonLaunch.py is a symbolic link to python 2.6.2 binary.
>From disassembling the python binary, I've found the corrosponding line
in source to be ceval.c:2717

if (tstate->frame->f_exc_type != NULL)

tstate->frame is null, and an access on f_exc_type causes a segfault
(trying to access memory 0x58, see above segfaults).

I can't find any clear code path that could cause tstate->frame to go
null, any suggestions? This is preventing us from moving from python 2.4
32-bit to python 2.6 64-bit.

----------
components: Interpreter Core
messages: 88748
nosy: tsavannah
severity: normal
status: open
title: Core error in Py_EvalFrameEx 2.6.2
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Tue Jun  2 22:21:48 2009
From: report at bugs.python.org (Mitchell Model)
Date: Tue, 02 Jun 2009 20:21:48 +0000
Subject: [New-bugs-announce] [issue6179] Documentation of for statement in
	Reference says that	range() returns a list
In-Reply-To: <1243974108.3.0.443832431096.issue6179@psf.upfronthosting.co.za>
Message-ID: <1243974108.3.0.443832431096.issue6179@psf.upfronthosting.co.za>


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

The documentation of the for statement in Section 7 of the Python 3
Reference states "range(3) returns the list [0, 1, 2]". Since range() no
longer returns a list, shouldn't this statement be made more precise?
(since this is the reference it should be technically accurate)

----------
assignee: georg.brandl
components: Documentation
messages: 88764
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Documentation of for statement in Reference says that range() returns a list
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Tue Jun  2 23:21:07 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 02 Jun 2009 21:21:07 +0000
Subject: [New-bugs-announce] [issue6180] Tkinter.Entry: fix for xview and
	some doc clarifications
In-Reply-To: <1243977667.14.0.414043606697.issue6180@psf.upfronthosting.co.za>
Message-ID: <1243977667.14.0.414043606697.issue6180@psf.upfronthosting.co.za>


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

The xview method in Tkinter.Entry doesn't indicate that index may be
None, which is used to query the Entry xview. I also considered that the
 docstrings in the selection_range and selection_present methods needed
some clarifications, so the attached patch also fixes this.

----------
components: Tkinter
files: Entry_fixes.diff
keywords: patch
messages: 88765
nosy: gpolo
severity: normal
status: open
title: Tkinter.Entry: fix for xview and some doc clarifications
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14157/Entry_fixes.diff

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

From report at bugs.python.org  Tue Jun  2 23:24:59 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 02 Jun 2009 21:24:59 +0000
Subject: [New-bugs-announce] [issue6181] Tkinter.Listbox several minor issues
In-Reply-To: <1243977899.25.0.845872446641.issue6181@psf.upfronthosting.co.za>
Message-ID: <1243977899.25.0.845872446641.issue6181@psf.upfronthosting.co.za>


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

Hi there,

I've found several minor issues in Tkinter.Listbox which are all fixed
by the attached patch.

I'm considering the bbox method should be clear in relation to the
amount of accepted arguments, which is always one. So I dropped the
*args usage there.
The curselection method has a reminder about applying getints on it, I
have done it now. I think it is fine to finally fix it, since we have
some tests for it now (at least in the tk_and_idle_maintenance branch).
The remaining changes in the patch are all about fixing docstring of
several methods in Listbox.

----------
components: Tkinter
files: Listbox_fixes.diff
keywords: patch
messages: 88766
nosy: gpolo
severity: normal
status: open
title: Tkinter.Listbox several minor issues
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14158/Listbox_fixes.diff

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

From report at bugs.python.org  Wed Jun  3 04:03:03 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 03 Jun 2009 02:03:03 +0000
Subject: [New-bugs-announce] [issue6182] Remove ipaddr library from py3k
	before 3.1rc2
In-Reply-To: <1243994583.57.0.193467275614.issue6182@psf.upfronthosting.co.za>
Message-ID: <1243994583.57.0.193467275614.issue6182@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

Do not use this bug for discussion of the topic.  Use the python-dev 
mailing list.

This bug is here to track its removal (or not) of the ipaddr library 
pending the outcome of the mailing list discussion.  Resolving this is a 
release blocker either way.

According to http://www.python.org/dev/peps/pep-0375/ 3.1rc2 goes out on 
June 13, 2009.

----------
assignee: gregory.p.smith
messages: 88785
nosy: gregory.p.smith
priority: release blocker
severity: normal
status: open
title: Remove ipaddr library from py3k before 3.1rc2
versions: Python 3.1

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

From report at bugs.python.org  Wed Jun  3 04:19:30 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 03 Jun 2009 02:19:30 +0000
Subject: [New-bugs-announce] [issue6183] test_time fails on VC6
In-Reply-To: <1243995570.35.0.0241749249605.issue6183@psf.upfronthosting.co.za>
Message-ID: <1243995570.35.0.0241749249605.issue6183@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

test_time fails on VC6 with following message.

======================================================================
FAIL: test_strptime (__main__.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_time.py", line 246, in <module>
    test_main()
  File "test_time.py", line 243, in test_main
    support.run_unittest(TimeTestCase, TestLocale)
  File "e:\python-dev\py3k\lib\test\support.py", line 879, in run_unittest
    _run_suite(suite)
  File "e:\python-dev\py3k\lib\test\support.py", line 854, in _run_suite
    result = runner.run(suite)
  File "e:\python-dev\py3k\lib\unittest.py", line 1490, in run
    result.printErrors()
  File "e:\python-dev\py3k\lib\unittest.py", line 1451, in printErrors
    self.printErrorList('FAIL', self.failures)
  File "e:\python-dev\py3k\lib\unittest.py", line 1458, in printErrorList
    self.stream.writeln("%s" % err)
  File "e:\python-dev\py3k\lib\unittest.py", line 1367, in writeln
    self.write(arg)
UnicodeEncodeError: 'cp932' codec can't encode character '\x93' in
position 453:
 illegal multibyte sequence


Here is quotation from 
http://msdn.microsoft.com/en-us/library/fe06s4ak%28VS.71%29.aspx

> Note   Before this version of Visual C++, the documentation described
> the format parameter of wcsftime as having the datatype const wchar_t
> *, but the actual implementation of the format datatype was const
> char *. In this version, the implementation of the format datatype
> has been updated to reflect the previous and current documentation, 
> that is: const wchar_t *.


Can I apply attached patch? Thank you.

----------
components: Extension Modules
files: patch_for_under_71.patch
keywords: patch
messages: 88786
nosy: ocean-city
severity: normal
status: open
title: test_time fails on VC6
versions: Python 3.1
Added file: http://bugs.python.org/file14163/patch_for_under_71.patch

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

From report at bugs.python.org  Wed Jun  3 04:59:18 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 03 Jun 2009 02:59:18 +0000
Subject: [New-bugs-announce] [issue6184] py3k build gets spurious errors
	from libinstall target	compile of lib2to3 files
In-Reply-To: <1243997958.63.0.926663545814.issue6184@psf.upfronthosting.co.za>
Message-ID: <1243997958.63.0.926663545814.issue6184@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

[...]
Compiling 
/tmp/image/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.
1/lib2to3/tests/__init__.py ...
Listing 
/tmp/image/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.
1/lib2to3/tests/data ...
Compiling 
/tmp/image/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.
1/lib2to3/tests/data/crlf.py ...
***   File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/lib2to3
/tests/data/crlf.py", line 1
    print "hi"
             ^
SyntaxError: invalid syntax

Compiling 
/tmp/image/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.
1/lib2to3/tests/data/different_encoding.py ...
***   File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/lib2to3
/tests/data/different_encoding.py", line 3
    
print(u'??????????????????????????????????????????????????????????????')
                                                                           
^
SyntaxError: invalid syntax

Listing 
/tmp/image/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.
1/lib2to3/tests/data/fixers ...
[...]


Seen during build on OSX 10.5:
  ./configure --enable-framework --enable-
universalsdk=/Developer/SDKs/MacOSX10.4u.sdk
  make
  make install DESTDIR=/tmp/image

----------
components: 2to3 (2.x to 3.0 conversion tool), Build
messages: 88787
nosy: nad
severity: normal
status: open
title: py3k build gets spurious errors from libinstall target compile of lib2to3 files
type: compile error
versions: Python 3.1

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

From martin at v.loewis.de  Wed Jun  3 06:30:15 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 03 Jun 2009 06:30:15 +0200
Subject: [New-bugs-announce] [issue6183] test_time fails on VC6
In-Reply-To: <1243995570.35.0.0241749249605.issue6183@psf.upfronthosting.co.za>
References: <1243995570.35.0.0241749249605.issue6183@psf.upfronthosting.co.za>
Message-ID: <4A25FC57.7080801@v.loewis.de>

> Can I apply attached patch? Thank you.

Looks fine to me, go ahead.

From report at bugs.python.org  Wed Jun  3 07:36:25 2009
From: report at bugs.python.org (Joe Amenta)
Date: Wed, 03 Jun 2009 05:36:25 +0000
Subject: [New-bugs-announce] [issue6185] 2to3 misses buffer slicing
In-Reply-To: <1244007385.35.0.333960656606.issue6185@psf.upfronthosting.co.za>
Message-ID: <1244007385.35.0.333960656606.issue6185@psf.upfronthosting.co.za>


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

Found this bug while writing the backwards version of this fix for
3to2... there is no test for it, so it went undetected.  The PATTERN
does not match a buffer() invocation if there is a token after the
rparen, i.e. slicing.

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: buffertest.patch
keywords: patch
messages: 88795
nosy: joe.amenta
severity: normal
status: open
title: 2to3 misses buffer slicing
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file14164/buffertest.patch

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

From report at bugs.python.org  Wed Jun  3 10:03:04 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 03 Jun 2009 08:03:04 +0000
Subject: [New-bugs-announce] [issue6186] test_thread occasionally reports
	unhandled exceptions on	OS X
In-Reply-To: <1244016184.43.0.482761629197.issue6186@psf.upfronthosting.co.za>
Message-ID: <1244016184.43.0.482761629197.issue6186@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

I've recently started seeing occasional regression test error messages 
on OS X from test_thread.  The test reports running OK but tracebacks 
are displayed.  It's not reproducible at will but has shown up on both 
10.5 Intel and 10.5 PPC machines with various recent top of py3k builds.  
Here are two examples:

nad at pbg4:/Library/Frameworks/Python.framework/Versions/3.1$ 
./bin/python3.1 -S ./lib/python3.1/test/regrtest.py -w test_thread
test_thread
Unhandled exception in thread started by <bound method 
ThreadRunningTests.task of <test.test_thread.ThreadRunningTests 
testMethod=test_stack_size>>
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/test/te
st_thread.py", line 49, in task
    self.done_mutex.release()
_thread.error: release unlocked lock
Unhandled exception in thread started by <bound method 
ThreadRunningTests.task of <test.test_thread.ThreadRunningTests 
testMethod=test_stack_size>>
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/test/te
st_thread.py", line 49, in task
    self.done_mutex.release()
_thread.error: release unlocked lock
Unhandled exception in thread started by <bound method 
ThreadRunningTests.task of <test.test_thread.ThreadRunningTests 
testMethod=test_stack_size>>
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/test/te
st_thread.py", line 49, in task
    self.done_mutex.release()
_thread.error: release unlocked lock
Unhandled exception in thread started by <bound method 
ThreadRunningTests.task of <test.test_thread.ThreadRunningTests 
testMethod=test_stack_size>>
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/test/te
st_thread.py", line 49, in task
    self.done_mutex.release()
_thread.error: release unlocked lock
Unhandled exception in thread started by <bound method 
ThreadRunningTests.task of <test.test_thread.ThreadRunningTests 
testMethod=test_starting_threads>>
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/test/te
st_thread.py", line 49, in task
    self.done_mutex.release()
_thread.error: release unlocked lock
1 test OK.

and

nad at fimt:/Library/Frameworks/Python.framework/Versions/3.1$ 
./bin/python3.1 -S ./lib/python3.1/test/regrtest.py -w test_thread
test_thread
Unhandled exception in thread started by <bound method 
ThreadRunningTests.task of <test.test_thread.ThreadRunningTests 
testMethod=test_stack_size>>
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/test/te
st_thread.py", line 49, in task
    self.done_mutex.release()
_thread.error: release unlocked lock
Unhandled exception in thread started by <bound method 
ThreadRunningTests.task of <test.test_thread.ThreadRunningTests 
testMethod=test_starting_threads>>
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/test/te
st_thread.py", line 49, in task
    self.done_mutex.release()
_thread.error: release unlocked lock
1 test OK.


Are the tracebacks from a harmless race condition and, if so, can the 
test be modified to eliminate them?  Or is there some new real problem?

----------
components: Tests
messages: 88799
nosy: nad
severity: normal
status: open
title: test_thread occasionally reports unhandled exceptions on OS X
versions: Python 3.1

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

From report at bugs.python.org  Wed Jun  3 13:27:48 2009
From: report at bugs.python.org (Jon Blubinger)
Date: Wed, 03 Jun 2009 11:27:48 +0000
Subject: [New-bugs-announce] [issue6187] Improvement in doc of "Extending
	and Embedding the Python	Interpreter,
	5.3 Beyond Very High Level Embedding: An overview"
In-Reply-To: <1244028468.87.0.409088876389.issue6187@psf.upfronthosting.co.za>
Message-ID: <1244028468.87.0.409088876389.issue6187@psf.upfronthosting.co.za>


New submission from Jon Blubinger <blubdiebla at gmail.com>:

It should me mentioned, that the Python variable PYTHONPATH has to be
set to the directory where the multiply.py file is. This can be achieved
via export in Linux or via the PySys_SetPath() function in C (see
attachment)

It should also be mentioned that otherwise the program will have
following output:

ImportError: No module named multiply
Failed to load "multiply"

----------
assignee: georg.brandl
components: Documentation
files: interp3.c
messages: 88805
nosy: blubdiebla, georg.brandl
severity: normal
status: open
title: Improvement in doc of "Extending and Embedding the Python Interpreter, 5.3 Beyond Very High Level Embedding: An overview"
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file14168/interp3.c

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

From report at bugs.python.org  Wed Jun  3 15:20:03 2009
From: report at bugs.python.org (Stephen Paul Chappell)
Date: Wed, 03 Jun 2009 13:20:03 +0000
Subject: [New-bugs-announce] [issue6188] Error Evaluating float(x) **
	float(y)
In-Reply-To: <1244035203.68.0.223995405838.issue6188@psf.upfronthosting.co.za>
Message-ID: <1244035203.68.0.223995405838.issue6188@psf.upfronthosting.co.za>


New submission from Stephen Paul Chappell <Noctis.Skytower at gmail.com>:

This is what I get while the interactive interpreter (IDLE 3.0.1) on the 
platform
Python 3.0.1 (r301:69561, Feb 13 2009, 20:04:18) [MSC v.1500 32 bit 
(Intel)] on win32

>>> a = -6.276479035564047
>>> b = -5.7974497499584849
>>> a ** b != -6.276479035564047 ** -5.7974497499584849
True
>>> 

Something is wrong. The float values are the same but not evaluated as 
being equal.
After writing an automated testing program, these sample numbers were 
generated
and found  to create erroneous symptoms in the system being 
automatically tested.

----------
components: Interpreter Core
messages: 88808
nosy: Zero
severity: normal
status: open
title: Error Evaluating float(x) ** float(y)
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Wed Jun  3 15:27:55 2009
From: report at bugs.python.org (Israel Tsadok)
Date: Wed, 03 Jun 2009 13:27:55 +0000
Subject: [New-bugs-announce] [issue6189] subprocess module not compatible
	with python 2.5
In-Reply-To: <1244035675.71.0.776263383534.issue6189@psf.upfronthosting.co.za>
Message-ID: <1244035675.71.0.776263383534.issue6189@psf.upfronthosting.co.za>


New submission from Israel Tsadok <itsadok at gmail.com>:

According to PEP 291, the subprocess module is supposed to be compatible 
with python 2.2 and up.

rev 60097 introduced the use of os.closerange(), which is new in python 
2.6.

Either PEP-291 needs to be revised, rev 60097 be reverted, or some sort of 
fallback mechanism needs to be added.

----------
components: Library (Lib)
files: subprocess.patch
keywords: patch
messages: 88810
nosy: itsadok
severity: normal
status: open
title: subprocess module not compatible with python 2.5
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file14170/subprocess.patch

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

From report at bugs.python.org  Wed Jun  3 22:05:03 2009
From: report at bugs.python.org (Michael Markert)
Date: Wed, 03 Jun 2009 20:05:03 +0000
Subject: [New-bugs-announce] [issue6190] Tutorial 3.1.2 (Strings) has
	duplicate lines
In-Reply-To: <1244059503.11.0.172911990378.issue6190@psf.upfronthosting.co.za>
Message-ID: <1244059503.11.0.172911990378.issue6190@psf.upfronthosting.co.za>


New submission from Michael Markert <markert.michael at gmail.com>:

Lines 242 - 246 of `introduction.rst` are the exact duplicate of 202 -
206 in the same file. 246+247 resemble 206+207.

The attached patch deletes the second notion.

----------
assignee: georg.brandl
components: Documentation
files: introduction.rst.patch
keywords: patch
messages: 88823
nosy: cofi, georg.brandl
severity: normal
status: open
title: Tutorial 3.1.2 (Strings) has duplicate lines
versions: Python 3.1
Added file: http://bugs.python.org/file14173/introduction.rst.patch

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

From report at bugs.python.org  Thu Jun  4 09:46:54 2009
From: report at bugs.python.org (=?utf-8?q?Pawe=C5=82_Widera?=)
Date: Thu, 04 Jun 2009 07:46:54 +0000
Subject: [New-bugs-announce] [issue6191] HTMLParser attribute parsing - 2
	test cases when it fails
In-Reply-To: <1244101614.1.0.195769853623.issue6191@psf.upfronthosting.co.za>
Message-ID: <1244101614.1.0.195769853623.issue6191@psf.upfronthosting.co.za>


New submission from Pawe? Widera <momat at man.poznan.pl>:

Of course both are not correct HTML but are easy to guess, so I believe
the parser should not give up too quick here.

1) extra comma between attributes
<form action="/xxx.php?a=1&amp;b=2&amp", method="post">

2) missing closing quotation mark for the first attribute
<a href="http://xxx.org/xxx.php?a=1 target="_blank">click me</a>

----------
components: Library (Lib)
messages: 88867
nosy: momat
severity: normal
status: open
title: HTMLParser attribute parsing - 2 test cases when it fails
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun  4 12:32:42 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 04 Jun 2009 10:32:42 +0000
Subject: [New-bugs-announce] [issue6192] add disable_nagle_algorithm to
	SocketServer.TCPServer
In-Reply-To: <1244111562.06.0.62559579479.issue6192@psf.upfronthosting.co.za>
Message-ID: <1244111562.06.0.62559579479.issue6192@psf.upfronthosting.co.za>


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

It is useful to be able to disable the Nagle algoritm on socket 
connections from the TCPServer.  These are typically used by HTTP servers.

If combined with write buffering (setting RequestHangler.wbufsize = -1) it  
can make sure that http responses are not subject to Nagle/Delayed-ack 
delays.  Disabling Nagle in addition to providing the buffering is 
necessary to make sure that the final wfile.flush() arrives promptly, in 
case a previous flush occurred and the final flush is small.

A patch is provided.

----------
files: disable_nagle.patch
keywords: easy, patch, patch
messages: 88878
nosy: krisvale
severity: normal
status: open
title: add disable_nagle_algorithm to SocketServer.TCPServer
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file14185/disable_nagle.patch

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

From report at bugs.python.org  Thu Jun  4 21:05:28 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 04 Jun 2009 19:05:28 +0000
Subject: [New-bugs-announce] [issue6193] urllib: ... IOError: ... unknown
	url type: 'c'
In-Reply-To: <1244142328.47.0.29736473077.issue6193@psf.upfronthosting.co.za>
Message-ID: <1244142328.47.0.29736473077.issue6193@psf.upfronthosting.co.za>


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

On Windows, urllib fails to open local files:

> python -c "import urllib; urllib.urlopen(r'C:\test.txt').read()"
Traceback (most recent call last):
  File "C:\HOME\as\pypm\bin\python-script.py", line 33, in <module>
    exec _val
  File "<string>", line 1, in <module>
  File "C:\Python26\lib\urllib.py", line 87, in urlopen
    return opener.open(url)
  File "C:\Python26\lib\urllib.py", line 200, in open
    return self.open_unknown(fullurl, data)
  File "C:\Python26\lib\urllib.py", line 212, in open_unknown
    raise IOError, ('url error', 'unknown url type', type)
IOError: [Errno url error] unknown url type: 'c'


However, on Unix this is not an issue:

$ python -c "import urllib; print urllib.urlopen('/tmp/test.txt').read()"
Foo
$

----------
components: Library (Lib)
messages: 88894
nosy: srid
severity: normal
status: open
title: urllib: ... IOError: ... unknown url type: 'c'
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun  4 23:38:38 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 04 Jun 2009 21:38:38 +0000
Subject: [New-bugs-announce] [issue6194] fcntl footnote about O_SHLOCK and
	O_EXLOCK is misleading
In-Reply-To: <1244151518.6.0.751803851074.issue6194@psf.upfronthosting.co.za>
Message-ID: <1244151518.6.0.751803851074.issue6194@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

At the bottom of http://docs.python.org/library/fcntl.html there is a
"see also" section for the os module that says:

    If the locking flags O_SHLOCK and O_EXLOCK are present in the os
module, the os.open() function provides a more platform-independent
alternative to the lockf() and flock() functions.

However, those flags are documented as being "unix only" (ie: no
windows), and in fact Linux does not support them.  Alan Cox rejected
support for them back in 2000 according to this linux kernel posting:

  http://lkml.indiana.edu/hypermail/linux/kernel/0005.1/1309.html

so it doesn't seem likely linux will ever support them.

Thus, to say that they provide a "more platform independent-alternative"
would appear to be false, since they appear to only be supported on BSD
and derivitives.

----------
assignee: georg.brandl
components: Documentation
keywords: easy
messages: 88904
nosy: georg.brandl, r.david.murray
priority: low
severity: normal
stage: needs patch
status: open
title: fcntl footnote about O_SHLOCK and O_EXLOCK is misleading
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu Jun  4 23:42:59 2009
From: report at bugs.python.org (Lisandro Dalcin)
Date: Thu, 04 Jun 2009 21:42:59 +0000
Subject: [New-bugs-announce] [issue6195] Serious regression in doctest in
	Py3.1rc1
In-Reply-To: <1244151779.64.0.307098872881.issue6195@psf.upfronthosting.co.za>
Message-ID: <1244151779.64.0.307098872881.issue6195@psf.upfronthosting.co.za>


New submission from Lisandro Dalcin <dalcinl at gmail.com>:

When doctests are written in docstrings from C extension modules,
'doctest' reads the binary extension module file.

The attached one-line patch seems to fix the problem, it is in fact very
similar to patch for issue4050 related to 'inspect'.

----------
components: Library (Lib), Tests
files: doctest.diff
keywords: patch
messages: 88907
nosy: dalcinl, scoder
severity: normal
status: open
title: Serious regression in doctest in Py3.1rc1
versions: Python 3.1
Added file: http://bugs.python.org/file14187/doctest.diff

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

From report at bugs.python.org  Thu Jun  4 23:45:52 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 04 Jun 2009 21:45:52 +0000
Subject: [New-bugs-announce] [issue6196] tarfile.extractall(readaccess=True)
In-Reply-To: <1244151952.15.0.48823803395.issue6196@psf.upfronthosting.co.za>
Message-ID: <1244151952.15.0.48823803395.issue6196@psf.upfronthosting.co.za>


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

If a tarball has a-x perms set on its root directory, one cannot access
its contents. 

$ tar zxf generator_tools-0.3.5.tar.gz.
$ ls generator_tools-0.3.5/
ls: cannot access generator_tools-0.3.5/README.txt: Permission denied
...
sridharr at double:/tmp/i$ 

This is fine for GNU tar (the user can always do a chmod +x later). But
for the tarfile library, it would be better to have a flag such as
readaccess=True that will force ``extractall`` to enforce *minimum*
permissions required for the basic read access. This means, tarfile
would ignore u-x on directories and u-r on files.

The reason I make this feature request (instead of working around the
issue myself in a verbose way) is that the very reason to write a
program to extract tarball (instead of doing it manually) is to automate
it .. which automation is more effective and simple if ``extractall``
had a flag such as readaccess=True.

----------
components: Library (Lib)
messages: 88908
nosy: srid
severity: normal
status: open
title: tarfile.extractall(readaccess=True)
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Fri Jun  5 05:43:34 2009
From: report at bugs.python.org (James Abbatiello)
Date: Fri, 05 Jun 2009 03:43:34 +0000
Subject: [New-bugs-announce] [issue6197] test__locale fails with RADIXCHAR
	on Windows
In-Reply-To: <1244173414.49.0.136863993589.issue6197@psf.upfronthosting.co.za>
Message-ID: <1244173414.49.0.136863993589.issue6197@psf.upfronthosting.co.za>


New submission from James Abbatiello <abbeyj at gmail.com>:

regrtest.py test__locale fails with:
test__locale
test test__locale crashed -- <type 'exceptions.ImportError'>: cannot
import name
 RADIXCHAR
1 test failed:
    test__locale

The attached patch backports the fix from issue5643

----------
components: Tests, Windows
files: test__locale_on_windows.patch
keywords: patch
messages: 88919
nosy: abbeyj, benjamin.peterson, ocean-city
severity: normal
status: open
title: test__locale fails with RADIXCHAR on Windows
versions: Python 2.7
Added file: http://bugs.python.org/file14190/test__locale_on_windows.patch

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

From report at bugs.python.org  Fri Jun  5 07:46:22 2009
From: report at bugs.python.org (James Abbatiello)
Date: Fri, 05 Jun 2009 05:46:22 +0000
Subject: [New-bugs-announce] [issue6198] test_float fails on Windows
In-Reply-To: <1244180782.5.0.462809934135.issue6198@psf.upfronthosting.co.za>
Message-ID: <1244180782.5.0.462809934135.issue6198@psf.upfronthosting.co.za>


New submission from James Abbatiello <abbeyj at gmail.com>:

test_float fails on Windows with:
======================================================================
FAIL: test_format_testfile (test.test_float.IEEEFormatTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Projects\python-trunk\lib\test\test_float.py", line 319, in
test_format_testfile
    self.assertEqual(fmt % float(arg), rhs)
AssertionError: '3' != '2'

----------------------------------------------------------------------


The problematic line from formatfloat_testcases.txt is:
%.0f 2.5 -> 2


On some systems *printf() uses round-to-even.  But the Windows CRT uses
round-half-away-from-zero.  Consider the following C code:
	printf("%+.1f -> %+.0f\n", -2.5, -2.5);
	printf("%+.1f -> %+.0f\n", -1.5, -1.5);
	printf("%+.1f -> %+.0f\n", +1.5, +1.5);
	printf("%+.1f -> %+.0f\n", +2.5, +2.5);

On Linux this will produce:
-2.5 -> -2
-1.5 -> -2
+1.5 -> +2
+2.5 -> +2

And on Windows:
-2.5 -> -3
-1.5 -> -2
+1.5 -> +2
+2.5 -> +3

----------
components: Tests, Windows
messages: 88922
nosy: abbeyj
severity: normal
status: open
title: test_float fails on Windows
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun  5 07:58:07 2009
From: report at bugs.python.org (James Abbatiello)
Date: Fri, 05 Jun 2009 05:58:07 +0000
Subject: [New-bugs-announce] [issue6199] test_unittest fails on Windows
In-Reply-To: <1244181487.09.0.399837041232.issue6199@psf.upfronthosting.co.za>
Message-ID: <1244181487.09.0.399837041232.issue6199@psf.upfronthosting.co.za>


New submission from James Abbatiello <abbeyj at gmail.com>:

test_unittest fails on Windows with:
======================================================================
FAIL: test_find_tests_with_package (test.test_unittest.TestDiscovery)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Projects\python-trunk\lib\test\test_unittest.py", line 3540,
in test_find_tests_with_package
    self.assertEqual(suite, ['load_tests', '/foo/test_directory2 module
tests'])

AssertionError: Lists differ: ['load_tests', '/foo\\test_dir... !=
['load_tests', '/foo/test_dire...

First differing element 1:
/foo\test_directory2 module tests
/foo/test_directory2 module tests

- ['load_tests', '/foo\\test_directory2 module tests']
?                     ^^

+ ['load_tests', '/foo/test_directory2 module tests']
?                     ^


----------------------------------------------------------------------


Patch attached.

----------
components: Tests, Windows
files: test_unittest_on_windows.patch
keywords: patch
messages: 88923
nosy: abbeyj
severity: normal
status: open
title: test_unittest fails on Windows
versions: Python 2.7
Added file: http://bugs.python.org/file14191/test_unittest_on_windows.patch

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

From report at bugs.python.org  Fri Jun  5 08:45:42 2009
From: report at bugs.python.org (James Abbatiello)
Date: Fri, 05 Jun 2009 06:45:42 +0000
Subject: [New-bugs-announce] [issue6201] test_winreg fails
In-Reply-To: <1244184342.63.0.700408501075.issue6201@psf.upfronthosting.co.za>
Message-ID: <1244184342.63.0.700408501075.issue6201@psf.upfronthosting.co.za>


New submission from James Abbatiello <abbeyj at gmail.com>:

test_winreg fails with:
======================================================================
ERROR: testLocalMachineRegistryWorks (test.test_winreg.WinregTests)
----------------------------------------------------------------------
Traceback (most recent call last):
<snip>
  File "C:\Projects\python-trunk\lib\test\test_winreg.py", line 86, in
ReadTestData
    with OpenKey(key, "sub_key") as sub_key:
AttributeError: __exit__

----------------------------------------------------------------------

_winreg.OpenKey() returns a PyHKEY.  This type can no longer be used in
a "with" statement after r72912 introduced the SETUP_WITH opcode.  The
old way used PyObject_GetAttr() to get __enter__ and __exit__ which
works fine with PyHKEY since it has a tp_getattr function.  The new way
uses _PyObject_LookupSpecial() which uses the MRO and the dict of the
object.

I guess the right fix here is to update PyHKEY so it uses the modern
APIs but I don't know how to do this without breaking the special casing
for the "handle" member.  Using T_INT isn't quite correct since it is a
pointer not an int.

----------
components: Tests, Windows
messages: 88926
nosy: abbeyj
severity: normal
status: open
title: test_winreg fails
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun  5 12:37:11 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 05 Jun 2009 10:37:11 +0000
Subject: [New-bugs-announce] [issue6202] Obsolete default file encoding
	"mac-roman" on OS X, not influenced by locale env variables
In-Reply-To: <1244198231.29.0.333691708249.issue6202@psf.upfronthosting.co.za>
Message-ID: <1244198231.29.0.333691708249.issue6202@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

Potential Release Blocker

The default file encoding for 3.x file objects is the value of 
locale.getpreferredencoding(). Currently, the locale module behavior on 
OS X deviates from other python POSIX platforms in a few unexpected and 
bad ways:

1. On OS X, locale.getpreferredencoding() returns "mac-roman", an 
obsolete encoding from the old "Classic" MacOS days.

2. Unlike other POSIX platforms (at least Debian Linux), the values 
returned by locale.getdefaultlocale() and locale.getpreferredencoding() 
on OS X are not influenced by the settings of the POSIX locale 
environment variables, i.e LANG.  So, unlike on the other POSIX 
platforms, one can't override the (obsolete) encoding without explicitly 
setting the encoding argument to open().

Compare the results from Debian Linux:

$ unset LANG
$ python3.1
Python 3.1a1+ (py3k, Mar 23 2009, 00:12:12) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getpreferredencoding()
'ANSI_X3.4-1968'
>>> open('blah','r').encoding
'ANSI_X3.4-1968'
>>> locale.getlocale()
(None, None)
>>> locale.getdefaultlocale()
(None, None)
>>> 
$ export LANG=en_US.UTF-8
$ python3.1
Python 3.1a1+ (py3k, Mar 23 2009, 00:12:12) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getpreferredencoding()
'UTF-8'
>>> open('blah','r').encoding
'UTF-8'
>>> locale.getlocale()
('en_US', 'UTF8')
>>> locale.getdefaultlocale()
('en_US', 'UTF8')
>>> 

... to OS X:

$ unset LANG
$ python3.1
Python 3.1rc1+ (py3k, Jun  3 2009, 14:31:41) 
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getpreferredencoding()
'mac-roman'
>>> open('blah','r').encoding
'mac-roman'
>>> locale.getlocale()
(None, None)
>>> locale.getdefaultlocale()
(None, 'mac-roman')
>>> 
$ export LANG=en_US.UTF-8
$ python3.1
Python 3.1rc1+ (py3k, Jun  3 2009, 14:31:41) 
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getpreferredencoding()
'mac-roman'
>>> open('blah','r').encoding
'mac-roman'
>>> locale.getlocale()
('en_US', 'UTF8')
>>> locale.getdefaultlocale()
(None, 'mac-roman')
>>> 

A quick look at the code shows that part of the problem is in 
Modules/_localemodule.c where there is a #if defined(__APPLE__) version 
of PyLocale_getdefaultlocale which appears to have its origins in MacOS 
and should probably just be removed and locale.py modified to 
eliminate/minimize the special case mac/darwin code.  For the case of no 
locale, "UTF-8" would seem to be a reasonable default.  In any case, 
"mac-roman" is not.

----------
assignee: ronaldoussoren
components: IO, Library (Lib), Macintosh
messages: 88929
nosy: benjamin.peterson, nad, ronaldoussoren
severity: normal
status: open
title: Obsolete default file encoding "mac-roman" on OS X, not influenced by locale env variables
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Fri Jun  5 12:56:38 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 05 Jun 2009 10:56:38 +0000
Subject: [New-bugs-announce] [issue6203] 3.x locale does not default to C,
	contrary to the documentation and to 2.x behavior
In-Reply-To: <1244199398.44.0.399320307295.issue6203@psf.upfronthosting.co.za>
Message-ID: <1244199398.44.0.399320307295.issue6203@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

In the Library Reference section 22.2.1 for locale, it states:

"Initially, when a program is started, the locale is the C locale, no 
matter what the user?s preferred locale is. The program must explicitly 
say that it wants the user?s preferred locale settings by calling 
setlocale(LC_ALL, '')."

This is the case for python2.x:

$ export LANG=en_US.UTF-8
$ python2.5
Python 2.5.4 (r254:67916, Feb 17 2009, 20:16:45) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale; locale.getlocale()
(None, None)
>>> locale.getdefaultlocale()
('en_US', 'UTF8')
>>> 

but not for 3.1:
$ python3.1
Python 3.1a1+ (py3k, Mar 23 2009, 00:12:12) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale; locale.getlocale()
('en_US', 'UTF8')
>>> locale.getdefaultlocale()
('en_US', 'UTF8')
>>> 

Either the code is incorrect in 3.1 or the documentation should be 
updated.

----------
assignee: georg.brandl
components: Documentation
messages: 88932
nosy: georg.brandl, nad
severity: normal
status: open
title: 3.x locale does not default to C, contrary to the documentation and to 2.x behavior
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Fri Jun  5 14:09:49 2009
From: report at bugs.python.org (Michael Markert)
Date: Fri, 05 Jun 2009 12:09:49 +0000
Subject: [New-bugs-announce] [issue6204] Missing reference in section 4.6 to
	chapter on classes
In-Reply-To: <1244203789.01.0.516038095674.issue6204@psf.upfronthosting.co.za>
Message-ID: <1244203789.01.0.516038095674.issue6204@psf.upfronthosting.co.za>


New submission from Michael Markert <markert.michael at gmail.com>:

In section 4.6 there is described that classes will be explained later
on. I think a real reference would be more appropriate.
See attached patch.

----------
assignee: georg.brandl
components: Documentation
files: controlflow.rst.patch
keywords: patch
messages: 88939
nosy: cofi, georg.brandl
severity: normal
status: open
title: Missing reference in section 4.6 to chapter on classes
versions: Python 3.1
Added file: http://bugs.python.org/file14192/controlflow.rst.patch

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

From report at bugs.python.org  Fri Jun  5 16:03:26 2009
From: report at bugs.python.org (James)
Date: Fri, 05 Jun 2009 14:03:26 +0000
Subject: [New-bugs-announce] [issue6205] sdist doesn't include data_files
In-Reply-To: <1244210606.6.0.749223227815.issue6205@psf.upfronthosting.co.za>
Message-ID: <1244210606.6.0.749223227815.issue6205@psf.upfronthosting.co.za>


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

Hi, I have shown the output from my terminal below, since it will be
easier to follow for explaining the bug.

james at computer:~/testsetup$ ls
helloworld2.py  image1.jpg  setup.py
james at computer:~/testsetup$ cat setup.py 
#!/usr/bin/python
import distutils.core	#from distutils.core import setup, Extension
import os

# build a list of modules required for setup function below
py_modules = []

py_modules.append('helloworld2')

distutils.core.setup(
	name='helloworld2',
	description='distutils test',
	version='0.1',
	author='James',
	author_email='purpleidea at gmail.com',
	py_modules=py_modules,
	# data_files: install directory, 
	data_files=[('share/helloworld2', ['image1.jpg'])]
)

james at computer:~/testsetup$ ./setup.py sdist
running sdist
warning: sdist: manifest template 'MANIFEST.in' does not exist (using
default file list)
warning: sdist: standard file not found: should have one of README,
README.txt
writing manifest file 'MANIFEST'
creating helloworld2-0.1
making hard links in helloworld2-0.1...
hard linking helloworld2.py -> helloworld2-0.1
hard linking setup.py -> helloworld2-0.1
creating dist
tar -cf dist/helloworld2-0.1.tar helloworld2-0.1
gzip -f9 dist/helloworld2-0.1.tar
removing 'helloworld2-0.1' (and everything under it)
james at computer:~/testsetup$ 

as you will notice, the image1.jpg file does not get included in the
source distribution, and if i want to backup the entire dir/code of
everything to send to someone else.
perhaps this is a peculiarity of distutils. i realize i could write my
own manifest.in but then i have to specify *everything* and this isn't
automatic anymore.
this is definitely an issue since a user who downloads the sdist file
and runs an install will see:

error: can't copy 'image1.jpg': doesn't exist or not a regular file

this occurs because it obviously didn't get included in the sdist. the
same thing happens when sdist is run with --no-prune

i thought that perhaps i was using the wrong target so i tried a bdist
(tar.gz). in this case the image1.jpg file gets included, however
unpacking the directory doesn't give me a structure similar to the one
my code is originally maintained in.
so how do i use distutils to share *everything*, (eg: everything
specified in the setup.py directory) with my friends on the tubes?

if you want, i'll write a patch.

_J

----------
assignee: tarek
components: Distutils
messages: 88945
nosy: purpleidea, tarek
severity: normal
status: open
title: sdist doesn't include data_files
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Fri Jun  5 17:26:13 2009
From: report at bugs.python.org (Vikram U Shenoy)
Date: Fri, 05 Jun 2009 15:26:13 +0000
Subject: [New-bugs-announce] [issue6206] Correct a trivial typo introduced
	by r73238.
In-Reply-To: <1244215573.84.0.259638619581.issue6206@psf.upfronthosting.co.za>
Message-ID: <1244215573.84.0.259638619581.issue6206@psf.upfronthosting.co.za>


New submission from Vikram U Shenoy <vikram.u.shenoy at gmail.com>:

Attached is a patch which should fix the 'too many values to unpack'
error introduced by commit r73238.

----------
components: Tests
files: test__locale_typo_jun_5_2009.patch
keywords: patch
messages: 88949
nosy: vshenoy
severity: normal
status: open
title: Correct a trivial typo introduced by r73238.
versions: Python 2.7
Added file: http://bugs.python.org/file14194/test__locale_typo_jun_5_2009.patch

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

From report at bugs.python.org  Fri Jun  5 17:54:36 2009
From: report at bugs.python.org (Gabriel Koritzky)
Date: Fri, 05 Jun 2009 15:54:36 +0000
Subject: [New-bugs-announce] [issue6207] Simple For-Loops
In-Reply-To: <1244217276.14.0.120438841588.issue6207@psf.upfronthosting.co.za>
Message-ID: <1244217276.14.0.120438841588.issue6207@psf.upfronthosting.co.za>


New submission from Gabriel Koritzky <naoehomeuemail at gmail.com>:

I don't know if something like this has been said before, so if it did
just ignore this.

I have noticed that very few programming languages use simple for loops.
Python itself doesn't have a really simple one. So here's my suggestion:

for ( value ):
# Repeats the code that follows 'value' times if value is an integer. If
it's a string or a list, repeats the code once per character or instance
on 'value'.

for ( iniINC , finalEXC ):
# Repeats the code that follows 'finalEXC - iniINC' times if they're
integers.

for ( variable , iniINC , finalEXC ):
# Assigns iniINC to variable and raises it by one until it reaches
finalEXC (not executing when it does).

#example1
for 70:
	doNothing()

#example2
a = 10
for a:
	doNothing()

#example3
a = 5
for ( a , 10 ):
	doNothing()

#example4
i = 0
for ( i , 10 , 20 ):
	doNothing()

----------
messages: 88950
nosy: gabrielkfl
severity: normal
status: open
title: Simple For-Loops

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

From report at bugs.python.org  Fri Jun  5 20:21:50 2009
From: report at bugs.python.org (ThurnerRupert)
Date: Fri, 05 Jun 2009 18:21:50 +0000
Subject: [New-bugs-announce] [issue6208] path separator output ignores
	shell's path separator: /	instead of \
In-Reply-To: <1244226110.31.0.876689452852.issue6208@psf.upfronthosting.co.za>
Message-ID: <1244226110.31.0.876689452852.issue6208@psf.upfronthosting.co.za>


New submission from ThurnerRupert <rupert.thurner at credit-suisse.com>:

when installing python for windows and running it from a msys or cygwin
shell, python does not notice that the path separator is backslash "/"
instead of forward slash "\".

can this be configured somehow, so the outputs are done like the current
shell accepts it? like checking in
http://docs.python.org/library/os.path.html what the parent process accepts?

----------
messages: 88958
nosy: ThurnerRupert
severity: normal
status: open
title: path separator output ignores shell's path separator: / instead of \
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Fri Jun  5 21:01:44 2009
From: report at bugs.python.org (dpodbori)
Date: Fri, 05 Jun 2009 19:01:44 +0000
Subject: [New-bugs-announce] [issue6209] compilation error in std. lib.
	module shutil (Python	3.1rc1, platform Win32)
In-Reply-To: <1244228504.73.0.885392136191.issue6209@psf.upfronthosting.co.za>
Message-ID: <1244228504.73.0.885392136191.issue6209@psf.upfronthosting.co.za>


New submission from dpodbori <dpodbori at gmail.com>:

In Python 3.1rc1 (observed under Win32) standard library function 
shutil.copyfile(src, dst) has an unreferenced local variable "st" that 
causes the following exception in the calling code:

D:\> c:\Python31\python.exe copyDrivers.py
Traceback (most recent call last):
  File "copyDrivers.py", line 20, in <module>
    shutil.copy( file1, file2)
  File "c:\Python31\lib\shutil.py", line 101, in copy
    copyfile(src, dst)
  File "c:\Python31\lib\shutil.py", line 62, in copyfile
    if stat.S_ISFIFO(st.st_mode):
UnboundLocalError: local variable 'st' referenced before assignment

----------
components: Library (Lib)
messages: 88964
nosy: dpodbori
severity: normal
status: open
title: compilation error in std. lib. module shutil (Python 3.1rc1, platform Win32)
type: compile error
versions: Python 3.1

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

From report at bugs.python.org  Fri Jun  5 21:04:25 2009
From: report at bugs.python.org (Patrick W.)
Date: Fri, 05 Jun 2009 19:04:25 +0000
Subject: [New-bugs-announce] [issue6210] Exception Chaining missing method
	for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>


New submission from Patrick W. <poke at BornToLaugh.de>:

I'm currently writing a library that executes predefined http requests
to a specified server. In case there is for example a HTTP Error, I want
to raise a user-defined exception that contains additional information
about when the error actually occured (so that the user of that library
gets information what happened without having to look at the actual
library code).
The in Python 3 introduced "feature" of chained exceptions (PEP 3134) is
something which is a bit annoying in that particular situation. While it
is probably good in a lot situation to know where an exception comes
from (especially when they are chained), it makes reading the actual
exception for the library user harder.
Let me show you an example:

def doXY ():
  # ...
  try:
    page = urlopen( someRequest )
  except urllib.error.URLError as e:
    raise MyError( 'while doing XY', e )
  # ...

MyError is an exception class, that uses the second parameter to get
additional information (for HTTPErrors the status code for example) and
compiles a detailed error message.
Before Python 3, this was a good way to prevent users from having to dig
into the code when they encounter an exception. Now however, you get
some error message like this:

-----
Traceback (most recent call last):
  File "..", line ., in doXY
    page = urlopen( someRequest )
  File "..\lib\urllib\request.py", line 122,
in urlopen
    return _opener.open(url, data, timeout)
  File "..\lib\urllib\request.py", line 364,
in open
    response = meth(req, response)
  File "..\lib\urllib\request.py", line 476,
in http_response
    'http', request, response, code, msg, hdrs)
  File "..\lib\urllib\request.py", line 402,
in error
    return self._call_chain(*args)
  File "..\lib\urllib\request.py", line 336,
in _call_chain
    result = func(*args)
  File "..\lib\urllib\request.py", line 484,
in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib.error.HTTPError: HTTP Error 401: Unauthorized

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "..", line ., in <module>
    doXY()
  File "..", line ., in doXY
    raise MyError( 'while doing XY', e )
MyError: 'HTTP Error 401 while doing XY (Unauthorized)'
-----

While the error message of MyError would be completely sufficient for
the user to know (and to fix by simply giving correct data) he is
flooded with a lot of information about the previously raised exception
instead with far too many unneccessary information.

So what I basically would like to have is some mechanism to prevent
Python from printing out all previous exception. As there is already the
'raise NewException from PreviousException' syntax, something like
'raise NewException from None' would be great, with explicitely stating
None to clear the buffer of previous exceptions.


Thanks you for any comments on this issue.
Patrick W.

----------
components: Interpreter Core
messages: 88965
nosy: poke
severity: normal
status: open
title: Exception Chaining missing method for suppressing context
type: feature request
versions: Python 3.0

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

From report at bugs.python.org  Fri Jun  5 21:46:07 2009
From: report at bugs.python.org (Michael Markert)
Date: Fri, 05 Jun 2009 19:46:07 +0000
Subject: [New-bugs-announce] [issue6211] [Tutorial] Section 4.7.2 has a
	wrong description of an	example
In-Reply-To: <1244231167.47.0.192271891945.issue6211@psf.upfronthosting.co.za>
Message-ID: <1244231167.47.0.192271891945.issue6211@psf.upfronthosting.co.za>


New submission from Michael Markert <markert.michael at gmail.com>:

[Tutorial] Section 4.7.2 has a piece of example code which gives three
possibilities to call that function, but the description states that
there are only two possibilities.

Attached patch changes that and gives the third possibility of calling.

----------
assignee: georg.brandl
components: Documentation
files: controlflow.patch
keywords: patch
messages: 88969
nosy: cofi, georg.brandl
severity: normal
status: open
title: [Tutorial] Section 4.7.2 has a wrong description of an example
versions: Python 3.1
Added file: http://bugs.python.org/file14197/controlflow.patch

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

From report at bugs.python.org  Fri Jun  5 21:59:23 2009
From: report at bugs.python.org (Robert T McQuaid)
Date: Fri, 05 Jun 2009 19:59:23 +0000
Subject: [New-bugs-announce] [issue6212] piped input
In-Reply-To: <1244231963.89.0.682497283333.issue6212@psf.upfronthosting.co.za>
Message-ID: <1244231963.89.0.682497283333.issue6212@psf.upfronthosting.co.za>


New submission from Robert T McQuaid <rtmq at fixcas.com>:

#
#  Python 3.0.1 can read piped input when invoked with a
#  program name as the argument of the interpreter, but not
#  when invoked implicitly by the file extension.  On
#  Windows xp the first command below runs successfully, the
#  second ends with a diagnostic:  'NoneType' object has no
#  attribute 'isatty'
#
#
#  dir | e:\python30\python test17.py
#  dir | test17.py
#
#

import sys
if sys.stdin.isatty(): pass

----------
components: IO
messages: 88970
nosy: rtmq
severity: normal
status: open
title: piped input
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Fri Jun  5 22:17:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Jun 2009 20:17:43 +0000
Subject: [New-bugs-announce] [issue6213] Incremental encoder incompatibility
	between 2.x and py3k
In-Reply-To: <1244233063.22.0.634170589597.issue6213@psf.upfronthosting.co.za>
Message-ID: <1244233063.22.0.634170589597.issue6213@psf.upfronthosting.co.za>


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

The behaviour of several incremental encoders is inconsistent between
2.x and py3k.

In 2.x:
>>> enc = codecs.getincrementalencoder('utf-16')()
>>> enc.getstate()
0
>>> enc.setstate(0)
>>> enc.encode(u'abc')
'\xff\xfea\x00b\x00c\x00'

In py3k:
>>> enc = codecs.getincrementalencoder('utf-16')()
>>> enc.getstate()
2
>>> enc.setstate(0)
>>> enc.encode('abc')
b'a\x00b\x00c\x00'

----------
messages: 88972
nosy: pitrou
priority: normal
severity: normal
status: open
title: Incremental encoder incompatibility between 2.x and py3k
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jun  5 23:21:32 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Jun 2009 21:21:32 +0000
Subject: [New-bugs-announce] [issue6214] test__locale broken on trunk
In-Reply-To: <1244236892.05.0.964070660069.issue6214@psf.upfronthosting.co.za>
Message-ID: <1244236892.05.0.964070660069.issue6214@psf.upfronthosting.co.za>


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

======================================================================
ERROR: test_lc_numeric_localeconv (test.test__locale._LocaleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test__locale.py", line
88, in test_lc_numeric_localeconv
    "thousands_sep"):
ValueError: too many values to unpack

----------
assignee: ocean-city
components: Tests
messages: 88973
nosy: ocean-city, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test__locale broken on trunk
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun  5 23:29:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Jun 2009 21:29:18 +0000
Subject: [New-bugs-announce] [issue6215] Backport the IO lib to trunk
In-Reply-To: <1244237358.55.0.232192412038.issue6215@psf.upfronthosting.co.za>
Message-ID: <1244237358.55.0.232192412038.issue6215@psf.upfronthosting.co.za>


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

The new IO lib has undergone deep changes in py3k which have never been
backported to trunk. This patch brings trunk up to date, including tests.

----------
components: IO
files: iobackport.patch
keywords: patch
messages: 88974
nosy: pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Backport the IO lib to trunk
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file14198/iobackport.patch

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

From report at bugs.python.org  Sat Jun  6 02:04:13 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 06 Jun 2009 00:04:13 +0000
Subject: [New-bugs-announce] [issue6216] Raise Unicode KEEPALIVE_SIZE_LIMIT
	from 9 to 32?
In-Reply-To: <1244246653.62.0.629764911773.issue6216@psf.upfronthosting.co.za>
Message-ID: <1244246653.62.0.629764911773.issue6216@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

>From msg88801
'''
for 3.1: raising the KEEPALIVE_SIZE_LIMIT to 32 as explained and
motivated here:

msg64215

That's a simple non-disruptive change which makes a lot of sense
due to the advances in CPU designs in the last 9 years. I determined
the original value of 9 using benchmarks and similar statistics in
1999/2000.

It's probably also a good time to remove the warning, now that the
implementation has proven itself for so many years...

/* Limit for the Unicode object free list stay alive optimization.

   The implementation will keep allocated Unicode memory intact for
   all objects on the free list having a size less than this
   limit. This reduces malloc() overhead for small Unicode objects.

   At worst this will result in PyUnicode_MAXFREELIST *
   (sizeof(PyUnicodeObject) + KEEPALIVE_SIZE_LIMIT +
   malloc()-overhead) bytes of unused garbage.

   Setting the limit to 0 effectively turns the feature off.

   Note: This is an experimental feature ! If you get core dumps when
   using Unicode objects, turn this feature off.

*/

#define KEEPALIVE_SIZE_LIMIT       9
'''
If this is as non-controversial as it seems, perhaps someone could
change 9 to 32 and remove "Note: This is an experimental feature..." in
time for rc2.

----------
components: Interpreter Core
messages: 88981
nosy: tjreedy
severity: normal
status: open
title: Raise Unicode KEEPALIVE_SIZE_LIMIT from 9 to 32?
type: resource usage
versions: Python 3.1

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

From report at bugs.python.org  Sat Jun  6 03:57:20 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Sat, 06 Jun 2009 01:57:20 +0000
Subject: [New-bugs-announce] [issue6217] Add _io._TextIOWrapper.errors
In-Reply-To: <1244253440.08.0.0505415308962.issue6217@psf.upfronthosting.co.za>
Message-ID: <1244253440.08.0.0505415308962.issue6217@psf.upfronthosting.co.za>


New submission from Philip Jenvey <pjenvey at users.sourceforge.net>:

_pyio.TextIOWrapper provides the encoding and associated errors values, 
but _io._TextIOWrapper only provides encoding. Patch adds errors and has 
it show up in repr in both places, against py3k

----------
components: IO
files: textiowrapper-errors.diff
keywords: patch
messages: 88986
nosy: pitrou, pjenvey
severity: normal
status: open
title: Add _io._TextIOWrapper.errors
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14201/textiowrapper-errors.diff

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

From report at bugs.python.org  Sat Jun  6 04:21:15 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 06 Jun 2009 02:21:15 +0000
Subject: [New-bugs-announce] [issue6218] Make io.BytesIO and io.StringIO
	picklable.
In-Reply-To: <1244254875.51.0.0941712294298.issue6218@psf.upfronthosting.co.za>
Message-ID: <1244254875.51.0.0941712294298.issue6218@psf.upfronthosting.co.za>


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

Here is a patch to add pickling support to io.BytesIO and io.StringIO.
Although they are non-trivial, the additions were made with a fair
amount of care (and love!) and thus I believe they could be included in
3.1. 

Furthermore, the improved test-suite uncovered a number of bugs in the
implementation of io.StringIO. So the patch also fixes:

  * fixes a memory-leak in stringio_dealloc; 
  * disallows bytes-like object from being used as the newline
    argument of StringIO;
  * and changes the exception raised by StringIO.__init__ to a
    TypeError when initial_value is not a str.

----------
components: IO, Library (Lib)
files: pickle_support_for_memoryio.diff
keywords: patch, patch
messages: 88987
nosy: alexandre.vassalotti
priority: normal
severity: normal
stage: patch review
status: open
title: Make io.BytesIO and io.StringIO picklable.
type: feature request
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14202/pickle_support_for_memoryio.diff

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

From report at bugs.python.org  Sat Jun  6 09:04:03 2009
From: report at bugs.python.org (Pushkar Paranjpe)
Date: Sat, 06 Jun 2009 07:04:03 +0000
Subject: [New-bugs-announce] [issue6219] nested list value change
In-Reply-To: <1244271843.74.0.384598823496.issue6219@psf.upfronthosting.co.za>
Message-ID: <1244271843.74.0.384598823496.issue6219@psf.upfronthosting.co.za>


New submission from Pushkar Paranjpe <pushkarparanjpe at gmail.com>:

Is this a bug ?

>>> a = [[1,2],[3,4],[5,6]]
>>> a
[[1, 2], [3, 4], [5, 6]]
>>> b = a[0]
>>> b
[1, 2]
>>> b[0] = -8888
>>> b
[-8888, 2]
>>> a
[[-8888, 2], [3, 4], [5, 6]]
>>>

Created a new variable (b) which refers to an element in a list (a).
Changing the value of the new variable also reflects in the original
list. I thought the new variable is actually a new variable with its own
memory allocation and not a symbolic link to pre-existing data. is this
a bug?
Please help.

----------
components: Library (Lib)
messages: 88989
nosy: pushkarparanjpe
severity: normal
status: open
title: nested list value change
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Sat Jun  6 11:58:28 2009
From: report at bugs.python.org (cate)
Date: Sat, 06 Jun 2009 09:58:28 +0000
Subject: [New-bugs-announce] [issue6220] typo: opne in "doanddont"
In-Reply-To: <1244282308.76.0.113174634694.issue6220@psf.upfronthosting.co.za>
Message-ID: <1244282308.76.0.113174634694.issue6220@psf.upfronthosting.co.za>


New submission from cate <cate at debian.org>:

http://docs.python.org/dev/howto/doanddont.html use twice in example the
"opne" function, which should be written as "open". From google it seems
that also 3.x is affected (but not really checked)

----------
assignee: georg.brandl
components: Documentation
messages: 88992
nosy: cate, georg.brandl
severity: normal
status: open
title: typo: opne in "doanddont"
versions: Python 2.7

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

From report at bugs.python.org  Sat Jun  6 15:26:31 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Jun 2009 13:26:31 +0000
Subject: [New-bugs-announce] [issue6221] Windows buildbot failure in
	test_winreg
In-Reply-To: <1244294791.11.0.0504716192427.issue6221@psf.upfronthosting.co.za>
Message-ID: <1244294791.11.0.0504716192427.issue6221@psf.upfronthosting.co.za>


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

I'm filing this as release blocker since it might indicate serious
breakage (I'm not a Windows expert).


======================================================================
FAIL: testLocalMachineRegistryWorks (test.test_winreg.WinregTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"E:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_winreg.py",
line 148, in testLocalMachineRegistryWorks
    self.TestAll(HKEY_CURRENT_USER)
  File
"E:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_winreg.py",
line 143, in TestAll
    self.WriteTestData(root_key, subkeystr)
  File
"E:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_winreg.py",
line 50, in WriteTestData
    "Not the correct number of values")
AssertionError: Not the correct number of values

----------------------------------------------------------------------

----------
components: Library (Lib), Tests
messages: 89001
nosy: pitrou
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Windows buildbot failure in test_winreg
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Sat Jun  6 18:11:53 2009
From: report at bugs.python.org (Haoyu Bai)
Date: Sat, 06 Jun 2009 16:11:53 +0000
Subject: [New-bugs-announce] [issue6222] 2to3 except fixer failed in certain
	case
In-Reply-To: <1244304713.46.0.332603077148.issue6222@psf.upfronthosting.co.za>
Message-ID: <1244304713.46.0.332603077148.issue6222@psf.upfronthosting.co.za>


New submission from Haoyu Bai <divinekid at gmail.com>:

The 2to3 except fixer will be failed with this code:

try: raise TypeError
except TypeError, x:
    pass

with this code, 2to3 will produce an empty diff, i.e. it fixes nothing.

But when change it to the following, 2to3 works again:

try:
    raise TypeError
except TypeError, x:
    pass

with this, 2to3 will provide a correct diff.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 89005
nosy: bhy
severity: normal
status: open
title: 2to3 except fixer failed in certain case
versions: Python 2.6, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat Jun  6 19:11:05 2009
From: report at bugs.python.org (Haoyu Bai)
Date: Sat, 06 Jun 2009 17:11:05 +0000
Subject: [New-bugs-announce] [issue6223] Make _PyUnicode_AsString as public
	API
In-Reply-To: <1244308265.08.0.506507735575.issue6223@psf.upfronthosting.co.za>
Message-ID: <1244308265.08.0.506507735575.issue6223@psf.upfronthosting.co.za>


New submission from Haoyu Bai <divinekid at gmail.com>:

Why _PyUnicode_AsString and _PyUnicode_AsStringAndSize are not public
API? They are very useful when porting extension module to Python 3,
because they have the semantic as same as PyString_AsString. For
extension author, these API can be used for replacing PyString_AsString
without any other change in code logic.

So why not make these API public? Any consideration? If we can document
these API, then C extension author can know them and use them, without
spending a lot of time to dig them out from Python source code.

Thanks!

----------
assignee: georg.brandl
components: Documentation, Extension Modules, Interpreter Core, Unicode
messages: 89007
nosy: bhy, georg.brandl
severity: normal
status: open
title: Make _PyUnicode_AsString as public API
type: feature request
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Jun  6 20:11:36 2009
From: report at bugs.python.org (Thijs Triemstra)
Date: Sat, 06 Jun 2009 18:11:36 +0000
Subject: [New-bugs-announce] [issue6224] References to JPython
In-Reply-To: <1244311896.45.0.961216428321.issue6224@psf.upfronthosting.co.za>
Message-ID: <1244311896.45.0.961216428321.issue6224@psf.upfronthosting.co.za>


New submission from Thijs Triemstra <lists at collab.nl>:

The documentation refers to JPython in several places, which is the old 
name, it's called Jython nowadays.

 - platform.java_ver
 - tkinter

----------
assignee: georg.brandl
components: Documentation
messages: 89012
nosy: georg.brandl, thijs
severity: normal
status: open
title: References to JPython
versions: Python 2.5, Python 2.6, Python 3.1

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

From report at bugs.python.org  Sat Jun  6 23:56:36 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 06 Jun 2009 21:56:36 +0000
Subject: [New-bugs-announce] [issue6225] Fixing several minor bugs in
	Tkinter.Canvas and one in	Misc._configure
In-Reply-To: <1244325396.24.0.788727463424.issue6225@psf.upfronthosting.co.za>
Message-ID: <1244325396.24.0.788727463424.issue6225@psf.upfronthosting.co.za>


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

Hi,

While testing Tkinter.Canvas I've found several minor bugs that I would
prefer to see fixed. Many of them change the current Canvas api a bit,
but for better. For example, the methods "focus", "gettags", "icursor",
"index", "insert", "move" (and some others) accept arbitrary amount of
arguments, but all these tcl subcommands have a fixed amount of
arguments they accept, so I consider it is better to make this clear on
Tkinter too.

I've also found a problem in Misc._configure which is also fixed by the
attached patch. The problem is that when cnf is a string, the call
"self.tk.split(self.tk.call(_flatten((self._w, cmd, '-'+cnf))))" may
still result in an empty string causing the following statement to fail
"return (x[0][1:],) + x[1:]".

One thing that left me curious was the comment "# XXX Should use
_flatten on args" in Canvas.coords. I've tried understanding why it
should use _flatten there, but couldn't figure it out. This is a very
old comment, so maybe it is no longer true ?

----------
components: Tkinter
files: Canvas_fixes.diff
keywords: patch
messages: 89019
nosy: gpolo
severity: normal
status: open
title: Fixing several minor bugs in Tkinter.Canvas and one in Misc._configure
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14207/Canvas_fixes.diff

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

From report at bugs.python.org  Sun Jun  7 00:02:08 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Sat, 06 Jun 2009 22:02:08 +0000
Subject: [New-bugs-announce] [issue6226] Inconsistent 'file' vs 'stream'
	kwarg in pprint, other stdlibs
In-Reply-To: <1244325728.64.0.945262534879.issue6226@psf.upfronthosting.co.za>
Message-ID: <1244325728.64.0.945262534879.issue6226@psf.upfronthosting.co.za>


New submission from Philip Jenvey <pjenvey at users.sourceforge.net>:

It'd be nice to eventually standardize on the kwarg name used for basic 
file-like args in the stdlib. print, warnings.showwarning and some 
others take a file= argument whereas pprint, getpass.getpass take 
stream=

print and pprint in particular should match -- though they do have a 
different option set, when you're using the same options this 
consistency would ease replacing:

print(obj, file=sys.stderr)
with
pprint(obj, stream=sys.stderr)

----------
components: Library (Lib)
messages: 89020
nosy: pjenvey
severity: normal
status: open
title: Inconsistent 'file' vs 'stream' kwarg in pprint, other stdlibs
type: feature request

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

From report at bugs.python.org  Sun Jun  7 06:37:44 2009
From: report at bugs.python.org (James Abbatiello)
Date: Sun, 07 Jun 2009 04:37:44 +0000
Subject: [New-bugs-announce] [issue6227] doctest_aliases doesn't test
	duplicate removal
In-Reply-To: <1244349464.7.0.139481605677.issue6227@psf.upfronthosting.co.za>
Message-ID: <1244349464.7.0.139481605677.issue6227@psf.upfronthosting.co.za>


New submission from James Abbatiello <abbeyj at gmail.com>:

The file Lib/test/doctest_aliases.py is used by test_doctest to check
the handling of duplicate removal.  The "g = f" line in this file is one
indent too far to the right so instead of creating an alias for f called
g it is just unreachable code inside of f.  Since there is no alias
there is no need to remove duplicates and the test passes trivially.

I think this affects all versions but I've only checked on 2.7.

----------
components: Tests
files: doctest_aliases.patch
keywords: patch
messages: 89027
nosy: abbeyj
severity: normal
status: open
title: doctest_aliases doesn't test duplicate removal
versions: Python 2.7
Added file: http://bugs.python.org/file14210/doctest_aliases.patch

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

From report at bugs.python.org  Sun Jun  7 09:44:04 2009
From: report at bugs.python.org (steve21)
Date: Sun, 07 Jun 2009 07:44:04 +0000
Subject: [New-bugs-announce] [issue6228] round() error
In-Reply-To: <1244360644.6.0.321389592966.issue6228@psf.upfronthosting.co.za>
Message-ID: <1244360644.6.0.321389592966.issue6228@psf.upfronthosting.co.za>


New submission from steve21 <steve872929-bv at yahoo.com.au>:

I wish to round the float 697.04157958254996 to 10 decimal digits after
the decimal point.

$ python3.0
Python 3.0.1 (r301:69556, Jun  7 2009, 14:51:41)
[GCC 4.3.2 20081105 (Red Hat 4.3.2-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>> 697.04157958254996
697.04157958254996      # python float can represent this number exactly

>>> 697.04157958250000  # this is the expected result
697.04157958250005      # this is the closest python float representation

>>> round(697.04157958254996, 10)
697.04157958259998      # error

round() gives a result that is closer to
697.0415795826
than the expected result of
697.0415795825
- it has not rounded to the closest 10th decimal digit after the decimal
point.

(python 2.6.2 has the same problem)

----------
messages: 89029
nosy: steve21
severity: normal
status: open
title: round() error
type: behavior
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Sun Jun  7 12:05:02 2009
From: report at bugs.python.org (eric)
Date: Sun, 07 Jun 2009 10:05:02 +0000
Subject: [New-bugs-announce] [issue6229] Installation python on mac
In-Reply-To: <1244369102.02.0.674682912004.issue6229@psf.upfronthosting.co.za>
Message-ID: <1244369102.02.0.674682912004.issue6229@psf.upfronthosting.co.za>


New submission from eric <mullen at gmx.ch>:

Hello
i wan't to install the python 3.0 on my mac. the python image, .dmg
file, i download from this site, run the installation. After this, the
framework doesn't installation in the folder
/System/Library/Frameworks/Python.framework.
How can i change the installation folder?

thx kostonstyle

----------
messages: 89030
nosy: kostonstyle
severity: normal
status: open
title: Installation python on mac
versions: Python 3.0

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

From report at bugs.python.org  Sun Jun  7 16:08:16 2009
From: report at bugs.python.org (Neil Muller)
Date: Sun, 07 Jun 2009 14:08:16 +0000
Subject: [New-bugs-announce] [issue6230] ElementTree.Element and
	cElementTree.Element have	slightly different repr
In-Reply-To: <1244383696.52.0.0575632707865.issue6230@psf.upfronthosting.co.za>
Message-ID: <1244383696.52.0.0575632707865.issue6230@psf.upfronthosting.co.za>


New submission from Neil Muller <drnlmuller+bugs at gmail.com>:

ElementTree and cElementTree give slightly different results for
repr(Element):

>>> import xml.etree.ElementTree as ET
>>> import xml.etree.cElementTree as cET
>>> repr(ET.ElementTree('tag'))
'<Element tag at b7cf506c>'
>>> repr(cET.ElementTree('tag')
"<Element 'tag' at 0xb7c266f8>"

The quoting around the tag name is missing from ElementTree.

This inconsistency seems pointless.

Attached patch changes ElementTree to match cElementTree behaviour, and
adds a test.

----------
components: Library (Lib)
files: repr-fix.diff
keywords: patch
messages: 89035
nosy: Neil Muller, effbot
severity: normal
status: open
title: ElementTree.Element and cElementTree.Element have slightly different repr
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14212/repr-fix.diff

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

From report at bugs.python.org  Sun Jun  7 16:21:44 2009
From: report at bugs.python.org (Neil Muller)
Date: Sun, 07 Jun 2009 14:21:44 +0000
Subject: [New-bugs-announce] [issue6231] ElementInclude may drop text
In-Reply-To: <1244384504.27.0.561199535147.issue6231@psf.upfronthosting.co.za>
Message-ID: <1244384504.27.0.561199535147.issue6231@psf.upfronthosting.co.za>


New submission from Neil Muller <drnlmuller+bugs at gmail.com>:

In some cases, ElementInclude will not include the tail from the current
node.

Test case and patch against trunk attached (from Simon Cross).

----------
components: Library (Lib)
files: ElementInclude.diff
keywords: patch
messages: 89037
nosy: Neil Muller, effbot, hodgestar
severity: normal
status: open
title: ElementInclude may drop text
type: behavior
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14214/ElementInclude.diff

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

From report at bugs.python.org  Sun Jun  7 16:31:24 2009
From: report at bugs.python.org (Neil Muller)
Date: Sun, 07 Jun 2009 14:31:24 +0000
Subject: [New-bugs-announce] [issue6232] Improve test coverage of
	ElementTree and cElementTree
In-Reply-To: <1244385084.63.0.587386346669.issue6232@psf.upfronthosting.co.za>
Message-ID: <1244385084.63.0.587386346669.issue6232@psf.upfronthosting.co.za>


New submission from Neil Muller <drnlmuller+bugs at gmail.com>:

The test coverage for ElementTree and cElementTree could be improved.

The attached file adds several more tests for ElementTree (including a
number from the ElementTree 1.2.7 pre-release).

This excludes the tests suggested in:
http://bugs.python.org/issue6230
http://bugs.python.org/issue6231
http://bugs.python.org/issue2746

----------
components: Tests
files: test_xml_etree.py
messages: 89038
nosy: Neil Muller, effbot
severity: normal
status: open
title: Improve test coverage of ElementTree and cElementTree
versions: Python 2.7
Added file: http://bugs.python.org/file14215/test_xml_etree.py

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

From report at bugs.python.org  Sun Jun  7 23:31:00 2009
From: report at bugs.python.org (Neil Muller)
Date: Sun, 07 Jun 2009 21:31:00 +0000
Subject: [New-bugs-announce] [issue6233] ElementTree (py3k) doesn't properly
	encode characters	that can't be represented in the specified
	encoding
In-Reply-To: <1244410260.68.0.534028988218.issue6233@psf.upfronthosting.co.za>
Message-ID: <1244410260.68.0.534028988218.issue6233@psf.upfronthosting.co.za>


New submission from Neil Muller <drnlmuller+bugs at gmail.com>:

In py3k, ElementTree no longer correctly converts characters to entities
when they can't be represented in the requested output encoding.

Python 2:

>>> import xml.etree.ElementTree as ET
>>> e = ET.XML("<?xml version='1.0'
encoding='iso-8859-1'?><body>t\xe3t</body>")
>>> ET.tostring(e, 'ascii')
"<?xml version='1.0' encoding='ascii'?>\n<body>t&#227;t</body>"

Python 3:

>>> import xml.etree.ElementTree as ET
>>> e = ET.XML("<?xml version='1.0'
encoding='iso-8859-1'?><body>t\xe3t</body>")
>>> ET.tostring(e, 'ascii')
.....
UnicodeEncodeError: 'ascii' codec can't encode characters in position
1-2: ordinal not in range(128)


It looks like _encode_entity isn't ever called inside ElementTree
anymore - it probably should be called as part of _encode for characters
that can't be represented.

----------
components: Library (Lib)
messages: 89058
nosy: Neil Muller, effbot, hodgestar
severity: normal
status: open
title: ElementTree (py3k) doesn't properly encode characters that can't be represented in the specified encoding
type: behavior
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Jun  8 00:07:36 2009
From: report at bugs.python.org (Evan Fosmark)
Date: Sun, 07 Jun 2009 22:07:36 +0000
Subject: [New-bugs-announce] [issue6234] cgi.FieldStorage is broken when
	given POST data
In-Reply-To: <1244412456.94.0.493968112391.issue6234@psf.upfronthosting.co.za>
Message-ID: <1244412456.94.0.493968112391.issue6234@psf.upfronthosting.co.za>


New submission from Evan Fosmark <me at evanfosmark.com>:

Right now, it seems impossible to use cgi.FieldStorage in 3.0 if you're
giving it environ['wsgi.input'] like so:

    post_data = cgi.FieldStorage(
        fp=environ["wsgi.input"],
        environ=environ,
        keep_blank_values=True
        )


It gives the following error:

      File "/usr/local/lib/python3.0/cgi.py", line 489, in __init__
        self.read_urlencoded()
      File "/usr/local/lib/python3.0/cgi.py", line 589, in read_urlencoded
        self.strict_parsing):
      File "/usr/local/lib/python3.0/urllib/parse.py", line 377, in
parse_qsl
        pairs = [s2 for s1 in qs.split('&') for s2 in s1.split(';')]
TypeError: Type str doesn't support the buffer API

----------
components: Library (Lib)
messages: 89060
nosy: efosmark
severity: normal
status: open
title: cgi.FieldStorage is broken when given POST data
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Mon Jun  8 03:51:23 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 08 Jun 2009 01:51:23 +0000
Subject: [New-bugs-announce] [issue6235] \d missing from effects of re.ASCII
	flag
In-Reply-To: <1244425883.3.0.62231385408.issue6235@psf.upfronthosting.co.za>
Message-ID: <1244425883.3.0.62231385408.issue6235@psf.upfronthosting.co.za>


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

In the documentation of the re module the ASCII flag is described as
"Make \w, \W, \b, \B, \s and \S perform ASCII-only matching instead of
full Unicode matching." This should also include \d and \D.

----------
assignee: georg.brandl
components: Documentation
messages: 89064
nosy: MLModel, georg.brandl
severity: normal
status: open
title: \d missing from effects of re.ASCII flag
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Jun  8 04:20:18 2009
From: report at bugs.python.org (nestor)
Date: Mon, 08 Jun 2009 02:20:18 +0000
Subject: [New-bugs-announce] [issue6236] os.popen causes illegal seek on AIX
	in Python 3.1rc
In-Reply-To: <1244427618.5.0.797941537993.issue6236@psf.upfronthosting.co.za>
Message-ID: <1244427618.5.0.797941537993.issue6236@psf.upfronthosting.co.za>


New submission from nestor <nestornissen at gmail.com>:

Python 2.6.2 (r262:71600, Jun  4 2009, 16:07:26) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.popen('cat','w')

<open file 'cat', mode 'w' at 0x1101ab4f8>


Python 3.0.1 (r301:69556, Jun  4 2009, 16:07:22) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.popen('cat','w')

<os._wrap_close object at 0x1103e5748> 

Python 3.1rc1 (r31rc1:73054, Jun  1 2009, 10:49:24) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.popen('cat','w')

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Python-3.1rc1/Lib/os.py", line 641, in popen
    return _wrap_close(io.TextIOWrapper(proc.stdin), proc)
IOError: [Errno 29] Illegal seek 

This in turn causes help not to work:

Python 3.1rc1 (r31rc1:73054, Jun  1 2009, 10:49:24) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
>>> help(open)

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Python-3.1rc1/Lib/site.py", line 429, in __call__
    return pydoc.help(*args, **kwds)
  File "/Python-3.1rc1/Lib/pydoc.py", line 1709, in __call__
    self.help(request)
  File "/Python-3.1rc1/Lib/pydoc.py", line 1756, in help
    else: doc(request, 'Help on %s:')
  File "/Python-3.1rc1/Lib/pydoc.py", line 1505, in doc
    pager(render_doc(thing, title, forceload))
  File "/Python-3.1rc1/Lib/pydoc.py", line 1320, in pager
    pager(text)
  File "/Python-3.1rc1/Lib/pydoc.py", line 1340, in <lambda>
    return lambda text: pipepager(text, 'less')
  File "/Python-3.1rc1/Lib/pydoc.py", line 1359, in pipepager
    pipe = os.popen(cmd, 'w')
  File "/Python-3.1rc1/Lib/os.py", line 641, in popen
    return _wrap_close(io.TextIOWrapper(proc.stdin), proc)
IOError: [Errno 29] Illegal seek

----------
components: Library (Lib)
messages: 89065
nosy: nestor
severity: normal
status: open
title: os.popen causes illegal seek on AIX in Python 3.1rc
versions: Python 3.1

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

From report at bugs.python.org  Mon Jun  8 04:26:53 2009
From: report at bugs.python.org (Funda Wang)
Date: Mon, 08 Jun 2009 02:26:53 +0000
Subject: [New-bugs-announce] [issue6237] Build errors when using
	LDFLAGS="-Wl, --no-undefined"
In-Reply-To: <1244428013.0.0.0482442850802.issue6237@psf.upfronthosting.co.za>
Message-ID: <1244428013.0.0.0482442850802.issue6237@psf.upfronthosting.co.za>


New submission from Funda Wang <fundawang at gmail.com>:

============================
gcc -pthread -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -lstdc++ -
Xlinker -export-dynamic -o python \
                        Modules/python.o \
                        -L. -lpython2.6 -lpthread -ldl  -lutil   -lm
build/temp.linux-i686-2.6/home/fwang/rpm/BUILD/Python-2.6.2/Modules/
_ctypes/_ctypes_test.o: In function `my_sqrt':
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/_ctypes/_ctypes_test.c:83: 
undefined reference to `sqrt'
collect2: ld returned 1 exit status
build/temp.linux-i686-2.6/home/fwang/rpm/BUILD/Python-2.6.2/Modules/
audioop.o: In function `audioop_rms':
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/audioop.c:419: undefined 
reference to `sqrt'
collect2: ld returned 1 exit status
build/temp.linux-i686-2.6/home/fwang/rpm/BUILD/Python-2.6.2/Modules/
dlmodule.o: In function `dl_open':
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/dlmodule.c:187: undefined 
reference to `dlopen'
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/dlmodule.c:189: undefined 
reference to `dlerror'
build/temp.linux-i686-2.6/home/fwang/rpm/BUILD/Python-2.6.2/Modules/
dlmodule.o: In function `dl_close':
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/dlmodule.c:49: undefined 
reference to `dlclose'
build/temp.linux-i686-2.6/home/fwang/rpm/BUILD/Python-2.6.2/Modules/
dlmodule.o: In function `dl_sym':
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/dlmodule.c:68: undefined 
reference to `dlsym'
build/temp.linux-i686-2.6/home/fwang/rpm/BUILD/Python-2.6.2/Modules/
dlmodule.o: In function `dl_call':
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/dlmodule.c:96: undefined 
reference to `dlsym'
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/dlmodule.c:100: undefined 
reference to `dlerror'
build/temp.linux-i686-2.6/home/fwang/rpm/BUILD/Python-2.6.2/Modules/
dlmodule.o: In function `dl_dealloc':
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/dlmodule.c:41: undefined 
reference to `dlclose'
collect2: ld returned 1 exit status

============================

build/temp.linux-i686-2.6/home/fwang/rpm/BUILD/Python-2.6.2/Modules/
_ctypes/_ctypes.o: In function `CDataType_in_dll':
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/_ctypes/_ctypes.c:600: 
undefined reference to `dlsym'
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/_ctypes/_ctypes.c:608: 
undefined reference to `dlerror'
build/temp.linux-i686-2.6/home/fwang/rpm/BUILD/Python-2.6.2/Modules/
_ctypes/_ctypes.o: In function `CFuncPtr_FromDll':
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/_ctypes/_ctypes.c:3285: 
undefined reference to `dlsym'
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/_ctypes/_ctypes.c:3293: 
undefined reference to `dlerror'
/usr/bin/ld: Dwarf Error: Offset (2614) greater than or equal 
to .debug_str size (815).
build/temp.linux-i686-2.6/home/fwang/rpm/BUILD/Python-2.6.2/Modules/
_ctypes/callproc.o: In function `py_dl_sym':
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/_ctypes/callproc.c:1448: 
undefined reference to `dlsym'
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/_ctypes/callproc.c:1451: 
undefined reference to `dlerror'
build/temp.linux-i686-2.6/home/fwang/rpm/BUILD/Python-2.6.2/Modules/
_ctypes/callproc.o: In function `py_dl_close':
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/_ctypes/callproc.c:1430: 
undefined reference to `dlclose'
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/_ctypes/callproc.c:1432: 
undefined reference to `dlerror'
build/temp.linux-i686-2.6/home/fwang/rpm/BUILD/Python-2.6.2/Modules/
_ctypes/callproc.o: In function `py_dl_open':
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/_ctypes/callproc.c:1412: 
undefined reference to `dlopen'
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/_ctypes/callproc.c:1414: 
undefined reference to `dlerror'
collect2: ld returned 1 exit status

============================


Failed to find the necessary bits to build these modules:
bsddb185           sunaudiodev
To find the necessary bits, look in setup.py in detect_modules() for 
the module's name.


Failed to build these modules:
_ctypes            _ctypes_test       audioop
dl

============================

I've attached the detail build log.

----------
components: Build
files: build.0.20090608003719.log.bz2
messages: 89066
nosy: fundawang
severity: normal
status: open
title: Build errors when using LDFLAGS="-Wl,--no-undefined"
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file14224/build.0.20090608003719.log.bz2

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

From report at bugs.python.org  Mon Jun  8 17:58:30 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 08 Jun 2009 15:58:30 +0000
Subject: [New-bugs-announce] [issue6238] string.ljust documentation is
	missing optional fillchar	description
In-Reply-To: <1244476710.84.0.84375943998.issue6238@psf.upfronthosting.co.za>
Message-ID: <1244476710.84.0.84375943998.issue6238@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

The documentation for string.ljust, string.rjust, and string.center is
missing the optional parameter fillchar.  The str.ljust documentation
appears to be correct.

This was observed in Python 2.6.2 documentation as found on the
docs.python.org site at the time of this report.

----------
assignee: georg.brandl
components: Documentation
messages: 89083
nosy: georg.brandl, jaraco
severity: normal
status: open
title: string.ljust documentation is missing optional fillchar description
versions: Python 2.6

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

From report at bugs.python.org  Mon Jun  8 18:07:29 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 08 Jun 2009 16:07:29 +0000
Subject: [New-bugs-announce] [issue6239] c_char_p return value returns
	string, not bytes
In-Reply-To: <1244477249.92.0.44777371921.issue6239@psf.upfronthosting.co.za>
Message-ID: <1244477249.92.0.44777371921.issue6239@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

If you assign a function a restype of c_char_p, you get back a Unicode
string, but you should get a bytes object.

>>> from ctypes import *
>>> strchr = cdll['libc.so.6'].strchr
>>> strchr.restype = c_char_p
>>> strchr.argtypes = [c_char_p, c_char]
>>> strchr(b'abcde', b'd')
'de'

----------
assignee: theller
components: ctypes
messages: 89086
nosy: georg.brandl, theller
priority: critical
severity: normal
stage: needs patch
status: open
title: c_char_p return value returns string, not bytes
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Jun  8 21:01:44 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 08 Jun 2009 19:01:44 +0000
Subject: [New-bugs-announce] [issue6240] API to get source encoding as
	defined by PEP 263
In-Reply-To: <1244487704.55.0.771864398626.issue6240@psf.upfronthosting.co.za>
Message-ID: <1244487704.55.0.771864398626.issue6240@psf.upfronthosting.co.za>


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

It'd be nice to get the encoding used by a specific Python file.
Considering that 'print' uses sys.stdout.encoding which is always set to
None when the Python process is run by subprocess, knowing the source
encoding is absolutely necessary in decoding the output generated by
that script.

eg: Run 'python setup.py --author' in the python-wifi-0.3.1 source
package as a subprocess.Popen(...) call.. and print the stdout.read()
string; you'll get encoding error.. unless you do
stdout.read().decode('latin1') .. where latin1 is specified as a coding:
line in setup.py.

The following function tries to detect the coding, but this guess work
not necessary when this is integrated with the standard library whose
implementation maps directly to that of PEP 263.

+def get_python_source_encoding(python_file):
+    """Detect the encoding used in the file ``python_file``
 
+    Detection is done as per http://www.python.org/dev/peps/pep-0263/
+    """
+    first_two_lines = open(python_file).readlines()[:2]
+    coding_line_regexp = ".*coding[:=]\s*([-\w.]+).*"
+
+    for line in first_two_lines:
+        m = re.match(coding_line_regexp, line)
+        if m:
+            return m.group(1)
+
+    # if no encoding is defined, use the default encoding
+    return 'ascii'

ref:
subprocess encoding mess: http://bugs.python.org/issue6135

----------
components: Interpreter Core, Library (Lib)
messages: 89097
nosy: lemburg, loewis, srid
severity: normal
status: open
title: API to get source encoding as defined by PEP 263
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Jun  8 21:47:02 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 08 Jun 2009 19:47:02 +0000
Subject: [New-bugs-announce] [issue6241] Better type checking for the
	arguments of io.StringIO
In-Reply-To: <1244490422.03.0.396715163252.issue6241@psf.upfronthosting.co.za>
Message-ID: <1244490422.03.0.396715163252.issue6241@psf.upfronthosting.co.za>


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

The included patch makes type checking of the arguments of StringIO
consistent between pyio and io.

>>> import io
>>> io.StringIO(b"hello")
Traceback (most recent call last):
  ...
ValueError: initial_value must be str or None, not bytes
>>> io.StringIO(newline=b"\n")
<_io.StringIO object at 0x7f93d52953d0>
>>> import _pyio as pyio
>>> pyio.StringIO(newline=b"\n")
Traceback (most recent call last):
  ...
TypeError: illegal newline type: <class 'bytes'>

>>> io.StringIO([])
Traceback (most recent call last):
  ...
ValueError: initial_value must be str or None, not list
>>> pyio.StringIO([])
<_pyio.StringIO object at 0x7f93d4942610>

----------
components: IO, Library (Lib)
files: typecheck_init_stringio.diff
keywords: patch
messages: 89104
nosy: alexandre.vassalotti
priority: normal
severity: normal
stage: patch review
status: open
title: Better type checking for the arguments of io.StringIO
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14231/typecheck_init_stringio.diff

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

From report at bugs.python.org  Mon Jun  8 21:51:36 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 08 Jun 2009 19:51:36 +0000
Subject: [New-bugs-announce] [issue6242] Fix reference leak in io.StringIO
In-Reply-To: <1244490696.88.0.117703122021.issue6242@psf.upfronthosting.co.za>
Message-ID: <1244490696.88.0.117703122021.issue6242@psf.upfronthosting.co.za>


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

io.StringIO does not clear its reference to its attributes dictionary
when deleted. This causes a leak when io.StringIO has attributes. 

>>> def leak():
...    for _ in range(100):
...      f = io.StringIO()
...      f.foo = 1
... 
[39348 refs]
>>> leak()
[39650 refs]
>>> leak()
[39950 refs]
>>> leak()
[40250 refs]

----------
components: IO, Library (Lib)
files: fix_refleak_stringio.diff
keywords: patch
messages: 89105
nosy: alexandre.vassalotti
priority: normal
severity: normal
stage: patch review
status: open
title: Fix reference leak in io.StringIO
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14232/fix_refleak_stringio.diff

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

From report at bugs.python.org  Mon Jun  8 22:36:14 2009
From: report at bugs.python.org (Trundle)
Date: Mon, 08 Jun 2009 20:36:14 +0000
Subject: [New-bugs-announce] [issue6243] getkey() can segfault in
	combination with curses.ungetch()
In-Reply-To: <1244493374.77.0.425204214179.issue6243@psf.upfronthosting.co.za>
Message-ID: <1244493374.77.0.425204214179.issue6243@psf.upfronthosting.co.za>


New submission from Trundle <andy-python at hammerhartes.de>:

Snippet to reproduce:

import curses

scr = curses.initscr()
curses.ungetch(1025)
scr.getkey()

This is because `keyname()` in `PyCursesWindow_GetKey()` returns NULL
which is passed to `PyString_FromString()` then.

The attached patch fixes the segfault.

----------
components: Library (Lib)
files: python_curses_ungetch_getkey.patch
keywords: patch
messages: 89111
nosy: Trundle
severity: normal
status: open
title: getkey() can segfault in combination with curses.ungetch()
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file14234/python_curses_ungetch_getkey.patch

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

From report at bugs.python.org  Mon Jun  8 23:35:03 2009
From: report at bugs.python.org (Michael Scherer)
Date: Mon, 08 Jun 2009 21:35:03 +0000
Subject: [New-bugs-announce] [issue6244] Support for tcl 8.6
In-Reply-To: <1244496903.79.0.308106230348.issue6244@psf.upfronthosting.co.za>
Message-ID: <1244496903.79.0.308106230348.issue6244@psf.upfronthosting.co.za>


New submission from Michael Scherer <misc at mandriva.org>:

It seems that python do not compile with tcl 8.6. Here is a patch, done
by Adam Williamson, to add this version in the supported list. We are
using on mandriva since 6 months without trouble, so I think this is
safe to include. The patch is against version 2.6.3, but I can rediff if
needed.

----------
components: Installation
files: python-2.5-tcl86.patch
keywords: patch
messages: 89117
nosy: misc
severity: normal
status: open
title: Support for tcl 8.6
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file14236/python-2.5-tcl86.patch

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

From report at bugs.python.org  Mon Jun  8 23:35:39 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 08 Jun 2009 21:35:39 +0000
Subject: [New-bugs-announce] [issue6245] Add "intel" universal architecture
	on OSX
In-Reply-To: <1244496939.41.0.183119086713.issue6245@psf.upfronthosting.co.za>
Message-ID: <1244496939.41.0.183119086713.issue6245@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

Apple just announced that MacOSX 10.6 ("Snow Leopard") will be released 
in September, and will only support intel systems.

This means that the --with-universal-archs option is not 100% usable if 
you want to build a version of Python that specifically targets this 
release of the OS.

The attached patch adds the option '--with-universal-archs=intel', which 
will build a 32-bit/64-bit framework for intel systemsn (that is i386 
and x86_64). 

Note: the patch is for the trunk, I'll port it to 3.x after review.

----------
assignee: ronaldoussoren
components: Build, Macintosh
files: arch-intel.patch
keywords: needs review, patch
messages: 89118
nosy: ronaldoussoren
severity: normal
status: open
title: Add "intel" universal architecture on OSX
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14237/arch-intel.patch

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

From report at bugs.python.org  Tue Jun  9 01:06:41 2009
From: report at bugs.python.org (Andreas Kloeckner)
Date: Mon, 08 Jun 2009 23:06:41 +0000
Subject: [New-bugs-announce] [issue6246] Python bebugger ignores exception
	if instructed to return	from generator
In-Reply-To: <1244502401.73.0.647401575179.issue6246@psf.upfronthosting.co.za>
Message-ID: <1244502401.73.0.647401575179.issue6246@psf.upfronthosting.co.za>


New submission from Andreas Kloeckner <inform at tiker.net>:

I get this debugger session with the attached file. Note that even
though a NameError occurs, no indication of that error is visible on the
debugger conosle.
8< -----------------------------------------------------------------
$ python -m pdb pdb_bug.py
> /home/andreas/tmp/pdb_bug.py(1)<module>()
-> def f():
(Pdb) n
> /home/andreas/tmp/pdb_bug.py(6)<module>()
-> list(f())
(Pdb) s
--Call--
> /home/andreas/tmp/pdb_bug.py(1)f()
-> def f():
(Pdb) n
> /home/andreas/tmp/pdb_bug.py(2)f()
-> print "BLAH"
(Pdb) r
BLAH
--Return--
> /home/andreas/tmp/pdb_bug.py(3)f()->None
-> bogus
(Pdb)

----------
components: Library (Lib)
files: pdb_bug.py
messages: 89123
nosy: inducer
severity: normal
status: open
title: Python bebugger ignores exception if instructed to return from generator
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file14239/pdb_bug.py

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

From report at bugs.python.org  Tue Jun  9 08:40:28 2009
From: report at bugs.python.org (Ritesh Raj Sarraf)
Date: Tue, 09 Jun 2009 06:40:28 +0000
Subject: [New-bugs-announce] [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>


New submission from Ritesh Raj Sarraf <rrs at researchut.com>:

Shoudl argparse be included in the Python Standard Library.

I know we already have getopt and optparse but optparse doesn't
support many features easily. (like options without hyphen, nargs=*)

Here a little about argparse:


argparse: Python command line parser
The argparse module makes writing command line tools in Python easy.
Just briefly describe your command line interface and argparse will take
care of the rest, including: 
parsing the arguments and flags from sys.argv 
converting arg strings into objects for your program 
formatting and printing any help messages 
and much more ... 
For those familiar with the optparse module from the Python standard
library, argparse improves on this module in a number of ways, including: 
handling positional arguments 
supporting sub-commands 
allowing alternative option prefixes like + and / 
handling zero-or-more and one-or-more style arguments 
producing more informative usage messages 
providing a much simpler interface for custom types and actions

----------
components: Extension Modules
messages: 89134
nosy: rickysarraf
severity: normal
status: open
title: should we include argparse
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Tue Jun  9 18:55:38 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 09 Jun 2009 16:55:38 +0000
Subject: [New-bugs-announce] [issue6248] TCP Sockets not closed by TCPServer
	and	StreamRequestHandler
In-Reply-To: <1244566538.72.0.477638958657.issue6248@psf.upfronthosting.co.za>
Message-ID: <1244566538.72.0.477638958657.issue6248@psf.upfronthosting.co.za>


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

When an error occurs in a StreamRequestHandler, its wfile and rfile 
members are not closed.  This causes the underlaying socket to stay 
alive and and it is therefore not closed, even when the SocketServer 
closes it in server.close_request().  This means that a client will not 
know that there is no one listening on the other end.

This is due to incorrect error handling semantics in BaseRequestHandler.

This patch fixes the error handling in BaseRequestHandler, ensuring that 
request.finish() is called when request.setup() has completed.

I also add an explicit socket.shutdown() in TCPServer.close_request() to 
make sure that at least a half-close occurs even in the face of socket 
reference leaks.

----------
components: Library (Lib)
files: socketserver.patch
keywords: needs review, patch, patch
messages: 89152
nosy: krisvale
severity: normal
status: open
title: TCP Sockets not closed by TCPServer and StreamRequestHandler
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file14245/socketserver.patch

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

From report at bugs.python.org  Wed Jun 10 02:31:59 2009
From: report at bugs.python.org (SonMarvin)
Date: Wed, 10 Jun 2009 00:31:59 +0000
Subject: [New-bugs-announce] [issue6249] Error Prompt
In-Reply-To: <1244593919.18.0.459180854095.issue6249@psf.upfronthosting.co.za>
Message-ID: <1244593919.18.0.459180854095.issue6249@psf.upfronthosting.co.za>


New submission from SonMarvin <marvinsd at gmail.com>:

When I open a Python File Prompt closes it quickly.My friends do not
have this problem. Now reinstall, download older versions and the
problem continued.

----------
components: Windows
messages: 89177
nosy: SonMarvin
severity: normal
status: open
title: Error Prompt
versions: Python 3.2

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

From report at bugs.python.org  Wed Jun 10 05:59:45 2009
From: report at bugs.python.org (James Abbatiello)
Date: Wed, 10 Jun 2009 03:59:45 +0000
Subject: [New-bugs-announce] [issue6250] Python compiles dead code
In-Reply-To: <1244606385.56.0.541524324574.issue6250@psf.upfronthosting.co.za>
Message-ID: <1244606385.56.0.541524324574.issue6250@psf.upfronthosting.co.za>


New submission from James Abbatiello <abbeyj at gmail.com>:

Python currently emits bytecode for code that is unreachable (e.g.
following a return statement).  This doesn't hurt anything but it takes
up space doing nothing.

This patch attempts to avoid generating any bytecode in this situation.
 There's an optional warning, enabled with the -r command line switch,
which notifies you if any unreachable code is found.  Running
regrtest.py with this switch produces a bit of noise but also revealed
issue6227 which looks like a real bug.

----------
components: Interpreter Core
files: deadcode.patch
keywords: patch
messages: 89183
nosy: abbeyj, collinwinter, jyasskin, pitrou
severity: normal
status: open
title: Python compiles dead code
versions: Python 2.7
Added file: http://bugs.python.org/file14252/deadcode.patch

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

From report at bugs.python.org  Wed Jun 10 10:19:14 2009
From: report at bugs.python.org (John O'Driscoll)
Date: Wed, 10 Jun 2009 08:19:14 +0000
Subject: [New-bugs-announce] [issue6251] c++ extension module implementation
	guide/example in	extending/embedding documentation
In-Reply-To: <1244621954.14.0.882115358869.issue6251@psf.upfronthosting.co.za>
Message-ID: <1244621954.14.0.882115358869.issue6251@psf.upfronthosting.co.za>


New submission from John O'Driscoll <biggerbumme at yahoo.co.in>:

feature: extension module C++ howto/example in extending-embedding/c-api
documentation


why:	The embedding/extension documentation states that module
implementation in c++ is possible, without providing any guidance beyond
this. Coders more familiar/comfortable with c++ than c, writing c++ code
to expose in python, might want to create the actual python class/module
implementations in c++ classes or structs. A basic guide can help
prevent wastage of energy reinventing the wheel, and also serve as a
guide to safe/preferred style. The method outlined here can be a
starting point in finding out what that style is. 
Also it seems, to my eyes at least, a little easier to 'visualise' and
apply than the equivalent in plain C (the Noddy module etc), a bit more
'systematic', and easier to understand the relation between c and python
objects. So after some trial and error, discovering the pitfalls, I am
finding it easy to create useful python classes with this recipe. Others
might also find it useful, even if only as a stimulus to find a Better Way.

Python is an object-oriented language noted for its clarity, so an
allegedly simple and clear OO implementation strategy for module classes
should be examined.


what:	I've written a module currently called 'cpeepee', containing a
basic python class ,(struct TestRealDestructor in C++,
'cpeepee.destructo' in python). It has been tested with python-2.5 and
g++-4.2 on ubuntu-'hardy heron' and python-2.5/g++-3.4 on FreeBSD-6.4. 

The c++ struct inherits from PyObject.(You could also inherit from
PyVarObject or other more specialised types). The most important
non-feature of this class is that it is not virtual, has no virtual
destructor or functions(in member objects virtual destructors and the
rest are OK however). Therefore the packing of ob_refcnt and friends is
correct, and casting to/from PyObject is safe(-and otherwise is not -
the PyObject* cast from such a type with virtual destructor is offset by
the size of a pointer -the vptr?-, but when python casts back to the
type - from void* or so?- the offset is not removed, leading to mayhem).

[You could also not inherit, simply put the PyObject_HEAD macro as the
first entry in the struct - could be a class also, as long as the
PyObject members(ob_refcnt, ob_type ... )were public - You would have to
write a new macro to fill in those members in the constructor's
initialiser list, but that doesn't look too hard. As it is the inherited
classes use a function and some macros (almost identical to
PyObject_HEAD_INIT(typo) ) to fill in the PyObject parent. Again, vfuncs
are out]

	The destructo method and member tables are static members of
TestRealDestructor, as is its type object.(Other optional tables etc
should also be static members if provided - makes for a simple
consistent setup)
	The objects constructor is called from
TestRealDestructor::type.tp_new() and passed the args and kwds arguments
it is passed, using placement new with memory obtained from
tp_alloc()(see TestRealDestructor::create() ). Being able to properly
call an object's constructor was the real motivation for writing the
code this derives from. Using C style one is stuck casting a char* to
your type and then filling its fields by hook or crook.
 
On error, either you could throw a c++ exception in constructor to catch
in tp_new, and convert to a python exception, or simply throw the python
exception in the constructor, and then check if PyErr_Occurred() in
tp_new() - the approach with destructo.

Since tp_new and the constructor take care of object creation, this
leaves tp_init not doing much at all. It could be used for extra checks,
or printing funky messages about preserved ham

Functions to be exposed in python API as class member functions should
static members of the class, and to do the work they call ordinary
member functions of the class object passed into the static function .
You could use global static functions(with the first arg
TestRealDestructor* say, rather than PyObject*), but that's less clear,
less systematic, less OO.

Everything can be placed in a namespace to avoid any pollution of global
namespace.

I've worked out the bugs that were obvious to me, so it should compile
and run as is, without error messages. The one compile warning I don't
know how to banish comes from the offsetof macro when setting member
offsets in the member table(as copied from the c example) - however the
object whose offset is so established works fine from python, so I think
it's a spurious warning. 

If you find any issues with my approach, I'm happy to work through them,
or if you know what to do then make whatever changes you think required.

I'm happy to put any code or words I contribute on this topic to go
under python's copyright as long as I'm credited somehow(however you
normally do that). Whatever, I'm happy to contribute to such a great
project as python

sincerely

John O'Driscoll

----------
assignee: georg.brandl
components: Documentation
files: CXXdemo-0.1.tar.gz
messages: 89190
nosy: georg.brandl, subgeometer
severity: normal
status: open
title: c++ extension module implementation guide/example in extending/embedding documentation
type: resource usage
versions: Python 2.5
Added file: http://bugs.python.org/file14253/CXXdemo-0.1.tar.gz

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

From report at bugs.python.org  Wed Jun 10 10:30:55 2009
From: report at bugs.python.org (Turnaev Evgeny)
Date: Wed, 10 Jun 2009 08:30:55 +0000
Subject: [New-bugs-announce] [issue6252] logging midnigh rotation
In-Reply-To: <1244622655.82.0.22543923389.issue6252@psf.upfronthosting.co.za>
Message-ID: <1244622655.82.0.22543923389.issue6252@psf.upfronthosting.co.za>


New submission from Turnaev Evgeny <xiled at yandex.ru>:

i have a very basic setup of logging in a long running daemon app..
I use TimedRotatingFileHandler with rotating at midnight.
The bug:
The last open logging file was for 2009-05-25..
app was running without logging anything for about a week or more.
After a week past something happened and daemon started to log messages,
but.. for each new message logging system creates new file.
In other words.. suppose we was idle since 2009-05-25, now it is 
2009-06-10 and we want to log 10 messages.. 
current opened file is for 2009-05-25.. so when a first messages
arrives into logging system current must be closed. and a new file must 
be opened where all 10 messages should be..
but instead logging system will log each subsequent message in files 
2009-05-26, 2009-05-27, 2009-05-28..(in fact it will log in file 
without a date and then when nect message arives rename current to 
2009-05-26, 2009-05-27, 2009-05-28.. but is still the same) and so on, 
one message per file.. i think until it reaches current date.
It is a logic error.


my logging setup looks like this:
---------
import logging
from logging import debug,warning,info,error,critical
from logging.handlers import TimedRotatingFileHandler

log_path = '/var/log/cherry/smsd_reg'
log_level = logging.DEBUG

basic_log_handler = TimedRotatingFileHandler(log_path + "/
app_log_smsd_reg_server",'midnight',1)
basic_log_handler.setLevel(log_level)
basic_log_formatter = logging.Formatter('%(asctime)s pid: %(process)d, 
%(levelname)s %(message)s')
basic_log_handler.setFormatter(basic_log_formatter)
logging.getLogger('').addHandler(basic_log_handler)
logging.getLogger('').setLevel(log_level)

----------------

system info:
Python 2.5.1
FreeBSD 6.2-RELEASE-p7 FreeBSD 6.2-RELEASE-p7

----------
components: Extension Modules
messages: 89191
nosy: SanityIO
severity: normal
status: open
title: logging midnigh rotation
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Wed Jun 10 16:28:17 2009
From: report at bugs.python.org (Jan Pobrislo)
Date: Wed, 10 Jun 2009 14:28:17 +0000
Subject: [New-bugs-announce] [issue6253] optparse.OptionParser.get_usage
	uses wrong formatter
In-Reply-To: <1244644097.18.0.346116774289.issue6253@psf.upfronthosting.co.za>
Message-ID: <1244644097.18.0.346116774289.issue6253@psf.upfronthosting.co.za>


New submission from Jan Pobrislo <ccx at volny.cz>:

When using OptionParser.format_help(formatter), the formatter parameter
should be used to format all of the help message. This is not the case
for usage message, as the method get_usage() is not passed the formatter
and always uses self.formatter. I'm using python-2.6.2-r1.

----------
components: Extension Modules
files: fix_optparse_usage_formatter.diff
keywords: patch
messages: 89202
nosy: ccx
severity: normal
status: open
title: optparse.OptionParser.get_usage uses wrong formatter
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14254/fix_optparse_usage_formatter.diff

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

From report at bugs.python.org  Wed Jun 10 17:46:52 2009
From: report at bugs.python.org (Michael K Johnson)
Date: Wed, 10 Jun 2009 15:46:52 +0000
Subject: [New-bugs-announce] [issue6254] tarfile unnecessarily requires
	seekable files
In-Reply-To: <1244648812.36.0.982521816376.issue6254@psf.upfronthosting.co.za>
Message-ID: <1244648812.36.0.982521816376.issue6254@psf.upfronthosting.co.za>


New submission from Michael K Johnson <a1237+pybugs at danlj.org>:

In python 2.6 (not 2.4, haven't checked 2.5), the __init__() method of
the TarFile class calls the tell() method on the tar file, which doesn't
work if you are reading from standard input or writing to standard
output, two very reasonable things to do with a tar file.

While there are cases where it is logical to seek within a tar file,
supporting those cases should not preclude the normal design case for
tar archives of streaming reads/writes, including tar files being
streamed between processes via pipes.  If the tell() method is not
implemented for the file object, then the seek() method of TarFile (and
any other methods that can be implemented only for seekable files) can
raise a reasonable exception.  Note that this also means that the next()
method should not need to seek() for non-seekable files; it should
assume that it is at the correct block and read from there.

----------
components: Library (Lib)
messages: 89206
nosy: johnsonm
severity: normal
status: open
title: tarfile unnecessarily requires seekable files
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Jun 10 18:07:01 2009
From: report at bugs.python.org (Naoki INADA)
Date: Wed, 10 Jun 2009 16:07:01 +0000
Subject: [New-bugs-announce] [issue6255] PyInt_FromSize_t is undocumented.
In-Reply-To: <1244650021.11.0.405068030111.issue6255@psf.upfronthosting.co.za>
Message-ID: <1244650021.11.0.405068030111.issue6255@psf.upfronthosting.co.za>


New submission from Naoki INADA <songofacandy at gmail.com>:

PyInt_FromSize_t() is not in Python/C API document.
People seeing document may be not able to find how to make int from 
unsigned long.

----------
assignee: georg.brandl
components: Documentation
messages: 89208
nosy: georg.brandl, naoki
severity: normal
status: open
title: PyInt_FromSize_t is undocumented.
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Jun 10 18:08:12 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Wed, 10 Jun 2009 16:08:12 +0000
Subject: [New-bugs-announce] [issue6256] Wrong stacklevel in warning for
	contextlib.nested
In-Reply-To: <1244650092.01.0.50718314097.issue6256@psf.upfronthosting.co.za>
Message-ID: <1244650092.01.0.50718314097.issue6256@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

This leads to unhelpful warnings:

>>> with contextlib.nested(open("x", "w")) as f: pass
... 
/usr/local/lib/python3.1/contextlib.py:17: DeprecationWarning:
With-statements now directly support multiple context managers
  return next(self.gen)

Patch is attached.

----------
components: Library (Lib)
files: warning_stacklevel.patch
keywords: patch
messages: 89209
nosy: hagen
severity: normal
status: open
title: Wrong stacklevel in warning for contextlib.nested
type: behavior
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14259/warning_stacklevel.patch

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

From report at bugs.python.org  Wed Jun 10 18:47:22 2009
From: report at bugs.python.org (Andy Harrington)
Date: Wed, 10 Jun 2009 16:47:22 +0000
Subject: [New-bugs-announce] [issue6257] Idle terminates on source save
	while debugging
In-Reply-To: <1244652442.36.0.452724625348.issue6257@psf.upfronthosting.co.za>
Message-ID: <1244652442.36.0.452724625348.issue6257@psf.upfronthosting.co.za>


New submission from Andy Harrington <aharrin at luc.edu>:

When I am running the idle debugger, and change something in a source
file and save it, the save works but idle immediately closes. 

I can see the debugger not liking it, but it would be much better if
just the debugger stopped, not the whole idle environment.

I'm running XP professional, Python 3.0.1

----------
messages: 89217
nosy: andyharrington
severity: normal
status: open
title: Idle terminates on source save while debugging
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Wed Jun 10 20:10:45 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 10 Jun 2009 18:10:45 +0000
Subject: [New-bugs-announce] [issue6258] distributions built with bdist_msi
	on 64-bit Windows fail	to install correctly
In-Reply-To: <1244657445.76.0.468429726834.issue6258@psf.upfronthosting.co.za>
Message-ID: <1244657445.76.0.468429726834.issue6258@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

It appears as if bdist_msi isn't properly tagging 64-bit binary builds.

When launching an .msi built by Python 2.6.2 using bdist_msi, such as
numpy found here
(https://sourceforge.net/project/showfiles.php?group_id=1369&package_id=175103),
it improperly detects the location of Python (which it gets from the
registry).  If the 32-bit Python 2.6 is also installed, it finds that
version.  If 32-bit Python 2.6 is not installed, it fails to find the
Python installation.  Even if the proper 64-bit Python 2.6 location is
selected, the files are not installed to the Python 2.6 site-packages. 
Furthermore, the registry Uninstall information is stored in the
Wow6432Node.

bdist_wininst executables appear to detect 64-bit Python and install
correctly.

I will attempt to recreate this problem with a minimal project and clean
64-bit Vista or Windows 7 machine at a later date.

----------
assignee: tarek
components: Distutils
messages: 89221
nosy: jaraco, tarek
severity: normal
status: open
title: distributions built with bdist_msi on 64-bit Windows fail to install correctly
versions: Python 2.6

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

From report at bugs.python.org  Wed Jun 10 21:38:00 2009
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 10 Jun 2009 19:38:00 +0000
Subject: [New-bugs-announce] [issue6259] ctypes pointer arithmetic
In-Reply-To: <1244662680.17.0.41540856406.issue6259@psf.upfronthosting.co.za>
Message-ID: <1244662680.17.0.41540856406.issue6259@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

This patch implements some pointer arithmetic operations for ctypes.

----------
files: ctypes-pointerarith.patch
keywords: patch
messages: 89225
nosy: theller
severity: normal
status: open
title: ctypes pointer arithmetic
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file14262/ctypes-pointerarith.patch

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

From report at bugs.python.org  Wed Jun 10 22:06:32 2009
From: report at bugs.python.org (James)
Date: Wed, 10 Jun 2009 20:06:32 +0000
Subject: [New-bugs-announce] [issue6260] os.utime should allow None values
	for ATIME or MTIME
In-Reply-To: <1244664392.83.0.0874142819498.issue6260@psf.upfronthosting.co.za>
Message-ID: <1244664392.83.0.0874142819498.issue6260@psf.upfronthosting.co.za>


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

Hi, in using os.utime, it's nice that you can specify `None' for the
second argument. However it would be even `nicer' to be able to specify
None for either (or potentially both) values for the argument in the
tuple. to emulate this, i've been using os.stat to read the value
beforehand, and just use os.utime with the new value, and the old one
pulled from stat()

HTH, _J

example:
os.utime('/dev/pts/1', None) WORKS
os.utime('/dev/pts/1') SHOULD WORK (allow second argument to default to
None)
os.utime('/dev/pts/1', (time.time(), None)) SHOULD WORK
os.utime('/dev/pts/1', (None, None)) SHOULD WORK
os.utime('/dev/pts/1', (None, time.time())) I GUESS SHOULD WORK

ps: if this is a feature you'd agree with, let me know any maybe i can
*try* to write a patch?

----------
components: IO
messages: 89227
nosy: purpleidea
severity: normal
status: open
title: os.utime should allow None values for ATIME or MTIME
type: feature request
versions: Python 2.5

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

From report at bugs.python.org  Wed Jun 10 23:30:28 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 10 Jun 2009 21:30:28 +0000
Subject: [New-bugs-announce] [issue6261] Clarify behaviour of random.uniform
In-Reply-To: <1244669428.58.0.991347750307.issue6261@psf.upfronthosting.co.za>
Message-ID: <1244669428.58.0.991347750307.issue6261@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The documentation for random.uniform() was recently updated to reflect 
the fact that it's possible for random.uniform(a, b) to produce the 
value b;  see issue 4979.

In a recent c.l.p. thread, Robert Kern suggested that 'it 
might be confusing to a user why random.random() returns values in a 
half-open interval while random.uniform() claims a closed interval';  
the thread itself confirms this potential for confusion.  See

http://mail.python.org/pipermail/python-list/2009-June/715851.html

Suggested extra wording for random.uniform, from Robert Kern:

"Due to floating point arithmetic, for some values of a and b, b may or 
may not be one of the possible generated results."

----------
assignee: georg.brandl
components: Documentation
messages: 89232
nosy: georg.brandl, marketdickinson
severity: normal
status: open
title: Clarify behaviour of random.uniform
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/issue6261>
_______________________________________

From report at bugs.python.org  Thu Jun 11 09:06:16 2009
From: report at bugs.python.org (Bellenot)
Date: Thu, 11 Jun 2009 07:06:16 +0000
Subject: [New-bugs-announce] [issue6262] VS 2008 binaries
In-Reply-To: <1244703976.71.0.511260473865.issue6262@psf.upfronthosting.co.za>
Message-ID: <1244703976.71.0.511260473865.issue6262@psf.upfronthosting.co.za>


New submission from Bellenot <bertrand.bellenot at cern.ch>:

Hi,

Would it be possible to obtain MSVC++2008(9.0) binaries of Python 2.5.4?
We are actually stuck to this version and have problem with MSVC 
runtime libraries incompatibility. I can build Python.exe from source, 
but there are a lot of missing modules (external dependencies). Then, 
as you already build full binaries with MSVC++7.1, I was wondering if 
it would be possible for you to build MSVC++9.0(2008) binaries...
Thanks in advance.

Cheers, Bertrand.

----------
components: Windows
messages: 89238
nosy: bellenot
severity: normal
status: open
title: VS 2008 binaries
type: feature request
versions: Python 2.5

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

From report at bugs.python.org  Thu Jun 11 11:11:11 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 11 Jun 2009 09:11:11 +0000
Subject: [New-bugs-announce] [issue6263] syntax error in get_msvcr
In-Reply-To: <1244711471.55.0.267324152593.issue6263@psf.upfronthosting.co.za>
Message-ID: <1244711471.55.0.267324152593.issue6263@psf.upfronthosting.co.za>


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

get_msvcr uses an unknown msc_Ver variable (should be msc_ver),
and wrong string formatting.

----------
assignee: tarek
components: Distutils
messages: 89242
nosy: tarek
severity: normal
status: open
title: syntax error in get_msvcr
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu Jun 11 11:58:23 2009
From: report at bugs.python.org (Black Dew)
Date: Thu, 11 Jun 2009 09:58:23 +0000
Subject: [New-bugs-announce] [issue6264] Misleading instructions for
	installing extensions with	mingw
In-Reply-To: <1244714303.63.0.906015224552.issue6264@psf.upfronthosting.co.za>
Message-ID: <1244714303.63.0.906015224552.issue6264@psf.upfronthosting.co.za>


New submission from Black Dew <blackdew at gmail.com>:

This page http://docs.python.org/install/index.html#gnu-c-cygwin-mingw 
says: 

"These instructions only apply if you?re using a version of Python 
prior to 2.4.1 with a MinGW prior to 3.0.0 (with binutils-2.13.90-
20030111-1)" 

But it seems that it is still needed for Python 2.6 with MinGW 3.15.2.

Without manually generating libpython26.a I can't compile any python 
extension, geting a bunch of undefined references, for example:

c:\mingw\bin\gcc.exe -mno-cygwin -shared -s build\temp.win32-2.6
\Release\zfec\fec.o build\temp.win32-2.6\Release\zfec\_fecmodule.o 
build\temp.win32-2.6\Release\zfec\_fec.def -LC:\Python26\libs -
LC:\Python26\PCbuild -lpython26 -lmsvcr90 -o build\lib.win32-2.6
\zfec\_fec.pyd
build\temp.win32-2.6\Release\zfec\_fecmodule.o:_fecmodule.c:
(.text+0xefa): undefined reference to `_imp___Py_TrueStruct'
build\temp.win32-2.6\Release\zfec\_fecmodule.o:_fecmodule.c:
(.text+0xf01): undefined reference to `_imp___Py_TrueStruct'
build\temp.win32-2.6\Release\zfec\_fecmodule.o:_fecmodule.c:
(.text+0xf08): undefined reference to `_imp___Py_ZeroStruct'
build\temp.win32-2.6\Release\zfec\_fecmodule.o:_fecmodule.c:
(.text+0xf0f): undefined reference to `_imp___Py_ZeroStruct'
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1

If I do generate libpython26.a - everythong works fine.

----------
assignee: georg.brandl
components: Documentation, Extension Modules
messages: 89244
nosy: bdew, georg.brandl
severity: normal
status: open
title: Misleading instructions for installing extensions with mingw
versions: 3rd party, Python 2.6

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

From report at bugs.python.org  Thu Jun 11 12:46:47 2009
From: report at bugs.python.org (Neil Muller)
Date: Thu, 11 Jun 2009 10:46:47 +0000
Subject: [New-bugs-announce] [issue6265] cElementTree & ElementTree use
	different exceptions for	XML Errors
In-Reply-To: <1244717207.44.0.0661498908043.issue6265@psf.upfronthosting.co.za>
Message-ID: <1244717207.44.0.0661498908043.issue6265@psf.upfronthosting.co.za>


New submission from Neil Muller <drnlmuller+bugs at gmail.com>:

cElementTree will raise a SyntaxError on XML parsing errors, while
ElementTree will raise ExpatError.  This makes changing between the two
a bit more problematic than it could be. See for example
https://lists.canonical.com/archives/bazaar/2006q3/017491.html

ElementTree 1.3 raises a ParseError, which is subclassed from
SyntaxError, which will improve the situation when it's merged, but
cElementTree should be adjusted to raise the same error.

----------
messages: 89247
nosy: Neil Muller, effbot, jerith
severity: normal
status: open
title: cElementTree & ElementTree use different exceptions for XML Errors
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Jun 11 12:53:52 2009
From: report at bugs.python.org (Neil Muller)
Date: Thu, 11 Jun 2009 10:53:52 +0000
Subject: [New-bugs-announce] [issue6266] cElementTree.iterparse &
	ElementTree.iterparse return	differently encoded strings
In-Reply-To: <1244717632.74.0.358309884859.issue6266@psf.upfronthosting.co.za>
Message-ID: <1244717632.74.0.358309884859.issue6266@psf.upfronthosting.co.za>


New submission from Neil Muller <drnlmuller+bugs at gmail.com>:

Consider:

>>> from StringIO import StringIO
>>> source = StringIO('<body xmlns="http://&#233;ffbot.org/ns">text</body>')
>>> import xml.etree.ElementTree as ET
>>> events = ("start-ns",)
>>> context = ET.iterparse(source, events)
>>> for action, elem in context:
...    print action, elem
... 
start-ns ('', u'http://\xe9ffbot.org/ns')
>>> source.seek(0)
>>> import xml.etree.cElementTree as cET
>>> context = cET.iterparse(source, events)
>>> for action, elem in context:
...    print action, elem
... 
start-ns ('', 'http://\xc3\xa9ffbot.org/ns')

I'm not sure which is more correct here, but unsing different encodings
in the result is somewhat unexpected.

----------
messages: 89248
nosy: Neil Muller, effbot, jerith
severity: normal
status: open
title: cElementTree.iterparse & ElementTree.iterparse return differently encoded strings
versions: Python 2.7

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

From report at bugs.python.org  Thu Jun 11 17:30:35 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 11 Jun 2009 15:30:35 +0000
Subject: [New-bugs-announce] [issue6267] Cumulative patch to http and xmlrpc
In-Reply-To: <1244734235.6.0.17264314682.issue6267@psf.upfronthosting.co.za>
Message-ID: <1244734235.6.0.17264314682.issue6267@psf.upfronthosting.co.za>


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

Please see 
http://codereview.appspot.com/73041/show

----------
messages: 89254
nosy: krisvale
severity: normal
status: open
title: Cumulative patch to http and xmlrpc
type: performance
versions: Python 2.7

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

From report at bugs.python.org  Thu Jun 11 20:26:43 2009
From: report at bugs.python.org (Mark Florisson)
Date: Thu, 11 Jun 2009 18:26:43 +0000
Subject: [New-bugs-announce] [issue6268] Seeking to the beginning of a text
	file a second time	will return the BOM as first character
In-Reply-To: <1244744803.37.0.794266933913.issue6268@psf.upfronthosting.co.za>
Message-ID: <1244744803.37.0.794266933913.issue6268@psf.upfronthosting.co.za>


New submission from Mark Florisson <markflorisson88 at gmail.com>:

>>> f = open('foo', 'wt+', encoding='UTF-16')
>>> f.write('spam ham eggs')
13
>>> f.seek(0)
0
>>> f.read()
'spam ham eggs'
>>> f.seek(0)
0
>>> f.read()
'\ufeffspam ham eggs'

Although the BOM character is a ZERO WIDTH NO-BREAK SPACE, and should
therefore not impose many problems, the behavior is inconsistent and
unexpected.
codecs.open in 2.x suffers from this same behavior.

----------
components: Unicode
messages: 89257
nosy: eggy
severity: normal
status: open
title: Seeking to the beginning of a text file a second time will return the BOM as first 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/issue6268>
_______________________________________

From report at bugs.python.org  Thu Jun 11 22:37:16 2009
From: report at bugs.python.org (Florian Mayer)
Date: Thu, 11 Jun 2009 20:37:16 +0000
Subject: [New-bugs-announce] [issue6269] threading documentation makes no
	mention of the GIL
In-Reply-To: <1244752636.53.0.230892071938.issue6269@psf.upfronthosting.co.za>
Message-ID: <1244752636.53.0.230892071938.issue6269@psf.upfronthosting.co.za>


New submission from Florian Mayer <flormayer at aim.com>:

I think the GIL should be mentioned in the threading documentation, so
that people do not try to use them for scalability reasons.

----------
assignee: georg.brandl
components: Documentation
files: threading.rst.patch
keywords: patch
messages: 89259
nosy: georg.brandl, segfaulthunter
severity: normal
status: open
title: threading documentation makes no mention of the GIL
versions: Python 2.7
Added file: http://bugs.python.org/file14264/threading.rst.patch

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

From report at bugs.python.org  Thu Jun 11 23:09:40 2009
From: report at bugs.python.org (Greg Couch)
Date: Thu, 11 Jun 2009 21:09:40 +0000
Subject: [New-bugs-announce] [issue6270] Menu deletecommand fails if command
	is already deleted
In-Reply-To: <1244754580.13.0.801057820447.issue6270@psf.upfronthosting.co.za>
Message-ID: <1244754580.13.0.801057820447.issue6270@psf.upfronthosting.co.za>


New submission from Greg Couch <gregc at cgl.ucsf.edu>:

Sometime around Python 2.5.4, Menu.delete was changed to delete
associated entry commands (and thus plug a memory leak).  This broke
Pmw.OptionMenu because it already had similar code, so when Menu.delete
was called, the commands were already gone, and a TclError was raised
saying "can't delete Tcl command".

While Pmw could be patched to workaround this bug, it seems strange that
Tkinter.Misc.deletecommand unconditionally deletes commands it knows
nothing about.  All uses of deletecommand in Tkinter refer to commands
that were Tkinter.Misc._register'ed, so they should appear in the
widget._tclCommands list.  So the proper solution is to only delete
commands that are still registered with the widget.

Repeat by:

import Pmw
om = Pmw.OptionMenu()
om.pack()
om.setitems(['a', 'b'])
om.setitems(['b'])

----------
components: Tkinter
files: delcmd.patch
keywords: patch
messages: 89262
nosy: gregcouch
severity: normal
status: open
title: Menu deletecommand fails if command is already deleted
type: crash
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file14265/delcmd.patch

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

From report at bugs.python.org  Fri Jun 12 12:50:30 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Jun 2009 10:50:30 +0000
Subject: [New-bugs-announce] [issue6271] mmap: don't close file description
	if fd=-1
In-Reply-To: <1244803830.2.0.352029440957.issue6271@psf.upfronthosting.co.za>
Message-ID: <1244803830.2.0.352029440957.issue6271@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Hi, Valgrind just told me that Python calls close(-1) on
my_mmap_object.close() for memory mappings. That's because a memory
mapping has no (related) file descriptor.

Using attached warn.py, you can see the warning using strace:

$ strace -e close python warn.py 2>&1|grep -A1 12345
close(12345)                            = -1 EBADF (Bad file descriptor)
close(4294967295)                       = -1 EBADF (Bad file descriptor)
close(12345)                            = -1 EBADF (Bad file descriptor)

where close(4294967295) means close(-1).

Attached patch fixes this warning.

----------
components: Extension Modules
files: warn.py
messages: 89269
nosy: haypo
severity: normal
status: open
title: mmap: don't close file description if fd=-1
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14268/warn.py

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

From report at bugs.python.org  Fri Jun 12 13:13:06 2009
From: report at bugs.python.org (Senthil)
Date: Fri, 12 Jun 2009 11:13:06 +0000
Subject: [New-bugs-announce] [issue6272] Upgrading xml.etree to ElementTree
	1.3
In-Reply-To: <1244805186.91.0.178368726896.issue6272@psf.upfronthosting.co.za>
Message-ID: <1244805186.91.0.178368726896.issue6272@psf.upfronthosting.co.za>


New submission from Senthil <orsenthil at gmail.com>:

The current ElementTree package shipped with Python is ElementTree 1.2.6.
ElementTree 1.3 has certain good features in handing XPaths which would
be a nice addition to the default xml.etree.

I don't know why ElementTree 1.2.6 was chosen initially.
I don't find any request for the upgrade.

So opening this one.

----------
assignee: effbot
components: Library (Lib), XML
messages: 89270
nosy: effbot, orsenthil
priority: normal
severity: normal
status: open
title: Upgrading xml.etree to ElementTree 1.3
type: feature request
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Fri Jun 12 18:43:48 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 12 Jun 2009 16:43:48 +0000
Subject: [New-bugs-announce] [issue6273] Add client side certificate support
	to httplib
In-Reply-To: <1244825028.47.0.339555934683.issue6273@psf.upfronthosting.co.za>
Message-ID: <1244825028.47.0.339555934683.issue6273@psf.upfronthosting.co.za>


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

The attached patch adds client-side cert support to httplib, as well as 
validation. Rather than just commit this, I would like to have additional 
review.

Also, ideally this could be added to 2.6 maint (it seems like a pretty big 
hole) as well as 2.7/3.0. The patch is against 2.6 maint.

----------
files: py26httplib.patch
keywords: patch
messages: 89288
nosy: jnoller
priority: normal
severity: normal
status: open
title: Add client side certificate support to httplib
type: feature request
versions: Python 2.6, Python 2.7, Python 3.2
Added file: http://bugs.python.org/file14274/py26httplib.patch

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

From report at bugs.python.org  Fri Jun 12 22:57:48 2009
From: report at bugs.python.org (Facundo Batista)
Date: Fri, 12 Jun 2009 20:57:48 +0000
Subject: [New-bugs-announce] [issue6274] subprocess.Popen() may leak file
	descriptors
In-Reply-To: <1244840268.32.0.756034248286.issue6274@psf.upfronthosting.co.za>
Message-ID: <1244840268.32.0.756034248286.issue6274@psf.upfronthosting.co.za>


New submission from Facundo Batista <facundo at taniquetil.com.ar>:

If something bad happens between a os.pipe() call is called, and the
returned file descriptors are closed, those file descriptors are never
closed.

In a long lived process this is a problem.

Patch (against trunk) to solve this is attached.

----------
assignee: facundobatista
files: subprocess.py.diff
keywords: patch
messages: 89301
nosy: facundobatista
severity: normal
status: open
title: subprocess.Popen() may leak file descriptors
type: resource usage
versions: Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14278/subprocess.py.diff

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

From martin at v.loewis.de  Fri Jun 12 23:00:26 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 12 Jun 2009 23:00:26 +0200
Subject: [New-bugs-announce] [issue6273] Add client side certificate
 support to httplib
In-Reply-To: <1244825028.47.0.339555934683.issue6273@psf.upfronthosting.co.za>
References: <1244825028.47.0.339555934683.issue6273@psf.upfronthosting.co.za>
Message-ID: <4A32C1EA.2040504@v.loewis.de>

> The attached patch adds client-side cert support to httplib, as well as 
> validation. Rather than just commit this, I would like to have additional 
> review.

I wouldn't call the feature "client-side cert support" - client
certificates are already supported, and had been for a long time.

What you are adding to httplib is server certificate validation.

I find the patch incomplete, for formal and semantical reasons:
a) it doesn't come with documentation or test suite changes, and
b) it doesn't implement the typical certificate checks that browsers
   do, beyond validating that the certificate is valid - e.g. also
   validating that the certificate is issued to the host you are trying
   to connect to.

API-wise, I'm not sure what the point of passing cert_reqs as a
parameter is - ISTM that, in httplib, if ca_certs is not None, then
cert_reqs should automatically be CERT_REQUIRED (just like it is
in get_server_certificate).

> Also, ideally this could be added to 2.6 maint (it seems like a pretty big 
> hole) 

It's a new feature, so it shouldn't be added to 2.6. Not sure what you
mean by "big hole".

From report at bugs.python.org  Fri Jun 12 23:43:14 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 12 Jun 2009 21:43:14 +0000
Subject: [New-bugs-announce] [issue6275] let unittest.assertRaises() return
	the exception object	caught
In-Reply-To: <1244842994.31.0.225778913715.issue6275@psf.upfronthosting.co.za>
Message-ID: <1244842994.31.0.225778913715.issue6275@psf.upfronthosting.co.za>


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

It can be useful, after a unittest.assertRaises() or assertRaisesRegexp() 
to be able to take a closer look at the exception that was raised.
To this end, I propose returning the caught exception from these methods.

Additionally, the context manager involved with keep the caught exception 
in its exc_value member after it has been successfully thrown (and 
matched)

----------
components: Library (Lib)
files: unittest.patch
keywords: easy, needs review, patch, patch
messages: 89304
nosy: krisvale
severity: normal
status: open
title: let unittest.assertRaises() return the exception object caught
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file14280/unittest.patch

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

From report at bugs.python.org  Sat Jun 13 11:34:47 2009
From: report at bugs.python.org (Vikram U Shenoy)
Date: Sat, 13 Jun 2009 09:34:47 +0000
Subject: [New-bugs-announce] [issue6276] Fix contextlib.nested
	DeprecationWarning for test_signal.
In-Reply-To: <1244885687.02.0.348626094115.issue6276@psf.upfronthosting.co.za>
Message-ID: <1244885687.02.0.348626094115.issue6276@psf.upfronthosting.co.za>


New submission from Vikram U Shenoy <vikram.u.shenoy at gmail.com>:

Attached is the patch to fix DeprecationWarning resulting from using
contextlib.nested() function in test_signal.py

----------
components: Tests
files: test_signal_with_fix_june_13_2009.patch
keywords: patch
messages: 89317
nosy: vshenoy
severity: normal
status: open
title: Fix contextlib.nested DeprecationWarning for test_signal.
versions: Python 2.7
Added file: http://bugs.python.org/file14283/test_signal_with_fix_june_13_2009.patch

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

From report at bugs.python.org  Sat Jun 13 11:38:49 2009
From: report at bugs.python.org (Vikram U Shenoy)
Date: Sat, 13 Jun 2009 09:38:49 +0000
Subject: [New-bugs-announce] [issue6277] Add description of new syntax of
	with to 2.7 whatsnew	document.
In-Reply-To: <1244885929.71.0.866974150177.issue6277@psf.upfronthosting.co.za>
Message-ID: <1244885929.71.0.866974150177.issue6277@psf.upfronthosting.co.za>


New submission from Vikram U Shenoy <vikram.u.shenoy at gmail.com>:

Attached are patches adding multiple context manager usage feature to
whats new document to both 2.7.rst in trunk and py3k.

Are 2.x.rsts in py3k supposed to be in sync with trunks 2.x.rsts ?

----------
assignee: georg.brandl
components: Documentation
messages: 89318
nosy: georg.brandl, vshenoy
severity: normal
status: open
title: Add description of new syntax of with to 2.7 whatsnew document.
versions: Python 2.7

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

From report at bugs.python.org  Sat Jun 13 13:12:06 2009
From: report at bugs.python.org (System32)
Date: Sat, 13 Jun 2009 11:12:06 +0000
Subject: [New-bugs-announce] [issue6278] http.server,
	BaseHTTPRequestHandler write string error
In-Reply-To: <1244891526.85.0.0899506861309.issue6278@psf.upfronthosting.co.za>
Message-ID: <1244891526.85.0.0899506861309.issue6278@psf.upfronthosting.co.za>


New submission from System32 <mullwar at gmail.com>:

CODE:
===========================================================
from http.server import HTTPServer, BaseHTTPRequestHandler

class RequestHandler(BaseHTTPRequestHandler):
	def _header(self):
		self.send_response(200)
		self.send_header("Content-type", "text/html")
		self.end_headers()
		
	def do_HEAD(self):
		self._header()
		
	def do_GET(self):
		self._header()	
		
		self.wfile.write('test')
		
server = HTTPServer(('localhost', 80), RequestHandler)
server.serve_forever()
===========================================================

ERROR:
===========================================================
localhost - - [13/Jun/2009 14:00:13] "GET / HTTP/1.1" 200 -
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 1907)
Traceback (most recent call last):
  File "C:\Python30\lib\socketserver.py", line 281, in 
_handle_request_noblock
    self.process_request(request, client_address)
  File "C:\Python30\lib\socketserver.py", line 307, in process_request
    self.finish_request(request, client_address)
  File "C:\Python30\lib\socketserver.py", line 320, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "C:\Python30\lib\socketserver.py", line 614, in __init__
    self.handle()
  File "C:\Python30\lib\http\server.py", line 363, in handle
    self.handle_one_request()
  File "C:\Python30\lib\http\server.py", line 357, in handle_one_request
    method()
  File "C:\Documents and Settings\User\Desktop\mHome\webserver.py", 
line 18, in
do_GET
    self.wfile.write('human')
  File "C:\Python30\lib\socket.py", line 219, in write
    return self._sock.send(b)
TypeError: send() argument 1 must be bytes or buffer, not str
===========================================================

----------
components: Library (Lib)
messages: 89321
nosy: System32
severity: normal
status: open
title: http.server, BaseHTTPRequestHandler write string error
type: compile error
versions: Python 3.0

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

From report at bugs.python.org  Sat Jun 13 16:13:49 2009
From: report at bugs.python.org (Florian Mayer)
Date: Sat, 13 Jun 2009 14:13:49 +0000
Subject: [New-bugs-announce] [issue6279] datamodel documentation confuses
	staticmethod with	classmethod
In-Reply-To: <1244902429.63.0.613787666637.issue6279@psf.upfronthosting.co.za>
Message-ID: <1244902429.63.0.613787666637.issue6279@psf.upfronthosting.co.za>


New submission from Florian Mayer <flormayer at aim.com>:

I think it is confusing that the datamodel documentation says __new__ is
a staticmethod while it actually is a classmethod (as it takes the class
as its first argument). Patch supplied.

----------
files: datamodel.rst.patch
keywords: patch
messages: 89331
nosy: segfaulthunter
severity: normal
status: open
title: datamodel documentation confuses staticmethod with classmethod
Added file: http://bugs.python.org/file14292/datamodel.rst.patch

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

From report at bugs.python.org  Sat Jun 13 18:48:03 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Sat, 13 Jun 2009 16:48:03 +0000
Subject: [New-bugs-announce] [issue6280] calendar.timegm() belongs in time
	module, next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>


New submission from Zooko O'Whielacronx <zooko at zooko.com>:

I've been struggling to write a function that takes UTC timestamps in
ISO-8601 strings and returns UTC timestamps in unix-seconds-since-epoch.
 The first implementation used time.mktime() minus time.timezone
(http://allmydata.org/trac/tahoe/browser/src/allmydata/util/time_format.py?rev=2424
), but that doesn't work in London if the argument date is in a certain
period during the 1970's.  Then there was force-the-tz-to-UTC
(http://allmydata.org/trac/tahoe/changeset/3911/src/allmydata/util/time_format.py
), but that doesn't work on Windows.  Then there was
force-the-tz-to-UTC-except-on-Windows
(http://allmydata.org/trac/tahoe/changeset/3913/src/allmydata/util/time_format.py
), but that still doesn't work on Windows.  Then there was this horrible
hack of converting from string-iso-8601 to localseconds with
time.mktime(), then converting from the resulting localseconds to an
iso-8601 string, then converting the resulting string back to seconds
with time.mktime(), then subtracting the two seconds values to find out
the real offset between UTC-seconds and local-seconds for the current tz
and for the time indicated by the argument
(http://allmydata.org/trac/tahoe/changeset/3914/src/allmydata/util/time_format.py
).  This actually works everywhere, but it is horrible.  Finally,
yesterday, someone pointed out to me that the inverse of time.gmtime()
is located in the "calendar" module and is named calendar.timegm().  Now
the implementation of our function is simple
(http://allmydata.org/trac/tahoe/changeset/3915/src/allmydata/util/time_format.py
)  I suggest that timegm() be moved to the time module next to its
sibling gmtime().

----------
components: Library (Lib)
messages: 89334
nosy: zooko
severity: normal
status: open
title: calendar.timegm() belongs in time module, next to time.gmtime()
versions: Python 2.5

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

From report at bugs.python.org  Sun Jun 14 00:45:31 2009
From: report at bugs.python.org (Daniel Eloff)
Date: Sat, 13 Jun 2009 22:45:31 +0000
Subject: [New-bugs-announce] [issue6281] Bug in hashlib
In-Reply-To: <1244933131.5.0.604284990762.issue6281@psf.upfronthosting.co.za>
Message-ID: <1244933131.5.0.604284990762.issue6281@psf.upfronthosting.co.za>


New submission from Daniel Eloff <dan.eloff at gmail.com>:

The try statement at the end of hashlib.py is some of the worst python
code I've had the mispleasure of reading for a long time.

Secondly, it seems flawed in function as well as form.
__get_builtin_constructor can throw an ImportError, which seems
erroneously caught in the except (why on earth does the except span more
than the "import _hashlib"? That's bad style for precisely this reason.)
This will cause an error in the import of hashlib when there are
possibly many working hash functions already imported. Changing the:

try:
    exec funcName + ' = __get_builtin_constructor(funcName)'
except ValueError:
    pass

to catch ImportError as well solves the problem for me.

----------
messages: 89338
nosy: Eloff
severity: normal
status: open
title: Bug in hashlib
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Jun 14 13:49:59 2009
From: report at bugs.python.org (Omri Shaked)
Date: Sun, 14 Jun 2009 11:49:59 +0000
Subject: [New-bugs-announce] [issue6282] In tarfile,
	compression level cannot be specified
In-Reply-To: <1244980199.28.0.54788876069.issue6282@psf.upfronthosting.co.za>
Message-ID: <1244980199.28.0.54788876069.issue6282@psf.upfronthosting.co.za>


New submission from Omri Shaked <omri.shaked at gmail.com>:

When creating a TarFile object that uses compression, the compressor is
always created using its default compression level.

import bz2
self.cmp = bz2.BZ2Compressor()

You can't specify the compression level (i.e. self.cmp =
bz2.BZ2Compressor(1)).

----------
components: Library (Lib)
messages: 89345
nosy: Tzigi
severity: normal
status: open
title: In tarfile, compression level cannot be specified
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Sun Jun 14 15:51:08 2009
From: report at bugs.python.org (Alex Shih-Han Lin)
Date: Sun, 14 Jun 2009 13:51:08 +0000
Subject: [New-bugs-announce] [issue6283] Cannot build extension in amd64
	using msvc9compiler
In-Reply-To: <1244987468.85.0.396301631891.issue6283@psf.upfronthosting.co.za>
Message-ID: <1244987468.85.0.396301631891.issue6283@psf.upfronthosting.co.za>


New submission from Alex Shih-Han Lin <alexsh at mail2000.com.tw>:

OS is Windows 7 x64, python using 2.6.2 amd64, SDK installed, but when I
build some module by setup.py, it always traceback ValueError.

running build
running build_py
running build_ext
building 'genshi._speedups' extension
Traceback (most recent call last):
  File "C:\Genshi-0.5.1\setup.py", line 116, in <module>
    'build_ext': optional_build_ext}
  File "C:\Python26\lib\distutils\core.py", line 152, in setup
    dist.run_commands()
  File "C:\Python26\lib\distutils\dist.py", line 975, in run_commands
    self.run_command(cmd)
  File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
    cmd_obj.run()
  File "C:\Python26\lib\distutils\command\build.py", line 134, in run
    self.run_command(cmd_name)
  File "C:\Python26\lib\distutils\cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
    cmd_obj.run()
  File "C:\Genshi-0.5.1\setup.py", line 39, in run
    build_ext.run(self)
  File "C:\Python26\lib\distutils\command\build_ext.py", line 345, in run
    self.build_extensions()
  File "C:\Python26\lib\distutils\command\build_ext.py", line 471, in
build_extensions
    self.build_extension(ext)
  File "C:\Genshi-0.5.1\setup.py", line 45, in build_extension
    build_ext.build_extension(self, ext)
  File "C:\Python26\lib\distutils\command\build_ext.py", line 536, in
build_extension
    depends=ext.depends)
  File "C:\Python26\lib\distutils\msvc9compiler.py", line 448, in compile
    self.initialize()
  File "C:\Python26\lib\distutils\msvc9compiler.py", line 358, in initialize
    vc_env = query_vcvarsall(VERSION, plat_spec)
  File "C:\Python26\lib\distutils\msvc9compiler.py", line 274, in
query_vcvarsall
    raise ValueError(str(list(result.keys())))
ValueError: [u'path']

I printed out the variables "result", it only had key 'path'.

----------
components: Library (Lib)
messages: 89348
nosy: alexsh
severity: normal
status: open
title: Cannot build extension in amd64 using msvc9compiler
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Sun Jun 14 19:03:39 2009
From: report at bugs.python.org (Campbell Barton)
Date: Sun, 14 Jun 2009 17:03:39 +0000
Subject: [New-bugs-announce] [issue6284] C/API PyErr_AsUnicode()
In-Reply-To: <1244999019.35.0.083174578591.issue6284@psf.upfronthosting.co.za>
Message-ID: <1244999019.35.0.083174578591.issue6284@psf.upfronthosting.co.za>


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

This function returns the output of PyErr_Print as a unicode string.

We needed this in Blender3D because it has its own error logging system
which does not use the console.

The patch is made against python3k r73429.

----------
components: None
files: PyErr_AsUnicode_r73429.diff
keywords: patch
messages: 89357
nosy: ideasman42
severity: normal
status: open
title: C/API PyErr_AsUnicode()
versions: Python 3.1
Added file: http://bugs.python.org/file14299/PyErr_AsUnicode_r73429.diff

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

From report at bugs.python.org  Mon Jun 15 01:26:47 2009
From: report at bugs.python.org (Scott David Daniels)
Date: Sun, 14 Jun 2009 23:26:47 +0000
Subject: [New-bugs-announce] [issue6285] Silent abort on XP help document
	display
In-Reply-To: <1245022007.21.0.85627036232.issue6285@psf.upfronthosting.co.za>
Message-ID: <1245022007.21.0.85627036232.issue6285@psf.upfronthosting.co.za>


New submission from Scott David Daniels <Scott.Daniels at Acm.Org>:

When running Idle on Windows XP, Python 3.1rc2, 
a failure to find an entry in the help documents causes Idle to exit
(with no visible indication of why).  The reason is in a failure of the
call to os.startfile, and apparenly the exception causes Idle to exit
silently.  Here is a patch to .../Lib/idlelib/EditorWindow.py:

@@ -436,20 +436,24 @@ class EditorWindow(object):
     def config_dialog(self, event=None):
         configDialog.ConfigDialog(self.top,'Settings')

     def help_dialog(self, event=None):
        
fn=os.path.join(os.path.abspath(os.path.dirname(__file__)),'help.txt')
         textView.view_file(self.top,'Help',fn)

     def python_docs(self, event=None):
-        if sys.platform[:3] == 'win':
-            os.startfile(self.help_url)
-        else:
-            webbrowser.open(self.help_url)
+        try:
+            if sys.platform[:3] == 'win':
+                os.startfile(self.help_url)
+            else:
+                webbrowser.open(self.help_url)
+        except EnvironmentError as why:
+            tkMessageBox.showerror(title='Document Start Failure',
+                                   message=str(why), parent=self.text)
         return "break"

     def cut(self,event):
         self.text.event_generate("<<Cut>>")
         return "break"

     def copy(self,event):
         if not self.text.tag_ranges("sel"):
@@ -741,20 +745,25 @@ class EditorWindow(object):
         # and update the menu dictionary
         self.menudict['help'] = helpmenu

     def __extra_help_callback(self, helpfile):
         "Create a callback with the helpfile value frozen at definition
time"
         def display_extra_help(helpfile=helpfile):
             if not helpfile.startswith(('www', 'http')):
                 url = os.path.normpath(helpfile)
-            if sys.platform[:3] == 'win':
-                os.startfile(helpfile)
-            else:
-                webbrowser.open(helpfile)
+            try:
+                if sys.platform[:3] == 'win':
+                    os.startfile(helpfile)
+                else:
+                    webbrowser.open(helpfile)
+            except EnvironmentError as why:
+                tkMessageBox.showerror(title='Document Start Failure',
+                                   message=str(why), parent=self.text)
+            return "break"
         return display_extra_help

     def update_recent_files_list(self, new_file=None):
         "Load and update the recent files list and menus"
         rf_list = []
         if os.path.exists(self.recent_files_path):
             rf_list_file = open(self.recent_files_path,'r')
             try:

----------
components: IDLE
messages: 89378
nosy: scott_daniels
severity: normal
status: open
title: Silent abort on XP help document display
versions: Python 3.1

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

From report at bugs.python.org  Mon Jun 15 11:54:22 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 15 Jun 2009 09:54:22 +0000
Subject: [New-bugs-announce] [issue6286] distutils upload command doesn't
	work with http proxy
In-Reply-To: <1245059662.2.0.968328150082.issue6286@psf.upfronthosting.co.za>
Message-ID: <1245059662.2.0.968328150082.issue6286@psf.upfronthosting.co.za>


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

upload is base on httplib and doesn't use the http_proxy envrionment
variable. So it's impossible to upload a file behind a firewall.

Let's change the command so it uses a proxy if set

----------
assignee: tarek
components: Distutils
messages: 89398
nosy: tarek
severity: normal
status: open
title: distutils upload command doesn't work with http proxy
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Jun 15 22:45:33 2009
From: report at bugs.python.org (Matthew Smart)
Date: Mon, 15 Jun 2009 20:45:33 +0000
Subject: [New-bugs-announce] [issue6287] distutils.core.setup does not
	document the 'license'	meta-data
In-Reply-To: <1245098733.95.0.286380216958.issue6287@psf.upfronthosting.co.za>
Message-ID: <1245098733.95.0.286380216958.issue6287@psf.upfronthosting.co.za>


New submission from Matthew Smart <mattsmart at gmail.com>:

The 'license' meta-data option is not listed under:

http://docs.python.org/distutils/setupscript.html#meta-data

There are others, too, from:

$ python setup.py --help
.. snip ..
Information display options (just display information, ignore any commands)
?--help-commands ? ? list all available commands
?--name ? ? ? ? ? ? ?print package name
?--version (-V) ? ? ?print package version
?--fullname ? ? ? ? ?print <package name>-<version>
?--author ? ? ? ? ? ?print the author's name
?--author-email ? ? ?print the author's email address
?--maintainer ? ? ? ?print the maintainer's name
?--maintainer-email ?print the maintainer's email address
?--contact ? ? ? ? ? print the maintainer's name if known, else the author's
?--contact-email ? ? print the maintainer's email address if known, else the
? ? ? ? ? ? ? ? ? ? ?author's
?--url ? ? ? ? ? ? ? print the URL for this package
?--license ? ? ? ? ? print the license of the package
?--licence ? ? ? ? ? alias for --license
?--description ? ? ? print the package description
?--long-description ?print the long package description
?--platforms ? ? ? ? print the list of platforms
?--classifiers ? ? ? print the list of classifiers
?--keywords ? ? ? ? ?print the list of keywords
?--provides ? ? ? ? ?print the list of packages/modules provided
?--requires ? ? ? ? ?print the list of packages/modules required
?--obsoletes ? ? ? ? print the list of packages/modules made obsolete

----------
assignee: tarek
components: Distutils
messages: 89410
nosy: mattsmart, tarek
severity: normal
status: open
title: distutils.core.setup does not document the 'license' meta-data
versions: Python 2.5

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

From report at bugs.python.org  Mon Jun 15 23:43:09 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 15 Jun 2009 21:43:09 +0000
Subject: [New-bugs-announce] [issue6288] Update contextlib.nested docs in
	light of deprecation
In-Reply-To: <1245102189.2.0.00392930921472.issue6288@psf.upfronthosting.co.za>
Message-ID: <1245102189.2.0.00392930921472.issue6288@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Just a placeholder to remind me to implement the suggestion from
python-dev of updating the contextlib.nested docs to show:

1. The one remaining valid use case (variable number of context managers)
2. The warnings module incantation needed to suppress the deprecation
warning

----------
assignee: ncoghlan
components: Documentation
messages: 89415
nosy: benjamin.peterson, ncoghlan
priority: release blocker
severity: normal
status: open
title: Update contextlib.nested docs in light of deprecation
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Tue Jun 16 00:22:40 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 15 Jun 2009 22:22:40 +0000
Subject: [New-bugs-announce] [issue6289] compile() raises SyntaxError with
	confusing message for	some decoding problems
In-Reply-To: <1245104560.97.0.54765703858.issue6289@psf.upfronthosting.co.za>
Message-ID: <1245104560.97.0.54765703858.issue6289@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

Consider this source file:

  # coding: ascii
  ?

It is not a valid Python program (for several reasons).  The first
problem encountered is that bytes representing SNOWMAN do not fit into
ASCII, so the file cannot be decoded using the declared encoding.

If one tries to import this file, a reasonable thing happens:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "encodingfoo.py", line 2
SyntaxError: 'ascii' codec can't decode byte 0xe2 in position 0: ordinal
not in range(128)

If the builtin compile() is used instead, though, something different
happens:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 0
SyntaxError: unknown encoding: ascii

----------
components: Library (Lib)
messages: 89417
nosy: exarkun
severity: normal
status: open
title: compile() raises SyntaxError with confusing message for some decoding problems
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue Jun 16 01:19:54 2009
From: report at bugs.python.org (Alex James)
Date: Mon, 15 Jun 2009 23:19:54 +0000
Subject: [New-bugs-announce] [issue6290] cPickle can misread data type
In-Reply-To: <1245107994.41.0.726587002709.issue6290@psf.upfronthosting.co.za>
Message-ID: <1245107994.41.0.726587002709.issue6290@psf.upfronthosting.co.za>


New submission from Alex James <ac.james at shaw.ca>:

When using cPickle to pickle / unpickle an object instance whose
__dict__ contains a dictionary of NumPy Arrays (on a windows32 system),
some of the array elements have the wrong type raising a ValueError:
could not convert string to float.  

On UNIX platform this error does not occur, and the data is read out in
the correct type every time.  
Forcing the caller to use pickle.py module instead removed the issue.

Statements about the imprecision of cPickle (such as issue1536, 655802),
or its deprecaition (now I can't find where that was mentioned), would
assist.  By contrast the current state of the documentation implies that
cPickle is better overall, and thus should be used preferentially.

----------
assignee: georg.brandl
components: Documentation, Extension Modules, Windows
messages: 89418
nosy: ac.james, georg.brandl
severity: normal
status: open
title: cPickle can misread data type
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Jun 16 10:19:54 2009
From: report at bugs.python.org (Milivoj Milani)
Date: Tue, 16 Jun 2009 08:19:54 +0000
Subject: [New-bugs-announce] [issue6291] TypeError: b2a_base64() argument 1
	must be bytes or	buffer, not str during SMTP.login
In-Reply-To: <1245140394.87.0.288539266224.issue6291@psf.upfronthosting.co.za>
Message-ID: <1245140394.87.0.288539266224.issue6291@psf.upfronthosting.co.za>


New submission from Milivoj Milani <milivojm at gzr.hr>:

When trying to send an e-mail using a tutorial like example, I get the 
following message:

Traceback (most recent call last):
  File "test.py", line 3, in <module>
    server.login("domena\someuser","somepassword")
  File "C:\Python\lib\smtplib.py", line 583, in login
    "%s %s" % (AUTH_LOGIN, encode_base64(user)))
  File "C:\Python\lib\email\base64mime.py", line 96, in body_encode
    enc = b2a_base64(s[i:i + max_unencoded]).decode("ascii")
TypeError: b2a_base64() argument 1 must be bytes or buffer, not str

----------
components: Library (Lib)
files: test.py
messages: 89428
nosy: milivojm
severity: normal
status: open
title: TypeError: b2a_base64() argument 1 must be bytes or buffer, not str during SMTP.login
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file14307/test.py

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

From report at bugs.python.org  Tue Jun 16 19:25:56 2009
From: report at bugs.python.org (Collin Winter)
Date: Tue, 16 Jun 2009 17:25:56 +0000
Subject: [New-bugs-announce] [issue6292] Fix tests to work with -OO
In-Reply-To: <1245173156.41.0.295143421803.issue6292@psf.upfronthosting.co.za>
Message-ID: <1245173156.41.0.295143421803.issue6292@psf.upfronthosting.co.za>


New submission from Collin Winter <collinw at gmail.com>:

The attached patch fixes a number of tests to work when -OO is given to 
Python. The majority of these tests are docstring-related, either doctests 
or making assertions about __doc__, with a handful of tests testing that 
assert statements will trigger and another handful of distutils tests that 
are looking for .pyc files.

With this applied, PYTHONOPTIMIZE=2 ./python.exe -OO Lib/test/regrtest.py 
now passes for trunk.

----------
components: Tests
files: oo_tests.patch
keywords: easy, patch
messages: 89434
nosy: collinwinter, jyasskin, rnk
severity: normal
stage: patch review
status: open
title: Fix tests to work with -OO
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file14309/oo_tests.patch

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

From report at bugs.python.org  Tue Jun 16 19:35:31 2009
From: report at bugs.python.org (Collin Winter)
Date: Tue, 16 Jun 2009 17:35:31 +0000
Subject: [New-bugs-announce] [issue6293] Have regrtest.py echo back sys.flags
In-Reply-To: <1245173731.34.0.991251966726.issue6293@psf.upfronthosting.co.za>
Message-ID: <1245173731.34.0.991251966726.issue6293@psf.upfronthosting.co.za>


New submission from Collin Winter <collinw at gmail.com>:

This patch makes regrtest.py echo back the contents of sys.flags at the 
beginning of a test run. Unladen Swallow has found this useful for 
verifying that the regrtest.py settings in the Makefile and in our 
Buildbot configs are interacting as expected.

Example output:
$ PYTHONOPTIMIZE=2 ./python.exe -OO Lib/test/regrtest.py
Testing with flags: sys.flags(debug=0, py3k_warning=0, 
division_warning=0, division_new=0, inspect=0, interactive=0, 
optimize=2, dont_write_bytecode=0, no_user_site=0, no_site=0, 
ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0)
test_grammar
test_opcodes
test_dict
test_builtin
test_exceptions
test_types
[snip]
$

----------
components: Tests
files: regrtest_flags.patch
keywords: easy, patch
messages: 89436
nosy: collinwinter
severity: normal
stage: patch review
status: open
title: Have regrtest.py echo back sys.flags
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file14310/regrtest_flags.patch

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

From report at bugs.python.org  Wed Jun 17 02:01:51 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 17 Jun 2009 00:01:51 +0000
Subject: [New-bugs-announce] [issue6294] Improve shutdown exception ignored
	message
In-Reply-To: <1245196911.61.0.437199244327.issue6294@psf.upfronthosting.co.za>
Message-ID: <1245196911.61.0.437199244327.issue6294@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

When (at least sometimes) exceptions occur during shutdown, warnings
like the following appear:
Exception TypeError: "'NoneType' object is not callable" in  ignored

This is apparently meant to be read as 
Exception <<TypeError: "'NoneType' object is not callable" in ...>>
[was] ignored

instead of, for instance
Exception TypeError: "'NoneType' object is not callable" in ignored

Even when parsed correctly, it is a bit mysterious (who/what ignored the
exception?) to one not in the know and has generated more than one
python-list thread.

Suggestion (from John Machin): reword to something like

Shutdown ignored this exception: TypeError: "'NoneType' object is not
callable"

This would tell people that they might need to find out more about the
shutdown process.

Would it be permissible to change this in 3.1?

----------
keywords: easy
messages: 89441
nosy: tjreedy
severity: normal
status: open
title: Improve shutdown exception ignored message
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Jun 17 11:18:33 2009
From: report at bugs.python.org (nojhan)
Date: Wed, 17 Jun 2009 09:18:33 +0000
Subject: [New-bugs-announce] [issue6295] curses doc : getch is blocking by
	default
In-Reply-To: <1245230313.16.0.0482722350238.issue6295@psf.upfronthosting.co.za>
Message-ID: <1245230313.16.0.0482722350238.issue6295@psf.upfronthosting.co.za>


New submission from nojhan <nojhan at gmail.com>:

The documentation of the curses module is not clear on the fact that
getch is blocking by default:
http://docs.python.org/3.0/library/curses.html#curses.window.getch

I suggest the following description instead of the current one:
"Get a character. Note that the integer returned does not have to be in
ASCII range: function keys, keypad keys and so on return numbers higher
than 256. By default, getch() is blocking and wait indefinitely for a
key press. In nodelay() mode, -1 is returned if there is no input."

----------
assignee: georg.brandl
components: Documentation
messages: 89447
nosy: georg.brandl, nojhan
severity: normal
status: open
title: curses doc : getch is blocking by default
type: feature request
versions: Python 3.0

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

From report at bugs.python.org  Wed Jun 17 15:33:50 2009
From: report at bugs.python.org (Michael Foord)
Date: Wed, 17 Jun 2009 13:33:50 +0000
Subject: [New-bugs-announce] [issue6296] Native (and default) tarfile
	support for setup.py sdist	in distutils on Windows
In-Reply-To: <1245245630.18.0.224607523943.issue6296@psf.upfronthosting.co.za>
Message-ID: <1245245630.18.0.224607523943.issue6296@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

setup.py should be able to generate tarfile distributions on Windows
without requiring tar to be on the path.

Ideally "setup.py sdist" should create the same type of archive (zip or
tarball) by default independent of platform.

At the moment it creates a zip by default on Windows and a tarball on
Linux / OS X.

Packages created on Windows also have CRLF line endings in the MANIFEST
file which is a nuisance for non-Windows consumers of distributions.

----------
assignee: tarek
components: Distutils
messages: 89454
nosy: michael.foord, tarek
severity: normal
status: open
title: Native (and default) tarfile support for setup.py sdist in distutils on Windows

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

From report at bugs.python.org  Wed Jun 17 21:14:20 2009
From: report at bugs.python.org (Jerry Chen)
Date: Wed, 17 Jun 2009 19:14:20 +0000
Subject: [New-bugs-announce] [issue6297] Added Misc/python.pc to 'distclean'
	Rule
In-Reply-To: <1245266060.76.0.919616953037.issue6297@psf.upfronthosting.co.za>
Message-ID: <1245266060.76.0.919616953037.issue6297@psf.upfronthosting.co.za>


New submission from Jerry Chen <jerry at 3rdengine.com>:

Added Misc/python.pc to 'distclean' rule

Minor issue... After running ./configure, Misc/python.pc is generated
from python.pc.in. Interesting to note in the python2.7 trunk, this file
is added to the svn:ignore property of Misc/ so it doesn't show up to
svn, but in accordance with the rest of the 'distclean' rule, it makes
sense to remove the file completely.

Diff'd against r73468.

----------
assignee: georg.brandl
components: Documentation
files: makefile-clobber.diff
keywords: patch
messages: 89476
nosy: georg.brandl, jcsalterego
severity: normal
status: open
title: Added Misc/python.pc to 'distclean' Rule
versions: Python 3.1
Added file: http://bugs.python.org/file14315/makefile-clobber.diff

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

From report at bugs.python.org  Wed Jun 17 22:00:19 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Wed, 17 Jun 2009 20:00:19 +0000
Subject: [New-bugs-announce] [issue6298] http://python.org/download says
	Python 2.4.5, but I think it means Python 2.4.6.
Message-ID: <1245268819.2.0.178643041383.issue6298@psf.upfronthosting.co.za>


Changes by Zooko O'Whielacronx <zooko at zooko.com>:


----------
assignee: georg.brandl
components: Documentation
nosy: georg.brandl, zooko
severity: normal
status: open
title: http://python.org/download says Python 2.4.5, but I think it means Python 2.4.6.

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

From report at bugs.python.org  Wed Jun 17 22:07:54 2009
From: report at bugs.python.org (Tim Mooney)
Date: Wed, 17 Jun 2009 20:07:54 +0000
Subject: [New-bugs-announce] [issue6299] pyexpat build failure on Solaris 10
	for 2.6.1/2.6.2
In-Reply-To: <1245269274.21.0.966496864817.issue6299@psf.upfronthosting.co.za>
Message-ID: <1245269274.21.0.966496864817.issue6299@psf.upfronthosting.co.za>


New submission from Tim Mooney <enchanter at users.sourceforge.net>:

I've built Python 2.6.1 and Python 2.6.2 on x86_64-sun-solaris2.10 using
the Sun Workshop Express (200903) toolchain.  I'm building in 64 bit mode.

Most stuff builds just fine (even warnings are rare), but pyexpat fails
to link with this error:

building 'pyexpat' extension
creating
build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/expat
cc -xtarget=native -m64 -xarch=native -KPIC -DNDEBUG -Xa -xO4 -xstrconst
-mt -xtarget=native -m64 -xarch=native -I/local/include
-I/local/gnu/include -I/local/BerkeleyDB/include
-I/local/openssl/include -DHAVE_EXPAT_CONFIG_H=1 -DUSE_PYEXPAT_CAPI
-I/local/src/RPM/BUILD/Python-2.6.2/./Modules/expat -I.
-I/local/src/RPM/BUILD/Python-2.6.2/./Include -I. -IInclude -I./Include
-I/local/include -I/local/gnu/include -I/local/BerkeleyDB/include
-I/local/openssl/include -I/usr/local/include
-I/local/src/RPM/BUILD/Python-2.6.2/Include
-I/local/src/RPM/BUILD/Python-2.6.2 -c
/local/src/RPM/BUILD/Python-2.6.2/Modules/pyexpat.c -o
build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/pyexpat.o
"/local/src/RPM/BUILD/Python-2.6.2/Modules/pyexpat.c", line 1574:
warning: assignment type mismatch:
    pointer to void "=" pointer to function(pointer to void, pointer to
const ch
ar, int) returning void
cc -xtarget=native -m64 -xarch=native -KPIC -DNDEBUG -Xa -xO4 -xstrconst
-mt -xtarget=native -m64 -xarch=native -I/local/include
-I/local/gnu/include -I/local/BerkeleyDB/include
-I/local/openssl/include -DHAVE_EXPAT_CONFIG_H=1 -DUSE_PYEXPAT_CAPI
-I/local/src/RPM/BUILD/Python-2.6.2/./Modules/expat -I.
-I/local/src/RPM/BUILD/Python-2.6.2/./Include -I. -IInclude -I./Include
-I/local/include -I/local/gnu/include -I/local/BerkeleyDB/include
-I/local/openssl/include -I/usr/local/include
-I/local/src/RPM/BUILD/Python-2.6.2/Include
-I/local/src/RPM/BUILD/Python-2.6.2 -c
/local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmlparse.c -o
build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmlparse.o
cc -xtarget=native -m64 -xarch=native -KPIC -DNDEBUG -Xa -xO4 -xstrconst
-mt -xtarget=native -m64 -xarch=native -I/local/include
-I/local/gnu/include -I/local/BerkeleyDB/include
-I/local/openssl/include -DHAVE_EXPAT_CONFIG_H=1 -DUSE_PYEXPAT_CAPI
-I/local/src/RPM/BUILD/Python-2.6.2/./Modules/expat -I.
-I/local/src/RPM/BUILD/Python-2.6.2/./Include -I. -IInclude -I./Include
-I/local/include -I/local/gnu/include -I/local/BerkeleyDB/include
-I/local/openssl/include -I/usr/local/include
-I/local/src/RPM/BUILD/Python-2.6.2/Include
-I/local/src/RPM/BUILD/Python-2.6.2 -c
/local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmlrole.c -o
build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmlrole.o
cc -xtarget=native -m64 -xarch=native -KPIC -DNDEBUG -Xa -xO4 -xstrconst
-mt -xtarget=native -m64 -xarch=native -I/local/include
-I/local/gnu/include -I/local/BerkeleyDB/include
-I/local/openssl/include -DHAVE_EXPAT_CONFIG_H=1 -DUSE_PYEXPAT_CAPI
-I/local/src/RPM/BUILD/Python-2.6.2/./Modules/expat -I.
-I/local/src/RPM/BUILD/Python-2.6.2/./Include -I. -IInclude -I./Include
-I/local/include -I/local/
gnu/include -I/local/BerkeleyDB/include -I/local/openssl/include
-I/usr/local/include -I/local/src/RPM/BUILD/Python-2.6.2/Include
-I/local/src/RPM/BUILD/Python-2.6.2 -c
/local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmltok.c -o
build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmltok.o
cc -xtarget=native -m64 -xarch=native -G -L/local/lib/64
-L/local/gnu/lib/64 -L/local/BerkeleyDB/lib/64 -L/local/openssl/lib/64
-L/local/lib/64 -L/local/gnu/lib/64 -L/local/BerkeleyDB/lib/64
-L/local/openssl/lib/64 -DNDEBUG -Xa -xO4 -xstrconst -mt -xtarget=native
-m64 -xarch=native -I/local/include -I/local/gnu/include
-I/local/BerkeleyDB/include -I/local/openssl/include -I. -IInclude
-I./Include 
-I/local/include -I/local/gnu/include -I/local/BerkeleyDB/include
-I/local/openssl/include
build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/pyexpat.o
build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmlparse.o
build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmlrole.o
build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmltok.o
-L/local/lib -L/local/lib/64 -L/local/gnu/lib/64
-L/local/BerkeleyDB/lib/64 -L/local/openssl/lib/64 -L/usr/local/lib -o
build/lib.solaris-2.10-i86pc-2.6/pyexpat.so
*** WARNING: renaming "pyexpat" since importing it failed: ld.so.1:
python: fatal: relocation error: file
build/lib.solaris-2.10-i86pc-2.6/pyexpat.so: symbol
XML_SetCharacterDataHandler: referenced symbol not found

I never tried any of the 2.5.x Python builds, but I can tell you that I
built several versions in the 2.4.x series, and none of those versions
had problems compiling or linking pyexpat.

I do have expat 2.0.1 (also built with the Sun compiler in 64 bit mode)
installed on the system, but from the comments in setup.py and the
compiler output, it appears clear that the expat components that ship
with Python 2.6.x are the ones that are being compiled and attempted for
use in the link.

Please let me know if I can provide any relevant information.

Thanks,

Tim (the Enchanter)

----------
components: Build
messages: 89478
nosy: enchanter
severity: normal
status: open
title: pyexpat build failure on Solaris 10 for 2.6.1/2.6.2
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun 18 02:00:15 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Jun 2009 00:00:15 +0000
Subject: [New-bugs-announce] [issue6300] encode and decode should accept
	'errors' as a keyword	argument
In-Reply-To: <1245283215.71.0.778706476044.issue6300@psf.upfronthosting.co.za>
Message-ID: <1245283215.71.0.778706476044.issue6300@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

I repeatedly find myself typing things like
"mybytestring.decode('ASCII', errors='replace')".  This seems like the
natural (I'm tempted to say Pythonic) thing to do, and is more readable
(IMO) than "mybytestring.decode('ASCII', 'replace')".  (replace what?).
 However currently encode and decode complain that they do not take any
keyword arguments.

----------
components: Interpreter Core
messages: 89485
nosy: r.david.murray
priority: low
severity: normal
status: open
title: encode and decode should accept 'errors' as a keyword argument
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Jun 18 03:14:21 2009
From: report at bugs.python.org (david)
Date: Thu, 18 Jun 2009 01:14:21 +0000
Subject: [New-bugs-announce] [issue6301] Error in tutorial section 7.2
In-Reply-To: <1245287661.76.0.495139825921.issue6301@psf.upfronthosting.co.za>
Message-ID: <1245287661.76.0.495139825921.issue6301@psf.upfronthosting.co.za>


New submission from david <davix at plasmatronics.com.au>:

http://docs.python.org/tutorial/inputoutput.html#reading-and-writing-
files
"Windows makes a distinction between text and binary files;
"the end-of-line characters in text files are automatically altered
"slightly when data is read or written.

Windows does not make a distinction between text and binary files:
http://msdn.microsoft.com/en-us/library/aa365430(VS.85).aspx
http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx
http://msdn.microsoft.com/en-us/library/aa365467(VS.85).aspx

Nor does it automatically alter end-of-line characters.

It is not clear what distinction Python makes between text and binary 
files. Do those options do anything on any platform? Is jPython 
different than cPython? And does Python automatically alter end-of-line 
characters?

----------
assignee: georg.brandl
components: Documentation
messages: 89487
nosy: georg.brandl, melbourne
severity: normal
status: open
title: Error in tutorial section 7.2

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

From report at bugs.python.org  Thu Jun 18 03:36:16 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Jun 2009 01:36:16 +0000
Subject: [New-bugs-announce] [issue6302] email.header.decode_header data
	types are inconsistent	and incorrectly documented
In-Reply-To: <1245288976.09.0.298419063758.issue6302@psf.upfronthosting.co.za>
Message-ID: <1245288976.09.0.298419063758.issue6302@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

decode_header only accepts str as input.  If the input contains no
encoded words, the output is str (ie: the input string) and None.  If it
does contain encoded words, the output is pairs of bytes plus str
charset identifiers (or None).  This makes it difficult to use this
function to decode headers, since one has to test for the special case
of str output when there are no encoded words.

I think decode_header should take bytes as input, and output (bytes.
str) pairs consistently.

In any case, the documentation is wrong since it says it returns
strings.  The example is also wrong, since the actual output is:

[(b'p\xf6stal', 'iso-8859-1')]

----------
components: Library (Lib)
messages: 89488
nosy: r.david.murray
priority: normal
severity: normal
stage: test needed
status: open
title: email.header.decode_header data types are inconsistent and incorrectly documented
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Jun 18 04:40:57 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Jun 2009 02:40:57 +0000
Subject: [New-bugs-announce] [issue6303] print does not appear in the 3.x
	documentation index
In-Reply-To: <1245292857.22.0.335775123818.issue6303@psf.upfronthosting.co.za>
Message-ID: <1245292857.22.0.335775123818.issue6303@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Since print is now a built in function, it should appear in the library
reference index, but it does not.

----------
assignee: georg.brandl
components: Documentation
messages: 89489
nosy: georg.brandl, r.david.murray
priority: low
severity: normal
stage: needs patch
status: open
title: print does not appear in the 3.x documentation index
type: behavior
versions: Python 3.0, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Jun 18 04:51:45 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Jun 2009 02:51:45 +0000
Subject: [New-bugs-announce] [issue6304] Confusing error message when
	passing bytes to print with	file pointing to a binary file
In-Reply-To: <1245293505.96.0.175038220478.issue6304@psf.upfronthosting.co.za>
Message-ID: <1245293505.96.0.175038220478.issue6304@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

The documentation for the print function specifies that the input
argument is coerced to string.  However, if bytes are passed and the
file= parameter points to a file open for binary write, the error
message produced is:

>>> out = open('temp', 'wb')
>>> print(b'abc', file=out)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: write() argument 1 must be bytes or buffer, not str

which is, to say the least, confusing, since I clearly passed print a
bytes object as argument 1.

----------
components: IO
messages: 89490
nosy: r.david.murray
priority: low
severity: normal
stage: test needed
status: open
title: Confusing error message when passing bytes to print with file pointing to a binary file
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Jun 18 09:14:23 2009
From: report at bugs.python.org (Thomas Guest)
Date: Thu, 18 Jun 2009 07:14:23 +0000
Subject: [New-bugs-announce] [issue6305] islice doesn't accept large stop
	values
In-Reply-To: <1245309263.43.0.625809679675.issue6305@psf.upfronthosting.co.za>
Message-ID: <1245309263.43.0.625809679675.issue6305@psf.upfronthosting.co.za>


New submission from Thomas Guest <tag at wordaligned.org>:

Python 3.0 (r30:67503, Jan  7 2009, 16:22:01) 
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin

>>> from itertools import islice, count
>>> islice(count(), (1<<31) - 1)
<itertools.islice object at 0x63a0c0>
>>> islice(count(), (1<<31))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Stop argument for islice() must be a non-negative integer or
None.

----------
messages: 89494
nosy: thomasguest
severity: normal
status: open
title: islice doesn't accept large stop values
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Thu Jun 18 12:36:14 2009
From: report at bugs.python.org (higer)
Date: Thu, 18 Jun 2009 10:36:14 +0000
Subject: [New-bugs-announce] [issue6306] filecmp.cmp can not compare two
	files from different OS	with the same content
In-Reply-To: <1245321374.99.0.206303396049.issue6306@psf.upfronthosting.co.za>
Message-ID: <1245321374.99.0.206303396049.issue6306@psf.upfronthosting.co.za>


New submission from higer <higerinbeijing at gmail.com>:

I just want to compare two files,one from windows and the other from
unix. But I do not want to compare them through reading them line by
line. Then I found there is a filecmp module which is used as file and
directory comparisons. However,when I use two same files (one from
unix,one from windows,the content of them is the same) to test its cmp
function, filecmp.cmp told me false.
Later, I found that windows use '\n\r' as new line flag but unix use
'\n', so filecmp.cmp think that they are different,then return false.

I think maybe it's a bug.
If filecmp.cmp can support two platform files with the same content
and only the diffrent last newline flag, that's would be wonderful.

----------
components: Library (Lib)
messages: 89498
nosy: higer
severity: normal
status: open
title: filecmp.cmp can not compare two files from different OS with the same content
type: feature request
versions: Python 2.5

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

From report at bugs.python.org  Thu Jun 18 13:37:27 2009
From: report at bugs.python.org (Viktor Ferenczi)
Date: Thu, 18 Jun 2009 11:37:27 +0000
Subject: [New-bugs-announce] [issue6307] AttributeError in
	traceback.print_last()
In-Reply-To: <1245325047.26.0.892033914272.issue6307@psf.upfronthosting.co.za>
Message-ID: <1245325047.26.0.892033914272.issue6307@psf.upfronthosting.co.za>


New submission from Viktor Ferenczi <python at cx.hu>:

Python 2.5.4, Windows MSI installer, WinXP SP2, 32 bit:

Try the following code: (test script attached)

import traceback

try:
    someundefinedsymbol
except:
    traceback.print_last()

It will raise the following exception:

Traceback (most recent call last):
  File "bug.py", line 6, in <module>
    traceback.print_last()
  File "D:\Python25\lib\traceback.py", line 246, in print_last
    print_exception(sys.last_type, sys.last_value, sys.last_traceback,
AttributeError: 'module' object has no attribute 'last_type'

----------
components: Library (Lib)
messages: 89499
nosy: complex
severity: normal
status: open
title: AttributeError in traceback.print_last()
type: crash
versions: Python 2.5

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

From report at bugs.python.org  Thu Jun 18 18:22:23 2009
From: report at bugs.python.org (Michael Haubenwallner)
Date: Thu, 18 Jun 2009 16:22:23 +0000
Subject: [New-bugs-announce] [issue6308] termios fix for QNX breaks HP-UX
In-Reply-To: <1245342143.83.0.0806702305005.issue6308@psf.upfronthosting.co.za>
Message-ID: <1245342143.83.0.0806702305005.issue6308@psf.upfronthosting.co.za>


New submission from Michael Haubenwallner <michael.haubenwallner at salomon.at>:

The patch for issue 1722225 in Include/pyport.h to include
<sys/termio.h> before <termios.h> for QNX does break for HP-UX:
On HP-UX, 'struct termios' gets declared within <sys/termio.h>, but when
included via <termios.h> _only_. Due to the include guard, it does not
declare 'struct termios' when included via <termios.h> the second time.

This is Python-2.6.2, but the code looks unchanged in trunk. As I'm not
sure how best to fix this, for 2.6.2 here I go with:
-#ifdef HAVE_SYS_TERMIO_H
+#if defined(HAVE_SYS_TERMIO_H) && defined(__QNX__)

Thanks!

----------
components: Build
messages: 89507
nosy: haubi
severity: normal
status: open
title: termios fix for QNX breaks HP-UX
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Fri Jun 19 02:19:01 2009
From: report at bugs.python.org (Erik Antelman)
Date: Fri, 19 Jun 2009 00:19:01 +0000
Subject: [New-bugs-announce] [issue6309] Tix needs TCL package require
	statement
In-Reply-To: <1245370741.24.0.759897657733.issue6309@psf.upfronthosting.co.za>
Message-ID: <1245370741.24.0.759897657733.issue6309@psf.upfronthosting.co.za>


New submission from Erik Antelman <eantelman at acm.org>:

For at least Tix.ComboBox it appears to be necessary to invoke the TCL
package loading explicitly with:
   root.tk.eval('package require Tix')

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

----------
components: Tkinter
files: TixIssue.py
messages: 89517
nosy: eantelman
severity: normal
status: open
title: Tix needs TCL package require statement
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14318/TixIssue.py

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

From report at bugs.python.org  Fri Jun 19 07:12:51 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 19 Jun 2009 05:12:51 +0000
Subject: [New-bugs-announce] [issue6310] Windows "App Paths" key is not
	checked when installed for	current user
In-Reply-To: <1245388371.55.0.866683174508.issue6310@psf.upfronthosting.co.za>
Message-ID: <1245388371.55.0.866683174508.issue6310@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

I found that if Python installed only for current user on Windows XP
Home Edition SP3 Python fails to run from Start -> Run dialog or using
ShellExecute() call. It is because it creates "App Paths" key in
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App
Paths\Python.exe
and not in
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App
Paths\Python.exe

Can anybody confirm this?

----------
components: Windows
messages: 89519
nosy: techtonik
severity: normal
status: open
title: Windows "App Paths" key is not checked when installed for current user
versions: Python 2.5

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

From report at bugs.python.org  Fri Jun 19 12:15:36 2009
From: report at bugs.python.org (helgekraak)
Date: Fri, 19 Jun 2009 10:15:36 +0000
Subject: [New-bugs-announce] [issue6311] virtual memory error with
	archivemail
In-Reply-To: <1245406536.49.0.871385683543.issue6311@psf.upfronthosting.co.za>
Message-ID: <1245406536.49.0.871385683543.issue6311@psf.upfronthosting.co.za>


New submission from helgekraak <helge at kraak.info>:

Hi,

I'm neither a Python nor a Unix specialist, so please understand that I
can't give a very professional bug report.

My issue seems to be related to issues 1092502 and 1389051. When I run
archivemail with Python 2.6.2 after a couple of minutes the virtual
memory in the activity monitor suddenly goes up to more than 2 GB and
then the python process quits as it seems to have reached a limit of the
virtual memory (the virtual memory available is about 10 GB). Most of
the time the virtual memory is stable around 40 MB and only sporadically
the memory suddenly increases to values between 100 MB and 2 GB but goes
back to 40 MB again until the one time that it goes so high that the
python process quits. The error happens much faster when I use a non
secured imap connection compared to a secured connection.

I get this error message:

command: archivemail --date='23 April 2030' --include-flagged
--output-dir=/temp  --copy  imaps://*****:*****@*****/inbox


error message: Python(1238) malloc: *** vm_allocate(size=15396864)
failed (error code=3)
Python(1238) malloc: *** error: can't allocate region
Python(1238) malloc: *** set a breakpoint in szone_error to debug
Traceback (most recent call last):
  File "/opt/local/bin/archivemail", line 1603, in ?
    main()
  File "/opt/local/bin/archivemail", line 702, in main
    archive(mailbox_path)
  File "/opt/local/bin/archivemail", line 1145, in archive
    _archive_imap(mailbox_name, final_archive_name)
  File "/opt/local/bin/archivemail", line 1424, in _archive_imap
    result, response = imap_srv.fetch(msn, '(RFC822)')
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/imaplib.py",
line 426, in fetch
    typ, dat = self._simple_command(name, message_set, message_parts)
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/imaplib.py",
line 1028, in _simple_command
    return self._command_complete(name, self._command(name, *args))
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/imaplib.py",
line 858, in _command_complete
    typ, data = self._get_tagged_response(tag)
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/imaplib.py",
line 959, in _get_tagged_response
    self._get_response()
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/imaplib.py",
line 921, in _get_response
    data = self.read(size)
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/imaplib.py",
line 1123, in read
    data = self.sslobj.read(size-read)
MemoryError


Thanks for your time!

Helge

----------
messages: 89520
nosy: helgekraak
severity: normal
status: open
title: virtual memory error with archivemail
versions: Python 2.6

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

From report at bugs.python.org  Fri Jun 19 15:53:30 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 19 Jun 2009 13:53:30 +0000
Subject: [New-bugs-announce] [issue6312] httplib fails with HEAD requests to
	pages with	"transfer-encoding: chunked"
In-Reply-To: <1245419610.47.0.800823464354.issue6312@psf.upfronthosting.co.za>
Message-ID: <1245419610.47.0.800823464354.issue6312@psf.upfronthosting.co.za>


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

Try this code (youtube.com uses "transfer-encoding: chunked"):

import httplib
url = 'www.youtube.com'
conn = httplib.HTTPConnection(url)
conn.request('HEAD', '/') # send an HEAD request
res = conn.getresponse()
print res.getheader('transfer-encoding')

so far it works fine, but when you try:

res.read()

it just hung there, where "there" is:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Programs\Python26\lib\httplib.py", line 517, in read
    return self._read_chunked(amt)
  File "C:\Programs\Python26\lib\httplib.py", line 553, in _read_chunked
    line = self.fp.readline()
  File "C:\Programs\Python26\lib\socket.py", line 395, in readline
    data = recv(1)
KeyboardInterrupt

If instead of youtube.com we replace the url with the one of a site that
doesn't use "transfer-encoding: chunked" (e.g. url = 'dpaste.com'),
res.read() returns an empty string.



When an HEAD request is sent, the content of the page is not returned,
so there should be no point in calling .read(), but try this:

import urllib2

class HeadRequest(urllib2.Request):
    def get_method(self):
        return 'HEAD'

url = 'http://www.youtube.com/watch?v=tCVqx2b-c7U'
# Note: I had this problem with this URL, the video 
# is not available in my country (Finland) and it
# may work fine for other countries

req = HeadRequest(url)
page = urllib2.urlopen(req)


This is what happens here with Python 2.5:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/urllib2.py", line 124, in urlopen
    return _opener.open(url, data)
  File "/usr/lib/python2.5/urllib2.py", line 387, in open
    response = meth(req, response)
  File "/usr/lib/python2.5/urllib2.py", line 498, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python2.5/urllib2.py", line 419, in error
    result = self._call_chain(*args)
  File "/usr/lib/python2.5/urllib2.py", line 360, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.5/urllib2.py", line 579, in http_error_302
    fp.read()
  File "/usr/lib/python2.5/socket.py", line 291, in read
    data = self._sock.recv(recv_size)
  File "/usr/lib/python2.5/httplib.py", line 509, in read
    return self._read_chunked(amt)
  File "/usr/lib/python2.5/httplib.py", line 548, in _read_chunked
    chunk_left = int(line, 16)
ValueError: invalid literal for int() with base 16: ''


With Python 2.6 the error is slightly different:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Programs\Python26\lib\urllib2.py", line 124, in urlopen
    return _opener.open(url, data, timeout)
  File "C:\Programs\Python26\lib\urllib2.py", line 389, in open
    response = meth(req, response)
  File "C:\Programs\Python26\lib\urllib2.py", line 502, in http_response
    'http', request, response, code, msg, hdrs)
  File "C:\Programs\Python26\lib\urllib2.py", line 421, in error
    result = self._call_chain(*args)
  File "C:\Programs\Python26\lib\urllib2.py", line 361, in _call_chain
    result = func(*args)
  File "C:\Programs\Python26\lib\urllib2.py", line 594, in http_error_302
    fp.read()
  File "C:\Programs\Python26\lib\socket.py", line 327, in read
    data = self._sock.recv(rbufsize)
  File "C:\Programs\Python26\lib\httplib.py", line 517, in read
    return self._read_chunked(amt)
  File "C:\Programs\Python26\lib\httplib.py", line 563, in _read_chunked
    raise IncompleteRead(value)
httplib.IncompleteRead

With Py3.0 it is the same:
[...]
http.client.IncompleteRead: b''


In this case self.fp.readline() (and the data = recv(1) in socket.py)
returns and the error happens a few lines later.
This seems to happen when there's a redirection in between (the video is
not available in my country, the server sends back a 303 status code,
and redirects me to the home page). The redirection is not handled by
httplib so there might be something wrong in urllib2 too (why it's
trying to read the content if we sent and HEAD request and if there is a
redirection in between?), but fixing httplib to return an empty string
or something similar could be enough to solve this problem too. If
there's actually a problem another issue should probably be created.

With the same code and the url of a working youtube video (no
redirections in between), "page = urllib2.urlopen(req)" works even if
there's the "transfer-encoding: chunked" but it fails later if we do
"page.read()": 

Traceback (most recent call last):
  File "C:\Programs\Python30\lib\http\client.py", line 520, in _read_chunked
    chunk_left = int(line, 16)
ValueError: invalid literal for int() with base 16: ''

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Programs\Python30\lib\http\client.py", line 479, in read
    return self._read_chunked(amt)
  File "C:\Programs\Python30\lib\http\client.py", line 525, in _read_chunked
    raise IncompleteRead(value)
http.client.IncompleteRead: b''

----------
components: Library (Lib)
messages: 89521
nosy: ezio.melotti
priority: normal
severity: normal
status: open
title: httplib fails with HEAD requests to pages with "transfer-encoding: chunked"
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0

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

From report at bugs.python.org  Sat Jun 20 00:05:39 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 19 Jun 2009 22:05:39 +0000
Subject: [New-bugs-announce] [issue6313] test_with.py has a couple minor
	mistakes
In-Reply-To: <1245449139.95.0.492404802638.issue6313@psf.upfronthosting.co.za>
Message-ID: <1245449139.95.0.492404802638.issue6313@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

I found a couple mistakes in test_with.py with Pyflakes.

----------
components: Tests
files: test_with.patch
keywords: patch
messages: 89530
nosy: exarkun
severity: normal
status: open
title: test_with.py has a couple minor mistakes
versions: Python 2.7
Added file: http://bugs.python.org/file14322/test_with.patch

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

From report at bugs.python.org  Sat Jun 20 06:58:49 2009
From: report at bugs.python.org (alexl)
Date: Sat, 20 Jun 2009 04:58:49 +0000
Subject: [New-bugs-announce] [issue6314] logging.basicConfig(level='DEBUG',
	...
In-Reply-To: <1245473929.89.0.283081310598.issue6314@psf.upfronthosting.co.za>
Message-ID: <1245473929.89.0.283081310598.issue6314@psf.upfronthosting.co.za>


New submission from alexl <alex_lukanin at mail.ru>:

The following code runs w/o exceptions, but log file is empty:

import logging
logging.basicConfig(level='DEBUG', filename='log.txt')
logging.info('Oh hi!')

To avoid such silent error, basicConfig must either throw exception on 
invalid level parameter, or accept string values.

----------
components: Library (Lib)
messages: 89536
nosy: alexl
severity: normal
status: open
title: logging.basicConfig(level='DEBUG', ...
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Sat Jun 20 10:03:55 2009
From: report at bugs.python.org (Stephen J. Turnbull)
Date: Sat, 20 Jun 2009 08:03:55 +0000
Subject: [New-bugs-announce] [issue6315]
	locale._build_localename(locale.getdefaultlocale())	returns
	'C.mac-roman'
In-Reply-To: <1245485035.23.0.886110297482.issue6315@psf.upfronthosting.co.za>
Message-ID: <1245485035.23.0.886110297482.issue6315@psf.upfronthosting.co.za>


New submission from Stephen J. Turnbull <stephen at xemacs.org>:

Which causes the locale machinery to spit exceptions, and the program to 
die, usually (eg, hg).

This manifests naturally on an Intel Mac, Mac OS X 10.5.7, but the 
problem behavior is in _build_localename.  When called as

_build_localename((None,'any_string'))

it returns 'C.any_string'.  I don't know of any system that supports 
anything but the POSIX portable character set in the C/POSIX locale, so
this is clearly wrong.

I suggest that when the first component of the argument is None, the
second component should be ignored.

Probably my Mac is misconfigured, but I think this is still a bug that 
should be fixed.

Observed in all of 2.5.4, 2.6.2, and 3.0.1 (vanilla MacPorts builds).

References: It's possible this is related to issue1699853, issue1176504, 
issue504219, but I don't think fixing this will help with those issues.  
It is not related to issue3067.

----------
components: Library (Lib)
messages: 89537
nosy: sjt
severity: normal
status: open
title: locale._build_localename(locale.getdefaultlocale()) returns 'C.mac-roman'
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Sat Jun 20 17:14:12 2009
From: report at bugs.python.org (Jeong-Min Lee)
Date: Sat, 20 Jun 2009 15:14:12 +0000
Subject: [New-bugs-announce] [issue6316] format,
	str.format don't work well with datetime, date object
In-Reply-To: <1245510852.42.0.472417043973.issue6316@psf.upfronthosting.co.za>
Message-ID: <1245510852.42.0.472417043973.issue6316@psf.upfronthosting.co.za>


New submission from Jeong-Min Lee <falsetru at gmail.com>:

format(datetime_obj, format_string) return format_string. (when
format_string is not empty.)


>>> import datetime
>>> d = datetime.datetime.now()
>>> format(d)
'2009-06-20 23:51:54.243428'
>>> format(d, '')
'2009-06-20 23:51:54.243428'
>>> d
datetime.datetime(2009, 6, 20, 23, 51, 54, 243428)
>>> '{0}'.format(d)
'2009-06-20 23:51:54.243428'
>>> '{0:30}'.format(d) # odd
'30'
>>> format(d, '30') # odd
'30'
>>> format(str(d), '30') # workaround
'2009-06-20 23:51:54.243428    '
>>> '{0!s:30}'.format(d) # workaround
'2009-06-20 23:51:54.243428    '

----------
components: Extension Modules, Library (Lib)
messages: 89539
nosy: falsetru
severity: normal
status: open
title: format, str.format don't work well with datetime, date object
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Jun 21 03:36:31 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 21 Jun 2009 01:36:31 +0000
Subject: [New-bugs-announce] [issue6317] winsound.PlaySound doesn't accept
	non-unicode string
In-Reply-To: <1245548191.7.0.718565157283.issue6317@psf.upfronthosting.co.za>
Message-ID: <1245548191.7.0.718565157283.issue6317@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

winsound.PlaySound doesn't accept non-unicode string.

Python 3.1rc2+ (py3k, Jun 14 2009, 14:07:51) [MSC v.1200 32 bit (Intel)]
on win3
2
Type "help", "copyright", "credits" or "license" for more information.
>>> import winsound
>>> winsound.PlaySound("?.wav", winsound.SND_LOOP | winsound.SND_ASYNC)

# Rings bell forever.

It's easy to fix this on python3x. I'm not sure this should be fixed in
python2.x, and if should be fixed, probably needs some code like in
posixmodule.c.

  /* try parse args as unicode */
      /* call PlaySoundW */
  /* if fail, try parse args as ascii */
      /* call PlaySoundA */

----------
components: Extension Modules, Windows
files: py3k_winsound.patch
keywords: patch
messages: 89554
nosy: ocean-city
severity: normal
status: open
title: winsound.PlaySound doesn't accept non-unicode string
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14325/py3k_winsound.patch

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

From report at bugs.python.org  Sun Jun 21 08:51:07 2009
From: report at bugs.python.org (Eric)
Date: Sun, 21 Jun 2009 06:51:07 +0000
Subject: [New-bugs-announce] [issue6318] HTMLParser Attributes Containing
	Javascript
In-Reply-To: <1245567067.54.0.00517715480066.issue6318@psf.upfronthosting.co.za>
Message-ID: <1245567067.54.0.00517715480066.issue6318@psf.upfronthosting.co.za>


New submission from Eric <e.rykwalder at gmail.com>:

The line:
n.feed('<a onclick="alert(\\"test\\")">test</a>')

is not matched by the regular expressions for attributes.

----------
components: Library (Lib)
messages: 89555
nosy: ericryk
severity: normal
status: open
title: HTMLParser Attributes Containing Javascript
versions: Python 3.0

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

From report at bugs.python.org  Sun Jun 21 21:10:44 2009
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 21 Jun 2009 19:10:44 +0000
Subject: [New-bugs-announce] [issue6319] bdist_msi runs out of memory for
	large packages
In-Reply-To: <1245611444.58.0.810302302684.issue6319@psf.upfronthosting.co.za>
Message-ID: <1245611444.58.0.810302302684.issue6319@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

Right now, bdist_msi can run out of memory when used for larger
packages. (I found this problem working with NLTK.) The solution is
really simple - just add a db.Commit() so that stuff gets flushed to
disk more often. The attached patch does just that.

I set this as a release blocker because I think shipping Python 3.1 with
a bdist_msi in that doesn't work for large packages is probably a
mistake, and the patch to fix it is small and non-invasive.

----------
assignee: bethard
components: Distutils
files: bdist_msi.patch
keywords: patch
messages: 89575
nosy: bethard
priority: release blocker
severity: normal
stage: patch review
status: open
title: bdist_msi runs out of memory for large packages
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14331/bdist_msi.patch

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

From report at bugs.python.org  Sun Jun 21 21:28:01 2009
From: report at bugs.python.org (jwishnie)
Date: Sun, 21 Jun 2009 19:28:01 +0000
Subject: [New-bugs-announce] [issue6320] Standard string encodings should
	include GSM0.38
In-Reply-To: <1245612481.83.0.685402230855.issue6320@psf.upfronthosting.co.za>
Message-ID: <1245612481.83.0.685402230855.issue6320@psf.upfronthosting.co.za>


New submission from jwishnie <jwishnie at gmail.com>:

The standard string codecs for converting from unicode to strs does not 
include the GSM 0.38 char mapping used by GSM services (like SMS).

I've written a codec for my use based on 'char_mapper' and the skeleton 
from gencodec.py, though it's a little complicated by the fact that the 
GSM encoding is semi-multibyte and not just a straight table look-up.

Gory details here in the comments:
http://www.unicode.org/Public/MAPPINGS/ETSI/GSM0338.TXT

The codec is available here:
http://github.com/jwishnie/pygsm/tree/f574f6db99c585f785f0c73a080814c043
2c6087/pygsm/gsmcodecs

Please consider it, or an optimized/improved version of it, for 
inclusion with the standard codecs distributed with python

----------
components: Unicode
messages: 89576
nosy: jwishnie
severity: normal
status: open
title: Standard string encodings should include GSM0.38
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Mon Jun 22 07:30:20 2009
From: report at bugs.python.org (samwyse)
Date: Mon, 22 Jun 2009 05:30:20 +0000
Subject: [New-bugs-announce] [issue6321] Reload Python modules when running
	programs
In-Reply-To: <1245648620.51.0.901061764952.issue6321@psf.upfronthosting.co.za>
Message-ID: <1245648620.51.0.901061764952.issue6321@psf.upfronthosting.co.za>


New submission from samwyse <samwyse at gmail.com>:

Every time IDLE is asked to run a program, it doesn't ensure that the 
modules referenced by the program are completely loaded.  This can cause 
problems if one of those modules is also being edited, because once it 
is loaded, any subsequent changes are not compiled and re-loaded.  
PyUnit faced a similar problem and solved it with a custom importer 
(http://pyunit.sourceforge.net/notes/reloading.html).  Ideally, the 
custom importer would be used in two places:  The obvious choice is when 
a program is run, unloading when it returns.  The less obvious is when 
the Python Shell window is opened, since import statements can be run 
from there as well.  Closing that window should cause all such imports 
to be unloaded.  Of course, care must be taken to insure that all run 
commands are properly nested within the lifetime of a shell window.

----------
components: IDLE
messages: 89593
nosy: samwyse
severity: normal
status: open
title: Reload Python modules when running programs
type: feature request
versions: Python 3.0

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

From report at bugs.python.org  Mon Jun 22 16:09:14 2009
From: report at bugs.python.org (Andreas Kloeckner)
Date: Mon, 22 Jun 2009 14:09:14 +0000
Subject: [New-bugs-announce] [issue6322] Pdb breakpoints don't work on lines
	without bytecode
In-Reply-To: <1245679754.68.0.982838087844.issue6322@psf.upfronthosting.co.za>
Message-ID: <1245679754.68.0.982838087844.issue6322@psf.upfronthosting.co.za>


New submission from Andreas Kloeckner <inform at tiker.net>:

Take this program:

8< -----------------------------------------------
print "START"

a = [
        1
        for i in range(10)]
8< -----------------------------------------------

as "a.py", run "python -m pdb a.py", say "b 3" to set a breakpoint on
line 3. Say "c" to start execution. Watch the program finish without
ever hitting the breakpoint.

The problem is that line 3 has no bytecode generated for it, so there's
nothing to break on. Pdb should provide feedback in this case. I'm the
author of PuDB, and I've written code to check for this condition Please
feel free to steal that code, here:

http://is.gd/19fvD

----------
components: Library (Lib)
messages: 89597
nosy: inducer
severity: normal
status: open
title: Pdb breakpoints don't work on lines without bytecode
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Mon Jun 22 16:11:47 2009
From: report at bugs.python.org (Andreas Kloeckner)
Date: Mon, 22 Jun 2009 14:11:47 +0000
Subject: [New-bugs-announce] [issue6323] Py3.1 pdb doesn't deal well with
	syntax errors
In-Reply-To: <1245679907.43.0.120493835283.issue6323@psf.upfronthosting.co.za>
Message-ID: <1245679907.43.0.120493835283.issue6323@psf.upfronthosting.co.za>


New submission from Andreas Kloeckner <inform at tiker.net>:

Steps to reprdocue:

1) Debug a program with a syntax error in pdb. 
2) Get the SyntaxError traceback.
3) Hit "q" to quit.
4) Another SyntaxError traceback, and you're back at the Pdb prompt.

----------
components: Library (Lib)
messages: 89599
nosy: inducer
severity: normal
status: open
title: Py3.1 pdb doesn't deal well with syntax errors
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Jun 22 21:27:54 2009
From: report at bugs.python.org (Anthony Foglia)
Date: Mon, 22 Jun 2009 19:27:54 +0000
Subject: [New-bugs-announce] [issue6324] "in" expression falls back to
	__iter__ before __getitem__
In-Reply-To: <1245698874.13.0.640137390853.issue6324@psf.upfronthosting.co.za>
Message-ID: <1245698874.13.0.640137390853.issue6324@psf.upfronthosting.co.za>


New submission from Anthony Foglia <afoglia at gmail.com>:

I was debugging a class where I defined __getitem__ and __iter__, but 
not __contains__.  The documentation describing this case (at the end of 
section 5.9) is old and hasn't been updated for the iterator protocol.

It should read something like:

"For user-defined classes which do not define __contains__() and do 
define __iter__() or __getitem__(), x in y is true if and only if there 
is a value z reachable from iter(y) before iter(y) throws a 
StopIteration exception. (If any other exception is raised, it is as if 
in raised that exception)."

Or something better worded.

(I'm using Python 2.5, but I really doubt things have changes in 2.6 or 
2.7.  I don't know enough about 3.0 to know either way.)

----------
assignee: georg.brandl
components: Documentation
messages: 89607
nosy: afoglia, georg.brandl
severity: normal
status: open
title: "in" expression falls back to __iter__ before __getitem__
versions: Python 2.5, Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Jun 23 06:25:50 2009
From: report at bugs.python.org (Brian Slesinsky)
Date: Tue, 23 Jun 2009 04:25:50 +0000
Subject: [New-bugs-announce] [issue6325] robotparser doesn't handle URL's
	with query strings
In-Reply-To: <1245731150.83.0.504271486523.issue6325@psf.upfronthosting.co.za>
Message-ID: <1245731150.83.0.504271486523.issue6325@psf.upfronthosting.co.za>


New submission from Brian Slesinsky <brian at slesinsky.org>:

If a robots.txt file contains a rule of the form:

  Disallow: /some/path?name=value

This pattern will never match a URL passed to can_fetch(), as far as I
can tell.

It's arguable whether this is a bug. The 1994 robots.txt protocol is
silent on whether to treat query strings specially and just says "any
URL that starts with this value will not be retrieved". The 1997 draft
standard talks about the path portion of a URL but doesn't give any
examples about how to treat the '?' character in a robots.txt pattern.

Google extends the protocol to allow wildcard characters in a way that
doesn't treat the '?' character specially. See:
http://www.google.com/support/webmasters/bin/answer.py?answer=40360&cbid=-1rdq1gi8f11xx&src=cb&lev=answer#3

I'll leave aside whether to implement pattern matching, but it seems
like a good idea to do something reasonable when a robots.txt pattern
contains a literal '?', and treating it as a literal character seems
simplest.

Cause: in robotparser.can_fetch(), there is this code which seems to
take only the path (stripping the query string).

 url = urllib.quote(urlparse.urlparse(urllib.unquote(url))[2]) or "/"

Also, when parsing patterns in the robots.txt file, a '?' character
seems to be automatically URL-escaped. There's nothing in a standards
doc about doing this so I think that might be a bug too.

Tested with python 2.4. I looked at the code in Subversion head and it
doesn't look like there were any changes on the trunk.

----------
components: Library (Lib)
messages: 89622
nosy: skybrian
severity: normal
status: open
title: robotparser doesn't handle URL's with query strings
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Jun 23 15:12:49 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 23 Jun 2009 13:12:49 +0000
Subject: [New-bugs-announce] [issue6326] Add a "swap" method to list
In-Reply-To: <1245762769.52.0.940605508616.issue6326@psf.upfronthosting.co.za>
Message-ID: <1245762769.52.0.940605508616.issue6326@psf.upfronthosting.co.za>


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

It is sometimes useful to be able to swap the contents of two lists and 
this patch provides a way to do so using the fastest way possible.

> a = [1, 2]
> b = [3]
> id(a), id(b)
(100, 101)
> a.swap(b)
> a
[3]
> b
[1, 2]
> id(a), id(b)
(100, 101)

One application of this is to make help a performance problem when one 
wants to upgrade a list instance into a subclass instance.
orglist = rawlist_from_server()
mylist = ListSubclass(orglist)

This involves copying duplicating the list, and then discarding, which 
can take a while for long lists.  Much faster is using>
mylist = ListSubclass()
mulist.swap(orglist)

We are using this extension within CCP to decoratate database queries 
from our database engine, that are returned as python lists.  The 
performance gained by shaving off this extra list duplication can be 
significant for large data sets.
to change a list, into a

----------
components: Interpreter Core
files: listswap.patch
keywords: patch, patch
messages: 89626
nosy: krisvale
severity: normal
status: open
title: Add a "swap" method to list
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file14341/listswap.patch

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

From report at bugs.python.org  Tue Jun 23 16:33:07 2009
From: report at bugs.python.org (Martijn Otto)
Date: Tue, 23 Jun 2009 14:33:07 +0000
Subject: [New-bugs-announce] [issue6327] [mimetext] long lines get cut with
	exclamation mark and	newline
In-Reply-To: <1245767587.65.0.844328731918.issue6327@psf.upfronthosting.co.za>
Message-ID: <1245767587.65.0.844328731918.issue6327@psf.upfronthosting.co.za>


New submission from Martijn Otto <martijntje at gmail.com>:

When using mimetext, long lines are cut at character 990, at which place
an exclamation mark, a newline and a space are inserted. After this the
line continues... For example, this line:

000000000148                                                           
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
                                   0220090622N0   K.        de       
Boer                                                                     
                                                                  
Badhuisstraat                      36                                       
         2012 CPHAARLEM                            NED20090622       
1500     628215290           19030201keesdeboerisdebeste at hotmail.com     
              0123456789  

will get changed to

000000000148                                                           
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
                               0220090622N0   K.        de        Boer 
                                                                       
                                                             
Badhuisstraat                      36                                  
             2012 CPHAARLEM                            NED20090622     
  1500     628215290           19030201keesdeboerisdebeste at hotm!
 ail.com                   0123456789

----------
messages: 89627
nosy: martijntje
severity: normal
status: open
title: [mimetext] long lines get cut with exclamation mark and newline
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue Jun 23 18:05:26 2009
From: report at bugs.python.org (Gehua Yang)
Date: Tue, 23 Jun 2009 16:05:26 +0000
Subject: [New-bugs-announce] [issue6328] login() function failed in smtplib
	with message "argument	1 must be bytes or buffer, not str"
In-Reply-To: <1245773126.97.0.509080047972.issue6328@psf.upfronthosting.co.za>
Message-ID: <1245773126.97.0.509080047972.issue6328@psf.upfronthosting.co.za>


New submission from Gehua Yang <yanggehua at gmail.com>:

Hi folks,

I encountered the following error with this Python code snippet. (I ran
it with Python 3.0.1). Judging from the error as shown in IDLE debugger,
the error was buried inside python. 

  try:
    server = smtplib.SMTP(EmailConfig.smtpServerName)
    server.set_debuglevel(3)
    print(server)
    server.login(bytes(EmailConfig.mailUser, encoding='ascii'),
bytes(EmailConfig.mailPass, encoding='ascii'))
    print('Login is successful.')
    failed = server.sendmail(from_addr, to_addr, text_msg)
  except Exception as ex:
    print('Error in communicating with SMTP server', ex)
  else:
    if failed : print('Failed in sending email with following
reason:\n', failed)


***********************************************
The output from terminal is:
$ c:/tools/Python30/python send_email.py
<smtplib.SMTP object at 0x00F21990>
send: 'ehlo quad-vision.hua\r\n'
reply: b'250-smtp.mxes.net\r\n'
reply: b'250-PIPELINING\r\n'
reply: b'250-SIZE 400000000\r\n'
reply: b'250-ETRN\r\n'
reply: b'250-STARTTLS\r\n'
reply: b'250-AUTH PLAIN LOGIN\r\n'
reply: b'250-AUTH=PLAIN LOGIN\r\n'
reply: b'250-ENHANCEDSTATUSCODES\r\n'
reply: b'250-8BITMIME\r\n'
reply: b'250 DSN\r\n'
reply: retcode (250); Msg: b'smtp.mxes.net\nPIPELINING\nSIZE
400000000\nETRN\nSTARTTLS\nAUTH PLAIN L
OGIN\nAUTH=PLAIN LOGIN\nENHANCEDSTATUSCODES\n8BITMIME\nDSN'
Error in communicating with SMTP server b2a_base64() argument 1 must be
bytes or buffer, not str

----------
files: python-shot.png
messages: 89629
nosy: hdvision
severity: normal
status: open
title: login() function failed in smtplib with message "argument 1 must be bytes or buffer, not str"
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file14342/python-shot.png

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

From report at bugs.python.org  Tue Jun 23 20:40:02 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Jun 2009 18:40:02 +0000
Subject: [New-bugs-announce] [issue6329] Fix iteration for memoryviews
In-Reply-To: <1245782402.41.0.142582030858.issue6329@psf.upfronthosting.co.za>
Message-ID: <1245782402.41.0.142582030858.issue6329@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

Despite being a sequence (with both __getitem__ and __len__ defined),
memoryview objects were not recognized as being iterable.  The docs say
that all such sequences are iterable, so this is a bug.

>>> b = b'abcde'
>>> m = memoryview(b)
>>> list(m)
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    list(m)
TypeError: 'memoryview' object is not iterable

The underlying problem is that the __getitem__ method is listed in the
as_mapping section instead of as_sequence.  This was necessary so that
the ellipsis could be supported (the mapping version accepts arbitrary
objects while the sequence version only accepts integer indices). 
Unfortunately, the logic for Objects/abstract.c::PySeq_Iter() expects to
find the getitem defined in s->ob_type->tp_as_sequence->sq_item slot.  

This patch attaches the appropriate code in that slot.  The code is a
simple cut and paste from the more general memory_subscript() function
listed just above.

----------
assignee: r.david.murray
components: Interpreter Core
files: mview.diff
keywords: patch
messages: 89637
nosy: r.david.murray, rhettinger
priority: high
severity: normal
stage: patch review
status: open
title: Fix iteration for memoryviews
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file14344/mview.diff

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

From report at bugs.python.org  Tue Jun 23 20:57:09 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 23 Jun 2009 18:57:09 +0000
Subject: [New-bugs-announce] [issue6330] trunk does not build with
	--enable-unicode=ucs4
In-Reply-To: <1245783429.44.0.152732934194.issue6330@psf.upfronthosting.co.za>
Message-ID: <1245783429.44.0.152732934194.issue6330@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

This was reported a few weeks ago by Benjamin Peterson, but I haven't
gotten around to fixing it. This is a reminder to myself to do it.

This is due to a bug in Objects/stringlib/formatter.h. Before I fix it
trunk, I need to backport some 3.1 code to keep the implementations in sync.

----------
assignee: eric.smith
components: Interpreter Core
keywords: easy
messages: 89640
nosy: eric.smith
severity: normal
status: open
title: trunk does not build with --enable-unicode=ucs4
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Tue Jun 23 22:50:59 2009
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Tue, 23 Jun 2009 20:50:59 +0000
Subject: [New-bugs-announce] [issue6331] Add unicode script info to the
	unicode database
In-Reply-To: <1245790259.44.0.08771310344.issue6331@psf.upfronthosting.co.za>
Message-ID: <1245790259.44.0.08771310344.issue6331@psf.upfronthosting.co.za>


New submission from Walter D?rwald <walter at livinglogic.de>:

This patch adds a function unicodedata.script() that returns information
about the script of the Unicode character.

----------
components: Unicode
files: unicode-script.diff
keywords: patch
messages: 89642
nosy: doerwalter
severity: normal
status: open
title: Add unicode script info to the unicode database
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file14348/unicode-script.diff

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

From report at bugs.python.org  Tue Jun 23 23:22:09 2009
From: report at bugs.python.org (Lie Ryan)
Date: Tue, 23 Jun 2009 21:22:09 +0000
Subject: [New-bugs-announce] [issue6332] typo on man page warning control
In-Reply-To: <1245792129.32.0.2769542898.issue6332@psf.upfronthosting.co.za>
Message-ID: <1245792129.32.0.2769542898.issue6332@psf.upfronthosting.co.za>


New submission from Lie Ryan <lie.1296 at gmail.com>:

A minor typo on the man page

> -W argument
> ...
> such as inside a loop); module to print each warning *only only*
> ...

----------
assignee: georg.brandl
components: Documentation
files: onlyonly.diff
keywords: patch
messages: 89645
nosy: georg.brandl, lieryan
severity: normal
status: open
title: typo on man page warning control
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file14349/onlyonly.diff

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

From report at bugs.python.org  Wed Jun 24 03:42:48 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 24 Jun 2009 01:42:48 +0000
Subject: [New-bugs-announce] [issue6333] logging: ValueError: I/O operation
	on closed file
In-Reply-To: <1245807768.39.0.536701423847.issue6333@psf.upfronthosting.co.za>
Message-ID: <1245807768.39.0.536701423847.issue6333@psf.upfronthosting.co.za>


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

The logging module has a bug that tries to call `flush' on a closed 
file handle (sys.std[out|err] to be specific). This bug was introduced 
by ConsoleHandler as defined in http://code.activestate.com/
recipes/576819/

The fix is simple: change definition of StreamHandler.flush in logging/
__init__.py to:

  def flush(self):
      if self.stream and hasattr(self.stream, 'flush') and not 
self.stream.closed:
          logging.StreamHandler.flush()

----------
components: Library (Lib)
messages: 89653
nosy: srid
severity: normal
status: open
title: logging: ValueError: I/O operation on closed file
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Jun 24 12:51:43 2009
From: report at bugs.python.org (Markus F.X.J. Oberhumer)
Date: Wed, 24 Jun 2009 10:51:43 +0000
Subject: [New-bugs-announce] [issue6334] 3.0/3.1: Bad bug in range()
	computation (or possible	Integer problem)
In-Reply-To: <1245840703.27.0.965976477326.issue6334@psf.upfronthosting.co.za>
Message-ID: <1245840703.27.0.965976477326.issue6334@psf.upfronthosting.co.za>


New submission from Markus F.X.J. Oberhumer <markus at oberhumer.com>:

Please note that the correct answer is 25, and the last element is missing !

This bug does not show on 64-bit versions (but 46337**2 is near 2**31).

~Markus


C:\Python31>python
Python 3.1rc2 (r31rc2:73414, Jun 13 2009, 16:43:15) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> len(list(range(46337**2, 46349**2, 46337)))
24

C:\Python30>python.exe
Python 3.0.1 (r301:69561, Feb 13 2009, 20:04:18) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> len(list(range(46337**2, 46349**2, 46337)))
24

----------
components: Interpreter Core
messages: 89660
nosy: mfxmfx
severity: normal
status: open
title: 3.0/3.1: Bad bug in range() computation (or possible Integer problem)
type: behavior
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Wed Jun 24 15:10:42 2009
From: report at bugs.python.org (smartmobili)
Date: Wed, 24 Jun 2009 13:10:42 +0000
Subject: [New-bugs-announce] [issue6335] Add support for mingw
In-Reply-To: <1245849042.65.0.399048729588.issue6335@psf.upfronthosting.co.za>
Message-ID: <1245849042.65.0.399048729588.issue6335@psf.upfronthosting.co.za>


New submission from smartmobili <forumer at smartmobili.com>:

Hi,

I can see that python still doesn't support mingw environnment whil
during past years some people provided some patch.
I wanted recently to compile Python-3.0.1 on mingw and I have found a
patch in a svn repository of a opensource project(don't remember which
one)- So I attach it and I hope it will studied by python dev.
Generally it's not very difficult, you should add some #ifdef
__MINGW32__ when needeed and hack around these lines.
Don't understand you still don't support it.

So this patch is a first step because it doesn't work very well, I mean
I had to copy manually errmap.h from PC to include folder.
And after I get an issue :

gcc -L/usr/local/lib  -o python.exe \
                Modules/python.o \
                libpython3.0.a    -lm
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Fatal Python error: Py_Initialize: can't initialize sys standard streams
ImportError: No module named encodings.utf_8

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
make: *** [sharedmods] Error 3

----------
components: Build
files: python3-mingw.patch
keywords: patch
messages: 89663
nosy: smartmobili
severity: normal
status: open
title: Add support for mingw
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file14353/python3-mingw.patch

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

From report at bugs.python.org  Wed Jun 24 15:12:17 2009
From: report at bugs.python.org (Floris Bruynooghe)
Date: Wed, 24 Jun 2009 13:12:17 +0000
Subject: [New-bugs-announce] [issue6336] nb_divide missing in docs
In-Reply-To: <1245849137.7.0.528327337133.issue6336@psf.upfronthosting.co.za>
Message-ID: <1245849137.7.0.528327337133.issue6336@psf.upfronthosting.co.za>


New submission from Floris Bruynooghe <floris.bruynooghe at gmail.com>:

http://docs.python.org/c-api/typeobj.html#number-object-structures is
missing the entry for nb_divide, this is confusing.

----------
assignee: georg.brandl
components: Documentation
messages: 89664
nosy: flub, georg.brandl
severity: normal
status: open
title: nb_divide missing in docs
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Jun 24 16:32:45 2009
From: report at bugs.python.org (Alexey Akimov)
Date: Wed, 24 Jun 2009 14:32:45 +0000
Subject: [New-bugs-announce] [issue6337] multiprocessing module: Double
	close of sys.stdin - ID:	2811568
In-Reply-To: <1245853965.54.0.75551607338.issue6337@psf.upfronthosting.co.za>
Message-ID: <1245853965.54.0.75551607338.issue6337@psf.upfronthosting.co.za>


New submission from Alexey Akimov <subdir at gmail.com>:

Double close of FD 0 when child process spawns its own child process.
Bug causes wrong file descriptors to be closed.
Bug affects only posix system.

How to reproduce:

>>> import multiprocessing as mp
>>> def child(q):
... print 'current process:', mp.current_process().name
... q.put(1)
... q.get()
... p = mp.Process(None, child, args=(mp.Queue(),))
... p.start()
...
>>> q = mp.Queue()
>>> child(q)
current process: MainProcess
current process: Process-1
current process: Process-1:1
Process Process-1:1:
Traceback (most recent call last):
File "/usr/lib/python2.5/site-packages/multiprocessing/process.py", line
236, in _bootstrap
self.run()
File "/usr/lib/python2.5/site-packages/multiprocessing/process.py", line
93, in run
self._target(*self._args, **self._kwargs)
File "<stdin>", line 4, in child
File "/usr/lib/python2.5/site-packages/multiprocessing/queues.py", line
91, in get
res = self._recv()
IOError: [Errno 9] Bad file descriptor

----------
components: Extension Modules, Library (Lib)
files: multiprocessing.patch
keywords: patch
messages: 89666
nosy: subdir
severity: normal
status: open
title: multiprocessing module: Double close of sys.stdin - ID: 2811568
versions: Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14354/multiprocessing.patch

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

From martin at v.loewis.de  Wed Jun 24 21:10:16 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 24 Jun 2009 21:10:16 +0200
Subject: [New-bugs-announce] [issue6335] Add support for mingw
In-Reply-To: <1245849042.65.0.399048729588.issue6335@psf.upfronthosting.co.za>
References: <1245849042.65.0.399048729588.issue6335@psf.upfronthosting.co.za>
Message-ID: <4A427A18.3030004@v.loewis.de>

> Don't understand you still don't support it.

Primarily because the patches that have been contributed don't work
well. We see no point in adding patches that don't work, and prefer
to add only patches that actually do work.

From report at bugs.python.org  Wed Jun 24 23:08:29 2009
From: report at bugs.python.org (Eric Huss)
Date: Wed, 24 Jun 2009 21:08:29 +0000
Subject: [New-bugs-announce] [issue6338] Error message displayed on stderr
	when no C compiler is	present with ctypes
In-Reply-To: <1245877709.89.0.124582375066.issue6338@psf.upfronthosting.co.za>
Message-ID: <1245877709.89.0.124582375066.issue6338@psf.upfronthosting.co.za>


New submission from Eric Huss <eric at huss.org>:

Importing the "uuid" module on a posix system (FreeBSD in my case) that
does not have a C compiler causes "cc: not found" to be sent to stderr.
 This is because it imports ctypes and calls ctypes.util.find_library
which attempts to determine if the C compiler is called "gcc" or "cc"
using a shell command.

----------
assignee: theller
components: ctypes
files: ctypes_util.patch
keywords: patch
messages: 89681
nosy: ehuss, theller
severity: normal
status: open
title: Error message displayed on stderr when no C compiler is present with ctypes
versions: Python 2.6
Added file: http://bugs.python.org/file14357/ctypes_util.patch

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

From report at bugs.python.org  Wed Jun 24 23:24:30 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Wed, 24 Jun 2009 21:24:30 +0000
Subject: [New-bugs-announce] [issue6339] Some functional errors in turtle.py
	documentation	(missing links)
In-Reply-To: <1245878670.95.0.838166352982.issue6339@psf.upfronthosting.co.za>
Message-ID: <1245878670.95.0.838166352982.issue6339@psf.upfronthosting.co.za>


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

In the Python3.1rc2 documentation for turtle.py there are the following
functional errors:

In the overview section the (newly added) entries for the functions/methods 

shearfactor
get_shapepoly
onkeypress
numinput

do not have links to the corresponding text sections. These exist but
also have errors, sometimes the leading 'turtle.' is missing, sometimes
the parameter self erroneously appears in the text.

I'm not very educated in restructured Text Syntax respectively the
documentatin system. Nevertheless I inspected the source and I assume
the following causes for this:

In the first lines of the sections for shearfactor and numinput there
are superfluous self, which should be deleted.

In the sections for get_shapepoly, onkeypress and numinput there are
perturbing colons at the end of the first lines, which perhaps should be
deleted.

As I'm not sure if this suggestions are right and/or comlete and I do
not have any means to test them, I cannot submit a patch. 

Please could some docs-guru check my suggestions (and possibly repair
the defects) It would be fine if this errors wouldn't appear in 3.1

Regards,
Gregor

----------
assignee: georg.brandl
components: Documentation
messages: 89682
nosy: georg.brandl, gregorlingl, loewis
severity: normal
status: open
title: Some functional errors in turtle.py documentation (missing links)
versions: Python 3.1

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

From report at bugs.python.org  Thu Jun 25 00:45:20 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Wed, 24 Jun 2009 22:45:20 +0000
Subject: [New-bugs-announce] [issue6340] replace tdemo_chaos.py
In-Reply-To: <1245883520.56.0.469281631359.issue6340@psf.upfronthosting.co.za>
Message-ID: <1245883520.56.0.469281631359.issue6340@psf.upfronthosting.co.za>


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

I've submitted a replacement, which is functionally 100% equivalent,
but cleaner code, more appropriate for a demo:

four or five superfluous lines, which were remains from some previous
version are deleted now; names and comments are now in English.

Regards,
Gregor

----------
components: Demos and Tools
files: tdemo_chaos.py
messages: 89686
nosy: georg.brandl, gregorlingl, loewis
severity: normal
status: open
title: replace tdemo_chaos.py
versions: Python 3.1
Added file: http://bugs.python.org/file14358/tdemo_chaos.py

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

From report at bugs.python.org  Thu Jun 25 14:56:45 2009
From: report at bugs.python.org (Georgios Moralis)
Date: Thu, 25 Jun 2009 12:56:45 +0000
Subject: [New-bugs-announce] [issue6341] io.path.ismount gives "local
	variable 'p' referenced	before assignment" error on Windows
	versions (ntpath.py)
In-Reply-To: <1245934605.11.0.579466844028.issue6341@psf.upfronthosting.co.za>
Message-ID: <1245934605.11.0.579466844028.issue6341@psf.upfronthosting.co.za>


New submission from Georgios Moralis <g.mwralhs at gmail.com>:

It returns with the following error:
UnboundLocalError: local variable 'p' referenced before assignment

Example causing this:


--- CODE FOLLOWS ---

import os

def show_cwd_list():
    alpha = os.listdir(os.getcwd())
    for dirnm in alpha[:]:
        if os.path.isdir(os.getcwd() + os.sep + dirnm):
            print("d ", dirnm)
        elif os.path.ismount(os.getcwd() + os.sep + dirnm):
            print("m ", dirnm)
        elif os.path.isfile(os.getcwd() + os.sep + dirnm):
            print("f ", dirnm)
        elif os.path.islink(os.getcwd() + os.sep + dirnm):
            print("l ", dirnm)
        elif os.path.isabs(os.getcwd() + os.sep + dirnm):
            print("a ", dirnm)
    return alpha

get_dirs()

--- END OF CODE ---

The definition of ismount from the ntpath.py:


--- CODE FOLLOWS (NTPATH.PY) ---
def ismount(path):
    """Test whether a path is a mount point (defined as root of drive)"""
    unc, rest = splitunc(path)
    seps = _get_bothseps(p)
    if unc:
        return rest in p[:0] + seps
    p = splitdrive(path)[1]
    return len(p) == 1 and p[0] in seps

--- END OF CODE ---

As it seems, variable 'p' is used before it is initialized (_get_bothseps)

----------
components: Windows
messages: 89704
nosy: g.moralis
severity: normal
status: open
title: io.path.ismount  gives "local variable 'p' referenced before assignment" error on Windows versions (ntpath.py)
type: compile error
versions: Python 3.0

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

From report at bugs.python.org  Thu Jun 25 14:56:46 2009
From: report at bugs.python.org (Georgios Moralis)
Date: Thu, 25 Jun 2009 12:56:46 +0000
Subject: [New-bugs-announce] [issue6342] io.path.ismount gives "local
	variable 'p' referenced	before assignment" error on Windows
	versions (ntpath.py)
In-Reply-To: <1245934606.89.0.398101008179.issue6342@psf.upfronthosting.co.za>
Message-ID: <1245934606.89.0.398101008179.issue6342@psf.upfronthosting.co.za>


New submission from Georgios Moralis <g.mwralhs at gmail.com>:

It returns with the following error:
UnboundLocalError: local variable 'p' referenced before assignment

Example causing this:


--- CODE FOLLOWS ---

import os

def show_cwd_list():
    alpha = os.listdir(os.getcwd())
    for dirnm in alpha[:]:
        if os.path.isdir(os.getcwd() + os.sep + dirnm):
            print("d ", dirnm)
        elif os.path.ismount(os.getcwd() + os.sep + dirnm):
            print("m ", dirnm)
        elif os.path.isfile(os.getcwd() + os.sep + dirnm):
            print("f ", dirnm)
        elif os.path.islink(os.getcwd() + os.sep + dirnm):
            print("l ", dirnm)
        elif os.path.isabs(os.getcwd() + os.sep + dirnm):
            print("a ", dirnm)
    return alpha

get_dirs()

--- END OF CODE ---

The definition of ismount from the ntpath.py:


--- CODE FOLLOWS (NTPATH.PY) ---
def ismount(path):
    """Test whether a path is a mount point (defined as root of drive)"""
    unc, rest = splitunc(path)
    seps = _get_bothseps(p)
    if unc:
        return rest in p[:0] + seps
    p = splitdrive(path)[1]
    return len(p) == 1 and p[0] in seps

--- END OF CODE ---

As it seems, variable 'p' is used before it is initialized (_get_bothseps)

----------
components: Windows
messages: 89705
nosy: g.moralis
severity: normal
status: open
title: io.path.ismount  gives "local variable 'p' referenced before assignment" error on Windows versions (ntpath.py)
type: compile error
versions: Python 3.0

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

From report at bugs.python.org  Thu Jun 25 18:59:45 2009
From: report at bugs.python.org (Dale Nagata)
Date: Thu, 25 Jun 2009 16:59:45 +0000
Subject: [New-bugs-announce] [issue6343] TimedRotatingFileHandler permission
	denied rename failure	on Windows
In-Reply-To: <1245949185.33.0.897995880567.issue6343@psf.upfronthosting.co.za>
Message-ID: <1245949185.33.0.897995880567.issue6343@psf.upfronthosting.co.za>


New submission from Dale Nagata <nagata at telus.net>:

Traceback (most recent call last):
  File "C:\python24\lib\logging\handlers.py", line 74, in emit
    self.doRollover()
  File "C:\python24\lib\logging\handlers.py", line 271, in doRollover
    os.rename(self.baseFilename, dfn)
OSError: [Errno 13] Permission denied

originally hit on W2K3 but could not see evidence as it was running as a
service with stderr not going anywhere, but deeply suspicious since it
failed right at midnight each time. 

whittled down to bare essentials, repro'd on XP running in console
window, test case will fail in 2 min when rollover is attempted

logging set up as follows:

def initlog():
    #h = logging.handlers.TimedRotatingFileHandler( LOGFILEPATH,
'MIDNIGHT', 1, 7 )
    h = logging.handlers.TimedRotatingFileHandler( LOGFILEPATH, 'M', 2, 7 )
    h.setLevel( logging.DEBUG )
    f = logging.Formatter( '%(asctime)s %(levelname)s %(message)s',
'%Y-%m-%d %H:%M:%S' )
    h.setFormatter( f )
    logging.root.addHandler( h )
    logging.root.setLevel( logging.DEBUG )

searched issue tracker for TimedRotatingFileHandler, no hits

----------
components: Library (Lib)
files: testlog.py
messages: 89711
nosy: dnagata
severity: normal
status: open
title: TimedRotatingFileHandler permission denied rename failure on Windows
type: crash
versions: Python 2.4
Added file: http://bugs.python.org/file14365/testlog.py

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

From report at bugs.python.org  Thu Jun 25 23:22:28 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 25 Jun 2009 21:22:28 +0000
Subject: [New-bugs-announce] [issue6344] mmap.read() crashes when passed a
	negative argument
In-Reply-To: <1245964948.96.0.802532537301.issue6344@psf.upfronthosting.co.za>
Message-ID: <1245964948.96.0.802532537301.issue6344@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

mmap.read() crashes when passed a negative count:

    def test_read_negative(self):
        f = open(TESTFN, 'w+')
        f.write("ABCDE\0abcde")
        f.flush()

        mf = mmap.mmap(f.fileno(), 0)

        self.assertEqual(mf.read(2),  "AB")    # OK
        self.assertEqual(mf.read(-1), "CDE")   # ??
        self.assertEqual(mf.read(-1), "BCDE")  # ??
        self.assertEqual(mf.read(-1), "ABCDE") # ??
        mf.read(-1)                            # crash!!

I don't know what mf.read(-1) should do: raise a ValueError, return the empty 
string, or return everything from the current pos to len(mf)?

----------
components: Library (Lib)
messages: 89714
nosy: amaury.forgeotdarc, ocean-city
priority: high
severity: normal
status: open
title: mmap.read() crashes when passed a negative argument
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun 26 04:20:30 2009
From: report at bugs.python.org (Mark Tolonen)
Date: Fri, 26 Jun 2009 02:20:30 +0000
Subject: [New-bugs-announce] [issue6345] extra characters displayed when
	writing to	sys.stdout.buffer
In-Reply-To: <1245982830.09.0.978078619889.issue6345@psf.upfronthosting.co.za>
Message-ID: <1245982830.09.0.978078619889.issue6345@psf.upfronthosting.co.za>


New submission from Mark Tolonen <metolone at hotmail.com>:

According to Issue xxxx, sys.stdout.buffer is the binary stream 
underlying stdout.  I see the following behavior on 3.0.1 and 3.1rc2 
when writing to a console window:

Python 3.1rc2 (r31rc2:73414, Jun 13 2009, 16:43:15) [MSC v.1500 32 bit 
(Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> 
sys.stdout.buffer.write('hello\u200bworld'.encode('cp437','replace'))
hello?world11

Notice the extra '11' at the end of the string.

----------
components: IO
messages: 89719
nosy: metolone
severity: normal
status: open
title: extra characters displayed when writing to sys.stdout.buffer
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Fri Jun 26 20:58:20 2009
From: report at bugs.python.org (Matt Kubilus)
Date: Fri, 26 Jun 2009 18:58:20 +0000
Subject: [New-bugs-announce] [issue6346] Rstrip Incorrectly Strips Some
	Strings
In-Reply-To: <1246042700.02.0.587103805178.issue6346@psf.upfronthosting.co.za>
Message-ID: <1246042700.02.0.587103805178.issue6346@psf.upfronthosting.co.za>


New submission from Matt Kubilus <kubilus1 at yahoo.com>:

Rstrip has unexpected behavior with some strings.  Example:

-----

>>> "proxa.py".rstrip(".py")
'proxa'
>>> "proxy.py".rstrip(".py")
'prox'

-----

Tested with Python 2.6.1

----------
components: Library (Lib)
messages: 89736
nosy: mkubilus
severity: normal
status: open
title: Rstrip Incorrectly Strips Some Strings
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Jun 27 01:46:16 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 26 Jun 2009 23:46:16 +0000
Subject: [New-bugs-announce] [issue6347] hpux11.00-parisc: dtoa.c: "Failed
	to find an exact-width	32-bit integer type"
In-Reply-To: <1246059976.81.0.366952581709.issue6347@psf.upfronthosting.co.za>
Message-ID: <1246059976.81.0.366952581709.issue6347@psf.upfronthosting.co.za>


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

(...)
cc +DAportable -Ae -D_REENTRANT +Z -c  -DNDEBUG -O  -I. -IInclude -I./
Include   -DPy_BUILD_CORE -o Python/pystrtod.o Python/pystrtod.c
cc +DAportable -Ae -D_REENTRANT +Z -c  -DNDEBUG -O  -I. -IInclude -I./
Include   -DPy_BUILD_CORE -o Python/dtoa.o Python/dtoa.c
cpp: "Python/dtoa.c", line 158: error 4062: "Failed to find an exact-
width 32-bit integer type"
make: *** [Python/dtoa.o] Error 1

Entire build log is attached (just look at the configure/make output of 
Python).

----------
components: Build
files: apy31-hpux11.00-parisc-bertha.log
messages: 89748
nosy: srid
severity: normal
status: open
title: hpux11.00-parisc: dtoa.c: "Failed to find an exact-width 32-bit integer type"
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file14367/apy31-hpux11.00-parisc-bertha.log

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

From report at bugs.python.org  Sat Jun 27 01:49:22 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 26 Jun 2009 23:49:22 +0000
Subject: [New-bugs-announce] [issue6348] solaris/aix: Py_Initialize: can't
	initialize sys standard	streams
In-Reply-To: <1246060162.58.0.439928346048.issue6348@psf.upfronthosting.co.za>
Message-ID: <1246060162.58.0.439928346048.issue6348@psf.upfronthosting.co.za>


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

I wonder which commit introduced this regression which used to work 
before (I think till rc1).

This error occurs on solaris10-x86, solaris8-sparc, solaris8-sparc64 
and aix5-powerpc.

(...)
ranlib libpython3.1.a
cc   -o python \
                Modules/python.o \
                libpython3.1.a -lresolv -lsocket -lnsl -lintl -lrt -
ldl   -lm  
Fatal Python error: Py_Initialize: can't initialize sys standard streams
IOError: [Errno 29] Illegal seek
*** Error code 134
The following command caused the error:
case $MAKEFLAGS in \
*s*)  CC='cc' LDSHARED='cc -G' OPT='-DNDEBUG -O' ./python -E ./setup.py 
-q build;; \
*)  CC='cc' LDSHARED='cc -G' OPT='-DNDEBUG -O' ./python -E ./setup.py 
build;; \
esac
make: Fatal error: Command failed for target `sharedmods'


Entire build log (solaris10-x86) is attached.

----------
components: Build
files: apy31-ginsu.log
messages: 89749
nosy: srid
severity: normal
status: open
title: solaris/aix: Py_Initialize: can't initialize sys standard streams
type: crash
versions: Python 3.1
Added file: http://bugs.python.org/file14368/apy31-ginsu.log

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

From report at bugs.python.org  Sat Jun 27 23:16:28 2009
From: report at bugs.python.org (David Bremner)
Date: Sat, 27 Jun 2009 21:16:28 +0000
Subject: [New-bugs-announce] [issue6349] email.Maildir cannot roundtrip
	messages.
In-Reply-To: <1246137388.38.0.130457686116.issue6349@psf.upfronthosting.co.za>
Message-ID: <1246137388.38.0.130457686116.issue6349@psf.upfronthosting.co.za>


New submission from David Bremner <bremner at unb.ca>:

if mailbox is an email.Maildir object  the following lines 
cause an exception for me.

for key in mailbox.keys():
	msg=mailbox[key]
        mailbox[key]=msg

I attach the whole script. I'm happy to send a tar file of the maildir
I used to test with.

----------
files: test.py
messages: 89754
nosy: bremner
severity: normal
status: open
title: email.Maildir cannot roundtrip messages.
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14371/test.py

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

From report at bugs.python.org  Sat Jun 27 23:34:07 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 27 Jun 2009 21:34:07 +0000
Subject: [New-bugs-announce] [issue6350] Example at end of HTMLParser
	documentation uses old-style	print syntax
In-Reply-To: <1246138447.18.0.57026515802.issue6350@psf.upfronthosting.co.za>
Message-ID: <1246138447.18.0.57026515802.issue6350@psf.upfronthosting.co.za>


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

Change the print statements in the example at the bottom of the
documentation for HTMLParser to function calls.

----------
assignee: georg.brandl
components: Documentation
messages: 89755
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Example at end of HTMLParser documentation uses old-style print syntax
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Jun 28 05:25:41 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sun, 28 Jun 2009 03:25:41 +0000
Subject: [New-bugs-announce] [issue6351] Compiler warning in _cursesmodule.c
In-Reply-To: <1246159541.88.0.944376557705.issue6351@psf.upfronthosting.co.za>
Message-ID: <1246159541.88.0.944376557705.issue6351@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

My gcc complains that the variables x and y might be used uninitialized
in the function PyCurses_getsyx in Modules/_cursesmodule.c. This is
because the macro getsyx of curses.h apparently only sets x and y if
newscr is not NULL. There seems to have been a related discussion last year:

http://mail.python.org/pipermail/python-dev/2008-March/077496.html

----------
components: Build
messages: 89763
nosy: hagen
severity: normal
status: open
title: Compiler warning in _cursesmodule.c
versions: Python 3.1

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

From report at bugs.python.org  Sun Jun 28 05:57:55 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sun, 28 Jun 2009 03:57:55 +0000
Subject: [New-bugs-announce] [issue6352] Compiler warning in unicodeobject.c
In-Reply-To: <1246161475.84.0.16800767496.issue6352@psf.upfronthosting.co.za>
Message-ID: <1246161475.84.0.16800767496.issue6352@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

Compiling --with-wide-unicode there's a warning that encodeUCS4 is
defined, but not used. A trivial patch for this is attached.

----------
files: warning.patch
keywords: patch
messages: 89764
nosy: hagen
severity: normal
status: open
title: Compiler warning in unicodeobject.c
versions: Python 3.1
Added file: http://bugs.python.org/file14373/warning.patch

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

From report at bugs.python.org  Sun Jun 28 09:55:05 2009
From: report at bugs.python.org (Pierre Bourdon)
Date: Sun, 28 Jun 2009 07:55:05 +0000
Subject: [New-bugs-announce] [issue6353] "L" integer suffix in Python 3.1
	tutorial
In-Reply-To: <1246175705.48.0.727392252197.issue6353@psf.upfronthosting.co.za>
Message-ID: <1246175705.48.0.727392252197.issue6353@psf.upfronthosting.co.za>


New submission from Pierre Bourdon <root at delroth.is-a-geek.org>:

Chapter 14 (Floating Point Arithmetic: Issues and Limitations) of the
Python 3.x tutorial contains integers with long suffix (424242L) when
talking about as_integer_ratio.

Patch is attached.

----------
assignee: georg.brandl
components: Documentation
files: fp-tutorial.diff
keywords: patch
messages: 89767
nosy: delroth, georg.brandl
severity: normal
status: open
title: "L" integer suffix in Python 3.1 tutorial
versions: Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14374/fp-tutorial.diff

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

From report at bugs.python.org  Sun Jun 28 09:58:46 2009
From: report at bugs.python.org (Pierre Bourdon)
Date: Sun, 28 Jun 2009 07:58:46 +0000
Subject: [New-bugs-announce] [issue6354] Old floating point representation
	in 3.1 tutorial
In-Reply-To: <1246175926.72.0.81229799374.issue6354@psf.upfronthosting.co.za>
Message-ID: <1246175926.72.0.81229799374.issue6354@psf.upfronthosting.co.za>


New submission from Pierre Bourdon <root at delroth.is-a-geek.org>:

In part 3.1.1 of the Python 3.1 tutorial, the following code sample is
obsolete :

>>> 8/5 # Fractions aren't lost when dividing integers
1.6000000000000001


In a fresh Python 3.1, 8/5 is now displayed as 1.6. The note below the
code sample should be updated too.

----------
assignee: georg.brandl
components: Documentation
messages: 89768
nosy: delroth, georg.brandl
severity: normal
status: open
title: Old floating point representation in 3.1 tutorial
versions: Python 3.1

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

From report at bugs.python.org  Sun Jun 28 11:34:37 2009
From: report at bugs.python.org (Benjamin Kramer)
Date: Sun, 28 Jun 2009 09:34:37 +0000
Subject: [New-bugs-announce] [issue6355] bogus NULL check in PyCapsule
In-Reply-To: <1246181677.92.0.360590014109.issue6355@psf.upfronthosting.co.za>
Message-ID: <1246181677.92.0.360590014109.issue6355@psf.upfronthosting.co.za>


New submission from Benjamin Kramer <benny.kra at gmail.com>:

Objects/capsule.c contains the following code:

if (!name1 || !name2) {
    /* they're only the same if they're both NULL. */
    return name2 == name2;
}

The result of this comparison will always be true. The comment says it 
should be 'name1 == name2'.

----------
components: Interpreter Core
files: capsulecompare.patch
keywords: patch
messages: 89769
nosy: bkramer
severity: normal
status: open
title: bogus NULL check in PyCapsule
versions: Python 3.1
Added file: http://bugs.python.org/file14375/capsulecompare.patch

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

From report at bugs.python.org  Sun Jun 28 11:51:44 2009
From: report at bugs.python.org (str1442)
Date: Sun, 28 Jun 2009 09:51:44 +0000
Subject: [New-bugs-announce] [issue6356] Segfault of sys.setrecursionlimit
	if limit exceeds the	value 18063 (GNU/Linux)
In-Reply-To: <1246182704.52.0.334692905676.issue6356@psf.upfronthosting.co.za>
Message-ID: <1246182704.52.0.334692905676.issue6356@psf.upfronthosting.co.za>


New submission from str1442 <lancerstr at freenet.de>:

After playing around with the setrecursionlimit() Function in the sys
module, i noticed it crashes if you set the limit to a value that is too
high. I explored this further until i noticed the value from which the
crashing begins is exactly 18063. I know that the highest setable value
is platformdependent, but crashing seems inappropriate if a value is
given that is too high.

I'm using Debian GNU/Linux Testing, last upgrade one month ago.

uname -svomr:

Linux 2.6.27.7 #4 SMP Fri Nov 28 01:44:17 CET 2008 i686 GNU/Linux

(Kernel is a pure kernel.org Kernel, self compiled)

Python Version in question is 2.5.4. Searching through the tracker for
setrecursionlimit brought no corresponding issues.

This is a the test script I used:

import sys

sys.setrecursionlimit(18063)

def f():
    g()

def g():
    f()

f()

----------
components: Interpreter Core, Library (Lib)
messages: 89772
nosy: str1442
severity: normal
status: open
title: Segfault of sys.setrecursionlimit if limit exceeds the value 18063 (GNU/Linux)
type: crash
versions: Python 2.5

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

From report at bugs.python.org  Sun Jun 28 22:24:26 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sun, 28 Jun 2009 20:24:26 +0000
Subject: [New-bugs-announce] [issue6357] tempfile.NamedTemporaryFile does
	not accept the delete=	parameter on Windows
In-Reply-To: <1246220666.51.0.756681443001.issue6357@psf.upfronthosting.co.za>
Message-ID: <1246220666.51.0.756681443001.issue6357@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

Likely affects Python 2.7 and Python3.x as well, but I have not checked.

Under Windows:
>>> tempfile.NamedTemporaryFile('w', delete = False)
TypeError: NamedTemporaryFile() got an unexpected keyword argument 'delete'

Under Unix:
>>> tempfile.NamedTemporaryFile('w', delete=True)
<open file '<fdopen>', mode 'w' at 0x7ff199d0>

----------
messages: 89782
nosy: stutzbach
severity: normal
status: open
title: tempfile.NamedTemporaryFile does not accept the delete= parameter on Windows
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Jun 28 23:31:30 2009
From: report at bugs.python.org (James Abbatiello)
Date: Sun, 28 Jun 2009 21:31:30 +0000
Subject: [New-bugs-announce] [issue6358] os.popen exit code inconsistent
In-Reply-To: <1246224690.37.0.731708410356.issue6358@psf.upfronthosting.co.za>
Message-ID: <1246224690.37.0.731708410356.issue6358@psf.upfronthosting.co.za>


New submission from James Abbatiello <abbeyj at gmail.com>:

Start a process with os.popen() and then try to get its exit code by
closing the resulting file handle.  The value returned is inconsistent
between 2.x and 3.x.  Example:

Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> f = os.popen("exit 42", "r")
>>> f.close()
42


Python 3.1 (r31:73574, Jun 26 2009, 20:21:35) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> f = os.popen("exit 42", "r")
>>> f.close()
10752
>>> divmod(10752, 256)
(42, 0)


The docs for 2.6.2 say that the return value is the exit status of the
process as returned by wait()
(http://docs.python.org/library/os.html#os.popen).  That's what 3.1 is
doing(*) but not what 2.6 has actually been doing.  In 2.6 the exit code
(not exit status) is returned; if the process didn't exit cleanly then
an exception is thrown.

The docs for 3.1 say that os.popen() is documented in the section "File
Object Creation" but it is not.
http://docs.python.org/3.1/library/os.html#process-management
http://docs.python.org/3.1/library/os.html#file-object-creation
It doesn't seem to be documented at all in 3.1 although it is mentioned
many times on that page.

Since os.popen() is mostly for backward compatibility, should the 3.x
behavior be changed to match the actual 2.6 behavior?

(*) It looks like 3.1 doesn't return the right value if the subprocess
is killed by a signal but I can't test this on win32.

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 89792
nosy: abbeyj, georg.brandl
severity: normal
status: open
title: os.popen exit code inconsistent
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Mon Jun 29 00:43:23 2009
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 28 Jun 2009 22:43:23 +0000
Subject: [New-bugs-announce] [issue6359] pyexpat.c calls trace function
	incorrectly for exceptions
In-Reply-To: <1246229003.36.0.107970043042.issue6359@psf.upfronthosting.co.za>
Message-ID: <1246229003.36.0.107970043042.issue6359@psf.upfronthosting.co.za>


New submission from Ned Batchelder <nedbat at users.sourceforge.net>:

Pyexpat.c calls the tracing function explicitly (not sure why).  When it
intercepts an exception, it calls the function with PyTrace_EXCEPTION,
but then leaves the scope without calling PyTrace_RETURN.  This is
incorrect.  There should always be a PyTrace_RETURN for every PyTrace_CALL.

I've attached domshow.py to demonstrate the problem.

Running it produces many lines of output, including:

                     line expatbuilder.py 222
                     line expatbuilder.py 223
                     call pyexpat.c 905
                        call expatbuilder.py 892
                           line expatbuilder.py 894
                           line expatbuilder.py 900
                           exception expatbuilder.py 900
                           return expatbuilder.py 900
                        exception pyexpat.c 905
                        exception expatbuilder.py 223
                        line expatbuilder.py 225
                        line expatbuilder.py 226

The exception at line 905 in pyexpat.c should be followed with a return
from line 905 in pyexpat.c, but is not.  After that exception, the
nesting is off by one because the Calls and Returns don't match.

----------
components: XML
files: domshow.py
messages: 89798
nosy: nedbat
severity: normal
status: open
title: pyexpat.c calls trace function incorrectly for exceptions
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14379/domshow.py

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

From report at bugs.python.org  Mon Jun 29 02:10:37 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 29 Jun 2009 00:10:37 +0000
Subject: [New-bugs-announce] [issue6360] Simplify string decoding in
	xmlrpc.client.
In-Reply-To: <1246234237.97.0.0894396904771.issue6360@psf.upfronthosting.co.za>
Message-ID: <1246234237.97.0.0894396904771.issue6360@psf.upfronthosting.co.za>


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

The following patch tries to improve how xmlrpc.client handles strings.
In particular, it simplifies the decoding of strings by keeping them as
unicode str.

----------
files: simplify_xmlrpc_string_decoding.diff
keywords: patch
messages: 89801
nosy: alexandre.vassalotti
priority: normal
severity: normal
stage: patch review
status: open
title: Simplify string decoding in xmlrpc.client.
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file14380/simplify_xmlrpc_string_decoding.diff

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

From report at bugs.python.org  Mon Jun 29 02:49:52 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 29 Jun 2009 00:49:52 +0000
Subject: [New-bugs-announce] [issue6361] I/O object wrappers shouldn't close
	their underlying file	when deleted.
In-Reply-To: <1246236592.97.0.944471121329.issue6361@psf.upfronthosting.co.za>
Message-ID: <1246236592.97.0.944471121329.issue6361@psf.upfronthosting.co.za>


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

Here's an example of the behaviour:

import io

def test(buf):
   textio = io.TextIOWrapper(buf)

buf = io.BytesIO()
test(buf)
print(buf.closed)  # This prints True currently


The problem here is TextIOWrapper closes its buffer when deleted.
BufferedRWPair behalves similarly. The solution is simply to override
the __del__ method of TextIOWrapper inherited from IOBase.

----------
messages: 89803
nosy: alexandre.vassalotti
priority: normal
severity: normal
stage: needs patch
status: open
title: I/O object wrappers shouldn't close their underlying file when deleted.
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Jun 29 02:55:53 2009
From: report at bugs.python.org (Ryan Leslie)
Date: Mon, 29 Jun 2009 00:55:53 +0000
Subject: [New-bugs-announce] [issue6362] multiprocessing: handling of errno
	after signals in	sem_acquire()
In-Reply-To: <1246236953.98.0.347685302465.issue6362@psf.upfronthosting.co.za>
Message-ID: <1246236953.98.0.347685302465.issue6362@psf.upfronthosting.co.za>


New submission from Ryan Leslie <rylesny at gmail.com>:

While developing an application, an inconsistency was noted where,
depending on the particular signal handler in use,
multiprocessing.Queue.put() may (or may not) raise OSError() after
sys.exit() was called by the handler. The following example, which was
tested with Python 2.6.1 on Linux, demonstrates this.

#!/usr/bin/env python

import multiprocessing
import signal
import sys

def handleKill(signum, frame):
   #sys.stdout.write("Exit requested by signal.\n")
   print "Exit requested by signal."
   sys.exit(1)
signal.signal(signal.SIGTERM, handleKill)

queue = multiprocessing.Queue(maxsize=1)
queue.put(None)
queue.put(None)

When the script is run, the process will block (as expected) on the
second queue.put(). If (from another terminal) I send the process
SIGTERM, I consistently see:

$ ./q.py
Exit requested by signal.
$

Now, if I modify the above program by commenting out the 'print', and
uncommenting the 'sys.stdout' (a very subtle change), I would expect
the result to be the same when killing the process. Instead, I
consistently see:

$ ./q.py
Exit requested by signal.
Traceback (most recent call last):
 File "./q.py", line 15, in <module>
   queue.put(None)
 File "python2.6/multiprocessing/queues.py", line 75, in put
   if not self._sem.acquire(block, timeout):
OSError: [Errno 0] Error
$ 

After debugging this further, the issue appears to be in
semlock_acquire() or semaphore.c in Modules/_multiprocessing:
http://svn.python.org/view/python/trunk/Modules/_multiprocessing/semaphore.c?revision=71009&view=markup

The relevant code from (the Unix version of) semlock_acquire() is:

do {
               Py_BEGIN_ALLOW_THREADS
               if (blocking && timeout_obj == Py_None)
                       res = sem_wait(self->handle);
               else if (!blocking)
                       res = sem_trywait(self->handle);
               else
                       res = sem_timedwait(self->handle, &deadline);
               Py_END_ALLOW_THREADS
               if (res == MP_EXCEPTION_HAS_BEEN_SET)
                       break;
       } while (res < 0 && errno == EINTR && !PyErr_CheckSignals());

       if (res < 0) {
               if (errno == EAGAIN || errno == ETIMEDOUT)
                       Py_RETURN_FALSE;
               else if (errno == EINTR)
                       return NULL;
               else
                       return PyErr_SetFromErrno(PyExc_OSError);
       }

In both versions of the program (print vs. sys.stdout), sem_wait() is
being interrupted and is returning -1 with errno set to EINTR. This is
what I expected. Also, in both cases it seems that the loop is
(correctly) terminating with PyErr_CheckSignals() returning non-zero.
This makes sense too; the call is executing our signal handler, and then
returning -1 since our particular handler raises SystemExit.

However, I suspect that depending on the exact code executed
for the signal handler, errno may or may not wind up being reset in
some nested call of PyErr_CheckSignals(). I believe that the
error checking code below the do-while (where sem_wait() is called),
needed errno to have the value set by sem_wait(), and the author
wasn't expecting anything else to have changed it. In the "print"
version, errno apparently winds up unchanged with EINTR, resulting in
the `return NULL' statement. In the "sys.stdout" version (and probably
many others), errno winds up being reset to 0, and the error handling
results in the `return PyErr_SetFromErrno(PyExc_OSError)' statement.

To patch this up, we can probably just save errno as, say, `wait_errno'
at the end of the loop body, and then use it within the error handling
block that follows. However, the rest of the code should probably be
checked for this type of issue.

----------
components: Library (Lib)
messages: 89804
nosy: ryles
severity: normal
status: open
title: multiprocessing: handling of errno after signals in sem_acquire()
type: behavior
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/issue6362>
_______________________________________

From report at bugs.python.org  Mon Jun 29 04:27:30 2009
From: report at bugs.python.org (Poor Yorick)
Date: Mon, 29 Jun 2009 02:27:30 +0000
Subject: [New-bugs-announce] [issue6363] __future__ statements break doctest
In-Reply-To: <1246242450.27.0.0341374672588.issue6363@psf.upfronthosting.co.za>
Message-ID: <1246242450.27.0.0341374672588.issue6363@psf.upfronthosting.co.za>


New submission from Poor Yorick <pooryorick at users.sourceforge.net>:

(this error also occurs with "print_function")

Python 3.1 (r31:73574, Jun 26 2009, 20:21:35) [MSC v.1500 32 bit
(Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import unicode_literals
>>> import doctest
>>> def func1():
...    '''
...    >>> func1()
...    hello
...    '''
...    print('hello')
...
>>> doctest.testmod()
**********************************************************************
File "__main__", line 3, in __main__.func1
Failed example:
    func1()
Exception raised:
    Traceback (most recent call last):
      File "c:\Python31\lib\doctest.py", line 1242, in __run
        compileflags, 1), test.globs)
    ValueError: compile(): unrecognised flags
**********************************************************************
1 items had failures:
   1 of   1 in __main__.func1
***Test Failed*** 1 failures.
TestResults(failed=1, attempted=1)

----------
components: Library (Lib)
messages: 89807
nosy: pooryorick
severity: normal
status: open
title: __future__ statements break doctest
versions: Python 3.1

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

From report at bugs.python.org  Mon Jun 29 05:15:49 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Mon, 29 Jun 2009 03:15:49 +0000
Subject: [New-bugs-announce] [issue6364] freeze tool broken in Python 3.x
In-Reply-To: <1246245349.44.0.542405438388.issue6364@psf.upfronthosting.co.za>
Message-ID: <1246245349.44.0.542405438388.issue6364@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

The freeze tool seems to be severely broken in Python 3.x. Applying it
to a "hello world" script produces:

Warning: unknown modules remain: _bisect _collections _ctypes _hashlib
_heapq _multiprocessing _pickle _random _socket _ssl _struct _tkinter
array atexit binascii datetime fcntl itertools math mmap operator
pyexpat readline select termios time

and a subsequent make results in

config.o:(.data+0x8): undefined reference to `init_codecs'
config.o:(.data+0x18): undefined reference to `init_functools'
config.o:(.data+0x28): undefined reference to `init_io'
config.o:(.data+0x38): undefined reference to `init_locale'
config.o:(.data+0x48): undefined reference to `init_sre'
config.o:(.data+0x58): undefined reference to `init_thread'
config.o:(.data+0x68): undefined reference to `init_weakref'
config.o:(.data+0x78): undefined reference to `initerrno'
config.o:(.data+0x88): undefined reference to `initgc'
config.o:(.data+0x98): undefined reference to `initimp'
config.o:(.data+0xa8): undefined reference to `initposix'
config.o:(.data+0xb8): undefined reference to `initpwd'
config.o:(.data+0xc8): undefined reference to `initsignal'
config.o:(.data+0xd8): undefined reference to `initzipimport'

----------
components: Demos and Tools
messages: 89808
nosy: hagen
severity: normal
status: open
title: freeze tool broken in Python 3.x
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Jun 29 08:20:42 2009
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 29 Jun 2009 06:20:42 +0000
Subject: [New-bugs-announce] [issue6365] distutils duplicates package
	directory for C extensions	in 3.1 final
In-Reply-To: <1246256442.36.0.248287671796.issue6365@psf.upfronthosting.co.za>
Message-ID: <1246256442.36.0.248287671796.issue6365@psf.upfronthosting.co.za>


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

When compiling a C extension (lxml in this case) in Py3.1, calling the
"build_ext -i" distutils target duplicates the package path when writing
the dynlib. In this case, I get "lxml/lxml/etree.so" instead of
"lxml/etree.so". Obviously, the extension module cannot be found
afterwards, as it's not inside its package anymore. The extension is
named "lxml.etree" when creating the Extension object.

This is a regression from 3.1rc1 AFAICT.

----------
assignee: tarek
components: Distutils
messages: 89813
nosy: scoder, tarek
severity: normal
status: open
title: distutils duplicates package directory for C extensions in 3.1 final
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Jun 29 15:27:06 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Jun 2009 13:27:06 +0000
Subject: [New-bugs-announce] [issue6366] rare assertion failure in
	test_multiprocessing
In-Reply-To: <1246282026.12.0.299929398487.issue6366@psf.upfronthosting.co.za>
Message-ID: <1246282026.12.0.299929398487.issue6366@psf.upfronthosting.co.za>


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

Just got the following non-reproducible failure in test_multiprocessing
on py3k. Python was compiled in non-debug mode so I assume the strange
failure message is a multiprocessing feature?

8e25dcc:       refcount=1
    <queue.Queue object at 0x8e25dcc>
  8e25f6c:       refcount=1
    <threading._Event object at 0x8e25f6c>
  8e3774c:       refcount=1
    <queue.Queue object at 0x8e3774c>
  8e377ac:       refcount=1
    <threading._Event object at 0x8e377ac>
  b785a08c:       refcount=2
    <multiprocessing.pool.Pool object at 0xb785a08c>
  8e25dcc:       refcount=1
    <queue.Queue object at 0x8e25dcc>
  8e25f6c:       refcount=1
    <threading._Event object at 0x8e25f6c>
  8e3774c:       refcount=1
    <queue.Queue object at 0x8e3774c>
  8e377ac:       refcount=1
    <threading._Event object at 0x8e377ac>
  b785a08c:       refcount=2
    <multiprocessing.pool.Pool object at 0xb785a08c>
test test_multiprocessing failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_multiprocessing.py",
line 1070, in test_number_of_objects
    self.assertEqual(refs, EXPECTED_NUMBER)
AssertionError: 5 != 1

----------
assignee: jnoller
components: Library (Lib)
messages: 89832
nosy: jnoller, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: rare assertion failure in test_multiprocessing
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Mon Jun 29 15:30:40 2009
From: report at bugs.python.org (vinoth)
Date: Mon, 29 Jun 2009 13:30:40 +0000
Subject: [New-bugs-announce] [issue6367] Change the instruction pointer in
	python
In-Reply-To: <1246282240.82.0.405033347803.issue6367@psf.upfronthosting.co.za>
Message-ID: <1246282240.82.0.405033347803.issue6367@psf.upfronthosting.co.za>


New submission from vinoth <4vinoth at gmail.com>:

HI all 

I am not the too technical guy, but thinking about the new way of
controlling the flow instead of throwing an error.

as of now if we need to break a control and go back exceptions helps,
but it is not a actual way. 

it would be great if we have a control over the frames execution, I mean

A  calls B calls C calls D 

at that point if we think to move directly to B (what error handler do
if that B has the handler defined of the error), changing the frames
instruction pointer to back to the B's position (in python code without
raising an exception) is a really useful for this web applications.

Please excuse me if we have this control already, (can u explain?)

Thanks 
Vinoth

----------
components: Interpreter Core
messages: 89833
nosy: vinoth
severity: normal
status: open
title: Change the instruction pointer in python
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Mon Jun 29 15:54:40 2009
From: report at bugs.python.org (Vikram U Shenoy)
Date: Mon, 29 Jun 2009 13:54:40 +0000
Subject: [New-bugs-announce] [issue6368] Fix unused variable warning
	introduced by commit r73603.
In-Reply-To: <1246283680.73.0.478947993554.issue6368@psf.upfronthosting.co.za>
Message-ID: <1246283680.73.0.478947993554.issue6368@psf.upfronthosting.co.za>


New submission from Vikram U Shenoy <vikram.u.shenoy at gmail.com>:

Attach patch fixes an unused variable warning introduced by commit r73603.

----------
components: Build
files: fix_unused_var_jun_29_2009.patch
keywords: patch
messages: 89839
nosy: vshenoy
severity: normal
status: open
title: Fix unused variable warning introduced by commit r73603.
versions: Python 2.7
Added file: http://bugs.python.org/file14383/fix_unused_var_jun_29_2009.patch

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

From report at bugs.python.org  Mon Jun 29 16:36:19 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Jun 2009 14:36:19 +0000
Subject: [New-bugs-announce] [issue6369] binhex buggy in py3k
In-Reply-To: <1246286179.9.0.0098379045157.issue6369@psf.upfronthosting.co.za>
Message-ID: <1246286179.9.0.0098379045157.issue6369@psf.upfronthosting.co.za>


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

The binhex module is buggy in py3k, witness the following example (it
works ok on trunk):

>>> binhex.binhex("README", "testA")
>>> binhex.hexbin("testA", "outA")
>>> binhex.binhex("LICENSE", "testB")
>>> binhex.hexbin("testB", "outB")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/py3k/__svn__/Lib/binhex.py", line 445, in hexbin
    ifp = HexBin(inp)
  File "/home/antoine/py3k/__svn__/Lib/binhex.py", line 364, in __init__
    self._readheader()
  File "/home/antoine/py3k/__svn__/Lib/binhex.py", line 384, in _readheader
    rest = self._read(1 + 4 + 4 + 2 + 4 + 4)
  File "/home/antoine/py3k/__svn__/Lib/binhex.py", line 367, in _read
    data = self.ifp.read(len)
  File "/home/antoine/py3k/__svn__/Lib/binhex.py", line 300, in read
    self._fill(wtd - len(self.post_buffer))
  File "/home/antoine/py3k/__svn__/Lib/binhex.py", line 337, in _fill
    binascii.rledecode_hqx(self.pre_buffer[:mark])
binascii.Error: Orphaned RLE code at start

----------
components: Library (Lib)
messages: 89842
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: binhex buggy in py3k
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Jun 29 16:56:28 2009
From: report at bugs.python.org (SilentGhost)
Date: Mon, 29 Jun 2009 14:56:28 +0000
Subject: [New-bugs-announce] [issue6370] Bad performance of
	colllections.Counter at initialisation	from an iterable
In-Reply-To: <1246287388.55.0.75208877327.issue6370@psf.upfronthosting.co.za>
Message-ID: <1246287388.55.0.75208877327.issue6370@psf.upfronthosting.co.za>


New submission from SilentGhost <michael.mischurow+bpo at gmail.com>:

I'm comparing initialisation of Counter from an iterable with the
following function:

def unique(seq):
	"""Dict of unique values (keys) & their counts in original sequence"""

	out_dict = dict.fromkeys(set(seq), 0)
	for i in seq:
		out_dict[i] += 1
	return out_dict


iterable = list(range(43)) + list(range(43, 0, -1))

The timeit-obtained values show that it takes Counter four (4) times
longer to finish. As it's obvious from comparing my function and lines
429-430 of collections.py the only difference is preallocating the final
dictionary. When line 430 of collections is replaced with:

self[elem] = self.get(elem, 0) + 1

I was able to get about 25% time-performance increase (I assume
__missing__ is bypassed). I hope that it's possible to improve its
implementation even further.

----------
components: Library (Lib)
messages: 89846
nosy: SilentGhost
severity: normal
status: open
title: Bad performance of colllections.Counter at initialisation from an iterable
type: performance
versions: Python 3.1

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

From report at bugs.python.org  Mon Jun 29 17:04:03 2009
From: report at bugs.python.org (Pascal Chambon)
Date: Mon, 29 Jun 2009 15:04:03 +0000
Subject: [New-bugs-announce] [issue6371] Minor internal link errors in
	Optparse doc
In-Reply-To: <1246287843.59.0.00928118566027.issue6371@psf.upfronthosting.co.za>
Message-ID: <1246287843.59.0.00928118566027.issue6371@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

Hello

A minor detail in optparse documentation :
"If optparse?s default error-handling behaviour does not suit your
needs, you?ll need to subclass OptionParser and override its exit()
and/or error() methods."
-> the links put on exit() and error() are wrong (the latter isn't set,
the former links to another exit() symbol.

Regards, 
Pascal

----------
assignee: georg.brandl
components: Documentation
messages: 89847
nosy: georg.brandl, pakal
severity: normal
status: open
title: Minor internal link errors in Optparse doc
versions: Python 2.6

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

From report at bugs.python.org  Mon Jun 29 17:21:04 2009
From: report at bugs.python.org (Pablo Torres Navarrete)
Date: Mon, 29 Jun 2009 15:21:04 +0000
Subject: [New-bugs-announce] [issue6372] Make all switches keyword-only
In-Reply-To: <1246288864.0.0.660684882906.issue6372@psf.upfronthosting.co.za>
Message-ID: <1246288864.0.0.660684882906.issue6372@psf.upfronthosting.co.za>


New submission from Pablo Torres Navarrete <tn.pablo at gmail.com>:

I propose that all formal parameters that really act as options/switches
be made keyword-only.  Examples of switches are all flags, timeouts,
'verbose' bools, maximums and minimums, etc.

This stresses the difference between needed input for a function and an
argument that changes/extends the behavior.  Besides, the code would be
more readable, because instead of having some cryptic function call like
register('Pablo Torres', 2, 4, 5, False) you would have the prettier
register('Pablo Torres', hour=2, min=4, sec=5, had_reservation=False).

The implementation would just require putting a star '*' before all
options, according to pep 3102.

If needed, I can rewrite this as a PEP.

----------
components: Library (Lib)
messages: 89850
nosy: ptn
severity: normal
status: open
title: Make all switches keyword-only
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Mon Jun 29 17:31:25 2009
From: report at bugs.python.org (Glynn Clements)
Date: Mon, 29 Jun 2009 15:31:25 +0000
Subject: [New-bugs-announce] [issue6373] SystemError in encoder
In-Reply-To: <1246289485.02.0.752200550546.issue6373@psf.upfronthosting.co.za>
Message-ID: <1246289485.02.0.752200550546.issue6373@psf.upfronthosting.co.za>


New submission from Glynn Clements <glynn at gclements.plus.com>:

Test case:

> "\udce4\udceb\udcef\udcf6\udcfc".encode("iso-8859-1", "surrogateescape")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Objects/bytesobject.c:3182: bad argument to internal function

The line number corresponds to _PyBytes_Resize()

----------
components: Interpreter Core, Unicode
messages: 89852
nosy: glynnc
severity: normal
status: open
title: SystemError in encoder
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Jun 29 17:47:38 2009
From: report at bugs.python.org (Pascal Chambon)
Date: Mon, 29 Jun 2009 15:47:38 +0000
Subject: [New-bugs-announce] [issue6374] Confused by subprocess API
	documentation
In-Reply-To: <1246290458.09.0.216781852955.issue6374@psf.upfronthosting.co.za>
Message-ID: <1246290458.09.0.216781852955.issue6374@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

I feel the description of the subprocess.popen semantics is a little
incomplete/confusing to me, on some points, eg. :
- what does the "shell" argument do on windows, exactly ? The beginning
of the description states that nothing changes (createProcess() is used
in any way), but later "COMSPEC" and "shell" are quoted, and their
effect is unclear on windows...  
-"If cwd is not None, the child?s current directory will be changed to
cwd before it is executed. Note that this directory is not considered
when searching the executable, so you can?t specify the program?s path
relative to cwd." -> maybe we should precise that only the "executable"
argument is concerned, not the 'executable' program name which might be
given as first item in "args" argument (and which is, on the contrary,
searched relatively to "cwd" argument)
-for the "bufsize" argument, it would be handy to precise which buffer
size is set (of which file descriptors exactly ? Of Pipes only ?)

Regards, 
P. Chambon

----------
assignee: georg.brandl
components: Documentation
messages: 89854
nosy: georg.brandl, pakal
severity: normal
status: open
title: Confused by subprocess API documentation
versions: Python 2.6

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

From report at bugs.python.org  Mon Jun 29 18:30:41 2009
From: report at bugs.python.org (Adam Golebiowski)
Date: Mon, 29 Jun 2009 16:30:41 +0000
Subject: [New-bugs-announce] [issue6375] compile failure in Modules/python.c
In-Reply-To: <1246293041.45.0.166944459621.issue6375@psf.upfronthosting.co.za>
Message-ID: <1246293041.45.0.166944459621.issue6375@psf.upfronthosting.co.za>


New submission from Adam Golebiowski <adamg at pld-linux.org>:

Python-3.1 fails to compile with:
./Modules/python.c: In function 'wchar_t* char2wchar(char*)':
./Modules/python.c:60: error: invalid conversion from 'void*' to 'wchar_t*'

The attached patch fixes this.

----------
files: python3-cast-fix.patch
keywords: patch
messages: 89860
nosy: adamg
severity: normal
status: open
title: compile failure in Modules/python.c
versions: Python 3.1
Added file: http://bugs.python.org/file14387/python3-cast-fix.patch

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

From report at bugs.python.org  Mon Jun 29 18:34:47 2009
From: report at bugs.python.org (MATSUI Tetsushi)
Date: Mon, 29 Jun 2009 16:34:47 +0000
Subject: [New-bugs-announce] [issue6376] description of
	Decinal.logical_invert is incorrect
In-Reply-To: <1246293287.33.0.612180884137.issue6376@psf.upfronthosting.co.za>
Message-ID: <1246293287.33.0.612180884137.issue6376@psf.upfronthosting.co.za>


New submission from MATSUI Tetsushi <mft at users.sourceforge.net>:

The library reference of Decimal.logical_invert:
   .. method:: logical_invert(other[, context])

      :meth:`logical_invert` is a logical operation.  The argument must
      be a *logical operand* (see :ref:`logical_operands_label`).  The
      result is the digit-wise inversion of the operand.

There should not be "other" argument, since it's an unary operation.

----------
assignee: georg.brandl
components: Documentation
messages: 89862
nosy: georg.brandl, mft
severity: normal
status: open
title: description of Decinal.logical_invert is incorrect
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Jun 29 20:22:20 2009
From: report at bugs.python.org (Anthony Tuininga)
Date: Mon, 29 Jun 2009 18:22:20 +0000
Subject: [New-bugs-announce] [issue6377] distutils compiler switch ignored
In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>
Message-ID: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>


New submission from Anthony Tuininga <anthony.tuininga at gmail.com>:

With the release of Python 3.1 the --compiler switch is ignored in
Lib/distutils/command/build_ext.py. The attached patch fixes that issue.
Once that was fixed there was another issue with get_version() in
cygwincompiler but that appears to be fixed in the 3.1 branch. The
revision that introduced this problem is 72596 (from 72593 in trunk).

----------
assignee: tarek
components: Distutils
files: distutils_compiler.patch
keywords: patch
messages: 89871
nosy: atuining, tarek
severity: normal
status: open
title: distutils compiler switch ignored
versions: Python 3.1
Added file: http://bugs.python.org/file14390/distutils_compiler.patch

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

From report at bugs.python.org  Mon Jun 29 22:45:22 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 29 Jun 2009 20:45:22 +0000
Subject: [New-bugs-announce] [issue6378] Patch to make 'idle.bat' run
	idle.pyw using appropriate	Python interpreter (so 3.1's
	idle.bat does not accidently use	python26.exe)
In-Reply-To: <1246308322.32.0.750084238969.issue6378@psf.upfronthosting.co.za>
Message-ID: <1246308322.32.0.750084238969.issue6378@psf.upfronthosting.co.za>


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

On Mon, 29 Jun 2009 09:56:53 -0700, Trent Mick <trentm at activestate.com>
wrote:

> Sridhar Ratnakumar wrote:
>> I installed ActivePython-3.1 to C:\Python31 but disabled the 
installer
>> option "Register as default Python" .. because, I use Python-2.6 by  
>> default.
>>
>> However, this disabling broke 3.1's IDLE. Clicking on 'idle.bat' or
>> 'idle.py' or 'idle.pyw' in C:\Python31\Lib\idle\ directory opens 
Python
>> 2.6's IDLE.
>>
>> Since the installer knows the path to Python - C:
\Python31\python.exe -
>> does it make sense to patch the idle.bat file to use this binary?
>
> IIRC there is a special NT batch file syntax that you can use do that
> idle.bat will look for python.exe in a relative path, so that you 
won't
> have to patch idle.bat after install (which would be a pain).
>
> Here, use this for idle.bat:
>
>    @echo off
>    set CURRDIR=%~dp0
>    start %CURRDIR%..\..\pythonw.exe idle.pyw
>
> Perhaps you could add a bug to core Python to change idle.bat to be 
that?
>
>
> Trent
>

----------
components: IDLE, Windows
files: idle-use-curr-py.patch
keywords: patch
messages: 89875
nosy: srid
severity: normal
status: open
title: Patch to make 'idle.bat' run idle.pyw using appropriate Python interpreter (so 3.1's idle.bat does not accidently use python26.exe)
type: behavior
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file14392/idle-use-curr-py.patch

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

From report at bugs.python.org  Mon Jun 29 23:20:26 2009
From: report at bugs.python.org (Zbigniew Braniecki)
Date: Mon, 29 Jun 2009 21:20:26 +0000
Subject: [New-bugs-announce] [issue6379] Add first() function that would
	take first matching case	from an iterator
In-Reply-To: <1246310426.36.0.617825815292.issue6379@psf.upfronthosting.co.za>
Message-ID: <1246310426.36.0.617825815292.issue6379@psf.upfronthosting.co.za>


New submission from Zbigniew Braniecki <zbigniew.braniecki at gmail.com>:

Python has a very useful function any() that will iterate over a list
and break on the first matching case.

Now, it would be great to have similar function but with:
a) ability to use a callback for matching test
b) that would return the first match

so something like:

key = first(['es-AR','es','en-US'], lambda x:self._value.has_key(x))

instead of:

for k in ['es-AR','es','en-US']:
    if self._value.has_key(k):
        key = k
        break

It would be also nice to be able to capture the first match and return it:
value = first(['es-AR','es','en-US'], lambda x:self._value[x])

I'm not sure which one is more generically applicable.

----------
components: None
messages: 89879
nosy: gandalf
severity: normal
status: open
title: Add first() function that would take first matching case from an iterator
versions: Python 3.1

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

From report at bugs.python.org  Tue Jun 30 00:52:14 2009
From: report at bugs.python.org (Dmitriy Khramtsov)
Date: Mon, 29 Jun 2009 22:52:14 +0000
Subject: [New-bugs-announce] [issue6380] Deadlock during the "import" in the
	fork()'ed child	process if fork() happened while import_lock
	was held
In-Reply-To: <1246315934.51.0.706424064381.issue6380@psf.upfronthosting.co.za>
Message-ID: <1246315934.51.0.706424064381.issue6380@psf.upfronthosting.co.za>


New submission from Dmitriy Khramtsov <highdn at gmail.com>:

Greetings,

The 2.4 and 2.5 versions of python contains a deadlock caused by
possibility to hold import_lock while doing fork() and not resetting it
in the child (on the linux platform).


The prove of concept code is:

--BEGIN (import_lock.py)--

#!/usr/bin/python2.4

import os
import time
import threading

class SecondThread(threading.Thread):
  def run(self):
    # Give the main thread time to hold import_lock and start importing.
    time.sleep(1)

    # Fork the process while holding import_lock in the main thread.
    pid = os.fork()

    if pid == 0:  # Child process
      print "child begin"

      # The import lock is still taken by main thread which is now not
the part
      # of the child process.  The import lock will never be released in the
      # child process.  Effectively, any import is a deadlock from now on.
      import types

      # This statement will never be executed.
      print "child end"

def main():
  second_thread = SecondThread()
  second_thread.start()

  # Take the import_lock and then release global interpreter lock in the
  # import_lock_helper module by calling any blocking operation.
  import import_lock_helper

  second_thread.join()

main()

--END (import_lock.py)--


--BEGIN (import_lock_helper.py)--

#!/usr/bin/python2.4

import time

# Release the global interpreter lock by calling any blocking operation.
time.sleep(10)

--END (import_lock_helper.py)--


The stack of the child python interpreter at the time of dead lock:

(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xf7f81700 in sem_wait at GLIBC_2.0 () from
/usr/grte/v1/lib/libpthread.so.0
#2  0x081ab500 in ?? ()
#3  0x080e1855 in PyThread_acquire_lock (lock=0x0, waitflag=1) at
../../Python/thread_pthread.h:313
#4  0x080d1f3b in lock_import () at ../../Python/import.c:247
#5  0x080d52a4 in PyImport_ImportModuleEx (name=0xf7e0f8f4 "types",
globals=0xf7def824, locals=0x8123cb8, fromlist=0x8123cb8) at
../../Python/import.c:1976
#6  0x080af2d0 in builtin___import__ (self=0x0, args=0xf7db7cd4) at
../../Python/bltinmodule.c:45
#7  0x08058d77 in PyObject_Call (func=0x0, arg=0xf7db7cd4, kw=0x0) at
../../Objects/abstract.c:1795
#8  0x080b30ec in PyEval_CallObjectWithKeywords (func=0xf7ddfd6c,
arg=0xf7db7cd4, kw=0x0) at ../../Python/ceval.c:3435
#9  0x080b5ca6 in PyEval_EvalFrame (f=0x8167a04) at
../../Python/ceval.c:2020
#10 0x080b942c in PyEval_EvalFrame (f=0x81ab57c) at
../../Python/ceval.c:3651
. . . .

(gdb) pystack
import_lock.py (26): run
/usr/lib/python2.4/threading.py (443): __bootstrap


The code directly responsible for import locking (Python/import.c):

--BEGIN--
static PyThread_type_lock import_lock = 0;
static long import_lock_thread = -1;
static int import_lock_level = 0;

static void
lock_import(void)
{
       long me = PyThread_get_thread_ident();
       if (me == -1)
               return; /* Too bad */
       if (import_lock == NULL) {
               import_lock = PyThread_allocate_lock();
               if (import_lock == NULL)
                       return;  /* Nothing much we can do. */
       }
       if (import_lock_thread == me) {
               import_lock_level++;
               return;
       }
       if (import_lock_thread != -1 ||
!PyThread_acquire_lock(import_lock, 0))
       {
               PyThreadState *tstate = PyEval_SaveThread();
               PyThread_acquire_lock(import_lock, 1);
               PyEval_RestoreThread(tstate);
       }
       import_lock_thread = me;
       import_lock_level = 1;
}

static int
unlock_import(void)
{
       long me = PyThread_get_thread_ident();
       if (me == -1 || import_lock == NULL)
               return 0; /* Too bad */
       if (import_lock_thread != me)
               return -1;
       import_lock_level--;
       if (import_lock_level == 0) {
               import_lock_thread = -1;
               PyThread_release_lock(import_lock);
       }
       return 1;
}

/* This function is called from PyOS_AfterFork to ensure that newly
  created child processes do not share locks with the parent. */

void
_PyImport_ReInitLock(void)
{
#ifdef _AIX
       if (import_lock != NULL)
               import_lock = PyThread_allocate_lock();
#endif
}
--END--


The possible solution is to reset import_lock in the
_PyImport_ReInitLock() not only for _AIX but also for Linux and maybe
other platforms (do you know why _AIX-only guard is there?).

--CUT HERE--
void
_PyImport_ReInitLock(void)
{
       if (import_lock != NULL)
               import_lock = PyThread_allocate_lock();
}
--CUT HERE--

Prove of concept example above works fine (w/o deadlocks) on the python
interpreter rebuilt with the _PyImport_ReInitLock() modification above.


Also this bug can be worked around in Python code by holding import_lock
before fork() and releasing import_lock right after fork() in both
parent and child.

The workaround code is:

--BEGIN (workaround_fork_import_bug.py)--

import imp
import os

def __fork():
  imp.acquire_lock()
  try:
    return _os_fork()
  finally:
    imp.release_lock()

try:
  _os_fork
except NameError:
  _os_fork = os.fork
  os.fork = __fork

--END (workaround_fork_import_bug.py)--


This workaround can also be implemented in Python interpreter in C and
could be other solution for this bug.


Thanks,
Dmitriy


$ uname -srvmpio
Linux 2.6.24-gg24-generic #1 SMP Wed Apr 22 21:48:06 PDT 2009 x86_64
unknown unknown GNU/Linux

P.S. The problem described above is probably causes (some) effects
described in http://bugs.python.org/issue1590864.

----------
components: Interpreter Core
messages: 89892
nosy: abaron, astrand, brett.cannon, hdn, kosuha, michaeltsai, ronaldoussoren
severity: normal
status: open
title: Deadlock during the "import" in the fork()'ed child process if fork() happened while import_lock was held
type: behavior
versions: Python 2.4, Python 2.5

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

From report at bugs.python.org  Tue Jun 30 03:40:20 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 30 Jun 2009 01:40:20 +0000
Subject: [New-bugs-announce] [issue6381] test_urllib2_localnet sporadic
	failures closing socket
In-Reply-To: <1246326020.83.0.77401775469.issue6381@psf.upfronthosting.co.za>
Message-ID: <1246326020.83.0.77401775469.issue6381@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Gentoo linux, r73699, I'm seeing sporadic failures in
test_urllib2_localnet in the following two tests:

test_sending_headers
test_proxy_with_no_password_raises_httperror

It happens about once every other run in one or the other of those.  I
don't see any problems on 2.6-maint or py3k.

In both cases it is failing in the close.  Here is an example traceback:

test_sending_headers (test.test_urllib2_localnet.TestUrlopen) ...
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 46051)
Traceback (most recent call last):
  File "/home/rdmurray/python/trunk/Lib/SocketServer.py", line 281, in
_handle_request_noblock
    self.process_request(request, client_address)
  File "/home/rdmurray/python/trunk/Lib/SocketServer.py", line 308, in
process_request
    self.close_request(request)
  File "/home/rdmurray/python/trunk/Lib/SocketServer.py", line 448, in
close_request
    request.shutdown(socket.SHUT_WR)
  File "/home/rdmurray/python/trunk/Lib/socket.py", line 219, in meth
    return getattr(self._sock,name)(*args)
error: [Errno 107] Transport endpoint is not connected
----------------------------------------
Exception in thread Thread-12:
Traceback (most recent call last):
  File "/home/rdmurray/python/trunk/Lib/threading.py", line 524, in
__bootstrap_inner
    self.run()
  File "/home/rdmurray/python/trunk/Lib/test/test_urllib2_localnet.py",
line 65, in run
    self.httpd.handle_request()
  File "/home/rdmurray/python/trunk/Lib/SocketServer.py", line 266, in
handle_request
    self._handle_request_noblock()
  File "/home/rdmurray/python/trunk/Lib/SocketServer.py", line 284, in
_handle_request_noblock
    self.close_request(request)
  File "/home/rdmurray/python/trunk/Lib/SocketServer.py", line 448, in
close_request
    request.shutdown(socket.SHUT_WR)
  File "/home/rdmurray/python/trunk/Lib/socket.py", line 219, in meth
    return getattr(self._sock,name)(*args)
error: [Errno 107] Transport endpoint is not connected

----------
components: Tests
messages: 89896
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: test_urllib2_localnet sporadic failures closing socket
type: security
versions: Python 2.7

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

From report at bugs.python.org  Tue Jun 30 03:58:44 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 30 Jun 2009 01:58:44 +0000
Subject: [New-bugs-announce] [issue6382] test_socketserver fails on trunk in
	test_ForkingTCPServer
In-Reply-To: <1246327124.37.0.772968679477.issue6382@psf.upfronthosting.co.za>
Message-ID: <1246327124.37.0.772968679477.issue6382@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Gentoo linux, trunk r73699.  test_socketserver fails with the following
tracebacks:

======================================================================
FAIL: test_ForkingTCPServer (test.test_socketserver.SocketServerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/rdmurray/python/trunk/Lib/test/test_socketserver.py", line
189, in test_ForkingTCPServer
    self.stream_examine)
  File "/home/rdmurray/python/trunk/Lib/test/test_socketserver.py", line
147, in run_server
    testfunc(svrcls.address_family, addr)
  File "/home/rdmurray/python/trunk/Lib/test/test_socketserver.py", line
161, in stream_examine
    self.assertEquals(buf, TEST_STR)
AssertionError: '' != 'hello world\n'

======================================================================
FAIL: test_ForkingUnixStreamServer (test.test_socketserver.SocketServerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/rdmurray/python/trunk/Lib/test/test_socketserver.py", line
207, in test_ForkingUnixStreamServer
    self.stream_examine)
  File "/home/rdmurray/python/trunk/Lib/test/test_socketserver.py", line
147, in run_server
    testfunc(svrcls.address_family, addr)
  File "/home/rdmurray/python/trunk/Lib/test/test_socketserver.py", line
161, in stream_examine
    self.assertEquals(buf, TEST_STR)
AssertionError: '' != 'hello world\n'

----------
components: Library (Lib)
messages: 89897
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: test_socketserver fails on trunk in test_ForkingTCPServer
versions: Python 2.7

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

From report at bugs.python.org  Tue Jun 30 04:43:04 2009
From: report at bugs.python.org (Vernon Cole)
Date: Tue, 30 Jun 2009 02:43:04 +0000
Subject: [New-bugs-announce] [issue6383] error in
	unicodedata.numeric(u"\u2187") and 2188
In-Reply-To: <1246329784.46.0.00677223147699.issue6383@psf.upfronthosting.co.za>
Message-ID: <1246329784.46.0.00677223147699.issue6383@psf.upfronthosting.co.za>


New submission from Vernon Cole <vernondcole at gmail.com>:

I am making a demo program, a class which is a subset of int, which
implements a partial implementation of PEP313 (Roman numeral literals).

I discover that my conversion routines fail for values > 50000 due to an
error in unicodedata for the two code points 2187 and 2188. The return
value of unicodedata.numeric() for those two points should be 50,000.0
and 100,000.0 respectively. See the following console dump which
includes code point 2181 which works correctly.

----- console dump follows -----

c:\BZR\roman>c:\python26\python.exe
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import unicodedata
>>> unicodedata.name(u"\u2187")
'ROMAN NUMERAL FIFTY THOUSAND'
>>> unicodedata.numeric(u"\u2187")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: not a numeric character
>>> unicodedata.name(u"\u2188")
'ROMAN NUMERAL ONE HUNDRED THOUSAND'
>>> unicodedata.numeric(u"\u2188")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: not a numeric character
>>> unicodedata.name(u"\u2181")
'ROMAN NUMERAL FIVE THOUSAND'
>>> unicodedata.numeric(u"\u2181")
5000.0
>>>

----------
components: Unicode
messages: 89899
nosy: vernondcole
severity: normal
status: open
title: error in unicodedata.numeric(u"\u2187") and 2188
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Jun 30 06:03:47 2009
From: report at bugs.python.org (Mitchell Model)
Date: Tue, 30 Jun 2009 04:03:47 +0000
Subject: [New-bugs-announce] [issue6384] Permalink to built-in exception
	class hierarchy	documentation
In-Reply-To: <1246334627.57.0.503103979691.issue6384@psf.upfronthosting.co.za>
Message-ID: <1246334627.57.0.503103979691.issue6384@psf.upfronthosting.co.za>


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

I think it would be useful to have a permalink to the built-in exception
class hierarchy at the end of the library exceptions documentation.

----------
assignee: georg.brandl
components: Documentation
messages: 89904
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Permalink to built-in exception class hierarchy documentation
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/issue6384>
_______________________________________

From report at bugs.python.org  Tue Jun 30 06:06:25 2009
From: report at bugs.python.org (Mitchell Model)
Date: Tue, 30 Jun 2009 04:06:25 +0000
Subject: [New-bugs-announce] [issue6385] two lines of typographical
	inconsistency in doc of	exception class hierarchy
In-Reply-To: <1246334785.12.0.590617897829.issue6385@psf.upfronthosting.co.za>
Message-ID: <1246334785.12.0.590617897829.issue6385@psf.upfronthosting.co.za>


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

In the documentation of the built-in exception class hierarhcy in the
library documentation WindowsError (Windows) and VMSError (VMS) are not
in the same color as the rest of the exception names.

----------
messages: 89905
nosy: MLModel
severity: normal
status: open
title: two lines of typographical inconsistency in doc of exception class hierarchy
versions: Python 3.0, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Jun 30 12:05:44 2009
From: report at bugs.python.org (jbeulich)
Date: Tue, 30 Jun 2009 10:05:44 +0000
Subject: [New-bugs-announce] [issue6386] importing yields unexpected results
	when initial script	is a symbolic link
In-Reply-To: <1246356344.6.0.218965497612.issue6386@psf.upfronthosting.co.za>
Message-ID: <1246356344.6.0.218965497612.issue6386@psf.upfronthosting.co.za>


New submission from jbeulich <jbeulich at novell.com>:

Due to the way PySys_SetArgv() works, when the initial script is a
symbolic link, importing from normal files in the same directory does
not work. This is particularly surprising when the work tree is a
symlinked clone (cp -s) of an original (i.e. snapshot) tree with a few
modifications (patches) applied to one or more of the modules imported
from: Due the the erratum, the modifications made will appear to not
take effect until one realizes that the wrong module is being imported from.

The solution would in my opinion be to not only add the path left after
the readlink()/realpath() processing to the import search path list, but
also any intermediately encountered ones (in the order processed) as
long as the leaf component continues to be a symlink.

(Note: It seems pointless to use readlink() in the current [3.1 and
earlier] implementation, since the result gets passed to realpath()
anyway. Also, the documentation doesn't seem to mention this behavior,
and from the sources it remains unclear why this processing is needed at
all.)

----------
messages: 89914
nosy: jbeulich
severity: normal
status: open
title: importing yields unexpected results when initial script is a symbolic link
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Tue Jun 30 12:55:42 2009
From: report at bugs.python.org (David Jones)
Date: Tue, 30 Jun 2009 10:55:42 +0000
Subject: [New-bugs-announce] [issue6387] floor division gives different
	result for int versus	float.
In-Reply-To: <1246359342.27.0.481159962703.issue6387@psf.upfronthosting.co.za>
Message-ID: <1246359342.27.0.481159962703.issue6387@psf.upfronthosting.co.za>


New submission from David Jones <drj at pobox.com>:

Consider: x//y != x//float(y) for some integer values of x and y.

For example, x = 2**54-1, and y = 2:

>>> x=2**54-1
>>> y=2
>>> x//y
9007199254740991L
>>> x//float(y)
9007199254740992.0
>>> _==x//y
False

I have no idea whether this should actually be a bug or not.  The 
behaviour (above) _is_ the documented behaviour (because the operands 
are documented as being converted to a common type).  But... I think 
there's a good case for computing the mathematically correct answer 
regardless of the types of the inputs.  For one thing, one of the 
reasons behind introducing the // operator was to make division the same 
regardless of whether the inputs were floating point or int.  Computing 
the mathematically correct answer (which since the answer is an integer 
is always exactly representable in Python) would be better, and simpler 
to document.

----------
components: Interpreter Core
messages: 89915
nosy: drj
severity: normal
status: open
title: floor division gives different result for int versus float.
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Jun 30 13:27:46 2009
From: report at bugs.python.org (Thomas Bleier)
Date: Tue, 30 Jun 2009 11:27:46 +0000
Subject: [New-bugs-announce] [issue6388] platform.python_implementation does
	not work on IronPython
In-Reply-To: <1246361266.54.0.86756549192.issue6388@psf.upfronthosting.co.za>
Message-ID: <1246361266.54.0.86756549192.issue6388@psf.upfronthosting.co.za>


New submission from Thomas Bleier <thomas at bleier.at>:

platform.python_implementation as of CPython 2.6 does not work on
IronPython 2.0.1

It obviously crashes because it fails determining that it run's on
IronPython.

>>> platform.python_implementation()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\IronPython2\Lib\platform.py", line 1409, in python_implementation
  File "C:\IronPython2\Lib\platform.py", line 1359, in _sys_version
ValueError: failed to parse CPython sys.version: '2.5.0 (IronPython 2.0
(2.0.0.0) on .NET 2.0.50727.4918)'

----------
components: Library (Lib)
messages: 89917
nosy: tbleier
severity: normal
status: open
title: platform.python_implementation does not work on IronPython
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Jun 30 17:49:03 2009
From: report at bugs.python.org (Michael)
Date: Tue, 30 Jun 2009 15:49:03 +0000
Subject: [New-bugs-announce] [issue6389] os.chmod() documentation refers to
	non-existent	documentation in stat
In-Reply-To: <1246376943.24.0.988862914661.issue6389@psf.upfronthosting.co.za>
Message-ID: <1246376943.24.0.988862914661.issue6389@psf.upfronthosting.co.za>


New submission from Michael <mhearne808 at yahoo.com>:

If you look at the documentation for os.chmod(), it says:
"mode may take one of the following values (as defined in the stat
module)..."

and then lists a number of constants from the stat module (stat.S_ISUID,
stat.S_ISGID, etc.)

I cannot seem to find these constants defined anywhere on the stat
module page.  May I suggest that these constants be defined in the
documentation for os.chmod(), to make it easier on the user?

----------
assignee: georg.brandl
components: Documentation
messages: 89932
nosy: georg.brandl, mhearne808
severity: normal
status: open
title: os.chmod() documentation refers to non-existent documentation in stat
versions: Python 2.6

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

From report at bugs.python.org  Tue Jun 30 18:52:50 2009
From: report at bugs.python.org (Brian Mearns)
Date: Tue, 30 Jun 2009 16:52:50 +0000
Subject: [New-bugs-announce] [issue6390] File reads past EOF in "w+b" mode
In-Reply-To: <1246380770.16.0.615703374982.issue6390@psf.upfronthosting.co.za>
Message-ID: <1246380770.16.0.615703374982.issue6390@psf.upfronthosting.co.za>


New submission from Brian Mearns <bmearns at ieee.org>:

Open a file in "w+b" mode: if you write to the file, then read from it
without seeking backward, it reads past the EOF, apparently out into
memory, which could be a pretty bad security concern. Have not checked
if "w+" mode does the same.

### Bad behavior...
>>> fid = open("temp", "w+b")
>>> fid.read()
''
>>> fid.write("foobar")
#Read while positioned on EOF
>>> fid.read(10)
'\xc2\x00\x00\x00\x00\x00\x00\x00\x00\x00'
>>> fid.seek(0)
>>> fid.read(10)
'foobar\xc2\x00\x00\x00'
>>> fid.close()

###Correct behavior after seeking backwards:
>>> fid = open("temp2", "w+b")
>>> fid.read()
''
>>> fid.write("foobar")
>>> fid.seek(0)
>>> fid.read(10)
'foobar'
>>> fid.close()

Interestingly, it appears that any seek works, you don't necessarily
have to go backwards:

>>> fid = open("temp2", "w+b")
>>> fid.write("foobar")
>>> fid.tell()
6L
>>> fid.seek(6)
>>> fid.read()
''

----------
components: IO
messages: 89941
nosy: bmearns
severity: normal
status: open
title: File reads past EOF in "w+b" mode
type: security
versions: Python 2.6

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

From report at bugs.python.org  Tue Jun 30 21:43:09 2009
From: report at bugs.python.org (En-Ran Zhou)
Date: Tue, 30 Jun 2009 19:43:09 +0000
Subject: [New-bugs-announce] [issue6391] Incorrect description of
	unittest.TestCase.run
In-Reply-To: <1246390989.67.0.115182745273.issue6391@psf.upfronthosting.co.za>
Message-ID: <1246390989.67.0.115182745273.issue6391@psf.upfronthosting.co.za>


New submission from En-Ran Zhou <zhouer at gmail.com>:

In Python 2.6 Document, Library reference 26.3 unittest
(http://docs.python.org/library/unittest.html#unittest.TestCase.run)
The description of TestCase.run method says that ``If result is omitted
or None, a temporary result object is created (by calling the
defaultTestCase() method) and used'', but I think it should be
defaultTestResult() instead of defaultTestCase().

----------
assignee: georg.brandl
components: Documentation
messages: 89948
nosy: georg.brandl, zhouer
severity: normal
status: open
title: Incorrect description of unittest.TestCase.run
versions: Python 2.6, Python 2.7

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