From report at bugs.python.org  Wed Oct  1 00:38:36 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Sep 2008 22:38:36 +0000
Subject: [New-bugs-announce] [issue4004] missing newline in "Could not
	convert argument %s to string" error message
In-Reply-To: <1222814316.77.0.949437896792.issue4004@psf.upfronthosting.co.za>
Message-ID: <1222814316.77.0.949437896792.issue4004@psf.upfronthosting.co.za>


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

Example:

$ ./python $(echo -e "\xff"); ./python $(echo -e "\xff"); echo "--"
Could not convert argument 1 to stringCould not convert argument 1 to 
string--

----------
files: argv_error_newline.patch
keywords: patch
messages: 74102
nosy: haypo
severity: normal
status: open
title: missing newline in "Could not convert argument %s to string" error message
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11668/argv_error_newline.patch

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

From report at bugs.python.org  Wed Oct  1 08:24:50 2008
From: report at bugs.python.org (James Mills)
Date: Wed, 01 Oct 2008 06:24:50 +0000
Subject: [New-bugs-announce] [issue4005] pydoc in web server mode tails at
	initial request
In-Reply-To: <1222842290.34.0.581261002226.issue4005@psf.upfronthosting.co.za>
Message-ID: <1222842290.34.0.581261002226.issue4005@psf.upfronthosting.co.za>


New submission from James Mills <prologic at shortcircuit.net.au>:

Trying to use pydoc in it's webserver mode fails:

$ pydoc3.0 -p 8000
pydoc server ready at http://localhost:8000/
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 42939)
Traceback (most recent call last):
  File "/usr/lib/python3.0/socketserver.py", line 281, in
_handle_request_noblock
    self.process_request(request, client_address)
  File "/usr/lib/python3.0/socketserver.py", line 307, in process_request
    self.finish_request(request, client_address)
  File "/usr/lib/python3.0/socketserver.py", line 320, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/lib/python3.0/socketserver.py", line 614, in __init__
    self.handle()
  File "/usr/lib/python3.0/http/server.py", line 363, in handle
    self.handle_one_request()
  File "/usr/lib/python3.0/http/server.py", line 357, in handle_one_request
    method()
  File "/usr/lib/python3.0/pydoc.py", line 1957, in do_GET
    indices.append(html.index(dir, seen))
  File "/usr/lib/python3.0/pydoc.py", line 929, in index
    for importer, name, ispkg in pkgutil.iter_modules([dir]):
  File "/usr/lib/python3.0/pkgutil.py", line 147, in iter_modules
    for name, ispkg in iter_importer_modules(i, prefix):
  File "/usr/lib/python3.0/pkgutil.py", line 325, in iter_zipimport_modules
    dirlist.sort()
AttributeError: 'dict_keys' object has no attribute 'sort'
----------------------------------------
pydoc server stopped

----------
components: Demos and Tools
messages: 74116
nosy: prologic
severity: normal
status: open
title: pydoc in web server mode tails at initial request
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Wed Oct  1 09:17:21 2008
From: report at bugs.python.org (Toshio Kuratomi)
Date: Wed, 01 Oct 2008 07:17:21 +0000
Subject: [New-bugs-announce] [issue4006] os.getenv silently discards env
	variables with non-UTF-8 values
In-Reply-To: <1222845441.08.0.104904424427.issue4006@psf.upfronthosting.co.za>
Message-ID: <1222845441.08.0.104904424427.issue4006@psf.upfronthosting.co.za>


New submission from Toshio Kuratomi <a.badger at gmail.com>:

On a Linux system with a locale setting whose encoding is utf-8, if you
set an environment variable to have a non-utf-8 chanacter, that
environment variable silently does not appear in os.environ::

mkdir ?
convmv -f utf-8 -t latin-1 --notest ?
for i in * ; do export PATH=$PATH:$i ; done
echo $PATH
/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/lib/ccache:/usr/local/bin:/usr/bin:/bin:/home/badger/bin:?
python3.0
Python 3.0rc1 (r30rc1:66499, Sep 28 2008, 08:21:09) 
[GCC 4.3.0 20080428 (Red Hat 4.3.0-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.environ['PATH']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.0/os.py", line 389, in __getitem__
    return self.data[self.keymap(key)]
KeyError: 'PATH'

I'm uncertain of the impact of this.  It was brought up in a discussion
of sending non-ASCii data to a CGI-WSGI script where the data would be
transferred via os.environ.

----------
components: Unicode
messages: 74118
nosy: a.badger
severity: normal
status: open
title: os.getenv silently discards env variables with non-UTF-8 values
type: behavior

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

From report at bugs.python.org  Wed Oct  1 14:52:38 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 01 Oct 2008 12:52:38 +0000
Subject: [New-bugs-announce] [issue4007] make clean fails to delete .a and
	.so.X.Y files
In-Reply-To: <1222865558.69.0.211492206559.issue4007@psf.upfronthosting.co.za>
Message-ID: <1222865558.69.0.211492206559.issue4007@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

The "clean" target in the makefile fails to delete the libpython.a file
and the libpython.so.X.Y file (should you have configured using
--enable-shared).  The attached trivial patch solves that problem.
The patch is against the trunk as of just before the 2.6 final release.
It will almost certainly apply cleanly to the py3k version as well.

----------
components: Build
keywords: easy, patch
messages: 74128
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: make clean fails to delete .a and .so.X.Y files
type: behavior

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

From report at bugs.python.org  Wed Oct  1 17:37:55 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Oct 2008 15:37:55 +0000
Subject: [New-bugs-announce] [issue4008] IDLE: checksyntax() doesn't support
	Unicode?
In-Reply-To: <1222875475.18.0.22602254781.issue4008@psf.upfronthosting.co.za>
Message-ID: <1222875475.18.0.22602254781.issue4008@psf.upfronthosting.co.za>


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

IDLE checksyntax() function doesn't support Unicode. Example with 
idle-3.0rc1-quits-when-run.py in an ASCII terminal:

$ ./python Tools/scripts/idle
Exception in Tkinter callback
Traceback (most recent call last):
  File "/home/haypo/prog/py3k/Lib/tkinter/__init__.py", line 1405, in 
__call__
    return self.func(*args)
  File "/home/haypo/prog/py3k/Lib/idlelib/ScriptBinding.py", line 124, 
in run_module_event
    code = self.checksyntax(filename)
  File "/home/haypo/prog/py3k/Lib/idlelib/ScriptBinding.py", line 86, 
in checksyntax
    source = f.read()
  File "/home/haypo/prog/py3k/Lib/io.py", line 1719, in read
    decoder.decode(self.buffer.read(), final=True))
  File "/home/haypo/prog/py3k/Lib/io.py", line 1294, in decode
    output = self.decoder.decode(input, final=final)
  File "/home/haypo/prog/py3k/Lib/encodings/ascii.py", line 26, in 
decode
    return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 
87: ordinal not in range(128)

To open an ASCII terminal on Linux, you can for example use xterm with 
an empty environment (except DISPLAY and HOME variables): "env -i 
DISPLAY=$DISPLAY HOME=$HOME xterm".

----------
components: IDLE
files: idle-3.0rc1-quits-when-run.py
messages: 74131
nosy: haypo
severity: normal
status: open
title: IDLE: checksyntax() doesn't support Unicode?
versions: Python 3.0
Added file: http://bugs.python.org/file11672/idle-3.0rc1-quits-when-run.py

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

From report at bugs.python.org  Wed Oct  1 17:41:24 2008
From: report at bugs.python.org (John)
Date: Wed, 01 Oct 2008 15:41:24 +0000
Subject: [New-bugs-announce] [issue4009] A Minor Glitch in the Documentation
In-Reply-To: <1222875684.11.0.0089536164395.issue4009@psf.upfronthosting.co.za>
Message-ID: <1222875684.11.0.0089536164395.issue4009@psf.upfronthosting.co.za>


New submission from John <fretai12345 at gmail.com>:

Hello,

I don't know why my previous bug report was ignored, but I must report 
this. Since this is a minor glitch, I hope it will be fixed. Please be 
so kind and fix this.

Please go here and see the 3rd code example:
http://docs.python.org/dev/3.0/library/functions.html?
highlight=property#property

class C(object):
    def __init__(self): self._x = None


All other lines in the code example are written in the way that the 
code block of the function definition is in the next line and properly 
indented. Please fix this little glitch. Thank you.

----------
assignee: georg.brandl
components: Documentation
messages: 74132
nosy: fretai, georg.brandl
severity: normal
status: open
title: A Minor Glitch in the Documentation
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Wed Oct  1 18:43:53 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 01 Oct 2008 16:43:53 +0000
Subject: [New-bugs-announce] [issue4010] configure options don't trickle
	down to distutils
In-Reply-To: <1222879433.22.0.765704464081.issue4010@psf.upfronthosting.co.za>
Message-ID: <1222879433.22.0.765704464081.issue4010@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

If you are fortunate enough to have all your third-party libraries in
a single quasi-standard location, say, /usr/local/lib, you will
probably have never encountered this problem, but setting environment
variables like LDFLAGS don't get translated into the relevant args for
the distutils build_ext command.  The evidence for this is this output
at the end of the make process:

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


    Failed to build these modules:
    _curses            _curses_panel      _tkinter
    gdbm               readline

Here's the specific failure for readline:

    >>> import readline_failed
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
	ImportError: ld.so.1: python: fatal: libreadline.so.4: open failed: No
such file or directory

yet if you poke around in my config.status file you'll see that I set
the relevant -L and -R flags:

    s, at LDFLAGS@,|#_!!_#|-L/opt/app/nonc++/ncurses-5.6/lib
-R/opt/app/nonc++/ncurses-5.6/lib -L/opt/app/nonc++/gdbm-1.8/lib
-R/opt/app/nonc++/gdbm-1.8/lib -L/opt/app/nonc++/readline-4.3/lib
-R/opt/app/nonc++/readline-4.3/lib -L/opt/app/nonc++/tcl-8.4/lib
-R/opt/app/nonc++/tcl-8.4/lib -L/opt/app/nonc++/BerkleyDB-4.3/lib
-R/opt/app/nonc++/BerkleyDB-4.3/lib,g

The workaround is to run the build_ext command separately:

    ./python ../setup.py build_ext --library-dirs=... --rpath=...

It's not hard to work around this problem, but it's tedious to build
the command line args from the massive list of directories I have to
educate distutils about.

----------
components: Build, Distutils
messages: 74137
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: configure options don't trickle down to distutils
type: behavior

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

From report at bugs.python.org  Wed Oct  1 23:31:05 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 01 Oct 2008 21:31:05 +0000
Subject: [New-bugs-announce] [issue4011] Create DAG for PEP 101
In-Reply-To: <1222896665.95.0.381960877122.issue4011@psf.upfronthosting.co.za>
Message-ID: <1222896665.95.0.381960877122.issue4011@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

PEP 101 says it would be nice to have a dependency graph that showed
what could and could not be done in parallel when cutting a release.
Should throw one together using OmniGraffle or Graphviz.

----------
assignee: brett.cannon
messages: 74147
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Create DAG for PEP 101

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

From report at bugs.python.org  Thu Oct  2 03:23:40 2008
From: report at bugs.python.org (Kent Johnson)
Date: Thu, 02 Oct 2008 01:23:40 +0000
Subject: [New-bugs-announce] [issue4012] Minor errors in multiprocessing docs
In-Reply-To: <1222910620.56.0.617350560863.issue4012@psf.upfronthosting.co.za>
Message-ID: <1222910620.56.0.617350560863.issue4012@psf.upfronthosting.co.za>


New submission from Kent Johnson <kent at kentsjohnson.com>:

In the docs for AsyncResult
http://docs.python.org/dev/library/multiprocessing.html#multiprocessing.pool.AsyncResult

"get([timeout)" is missing a ]

In the example following, it refers to pool.applyAsync() in two places;
the docs spell this apply_async(), one of them must be wrong :-)

----------
assignee: georg.brandl
components: Documentation
messages: 74150
nosy: georg.brandl, kjohnson
severity: normal
status: open
title: Minor errors in multiprocessing docs
versions: Python 2.6

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

From report at bugs.python.org  Thu Oct  2 12:14:39 2008
From: report at bugs.python.org (Koen van de Sande)
Date: Thu, 02 Oct 2008 10:14:39 +0000
Subject: [New-bugs-announce] [issue4013] Python 2.6 Doc/tools folder bigger
	than in 2.6rc2
In-Reply-To: <1222942479.13.0.732489569924.issue4013@psf.upfronthosting.co.za>
Message-ID: <1222942479.13.0.732489569924.issue4013@psf.upfronthosting.co.za>


New submission from Koen van de Sande <koen at tibed.net>:

The Doc/tools folder in the 2.6 distribution contains docutils, jinja, 
pygments, sphinx folders, which were not there in the 2.6rc2 .tar.bz2. 
Also, there is a roman.pyc in the Doc/tools folder. 

The difference in uncompressed size is about 9MB between 2.6 and 
2.6rc2. The difference in compressed size is 1.5MB. Perhaps including a 
fully functional doc build environment is intentional?

----------
assignee: georg.brandl
components: Documentation
messages: 74156
nosy: georg.brandl, koen
severity: normal
status: open
title: Python 2.6 Doc/tools folder bigger than in 2.6rc2
type: resource usage
versions: Python 2.6

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

From report at bugs.python.org  Thu Oct  2 13:03:33 2008
From: report at bugs.python.org (Koen van de Sande)
Date: Thu, 02 Oct 2008 11:03:33 +0000
Subject: [New-bugs-announce] [issue4014] Python-2.6-py2.6.egg-info contains
	Alpha reference
In-Reply-To: <1222945413.86.0.0834970306858.issue4014@psf.upfronthosting.co.za>
Message-ID: <1222945413.86.0.0834970306858.issue4014@psf.upfronthosting.co.za>


New submission from Koen van de Sande <koen at tibed.net>:

In file lib/python2.6/lib-dynload/Python-2.6-py2.6.egg-info, after a 
fresh installation of Python 2.6 there are two lines for Development 
status both Alpha and Mature:

Platform: Many
Classifier: Development Status :: 3 - Alpha
Classifier: Development Status :: 6 - Mature
Classifier: License :: OSI Approved :: Python Software Foundation 
License

This is found in line 1839 of http://svn.python.org/view/python/tags/
r26/setup.py?rev=66716&view=markup

----------
components: None
messages: 74157
nosy: koen
severity: normal
status: open
title: Python-2.6-py2.6.egg-info contains Alpha reference
versions: Python 2.6

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

From report at bugs.python.org  Thu Oct  2 14:12:08 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 02 Oct 2008 12:12:08 +0000
Subject: [New-bugs-announce] [issue4015] [patch] make installed scripts
	executable on windows
In-Reply-To: <1222949528.24.0.767744507339.issue4015@psf.upfronthosting.co.za>
Message-ID: <1222949528.24.0.767744507339.issue4015@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Distutils contains code to make scripts executable on posix platform.
Here is a patch to for the same feature for nt. It adds .bat file for
every script that doesn't have executable launcher.

----------
components: Distutils
files: create.bat.scripts.on.nt.patch
keywords: patch
messages: 74159
nosy: techtonik
severity: normal
status: open
title: [patch] make installed scripts executable on windows
versions: Python 2.6
Added file: http://bugs.python.org/file11676/create.bat.scripts.on.nt.patch

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

From report at bugs.python.org  Thu Oct  2 16:42:04 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Oct 2008 14:42:04 +0000
Subject: [New-bugs-announce] [issue4016] improve linecache: reuse
	tokenize.detect_encoding() and io.open()
In-Reply-To: <1222958524.04.0.862408977928.issue4016@psf.upfronthosting.co.za>
Message-ID: <1222958524.04.0.862408977928.issue4016@psf.upfronthosting.co.za>


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

linecache uses it own code to detect a Python script encoding whereas 
a function tokenize.detect_encoding() already exists. It does also 
convert bytes => unicode conversion of the file lines whereas open() 
already supports this feature.

----------
components: Library (Lib)
files: linecache_refactor.patch
keywords: patch
messages: 74165
nosy: haypo
severity: normal
status: open
title: improve linecache: reuse tokenize.detect_encoding() and io.open()
versions: Python 3.0
Added file: http://bugs.python.org/file11678/linecache_refactor.patch

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

From report at bugs.python.org  Thu Oct  2 17:16:30 2008
From: report at bugs.python.org (Fabio FZero)
Date: Thu, 02 Oct 2008 15:16:30 +0000
Subject: [New-bugs-announce] [issue4017] IDLE 2.6 broken on OSX (Leopard)
In-Reply-To: <1222960590.08.0.635891151551.issue4017@psf.upfronthosting.co.za>
Message-ID: <1222960590.08.0.635891151551.issue4017@psf.upfronthosting.co.za>


New submission from Fabio FZero <fabio.fzero+python at gmail.com>:

I've just installed Python 2.6 on Mac OS X 10.5.5 and IDLE won't start.
IDLE 2.5 still works fine.

Here's the traceback:

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/Current/bin/idle",
line 3, in <module>
    from idlelib.PyShell import main
  File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/idlelib/PyShell.py",
line 14, in <module>
    import macosxSupport
  File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/idlelib/macosxSupport.py",
line 6, in <module>
    import Tkinter
  File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-tk/Tkinter.py",
line 39, in <module>
    import _tkinter # If this fails your Python may not be configured for Tk
ImportError:
dlopen(/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_tkinter.so,
2): Library not loaded: /Library/Frameworks/Tcl.framework/Versions/8.5/Tcl
  Referenced from:
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_tkinter.so
  Reason: image not found

----------
components: IDLE
messages: 74166
nosy: fzero
severity: normal
status: open
title: IDLE 2.6 broken on OSX (Leopard)
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Thu Oct  2 18:06:12 2008
From: report at bugs.python.org (John Ehresman)
Date: Thu, 02 Oct 2008 16:06:12 +0000
Subject: [New-bugs-announce] [issue4018] "for me" installer problem on x64
	Vista
In-Reply-To: <1222963572.56.0.515590438992.issue4018@psf.upfronthosting.co.za>
Message-ID: <1222963572.56.0.515590438992.issue4018@psf.upfronthosting.co.za>


New submission from John Ehresman <jpe at wingware.com>:

After installing the 32 bit .msi or the 64 bit .msi "for me" on a fairly
clean Vista x64 machine, the socket module won't import because of a
side-by-side configuration error.  The output below is from the 32 bit
build.

Microsoft Windows [Version 6.0.6000]
Copyright (c) 2006 Microsoft Corporation.  All rights reserved.

C:\Users\maint>\python26\python
Python 2.6 (r26:66721, Oct  2 2008, 11:35:03) [MSC v.1500 32 bit
(Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\python26\lib\socket.py", line 46, in <module>
    import _socket
ImportError: DLL load failed: The application has failed to start
because its si
de-by-side configuration is incorrect. Please see the application event
log for
more detail.
>>>

The event log entry for this is:
Activation context generation failed for
"C:\python26\DLLs\_socket.pyd".Error in manifest or policy file
"C:\python26\DLLs\Microsoft.VC90.CRT.MANIFEST" on line 12. The value
"../msvcr90.dll" of attribute "name" in element
"urn:schemas-microsoft-com:asm.v1^file" is invalid.

Changing ../msvcr90.dll to ..\msvcr90.dll does not fix the problem

Importing socket does work when the msi is installed for everyone.

----------
components: Windows
messages: 74168
nosy: jpe
severity: normal
status: open
title: "for me" installer problem on x64 Vista
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Oct  2 18:34:58 2008
From: report at bugs.python.org (Craig Holmquist)
Date: Thu, 02 Oct 2008 16:34:58 +0000
Subject: [New-bugs-announce] [issue4019] 2.6 (final) uses old icons in Start
	Menu
In-Reply-To: <1222965298.37.0.497940779276.issue4019@psf.upfronthosting.co.za>
Message-ID: <1222965298.37.0.497940779276.issue4019@psf.upfronthosting.co.za>


New submission from Craig Holmquist <craig at neurotronics.com>:

The Start Menu icons created by the Python 2.6 installer use the old
icons (the green snake, 4-bit color) instead of the new ones (blue and
yellow snake, 24-bit color).  This was observed on Windows XP.  An
installation of 2.5.2 on the same machine uses the new icons.

----------
components: Installation
messages: 74171
nosy: craigneuro
severity: normal
status: open
title: 2.6 (final) uses old icons in Start Menu
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Oct  2 21:06:41 2008
From: report at bugs.python.org (Xore)
Date: Thu, 02 Oct 2008 19:06:41 +0000
Subject: [New-bugs-announce] [issue4020] hasattr boundary case failure
In-Reply-To: <1222974401.06.0.475431208448.issue4020@psf.upfronthosting.co.za>
Message-ID: <1222974401.06.0.475431208448.issue4020@psf.upfronthosting.co.za>


New submission from Xore <xore.ander at gmail.com>:

http://www.python.org/doc/2.5.2/lib/built-in-funcs.html#l2h-35

"(This is implemented by calling getattr(object, name) and seeing
whether it raises an exception or not.)"

If a property exists but it's retrieval throws some error, hasattr will
interpret this as the property not existing, since it only checks for
the existence of an error, not an AttributeError

<code>
class test:
    @property
    def prop(self):
        # do stuff
        raise ZeroDivisionError # an example

foobar = test()

assert hasattr(foobar, "prop")
</code>

----------
messages: 74187
nosy: Xore
severity: normal
status: open
title: hasattr boundary case failure
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Fri Oct  3 01:00:33 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Oct 2008 23:00:33 +0000
Subject: [New-bugs-announce] [issue4021] tokenize.detect_encoding(): raise
	SyntaxError on codecs.lookup() error
In-Reply-To: <1222988433.37.0.412294241613.issue4021@psf.upfronthosting.co.za>
Message-ID: <1222988433.37.0.412294241613.issue4021@psf.upfronthosting.co.za>


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

tokenize.detect_encoding() raises a LookupError() if the charset is 
unknown whereas Python raises a SyntaxError. So this patch mimics 
Python behaviour for tokenize module.

Extra: reuse BOM_UTF8 from the codecs module.

----------
files: tokenize_detect_encoding.patch
keywords: patch, patch
messages: 74205
nosy: haypo
severity: normal
status: open
title: tokenize.detect_encoding(): raise SyntaxError on codecs.lookup() error
versions: Python 3.0
Added file: http://bugs.python.org/file11683/tokenize_detect_encoding.patch

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

From report at bugs.python.org  Fri Oct  3 01:15:42 2008
From: report at bugs.python.org (Armando Rowe)
Date: Thu, 02 Oct 2008 23:15:42 +0000
Subject: [New-bugs-announce] [issue4022] 2.6 dependent on c:\python26\ on
	windows
In-Reply-To: <1222989342.94.0.529774628368.issue4022@psf.upfronthosting.co.za>
Message-ID: <1222989342.94.0.529774628368.issue4022@psf.upfronthosting.co.za>


New submission from Armando Rowe <armando.rowe at gmail.com>:

The windows installer for Python 2.6 offers to install on c:\python26\ -
If you chose to install on c:\python\ instead, the installation will run
through and terminate succesfully, but whenever you try executing any
python program, an error message tells you that mvscr90.dll is missing.

It turns out the installer does properly install the dll in a subfolder
of c:\windows\winsxs.

If you remove python, then install on c:\python26\, it will work just fine.

Event occurred on a Dell latitude D620 laptop with 2 GB RAM and a 2 GHz
intel core duo, with Windows XP professional Service Pack 3. No python
packages were installed.

----------
components: Build
messages: 74209
nosy: armandorowe
severity: normal
status: open
title: 2.6 dependent on c:\python26\ on windows
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Oct  3 01:22:19 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Oct 2008 23:22:19 +0000
Subject: [New-bugs-announce] [issue4023] convert os.getcwdu() to os.getcwd(),
	and getcwdu() to getcwd()
In-Reply-To: <1222989739.85.0.364233815039.issue4023@psf.upfronthosting.co.za>
Message-ID: <1222989739.85.0.364233815039.issue4023@psf.upfronthosting.co.za>


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

Python3 removes os.getcwdu() and introduces os.getcwdb(). The patch is 
a fixer for lib2to3 replacing "os.getcwdu()" to "os.getcwd()", 
and "getcwdu()" to "getcwd()". I hope that nobody defined its 
own "getcwdu()" function :-)

Example:
----
cwd = os.getcwdu()
print "cwd=%s" % cwd

from os import getcwdu
cwd = getcwdu()
print "cwd=%s" % cwd
----

Result:
-----
 import os
-cwd = os.getcwdu()
-print "cwd=%s" % cwd
+cwd = os.getcwd()
+print("cwd=%s" % cwd)

-from os import getcwdu
-cwd = getcwdu()
-print "cwd=%s" % cwd
+from os import getcwd
+cwd = getcwd()
+print("cwd=%s" % cwd)
-----

----------
assignee: benjamin.peterson
components: 2to3 (2.x to 3.0 conversion tool)
keywords: patch
messages: 74211
nosy: benjamin.peterson, haypo
severity: normal
status: open
title: convert os.getcwdu() to os.getcwd(), and getcwdu() to getcwd()
versions: Python 3.0

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

From report at bugs.python.org  Fri Oct  3 05:25:06 2008
From: report at bugs.python.org (lplatypus)
Date: Fri, 03 Oct 2008 03:25:06 +0000
Subject: [New-bugs-announce] [issue4024] float(0.0) singleton
In-Reply-To: <1223004306.88.0.574076862856.issue4024@psf.upfronthosting.co.za>
Message-ID: <1223004306.88.0.574076862856.issue4024@psf.upfronthosting.co.za>


New submission from lplatypus <luke at deller.id.au>:

Here is a patch to make PyFloat_FromDouble(0.0) always return the same 
float instance.  This is similar to the existing optimization in 
PyInt_FromLong(x) for small x.

My own motivation is that the patch reduces memory by several megabytes 
for a particular in-house data processing script, but I think that it 
should be generally useful assuming that zero is a very common float 
value, and at worst almost neutral when this assumption is wrong.  The 
minimal performance impact of the test for zero should be easily 
recovered by reduced memory allocation calls.  I am happy to look into 
benchmarking if you require empirical performance data.

----------
components: Interpreter Core
files: python_zero_float.patch
keywords: patch
messages: 74224
nosy: ldeller
severity: normal
status: open
title: float(0.0) singleton
type: resource usage
versions: Python 2.6
Added file: http://bugs.python.org/file11686/python_zero_float.patch

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

From report at bugs.python.org  Fri Oct  3 10:15:05 2008
From: report at bugs.python.org (David Jones)
Date: Fri, 03 Oct 2008 08:15:05 +0000
Subject: [New-bugs-announce] [issue4025] C99 comments in Python 2.6 break
	build on AIX 6.1
In-Reply-To: <1223021705.78.0.0680927211456.issue4025@psf.upfronthosting.co.za>
Message-ID: <1223021705.78.0.0680927211456.issue4025@psf.upfronthosting.co.za>


New submission from David Jones <drj at pobox.com>:

Doing a plan "configure" then "make"; the compilation breaks due to // 
style comments in a file called Objects/frameobject.c:

cc_r -qlanglvl=extc89 -c  -DNDEBUG -O  -I. -IInclude -I./Include   -
DPy_BUILD_CORE -o Objects/frameobject.o Objects/frameobject.c
"Objects/frameobject.c", line 520.9: 1506-046 (S) Syntax error.

Full transcript attached.

Furthermore, attempting to select a more permissive (better?) compiler, 
with "CC=c99 ./configure --without-gcc" for example, doesn't work 
because of the bug reported in http://bugs.python.org/issue1633863 (CC 
is ignored).  I will comment separately in that issue.

It is my understanding (per my blog article http://drj11.wordpress.com/2008/10/02/python-and-bragging-about-c89/ ) 
that the code is now c89 clean (or at least as clean as ?gcc -std=c89 -
Werror? can make it.  That means you should be able to close this bug 
fairly quickly. :)

After I've hacked the configure script the build still fails, but for 
different reasons.  I'll file another bug for that.

----------
components: Interpreter Core
files: py26aix61script1
messages: 74229
nosy: drj
severity: normal
status: open
title: C99 comments in Python 2.6 break build on AIX 6.1
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file11687/py26aix61script1

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

From report at bugs.python.org  Fri Oct  3 10:32:43 2008
From: report at bugs.python.org (David Jones)
Date: Fri, 03 Oct 2008 08:32:43 +0000
Subject: [New-bugs-announce] [issue4026] fcntl extension fails to build on
	AIX 6.1
In-Reply-To: <1223022763.11.0.245770368063.issue4026@psf.upfronthosting.co.za>
Message-ID: <1223022763.11.0.245770368063.issue4026@psf.upfronthosting.co.za>


New submission from David Jones <drj at pobox.com>:

After hacking the configure script to work around the issues http://bugs.python.org/issue4025 and http://bugs.python.org/issue1633863 
the build still fails:

building 'fcntl' extension
xlc_r -DNDEBUG -O -I. -I/home/u0006584/Python-2.6/./Include -I. -
IInclude -I./Include -I/home/u0006584/Python-2.6/Include -
I/home/u0006584/Python-2.6 -c /home/u0006584/Python-
2.6/Modules/fcntlmodule.c -o build/temp.aix-6.1-
2.6/home/u0006584/Python-2.6/Modules/fcntlmodule.o
./Modules/ld_so_aix xlc_r -bI:Modules/python.exp build/temp.aix-6.1-
2.6/home/u0006584/Python-2.6/Modules/fcntlmodule.o -o build/lib.aix-6.1-
2.6/fcntl.so
ld: 0711-317 ERROR: Undefined symbol: .flock
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more 
information.
*** WARNING: renaming "fcntl" since importing it failed:        0509-022 
Cannot load module build/lib.aix-6.1-2.6.
        0509-026 System error: A file or directory in the path name does 
not exist.
error: No such file or directory
make: 1254-004 The error code from the last command is 1.

(Full transcript attached)

I'm mystified and I can't log in to the AIX box right now.

This does not appear to be the same as http://bugs.python.org/issue1756343 and http://bugs.python.org/issue1694442 which both appear to be the same, 
but documenting a differen AIX build problem.

----------
files: py26aix61script2
messages: 74231
nosy: drj
severity: normal
status: open
title: fcntl extension fails to build on AIX 6.1
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file11688/py26aix61script2

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

From report at bugs.python.org  Fri Oct  3 11:41:16 2008
From: report at bugs.python.org (Ray Wang)
Date: Fri, 03 Oct 2008 09:41:16 +0000
Subject: [New-bugs-announce] [issue4027] wrong page index number in
	reference book of python documentation
In-Reply-To: <1223026876.14.0.133212410345.issue4027@psf.upfronthosting.co.za>
Message-ID: <1223026876.14.0.133212410345.issue4027@psf.upfronthosting.co.za>


New submission from Ray Wang <wanglei1123 at gmail.com>:

the Glossary's index number is 3, which should be 75,
so people could not navigate "Glossary" by clicking the title showed in
Table of Content, or index link which is beside the content in Evince.

----------
assignee: georg.brandl
components: Documentation
files: ref.png
messages: 74233
nosy: georg.brandl, ray
severity: normal
status: open
title: wrong page index number in reference book of python documentation
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11689/ref.png

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

From report at bugs.python.org  Fri Oct  3 15:14:20 2008
From: report at bugs.python.org (JB Robertson)
Date: Fri, 03 Oct 2008 13:14:20 +0000
Subject: [New-bugs-announce] [issue4028] Problem compiling the
	multiprocessing module on sunos5
In-Reply-To: <1223039660.71.0.470025758339.issue4028@psf.upfronthosting.co.za>
Message-ID: <1223039660.71.0.470025758339.issue4028@psf.upfronthosting.co.za>


New submission from JB Robertson <jr244 at kent.ac.uk>:

Hello,

there's some issues compiling the multiprocessing module on the SunOS I
have here, where CMSG_LEN, CMSG_ALIGN, CMSG_SPACE and sem_timedwait are
absent.

$ uname -av
SunOS xxxxxxx 5.9 Generic_117171-15 sun4u sparc SUNW,Sun-Fire-V440

it looks like simply defining the first three macros like this works:
#ifndef CMSG_SPACE
#   define CMSG_SPACE(len) (CMSG_ALIGN(sizeof(struct
cmsghdr))+CMSG_ALIGN(len))
#endif

#ifndef CMSG_ALIGN
#   ifdef __sun__
#       define CMSG_ALIGN _CMSG_DATA_ALIGN
#   else
#       define CMSG_ALIGN(len) (((len)+sizeof(long)-1) & ~(sizeof(long)-1))
#   endif
#endif

#ifndef CMSG_LEN
#   define CMSG_LEN(len) (CMSG_ALIGN(sizeof(struct cmsghdr))+(len))
#endif

(from http://mailman.videolan.org/pipermail/vlc-devel/2006-May/024400.html )

and setting HAVE_SEM_TIMEDWAIT=0 in setup.py does the trick for the last
one.  Presumably, adding something like 

    elif platform.startswith('sunos5'):
        macros = dict(
                HAVE_SEM_OPEN=1,
                HAVE_SEM_TIMEDWAIT=0,
                HAVE_FD_TRANSFER=1
                )
        libraries = ['rt']

in setup.py should work, but I have no other SunOS machines to test this on.

thanks

----------
components: Extension Modules
messages: 74248
nosy: jr244
severity: normal
status: open
title: Problem compiling the multiprocessing module on sunos5
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Fri Oct  3 16:17:29 2008
From: report at bugs.python.org (David W. Lambert)
Date: Fri, 03 Oct 2008 14:17:29 +0000
Subject: [New-bugs-announce] [issue4029] Documentation displays incorrectly
	in iexplore.
In-Reply-To: <1223043449.43.0.741779453712.issue4029@psf.upfronthosting.co.za>
Message-ID: <1223043449.43.0.741779453712.issue4029@psf.upfronthosting.co.za>


New submission from David W. Lambert <lambertdw at corning.com>:

I use IEXPLORE version 6.0.2900.2180.xpsp_sp2_gdr.-70227-2254CO 
without any known customizations and have observed 3 display 
problems.  (And since I guess that the python html libraries generated 
the manuals, could these libraries be improved?)

1) The browser ties underscores together into an underline making them 
hard to count.

2) The horizontal position of the quick links depends on the browser 
window width.  Very narrow and they hide themselves beyond the right 
window edge.  Sufficiently wide and they fit into the left margin 
where they sensibly belong.  At a comfortable reading width they 
overlap the text.  See picture.

3) The "print" function heading displays incorrectly.  Please view the 
attached picture.  Backslashes seem to display correctly elsewhere in 
the various normal texts throughout the documents.  Also the space 
character would be more obvious in a fixed width font.

Thanks,
Dave.

----------
assignee: georg.brandl
components: Documentation
files: linksCanOverlapText.bmp
messages: 74251
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: Documentation displays incorrectly in iexplore.
versions: Python 3.0
Added file: http://bugs.python.org/file11692/linksCanOverlapText.bmp

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

From report at bugs.python.org  Fri Oct  3 16:39:25 2008
From: report at bugs.python.org (Manatsawin Hanmongkolchai)
Date: Fri, 03 Oct 2008 14:39:25 +0000
Subject: [New-bugs-announce] [issue4030] msi installer does not requires UAC
	permission on Vista
In-Reply-To: <1223044765.27.0.112047586653.issue4030@psf.upfronthosting.co.za>
Message-ID: <1223044765.27.0.112047586653.issue4030@psf.upfronthosting.co.za>


New submission from Manatsawin Hanmongkolchai <manatsawin at gmail.com>:

Hello, the Python 2.6 installer on Vista does not requires UAC
permission thus does not work with "install for All user" option.

The installer said: You do not have sufficient privilleges to completes
the installation for all users of the machine. Log on as administrator
and then retry this installation.

----------
components: Installation
messages: 74252
nosy: willwill
severity: normal
status: open
title: msi installer does not requires UAC permission on Vista
versions: Python 2.6

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

From report at bugs.python.org  Fri Oct  3 18:43:44 2008
From: report at bugs.python.org (patricio)
Date: Fri, 03 Oct 2008 16:43:44 +0000
Subject: [New-bugs-announce] [issue4031] 08 value popups an stdin error,
	no date handle allowed
In-Reply-To: <1223052224.4.0.0197033611138.issue4031@psf.upfronthosting.co.za>
Message-ID: <1223052224.4.0.0197033611138.issue4031@psf.upfronthosting.co.za>


New submission from patricio <patriciogimelli at yahoo.com.ar>:

a = 08
 print a
 File"<stdin>",line 1
 a = 08
      <
 syntax error:invalid token

(if I use 07, the 0 is supressed but it compiles & display the 7)

----------
messages: 74258
nosy: pgimelli
severity: normal
status: open
title: 08 value popups an stdin error, no date handle allowed
type: compile error
versions: Python 2.5

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

From report at bugs.python.org  Fri Oct  3 19:38:54 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 03 Oct 2008 17:38:54 +0000
Subject: [New-bugs-announce] [issue4032] disutils cannot recognize ".dll.a"
	as library on cygwin
In-Reply-To: <1223055534.39.0.439061882395.issue4032@psf.upfronthosting.co.za>
Message-ID: <1223055534.39.0.439061882395.issue4032@psf.upfronthosting.co.za>


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

This issue is derived from issue1706863.

----------
components: Distutils
messages: 74265
nosy: amaury.forgeotdarc, ghaering, jlt63, ocean-city, rpetrov, tan2, vitalyy2000
severity: normal
status: open
title: disutils cannot recognize ".dll.a" as library on cygwin
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Fri Oct  3 23:15:09 2008
From: report at bugs.python.org (jolleyjoe)
Date: Fri, 03 Oct 2008 21:15:09 +0000
Subject: [New-bugs-announce] [issue4033] python search path - .pth recursion
In-Reply-To: <1223068509.57.0.8948521791.issue4033@psf.upfronthosting.co.za>
Message-ID: <1223068509.57.0.8948521791.issue4033@psf.upfronthosting.co.za>


New submission from jolleyjoe <chanj at colorado.edu>:

I have an a.pth file in dir_a with a line that says:

dir_b

In dir_b, I have a b.pth file that lists some eggs in dir_b:

JCC-1.9-py2.5-linux-i686.egg
lucene-2.3.2-py2.5-linux-i686.egg

>From http://www.python.org/doc/2.5.2/inst/search-path.html:
"Paths can be absolute or relative, in which case they're relative to
the directory containing the .pth file. Any directories added to the
search path will be scanned in turn for .pth files. See site module
documentation for more information."

I assume that .pth files are scanned recursively... is this true?

I found an old ticket here: http://bugs.python.org/issue1431, but it
wasn't clear how it concludes (ie: do .pth files get scanned recursively
for directories to add to the search path or not).

----------
assignee: georg.brandl
components: Documentation
messages: 74274
nosy: georg.brandl, jolleyjoe
severity: normal
status: open
title: python search path - .pth recursion
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Sat Oct  4 01:31:59 2008
From: report at bugs.python.org (Greg Hazel)
Date: Fri, 03 Oct 2008 23:31:59 +0000
Subject: [New-bugs-announce] [issue4034] traceback attribute error
In-Reply-To: <1223076719.45.0.395696576555.issue4034@psf.upfronthosting.co.za>
Message-ID: <1223076719.45.0.395696576555.issue4034@psf.upfronthosting.co.za>


New submission from Greg Hazel <ghazel at users.sourceforge.net>:

Unrelated to this bug, I would like to have the ability to remove the 
reference to the frame from the traceback object. Specifically so that 
the traceback object could be stored for a while without keeping all 
the locals alive as well.

So, periodically I test to see if python allows that. Python 2.6 gave 
some strange results compared to 2.5.2:

Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> try:
...     x = dskjfds
... except:
...     import sys
...     t, v, tb = sys.exc_info()
...
>>> tb
<traceback object at 0x01396670>
>>> dir(tb)
['tb_frame', 'tb_lasti', 'tb_lineno', 'tb_next']
>>> tb.tb_frame
<frame object at 0x01371598>
>>> tb.tb_frame = None
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'traceback' object has only read-only attributes (assign 
to .tb_frame)
>>>


Python 2.6 (r26:66721, Oct  2 2008, 11:35:03) [MSC v.1500 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> try:
...     x = lfdskf
... except:
...     import sys
...     t, v, tb = sys.exc_info()
...
>>> tb
<traceback object at 0x01581F80>
>>> dir(tb)
['tb_frame', 'tb_lasti', 'tb_lineno', 'tb_next']
>>> tb.tb_frame
<frame object at 0x013B9E10>
>>> tb.tb_frame = None
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'traceback' object has no attribute 'tb_frame'
>>>

----------
messages: 74282
nosy: ghazel
severity: normal
status: open
title: traceback attribute error
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Oct  4 01:38:24 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Oct 2008 23:38:24 +0000
Subject: [New-bugs-announce] [issue4035] Support bytes for os.exec*()
In-Reply-To: <1223077104.22.0.62328245443.issue4035@psf.upfronthosting.co.za>
Message-ID: <1223077104.22.0.62328245443.issue4035@psf.upfronthosting.co.za>


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

os.exec*() functions doesn't support bytes if the program name doesn't 
use absolute path. The problem is that PATH is used to complete the 
full path but Python3 disallows bytes+str (which is a good thing!). 
Example:

python -c "import os; os.execvp('pwd', 'pwd')"
Traceback (most recent call last):
  ...
  File "/home/haypo/prog/py3k/Lib/os.py", line 328, in execvp
    _execvpe(file, args)
  File "/home/haypo/prog/py3k/Lib/os.py", line 364, in _execvpe
    func(fullname, *argrest)
TypeError: execv() arg 2 must be a tuple or list

Attached patch allows bytes in os.exec*(). It converts each directory 
of PATH using sys.getfilesystemencoding().

----------
files: os_exec_bytes.patch
keywords: patch, patch
messages: 74283
nosy: haypo
severity: normal
status: open
title: Support bytes for os.exec*()
versions: Python 3.0
Added file: http://bugs.python.org/file11695/os_exec_bytes.patch

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

From report at bugs.python.org  Sat Oct  4 01:45:15 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Oct 2008 23:45:15 +0000
Subject: [New-bugs-announce] [issue4036] Support bytes for subprocess.Popen()
In-Reply-To: <1223077515.41.0.60688229915.issue4036@psf.upfronthosting.co.za>
Message-ID: <1223077515.41.0.60688229915.issue4036@psf.upfronthosting.co.za>


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

subprocess doesn't support bytes for the "args" argument.
 - On Windows, subprocess._execute_child() converts args to a string 
if it was a list
 - On UNIX, subprocess._execute_child() converts args to a list if 
it's a string

If shell=True, _execute_child() adds a prefix to the arguments.

I don't know if subprocess should accept bytes in a command line. 
Attached patch fixes POSIX version of subprocess to support bytes.

See also related issue #4035.

----------
files: os_exec_bytes.patch
keywords: patch, patch
messages: 74284
nosy: haypo
severity: normal
status: open
title: Support bytes for subprocess.Popen()
versions: Python 3.0
Added file: http://bugs.python.org/file11696/os_exec_bytes.patch

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

From report at bugs.python.org  Sat Oct  4 02:13:26 2008
From: report at bugs.python.org (daaku)
Date: Sat, 04 Oct 2008 00:13:26 +0000
Subject: [New-bugs-announce] [issue4037] doctest.py should include method
	descriptors when looking inside a class __dict__
In-Reply-To: <1223079206.04.0.17382541424.issue4037@psf.upfronthosting.co.za>
Message-ID: <1223079206.04.0.17382541424.issue4037@psf.upfronthosting.co.za>


New submission from daaku <n at daaku.org>:

doctest.py currently does not include doctests from method descriptors 
in a class.

The patch is simple, in the _find function in class DocTestFinder:

Original:
                # Recurse to methods, properties, and nested classes.
                if ((inspect.isfunction(val) or inspect.isclass(val) or
                      isinstance(val, property)) and
                      self._from_module(module, val)):

Patched:
                # Recurse to methods, properties, and nested classes.
                if ((inspect.isfunction(val) or inspect.isclass(val) or
                      inspect.ismethoddescriptor(val) or
                      isinstance(val, property)) and
                      self._from_module(module, val)):

Adding the "inspect.ismethoddescriptor(val) or" line.

----------
components: Library (Lib)
messages: 74285
nosy: daaku
severity: normal
status: open
title: doctest.py should include method descriptors when looking inside a class __dict__
versions: Python 2.6

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

From report at bugs.python.org  Sat Oct  4 02:55:56 2008
From: report at bugs.python.org (Mark Hammond)
Date: Sat, 04 Oct 2008 00:55:56 +0000
Subject: [New-bugs-announce] [issue4038] py3k error in distutils file_copy
	exception handlers
In-Reply-To: <1223081756.15.0.501609436342.issue4038@psf.upfronthosting.co.za>
Message-ID: <1223081756.15.0.501609436342.issue4038@psf.upfronthosting.co.za>


New submission from Mark Hammond <mhammond at users.sourceforge.net>:

All the exception handlers i dustutils.file_utils._copy_file_contents()
are of the form:

|except os.error as e:
|    (errno, errstr) = e

This fails to unpack the exception in py3k.  I'm attaching a patch that
uses exception attributes rather than unpacking e.args.  FWIW, one of
these exceptions in particular is likely to get hit on Windows if the
destination file is in use, as Windows can't replace such files.  This
isn't a huge problem in practice as it only hits when an error occurs.

----------
components: Distutils
files: file_util_exceptions.patch
keywords: needs review, patch, patch
messages: 74292
nosy: mhammond
priority: normal
severity: normal
status: open
title: py3k error in distutils file_copy exception handlers
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11699/file_util_exceptions.patch

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

From report at bugs.python.org  Sat Oct  4 13:06:33 2008
From: report at bugs.python.org (peppergrower)
Date: Sat, 04 Oct 2008 11:06:33 +0000
Subject: [New-bugs-announce] [issue4039] Add __enter__ and __exit__ methods
	to StringIO/cStringIO classes
In-Reply-To: <1223118393.0.0.542108397821.issue4039@psf.upfronthosting.co.za>
Message-ID: <1223118393.0.0.542108397821.issue4039@psf.upfronthosting.co.za>


New submission from peppergrower <mjjohnson.geo at yahoo.com>:

Currently, StringIO objects do not have __enter__ and __exit__ methods
associated with them.  As a result, the 'with' statement won't work
properly on StringIO objects in a construction like the following,
though they can otherwise be manipulated like files:

with obj.open_file(...) as f:
    ... 

(I brought up this behavior first on comp.lang.python,* and the above
example was borrowed from Hrvoje Niksic.)  To allow StringIO objects to
be used more interchangeably with actual file objects, could __enter__
and __exit__ methods be added?

Thanks,
peppergrower

*
http://groups.google.com/group/comp.lang.python/browse_thread/thread/6bdf65bce431e404/a5dc64f43147f4dd?lnk=gst

----------
components: Interpreter Core
messages: 74309
nosy: peppergrower
severity: normal
status: open
title: Add __enter__ and __exit__ methods to StringIO/cStringIO classes
type: feature request
versions: Python 2.5

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

From report at bugs.python.org  Sat Oct  4 17:21:29 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 04 Oct 2008 15:21:29 +0000
Subject: [New-bugs-announce] [issue4040] ignored exceptions in generators
	(regression?)
In-Reply-To: <1223133689.63.0.365168051222.issue4040@psf.upfronthosting.co.za>
Message-ID: <1223133689.63.0.365168051222.issue4040@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

Given this code:

def f():
    for i in f():
        yield i

for i in f(): print i

2.6 gives:
Exception RuntimeError: 'maximum recursion depth exceeded in
__subclasscheck__' in <type 'exceptions.RuntimeError'> ignored
Exception RuntimeError: 'maximum recursion depth exceeded while calling
a Python object' in <type 'exceptions.RuntimeError'> ignored
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
...
  File "<stdin>", line 2, in f
RuntimeError: maximum recursion depth exceeded

2.5 and 3.0 do not have this problem.

----------
messages: 74314
nosy: benjamin.peterson
priority: high
severity: normal
status: open
title: ignored exceptions in generators (regression?)
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Sat Oct  4 20:20:31 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Sat, 04 Oct 2008 18:20:31 +0000
Subject: [New-bugs-announce] [issue4041] reference to rexec in __import__
In-Reply-To: <1223144431.92.0.531332933885.issue4041@psf.upfronthosting.co.za>
Message-ID: <1223144431.92.0.531332933885.issue4041@psf.upfronthosting.co.za>


New submission from Winfried Plappert <Winfried.Plappert at gmx.de>:

on the web page http://docs.python.org/library/functions.html,
__import__ references rexec why and how one could use __import__. On the
rexec page (http://docs.python.org/library/rexec.html) it says:
"Deprecated since version 2.6". I think one should not really refer to
deprecated functions in the current documentation.

----------
assignee: georg.brandl
components: Documentation
messages: 74316
nosy: georg.brandl, wplappert
severity: normal
status: open
title: reference to rexec in __import__
versions: Python 2.6

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

From report at bugs.python.org  Sun Oct  5 00:07:53 2008
From: report at bugs.python.org (Robert Yodlowski)
Date: Sat, 04 Oct 2008 22:07:53 +0000
Subject: [New-bugs-announce] [issue4042] IDLE won't start in 2.6 final. A
	known fix was overlooked?
In-Reply-To: <1223158073.65.0.65937344153.issue4042@psf.upfronthosting.co.za>
Message-ID: <1223158073.65.0.65937344153.issue4042@psf.upfronthosting.co.za>


New submission from Robert Yodlowski <rbtyod at gmail.com>:

I just installed the 2.6 final release on my fully updated Win XP
system. When I tried to run IDLE I got the same... 

"IDLE's subprocess didn't make connection. Either IDLE can't start
subprocess or personal firewall is blocking." 

...fatal error message I got when I installed the last release candidate
version on Sept 22, 2008. I put in a bug report at that time 

"[issue3943] IDLE won't start in 3.0rc1 "Subprocess didn't make
connection"" 

but it was closed since the fix to LIB/idlelib/run.py (on line 76) in
#3905 message 73496 by Georg Brandl fixes this problem.

I believe that this known fix was overlooked when 2.6 final was released
this week.

...Bob

----------
components: IDLE
messages: 74321
nosy: rbtyod
severity: normal
status: open
title: IDLE won't start in 2.6 final. A known fix was overlooked?
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Sun Oct  5 00:30:09 2008
From: report at bugs.python.org (Craig Holmquist)
Date: Sat, 04 Oct 2008 22:30:09 +0000
Subject: [New-bugs-announce] [issue4043] Attempting to import deprecated
	modules in IDLE raises TypeError
In-Reply-To: <1223159409.57.0.545310219567.issue4043@psf.upfronthosting.co.za>
Message-ID: <1223159409.57.0.545310219567.issue4043@psf.upfronthosting.co.za>


New submission from Craig Holmquist <craigholm at gmail.com>:

In Python 2.6, attempting to import depecated modules in IDLE raises a
TypeError exception.  I verified this with sets, mimify, and MimeWriter.
 Here's the output for sets:

>>> import sets

Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    import sets
  File "C:\Python26\Lib\sets.py", line 85, in <module>
    stacklevel=2)
  File "C:\Python26\Lib\warnings.py", line 29, in _show_warning
    file.write(formatwarning(message, category, filename, lineno, line))
TypeError: idle_formatwarning_subproc() takes exactly 4 arguments (5 given)

The other modules give a similar trace.

Normally, I wouldn't consider this a serious issue, but there are some
major packages out there that still use deprecated modules such as
these.  For example, MySQLdb 1.2.2 and SQLAlchemy 4.7p1 import the sets
module so they can't be used at all in IDLE.

----------
components: IDLE
messages: 74324
nosy: craigh
severity: normal
status: open
title: Attempting to import deprecated modules in IDLE raises TypeError
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Oct  5 14:19:42 2008
From: report at bugs.python.org (Martina Oefelein)
Date: Sun, 05 Oct 2008 12:19:42 +0000
Subject: [New-bugs-announce] [issue4044] test_output_textcalendar fails on
	non-englisch locale
In-Reply-To: <1223209182.04.0.559787210329.issue4044@psf.upfronthosting.co.za>
Message-ID: <1223209182.04.0.559787210329.issue4044@psf.upfronthosting.co.za>


New submission from Martina Oefelein <Martina at oefelein.de>:

test_output_textcalendar (in test_calendar.py) fails if the environment 
variable LANG is set to a non-english locale.

Python 3.0rc1 on MacOSX 10.5.5

$ LANG=de_DE.UTF-8 ./python.exe -E -bb ./Lib/test/regrtest.py -l 
test_calendar
test_calendar
test test_calendar failed -- errors occurred; run in verbose mode for 
details
1 test failed:
    test_calendar
$ LANG=en_US.UTF-8 ./python.exe -E -bb ./Lib/test/regrtest.py -l 
test_calendar
test_calendar
1 test OK.

----------
components: Tests
messages: 74339
nosy: oefe
severity: normal
status: open
title: test_output_textcalendar fails on non-englisch locale
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Sun Oct  5 14:33:38 2008
From: report at bugs.python.org (Martina Oefelein)
Date: Sun, 05 Oct 2008 12:33:38 +0000
Subject: [New-bugs-announce] [issue4045] test_mboxmmdf_to_maildir fails on
	non-englisch locale
In-Reply-To: <1223210018.98.0.954404111319.issue4045@psf.upfronthosting.co.za>
Message-ID: <1223210018.98.0.954404111319.issue4045@psf.upfronthosting.co.za>


New submission from Martina Oefelein <Martina at oefelein.de>:

test_mboxmmdf_to_maildir (in test_mailbox.py) fails if the environment 
variable LANG is set to a non-english locale.

Python 3.0rc1 on MacOSX 10.5.5

Majestix:Python-3.0rc1 martina$ LANG=en_US.UTF-8 ./python.exe -E -bb 
./Lib/test/regrtest.py -l test_mailbox
test_mailbox
1 test OK.
Majestix:Python-3.0rc1 martina$ LANG=de_DE.UTF-8 ./python.exe -E -bb 
./Lib/test/regrtest.py -l test_mailbox
test_mailbox
test test_mailbox failed -- Traceback (most recent call last):
  File "/Users/martina/Downloads/Python-
3.0rc1/Lib/test/test_mailbox.py", line 1389, in test_mboxmmdf_to_maildir
    self.assert_(msg.get_date() == 0.0, msg.get_date())
AssertionError: 1223209655.11

----------
components: Tests
messages: 74340
nosy: oefe
severity: normal
status: open
title: test_mboxmmdf_to_maildir fails on non-englisch locale
versions: Python 3.0

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

From report at bugs.python.org  Sun Oct  5 14:47:17 2008
From: report at bugs.python.org (Martina Oefelein)
Date: Sun, 05 Oct 2008 12:47:17 +0000
Subject: [New-bugs-announce] [issue4046] test_formatdate_usegmt fails on
	non-englisch locale
In-Reply-To: <1223210837.43.0.59197631848.issue4046@psf.upfronthosting.co.za>
Message-ID: <1223210837.43.0.59197631848.issue4046@psf.upfronthosting.co.za>


New submission from Martina Oefelein <Martina at oefelein.de>:

test_formatdate_usegmt (in test_email.py) fails if the environment 
variable LANG is set to a non-english locale.

Python 3.0rc1 on MacOSX 10.5.5

$ LANG=en_US.UTF-8 ./python.exe -E -bb ./Lib/test/regrtest.py -l 
test_email
test_email
1 test OK.

$ LANG=de_DE.UTF-8 ./python.exe -E -bb ./Lib/test/regrtest.py -l 
test_email
test_email
test test_email failed -- Traceback (most recent call last):
  File "/Users/martina/Downloads/Python-
3.0rc1/Lib/email/test/test_email.py", line 2139, in 
test_formatdate_usegmt
    time.strftime('%a, %d %b %Y %H:%M:%S -0000', time.gmtime(now)))
AssertionError: 'Sun, 05 Oct 2008 12:44:04 -0000' != 'So, 05 Okt 2008 
12:44:04 -0000'

1 test failed:
    test_email

----------
components: Tests
messages: 74343
nosy: oefe
severity: normal
status: open
title: test_formatdate_usegmt fails on non-englisch locale
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Sun Oct  5 15:15:46 2008
From: report at bugs.python.org (Martina Oefelein)
Date: Sun, 05 Oct 2008 13:15:46 +0000
Subject: [New-bugs-announce] [issue4047] test_run_abort triggers
	CrashReporter on MacOS X
In-Reply-To: <1223212546.3.0.400600313868.issue4047@psf.upfronthosting.co.za>
Message-ID: <1223212546.3.0.400600313868.issue4047@psf.upfronthosting.co.za>


New submission from Martina Oefelein <Martina at oefelein.de>:

test_run_abort (in test_subprocess.py) causes the MaxOS X crash reporter 
dialog to pop up (at least when running from an interactive session). This 
might be unavoidable (the crash is part of the test); however, to avoid 
confusion, it should maybe pointed out in the README that this is expected 
behavior -- or skip the test by default?

Python 3.0rc1 on MacOSX 10.5.5

----------
components: Tests
messages: 74344
nosy: oefe
severity: normal
status: open
title: test_run_abort triggers CrashReporter on MacOS X
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Mon Oct  6 00:15:20 2008
From: report at bugs.python.org (David Binger)
Date: Sun, 05 Oct 2008 22:15:20 +0000
Subject: [New-bugs-announce] [issue4048] parsermodule won't validate
	relative imports
In-Reply-To: <1223244920.43.0.0525505327115.issue4048@psf.upfronthosting.co.za>
Message-ID: <1223244920.43.0.0525505327115.issue4048@psf.upfronthosting.co.za>


New submission from David Binger <davidbinger at mac.com>:

The parser module validates st instances that it builds from 
list or tuple structures.  This validation fails for parse
trees that include relative imports because it fails to correctly
count the dots that immediately follow the "from" token.

Here is a test and a patch.

This bug probably extends back to all Python 2 versions that support
relative import, but I have not checked it.

Fixing this has immediate value to me because the QPY package 
depends on the parser module to convert list structures into st 
instances.  (In the long run, I wonder if the verification
part of the sequence2st() function could be made optional or dropped,
since the current pattern requires to parser module to be updated
every time the language grammer changes.)

----------
components: Library (Lib)
files: parserdot.diff
keywords: patch
messages: 74354
nosy: dbinger
severity: normal
status: open
title: parsermodule won't validate relative imports
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11705/parserdot.diff

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

From report at bugs.python.org  Mon Oct  6 02:31:21 2008
From: report at bugs.python.org (Chris)
Date: Mon, 06 Oct 2008 00:31:21 +0000
Subject: [New-bugs-announce] [issue4049] IDLE does not open at all
In-Reply-To: <1223253081.14.0.0863464602504.issue4049@psf.upfronthosting.co.za>
Message-ID: <1223253081.14.0.0863464602504.issue4049@psf.upfronthosting.co.za>


New submission from Chris <chrisl0426 at yahoo.com>:

IDLE just won't open in 2.6 for me. The command line works but not the
GUI. It works in 2.5.2 though. I am a neophyte, any help is much
appreciated.

----------
messages: 74357
nosy: Chris_L
severity: normal
status: open
title: IDLE does not open at all
versions: Python 2.6

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

From report at bugs.python.org  Mon Oct  6 05:20:46 2008
From: report at bugs.python.org (Brodie Rao)
Date: Mon, 06 Oct 2008 03:20:46 +0000
Subject: [New-bugs-announce] [issue4050] inspect.findsource() returns binary
	data for shared library modules
In-Reply-To: <1223263246.04.0.311292342093.issue4050@psf.upfronthosting.co.za>
Message-ID: <1223263246.04.0.311292342093.issue4050@psf.upfronthosting.co.za>


New submission from Brodie Rao <junk at dackz.net>:

Calling inspect.findsource() on a module whose __file__ attribute points 
to a shared library causes findsource() to return the binary's data:

>>> import time
>>> time.__file__
'/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/
lib-dynload/time.so'
>>> import inspect
>>> inspect.findsource(time)
(['\xca\xfe\xba\xbe\x00\x00\x00\x04\x00\x00\x00\x12\x00\x00\x00\n', 
'\x00\x00\x10\x00\x00\x00Jt\x00...

It should raise an error saying it can't retrieve the source. It doesn't 
do this because when it tries to find the source file it calls both 
getsourcefile() - and getfile() when that fails. It should call only 
getsourcefile() - which checks to see if __file__ points to a binary - 
and if the result is None, raise an error.

I'm attaching a patch against trunk that fixes this. The issue affects 
3.0, 2.6, 2.5, and probably previous versions.

----------
components: Library (Lib)
files: inspect-findsource-binary.diff
keywords: patch
messages: 74358
nosy: brodierao
severity: normal
status: open
title: inspect.findsource() returns binary data for shared library modules
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11706/inspect-findsource-binary.diff

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

From report at bugs.python.org  Mon Oct  6 12:28:46 2008
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Mon, 06 Oct 2008 10:28:46 +0000
Subject: [New-bugs-announce] [issue4051] use of TCHAR under win32
In-Reply-To: <1223288926.88.0.428745871562.issue4051@psf.upfronthosting.co.za>
Message-ID: <1223288926.88.0.428745871562.issue4051@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt <eckhardt at satorlaser.com>:

In several places, Python is using TCHAR-based win32 APIs which has 
several consequences:
1. The actually used function depends on the _UNICODE macro, while the 
using code often assumes that this macro is not defined. That means 
that not only the code changes when the macro is defined but that it 
simply breaks.
2. Using the ANSI-variants of functions causes overhead when a Unicode 
string has to be transcoded and possibly data loss, because the ANSI 
encoding can't represent the full Unicode range. Note that I'm 
assuming an NT based system (i.e. NT, win2k etc), because the systems 
where the ANSI encoding is native (win9x, ME(?) etc) have been dropped 
from the supported platforms.
3. The main reason for me wanting a build independent of TCHAR is a 
port to MS Windows CE, which doesn't support the ANSI encoding at all. 
This means that a TCHAR-clean build for desktop win32 is a necessary 
part of the port to CE, but even without the port it would be useful 
to skip the conversion overhead and at the same time gain 
functionality. Concerning the CE port, see this thread as a reference:
http://mail.python.org/pipermail/python-dev/2008-September/082529.html

Note: I'm adding this tracker item mainly in order to attach patches 
for review, so they don't get lost like it's possible on the 
mailinglist.

----------
components: Windows
messages: 74363
nosy: eckhardt
severity: normal
status: open
title: use of TCHAR under win32
versions: Python 2.7

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

From report at bugs.python.org  Mon Oct  6 13:30:40 2008
From: report at bugs.python.org (Gerard)
Date: Mon, 06 Oct 2008 11:30:40 +0000
Subject: [New-bugs-announce] [issue4052] Build on 2.6 on AIX 5.3 fails
	(syntax error / undeclared identifier subtract)
In-Reply-To: <1223292640.72.0.293945731017.issue4052@psf.upfronthosting.co.za>
Message-ID: <1223292640.72.0.293945731017.issue4052@psf.upfronthosting.co.za>


New submission from Gerard <gerardpiek at gmail.com>:

I'm using an IBM compiler running in AIX 5.3.
Compilation of Python 2.6 fails (see explanation below).
Compilation of Python 2.5.2 is ok.

/home/xyz/python/Python-2.6$ lslpp -L | grep vac
  vac.C                     10.1.0.0    C     F    IBM XL C Compiler
  vac.aix53.lib             10.1.0.0    C     F    XL C for AIX
Libraries for AIX
  vac.include               10.1.0.0    C     F    IBM XL C Compiler Include
  vac.lib                   10.1.0.0    C     F    XL C for AIX Libraries
  vac.lic                   10.1.0.0    C     F    XL C for AIX Licence
Files
  vacpp.cmp.rte             10.1.0.0    C     F    IBM XL C/C++ Compiler
  vacpp.cmp.tools           10.1.0.0    C     F    IBM XL C/C++ Tools
  vacpp.licAgreement        10.1.0.0    C     F    IBM XL C++ Electronic
License
  vacpp.memdbg.aix53.rte    10.1.0.0    C     F    IBM XL C/C++ User
Heap/Memory
  vacpp.memdbg.rte          10.1.0.0    C     F    IBM XL C/C++ User
Heap and

Configure --prefix <some path> 
runs ok.
Then, make fails:

/home/xyz/python/Python-2.6$ make
        cc_r -qlanglvl=extc89 -c  -DNDEBUG -O  -I. -IInclude -I./Include
-I/usr/local/include/  -DPy_BUILD_CORE -o Objects/frameobject.o
Objects/frameobject.c
"Objects/frameobject.c", line 520.9: 1506-046 (S) Syntax error.
"Objects/frameobject.c", line 520.12: 1506-045 (S) Undeclared identifier
subtract.
make: The error code from the last command is 1.

----------
components: Build
messages: 74365
nosy: gerard
severity: normal
status: open
title: Build on 2.6 on AIX 5.3 fails (syntax error / undeclared identifier subtract)
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Mon Oct  6 15:01:58 2008
From: report at bugs.python.org (Govind)
Date: Mon, 06 Oct 2008 13:01:58 +0000
Subject: [New-bugs-announce] [issue4053] str.split unintentionally strips
	char 'I' from the string
In-Reply-To: <1223298118.61.0.171396290216.issue4053@psf.upfronthosting.co.za>
Message-ID: <1223298118.61.0.171396290216.issue4053@psf.upfronthosting.co.za>


New submission from Govind <avgovind at hotmail.com>:

I tried to process a text file (with UTF-8 encoding) which has 
contents like this:


FILE=India
asbds
FILE=Indonasia
ssgsds
FILE=Africa
DBGDGDFG

When I use the below code:
>>> f = open("e:\\temp\\file.txt", 'r')
>>> lines = f.readlines()
>>> for line in lines:
	if line.startswith("FILE="):
		print line.strip("FILE=")


I get output as:
ndia

ndonasia

Africa


I is always stripped if it follows the substring that I want to strip 
off.

Am I doing something wrong here or is this a bug in Python?

-Govind

----------
components: Library (Lib)
messages: 74367
nosy: Govind
severity: normal
status: open
title: str.split unintentionally strips char 'I' from the string
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Mon Oct  6 15:04:30 2008
From: report at bugs.python.org (Govind)
Date: Mon, 06 Oct 2008 13:04:30 +0000
Subject: [New-bugs-announce] [issue4054] str.split unintentionally strips
	char 'I' from the string
In-Reply-To: <1223298270.23.0.44559787847.issue4054@psf.upfronthosting.co.za>
Message-ID: <1223298270.23.0.44559787847.issue4054@psf.upfronthosting.co.za>


New submission from Govind <avgovind at hotmail.com>:

I tried to process a text file (with UTF-8 encoding) which has 
contents like this:


FILE=India
asbds
FILE=Indonasia
ssgsds
FILE=Africa
DBGDGDFG

When I use the below code:
>>> f = open("e:\\temp\\file.txt", 'r')
>>> lines = f.readlines()
>>> for line in lines:
	if line.startswith("FILE="):
		print line.strip("FILE=")


I get output as:
ndia

ndonasia

Africa


I is always stripped if it follows the substring that I want to strip 
off.

Am I doing something wrong here or is this a bug in Python?

-Govind

----------
files: file.txt
messages: 74368
nosy: Govind
severity: normal
status: open
title: str.split unintentionally strips char 'I' from the string
type: behavior
Added file: http://bugs.python.org/file11710/file.txt

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

From report at bugs.python.org  Mon Oct  6 18:36:35 2008
From: report at bugs.python.org (Ignacio Vazquez-Abrams)
Date: Mon, 06 Oct 2008 16:36:35 +0000
Subject: [New-bugs-announce] [issue4055] Documentation on website is missing
	section numbers
In-Reply-To: <1223310995.33.0.795249867798.issue4055@psf.upfronthosting.co.za>
Message-ID: <1223310995.33.0.795249867798.issue4055@psf.upfronthosting.co.za>


New submission from Ignacio Vazquez-Abrams <ivazqueznet+python at gmail.com>:

The documentation on the website seems to have lost the numbers
identifying the various sections. It was useful to point a user to e.g.
?3.6.2 of the libref in order to guide them to the string interpolation
documentation. This is now no longer possible, and instead the user must
hunt around for the appropriate section. This is a severe usability hit
against the documentation.

----------
assignee: georg.brandl
components: Documentation
messages: 74381
nosy: georg.brandl, ivazquez
severity: normal
status: open
title: Documentation on website is missing section numbers
type: performance
versions: Python 2.6

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

From report at bugs.python.org  Mon Oct  6 21:10:40 2008
From: report at bugs.python.org (Ian Bicking)
Date: Mon, 06 Oct 2008 19:10:40 +0000
Subject: [New-bugs-announce] [issue4056] :Class: causes exception
In-Reply-To: <1223320240.78.0.644228584964.issue4056@psf.upfronthosting.co.za>
Message-ID: <1223320240.78.0.644228584964.issue4056@psf.upfronthosting.co.za>


New submission from Ian Bicking <ianb at colorstudy.com>:

I used a reference like :Class:`something` (note the capitalization) and
got this exception:

Traceback (most recent call last):
  File
"/home/ianb/src/env/lib/python2.4/site-packages/sphinx/__init__.py",
line 135, in main
    app.builder.build_update()
  File
"/home/ianb/src/env/lib/python2.4/site-packages/sphinx/builder.py", line
201, in build_update
    summary='targets for %d source files that are '
  File
"/home/ianb/src/env/lib/python2.4/site-packages/sphinx/builder.py", line
241, in build
    self.write(docnames, updated_docnames, method)
  File
"/home/ianb/src/env/lib/python2.4/site-packages/sphinx/builder.py", line
276, in write
    doctree = self.env.get_and_resolve_doctree(docname, self)
  File
"/home/ianb/src/env/lib/python2.4/site-packages/sphinx/environment.py",
line 779, in get_and_resolve_doctree
    self.resolve_references(doctree, docname, builder)
  File
"/home/ianb/src/env/lib/python2.4/site-packages/sphinx/environment.py",
line 998, in resolve_references
    raise RuntimeError('unknown xfileref node encountered: %s' % node)
RuntimeError: unknown xfileref node encountered: <pending_xref classname
modname refcaption="False" reftarget="deliverance.rules.Drop"
reftype="Class"><literal
classes="xref">deliverance.rules.Drop</literal></pending_xref>

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 74385
nosy: georg.brandl, ianb
severity: normal
status: open
title: :Class: causes exception

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

From report at bugs.python.org  Mon Oct  6 21:28:03 2008
From: report at bugs.python.org (Miki Tebeka)
Date: Mon, 06 Oct 2008 19:28:03 +0000
Subject: [New-bugs-announce] [issue4057] Popen(...,
	cwd=...) does not set PWD environment variable
In-Reply-To: <1223321283.05.0.79921922605.issue4057@psf.upfronthosting.co.za>
Message-ID: <1223321283.05.0.79921922605.issue4057@psf.upfronthosting.co.za>


New submission from Miki Tebeka <miki.tebeka at gmail.com>:

[21:26] pwd-bug $cat m
#!/usr/bin/env python

from subprocess import Popen
Popen(["./t"], cwd="./p")
[21:26] pwd-bug $cat p/t 
#!/usr/bin/env python

from os import environ
print environ["PWD"]
[21:26] pwd-bug $python m 
/Users/mtebeka/playground/pwd-bug

The output should be /Users/mtebeka/playground/pwd-bug/p

----------
messages: 74388
nosy: tebeka
severity: normal
status: open
title: Popen(..., cwd=...) does not set PWD environment variable
versions: Python 2.6

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

From report at bugs.python.org  Mon Oct  6 21:40:09 2008
From: report at bugs.python.org (Robert Lehmann)
Date: Mon, 06 Oct 2008 19:40:09 +0000
Subject: [New-bugs-announce] [issue4058] markup in What's New in 2.6
In-Reply-To: <1223322009.26.0.795305514424.issue4058@psf.upfronthosting.co.za>
Message-ID: <1223322009.26.0.795305514424.issue4058@psf.upfronthosting.co.za>


New submission from Robert Lehmann <lehmannro at gmail.com>:

The markup in the Doc/whatsnew/2.6.rst document is somewhat messy in
some places. I fixed indentation (spaces to tabs -- made some things
readable in the docutils output but not in the source), code samples
("->" notation to Python prompt) and some minor things (which are too
small for issues on their own).

----------
assignee: georg.brandl
components: Documentation
files: whatsnew.2.6.patch
keywords: patch
messages: 74389
nosy: georg.brandl, lehmannro
severity: normal
status: open
title: markup in What's New in 2.6
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file11713/whatsnew.2.6.patch

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

From report at bugs.python.org  Mon Oct  6 23:42:05 2008
From: report at bugs.python.org (Robert Lehmann)
Date: Mon, 06 Oct 2008 21:42:05 +0000
Subject: [New-bugs-announce] [issue4059] sqlite3 docs incomplete
In-Reply-To: <1223329325.4.0.307083135526.issue4059@psf.upfronthosting.co.za>
Message-ID: <1223329325.4.0.307083135526.issue4059@psf.upfronthosting.co.za>


New submission from Robert Lehmann <lehmannro at gmail.com>:

The sqlite3 documentation misses Row and Cursor.description.
Additionally it does not use the best markup in all places (missing
links, basically, and forgotten .. class:: statements).

A patch is attached.

----------
assignee: georg.brandl
components: Documentation
files: sqlite3.patch
keywords: patch
messages: 74392
nosy: georg.brandl, lehmannro
severity: normal
status: open
title: sqlite3 docs incomplete
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file11714/sqlite3.patch

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

From report at bugs.python.org  Tue Oct  7 00:27:10 2008
From: report at bugs.python.org (Trent Mick)
Date: Mon, 06 Oct 2008 22:27:10 +0000
Subject: [New-bugs-announce] [issue4060] PyUnicode_DecodeUTF16(...,
	byteorder=0) gets it wrong on Mac OS X/PowerPC
In-Reply-To: <1223332030.39.0.313145041612.issue4060@psf.upfronthosting.co.za>
Message-ID: <1223332030.39.0.313145041612.issue4060@psf.upfronthosting.co.za>


New submission from Trent Mick <trentm at gmail.com>:

Revision 63955 removed a block from configure.in (and effectively from
pyconfig.h.in) having to do with endianness that results in an incorrect
setting for "WORDS_BIGENDIAN" in Universal builds on Mac OS X.

The removed part was this:

> AH_VERBATIM([WORDS_BIGENDIAN], 	 
> [ 	 
>  /* Define to 1 if your processor stores words with the most
significant byte 	 
>     first (like Motorola and SPARC, unlike Intel and VAX). 	 
>  	 
>     The block below does compile-time checking for endianness on
platforms 	 
>     that use GCC and therefore allows compiling fat binaries on OSX by
using 	 
>     '-arch ppc -arch i386' as the compile flags. The phrasing was
choosen 	 
>     such that the configure-result is used on systems that don't use
GCC. 	 
>   */ 	 
> #ifdef __BIG_ENDIAN__ 	 
> #define WORDS_BIGENDIAN 1 	 
> #else 	 
> #ifndef __LITTLE_ENDIAN__ 	 
> #undef WORDS_BIGENDIAN 	 
> #endif 	 
> #endif])

This used to allow "WORDS_BIGENDIAN" to be correct for all parts of a
universal Python build done via `gcc -arch i386 -arch ppc ...`.

This was originally added for issue 1471883 (see msg50040 for a
discussion of this particular bit).


The result of this bug is that Python extensions using either of the
following to get native byte ordering for UTF-16 decoding:

   PyUnicode_DecodeUTF16(..., byteorder=0);
   PyUnicode_DecodeUTF16Stateful(..., byteorder=0, ...);

on Mac OS X/PowerPC with a universal build built on Intel hardware (most
such builds) will get the wrong byte-ordering.


The fix is to restore that section to configure.in and re-run autoconf
and autoheader.


Ronald,

Was there are particular reason that this block was removed from
configure.in (and pyconfig.h.in)?

I'd like to hear comments from either Ronald or Martin, and then I can
commit the fix.

----------
components: Unicode
messages: 74398
nosy: loewis, ronaldoussoren, trentm
severity: normal
status: open
title: PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS X/PowerPC
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Oct  7 01:02:12 2008
From: report at bugs.python.org (Mehmet Yozcu)
Date: Mon, 06 Oct 2008 23:02:12 +0000
Subject: [New-bugs-announce] [issue4061] summing two numbers-strange answer
In-Reply-To: <1223334132.73.0.738465062828.issue4061@psf.upfronthosting.co.za>
Message-ID: <1223334132.73.0.738465062828.issue4061@psf.upfronthosting.co.za>


New submission from Mehmet Yozcu <mhmtyozcu001 at gmail.com>:

I don't know what's wrong but when I write on the IDLE 
2.3+6.3
it gives an answer like 8.59999999996 or similar
when I write on the IDLE
print 2.3+6.3
the answer is 8.6 as I expected
I tried these two commands on the DrPython IDE;the result was the same.

Below, I copy-past everything on the consol screen with detail of my
system configuration. And I ask if someone can help me with this?
Thank you in advance.


mehmet at mehmet-desktop:~$ python
Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 2.3+6.3
8.5999999999999996
>>> print 2.3+6.3
8.6
>>>

----------
messages: 74408
nosy: mhmtyozcu001
severity: normal
status: open
title: summing two numbers-strange answer

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

From report at bugs.python.org  Tue Oct  7 01:28:01 2008
From: report at bugs.python.org (Orestis Markou)
Date: Mon, 06 Oct 2008 23:28:01 +0000
Subject: [New-bugs-announce] [issue4062] Reference to non-existent
	__version__ in ast module
In-Reply-To: <1223335681.88.0.292034788645.issue4062@psf.upfronthosting.co.za>
Message-ID: <1223335681.88.0.292034788645.issue4062@psf.upfronthosting.co.za>


New submission from Orestis Markou <orestis at orestis.gr>:

The docs for the ast module refer to a __version__ number, that should track the 
Subversion id. 

However, this doesn't exist:

>>>import ast
>>>ast.__version__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute '__version__'

Looking at ast.py, nothing of that sort is there in the first place.

----------
assignee: georg.brandl
components: Documentation
messages: 74413
nosy: georg.brandl, orestis
severity: normal
status: open
title: Reference to non-existent __version__ in ast module
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Oct  7 11:17:05 2008
From: report at bugs.python.org (Thomas Guettler)
Date: Tue, 07 Oct 2008 09:17:05 +0000
Subject: [New-bugs-announce] [issue4063] sphinx: make all-pdf does not exist.
In-Reply-To: <1223371025.23.0.890988080219.issue4063@psf.upfronthosting.co.za>
Message-ID: <1223371025.23.0.890988080219.issue4063@psf.upfronthosting.co.za>


New submission from Thomas Guettler <guettli at thomas-guettler.de>:

Hi,

after sphinx-quickstart and running "make latex" I get:
Build finished; the LaTeX files are in build/latex.
Run `make all-pdf' or `make all-ps' in that directory to run these through 

user at host:...> LANG=C make all-pdf
make: *** No rule to make target `all-pdf'.  Stop.

Sphinx Version 0.4.2

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 74431
nosy: georg.brandl, guettli
severity: normal
status: open
title: sphinx: make all-pdf does not exist.
versions: Python 2.5

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

From report at bugs.python.org  Tue Oct  7 11:41:46 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 07 Oct 2008 09:41:46 +0000
Subject: [New-bugs-announce] [issue4064] distutils.util.get_platform() is
	wrong for universal builds on macosx
In-Reply-To: <1223372506.67.0.0695437695796.issue4064@psf.upfronthosting.co.za>
Message-ID: <1223372506.67.0.0695437695796.issue4064@psf.upfronthosting.co.za>


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

When using a universal build of python on macosx 
distutils.util.get_platform should use "fat" for the machine 
architecture, instead of the architecture of the current machine.

That's not what's currently happening:

$ python26 -c 'from distutils.util import get_platform; print 
get_platform()'
macosx-10.3-ppc
$

----------
components: Distutils
messages: 74432
nosy: ronaldoussoren
severity: normal
status: open
title: distutils.util.get_platform() is wrong for universal builds on macosx
versions: Python 2.6

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

From report at bugs.python.org  Tue Oct  7 12:52:52 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 07 Oct 2008 10:52:52 +0000
Subject: [New-bugs-announce] [issue4065] _multiprocessing doesn't build on
	macosx 10.3
In-Reply-To: <1223376772.75.0.564119782301.issue4065@psf.upfronthosting.co.za>
Message-ID: <1223376772.75.0.564119782301.issue4065@psf.upfronthosting.co.za>


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

I'm trying to build python 2.6 on a Mac OS X 10.3 system. This fails to 
build the multiprocessing extension due to a missing definition of "struct 
iovec".

It turns out that you have to include <sys/uio.h> to get that definition 
on OSX 10.3.

Adding '#include <sys/uio.h>' to multiprocessing.h enables building the 
extension on OSX 10.3, but is probably not the right solution.

----------
components: Extension Modules
messages: 74436
nosy: ronaldoussoren
priority: low
severity: normal
status: open
title: _multiprocessing doesn't build on macosx 10.3
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Tue Oct  7 16:26:15 2008
From: report at bugs.python.org (Marcin Bachry)
Date: Tue, 07 Oct 2008 14:26:15 +0000
Subject: [New-bugs-announce] [issue4066] smtplib SMTP_SSL._get_socket
	doesn't return a value
In-Reply-To: <1223389575.89.0.292427308742.issue4066@psf.upfronthosting.co.za>
Message-ID: <1223389575.89.0.292427308742.issue4066@psf.upfronthosting.co.za>


New submission from Marcin Bachry <hegel666 at gmail.com>:

SMTP.connect method expects _get_socket() method to return socket object:

  self.sock = self._get_socket(host, port, self.timeout)

but overriden _get_socket() method in SMTP_SSL class doesnt' have return
statement (it sets self.sock instead).  Hence I get
SMTPServerDisconnected exception when I try to send mail over ssl.

The same seems to apply to LMTP class.

----------
components: Library (Lib)
files: smtplib.diff
keywords: patch
messages: 74452
nosy: marcin.bachry
severity: normal
status: open
title: smtplib SMTP_SSL._get_socket doesn't return a value
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11729/smtplib.diff

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

From report at bugs.python.org  Tue Oct  7 16:37:56 2008
From: report at bugs.python.org (Marcin Bachry)
Date: Tue, 07 Oct 2008 14:37:56 +0000
Subject: [New-bugs-announce] [issue4067] ast.fix_missing_locations() breaks
	if node doesn't have "_attributes" variable
In-Reply-To: <1223390276.15.0.153059354273.issue4067@psf.upfronthosting.co.za>
Message-ID: <1223390276.15.0.153059354273.issue4067@psf.upfronthosting.co.za>


New submission from Marcin Bachry <hegel666 at gmail.com>:

ast.fix_missing_locations() fails if any node is missing "_attributes"
instance variable - but it's the case of some fundamental nodes like
"alias" or "identifier".  When I run simple test:

  import ast
  with open(__file__) as fp:
      tree = ast.parse(fp.read())
  ast.fix_missing_locations(tree)

I get:

  $ python2.6 /tmp/test.py 
  Traceback (most recent call last):
    File "/tmp/test.py", line 5, in <module>
      ast.fix_missing_locations(tree)
    File "/usr/local/lib/python2.6/ast.py", line 133, in
fix_missing_locations
      _fix(node, 1, 0)
    File "/usr/local/lib/python2.6/ast.py", line 132, in _fix
      _fix(child, lineno, col_offset)
    File "/usr/local/lib/python2.6/ast.py", line 132, in _fix
      _fix(child, lineno, col_offset)
    File "/usr/local/lib/python2.6/ast.py", line 121, in _fix
      if 'lineno' in node._attributes:
  AttributeError: 'alias' object has no attribute '_attributes'

----------
components: Library (Lib)
files: ast.diff
keywords: patch
messages: 74453
nosy: marcin.bachry
severity: normal
status: open
title: ast.fix_missing_locations() breaks if node doesn't have "_attributes" variable
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11730/ast.diff

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

From report at bugs.python.org  Tue Oct  7 16:43:05 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Tue, 07 Oct 2008 14:43:05 +0000
Subject: [New-bugs-announce] [issue4068] Backport fix for issue 3312
In-Reply-To: <1223390585.08.0.984761019312.issue4068@psf.upfronthosting.co.za>
Message-ID: <1223390585.08.0.984761019312.issue4068@psf.upfronthosting.co.za>


New submission from Gerhard H?ring <gh at ghaering.de>:

This is a backport of Georg Brandl's fix for issue #3312.

----------
assignee: ghaering
files: 253_backport_fix_issue3312.diff
keywords: patch, patch
messages: 74454
nosy: ghaering
priority: normal
severity: normal
status: open
title: Backport fix for issue 3312
type: crash
versions: Python 2.5.3
Added file: http://bugs.python.org/file11731/253_backport_fix_issue3312.diff

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

From report at bugs.python.org  Tue Oct  7 17:58:34 2008
From: report at bugs.python.org (Carl Friedrich Bolz)
Date: Tue, 07 Oct 2008 15:58:34 +0000
Subject: [New-bugs-announce] [issue4069] set.remove raises confusing KeyError
In-Reply-To: <1223395114.41.0.0284557162772.issue4069@psf.upfronthosting.co.za>
Message-ID: <1223395114.41.0.0284557162772.issue4069@psf.upfronthosting.co.za>


New submission from Carl Friedrich Bolz <cfbolz at gmx.de>:

When trying to remove a set from a set, the KeyError that is raised is
confusing:

Python 2.6 (r26:66714, Oct  7 2008, 13:23:57)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> s = set([frozenset([1, 2]), frozenset([2, 3])])
>>> s.remove(set([3, 4]))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: frozenset([])


I understand that s.remove(set(...)) turns the set into a frozenset, but
I was expecting this converted frozenset to be attached to the KeyError,
not an empty set.

----------
components: Interpreter Core
messages: 74461
nosy: cfbolz
severity: normal
status: open
title: set.remove raises confusing KeyError
type: behavior
versions: Python 2.5, Python 2.6

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

From martin at v.loewis.de  Tue Oct  7 21:29:17 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 07 Oct 2008 21:29:17 +0200
Subject: [New-bugs-announce] [issue4064] distutils.util.get_platform()
 is	wrong for universal builds on macosx
In-Reply-To: <1223372506.67.0.0695437695796.issue4064@psf.upfronthosting.co.za>
References: <1223372506.67.0.0695437695796.issue4064@psf.upfronthosting.co.za>
Message-ID: <48EBB88D.4040803@v.loewis.de>

> When using a universal build of python on macosx 
> distutils.util.get_platform should use "fat" for the machine 
> architecture, instead of the architecture of the current machine.

Can you please explain why it should do so? Where do these architecture
names come from?

From report at bugs.python.org  Wed Oct  8 00:33:06 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 07 Oct 2008 22:33:06 +0000
Subject: [New-bugs-announce] [issue4070] python tests failure if builddir <>
	sourcedir
In-Reply-To: <1223418786.48.0.948441318912.issue4070@psf.upfronthosting.co.za>
Message-ID: <1223418786.48.0.948441318912.issue4070@psf.upfronthosting.co.za>


New submission from Roumen Petrov <bugtrack at roumenpetrov.info>:

The proposed patch add possibility to run python tests if python is
build outside source tree on POSIX systems.

----------
components: Tests
files: python-trunk-DIST.patch
keywords: patch
messages: 74492
nosy: rpetrov
severity: normal
status: open
title: python tests failure if builddir <> sourcedir
versions: Python 2.7
Added file: http://bugs.python.org/file11735/python-trunk-DIST.patch

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

From report at bugs.python.org  Wed Oct  8 02:27:15 2008
From: report at bugs.python.org (Jason Day)
Date: Wed, 08 Oct 2008 00:27:15 +0000
Subject: [New-bugs-announce] [issue4071] ntpath.abspath can fail on Win
	Server 2008 (64-bit)
In-Reply-To: <1223425635.48.0.940202056696.issue4071@psf.upfronthosting.co.za>
Message-ID: <1223425635.48.0.940202056696.issue4071@psf.upfronthosting.co.za>


New submission from Jason Day <jason.day at bluetechllc.com>:

On my system (Windows Server 2008 SP1 - 64-bit, Python 2.5.2 - 32-bit),
simple actions like:
>>> help(help) # Or any function
or
>>> import tempfile
>>> f = tempfile.mktemp()
result in this (rather confusing) error:
TypeError: _getfullpathname() argument 1 must be (buffer overflow), not str

Apparently, _getfullpathname() chokes on certain paths if they are not
supplied as unicode. Locally, I was able to work around the issue by
changing the call to _getfullpathname in ntpath.abspath to:
                path = str(_getfullpathname(unicode(path)))

----------
components: Windows
messages: 74502
nosy: JDay
severity: normal
status: open
title: ntpath.abspath can fail on Win Server 2008 (64-bit)
type: crash
versions: Python 2.5

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

From report at bugs.python.org  Wed Oct  8 02:49:57 2008
From: report at bugs.python.org (Mark Hammond)
Date: Wed, 08 Oct 2008 00:49:57 +0000
Subject: [New-bugs-announce] [issue4072] build_py support for lib2to3 is
	stale
In-Reply-To: <1223426997.83.0.795530448507.issue4072@psf.upfronthosting.co.za>
Message-ID: <1223426997.83.0.795530448507.issue4072@psf.upfronthosting.co.za>


New submission from Mark Hammond <mhammond at users.sourceforge.net>:

The way build_py uses lib2to3 is out of date.  Instead of a dummy
Options object a dict should be used, and it seems the 'fixers' must
explicitly be loaded.  I'm afraid I don't have a specific patch as I
don't have a good test case, but the lib2to3 code needs to look
something like:

from lib2to3.refactor import RefactoringTool, get_fixers_from_package
fixers = get_fixers_from_package('lib2to3.fixes')
options = dict(doctests_only=False, fix=[], list_fixes=[], 
               print_function=False, verbose=False,
               write=True)
r = RefactoringTool(fixers, options)
r.refactor(self.updated_files)

----------
components: Distutils
messages: 74506
nosy: loewis, mhammond
severity: normal
status: open
title: build_py support for lib2to3 is stale
versions: Python 3.0

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

From report at bugs.python.org  Wed Oct  8 02:55:47 2008
From: report at bugs.python.org (Mark Hammond)
Date: Wed, 08 Oct 2008 00:55:47 +0000
Subject: [New-bugs-announce] [issue4073] distutils build_scripts and
	install_data commands need 2to3 support
In-Reply-To: <1223427347.42.0.185462217727.issue4073@psf.upfronthosting.co.za>
Message-ID: <1223427347.42.0.185462217727.issue4073@psf.upfronthosting.co.za>


New submission from Mark Hammond <mhammond at users.sourceforge.net>:

The distutils commands 'build_scripts' and 'install_data' both may end
up installing .py files.  Such .py file should be able tobe run through
lib2to3 in the same way supported by build_py.

pywin32 has ended up with something like:

    class my_build_scripts(build_scripts):
        def copy_file(self, src, dest):
            dest, copied = build_scripts.copy_file(self, src, dest)
            # 2to3
            if not self.dry_run and copied:
                refactor_filenames([dest])
            return dest, copied

where 'refactor_filenames' is (basically) the lib2to3 block from
build_py moved to a utility function.

----------
components: Distutils
messages: 74507
nosy: loewis, mhammond
severity: normal
status: open
title: distutils build_scripts and install_data commands need 2to3 support
type: feature request
versions: Python 3.0

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

From report at bugs.python.org  Wed Oct  8 06:00:52 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 08 Oct 2008 04:00:52 +0000
Subject: [New-bugs-announce] [issue4074] Building a list of tuples has
	non-linear performance
In-Reply-To: <1223438452.4.0.926419942993.issue4074@psf.upfronthosting.co.za>
Message-ID: <1223438452.4.0.926419942993.issue4074@psf.upfronthosting.co.za>


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

The attached script simply loops building a list of tuples.  It has
horrible performance as the list gets larger compared to something
appending simple objects like ints to the list.

% python tuple_gc_hell.py                  ~
...
1000000 1.3615500927
2000000 2.95893096924
3000000 4.53531980515
4000000 5.62795209885
5000000 7.70974612236
...

The time it takes to execute grows linearly with the number of tuples
already appended to the list.

Turning on gc.debug(gc.DEBUG_STATS) shows why as does running python
under a profiler:

  %   cumulative   self              self     total          
 time   seconds   seconds    calls   s/call   s/call  name   
 27.85    115.84   115.84    14270     0.01     0.02  collect
 21.19    204.01    88.17 1115120314   0.00     0.00  tupletraverse
 13.14    258.65    54.64 1655624731   0.00     0.00  visit_reachable
 10.72    303.25    44.60 1655624731   0.00     0.00  visit_decref
  5.97    328.10    24.85      338     0.07     1.10  PyEval_EvalFrame


It appears the cyclic gc is rechecking all of these tuples repeatedly. 
disabling gc during the loop or using a very high gc.set_threshold hides
the problem.

----------
components: Interpreter Core
files: tuple_gc_hell.py
messages: 74512
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: Building a list of tuples has non-linear performance
type: performance
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file11743/tuple_gc_hell.py

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

From report at bugs.python.org  Wed Oct  8 15:13:27 2008
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Wed, 08 Oct 2008 13:13:27 +0000
Subject: [New-bugs-announce] [issue4075] Use WCHAR variant of
	OutputDebugString
In-Reply-To: <1223471607.48.0.166278298943.issue4075@psf.upfronthosting.co.za>
Message-ID: <1223471607.48.0.166278298943.issue4075@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt <eckhardt at satorlaser.com>:

The attached patch converts the call to OutputDebugString() with a
'TCHAR' parameter (which boils down to a 'char') to one using a 'WCHAR'
parameter, allowing the code to be compiled under MS Windows CE, which
doesn't have the 'char' version.

----------
components: Windows
files: Python-OutputDebugStringW.0.patch
keywords: patch
messages: 74527
nosy: eckhardt
severity: normal
status: open
title: Use WCHAR variant of OutputDebugString
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file11749/Python-OutputDebugStringW.0.patch

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

From report at bugs.python.org  Wed Oct  8 16:09:35 2008
From: report at bugs.python.org (Dan OD)
Date: Wed, 08 Oct 2008 14:09:35 +0000
Subject: [New-bugs-announce] [issue4076] Cannot build non-framework tkinter
	Python on Mac OS X.5
In-Reply-To: <1223474975.98.0.266450450683.issue4076@psf.upfronthosting.co.za>
Message-ID: <1223474975.98.0.266450450683.issue4076@psf.upfronthosting.co.za>


New submission from Dan OD <djo35 at cam.ac.uk>:

On a Mac running OS X 10.5:
As per previous releases, I have set up _tkinter in Modules/Setup.dist 
with a unix X11 Tcl/Tk build variables. 
I then run ./configure && make

This builds _tkinter with (wrongly) the Mac Tcl framework (ie not X11)

building '_tkinter' extension
gcc-4.2 -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-
prototypes -DWITH_APPINIT=1 -
I/System/Library/Frameworks/Tcl.framework/Headers -
I/System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeader
s -I/System/Library/Frameworks/Tk.framework/Headers -
I/System/Library/Frameworks/Tk.framework/Versions/Current/PrivateHeaders 
-I/usr/X11R6/include -I. -I/Users/djo35/src/Python-3.0rc1/./Include -I. 
-IInclude -I./Include -I/usr/local/include -I/Users/djo35/src/Python-
3.0rc1/Include -I/Users/djo35/src/Python-3.0rc1 -c 
/Users/djo35/src/Python-3.0rc1/Modules/_tkinter.c -o build/temp.macosx-
10.3-i386-3.0/Users/djo35/src/Python-3.0rc1/Modules/_tkinter.o -
framework Tk

I would like this to build a unix tkinter.so - is this possible? I can't 
find a reference in the 3k documentation. Thanks, Dan

----------
components: Build
messages: 74528
nosy: indiedan
severity: normal
status: open
title: Cannot build non-framework tkinter Python on Mac OS X.5
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Wed Oct  8 17:50:25 2008
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Wed, 08 Oct 2008 15:50:25 +0000
Subject: [New-bugs-announce] [issue4077] Py_FatalError cleanup patch
In-Reply-To: <1223481025.87.0.784441664166.issue4077@psf.upfronthosting.co.za>
Message-ID: <1223481025.87.0.784441664166.issue4077@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt <eckhardt at satorlaser.com>:

This patch does two things:
* It removes trailing newlines from the arguments given to
Py_FatalError() because a trailing newline is already added automatically.
* It fixes the declaration in ffi.c to take a 'const char*'.

----------
components: None
files: Python-FatalError-no-newline.0.patch
keywords: patch
messages: 74531
nosy: eckhardt
severity: normal
status: open
title: Py_FatalError cleanup patch
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file11750/Python-FatalError-no-newline.0.patch

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

From report at bugs.python.org  Wed Oct  8 20:04:46 2008
From: report at bugs.python.org (Sidnei da Silva)
Date: Wed, 08 Oct 2008 18:04:46 +0000
Subject: [New-bugs-announce] [issue4078] asyncore fixes are not backwards
	compatible
In-Reply-To: <1223489086.17.0.537265261375.issue4078@psf.upfronthosting.co.za>
Message-ID: <1223489086.17.0.537265261375.issue4078@psf.upfronthosting.co.za>


New submission from Sidnei da Silva <sidnei.da.silva at gmail.com>:

I am working on getting Zope to run (or at least, start) with Python
2.6. It actually starts right now after applying some patches, which
is amazing on itself, but it dies right away due to changes in
asyncore that break Zope's internal version of medusa.

I've opened a bug against Zope on Launchpad, but someone suggested
that it might actually be a bug in python, in the sense that it
changed asyncore in a backwards-incompatible way. I wouldn't go that
far, since I think it's more likely that Zope's version of medusa is
poking into asyncore internals instead.

Here's the bug, for reference:

  https://bugs.launchpad.net/zope2/+bug/280020

I suspect a change similar to this will need to be applied to medusa:

  http://codereview.appspot.com/744/diff/1/23

I'm puzzled though as to why the change is incompatible. I would have
expected at least some kind of deprecation warning on Python 2.5.

Either way, if you think the issue needs to be fixed in medusa feel free
to close this bug.

----------
components: Library (Lib)
messages: 74540
nosy: sidnei
severity: normal
status: open
title: asyncore fixes are not backwards compatible
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Oct  8 20:29:59 2008
From: report at bugs.python.org (Sidnei da Silva)
Date: Wed, 08 Oct 2008 18:29:59 +0000
Subject: [New-bugs-announce] [issue4079] new urllib2.Request 'timeout'
	attribute needs to have a default
In-Reply-To: <1223490599.12.0.198174561396.issue4079@psf.upfronthosting.co.za>
Message-ID: <1223490599.12.0.198174561396.issue4079@psf.upfronthosting.co.za>


New submission from Sidnei da Silva <sidnei.da.silva at gmail.com>:

'urllib2' has introduced a configurable 'timeout' setting by assigning
to the 'timeout' attribute of the urllib2.Request object. However the
implementation is flawed:

- the 'timeout' attribute is set in OpenerDirector.open() and nowhere else

- if someone overrides OpenerDirector.open() (btw: mechanize does
  this), then the 'timeout' attribute will never be set, breaking
  other parts of the code which require the 'timeout' attribute to be
  present.

A simple workaround for this would be to do one or more of:

a) define the 'timeout' attribute as socket._GLOBAL_DEFAULT_TIMEOUT at
   class-level

b) initialize the 'timeout' attribute on urllib2.Request.__init__()

----------
components: Library (Lib)
messages: 74541
nosy: sidnei
severity: normal
status: open
title: new urllib2.Request 'timeout' attribute needs to have a default
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Oct  8 22:28:16 2008
From: report at bugs.python.org (Pawel Prokop)
Date: Wed, 08 Oct 2008 20:28:16 +0000
Subject: [New-bugs-announce] [issue4080] pyunit - display time of each test
	case - patch
In-Reply-To: <1223497696.14.0.913391715353.issue4080@psf.upfronthosting.co.za>
Message-ID: <1223497696.14.0.913391715353.issue4080@psf.upfronthosting.co.za>


New submission from Pawel Prokop <pablo at uek.krakow.pl>:

I've needed to measure each unit test running time
to measure the performance changing of each functionality
that every test case tests.
Latest version of pyunit has only displayed summary running time of the
suite, so I've implemented small enhancement to unittest.py that 
(in verbose mode) shows time of each test case run.
Maybe that would be usefull for anybody else?

----------
components: None
files: pyunit_time.patch
keywords: patch
messages: 74545
nosy: pprokop
severity: normal
status: open
title: pyunit - display time of each test case - patch
type: feature request
versions: 3rd party
Added file: http://bugs.python.org/file11751/pyunit_time.patch

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

From report at bugs.python.org  Thu Oct  9 00:28:39 2008
From: report at bugs.python.org (Tim Delaney)
Date: Wed, 08 Oct 2008 22:28:39 +0000
Subject: [New-bugs-announce] [issue4081] Error copying directory to _static
	in Sphinx
In-Reply-To: <1223504918.57.0.382949560871.issue4081@psf.upfronthosting.co.za>
Message-ID: <1223504918.57.0.382949560871.issue4081@psf.upfronthosting.co.za>


New submission from Tim Delaney <timothy.c.delaney at gmail.com>:

If there is a directory to be copied to _static, Sphinx first attempts 
to delete any directory by the same name in the _static directory. See 
attached sphinx_static_exc.txt for the exception.

The simplest fix is to change the call (line 595, Sphinx 0.4.2) to::

    shutil.rmtree(targetname)

to::

    shutil.rmtree(targetname, ignore_errors=True)

It would also be preferable if instead of blindly doing rmtree/copytree, 
only updated files be copied to _static.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: sphinx_static_exc.txt
messages: 74551
nosy: georg.brandl, tcdelaney
severity: normal
status: open
title: Error copying directory to _static in Sphinx
type: crash
Added file: http://bugs.python.org/file11752/sphinx_static_exc.txt

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

From report at bugs.python.org  Thu Oct  9 01:51:51 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 08 Oct 2008 23:51:51 +0000
Subject: [New-bugs-announce] [issue4082] python2.6 -m site doesn't run
	site._script() any more
In-Reply-To: <1223509911.91.0.368315833446.issue4082@psf.upfronthosting.co.za>
Message-ID: <1223509911.91.0.368315833446.issue4082@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

python2.6 -m site used to print some status information to the console.
python3.0 -m site and python2.5 -m site are still working as expected.
An initial debug session showed that the site module isn't imported a
second time under the name __main__. I suspect a regression in runpy or
related code.

----------
components: Library (Lib)
messages: 74553
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: python2.6 -m site doesn't run site._script() any more
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Thu Oct  9 09:40:33 2008
From: report at bugs.python.org (Davi Post)
Date: Thu, 09 Oct 2008 07:40:33 +0000
Subject: [New-bugs-announce] [issue4083] try statement in language reference
	not updated for v2.6
In-Reply-To: <1223538033.46.0.0709872608111.issue4083@psf.upfronthosting.co.za>
Message-ID: <1223538033.46.0.0709872608111.issue4083@psf.upfronthosting.co.za>


New submission from Davi Post <post at pobox.com>:

Language Reference for the try statement does not show changes for v2.6, 
specifically the "PEP 3110: Exception-Handling Changes". At least, the 
grammar should include the "except ... as" syntax.

http://docs.python.org/reference/compound_stmts.html#try
http://docs.python.org/whatsnew/2.6.html#pep-3110-exception-handling-
changes
http://www.python.org/dev/peps/pep-3110/#compatibility

----------
assignee: georg.brandl
components: Documentation
messages: 74556
nosy: davipo, georg.brandl
severity: normal
status: open
title: try statement in language reference not updated for v2.6
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Oct  9 10:43:17 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 09 Oct 2008 08:43:17 +0000
Subject: [New-bugs-announce] [issue4084] Decimal.max(NaN,
	x) gives incorrect results when x is finite and long
In-Reply-To: <1223541797.81.0.999567661015.issue4084@psf.upfronthosting.co.za>
Message-ID: <1223541797.81.0.999567661015.issue4084@psf.upfronthosting.co.za>


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

Here's a snippet from Python 2.6:

>>> from decimal import Decimal, getcontext
>>> getcontext().prec = 3
>>> Decimal('NaN').max(Decimal('1234'))
Decimal('sNaN234')

The result here should be Decimal('1.23E+3')---the specification says that 
the result of comparing a quiet NaN with a finite value should be that 
finite value, rounded according to the context.

This also affects min, max_mag and min_mag.

The cause is that non-NaNs are incorrectly being passed to the _fix_nan 
method.  The attached patch fixes this, and adds new testcases to 
extra.decTest to stop it happening again.

It would be good to get this fix into 3.0, if possible.  I think it should 
also be backported to 2.5.3.

----------
assignee: facundobatista
files: decimal_maxbug.patch
keywords: patch
messages: 74557
nosy: facundobatista, marketdickinson
priority: normal
severity: normal
status: open
title: Decimal.max(NaN, x) gives incorrect results when x is finite and long
type: behavior
versions: Python 2.5.3, Python 2.6, Python 2.7, Python 3.0
Added file: http://bugs.python.org/file11753/decimal_maxbug.patch

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

From report at bugs.python.org  Thu Oct  9 11:27:55 2008
From: report at bugs.python.org (David Jones)
Date: Thu, 09 Oct 2008 09:27:55 +0000
Subject: [New-bugs-announce] [issue4085] 2.5.2 whatsnew document corrupts
	names, by having broken HTML, at least on the Web.
In-Reply-To: <1223544475.01.0.800485054454.issue4085@psf.upfronthosting.co.za>
Message-ID: <1223544475.01.0.800485054454.issue4085@psf.upfronthosting.co.za>


New submission from David Jones <drj at pobox.com>:

Consider the web page:

http://www.python.org/doc/2.5.2/whatsnew/acks.html

(the problem appears throughout the whatsnew document, but that page 
happens to be short and have more than one instance).

On my browser, Safari 3.1.2 on Intel OS X 10.4.11, Martin von L?wis has 
his name corrupted, as does Lars Gust?bel.

The problem seems to be because whilst the page is encoded in utf-8 the 
web server does not transmit a Content-Type header that specifies utf-8:

$ curl -I http://www.python.org/doc/2.5.2/whatsnew/acks.html
HTTP/1.1 200 OK
Date: Thu, 09 Oct 2008 08:51:22 GMT
Server: Apache/2.2.3 (Debian) DAV/2 SVN/1.4.2 mod_ssl/2.2.3 
OpenSSL/0.9.8c mod_wsgi/2.0 Python/2.4.4
Last-Modified: Fri, 22 Feb 2008 12:58:18 GMT
ETag: "12c008-1336-c6b00e80"
Accept-Ranges: bytes
Content-Length: 4918
Content-Type: text/html

Shouldn't that be "Content-Type: text/html; charset=UTF-8"? Yeah, 
probably.  Shouldn't the browser be using the meta tag in the HTML file 
itself?  Probably, but your broken HTML is preventing Safari from 
parsing the <meta> tag correctly.

Specifically:

$ curl http://www.python.org/doc/2.5.2/whatsnew/acks.html | grep 
rel=.first.
<link rel="first" href="whatsnew25.html" title='What's new in python 
2.5' />

The title attribute of that link element is incorrect.  It features a 
single-quote inside a single-quoted string.  Oopsie.  I don't think 
Safari should be so mean, but bad HTML is bad HTML.

Taking a local copy and fixing that title attribute (by using double 
quotes for example) causes the page to render just fine.

----------
assignee: georg.brandl
components: Documentation
messages: 74560
nosy: drj, georg.brandl
severity: normal
status: open
title: 2.5.2 whatsnew document corrupts names, by having broken HTML, at least on the Web.
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Thu Oct  9 13:27:26 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 09 Oct 2008 11:27:26 +0000
Subject: [New-bugs-announce] [issue4086] support %z format in time.strftime
	and _strptime?
In-Reply-To: <1223551646.15.0.164355592546.issue4086@psf.upfronthosting.co.za>
Message-ID: <1223551646.15.0.164355592546.issue4086@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

While responding to a c.l.py question just now I discovered that
numeric timezone offsets don't appear to be supported by either the
time.strftime function or the _strptime module.  I noticed on my
Mac's strftime(3) man page that it supports a %Z format for TZ
names and a %z format for numeric tz offsets.  It seems Python
should as well.

----------
messages: 74570
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: support %z format in time.strftime and _strptime?
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Thu Oct  9 15:39:44 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 09 Oct 2008 13:39:44 +0000
Subject: [New-bugs-announce] [issue4087] equality involving Decimals is not
	transitive; strange set behaviour results
In-Reply-To: <1223559584.24.0.470688627133.issue4087@psf.upfronthosting.co.za>
Message-ID: <1223559584.24.0.470688627133.issue4087@psf.upfronthosting.co.za>


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

The Decimal module breaks transitivity of equality:  Decimal(2) == 2 and 
2 == float(2), but Decimal(2) != float(2).

The Python set and dict implementations rely on transitivity of equality 
for correct operation.

These two facts together give some strange results when playing with 
sets and dicts involving Decimals and floats.  For example (with Python 
2.6):

>>> s = set([Decimal(2), float(2)])
>>> t = set([2])
>>> s | t == t | s
False
>>> len(s | t)
2
>>> len(t | s)
1

Other strange examples, and possible solutions, were discussed recently 
on comp.lang.python;  see the thread starting at:

http://mail.python.org/pipermail/python-list/2008-September/508859.html

Possible solutions:

(1) Document the problem, making it clear in the language reference that 
correct set operation relies on transitivity of equality, and adding a 
note to the decimal documentation indicating that mixing floats and 
Decimals in a container is asking for trouble.

(2) Fix up Decimal so that equal numeric objects compare equal; this 
would also involve fixing the hash operation.  To me, this goes against 
the philosophy of keeping the Decimal module close to the specification.

(3) Terry Reedy suggested (in the c.l.python thread linked to above) a 
simpler version of (2): allow Decimal(i) == float(i) or Decimal(i) == 
Fraction(i) to return True for all integers i.  (Decimal('0.5') == 0.5 
would still return False.)  This fixes transitivity, and has the 
advantage of not requiring any changes to the hash functions:  
hash(Decimal(i)) == hash(float(i)) is already true for all integers i.

My own preference would be simply to document the problem;  it doesn't 
seem like something that's going to affect that vast majority of Python 
users.

Raymond, Facundo:  any thoughts?

----------
messages: 74576
nosy: facundobatista, marketdickinson, rhettinger, tjreedy
priority: normal
severity: normal
status: open
title: equality involving Decimals is not transitive;  strange set behaviour results
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0

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

From report at bugs.python.org  Thu Oct  9 17:23:58 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 09 Oct 2008 15:23:58 +0000
Subject: [New-bugs-announce] [issue4088] Patch to implement a real poplib
	test suite
In-Reply-To: <1223565838.71.0.340118865105.issue4088@psf.upfronthosting.co.za>
Message-ID: <1223565838.71.0.340118865105.issue4088@psf.upfronthosting.co.za>


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

poplib module is currently lacking a test suite which actually connects
to a server and uses the POP3 class methods and facilities.
Bug #3727, discovered just a bunch of days before the stable release of
Python 3.0 is an example of how much a test suite is necessary.

As done in #3939 for the ftplib module, in attachment I provide a test
suite which implements an asyncore-based dummy POP3 server which sends
fixed response codes that I used to test all the relevant POP3 class
methods.
Tests for the POP3_SSL class are also included.
Although not that useful (IMHO) I didn't remove the old tests about
timeouts.

Tested successfully against Python 2.6 on Windows XP SP3, Debian Etch
and FreeBSD 7.0.

----------
components: Tests
files: test_poplib.patch
keywords: patch
messages: 74581
nosy: benjamin.peterson, facundobatista, giampaolo.rodola, gvanrossum
severity: normal
status: open
title: Patch to implement a real poplib test suite
versions: Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file11754/test_poplib.patch

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

From report at bugs.python.org  Thu Oct  9 17:40:43 2008
From: report at bugs.python.org (Manuel)
Date: Thu, 09 Oct 2008 15:40:43 +0000
Subject: [New-bugs-announce] [issue4089] linking python2.6.dll crash on
	windows xp
In-Reply-To: <1223566843.64.0.613878157863.issue4089@psf.upfronthosting.co.za>
Message-ID: <1223566843.64.0.613878157863.issue4089@psf.upfronthosting.co.za>


New submission from Manuel <info at makehuman.org>:

On some machines, the application (makehuman, an open source software)
crash, immediately, as soon the user try to double click on the exe. The
problem happen with the version compiled using python 2.6, while the one
compiled with 2.5 work fine.

We have asked to our users to try the installation of  Visual C++ 2005
Redistributable Package, but this hasn't fixed the crash.

Both binary files (compiled using gcc and debug symbols with 2.5 and
with 2.6) are here:

http://www.makehuman.org/tmp/makehuman_test_python25_and_python26.zip

Furthermore:

Installing full python2.6 it work.
Unistalling full python2.6 it don't work.
Installing python26 and deleting C:/python26 folder (without unistall
it), it work again...

thx,

Manuel

----------
components: Windows
messages: 74582
nosy: Manuel
severity: normal
status: open
title: linking python2.6.dll crash on windows xp
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Thu Oct  9 18:17:27 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 09 Oct 2008 16:17:27 +0000
Subject: [New-bugs-announce] [issue4090] Documenting set comparisons and
	operations
In-Reply-To: <1223569047.14.0.973921550653.issue4090@psf.upfronthosting.co.za>
Message-ID: <1223569047.14.0.973921550653.issue4090@psf.upfronthosting.co.za>


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

RefMan Expressions Comparisons has a subsection headed
"Comparison of objects of the same type depends on the type"
with entries for numbers, bytes, strings, tuples, lists, mappings, and
most_other (compared by id).  Sets (and dict views) are missing.  While
sets are similar to dicts, they are different because they also have
order comparisons.

A problem in defining comparisons for sets is that the usual definitions
depend on equality comparisons of the members involved being, as usual,
reflexive, symmetric, and transitive.  But float('nan') is irreflexive.
 For integral value i, int(i), float(i) or Fraction(i), and Decimal(i)
are (currently) jointly intransitive.  See
http://bugs.python.org/issue4087 
Even without these issues, users are free to write __eq__ methods
however they want.

So I suggest something like the following:
"If equality among the set members involved is reflexive, symmetric, and
transitive as defined in mathematics, set comparisons have the usual
definitions in terms of set inclusion.  Otherwise, they are undefined."

If dict equality had been defined in terms of equality of the set of
(key,value) pairs, it would have the same problem.  The algorithmic
definition in terms of ordered lists works fine, however.

I also suggest a warning be added at the top of the set section in the
Lib. Ref.  Something like:
"The usual definitions of set operations, given below, depend on
equality testing between the members involved being reflexive,
symmetric, and transitive.  If this is not true, results are undefined."

----------
assignee: georg.brandl
components: Documentation
messages: 74585
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Documenting set comparisons and operations
versions: Python 2.6, Python 2.7, Python 3.0

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

From report at bugs.python.org  Thu Oct  9 20:20:23 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 09 Oct 2008 18:20:23 +0000
Subject: [New-bugs-announce] [issue4091] python dll not installed in windows
	system directory
In-Reply-To: <1223576423.68.0.448178359444.issue4091@psf.upfronthosting.co.za>
Message-ID: <1223576423.68.0.448178359444.issue4091@psf.upfronthosting.co.za>


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

Python 2.6 final and Python 3.0 rc1 do NOT install the python dlls into
the windows system directory, even when installing 'for all users' and
with admin rights.  This causes problems with COM objects implemented in
Python.

Observed on Windows XP SP3.

----------
components: Installation
messages: 74591
nosy: theller
severity: normal
status: open
title: python dll not installed in windows system directory
type: behavior
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Thu Oct  9 20:44:12 2008
From: report at bugs.python.org (Aaron Brady)
Date: Thu, 09 Oct 2008 18:44:12 +0000
Subject: [New-bugs-announce] [issue4092] inspect.getargvalues return type
	not ArgInfo
In-Reply-To: <1223577852.4.0.573977291018.issue4092@psf.upfronthosting.co.za>
Message-ID: <1223577852.4.0.573977291018.issue4092@psf.upfronthosting.co.za>


New submission from Aaron Brady <castironpi at gmail.com>:

Python 2.6 (r26:66721, Oct  2 2008, 11:35:03) [MSC v.1500 32 bit
(Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import inspect
>>> type( inspect.getargvalues( inspect.currentframe() ) )

<type 'tuple'>

Docs say:

inspect.getargvalues(frame)
...
Changed in version 2.6: Returns a named tuple ArgInfo(args, varargs,
keywords, locals).

The code defines an ArgInfo type, but doesn't instantiate it in the
return, as shown here:

    return args, varargs, varkw, frame.f_locals

----------
components: Library (Lib)
messages: 74595
nosy: castironpi
severity: normal
status: open
title: inspect.getargvalues return type not ArgInfo
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Oct  9 22:21:11 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 09 Oct 2008 20:21:11 +0000
Subject: [New-bugs-announce] [issue4093] add gc/memory management tests to
	pybench
In-Reply-To: <1223583671.55.0.378027083511.issue4093@psf.upfronthosting.co.za>
Message-ID: <1223583671.55.0.378027083511.issue4093@psf.upfronthosting.co.za>


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

Issue #4074 suggests to me that maybe pybench should have some gc and/or
memory management tests. Marc-Andre, what do you think?

----------
components: Demos and Tools
messages: 74599
nosy: lemburg, pitrou
priority: normal
severity: normal
status: open
title: add gc/memory management tests to pybench
type: feature request
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Thu Oct  9 22:48:59 2008
From: report at bugs.python.org (Martin Marcher)
Date: Thu, 09 Oct 2008 20:48:59 +0000
Subject: [New-bugs-announce] [issue4094] "Future statements" Doc from 2.6
	refers to 2.5
In-Reply-To: <1223585339.1.0.142071058322.issue4094@psf.upfronthosting.co.za>
Message-ID: <1223585339.1.0.142071058322.issue4094@psf.upfronthosting.co.za>


New submission from Martin Marcher <martin at marcher.name>:

http://docs.python.org/reference/simple_stmts.html#future-statements

says this:

"""
The features recognized by Python 2.5 are absolute_import, division,
generators, nested_scopes and with_statement. generators and
nested_scopes are redundant in Python version 2.3 and above because they
are always enabled.
"""

shouldn't it mention the features recognized by Python 2.6?

----------
assignee: georg.brandl
components: Documentation
messages: 74601
nosy: georg.brandl, martin.marcher
severity: normal
status: open
title: "Future statements" Doc from 2.6 refers to 2.5
versions: Python 2.6

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

From report at bugs.python.org  Fri Oct 10 08:03:51 2008
From: report at bugs.python.org (Nobody/Anonymous)
Date: Fri, 10 Oct 2008 06:03:51 +0000
Subject: [New-bugs-announce] [issue4095] Delivery Status
In-Reply-To: <20081010060347.AD74078547@psf.upfronthosting.co.za>
Message-ID: <20081010060347.AD74078547@psf.upfronthosting.co.za>


New submission from Nobody/Anonymous:

--- The following addresses had delivery problems ---

<masuda at bcomp.metro-u.ac.jp>   (5.1.1 <masuda at bcomp.metro-u.ac.jp>... User unknown)

----------
files: deliverystatus.txt, unnamed
messages: 74616
nosy: nobody
severity: normal
status: open
title: Delivery Status
Added file: http://bugs.python.org/file11759/deliverystatus.txt
Added file: http://bugs.python.org/file11760/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4095>
_______________________________________
-------------- next part --------------
An embedded message was scrubbed...
From: unknown sender
Subject: no subject
Date: no date
Size: 2077
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20081010/3c1a532a/attachment.eml>

From report at bugs.python.org  Fri Oct 10 09:22:52 2008
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 10 Oct 2008 07:22:52 +0000
Subject: [New-bugs-announce] [issue4096] Lib/lib2to3/*.pickle are shipped /
	modified in the build
In-Reply-To: <1223623372.4.0.845692129772.issue4096@psf.upfronthosting.co.za>
Message-ID: <1223623372.4.0.845692129772.issue4096@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

the files
  Lib/lib2to3/Grammar2.6.0.final.0.pickle
  Lib/lib2to3/PatternGrammar2.6.0.final.0.pickle

are created/modfied during a build/test cycle. Is this expected, should
these be included in the release at all?

----------
messages: 74617
nosy: doko
severity: normal
status: open
title: Lib/lib2to3/*.pickle are shipped / modified in the build
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Fri Oct 10 10:54:37 2008
From: report at bugs.python.org (pinkisntwell)
Date: Fri, 10 Oct 2008 08:54:37 +0000
Subject: [New-bugs-announce] [issue4097] Traceback doesn't run back all the
	way
In-Reply-To: <1223628877.95.0.314236437557.issue4097@psf.upfronthosting.co.za>
Message-ID: <1223628877.95.0.314236437557.issue4097@psf.upfronthosting.co.za>


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

I just got an exception and the traceback wouldn't go all the 
way to the statement that threw the exception. I found that out 
by using the debugger.

Contrast the traceback:

http://tinyurl.com/5xglde

with the debugger output (notice the arrow pointing to the last 
statement the traceback showed and how the execution went on 
beyond it):

http://tinyurl.com/3fjgrl

----------
components: None
messages: 74621
nosy: pinkisntwell
severity: normal
status: open
title: Traceback doesn't run back all the way
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Oct 10 11:24:44 2008
From: report at bugs.python.org (Torsten Rottmann)
Date: Fri, 10 Oct 2008 09:24:44 +0000
Subject: [New-bugs-announce] [issue4098] surprised by default list parameter
In-Reply-To: <1223630684.29.0.595274599249.issue4098@psf.upfronthosting.co.za>
Message-ID: <1223630684.29.0.595274599249.issue4098@psf.upfronthosting.co.za>


New submission from Torsten Rottmann <trott at meditec-gmbh.com>:

The attached file produced the following result:

______________________
trott$ python2.5 p6.py
[]
[1234]
______________________

I expected both times the empty list since the print
statement prints just a defaulted parameter ("e") which
was defaulted to an empty list literal ("[]") and never set
by supplying an actual class parameter.

The object property "entries" appears to be shared by
both instances. Why?

----------
components: Build
files: p6.py
messages: 74624
nosy: trott
severity: normal
status: open
title: surprised by default list parameter
type: behavior
versions: Python 2.5, Python 2.5.3, Python 2.6
Added file: http://bugs.python.org/file11761/p6.py

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

From report at bugs.python.org  Fri Oct 10 14:37:21 2008
From: report at bugs.python.org (=?utf-8?q?Bartosz_Radaczy=C5=84ski?=)
Date: Fri, 10 Oct 2008 12:37:21 +0000
Subject: [New-bugs-announce] [issue4099] dir on a compiled re does not show
	pattern as a part of the list
In-Reply-To: <1223642241.74.0.837602325601.issue4099@psf.upfronthosting.co.za>
Message-ID: <1223642241.74.0.837602325601.issue4099@psf.upfronthosting.co.za>


New submission from Bartosz Radaczy?ski <radaczynski at gmail.com>:

It does not show a few other things that are listed here:
http://www.python.org/doc/2.5.2/lib/re-objects.html

----------
components: Regular Expressions
messages: 74632
nosy: bartoszr
severity: normal
status: open
title: dir on a compiled re does not show pattern as a part of the list
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Fri Oct 10 16:53:38 2008
From: report at bugs.python.org (roland rehmnert)
Date: Fri, 10 Oct 2008 14:53:38 +0000
Subject: [New-bugs-announce] [issue4100] xml.etree.ElementTree does not read
	xml-text over page bonderies
In-Reply-To: <1223650418.42.0.473297107812.issue4100@psf.upfronthosting.co.za>
Message-ID: <1223650418.42.0.473297107812.issue4100@psf.upfronthosting.co.za>


New submission from roland rehmnert <roland.rehmnert at ericsson.com>:

xml text fields are not read properly when it is encountered in a
'start' event.

During a 'start'-event elem.text returns None, if the text string cross
a page boundary of the file. (this is platform dependent and a typical
value is 8K (8192 byte)).  



This line cause an error if the page size is 8192.
<a>this is a text where X has position 8192 in the file</a>

In most cases this erroneous behaviour can be avoid when elem.tree
always returns the proper value at the 'end'-event.   


Two files are submitted:
bug.py: An excerpted file that produced an error with the submitted xml
file.

bug.xml: An xml file, a little bit more then 8200 bytes. In can of the
page size is greater than 8K.. file should be enlarged. Important is
however that the text should cross the page boundary. Tags and
attributes and attribute values as well are OK

 
I might have misunderstood the documentation of etree, because there are
situations that I have not tested.
/roland

----------
components: Library (Lib)
messages: 74635
nosy: roland
severity: normal
status: open
title: xml.etree.ElementTree does not read xml-text over page bonderies
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Fri Oct 10 23:11:25 2008
From: report at bugs.python.org (Antoine d'Otreppe)
Date: Fri, 10 Oct 2008 21:11:25 +0000
Subject: [New-bugs-announce] [issue4101] Missing type in "types" module
In-Reply-To: <1223673085.31.0.428507703643.issue4101@psf.upfronthosting.co.za>
Message-ID: <1223673085.31.0.428507703643.issue4101@psf.upfronthosting.co.za>


New submission from Antoine d'Otreppe <a.dotreppe at gmail.com>:

Hello

There's a type missing in the standard "types" modules (or I didn't find
it, in what case I apologize for this useless posting)

Consider this code:

---
WrapperDescriptorType = None

class Meta(type):
    def __init__(cls, *args, **kwargs):
        global WrapperDescriptorType
        type.__init__(cls, *args, **kwargs)
        WrapperDescriptorType = type(cls.__init__)

class A:
    __metaclass__ = Meta
---

I could not find WrapperDescriptorType in types module.

btw, I have to pass this descriptor to another function. But in fact I
don't need the wrapper but the real method. How to get it ?

----------
components: Library (Lib)
messages: 74643
nosy: Antoine d'Otreppe
severity: normal
status: open
title: Missing type in "types" module
type: feature request
versions: Python 2.5

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

From report at bugs.python.org  Fri Oct 10 23:21:01 2008
From: report at bugs.python.org (Mikhail Gusarov)
Date: Fri, 10 Oct 2008 21:21:01 +0000
Subject: [New-bugs-announce] [issue4102] sphinx: ansi color even on dumb
	terminal
In-Reply-To: <1223673661.93.0.815684986423.issue4102@psf.upfronthosting.co.za>
Message-ID: <1223673661.93.0.815684986423.issue4102@psf.upfronthosting.co.za>


New submission from Mikhail Gusarov <dottedmag at dottedmag.net>:

Debian bug #501629 (http://bugs.debian.org/cgi-bin/bugreport.cgi?
bug=501629).

Both sphinx-build and sphinx-quicksetup attempt (and fail) to use ansi
color sequences, even when TERM=dumb (for example, when run from an
emacs shell buffer, or m-x compile.  This produces garbage, like this:

^[[01mSphinx v0.4.2, building linkcheck^[[39;49;00m

While it does look like I can add -N in the generated Makefile, and
thus this is only a wishlist item since I have a workaround - it
really shouldn't generate color unless it has *some* indication that
it might work - even mooching off of $LSCOLORS would be better than
doing it blindly, though it should be enough to look at a TERM or
TERMCAP property - or perhaps indirectly via curses.has_colors() which
does appear to be able to tell "xterm" from "dumb" successfully.

----------
messages: 74644
nosy: dottedmag
severity: normal
status: open
title: sphinx: ansi color even on dumb terminal

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

From report at bugs.python.org  Fri Oct 10 23:32:57 2008
From: report at bugs.python.org (Mikhail Gusarov)
Date: Fri, 10 Oct 2008 21:32:57 +0000
Subject: [New-bugs-announce] [issue4103] sphinx: latexwriter uses undefined
	'excdescni' environment
In-Reply-To: <1223674377.15.0.736293209348.issue4103@psf.upfronthosting.co.za>
Message-ID: <1223674377.15.0.736293209348.issue4103@psf.upfronthosting.co.za>


New submission from Mikhail Gusarov <dottedmag at dottedmag.net>:

Debian bug#501763
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501763):

when using the autodoc extension similiar to this template:

.. automodule:: mvpa.misc.exceptions
  :members:
  :undoc-members:
  :show-inheritance:
  :noindex:

the generated latex code cannot be compiled, as it uses an undefined
environment.

  ! LaTeX Error: Environment excdescni undefined.

This is supposed to be the corresponding env to 'excdesc' for exception
descriptions that should not end up in the index. It looks like this has
simply been forgotten, as e.g. funcdescni is part of
texinputs/sphinx.sty

Looking at

  http://svn.python.org/projects/doctools/trunk/sphinx/texinputs/
sphinx.sty

I'd say, that the problem is still present in the current SVN trunk.

----------
assignee: georg.brandl
components: Documentation
messages: 74646
nosy: dottedmag, georg.brandl
severity: normal
status: open
title: sphinx: latexwriter uses undefined 'excdescni' environment
type: behavior

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

From report at bugs.python.org  Fri Oct 10 23:35:36 2008
From: report at bugs.python.org (Antoine d'Otreppe)
Date: Fri, 10 Oct 2008 21:35:36 +0000
Subject: [New-bugs-announce] [issue4104] Namespace inconsistency
In-Reply-To: <1223674536.22.0.160836227089.issue4104@psf.upfronthosting.co.za>
Message-ID: <1223674536.22.0.160836227089.issue4104@psf.upfronthosting.co.za>


New submission from Antoine d'Otreppe <a.dotreppe at gmail.com>:

Hello

See the following code and comments for explanation ;) (Try it with
interactive mode)

---
>>> class A:
...     class B:
...         pass

>>> A
<class __main__.A at 0x...>
>>> A.B
<class __main__.B at 0x...>
>>> B
NameError: B is not defined
---

This seems to be inconsistent, as Python represents A.B as __main__.B,
but B is not accessable from __main__

Maybe this could be better:
---
>>> A.B
<class __main__.A.B at 0x...>
                  ^
---

----------
components: Interpreter Core
messages: 74648
nosy: Antoine d'Otreppe
severity: normal
status: open
title: Namespace inconsistency
type: feature request
versions: Python 2.5

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

From report at bugs.python.org  Sat Oct 11 00:12:22 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 10 Oct 2008 22:12:22 +0000
Subject: [New-bugs-announce] [issue4105] Renamed PyGILState_Acquire to
	PyGILState_Ensure in Docs/c-api/init.rst
In-Reply-To: <1223676742.05.0.929533149054.issue4105@psf.upfronthosting.co.za>
Message-ID: <1223676742.05.0.929533149054.issue4105@psf.upfronthosting.co.za>


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

I see the comment in Include/pystate.h got fixed, but this other in
Docs/c-api/init.rst didn't

----------
files: PyGILState_Acquire=>PyGILState_Ensure.diff
keywords: patch
messages: 74651
nosy: gpolo
severity: normal
status: open
title: Renamed PyGILState_Acquire to PyGILState_Ensure in Docs/c-api/init.rst
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11767/PyGILState_Acquire=>PyGILState_Ensure.diff

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

From report at bugs.python.org  Sat Oct 11 05:30:22 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 11 Oct 2008 03:30:22 +0000
Subject: [New-bugs-announce] [issue4106] multiprocessing occasionally spits
	out exception during shutdown
In-Reply-To: <1223695822.85.0.145044917765.issue4106@psf.upfronthosting.co.za>
Message-ID: <1223695822.85.0.145044917765.issue4106@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

I worked up a simple example of using the external processing module 
(0.52) for a friend at work today.  I noticed some cases where it raised 
exceptions during exit.  Not all the time, but not infrequently either.  
This evening I tweaked it for the 2.6 multiprocessing module's API and 
tried it out.  I ran it in a large loop:

   for i in $(range 500) ; do
       echo '!'$i
       python test_proc.py
   end | egrep '!'

Most of the time all I see are the '!' lines from the echo command.  
Every once in awhile I see a traceback though.  For example:

Exception in thread QueueFeederThread (most likely raised during 
interpreter shutdown):
Traceback (most recent call last):
  File "/Users/skip/local/lib/python2.7/threading.py", line 522, in 
__bootstrap_inner
  File "/Users/skip/local/lib/python2.7/threading.py", line 477, in run
  File "/Users/skip/local/lib/python2.7/multiprocessing/queues.py", line 
233, in _feed
<type 'exceptions.TypeError'>: 'NoneType' object is not callable

This occurred once in approximately 1500 runs of the script (three times 
through the above shell loop).  The script used to trigger this 
exception is attached.

----------
components: Library (Lib)
files: test_proc.py
messages: 74656
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: multiprocessing occasionally spits out exception during shutdown
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file11771/test_proc.py

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

From report at bugs.python.org  Sun Oct 12 12:03:47 2008
From: report at bugs.python.org (jamesie)
Date: Sun, 12 Oct 2008 10:03:47 +0000
Subject: [New-bugs-announce] [issue4107] Backticks still mentioned in
	documentation
In-Reply-To: <1223805827.76.0.682079742301.issue4107@psf.upfronthosting.co.za>
Message-ID: <1223805827.76.0.682079742301.issue4107@psf.upfronthosting.co.za>


New submission from jamesie <post06 at jamesie.de>:

At
<http://docs.python.org/dev/3.0/reference/datamodel.html#object.__repr__> the
following part of the first sentence should be ommited:

"and by string conversions (reverse quotes)"

----------
assignee: georg.brandl
components: Documentation
messages: 74662
nosy: georg.brandl, jamesie
severity: normal
status: open
title: Backticks still mentioned in documentation
versions: Python 3.0

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

From report at bugs.python.org  Sun Oct 12 15:41:32 2008
From: report at bugs.python.org (taskinoor hasan sajid)
Date: Sun, 12 Oct 2008 13:41:32 +0000
Subject: [New-bugs-announce] [issue4108] robotparser.py fail when more than
	one User-Agent: * is present
In-Reply-To: <1223818892.29.0.704490324988.issue4108@psf.upfronthosting.co.za>
Message-ID: <1223818892.29.0.704490324988.issue4108@psf.upfronthosting.co.za>


New submission from taskinoor hasan sajid <taskinoor at gmail.com>:

Check the robots.txt file from mathworld.

--> http://mathworld.wolfram.com/robots.txt

It contains 2 User-Agent: * lines.

>From http://www.robotstxt.org/norobots-rfc.txt

"These name tokens are used in User-agent lines in /robots.txt to
identify to which specific robots the record applies. The robot
must obey the first record in /robots.txt that contains a User-
Agent line whose value contains the name token of the robot as a 
substring. The name comparisons are case-insensitive. If no such
record exists, it should obey the first record with a User-agent
line with a "*" value, if present. If no record satisfied either
condition, or no records are present at all, access is unlimited."

But it seems that our robotparser is obeying the 2nd one. the problem
occures because robotparser assumes that no robots.txt will contain two
* user-agent. it should not have two two such line, but in reality many
site may have two.

So i have changed robotparser.py as follow:

    def _add_entry(self, entry):
        if "*" in entry.useragents:
            # the default entry is considered last
            if self.default_entry == None:   # this check is added
                   self.default_entry = entry
        else:
            self.entries.append(entry)

And at the end of parse(self, lines) method

        if state==2:
#            self.entries.append(entry)
            self._add_entry(entry)  # necessary if there is no new line
at end and last User-Agent is *

----------
components: Library (Lib)
messages: 74665
nosy: thsajid
severity: normal
status: open
title: robotparser.py fail when more than one User-Agent: * is present
versions: Python 2.5

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

From report at bugs.python.org  Sun Oct 12 15:56:42 2008
From: report at bugs.python.org (Eric Atienza)
Date: Sun, 12 Oct 2008 13:56:42 +0000
Subject: [New-bugs-announce] [issue4109] Wrong UnboundLocalError with +=
	operator
In-Reply-To: <1223819802.24.0.226294192921.issue4109@psf.upfronthosting.co.za>
Message-ID: <1223819802.24.0.226294192921.issue4109@psf.upfronthosting.co.za>


New submission from Eric Atienza <eric at ericaro.net>:

the following code :

def test():
    code=''
    def sub(n):
        for i in range(n):
            code+=str(i)
    sub(5)
    sub(10)
    return code

>>> test()
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "<console>", line 6, in test
  File "<console>", line 5, in sub
UnboundLocalError: local variable 'code' referenced before assignment

error came from the += operator.
Tested for code initialized to '', to 0
I guess it's the same for all inline operators.

I agree that global variables CANNOT be assigned, it's ok.

But += (and I guess *= etc) operators are not assignements, and are not 
different from .append(), or .extend() methods.

I was expecting += to work the same as append() method

----------
components: Interpreter Core
messages: 74666
nosy: atienza
severity: normal
status: open
title: Wrong UnboundLocalError with += operator
type: behavior
versions: Python 2.5.3

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

From report at bugs.python.org  Sun Oct 12 17:58:53 2008
From: report at bugs.python.org (John)
Date: Sun, 12 Oct 2008 15:58:53 +0000
Subject: [New-bugs-announce] [issue4110] A minor slip while typing
In-Reply-To: <1223827133.93.0.666045879056.issue4110@psf.upfronthosting.co.za>
Message-ID: <1223827133.93.0.666045879056.issue4110@psf.upfronthosting.co.za>


New submission from John <vinetouu at gmail.com>:

Hello,

please let me focus your attention to a little slip that was made while
typing a code example in the Python 3.0 documentation. Please visit the
link  
http://docs.python.org/dev/3.0/library/functions.html?highlight=property#property
  and note the 3rd code example which starts like this:

class C(object):
    def __init__(self): self._x = None


This is probably a slip, because it should better be like this:

class C(object):
    def __init__(self):
        self._x = None


And since this is the only method with such coding style used, it's
probably a slip. Please fix this if you have the time to do so. After
all, it's not a very time-consuming thing to do.


P.S.: I have discovered that the code example

class C(object):
    def __init__(self): self._x = None

was used from the documentation of Python 2.5.x which is

class C(object):
    def __init__(self): self._x = None
    def getx(self): return self._x
    def setx(self, value): self._x = value
    def delx(self): del self._x
    x = property(getx, setx, delx, "I'm the 'x' property.")

but the author of the documentation forgot to put the part  self._x =
None  in a new line and indent the code block.

This slip is present in the documentation for both Python 2.6 and Python
3.0. Please fix it if it is doable. Thanks.

----------
assignee: georg.brandl
components: Documentation
messages: 74669
nosy: georg.brandl, vinetou
severity: normal
status: open
title: A minor slip while typing
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Oct 12 18:08:15 2008
From: report at bugs.python.org (Brett Hoerner)
Date: Sun, 12 Oct 2008 16:08:15 +0000
Subject: [New-bugs-announce] [issue4111] Add DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>


New submission from Brett Hoerner <bretthoerner at gmail.com>:

It would be great if the main Python distribution supported DTrace on
(Open)Solaris / FreeBSD / OS X.

I've attached a patch against 2.6 that instruments function calls.  It's
from the ed scripts included in Apple's Python distribution:
http://developer.apple.com/opensource/index.html (PSF License)

It is imperfect because I wasn't sure how to do the equivalent of IFDEF
in the Makefile.pre.in, as you can see this patch will make ceval.o
depend on pydtrace.h, which depends on having a local `dtrace` command.
 The rest of the patch properly uses IFDEFs.

----------
components: Build, Installation
files: python-2.6-dtrace.diff
keywords: patch
messages: 74670
nosy: bretthoerner
severity: normal
status: open
title: Add DTrace probes
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file11772/python-2.6-dtrace.diff

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

From report at bugs.python.org  Mon Oct 13 12:36:19 2008
From: report at bugs.python.org (=?utf-8?q?Boye_H=C3=B8verstad?=)
Date: Mon, 13 Oct 2008 10:36:19 +0000
Subject: [New-bugs-announce] [issue4112] Subprocess: Popen'ed children hang
	due to open pipes
In-Reply-To: <1223894179.31.0.303015562598.issue4112@psf.upfronthosting.co.za>
Message-ID: <1223894179.31.0.303015562598.issue4112@psf.upfronthosting.co.za>


New submission from Boye H?verstad <boyeah at gmail.com>:

subprocess.Popen.wait() hangs if you have spawned multiple child
processes that do not terminate until their standard input is closed
('cat' is example of such a process).  This happens on POSIX platforms.
 I'm using Python 2.5.1, but I believe the issue is present in the SVN
trunk version of subprocess as well.

Here is a test program:
--------------------------
import subprocess, sys

p1 = subprocess.Popen("cat", bufsize=0, stdin=subprocess.PIPE)
p2 = subprocess.Popen("cat", bufsize=0, stdin=subprocess.PIPE)

p1.stdin.close()
ret = p1.wait()
print >>sys.stderr, "Child 1 wait completed with ret", ret

p2.stdin.close()
ret = p2.wait()
print >>sys.stderr, "Child 2 wait completed with ret", ret, "Bye bye"
--------------------------

The call to p1.wait() will never return.  If p2.wait is called first,
the program terminates cleanly.

p1 never terminates because p1.stdin is duplicated in the (second) child
process when the parent process forks as part of the call to p2 =
subprocess.Popen().  The line p1.stdin.close() thus has no effect.

I am not sure whether this is a bug or deliberate design, but the
behavior above seems a bit weird to me, and it took me quite some time
to figure out what happened.  However, the proposed fix below of course
has side effects that may be undesirable.

wait() will not hang if  the "close on exec" flag is set on the
subprocess pipes.  Conveniently, the method _set_cloexec_flag already
exists to do this, so the fix amounts to calling this from
Popen._get_handles:

elif stdin == PIPE:
    p2cread, p2cwrite = os.pipe()
    self._set_cloexec_flag(p2cwrite)

The last line is the added one, similar lines must be added for stdout
and stderr.

Alternatively, the test program above will terminate cleanly if
"p1._set_cloexec_flag(p1.stdin)" is added before the creation of p2.

----------
components: Library (Lib)
messages: 74680
nosy: boye
severity: normal
status: open
title: Subprocess: Popen'ed children hang due to open pipes
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Oct 13 13:45:15 2008
From: report at bugs.python.org (Andrew Stribblehill)
Date: Mon, 13 Oct 2008 11:45:15 +0000
Subject: [New-bugs-announce] [issue4113] functools.partial(), no __name__;
	wrong __doc__
In-Reply-To: <1223898315.71.0.950281538816.issue4113@psf.upfronthosting.co.za>
Message-ID: <1223898315.71.0.950281538816.issue4113@psf.upfronthosting.co.za>


New submission from Andrew Stribblehill <ads at wompom.org>:

When I partially apply a function using functools.partial(), the
resultant function doesn't have the same name as the original function
(it has no __name__) and its docstring is that of functools.partial()
rather than that of the function that was partially applied.

Transcript:

Python 2.6 (r26:66714, Oct 13 2008, 10:32:02)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>> import functools
>>> def sum(a,b,c):
...   return a+b+c
...
>>> functools.partial(sum,1)
<functools.partial object at 0xf7efeb6c>
>>> p = functools.partial(sum, 1)
>>> p.__name__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'functools.partial' object has no attribute '__name__'
>>> p(2,3)
6
>>> sum.__name__
'sum'
>>> sum.__doc__
>>> p.__doc__
'partial(func, *args, **keywords) - new function with partial
application\n\tof the given arguments and keywords.\n'

----------
components: Extension Modules
messages: 74682
nosy: stribb
severity: normal
status: open
title: functools.partial(), no __name__; wrong __doc__
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Oct 13 19:11:43 2008
From: report at bugs.python.org (TD22057)
Date: Mon, 13 Oct 2008 17:11:43 +0000
Subject: [New-bugs-announce] [issue4114] struct returns incorrect 4 byte
	float
In-Reply-To: <1223917903.14.0.727253011599.issue4114@psf.upfronthosting.co.za>
Message-ID: <1223917903.14.0.727253011599.issue4114@psf.upfronthosting.co.za>


New submission from TD22057 <ted.drain at jpl.nasa.gov>:

FYI Actual version is 2.5.2 running on Linux RHE4.

>>> import struct
>>> fmt ='>f'
>>> v=1.8183e-7
>>> v
1.8183000000000001e-07
>>> s=struct.pack(fmt,v)
>>> struct.unpack(fmt,s)
(1.818300034983622e-07,)

Looks to me like the float->double conversion is not being zeroed out
before the 4 bytes are written to it.  FYI this is a fairly serious
issue since it leads to incorrect results be read from files (at least
for me anyway).

----------
components: Extension Modules
messages: 74690
nosy: TD22057
severity: normal
status: open
title: struct returns incorrect 4 byte float
type: behavior
versions: Python 2.5.3

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

From report at bugs.python.org  Tue Oct 14 00:01:31 2008
From: report at bugs.python.org (Terry Scott)
Date: Mon, 13 Oct 2008 22:01:31 +0000
Subject: [New-bugs-announce] [issue4115] split() method
In-Reply-To: <1223935291.9.0.99017812612.issue4115@psf.upfronthosting.co.za>
Message-ID: <1223935291.9.0.99017812612.issue4115@psf.upfronthosting.co.za>


New submission from Terry Scott <tscott at fisher.unco.edu>:

x = "Four score  and seven"
x.split() => ["Four", "score", "and", "seven"] 
x.split(" ") => ["Four", "score", " ", "and", "seven"] 

Probably not a big deal but it seems that it should be consistent. One
of my students spotted it.

----------
components: Windows
messages: 74701
nosy: terry.scott
severity: normal
status: open
title: split() method
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue Oct 14 00:57:07 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Mon, 13 Oct 2008 22:57:07 +0000
Subject: [New-bugs-announce] [issue4116] name conflict in
	ScrolledCanvas.__init__() in Lib/turtle.py
In-Reply-To: <1223938627.85.0.00676973039125.issue4116@psf.upfronthosting.co.za>
Message-ID: <1223938627.85.0.00676973039125.issue4116@psf.upfronthosting.co.za>


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

In ScrolledCanvas.__init__()  there's a name conflict with a methodname
of the parentclass Frame: _root. The bugfix consists in renaming this
attribute, which occurs only twice. No change in behaviour at all.

Regards,
Gregor

----------
components: Library (Lib)
files: ScrolledCanvas.__init__.diff
keywords: patch
messages: 74709
nosy: gregorlingl, loewis
severity: normal
status: open
title: name conflict in ScrolledCanvas.__init__() in Lib/turtle.py
versions: Python 3.0
Added file: http://bugs.python.org/file11776/ScrolledCanvas.__init__.diff

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

From report at bugs.python.org  Tue Oct 14 01:02:44 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Mon, 13 Oct 2008 23:02:44 +0000
Subject: [New-bugs-announce] [issue4117] missing update() in _Screen.setup()
	of Lib/turtle.py
In-Reply-To: <1223938964.4.0.025382695872.issue4117@psf.upfronthosting.co.za>
Message-ID: <1223938964.4.0.025382695872.issue4117@psf.upfronthosting.co.za>


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

In Lib/turtle.py

_Screen.setup() needs a final update() call in order
to ensure, that immediately following calls of window_width() or
window_height() return correct values.

Consequently the setup() method call in _Screen.__init__()
has to take place only after the call of TurtleScreen.__init__()

----------
components: Library (Lib)
files: _Screen.setup.diff
keywords: patch
messages: 74710
nosy: gregorlingl, loewis
severity: normal
status: open
title: missing update() in _Screen.setup() of Lib/turtle.py
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11777/_Screen.setup.diff

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

From report at bugs.python.org  Tue Oct 14 01:17:35 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 13 Oct 2008 23:17:35 +0000
Subject: [New-bugs-announce] [issue4118] Built-in compile() and ast module
	doc issues
In-Reply-To: <1223939855.4.0.779100160496.issue4118@psf.upfronthosting.co.za>
Message-ID: <1223939855.4.0.779100160496.issue4118@psf.upfronthosting.co.za>


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

>From docs.python.org
2.6: Compile the source into a code or AST object.
3.0: Compile the source into a code object.
Add 'or AST ' to the latter.

Both: Refer to the _ast module documentation
<there is none, docs only for the ast module, but see below>

Both: for information on how to compile into and from AST objects.

This sentence should at least have 'and from AST ' deleted. The
information on 'from' is given in the previous sentence.
Both: source can either be a string or an AST object.

The ast doc adds nothing.  "A modified abstract syntax tree can be
compiled into a Python code object using the built-in compile() function."

The remainder of the sentence could be replaced by the shorter
"To compile into an AST object, import ast and pass ast.PyCF_ONLY_AST as
a flag."

This could be followed by "See ast module documentation for more."

----
In the ast doc, both say: "An abstract syntax tree can be generated by
passing _ast.PyCF_ONLY_AST ..."

That should be ast, not _ast; the existence of the shadow C version is a
CPython implementation detail.

In the parse() doc lines, 'PyCF_ONLY_AST' should, I think, have the
'ast' prefix as the former will not work unless one does 'from ast
import PyCF_ONLY_AST' (or '... import *').

----
Back to compile():
2.6 (and before): When compiling a string with multi-line statements...
3.0 <Caveats missing>

The first, about '\n' versus '\r\n' still applies.
print (compile("def f():\r\n  pass #haha",'','exec')) #fails
print (compile("def f():\n  pass #haha",'','exec')) # succeeds

The second, at least for 2.5.2 and 3.0c1 (and I presume for 2.6), only
applies, it seems, based on testing, if the last line consists only of a
comment.  In the second example above, putting '#haha' on a separate
line fails.

See: 'compile' built-in function failures when missing EOL
http://bugs.python.org/issue1479099

I am not sure what to suggest, but a warning that is nearly always a
false alarm confuses and lulls.

----------
assignee: georg.brandl
components: Documentation
messages: 74712
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Built-in compile() and ast module doc issues
versions: Python 2.6, Python 2.7, Python 3.0

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

From report at bugs.python.org  Tue Oct 14 01:44:54 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Oct 2008 23:44:54 +0000
Subject: [New-bugs-announce] [issue4119] ssl wrapper: add makefile() method
In-Reply-To: <1223941494.63.0.576303360385.issue4119@psf.upfronthosting.co.za>
Message-ID: <1223941494.63.0.576303360385.issue4119@psf.upfronthosting.co.za>


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

ssl module of Python 2.6 has a makefile() method whereas Python3 has 
not. Attached patch fix this issue. There a just a difference between 
Python2 and Python3 makefile() method: Python3 has not bufsize 
optional argument because SocketIO() is unbuffered.

----------
components: Library (Lib)
files: ssl_makefile.py
messages: 74714
nosy: haypo
severity: normal
status: open
title: ssl wrapper: add makefile() method
versions: Python 3.0
Added file: http://bugs.python.org/file11779/ssl_makefile.py

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

From report at bugs.python.org  Tue Oct 14 10:01:52 2008
From: report at bugs.python.org (Andre Heider)
Date: Tue, 14 Oct 2008 08:01:52 +0000
Subject: [New-bugs-announce] [issue4120] Do not embed manifest files in
	*.pyd when compiling with MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>


New submission from Andre Heider <a.heider at gom.com>:

The MSVC build process currently embeds the .manifest file, which is
generated by the MS linker, in the following files:

- python.exe
- pythonXY.dll
- *.pyd

The latter is problematic on machines without the MS CRT redistributable
installed (No CRT files in %WINDIR%\WinSxS). While this error won't
occur when the python package is installed, it will in other cases like
in ours:

We use the python interpreter within our application and do ship
python25.dll. We also ship the MS CRT files and place them next to the
main application (MS calls this "private assemblies" and "xcopy
deployment). We do not install the redistributable, because it needs
admin rights.
If a user tries to "import socket" on this setup it will fail, because
the Side by Side / Fusion loader expects the CRT next to the calling
Binary (%PYTHONHOME%\DLLs\_socket.pyd) because of the manifest.

The solution is to not embed the manifest in the *.pyd Modules. This way
the modules just link against msvc*.dll. This works because the windows
loader has already mapped the CRT into memory for the process (either
through python.exe or pythonXY.dll). This is also the only reliable way
i could find to fix the import on machines without redist.

Attached you'll find a patch for the MSVC90 build, apply with -p5. It
will only patch the release file, PCbuild8/pyd_d.vsprops requires the
same fix.

Trolltech also uses this approach for its plugins:
https://trolltech.com/developer/faqs/faq.2007-10-19.6185511205

----------
components: Build
files: Python-2.5.2-no.manifest.in.pyd.diff
keywords: patch
messages: 74723
nosy: aheider
severity: normal
status: open
title: Do not embed manifest files in *.pyd when compiling with MSVC
versions: Python 2.5
Added file: http://bugs.python.org/file11783/Python-2.5.2-no.manifest.in.pyd.diff

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

From report at bugs.python.org  Tue Oct 14 13:02:02 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Oct 2008 11:02:02 +0000
Subject: [New-bugs-announce] [issue4121] open(): use keyword only for
	arguments other than file and mode
In-Reply-To: <1223982122.27.0.317312591734.issue4121@psf.upfronthosting.co.za>
Message-ID: <1223982122.27.0.317312591734.issue4121@psf.upfronthosting.co.za>


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

In the C library, fopen() have two arguments: filename and the mode, 
and open() has three arguments: filename, mode and flags. In Python, 
open() has 7 arguments:
 - file
 - mode
 - buffering
 - encoding
 - errors
 - newline
 - closefd

Most programs only use the two first arguments, but buffering is 
sometimes set. Eg. open(filename, "r") or open(filename, "wb", 0).

I think that only the file and mode arguments are easy to understand, 
the others have to be specified using their name. Eg. 
open(filename, "wb", buffering=0) or open(filename, "r", 
encoding="GBK").

I wrote a patch to use keyword only arguments, and another to fix some 
libraries and the unit tests.

explicit_open.patch needs review. I don't know the best way to create 
a dictionary. Py_BuildValue() may be used to write a smaller patch.

--

open(file, mode, *, buffering, ...) may be replaced by open(file, 
mode, buffering, *, ...) to keep compatibility with Python2, but I 
read somewhere that Python3 breaks the compatibility and a 2to3 fixer 
can be used to fix open().

----------
components: Library (Lib)
files: explicit_open.patch
keywords: needs review, patch, patch
messages: 74727
nosy: haypo
severity: normal
status: open
title: open(): use keyword only for arguments other than file and mode
versions: Python 3.0
Added file: http://bugs.python.org/file11784/explicit_open.patch

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

From report at bugs.python.org  Tue Oct 14 15:39:08 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 14 Oct 2008 13:39:08 +0000
Subject: [New-bugs-announce] [issue4122] undefined reference to
	_Py_ascii_whitespace
In-Reply-To: <1223991548.86.0.809237615427.issue4122@psf.upfronthosting.co.za>
Message-ID: <1223991548.86.0.809237615427.issue4122@psf.upfronthosting.co.za>


New submission from Ralf Schmitt <schmir at gmail.com>:

unicodeobject.h contains the following code:

extern const unsigned char _Py_ascii_whitespace[];

#define Py_UNICODE_ISSPACE(ch) \
	((ch) < 128U ? _Py_ascii_whitespace[(ch)] : _PyUnicode_IsWhitespace(ch))

When linking a module which uses the Py_UNICODE_ISSPACE macro, I get an
error "undefined reference to _Py_ascii_whitespace" (on windows using
the mingw compiler, linux works without problems).

The symbol should most probably be exported with the PyAPI_DATA macro...

This happens with python 2.6.

----------
components: Windows
messages: 74743
nosy: schmir
severity: normal
status: open
title: undefined reference to _Py_ascii_whitespace
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Wed Oct 15 00:03:01 2008
From: report at bugs.python.org (paul rubin)
Date: Tue, 14 Oct 2008 22:03:01 +0000
Subject: [New-bugs-announce] [issue4123] random.shuffle slow on deque
In-Reply-To: <1224021781.11.0.882167475115.issue4123@psf.upfronthosting.co.za>
Message-ID: <1224021781.11.0.882167475115.issue4123@psf.upfronthosting.co.za>


New submission from paul rubin <phr at users.sourceforge.net>:

This is observed in Python 2.5.1, I haven't tried any later versions.

d = collections.deque(xrange(100000))
random.shuffle(d)

is quite slow.  Increasing the size to 200k, 300k, etc. shows that the
runtime increases quadratically or worse.  It's much faster to convert
the deque to a list, shuffle the list, and make a new deque from the
shuffled list.

----------
components: Library (Lib)
messages: 74773
nosy: phr
severity: normal
status: open
title: random.shuffle slow on deque
versions: Python 2.5

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

From report at bugs.python.org  Wed Oct 15 00:07:33 2008
From: report at bugs.python.org (Miki Tebeka)
Date: Tue, 14 Oct 2008 22:07:33 +0000
Subject: [New-bugs-announce] [issue4124] Patch for adding "default" to
	itemgetter and attrgetter
In-Reply-To: <1224022053.76.0.0750871741065.issue4124@psf.upfronthosting.co.za>
Message-ID: <1224022053.76.0.0750871741065.issue4124@psf.upfronthosting.co.za>


New submission from Miki Tebeka <miki.tebeka at gmail.com>:

This is a patch for adding "default" keyword to itemgetter and attrgetter.

This way you can do:
>>> f = itemgetter(0, default=1)
>>> f([])
1
>>> f= attrgetter("a", default="b")
>>> f(object())
'b'
>>>

I'm not sure about all the Py_INCREF I've placed there, someone with
more knowledge than me should review the code.

----------
components: Library (Lib)
files: getter.patch
keywords: patch
messages: 74774
nosy: tebeka
severity: normal
status: open
title: Patch for adding "default" to itemgetter and attrgetter
versions: Python 2.7
Added file: http://bugs.python.org/file11793/getter.patch

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

From report at bugs.python.org  Wed Oct 15 01:06:40 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Oct 2008 23:06:40 +0000
Subject: [New-bugs-announce] [issue4125] runtests.sh: use -bb flag of Python
In-Reply-To: <1224025600.55.0.798566736158.issue4125@psf.upfronthosting.co.za>
Message-ID: <1224025600.55.0.798566736158.issue4125@psf.upfronthosting.co.za>


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

The -bb (raise ByteWarning error) is useful for debugging and needed 
to improve bytes/unicode distinction in Python3. Here is a small patch 
to always run Python with -bb option.

The patch helps issue3988 test.

----------
files: runtests.patch
keywords: patch
messages: 74781
nosy: haypo
severity: normal
status: open
title: runtests.sh: use -bb flag of Python
versions: Python 3.0
Added file: http://bugs.python.org/file11797/runtests.patch

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

From report at bugs.python.org  Wed Oct 15 02:45:25 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Oct 2008 00:45:25 +0000
Subject: [New-bugs-announce] [issue4126] remove not decodable environment
	variables
In-Reply-To: <1224031525.89.0.11832939128.issue4126@psf.upfronthosting.co.za>
Message-ID: <1224031525.89.0.11832939128.issue4126@psf.upfronthosting.co.za>


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

Python3 skips environment variables which can not be parsed and 
decoded as unicode strings. But exec*() functions keep the original 
environment and so the child process environment is different than the 
Python environement (than os.environ).

I propose to remove these variables to avoid strange behaviours, but 
also to avoid possible security issues.

The attached patch is an implementation of this idea using a custom 
implementation of unsetenv(): _Py_unsetenv() argument is not the name 
of the variable but the raw variable including the value (eg. "a=b"). 
So it's also possible to drop truncated variables like "a" (no value 
nor "=" character).

This issue also affects Python2 since Python2 does also skip variable 
with no value but the variables still exist in memory (and so child 
process get them).

----------
components: Interpreter Core
files: unsetenv.patch
keywords: patch
messages: 74784
nosy: haypo
severity: normal
status: open
title: remove not decodable environment variables
type: security
versions: Python 3.0
Added file: http://bugs.python.org/file11799/unsetenv.patch

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

From report at bugs.python.org  Wed Oct 15 04:22:12 2008
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 15 Oct 2008 02:22:12 +0000
Subject: [New-bugs-announce] [issue4127] repr or reprlib?
In-Reply-To: <1224037332.88.0.79090862313.issue4127@psf.upfronthosting.co.za>
Message-ID: <1224037332.88.0.79090862313.issue4127@psf.upfronthosting.co.za>


New submission from David W. Lambert <lambertdw at corning.com>:

http://docs.python.org/dev/3.0/library/reprlib.html#module-reprlib
names the module reprlib.
However, the example at bottom of page uses:

http://docs.python.org/dev/3.0/library/reprlib.html#subclassing-repr-
objects

import repr

----------
assignee: georg.brandl
components: Documentation
messages: 74790
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: repr or reprlib?
versions: Python 3.0

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

From report at bugs.python.org  Wed Oct 15 12:03:17 2008
From: report at bugs.python.org (Fredrik Johansson)
Date: Wed, 15 Oct 2008 10:03:17 +0000
Subject: [New-bugs-announce] [issue4128] Performance regression in long
	division in 2.6
In-Reply-To: <1224064997.42.0.94461510007.issue4128@psf.upfronthosting.co.za>
Message-ID: <1224064997.42.0.94461510007.issue4128@psf.upfronthosting.co.za>


New submission from Fredrik Johansson <fredrik.johansson at gmail.com>:

On my laptop (Windows XP, 32-bit), long division is about 15% slower in
2.6 compared to 2.5. See the attached .txt for timings.

I noticed this when comparing the unit tests for mpmath
(http://code.google.com/p/mpmath/) under 2.5 and 2.6. It appears that
most tests run 10-20% faster under 2.6 (good work all Python
developers!), but the tests performing very high precision arithmetic
run noticeably slower.

>From some quick benchmarking, addition and multiplication are not the
culprits (they both actually seem to be quite a bit faster in 2.6). 

There could be other factors involved, but from what I've found out so
far, it is only division that has become slower in 2.6.

Division in Python 2.4 is also the same speed as 2.5.

----------
components: Interpreter Core
files: division_speed.txt
messages: 74798
nosy: fredrikj
severity: normal
status: open
title: Performance regression in long division in 2.6
versions: Python 2.6
Added file: http://bugs.python.org/file11804/division_speed.txt

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

From report at bugs.python.org  Wed Oct 15 13:16:16 2008
From: report at bugs.python.org (=?utf-8?q?Jakob_Schi=C3=B8tz?=)
Date: Wed, 15 Oct 2008 11:16:16 +0000
Subject: [New-bugs-announce] [issue4129] C/API documentation: request for
	documentation of change to Py_ssize_t* arguments.
In-Reply-To: <1224069376.75.0.412282464499.issue4129@psf.upfronthosting.co.za>
Message-ID: <1224069376.75.0.412282464499.issue4129@psf.upfronthosting.co.za>


New submission from Jakob Schi?tz <schiotz at fysik.dtu.dk>:

In general, the Python C/API manual is very careful to document when
changes have occurred in the API, this is really useful information when
writing portable extension modules to be used with different Python
versions.

However, there is a group of changes that are not documented.  In Python
2.5 the Py_ssize_t type was introduced, and a number of functions had
arguments changed from int to Py_ssize_t (a trivial change) or from int*
to Py_ssize_t*.  The latter is an incompatible change on 64-bit
platforms, as int and Py_ssize_t have different size, and this DOES
break extension modules on 64-bit platforms.  For example, the change in
int PySlice_GetIndices breaks the Scientific Python NetCDF module badly.

I suggest that a note is added to the documentation of all functions
taking a Py_ssize_t* argument stating that the type of the argument was
changed in Python 2.5.

Best regards

Jakob

----------
assignee: georg.brandl
components: Documentation
messages: 74801
nosy: georg.brandl, schiotz
severity: normal
status: open
title: C/API documentation: request for documentation of change to Py_ssize_t* arguments.
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Wed Oct 15 22:42:16 2008
From: report at bugs.python.org (jared jennings)
Date: Wed, 15 Oct 2008 20:42:16 +0000
Subject: [New-bugs-announce] [issue4130] Intel icc 9.1 does not support
	__int128_t used by ctypes
In-Reply-To: <1224103336.6.0.753228794094.issue4130@psf.upfronthosting.co.za>
Message-ID: <1224103336.6.0.753228794094.issue4130@psf.upfronthosting.co.za>


New submission from jared jennings <jared.jennings.ctr at eglin.af.mil>:

If the Intel 9.1 compilers are used to compile Python 2.6, the following
compiler error results:

/mnt/gpfs/usrpeople/jenninjl/Python-2.6-intel/Modules/_ctypes/libffi/src/x86/ffi64.c(43):
error: identifier "__int128_t" is undefined
    __int128_t sse[MAX_SSE_REGS];
    ^

Forum thread regarding lack of support for __int128_t in icc:
http://software.intel.com/en-us/forums/intel-c-compiler/topic/56652/

Intel C++ Compiler 10.1 for Linux, Intrinsic Reference:
http://softwarecommunity.intel.com/isn/downloads/softwareproducts/pdfs/347603.pdf

The Intrinsic Reference details (pp. 2-4) the __m128 type supported by
the Intel compiler, and restrictions on its use. (Note that the compiler
used was 9.1 but the documentation is from 10.1.)

----------
assignee: theller
components: ctypes
messages: 74813
nosy: jared.jennings, theller
severity: normal
status: open
title: Intel icc 9.1 does not support __int128_t used by ctypes
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Thu Oct 16 00:09:18 2008
From: report at bugs.python.org (John J Lee)
Date: Wed, 15 Oct 2008 22:09:18 +0000
Subject: [New-bugs-announce] [issue4131] Note that Firefox 3 does not write
	cookies.txt
In-Reply-To: <1224108558.64.0.703968829281.issue4131@psf.upfronthosting.co.za>
Message-ID: <1224108558.64.0.703968829281.issue4131@psf.upfronthosting.co.za>


New submission from John J Lee <jjlee at users.sourceforge.net>:

Just adds a note to the cookielib documentation to point out that
Firefox 3 no longer writes cookies.txt, the file format understood by
cookielib.MozillaCookieJar (firefox now maintains persistent cookie
state in an sqlite database).

----------
assignee: georg.brandl
components: Documentation
files: firefox3_cookies_txt.patch
keywords: patch
messages: 74823
nosy: georg.brandl, jjlee
severity: normal
status: open
title: Note that Firefox 3 does not write cookies.txt
Added file: http://bugs.python.org/file11806/firefox3_cookies_txt.patch

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

From report at bugs.python.org  Thu Oct 16 15:38:38 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Thu, 16 Oct 2008 13:38:38 +0000
Subject: [New-bugs-announce] [issue4132] LaTeX Error: Environment
	cmemberdescni undefined.
In-Reply-To: <1224164318.48.0.349785856959.issue4132@psf.upfronthosting.co.za>
Message-ID: <1224164318.48.0.349785856959.issue4132@psf.upfronthosting.co.za>


New submission from Winfried Plappert <Winfried.Plappert at gmx.de>:

When building latex documentation for the first time round, the make of
c-api fails with "! LaTeX Error: Environment cmemberdescni undefined.". 

A second make builds c-api and all other documents successfully.
However, The pdf document c-api.pdf is lacking the TOC and the Index.
All other PDFs have a TOC and an Index. 

I will include the a copy of the make output (typescript.org) - first
call to make.

----------
assignee: georg.brandl
components: Documentation
files: typescript.org
messages: 74836
nosy: georg.brandl, wplappert
severity: normal
status: open
title: LaTeX Error: Environment cmemberdescni undefined.
versions: Python 3.0
Added file: http://bugs.python.org/file11808/typescript.org

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

From report at bugs.python.org  Thu Oct 16 19:52:33 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 16 Oct 2008 17:52:33 +0000
Subject: [New-bugs-announce] [issue4133] -R fix for setup.py
In-Reply-To: <1224179553.69.0.502715553095.issue4133@psf.upfronthosting.co.za>
Message-ID: <1224179553.69.0.502715553095.issue4133@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

Please apply the attached one-line patch to setup.py.  This is a
backport from trunk/2.6.  I would check it in myself but I don't have
access to a read/write checkout at the moment.

Thanks,

Skip

----------
files: setup.py.diff
keywords: patch
messages: 74841
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: -R fix for setup.py
versions: Python 2.5.3
Added file: http://bugs.python.org/file11809/setup.py.diff

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

From report at bugs.python.org  Thu Oct 16 21:54:10 2008
From: report at bugs.python.org (David Turner)
Date: Thu, 16 Oct 2008 19:54:10 +0000
Subject: [New-bugs-announce] [issue4134] Peephole optimization: returning a
	temp
In-Reply-To: <1224186850.06.0.464686732743.issue4134@psf.upfronthosting.co.za>
Message-ID: <1224186850.06.0.464686732743.issue4134@psf.upfronthosting.co.za>


New submission from David Turner <novalis at novalis.org>:

This patch adds an optimization to the peephole optimizer for the common
case of:

def func(...):
   ...
   retval = ...
   return retval

Before the patch, the compiler would generate
STORE_FAST 3
LOAD_FAST 3
RETURN_VALUE

The store and load are pointless, as the local 3 (or whatever) is never
used again.  This patch makes the peephole optimizer optimize them out.

----------
components: None
files: peephole-return-temp.diff
keywords: patch
messages: 74853
nosy: novalis_dt
severity: normal
status: open
title: Peephole optimization: returning a temp
versions: Python 2.7
Added file: http://bugs.python.org/file11811/peephole-return-temp.diff

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

From report at bugs.python.org  Fri Oct 17 00:05:36 2008
From: report at bugs.python.org (Alex Coventry)
Date: Thu, 16 Oct 2008 22:05:36 +0000
Subject: [New-bugs-announce] [issue4135] help("modules ftp") fails due to
	test modules
In-Reply-To: <1224194736.44.0.337868576776.issue4135@psf.upfronthosting.co.za>
Message-ID: <1224194736.44.0.337868576776.issue4135@psf.upfronthosting.co.za>


New submission from Alex Coventry <throwaway at mit.edu>:

The modules test.bad_coding and test.badsyntax_pep3120.py cause the
command "help('modules ftp')" to fail with the errors 

LookupError: unknown encoding: uft-8

and

SyntaxError: Non-UTF-8 code starting with '\xf6' in file (null) on line
1, but no encoding declared; see http://python.org/dev/peps/pep-0263/
for details

respectively.  Removing these modules causes the help command to run
without error.  Not that that's a solution, just evidence for their
involvement in the problem.

----------
messages: 74871
nosy: throwaway
severity: normal
status: open
title: help("modules ftp") fails due to test modules

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

From report at bugs.python.org  Fri Oct 17 00:08:49 2008
From: report at bugs.python.org (Bob Ippolito)
Date: Thu, 16 Oct 2008 22:08:49 +0000
Subject: [New-bugs-announce] [issue4136] merge json library with simplejson
	2.0.3
In-Reply-To: <1224194929.7.0.263636117378.issue4136@psf.upfronthosting.co.za>
Message-ID: <1224194929.7.0.263636117378.issue4136@psf.upfronthosting.co.za>


New submission from Bob Ippolito <bob at redivi.com>:

simplejson 2.0.3 includes major performance enhancements (both in Python 
and C) and removes usage of the private sre functionality.

I will need some help with 3.0 since I am not well versed in the changes 
to the C API or Python code for that, but merging for 2.6.1 should be no 
big deal.

How should I go about this?

----------
assignee: bob.ippolito
components: Library (Lib)
messages: 74872
nosy: bob.ippolito
severity: normal
status: open
title: merge json library with simplejson 2.0.3
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Fri Oct 17 10:09:24 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 17 Oct 2008 08:09:24 +0000
Subject: [New-bugs-announce] [issue4137] update SIG web pages
In-Reply-To: <1224230964.55.0.983457546691.issue4137@psf.upfronthosting.co.za>
Message-ID: <1224230964.55.0.983457546691.issue4137@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Distutils SIG pages contain largely outdated information. 
http://www.python.org/community/sigs/current/distutils-sig/

It would be good to replace CVS instructions with SVN, add wiki link,
mark download page as "archived version" and add notice how newer
distutils are packaged into Python distribution. In general this content
seems a little bit stale and if it could be revised to a more up-to-date
status - that will surely increase the willingness to collaborate.

----------
components: Distutils
messages: 74899
nosy: techtonik
severity: normal
status: open
title: update SIG web pages
type: feature request

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

From report at bugs.python.org  Fri Oct 17 16:44:16 2008
From: report at bugs.python.org (Jianmin Xue)
Date: Fri, 17 Oct 2008 14:44:16 +0000
Subject: [New-bugs-announce] [issue4138] IDLE crashes in my Windows Vista
In-Reply-To: <1224254656.95.0.739612699268.issue4138@psf.upfronthosting.co.za>
Message-ID: <1224254656.95.0.739612699268.issue4138@psf.upfronthosting.co.za>


New submission from Jianmin Xue <heidan at gmail.com>:

I just downloaded Python 3.0 RC1 today from python.org and installed in 
my Windows Vista. However when I tried to run IDLE, it crashed with 
error message popping up. Screen-shot is attached.

Please let me know if any other information is needed.

----------
components: IDLE
files: py3_idle_crash_20081017.JPG
messages: 74914
nosy: xuejm1225
severity: normal
status: open
title: IDLE crashes in my Windows Vista
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file11817/py3_idle_crash_20081017.JPG

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

From report at bugs.python.org  Fri Oct 17 17:16:05 2008
From: report at bugs.python.org (thor222)
Date: Fri, 17 Oct 2008 15:16:05 +0000
Subject: [New-bugs-announce] [issue4139] Major error in cmath routines
In-Reply-To: <1224256565.24.0.380974841882.issue4139@psf.upfronthosting.co.za>
Message-ID: <1224256565.24.0.380974841882.issue4139@psf.upfronthosting.co.za>


New submission from thor222 <horizon at msbx.ws>:

There's an error in the way cmath computes the inverse sine, cosine and
tangent functions.

Example:
In 2.6: cmath.asin(2) returns 1.5707963267948966+1.3169578969248166j
However, the answer should be 1.5707963267948966-1.3169578969248166j
cmath.asin(2) returns the correct answer in 2.5.2.

Same problem exists in cmath.acos:
In 2.6: cmath.acos(2) = -1.3169578969248164j, but should be
1.3169578969248164j (once again, 2.5.2 returns the correct answer).

However, in 2.5.2 and 2.6, cmath.asin(1j) = 0.88137358701954283j, which
is correct.

----------
components: Library (Lib)
messages: 74917
nosy: thor222
severity: normal
status: open
title: Major error in cmath routines
versions: Python 2.6

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

From report at bugs.python.org  Fri Oct 17 17:45:33 2008
From: report at bugs.python.org (Jan-Klaas Kollhof)
Date: Fri, 17 Oct 2008 15:45:33 +0000
Subject: [New-bugs-announce] [issue4140] urllib2: request with digest auth
	through proxy fail
In-Reply-To: <1224258333.01.0.331002758914.issue4140@psf.upfronthosting.co.za>
Message-ID: <1224258333.01.0.331002758914.issue4140@psf.upfronthosting.co.za>


New submission from Jan-Klaas Kollhof <jan at kollhof.net>:

When using a proxy to request URLs that require Digest Auth,
a header similar to the following is sent to the server:

Authorization: Digest ... uri="http://example.org/foobar/spam" ...

The server then responded with:

HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/6.0


When not using a proxy, the header sent will look like:

Authorization: Digest ... uri="/foobar/spam" ...

and the server responded as expected with a 200 OK.

I don't know what is at fault here, urllib2 or IIS,
but patching the urllib2 to not use the full URL, when creating 
the Digest Auth. header, works.

When a proxy is being used by urllib2, the Request's get_selector() will
always return the full URL instead of just the selector.
The code that creates the Digest auth. header also uses the
get_selector() to set the "uri="-part in the auth header.
Making sure that the "uri="-part is not a full URL all seems to work.
See the patched urllib2.py attached.

I have only tested the fix against the server I had problems with,
and it seems to be working.

----------
components: Library (Lib)
files: urllib2.py
messages: 74918
nosy: jan.kollhof
severity: normal
status: open
title: urllib2: request with digest auth through proxy fail
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file11819/urllib2.py

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

From report at bugs.python.org  Fri Oct 17 20:27:58 2008
From: report at bugs.python.org (David Turner)
Date: Fri, 17 Oct 2008 18:27:58 +0000
Subject: [New-bugs-announce] [issue4141] Dis docs on CALL_FUNCTION a bit
	unclear
In-Reply-To: <1224268078.7.0.393708918822.issue4141@psf.upfronthosting.co.za>
Message-ID: <1224268078.7.0.393708918822.issue4141@psf.upfronthosting.co.za>


New submission from David Turner <novalis at novalis.org>:

This patch improves them.

----------
files: dis-doc-patch.diff
keywords: patch
messages: 74928
nosy: novalis_dt
severity: normal
status: open
title: Dis docs on CALL_FUNCTION a bit unclear
Added file: http://bugs.python.org/file11821/dis-doc-patch.diff

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

From report at bugs.python.org  Fri Oct 17 22:02:42 2008
From: report at bugs.python.org (Don Dwiggins)
Date: Fri, 17 Oct 2008 20:02:42 +0000
Subject: [New-bugs-announce] [issue4142] smtplib doesn't clear helo/ehlo
	flags on quit
In-Reply-To: <1224273762.79.0.0391835714009.issue4142@psf.upfronthosting.co.za>
Message-ID: <1224273762.79.0.0391835714009.issue4142@psf.upfronthosting.co.za>


New submission from Don Dwiggins <ddwiggins at advpubtech.com>:

Found on Windows, running Python 2.4.3.

SMTP.login() and SMTP.sendmail set one of the attributes ehlo_resp or
helo_resp to whatever the server responded (only if they're not already
set).

SMTP.quit() doesn't clear these attributes, so on the next connection,
the HELO/EHLO commands won't be sent; this will cause problems with some
servers (MDaemon in my case).  The fix is obvious, and a workaround
would be to clear the attributes in the instance before calling login
(or sendmail where authentication isn't needed).

----------
components: Library (Lib)
messages: 74935
nosy: dwig
severity: normal
status: open
title: smtplib doesn't clear helo/ehlo flags on quit
type: behavior
versions: Python 2.4

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

From report at bugs.python.org  Sat Oct 18 02:08:59 2008
From: report at bugs.python.org (Kevin Watters)
Date: Sat, 18 Oct 2008 00:08:59 +0000
Subject: [New-bugs-announce] [issue4143] ast.Node objects do not have column
	number information
In-Reply-To: <1224288539.13.0.569366728466.issue4143@psf.upfronthosting.co.za>
Message-ID: <1224288539.13.0.569366728466.issue4143@psf.upfronthosting.co.za>


New submission from Kevin Watters <kevinwatters at gmail.com>:

I see column number information in ast.c, but it's not accessible via 
the information by the Node objects returned by compiler.parse.

----------
components: Library (Lib)
messages: 74948
nosy: kevinwatters
severity: normal
status: open
title: ast.Node objects do not have column number information
type: behavior

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

From report at bugs.python.org  Sat Oct 18 22:35:34 2008
From: report at bugs.python.org (David W. Lambert)
Date: Sat, 18 Oct 2008 20:35:34 +0000
Subject: [New-bugs-announce] [issue4144] 3 tutorial documentation errors
In-Reply-To: <1224362134.12.0.593423230728.issue4144@psf.upfronthosting.co.za>
Message-ID: <1224362134.12.0.593423230728.issue4144@psf.upfronthosting.co.za>


New submission from David W. Lambert <lambertdw at corning.com>:

I ran doctests on the interactive session scripts from the tutorial.
Aside from finding a doctest enhancement---but there are already so 
many doctest issues tracked---I found these discrepancies using online 
tutorial and Python 3.0rc1 (r30rc1:66499, Oct 17 2008, 13:11:34)

-1--1--1--1--1--1--1--1--1--1--1--1--1--1--1--1--1--1--1--1--1--
"doesn't" --> "does not"   Trite documentation error

http://docs.python.org/dev/3.0/tutorial/introduction.html


Time to fix the doctest EXCEPTION_DETAIL

TypeError: 'str' object doesn't support ... (multiple occurrences)

"doesn't"  became  "does not"  in release 2.4.

-2--2--2--2--2--2--2--2--2--2--2--2--2--2--2--2--2--2--2--2--2--
"coercing to Unicode" or "convert to str"?

$ p3
Python 3.0rc1 (r30rc1:66499, Oct 17 2008, 13:11:34) 
[GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> '2'+3
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Can't convert 'int' object to str implicitly



http://docs.python.org/dev/3.0/tutorial/errors.html
>>> '2' + 2
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: coercing to Unicode: need string or buffer, int found


-3--3--3--3--3--3--3--3--3--3--3--3--3--3--3--3--3--3--3--3--3--
Integer division yields float

http://docs.python.org/dev/3.0/tutorial/errors.html

>>> divide(2, 1)    # 2.0 is correct
result is 2


-doctest---doctest---doctest---doctest---doctest---doctest--
doctest improvement possible

# execute this as sh code to exhibit problem
cat<<EOF>p.py
'''
    example from
     http://docs.python.org/dev/3.0/tutorial/introduction.html

    >>> 'doesn\'t'
    "doesn't"
'''

import doctest
doctest.testmod()
EOF
python p.py
# "\"Yes,\" he said." # likewise breaks doctest
# end of sh scripting

I suppose these issues are known.  Here's another that fails in 
doctest:
http://docs.python.org/dev/3.0/tutorial/stdlib.html

>>> re.findall(r'\bf[a-z]*', 'which foot or hand fell fastest')
['foot', 'fell', 'fastest']

----------
messages: 74958
nosy: LambertDW
severity: normal
status: open
title: 3 tutorial documentation errors
versions: Python 3.0

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

From report at bugs.python.org  Sun Oct 19 10:46:59 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Sun, 19 Oct 2008 08:46:59 +0000
Subject: [New-bugs-announce] [issue4145] tabulary entries in PDF
	documentation
In-Reply-To: <1224406019.73.0.627994354189.issue4145@psf.upfronthosting.co.za>
Message-ID: <1224406019.73.0.627994354189.issue4145@psf.upfronthosting.co.za>


New submission from Winfried Plappert <Winfried.Plappert at gmx.de>:

I wonder if the readabiliy of tables in PDFs can be improved. I take the
example of ABCs. The online documentation can be found at
http://docs.python.org/library/collections.html, the rst source is at
/Doc/library/collections.rst. I'll enclose two png files, which show the
table in HTML format and in PDF format. My PDF reader is Adobe Acrobat
Reader 8.1.2 (Ubuntu), but I also tried xpdf and "Evince Document Viewer
2.22.2". The result is the same that the coulumn width is somehow not
calculated correctly. Any ideas?

PS.: Since I can only upload one file at a time, there will be another
entry soon.

----------
assignee: georg.brandl
components: Documentation
files: Screenshot-collections ? High-performance container datatypes ? Python v2.6 documentation - Mozilla Firefox.png
messages: 74969
nosy: georg.brandl, wplappert
severity: normal
status: open
title: tabulary entries in PDF documentation
type: behavior
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11827/Screenshot-collections ? High-performance container datatypes ? Python v2.6 documentation - Mozilla Firefox.png

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

From report at bugs.python.org  Sun Oct 19 14:11:32 2008
From: report at bugs.python.org (Damien Miller)
Date: Sun, 19 Oct 2008 12:11:32 +0000
Subject: [New-bugs-announce] [issue4146] compilation of Modules/python.c
	fails on OpenBSD
In-Reply-To: <1224418292.85.0.510600214379.issue4146@psf.upfronthosting.co.za>
Message-ID: <1224418292.85.0.510600214379.issue4146@psf.upfronthosting.co.za>


New submission from Damien Miller <djmdjm at users.sourceforge.net>:

Compilation of 3.0rc1 Modules/python.c fails on OpenBSD with the
following error. The attached patch fixes things by explicitly casting
PyMem_Malloc's return value

c++ -pthread -c -fno-strict-aliasing -DNDEBUG -O2 -pipe 
-DTHREAD_STACK_SIZE=0x20000 -fPIC  -I. -IInclude -I./Include 
-DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c
Modules/python.c: In function `int main(int, char**)':
Modules/python.c:20: error: invalid conversion from `void*' to `wchar_t**'
Modules/python.c:22: error: invalid conversion from `void*' to `wchar_t**'
Modules/python.c:57: error: invalid conversion from `void*' to `wchar_t*'

----------
components: Interpreter Core
files: patch-Modules_python_c
messages: 74973
nosy: djmdjm
severity: normal
status: open
title: compilation of Modules/python.c fails on OpenBSD
type: compile error
versions: Python 3.0
Added file: http://bugs.python.org/file11830/patch-Modules_python_c

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

From report at bugs.python.org  Sun Oct 19 17:33:24 2008
From: report at bugs.python.org (Thomas Lee)
Date: Sun, 19 Oct 2008 15:33:24 +0000
Subject: [New-bugs-announce] [issue4147] xml.dom.minidom toprettyxml: omit
	whitespace for text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>


New submission from Thomas Lee <tom at vector-seven.com>:

For XML elements containing only text data, it would be nice if
toprettyxml could omit the whitespace it normally injects before & after
the text, e.g.

<person>
    <first-name>
        Bob
    </first-name>
</person>

Becomes:

<person>
    <first-name>Bob</first-name>
</person>

>From what I understand the handling of whitespace within XML elements is
application-defined, so I'm classifying this as a nice-to-have feature.
However it should be noted that in our particular case, the existing
behaviour caused a few problems with a third-party system which treated
whitespace as being significant.

----------
components: Library (Lib), XML
files: minidom-toprettyxml-01.patch
keywords: patch
messages: 74978
nosy: thomas.lee
severity: normal
status: open
title: xml.dom.minidom toprettyxml: omit whitespace for text-only elements
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file11832/minidom-toprettyxml-01.patch

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

From report at bugs.python.org  Mon Oct 20 06:27:57 2008
From: report at bugs.python.org (mshee)
Date: Mon, 20 Oct 2008 04:27:57 +0000
Subject: [New-bugs-announce] [issue4148] Using blender
In-Reply-To: <1224476876.93.0.671447627318.issue4148@psf.upfronthosting.co.za>
Message-ID: <1224476876.93.0.671447627318.issue4148@psf.upfronthosting.co.za>


New submission from mshee <msheethe at yahoo.com>:

When I start blender this shows in the cmd box. Why?

Compiled with python version 2.5.2
'import site' failed; use -v for traceback
checking for installed python... No installed python found.
only built-in modules are available.  some scripts may not run.
continuing happily.

----------
messages: 74987
nosy: mshee
severity: normal
status: open
title: Using blender
type: behavior

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

From report at bugs.python.org  Mon Oct 20 07:33:30 2008
From: report at bugs.python.org (Kandalintsev Alexandre)
Date: Mon, 20 Oct 2008 05:33:30 +0000
Subject: [New-bugs-announce] [issue4149] Py_BuildValue and "y" format unit
In-Reply-To: <1224480810.72.0.431948511218.issue4149@psf.upfronthosting.co.za>
Message-ID: <1224480810.72.0.431948511218.issue4149@psf.upfronthosting.co.za>


New submission from Kandalintsev Alexandre <bug_hunter at messir.net>:

Hello!

'y' format unit in Py_BuildValue undocumented. However it's described in 
PyArg_ParseTuple.

----------
assignee: georg.brandl
components: Documentation
messages: 74989
nosy: exe, georg.brandl
severity: normal
status: open
title: Py_BuildValue and "y" format unit
versions: Python 3.0

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

From report at bugs.python.org  Mon Oct 20 16:21:09 2008
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 20 Oct 2008 14:21:09 +0000
Subject: [New-bugs-announce] [issue4150] pdb "up" command fails in generator
	frames
In-Reply-To: <1224512469.54.0.977568708745.issue4150@psf.upfronthosting.co.za>
Message-ID: <1224512469.54.0.977568708745.issue4150@psf.upfronthosting.co.za>


New submission from Armin Rigo <arigo at users.sourceforge.net>:

pdb in post-mortem mode is not able to walk the stack through frames
that belong to generators.  The "up" command fails with the message
"Oldest frame", making it impossible to inspect the caller (or even know
what the caller was).

The attached patch fixes this.

----------
components: Library (Lib)
files: pdb-gen-frames.diff
keywords: patch, patch
messages: 74995
nosy: arigo
severity: normal
status: open
title: pdb "up" command fails in generator frames
type: behavior
versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.5.3, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file11836/pdb-gen-frames.diff

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

From report at bugs.python.org  Mon Oct 20 19:04:16 2008
From: report at bugs.python.org (Neil Schemenauer)
Date: Mon, 20 Oct 2008 17:04:16 +0000
Subject: [New-bugs-announce] [issue4151] Separate build dir broken
In-Reply-To: <1224522256.17.0.820973690454.issue4151@psf.upfronthosting.co.za>
Message-ID: <1224522256.17.0.820973690454.issue4151@psf.upfronthosting.co.za>


New submission from Neil Schemenauer <nas-pythonbugs at arctrix.com>:

Building in a separate directory got broken at some point.  The code is
hairy but it looks like the source of the problem was a lame
sysconfig.get_python_inc() function.  The attached patches fix things
and hopefully do not introduce any new bugs.

----------
components: Build
files: get_python_inc.patch
keywords: patch
messages: 74996
nosy: nas
severity: normal
status: open
title: Separate build dir broken
type: compile error
Added file: http://bugs.python.org/file11837/get_python_inc.patch

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

From report at bugs.python.org  Mon Oct 20 19:36:42 2008
From: report at bugs.python.org (Neil Schemenauer)
Date: Mon, 20 Oct 2008 17:36:42 +0000
Subject: [New-bugs-announce] [issue4152] ihooks module cannot handle
	absolute imports
In-Reply-To: <1224524202.33.0.257355673326.issue4152@psf.upfronthosting.co.za>
Message-ID: <1224524202.33.0.257355673326.issue4152@psf.upfronthosting.co.za>


New submission from Neil Schemenauer <nas-pythonbugs at arctrix.com>:

The ihooks module was updated when the absolute imports feature was
implemented.  At a minimum, I guess the import_module() methods in that
module would need to have "level=-1" keyword arguments added.  The only
library in the core that uses an absolute import is encodings/__init__.py.

----------
messages: 74998
nosy: nas
severity: normal
status: open
title: ihooks module cannot handle absolute imports
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Oct 20 20:04:00 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 20 Oct 2008 18:04:00 +0000
Subject: [New-bugs-announce] [issue4153] Unicode HOWTO up to date?
In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za>
Message-ID: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za>


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

The Unicode HOWTO begins with 
"Warning This HOWTO has not yet been updated for Python 3000?s string
object changes."

Without reading in detail, it appears it has been updated, at least
somewhat, and certainly more than I feared from the warning.
"The String Type
Since Python 3.0, the language features a str type that contain Unicode
characters"
and then a section "Converting to Bytes" and a later reference to
bytearrays.

So perhaps the warning is obsolete and should be removed.
Also, the revision history should have at least one more entry for the
3.0 updates, which certainly were entered since 2005

----------
assignee: georg.brandl
components: Documentation
messages: 74999
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Unicode HOWTO up to date?
versions: Python 3.0

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

From report at bugs.python.org  Mon Oct 20 21:07:13 2008
From: report at bugs.python.org (David W. Lambert)
Date: Mon, 20 Oct 2008 19:07:13 +0000
Subject: [New-bugs-announce] [issue4154] More doc trivia
In-Reply-To: <1224529633.22.0.844259184987.issue4154@psf.upfronthosting.co.za>
Message-ID: <1224529633.22.0.844259184987.issue4154@psf.upfronthosting.co.za>


New submission from David W. Lambert <lambertdw at corning.com>:

http://docs.python.org/dev/3.0/extending/extending.html

Given that the following paragraph tells us that there should be just
one non-static item in the module file,

struct PyModuleDef spammodule = 

should be

static struct PyModuleDef spammodule =


Possibly this persists into the Demos, that's not available to me right now.

Thanks!


(perusal---might wish to write

static void
no_bug


static void
bug

)

----------
assignee: georg.brandl
components: Documentation
messages: 75001
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: More doc trivia
versions: Python 3.0

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

From report at bugs.python.org  Mon Oct 20 22:08:01 2008
From: report at bugs.python.org (Petr)
Date: Mon, 20 Oct 2008 20:08:01 +0000
Subject: [New-bugs-announce] [issue4155] Wrong math calculation
In-Reply-To: <1224533281.89.0.753070831539.issue4155@psf.upfronthosting.co.za>
Message-ID: <1224533281.89.0.753070831539.issue4155@psf.upfronthosting.co.za>


New submission from Petr <bubersson at gmail.com>:

Hi, I've just tried some math functions in python3.0, but there's an 
wrong calculation (see the example). sin(pi/4) should be same as 
(2^.5)/2, but the result is different in last two digits. I don't know 
if it's an expected behaviour and this is my first posted issue. 

Python 3.0rc1 (r30rc1:66507, Sep 18 2008, 14:47:08) [MSC v.1500 32 bit 
(Intel)]
>>> from math import *
>>> sin(pi/4)==(2**0.5)/2
False

sin(pi/4)==0.70710678118654746
(2**0.5)/2==0.70710678118654757

bubersson

----------
messages: 75002
nosy: bubersson
severity: normal
status: open
title: Wrong math calculation
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Tue Oct 21 13:09:30 2008
From: report at bugs.python.org (Kent Johnson)
Date: Tue, 21 Oct 2008 11:09:30 +0000
Subject: [New-bugs-announce] [issue4156] Docs for BaseHandler.protocol_xxx
	methods are unclear
In-Reply-To: <1224587370.27.0.33419504535.issue4156@psf.upfronthosting.co.za>
Message-ID: <1224587370.27.0.33419504535.issue4156@psf.upfronthosting.co.za>


New submission from Kent Johnson <kent at kentsjohnson.com>:

In the docs for urllib2.BaseHandler previous to Python 2.6, the names of
the protocol_xxx() methods were spelled with 'protocol' in italics to
indicate that it is a placeholder; the actual method name is e.g.
http_opener().
http://www.python.org/doc/2.5.2/lib/base-handler-objects.html

In the Python 2.6 docs this typographic distinction has been lost
http://docs.python.org/library/urllib2.html#basehandler-objects
so it is not so clear that e.g. protocol_open() is not an actual method.

I suggest either restoring the italics or using a spelling such as
<protocol>_open() for the method names. If this is difficult then the
body of the descriptions should be rewritten to make it clear that the
'given protocol' is indicated by the name of the method.

----------
assignee: georg.brandl
components: Documentation
messages: 75023
nosy: georg.brandl, kjohnson
severity: normal
status: open
title: Docs for BaseHandler.protocol_xxx methods are unclear
versions: Python 2.6

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

From report at bugs.python.org  Tue Oct 21 15:37:40 2008
From: report at bugs.python.org (Feite Jaarsma)
Date: Tue, 21 Oct 2008 13:37:40 +0000
Subject: [New-bugs-announce] [issue4157] Tuple not callable in platform.py
In-Reply-To: <1224596260.97.0.062858509503.issue4157@psf.upfronthosting.co.za>
Message-ID: <1224596260.97.0.062858509503.issue4157@psf.upfronthosting.co.za>


New submission from Feite Jaarsma <f.jaarsma at innoteam.nl>:

The function 'def _test_parse_release_file()' has a for statement with 
a tuple as iter in it (examples of release file contents). This tuple 
is not a tuple. There is a ',' missing on every line (marked by '*'):

    for input, output in (
        # Examples of release file contents:
        ('SuSE Linux 9.3 (x86-64)', ('SuSE Linux ', '9.3', 'x86-64'))*
        ('SUSE LINUX 10.1 (X86-64)', ('SUSE LINUX ', '10.1', 'X86-64'))*
        ('SUSE LINUX 10.1 (i586)', ('SUSE LINUX ', '10.1', 'i586'))*
        ('Fedora Core release 5 (Bordeaux)', ('Fedora 
Core', '5', 'Bordeaux'))*
        ('Red Hat Linux release 8.0 (Psyche)', ('Red Hat 
Linux', '8.0', 'Psyche'))*
        ('Red Hat Linux release 9 (Shrike)', ('Red Hat 
Linux', '9', 'Shrike'))*
        ('Red Hat Enterprise Linux release 4 (Nahant)', ('Red Hat 
Enterprise Linux', '4', 'Nahant'))*
        ('CentOS release 4', ('CentOS', '4', None))*
        ('Rocks release 4.2.1 (Cydonia)', ('Rocks', '4.2.1', 'Cydonia'))
        ):

----------
components: Library (Lib)
messages: 75024
nosy: Feite
severity: normal
status: open
title: Tuple not callable in platform.py
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Tue Oct 21 16:36:27 2008
From: report at bugs.python.org (Jacques Lemire)
Date: Tue, 21 Oct 2008 14:36:27 +0000
Subject: [New-bugs-announce] [issue4158] import of sqlite3 fails
In-Reply-To: <1224599787.4.0.032538793853.issue4158@psf.upfronthosting.co.za>
Message-ID: <1224599787.4.0.032538793853.issue4158@psf.upfronthosting.co.za>


New submission from Jacques Lemire <jaclemire at gmail.com>:

This is a dump of the error:

Python 3.0rc1 (r30rc1:66499, Oct  6 2008, 12:44:02) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information. 

>>> import sqlite3
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/devp/altBIN/Python3r/lib/python3.0/sqlite3/__init__.py",
line 24, in <module>
    from sqlite3.dbapi2 import *
  File "/home/devp/altBIN/Python3r/lib/python3.0/sqlite3/dbapi2.py",
line 27, in <module>
    from _sqlite3 import *
ImportError: No module named _sqlite3

----------
components: Library (Lib)
messages: 75027
nosy: jlp
severity: normal
status: open
title: import of sqlite3 fails
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Tue Oct 21 16:48:05 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Tue, 21 Oct 2008 14:48:05 +0000
Subject: [New-bugs-announce] [issue4159] Table about Standard Encodings is
	cut off at the bottom - 35 entries missing
In-Reply-To: <1224600485.7.0.778638686943.issue4159@psf.upfronthosting.co.za>
Message-ID: <1224600485.7.0.778638686943.issue4159@psf.upfronthosting.co.za>


New submission from Winfried Plappert <Winfried.Plappert at gmx.de>:

library.pdf - Chapter 8.8.3 deals with Standard Encodings. There is a
long table which is massively overshooting the bottom of the page (page
110) in the PDF-A4 version. About 35 rows in the table get completely
lost - compared to the HTML version at
http://docs.python.org/library/codecs.html.

----------
assignee: georg.brandl
components: Documentation
messages: 75028
nosy: georg.brandl, wplappert
severity: normal
status: open
title: Table about Standard Encodings is cut off at the bottom - 35 entries missing
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Oct 21 17:06:34 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Tue, 21 Oct 2008 15:06:34 +0000
Subject: [New-bugs-announce] [issue4160] library.pdf - Section 12.13.2
	Connection Objects - example cut off at the right hand side
In-Reply-To: <1224601594.18.0.145893129918.issue4160@psf.upfronthosting.co.za>
Message-ID: <1224601594.18.0.145893129918.issue4160@psf.upfronthosting.co.za>


New submission from Winfried Plappert <Winfried.Plappert at gmx.de>:

in the Python 2.6 PDF-documentation, the example followong the
"text_factory is incomplete, because it is cut off at the right hand
side of the text. HTML-version: http://docs.python.org/library/sqlite3.html

I include the relevant line from the HTML-version:
cur.execute("select ?", ("this is latin1 and would normally create  
errors" + u"\xe4\xf6\xfc".encode("latin1"),)) . 

This line should probably be split, so the text cannot run off at the
right edge.

----------
assignee: georg.brandl
components: Documentation
messages: 75029
nosy: georg.brandl, wplappert
severity: normal
status: open
title: library.pdf - Section 12.13.2 Connection Objects - example cut off at the right hand side
versions: Python 2.6

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

From report at bugs.python.org  Tue Oct 21 17:19:19 2008
From: report at bugs.python.org (Zsolt Cserna)
Date: Tue, 21 Oct 2008 15:19:19 +0000
Subject: [New-bugs-announce] [issue4161] test_urllib fails with ValueError
In-Reply-To: <1224602359.77.0.0539565176483.issue4161@psf.upfronthosting.co.za>
Message-ID: <1224602359.77.0.0539565176483.issue4161@psf.upfronthosting.co.za>


New submission from Zsolt Cserna <zsolt.cserna at morganstanley.com>:

test_urllib regression test fails with ValueError on linux (kernel 2.4,
glibc 2.3):

test_urllib
test test_urllib failed -- Traceback (most recent call last):
  File "/tmp/x/Lib/test/test_urllib.py", line 112, in tearDown
    for k, v in self._saved_environ:
ValueError: too many values to unpack

I think the fix is trivial, but I've attached the patch.

If this bug has been already fixed, sorry for reporting it.

----------
files: test_urllib.patch
keywords: patch
messages: 75031
nosy: csernazs
severity: normal
status: open
title: test_urllib fails with ValueError
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11846/test_urllib.patch

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

From report at bugs.python.org  Tue Oct 21 17:47:01 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Tue, 21 Oct 2008 15:47:01 +0000
Subject: [New-bugs-announce] [issue4162] library.pdf - Section 17.6.4
	Examples - Multiprocessing - Formatting got lost
In-Reply-To: <1224604021.37.0.924796663652.issue4162@psf.upfronthosting.co.za>
Message-ID: <1224604021.37.0.924796663652.issue4162@psf.upfronthosting.co.za>


New submission from Winfried Plappert <Winfried.Plappert at gmx.de>:

There is a very long (last) example following the paragraph which starts
with the words: "An example/demo of how to use the managers.SyncManager,
Process and others ...". The formatting that this an example somehow got
lost and the PDF text becomes very sparse. I will attach a png file later.

The HTML documentation recognizes it as an example and formats it correctly.

----------
assignee: georg.brandl
components: Documentation
messages: 75033
nosy: georg.brandl, wplappert
severity: normal
status: open
title: library.pdf - Section 17.6.4 Examples - Multiprocessing - Formatting got lost
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Oct 21 22:05:23 2008
From: report at bugs.python.org (Sebastian Kirsche)
Date: Tue, 21 Oct 2008 20:05:23 +0000
Subject: [New-bugs-announce] [issue4163] textwrap wordsep_re Unicode
In-Reply-To: <1224619523.16.0.79700210606.issue4163@psf.upfronthosting.co.za>
Message-ID: <1224619523.16.0.79700210606.issue4163@psf.upfronthosting.co.za>


New submission from Sebastian Kirsche <sebastian.kirsche at gmail.com>:

The attached patch makes textwrap work with strings containing dashes 
and Unicode alphabetic characters. In addition, it fixes the test case 
for issue 1149508, which no longer failed after temporarily undoing the 
corresponding change.


Example 1:
    print textwrap.fill(u'Die Empf?nger-Auswahl', 13)

Output without patch: 
    Die Empf
    ?nger-Auswahl

With patch:
    Die
    Empf?nger-
    Auswahl


Example 2:
    print textwrap.fill(u'aa ??-??', 7)

Output without patch:
    aa
    ??-??

With patch:
    aa ??-
    ??

----------
components: Library (Lib)
files: textwrap-umlauts.patch
keywords: patch
messages: 75037
nosy: skirsche
severity: normal
status: open
title: textwrap wordsep_re Unicode
type: behavior
versions: Python 2.5, Python 2.5.3, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file11848/textwrap-umlauts.patch

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

From report at bugs.python.org  Tue Oct 21 22:10:25 2008
From: report at bugs.python.org (Felipe)
Date: Tue, 21 Oct 2008 20:10:25 +0000
Subject: [New-bugs-announce] [issue4164] String double quoted fatal problem
In-Reply-To: <1224619825.55.0.957590005213.issue4164@psf.upfronthosting.co.za>
Message-ID: <1224619825.55.0.957590005213.issue4164@psf.upfronthosting.co.za>


New submission from Felipe <cliffdover88 at hotmail.com>:

Hi

I have a problem with python 2.6, when i try to process strings with
triple-quoted string literal i get an error:

a='a''a' #1 double quoted Ok

a='a''''a' # 2 Ok

a= 'a''''''a' # 3 doble quoted -- SyntaxError: EOF while scanning
triple-quoted string literal

a= 'a''''''''a' # 4 ok

a='a''''''''''a' # 5 same error impair doble quoted

a='a''''''''''''a' # 6 Ok...............

a... #7 error..................

----------
components: Library (Lib)
messages: 75038
nosy: cliffdover88
severity: normal
status: open
title: String double quoted fatal problem
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Tue Oct 21 22:31:47 2008
From: report at bugs.python.org (Anand Patil)
Date: Tue, 21 Oct 2008 20:31:47 +0000
Subject: [New-bugs-announce] [issue4165] Failure building 64-bit Python on
	Leopard
In-Reply-To: <1224621107.94.0.119625965208.issue4165@psf.upfronthosting.co.za>
Message-ID: <1224621107.94.0.119625965208.issue4165@psf.upfronthosting.co.za>


New submission from Anand Patil <anand.prabhakar.patil at gmail.com>:

Configuring with 

sihpc03:Python-2.6 anand$ ./configure --with-framework-name=Python64 --
with-universal-archs=all --enable-framework --enable-
universalsdk=MACOSX_DEPLOYMENT_TARGET=10.5

on an Intel Mac Pro with the latest Leopard and Apple gcc 4.0, I get 
many errors like the following instructing me to report a bug. My 
config.log file is attached.

checking errno.h presence... yes
configure: WARNING: errno.h: present but cannot be compiled
configure: WARNING: errno.h:     check for missing prerequisite headers?
configure: WARNING: errno.h: see the Autoconf documentation
configure: WARNING: errno.h:     section "Present But Cannot Be 
Compiled"
configure: WARNING: errno.h: proceeding with the preprocessor's result
configure: WARNING: errno.h: in the future, the compiler will take 
precedence
configure: WARNING:     ## ---------------------------------------------
--- ##
configure: WARNING:     ## Report this to http://www.python.org/python-
bugs ##
configure: WARNING:     ## ---------------------------------------------
--- ##

----------
components: Macintosh
files: config.log
messages: 75039
nosy: anand
severity: normal
status: open
title: Failure building 64-bit Python on Leopard
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file11849/config.log

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

From report at bugs.python.org  Tue Oct 21 23:52:11 2008
From: report at bugs.python.org (Eric Firing)
Date: Tue, 21 Oct 2008 21:52:11 +0000
Subject: [New-bugs-announce] [issue4166] extra "\fi
Message-ID: <1224625931.36.0.439342755436.issue4166@psf.upfronthosting.co.za>


Changes by Eric Firing <efiring at hawaii.edu>:


----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
nosy: efiring, georg.brandl
severity: normal
status: open
title: extra "\fi

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

From report at bugs.python.org  Wed Oct 22 08:39:15 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Wed, 22 Oct 2008 06:39:15 +0000
Subject: [New-bugs-announce] [issue4167] Inline Markup :const: shows up in
	Documentation
In-Reply-To: <1224657555.02.0.872283376667.issue4167@psf.upfronthosting.co.za>
Message-ID: <1224657555.02.0.872283376667.issue4167@psf.upfronthosting.co.za>


New submission from Winfried Plappert <Winfried.Plappert at gmx.de>:

The Inline Markup :const: shows up in the final documentation. Example
can be found on http://docs.python.org/library/select.html :

kevent.fflags?

    Filter specific flags

    :const:`KQ_FILTER_READ` and :const:`KQ_FILTER_WRITE` filter flags
    Constant 	Meaning
    KQ_NOTE_LOWAT 	low water mark of a socket buffer

    :const:`KQ_FILTER_VNODE` filter flags

It also shows up in the equivalent PDF documentation. The underlying rst
file is library/select.rst, relevant part of source text follows:
   *:const:`KQ_FILTER_READ` and  :const:`KQ_FILTER_WRITE` filter flags*

  
+----------------------------+--------------------------------------------+
   | Constant                   | Meaning                              
     |
  
+============================+============================================+
   | :const:`KQ_NOTE_LOWAT`     | low water mark of a socket buffer    
     |
  
+----------------------------+--------------------------------------------+


   *:const:`KQ_FILTER_VNODE` filter flags*


There is one more occurrance of :const: in
http://docs.python.org/library/cookielib.html:
...
Cookie.is_expired([now=:const:`None`])?
    True if cookie ...

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 75063
nosy: georg.brandl, wplappert
severity: normal
status: open
title: Inline Markup :const: shows up in Documentation
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Oct 22 09:37:10 2008
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 22 Oct 2008 07:37:10 +0000
Subject: [New-bugs-announce] [issue4168] core dump exiting python
In-Reply-To: <1224661030.95.0.853599838513.issue4168@psf.upfronthosting.co.za>
Message-ID: <1224661030.95.0.853599838513.issue4168@psf.upfronthosting.co.za>


New submission from David W. Lambert <lambertdw at corning.com>:

I created in the python module gsl_fft a __del__ method to release 
workspace when the data size changes.  It is called upon exiting 
python, and gave errors without traceback.  So I registered it with 
atexit.  This caused core dump.  The attached tape archive has 
necessary modules, and file gdb.output.  The latter contains, I hope, 
enough information to reconstruct the command line and even to find 
the cause.  Additionally you'll need the gsl and gslcblas shared 
object libraries.

----------
components: Interpreter Core
files: coredump.tar
messages: 75064
nosy: LambertDW
severity: normal
status: open
title: core dump exiting python
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file11854/coredump.tar

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

From report at bugs.python.org  Wed Oct 22 10:07:47 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Wed, 22 Oct 2008 08:07:47 +0000
Subject: [New-bugs-announce] [issue4169] library/turtle.rst does not format
	properly in PDF mode
In-Reply-To: <1224662867.9.0.0428544955295.issue4169@psf.upfronthosting.co.za>
Message-ID: <1224662867.9.0.0428544955295.issue4169@psf.upfronthosting.co.za>


New submission from Winfried Plappert <Winfried.Plappert at gmx.de>:

library.pdf, Section 25.4.3 Methods of RawTurtle/Turtle and
corresponding functions does not format the :param xxx: keyword
properly. The HTML version at http://docs.python.org/library/turtle.html
looks like

turtle.fd(distance)?
    Parameters:	

        * distancea number (integer or float)

The formatting in HTML version is 100% correct, since it misses a space
between 'distance' and 'a', but at least is readable. The screenshot of
the PDF is not really readble. There is also the space missing between
the parameter and its description.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: turtle-pdf.png
messages: 75065
nosy: georg.brandl, wplappert
severity: normal
status: open
title: library/turtle.rst does not format properly in PDF mode
versions: Python 2.6
Added file: http://bugs.python.org/file11855/turtle-pdf.png

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

From report at bugs.python.org  Wed Oct 22 11:27:02 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Wed, 22 Oct 2008 09:27:02 +0000
Subject: [New-bugs-announce] [issue4170] segfault with defaultdict and pickle
In-Reply-To: <1224667622.54.0.802753290346.issue4170@psf.upfronthosting.co.za>
Message-ID: <1224667622.54.0.802753290346.issue4170@psf.upfronthosting.co.za>


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

It seems like there's a bug with defaultdict. This is segfaulting with 
the latest python 3.0 svn checkout:

import collections, pickle
d=collections.defaultdict(int)
d[1]
pickle.dumps(d)


It errors out with:

Assertion failed: (PyIter_Check(iter)), function PyIter_Next, file 
Objects/abstract.c, line 2751.
zsh: abort      /tmp/python/bin/python3.0 foo.py

----------
components: Library (Lib)
messages: 75073
nosy: erickt
severity: normal
status: open
title: segfault with defaultdict and pickle
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Wed Oct 22 13:37:24 2008
From: report at bugs.python.org (Dmitry Dvoinikov)
Date: Wed, 22 Oct 2008 11:37:24 +0000
Subject: [New-bugs-announce] [issue4171] SSL handshake fails after TCP
	connection in getpeername()
In-Reply-To: <1224675444.68.0.815389836032.issue4171@psf.upfronthosting.co.za>
Message-ID: <1224675444.68.0.815389836032.issue4171@psf.upfronthosting.co.za>


New submission from Dmitry Dvoinikov <dmitry at targeted.org>:

If I connect a TCP socket s using regular s.connect(), then wrap it
using ssl.wrap_socket(s) and call do_handshake on the resulting SSL
socket, handshake fails in ssl.py:320 with 

AttributeError: 'NoneType' object has no attribute 'do_handshake'

The problem is that when TCP socket is being wrapped in ssl.py:116, it
is not recognized as connected by a call to getpeername(), the exception
thrown in ssl.py:116 and silenced is this:

[Errno 10057] A request to send or receive data was disallowed because
the socket is not connected and (when sending on a datagram socket using
a sendto call) no address was supplied

This is awkward, because synchronous s.connect() has just returned
successfully. Even more weird, if I insert s.getpeername() between TCP
connect() and SSL do_handshake() the latter works fine.

Here is a working sample:

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

from socket import socket, AF_INET, SOCK_STREAM
from ssl import wrap_socket, PROTOCOL_TLSv1, CERT_NONE

def test_handshake(address, WORKAROUND):

    s = socket(AF_INET, SOCK_STREAM)
    s.settimeout(3.0)
    s.connect(address)

    if WORKAROUND:
        s.getpeername()

    ssl = wrap_socket(s, server_side = False,
                      ssl_version = PROTOCOL_TLSv1,
                      cert_reqs = CERT_NONE,
                      do_handshake_on_connect = False)
    ssl.do_handshake()

address = ("www.amazon.com", 443)

test_handshake(address, True) # with workaround
print("worked so far")
test_handshake(address, False)
print("but not here it didn't")

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

I'm using Python 3.0rc1 under Windows.

----------
components: Library (Lib)
messages: 75077
nosy: ddvoinikov
severity: normal
status: open
title: SSL handshake fails after TCP connection in getpeername()
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Wed Oct 22 15:17:55 2008
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Wed, 22 Oct 2008 13:17:55 +0000
Subject: [New-bugs-announce] [issue4172] distutils too picky about cygwin
	ld's version number
In-Reply-To: <1224681475.69.0.42802955697.issue4172@psf.upfronthosting.co.za>
Message-ID: <1224681475.69.0.42802955697.issue4172@psf.upfronthosting.co.za>


New submission from Zooko O'Whielacronx <zooko at zooko.com>:

When I build an extension module with cygwin g++ and "compiler=mingw32"
in my distutils config file, the build fails with:

  File
"c:\python25\lib\site-packages\setuptools-0.6c9.egg\setuptools\command\build_ext.py",
line 46, in run
    _build_ext.run(self)
  File "c:\Python25\lib\distutils\command\build_ext.py", line 264, in run
    force=self.force)
  File "c:\Python25\lib\distutils\ccompiler.py", line 1175, in new_compiler
    return klass (None, dry_run, force)
  File "c:\Python25\lib\distutils\cygwinccompiler.py", line 292, in __init__
    CygwinCCompiler.__init__ (self, verbose, dry_run, force)
  File "c:\Python25\lib\distutils\cygwinccompiler.py", line 84, in __init__
    get_versions()
  File "c:\Python25\lib\distutils\cygwinccompiler.py", line 424, in
get_versions
    ld_version = StrictVersion(result.group(1))
  File "c:\Python25\lib\distutils\version.py", line 40, in __init__
    self.parse(vstring)
  File "c:\Python25\lib\distutils\version.py", line 107, in parse
    raise ValueError, "invalid version number '%s'" % vstring
ValueError: invalid version number '2.18.50.20080625'


If I change "StrictVersion" to "LooseVersion" in cygwinccompiler.py,
then the build succeeds:

C:\playground\allmydata\tahoe\installtahoe\allmydata-tahoe-1.2.0-r3092-SUMO>diff
-u C:\Python25\Lib\distutils\cygwinccompiler.py
C:\Python25\Lib\distutils\cyg
winccompiler.py.new
--- C:\Python25\Lib\distutils\cygwinccompiler.py        2008-10-22
07:09:26.765625000 -0600
+++ C:\Python25\Lib\distutils\cygwinccompiler.py.new    2008-10-22
07:09:06.234375000 -0600
@@ -398,7 +398,7 @@
     """ Try to find out the versions of gcc, ld and dllwrap.
         If not possible it returns None for it.
     """
-    from distutils.version import StrictVersion
+    from distutils.version import LooseVersion, StrictVersion
     from distutils.spawn import find_executable
     import re

@@ -421,7 +421,7 @@
         out.close()
         result = re.search('(\d+\.\d+(\.\d+)*)',out_string)
         if result:
-            ld_version = StrictVersion(result.group(1))
+            ld_version = LooseVersion(result.group(1))
         else:
             ld_version = None
     else:
@@ -433,7 +433,7 @@
         out.close()
         result = re.search(' (\d+\.\d+(\.\d+)*)',out_string)
         if result:
-            dllwrap_version = StrictVersion(result.group(1))
+            dllwrap_version = LooseVersion(result.group(1))
         else:
             dllwrap_version = None

----------
components: Distutils
messages: 75079
nosy: zooko
severity: normal
status: open
title: distutils too picky about cygwin ld's version number
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Wed Oct 22 16:11:57 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Wed, 22 Oct 2008 14:11:57 +0000
Subject: [New-bugs-announce] [issue4173] PDF documentation: long verbatim
	lines are cut off at right hand side
In-Reply-To: <1224684717.3.0.110027961744.issue4173@psf.upfronthosting.co.za>
Message-ID: <1224684717.3.0.110027961744.issue4173@psf.upfronthosting.co.za>


New submission from Winfried Plappert <Winfried.Plappert at gmx.de>:

I seen this issue at various places, but I will quote from extending.pdf:
Chapter 3: 'Building C and C++ Extensions with distutils' shows two long
gcc commands.

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DMAJOR_VERSION=1
-DMINOR_VERSION=0 -I/usr/local/include -I/usr/local/include/python2.2 -c
demo.c -o build/temp.linux-i686-2.2/demo.o

gcc -shared build/temp.linux-i686-2.2/demo.o -L/usr/local/lib -ltcl83 -o
build/lib.linux-i686-2.2/demo.so

The HTML version at http://docs.python.org/extending/building.html uses
a slider to be able to see all the code, but the PDF-version does not
have this feature. Consequently, the text is chopped off at the right
hand side after the 98th character.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 75080
nosy: georg.brandl, wplappert
severity: normal
status: open
title: PDF documentation: long verbatim lines are cut off at right hand side
versions: Python 2.6

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

From report at bugs.python.org  Wed Oct 22 17:18:09 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 22 Oct 2008 15:18:09 +0000
Subject: [New-bugs-announce] [issue4174] Performance optimization for min()
	and max() over lists
In-Reply-To: <1224688689.45.0.882872543074.issue4174@psf.upfronthosting.co.za>
Message-ID: <1224688689.45.0.882872543074.issue4174@psf.upfronthosting.co.za>


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

This adds a special case for min() and max() when iterating over lists.
For simple lists of floats, the improvement is some 15% on a windows 
machine using release build (non pgo)

----------
components: Interpreter Core
files: minmax.patch
keywords: needs review, patch, patch
messages: 75082
nosy: krisvale
severity: normal
status: open
title: Performance optimization for min() and max() over lists
type: performance
versions: Python 2.5.3
Added file: http://bugs.python.org/file11857/minmax.patch

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

From report at bugs.python.org  Wed Oct 22 18:52:01 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 22 Oct 2008 16:52:01 +0000
Subject: [New-bugs-announce] [issue4175] Should Unix-only tty be present in
	Windows /Lib?
In-Reply-To: <1224694321.91.0.166298390618.issue4175@psf.upfronthosting.co.za>
Message-ID: <1224694321.91.0.166298390618.issue4175@psf.upfronthosting.co.za>


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

As long as tty is *nix only and does not have a msvcrt-based
implementation (which I presume is not exactly possible), I think it
should be absent, just like termios is.

>>> import tty
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    import tty
  File "C:\Programs\Python30\lib\tty.py", line 5, in <module>
    from termios import *
ImportError: No module named termios

Since this is expected, and not a bug, removing tty would give a
slightly shorter and clearer traceback ending with "No module named tty"

----------
components: Windows
messages: 75090
nosy: tjreedy
severity: normal
status: open
title: Should Unix-only tty be present in Windows /Lib?
versions: Python 3.0

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

From report at bugs.python.org  Wed Oct 22 20:17:38 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 22 Oct 2008 18:17:38 +0000
Subject: [New-bugs-announce] [issue4176] segfault with pickle if 4th or 5th
	item of tuple returned by __reduce__ is not an iterator
In-Reply-To: <1224699458.64.0.19589652139.issue4176@psf.upfronthosting.co.za>
Message-ID: <1224699458.64.0.19589652139.issue4176@psf.upfronthosting.co.za>


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

Following code crashes. (See issue4170)

trunk/Modules/cPickle.c (save() or save_reduce()) needs more checks of
returned value from __reduce__.

class C(object):
    def __reduce__(self):
        return C, (), None, None, [] # 5th item is not an iterator
class D(object):
    def __reduce__(self):
        return D, (), None, [], None # 4th item is not an iterator

import sys
if sys.version_info[0] == 3:
    import pickle
else:
    import cPickle as pickle
pickle.dumps(C()) # crash
pickle.dumps(D()) # crash

----------
components: Extension Modules
messages: 75094
nosy: ocean-city
severity: normal
status: open
title: segfault with pickle if 4th or 5th item of tuple returned by __reduce__ is not an iterator
type: crash
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Wed Oct 22 20:40:39 2008
From: report at bugs.python.org (=?utf-8?q?S=C3=A9rgio_Surkamp?=)
Date: Wed, 22 Oct 2008 18:40:39 +0000
Subject: [New-bugs-announce] [issue4177] Crash in MIMEText on FreeBSD
In-Reply-To: <1224700839.13.0.201844476382.issue4177@psf.upfronthosting.co.za>
Message-ID: <1224700839.13.0.201844476382.issue4177@psf.upfronthosting.co.za>


New submission from S?rgio Surkamp <sergio at gruposinternet.com.br>:

If you try to create a MIMEText object from a very large string (test
case include a 40Mbytes string), the program just eat all the CPU and
with high memory usage or raise a MemoryError. Sometimes it just
deadlocks when using _charset = "iso-8859-1".

Use the submited file and the script to test the case.

** On Linux its very slow, but work's ** - the problem occour on a
FreeBSD installation.

----------
components: Library (Lib), Unicode
files: test_MIMEText.tar.bz2
messages: 75097
nosy: surkamp
severity: normal
status: open
title: Crash in MIMEText on FreeBSD
type: behavior
versions: Python 2.5, Python 2.5.3
Added file: http://bugs.python.org/file11859/test_MIMEText.tar.bz2

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

From report at bugs.python.org  Wed Oct 22 21:51:23 2008
From: report at bugs.python.org (Michael Witten)
Date: Wed, 22 Oct 2008 19:51:23 +0000
Subject: [New-bugs-announce] [issue4178] codecs: Documentation Inconsistency
In-Reply-To: <1224705083.0.0.680712711599.issue4178@psf.upfronthosting.co.za>
Message-ID: <1224705083.0.0.680712711599.issue4178@psf.upfronthosting.co.za>


New submission from Michael Witten <mfwitten at mit.edu>:

CodecInfo objects are supposed to have 'encoder' and 'decoder' 
attributes as per http://www.python.org/doc/2.5.2/lib/module-codecs.html 
(naturally, this applies to 2.5.* as well). However, at least the 
CodecInfo object for 'string_escape' names these attributes 'encode' and 
'decode'.

>>> import codecs
>>> dir(codecs.lookup('string_escape'))
['__add__', '__class__', '__contains__', '__delattr__', '__dict__', 
'__doc__', '__eq__', '__ge__', '__getattribute__', '__getitem__', 
'__getnewargs__', '__getslice__', '__gt__', '__hash__', '__init__', 
'__iter__', '__le__', '__len__', '__lt__', '__module__', '__mul__', 
'__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', 
'__rmul__', '__setattr__', '__str__', 'decode', 'encode', 
'incrementaldecoder', 'incrementalencoder', 'name', 'streamreader', 
'streamwriter']

----------
components: Library (Lib)
messages: 75104
nosy: mfwitten
severity: normal
status: open
title: codecs: Documentation Inconsistency
versions: Python 2.6

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

From report at bugs.python.org  Wed Oct 22 23:07:34 2008
From: report at bugs.python.org (Daniel Clemente Laboreo)
Date: Wed, 22 Oct 2008 21:07:34 +0000
Subject: [New-bugs-announce] [issue4179] pdb: Allow the "list" command to
	return to the currently debugged line
In-Reply-To: <1224709654.06.0.420157536807.issue4179@psf.upfronthosting.co.za>
Message-ID: <1224709654.06.0.420157536807.issue4179@psf.upfronthosting.co.za>


New submission from Daniel Clemente Laboreo <dcl441-bugs at yahoo.com>:

The attached patch against today's trunk adds a new option to the "list"
("l") command of the debugger (pdb): "l ."

"l" starts showing the portion of code which contains the current line.
Further calls to "l" show the code below that. I found that I needed a
way to see the original line again. Manually I'd do "w" to see the
current line number and then "l 123" or so.
The new command "l ." brings you again to the code portion that was
shown first time, so this is automatic and faster.

I have absolutely no preference for the syntax "."; please change it if
something else would be more mnemonic or consistent.

Since this is my first patch; please complain if I do something wrong.

----------
components: Library (Lib)
files: pdb_list_refocus.patch
keywords: patch
messages: 75108
nosy: dclemente
severity: normal
status: open
title: pdb: Allow the "list" command to return to the currently debugged line
type: feature request
Added file: http://bugs.python.org/file11860/pdb_list_refocus.patch

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

From report at bugs.python.org  Wed Oct 22 23:49:32 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 22 Oct 2008 21:49:32 +0000
Subject: [New-bugs-announce] [issue4180] warnings.simplefilter("always")
	does not make warnings always show up
In-Reply-To: <1224712172.47.0.998538899646.issue4180@psf.upfronthosting.co.za>
Message-ID: <1224712172.47.0.998538899646.issue4180@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

If a warning is emitted then a filter with the "always" rule is added
then the is emitted again, it will not be shown the second time:

  exarkun at charm:~$ python
  Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) 
  [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import warnings
  >>> def f():
  ...     warnings.warn("foo")
  ... 
  >>> f()
  /home/exarkun/.pythonstartup.py:2: UserWarning: foo
  >>> warnings.simplefilter("always")
  >>> f()
  >>> 

The "always" filter is documented as "always print matching warnings"
which is contrary to this behavior.  Also, the string "always" strongly
implies that it will be shown the second time.

----------
messages: 75113
nosy: exarkun
severity: normal
status: open
title: warnings.simplefilter("always") does not make warnings always show up
versions: Python 2.4, Python 2.5, Python 2.6

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

From report at bugs.python.org  Wed Oct 22 23:52:18 2008
From: report at bugs.python.org (Pasha)
Date: Wed, 22 Oct 2008 21:52:18 +0000
Subject: [New-bugs-announce] [issue4181] Invalid Behavior When a Default
	Argument is a Dictionary.
In-Reply-To: <1224712338.02.0.509740184342.issue4181@psf.upfronthosting.co.za>
Message-ID: <1224712338.02.0.509740184342.issue4181@psf.upfronthosting.co.za>


New submission from Pasha <pavel.kamyshev at yale.edu>:

Whenever the default argument to a function is a dictionary, and the
function is called twice, then the function "remembers" the changes to
the dictionary. 

This means that any time that a default argument is set to a dictionary,
a list or any other built in data structure, it cannot be relied upon to
correctly do the right thing. 

I assume this is actually two issues:

1) The default arguments are not being garbage collected after the
function is done. You can check that by using a __del__ tracker 

2) the argument is at the same memory location at all times. 

I have seen this on Python 2.5.2, however its highly possible other
parts are affected as well.

----------
components: Interpreter Core
files: default_argument_dictionary_bug.py
messages: 75114
nosy: Pasha2009
severity: normal
status: open
title: Invalid Behavior When a Default Argument is a Dictionary.
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file11861/default_argument_dictionary_bug.py

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

From report at bugs.python.org  Wed Oct 22 23:55:26 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 22 Oct 2008 21:55:26 +0000
Subject: [New-bugs-announce] [issue4182] warnings.warn shows the wrong
	filename and line number for stacklevel of 0
In-Reply-To: <1224712526.35.0.138565894307.issue4182@psf.upfronthosting.co.za>
Message-ID: <1224712526.35.0.138565894307.issue4182@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

In Python 2.5 and earlier, passing stacklevel=0 to warnings.warn
resulted in a warning shown which pointed to warnings.py.  In Python
2.6, passing a stacklevel of 0 results in the warning shown pointing to
the file containing the call to warnings.warn.  To illustrate:

  exarkun at charm:~$ python
  Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) 
  [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import warnings
  >>> def f():
  ...     warnings.warn("foo", stacklevel=0)
  ... 
  >>> f()
  /usr/lib/python2.5/warnings.py:41: UserWarning: foo
    lineno = caller.f_lineno
  >>> 

as compared to

  exarkun at charm:~$ ~/Projects/python/branches/release26-maint/python 
  Python 2.6+ (trunk:66997, Oct 22 2008, 14:43:32) 
  [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import warnings
  >>> def f():
  ...     warnings.warn("foo", stacklevel=0)
  ... 
  >>> f()
  __main__:2: UserWarning: foo
  >>> 

This breaks code which assumes that stacklevel=0 will result in a
different file than stacklevel=1.

----------
messages: 75116
nosy: exarkun
severity: normal
status: open
title: warnings.warn shows the wrong filename and line number for stacklevel of 0
versions: Python 2.6

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

From report at bugs.python.org  Thu Oct 23 02:11:34 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 23 Oct 2008 00:11:34 +0000
Subject: [New-bugs-announce] [issue4183] test with pickle.HIGHEST_PROTOCOL
	missing
In-Reply-To: <1224720694.29.0.00411175636093.issue4183@psf.upfronthosting.co.za>
Message-ID: <1224720694.29.0.00411175636093.issue4183@psf.upfronthosting.co.za>


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

some tests use "for proto in range(pickle.HIGHEST_PROTOCOL)", but this
statement won't invoke proto == pickle.HIGHEST_PROTOCOL. Is this
intended? If not, I hope attached patch will fix this issue.

----------
components: Tests
files: test_with_HIGHEST_PROTOCOL_on_trunk.patch
keywords: patch
messages: 75125
nosy: ocean-city
severity: normal
status: open
title: test with pickle.HIGHEST_PROTOCOL missing
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file11863/test_with_HIGHEST_PROTOCOL_on_trunk.patch

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

From report at bugs.python.org  Thu Oct 23 03:17:14 2008
From: report at bugs.python.org (Richard Jones)
Date: Thu, 23 Oct 2008 01:17:14 +0000
Subject: [New-bugs-announce] [issue4184] Remove use of private attributes in
	smtpd
In-Reply-To: <1224724634.09.0.0444621109477.issue4184@psf.upfronthosting.co.za>
Message-ID: <1224724634.09.0.0444621109477.issue4184@psf.upfronthosting.co.za>


New submission from Richard Jones <richardjones at optushome.com.au>:

Executive summary of the patch:

The attached patch removes the use of __private attributes in the smtpd
module allowing it to be extensible without needing to use the
"_<classname>__<attributename>" hack.


Summary of the patch's changes:

1. removes the unused __conn and __addr attributes
2. renames __server to smtp_server
3. renames __lines to received_lines
4. renames __state to smtp_state
5. renames __greeting to seen_greeting, and alters the default to empty
string to match the anticipated data
6. renames __mailfrom to mailfrom
7. renames __date to received_data
8. renames __fqdn to fqdn
9. removes __peer and uses base class' addr attribute

The existing unit tests contained within test_smtplib pass. Additional
tests could be written if it's deemed necessary.

There is a chance this patch will break backward compatibility with
programs that use the private-variable-access hack. A more complex patch
could be written providing greater compatibility if it's deemed necessary.

----------
components: Library (Lib)
files: smtpd.py-patch
messages: 75132
nosy: richard
severity: normal
status: open
title: Remove use of private attributes in smtpd
versions: Python 2.6
Added file: http://bugs.python.org/file11867/smtpd.py-patch

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

From report at bugs.python.org  Thu Oct 23 05:55:29 2008
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 23 Oct 2008 03:55:29 +0000
Subject: [New-bugs-announce] [issue4185] re module treats raw strings as
	normal strings
In-Reply-To: <1224734129.35.0.170011642262.issue4185@psf.upfronthosting.co.za>
Message-ID: <1224734129.35.0.170011642262.issue4185@psf.upfronthosting.co.za>


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

The re module seems to treat the raw strings as normal strings:
>>> 'a1a1a'.replace('1', r'\n') == re.sub('1', r'\n', 'a1a1a')
False
>>> 'a1a1a'.replace('1', '\n') == re.sub('1', r'\n', 'a1a1a')
True
In the first line str.replace and re.sub should perform exactly the same
operation and return the same result but re.sub replaces the 1s with
newlines, instead of a literal '\' and 'n'.
The second line should evaluate to False but re.sub replaces again the
1s with newlines so the result is equal to the LHS.

>>> re.search(r'\n', 'a\na')
<_sre.SRE_Match object at 0x00A81BF0>
>>> r'\n' in 'a\na'
False
Searching a r'\n' in a string that contains a newline also return a
result even if r'\n' is not in 'a\na'.

Tested with Py2.5 on Linux and Py2.4/2.6 on win.
The problem could be related to http://bugs.python.org/msg71861 
Attached there is a txt file with more examples.

----------
components: Library (Lib), Regular Expressions
files: raw-strings-with-re.txt
messages: 75133
nosy: ezio.melotti
severity: normal
status: open
title: re module treats raw strings as normal strings
type: behavior
versions: Python 2.4, Python 2.5, Python 2.5.3, Python 2.6
Added file: http://bugs.python.org/file11868/raw-strings-with-re.txt

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

From report at bugs.python.org  Thu Oct 23 11:13:31 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 23 Oct 2008 09:13:31 +0000
Subject: [New-bugs-announce] [issue4186] type() doesn't accept bases and
	dict keyword arguments
In-Reply-To: <1224753211.57.0.0760272194538.issue4186@psf.upfronthosting.co.za>
Message-ID: <1224753211.57.0.0760272194538.issue4186@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

According to bug 1683368, Python 3.0's object.__init__() no longer
accepts arbitrary keyword arguments.  What's new in Python 2.6 says the
same thing has been implemented in 2.6.  However, type() no longer
accepts /any/ keyword arguments, including the documented 'bases' and
'dict' keyword arguments.  This seems to be a bug.

It's not clear to me we no longer want to support type()'s documented
keyword arguments, but even if we do, we should deprecate them in 2.6
and remove them in 2.7.

The work around is fairly easy (pass positional args), but this will
still break existing code.

----------
components: Interpreter Core
messages: 75136
nosy: barry
priority: critical
severity: normal
status: open
title: type() doesn't accept bases and dict keyword arguments
versions: Python 2.6

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

From report at bugs.python.org  Thu Oct 23 15:49:59 2008
From: report at bugs.python.org (ldehkire)
Date: Thu, 23 Oct 2008 13:49:59 +0000
Subject: [New-bugs-announce] [issue4187] IDLE will not start.
In-Reply-To: <1224769799.89.0.110576090297.issue4187@psf.upfronthosting.co.za>
Message-ID: <1224769799.89.0.110576090297.issue4187@psf.upfronthosting.co.za>


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

IDLE will not start.  I have installed python via the
python-2.6-macosx.dmg image found on http://www.python.org/download/.  I
didn't find any resolutions in bugs.python.org, but did note that you
are having some trouble with tk (as discussed in other bugs).  I haven't
tried much to troubleshoot the issue yet other than note that the 2.5
version of IDLE does start.  Below is some info on the problem:

I see the following in my logs every time I try and start IDLE:
Oct 23 07:15:03 kaos [0x0-0x30030].org.python.IDLE[333]: Traceback (most
recent call last):
Oct 23 07:15:03 kaos [0x0-0x30030].org.python.IDLE[333]:   File
"/Applications/Python 2.6/IDLE.app/Contents/Resources/idlemain.py", line
6, in <module>
Oct 23 07:15:03 kaos [0x0-0x30030].org.python.IDLE[333]:     from
idlelib.PyShell import main
Oct 23 07:15:03 kaos [0x0-0x30030].org.python.IDLE[333]:   File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/idlelib/PyShell.py",
line 14, in <module>
Oct 23 07:15:03 kaos [0x0-0x30030].org.python.IDLE[333]:     import
macosxSupport
Oct 23 07:15:03 kaos [0x0-0x30030].org.python.IDLE[333]:   File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/idlelib/macosxSupport.py",
line 6, in <module>
Oct 23 07:15:03 kaos [0x0-0x30030].org.python.IDLE[333]:     import Tkinter
Oct 23 07:15:03 kaos [0x0-0x30030].org.python.IDLE[333]:   File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-tk/Tkinter.py",
line 39, in <module>
Oct 23 07:15:03 kaos [0x0-0x30030].org.python.IDLE[333]:     import
_tkinter # If this fails your Python may not be configured for Tk
Oct 23 07:15:03 kaos [0x0-0x30030].org.python.IDLE[333]: ImportError:
dlopen(/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_tkinter.so,
2): Library not loaded: /Library/Frameworks/Tcl.framework/Versions/8.5/Tcl
Oct 23 07:15:03 kaos [0x0-0x30030].org.python.IDLE[333]:   Referenced
from:
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_tkinter.so
Oct 23 07:15:03 kaos [0x0-0x30030].org.python.IDLE[333]:   Reason: image
not found
Oct 23 07:15:03 kaos com.apple.launchd[87]
([0x0-0x30030].org.python.IDLE[333]): Exited with exit code: 1

I looked, and found the following in the referenced directory:
-rwxrwxr-x  1 root  admin   225936 Oct  1 17:49 _tkinter.so

System info: 
MacBook Pro, Intel Core 2 Duo, 2 GB RAM, Mac OS X 10.5.5

----------
components: IDLE
messages: 75144
nosy: ldehkire
severity: normal
status: open
title: IDLE will not start.
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Thu Oct 23 22:28:23 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 23 Oct 2008 20:28:23 +0000
Subject: [New-bugs-announce] [issue4188] Lib/threading.py causes infinite
	recursion when running as verbose
In-Reply-To: <1224793703.28.0.169476277835.issue4188@psf.upfronthosting.co.za>
Message-ID: <1224793703.28.0.169476277835.issue4188@psf.upfronthosting.co.za>


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

Lib/threading.py gets into infinite recursion while testing (or using)
it with verbose set. This didn't happen before because Thread.__started
didn't use to be an Event, but now it is.

Typical situation:
_DummyThread calls _Thread__started.set, which calls
__started.__cond.notify_all(), which calls __cond.notify(). If there are
no waiters, it calls _Verbose._note, which calls currentThread, but if
there is no current thread _DummyThread is called, which calls
_Thread__started.set ...

----------
components: Library (Lib)
files: move_Thread__started.diff
keywords: patch
messages: 75149
nosy: gpolo
severity: normal
status: open
title: Lib/threading.py causes infinite recursion when running as verbose
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file11869/move_Thread__started.diff

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

From report at bugs.python.org  Thu Oct 23 23:07:13 2008
From: report at bugs.python.org (Jeffrey Harris)
Date: Thu, 23 Oct 2008 21:07:13 +0000
Subject: [New-bugs-announce] [issue4189] Tilde compression isn't applied in
	TOC
In-Reply-To: <1224796033.71.0.204844693671.issue4189@psf.upfronthosting.co.za>
Message-ID: <1224796033.71.0.204844693671.issue4189@psf.upfronthosting.co.za>


New submission from Jeffrey Harris <jeffrey at skyhouseconsulting.com>:

When Sphinx builds TOC nodes, it isn't applying the tilde rule (use only
the last dotted name).  For example compare the heading for:

http://people.osafoundation.org/~jeffrey/rearch_documentation/Chandler-Platform/Core.html#the-dashboardentry-class

to the table of contents at the top of the page, or to the node's link on:

http://people.osafoundation.org/~jeffrey/rearch_documentation/Chandler-Platform/README.html

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 75150
nosy: georg.brandl, jeffreyharris
severity: normal
status: open
title: Tilde compression isn't applied in TOC
type: behavior

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

From report at bugs.python.org  Fri Oct 24 01:23:34 2008
From: report at bugs.python.org (Andrew Shaw)
Date: Thu, 23 Oct 2008 23:23:34 +0000
Subject: [New-bugs-announce] [issue4190] IDLE (2.6) doesn't stay open
In-Reply-To: <1224804214.95.0.696961059399.issue4190@psf.upfronthosting.co.za>
Message-ID: <1224804214.95.0.696961059399.issue4190@psf.upfronthosting.co.za>


New submission from Andrew Shaw <andrew.t.shaw7 at gmail.com>:

Downloaded Python 2.6 for Mac OS X.  When launching IDLE.app, it puts the 
icon on the dock for a second, then disappears.  Nothing else ever 
happens.  X11 does not open either.

----------
components: IDLE
messages: 75151
nosy: andrew.t.shaw7
severity: normal
status: open
title: IDLE (2.6) doesn't stay open
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Fri Oct 24 09:50:33 2008
From: report at bugs.python.org (monk.e.boy)
Date: Fri, 24 Oct 2008 07:50:33 +0000
Subject: [New-bugs-announce] [issue4191] urlparse normalize URL path
In-Reply-To: <1224834633.73.0.450098014303.issue4191@psf.upfronthosting.co.za>
Message-ID: <1224834633.73.0.450098014303.issue4191@psf.upfronthosting.co.za>


New submission from monk.e.boy <johng at neutralize.com>:

Hi,

  The way urljoin works is a bit funky, equivalent paths do not get
cleaned in a consistent way:


import urlparse
import posixpath

print urlparse.urljoin('http://www.example.com', '///')
print urlparse.urljoin('http://www.example.com/', '///')
print urlparse.urljoin('http://www.example.com///', '///')
print urlparse.urljoin('http://www.example.com///', '//')
print urlparse.urljoin('http://www.example.com///', '/')
print urlparse.urljoin('http://www.example.com///', '')
print
# the above should reduce down to:
print posixpath.normpath('///')
print
print urlparse.urljoin('http://www.example.com///', '.')
print urlparse.urljoin('http://www.example.com///', '/.')
print urlparse.urljoin('http://www.example.com///', './')
print urlparse.urljoin('http://www.example.com///', '/.')
print
print posixpath.normpath('/.')
print
print urlparse.urljoin('http://www.example.com///', '..')
print urlparse.urljoin('http://www.example.com', '/a/../a/')
print urlparse.urljoin('http://www.example.com', '../')
print urlparse.urljoin('http://www.example.com', 'a/../a/')
print urlparse.urljoin('http://www.example.com', 'a/../a/./')
print urlparse.urljoin('http://www.example.com/a/../a/', '../a/./../a/')
print urlparse.urljoin('http://www.example.com/a/../a/', '/../a/./../a/')

The results of the above code are:

http://www.example.com/
http://www.example.com/
http://www.example.com/
http://www.example.com///
http://www.example.com/
http://www.example.com///

/

http://www.example.com///
http://www.example.com/.
http://www.example.com///
http://www.example.com/.

/

http://www.example.com
http://www.example.com/.
http://www.example.com
http://www.example.com/.

http://www.example.com//
http://www.example.com/a/../a/
http://www.example.com/../
http://www.example.com/a/
http://www.example.com/a/
http://www.example.com/a/
http://www.example.com/../a/./../a/

Sometimes the path is cleaned, sometimes it is not. When it is cleaned,
the cleaning process is not perfect.

The bit of code that is causing problems is commented:

  # XXX The stuff below is bogus in various ways...

If I may be so bold, I would like to see this URL cleaning code stripped
from urljoin.

A new method/function could be added that cleans a URL. It could have a
'mimic browser' option, because a browser *will* follow URLs like:
http://example.com/../../../ (see this non-bug
http://bugs.python.org/issue2583 )

The URL cleaner could use some of the code from "posixpath". Shorter
URLs would be preferred over longer (e.g: http://example.com preferred
to http://example.com/ )

Thanks,

monk.e.boy

----------
messages: 75154
nosy: monk.e.boy
severity: normal
status: open
title: urlparse normalize URL path
versions: Python 2.6

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

From report at bugs.python.org  Fri Oct 24 17:23:20 2008
From: report at bugs.python.org (Pascal Chambon)
Date: Fri, 24 Oct 2008 15:23:20 +0000
Subject: [New-bugs-announce] [issue4192] Subprocess error with I/O
	redirection to Pipes
In-Reply-To: <1224861800.81.0.399738040895.issue4192@psf.upfronthosting.co.za>
Message-ID: <1224861800.81.0.399738040895.issue4192@psf.upfronthosting.co.za>


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

I've created on my desktop a file flooder.py containing just the following:
##################
import sys, os

progress=open(r"C:\Users\v-pascha\Desktop\STDERR.txt","w")

for i in range(101):
   print str(i)*20
   progress.write( str(i)+"\n" )
   
progress.close()
##################


and a file receiver.py containing just :


################
import sys, os, subprocess

#os.system("pause")
subprocess.Popen(r"python
C:\Users\v-pascha\Desktop\flooder.py",stdin=subprocess.PIPE,stdout=subprocess.PIPE)
#,stdin=subprocess.PIPE,stdout=subprocess.PIPE
#os.system("pause")

#####################

And when I launch receiver.py, I get a crash with that (not explicit)
message :
"close failed in file object destructor:
Error in sys.excepthook:

Original exception was:"

The crash doesn't happen if I don't redirect the stdout and stdin of the
child process. So it seems something weird happens when subprocess tries
to redirect the child's I/O to the PIPEs...

----------
components: Library (Lib), Windows
messages: 75169
nosy: pakal
severity: normal
status: open
title: Subprocess error with I/O redirection to Pipes
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Fri Oct 24 18:54:37 2008
From: report at bugs.python.org (David W. Lambert)
Date: Fri, 24 Oct 2008 16:54:37 +0000
Subject: [New-bugs-announce] [issue4193] Multiprocessing example
In-Reply-To: <1224867277.0.0.802822144442.issue4193@psf.upfronthosting.co.za>
Message-ID: <1224867277.0.0.802822144442.issue4193@psf.upfronthosting.co.za>


New submission from David W. Lambert <lambertdw at corning.com>:

http://docs.python.org/dev/3.0/library/multiprocessing.html

I'm sure the examples have been thoughtfully contrived.  Still, this 
seems instructive without adding much complexity.  I'd change the 
first "trivial example" to

###########################################
from multiprocessing import Process
import os

def info(title):
    print(title)
    print('module name:',__name__)
    print('parent process:',os.getppid())
    print('process id:',os.getpid())
    print()

def f(name):
    info('function f')
    print('hello', name)

if __name__ == '__main__':
    info('main line')
    p = Process(target=f, args=('bob',))
    p.start()
    p.join()
###########################################

with output similar to


main line
module name: __main__
parent process: 12926
process id: 17002

function f
module name: __main__
parent process: 17002
process id: 17004

hello bob

----------
assignee: georg.brandl
components: Documentation
messages: 75172
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: Multiprocessing example
type: feature request
versions: Python 3.0

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

From report at bugs.python.org  Fri Oct 24 19:54:42 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 24 Oct 2008 17:54:42 +0000
Subject: [New-bugs-announce] [issue4194] Miserable subprocess.Popen
	performance
In-Reply-To: <18690.3034.472764.227788@montanaro-dyndns-org.local>
Message-ID: <18690.3034.472764.227788@montanaro-dyndns-org.local>


New submission from Skip Montanaro <skip at pobox.com>:

I noticed a colleague at work today checked in a change to his code to
switch back from subprocess.Popen to os.popen.  I asked him about it and he
reported that subprocess.Popen was about 10x slower than os.popen.  I asked
him for a simple test case, which is attached.  Here are my results with
Python 2.4 through 2.7 (aka CVS HEAD):

    tmp% python2.4 popentest.py 
    time with os.popen :  0.09
    time with subprocess.Popen :  2.27
    tmp% python2.5 popentest.py 
    time with os.popen :  0.03
    time with subprocess.Popen :  1.52
    tmp% python2.6 popentest.py 
    time with os.popen :  0.038824
    time with subprocess.Popen :  1.517056
    tmp% python2.7 popentest.py 
    time with os.popen :  0.033746
    time with subprocess.Popen :  1.512331

These times are on my Mac laptop, all writing to the local disk.  It seems
there was a bit of improvement in the 2.5 release but that it is still
miserably slow when compared with os.popen.

His original test used time.clock() as the timer.  I changed to time.time()
but got essentially the same result.

Skip

----------
files: popentest.py
messages: 75173
nosy: skip.montanaro
severity: normal
status: open
title: Miserable subprocess.Popen performance
Added file: http://bugs.python.org/file11871/popentest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4194>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: popentest.py
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20081024/1d6202ba/attachment.txt>

From report at bugs.python.org  Fri Oct 24 20:44:59 2008
From: report at bugs.python.org (vajda)
Date: Fri, 24 Oct 2008 18:44:59 +0000
Subject: [New-bugs-announce] [issue4195] Regression for executing packages
In-Reply-To: <1224873899.8.0.177595218059.issue4195@psf.upfronthosting.co.za>
Message-ID: <1224873899.8.0.177595218059.issue4195@psf.upfronthosting.co.za>


New submission from vajda <vajda at osafoundation.org>:

Copy of #2751.

Having discussed this with Nick a bit more over email, he suggested that
package execution could actually be properly supported by looking for a
__main__ module inside the package and executing it instead. This is
consistent with the way .zip archives are executed and would neatly
resolve this problem. I attached a simple patch implementing this.

Nick also said that fixing this might be considered a new feature and
might have to wait until 2.7. Given that this worked on Python 2.5,
albeit unintentionally, I'd argue that this is closer to a fix of a
somewhat buggy Python 2.5 feature than a new feature in 2.6.

----------
components: Interpreter Core
files: patch.2751
messages: 75175
nosy: benjamin.peterson, ncoghlan, vajda
severity: normal
status: open
title: Regression for executing packages
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11876/patch.2751

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

From report at bugs.python.org  Fri Oct 24 20:47:36 2008
From: report at bugs.python.org (David W. Lambert)
Date: Fri, 24 Oct 2008 18:47:36 +0000
Subject: [New-bugs-announce] [issue4196] library documentation errors
In-Reply-To: <1224874056.75.0.148579483822.issue4196@psf.upfronthosting.co.za>
Message-ID: <1224874056.75.0.148579483822.issue4196@psf.upfronthosting.co.za>


New submission from David W. Lambert <lambertdw at corning.com>:

4 problems noted here.

Thanks, Dave.

1,2---problems 1 & 2 concern py<3k references:

http://docs.python.org/dev/3.0/library/multiprocessing.html


1) "apply(func[, args[, kwds]])
Equivalent of the apply() builtin function. It blocks till the result 
is ready."

Of course there isn't any longer an "apply" builtin.


2) "imap(func, iterable[, chunksize])
An equivalent of itertools.imap()."

Likewise, there's no "itertools.imap".  Perhaps use 
itertools.some_sort_of_truncating_wrapper(itertools.zip_longest(...))?


This brings us to the itertools problem.


3,4---problems 3 & 4 concern "izip" in: 

http://docs.python.org/dev/3.0/library/itertools.html

This mentions "izip_longest()", but there isn't an "izip_anything" in 
py3k itertools.  Searching the page for the string "izip" produces two 
separate occurrences.  izip_longest -> zip_longest but I don't know 
how to fix the other one.

----------
assignee: georg.brandl
components: Documentation
messages: 75176
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: library documentation errors
versions: Python 3.0

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

From report at bugs.python.org  Fri Oct 24 23:59:37 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 24 Oct 2008 21:59:37 +0000
Subject: [New-bugs-announce] [issue4197] Doctest module does not work with
	zipped packages
In-Reply-To: <1224885577.37.0.0757752980748.issue4197@psf.upfronthosting.co.za>
Message-ID: <1224885577.37.0.0757752980748.issue4197@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

With attached teestmodule.zip and svn revision 67006,

$ ./python.exe testmodule.zip 
Traceback (most recent call last):
  File "/Users/sasha/Work/python-svn/trunk/Lib/runpy.py", line 121, in 
_run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/Users/sasha/Work/python-svn/trunk/Lib/runpy.py", line 34, in 
_run_code
    exec code in run_globals
  File "testmodule.zip/__main__.py", line 7, in <module>
  File "/Users/sasha/Work/python-svn/trunk/Lib/doctest.py", line 1817, 
in testmod
    for test in finder.find(m, name, globs=globs, 
extraglobs=extraglobs):
  File "/Users/sasha/Work/python-svn/trunk/Lib/doctest.py", line 842, in 
find
    self._find(tests, obj, name, module, source_lines, globs, {})
  File "/Users/sasha/Work/python-svn/trunk/Lib/doctest.py", line 884, in 
_find
    test = self._get_test(obj, name, module, globs, source_lines)
  File "/Users/sasha/Work/python-svn/trunk/Lib/doctest.py", line 965, in 
_get_test
    if filename[-4:] in (".pyc", ".pyo"):
TypeError: 'NoneType' object is unsubscriptable

----------
components: Library (Lib)
files: testmodule.zip
messages: 75186
nosy: belopolsky
severity: normal
status: open
title: Doctest module does not work with zipped packages
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file11877/testmodule.zip

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

From report at bugs.python.org  Sat Oct 25 00:03:53 2008
From: report at bugs.python.org (dawidjoubert)
Date: Fri, 24 Oct 2008 22:03:53 +0000
Subject: [New-bugs-announce] [issue4198] os.path.normcase gets fooled on
	windows with mapped linux network drive
In-Reply-To: <1224885833.7.0.0397055051655.issue4198@psf.upfronthosting.co.za>
Message-ID: <1224885833.7.0.0397055051655.issue4198@psf.upfronthosting.co.za>


New submission from dawidjoubert <djspy187 at gmail.com>:

The documentation for os.path.normcase reads the case gets normalized
based on the file system
http://docs.python.org/dev/library/os.path.html

Current documentation:
Normalize the case of a pathname. On Unix, this returns the path
unchanged; on case-insensitive filesystems, it converts the path to
lowercase. On Windows, it also converts forward slashes to backward slashes.

Problem:
When mounting a network drive (via Samba) onto windows the mapped
network drive will claim to be an NTFS network (on Windows XP). Where
the network drive is actually a Samba share this can cause problems with
case sensitivity versus case insensitivity.

More:
The Windows based file systems such as FAT, FAT32 and NTFS are as a
matter of fact case preservant but case insensitive. That is a file
saved with the name 'MyName' will retain its name as 'MyName' and a ls
(dir) command will returnr the file as 'MyName' however access to
'Myname' or 'myname' or 'MYNAME' will all still access the same file.

Solution:
I suggest we drop converting the case to lower case where the file
systems FAT, FAT32 and NTFS are involved

----------
components: Windows
messages: 75187
nosy: dawidjoubert
severity: normal
status: open
title: os.path.normcase gets fooled on windows with mapped linux network drive
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Oct 25 00:32:15 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 24 Oct 2008 22:32:15 +0000
Subject: [New-bugs-announce] [issue4199] add shorthand global and nonlocal
	statements
In-Reply-To: <1224887535.03.0.272495603252.issue4199@psf.upfronthosting.co.za>
Message-ID: <1224887535.03.0.272495603252.issue4199@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

PEP 3104 says that the nonlocal and global statements should allow a
shorthand. ("global x; x = 3" == "global x = 3") This patch implements that.

----------
components: Interpreter Core
files: global_nonlocal_short_assign.patch
keywords: patch
messages: 75193
nosy: benjamin.peterson
priority: high
severity: normal
status: open
title: add shorthand global and nonlocal statements
versions: Python 3.1
Added file: http://bugs.python.org/file11880/global_nonlocal_short_assign.patch

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

From report at bugs.python.org  Sat Oct 25 00:45:55 2008
From: report at bugs.python.org (Graham Dumpleton)
Date: Fri, 24 Oct 2008 22:45:55 +0000
Subject: [New-bugs-announce] [issue4200] atexit module not safe in Python
	3.0 with multiple interpreters
In-Reply-To: <1224888355.2.0.82482284838.issue4200@psf.upfronthosting.co.za>
Message-ID: <1224888355.2.0.82482284838.issue4200@psf.upfronthosting.co.za>


New submission from Graham Dumpleton <Graham.Dumpleton at gmail.com>:

In Python 3.0 the atexit module was translated from Python code to C code.

Prior to Python 3.0, because it was implemented at C code level, the list of 
callbacks was specific to each sub interpreter. In Python 3.0 that appears to 
no longer be the case, with the list of callbacks being maintained globally as 
static C variable across all interpreters.

The end result is that if a sub interpreter registers an atexit callback, that 
callback will be called within the context of the main interpreter on call of 
Py_Finalize(), and not in context of the sub interpreter against which it was 
registered.

Various problems could ensue from this depending on whether or not the sub 
interpreter had also since been destroyed.

Still need to validate the above, but from visual inspection looks to be a 
problem. Issue found because mod_wsgi will trigger atexit callbacks for a sub 
interpreter when the sub interpreter is being destroyed. This is because Python 
prior to 3.0 only did it from the main interpreter. In Python 3.0, this all 
seems to get messed up now as no isolation between callbacks for each 
interpreter.

For mod_wsgi case, since it is explicitly triggering atexit callbacks for sub 
interpreter, in doing so it is actually calling all registered atexit callbacks 
across all interpreters for each sub interpreter being destroyed. They then 
again get called for Py_Finalize().

Even if mod_wsgi weren't doing this, still a problem that Py_Finalize() calling 
atexit callbacks in context of main interpreter which were actually associated 
with sub interpreter.

For mod_wsgi, will probably end up installing own 'atexit' module variant in 
sub interpreters to ensure separation.

----------
components: Interpreter Core
messages: 75195
nosy: grahamd
severity: normal
status: open
title: atexit module not safe in Python 3.0 with multiple interpreters
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Sat Oct 25 00:52:22 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 24 Oct 2008 22:52:22 +0000
Subject: [New-bugs-announce] [issue4201] Pdb cannot access source code in
	zipped packages.
In-Reply-To: <1224888742.6.0.77067400529.issue4201@psf.upfronthosting.co.za>
Message-ID: <1224888742.6.0.77067400529.issue4201@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

With attached test.zip and svn revision 67006,

$ ./python.exe test.zip 
> /Users/sasha/Work/python-svn/trunk/test.zip/__main__.py(2)f()
(Pdb) l
[EOF]

With pdb.patch:

$ ./python.exe test.zip 
> /Users/sasha/Work/python-svn/trunk/test.zip/__main__.py(2)f()
-> pass
(Pdb) l
  1  	def f():
  2  ->	    pass
  3  	
  4  	import pdb
  5  	pdb.runcall(f)
  6  	
  7  	                                
[EOF]

----------
files: test.zip
messages: 75197
nosy: belopolsky
severity: normal
status: open
title: Pdb cannot access source code in zipped packages.
Added file: http://bugs.python.org/file11882/test.zip

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

From report at bugs.python.org  Sat Oct 25 04:52:44 2008
From: report at bugs.python.org (Graham Dumpleton)
Date: Sat, 25 Oct 2008 02:52:44 +0000
Subject: [New-bugs-announce] [issue4202] Multiple interpreters and readline
	module hook functions.
In-Reply-To: <1224903164.25.0.50876142409.issue4202@psf.upfronthosting.co.za>
Message-ID: <1224903164.25.0.50876142409.issue4202@psf.upfronthosting.co.za>


New submission from Graham Dumpleton <Graham.Dumpleton at gmail.com>:

Because the readline module uses PyGILState_Ensure() to facilitate triggering 
callbacks into Python code, this would make the ability to use the hook 
functions incompatible with use in sub interpreters.

If this is the case, then that readline module cannot be used in sub 
interpreters should be documented if not already.

Better still, attempts to register hooks from sub interpreters should result in 
an exception. Further, when in use, in sub interpreter, callback hooks should 
also not be called if defined, because if defined they would be the hooks from 
the main interpreter since variables holding the hooks are static C variables 
and shared across all interpreters.

This issue derived from reading of code only and not tested in real program.

----------
components: Interpreter Core
messages: 75201
nosy: grahamd
severity: normal
status: open
title: Multiple interpreters and readline module hook functions.
versions: Python 2.5, Python 3.0

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

From report at bugs.python.org  Sat Oct 25 17:58:06 2008
From: report at bugs.python.org (Tim Michelsen)
Date: Sat, 25 Oct 2008 15:58:06 +0000
Subject: [New-bugs-announce] [issue4203] adapt sphinx-quickstart for windows
In-Reply-To: <1224950286.79.0.54626272369.issue4203@psf.upfronthosting.co.za>
Message-ID: <1224950286.79.0.54626272369.issue4203@psf.upfronthosting.co.za>


New submission from Tim Michelsen <timmichelsen at gmx-topmail.de>:

Hello,
for users on the windows platform, it could be of great help if the
sphinx-quickstart would be adjuste to their platform.
Here are my suggestions:
* create a batch file instead of the Makefile
    * make-docs.bat, contents: sphinx-build -a source build
* use "_" as default suggestion for the dotfiles.

Thanks for your great tool!

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 75212
nosy: georg.brandl, timmie
severity: normal
status: open
title: adapt sphinx-quickstart for windows

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

From report at bugs.python.org  Sat Oct 25 20:01:03 2008
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 25 Oct 2008 18:01:03 +0000
Subject: [New-bugs-announce] [issue4204] Cannot build _multiprocessing, math,
	mmap and readline of Python 2.6 on FreeBSD 4.11 w/ gcc 2.95.4
In-Reply-To: <1224957663.27.0.455052730171.issue4204@psf.upfronthosting.co.za>
Message-ID: <1224957663.27.0.455052730171.issue4204@psf.upfronthosting.co.za>


New submission from Akira Kitada <akitada at gmail.com>:

I was trying to build Python 2.6 on FreeBSD 4.11 and found it failed
to build some of the modules.

"""
Failed to find the necessary bits to build these modules:
_bsddb             _sqlite3           _tkinter
gdbm               linuxaudiodev      spwd
sunaudiodev
To find the necessary bits, look in setup.py in detect_modules() for
the module's name.


Failed to build these modules:
_multiprocessing   math               mmap
readline
"""

Because I don't have Berkeley DB, SQLite3 tk, GDBM installed on the
system and running FreeBSD,
there is no wonder it failed to build  _bsddb, _sqlite3, _tkinter,
gdbm, linuxaudiodev, spwd and sunaudiodev.

The problem is it failed to build _multiprocessing, math, mmap and readline.

Here are the outputs of each build failure.

"""
building '_multiprocessing' extension
creating
build/temp.freebsd-4.11-RELEASE-i386-2.6/usr/home/build/dev/Python-2.6/Modules/_multiprocessing
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1
-DHAVE_SEM_TIMEDWAIT=1 -IModules/_multiprocessing -I.
-I/usr/home/build/dev/Python-2.6/./
Include -I. -IInclude -I./Include -I/usr/local/include
-I/usr/home/build/dev/Python-2.6/Include
-I/usr/home/build/dev/Python-2.6 -c
/usr/home/build/dev/Python-2.6/Modules/_multiprocessing/multiprocessing.c
-o b
uild/temp.freebsd-4.11-RELEASE-i386-2.6/usr/home/build/dev/Python-2.6/Modules/_multiprocessing/multiprocessing.o
In file included from
/usr/home/build/dev/Python-2.6/Modules/_multiprocessing/multiprocessing.h:24,
                from
/usr/home/build/dev/Python-2.6/Modules/_multiprocessing/multiprocessing.c:9:
/usr/include/arpa/inet.h:89: warning: parameter has incomplete type
/usr/include/arpa/inet.h:92: warning: parameter has incomplete type
/usr/include/arpa/inet.h:96: warning: parameter has incomplete type
/usr/home/build/dev/Python-2.6/Modules/_multiprocessing/multiprocessing.c:
In function `multiprocessing_sendfd':
/usr/home/build/dev/Python-2.6/Modules/_multiprocessing/multiprocessing.c:102:
storage size of `dummy_iov' isn't known
/usr/home/build/dev/Python-2.6/Modules/_multiprocessing/multiprocessing.c:102:
warning: unused variable `dummy_iov'
/usr/home/build/dev/Python-2.6/Modules/_multiprocessing/multiprocessing.c:
In function `multiprocessing_recvfd':
/usr/home/build/dev/Python-2.6/Modules/_multiprocessing/multiprocessing.c:137:
storage size of `dummy_iov' isn't known
/usr/home/build/dev/Python-2.6/Modules/_multiprocessing/multiprocessing.c:137:
warning: unused variable `dummy_iov'
"""

"""
building 'cmath' extension
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/usr/home/build/dev/Python-2.6/./Include -I.
-IInclude -I./Include -I/usr/local/include
-I/usr/home/build/dev/Python-2.6/I
nclude -I/usr/home/build/dev/Python-2.6 -c
/usr/home/build/dev/Python-2.6/Modules/cmathmodule.c -o
build/temp.freebsd-4.11-RELEASE-i386-2.6/usr/home/build/dev/Python-2.6/Modules/cmathmodule.o
/usr/home/build/dev/Python-2.6/Modules/cmathmodule.c: In function
`special_type':
/usr/home/build/dev/Python-2.6/Modules/cmathmodule.c:79: warning:
implicit declaration of function `copysign'
/usr/home/build/dev/Python-2.6/Modules/cmathmodule.c: In function `c_acos':
/usr/home/build/dev/Python-2.6/Modules/cmathmodule.c:152: warning:
implicit declaration of function `asinh'
/usr/home/build/dev/Python-2.6/Modules/cmathmodule.c: In function `c_atanh':
/usr/home/build/dev/Python-2.6/Modules/cmathmodule.c:345: warning:
implicit declaration of function `log1p'
gcc -shared
build/temp.freebsd-4.11-RELEASE-i386-2.6/usr/home/build/dev/Python-2.6/Modules/cmathmodule.o
-L/usr/local/lib -lm -o
build/lib.freebsd-4.11-RELEASE-i386-2.6/cmath.so
building 'math' extension
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/usr/home/build/dev/Python-2.6/./Include -I.
-IInclude -I./Include -I/usr/local/include
-I/usr/home/build/dev/Python-2.6/I
nclude -I/usr/home/build/dev/Python-2.6 -c
/usr/home/build/dev/Python-2.6/Modules/mathmodule.c -o
build/temp.freebsd-4.11-RELEASE-i386-2.6/usr/home/build/dev/Python-2.6/Modules/mathmodule.o
/usr/home/build/dev/Python-2.6/Modules/mathmodule.c: In function `m_atan2':
/usr/home/build/dev/Python-2.6/Modules/mathmodule.c:118: warning:
implicit declaration of function `copysign'
/usr/home/build/dev/Python-2.6/Modules/mathmodule.c: In function
`math_acosh':
/usr/home/build/dev/Python-2.6/Modules/mathmodule.c:272: `acosh'
undeclared (first use in this function)
/usr/home/build/dev/Python-2.6/Modules/mathmodule.c:272: (Each
undeclared identifier is reported only once
/usr/home/build/dev/Python-2.6/Modules/mathmodule.c:272: for each
function it appears in.)
/usr/home/build/dev/Python-2.6/Modules/mathmodule.c: In function
`math_asinh':
/usr/home/build/dev/Python-2.6/Modules/mathmodule.c:276: `asinh'
undeclared (first use in this function)
/usr/home/build/dev/Python-2.6/Modules/mathmodule.c: In function
`math_atanh':
/usr/home/build/dev/Python-2.6/Modules/mathmodule.c:283: `atanh'
undeclared (first use in this function)
/usr/home/build/dev/Python-2.6/Modules/mathmodule.c: In function
`math_copysign':
/usr/home/build/dev/Python-2.6/Modules/mathmodule.c:288: `copysign'
undeclared (first use in this function)
/usr/home/build/dev/Python-2.6/Modules/mathmodule.c: In function
`math_log1p':
/usr/home/build/dev/Python-2.6/Modules/mathmodule.c:301: `log1p'
undeclared (first use in this function)
/usr/home/build/dev/Python-2.6/Modules/mathmodule.c: In function
`math_ldexp':
/usr/home/build/dev/Python-2.6/Modules/mathmodule.c:666: `copysign'
used prior to declaration
/usr/home/build/dev/Python-2.6/Modules/mathmodule.c:670: `copysign'
used prior to declaration
/usr/home/build/dev/Python-2.6/Modules/mathmodule.c: In function
`math_modf':
/usr/home/build/dev/Python-2.6/Modules/mathmodule.c:699: `copysign'
used prior to declaration
/usr/home/build/dev/Python-2.6/Modules/mathmodule.c: In function `math_pow':
/usr/home/build/dev/Python-2.6/Modules/mathmodule.c:901: `copysign'
used prior to declaration
"""

"""
building 'mmap' extension
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/usr/home/build/dev/Python-2.6/./Include -I.
-IInclude -I./Include -I/usr/local/include
-I/usr/home/build/dev/Python-2.6/I
nclude -I/usr/home/build/dev/Python-2.6 -c
/usr/home/build/dev/Python-2.6/Modules/mmapmodule.c -o
build/temp.freebsd-4.11-RELEASE-i386-2.6/usr/home/build/dev/Python-2.6/Modules/mmapmodule.o
/usr/home/build/dev/Python-2.6/Modules/mmapmodule.c: In function `initmmap':
/usr/home/build/dev/Python-2.6/Modules/mmapmodule.c:1440: warning:
implicit declaration of function `my_getallocationgranularity'
gcc -shared
build/temp.freebsd-4.11-RELEASE-i386-2.6/usr/home/build/dev/Python-2.6/Modules/mmapmodule.o
-L/usr/local/lib -o build/lib.freebsd-4.11-RELEASE-i386-2.6/mmap.so
*** WARNING: renaming "mmap" since importing it failed:
build/lib.freebsd-4.11-RELEASE-i386-2.6/mmap.so: Undefined symbol
"my_getallocationgranularity"
"""

"""
building 'readline' extension
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/usr/home/build/dev/Python-2.6/./Include -I.
-IInclude -I./Include -I/usr/local/include
-I/usr/home/build/dev/Python-2.6/I
nclude -I/usr/home/build/dev/Python-2.6 -c
/usr/home/build/dev/Python-2.6/Modules/readline.c -o
build/temp.freebsd-4.11-RELEASE-i386-2.6/usr/home/build/dev/Python-2.6/Modules/readline.o
In file included from /usr/include/readline/readline.h:37,
                from /usr/home/build/dev/Python-2.6/Modules/readline.c:31:
/usr/include/readline/keymaps.h:40: warning: function declaration
isn't a prototype
/usr/include/readline/keymaps.h:41: warning: function declaration
isn't a prototype
/usr/include/readline/keymaps.h:42: warning: function declaration
isn't a prototype
/usr/include/readline/keymaps.h:43: warning: function declaration
isn't a prototype
In file included from /usr/home/build/dev/Python-2.6/Modules/readline.c:31:
/usr/include/readline/readline.h:343: warning: function declaration
isn't a prototype
/usr/home/build/dev/Python-2.6/Modules/readline.c:38: syntax error
before `rl_compentry_func_t'
/usr/home/build/dev/Python-2.6/Modules/readline.c:38: warning:
function declaration isn't a prototype
/usr/home/build/dev/Python-2.6/Modules/readline.c: In function
`set_completion_display_matches_hook':
/usr/home/build/dev/Python-2.6/Modules/readline.c:216:
`rl_compdisp_func_t' undeclared (first use in this function)
/usr/home/build/dev/Python-2.6/Modules/readline.c:216: (Each
undeclared identifier is reported only once
/usr/home/build/dev/Python-2.6/Modules/readline.c:216: for each
function it appears in.)
/usr/home/build/dev/Python-2.6/Modules/readline.c:216: syntax error
before `)'
/usr/home/build/dev/Python-2.6/Modules/readline.c: At top level:
/usr/home/build/dev/Python-2.6/Modules/readline.c:669: warning:
`on_completion_display_matches_hook' defined but not used
"""

Because FreeBSD is not listed on
http://www.python.org/dev/peps/pep-0011/, I suppose it's still a
supported platform.

----------
messages: 75215
nosy: akitada
severity: normal
status: open
title: Cannot build _multiprocessing, math, mmap and readline of Python 2.6 on FreeBSD 4.11 w/ gcc 2.95.4
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Sat Oct 25 23:44:55 2008
From: report at bugs.python.org (Eric Devolder)
Date: Sat, 25 Oct 2008 21:44:55 +0000
Subject: [New-bugs-announce] [issue4205] unexpected str.__init__() behaviour
	on b''
In-Reply-To: <1224971095.64.0.171830608062.issue4205@psf.upfronthosting.co.za>
Message-ID: <1224971095.64.0.171830608062.issue4205@psf.upfronthosting.co.za>


New submission from Eric Devolder <eric.devolder at gmail.com>:

creating a unicode string from an empty b'' does not result in '', but
produces "b''" instead.

>>> str(b'')
"b''"

Workaround: if the encoding is specified, the resulting string is fine.
>>> str(b'', 'ascii')
''

----------
components: Interpreter Core, Unicode
messages: 75220
nosy: keldonin
severity: normal
status: open
title: unexpected str.__init__() behaviour on b''
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Sun Oct 26 03:21:08 2008
From: report at bugs.python.org (David W. Lambert)
Date: Sun, 26 Oct 2008 02:21:08 +0000
Subject: [New-bugs-announce] [issue4206] multiprocessing docs
In-Reply-To: <1224987668.88.0.751751151091.issue4206@psf.upfronthosting.co.za>
Message-ID: <1224987668.88.0.751751151091.issue4206@psf.upfronthosting.co.za>


New submission from David W. Lambert <lambertdw at corning.com>:

http://docs.python.org/dev/3.0/library/multiprocessing.html

"map(func, iterable[, chunksize])
A parallel equivalent of the map() builtin function. It blocks till the 
result is ready."

Not really, __builtins__.map returns a mapping object,
Pool().map returns...a list?

>>> print(multiprocessing.Pool().map.__doc__)  # rather lame doc string!

        Equivalent of `map()` builtin

----------
assignee: georg.brandl
components: Documentation
messages: 75223
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: multiprocessing docs
versions: Python 3.0

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

From report at bugs.python.org  Sun Oct 26 12:53:07 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 26 Oct 2008 11:53:07 +0000
Subject: [New-bugs-announce] [issue4207] Remove backwards compatibility in
	_heapq for performance
In-Reply-To: <1225021987.36.0.560633277086.issue4207@psf.upfronthosting.co.za>
Message-ID: <1225021987.36.0.560633277086.issue4207@psf.upfronthosting.co.za>


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

Comparing _heapq with our own legacy C implementation, blue.heapq at 
CCP, I noticed that ours was somewhat faster.
I discovered that a lot of effort is being spent to dynamically search 
for a __lt__ operator, to provide backwards compatibility.  I think we 
should consider dropping that after this much time, especially for a 
new python version.  Running this code:

from timeit import *
s = """
import heapq
import random
l = [random.random() for i in xrange(10000)]
"""

print "heapify", Timer("heapq.heapify(list(l))", s).timeit(100)

s = s + """
heapq.heapify(l)
"""
print "pushpop", Timer("heapq.heappushpop(l,random.random())", s).timeit
(500000)


would give 
heapify 0.289102944648
pushpop 0.343299078514
before.  After the patch, we get:
heapify 0.0958507994731
pushpop 0.220800967721

This is "release" code on a snappy windows machine.

----------
components: Extension Modules
files: heapq1.patch
keywords: easy, patch, patch
messages: 75224
nosy: krisvale
severity: normal
status: open
title: Remove backwards compatibility in _heapq for performance
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file11889/heapq1.patch

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

From report at bugs.python.org  Sun Oct 26 16:21:14 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 26 Oct 2008 15:21:14 +0000
Subject: [New-bugs-announce] [issue4208] Make multiprocessing compatible
	with Python 2.4 and 2.5
In-Reply-To: <1225034474.82.0.458838457625.issue4208@psf.upfronthosting.co.za>
Message-ID: <1225034474.82.0.458838457625.issue4208@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

The patch contains all differences between our multiprocessing backport
to 2.4 / 2.5 and the release26-maint branch. The patch should NOT be
applied yet. I've created the patch to discuss the differences.

Several changes could be avoided by monkey patching the threading module
of Python 2.4 and 2.5. Other changes are required like using the old
buffer protocol.

----------
components: Interpreter Core, Library (Lib)
files: mp_py25_compat.diff
keywords: patch, patch
messages: 75231
nosy: christian.heimes, jnoller, skip.montanaro
priority: low
severity: normal
status: open
title: Make multiprocessing compatible with Python 2.4 and 2.5
type: feature request
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file11891/mp_py25_compat.diff

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

From report at bugs.python.org  Sun Oct 26 18:09:42 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 26 Oct 2008 17:09:42 +0000
Subject: [New-bugs-announce] [issue4209] from __future__ import
	unicode_literals, print_function doesn't work
In-Reply-To: <1225040982.87.0.144130248844.issue4209@psf.upfronthosting.co.za>
Message-ID: <1225040982.87.0.144130248844.issue4209@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

This is because parser.c's future_hack breaks out of the loop when it
finds one feature. Patch with test is attached.

----------
components: Interpreter Core
files: fix_multiple_features.patch
keywords: patch
messages: 75237
nosy: benjamin.peterson
priority: release blocker
severity: normal
status: open
title: from __future__ import unicode_literals, print_function doesn't work
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file11893/fix_multiple_features.patch

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

From report at bugs.python.org  Sun Oct 26 18:48:49 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 26 Oct 2008 17:48:49 +0000
Subject: [New-bugs-announce] [issue4210] os.remove can be used to remove
	directories on SunOS
In-Reply-To: <1225043329.93.0.727010084748.issue4210@psf.upfronthosting.co.za>
Message-ID: <1225043329.93.0.727010084748.issue4210@psf.upfronthosting.co.za>


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

Done against a SunOS 5.10 equipped with Python 2.4.4.

>>> import os
>>> os.mkdir('foo')
>>> os.remove('foo')
>>>

----------
messages: 75238
nosy: giampaolo.rodola
severity: normal
status: open
title: os.remove can be used to remove directories on SunOS

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

From report at bugs.python.org  Mon Oct 27 03:42:05 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 Oct 2008 02:42:05 +0000
Subject: [New-bugs-announce] [issue4211] frozen packages set an improper
	__path__ value
In-Reply-To: <1225075325.55.0.00322854082077.issue4211@psf.upfronthosting.co.za>
Message-ID: <1225075325.55.0.00322854082077.issue4211@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

If you import a frozen package (e.g. __phello__), __path__ is set to
'__phello__'. But this should be a list as specified by both PEP 302
(http://www.python.org/dev/peps/pep-0302/) and the original doc
outlining the package mechanism
(http://www.python.org/doc/essays/packages.html).

Changing import to put the string in a list is all that is needed to
correct this (although it might break some code relying on the fact that
it has been a string in previous versions).

----------
components: Interpreter Core
messages: 75250
nosy: brett.cannon
severity: normal
status: open
title: frozen packages set an improper __path__ value
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Mon Oct 27 06:57:21 2008
From: report at bugs.python.org (Brandon Bloom)
Date: Mon, 27 Oct 2008 05:57:21 +0000
Subject: [New-bugs-announce] [issue4212] email.LazyImporter does not use
	absolute imports
In-Reply-To: <1225087041.33.0.0357186656553.issue4212@psf.upfronthosting.co.za>
Message-ID: <1225087041.33.0.0357186656553.issue4212@psf.upfronthosting.co.za>


New submission from Brandon Bloom <brandon at classlet.com>:

I have a package with a module called "email". If I try to use the 
standard email package, it fails to load email.Utils because 
email.LazyImporter is looking in my email module instead of the top-
level email package.

----------
components: Library (Lib)
messages: 75251
nosy: brandonbloom
severity: normal
status: open
title: email.LazyImporter does not use absolute imports
type: behavior
versions: Python 2.5.3

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

From report at bugs.python.org  Mon Oct 27 14:29:15 2008
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 27 Oct 2008 13:29:15 +0000
Subject: [New-bugs-announce] [issue4213] Lower case file system encoding
In-Reply-To: <1225114155.31.0.609003653611.issue4213@psf.upfronthosting.co.za>
Message-ID: <1225114155.31.0.609003653611.issue4213@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

Python should lower case the file system encoding in Python/pythonrun.c.
On several occasions Python optimizes code paths for lower case
encodings like "utf-8" or "latin-1". On my Ubuntu system the file system
encoding is upper case ("UTF-8") and the optimizations aren't used. This
also causes problems with sub interpreters #3723 initstdio() in the sub
interpreter fails because "UTF-8" must be looked up in the codecs and
encoding registry while "utf-8" works like a charm.

$ python2.6 -c "import sys; print sys.getfilesystemencoding()"
UTF-8

$ python3.0 -c "import sys; print(sys.getfilesystemencoding())"
UTF-8

$ locale
LANG=de_DE.UTF-8
LANGUAGE=en_US:en:de_DE:de
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=

The patch is trivial:

	if (codeset) {
		if (!Py_FileSystemDefaultEncoding) {
			char *p;
			for (p=codeset; *p; p++)
				*p = tolower(*p);
			Py_FileSystemDefaultEncoding = codeset;
                }
		else
			free(codeset);
	}

Python/codecs.c:normalizestring() does a similar job. Maybe a new method
"char* PyCodec_NormalizeEncodingName(const char*)" could be introduced
for the problem.

----------
assignee: barry
components: Interpreter Core
keywords: patch
messages: 75252
nosy: barry, christian.heimes
priority: release blocker
severity: normal
status: open
title: Lower case file system encoding
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0

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

From report at bugs.python.org  Mon Oct 27 22:54:22 2008
From: report at bugs.python.org (Robin Dunn)
Date: Mon, 27 Oct 2008 21:54:22 +0000
Subject: [New-bugs-announce] [issue4214] no extension debug info with
	msvc9compiler.py
In-Reply-To: <1225144462.62.0.9122976862.issue4214@psf.upfronthosting.co.za>
Message-ID: <1225144462.62.0.9122976862.issue4214@psf.upfronthosting.co.za>


New submission from Robin Dunn <robin at alldunn.com>:

It looks like part of r59290 resulted in /pdb:None always being part of
the ldflags_shared_debug list.  This means that there will be no debug
info stored for extensions built in debug mode, which kinda negates the
purpose of doing a debug build.  

Looking back at the revision history and comparing similar code in
msvccompiler.py it looks like the /pdb:None was optionally added in the
first place because of compatibility issues with earlier compilers.  For
MSVC 7 and 9 I think it should be fine to simply remove /pdb:None from
that list.  My ad hoc testing so far has not revealed any problems with
making this change.

----------
components: Distutils
messages: 75264
nosy: robind
severity: normal
status: open
title: no extension debug info with msvc9compiler.py
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Tue Oct 28 00:18:28 2008
From: report at bugs.python.org (Joey Pallaria)
Date: Mon, 27 Oct 2008 23:18:28 +0000
Subject: [New-bugs-announce] [issue4215] Running Python 2.6 GUI on Windows
	Vista
In-Reply-To: <1225149508.54.0.581976390408.issue4215@psf.upfronthosting.co.za>
Message-ID: <1225149508.54.0.581976390408.issue4215@psf.upfronthosting.co.za>


New submission from Joey Pallaria <fighterwing04 at hotmail.com>:

I installed Python 2.6 a few days ago and tried to launch the Python 
IDLE GUI application. Nothing happened. 

I've read a couple issues about previous versions of Python IDLE not 
working on Windows Vista. and they recommended deleting the .idlerc 
folder in the user directory as well as disabling the UAC (User Account 
Control)

I've done both of these, but i still can't manage to get IDLE to run, 
any help would be greatly appreciated.

----------
components: IDLE
messages: 75267
nosy: Elushin
severity: normal
status: open
title: Running Python 2.6 GUI on Windows Vista
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Oct 28 00:57:47 2008
From: report at bugs.python.org (Amy)
Date: Mon, 27 Oct 2008 23:57:47 +0000
Subject: [New-bugs-announce] [issue4216] subprocess.Popen hangs at
	communicate() when child exits
In-Reply-To: <1225151867.64.0.844146967045.issue4216@psf.upfronthosting.co.za>
Message-ID: <1225151867.64.0.844146967045.issue4216@psf.upfronthosting.co.za>


New submission from Amy <amy20_z at yahoo.com>:

I have a simple program to call a shell command "service cpboot start"
to start Check Point firewall on RHEL5.1.

=================
#!/usr/bin/env python
# vim: softtabstop=4 shiftwidth=4 expandtab

import os
from subprocess import *

p = Popen('service cpboot stop',shell=True, stdout=PIPE)
output = p.communicate()
print 'STDERR: %s' % output[0]
print 'STDOUT: %s' % output[1]

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

Python process pid 13343 spawned child 13375 to run "service cpboot
start".  However, after child process 13375 finished and sent SIGCHLD to
the python script, the parent hangs in Popen function communicate() at
line 1041 and child process 13375 became a defunct process.


Traceback (most recent call last):
  File "./subprocess_test03.py", line 7, in ?
    output = p.communicate()
  File "/usr/lib/python2.4/subprocess.py", line 1041, in communicate
    rlist, wlist, xlist = select.select(read_set, write_set, [])
KeyboardInterrupt


Here is part of the strace:

Process 13375 detached
[pid 19195] close(878)                  = -1 EBADF (Bad file descriptor)
[pid 19195] close(879)                  = -1 EBADF (Bad file descriptor)
[pid 19195] close(880)                  = -1 EBADF (Bad file descriptor)
[pid 13343] <... select resumed> )      = ? ERESTARTNOHAND (To be restarted)
[pid 19195] close(881 <unfinished ...>
[pid 13343] --- SIGCHLD (Child exited) @ 0 (0) ---
[pid 19195] <... close resumed> )       = -1 EBADF (Bad file descriptor)
[pid 13343] select(7, [4 6], [], [], NULL <unfinished ...>


It seems like the select system call got interrupted and error code was
"ERESTARTNOHAND" was returned. The PIPEs won't be able to terminate
since child process has finished and exited and EOF won't be read from
the PIPEs.

If executing the shell command directly from shell command line, there's
no problem at all.It seems like there might be some race condition
somewhere in the python library. 

Any idea what may cause the problem? Many thanks in advance.

----------
components: Library (Lib)
files: subprocess_test03.py
messages: 75270
nosy: amy20_z
severity: normal
status: open
title: subprocess.Popen hangs at communicate() when child exits
type: crash
versions: Python 2.4
Added file: http://bugs.python.org/file11898/subprocess_test03.py

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

From report at bugs.python.org  Tue Oct 28 01:26:26 2008
From: report at bugs.python.org (Bill Hart)
Date: Tue, 28 Oct 2008 00:26:26 +0000
Subject: [New-bugs-announce] [issue4217] Add file comparisons to the
	unittest library
In-Reply-To: <1225153586.34.0.218245937188.issue4217@psf.upfronthosting.co.za>
Message-ID: <1225153586.34.0.218245937188.issue4217@psf.upfronthosting.co.za>


New submission from Bill Hart <wehart at sandia.gov>:

In the past year I've become a heavy user of the unittest package for
managing a variety of software tests.  One capability that I've
frequently needed is the ability to generate text file outputs that can
be compared against a baseline.  To my knowledge, this is not currently
supported in unittest.

I've developed several file comparison functions that are written in a
unittest-like style.  See

 
https://software.sandia.gov/svn/public/pyutilib/trunk/pyutilib_th/pyunit.py

for the test functions, and 

  https://software.sandia.gov/svn/public/pyutilib/trunk/pyutilib_th/misc.py

for the underlying file comparison functions.

----------
components: Library (Lib)
messages: 75271
nosy: wehart
severity: normal
status: open
title: Add file comparisons to the unittest library
type: feature request

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

From report at bugs.python.org  Tue Oct 28 16:12:12 2008
From: report at bugs.python.org (gerhard_xXx)
Date: Tue, 28 Oct 2008 15:12:12 +0000
Subject: [New-bugs-announce] [issue4218] tarfile module fails to correctly
	parse some .tar.gz archives?!
In-Reply-To: <1225206732.62.0.645534354703.issue4218@psf.upfronthosting.co.za>
Message-ID: <1225206732.62.0.645534354703.issue4218@psf.upfronthosting.co.za>


New submission from gerhard_xXx <h9204473 at wu-wien.ac.at>:

hi,

seems like tarfile module for python 2.4 is broken.
If I open the attached dir.tar.gz (tried it on different machines) then
tarfile module only displays a part of the contents.

what I did:
>>> import tarfile
>>> f = tarfile.open('dir.tar.gz','r:gz')
>>> f.getnames()

getnames() only returns the files/directories in the dir.tar.gz that
start with letter "a-j" and skips the rest???!!

cheers gerhard

More info (I have debian etch installation):
Python 2.4.4 (#2, Apr 16 2008, 17:58:59)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2

$ tar --version
tar (GNU tar) 1.16
Copyright (C) 2006 Free Software Foundation, Inc.

----------
components: Extension Modules
files: dir.tar.gz
messages: 75284
nosy: gerhard_xXx
severity: normal
status: open
title: tarfile module fails to correctly parse some .tar.gz archives?!
type: behavior
versions: Python 2.4
Added file: http://bugs.python.org/file11899/dir.tar.gz

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

From report at bugs.python.org  Tue Oct 28 16:46:13 2008
From: report at bugs.python.org (Carlos Eduardo Klock)
Date: Tue, 28 Oct 2008 15:46:13 +0000
Subject: [New-bugs-announce] [issue4219] Problem with regular expression
In-Reply-To: <1225208773.16.0.104236960618.issue4219@psf.upfronthosting.co.za>
Message-ID: <1225208773.16.0.104236960618.issue4219@psf.upfronthosting.co.za>


New submission from Carlos Eduardo Klock <ceklock at gmail.com>:

Hello, 

I am having a weird problem with regex. I am trying to get the tokens
that match the pattern below, but it is not working only for a specific
case. I do this for many lines of text, and it works, except for the
string '1214578800'.

Any idea of what is happening? Is it a problem of my code or a bug in
regular expressions?

Thanks for any help,

Carlos.



import re
r =
re.compile(",'([0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9])'[,|)]")
text =
"('25','2','3','2','0','1','0','0/350','30','21','5','','1211641200','1214578800','0','2','1214662622');"
timestamps = r.findall(text)
print timestamps


OUTPUT:
Python 2.5.2 (r252:60911, Jul 31 2008, 17:31:22) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on Trabalho15, Standard
>>> ['1211641200', '1214662622']

----------
components: Regular Expressions
messages: 75286
nosy: carlosklock
severity: normal
status: open
title: Problem with regular expression
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue Oct 28 17:19:48 2008
From: report at bugs.python.org (David Fugate)
Date: Tue, 28 Oct 2008 16:19:48 +0000
Subject: [New-bugs-announce] [issue4220] Builtins treated as free variables?
In-Reply-To: <1225210788.32.0.89272753959.issue4220@psf.upfronthosting.co.za>
Message-ID: <1225210788.32.0.89272753959.issue4220@psf.upfronthosting.co.za>


New submission from David Fugate <dfugate at microsoft.com>:

#----------------------------------------------------------------------
VERSION AFFECTED: 2.5 and 2.6
BUILD TYPE: x86
FLAGS PASSED TO PYTHON.EXE: None
OPERATING SYSTEM: 32-bit Windows Vista SP1

#----------------------------------------------------------------------
BRIEF DESCRIPTION:
According to 
http://docs.python.org/dev/reference/executionmodel.html#interaction-
with-dynamic-features, a free variable is a variable used from some 
local scope that is not defined there.  The behavior of Python 2.5/2.6 
is that it treats certain Python keywords and builtin types/functions 
used in nested scopes as free variables as well.  This seems a little 
odd.

Could the documentation be clarified to state: usage of certain Python 
keywords are considered to be free variables.  I.e., a line simply 
containing "int" triggers the free variable behavior.  Alternatively, 
usage of builtin types/functions could be allowed from nested functions 
with calls to "exec"?

Thanks,

Dave

#----------------------------------------------------------------------
REPRODUCTION SNIPPET:
def a():
    def b():
        x = long(3) #Replace me with "x = 3L" and this works
        int #This must be commented out
        exec ""


emits the following:
      File "garbage.py", line 4
        exec ""
     SyntaxError: unqualified exec is not allowed in function 'b' it is 
a nested function
unless the "x = long(3)" and "int" lines are commented out.

----------
assignee: georg.brandl
components: Documentation, Interpreter Core
files: garbage.py
messages: 75289
nosy: dfugate, georg.brandl
severity: normal
status: open
title: Builtins treated as free variables?
type: compile error
versions: Python 2.5.3, Python 2.6
Added file: http://bugs.python.org/file11900/garbage.py

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

From report at bugs.python.org  Tue Oct 28 18:11:57 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 28 Oct 2008 17:11:57 +0000
Subject: [New-bugs-announce] [issue4221] inconsistent exception from int is
	confusing
In-Reply-To: <1225213917.89.0.391557406226.issue4221@psf.upfronthosting.co.za>
Message-ID: <1225213917.89.0.391557406226.issue4221@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

exarkun at charm:~$ python
Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> int('\0', 256)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 256: '\x00'
>>> int('x', 256)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: int() base must be >= 2 and <= 36
>>> 

The former is misleading.  \x00 is a perfectly valid byte if the base is
256.  The real problem, that base 256 isn't supported, is obscured.  It
would be much better for the latter case's message to be used in the
former case.

----------
components: Interpreter Core
messages: 75290
nosy: exarkun
severity: normal
status: open
title: inconsistent exception from int is confusing
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Oct 28 18:16:46 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 28 Oct 2008 17:16:46 +0000
Subject: [New-bugs-announce] [issue4222] dis.findlinestarts is missing from
	dis.__all__ and from the online documentation
In-Reply-To: <1225214206.66.0.527749553778.issue4222@psf.upfronthosting.co.za>
Message-ID: <1225214206.66.0.527749553778.issue4222@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

There aren't many high-ish level APIs for dealing with lnotab. 
dis.findlinestarts is one, but it's not clear if it's private or public.
 If it's public, it'd be great to make it clear that it is and document
it.  If it's not, perhaps it should be renamed _findlinestarts.

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 75291
nosy: exarkun, georg.brandl
severity: normal
status: open
title: dis.findlinestarts is missing from dis.__all__ and from the online documentation
versions: Python 2.4, Python 2.5, Python 2.5.3, Python 2.6

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

From report at bugs.python.org  Tue Oct 28 18:19:46 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 28 Oct 2008 17:19:46 +0000
Subject: [New-bugs-announce] [issue4223] inspect.getsource doesn't work on
	functions imported from a zipfile
In-Reply-To: <1225214386.69.0.0480331344152.issue4223@psf.upfronthosting.co.za>
Message-ID: <1225214386.69.0.0480331344152.issue4223@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

It'd be better if it did.

----------
components: Library (Lib)
messages: 75292
nosy: exarkun
severity: normal
status: open
title: inspect.getsource doesn't work on functions imported from a zipfile
type: behavior
versions: Python 2.5, Python 2.5.3, Python 2.6

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

From report at bugs.python.org  Tue Oct 28 22:53:14 2008
From: report at bugs.python.org (Martin Green)
Date: Tue, 28 Oct 2008 21:53:14 +0000
Subject: [New-bugs-announce] [issue4224] ** operating incorrectly for
	negative bases?
In-Reply-To: <1225230794.37.0.55524776899.issue4224@psf.upfronthosting.co.za>
Message-ID: <1225230794.37.0.55524776899.issue4224@psf.upfronthosting.co.za>


New submission from Martin Green <martin.speleo at gmail.com>:

I suspect that the following behavior is incorrect:

Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit
(Intel)] on win32
>>> -1**2
-1
>>> -2**2
-4
>>> -1**0.5
-1.0

The same happens when the base is a float.
I have not checked out the functionality of other versions of python

The function pow (which claims to be equivalent to **) works as I would
expect:

>>> pow(-1, 2)
1
>>> pow(-2, 2)
4
>>> pow(-1, 0.5)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: negative number cannot be raised to a fractional power

I was not sure which components to select, please change them if I got
it wrong.

----------
assignee: theller
components: Tests, ctypes
messages: 75304
nosy: martin.speleo, theller
severity: normal
status: open
title: ** operating incorrectly for negative bases?
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue Oct 28 23:06:44 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 28 Oct 2008 22:06:44 +0000
Subject: [New-bugs-announce] [issue4225] unicode_literals doesn't work in
	exec
In-Reply-To: <1225231604.07.0.232278936912.issue4225@psf.upfronthosting.co.za>
Message-ID: <1225231604.07.0.232278936912.issue4225@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

exec "from __future__ import unicode_literals; print type('')"

gives <type 'str'> in 2.6/2.7. It's the result of flags not being passed
from the parser to AST.

----------
components: Interpreter Core
files: fix_exec_literals.patch
keywords: needs review, patch
messages: 75307
nosy: benjamin.peterson, georg.brandl
priority: high
severity: normal
status: open
title: unicode_literals doesn't work in exec
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file11902/fix_exec_literals.patch

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

From report at bugs.python.org  Wed Oct 29 04:23:20 2008
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 29 Oct 2008 03:23:20 +0000
Subject: [New-bugs-announce] [issue4226] Should 2to3 know that file type is
	gone?
In-Reply-To: <1225250600.04.0.735766094217.issue4226@psf.upfronthosting.co.za>
Message-ID: <1225250600.04.0.735766094217.issue4226@psf.upfronthosting.co.za>


New submission from David W. Lambert <lambertdw at corning.com>:

class c(file):
    pass


2to3 says no changes required.
Might it possibly suggest a replacement for file class?

Thanks, Dave.

----------
messages: 75310
nosy: LambertDW
severity: normal
status: open
title: Should 2to3 know that file type is gone?

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

From report at bugs.python.org  Wed Oct 29 10:57:56 2008
From: report at bugs.python.org (Wang Chun)
Date: Wed, 29 Oct 2008 09:57:56 +0000
Subject: [New-bugs-announce] [issue4227] unicode_literals and print_function
	do not work together.
In-Reply-To: <1225274276.85.0.338026841433.issue4227@psf.upfronthosting.co.za>
Message-ID: <1225274276.85.0.338026841433.issue4227@psf.upfronthosting.co.za>


New submission from Wang Chun <yaohua2000 at gmail.com>:

If "from __future__ import unicode_literals, print_function", 
unicode_literals works, but not print_function;

If "from __future__ import print_function, unicode_literals", 
print_function works, but not unicode_literals.

----------
components: Interpreter Core
messages: 75314
nosy: wangchun
severity: normal
status: open
title: unicode_literals and print_function do not work together.
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Oct 29 16:41:02 2008
From: report at bugs.python.org (Armin Rigo)
Date: Wed, 29 Oct 2008 15:41:02 +0000
Subject: [New-bugs-announce] [issue4228] struct.pack('L', -1)
In-Reply-To: <1225294862.2.0.0798680271584.issue4228@psf.upfronthosting.co.za>
Message-ID: <1225294862.2.0.0798680271584.issue4228@psf.upfronthosting.co.za>


New submission from Armin Rigo <arigo at users.sourceforge.net>:

struct.pack('L', -1) raises a DeprecationWarning since Python 2.5, as it
should.  However, it also returns a different (and nonsensical) result
than Python <= 2.4 used to: it returns '\x00\x00\x00\x00' instead of
'\xff\xff\xff\xff'.

This might lead the zipfile module of release25-maint (the version >=
2.5.2) to produce buggy zip files.  The -1 value can come as the
header_offset field, which will then be packed as an all-0 string
instead of an all-ff string in the zip file headers.

Given the DeprecationWarning I would classify this as low priority. 
However, given that the stdlib module zipfile relies on this feature in
release25-maint, it should probably really be fixed.

----------
messages: 75319
nosy: arigo
severity: normal
status: open
title: struct.pack('L', -1)
versions: Python 2.5, Python 2.5.3, Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Oct 29 18:11:17 2008
From: report at bugs.python.org (Clifford Burtown)
Date: Wed, 29 Oct 2008 17:11:17 +0000
Subject: [New-bugs-announce] [issue4229] Can't Start Python
In-Reply-To: <1225300277.72.0.801669602518.issue4229@psf.upfronthosting.co.za>
Message-ID: <1225300277.72.0.801669602518.issue4229@psf.upfronthosting.co.za>


New submission from Clifford Burtown <antonio_rolo at hotmail.com>:

I just got Python, in order to do some game modding that required it.
However, I can't open Python files in my computer, neither can I edit
them with IDLE. I'm using Vista. Is this common?

----------
messages: 75321
nosy: CliffB
severity: normal
status: open
title: Can't Start Python
versions: Python 2.6

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

From report at bugs.python.org  Wed Oct 29 18:46:02 2008
From: report at bugs.python.org (Armin Rigo)
Date: Wed, 29 Oct 2008 17:46:02 +0000
Subject: [New-bugs-announce] [issue4230] "__getattr__" can't be a descriptor
In-Reply-To: <1225302362.81.0.484581196319.issue4230@psf.upfronthosting.co.za>
Message-ID: <1225302362.81.0.484581196319.issue4230@psf.upfronthosting.co.za>


New submission from Armin Rigo <arigo at users.sourceforge.net>:

The attached example works in the __add__ and __getattribute__ cases on
CPython, but fails in the __getattr__ case.  All three cases work as the
semantics say they should on Jython, IronPython and PyPy.  It's
admittedly an obscure use case. 

There is no reason that __getattr__ should behave differently.  The
behavior of __add__ and __getattribute__ is the "correct" one, according
to the rule that special methods are bound (with __get__) before they
are called.

----------
components: Interpreter Core
files: x.py
messages: 75322
nosy: arigo, cfbolz
priority: low
severity: normal
status: open
title: "__getattr__" can't be a descriptor
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file11905/x.py

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

From report at bugs.python.org  Wed Oct 29 20:21:37 2008
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 29 Oct 2008 19:21:37 +0000
Subject: [New-bugs-announce] [issue4231] print "    should be   print("
In-Reply-To: <1225308097.29.0.139692797373.issue4231@psf.upfronthosting.co.za>
Message-ID: <1225308097.29.0.139692797373.issue4231@psf.upfronthosting.co.za>


New submission from David W. Lambert <lambertdw at corning.com>:

http://docs.python.org/dev/3.0/reference/datamodel.html


>>> class Meta(type):
...    def __getattribute__(*args):
...       print "Metaclass getattribute invoked"
xxx
...         print "Class getattribute invoked"

perhaps there's a way to search all of the code examples in the new
documents to fix most of these occurrences instead of finding them
piecemeal?

print(re.compile("print *[^(]").search(code_examples(all_dev_docs)))

----------
messages: 75326
nosy: LambertDW
severity: normal
status: open
title: print "    should be   print("

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

From report at bugs.python.org  Wed Oct 29 21:23:41 2008
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Wed, 29 Oct 2008 20:23:41 +0000
Subject: [New-bugs-announce] [issue4232] tempfile.gettempdir() availability
	not documented
In-Reply-To: <1225311821.2.0.778460458115.issue4232@psf.upfronthosting.co.za>
Message-ID: <1225311821.2.0.778460458115.issue4232@psf.upfronthosting.co.za>


New submission from Ville Skytt? <ville.skytta at iki.fi>:

The documentation for tempfile.gettempdir() at
http://docs.python.org/library/tempfile.html#module-tempfile does not
mention in which version the function was added.

Based on browsing older docs, looks like "New in version 2.3." should be
added to its docs.

----------
assignee: georg.brandl
components: Documentation
messages: 75327
nosy: georg.brandl, scop
severity: normal
status: open
title: tempfile.gettempdir() availability not documented
versions: Python 2.6

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

From report at bugs.python.org  Thu Oct 30 01:08:01 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 30 Oct 2008 00:08:01 +0000
Subject: [New-bugs-announce] [issue4233] open(0,
	closefd=False) prints 3 warnings
In-Reply-To: <1225325281.06.0.202625450166.issue4233@psf.upfronthosting.co.za>
Message-ID: <1225325281.06.0.202625450166.issue4233@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

This happens with a recent py3k build:

>>> x = open(0, closefd=False)
>>> del x
C:\dev\python\py3k\lib\io.py:1461: RuntimeWarning: Trying to close 
unclosable fd!
  self.buffer.close()
C:\dev\python\py3k\lib\io.py:389: RuntimeWarning: Trying to close 
unclosable fd!
  self.close()
__main__:1: RuntimeWarning: Trying to close unclosable fd!

Also, there are no unit test for closefd.

----------
components: Interpreter Core
messages: 75337
nosy: amaury.forgeotdarc
priority: critical
severity: normal
status: open
title: open(0, closefd=False) prints 3 warnings
versions: Python 3.0

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

From report at bugs.python.org  Thu Oct 30 01:17:49 2008
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 30 Oct 2008 00:17:49 +0000
Subject: [New-bugs-announce] [issue4234] bin missing from documentation
In-Reply-To: <1225325869.41.0.586364126902.issue4234@psf.upfronthosting.co.za>
Message-ID: <1225325869.41.0.586364126902.issue4234@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

Py3.0 has

bin(x)
Convert an integer number to a binary string. The result is a valid
Python expression. If x is not a Python int object, it has to define an
__index__() method that returns an integer. 

Py2.6 doesn't document builtin bin.

----------
assignee: georg.brandl
components: Documentation
messages: 75340
nosy: georg.brandl, v+python
severity: normal
status: open
title: bin missing from documentation
versions: Python 2.6

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

From report at bugs.python.org  Thu Oct 30 01:36:36 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 30 Oct 2008 00:36:36 +0000
Subject: [New-bugs-announce] [issue4235] Crash when iImporting a builtin
	module crashes
In-Reply-To: <1225326996.63.0.504612324764.issue4235@psf.upfronthosting.co.za>
Message-ID: <1225326996.63.0.504612324764.issue4235@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

Some object deallocator (file_dealloc) sometimes call PyErr_WarnEx.
This can happen on interpreter shutdown.
But this function may try to

----------
messages: 75341
nosy: amaury.forgeotdarc
severity: normal
status: open
title: Crash when iImporting a builtin module crashes

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

From report at bugs.python.org  Thu Oct 30 01:57:46 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 30 Oct 2008 00:57:46 +0000
Subject: [New-bugs-announce] [issue4236] Crash when importing builtin module
	during interpreter shutdown
In-Reply-To: <1225328266.56.0.143062114726.issue4236@psf.upfronthosting.co.za>
Message-ID: <1225328266.56.0.143062114726.issue4236@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

The following interactive session crashes the interpreter on shutdown:

>>> class C:
...   def __del__(self):
...      import warnings
...
>>> C()
<__main__.C object at 0x00C29D58>
>>> ^Z
Fatal Python error: Interpreter not initialized (version mismatch?)


This problem actually happens with the file object, which can call PyErr_WarnEx when it 
is deallocated and closed, see example in issue4226.
This "Fatal" message is new in 3.0. If I ignore it all seems correct, and the module is 
correctly imported.

----------
messages: 75344
nosy: amaury.forgeotdarc
priority: release blocker
severity: normal
status: open
title: Crash when importing builtin module during interpreter shutdown
versions: Python 3.0

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

From report at bugs.python.org  Thu Oct 30 02:02:18 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 30 Oct 2008 01:02:18 +0000
Subject: [New-bugs-announce] [issue4237] io.FileIO('foo',
	'rt') prints a RuntimeWarning
In-Reply-To: <1225328538.91.0.279296861257.issue4237@psf.upfronthosting.co.za>
Message-ID: <1225328538.91.0.279296861257.issue4237@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

>>> import io
>>> io.FileIO('foo', 'rt')
__main__:1: RuntimeWarning: Trying to close unclosable fd!
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid mode: rt

The ValueError is expected, but the warning is not.
This happens on file deallocation: the file object is in an invalid 
state.

----------
messages: 75346
nosy: amaury.forgeotdarc
severity: normal
status: open
title: io.FileIO('foo', 'rt') prints a RuntimeWarning
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Thu Oct 30 06:18:45 2008
From: report at bugs.python.org (Eric Gillespie)
Date: Thu, 30 Oct 2008 05:18:45 +0000
Subject: [New-bugs-announce] [issue4238] BSD support for
	multiprocessing.cpu_count
In-Reply-To: <1225343925.21.0.735322419857.issue4238@psf.upfronthosting.co.za>
Message-ID: <1225343925.21.0.735322419857.issue4238@psf.upfronthosting.co.za>


New submission from Eric Gillespie <epg at pretzelnet.org>:

Tested on NetBSD, but should work on any; sysctl goes back to 4.4BSD.

----------
components: Library (Lib)
files: diff
messages: 75353
nosy: epg
severity: normal
status: open
title: BSD support for multiprocessing.cpu_count
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11907/diff

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

From report at bugs.python.org  Thu Oct 30 06:29:47 2008
From: report at bugs.python.org (Matt Johnston)
Date: Thu, 30 Oct 2008 05:29:47 +0000
Subject: [New-bugs-announce] [issue4239] Email example should use
	SMTP.quit() rather than SMTP.close()
In-Reply-To: <1225344587.11.0.0184336607447.issue4239@psf.upfronthosting.co.za>
Message-ID: <1225344587.11.0.0184336607447.issue4239@psf.upfronthosting.co.za>


New submission from Matt Johnston <matt at ucc.asn.au>:

The email module example has "s.close()", while the smtplib docs say to
use .quit()

The latter is probably correct?

----------
assignee: georg.brandl
components: Documentation
messages: 75354
nosy: georg.brandl, matt
severity: normal
status: open
title: Email example should use SMTP.quit() rather than SMTP.close()
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Oct 30 09:13:01 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 30 Oct 2008 08:13:01 +0000
Subject: [New-bugs-announce] [issue4240] parasite form feed character in
	email.mime.text
In-Reply-To: <1225354381.34.0.206878201002.issue4240@psf.upfronthosting.co.za>
Message-ID: <1225354381.34.0.206878201002.issue4240@psf.upfronthosting.co.za>


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

Hi, 

There's a parasite form feed character in email/mime/text.py 
(as well in python 2.4 and 2.5)

I caught that under vim (^L), it is located line 12 in the file,
the line before the class definition starts

----------
components: Library (Lib)
messages: 75356
nosy: tarek
severity: normal
status: open
title: parasite form feed character in email.mime.text
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu Oct 30 12:52:05 2008
From: report at bugs.python.org (=?utf-8?q?Eino_M=C3=A4kitalo?=)
Date: Thu, 30 Oct 2008 11:52:05 +0000
Subject: [New-bugs-announce] [issue4241] zipfile.py -> is_zipfile leaves
	file open when error
In-Reply-To: <1225367525.69.0.93727529387.issue4241@psf.upfronthosting.co.za>
Message-ID: <1225367525.69.0.93727529387.issue4241@psf.upfronthosting.co.za>


New submission from Eino M?kitalo <eino.makitalo at netitbe.fi>:

Very simple error.
If is_zipfile crashes when checking is_zipfile if zipfile is corrupted
or not at all zip. It leaves file open and prevents later to remove file
etc... Maybe it's corrected in next versions

Old code: zipfile...
  line 86:  endrec = _EndRecData(fpin)
  line 87:  fpin.close


My simple corrections to cope with this
        try:
            endrec = _EndRecData(fpin)
        finally:
            fpin.close()

----------
components: Library (Lib)
messages: 75368
nosy: eino
severity: normal
status: open
title: zipfile.py -> is_zipfile leaves file open when error
type: crash
versions: Python 2.5

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

From report at bugs.python.org  Thu Oct 30 18:03:00 2008
From: report at bugs.python.org (Armin Rigo)
Date: Thu, 30 Oct 2008 17:03:00 +0000
Subject: [New-bugs-announce] [issue4242] Classify language vs. impl-detail
	tests, step 1
In-Reply-To: <1225386180.53.0.475585271298.issue4242@psf.upfronthosting.co.za>
Message-ID: <1225386180.53.0.475585271298.issue4242@psf.upfronthosting.co.za>


New submission from Armin Rigo <arigo at users.sourceforge.net>:

This patch contains a first step towards classifying CPython tests into
language tests and implementation-details tests.  The patch is against
the 2.7 trunk's test_descr.py.  It is derived from a similar patch that
we wrote for the 2.5's test_descr.py in order to make it pass on PyPy.

The main new feature introduced here is a couple of helpers in
test_support - see comments and docstrings in the patch.  The main ones
are "check_impl_detail", which is a flag which is False on non-CPython
hosts; and "impl_detail", a decorator to skip whole functions based on
the "check_impl_detail" flag.

If this patch is accepted, then we plan to port many more of PyPy's
patches for core tests, as a step towards helping non-CPython
implementations to obtain a good test suite.

----------
components: Tests
files: test-impl-details.diff
keywords: patch, patch
messages: 75373
nosy: arigo, cfbolz
severity: normal
status: open
title: Classify language vs. impl-detail tests, step 1
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file11910/test-impl-details.diff

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

From report at bugs.python.org  Thu Oct 30 18:48:25 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 30 Oct 2008 17:48:25 +0000
Subject: [New-bugs-announce] [issue4243] has_key doc could be clearer
In-Reply-To: <1225388905.15.0.305323271668.issue4243@psf.upfronthosting.co.za>
Message-ID: <1225388905.15.0.305323271668.issue4243@psf.upfronthosting.co.za>


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

2.6 lib ref builtin types, mappings, has_key doc now says
"dict.has_key(key) is equivalent to key in d, but deprecated."
Posters on c.l.p found this confusing.  Which is deprecated?
I agree that this could be confusing to a beginner.

D'Arcy J.M. Cain suggests
"dict.has_key(key) is deprecated.  Use "key in dict" instead."
Or "Use the replacement ..."
Or "Use the new version ..."

----------
assignee: georg.brandl
components: Documentation
messages: 75374
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: has_key doc could be clearer
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri Oct 31 14:32:40 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 31 Oct 2008 13:32:40 +0000
Subject: [New-bugs-announce] [issue4244] ihooks incompatible with
	absolute_import feature
In-Reply-To: <1225459960.12.0.259014417715.issue4244@psf.upfronthosting.co.za>
Message-ID: <1225459960.12.0.259014417715.issue4244@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

The __import__ function ihooks installs has a signature which is
incompatible with the real __import__ function, breaking some things
when ihooks is in use:

exarkun at charm:~$ python2.5
Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ihooks
>>> ihooks.install()
>>> from __future__ import absolute_import
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: import_module() takes at most 5 arguments (6 given)
>>>

----------
components: Interpreter Core, Library (Lib)
messages: 75414
nosy: exarkun
severity: normal
status: open
title: ihooks incompatible with absolute_import feature
type: behavior
versions: Python 2.5, Python 2.5.3, Python 2.6

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

From report at bugs.python.org  Fri Oct 31 18:03:34 2008
From: report at bugs.python.org (Michael Hoffman)
Date: Fri, 31 Oct 2008 17:03:34 +0000
Subject: [New-bugs-announce] [issue4245] threading documentation: reorder
	sections
In-Reply-To: <1225472614.88.0.0607016795949.issue4245@psf.upfronthosting.co.za>
Message-ID: <1225472614.88.0.0607016795949.issue4245@psf.upfronthosting.co.za>


New submission from Michael Hoffman <michaelfilter.57405889 at bloglines.com>:

It is somewhat confusing that the meat of the threading module, the
Thread object itself, is so far down in the documentation. It should be
the first  section after the module functions and objects.

http://docs.python.org/library/threading.html

----------
assignee: georg.brandl
components: Documentation
messages: 75422
nosy: georg.brandl, hoffman
severity: normal
status: open
title: threading documentation: reorder sections

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