From report at bugs.python.org  Sun Nov  1 00:14:49 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 31 Oct 2009 23:14:49 +0000
Subject: [issue1006238] cross compile patch
Message-ID: <1257030889.5.0.628185203011.issue1006238@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Documenting the parameters needed to avoid all AC_TRY_RUNs is a good first  
step for any that are not obvious how to convert from AC_TRY_RUN into 
something else.

----------

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

From report at bugs.python.org  Sun Nov  1 00:42:03 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Oct 2009 23:42:03 +0000
Subject: [issue6896] Intermittent failures in test_mailbox
In-Reply-To: <1252779314.23.0.231704147278.issue6896@psf.upfronthosting.co.za>
Message-ID: <1257032523.52.0.900384659073.issue6896@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ezio, could you give a try to the following patch?

----------
keywords: +patch
Added file: http://bugs.python.org/file15243/test_mailbox.patch

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

From report at bugs.python.org  Sun Nov  1 00:56:16 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Oct 2009 23:56:16 +0000
Subject: [issue6896] Intermittent failures in test_mailbox
In-Reply-To: <1252779314.23.0.231704147278.issue6896@psf.upfronthosting.co.za>
Message-ID: <1257033376.88.0.847802588391.issue6896@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +r.david.murray

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

From report at bugs.python.org  Sun Nov  1 01:14:09 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Nov 2009 00:14:09 +0000
Subject: [issue6896] Intermittent failures in test_mailbox
In-Reply-To: <1252779314.23.0.231704147278.issue6896@psf.upfronthosting.co.za>
Message-ID: <1257034449.49.0.753237113221.issue6896@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Another possible explanation is that the logic for computing
Maildir._last_time is wrong. It should be computed before refreshing the
internal cache, not after. Here is a patch.

----------
Added file: http://bugs.python.org/file15244/test_mailbox2.patch

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

From report at bugs.python.org  Sun Nov  1 02:07:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Nov 2009 01:07:10 +0000
Subject: [issue6896] Intermittent failures in test_mailbox
In-Reply-To: <1252779314.23.0.231704147278.issue6896@psf.upfronthosting.co.za>
Message-ID: <1257037630.86.0.378895180302.issue6896@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

According to testers, both patches fail at addressing the issue.

----------

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

From report at bugs.python.org  Sun Nov  1 02:07:17 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Nov 2009 01:07:17 +0000
Subject: [issue6896] Intermittent failures in test_mailbox
In-Reply-To: <1252779314.23.0.231704147278.issue6896@psf.upfronthosting.co.za>
Message-ID: <1257037637.4.0.887158611493.issue6896@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file15243/test_mailbox.patch

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

From report at bugs.python.org  Sun Nov  1 02:07:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Nov 2009 01:07:20 +0000
Subject: [issue6896] Intermittent failures in test_mailbox
In-Reply-To: <1252779314.23.0.231704147278.issue6896@psf.upfronthosting.co.za>
Message-ID: <1257037640.73.0.17347845529.issue6896@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file15244/test_mailbox2.patch

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

From report at bugs.python.org  Sun Nov  1 02:23:21 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 01 Nov 2009 01:23:21 +0000
Subject: [issue7195] Value error 'path is on drive c: start on drive d:' in
	os.path.relpath
In-Reply-To: <1256333963.61.0.85026079779.issue7195@psf.upfronthosting.co.za>
Message-ID: <1257038601.35.0.591408009858.issue7195@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

os.relpath *does* give you a relative path between two directories.

The problem you are encountering is that, on Windows, a relative path
doesn't even *exist* if the two directories are on different drives
(which is exactly what the error message says).

----------

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

From report at bugs.python.org  Sun Nov  1 03:01:24 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 01 Nov 2009 02:01:24 +0000
Subject: [issue6896] Intermittent failures in test_mailbox
In-Reply-To: <1252779314.23.0.231704147278.issue6896@psf.upfronthosting.co.za>
Message-ID: <1257040884.71.0.353955482214.issue6896@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I hacked mailbox.py so that a _toc refresh is always done and ran the
tests in a loop, and did not get a failure in 30+ runs, whereas without
that hack I would get failures almost every run.  So I think Antoine is
on the right track.

----------

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

From report at bugs.python.org  Sun Nov  1 05:45:49 2009
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Sun, 01 Nov 2009 04:45:49 +0000
Subject: [issue7245] better Ctrl-C support in pdb (program can be resumed)
In-Reply-To: <1257017877.16.0.972733875092.issue7245@psf.upfronthosting.co.za>
Message-ID: <1257050749.79.0.183310178201.issue7245@psf.upfronthosting.co.za>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

It is better for this functionality to be added in "Cmd" module as that
will benefit all users of that module. Please see bug #1294 which has a
patch for this purpose. It would be nice if you can test with that patch
and see if pdb works as you expected.

----------
nosy: +draghuram

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

From report at bugs.python.org  Sun Nov  1 10:32:55 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 01 Nov 2009 09:32:55 +0000
Subject: [issue7244] itertools.zip_longest behaves strangely with an iterable
	class
In-Reply-To: <1256980079.18.0.534636064924.issue7244@psf.upfronthosting.co.za>
Message-ID: <1257067975.68.0.794597746187.issue7244@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I created the patch to improve test which was checked in r76004. This
patch checks if correct elements are returned even when RuntimeError is
raised. Could you take a look?

----------
Added file: http://bugs.python.org/file15245/improve_test_itertools.patch

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

From report at bugs.python.org  Sun Nov  1 10:37:41 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 01 Nov 2009 09:37:41 +0000
Subject: [issue7244] itertools.zip_longest behaves strangely with an iterable
	class
In-Reply-To: <1256980079.18.0.534636064924.issue7244@psf.upfronthosting.co.za>
Message-ID: <1257068261.94.0.663855582249.issue7244@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

> correct elements are returned even when RuntimeError is
raised.

Or maybe it is not guaranteed. :-)

----------

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

From report at bugs.python.org  Sun Nov  1 13:50:46 2009
From: report at bugs.python.org (Mike Frysinger)
Date: Sun, 01 Nov 2009 12:50:46 +0000
Subject: [issue1006238] cross compile patch
Message-ID: <1257079846.68.0.208150856736.issue1006238@psf.upfronthosting.co.za>


Mike Frysinger <vapier at users.sourceforge.net> added the comment:

AC_TRY_RUN is already documented:
http://www.gnu.org/software/autoconf/manual/html_node/Obsolete-Macros.html#index-AC_005fTRY_005fRUN-1992

there are a bunch of distros out there (like OE and Gentoo) that have
been maintaining cross-compile patches for python.  i'm pretty sure the
stuff in Gentoo works for 2.6.x, but i havent tried 3.1.x yet.

ive given up on pushing to upstream as this bug (among others)) shows
that such attempts go nowhere

----------

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

From report at bugs.python.org  Sun Nov  1 13:52:07 2009
From: report at bugs.python.org (ali)
Date: Sun, 01 Nov 2009 12:52:07 +0000
Subject: [issue7217] IDLE Subprocess Startup Error
In-Reply-To: <1256630225.32.0.706380843912.issue7217@psf.upfronthosting.co.za>
Message-ID: <1257079927.16.0.873430435141.issue7217@psf.upfronthosting.co.za>


ali <mr.dalba at gmail.com> added the comment:

?

----------

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

From report at bugs.python.org  Sun Nov  1 15:50:26 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Nov 2009 14:50:26 +0000
Subject: [issue6896] Intermittent failures in test_mailbox
In-Reply-To: <1252779314.23.0.231704147278.issue6896@psf.upfronthosting.co.za>
Message-ID: <1257087026.3.0.447601386449.issue6896@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The explanation seems to be that some systems (including RDM's buildbot)
have slightly bizarre mtime behaviour:

$ date && python -c 'import os; os.link("setup.py", "t/c")' && stat t &&
date
Sun Nov  1 09:49:04 EST 2009
  File: `t'
  Size: 144       	Blocks: 0          IO Block: 4096   directory
Device: 811h/2065d	Inode: 223152      Links: 2
Access: (0755/drwxr-xr-x)  Uid: ( 1001/  pitrou)   Gid: ( 1005/  pitrou)
Access: 2009-11-01 09:10:11.000000000 -0500
Modify: 2009-11-01 09:49:03.000000000 -0500
Change: 2009-11-01 09:49:03.000000000 -0500
Sun Nov  1 09:49:04 EST 2009


As you see, the mtime of the directory is set a full one second before
the date at which its contents are modified.
I guess the only safe solution is to explicitly flush the internal cache
when we do any modifications.

----------

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

From report at bugs.python.org  Sun Nov  1 16:12:13 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Nov 2009 15:12:13 +0000
Subject: [issue6896] Intermittent failures in test_mailbox
In-Reply-To: <1252779314.23.0.231704147278.issue6896@psf.upfronthosting.co.za>
Message-ID: <1257088333.88.0.857089988138.issue6896@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, here is a patch which seems to fix the problem reliably on RDM's
buildbot. Ezio, can you give it a try?

----------
Added file: http://bugs.python.org/file15246/maildir.patch

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

From report at bugs.python.org  Sun Nov  1 16:31:29 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Nov 2009 15:31:29 +0000
Subject: [issue6896] Intermittent failures in test_mailbox
In-Reply-To: <1252779314.23.0.231704147278.issue6896@psf.upfronthosting.co.za>
Message-ID: <1257089489.3.0.246655720372.issue6896@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

PS: this is the kind of traces I had when running TestMaildir on David's
buildbot:

at 1257086460.18, linking/renaming ... mtime of
'/home/pitrou/trunk/@test_23145_tmp/new' is now 1257086459.0
at 1257086460.21, linking/renaming ... mtime of
'/home/pitrou/trunk/@test_23145_tmp/new' is now 1257086459.0
at 1257086460.24, linking/renaming ... mtime of
'/home/pitrou/trunk/@test_23145_tmp/new' is now 1257086459.0
at 1257086460.27, linking/renaming ... mtime of
'/home/pitrou/trunk/@test_23145_tmp/new' is now 1257086459.0
at 1257086460.3, linking/renaming ... mtime of
'/home/pitrou/trunk/@test_23145_tmp/new' is now 1257086459.0
at 1257086460.33, linking/renaming ... mtime of
'/home/pitrou/trunk/@test_23145_tmp/new' is now 1257086459.0
at 1257086460.36, linking/renaming ... mtime of
'/home/pitrou/trunk/@test_23145_tmp/new' is now 1257086460.0
at 1257086460.38, linking/renaming ... mtime of
'/home/pitrou/trunk/@test_23145_tmp/new' is now 1257086460.0
at 1257086460.4, linking/renaming ... mtime of
'/home/pitrou/trunk/@test_23145_tmp/new' is now 1257086460.0


As you see, the mtime is set to 1257086459 even when time.time() returns
1257086460.00 and higher, and it's only set to 1257086460 when
time.time() reaches 1257086460.36.

----------

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

From report at bugs.python.org  Sun Nov  1 17:23:07 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Nov 2009 16:23:07 +0000
Subject: [issue6748] test_debuglevel from test_telnetlib.py fails
In-Reply-To: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
Message-ID: <1257092587.09.0.593938794226.issue6748@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Please note that the Windows buildbot shows another error:

======================================================================
ERROR: test_debuglevel (test.test_telnetlib.OptionTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"E:\cygwin\home\db3l\buildarea\3.1.bolen-windows\build\lib\test\test_telnetlib.py",
line 409, in test_debuglevel
    self._test_debuglevel([a, EOF_sigil], b)
  File
"E:\cygwin\home\db3l\buildarea\3.1.bolen-windows\build\lib\test\test_telnetlib.py",
line 389, in _test_debuglevel
    txt = telnet.read_all()
  File
"E:\cygwin\home\db3l\buildarea\3.1.bolen-windows\build\lib\telnetlib.py", line
325, in read_all
    self.fill_rawq()
  File
"E:\cygwin\home\db3l\buildarea\3.1.bolen-windows\build\lib\telnetlib.py", line
516, in fill_rawq
    buf = self.sock.recv(50)
socket.error: [Errno 10053] An established connection was aborted by the
software in your host machine


According to a quick search on the Web, 10053 under Windows would be for
ECONNABORTED. Bazaar apparently faced the same issue:

https://lists.ubuntu.com/archives/bazaar/2006q4/020035.html

----------

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

From report at bugs.python.org  Sun Nov  1 17:46:28 2009
From: report at bugs.python.org (Avihu Turzion)
Date: Sun, 01 Nov 2009 16:46:28 +0000
Subject: [issue7246] getpass crashes when several returns are in stdin before
	getpass was called
In-Reply-To: <1257093988.16.0.063739997235.issue7246@psf.upfronthosting.co.za>
Message-ID: <1257093988.16.0.063739997235.issue7246@psf.upfronthosting.co.za>


New submission from Avihu Turzion <avihu at turzion.com>:

When I have the following code:

blah.py
=======

import getpass
nothing = getpass.getpass("blah:")

And I run it like so:

>>> sleep 5
./blah.py <return>
<return>

(I write the ./blah.py and returns while the sleep occurs)

I get the following stack-trace:

Traceback (most recent call last):
  File "./xuy.py", line 5, in <module>
    nothing = getpass.getpass("XUY:")
  File "/usr/local/lib/python2.6/getpass.py", line 81, in unix_getpass
    stream.write('\n')
IOError: [Errno 29] Illegal seek
close failed in file object destructor:
IOError: [Errno 29] Illegal seek

This error occurs only when getpass is called with 2 or more returns in 
the buffer. One return will not reveal the problem.

Running this code with strace shows clearly that the seek problem is 
because that for return in the buffer it tries to seek back. 2 returns 
will cause it to seek -2. 7 returns will cause it to seek -7.

This problem was introduced in python 2.6, and is maintained throughout 
the minor releases of python 2.6 - 2.6.4. It doesn't appear in python 
2.5 and before, and it doesn't appear in python 3.

Doing sys.stdin.flush() doesn't resolve this issue.

----------
components: IO
messages: 94791
nosy: avihu
severity: normal
status: open
title: getpass crashes when several returns are in stdin before getpass was called
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Sun Nov  1 18:35:42 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 01 Nov 2009 17:35:42 +0000
Subject: [issue1006238] cross compile patch
Message-ID: <1257096942.86.0.992444694543.issue1006238@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Removing a toxic person from the cc list.  Mike, please go harm some other 
all volunteer project.

----------
nosy:  -vapier

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

From report at bugs.python.org  Sun Nov  1 18:41:03 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Nov 2009 17:41:03 +0000
Subject: [issue7244] itertools.zip_longest behaves strangely with an iterable
	class
In-Reply-To: <1256980079.18.0.534636064924.issue7244@psf.upfronthosting.co.za>
Message-ID: <1257097263.44.0.512552894292.issue7244@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Already checked-in a fix for Py2.6 in r76004.
Will forward port shortly.

----------

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

From report at bugs.python.org  Sun Nov  1 18:47:05 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 01 Nov 2009 17:47:05 +0000
Subject: [issue7246] getpass raises IOError when several returns are in stdin
	before getpass was called
In-Reply-To: <1257093988.16.0.063739997235.issue7246@psf.upfronthosting.co.za>
Message-ID: <1257097625.32.0.12818122721.issue7246@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
components: +Library (Lib)
nosy: +gregory.p.smith
priority:  -> normal
title: getpass crashes when several returns are in stdin before getpass was called -> getpass raises IOError when several returns are in stdin before getpass was called
type: crash -> behavior

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

From report at bugs.python.org  Sun Nov  1 18:52:00 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Nov 2009 17:52:00 +0000
Subject: [issue7244] itertools.zip_longest behaves strangely with an iterable
	class
In-Reply-To: <1256980079.18.0.534636064924.issue7244@psf.upfronthosting.co.za>
Message-ID: <1257097920.55.0.442182469151.issue7244@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Will take a look at your patch.
Am also still doing work to complete r76004
for the case where the refcnt > 1.

----------

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

From report at bugs.python.org  Sun Nov  1 18:52:55 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 01 Nov 2009 17:52:55 +0000
Subject: [issue7246] getpass raises IOError when several returns are in stdin
	before getpass was called
In-Reply-To: <1257093988.16.0.063739997235.issue7246@psf.upfronthosting.co.za>
Message-ID: <1257097975.87.0.190349236115.issue7246@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

am unable to duplicate this behavior on Linux or OS X using python 2.6.

What platform did you see the problem on?

that said, can you apply the following patch to your getpass.py and see if 
it helps at all?

http://svn.python.org/view/python/trunk/Lib/getpass.py?
r1=74860&r2=76000&pathrev=76000

----------

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

From report at bugs.python.org  Sun Nov  1 18:54:07 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 01 Nov 2009 17:54:07 +0000
Subject: [issue7246] getpass raises IOError when several returns are in stdin
	before getpass was called
In-Reply-To: <1257093988.16.0.063739997235.issue7246@psf.upfronthosting.co.za>
Message-ID: <1257098047.98.0.796804159612.issue7246@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

ah i misread your example.  the following works to reproduce it:


Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import time, getpass
>>> time.sleep(5)
getpass.getpass()  


>>> getpass.getpass()
Password: Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/getpass.py", line 81, in unix_getpass
    stream.write('\n')
IOError: [Errno 29] Illegal seek

----------

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

From report at bugs.python.org  Sun Nov  1 18:55:02 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 01 Nov 2009 17:55:02 +0000
Subject: [issue7246] getpass raises IOError when several returns are in stdin
	before getpass was called
In-Reply-To: <1257093988.16.0.063739997235.issue7246@psf.upfronthosting.co.za>
Message-ID: <1257098102.8.0.0142071361493.issue7246@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

and the r76000 patch does not fix it.  investigating.

----------

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

From report at bugs.python.org  Sun Nov  1 19:31:42 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 01 Nov 2009 18:31:42 +0000
Subject: [issue7246] getpass raises IOError when several returns are in stdin
	before getpass was called
In-Reply-To: <1257093988.16.0.063739997235.issue7246@psf.upfronthosting.co.za>
Message-ID: <1257100302.33.0.788414499408.issue7246@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

change that.  it looks like r76000 in trunk already fixes this.  i was 
using an old build when i tried earlier.

merged into release26-maint in r76015.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sun Nov  1 19:46:27 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Nov 2009 18:46:27 +0000
Subject: [issue7244] itertools.zip_longest behaves strangely with an iterable
	class
In-Reply-To: <1256980079.18.0.534636064924.issue7244@psf.upfronthosting.co.za>
Message-ID: <1257101187.63.0.712939479968.issue7244@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------

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

From report at bugs.python.org  Sun Nov  1 19:46:37 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Nov 2009 18:46:37 +0000
Subject: [issue7244] itertools.zip_longest behaves strangely with an iterable
	class
In-Reply-To: <1256980079.18.0.534636064924.issue7244@psf.upfronthosting.co.za>
Message-ID: <1257101197.76.0.180816398125.issue7244@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------

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

From report at bugs.python.org  Sun Nov  1 19:48:16 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Nov 2009 18:48:16 +0000
Subject: [issue7244] itertools.zip_longest behaves strangely with an iterable
	class
In-Reply-To: <1256980079.18.0.534636064924.issue7244@psf.upfronthosting.co.za>
Message-ID: <1257101296.97.0.434530117279.issue7244@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Added r76018 to use Hirokazu's test for the RuntimeError case and to
redirect stdout to a file for the StopIteration case.  Also, fixed-up
weird indentation in the C code.

----------

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

From report at bugs.python.org  Sun Nov  1 19:48:49 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 01 Nov 2009 18:48:49 +0000
Subject: [issue7208] Getpass echo's password to screen on 2.6,
	but not on 2.5 or 3.1
In-Reply-To: <1256567979.01.0.00205480055698.issue7208@psf.upfronthosting.co.za>
Message-ID: <1257101329.03.0.393714683616.issue7208@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

merged into release26-maint in r76015.  this patch also fixed issue7246.

py3k r76017
release31-maint r76019

----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 2.6, Python 2.7

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

From report at bugs.python.org  Sun Nov  1 20:20:06 2009
From: report at bugs.python.org (Tony Vroon)
Date: Sun, 01 Nov 2009 19:20:06 +0000
Subject: [issue7247] 2.6.4 fnctl test failure
In-Reply-To: <1257103206.04.0.134413608226.issue7247@psf.upfronthosting.co.za>
Message-ID: <1257103206.04.0.134413608226.issue7247@psf.upfronthosting.co.za>


New submission from Tony Vroon <tony at vroon.org>:

chainsaw at prometheus ~ $ python2.6 
/usr/lib64/python2.6/test/test_fcntl.py
struct.pack: 
'\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
test_fcntl_64_bit (__main__.TestFcntl) ... ERROR
test_fcntl_file_descriptor (__main__.TestFcntl) ... ok
test_fcntl_fileno (__main__.TestFcntl) ... Status from fcntl with 
O_NONBLOCK: 
0
String from fcntl with F_SETLKW: 
'\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
ok

======================================================================
ERROR: test_fcntl_64_bit (__main__.TestFcntl)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python2.6/test/test_fcntl.py", line 96, in 
test_fcntl_64_bit
    fcntl.fcntl(fd, cmd, flags)
IOError: [Errno 22] Invalid argument

----------------------------------------------------------------------
Ran 3 tests in 0.000s

FAILED (errors=1)
Traceback (most recent call last):
  File "/usr/lib64/python2.6/test/test_fcntl.py", line 105, in <module>
    test_main()
  File "/usr/lib64/python2.6/test/test_fcntl.py", line 102, in test_main
    run_unittest(TestFcntl)
  File "/usr/lib64/python2.6/test/test_support.py", line 724, in 
run_unittest
    _run_suite(suite)
  File "/usr/lib64/python2.6/test/test_support.py", line 707, in 
_run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "/usr/lib64/python2.6/test/test_fcntl.py", line 96, in 
test_fcntl_64_bit
    fcntl.fcntl(fd, cmd, flags)
IOError: [Errno 22] Invalid argument

----------
components: Tests
messages: 94801
nosy: Chainsaw
severity: normal
status: open
title: 2.6.4 fnctl test failure
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Nov  1 20:55:16 2009
From: report at bugs.python.org (Garrett Cooper)
Date: Sun, 01 Nov 2009 19:55:16 +0000
Subject: [issue1006238] cross compile patch
In-Reply-To: <1257079846.68.0.208150856736.issue1006238@psf.upfronthosting.co.za>
Message-ID: <364299f40911011155u727322dfwa4b4afdab7b36243@mail.gmail.com>


Garrett Cooper <yanegomi at gmail.com> added the comment:

On Sun, Nov 1, 2009 at 5:50 AM, Mike Frysinger <report at bugs.python.org> wrote:
>
> Mike Frysinger <vapier at users.sourceforge.net> added the comment:
>
> AC_TRY_RUN is already documented:
> http://www.gnu.org/software/autoconf/manual/html_node/Obsolete-Macros.html#index-AC_005fTRY_005fRUN-1992
>
> there are a bunch of distros out there (like OE and Gentoo) that have
> been maintaining cross-compile patches for python. ?i'm pretty sure the
> stuff in Gentoo works for 2.6.x, but i havent tried 3.1.x yet.
>
> ive given up on pushing to upstream as this bug (among others)) shows
> that such attempts go nowhere

Actually what Mike showed was helpful for me. I didn't realize that
the 3rd argument to AC_TRY_RUN was for Canadian cross, aka
cross-compiling.

My personal opinion on why past attempts have failed (and it's just my
opinion) is probably because:

1. The change set wasn't incremental, thus the diff was large, and the
checkin was rejected.
2. The patch was based on previous versions of python, which doesn't
help the current trunk, release-maint* branches, etc.

I'm more than happy to steal existing code (if possible :)..), but it
should be well designed so longterm maintenance can be eased, and the
cross-compile issue can be resolved in a correct manner.

It took me 2 months to rewrite the Makefile infrastructure for LTP --
this should be a lot simpler and less painful to resolve (in terms of
autotools input files, Makefile, etc). setup.py and distutils is
something that I need to defer to someone more seasoned in the python
internals (at least for mentoring) s.t. it can be resolved on all
branches.

First comes first, I'll propose some changes for cross-compilation
dealing with some of the AC_TRY_RUN tests -- there are some tests that
can be turned into preprocessor defines and/or AC_TRY_COMPILES [the
sizeof(pthread_t), etc], then I'll look at the other tests and propose
appropriate action for them.

If needed individuals in the python org. aren't aware of this work, it
probably should be brought to their attention sometime in the next
couple of weeks, because I need to make sure core team members are
aware of these changes so that they can get reviewed and checked into
the project in a timely manner (my group needs to upgrade from 2.4.2
to python 2.6.x in the next couple months; this is a stopgap item for
us because we use a cross-compilation environment).

All the best,
-Garrett

----------

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

From report at bugs.python.org  Sun Nov  1 21:30:05 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 01 Nov 2009 20:30:05 +0000
Subject: [issue1008086] socket.inet_aton returns 8 bytes on LP64 platforms
Message-ID: <1257107405.59.0.731109618008.issue1008086@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Fixed in release26-maint r76022.  This will appear in Python 2.6.5.

I'm leaving release30-maint alone as it is already in 3.1.

sorry for not making it into 2.6.3/2.6.4 despite the code being ready.  I 
should've set this as a release blocker.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sun Nov  1 21:37:15 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 01 Nov 2009 20:37:15 +0000
Subject: [issue6665] fnmatch fails on filenames containing \n character
In-Reply-To: <1249638559.7.0.0574356115412.issue6665@psf.upfronthosting.co.za>
Message-ID: <1257107835.63.0.0667883960168.issue6665@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

release26-maint r76023 to appear in Python 2.6.5.
release31-maint r76024 to appear in Python 3.1.2.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sun Nov  1 21:57:28 2009
From: report at bugs.python.org (Mike Frysinger)
Date: Sun, 01 Nov 2009 20:57:28 +0000
Subject: [issue1006238] cross compile patch
Message-ID: <1257109048.88.0.333193388822.issue1006238@psf.upfronthosting.co.za>


Mike Frysinger <vapier at users.sourceforge.net> added the comment:

Gregory: there's no need to be a dick.  i'm pointing out the obvious --
bugs have been open literally for *years* with zero assistance/feedback
from anyone who can actually get things merged.  people have posted
patches, but no one has said "xxx needs to be done in order to get
merged".  you havent posted anything here either (assuming you're
someone who can actually get things merged and not just comment in a
tracker).  if you can at least do something with trackers, you should
start by marking 1597850 as a dupe of this one.  or you can simply prove
my point by continuing to contribute nothing.

the basic required changes are simple -- fix the few autoconf tests. 
getting automatic cross-detection (building a host python/pygen
automatically) isnt nearly as important as long as people have a way to
tell the build system to use a different python/pgen for build purposes.
 last i looked, these simple changes were pretty trivial to move across
major versions of python.

i fixed the chflags specific check a long time ago (as i imagine others
have as well):
http://sources.gentoo.org/dev-lang/python/files/python-2.6-chflags-cross.patch

same goes for the printf %zd test:
http://sources.gentoo.org/dev-lang/python/files/python-2.5-cross-printf.patch

however, unless these trivial baby steps can be made, worrying about the
next step (properly cross-compiling modules and such) is a complete
waste of time as these require diving into the python-specific build
system which does see a lot of churn over versions.

----------
nosy: +vapier

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

From report at bugs.python.org  Sun Nov  1 22:04:17 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Nov 2009 21:04:17 +0000
Subject: [issue7244] itertools.zip_longest behaves strangely with an iterable
	class
In-Reply-To: <1256980079.18.0.534636064924.issue7244@psf.upfronthosting.co.za>
Message-ID: <1257109457.45.0.524009983434.issue7244@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Forward-ported in r76025 r76026 and r76027.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sun Nov  1 22:11:54 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 01 Nov 2009 21:11:54 +0000
Subject: [issue1115] Minor Change For Better cross compile
In-Reply-To: <1189061255.17.0.84912008961.issue1115@psf.upfronthosting.co.za>
Message-ID: <1257109914.96.0.450961388012.issue1115@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Thanks for the patch!

applied in trunk r76028/r76029.  py3k r76030/r76032

There are more of these, other bugs are open that should result in us 
cleaning them up.  see issue1006238 for example.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sun Nov  1 23:01:00 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 01 Nov 2009 22:01:00 +0000
Subject: [issue4698] Solaris buildbot failure on trunk in test_hostshot
In-Reply-To: <1229641134.61.0.646218726644.issue4698@psf.upfronthosting.co.za>
Message-ID: <1257112860.42.0.767818891912.issue4698@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This was apparently fixed some months ago with r69410.
Neil, would you mind backporting it to 2.6?

----------
assignee:  -> nascheme
nosy: +nascheme

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

From report at bugs.python.org  Sun Nov  1 23:30:14 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 01 Nov 2009 22:30:14 +0000
Subject: [issue7247] 2.6.4 fnctl test failure
In-Reply-To: <1257103206.04.0.134413608226.issue7247@psf.upfronthosting.co.za>
Message-ID: <1257114614.69.0.689805558088.issue7247@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Sun Nov  1 23:34:17 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 01 Nov 2009 22:34:17 +0000
Subject: [issue7247] test_fcntl_64_bit from test_fcntl.py fails in Python 2.6.4
In-Reply-To: <1257103206.04.0.134413608226.issue7247@psf.upfronthosting.co.za>
Message-ID: <1257114857.65.0.109391848591.issue7247@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
title: 2.6.4 fnctl test failure -> test_fcntl_64_bit from test_fcntl.py fails in Python 2.6.4

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

From report at bugs.python.org  Sun Nov  1 23:41:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Nov 2009 22:41:20 +0000
Subject: [issue7248] test_importlib uses a fixed name in /tmp
In-Reply-To: <1257115280.67.0.551284747455.issue7248@psf.upfronthosting.co.za>
Message-ID: <1257115280.67.0.551284747455.issue7248@psf.upfronthosting.co.za>


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

test_importlib uses fixed names in /tmp (e.g. /tmp/pkg), which will make
the tests fail is such files/dirs already exist and aren't writable by
the current user (which can happen if several users run the python test
suite...).

----------
assignee: brett.cannon
components: Library (Lib), Tests
messages: 94810
nosy: brett.cannon, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_importlib uses a fixed name in /tmp
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Nov  1 23:44:22 2009
From: report at bugs.python.org (Ilya Sandler)
Date: Sun, 01 Nov 2009 22:44:22 +0000
Subject: [issue7245] better Ctrl-C support in pdb (program can be resumed)
In-Reply-To: <1257017877.16.0.972733875092.issue7245@psf.upfronthosting.co.za>
Message-ID: <1257115462.75.0.282874132117.issue7245@psf.upfronthosting.co.za>


Ilya Sandler <ilya.sandler at gmail.com> added the comment:

No,I don't think patch in the issue #1294 addresses the problem which
I'm trying to solve.

I tried applying patch#1294, and Ctrl-C will still throws your debugger
into postmortem mode and I don't think you can change that by overriding
do_KeyboardInterrupt(): when do_KbdInterrupt() is called you cannot
resume execution (or at least I don't know any way of doing it).

My patch handles the SIGINT directly which allows it to set tracing and
resume the program immediately (and keyboardinterrupt is never raised)

I'll also add comments to patch#1294

----------

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

From report at bugs.python.org  Mon Nov  2 00:10:52 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 01 Nov 2009 23:10:52 +0000
Subject: [issue7248] test_importlib uses a fixed name in /tmp
In-Reply-To: <1257115280.67.0.551284747455.issue7248@psf.upfronthosting.co.za>
Message-ID: <1257117052.54.0.463149272611.issue7248@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Yeah, I should have used tempfile.mkdtemp().

----------

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

From report at bugs.python.org  Mon Nov  2 00:20:39 2009
From: report at bugs.python.org (Garrett Cooper)
Date: Sun, 01 Nov 2009 23:20:39 +0000
Subject: [issue1006238] cross compile patch
Message-ID: <1257117639.09.0.716788792303.issue1006238@psf.upfronthosting.co.za>


Garrett Cooper <yanegomi at gmail.com> added the comment:

Ok. Taking a look at trunk...

The following could be converted to AC_TRY_COMPILE statements for the
3rd AC_TRY_RUN tuple:

1. $ac_enable_profiling : 697
2. $ac_cv_no_strict_aliasing_ok : 921
3. $ac_cv_opt_olimit_ok : 1070
4. $ac_cv_olimit_ok : 1092
5. $ac_cv_pthread_is_default : 1126
6. $ac_cv_kpthread : 1163
7. $ac_cv_pthread : 1225
8. $ac_osx_32bit : 1569
9. $ac_cv_pthread_system_supported : 2229
10. $ac_cv_have_size_t_format : 3959

The following can just be converted to AC_TRY_COMPILE:
1. $ipv6 : 2278
2. $ac_cv_have_chflags : 2663
3. $ac_cv_have_lchflags : 2693

The following will need to be sorted out, as to what needs to be done
here, as they are legitimate runtime only tests:
1. $ac_cv_little_endian_double : 3249
2. $ac_cv_big_endian_double : 3271
3. $ac_cv_mixed_endian_double : 3299
4. $ac_cv_x87_double_rounding : 3354
5. $ac_cv_broken_sem_getvalue : 3395
6. $ac_cv_tanh_preserves_zero_sign : 3430
7. $ac_cv_wchar_t_signed : 3510
8. $ac_cv_rshift_extends_sign : 3597
9. $ac_cv_broken_nice : 3714
10. $ac_cv_broken_poll : 3735
11. $ac_cv_working_tzset : 3772

Taking a look at py3k, most of the offsets are the same -- some have
changed, but the only the test which doesn't exist in trunk is the
following:

1. $ac_cv_broken_mbstowcs : 3872

Again, this is a valid runtime test, so it needs to be sorted out what
should be done here with cross-compilation.

----------

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

From report at bugs.python.org  Mon Nov  2 02:01:22 2009
From: report at bugs.python.org (Neil Schemenauer)
Date: Mon, 02 Nov 2009 01:01:22 +0000
Subject: [issue4698] Solaris buildbot failure on trunk in test_hostshot
In-Reply-To: <1229641134.61.0.646218726644.issue4698@psf.upfronthosting.co.za>
Message-ID: <1257123682.32.0.818116731013.issue4698@psf.upfronthosting.co.za>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

I checked in the fix on the 2.6 branch.

----------

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

From report at bugs.python.org  Mon Nov  2 02:06:34 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Nov 2009 01:06:34 +0000
Subject: [issue6896] Intermittent failures in test_mailbox
In-Reply-To: <1252779314.23.0.231704147278.issue6896@psf.upfronthosting.co.za>
Message-ID: <1257123994.36.0.236425061565.issue6896@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ezio indicated that the patch suppressed all failures for him, so I
committed it on trunk.

----------

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

From report at bugs.python.org  Mon Nov  2 03:03:55 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 02 Nov 2009 02:03:55 +0000
Subject: [issue1006238] cross compile patch
Message-ID: <1257127435.14.0.156126683962.issue1006238@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

these two have been merged and applied to trunk.

"""
i fixed the chflags specific check a long time ago (as i imagine others
have as well):
http://sources.gentoo.org/dev-lang/python/files/python-2.6-chflags-
cross.patch

same goes for the printf %zd test:
http://sources.gentoo.org/dev-lang/python/files/python-2.5-cross-
printf.patch
"""

----------

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

From report at bugs.python.org  Mon Nov  2 04:20:19 2009
From: report at bugs.python.org (Mike Frysinger)
Date: Mon, 02 Nov 2009 03:20:19 +0000
Subject: [issue1006238] cross compile patch
Message-ID: <1257132019.96.0.862251731339.issue1006238@psf.upfronthosting.co.za>


Mike Frysinger <vapier at users.sourceforge.net> added the comment:

the chflags is specifically documented as needing a runtime test:
# On Tru64, chflags seems to be present, but calling it will
# exit Python

which is why i left the default of AC_TRY_RUN but cross-compile falls
back to a simple link test.  btw, a compile test is not valid when
trying to see if a function exists.  you'll get a successful compile
(and warning about implicit function), but no error because you didnt
finally link the object with the undefined reference.

somewhat similar are the compiler checks (profile/pthread/alias/etc...).
 some compilers do different things when linking and compiling (like gcc
and -pthread), so sticking to a LINK in the fallback of the RUN is
better, although not always perfect.  some flags are accepted/ignored by
compilers and issue only warnings about the unknown flags, not errors. 
but this issue probably isnt worth worrying about considering the code
in there today suffers from this edge case (and if no one is
complaining, then forget about it).

in terms of making sure all AC_TRY_RUN's have cross-compile fallbacks, i
only worried about the ones that actually get exercised.  the two i
posted fixes for are the only ones ive seen people (and myself) actively
hit.

the ipv6 should def have a LINK fallback, and it should try using
in6addr_any as that is often an exported symbol (which is missing when
ipv6 doesnt exist).

the double endian checks could easily be made into a compile test with a
creative grep.  pick a double value that expands into a funky ascii
string and then grep the object file for a match.  otherwise, a char
swapped ascii string indicates it's big endian.

the wchar/rshift signed tests can be made into a compile-only test by
creative use of arrays (like autoconf does now with compile sizeof() tests).
  main() { char foo[(((wchar_t) -1) < ((wchar_t) 0)) ? 1 : -1]; }
compilers will portably abort when array size is negative, and this
expression should be a constant.

i dont think any of the "broken" ones need to be sorted out as they
already have cross-compile fall backs and there isnt much to be done in
figuring out if the run time env is broken.

thanks Greg for the commits !

----------

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

From report at bugs.python.org  Mon Nov  2 04:50:44 2009
From: report at bugs.python.org (Ryan Leslie)
Date: Mon, 02 Nov 2009 03:50:44 +0000
Subject: [issue7249] Consider allowing io.BytesIO sizes to be passed as 'long'
	in 2.6
In-Reply-To: <1257133844.49.0.793599813853.issue7249@psf.upfronthosting.co.za>
Message-ID: <1257133844.49.0.793599813853.issue7249@psf.upfronthosting.co.za>


New submission from Ryan Leslie <rylesny at gmail.com>:

py> StringIO.StringIO("foo").read(long(1))
'f'

py> io.BytesIO("foo").read(long(1))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: integer argument expected, got 'long'

This is known to cause problems when reading zip data from a BytesIO
object with zipfile. See this recent thread on comp.lang.python:

http://groups.google.com/group/comp.lang.python/browse_thread/thread/337c1b8a48e8acae/

----------
components: Library (Lib)
messages: 94818
nosy: ryles
severity: normal
status: open
title: Consider allowing io.BytesIO sizes to be passed as 'long' in 2.6
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Nov  2 07:22:20 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 02 Nov 2009 06:22:20 +0000
Subject: [issue1006238] cross compile patch
Message-ID: <1257142940.28.0.228927536241.issue1006238@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Mon Nov  2 07:47:35 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 02 Nov 2009 06:47:35 +0000
Subject: [issue6873] posix_lchown: possible overflow of uid, gid
In-Reply-To: <1252530083.88.0.0590368551001.issue6873@psf.upfronthosting.co.za>
Message-ID: <1257144455.57.0.459390876798.issue6873@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith

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

From report at bugs.python.org  Mon Nov  2 07:47:43 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 02 Nov 2009 06:47:43 +0000
Subject: [issue6873] posix_lchown: possible overflow of uid, gid
In-Reply-To: <1252530083.88.0.0590368551001.issue6873@psf.upfronthosting.co.za>
Message-ID: <1257144463.28.0.838950004062.issue6873@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
priority:  -> normal

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

From report at bugs.python.org  Mon Nov  2 08:14:07 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 02 Nov 2009 07:14:07 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1257146047.08.0.363071210269.issue1628484@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
nosy: +ronaldoussoren

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

From report at bugs.python.org  Mon Nov  2 08:34:05 2009
From: report at bugs.python.org (Brandon Bloom)
Date: Mon, 02 Nov 2009 07:34:05 +0000
Subject: [issue7250] wsgiref.handlers.CGIHandler caches os.environ,
	leaking info between requests
In-Reply-To: <1257147245.14.0.668660104401.issue7250@psf.upfronthosting.co.za>
Message-ID: <1257147245.14.0.668660104401.issue7250@psf.upfronthosting.co.za>


New submission from Brandon Bloom <snprbob86 at gmail.com>:

This issue came up while doing Google App Engine development. Apparently 
the default wsgi handler logic is to cache os.environ into os_environ at 
import time. This is reasonable behavior for wsgi, but when using cgi, 
this is a serious security hole which leaks information between requests.

See this related bug at GAE:
http://code.google.com/p/googleappengine/issues/detail?
id=2040&q=cookies%20dev_appserver.py&colspec=ID%20Type%20Status%20Priority
%20Stars%20Owner%20Summary%20Log%20Component

----------
components: Library (Lib)
messages: 94819
nosy: snprbob86
severity: normal
status: open
title: wsgiref.handlers.CGIHandler caches os.environ, leaking info between requests
type: security
versions: Python 2.5

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

From report at bugs.python.org  Mon Nov  2 09:31:14 2009
From: report at bugs.python.org (Zsolt Cserna)
Date: Mon, 02 Nov 2009 08:31:14 +0000
Subject: [issue7242] Forking in a thread raises RuntimeError
In-Reply-To: <1256900282.72.0.764098234436.issue7242@psf.upfronthosting.co.za>
Message-ID: <1257150674.86.0.326425446997.issue7242@psf.upfronthosting.co.za>


Zsolt Cserna <zsolt.cserna at morganstanley.com> added the comment:

I've tested it only on solaris 8, 32-bit.

----------

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

From report at bugs.python.org  Mon Nov  2 10:43:05 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 02 Nov 2009 09:43:05 +0000
Subject: [issue7251] Mark expected failures of test_math,
	test_cmath and test_round as such.
In-Reply-To: <1257154985.1.0.42933155819.issue7251@psf.upfronthosting.co.za>
Message-ID: <1257154985.1.0.42933155819.issue7251@psf.upfronthosting.co.za>


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

There are some buildbot failures due to platform-specific bugs that need
to be marked as expected failures, using the unittest.expectedFailure
decorator.  This may require reorganizing the tests slightly.

* tanh(-0.0) produces 0.0 instead of -0.0 on FreeBSD 6;  this causes
test_math and test_cmath to fail.  E.g.,

http://www.python.org/dev/buildbot/builders/x86%20FreeBSD%20trunk/builds/2741

* the libm round function on Debian alpha seems to be buggy;  this
causes test_round in test_builtin.py to fail.  E.g.,

http://www.python.org/dev/buildbot/builders/alpha%20Debian%20trunk/builds/30

----------
assignee: mark.dickinson
components: Tests
keywords: buildbot
messages: 94821
nosy: mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: Mark expected failures of test_math, test_cmath and test_round as such.
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Nov  2 10:44:51 2009
From: report at bugs.python.org (Zsolt Cserna)
Date: Mon, 02 Nov 2009 09:44:51 +0000
Subject: [issue7242] Forking in a thread raises RuntimeError
In-Reply-To: <1256900282.72.0.764098234436.issue7242@psf.upfronthosting.co.za>
Message-ID: <1257155091.42.0.368489006359.issue7242@psf.upfronthosting.co.za>


Zsolt Cserna <zsolt.cserna at morganstanley.com> added the comment:

solaris 10 x86, 32-bit, sun-studio 11 is ok (in this case the parent's
thread has thread_id=2 and the child inherits this id)
solaris 8 sparc4, 32-bit, sun-studio 11 is not working

So it seems it's independent from sun-cc but depends from the
architecture and/or the OS.

----------

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

From report at bugs.python.org  Mon Nov  2 10:47:09 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 02 Nov 2009 09:47:09 +0000
Subject: [issue7251] Mark expected failures of test_math,
	test_cmath and test_round as such.
In-Reply-To: <1257154985.1.0.42933155819.issue7251@psf.upfronthosting.co.za>
Message-ID: <1257155229.2.0.471215933145.issue7251@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Oops.  I meant 'platform' bugs, not 'platform-specific' bugs.  These are
not bugs in Python, but in the underlying C library.

----------

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

From report at bugs.python.org  Mon Nov  2 11:21:58 2009
From: report at bugs.python.org (Avihu Turzion)
Date: Mon, 02 Nov 2009 10:21:58 +0000
Subject: [issue7246] getpass raises IOError when several returns are in stdin
	before getpass was called
In-Reply-To: <1257093988.16.0.063739997235.issue7246@psf.upfronthosting.co.za>
Message-ID: <1257157318.31.0.893250296075.issue7246@psf.upfronthosting.co.za>


Avihu Turzion <avihu at turzion.com> added the comment:

Great. Thanks :)

----------

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

From report at bugs.python.org  Mon Nov  2 12:59:13 2009
From: report at bugs.python.org (djc)
Date: Mon, 02 Nov 2009 11:59:13 +0000
Subject: [issue7252] list().index() should provide better error reporting
In-Reply-To: <1257163153.85.0.398972946442.issue7252@psf.upfronthosting.co.za>
Message-ID: <1257163153.85.0.398972946442.issue7252@psf.upfronthosting.co.za>


New submission from djc <dirkjan at ochtman.nl>:

>>> a = 'b'
>>> [].index(a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: list.index(x): x not in list

This is suboptimal. IMO it would be much more useful if the ValueError
reported the actual value that wasn't in the list, like this:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: list.index('b'): 'b' not in list

The error in general doesn't really seem to fit in, repeating the code
but with a fake variable name in it. In real contexts, it's mostly just
repeating what's there on a previous line:

 File "/home/watt/src/dawkins/ttlib.py", line 86, in shift
   bits.append(SHIFTS.index(rest.split('_')[0]))
 ValueError: list.index(x): x not in list

So maybe just make it "'b' not in list"? Or do we really need a
reference to the index() method in there?

----------
components: Library (Lib)
messages: 94825
nosy: djc
severity: normal
status: open
title: list().index() should provide better error reporting
versions: Python 2.6

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

From report at bugs.python.org  Mon Nov  2 12:59:59 2009
From: report at bugs.python.org (djc)
Date: Mon, 02 Nov 2009 11:59:59 +0000
Subject: [issue7252] list().index() should provide better error reporting
In-Reply-To: <1257163153.85.0.398972946442.issue7252@psf.upfronthosting.co.za>
Message-ID: <1257163199.43.0.35842336146.issue7252@psf.upfronthosting.co.za>


djc <dirkjan at ochtman.nl> added the comment:

FWIW, quickly grepping through the raises of ValueErrors in the 2.6
stdlib doesn't bring up any other usage of repeat-with-fake-variable-x.

----------

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

From report at bugs.python.org  Mon Nov  2 13:23:15 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Nov 2009 12:23:15 +0000
Subject: [issue6896] Intermittent failures in test_mailbox
In-Reply-To: <1252779314.23.0.231704147278.issue6896@psf.upfronthosting.co.za>
Message-ID: <1257164595.84.0.030876327948.issue6896@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Now merged into py3k and 3.1, where it has solved the buildbot issues.
2.6 doesn't apply, since the caching scheme isn't present there.
If there's any problem with the patch, please reopen.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Mon Nov  2 14:50:19 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 02 Nov 2009 13:50:19 +0000
Subject: [issue7247] test_fcntl_64_bit from test_fcntl.py fails in Python 2.6.4
In-Reply-To: <1257103206.04.0.134413608226.issue7247@psf.upfronthosting.co.za>
Message-ID: <1257169819.62.0.83223333456.issue7247@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

On what platform did you encounter this failure?  I can't reproduce it
on Mac OSX (Leopard - 10.5.8) or Solaris 10 (update 5) running from
up-to-date release26-maint branches or on Ubuntu (8.10) running the 2.6.4
release code.

----------
nosy: +skip.montanaro

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

From report at bugs.python.org  Mon Nov  2 15:46:26 2009
From: report at bugs.python.org (Tony Vroon)
Date: Mon, 02 Nov 2009 14:46:26 +0000
Subject: [issue7247] test_fcntl_64_bit from test_fcntl.py fails in Python 2.6.4
In-Reply-To: <1257103206.04.0.134413608226.issue7247@psf.upfronthosting.co.za>
Message-ID: <1257173186.47.0.0328571717817.issue7247@psf.upfronthosting.co.za>


Tony Vroon <tony at vroon.org> added the comment:

This is AMD64 Linux, to be specific a 2.6.32-rc5-00336-g8d5eb43 kernel 
running on a dual Opteron 2435 system. The distribution is Gentoo linux, 
with a glibc version of 2.10.1-r0, compiled with GCC 4.4.2

----------

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

From report at bugs.python.org  Mon Nov  2 16:07:51 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 02 Nov 2009 15:07:51 +0000
Subject: [issue7252] list().index() should provide better error reporting
In-Reply-To: <1257163153.85.0.398972946442.issue7252@psf.upfronthosting.co.za>
Message-ID: <1257174471.85.0.18528036106.issue7252@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

How's "object is not in list"?

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Mon Nov  2 16:14:21 2009
From: report at bugs.python.org (djc)
Date: Mon, 02 Nov 2009 15:14:21 +0000
Subject: [issue7252] list().index() should provide better error reporting
In-Reply-To: <1257163153.85.0.398972946442.issue7252@psf.upfronthosting.co.za>
Message-ID: <1257174861.92.0.295343850078.issue7252@psf.upfronthosting.co.za>


djc <dirkjan at ochtman.nl> added the comment:

I want the actual value in there, though! So I can spot the bug.

----------

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

From report at bugs.python.org  Mon Nov  2 16:51:56 2009
From: report at bugs.python.org (Zsolt Cserna)
Date: Mon, 02 Nov 2009 15:51:56 +0000
Subject: [issue7242] Forking in a thread raises RuntimeError
In-Reply-To: <1256900282.72.0.764098234436.issue7242@psf.upfronthosting.co.za>
Message-ID: <1257177116.45.0.363618500606.issue7242@psf.upfronthosting.co.za>


Zsolt Cserna <zsolt.cserna at morganstanley.com> added the comment:

I've attached a patch which seems to fix this issue. It sets
import_lock_thread to the current thread id after forking in the child
process, but still I'm not quite sure that it's the correct way of
solving this issue.

----------
keywords: +patch
Added file: http://bugs.python.org/file15247/patch_1.diff

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

From report at bugs.python.org  Mon Nov  2 17:12:49 2009
From: report at bugs.python.org (Moriyoshi Koizumi)
Date: Mon, 02 Nov 2009 16:12:49 +0000
Subject: [issue7139] ElementTree: Incorrect serialization of end-of-line
	characters in attribute values
In-Reply-To: <1255587690.83.0.0369111720877.issue7139@psf.upfronthosting.co.za>
Message-ID: <1257178369.39.0.919919967061.issue7139@psf.upfronthosting.co.za>


Moriyoshi Koizumi <mozo+python at mozo.jp> added the comment:

Looks like a duplicate of #6492

----------

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

From report at bugs.python.org  Mon Nov  2 17:15:38 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 02 Nov 2009 16:15:38 +0000
Subject: [issue7252] list().index() should provide better error reporting
In-Reply-To: <1257163153.85.0.398972946442.issue7252@psf.upfronthosting.co.za>
Message-ID: <1257178538.13.0.965211828667.issue7252@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r76058 should do the trick.

----------
resolution:  -> accepted
status: open -> closed

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

From report at bugs.python.org  Mon Nov  2 18:13:47 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 02 Nov 2009 17:13:47 +0000
Subject: [issue7253] AssertionError Tree is insane with *args and reduce
In-Reply-To: <1257182027.38.0.713900492419.issue7253@psf.upfronthosting.co.za>
Message-ID: <1257182027.38.0.713900492419.issue7253@psf.upfronthosting.co.za>


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

Create a file with a single line of code:

def x(arg): return reduce(sum, [])

On Python 3.1.1 (I used Windows 64-bit), run 2to3 on it returns the
following error:

PS C:\Users\jaraco\projects\jaraco.util\jaraco\util>
C:\python\Tools\Scripts\2to3.py .\functools.py
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
Traceback (most recent call last):
  File "C:\python\Tools\Scripts\2to3.py", line 6, in <module>
    sys.exit(main("lib2to3.fixes"))
  File "C:\Python\lib\lib2to3\main.py", line 159, in main
    options.processes)
  File "C:\Python\lib\lib2to3\refactor.py", line 616, in refactor
    items, write, doctests_only)
  File "C:\Python\lib\lib2to3\refactor.py", line 276, in refactor
    self.refactor_file(dir_or_file, write, doctests_only)
  File "C:\Python\lib\lib2to3\refactor.py", line 656, in refactor_file
    *args, **kwargs)
  File "C:\Python\lib\lib2to3\refactor.py", line 328, in refactor_file
    tree = self.refactor_string(input, filename)
  File "C:\Python\lib\lib2to3\refactor.py", line 358, in refactor_string
    self.refactor_tree(tree, name)
  File "C:\Python\lib\lib2to3\refactor.py", line 392, in refactor_tree
    self.traverse_by(self.post_order_heads, tree.post_order())
  File "C:\Python\lib\lib2to3\refactor.py", line 416, in traverse_by
    new = fixer.transform(node, results)
  File "C:\Python\lib\lib2to3\fixes\fix_reduce.py", line 33, in transform
    touch_import('functools', 'reduce', node)
  File "C:\Python\lib\lib2to3\fixer_util.py", line 289, in touch_import
    root = find_root(node)
  File "C:\Python\lib\lib2to3\fixer_util.py", line 265, in find_root
    assert node.parent, "Tree is insane! root found before "\
AssertionError: Tree is insane! root found before file_input node was found.

2to3 on Python 2.6.4 does not exhibit the same error.

Remove 'arg' or the call to reduce and the problem is not exhibited.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 94835
nosy: jaraco
severity: normal
status: open
title: AssertionError Tree is insane with *args and reduce
versions: Python 3.1

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

From report at bugs.python.org  Mon Nov  2 18:22:09 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Nov 2009 17:22:09 +0000
Subject: [issue7253] AssertionError Tree is insane with *args and reduce
In-Reply-To: <1257182027.38.0.713900492419.issue7253@psf.upfronthosting.co.za>
Message-ID: <1257182529.02.0.195184616368.issue7253@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson
priority:  -> normal

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

From report at bugs.python.org  Mon Nov  2 18:42:53 2009
From: report at bugs.python.org (Milko Krachounov)
Date: Mon, 02 Nov 2009 17:42:53 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1257183773.5.0.98206846201.issue4356@psf.upfronthosting.co.za>


Milko Krachounov <python at milko.3mhz.net> added the comment:

I've been bugged by the lack of key= argument for bisect for some time
now, and today I got to read this and the previous issues about the
matter. I still fail to understand the reasons for the rejections. It
might encourage bad design in which expensive key functions will get
called more than once for the same element. However:

1. Not all key= functions are computationally expensive, in fact a quick
search shows that most key= uses come are with itemgetter, attrgetter or
some cousin.
2. Even for a computationally expensive function precached key isn't
necessarily the right answer. And if the keys are huge, a key= function
can actually be useful in implementing intelligent caching.
3. The reason for rejection is merely a performance issue which *can* be
fixed without any significant changes to the design of the app should it
prove to be a real issue.


I was writing a module that keeps a sorted list of items in which items
can be added, removed, or changed (they might get reordered). I used
bisect to avoid useless slow linear searches, which would be one
obstacle for the app to scale well. However, the sort key can be changed
at any time, so implementing __lt__ wasn't an option. Keeping a second
list with the keys is both memory and computationally expensive as
inserting into a list is slow. It's not a shiny example of a bisect
use-case as the only thing I've used my module so far is to display the
files in a directory, which means the lists are small and the changes
are seldom, so any implementation is good enough.  But bisect with key=
would have been best if it was available. What's worse, I have a buggy
unreadable ad hoc implementation of bisect in my code right now. ;)

I see the following as reasons why key= would provide benefit:
1. If you have a sorted list, bisect is a net win. Having a key= would
enable you to utilize it without refactoring anything. The lack of key
may as well encourage you to continue using linear searches, or other
sub-optimal solutions.
2. Using key= is more readable and less error-prone than keeping two
lists in simple cases where defining a class with __le__ is an overkill.
Two examples I had where this was the case:
a) A class I implemented to pick numbers from a certain discrete random
distribution with bisect. Oh, but yeah, the implementation without key=
is twice faster.
b) I gave a hand to someone who was implementing a dictionary looked up
the words as you typed them with bisect.
3. Insort. Insort is already slow enough as it is, a key= wouldn't slow
it down much if at all. In fact, if you are keeping two lists, key=
would speed it up. Insort with key= is a net win.

I've implemented key= and quickly hacked a benchmark to show what
performance hit it might have, and to put things into perspective. The
results:

1. Cheap key function, integers and abs(), 1000000 items, 5000 bisects
or insorts:
a) Bisect with a key: 0.02205014s
b) Bisect with a second list: 0.01328707s
c) Insort with a key: 5.83688211s
d) Bisect with a second list, and two inserts: 16.17302299s

2. Cheap key function, ~4000 char bytestrings and len(), 100000 items,
5000 bisects or insorts:
a) Bisect with a key: 0.01829195s
b) Bisect with a second list: 0.00945401s
c) Insort with a key: 0.25511408s
d) Bisect with a second list, and two inserts: 0.49303603s

3. Expensive key function, ~4000 char bytestrings and str.lower(),
100000 (500 MB) items, 5000 bisects or insorts:
a) Bisect with a key: 1.26837015s
b) Bisect with a second list: 0.08390594s
c) Insort with a key: 1.50406289s
d) Bisect with a second list, and two inserts: 0.57737398s

4. Expensive key function, ~4000 char bytestrings and str.lower(),
500000 (2.5 GB) items, 5000 bisects or insorts:
a) Bisect with a key: 1.46136308s
b) Bisect with a second list: 0.08768606s
c) Insort with a key: 3.05218720s
d) Bisect with a second list, and two inserts: 6.43227386s

5. Expensive key function, ~4000 char bytestrings and str.strip(),
100000 (500 MB) items, 5000 bisects or insorts:
a) Bisect with a key: 0.03311396s
b) Bisect with a second list: 0.01374602s
c) Insort with a key: 0.27423000s
d) Bisect with a second list, and two inserts: 0.49585080s

6. Expensive key function, ~4000 char bytestrings and str.strip(),
500000 (2.5 GB) items, 5000 bisects or insorts:
a) Bisect with a key: 0.04530501
b) Bisect with a second list: 0.01912594
c) Insort with a key: 1.62209797
d) Bisect with a second list, and two inserts: 5.91734695

Also, I tried to bench linear searches, but as they had to run in Python
code they aren't representative of anything. In the integer test they
went for about 250 seconds without recalculating the key, and for about
500 with. Also, replacing them with .index() gave about 60 seconds if I
ensured there's high probability that the number is in the list, and for
500 if I didn't.

In short, key= for bisect would be convenient and neat, really useful in
rare cases, leading to more readable code in the most common cases, and
I'm unconvinced of the perceived harm that it would cause.

I attach a patch implementing it for trunk, py3k, and the benchmark
script I used to test it (on trunk).

----------
keywords: +patch
nosy: +milko.krachounov
Added file: http://bugs.python.org/file15248/bisect-trunk.patch

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

From report at bugs.python.org  Mon Nov  2 18:43:13 2009
From: report at bugs.python.org (Milko Krachounov)
Date: Mon, 02 Nov 2009 17:43:13 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1257183793.44.0.452584762765.issue4356@psf.upfronthosting.co.za>


Changes by Milko Krachounov <python at milko.3mhz.net>:


Added file: http://bugs.python.org/file15249/bisect-py3k.patch

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

From report at bugs.python.org  Mon Nov  2 18:43:47 2009
From: report at bugs.python.org (Milko Krachounov)
Date: Mon, 02 Nov 2009 17:43:47 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1257183827.95.0.161042093393.issue4356@psf.upfronthosting.co.za>


Changes by Milko Krachounov <python at milko.3mhz.net>:


Added file: http://bugs.python.org/file15250/bench_bisect_key.py

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

From report at bugs.python.org  Mon Nov  2 18:51:02 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 02 Nov 2009 17:51:02 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1257184262.51.0.139870037142.issue4356@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger

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

From report at bugs.python.org  Mon Nov  2 19:06:34 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 02 Nov 2009 18:06:34 +0000
Subject: [issue7253] AssertionError Tree is insane with *args and reduce
In-Reply-To: <1257182027.38.0.713900492419.issue7253@psf.upfronthosting.co.za>
Message-ID: <1257185194.61.0.0912010666203.issue7253@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r76061.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Mon Nov  2 19:20:25 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 02 Nov 2009 18:20:25 +0000
Subject: [issue7249] Consider allowing io.BytesIO sizes to be passed as 'long'
	in 2.6
In-Reply-To: <1257133844.49.0.793599813853.issue7249@psf.upfronthosting.co.za>
Message-ID: <1257186025.89.0.696599746519.issue7249@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> pitrou
nosy: +pitrou

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

From report at bugs.python.org  Mon Nov  2 20:19:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Nov 2009 19:19:08 +0000
Subject: [issue7249] Consider allowing io.BytesIO sizes to be passed as 'long'
	in 2.6
In-Reply-To: <1257133844.49.0.793599813853.issue7249@psf.upfronthosting.co.za>
Message-ID: <1257189548.78.0.854008853189.issue7249@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +IO
priority:  -> normal
stage:  -> needs patch
versions: +Python 2.7

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

From report at bugs.python.org  Mon Nov  2 21:16:49 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Nov 2009 20:16:49 +0000
Subject: [issue7248] test_importlib uses a fixed name in /tmp
In-Reply-To: <1257115280.67.0.551284747455.issue7248@psf.upfronthosting.co.za>
Message-ID: <1257193009.25.0.528364543738.issue7248@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It sometimes seems to trigger another error:

======================================================================
ERROR: test_package (importlib.test.source.test_file_loader.SimpleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/var/lib/buildbot/cpython/trunk.pitrou-ubuntu/build/Lib/importlib/test/source/util.py",
line 78, in create_modules
    with open(file_path, 'w') as file:
IOError: [Errno 13] Permission denied: '/tmp/_pkg/__init__.py'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File
"/var/lib/buildbot/cpython/trunk.pitrou-ubuntu/build/Lib/importlib/test/source/test_file_loader.py",
line 33, in test_package
    with source_util.create_modules('_pkg.__init__') as mapping:
  File
"/var/lib/buildbot/cpython/trunk.pitrou-ubuntu/build/Lib/contextlib.py",
line 17, in __enter__
    return next(self.gen)
  File
"/var/lib/buildbot/cpython/trunk.pitrou-ubuntu/build/Lib/importlib/test/source/util.py",
line 88, in create_modules
    state_manager.__exit__(None, None, None)
UnboundLocalError: local variable 'state_manager' referenced before
assignment

----------

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

From report at bugs.python.org  Mon Nov  2 21:29:52 2009
From: report at bugs.python.org (Shawn Ligocki)
Date: Mon, 02 Nov 2009 20:29:52 +0000
Subject: [issue7076] Documentation add note about SystemRandom
In-Reply-To: <1254894491.86.0.615800723933.issue7076@psf.upfronthosting.co.za>
Message-ID: <1257193792.63.0.647155661727.issue7076@psf.upfronthosting.co.za>


Shawn Ligocki <sligocki at gmail.com> added the comment:

I rewrote the description, mostly using the claims form urandom, so that
we don't claim something new. What do you guys think?

----------
Added file: http://bugs.python.org/file15251/random.patch

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

From report at bugs.python.org  Mon Nov  2 21:40:45 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 02 Nov 2009 20:40:45 +0000
Subject: [issue7076] Documentation add note about SystemRandom
In-Reply-To: <1254894491.86.0.615800723933.issue7076@psf.upfronthosting.co.za>
Message-ID: <1257194445.69.0.725497626268.issue7076@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The wording looks reasonable but it doesn't seem to add much that is not
already said:

'''
class SystemRandom( [seed]) 

Class that uses the os.urandom() function for generating random numbers
from sources provided by the operating system. Not available on all
systems. Does not rely on software state and sequences are not
reproducible. Accordingly, the seed() and jumpahead() methods have no
effect and are ignored. The getstate() and setstate() methods raise
NotImplementedError if called. 
'''

I hesitate to include anything about cryptographic strength because that
isn't really guaranteed on any system.  At best, there are a fixed
number of bytes of machine generated entropy.  At worst, it is
deterministic (computed from time, etc) or it is not available at all.

----------

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

From report at bugs.python.org  Mon Nov  2 21:44:30 2009
From: report at bugs.python.org (Shawn Ligocki)
Date: Mon, 02 Nov 2009 20:44:30 +0000
Subject: [issue7076] Documentation add note about SystemRandom
In-Reply-To: <1254894491.86.0.615800723933.issue7076@psf.upfronthosting.co.za>
Message-ID: <1257194670.11.0.237458651525.issue7076@psf.upfronthosting.co.za>


Shawn Ligocki <sligocki at gmail.com> added the comment:

So, all I really want to do is call attention to SystemRandom from the
top of the page, because it is easily not noticed at the bottom. Do you
guys have any suggestions for how to do that that doesn't repeat too
much and doesn't claim things that you aren't comfortable with claiming?

----------

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

From report at bugs.python.org  Mon Nov  2 21:46:03 2009
From: report at bugs.python.org (Shawn Ligocki)
Date: Mon, 02 Nov 2009 20:46:03 +0000
Subject: [issue7076] Documentation add note about SystemRandom
In-Reply-To: <1254894491.86.0.615800723933.issue7076@psf.upfronthosting.co.za>
Message-ID: <1257194763.1.0.750341446806.issue7076@psf.upfronthosting.co.za>


Shawn Ligocki <sligocki at gmail.com> added the comment:

How about this, sweet and simple.

----------
Added file: http://bugs.python.org/file15252/random.patch

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

From report at bugs.python.org  Mon Nov  2 21:57:59 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Mon, 02 Nov 2009 20:57:59 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1257195479.88.0.633989298286.issue1628484@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

> > Martin, can you please elaborate on this? I never heard of such
> > "standards" in OSS.
> 
> MAL already gave the link. From the link:
> 
> Sometimes package developers are tempted to set user variables such as
> CFLAGS because it appears to make their job easier. However, the package
> itself should never set a user variable, particularly not to include
> switches that are required for proper compilation of the package. Since
> these variables are documented as being for the package builder, that
> person rightfully expects to be able to override any of these variables
> at build time.

So one day package builder by right will set CFLAGS to make their job
easier and python build system will not ignore it.

----------

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

From report at bugs.python.org  Mon Nov  2 22:03:51 2009
From: report at bugs.python.org (Carey)
Date: Mon, 02 Nov 2009 21:03:51 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1257195831.73.0.79570307428.issue7206@psf.upfronthosting.co.za>


Carey <carey.metcalfe at gmail.com> added the comment:

I am having the exact same problem with both the AMD64 and 32 bit
installs. The python shell just will not open. For now I am running it
in the virtual XP machine but it is extremely slow and a fix would be
very helpful. I have tried uninstalling and reinstalling with no effect.
I too am willing to set up a remote desktop connection if it would help.

Windows 7 Pro RTM, Intel Core 2 Duo

----------
nosy: +Carey

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

From report at bugs.python.org  Mon Nov  2 22:05:09 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Nov 2009 21:05:09 +0000
Subject: [issue7249] Consider allowing io.BytesIO sizes to be passed as 'long'
	in 2.6
In-Reply-To: <1257133844.49.0.793599813853.issue7249@psf.upfronthosting.co.za>
Message-ID: <1257195909.44.0.757509538964.issue7249@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed to the 2.6 branch in r76073. 2.7 is actually ok.
Thanks for the report!

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Mon Nov  2 22:12:42 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 02 Nov 2009 21:12:42 +0000
Subject: [issue7076] Documentation add note about SystemRandom
In-Reply-To: <1254894491.86.0.615800723933.issue7076@psf.upfronthosting.co.za>
Message-ID: <1257196362.18.0.559903667283.issue7076@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'm disinclined to move this to the top of the page but will keep this
open and consider further at a later date.

The SystemRandom class is an alternative generator like WichmanHill
which is typically not the right choice for many applications.

----------
priority:  -> low

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

From report at bugs.python.org  Mon Nov  2 22:21:08 2009
From: report at bugs.python.org (Shawn Ligocki)
Date: Mon, 02 Nov 2009 21:21:08 +0000
Subject: [issue7076] Documentation add note about SystemRandom
In-Reply-To: <1254894491.86.0.615800723933.issue7076@psf.upfronthosting.co.za>
Message-ID: <1257196868.99.0.381738266059.issue7076@psf.upfronthosting.co.za>


Shawn Ligocki <sligocki at gmail.com> added the comment:

There is a whole paragraph about WichmanHill at the top of this page
already and (if anything) I think that WichmanHill is less notable
(basically only used in legacy applications). However SystemRandom is
very useful. I don't want to make claims about urandom that I can't back
up, but urandom is very useful and I think that there ought to be some
note of it in the opening for people who want a stronger random
instance. All I'm suggesting is a sentence to point it out. That would
have been enough for me not to have reinvented the wheel.

----------

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

From report at bugs.python.org  Mon Nov  2 22:26:57 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 02 Nov 2009 21:26:57 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1257197217.13.0.0438718141695.issue7206@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

By "exactly the same problem", do you mean that your installation also
runs into a break instruction in ntdll!CsrSetPriorityClass+0x40? Can you
please also attach the debugger log (unless it's byte-for-byte identical
with the one from richo)?

----------

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

From report at bugs.python.org  Mon Nov  2 22:37:12 2009
From: report at bugs.python.org (Carey)
Date: Mon, 02 Nov 2009 21:37:12 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1257197832.62.0.531604971776.issue7206@psf.upfronthosting.co.za>


Carey <carey.metcalfe at gmail.com> added the comment:

i don't know how to do that. Is there an integrated debugger within
Windows 7? My program just doesn't open, it doesn't display any error
messages at all.

----------

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

From report at bugs.python.org  Mon Nov  2 22:44:07 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 02 Nov 2009 21:44:07 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1257197832.62.0.531604971776.issue7206@psf.upfronthosting.co.za>
Message-ID: <4AEF52A4.5070403@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> i don't know how to do that. Is there an integrated debugger within
> Windows 7? My program just doesn't open, it doesn't display any error
> messages at all.

Ok. So I'm skeptical that this is the same bug (having roughly the same
symptom is not convincing). If you want it studied, please report it
separately.

----------

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

From report at bugs.python.org  Mon Nov  2 22:55:36 2009
From: report at bugs.python.org (Vlad)
Date: Mon, 02 Nov 2009 21:55:36 +0000
Subject: [issue7254] Class members not properly initialized if declared
	outside of function
In-Reply-To: <1257198936.49.0.96904959127.issue7254@psf.upfronthosting.co.za>
Message-ID: <1257198936.49.0.96904959127.issue7254@psf.upfronthosting.co.za>


New submission from Vlad <vladc6 at yahoo.com>:

If a class member is declared outside of a function, it's creation is
_not_ repeated with every new instance of the class. Instead, the same
member is created during the first instance and then shared by all the
subsequent instances of that class. This is wrong, because a new member
should be created for every instance.

I have attached a sample code contrasting the incorrect behavior (on
top) with the correct behavior (on bottom). Python behaves correctly if
the member is declared in __init__ (that is, Python initializes a new
member for every instance).

The output of "print b.greet" and "print d.greet" should be the same and
should read "['Howdy']".

----------
files: class_member_init_inconsistency.py
messages: 94851
nosy: vladc6
severity: normal
status: open
title: Class members not properly initialized if declared outside of function
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file15253/class_member_init_inconsistency.py

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

From report at bugs.python.org  Mon Nov  2 23:05:19 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Nov 2009 22:05:19 +0000
Subject: [issue6492] xml.etree does not escape CR,
	LF and TAB characters within attribute values
In-Reply-To: <1247696588.32.0.942237333428.issue6492@psf.upfronthosting.co.za>
Message-ID: <1257199519.05.0.996368631958.issue6492@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Closing as duplicate of #7139.

----------
nosy: +ezio.melotti
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Nov  2 23:06:36 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Nov 2009 22:06:36 +0000
Subject: [issue7139] ElementTree: Incorrect serialization of end-of-line
	characters in attribute values
In-Reply-To: <1255587690.83.0.0369111720877.issue7139@psf.upfronthosting.co.za>
Message-ID: <1257199596.62.0.384083201988.issue7139@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If I understood correctly, the correct behavior while reading is:
  * literal newlines (\n or \r) and tabs (\t) should be collapsed and
converted to a space
  * newlines (&#xA; or &#xD;) and tabs (&#x9;) as entities should be
converted to the literal equivalents (\n, \r and \t)

(See http://www.w3.org/TR/2000/WD-xml-c14n-20000119.html#charescaping)

This should be ok in both xml.minidom and etree.


Instead, while writing, if literal newlines and tabs are written as they
are (\n, \r and \t), they can't be read during the parsing phase because
they are collapsed and converted to a space. They should therefore be
converted to entities (&#xA;, &#xD; and &#x9;) automatically, but this
could be incompatible with the current behavior (i.e. \n, \r or \t that
now are written and collapsed as a space during the parsing will then
become significant).

Moriyoshi, can you confirm that what I said is correct and the problem
is similar to the one described in #5752?
I also closed #6492 as duplicate of this.

----------
nosy: +devon, ezio.melotti
versions: +Python 2.7

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

From report at bugs.python.org  Mon Nov  2 23:18:56 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 02 Nov 2009 22:18:56 +0000
Subject: [issue7254] Class members not properly initialized if declared
	outside of function
In-Reply-To: <1257198936.49.0.96904959127.issue7254@psf.upfronthosting.co.za>
Message-ID: <1257200336.33.0.243291042183.issue7254@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is the way python works.  For help on using python please post to
python-list or python-tutor.

----------
nosy: +r.david.murray
priority:  -> low
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Nov  2 23:23:34 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 02 Nov 2009 22:23:34 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>
Message-ID: <1257200614.19.0.207456589021.issue6377@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
nosy: +dalcinl

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

From report at bugs.python.org  Mon Nov  2 23:27:31 2009
From: report at bugs.python.org (Fredrik Lundh)
Date: Mon, 02 Nov 2009 22:27:31 +0000
Subject: [issue7139] ElementTree: Incorrect serialization of end-of-line
	characters in attribute values
In-Reply-To: <1255587690.83.0.0369111720877.issue7139@psf.upfronthosting.co.za>
Message-ID: <1257200851.31.0.444434924714.issue7139@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

The real problem here is that XML attributes weren't really designed
to hold data that doesn't survive normalization.  One would have
thought that making it difficult to do that, and easy to store such
things as character data, would have made people think a bit before
designing XML formats that does things the other way around, but
apparently some people finds it hard having to use their brain when
designing things...

FWIW, the current ET 1.3 beta escapes newline but not tabs and
carriage returns; I don't really mind adding tabs, but I'm less sure
about carriage return -- XML pretty much treats CT as a junk character
also outside attributes, and escaping it in all contexts would just be
silly.

----------

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

From report at bugs.python.org  Tue Nov  3 00:20:11 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Nov 2009 23:20:11 +0000
Subject: [issue7250] wsgiref.handlers.CGIHandler caches os.environ,
	leaking info between requests
In-Reply-To: <1257147245.14.0.668660104401.issue7250@psf.upfronthosting.co.za>
Message-ID: <1257204011.94.0.554560643646.issue7250@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> pje
nosy: +pje
priority:  -> high
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5

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

From report at bugs.python.org  Tue Nov  3 05:22:03 2009
From: report at bugs.python.org (daniel mccloy)
Date: Tue, 03 Nov 2009 04:22:03 +0000
Subject: [issue7255] "Default" word boundaries for Unicode data?
In-Reply-To: <1257222123.85.0.715983159645.issue7255@psf.upfronthosting.co.za>
Message-ID: <1257222123.85.0.715983159645.issue7255@psf.upfronthosting.co.za>


New submission from daniel mccloy <bangalore.online at gmail.com>:

Regarding UTS #18 (Unicode Standards for RegEx Engines), which can be
found at:
http://www.unicode.org/reports/tr18/

Is there a plan or commitment for Python to implement at least "default
word boundaries" (a Level 2 feature), rather than the current "simple
word boundaries"?  I don't believe that the algorithm for this is a
whole lot more complicated, but it certainly makes a huge difference for
processing non-Roman text.

For example, to match the whole word ?? without matching the word ???
(which has an additional vowel at the end, the vertical line), with
"default word boundary" recognition, you could use the pattern \b??\b. 
With Python's current "simple word boundary" recognition, however, the
\b assertion is pretty much useless here, and I have yet to see a decent
zero-width pattern that can take its place.

BTW, the ICU regex libraries do provide this level of Unicode support:
http://userguide.icu-project.org/strings/regexp
It seems to work perfectly on Indic text, based on the tests I've done.

Being open-source, it may be a helpful reference for the algorithm needed.

Dan

----------
components: Regular Expressions
messages: 94856
nosy: RegEx4All
severity: normal
status: open
title: "Default" word boundaries for Unicode data?
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Tue Nov  3 07:12:48 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 03 Nov 2009 06:12:48 +0000
Subject: [issue7255] "Default" word boundaries for Unicode data?
In-Reply-To: <1257222123.85.0.715983159645.issue7255@psf.upfronthosting.co.za>
Message-ID: <4AEFC9DC.2000108@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Is there a plan or commitment for Python to implement at least "default
> word boundaries" (a Level 2 feature), rather than the current "simple
> word boundaries"?

No such plan exists at this time. Contributions are welcome.

----------
nosy: +loewis

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

From report at bugs.python.org  Tue Nov  3 08:52:41 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 03 Nov 2009 07:52:41 +0000
Subject: [issue7240] subprocess.Popen.stdout.flush fails os OS-X 10.6.1
In-Reply-To: <1256879749.75.0.623795302461.issue7240@psf.upfronthosting.co.za>
Message-ID: <1257234761.79.0.89064210408.issue7240@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I don't think so. stdio on OSX has a fdiscard function, but that's not 
exposed to Python.

I tend to explicitly synchronize on prompts when communicating with an 
interactive program over a pipe. That is, read until you found the prompt, 
then send a command, then read again until getting to the prompt, ...

----------

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

From report at bugs.python.org  Tue Nov  3 09:25:40 2009
From: report at bugs.python.org (chuck)
Date: Tue, 03 Nov 2009 08:25:40 +0000
Subject: [issue7076] Documentation add note about SystemRandom
In-Reply-To: <1254894491.86.0.615800723933.issue7076@psf.upfronthosting.co.za>
Message-ID: <1257236740.79.0.161765381538.issue7076@psf.upfronthosting.co.za>


chuck <jan.hosang at gmail.com> added the comment:

I think many people who are looking for a random number generator end up 
on this page and need to be informed if there are alternatives so they can 
make up their own mind. If you want to discourage people to use it, that's 
fine and we can do so, but I think it's wrong to hide it from people who 
don't suspect random functions which are os dependent to be in the os 
package instead of the random package or don't even know about the os 
random facility.

----------

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

From report at bugs.python.org  Tue Nov  3 12:36:01 2009
From: report at bugs.python.org (Jeroen Habraken)
Date: Tue, 03 Nov 2009 11:36:01 +0000
Subject: [issue7256] parse_qs and parse_qsl in urlparse are not documented as
	New in version 2.6
In-Reply-To: <1257248161.63.0.720725035122.issue7256@psf.upfronthosting.co.za>
Message-ID: <1257248161.63.0.720725035122.issue7256@psf.upfronthosting.co.za>


New submission from Jeroen Habraken <vexocide at gmail.com>:

The parse_qs and parse_qsl functions in the urlparse module seem to be new 
since version 2.6, though this is not documented, please add "New in version 
2.6.".

----------
assignee: georg.brandl
components: Documentation
messages: 94860
nosy: VeXocide, georg.brandl
severity: normal
status: open
title: parse_qs and parse_qsl in urlparse are not documented as New in version 2.6

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

From report at bugs.python.org  Tue Nov  3 12:58:42 2009
From: report at bugs.python.org (Thomas Guettler)
Date: Tue, 03 Nov 2009 11:58:42 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1257249522.41.0.115834243456.issue3244@psf.upfronthosting.co.za>


Changes by Thomas Guettler <guettli at thomas-guettler.de>:


----------
nosy: +guettli

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

From report at bugs.python.org  Tue Nov  3 15:16:22 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 03 Nov 2009 14:16:22 +0000
Subject: [issue6462] bsddb3 intermittent test failures
In-Reply-To: <1247329933.16.0.47150397.issue6462@psf.upfronthosting.co.za>
Message-ID: <1257257782.67.0.441621471584.issue6462@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Unless someone objects, I'm going to disable the replication timeout
check unconditionally, since it is the worst culprit for buildbot
stability on 2.x.  Note that issue 3892 indicates it happens
consistently on windows, and there was already a partial disable for
that platform.  All the other tests usually succeed even if that
particular assert fails.

----------
versions: +Python 2.6

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

From report at bugs.python.org  Tue Nov  3 15:34:24 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 03 Nov 2009 14:34:24 +0000
Subject: [issue7255] "Default" word boundaries for Unicode data?
In-Reply-To: <1257222123.85.0.715983159645.issue7255@psf.upfronthosting.co.za>
Message-ID: <1257258864.58.0.836806189455.issue7255@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
versions: +Python 2.7

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

From report at bugs.python.org  Tue Nov  3 17:15:18 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 03 Nov 2009 16:15:18 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1257264918.05.0.0955020804847.issue7117@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch for correctly-rounded round in trunk.  This patch doesn't 
change the rounding behaviour between 2.6 and 2.7:  it's still doing 
round-half-away-from-zero instead of round-half-even.  It was necessary to 
detect and treat halfway cases specially to make this work.  Removing this 
special case code would be easy, so we can decide later whether it's worth 
changing round to do round-half-to-even for 2.7.

I want to let this sit for a couple of days before I apply it.

----------
keywords: +patch
Added file: http://bugs.python.org/file15254/round_fixup.patch

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

From report at bugs.python.org  Tue Nov  3 19:03:22 2009
From: report at bugs.python.org (Ole Laursen)
Date: Tue, 03 Nov 2009 18:03:22 +0000
Subject: [issue7257] Improve documentation of list.sort and sorted()
In-Reply-To: <1257271402.44.0.845935336984.issue7257@psf.upfronthosting.co.za>
Message-ID: <1257271402.44.0.845935336984.issue7257@psf.upfronthosting.co.za>


New submission from Ole Laursen <olau at iola.dk>:

On my Python 3.1, help() for sorted returns

sort(...)
    L.sort(key=None, reverse=False) -- stable sort *IN PLACE*

sorted(...)
    sorted(iterable, key=None, reverse=False) --> new sorted list

Kindly suggest this be expanded. Here's some text:

sort(...)

Sorts the sequence with a fast stable sort. The sequence is modified in
place. To remind you of this, the function always returns None. Example:

a = [1, 3, 2]
a.sort()
# a is now [1, 2, 3]

Use the "sorted()" built-in function if you need to preserve the
original list.

Set "reverse" to True to sort the elements in reverse order. A function
for extracting a key for comparison from each object can be passed in as
"key", e.g.

a = [{'k': 'foo'}, {'k': 'bar'}]
a.sort(key=lambda x: x['k'])
# a is now [{'k': 'bar'}, {'k': 'foo'}]

Note that "key" can be used to solve many sorting problems, e.g.
key=str.lower can be used for case-insensitive sorting and key=lambda x:
(x['a'], x['b']) can be used to sort by first 'a' then 'b'.

The sort is stable which means that the relative order of elements that
compare equal is not changed.


sorted(...)

Sorts the sequence with a fast stable sort and returns a new list with
the result. Example:

[same text as before]


I'm not sure how this interacts with what's in the online help
(http://docs.python.org/3.1/library/stdtypes.html search for "sort("),
maybe the text could just be copied over. I think it's important to give
copy-pasteable examples for something as important as this, and hint at
how you solve common sorting problems.

----------
assignee: georg.brandl
components: Documentation
messages: 94863
nosy: georg.brandl, olau
severity: normal
status: open
title: Improve documentation of list.sort and sorted()

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

From report at bugs.python.org  Tue Nov  3 19:14:16 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 03 Nov 2009 18:14:16 +0000
Subject: [issue7257] Improve documentation of list.sort and sorted()
In-Reply-To: <1257271402.44.0.845935336984.issue7257@psf.upfronthosting.co.za>
Message-ID: <1257272056.09.0.142956767087.issue7257@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Raymond, do you have an opinion on this?

----------
assignee: georg.brandl -> rhettinger
nosy: +rhettinger

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

From report at bugs.python.org  Tue Nov  3 19:22:29 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 03 Nov 2009 18:22:29 +0000
Subject: [issue7257] Improve documentation of list.sort and sorted()
In-Reply-To: <1257271402.44.0.845935336984.issue7257@psf.upfronthosting.co.za>
Message-ID: <1257272549.69.0.492640649673.issue7257@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'm inclined to leave the on-line help docstring as-is (pretty much
everywhere, we adopt a style of terse reminders instead of lengthy prose
with examples).  

Instead, was thinking of updating the sorting how-to and providing a
link to it from the main docs.

----------
priority:  -> low

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

From report at bugs.python.org  Tue Nov  3 19:34:44 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 03 Nov 2009 18:34:44 +0000
Subject: [issue7256] parse_qs and parse_qsl in urlparse are not documented as
	New in version 2.6
In-Reply-To: <1257248161.63.0.720725035122.issue7256@psf.upfronthosting.co.za>
Message-ID: <1257273284.65.0.365697922623.issue7256@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r76095 and will backport.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Tue Nov  3 20:05:20 2009
From: report at bugs.python.org (Phillip J. Eby)
Date: Tue, 03 Nov 2009 19:05:20 +0000
Subject: [issue7250] wsgiref.handlers.CGIHandler caches os.environ,
	leaking info between requests
In-Reply-To: <1257147245.14.0.668660104401.issue7250@psf.upfronthosting.co.za>
Message-ID: <1257275120.05.0.460450812771.issue7250@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

This is not an issue with CGI, but an issue with using an inappropriate
WSGI handler for a long-running process environment that only emulates CGI.

That is, in a true CGI environment, there can't be *multiple* requests
made to CGIHandler, and so it can't leak.  In "normal" (i.e. pre-GAE)
long-running web environments, os.environ would not contain any request
information, only the process startup environment.

This limitation of CGIHandler should be better documented, but it's a
natural consequence of its design.  The os_environ and base_environ
variables are provided so that subclasses with specialized needs can
handle them differently, and GAE is definitely a specialized need.

If someone wants to provide a GAEHandler class, great; otherwise, the
documented way to run a WSGI app under GAE is the
google.appengine.ext.webapp.util.run_wsgi_app function.

----------

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

From report at bugs.python.org  Tue Nov  3 20:20:55 2009
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 03 Nov 2009 19:20:55 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1257276055.74.0.431869766235.issue5094@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee: brett.cannon -> 

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

From report at bugs.python.org  Tue Nov  3 20:22:00 2009
From: report at bugs.python.org (Ole Laursen)
Date: Tue, 03 Nov 2009 19:22:00 +0000
Subject: [issue7257] Improve documentation of list.sort and sorted()
In-Reply-To: <1257271402.44.0.845935336984.issue7257@psf.upfronthosting.co.za>
Message-ID: <1257276120.66.0.939983786588.issue7257@psf.upfronthosting.co.za>


Ole Laursen <olau at iola.dk> added the comment:

If you think it's too long, here's a shorter version:

Sorts sequence in place with a fast stable sort, returning None. key is
a function for extracting a comparison key from each element, e.g.
key=lambda x: x['name'] or key=str.lower. reverse=True reverses the
result order.

a = [1, 3, 2]
a.sort() # a is now [1, 2, 3]

Use the "sorted()" built-in function if you need to preserve the
original list.


Is this better? You could whack the last comment about sorted and/or the
example, then it's about the same length as the other built-in
docstrings (e.g. zip, reduce, getattr).

----------
nosy:  -rhettinger

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

From report at bugs.python.org  Tue Nov  3 20:45:08 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 03 Nov 2009 19:45:08 +0000
Subject: [issue7257] Improve documentation of list.sort and sorted()
In-Reply-To: <1257271402.44.0.845935336984.issue7257@psf.upfronthosting.co.za>
Message-ID: <1257277508.29.0.612106510291.issue7257@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
nosy: +rhettinger

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

From report at bugs.python.org  Tue Nov  3 20:49:15 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 03 Nov 2009 19:49:15 +0000
Subject: [issue7257] Improve documentation of list.sort and sorted()
In-Reply-To: <1257271402.44.0.845935336984.issue7257@psf.upfronthosting.co.za>
Message-ID: <1257277755.11.0.235760610032.issue7257@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Will look at it and make an update, but not right away.

----------

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

From report at bugs.python.org  Tue Nov  3 21:57:24 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Tue, 03 Nov 2009 20:57:24 +0000
Subject: [issue7240] subprocess.Popen.stdout.flush fails os OS-X 10.6.1
In-Reply-To: <1256879749.75.0.623795302461.issue7240@psf.upfronthosting.co.za>
Message-ID: <1257281844.06.0.374261774388.issue7240@psf.upfronthosting.co.za>


Changes by Philip Jenvey <pjenvey at underboss.org>:


----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Tue Nov  3 21:58:15 2009
From: report at bugs.python.org (Brandon Bloom)
Date: Tue, 03 Nov 2009 20:58:15 +0000
Subject: [issue7250] wsgiref.handlers.CGIHandler caches os.environ,
	leaking info between requests
In-Reply-To: <1257275120.05.0.460450812771.issue7250@psf.upfronthosting.co.za>
Message-ID: <b2126670911031257g21ef5d68ke34568356e87bdc4@mail.gmail.com>


Brandon Bloom <snprbob86 at gmail.com> added the comment:

> That is, in a true CGI environment, there can't be *multiple* requests
> made to CGIHandler, and so it can't leak. ?In "normal" (i.e. pre-GAE)
> long-running web environments, os.environ would not contain any request
> information, only the process startup environment.

That's fair. In this case the CGIHandler should raise an exception on
subsequent requests to prevent this programming error.

> If someone wants to provide a GAEHandler class, great; otherwise, the
> documented way to run a WSGI app under GAE is the
> google.appengine.ext.webapp.util.run_wsgi_app function.

I'm not sure if run_wsgi_app was available right from the start, as
some early tutorials and samples show using CGIHandler. That's how we
ran into this issue.

----------

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

From report at bugs.python.org  Tue Nov  3 22:13:57 2009
From: report at bugs.python.org (Phillip J. Eby)
Date: Tue, 03 Nov 2009 21:13:57 +0000
Subject: [issue7250] wsgiref.handlers.CGIHandler caches os.environ,
	leaking info between requests
In-Reply-To: <1257147245.14.0.668660104401.issue7250@psf.upfronthosting.co.za>
Message-ID: <1257282837.47.0.0421921769598.issue7250@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

Hm.  In retrospect, CGIHandler should probably just set os_environ to an
empty dictionary in its class body (thereby not using the cached
environ), and this would then work correctly for repeated uses.

This would be a clean bugfix and wouldn't affect behavior for any
existing uses of CGIHandler that weren't already worse broken than the
GAE case.  ;-)

----------

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

From report at bugs.python.org  Tue Nov  3 23:25:28 2009
From: report at bugs.python.org (Timothy Farrell)
Date: Tue, 03 Nov 2009 22:25:28 +0000
Subject: [issue4969] mimetypes on Windows should read MIME database from
	registry (w/patch)
In-Reply-To: <1232182722.74.0.429880551513.issue4969@psf.upfronthosting.co.za>
Message-ID: <1257287128.07.0.281999316127.issue4969@psf.upfronthosting.co.za>


Changes by Timothy Farrell <tfarrell at swgen.com>:


----------
nosy: +tercero12

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

From report at bugs.python.org  Wed Nov  4 00:33:55 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Nov 2009 23:33:55 +0000
Subject: [issue7247] test_fcntl_64_bit from test_fcntl.py fails in Python 2.6.4
In-Reply-To: <1257103206.04.0.134413608226.issue7247@psf.upfronthosting.co.za>
Message-ID: <1257291235.73.0.28854376814.issue7247@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

That test was added as part of #1309352, to check that fcntl accepted
64-bit arguments on 64-bit systems. Previously it would raise an
OverflowError. Perhaps we should silent the IOError, since it only shows
that the OS refuses that particular case, not that the Python wrapper is
at fault.

(seeing you have problems, I don't know how to make the test pass
reliably on all systems; it does pass on my x86-64 system)

----------
nosy: +pitrou

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

From report at bugs.python.org  Wed Nov  4 00:47:23 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Nov 2009 23:47:23 +0000
Subject: [issue7247] test_fcntl_64_bit from test_fcntl.py fails in Python 2.6.4
In-Reply-To: <1257103206.04.0.134413608226.issue7247@psf.upfronthosting.co.za>
Message-ID: <1257292043.31.0.306715572979.issue7247@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Library (Lib)
priority:  -> normal
stage:  -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Nov  4 01:33:06 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 04 Nov 2009 00:33:06 +0000
Subject: [issue7217] IDLE Subprocess Startup Error
In-Reply-To: <1256630225.32.0.706380843912.issue7217@psf.upfronthosting.co.za>
Message-ID: <1257294786.75.0.217315672284.issue7217@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Do you have some Queue.py in your PYTHONPATH, before the standard one?
What do you get when starting python from cmd:
  import Queue
  print Queue
(It should be <module 'Queue' from 'C:\Python26\lib\Queue.pyc'>)

----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Wed Nov  4 02:17:55 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Nov 2009 01:17:55 +0000
Subject: [issue7258] test_multiprocessing leaves a temporary directory
In-Reply-To: <1257297475.58.0.890770725694.issue7258@psf.upfronthosting.co.za>
Message-ID: <1257297475.58.0.890770725694.issue7258@psf.upfronthosting.co.za>


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

On my buildbot, test_multiprocessing, although it succeeds, leaves an
empty temporary directory behind it (something like "/tmp/pymp-UHJdgH/").

----------
assignee: jnoller
components: Tests
messages: 94874
nosy: jnoller, pitrou, r.david.murray
priority: low
severity: normal
stage: needs patch
status: open
title: test_multiprocessing leaves a temporary directory
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Nov  4 02:26:16 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Nov 2009 01:26:16 +0000
Subject: [issue4969] mimetypes on Windows should read MIME database from
	registry (w/patch)
In-Reply-To: <1232182722.74.0.429880551513.issue4969@psf.upfronthosting.co.za>
Message-ID: <1257297976.55.0.671427371856.issue4969@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

A couple of points:
- if the method is Windows-specific, I don't think it shouldn't bear a
name as generic as "read_registry()". There are "registries" on other
systems.
- the method should probably raise early on non-Windows systems (raise
NotImplementedError?)
- please fix the coding style; don't collapse a "try", "except" or
"finally" and the following statement on a single line
- in the tests, rather than defining an empty test case on non-Windows
systems, make the tests skip (for example, call self.skipTest()

----------
nosy: +pitrou
priority:  -> normal
stage:  -> patch review
type:  -> feature request
versions: +Python 3.2 -Python 3.1

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

From report at bugs.python.org  Wed Nov  4 02:27:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Nov 2009 01:27:54 +0000
Subject: [issue7258] test_multiprocessing leaves a temporary directory
In-Reply-To: <1257297475.58.0.890770725694.issue7258@psf.upfronthosting.co.za>
Message-ID: <1257298074.55.0.376821129273.issue7258@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hmm, apparently it is automatically removed at the end of the test
suite. Sorry for the noise :)

----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Wed Nov  4 02:33:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Nov 2009 01:33:46 +0000
Subject: [issue4969] mimetypes on Windows should read MIME database from
	registry (w/patch)
In-Reply-To: <1232182722.74.0.429880551513.issue4969@psf.upfronthosting.co.za>
Message-ID: <1257298426.06.0.0892683423366.issue4969@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +ocean-city

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

From report at bugs.python.org  Wed Nov  4 04:34:19 2009
From: report at bugs.python.org (Rich Healey)
Date: Wed, 04 Nov 2009 03:34:19 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1257305659.4.0.955293278787.issue7206@psf.upfronthosting.co.za>


Rich Healey <richo at psych0tik.net> added the comment:

Carey I can send you the steps I used to create the dump if you like so we 
can check if it's the same issue?

----------

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

From report at bugs.python.org  Wed Nov  4 06:23:39 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 04 Nov 2009 05:23:39 +0000
Subject: [issue7259] Documentation update for operator module
In-Reply-To: <1257312219.3.0.741545743577.issue7259@psf.upfronthosting.co.za>
Message-ID: <1257312219.3.0.741545743577.issue7259@psf.upfronthosting.co.za>


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

This patch fixes some issues with the documentation of the operator 
module:

- docstrings for all augmented assignments incorrectly stated, e.g., 
`operator.iadd(a,b)` is the same as `a += b`. The main documentation 
shows `a = operator.iadd(a,b)` instead, and that's correct. This patch 
updates all affected docstrings in the operator.c module.

- Added +obj to the table of operators.

- Replaced getslice/setslice/delslice examples (deprecated) with their 
getitem/setitem/delitem equivalents. This change unfortunately made the 
table some characters wider.

Originally reported by Juanjo Conti:
http://permalink.gmane.org/gmane.org.user-groups.python.argentina/28596

----------
assignee: georg.brandl
components: Documentation
files: operator.diff
keywords: patch
messages: 94878
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: Documentation update for operator module
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15255/operator.diff

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

From report at bugs.python.org  Wed Nov  4 08:04:59 2009
From: report at bugs.python.org (Noam Raphael)
Date: Wed, 04 Nov 2009 07:04:59 +0000
Subject: [issue7260] SyntaxError with a not-existing offset for unicode code
In-Reply-To: <1257318299.81.0.115338436222.issue7260@psf.upfronthosting.co.za>
Message-ID: <1257318299.81.0.115338436222.issue7260@psf.upfronthosting.co.za>


New submission from Noam Raphael <noamraph at gmail.com>:

Hello,

This is from the current svn:

> ./python
Python 3.2a0 (py3k:76104, Nov  4 2009, 08:49:44) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> try:
... 	eval("u'????'")
... except SyntaxError as e:
... 	e
... 
SyntaxError('invalid syntax', ('<string>', 1, 11, "u'????'"))

As you can see, the offset (11) refers to a non-existing character, as
the code contains only 7 characters.

Thanks,
Noam

----------
components: Interpreter Core
messages: 94879
nosy: noam
severity: normal
status: open
title: SyntaxError with a not-existing offset for unicode code
versions: Python 3.2

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

From report at bugs.python.org  Wed Nov  4 08:14:31 2009
From: report at bugs.python.org (Brandon Bloom)
Date: Wed, 04 Nov 2009 07:14:31 +0000
Subject: [issue7250] wsgiref.handlers.CGIHandler caches os.environ,
	leaking info between requests
In-Reply-To: <1257282837.47.0.0421921769598.issue7250@psf.upfronthosting.co.za>
Message-ID: <b2126670911032314s23fbf403v2b5422214ad678b8@mail.gmail.com>


Brandon Bloom <snprbob86 at gmail.com> added the comment:

> Hm. ?In retrospect, CGIHandler should probably just set os_environ to an
> empty dictionary in its class body (thereby not using the cached
> environ), and this would then work correctly for repeated uses.
>
> This would be a clean bugfix and wouldn't affect behavior for any
> existing uses of CGIHandler that weren't already worse broken than the
> GAE case. ?;-)

Yup, rock on with that :-)

----------

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

From report at bugs.python.org  Wed Nov  4 08:17:53 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 04 Nov 2009 07:17:53 +0000
Subject: [issue7260] SyntaxError with a not-existing offset for unicode code
In-Reply-To: <1257318299.81.0.115338436222.issue7260@psf.upfronthosting.co.za>
Message-ID: <1257319073.33.0.399874816251.issue7260@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Apparently the position of the caret is based on the number of bytes in
the line, not on the characters:
>>> [aaa for x in]
  File "<stdin>", line 1
    [aaa for x in]
                 ^
SyntaxError: invalid syntax
>>> [??? for x in]
  File "<stdin>", line 1
    [??? for x in]
                    ^
SyntaxError: invalid syntax

In this example each ? takes two bytes so the caret is 3 extra chars on
the right.

----------
nosy: +ezio.melotti
priority:  -> normal

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

From report at bugs.python.org  Wed Nov  4 08:38:26 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 04 Nov 2009 07:38:26 +0000
Subject: [issue7259] Documentation update for operator module
In-Reply-To: <1257312219.3.0.741545743577.issue7259@psf.upfronthosting.co.za>
Message-ID: <1257320306.2.0.520338543175.issue7259@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied in r76105.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Wed Nov  4 08:49:58 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 04 Nov 2009 07:49:58 +0000
Subject: [issue7260] SyntaxError with a not-existing offset for unicode code
In-Reply-To: <1257318299.81.0.115338436222.issue7260@psf.upfronthosting.co.za>
Message-ID: <1257320998.09.0.809691614047.issue7260@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is actually a duplicate of #2382, so I'm closing it.
#2382 also has some patch.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Nov  4 10:52:13 2009
From: report at bugs.python.org (Jean-Christophe Helary)
Date: Wed, 04 Nov 2009 09:52:13 +0000
Subject: [issue4652] IDLE does not work with Unicode
In-Reply-To: <1229154229.3.0.726059762082.issue4652@psf.upfronthosting.co.za>
Message-ID: <1257328333.18.0.817739481778.issue4652@psf.upfronthosting.co.za>


Jean-Christophe Helary <jean.christophe.helary at gmail.com> added the comment:

I've installed Python 3.1.1 on OSX today.
1) When I use the Japanese input from OSX, IDLE interprets any character 
I attempt to type as a space.
2) When I paste a Japanese string from a different place, it is 
correctly handled. For ex:
>>> print('??')
??
>>> 

While on Python 2.5's IDLE I had:
>>> print('??')
Unsupported characters in input

>>> 

by default.

In any case, IDLE 3.1.1 does not respect the input source and that makes 
it impossible to directly type Japanese (if not other double byte 
character based languages).

Note: IDLE respect OSX dead keys and I can correctly use "Alt+c" to 
input "?".

----------
nosy: +jchelary
versions: +Python 3.1 -Python 3.0

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

From report at bugs.python.org  Wed Nov  4 11:11:11 2009
From: report at bugs.python.org (Ole Laursen)
Date: Wed, 04 Nov 2009 10:11:11 +0000
Subject: [issue7257] Improve documentation of list.sort and sorted()
In-Reply-To: <1257271402.44.0.845935336984.issue7257@psf.upfronthosting.co.za>
Message-ID: <1257329471.07.0.496539119039.issue7257@psf.upfronthosting.co.za>


Ole Laursen <olau at iola.dk> added the comment:

OK, thanks! :) Sorry about the unintended nosy list removal, my browser 
got me there.

----------

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

From report at bugs.python.org  Wed Nov  4 11:33:13 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 04 Nov 2009 10:33:13 +0000
Subject: [issue7261] Document 2.x -> 3.x round changes in "Whats New"
	documents.
In-Reply-To: <1257330793.87.0.85024867948.issue7261@psf.upfronthosting.co.za>
Message-ID: <1257330793.87.0.85024867948.issue7261@psf.upfronthosting.co.za>


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

The round builtin function changed in three fairly significant ways
between 2.x and 3.x:

(1) In 2.x, halfway cases are rounded using the
    round-half-away-from-zero rule, while in 3.x they're
    rounded using round-half-to-even.

(2) The single argument version, round(x), generally returns an
    integer in 3.x and a float in 2.x.  (For float inputs, this
    actually changed between 3.0 and 3.1, not between 2.x and 3.x.).

(3) In 3.x, round(x, n) delegates to x.__round__; in 2.x, x is simply
    converted to a float (if possible).  (So for example, rounding
    a Decimal instance in 2.x gives a float result;  in 3.x it uses
    Decimal.__round__, which returns another Decimal.)

I think all of this is covered (more-or-less) in the 'built-in
functions' section of the documentation, but I suggest that it would be
worth putting an entry for these changes into the 'What's new in Python
3.0' document as well.

The first change above is particularly evil (i.e., likely to cause
late-discovered bugs), since the value of round(x) will change silently,
just for a few values of x.  Note that this change affects
integers, too, so it's applicable beyond the "well you should be
using Decimal then" situations.

[2.5]
>>> int(round(2500, -3))
3000

[3.1]
>>> round(2500, -3)
2000

----------
assignee: georg.brandl
components: Documentation
messages: 94886
nosy: georg.brandl, mark.dickinson
severity: normal
stage: needs patch
status: open
title: Document 2.x -> 3.x round changes in "Whats New" documents.

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

From report at bugs.python.org  Wed Nov  4 11:35:51 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 04 Nov 2009 10:35:51 +0000
Subject: [issue7261] Document 2.x -> 3.x round changes in "What's New"
	documents.
In-Reply-To: <1257330793.87.0.85024867948.issue7261@psf.upfronthosting.co.za>
Message-ID: <1257330951.4.0.819565242004.issue7261@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
title: Document 2.x -> 3.x round changes in "Whats New" documents. -> Document 2.x -> 3.x round changes in "What's New" documents.

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

From report at bugs.python.org  Wed Nov  4 12:03:49 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 04 Nov 2009 11:03:49 +0000
Subject: [issue7261] Document 2.x -> 3.x round changes in "What's New"
	documents.
In-Reply-To: <1257330793.87.0.85024867948.issue7261@psf.upfronthosting.co.za>
Message-ID: <1257332629.64.0.156606619163.issue7261@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee: georg.brandl -> mark.dickinson

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

From report at bugs.python.org  Wed Nov  4 14:46:32 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 04 Nov 2009 13:46:32 +0000
Subject: [issue7224] One obvious way to do interning
In-Reply-To: <1256691929.12.0.04518648136.issue7224@psf.upfronthosting.co.za>
Message-ID: <1257342392.61.0.636990789703.issue7224@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

If the idea is to create the "one obvious way" for interning, calling
the method and corresponding C function "intern" isn't painting a
bikeshed, it's meeting the design spec :)

Adding a new method also avoids a whole host of issues with the Set ABC.

----------
nosy: +ncoghlan

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

From report at bugs.python.org  Wed Nov  4 15:13:30 2009
From: report at bugs.python.org (shamilbi)
Date: Wed, 04 Nov 2009 14:13:30 +0000
Subject: [issue7262] codecs.open() + eol (windows)
In-Reply-To: <1257344010.52.0.739143662559.issue7262@psf.upfronthosting.co.za>
Message-ID: <1257344010.52.0.739143662559.issue7262@psf.upfronthosting.co.za>


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

different eol when writing to fp = codecs.open(.., 'w', 'cp866')
(windows, python-2.6.4)

def write(fp):
    fp.write("""\
a
""")

# eol=0d0a (windows, python-2.6.4)
with open('0d0a.tmp', 'w') as fp:
    write(fp)

# eol=0d0a (windows, python-2.6.4)
with codecs.open('0d0a-codecs.tmp', 'w') as fp:
    write(fp)

# --- BUG ---
# eol=0a (windows, python-2.6.4)
with codecs.open('0a-codecs.tmp', 'w', 'cp866') as fp:
    write(fp)

----------
components: Library (Lib)
files: eol-bug.py
messages: 94888
nosy: shamilbi
severity: normal
status: open
title: codecs.open() + eol (windows)
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15256/eol-bug.py

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

From report at bugs.python.org  Wed Nov  4 15:43:50 2009
From: report at bugs.python.org (Carey)
Date: Wed, 04 Nov 2009 14:43:50 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1257345830.22.0.519775978796.issue7206@psf.upfronthosting.co.za>


Carey <carey.metcalfe at gmail.com> added the comment:

yes, please do

----------

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

From report at bugs.python.org  Wed Nov  4 15:47:05 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 04 Nov 2009 14:47:05 +0000
Subject: [issue7224] One obvious way to do interning
In-Reply-To: <1257342392.61.0.636990789703.issue7224@psf.upfronthosting.co.za>
Message-ID: <d38f5330911040646u537ec23bw2cf69b20323bc778@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Nov 4, 2009 at 9:46 AM, Nick Coghlan <report at bugs.python.org> wrote:
>
> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>
> If the idea is to create the "one obvious way" for interning, calling
> the method and corresponding C function "intern" isn't painting a
> bikeshed, it's meeting the design spec :)
>

Any bikeshed needs to be painted and _PySet_Add was deliberately just
a primer. (Sorry for the cliche abuse.)  At the C API level, I was
hoping that old PySet_Add semantics could be eventually deprecated and
_PySet_Add be promoted to a public method.  Keeping two functions that
have the same effect but return different values is inelegant
especially given that zero return from one is success and from the
other is an error, so people who don't pay attention to compiler
warnings may get some nasty bugs.  Maybe _PySet_Add should be renamed
to _PySet_AddAndReturn to emphasize the similarity and difference with
PySet_Add.  I don't mind calling the method _PySet_Intern (in the
original patch I used _PySet_InternString), but that choice will only
become obvious if set grows intern(..) method in addition to add(..).
I also wonder how widespread the knowledge of the term "intern" is.  I
would not be surprised if some non-CS users would be more comfortable
with AddAndReturn.

> Adding a new method also avoids a whole host of issues with the Set ABC.

I am neutral on changing add(..) return value vs. adding a new method.
 Can you elaborate on the "whole host of issues with the Set ABC".
Interestingly, current implementation of add(..) does not match PEP
3119 [1] which calls for a boolean return value.

[1] http://www.python.org/dev/peps/pep-3119/#sets

----------

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

From report at bugs.python.org  Wed Nov  4 16:57:53 2009
From: report at bugs.python.org (ali)
Date: Wed, 04 Nov 2009 15:57:53 +0000
Subject: [issue7217] IDLE Subprocess Startup Error {Solved}
In-Reply-To: <1256630225.32.0.706380843912.issue7217@psf.upfronthosting.co.za>
Message-ID: <1257350273.71.0.664050494402.issue7217@psf.upfronthosting.co.za>


ali <mr.dalba at gmail.com> added the comment:

{Solved}
Thanks for following up Amaury
But my problem was solved yesterday.
There was a few programs in the main python directory which I didn't
want to delete, so I moved them to another directory and manually
deleted C:\Python26 and then restarted my computer. After installing
python again, the problem was solved.
Thanks again

----------
title: IDLE Subprocess Startup Error -> IDLE Subprocess Startup Error {Solved}

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

From report at bugs.python.org  Wed Nov  4 17:24:39 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 04 Nov 2009 16:24:39 +0000
Subject: [issue7263] Fix set.intersection docstring
In-Reply-To: <1257351879.79.0.961594941998.issue7263@psf.upfronthosting.co.za>
Message-ID: <1257351879.79.0.961594941998.issue7263@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

"""
intersection(...)
    Return the intersection of two sets as a new set.
    
    (i.e. all elements that are in both sets.)
"""

Is incorrect because set.intersection takes two or more sets.

Attached patch changes that to

"""
intersection(...)
    Return the intersection of two or more sets as a new set.
    
    (i.e. all elements that are in all sets.)
"""

----------
assignee: georg.brandl
components: Documentation
files: set-intersection-doc.diff
keywords: patch
messages: 94892
nosy: belopolsky, georg.brandl
severity: normal
status: open
title: Fix set.intersection docstring
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15257/set-intersection-doc.diff

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

From report at bugs.python.org  Wed Nov  4 17:33:04 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 04 Nov 2009 16:33:04 +0000
Subject: [issue7263] Fix set.intersection docstring
In-Reply-To: <1257351879.79.0.961594941998.issue7263@psf.upfronthosting.co.za>
Message-ID: <1257352384.55.0.651262605557.issue7263@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: georg.brandl -> rhettinger
nosy: +rhettinger

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

From report at bugs.python.org  Wed Nov  4 17:43:39 2009
From: report at bugs.python.org (Phillip J. Eby)
Date: Wed, 04 Nov 2009 16:43:39 +0000
Subject: [issue7250] wsgiref.handlers.CGIHandler caches os.environ,
	leaking info between requests
In-Reply-To: <1257147245.14.0.668660104401.issue7250@psf.upfronthosting.co.za>
Message-ID: <1257353019.69.0.857901207546.issue7250@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

I've forwarded the suggested fix to the GAE team; it is to add this line:

    os_environ = {}     # Handle GAE and other multi-run CGI use cases

to the class body of CGIHandler.  This should also be done in the Python
stdlib.

Btw, this fix can also be applied as a monkeypatch, by simply doing
'CGIHandler.os_environ = {}' before using CGIHandler.

----------
keywords: +26backport, easy, patch

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

From report at bugs.python.org  Wed Nov  4 17:54:36 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 04 Nov 2009 16:54:36 +0000
Subject: [issue7251] Mark expected failures of test_math,
	test_cmath and test_round as such.
In-Reply-To: <1257154985.1.0.42933155819.issue7251@psf.upfronthosting.co.za>
Message-ID: <1257353676.15.0.809447219592.issue7251@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

For 2.6.4 I get a test_float failure on Solaris as well:

test test_float failed -- Traceback (most recent call last):
 File "/home/tuba/skipm/src/python/Python-2.6.4/Lib/test/test_float.py",
line 765, in test_roundtrip
   self.identical(-x, roundtrip(-x))
 File "/home/tuba/skipm/src/python/Python-2.6.4/Lib/test/test_float.py",
line 375, in identical
   self.fail('%r not identical to %r' % (x, y))
AssertionError: -0.0 not identical to 0.0

Haven't looked at 2.7 or 3.1 yet, but it seems to fall into the same
class of test failures as the tanh(-0.0) critter.

----------
nosy: +skip.montanaro

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

From report at bugs.python.org  Wed Nov  4 18:21:00 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 04 Nov 2009 17:21:00 +0000
Subject: [issue7217] IDLE Subprocess Startup Error {Solved}
In-Reply-To: <1256630225.32.0.706380843912.issue7217@psf.upfronthosting.co.za>
Message-ID: <1257355260.14.0.474164357969.issue7217@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Wed Nov  4 19:02:09 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 04 Nov 2009 18:02:09 +0000
Subject: [issue7262] codecs.open() + eol (windows)
In-Reply-To: <1257344010.52.0.739143662559.issue7262@psf.upfronthosting.co.za>
Message-ID: <1257357729.23.0.910181654488.issue7262@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The docs say::
  Files are always opened in binary mode, even if no binary mode was
  specified. This is done to avoid data loss due to encodings using
  8-bit values. This means that no automatic conversion of '\n' is done
  on reading and writing.

But this does not match the code of codecs.open()::
    if encoding is not None and \
       'b' not in mode:
        # Force opening of the file in binary mode
        mode = mode + 'b'

When the encoding is None, the file is opened in text mode.
Marc-Andre, what do you think? is it a documentation bug instead?

----------
assignee:  -> lemburg
nosy: +amaury.forgeotdarc, lemburg

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

From report at bugs.python.org  Wed Nov  4 19:15:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Nov 2009 18:15:20 +0000
Subject: [issue7211] select module - kevent ident field 64 bit issue
In-Reply-To: <1256586883.91.0.341415015996.issue7211@psf.upfronthosting.co.za>
Message-ID: <1257358520.43.0.0238445909572.issue7211@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For me, the patch is worth trying out on the buildbots - to see if there
are any configuration problems we might have overlooked.

----------

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

From report at bugs.python.org  Wed Nov  4 19:15:53 2009
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 04 Nov 2009 18:15:53 +0000
Subject: [issue6292] Fix tests to work with -OO
In-Reply-To: <1245173156.41.0.295143421803.issue6292@psf.upfronthosting.co.za>
Message-ID: <1257358553.33.0.350031547054.issue6292@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I've attached a patch against trunk (r76107) which I think implements
more of what Antoine is looking for. It builds on Collin's patch but
uses unittest.skipIf to skip tests which shouldn't be run with -OO. It
also checks sys.flags.optimize in DocTestSuite and returns a suite with
a single skipped test as a placeholder in the case that -OO is used.

One thing that isn't really clean is that test_docxmlrpc has two skipped
tests and requires work to be done in the tearDown method after those
methods are skipped. Since setUp gets called even when the test will be
skipped, the server is started and blocking on getting a request, so I
just figure out if the test was skipped and do a request for it. Maybe
that's acceptable, I'm not sure. If anyone has a better way to figure
get around that, I'm all ears.

For comparison's sake, regrtest with -OO on r76107 results in 297 OK and
17 failed, and without optimize it results in 311/2. The patch results
in 311 OK and 2 failed for runs of regrtest both optimized and not, and
you can see the improvements more clearly when running the module-level
tests which were modified.

----------
nosy: +brian.curtin
Added file: http://bugs.python.org/file15258/issue6292_20091104_v1.patch

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

From report at bugs.python.org  Wed Nov  4 19:18:08 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 04 Nov 2009 18:18:08 +0000
Subject: [issue7262] codecs.open() + eol (windows)
In-Reply-To: <1257357729.23.0.910181654488.issue7262@psf.upfronthosting.co.za>
Message-ID: <4AF1C568.9000001@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
> 
> The docs say::
>   Files are always opened in binary mode, even if no binary mode was
>   specified. This is done to avoid data loss due to encodings using
>   8-bit values. This means that no automatic conversion of '\n' is done
>   on reading and writing.
> 
> But this does not match the code of codecs.open()::
>     if encoding is not None and \
>        'b' not in mode:
>         # Force opening of the file in binary mode
>         mode = mode + 'b'
> 
> When the encoding is None, the file is opened in text mode.
> Marc-Andre, what do you think? is it a documentation bug instead?

Agreed, it's a documentation bug. If no encoding is specified,
codecs.open() works just like the standard open() (except for
the default value of mode, but that's documented).

The idea was to provide a drop-in replacement for open() - with
the added encoding parameter support.

Perhaps the default mode should have been 'r' to match the
regular open() - I guess it's too late to change that, though.

----------

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

From report at bugs.python.org  Wed Nov  4 19:28:45 2009
From: report at bugs.python.org (Adam Doherty)
Date: Wed, 04 Nov 2009 18:28:45 +0000
Subject: [issue7144] imp.load_module in thread causes core dump on OSX 10.6
In-Reply-To: <1255635321.71.0.461133930779.issue7144@psf.upfronthosting.co.za>
Message-ID: <1257359325.17.0.321633326564.issue7144@psf.upfronthosting.co.za>


Adam Doherty <dohertywa at gmail.com> added the comment:

Hello:

Having the same issues in a web app I've written. Tested with the
default 2.5 and 2.6 on Snow Leopard and 2.5 on Ubuntu 8.04 (no problems
under Linux)  Replaced the default Python with 2.6.4 from python.org, my
app no longer crashes.

Hope it helps.

----------
nosy: +dohertywa

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

From report at bugs.python.org  Wed Nov  4 21:04:17 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Nov 2009 20:04:17 +0000
Subject: [issue7264] test_threading_local sometimes hangs when run with -R
In-Reply-To: <1257365057.55.0.816079780185.issue7264@psf.upfronthosting.co.za>
Message-ID: <1257365057.55.0.816079780185.issue7264@psf.upfronthosting.co.za>


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

If I run something like:
  ./python -m test.regrtest -R3:2: test_threading_local

Python sometimes hangs and I have to "kill -9" it.

Running through gdb shows it gets stuck at the following point:

/home/antoine/cpython/debug/Lib/threading.py (239): wait
/home/antoine/cpython/debug/Lib/threading.py (638): join
/home/antoine/cpython/debug/Lib/test/test_threading_local.py (68):
test_derived
[snip]

That is, it hangs waiting for a thread to join().

----------
components: Library (Lib), Tests
messages: 94900
nosy: gps, pitrou
priority: normal
severity: normal
status: open
title: test_threading_local sometimes hangs when run with -R
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov  4 21:23:12 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Nov 2009 20:23:12 +0000
Subject: [issue7264] test_threading_local sometimes hangs when run with -R
In-Reply-To: <1257365057.55.0.816079780185.issue7264@psf.upfronthosting.co.za>
Message-ID: <1257366192.74.0.459548396253.issue7264@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It turns out that the __del__ method in _threading_local.py tries to
call threading.enumerate() which itself takes the _active_limbo_lock.
The problem is that __del__ can be called at any point in time (because
of the GC), including at a point where the same thread has already taken
the lock. The obvious fix is to bypass enumerate().

(an alternate fix would be to use an RLock for _active_limbo_lock, but
it could have unforeseen consequences, such as performance ones)

----------
keywords: +patch
Added file: http://bugs.python.org/file15259/threading_local.patch

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

From report at bugs.python.org  Wed Nov  4 21:23:59 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Nov 2009 20:23:59 +0000
Subject: [issue7264] test_threading_local sometimes hangs when run with -R
In-Reply-To: <1257365057.55.0.816079780185.issue7264@psf.upfronthosting.co.za>
Message-ID: <1257366239.81.0.475763974355.issue7264@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> patch review

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

From report at bugs.python.org  Wed Nov  4 21:24:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Nov 2009 20:24:10 +0000
Subject: [issue7264] test_threading_local sometimes hangs when run with -R
In-Reply-To: <1257365057.55.0.816079780185.issue7264@psf.upfronthosting.co.za>
Message-ID: <1257366250.91.0.22105135362.issue7264@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 2.6, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Nov  4 22:33:44 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 04 Nov 2009 21:33:44 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1221572918.25.0.474796677446.issue3881@psf.upfronthosting.co.za>
Message-ID: <1257370424.53.0.507159657649.issue3881@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
nosy: +srid

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

From report at bugs.python.org  Wed Nov  4 22:53:55 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Nov 2009 21:53:55 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1257371635.6.0.870722938455.issue2054@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I noticed you were using ftp.python.org in the example strings, but that
service doesn't seem to be alive. I don't know if there's another public
FTP-TLS server you could rely on...?

----------

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

From report at bugs.python.org  Wed Nov  4 22:56:43 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 04 Nov 2009 21:56:43 +0000
Subject: [issue7251] Mark expected failures of test_math,
	test_cmath and test_round as such.
In-Reply-To: <1257154985.1.0.42933155819.issue7251@psf.upfronthosting.co.za>
Message-ID: <1257371803.51.0.45068409615.issue7251@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

May be one day python modules will deal with TANH_PRESERVES_ZERO_SIGN
set by configure check.

----------
nosy: +rpetrov

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

From report at bugs.python.org  Wed Nov  4 22:57:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Nov 2009 21:57:51 +0000
Subject: [issue7211] select module - kevent ident field 64 bit issue
In-Reply-To: <1256586883.91.0.341415015996.issue7211@psf.upfronthosting.co.za>
Message-ID: <1257371871.13.0.657049525585.issue7211@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch was committed in r76108 (trunk) and r76111 (py3k) and didn't
introduce any regression on the FreeBSD and OS X buildbots. Thanks!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Nov  4 23:02:06 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Nov 2009 22:02:06 +0000
Subject: [issue2499] Fold unary + and not on constants
In-Reply-To: <1206677118.63.0.142364619401.issue2499@psf.upfronthosting.co.za>
Message-ID: <1257372126.88.0.302135147384.issue2499@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Folding UNARY_POSITIVE was done by Raymond in r75601.

----------
nosy: +pitrou

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

From report at bugs.python.org  Wed Nov  4 23:04:31 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 04 Nov 2009 22:04:31 +0000
Subject: [issue3754] minimal cross-compilation support for configure
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1257372271.03.0.942876026893.issue3754@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Added file: http://bugs.python.org/file15260/python-trunk-20091104-CROSS.patch

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

From report at bugs.python.org  Wed Nov  4 23:06:49 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 04 Nov 2009 22:06:49 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1257372409.87.0.0186873727062.issue3871@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Added file: http://bugs.python.org/file15261/python-trunk-20091104-MINGW.patch

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

From report at bugs.python.org  Wed Nov  4 23:27:15 2009
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 04 Nov 2009 22:27:15 +0000
Subject: [issue5774] _winreg.OpenKey() is documented with keyword arguments,
	but doesn't take them
In-Reply-To: <1239908773.0.0.157202779439.issue5774@psf.upfronthosting.co.za>
Message-ID: <1257373635.73.0.380504512978.issue5774@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Attached is a patch against trunk r76107 which fixes OpenKey to take
keyword arguments as the documentation states. There is also a small fix
to test_winreg - the third param to OpenKey on line 45 is the `res`
positional param, which should always be zero according to the doc. The
parameter passed is supposed to be the `sam` parameter, which is now
passed as a kwarg. There is no actual change to the test results.


While looking at this, I'm not sure I see the need for OpenKeyEx - it
just points to OpenKey. At the very least, it's parameter list in the
documentation is incorrect.

----------
keywords: +patch
nosy: +brian.curtin
Added file: http://bugs.python.org/file15262/issue5774_20091104_v1.patch

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

From report at bugs.python.org  Wed Nov  4 23:39:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Nov 2009 22:39:43 +0000
Subject: [issue6509] re.py - <compiled byte-object regular expr> encounter
	unexpected str-object
In-Reply-To: <1247876846.09.0.430669746251.issue6509@psf.upfronthosting.co.za>
Message-ID: <1257374383.84.0.077757157529.issue6509@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch.

----------
keywords: +patch
nosy: +effbot
stage:  -> patch review
Added file: http://bugs.python.org/file15263/parse_template.patch

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

From report at bugs.python.org  Wed Nov  4 23:46:02 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Nov 2009 22:46:02 +0000
Subject: [issue4199] add shorthand global and nonlocal statements
In-Reply-To: <1224887535.03.0.272495603252.issue4199@psf.upfronthosting.co.za>
Message-ID: <1257374762.96.0.35066679382.issue4199@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority: critical -> normal

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

From report at bugs.python.org  Thu Nov  5 00:19:02 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 04 Nov 2009 23:19:02 +0000
Subject: [issue7264] test_threading_local sometimes hangs when run with -R
In-Reply-To: <1257365057.55.0.816079780185.issue7264@psf.upfronthosting.co.za>
Message-ID: <1257376742.74.0.351226963644.issue7264@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

How about defining this in threading.py:

def _enumerate():
    """Internal use only: enumerate() without the lock."""
    return _active.values() + _limbo.values()

And calling it from _threading_local instead of accessing _active and
_limbo directly.

----------
nosy: +gregory.p.smith

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

From report at bugs.python.org  Thu Nov  5 00:24:41 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Nov 2009 23:24:41 +0000
Subject: [issue7264] test_threading_local sometimes hangs when run with -R
In-Reply-To: <1257365057.55.0.816079780185.issue7264@psf.upfronthosting.co.za>
Message-ID: <1257377081.7.0.347487310515.issue7264@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Good point. Here is a new patch.

----------
Added file: http://bugs.python.org/file15264/threading_local2.patch

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

From report at bugs.python.org  Thu Nov  5 00:35:59 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 04 Nov 2009 23:35:59 +0000
Subject: [issue2499] Fold unary + and not on constants
In-Reply-To: <1206677118.63.0.142364619401.issue2499@psf.upfronthosting.co.za>
Message-ID: <1257377759.08.0.794897358275.issue2499@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger

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

From report at bugs.python.org  Thu Nov  5 00:37:19 2009
From: report at bugs.python.org (Rich Healey)
Date: Wed, 04 Nov 2009 23:37:19 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1257377839.56.0.470118537164.issue7206@psf.upfronthosting.co.za>


Rich Healey <richo at psych0tik.net> added the comment:

Download the debugging suite from
http://www.microsoft.com/whdc/devtools/debugging/install64bit.mspx#

Open windbg
Press Ctrl + E to load an executable
Select your python binary
Step through by typing g in the text box at the bottom of the Command
window.

The application will fail to crash completely as windbg will catch the
exception, however you should notice that it's spitting out duplicate
errors after a few breaks.

Paste up your log :)

----------

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

From report at bugs.python.org  Thu Nov  5 02:17:58 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 05 Nov 2009 01:17:58 +0000
Subject: [issue7248] test_importlib uses a fixed name in /tmp
In-Reply-To: <1257115280.67.0.551284747455.issue7248@psf.upfronthosting.co.za>
Message-ID: <1257383878.41.0.874515145918.issue7248@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

r76113 fixes the name problem in py3k. After I fix the other issue I will 
backport to 3.1.

----------

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

From report at bugs.python.org  Thu Nov  5 02:31:01 2009
From: report at bugs.python.org (Carey)
Date: Thu, 05 Nov 2009 01:31:01 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1257384661.29.0.482904819091.issue7206@psf.upfronthosting.co.za>


Carey <carey.metcalfe at gmail.com> added the comment:

I dont know if what i did was right but heres my log


Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: C:\Python31\pythonw.exe
Symbol search path is: srv*
Executable search path is: 
ModLoad: 00000000`1d000000 00000000`1d00b000   pythonw.exe
ModLoad: 00000000`76f20000 00000000`770cb000   ntdll.dll
ModLoad: 00000000`76e00000 00000000`76f1f000  
C:\Windows\system32\kernel32.dll
ModLoad: 000007fe`fd1e0000 000007fe`fd24b000  
C:\Windows\system32\KERNELBASE.dll
ModLoad: 00000000`1e000000 00000000`1e2b0000  
C:\Windows\system32\python31.dll
ModLoad: 00000000`76d00000 00000000`76dfa000  
C:\Windows\system32\USER32.dll
ModLoad: 000007fe`ff1c0000 000007fe`ff227000   C:\Windows\system32\GDI32.dll
ModLoad: 000007fe`ff1b0000 000007fe`ff1be000   C:\Windows\system32\LPK.dll
ModLoad: 000007fe`fd380000 000007fe`fd44a000   C:\Windows\system32\USP10.dll
ModLoad: 000007fe`fdb30000 000007fe`fdbcf000  
C:\Windows\system32\msvcrt.dll
ModLoad: 000007fe`fda50000 000007fe`fdb2b000  
C:\Windows\system32\ADVAPI32.dll
ModLoad: 000007fe`fdd00000 000007fe`fdd1f000  
C:\Windows\SYSTEM32\sechost.dll
ModLoad: 000007fe`fd250000 000007fe`fd37e000  
C:\Windows\system32\RPCRT4.dll
ModLoad: 000007fe`fdf00000 000007fe`fec86000  
C:\Windows\system32\SHELL32.dll
ModLoad: 000007fe`fec90000 000007fe`fed01000  
C:\Windows\system32\SHLWAPI.dll
ModLoad: 00000000`730a0000 00000000`7313d000  
C:\Windows\WinSxS\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4926_none_08e1a05ba83fe554\MSVCR90.dll
(1284.19dc): Break instruction exception - code 80000003 (first chance)
ntdll!LdrpDoDebuggerBreak+0x30:
00000000`76fd1220 cc              int     3
0:000> g
ModLoad: 000007fe`fcd50000 000007fe`fcda7000  
C:\Windows\system32\apphelp.dll
ModLoad: 000007fe`fd810000 000007fe`fd83e000   C:\Windows\system32\IMM32.DLL
ModLoad: 000007fe`fed90000 000007fe`fee99000   C:\Windows\system32\MSCTF.dll
ntdll!NtTerminateProcess+0xa:
00000000`76f7017a c3              ret
0:000> g
       ^ No runnable debuggees error in 'g'
0:000> g
       ^ No runnable debuggees error in 'g'



It seems it cant find a file that it needs, but i dont know why.
Obviously this is a different issue

----------

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

From report at bugs.python.org  Thu Nov  5 02:34:47 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 05 Nov 2009 01:34:47 +0000
Subject: [issue7248] test_importlib uses a fixed name in /tmp
In-Reply-To: <1257115280.67.0.551284747455.issue7248@psf.upfronthosting.co.za>
Message-ID: <1257384887.64.0.437520330498.issue7248@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

r76114 has the temp directory fix. r76115 has the backport to 3.1.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Thu Nov  5 02:47:44 2009
From: report at bugs.python.org (Rich Healey)
Date: Thu, 05 Nov 2009 01:47:44 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1257385664.25.0.131004984253.issue7206@psf.upfronthosting.co.za>


Rich Healey <richo at psych0tik.net> added the comment:

Carey: You need to run python.exe, pythonw.exe does not create a console
window and is for running python scripts that have their own GUI.

----------

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

From report at bugs.python.org  Thu Nov  5 02:54:04 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 Nov 2009 01:54:04 +0000
Subject: [issue6462] bsddb3 intermittent test failures
In-Reply-To: <1247329933.16.0.47150397.issue6462@psf.upfronthosting.co.za>
Message-ID: <1257386044.89.0.0608888834452.issue6462@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I was able to consistently reproduce the timeout on my Gentoo buildbot
running in a vserver virthost.  After some experimentation and perusing
the related issue 3892, I discovered that by increasing the timeout I
could get the test to consistently pass in my buildbot.  However, it
does occasionally produce the DB_LOCK_DEADLOCK traceback in one of the
threads. (Two times out of about 17 runs in a loop).

I've checked an increase in the timeout for the two replication tests
into trunk in r76116.  In some of my experiments it was clear that the
base replication case is much quicker than the ReplicationManager case,
so I made the ReplicationManager timeout longer.  I'm hoping this will
fix the line 315 failure in the windows buildbot, since it does
sometimes pass.

----------

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

From report at bugs.python.org  Thu Nov  5 03:38:58 2009
From: report at bugs.python.org (Carey)
Date: Thu, 05 Nov 2009 02:38:58 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1257388738.95.0.424385509575.issue7206@psf.upfronthosting.co.za>


Carey <carey.metcalfe at gmail.com> added the comment:

python.exe works fine. It's IDLE that doesn't work and it uses pythonw.exe.

----------

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

From report at bugs.python.org  Thu Nov  5 04:40:26 2009
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 05 Nov 2009 03:40:26 +0000
Subject: [issue4722] _winreg.QueryValue fault while reading mangled registry
	values
In-Reply-To: <1229958391.62.0.85659959701.issue4722@psf.upfronthosting.co.za>
Message-ID: <1257392426.89.0.195283374458.issue4722@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

The attached patch will return "" in the case that Alex describes.
However, I haven't been able to reproduce his actions outside of
manually running the steps, so I don't have a test written for it.
Anyone know how to reproduce it from code?

----------
keywords: +patch
nosy: +brian.curtin
Added file: http://bugs.python.org/file15265/issue4722_20091104_v1.patch

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

From report at bugs.python.org  Thu Nov  5 05:47:00 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 05 Nov 2009 04:47:00 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1257388738.95.0.424385509575.issue7206@psf.upfronthosting.co.za>
Message-ID: <4AF258C1.8010206@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> python.exe works fine. It's IDLE that doesn't work and it uses pythonw.exe.

So please report this as a separate bug. For the OP, python.exe crashes.

----------

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

From report at bugs.python.org  Thu Nov  5 05:51:12 2009
From: report at bugs.python.org (Carey)
Date: Thu, 05 Nov 2009 04:51:12 +0000
Subject: [issue7265] IDLE not working
In-Reply-To: <1257396672.49.0.0556052422115.issue7265@psf.upfronthosting.co.za>
Message-ID: <1257396672.49.0.0556052422115.issue7265@psf.upfronthosting.co.za>


New submission from Carey <carey.metcalfe at gmail.com>:

IDLE will not open in windows 7 64 bit

My debug log is as follows:


Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: C:\Python31\pythonw.exe
Symbol search path is: srv*
Executable search path is: 
ModLoad: 00000000`1d000000 00000000`1d00b000   pythonw.exe
ModLoad: 00000000`76f20000 00000000`770cb000   ntdll.dll
ModLoad: 00000000`76e00000 00000000`76f1f000  
C:\Windows\system32\kernel32.dll
ModLoad: 000007fe`fd1e0000 000007fe`fd24b000  
C:\Windows\system32\KERNELBASE.dll
ModLoad: 00000000`1e000000 00000000`1e2b0000  
C:\Windows\system32\python31.dll
ModLoad: 00000000`76d00000 00000000`76dfa000  
C:\Windows\system32\USER32.dll
ModLoad: 000007fe`ff1c0000 000007fe`ff227000   C:\Windows\system32\GDI32.dll
ModLoad: 000007fe`ff1b0000 000007fe`ff1be000   C:\Windows\system32\LPK.dll
ModLoad: 000007fe`fd380000 000007fe`fd44a000   C:\Windows\system32\USP10.dll
ModLoad: 000007fe`fdb30000 000007fe`fdbcf000  
C:\Windows\system32\msvcrt.dll
ModLoad: 000007fe`fda50000 000007fe`fdb2b000  
C:\Windows\system32\ADVAPI32.dll
ModLoad: 000007fe`fdd00000 000007fe`fdd1f000  
C:\Windows\SYSTEM32\sechost.dll
ModLoad: 000007fe`fd250000 000007fe`fd37e000  
C:\Windows\system32\RPCRT4.dll
ModLoad: 000007fe`fdf00000 000007fe`fec86000  
C:\Windows\system32\SHELL32.dll
ModLoad: 000007fe`fec90000 000007fe`fed01000  
C:\Windows\system32\SHLWAPI.dll
ModLoad: 00000000`730a0000 00000000`7313d000  
C:\Windows\WinSxS\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4926_none_08e1a05ba83fe554\MSVCR90.dll
(1284.19dc): Break instruction exception - code 80000003 (first chance)
ntdll!LdrpDoDebuggerBreak+0x30:
00000000`76fd1220 cc              int     3
0:000> g
ModLoad: 000007fe`fcd50000 000007fe`fcda7000  
C:\Windows\system32\apphelp.dll
ModLoad: 000007fe`fd810000 000007fe`fd83e000   C:\Windows\system32\IMM32.DLL
ModLoad: 000007fe`fed90000 000007fe`fee99000   C:\Windows\system32\MSCTF.dll
ntdll!NtTerminateProcess+0xa:
00000000`76f7017a c3              ret
0:000> g
       ^ No runnable debuggees error in 'g'
0:000> g
       ^ No runnable debuggees error in 'g'



It seems it cant find a file that it needs, but i dont know why.

----------
components: IDLE
messages: 94919
nosy: Carey
severity: normal
status: open
title: IDLE not working
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Thu Nov  5 05:57:46 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 05 Nov 2009 04:57:46 +0000
Subject: [issue7265] IDLE not working
In-Reply-To: <1257396672.49.0.0556052422115.issue7265@psf.upfronthosting.co.za>
Message-ID: <1257397066.56.0.54918427114.issue7265@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please open a shell (cmd.exe), then

cd c:\python31
python.exe Lib\idlelib\idle.py

and report any python error messages that you receive.

----------
nosy: +loewis

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

From report at bugs.python.org  Thu Nov  5 07:24:24 2009
From: report at bugs.python.org (Rich Healey)
Date: Thu, 05 Nov 2009 06:24:24 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1257402264.09.0.747998679983.issue7206@psf.upfronthosting.co.za>


Rich Healey <richo at psych0tik.net> added the comment:

Precisely.

Martin: What more can I do to help? I really need 64 bit Python working
on this machine but am running out of things I can do.

Am happy to put in the hard yards, just need clarification about what I
should be doing.

----------

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

From report at bugs.python.org  Thu Nov  5 07:32:22 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 05 Nov 2009 06:32:22 +0000
Subject: [issue7264] test_threading_local sometimes hangs when run with -R
In-Reply-To: <52dc1c820911042231i1acd087es2d091c2d70e0e259@mail.gmail.com>
Message-ID: <52dc1c820911042232m2e048dcfo481559b8e6415c34@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

Looks good to me.

typed poorly on a tiny Android phone.

On Nov 4, 2009 3:24 PM, "Antoine Pitrou" <report at bugs.python.org> wrote:

Antoine Pitrou <pitrou at free.fr> added the comment:

Good point. Here is a new patch.

----------
Added file: http://bugs.python.org/file15264/threading_local2.patch

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

----------
Added file: http://bugs.python.org/file15266/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7264>
_______________________________________
-------------- next part --------------
<p>Looks good to me.</p>
<p>typed poorly on a tiny Android phone.</p>
<p><blockquote type="cite">On Nov 4, 2009 3:24 PM, &quot;Antoine Pitrou&quot; &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt; wrote:<br><br><br>
Antoine Pitrou &lt;<a href="mailto:pitrou at free.fr">pitrou at free.fr</a>&gt; added the comment:<br>
<br>
Good point. Here is a new patch.<br>
<br>
----------<br>
Added file: <a href="http://bugs.python.org/file15264/threading_local2.patch" target="_blank">http://bugs.python.org/file15264/threading_local2.patch</a><br>
<p><font color="#500050">
_______________________________________
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;
&lt;<a href="http://bugs.python.">http://bugs.python.</a>..</font></p></blockquote></p>

From report at bugs.python.org  Thu Nov  5 09:11:02 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 05 Nov 2009 08:11:02 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1257402264.09.0.747998679983.issue7206@psf.upfronthosting.co.za>
Message-ID: <4AF28892.4000109@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Am happy to put in the hard yards, just need clarification about what I
> should be doing.

The only thing I can think of is debugging. Install visual studio,
create a debug build of Python, hope that it will still crash, and
debug why it does. Alternatively, run the release build in a debugger...

----------

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

From report at bugs.python.org  Thu Nov  5 11:40:31 2009
From: report at bugs.python.org (Brandon Bloom)
Date: Thu, 05 Nov 2009 10:40:31 +0000
Subject: [issue7250] wsgiref.handlers.CGIHandler caches os.environ,
	leaking info between requests
In-Reply-To: <1257353019.69.0.857901207546.issue7250@psf.upfronthosting.co.za>
Message-ID: <b2126670911050240q4b9e6923s3dce48c9f90aad7@mail.gmail.com>


Brandon Bloom <snprbob86 at gmail.com> added the comment:

> I've forwarded the suggested fix to the GAE team; it is to add this line:
>
> ? ?os_environ = {} ? ? # Handle GAE and other multi-run CGI use cases
>
> to the class body of CGIHandler. ?This should also be done in the Python
> stdlib.

I don't think that works. This still shares a common os_environ across
requests. You need to clear the dictionary after every request.

----------

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

From report at bugs.python.org  Thu Nov  5 14:36:33 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 05 Nov 2009 13:36:33 +0000
Subject: [issue7251] Mark expected failures of test_math,
	test_cmath and test_round as such.
In-Reply-To: <1257154985.1.0.42933155819.issue7251@psf.upfronthosting.co.za>
Message-ID: <1257428193.01.0.233717121438.issue7251@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Skip, that looks like a float.hex failure.  I'm not sure what the 
underlying problem is here;  my best guess is that it's something to do 
with the copysign function.  Please could you tell me what the Solaris 
results are for the following interactive session? (Results shown are on 
OS X 10.5.)

Python 2.6.4+ (release26-maint:76116, Nov  5 2009, 13:30:59) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> (-0.0).hex()
'-0x0.0p+0'
>>> float.fromhex((-0.0).hex())
-0.0
>>> math.copysign(1.0, -0.0)
-1.0

Also, is HAVE_COPYSIGN defined in pyconfig.h?

----------

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

From report at bugs.python.org  Thu Nov  5 14:38:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Nov 2009 13:38:04 +0000
Subject: [issue7264] test_threading_local sometimes hangs when run with -R
In-Reply-To: <1257365057.55.0.816079780185.issue7264@psf.upfronthosting.co.za>
Message-ID: <1257428284.73.0.805714788663.issue7264@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file15266/unnamed

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

From report at bugs.python.org  Thu Nov  5 14:41:13 2009
From: report at bugs.python.org (Carey)
Date: Thu, 05 Nov 2009 13:41:13 +0000
Subject: [issue7265] IDLE not working
In-Reply-To: <1257396672.49.0.0556052422115.issue7265@psf.upfronthosting.co.za>
Message-ID: <1257428473.9.0.206339472537.issue7265@psf.upfronthosting.co.za>


Carey <carey.metcalfe at gmail.com> added the comment:

Running as an admin in Windows 7 64 bit


C:\>cd python31
cd python31

C:\Python31>python.exe lib/idlelib/idle.py
python.exe lib/idlelib/idle.py
Traceback (most recent call last):
  File "lib/idlelib/idle.py", line 11, in <module>
    idlelib.PyShell.main()
  File "C:\Python31\lib\idlelib\PyShell.py", line 1388, in main
    shell = flist.open_shell()
  File "C:\Python31\lib\idlelib\PyShell.py", line 277, in open_shell
    self.pyshell = PyShell(self)
  File "C:\Python31\lib\idlelib\PyShell.py", line 813, in __init__
    OutputWindow.__init__(self, flist, None, None)
  File "C:\Python31\lib\idlelib\OutputWindow.py", line 16, in __init__
    EditorWindow.__init__(self, *args)
  File "C:\Python31\lib\idlelib\EditorWindow.py", line 261, in __init__
    self.update_recent_files_list()
  File "C:\Python31\lib\idlelib\EditorWindow.py", line 779, in
update_recent_files_list
    rf_file = open(self.recent_files_path, 'w')
IOError: [Errno 13] Permission denied: 'C:\\Users\\Carey
Metcalfe\\.idlerc\\recent-files.lst'


It seems to not be able to access the recent files list (which does
exist, i checked)

The same issue is here: http://bugs.python.org/issue1743

----------

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

From report at bugs.python.org  Thu Nov  5 14:43:49 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 05 Nov 2009 13:43:49 +0000
Subject: [issue7251] Mark expected failures of test_math,
	test_cmath and test_round as such.
In-Reply-To: <1257154985.1.0.42933155819.issue7251@psf.upfronthosting.co.za>
Message-ID: <1257428629.78.0.0232744955796.issue7251@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> May be one day python modules will deal with TANH_PRESERVES_ZERO_SIGN
> set by configure check.

Maybe.  I added that configure check mainly as a diagnostic, to verify a 
suspected cause of test failures.  I'm not sure to what degree it's worth 
working around system libm bugs in the Python source:  an explosion of 
#ifdefs in mathmodule.c and cmathmodule.c would reduce readability and 
maintainability.

----------

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

From report at bugs.python.org  Thu Nov  5 14:47:01 2009
From: report at bugs.python.org (Carey)
Date: Thu, 05 Nov 2009 13:47:01 +0000
Subject: [issue1743] IDLE fails to launch
In-Reply-To: <1199623661.98.0.40278746371.issue1743@psf.upfronthosting.co.za>
Message-ID: <1257428821.25.0.0245089014805.issue1743@psf.upfronthosting.co.za>


Carey <carey.metcalfe at gmail.com> added the comment:

I also had the same problem in Windows 7 64 bit. I unhid the file and
everything works now

----------
nosy: +Carey
versions: +Python 3.1

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

From report at bugs.python.org  Thu Nov  5 14:48:50 2009
From: report at bugs.python.org (Carey)
Date: Thu, 05 Nov 2009 13:48:50 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1257428930.59.0.479924026232.issue7206@psf.upfronthosting.co.za>


Carey <carey.metcalfe at gmail.com> added the comment:

In the other issue there was a fix that involved unhiding the recent
files list. I unhid the files in the .idlerc folder and everthing works now.

----------

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

From report at bugs.python.org  Thu Nov  5 14:53:04 2009
From: report at bugs.python.org (Carey)
Date: Thu, 05 Nov 2009 13:53:04 +0000
Subject: [issue7265] IDLE not working
In-Reply-To: <1257396672.49.0.0556052422115.issue7265@psf.upfronthosting.co.za>
Message-ID: <1257429184.21.0.121490879483.issue7265@psf.upfronthosting.co.za>


Carey <carey.metcalfe at gmail.com> added the comment:

In the other issue there was a fix that involved unhiding the recent
files list. I unhid the files in the .idlerc folder and everthing works now.

----------

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

From report at bugs.python.org  Thu Nov  5 15:42:06 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Nov 2009 14:42:06 +0000
Subject: [issue7264] test_threading_local sometimes hangs when run with -R
In-Reply-To: <1257365057.55.0.816079780185.issue7264@psf.upfronthosting.co.za>
Message-ID: <1257432126.04.0.896677907151.issue7264@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed, thanks.

----------

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

From report at bugs.python.org  Thu Nov  5 15:42:14 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Nov 2009 14:42:14 +0000
Subject: [issue7264] test_threading_local sometimes hangs when run with -R
In-Reply-To: <1257365057.55.0.816079780185.issue7264@psf.upfronthosting.co.za>
Message-ID: <1257432134.81.0.0800724479345.issue7264@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Nov  5 15:49:19 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 Nov 2009 14:49:19 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails on Windows sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1257432559.14.0.70637327567.issue3892@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I changed the timeout to +30, and the bsddb3 test has been passing on
the windows buildbot.  That buildbot is a virtualbox instance running on
a P4, so it makes sense that it just took a long time for the (second)
test to pass.  While testing I noticed that on my gentoo buildbot the
ReplicationManager test would time out but the base test would pass...so
I wonder if the test that is currently being skipped would pass if you
gave that windows buildbot even longer to think about it.  But since
bsddb3 isn't in py3k, I'm not inclined to take the time to find out.

----------
nosy: +r.david.murray
versions: +Python 2.7

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

From report at bugs.python.org  Thu Nov  5 16:06:31 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Nov 2009 15:06:31 +0000
Subject: [issue7266] test_lib2to3 failure under Windows
In-Reply-To: <1257433591.14.0.555852020916.issue7266@psf.upfronthosting.co.za>
Message-ID: <1257433591.14.0.555852020916.issue7266@psf.upfronthosting.co.za>


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

test_lib2to3 fails deterministically on the Windows buildbots:

test test_lib2to3 failed -- Traceback (most recent call last):
  File
"E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\lib2to3\tests\test_parser.py",
line 161, in test_all_project_files
    self.fail("Idempotency failed: %s" % filepath)
AssertionError: Idempotency failed:
E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\lib2to3\fixer_base.py

If you look at the logs (*), you'll see that it's apparently just a
newline issue. Either the test should be modified to ignore newline
style changes, or lib2to3 should be fixed to output the same kind of
newlines it encountered on input.

(*) e.g.
http://www.python.org/dev/buildbot/trunk.stable/builders/x86%20XP-4%20trunk/builds/2590/steps/test/logs/stdio

----------
assignee: benjamin.peterson
components: 2to3 (2.x to 3.0 conversion tool)
messages: 94933
nosy: benjamin.peterson, pitrou
priority: normal
severity: normal
status: open
title: test_lib2to3 failure under Windows
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov  5 16:12:52 2009
From: report at bugs.python.org (Rich)
Date: Thu, 05 Nov 2009 15:12:52 +0000
Subject: [issue1743] IDLE fails to launch
In-Reply-To: <1199623661.98.0.40278746371.issue1743@psf.upfronthosting.co.za>
Message-ID: <1257433972.11.0.355768210438.issue1743@psf.upfronthosting.co.za>


Changes by Rich <richjtd at gmail.com>:


----------
nosy:  -richjtd

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

From report at bugs.python.org  Thu Nov  5 16:39:51 2009
From: report at bugs.python.org (Phillip J. Eby)
Date: Thu, 05 Nov 2009 15:39:51 +0000
Subject: [issue7250] wsgiref.handlers.CGIHandler caches os.environ,
	leaking info between requests
In-Reply-To: <1257147245.14.0.668660104401.issue7250@psf.upfronthosting.co.za>
Message-ID: <1257435591.08.0.58238876008.issue7250@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

The os_environ attribute is only used in one place; this line:

   env = self.environ = self.os_environ.copy()

So, nothing is shared.

----------

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

From report at bugs.python.org  Thu Nov  5 17:00:38 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 Nov 2009 16:00:38 +0000
Subject: [issue7266] test_lib2to3 failure under Windows
In-Reply-To: <1257433591.14.0.555852020916.issue7266@psf.upfronthosting.co.za>
Message-ID: <1257436838.43.0.335814481301.issue7266@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords: +buildbot

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

From report at bugs.python.org  Thu Nov  5 17:22:48 2009
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Thu, 05 Nov 2009 16:22:48 +0000
Subject: [issue7267] format method: c presentation type broken
In-Reply-To: <1257438168.68.0.774312526176.issue7267@psf.upfronthosting.co.za>
Message-ID: <1257438168.68.0.774312526176.issue7267@psf.upfronthosting.co.za>


New submission from Walter D?rwald <walter at livinglogic.de>:

The c presentation type in the new format method from PEP 3101 seems to
be broken:

Python 2.6.4 (r264:75706, Oct 27 2009, 15:18:04) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> u'{0:c}'.format(256)
u'\x00'

The PEP states:

'c' - Character. Converts the integer to the corresponding Unicode
character before printing, so I would have expected this to return
u'\u0100' instead of u'\x00'.

----------
components: Interpreter Core
messages: 94935
nosy: doerwalter
severity: normal
status: open
title: format method: c presentation type broken
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Nov  5 17:30:32 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 05 Nov 2009 16:30:32 +0000
Subject: [issue7267] format method: c presentation type broken
In-Reply-To: <1257438168.68.0.774312526176.issue7267@psf.upfronthosting.co.za>
Message-ID: <1257438632.41.0.746679685626.issue7267@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I'll look at it.

----------
assignee:  -> eric.smith
nosy: +eric.smith

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

From report at bugs.python.org  Thu Nov  5 18:53:12 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 05 Nov 2009 17:53:12 +0000
Subject: [issue7077] SysLogHandler can't handle Unicode
In-Reply-To: <1254919358.82.0.721761611674.issue7077@psf.upfronthosting.co.za>
Message-ID: <1257443592.63.0.899203628462.issue7077@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

No adverse feedback on fix, so closing.

----------
status: pending -> closed

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

From report at bugs.python.org  Thu Nov  5 19:42:07 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 Nov 2009 18:42:07 +0000
Subject: [issue7212] Retrieve an arbitrary element from a set without removing
	it
In-Reply-To: <1256591239.7.0.409642892772.issue7212@psf.upfronthosting.co.za>
Message-ID: <1257446527.81.0.162339678343.issue7212@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

After a long discussion on python-dev, this proposal is rejected in
favor of adding documentation notes on the ways to non-destructively
retrieve an arbitrary item from a set or frozenset.

Here is an except from the end of the thread:

[Steven D'Aprano]
>> Anyway, given the level of opposition to the suggestion, I'm no longer
>> willing to carry the flag for it. If anyone else -- perhaps the OP --
>> feels they want to take it any further, be my guest.

[geremy condra]
> I've said before that I'd like there to be one, standard way of
> doing this. A function call- set.pick() seems reasonably named
> to me- is probably the cleanest way to do that. Absent that,
> an example in the docs that illustrates the preferred idiom
> would be great. 

[Raymond]
Summarizing my opposition to a new set method:
1) there already are at least two succinct ways to get the same effect
2) those ways work with any container, not just sets
3) set implementations in other languages show that this isn't needed.
4) there is value to keeping the API compact
5) isn't needed for optimization (selecting the same value in a loop
makes no sense)
6) absence of real-world code examples that would be meaningfully improved

[Terry Reedy]
Agreed

[Raymond]
I would be happy to add an example to the docs so that this thread
can finally end.

[Eric Smith]
Please do!

[Terry Reedy]
Yes!
'''


Leaving this open until I've done the documentation patch.

----------
priority:  -> low
resolution:  -> rejected

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

From report at bugs.python.org  Thu Nov  5 19:46:22 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 Nov 2009 18:46:22 +0000
Subject: [issue1182143] making builtin exceptions more informative
Message-ID: <1257446782.22.0.377036422583.issue1182143@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: rhettinger -> 

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

From report at bugs.python.org  Thu Nov  5 19:57:35 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 05 Nov 2009 18:57:35 +0000
Subject: [issue7212] Retrieve an arbitrary element from a set without removing
	it
In-Reply-To: <1256591239.7.0.409642892772.issue7212@psf.upfronthosting.co.za>
Message-ID: <1257447455.52.0.29105584299.issue7212@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I don't want to pollute python-dev with more hopeless ideas, but I wonder 
if itertools could grow an efficient C-implemented

def first(collection):
   return next(iter(collection))

On the other hand, it probably belongs to recipes more than stdlib.  This 
is not really an iterator tool after all.

----------

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

From report at bugs.python.org  Thu Nov  5 20:16:02 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 Nov 2009 19:16:02 +0000
Subject: [issue7224] One obvious way to do interning
In-Reply-To: <1256691929.12.0.04518648136.issue7224@psf.upfronthosting.co.za>
Message-ID: <1257448562.56.0.696280957518.issue7224@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The basic problem here is that the "one obvious way" to some people
(including me and Martin v. L?wis) is to use a dictionary.  Further,
there is the problem of conflating types in a user's mind -- right now,
dictionaries are all about looking up and returning values, while sets
are not.  

The current notion of sets corresponds neatly with what folks learn in
their basic math classes.  In contrast, the notion of "canonical
representatives of an equivalence class" is a more advanced mathematical
concept, one that many people are never taught.  This is even more
problematic in Python because the operation of finding canonical values
is hidden behind well designed __hash__ and __eq__ functions (for
example, it is not at all obvious how Decimal(3.0), float(3.0), and
int(3.0) all have the same hash value).  

An additional problem is the modification of set.add() so that it
violates Python's norm of having mutating methods return None.  We
should keep the language consistent in this regard.

Also, I should comment on the "appreciable memory savings".  This saves
only a single pointer (4 bytes on a 32-bit build) out of three per
string.  But the string object itself takes up memory, so the percent
savings per string is smaller than you would might expect (typically
less than 15%).

Finally, the spirit of the language moratorium is to make it so that
other Python implementations don't have to change for a few years.

FWIW, I am already going to expand the set/frozenset documention to show
some techniques for accessing and using sets.  I can add a link to a
get_equivalent() recipe that makes it possible to retrieve canonical
values from any container including sets.  That recipe uses all the
containers as-is, no patching or API changes needed.

----------

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

From report at bugs.python.org  Thu Nov  5 20:23:08 2009
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 05 Nov 2009 19:23:08 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1257448988.66.0.0956248800513.issue1294959@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If I understand correctly, using lib32 or lib64 is a kludge. Debian
and Ubuntu want to come up with a better way to do this:
http://wiki.debian.org/ReleaseGoals/MultiArch
https://wiki.ubuntu.com/MultiarchSpec

Kind regards.

----------
nosy: +Merwok

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

From report at bugs.python.org  Thu Nov  5 20:25:26 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 05 Nov 2009 19:25:26 +0000
Subject: [issue7265] IDLE not working
In-Reply-To: <1257396672.49.0.0556052422115.issue7265@psf.upfronthosting.co.za>
Message-ID: <1257449126.83.0.887317027085.issue7265@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Closing as resolved, then.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Thu Nov  5 20:50:53 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 05 Nov 2009 19:50:53 +0000
Subject: [issue7224] One obvious way to do interning
In-Reply-To: <1257448562.56.0.696280957518.issue7224@psf.upfronthosting.co.za>
Message-ID: <d38f5330911051150x33bfb17brdce660102182991c@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Nov 5, 2009 at 2:16 PM, Raymond Hettinger
<report at bugs.python.org> wrote:
>
> Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:
>
> The basic problem here is that the "one obvious way" to some people
> (including me and Martin v. L?wis) is to use a dictionary. ?Further,
> there is the problem of conflating types in a user's mind -- right now,
> dictionaries are all about looking up and returning values, while sets
> are not.

One feature that is missing from both dict approach and get_equivalent
recipe is the ability to do interning of new values with a single
lookup.  Note that even at the C level one has to first try to
retrieve the key from the dictionary and then if that fails, do an
insert which repeats the same lookup.  Even dict.setdefault which is
designed to remove the double lookup while eliminates it when key is
present, still does the second lookup when the key is missing.

----------

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

From report at bugs.python.org  Thu Nov  5 21:23:36 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 Nov 2009 20:23:36 +0000
Subject: [issue7224] One obvious way to do interning
In-Reply-To: <1256691929.12.0.04518648136.issue7224@psf.upfronthosting.co.za>
Message-ID: <1257452616.06.0.27080089019.issue7224@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

That is a false optimization.  Regular python code is full of look-ups
(even set.add has a getattr(s, 'add') lookup just to find the
add-method; every call to a built-in typically goes through multiple
lookups).   Also, the cost of a second lookup is trivial because of
processor caching:  see Object/dictnotes.txt.

Martin has already rejected a similar proposal for similar reasons. 
Please drop this one.  IMO, it is harmful to the set API because it
changes set's core concept to include lookup operations instead of just
simple set operations.

Either use sys.intern() or roll your own using get_equivalent() or a
dictionary.  A single use-case doesn't warrant building-out the
language, providing more ways to do it, or messing the core concept of
the set/frozenset datatype.

----------

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

From report at bugs.python.org  Thu Nov  5 21:38:32 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 05 Nov 2009 20:38:32 +0000
Subject: [issue7224] One obvious way to do interning
In-Reply-To: <1256691929.12.0.04518648136.issue7224@psf.upfronthosting.co.za>
Message-ID: <1257453512.57.0.137494310323.issue7224@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I agree with Raymond here. This use case isn't special enough, or the
performance of the current "one way to do it" bad enough to warrant
changing set. I recommend closing this issue.

----------
nosy: +eric.smith

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

From report at bugs.python.org  Thu Nov  5 22:03:32 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 05 Nov 2009 21:03:32 +0000
Subject: [issue7224] One obvious way to do interning
In-Reply-To: <1257452616.06.0.27080089019.issue7224@psf.upfronthosting.co.za>
Message-ID: <d38f5330911051303w499af35ftc3aa032bf4e7561d@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Nov 5, 2009 at 3:23 PM, Raymond Hettinger
<report at bugs.python.org> wrote:
..
> Martin has already rejected a similar proposal for similar reasons.
> Please drop this one.

Sure.  In fact I've never proposed to apply this patch.  As I said in
my original submission, the only purpose of reviving  issue1507011 is
this way was to give an easy way for users who claimed that in their
apps saving 4-8 bytes per interned string would make a difference to
test their claim.

Just as with issue1507011 three years ago I personally did not see
noticeable improvements in my applications from the patch.

----------

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

From report at bugs.python.org  Thu Nov  5 22:06:36 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 Nov 2009 21:06:36 +0000
Subject: [issue7224] One obvious way to do interning
In-Reply-To: <1256691929.12.0.04518648136.issue7224@psf.upfronthosting.co.za>
Message-ID: <1257455196.47.0.721509356085.issue7224@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thank you.

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Fri Nov  6 00:35:12 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 05 Nov 2009 23:35:12 +0000
Subject: [issue7266] test_lib2to3 failure under Windows
In-Reply-To: <1257433591.14.0.555852020916.issue7266@psf.upfronthosting.co.za>
Message-ID: <1257464112.79.0.663647391687.issue7266@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think we need someone with access to windows to propose a patch.

----------
assignee: benjamin.peterson -> 
components: +Windows

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

From report at bugs.python.org  Fri Nov  6 01:08:56 2009
From: report at bugs.python.org (flashk)
Date: Fri, 06 Nov 2009 00:08:56 +0000
Subject: [issue7268] 2to3 execfile conversion changes behavior
In-Reply-To: <1257466136.74.0.490341354872.issue7268@psf.upfronthosting.co.za>
Message-ID: <1257466136.74.0.490341354872.issue7268@psf.upfronthosting.co.za>


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

I recently ran 2to3 on some of my scripts and noticed a change in behavior.

I had a script that used the built-in execfile function. After the conversion, it was 
changed to manually open the file and read the contents into the exec function. Now I am 
getting a SyntaxError with the modified code.

The SyntaxError is caused when the new exec code is called on a script that ends with an 
empty indented line. I'm not sure if this is an error with the 2to3 script or the built-
in exec function.

I've attached a very minimal test case. The test.py file is a simple hello world script 
that ends with an empty indented line. The execfile_example.py file simply calls 
execfile on the test.py script. The execfile_example_converted.py file is the 2to3 
converted version of execfile_example.py.

I'm running Python 2.6.2 on Windows XP.

----------
components: 2to3 (2.x to 3.0 conversion tool), Interpreter Core
files: execfile_problem.zip
messages: 94949
nosy: flashk
severity: normal
status: open
title: 2to3 execfile conversion changes behavior
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15267/execfile_problem.zip

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

From report at bugs.python.org  Fri Nov  6 01:18:42 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 06 Nov 2009 00:18:42 +0000
Subject: [issue7268] 2to3 execfile conversion changes behavior
In-Reply-To: <1257466136.74.0.490341354872.issue7268@psf.upfronthosting.co.za>
Message-ID: <1257466722.7.0.420761173167.issue7268@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Could you attach the files separately or paste them into the bug? zip
files are hard to work with.

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Fri Nov  6 01:22:09 2009
From: report at bugs.python.org (flashk)
Date: Fri, 06 Nov 2009 00:22:09 +0000
Subject: [issue7268] 2to3 execfile conversion changes behavior
In-Reply-To: <1257466136.74.0.490341354872.issue7268@psf.upfronthosting.co.za>
Message-ID: <1257466929.05.0.695725426853.issue7268@psf.upfronthosting.co.za>


Changes by flashk <flashk at gmail.com>:


Added file: http://bugs.python.org/file15268/test.py

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

From report at bugs.python.org  Fri Nov  6 01:22:34 2009
From: report at bugs.python.org (flashk)
Date: Fri, 06 Nov 2009 00:22:34 +0000
Subject: [issue7268] 2to3 execfile conversion changes behavior
In-Reply-To: <1257466136.74.0.490341354872.issue7268@psf.upfronthosting.co.za>
Message-ID: <1257466954.73.0.0917353807513.issue7268@psf.upfronthosting.co.za>


Changes by flashk <flashk at gmail.com>:


Added file: http://bugs.python.org/file15269/execfile_example.py

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

From report at bugs.python.org  Fri Nov  6 01:22:52 2009
From: report at bugs.python.org (flashk)
Date: Fri, 06 Nov 2009 00:22:52 +0000
Subject: [issue7268] 2to3 execfile conversion changes behavior
In-Reply-To: <1257466136.74.0.490341354872.issue7268@psf.upfronthosting.co.za>
Message-ID: <1257466972.47.0.487880447152.issue7268@psf.upfronthosting.co.za>


Changes by flashk <flashk at gmail.com>:


Added file: http://bugs.python.org/file15270/execfile_example_converted.py

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

From report at bugs.python.org  Fri Nov  6 01:24:18 2009
From: report at bugs.python.org (flashk)
Date: Fri, 06 Nov 2009 00:24:18 +0000
Subject: [issue7268] 2to3 execfile conversion changes behavior
In-Reply-To: <1257466136.74.0.490341354872.issue7268@psf.upfronthosting.co.za>
Message-ID: <1257467058.32.0.00853434814001.issue7268@psf.upfronthosting.co.za>


flashk <flashk at gmail.com> added the comment:

I just attached the files individually.

----------

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

From report at bugs.python.org  Fri Nov  6 01:27:33 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 06 Nov 2009 00:27:33 +0000
Subject: [issue7268] 2to3 execfile conversion changes behavior
In-Reply-To: <1257466136.74.0.490341354872.issue7268@psf.upfronthosting.co.za>
Message-ID: <1257467253.85.0.564028705164.issue7268@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

test.py is invalid Python 3 syntax.

----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Fri Nov  6 01:44:41 2009
From: report at bugs.python.org (flashk)
Date: Fri, 06 Nov 2009 00:44:41 +0000
Subject: [issue7268] 2to3 execfile conversion changes behavior
In-Reply-To: <1257466136.74.0.490341354872.issue7268@psf.upfronthosting.co.za>
Message-ID: <1257468281.57.0.218086475611.issue7268@psf.upfronthosting.co.za>


flashk <flashk at gmail.com> added the comment:

I'm running this code under 2.6, so the print statement should not be the 
issue. I've attached a new version of test.py that simply performs a 
variable assignment and I still get the syntax error on both 2.6 and 3.1 
with the exec function. Also, the syntax error is reported on line 3, 
which is the empty indented line. Sorry for the confusion.

----------
Added file: http://bugs.python.org/file15271/test.py

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

From report at bugs.python.org  Fri Nov  6 01:57:42 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Nov 2009 00:57:42 +0000
Subject: [issue3001] RLock's are SLOW
In-Reply-To: <1212074891.45.0.23606216758.issue3001@psf.upfronthosting.co.za>
Message-ID: <1257469062.57.0.647555782717.issue3001@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> pitrou
components:  -Interpreter Core
stage: patch review -> needs patch
versions: +Python 3.2 -Python 2.7, Python 3.1

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

From report at bugs.python.org  Fri Nov  6 02:00:55 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 06 Nov 2009 01:00:55 +0000
Subject: [issue7268] 2to3 execfile conversion changes behavior
In-Reply-To: <1257466136.74.0.490341354872.issue7268@psf.upfronthosting.co.za>
Message-ID: <1257469255.16.0.246085082358.issue7268@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This is because you have DOS newlines which the Python compiler cannot
handle. In 2.x, open("test.py", "r") does not translate newlines. In
3.x, it does.

----------

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

From report at bugs.python.org  Fri Nov  6 02:15:15 2009
From: report at bugs.python.org (flashk)
Date: Fri, 06 Nov 2009 01:15:15 +0000
Subject: [issue7268] 2to3 execfile conversion changes behavior
In-Reply-To: <1257466136.74.0.490341354872.issue7268@psf.upfronthosting.co.za>
Message-ID: <1257470115.11.0.523570296329.issue7268@psf.upfronthosting.co.za>


flashk <flashk at gmail.com> added the comment:

Ok, I converted test.py to use Unix style newlines and still get the 
syntax error on both 2.6 and 3.1. I'm confused as to why execfile works on 
the file but reading the contents and passing it to exec behaves 
differently under 2.6. Sorry if I'm just being dense.

----------
Added file: http://bugs.python.org/file15272/test.py

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

From report at bugs.python.org  Fri Nov  6 02:25:47 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 06 Nov 2009 01:25:47 +0000
Subject: [issue7268] 2to3 execfile conversion changes behavior
In-Reply-To: <1257470115.11.0.523570296329.issue7268@psf.upfronthosting.co.za>
Message-ID: <1afaf6160911051725x7209c303r82d1b13eba87354c@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2009/11/5 flashk <report at bugs.python.org>:
>
> flashk <flashk at gmail.com> added the comment:
>
> Ok, I converted test.py to use Unix style newlines and still get the
> syntax error on both 2.6 and 3.1. I'm confused as to why execfile works on
> the file but reading the contents and passing it to exec behaves
> differently under 2.6. Sorry if I'm just being dense.

open in 2.x does not translate newlines by default. It does so in 3.x.

----------

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

From report at bugs.python.org  Fri Nov  6 02:38:18 2009
From: report at bugs.python.org (flashk)
Date: Fri, 06 Nov 2009 01:38:18 +0000
Subject: [issue7268] 2to3 execfile conversion changes behavior
In-Reply-To: <1257466136.74.0.490341354872.issue7268@psf.upfronthosting.co.za>
Message-ID: <1257471498.88.0.704911920359.issue7268@psf.upfronthosting.co.za>


flashk <flashk at gmail.com> added the comment:

Ok, but why am I still getting a syntax error in both 2.6 and 3.1 on the 
file, even after converting the newlines?

If I remove the trailing indentation then everything works properly on 2.6 
and 3.1, even with DOS newlines.

It just seems that exec does not properly handle code that ends with an 
empty indented line, but execfile handles it correctly.

----------

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

From report at bugs.python.org  Fri Nov  6 02:48:39 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 06 Nov 2009 01:48:39 +0000
Subject: [issue7268] 2to3 execfile conversion changes behavior
In-Reply-To: <1257471498.88.0.704911920359.issue7268@psf.upfronthosting.co.za>
Message-ID: <1afaf6160911051748y2e48a620lbfe91fce2307408e@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2009/11/5 flashk <report at bugs.python.org>:
>
> flashk <flashk at gmail.com> added the comment:
>
> Ok, but why am I still getting a syntax error in both 2.6 and 3.1 on the
> file, even after converting the newlines?
>
> If I remove the trailing indentation then everything works properly on 2.6
> and 3.1, even with DOS newlines.
>
> It just seems that exec does not properly handle code that ends with an
> empty indented line, but execfile handles it correctly.

Well, it works for me with the empty newline. Can you isolate the exact problem?

----------

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

From report at bugs.python.org  Fri Nov  6 03:40:23 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Nov 2009 02:40:23 +0000
Subject: [issue6462] bsddb3 intermittent test failures
In-Reply-To: <1247329933.16.0.47150397.issue6462@psf.upfronthosting.co.za>
Message-ID: <1257475223.38.0.816799954531.issue6462@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The deadlock error is still there, so I'm leaving this open, but it is
no longer causing buildbot instability.

----------

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

From report at bugs.python.org  Fri Nov  6 03:41:08 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Nov 2009 02:41:08 +0000
Subject: [issue6462] bsddb3 intermittent test failures
In-Reply-To: <1247329933.16.0.47150397.issue6462@psf.upfronthosting.co.za>
Message-ID: <1257475268.4.0.293488631271.issue6462@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords:  -buildbot

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

From report at bugs.python.org  Fri Nov  6 03:46:31 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Nov 2009 02:46:31 +0000
Subject: [issue7266] test_lib2to3 failure under Windows
In-Reply-To: <1257433591.14.0.555852020916.issue7266@psf.upfronthosting.co.za>
Message-ID: <1257475591.46.0.293533349759.issue7266@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Benjamin disabled this test on windows so it is no longer causing the
buildbot to fail.

----------
components: +Tests
keywords: +easy -buildbot
nosy: +r.david.murray
priority: normal -> low
stage:  -> needs patch

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

From report at bugs.python.org  Fri Nov  6 03:47:35 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Nov 2009 02:47:35 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails on Windows sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1257475655.99.0.304146136905.issue3892@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords:  -buildbot

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

From report at bugs.python.org  Fri Nov  6 03:49:39 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Nov 2009 02:49:39 +0000
Subject: [issue6748] test_debuglevel from test_telnetlib.py fails
In-Reply-To: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
Message-ID: <1257475779.96.0.885391301649.issue6748@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords: +buildbot

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

From report at bugs.python.org  Fri Nov  6 03:58:19 2009
From: report at bugs.python.org (flashk)
Date: Fri, 06 Nov 2009 02:58:19 +0000
Subject: [issue7268] 2to3 execfile conversion changes behavior
In-Reply-To: <1afaf6160911051748y2e48a620lbfe91fce2307408e@mail.gmail.com>
Message-ID: <978d1eac0911051857h38513bfbq4452e3d0c94fac7c@mail.gmail.com>


flashk <flashk at gmail.com> added the comment:

On Thu, Nov 5, 2009 at 5:48 PM, Benjamin Peterson <report at bugs.python.org>wrote:
>
>
> Well, it works for me with the empty newline. Can you isolate the exact
> problem?

For me, the exact problem seems to be that exec raises a SyntaxError if the
code contains a trailing indentation. Here's a summary of everything I've
tried:

 * test.py runs successfully on 2.6 and 3.1, regardless of line ending style
(LF, CR+LF)

 * "execfile('test.py')" runs successfully on 2.6, regardless of line ending
style

 * "exec(compile(open('test.py').read(), 'test.py', 'exec'))" raises a
SyntaxError on line 3 of test.py under 2.6 and 3.1, regardless of line
ending style.

 * Removing the trailing indentation from test.py causes the above code to
succeed under 2.6 and 3.1, regardless of line ending style.

You mentioned that it worked for you with an empty newline. To be clear, the
last line of test.py contains a single tab, with no newline character.

----------
Added file: http://bugs.python.org/file15273/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7268>
_______________________________________
-------------- next part --------------
<div class="gmail_quote">On Thu, Nov 5, 2009 at 5:48 PM, Benjamin Peterson <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">
<br>
</div>Well, it works for me with the empty newline. Can you isolate the exact problem?</blockquote><div><br></div><div>For me, the exact problem seems to be that exec raises a SyntaxError if the code contains a trailing indentation. Here&#39;s a summary of everything I&#39;ve tried:</div>

<div><br></div><div>??* test.py runs successfully on 2.6 and 3.1, regardless of line ending style (LF, CR+LF)</div><div><br></div><div>??* &quot;execfile(&#39;test.py&#39;)&quot; runs successfully on 2.6, regardless of line ending style</div>

<div><br></div><div>??* &quot;exec(compile(open(&#39;test.py&#39;).read(), &#39;test.py&#39;, &#39;exec&#39;))&quot; raises a SyntaxError on line 3 of test.py under 2.6 and 3.1, regardless of line ending style.</div><div>
<br>
</div><div>??* Removing the trailing indentation from test.py causes the above code to succeed under 2.6 and 3.1, regardless of line ending style.</div><div><br></div><div>You mentioned that it worked for you with an empty newline. To be clear, the last line of test.py contains a single tab, with no newline character.</div>

<div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>

From report at bugs.python.org  Fri Nov  6 03:58:52 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Nov 2009 02:58:52 +0000
Subject: [issue7269] Windows buildbot occasional DBFileExistsError failures in
	test_bsddb3
In-Reply-To: <1257476332.86.0.346139621294.issue7269@psf.upfronthosting.co.za>
Message-ID: <1257476332.86.0.346139621294.issue7269@psf.upfronthosting.co.za>


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

The windows buildbot occasionally fails with tracebacks like this:

======================================================================
ERROR: test01_badpointer (bsddb.test.test_misc.MiscTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"E:\cygwin\home\db3l\buildarea\2.6.bolen-windows\build\lib\bsddb\test\test_misc.py",
line 21, in test01_badpointer
    dbs = dbshelve.open(self.filename)
  File
"E:\cygwin\home\db3l\buildarea\2.6.bolen-windows\build\lib\bsddb\dbshelve.py",
line 106, in open
    d.open(filename, dbname, filetype, flags, mode)
  File
"E:\cygwin\home\db3l\buildarea\2.6.bolen-windows\build\lib\bsddb\dbshelve.py",
line 171, in open
    self.db.open(*args, **kwargs)
DBFileExistsError: (17, 'File exists -- __fop_file_setup:  Retry limit
(100) exceeded')

This also happens for several of the other test methods.

----------
assignee: jcea
components: Library (Lib), Tests
keywords: buildbot
messages: 94962
nosy: jcea, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Windows buildbot occasional DBFileExistsError failures in test_bsddb3
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri Nov  6 04:10:45 2009
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 Nov 2009 03:10:45 +0000
Subject: [issue7175] unify pydistutils.cfg and distutils.cfg and use .local
In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
Message-ID: <1257477045.33.0.457874833875.issue7175@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

When ~/.local/lib was chosen for the user directory, the BaseDir Spec
was given as prior example. Why not go the full way and follow the spec?
The config file could be $XDG_CONFIG_HOME/python/distutils, with
$XDG_CONFIG_HOME defaulting to ~/.config.

References:
http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
http://www.freedesktop.org/wiki/Software/pyxdg (deals with
freedesktop.org-approved file formats too; the part of the code that
deals with paths would make a useful addition to the stdlib, as more and
more applications follow the spec)

----------
nosy: +Merwok

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

From report at bugs.python.org  Fri Nov  6 04:13:10 2009
From: report at bugs.python.org (flashk)
Date: Fri, 06 Nov 2009 03:13:10 +0000
Subject: [issue7268] 2to3 execfile conversion changes behavior
In-Reply-To: <1257466136.74.0.490341354872.issue7268@psf.upfronthosting.co.za>
Message-ID: <1257477190.09.0.938700341502.issue7268@psf.upfronthosting.co.za>


flashk <flashk at gmail.com> added the comment:

I noticed that calling "exec('\t')" raises a SyntaxError, so maybe this is 
the root of the problem. I manually added a newline character to the end 
of the file contents and it fixes the issue for me:

exec(compile(open('test.py').read()+'\n', 'test.py', 'exec'))

So maybe the 2to3 script should automatically do this in order to be 
compatible with previous execfile behavior? Or is this a problem with 
exec?

----------

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

From report at bugs.python.org  Fri Nov  6 11:37:34 2009
From: report at bugs.python.org (Kuang-che Wu)
Date: Fri, 06 Nov 2009 10:37:34 +0000
Subject: [issue6450] normpath() sometimes maps unicode to str
In-Reply-To: <1247165396.23.0.921821362773.issue6450@psf.upfronthosting.co.za>
Message-ID: <1257503854.28.0.154951305505.issue6450@psf.upfronthosting.co.za>


Kuang-che Wu <kcwu at csie.org> added the comment:

see issue 5827, it includes a patch fixing this issue.

----------
nosy: +kcwu

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

From report at bugs.python.org  Fri Nov  6 12:26:29 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Nov 2009 11:26:29 +0000
Subject: [issue7270] Tests for synchronization primitives
In-Reply-To: <1257506788.68.0.0613740035295.issue7270@psf.upfronthosting.co.za>
Message-ID: <1257506788.68.0.0613740035295.issue7270@psf.upfronthosting.co.za>


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

Here is a patch adding unit tests for synchronization primitives in
threading.py (Lock, RLock, Event, Condition). I've left Semaphore and
BoundedSemaphore out of the picture.

----------
components: Library (Lib), Tests
files: locktests.patch
keywords: patch
messages: 94966
nosy: gregory.p.smith, jyasskin, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Tests for synchronization primitives
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15274/locktests.patch

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

From report at bugs.python.org  Fri Nov  6 12:44:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Nov 2009 11:44:46 +0000
Subject: [issue7270] Tests for synchronization primitives
In-Reply-To: <1257506788.68.0.0613740035295.issue7270@psf.upfronthosting.co.za>
Message-ID: <1257507886.04.0.995457155769.issue7270@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +tim_one

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

From report at bugs.python.org  Fri Nov  6 14:29:32 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Nov 2009 13:29:32 +0000
Subject: [issue7270] Tests for synchronization primitives
In-Reply-To: <1257506788.68.0.0613740035295.issue7270@psf.upfronthosting.co.za>
Message-ID: <1257514172.68.0.1555227503.issue7270@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

New patch adding Semaphore and BoundedSemaphore tests.

----------
Added file: http://bugs.python.org/file15275/locktests2.patch

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

From report at bugs.python.org  Fri Nov  6 14:32:26 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 06 Nov 2009 13:32:26 +0000
Subject: [issue7271] Typo in turtle module documentation.
In-Reply-To: <1257514346.42.0.243931952631.issue7271@psf.upfronthosting.co.za>
Message-ID: <1257514346.42.0.243931952631.issue7271@psf.upfronthosting.co.za>


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

Reported on c.l.p. by Lawrence D'Oliveiro:

<http://docs.python.org/library/turtle.html> -- ?ScrolledCavas? should be
?ScrolledCanvas?.

----------
assignee: georg.brandl
components: Documentation
messages: 94968
nosy: georg.brandl, mark.dickinson
severity: normal
status: open
title: Typo in turtle module documentation.
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Nov  6 15:09:22 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 06 Nov 2009 14:09:22 +0000
Subject: [issue7267] format method: c presentation type broken
In-Reply-To: <1257438168.68.0.774312526176.issue7267@psf.upfronthosting.co.za>
Message-ID: <1257516562.75.0.0667917660584.issue7267@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This is a bug in the way ints and longs are formatted. They always do
the formatting as str, then convert to unicode. This works everywhere
except with the 'c' presentation type. I'm still trying to decide how
best to handle this.

----------
versions: +Python 2.7

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

From report at bugs.python.org  Fri Nov  6 15:17:18 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 06 Nov 2009 14:17:18 +0000
Subject: [issue7269] Windows buildbot occasional DBFileExistsError failures in
	test_bsddb3
In-Reply-To: <1257476332.86.0.346139621294.issue7269@psf.upfronthosting.co.za>
Message-ID: <1257517038.99.0.208253853356.issue7269@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Unless I am mistaken, self.filename has no path, and files are created
in the current directory...

----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Fri Nov  6 15:32:27 2009
From: report at bugs.python.org (Jack Diederich)
Date: Fri, 06 Nov 2009 14:32:27 +0000
Subject: [issue6748] test_debuglevel from test_telnetlib.py fails
In-Reply-To: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
Message-ID: <1257517947.05.0.747841333274.issue6748@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

Simplified tests attached.  Instead of bulking up and testing the TCP
server implementation I ended up mocking/stubing the socket recv/sendall
and select.select functions.  The only tests that use real sockets are
the ones to test timeouts.  Therefore test_telnetlib.py should be
platform neutral (let test_socket.py figure that stuff out).

Unless this blows up for anyone I'll check it in later today.

----------
Added file: http://bugs.python.org/file15276/simplified_6748.diff

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

From report at bugs.python.org  Fri Nov  6 15:44:01 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Nov 2009 14:44:01 +0000
Subject: [issue7270] Tests for synchronization primitives
In-Reply-To: <1257506788.68.0.0613740035295.issue7270@psf.upfronthosting.co.za>
Message-ID: <1257518641.5.0.774903571534.issue7270@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file15274/locktests.patch

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

From report at bugs.python.org  Fri Nov  6 15:44:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Nov 2009 14:44:04 +0000
Subject: [issue7270] Tests for synchronization primitives
In-Reply-To: <1257506788.68.0.0613740035295.issue7270@psf.upfronthosting.co.za>
Message-ID: <1257518644.66.0.610772225348.issue7270@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file15275/locktests2.patch

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

From report at bugs.python.org  Fri Nov  6 15:44:12 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Nov 2009 14:44:12 +0000
Subject: [issue7270] Tests for synchronization primitives
In-Reply-To: <1257506788.68.0.0613740035295.issue7270@psf.upfronthosting.co.za>
Message-ID: <1257518652.89.0.366415740564.issue7270@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file15277/locktests2.patch

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

From report at bugs.python.org  Fri Nov  6 15:52:32 2009
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Fri, 06 Nov 2009 14:52:32 +0000
Subject: [issue7267] format method: c presentation type broken
In-Reply-To: <1257438168.68.0.774312526176.issue7267@psf.upfronthosting.co.za>
Message-ID: <1257519152.13.0.78194106886.issue7267@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

I'd say that a value >= 128 should generate a Unicode string (as the PEP
explicitely states that the value is a Unicode code point and not a byte
value).

However str.format() doesn't seem to support mixing str and unicode anyway:

>>> '{0}'.format(u'\u3042')
UnicodeEncodeError: 'ascii' codec can't encode character u'\u3042' in
position 0: ordinal not in range(128)

so str.format() might raise an OverflowError for values >= 128 (or >= 256?)

----------

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

From report at bugs.python.org  Fri Nov  6 15:53:18 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 06 Nov 2009 14:53:18 +0000
Subject: [issue6748] test_debuglevel from test_telnetlib.py fails
In-Reply-To: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
Message-ID: <1257519198.38.0.145709222069.issue6748@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

With these test simplifications, it looks as though you could lose some
imports as well. (E.g., queue, os).

Patch works fine for me on 64-bit Linux.  I'll test it on OS X (10.5 and
10.6) when I get home tonight.

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Fri Nov  6 16:02:23 2009
From: report at bugs.python.org (Jack Diederich)
Date: Fri, 06 Nov 2009 15:02:23 +0000
Subject: [issue6748] test_debuglevel from test_telnetlib.py fails
In-Reply-To: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
Message-ID: <1257519743.39.0.246982109232.issue6748@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

ran pyflakes and removed unused imports.

----------
Added file: http://bugs.python.org/file15278/simplified_6748.diff

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

From report at bugs.python.org  Fri Nov  6 16:02:37 2009
From: report at bugs.python.org (Jack Diederich)
Date: Fri, 06 Nov 2009 15:02:37 +0000
Subject: [issue6748] test_debuglevel from test_telnetlib.py fails
In-Reply-To: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
Message-ID: <1257519757.6.0.233025796807.issue6748@psf.upfronthosting.co.za>


Changes by Jack Diederich <jackdied at gmail.com>:


Removed file: http://bugs.python.org/file15276/simplified_6748.diff

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

From report at bugs.python.org  Fri Nov  6 16:21:02 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 06 Nov 2009 15:21:02 +0000
Subject: [issue6748] test_debuglevel from test_telnetlib.py fails
In-Reply-To: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
Message-ID: <1257520862.99.0.103429822798.issue6748@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The new patch works for me on 32-bit OS X 10.5. I think the approach of
mocking the sockets is a good idea, although I haven't reviewed the
patch itself.

----------

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

From report at bugs.python.org  Fri Nov  6 16:44:19 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 06 Nov 2009 15:44:19 +0000
Subject: [issue6748] test_debuglevel from test_telnetlib.py fails
In-Reply-To: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
Message-ID: <1257522259.0.0.0226958461098.issue6748@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The most recent patch (http://bugs.python.org/file15278) works for
me on OS X 10.4/PPC (32-bit), OS X 10.5/Intel (32-bit) and OS X 10.6/Intel 
(64-bit).

----------

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

From report at bugs.python.org  Fri Nov  6 16:57:14 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 06 Nov 2009 15:57:14 +0000
Subject: [issue7272] test_multiprocessing fails consistently with 'signal 12'
	on FreeBSD 6.2 buildbot.
In-Reply-To: <1257523034.1.0.340985846807.issue7272@psf.upfronthosting.co.za>
Message-ID: <1257523034.1.0.340985846807.issue7272@psf.upfronthosting.co.za>


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

The x86 FreeBSD buildslave is consistently aborting the test run with a 
'Signal 12' failure in test_multiprocessing.  See e.g.,

http://www.python.org/dev/buildbot/builders/x86%20FreeBSD%20trunk/builds/2
756/steps/test/logs/stdio

(scroll all the way to the bottom to see the failure).

The failure occurs on 2.7, 3.1 and 3.2.  On 2.6, it looks as though 
test_multiprocessing is disabled:  the message gives a reference to issue 
3770.

Note that the maintainer of the buildbot (David Bolen) has offered to 
arrange ssh access for anyone wanting to look into this.  (See

http://mail.python.org/pipermail/python-dev/2009-November/093857.html

.)

----------
components: Tests
keywords: buildbot
messages: 94977
nosy: db3l, jnoller, mark.dickinson
severity: normal
status: open
title: test_multiprocessing fails consistently with 'signal 12' on FreeBSD 6.2 buildbot.
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Nov  6 16:58:53 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 06 Nov 2009 15:58:53 +0000
Subject: [issue7272] test_multiprocessing fails consistently with 'signal 12'
	on FreeBSD 6.2 buildbot.
In-Reply-To: <1257523034.1.0.340985846807.issue7272@psf.upfronthosting.co.za>
Message-ID: <1257523133.75.0.0318084733737.issue7272@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I mangled the buildbot results URL.  Here it is again.

http://www.python.org/dev/buildbot/builders/x86%20FreeBSD%20trunk/builds/2756/steps/test/logs/stdio

----------

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

From report at bugs.python.org  Fri Nov  6 17:05:07 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 06 Nov 2009 16:05:07 +0000
Subject: [issue7272] test_multiprocessing fails consistently with 'signal 12'
	on FreeBSD 6.2 buildbot.
In-Reply-To: <1257523034.1.0.340985846807.issue7272@psf.upfronthosting.co.za>
Message-ID: <1257523507.8.0.147781899652.issue7272@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm not sure whether this is relevant, but the configure output for the 
FreeBSD trunk build includes the line:

checking for broken sem_getvalue... yes

----------

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

From report at bugs.python.org  Fri Nov  6 17:16:36 2009
From: report at bugs.python.org (Caleb Madrigal)
Date: Fri, 06 Nov 2009 16:16:36 +0000
Subject: [issue7273] struct.pack adding extra '\x00' character in very
	specific case
In-Reply-To: <1257524196.77.0.950133789456.issue7273@psf.upfronthosting.co.za>
Message-ID: <1257524196.77.0.950133789456.issue7273@psf.upfronthosting.co.za>


New submission from Caleb Madrigal <caleb.madrigal at gmail.com>:

struct.pack("17scBH", 'a'*17, 'c', 255, 65535)
produces 'aaaaaaaaaaaaaaaaac\xff\x00\xff\xff'.

Notice the extra '\x00' character between '\xff' and '\xff\xff'.

I have noticed that this happens when there is an odd-length string
(like '17s'), followed by a character ('c'), followed by a byte ('B'),
followed by an unsigned short ('H').

Other variations reproduce it also (such as using a 19-character string).

However, if any one of the following modifications are made to the
format, the problem goes away:
* Change the string to 16s
* Remove the byte ('B')
* Remove the character ('c')
* Remove the unsigned short ('H')

So obviously, this is a seriously deep, dark corner-case.

----------
components: Library (Lib)
messages: 94980
nosy: cmadrigal
severity: normal
status: open
title: struct.pack adding extra '\x00' character in very specific case
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Fri Nov  6 17:25:44 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 06 Nov 2009 16:25:44 +0000
Subject: [issue7273] struct.pack adding extra '\x00' character in very
	specific case
In-Reply-To: <1257524196.77.0.950133789456.issue7273@psf.upfronthosting.co.za>
Message-ID: <1257524744.21.0.500080848795.issue7273@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I don't think this is a bug:  struct.pack deliberately adds padding bytes 
so that the byte sequence matches the way that a corresponding C struct 
would be stored in memory, on that platform.  This is described 
(admittedly rather briefly) in the documentation at:

http://docs.python.org/library/struct.html

"""By default, C numbers are represented in the machine?s native format 
and byte order, and properly aligned by skipping pad bytes if necessary 
(according to the rules used by the C compiler)."""

Depending on your application, you may want to use standard size and 
alignment instead, e.g., with:

struct.pack("<17scBH", ...)

----------
assignee:  -> mark.dickinson
nosy: +mark.dickinson
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Fri Nov  6 17:26:23 2009
From: report at bugs.python.org (jan matejek)
Date: Fri, 06 Nov 2009 16:26:23 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1257524783.55.0.781160112934.issue1294959@psf.upfronthosting.co.za>


jan matejek <jmatejek at suse.cz> added the comment:

thanks for the info; however, it still means that python needs to learn
to live in places other than "/usr/lib"

----------

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

From report at bugs.python.org  Fri Nov  6 17:46:11 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 06 Nov 2009 16:46:11 +0000
Subject: [issue858809] Use directories from configure rather than hardcoded
Message-ID: <1257525971.04.0.890507158022.issue858809@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Fri Nov  6 17:47:16 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 06 Nov 2009 16:47:16 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1257526036.67.0.125685919774.issue1294959@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Fri Nov  6 18:15:14 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Nov 2009 17:15:14 +0000
Subject: [issue6748] test_debuglevel from test_telnetlib.py fails
In-Reply-To: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
Message-ID: <1257527714.55.0.0511806775097.issue6748@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The patch runs clean on my Gentoo buildbot, which otherwise fails
consistently.  I say apply it, I doubt you'd be making things worse by
doing so :)

Using minimal mocks with as few external dependencies as possible is
considered good unit-testing practice, from what I understand.

----------
nosy: +r.david.murray
priority: normal -> high
stage:  -> commit review
type:  -> behavior

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

From report at bugs.python.org  Fri Nov  6 18:18:51 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Nov 2009 17:18:51 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1257527931.2.0.223189756536.issue3864@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Mark, can this bug be closed, then?

----------

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

From report at bugs.python.org  Fri Nov  6 18:21:26 2009
From: report at bugs.python.org (Jack Diederich)
Date: Fri, 06 Nov 2009 17:21:26 +0000
Subject: [issue6748] test_debuglevel from test_telnetlib.py fails
In-Reply-To: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
Message-ID: <1257528086.51.0.823434365288.issue6748@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

committed in rev 76133

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Nov  6 18:27:22 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 06 Nov 2009 17:27:22 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
In-Reply-To: <1257524783.55.0.781160112934.issue1294959@psf.upfronthosting.co.za>
Message-ID: <4AF45C8D.2020602@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

jan matejek wrote:
> 
> jan matejek <jmatejek at suse.cz> added the comment:
> 
> thanks for the info; however, it still means that python needs to learn
> to live in places other than "/usr/lib"

The main problem is that Python's configuration system is not
geared up to having the lib directories for platform dependent
and platform independent parts use different names.

It currently only supports using different path *prefixes* for
such setups (--prefix and --exec-prefix), e.g. /usr and /usr64
would work just fine. It doesn't follow --libdir.

Note that Tarek is currently working on a cleanup of the
installation schemes (see distutils/commands/install.py,
distutils/sysconfig.py and site.py) which will then also
be used by site.py to setup sys.path.

A new modules will unite all these settings, so this should
be the target of any patches regarding installation and
path lookup schemes.

BTW: The "sys.lib" setting mentioned on the tracker is not standard.
The naming also doesn't look right, since the name of the "lib"
directory path component is an OS feature, not a system one that
you configure. os.lib_dir would be more appropriate.

----------
nosy: +lemburg

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

From report at bugs.python.org  Fri Nov  6 18:29:33 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 06 Nov 2009 17:29:33 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1257528573.79.0.905685994131.issue3864@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Well, test_signal is still failing.  So I guess this should stay open 
until we deal with the failure one way or another.  (E.g. skipping the 
test, or marking the failure as expected, or ...)

----------

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

From report at bugs.python.org  Fri Nov  6 18:41:22 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Nov 2009 17:41:22 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1257529282.19.0.0484986842724.issue3864@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Put in a platform+release specific skip, perhaps.

----------
keywords: +easy -buildbot
priority:  -> normal

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

From report at bugs.python.org  Fri Nov  6 18:41:24 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 06 Nov 2009 17:41:24 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1257529284.81.0.207956591047.issue1294959@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Adding Tarek to the ticket.

----------
nosy: +tarek

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

From report at bugs.python.org  Fri Nov  6 18:42:05 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Nov 2009 17:42:05 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1257529325.94.0.615978710921.issue3864@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords: +buildbot

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

From report at bugs.python.org  Fri Nov  6 19:11:43 2009
From: report at bugs.python.org (Douglas Shawhan)
Date: Fri, 06 Nov 2009 18:11:43 +0000
Subject: [issue7274] json module apparently fails regression found at
	http://json.org/JSON_checker/test.zip.
In-Reply-To: <1257531102.99.0.282987188143.issue7274@psf.upfronthosting.co.za>
Message-ID: <1257531102.99.0.282987188143.issue7274@psf.upfronthosting.co.za>


New submission from Douglas Shawhan <doug.shawhan at gmail.com>:

Environment:
Ubuntu 9.04 Jaunty
Linux thebadpipsissewah 2.6.28-16-server #55-Ubuntu SMP Tue Oct 20
20:37:10 UTC 2009 x86_64 GNU/Linux
Python 2.6.2 (release26-maint, Apr 19 2009, 01:58:18) 
[GCC 4.3.3] on linux2

Passes two "fail" cases:
fail1.json "A JSON payload should be an object or array, not a string."
fail18.json [[[[[[[[[[[[[[[[[[[["Too deep"]]]]]]]]]]]]]]]]]]]]

All other cases pass or fail as indicated.

=== test ===

#!/usr/bin/env python

import json, os
from StringIO import StringIO

def Validate( case ):
    try:
        l = json.loads( case[1] )
        print( "%s %s"%case )
    except:
        pass

    try:
        io = StringIO( case[1] )
        json.load( io )
        print( "%s %s"%case )
    except:
        pass

for passfail in [ "fail" ]:
    cases = [ [( i, open( os.path.join( base, i ), "r").read() )
                for i in files if passfail in i ]
                for base, subs, files in os.walk( "tests" ) ][0]

    [ Validate( case ) for case in cases ]

Sorry for ugly code, in a hurry. If this is wrong, please feel free to
backhand me.

d

----------
components: Extension Modules
messages: 94990
nosy: DougShawhan
severity: normal
status: open
title: json module apparently fails regression found at http://json.org/JSON_checker/test.zip.
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Nov  6 19:12:01 2009
From: report at bugs.python.org (Christian Glinsvad)
Date: Fri, 06 Nov 2009 18:12:01 +0000
Subject: [issue7275] CoverageResult fails to merge input file with non-empty
	callers in trace.py (patch)
In-Reply-To: <1257531121.53.0.200338110704.issue7275@psf.upfronthosting.co.za>
Message-ID: <1257531121.53.0.200338110704.issue7275@psf.upfronthosting.co.za>


New submission from Christian Glinsvad <glinsvad at hotmail.com>:

CoverageResults expects arguments in the order "counts, calledfuncs,
infile, callers..." but the try statement in the last part of __init__
passes "counts, calledfuncs, callers" as positional arguments to a new
instance of the same class. Thus, the secondary instance erroneously
obtains a dict for the "infile" argument, so I propose passing "callers"
as a keyword argument to avoid this.

Not that this has gone unnoticed because an empty dict for the "infile"
argument evaluates to False in "if self.infile:", which must have been
intended as "if self.infile is not None:". If, however, the original
instance loads a pickle file with a non-empty "callers" argument, the
secondary instance tries to run "open({}, 'rb')", which yields:

TypeError: coercing to Unicode: need string or buffer, dict found

----------
components: Library (Lib)
files: trace.diff
keywords: patch
messages: 94991
nosy: glinsvad
severity: normal
status: open
title: CoverageResult fails to merge input file with non-empty callers in trace.py (patch)
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15279/trace.diff

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

From report at bugs.python.org  Fri Nov  6 19:18:41 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 06 Nov 2009 18:18:41 +0000
Subject: [issue7251] Mark expected failures of test_math,
	test_cmath and test_round as such.
In-Reply-To: <1257154985.1.0.42933155819.issue7251@psf.upfronthosting.co.za>
Message-ID: <1257531521.25.0.369043551843.issue7251@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The test_round failure on Debian alpha is likely related to this glibc 
bug:

http://sources.redhat.com/bugzilla/show_bug.cgi?id=5350

----------

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

From report at bugs.python.org  Fri Nov  6 19:26:23 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Nov 2009 18:26:23 +0000
Subject: [issue7270] Tests for synchronization primitives
In-Reply-To: <1257506788.68.0.0613740035295.issue7270@psf.upfronthosting.co.za>
Message-ID: <1257531983.55.0.0753979791841.issue7270@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Please make a sign if you want to review, otherwise I will commit.

----------

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

From report at bugs.python.org  Fri Nov  6 20:23:17 2009
From: report at bugs.python.org (Ole Laursen)
Date: Fri, 06 Nov 2009 19:23:17 +0000
Subject: [issue7276] UnboundLocalError scoping problem with nested functions
In-Reply-To: <1257535397.32.0.778843860173.issue7276@psf.upfronthosting.co.za>
Message-ID: <1257535397.32.0.778843860173.issue7276@psf.upfronthosting.co.za>


New submission from Ole Laursen <olau at iola.dk>:

This works:

def outer(name):
    tmp = name
    def inner():
        print(tmp)
    return inner

outer("foo") # prints "foo"

While the same code with one extra line (setting tmp after printing) 
fails

def outer(name):
    tmp = name
    def inner():
        print(tmp)
        tmp = "hello"
    return inner

outer("foo")()

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in inner
UnboundLocalError: local variable 'tmp' referenced before assignment

and the following works

def outer(name):
    tmp = name
    def inner():
        tmp = "hello"
        print(tmp)
    return inner

outer("foo")() # prints "hello"

Now, I understand there's an interesting issue of assignment binding to 
the inner-most scope. So tmp = "hello" is binding a new variable, not 
changing the outermost tmp. But I should still be able to read tmp, 
right? It looks like some kind of optimizer error.


For the record, this pattern came up in a decorator like this

def deco(x = None):
    def inner(fn):
         if not x:
             x = somedefaultvalue
    
    return inner

which gives the same UnboundLocalError error.

----------
messages: 94994
nosy: olau
severity: normal
status: open
title: UnboundLocalError scoping problem with nested functions
type: compile error

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

From report at bugs.python.org  Fri Nov  6 20:27:17 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Nov 2009 19:27:17 +0000
Subject: [issue6748] test_debuglevel from test_telnetlib.py fails
In-Reply-To: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
Message-ID: <1257535637.32.0.559715175391.issue6748@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Jack, this failure is happening also in 3.1.  I tried to merge the
revision, but there are too many differences between 3.x and 3.1 for me
to be confident that I'd get it right.  Could you do the backport, please?

----------
status: closed -> open

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

From report at bugs.python.org  Fri Nov  6 21:10:12 2009
From: report at bugs.python.org (Domen)
Date: Fri, 06 Nov 2009 20:10:12 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1257538212.01.0.952450494482.issue2054@psf.upfronthosting.co.za>


Domen <ielectric at gmail.com> added the comment:

I've tested TLS with several private servers today, seems to work. I 
cannot test patch against FTP SSL encryption, although it is obviously 
not implemented

----------

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

From report at bugs.python.org  Fri Nov  6 21:17:24 2009
From: report at bugs.python.org (Travis H.)
Date: Fri, 06 Nov 2009 20:17:24 +0000
Subject: [issue6508] expose setresuid
In-Reply-To: <1247869532.62.0.249757468331.issue6508@psf.upfronthosting.co.za>
Message-ID: <1257538644.75.0.336261403381.issue6508@psf.upfronthosting.co.za>


Travis H. <travis+w-python.org at subspacefield.org> added the comment:

So this patch is done and tested, but no movement on it since 18
September.  Is there anything I can do to help move this along towards
integration?

----------

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

From report at bugs.python.org  Fri Nov  6 21:31:44 2009
From: report at bugs.python.org (GUO, Chen)
Date: Fri, 06 Nov 2009 20:31:44 +0000
Subject: [issue5707] IDLE will not load
In-Reply-To: <1239003620.62.0.108807854341.issue5707@psf.upfronthosting.co.za>
Message-ID: <1257539504.68.0.941205121522.issue5707@psf.upfronthosting.co.za>


GUO, Chen <gcd0318 at hotmail.com> added the comment:

Modification to "customer key set" would make IDLE fail to start

To re-produce:
1, Start IDLE, and switch to Preference -> Keys;
2, Make modification to the key binding;
3, Click Apply, then click OK
4, repeat above steps.
The 2nd time to click OK would not get any response.
But this is not the nightmare. Now quit IDLE and restart IDLE. But IDLE 
cannot restart.

I believe that issue5707 is still exist in Ver. 3.1.1 for Mac OS X.

OS: Mac OS X 10.6.1
Python version: 3.1.1

The error message from console of Mac OS X is attached as following:
-------------------------------
Last login: Sat Nov  7 03:34:20 on ttys000
/Applications/Python\ 3.1/IDLE.app/Contents/MacOS/IDLE ; exit;
localhost:~ gcd$ /Applications/Python\ 3.1/IDLE.app/Contents/MacOS/IDLE 
; exit;
Traceback (most recent call last):
  File "/Applications/Python 
3.1/IDLE.app/Contents/Resources/idlemain.py", line 73, in <module>
    main()
  File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/idlelib
/PyShell.py", line 1386, in main
    flist.new()
  File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/idlelib
/FileList.py", line 49, in new
    return self.EditorWindow(self, filename)
  File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/idlelib
/PyShell.py", line 107, in __init__
    EditorWindow.__init__(self, *args)
  File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/idlelib
/EditorWindow.py", line 135, in __init__
    self.apply_bindings()
  File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/idlelib
/EditorWindow.py", line 961, in apply_bindings
    text.event_add(event, *keylist)
  File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/idlelib
/MultiCall.py", line 359, in event_add
    widget.event_add(self, virtual, seq)
  File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/tkinter
/__init__.py", line 1353, in event_add
    self.tk.call(args)
_tkinter.TclError: bad event type or keysym "Control"
logout

----------
nosy: +gcd0318

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

From report at bugs.python.org  Fri Nov  6 22:04:02 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 06 Nov 2009 21:04:02 +0000
Subject: [issue6508] expose setresuid
In-Reply-To: <1247869532.62.0.249757468331.issue6508@psf.upfronthosting.co.za>
Message-ID: <1257541442.03.0.0204796142731.issue6508@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I'll take care of it.  It needs unittests but those will be trivial.

----------
assignee:  -> gregory.p.smith
priority:  -> normal
stage:  -> test needed
type:  -> feature request
versions: +Python 2.7, Python 3.2 -Python 2.6

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

From report at bugs.python.org  Fri Nov  6 22:08:56 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 06 Nov 2009 21:08:56 +0000
Subject: [issue7270] Tests for synchronization primitives
In-Reply-To: <1257506788.68.0.0613740035295.issue7270@psf.upfronthosting.co.za>
Message-ID: <1257541736.03.0.811806565815.issue7270@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Can you have Bunch inherit from object and add a docstring to its
constructor?

otherwise looks good, commit when you're ready.

----------
assignee:  -> pitrou

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

From report at bugs.python.org  Fri Nov  6 22:17:30 2009
From: report at bugs.python.org (Jack Diederich)
Date: Fri, 06 Nov 2009 21:17:30 +0000
Subject: [issue6748] test_debuglevel from test_telnetlib.py fails
In-Reply-To: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
Message-ID: <1257542250.83.0.224272904778.issue6748@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

backported to maint via svnmerge in r76136.  3.1 and 3.x
test_telnetlib.py's (and telnetlib.py's) are now identical.

----------
status: open -> closed

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

From report at bugs.python.org  Fri Nov  6 22:21:58 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 06 Nov 2009 21:21:58 +0000
Subject: [issue7276] UnboundLocalError scoping problem with nested functions
In-Reply-To: <1257535397.32.0.778843860173.issue7276@psf.upfronthosting.co.za>
Message-ID: <1257542518.1.0.879904923229.issue7276@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Any assignment causes a value to be local to its current scope.

----------
nosy: +benjamin.peterson
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Fri Nov  6 22:40:13 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 06 Nov 2009 21:40:13 +0000
Subject: [issue7274] json module apparently fails regression found at
	http://json.org/JSON_checker/test.zip.
In-Reply-To: <1257531102.99.0.282987188143.issue7274@psf.upfronthosting.co.za>
Message-ID: <1257543613.44.0.817755015362.issue7274@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> bob.ippolito
nosy: +bob.ippolito

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

From report at bugs.python.org  Fri Nov  6 23:41:55 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Nov 2009 22:41:55 +0000
Subject: [issue7270] Tests for synchronization primitives
In-Reply-To: <1257506788.68.0.0613740035295.issue7270@psf.upfronthosting.co.za>
Message-ID: <1257547315.33.0.98991465139.issue7270@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I committed the patch in trunk and py3k after applying the suggested
fixes. Thank you.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Nov  6 23:45:11 2009
From: report at bugs.python.org (Bob Ippolito)
Date: Fri, 06 Nov 2009 22:45:11 +0000
Subject: [issue7274] json module apparently fails regression found at
	http://json.org/JSON_checker/test.zip.
In-Reply-To: <1257531102.99.0.282987188143.issue7274@psf.upfronthosting.co.za>
Message-ID: <1257547511.01.0.145507605323.issue7274@psf.upfronthosting.co.za>


Bob Ippolito <bob at redivi.com> added the comment:

The json module departs slightly from the spec in that it will allow you 
to consume and produce documents that don't have an array or object 
envelope. This is a feature.

The "Too deep" test case is just a silly thing that crockford's code 
does, there's a fixed limitation for how complex an object could be. 
That's not a regression failure and the spec doesn't say anything about 
a maximum nesting level.

The json module includes all of these in its test suite, although it 
disagrees slightly with crockford on what should pass.

http://svn.python.org/view/python/branches/release26-
maint/Lib/json/tests/test_fail.py

SKIPS = {
    1: "why not have a string payload?",
    18: "spec doesn't specify any nesting limitations",
}

----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Sat Nov  7 00:51:41 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 06 Nov 2009 23:51:41 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1257551501.75.0.239362050313.issue2054@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

Sorry for delay in the response. The latest messages slipped under my 
radar.

> What about AUTH SSL? Or is it too-deprecated?

I'm not sure about this.
TLS is certainly preferred over SSL and RFC-4217 only refers to TLS 
protocol, altough SSL is mentioned in some chapters.

RFC-4217 states:

> As the SSL/TLS protocols self-negotiate their levels, there is no
> need to distinguish between SSL and TLS in the application layer. 
> The mechanism name for negotiating TLS is the character string 
> identified in {TLS-PARM}.
>
> [...]
>
> {TLS-PARM} - The parameter for the AUTH command to indicate that TLS
> is required.  To request the TLS protocol in accordance with this
> document, the client MUST use 'TLS'


If we want to support SSL we could change the current implementation by 
renaming "auth_tls()" method to just "auth" and play with the 
ssl_version attribute, like this:


class FTP_TLS(FTP):
    ssl_version = ssl.PROTOCOL_TLSv1

    def auth(self):
        if self.ssl_version == ssl.PROTOCOL_TLSv1:
            resp = self.voidcmd('AUTH TLS')
        else:
            resp = self.voidcmd('AUTH SSL')
        ...

The user willing to use SSL instead of TLS will have to change 
ssl_version class attribute with "FTP_TLS.ssl_version = 
ssl.PROTOCOL_TLSv1" and then call auth().

Deciding whether rejecting or accepting it will be up to the server 
depending on how it has been configured (almost all recent FTP servers 
reject SSLv2).

> I noticed you were using ftp.python.org in the example strings, but 
> that service doesn't seem to be alive. I don't know if there's another 
> public FTP-TLS server you could rely on...?

Yeah, I know. I just copied from original FTP class docstring.
As of now I'm not aware of any public FTPS server we could use.

----------

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

From report at bugs.python.org  Sat Nov  7 00:53:28 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 06 Nov 2009 23:53:28 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1257551608.62.0.464839293404.issue2054@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

> The user willing to use SSL instead of TLS will have to change 
> ssl_version class attribute with "FTP_TLS.ssl_version = 
> ssl.PROTOCOL_TLSv1" and then call auth().

Sorry but here I obviously meant "ssl.PROTOCOL_SSLv2/3"

----------

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

From report at bugs.python.org  Sat Nov  7 02:07:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Nov 2009 01:07:54 +0000
Subject: [issue3001] RLock's are SLOW
In-Reply-To: <1212074891.45.0.23606216758.issue3001@psf.upfronthosting.co.za>
Message-ID: <1257556074.44.0.663516507669.issue3001@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a new patch against py3k. It passes all tests and is generally
10-15x faster than the pure Python version.

----------
Added file: http://bugs.python.org/file15280/rlock2.patch

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

From report at bugs.python.org  Sat Nov  7 02:13:01 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Nov 2009 01:13:01 +0000
Subject: [issue3001] RLock's are SLOW
In-Reply-To: <1212074891.45.0.23606216758.issue3001@psf.upfronthosting.co.za>
Message-ID: <1257556381.83.0.358374717838.issue3001@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: needs patch -> patch review

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

From report at bugs.python.org  Sat Nov  7 05:08:24 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 07 Nov 2009 04:08:24 +0000
Subject: [issue7277] online docs out-of-sync with sources and distributed .chm
	files
In-Reply-To: <1257566904.77.0.989194227231.issue7277@psf.upfronthosting.co.za>
Message-ID: <1257566904.77.0.989194227231.issue7277@psf.upfronthosting.co.za>


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

The online version of the 2.6.4 documentation, at
http://www.python.org/doc/2.6.4/reference/simple_stmts.html#assignment-
statements
includes the changes made in r74822
But neither the source tarball nor the .chm Windows help file 
corresponding to the same release include such changes.

Same thing happens with other documentation changes, like r73163.

In case those changes were intentionally not merged into the 2.6 
branch, why does the online version show them?

----------
assignee: georg.brandl
components: Documentation
messages: 95008
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: online docs out-of-sync with sources and distributed .chm files
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Sat Nov  7 06:44:23 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 07 Nov 2009 05:44:23 +0000
Subject: [issue4722] _winreg.QueryValue fault while reading mangled registry
	values
In-Reply-To: <1229958391.62.0.85659959701.issue4722@psf.upfronthosting.co.za>
Message-ID: <1257572663.69.0.49342588458.issue4722@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

I cannot reproduce this bug with the current 2.6.4 release - it is 
either fixed or masked now.

----------

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

From report at bugs.python.org  Sat Nov  7 06:55:42 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 07 Nov 2009 05:55:42 +0000
Subject: [issue7277] online docs out-of-sync with sources and distributed .chm
	files
In-Reply-To: <1257566904.77.0.989194227231.issue7277@psf.upfronthosting.co.za>
Message-ID: <1257573342.39.0.303586605972.issue7277@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Because they were merged after 2.6.4 was tagged.  The online docs show
the current state of the branch rather than the tagged state, because
why not publish the doc fixes, since we can?  Yes, ideally they would
have been merged before the release, but that didn't happen.  I'm sure
Georg would be happy to have help merging doc fixes :)

----------
nosy: +r.david.murray
priority:  -> low
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Sat Nov  7 07:14:46 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 07 Nov 2009 06:14:46 +0000
Subject: [issue7268] 2to3 execfile conversion changes behavior
In-Reply-To: <1257466136.74.0.490341354872.issue7268@psf.upfronthosting.co.za>
Message-ID: <1257574486.11.0.177216041451.issue7268@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

The docs for the built-in function compile() say:

"Note: When compiling a string with multi-line statements, line endings 
must be represented by a single newline character ('\n'), and the input 
must be terminated by at least one newline character. If line endings 
are represented by '\r\n', use str.replace() to change them into '\n'."
http://www.python.org/doc/3.1/library/functions.html#compile

And the standard module py_compile ensures the source text ends with 
'\n' before calling the built-in compile function:

    if codestring and codestring[-1] != '\n':
        codestring = codestring + '\n'

I'd say the corresponding 2to3 fixer should do the same.

----------
nosy: +gagenellina

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

From report at bugs.python.org  Sat Nov  7 08:48:08 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 07 Nov 2009 07:48:08 +0000
Subject: [issue3001] RLock's are SLOW
In-Reply-To: <1212074891.45.0.23606216758.issue3001@psf.upfronthosting.co.za>
Message-ID: <00163691fe1f3ed1760477c32e9c@google.com>


Gregory P. Smith <greg at krypto.org> added the comment:

Reviewers: ,

http://codereview.appspot.com/150055/diff/1/4
File Modules/_threadmodule.c (right):

http://codereview.appspot.com/150055/diff/1/4#newcode221
Modules/_threadmodule.c:221: return PyBool_FromLong((long) r);
This explicit (long) cast is unnecessary.

http://codereview.appspot.com/150055/diff/1/4#newcode246
Modules/_threadmodule.c:246: PyThread_release_lock(self->rlock_lock);
reset self->rlock_owner to 0 before releasing the lock.

Description:
code review for http://bugs.python.org/issue3001

Please review this at http://codereview.appspot.com/150055

Affected files:
   M     Lib/test/test_threading.py
   M     Lib/threading.py
   M     Modules/_threadmodule.c

----------

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

From report at bugs.python.org  Sat Nov  7 09:26:53 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 07 Nov 2009 08:26:53 +0000
Subject: [issue7271] Typo in turtle module documentation.
In-Reply-To: <1257514346.42.0.243931952631.issue7271@psf.upfronthosting.co.za>
Message-ID: <1257582413.41.0.245337379867.issue7271@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r76143.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sat Nov  7 09:57:23 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 Nov 2009 08:57:23 +0000
Subject: [issue3001] RLock's are SLOW
In-Reply-To: <1212074891.45.0.23606216758.issue3001@psf.upfronthosting.co.za>
Message-ID: <1257584243.44.0.810494399338.issue3001@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

rlock_acquire_doc: "(...) return None once the lock is acquired".
That's wrong, acquire() always return a boolean (True or False).

rlock_release(): Is the assert(self->rlock_count > 0); really required?
You're checking its value few lines before.

rlock_acquire_restore(): raise an error if the lock acquire failed,
whereas rlock_acquire() doesn't. Why not raising an error in
rlock_acquire() (especially if blocking is True)? Or if the error can
never occur, remove the error checking in rlock_acquire_restore().

rlock_acquire_restore(): (maybe) set owner to 0 if count is 0.

rlock_release_save(): may also reset self->rlock_owner to 0, as
rlock_release().

rlock_new(): why not reusing type instead of Py_TYPE(self) in
"Py_TYPE(self)->tp_free(self)"?

__exit__: rlock_release() is defined as __exit__() with METH_VARARGS,
but it has no argument. Can it be a problem?

Anything, thanks for the faster RLock!

If your patch is commited, you can reconsider #3618 (possible deadlock
in python IO implementation).

----------

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

From report at bugs.python.org  Sat Nov  7 10:51:28 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 07 Nov 2009 09:51:28 +0000
Subject: [issue7278] decimal.py: New instance vs. new reference
In-Reply-To: <1257587488.65.0.148889938106.issue7278@psf.upfronthosting.co.za>
Message-ID: <1257587488.65.0.148889938106.issue7278@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

In the following case, Decimal() and int() behave differently. I wonder
if this is intentional:

>>> from decimal import *
>>> x = Decimal(2)
>>> y = Decimal(x)
>>> id(x) == id(y)
False
>>> 
>>> x = int(2)
>>> y = int(x)
>>> id(x) == id(y)
True
>>>

----------
messages: 95015
nosy: mark.dickinson, skrah
severity: normal
status: open
title: decimal.py: New instance vs. new reference

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

From report at bugs.python.org  Sat Nov  7 11:21:56 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 07 Nov 2009 10:21:56 +0000
Subject: [issue7268] 2to3 execfile conversion changes behavior
In-Reply-To: <1257466136.74.0.490341354872.issue7268@psf.upfronthosting.co.za>
Message-ID: <1257589316.96.0.261127266574.issue7268@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

This is a patch for the execfile fixer, so it converts
        execfile("fn")
into this:
        exec(compile(open("fn").read()+'\n', "fn", 'exec'))

(Yes, it looks ugly. A better way would be to fix the compile() builtin 
so it does not require the last line of source to end with '\n')

This is my very first incursion into 2to3 so it may be terribly wrong...

----------
keywords: +patch
Added file: http://bugs.python.org/file15281/lib2to3.diff

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

From report at bugs.python.org  Sat Nov  7 11:43:52 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 07 Nov 2009 10:43:52 +0000
Subject: [issue7279] decimal.py: == and != comparisons involving NaNs
In-Reply-To: <1257590632.12.0.893741146745.issue7279@psf.upfronthosting.co.za>
Message-ID: <1257590632.12.0.893741146745.issue7279@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

I'm not sure this is a bug, but I am trying to understand the rationale
for mimicking IEEE 754 for == and != comparisons involving NaNs. The
comment in decimal.py says:

"Note: The Decimal standard doesn't cover rich comparisons for Decimals.
 In particular, the specification is silent on the subject of what
should happen for a comparison involving a NaN."


First, I think rich comparisons are covered with compare_total(), but
indeed that isn't very useful for == and !=. (It might be useful for
sorting a list of decimals.)

The standard compare() function returns NaN for comparisons involving
NaNs. In addition to that it signals for sNaNs. I'm interpreting this as
"the comparison is undefined". So, in terms of decimal return values,
the standard does define NaN comparisons.

The question remains how to translate "undefined" to a Python truth
value. I'd think that the natural thing is to raise an InvalidOperation
exception in the same way it is done for <, <=, >, >=.


This ...

Decimal("NaN") == 9  ==> InvalidOperation
Decimal("sNaN") == 9  ==> InvalidOperation

... is the behavior of compare_signal(). In my opinion this would follow
the principle of least surprise for the user.

----------
messages: 95017
nosy: mark.dickinson, skrah
severity: normal
status: open
title: decimal.py: == and != comparisons involving NaNs

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

From report at bugs.python.org  Sat Nov  7 16:06:59 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Nov 2009 15:06:59 +0000
Subject: [issue3001] RLock's are SLOW
In-Reply-To: <1212074891.45.0.23606216758.issue3001@psf.upfronthosting.co.za>
Message-ID: <0016361e86cc72961c0477c94fc0@google.com>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the review. I will make the suggested modifications.

http://codereview.appspot.com/150055/diff/1/4
File Modules/_threadmodule.c (right):

http://codereview.appspot.com/150055/diff/1/4#newcode221
Modules/_threadmodule.c:221: return PyBool_FromLong((long) r);
On 2009/11/07 07:48:05, gregory.p.smith wrote:
> This explicit (long) cast is unnecessary.

Right.

http://codereview.appspot.com/150055/diff/1/4#newcode246
Modules/_threadmodule.c:246: PyThread_release_lock(self->rlock_lock);
On 2009/11/07 07:48:05, gregory.p.smith wrote:
> reset self->rlock_owner to 0 before releasing the lock.

We always check rlock_count before rlock_owner anyway but, yes, I could
reset rlock_owner out of safety.

http://codereview.appspot.com/150055

----------

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

From report at bugs.python.org  Sat Nov  7 16:17:16 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Nov 2009 15:17:16 +0000
Subject: [issue3001] RLock's are SLOW
In-Reply-To: <1257584243.44.0.810494399338.issue3001@psf.upfronthosting.co.za>
Message-ID: <1257607036.3437.12.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> rlock_acquire_doc: "(...) return None once the lock is acquired".
> That's wrong, acquire() always return a boolean (True or False).

You're right, I should fix that docstring.

> rlock_release(): Is the assert(self->rlock_count > 0); really required?
> You're checking its value few lines before.

Right again :) I forgot this was unsigned.

> rlock_acquire_restore(): raise an error if the lock acquire failed,
> whereas rlock_acquire() doesn't. Why not raising an error in
> rlock_acquire() (especially if blocking is True)?

For rlock_acquire(), I mimicked what the Python code (_PyRLock.acquire)
does: if locking fails, it returns False instead. It is part of the API.

(and I agree this is not necessarily right, because failing to lock if
blocking is True would probably indicate a low-level system error, but
the purpose of the patch is not to change the API)

But you're right that the Python version of rlock_acquire_restore()
doesn't check the return code either, so I may remove this check from
the C code, although the rest of the method clearly assumes the lock has
been taken.

> rlock_acquire_restore(): (maybe) set owner to 0 if count is 0.
> 
> rlock_release_save(): may also reset self->rlock_owner to 0, as
> rlock_release().

As I said to Gregory, the current code doesn't rely on rlock_owner to be
reset but, yes, we could still add it out of safety.

> rlock_new(): why not reusing type instead of Py_TYPE(self) in
> "Py_TYPE(self)->tp_free(self)"?

Good point.

> __exit__: rlock_release() is defined as __exit__() with METH_VARARGS,
> but it has no argument. Can it be a problem?

I just mimicked the corresponding declarations in the non-recursive lock
object. Apparently it's safe on all architectures Python has been
running on for years, although I agree it looks strange.

> If your patch is commited, you can reconsider #3618 (possible deadlock
> in python IO implementation).

Indeed.

Thanks !

----------

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

From report at bugs.python.org  Sat Nov  7 18:39:06 2009
From: report at bugs.python.org (Anand B Pillai)
Date: Sat, 07 Nov 2009 17:39:06 +0000
Subject: [issue3488] Provide compress/uncompress functions on the gzip module
In-Reply-To: <1217613416.28.0.352724086622.issue3488@psf.upfronthosting.co.za>
Message-ID: <1257615546.89.0.985860792789.issue3488@psf.upfronthosting.co.za>


Changes by Anand B Pillai <abpillai at gmail.com>:


Removed file: http://bugs.python.org/file11035/gzip_patch.py

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

From report at bugs.python.org  Sat Nov  7 18:39:13 2009
From: report at bugs.python.org (Anand B Pillai)
Date: Sat, 07 Nov 2009 17:39:13 +0000
Subject: [issue3488] Provide compress/uncompress functions on the gzip module
In-Reply-To: <1217613416.28.0.352724086622.issue3488@psf.upfronthosting.co.za>
Message-ID: <1257615553.54.0.632997110257.issue3488@psf.upfronthosting.co.za>


Changes by Anand B Pillai <abpillai at gmail.com>:


Removed file: http://bugs.python.org/file11044/gzip.patch

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

From report at bugs.python.org  Sat Nov  7 18:39:18 2009
From: report at bugs.python.org (Anand B Pillai)
Date: Sat, 07 Nov 2009 17:39:18 +0000
Subject: [issue3488] Provide compress/uncompress functions on the gzip module
In-Reply-To: <1217613416.28.0.352724086622.issue3488@psf.upfronthosting.co.za>
Message-ID: <1257615558.65.0.42694688541.issue3488@psf.upfronthosting.co.za>


Changes by Anand B Pillai <abpillai at gmail.com>:


Removed file: http://bugs.python.org/file11050/gzip_svn_diff.patch

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

From report at bugs.python.org  Sat Nov  7 18:41:06 2009
From: report at bugs.python.org (Anand B Pillai)
Date: Sat, 07 Nov 2009 17:41:06 +0000
Subject: [issue3488] Provide compress/uncompress functions on the gzip module
In-Reply-To: <1217613416.28.0.352724086622.issue3488@psf.upfronthosting.co.za>
Message-ID: <1257615666.07.0.782350673092.issue3488@psf.upfronthosting.co.za>


Anand B Pillai <abpillai at gmail.com> added the comment:

Uploading fresh gzip.py SVN diff with a minor change, i.e accepting a
regular string as argument, aka zlib.compress.

----------
Added file: http://bugs.python.org/file15282/gzip.py.svndiff

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

From report at bugs.python.org  Sat Nov  7 18:41:44 2009
From: report at bugs.python.org (Anand B Pillai)
Date: Sat, 07 Nov 2009 17:41:44 +0000
Subject: [issue3488] Provide compress/uncompress functions on the gzip module
In-Reply-To: <1217613416.28.0.352724086622.issue3488@psf.upfronthosting.co.za>
Message-ID: <1257615704.84.0.129785866981.issue3488@psf.upfronthosting.co.za>


Anand B Pillai <abpillai at gmail.com> added the comment:

Uploading rst documentation svn diff for module.

----------
Added file: http://bugs.python.org/file15283/gzip.rst.svndiff

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

From report at bugs.python.org  Sat Nov  7 18:47:31 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Nov 2009 17:47:31 +0000
Subject: [issue3001] RLock's are SLOW
In-Reply-To: <1212074891.45.0.23606216758.issue3001@psf.upfronthosting.co.za>
Message-ID: <1257616051.16.0.988340046881.issue3001@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is an updated patch. I addressed all review comments, except the
one about acquire_restore() checking the return result of acquire(),
because I think it's really a weakness in the Python implementation.

----------
Added file: http://bugs.python.org/file15284/rlock3.patch

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

From report at bugs.python.org  Sat Nov  7 20:44:52 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 07 Nov 2009 19:44:52 +0000
Subject: [issue3001] RLock's are SLOW
In-Reply-To: <1212074891.45.0.23606216758.issue3001@psf.upfronthosting.co.za>
Message-ID: <1257623092.83.0.674177382692.issue3001@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Can you make the C implementation's repr() show something similar to the 
Python implementation?

----------

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

From report at bugs.python.org  Sat Nov  7 21:12:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Nov 2009 20:12:20 +0000
Subject: [issue3001] RLock's are SLOW
In-Reply-To: <1212074891.45.0.23606216758.issue3001@psf.upfronthosting.co.za>
Message-ID: <1257624740.62.0.654854345274.issue3001@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Yes, here is a new patch adding tp_repr.

----------
Added file: http://bugs.python.org/file15285/rlock4.patch

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

From report at bugs.python.org  Sat Nov  7 21:18:53 2009
From: report at bugs.python.org (Baptiste Lepilleur)
Date: Sat, 07 Nov 2009 20:18:53 +0000
Subject: [issue7280] PCBuild instruction says to use nasmw.exe but it no
	longer exist
In-Reply-To: <1257625133.53.0.426769488546.issue7280@psf.upfronthosting.co.za>
Message-ID: <1257625133.53.0.426769488546.issue7280@psf.upfronthosting.co.za>


New submission from Baptiste Lepilleur <blep at users.sourceforge.net>:

PCBuild requires nasmw.exe but it no longer exists in the latest version
of nasm. 

I had to rename nasm.exe to nasmw.exe. Would be nice to add this to the
readme to avoid confusion...

----------
components: Build
files: nasm-doc.patch
keywords: patch
messages: 95025
nosy: blep
severity: normal
status: open
title: PCBuild instruction says to use nasmw.exe but it no longer exist
versions: Python 3.1
Added file: http://bugs.python.org/file15286/nasm-doc.patch

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

From report at bugs.python.org  Sat Nov  7 21:40:08 2009
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 07 Nov 2009 20:40:08 +0000
Subject: [issue4722] _winreg.QueryValue fault while reading mangled registry
	values
In-Reply-To: <1229958391.62.0.85659959701.issue4722@psf.upfronthosting.co.za>
Message-ID: <1257626408.97.0.0523939543823.issue4722@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

It happens to me on trunk with Windows XP. I also have access to Windows
Server 2003 where I can test this (haven't yet). Which version are you
running that you don't see this issue?

----------

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

From report at bugs.python.org  Sat Nov  7 21:41:39 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 07 Nov 2009 20:41:39 +0000
Subject: [issue7281] copysign() with NaN arguments on OpenSolaris
In-Reply-To: <1257626499.13.0.928047451376.issue7281@psf.upfronthosting.co.za>
Message-ID: <1257626499.13.0.928047451376.issue7281@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Sorry to report so many obscure corner cases. With the combination
Opensolaris/suncc/Python3.x copysign() gives reversed results when the
second argument is a NaN. The bug is in the C99 copysign() function
(OpenSolaris/suncc), but Python2.6 seems to have a workaround: 

Python 3.2a0 (py3k:76144, Nov  7 2009, 18:50:00) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> from math import *
>>> copysign(1.0, float("nan"))
-1.0
>>> copysign(1.0, float("-nan"))
1.0

Python 2.6.2 (r262:71600, Nov  7 2009, 19:29:52) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> from math import copysign
>>> copysign(1.0, float("nan"))
1.0
>>> copysign(1.0, float("-nan"))
-1.0
>>>

----------
messages: 95027
nosy: mark.dickinson, skrah
severity: normal
status: open
title: copysign() with NaN arguments on OpenSolaris
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Nov  7 21:42:14 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 07 Nov 2009 20:42:14 +0000
Subject: [issue7279] decimal.py: == and != comparisons involving NaNs
In-Reply-To: <1257590632.12.0.893741146745.issue7279@psf.upfronthosting.co.za>
Message-ID: <1257626534.01.0.151314430082.issue7279@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
type:  -> behavior

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

From report at bugs.python.org  Sat Nov  7 21:42:31 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 07 Nov 2009 20:42:31 +0000
Subject: [issue7278] decimal.py: New instance vs. new reference
In-Reply-To: <1257587488.65.0.148889938106.issue7278@psf.upfronthosting.co.za>
Message-ID: <1257626551.9.0.306246132929.issue7278@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
type:  -> behavior

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

From report at bugs.python.org  Sun Nov  8 00:57:59 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 07 Nov 2009 23:57:59 +0000
Subject: [issue7187] importlib/_bootstrap.py write_bytecode raises an IOError
	if it can't open the .pyc file for writing
In-Reply-To: <1256243827.37.0.0884595993995.issue7187@psf.upfronthosting.co.za>
Message-ID: <1257638279.66.0.646293349478.issue7187@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Committed to py3k in r76146 and r76147 for 3.1.

Thanks for the detailed report, Dave!

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sun Nov  8 01:00:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Nov 2009 00:00:40 +0000
Subject: [issue7282] RLocks leak references when used in raw threads
In-Reply-To: <1257638440.73.0.268077668125.issue7282@psf.upfronthosting.co.za>
Message-ID: <1257638440.73.0.268077668125.issue7282@psf.upfronthosting.co.za>


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

When you use an RLock from a thread which wasn't created through the
high-level `threading` API (but, for example, using
thread.start_new_thread()), the RLock creates a DummyThread object by
calling current_thread(), and that DummyThread is immortal (as well as
its attributes etc.). This implementation wart can easily lead to
reference leaks for unsuspecting users.

One simple solution is not to call current_thread() in RLock, but use
get_ident() instead. Patch attached.

----------
components: Library (Lib)
files: rlock_leak.patch
keywords: patch
messages: 95029
nosy: pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: RLocks leak references when used in raw threads
type: resource usage
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15287/rlock_leak.patch

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

From report at bugs.python.org  Sun Nov  8 01:14:45 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 08 Nov 2009 00:14:45 +0000
Subject: [issue7278] decimal.py: New instance vs. new reference
In-Reply-To: <1257587488.65.0.148889938106.issue7278@psf.upfronthosting.co.za>
Message-ID: <1257639285.87.0.108618121853.issue7278@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I don't think it should matter whether either 'id(x) == id(y)' returns 
True or False:  since both ints and Decimals are regarded as immutable, 
the implementation should be free to reuse (or not) existing objects at 
will.

There is a test in test_decimal.py that seems to expect that Decimal(x) 
always returns a copy.  I'm not quite sure why that test is there, 
though it may be because Decimal instances weren't always as immutable 
as they are now (some of the non-__new__ methods used to modify the 
Decimal fields directly).  In my opinion that test could be removed, but 
I'd like to consult with some of the other Decimal authors before doing 
so.

(An aside: it's important to note that operations on Decimal subclasses 
should always return *Decimal* instances, not instances of the subclass.
So any code like:

  if isinstance(x, Decimal): return x

should be regarded with suspicion.)

N.B. Some of your recent reports seem more like questions about the 
implementation rather than reports of possible bugs in Python;  I'm not 
sure that the bug tracker is the best medium for this.  python-dev might 
be more appropriate, or I'm happy to answer private emails.

----------

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

From report at bugs.python.org  Sun Nov  8 01:27:14 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Nov 2009 00:27:14 +0000
Subject: [issue7283] test_site failure when Python gets installed along a
	symbolic link
In-Reply-To: <1257640034.65.0.139323856655.issue7283@psf.upfronthosting.co.za>
Message-ID: <1257640034.65.0.139323856655.issue7283@psf.upfronthosting.co.za>


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

On that buildbot, /var/lib/buildbot is a symlink to /home/buildbot and I
get the following failure:

======================================================================
FAIL: test_s_option (test.test_site.HelperFunctionsTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home/buildbot/cpython-ucs2/3.x.pitrou-ubuntu/build/Lib/test/test_site.py",
line 107, in test_s_option
    self.assertIn(usersite, sys.path)
AssertionError: '/var/lib/buildbot/.local/lib/python3.2/site-packages'
not found in ['/usr/local/lib/python32.zip',
'/home/buildbot/cpython-ucs2/3.x.pitrou-ubuntu/build/Lib',
'/home/buildbot/cpython-ucs2/3.x.pitrou-ubuntu/build/Lib/plat-linux2',
'/home/buildbot/cpython-ucs2/3.x.pitrou-ubuntu/build/Modules',
'/home/buildbot/cpython-ucs2/3.x.pitrou-ubuntu/build/build/lib.linux-x86_64-3.2-pydebug']

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

----------
assignee: tarek
components: Tests
messages: 95031
nosy: pitrou, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_site failure when Python gets installed along a symbolic link
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Nov  8 01:28:26 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Nov 2009 00:28:26 +0000
Subject: [issue7283] test_site failure when Python gets installed along a
	symbolic link
In-Reply-To: <1257640034.65.0.139323856655.issue7283@psf.upfronthosting.co.za>
Message-ID: <1257640106.71.0.103555580442.issue7283@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, I'm not sure the symlink is actually the problem. Apparently the
".local" directory hadn't been created when the first test run.

----------

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

From report at bugs.python.org  Sun Nov  8 01:30:03 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 08 Nov 2009 00:30:03 +0000
Subject: [issue7281] copysign() with NaN arguments on OpenSolaris
In-Reply-To: <1257626499.13.0.928047451376.issue7281@psf.upfronthosting.co.za>
Message-ID: <1257640203.23.0.367021606125.issue7281@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

You may have let yourself in for something here.  :-)

Can you tell me what:

>>> import sys
>>> print sys.float_repr_style

gives for your Opensolaris/suncc/Python3.x combination?  If it prints 
'legacy', then I'd dearly like some help with making it read 'short' 
instead.  That would then make treatment of nans on that combination 
consistent with other platforms.

All I really need to know is how to set the x87 (I'm assuming you're on 
32-bit x86 here) FPU control word using suncc.  Oh, and a willing victim 
to test changes.  Look for HAVE_PY_SET_53BIT_PRECISION in 
Include/pyport.h for details.


Having said that, I don't really see this difference with nans as an 
actual bug.  Is it possible that float("nan") is simply giving a nan 
with its sign bit set here, and that float("-nan") is giving a nan with 
no sign bit set?  That would actually be quite unsurprising, since 
according to Intel's manuals, the 'default' NaN value returned by 
invalid operations has its sign bit set.  It would also be (I think) 
quite legal:  sign bits of NaNs don't make a lot of sense anyway, and I 
don't think Python should specify anything about the sign bit (or indeed 
the payload) of the NaN coming from float('nan').

In other words, I think it's not unreasonable to regard the sign of
copysign(x, y) as undefined whenever y is a nan.  (I'm fairly sure that 
MPFR takes this attitude, for example.)

----------

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

From report at bugs.python.org  Sun Nov  8 01:51:38 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Nov 2009 00:51:38 +0000
Subject: [issue7283] test_site failure when .local/lib/pythonX.Y/site-packages
	hasn't been created yet
In-Reply-To: <1257640034.65.0.139323856655.issue7283@psf.upfronthosting.co.za>
Message-ID: <1257641498.77.0.110135350876.issue7283@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
title: test_site failure when Python gets installed along a symbolic link -> test_site failure when .local/lib/pythonX.Y/site-packages hasn't been created yet

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

From report at bugs.python.org  Sun Nov  8 01:56:22 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 08 Nov 2009 00:56:22 +0000
Subject: [issue7284] optparse - display version in usage by default
In-Reply-To: <1257641781.98.0.415542584092.issue7284@psf.upfronthosting.co.za>
Message-ID: <1257641781.98.0.415542584092.issue7284@psf.upfronthosting.co.za>


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

It would be useful if optparse could display version right in usage help 
before command syntax. Right now it can only output either usage or 
version.

----------
messages: 95034
nosy: techtonik
severity: normal
status: open
title: optparse - display version in usage by default
type: feature request

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

From report at bugs.python.org  Sun Nov  8 03:32:00 2009
From: report at bugs.python.org (Kouki Hashimoto)
Date: Sun, 08 Nov 2009 02:32:00 +0000
Subject: [issue7285] multiprocessing module, example code error
In-Reply-To: <1257647520.68.0.169575152715.issue7285@psf.upfronthosting.co.za>
Message-ID: <1257647520.68.0.169575152715.issue7285@psf.upfronthosting.co.za>


New submission from Kouki Hashimoto <hsmtkk at gmail.com>:

Example codes on multiprocessing module occur errors.
I attached the patch to fix these errors.

http://docs.python.org/dev/py3k/library/multiprocessing.html#module-
multiprocessing
"16.6.2.10. Listeners and Clients" section

Fix points are
1. Listener argument "authkey" must be a byte string
2. Client argument "authkey" must be a byte string
3. send_bytes argument must be a byte string

This is the server code listed on the section.
$ cat mpserver.py
from multiprocessing.connection import Listener
from array import array
address = ('localhost', 6000)     # family is deduced to be 'AF_INET'
listener = Listener(address, authkey='secret password')
conn = listener.accept()
print('connection accepted from', listener.last_accepted)
conn.send([2.25, None, 'junk', float])
conn.send_bytes('hello')
conn.send_bytes(array('i', [42, 1729]))
conn.close()
listener.close()

And the error is
$ python3.2 mpserver.py
Traceback (most recent call last):
  File "mpserver1.py", line 5, in <module>
    listener = Listener(address, authkey='secret password')
  File 
"/Users/kosmos/local/stow/py3k/lib/python3.2/multiprocessing/connection.
py", line 100, in __init__
    raise TypeError('authkey should be a byte string')
TypeError: authkey should be a byte string

My source code is svn revision 76151.
Regards.

---
Kouki Hashimoto
hsmtkk at gmail.com

----------
assignee: georg.brandl
components: Documentation
files: multiprocessing.rst.diff
keywords: patch
messages: 95035
nosy: georg.brandl, hsmtkk
severity: normal
status: open
title: multiprocessing module, example code error
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file15288/multiprocessing.rst.diff

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

From report at bugs.python.org  Sun Nov  8 05:35:40 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 08 Nov 2009 04:35:40 +0000
Subject: [issue7285] multiprocessing module, example code error
In-Reply-To: <1257647520.68.0.169575152715.issue7285@psf.upfronthosting.co.za>
Message-ID: <1257654940.17.0.484342794449.issue7285@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee: georg.brandl -> jnoller
nosy: +jnoller

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

From report at bugs.python.org  Sun Nov  8 07:39:06 2009
From: report at bugs.python.org (Peter Mawhorter)
Date: Sun, 08 Nov 2009 06:39:06 +0000
Subject: [issue7286] odd exec() behavior or documentation
In-Reply-To: <1257662346.28.0.188136963391.issue7286@psf.upfronthosting.co.za>
Message-ID: <1257662346.28.0.188136963391.issue7286@psf.upfronthosting.co.za>


New submission from Peter Mawhorter <pmawhorter at gmail.com>:

The behavior of the built-in exec() function differs in Python3.1 from
the behavior in Python 2.6 when only a single argument is passed.
Additionally, the documentation for the function does not suggest the
behavior that it has. In Python2.6, an exec statement could both access
and change the values of local variables. In Python3.1, it can read
values from the local scope, but can't change them. Run the attached
script to see examples of this behavior. Note especially that in the
first function, the exec'd code changes the value of a variable called
'value'. However, the change isn't visible after the call to exec(),
because the value changed was a local variable and presumably, the
update is dropped after the exec() finishes. To me, this conflicts with
the statement in the documentation that "In all cases, if the optional
parts are omitted, the code is executed in the current scope." At the
very least, a sentence or two should be added to the documentation
explaining that exec() can't affect the value of local variables. In
addition, it's strange that, for example, in a function declaring
"global value", an exec() statement that modifies 'value' doesn't affect
the value of the global variable. In this sense, the code being exec'd
doesn't seem to be running in a perfect copy of the function's scope.

If it were up to me, I'd allow code being executed by an exec()
statement to modify the value of local variables, because that keeps
with the paradigm of the exec'd code being simply dynamic code that
behaves as if it were written in-line. It also means that programmers
who need to change things with an exec statement aren't limited to
pushing their changes through global variables, which can lead to
conflicts with name sharing (for example, what if my exec() statement is
in a recursive function?). Of course, implementing this may be
difficult... so it may be better just to add to the documentation to
explain this behavior of exec().

----------
assignee: georg.brandl
components: Documentation, Interpreter Core
files: test.py
messages: 95036
nosy: georg.brandl, pmawhorter
severity: normal
status: open
title: odd exec() behavior or documentation
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file15289/test.py

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

From report at bugs.python.org  Sun Nov  8 07:40:40 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 08 Nov 2009 06:40:40 +0000
Subject: [issue7278] decimal.py: New instance vs. new reference
In-Reply-To: <1257587488.65.0.148889938106.issue7278@psf.upfronthosting.co.za>
Message-ID: <1257662440.37.0.975281416946.issue7278@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Stefan, this is a non-guaranteed implementation detail (for both ints
and decimals).

----------
nosy: +rhettinger
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Sun Nov  8 08:37:28 2009
From: report at bugs.python.org (Brian Harring)
Date: Sun, 08 Nov 2009 07:37:28 +0000
Subject: [issue3475] _elementtree.c import can fail silently
In-Reply-To: <1217488390.82.0.966024621847.issue3475@psf.upfronthosting.co.za>
Message-ID: <1257665848.63.0.734142877767.issue3475@psf.upfronthosting.co.za>


Brian Harring <ferringb at gmail.com> added the comment:

At this point, this affects 2.5, 2.6, and 3.1 (and the normal 1.0.5
release of cElementTree); what's required to get this fixed and queued
up for micro/minor releases?

Sidenote, the patch posted above still leaks a reference-

----------
keywords: +patch
nosy: +ferringb
Added file: http://bugs.python.org/file15290/fix-celementtree.patch

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

From report at bugs.python.org  Sun Nov  8 10:28:50 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 08 Nov 2009 09:28:50 +0000
Subject: [issue7279] decimal.py: == and != comparisons involving NaNs
In-Reply-To: <1257590632.12.0.893741146745.issue7279@psf.upfronthosting.co.za>
Message-ID: <1257672530.83.0.836585441467.issue7279@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

There's a second issue to consider here, which is that Python uses 
equality as specified by the == operator as the basic equivalence relation 
for set and dict membership tests.  So as a general rule, an equality test 
between two objects of the same type shouldn't be raising exceptions.  If 
== raised for comparisons with nans then it would make it awkward to put 
nans into a set.

Hmm.  But now I notice that you can't put Decimal nans into sets anyway:  
you get a 'TypeError: Cannot hash a NaN value'.  I'm not sure of the 
rationale for this.

One might also question whether Decimal("NaN") < 9 should really be 
raising InvalidOperation, or whether (as an operation that doesn't return 
a Decimal instance and is in some sense outside the scope of the standard-
--similar to int(Decimal('nan')) and hash(Decimal('nan'))) it should be 
raising some general Python exception instead.

I'm closing this as invalid: the behaviour isn't a bug, at least in the 
sense that the code is working as designed.  I think there may well be a 
useful discussion here, but the bugtracker isn't the right place to have 
it:  could we move it to python-dev instead?

----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Sun Nov  8 14:30:50 2009
From: report at bugs.python.org (Baptiste Lepilleur)
Date: Sun, 08 Nov 2009 13:30:50 +0000
Subject: [issue7287] import hook demo does not work
In-Reply-To: <1257687050.33.0.193418499466.issue7287@psf.upfronthosting.co.za>
Message-ID: <1257687050.33.0.193418499466.issue7287@psf.upfronthosting.co.za>


New submission from Baptiste Lepilleur <blep at users.sourceforge.net>:

The import hook demo in the source directory
Python-3.1.1\Demo\imputil\knee.py fails to run correctly:

Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import knee
>>> import ctypes.utils
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: import_hook() takes at most 4 positional arguments (5 given)
>>>

----------
components: Demos and Tools
messages: 95040
nosy: blep
severity: normal
status: open
title: import hook demo does not work
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Sun Nov  8 14:49:13 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 08 Nov 2009 13:49:13 +0000
Subject: [issue7281] copysign() with NaN arguments on OpenSolaris
In-Reply-To: <1257626499.13.0.928047451376.issue7281@psf.upfronthosting.co.za>
Message-ID: <1257688153.86.0.996709680292.issue7281@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I hope this won't be getting too complex. :)

Firstly, I agree that this is perhaps not a bug at all. I reported it
because I seemed possible that Python2.x had a deliberate workaround for
this issue which somehow got lost in 3.x.

Secondly, I didn't mention that I'm running OpenSolaris on KVM since I
can't get it to install on physical hardware. However, I don't think KVM
plays a role here since gcc produces 'normal' results.

So, the problem combination is:

Ubuntu64bit -> KVM -> OpenSolaris32bit/suncc/Py3k


On the C level, here's an example:

#include <stdio.h>
#include <math.h>

int main(void)
{
        double x = NAN;
        printf("%f  %f\n", x, copysign(1.0, x));
        return 0;
}

This gives -NaN, -1.000000 with suncc and NaN, 1.000000 with gcc. 


Back to Python:

sys.float_repr_style is 'legacy'.

It looks like the C99 fenv functions are pretty much supported, but I
don't know since when. I found man pages from 2003 for fenv and from
2006 for the fe*() functions.

This for example works:

#include <stdio.h>
#include <stdio.h>
#include <fenv.h>
#include <assert.h>

int main(void)
{
        #pragma STDC FENV_ACCESS ON
        int save_round;
        int setround_ok;

        save_round = fegetround();

        setround_ok = fesetround(FE_DOWNWARD);
        assert(setround_ok == 0);

        fesetround(save_round);
}


I could test changes that you make (preferably in p3k head, so I could
just pull them). But as I said: If the 'proper' behavior in 2.x was not
a deliberate workaround, there's really no need to change anything.

----------

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

From report at bugs.python.org  Sun Nov  8 15:10:36 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Nov 2009 14:10:36 +0000
Subject: [issue3001] RLock's are SLOW
In-Reply-To: <1212074891.45.0.23606216758.issue3001@psf.upfronthosting.co.za>
Message-ID: <1257689436.12.0.672161987332.issue3001@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

rlock4.patch looks correct and pass test_threading.py tests.

----------

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

From report at bugs.python.org  Sun Nov  8 19:30:30 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 08 Nov 2009 18:30:30 +0000
Subject: [issue3475] _elementtree.c import can fail silently
In-Reply-To: <1217488390.82.0.966024621847.issue3475@psf.upfronthosting.co.za>
Message-ID: <1257705030.73.0.827695729699.issue3475@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

For 2.5, this will not be fixed, as it is not security-critical.

----------
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5

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

From report at bugs.python.org  Sun Nov  8 19:35:40 2009
From: report at bugs.python.org (Fredrik Lundh)
Date: Sun, 08 Nov 2009 18:35:40 +0000
Subject: [issue3475] _elementtree.c import can fail silently
In-Reply-To: <1217488390.82.0.966024621847.issue3475@psf.upfronthosting.co.za>
Message-ID: <1257705340.23.0.0838944665445.issue3475@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

Note that "fail silently" is a bit of a misnomer - if the embedded import 
doesn't work, portions of the library will fail pretty loudly.  Feel free 
to use some variation of the suggested patch, or just wait until the next 
upstream release gets imported (if ever).

----------

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

From report at bugs.python.org  Sun Nov  8 21:43:16 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Nov 2009 20:43:16 +0000
Subject: [issue6233] ElementTree (py3k) doesn't properly encode characters
	that can't be represented in the specified encoding
In-Reply-To: <1244410260.68.0.534028988218.issue6233@psf.upfronthosting.co.za>
Message-ID: <1257712996.23.0.725545853925.issue6233@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch looks ok to me.

----------

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

From report at bugs.python.org  Sun Nov  8 22:42:06 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 Nov 2009 21:42:06 +0000
Subject: [issue5611] Auto-detect indentation in C source in vimrc
In-Reply-To: <1238436646.8.0.898787236764.issue5611@psf.upfronthosting.co.za>
Message-ID: <1257716526.4.0.106305840854.issue5611@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

in r76154 for trunk and r76155 for py3k. Thanks for the help, guys!

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Nov  8 22:46:55 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 Nov 2009 21:46:55 +0000
Subject: [issue7288] Detect improper leading whitespace in C files for Vim
In-Reply-To: <1257716815.02.0.0950136651799.issue7288@psf.upfronthosting.co.za>
Message-ID: <1257716815.02.0.0950136651799.issue7288@psf.upfronthosting.co.za>


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

With the proper detection for C files using either tabs or spaces now in 
there should also be proper highlighting when the wrong leading whitespace 
is used, e.g. if the file uses tabs then any lines with "^ +" should be 
flagged as wrong.

----------
assignee: brett.cannon
components: None
keywords: easy
messages: 95047
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: Detect improper leading whitespace in C files for Vim
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Nov  8 23:03:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Nov 2009 22:03:51 +0000
Subject: [issue7288] Detect improper leading whitespace in C files for Vim
In-Reply-To: <1257716815.02.0.0950136651799.issue7288@psf.upfronthosting.co.za>
Message-ID: <1257717831.05.0.241028783681.issue7288@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As a non-Vim user, I don't really care, but lines beginning with spaces
are valid if you want to indent by something smaller than a tab (this is
common in comments).

----------
nosy: +pitrou

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

From report at bugs.python.org  Mon Nov  9 00:31:24 2009
From: report at bugs.python.org (Alan Gauld)
Date: Sun, 08 Nov 2009 23:31:24 +0000
Subject: [issue7289] bad import in redemo.py script in v3.1
In-Reply-To: <1257723084.57.0.829178832039.issue7289@psf.upfronthosting.co.za>
Message-ID: <1257723084.57.0.829178832039.issue7289@psf.upfronthosting.co.za>


New submission from Alan Gauld <alan.gauld at btinternet.com>:

The Tkinter import in redemo.py in Tools/Scripts folder of the 3.1 
distribution uses the old spelling of Tkinter. Changing it to lower case 
fixes it. I've just noticed there is a 3.2 listed, I haven't checked 
whether it's been fixed there but its not mentioned in the change log for 
3.1.1

----------
components: Demos and Tools
messages: 95049
nosy: alan.gauld at btinternet.com
severity: normal
status: open
title: bad import in redemo.py script in v3.1
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Nov  9 01:43:29 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 09 Nov 2009 00:43:29 +0000
Subject: [issue7289] bad import in redemo.py script in v3.1
In-Reply-To: <1257723084.57.0.829178832039.issue7289@psf.upfronthosting.co.za>
Message-ID: <1257727409.89.0.921178914699.issue7289@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r76156.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Mon Nov  9 02:22:04 2009
From: report at bugs.python.org (Ilya Sandler)
Date: Mon, 09 Nov 2009 01:22:04 +0000
Subject: [issue1294] Management of KeyboardInterrupt in cmd.py
In-Reply-To: <1192711916.5.0.235687394478.issue1294@psf.upfronthosting.co.za>
Message-ID: <1257729724.99.0.486336497157.issue1294@psf.upfronthosting.co.za>


Ilya Sandler <ilya.sandler at gmail.com> added the comment:

Is not this patch backward incompatible?

E.g any cmd-based application which expects Ctrl-C to propagate to the
top level will be broken by this patch.

As for pdb, I don't think pdb will benefit from this patch: as I believe
that pdb needs something along the lines of patch #7245 for Ctrl-C
(temporary interrupt of execution with ability to resume similar to what
gdb does)

----------
nosy: +isandler

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

From report at bugs.python.org  Mon Nov  9 02:35:33 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Nov 2009 01:35:33 +0000
Subject: [issue6986] _json crash on scanner/encoder initialization error
In-Reply-To: <1253791266.79.0.0913001727674.issue6986@psf.upfronthosting.co.za>
Message-ID: <1257730533.85.0.0272394026036.issue6986@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New version of my patch:
 * don't create file in Lib/json/tests/: add new tests in
Lib/json/tests/test_speedups.py as asked by pitrou
 * use json.scanner.c_make_scanner and json.encoder.c_make_encoder in
the test, instead of using directly the _json module

----------
Added file: http://bugs.python.org/file15291/json-crash-2.patch

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

From report at bugs.python.org  Mon Nov  9 02:40:00 2009
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 09 Nov 2009 01:40:00 +0000
Subject: [issue7288] Detect improper leading whitespace in C files for Vim
In-Reply-To: <1257716815.02.0.0950136651799.issue7288@psf.upfronthosting.co.za>
Message-ID: <1257730800.19.0.14647538565.issue7288@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Ah nuts, you're right. I guess it will only work for starting with tabs 
when spaces are being used for the indentation.

----------

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

From report at bugs.python.org  Mon Nov  9 02:40:09 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Nov 2009 01:40:09 +0000
Subject: [issue6986] _json crash on scanner/encoder initialization error
In-Reply-To: <1253791266.79.0.0913001727674.issue6986@psf.upfronthosting.co.za>
Message-ID: <1257730809.12.0.53704114329.issue6986@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file15291/json-crash-2.patch

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

From report at bugs.python.org  Mon Nov  9 02:41:13 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Nov 2009 01:41:13 +0000
Subject: [issue6986] _json crash on scanner/encoder initialization error
In-Reply-To: <1253791266.79.0.0913001727674.issue6986@psf.upfronthosting.co.za>
Message-ID: <1257730873.1.0.187590100257.issue6986@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oops, you forget json-crash-2.patch, the patch was completly wrong.
Check the json-crash-3.patch.

----------
Added file: http://bugs.python.org/file15292/json-crash-3.patch

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

From report at bugs.python.org  Mon Nov  9 02:43:26 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Nov 2009 01:43:26 +0000
Subject: [issue3999] Real segmentation fault handler
In-Reply-To: <1222737012.4.0.203589723568.issue3999@psf.upfronthosting.co.za>
Message-ID: <1257731006.56.0.271927892446.issue3999@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

My idea was rejected on python-dev mailing list. But I'm unable to
write a patch to dump a backtrace on segfault. Anyway it would be a
complelty different patch (and so a different issue). So I prefer to
close this (old) issue.

----------
status: open -> closed

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

From report at bugs.python.org  Mon Nov  9 03:53:20 2009
From: report at bugs.python.org (Douglas Shawhan)
Date: Mon, 09 Nov 2009 02:53:20 +0000
Subject: [issue7274] json module apparently fails regression found at
	http://json.org/JSON_checker/test.zip.
In-Reply-To: <1257547511.01.0.145507605323.issue7274@psf.upfronthosting.co.za>
Message-ID: <5e1ceb8a0911081852x5f47f5edm58855db2b39a2d02@mail.gmail.com>


Douglas Shawhan <doug.shawhan at gmail.com> added the comment:

Fair enough. Thanks.

On Fri, Nov 6, 2009 at 5:45 PM, Bob Ippolito <report at bugs.python.org> wrote:

>
> Bob Ippolito <bob at redivi.com> added the comment:
>
> The json module departs slightly from the spec in that it will allow you
> to consume and produce documents that don't have an array or object
> envelope. This is a feature.
>
> The "Too deep" test case is just a silly thing that crockford's code
> does, there's a fixed limitation for how complex an object could be.
> That's not a regression failure and the spec doesn't say anything about
> a maximum nesting level.
>
> The json module includes all of these in its test suite, although it
> disagrees slightly with crockford on what should pass.
>
> http://svn.python.org/view/python/branches/release26-
> maint/Lib/json/tests/test_fail.py<http://svn.python.org/view/python/branches/release26-%0Amaint/Lib/json/tests/test_fail.py>
>
> SKIPS = {
>    1: "why not have a string payload?",
>    18: "spec doesn't specify any nesting limitations",
> }
>
> ----------
> resolution:  -> invalid
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7274>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file15293/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7274>
_______________________________________
-------------- next part --------------
Fair enough. Thanks.<br><br><div class="gmail_quote">On Fri, Nov 6, 2009 at 5:45 PM, Bob Ippolito <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>
Bob Ippolito &lt;<a href="mailto:bob at redivi.com">bob at redivi.com</a>&gt; added the comment:<br>
<br>
The json module departs slightly from the spec in that it will allow you<br>
to consume and produce documents that don&#39;t have an array or object<br>
envelope. This is a feature.<br>
<br>
The &quot;Too deep&quot; test case is just a silly thing that crockford&#39;s code<br>
does, there&#39;s a fixed limitation for how complex an object could be.<br>
That&#39;s not a regression failure and the spec doesn&#39;t say anything about<br>
a maximum nesting level.<br>
<br>
The json module includes all of these in its test suite, although it<br>
disagrees slightly with crockford on what should pass.<br>
<br>
<a href="http://svn.python.org/view/python/branches/release26-%0Amaint/Lib/json/tests/test_fail.py" target="_blank">http://svn.python.org/view/python/branches/release26-<br>
maint/Lib/json/tests/test_fail.py</a><br>
<br>
SKIPS = {<br>
 ?? ??1: &quot;why not have a string payload?&quot;,<br>
 ?? ??18: &quot;spec doesn&#39;t specify any nesting limitations&quot;,<br>
}<br>
<br>
----------<br>
resolution: ??-&gt; invalid<br>
status: open -&gt; closed<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue7274" target="_blank">http://bugs.python.org/issue7274</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Mon Nov  9 04:53:16 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 Nov 2009 03:53:16 +0000
Subject: [issue7290] Update 'how do I set a global variable' faq entry
In-Reply-To: <1257738795.91.0.826293712603.issue7290@psf.upfronthosting.co.za>
Message-ID: <1257738795.91.0.826293712603.issue7290@psf.upfronthosting.co.za>


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

Someone else closed issue 7276, but I was thinking of doing so but
wanted to include a pointer to the relevant documentation.  I'm not sure
where that documentation is, but I figured there ought to be a FAQ entry
for it.  And there is, sort of...the first two sections of the
programming faq's 'core language' section.  However, I think that the
way that most people run in to this problem is by getting the
'UnboundLocalError', and so I think the FAQ entry title should mention
that error.  I attach a proposed update to the first section of the core
language section of the programming FAQ.  I'm also going to attach a
copy of the complete entry since it is hard to read in the patch.

----------
assignee: georg.brandl
components: Documentation
files: UnboundLocalError-faq.patch
keywords: patch
messages: 95057
nosy: georg.brandl, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Update 'how do I set a global variable' faq entry
type: feature request
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15294/UnboundLocalError-faq.patch

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

From report at bugs.python.org  Mon Nov  9 04:53:51 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 Nov 2009 03:53:51 +0000
Subject: [issue7290] Update 'how do I set a global variable' faq entry
In-Reply-To: <1257738795.91.0.826293712603.issue7290@psf.upfronthosting.co.za>
Message-ID: <1257738831.15.0.434194143208.issue7290@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Added file: http://bugs.python.org/file15295/UnboundLocalError-faq.rst

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

From report at bugs.python.org  Mon Nov  9 05:38:18 2009
From: report at bugs.python.org (Tatsuhiro Tsujikawa)
Date: Mon, 09 Nov 2009 04:38:18 +0000
Subject: [issue7291] urllib2 cannot handle https with proxy requiring auth
In-Reply-To: <1257741498.16.0.683281197284.issue7291@psf.upfronthosting.co.za>
Message-ID: <1257741498.16.0.683281197284.issue7291@psf.upfronthosting.co.za>


New submission from Tatsuhiro Tsujikawa <tsujikawa at gp.hitachi.co.jp>:

urllib2 cannot handle https with proxy requiring authorization.

After https_proxy is set correctly,

Python 2.6.4 (r264:75706, Oct 29 2009, 15:38:25)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib2
>>> c=urllib2.urlopen("https://sourceforge.net")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/urllib2.py", line 124, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib/python2.6/urllib2.py", line 389, in open
    response = self._open(req, data)
  File "/usr/lib/python2.6/urllib2.py", line 407, in _open
    '_open', req)
  File "/usr/lib/python2.6/urllib2.py", line 367, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.6/urllib2.py", line 1154, in https_open
    return self.do_open(httplib.HTTPSConnection, req)
  File "/usr/lib/python2.6/urllib2.py", line 1121, in do_open
    raise URLError(err)
urllib2.URLError: <urlopen error Tunnel connection failed: 407 Proxy
Authentication Required>

This is because HTTPConnection::_tunnel() in httplib.py doesn't send
Proxy-Authorization header.

----------
components: Library (Lib)
messages: 95058
nosy: tsujikawa
severity: normal
status: open
title: urllib2 cannot handle https with proxy requiring auth
versions: Python 2.6

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

From report at bugs.python.org  Mon Nov  9 07:31:27 2009
From: report at bugs.python.org (Jonathan)
Date: Mon, 09 Nov 2009 06:31:27 +0000
Subject: [issue7292] Multiprocessing Joinable race condition?
In-Reply-To: <1257748286.94.0.346139031927.issue7292@psf.upfronthosting.co.za>
Message-ID: <1257748286.94.0.346139031927.issue7292@psf.upfronthosting.co.za>


New submission from Jonathan <jonathan at kc8onw.net>:

In multiprocessing.JoinableQueue when task_done is called
self._unfinished_tasks.acquire(False) is called non-blocking.  My
program reliably crashes with the "task_done() called too many times"
message.  If I change the .acquire() call to True (blocking) then my
program no longer crashes and I have not noticed any adverse effects.  I
don't know if this would be considered a race condition or something
else but it does lead to crashes even in correct use scenarios.

(Code snippet follows for context, line 292 is the critical one for me)

    def task_done(self):
        self._cond.acquire()
        try:
            if not self._unfinished_tasks.acquire(False):
                raise ValueError('task_done() called too many times')
            if self._unfinished_tasks._semlock._is_zero():

----------
components: None
messages: 95059
nosy: jonathan at kc8onw.net
severity: normal
status: open
title: Multiprocessing Joinable race condition?
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Nov  9 07:56:15 2009
From: report at bugs.python.org (Tatsuhiro Tsujikawa)
Date: Mon, 09 Nov 2009 06:56:15 +0000
Subject: [issue7291] urllib2 cannot handle https with proxy requiring auth
In-Reply-To: <1257741498.16.0.683281197284.issue7291@psf.upfronthosting.co.za>
Message-ID: <1257749775.14.0.0718616958135.issue7291@psf.upfronthosting.co.za>


Tatsuhiro Tsujikawa <tsujikawa at gp.hitachi.co.jp> added the comment:

I created a patch.
I added additional argument 'headers' to HTTPConnection::set_tunnel()
method,
which is a mapping of HTTP headers to sent with CONNECT method. Since
authorization
credential is already set to Request object, in
AbstractHTTPHandler::do_open(),
if "Proxy-Authorization" header is found, pass it to set_tunnel().

It works fine for me.

----------
keywords: +patch
Added file: http://bugs.python.org/file15296/https_proxy_auth.patch

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

From report at bugs.python.org  Mon Nov  9 08:00:00 2009
From: report at bugs.python.org (David Bolen)
Date: Mon, 09 Nov 2009 07:00:00 +0000
Subject: [issue7293] test_msvc9compiler test_reg_class failure on new Windows
	box
In-Reply-To: <1257750000.16.0.245083157049.issue7293@psf.upfronthosting.co.za>
Message-ID: <1257750000.16.0.245083157049.issue7293@psf.upfronthosting.co.za>


New submission from David Bolen <db3l.net at gmail.com>:

This is a pretty tiny bug..

The test_reg_class test in test_msvc9compiler.py assumes that there is a
Notepad registry key on Windows systems.  That appears to be false until
Notepad is run the very first time.  I ran into this setting up a build
slave VM, where I never had the need to run Notepad.

I guess it's pretty rare for Notepad not to be run eventually, but
clearly the comments in the test saying the key is always present is
inaccurate, and perhaps a different key should be chosen or at least
have the test not fail if the key is missing.

It also appears that Windows 7 doesn't have that key even after Notepad
is run.

----------
assignee: tarek
components: Distutils
messages: 95061
nosy: db3l, tarek
severity: normal
status: open
title: test_msvc9compiler test_reg_class failure on new Windows box

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

From report at bugs.python.org  Mon Nov  9 09:03:36 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 09 Nov 2009 08:03:36 +0000
Subject: [issue6508] expose setresuid
In-Reply-To: <1247869532.62.0.249757468331.issue6508@psf.upfronthosting.co.za>
Message-ID: <1257753816.96.0.911645253889.issue6508@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Attaching an updated patch that includes unittests.

I also changed the set functions to take input as long's instead of int's 
as that is more likely to fit within a uid_t and forced the return values 
on the get's to fit within a long and used Py_BuildValue() to handle 
memory errors and such that could happen while allocating the ints and 
tuple rather than PyTuple_Pack.

Remaining work: os module documentation.

----------
Added file: http://bugs.python.org/file15297/issue6508-gps01.diff

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

From report at bugs.python.org  Mon Nov  9 09:26:01 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 09 Nov 2009 08:26:01 +0000
Subject: [issue7293] test_msvc9compiler test_reg_class failure on new Windows
	box
In-Reply-To: <1257750000.16.0.245083157049.issue7293@psf.upfronthosting.co.za>
Message-ID: <1257755161.4.0.83502734205.issue7293@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As you now have access to freshly-installed systems: can you propose
such a key?

----------
nosy: +loewis

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

From report at bugs.python.org  Mon Nov  9 09:36:29 2009
From: report at bugs.python.org (David Bolen)
Date: Mon, 09 Nov 2009 08:36:29 +0000
Subject: [issue7293] test_msvc9compiler test_reg_class failure on new Windows
	box
In-Reply-To: <1257750000.16.0.245083157049.issue7293@psf.upfronthosting.co.za>
Message-ID: <1257755789.26.0.763889894056.issue7293@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

Well, I can at least start by comparing XP and Win7 immediately
post-installation.  Any suggestions on guidelines to what can be chosen?
 Does it have to be a DWORD, or a 0/1 value, or under HKCU for a
specific reason?

----------

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

From report at bugs.python.org  Mon Nov  9 11:43:36 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Nov 2009 10:43:36 +0000
Subject: [issue5792] Enable short float repr() on Solaris/x86
In-Reply-To: <1240144400.05.0.462557167881.issue5792@psf.upfronthosting.co.za>
Message-ID: <1257763416.64.0.119763491194.issue5792@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

There are some related comments in issue #7281.

----------

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

From report at bugs.python.org  Mon Nov  9 11:49:30 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Nov 2009 10:49:30 +0000
Subject: [issue7281] copysign() with NaN arguments on OpenSolaris
In-Reply-To: <1257626499.13.0.928047451376.issue7281@psf.upfronthosting.co.za>
Message-ID: <1257763770.26.0.0856855931161.issue7281@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Yes, I don't think Python 2.6 had a deliberate workaround.  I suspect
that it's just that one version of Python happened to use something like
0.0/0.0 to generate NaN, while another used some equivalent of
strtod("nan", ...).

I also remember noticing at some point that even on a single machine/OS,
the sign bit of 0.0/0.0 depends on which version of gcc and which
optimization flags are present.

So I think we're in agreement that there's no need to change anything
here;  I'll close this issue.

But:  I really *would* like to get the short float repr working with
suncc!  Issue #5792 is already open for this, so discussion should move
there.  (This is about much more than consistent nan signs: 
implementing short float repr gives a whole bunch of benefits: correctly
rounded float <-> string conversions (including all float formatting
operations), a correctly rounded 'round' function, a prettier float
repr, ...).

----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Mon Nov  9 12:31:38 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Nov 2009 11:31:38 +0000
Subject: [issue7281] copysign() with NaN arguments on OpenSolaris
In-Reply-To: <1257626499.13.0.928047451376.issue7281@psf.upfronthosting.co.za>
Message-ID: <1257766298.73.0.112313414909.issue7281@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Just to confirm the above:

In 2.6, PyFloat_FromString in Objects/floatobject.c ends up using the
system strtod to parse "nan" and "-nan" (except that if the system
strtod fails to recognise "nan" for some reason then it returns the
result of 0.0 * Infinity instead, and in that case disregards the sign).
 In 2.7 and 3.x, it ends up calling _Py_parse_inf_or_nan in
Python/pystrtod.c, and this returns 0.0 * Infinity for "nan" and -(0.0 *
Infinity) for "-nan".  And depending on compiler flags, 0.0 * Infinity
ends up being either +nan (this usually seems to happen when
optimization is on, so that the compiler itself evaluates 0.0 *
Infinity), or -nan (which happens when there's no optimization and the
FPU ends up doing the 0.0 * Infinity multiplication at runtime.) This
should explain the results you're seeing.

----------

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

From report at bugs.python.org  Mon Nov  9 12:32:12 2009
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 09 Nov 2009 11:32:12 +0000
Subject: [issue5792] Enable short float repr() on Solaris/x86
In-Reply-To: <1240144400.05.0.462557167881.issue5792@psf.upfronthosting.co.za>
Message-ID: <1257766332.56.0.243526083218.issue5792@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I can confirm that short float repr() is active and all float tests are
passed on this combination:

Ubuntu64bit -> KVM -> OpenSolaris32bit/Python3.2/gcc

----------
nosy: +skrah

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

From report at bugs.python.org  Mon Nov  9 12:34:05 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Nov 2009 11:34:05 +0000
Subject: [issue5792] Enable short float repr() on Solaris/x86
In-Reply-To: <1240144400.05.0.462557167881.issue5792@psf.upfronthosting.co.za>
Message-ID: <1257766445.46.0.017925263148.issue5792@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Stefan Krah mentions in the issue 7281 discussion that suncc supports
the C99 fenv functions.  I'm not sure how to use these to set the x87
precision, though.  (Setting the rounding mode is straightforward.)

----------

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

From report at bugs.python.org  Mon Nov  9 12:39:16 2009
From: report at bugs.python.org (Ole Laursen)
Date: Mon, 09 Nov 2009 11:39:16 +0000
Subject: [issue7276] UnboundLocalError scoping problem with nested functions
In-Reply-To: <1257535397.32.0.778843860173.issue7276@psf.upfronthosting.co.za>
Message-ID: <1257766756.09.0.564059508624.issue7276@psf.upfronthosting.co.za>


Ole Laursen <olau at iola.dk> added the comment:

OK, sorry, I was under the impression that the global binding was still 
available (I can't find anything to the contrary here 
http://docs.python.org/reference/simple_stmts.html#assignment-statements 
) but it's obviously using a static definition of scope.

The error message isn't super helpful, though. :) Would it make sense to 
add a "(non-local "tmp" is shadowed)"? I guess that's easy to detect?

----------

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

From report at bugs.python.org  Mon Nov  9 12:41:19 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Nov 2009 11:41:19 +0000
Subject: [issue5792] Enable short float repr() on Solaris/x86
In-Reply-To: <1240144400.05.0.462557167881.issue5792@psf.upfronthosting.co.za>
Message-ID: <1257766879.2.0.812846556103.issue5792@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I see two alternatives:

(1) Use fesetenv.  I don't know what the appropriate value to pass would
be though, or even whether solaris lets you use fesetenv to control the
x87 precision.  It seems that its primary purpose is to set flags and traps.

(2) Use inline assembly, assuming that suncc supports this.  This seems
simpler.  It's just a matter of figuring out the syntax that suncc
expects for asm, and making sure the code is properly tested.

----------

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

From report at bugs.python.org  Mon Nov  9 12:46:38 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Nov 2009 11:46:38 +0000
Subject: [issue5792] Enable short float repr() on Solaris/x86
In-Reply-To: <1240144400.05.0.462557167881.issue5792@psf.upfronthosting.co.za>
Message-ID: <1257767198.93.0.551124540908.issue5792@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Looking at:

http://docs.sun.com/app/docs/doc/816-5172/fesetenv-3m

it seems that fesetenv isn't what we want here.  It 'only installs the
state of the floating-point status flags represented through its argument'.

----------

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

From report at bugs.python.org  Mon Nov  9 12:53:01 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Nov 2009 11:53:01 +0000
Subject: [issue5792] Enable short float repr() on Solaris/x86
In-Reply-To: <1240144400.05.0.462557167881.issue5792@psf.upfronthosting.co.za>
Message-ID: <1257767581.45.0.581763822255.issue5792@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Stefan, is it possible that suncc already accepts the assembler syntax
used in Python/pymath.h (py3k or trunk) for the functions
_Py_get_387controlword and _Py_set_387controlword?

----------

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

From report at bugs.python.org  Mon Nov  9 12:59:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Nov 2009 11:59:18 +0000
Subject: [issue7282] RLocks leak references when used in raw threads
In-Reply-To: <1257638440.73.0.268077668125.issue7282@psf.upfronthosting.co.za>
Message-ID: <1257767958.59.0.0512339180279.issue7282@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

An updated patch with test.

----------
Added file: http://bugs.python.org/file15298/rlock_leak2.patch

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

From report at bugs.python.org  Mon Nov  9 13:17:17 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Nov 2009 12:17:17 +0000
Subject: [issue5792] Enable short float repr() on Solaris/x86
In-Reply-To: <1240144400.05.0.462557167881.issue5792@psf.upfronthosting.co.za>
Message-ID: <1257769037.14.0.866768324158.issue5792@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> mark.dickinson

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

From report at bugs.python.org  Mon Nov  9 13:38:10 2009
From: report at bugs.python.org (Zsolt Cserna)
Date: Mon, 09 Nov 2009 12:38:10 +0000
Subject: [issue7242] Forking in a thread raises RuntimeError
In-Reply-To: <1256900282.72.0.764098234436.issue7242@psf.upfronthosting.co.za>
Message-ID: <1257770290.85.0.466130935725.issue7242@psf.upfronthosting.co.za>


Zsolt Cserna <zsolt.cserna at morganstanley.com> added the comment:

Additional info:
I've tested it on solaris 10 / sparc 32-bit, and my test script runs
fine on that.
Based on my test it seems that this bug does not affect solaris 10.

----------

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

From report at bugs.python.org  Mon Nov  9 13:51:21 2009
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 09 Nov 2009 12:51:21 +0000
Subject: [issue5792] Enable short float repr() on Solaris/x86
In-Reply-To: <1240144400.05.0.462557167881.issue5792@psf.upfronthosting.co.za>
Message-ID: <1257771081.11.0.825775797784.issue5792@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The inline asm compiles, but I don't know how good the GNU inline asm
support is with suncc in general. I'm not a heavy user of suncc, I just
use it for testing.

That said, perhaps fesetprec works, too:

http://docs.sun.com/app/docs/doc/816-5172/fesetprec-3m

----------

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

From report at bugs.python.org  Mon Nov  9 14:33:56 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Nov 2009 13:33:56 +0000
Subject: [issue5792] Enable short float repr() on Solaris/x86
In-Reply-To: <1240144400.05.0.462557167881.issue5792@psf.upfronthosting.co.za>
Message-ID: <1257773636.83.0.495216329193.issue5792@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Excellent!  From a bit of searching, it looks as though this assembler
syntax works on icc as well, which is very good news.

Thanks for finding fesetprec as well.  It's a shame this isn't standard
C.  Oh well;  maybe for C201X.  I think I'd prefer to stick with the
inline assembly, since it seems that there's very little to do to make
this just work.

Next problem:  when compiling with suncc, how do I detect (in the
configure script)

(1) that I'm using suncc, and
(2) whether the hardware is x86 or not (preferably excluding the case of
x86-64).

For gcc, configure.in is using:

if test -n "`$CC -dM -E - </dev/null | grep i386`"

to detect whether we're on x86.  I guess it's too much to hope for that
this works for suncc as well.

----------

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

From report at bugs.python.org  Mon Nov  9 15:02:50 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Nov 2009 14:02:50 +0000
Subject: [issue5792] Enable short float repr() on Solaris/x86
In-Reply-To: <1240144400.05.0.462557167881.issue5792@psf.upfronthosting.co.za>
Message-ID: <1257775370.99.0.148242626445.issue5792@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

fesetprec and fegetprec are at least semi-standard, it seems.  They're
recommended in the C99 rationale (see page 121 of

http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf

).

----------

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

From report at bugs.python.org  Mon Nov  9 15:27:59 2009
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 09 Nov 2009 14:27:59 +0000
Subject: [issue5792] Enable short float repr() on Solaris/x86
In-Reply-To: <1240144400.05.0.462557167881.issue5792@psf.upfronthosting.co.za>
Message-ID: <1257776879.59.0.343957851116.issue5792@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

If gcc and suncc are present, ./configure chooses gcc and everything is
fine.

If only suncc is present, it's detected as cc. These tests should be
possible:

stefan at opensolaris:~/svn/py3k$ cc -V
cc: Sun C 5.9 SunOS_i386 Patch 124868-07 2008/10/07
usage: cc [ options] files.  Use 'cc -flags' for details
stefan at opensolaris:~/svn/py3k$ if cc -V 2>&1 | grep -q 'SunOS_i386';
then echo yes; fi
yes
stefan at opensolaris:~/svn/py3k$ uname -a
SunOS opensolaris 5.11 snv_101b i86pc i386 i86pc Solaris
stefan at opensolaris:~/svn/py3k$ if uname -a | grep -q i386; then echo yes; fi
yes

----------

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

From report at bugs.python.org  Mon Nov  9 15:33:45 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Nov 2009 14:33:45 +0000
Subject: [issue5792] Enable short float repr() on Solaris/x86
In-Reply-To: <1240144400.05.0.462557167881.issue5792@psf.upfronthosting.co.za>
Message-ID: <1257777225.79.0.0532629370574.issue5792@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks.  uname looks like the way to go, then.

Is your copy of OpenSolaris running in 32-bit mode or 64-bit mode?  Does
the mode make a difference to the output of uname, or is uname -p always
i386, regardless of the mode?

I think the configure test for the inline assembly should go ahead on
both x86 and x86-64:  it seems likely that a 64-bit OS would be using
SSE2 instructions for floating-point (which would make setting and
getting the x87 control word unnecessary) instead of the x87 FPU, but I
don't know that for sure.

Actually, I guess I could just make that configure test unconditional.
It'll fail on non-x86 hardware, but that's no big deal.

----------

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

From report at bugs.python.org  Mon Nov  9 15:34:23 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 09 Nov 2009 14:34:23 +0000
Subject: [issue7294] MSDN URL in subprocess.py is incorrect
In-Reply-To: <1257777263.24.0.231988954498.issue7294@psf.upfronthosting.co.za>
Message-ID: <1257777263.24.0.231988954498.issue7294@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

subprocess.py includes this comment, in list2cmdline():

    # See
    # http://msdn.microsoft.com/library/en-us/vccelng/htm/progs_12.asp

MSDN gets reorganized with surprising regularity, and this URL is no
longer valid. I think the current URL is:
http://msdn.microsoft.com/en-us/library/17w5ykft.aspx
The best way to find this is to go to:
http://msdn.microsoft.com
and search on "Parsing C++ Command-Line Arguments".

----------
components: Library (Lib)
keywords: easy
messages: 95081
nosy: eric.smith
severity: normal
status: open
title: MSDN URL in subprocess.py is incorrect
versions: Python 2.7

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

From report at bugs.python.org  Mon Nov  9 15:44:57 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 09 Nov 2009 14:44:57 +0000
Subject: [issue7294] MSDN URL in subprocess.py is incorrect
In-Reply-To: <1257777263.24.0.231988954498.issue7294@psf.upfronthosting.co.za>
Message-ID: <1257777897.4.0.446238273236.issue7294@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
versions: +Python 3.2

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

From report at bugs.python.org  Mon Nov  9 15:45:31 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Nov 2009 14:45:31 +0000
Subject: [issue5792] Enable short float repr() on Solaris/x86
In-Reply-To: <1240144400.05.0.462557167881.issue5792@psf.upfronthosting.co.za>
Message-ID: <1257777931.63.0.843004736416.issue5792@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Stefan, please could you test the attached patch (against py3k) with
suncc?  With this patch, sys.float_repr_style should report 'short', and
'make test' should not produce any obviously float-related failures.

----------
keywords: +patch
Added file: http://bugs.python.org/file15299/sun_short_float_repr.patch

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

From report at bugs.python.org  Mon Nov  9 15:55:01 2009
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 09 Nov 2009 14:55:01 +0000
Subject: [issue5792] Enable short float repr() on Solaris/x86
In-Reply-To: <1240144400.05.0.462557167881.issue5792@psf.upfronthosting.co.za>
Message-ID: <1257778501.83.0.403730327505.issue5792@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

My copy is 32-bit. I never installed a 64-bit version, but I strongly
assume that uname -p gives x86_64. BTW, uname -p works on Solaris, but
returns 'unknown' on my 64 bit Linux.

----------

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

From report at bugs.python.org  Mon Nov  9 16:06:03 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 09 Nov 2009 15:06:03 +0000
Subject: [issue7294] MSDN URL in subprocess.py is incorrect
In-Reply-To: <1257777263.24.0.231988954498.issue7294@psf.upfronthosting.co.za>
Message-ID: <1257779163.2.0.428438305104.issue7294@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
assignee:  -> eric.smith
versions: +Python 2.6, Python 3.1

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

From report at bugs.python.org  Mon Nov  9 16:25:25 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 09 Nov 2009 15:25:25 +0000
Subject: [issue7294] MSDN URL in subprocess.py is incorrect
In-Reply-To: <1257777263.24.0.231988954498.issue7294@psf.upfronthosting.co.za>
Message-ID: <1257780325.3.0.674699869165.issue7294@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Fixed in:

trunk: r76168
release26-maint: r76169
py3k: r76170
release31-maint: r76171

----------
priority:  -> low
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Nov  9 16:36:52 2009
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 09 Nov 2009 15:36:52 +0000
Subject: [issue5792] Enable short float repr() on Solaris/x86
In-Reply-To: <1240144400.05.0.462557167881.issue5792@psf.upfronthosting.co.za>
Message-ID: <1257781011.98.0.881704432635.issue5792@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Tested the patch against an updated 3.2. repr-style is 'short', and I
did not see obvious float errors. In particular, test_float.py is
passed. I also did not see new compile warnings.

As for the other tests, the errors I get seem to be the same with or
without the patch. Any other tests I should watch out for apart from
test_float.py?

----------

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

From report at bugs.python.org  Mon Nov  9 17:25:21 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Nov 2009 16:25:21 +0000
Subject: [issue7295] test_tarfile uses a hardcoded file name
In-Reply-To: <1257783921.08.0.721111694133.issue7295@psf.upfronthosting.co.za>
Message-ID: <1257783921.08.0.721111694133.issue7295@psf.upfronthosting.co.za>


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

I got this error on my buildbot:

test test_tarfile crashed -- <class 'IOError'>: [Errno 13] Permission
denied: '/tmp/test_tarfile_tmp/testtar.tar.gz'

test_tarfile should not use a hardcoded file name but rely on TESTFN
instead (or any of tempfile.mk*), so that concurrent test runs don't fail.

----------
assignee: lars.gustaebel
components: Library (Lib), Tests
messages: 95086
nosy: lars.gustaebel, pitrou
priority: low
severity: normal
stage: needs patch
status: open
title: test_tarfile uses a hardcoded file name
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Nov  9 17:32:12 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Nov 2009 16:32:12 +0000
Subject: [issue5792] Enable short float repr() on Solaris/x86
In-Reply-To: <1240144400.05.0.462557167881.issue5792@psf.upfronthosting.co.za>
Message-ID: <1257784332.77.0.120676564704.issue5792@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Many thanks for testing this, Stefan!  I'll tidy up the patch a little bit 
and add a Misc/NEWS entry, then commit this.

----------

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

From report at bugs.python.org  Mon Nov  9 17:37:19 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Nov 2009 16:37:19 +0000
Subject: [issue5792] Enable short float repr() on Solaris/x86
In-Reply-To: <1240144400.05.0.462557167881.issue5792@psf.upfronthosting.co.za>
Message-ID: <1257784639.41.0.34562372554.issue5792@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> As for the other tests, the errors I get seem to be the same with or
> without the patch. Any other tests I should watch out for apart from
> test_float.py?

Well *ideally* you shouldn't be getting any test failures :-).  But I 
could imagine than running Solaris within a VM might cause some 
problems.  Which tests are failing?

Tests I'd be worried about for the float repr change include: 
test_float, test_complex, test_math, test_cmath, test_ast, test_format, 
test_marshal, test_pickle, test_json, test_builtin, test_capi.

----------

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

From report at bugs.python.org  Mon Nov  9 17:54:50 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Nov 2009 16:54:50 +0000
Subject: [issue7282] RLocks leak references when used in raw threads
In-Reply-To: <1257638440.73.0.268077668125.issue7282@psf.upfronthosting.co.za>
Message-ID: <1257785690.08.0.165602697221.issue7282@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r76172-r76175.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Nov  9 18:19:12 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Nov 2009 17:19:12 +0000
Subject: [issue7251] Mark expected failures of test_math,
	test_cmath and test_round as such.
In-Reply-To: <1257154985.1.0.42933155819.issue7251@psf.upfronthosting.co.za>
Message-ID: <1257787152.77.0.241887302281.issue7251@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The round tests for large values have been broken out into their own test;  
this test is now skipped (only if it would fail) on Linux/alpha.  See 
r76176 (trunk), r76177 (py3k) and r76178 (release31-maint).

The round function itself needs fixing in release26-maint:  issue #7070.

----------

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

From report at bugs.python.org  Mon Nov  9 18:46:06 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Nov 2009 17:46:06 +0000
Subject: [issue7070] round(x) gives wrong result for large odd integers
In-Reply-To: <1254818325.66.0.811291436482.issue7070@psf.upfronthosting.co.za>
Message-ID: <1257788766.26.0.928031738024.issue7070@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed in r76179.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Mon Nov  9 18:49:56 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Nov 2009 17:49:56 +0000
Subject: [issue7251] Mark expected failures of test_math,
	test_cmath and test_round as such.
In-Reply-To: <1257154985.1.0.42933155819.issue7251@psf.upfronthosting.co.za>
Message-ID: <1257788996.73.0.655636946341.issue7251@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The round function in release26-maint is fixed (r76179).  I'm not sure 
whether the round_large test needs to be skipped for release26-maint, 
since the Python  2.6 version of round doesn't use the libm round 
function.

----------

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

From report at bugs.python.org  Mon Nov  9 18:54:03 2009
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 09 Nov 2009 17:54:03 +0000
Subject: [issue5792] Enable short float repr() on Solaris/x86
In-Reply-To: <1240144400.05.0.462557167881.issue5792@psf.upfronthosting.co.za>
Message-ID: <1257789243.76.0.112762058609.issue5792@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The tests that you mention run o.k., except capi, but that looks harmless:

stefan at opensolaris:~/svn/py3k/Lib/test# ../../python test_capi.py
test_instancemethod (__main__.CAPITest) ... ok

----------------------------------------------------------------------
Ran 1 test in 0.000s

OK
internal test_L_code
internal test_Z_code
internal test_capsule
internalTraceback (most recent call last):
  File "test_capi.py", line 170, in <module>
    test_main()
  File "test_capi.py", line 130, in test_main
    print("internal", name)
ImportError: No module named _curses



Tests that fail:

test_ascii_formatd, test_calendar, test_datetime, test_distutils,
test_email, test_httpservers, test_mailbox, test_multiprocessing,
test_os, test_pipes, test_platform, test_poll, test_popen, test_pty,
test_pydoc, test_quopri, test_select, test_signal, test_strftime,
test_strptime, test_subprocess, test_sys, test_tempfile, test_threading


A lot of these fail either due to the inability to allocate resources or
the fact that strftime appears to give weird results.

----------

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

From report at bugs.python.org  Mon Nov  9 19:28:32 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Nov 2009 18:28:32 +0000
Subject: [issue5792] Enable short float repr() on Solaris/x86
In-Reply-To: <1240144400.05.0.462557167881.issue5792@psf.upfronthosting.co.za>
Message-ID: <1257791312.37.0.561012441152.issue5792@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Is the test_ascii_formatd failure due to a failed 'from ctypes import 
...'?  That's the only failure that looks like it could be related.

Thanks for this.

----------

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

From report at bugs.python.org  Mon Nov  9 19:51:34 2009
From: report at bugs.python.org (Adam Olsen)
Date: Mon, 09 Nov 2009 18:51:34 +0000
Subject: [issue3999] Real segmentation fault handler
In-Reply-To: <1222737012.4.0.203589723568.issue3999@psf.upfronthosting.co.za>
Message-ID: <1257792694.15.0.638669515682.issue3999@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

That's fine, but please provide a link to the new issue once you create it.

----------

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

From report at bugs.python.org  Mon Nov  9 20:15:30 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 Nov 2009 19:15:30 +0000
Subject: [issue7276] UnboundLocalError scoping problem with nested functions
In-Reply-To: <1257535397.32.0.778843860173.issue7276@psf.upfronthosting.co.za>
Message-ID: <1257794130.35.0.726258047068.issue7276@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The relevant section is
http://docs.python.org/reference/executionmodel.html#naming-and-binding.
 Perhaps a cross-reference should be added to the assignment section. 
If you think it should, please open a new issue for that.

I have opened issue 7290 with a suggested improvement to the FAQ entry
that most closely deals with this.  Could you review that and let me
know in that issue if you think it is a worthwhile improvement?

----------
nosy: +r.david.murray
priority:  -> low
stage:  -> committed/rejected
type: compile error -> behavior

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

From report at bugs.python.org  Mon Nov  9 22:09:22 2009
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 09 Nov 2009 21:09:22 +0000
Subject: [issue5792] Enable short float repr() on Solaris/x86
In-Reply-To: <1240144400.05.0.462557167881.issue5792@psf.upfronthosting.co.za>
Message-ID: <1257800962.01.0.10016972913.issue5792@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Yes, test_ascii_formatd fails with 'ImportError: No module named _ctypes'.

----------

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

From report at bugs.python.org  Mon Nov  9 22:53:16 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 09 Nov 2009 21:53:16 +0000
Subject: [issue1752919] Exception in HTMLParser for special JavaScript code
Message-ID: <1257803596.26.0.164204468786.issue1752919@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Tue Nov 10 00:02:14 2009
From: report at bugs.python.org (jasper)
Date: Mon, 09 Nov 2009 23:02:14 +0000
Subject: [issue7296] OverflowError: signed integer is greater than maximum on
	mips64
In-Reply-To: <1257807734.54.0.518943570242.issue7296@psf.upfronthosting.co.za>
Message-ID: <1257807734.54.0.518943570242.issue7296@psf.upfronthosting.co.za>


New submission from jasper <jasper at humppa.nl>:

While trying to get Python 2.6 working on OpenBSD/sgi (64-bit port)
I ran into the following during build:

OverflowError: signed integer is greater than maximum

I ran the command that triggered this by hand with -v added:

(sgi Python-2.6.3 40)$ export PATH; PATH="`pwd`:$PATH";  export
PYTHONPATH; PYTHONPATH="`pwd`/Lib";  export DYLD_FRAMEWORK_PATH;
DYLD_FRAMEWORK_PATH="`pwd`";  export EXE; EXE="";  cd
./Lib/plat-openbsd4;  ./regen
python$EXE -v ../../Tools/scripts/h2py.py -i '(u_long)'
/usr/include/netinet/in.h
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
# /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/site.pyc matches
/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/site.py
import site # precompiled from
/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/site.pyc
'import site' failed; traceback:
Traceback (most recent call last):
  File "/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/site.py", line 61,
in <module>
    import sys
OverflowError: signed integer is greater than maximum
import encodings # directory
/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/encodings
# /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/encodings/__init__.pyc
matches /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/encodings/__init__.py
import encodings # precompiled from
/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/encodings/__init__.pyc
Python 2.6.3 (r263:75183, Nov  6 2009, 09:50:33) 
[GCC 3.3.5 (propolice)] on openbsd4
Type "help", "copyright", "credits" or "license" for more information.
# /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/re.pyc matches
/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/re.py
import re # precompiled from
/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/re.pyc
Traceback (most recent call last):
  File "../../Tools/scripts/h2py.py", line 24, in <module>
    import sys, re, getopt, os
  File "/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/re.py", line 104,
in <module>
    import sys
OverflowError: signed integer is greater than maximum
# clear __builtin__._
# clear sys.path
# clear sys.argv
# clear sys.ps1
# clear sys.ps2
# clear sys.exitfunc
# clear sys.exc_type
# clear sys.exc_value
# clear sys.exc_traceback
# clear sys.last_type
# clear sys.last_value
# clear sys.last_traceback
# clear sys.path_hooks
# clear sys.path_importer_cache
# clear sys.meta_path
# clear sys.flags
# clear sys.float_info
# restore sys.stdin
# restore sys.stdout
# restore sys.stderr
# cleanup __main__
# cleanup[1] zipimport
# cleanup[1] signal
# cleanup[1] exceptions
# cleanup[1] _warnings
# cleanup sys
# cleanup __builtin__
# cleanup ints: 3 unfreed ints
# cleanup floats
(sgi plat-openbsd4 41)$

There have been several patches applied:
http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/python/2.6/patches/
Although none seem to be relevant as far as I can see.

Please find attached the build log and the configure log.

----------
components: Build
files: config.log
messages: 95098
nosy: jasper
severity: normal
status: open
title: OverflowError: signed integer is greater than maximum on mips64
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file15300/config.log

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

From report at bugs.python.org  Tue Nov 10 00:03:10 2009
From: report at bugs.python.org (jasper)
Date: Mon, 09 Nov 2009 23:03:10 +0000
Subject: [issue7296] OverflowError: signed integer is greater than maximum on
	mips64
In-Reply-To: <1257807734.54.0.518943570242.issue7296@psf.upfronthosting.co.za>
Message-ID: <1257807790.63.0.243524629061.issue7296@psf.upfronthosting.co.za>


jasper <jasper at humppa.nl> added the comment:

And the build log on OpenBSD/sgi.

----------
Added file: http://bugs.python.org/file15301/Python-2.6.3.log

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

From report at bugs.python.org  Tue Nov 10 03:19:40 2009
From: report at bugs.python.org (Pablo Mouzo)
Date: Tue, 10 Nov 2009 02:19:40 +0000
Subject: [issue6845] Restart support in binary upload for ftplib
In-Reply-To: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>
Message-ID: <1257819580.67.0.115421781068.issue6845@psf.upfronthosting.co.za>


Pablo Mouzo <pablomouzo at gmail.com> added the comment:

Here is a new patch. It works with both ints and strings.

I'm working on a patch for py3k.

----------
Added file: http://bugs.python.org/file15302/issue6845-trunk.diff

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

From report at bugs.python.org  Tue Nov 10 03:19:56 2009
From: report at bugs.python.org (Pablo Mouzo)
Date: Tue, 10 Nov 2009 02:19:56 +0000
Subject: [issue6845] Restart support in binary upload for ftplib
In-Reply-To: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>
Message-ID: <1257819596.93.0.560650319203.issue6845@psf.upfronthosting.co.za>


Changes by Pablo Mouzo <pablomouzo at gmail.com>:


Removed file: http://bugs.python.org/file15027/issue6845.diff

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

From report at bugs.python.org  Tue Nov 10 03:38:52 2009
From: report at bugs.python.org (Brandon Dixon)
Date: Tue, 10 Nov 2009 02:38:52 +0000
Subject: [issue7297] Releasing FamousFoodFinder.com
In-Reply-To: <22e7e1600911091838j58d0a41n27678b169aa7b72c@mail.gmail.com>
Message-ID: <22e7e1600911091838j58d0a41n27678b169aa7b72c@mail.gmail.com>

<span style="font-family:&#39;Times New Roman&#39;;font-size:medium"><div style="background-repeat:initial;background-color:rgb(255, 255, 255);padding-top:0.6em;padding-right:0.6em;padding-bottom:0.6em;padding-left:0.6em;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px">


<span class="Apple-style-span" style="font-family: monospace; font-size: 13px; white-space: pre-wrap; ">For the past 2 months a friend and I have been working on a site (<a href="http://www.famousfoodfinder.com">www.famousfoodfinder.com</a>) that would allow users to search for famous restaurants. The idea initially came from the fact that I love food and have been considering traveling around the US for quite some time. I couldn&#39;t think of a better way to enjoy good food and travel than to hit up all the places that I saw on all my favorite shows.

Searching online didn&#39;t reveal any site that contained multiple shows and allowed me to filter my searches. Rather then wait for someone to add the shows I wanted or the searching capabilities I felt were necessary, I decided to create my own. 

The site currently supports 5 popular shows:<br><ul><li>&quot;Diners, Drive-Ins and Dives&quot;</li><li>&quot;Feasting on Asphalt 1&quot;</li><li>&quot;Feasting on Asphalt 2&quot;</li><li>&quot;The Best Thing I Ever Ate&quot;&quot;Throwdown with Bobby Flay&quot;</li>

</ul></span></div><div style="background-repeat:initial;background-color:rgb(255, 255, 255);padding-top:0.6em;padding-right:0.6em;padding-bottom:0.6em;padding-left:0.6em;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px">

<span class="Apple-style-span" style="font-family: monospace; font-size: 13px; white-space: pre-wrap; ">We are currently working on adding more details to each show as well as a few other shows that feature more restaurants. The site is still in beta, but we wanted to release it in it&#39;s current state so that users could suggest ideas on how to improve the design/functionality. We hope you find it as useful as we do.<br>

</span></div><div style="background-repeat:initial;background-color:rgb(255, 255, 255);padding-top:0.6em;padding-right:0.6em;padding-bottom:0.6em;padding-left:0.6em;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px">

<font class="Apple-style-span" face="monospace" size="3"><span class="Apple-style-span" style="font-size: 13px; white-space: pre-wrap;">Please send any feedback, comments, or requests to: <a href="mailto:brandon at famousfoodfinder.com">brandon at famousfoodfinder.com</a>.</span></font></div>

</span><br>-- <br>Brandon Dixon - CCNA, OSCP, WebSphere DataPower Solution Developer<br>Information Systems Security Engineer<br><a href="http://www.dueyesterday.net" target="_blank">www.dueyesterday.net</a> - Documentation for the masses<br>


<a href="http://www.famousfoodfinder.com" target="_blank">www.famousfoodfinder.com</a> - Search for famous restaurants around you!<br>
-------------- next part --------------
<span style="font-family:&#39;Times New Roman&#39;;font-size:medium"><div style="background-repeat:initial;background-color:rgb(255, 255, 255);padding-top:0.6em;padding-right:0.6em;padding-bottom:0.6em;padding-left:0.6em;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px">


<span class="Apple-style-span" style="font-family: monospace; font-size: 13px; white-space: pre-wrap; ">For the past 2 months a friend and I have been working on a site (<a href="http://www.famousfoodfinder.com">www.famousfoodfinder.com</a>) that would allow users to search for famous restaurants. The idea initially came from the fact that I love food and have been considering traveling around the US for quite some time. I couldn&#39;t think of a better way to enjoy good food and travel than to hit up all the places that I saw on all my favorite shows.

Searching online didn&#39;t reveal any site that contained multiple shows and allowed me to filter my searches. Rather then wait for someone to add the shows I wanted or the searching capabilities I felt were necessary, I decided to create my own. 

The site currently supports 5 popular shows:<br><ul><li>&quot;Diners, Drive-Ins and Dives&quot;</li><li>&quot;Feasting on Asphalt 1&quot;</li><li>&quot;Feasting on Asphalt 2&quot;</li><li>&quot;The Best Thing I Ever Ate&quot;&quot;Throwdown with Bobby Flay&quot;</li>

</ul></span></div><div style="background-repeat:initial;background-color:rgb(255, 255, 255);padding-top:0.6em;padding-right:0.6em;padding-bottom:0.6em;padding-left:0.6em;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px">

<span class="Apple-style-span" style="font-family: monospace; font-size: 13px; white-space: pre-wrap; ">We are currently working on adding more details to each show as well as a few other shows that feature more restaurants. The site is still in beta, but we wanted to release it in it&#39;s current state so that users could suggest ideas on how to improve the design/functionality. We hope you find it as useful as we do.<br>

</span></div><div style="background-repeat:initial;background-color:rgb(255, 255, 255);padding-top:0.6em;padding-right:0.6em;padding-bottom:0.6em;padding-left:0.6em;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px">

<font class="Apple-style-span" face="monospace" size="3"><span class="Apple-style-span" style="font-size: 13px; white-space: pre-wrap;">Please send any feedback, comments, or requests to: <a href="mailto:brandon at famousfoodfinder.com">brandon at famousfoodfinder.com</a>.</span></font></div>

</span><br>-- <br>Brandon Dixon - CCNA, OSCP, WebSphere DataPower Solution Developer<br>Information Systems Security Engineer<br><a href="http://www.dueyesterday.net" target="_blank">www.dueyesterday.net</a> - Documentation for the masses<br>


<a href="http://www.famousfoodfinder.com" target="_blank">www.famousfoodfinder.com</a> - Search for famous restaurants around you!<br>

From report at bugs.python.org  Tue Nov 10 03:50:51 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 10 Nov 2009 02:50:51 +0000
Subject: [issue7297] Releasing FamousFoodFinder.com
In-Reply-To: <22e7e1600911091838j58d0a41n27678b169aa7b72c@mail.gmail.com>
Message-ID: <1257821451.2.0.893108798081.issue7297@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Tue Nov 10 08:17:40 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 10 Nov 2009 07:17:40 +0000
Subject: [issue7297] Releasing FamousFoodFinder.com
In-Reply-To: <22e7e1600911091838j58d0a41n27678b169aa7b72c@mail.gmail.com>
Message-ID: <1257837460.33.0.472101347971.issue7297@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Removed file: http://bugs.python.org/file15303/unnamed

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

From report at bugs.python.org  Tue Nov 10 08:17:46 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 10 Nov 2009 07:17:46 +0000
Subject: [issue7297] Releasing FamousFoodFinder.com
Message-ID: <1257837466.29.0.657560234918.issue7297@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------

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

From report at bugs.python.org  Tue Nov 10 08:18:15 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 10 Nov 2009 07:18:15 +0000
Subject: [issue7297] --spam--
Message-ID: <1257837495.5.0.341825951189.issue7297@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
title: Releasing FamousFoodFinder.com -> --spam--

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

From report at bugs.python.org  Tue Nov 10 10:57:56 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Tue, 10 Nov 2009 09:57:56 +0000
Subject: [issue7295] test_tarfile uses a hardcoded file name
In-Reply-To: <1257783921.08.0.721111694133.issue7295@psf.upfronthosting.co.za>
Message-ID: <1257847076.11.0.916016332202.issue7295@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

I attached a patch that uses TESTFN. Please verify that it works and
then one of us checks it in.

----------
keywords: +patch
Added file: http://bugs.python.org/file15304/issue7295.diff

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

From report at bugs.python.org  Tue Nov 10 11:02:20 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 10 Nov 2009 10:02:20 +0000
Subject: [issue7296] OverflowError: signed integer is greater than maximum on
	mips64
In-Reply-To: <1257807734.54.0.518943570242.issue7296@psf.upfronthosting.co.za>
Message-ID: <1257847340.85.0.990477725095.issue7296@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for filing the report!  Some questions:

If you configure with the --with-pydebug option, and also do whatever
else (if anything) is necessary to remove the -O2 flag from the
compilation steps, does the build failure still occur?

What's the minimal Python code required to cause the failure.  Is it
enough to launch the interpreter and then just do 'import sys'?

Judging by the error message, it looks as though the OverflowError is
being set in the 'convertsimple' function in Python/getargs.c:  the
relevant code looks something like:

	case 'i': {/* signed int */
		int *p = va_arg(*p_va, int *);
		long ival;
		if (float_argument_error(arg))
			return converterr("integer<i>", arg, msgbuf, bufsize);
		ival = PyInt_AsLong(arg);
		if (ival == -1 && PyErr_Occurred())
			return converterr("integer<i>", arg, msgbuf, bufsize);
		else if (ival > INT_MAX) {
			PyErr_SetString(PyExc_OverflowError,
				"signed integer is greater than maximum");
			return converterr("integer<i>", arg, msgbuf, bufsize);
		}


But this code is part of Python's general argument parsing mechanism, so
is called from many many places; we really need some way of figuring out
where it's getting called from when the build fails.  Still with a
--with-pydebug build, could you try using gdb (or an equivalent) to set
a breakpoint on the PyErr_SetString line in the (ival > INT_MAX) branch,
then do whatever is required to trigger the failure and report the
backtrace at that breakpoint?

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Tue Nov 10 11:27:38 2009
From: report at bugs.python.org (ledave123)
Date: Tue, 10 Nov 2009 10:27:38 +0000
Subject: [issue7298] reversed(range(x, -1, -1)) is empty when x > 1
In-Reply-To: <1257848858.69.0.270094372501.issue7298@psf.upfronthosting.co.za>
Message-ID: <1257848858.69.0.270094372501.issue7298@psf.upfronthosting.co.za>


New submission from ledave123 <ledave123 at yahoo.fr>:

On python 2.4.4, reversed(range()) is correct :
>>> list(reversed(range(12,-1,-1)))
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]

However, on python 3.1.1 :
>>> list(reversed(range(12,-1,-1)))
[]
which is obviously wrong.

When step is positive, the result is okay on python 3.1.1 :
>>> list(reversed(range(13)))
[12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0]

----------
components: Interpreter Core
messages: 95104
nosy: ledave123
severity: normal
status: open
title: reversed(range(x, -1, -1)) is empty when x > 1
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Tue Nov 10 12:25:14 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 10 Nov 2009 11:25:14 +0000
Subject: [issue7298] reversed(range(x, -1, -1)) is empty when x > 1
In-Reply-To: <1257848858.69.0.270094372501.issue7298@psf.upfronthosting.co.za>
Message-ID: <1257852314.86.0.970390738061.issue7298@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Nice catch!  Thanks for reporting this.

get_len_of_range in Objects/rangeobject.c only works for positive steps,
but is being called with a negative step here.

I think get_len_of_range should be changed to work with both positive
and negative steps.  It's only called from one other place, and that
place also has to deal with negative steps.  (And I'm not convinced that
this place is dealing with negative steps correctly either:  it uses
simply -step to negate the step, which can overflow if step == LONG_MIN.)

I'll put a patch together.

----------
assignee:  -> mark.dickinson
keywords: +easy
nosy: +mark.dickinson
priority:  -> critical
versions: +Python 3.2

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

From report at bugs.python.org  Tue Nov 10 12:28:48 2009
From: report at bugs.python.org (Ole Laursen)
Date: Tue, 10 Nov 2009 11:28:48 +0000
Subject: [issue7290] Update 'how do I set a global variable' faq entry
In-Reply-To: <1257738795.91.0.826293712603.issue7290@psf.upfronthosting.co.za>
Message-ID: <1257852528.95.0.935494760136.issue7290@psf.upfronthosting.co.za>


Ole Laursen <olau at iola.dk> added the comment:

As the reporter of issue 7276, I think it's a clear explanation of this 
phenomonen. I think that maybe you should remove the "New Python 
programmers" in

"New Python programmers are often surprised when they get this error in 
previously working code when they modify it by adding an assignment 
statement somewhere in the body of a function."

so say something like

"It can be a surprise to get this error in previously working code when it 
is modified by adding an assignment statement somewhere in a function 
body."

----------
nosy: +olau

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

From report at bugs.python.org  Tue Nov 10 13:17:02 2009
From: report at bugs.python.org (Francesco Frassinelli)
Date: Tue, 10 Nov 2009 12:17:02 +0000
Subject: [issue755660] allow HTMLParser to continue after a parse error
Message-ID: <1257855422.32.0.966082951897.issue755660@psf.upfronthosting.co.za>


Francesco Frassinelli <fraph24 at gmail.com> added the comment:

I'm using Python 3.1.1 and the patch (patch.txt, provided by smroid)
works very well. It's usefull, and I really need it, thanks :)
Without this patch, I can't parse: http://ftp.vim.org/pub/vim/ (due to a
fake tag, like "<user at mail.com>"), and many others websites.

I hope this patch will be merged in Python 3.2 :)

----------
nosy: +frafra

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

From report at bugs.python.org  Tue Nov 10 13:32:59 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 10 Nov 2009 12:32:59 +0000
Subject: [issue7298] reversed(range(x, -1, -1)) is empty when x > 1
In-Reply-To: <1257848858.69.0.270094372501.issue7298@psf.upfronthosting.co.za>
Message-ID: <1257856379.57.0.0448272199872.issue7298@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

There's another problem with range_reverse:  it uses a short range (all
fields longs) if start, stop and step fit into a C long.  But it doesn't
check whether the length fits into a C long.  This leads to the following:

>>> list(reversed(range(-1, 2**63-1)))
[]

(this is on a 64-bit machine;  for a 32-bit machine the same failure
should occur with 2**31-1 in place of 2**63-1).

----------

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

From report at bugs.python.org  Tue Nov 10 13:47:10 2009
From: report at bugs.python.org (Francesco Frassinelli)
Date: Tue, 10 Nov 2009 12:47:10 +0000
Subject: [issue755660] allow HTMLParser to continue after a parse error
Message-ID: <1257857230.4.0.298993649628.issue755660@psf.upfronthosting.co.za>


Francesco Frassinelli <fraph24 at gmail.com> added the comment:

Site: http://ftp.vim.org/pub/vim/unstable/patches/

Outuput without error customized function:
[...]
  File "./takeit.py", line 54, in inspect
    parser.feed(data.read().decode())
  File "/home/frafra/Scrivania/takeit/html/parser.py", line 107, in feed
    self.goahead(0)
  File "/home/frafra/Scrivania/takeit/html/parser.py", line 163, in goahead
    k = self.parse_declaration(i)
  File "/usr/local/lib/python3.1/_markupbase.py", line 97, in
parse_declaration
    decltype, j = self._scan_name(j, i)
  File "/usr/local/lib/python3.1/_markupbase.py", line 387, in _scan_name
    % rawdata[declstartpos:declstartpos+20])
  File "/home/frafra/Scrivania/takeit/html/parser.py", line 122, in error
    raise HTMLParseError(message, self.getpos())
html.parser.HTMLParseError: expected name token at '<! gives an error
me', at line 153, column 48

Output with error customized function:
[...]
  File "./takeit.py", line 55, in inspect
    parser.feed(data.read().decode())
  File "/home/frafra/Scrivania/takeit/html/parser.py", line 107, in feed
    self.goahead(0)
  File "/home/frafra/Scrivania/takeit/html/parser.py", line 163, in goahead
    k = self.parse_declaration(i)
  File "/usr/local/lib/python3.1/_markupbase.py", line 97, in
parse_declaration
    decltype, j = self._scan_name(j, i)
TypeError: 'NoneType' object is not iterable

----------

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

From report at bugs.python.org  Tue Nov 10 13:47:38 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 10 Nov 2009 12:47:38 +0000
Subject: [issue7298] reversed(range(x, -1, -1)) is empty when x > 1
In-Reply-To: <1257848858.69.0.270094372501.issue7298@psf.upfronthosting.co.za>
Message-ID: <1257857258.54.0.603941946095.issue7298@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Further investigations show that range_iter has the same problem.  :-(

>>> for x in range(-1, 2**63-1): print(x)
...
(no output)

This really needs to be fixed.  Upgrading to release blocker, and
removing the easy flag.

----------
keywords:  -easy
priority: critical -> release blocker

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

From report at bugs.python.org  Tue Nov 10 13:52:22 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 10 Nov 2009 12:52:22 +0000
Subject: [issue7298] reversed(range(x, -1, -1)) is empty when x > 1
In-Reply-To: <1257848858.69.0.270094372501.issue7298@psf.upfronthosting.co.za>
Message-ID: <1257857542.09.0.816028557281.issue7298@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

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

From report at bugs.python.org  Tue Nov 10 13:56:39 2009
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 10 Nov 2009 12:56:39 +0000
Subject: [issue7299] setup.py install doesn't honor PYTHONUSERBASE
In-Reply-To: <1257857799.68.0.397965237537.issue7299@psf.upfronthosting.co.za>
Message-ID: <1257857799.68.0.397965237537.issue7299@psf.upfronthosting.co.za>


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

Got an user report about setup.py install not honoring PYTHONUSERBASE.
Is this by design? If not, the attached patch seems to implement this
functionality.

----------
assignee: tarek
components: Distutils
files: userbase.diff
keywords: patch, patch
messages: 95111
nosy: doko, tarek
severity: normal
status: open
title: setup.py install doesn't honor PYTHONUSERBASE
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file15305/userbase.diff

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

From report at bugs.python.org  Tue Nov 10 14:13:24 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 10 Nov 2009 13:13:24 +0000
Subject: [issue7299] setup.py install doesn't honor PYTHONUSERBASE
In-Reply-To: <1257857799.68.0.397965237537.issue7299@psf.upfronthosting.co.za>
Message-ID: <1257858804.04.0.294455532749.issue7299@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

install_userbase is using USER_BASE which is in site.py.

This value is initialized when Python starts, and does check for
PYTHONUSERBASE in the environ. (if ENABLE_USER_SITE is true)

If this doesn't happen, this is most likely because the user can't write
to its .local.

If he can, you need to debug the Python starting process (site.main())
to see why it's not used.

----------

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

From report at bugs.python.org  Tue Nov 10 14:20:19 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 10 Nov 2009 13:20:19 +0000
Subject: [issue7267] format method: c presentation type broken
In-Reply-To: <1257438168.68.0.774312526176.issue7267@psf.upfronthosting.co.za>
Message-ID: <1257859219.18.0.49969534424.issue7267@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

> so str.format() might raise an OverflowError for values >= 128 (or >=
256?)

Maybe, but the issue you reported is in unicode.format() (not
str.format()), and I think that should be fixed. I'm trying to think of
how best to address it.

As for the second issue you raise (which I think is that str.format()
can't take a unicode argument), would you mind opening a separate issue
for this and assigning it to me? Thanks.

----------

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

From report at bugs.python.org  Tue Nov 10 14:57:35 2009
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Tue, 10 Nov 2009 13:57:35 +0000
Subject: [issue7300] Unicode arguments in str.format()
In-Reply-To: <1257861455.06.0.0846130484851.issue7300@psf.upfronthosting.co.za>
Message-ID: <1257861455.06.0.0846130484851.issue7300@psf.upfronthosting.co.za>


New submission from Walter D?rwald <walter at livinglogic.de>:

str.format() doesn't handle unicode arguments:

Python 2.6.4 (r264:75706, Oct 27 2009, 15:18:04) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> '{0}'.format(u'\u3042')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\u3042' in
position 0: ordinal not in range(128)

Unicode arguments should be treated in the same way as the % operator
does it: by promoting the format string to unicode:

>>> '%s' % u'\u3042'
u'\u3042'

----------
assignee: eric.smith
components: Interpreter Core
messages: 95114
nosy: doerwalter, eric.smith
severity: normal
status: open
title: Unicode arguments in str.format()
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Nov 10 14:58:24 2009
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Tue, 10 Nov 2009 13:58:24 +0000
Subject: [issue7267] format method: c presentation type broken
In-Reply-To: <1257438168.68.0.774312526176.issue7267@psf.upfronthosting.co.za>
Message-ID: <1257861504.07.0.00492398223998.issue7267@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

Done: issue 7300.

----------

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

From report at bugs.python.org  Tue Nov 10 15:54:20 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 10 Nov 2009 14:54:20 +0000
Subject: [issue7298] reversed(range(x, -1, -1)) is empty when x > 1
In-Reply-To: <1257848858.69.0.270094372501.issue7298@psf.upfronthosting.co.za>
Message-ID: <1257864860.6.0.299741795784.issue7298@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here are some tests.

----------
keywords: +patch
stage:  -> needs patch
Added file: http://bugs.python.org/file15306/issue7298_test.patch

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

From report at bugs.python.org  Tue Nov 10 16:05:32 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 10 Nov 2009 15:05:32 +0000
Subject: [issue7301] Add environment variable $PYTHONWARNINGS
In-Reply-To: <1257865531.11.0.841786263832.issue7301@psf.upfronthosting.co.za>
Message-ID: <1257865531.11.0.841786263832.issue7301@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

It would be very useful to have an environment variable $PYTHONWARNINGS,
tied to the -W option for silencing various warnings (most importantly,
DeprecationWarnings).

Use case: a test suite running many subprocesses, testing that those
subproc output is clean.  DeprecationWarnings cannot easily be
suppressed by passing -W flags all around or using liberally sprinkled
filterwarnings().  Setting $PYTHONWARNINGS once and for all to silence
all processes would be very useful.

----------
components: Library (Lib)
messages: 95117
nosy: barry
severity: normal
status: open
title: Add environment variable $PYTHONWARNINGS
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Nov 10 16:27:17 2009
From: report at bugs.python.org (jasper)
Date: Tue, 10 Nov 2009 15:27:17 +0000
Subject: [issue7296] OverflowError: signed integer is greater than maximum on
	mips64
In-Reply-To: <1257807734.54.0.518943570242.issue7296@psf.upfronthosting.co.za>
Message-ID: <1257866837.55.0.0225307687233.issue7296@psf.upfronthosting.co.za>


jasper <jasper at humppa.nl> added the comment:

After properly compiling with -O0, it actually gets a lot further in the
build. It crashes elsewhere though:

PYTHONPATH=/usr/obj/ports/Python-2.6.3/fake-sgi/usr/local/lib/python2.6
   ./python -Wi -tt
/usr/obj/ports/Python-2.6.3/fake-sgi/usr/local/lib/python2.6/compileall.py
 -d /usr/local/lib/python2.6 -f  -x 'bad_coding|badsyntax|site-packages'
/usr/obj/ports/Python-2.6.3/fake-sgi/usr/local/lib/python2.6
Floating point exception (core dumped)

Attached is the full build log with the backtrace of that core file.

----------
Added file: http://bugs.python.org/file15307/Debug_build.log

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

From report at bugs.python.org  Tue Nov 10 17:18:45 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 10 Nov 2009 16:18:45 +0000
Subject: [issue2422] Automatically disable pymalloc when running under valgrind
In-Reply-To: <1205925069.41.0.603933745456.issue2422@psf.upfronthosting.co.za>
Message-ID: <1257869925.25.0.948408864751.issue2422@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
nosy: +dmalcolm

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

From report at bugs.python.org  Tue Nov 10 17:25:25 2009
From: report at bugs.python.org (Rene Dudfield)
Date: Tue, 10 Nov 2009 16:25:25 +0000
Subject: [issue2399] Patches for Tools/msi
In-Reply-To: <1205858738.04.0.681248681608.issue2399@psf.upfronthosting.co.za>
Message-ID: <1257870325.71.0.257776712151.issue2399@psf.upfronthosting.co.za>


Rene Dudfield <illume at users.sourceforge.net> added the comment:

Adding distutils to components for this old msi patch.

These seem like useful things for those making msi packages with distutils.

----------
components: +Distutils
nosy: +illume

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

From report at bugs.python.org  Tue Nov 10 17:43:08 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 10 Nov 2009 16:43:08 +0000
Subject: [issue7296] OverflowError: signed integer is greater than maximum on
	mips64
In-Reply-To: <1257807734.54.0.518943570242.issue7296@psf.upfronthosting.co.za>
Message-ID: <1257871388.46.0.388800939519.issue7296@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  I don't understand that backtrace at all.  It seems to say that
the conversion of this particular double value (2.34e17) to long is
causing some kind of arithmetic exception.  I'd assume overflow, except
that the configure script says sizeof(long) == 8, and a 64-bit long
should be plenty large enough to hold the result of the conversion.

Is it possible that the configure script is somehow ending up with the
wrong value for SIZEOF_LONG?  Or do C longs definitely have width 64 on
this platform?

----------

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

From report at bugs.python.org  Tue Nov 10 17:59:17 2009
From: report at bugs.python.org (jasper)
Date: Tue, 10 Nov 2009 16:59:17 +0000
Subject: [issue7296] OverflowError: signed integer is greater than maximum on
	mips64
In-Reply-To: <1257807734.54.0.518943570242.issue7296@psf.upfronthosting.co.za>
Message-ID: <1257872357.78.0.5611347467.issue7296@psf.upfronthosting.co.za>


jasper <jasper at humppa.nl> added the comment:

this little test program:
#include <unistd.h>
int main(int argc, char*argv[])
{
  printf("short = %d\n", sizeof(short));
  printf("int = %d\n", sizeof(int));
  printf("float = %d\n", sizeof(float));
  printf("long = %d\n", sizeof(long));
  printf("double = %d\n", sizeof(double));
  printf("long long = %d\n", sizeof(long long));
  printf("double long = %d\n", sizeof(double long));
  return 0;
}
gives the following values on mips64:
short = 2
int = 4
float = 4
long = 8
double = 8
long long = 8
double long = 16

is there any other thing I should check?

----------

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

From report at bugs.python.org  Tue Nov 10 18:32:02 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 10 Nov 2009 17:32:02 +0000
Subject: [issue1235] CGIHTTPRequestHandler.run_cgi() does not run on Windows
	if sys.executable contains blanks
In-Reply-To: <1191492781.93.0.606740316101.issue1235@psf.upfronthosting.co.za>
Message-ID: <1257874322.87.0.220561140476.issue1235@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

drukker: I verified your patch. Looks fine for changes made to the
subprocess call. 

You mentioned: I've also unified the Unix and Windows portions in
run_cgi.  Both now use subprocess."
I don't see it in the patch. Was it that you assumed changing the
variable to from cmdline to 'args' makes it unified for windows and
linux? But it does not.

Irrespective, this report can be addressed by the changes you suggested.

----------
assignee:  -> orsenthil
nosy: +orsenthil

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

From report at bugs.python.org  Tue Nov 10 18:53:45 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 10 Nov 2009 17:53:45 +0000
Subject: [issue7296] OverflowError: signed integer is greater than maximum on
	mips64
In-Reply-To: <1257807734.54.0.518943570242.issue7296@psf.upfronthosting.co.za>
Message-ID: <1257875625.79.0.00942679463806.issue7296@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Sorry, I'm running out of ideas.  The traceback is truly baffling.

I'm not sure why you're configuring with --with-fpectl.  Does removing 
this make any difference?

Maybe you could also try copying _PyHash_Double into a small test program, 
calling it with an input of 2.34e17 (get rid of the Python-specific calls 
in the if-branch, which I believe isn't taken in this case anyway) and see 
if you can reproduce the FP signal there.

----------

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

From report at bugs.python.org  Tue Nov 10 19:08:16 2009
From: report at bugs.python.org (Ned Deily)
Date: Tue, 10 Nov 2009 18:08:16 +0000
Subject: [issue6393] OS X: python3 from python-3.1.dmg crashes at startup
In-Reply-To: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>
Message-ID: <1257876496.23.0.496619533496.issue6393@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The missing return result in the else case has been subsequently fixed in 
r75539 (py3k) and r75541 (3.0) so this issue should be re-closed.

----------

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

From report at bugs.python.org  Tue Nov 10 19:26:04 2009
From: report at bugs.python.org (Derk Drukker)
Date: Tue, 10 Nov 2009 18:26:04 +0000
Subject: [issue1235] CGIHTTPRequestHandler.run_cgi() does not run on Windows
	if sys.executable contains blanks
In-Reply-To: <1191492781.93.0.606740316101.issue1235@psf.upfronthosting.co.za>
Message-ID: <1257877564.82.0.557633848375.issue1235@psf.upfronthosting.co.za>


Derk Drukker <derk.drukker at gmail.com> added the comment:

orsenthil: I reverted the changes that make Windows and Unix use the
same code in Patch Set 3, and briefly mentioned the reason for that in
the Rietveld app.  I should have mentioned it here too.

It was because it actually makes the implementation on Unix worse, since
the Windows implementation reads all data in memory.  (The subprocess
module documentation has this note: "The data read is buffered in
memory, so do not use this method if the data size is large or unlimited.")

I tried replacing subprocess.PIPE with rfile/wfile, but it turns out
that that won't work, because on Windows socket.fileno() cannot be used
where file descriptors can be used, as the socket module documentation
states.

----------

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

From report at bugs.python.org  Tue Nov 10 19:26:10 2009
From: report at bugs.python.org (Derk Drukker)
Date: Tue, 10 Nov 2009 18:26:10 +0000
Subject: [issue1235] CGIHTTPRequestHandler.run_cgi() does not run on Windows
	if sys.executable contains blanks
In-Reply-To: <1191492781.93.0.606740316101.issue1235@psf.upfronthosting.co.za>
Message-ID: <1257877570.27.0.433767423835.issue1235@psf.upfronthosting.co.za>


Changes by Derk Drukker <derk.drukker at gmail.com>:


Removed file: http://bugs.python.org/file15181/fix-issue1235-py3k.patch

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

From report at bugs.python.org  Tue Nov 10 19:39:27 2009
From: report at bugs.python.org (Egon Frerich)
Date: Tue, 10 Nov 2009 18:39:27 +0000
Subject: [issue7302] Wrong link to Python Language Mapping Specification
In-Reply-To: <1257878367.72.0.0298687588938.issue7302@psf.upfronthosting.co.za>
Message-ID: <1257878367.72.0.0298687588938.issue7302@psf.upfronthosting.co.za>


New submission from Egon Frerich <e.frerich at nord-com.net>:

There is a wrong link in
 
http://docs.python.org/library/xml.dom.html#domimplementation-objects

Python Language Mapping Specification
is linked to
http://www.omg.org/docs/formal/02-11-05.pdf

but I assume it should be

http://www.omg.org/spec/PYTH/1.2/PDF

----------
assignee: georg.brandl
components: Documentation
messages: 95126
nosy: efrerich, georg.brandl
severity: normal
status: open
title: Wrong link to Python Language Mapping Specification

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

From report at bugs.python.org  Tue Nov 10 19:41:31 2009
From: report at bugs.python.org (Ned Deily)
Date: Tue, 10 Nov 2009 18:41:31 +0000
Subject: [issue7072] isspace(0xa0) is true on Mac OS X
In-Reply-To: <1254838065.19.0.554814525306.issue7072@psf.upfronthosting.co.za>
Message-ID: <1257878491.15.0.591967017442.issue7072@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ronaldoussoren
versions:  -Python 3.0

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

From report at bugs.python.org  Tue Nov 10 19:52:32 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Nov 2009 18:52:32 +0000
Subject: [issue3001] RLock's are SLOW
In-Reply-To: <1212074891.45.0.23606216758.issue3001@psf.upfronthosting.co.za>
Message-ID: <1257879152.4.0.0762184606738.issue3001@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed the latest patch in r76189. Thanks for the reviews, everyone.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Tue Nov 10 20:00:33 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 10 Nov 2009 19:00:33 +0000
Subject: [issue7290] Update 'how do I set a global variable' faq entry
In-Reply-To: <1257738795.91.0.826293712603.issue7290@psf.upfronthosting.co.za>
Message-ID: <1257879633.49.0.680921342779.issue7290@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed, with your suggested rewording, in r76190.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Nov 10 21:29:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Nov 2009 20:29:48 +0000
Subject: [issue7197] test_multiprocessing crashes under Windows when run in
	verbose mode
In-Reply-To: <1256382825.55.0.179199170316.issue7197@psf.upfronthosting.co.za>
Message-ID: <1257884988.42.0.92318538499.issue7197@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, if nobody objects, I will commit it since it's simple enough and
blocks any attempt at diagnosing test_multiprocessing under Windows.

----------

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

From report at bugs.python.org  Tue Nov 10 21:31:24 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 10 Nov 2009 20:31:24 +0000
Subject: [issue7197] test_multiprocessing crashes under Windows when run in
	verbose mode
In-Reply-To: <1256382825.55.0.179199170316.issue7197@psf.upfronthosting.co.za>
Message-ID: <1257885084.71.0.227860840658.issue7197@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Please do; I've been swamped - I'm sorry

----------

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

From report at bugs.python.org  Tue Nov 10 21:51:05 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 10 Nov 2009 20:51:05 +0000
Subject: [issue2399] Patches for Tools/msi
In-Reply-To: <1205858738.04.0.681248681608.issue2399@psf.upfronthosting.co.za>
Message-ID: <1257886265.44.0.632451405662.issue2399@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Strictly speaking, they apply to Tools/msi only (IIUC). So adjusting
them to msilib is likely extra work.

----------

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

From report at bugs.python.org  Tue Nov 10 23:12:33 2009
From: report at bugs.python.org (ulrik)
Date: Tue, 10 Nov 2009 22:12:33 +0000
Subject: [issue7303] pkgutil lacks documentation for useful functions
In-Reply-To: <1257891153.41.0.767469344024.issue7303@psf.upfronthosting.co.za>
Message-ID: <1257891153.41.0.767469344024.issue7303@psf.upfronthosting.co.za>


New submission from ulrik <ulrik.sverdrup at gmail.com>:

The module pkgutil has no documentation of functions added after its
introduction, in the official python documentation collection.

http://docs.python.org/dev/py3k/library/pkgutil.html

The module is well documented with docstrings.

I assume the module's exposed functions, some very useful, are open for
public use, for example pkgutil.iter_modules and .walk_packages.

Is all that is required copying the docstrings into the documentation?
If someone believes only Python insight and knowledge of reST sytax is
enough to make some passable documentation from the existing docstrings,
I could submit a patch for that.

----------
assignee: georg.brandl
components: Documentation
messages: 95132
nosy: englabenny, georg.brandl
severity: normal
status: open
title: pkgutil lacks documentation for useful functions
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Tue Nov 10 23:32:48 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 10 Nov 2009 22:32:48 +0000
Subject: [issue7304] email.message.Message.set_payload and as_string given
	charset 'us-ascii' plus 8bit data produces invalid message
In-Reply-To: <1257892368.6.0.221695441401.issue7304@psf.upfronthosting.co.za>
Message-ID: <1257892368.6.0.221695441401.issue7304@psf.upfronthosting.co.za>


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

The following produces a non-conformant message, since the us-ascii
charset is strictly 7bit:

>>> import email.message
>>> m = email.message.Message()
>>> m.set_payload("""A few lines
... of 8-bit text
...
... One high bit character: ?.
... """, 'us-ascii')
>>> print m.as_string()
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit

A few lines
of 8-bit text

One high bit character: ?.

>>>

----------
components: Library (Lib)
messages: 95133
nosy: r.david.murray
priority: normal
severity: normal
stage: test needed
status: open
title: email.message.Message.set_payload and as_string given charset 'us-ascii' plus 8bit data produces invalid message
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Nov 11 00:58:46 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Tue, 10 Nov 2009 23:58:46 +0000
Subject: [issue7301] Add environment variable $PYTHONWARNINGS
In-Reply-To: <1257865531.11.0.841786263832.issue7301@psf.upfronthosting.co.za>
Message-ID: <1257897526.44.0.759776773351.issue7301@psf.upfronthosting.co.za>


Changes by Philip Jenvey <pjenvey at underboss.org>:


----------
nosy: +pjenvey

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

From report at bugs.python.org  Wed Nov 11 02:06:09 2009
From: report at bugs.python.org (Tatsuhiro Tsujikawa)
Date: Wed, 11 Nov 2009 01:06:09 +0000
Subject: [issue7291] urllib2 cannot handle https with proxy requiring auth
In-Reply-To: <1257741498.16.0.683281197284.issue7291@psf.upfronthosting.co.za>
Message-ID: <1257901569.47.0.339753682138.issue7291@psf.upfronthosting.co.za>


Changes by Tatsuhiro Tsujikawa <tsujikawa at gp.hitachi.co.jp>:


----------
versions: +Python 2.7

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

From report at bugs.python.org  Wed Nov 11 02:36:03 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 11 Nov 2009 01:36:03 +0000
Subject: [issue1235] CGIHTTPRequestHandler.run_cgi() does not run on Windows
	if sys.executable contains blanks
In-Reply-To: <1191492781.93.0.606740316101.issue1235@psf.upfronthosting.co.za>
Message-ID: <1257903363.71.0.454899211151.issue1235@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Committed revision 76208 in trunk.  Shall look at the output of windows
buildbots and merge the changes to other codelines.

----------

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

From report at bugs.python.org  Wed Nov 11 03:35:18 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 11 Nov 2009 02:35:18 +0000
Subject: [issue7303] pkgutil lacks documentation for useful functions
In-Reply-To: <1257891153.41.0.767469344024.issue7303@psf.upfronthosting.co.za>
Message-ID: <1257906918.77.0.79042600578.issue7303@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
nosy: +pje

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

From report at bugs.python.org  Wed Nov 11 04:19:05 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 11 Nov 2009 03:19:05 +0000
Subject: [issue7190] Problems running threaded Tkinter program under OS X IDLE
In-Reply-To: <1256304335.58.0.401726660666.issue7190@psf.upfronthosting.co.za>
Message-ID: <1257909545.74.0.227389670079.issue7190@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The test program depends on an external third-party module graphics.  
>From the problem description and a web search, I assume the file is:

   http://mcsp.wartburg.edu/zelle/python/graphics.py

Can you confirm that?

Using that module, target.py runs on 10.5 invoking python2.6 directly 
with Apple-supplied Tk 8.4.7 or under idle2.6.  However, with a 
python2.6 using ActiveState Tk 8.4.19 installed on 10.5 or 10.6, 
target.py fails with:
Tk_MacOSXSetupTkNotifier: first [load] of TkAqua has to occur in the 
main thread!

As of 10.6(.2), attempts to run with a Tkinter linked to the Apple-
suppled Tk 8.5.7 hang (similar problems noted with other apps).

I was not able to reproduce the error message your report but there are 
certainly known and/or suspected issues with Tkinter and Apple's Tk 
8.4.7, even more likely running under IDLE which uses Tkinter itself.  

I'm not sure what action to recommend with this issue.  Perhaps it makes 
the most sense to leave it open until Tkinter with Apple Tk 8.5 is 
working reliably and then retest.

BTW, the message "IDLE can't bind TCP/IP port 8833" most likely 
indicates one of the IDLE processes has aborted leaving another waiting 
for the socket to close.  Ideally, that shouldn't happen.

Thanks for the problem report.

----------
nosy: +ned.deily
title: TCP/IP? -> Problems running threaded Tkinter program under OS X IDLE

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

From report at bugs.python.org  Wed Nov 11 05:22:47 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 11 Nov 2009 04:22:47 +0000
Subject: [issue1235] CGIHTTPRequestHandler.run_cgi() does not run on Windows
	if sys.executable contains blanks
In-Reply-To: <1191492781.93.0.606740316101.issue1235@psf.upfronthosting.co.za>
Message-ID: <1257913367.42.0.178995901191.issue1235@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Committed revision 76209 - release26-maint
Committed revision 76210 - py3k
Committed revision 76211 - release31-maint

Thanks Derk for the patch.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Wed Nov 11 08:20:12 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 11 Nov 2009 07:20:12 +0000
Subject: [issue7190] Problems running threaded Tkinter program under OS X IDLE
In-Reply-To: <1256304335.58.0.401726660666.issue7190@psf.upfronthosting.co.za>
Message-ID: <1257924012.02.0.592205550012.issue7190@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The "graphics" module runs Tk in a separate thread, which means it 
accesses the Apple GUI frameworks from a thread that is not the main 
thread. 

This is AFAIK not supported by Apple, which would explain why it doesn't 
work.

I'll look for a link to the relevant Apple documentation before closing 
this.

----------

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

From report at bugs.python.org  Wed Nov 11 09:13:08 2009
From: report at bugs.python.org (Chris Rebert)
Date: Wed, 11 Nov 2009 08:13:08 +0000
Subject: [issue7159] Urllib2 authentication memory.
In-Reply-To: <1255793559.46.0.185389780208.issue7159@psf.upfronthosting.co.za>
Message-ID: <1257927188.3.0.223307239645.issue7159@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

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

From report at bugs.python.org  Wed Nov 11 13:05:58 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 11 Nov 2009 12:05:58 +0000
Subject: [issue7190] Problems running threaded Tkinter program under OS X IDLE
In-Reply-To: <1256304335.58.0.401726660666.issue7190@psf.upfronthosting.co.za>
Message-ID: <1257941158.28.0.667786254888.issue7190@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

<http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/Mul
tithreading/ThreadSafetySummary/ThreadSafetySummary.html#//apple_ref/doc/u
id/10000057i-CH12-SW1> summarizes the thread safety aspects for Apple GUI 
programs.

Basicly all eventhandling needs to be done on the main thread.

This means that this issue is not a python bug, but a platform issue that 
we cannot fix or work around. I therefore propose to close this issue.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> pending
type: crash -> behavior

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

From report at bugs.python.org  Wed Nov 11 14:42:52 2009
From: report at bugs.python.org (River Tarnell)
Date: Wed, 11 Nov 2009 13:42:52 +0000
Subject: [issue7305] urllib2.urlopen() segfault using SSL on Solaris
In-Reply-To: <1257946972.34.0.0114488119184.issue7305@psf.upfronthosting.co.za>
Message-ID: <1257946972.34.0.0114488119184.issue7305@psf.upfronthosting.co.za>


New submission from River Tarnell <river at flyingparchment.org.uk>:

Using Python 2.6.2 or 2.6.4 on Solaris 10, opening an SSL (https) URL 
using urllib2.urlopen() crashes Python:

% python
Python 2.6.4 (r264:75706, Nov 11 2009, 13:23:45) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib2; urllib2.urlopen('https://launchpad.net/~netbook-
remix-team/+archive/ppa')
zsh: segmentation fault (core dumped)  python
% pstack core
core 'core' of 14970:   python
 fe86663f AES_encrypt () + 173
%

Python was compiled using Sun C 5.10 SunOS_i386 2009/06/03 and OpenSSL 
0.9.7d (+ Sun security patches) using flags:

CFLAGS='-i -xO4 -xspace -xstrconst -xpentium -mr -xregs=no%frameptr'
LDFLAGS='-L/opt/ts/python/2.6/lib -L/usr/sfw/lib -R/opt/ts/python/2.6/
lib:/usr/sfw/lib -L/opt/ts/X11/lib -R/opt/ts/X11/lib -L/opt/ts/lib -R/
opt/ts/lib -L/opt/ts/python/2.6/lib'
CPPFLAGS='-I/opt/ts/python/2.6/include -I/usr/sfw/include -I/opt/ts/X11/
include -D__EXTENSIONS__ -I/opt/ts/include'

./configure --prefix=/opt/ts/python/2.6 --bindir=/opt/ts/python/2.6/bin 
--libdir=/opt/ts/python/2.6/lib --mandir=/opt/ts/python/26/share/man --
datadir=/opt/ts/python/2.6/share --includedir=/opt/ts/python/2.6/
include --infodir=/opt/ts/python/2.6/share/info --libexecdir=/opt/ts/
python/2.6/lib --sysconfdir=/etc/opt/ts --disable-nls --disable-static 
--with-threads --enable-ipv6 --prefix=/opt/ts/python/2.6 --enable-shared

----------
components: Extension Modules
messages: 95139
nosy: rtarnell
severity: normal
status: open
title: urllib2.urlopen() segfault using SSL on Solaris
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Wed Nov 11 16:29:01 2009
From: report at bugs.python.org (David Fraser)
Date: Wed, 11 Nov 2009 15:29:01 +0000
Subject: [issue6132] Implement the GIL with critical sections in Windows
In-Reply-To: <1243462195.91.0.81958628587.issue6132@psf.upfronthosting.co.za>
Message-ID: <1257953341.86.0.339440428608.issue6132@psf.upfronthosting.co.za>


Changes by David Fraser <davidf at sjsoft.com>:


----------
nosy: +davidfraser

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

From report at bugs.python.org  Wed Nov 11 16:38:05 2009
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 11 Nov 2009 15:38:05 +0000
Subject: [issue7306] Patch - skip winsound tests if no default sound is
	configured
In-Reply-To: <1257953885.18.0.603136766884.issue7306@psf.upfronthosting.co.za>
Message-ID: <1257953885.18.0.603136766884.issue7306@psf.upfronthosting.co.za>


New submission from Brian Curtin <curtin at acm.org>:

I noticed test failures on trunk for test_winsound on only one of my
boxes. Everything works fine on XP, but PlaySoundTest test methods fail
on Windows Server 2003.

It appears that on WS2k3 there are no default system sounds configured.
For example, view the difference of the following registry key on an XP
and Server machine:
HKEY_CURRENT_USER\AppEvents\Schemes\Apps\.Default\SystemExit\.Default.

The patch includes a function to figure out if a WAV file is associated
with a particular sound, and unittest.skipIf is used to decorate some
methods to skip if they don't have a configured sound.

----------
components: Tests, Windows
files: winsound_test_skipping.patch
keywords: patch
messages: 95140
nosy: brian.curtin
severity: normal
status: open
title: Patch - skip winsound tests if no default sound is configured
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file15308/winsound_test_skipping.patch

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

From report at bugs.python.org  Wed Nov 11 16:42:49 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 11 Nov 2009 15:42:49 +0000
Subject: [issue7197] test_multiprocessing crashes under Windows when run in
	verbose mode
In-Reply-To: <1256382825.55.0.179199170316.issue7197@psf.upfronthosting.co.za>
Message-ID: <1257954169.89.0.466960359437.issue7197@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This has been committed to trunk (r76196) and py3k (r76198).
I'm reluctant to backport it to 2.6/3.1 because unittest has changed a
lot in-between, and the old version doesn't have a lot of tests. Please
do if you think it's useful :)

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Wed Nov 11 18:09:22 2009
From: report at bugs.python.org (Moriyoshi Koizumi)
Date: Wed, 11 Nov 2009 17:09:22 +0000
Subject: [issue5890] Subclassing property doesn't preserve the auto __doc__
	behavior
In-Reply-To: <1241129592.84.0.608165277997.issue5890@psf.upfronthosting.co.za>
Message-ID: <1257959362.03.0.571776463226.issue5890@psf.upfronthosting.co.za>


Moriyoshi Koizumi <mozo+python at mozo.jp> added the comment:

A subclass of property doesn't always have writable __doc__, especially 
what is implemented in C.  This actually causes a problem with 
Boost.Python's StaticProperty.

References:
- http://mail.python.org/pipermail/cplusplus-sig/2009-August/014747.html
- http://lists.boost.org/Archives/boost/2009/10/157512.php
- https://bugs.launchpad.net/ubuntu/+source/boost1.38/+bug/457688

----------
nosy: +moriyoshi

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

From report at bugs.python.org  Wed Nov 11 18:11:50 2009
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 11 Nov 2009 17:11:50 +0000
Subject: [issue1235] CGIHTTPRequestHandler.run_cgi() does not run on Windows
	if sys.executable contains blanks
In-Reply-To: <1191492781.93.0.606740316101.issue1235@psf.upfronthosting.co.za>
Message-ID: <1257959510.88.0.69775010892.issue1235@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

This change causes failures in test_httpservers on trunk r76211 on
Windows. I attached a simple patch which fixes the problem (NameError on
'p').

----------
nosy: +brian.curtin
Added file: http://bugs.python.org/file15309/issue1235_fix.patch

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

From report at bugs.python.org  Wed Nov 11 18:26:54 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 11 Nov 2009 17:26:54 +0000
Subject: [issue1235] CGIHTTPRequestHandler.run_cgi() does not run on Windows
	if sys.executable contains blanks
In-Reply-To: <1191492781.93.0.606740316101.issue1235@psf.upfronthosting.co.za>
Message-ID: <1257960414.16.0.846963812164.issue1235@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Thanks for the notification. Seems I over looked it. Fixed it with the
changes in 76212 (trunk) and 76213 (release26-maint). py3k did not have
this issue.

----------

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

From report at bugs.python.org  Wed Nov 11 18:38:15 2009
From: report at bugs.python.org (Moriyoshi Koizumi)
Date: Wed, 11 Nov 2009 17:38:15 +0000
Subject: [issue7139] ElementTree: Incorrect serialization of end-of-line
	characters in attribute values
In-Reply-To: <1255587690.83.0.0369111720877.issue7139@psf.upfronthosting.co.za>
Message-ID: <1257961095.13.0.647236727364.issue7139@psf.upfronthosting.co.za>


Moriyoshi Koizumi <mozo+python at mozo.jp> added the comment:

@ezio.melotti

Yes, it works flawlessly as for parsing. 

Fixing this would actually break the current behavior, but I believe 
this is how it should work.

It seems #5752 pretty much says the same thing.

@effbot

As specified in 2.11 End-of-Line Handling [2], any variants of EOL 
characters should have been normalized into single #xa before it 
actually gets parsed, so bare #xd characters would never appear as they 
are amongst parsed information items.


[2] http://www.w3.org/TR/xml/#sec-line-ends

----------

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

From report at bugs.python.org  Wed Nov 11 19:49:46 2009
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Wed, 11 Nov 2009 18:49:46 +0000
Subject: [issue1294] Management of KeyboardInterrupt in cmd.py
In-Reply-To: <1257729724.99.0.486336497157.issue1294@psf.upfronthosting.co.za>
Message-ID: <2c51ecee0911111049y244730a0rc2aab0ec3605dd44@mail.gmail.com>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

On Sun, Nov 8, 2009 at 8:22 PM, Ilya Sandler <report at bugs.python.org> wrote:

> Is not this patch backward incompatible?
>
> E.g any cmd-based application which expects Ctrl-C to propagate to the
> top level will be broken by this patch.

But currently, CTRL-C terminates the session instead of propagating
upstream. The only way it would do so is if do_KeyboardInterrupt() is
implemented in which case, the behaviour would remain same even with
the patch.

----------

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

From report at bugs.python.org  Wed Nov 11 20:33:27 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 11 Nov 2009 19:33:27 +0000
Subject: [issue7298] reversed(range(x, -1, -1)) is empty when x > 1
In-Reply-To: <1257848858.69.0.270094372501.issue7298@psf.upfronthosting.co.za>
Message-ID: <1257968007.77.0.199753436459.issue7298@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

and here's a patch (includes the earlier tests).

----------
Added file: http://bugs.python.org/file15310/issue7298.patch

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

From report at bugs.python.org  Wed Nov 11 20:33:39 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 11 Nov 2009 19:33:39 +0000
Subject: [issue7298] reversed(range(x, -1, -1)) is empty when x > 1
In-Reply-To: <1257848858.69.0.270094372501.issue7298@psf.upfronthosting.co.za>
Message-ID: <1257968019.98.0.382733436812.issue7298@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
stage: needs patch -> patch review

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

From report at bugs.python.org  Wed Nov 11 20:41:45 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 11 Nov 2009 19:41:45 +0000
Subject: [issue7298] reversed(range(x, -1, -1)) is empty when x > 1
In-Reply-To: <1257848858.69.0.270094372501.issue7298@psf.upfronthosting.co.za>
Message-ID: <1257968505.2.0.082130784751.issue7298@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I've uploaded this patch to Rietveld to make it easier to review:

http://codereview.appspot.com/154060/show

----------

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

From report at bugs.python.org  Wed Nov 11 21:36:03 2009
From: report at bugs.python.org (Eric Smith)
Date: Wed, 11 Nov 2009 20:36:03 +0000
Subject: [issue7298] reversed(range(x, -1, -1)) is empty when x > 1
In-Reply-To: <1257848858.69.0.270094372501.issue7298@psf.upfronthosting.co.za>
Message-ID: <1257971763.49.0.268614770717.issue7298@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I reviewed the issue on Rietveld, and it looks fine to me with the
exception of my comment about the tests. The comment is mostly a nit, so
if you don't agree don't worry about it.

I tested it with and without pydebug and the tests pass.

I think this should be committed and backported.

----------

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

From report at bugs.python.org  Wed Nov 11 21:48:32 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 11 Nov 2009 20:48:32 +0000
Subject: [issue7307] test_distutils failure under Windows 7
In-Reply-To: <1257972511.98.0.363169878923.issue7307@psf.upfronthosting.co.za>
Message-ID: <1257972511.98.0.363169878923.issue7307@psf.upfronthosting.co.za>


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

In
http://www.python.org/dev/buildbot/3.x/builders/x86%20Windows7%203.x/builds/10/steps/test/logs/stdio
:

======================================================================
ERROR: test_reg_class
(distutils.tests.test_msvc9compiler.msvc9compilerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\distutils\tests\test_msvc9compiler.py",
line 48, in test_reg_class
    v = Reg.get_value(path, "lfitalic")
  File
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\distutils\msvc9compiler.py",
line 62, in get_value
    raise KeyError(key)
KeyError: 'lfitalic'

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

----------
assignee: tarek
components: Distutils
messages: 95150
nosy: pitrou, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_distutils failure under Windows 7
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Nov 11 22:01:52 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 11 Nov 2009 21:01:52 +0000
Subject: [issue7295] test_tarfile uses a hardcoded file name
In-Reply-To: <1257783921.08.0.721111694133.issue7295@psf.upfronthosting.co.za>
Message-ID: <1257973312.63.0.613523995969.issue7295@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch is fine and I've committed it, thanks!

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Nov 11 22:49:22 2009
From: report at bugs.python.org (Stefan Sonnenberg-Carstens)
Date: Wed, 11 Nov 2009 21:49:22 +0000
Subject: [issue7308] Named group regex error
In-Reply-To: <1257976161.92.0.516283510744.issue7308@psf.upfronthosting.co.za>
Message-ID: <1257976161.92.0.516283510744.issue7308@psf.upfronthosting.co.za>


New submission from Stefan Sonnenberg-Carstens <stefan.sonnenberg at pythonmeister.com>:

>>> import re
>>> p = re.compile(r'(P?<quotedstring>("[^"]*"))')
>>> p.match('"Hallo"')
>>> p = re.compile(r'("[^"]*")')
>>> p.match('"Hallo"')
<_sre.SRE_Match object at 0x0197F758>
>>> p.match('"Hallo"').group()
'"Hallo"'
>>> import sys
>>> sys.version
'2.6.3 (r263:75183, Oct  5 2009, 14:41:55) [MSC v.1500 32 bit (Intel)]'

When I use a named group like above, the regex does not match.
It otherwise does.
I could not find a hint in the docs, so I guess this behaviour is
not intended.

----------
components: Interpreter Core, Library (Lib)
messages: 95152
nosy: pythonmeister
severity: normal
status: open
title: Named group regex error
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Nov 11 22:54:03 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 11 Nov 2009 21:54:03 +0000
Subject: [issue7308] Named group regex error
In-Reply-To: <1257976161.92.0.516283510744.issue7308@psf.upfronthosting.co.za>
Message-ID: <1257976443.51.0.884692293084.issue7308@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I think you want '(?P...', not '(P?...'.

Python 2.6.3 (r263:75183, Oct 16 2009, 15:14:21) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> p = re.compile(r'(?P<quotedstring>("[^"]*"))')
>>> p.match('"Hallo"')
<_sre.SRE_Match object at 0x8a3c8>

----------
nosy: +mark.dickinson
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Thu Nov 12 03:18:07 2009
From: report at bugs.python.org (Moriyoshi Koizumi)
Date: Thu, 12 Nov 2009 02:18:07 +0000
Subject: [issue5890] Subclassing property doesn't preserve the auto __doc__
	behavior
In-Reply-To: <1241129592.84.0.608165277997.issue5890@psf.upfronthosting.co.za>
Message-ID: <1257992287.41.0.14722430323.issue5890@psf.upfronthosting.co.za>


Moriyoshi Koizumi <mozo+python at mozo.jp> added the comment:

I created a patch against trunk and 2.6-maint that lets it simply ignore
the error that might happen during PyObject_SetAttrString();

----------
Added file: http://bugs.python.org/file15311/issue5890-refix-py2.6.patch

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

From report at bugs.python.org  Thu Nov 12 03:18:42 2009
From: report at bugs.python.org (Moriyoshi Koizumi)
Date: Thu, 12 Nov 2009 02:18:42 +0000
Subject: [issue5890] Subclassing property doesn't preserve the auto __doc__
	behavior
In-Reply-To: <1241129592.84.0.608165277997.issue5890@psf.upfronthosting.co.za>
Message-ID: <1257992322.13.0.765260612787.issue5890@psf.upfronthosting.co.za>


Moriyoshi Koizumi <mozo+python at mozo.jp> added the comment:

and the other one

----------
Added file: http://bugs.python.org/file15312/issue5890-refix-trunk.patch

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

From report at bugs.python.org  Thu Nov 12 06:03:41 2009
From: report at bugs.python.org (Moriyoshi Koizumi)
Date: Thu, 12 Nov 2009 05:03:41 +0000
Subject: [issue7183] did 2.6.3 regress for some uses of the __doc__ property?
In-Reply-To: <1256167357.49.0.413782567423.issue7183@psf.upfronthosting.co.za>
Message-ID: <1258002221.27.0.518768866808.issue7183@psf.upfronthosting.co.za>


Moriyoshi Koizumi <mozo+python at mozo.jp> added the comment:

See my comment on issue #5890. I attached a patch to solve the
Boost.Python issue.

----------
nosy: +moriyoshi

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

From report at bugs.python.org  Thu Nov 12 06:07:27 2009
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 12 Nov 2009 05:07:27 +0000
Subject: [issue2777] subprocess unit tests for kill, term and send_signal flaky
In-Reply-To: <1210117255.49.0.763796854564.issue2777@psf.upfronthosting.co.za>
Message-ID: <1258002447.12.0.869743215157.issue2777@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I re-enabled the tests a few days ago and haven't seen any issues on
Windows or Linux. I attached a patch against r76222 which enables the
kill, term, and send_signal tests again, and also did some clean-up and
updating to the way tests are skipped.

I also changed the assertNotEqual at the end of the kill, term, and
send_signal tests to check against None instead of 0. I *think* it
should be checking against None there to make sure that the subprocess
isn't live anymore (where None would mean that it is).

Let me know what you think and if this needs anything else.

----------
keywords: +patch
nosy: +brian.curtin
Added file: http://bugs.python.org/file15313/issue2777.patch

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

From report at bugs.python.org  Thu Nov 12 06:22:51 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 12 Nov 2009 05:22:51 +0000
Subject: [issue6108] unicode(exception) and str(exception) should return the
	same message on Py2.6
In-Reply-To: <1243313597.65.0.747575886374.issue6108@psf.upfronthosting.co.za>
Message-ID: <1258003371.36.0.490018009405.issue6108@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I added the output of unicode_exceptions.py on Py2.6 and a testcase
(against the trunk) that fails for 5 different exceptions, including the
IOError mentioned in #6890 (also added to unicode_exceptions.py).
The problem has been introduced by #2517.

----------
keywords: +patch
priority: high -> release blocker
title: unicode(exception) behaves differently on Py2.6 when len(exception.args) > 1 -> unicode(exception) and str(exception) should return the same message on Py2.6
Added file: http://bugs.python.org/file15314/issue6108_testcase.diff

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

From report at bugs.python.org  Thu Nov 12 06:23:02 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 12 Nov 2009 05:23:02 +0000
Subject: [issue6108] unicode(exception) and str(exception) should return the
	same message on Py2.6
In-Reply-To: <1243313597.65.0.747575886374.issue6108@psf.upfronthosting.co.za>
Message-ID: <1258003382.61.0.361893363198.issue6108@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file14071/unicode_exceptions.py

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

From report at bugs.python.org  Thu Nov 12 06:24:18 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 12 Nov 2009 05:24:18 +0000
Subject: [issue6108] unicode(exception) and str(exception) should return the
	same message on Py2.6
In-Reply-To: <1243313597.65.0.747575886374.issue6108@psf.upfronthosting.co.za>
Message-ID: <1258003458.37.0.693389064256.issue6108@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords:  -patch
Added file: http://bugs.python.org/file15315/output_on_py26.txt

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

From report at bugs.python.org  Thu Nov 12 06:25:54 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 12 Nov 2009 05:25:54 +0000
Subject: [issue6108] unicode(exception) and str(exception) should return the
	same message on Py2.6
In-Reply-To: <1243313597.65.0.747575886374.issue6108@psf.upfronthosting.co.za>
Message-ID: <1258003554.06.0.81031206317.issue6108@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file15316/unicode_exceptions.py

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

From report at bugs.python.org  Thu Nov 12 11:50:50 2009
From: report at bugs.python.org (Armin Rigo)
Date: Thu, 12 Nov 2009 10:50:50 +0000
Subject: [issue7309] crasher in str(Exception())
In-Reply-To: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>
Message-ID: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>


New submission from Armin Rigo <arigo at users.sourceforge.net>:

The __str__ method of some exception classes reads attributes without
typechecking them.  Alternatively, the issue could be that the user is
allowed to set the value of these attributes directly, without
typecheck.  The typechecking is only done when we create the exception,
but not later.  Example:

>>> u=UnicodeTranslateError(u'x', 1, 5, 'bah')
>>> u.reason = 0x345345345345345345  
>>> str(u)
"can't translate characters in position 1-4: E\x03"

The 'E\x03' comes from PyString_AS_STRING(reason).  By playing enough it
is probably possible to come up with a real crasher.

----------
components: Interpreter Core
messages: 95159
nosy: arigo
severity: normal
status: open
title: crasher in str(Exception())
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov 12 12:54:01 2009
From: report at bugs.python.org (Kent Johnson)
Date: Thu, 12 Nov 2009 11:54:01 +0000
Subject: [issue7310] Unhelpful __repr__() in os.environ
In-Reply-To: <1258026841.53.0.960128215471.issue7310@psf.upfronthosting.co.za>
Message-ID: <1258026841.53.0.960128215471.issue7310@psf.upfronthosting.co.za>


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

In Python 2.x, os.environ extends UserDict.IterableUserDict and
therefore os.environ.__repr__() shows the environment. This makes it
easy and intuitive to view the entire environment in the interactive
interpreter.

In Python 3.1, os.environ extends _abcoll.MutableMapping and uses
object.__repr__(). This is a much less useful representation.

I suggest adding this __repr__() method to class os._Environ (os.py line
380):

    def __repr__(self): return repr(self.data)

----------
components: Library (Lib)
messages: 95160
nosy: kjohnson
severity: normal
status: open
title: Unhelpful __repr__() in os.environ
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Thu Nov 12 13:45:27 2009
From: report at bugs.python.org (Anand B Pillai)
Date: Thu, 12 Nov 2009 12:45:27 +0000
Subject: [issue7191] Odd behaviour with zlib.decompressobj optional parameter
	"wbits"
In-Reply-To: <1256305257.34.0.885450394278.issue7191@psf.upfronthosting.co.za>
Message-ID: <1258029927.66.0.816410879134.issue7191@psf.upfronthosting.co.za>


Anand B Pillai <abpillai at gmail.com> added the comment:

Ok, so you think a documentation update is enough ? Thanks.

----------

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

From report at bugs.python.org  Thu Nov 12 17:25:50 2009
From: report at bugs.python.org (Chiyuan Zhang)
Date: Thu, 12 Nov 2009 16:25:50 +0000
Subject: [issue7311] Bug on regexp of HTMLParser
In-Reply-To: <1258043150.41.0.372876851796.issue7311@psf.upfronthosting.co.za>
Message-ID: <1258043150.41.0.372876851796.issue7311@psf.upfronthosting.co.za>


New submission from Chiyuan Zhang <pluskid at gmail.com>:

Hi all,

I'm using BeautifulSoup to parsing an HTML page and find it refused to
parse the page. By looking at the backtrace, I found it is a problem
with the python built-in HTMLParser.py. In fact, the web page I'm
parsing is with some Chinese characters. there is a tag like <img
src=/foo/bar.png alt=??> , note this is legacy html page where the
attributes are not quoted. However, the regexp defined in
HTMLParser.py is :

 attrfind = re.compile(
    r'\s*([a-zA-Z_][-.:a-zA-Z_0-9]*)(\s*=\s*'
    r'(\'[^\']*\'|"[^"]*"|[-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~@]*))?')

Note that the Chinese character (also any other non-english
characters), so it fire an error parsing this. I'm not sure whether
the HTML standard allow un-quoted non-ASCII characters in the
attributes. If it allows, this seems to be a bug. and the regexp to
better be [^>\s] IMHO.

BTW: It seems something like :

<script>
var st = "<a></";
</script>

can not be parsed. :-/

----------
components: Library (Lib)
messages: 95162
nosy: pluskid
severity: normal
status: open
title: Bug on regexp of HTMLParser
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Nov 12 21:17:45 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 12 Nov 2009 20:17:45 +0000
Subject: [issue7307] test_distutils failure under Windows 7
In-Reply-To: <1257972511.98.0.363169878923.issue7307@psf.upfronthosting.co.za>
Message-ID: <1258057065.4.0.035271250761.issue7307@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is the same as issue7293.

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed
superseder:  -> test_msvc9compiler test_reg_class failure on new Windows box

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

From report at bugs.python.org  Fri Nov 13 00:40:18 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 12 Nov 2009 23:40:18 +0000
Subject: [issue4628] No universal newline support for compile() when using
	bytes
In-Reply-To: <1228978447.23.0.301216613627.issue4628@psf.upfronthosting.co.za>
Message-ID: <1258069218.03.0.107557438126.issue4628@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Finally got around to fixing this. r76230

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Nov 13 00:58:19 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 12 Nov 2009 23:58:19 +0000
Subject: [issue1479099] 'compile' built-in function failures when missing EOL
Message-ID: <1258070299.97.0.307401454599.issue1479099@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r76231.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Nov 13 00:58:27 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Nov 2009 23:58:27 +0000
Subject: [issue7312] Run some tests in a loop until failure
In-Reply-To: <1258070307.12.0.876277765966.issue7312@psf.upfronthosting.co.za>
Message-ID: <1258070307.12.0.876277765966.issue7312@psf.upfronthosting.co.za>


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

It can be useful to run one or several of the regression tests in a
loop, until one of the tests fail. Here is a patch to do that.

(interesting thing, by the way: you can combine it with -j, in order to
run several instance of the test at once)

----------
components: Tests
files: looptests.patch
keywords: patch
messages: 95166
nosy: jnoller, pitrou, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Run some tests in a loop until failure
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15317/looptests.patch

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

From report at bugs.python.org  Fri Nov 13 01:12:29 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 13 Nov 2009 00:12:29 +0000
Subject: [issue7312] Run some tests in a loop until failure
In-Reply-To: <1258070307.12.0.876277765966.issue7312@psf.upfronthosting.co.za>
Message-ID: <1258071149.45.0.348990035271.issue7312@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

+1 I wanted to do this in +1

This is what I wanted to do in http://bugs.python.org/issue7134

I would put this in 2.x and 3.x :)

There was some feedback in this ML thread: 
http://mail.python.org/pipermail/python-dev/2009-June/090238.html

----------

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

From report at bugs.python.org  Fri Nov 13 01:14:41 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Nov 2009 00:14:41 +0000
Subject: [issue7134] Add looping capability to regrtest
In-Reply-To: <1255563604.05.0.373635467839.issue7134@psf.upfronthosting.co.za>
Message-ID: <1258071281.01.0.341889752287.issue7134@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Run some tests in a loop until failure

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

From report at bugs.python.org  Fri Nov 13 01:15:02 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Nov 2009 00:15:02 +0000
Subject: [issue7312] Run some tests in a loop until failure
In-Reply-To: <1258070307.12.0.876277765966.issue7312@psf.upfronthosting.co.za>
Message-ID: <1258071302.73.0.156489358193.issue7312@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> This is what I wanted to do in http://bugs.python.org/issue7134

Ah, sorry, I hadn't seen it.

----------

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

From report at bugs.python.org  Fri Nov 13 01:16:07 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 13 Nov 2009 00:16:07 +0000
Subject: [issue7312] Run some tests in a loop until failure
In-Reply-To: <1258070307.12.0.876277765966.issue7312@psf.upfronthosting.co.za>
Message-ID: <1258071367.07.0.48787674408.issue7312@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Oh, no apologies needed. You have a patch! :)

----------

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

From report at bugs.python.org  Fri Nov 13 01:45:22 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Nov 2009 00:45:22 +0000
Subject: [issue7312] Run some tests in a loop until failure
In-Reply-To: <1258070307.12.0.876277765966.issue7312@psf.upfronthosting.co.za>
Message-ID: <1258073122.94.0.340299096836.issue7312@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The patch generally looks good to me, but I think you overlooked line
507, where you do a pending.clear() in case of keyboard interrupt in -j
mode.  I tested it on trunk and it seems to work great, except when I
press ctl-C :)

----------

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

From report at bugs.python.org  Fri Nov 13 02:56:33 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Nov 2009 01:56:33 +0000
Subject: [issue6551] test_codecs fails when ran after test_zipimport and
	test_mailbox.
In-Reply-To: <1248318273.86.0.60176603488.issue6551@psf.upfronthosting.co.za>
Message-ID: <1258077393.28.0.424565452211.issue6551@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch.

----------
nosy: +pitrou
stage: needs patch -> patch review

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

From report at bugs.python.org  Fri Nov 13 02:57:07 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Nov 2009 01:57:07 +0000
Subject: [issue6551] test_codecs fails when ran after test_zipimport and
	test_mailbox.
In-Reply-To: <1248318273.86.0.60176603488.issue6551@psf.upfronthosting.co.za>
Message-ID: <1258077427.05.0.0733983565977.issue6551@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
keywords: +patch
Added file: http://bugs.python.org/file15318/modcleanup.patch

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

From report at bugs.python.org  Fri Nov 13 03:04:49 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 13 Nov 2009 02:04:49 +0000
Subject: [issue6551] test_codecs fails when ran after test_zipimport and
	test_mailbox.
In-Reply-To: <1248318273.86.0.60176603488.issue6551@psf.upfronthosting.co.za>
Message-ID: <1258077889.95.0.0174626117071.issue6551@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

The patch looks good to me.

----------
resolution:  -> accepted

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

From report at bugs.python.org  Fri Nov 13 03:37:22 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 13 Nov 2009 02:37:22 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1258079842.63.0.0651247303591.issue7060@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

If this is not ported by the time we get to a 2.7 or 3.2 release, I'd
like to back it out.

----------
priority: normal -> release blocker

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

From report at bugs.python.org  Fri Nov 13 08:00:07 2009
From: report at bugs.python.org (Ilya Sandler)
Date: Fri, 13 Nov 2009 07:00:07 +0000
Subject: [issue1294] Management of KeyboardInterrupt in cmd.py
In-Reply-To: <1192711916.5.0.235687394478.issue1294@psf.upfronthosting.co.za>
Message-ID: <1258095607.89.0.897957063221.issue1294@psf.upfronthosting.co.za>


Ilya Sandler <ilya.sandler at gmail.com> added the comment:

> But currently, CTRL-C terminates the session instead of propagating
upstream

I am not sure I understand: currently Ctrl-C generates a
KeyboardInterrupt, which can be caught by the  application which can
then decide how to proceed (in particular it  can start another command
loop or exit with a meaningful message or anything else).

This patch would suppress KeyboardInterrupt and thus interfere with such
applications. Or am I missing something?

----------

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

From report at bugs.python.org  Fri Nov 13 10:16:24 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 13 Nov 2009 09:16:24 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1258103784.69.0.637586452159.issue7060@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I can easily port it again, and remove the traceback from the exception.
But won't we be sweeping that GC problem under the carpet then?

----------

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

From report at bugs.python.org  Fri Nov 13 13:02:09 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 13 Nov 2009 12:02:09 +0000
Subject: [issue7313] 2to3 fails when source file starts with BOM
In-Reply-To: <1258113728.92.0.380027022792.issue7313@psf.upfronthosting.co.za>
Message-ID: <1258113728.92.0.380027022792.issue7313@psf.upfronthosting.co.za>


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

If the source file is encoded in UTF-8 with a BOM, 
2to3 cannot parse it:

C:\APPS\python\trunk\PCbuild>.\python ..\Tools\scripts
\2to3 c:\temp\test_2to3.py
root: Generating grammar tables from C:\APPS\python
\trunk\lib\lib2to3\PatternGrammar.txt
root: Writing grammar tables to C:\APPS\python\trunk
\lib\lib2to3\PatternGrammar2.7.0.alpha.0.pickle
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: Can't parse c:\temp\test_2to3.py: 
ParseError: bad token: type=55, value=u'\ufeff', 
context=(u'', (1, 0)
)
RefactoringTool: No files need to be modified.
RefactoringTool: There was 1 error:
RefactoringTool: Can't parse c:\temp\test_2to3.py: 
ParseError: bad token: type=55, value=u'\ufeff', 
context=(u'', (1, 0)
)


Tested with 3.1.1 and trunk.

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: test_2to3_bom.py
messages: 95176
nosy: gagenellina
severity: normal
status: open
title: 2to3 fails when source file starts with BOM
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15319/test_2to3_bom.py

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

From report at bugs.python.org  Fri Nov 13 15:24:19 2009
From: report at bugs.python.org (Robin)
Date: Fri, 13 Nov 2009 14:24:19 +0000
Subject: [issue6869] Embedded python crashed on 4th run, if "ctypes" is used
In-Reply-To: <1252485075.59.0.965228056128.issue6869@psf.upfronthosting.co.za>
Message-ID: <1258122259.85.0.926812622705.issue6869@psf.upfronthosting.co.za>


Changes by Robin <robince at gmail.com>:


----------
nosy: +robince

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

From report at bugs.python.org  Fri Nov 13 15:26:02 2009
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 13 Nov 2009 14:26:02 +0000
Subject: [issue7311] Bug on regexp of HTMLParser
In-Reply-To: <1258043150.41.0.372876851796.issue7311@psf.upfronthosting.co.za>
Message-ID: <1258122362.36.0.344769048789.issue7311@psf.upfronthosting.co.za>


Changes by Fred L. Drake, Jr. <fdrake at acm.org>:


----------
nosy: +fdrake

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

From report at bugs.python.org  Fri Nov 13 15:56:11 2009
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Fri, 13 Nov 2009 14:56:11 +0000
Subject: [issue1294] Management of KeyboardInterrupt in cmd.py
In-Reply-To: <1258095607.89.0.897957063221.issue1294@psf.upfronthosting.co.za>
Message-ID: <2c51ecee0911130656p7ef6b10cib1d94c37f6c7ed4e@mail.gmail.com>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

> I am not sure I understand: currently Ctrl-C generates a
> KeyboardInterrupt, which can be caught by the  application which can
> then decide how to proceed (in particular it  can start another command
> loop or exit with a meaningful message or anything else).
>
> This patch would suppress KeyboardInterrupt and thus interfere with such
> applications. Or am I missing something?

I checked the patch and tested with python from trunk. You are right
that the patch catches KeyboardInterrupt thus interfering with any
applications that expect it to be propagated upstream.  Perhaps, this
can be made conditional so that we can keep both behaviors.

But CTRL-D processing doesn't suffer from any backwards compatible
issues and that part of the patch should be able to be applied safely.

----------

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

From report at bugs.python.org  Fri Nov 13 16:04:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Nov 2009 15:04:46 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1258124686.58.0.492820739589.issue7060@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Please note there's a patch in issue7105 to allow safer iteration of
weak dicts.

----------

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

From report at bugs.python.org  Fri Nov 13 16:55:11 2009
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 13 Nov 2009 15:55:11 +0000
Subject: [issue7306] Patch - skip winsound tests if no default sound is
	configured
In-Reply-To: <1257953885.18.0.603136766884.issue7306@psf.upfronthosting.co.za>
Message-ID: <1258127711.58.0.140064880968.issue7306@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Removed file: http://bugs.python.org/file15308/winsound_test_skipping.patch

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

From report at bugs.python.org  Fri Nov 13 16:55:35 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 13 Nov 2009 15:55:35 +0000
Subject: [issue1294] Management of KeyboardInterrupt in cmd.py
In-Reply-To: <1192711916.5.0.235687394478.issue1294@psf.upfronthosting.co.za>
Message-ID: <1258127735.13.0.817992158248.issue1294@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


Removed file: http://bugs.python.org/file8578/unnamed

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

From report at bugs.python.org  Fri Nov 13 16:56:04 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 13 Nov 2009 15:56:04 +0000
Subject: [issue1294] Management of KeyboardInterrupt in cmd.py
In-Reply-To: <1192711916.5.0.235687394478.issue1294@psf.upfronthosting.co.za>
Message-ID: <1258127764.13.0.202020574036.issue1294@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I don't think this is a good idea.

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Fri Nov 13 16:56:15 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Nov 2009 15:56:15 +0000
Subject: [issue6132] Implement the GIL with critical sections in Windows
In-Reply-To: <1243462195.91.0.81958628587.issue6132@psf.upfronthosting.co.za>
Message-ID: <1258127775.87.0.437768520591.issue6132@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Phillip, the GIL implementation has changed completely in the current
py3k (3.2) branch. If you have any specific benchmark to test it, it
would be nice to give it a try.

In any case, using a critical section in thread_nt.h could still be
beneficial for things other than the GIL, assuming it doesn't change the
semantics.

----------
versions: +Python 3.2 -Python 3.1

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

From report at bugs.python.org  Fri Nov 13 16:56:17 2009
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 13 Nov 2009 15:56:17 +0000
Subject: [issue7306] Patch - skip winsound tests if no default sound is
	configured
In-Reply-To: <1257953885.18.0.603136766884.issue7306@psf.upfronthosting.co.za>
Message-ID: <1258127777.65.0.234630425318.issue7306@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Minor cleanup of the original patch

----------
Added file: http://bugs.python.org/file15320/winsound_test_skipping.patch

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

From report at bugs.python.org  Fri Nov 13 17:11:00 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 13 Nov 2009 16:11:00 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1258128660.46.0.390865500646.issue7060@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Ok, I ported the change again in revision 76238, removing the traceback 
from the stored exception object.

----------

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

From report at bugs.python.org  Fri Nov 13 17:12:58 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Nov 2009 16:12:58 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1258128660.46.0.390865500646.issue7060@psf.upfronthosting.co.za>
Message-ID: <1258128788.3574.31.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:
> 
> Ok, I ported the change again in revision 76238, removing the traceback 
> from the stored exception object.

"versionchanged" should be 3.2, not 3.1.
Thanks!

----------

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

From report at bugs.python.org  Fri Nov 13 17:16:32 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 13 Nov 2009 16:16:32 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1258128992.06.0.997400339175.issue7060@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Thanks. Fixed in revision 76239.

----------

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

From report at bugs.python.org  Fri Nov 13 17:32:19 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Nov 2009 16:32:19 +0000
Subject: [issue6551] test_codecs fails when ran after test_zipimport and
	test_mailbox.
In-Reply-To: <1248318273.86.0.60176603488.issue6551@psf.upfronthosting.co.za>
Message-ID: <1258129939.19.0.609186072424.issue6551@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks. The patch is now committed in py3k and 3.1.

----------
resolution: accepted -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Nov 13 17:52:55 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 13 Nov 2009 16:52:55 +0000
Subject: [issue7314] test_multiprocessing hangs on Windows 7 64 bit
In-Reply-To: <1258131175.63.0.744980392566.issue7314@psf.upfronthosting.co.za>
Message-ID: <1258131175.63.0.744980392566.issue7314@psf.upfronthosting.co.za>


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

Running a debug python from the py3k branch on my windows 7 machine, 64 
bit, test_multiprocessing hangs in the _TestZZZNumberOfObjects test.

I don't know this module, but I did a little digging:
The main process is in the gc.collec() causing some manager object to 
call a _decref() method, which is initiating a socket connection to a 
child process (I presume.)  This is spinning endlessly because the 
connection is constantly refused.

The child processes don't have any sockets open (according to the 
resource monitor) and when I look at the state they are in, the are 
stuck waiting for a ReadFile to succeed.  The python traceback appears 
to be (innermost first, line numbers approximate:)
queues.py:349
pool.py:45
process.py:83
process.py:215
forking.py:326

----------
components: Tests
keywords: 64bit
messages: 95186
nosy: krisvale
severity: normal
status: open
title: test_multiprocessing hangs on Windows 7 64 bit
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Nov 13 18:00:31 2009
From: report at bugs.python.org (Michael K Johnson)
Date: Fri, 13 Nov 2009 17:00:31 +0000
Subject: [issue1160] Medium size regexp crashes python
In-Reply-To: <1189670456.94.0.669298411185.issue1160@psf.upfronthosting.co.za>
Message-ID: <1258131631.9.0.452971331396.issue1160@psf.upfronthosting.co.za>


Michael K Johnson <a1237+pybugs at danlj.org> added the comment:

I also ran into this issue, and dealt with it as suggested here by
changing to sets.  Because I have underlying code that has to deal both
with small hand-crafted regular expressions and arbitrarily-large
machine-generated sets of paths, I subclassed set and implemented the
match and search methods in my subclass so that the underlying code
would work both against the hand-generated regular expressions and the
machine-generated sets of paths.  Hope this helps someone else who runs
into this restriction.

----------
nosy: +johnsonm

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

From report at bugs.python.org  Fri Nov 13 18:04:41 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Nov 2009 17:04:41 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1258131881.53.0.766444495172.issue7060@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't know if it's your last change, but test_multiprocessing is now
hanging on all buildbots.

----------

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

From report at bugs.python.org  Fri Nov 13 18:05:15 2009
From: report at bugs.python.org (James)
Date: Fri, 13 Nov 2009 17:05:15 +0000
Subject: [issue7315] os.path.normpath doesn't normalize ../path/something.py
In-Reply-To: <1258131915.3.0.590815402917.issue7315@psf.upfronthosting.co.za>
Message-ID: <1258131915.3.0.590815402917.issue7315@psf.upfronthosting.co.za>


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

os.path.normpath doesn't normalize paths that start with ../
you would expect the final output line in the secpnd run to read:
"normpath: badnormpath.py" instead of: "normpath: ../tmp/badnormpath.py"

example:

james at home:~$ cd tmp/
james at home:~/tmp$ cat badnormpath.py 
#!/usr/bin/python

import os.path

print '__file__: %s' % __file__
print 'normpath: %s' % os.path.normpath(__file__)

james at home:~/tmp$ ./badnormpath.py 
__file__: ./badnormpath.py
normpath: badnormpath.py
james at home:~/tmp$ ./../tmp/badnormpath.py 
__file__: ./../tmp/badnormpath.py
normpath: ../tmp/badnormpath.py
james at home:~/tmp$

----------
components: Library (Lib)
messages: 95189
nosy: purpleidea
severity: normal
status: open
title: os.path.normpath doesn't normalize ../path/something.py
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0

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

From report at bugs.python.org  Fri Nov 13 18:26:17 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Nov 2009 17:26:17 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1258133177.62.0.800676828142.issue7060@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It is.  TestZZZNumberOfObjects hangs at r76238, and does not hang at
r76239 on my Gentoo Linux box.

----------

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

From report at bugs.python.org  Fri Nov 13 18:28:21 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Nov 2009 17:28:21 +0000
Subject: [issue7314] test_multiprocessing hangs on Windows 7 64 bit
In-Reply-To: <1258131175.63.0.744980392566.issue7314@psf.upfronthosting.co.za>
Message-ID: <1258133301.63.0.46950951189.issue7314@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See issue 7060.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Fri Nov 13 18:31:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Nov 2009 17:31:48 +0000
Subject: [issue7316] Add a timeout functionality to common locking operations
In-Reply-To: <1258133508.5.0.728130823639.issue7316@psf.upfronthosting.co.za>
Message-ID: <1258133508.5.0.728130823639.issue7316@psf.upfronthosting.co.za>


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

Here is a patch which adds a timeout feature to the locking operations
provided by Python. This feature is added at two levels:
- the C API level, with a new function PyThread_acquire_lock_timed()
- the Python level, with an optional `timeout` argument to the acquire()
method of Lock and RLock objects (it also helps simplify the wait()
function of Condition objects)

The timeout duration is expressed in microseconds at the C API level,
and in seconds at the Python API level. There is also a new Python-level
constant, `_thread.TIMEOUT_MAX`, indicating the max allowable timeout
value (values above this raise an OverflowError).

At the C level, the max timeout is PY_TIMEOUT_MAX (in microseconds). The
caller should check the value him/herself.

The patch contains both a POSIX implementation and a Windows
implementation. It still lacks docs.

----------
components: Interpreter Core, Library (Lib)
files: timedlock.patch
keywords: patch
messages: 95192
nosy: gps, pitrou
priority: normal
severity: normal
status: open
title: Add a timeout functionality to common locking operations
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file15321/timedlock.patch

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

From report at bugs.python.org  Fri Nov 13 18:32:36 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Nov 2009 17:32:36 +0000
Subject: [issue7314] test_multiprocessing hangs in TestZZZNumberOfObjects
	after unittest traceback patch
In-Reply-To: <1258131175.63.0.744980392566.issue7314@psf.upfronthosting.co.za>
Message-ID: <1258133556.0.0.48722011746.issue7314@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords: +buildbot -64bit
priority:  -> high
title: test_multiprocessing hangs on Windows 7 64 bit -> test_multiprocessing hangs in TestZZZNumberOfObjects after unittest traceback patch

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

From report at bugs.python.org  Fri Nov 13 18:34:35 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Nov 2009 17:34:35 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1258133675.65.0.195439642881.issue7060@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------

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

From report at bugs.python.org  Fri Nov 13 18:34:59 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Nov 2009 17:34:59 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1258133699.08.0.312868269385.issue7060@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It is.  TestZZZNumberOfObjects hangs at r76237, and does not hang at
r76238 on my Gentoo Linux box.

----------

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

From report at bugs.python.org  Fri Nov 13 18:35:22 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Nov 2009 17:35:22 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1258133722.93.0.37398695022.issue7060@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------

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

From report at bugs.python.org  Fri Nov 13 18:35:41 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Nov 2009 17:35:41 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1258133741.07.0.720665560251.issue7060@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It is.  TestZZZNumberOfObjects hangs at r76238, and does not hang at
r76237 on my Gentoo Linux box.

----------

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

From report at bugs.python.org  Fri Nov 13 18:39:28 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Nov 2009 17:39:28 +0000
Subject: [issue7105] weak dict iterators are fragile because of unpredictable
	GC runs
In-Reply-To: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za>
Message-ID: <1258133968.05.0.271551402487.issue7105@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file15103/weakiter.patch

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

From report at bugs.python.org  Fri Nov 13 18:39:30 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Nov 2009 17:39:30 +0000
Subject: [issue7105] weak dict iterators are fragile because of unpredictable
	GC runs
In-Reply-To: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za>
Message-ID: <1258133970.57.0.719170280266.issue7105@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file15112/weakiter2.patch

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

From report at bugs.python.org  Fri Nov 13 19:04:35 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Nov 2009 18:04:35 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1258135475.59.0.679735485489.issue7060@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It seems the error is different, though. This is what I get after Ctrl-C
(I omit the tracebacks from the other processes):

Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_multiprocessing.py",
line 1071, in test_number_of_objects
    refs = self.manager._number_of_objects()
  File "Z:\py3k\__svn__\lib\multiprocessing\managers.py", line 569, in
_number_of_objects
    conn = self._Client(self._address, authkey=self._authkey)
  File "Z:\py3k\__svn__\lib\multiprocessing\connection.py", line 134, in
Client
    c = SocketClient(address)
  File "Z:\py3k\__svn__\lib\multiprocessing\connection.py", line 253, in
SocketClient
    s.connect(address)
socket.error: [Errno 2] No such file or directory

----------

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

From report at bugs.python.org  Fri Nov 13 20:04:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Nov 2009 19:04:48 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1258139088.15.0.354485050055.issue7060@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, the problem is that a finalizer calls _decref which tries to open an
XMLRPC connection (!) to an address on which nobody listens anymore.
Then stupid SocketClient (in multiprocessing.connection) loops endlessly
because it is designed to do so when it gets ECONNREFUSED.

(when you Ctrl-C, you don't see all this because it happens in a
finalizer, and only a terse message is displayed)

So there are two problems:
- why does test_multiprocessing think it should open an XMLRPC
connection to a closed endpoint
- why doesn't SocketClient have some kind of timeout rather than looping
stupidly

----------

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

From report at bugs.python.org  Fri Nov 13 20:23:35 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Nov 2009 19:23:35 +0000
Subject: [issue7317] Display full tracebacks when an error occurs
	asynchronously
In-Reply-To: <1258140215.22.0.835793798885.issue7317@psf.upfronthosting.co.za>
Message-ID: <1258140215.22.0.835793798885.issue7317@psf.upfronthosting.co.za>


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

When an exception is raised in a __del__ method or a finalizer (i.e. a
weakref callback), only the exception name is printed out.
Unfortunately, arbitrarily complex code can be involved which makes
debugging quite tedious. It would be nice to display the full traceback
so that these errors are easier to diagnose (see issue7060 as an example).

----------
components: Interpreter Core, Library (Lib)
messages: 95197
nosy: pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: Display full tracebacks when an error occurs asynchronously
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Nov 13 20:28:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Nov 2009 19:28:54 +0000
Subject: [issue7318] multiprocessing should not wait endlessly
In-Reply-To: <1258140534.04.0.0239961207692.issue7318@psf.upfronthosting.co.za>
Message-ID: <1258140534.04.0.0239961207692.issue7318@psf.upfronthosting.co.za>


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

SocketClient() in multiprocessing.connection loops endlessly when the
connection is refused. It shouldn't, and instead use a timeout.
This is especially annoying since SocketClient() can be called as part
of finalizing an object, which makes debugging very annoying (see
issue7060).

----------
assignee: jnoller
components: Library (Lib)
messages: 95198
nosy: jnoller, pitrou
priority: critical
severity: normal
stage: needs patch
status: open
title: multiprocessing should not wait endlessly
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Nov 13 20:29:14 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Nov 2009 19:29:14 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1258140554.97.0.100163902057.issue7060@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
dependencies: +multiprocessing should not wait endlessly

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

From report at bugs.python.org  Fri Nov 13 21:27:38 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 13 Nov 2009 20:27:38 +0000
Subject: [issue7315] os.path.normpath doesn't normalize ../path/something.py
In-Reply-To: <1258131915.3.0.590815402917.issue7315@psf.upfronthosting.co.za>
Message-ID: <1258144058.42.0.108306239041.issue7315@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

normpath() doesn't look at the file system.  It cannot know that your
current directory is ~/tmp, so it cannot know that . and ../tmp are the
same directory.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Fri Nov 13 22:15:47 2009
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 13 Nov 2009 21:15:47 +0000
Subject: [issue7301] Add environment variable $PYTHONWARNINGS
In-Reply-To: <1257865531.11.0.841786263832.issue7301@psf.upfronthosting.co.za>
Message-ID: <1258146947.42.0.680365414173.issue7301@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I attached a patch against trunk r76237 which seems to cover this, sans
official tests. I looked around and didn't find a good place for
specifically testing environment variables. I could add test code in
test_warnings if that's the best place.

The patch allows multiple warnings to be passed to the environment
variable as a comma separated string, and works in conjunction with -W.

Let me know what you think.

----------
keywords: +patch
nosy: +brian.curtin
Added file: http://bugs.python.org/file15322/issue7301.patch

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

From report at bugs.python.org  Fri Nov 13 22:23:37 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Nov 2009 21:23:37 +0000
Subject: [issue7302] Wrong link to Python Language Mapping Specification
In-Reply-To: <1257878367.72.0.0298687588938.issue7302@psf.upfronthosting.co.za>
Message-ID: <1258147417.14.0.688845681997.issue7302@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The proper link for this issue is to the top of the file:
http://docs.python.org/library/xml.dom.html
and the See Also section under that.

The current link is dead: 404
The proposed link seems correct as its title is the same as the link
title: Python Language Mapping Specification and it is the most recent
publicly available. So I concur with the proposed change.

----------
nosy: +tjreedy

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

From report at bugs.python.org  Fri Nov 13 22:28:42 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Fri, 13 Nov 2009 21:28:42 +0000
Subject: [issue7301] Add environment variable $PYTHONWARNINGS
In-Reply-To: <1257865531.11.0.841786263832.issue7301@psf.upfronthosting.co.za>
Message-ID: <1258147722.07.0.544897335306.issue7301@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

test_warnings is probably the best place since test_cmd_line ignores 
environment variables

----------

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

From report at bugs.python.org  Fri Nov 13 22:39:12 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 13 Nov 2009 21:39:12 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1258148352.48.0.131590081453.issue7060@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Yes, this is quite different.
After seeing this, I created issue 7314.
I didn't realize that it had anything to do with my patch but rather 
blamed it on my brand new windows 7.

----------

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

From report at bugs.python.org  Fri Nov 13 22:41:26 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Nov 2009 21:41:26 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1258148352.48.0.131590081453.issue7060@psf.upfronthosting.co.za>
Message-ID: <1258148496.3574.49.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Yes, this is quite different.
> After seeing this, I created issue 7314.
> I didn't realize that it had anything to do with my patch but rather 
> blamed it on my brand new windows 7.

I don't think it has anything to do with your patch. While diagnosing
the problem, I noticed that adding some random print() lines would
sometimes make the problem disappear. So it is really timing-dependent
and your patch happens to trigger the right (or wrong ;-)) timing.

----------

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

From report at bugs.python.org  Fri Nov 13 22:42:48 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 13 Nov 2009 21:42:48 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1258148568.31.0.470634088489.issue7060@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

See my analysis from issue 7314:
The other processes are all waiting to ReadFile().  Maybe they have yet 
to run to the point where they open the socket to which the master 
process is trying to connect to.

The mystery is also: Why does the harmless act of setting an instance 
attribute on a context manager (and without any traceback) trigger this 
behaviour?

----------

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

From report at bugs.python.org  Fri Nov 13 22:44:05 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 13 Nov 2009 21:44:05 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1258148645.36.0.292535134578.issue7060@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Ah, okay then.  Let's focus on solving 7414 then.

----------

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

From report at bugs.python.org  Fri Nov 13 22:44:36 2009
From: report at bugs.python.org (James)
Date: Fri, 13 Nov 2009 21:44:36 +0000
Subject: [issue7315] os.path.normpath doesn't normalize ../path/something.py
In-Reply-To: <1258131915.3.0.590815402917.issue7315@psf.upfronthosting.co.za>
Message-ID: <1258148676.37.0.651038624953.issue7315@psf.upfronthosting.co.za>


James <purpleidea at gmail.com> added the comment:

i looked at the source for normpath.
i know that it doesn't look at the filesystem.
assuming you're not currently sitting at the root directory, in all? 
cases ../xyz brings you back to where you started. we expect normpath to 
clean up a path string, collapsing '../' (as documented), perhaps either 
the docs should state otherwise, or this should collapse dirs as long as 
they are present in the path given to it ?

as an aside is there any reason why normpath shouldn't look at the 
filesystem and decide if it makes sense to collapse a leading '../' when 
this case arises ?

----------

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

From report at bugs.python.org  Fri Nov 13 23:06:31 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Nov 2009 22:06:31 +0000
Subject: [issue7318] multiprocessing should not wait endlessly
In-Reply-To: <1258140534.04.0.0239961207692.issue7318@psf.upfronthosting.co.za>
Message-ID: <1258149991.56.0.986745602556.issue7318@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Please review.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file15323/mptimeout.patch

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

From report at bugs.python.org  Fri Nov 13 23:09:07 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 13 Nov 2009 22:09:07 +0000
Subject: [issue7318] multiprocessing should not wait endlessly
In-Reply-To: <1258140534.04.0.0239961207692.issue7318@psf.upfronthosting.co.za>
Message-ID: <1258150147.75.0.107855384922.issue7318@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Patch seems fine, going to test it against trunk locally

----------

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

From report at bugs.python.org  Fri Nov 13 23:10:21 2009
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 13 Nov 2009 22:10:21 +0000
Subject: [issue7301] Add environment variable $PYTHONWARNINGS
In-Reply-To: <1257865531.11.0.841786263832.issue7301@psf.upfronthosting.co.za>
Message-ID: <1258150221.44.0.426025633697.issue7301@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Added a patch which includes tests in test_warnings. There are tests for
a single warning, two comma separated warnings, and one env var warning
and one command line warning at the same time.

----------
Added file: http://bugs.python.org/file15324/issue7301_v2.patch

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

From report at bugs.python.org  Fri Nov 13 23:17:20 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 13 Nov 2009 22:17:20 +0000
Subject: [issue7298] reversed(range(x, -1, -1)) is empty when x > 1
In-Reply-To: <1257848858.69.0.270094372501.issue7298@psf.upfronthosting.co.za>
Message-ID: <1258150640.39.0.142281718709.issue7298@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for reviewing, Eric.  I'll work a bit more on the tests.

I'm also not sure what to do about 2.x:  here reversed(xrange(start, 
stop, step)) has some of the same problems for large numbers. (E.g., if 
step == LONG_MIN.)

The options are: (1) have reversed(x) raise ValueError for some extreme 
xrange instances x, or (2) rework the internals so that reversed(x) 
always works.

Given that this is a bugfix, I'm inclined to go for (1) for now;  we can 
always look at reworking xrange later on, for 2.7 and 3.2.

----------

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

From report at bugs.python.org  Fri Nov 13 23:21:04 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 13 Nov 2009 22:21:04 +0000
Subject: [issue7318] multiprocessing should not wait endlessly
In-Reply-To: <1258140534.04.0.0239961207692.issue7318@psf.upfronthosting.co.za>
Message-ID: <1258150864.3.0.612042438969.issue7318@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Passes on OS/X 10.6.2, I'm ok with it

----------

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

From report at bugs.python.org  Fri Nov 13 23:37:58 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 13 Nov 2009 22:37:58 +0000
Subject: [issue7298] reversed(range(x, -1, -1)) is empty when x > 1
In-Reply-To: <1257848858.69.0.270094372501.issue7298@psf.upfronthosting.co.za>
Message-ID: <1258151878.8.0.63125114547.issue7298@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

For 2.x, I'd just raise an exception. No one is going to be using a step
of LONG_MIN.

----------

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

From report at bugs.python.org  Fri Nov 13 23:38:21 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 13 Nov 2009 22:38:21 +0000
Subject: [issue7286] odd exec() behavior or documentation
In-Reply-To: <1257662346.28.0.188136963391.issue7286@psf.upfronthosting.co.za>
Message-ID: <1258151901.88.0.456111918187.issue7286@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This is a largely inevitable consequence of the conversion from a
statement to a function - the interpreter eval loop for the exec
statement used to do some fancy footwork to make locals() modifications
work, but with exec becoming just another builtin function that special
casing is gone.

Accordingly, in 3.x, exec() is dependent on the implementation defined
behaviour of locals(), just like all other code. (The upside to this is
that it means the compiler always knows the identity of all local
variables).

I have no idea how well this change has been documented though (to be
honest, I'd forgotten that exec had been converted to a function for 3.x)

----------
components:  -Interpreter Core
nosy: +ncoghlan

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

From report at bugs.python.org  Fri Nov 13 23:40:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Nov 2009 22:40:43 +0000
Subject: [issue7318] multiprocessing should not wait endlessly
In-Reply-To: <1258140534.04.0.0239961207692.issue7318@psf.upfronthosting.co.za>
Message-ID: <1258152043.07.0.228664540788.issue7318@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, this is now committed to all 4 branches. Amusingly, it seems to
solve the test_multiprocessing freeze/failure problem in py3k...
(I still hope you can find some time to make multiprocessing more robust
and less baroque inside!)

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Nov 13 23:43:40 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 13 Nov 2009 22:43:40 +0000
Subject: [issue7318] multiprocessing should not wait endlessly
In-Reply-To: <1258152043.07.0.228664540788.issue7318@psf.upfronthosting.co.za>
Message-ID: <B4168335-85AF-48F4-9359-B0E2323DC960@gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

On Nov 13, 2009, at 5:40 PM, Antoine Pitrou <report at bugs.python.org>  
wrote:

>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Ok, this is now committed to all 4 branches. Amusingly, it seems to
> solve the test_multiprocessing freeze/failure problem in py3k...
> (I still hope you can find some time to make multiprocessing more  
> robust
> and less baroque inside!)
>

So do I and I'm sorry I haven't been able to yet. First on my list is  
a total test suite scrub.

----------

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

From report at bugs.python.org  Fri Nov 13 23:57:03 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 13 Nov 2009 22:57:03 +0000
Subject: [issue7313] 2to3 fails when source file starts with BOM
In-Reply-To: <1258113728.92.0.380027022792.issue7313@psf.upfronthosting.co.za>
Message-ID: <1258153023.43.0.0632719961625.issue7313@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r76250.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sat Nov 14 00:58:07 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Nov 2009 23:58:07 +0000
Subject: [issue7312] Run some tests in a loop until failure
In-Reply-To: <1258070307.12.0.876277765966.issue7312@psf.upfronthosting.co.za>
Message-ID: <1258156687.0.0.654094709585.issue7312@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you, here is an update patch.

----------
Added file: http://bugs.python.org/file15325/looptests2.patch

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

From report at bugs.python.org  Sat Nov 14 01:08:45 2009
From: report at bugs.python.org (David Bolen)
Date: Sat, 14 Nov 2009 00:08:45 +0000
Subject: [issue7293] test_msvc9compiler test_reg_class failure on new Windows
	box
In-Reply-To: <1257750000.16.0.245083157049.issue7293@psf.upfronthosting.co.za>
Message-ID: <1258157325.99.0.88683960005.issue7293@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

Since I was feeling bad for the Windows 7 build slave not being able to
pass the tests due to this (at least when other tests weren't failing),
I manually added a matching key on the slave pending any test changes.

In looking around, since this test is specifically part of the
msvc9compiler test module, thus presumably we know that VC9 (VS2008) is
installed, how about a key that is VC9 specific?  It would appear that
"HKCU\Software\Microsoft\VisualStudio\9.0\VC\Build Timing" (DWORD,
default 0) is present on a brand new VS 2008 install.  It's also present
in both the full VS version as well as express.

If the test also needs to support VC8 (VS2005), the same key is present
but under "8.0" rather than "9.0" so the test would need to pass if
either worked.

(Oh, and a correction to my last comment about HKCU - I missed that the
Reg.get_value() in the failing part of the test checks multiple roots,
not just HKCU).

----------

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

From report at bugs.python.org  Sat Nov 14 01:15:53 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 14 Nov 2009 00:15:53 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>


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

This issue is to track the silencing of DeprecationWarning by default.

To start a patch has been attached against trunk which silences 
DeprecationWarning. Documentation changes are still needed, though.

----------
components: Interpreter Core
files: silence_deprecations.diff
keywords: patch
messages: 95220
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Silence DeprecationWarning by default
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15326/silence_deprecations.diff

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

From report at bugs.python.org  Sat Nov 14 01:34:21 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 14 Nov 2009 00:34:21 +0000
Subject: [issue1160] Medium size regexp crashes python
In-Reply-To: <1189670456.94.0.669298411185.issue1160@psf.upfronthosting.co.za>
Message-ID: <1258158861.42.0.555701583901.issue1160@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Michael, can you provide the regex or even better a testcase that shows
the problem?

----------
stage:  -> test needed

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

From report at bugs.python.org  Sat Nov 14 01:38:20 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 14 Nov 2009 00:38:20 +0000
Subject: [issue6450] normpath() sometimes maps unicode to str
In-Reply-To: <1247165396.23.0.921821362773.issue6450@psf.upfronthosting.co.za>
Message-ID: <1258159100.37.0.54666263995.issue6450@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Closing this as duplicate of #5827.

----------
resolution:  -> duplicate
stage: test needed -> committed/rejected
status: open -> closed
superseder:  -> os.path.normpath doesn't preserve unicode

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

From report at bugs.python.org  Sat Nov 14 02:10:36 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 14 Nov 2009 01:10:36 +0000
Subject: [issue5827] os.path.normpath doesn't preserve unicode
In-Reply-To: <1240547039.35.0.461990786151.issue5827@psf.upfronthosting.co.za>
Message-ID: <1258161036.75.0.074690495936.issue5827@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Thanks for the patch, I tried it on Linux and it seems to solve the problem.

A few comments about it:
1) I'd change all the self.assertEqual(type(posixpath.normpath(u"")),
unicode) to self.assertTrue(isinstance(posixpath.normpath(u""), unicode));
2) a test for normpath(u'.') should probably be added;
3) in ntpath.py the 'slash' is actually a backslash, so the name of the
var should be changed;

----------
nosy: +ezio.melotti, kcwu, loewis, sandberg
priority:  -> normal
stage:  -> patch review

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

From report at bugs.python.org  Sat Nov 14 02:23:19 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 14 Nov 2009 01:23:19 +0000
Subject: [issue7311] Bug on regexp of HTMLParser
In-Reply-To: <1258043150.41.0.372876851796.issue7311@psf.upfronthosting.co.za>
Message-ID: <1258161799.23.0.950341216445.issue7311@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> test needed
versions: +Python 2.7

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

From report at bugs.python.org  Sat Nov 14 02:34:59 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 14 Nov 2009 01:34:59 +0000
Subject: [issue7310] Unhelpful __repr__() in os.environ
In-Reply-To: <1258026841.53.0.960128215471.issue7310@psf.upfronthosting.co.za>
Message-ID: <1258162499.48.0.460682779204.issue7310@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here is a patch against py3k.

----------
assignee:  -> ezio.melotti
keywords: +easy, patch
nosy: +ezio.melotti
priority:  -> normal
stage:  -> patch review
versions: +Python 3.2
Added file: http://bugs.python.org/file15327/issue7310.diff

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

From report at bugs.python.org  Sat Nov 14 03:06:46 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 14 Nov 2009 02:06:46 +0000
Subject: [issue7309] crasher in str(Exception())
In-Reply-To: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>
Message-ID: <1258164406.17.0.128946008489.issue7309@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I don't know if this is a real problem. If someone who want to crash
someone else program is able to do something like 'u.reason =
somethingweird' there are already more serious problems to solve.
I don't see why someone would want to do that in his own program either.

So, even assuming that PyString_AS_STRING() might indeed crash when some
weird arg is passed, the problem should be fixed there and not
typechecking all the args before calling it. (i.e. even if you fix it
for Exceptions, there are probably several other places where you can
set arbitrary things that will be passed to PyString_AS_STRING() anyway.)

That said, I played with it and tried to set u.reason with a number of
things (including big numbers and strings, Unicode chars outside the
BMP, builtin types, functions, modules) and str(u) either returned an
empty string or a random sequence of bytes (like your 'E\x03'), but it
didn't crash.

Unless you can find a way to make it crash, I'd close this as 'invalid'.

----------
nosy: +ezio.melotti
priority:  -> low
stage:  -> test needed

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

From report at bugs.python.org  Sat Nov 14 03:09:07 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 14 Nov 2009 02:09:07 +0000
Subject: [issue7300] Unicode arguments in str.format()
In-Reply-To: <1257861455.06.0.0846130484851.issue7300@psf.upfronthosting.co.za>
Message-ID: <1258164547.25.0.161378988018.issue7300@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
priority:  -> high
stage:  -> test needed
versions: +Python 2.7

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

From report at bugs.python.org  Sat Nov 14 03:09:22 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 14 Nov 2009 02:09:22 +0000
Subject: [issue7310] Unhelpful __repr__() in os.environ
In-Reply-To: <1258026841.53.0.960128215471.issue7310@psf.upfronthosting.co.za>
Message-ID: <1258164562.4.0.545290030123.issue7310@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +needs review

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

From report at bugs.python.org  Sat Nov 14 04:54:25 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Nov 2009 03:54:25 +0000
Subject: [issue7312] Run some tests in a loop until failure
In-Reply-To: <1258070307.12.0.876277765966.issue7312@psf.upfronthosting.co.za>
Message-ID: <1258170865.55.0.571878220979.issue7312@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I still get:

ValueError: No JSON object could be decoded

in one or more of the threads when I hit ctl-c during a -j run.

I've attached an updated patch that fixes the problem, but I'm not sure
it is a correct fix.

----------
Added file: http://bugs.python.org/file15328/looptests3.patch

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

From report at bugs.python.org  Sat Nov 14 05:30:29 2009
From: report at bugs.python.org (David Bolen)
Date: Sat, 14 Nov 2009 04:30:29 +0000
Subject: [issue7320] Unable to load external modules on build slave with debug
	python
In-Reply-To: <1258173028.92.0.517735390444.issue7320@psf.upfronthosting.co.za>
Message-ID: <1258173028.92.0.517735390444.issue7320@psf.upfronthosting.co.za>


New submission from David Bolen <db3l.net at gmail.com>:

As I mentioned in a recent python-dev post, I've noticed that the
Windows build slaves are skipping tests of external modules (like ssl
and bz2).

After finding an old 2.6a0 tree that I had locally built where things
worked fine, I stepped through some 2.6 tags and discovered that this
broke between 2.6 and 2.6.1

The problem appears to be the the change in r67121 for 2.6 (67120 in
trunk) from Nov, 2008 that removed the embedded manifest.  With that
change, you can't import the external modules from python_d in PCBuild,
so the tests will skip.  Reverting just that change, even on the 2.6.1
source tree, and importing works fine.

So I don't think the external module tests have been running on the
Windows build slave since late 2008.

I tried creating some external manifest files, but haven't been able to
work around the problem so far.  Perhaps embedded manifests could be
permitted in debug mode and/or when building for buildbot?

----------
components: Build, Windows
messages: 95227
nosy: db3l
severity: normal
status: open
title: Unable to load external modules on build slave with debug python

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

From report at bugs.python.org  Sat Nov 14 07:24:34 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 14 Nov 2009 06:24:34 +0000
Subject: [issue7309] crasher in str(Exception())
In-Reply-To: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>
Message-ID: <1258179874.03.0.273567090173.issue7309@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

After further investigations I found out that PyString_AS_STRING() is
the macro form of PyString_AsString() but without error checking (so
there's nothing to fix there, possibly just replace that call with
PyString_AsString if it turns out to be a real problem).
I think that what I said in the first paragraph of my previous message
is still true though, and that might be the reason why they preferred
PyString_AS_STRING() in the first place.

----------

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

From report at bugs.python.org  Sat Nov 14 10:08:49 2009
From: report at bugs.python.org (Damian Eads)
Date: Sat, 14 Nov 2009 09:08:49 +0000
Subject: [issue7321] PyIter_Check(obj) fails when obj is of type PySetType
In-Reply-To: <1258189729.02.0.287684022873.issue7321@psf.upfronthosting.co.za>
Message-ID: <1258189729.02.0.287684022873.issue7321@psf.upfronthosting.co.za>


New submission from Damian Eads <damian.eads at gmail.com>:

The instructions for the C interface to the Python set class

  http://docs.python.org/c-api/set.html

say to use PyObject_GetIter and follow the iterator protocol. After
following the instructions for the iterator protocol here,

  http://docs.python.org/c-api/iter.html

I was able to successfully iterate through a set object. However,
PyIter_Check(obj) returns false yet set objects follow the iterator
protocol. Is this the correct behavior?

Thank you.

Kind regards,

Damian Eads

----------
messages: 95229
nosy: damianeads
severity: normal
status: open
title: PyIter_Check(obj) fails when obj is of type PySetType
versions: Python 2.6

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

From report at bugs.python.org  Sat Nov 14 10:14:02 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 14 Nov 2009 09:14:02 +0000
Subject: [issue7320] Unable to load external modules on build slave with debug
	python
In-Reply-To: <1258173028.92.0.517735390444.issue7320@psf.upfronthosting.co.za>
Message-ID: <1258190042.7.0.268919889072.issue7320@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
nosy: +loewis

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

From report at bugs.python.org  Sat Nov 14 11:18:03 2009
From: report at bugs.python.org (Trundle)
Date: Sat, 14 Nov 2009 10:18:03 +0000
Subject: [issue7309] crasher in str(Exception())
In-Reply-To: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>
Message-ID: <1258193883.37.0.172397511351.issue7309@psf.upfronthosting.co.za>


Trundle <andy-python at hammerhartes.de> added the comment:

Crashes reliable with a segfault in Python 3.1.1.

Fixing the setter so that one can only set strings and not arbitrary 
objects is possibly the best solution.

----------
nosy: +Trundle
versions: +Python 3.1

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

From report at bugs.python.org  Sat Nov 14 11:44:06 2009
From: report at bugs.python.org (jasper)
Date: Sat, 14 Nov 2009 10:44:06 +0000
Subject: [issue7296] OverflowError: signed integer is greater than maximum on
	mips64
In-Reply-To: <1257807734.54.0.518943570242.issue7296@psf.upfronthosting.co.za>
Message-ID: <1258195446.15.0.767781775402.issue7296@psf.upfronthosting.co.za>


jasper <jasper at humppa.nl> added the comment:

Removing --with-fpectl makes no difference.

I'll try the _PyHash_Double-thing later this weekend.

----------

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

From report at bugs.python.org  Sat Nov 14 11:49:21 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 14 Nov 2009 10:49:21 +0000
Subject: [issue7309] crasher in str(Exception())
In-Reply-To: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>
Message-ID: <1258195761.98.0.30363265732.issue7309@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I'm not sure why reason should be restricted to a string. This patch
(against trunk) just converts reason to a string when str() is called.
I'll add tests and fix the other places in exceptions.c where similar
shortcuts are taken without checking, if there's agreement on the approach.

----------
assignee:  -> eric.smith
nosy: +eric.smith
priority: low -> high
stage: test needed -> patch review
type:  -> crash
versions: +Python 2.6, Python 3.2

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

From report at bugs.python.org  Sat Nov 14 11:54:39 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 14 Nov 2009 10:54:39 +0000
Subject: [issue7309] crasher in str(Exception())
In-Reply-To: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>
Message-ID: <1258196079.05.0.336401314753.issue7309@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Actually attach the patch.

----------

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

From report at bugs.python.org  Sat Nov 14 11:56:41 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 14 Nov 2009 10:56:41 +0000
Subject: [issue7309] crasher in str(Exception())
In-Reply-To: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>
Message-ID: <1258196201.98.0.738580808905.issue7309@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

One more time with the patch attachment.

----------

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

From report at bugs.python.org  Sat Nov 14 11:59:29 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 14 Nov 2009 10:59:29 +0000
Subject: [issue7309] crasher in str(Exception())
In-Reply-To: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>
Message-ID: <1258196369.75.0.556817432047.issue7309@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------

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

From report at bugs.python.org  Sat Nov 14 11:59:35 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 14 Nov 2009 10:59:35 +0000
Subject: [issue7309] crasher in str(Exception())
In-Reply-To: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>
Message-ID: <1258196375.76.0.561971677225.issue7309@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------

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

From report at bugs.python.org  Sat Nov 14 12:04:49 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 14 Nov 2009 11:04:49 +0000
Subject: [issue7309] crasher in str(Exception())
In-Reply-To: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>
Message-ID: <1258196689.99.0.798819726162.issue7309@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

For some reason I'm not able to attach the patch file. I'll look at
that, but in the meantime here's the preliminary patch against trunk:
Index: Objects/exceptions.c
===================================================================
--- Objects/exceptions.c        (revision 76258)
+++ Objects/exceptions.c        (working copy)
@@ -1779,7 +1779,13 @@
 UnicodeTranslateError_str(PyObject *self)
 {
     PyUnicodeErrorObject *uself = (PyUnicodeErrorObject *)self;
+    PyObject *result = NULL;
+    PyObject *reason_str = NULL;
 
+    reason_str = PyObject_Str(uself->reason);
+    if (reason_str == NULL)
+        goto done;
+
     if (uself->end==uself->start+1) {
         int badchar =
(int)PyUnicode_AS_UNICODE(uself->object)[uself->start];
         char badchar_str[20];
@@ -1789,19 +1795,22 @@
             PyOS_snprintf(badchar_str, sizeof(badchar_str), "u%04x",
badchar);
         else
             PyOS_snprintf(badchar_str, sizeof(badchar_str), "U%08x",
badchar);
-        return PyString_FromFormat(
+        result = PyString_FromFormat(
             "can't translate character u'\\%s' in position %zd: %.400s",
             badchar_str,
             uself->start,
-            PyString_AS_STRING(uself->reason)
+            PyString_AS_STRING(reason_str)
         );
-    }
-    return PyString_FromFormat(
-        "can't translate characters in position %zd-%zd: %.400s",
-        uself->start,
-        uself->end-1,
-        PyString_AS_STRING(uself->reason)
-    );
+    } else
+        result = PyString_FromFormat(
+            "can't translate characters in position %zd-%zd: %.400s",
+            uself->start,
+            uself->end-1,
+            PyString_AS_STRING(reason_str)
+        );
+done:
+    Py_XDECREF(reason_str);
+    return result;
 }
 
 static PyTypeObject _PyExc_UnicodeTranslateError = {

----------

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

From report at bugs.python.org  Sat Nov 14 12:09:54 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 14 Nov 2009 11:09:54 +0000
Subject: [issue7298] reversed(range(x, -1, -1)) is empty when x > 1
In-Reply-To: <1257848858.69.0.270094372501.issue7298@psf.upfronthosting.co.za>
Message-ID: <1258196994.07.0.374659802407.issue7298@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It looks like the PyLong version of reverse is broken too:

>>> list(range(10**100, 10**100-2, -2))
[1000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000]
>>> list(reversed(range(10**100, 10**100-2, -2)))
[9999999999999999999999999999999999999999999999999999999999999999999999999
999999999999999999999999998]

----------

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

From report at bugs.python.org  Sat Nov 14 12:45:58 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 14 Nov 2009 11:45:58 +0000
Subject: [issue7315] os.path.normpath doesn't normalize ../path/something.py
In-Reply-To: <1258131915.3.0.590815402917.issue7315@psf.upfronthosting.co.za>
Message-ID: <1258199158.54.0.619853533023.issue7315@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

If your current directory is (e.g.) /home/user, then ../xyz will not
"bring you back" to it.  (xyz/.. would.)

----------

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

From report at bugs.python.org  Sat Nov 14 13:29:07 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 14 Nov 2009 12:29:07 +0000
Subject: [issue7309] crasher in str(Exception())
In-Reply-To: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>
Message-ID: <1258201747.8.0.369838581096.issue7309@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Note that on Py2.6, when, for example, a string is assigned to u.start
and u.end a TypeError is raised, and the value is then set to -1:
>>> u=UnicodeTranslateError(u'x', 1, 5, 'bah')
>>> u.start = 'foo'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: an integer is required
>>> u.end = 'bar'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: an integer is required
>>> str(u)
"can't translate characters in position -1--2: bah"
>>> u.start, u.end
(-1, -1)

Is it possible to change the values assigning an int (or even a float
that is then converted to int).

On py3k the behavior is different; as Trundle said, it segfaults easily,
and trying to change the value of u.start and u.end returns a different
error:
>>> u.start = 'foo'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Objects/longobject.c:441: bad argument to internal function


Also note that on both the versions there's no check on these values
either, it's easy to have a segfault doing this:
>>> u = UnicodeTranslateError(u'x', 1, 5, 'bah')
>>> u.start = 2**30
>>> u.end = 2**30+1
>>> str(u)

(if the char is only one, Python will try to read it and display it)

----------

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

From report at bugs.python.org  Sat Nov 14 13:44:25 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 14 Nov 2009 12:44:25 +0000
Subject: [issue7298] reversed(range(x, -1, -1)) is empty when x > 1
In-Reply-To: <1257848858.69.0.270094372501.issue7298@psf.upfronthosting.co.za>
Message-ID: <1258202665.65.0.303205990507.issue7298@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I've updated to patch to improve the tests, and fix the problems with the 
PyLong version of range.__reversed__.  (Also updated on Rietveld.)

----------
Added file: http://bugs.python.org/file15329/issue7298_v2.patch

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

From report at bugs.python.org  Sat Nov 14 14:42:34 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 14 Nov 2009 13:42:34 +0000
Subject: [issue7321] PyIter_Check(obj) fails when obj is of type PySetType
In-Reply-To: <1258189729.02.0.287684022873.issue7321@psf.upfronthosting.co.za>
Message-ID: <1258206154.88.0.485837122705.issue7321@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Set objects are iterable, they are not iterators themselves.
In other words, PyIter_Check() should return true when called with the
result of PyObject_GetIter() (but normally you don't need to check anyway).

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Sat Nov 14 14:54:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 14 Nov 2009 13:54:40 +0000
Subject: [issue7312] Run some tests in a loop until failure
In-Reply-To: <1258170865.55.0.571878220979.issue7312@psf.upfronthosting.co.za>
Message-ID: <1258206892.3427.0.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I've attached an updated patch that fixes the problem, but I'm not sure
> it is a correct fix.

Your patch looks fine to me.

----------

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

From report at bugs.python.org  Sat Nov 14 16:49:35 2009
From: report at bugs.python.org (Domen)
Date: Sat, 14 Nov 2009 15:49:35 +0000
Subject: [issue5672] Implement a way to change the python process name
In-Reply-To: <1238701084.1.0.0781987214897.issue5672@psf.upfronthosting.co.za>
Message-ID: <1258213775.44.0.438109416959.issue5672@psf.upfronthosting.co.za>


Changes by Domen <ielectric at gmail.com>:


----------
nosy: +iElectric

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

From report at bugs.python.org  Sat Nov 14 17:18:51 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Nov 2009 16:18:51 +0000
Subject: [issue7312] Run some tests in a loop until failure
In-Reply-To: <1258070307.12.0.876277765966.issue7312@psf.upfronthosting.co.za>
Message-ID: <1258215531.86.0.788547581805.issue7312@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed to trunk in r76260 and py3k in r76261.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed
type: behavior -> feature request

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

From report at bugs.python.org  Sat Nov 14 17:39:03 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 14 Nov 2009 16:39:03 +0000
Subject: [issue4683] urllib2.HTTPDigestAuthHandler fails on third hostname?
In-Reply-To: <1229523259.96.0.571468029932.issue4683@psf.upfronthosting.co.za>
Message-ID: <1258216743.36.0.184627209319.issue4683@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil

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

From report at bugs.python.org  Sat Nov 14 17:43:01 2009
From: report at bugs.python.org (Charles Cazabon)
Date: Sat, 14 Nov 2009 16:43:01 +0000
Subject: [issue6963] Add worker process lifetime to multiprocessing.Pool -
	patch included
In-Reply-To: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>
Message-ID: <1258216981.83.0.901180351616.issue6963@psf.upfronthosting.co.za>


Charles Cazabon <charlesc-python at pyropus.ca> added the comment:

Hi Jesse -- Any chance you'll be able to review this in time for it to
make it into trunk for the 2.7 alpha release?

Charles

----------

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

From report at bugs.python.org  Sat Nov 14 18:11:46 2009
From: report at bugs.python.org (Mats Kindahl)
Date: Sat, 14 Nov 2009 17:11:46 +0000
Subject: [issue7005] ConfigParser does not handle options without values
In-Reply-To: <1254032044.95.0.187935622211.issue7005@psf.upfronthosting.co.za>
Message-ID: <1258218706.81.0.366264717852.issue7005@psf.upfronthosting.co.za>


Mats Kindahl <mats at sun.com> added the comment:

So, what is the status on this?
Who needs to review it?
Is there anything I can do to get it accepted?
Do I need to make any changes (in addition to those already suggested
and done by fdrake)?

----------

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

From report at bugs.python.org  Sat Nov 14 18:16:33 2009
From: report at bugs.python.org (David M. Beazley)
Date: Sat, 14 Nov 2009 17:16:33 +0000
Subject: [issue7322] Socket timeout can cause file-like readline() method to
	lose data
In-Reply-To: <1258218993.08.0.764402701678.issue7322@psf.upfronthosting.co.za>
Message-ID: <1258218993.08.0.764402701678.issue7322@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

Consider a socket that has had a file-like wrapper placed around it 
using makefile()

# s is a socket created previously
f = s.makefile()

Now, suppose that this socket has had a timeout placed on it.

s.settimeout(15)

If you try to read data from f, but nothing is available. You'll 
eventually get a timeout. For example:

f.readline()   # Now, just wait
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File 
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/socket.
py", line 406, in readline
    data = self._sock.recv(self._rbufsize)
socket.timeout: timed out

However, now consider the case where you're reading a line of data, but 
the receiver has only received a partial line and it's waiting for the 
rest of the data to arrive.   For example, type this:

f.readline()

Now, go to the other end of the socket connection and send a buffer with 
no newline character.  For example, send the message "Hello".

Since no newline character has been received, the readline() method will 
eventually fail with a timeout as before.   However, if you now retry 
the read operation f.readline() and send more data such as the message 
"World\n", you'll find that the "Hello" message gets lost.  In other 
words, the repeated readline() operation discards any buffers 
corresponding to previously received line data and just returns the new 
data.

Admittedly this is a corner case, but you probably don't want data to be 
discarded on a TCP connection even if a timeout occurs.

Hope that makes some sense :-).  (It helps to try it out).

----------
components: Library (Lib)
messages: 95245
nosy: beazley
severity: normal
status: open
title: Socket timeout can cause file-like readline() method to lose data
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Nov 14 18:28:27 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 14 Nov 2009 17:28:27 +0000
Subject: [issue4722] _winreg.QueryValue fault while reading mangled registry
	values
In-Reply-To: <1229958391.62.0.85659959701.issue4722@psf.upfronthosting.co.za>
Message-ID: <1258219707.46.0.20779164672.issue4722@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

I've noticed this depends on the user privileges. When logged in as a 
normal user, I get the internal error as originally reported. When 
logged in as an administrator, there is no error and I get an empty 
string.

----------

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

From report at bugs.python.org  Sat Nov 14 18:48:12 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 14 Nov 2009 17:48:12 +0000
Subject: [issue6666] List of dirs to ignore in trace.py is applied only for
	the first file
In-Reply-To: <1249638615.65.0.163009414102.issue6666@psf.upfronthosting.co.za>
Message-ID: <1258220892.75.0.656375869562.issue6666@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
versions: +Python 3.1

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

From report at bugs.python.org  Sat Nov 14 19:22:44 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Nov 2009 18:22:44 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1258222964.26.0.735276193691.issue3892@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Failures still occur occasionally even with the timeout set to 60.  So
I've turned the check that is skipped on Windows from an assertion into
a warning only on all other platforms, since bsddb support isn't
actively maintained and is gone in py3k.  Fix applied to trunk in r76265
and 2.6 in r76267.

----------
components: +Tests
stage:  -> patch review
title: bsddb: test01_basic_replication fails on Windows sometimes -> bsddb: test01_basic_replication fails sometimes
type:  -> behavior

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

From report at bugs.python.org  Sat Nov 14 19:39:20 2009
From: report at bugs.python.org (Adam Tomjack)
Date: Sat, 14 Nov 2009 18:39:20 +0000
Subject: [issue7323] decimal.Decimal greater than/less than sometimes gives
	wrong answers when comparing to floats.
In-Reply-To: <1258223960.66.0.3588708996.issue7323@psf.upfronthosting.co.za>
Message-ID: <1258223960.66.0.3588708996.issue7323@psf.upfronthosting.co.za>


New submission from Adam Tomjack <adam at zuerchertech.com>:

These should all return False, or some of them should raise exceptions:

Python 2.6.2 (release26-maint, Apr 19 2009, 01:58:18)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import decimal
>>> decimal.Decimal('0') > 0
False
>>> decimal.Decimal('0') < 0
False
>>> decimal.Decimal('0') > 0.0
True
>>> decimal.Decimal('0') < 0.0
False
>>> 0.0 > decimal.Decimal('0')
False
>>> 0.0 < decimal.Decimal('0')
True
>>> 0.0 < decimal.Decimal('0.0')
True
>>> decimal.Decimal('0') > decimal.Decimal('0')
False

----------
components: Library (Lib)
messages: 95248
nosy: adamtj
severity: normal
status: open
title: decimal.Decimal greater than/less than sometimes gives wrong answers when comparing to floats.
versions: Python 2.4, Python 2.5, Python 2.6

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

From report at bugs.python.org  Sat Nov 14 19:39:33 2009
From: report at bugs.python.org (Adam Tomjack)
Date: Sat, 14 Nov 2009 18:39:33 +0000
Subject: [issue7323] decimal.Decimal greater than/less than sometimes gives
	wrong answers when comparing to floats.
In-Reply-To: <1258223960.66.0.3588708996.issue7323@psf.upfronthosting.co.za>
Message-ID: <1258223973.67.0.969375297307.issue7323@psf.upfronthosting.co.za>


Changes by Adam Tomjack <adam at zuerchertech.com>:


----------
type:  -> behavior

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

From report at bugs.python.org  Sat Nov 14 19:43:11 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Nov 2009 18:43:11 +0000
Subject: [issue7324] Add sanity-check else case to regrtest option parsing
In-Reply-To: <1258224191.28.0.763058552728.issue7324@psf.upfronthosting.co.za>
Message-ID: <1258224191.28.0.763058552728.issue7324@psf.upfronthosting.co.za>


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

In forward porting a patch to py3k I noticed that there is a 'g' option
in the optparse argument list in regrtest in 2.x that is not present in
3.x.  But the surprising thing was that there are no docs for this
option, nor any option handler in the 2.x regrtest.

I propose to add an 'else' case to the option parsing loop that asks the
user to report a bug if it is handed an unknown option.  Patch attached.

My one question is whether this might have been intentional for backward
compatibility reasons: let -g be passed and ignore it silently.  I'm
guessing it was just a deletion oversight, though.

----------
components: Tests
files: regrtest-detect-bad-option.patch
keywords: patch, patch
messages: 95249
nosy: pitrou, r.david.murray
priority: low
severity: normal
stage: patch review
status: open
title: Add sanity-check else case to regrtest option parsing
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15330/regrtest-detect-bad-option.patch

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

From report at bugs.python.org  Sat Nov 14 19:43:20 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 14 Nov 2009 18:43:20 +0000
Subject: [issue6963] Add worker process lifetime to multiprocessing.Pool -
	patch included
In-Reply-To: <1258216981.83.0.901180351616.issue6963@psf.upfronthosting.co.za>
Message-ID: <4222a8490911141043x751c660cr46cc6808741a7757@mail.gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

On Sat, Nov 14, 2009 at 11:43 AM, Charles Cazabon
<report at bugs.python.org> wrote:
>
> Charles Cazabon <charlesc-python at pyropus.ca> added the comment:
>
> Hi Jesse -- Any chance you'll be able to review this in time for it to
> make it into trunk for the 2.7 alpha release?

2.7 isn't slated until next year some time, so yes.

----------

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

From report at bugs.python.org  Sat Nov 14 19:45:33 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 14 Nov 2009 18:45:33 +0000
Subject: [issue7309] crasher in str(Exception())
In-Reply-To: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>
Message-ID: <1258224333.69.0.481825415183.issue7309@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The patch that is (hopefully) attached is a first, incomplete cut just
for demonstration purposes. I still need to cover all of the cases where
PyString_AS_STRING are called without type checking. Also, as Ezio
points out, start and end are used to index an array without type
checking. I'll fix that as well.

The patch is against trunk.

----------
keywords: +patch
Added file: http://bugs.python.org/file15331/issue7309.patch

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

From report at bugs.python.org  Sat Nov 14 19:45:41 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 14 Nov 2009 18:45:41 +0000
Subject: [issue7309] crasher in str(Exception())
In-Reply-To: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>
Message-ID: <1258224341.59.0.653932031337.issue7309@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------

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

From report at bugs.python.org  Sat Nov 14 19:48:06 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Nov 2009 18:48:06 +0000
Subject: [issue7323] decimal.Decimal greater than/less than sometimes gives
	wrong answers when comparing to floats.
In-Reply-To: <1258223960.66.0.3588708996.issue7323@psf.upfronthosting.co.za>
Message-ID: <1258224486.89.0.620146071857.issue7323@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Sat Nov 14 19:57:54 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 14 Nov 2009 18:57:54 +0000
Subject: [issue7309] crasher in str(Exception())
In-Reply-To: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>
Message-ID: <1258225074.84.0.842660855676.issue7309@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The same problem (u.start and u.end) also affects the other UnicodeError
exceptions (namely UnicodeEncodeError and UnicodeDecodeError).

Py2.4 and 2.5 don't seem to segfault with the example I provided.

----------

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

From report at bugs.python.org  Sat Nov 14 20:00:31 2009
From: report at bugs.python.org (Pawel Prokop)
Date: Sat, 14 Nov 2009 19:00:31 +0000
Subject: [issue4080] pyunit - display time of each test case - patch
In-Reply-To: <1223497696.14.0.913391715353.issue4080@psf.upfronthosting.co.za>
Message-ID: <1258225231.52.0.590540141439.issue4080@psf.upfronthosting.co.za>


Pawel Prokop <pablo at uek.krakow.pl> added the comment:

Repack of unittest was good idea. It is a patch against trunk, one test
case is provided and documentation update.

----------
Added file: http://bugs.python.org/file15332/unittest_runTime.patch

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

From report at bugs.python.org  Sat Nov 14 20:03:30 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Nov 2009 19:03:30 +0000
Subject: [issue7324] Add sanity-check else case to regrtest option parsing
In-Reply-To: <1258224191.28.0.763058552728.issue7324@psf.upfronthosting.co.za>
Message-ID: <1258225410.58.0.176548409621.issue7324@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

That should have been 'getopt option list'.

----------

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

From report at bugs.python.org  Sat Nov 14 20:17:07 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 14 Nov 2009 19:17:07 +0000
Subject: [issue7324] Add sanity-check else case to regrtest option parsing
In-Reply-To: <1258224191.28.0.763058552728.issue7324@psf.upfronthosting.co.za>
Message-ID: <1258226227.46.0.594783605722.issue7324@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I bet it was an option oversight. Since regrtest is an internal tool we 
don't really need to fret about backwards-compatibility for anyone.

----------
nosy: +brett.cannon

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

From report at bugs.python.org  Sat Nov 14 20:27:36 2009
From: report at bugs.python.org (Roy Smith)
Date: Sat, 14 Nov 2009 19:27:36 +0000
Subject: [issue7325] tempfile.mkdtemp() does not return absolute pathname when
	dir is specified
In-Reply-To: <1258226856.45.0.72736645389.issue7325@psf.upfronthosting.co.za>
Message-ID: <1258226856.45.0.72736645389.issue7325@psf.upfronthosting.co.za>


New submission from Roy Smith <roy at panix.com>:

The docs (http://www.python.org/doc/2.5.1/lib/module-tempfile.html) specify that 
mkdtemp(), "returns the absolute pathname of the new directory".  It does that in 
the default case, but if you specify a relative path for 'dir', you get back a 
relative path.


$ python
Python 2.5.1 (r251:54863, Oct 17 2008, 14:39:09) 
[GCC 3.4.6 20060404 (Red Hat 3.4.6-10)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tempfile
>>> tempfile.mkdtemp(dir='.')
'./tmpHk1pBD'

similar results were obtained on:

Python 2.5.1 (r251:54863, Feb  6 2009, 19:02:12) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin

Note that mkstemp() gets it right:

>>> tempfile.mkdtemp(dir='.')
'./tmpoPXdL7'
>>> tempfile.mkstemp(dir='.')
(3, '/Users/roy2/tmpwTGZ2y')
>>>

----------
components: Library (Lib)
messages: 95256
nosy: roysmith
severity: normal
status: open
title: tempfile.mkdtemp() does not return absolute pathname when dir is specified
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Sat Nov 14 20:51:31 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Nov 2009 19:51:31 +0000
Subject: [issue7325] tempfile.mkdtemp() does not return absolute pathname when
	dir is specified
In-Reply-To: <1258226856.45.0.72736645389.issue7325@psf.upfronthosting.co.za>
Message-ID: <1258228291.6.0.139310520312.issue7325@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is true on trunk and py3k as well.  2.5 is in security fix only
mode, so I've removed it from the versions list.

Since mkstemp does return in the absolute path in this case, I think
this is a code rather than a documentation bug.  However, changing it
would be backward incompatible, so it may not be possible to fix it in
2.6 and 3.1.

----------
keywords: +easy
nosy: +r.david.murray
priority:  -> normal
stage:  -> test needed
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5

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

From report at bugs.python.org  Sat Nov 14 21:16:10 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 14 Nov 2009 20:16:10 +0000
Subject: [issue7322] Socket timeout can cause file-like readline() method to
	lose data
In-Reply-To: <1258218993.08.0.764402701678.issue7322@psf.upfronthosting.co.za>
Message-ID: <1258229770.95.0.871700450122.issue7322@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
priority:  -> normal

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

From report at bugs.python.org  Sat Nov 14 21:38:12 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 14 Nov 2009 20:38:12 +0000
Subject: [issue1023290] Conversion of longs to bytes and vice-versa.
Message-ID: <1258231092.21.0.673577046452.issue1023290@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Here's an updated patch.

- Renamed tobytes() to to_bytes() and frombytes() to from_bytes().
- Moved the changes to pickle to a different patch.
- Made the NULL-checks more consistent with the rest of long's code.
- Fixed the type check of the `length' parameter of to_bytes() to use
  PyIndex_Check() instead of PyLong_Check().

----------
dependencies: +Move the special-case for integer objects out of PyBytes_FromObject.
Added file: http://bugs.python.org/file15333/long_and_bytes_conversion-3.diff

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

From report at bugs.python.org  Sat Nov 14 22:36:29 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 14 Nov 2009 21:36:29 +0000
Subject: [issue6804] IDLE: Detect Python files even if name doesn't end in .py
In-Reply-To: <1251582280.35.0.0143459273436.issue6804@psf.upfronthosting.co.za>
Message-ID: <1258234589.17.0.114813746878.issue6804@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


Removed file: http://bugs.python.org/file14803/EditorWindow.diff

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

From report at bugs.python.org  Sat Nov 14 22:38:23 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 14 Nov 2009 21:38:23 +0000
Subject: [issue6804] IDLE: Detect Python files even if name doesn't end in .py
In-Reply-To: <1251582280.35.0.0143459273436.issue6804@psf.upfronthosting.co.za>
Message-ID: <1258234703.88.0.597538127097.issue6804@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

This new patch addresses the previous comments.

----------
Added file: http://bugs.python.org/file15334/EditorWindow.diff

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

From report at bugs.python.org  Sat Nov 14 23:06:31 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 14 Nov 2009 22:06:31 +0000
Subject: [issue6906] Tkinter sets an unicode environment variable on win32
In-Reply-To: <1252920566.52.0.249075498328.issue6906@psf.upfronthosting.co.za>
Message-ID: <1258236391.19.0.575338592252.issue6906@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

This patch may solve this issue, but I don't have a Vista install to 
test it.

----------
keywords: +patch
Added file: http://bugs.python.org/file15335/FixTk.diff

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

From report at bugs.python.org  Sat Nov 14 23:19:57 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 14 Nov 2009 22:19:57 +0000
Subject: [issue7309] crasher in str(Exception())
In-Reply-To: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>
Message-ID: <1258237197.02.0.701549020469.issue7309@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Another patch against trunk which deals with:

UnicodeEncodeError: reason and encoding
UnicodeDecodeError: reason and encoding
UnicodeTranslateError: reason

Still needs tests. Also, the unchecked use of start and end needs to be
addressed. I'm working on that.

----------
Added file: http://bugs.python.org/file15336/issue7309.patch

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

From report at bugs.python.org  Sat Nov 14 23:20:09 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 14 Nov 2009 22:20:09 +0000
Subject: [issue7309] crasher in str(Exception())
In-Reply-To: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>
Message-ID: <1258237209.57.0.560923187354.issue7309@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


Removed file: http://bugs.python.org/file15331/issue7309.patch

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

From report at bugs.python.org  Sat Nov 14 23:20:50 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 14 Nov 2009 22:20:50 +0000
Subject: [issue7323] decimal.Decimal greater than/less than sometimes gives
	wrong answers when comparing to floats.
In-Reply-To: <1258223960.66.0.3588708996.issue7323@psf.upfronthosting.co.za>
Message-ID: <1258237250.83.0.248312217702.issue7323@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Unfortunately there's no easy way to fix this in 2.x, where any object is 
supposed to be comparable with any other.  See issue 2531 for a previous 
discussion.  It's fixed in 3.x:  there a comparison (other than ==, !=) 
between a float and a Decimal does raise an exception.

Closing as a duplicate of issue 2531.  Issue 2531 is also closed, but you 
should feel free to add to the discussion there.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> float compared to decimal is silently incorrect.

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

From report at bugs.python.org  Sat Nov 14 23:25:41 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 14 Nov 2009 22:25:41 +0000
Subject: [issue7309] crasher in str(Exception())
In-Reply-To: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>
Message-ID: <1258237541.75.0.843103117479.issue7309@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


Added file: http://bugs.python.org/file15337/issue7309-1.patch

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

From report at bugs.python.org  Sat Nov 14 23:25:47 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 14 Nov 2009 22:25:47 +0000
Subject: [issue7309] crasher in str(Exception())
In-Reply-To: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>
Message-ID: <1258237547.23.0.989995886386.issue7309@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


Removed file: http://bugs.python.org/file15336/issue7309.patch

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

From report at bugs.python.org  Sat Nov 14 23:37:14 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 14 Nov 2009 22:37:14 +0000
Subject: [issue2531] float compared to decimal is silently incorrect.
In-Reply-To: <1207087897.38.0.261389881483.issue2531@psf.upfronthosting.co.za>
Message-ID: <1258238234.77.0.876707355875.issue2531@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Just closed issue 7323 as a duplicate of this one.

I think this issue is worth reopening:  with the backport of the py3k 
correctly rounded string <-> float conversions, there might now be a 
reasonable way to rewrite Decimal.__hash__ so that it's consistent with 
float.__hash__.  Then we can make Decimal-to-float comparisons behave 
correctly and clear up this mess.

I'd still be uncomfortable with allowing Decimal-to-float comparisons in 
2.x but not in 3.x.  Maybe they could be permitted in 3.x too?

----------
resolution: wont fix -> 
status: closed -> open

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

From report at bugs.python.org  Sat Nov 14 23:37:52 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 14 Nov 2009 22:37:52 +0000
Subject: [issue2531] float compared to decimal is silently incorrect.
In-Reply-To: <1207087897.38.0.261389881483.issue2531@psf.upfronthosting.co.za>
Message-ID: <1258238272.71.0.991596179351.issue2531@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +adamtj

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

From report at bugs.python.org  Sat Nov 14 23:39:18 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 14 Nov 2009 22:39:18 +0000
Subject: [issue7323] decimal.Decimal greater than/less than sometimes gives
	wrong answers when comparing to floats.
In-Reply-To: <1258223960.66.0.3588708996.issue7323@psf.upfronthosting.co.za>
Message-ID: <1258238358.06.0.339378582269.issue7323@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I've re-opened issue 2531:  some recent changes (in particular, the 
backport of the 3.x float <-> string conversions to 2.x) may make 
previously rejected solutions viable again.

----------

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

From report at bugs.python.org  Sat Nov 14 23:55:15 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 14 Nov 2009 22:55:15 +0000
Subject: [issue7309] crasher in str(Exception())
In-Reply-To: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>
Message-ID: <1258239315.63.0.669510042013.issue7309@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Tests need to cover issues like:

# assigning a non-string to e.object
e = UnicodeDecodeError("", "", 0, 1, "")
e.object = None
print str(e)

# start and end out of range
e = UnicodeDecodeError("", "", 0, 1, "")
e.start = 1000
e.end = 1001
print str(e)

For all cases of UnicodeXXXError with start and end, the code has a
special case for end = start+1. Invalid start/end tests need to have
end==start+1, end>start+1, end<start+1.

I'm not sure what the functions should do when start and end are out of
range.

----------

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

From report at bugs.python.org  Sun Nov 15 01:31:11 2009
From: report at bugs.python.org (Patricia Irwin)
Date: Sun, 15 Nov 2009 00:31:11 +0000
Subject: [issue4049] IDLE does not open too
In-Reply-To: <1223253081.14.0.0863464602504.issue4049@psf.upfronthosting.co.za>
Message-ID: <1258245071.27.0.42771459971.issue4049@psf.upfronthosting.co.za>


Patricia Irwin <plirwin at gmail.com> added the comment:

Hi, 

I'm running Windows XP Professional and just installed Python 2.6. I
installed it for all users. Tried starting up IDLE and nothing happened.
I read the boards here, and it looks like others have had similar
troubles. I read on this board that moving the Tcl/Tk directories
helped, so I tried moving the tcl8.5 and tk8.5 directories to
C:\Python26\Lib, but IDLE still wouldn't start up. (So I moved them back.)

I opened a command shell and tried running idle that way. I will paste
the output below. Could someone help with this? Sorry if this is the
wrong place to post this problem; I am Python newbie.

C:\Python26>python Lib\idlelib\idle.py

Traceback (most recent call last):
  File "Lib\idlelib\idle.py", line 21, in <module>
    idlelib.PyShell.main()
  File "C:\Python26\lib\idlelib\PyShell.py", line 1400, in main
    shell = flist.open_shell()
  File "C:\Python26\lib\idlelib\PyShell.py", line 279, in open_shell
    self.pyshell = PyShell(self)
  File "C:\Python26\lib\idlelib\PyShell.py", line 820, in __init__
    OutputWindow.__init__(self, flist, None, None)
  File "C:\Python26\lib\idlelib\OutputWindow.py", line 16, in __init__
    EditorWindow.__init__(self, *args)
  File "C:\Python26\lib\idlelib\EditorWindow.py", line 234, in __init__
    self.update_recent_files_list()
  File "C:\Python26\lib\idlelib\EditorWindow.py", line 755, in
update_recent_fil
es_list
    rf_file = open(self.recent_files_path, 'w')
IOError: [Errno 13] Permission denied: 'C:\\Documents and
Settings\\Tricia\\.idl
erc\\recent-files.lst'

----------
nosy: +pi
versions: +Python 2.6 -Python 3.0

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

From report at bugs.python.org  Sun Nov 15 01:41:58 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 Nov 2009 00:41:58 +0000
Subject: [issue7324] Add sanity-check else case to regrtest option parsing
In-Reply-To: <1258224191.28.0.763058552728.issue7324@psf.upfronthosting.co.za>
Message-ID: <1258245718.31.0.160404326427.issue7324@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed in r76276 through r76281, along with removing 'g' from the
getopt list in 2.6.  3.1 still has other traces of the -g option; I
haven't cleaned that up.

----------
assignee:  -> r.david.murray
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type: feature request -> behavior

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

From report at bugs.python.org  Sun Nov 15 02:02:20 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 15 Nov 2009 01:02:20 +0000
Subject: [issue7293] test_msvc9compiler test_reg_class failure on new Windows
	box
In-Reply-To: <1257750000.16.0.245083157049.issue7293@psf.upfronthosting.co.za>
Message-ID: <1258246940.48.0.634083723542.issue7293@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

> Does it have to be a DWORD, or a 0/1 value, or under HKCU for a
> specific reason?

This notepad test was just to make sure the registry reader works
by returning a known value.

I can change it using:

Reg.get_value("Software\Microsoft\VisualStudio\9.0\VC", "Build Timing")
 == 0


For this test, if you can check that this value is the same on a fresh
win XP and 7, it's perfect. (8.0 doesn't matter here, I can restrict the
build version to 9.0)

----------

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

From report at bugs.python.org  Sun Nov 15 02:12:03 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 15 Nov 2009 01:12:03 +0000
Subject: [issue4359] at runtime, distutils uses buildtime files
In-Reply-To: <1227138737.98.0.796971482315.issue4359@psf.upfronthosting.co.za>
Message-ID: <1258247523.43.0.905901643876.issue4359@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

This is a problem indeed. 

One solution would be to generate a module in the stdlib that contains
all these info, when configure is called.

as a matter of fact, I am currently working in a branch to add a module
called "sysconfig" to the stdlib, that contains installation paths
extracted from distutils/sysconfig and site.py, so the stdlib has only
one place to handle those.

This module will basically be the last spot to look for data in makefile
and pyconfig.h, so maybe we could inject in it a condensed version of
these files, in the form of a dict.

(I'll send a mail on python-dev about this)

----------

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

From report at bugs.python.org  Sun Nov 15 02:34:40 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 15 Nov 2009 01:34:40 +0000
Subject: [issue4049] IDLE does not open too
In-Reply-To: <1223253081.14.0.0863464602504.issue4049@psf.upfronthosting.co.za>
Message-ID: <1258248880.71.0.356838760452.issue4049@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Patricia, if you want to report a bug, please don't follow up to an
existing, closed bug report.

If you are just asking for help: delete the folder .idlerc and all of
its files, and retry.

----------

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

From report at bugs.python.org  Sun Nov 15 03:16:46 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 15 Nov 2009 02:16:46 +0000
Subject: [issue4359] at runtime, distutils uses buildtime files
In-Reply-To: <1227138737.98.0.796971482315.issue4359@psf.upfronthosting.co.za>
Message-ID: <1258251406.17.0.250963880171.issue4359@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

see http://mail.python.org/pipermail/python-dev/2009-November/094232.html

(notice that the dependency in install can be removed easily because it
just reads variables from sys and does not require to import sysconfig)

----------

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

From report at bugs.python.org  Sun Nov 15 03:17:55 2009
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Pasternak?=)
Date: Sun, 15 Nov 2009 02:17:55 +0000
Subject: [issue6906] Tkinter sets an unicode environment variable on win32
In-Reply-To: <1252920566.52.0.249075498328.issue6906@psf.upfronthosting.co.za>
Message-ID: <1258251475.97.0.327838633697.issue6906@psf.upfronthosting.co.za>


Micha? Pasternak <michal.dtz at gmail.com> added the comment:

This patch works OK for me (Vista Home Premium + Python 2.6), thanks!

----------

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

From report at bugs.python.org  Sun Nov 15 05:59:03 2009
From: report at bugs.python.org (pablo veloz)
Date: Sun, 15 Nov 2009 04:59:03 +0000
Subject: [issue7326] SOLUTION pls?
	/usr/lib/python2.6/dist-packages/visual/__init__.py", line 59,
	in <module> import cvisual AttributeError:
	'Boost.Python.StaticProperty' object attribute '__doc__' is read-only
In-Reply-To: <1258261143.05.0.897261175565.issue7326@psf.upfronthosting.co.za>
Message-ID: <1258261143.05.0.897261175565.issue7326@psf.upfronthosting.co.za>


New submission from pablo veloz <pveloz16 at msn.com>:

sorry for my english, but how can i reparer that problem? help me pls thank.

----------
messages: 95273
nosy: pveloz
severity: normal
status: open
title: SOLUTION pls? /usr/lib/python2.6/dist-packages/visual/__init__.py", line 59, in <module>     import cvisual AttributeError: 'Boost.Python.StaticProperty' object attribute '__doc__' is read-only
versions: Python 2.6

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

From report at bugs.python.org  Sun Nov 15 07:08:04 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 15 Nov 2009 06:08:04 +0000
Subject: [issue1368312] fix for scheme identification in urllib2?
Message-ID: <1258265284.88.0.475199186807.issue1368312@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

This issue is Invalid. I am sorry that it had be open for so long
without any explanation. 

The order in which the handlers are tried does not depend upon the way
http_error_auth_reqed method is coded, but rather on the handler_order.
In urllib2, we have handler_order set to 490 for digest and 500 for
basic, which means that Digest will always be tried before Basic
(Correctly so).  If you have any server implementing both Basic and
Digest (well,it is bad idea on the server part), you can try with any
client, like firefox and see that Digest overrules Basic.

Now, if you have two files (one under Basic Authentication ) and another
under Digest Authentication configured, then it all boils down to adding
"both" HTTPBasicAuthHandler and HTTPDigestAuthHandler to your
OpenerDirector instance. The handler_order and opener instance will
properly take care of opening the individual distinct requests with
appropriate handlers.
I tested it with the setup here and could not see any problem.  I am
closing this bug as Invalid.

----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Sun Nov 15 08:18:53 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Nov 2009 07:18:53 +0000
Subject: [issue6816] Provide CPython command line functionality via runpy
	module
In-Reply-To: <1251802599.29.0.539498266032.issue6816@psf.upfronthosting.co.za>
Message-ID: <1258269533.61.0.845852274795.issue6816@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Descoped idea to just provide runpy.run_path (filesystem path equivalent
of runpy.run_module)

----------

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

From report at bugs.python.org  Sun Nov 15 09:32:47 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 15 Nov 2009 08:32:47 +0000
Subject: [issue4683] urllib2.HTTPDigestAuthHandler fails on third hostname?
In-Reply-To: <1229523259.96.0.571468029932.issue4683@psf.upfronthosting.co.za>
Message-ID: <1258273967.23.0.363630262581.issue4683@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Interesting issue. RFC 2617 supports the claim. In RFC 2617, section
3.2.2 The Authorization Request Header, we see that nonce-count is
maintained for each particular nonce value and it can used by the server
to verify the replays.

"""
The nc-value is the hexadecimal count of the number of requests
(including the current request) that the client has sent with the nonce
value in this request.  For  example, in the first request sent in
response to a given nonce value, the client sends "nc=00000001".  The
purpose of this  directive is to allow the server to detect request
replays by  maintaining its own copy of this count - if the same
nc-value is  seen twice, then the request is a replay. 
"""

resetting the nonce_count for each new nonce is the correct thing to do.
Patch seems okay and I going ahead with that.

We don't have test for HTTPDigestAuth yet, the nonce tests should be a
part of that.

----------
resolution:  -> accepted

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

From report at bugs.python.org  Sun Nov 15 09:49:41 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 15 Nov 2009 08:49:41 +0000
Subject: [issue7309] crasher in str(Exception())
In-Reply-To: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>
Message-ID: <1258274981.9.0.588676837774.issue7309@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> I'm not sure what the functions should do when start and end are
> out of range.

I think the best approach would be to prevent these values to be out of
range in the first place. 
All the args should be checked when the instance is created (to avoid
things like UnicodeTranslateError(None, 2**30, 2**30+1, 'bah')) and
then, if possible, the attributes should be set as read-only.
I don't see any valid reason to change them anyway.

----------

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

From report at bugs.python.org  Sun Nov 15 09:51:13 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 15 Nov 2009 08:51:13 +0000
Subject: [issue4683] urllib2.HTTPDigestAuthHandler fails on third hostname?
In-Reply-To: <1229523259.96.0.571468029932.issue4683@psf.upfronthosting.co.za>
Message-ID: <1258275073.76.0.422309341999.issue4683@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in r76288 (trunk), r76289 (release26-maint), r76290 (py3k) and
r76291(release31-maint). The issue is fixed. I am keeping it open to
remind of the pending tests (HTTPAuthDigest and nonce value check testcase).

----------
resolution: accepted -> fixed

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

From report at bugs.python.org  Sun Nov 15 09:56:02 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sun, 15 Nov 2009 08:56:02 +0000
Subject: [issue4969] mimetypes on Windows should read MIME database from
	registry (w/patch)
In-Reply-To: <1232182722.74.0.429880551513.issue4969@psf.upfronthosting.co.za>
Message-ID: <1258275362.82.0.514073293383.issue4969@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

A new patch taking into account M. Pitrou comments:

- name changed to read_windows_registry()
- read_windows_registry() does nothing on non-Windows platforms; same 
as read_mime_types(filename) when the file does not exist.
- I hope the coding style is acceptable now
- the test is skipped on non-Windows platforms
- documentation updated
- documentation for MimeTypes.guess_all_extensions was missing; I 
added it although it isn't directly related to this issue.

----------
Added file: http://bugs.python.org/file15338/mimetypes.diff

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

From report at bugs.python.org  Sun Nov 15 09:56:26 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sun, 15 Nov 2009 08:56:26 +0000
Subject: [issue4969] mimetypes on Windows should read MIME database from
	registry (w/patch)
In-Reply-To: <1232182722.74.0.429880551513.issue4969@psf.upfronthosting.co.za>
Message-ID: <1258275387.0.0.00843637574411.issue4969@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


Removed file: http://bugs.python.org/file12774/mimetypes.diff

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

From report at bugs.python.org  Sun Nov 15 10:10:26 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Nov 2009 09:10:26 +0000
Subject: [issue6816] Provide CPython command line functionality via runpy
	module
In-Reply-To: <1251802599.29.0.539498266032.issue6816@psf.upfronthosting.co.za>
Message-ID: <1258276226.32.0.0861991967253.issue6816@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

2.7: r76286
3.2 merge is still a work in progress

----------

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

From report at bugs.python.org  Sun Nov 15 10:21:35 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 15 Nov 2009 09:21:35 +0000
Subject: [issue7291] urllib2 cannot handle https with proxy requiring auth
In-Reply-To: <1257741498.16.0.683281197284.issue7291@psf.upfronthosting.co.za>
Message-ID: <1258276895.18.0.959863806001.issue7291@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil
nosy: +orsenthil
resolution:  -> accepted

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

From report at bugs.python.org  Sun Nov 15 11:12:30 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sun, 15 Nov 2009 10:12:30 +0000
Subject: [issue6598] calling email.utils.make_msgid frequently has a
	non-trivial probability of generating colliding ids
In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za>
Message-ID: <1258279950.97.0.958965392122.issue6598@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

An updated version of the make_msgid patch.
Includes a random part plus a sequential part. Testing takes at most 3 
seconds now (we're interested in those msgids generated in a whole 
second)

----------
Added file: http://bugs.python.org/file15339/make_msgid.diff

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

From report at bugs.python.org  Sun Nov 15 11:12:43 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sun, 15 Nov 2009 10:12:43 +0000
Subject: [issue6598] calling email.utils.make_msgid frequently has a
	non-trivial probability of generating colliding ids
In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za>
Message-ID: <1258279963.11.0.458160249825.issue6598@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


Removed file: http://bugs.python.org/file14644/test_email.diff

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

From report at bugs.python.org  Sun Nov 15 11:12:49 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sun, 15 Nov 2009 10:12:49 +0000
Subject: [issue6598] calling email.utils.make_msgid frequently has a
	non-trivial probability of generating colliding ids
In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za>
Message-ID: <1258279969.93.0.305901875242.issue6598@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


Removed file: http://bugs.python.org/file14676/utils.diff

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

From report at bugs.python.org  Sun Nov 15 11:18:03 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 15 Nov 2009 10:18:03 +0000
Subject: [issue7298] reversed(range(x, -1, -1)) is empty when x > 1
In-Reply-To: <1257848858.69.0.270094372501.issue7298@psf.upfronthosting.co.za>
Message-ID: <1258280283.83.0.757974480319.issue7298@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The fix was applied to py3k in r76292, but I bodged the commit and 
committed some extra (non-working) code by mistake.  That was removed in 
r76293, so all should be well now.

Merged to release31-maint in r76294.

trunk and the 2.6 maintenance branch also need some (but not all) of these 
fixes backporting.

----------
versions: +Python 2.6, Python 2.7 -Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Nov 15 11:29:31 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 15 Nov 2009 10:29:31 +0000
Subject: [issue7327] format: minimum width: UTF-8 separators and decimal points
In-Reply-To: <1258280971.1.0.983226181609.issue7327@psf.upfronthosting.co.za>
Message-ID: <1258280971.1.0.983226181609.issue7327@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

This issue affects the format functions of float and decimal.

When calculating the padding necessary to reach the minimum width,
UTF-8 separators and decimal points are calculated by their byte
lengths. This can lead to printed representations that are too short.


Real world example (separator):

>>> import locale
>>> from decimal import *
>>> locale.setlocale(locale.LC_NUMERIC, "cs_CZ.UTF-8")
'cs_CZ.UTF-8'
>>> s = format(Decimal("-1.5"),  ' 019.18n')
>>> len(s)
19
>>> len(s.decode('utf-8'))
16
>>> s
'-0\xc2\xa0000\xc2\xa0000\xc2\xa0001,5'
>>> 
>>> 
>>> s = format(-1.5,  ' 019.18n')
>>> s
'-0\xc2\xa0000\xc2\xa0000\xc2\xa0001,5'
>>> len(s.decode('utf-8'))
16
>>> 


Constructed example (separator and decimal point):

>>> u = {'decimal_point' : "\xc2\xbf",  'grouping' : [3, 3, 0],
'thousands_sep': "\xc2\xb4"}
>>> def get_fmt(x, locale, fmt='n'):
...     return Decimal.__format__(Decimal(x), fmt, _localeconv=locale)
... 
>>> s = get_fmt(Decimal("1.5"), u, "020n")
>>> s
'00\xc2\xb4000\xc2\xb4000\xc2\xb4001\xc2\xbf5'
>>> len(s.decode('utf-8'))
16

----------
messages: 95283
nosy: eric.smith, mark.dickinson, skrah
severity: normal
status: open
title: format: minimum width: UTF-8 separators and decimal points

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

From report at bugs.python.org  Sun Nov 15 11:46:55 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sun, 15 Nov 2009 10:46:55 +0000
Subject: [issue2304] subprocess under windows fails to quote properly
	when	shell=True
In-Reply-To: <1205685138.96.0.183811169845.issue2304@psf.upfronthosting.co.za>
Message-ID: <1258282015.88.0.318264493837.issue2304@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

An up-to-date patch; same contents, but this one can be cleanly 
applied to trunk (as of r76294)

----------
versions: +Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15340/subprocess.diff

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

From report at bugs.python.org  Sun Nov 15 12:15:31 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sun, 15 Nov 2009 11:15:31 +0000
Subject: [issue6647] warnings.catch_warnings is not thread-safe
In-Reply-To: <1249447980.99.0.321429613778.issue6647@psf.upfronthosting.co.za>
Message-ID: <1258283731.19.0.046130702158.issue6647@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Document that warnings.catch_warnings is not thread safe.

----------
keywords: +patch
Added file: http://bugs.python.org/file15341/warnings.diff

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

From report at bugs.python.org  Sun Nov 15 13:05:56 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sun, 15 Nov 2009 12:05:56 +0000
Subject: [issue6031] BaseServer.shutdown documentation is incomplete
In-Reply-To: <1242431876.91.0.139343855315.issue6031@psf.upfronthosting.co.za>
Message-ID: <1258286756.74.0.612342521688.issue6031@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Documentation patch for BaseServer.server_forever() and shutdown()

----------
keywords: +patch
Added file: http://bugs.python.org/file15342/socketserver.rst.diff

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

From report at bugs.python.org  Sun Nov 15 13:41:02 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 15 Nov 2009 12:41:02 +0000
Subject: [issue7298] reversed(range(x, -1, -1)) is empty when x > 1
In-Reply-To: <1257848858.69.0.270094372501.issue7298@psf.upfronthosting.co.za>
Message-ID: <1258288862.7.0.534195935764.issue7298@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Backported the tests and some of the fixes to 2.x in r76295 (trunk) and 
r76296 (release26-maint).

2.x seems to have been producing correct results in all cases on my 
machine.  The only problem on 2.x was that the code depended on signed 
arithmetic wrapping modulo 2**width (undefined behaviour!  very bad!);  
now it only depends on unsigned -> signed conversions wrapping modulo 
2**width, which still isn't guaranteed by the C standards, but it's 
merely implementation-defined behaviour rather than undefined behaviour, 
and all implementations that I'm aware of do this.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sun Nov 15 14:09:04 2009
From: report at bugs.python.org (Thomas Courbon)
Date: Sun, 15 Nov 2009 13:09:04 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1258290544.86.0.745872491715.issue4953@psf.upfronthosting.co.za>


Thomas Courbon <harthie at yahoo.fr> added the comment:

*bump*

Hi there Pythoners !

As Timothy Farrell I'm currently working (or rather, toying since it
just for fun) on a Python3 web framework. I just started but when it
come to file upload I experience issues which I believe are connected to
that issue.

Just want if their was any progress since last messages or I should jump
in and try writing my own multipart parser (as I doubt I have the
required skill to contribute to the email parser).

----------
nosy: +tcourbon

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

From report at bugs.python.org  Sun Nov 15 14:49:50 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 15 Nov 2009 13:49:50 +0000
Subject: [issue5792] Enable short float repr() on Solaris/x86
In-Reply-To: <1240144400.05.0.462557167881.issue5792@psf.upfronthosting.co.za>
Message-ID: <1258292990.33.0.0852641047164.issue5792@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Committed in r76300 (trunk) and r76301 (py3k).  Thanks for all your help, 
Stefan.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Nov 15 14:51:06 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 15 Nov 2009 13:51:06 +0000
Subject: [issue7261] Document 2.x -> 3.x round changes in "What's New"
	documents.
In-Reply-To: <1257330793.87.0.85024867948.issue7261@psf.upfronthosting.co.za>
Message-ID: <1258293066.94.0.240457789276.issue7261@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
priority:  -> low

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

From report at bugs.python.org  Sun Nov 15 15:00:28 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 15 Nov 2009 14:00:28 +0000
Subject: [issue6970] Redundant calls made to comparison methods.
In-Reply-To: <1253633826.69.0.906783936542.issue6970@psf.upfronthosting.co.za>
Message-ID: <1258293628.43.0.856152323171.issue6970@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Committed to py3k in r76304.  Leaving trunk alone, as Brett suggested.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Nov 15 15:01:15 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 15 Nov 2009 14:01:15 +0000
Subject: [issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)
In-Reply-To: <1256712581.76.0.435920152498.issue7228@psf.upfronthosting.co.za>
Message-ID: <1258293675.71.0.22582733738.issue7228@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
priority:  -> normal

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

From report at bugs.python.org  Sun Nov 15 15:06:12 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 15 Nov 2009 14:06:12 +0000
Subject: [issue4969] mimetypes on Windows should read MIME database from
	registry (w/patch)
In-Reply-To: <1232182722.74.0.429880551513.issue4969@psf.upfronthosting.co.za>
Message-ID: <1258293972.16.0.235574386512.issue4969@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you, the patch looks ok to me.

----------
resolution:  -> accepted

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

From report at bugs.python.org  Sun Nov 15 15:18:12 2009
From: report at bugs.python.org (Timothy Farrell)
Date: Sun, 15 Nov 2009 14:18:12 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1258294692.86.0.0357849957955.issue4953@psf.upfronthosting.co.za>


Timothy Farrell <tfarrell at swgen.com> added the comment:

Perhaps this update should go in the linked email bug.  The email team
has a goal of fixing the email module in time for the 3.2 release.  I
also, feel as though I lack the skill to fix the email module, but it
goes beyond that since they're potentially having to change some
interfaces.  See this document:
http://wiki.python.org/moin/Email%20SIG/DesignThoughts

Once the email module is fixed, the cgi module will be trivial to fix. 
I'm confident enough to handle it.  I don't think anyone can give you a
date so you'll have to make the custom solution decision based on your
timeframe and patience.

----------

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

From report at bugs.python.org  Sun Nov 15 15:19:42 2009
From: report at bugs.python.org (Timothy Farrell)
Date: Sun, 15 Nov 2009 14:19:42 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1258294782.02.0.87316464516.issue4661@psf.upfronthosting.co.za>


Timothy Farrell <tfarrell at swgen.com> added the comment:

Just an update for people interested:

The email team has a goal of fixing the email module in time for the 3.2
release.  There is the possibility of having to change some interfaces.
 See this document: http://wiki.python.org/moin/Email%20SIG/DesignThoughts

----------

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

From report at bugs.python.org  Sun Nov 15 15:26:56 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 15 Nov 2009 14:26:56 +0000
Subject: [issue4969] mimetypes on Windows should read MIME database from
	registry (w/patch)
In-Reply-To: <1232182722.74.0.429880551513.issue4969@psf.upfronthosting.co.za>
Message-ID: <1258295216.0.0.689597025244.issue4969@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r76306 and r76307, closing.

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Nov 15 15:28:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 15 Nov 2009 14:28:43 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1258295323.49.0.893203358489.issue2054@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Giampaolo, do you plan to add something or is the patch ok to commit?

----------

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

From report at bugs.python.org  Sun Nov 15 15:28:46 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 15 Nov 2009 14:28:46 +0000
Subject: [issue7326] SOLUTION pls?
	/usr/lib/python2.6/dist-packages/visual/__init__.py", line 59,
	in <module> import cvisual AttributeError:
	'Boost.Python.StaticProperty' object attribute '__doc__' is read-only
In-Reply-To: <1258261143.05.0.897261175565.issue7326@psf.upfronthosting.co.za>
Message-ID: <1258295326.63.0.181037576531.issue7326@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

This issue is a duplicate of issue 7183.

----------
nosy: +Arfrever

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

From report at bugs.python.org  Sun Nov 15 15:32:06 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 15 Nov 2009 14:32:06 +0000
Subject: [issue7326] SOLUTION pls?
	/usr/lib/python2.6/dist-packages/visual/__init__.py", line 59,
	in <module> import cvisual AttributeError:
	'Boost.Python.StaticProperty' object attribute '__doc__' is read-only
In-Reply-To: <1258261143.05.0.897261175565.issue7326@psf.upfronthosting.co.za>
Message-ID: <1258295526.33.0.738330056915.issue7326@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Nov 15 15:32:42 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 15 Nov 2009 14:32:42 +0000
Subject: [issue7326] SOLUTION pls?
	/usr/lib/python2.6/dist-packages/visual/__init__.py", line 59,
	in <module> import cvisual AttributeError:
	'Boost.Python.StaticProperty' object attribute '__doc__' is read-only
In-Reply-To: <1258261143.05.0.897261175565.issue7326@psf.upfronthosting.co.za>
Message-ID: <1258295562.64.0.270841611423.issue7326@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy:  -Arfrever

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

From report at bugs.python.org  Sun Nov 15 15:33:16 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 15 Nov 2009 14:33:16 +0000
Subject: [issue7183] did 2.6.3 regress for some uses of the __doc__ property?
In-Reply-To: <1256167357.49.0.413782567423.issue7183@psf.upfronthosting.co.za>
Message-ID: <1258295596.24.0.276247778072.issue7183@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
nosy: +pveloz

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

From report at bugs.python.org  Sun Nov 15 15:34:39 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 15 Nov 2009 14:34:39 +0000
Subject: [issue7328] pydoc doesn't work from the command line
In-Reply-To: <1258295679.52.0.0670175954257.issue7328@psf.upfronthosting.co.za>
Message-ID: <1258295679.52.0.0670175954257.issue7328@psf.upfronthosting.co.za>


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

This works under 2.x but not 3.x:

$ ./python -m pydoc str
No module named subprocess

----------
components: Library (Lib)
messages: 95297
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: pydoc doesn't work from the command line
type: crash
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Nov 15 15:42:34 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 15 Nov 2009 14:42:34 +0000
Subject: [issue7328] pydoc doesn't work from the command line
In-Reply-To: <1258295679.52.0.0670175954257.issue7328@psf.upfronthosting.co.za>
Message-ID: <1258296154.48.0.655622473397.issue7328@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Same with an installed Python by the way:

$ usr/bin/python3 -m pydoc str
No module named subprocess

However, it works when not using "-m" but invoking the file directly:

$ ./python Lib/pydoc.py str

[displays the str doc page]

----------
assignee:  -> ncoghlan
nosy: +ncoghlan

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

From report at bugs.python.org  Sun Nov 15 16:10:27 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 15 Nov 2009 15:10:27 +0000
Subject: [issue7329] global statements outside functions/methods should raise
	SyntaxError
In-Reply-To: <1258297827.42.0.98275960381.issue7329@psf.upfronthosting.co.za>
Message-ID: <1258297827.42.0.98275960381.issue7329@psf.upfronthosting.co.za>


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

Python currently accepts global statements at the top level:
>>> global foo
>>>

Beside being a meaningless operation, this might lead unexperienced user
to make mistakes like:
>>> foo = 5
>>> global foo # make foo global
>>> def func():
...   print foo # access the global foo
...
>>> func()
5
>>> # it works!

"global foo" should raise a SyntaxError, similarly to what already
happens with "return":
>>> return foo
  File "<stdin>", line 1
SyntaxError: 'return' outside function

----------
components: Interpreter Core
messages: 95299
nosy: benjamin.peterson, ezio.melotti
priority: normal
severity: normal
status: open
title: global statements outside functions/methods should raise SyntaxError
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Nov 15 16:41:37 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 15 Nov 2009 15:41:37 +0000
Subject: [issue3944] faster long multiplication
In-Reply-To: <1222165559.78.0.447355238601.issue3944@psf.upfronthosting.co.za>
Message-ID: <1258299697.74.0.844273307709.issue3944@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
priority: high -> normal

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

From report at bugs.python.org  Sun Nov 15 16:47:39 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 15 Nov 2009 15:47:39 +0000
Subject: [issue7251] Mark expected failures of test_math,
	test_cmath and test_round as such.
In-Reply-To: <1257154985.1.0.42933155819.issue7251@psf.upfronthosting.co.za>
Message-ID: <1258300059.72.0.326730369701.issue7251@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The tanh-related failures are no longer happening, since the FreeBSD 
buildbot was upgraded from FreeBSD 6.2 to FreeBSD 6.4.

I'm still worried by Skip's report, but that's a separate issue.

Closing.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Nov 15 17:55:29 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 15 Nov 2009 16:55:29 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1258304129.64.0.482581929424.issue2054@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

If we want to add SSL support then the patch in attachment modifies the 
last one as I described in my previous comment.
I re-run the tests and they are ok so I guess you can go on with the 
commit.

----------
Added file: http://bugs.python.org/file15343/ftplib.patch

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

From report at bugs.python.org  Sun Nov 15 18:06:48 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 15 Nov 2009 17:06:48 +0000
Subject: [issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)
In-Reply-To: <1256712581.76.0.435920152498.issue7228@psf.upfronthosting.co.za>
Message-ID: <1258304808.39.0.88027671727.issue7228@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Added extra #ifdef HAVE_LONG_LONG as suggested.

Committed to trunk in r76308.  I'm working on the merge to py3k, which 
isn't entirely straightforward.

----------

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

From report at bugs.python.org  Sun Nov 15 18:33:42 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 15 Nov 2009 17:33:42 +0000
Subject: [issue7329] global statements outside functions/methods should raise
	SyntaxError
In-Reply-To: <1258297827.42.0.98275960381.issue7329@psf.upfronthosting.co.za>
Message-ID: <1258306422.14.0.179829785382.issue7329@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Please bring this up on Python-dev if you'd like to change it. The fact
that there's a test verifying that this can happen suggests there is
some reason.

----------

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

From report at bugs.python.org  Sun Nov 15 18:50:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 15 Nov 2009 17:50:43 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1258307443.33.0.318229857628.issue2054@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The tests don't work under py3k, for some reason I can't figure out.
There's the following error and then the tests hang:

test_acct (test.test_ftplib.TestTLS_FTPClassMixin) ... Exception in
thread Thread-31:
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/threading.py", line 521, in
_bootstrap_inner
    self.run()
  File "/home/antoine/py3k/__svn__/Lib/test/test_ftplib.py", line 214,
in run
    asyncore.loop(timeout=0.1, count=1)
  File "/home/antoine/py3k/__svn__/Lib/asyncore.py", line 210, in loop
    poll_fun(timeout, map)
  File "/home/antoine/py3k/__svn__/Lib/asyncore.py", line 136, in poll
    r, w, e = select.select(r, w, e, timeout)
select.error: (9, 'Bad file descriptor')

----------
assignee: pitrou -> 
versions:  -Python 2.7

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

From report at bugs.python.org  Sun Nov 15 20:14:53 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 15 Nov 2009 19:14:53 +0000
Subject: [issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)
In-Reply-To: <1256712581.76.0.435920152498.issue7228@psf.upfronthosting.co.za>
Message-ID: <1258312493.16.0.601217693233.issue7228@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Just so I don't lose it, here's the current version of the forward merge 
of r76308 to py3k.

In testing this, I found some other possible bugs in the py3k 
implementation of PyUnicode_FromFormat;  I need to investigate and 
possibly fix those before this can be applied.

----------
Added file: http://bugs.python.org/file15344/add_lld_format_py3k.patch

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

From report at bugs.python.org  Sun Nov 15 20:42:34 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 15 Nov 2009 19:42:34 +0000
Subject: [issue7330] PyUnicode_FromFormat segfault when using widths.
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>


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

There seems to be something wrong with the width handling code in 
PyUnicode_FromFormat;  or perhaps I'm misusing it.

To reproduce:  replace the line

   return PyUnicode_FromFormat("range(%R, %R)", r->start, r->stop);

in range_repr in Objects/rangeobject.c with

   return PyUnicode_FromFormat("range(%20R, %20R)", r->start, r->stop);

On my machine (OS X 10.6), this results in a segfault when invoking 
range_repr:

Python 3.2a0 (py3k:76311M, Nov 15 2009, 19:16:40) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> range(0, 10)
Segmentation fault

Perhaps these modifiers aren't supposed to be used with a width?

----------
messages: 95306
nosy: mark.dickinson
severity: normal
status: open
title: PyUnicode_FromFormat segfault when using widths.
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Sun Nov 15 21:56:35 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 15 Nov 2009 20:56:35 +0000
Subject: [issue7325] tempfile.mkdtemp() does not return absolute pathname when
	dir is specified
In-Reply-To: <1258226856.45.0.72736645389.issue7325@psf.upfronthosting.co.za>
Message-ID: <1258318595.77.0.500723270097.issue7325@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

It's a border case for backporting. The docs do say it should be returning 
an absolute path, so that is a bug. And chances are anyone who has 
discovered this and is working around it simply called os.path.abspath() 
on the value instead of some manual calculation (if at all; bigger chance 
no one simply noticed).

My vote is to backport. Otherwise the docs should be updated for 2.6/3.1 
to mention the bug.

----------
nosy: +brett.cannon

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

From report at bugs.python.org  Sun Nov 15 22:03:32 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 15 Nov 2009 21:03:32 +0000
Subject: [issue7325] tempfile.mkdtemp() does not return absolute pathname when
	dir is specified
In-Reply-To: <1258226856.45.0.72736645389.issue7325@psf.upfronthosting.co.za>
Message-ID: <1258319012.44.0.594717191308.issue7325@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think we should be conservative. People may be relying on it *not*
returning an absolute path; besides, the bug itself wasn't a problem in
practice, so backporting the fix doesn't bring any added value.

----------
nosy: +pitrou

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

From report at bugs.python.org  Sun Nov 15 22:28:26 2009
From: report at bugs.python.org (Eric Smith)
Date: Sun, 15 Nov 2009 21:28:26 +0000
Subject: [issue7309] crasher in str(Exception())
In-Reply-To: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>
Message-ID: <1258320506.19.0.298257580915.issue7309@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I agree there's not much value in making the attributes read/write, but
it looks like all of the exceptions allow it, so I don't really want to
make these exceptions the only ones that are different.

----------

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

From report at bugs.python.org  Sun Nov 15 22:35:48 2009
From: report at bugs.python.org (Eric Smith)
Date: Sun, 15 Nov 2009 21:35:48 +0000
Subject: [issue7330] PyUnicode_FromFormat segfault when using widths.
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1258320948.64.0.12524760293.issue7330@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

It looks like PyUnicode_FromFormatV is computing callcount incorrectly.
It's looking for 'S', 'R', or 'A' immediately following '%', before the
width. It seems to me it should be treating them the same as 's',
although I'll admit to not having looked at it close enough to know
exactly what's going on.

The whole routine could use some attention, I think.

----------
nosy: +eric.smith

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

From report at bugs.python.org  Sun Nov 15 22:59:30 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 Nov 2009 21:59:30 +0000
Subject: [issue6816] Provide CPython command line functionality via runpy
	module
In-Reply-To: <1251802599.29.0.539498266032.issue6816@psf.upfronthosting.co.za>
Message-ID: <1258322370.88.0.0271539318987.issue6816@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The windows buildbots are reporting an odd error in test_runpy.  I can't
see by visual inspection why the test is failing:

http://www.python.org/dev/buildbot/stable/builders/x86%20XP-4%20trunk/builds/2615/steps/test/logs/stdio

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Sun Nov 15 23:20:24 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 15 Nov 2009 22:20:24 +0000
Subject: [issue6816] Provide CPython command line functionality via runpy
	module
In-Reply-To: <1251802599.29.0.539498266032.issue6816@psf.upfronthosting.co.za>
Message-ID: <1258323624.3.0.701691920691.issue6816@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The test is probably failing because the pattern is interpreted as a regex:
>>> re.match(r'\t', r'\t') is None
True

There is another problem, which is that test_runpy (or runpy itself) is
now leaking references:

test_runpy
beginning 6 repetitions
123456
......
test_runpy leaked [56, 56, 56] references, sum=168

----------
nosy: +pitrou

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

From report at bugs.python.org  Sun Nov 15 23:27:42 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Nov 2009 22:27:42 +0000
Subject: [issue7328] pydoc doesn't work from the command line
In-Reply-To: <1258295679.52.0.0670175954257.issue7328@psf.upfronthosting.co.za>
Message-ID: <1258324062.17.0.195977909449.issue7328@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

pydoc removes the "scriptdir" from sys.path. When run under -m, that
means it removes the standard library directory!

It works in 2.x because os.popen doesn't rely on subprocess there -
instead it comes direct from the builtin posix module.

----------

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

From report at bugs.python.org  Sun Nov 15 23:38:38 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Nov 2009 22:38:38 +0000
Subject: [issue7328] pydoc doesn't work from the command line
In-Reply-To: <1258295679.52.0.0670175954257.issue7328@psf.upfronthosting.co.za>
Message-ID: <1258324718.23.0.522836793612.issue7328@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Fixed in r76312 and subsequent checkins (pydoc was corrupting sys.path
when run under -m and getting away with it in 2.x, but breaking os.popen
in 3.x)

----------

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

From report at bugs.python.org  Sun Nov 15 23:38:49 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Nov 2009 22:38:49 +0000
Subject: [issue7328] pydoc doesn't work from the command line
In-Reply-To: <1258295679.52.0.0670175954257.issue7328@psf.upfronthosting.co.za>
Message-ID: <1258324729.1.0.539334186883.issue7328@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sun Nov 15 23:54:41 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Nov 2009 22:54:41 +0000
Subject: [issue6816] Provide CPython command line functionality via runpy
	module
In-Reply-To: <1251802599.29.0.539498266032.issue6816@psf.upfronthosting.co.za>
Message-ID: <1258325681.15.0.661794108376.issue6816@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The windows errors are most likely due to the fact that I'm not doubling
the backslashes in the file paths before passing them to
assertRaisesRegex() as the regular expression pattern.

The reference leak is also interesting, since there isn't any new C code
here. Although I do add quite a few new entries to the path importer
cache as part of the run_path tests - that might be enough to explain it.

----------

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

From report at bugs.python.org  Mon Nov 16 00:20:04 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Nov 2009 23:20:04 +0000
Subject: [issue6816] Provide CPython command line functionality via runpy
	module
In-Reply-To: <1251802599.29.0.539498266032.issue6816@psf.upfronthosting.co.za>
Message-ID: <1258327204.46.0.0260410019028.issue6816@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Hmm, definitely not the path importer cache - regrtest already takes
that into account by reverting it to its original state before checking
the reference counts.

----------

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

From report at bugs.python.org  Mon Nov 16 01:05:53 2009
From: report at bugs.python.org (David Bolen)
Date: Mon, 16 Nov 2009 00:05:53 +0000
Subject: [issue7293] test_msvc9compiler test_reg_class failure on new Windows
	box
In-Reply-To: <1257750000.16.0.245083157049.issue7293@psf.upfronthosting.co.za>
Message-ID: <1258329953.1.0.157385941749.issue7293@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

Our last comments may have crossed, but as I mentioned in my last one,
yes, as best I can tell from my slaves (XP+VS-Express, XP+VS-Standard,
Win7+VS-Standard), the Visual Studio key is present in a brand new
install.  Note that it is not present in a brand new XP or Windows7
install, but only after Visual Studio (Express or Standard) is
installed.  So it comes along with Visual Studio regardless of platform,
although the key does change according to VS version.

I think that should be fine, since the test is only running in a Visual
Studio environment to start with, so having a VS-based key should be
just as good as a Windows-based key.

----------

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

From report at bugs.python.org  Mon Nov 16 01:10:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Nov 2009 00:10:46 +0000
Subject: [issue7298] reversed(range(x, -1, -1)) is empty when x > 1
In-Reply-To: <1257848858.69.0.270094372501.issue7298@psf.upfronthosting.co.za>
Message-ID: <1258330246.83.0.0214783263186.issue7298@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Not sure whether it's related, but there is now a sizeable refleak:

test_range
beginning 6 repetitions
123456
......
test_range leaked [150, 150, 150] references, sum=450

----------
nosy: +pitrou

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

From report at bugs.python.org  Mon Nov 16 02:08:54 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Nov 2009 01:08:54 +0000
Subject: [issue5890] Subclassing property doesn't preserve the auto __doc__
	behavior
In-Reply-To: <1241129592.84.0.608165277997.issue5890@psf.upfronthosting.co.za>
Message-ID: <1258333734.04.0.672459650267.issue5890@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It seems to me that all that patch does is re-enable the bug (in the
extension class context) that the patch for this issue was a workaround
for.  I think perhaps the correct fix is to look at how the __doc__
attribute is found in the general case and see if it can be fixed there,
allowing the removal of the workaround in property.

See for example this sub-thread on python-dev:

http://www.mail-archive.com/python-dev at python.org/msg42786.html

----------

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

From report at bugs.python.org  Mon Nov 16 02:13:28 2009
From: report at bugs.python.org (Michael K Johnson)
Date: Mon, 16 Nov 2009 01:13:28 +0000
Subject: [issue1160] Medium size regexp crashes python
In-Reply-To: <1189670456.94.0.669298411185.issue1160@psf.upfronthosting.co.za>
Message-ID: <1258334008.56.0.180475284719.issue1160@psf.upfronthosting.co.za>


Michael K Johnson <a1237+pybugs at danlj.org> added the comment:

The test case at the top of this issue reproduces just fine; if you are
looking for a different test case you'll have to specify what you don't
like about it so that it's clear what you are looking for.

I don't think there's any mystery about this issue; it seems perfectly
well understood.  I commented merely to encourage others who run into
this issue to consider one way of using sets if they are running into
the same case I was, in which I was trying to use a regular expression
to match a candidate string against a large set of exact matches.

I was doing this because the initial purpose of the interface I was
working with was to allow small, hand-specified regular expressions;
this interface was later additionally wrapped in code that automatically
created regular expressions for this interface originally (and still
also) intended for use with hand-crafted regular expressions.  That's
why the interface was not originally crafted to use sets, and why it was
not appropriate to simply change the interface to use sets.  However, my
interface also allows passing a callable which resolves the object at
the time of use, and so I merely passed a reference to a method which
returned an object derived from set but which implemented the match and
search methods.

If you REALLY want a simpler reproducer, this does it for me in the
restricted case (i.e., not using UCS4 encoding):
 import re
 r = re.compile('|'.join(('%d'%x for x in range(7000))))

But I really don't think that additional test cases are a barrier here.

Again, my goal was merely to suggest an easy way to use sets as a
replacement for regexps, for machine-generated regexps intended to match
against exact strings; subclass set and add necessary methods such as
search and/or match.

----------

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

From report at bugs.python.org  Mon Nov 16 05:46:57 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Nov 2009 04:46:57 +0000
Subject: [issue6816] Provide CPython command line functionality via runpy
	module
In-Reply-To: <1251802599.29.0.539498266032.issue6816@psf.upfronthosting.co.za>
Message-ID: <1258346817.81.0.187368212278.issue6816@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

There's another cache in zipimport that wasn't being cleared when
hunting refleaks. I've updated that on the trunk and will include it in
the forward port to 3k (along with a fix for the Windows path separator
problem).

----------

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

From report at bugs.python.org  Mon Nov 16 07:14:55 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Nov 2009 06:14:55 +0000
Subject: [issue7331] Command line testing consistency between 2.x and 3.x
In-Reply-To: <1258352095.53.0.801407348476.issue7331@psf.upfronthosting.co.za>
Message-ID: <1258352095.53.0.801407348476.issue7331@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

I ran into a few gratuitous conflicts forward porting the command line
testing cleanup. This should be eliminated by making script_helper
sufficiently flexible to cover both the 2.x and 3.x use cases.

----------
assignee: ncoghlan
components: Tests
keywords: easy
messages: 95322
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Command line testing consistency between 2.x and 3.x
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Nov 16 07:58:47 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Nov 2009 06:58:47 +0000
Subject: [issue6816] Provide CPython command line functionality via runpy
	module
In-Reply-To: <1251802599.29.0.539498266032.issue6816@psf.upfronthosting.co.za>
Message-ID: <1258354727.28.0.421915344778.issue6816@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Added to Py3k in r76324 (including the fixes made on 2.x after the
original checkin)

----------
resolution:  -> accepted
status: open -> closed

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

From report at bugs.python.org  Mon Nov 16 07:59:02 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Nov 2009 06:59:02 +0000
Subject: [issue7331] Command line testing consistency between 2.x and 3.x
In-Reply-To: <1258352095.53.0.801407348476.issue7331@psf.upfronthosting.co.za>
Message-ID: <1258354742.17.0.160494403949.issue7331@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
priority: normal -> low

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

From report at bugs.python.org  Mon Nov 16 08:00:27 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Nov 2009 07:00:27 +0000
Subject: [issue5251] contextlib.nested inconsistent with, well,
	nested with statements due exceptions raised in __enter__
In-Reply-To: <1234548570.86.0.145574171135.issue5251@psf.upfronthosting.co.za>
Message-ID: <1258354827.42.0.882126603014.issue5251@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Lowering priority due to implementation of explicit syntax for multiple
context managers in a single with statement

----------
priority:  -> low

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

From report at bugs.python.org  Mon Nov 16 08:50:35 2009
From: report at bugs.python.org (liang)
Date: Mon, 16 Nov 2009 07:50:35 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>


New submission from liang <xfanliang at hotmail.com>:

In our testbed,we have seem serveral sgement fault in our python scrit.
The enviroment is:
linux=2.6.29.6-0.6.smp.gcc4.1.x86_64
python=2.4.4-41.4-1
GCC = GCC 4.1.2 20070626 (rPath Inc.)] on linux2
Below are the detail call stack:
(gdb) bt
#0  PyMarshal_ReadLastObjectFromFile (fp=0x73a550) at 
Python/marshal.c:748
#1  0x000000000047bbf9 in read_compiled_module 
(cpathname=0x7fff184ba600
"/usr/lib64/python2.4/sre_constants.pyc", 
fp=0x73a550) at Python/import.c:728
#2  0x000000000047da2c in load_source_module (name=0x7fff184bc740
"sre_constants", pathname=0x7fff184bb680 
"/usr/lib64/python2.4/sre_constants.py", fp=0x737df0)
    at Python/import.c:896
#3  0x000000000047e7bd in import_submodule (mod=0x6ea570,
subname=0x7fff184bc740 "sre_constants", fullname=0x7fff184bc740 
"sre_constants") at Python/import.c:2276
#4  0x000000000047ec3c in load_next (mod=0x6ea570, altmod=0x6ea570,
p_name=<value optimized out>, buf=0x7fff184bc740 
"sre_constants", p_buflen=0x7fff184bc73c)
    at Python/import.c:2096
#5  0x000000000047ee47 in PyImport_ImportModuleEx 
(name=0x7fff18bac298 "\001",
globals=0x7fff18bac2bc, locals=<value 
optimized out>, fromlist=0x7fff18c90990)
    at Python/import.c:1931
#6  0x000000000045f963 in builtin___import__ (self=<value optimized 
out>,
args=<value optimized out>) at 
Python/bltinmodule.c:45
#7  0x00000000004148e0 in PyObject_Call (func=0x73a550, arg=0x73a550,
kw=0x46e829e3) at Objects/abstract.c:1795
#8  0x00000000004628fd in PyEval_CallObjectWithKeywords 
(func=0x7fff18ca5440,
arg=0x7fff18c944c8, kw=0x0) at 
Python/ceval.c:3435
#9  0x000000000046461a in PyEval_EvalFrame (f=0x744650) at 
Python/ceval.c:2020
#10 0x0000000000468ce0 in PyEval_EvalCodeEx (co=0x7fff18c95ab0, 
globals=<value
optimized out>, locals=<value optimized out>, 
args=0x0, argcount=0, kws=0x0, kwcount=0,
    defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2741
#11 0x0000000000468d92 in PyEval_EvalCode (co=0x73a550, 
globals=0x73a550,
locals=0x46e829e3) at Python/ceval.c:484
#12 0x000000000047d29a in PyImport_ExecCodeModuleEx 
(name=0x7fff184bfce0
"sre_compile", co=0x7fff18c95ab0, 
pathname=0x7fff184bdba0 "/usr/lib64/python2.4/sre_compile.pyc")
    at Python/import.c:636
#13 0x000000000047d7d0 in load_source_module (name=0x7fff184bfce0
"sre_compile", pathname=0x7fff184bdba0 
"/usr/lib64/python2.4/sre_compile.pyc", fp=<value optimized out>)
    at Python/import.c:915
#14 0x000000000047e7bd in import_submodule (mod=0x6ea570,
subname=0x7fff184bfce0 "sre_compile", fullname=0x7fff184bfce0 
"sre_compile") at Python/import.c:2276
#15 0x000000000047ec3c in load_next (mod=0x6ea570, altmod=0x6ea570,
p_name=<value optimized out>, buf=0x7fff184bfce0 
"sre_compile", p_buflen=0x7fff184bfcdc)
    at Python/import.c:2096
#16 0x000000000047ee47 in PyImport_ImportModuleEx 
(name=0x7fff18c8fbd0 "\001",
globals=0x7fff18c8fbf4, locals=<value 
optimized out>, fromlist=0x6ea570) at Python/import.c:1931
#17 0x000000000045f963 in builtin___import__ (self=<value optimized 
out>,
args=<value optimized out>) at 
Python/bltinmodule.c:45
#18 0x00000000004148e0 in PyObject_Call (func=0x73a550, arg=0x73a550,
kw=0x46e829e3) at Objects/abstract.c:1795
#19 0x00000000004628fd in PyEval_CallObjectWithKeywords 
(func=0x7fff18ca5440,
arg=0x7fff18c94208, kw=0x0) at 
Python/ceval.c:3435
#20 0x000000000046461a in PyEval_EvalFrame (f=0x7b6680) at 
Python/ceval.c:2020
#21 0x0000000000468ce0 in PyEval_EvalCodeEx (co=0x7fff18c95500, 
globals=<value
optimized out>, locals=<value optimized out>, 
args=0x0, argcount=0, kws=0x0, kwcount=0,
    defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2741
#22 0x0000000000468d92 in PyEval_EvalCode (co=0x73a550, 
globals=0x73a550,
locals=0x46e829e3) at Python/ceval.c:484
#23 0x000000000047d29a in PyImport_ExecCodeModuleEx 
(name=0x7fff184c3280 "sre",
co=0x7fff18c95500, pathname=0x7fff184c1140 
"/usr/lib64/python2.4/sre.pyc")
    at Python/import.c:636
#24 0x000000000047d7d0 in load_source_module 
(name=0x7fff184c3280 "sre",
pathname=0x7fff184c1140 
"/usr/lib64/python2.4/sre.pyc", fp=<value optimized out>)
    at Python/import.c:915
#25 0x000000000047e7bd in import_submodule (mod=0x6ea570,
subname=0x7fff184c3280 "sre", fullname=0x7fff184c3280 "sre") at 
Python/import.c:2276
#26 0x000000000047ec3c in load_next (mod=0x6ea570, altmod=0x6ea570,
p_name=<value optimized out>, buf=0x7fff184c3280 "sre", 
p_buflen=0x7fff184c327c) at Python/import.c:2096
#27 0x000000000047ee47 in PyImport_ImportModuleEx 
(name=0x7fff18c8cc90 "\001",
globals=0x7fff18c8ccb4, locals=<value 
optimized out>, fromlist=0x7fff18c90450)
    at Python/import.c:1931
#28 0x000000000045f963 in builtin___import__ (self=<value optimized 
out>,
args=<value optimized out>) at 
Python/bltinmodule.c:45
#29 0x00000000004148e0 in PyObject_Call (func=0x73a550, arg=0x73a550,
kw=0x46e829e3) at Objects/abstract.c:1795
#30 0x00000000004628fd in PyEval_CallObjectWithKeywords 
(func=0x7fff18ca5440,
arg=0x7fff18c83788, kw=0x0) at 
Python/ceval.c:3435
#31 0x000000000046461a in PyEval_EvalFrame (f=0x753bb0) at 
Python/ceval.c:2020
#32 0x0000000000468ce0 in PyEval_EvalCodeEx (co=0x7fff18c8a7a0, 
globals=<value
optimized out>, locals=<value optimized out>, 
args=0x0, argcount=0, kws=0x0, kwcount=0,
    defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2741
#33 0x0000000000468d92 in PyEval_EvalCode (co=0x73a550, 
globals=0x73a550,
locals=0x46e829e3) at Python/ceval.c:484
#34 0x000000000047d29a in PyImport_ExecCodeModuleEx 
(name=0x7fff184c6820 "re",
co=0x7fff18c8a7a0, pathname=0x7fff184c46e0 
"/usr/lib64/python2.4/re.pyc") at Python/import.c:636
#35 0x000000000047d7d0 in load_source_module (name=0x7fff184c6820 "re",
pathname=0x7fff184c46e0 
"/usr/lib64/python2.4/re.pyc", fp=<value optimized out>) at 
Python/import.c:915
#36 0x000000000047e7bd in import_submodule (mod=0x6ea570,
subname=0x7fff184c6820 "re", fullname=0x7fff184c6820 "re") at 
Python/import.c:2276
#37 0x000000000047ec3c in load_next (mod=0x6ea570, altmod=0x6ea570,
p_name=<value optimized out>, buf=0x7fff184c6820 "re", 
p_buflen=0x7fff184c681c) at Python/import.c:2096
#38 0x000000000047ee47 in PyImport_ImportModuleEx 
(name=0x7fff18c8ca50 "\032",
globals=0x7fff18c8ca74, locals=<value 
optimized out>, fromlist=0x6ea570) at Python/import.c:1931
#39 0x000000000045f963 in builtin___import__ (self=<value optimized 
out>,
args=<value optimized out>) at 
Python/bltinmodule.c:45
#40 0x00000000004148e0 in PyObject_Call (func=0x73a550, arg=0x73a550,
kw=0x46e829e3) at Objects/abstract.c:1795
#41 0x00000000004628fd in PyEval_CallObjectWithKeywords 
(func=0x7fff18ca5440,
arg=0x7fff18c83680, kw=0x0) at 
Python/ceval.c:3435
#42 0x000000000046461a in PyEval_EvalFrame (f=0x7932d0) at 
Python/ceval.c:2020
#43 0x0000000000468ce0 in PyEval_EvalCodeEx (co=0x7fff18c8a730, 
globals=<value
optimized out>, locals=<value optimized out>, 
args=0x0, argcount=0, kws=0x0, kwcount=0,
    defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2741
#44 0x0000000000468d92 in PyEval_EvalCode (co=0x73a550, 
globals=0x73a550,
locals=0x46e829e3) at Python/ceval.c:484
#45 0x000000000047d29a in PyImport_ExecCodeModuleEx 
(name=0x7fff184c9dc0
"difflib", co=0x7fff18c8a730, 
pathname=0x7fff184c7c80 "/usr/lib64/python2.4/difflib.pyc")
    at Python/import.c:636
#46 0x000000000047d7d0 in load_source_module 
(name=0x7fff184c9dc0 "difflib",
pathname=0x7fff184c7c80 
"/usr/lib64/python2.4/difflib.pyc", fp=<value optimized out>)
    at Python/import.c:915
#47 0x000000000047e7bd in import_submodule (mod=0x6ea570,
subname=0x7fff184c9dc0 "difflib", fullname=0x7fff184c9dc0 
"difflib") at Python/import.c:2276
#48 0x000000000047ec3c in load_next (mod=0x6ea570, altmod=0x6ea570,
p_name=<value optimized out>, buf=0x7fff184c9dc0 
"difflib", p_buflen=0x7fff184c9dbc) at Python/import.c:2096
#49 0x000000000047ee47 in PyImport_ImportModuleEx 
(name=0x7fff18cb9300 "\001",
globals=0x7fff18cb9324, locals=<value 
optimized out>, fromlist=0x6ea570) at Python/import.c:1931
#50 0x000000000045f963 in builtin___import__ (self=<value optimized 
out>,
args=<value optimized out>) at 
Python/bltinmodule.c:45
#51 0x00000000004148e0 in PyObject_Call (func=0x73a550, arg=0x73a550,
kw=0x46e829e3) at Objects/abstract.c:1795
#52 0x00000000004628fd in PyEval_CallObjectWithKeywords 
(func=0x7fff18ca5440,
arg=0x7fff18c810a8, kw=0x0) at 
Python/ceval.c:3435
#53 0x000000000046461a in PyEval_EvalFrame (f=0x7921c0) at 
Python/ceval.c:2020
#54 0x0000000000468ce0 in PyEval_EvalCodeEx (co=0x7fff18623490, 
globals=<value
optimized out>, locals=<value optimized out>, 
args=0x0, argcount=0, kws=0x0, kwcount=0,
    defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2741
#55 0x0000000000468d92 in PyEval_EvalCode (co=0x73a550, 
globals=0x73a550,
locals=0x46e829e3) at Python/ceval.c:484
#56 0x00000000004853d9 in run_node (n=<value optimized out>, 
filename=<value
optimized out>, globals=0x718650, 
locals=0x718650, flags=<value optimized out>)
    at Python/pythonrun.c:1285
#57 0x00000000004868b8 in PyRun_SimpleFileExFlags (fp=<value optimized 
out>,
filename=0x7fff184ccbcc 
"/usr/local/maui/ganglia/lib/ganglia/python_modules/maui_svc.py",
    closeit=1, flags=0x7fff184cb350) at Python/pythonrun.c:869
#58 0x000000000041168d in Py_Main (argc=<value optimized out>,
argv=0x7fff184cb478) at Modules/main.c:493
#59 0x00007fff177f48a4 in __libc_start_main () from /lib64/libc.so.6
#60 0x0000000000410a59 in _start ()
Segment fault when it try to load sre_constants.pyc.

Another stack:

#0  PyMarshal_ReadLastObjectFromFile (fp=0x7f33f0) at 
Python/marshal.c:748
#1  0x000000000047bbf9 in read_compiled_module 
(cpathname=0x7fff069fe830
"/usr/lib64/python2.4/inspect.pyc", fp=0x7f33f0) at Python/import.c:728
#2  0x000000000047da2c in load_source_module 
(name=0x7fff06a00970 "inspect",
pathname=0x7fff069ff8b0 "/usr/lib64/python2.4/inspect.py", 
fp=0x7d97d0) at
Python/import.c:896
#3  0x000000000047e7bd in import_submodule (mod=0x6ea570,
subname=0x7fff06a00970 "inspect", fullname=0x7fff06a00970 "inspect") at
Python/import.c:2276
#4  0x000000000047ec3c in load_next (mod=0x6ea570, altmod=0x6ea570,
p_name=<value optimized out>, buf=0x7fff06a00970 "inspect",
p_buflen=0x7fff06a0096c) at Python/import.c:2096

Segment fault when it try to load inspect.pyc.

Another core at:
(gdb) bt
#0  PyMarshal_ReadLastObjectFromFile (fp=0x7dd190) at 
Python/marshal.c:748
#1  0x000000000047bbf9 in read_compiled_module 
(cpathname=0x7fff1bc03de0
"/usr/lib64/python2.4/string.pyc", fp=0x7dd190) at Python/import.c:728
#2  0x000000000047da2c in load_source_module 
(name=0x7fff1bc05f20 "string",
pathname=0x7fff1bc04e60 "/usr/lib64/python2.4/string.py", fp=0x7dc6f0) 
at
Python/import.c:896
#3  0x000000000047e7bd in import_submodule (mod=0x6ea570,
subname=0x7fff1bc05f20 "string", fullname=0x7fff1bc05f20 "string") at
Python/import.c:2276
#4  0x000000000047ec3c in load_next (mod=0x6ea570, altmod=0x6ea570,
p_name=<value optimized out>, buf=0x7fff1bc05f20 "string",
p_buflen=0x7fff1bc05f1c) at Python/import.c:2096
#5  0x000000000047ee47 in PyImport_ImportModuleEx 
(name=0x7fff1c6694b0 "\001",
globals=0x7fff1c6694d4, locals=<value optimized out>, 
fromlist=0x6ea570) at
Python/import.c:1931
#6  0x000000000045f963 in builtin___import__ (self=<value optimized 
out>,
args=<value optimized out>) at Python/bltinmodule.c:45
#7  0x00000000004148e0 in PyObject_Call (func=0x7dd190, arg=0x7dd190,
kw=0x46e829e3) at Objects/abstract.c:1795
#8  0x00000000004628fd in PyEval_CallObjectWithKeywords 
(func=0x7fff1c741440,
arg=0x7fff1c663890, kw=0x0) at Python/ceval.c:3435
#9  0x000000000046461a in PyEval_EvalFrame (f=0x744650) at 
Python/ceval.c:2020
#10 0x0000000000468ce0 in PyEval_EvalCodeEx (co=0x7fff1c66a8f0, 
globals=<value
optimized out>, locals=<value optimized out>, args=0x0, argcount=0, 
kws=0x0,
kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2741
#11 0x0000000000468d92 in PyEval_EvalCode (co=0x7dd190, 
globals=0x7dd190,
locals=0x46e829e3) at Python/ceval.c:484
#12 0x000000000047d29a in PyImport_ExecCodeModuleEx 
(name=0x7fff1bc094c0
"inspect", co=0x7fff1c66a8f0, pathname=0x7fff1bc07380
"/usr/lib64/python2.4/inspect.pyc") at Python/import.c:636
#13 0x000000000047d7d0 in load_source_module 
(name=0x7fff1bc094c0 "inspect",
pathname=0x7fff1bc07380 "/usr/lib64/python2.4/inspect.pyc", fp=<value 
optimized
out>) at Python/import.c:915
#14 0x000000000047e7bd in import_submodule (mod=0x6ea570,
subname=0x7fff1bc094c0 "inspect", fullname=0x7fff1bc094c0 "inspect") at
Python/import.c:2276
#15 0x000000000047ec3c in load_next (mod=0x6ea570, altmod=0x6ea570,
p_name=<value optimized out>, buf=0x7fff1bc094c0 "inspect",
p_buflen=0x7fff1bc094bc) at Python/import.c:2096
#16 0x000000000047ee47 in PyImport_ImportModuleEx 
(name=0x7fff1c65dba0 "\002",
globals=0x7fff1c65dbc4, locals=<value optimized out>, 
fromlist=0x6ea570) at
Python/import.c:1931

Segment fault when it try to load string.pyc.

We have seen it several times.However,the script is long running and 
we can not sure how it happened and how to make it reproduce.

Does anyone have any ideas on this?

----------
components: Interpreter Core
messages: 95325
nosy: liang
severity: normal
status: open
title: python script segment fault at PyMarshal_ReadLastObjectFromFile in import_submodule
type: crash
versions: Python 2.4

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

From report at bugs.python.org  Mon Nov 16 09:17:34 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 16 Nov 2009 08:17:34 +0000
Subject: [issue7298] reversed(range(x, -1, -1)) is empty when x > 1
In-Reply-To: <1257848858.69.0.270094372501.issue7298@psf.upfronthosting.co.za>
Message-ID: <1258359454.79.0.458033867256.issue7298@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Antoine.  I'll investigate.

----------

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

From report at bugs.python.org  Mon Nov 16 09:37:20 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 16 Nov 2009 08:37:20 +0000
Subject: [issue7298] reversed(range(x, -1, -1)) is empty when x > 1
In-Reply-To: <1257848858.69.0.270094372501.issue7298@psf.upfronthosting.co.za>
Message-ID: <1258360640.15.0.629041819792.issue7298@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Looks like Benjamin already fixed the refleak in r76319, r76320.

----------

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

From report at bugs.python.org  Mon Nov 16 09:47:33 2009
From: report at bugs.python.org (Thomas Courbon)
Date: Mon, 16 Nov 2009 08:47:33 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1258361252.96.0.362442050728.issue4953@psf.upfronthosting.co.za>


Thomas Courbon <harthie at yahoo.fr> added the comment:

It seems that there wasn't work on that issue (which look complicated by
the way). I'll wait, there is so much other aspects of a web framework
to play with :)
Thank anyway for the pointer.

----------

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

From report at bugs.python.org  Mon Nov 16 09:59:09 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Mon, 16 Nov 2009 08:59:09 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1221572918.25.0.474796677446.issue3881@psf.upfronthosting.co.za>
Message-ID: <1258361949.5.0.35315104649.issue3881@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

This patch had unintended consequences; see #6906

----------

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

From report at bugs.python.org  Mon Nov 16 10:36:59 2009
From: report at bugs.python.org (Alexander Belchenko)
Date: Mon, 16 Nov 2009 09:36:59 +0000
Subject: [issue1616979] cp720 encoding map
Message-ID: <1258364219.61.0.282578468119.issue1616979@psf.upfronthosting.co.za>


Alexander Belchenko <bialix at users.sourceforge.net> added the comment:

As the author of original patch I want to note that it seems your merged
patch does not update the documentation (list of standard encodings).

Please, update the docs as well.

----------

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

From report at bugs.python.org  Mon Nov 16 10:38:28 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Mon, 16 Nov 2009 09:38:28 +0000
Subject: [issue7329] global statements outside functions/methods should raise
	SyntaxError
In-Reply-To: <1258297827.42.0.98275960381.issue7329@psf.upfronthosting.co.za>
Message-ID: <1258364308.08.0.597319937904.issue7329@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

The compiler doesn't know how the code is going to be used apart from 
the "mode" parameter:

py> c=compile("x=1","","exec")
py> import dis
py> dis.dis(c)
  1           0 LOAD_CONST               0 (1)
              3 STORE_NAME               0 (x)
              6 LOAD_CONST               1 (None)
              9 RETURN_VALUE
py> c=compile("global x; x=1","","exec")
py> dis.dis(c)
  1           0 LOAD_CONST               0 (1)
              3 STORE_GLOBAL             0 (x)
              6 LOAD_CONST               1 (None)
              9 RETURN_VALUE

The generated code is different, and I may exec it at global or local 
scope, with different results. 

compile would require a new mode, different from "exec", to 
mean "compile this as a module at global scope; forbid global 
statements"

If not, this would become invalid:

def foo():
  c=compile("global x; x=1","","exec")
  exec c

since -at the compile phase- the code is indistinghishable from a 
module.

Also, since PEP3003 has been approved (moratorium), language changes 
like this will have to wait a few years.

----------
nosy: +gagenellina

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

From report at bugs.python.org  Mon Nov 16 10:43:35 2009
From: report at bugs.python.org (David Bolen)
Date: Mon, 16 Nov 2009 09:43:35 +0000
Subject: [issue7293] test_msvc9compiler test_reg_class failure on new Windows
	box
In-Reply-To: <1257750000.16.0.245083157049.issue7293@psf.upfronthosting.co.za>
Message-ID: <1258364615.14.0.318005236504.issue7293@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

Oh, Tarek, something I missed in your last comment - for the "Build
Timing" key, it should probably permit the value to be either 0 or 1,
just as the current test does.  Just in case someone happens to have
build timing turned on.

----------

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

From report at bugs.python.org  Mon Nov 16 10:49:57 2009
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Mon, 16 Nov 2009 09:49:57 +0000
Subject: [issue7309] crasher in str(Exception())
In-Reply-To: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>
Message-ID: <1258364997.79.0.652732888281.issue7309@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

>> I'm not sure what the functions should do when start and end are
>> out of range.
>
> I think the best approach would be to prevent these values to be out of
> range in the first place. 

The start and end values should be clipped, just like normal slices in
Python do:

>>> ""[2**30:2**30+1]
''

> I agree there's not much value in making the attributes read/write,
> but it looks like all of the exceptions allow it, so I don't really
> want to make these exceptions the only ones that are different.

Exception attributes *must* be read/write, because the codecs create an
exception object once, and then uses this exception object to
communicate multiple errors to the callback. PEP 293 states: "Should
further encoding errors occur, the encoder is allowed to reuse the
exception object for the next call to the callback."

----------
nosy: +doerwalter

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

From report at bugs.python.org  Mon Nov 16 10:52:51 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 16 Nov 2009 09:52:51 +0000
Subject: [issue7309] crasher in str(Exception())
In-Reply-To: <1258023049.96.0.905367835129.issue7309@psf.upfronthosting.co.za>
Message-ID: <1258365171.71.0.804643245925.issue7309@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Thanks, Walter. I'll finish my patch, then.

----------

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

From report at bugs.python.org  Mon Nov 16 11:13:45 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 16 Nov 2009 10:13:45 +0000
Subject: [issue1616979] cp720 encoding map
Message-ID: <1258366425.41.0.290209046986.issue1616979@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I think it is, see r74006 and
http://docs.python.org/dev/library/codecs.html#standard-encodings
(this is the doc for the future 2.7 version)

----------

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

From report at bugs.python.org  Mon Nov 16 11:19:29 2009
From: report at bugs.python.org (Alexander Belchenko)
Date: Mon, 16 Nov 2009 10:19:29 +0000
Subject: [issue1616979] cp720 encoding map
Message-ID: <1258366769.84.0.424602615973.issue1616979@psf.upfronthosting.co.za>


Alexander Belchenko <bialix at users.sourceforge.net> added the comment:

OK, thanks.

----------

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

From report at bugs.python.org  Mon Nov 16 11:42:24 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 16 Nov 2009 10:42:24 +0000
Subject: [issue7293] test_msvc9compiler test_reg_class failure on new Windows
	box
In-Reply-To: <1257750000.16.0.245083157049.issue7293@psf.upfronthosting.co.za>
Message-ID: <1258368144.84.0.709414228182.issue7293@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I made a test on my Express edition on the "FullScreen" value, but I
don't have a "Build Time" one.

Do you have a "FullScreen" key ?

can you run this in a shell, to see what value you get for FullScreen, 
and for build time ? (I find it strange that this one has a space btw, I
couldn't find a key with a space on my side)

>>> from distutils.msvc9compiler import Reg
>>> path = r'Software\Microsoft\VisualStudio\9.0'
>>> Reg.get_value(path, u"fullscreen")
>>> Reg.get_value(path, u"build timing")

If you get a value for fullscreen, we can have the same test for VC9 and
VCExpress.

----------

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

From report at bugs.python.org  Mon Nov 16 12:11:52 2009
From: report at bugs.python.org (David Bolen)
Date: Mon, 16 Nov 2009 11:11:52 +0000
Subject: [issue7293] test_msvc9compiler test_reg_class failure on new Windows
	box
In-Reply-To: <1257750000.16.0.245083157049.issue7293@psf.upfronthosting.co.za>
Message-ID: <1258369912.87.0.0989345537282.issue7293@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

The "Build Timing" key (not Build Time) is the only one at all under
HKCU/VisualStudio/9.0/VC (and actually the only key under the entire
HKCU/VisualStudio tree) on both my XP and Win7 new VS 2008 installation.
 I can't rule out it being part of SP1 which I included in the install,
though I found references on the web to it earlier than that.

It's strange though, because I've also verified that key on the older XP
build slave that was installed with VC Express (and never was installed
with the full version, nor did I use any service packs other than what
was part of VC Express), so I'm a bit surprised that you don't have it
in your install.

I don't have Fullscreen keys in that tree, although I did find a
Fullscreen key under HKCU/Software/Microsoft/VCExpress/9.0 just on my
express installation on XP.  It's possible that key only gets created
when you actually run Visual Studio (which I generally don't on
buildbots), but I suspect the path would differ between express and regular.

There's nothing else that looks viable under HKCU, at least related to
Visual Studio.  All of my other brand-new-install keys are under HKLM
instead, but there's a larger divergence between express and standard. 
It appears that on VC express most keys end up under
HKLM/Software/Microsoft/VCExpress/9.0, while under VS 2008 standard
they're the same path but "VisualStudio" instead.

Another choice that might be pretty safe as an alternate possibility,
but you have to be willing to separate the express and standard checks,
is the HKLM/Software/Microsoft/XXXX/9.0/ApplicationID key.  XXXX is
"VCExpress" or "VisualStudio" and that's also the value of that key.

Alternatively, as siblings to the ApplicationID key, I have two keys
that have common values between the express and standard installs:
"EnablePreloadCLR" and "RestoreAppPath" are both 1 in all installs.  I'm
guessing both represent boolean flags so accepting either 0 or 1 would
work, but that's a guess, so the ApplicationID key may be a better choice.

----------

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

From report at bugs.python.org  Mon Nov 16 12:20:37 2009
From: report at bugs.python.org (David Bolen)
Date: Mon, 16 Nov 2009 11:20:37 +0000
Subject: [issue7293] test_msvc9compiler test_reg_class failure on new Windows
	box
In-Reply-To: <1257750000.16.0.245083157049.issue7293@psf.upfronthosting.co.za>
Message-ID: <1258370437.98.0.638258915477.issue7293@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

Oh, BTW, you were missing the VC part of the path in your test.  But if
I run the same code with that corrected on my Win7 box, I get:

>>> from distutils.msvc9compiler import Reg
>>> path = r'Software\Microsoft\VisualStudio\9.0'
>>> Reg.get_value(path, u"fullscreen")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\python\2.6\lib\distutils\msvc9compiler.py", line 62, in get_value
    raise KeyError(key)
KeyError: u'fullscreen'
>>> path = r'Software\Microsoft\VisualStudio\9.0\VC'
>>> Reg.get_value(path, u"build timing")
0

I get the same results on my XP+VS 2008 box but also on my XP + VC
Express box.  (E.g., "fullscreen" doesn't work on any of them)

----------

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

From report at bugs.python.org  Mon Nov 16 12:49:34 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 16 Nov 2009 11:49:34 +0000
Subject: [issue7293] test_msvc9compiler test_reg_class failure on new Windows
	box
In-Reply-To: <1257750000.16.0.245083157049.issue7293@psf.upfronthosting.co.za>
Message-ID: <1258372174.12.0.827424512577.issue7293@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Ok so, can you confirm this is working on your side ?

VisualStudio 9:

>>> from distutils.msvc9compiler import Reg
>>> path = r'Software/Microsoft/VisualStudio/9.0'
>>> Reg.get_value(path, u"applicationid")
'VisualStudio'
>>> import _winreg
>>> HKCU = _winreg.HKEY_CURRENT_USER
>>> 'VisualStudio' in Reg.read_keys(HKCU, r'Software\Microsoft')
True


VCExpress 9: (works for me on Windows XP - VC ++9.0 Express edition)

>>> from distutils.msvc9compiler import Reg
>>> path = r'Software/Microsoft/VCExpress/9.0'
>>> Reg.get_value(path, u"applicationid")
'VCExpress'
>>> import _winreg
>>> HKCU = _winreg.HKEY_CURRENT_USER
>>> 'VisualStudio' in Reg.read_keys(HKCU, r'Software\Microsoft')
True

----------

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

From report at bugs.python.org  Mon Nov 16 13:22:05 2009
From: report at bugs.python.org (David Bolen)
Date: Mon, 16 Nov 2009 12:22:05 +0000
Subject: [issue7293] test_msvc9compiler test_reg_class failure on new Windows
	box
In-Reply-To: <1257750000.16.0.245083157049.issue7293@psf.upfronthosting.co.za>
Message-ID: <1258374125.81.0.171092421921.issue7293@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

Yes to both examples (the first on my VS 2008 full installs on XP and
Windows 7, and the second on my XP with VC++ Express).

Two caveats (that I don't think invalidates the result) though.

First, I can't use forward slashes in the path I supply to
Reg.get_value, they have to be backslashes.  But I'm running the tests
under a Python 2.6.x, so perhaps this was changed in a later release.

At least in my case, the results of Reg.get_value() are unicode strings,
not regular strings.  I thought perhaps your code was under Python 3.x,
but then I saw you were still using u"applicationid" so I'm not sure.

----------

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

From report at bugs.python.org  Mon Nov 16 14:27:11 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 16 Nov 2009 13:27:11 +0000
Subject: [issue7293] test_msvc9compiler test_reg_class failure on new Windows
	box
In-Reply-To: <1257750000.16.0.245083157049.issue7293@psf.upfronthosting.co.za>
Message-ID: <1258378031.81.0.464245896617.issue7293@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Ooops my bet, that's a typo, it's backlashes you are right.


I'll change the test now, thanks a lot for all the feedback !

----------
priority:  -> normal
resolution:  -> accepted

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

From report at bugs.python.org  Mon Nov 16 14:28:18 2009
From: report at bugs.python.org (Moriyoshi Koizumi)
Date: Mon, 16 Nov 2009 13:28:18 +0000
Subject: [issue5890] Subclassing property doesn't preserve the auto __doc__
	behavior
In-Reply-To: <1241129592.84.0.608165277997.issue5890@psf.upfronthosting.co.za>
Message-ID: <1258378098.48.0.868555117018.issue5890@psf.upfronthosting.co.za>


Moriyoshi Koizumi <mozo+python at mozo.jp> added the comment:

Sorry, I don't quite have an idea on the part "these patches reenable
the bug". The script of the first message yields exactly the same result
both with the original 2.6.4 and the patched.  Assuming the weirdness
you referred to is different from 5890, I'd say the workaround
introduced by the original patch to property class didn't correctly
avoid the issue in the first place. I mean the fix should be fixed anyhow.

----------

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

From report at bugs.python.org  Mon Nov 16 14:51:45 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Nov 2009 13:51:45 +0000
Subject: [issue5890] Subclassing property doesn't preserve the auto __doc__
	behavior
In-Reply-To: <1241129592.84.0.608165277997.issue5890@psf.upfronthosting.co.za>
Message-ID: <1258379505.87.0.0914228287506.issue5890@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, I haven't worked with boost or any other extension class that
defines a subclass of property.  If MyProp is such a subclass, would
print Fro.baz.__doc__ print "Get a baz" in 2.6.2 but raise an error in
2.6.3/4, or would it print None?

Regardless of which one it does, I think there is a better fix than
patching the original patch in this issue, assuming I can code it and
get approval to apply it.

On the other hand, the suggested 'refix' may be appropriate for 2.6.5.

----------

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

From report at bugs.python.org  Mon Nov 16 15:51:33 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 16 Nov 2009 14:51:33 +0000
Subject: [issue6906] Tkinter sets an unicode environment variable on win32
In-Reply-To: <1252920566.52.0.249075498328.issue6906@psf.upfronthosting.co.za>
Message-ID: <1258383093.96.0.894576066826.issue6906@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
nosy: +srid

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

From report at bugs.python.org  Mon Nov 16 15:53:09 2009
From: report at bugs.python.org (ivank)
Date: Mon, 16 Nov 2009 14:53:09 +0000
Subject: [issue6906] Tkinter sets an unicode environment variable on win32
In-Reply-To: <1252920566.52.0.249075498328.issue6906@psf.upfronthosting.co.za>
Message-ID: <1258383189.69.0.848928767613.issue6906@psf.upfronthosting.co.za>


ivank <ivan at ludios.org> added the comment:

The bug on the Twisted side may be of interest:
http://twistedmatrix.com/trac/ticket/3964

----------
nosy: +ivank

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

From report at bugs.python.org  Mon Nov 16 15:57:40 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 16 Nov 2009 14:57:40 +0000
Subject: [issue7333] Add initgroups to the posix/os modules
In-Reply-To: <1258383460.23.0.536261315778.issue7333@psf.upfronthosting.co.za>
Message-ID: <1258383460.23.0.536261315778.issue7333@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

initgroups(2) is a function for initializing the aux group id list from
site-specific configuration (typically /etc/groups, but not necessarily).

Attached is a patch based on some code from Zope, expanded to have a
test and some docs.  Presumably Zope will be happy to use this function
from the stdlib once they can depend on a version of Python which
includes it.  Twisted would like to as well.

I wasn't able to test the autoconf related parts of the patch as I don't
have easy access to autoconf 2.61.

I also can't run regrtest.py in my environment for some reason.  It
fails to import some names from test_support.  So I didn't run the unit
test that I added, either.

----------
components: Library (Lib)
files: initgroups.patch
keywords: patch
messages: 95348
nosy: exarkun
severity: normal
status: open
title: Add initgroups to the posix/os modules
versions: Python 2.7
Added file: http://bugs.python.org/file15345/initgroups.patch

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

From report at bugs.python.org  Mon Nov 16 16:56:09 2009
From: report at bugs.python.org (Gareth Doutch)
Date: Mon, 16 Nov 2009 15:56:09 +0000
Subject: [issue7334] XML file locking in Jython 2.5 (OSError on Windows)
In-Reply-To: <1258386968.95.0.507644857951.issue7334@psf.upfronthosting.co.za>
Message-ID: <1258386968.95.0.507644857951.issue7334@psf.upfronthosting.co.za>


New submission from Gareth Doutch <gareth.doutch at gmail.com>:

I have a problem with an xml file locking after read and/or write.

I have a short sample code with unit test available here:
http://bugs.jython.org/file741/lock.py

Below are the
outputs from Jython and CPython (v 2.5.4).
 
I am using Jython 2.5.1 on Windows XP and java version "1.6.0_16".

>jython lock.py
E
======================================================================
ERROR: runTest (__main__.TestDelete)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "W:\testTeam\SIT\JySit\sit\scripts\lock.py", line 73, in tearDown
    os.remove(self.fileName)
  File "C:\jython2.5.1\Lib\os.py", line 342, in remove
    raise OSError(0, "couldn't delete file", path)
OSError: [Errno 0] couldn't delete file: 'C:\\testdir\\test.xml'
 
----------------------------------------------------------------------
Ran 1 test in 0.454s
 
FAILED (errors=1)
 
 
>python lock.py
.
----------------------------------------------------------------------
Ran 1 test in 0.015s
 
OK


The problem can be cured by applying the changes as per file:
http://bugs.jython.org/file742/ElementTree.py

----------
components: Windows, XML
messages: 95349
nosy: gdoutch
severity: normal
status: open
title: XML file locking in Jython 2.5 (OSError on Windows)
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Mon Nov 16 17:02:58 2009
From: report at bugs.python.org (Gareth Doutch)
Date: Mon, 16 Nov 2009 16:02:58 +0000
Subject: [issue7334] XML file locking in Jython 2.5 (OSError on Windows)
In-Reply-To: <1258386968.95.0.507644857951.issue7334@psf.upfronthosting.co.za>
Message-ID: <1258387378.03.0.864129765708.issue7334@psf.upfronthosting.co.za>


Gareth Doutch <gareth.doutch at gmail.com> added the comment:

This is on the Jython list:
http://bugs.jython.org/issue1479

----------

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

From report at bugs.python.org  Mon Nov 16 17:44:16 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 16 Nov 2009 16:44:16 +0000
Subject: [issue7302] Wrong link to Python Language Mapping Specification
In-Reply-To: <1257878367.72.0.0298687588938.issue7302@psf.upfronthosting.co.za>
Message-ID: <1258389856.26.0.682306590928.issue7302@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r76326.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Mon Nov 16 18:02:38 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 16 Nov 2009 17:02:38 +0000
Subject: [issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)
In-Reply-To: <1256712581.76.0.435920152498.issue7228@psf.upfronthosting.co.za>
Message-ID: <1258390958.42.0.742150696863.issue7228@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Merged to py3k in r76328.

----------

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

From report at bugs.python.org  Mon Nov 16 18:19:38 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 16 Nov 2009 17:19:38 +0000
Subject: [issue7286] odd exec() behavior or documentation
In-Reply-To: <1257662346.28.0.188136963391.issue7286@psf.upfronthosting.co.za>
Message-ID: <1258391978.67.0.324879794988.issue7286@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The docs already contain the following note:

   .. note::

      The default *locals* act as described for function :func:`locals`
below:
      modifications to the default *locals* dictionary should not be
attempted.
      Pass an explicit *locals* dictionary if you need to see effects of the
      code on *locals* after function :func:`exec` returns.

----------
resolution:  -> works for me
status: open -> closed

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

From report at bugs.python.org  Mon Nov 16 18:29:14 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 16 Nov 2009 17:29:14 +0000
Subject: [issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)
In-Reply-To: <1256712581.76.0.435920152498.issue7228@psf.upfronthosting.co.za>
Message-ID: <1258392554.81.0.415463060695.issue7228@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

ocean-city, now that "lld" and "llu" support has been added, could you 
retest this patch (offt_formats.patch) for me?

----------
Added file: http://bugs.python.org/file15346/offt_formats.patch

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

From report at bugs.python.org  Mon Nov 16 18:34:48 2009
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Pasternak?=)
Date: Mon, 16 Nov 2009 17:34:48 +0000
Subject: [issue6906] Tkinter sets an unicode environment variable on win32
In-Reply-To: <1258383189.69.0.848928767613.issue6906@psf.upfronthosting.co.za>
Message-ID: <4b018d35.100db80a.116c.073a@mx.google.com>


Micha? Pasternak <michal.dtz at gmail.com> added the comment:

I hit that bug with Twisted too - I tried to use AMP: http://twistedmatrix.com/trac/ticket/3931

----------

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

From report at bugs.python.org  Mon Nov 16 19:28:41 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 16 Nov 2009 18:28:41 +0000
Subject: [issue7335] int/long discrepancy when formatting zero with ".0d"
In-Reply-To: <1258396121.34.0.904400229223.issue7335@psf.upfronthosting.co.za>
Message-ID: <1258396121.34.0.904400229223.issue7335@psf.upfronthosting.co.za>


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

In Python 2.x we have:

>>> "%.0d" % 0
''
>>> "%.0d" % 0L
'0'

In Python 3.x:

>>> "%.0d" % 0
'0'

I think the 2.x behaviour for int comes directly from C's sprintf 
behaviour:  section 7.19.6.1, p8 of the C99 standard says:

"The result of converting a zero value with a precision of zero is no 
characters."

I'm not sure which the more sensible behaviour is, but in 2.x, int and 
long should behave in the same way.  Fixing long to behave like int 
seems both simplest and least likely to break existing code.

----------
components: Interpreter Core
messages: 95356
nosy: eric.smith, mark.dickinson
priority: normal
severity: normal
status: open
title: int/long discrepancy when formatting zero with ".0d"
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Mon Nov 16 19:52:08 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 16 Nov 2009 18:52:08 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1258397528.48.0.507851008575.issue2054@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

Can you attach the 3.x patch so that I can test it myself?
I tried to apply the current 2.x patch against the 3.x trunk but I get 
conflicts.

----------

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

From report at bugs.python.org  Mon Nov 16 20:11:16 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 16 Nov 2009 19:11:16 +0000
Subject: [issue7310] Unhelpful __repr__() in os.environ
In-Reply-To: <1258026841.53.0.960128215471.issue7310@psf.upfronthosting.co.za>
Message-ID: <1258398676.07.0.490908818411.issue7310@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

A unit test would be appreciated. It should check that the output looks
like a dict.

----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Mon Nov 16 20:23:34 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 16 Nov 2009 19:23:34 +0000
Subject: [issue7335] int/long discrepancy when formatting zero with "%.0d"
In-Reply-To: <1258396121.34.0.904400229223.issue7335@psf.upfronthosting.co.za>
Message-ID: <1258399414.74.0.915347554543.issue7335@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
title: int/long discrepancy when formatting zero with ".0d" -> int/long discrepancy when formatting zero with "%.0d"

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

From report at bugs.python.org  Mon Nov 16 22:33:59 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 16 Nov 2009 21:33:59 +0000
Subject: [issue7333] Add initgroups to the posix/os modules
In-Reply-To: <1258383460.23.0.536261315778.issue7333@psf.upfronthosting.co.za>
Message-ID: <1258407239.83.0.917435930924.issue7333@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

In case anyone is concerned about licensing issues, please see
<https://mail.zope.org/pipermail/zope-dev/2009-November/038289.html>

----------

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

From report at bugs.python.org  Tue Nov 17 00:08:31 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 16 Nov 2009 23:08:31 +0000
Subject: [issue7268] 2to3 execfile conversion changes behavior
In-Reply-To: <1257466136.74.0.490341354872.issue7268@psf.upfronthosting.co.za>
Message-ID: <1258412911.42.0.598665563991.issue7268@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I've fixed underlying compile() newline problem in the trunk and py3k.
However, I think that change is big enough that I don't want to to
backport it. I'm leaving this open to think about what to do with 2to3
in this situation.

----------
priority:  -> normal
resolution: invalid -> 
status: closed -> open

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

From report at bugs.python.org  Tue Nov 17 00:23:59 2009
From: report at bugs.python.org (R. Tyler Ballance)
Date: Mon, 16 Nov 2009 23:23:59 +0000
Subject: [issue7336] threading module not properly handling shutdown
In-Reply-To: <1258413839.38.0.430585773151.issue7336@psf.upfronthosting.co.za>
Message-ID: <1258413839.38.0.430585773151.issue7336@psf.upfronthosting.co.za>


New submission from R. Tyler Ballance <tyler at monkeypox.org>:

Receiving a traceback when shutting down an interpreter with threads 
spawned inside of it:

Traceback (most recent call last):
  File "/usr/lib/python2.6/threading.py", line 497, in __bootstrap
    self.__bootstrap_inner()
  File "/usr/lib/python2.6/threading.py", line 538, in __bootstrap_inner
    (self.name, _format_exc()))
  File "/usr/lib/python2.6/traceback.py", line 235, in format_exc
    etype, value, tb = sys.exc_info()
AttributeError: 'NoneType' object has no attribute 'exc_info'


According to mzz on #Python:

17:29 < mzz> rtyler: I think this is worth a bug report. If you look up 
threading.py:538 you'll find (assuming our line numbers match) that bit 
of code actually goes out of its way to deal with the shutdown problem 
I mentioned, but then it calls into the traceback module, which doesn't.

----------
components: Interpreter Core
messages: 95361
nosy: rtyler
severity: normal
status: open
title: threading module not properly handling shutdown
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Tue Nov 17 00:36:35 2009
From: report at bugs.python.org (Marien Zwart)
Date: Mon, 16 Nov 2009 23:36:35 +0000
Subject: [issue7336] threading module not properly handling shutdown
In-Reply-To: <1258413839.38.0.430585773151.issue7336@psf.upfronthosting.co.za>
Message-ID: <1258414595.37.0.803174559906.issue7336@psf.upfronthosting.co.za>


Changes by Marien Zwart <m_zwart at 123mail.org>:


----------
nosy: +marienz

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

From report at bugs.python.org  Tue Nov 17 00:49:36 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Mon, 16 Nov 2009 23:49:36 +0000
Subject: [issue7333] Add initgroups to the posix/os modules
In-Reply-To: <1258383460.23.0.536261315778.issue7333@psf.upfronthosting.co.za>
Message-ID: <1258415376.52.0.34154691038.issue7333@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

The test should skip when not hasattr(os, 'initgroups') since it's 
optional

----------
nosy: +pjenvey

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

From report at bugs.python.org  Tue Nov 17 00:53:59 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 16 Nov 2009 23:53:59 +0000
Subject: [issue7333] Add initgroups to the posix/os modules
In-Reply-To: <1258383460.23.0.536261315778.issue7333@psf.upfronthosting.co.za>
Message-ID: <1258415639.92.0.687923407527.issue7333@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Good point.  Updated patch attached.

----------
Added file: http://bugs.python.org/file15347/initgroups-2.patch

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

From report at bugs.python.org  Tue Nov 17 01:09:59 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Nov 2009 00:09:59 +0000
Subject: [issue7336] traceback module not properly printing exceptions on
	interpreter shutdown
In-Reply-To: <1258413839.38.0.430585773151.issue7336@psf.upfronthosting.co.za>
Message-ID: <1258416599.12.0.808108858315.issue7336@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Library (Lib) -Interpreter Core
nosy: +gps, jyasskin
priority:  -> normal
stage:  -> needs patch
title: threading module not properly handling shutdown -> traceback module not properly printing exceptions on interpreter shutdown
type: crash -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Nov 17 05:14:48 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Tue, 17 Nov 2009 04:14:48 +0000
Subject: [issue1757126] [PATCH] Fix ptcp154 encoding cyrillic_asian alias
Message-ID: <1258431288.73.0.277472958813.issue1757126@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

fixed in r76337, r76338

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Tue Nov 17 05:15:33 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Tue, 17 Nov 2009 04:15:33 +0000
Subject: [issue7334] XML file locking in Jython 2.5 (OSError on Windows)
In-Reply-To: <1258386968.95.0.507644857951.issue7334@psf.upfronthosting.co.za>
Message-ID: <1258431333.48.0.577553304748.issue7334@psf.upfronthosting.co.za>


Changes by Philip Jenvey <pjenvey at underboss.org>:


----------
assignee:  -> pjenvey
nosy: +pjenvey
versions: +Python 2.7, Python 3.2 -Python 2.5

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

From report at bugs.python.org  Tue Nov 17 06:11:17 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 17 Nov 2009 05:11:17 +0000
Subject: [issue1087] py3k os.popen result is not iterable, patch attached
In-Reply-To: <1194531480.0.0.141906660951.issue1087@psf.upfronthosting.co.za>
Message-ID: <1258434677.26.0.427372467282.issue1087@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

While I was working on EnvironTests I found 'test_os_popen_iter' (added
in r58912) and I don't see why it is there.
Christian, did you put it in the wrong place by mistake or is it somehow
related to os.environ?
(the test should also use unittest.skipUnless(os.path.exists("/bin/sh"))
instead of the 'if')

----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Tue Nov 17 08:21:04 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 17 Nov 2009 07:21:04 +0000
Subject: [issue7310] Unhelpful __repr__() in os.environ
In-Reply-To: <1258026841.53.0.960128215471.issue7310@psf.upfronthosting.co.za>
Message-ID: <1258442464.55.0.633921372623.issue7310@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file15327/issue7310.diff

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

From report at bugs.python.org  Tue Nov 17 08:42:54 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 17 Nov 2009 07:42:54 +0000
Subject: [issue7310] Unhelpful __repr__() in os.environ
In-Reply-To: <1258026841.53.0.960128215471.issue7310@psf.upfronthosting.co.za>
Message-ID: <1258443774.38.0.817621715712.issue7310@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

New patch that includes a unittest.

I was also considering to replace the repr() with something that looks
like _Environ({dict-here}). That will still contain all the information
and also clarify that os.environ is not just a simple dict. (Even if
it's probably not relevant, if we want eval(repr(os.environ)) to work,
the repr() should also include the other args accepted by the _Environ()
constructor.)

If you think this is a good idea I can make a new patch, otherwise, if
the current patch is fine, I'll commit it as it is.

----------
Added file: http://bugs.python.org/file15348/issue7310.diff

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

From report at bugs.python.org  Tue Nov 17 09:23:41 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 17 Nov 2009 08:23:41 +0000
Subject: [issue5057] Unicode-width dependent optimization leads to
	non-portable pyc file
In-Reply-To: <1232900172.29.0.659028766072.issue5057@psf.upfronthosting.co.za>
Message-ID: <1258446221.92.0.781615229096.issue5057@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I have the same failure on trunk (narrow build).

----------
priority:  -> normal
stage:  -> needs patch
versions: +Python 3.2 -Python 3.0

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

From report at bugs.python.org  Tue Nov 17 09:27:16 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 17 Nov 2009 08:27:16 +0000
Subject: [issue5640] Wrong print() result when unicode error handler is not
	'strict'
In-Reply-To: <1238571303.14.0.143713902199.issue5640@psf.upfronthosting.co.za>
Message-ID: <1258446436.41.0.247672934695.issue5640@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
priority:  -> normal
stage: needs patch -> patch review

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

From report at bugs.python.org  Tue Nov 17 09:47:49 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 17 Nov 2009 08:47:49 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1258447669.32.0.577595336702.issue1578269@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

When building on XP with "windows symlink draft 15.patch", I get:

Build started: Project: _hashlib, Configuration: Release|Win32
Performing Pre-Build Event...
Found a working perl at 'c:\opt\cygwin\bin\perl.exe'
Found an SSL directory at '..\..\openssl-0.9.8g'
Traceback (most recent call last):
  File "build_ssl.py", line 258, in <module>
    main()
  File "build_ssl.py", line 241, in main
    shutil.copy(r"crypto\buildinf_%s.h" % arch, r"crypto\buildinf.h")
  File "C:\home\eric\python\py3k\lib\shutil.py", line 102, in copy
    copyfile(src, dst)
  File "C:\home\eric\python\py3k\lib\shutil.py", line 50, in copyfile
    if _samefile(src, dst):
  File "C:\home\eric\python\py3k\lib\shutil.py", line 40, in _samefile
    return os.path.samefile(src, dst)
  File "C:\home\eric\python\py3k\lib\ntpath.py", line 635, in samefile
    return _getfinalpathname(f1) == _getfinalpathname(f2)
NotImplementedError: GetFinalPathNameByHandle not available on this platform
Project : error PRJ0019: A tool returned an error code from "Performing
Pre-Build Event..."
Build log was saved at
"file://C:\home\eric\python\py3k\PCbuild\Win32-temp-Release\_hashlib\BuildLog
.htm"
_hashlib - 1 error(s), 0 warning(s)

----------

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

From report at bugs.python.org  Tue Nov 17 10:36:49 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Nov 2009 09:36:49 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1258450609.28.0.703233697746.issue2054@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is the current py3k patch I have, after resolving conflicts and
cleaning up the obvious problems.
After tracing a bit, it seems that ssl.wrap_socket() changes the socket
fileno under py3k, while it doesn't under trunk.

----------
Added file: http://bugs.python.org/file15349/ftptls-py3k.patch

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

From report at bugs.python.org  Tue Nov 17 10:43:05 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Nov 2009 09:43:05 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1258450985.08.0.884244587503.issue2054@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I now have a working patch. The main fix was to change
SSLConnection.secure_connection() to:

        def secure_connection(self):
            socket = ssl.wrap_socket([ ##etc. ])
            self.del_channel()
            self.set_socket(socket)
            self._ssl_accepting = True

Can you take a look?

----------
Added file: http://bugs.python.org/file15350/ftptls-py3k-2.patch

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

From report at bugs.python.org  Tue Nov 17 10:45:35 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Nov 2009 09:45:35 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1258451135.05.0.159598074408.issue2054@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file15350/ftptls-py3k-2.patch

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

From report at bugs.python.org  Tue Nov 17 10:45:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Nov 2009 09:45:46 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1258451146.7.0.549224516456.issue2054@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file15351/ftptls-py3k-2.patch

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

From report at bugs.python.org  Tue Nov 17 10:55:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Nov 2009 09:55:20 +0000
Subject: [issue7333] Add initgroups to the posix/os modules
In-Reply-To: <1258383460.23.0.536261315778.issue7333@psf.upfronthosting.co.za>
Message-ID: <1258451720.63.0.616429746013.issue7333@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You can use the new test-skipping feature:
http://docs.python.org/dev/library/unittest.html#skipping-tests-and-expected-failures

----------
nosy: +pitrou

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

From report at bugs.python.org  Tue Nov 17 11:07:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Nov 2009 10:07:20 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1258452440.59.0.260075389973.issue7060@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't think this is a blocker anymore. Kristj?n's patch has been
ported and the test_multiprocessing freezes have been "fixed" by adding
a timeout.
As for the original purpose of this ticket, issue7105 is still (part
of?) the answer.

----------
priority: release blocker -> normal

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

From report at bugs.python.org  Tue Nov 17 11:40:37 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 17 Nov 2009 10:40:37 +0000
Subject: [issue7291] urllib2 cannot handle https with proxy requiring auth
In-Reply-To: <1257741498.16.0.683281197284.issue7291@psf.upfronthosting.co.za>
Message-ID: <1258454437.95.0.870273018065.issue7291@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The patch looks good to me.

IMHO this should be backported to 2.6 as well.

----------
keywords: +needs review
nosy: +ronaldoussoren

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

From report at bugs.python.org  Tue Nov 17 11:40:41 2009
From: report at bugs.python.org (Ben Bass)
Date: Tue, 17 Nov 2009 10:40:41 +0000
Subject: [issue7337] Add lossy queue to queue library module
In-Reply-To: <1258454440.69.0.147012340761.issue7337@psf.upfronthosting.co.za>
Message-ID: <1258454440.69.0.147012340761.issue7337@psf.upfronthosting.co.za>


New submission from Ben Bass <benpaulbass at googlemail.com>:

Many applications would benefit from 'connectionless' queues, i.e. they 
don't want to care whether anything is reading from the other end.  
Using current queue module classes this is not practical, because there 
is a choice between unbounded memory consumption or blocking. I propose 
adding a 'LossyQueue' class in the queue module which would allow 
bounded memory consumption without blocking on put.  (i.e. items are 
dropped in fifo manner beyond a certain limit).  In my view this is at 
least as natural as the PriorityQueue and LifoQueue extensions in that 
module.

Outline as follows:

class LossyQueue(Queue):
    "Queue subclass which drops items on overflow"
    def _init(self, maxsize):
        if maxsize > 0:
            # build the deque with maxsize limit
            self.queue = deque(maxlen=maxsize)
        else:
            # same as normal Queue instance
            self.queue = collections.deque()
        # deque alone handles maxsize,
        # so we pretend we have none
        self.maxsize = 0

if there is interest in this I will offer a proper patch with docs and 
tests.

----------
components: Library (Lib)
messages: 95374
nosy: bpb
severity: normal
status: open
title: Add lossy queue to queue library module
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Nov 17 11:50:32 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 17 Nov 2009 10:50:32 +0000
Subject: [issue7318] multiprocessing should not wait endlessly
In-Reply-To: <1258140534.04.0.0239961207692.issue7318@psf.upfronthosting.co.za>
Message-ID: <1258455032.23.0.488597944612.issue7318@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

See also issue 7314

----------
nosy: +krisvale

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

From report at bugs.python.org  Tue Nov 17 11:50:49 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 17 Nov 2009 10:50:49 +0000
Subject: [issue7293] test_msvc9compiler test_reg_class failure on new Windows
	box
In-Reply-To: <1257750000.16.0.245083157049.issue7293@psf.upfronthosting.co.za>
Message-ID: <1258455049.89.0.821766033185.issue7293@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

There's one more thing we didn't take care of in our change: windows
platforms where people just install Python and run tests, so there's no
VC++ installed.

For them I guess we can use: r'Software\Microsoft\Windows\CurrentVersion'
and look for the u'productid' value, and just make sure its not empty.

Would you mind checking that you have this key on your windows
plartforms ? I've checked on XP.

----------

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

From report at bugs.python.org  Tue Nov 17 11:52:29 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 17 Nov 2009 10:52:29 +0000
Subject: [issue7291] urllib2 cannot handle https with proxy requiring auth
In-Reply-To: <1257741498.16.0.683281197284.issue7291@psf.upfronthosting.co.za>
Message-ID: <1258455149.39.0.968452028928.issue7291@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've tested a backport of the patch to 2.6 (just replace set_proxy by 
_set_proxy in the patch) and the resulting version of urllib2 can login to 
the proxy (as expected).

Thanks for the patch.

----------

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

From report at bugs.python.org  Tue Nov 17 11:53:14 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 17 Nov 2009 10:53:14 +0000
Subject: [issue7314] test_multiprocessing hangs in TestZZZNumberOfObjects
	after unittest traceback patch
In-Reply-To: <1258131175.63.0.744980392566.issue7314@psf.upfronthosting.co.za>
Message-ID: <1258455194.58.0.527899755003.issue7314@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Ok, I'm closing this as a duplicate.

----------
resolution:  -> duplicate
superseder:  -> multiprocessing should not wait endlessly

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

From report at bugs.python.org  Tue Nov 17 11:53:28 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 17 Nov 2009 10:53:28 +0000
Subject: [issue7314] test_multiprocessing hangs in TestZZZNumberOfObjects
	after unittest traceback patch
In-Reply-To: <1258131175.63.0.744980392566.issue7314@psf.upfronthosting.co.za>
Message-ID: <1258455208.53.0.30908257334.issue7314@psf.upfronthosting.co.za>


Changes by Kristj?n Valur J?nsson <kristjan at ccpgames.com>:


----------
status: open -> closed

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

From report at bugs.python.org  Tue Nov 17 11:57:29 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Nov 2009 10:57:29 +0000
Subject: [issue7316] Add a timeout functionality to common locking operations
In-Reply-To: <1258133508.5.0.728130823639.issue7316@psf.upfronthosting.co.za>
Message-ID: <1258455449.46.0.217553473301.issue7316@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This patch adds some docs and comments. It also adds the feature in the
non-semaphore path of thread_pthread.h, which I had forgotten to address.

----------
Added file: http://bugs.python.org/file15352/timedlock2.patch

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

From report at bugs.python.org  Tue Nov 17 11:58:08 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 17 Nov 2009 10:58:08 +0000
Subject: [issue7085] strptime problem
In-Reply-To: <1255042131.92.0.134837798932.issue7085@psf.upfronthosting.co.za>
Message-ID: <1258455488.07.0.215622876866.issue7085@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

FWIW, I've filed an issue with Apple for this: Radar #7330231

----------

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

From report at bugs.python.org  Tue Nov 17 12:01:34 2009
From: report at bugs.python.org (kai zhu)
Date: Tue, 17 Nov 2009 11:01:34 +0000
Subject: [issue7338] recursive __attribute__ -> Fatal Python error: Cannot
	recover from stack overflow.
In-Reply-To: <1258455694.17.0.877793280726.issue7338@psf.upfronthosting.co.za>
Message-ID: <1258455694.17.0.877793280726.issue7338@psf.upfronthosting.co.za>


New submission from kai zhu <kaizhu256 at gmail.com>:

Python 3.1.1 (r311:74480, Sep 13 2009, 17:17:12)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class Foo(object):
...   def __getattribute__(self, attr):
...     try: return object.__getattribute__(attr)
...     except: return self.x
...
>>> Foo().y
Fatal Python error: Cannot recover from stack overflow.
Aborted
$

python2.6 recovers from above w/ a RuntimeError

----------
components: Interpreter Core
messages: 95381
nosy: kaizhu
severity: normal
status: open
title: recursive __attribute__ -> Fatal Python error: Cannot recover from stack overflow.
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Tue Nov 17 12:10:24 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Nov 2009 11:10:24 +0000
Subject: [issue7338] recursive __attribute__ -> Fatal Python error: Cannot
	recover from stack overflow.
In-Reply-To: <1258455694.17.0.877793280726.issue7338@psf.upfronthosting.co.za>
Message-ID: <1258456224.63.0.899753605017.issue7338@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is normal. By doing "except: return self.x", you are reinvoking
__getattribute__ as soon as the RuntimeError is raised, and forcing the
interpreter into another infinite recursion.

----------
nosy: +loewis, pitrou

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

From report at bugs.python.org  Tue Nov 17 12:16:55 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 17 Nov 2009 11:16:55 +0000
Subject: [issue3962] single architecture framework build fails on OS X 10.5
In-Reply-To: <1222349749.71.0.779692324968.issue3962@psf.upfronthosting.co.za>
Message-ID: <1258456615.42.0.809250311127.issue3962@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
status: pending -> closed

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

From report at bugs.python.org  Tue Nov 17 12:55:15 2009
From: report at bugs.python.org (kai zhu)
Date: Tue, 17 Nov 2009 11:55:15 +0000
Subject: [issue3555] Regression: nested exceptions crash (Cannot recover from
	stack overflow)
In-Reply-To: <1218740615.84.0.303510238935.issue3555@psf.upfronthosting.co.za>
Message-ID: <1258458915.79.0.175900910004.issue3555@psf.upfronthosting.co.za>


kai zhu <kaizhu256 at gmail.com> added the comment:

just submitted a nearly identical bug (#7338) b4 checking for this one.
 so u think it works correctly up to the 2nd N+50 check.  can someone
give a reason y we should crash after that instead of throwing a
fallback RuntimeError?

----------
nosy: +kaizhu

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

From report at bugs.python.org  Tue Nov 17 14:04:18 2009
From: report at bugs.python.org (Thomas Guettler)
Date: Tue, 17 Nov 2009 13:04:18 +0000
Subject: [issue5673] Add timeout option to subprocess.Popen
In-Reply-To: <1238701276.41.0.515283298202.issue5673@psf.upfronthosting.co.za>
Message-ID: <1258463058.89.0.88140821912.issue5673@psf.upfronthosting.co.za>


Changes by Thomas Guettler <guettli at thomas-guettler.de>:


----------
nosy: +guettli

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

From report at bugs.python.org  Tue Nov 17 14:34:03 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 17 Nov 2009 13:34:03 +0000
Subject: [issue7333] Add initgroups to the posix/os modules
In-Reply-To: <1258383460.23.0.536261315778.issue7333@psf.upfronthosting.co.za>
Message-ID: <1258464843.63.0.211892509629.issue7333@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Alright.  Updated patch attached.

----------
Added file: http://bugs.python.org/file15353/initgroups-3.patch

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

From report at bugs.python.org  Tue Nov 17 14:35:04 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 17 Nov 2009 13:35:04 +0000
Subject: [issue7333] Add initgroups to the posix/os modules
In-Reply-To: <1258383460.23.0.536261315778.issue7333@psf.upfronthosting.co.za>
Message-ID: <1258464904.14.0.021416136035.issue7333@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

pyflakes told me I didn't import errno in test_posix.py.  Updated patch
attached.

----------
Added file: http://bugs.python.org/file15354/initgroups-4.patch

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

From report at bugs.python.org  Tue Nov 17 17:04:27 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 17 Nov 2009 16:04:27 +0000
Subject: [issue5614] Malloc errors in test_io
In-Reply-To: <1238450576.61.0.363286616174.issue5614@psf.upfronthosting.co.za>
Message-ID: <1258473867.79.0.532200702317.issue5614@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Closing the issue as this is not a bug in python (as noted in the 
comments) and there doesn't seem to be a workaround for avoiding the 
spurious messages on stderr.

----------
resolution:  -> wont fix
status: open -> closed
type: crash -> behavior

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

From report at bugs.python.org  Tue Nov 17 17:05:54 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Tue, 17 Nov 2009 16:05:54 +0000
Subject: [issue7316] Add a timeout functionality to common locking operations
In-Reply-To: <1258133508.5.0.728130823639.issue7316@psf.upfronthosting.co.za>
Message-ID: <1258473954.48.0.520173884773.issue7316@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

I don't object strongly, but since locks are "supposed" to be held for 
short amounts of time, a timeout shouldn't be that useful, and when 
people really need it they can put it together with a condition 
variable. Timeouts also interact poorly with condition variables: you 
can time out the initial acquire, but if you wait on a condition there's 
no place to put the timeout on the reacquire.

Given that it's hard to pick a timeout in most cases anyway, I think 
it'd be a much bigger win to figure out thread interruption. (Yes, I 
know that's hard, and that I promised to do it a long while ago and 
never got around to it.)

That said, I have no objections at all to adding an internal timeout 
ability for use by Condition.wait, and if you're still enthusiastic 
about adding the timeout given the above argument, I won't block you.

----------
nosy: +jyasskin

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

From report at bugs.python.org  Tue Nov 17 17:29:39 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Nov 2009 16:29:39 +0000
Subject: [issue7316] Add a timeout functionality to common locking operations
In-Reply-To: <1258473954.48.0.520173884773.issue7316@psf.upfronthosting.co.za>
Message-ID: <1258475392.3472.24.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Timeouts also interact poorly with condition variables: you 
> can time out the initial acquire, but if you wait on a condition there's 
> no place to put the timeout on the reacquire.

I don't see how it's an objection. If you have a condition variable you
just use the cv's timeout feature, don't you? I guess there are already
tons of combinations which don't make sense anyway.

> Given that it's hard to pick a timeout in most cases anyway, I think 
> it'd be a much bigger win to figure out thread interruption. (Yes, I 
> know that's hard, and that I promised to do it a long while ago and 
> never got around to it.)

What do you mean by thread interruption? Cancellation?

> That said, I have no objections at all to adding an internal timeout 
> ability for use by Condition.wait, and if you're still enthusiastic 
> about adding the timeout given the above argument, I won't block you.

Well, it's pretty basic functionality provided by the underlying OS
APIs, which is why I think it would be good to expose it. I remember
being annoyed by its absence, but it was a long time ago and I don't
remember which problem I was trying to solve.

(and it's safer than thread cancellation ;-))

----------

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

From report at bugs.python.org  Tue Nov 17 17:39:11 2009
From: report at bugs.python.org (Paul Colomiets)
Date: Tue, 17 Nov 2009 16:39:11 +0000
Subject: [issue7339] bsddb crashes when transaction limit occurs
In-Reply-To: <1258475951.23.0.0144447092049.issue7339@psf.upfronthosting.co.za>
Message-ID: <1258475951.23.0.0144447092049.issue7339@psf.upfronthosting.co.za>


New submission from Paul Colomiets <pc at gafol.net>:

When maximum transaction number exceeded and DBEnv->txn_begin returns
with error ENOMEM, error with following traceback occur:

#0  0x0000000803d4fa48 in DBTxn_dealloc (self=0x846480648) at _bsddb.c:1235
#1  0x0000000803d506dc in newDBTxnObject (myenv=0x804c23d98, parent=0x0,
txn=Variable "txn" is not available.
) at _bsddb.c:1179
#2  0x0000000803d50770 in DBEnv_txn_begin (self=0x804c23d98,
args=Variable "args" is not available.
) at _bsddb.c:4584
#3  0x0000000000523ea4 in PyCFunction_Call ()
[..snip..]

I believe that following patch will fix that problem:

Index: Modules/_bsddb.c
===================================================================
--- Modules/_bsddb.c	(revision 76338)
+++ Modules/_bsddb.c	(working copy)
@@ -1232,7 +1232,7 @@
     if (self->env) {
         Py_DECREF(self->env);
     } else {
-        Py_DECREF(self->parent_txn);
+        Py_XDECREF(self->parent_txn);
     }
     PyObject_Del(self);
 }

Seems that normally either env or parent_txn attribute is not null but
when transaction where not created it's untrue (look at the end of
newDBTxnObject if you don't trust :) )

----------
components: Library (Lib)
messages: 95389
nosy: pc
severity: normal
status: open
title: bsddb crashes when transaction limit occurs
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Tue Nov 17 17:47:45 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 17 Nov 2009 16:47:45 +0000
Subject: [issue7144] imp.load_module in thread causes core dump on OSX 10.6
In-Reply-To: <1255635321.71.0.461133930779.issue7144@psf.upfronthosting.co.za>
Message-ID: <1258476465.91.0.300994981918.issue7144@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The crash is caused by loading any extension that happens to link with 
CoreFoundation on a secondary thread, unless CoreFoundation was already 
initialized.

The CF framework contains a constructor that explicitly aborts when it 
is not called on the main thread (all of this on Snow Leopard only).

I've found a workaround for this issue: ensure that Python is linked to 
the CoreFoundation framework, that way CF will be initialized when 
Python starts.

I'm working on a clean patch for this

----------

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

From report at bugs.python.org  Tue Nov 17 17:49:56 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 17 Nov 2009 16:49:56 +0000
Subject: [issue7085] strptime problem
In-Reply-To: <1255042131.92.0.134837798932.issue7085@psf.upfronthosting.co.za>
Message-ID: <1258476596.08.0.771152464827.issue7085@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The crash is caused by loading any extension that happens to link with 
CoreFoundation on a secondary thread, unless CoreFoundation was already 
initialized.

The CF framework contains a constructor that explicitly aborts when it 
is not called on the main thread (all of this on Snow Leopard only).

I've found a workaround for this issue: ensure that Python is linked to 
the CoreFoundation framework, that way CF will be initialized when 
Python starts.

I'm working on a clean patch for this.

----------

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

From report at bugs.python.org  Tue Nov 17 18:54:25 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Tue, 17 Nov 2009 17:54:25 +0000
Subject: [issue7316] Add a timeout functionality to common locking operations
In-Reply-To: <1258475392.3472.24.camel@localhost>
Message-ID: <5d44f72f0911170954l5c5ab6c0s4d9af5d4db4fd257@mail.gmail.com>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

>> Timeouts also interact poorly with condition variables: you
>> can time out the initial acquire, but if you wait on a condition there's
>> no place to put the timeout on the reacquire.
>
> I don't see how it's an objection. If you have a condition variable you
> just use the cv's timeout feature, don't you? I guess there are already
> tons of combinations which don't make sense anyway.

The cv's timeout stops waiting for the cv to be notified, but then it
just calls acquire() with no timeout.

>> Given that it's hard to pick a timeout in most cases anyway, I think
>> it'd be a much bigger win to figure out thread interruption. (Yes, I
>> know that's hard, and that I promised to do it a long while ago and
>> never got around to it.)
>
> What do you mean by thread interruption? Cancellation?

Yes, sorry, I was using the Java term, which isn't particularly accurate.

>> That said, I have no objections at all to adding an internal timeout
>> ability for use by Condition.wait, and if you're still enthusiastic
>> about adding the timeout given the above argument, I won't block you.
>
> Well, it's pretty basic functionality provided by the underlying OS
> APIs, which is why I think it would be good to expose it. I remember
> being annoyed by its absence, but it was a long time ago and I don't
> remember which problem I was trying to solve.

Fair enough.

----------

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

From report at bugs.python.org  Tue Nov 17 19:12:47 2009
From: report at bugs.python.org (Greg Hewgill)
Date: Tue, 17 Nov 2009 18:12:47 +0000
Subject: [issue7340] Doc for sys.exc_info has warning that is no longer valid
In-Reply-To: <1258481567.01.0.124523901293.issue7340@psf.upfronthosting.co.za>
Message-ID: <1258481567.01.0.124523901293.issue7340@psf.upfronthosting.co.za>


New submission from Greg Hewgill <greg at hewgill.com>:

Based on a short discussion on python-dev: 
http://mail.python.org/pipermail/python-dev/2009-November/094306.html

the "Warning" box in the documentation for sys.exc_info needs to be 
updated in light of PEP 3134, and perhaps moved elsewhere since the 
circular reference problem can now occur whether or not the traceback 
returned by sys.exc_info is used.

It might also be worth mentioning that the way to break the circular 
reference, if necessary, is to explicitly set the __traceback__ member 
of the handled exception to None.

----------
assignee: georg.brandl
components: Documentation
messages: 95393
nosy: georg.brandl, ghewgill
severity: normal
status: open
title: Doc for sys.exc_info has warning that is no longer valid
type: behavior
versions: Python 3.0, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Nov 17 20:39:37 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 17 Nov 2009 19:39:37 +0000
Subject: [issue7337] Add lossy queue to queue library module
In-Reply-To: <1258454440.69.0.147012340761.issue7337@psf.upfronthosting.co.za>
Message-ID: <1258486777.17.0.692826054696.issue7337@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'm curious about your "many applications would benefit from
'connectionless' queues".  What do you have in mind?  Is there any
reason those apps cannot use collections.deque() directly?

----------
assignee:  -> rhettinger
nosy: +rhettinger

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

From report at bugs.python.org  Tue Nov 17 20:50:18 2009
From: report at bugs.python.org (Paul Moore)
Date: Tue, 17 Nov 2009 19:50:18 +0000
Subject: [issue7341] test_tarfile failing (file in use when deleting) on
	Windows buildbots
In-Reply-To: <1258487418.77.0.523197359999.issue7341@psf.upfronthosting.co.za>
Message-ID: <1258487418.77.0.523197359999.issue7341@psf.upfronthosting.co.za>


New submission from Paul Moore <p.f.moore at gmail.com>:

Windows 3.x buildbots are failing in test_tarfile.

The problem, as best I can diagnose it, appears to be a failure
somewhere in the tarfile module to close files on exceptions. The error
is "WindowsError: [Error 32] The process cannot access the file because
it is being used by another process", but I am pretty sure it's actually
the *same* process which still has an open handle on the file. The
problem occurs around  test_append_gz, which tries to open the tarfile
but expects an error. I think when the call raises the error, it is
leaving a filehandle open, which is what causes the delete in setUp to fail.

----------
components: Library (Lib), Tests
keywords: buildbot
messages: 95395
nosy: pmoore
priority: normal
severity: normal
status: open
title: test_tarfile failing (file in use when deleting) on Windows buildbots
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Nov 17 20:50:38 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 17 Nov 2009 19:50:38 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1258487438.52.0.811671097996.issue6877@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
nosy: +srid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6877>
_______________________________________

From report at bugs.python.org  Tue Nov 17 21:01:22 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 17 Nov 2009 20:01:22 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1258488082.89.0.884738382915.issue2054@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

Ok, I took a look and it seems ok to me but I still get some occasional 
failures on Windows from time to time.
Because of the threading nature of our server I suspect that moving 
del_channel() before ssl.wrap_socket() call, like this:

-            socket = ssl.wrap_socket([ ##etc. ])
-            self.del_channel()
-            self.set_socket(socket)

+            self.del_channel()
+            self.socket = ssl.wrap_socket(...)
+            self.set_socket(self.socket)

...makes more sense (ps: pay attention, it's "self.socket", not 
"socket").
After I did that I stopped seeing the occasional failures (I'm not 100% 
sure it's actually related, but...).

This is quite strange, anyway.
I suspect it has something to do with this:
http://entitycrisis.blogspot.com/2009/11/python-3-is-it-doomed.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Tue Nov 17 21:24:11 2009
From: report at bugs.python.org (David Bolen)
Date: Tue, 17 Nov 2009 20:24:11 +0000
Subject: [issue7293] test_msvc9compiler test_reg_class failure on new Windows
	box
In-Reply-To: <1257750000.16.0.245083157049.issue7293@psf.upfronthosting.co.za>
Message-ID: <1258489451.02.0.674632233714.issue7293@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

Oh, my bad - I was working on the assumption that test_msvc9compiler was
testing compiler related stuff, so obviously would have the compiler
installed.  But it makes sense you might test support for that compiler
on a machine other than the one doing the building.

As for ProductId, Windows 7 has that under the "Windows NT" key instead
of "Windows".  My XP systems seem to have it in both places.  Don't know
about earlier Windows versions.

If it's something for general use, how about HKCU\Control
Panel\Desktop\DragFullWindows (REG_SZ, but should be 0 or 1).  Everyone
should have desktop settings.  It's on both my XP and Win7 systems. 
Looking around at http://www.pctools.com/guides/registry/ would seem to
indicate that key should be present on all releases back to Win95,
though some other web references make it unclear if the key is
automatically there on Win9x.  I can do some quick test installs to
verify if I get a moment tonight though.

Alternatively, you could just pick something for Windows 7 and let any
other platform default back to the old Notepad key, perhaps fixing the
error message to suggest running Notepad?  It's not like anyone else has
complained about the test failing before this, and it's only Windows 7
for which running Notepad the first time won't create the necessary key.

I suppose checking for the desktop key first, and falling back to the
notepad key would accomplish the same thing without having to check
platform.

-- David

PS: Have we hit our "ridiculous amount of effort expended against such a
small item" quota yet?  :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7293>
_______________________________________

From report at bugs.python.org  Tue Nov 17 21:31:22 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Nov 2009 20:31:22 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1258488082.89.0.884738382915.issue2054@psf.upfronthosting.co.za>
Message-ID: <1258489896.3472.36.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Ok, I took a look and it seems ok to me but I still get some occasional 
> failures on Windows from time to time.
> Because of the threading nature of our server I suspect that moving 
> del_channel() before ssl.wrap_socket() call, like this:

Ok, thanks!

> ...makes more sense (ps: pay attention, it's "self.socket", not 
> "socket").

set_socket() sets self.socket, so it should be the same.

I'm going to commit on py3k and watch the buildbots a bit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Tue Nov 17 21:51:29 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 17 Nov 2009 20:51:29 +0000
Subject: [issue7293] test_msvc9compiler test_reg_class failure on new Windows
	box
In-Reply-To: <1257750000.16.0.245083157049.issue7293@psf.upfronthosting.co.za>
Message-ID: <1258491089.03.0.395856726857.issue7293@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

> If it's something for general use, how about
HKCU\ControlPanel\Desktop\DragFullWindows 

Yes I'll just use this one.

> I can do some quick test installs to verify if I get a moment tonight
though.

Don't worry about it. XP and Windows 7 are enough to make the test
better here. 


> PS: Have we hit our "ridiculous amount of effort expended against 
> such a small item" quota yet?  :-)

Definitely :) 

Thanks for your patience and time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7293>
_______________________________________

From report at bugs.python.org  Tue Nov 17 21:56:57 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 17 Nov 2009 20:56:57 +0000
Subject: [issue7006] The replacement suggested for callable(x) in py3k is not
	equivalent
In-Reply-To: <1254061435.03.0.676892081826.issue7006@psf.upfronthosting.co.za>
Message-ID: <1258491417.03.0.636397663706.issue7006@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

How about bringing callable back since there is no obvious replacement
for it?  It's valuable as a LYBL check in circumstances where an object
submitted far away from the place where it's invoked.  Such uses can't
easily be replaced with direct calls to follow the recommended EAFP style.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7006>
_______________________________________

From report at bugs.python.org  Tue Nov 17 21:59:31 2009
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 17 Nov 2009 20:59:31 +0000
Subject: [issue1286] fileinput, StringIO,
	and cStringIO do not support the with protocol
In-Reply-To: <1192538556.96.0.72107595061.issue1286@psf.upfronthosting.co.za>
Message-ID: <1258491571.88.0.00665852421719.issue1286@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Attached is a patch against trunk r76325 which implements context
manager support for fileinput/FileInput, with tests and doc change.

----------
keywords: +patch
nosy: +brian.curtin
Added file: http://bugs.python.org/file15355/issue1286.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1286>
_______________________________________

From report at bugs.python.org  Tue Nov 17 22:01:22 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Nov 2009 21:01:22 +0000
Subject: [issue7341] test_tarfile failing (file in use when deleting) on
	Windows buildbots
In-Reply-To: <1258487418.77.0.523197359999.issue7341@psf.upfronthosting.co.za>
Message-ID: <1258491682.35.0.51450783904.issue7341@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is a problem in the Tarfile class, which keeps the underlying
`fileobj` open even when the constructor fails. Here is a possible patch.

----------
assignee:  -> lars.gustaebel
keywords: +patch
nosy: +lars.gustaebel, pitrou
stage:  -> patch review
type:  -> resource usage
versions: +Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15356/tarfile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7341>
_______________________________________

From report at bugs.python.org  Tue Nov 17 22:03:15 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 17 Nov 2009 21:03:15 +0000
Subject: [issue1286] fileinput, StringIO,
	and cStringIO do not support the with protocol
In-Reply-To: <1192538556.96.0.72107595061.issue1286@psf.upfronthosting.co.za>
Message-ID: <1258491795.88.0.9764170651.issue1286@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1286>
_______________________________________

From report at bugs.python.org  Tue Nov 17 22:16:00 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Nov 2009 21:16:00 +0000
Subject: [issue7006] The replacement suggested for callable(x) in py3k is not
	equivalent
In-Reply-To: <1254061435.03.0.676892081826.issue7006@psf.upfronthosting.co.za>
Message-ID: <1258492560.77.0.870261069478.issue7006@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I also think isinstance(x, collections.Callable) is the correct
replacement. Even though it might give a different answer on weird
corner cases, it is semantically what you are looking for.
(too bad it has a stupid module placement)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7006>
_______________________________________

From report at bugs.python.org  Tue Nov 17 23:02:52 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 17 Nov 2009 22:02:52 +0000
Subject: [issue7342] str(datetime_obj) doesn't include microseconds if their
	value is 0
In-Reply-To: <1258495371.1.0.197938868538.issue7342@psf.upfronthosting.co.za>
Message-ID: <1258495371.1.0.197938868538.issue7342@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

Last night, test_strptime failed on one of the buildbots [1] with the
following error:
test test_strptime failed -- Traceback (most recent call last):
  File
"C:\buildslave\3.x.moore-windows\build\lib\test\test_strptime.py", line
279, in test_fraction
    tup, frac = _strptime._strptime(str(now), format="%Y-%m-%d %H:%M:%S.%f")
  File "C:\buildslave\3.x.moore-windows\build\lib\_strptime.py", line
332, in _strptime
    (data_string, format))
ValueError: time data '2009-11-16 17:17:14' does not match format
'%Y-%m-%d %H:%M:%S.%f'

The reason is that the __str__ method of datetime objects
(datetime.now() in the test) adds the trailing .%f only if the
microseconds are != 0. Since the possible values of microseconds are
between 0  and 999999 (both included), there is 1 possibility out of
1000000 that the microseconds of datetime.now() are equal to 0 (and
depending on how the value is incremented it might not include 0 among
the possible values at all). Apparently that was the cause of the
failure in the test.

This can be reproduced easily doing:
>>> from datetime import datetime
>>> str(datetime.now())
'2009-11-17 22:11:23.522951'
>>> str(datetime(2012, 12, 21)) # no microseconds
'2012-12-21 00:00:00'

This behavior is defined in Modules/datetimemodule.c, in the C function
datetime_isoformat (line 4145 on py3k, introduced by tim_one in r30151)
and in isoformat_time (line 1278 on trunk, called by datetime_isoformat,
introduced by walter.doerwald in r55714).

Is there a valid reason to omit the microseconds in case they are equal
to 0 instead of just adding the trailing '.000000'?

If the behavior doesn't change the test can be probably fixed checking
the value of the microseconds before the call to str(). The
documentation and other tests to check this should also be added.

(Thanks to R. David Murray for pointing me in the right direction while
I was investigating the problem.)

[1]:
http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/52/steps/test/logs/stdio

----------
assignee: georg.brandl
components: Documentation, Extension Modules, Tests
messages: 95404
nosy: doerwalter, ezio.melotti, georg.brandl, r.david.murray, tim_one
priority: low
severity: normal
stage: test needed
status: open
title: str(datetime_obj) doesn't include microseconds if their value is 0
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7342>
_______________________________________

From report at bugs.python.org  Tue Nov 17 23:08:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Nov 2009 22:08:54 +0000
Subject: [issue7342] str(datetime_obj) doesn't include microseconds if their
	value is 0
In-Reply-To: <1258495371.1.0.197938868538.issue7342@psf.upfronthosting.co.za>
Message-ID: <1258495734.21.0.422172473474.issue7342@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Yes, there is a valid reason. You certainly don't want spurious
microseconds to be displayed when a datetime object was constructed from
a second-precise source (e.g. parsing e-mail headers).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7342>
_______________________________________

From report at bugs.python.org  Tue Nov 17 23:13:29 2009
From: report at bugs.python.org (Tim Peters)
Date: Tue, 17 Nov 2009 22:13:29 +0000
Subject: [issue7342] str(datetime_obj) doesn't include microseconds if their
	value is 0
In-Reply-To: <1258495371.1.0.197938868538.issue7342@psf.upfronthosting.co.za>
Message-ID: <1258496009.84.0.200285365909.issue7342@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

This behavior is intentional and is documented in the
datetime.isoformat() docs:

"""
Return a string representing the date and time in ISO 8601 format,
YYYY-MM-DDTHH:MM:SS.mmmmmm or, if microsecond is 0, YYYY-MM-DDTHH:MM:SS 
...
"""

It was Guido's idea ;-)  The point is that __str__ is supposed to
produce "nice" output, and ".0000000" was thought to be more annoying
than useful, since the common case is that datetime objects don't use
microseconds.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7342>
_______________________________________

From report at bugs.python.org  Wed Nov 18 00:15:49 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Nov 2009 23:15:49 +0000
Subject: [issue6816] Provide CPython command line functionality via runpy
	module
In-Reply-To: <1251802599.29.0.539498266032.issue6816@psf.upfronthosting.co.za>
Message-ID: <1258499749.93.0.409173586122.issue6816@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Another probably related buildbot failure (again, lack of escaping the
regex pattern):

======================================================================
ERROR: test_directory_error (test.test_runpy.RunPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/Users/buildbot/buildarea/3.x.heller-x86-osx5/build/Lib/runpy.py", line
125, in _get_main_module_details
    return _get_module_details(main_name)
  File
"/Users/buildbot/buildarea/3.x.heller-x86-osx5/build/Lib/runpy.py", line
115, in _get_module_details
    raise ImportError("No code object available for %s" % mod_name)
ImportError: No code object available for __main__

During handling of the above exception, another exception occurred:

ImportError: can't find '__main__' module in
'/private/var/folders/hm/hmcPs0tuELuc-92a0F0LIk+++TM/-Tmp-/tmpp8zORb'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File
"/Users/buildbot/buildarea/3.x.heller-x86-osx5/build/Lib/test/test_runpy.py",
line 334, in test_directory_error
    self._check_import_error(script_dir, msg)
  File
"/Users/buildbot/buildarea/3.x.heller-x86-osx5/build/Lib/test/test_runpy.py",
line 295, in _check_import_error
    self.assertRaisesRegexp(ImportError, msg, run_path, script_name)
  File
"/Users/buildbot/buildarea/3.x.heller-x86-osx5/build/Lib/unittest/case.py",
line 869, in assertRaisesRegexp
    callable_obj(*args, **kwargs)
  File
"/Users/buildbot/buildarea/3.x.heller-x86-osx5/build/Lib/unittest/case.py",
line 126, in __exit__
    expected_regexp = re.compile(expected_regexp)
  File "/Users/buildbot/buildarea/3.x.heller-x86-osx5/build/Lib/re.py",
line 205, in compile
    return _compile(pattern, flags)
  File "/Users/buildbot/buildarea/3.x.heller-x86-osx5/build/Lib/re.py",
line 273, in _compile
    p = sre_compile.compile(pattern, flags)
  File
"/Users/buildbot/buildarea/3.x.heller-x86-osx5/build/Lib/sre_compile.py", line
491, in compile
    p = sre_parse.parse(p, flags)
  File
"/Users/buildbot/buildarea/3.x.heller-x86-osx5/build/Lib/sre_parse.py",
line 692, in parse
    p = _parse_sub(source, pattern, 0)
  File
"/Users/buildbot/buildarea/3.x.heller-x86-osx5/build/Lib/sre_parse.py",
line 315, in _parse_sub
    itemsappend(_parse(source, state))
  File
"/Users/buildbot/buildarea/3.x.heller-x86-osx5/build/Lib/sre_parse.py",
line 522, in _parse
    raise error("multiple repeat")
sre_constants.error: multiple repeat

======================================================================
ERROR: test_zipfile_error (test.test_runpy.RunPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/Users/buildbot/buildarea/3.x.heller-x86-osx5/build/Lib/runpy.py", line
125, in _get_main_module_details
    return _get_module_details(main_name)
  File
"/Users/buildbot/buildarea/3.x.heller-x86-osx5/build/Lib/runpy.py", line
115, in _get_module_details
    raise ImportError("No code object available for %s" % mod_name)
ImportError: No code object available for __main__

During handling of the above exception, another exception occurred:

ImportError: can't find '__main__' module in
'/private/var/folders/hm/hmcPs0tuELuc-92a0F0LIk+++TM/-Tmp-/tmpOprB3K/test_zip.zip'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File
"/Users/buildbot/buildarea/3.x.heller-x86-osx5/build/Lib/test/test_runpy.py",
line 357, in test_zipfile_error
    self._check_import_error(zip_name, msg)
  File
"/Users/buildbot/buildarea/3.x.heller-x86-osx5/build/Lib/test/test_runpy.py",
line 295, in _check_import_error
    self.assertRaisesRegexp(ImportError, msg, run_path, script_name)
  File
"/Users/buildbot/buildarea/3.x.heller-x86-osx5/build/Lib/unittest/case.py",
line 869, in assertRaisesRegexp
    callable_obj(*args, **kwargs)
  File
"/Users/buildbot/buildarea/3.x.heller-x86-osx5/build/Lib/unittest/case.py",
line 126, in __exit__
    expected_regexp = re.compile(expected_regexp)
  File "/Users/buildbot/buildarea/3.x.heller-x86-osx5/build/Lib/re.py",
line 205, in compile
    return _compile(pattern, flags)
  File "/Users/buildbot/buildarea/3.x.heller-x86-osx5/build/Lib/re.py",
line 273, in _compile
    p = sre_compile.compile(pattern, flags)
  File
"/Users/buildbot/buildarea/3.x.heller-x86-osx5/build/Lib/sre_compile.py", line
491, in compile
    p = sre_parse.parse(p, flags)
  File
"/Users/buildbot/buildarea/3.x.heller-x86-osx5/build/Lib/sre_parse.py",
line 692, in parse
    p = _parse_sub(source, pattern, 0)
  File
"/Users/buildbot/buildarea/3.x.heller-x86-osx5/build/Lib/sre_parse.py",
line 315, in _parse_sub
    itemsappend(_parse(source, state))
  File
"/Users/buildbot/buildarea/3.x.heller-x86-osx5/build/Lib/sre_parse.py",
line 522, in _parse
    raise error("multiple repeat")
sre_constants.error: multiple repeat

----------------------------------------------------------------------
Ran 16 tests in 32.210s

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6816>
_______________________________________

From report at bugs.python.org  Wed Nov 18 00:16:50 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Nov 2009 23:16:50 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1258499810.02.0.750114073708.issue2054@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Buildbots are ok. Thank you!

----------
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Wed Nov 18 03:07:21 2009
From: report at bugs.python.org (Isaul Vargas)
Date: Wed, 18 Nov 2009 02:07:21 +0000
Subject: [issue7231] Windows installer does not add \Scripts folder to the path
In-Reply-To: <1256749152.57.0.801313448944.issue7231@psf.upfronthosting.co.za>
Message-ID: <1258510041.26.0.369521005233.issue7231@psf.upfronthosting.co.za>


Isaul Vargas <isaulv at gmail.com> added the comment:

For now you can modify the path yourself, and only once, by following 
these instructions:
1) Open the System Properties either via the Control Panel or pressing 
WinKey-Pause
2) Click on the tab that says Advanced
3) Click on Environment Variables
4) Under System Variables, scroll down and find Path
5) Click on Edit
6) Add ;X:/PythonXX/Scripts where X is the appropriate drive letter and 
python version.
7) Click OK, and OK again.

You might have to reboot, but now that it is added, you don't have to 
manually update it.

----------
nosy: +Dude-X

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7231>
_______________________________________

From report at bugs.python.org  Wed Nov 18 06:38:34 2009
From: report at bugs.python.org (Rich Healey)
Date: Wed, 18 Nov 2009 05:38:34 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1258522714.67.0.952877929776.issue7206@psf.upfronthosting.co.za>


Rich Healey <richo at psych0tik.net> added the comment:

I've done some more fiddling with the debugger, once I discovered the 
Windows symbol servers, and a tool called application verifier some 
things started to fall into place.

LuaPriv takes care of user privelidges, the program runs fine when I run 
it as administrator. I believe that disabling UAC has caused the issue.

I will attempt 2 things
a) Create a new user account on this machine to see if the issue is 
ongoing.
b) Try to fiddle more with the debugger to find the last python call in 
the stack.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7206>
_______________________________________

From report at bugs.python.org  Wed Nov 18 06:46:05 2009
From: report at bugs.python.org (Jared Grubb)
Date: Wed, 18 Nov 2009 05:46:05 +0000
Subject: [issue7343] "What's new in 3.0" says % operator will be deprecated in
	3.1
In-Reply-To: <1258523164.66.0.0511843184453.issue7343@psf.upfronthosting.co.za>
Message-ID: <1258523164.66.0.0511843184453.issue7343@psf.upfronthosting.co.za>


New submission from Jared Grubb <python at jaredgrubb.com>:

The existing text:

http://www.python.org/doc/3.0/whatsnew/3.0.html
"A new system for built-in string formatting operations replaces the %
string formatting operator. (However, the % operator is still supported;
it will be deprecated in Python 3.1 and removed from the language at
some later time.) Read PEP 3101 for the full scoop."

Python 3.1 did not deprecate the % operator, right? Is it appropriate to
edit the 3.0 docs to reflect that?

----------
assignee: georg.brandl
components: Documentation
messages: 95411
nosy: georg.brandl, jaredgrubb
severity: normal
status: open
title: "What's new in 3.0" says % operator will be deprecated in 3.1
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7343>
_______________________________________

From report at bugs.python.org  Wed Nov 18 06:46:58 2009
From: report at bugs.python.org (Rich Healey)
Date: Wed, 18 Nov 2009 05:46:58 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1258523218.39.0.155447095768.issue7206@psf.upfronthosting.co.za>


Rich Healey <richo at psych0tik.net> added the comment:

I have an apology to make for wasting your time.

Further investigation demonstrates that it was evidently fiddling with 
the Application Verifier that broke everything (although I installed it 
during my debugging attempts- I'm guessing that something else in VS has 
the same capabilities).

By disabling all tests the application runs, by reenabling them it stops 
again.

I now have a few questions

1) How can the verifier add the flags to the loading mechanism to add 
the breaks? In that when I installed different versions/clean reinstall 
of the same version it was still broken. Clearly it doesn't patch the 
binary, but leaves a flag somewhere (???) about the binary?

2) OK by the looks of it I only had one question ;)

thanks for all your help!

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7206>
_______________________________________

From report at bugs.python.org  Wed Nov 18 07:13:58 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 18 Nov 2009 06:13:58 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1258524838.13.0.791715495538.issue7206@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

See the section "How Does AppVerifier Work?" in

http://msdn.microsoft.com/en-us/library/aa480483.aspx

This doesn't answer your question fully, as it fails to explain how
precisely they hook into the app.

ISTM that they use the HKLM\Software\Microsoft\Windows
NT\CurrentVersion\Image File Execution Options registry hook. For each
executable (such as python.exe), you can specify an alternative binary
that gets launched whenever somebody is asking to launch python.exe
(IIUC, by setting the "Debugger" value on the registry key). In case of
appverifier, they probably then load the original binary, do their entry
point rewriting, and start the binary.

There actually *is* a second question: what is it that AppVerifier
complains about? It may be useful to run Python in AppVerifier to detect
bugs - but any outcome of this is out of scope of this report, it seems.
If you are curious to look into this further, that would be much
appreciated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7206>
_______________________________________

From report at bugs.python.org  Wed Nov 18 09:40:53 2009
From: report at bugs.python.org (sorin)
Date: Wed, 18 Nov 2009 08:40:53 +0000
Subject: [issue7231] Windows installer does not add \Scripts folder to the path
In-Reply-To: <1256749152.57.0.801313448944.issue7231@psf.upfronthosting.co.za>
Message-ID: <1258533653.46.0.799126249874.issue7231@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

Thanks Isaul,
Anyway I made the required change before submitting the bug first time
and additionally to what you wrote it is enough to logout/login to
update the path - no reboot required.

The bug is about repairing/improving Python experience for all Windows
users. Imagine that you want to deploy Python plus some extensions to
many Windows computers - you will have a hard time adding Script
directory to the path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7231>
_______________________________________

From report at bugs.python.org  Wed Nov 18 10:44:48 2009
From: report at bugs.python.org (Ben Bass)
Date: Wed, 18 Nov 2009 09:44:48 +0000
Subject: [issue7337] Add lossy queue to queue library module
In-Reply-To: <1258454440.69.0.147012340761.issue7337@psf.upfronthosting.co.za>
Message-ID: <1258537488.43.0.265340676974.issue7337@psf.upfronthosting.co.za>


Ben Bass <benpaulbass at googlemail.com> added the comment:

'connectionless' is from how I see it as an analogy with UDP (vs TCP); 
why not just use a deque is primarily about having the same API - a 
client (getter) of the queue shouldn't know or care whether it is a 
'lossy' queue or a normal queue.  I guess most uses of a normal queue 
(excepting the 'task' functions) could just use a deque, but it wouldn't 
feel natural.

Use cases: non-critical event/status reporting is my canonical example.
Specific examples:
 - a program which executes a long running process in a thread. It wants 
to update a GUI progress bar or similar, which must occur in a different 
thread because of the GUI model. By using a LossyQueue, the server 
thread is simplified; it doesn't have to care whether anything is 
listening on the other end, allowing greater decoupling (e.g. no changes 
required if there isn't a GUI). LossyQueues become part of the interface 
which can be used or not as required.
 - emulating/providing wrapper around UDP sockets
 - many application protocols support a get/set/report type interface 
with the addition of asynchronous events (e.g. SNMP, Netconf, SCPI).  In 
these type of applications a suitable abstraction might be a normal 
Queue(s) for the standard commands and a LossyQueue for the events 
(which some applications might not care about).  The point is that to 
the user of this abstraction, these two interfaces look the same.

The 'server' doesn't care if a client is listening or not (it won't 
block and it won't use unlimited memory)
The 'client' (if it wants to use it) doesn't know that it isn't a normal 
queue (same API).
-> decouples server and client tasks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7337>
_______________________________________

From report at bugs.python.org  Wed Nov 18 11:16:35 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Nov 2009 10:16:35 +0000
Subject: [issue7006] The replacement suggested for callable(x) in py3k is
	not	equivalent
In-Reply-To: <1258492560.77.0.870261069478.issue7006@psf.upfronthosting.co.za>
Message-ID: <4B03C977.4000402@gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> I also think isinstance(x, collections.Callable) is the correct
> replacement. Even though it might give a different answer on weird
> corner cases, it is semantically what you are looking for.
> (too bad it has a stupid module placement)

Yes, I was very surprised not to find it as abc.Callable...

Regards,
Nick.

----------
title: The replacement suggested for callable(x) in py3k is not equivalent -> The replacement suggested for callable(x) in py3k is not	equivalent

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7006>
_______________________________________

From report at bugs.python.org  Wed Nov 18 11:20:02 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 18 Nov 2009 10:20:02 +0000
Subject: [issue7293] test_msvc9compiler test_reg_class failure on new Windows
	box
In-Reply-To: <1257750000.16.0.245083157049.issue7293@psf.upfronthosting.co.za>
Message-ID: <1258539602.1.0.121358300547.issue7293@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

r76358 and r76360 and r76361

Thanks David !

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7293>
_______________________________________

From report at bugs.python.org  Wed Nov 18 11:26:49 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Nov 2009 10:26:49 +0000
Subject: [issue6816] Provide CPython command line functionality via runpy
	module
In-Reply-To: <1251802599.29.0.539498266032.issue6816@psf.upfronthosting.co.za>
Message-ID: <1258540009.0.0.827724570236.issue6816@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Hmm, I think I need to use a more robust regex escaping approach... I
never knew the OS level temp dir creation could get that creative.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6816>
_______________________________________

From report at bugs.python.org  Wed Nov 18 11:35:49 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Nov 2009 10:35:49 +0000
Subject: [issue2029] "python -m pydoc -g"  fails
In-Reply-To: <1202387094.14.0.198769715828.issue2029@psf.upfronthosting.co.za>
Message-ID: <1258540549.41.0.49085935991.issue2029@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It turns out this problem was breaking pydoc -m completely in Python 3.x
(os.popen was breaking since it couldn't find the subprocess module -
see #7238).

A more robust fix that retains the three lines, but modifies them to
avoid deleting the standard library directory from sys.path when using
'-m' has been applied to the 2.6 and 3.1 maintenance branches as well as
the main development branches for 2.7 and 3.2.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2029>
_______________________________________

From report at bugs.python.org  Wed Nov 18 12:32:49 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Nov 2009 11:32:49 +0000
Subject: [issue6816] Provide CPython command line functionality via runpy
	module
In-Reply-To: <1251802599.29.0.539498266032.issue6816@psf.upfronthosting.co.za>
Message-ID: <1258543969.41.0.296756349995.issue6816@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I fixed the tests to use the proper escaping function from the re module
instead of directly doubling backslashes, so that error shouldn't happen
any more.

(Was it one of the unstable buildbots that picked this up? I didn't see
anything come through on the checkins list)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6816>
_______________________________________

From report at bugs.python.org  Wed Nov 18 12:50:07 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Nov 2009 11:50:07 +0000
Subject: [issue7344] wsgiref tests failing on Windows 7 buildbot
In-Reply-To: <1258545007.71.0.460260425004.issue7344@psf.upfronthosting.co.za>
Message-ID: <1258545007.71.0.460260425004.issue7344@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

As the subject line says: the wsgiref unit tests fail on the new Windows
7 buildbot.

It appears to be happening every run, but here's one example:
http://www.python.org/dev/buildbot/trunk/builders/x86%20Windows7%20trunk/builds/25/steps/test/logs/stdio

----------
keywords: buildbot
messages: 95421
nosy: ncoghlan
severity: normal
status: open
title: wsgiref tests failing on Windows 7 buildbot
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7344>
_______________________________________

From report at bugs.python.org  Wed Nov 18 13:01:12 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Nov 2009 12:01:12 +0000
Subject: [issue5037] unicode(x) for weakref.proxy objects invokes __str__
	instead of __unicode__
In-Reply-To: <1232723011.79.0.257405867279.issue5037@psf.upfronthosting.co.za>
Message-ID: <1258545672.65.0.661998944326.issue5037@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Patch looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5037>
_______________________________________

From report at bugs.python.org  Wed Nov 18 13:04:29 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Nov 2009 12:04:29 +0000
Subject: [issue4486] Exception traceback is incorrect for strange exception
	handling
In-Reply-To: <1228214038.9.0.934760513423.issue4486@psf.upfronthosting.co.za>
Message-ID: <1258545869.51.0.788814901322.issue4486@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Reviewed patch diff - looks good to me. It's an obscure corner case, but
the patch is pretty straightforward so we may as well clean it up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4486>
_______________________________________

From report at bugs.python.org  Wed Nov 18 13:06:18 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Nov 2009 12:06:18 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1258545978.77.0.409922910007.issue5949@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Unassigned from Barry since this isn't an RM review issue anymore

----------
assignee: barry -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5949>
_______________________________________

From report at bugs.python.org  Wed Nov 18 13:06:26 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Nov 2009 12:06:26 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1258545986.4.0.643610979232.issue5949@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5949>
_______________________________________

From report at bugs.python.org  Wed Nov 18 13:11:32 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Wed, 18 Nov 2009 12:11:32 +0000
Subject: [issue7341] test_tarfile failing (file in use when deleting) on
	Windows buildbots
In-Reply-To: <1258487418.77.0.523197359999.issue7341@psf.upfronthosting.co.za>
Message-ID: <1258546292.73.0.228022809538.issue7341@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Any idea why the 2.x buildbots aren't failing? The code is basically the
same. Coincidence?

The patch is okay. Still, I have attached another version of it with a
slightly smaller try-except clause. Is it feasible to test if the patch
actually solves the problem?

----------
Added file: http://bugs.python.org/file15357/issue7341-3.x.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7341>
_______________________________________

From report at bugs.python.org  Wed Nov 18 13:18:33 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Nov 2009 12:18:33 +0000
Subject: [issue6749] Support for encrypted zipfiles when interpreting zipfile
	as script
In-Reply-To: <1250830303.29.0.377270089004.issue6749@psf.upfronthosting.co.za>
Message-ID: <1258546713.22.0.0347956893009.issue6749@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

A few pointers in case anyone decides to follow this up further:

Zipfile execution is just a special case of normal zipimport: the
zipfile's name is placed at the head of sys.path and a (very) rough
equivalent of "import __main__" is then invoked.

So for zipfile execution to support password protected zipfiles, general
zipimport would need to support them as well.

However, this runs into the problem that invocation of the zipimport
module is largely implicit - the import engine invokes sys.path_hooks
entries (which includes ZipImporter automatically) for a given sys.path
entry and finds that, sure enough, ZipImporter recognises it and creates
an appropriate object to handle it.

So the trick lies in getting the password to the importer that needs to
know it in order to open the zipfile.

For the general case, you could create a new path hook that had a list
of filename pattern<->password pairs that could be placed in
sys.path_hooks ahead of the normal zipimport hook. If it saw a pattern
it recognised, it could use the appropriate password to open the zipfile
and return a corresponding importer object (you could do this largely
independently of the standard library itself - PEP 302 is expressly
designed to let third party developers run with this kind of idea).

That wouldn't help much with zipfile execution though, as you still
wouldn't have a mechanism for providing the password on the command line.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6749>
_______________________________________

From report at bugs.python.org  Wed Nov 18 14:04:22 2009
From: report at bugs.python.org (Tim Golden)
Date: Wed, 18 Nov 2009 13:04:22 +0000
Subject: [issue7344] wsgiref tests failing on Windows 7 buildbot
In-Reply-To: <1258545007.71.0.460260425004.issue7344@psf.upfronthosting.co.za>
Message-ID: <1258549462.67.0.998565661172.issue7344@psf.upfronthosting.co.za>


Changes by Tim Golden <mail at timgolden.me.uk>:


----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7344>
_______________________________________

From report at bugs.python.org  Wed Nov 18 14:42:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 Nov 2009 13:42:10 +0000
Subject: [issue6816] Provide CPython command line functionality via runpy
	module
In-Reply-To: <1258543969.41.0.296756349995.issue6816@psf.upfronthosting.co.za>
Message-ID: <1258551745.3476.0.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> (Was it one of the unstable buildbots that picked this up? I didn't see
> anything come through on the checkins list)

Buildbot failures have stopped being e-mailed long ago it seems.
(ah, you really thought our buildbots were all green in all that
time? :P)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6816>
_______________________________________

From report at bugs.python.org  Wed Nov 18 14:43:44 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 Nov 2009 13:43:44 +0000
Subject: [issue7341] test_tarfile failing (file in use when deleting) on
	Windows buildbots
In-Reply-To: <1258546292.73.0.228022809538.issue7341@psf.upfronthosting.co.za>
Message-ID: <1258551834.3476.2.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le mercredi 18 novembre 2009 ? 12:11 +0000, Lars Gust?bel a ?crit :
> Lars Gust?bel <lars at gustaebel.de> added the comment:
> 
> Any idea why the 2.x buildbots aren't failing? The code is basically the
> same. Coincidence?

No, the difference is that exception objects carry the traceback with
them in 3.x, which keeps alive a reference cycle long enough for
`fileobj` not to be garbage collected before the next test run.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7341>
_______________________________________

From report at bugs.python.org  Wed Nov 18 16:59:30 2009
From: report at bugs.python.org (Paul Moore)
Date: Wed, 18 Nov 2009 15:59:30 +0000
Subject: [issue7341] test_tarfile failing (file in use when deleting) on
	Windows buildbots
In-Reply-To: <1258546292.73.0.228022809538.issue7341@psf.upfronthosting.co.za>
Message-ID: <79990c6b0911180759x3aa123b4g743ae68722f6d172@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

I can run a test on my buildbot - but I may not have a chance until
tomorrow. I'll do that and report back unless someone else reports
that they have managed to run a test before me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7341>
_______________________________________

From report at bugs.python.org  Wed Nov 18 17:11:44 2009
From: report at bugs.python.org (dingle)
Date: Wed, 18 Nov 2009 16:11:44 +0000
Subject: [issue7345] calendar.TextCalendar().formatyear wrong argument list
In-Reply-To: <1258560704.19.0.583792221573.issue7345@psf.upfronthosting.co.za>
Message-ID: <1258560704.19.0.583792221573.issue7345@psf.upfronthosting.co.za>


New submission from dingle <xinjiang.lu at gmail.com>:

class calendar.TextCalendar([firstweekday]):
formatyear(theyear, themonth[, w[, l[, c[, m]]]])

Should delete "themonth". Found this problem with all 2.6, 2.7, 3K
documentation.

----------
assignee: georg.brandl
components: Documentation
messages: 95430
nosy: dingle, georg.brandl
severity: normal
status: open
title: calendar.TextCalendar().formatyear wrong argument list
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7345>
_______________________________________

From report at bugs.python.org  Wed Nov 18 17:16:16 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 18 Nov 2009 16:16:16 +0000
Subject: [issue7344] wsgiref tests failing on Windows 7 buildbot
In-Reply-To: <1258545007.71.0.460260425004.issue7344@psf.upfronthosting.co.za>
Message-ID: <1258560976.01.0.483436050191.issue7344@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

[In case the URL disappears, the error message contains
"AssertionError: Environmental variable TCL_LIBRARY is not a string"]

This issue is another effect of issue6906.

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed
superseder:  -> Tkinter sets an unicode environment variable on win32

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7344>
_______________________________________

From report at bugs.python.org  Wed Nov 18 17:21:58 2009
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 18 Nov 2009 16:21:58 +0000
Subject: [issue3976] pprint._safe_repr is not general enough in one instance
In-Reply-To: <1222445700.05.0.107288672735.issue3976@psf.upfronthosting.co.za>
Message-ID: <1258561318.27.0.688967464575.issue3976@psf.upfronthosting.co.za>


Changes by David W. Lambert <b49P23TIvg at stny.rr.com>:


----------
nosy: +LambertDW

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3976>
_______________________________________

From report at bugs.python.org  Wed Nov 18 18:07:27 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 Nov 2009 17:07:27 +0000
Subject: [issue7341] test_tarfile failing (file in use when deleting) on
	Windows buildbots
In-Reply-To: <1258546292.73.0.228022809538.issue7341@psf.upfronthosting.co.za>
Message-ID: <1258564061.3476.4.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Still, I have attached another version of it with a
> slightly smaller try-except clause. Is it feasible to test if the patch
> actually solves the problem?

Yes, it does.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7341>
_______________________________________

From report at bugs.python.org  Wed Nov 18 18:15:33 2009
From: report at bugs.python.org (Ecir Hana)
Date: Wed, 18 Nov 2009 17:15:33 +0000
Subject: [issue7346] Redirected stdout fires [Errno 9]
In-Reply-To: <1258564533.69.0.0908463291045.issue7346@psf.upfronthosting.co.za>
Message-ID: <1258564533.69.0.0908463291045.issue7346@psf.upfronthosting.co.za>


New submission from Ecir Hana <ecir.hana at gmail.com>:

I try to log all the output of a program written in Python and C to a
buffer. I create a pipe, redirect stdout to its write-end and then read
its content afterward. However, printing from Python fires "IOError:
[Errno 9] Bad file descriptor". Please see the attached test-case.

It is happening on Windows XP, Python 2.6 and MinGW GCC and I used this
to compile:
gcc -o std.exe std.c -Ic:/dev/include/python2.6 -l python26

PS: It might be that the problem is that Python was compiled with
MSVC2008 and I'm using MinGW but I'm not sure...

----------
components: IO, Windows
files: std.c
messages: 95433
nosy: ecir.hana
severity: normal
status: open
title: Redirected stdout fires [Errno 9]
versions: Python 2.6
Added file: http://bugs.python.org/file15358/std.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7346>
_______________________________________

From report at bugs.python.org  Wed Nov 18 18:48:15 2009
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 18 Nov 2009 17:48:15 +0000
Subject: [issue7347] Patch - add RegCreateKeyEx to _winreg
In-Reply-To: <1258566495.76.0.636986979508.issue7347@psf.upfronthosting.co.za>
Message-ID: <1258566495.76.0.636986979508.issue7347@psf.upfronthosting.co.za>


New submission from Brian Curtin <curtin at acm.org>:

The _winreg module could use the addition of the RegCreateKeyEx call, as
evidenced by this thread on c.l.py:
http://mail.python.org/pipermail/python-list/2009-November/614023.html
This expanded API would benefit users trying to create keys with access
masks (like KEY_WOW64_64KEY), which you can't set through _winreg.CreateKey.

The patch includes the change to _winreg.c, along with doc and test
changes. Comments/suggestions appreciated.

----------
components: Extension Modules
files: winreg_add_createkeyex.patch
keywords: patch
messages: 95434
nosy: brian.curtin
severity: normal
status: open
title: Patch - add RegCreateKeyEx to _winreg
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file15359/winreg_add_createkeyex.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7347>
_______________________________________

From report at bugs.python.org  Wed Nov 18 18:51:14 2009
From: report at bugs.python.org (Paul Moore)
Date: Wed, 18 Nov 2009 17:51:14 +0000
Subject: [issue7341] test_tarfile failing (file in use when deleting) on
	Windows buildbots
In-Reply-To: <1258487418.77.0.523197359999.issue7341@psf.upfronthosting.co.za>
Message-ID: <1258566674.35.0.75119949504.issue7341@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

I can confirm it fixes the issue, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7341>
_______________________________________

From report at bugs.python.org  Wed Nov 18 18:55:02 2009
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 18 Nov 2009 17:55:02 +0000
Subject: [issue7347] Patch - add RegCreateKeyEx to _winreg
In-Reply-To: <1258566495.76.0.636986979508.issue7347@psf.upfronthosting.co.za>
Message-ID: <1258566902.72.0.175337383391.issue7347@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Removed file: http://bugs.python.org/file15359/winreg_add_createkeyex.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7347>
_______________________________________

From report at bugs.python.org  Wed Nov 18 18:55:46 2009
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 18 Nov 2009 17:55:46 +0000
Subject: [issue7347] Patch - add RegCreateKeyEx to _winreg
In-Reply-To: <1258566495.76.0.636986979508.issue7347@psf.upfronthosting.co.za>
Message-ID: <1258566946.08.0.0835993063685.issue7347@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Updated patch - c&p mistake in a comment

----------
Added file: http://bugs.python.org/file15360/winreg_add_createkeyex.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7347>
_______________________________________

From report at bugs.python.org  Wed Nov 18 19:38:40 2009
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 18 Nov 2009 18:38:40 +0000
Subject: [issue7343] "What's new in 3.0" says % operator will be deprecated in
	3.1
In-Reply-To: <1258523164.66.0.0511843184453.issue7343@psf.upfronthosting.co.za>
Message-ID: <1258569520.52.0.0839055571267.issue7343@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The % operator has not been deprecated, although talk of removing it 
flares up from time to time. We are still encouraging people to use the 
new str.format().

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7343>
_______________________________________

From report at bugs.python.org  Wed Nov 18 19:58:37 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 18 Nov 2009 18:58:37 +0000
Subject: [issue7348] StringIO.StringIO.readline(-1) returns the wrong result
	compared to other file-like objects
In-Reply-To: <1258570716.97.0.757460234956.issue7348@psf.upfronthosting.co.za>
Message-ID: <1258570716.97.0.757460234956.issue7348@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

cStringIO and file both accept -1 to readline to mean the same thing as
not passing any argument at all.  StringIO, on the other hand, gets
totally confused:

  >>> from StringIO import StringIO
  >>> StringIO('a\nb\nfoo').readline(-1)
  'a\nb\nfo'
  >>>

----------
components: Library (Lib)
messages: 95438
nosy: exarkun
severity: normal
status: open
title: StringIO.StringIO.readline(-1)  returns the wrong result compared to other file-like objects

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7348>
_______________________________________

From report at bugs.python.org  Wed Nov 18 20:01:54 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 18 Nov 2009 19:01:54 +0000
Subject: [issue7349] StringIO.StringIO, io.BytesIO,
	and io.StringIO accept None in places where other file-like objects
	don't
In-Reply-To: <1258570914.64.0.211682819163.issue7349@psf.upfronthosting.co.za>
Message-ID: <1258570914.64.0.211682819163.issue7349@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

The actual file type rejects None in places like as the argument to read
or readlines.  StringIO.StringIO, io.BytesIO, and io.StringIO all accept
None to mean the same as passing no argument at all.

This makes it tricky to write code that might operate on any of these
types (as many APIs accepting a "file-like object" try to).  Testing
with one will not demonstrate that code works with any.  In particular,
it's common to start test with StringIO, which is more liberal, and only
discover a problem when code is run for real against an actual file.

----------
components: Library (Lib)
messages: 95439
nosy: exarkun
severity: normal
status: open
title: StringIO.StringIO, io.BytesIO, and io.StringIO accept None in places where other file-like objects don't

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7349>
_______________________________________

From report at bugs.python.org  Wed Nov 18 20:08:55 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 18 Nov 2009 19:08:55 +0000
Subject: [issue7349] StringIO.StringIO, io.BytesIO,
	and io.StringIO accept None in places where other file-like objects
	don't
In-Reply-To: <1258570914.64.0.211682819163.issue7349@psf.upfronthosting.co.za>
Message-ID: <1258571335.31.0.837742742624.issue7349@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

The original pure-python impl. of io accepted None, and still does. This 
is a regression in C impl.

----------
nosy: +pjenvey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7349>
_______________________________________

From report at bugs.python.org  Wed Nov 18 20:11:56 2009
From: report at bugs.python.org (Eric Torstenson)
Date: Wed, 18 Nov 2009 19:11:56 +0000
Subject: [issue7350] csv doesn't handle escaped characters properly
In-Reply-To: <1258571515.92.0.182844984253.issue7350@psf.upfronthosting.co.za>
Message-ID: <1258571515.92.0.182844984253.issue7350@psf.upfronthosting.co.za>


New submission from Eric Torstenson <e_torstenson at hotmail.com>:

When I use CSV with a separator, if there is an escaped separator in the
field, it causes the next field to become part of the current one:

file = csv.reader(open(filename), delimiter='\t', quotechar="'")
for words in file:
    print words[0-8]

If, say line 3 contains: '1709'	'PF01322'	'Cytochrom_C_2'
'Cytochrome_C_2; '	'Cytochrome C\''	'Finn RD, Bateman A'	'anon'	'Sarah
Teichmann'

Column 4 will be printed as:
Cytochrome C\'\tFinn RD, Bateman A'

I've checked this with a spreadsheet application, and it opened this
line just fine, but when I used csv to parse, I had to remove that
escaped single quote to get my columns to work out properly for that line.

----------
components: Extension Modules
messages: 95441
nosy: est_python_tracker
severity: normal
status: open
title: csv doesn't handle escaped characters properly
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7350>
_______________________________________

From report at bugs.python.org  Wed Nov 18 20:12:30 2009
From: report at bugs.python.org (Eric Smith)
Date: Wed, 18 Nov 2009 19:12:30 +0000
Subject: [issue7343] "What's new in 3.0" says % operator will be deprecated in
	3.1
In-Reply-To: <1258523164.66.0.0511843184453.issue7343@psf.upfronthosting.co.za>
Message-ID: <1258571550.55.0.0194690552007.issue7343@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7343>
_______________________________________

From report at bugs.python.org  Wed Nov 18 20:12:35 2009
From: report at bugs.python.org (Retro)
Date: Wed, 18 Nov 2009 19:12:35 +0000
Subject: =?utf-8?q?=5Bissue7351=5D_Documentation_typos_found_in_=22zipfile_?=
	=?utf-8?q?=E2=80=94_Work_with_ZIP_archives=22?=
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>


New submission from Retro <vinetouu at gmail.com>:

There are some minor typos in the docs. The section zipfile has twp typos:

exception zipfile.BadZipfile
    The error raised for bad ZIP files (old name: zipfile.error).

this should be

exception zipfile.BadZipFile
    The error raised for bad ZIP files (old name: zipfile.error).

Note: There needs to be a capital F in the exception class name BadZipFile.


There's also a typo in the sentence "Decryption is extremely slow as it
is implemented in native python rather than C." which should be
"Decryption is extremely slow as it is implemented in native Python
rather than C." This sentence is found just above the previous
BadZipfile typo.

Note: The word 'python' is needed to be capitalized.


These typos exist since the creation of the zipfile docs. Please correct
the docs for the selected versions. Thank you.

----------
assignee: georg.brandl
components: Documentation
messages: 95442
nosy: Retro, georg.brandl
severity: normal
status: open
title: Documentation typos found in "zipfile ? Work with ZIP archives"
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Wed Nov 18 20:22:01 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 18 Nov 2009 19:22:01 +0000
Subject: [issue7343] "What's new in 3.0" says % operator will be deprecated in
	3.1
In-Reply-To: <1258523164.66.0.0511843184453.issue7343@psf.upfronthosting.co.za>
Message-ID: <1258572121.29.0.779340672736.issue7343@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed in r76372:

* :ref:`pep-3101`.  Note: the 2.6 description mentions the
  :meth:`format` method for both 8-bit and Unicode strings.  In 3.0,
  only the :class:`str` type (text strings with Unicode support)
  supports this method; the :class:`bytes` type does not.  The plan is
  to make this the preferred API for string formatting and to
  de-emphasize the ``%`` string formatting operator.

----------
nosy: +rhettinger
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7343>
_______________________________________

From report at bugs.python.org  Wed Nov 18 20:35:42 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 18 Nov 2009 19:35:42 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1258572942.32.0.956779546368.issue7117@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

r76373:  Backport round.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Wed Nov 18 20:40:07 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 18 Nov 2009 19:40:07 +0000
Subject: =?utf-8?q?=5Bissue7351=5D_Documentation_typos_found_in_=22zipfile_?=
	=?utf-8?q?=E2=80=94_Work_with_ZIP_archives=22?=
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1258573207.5.0.877700768544.issue7351@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

BadZipfile is actually the correct name of the exception.

Fixed the other nit in r76376.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Wed Nov 18 20:58:37 2009
From: report at bugs.python.org (Eric Smith)
Date: Wed, 18 Nov 2009 19:58:37 +0000
Subject: [issue7347] Patch - add RegCreateKeyEx to _winreg
In-Reply-To: <1258566495.76.0.636986979508.issue7347@psf.upfronthosting.co.za>
Message-ID: <1258574317.53.0.598608307948.issue7347@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7347>
_______________________________________

From report at bugs.python.org  Wed Nov 18 21:10:09 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 18 Nov 2009 20:10:09 +0000
Subject: [issue2499] Fold unary + and not on constants
In-Reply-To: <1206677118.63.0.142364619401.issue2499@psf.upfronthosting.co.za>
Message-ID: <1258575009.37.0.0657374102563.issue2499@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Closing this.  The Unary Positive is already implemented and there are
no known use cases for constant folding a Unary Not.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2499>
_______________________________________

From report at bugs.python.org  Wed Nov 18 21:29:32 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 Nov 2009 20:29:32 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1258576172.61.0.203735126016.issue5949@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> janssen
nosy: +janssen
stage:  -> patch review
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5949>
_______________________________________

From report at bugs.python.org  Wed Nov 18 21:32:52 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 Nov 2009 20:32:52 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1258576372.66.0.89412527565.issue3890@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Based on the various comments the current patch should be ok, shouldn't it?
Although it would certainly be better with a patch ;)

----------
assignee: barry -> 
nosy: +pitrou
stage:  -> patch review
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Wed Nov 18 21:33:21 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 Nov 2009 20:33:21 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1258576401.05.0.600464504333.issue3890@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Oops. I meant "better with tests" of course...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Wed Nov 18 21:34:27 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Wed, 18 Nov 2009 20:34:27 +0000
Subject: [issue7341] test_tarfile failing (file in use when deleting) on
	Windows buildbots
In-Reply-To: <1258487418.77.0.523197359999.issue7341@psf.upfronthosting.co.za>
Message-ID: <1258576467.71.0.230250625989.issue7341@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Alright then. I applied the change to the trunk (r76381) and py3k
(r76383). What about release26-maint and release31-maint? IMO this is
not necessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7341>
_______________________________________

From report at bugs.python.org  Wed Nov 18 21:36:32 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 Nov 2009 20:36:32 +0000
Subject: [issue7341] test_tarfile failing (file in use when deleting) on
	Windows buildbots
In-Reply-To: <1258576467.71.0.230250625989.issue7341@psf.upfronthosting.co.za>
Message-ID: <1258576607.3476.7.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Alright then. I applied the change to the trunk (r76381) and py3k
> (r76383). What about release26-maint and release31-maint? IMO this is
> not necessary.

Unless it might cause compatibility concerns I think it would be better
to backport it.
In general it's bad to rely on reference counting to automatically close
files. The object could be hanging on a traceback, or you could be
running on a Python implementation with a different GC strategy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7341>
_______________________________________

From report at bugs.python.org  Wed Nov 18 21:52:02 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Wed, 18 Nov 2009 20:52:02 +0000
Subject: [issue7341] test_tarfile failing (file in use when deleting) on
	Windows buildbots
In-Reply-To: <1258487418.77.0.523197359999.issue7341@psf.upfronthosting.co.za>
Message-ID: <1258577522.54.0.99821788428.issue7341@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

I have always tried to be very conservative with backporting stuff that
is not clearly a bugfix but alters any kind of behaviour. I am always
very concerned about compatibility, especially if code has been around
for as long as this code has.
But as I don't want to waste anybody's time with a lengthy discussion,
just say a word and I apply it to 2.6 and 3.1 as well ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7341>
_______________________________________

From report at bugs.python.org  Wed Nov 18 21:54:26 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 Nov 2009 20:54:26 +0000
Subject: [issue7341] test_tarfile failing (file in use when deleting) on
	Windows buildbots
In-Reply-To: <1258577522.54.0.99821788428.issue7341@psf.upfronthosting.co.za>
Message-ID: <1258577679.3476.18.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I have always tried to be very conservative with backporting stuff that
> is not clearly a bugfix but alters any kind of behaviour. I am always
> very concerned about compatibility, especially if code has been around
> for as long as this code has.
> But as I don't want to waste anybody's time with a lengthy discussion,
> just say a word and I apply it to 2.6 and 3.1 as well ;-)

What if I say chocolate?
Regardless, I think you should backport it at least to 3.1, and that it
makes sense to backport it to 2.6 too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7341>
_______________________________________

From report at bugs.python.org  Wed Nov 18 21:54:53 2009
From: report at bugs.python.org (Retro)
Date: Wed, 18 Nov 2009 20:54:53 +0000
Subject: =?utf-8?q?=5Bissue7351=5D_Documentation_typos_found_in_=22zipfile_?=
	=?utf-8?q?=E2=80=94_Work_with_ZIP_archives=22?=
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1258577693.76.0.170209763183.issue7351@psf.upfronthosting.co.za>


Retro <vinetouu at gmail.com> added the comment:

Thanks for upcassing 'Python'.

I have to ask you why are all other classes named in the form of
...ZipFile, like
- exception: LargeZipFile
- class: ZipFile
- class: PyZipFile

Please at least consider of making the class BadZipfile consistent to
other classes and let it be renamed to BadZipFile. Thank you again.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Wed Nov 18 21:58:57 2009
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois_Mauger?=)
Date: Wed, 18 Nov 2009 20:58:57 +0000
Subject: [issue7352] python2.6-config --ldflags out of /usr and missing
	-L<install_lib_dir>
Message-ID: <1258577937.58.0.058967075582.issue7352@psf.upfronthosting.co.za>


Changes by Fran?ois Mauger <mauger at lpccaen.in2p3.fr>:


----------
components: Installation
nosy: mauger
severity: normal
status: open
title: python2.6-config --ldflags out of /usr and missing -L<install_lib_dir>
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7352>
_______________________________________

From report at bugs.python.org  Wed Nov 18 22:00:45 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Wed, 18 Nov 2009 21:00:45 +0000
Subject: [issue7341] test_tarfile failing (file in use when deleting) on
	Windows buildbots
In-Reply-To: <1258487418.77.0.523197359999.issue7341@psf.upfronthosting.co.za>
Message-ID: <1258578045.87.0.992467800459.issue7341@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Mmm, chocolate... ;-)

Okay, consider it done.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7341>
_______________________________________

From report at bugs.python.org  Wed Nov 18 22:05:41 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 18 Nov 2009 21:05:41 +0000
Subject: [issue7353] Why was Include/intobject.h removed in 3.1?
In-Reply-To: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za>
Message-ID: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

I'm attempting to package Python 3 for a Linux distribution, together with a stack of python extension 
modules; I'm currently using Python-3.1.1.   (see https://fedoraproject.org/wiki/Features/Python3F13 )

Many of these extension modules are close to compiling under both python 2 and python 3.

The page "http://wiki.python.org/moin/PortingExtensionModulesToPy3k" refers to using the macros in 
intobject.h, so that all PyInt_* calls in the python 3 build are aliased to PyLong_ API hooks.

Similarly, the page: http://docs.python.org/howto/cporting.html recommends using this file.

However, that header file was removed in this commit:
  http://svn.python.org/view?view=rev&revision=71697
with this message:
  Issue #4910:  PyNumber_Int is deprecated in 3.0.1; will be removed in 3.1.
(which links to this issue: http://bugs.python.org/issue4910 ; that issue refers to removal of the 
nb_long slot).

This seems to make it harder to port modules.

Is is acceptable if I ship that header file in my distribution packages of python-3.1.1 ?  (possibly 
with a reworded deprecation warning?)

Alternatively, is the fix to migrate all usage of the PyInt_ API to the PyLong_ equivalents ?  That 
would cause a change of behavior for the python 2 builds, assuming a shared source tree.

(I'd much prefer to ship the latest in the py3k branch than to stay with 3.0.1 for this)


In any case, it seems like the porting documentation isn't in sync with the code.

Hope this is helpful.

----------
components: Interpreter Core
messages: 95455
nosy: dmalcolm
severity: normal
status: open
title: Why was Include/intobject.h removed in 3.1?
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7353>
_______________________________________

From report at bugs.python.org  Wed Nov 18 22:07:47 2009
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois_Mauger?=)
Date: Wed, 18 Nov 2009 21:07:47 +0000
Subject: [issue7352] python2.6-config --ldflags out of /usr and missing
	-L<install_lib_dir>
In-Reply-To: <1258578467.08.0.137292547946.issue7352@psf.upfronthosting.co.za>
Message-ID: <1258578467.08.0.137292547946.issue7352@psf.upfronthosting.co.za>


New submission from Fran?ois Mauger <mauger at lpccaen.in2p3.fr>:

Hi Python!

I installed python2.6 from official source tarball under Scientific
Linux 5.2. I use the python2.6-config utility through makefiles to link
against lipython2.6.so. The installation prefix is NOT /usr nor some
standard /usr/local path.
The problem is that the python2.6-config --ldflags
does not print the linker -L<install shared library path>
so 'ld' failed with some "non found lipython2.6.so" error.

Is it a feature or a mistake in the 
build/installation process of Python2.6 ?

Thanks a lot to give any useful hint.

Some details of my config follow: 
>>>
bash-3.2$ cat /etc/redhat-release 
Scientific Linux SL release 5.3 (Boron)

bash-3.2$ uname -a
Linux XXXXXX 2.6.18-164.6.1.el5 #1 SMP Tue Nov 3 23:02:51 EST 2009
x86_64 x86_64 x86_64 GNU/Linux

bash-3.2$ python -V
Python 2.6.4

bash-3.2$ python2.6-config --prefix
/some_path/sw/python/install_2.6.4_Linux-x86_64

bash-3.2$ ls -l /some_path/sw/python/install_2.6.4_Linux-x86_64/lib
total 5419
lrwxr-xr-x  1 mauger nemo      19 Nov 18 11:03 libpython2.6.so ->
libpython2.6.so.1.0
-r-xr-xr-x  1 mauger nemo 5524796 Nov 18 11:03 libpython2.6.so.1.0
drwxr-xr-x 25 mauger nemo   22528 Nov 18 11:04 python2.6

bash-3.2$ python2.6-config --cflags
-I/some_path/sw/python/install_2.6.4_Linux-x86_64/include/python2.6
-I/some_path/sw/python/install_2.6.4_Linux-x86_64/include/python2.6
-fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes

HERE I don't get the -L/some_path/sw/python/install_2.6.4_Linux-x86_64/lib:

bash-3.2$ python2.6-config --ldflags  
-lpthread -ldl -lutil -lm -lpython2.6
<<<

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7352>
_______________________________________

From report at bugs.python.org  Wed Nov 18 22:16:49 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 18 Nov 2009 21:16:49 +0000
Subject: [issue5080] PyArg_Parse* should raise TypeError for float parsed with
	integer format
In-Reply-To: <1233059037.74.0.384834765102.issue5080@psf.upfronthosting.co.za>
Message-ID: <1258579009.17.0.715837873873.issue5080@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5080>
_______________________________________

From report at bugs.python.org  Wed Nov 18 22:43:57 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Nov 2009 21:43:57 +0000
Subject: [issue6816] Provide CPython command line functionality via runpy
	module
In-Reply-To: <1258551745.3476.0.camel@localhost>
Message-ID: <4B046A94.4070301@gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> (Was it one of the unstable buildbots that picked this up? I didn't see
>> anything come through on the checkins list)
> 
> Buildbot failures have stopped being e-mailed long ago it seems.
> (ah, you really thought our buildbots were all green in all that
> time? :P)

I knew the stable list was a lot shorter than the full list, so I
thought it was remotely possible :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6816>
_______________________________________

From report at bugs.python.org  Wed Nov 18 22:47:57 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Nov 2009 21:47:57 +0000
Subject: [issue6816] Provide CPython command line functionality via runpy
	module
In-Reply-To: <1251802599.29.0.539498266032.issue6816@psf.upfronthosting.co.za>
Message-ID: <1258580877.67.0.292184115067.issue6816@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy:  -r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6816>
_______________________________________

From report at bugs.python.org  Wed Nov 18 23:16:22 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 18 Nov 2009 22:16:22 +0000
Subject: [issue7353] Why was Include/intobject.h removed in 3.1?
In-Reply-To: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za>
Message-ID: <1258582582.05.0.937497507877.issue7353@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7353>
_______________________________________

From report at bugs.python.org  Thu Nov 19 00:48:42 2009
From: report at bugs.python.org (Paul Moore)
Date: Wed, 18 Nov 2009 23:48:42 +0000
Subject: [issue7354] distutils.tests.test_msvc9compiler - dragfullwindows can
	have value 2
In-Reply-To: <1258588122.3.0.424936986144.issue7354@psf.upfronthosting.co.za>
Message-ID: <1258588122.3.0.424936986144.issue7354@psf.upfronthosting.co.za>


New submission from Paul Moore <p.f.moore at gmail.com>:

It looks like the "Control Panel\Desktop\dragfullwindows" registry entry
can have value 2 (it does on my buildbot!) The distutils test
"test_msvc9compiler" assumes that only values 0 and 1 are valid.

The following patch (against trunk) fixes this. I've tested it on my
buildbot machine and it seems to do the trick.

----------
assignee: tarek
components: Distutils, Tests
files: msvc9compiler.patch
keywords: buildbot, patch, patch
messages: 95458
nosy: pmoore, tarek
severity: normal
status: open
title: distutils.tests.test_msvc9compiler - dragfullwindows can have value 2
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15361/msvc9compiler.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7354>
_______________________________________

From report at bugs.python.org  Thu Nov 19 01:39:30 2009
From: report at bugs.python.org (Matt Giuca)
Date: Thu, 19 Nov 2009 00:39:30 +0000
Subject: [issue5827] os.path.normpath doesn't preserve unicode
In-Reply-To: <1240547039.35.0.461990786151.issue5827@psf.upfronthosting.co.za>
Message-ID: <1258591170.63.0.403551861757.issue5827@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Thanks Ezio.

I've updated the patch to incorporate your suggestions.

Note that I too have only tested it on Linux, but I tested both
posixpath and ntpath (and there is no OS-specific code, except for the
filenames themselves).

I'm not sure if using assertTrue(isinstance ...) is better than
assertEqual(type ...), because the type equality checking produces this
error:
AssertionError: <type 'str'> != <type 'unicode'>
while isinstance produces this unhelpful error:
AssertionError: False is not True

But oh well, I made the change anyway as most test cases use isinstance.

----------
Added file: http://bugs.python.org/file15362/normpath.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5827>
_______________________________________

From report at bugs.python.org  Thu Nov 19 01:43:54 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 19 Nov 2009 00:43:54 +0000
Subject: [issue7349] StringIO.StringIO, io.BytesIO,
	and io.StringIO accept None in places where other file-like objects
	don't
In-Reply-To: <1258570914.64.0.211682819163.issue7349@psf.upfronthosting.co.za>
Message-ID: <1258591434.9.0.966224833571.issue7349@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7349>
_______________________________________

From report at bugs.python.org  Thu Nov 19 02:07:24 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 19 Nov 2009 01:07:24 +0000
Subject: [issue3976] pprint._safe_repr is not general enough in one instance
In-Reply-To: <1222445700.05.0.107288672735.issue3976@psf.upfronthosting.co.za>
Message-ID: <1258592844.12.0.138010101428.issue3976@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed.  See r76389 and r76390.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3976>
_______________________________________

From report at bugs.python.org  Thu Nov 19 02:07:50 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 19 Nov 2009 01:07:50 +0000
Subject: [issue7263] Fix set.intersection docstring
In-Reply-To: <1257351879.79.0.961594941998.issue7263@psf.upfronthosting.co.za>
Message-ID: <1258592870.8.0.196000894929.issue7263@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7263>
_______________________________________

From report at bugs.python.org  Thu Nov 19 02:12:37 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 19 Nov 2009 01:12:37 +0000
Subject: [issue6454] Add "example" keyword argument to optparse constructor
In-Reply-To: <1247183660.32.0.307989578437.issue6454@psf.upfronthosting.co.za>
Message-ID: <1258593157.99.0.724246293886.issue6454@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: rhettinger -> gward
nosy: +gward

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6454>
_______________________________________

From report at bugs.python.org  Thu Nov 19 02:26:55 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 19 Nov 2009 01:26:55 +0000
Subject: [issue6738] Wrong doc strings in itertools
In-Reply-To: <1250753532.16.0.563820931893.issue6738@psf.upfronthosting.co.za>
Message-ID: <1258594015.97.0.781627798498.issue6738@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed.  See r76391 to r76394.
Thanks for the report.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6738>
_______________________________________

From report at bugs.python.org  Thu Nov 19 03:57:37 2009
From: report at bugs.python.org (Rich Healey)
Date: Thu, 19 Nov 2009 02:57:37 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1258599457.79.0.59644106814.issue7206@psf.upfronthosting.co.za>


Rich Healey <richo at psych0tik.net> added the comment:

I looked into it a bit further.

With some trial and error I narrowed the source of the problem to be the 
'KernelModeDriverInstall' option under compatibility. I believe this 
isn't a problem, because python shouldn't be trying to install drivers, 
and even if it needed to presumably that would be nested in something 
loaded dynamically, rather than the original image so it could catch the 
issue and deal with it.

I will try to reproduce this on another machine to double check my 
logic. Thanks again for all your help Martin.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7206>
_______________________________________

From report at bugs.python.org  Thu Nov 19 04:01:10 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 19 Nov 2009 03:01:10 +0000
Subject: [issue5037] unicode(x) for weakref.proxy objects invokes __str__
	instead of __unicode__
In-Reply-To: <1232723011.79.0.257405867279.issue5037@psf.upfronthosting.co.za>
Message-ID: <1258599670.21.0.457254403823.issue5037@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r76395.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5037>
_______________________________________

From report at bugs.python.org  Thu Nov 19 06:28:31 2009
From: report at bugs.python.org (Moriyoshi Koizumi)
Date: Thu, 19 Nov 2009 05:28:31 +0000
Subject: [issue5890] Subclassing property doesn't preserve the auto __doc__
	behavior
In-Reply-To: <1241129592.84.0.608165277997.issue5890@psf.upfronthosting.co.za>
Message-ID: <1258608511.91.0.544417362485.issue5890@psf.upfronthosting.co.za>


Moriyoshi Koizumi <mozo+python at mozo.jp> added the comment:

@r.david.murray

> If MyProp is such a subclass, would
> print Fro.baz.__doc__ print "Get a baz" in 2.6.2 but raise an error in
> 2.6.3/4, or would it print None?

Just let it return None as they were for now.  I completely agree
there's a better fix like delegating the access to __doc__ to the base
class (property class in this specific case).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5890>
_______________________________________

From report at bugs.python.org  Thu Nov 19 06:41:58 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 19 Nov 2009 05:41:58 +0000
Subject: [issue7354] distutils.tests.test_msvc9compiler - dragfullwindows can
	have value 2
In-Reply-To: <1258588122.3.0.424936986144.issue7354@psf.upfronthosting.co.za>
Message-ID: <1258609318.27.0.709643273647.issue7354@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r76399, r76401 and r76402

Thx

----------
status: open -> closed
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7354>
_______________________________________

From report at bugs.python.org  Thu Nov 19 09:17:23 2009
From: report at bugs.python.org (Chris Withers)
Date: Thu, 19 Nov 2009 08:17:23 +0000
Subject: [issue6816] Provide CPython command line functionality via runpy
	module
In-Reply-To: <1251802599.29.0.539498266032.issue6816@psf.upfronthosting.co.za>
Message-ID: <1258618643.22.0.680523713568.issue6816@psf.upfronthosting.co.za>


Changes by Chris Withers <chris at simplistix.co.uk>:


----------
nosy:  -cjw296

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6816>
_______________________________________

From report at bugs.python.org  Thu Nov 19 09:31:54 2009
From: report at bugs.python.org (Phillip Hellewell)
Date: Thu, 19 Nov 2009 08:31:54 +0000
Subject: [issue1488943] difflib.Differ() doesn't always add hints for tab
	characters
Message-ID: <1258619514.5.0.500711880644.issue1488943@psf.upfronthosting.co.za>


Phillip Hellewell <sshock3 at gmail.com> added the comment:

Please apply the patch ASAP.  This bug is affecting downstream product
viewvc in a very adverse way.  See
http://viewvc.tigris.org/issues/show_bug.cgi?id=436

It's sad that I spent several hours tracking down this bug only to find
out that henryl found it and provided a fix *3 and a half years ago*. 
Why is it taking so long to apply such a small yet important patch?

----------
nosy: +sshock

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1488943>
_______________________________________

From report at bugs.python.org  Thu Nov 19 10:42:01 2009
From: report at bugs.python.org (Steve Krenzel)
Date: Thu, 19 Nov 2009 09:42:01 +0000
Subject: [issue7355] Struct incorrectly compiles format strings
In-Reply-To: <1258623721.25.0.299543316527.issue7355@psf.upfronthosting.co.za>
Message-ID: <1258623721.25.0.299543316527.issue7355@psf.upfronthosting.co.za>


New submission from Steve Krenzel <sgk284 at gmail.com>:

The struct module has a calcsize() method which reports the size of the data for a specified format 
string. In some instances, to the best of my knowledge, this is wrong.

To repro:
>>> from struct import calcsize
>>> calcsize("ci")
8
>>> calcsize("ic")
5

The correct answer is 5 (a single byte character and a four byte int take up 5 bytes of space). For 
some reason when a 'c' is followed by an 'i', this is wrong and instead allocates 4 bytes to the 'c'.
This has been verified in 2.6 and 2.5.

You can also repro this by using 's', '2c', and similar combinations in place of 'c'. as well as 'I' 
in place of 'i'. This might effect other combinations as well.

----------
components: Library (Lib)
messages: 95467
nosy: sgk284
severity: normal
status: open
title: Struct incorrectly compiles format strings
type: behavior
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7355>
_______________________________________

From report at bugs.python.org  Thu Nov 19 12:51:38 2009
From: report at bugs.python.org (Alexander Dutton)
Date: Thu, 19 Nov 2009 11:51:38 +0000
Subject: [issue5862] multiprocessing 'using a remote manager' example errors
	and possible 'from_address' code leftover
In-Reply-To: <1240883702.69.0.562256281063.issue5862@psf.upfronthosting.co.za>
Message-ID: <1258631498.28.0.467196900517.issue5862@psf.upfronthosting.co.za>


Changes by Alexander Dutton <dev at alexdutton.co.uk>:


----------
nosy: +alexdutton

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5862>
_______________________________________

From report at bugs.python.org  Thu Nov 19 13:46:05 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 19 Nov 2009 12:46:05 +0000
Subject: [issue7355] Struct incorrectly compiles format strings
In-Reply-To: <1258623721.25.0.299543316527.issue7355@psf.upfronthosting.co.za>
Message-ID: <1258634765.06.0.269437509632.issue7355@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

It's a padding issue, having to do with putting values at the correct
word boundaries.

----------
nosy: +eric.smith
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7355>
_______________________________________

From report at bugs.python.org  Thu Nov 19 14:52:25 2009
From: report at bugs.python.org (Tom Lynn)
Date: Thu, 19 Nov 2009 13:52:25 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1258638745.35.0.917730127591.issue1859@psf.upfronthosting.co.za>


Tom Lynn <tlynn at users.sourceforge.net> added the comment:

This bug should be re-opened, since there is definitely a bug here.  
I think the patch was incorrectly rejected.

If I can expand palfrey's example:

from textwrap import *
T = TextWrapper(replace_whitespace=False, width=75)
text = '''\
aaaaa aaaaa aaaaa aaaaa aaaaa
bbbbb bbbbb bbbbb bbbbb bbbbb
ccccc ccccc ccccc ccccc ccccc
ddddd ddddd ddddd ddddd ddddd
eeeee eeeee eeeee eeeee eeeee'''
for line in T.wrap(text): print line

Python 2.5 textwrap turns it into:

aaaaa aaaaa aaaaa aaaaa aaaaa
bbbbb bbbbb bbbbb bbbbb bbbbb
ccccc ccccc
ccccc ccccc ccccc
ddddd ddddd ddddd ddddd ddddd
eeeee eeeee eeeee eeeee
eeeee

That can't be right.  palfrey's patch leaves the input unchanged, which 
seems correct to me.  I think Guido guessed wrong here: the docs for 
replace_whitespace say:

  If true, each whitespace character (as defined by string.whitespace)
  remaining after tab expansion will be replaced by a single space

The text should therefore not be reflowed in this case since 
replace_whitespace=False.  palfrey's patch seems correct to me.

It can be made to reflow to the full width by editing palfrey's patch, 
but that would disagree with the docs and break code.

----------
nosy: +tlynn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Thu Nov 19 15:07:25 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 19 Nov 2009 14:07:25 +0000
Subject: [issue7353] Why was Include/intobject.h removed in 3.1?
In-Reply-To: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za>
Message-ID: <1258639645.94.0.636054575624.issue7353@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> However, that header file was removed in this commit:
>  http://svn.python.org/view?view=rev&revision=71697

Hmm.  That was me.

> with this message:
>   Issue #4910:  PyNumber_Int is deprecated in 3.0.1; will be removed in
> 3.1.

That's the message for r69517, I think, which just added an entry to
Include/intobject.h.  The message for r71697 was:

"The comments at the top of intobject.h say that it will be removed in
3.1.  Make it so."

I'm not too sure of the history here, but I suspect that
Include/intobject.h was at least partly an aid to porting the Python
extension modules from 2.x to 3.0, rather than third-party modules.

Christian, Benjamin:  any comments?

I'm -1 on resurrecting Include/intobject.h in its old location.  I don't
much like the idea of having a random include file that's no longer used
by Python itself in the main Include directory;  it'll likely succumb to
bitrot before long.  But maybe there's a place for 2-to-3 porting aids
in the Tools directory, where there's less expectation that files are
well-maintained?

> Is is acceptable if I ship that header file in my distribution
> packages of python-3.1.1 ?  (possibly with a reworded deprecation
> warning?)

I can't see any problem with this.

I agree the porting documentation needs to be updated, whatever happens.

----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +benjamin.peterson, christian.heimes, georg.brandl, mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7353>
_______________________________________

From report at bugs.python.org  Thu Nov 19 15:09:56 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 19 Nov 2009 14:09:56 +0000
Subject: [issue7353] Why was Include/intobject.h removed in 3.1?
In-Reply-To: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za>
Message-ID: <1258639796.39.0.324644064124.issue7353@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I didn't mean to assign this to Georg.  Apologies.

----------
assignee: georg.brandl -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7353>
_______________________________________

From report at bugs.python.org  Thu Nov 19 15:21:08 2009
From: report at bugs.python.org (Marcin Kasperski)
Date: Thu, 19 Nov 2009 14:21:08 +0000
Subject: [issue6454] Add "example" keyword argument to optparse constructor
In-Reply-To: <1247183660.32.0.307989578437.issue6454@psf.upfronthosting.co.za>
Message-ID: <1258640468.41.0.0924196943685.issue6454@psf.upfronthosting.co.za>


Marcin Kasperski <Marcin.Kasperski at mekk.waw.pl> added the comment:

I found this bug while looking for suggestions how to add examples to
the optparse help call, but I feel there is a better and more general
solution - just provide some minimal formatting for description: treat
empty line as paragraph separator. Then I would be able to add example
or anything else to the description formatting it as necessary

----------
nosy: +Mekk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6454>
_______________________________________

From report at bugs.python.org  Thu Nov 19 15:23:01 2009
From: report at bugs.python.org (Retro)
Date: Thu, 19 Nov 2009 14:23:01 +0000
Subject: =?utf-8?q?=5Bissue7351=5D_Documentation_typos_found_in_=22zipfile_?=
	=?utf-8?q?=E2=80=94_Work_with_ZIP_archives=22?=
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1258640581.31.0.641876918542.issue7351@psf.upfronthosting.co.za>


Retro <vinetouu at gmail.com> added the comment:

I suggest renaming the class from BadZipfile to BadZipFile. We have a
class named LargeZipFile. It would make sence to have the previously
mentioned class named as BadZipFile then. What is your verdict on that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Thu Nov 19 15:33:04 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 19 Nov 2009 14:33:04 +0000
Subject: [issue7355] Struct incorrectly compiles format strings
In-Reply-To: <1258623721.25.0.299543316527.issue7355@psf.upfronthosting.co.za>
Message-ID: <1258641184.35.0.597842496306.issue7355@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

What Eric said.  You can see the padding explicitly in the results of
struct.pack:

>>> struct.pack("ci", '*', 0x12131415) # 8-byte result, 3 padding bytes
'*\x00\x00\x00\x15\x14\x13\x12'
>>> struct.pack("ic", 0x12131415, '*') # 5-byte result, no padding.
'\x15\x14\x13\x12*'

Note the 3 zero bytes in the first result string.

This gets reported frequently enough that I wonder whether the docs
should be rearranged and/or expanded.  The existence of padding is
mentioned, but not particularly prominently or thoroughly.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7355>
_______________________________________

From report at bugs.python.org  Thu Nov 19 15:33:08 2009
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 19 Nov 2009 14:33:08 +0000
Subject: [issue7356] parsing of ldconfig output in ctypes/utils.py depends on
	the locale
In-Reply-To: <1258641188.9.0.430542588966.issue7356@psf.upfronthosting.co.za>
Message-ID: <1258641188.9.0.430542588966.issue7356@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

% /sbin/ldconfig -p | grep GL
    libGLU.so.1 (libc6) => /usr/lib/libGLU.so.1
    libGLEW.so.1.5 (libc6) => /usr/lib/libGLEW.so.1.5
    libGL.so.1 (libc6, Syst?me d'exploitation ABI : Linux 2.4.20) =>
/usr/lib/libGL.so.1

the regexp fails to parse this. proposing to set LANG=C when calling
ldconfig.

----------
assignee: theller
components: ctypes
files: util.py.diff
keywords: patch
messages: 95475
nosy: doko, theller
severity: normal
status: open
title: parsing of ldconfig output in ctypes/utils.py depends on the locale
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15363/util.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7356>
_______________________________________

From report at bugs.python.org  Thu Nov 19 15:38:00 2009
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 19 Nov 2009 14:38:00 +0000
Subject: [issue5833] readline update
In-Reply-To: <1240605993.87.0.323265568101.issue5833@psf.upfronthosting.co.za>
Message-ID: <1258641480.08.0.0227044141718.issue5833@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

msg94560 should read "backported to the 2.6 branch". can we close the
report?

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5833>
_______________________________________

From report at bugs.python.org  Thu Nov 19 15:41:27 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 19 Nov 2009 14:41:27 +0000
Subject: =?utf-8?q?=5Bissue7351=5D_Documentation_typos_found_in_=22zipfile_?=
	=?utf-8?q?=E2=80=94_Work_with_ZIP_archives=22?=
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1258641687.57.0.460030541605.issue7351@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The old name could be deprecated and replaced by the right one, but as
Eric Smith mentioned on #python-dev, the class with the old name can't
be removed because - even if unlikely - the object might exist in a pickle.
So we can either live with the wrong name or deprecate it, fix the
places where it's used and live with a deprecated version that can't be
removed.

----------
nosy: +ezio.melotti
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Thu Nov 19 15:49:25 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 19 Nov 2009 14:49:25 +0000
Subject: [issue7353] cporting docs recommend using Include/intobject.h,
	which was removed in 3.1?
In-Reply-To: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za>
Message-ID: <1258642165.77.0.883838178311.issue7353@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You didn't.  Doc bugs are automatically assigned to Georg by the tracker.

----------
nosy: +r.david.murray
priority:  -> normal
stage:  -> needs patch
title: Why was Include/intobject.h removed in 3.1? -> cporting docs recommend using Include/intobject.h, which was removed in 3.1?
type:  -> behavior
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7353>
_______________________________________

From report at bugs.python.org  Thu Nov 19 15:50:15 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 19 Nov 2009 14:50:15 +0000
Subject: [issue7353] cporting docs recommend using Include/intobject.h,
	which was removed in 3.1?
In-Reply-To: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za>
Message-ID: <1258642215.18.0.0545621025074.issue7353@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy:  -r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7353>
_______________________________________

From report at bugs.python.org  Thu Nov 19 16:02:02 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Nov 2009 15:02:02 +0000
Subject: [issue5833] readline update
In-Reply-To: <1240605993.87.0.323265568101.issue5833@psf.upfronthosting.co.za>
Message-ID: <1258642922.94.0.121568782938.issue5833@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Can we close the report?

Well there's something else in the original patch, although I don't care
about it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5833>
_______________________________________

From report at bugs.python.org  Thu Nov 19 16:02:38 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 19 Nov 2009 15:02:38 +0000
Subject: [issue7355] Struct incorrectly compiles format strings
In-Reply-To: <1258623721.25.0.299543316527.issue7355@psf.upfronthosting.co.za>
Message-ID: <1258642958.03.0.0871670604993.issue7355@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Reopening for possible doc clarification.  Suggestions welcome!

----------
assignee:  -> mark.dickinson
components: +Documentation, Extension Modules -Library (Lib)
keywords: +easy
priority:  -> low
resolution: invalid -> 
stage: committed/rejected -> needs patch
status: closed -> open
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7355>
_______________________________________

From report at bugs.python.org  Thu Nov 19 16:21:28 2009
From: report at bugs.python.org (Eli Venter)
Date: Thu, 19 Nov 2009 15:21:28 +0000
Subject: [issue7357] tarfile doesn't detect disk full error on extraction
In-Reply-To: <1258644088.41.0.896427627172.issue7357@psf.upfronthosting.co.za>
Message-ID: <1258644088.41.0.896427627172.issue7357@psf.upfronthosting.co.za>


New submission from Eli Venter <eventer at jcvi.org>:

tarfile doesn't seem to return any error or raise any exception when an
extraction fills up the disk, making it hard to use safely. Both
extractall and extract suffer from this problem. I'm using CentOS 5.2
and python 2.6.2.

----------
components: Library (Lib)
messages: 95481
nosy: eliv
severity: normal
status: open
title: tarfile doesn't detect disk full error on extraction
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7357>
_______________________________________

From report at bugs.python.org  Thu Nov 19 16:50:22 2009
From: report at bugs.python.org (Ryan Shaw)
Date: Thu, 19 Nov 2009 15:50:22 +0000
Subject: [issue7358] cPickle crash on failed assertion
In-Reply-To: <1258645822.27.0.150067328286.issue7358@psf.upfronthosting.co.za>
Message-ID: <1258645822.27.0.150067328286.issue7358@psf.upfronthosting.co.za>


New submission from Ryan Shaw <ryan.shaw at stanfordalumni.org>:

def save_object(r, key, m):
    r.set(key, cPickle.dumps(m))

[4] >>> save_object(r, 'cluster', cluster)
python: ./Modules/cStringIO.c:419: O_cwrite: Assertion `oself->pos + l < 
2147483647' failed.
Aborted

Linux 2.6.30.9-96.fc11.x86_64 #1 SMP x86_64 GNU/Linux

----------
components: Library (Lib)
messages: 95482
nosy: rybesh
severity: normal
status: open
title: cPickle crash on failed assertion
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7358>
_______________________________________

From report at bugs.python.org  Thu Nov 19 16:56:24 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 19 Nov 2009 15:56:24 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1258646184.68.0.841514540887.issue1859@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I think the code originally wasn't meant to support this feature (honor 
embedded newlines when replace_whitespace=False). I'm thinking that we 
could add it though.  Maybe Mark is interested in getting this into 2.7 
and 3.2?  I imagine it needs a new unittest too.

----------
resolution: rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Thu Nov 19 17:05:13 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 19 Nov 2009 16:05:13 +0000
Subject: [issue7358] cPickle crash on failed assertion
In-Reply-To: <1258645822.27.0.150067328286.issue7358@psf.upfronthosting.co.za>
Message-ID: <1258646713.15.0.980175914433.issue7358@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

What are the types and values of cluster and r?

Can you reproduce this in a self-contained script?

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7358>
_______________________________________

From report at bugs.python.org  Thu Nov 19 17:09:53 2009
From: report at bugs.python.org (Retro)
Date: Thu, 19 Nov 2009 16:09:53 +0000
Subject: =?utf-8?q?=5Bissue7351=5D_Documentation_typos_found_in_=22zipfile_?=
	=?utf-8?q?=E2=80=94_Work_with_ZIP_archives=22?=
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1258646993.64.0.19587671931.issue7351@psf.upfronthosting.co.za>


Retro <vinetouu at gmail.com> added the comment:

I am merely speaking of renaming the class name from BadZipfile to
BadZipFile. 

class BadZipFile(exceptions.Exception):
    # etc.


Only the name is fixed at class definition. I am aiming for that in this
bug report. And then every other BadZipfile should be fixed to
BadZipFile. Is that doable?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Thu Nov 19 17:15:26 2009
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 19 Nov 2009 16:15:26 +0000
Subject: [issue7359] mailbox cannot modify mailboxes in system mail spool
In-Reply-To: <1258647326.68.0.261951425057.issue7359@psf.upfronthosting.co.za>
Message-ID: <1258647326.68.0.261951425057.issue7359@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

no change in behaviour in 2.6

the mailbox module in python 2.5 cannot modify mboxes in read-only
directories, e.g. the system mail spool.  This is because
mailbox._singlefileMailbox.flush() tries to write the modified mailbox
to a temporary file and then rename it.  See: 

penelope[tmp]$ python2.5
Python 2.5 (release25-maint, Dec  9 2006, 14:35:53) 
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import mailbox
>>> mbox = mailbox.mbox("/var/mail/nikolaus")
>>> mbox.clear()
>>> mbox.close()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/mailbox.py", line 623, in close
    self.flush()
  File "/usr/lib/python2.5/mailbox.py", line 570, in flush
    new_file = _create_temporary(self._path)
  File "/usr/lib/python2.5/mailbox.py", line 1885, in _create_temporary
    os.getpid()))
  File "/usr/lib/python2.5/mailbox.py", line 1875, in _create_carefully
    fd = os.open(path, os.O_CREAT | os.O_EXCL | os.O_RDWR)
OSError: [Errno 13] Permission denied:
'/tmp/mail/nikolaus.1195061622.penelope.4241'
>>>

----------
components: Library (Lib)
messages: 95486
nosy: doko
severity: normal
status: open
title: mailbox cannot modify mailboxes in system mail spool
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7359>
_______________________________________

From report at bugs.python.org  Thu Nov 19 17:20:22 2009
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 19 Nov 2009 16:20:22 +0000
Subject: [issue7360] [mailbox] race: mbox may lose data with concurrent access
In-Reply-To: <1258647622.46.0.810277433722.issue7360@psf.upfronthosting.co.za>
Message-ID: <1258647622.46.0.810277433722.issue7360@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

[forwarded from http://bugs.debian.org/451733]

the mailbox._singlefileMailbox class is not safe with concurrent access,
because mailbox._singlefileMailbox.flush() replaces the underlying file
with a new copy by constructing a temporary file and then renaming it.
This breaks all other class instances which have this mailbox open.  I'm
attaching a script demonstrating the problem. 

I think it's a bad idea to use rename(2) here; overwriting the file
content would fix the race condition, and #451274 too[1].

----------
components: Library (Lib)
messages: 95487
nosy: doko
severity: normal
status: open
title: [mailbox] race: mbox may lose data with concurrent access
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7360>
_______________________________________

From report at bugs.python.org  Thu Nov 19 17:20:41 2009
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 19 Nov 2009 16:20:41 +0000
Subject: [issue7360] [mailbox] race: mbox may lose data with concurrent access
In-Reply-To: <1258647622.46.0.810277433722.issue7360@psf.upfronthosting.co.za>
Message-ID: <1258647641.87.0.858189480436.issue7360@psf.upfronthosting.co.za>


Changes by Matthias Klose <doko at debian.org>:


Added file: http://bugs.python.org/file15364/mailbox-race.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7360>
_______________________________________

From report at bugs.python.org  Thu Nov 19 17:24:02 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 19 Nov 2009 16:24:02 +0000
Subject: =?utf-8?q?=5Bissue7351=5D_Documentation_typos_found_in_=22zipfile_?=
	=?utf-8?q?=E2=80=94_Work_with_ZIP_archives=22?=
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1258647842.54.0.266863204792.issue7351@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

It might be doable for Python and its stdlib, but all the programs and
modules that are using the old name will start raising errors if they
don't find the old name anymore.
If the old name is deprecated for at least one Python version (e.g.
2.7/3.2), these programs can fix it and then, after a few versions (e.g.
3.3), the old name can finally be removed.
There is still the pickle issue, even if IMHO it's so unlikely that it
shouldn't be relevant.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Thu Nov 19 17:27:11 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 19 Nov 2009 16:27:11 +0000
Subject: [issue7357] tarfile doesn't detect disk full error on extraction
In-Reply-To: <1258644088.41.0.896427627172.issue7357@psf.upfronthosting.co.za>
Message-ID: <1258648031.3.0.179893802769.issue7357@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

The TarFile constructor (as well as tarfile.open) takes an errorlevel
keyword argument. See
http://docs.python.org/dev/library/tarfile.html#tarfile-objects

I quote: "If errorlevel is 0, all errors are ignored when using
TarFile.extract(). Nevertheless, they appear as error messages in the
debug output, when debugging is enabled. If 1, all fatal errors are
raised as OSError or IOError exceptions. If 2, all non-fatal errors are
raised as TarError exceptions as well."

Hope that helps.

----------
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7357>
_______________________________________

From report at bugs.python.org  Thu Nov 19 17:42:49 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 19 Nov 2009 16:42:49 +0000
Subject: [issue5827] os.path.normpath doesn't preserve unicode
In-Reply-To: <1240547039.35.0.461990786151.issue5827@psf.upfronthosting.co.za>
Message-ID: <1258648969.28.0.296079936044.issue5827@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

assertTrue() also accepts a 'msg' argument where to explain what went
wrong in case of failure [1].

[1]:
http://docs.python.org/library/unittest.html#unittest.TestCase.assertTrue

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5827>
_______________________________________

From report at bugs.python.org  Thu Nov 19 17:52:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Nov 2009 16:52:20 +0000
Subject: [issue7360] [mailbox] race: mbox may lose data with concurrent access
In-Reply-To: <1258647622.46.0.810277433722.issue7360@psf.upfronthosting.co.za>
Message-ID: <1258649540.01.0.139522097353.issue7360@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> the mailbox._singlefileMailbox class is not safe with concurrent access,
> because mailbox._singlefileMailbox.flush() replaces the underlying file
> with a new copy by constructing a temporary file and then renaming it.
> This breaks all other class instances which have this mailbox open.

I don't think this class aims at being safe against concurrent access,
so having it fail loudly is a good thing.
Besides, the proposed cure (overwriting instead of renaming) looks worse
than the illness. The virtue of renaming is that it is atomic (on POSIX
systems at least), so you can't end up with a half-written mailbox if
there's a crash or an IO problem in the middle.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7360>
_______________________________________

From report at bugs.python.org  Thu Nov 19 17:56:51 2009
From: report at bugs.python.org (Runar Tenfjord)
Date: Thu, 19 Nov 2009 16:56:51 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1258649811.04.0.548309632722.issue3783@psf.upfronthosting.co.za>


Runar Tenfjord <runar.tenfjord at gmail.com> added the comment:

By utilizing triggers on inserts and deletes it is possible to
keep track of the size and speed up __len__ by 10 x.

SQL:

CREATE TABLE IF NOT EXISTS info
   (key TEXT UNIQUE NOT NULL,
    value INTEGER NOT NULL);

INSERT OR IGNORE INTO info (key,value) VALUES ('size',0);

CREATE TABLE IF NOT EXISTS shelf
    (key TEXT UNIQUE NOT NULL,
     value TEXT NOT NULL);

CREATE TRIGGER IF NOT EXISTS insert_shelf
    AFTER INSERT ON shelf
    BEGIN
         UPDATE info SET value = value + 1 WHERE key = 'size';
    END;

CREATE TRIGGER IF NOT EXISTS delete_shelf
    AFTER DELETE ON shelf
    BEGIN
         UPDATE info SET value = value - 1 WHERE key = 'size';
    END;

On my laptop this increase the speed of 'len' about 10x

I have a slightly modified version of dbsqlite.py for
running on python 2.5 utilizing the triggers for 
keep track of the size:

http://dpaste.com/hold/122439/

----------
nosy: +rute

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Thu Nov 19 17:59:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Nov 2009 16:59:10 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1258649950.19.0.11267020118.issue3783@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> needs patch
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Thu Nov 19 18:01:43 2009
From: report at bugs.python.org (Erik Carstensen)
Date: Thu, 19 Nov 2009 17:01:43 +0000
Subject: [issue5827] os.path.normpath doesn't preserve unicode
In-Reply-To: <1240547039.35.0.461990786151.issue5827@psf.upfronthosting.co.za>
Message-ID: <1258650103.92.0.539373832328.issue5827@psf.upfronthosting.co.za>


Erik Carstensen <sandberg at virtutech.com> added the comment:

Also, assertTrue has an alias failUnless which I personally find more
descriptive (I don't know if either form is preferred for inclusion in
Python though).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5827>
_______________________________________

From report at bugs.python.org  Thu Nov 19 18:06:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Nov 2009 17:06:46 +0000
Subject: [issue7360] [mailbox] race: mbox may lose data with concurrent access
In-Reply-To: <1258647622.46.0.810277433722.issue7360@psf.upfronthosting.co.za>
Message-ID: <1258650406.78.0.31913498865.issue7360@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Oops, sorry:
> I don't think this class aims at being safe against concurrent access,
> so having it fail loudly is a good thing.

I now understand that the problem is that it doesn't fail loudly. That's
what I get for replying too quickly.
Still, I don't think the suggested fix is ok. Perhaps we should simply
state in the documentation that flush() discards the old file, so that
other processes accessing it may get a surprise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7360>
_______________________________________

From report at bugs.python.org  Thu Nov 19 18:06:54 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 19 Nov 2009 17:06:54 +0000
Subject: [issue5827] os.path.normpath doesn't preserve unicode
In-Reply-To: <1240547039.35.0.461990786151.issue5827@psf.upfronthosting.co.za>
Message-ID: <1258650414.11.0.162117875996.issue5827@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

failUnless is deprecated in Python3.1 [1]. The assert* methods are
preferred over the fail* ones that are now deprecated.

[1]:
http://docs.python.org/3.1/library/unittest.html#unittest.TestCase.failUnless

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5827>
_______________________________________

From report at bugs.python.org  Thu Nov 19 18:18:30 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Nov 2009 17:18:30 +0000
Subject: [issue7360] [mailbox] race: mbox may lose data with concurrent access
In-Reply-To: <1258647622.46.0.810277433722.issue7360@psf.upfronthosting.co.za>
Message-ID: <1258651110.15.0.35595583029.issue7360@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, the doc is quite clear about it:

? Be very cautious when modifying mailboxes that might be simultaneously
changed by some other process. The safest mailbox format to use for such
tasks is Maildir; try to avoid using single-file formats such as mbox
for concurrent writing. ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7360>
_______________________________________

From report at bugs.python.org  Thu Nov 19 18:22:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Nov 2009 17:22:48 +0000
Subject: [issue5080] PyArg_Parse* should raise TypeError for float parsed with
	integer format
In-Reply-To: <1233059037.74.0.384834765102.issue5080@psf.upfronthosting.co.za>
Message-ID: <1258651368.83.0.617661519513.issue5080@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

+1 for a TypeError too.

----------
nosy: +pitrou
priority:  -> normal
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5080>
_______________________________________

From report at bugs.python.org  Thu Nov 19 18:28:33 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 19 Nov 2009 17:28:33 +0000
Subject: [issue5080] PyArg_Parse* should raise TypeError for float parsed with
	integer format
In-Reply-To: <1233059037.74.0.384834765102.issue5080@psf.upfronthosting.co.za>
Message-ID: <1258651713.07.0.4377406745.issue5080@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5080>
_______________________________________

From report at bugs.python.org  Thu Nov 19 18:30:20 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 19 Nov 2009 17:30:20 +0000
Subject: [issue7085] strptime problem
In-Reply-To: <1255042131.92.0.134837798932.issue7085@psf.upfronthosting.co.za>
Message-ID: <1258651820.97.0.754997334507.issue7085@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I committed a fix in r76403 (trunk), r76404 (2.6), r76405 (3.2), 76406 
(3.1)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7085>
_______________________________________

From report at bugs.python.org  Thu Nov 19 18:31:06 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 19 Nov 2009 17:31:06 +0000
Subject: [issue7144] imp.load_module in thread causes core dump on OSX 10.6
In-Reply-To: <1255635321.71.0.461133930779.issue7144@psf.upfronthosting.co.za>
Message-ID: <1258651866.32.0.233925776536.issue7144@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've just committed a fix for this issue in all 4 active branches (2.6, 
2.7, 3.1 and 3.2)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7144>
_______________________________________

From report at bugs.python.org  Thu Nov 19 18:33:31 2009
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 19 Nov 2009 17:33:31 +0000
Subject: [issue7356] parsing of ldconfig output in ctypes/utils.py depends on
	the locale
In-Reply-To: <1258641188.9.0.430542588966.issue7356@psf.upfronthosting.co.za>
Message-ID: <1258652011.0.0.674427507104.issue7356@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

I'm curious:  Which output do you get from:
  'LANG=C /sbin/ldconfig -p | fgrep GL'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7356>
_______________________________________

From report at bugs.python.org  Thu Nov 19 18:40:59 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 19 Nov 2009 17:40:59 +0000
Subject: [issue7180] "pydoc -k" can generate AttributeError on Mac OS X
In-Reply-To: <1256107397.12.0.192527244395.issue7180@psf.upfronthosting.co.za>
Message-ID: <1258652459.14.0.621625754692.issue7180@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The problem occurs in two occassions:

1) python was configured/built without the Carbon bindings (such
  as the copy that Apple ships)

2) python was build in 64-bit mode

In both cases Carbon.File does not have an FSSpec type.

Luckily this has already been fixed (r74681 in the 2.6 branch, and an 
earlier revision on the trunk).  The fix is in 2.6.4.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7180>
_______________________________________

From report at bugs.python.org  Thu Nov 19 18:43:11 2009
From: report at bugs.python.org (Ryan Shaw)
Date: Thu, 19 Nov 2009 17:43:11 +0000
Subject: [issue7358] cPickle crash on failed assertion
In-Reply-To: <1258645822.27.0.150067328286.issue7358@psf.upfronthosting.co.za>
Message-ID: <1258652591.55.0.724415717137.issue7358@psf.upfronthosting.co.za>


Ryan Shaw <ryan.shaw at stanfordalumni.org> added the comment:

r is the Redis python client. cluster is a large cluster tree along the 
lines of the cluster_node class found here: 
http://jesolem.blogspot.com/2009/04/hierarchical-clustering-in-python.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7358>
_______________________________________

From report at bugs.python.org  Thu Nov 19 18:46:02 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 19 Nov 2009 17:46:02 +0000
Subject: [issue7179] Unportable test(1) construct
In-Reply-To: <1256085687.72.0.300279109357.issue7179@psf.upfronthosting.co.za>
Message-ID: <1258652762.86.0.139655702708.issue7179@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Fixed the postflight issue in r76407 (trunk), r76408 (2.6), r76409 (3.2) 
and r76410 (3.1).

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7179>
_______________________________________

From report at bugs.python.org  Thu Nov 19 18:47:44 2009
From: report at bugs.python.org (Ryan Shaw)
Date: Thu, 19 Nov 2009 17:47:44 +0000
Subject: [issue7358] cPickle crash on failed assertion
In-Reply-To: <1258645822.27.0.150067328286.issue7358@psf.upfronthosting.co.za>
Message-ID: <1258652864.15.0.0504517509643.issue7358@psf.upfronthosting.co.za>


Ryan Shaw <ryan.shaw at stanfordalumni.org> added the comment:

I can't reproduce this in a self-contained script. Pickling a smaller 
cluster object and storing it in Redis works fine. The cluster object that 
caused the crash was large, a binary tree with >5000 leaves holding the 
results of a nine-hour calculation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7358>
_______________________________________

From report at bugs.python.org  Thu Nov 19 18:48:23 2009
From: report at bugs.python.org (Retro)
Date: Thu, 19 Nov 2009 17:48:23 +0000
Subject: =?utf-8?q?=5Bissue7351=5D_Documentation_typos_found_in_=22zipfile_?=
	=?utf-8?q?=E2=80=94_Work_with_ZIP_archives=22?=
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1258652903.35.0.967472962376.issue7351@psf.upfronthosting.co.za>


Retro <vinetouu at gmail.com> added the comment:

I made a patch which fixes the BadZipfile issue. Please take a look and
decide whether you'll toss it or use it. Maybe it'll come handy some
other time in the future.

----------
keywords: +patch
Added file: http://bugs.python.org/file15365/zipfile-patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Thu Nov 19 19:43:15 2009
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 19 Nov 2009 18:43:15 +0000
Subject: [issue7356] parsing of ldconfig output in ctypes/utils.py depends on
	the locale
In-Reply-To: <1258641188.9.0.430542588966.issue7356@psf.upfronthosting.co.za>
Message-ID: <1258656195.47.0.670731749023.issue7356@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

$ LANG=C /sbin/ldconfig -p | fgrep GL
	libGLU.so.1 (libc6) => /usr/lib/libGLU.so.1
	libGLEW.so.1.5 (libc6) => /usr/lib/libGLEW.so.1.5
	libGL.so.1 (libc6, OS ABI: Linux 2.4.20) => /usr/lib/libGL.so.1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7356>
_______________________________________

From report at bugs.python.org  Thu Nov 19 19:44:42 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 19 Nov 2009 18:44:42 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1258656282.73.0.0422909973558.issue7117@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Short float repr is now enabled in r76379.

Misc/NEWS entries added/updated in r76411.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Thu Nov 19 20:03:19 2009
From: report at bugs.python.org (Steve Krenzel)
Date: Thu, 19 Nov 2009 19:03:19 +0000
Subject: [issue7355] Struct incorrectly compiles format strings
In-Reply-To: <1258623721.25.0.299543316527.issue7355@psf.upfronthosting.co.za>
Message-ID: <1258657399.32.0.885520752464.issue7355@psf.upfronthosting.co.za>


Steve Krenzel <sgk284 at gmail.com> added the comment:

Just for clarification, why does "ci" get padded but "ic" doesn't? 
While I agree that updating the documentation would help clarify, 
perhaps either everything should be padded to word boundaries or 
nothing should.

It is weird behavior that "ic" != "ci". If both formats were 8 bytes 
then my first thought would have been "Oh, it's just getting padded", 
but with this inconsistency it appeared as a bug.

Whatever the reason behind this discrepancy is, it should definitely be 
included in the doc updates.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7355>
_______________________________________

From report at bugs.python.org  Thu Nov 19 20:07:52 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 19 Nov 2009 19:07:52 +0000
Subject: [issue7355] Struct incorrectly compiles format strings
In-Reply-To: <1258623721.25.0.299543316527.issue7355@psf.upfronthosting.co.za>
Message-ID: <1258657672.4.0.0637042015963.issue7355@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

It's basically because nothing comes after it. If you put something
after it, such as a zero length integer, you'll see:

>>> from struct import calcsize
>>> calcsize("ci")
8
>>> calcsize("ic")
5
>>> calcsize("ic0i")
8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7355>
_______________________________________

From report at bugs.python.org  Thu Nov 19 20:10:22 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 19 Nov 2009 19:10:22 +0000
Subject: [issue7355] Struct incorrectly compiles format strings
In-Reply-To: <1258623721.25.0.299543316527.issue7355@psf.upfronthosting.co.za>
Message-ID: <1258657822.0.0.604907120759.issue7355@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Just for clarification, why does "ci" get padded but "ic" doesn't?

Because no padding is necessary in the second case:  both the integer and 
the character already start at a position that's a multiple of 4---the 
integer at position 0 and the character at position 4.

In the first case, without padding, the integer wouldn't start at a word 
boundary.

The aim is to make sure that the byte sequence output by struct.pack 
matches the layout of a corresponding C struct.  In the first case inter-
item padding is necessary to make that work, in the second it isn't.

You could argue that in the second case, Python should add trailing 
padding, but I'm not sure what the point would be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7355>
_______________________________________

From report at bugs.python.org  Thu Nov 19 20:18:08 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 19 Nov 2009 19:18:08 +0000
Subject: [issue7361] Strange importlib error during test_multiprocessing
	failure
In-Reply-To: <1258658288.16.0.0772350847135.issue7361@psf.upfronthosting.co.za>
Message-ID: <1258658288.16.0.0772350847135.issue7361@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

One of the buildbots suffered a test_multiprocessing failure, which
itself is not such an unusual thing.  But the error that was
subsequently thrown looks like it might point to a place where
importlib's error handling could be improved.  The error that was thrown
certainly gives no clear indication of what really caused the problem.

The full buildbot report was:
http://www.python.org/dev/buildbot/all/builders/ia64%20Ubuntu%203.1/builds/93/steps/test/logs/stdio

Here are the tracebacks (the second one being the interesting one):

    Traceback (most recent call last):
      File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/multiprocessing/process.py",
line 233, in _bootstrap
        self.run()
      File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/multiprocessing/process.py",
line 88, in run
        self._target(*self._args, **self._kwargs)
      File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_multiprocessing.py",
line 1211, in _putter
        queue = manager.get_queue()
      File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/multiprocessing/managers.py",
line 644, in temp
        token, exp = self._create(typeid, *args, **kwds)
      File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/multiprocessing/managers.py",
line 544, in _create
        id, exposed = dispatch(conn, None, 'create', (typeid,)+args, kwds)
      File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/multiprocessing/managers.py",
line 79, in dispatch
        kind, result = c.recv()
      File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/multiprocessing/connection.py",
line 408, in recv
        s = self._conn.recv_bytes()
    IOError: [Errno 104] Connection reset by peer
    test test_multiprocessing failed -- Traceback (most recent call last):
      File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_multiprocessing.py",
line 1222, in test_rapid_restart
        queue = manager.get_queue()
      File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/multiprocessing/managers.py",
line 644, in temp
        token, exp = self._create(typeid, *args, **kwds)
      File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/multiprocessing/managers.py",
line 542, in _create
        conn = self._Client(self._address, authkey=self._authkey)
      File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/multiprocessing/connection.py",
line 427, in XmlClient
        import xmlrpc.client as xmlrpclib
      File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/importlib/_bootstrap.py",
line 151, in decorated
        return fxn(self, module)
      File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/importlib/_bootstrap.py",
line 399, in load_module
        return self._load_module(module)
      File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/importlib/_bootstrap.py",
line 324, in _load_module
        code_object = self.get_code(module.__name__)
      File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/importlib/_bootstrap.py",
line 411, in get_code
        pyc_timestamp = marshal._r_long(data[4:8])
      File
"/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/importlib/__init__.py",
line 65, in _r_long
        x = int_bytes[0]
    IndexError: index out of range

----------
components: Library (Lib)
messages: 95511
nosy: brett.cannon, jnoller, r.david.murray
priority: low
severity: normal
stage: test needed
status: open
title: Strange importlib error during test_multiprocessing failure
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7361>
_______________________________________

From report at bugs.python.org  Thu Nov 19 20:47:02 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 19 Nov 2009 19:47:02 +0000
Subject: [issue7355] Struct incorrectly compiles format strings
In-Reply-To: <1258623721.25.0.299543316527.issue7355@psf.upfronthosting.co.za>
Message-ID: <1258660022.75.0.433408222577.issue7355@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm half-convinced that struct.pack *should* ideally add trailing padding 
in the same situation that C does, for consistency with C.  Then calcsize 
would match C's sizeof.  If you're writing or reading a struct from C, 
it's probably easiest/most natural to write or read sizeof(my_struct) 
bytes, rather than worrying about stripping trailing padding for 
efficiency.

I don't see a sensible way to make this change without breaking backwards 
compatibility, though.

(Note: this still wouldn't mean that the calcsize result would be 
independent of order: calcsize('cci') and calcsize('cic') would still be 
different, for example, on a typical platform.)  

Eric's solution of adding '0i' should be included in the documentation 
update.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7355>
_______________________________________

From report at bugs.python.org  Thu Nov 19 20:50:05 2009
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 19 Nov 2009 19:50:05 +0000
Subject: [issue7356] parsing of ldconfig output in ctypes/utils.py depends on
	the locale
In-Reply-To: <1258641188.9.0.430542588966.issue7356@psf.upfronthosting.co.za>
Message-ID: <1258660205.62.0.23623193668.issue7356@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

I assume the patch is fine, would you like to apply it?  Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7356>
_______________________________________

From report at bugs.python.org  Thu Nov 19 21:27:54 2009
From: report at bugs.python.org (Andy Buckley)
Date: Thu, 19 Nov 2009 20:27:54 +0000
Subject: [issue444582] Finding programs in PATH, addition to os
Message-ID: <1258662474.8.0.728461547294.issue444582@psf.upfronthosting.co.za>


Changes by Andy Buckley <andy at insectnation.org>:


----------
nosy: +andybuckley

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue444582>
_______________________________________

From report at bugs.python.org  Thu Nov 19 21:54:23 2009
From: report at bugs.python.org (James Lingard)
Date: Thu, 19 Nov 2009 20:54:23 +0000
Subject: [issue7362] Incorrect error message with def((x)=0)
In-Reply-To: <1258664063.02.0.823547791226.issue7362@psf.upfronthosting.co.za>
Message-ID: <1258664063.02.0.823547791226.issue7362@psf.upfronthosting.co.za>


New submission from James Lingard <jchl at aristanetworks.com>:

def f((x)=0): pass

gives the following incorrect error message:

  SyntaxError: non-default argument follows default argument

"def f((x)): pass" is treated exactly the same as "def f(x): pass", so
it would seem sensible for the same to be true if a default value is
used.  But if this syntax is disallowed for some reason, the error
message should be fixed.

This appears to be related to bug #1557232.

[Tested on Python 2.6 (r26:66714, Jun  8 2009, 16:07:29).]

----------
components: Interpreter Core
messages: 95514
nosy: james.lingard
severity: normal
status: open
title: Incorrect error message with def((x)=0)
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7362>
_______________________________________

From report at bugs.python.org  Thu Nov 19 23:55:18 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 19 Nov 2009 22:55:18 +0000
Subject: [issue7362] Incorrect error message with def((x)=0)
In-Reply-To: <1258664063.02.0.823547791226.issue7362@psf.upfronthosting.co.za>
Message-ID: <1258671318.28.0.670374216561.issue7362@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r76416.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7362>
_______________________________________

From report at bugs.python.org  Fri Nov 20 00:03:27 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 19 Nov 2009 23:03:27 +0000
Subject: [issue7353] cporting docs recommend using Include/intobject.h,
	which was removed in 3.1?
In-Reply-To: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za>
Message-ID: <1258671807.93.0.168618723668.issue7353@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Hmm, I wish intobject.h hadn't been removed so soon. I'm not really sure
how a file of #defines could suffer bitrot. This point is probably moot,
though because there's little point in having its presence skip a
version. I suppose sticking it in Tools or even Doc/includes is the
second best option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7353>
_______________________________________

From report at bugs.python.org  Fri Nov 20 01:35:30 2009
From: report at bugs.python.org (Yuv Gre)
Date: Fri, 20 Nov 2009 00:35:30 +0000
Subject: [issue7363] Inconsisten Indentation In SocketServer Docs
In-Reply-To: <1258677330.72.0.00426773742619.issue7363@psf.upfronthosting.co.za>
Message-ID: <1258677330.72.0.00426773742619.issue7363@psf.upfronthosting.co.za>


New submission from Yuv Gre <ubershmekel at gmail.com>:

A bit nitpicky but there are 3 spaces instead of 4 in the docs. This is 
relevant to py3k and trunk.

http://docs.python.org/library/socketserver.html#socketserver-udpserver-
example

----------
assignee: georg.brandl
components: Documentation
files: 3-spaces-udp-server.patch
keywords: patch
messages: 95517
nosy: georg.brandl, ubershmekel
severity: normal
status: open
title: Inconsisten Indentation In SocketServer Docs
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15366/3-spaces-udp-server.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7363>
_______________________________________

From report at bugs.python.org  Fri Nov 20 01:36:24 2009
From: report at bugs.python.org (James Lingard)
Date: Fri, 20 Nov 2009 00:36:24 +0000
Subject: [issue7364] Traceback contains incorrect line number for duplicate
	argument in lambda definition
In-Reply-To: <1258677384.54.0.437692828037.issue7364@psf.upfronthosting.co.za>
Message-ID: <1258677384.54.0.437692828037.issue7364@psf.upfronthosting.co.za>


New submission from James Lingard <jchl at aristanetworks.com>:

The following python file:

  lambda a, a: 0

when executed gives the following backtrace:

    File "/tmp/test.py", line 0
  SyntaxError: duplicate argument 'a' in function definition

Note that the line number is 0, not 1.  (It's always 0, regardless of
the position in the file).

---

Note that this doesn't happen for other similar errors in lambda
functions, for example the file:

  lambda a=0, a: 0

leads to the following error message:

    File "/tmp/test.py", line 1
      lambda a=0, a: 0
  SyntaxError: non-default argument follows default argument

and it also doesn't happen for the same error in a 'def':

  def f(a, a): pass

leads to the following error message:

    File "/tmp/test.py", line 1
      def f(a, a): pass
  SyntaxError: duplicate argument 'a' in function definition

---

Tested on Python 2.6 (r26:66714, Jun  8 2009, 16:07:29).

----------
components: Interpreter Core
messages: 95518
nosy: james.lingard
severity: normal
status: open
title: Traceback contains incorrect line number for duplicate argument in lambda definition
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7364>
_______________________________________

From report at bugs.python.org  Fri Nov 20 02:17:20 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 20 Nov 2009 01:17:20 +0000
Subject: [issue7364] Traceback contains incorrect line number for duplicate
	argument in lambda definition
In-Reply-To: <1258677384.54.0.437692828037.issue7364@psf.upfronthosting.co.za>
Message-ID: <1258679840.23.0.724369368628.issue7364@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r76423.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7364>
_______________________________________

From report at bugs.python.org  Fri Nov 20 02:24:06 2009
From: report at bugs.python.org (Ed Plese)
Date: Fri, 20 Nov 2009 01:24:06 +0000
Subject: [issue7365] grp and pwd should treat uid and gid as unsigned
In-Reply-To: <1258680245.88.0.627899346962.issue7365@psf.upfronthosting.co.za>
Message-ID: <1258680245.88.0.627899346962.issue7365@psf.upfronthosting.co.za>


New submission from Ed Plese <ed at edplese.com>:

Both Linux and Solaris define uid_t and gid_t as unsigned integers.  The
pwd and grp modules cast these to signed long values that are then
converted with PyInt_FromLong.  For large values, greater than 2 ** 32 -
1, the result is correct when Python is compiled as a 64-bit executable,
but is incorrect when compiled as a 32-bit executable.

Similar bugs have been noted in the posix module as reported in #4591.

For example, on OpenSolaris build 127, the 32-bit version of Python
returns a negative uid: pw_uid=-2147483647:

$ file /usr/bin/python2.6
/usr/bin/python2.6:     ELF 32-bit LSB executable 80386 Version 1 [FPU],
dynamically linked, not stripped, no debugging information available

$ /usr/bin/python2.6
Python 2.6.2 (r262, Oct 26 2009, 01:06:14) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import pwd
>>> pwd.getpwnam('test at foo.com')
pwd.struct_passwd(pw_name='test at foo.com', pw_passwd='x',
pw_uid=-2147483647, pw_gid=10000, pw_gecos='Test User', pw_dir='',
pw_shell='')

$ file /usr/bin/amd64/python2.6
/usr/bin/amd64/python2.6:       ELF 64-bit LSB executable AMD64 Version
1 [SSE FXSR FPU], dynamically linked, not stripped, no debugging
information available

$ /usr/bin/amd64/python2.6
Python 2.6.2 (r262, Oct 26 2009, 01:09:04) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import pwd
>>> pwd.getpwnam('test at foo.com')
pwd.struct_passwd(pw_name='test at foo.com', pw_passwd='x',
pw_uid=2147483649, pw_gid=10000, pw_gecos='Test User', pw_dir='',
pw_shell='')

The attached patch against 2.6.4 changes PyInt_FromLong to
PyLong_FromUnsignedLong and changes casts to unsigned long.

----------
components: Extension Modules
files: pwd-grp-unsigned-uid.patch
keywords: patch
messages: 95520
nosy: eplese
severity: normal
status: open
title: grp and pwd should treat uid and gid as unsigned
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15367/pwd-grp-unsigned-uid.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7365>
_______________________________________

From report at bugs.python.org  Fri Nov 20 02:27:09 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Nov 2009 01:27:09 +0000
Subject: [issue5683] Speed up cPickle's pickling generally
In-Reply-To: <1238803338.21.0.932870288543.issue5683@psf.upfronthosting.co.za>
Message-ID: <1258680429.94.0.475371006265.issue5683@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Are you still willing to work on this?

----------
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5683>
_______________________________________

From report at bugs.python.org  Fri Nov 20 02:34:38 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Nov 2009 01:34:38 +0000
Subject: [issue7359] mailbox cannot modify mailboxes in system mail spool
In-Reply-To: <1258647326.68.0.261951425057.issue7359@psf.upfronthosting.co.za>
Message-ID: <1258680878.79.0.336402455253.issue7359@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The same remark as in issue7360, that is it is not robust at all to
overwrite the file rather than doing an atomic rename from a temporary
file. The only possible exception would be if you only /append/ to the
mbox file (and that's assuming all mailbox-reading software you use be
able to deal with a partially written message at the end of an mbox file).

----------
nosy: +akuchling, pitrou
priority:  -> normal
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7359>
_______________________________________

From report at bugs.python.org  Fri Nov 20 02:34:56 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Nov 2009 01:34:56 +0000
Subject: [issue7360] [mailbox] race: mbox may lose data with concurrent access
In-Reply-To: <1258647622.46.0.810277433722.issue7360@psf.upfronthosting.co.za>
Message-ID: <1258680896.68.0.706694200307.issue7360@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7360>
_______________________________________

From report at bugs.python.org  Fri Nov 20 03:23:00 2009
From: report at bugs.python.org (Valentin Kuznetsov)
Date: Fri, 20 Nov 2009 02:23:00 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1258683780.63.0.931565526551.issue6594@psf.upfronthosting.co.za>


Valentin Kuznetsov <vkuznet at gmail.com> added the comment:

Hi,
I just found this bug and would like to add my experience with 
performance of large JSON docs. I have a few JSON docs about 180MB in 
size which I read from data-services. I use python2.6, run on Linux, 64-
bit node w/ 16GB of RAM and 8 core CPU, Intel Xeon 2.33GHz each. I used 
both json and cjson modules to parse my documents. My observation that 
the amount of RAM used to parse such docs is about 2GB, which is a way 
too much. The total time spent about 30 seconds (using cjson). The 
content of my docs are very mixed, lists, strings, other dicts. I can 
provide them if it will be required, but it's 200MB :)

For comparison, I got the same data in XML and using 
cElementTree.iterparse I stay w/ 300MB RAM usage per doc, which is 
really reasonable to me.

I can provide some benchmarks and perform such tests if it will be 
required.

----------
nosy: +vkuznet

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6594>
_______________________________________

From report at bugs.python.org  Fri Nov 20 03:35:36 2009
From: report at bugs.python.org (Bob Ippolito)
Date: Fri, 20 Nov 2009 02:35:36 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1258684536.65.0.863566725746.issue6594@psf.upfronthosting.co.za>


Bob Ippolito <bob at redivi.com> added the comment:

Did you try the trunk of simplejson? It doesn't work quite the same way as 
the current json module in Python 2.6+.

Without the data or a tool to produce data that causes the problem, there 
isn't much I can do to help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6594>
_______________________________________

From report at bugs.python.org  Fri Nov 20 03:49:53 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Nov 2009 02:49:53 +0000
Subject: [issue7361] Strange importlib error during test_multiprocessing
	failure
In-Reply-To: <1258658288.16.0.0772350847135.issue7361@psf.upfronthosting.co.za>
Message-ID: <1258685393.58.0.299196493093.issue7361@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I will obviously have a look, but why the heck is test_multiprocessing 
calling importlib? Is it meant to do that? Or is this part of the -j flag 
for regrtest?

----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7361>
_______________________________________

From report at bugs.python.org  Fri Nov 20 03:50:30 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Nov 2009 02:50:30 +0000
Subject: [issue444582] Finding programs in PATH, addition to os
Message-ID: <1258685430.34.0.159999561233.issue444582@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue444582>
_______________________________________

From report at bugs.python.org  Fri Nov 20 03:51:50 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Nov 2009 02:51:50 +0000
Subject: [issue7361] Strange importlib error during test_multiprocessing
	failure
In-Reply-To: <1258658288.16.0.0772350847135.issue7361@psf.upfronthosting.co.za>
Message-ID: <1258685510.94.0.934874426109.issue7361@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

And it looks like the error was triggered from a malformed .pyc file that 
was truncated. Guess I need to be more careful with that possibility. =)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7361>
_______________________________________

From report at bugs.python.org  Fri Nov 20 03:59:30 2009
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 20 Nov 2009 02:59:30 +0000
Subject: [issue7311] Bug on regexp of HTMLParser
In-Reply-To: <1258043150.41.0.372876851796.issue7311@psf.upfronthosting.co.za>
Message-ID: <1258685970.36.0.0658279194932.issue7311@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Re: the BTW -- < and > should be entity-escaped when used in attribute
values inside tag attributes... (but are probably seldom found as part
of tag attribute values)

But the example you showed is not an attribute in a tag, but rather text
within a paired tag.

But your suggestion for the regexp seems correct to me, if the non-ASCII
characters are permitted for non-quoted attribute values.

----------
nosy: +v+python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7311>
_______________________________________

From report at bugs.python.org  Fri Nov 20 04:08:01 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Nov 2009 03:08:01 +0000
Subject: [issue7361] Strange importlib error during test_multiprocessing
	failure
In-Reply-To: <1258658288.16.0.0772350847135.issue7361@psf.upfronthosting.co.za>
Message-ID: <1258686481.27.0.531156433503.issue7361@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This was on a buildbot, and regrtest -j isn't used there, but in any
case it wouldn't affect importlib as far as I know.  From the traceback
it looks like multiprocessing is just doing an import.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7361>
_______________________________________

From report at bugs.python.org  Fri Nov 20 05:37:55 2009
From: report at bugs.python.org (Chiyuan Zhang)
Date: Fri, 20 Nov 2009 04:37:55 +0000
Subject: [issue7311] Bug on regexp of HTMLParser
In-Reply-To: <1258043150.41.0.372876851796.issue7311@psf.upfronthosting.co.za>
Message-ID: <1258691875.39.0.766697882788.issue7311@psf.upfronthosting.co.za>


Chiyuan Zhang <pluskid at gmail.com> added the comment:

re: Yes. In fact, the BTW is a different problem with respect to this
bug. And that seems to be more complicated to fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7311>
_______________________________________

From report at bugs.python.org  Fri Nov 20 07:07:35 2009
From: report at bugs.python.org (James Henstridge)
Date: Fri, 20 Nov 2009 06:07:35 +0000
Subject: [issue7366] weakref module example relies on behaviour not guaranteed
	by id()
In-Reply-To: <1258697255.57.0.532906770015.issue7366@psf.upfronthosting.co.za>
Message-ID: <1258697255.57.0.532906770015.issue7366@psf.upfronthosting.co.za>


New submission from James Henstridge <james at jamesh.id.au>:

The documentation for the weakref module contains an example that uses
WeakValueDictionary to implement a id2obj() lookup function that doesn't
store strong references to those objects.

This example implicitly assumes that the id() of an object will be
unique for the lifetime of the interpreter, when it is only unique for
the lifetime of the object.  The problem can be demonstrated like so:

1. create an object "foo"
2. function 1 remembers the id of this object with "oid1 = remember(foo)"
3. "foo" gets garbage collected
4. an object "bar" is created and happens to get the same memory location
5. function 2 remembers the id of this object with "oid2 = remember(bar)"
6. function 1 looks up its stored object ID with "id2obj(oid1)"

In step 6, the object "bar" is returned rather than an exception being
raised.

As well as the example being broken, the weakref module contains the
functionality a programmer would need to do this kind of thing safely:
use the weakref.ref type directly.

It'd be good to replace the example with a better one.

----------
assignee: georg.brandl
components: Documentation
messages: 95530
nosy: georg.brandl, jamesh
severity: normal
status: open
title: weakref module example relies on behaviour not guaranteed by id()
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7366>
_______________________________________

From report at bugs.python.org  Fri Nov 20 07:09:32 2009
From: report at bugs.python.org (James Henstridge)
Date: Fri, 20 Nov 2009 06:09:32 +0000
Subject: [issue7366] weakref module example relies on behaviour not guaranteed
	by id()
In-Reply-To: <1258697255.57.0.532906770015.issue7366@psf.upfronthosting.co.za>
Message-ID: <1258697372.77.0.093243271728.issue7366@psf.upfronthosting.co.za>


James Henstridge <james at jamesh.id.au> added the comment:

Forgot to include a link to the documentation I was talking about:

    http://docs.python.org/library/weakref#example

This example also appears in the 2.7a0 and 3.2a0 documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7366>
_______________________________________

From report at bugs.python.org  Fri Nov 20 08:08:52 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 20 Nov 2009 07:08:52 +0000
Subject: [issue7342] str(datetime_obj) doesn't include microseconds if their
	value is 0
In-Reply-To: <1258495371.1.0.197938868538.issue7342@psf.upfronthosting.co.za>
Message-ID: <1258700932.72.0.72710143105.issue7342@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If __str__ is supposed to produce "nice" output, the microsecond shouldn't 
be visible at all imho (special cases are not special enough to break the 
rules).
If the date/time object is read by a human he probably doesn't care of 
the microseconds anyway, if it's parsed by a machine the '0 microseconds' 
situation must be special-cased to avoid failures like the one mentioned in 
the first message.
The fact that the documentation of datetime.isotime() mentions it is not 
enough if the user doesn't know that it's used by str(), so a note should be 
added to the doc.
I don't know if/how the situation can be fixed though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7342>
_______________________________________

From report at bugs.python.org  Fri Nov 20 08:31:25 2009
From: report at bugs.python.org (Jay Lugo)
Date: Fri, 20 Nov 2009 07:31:25 +0000
Subject: [issue7367] OSError [errno 13] permission denied
In-Reply-To: <1258702285.22.0.207199237354.issue7367@psf.upfronthosting.co.za>
Message-ID: <1258702285.22.0.207199237354.issue7367@psf.upfronthosting.co.za>


New submission from Jay Lugo <jacewickman at gmail.com>:

I spend the better part of a day figuring out this relatively simple
problem with the help files in IDLE with python 2.6 on a mac OSX

I came about the solution by following the code errors all over
up and down the program files.

Eventual I came about the public folder ex..
Users/ME/Public

I spent time looking through the properties and settings tabs editing my
firewall settings and file sharing options (I reverted them when i fixed
the problem)
but i ended up removing all file sharing settings anyway.

I simply right clicked on the public folder and my permission was set
to "Write only(Drop Box)"
a simple change to "Reed and Write" fixed the IDLE error.

Hope i just saved some one some time.

----------
components: IDLE
messages: 95533
nosy: Quik_Foot
severity: normal
status: open
title: OSError [errno 13] permission denied
type: resource usage
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7367>
_______________________________________

From report at bugs.python.org  Fri Nov 20 10:19:10 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 20 Nov 2009 09:19:10 +0000
Subject: [issue7367] OSError [errno 13] permission denied
In-Reply-To: <1258702285.22.0.207199237354.issue7367@psf.upfronthosting.co.za>
Message-ID: <1258708750.67.0.725348713844.issue7367@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Can you be more specific about how to reproduce the problem you saw?  
Also, which version of Python were you using?  Please copy the information 
from the the first line of IDLE's Python Shell window, like so:

Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7367>
_______________________________________

From report at bugs.python.org  Fri Nov 20 10:50:20 2009
From: report at bugs.python.org (Yuv Gre)
Date: Fri, 20 Nov 2009 09:50:20 +0000
Subject: [issue7363] Inconsistent indentation in SocketServer docs
In-Reply-To: <1258677330.72.0.00426773742619.issue7363@psf.upfronthosting.co.za>
Message-ID: <1258710620.47.0.200980473164.issue7363@psf.upfronthosting.co.za>


Changes by Yuv Gre <ubershmekel at gmail.com>:


----------
title: Inconsisten Indentation In SocketServer Docs -> Inconsistent indentation in SocketServer docs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7363>
_______________________________________

From report at bugs.python.org  Fri Nov 20 12:17:28 2009
From: report at bugs.python.org (Jay Lugo)
Date: Fri, 20 Nov 2009 11:17:28 +0000
Subject: [issue7367] OSError [errno 13] permission denied
In-Reply-To: <1258702285.22.0.207199237354.issue7367@psf.upfronthosting.co.za>
Message-ID: <1258715848.19.0.756822287552.issue7367@psf.upfronthosting.co.za>


Jay Lugo <jacewickman at gmail.com> added the comment:

Python 2.6.4
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin

>From the best I can tell the error came about
when I updated my firewall/shared folder settings.
(I lost a computer on my home network due to my partner leaving me :( )
so I did a complete revamp of my network to close up any holes
and Bam no IDLE.

The solution as I said came about from simply changing the user access
on the public folder in User/ME/

I initially came across the error when attempting to get a modules list
and was returned a list of errors. One of them was the [errno 13].

Hope that clears things.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7367>
_______________________________________

From report at bugs.python.org  Fri Nov 20 12:57:52 2009
From: report at bugs.python.org (Tim Peters)
Date: Fri, 20 Nov 2009 11:57:52 +0000
Subject: [issue7342] str(datetime_obj) doesn't include microseconds if their
	value is 0
In-Reply-To: <1258495371.1.0.197938868538.issue7342@psf.upfronthosting.co.za>
Message-ID: <1258718272.38.0.507058752372.issue7342@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Ezio, it was Guido's design decision, it was intentional, and it's been
documented from the start(*).  So you can disagree with it, but you
won't get anywhere claiming it's "a bug":  intentional, documented
behaviors are never "bugs".  At best you can make a case for that
they're design errors.

But that won't fly either.  It's no more inconsistent than that, e.g.,
most floating-point numbers in practice aren't usually displayed with an
exponent, but if an exponent is needed, one is added to the output:

>>> .25
0.25
>>> .25 * 10**100
2.5e+99

Overly literal readings don't help your case either.  Yes, __str__ aims
at producing nice output, but it's pedantic to argue as if that is, or
should be, __str__'s /only/ goal.  Python's design just isn't that
simple-minded ;-)  If someone uses non-zero microseconds, presumably
they want to see them.

Utterly trivial mechanical parsing of str() output is a non-goal in Python.

Of course the failing test should be repaired, and that was a good
catch.  But the chance of changing the language to make the test work
as-is is approximately 0%.


(*) The datetime docs already say:

"""
__str__( ) 

For a datetime instance d, str(d) is equivalent to d.isoformat(' '). 
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7342>
_______________________________________

From report at bugs.python.org  Fri Nov 20 13:23:43 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 20 Nov 2009 12:23:43 +0000
Subject: [issue7342] str(datetime_obj) doesn't include microseconds if their
	value is 0
In-Reply-To: <1258495371.1.0.197938868538.issue7342@psf.upfronthosting.co.za>
Message-ID: <1258719823.65.0.46598506013.issue7342@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Yes, I wrote the previous message from a cellphone and I wasn't able to
check the doc. It is indeed already documented in datetime.__str__ --
sorry for the noise.
I also noticed that the microseconds are not the only thing that can
change in datetime.isoformat(), there are also the separator and the UTC
offset, so if someone is parsing the output of str(d)/d.isoformat(), he
should already include other checks anyway.

I agree that only the test should be fixed (and possibly others tests
should be added to check that str() outputs the right thing when there
is a UTC offset and/or a different separator).

I'll work on a patch for that.

----------
assignee: georg.brandl -> ezio.melotti
components:  -Documentation, Extension Modules

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7342>
_______________________________________

From report at bugs.python.org  Fri Nov 20 13:33:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Nov 2009 12:33:18 +0000
Subject: [issue6077] Unicode issue with tempfile on Windows
In-Reply-To: <1242902281.19.0.785534921176.issue6077@psf.upfronthosting.co.za>
Message-ID: <1258720398.8.0.14833680794.issue6077@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +IO -Library (Lib)
priority:  -> normal
stage:  -> patch review
versions: +Python 3.1, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6077>
_______________________________________

From report at bugs.python.org  Fri Nov 20 13:36:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Nov 2009 12:36:46 +0000
Subject: [issue5080] PyArg_Parse* should raise TypeError for float parsed with
	integer format
In-Reply-To: <1233059037.74.0.384834765102.issue5080@psf.upfronthosting.co.za>
Message-ID: <1258720606.1.0.954079294585.issue5080@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think this should be signalled on the mailing-list, by the way. I
expect everyone to agree of course :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5080>
_______________________________________

From report at bugs.python.org  Fri Nov 20 14:22:49 2009
From: report at bugs.python.org (JoostBehrends)
Date: Fri, 20 Nov 2009 13:22:49 +0000
Subject: [issue7368] Internal error in threading.py
In-Reply-To: <1258723369.04.0.0815144393289.issue7368@psf.upfronthosting.co.za>
Message-ID: <1258723369.04.0.0815144393289.issue7368@psf.upfronthosting.co.za>


New submission from JoostBehrends <joost at h-labahn.de>:

On Nov.20, 2009 i got the traceback below from Python 3.1.1 under
WindowsXP-SP3, as several times before. From code with 

def _core(func, my_args):
    A = Thread(target = func, args = my_args); A.start(); A.join()
_core(ask_user, (question, default_answer))

Doesn't matter from what, the traceback is showing no calling line (thus
there is at least a slip in threading.py's exception handlers):

Unhandled exception in thread started by <bound method Thread._bootstrap
of <Thread(Thread-1, stopped 288)>>
Traceback (most recent call last):
  File "D:\Programme\Python31\lib\threading.py", line 482, in _bootstrap
    self._bootstrap_inner()
  File "D:\Programme\Python31\lib\threading.py", line 558, in
_bootstrap_inner
    self._stop()
  File "D:\Programme\Python31\lib\threading.py", line 569, in _stop
    self._block.notify_all()
  File "D:\Programme\Python31\lib\threading.py", line 273, in notify_all
    self.notify(len(self._waiters))
  File "D:\Programme\Python31\lib\threading.py", line 265, in notify
    for waiter in waiters:
TypeError: function takes exactly 1 argument (0 given)

----------
components: Library (Lib)
messages: 95539
nosy: 3Jane
severity: normal
status: open
title: Internal error in threading.py
type: compile error
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7368>
_______________________________________

From report at bugs.python.org  Fri Nov 20 14:32:53 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Nov 2009 13:32:53 +0000
Subject: [issue7363] Inconsistent indentation in SocketServer docs
In-Reply-To: <1258677330.72.0.00426773742619.issue7363@psf.upfronthosting.co.za>
Message-ID: <1258723973.87.0.897237182668.issue7363@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks, fixed in r76430.  It'll get to the other doc versions eventually.

----------
nosy: +r.david.murray
priority:  -> low
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior
versions: +Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7363>
_______________________________________

From report at bugs.python.org  Fri Nov 20 14:46:59 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 20 Nov 2009 13:46:59 +0000
Subject: [issue5080] PyArg_Parse* should raise TypeError for float parsed with
	integer format
In-Reply-To: <1233059037.74.0.384834765102.issue5080@psf.upfronthosting.co.za>
Message-ID: <1258724819.06.0.93171602374.issue5080@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Yes, checking with python-dev sounds sensible.  I'll wait until there's
a working patch, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5080>
_______________________________________

From report at bugs.python.org  Fri Nov 20 14:50:32 2009
From: report at bugs.python.org (prm225)
Date: Fri, 20 Nov 2009 13:50:32 +0000
Subject: [issue7369] Fibonacci example does not include 0; section 4.6
In-Reply-To: <1258725032.09.0.34838264618.issue7369@psf.upfronthosting.co.za>
Message-ID: <1258725032.09.0.34838264618.issue7369@psf.upfronthosting.co.za>


New submission from prm225 <prm225 at gmail.com>:

The example starts off with 1 being printed, while the series is 
expected to begin with 0 and 1.
The example in 4.6 (defining functions) should have been:

def fib(n):
  a, b = 0, 1
  while a < n:
    print a,
    a, b = b, a+b
fib(2000)

0 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597

----------
assignee: georg.brandl
components: Documentation
messages: 95542
nosy: georg.brandl, prm225
severity: normal
status: open
title: Fibonacci example does not include 0; section 4.6
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7369>
_______________________________________

From report at bugs.python.org  Fri Nov 20 14:55:21 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 20 Nov 2009 13:55:21 +0000
Subject: [issue7369] Fibonacci example does not include 0; section 4.6
In-Reply-To: <1258725032.09.0.34838264618.issue7369@psf.upfronthosting.co.za>
Message-ID: <1258725321.47.0.565411829125.issue7369@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

That depends on whether you want to start the sequence with F_0  (=0) or
F_1 (=1), I guess.  Given Python's general preferences for zero-based
indexing, I agree that this very serious issue should be fixed.

See

http://www.research.att.com/~njas/sequences/A000045

for an authoritative reference.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7369>
_______________________________________

From report at bugs.python.org  Fri Nov 20 15:00:37 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Nov 2009 14:00:37 +0000
Subject: [issue7367] IDLE OSError [errno 13] permission denied accessing help
	files
In-Reply-To: <1258702285.22.0.207199237354.issue7367@psf.upfronthosting.co.za>
Message-ID: <1258725637.6.0.454577138224.issue7367@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

A more specific issue title will also help others hitting the same
problem...hopefully I've guessed correctly as to what it should be.

----------
nosy: +r.david.murray
priority:  -> normal
title: OSError [errno 13] permission denied -> IDLE OSError [errno 13] permission denied accessing help files
type: resource usage -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7367>
_______________________________________

From report at bugs.python.org  Fri Nov 20 15:01:17 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Nov 2009 14:01:17 +0000
Subject: [issue7367] IDLE OSError [errno 13] permission denied accessing help
	files
In-Reply-To: <1258702285.22.0.207199237354.issue7367@psf.upfronthosting.co.za>
Message-ID: <1258725677.72.0.253585515087.issue7367@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy:  -r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7367>
_______________________________________

From report at bugs.python.org  Fri Nov 20 15:01:59 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 20 Nov 2009 14:01:59 +0000
Subject: [issue7272] test_multiprocessing fails consistently with 'signal 12'
	on FreeBSD 6.2 buildbot.
In-Reply-To: <1257523034.1.0.340985846807.issue7272@psf.upfronthosting.co.za>
Message-ID: <1258725719.98.0.527321479441.issue7272@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I had an opportunity to play with a FreeBSD 7.2 box recently.

The diagnosis is simple.  The solution may be less so...

Diagnosis:  FreeBSD still considers POSIX semaphores (sem_open,
sem_close, etc.) to be experimental, so they're not enabled by default
on a standard install.  So the very first call to sem_open, from
SEM_CREATE in semaphore.c (around line 439), produces the Signal 12.

Enabling POSIX semaphores (assuming that they've been built into the
kernel, which they seem to have been by default) is as simple as
executing 'kldload sem' (as root) at a shell prompt.  After I did this,
test_multiprocessing ran and all tests passed.

So the question is what multiprocessing (and test_multiprocessing)
should do when POSIX semaphores aren't available.  I guess the options
are: (1) fail loudly, with an error message telling the user to enable
the POSIX semaphores, or (2) try to use SysV semaphores (which are
supported out of the box) instead.

In the immediate future we should probably at least detect when POSIX
semaphores don't exist, and skip test_multiprocessing in that case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7272>
_______________________________________

From report at bugs.python.org  Fri Nov 20 15:10:16 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 20 Nov 2009 14:10:16 +0000
Subject: [issue7353] cporting docs recommend using Include/intobject.h,
	which was removed in 3.1?
In-Reply-To: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za>
Message-ID: <1258726216.99.0.648002145076.issue7353@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Benjamin]
>I wish intobject.h hadn't been removed so soon.

Yes;  I'm sorry about that.

> I'm not really sure how a file of #defines could suffer bitrot.

Good point.  Me neither.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7353>
_______________________________________

From report at bugs.python.org  Fri Nov 20 15:16:58 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 20 Nov 2009 14:16:58 +0000
Subject: [issue7316] Add a timeout functionality to common locking operations
In-Reply-To: <1258133508.5.0.728130823639.issue7316@psf.upfronthosting.co.za>
Message-ID: <1258726618.68.0.193907455584.issue7316@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7316>
_______________________________________

From report at bugs.python.org  Fri Nov 20 15:17:46 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 20 Nov 2009 14:17:46 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1258726666.58.0.0319893785976.issue1859@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'll take a look.

----------
assignee:  -> mark.dickinson
priority:  -> normal
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Fri Nov 20 15:23:04 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 20 Nov 2009 14:23:04 +0000
Subject: [issue7272] test_multiprocessing fails consistently with 'signal 12'
	on FreeBSD 6.2 buildbot.
In-Reply-To: <1257523034.1.0.340985846807.issue7272@psf.upfronthosting.co.za>
Message-ID: <1258726984.56.0.193438139769.issue7272@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Thanks mark - if POSIX semaphores aren't available, we're largely dead-
on-arrival. I thought FBSD was at the point of enabling them by default 
- boo on me. See also: http://bugs.python.org/issue3770#msg73958 and 
http://bugs.python.org/issue3770#msg83495 - with martin's help last 
pycon I cut a lot of the "HAVE_BROKEN..." values to autoconf checks in 
configure.in.

I think the right way (however unpleasant) is to check to see if we have 
POSIX semaphores, period - if we don't, _multiprocessing should just not 
compile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7272>
_______________________________________

From report at bugs.python.org  Fri Nov 20 15:37:13 2009
From: report at bugs.python.org (Virgil Dupras)
Date: Fri, 20 Nov 2009 14:37:13 +0000
Subject: [issue7350] csv doesn't handle escaped characters properly
In-Reply-To: <1258571515.92.0.182844984253.issue7350@psf.upfronthosting.co.za>
Message-ID: <1258727833.95.0.961698977986.issue7350@psf.upfronthosting.co.za>


Virgil Dupras <hsoft at hardcoded.net> added the comment:

You have to tell the reader how to handle escaping. In your case, you 
should send escapechar="\\" in reader()'s kwargs.

----------
nosy: +vdupras

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7350>
_______________________________________

From report at bugs.python.org  Fri Nov 20 15:45:35 2009
From: report at bugs.python.org (Eli Venter)
Date: Fri, 20 Nov 2009 14:45:35 +0000
Subject: [issue7357] tarfile doesn't detect disk full error on extraction
In-Reply-To: <1258644088.41.0.896427627172.issue7357@psf.upfronthosting.co.za>
Message-ID: <1258728335.0.0.828406138599.issue7357@psf.upfronthosting.co.za>


Eli Venter <eventer at jcvi.org> added the comment:

Yes, thanks errorlevel works as expected, and errors are correctly
generated. It's quite unintuitive to ignore fatal errors by default
however.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7357>
_______________________________________

From report at bugs.python.org  Fri Nov 20 16:11:20 2009
From: report at bugs.python.org (JoostBehrends)
Date: Fri, 20 Nov 2009 15:11:20 +0000
Subject: [issue7368] Internal error in threading.py
In-Reply-To: <1258723369.04.0.0815144393289.issue7368@psf.upfronthosting.co.za>
Message-ID: <1258729880.25.0.478872255561.issue7368@psf.upfronthosting.co.za>


JoostBehrends <joost at h-labahn.de> added the comment:

Most probably better to ignore this. Sorry :(

The last line number 265 of the traceback is not the line causing the
error. This can be at quite another place, probably not in threading.py
- this is from code importing a new C-extension from me, who might
muddle the interpreter so terribly, that he is behaving like this
(unfortunately with code working very well on other opportunities).

I remember, that i had such a muddled interpreter with other problems
recently, and am working out now, what the real error might be (perhaps
missing Py_INCREFs). Still this is not the best behavior of the
interpreter, but one should not expect too much safety against
programming errors in C-extensions.

I wouldn't object a total deletion of this thread.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7368>
_______________________________________

From report at bugs.python.org  Fri Nov 20 16:13:53 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Nov 2009 15:13:53 +0000
Subject: [issue6077] Unicode issue with tempfile on Windows
In-Reply-To: <1242902281.19.0.785534921176.issue6077@psf.upfronthosting.co.za>
Message-ID: <1258730033.55.0.88080679922.issue6077@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch looks ok to me.

----------
assignee:  -> amaury.forgeotdarc
nosy: +pitrou
resolution:  -> accepted
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6077>
_______________________________________

From report at bugs.python.org  Fri Nov 20 17:08:55 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Nov 2009 16:08:55 +0000
Subject: [issue7368] Internal error in threading.py
In-Reply-To: <1258723369.04.0.0815144393289.issue7368@psf.upfronthosting.co.za>
Message-ID: <1258733335.33.0.161222250762.issue7368@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> normal
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7368>
_______________________________________

From report at bugs.python.org  Fri Nov 20 17:18:39 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 20 Nov 2009 16:18:39 +0000
Subject: [issue7272] test_multiprocessing fails consistently with 'signal 12'
	on FreeBSD 6.2 buildbot.
In-Reply-To: <1257523034.1.0.340985846807.issue7272@psf.upfronthosting.co.za>
Message-ID: <1258733919.86.0.444516046393.issue7272@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch that makes FreeBSD behave exactly as though HAVE_SEM_OPEN
is not defined, when semaphores aren't available.  On my FreeBSD 7.2
test system, it results in the multiprocessing module being built
(without the contents of semaphore.c), but the test is skipped, along
with a message indicating that semaphores don't work on that system.

I added an autoconf test for the sem_open failure, and reused the
already existing pyconfig.h variable HAVE_BROKEN_POSIX_SEMAPHORES.

----------
keywords: +patch
Added file: http://bugs.python.org/file15368/freebsd_multiprocessing.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7272>
_______________________________________

From report at bugs.python.org  Fri Nov 20 17:18:53 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 20 Nov 2009 16:18:53 +0000
Subject: [issue7272] test_multiprocessing fails consistently with 'signal 12'
	on FreeBSD 6.2 buildbot.
In-Reply-To: <1257523034.1.0.340985846807.issue7272@psf.upfronthosting.co.za>
Message-ID: <1258733933.34.0.691106636429.issue7272@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7272>
_______________________________________

From report at bugs.python.org  Fri Nov 20 17:22:45 2009
From: report at bugs.python.org (Josh Kupershmidt)
Date: Fri, 20 Nov 2009 16:22:45 +0000
Subject: [issue7370] patch: BaseHTTPServer reinventing rfc822
In-Reply-To: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>
Message-ID: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>


New submission from Josh Kupershmidt <schmiddy at gmail.com>:

While digging through Lib/BaseHTTPServer.py, I noticed that the
date_time_string() function duplicates rfc822.formatdate(). Attached is
a patch to eliminate this duplication of code.

----------
components: Library (Lib)
files: BaseHTTPServer.patch
keywords: patch
messages: 95554
nosy: schmiddy
severity: normal
status: open
title: patch: BaseHTTPServer reinventing rfc822
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file15369/BaseHTTPServer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7370>
_______________________________________

From report at bugs.python.org  Fri Nov 20 17:58:28 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 20 Nov 2009 16:58:28 +0000
Subject: [issue7272] test_multiprocessing fails consistently with 'signal 12'
	on FreeBSD 6.2 buildbot.
In-Reply-To: <1257523034.1.0.340985846807.issue7272@psf.upfronthosting.co.za>
Message-ID: <1258736308.61.0.163801998035.issue7272@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Looks good so far to me - I'll apply and run the tests locally (but I 
don't have a fbsd box, so I'm just checking for regressions). One question 
- what's with all the 

-rm -f -r conftest*
+rm -f conftest*

Lines in there?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7272>
_______________________________________

From report at bugs.python.org  Fri Nov 20 18:05:18 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 20 Nov 2009 17:05:18 +0000
Subject: [issue7272] test_multiprocessing fails consistently with 'signal 12'
	on FreeBSD 6.2 buildbot.
In-Reply-To: <1257523034.1.0.340985846807.issue7272@psf.upfronthosting.co.za>
Message-ID: <1258736718.08.0.0727054095757.issue7272@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

About the rm -f -r conftest stuff:

My guess is that the last person to update configure used Apple's 
version of autoconf:  Apple seems to have silently 'fixed' autoconf 
version 2.61 to remove some (fairly benign) warnings that appear when 
running the configure script.  Which is fine, but it would be nice if 
the version string for their autoconf gave some indication that it had 
been fixed.

In any case, rm -f is what comes from standard autoconf 2.61, so I think 
that's what should be there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7272>
_______________________________________

From report at bugs.python.org  Fri Nov 20 18:08:42 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 20 Nov 2009 17:08:42 +0000
Subject: [issue7272] test_multiprocessing fails consistently with 'signal 12'
	on FreeBSD 6.2 buildbot.
In-Reply-To: <1257523034.1.0.340985846807.issue7272@psf.upfronthosting.co.za>
Message-ID: <1258736922.4.0.231838033678.issue7272@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

One other thought:  if this is applied, would it make sense to ask the 
FreeBSD buildbot maintainer to then enable the POSIX semaphores for 
FreeBSD 7.2 (but probably not for 6.4)?  It looks like FreeBSD 8.0 is just 
around the corner, and the rumours are that it'll have these semaphores 
enabled by default;  it would be nice to know about any multiprocessing 
failures on FreeBSD, so that we can be reasonably sure it'll work on 8.0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7272>
_______________________________________

From report at bugs.python.org  Fri Nov 20 18:11:49 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 20 Nov 2009 17:11:49 +0000
Subject: [issue7272] test_multiprocessing fails consistently with 'signal 12'
	on FreeBSD 6.2 buildbot.
In-Reply-To: <1258736922.4.0.231838033678.issue7272@psf.upfronthosting.co.za>
Message-ID: <4222a8490911200911n6bc0bfa2o4e2d5631b86142e1@mail.gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

On Fri, Nov 20, 2009 at 12:08 PM, Mark Dickinson <report at bugs.python.org> wrote:
> One other thought: ?if this is applied, would it make sense to ask the
> FreeBSD buildbot maintainer to then enable the POSIX semaphores for
> FreeBSD 7.2 (but probably not for 6.4)? ?It looks like FreeBSD 8.0 is just
> around the corner, and the rumours are that it'll have these semaphores
> enabled by default; ?it would be nice to know about any multiprocessing
> failures on FreeBSD, so that we can be reasonably sure it'll work on 8.0.

Agreed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7272>
_______________________________________

From report at bugs.python.org  Fri Nov 20 18:49:41 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 20 Nov 2009 17:49:41 +0000
Subject: [issue7272] test_multiprocessing fails consistently with 'signal 12'
	on FreeBSD 6.2 buildbot.
In-Reply-To: <1257523034.1.0.340985846807.issue7272@psf.upfronthosting.co.za>
Message-ID: <1258739381.79.0.272503259203.issue7272@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Mark, the patch looks ok on os/x and fedora core 12. Nothing jumps out at 
me as incorrect. I'm for committing and watching the BSD buildbot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7272>
_______________________________________

From report at bugs.python.org  Fri Nov 20 19:02:15 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 20 Nov 2009 18:02:15 +0000
Subject: [issue7369] Fibonacci example does not include 0; section 4.6
In-Reply-To: <1258725032.09.0.34838264618.issue7369@psf.upfronthosting.co.za>
Message-ID: <1258740135.96.0.740362434026.issue7369@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7369>
_______________________________________

From report at bugs.python.org  Fri Nov 20 20:22:42 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Nov 2009 19:22:42 +0000
Subject: [issue7361] Strange importlib error during test_multiprocessing
	failure
In-Reply-To: <1258658288.16.0.0772350847135.issue7361@psf.upfronthosting.co.za>
Message-ID: <1258744962.03.0.226697896914.issue7361@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Huh. I wonder how importlib is ending up being the implementation of 
import then? Guess I also need to double-check everything is still 
cleaning itself up properly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7361>
_______________________________________

From report at bugs.python.org  Fri Nov 20 20:42:29 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 20 Nov 2009 19:42:29 +0000
Subject: [issue7272] test_multiprocessing fails consistently with 'signal 12'
	on FreeBSD 6.2 buildbot.
In-Reply-To: <1257523034.1.0.340985846807.issue7272@psf.upfronthosting.co.za>
Message-ID: <1258746149.0.0.337617160043.issue7272@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Jesse.  Applied in r76432 (trunk).  Unfortunately the buildbots 
are all purple right now;  once they're building again, and the FreeBSD 
buildbots have gone green (/me crosses fingers) I'll merge to py3k.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7272>
_______________________________________

From report at bugs.python.org  Fri Nov 20 21:38:20 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Nov 2009 20:38:20 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1258749500.35.0.732100046832.issue1859@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree that if newlines in the text are left in, they should reset the
characters in line count to 0 the same as inserted newlines.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Fri Nov 20 22:07:48 2009
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 20 Nov 2009 21:07:48 +0000
Subject: [issue7347] Add {Create|Delete}KeyEx to _winreg, doc and test updates
In-Reply-To: <1258566495.76.0.636986979508.issue7347@psf.upfronthosting.co.za>
Message-ID: <1258751268.76.0.782826259827.issue7347@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

After looking at this more, I poked around and found a whole lot of
things either missing or broken with _winreg.

Changes:
- documentation missing for *ReflectionKey, and updated a few
incorrectly documented exceptions in the docstrings
- QueryReflectionKey always returned False if the underlying API call
succeeded (used return code from call instead of bool param)
- addition of RegCreateKeyEx and RegDeleteKeyEx for 64-bit support
- changed the test suite to cover much more of the _winreg API. There
are now classes for local, remote, and 64-bit specific tests, with some
tests in the 64-bit class which are specific to whether Python was
compiled for 32 or 64-bit due to the differences in how _winreg acts.


So far everything passes on XP 32-bit, Server 2003 32-bit, and Server
2003 64-bit with a 32-bit Python. On Server 2003 64-bit with a 64-bit
Python, I get one failure on test_create_open_delete_for_32bit about
DeleteKeyEx -- not sure what the deal is, but I'm looking into it.

There is an added file, delete_regkey.vbs, because 32-bit applications
can create keys in the 64-bit space, but apparently they cannot be
deleted with DeleteKey -- they'd need DeleteKeyEx but that's 64-bit
only. It's used as a cleanup to make sure the key gets deleted in one case.

----------
title: Patch - add RegCreateKeyEx to _winreg -> Add {Create|Delete}KeyEx to _winreg, doc and test updates
Added file: http://bugs.python.org/file15370/winreg_add_createkeyex_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7347>
_______________________________________

From report at bugs.python.org  Fri Nov 20 22:20:32 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Nov 2009 21:20:32 +0000
Subject: [issue7329] global statements outside functions/methods should raise
	SyntaxError
In-Reply-To: <1258297827.42.0.98275960381.issue7329@psf.upfronthosting.co.za>
Message-ID: <1258752032.7.0.0556980526107.issue7329@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I once proposed this change, but became less supportive as I can to
appreciate have fewer rather than more special-case rules. With
Gabriel's explanation, I now oppose the idea and think this should be
closed.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7329>
_______________________________________

From report at bugs.python.org  Fri Nov 20 22:24:08 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 20 Nov 2009 21:24:08 +0000
Subject: [issue7371] Windows 64-bit build "skips" several projects in VS 2008
In-Reply-To: <1258752248.05.0.167808334648.issue7371@psf.upfronthosting.co.za>
Message-ID: <1258752248.05.0.167808334648.issue7371@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

1. Install Windows 64-bit (SP2)
2. Install Visual Studio 2008 Professional w/ 64-bit components
3. Download Python-2.6.4.tgz
4. Open PCbuild/pcbuild.sln
5. Select "Release" and "x64" in the configuration toolbar

One would notice that only the projects "make_buildinfo" and 
"make_versioninfo" are built (which too as Win32, not x64 - for unknown 
reason). All projects are *skipped*. I don't know why. 

64-bit build would work on a 32-bit Windows machine (cross-
compilation), but not a native 64-bit Windows machine?

Attached is the Visual Studio build log.

----------
components: Build, Windows
files: py264-xp64bit-vs2008-buildlog.txt
messages: 95565
nosy: srid
severity: normal
status: open
title: Windows 64-bit build "skips" several projects in VS 2008
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15371/py264-xp64bit-vs2008-buildlog.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7371>
_______________________________________

From report at bugs.python.org  Fri Nov 20 22:25:30 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 20 Nov 2009 21:25:30 +0000
Subject: [issue7371] Windows 64-bit build "skips" several projects in VS 2008
In-Reply-To: <1258752248.05.0.167808334648.issue7371@psf.upfronthosting.co.za>
Message-ID: <1258752330.13.0.853723756932.issue7371@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

> All projects are *skipped*.

I meant: All other projects are *skipped*.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7371>
_______________________________________

From report at bugs.python.org  Fri Nov 20 22:25:51 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Nov 2009 21:25:51 +0000
Subject: [issue7335] int/long discrepancy when formatting zero with "%.0d"
In-Reply-To: <1258396121.34.0.904400229223.issue7335@psf.upfronthosting.co.za>
Message-ID: <1258752351.4.0.114992794705.issue7335@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree with the 'should' (behave same way), but changing nothing will
break no code. Given that the purpose of 2.7 is to aid 3.x migration, an
argument could be made for matching the 3.x behavior.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7335>
_______________________________________

From report at bugs.python.org  Fri Nov 20 22:45:09 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Nov 2009 21:45:09 +0000
Subject: [issue7348] StringIO.StringIO.readline(-1) returns the wrong result
	compared to other file-like objects
In-Reply-To: <1258570716.97.0.757460234956.issue7348@psf.upfronthosting.co.za>
Message-ID: <1258753509.61.0.400648802801.issue7348@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

You specified neither version nor system.
On 3.1, Windows
>>> from io import StringIO as s
>>> s('a\nb\nfoo').readline(-1)

'a\n'

which, I gather, is what you describe as expected, although using -1 to
mean None is rather weird. 

The 3.1 doc says only 
"readline(limit=-1) 
Read and return one line from the stream. If limit is specified, at most
limit bytes will be read."
which would imply that negative numbers are the same as 0.

So even in 3.1, either the behavior is wrong or the doc is incomplete.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7348>
_______________________________________

From report at bugs.python.org  Fri Nov 20 22:46:02 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 20 Nov 2009 21:46:02 +0000
Subject: [issue7367] pkgutil.walk_packages fails on write-only directory in
	sys.path
In-Reply-To: <1258702285.22.0.207199237354.issue7367@psf.upfronthosting.co.za>
Message-ID: <1258753562.03.0.927923190909.issue7367@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

>I initially came across the error when attempting to get a modules list
>and was returned a list of errors. One of them was the [errno 13].

OK, now that makes more sense!

The problem is that somehow you had a write-only directory ("~/Public/Drop 
Box") on your python module search path.  If you type the following commands 
in IDLE or in the interpreter:

import sys
sys.path

you will likely see the "Drop Box" directory in the list of paths (assuming 
things haven't changed).

When you run the "modules" help command, the python help module, pydoc, uses 
the pkgutil module to search the entire list of directories in sys.path and 
attempts to import each package it finds in each directory to print the 
module's help information (btw, there are no separate help files).

While the pkgutil.walk_packages function tries to handle most errors, it 
isn't prepared to handle the case of a write-only directory on sys.path and 
that's the root cause of the error of the error you saw.  The following test 
case demonstrates the problem:

import os, pkgutil, sys

dirname_wo = os.tempnam()
os.mkdir(dirname_wo, 0222)  # write permission only
try:
    sys.path.insert(0, dirname_wo)
    def onerror(pkgname):
        print('onerror called for package %s' % pkgname)
    for importer, modname, ispkg in pkgutil.walk_packages(onerror=onerror):
        print modname
finally:
    os.rmdir(dirname_wo)

The long-term solution is to have pkgutil.walk_packages protect itself 
against os.listdir errors.  A patch is needed for that.

In your case, though, you should check for and remove whatever is adding 
"Drop Box" to your Python sys.path.  Perhaps you have an out-of-date export 
of PYTHONPATH in a shell profile (.bash_profile, etc)?  Or something left 
over in a site-packages pth file (perhaps by trying to install a package 
from the "Drop Box" directory)?  By changing the permissions as you did, you 
worked around the problem but that's not the right solution and you could be 
compromising the security of your drop box file.

----------
components: +Library (Lib) -IDLE
title: IDLE OSError [errno 13] permission denied accessing help files -> pkgutil.walk_packages fails on write-only directory in sys.path
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7367>
_______________________________________

From report at bugs.python.org  Fri Nov 20 22:47:13 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 20 Nov 2009 21:47:13 +0000
Subject: [issue7348] StringIO.StringIO.readline(-1) returns the wrong result
	compared to other file-like objects
In-Reply-To: <1258570716.97.0.757460234956.issue7348@psf.upfronthosting.co.za>
Message-ID: <1258753633.41.0.560701323112.issue7348@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Python 2.6, Linux.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7348>
_______________________________________

From report at bugs.python.org  Fri Nov 20 22:52:31 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Nov 2009 21:52:31 +0000
Subject: [issue7350] csv doesn't handle escaped characters properly
In-Reply-To: <1258571515.92.0.182844984253.issue7350@psf.upfronthosting.co.za>
Message-ID: <1258753951.72.0.351020022049.issue7350@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7350>
_______________________________________

From report at bugs.python.org  Fri Nov 20 22:54:05 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 20 Nov 2009 21:54:05 +0000
Subject: [issue7367] pkgutil.walk_packages fails on write-only directory in
	sys.path
In-Reply-To: <1258702285.22.0.207199237354.issue7367@psf.upfronthosting.co.za>
Message-ID: <1258754045.03.0.577200005333.issue7367@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

More precisely: you should check for and remove whatever is adding 
"Drop Box" or a directory within it to your Python sys.path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7367>
_______________________________________

From report at bugs.python.org  Fri Nov 20 23:02:02 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Nov 2009 22:02:02 +0000
Subject: [issue7369] Fibonacci example does not include 0; section 4.6
In-Reply-To: <1258725032.09.0.34838264618.issue7369@psf.upfronthosting.co.za>
Message-ID: <1258754522.03.0.214977004832.issue7369@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The delta (patch) is to change 'b' to 'a' in the while and print
statements and prepend '0 ' to the output line.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7369>
_______________________________________

From report at bugs.python.org  Sat Nov 21 01:15:47 2009
From: report at bugs.python.org (David Bolen)
Date: Sat, 21 Nov 2009 00:15:47 +0000
Subject: [issue7272] test_multiprocessing fails consistently with 'signal 12'
	on FreeBSD 6.2 buildbot.
In-Reply-To: <1257523034.1.0.340985846807.issue7272@psf.upfronthosting.co.za>
Message-ID: <1258762547.01.0.871116713601.issue7272@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

Looks like some sort of master side global rebuild was initiated but
without the proper SVN information.  But I see a rebuild on 7.2 with
this patch revision that looks like it worked (still failed, but with a
different reason)

I'm not that familiar with the test harness, but would it be possible to
get test_multiprocessing to log an error when it has to be skipped (like
other tests that fail to find supporting modules and what not), so as to
highlight it in the log?  It might even warn about what to do to fix the
behavior for someone running the tests.

In any event though, I'm fine with enabling the support on the 7.2
buildbot (I'll stick it in loader.conf so I don't have to remember after
a reboot) if we're past any point of wanting to check how the test
behaves without them.  Or I guess the 6.4 buildbot can continue to serve
that purpose, right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7272>
_______________________________________

From report at bugs.python.org  Sat Nov 21 02:03:12 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 21 Nov 2009 01:03:12 +0000
Subject: [issue7372] Regression in pstats
In-Reply-To: <1258765391.77.0.857956675588.issue7372@psf.upfronthosting.co.za>
Message-ID: <1258765391.77.0.857956675588.issue7372@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Attached zip archive can be run directly to reproduce the bug:

$ ./python.exe bug.zip 
Traceback (most recent call last):
  File "/Users/sasha/Work/python-svn/trunk/Lib/runpy.py", line 162, in 
_run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/Users/sasha/Work/python-svn/trunk/Lib/runpy.py", line 72, in 
_run_code
    exec code in run_globals
  File "bug.zip/__main__.py", line 9, in <module>
  File "/Users/sasha/Work/python-svn/trunk/Lib/pstats.py", line 268, in 
strip_dirs
    (cc, nc, tt, ct, newcallers))
  File "/Users/sasha/Work/python-svn/trunk/Lib/pstats.py", line 516, in 
add_func_stats
    add_callers(t_callers, callers))
  File "/Users/sasha/Work/python-svn/trunk/Lib/pstats.py", line 526, in 
add_callers
    zip(caller, new_callers[func])])
TypeError: zip argument #1 must support iteration


This is a regression introduced by r60149 which fixed processing of 
cProfile data, but broke processing of profile.

It is fairly easy to fix this problem in pstats, but a better solution 
may be to make profile output compatible with cProfile.

See also issue1269 and issue1315 .

----------
components: Library (Lib)
files: bug.zip
messages: 95574
nosy: belopolsky, georg.brandl, matthew.fremont, stromnov, therve
severity: normal
status: open
title: Regression in pstats
type: crash
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15372/bug.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7372>
_______________________________________

From report at bugs.python.org  Sat Nov 21 03:20:44 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 21 Nov 2009 02:20:44 +0000
Subject: [issue7372] Regression in pstats
In-Reply-To: <1258765391.77.0.857956675588.issue7372@psf.upfronthosting.co.za>
Message-ID: <1258770044.67.0.398339111583.issue7372@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching a simple fix.  The test for data format could be taken out 
of the loop, but it is probably not worth complicating the logic.  In any 
case the real issue is whether profile and cProfile should produce 
compatible output or not.

----------
keywords: +patch
Added file: http://bugs.python.org/file15373/issue7372.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7372>
_______________________________________

From report at bugs.python.org  Sat Nov 21 06:39:09 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 21 Nov 2009 05:39:09 +0000
Subject: [issue5683] Speed up cPickle's pickling generally
In-Reply-To: <1238803338.21.0.932870288543.issue5683@psf.upfronthosting.co.za>
Message-ID: <1258781949.04.0.605852040714.issue5683@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Last august, I worked on integrating Collin's optimization work into
py3k in a local Mercurial branch. So, I can champion these changes into
py3k, if Collin is unavailable.

And if Collin allows me, I would like to merge the other pickle
optimizations currently in Unladen Swallow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5683>
_______________________________________

From report at bugs.python.org  Sat Nov 21 06:53:04 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 21 Nov 2009 05:53:04 +0000
Subject: [issue7128] cPickle looking for non-existent package copyreg
In-Reply-To: <1255536754.55.0.971036296539.issue7128@psf.upfronthosting.co.za>
Message-ID: <1258782784.47.0.544452776647.issue7128@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

But, that change was undone already, no? In fact, it is you, Georg, that
reverted my mess in r63493. ;-)

----------
nosy: +alexandre.vassalotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7128>
_______________________________________

From report at bugs.python.org  Sat Nov 21 13:03:25 2009
From: report at bugs.python.org (Ask Solem)
Date: Sat, 21 Nov 2009 12:03:25 +0000
Subject: [issue7285] multiprocessing module, example code error
In-Reply-To: <1257647520.68.0.169575152715.issue7285@psf.upfronthosting.co.za>
Message-ID: <1258805005.94.0.182312312129.issue7285@psf.upfronthosting.co.za>


Changes by Ask Solem <askh at opera.com>:


Added file: http://bugs.python.org/file15374/7285.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7285>
_______________________________________

From report at bugs.python.org  Sat Nov 21 14:25:37 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 21 Nov 2009 13:25:37 +0000
Subject: [issue7128] cPickle looking for non-existent package copyreg
In-Reply-To: <1255536754.55.0.971036296539.issue7128@psf.upfronthosting.co.za>
Message-ID: <1258809937.27.0.177459114457.issue7128@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Now I'm confused. So the only thing left to do is the patch attached here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7128>
_______________________________________

From report at bugs.python.org  Sat Nov 21 14:41:50 2009
From: report at bugs.python.org (Ask Solem)
Date: Sat, 21 Nov 2009 13:41:50 +0000
Subject: [issue5738] multiprocessing example wrong
In-Reply-To: <1239483237.04.0.0741779763922.issue5738@psf.upfronthosting.co.za>
Message-ID: <1258810910.16.0.866504044203.issue5738@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

Are we sure this fits the scope of multiprocessing? It's a nice feature, 
but such a long and complex example in the documentation is wrong IMHO, if 
this is something people need it should be implemented as a reusable 
solution, not as an example people copy and paste.

----------
nosy: +asksol

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5738>
_______________________________________

From report at bugs.python.org  Sat Nov 21 14:51:18 2009
From: report at bugs.python.org (Ask Solem)
Date: Sat, 21 Nov 2009 13:51:18 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
Message-ID: <1258811478.06.0.383014130809.issue6615@psf.upfronthosting.co.za>


Changes by Ask Solem <askh at opera.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file15375/6615.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Sat Nov 21 14:52:52 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 21 Nov 2009 13:52:52 +0000
Subject: [issue5738] multiprocessing example wrong
In-Reply-To: <1258810910.16.0.866504044203.issue5738@psf.upfronthosting.co.za>
Message-ID: <4222a8490911210552l76b6556ne7a91f299d356c64@mail.gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

On Sat, Nov 21, 2009 at 8:41 AM, Ask Solem <report at bugs.python.org> wrote:
>
> Ask Solem <askh at opera.com> added the comment:
>
> Are we sure this fits the scope of multiprocessing? It's a nice feature,
> but such a long and complex example in the documentation is wrong IMHO, if
> this is something people need it should be implemented as a reusable
> solution, not as an example people copy and paste.

In hindsight; I agree - this belongs in an "addons" module someplace
outside the standard library. I'll remove it today - the one thing we
are short on though is manager examples.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5738>
_______________________________________

From report at bugs.python.org  Sat Nov 21 15:00:08 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 21 Nov 2009 14:00:08 +0000
Subject: [issue7272] test_multiprocessing fails consistently with 'signal 12'
	on FreeBSD 6.2 buildbot.
In-Reply-To: <1257523034.1.0.340985846807.issue7272@psf.upfronthosting.co.za>
Message-ID: <1258812008.12.0.811679934111.issue7272@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I'm not that familiar with the test harness, but would it be possible to
> get test_multiprocessing to log an error when it has to be skipped.

Well, there should be a skip message next to the test_multiprocessing line 
in the results.  I'm not sure whether that's the sort of thing you mean.

Unfortunately it looks like both runs (6.4 and 7.2) were prematurely 
terminated by test_curses before they even got as far as 
test_multiprocessing.  I might try running them again and hope for a 
different random test ordering.

I'm also seeing warnings about HAVE_BROKEN_POSIX_SEMAPHORES being 
redefined, in Python/thread_pthread.h;  I'll take another look at this 
next week (no access to the FreeBSD machine at the moment).

----------
assignee:  -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7272>
_______________________________________

From report at bugs.python.org  Sat Nov 21 15:01:39 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 21 Nov 2009 14:01:39 +0000
Subject: [issue7272] test_multiprocessing fails consistently with 'signal 12'
	on FreeBSD 6.2 buildbot.
In-Reply-To: <1257523034.1.0.340985846807.issue7272@psf.upfronthosting.co.za>
Message-ID: <1258812099.02.0.276424681633.issue7272@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> In any event though, I'm fine with enabling the support on the 7.2
> buildbot (I'll stick it in loader.conf so I don't have to remember 
after
a reboot)

That would be great---thank you!

> if we're past any point of wanting to check how the test
> behaves without them.

I'm not sure we are, just yet.  But soon... :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7272>
_______________________________________

From report at bugs.python.org  Sat Nov 21 15:30:54 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 21 Nov 2009 14:30:54 +0000
Subject: [issue5738] multiprocessing example wrong
In-Reply-To: <1239483237.04.0.0741779763922.issue5738@psf.upfronthosting.co.za>
Message-ID: <1258813854.55.0.57636445986.issue5738@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I've removed the example on all active branches. r76433 is the changelist

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5738>
_______________________________________

From report at bugs.python.org  Sat Nov 21 15:38:58 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 21 Nov 2009 14:38:58 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
Message-ID: <1258814338.36.0.824064789354.issue6615@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

patch committed to trunk in r76438

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Sat Nov 21 16:32:41 2009
From: report at bugs.python.org (Ask Solem)
Date: Sat, 21 Nov 2009 15:32:41 +0000
Subject: [issue6064] Add "daemon" argument to threading.Thread constructor
In-Reply-To: <1242760441.53.0.863717257975.issue6064@psf.upfronthosting.co.za>
Message-ID: <1258817561.47.0.438853070211.issue6064@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

Patch for multiprocessing, adding the daemon kwarg attached.

----------
nosy: +asksol
Added file: http://bugs.python.org/file15376/6064-multiprocessing-daemon-kwarg.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6064>
_______________________________________

From report at bugs.python.org  Sat Nov 21 17:06:02 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 21 Nov 2009 16:06:02 +0000
Subject: [issue7372] Regression in pstats
In-Reply-To: <1258765391.77.0.857956675588.issue7372@psf.upfronthosting.co.za>
Message-ID: <1258819562.02.0.305530935439.issue7372@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7372>
_______________________________________

From report at bugs.python.org  Sat Nov 21 18:04:08 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 21 Nov 2009 17:04:08 +0000
Subject: [issue7353] cporting docs recommend using Include/intobject.h,
	which was removed in 3.1?
In-Reply-To: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za>
Message-ID: <1258823048.48.0.400972139976.issue7353@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I don't think it would hurt to put it back, would it?  I think the "remove 
this in 3.1" note was made when we expected 3.1 to be happening 1.5 years 
after 3.0 rather than a few months.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7353>
_______________________________________

From report at bugs.python.org  Sat Nov 21 19:02:55 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 21 Nov 2009 18:02:55 +0000
Subject: [issue7128] cPickle looking for non-existent package copyreg
In-Reply-To: <1255536754.55.0.971036296539.issue7128@psf.upfronthosting.co.za>
Message-ID: <1258826575.43.0.390898898633.issue7128@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Yes. But, I would remove the ugly copy_reg_str variable from cPickle as
the patch.

----------
Added file: http://bugs.python.org/file15377/remove_copyreg_str.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7128>
_______________________________________

From report at bugs.python.org  Sat Nov 21 19:10:27 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 21 Nov 2009 18:10:27 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
Message-ID: <1258827027.19.0.404204569311.issue6615@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

merged to py3k in r76439

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Sat Nov 21 20:38:44 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 21 Nov 2009 19:38:44 +0000
Subject: [issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2
In-Reply-To: <1256030477.33.0.0599886113888.issue7173@psf.upfronthosting.co.za>
Message-ID: <1258832324.09.0.489397912794.issue7173@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7173>
_______________________________________

From report at bugs.python.org  Sun Nov 22 00:56:46 2009
From: report at bugs.python.org (Jon Parise)
Date: Sat, 21 Nov 2009 23:56:46 +0000
Subject: [issue7373] Use PyModule_AddIntMacro() in Modules/gcmodule.c
In-Reply-To: <1258847806.44.0.30023872526.issue7373@psf.upfronthosting.co.za>
Message-ID: <1258847806.44.0.30023872526.issue7373@psf.upfronthosting.co.za>


New submission from Jon Parise <jon at indelible.org>:

The attached patch uses PyModule_AddIntMacro() to register the gc
module's constants instead of using a local ADD_INT() macro.

----------
components: Interpreter Core
files: gc_macros-trunk.patch
keywords: patch
messages: 95589
nosy: jon
severity: normal
status: open
title: Use PyModule_AddIntMacro() in Modules/gcmodule.c
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15378/gc_macros-trunk.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7373>
_______________________________________

From report at bugs.python.org  Sun Nov 22 00:57:13 2009
From: report at bugs.python.org (Jon Parise)
Date: Sat, 21 Nov 2009 23:57:13 +0000
Subject: [issue7373] Use PyModule_AddIntMacro() in Modules/gcmodule.c
In-Reply-To: <1258847806.44.0.30023872526.issue7373@psf.upfronthosting.co.za>
Message-ID: <1258847833.79.0.404208205241.issue7373@psf.upfronthosting.co.za>


Changes by Jon Parise <jon at indelible.org>:


Added file: http://bugs.python.org/file15379/gc_macros-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7373>
_______________________________________

From report at bugs.python.org  Sun Nov 22 00:58:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Nov 2009 23:58:43 +0000
Subject: [issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2
In-Reply-To: <1256030477.33.0.0599886113888.issue7173@psf.upfronthosting.co.za>
Message-ID: <1258847923.19.0.283471119557.issue7173@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Have you tried using 3.1.0 and even 3.0?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7173>
_______________________________________

From report at bugs.python.org  Sun Nov 22 01:02:04 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 22 Nov 2009 00:02:04 +0000
Subject: [issue7373] Use PyModule_AddIntMacro() in Modules/gcmodule.c
In-Reply-To: <1258847806.44.0.30023872526.issue7373@psf.upfronthosting.co.za>
Message-ID: <1258848124.23.0.849481617116.issue7373@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

You don't account for PyModule_AddIntMacro failing.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7373>
_______________________________________

From report at bugs.python.org  Sun Nov 22 02:18:58 2009
From: report at bugs.python.org (Jon Parise)
Date: Sun, 22 Nov 2009 01:18:58 +0000
Subject: [issue7373] Use PyModule_AddIntMacro() in Modules/gcmodule.c
In-Reply-To: <1258847806.44.0.30023872526.issue7373@psf.upfronthosting.co.za>
Message-ID: <1258852738.82.0.153500342364.issue7373@psf.upfronthosting.co.za>


Jon Parise <jon at indelible.org> added the comment:

That's true.  I thought it worked the same as the ADD_INT() macro I
replaced, but I see that I was wrong.

Given that, perhaps the original code is best.  I don't see a lot of
value in replacing PyModule_AddIntConstant() with PyModule_AddIntMacro()
within ADD_INT().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7373>
_______________________________________

From report at bugs.python.org  Sun Nov 22 02:28:28 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 22 Nov 2009 01:28:28 +0000
Subject: [issue7329] global statements outside functions/methods should raise
	SyntaxError
In-Reply-To: <1258297827.42.0.98275960381.issue7329@psf.upfronthosting.co.za>
Message-ID: <1258853308.97.0.338266734864.issue7329@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I concur.

----------
nosy: +rhettinger
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7329>
_______________________________________

From report at bugs.python.org  Sun Nov 22 05:35:31 2009
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 22 Nov 2009 04:35:31 +0000
Subject: [issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2
In-Reply-To: <1256030477.33.0.0599886113888.issue7173@psf.upfronthosting.co.za>
Message-ID: <1258864531.05.0.0931947912766.issue7173@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

I hadn't, but it looks like the 2to3-ed Cython also runs on 3.0 now, so
I tested that, but I failed to get the procedure below to crash for me.
And that's both in 3.0 *and* 3.1.1! :-/

But I can still provoke the crash in 3.0, 3.0.1, 3.1.1 and the latest
3.2 when running the test suite normally, so it's still there, and it's
been there for a while.

At least a debug build of the latest py3k SVN rev. 76441 (3.2a0) seems
to crash reliably for the latest Cython (cython-devel, rev.
76a814a1fc57) with the attached crash patch applied. Running the
following crashes after printing the "HERE1":

    python3.2 runtests.py --no-cpp --no-pyregr --no-doctest \
         --no-cpp --no-fork --no-refnanny -vv first_assignment

with the error:
"""
python3.2: Objects/unicodeobject.c:885: PyUnicodeUCS4_FromFormatV:
Assertion `obj' failed.
Aborted
"""
which occurs when it's trying to print() the dead exception. Again, no
Cython modules have been loaded up to this point, so this is still pure
Python code that crashes the interpreter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7173>
_______________________________________

From report at bugs.python.org  Sun Nov 22 09:14:59 2009
From: report at bugs.python.org (Michal Liddle)
Date: Sun, 22 Nov 2009 08:14:59 +0000
Subject: [issue7374] Property accessor/getter called twice
In-Reply-To: <1258877699.05.0.144558862329.issue7374@psf.upfronthosting.co.za>
Message-ID: <1258877699.05.0.144558862329.issue7374@psf.upfronthosting.co.za>


New submission from Michal Liddle <michael at liddle.net.nz>:

The following snippet demonstrates the problem:

-------------------------------------
class Test(object):
    def get(self):
        print "get"
    def set(self, v):
        print "set"
    test = property(get, set)

t = Test()
t.test
t.test = 3
-----------------------------------

"get" is printed twice (expected once?), "set" is printed only once (as
expected)

----------
messages: 95595
nosy: mliddle
severity: normal
status: open
title: Property accessor/getter called twice
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7374>
_______________________________________

From report at bugs.python.org  Sun Nov 22 09:41:32 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 22 Nov 2009 08:41:32 +0000
Subject: [issue7374] Property accessor/getter called twice
In-Reply-To: <1258877699.05.0.144558862329.issue7374@psf.upfronthosting.co.za>
Message-ID: <1258879292.75.0.378848879785.issue7374@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Tried your snippet with both py2.5 and py2.6.  It works as expected (one
get and one set).

----------
nosy: +rhettinger
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7374>
_______________________________________

From report at bugs.python.org  Sun Nov 22 13:59:37 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 22 Nov 2009 12:59:37 +0000
Subject: [issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2
In-Reply-To: <1256030477.33.0.0599886113888.issue7173@psf.upfronthosting.co.za>
Message-ID: <1258894777.24.0.981336082633.issue7173@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I don't reproduce the problem on Windows. But the class NodeTypeWriter is 
not even used at all; did I miss something? The test builds a python 
extension and runs it, successfully it seems.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7173>
_______________________________________

From report at bugs.python.org  Sun Nov 22 14:01:31 2009
From: report at bugs.python.org (Michal Liddle)
Date: Sun, 22 Nov 2009 13:01:31 +0000
Subject: [issue7374] Property accessor/getter called twice
In-Reply-To: <1258877699.05.0.144558862329.issue7374@psf.upfronthosting.co.za>
Message-ID: <1258894891.44.0.194139846487.issue7374@psf.upfronthosting.co.za>


Michal Liddle <michael at liddle.net.nz> added the comment:

Right you are. Looks like its actually an IPython specific behaviour
here (didn't think to check that in the first place, sorry).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7374>
_______________________________________

From report at bugs.python.org  Sun Nov 22 15:21:55 2009
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 22 Nov 2009 14:21:55 +0000
Subject: [issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2
In-Reply-To: <1256030477.33.0.0599886113888.issue7173@psf.upfronthosting.co.za>
Message-ID: <1258899715.83.0.0356247907062.issue7173@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

The patch is supposed to apply near the end of the class
TreeAssertVisitor at the end of the file Cython/TestUtils.py, not in the
class NodeTypeWriter.

And the test doesn't run (or even import) the extension, it just builds it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7173>
_______________________________________

From report at bugs.python.org  Sun Nov 22 16:30:21 2009
From: report at bugs.python.org (Greg Ward)
Date: Sun, 22 Nov 2009 15:30:21 +0000
Subject: [issue6454] Add "example" keyword argument to optparse constructor
In-Reply-To: <1247183660.32.0.307989578437.issue6454@psf.upfronthosting.co.za>
Message-ID: <1258903821.1.0.640045183845.issue6454@psf.upfronthosting.co.za>


Greg Ward <greg at gerg.ca> added the comment:

> but I feel there is a better and more general
> solution - just provide some minimal formatting for description: treat
> empty line as paragraph separator. Then I would be able to add example
> or anything else to the description formatting it as necessary

Agreed.  I have also been bitten by optparse munging paragraphs together
in the description, and it's annoying.  I *think* we could get away with
two simple rules:

  * blank lines separate paragraphs
  * indented lines don't get wrapped

Obviously no one wants to reinvent reStructuredText, but I think that
should do the trick.

If that works, I think the suggested 'examples' arg becomes unnecessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6454>
_______________________________________

From report at bugs.python.org  Sun Nov 22 16:33:59 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 22 Nov 2009 15:33:59 +0000
Subject: [issue5007] urllib2 HTTPS connection failure (BadStatusLine Exception)
In-Reply-To: <1232408710.01.0.641128080754.issue5007@psf.upfronthosting.co.za>
Message-ID: <1258904039.64.0.242374175705.issue5007@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

This bug is not reproducible in trunk, py3k and is not reproducible in
py26 releases too. I tried to hunt down if any changes in the code-line
from py2.5 to py2.6 had effect on the behavior mention (BadStatusLine) ,
but don't see any. 

I am closing this as works for me.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5007>
_______________________________________

From report at bugs.python.org  Sun Nov 22 16:40:33 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 22 Nov 2009 15:40:33 +0000
Subject: [issue7375] 2to3 - does not translate urllib2 to urllib.request
	correctly for function/method argument
In-Reply-To: <1258904433.77.0.0888742690092.issue7375@psf.upfronthosting.co.za>
Message-ID: <1258904433.77.0.0888742690092.issue7375@psf.upfronthosting.co.za>


New submission from Senthil Kumaran <orsenthil at gmail.com>:

2.x code:

import urllib2
opener = urllib2.build_opener(urllib2.HTTPHandler(debuglevel=1))

2to3 on this would result in:

import urllib.request, urllib.error, urllib.parse
opener = urllib.request.build_opener(urllib2.HTTPHandler(debuglevel=1))

which is wrong. It did not translate the urllib2 in argument.

----------
assignee: benjamin.peterson
messages: 95602
nosy: benjamin.peterson, orsenthil
priority: normal
severity: normal
status: open
title: 2to3 - does not translate urllib2 to urllib.request correctly for function/method argument
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7375>
_______________________________________

From report at bugs.python.org  Sun Nov 22 16:40:45 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 22 Nov 2009 15:40:45 +0000
Subject: [issue7375] 2to3 - does not translate urllib2 to urllib.request
	correctly for function/method argument
In-Reply-To: <1258904433.77.0.0888742690092.issue7375@psf.upfronthosting.co.za>
Message-ID: <1258904445.85.0.0917271523005.issue7375@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
components: +2to3 (2.x to 3.0 conversion tool)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7375>
_______________________________________

From report at bugs.python.org  Sun Nov 22 16:55:43 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 22 Nov 2009 15:55:43 +0000
Subject: [issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2
In-Reply-To: <1256030477.33.0.0599886113888.issue7173@psf.upfronthosting.co.za>
Message-ID: <1258905343.96.0.077439834793.issue7173@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Sorry, my mistake. Now the prints are there, but the test run without 
error:

Running tests against Cython 0.12.rc1
Python 3.2a0 (py3k, Nov 22 2009, 12:04:23) [MSC v.1500 32 bit (Intel)]
HERE1
(None, None, None)
HERE2
HERE1
(None, None, None)
HERE2
HERE1
(None, None, None)
HERE2
building 'first_assignment' extension
[...More output...]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7173>
_______________________________________

From report at bugs.python.org  Sun Nov 22 18:37:31 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 22 Nov 2009 17:37:31 +0000
Subject: [issue7369] Fibonacci example does not include 0; section 4.6
In-Reply-To: <1258725032.09.0.34838264618.issue7369@psf.upfronthosting.co.za>
Message-ID: <1258911451.07.0.802064881702.issue7369@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

tjreedy: The reporter's suggestion seems fine. Prepending a 0 does not
seem to be a good idea.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7369>
_______________________________________

From report at bugs.python.org  Sun Nov 22 18:57:13 2009
From: report at bugs.python.org (flox)
Date: Sun, 22 Nov 2009 17:57:13 +0000
Subject: [issue7376] FAIL: Doctest: __main__.DebugRunner
In-Reply-To: <1258912633.73.0.334320263097.issue7376@psf.upfronthosting.co.za>
Message-ID: <1258912633.73.0.334320263097.issue7376@psf.upfronthosting.co.za>


New submission from flox <laxyf at yahoo.fr>:

Running on Debian Lenny, with Python 3.1.
The Python 2.5 version is OK.

~ $ python3 --version
Python 3.1.1+
~ $ python3 -m doctest
F..............
======================================================================
FAIL: Doctest: __main__.DebugRunner
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.1/doctest.py", line 2096, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for __main__.DebugRunner
  File "/usr/lib/python3.1/doctest.py", line 1644, in DebugRunner

----------------------------------------------------------------------
File "/usr/lib/python3.1/doctest.py", line 1712, in __main__.DebugRunner
Failed example:
    runner.run(test)
Expected:
    Traceback (most recent call last):
    ...
    doctest.UnexpectedException: <DocTest foo from foo.py:0 (2 examples)>
Got:
    Traceback (most recent call last):
      File "/usr/lib/python3.1/doctest.py", line 1243, in __run
        compileflags, 1), test.globs)
      File "<doctest __main__.DebugRunner[15]>", line 1, in <module>
        runner.run(test)
      File "/usr/lib/python3.1/doctest.py", line 1736, in run
        r = DocTestRunner.run(self, test, compileflags, out, False)
      File "/usr/lib/python3.1/doctest.py", line 1375, in run
        return self.__run(test, compileflags, out)
      File "/usr/lib/python3.1/doctest.py", line 1296, in __run
        exception)
      File "/usr/lib/python3.1/doctest.py", line 1742, in
report_unexpected_exception
        raise UnexpectedException(test, example, exc_info)
    UnexpectedException: <DocTest foo from foo.py:0 (2 examples)>


----------------------------------------------------------------------
Ran 15 tests in 0.015s

FAILED (failures=1)
~ $

----------
components: Library (Lib), Tests
messages: 95605
nosy: flox
severity: normal
status: open
title: FAIL: Doctest: __main__.DebugRunner
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7376>
_______________________________________

From report at bugs.python.org  Sun Nov 22 19:09:56 2009
From: report at bugs.python.org (flox)
Date: Sun, 22 Nov 2009 18:09:56 +0000
Subject: [issue7377] Slight difference: math.floor returns an Integral
In-Reply-To: <1258913396.31.0.675484209097.issue7377@psf.upfronthosting.co.za>
Message-ID: <1258913396.31.0.675484209097.issue7377@psf.upfronthosting.co.za>


New submission from flox <laxyf at yahoo.fr>:

The last code snippet on section "25.2.3.2 How are Docstring Examples
Recognized?" does not output the expected result.
http://docs.python.org/dev/py3k/library/doctest.html#how-are-docstring-examples-recognized


Documentation example:

    >>> assert "Easy!"
          >>> import math
              >>> math.floor(1.9)
              1.0

Real life (Python 3.1):
    >>> math.floor(1.9)
    1

----------
assignee: georg.brandl
components: Documentation
messages: 95606
nosy: flox, georg.brandl
severity: normal
status: open
title: Slight difference: math.floor returns an Integral
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7377>
_______________________________________

From report at bugs.python.org  Sun Nov 22 20:10:33 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sun, 22 Nov 2009 19:10:33 +0000
Subject: [issue6123] tarfile: opening an empty tar file fails
In-Reply-To: <1243427347.79.0.845990376951.issue6123@psf.upfronthosting.co.za>
Message-ID: <1258917033.76.0.976813237812.issue6123@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

I have checked in a fix for this problem: trunk (r76443) and py3k (r76444).

Thank you very much for your report. Sorry that it took that long to get
it fixed.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6123>
_______________________________________

From report at bugs.python.org  Sun Nov 22 22:07:58 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 22 Nov 2009 21:07:58 +0000
Subject: [issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2
In-Reply-To: <1256030477.33.0.0599886113888.issue7173@psf.upfronthosting.co.za>
Message-ID: <1258924078.24.0.537868752132.issue7173@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I reproduce the crash on Linux. Some debug prints showed that the failing 
exception object is "tp_clear'ed", because it belongs to a reference 
cycle. Now if it is cleared it should not be reachable...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7173>
_______________________________________

From report at bugs.python.org  Sun Nov 22 23:49:25 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 22 Nov 2009 22:49:25 +0000
Subject: [issue7369] Fibonacci example does not include 0; section 4.6
In-Reply-To: <1258725032.09.0.34838264618.issue7369@psf.upfronthosting.co.za>
Message-ID: <1258930165.84.0.992000137275.issue7369@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Senthil: look again. The OP's suggestion *is* to prepend a 0 to the current
1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597
I just specified the delta between current and suggested, should someone
decide to make the change.

That said, def fib2(n), a little further on in 4.6, should get the same
edit as def fib(n) does.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7369>
_______________________________________

From report at bugs.python.org  Mon Nov 23 01:17:59 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 23 Nov 2009 00:17:59 +0000
Subject: [issue7375] 2to3 - does not translate urllib2 to urllib.request
	correctly for function/method argument
In-Reply-To: <1258904433.77.0.0888742690092.issue7375@psf.upfronthosting.co.za>
Message-ID: <1258935479.98.0.900391833286.issue7375@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r76447.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7375>
_______________________________________

From report at bugs.python.org  Mon Nov 23 01:18:14 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 23 Nov 2009 00:18:14 +0000
Subject: [issue7369] Fibonacci example does not include 0; section 4.6
In-Reply-To: <1258725032.09.0.34838264618.issue7369@psf.upfronthosting.co.za>
Message-ID: <1258935494.06.0.307379049644.issue7369@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Terry: Oh, sorry. Now I get what you meant by "Prepend O to output
line". That is, Output line from the fib, as part of the patch.  The
changes need to be done at 3 places. Section 3.2, twice in Section 4.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7369>
_______________________________________

From report at bugs.python.org  Mon Nov 23 03:34:02 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 23 Nov 2009 02:34:02 +0000
Subject: [issue7373] Use PyModule_AddIntMacro() in Modules/gcmodule.c
In-Reply-To: <1258847806.44.0.30023872526.issue7373@psf.upfronthosting.co.za>
Message-ID: <1258943642.93.0.77609876362.issue7373@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7373>
_______________________________________

From report at bugs.python.org  Mon Nov 23 03:47:00 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 23 Nov 2009 02:47:00 +0000
Subject: [issue1169193] Handle ungzipped man pages in rpm builds correctly
Message-ID: <1258944420.03.0.174952736128.issue1169193@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1169193>
_______________________________________

From report at bugs.python.org  Mon Nov 23 04:16:51 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 Nov 2009 03:16:51 +0000
Subject: [issue7377] Slight difference: math.floor returns an Integral
In-Reply-To: <1258913396.31.0.675484209097.issue7377@psf.upfronthosting.co.za>
Message-ID: <1258946211.89.0.842378024367.issue7377@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Fixed in r76448 and r76449.  Thanks for pointing this out.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7377>
_______________________________________

From report at bugs.python.org  Mon Nov 23 05:19:03 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 23 Nov 2009 04:19:03 +0000
Subject: [issue7376] FAIL: Doctest: __main__.DebugRunner
In-Reply-To: <1258912633.73.0.334320263097.issue7376@psf.upfronthosting.co.za>
Message-ID: <1258949943.56.0.857230465737.issue7376@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Apparently this was introduced with r51625 :

r51625 | guido.van.rossum | 2006-08-26 16:37:44 -0400 (Sat, 26 Aug 2006) 
| 4 lines

Inspired by SF patch #860326, make the exception formatting by
traceback.py be closer to the built-in formatting.
A few unittests had to be fixed, too.

------------------------------------------------------------------------


When doctest is imported as __main__, traceback does not prepend 
UnexpectedException with doctest. prefix.  Attached patch fixes the 
issue by explicitly reimporting doctest in the 'if __name__ == 
"__main__":' clause.

This is rather inelegant and a better solution would probably be to use 
python -m doctest for something other than self test.  For example, 
running doctest.testfile on command line arguments would be a reasonable  
use, but python -m doctest Lib/doctest.py may still have a problem.

----------
keywords: +patch
nosy: +belopolsky
Added file: http://bugs.python.org/file15380/issue7376.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7376>
_______________________________________

From report at bugs.python.org  Mon Nov 23 05:41:34 2009
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 23 Nov 2009 04:41:34 +0000
Subject: [issue444582] Finding programs in PATH, addition to os
Message-ID: <1258951294.57.0.0885568235152.issue444582@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Here is a patch against r76432 which implements a "which" generator
function in shutil that yields full file paths where the searched file
exists on the PATH. Includes doc change and a test. It is pretty similar
to what edemaine had suggested.

This could just as easily return a list, so if that would be more
preferable I'll change the patch.

----------
nosy: +brian.curtin
Added file: http://bugs.python.org/file15381/shutil_which.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue444582>
_______________________________________

From report at bugs.python.org  Mon Nov 23 09:37:09 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 23 Nov 2009 08:37:09 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>
Message-ID: <1258965429.09.0.933792121241.issue6071@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think the error is really in _hashlib, not in the array object. It
should not require 3.x style buffers, but continue to support 2.x
readbuffers. Attached is a patch that takes this route to fixing the bug.

As for the checks for bf_releasebuffer: I still think they are
necessary. If an object implements bf_releasebuffer, that means that the
object may change the buffer underneath, unless proper locking and
unlocking takes place. Indeed, the array's getreadbuf operation is not
thread-safe. It might be possible to remove them if it is clarified that
anybody calling getreadbuffer must not release the GIL while they hold
on to the buffer.

----------
Added file: http://bugs.python.org/file15382/hashlib.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6071>
_______________________________________

From report at bugs.python.org  Mon Nov 23 10:42:43 2009
From: report at bugs.python.org (Thomas Vander Stichele)
Date: Mon, 23 Nov 2009 09:42:43 +0000
Subject: [issue644744] bdist_rpm fails when installing man pages
Message-ID: <1258969363.62.0.901716130579.issue644744@psf.upfronthosting.co.za>


Thomas Vander Stichele <thomasvs at users.sourceforge.net> added the comment:

Attaching a reworked patch of the patch attached in
http://bugs.python.org/issue1169193

This worked for me on f-11, with python 2.6

----------
keywords: +patch
nosy: +thomasvs
Added file: http://bugs.python.org/file15383/distutils.bdist_rpm.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue644744>
_______________________________________

From report at bugs.python.org  Mon Nov 23 11:04:22 2009
From: report at bugs.python.org (Greg Hewgill)
Date: Mon, 23 Nov 2009 10:04:22 +0000
Subject: [issue7378] unexpected truncation of traceback
In-Reply-To: <1258970662.35.0.76558630095.issue7378@psf.upfronthosting.co.za>
Message-ID: <1258970662.35.0.76558630095.issue7378@psf.upfronthosting.co.za>


New submission from Greg Hewgill <greg at hewgill.com>:

Quite by accident, I came across a case where Python would quit
generating traceback text and skip printing the actual exception
information. Here is a sample program:

    exec(compile("spam()", ".", "exec"))

and the output in Python 3.1 ("spam" is undefined):

    $ python3.1 test.py
    Traceback (most recent call last):
      File "test.py", line 1, in <module>
        exec(compile("spam()", ".", "exec"))
      File ".", line 1, in <module>
    $

This was bewildering until I realised that the traceback generator was
unable to read from the filename passed to compile() (my original
example was using a name other than "." that wasn't intended to be a
file name, but just happened to also be a directory name). I didn't
really mind the lack of source text, but the lack of the actual
exception message was most disturbing.

This appears to be a failure mode common to both traceback.c and
traceback.py, through slightly different mechanisms. In traceback.c, if
the source filename refers to a directory, the C open() succeeds but an
error occurs when trying to read from the directory handle. In 
traceback.py, the Python open() call fails with an IOError exception, 
and the exception wasn't handled gracefully.

I have attached a patch that creates the following output instead:

    $ ./python.exe test.py
    Traceback (most recent call last):
      File "test.py", line 1, in <module>
        exec(compile("spam()", ".", "exec"))
      File ".", line 1, in <module>
        [Errno 21] Is a directory: '.'
    NameError: name 'spam' is not defined
    $
    
I have tested the patch against Python 3.1, but it applies cleanly to 
the trunk (for some reason I couldn't make the trunk build, but that's 
unrelated). This patch may need some finesse for a Win32 build; I don't
have the ability to test that at the moment.

----------
components: Interpreter Core, Library (Lib)
files: traceback.patch
keywords: patch
messages: 95617
nosy: ghewgill
severity: normal
status: open
title: unexpected truncation of traceback
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file15384/traceback.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7378>
_______________________________________

From report at bugs.python.org  Mon Nov 23 11:32:36 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 Nov 2009 10:32:36 +0000
Subject: [issue7376] FAIL: Doctest: __main__.DebugRunner
In-Reply-To: <1258912633.73.0.334320263097.issue7376@psf.upfronthosting.co.za>
Message-ID: <1258972356.07.0.127932254545.issue7376@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

python -m doctest does accept file arguments.  Running the self-test is
the default if no arguments are supplied.

python -m doctest Lib/doctest.py passes.

So perhaps we should just remove the default and instead issue an error
message about missing arguments.

----------
nosy: +r.david.murray
priority:  -> low
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7376>
_______________________________________

From report at bugs.python.org  Mon Nov 23 11:33:39 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 Nov 2009 10:33:39 +0000
Subject: [issue7376] "python -m doctest" results in FAIL: Doctest:
	__main__.DebugRunner
In-Reply-To: <1258912633.73.0.334320263097.issue7376@psf.upfronthosting.co.za>
Message-ID: <1258972419.02.0.38411637974.issue7376@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
title: FAIL: Doctest: __main__.DebugRunner -> "python -m doctest" results in FAIL: Doctest: __main__.DebugRunner

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7376>
_______________________________________

From report at bugs.python.org  Mon Nov 23 12:53:41 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 23 Nov 2009 11:53:41 +0000
Subject: [issue644744] bdist_rpm fails when installing man pages
Message-ID: <1258977221.46.0.286574948472.issue644744@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I'd rather see sed called from within Distutils. But I am not sure how
to handle it after install has been called.

Do you know if sed is *always* present on a fresh Fedora ?

(I am nosying Toshio as well)

----------
assignee:  -> tarek
nosy: +a.badger
type:  -> behavior
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue644744>
_______________________________________

From report at bugs.python.org  Mon Nov 23 12:55:07 2009
From: report at bugs.python.org (flox)
Date: Mon, 23 Nov 2009 11:55:07 +0000
Subject: [issue7379] Docstring for fractions.Fraction.limit_denominator fails
In-Reply-To: <1258977307.89.0.840946928578.issue7379@psf.upfronthosting.co.za>
Message-ID: <1258977307.89.0.840946928578.issue7379@psf.upfronthosting.co.za>


New submission from flox <laxyf at yahoo.fr>:

Yes, you can reduce the fraction 1234/5678.
Bad Luck :p

~ $  python3 -m doctest /usr/lib/python3.1/fractions.py
**********************************************************************
File "/usr/lib/python3.1/fractions.py", line 165, in
fractions.Fraction.limit_denominator
Failed example:
    Fraction(1234, 5678).limit_denominator(10000)
Expected:
    Fraction(1234, 5678)
Got:
    Fraction(617, 2839)
**********************************************************************
1 items had failures:
   1 of   3 in fractions.Fraction.limit_denominator
***Test Failed*** 1 failures.
~ $

----------
components: Library (Lib), Tests
messages: 95620
nosy: flox
severity: normal
status: open
title: Docstring for fractions.Fraction.limit_denominator fails
versions: Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7379>
_______________________________________

From report at bugs.python.org  Mon Nov 23 13:24:15 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 23 Nov 2009 12:24:15 +0000
Subject: [issue7353] cporting docs recommend using Include/intobject.h,
	which was removed in 3.1?
In-Reply-To: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za>
Message-ID: <1258979055.2.0.890470059833.issue7353@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

MvL made this comment in
http://www.mail-archive.com/python-dev at python.org/msg43844.html

I'm copying it here so it doesn't get lost and because I think he makes
a good point that many people would miss (at least I didn't think of it).
-----------------------------------------------

The macros (unfortunately) allowed
to make non-obvious mistakes. Now that they are gone, people need to
really think of what precisely they want to do.

For example, consider

if (PyInt_Check(o)){
  long val = PyInt_AsLong(o);
  // process
} else if (PyLong_Check(o)) {
  long long val = PyLong_AsLongLong(o);
  // check for overflow
  // process
}

With intobject.h, this code would continue to compile, but work
incorrectly, as the second case will never be executed. It would
be better to port this as

#if Py2.x
if (PyInt_Check(o)){
  long val = PyInt_AsLong(o);
  // process
} else
#endif
if (PyLong_Check(o)) {

i.e. eliminating the int case altogether. For another example,

long foo = PyInt_AsLong(Foo);

has a hidden error in 3.x, with intobject: PyLong_AsLong might
overflow, which the 2.x case doesn't.

So eliminating intobject.h likely helps avoiding subtle errors.

Regards,
Martin

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7353>
_______________________________________

From report at bugs.python.org  Mon Nov 23 13:33:53 2009
From: report at bugs.python.org (flox)
Date: Mon, 23 Nov 2009 12:33:53 +0000
Subject: [issue7380] uuid.UUID.bytes gives a bytearray() instead of bytes
In-Reply-To: <1258979633.13.0.798699674887.issue7380@psf.upfronthosting.co.za>
Message-ID: <1258979633.13.0.798699674887.issue7380@psf.upfronthosting.co.za>


New submission from flox <laxyf at yahoo.fr>:

I've tried some experiments with module uuid, and I meet some
inconsistencies between the documentation, the docstring and the real
behavior of the module.

An interactive session is worth a thousand words:

>>> import uuid
>>> uuid.UUID(bytes='\x12\x34\x56\x78'*4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.1/uuid.py", line 149, in __init__
    assert isinstance(bytes, bytes_), repr(bytes)
AssertionError: '\x124Vx\x124Vx\x124Vx\x124Vx'
>>> uuid.UUID(bytes_le='\x78\x56\x34\x12\x34\x12\x78\x56' +
...                    '\x12\x34\x56\x78\x12\x34\x56\x78')
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/usr/lib/python3.1/uuid.py", line 144, in __init__
    bytes_(reversed(bytes_le[6:8])) +
TypeError: 'str' object cannot be interpreted as an integer
>>> 

Ok, the lines above are just parts of the documentation which need
update. But what is more confusing is the last example of the documentation.
http://docs.python.org/dev/py3k/library/uuid.html

Here is the interactive session:

>>> x = uuid.UUID('{00010203-0405-0607-0809-0a0b0c0d0e0f}')
>>> x.bytes
bytearray(b'\x00\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f')
>>> x.bytes_le
b'\x03\x02\x01\x00\x05\x04\x07\x06\x08\t\n\x0b\x0c\r\x0e\x0f'
>>> 

Normally both attributes should get a "UUID as a 16-byte string",
according to the documentation. Only the endianness should do the
difference. I guess this one need a patch.


Finally, the docstring fails, too:

~ $ python3 -m doctest /usr/lib/python3.1/uuid.py
**********************************************************************
File "/usr/lib/python3.1/uuid.py", line 16, in uuid
Failed example:
    uuid.uuid1()
Expected:
    UUID('a8098c1a-f86e-11da-bd1a-00112444be1e')
Got:
    UUID('e4bc8a38-d829-11de-9eee-0024e8bc58f0')
**********************************************************************
File "/usr/lib/python3.1/uuid.py", line 24, in uuid
Failed example:
    uuid.uuid4()
Expected:
    UUID('16fd2706-8baf-433b-82eb-8c7fada847da')
Got:
    UUID('71588cf5-7a51-4d59-ad76-05fb6b932673')
**********************************************************************
File "/usr/lib/python3.1/uuid.py", line 39, in uuid
Failed example:
    x.bytes
Expected:
    b'\x00\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f'
Got:
    bytearray(b'\x00\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f')
**********************************************************************
File "/usr/lib/python3.1/uuid.py", line 43, in uuid
Failed example:
    uuid.UUID(bytes=x.bytes)
Exception raised:
    Traceback (most recent call last):
      File "/usr/lib/python3.1/doctest.py", line 1243, in __run
        compileflags, 1), test.globs)
      File "<doctest uuid[8]>", line 1, in <module>
        uuid.UUID(bytes=x.bytes)
      File "/usr/lib/python3.1/uuid.py", line 149, in __init__
        assert isinstance(bytes, bytes_), repr(bytes)
    AssertionError:
bytearray(b'\x00\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f')
**********************************************************************
1 items had failures:
   4 of   9 in uuid
***Test Failed*** 4 failures.
~ $

----------
components: Library (Lib)
messages: 95622
nosy: flox
severity: normal
status: open
title: uuid.UUID.bytes gives a bytearray() instead of bytes
versions: Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7380>
_______________________________________

From report at bugs.python.org  Mon Nov 23 13:47:18 2009
From: report at bugs.python.org (flox)
Date: Mon, 23 Nov 2009 12:47:18 +0000
Subject: [issue7380] uuid.UUID.bytes gives a bytearray() instead of bytes
In-Reply-To: <1258979633.13.0.798699674887.issue7380@psf.upfronthosting.co.za>
Message-ID: <1258980438.31.0.486818721138.issue7380@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Attached patch gives coherence:
 * both UUID.bytes and UUID.bytes_le return a "bytes" object
 * the random tests are explicitly skipped

Then the documentation needs fixing, too.

----------
keywords: +patch
Added file: http://bugs.python.org/file15385/issue7380_uuid.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7380>
_______________________________________

From report at bugs.python.org  Mon Nov 23 13:52:54 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 23 Nov 2009 12:52:54 +0000
Subject: [issue7353] cporting docs recommend using Include/intobject.h,
	which was removed in 3.1?
In-Reply-To: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za>
Message-ID: <1258980774.27.0.0539502434311.issue7353@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Eric pointed me to this ticket after having raised the question on
python-dev: http://www.mail-archive.com/python-dev at python.org/msg43841.html

I think the discussion should be continued there instead of on this ticket.

Just for completeness, I'm copying my reply to Martin's reply here
(http://www.mail-archive.com/python-dev at python.org/msg43849.html):

"""
> For example, consider
> 
> if (PyInt_Check(o)){
>   long val = PyInt_AsLong(o);
>   // process
> } else if (PyLong_Check(o)) {
>   long long val = PyLong_AsLongLong(o);
>   // check for overflow
>   // process
> }
> 
> With intobject.h, this code would continue to compile, but work
> incorrectly, as the second case will never be executed. It would
> be better to port this as
> 
> #if Py2.x
> if (PyInt_Check(o)){
>   long val = PyInt_AsLong(o);
>   // process
> } else
> #endif
> if (PyLong_Check(o)) {
> 
> i.e. eliminating the int case altogether.

Sure, but that assumes that the original code already had support
for Python longs, which a lot of code doesn't.

In an ideal world, developers would add that code to their
extensions right away. In the real world, where developers only
have limited resources available, you'll get more 3.x ports
by making such ports as painless as possible while at the
same time not forcing them to alienate their 2.x user base.

The long support could then be added in later releases
of the extensions, giving the developers more time adapt.

> For another example,
> 
> long foo = PyInt_AsLong(Foo);
> 
> has a hidden error in 3.x, with intobject: PyLong_AsLong might
> overflow, which the 2.x case doesn't.

That's not quite true: PyInt_AsLong(obj) will try the
nb_int slot on non-integer objects which can return errors
(it returns -1 and sets the error message).

> So eliminating intobject.h likely helps avoiding subtle errors.

In the long run, yes. In the short run, other criteria are
more important, IMHO.
"""

IMO, it would be worthwhile collecting all Python 2.x compatibility C
APIs in two new files:

 * py2compat.h
 * py2compat.c

These could then be used in extensions and make the use of such
compatibility APIs explicit in the extension.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7353>
_______________________________________

From report at bugs.python.org  Mon Nov 23 14:28:37 2009
From: report at bugs.python.org (flox)
Date: Mon, 23 Nov 2009 13:28:37 +0000
Subject: [issue7381] subprocess.check_output: "docstring has inconsistent
	leading whitespace"
In-Reply-To: <1258982917.41.0.193216902616.issue7381@psf.upfronthosting.co.za>
Message-ID: <1258982917.41.0.193216902616.issue7381@psf.upfronthosting.co.za>


New submission from flox <laxyf at yahoo.fr>:

I've tested the docstring of the module subprocess.
Python 2.5 is OK, but Python 3.1 fails.

~ $ python2.5 -m doctest /usr/lib/python2.5/subprocess.py
...............
----------------------------------------------------------------------
Ran 15 tests in 0.012s

OK
~ $ python3 -m doctest /usr/lib/python3.1/subprocess.py
Traceback (most recent call last):
  File "/usr/lib/python3.1/runpy.py", line 128, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python3.1/runpy.py", line 34, in _run_code
    exec(code, run_globals)
  File "/usr/lib/python3.1/doctest.py", line 2637, in <module>
    sys.exit(_test())
  File "/usr/lib/python3.1/doctest.py", line 2626, in _test
    failures, _ = testmod(m)
  File "/usr/lib/python3.1/doctest.py", line 1847, in testmod
    for test in finder.find(m, name, globs=globs, extraglobs=extraglobs):
  File "/usr/lib/python3.1/doctest.py", line 854, in find
    self._find(tests, obj, name, module, source_lines, globs, {})
  File "/usr/lib/python3.1/doctest.py", line 908, in _find
    globs, seen)
  File "/usr/lib/python3.1/doctest.py", line 896, in _find
    test = self._get_test(obj, name, module, globs, source_lines)
  File "/usr/lib/python3.1/doctest.py", line 980, in _get_test
    filename, lineno)
  File "/usr/lib/python3.1/doctest.py", line 590, in get_doctest
    return DocTest(self.get_examples(string, name), globs,
  File "/usr/lib/python3.1/doctest.py", line 604, in get_examples
    return [x for x in self.parse(string, name)
  File "/usr/lib/python3.1/doctest.py", line 566, in parse
    self._parse_example(m, name, lineno)
  File "/usr/lib/python3.1/doctest.py", line 636, in _parse_example
    lineno + len(source_lines))
  File "/usr/lib/python3.1/doctest.py", line 722, in _check_prefix
    (lineno+i+1, name, line))
ValueError: line 11 of the docstring for subprocess.check_output has
inconsistent leading whitespace: "'"

----------
components: Library (Lib), Tests
messages: 95625
nosy: flox
severity: normal
status: open
title: subprocess.check_output: "docstring has inconsistent leading whitespace"
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7381>
_______________________________________

From report at bugs.python.org  Mon Nov 23 14:40:01 2009
From: report at bugs.python.org (flox)
Date: Mon, 23 Nov 2009 13:40:01 +0000
Subject: [issue7381] subprocess.check_output: "docstring has inconsistent
	leading whitespace"
In-Reply-To: <1258982917.41.0.193216902616.issue7381@psf.upfronthosting.co.za>
Message-ID: <1258983601.52.0.689931989197.issue7381@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

I fixed the docstring inconsistency (see patch) and some obvious things.

But I still have errors.


~ $ python3 -m doctest py3_failed/subprocess.py
**********************************************************************
File "py3_failed/subprocess.py", line 139, in subprocess
Failed example:
    subprocess.getstatusoutput('/bin/junk')
Expected:
    (256, 'sh: /bin/junk: not found')
Got:
    (32512, '/bin/sh: /bin/junk: No such file or directory')
**********************************************************************
File "py3_failed/subprocess.py", line 449, in subprocess.check_output
Failed example:
    check_output(["ls", "-l", "/dev/null"])
Expected:
    b'crw-rw-rw- 1 root root 1, 3 Oct 18  2007 /dev/null\n'
Got:
    b'crw-rw-rw- 1 root root 1, 3 Nov 15 17:41 /dev/null\n'
**********************************************************************
File "py3_failed/subprocess.py", line 455, in subprocess.check_output
Failed example:
    check_output(["/bin/sh", "-c",
                  "ls -l non_existent_file ; exit 0"],
                  stderr=STDOUT)
Expected:
    b'ls: non_existent_file: No such file or directory\n'
Got:
    b'ls: cannot access non_existent_file: No such file or directory\n'
**********************************************************************
File "py3_failed/subprocess.py", line 559, in subprocess.getstatusoutput
Failed example:
    subprocess.getstatusoutput('/bin/junk')
Expected:
    (256, 'sh: /bin/junk: not found')
Got:
    (32512, '/bin/sh: /bin/junk: No such file or directory')
**********************************************************************
3 items had failures:
   1 of   6 in subprocess
   2 of   2 in subprocess.check_output
   1 of   4 in subprocess.getstatusoutput
***Test Failed*** 4 failures.
~ $

----------
keywords: +patch
Added file: http://bugs.python.org/file15386/issue7381_first.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7381>
_______________________________________

From report at bugs.python.org  Mon Nov 23 14:45:47 2009
From: report at bugs.python.org (flox)
Date: Mon, 23 Nov 2009 13:45:47 +0000
Subject: [issue7381] subprocess.check_output: "docstring has inconsistent
	leading whitespace"
In-Reply-To: <1258982917.41.0.193216902616.issue7381@psf.upfronthosting.co.za>
Message-ID: <1258983947.21.0.5891880793.issue7381@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

It may be fixed with "# doctest: +ELLIPSIS" and "# doctest: +SKIP"
directives...
But it is probably platform-dependent.

I have tested only with Debian Lenny.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7381>
_______________________________________

From report at bugs.python.org  Mon Nov 23 14:57:27 2009
From: report at bugs.python.org (flox)
Date: Mon, 23 Nov 2009 13:57:27 +0000
Subject: [issue7376] "python -m doctest" results in FAIL: Doctest:
	__main__.DebugRunner
In-Reply-To: <1258912633.73.0.334320263097.issue7376@psf.upfronthosting.co.za>
Message-ID: <1258984647.21.0.36777638172.issue7376@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

I am ok with the proposal of removing the current "selftest" default
behavior.

And thank you for the tip.
I tried the command "python -m doctest Lib/*.py" and I found interesting
things:
 * #7379 about Lib/fractions.py
 * #7380 about Lib/uuid.py
 * #7381 about Lib/subprocess.py

;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7376>
_______________________________________

From report at bugs.python.org  Mon Nov 23 15:21:40 2009
From: report at bugs.python.org (Michael Droettboom)
Date: Mon, 23 Nov 2009 14:21:40 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1258986100.16.0.728317543037.issue1222585@psf.upfronthosting.co.za>


Michael Droettboom <mdboom at users.sourceforge.net> added the comment:

This is a rather serious bug for matplotlib -- since the C++ compiler is
not correctly selected, it can't be built with many Unix compilers, such
as Sun Studio.

----------
nosy: +mdboom

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222585>
_______________________________________

From report at bugs.python.org  Mon Nov 23 15:23:48 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 23 Nov 2009 14:23:48 +0000
Subject: [issue7371] Windows 64-bit build "skips" several projects in VS 2008
In-Reply-To: <1258752248.05.0.167808334648.issue7371@psf.upfronthosting.co.za>
Message-ID: <1258986228.97.0.508098741294.issue7371@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I can't reproduce this. If I do your steps 1 to 5, *nothing* is build -
not surprisingly, since these steps don't invoke a build at all.

When I then select, in the context menu of "Solution 'pcbuild'", the
menu item "Build solution", it builds everything.

Also, what operating system is "Windows 64-bit (SP2)"?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7371>
_______________________________________

From report at bugs.python.org  Mon Nov 23 15:29:39 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 23 Nov 2009 14:29:39 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1258986579.72.0.520257146387.issue1222585@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Has someone tried to apply it with a recent Python ?

I can work on it but I'll need some help from someone matplotlib or Sage
I guess..

----------
assignee:  -> tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222585>
_______________________________________

From report at bugs.python.org  Mon Nov 23 16:17:40 2009
From: report at bugs.python.org (Sebastian Hagen)
Date: Mon, 23 Nov 2009 15:17:40 +0000
Subject: [issue7382] bytes.__getnewargs__ is broken;
	copy.copy() therefore doesn't work on bytes, and bytes subclasses
	can't be pickled by default
In-Reply-To: <1258989459.99.0.51081222067.issue7382@psf.upfronthosting.co.za>
Message-ID: <1258989459.99.0.51081222067.issue7382@psf.upfronthosting.co.za>


New submission from Sebastian Hagen <sh_pybugs at memespace.net>:

In either python 3.0, bytes instances cannot be copied, and (even
trivial) bytes subclasses cannot be unpickled unless they explicitly
override __getnewargs__() or __reduce_ex__().

Copy problem:
>>> import copy; copy.copy(b'foo')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.1/copy.py", line 96, in copy
    return _reconstruct(x, rv, 0)
  File "/usr/lib/python3.1/copy.py", line 280, in _reconstruct
    y = callable(*args)
  File "/usr/lib/python3.1/copyreg.py", line 88, in __newobj__
    return cls.__new__(cls, *args)
TypeError: string argument without an encoding

Bytes subclass unpickle problem:
>>> class B(bytes):
...  pass
...
>>> import pickle; pickle.loads(pickle.dumps(B(b'foo')))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.1/pickle.py", line 1373, in loads
    encoding=encoding, errors=errors).load()
TypeError: string argument without an encoding


AFAICT, the problem is that bytes.__getnewargs__() returns a tuple with
a single argument - a string - and bytes.__new__() refuses to
reconstruct the instance when called with in that manner. That is,
"bytes.__new__(bytes, *b'foo'.__getnewargs__())" fails with a TypeError.

This does not cause a problem for pickling bytes instances (as opposed
to instances of a subclass of bytes), because both the Python and C
versions of pickle shipped with Python 3.[01] have built-in magic
(_Pickler.save_bytes() and save_bytes(), respectively) to deal with
bytes instances, and therefore never call their __getnewargs__().

The pickle case, in particular, is highly irritating; the error message
doesn't indicate which object is causing the problem, and until you
actually try to load the pickle, there's nothing to indicate that
there's anything problematic about pickling an instance of a subclass of
bytes.

----------
components: Library (Lib)
files: pickle_bytes_subclass.py
messages: 95632
nosy: sh
severity: normal
status: open
title: bytes.__getnewargs__ is broken; copy.copy() therefore doesn't work on bytes, and bytes subclasses can't be pickled by default
type: behavior
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file15387/pickle_bytes_subclass.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7382>
_______________________________________

From report at bugs.python.org  Mon Nov 23 16:43:36 2009
From: report at bugs.python.org (Michael Droettboom)
Date: Mon, 23 Nov 2009 15:43:36 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1258991016.65.0.855232510481.issue1222585@psf.upfronthosting.co.za>


Michael Droettboom <mdboom at users.sourceforge.net> added the comment:

I'm testing this against release25_maint and release26_maint as we
speak.  I'll post new patches when that's done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222585>
_______________________________________

From report at bugs.python.org  Mon Nov 23 16:56:41 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 Nov 2009 15:56:41 +0000
Subject: [issue7382] bytes.__getnewargs__ is broken;
	copy.copy() therefore doesn't work on bytes, and bytes subclasses
	can't be pickled by default
In-Reply-To: <1258989459.99.0.51081222067.issue7382@psf.upfronthosting.co.za>
Message-ID: <1258991801.77.0.447960186572.issue7382@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Confirmed on py3k trunk.  We no longer do bug fixes in 3.0, which is why
I'm removing it from versions.

----------
keywords: +easy
nosy: +r.david.murray
priority:  -> high
stage:  -> test needed
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7382>
_______________________________________

From report at bugs.python.org  Mon Nov 23 17:29:49 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 23 Nov 2009 16:29:49 +0000
Subject: [issue7379] Docstring for fractions.Fraction.limit_denominator fails
In-Reply-To: <1258977307.89.0.840946928578.issue7379@psf.upfronthosting.co.za>
Message-ID: <1258993789.48.0.331543943742.issue7379@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the report!  Fixed in r76456 through r76459.

----------
nosy: +mark.dickinson
resolution:  -> fixed
status: open -> closed
versions: +Python 2.6, Python 2.7 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7379>
_______________________________________

From report at bugs.python.org  Mon Nov 23 17:40:51 2009
From: report at bugs.python.org (flox)
Date: Mon, 23 Nov 2009 16:40:51 +0000
Subject: [issue7381] subprocess.check_output: "docstring has inconsistent
	leading whitespace"
In-Reply-To: <1258982917.41.0.193216902616.issue7381@psf.upfronthosting.co.za>
Message-ID: <1258994451.29.0.191070504304.issue7381@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Forget the "python2.5 -m doctest /usr/lib/python2.5/subprocess.py" in
first message msg95625.
This command does not do what I guessed. And there's no doctest in the
Python2.5 "subprocess" module.


The attached patch may be enough to fix the docstring inconsistencies
with Python3.1.
It might not be mandatory to make the docstring 100% successful.
(I see no PEP which requires that).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7381>
_______________________________________

From report at bugs.python.org  Mon Nov 23 17:43:29 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 23 Nov 2009 16:43:29 +0000
Subject: [issue7369] Fibonacci example does not include 0; section 4.6
In-Reply-To: <1258725032.09.0.34838264618.issue7369@psf.upfronthosting.co.za>
Message-ID: <1258994609.29.0.106735286333.issue7369@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed in r76460 through r76463.

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7369>
_______________________________________

From report at bugs.python.org  Mon Nov 23 18:05:53 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 23 Nov 2009 17:05:53 +0000
Subject: [issue7371] Windows 64-bit build "skips" several projects in VS 2008
In-Reply-To: <1258752248.05.0.167808334648.issue7371@psf.upfronthosting.co.za>
Message-ID: <1258995953.56.0.176984883329.issue7371@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

[...]
Step 6. Build Solution

The OS was 64-bit Windows XP (w/ Service Pack 2). Are you sure you were 
running a 64-bit operating system (i.e., not cross-compiling)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7371>
_______________________________________

From report at bugs.python.org  Mon Nov 23 19:03:47 2009
From: report at bugs.python.org (flox)
Date: Mon, 23 Nov 2009 18:03:47 +0000
Subject: [issue7380] uuid.UUID.bytes gives a bytearray() instead of bytes
In-Reply-To: <1258979633.13.0.798699674887.issue7380@psf.upfronthosting.co.za>
Message-ID: <1258999427.83.0.767570414681.issue7380@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Patch with documentation included. (branches/py3k)

----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +georg.brandl
Added file: http://bugs.python.org/file15388/issue7380.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7380>
_______________________________________

From report at bugs.python.org  Mon Nov 23 19:05:29 2009
From: report at bugs.python.org (Michael Droettboom)
Date: Mon, 23 Nov 2009 18:05:29 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1258999529.36.0.648106593271.issue1222585@psf.upfronthosting.co.za>


Michael Droettboom <mdboom at users.sourceforge.net> added the comment:

Attached is a patch against the release26-maint branch.  This works for
me on Sun Workshop 6.

Note that on Sun, the C compiler is 'cc' and the C++ compiler is 'CC',
but distutils uses 'cc' and 'c++'.  However, the CXX environment
variable now works (after applying the patch), so this is less of an
issue, if it can be considered a bug at all.

----------
Added file: http://bugs.python.org/file15389/py26_cxx_compiler.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222585>
_______________________________________

From report at bugs.python.org  Mon Nov 23 19:05:32 2009
From: report at bugs.python.org (flox)
Date: Mon, 23 Nov 2009 18:05:32 +0000
Subject: [issue7380] uuid.UUID.bytes gives a bytearray() instead of bytes
In-Reply-To: <1258979633.13.0.798699674887.issue7380@psf.upfronthosting.co.za>
Message-ID: <1258999532.72.0.720086150528.issue7380@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15385/issue7380_uuid.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7380>
_______________________________________

From report at bugs.python.org  Mon Nov 23 19:06:51 2009
From: report at bugs.python.org (Michael Droettboom)
Date: Mon, 23 Nov 2009 18:06:51 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1258999611.34.0.180265571678.issue1222585@psf.upfronthosting.co.za>


Michael Droettboom <mdboom at users.sourceforge.net> added the comment:

Here's another patch against release25_maint for the benefit of those
still using Python 2.5.  It's different only in some whitespace changes.

----------
Added file: http://bugs.python.org/file15390/py25_cxx_compiler.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222585>
_______________________________________

From report at bugs.python.org  Mon Nov 23 19:31:27 2009
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 23 Nov 2009 18:31:27 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1259001087.96.0.108977034371.issue1222585@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222585>
_______________________________________

From report at bugs.python.org  Mon Nov 23 19:42:36 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 23 Nov 2009 18:42:36 +0000
Subject: [issue1488943] difflib.Differ() doesn't always add hints for tab
	characters
Message-ID: <1259001756.01.0.18459356233.issue1488943@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Yes, I noticed the issue and found the patch to be good as well.
Unfortunate it was pending for a long time.
Fixed and Committed revision 76464 (trunk).

----------
assignee:  -> orsenthil
nosy: +orsenthil
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1488943>
_______________________________________

From report at bugs.python.org  Mon Nov 23 19:42:35 2009
From: report at bugs.python.org (Toshio Kuratomi)
Date: Mon, 23 Nov 2009 18:42:35 +0000
Subject: [issue644744] bdist_rpm fails when installing man pages
Message-ID: <1259001755.21.0.909294923918.issue644744@psf.upfronthosting.co.za>


Toshio Kuratomi <a.badger at gmail.com> added the comment:

sed is one of the programs we assume is always present when we build
packages in Fedora which is probably also what is wanted here.  (A
default install of Fedora will include sed but someone might be able to
create a minimal install that did not include it.) Note that within
Fedora we usually use a wildcard with man pages.  For example::

  %{_mandir}/man1/foo.1*

I'd suggest doing this rather than hardcoding ".gz".  Automatic
compression of manpages could be disabled on other distros, set to
bzip2, compress, or xz instead.  Wildcarding the suffix will catch all
of these cases and be more future-proof.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue644744>
_______________________________________

From report at bugs.python.org  Mon Nov 23 19:48:28 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 23 Nov 2009 18:48:28 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1259002108.07.0.64591074138.issue7117@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

r76465 removes the fixed-length buffer for formatting floats, hence
removes the restriction on the precision.   This should make removal of 
the %f -> %g switch straightforward.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Mon Nov 23 19:56:33 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 23 Nov 2009 18:56:33 +0000
Subject: [issue1488943] difflib.Differ() doesn't always add hints for tab
	characters
Message-ID: <1259002593.95.0.913567516114.issue1488943@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

merged to 26-maint in revision 76468 and shall merge in py3k too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1488943>
_______________________________________

From report at bugs.python.org  Mon Nov 23 20:07:08 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 23 Nov 2009 19:07:08 +0000
Subject: [issue1488943] difflib.Differ() doesn't always add hints for tab
	characters
Message-ID: <1259003228.33.0.988308207609.issue1488943@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

fixed r76469 (py3k) and r76470(release31-maint). Closing the issue.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1488943>
_______________________________________

From report at bugs.python.org  Mon Nov 23 20:14:21 2009
From: report at bugs.python.org (flox)
Date: Mon, 23 Nov 2009 19:14:21 +0000
Subject: [issue7376] "python -m doctest" results in FAIL: Doctest:
	__main__.DebugRunner
In-Reply-To: <1258912633.73.0.334320263097.issue7376@psf.upfronthosting.co.za>
Message-ID: <1259003661.47.0.535510025495.issue7376@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Patch proposed.

----------
Added file: http://bugs.python.org/file15391/issue7376_usage.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7376>
_______________________________________

From report at bugs.python.org  Mon Nov 23 20:18:35 2009
From: report at bugs.python.org (flox)
Date: Mon, 23 Nov 2009 19:18:35 +0000
Subject: [issue7376] "python -m doctest" results in FAIL: Doctest:
	__main__.DebugRunner
In-Reply-To: <1258912633.73.0.334320263097.issue7376@psf.upfronthosting.co.za>
Message-ID: <1259003915.4.0.757345383553.issue7376@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15392/issue7376_usage.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7376>
_______________________________________

From report at bugs.python.org  Mon Nov 23 20:18:45 2009
From: report at bugs.python.org (flox)
Date: Mon, 23 Nov 2009 19:18:45 +0000
Subject: [issue7376] "python -m doctest" results in FAIL: Doctest:
	__main__.DebugRunner
In-Reply-To: <1258912633.73.0.334320263097.issue7376@psf.upfronthosting.co.za>
Message-ID: <1259003925.04.0.529950865432.issue7376@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15391/issue7376_usage.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7376>
_______________________________________

From report at bugs.python.org  Mon Nov 23 20:25:45 2009
From: report at bugs.python.org (Thomas Vander Stichele)
Date: Mon, 23 Nov 2009 19:25:45 +0000
Subject: [issue644744] bdist_rpm fails when installing man pages
Message-ID: <1259004345.32.0.974364374933.issue644744@psf.upfronthosting.co.za>


Thomas Vander Stichele <thomasvs at users.sourceforge.net> added the comment:

Hi Toshio,

I'd probably also go for the wildcarding, but you'd still need to
'change' the INSTALLED_FILES file to do so, so you'd still use the same
mechanism.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue644744>
_______________________________________

From report at bugs.python.org  Mon Nov 23 20:39:22 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 Nov 2009 19:39:22 +0000
Subject: [issue7383] test_multiprocessing leaks
In-Reply-To: <1259005162.5.0.211028824786.issue7383@psf.upfronthosting.co.za>
Message-ID: <1259005162.5.0.211028824786.issue7383@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This has started a few days ago. I don't know if this was triggered by a
multiprocessing change or an unrelated one.
On trunk:

test_multiprocessing
beginning 6 repetitions
123456
......
test_multiprocessing leaked [277, 277, 277] references, sum=831

On py3k:

test_multiprocessing
beginning 6 repetitions
123456
......
test_multiprocessing leaked [229, 229, 229] references, sum=687

----------
assignee: jnoller
components: Library (Lib), Tests
messages: 95649
nosy: jnoller, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: test_multiprocessing leaks
type: resource usage
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7383>
_______________________________________

From report at bugs.python.org  Mon Nov 23 20:51:24 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 Nov 2009 19:51:24 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1258965429.09.0.933792121241.issue6071@psf.upfronthosting.co.za>
Message-ID: <1259005903.3519.11.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> As for the checks for bf_releasebuffer: I still think they are
> necessary. If an object implements bf_releasebuffer, that means that the
> object may change the buffer underneath, unless proper locking and
> unlocking takes place.

I know, but the problem is that by switching some argument definitions
to "s*" and friends we have broken compatibility for the (admittedly
uncommon) use case of giving an array object to those functions. Since
we probably don't want to backout those changes perhaps adding support
for the new buffer API to the array object is the best course of action.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6071>
_______________________________________

From report at bugs.python.org  Mon Nov 23 20:53:30 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 23 Nov 2009 19:53:30 +0000
Subject: [issue7345] calendar.TextCalendar().formatyear wrong argument list
In-Reply-To: <1258560704.19.0.583792221573.issue7345@psf.upfronthosting.co.za>
Message-ID: <1259006010.0.0.328425936319.issue7345@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r76471.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7345>
_______________________________________

From report at bugs.python.org  Mon Nov 23 21:03:48 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 23 Nov 2009 20:03:48 +0000
Subject: [issue7384] test_curses crash on FreeBSD buildbots
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

test_curses is currently causing the test runs to abort on the FreeBSD 6.4 
and 7.2 buildbots.

I can reproduce this on a FreeBSD 7.2 /amd64 machine by doing

./python Lib/test/regrtest.py -uall test___all__ test_curses

This dumps core, and the traceback points at the call to delwin() in 
PyCursesWindow_Dealloc, but it's far from obvious (to me) what's going 
wrong.  wo->win is not NULL here, and appears to point to a valid WINDOW.  
However, stdscr is NULL!  As far as I can tell, this shouldn't happen.

test_curses by itself doesn't crash, unless I add an 'import readline' or 
'import rlcompleter' to the top of test_curses.py.

I expect to have access to the FreeBSD machine for a few more days.  Any 
hints about what to try next would be appreciated.

----------
components: Extension Modules
keywords: buildbot
messages: 95652
nosy: mark.dickinson
severity: normal
status: open
title: test_curses crash on FreeBSD buildbots
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Mon Nov 23 21:10:13 2009
From: report at bugs.python.org (flox)
Date: Mon, 23 Nov 2009 20:10:13 +0000
Subject: [issue7376] "python -m doctest" results in FAIL: Doctest:
	__main__.DebugRunner
In-Reply-To: <1258912633.73.0.334320263097.issue7376@psf.upfronthosting.co.za>
Message-ID: <1259007013.01.0.153678497913.issue7376@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Patch could be applied to Python 2.6 and trunk too.

----------
versions: +Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7376>
_______________________________________

From report at bugs.python.org  Mon Nov 23 21:12:18 2009
From: report at bugs.python.org (Toshio Kuratomi)
Date: Mon, 23 Nov 2009 20:12:18 +0000
Subject: [issue644744] bdist_rpm fails when installing man pages
Message-ID: <1259007138.57.0.215784195216.issue644744@psf.upfronthosting.co.za>


Toshio Kuratomi <a.badger at gmail.com> added the comment:

Agreed.  The substitution is still needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue644744>
_______________________________________

From report at bugs.python.org  Mon Nov 23 21:24:24 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 23 Nov 2009 20:24:24 +0000
Subject: [issue7128] cPickle looking for non-existent package copyreg
In-Reply-To: <1255536754.55.0.971036296539.issue7128@psf.upfronthosting.co.za>
Message-ID: <1259007864.74.0.167608304911.issue7128@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Patch looks ok to me, do you want to apply it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7128>
_______________________________________

From report at bugs.python.org  Mon Nov 23 21:25:10 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 23 Nov 2009 20:25:10 +0000
Subject: [issue7383] test_multiprocessing leaks
In-Reply-To: <1259005162.5.0.211028824786.issue7383@psf.upfronthosting.co.za>
Message-ID: <1259007910.9.0.662739123594.issue7383@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

AFAIK; I haven't changed anything which would introduce refleaks in the 
code. So, it's going to be a matter of chasing down all of the changes 
since the refleaks popped up and see which one triggered it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7383>
_______________________________________

From report at bugs.python.org  Mon Nov 23 21:31:40 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 23 Nov 2009 20:31:40 +0000
Subject: [issue7372] Regression in pstats
In-Reply-To: <1258765391.77.0.857956675588.issue7372@psf.upfronthosting.co.za>
Message-ID: <1259008300.83.0.264867101939.issue7372@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Alexander, how hard would it be to change the profile output?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7372>
_______________________________________

From report at bugs.python.org  Mon Nov 23 21:56:27 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 23 Nov 2009 20:56:27 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1259009787.54.0.150697927168.issue7117@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

r76474: Remove %f -> %g switch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Mon Nov 23 22:06:20 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 23 Nov 2009 21:06:20 +0000
Subject: [issue7372] Regression in pstats
In-Reply-To: <1259008300.83.0.264867101939.issue7372@psf.upfronthosting.co.za>
Message-ID: <d38f5330911231306w2bfca1efv76a5e18d1d99a79a@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It would be fairly easy to change format before dumping stats to disk,
but unfortunately Profile does not encapsulate it's run-time data and
changing its format would be a mess.

Of course, one can hack around that by turning Profile.stats into a
computed property, but that's hardly an acceptable solution.

I think it is worthwhile fixing the on-disk format, but as a long-tem
solution one may consider adding common (possibly iterator-based) API
to both profile and cProfile that pstats can use instead of accessing
internal data structures.

Creating an ABC for a standard Python profiler, seems to be a
worthwhile project that in the future may simplify plugging in 3rd
party profilers, but I don't have expertise to undertake such a
project.  That would require experience with multiple Python profilers
that I don't have.

On Mon, Nov 23, 2009 at 3:31 PM, Georg Brandl <report at bugs.python.org> wrote:
>
> Georg Brandl <georg at python.org> added the comment:
>
> Alexander, how hard would it be to change the profile output?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7372>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7372>
_______________________________________

From report at bugs.python.org  Mon Nov 23 23:07:07 2009
From: report at bugs.python.org (Pauli Virtanen)
Date: Mon, 23 Nov 2009 22:07:07 +0000
Subject: [issue7385] MemoryView_FromObject crashes if PyBuffer_GetBuffer fails
In-Reply-To: <1259014027.47.0.458918561634.issue7385@psf.upfronthosting.co.za>
Message-ID: <1259014027.47.0.458918561634.issue7385@psf.upfronthosting.co.za>


New submission from Pauli Virtanen <pav at iki.fi>:

In Objects/memoryobject.c:PyMemoryView_FromObject there's a
_PyObject_GC_UNTRACK unpaired with corresponding _PyObject_GC_TRACK,
which seems to cause a segmentation fault. This can be triggered by
calling PyMemoryView_FromObject on an object whose bf_getbuffer returns
an error.

PyMemoryView_FromObject(PyObject *base) {
   ...
   if (PyObject_GetBuffer(base, &(mview->view), PyBUF_FULL_RO) < 0) {
       Py_DECREF(mview);
       return NULL;
   } 
   ...
   _PyObject_GC_TRACK(mview);
}
...
static void memory_dealloc(PyMemoryViewObject *self) {
   _PyObject_GC_UNTRACK(self); 
   ....
}

----------
components: Interpreter Core
messages: 95660
nosy: pv
severity: normal
status: open
title: MemoryView_FromObject crashes if PyBuffer_GetBuffer fails
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7385>
_______________________________________

From report at bugs.python.org  Tue Nov 24 03:25:35 2009
From: report at bugs.python.org (pengyu.ut)
Date: Tue, 24 Nov 2009 02:25:35 +0000
Subject: [issue7386] More precise document on os.path.normpath()
In-Reply-To: <1259029535.8.0.110880013855.issue7386@psf.upfronthosting.co.za>
Message-ID: <1259029535.8.0.110880013855.issue7386@psf.upfronthosting.co.za>


New submission from pengyu.ut <pengyu.ut at gmail.com>:

os.path.normpath() doesn't return the trailing '/', if the path is a
directory. But the document doesn't mention this fact.

I recommend document this feature.

----------
assignee: georg.brandl
components: Documentation
messages: 95661
nosy: georg.brandl, pengyu.ut
severity: normal
status: open
title: More precise document on os.path.normpath()
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7386>
_______________________________________

From report at bugs.python.org  Tue Nov 24 03:25:52 2009
From: report at bugs.python.org (pengyu.ut)
Date: Tue, 24 Nov 2009 02:25:52 +0000
Subject: [issue7387] More precise document on os.path.normpath()
In-Reply-To: <1259029552.04.0.647489871972.issue7387@psf.upfronthosting.co.za>
Message-ID: <1259029552.04.0.647489871972.issue7387@psf.upfronthosting.co.za>


New submission from pengyu.ut <pengyu.ut at gmail.com>:

os.path.normpath() doesn't return the trailing '/', if the path is a
directory. But the document doesn't mention this fact.

I recommend document this feature.

----------
assignee: georg.brandl
components: Documentation
messages: 95662
nosy: georg.brandl, pengyu.ut
severity: normal
status: open
title: More precise document on os.path.normpath()
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7387>
_______________________________________

From report at bugs.python.org  Tue Nov 24 04:04:37 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Nov 2009 03:04:37 +0000
Subject: [issue7383] test_multiprocessing leaks
In-Reply-To: <1259005162.5.0.211028824786.issue7383@psf.upfronthosting.co.za>
Message-ID: <1259031877.36.0.563921298196.issue7383@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This started just after r76438, which is an additional test for
multiprocessing.  Given build delays this is only a correlation not a
definite cause, but it is suspicious.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7383>
_______________________________________

From report at bugs.python.org  Tue Nov 24 05:03:04 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 24 Nov 2009 04:03:04 +0000
Subject: [issue7387] More precise document on os.path.normpath()
In-Reply-To: <1259029552.04.0.647489871972.issue7387@psf.upfronthosting.co.za>
Message-ID: <1259035384.87.0.858206735241.issue7387@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7387>
_______________________________________

From report at bugs.python.org  Tue Nov 24 08:28:58 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 24 Nov 2009 07:28:58 +0000
Subject: [issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)
In-Reply-To: <1256712581.76.0.435920152498.issue7228@psf.upfronthosting.co.za>
Message-ID: <1259047738.36.0.18746743361.issue7228@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I think your patch is correct. (I couldn't check the behavior on error
condition itself, because I wasn't sure how, but I checked test_io run
on windows)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7228>
_______________________________________

From report at bugs.python.org  Tue Nov 24 09:27:14 2009
From: report at bugs.python.org (Ben Standefer)
Date: Tue, 24 Nov 2009 08:27:14 +0000
Subject: [issue6683] smtplib authentication - try all mechanisms
In-Reply-To: <1250007436.58.0.446313092376.issue6683@psf.upfronthosting.co.za>
Message-ID: <1259051234.29.0.941148554969.issue6683@psf.upfronthosting.co.za>


Ben Standefer <benstandefer at gmail.com> added the comment:

Here is one work-around.  The default smtplib.SMTP.login() doesn't work
for StrongMail out of the box.

http://www.harelmalka.com/?p=94&cpage=1

----------
nosy: +aguynamedben

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6683>
_______________________________________

From report at bugs.python.org  Tue Nov 24 10:43:52 2009
From: report at bugs.python.org (Retro)
Date: Tue, 24 Nov 2009 09:43:52 +0000
Subject: [issue7388] Documentation: capitalizations of the word 'python'
	needed when used as a name
In-Reply-To: <1259055832.84.0.933127183577.issue7388@psf.upfronthosting.co.za>
Message-ID: <1259055832.84.0.933127183577.issue7388@psf.upfronthosting.co.za>


New submission from Retro <vinetouu at gmail.com>:

There are 'python' typos in the Python tutorial in these titles:

(1) Tools for Working with Lists:
The following example shows an array of numbers stored as two byte
unsigned binary numbers (typecode "H") rather than the usual 16 bytes
per entry for regular lists of !!!python!!! (should be: Python) int objects

(2) Batteries Included:
Together, these modules and packages greatly simplify data interchange
between !!!python!!! (should be: Python) applications and other tools.


There may be other typos, but I only manage to find those two. Please
capitalize those two words. Thank you.

----------
assignee: georg.brandl
components: Documentation
messages: 95666
nosy: Retro, georg.brandl
severity: normal
status: open
title: Documentation: capitalizations of the word 'python' needed when used as a name
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7388>
_______________________________________

From report at bugs.python.org  Tue Nov 24 10:57:14 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 24 Nov 2009 09:57:14 +0000
Subject: [issue7388] Documentation: capitalizations of the word 'python'
	needed when used as a name
In-Reply-To: <1259055832.84.0.933127183577.issue7388@psf.upfronthosting.co.za>
Message-ID: <1259056634.07.0.511195682222.issue7388@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
keywords: +easy
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7388>
_______________________________________

From report at bugs.python.org  Tue Nov 24 11:05:48 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 24 Nov 2009 10:05:48 +0000
Subject: [issue1519816] urllib2 proxy does not work in 2.4.3
Message-ID: <1259057148.22.0.230596727298.issue1519816@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

HTTP Proxy Authentication works on Windows and has been verified. Under
the situation of failure, we do not enough details. Closing this bug as
out-of-date as the reporter informed it worked on py2.5 and problem was
with py2.4.

----------
assignee:  -> orsenthil
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1519816>
_______________________________________

From report at bugs.python.org  Tue Nov 24 12:05:59 2009
From: report at bugs.python.org (Retro)
Date: Tue, 24 Nov 2009 11:05:59 +0000
Subject: [issue7389] Make decimal floating point be default,
	remove binary floating point
In-Reply-To: <1259060759.88.0.182067416684.issue7389@psf.upfronthosting.co.za>
Message-ID: <1259060759.88.0.182067416684.issue7389@psf.upfronthosting.co.za>


New submission from Retro <vinetouu at gmail.com>:

The Python interpreter should have the decimal type built into its core.
The mechanism for dealing with decimal numbers should be handled by the
decimal type and not by the processor which spits binary floats. The
time is now. But ask yourself these questions:

Is this doable? If yes:
Would it break anything? If yes, note that:
Python 3.1 opposed to Python 3.0 also had major changes that break the
two appart.

I say go for revolutional change in Python 3.2. But the call is yours.

----------
components: Interpreter Core
messages: 95668
nosy: Retro, gvanrossum
severity: normal
status: open
title: Make decimal floating point be default, remove binary floating point
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7389>
_______________________________________

From report at bugs.python.org  Tue Nov 24 12:24:34 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 24 Nov 2009 11:24:34 +0000
Subject: [issue7389] Make decimal floating point be default,
	remove binary floating point
In-Reply-To: <1259060759.88.0.182067416684.issue7389@psf.upfronthosting.co.za>
Message-ID: <1259061874.32.0.0283072866519.issue7389@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I think the bug tracker is the wrong place to discuss such a wide-
ranging and (currently) ill-specified change.  The python-list or 
python-ideas mailing lists might be better places.

Decimal in the core is out of the question for Python 3.2, thanks to PEP 
3003.  What *is* feasible at this stage is to replace the current slow 
Python implementation of the decimal module with a C version;  there's 
some ongoing work on that.

Removing binary floats from the core entirely sounds like a bad idea to 
me, for performance reasons.  And it probably couldn't be done before 
Python 4.x without breaking backwards compatibility.

I'm closing this for now;  if you're interested in this, please take the 
discussion to python-list or python-ideas.

----------
nosy: +mark.dickinson
resolution:  -> later
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7389>
_______________________________________

From report at bugs.python.org  Tue Nov 24 13:37:28 2009
From: report at bugs.python.org (=?utf-8?q?S=C3=A9rgio_Surkamp?=)
Date: Tue, 24 Nov 2009 12:37:28 +0000
Subject: [issue7390] inconsistent type return
In-Reply-To: <1259066247.95.0.49478511562.issue7390@psf.upfronthosting.co.za>
Message-ID: <1259066247.95.0.49478511562.issue7390@psf.upfronthosting.co.za>


New submission from S?rgio Surkamp <sergio at gruposinternet.com.br>:

The type function returns inconsistent value depending on class hierarchy.

>>> class X:
...     pass
... 
>>> x = X()
>>> type(x)
<type 'instance'>
>>> class Y(object):
...     pass
... 
>>> x = Y()
>>> type(x)
<class '__main__.Y'>
>>> 
>>> class Z(X):
...     pass
...  
>>> x = Z()
>>> type(x)
<type 'instance'>
>>> class K(Y):
...     pass
...   
>>> x = K()
>>> type(x)
<class '__main__.K'>

All should reply 'instance'. As long as I have read on documentation the
only way to change the type function return is by writing a
__metaclass__ (PEP3115).

----------
components: Interpreter Core
messages: 95670
nosy: surkamp
severity: normal
status: open
title: inconsistent type return
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7390>
_______________________________________

From report at bugs.python.org  Tue Nov 24 13:43:49 2009
From: report at bugs.python.org (flox)
Date: Tue, 24 Nov 2009 12:43:49 +0000
Subject: [issue7390] inconsistent type return
In-Reply-To: <1259066247.95.0.49478511562.issue7390@psf.upfronthosting.co.za>
Message-ID: <1259066629.9.0.576575206933.issue7390@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

The relevant documentation for Python 2.6 is there.
http://docs.python.org/reference/datamodel.html#new-style-and-classic-classes

The PEP 3115 is implemented for Python >= 3.0.

There's nothing wrong.

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7390>
_______________________________________

From report at bugs.python.org  Tue Nov 24 13:44:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Nov 2009 12:44:18 +0000
Subject: [issue7390] inconsistent type return
In-Reply-To: <1259066247.95.0.49478511562.issue7390@psf.upfronthosting.co.za>
Message-ID: <1259066658.15.0.705800642093.issue7390@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

`instance` means it is an instance of an old-style class. Old-style
classes are classes which don't have `object` in their inheritance
hierarchy.
On the other hand, for instance new-style classes type() returns the
actual class.
Bottom line: this is by design. Of course in an ideal world (or in
Python 3) there are only new-style classes, but we had to maintain
compatibility, and that's why there are two slightly different object
models cohabiting in Python 2.x.

----------
nosy: +pitrou
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7390>
_______________________________________

From report at bugs.python.org  Tue Nov 24 13:44:22 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Nov 2009 12:44:22 +0000
Subject: [issue7390] inconsistent type return
In-Reply-To: <1259066247.95.0.49478511562.issue7390@psf.upfronthosting.co.za>
Message-ID: <1259066662.7.0.547987841353.issue7390@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7390>
_______________________________________

From report at bugs.python.org  Tue Nov 24 13:50:03 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Nov 2009 12:50:03 +0000
Subject: [issue7382] bytes.__getnewargs__ is broken;
	copy.copy() therefore doesn't work on bytes, and bytes subclasses
	can't be pickled by default
In-Reply-To: <1258989459.99.0.51081222067.issue7382@psf.upfronthosting.co.za>
Message-ID: <1259067003.43.0.919771280432.issue7382@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +alexandre.vassalotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7382>
_______________________________________

From report at bugs.python.org  Tue Nov 24 13:53:12 2009
From: report at bugs.python.org (Swapnil Talekar)
Date: Tue, 24 Nov 2009 12:53:12 +0000
Subject: [issue5294] pdb "break" command messes up "continue"
In-Reply-To: <1234871505.48.0.0380268951532.issue5294@psf.upfronthosting.co.za>
Message-ID: <1259067192.05.0.577804229899.issue5294@psf.upfronthosting.co.za>


Swapnil Talekar <swapnil.st at gmail.com> added the comment:

The problem it seems is actually in the bdb module and not in pdb. The 
set_next function sets the current frame as stopframe but it does not 
specify the stoplineno. Hence it's always -1. When you do c(ontinue), 
set_continue just sets botframe as stopframe, if there are no breakpoints.  
Hence, stop_here wrongly returns True on every line event. To rectify 
this, set_next should also specify stoplineno for the stopframe and this 
should be checked in stop_here before returning True. Here is the patch.

----------
nosy: +swapnil
type:  -> behavior
Added file: http://bugs.python.org/file15393/bdbdiff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5294>
_______________________________________

From report at bugs.python.org  Tue Nov 24 13:56:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Nov 2009 12:56:10 +0000
Subject: [issue7383] test_multiprocessing leaks
In-Reply-To: <1259031877.36.0.563921298196.issue7383@psf.upfronthosting.co.za>
Message-ID: <1259067388.3450.8.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> R. David Murray <rdmurray at bitdance.com> added the comment:
> 
> This started just after r76438, which is an additional test for
> multiprocessing.  Given build delays this is only a correlation not a
> definite cause, but it is suspicious.

I just checked, it was indeed introduced by r76438.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7383>
_______________________________________

From report at bugs.python.org  Tue Nov 24 15:14:13 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 24 Nov 2009 14:14:13 +0000
Subject: [issue7383] test_multiprocessing leaks
In-Reply-To: <1259005162.5.0.211028824786.issue7383@psf.upfronthosting.co.za>
Message-ID: <1259072053.6.0.735567721478.issue7383@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Well, that's alarming. I'll back that out for now - I'm fairly disturbed 
it introduced leaks that bad.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7383>
_______________________________________

From report at bugs.python.org  Tue Nov 24 15:19:23 2009
From: report at bugs.python.org (Neil Cerutti)
Date: Tue, 24 Nov 2009 14:19:23 +0000
Subject: [issue7391] Re-title the "Using Backslash to Continue Statements"
	anti-idiom
In-Reply-To: <1259072363.61.0.346322429524.issue7391@psf.upfronthosting.co.za>
Message-ID: <1259072363.61.0.346322429524.issue7391@psf.upfronthosting.co.za>


New submission from Neil Cerutti <cerutti at trans-video.net>:

This "anti-idiom" is in the Python HOWTOs->Idioms and Anti-Idioms

The current title is "Using Backslash to Continue Statements"

However, using the line continuation character won't cause mysterious
problems in statements, but only in certain expressions, as the article
goes on to explain.

Moreover, the proposed solution of wrapping expressions in parentheses
is a syntax error in a statement, e.g.:

with (open(roster_path, 'r') as roster_file,
      open(disb_path, 'w') as out_file,
      open(report_path, 'w') as report_file):
File "C:\project\codxml.py", line 184
   with (open(roster_path, 'r') as roster_file,
                                   ^
SyntaxError: invalid syntax

I suggest that the title be changed to "Using Backslash to Continue
Expressions."

I'm sorry I don't know for sure when this HOWTO was first included in
the normal Python distribution.

----------
assignee: georg.brandl
components: Documentation
messages: 95676
nosy: Horpner, georg.brandl
severity: normal
status: open
title: Re-title the "Using Backslash to Continue Statements" anti-idiom
versions: Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7391>
_______________________________________

From report at bugs.python.org  Tue Nov 24 15:22:16 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 24 Nov 2009 14:22:16 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
Message-ID: <1259072536.04.0.518040888216.issue6615@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I've commented out the test (therefore, reopening this) the test 
introduces a pretty bad refleak problem. Need to debug.

----------
resolution: fixed -> accepted
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Tue Nov 24 15:22:56 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 24 Nov 2009 14:22:56 +0000
Subject: [issue7383] test_multiprocessing leaks
In-Reply-To: <1259005162.5.0.211028824786.issue7383@psf.upfronthosting.co.za>
Message-ID: <1259072576.56.0.00495091651733.issue7383@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I've backed it out on trunk and py3k. I've reopened the original bug to 
debug the refleak caused by the test.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7383>
_______________________________________

From report at bugs.python.org  Tue Nov 24 15:27:37 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 24 Nov 2009 14:27:37 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
Message-ID: <1259072857.35.0.883757163602.issue6615@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Are these leaks caused by the test, or revealed by it?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Tue Nov 24 16:05:27 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Nov 2009 15:05:27 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
Message-ID: <1259075127.23.0.455575477075.issue6615@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

>From a quick command-line attempt, it seems that logging is the culprit:

>>> handler = logging.Handler()
[64370 refs]
>>> handler = logging.Handler()
[64383 refs]
>>> handler = logging.Handler()
[64396 refs]

----------
nosy: +pitrou, vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Tue Nov 24 16:14:27 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 24 Nov 2009 15:14:27 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
Message-ID: <1259075667.28.0.608101482413.issue6615@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, test_logging has a serious tearDown() method to wipe installed
handlers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Tue Nov 24 16:16:55 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Nov 2009 15:16:55 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1259075667.28.0.608101482413.issue6615@psf.upfronthosting.co.za>
Message-ID: <1259075834.3450.11.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Yes, test_logging has a serious tearDown() method to wipe installed
> handlers.

In general it would be nice if logging were more conservative (or
cautious) when it comes to keeping objects persistent. It is too easy to
fall into a trap and experience memory leaks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Tue Nov 24 16:25:57 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Nov 2009 15:25:57 +0000
Subject: [issue7383] test_multiprocessing leaks
In-Reply-To: <1259005162.5.0.211028824786.issue7383@psf.upfronthosting.co.za>
Message-ID: <1259076357.07.0.311257141882.issue7383@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I haven't looked at the test, but is it possible that the logging module
is creating state that isn't being cleaned up after the test completes?
 Test refleaks don't always mean refleaks in the underlying C code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7383>
_______________________________________

From report at bugs.python.org  Tue Nov 24 17:09:17 2009
From: report at bugs.python.org (Andy)
Date: Tue, 24 Nov 2009 16:09:17 +0000
Subject: [issue5166] ElementTree and minidom don't prevent creation of not
	well-formed XML
In-Reply-To: <1233918825.25.0.360851750395.issue5166@psf.upfronthosting.co.za>
Message-ID: <1259078957.56.0.959172293741.issue5166@psf.upfronthosting.co.za>


Andy <strangefeatures at users.sourceforge.net> added the comment:

I'm also of the opinion that this would be a valuable feature to have. I
think it's a reasonable expectation that an XML library produces valid
XML. It's particularly strange that ET would output XML that it can't
itself read. Surely the job of making the input valid falls on the XML
creator - that's the point of using libraries in the first place, to
abstract away from details like not being able to use characters in the
0-32 range, in the same way that ampersands etc are auto-escaped.
Granted, it's not as clear-cut here since the low-range ASCII characters
are likely to be less frequent and the strategy to handle them is less
clear. I think the sanest behaviour would be to raise an exception by
default, although a user-configurable option to replace or omit the
characters would also make sense. If impacting performance is a concern,
maybe it would make sense to be off by default, but I would have thought
that the single regex that could perform the check would have relatively
minimal impact - and it seems to be an acceptable overhead on the
parsing side, so why not on generation?

----------
nosy: +strangefeatures

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5166>
_______________________________________

From report at bugs.python.org  Tue Nov 24 17:37:44 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 24 Nov 2009 16:37:44 +0000
Subject: [issue6393] OS X: python3 from python-3.1.dmg crashes at startup
In-Reply-To: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>
Message-ID: <1259080664.37.0.796612204927.issue6393@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6393>
_______________________________________

From report at bugs.python.org  Tue Nov 24 17:40:17 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 24 Nov 2009 16:40:17 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
Message-ID: <1259080817.91.0.227802841908.issue6615@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Yeah, I should have checked the tearDown stuff in the logging test suite

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Tue Nov 24 17:55:16 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 24 Nov 2009 16:55:16 +0000
Subject: [issue1653416] print >> f, "Hello" produces no error: normal?
Message-ID: <1259081716.93.0.507957697484.issue1653416@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

<http://www.opengroup.org/onlinepubs/9699919799/functions/printf.html> 
claims fprintf should return a negative value when there is an output 
error (the same claims is in the manpage of fprintf on OSX 10.6).

Neither document refers to the error indicator. I'm afraid Martin is right 
that that the return value of all calls to fprintf (and fwrite) need to be  
explicitly checked, which is a very large patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1653416>
_______________________________________

From report at bugs.python.org  Tue Nov 24 17:59:40 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 24 Nov 2009 16:59:40 +0000
Subject: [issue822005] Carbon.CarbonEvt.ReceiveNextEvent args wrong
Message-ID: <1259081980.18.0.55751085036.issue822005@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

According to 
<http://developer.apple.com/legacy/mac/library/documentation/Carbon/Concep
tual/Carbon_Event_Manager/CarbonEvents.pdf> this issue is valid.

However, I won't work on fixing this because Carbon is deprecated, both 
the Python bindings and the framework itself.

Therefore lowering the priority.

----------
nosy: +ronaldoussoren
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue822005>
_______________________________________

From report at bugs.python.org  Tue Nov 24 17:59:58 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 24 Nov 2009 16:59:58 +0000
Subject: [issue822005] Carbon.CarbonEvt.ReceiveNextEvent args wrong
Message-ID: <1259081998.59.0.644315904268.issue822005@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
resolution:  -> wont fix
versions: +Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue822005>
_______________________________________

From report at bugs.python.org  Tue Nov 24 18:02:13 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 24 Nov 2009 17:02:13 +0000
Subject: [issue1700507] Carbon.Scrap.PutScrapFlavor
Message-ID: <1259082133.4.0.261832046056.issue1700507@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Lowering the priority to low because this is a bug in a deprecated binding 
for a deprecated Apple framework.  I won't work on a fix, although I am 
willing to review and apply a patch when someone provides one.

----------
nosy: +ronaldoussoren
priority: normal -> low
resolution:  -> wont fix
versions: +Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1700507>
_______________________________________

From report at bugs.python.org  Tue Nov 24 18:15:04 2009
From: report at bugs.python.org (Reid Kleckner)
Date: Tue, 24 Nov 2009 17:15:04 +0000
Subject: [issue6033] LOOKUP_METHOD and CALL_METHOD optimization
In-Reply-To: <1242438240.35.0.944379800728.issue6033@psf.upfronthosting.co.za>
Message-ID: <1259082904.09.0.571808399043.issue6033@psf.upfronthosting.co.za>


Changes by Reid Kleckner <rnk at mit.edu>:


----------
nosy: +rnk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6033>
_______________________________________

From report at bugs.python.org  Tue Nov 24 18:26:35 2009
From: report at bugs.python.org (Denis S. Otkidach)
Date: Tue, 24 Nov 2009 17:26:35 +0000
Subject: [issue5166] ElementTree and minidom don't prevent creation of not
	well-formed XML
In-Reply-To: <1233918825.25.0.360851750395.issue5166@psf.upfronthosting.co.za>
Message-ID: <1259083595.27.0.0857744224848.issue5166@psf.upfronthosting.co.za>


Denis S. Otkidach <denis.otkidach at gmail.com> added the comment:

Here is a regexp I use to clean up text (note, that I don't touch 
"compatibility characters" that are also not recommended in XML; some 
other developers remove them too):

# http://www.w3.org/TR/REC-xml/#NT-Char
# Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | 
#          [#x10000- #x10FFFF]
# (any Unicode character, excluding the surrogate blocks, FFFE, and 
FFFF)
_char_tail = ''
if sys.maxunicode > 0x10000:
    _char_tail = u'%s-%s' % (unichr(0x10000),
                             unichr(min(sys.maxunicode, 0x10FFFF)))
_nontext_sub = re.compile(
                ur'[^\x09\x0A\x0D\x20-\uD7FF\uE000-\uFFFD%s]' % 
_char_tail,
                re.U).sub
def replace_nontext(text, replacement=u'\uFFFD'):
    return _nontext_sub(replacement, text)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5166>
_______________________________________

From report at bugs.python.org  Tue Nov 24 18:42:51 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 24 Nov 2009 17:42:51 +0000
Subject: [issue7382] bytes.__getnewargs__ is broken;
	copy.copy() therefore doesn't work on bytes, and bytes subclasses
	can't be pickled by default
In-Reply-To: <1258989459.99.0.51081222067.issue7382@psf.upfronthosting.co.za>
Message-ID: <1259084571.26.0.924461089365.issue7382@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

We just need make __getnewargs__ return bytes, instead of a unicode
string. So this is a single character fix.

I think we should reuse the ByteArraySubclass test case in test_bytes.py
to test for this bug. Incidentally, the reduce method of bytearray
should also be changed to emit bytes instead of a unicode string.

----------
keywords: +patch
Added file: http://bugs.python.org/file15394/fix_bytes_reduce.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7382>
_______________________________________

From report at bugs.python.org  Tue Nov 24 19:01:43 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 24 Nov 2009 18:01:43 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1259075834.3450.11.camel@localhost>
Message-ID: <182498.32330.qm@web25806.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> In general it would be nice if logging were more conservative (or

> cautious) when it comes to keeping objects persistent. It is too easy to
> fall into a trap and experience memory leaks.

I've checked in a change into trunk today which might improve matters. Handler.__init__ no longer adds the handler instance to the _handlers map unconditionally, but still adds it to the _handlerList array. The only place this array is actually used is in the shutdown() API, which is registered to be run via atexit. It flushes and closes  all the handlers in the list, so that any data in logging buffers gets flushed before the process exits.

The _handlers dict is now used to hold a mapping between handler names and handlers - the name property was added to Handler in the change I checked in today. This will be used by the dictConfig functionality which is proposed in PEP 391. If no name property is set on a Handler, then this will not add any additional references to handlers.

Python 2.7a0 (trunk:75403, Oct 14 2009, 20:14:09) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging
[49139 refs]
>>> logging._handlerList
[]
[49146 refs]
>>> logging.Handler()
<logging.Handler object at 0x00B72658>
[49179 refs]
>>> logging.Handler()
<logging.Handler object at 0x00B72620>
[49202 refs]
>>> logging.Handler()
<logging.Handler object at 0x00B764D0>
[49225 refs]
>>> logging._handlerList
[<logging.Handler object at 0x00B764D0>, <logging.Handler object at 0x00B72620>,
 <logging.Handler object at 0x00B72658>]
[49225 refs]
>>> logging.shutdown()
[49156 refs]
>>> logging._handlerList
[]
[49156 refs]
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Tue Nov 24 19:05:41 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 24 Nov 2009 18:05:41 +0000
Subject: [issue7392] cPickle test failure on release26-maint branch
In-Reply-To: <1259085941.32.0.227872963702.issue7392@psf.upfronthosting.co.za>
Message-ID: <1259085941.32.0.227872963702.issue7392@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti <alexandre at peadrop.com>:

I get the following test failure on the release26-maint branch:

./python Lib/test/test_cpickle.py
[...]
======================================================================
ERROR: test_issue2702 (__main__.cPickleDeepRecursive)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_cpickle.py", line 110, in test_issue2702
    self.assertRaises(RuntimeError, cPickle.dumps, n)
  File "/home/alex/src/python.org/release26-maint/Lib/unittest.py", line
336, in failUnlessRaises
    callableObj(*args, **kwargs)
  File "/home/alex/src/python.org/release26-maint/Lib/copy_reg.py", line
74, in _reduce_ex
    getstate = self.__getstate__
AttributeError: 'Node' object has no attribute '__getstate__'

----------
components: Library (Lib), Tests
messages: 95692
nosy: alexandre.vassalotti
priority: normal
severity: normal
stage: needs patch
status: open
title: cPickle test failure on release26-maint branch
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7392>
_______________________________________

From report at bugs.python.org  Tue Nov 24 19:07:07 2009
From: report at bugs.python.org (Andrew Shuiu)
Date: Tue, 24 Nov 2009 18:07:07 +0000
Subject: [issue3924] cookielib chokes on non-integer cookie version,
	should ignore it instead
In-Reply-To: <1222021824.75.0.209543556591.issue3924@psf.upfronthosting.co.za>
Message-ID: <1259086027.38.0.388463437253.issue3924@psf.upfronthosting.co.za>


Changes by Andrew Shuiu <asuiu at bitdefender.com>:


----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3924>
_______________________________________

From report at bugs.python.org  Tue Nov 24 19:07:42 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 24 Nov 2009 18:07:42 +0000
Subject: [issue7128] cPickle looking for non-existent package copyreg
In-Reply-To: <1255536754.55.0.971036296539.issue7128@psf.upfronthosting.co.za>
Message-ID: <1259086062.79.0.708443324702.issue7128@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Thanks you!

Committed in r76499 and backported to 2.6 in r76500.

----------
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7128>
_______________________________________

From report at bugs.python.org  Tue Nov 24 19:08:36 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Nov 2009 18:08:36 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <182498.32330.qm@web25806.mail.ukl.yahoo.com>
Message-ID: <1259086135.3450.23.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Handler.__init__ no longer adds the handler instance to the _handlers
> map unconditionally, but still adds it to the _handlerList array. The
> only place this array is actually used is in the shutdown() API, which
> is registered to be run via atexit. It flushes and closes  all the
> handlers in the list, so that any data in logging buffers gets flushed
> before the process exits.

Why is this exactly? Why do you want to keep handlers until shutdown
rather than dispose of them when they aren't used anymore?

Moreover, closing in atexit is rather bad because the resources
necessary for proper closing (files, sockets...) may already have been
freed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Tue Nov 24 19:23:47 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 24 Nov 2009 18:23:47 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1259086135.3450.23.camel@localhost>
Message-ID: <875918.56341.qm@web25804.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Why is this exactly? Why do you want to keep handlers until shutdown

> rather than dispose of them when they aren't used anymore?

Typically handlers are only instantiated when being added to loggers, and loggers live for the lifetime of the process so those handler references will typically be persistent. However, if a handler is closed (typically after removing from a handler), it's removed from the list and would not cause a memory leak.

> Moreover, closing in atexit is rather bad because the resources
> necessary for proper closing (files, sockets...) may already have been
> freed.

That's potentially true, but it's behaviour which has been there from the beginning so ISTM it needs to be there for backward compatibility reasons :-( When logging.raiseExceptions is True (the default) any exceptions in shutdown() would be raised, but this doesn't appear to happen in practice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Tue Nov 24 19:24:58 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 24 Nov 2009 18:24:58 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <875918.56341.qm@web25804.mail.ukl.yahoo.com>
Message-ID: <857185.79870.qm@web25805.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> removing from a handler), it's removed from the list and would not cause a 

s/handler/logger/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Tue Nov 24 20:23:49 2009
From: report at bugs.python.org (flox)
Date: Tue, 24 Nov 2009 19:23:49 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
Message-ID: <1259090629.98.0.603707520195.issue6615@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

I would think to use weak references in order to prevent such leaks.

With the patch attached, if the handler is not referenced anywhere, it
is closed.
However named handlers are not closed (because of hard reference in
_handlers dictionary).

----------
nosy: +flox
Added file: http://bugs.python.org/file15395/issue6615_weakref.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Tue Nov 24 21:47:48 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 24 Nov 2009 20:47:48 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1259090629.98.0.603707520195.issue6615@psf.upfronthosting.co.za>
Message-ID: <112227.16993.qm@web25806.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> With the patch attached, if the handler is not referenced anywhere, it

> is closed.
> However named handlers are not closed (because of hard reference in
> _handlers dictionary).

I haven't tried it yet, but does the patch actually work? You seem to have self_weakref in one place and self._weakref in another...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Tue Nov 24 21:59:25 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 24 Nov 2009 20:59:25 +0000
Subject: [issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)
In-Reply-To: <1256712581.76.0.435920152498.issue7228@psf.upfronthosting.co.za>
Message-ID: <1259096365.79.0.0872535321701.issue7228@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for testing!

Fixed (again) in r76502 (trunk), r76503 (py3k).  I don't think it's worth 
backporting the fix to the release branches, given that that would require 
also implementing %lld support in those branches.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7228>
_______________________________________

From report at bugs.python.org  Tue Nov 24 22:46:22 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 24 Nov 2009 21:46:22 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1259099182.29.0.672473912678.issue7117@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I think we're pretty much done here.

I'd still like to produce a more complete set of float formatting test 
cases at some point (for both trunk and py3k), but that's a separate 
activity.

Eric, Raymond:  can you spot anything we've missed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Tue Nov 24 22:54:16 2009
From: report at bugs.python.org (flox)
Date: Tue, 24 Nov 2009 21:54:16 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
Message-ID: <1259099656.38.0.220077519017.issue6615@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15395/issue6615_weakref.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Tue Nov 24 23:41:53 2009
From: report at bugs.python.org (flox)
Date: Tue, 24 Nov 2009 22:41:53 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
Message-ID: <1259102513.69.0.711764579788.issue6615@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

yep... patch was not clean. Sorry :(

I changed it.
It passes the 21 tests of the test_logging suite.

And the count of references decreases with the test:

>>> import logging
>>> handler = logging.Handler()
>>> handler = logging.Handler()

----------
Added file: http://bugs.python.org/file15396/issue6615_weakref.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Tue Nov 24 23:45:22 2009
From: report at bugs.python.org (Trundle)
Date: Tue, 24 Nov 2009 22:45:22 +0000
Subject: [issue5911] built-in compile() should take encoding option.
In-Reply-To: <1241315725.1.0.346952935822.issue5911@psf.upfronthosting.co.za>
Message-ID: <1259102722.15.0.135329583498.issue5911@psf.upfronthosting.co.za>


Changes by Trundle <andy-python at hammerhartes.de>:


----------
nosy: +Trundle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5911>
_______________________________________

From report at bugs.python.org  Tue Nov 24 23:45:34 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 24 Nov 2009 22:45:34 +0000
Subject: [issue7391] Re-title the "Using Backslash to Continue Statements"
	anti-idiom
In-Reply-To: <1259072363.61.0.346322429524.issue7391@psf.upfronthosting.co.za>
Message-ID: <1259102734.55.0.155040631215.issue7391@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

As you write, the parentheses "trick" only works in expressions (what
you tried to wrap in your with statement is not an expression).

The backslash works for all kinds of statements however, so the
suggested change is wrong.

----------
resolution:  -> wont fix
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7391>
_______________________________________

From report at bugs.python.org  Tue Nov 24 23:46:42 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 24 Nov 2009 22:46:42 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1259102802.59.0.887779014569.issue7117@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Thanks for tackling the last few bits, Mark. I think we're done,
although I admit I haven't verified what state the documentation is in.

I suggest we close this issue and if any problems occur open them as new
issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Tue Nov 24 23:46:53 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Nov 2009 22:46:53 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
Message-ID: <1259102813.4.0.786911729588.issue6615@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Some quick comments on your patch (not an in-depth review):
- you should add some tests for the problem you're trying to solve
- using __del__ when you have a weakref is counter-productive; use the
weakref's optional callback instead
- if you remove arbitrary elements from it, _handlerList should probably
be a set rather a list (but it's more of an optimization concern)
- `for h in [wr() for wr in handlerList if wr() is not None]` isn't a
pretty notation; just put the `if` inside the `for` instead

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Wed Nov 25 00:55:51 2009
From: report at bugs.python.org (flox)
Date: Tue, 24 Nov 2009 23:55:51 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
Message-ID: <1259106951.76.0.372379984736.issue6615@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Updated the patch with technical recommendations from Antoine.

I kept the _handlerList as a list because "It allows handlers to be
removed in reverse of order initialized."

And some tests are needed to outline the change.

----------
Added file: http://bugs.python.org/file15397/issue6615_weakref.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Wed Nov 25 00:57:32 2009
From: report at bugs.python.org (flox)
Date: Tue, 24 Nov 2009 23:57:32 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
Message-ID: <1259107052.63.0.161891301192.issue6615@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15396/issue6615_weakref.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Wed Nov 25 01:14:18 2009
From: report at bugs.python.org (flox)
Date: Wed, 25 Nov 2009 00:14:18 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
Message-ID: <1259108058.22.0.469376723611.issue6615@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Small change to acquire the module lock before working on _handlerList.

----------
Added file: http://bugs.python.org/file15398/issue6615_weakref.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Wed Nov 25 01:14:38 2009
From: report at bugs.python.org (flox)
Date: Wed, 25 Nov 2009 00:14:38 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
Message-ID: <1259108078.54.0.563134527304.issue6615@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15397/issue6615_weakref.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Wed Nov 25 03:21:18 2009
From: report at bugs.python.org (Reid Kleckner)
Date: Wed, 25 Nov 2009 02:21:18 +0000
Subject: [issue6033] LOOKUP_METHOD and CALL_METHOD optimization
In-Reply-To: <1242438240.35.0.944379800728.issue6033@psf.upfronthosting.co.za>
Message-ID: <1259115678.3.0.140520221277.issue6033@psf.upfronthosting.co.za>


Reid Kleckner <rnk at mit.edu> added the comment:

One thing I was wondering about the current patch is what about objects
that have attributes that shadow methods?  For example:

class C(object):
    def foo(self):
        return 1
c = c()
print c.foo()
c.foo = lambda: 2
print c.foo()

Shouldn't the above print 1 and 2?  With the current patch, it seems
that you might still print 1.

There's also the possible performance drawback where you're loading
builtin C methods, so the optimization fails, but you end up calling
_PyType_Lookup twice.  :(

I'm doing the same optimization for unladen swallow, and these were some
of the things I ran into.  I think I'm going to write a
PyObject_GetMethod that tries to get a method without binding it, but if
it can't for any reason, it behaves just like PyObject_GetAttr and sets
a status code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6033>
_______________________________________

From report at bugs.python.org  Wed Nov 25 03:44:30 2009
From: report at bugs.python.org (Craig McQueen)
Date: Wed, 25 Nov 2009 02:44:30 +0000
Subject: [issue1606092] csv module broken for unicode
Message-ID: <1259117070.32.0.261643335364.issue1606092@psf.upfronthosting.co.za>


Changes by Craig McQueen <ces-pub at mcqueen.id.au>:


----------
nosy: +cmcqueen1975

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1606092>
_______________________________________

From report at bugs.python.org  Wed Nov 25 03:48:50 2009
From: report at bugs.python.org (Craig McQueen)
Date: Wed, 25 Nov 2009 02:48:50 +0000
Subject: [issue1606092] csv module broken for unicode
Message-ID: <1259117330.4.0.210214410411.issue1606092@psf.upfronthosting.co.za>


Craig McQueen <ces-pub at mcqueen.id.au> added the comment:

Is this still an open bug? I have the following code:

    lookup = {}
    csv_reader = csv.reader(codecs.open(lookup_file_name, 'r', 'utf-8'))
    for row in csv_reader:
        lookup[row[1]] = row[0]

And it "appears to work" (it runs) using Python 2.6.2. So has this bug
been fixed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1606092>
_______________________________________

From report at bugs.python.org  Wed Nov 25 04:07:20 2009
From: report at bugs.python.org (Craig McQueen)
Date: Wed, 25 Nov 2009 03:07:20 +0000
Subject: [issue1606092] csv module broken for unicode
Message-ID: <1259118440.99.0.953061984311.issue1606092@psf.upfronthosting.co.za>


Craig McQueen <ces-pub at mcqueen.id.au> added the comment:

I think I see now--it accepts Unicode input, but converts it back to
bytes internally using the ASCII codec. So it works as long as the
Unicode input contains on ASCII characters. That's a gotcha.

It appears that it's been fixed in Python 3.x, judging by the documentation.

----------
versions: +Python 2.4, Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1606092>
_______________________________________

From report at bugs.python.org  Wed Nov 25 04:27:42 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 25 Nov 2009 03:27:42 +0000
Subject: [issue6033] LOOKUP_METHOD and CALL_METHOD optimization
In-Reply-To: <1242438240.35.0.944379800728.issue6033@psf.upfronthosting.co.za>
Message-ID: <1259119662.79.0.234238930113.issue6033@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Yes, my patch introduces that regression you mention. PyPy solves this
by having the instances dictionary keep track of shadowing of the type
dictionary. Not easy for CPython... I wish you luck on your patch!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6033>
_______________________________________

From report at bugs.python.org  Wed Nov 25 08:09:55 2009
From: report at bugs.python.org (Mayuresh)
Date: Wed, 25 Nov 2009 07:09:55 +0000
Subject: [issue7393] Executing Python program of sum of 2 nos.
In-Reply-To: <1259132995.34.0.685244860607.issue7393@psf.upfronthosting.co.za>
Message-ID: <1259132995.34.0.685244860607.issue7393@psf.upfronthosting.co.za>


New submission from Mayuresh <mayur_marathe at hotmail.com>:

I am getting error of sum of two nos. the output should give addition 
of two numbers,but instead it is displaying 2 nos. side-by-side.I have 
pasted the program and output for the same.

print "Please give a number: "
a = input()
print "And another: "
b = input()
print "The sum of these numbers is: "
print a + b

output should be a=21,b=21, a+b=42
whereas it is showing 2121.

----------
components: IDLE
messages: 95711
nosy: mayur78
severity: normal
status: open
title: Executing Python program of sum of 2 nos.
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7393>
_______________________________________

From report at bugs.python.org  Wed Nov 25 08:19:23 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 25 Nov 2009 07:19:23 +0000
Subject: [issue7393] Executing Python program of sum of 2 nos.
In-Reply-To: <1259132995.34.0.685244860607.issue7393@psf.upfronthosting.co.za>
Message-ID: <1259133563.74.0.760150763287.issue7393@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

In Python 3.1, the input() function always returns a string.  In your
case, the string is "21".  Adding two strings together gives you a
longer string:  "12" + "34" --> "1234".

To get your program to do what you want, convert the string to a number
using int():

a = int(input('give a number: '))
b = int(input('and another: '))
print('the sum is', a + b)

----------
nosy: +rhettinger
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7393>
_______________________________________

From report at bugs.python.org  Wed Nov 25 10:38:52 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 25 Nov 2009 09:38:52 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1259108078.62.0.683684670103.issue6615@psf.upfronthosting.co.za>
Message-ID: <530222.23376.qm@web25805.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Changes checked into trunk (r76508) - very slightly different to flox's patch. Also made _handlers a WeakValueDictionary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Wed Nov 25 11:41:13 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 25 Nov 2009 10:41:13 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1259145673.87.0.737726446597.issue7117@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Eric.

The only remaining documentation issues I'm aware of are in 
Doc/tutorial/floatingpoint.rst.  I think Raymond is going to update this 
to match the py3k version.

I'll call this done, then!  Thanks for all your help.

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Wed Nov 25 11:45:24 2009
From: report at bugs.python.org (flox)
Date: Wed, 25 Nov 2009 10:45:24 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
Message-ID: <1259145924.48.0.644664364984.issue6615@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Thank you Vinay.

Since you "reversed()" the _handlerList, the following part need to be
changed:

Index: Lib/logging/__init__.py
===================================================================
--- Lib/logging/__init__.py     (revision 76508)
+++ Lib/logging/__init__.py     (working copy)
@@ -610,7 +610,7 @@
     """
     _acquireLock()
     try:
-        _handlerList.insert(0, weakref.ref(handler, _removeHandlerRef))
+        _handlerList.append(weakref.ref(handler, _removeHandlerRef))
     finally:
         _releaseLock()

----------
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Wed Nov 25 13:12:47 2009
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 25 Nov 2009 12:12:47 +0000
Subject: [issue1515] deepcopy doesn't copy instance methods
In-Reply-To: <1196296860.13.0.0113919656838.issue1515@psf.upfronthosting.co.za>
Message-ID: <1259151167.79.0.134358463826.issue1515@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

(I see some time has passed since the last message. I'm assuming the 
issue wasn't fixed, correct me if I'm wrong.)

Here's a use case for using deepcopy: I'm developing a simulations 
framework called GarlicSim, all Python. You can see a short video here: 
http://garlicsim.org/brief_introduction.html
The program handles world states in simulated worlds. Some simpacks 
deepcopy the existing world state to generate the next world state.

This bug is currently preventing me from writing simpacks whose world 
states reference instance methods, which is a severe limitation for me.

I think this issue should be bumped in priority. Also, in the mean time, 
a more informative error message should be given (Like "deepcopy can't 
handle instance methods."), instead of the current cryptic one.

----------
nosy: +cool-RR

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1515>
_______________________________________

From report at bugs.python.org  Wed Nov 25 13:17:29 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 Nov 2009 12:17:29 +0000
Subject: [issue1606092] csv module broken for unicode
Message-ID: <1259151449.04.0.0461489553856.issue1606092@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is indeed fixed in Python 3.  If someone wishes to step forward
with patches for 2.7, they can reopen this bug, but I don't think it is
worth the effort.

----------
nosy: +r.david.murray
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1606092>
_______________________________________

From report at bugs.python.org  Wed Nov 25 15:13:14 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 25 Nov 2009 14:13:14 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1259145924.48.0.644664364984.issue6615@psf.upfronthosting.co.za>
Message-ID: <675179.9198.qm@web25803.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Since you "reversed()" the _handlerList, the following part need to be

> changed:
> 
> -        _handlerList.insert(0, weakref.ref(handler, _removeHandlerRef))
> +        _handlerList.append(weakref.ref(handler, _removeHandlerRef))

Corrected in r76509. Florent, thanks for catching this (and for the patch).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Wed Nov 25 17:39:19 2009
From: report at bugs.python.org (dontbugme)
Date: Wed, 25 Nov 2009 16:39:19 +0000
Subject: [issue7394] sqlite3: some OperationalError exceptions should be
	ProgrammingError (PEP 249)
In-Reply-To: <1259167159.55.0.802533140683.issue7394@psf.upfronthosting.co.za>
Message-ID: <1259167159.55.0.802533140683.issue7394@psf.upfronthosting.co.za>


New submission from dontbugme <pythonbugsbugmenot at spamavert.com>:

The following code raises OperationalError exceptions:
python -c 'import sqlite3; sqlite3.connect(":memory:").execute("bad
syntax")'
python -c 'import sqlite3; sqlite3.connect(":memory:").execute("SELECT *
FROM no_such_table")'
python -c 'import sqlite3; sqlite3.connect(":memory:").execute("SELECT
no_such_column")'

But ProgrammingError should be raised, as per PEP 249:

        ProgrammingError
          
            Exception raised for programming errors, e.g. table not
            found or already exists, syntax error in the SQL
            statement, wrong number of parameters specified, etc.  It
            must be a subclass of DatabaseError.

----------
components: Library (Lib)
messages: 95719
nosy: dontbugme
severity: normal
status: open
title: sqlite3: some OperationalError exceptions should be ProgrammingError (PEP 249)
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7394>
_______________________________________

From report at bugs.python.org  Wed Nov 25 18:01:58 2009
From: report at bugs.python.org (Neil Cerutti)
Date: Wed, 25 Nov 2009 17:01:58 +0000
Subject: [issue7391] Re-title the "Using Backslash to Continue Statements"
	anti-idiom
In-Reply-To: <1259072363.61.0.346322429524.issue7391@psf.upfronthosting.co.za>
Message-ID: <1259168518.2.0.790955510163.issue7391@psf.upfronthosting.co.za>


Neil Cerutti <cerutti at trans-video.net> added the comment:

Yes, I know. That's why I feel it should not be labeled an anti-idiom,
as it currently seems to be.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7391>
_______________________________________

From report at bugs.python.org  Wed Nov 25 18:13:50 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 25 Nov 2009 17:13:50 +0000
Subject: [issue7391] Re-title the "Using Backslash to Continue Statements"
	anti-idiom
In-Reply-To: <1259072363.61.0.346322429524.issue7391@psf.upfronthosting.co.za>
Message-ID: <1259169230.76.0.286867356007.issue7391@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Agreed.

----------
priority:  -> low
resolution: wont fix -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7391>
_______________________________________

From report at bugs.python.org  Wed Nov 25 18:16:46 2009
From: report at bugs.python.org (flox)
Date: Wed, 25 Nov 2009 17:16:46 +0000
Subject: [issue4097] Traceback doesn't run back all the way
In-Reply-To: <1223628877.95.0.314236437557.issue4097@psf.upfronthosting.co.za>
Message-ID: <1259169406.22.0.973964866034.issue4097@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

It looks similar to issue7378, but the latter has more details.

Close as duplicate?

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4097>
_______________________________________

From report at bugs.python.org  Wed Nov 25 18:20:33 2009
From: report at bugs.python.org (flox)
Date: Wed, 25 Nov 2009 17:20:33 +0000
Subject: [issue4158] compilation of sqlite3 fails
In-Reply-To: <1224599787.4.0.032538793853.issue4158@psf.upfronthosting.co.za>
Message-ID: <1259169633.35.0.920600596231.issue4158@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Please close as invalid.

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4158>
_______________________________________

From report at bugs.python.org  Wed Nov 25 18:21:11 2009
From: report at bugs.python.org (flox)
Date: Wed, 25 Nov 2009 17:21:11 +0000
Subject: [issue4158] compilation of sqlite3 fails
In-Reply-To: <1224599787.4.0.032538793853.issue4158@psf.upfronthosting.co.za>
Message-ID: <1259169671.56.0.123254076209.issue4158@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


----------
nosy:  -flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4158>
_______________________________________

From report at bugs.python.org  Wed Nov 25 18:39:56 2009
From: report at bugs.python.org (flox)
Date: Wed, 25 Nov 2009 17:39:56 +0000
Subject: [issue4380] Deepcopy of functools.partial gives wierd exception
In-Reply-To: <1227298848.26.0.43954537451.issue4380@psf.upfronthosting.co.za>
Message-ID: <1259170796.57.0.367937721617.issue4380@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

This issue is somewhat related to the same issue with pickle.
See issue1398 for the explanation.

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4380>
_______________________________________

From report at bugs.python.org  Wed Nov 25 21:01:28 2009
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 25 Nov 2009 20:01:28 +0000
Subject: [issue4158] compilation of sqlite3 fails
In-Reply-To: <1224599787.4.0.032538793853.issue4158@psf.upfronthosting.co.za>
Message-ID: <1259179288.59.0.674474940392.issue4158@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4158>
_______________________________________

From report at bugs.python.org  Wed Nov 25 21:40:17 2009
From: report at bugs.python.org (flox)
Date: Wed, 25 Nov 2009 20:40:17 +0000
Subject: [issue7392] cPickle test failure on release26-maint branch
In-Reply-To: <1259085941.32.0.227872963702.issue7392@psf.upfronthosting.co.za>
Message-ID: <1259181617.03.0.513689742303.issue7392@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

I experienced same failure (trunk is OK).

It seems that r70531 needs backporting.

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7392>
_______________________________________

From report at bugs.python.org  Thu Nov 26 00:04:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 Nov 2009 23:04:51 +0000
Subject: [issue5788] datetime.timedelta is inconvenient to use...
In-Reply-To: <1240079860.62.0.329216013715.issue5788@psf.upfronthosting.co.za>
Message-ID: <1259190291.3.0.399122461916.issue5788@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch is committed in r76529 (trunk) and r76530 (py3k). Thank you!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5788>
_______________________________________

From report at bugs.python.org  Thu Nov 26 00:16:06 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 25 Nov 2009 23:16:06 +0000
Subject: [issue7371] Windows 64-bit build "skips" several projects in VS 2008
In-Reply-To: <1258752248.05.0.167808334648.issue7371@psf.upfronthosting.co.za>
Message-ID: <1259190966.22.0.598414488277.issue7371@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Ok, I found that this issue happens only with RTM version of VS2008. 
The fix is to install SP1. 

ref - http://social.msdn.microsoft.com/Forums/en-US/vssetup/thread/
beb4abe5-b40c-4008-aac4-343f3493e5ba

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7371>
_______________________________________

From report at bugs.python.org  Thu Nov 26 00:32:50 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 Nov 2009 23:32:50 +0000
Subject: [issue2281] Enhanced cPython profiler with high-resolution timer
In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za>
Message-ID: <1259191970.82.0.77039009027.issue2281@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

One issue with using timestamp counters is that their resolution varies
with CPU speed, which is not necessarily constant during a whole run
(because of power management). On the other hand I'm not sure it's
really a problem.

----------
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2281>
_______________________________________

From report at bugs.python.org  Thu Nov 26 00:35:43 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 25 Nov 2009 23:35:43 +0000
Subject: [issue7395] pstats add command raises unhandled exception
In-Reply-To: <1259192143.69.0.167653285401.issue7395@psf.upfronthosting.co.za>
Message-ID: <1259192143.69.0.167653285401.issue7395@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

$ python -m pstats
Welcome to the profile statistics browser.
% help

Documented commands (type help <topic>):
========================================
EOF  add  callees  callers  quit  read  reverse  sort  stats  strip

Undocumented commands:
======================
help

% help add
Add profile info from given file to current statistics object.
% add client.prof
Traceback (most recent call last):
  File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
    exec code in run_globals
  File "/usr/lib/python2.6/pstats.py", line 690, in <module>
    browser.cmdloop()
  File "/usr/lib/python2.6/cmd.py", line 142, in cmdloop
    stop = self.onecmd(line)
  File "/usr/lib/python2.6/cmd.py", line 219, in onecmd
    return func(arg)
  File "/usr/lib/python2.6/pstats.py", line 600, in do_add
    self.stats.add(line)
AttributeError: 'NoneType' object has no attribute 'add'
$

----------
components: Library (Lib)
messages: 95729
nosy: exarkun
severity: normal
status: open
title: pstats add command raises unhandled exception
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7395>
_______________________________________

From report at bugs.python.org  Thu Nov 26 00:58:24 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 Nov 2009 23:58:24 +0000
Subject: [issue1023290] Conversion of longs to bytes and vice-versa.
Message-ID: <1259193504.45.0.891934049565.issue1023290@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The following example is strange:

+        >>> int.from_bytes([255, 0, 0], byteorder='big')
+        -65536

Isn't `signed` supposed to be False by default?
The rest looks ok.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1023290>
_______________________________________

From report at bugs.python.org  Thu Nov 26 02:54:20 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 26 Nov 2009 01:54:20 +0000
Subject: [issue4097] Traceback doesn't run back all the way
In-Reply-To: <1223628877.95.0.314236437557.issue4097@psf.upfronthosting.co.za>
Message-ID: <1259200460.65.0.968467935894.issue4097@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4097>
_______________________________________

From report at bugs.python.org  Thu Nov 26 05:50:15 2009
From: report at bugs.python.org (James G. sack (jim))
Date: Thu, 26 Nov 2009 04:50:15 +0000
Subject: [issue7396] regrtest single: iterator not subscriptable
In-Reply-To: <1259211015.26.0.0435309499535.issue7396@psf.upfronthosting.co.za>
Message-ID: <1259211015.26.0.0435309499535.issue7396@psf.upfronthosting.co.za>


New submission from James G. sack (jim) <jgsack at users.sourceforge.net>:

file Lib/tests/regrtest.py
 
Evidently rev 76260 (trunk) / 76261 (py3k)
broke code at
  rev 76324 line 655 (py3k)
  rev 76321 line 620 (trunk) 
which is
   if tests[0] == alltests[i]  
because tests was rebound from a list to an iterable, and hence indexing 
cannot be performed on tests subsequent to the rebinding.

There are a few other places where tests is indexed, but I suspect those 
places are before the rebinding to an iterable.

At first glance, a viable patch might be to use a different name, eg 
itests, and leave the original tests list available for use by the line 
causing the TypeError. However, I think someone more knowledgeable needs 
to have a look.

Ummm, forgive me if this is offbase, but would it be fair to identify as 
a bad practice, the rebinding of a variable to a different type. 

~jim

----------
messages: 95731
nosy: jgsack
severity: normal
status: open
title: regrtest single: iterator not subscriptable
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7396>
_______________________________________

From report at bugs.python.org  Thu Nov 26 09:13:13 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 26 Nov 2009 08:13:13 +0000
Subject: [issue5788] datetime.timedelta is inconvenient to use...
In-Reply-To: <1240079860.62.0.329216013715.issue5788@psf.upfronthosting.co.za>
Message-ID: <1259223193.59.0.642389849885.issue5788@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

A late note: this would be redundant if the oft-requested division of 
timedeltas were implemented:  t.total_seconds could then be spelt

t/timedelta(seconds=1)

with the advantage that there would then be a natural way to spell 
t.total_days or t.total_hours as well.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5788>
_______________________________________

From report at bugs.python.org  Thu Nov 26 09:14:17 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 26 Nov 2009 08:14:17 +0000
Subject: [issue5788] datetime.timedelta is inconvenient to use...
In-Reply-To: <1240079860.62.0.329216013715.issue5788@psf.upfronthosting.co.za>
Message-ID: <1259223257.06.0.395737386943.issue5788@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

That should be t.total_seconds(), of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5788>
_______________________________________

From report at bugs.python.org  Thu Nov 26 10:38:24 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 26 Nov 2009 09:38:24 +0000
Subject: [issue1023290] Conversion of longs to bytes and vice-versa.
Message-ID: <1259228304.23.0.969311998777.issue1023290@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Looks good to me, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1023290>
_______________________________________

From report at bugs.python.org  Thu Nov 26 10:41:14 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 26 Nov 2009 09:41:14 +0000
Subject: [issue1023290] Conversion of longs to bytes and vice-versa.
Message-ID: <1259228474.87.0.718820745441.issue1023290@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

All tests pass on OS X 10.5/Intel, except that I'm still getting the issue 
6687 test failure.  This needs to be resolved somehow before committing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1023290>
_______________________________________

From report at bugs.python.org  Thu Nov 26 11:21:12 2009
From: report at bugs.python.org (Geoffrey Bache)
Date: Thu, 26 Nov 2009 10:21:12 +0000
Subject: [issue4057] Popen(..., cwd=...) does not set PWD environment variable
In-Reply-To: <1223321283.05.0.79921922605.issue4057@psf.upfronthosting.co.za>
Message-ID: <1259230872.09.0.746724561169.issue4057@psf.upfronthosting.co.za>


Changes by Geoffrey Bache <gjb1002 at users.sourceforge.net>:


----------
nosy: +gjb1002

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4057>
_______________________________________

From report at bugs.python.org  Thu Nov 26 12:33:19 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Nov 2009 11:33:19 +0000
Subject: [issue7397] __import__ docs should reference imputil.import_module
In-Reply-To: <1259235199.82.0.599302527492.issue7397@psf.upfronthosting.co.za>
Message-ID: <1259235199.82.0.599302527492.issue7397@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Fairly straightforward one - __import__ is no longer the preferred tool
for doing runtime imports, so its documentation should point to
imputil.import_module

(this is a little more than just a "see also", some of the existing
wording in the first few paragraphs should also be tweaked)

----------
assignee: georg.brandl
components: Documentation
keywords: easy
messages: 95736
nosy: georg.brandl, ncoghlan
severity: normal
status: open
title: __import__ docs should reference imputil.import_module
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7397>
_______________________________________

From report at bugs.python.org  Thu Nov 26 12:45:30 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Nov 2009 11:45:30 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1259235930.82.0.730022694329.issue6727@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Given that you had to use ctypes to create the symlinks on Windows in
the first place, I'd say you're right :)

Probably the first step would be to make sure the nt OS and path modules
get Windows symlink support (although even that may not be enough, due
to the bootstrapping issues with file access and the import machinery).

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Thu Nov 26 12:59:06 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 26 Nov 2009 11:59:06 +0000
Subject: [issue7397] __import__ docs should reference imputil.import_module
In-Reply-To: <1259235199.82.0.599302527492.issue7397@psf.upfronthosting.co.za>
Message-ID: <1259236746.67.0.651305377762.issue7397@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

According to http://docs.python.org/library/imputil.html, imputil is
deprecated and it has been removed in 3.x. Further, I don't see
import_module in imputil (2.6 or trunk), it's just an example on that
documentation page.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7397>
_______________________________________

From report at bugs.python.org  Thu Nov 26 13:10:34 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Nov 2009 12:10:34 +0000
Subject: [issue7397] __import__ docs should reference importlib.import_module
In-Reply-To: <1259235199.82.0.599302527492.issue7397@psf.upfronthosting.co.za>
Message-ID: <1259237434.93.0.163033405899.issue7397@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

s/imputil/importlib/

Details, details...

----------
title: __import__ docs should reference imputil.import_module -> __import__ docs should reference importlib.import_module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7397>
_______________________________________

From report at bugs.python.org  Thu Nov 26 13:17:25 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 26 Nov 2009 12:17:25 +0000
Subject: [issue5788] datetime.timedelta is inconvenient to use...
In-Reply-To: <1259223193.59.0.642389849885.issue5788@psf.upfronthosting.co.za>
Message-ID: <1259237866.3466.2.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> A late note: this would be redundant if the oft-requested division of 
> timedeltas were implemented:  t.total_seconds could then be spelt
> 
> t/timedelta(seconds=1)

It would be less obvious, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5788>
_______________________________________

From report at bugs.python.org  Thu Nov 26 13:23:48 2009
From: report at bugs.python.org (Paul H)
Date: Thu, 26 Nov 2009 12:23:48 +0000
Subject: [issue7398] Issue with _PyLong_Format while trying to build Python on
	HP-UX itanium
In-Reply-To: <1259238228.23.0.895508664034.issue7398@psf.upfronthosting.co.za>
Message-ID: <1259238228.23.0.895508664034.issue7398@psf.upfronthosting.co.za>


New submission from Paul H <paulh.misc at gmail.com>:

Hello all,

First post here so go easy on me please! And please bear in mind I am
not a C programmer, just a unix admin trying to build python as an
option for other programmers to use.

I am trying to build Python 3.1.1 on HP-UX itanium. OS and compiler
details are as follows:

HP-UX <hostname> B.11.31 U ia64 2812253632 unlimited-user license
aCC: HP C/aC++ B3910B A.06.23 [May 18, 2009]

So far, with the help of this forum and documentation from this and
previous versions of Python, I have been working through the process as
follows:

export CC="/opt/aCC/bin/aCC -Ae +DD64"
export CFLAGS="-Ae +DD64"
export CXX="/opt/aCC/bin/aCC -Ae"
export CXXFLAGS="-Ae +DD64"
export LDFLAGS="+DD64 -L/usr/local/bzip2-1.0.3/lib"
./configure --prefix=<my target>/python/3.1.1 --without-gcc

unset CC CFLAGS CXX CXXFLAGS LDFLAGS
make

I've been working through the various errors I've been getting as best I
can and have hit one that I don't think I can progress:

"Python/../Objects/stringlib/formatter.h", line 1369: error #2140: too many
          arguments in function call
      return _PyLong_Format(value, base, 0, 1);

It looks like _PyLong_Format is defined in Objects/longobject.c.

Any ideas on how to progress this one, or indeed any tips to get a
successful build on my architecture, would be much appreciated.

Many thanks,
Paul.

----------
components: Build
messages: 95741
nosy: paulh_irl
severity: normal
status: open
title: Issue with _PyLong_Format while trying to build Python on HP-UX itanium
type: compile error
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7398>
_______________________________________

From report at bugs.python.org  Thu Nov 26 13:37:38 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 26 Nov 2009 12:37:38 +0000
Subject: [issue7398] Issue with _PyLong_Format while trying to build Python on
	HP-UX itanium
In-Reply-To: <1259238228.23.0.895508664034.issue7398@psf.upfronthosting.co.za>
Message-ID: <1259239058.39.0.0245328468967.issue7398@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

For 3.1, line 1369 of Python/../Objects/stringlib/formatter.h should not
be used. There's a #if on line 1359 that prevents the long_format
function from being used. Could you investigate why that #if is using
the wrong value?

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7398>
_______________________________________

From report at bugs.python.org  Thu Nov 26 13:46:43 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 26 Nov 2009 12:46:43 +0000
Subject: [issue7398] Issue with _PyLong_Format while trying to build Python on
	HP-UX itanium
In-Reply-To: <1259238228.23.0.895508664034.issue7398@psf.upfronthosting.co.za>
Message-ID: <1259239603.48.0.350019050927.issue7398@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

To elaborate on Eric's suggestion, put a single line

top PY_VERSION_HEX bottom

right above the line 

#if PY_VERSION_HEX >= 0x03000000

Then add the flag that produces preprocessor output to the compiler line
(copy the compiler line literally from the build process). Most likely,
you'll have to replace the -c option with either -P or -E; search the
output for the top/bottem pattern, and report the value of PY_VERSION_HEX.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7398>
_______________________________________

From report at bugs.python.org  Thu Nov 26 16:07:09 2009
From: report at bugs.python.org (Philip Semanchuk)
Date: Thu, 26 Nov 2009 15:07:09 +0000
Subject: [issue5725] process SysV-Semaphore support
In-Reply-To: <1239254455.57.0.547868960031.issue5725@psf.upfronthosting.co.za>
Message-ID: <1259248029.66.0.882514551382.issue5725@psf.upfronthosting.co.za>


Philip Semanchuk <osvenskan at users.sourceforge.net> added the comment:

I stumbled across this bug report while looking for an mmap-related
issue. I thought I'd mention that I have a module for SysV IPC that's
about a year old. 

Obviously it's not in the standard library, but it is pretty well
fleshed out. It's in active use and I consider it fairly well debugged. 

It's for Python 2.x only.

http://semanchuk.com/philip/sysv_ipc/

Hope this helps

----------
nosy: +osvenskan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5725>
_______________________________________

From report at bugs.python.org  Thu Nov 26 16:19:06 2009
From: report at bugs.python.org (Paul H)
Date: Thu, 26 Nov 2009 15:19:06 +0000
Subject: [issue7398] Issue with _PyLong_Format while trying to build Python on
	HP-UX itanium
In-Reply-To: <1259238228.23.0.895508664034.issue7398@psf.upfronthosting.co.za>
Message-ID: <1259248746.61.0.0693758951165.issue7398@psf.upfronthosting.co.za>


Paul H <paulh.misc at gmail.com> added the comment:

Hi all,

Many thanks for the tips, and for the super-quick responses also! 

Yes indeed, what is happening here is that PY_VERSION_HEX is not being
evaluated correctly. In fact what appears to be happening is that
Include/patchlevel.h is not being considered in the compile despite
"-IInclude" being on the compiler command line. Perhaps I have a
compiler issue. I'll work it from here.

Thanks again for your help.
Paul.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7398>
_______________________________________

From report at bugs.python.org  Thu Nov 26 16:57:59 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 26 Nov 2009 15:57:59 +0000
Subject: [issue7398] Issue with _PyLong_Format while trying to build Python on
	HP-UX itanium
In-Reply-To: <1259238228.23.0.895508664034.issue7398@psf.upfronthosting.co.za>
Message-ID: <1259251079.85.0.273493764458.issue7398@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I'm going to close this, but if you find the problem (and especially if
you develop a patch to resolve it), please post back here.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7398>
_______________________________________

From report at bugs.python.org  Thu Nov 26 17:02:31 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 26 Nov 2009 16:02:31 +0000
Subject: [issue4057] Popen(..., cwd=...) does not set PWD environment variable
In-Reply-To: <1223321283.05.0.79921922605.issue4057@psf.upfronthosting.co.za>
Message-ID: <1259251351.88.0.732513590501.issue4057@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

In most shells $PWD is a magic variable that is maintained by the shell 
itself. 

IMHO python has no reason to mess with variables that happen to be defined 
by some shells. If subprocess were to set $PWD, os.setuid should set $UID, 
and there may be other magic variables as well.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4057>
_______________________________________

From report at bugs.python.org  Thu Nov 26 17:13:14 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 26 Nov 2009 16:13:14 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1259251994.59.0.306713009881.issue6727@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I agree that a proper solution might include full symlink support.

However, symlink support for windows (issue1578269) is taking some time
to develop and will likely never be available for Python 2.

My feeling is that a symlink naive implementation (such as Python is
now), should treat symlinks in a naive manner -- that is, treat them as
regular files and directories and let the OS perform the abstraction.

I hope to begin investigating this after I've closed out issue1578269,
although I'd be happy if someone else wanted to address this issue
beforehand.

If it's possible to address this in a straightforward way independent of
a symlink-aware Python interpreter, that would be desirable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Thu Nov 26 17:30:26 2009
From: report at bugs.python.org (David Henretty)
Date: Thu, 26 Nov 2009 16:30:26 +0000
Subject: [issue7399] Possible bug in Python Tutorial
In-Reply-To: <1259253026.9.0.615339023248.issue7399@psf.upfronthosting.co.za>
Message-ID: <1259253026.9.0.615339023248.issue7399@psf.upfronthosting.co.za>


New submission from David Henretty <dhenretty at a2etech.com>:

Hi,

In the v3.1.1 Python Tutorial (section 10.7 - Internet Access), the 
sample code (shown below) results in the following error :-

from urllib.request import urlopen
for line in urlopen('http://tycho.usno.navy.mil/cgi-bin/timer.pl'):
     if 'EST' in line or 'EDT' in line:
         print(line)

Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
TypeError: Type str doesn't support the buffer API

I presume this has something to do with the assumed type of the 
variable 'line', but I am very new to Python.

Replacing the 'if' line with the following DOES work :-

     if 'EST' in str(line) or 'EDT' in str(line):

Can anyone confirm / explain this ?

Thanks,

DH

----------
assignee: georg.brandl
components: Documentation
messages: 95749
nosy: dh, georg.brandl
severity: normal
status: open
title: Possible bug in Python Tutorial
type: compile error
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7399>
_______________________________________

From report at bugs.python.org  Thu Nov 26 19:22:38 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 26 Nov 2009 18:22:38 +0000
Subject: [issue7399] Possible bug in Python Tutorial
In-Reply-To: <1259253026.9.0.615339023248.issue7399@psf.upfronthosting.co.za>
Message-ID: <1259259758.43.0.987799791179.issue7399@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The example is indeed wrong.  urlopen is returning an object that emits
binary data.  The error comes from using 'in' on incompatible types. 
The solution is to encode the data with an appropriate encoding, once
you figure out what that is.

----------
nosy: +r.david.murray
priority:  -> normal
stage:  -> needs patch
type: compile error -> behavior
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7399>
_______________________________________

From report at bugs.python.org  Thu Nov 26 19:27:45 2009
From: report at bugs.python.org (Geoffrey Bache)
Date: Thu, 26 Nov 2009 18:27:45 +0000
Subject: [issue4057] Popen(..., cwd=...) does not set PWD environment variable
In-Reply-To: <1223321283.05.0.79921922605.issue4057@psf.upfronthosting.co.za>
Message-ID: <1259260065.63.0.98141409806.issue4057@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

I can see your point, though I think particularly in this case it's
(unfortunately) fairly common that scripts on POSIX platforms read $PWD
instead of finding the current working directory properly. 

I'm probably not the first person that has had to set PWD explicitly in
a python program for this reason. Yes, it's really the fault of the
people who maintain the script I'm calling, but I don't think setting
PWD on POSIX could have any bad effects and should surely be easy to do?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4057>
_______________________________________

From report at bugs.python.org  Thu Nov 26 21:10:41 2009
From: report at bugs.python.org (Renato Cunha)
Date: Thu, 26 Nov 2009 20:10:41 +0000
Subject: [issue7400] Small typo in Python's library documentation: set
In-Reply-To: <1259266241.33.0.106034048132.issue7400@psf.upfronthosting.co.za>
Message-ID: <1259266241.33.0.106034048132.issue7400@psf.upfronthosting.co.za>


New submission from Renato Cunha <renato at renatocunha.com>:

In the documentation of the built-in functions, the description of set
says "Return a new set, optionally with elements ARE taken from
iterable. ...".

The referenced text should be either "... optionally with elements taken
from iterable. ...".

----------
assignee: georg.brandl
components: Documentation
files: set-typo-fix.diff
keywords: patch
messages: 95752
nosy: georg.brandl, trovao
severity: normal
status: open
title: Small typo in Python's library documentation: set
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15399/set-typo-fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7400>
_______________________________________

From report at bugs.python.org  Thu Nov 26 21:48:44 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 26 Nov 2009 20:48:44 +0000
Subject: [issue7400] Small typo in Python's library documentation: set
In-Reply-To: <1259266241.33.0.106034048132.issue7400@psf.upfronthosting.co.za>
Message-ID: <1259268524.14.0.974347032165.issue7400@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r76538.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7400>
_______________________________________

From report at bugs.python.org  Thu Nov 26 22:21:02 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 26 Nov 2009 21:21:02 +0000
Subject: [issue7397] __import__ docs should reference importlib.import_module
In-Reply-To: <1259235199.82.0.599302527492.issue7397@psf.upfronthosting.co.za>
Message-ID: <1259270462.09.0.749557395827.issue7397@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7397>
_______________________________________

From report at bugs.python.org  Thu Nov 26 23:58:21 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 26 Nov 2009 22:58:21 +0000
Subject: [issue6845] Restart support in binary upload for ftplib
In-Reply-To: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>
Message-ID: <1259276301.94.0.0475704045735.issue6845@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Now that FTP_TLS has been integrated into the trunk, the patch should be
augmented in order to also cover that class. Right now a test is failing:

======================================================================
ERROR: test_storbinary_rest (test.test_ftplib.TestTLS_FTPClassMixin)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_ftplib.py", line
485, in test_storbinary_rest
    self.client.storbinary('stor', f, rest=r)
TypeError: storbinary() got an unexpected keyword argument 'rest'

Apart from that, the patch looks ok.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6845>
_______________________________________

From report at bugs.python.org  Fri Nov 27 00:22:25 2009
From: report at bugs.python.org (Hugh Secker-Walker)
Date: Thu, 26 Nov 2009 23:22:25 +0000
Subject: [issue7401] os.write and os.close on pipe from separate threads hangs
	on Mac OS X
In-Reply-To: <1259277745.82.0.939130045667.issue7401@psf.upfronthosting.co.za>
Message-ID: <1259277745.82.0.939130045667.issue7401@psf.upfronthosting.co.za>


New submission from Hugh Secker-Walker <hughsw at users.sourceforge.net>:

The attached script demonstrates a problem on Mac OS X 10.5 whereby
Python can hang while simultaneously trying os.write with a large buffer
and os.close, from separate threads on the write and read fds
respectively of a pipe.

----------
components: IO
files: os_pipe_write_close_bug.py
messages: 95755
nosy: hughsw
severity: normal
status: open
title: os.write and os.close on pipe from separate threads hangs on Mac OS X
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15400/os_pipe_write_close_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7401>
_______________________________________

From report at bugs.python.org  Fri Nov 27 00:40:19 2009
From: report at bugs.python.org (Pablo Mouzo)
Date: Thu, 26 Nov 2009 23:40:19 +0000
Subject: [issue6845] Restart support in binary upload for ftplib
In-Reply-To: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>
Message-ID: <1259278819.36.0.649230953109.issue6845@psf.upfronthosting.co.za>


Changes by Pablo Mouzo <pablomouzo at gmail.com>:


Removed file: http://bugs.python.org/file15302/issue6845-trunk.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6845>
_______________________________________

From report at bugs.python.org  Fri Nov 27 00:43:27 2009
From: report at bugs.python.org (Pablo Mouzo)
Date: Thu, 26 Nov 2009 23:43:27 +0000
Subject: [issue6845] Restart support in binary upload for ftplib
In-Reply-To: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>
Message-ID: <1259279007.06.0.190900805556.issue6845@psf.upfronthosting.co.za>


Pablo Mouzo <pablomouzo at gmail.com> added the comment:

Thanks Antoine, I'm attaching both patches. Now the test isn't failing.

----------
Added file: http://bugs.python.org/file15401/issue6845-trunk.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6845>
_______________________________________

From report at bugs.python.org  Fri Nov 27 00:43:50 2009
From: report at bugs.python.org (Pablo Mouzo)
Date: Thu, 26 Nov 2009 23:43:50 +0000
Subject: [issue6845] Restart support in binary upload for ftplib
In-Reply-To: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>
Message-ID: <1259279030.24.0.867925165763.issue6845@psf.upfronthosting.co.za>


Changes by Pablo Mouzo <pablomouzo at gmail.com>:


Added file: http://bugs.python.org/file15402/issue6845-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6845>
_______________________________________

From report at bugs.python.org  Fri Nov 27 02:40:32 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 27 Nov 2009 01:40:32 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1259286032.18.0.778421879418.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Thanks Eric for the report. I had tested earlier on XP, but didn't do so
with the latest changes. It appears that a couple of modules didn't
behave well under XP. The latest patch (16) addresses these issues. In
particular, many tests use the presence of os.symlink to presume
symbolic link support, but under Windows XP, os.symlink exists but
raises a NotImplementedError when called. To address this, I added
test.support.has_symlink function which can be used to determine whether
the OS has symlink support (and not just a symlink function).

This raises the issue that it might be worthwhile to remove the symlink
and readlink methods at the os module init time if symlinks aren't
supported on the OS.

For now, this implementation should be adequate to move forward.

----------
Added file: http://bugs.python.org/file15403/windows symlink draft 16.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Fri Nov 27 04:19:40 2009
From: report at bugs.python.org (Hugh Secker-Walker)
Date: Fri, 27 Nov 2009 03:19:40 +0000
Subject: [issue7401] os.write and os.close on pipe from separate threads hangs
	on Mac OS X
In-Reply-To: <1259277745.82.0.939130045667.issue7401@psf.upfronthosting.co.za>
Message-ID: <1259291980.61.0.839130051822.issue7401@psf.upfronthosting.co.za>


Changes by Hugh Secker-Walker <hughsw at users.sourceforge.net>:


----------
versions: +Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7401>
_______________________________________

From report at bugs.python.org  Fri Nov 27 04:20:28 2009
From: report at bugs.python.org (Hugh Secker-Walker)
Date: Fri, 27 Nov 2009 03:20:28 +0000
Subject: [issue7401] os.write and os.close on pipe from separate threads hangs
	on Mac OS X
In-Reply-To: <1259277745.82.0.939130045667.issue7401@psf.upfronthosting.co.za>
Message-ID: <1259292028.05.0.212358240021.issue7401@psf.upfronthosting.co.za>


Changes by Hugh Secker-Walker <hughsw at users.sourceforge.net>:


----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7401>
_______________________________________

From report at bugs.python.org  Fri Nov 27 08:23:04 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 27 Nov 2009 07:23:04 +0000
Subject: [issue4057] Popen(..., cwd=...) does not set PWD environment variable
In-Reply-To: <1259260065.63.0.98141409806.issue4057@psf.upfronthosting.co.za>
Message-ID: <89B90235-CDA6-47A1-BB51-4CBF82880C9A@mac.com>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

On 26 Nov, 2009, at 19:27, Geoffrey Bache wrote:

> 
> Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:
> 
> I can see your point, though I think particularly in this case it's
> (unfortunately) fairly common that scripts on POSIX platforms read $PWD
> instead of finding the current working directory properly. 
> 
> I'm probably not the first person that has had to set PWD explicitly in
> a python program for this reason. Yes, it's really the fault of the
> people who maintain the script I'm calling, but I don't think setting
> PWD on POSIX could have any bad effects and should surely be easy to do?

Shouldn't the script set $PWD itself? AFAIK shells like bash will set $PWD regardless of whether they are running as an interactive shell or as a shellscript.

Reading os.environ['PWD'] in a Python script not a good example of whey the proposed functionality might be useful because there are a number of ways to change the current working directory without affecting os.environ. For example using os.chdir, or even an extensions that calls the chdir system call directly.

Ronald

----------
Added file: http://bugs.python.org/file15404/smime.p7s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4057>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20091127/32cbbbf2/attachment-0001.bin>

From report at bugs.python.org  Fri Nov 27 08:41:26 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 27 Nov 2009 07:41:26 +0000
Subject: [issue7401] os.write and os.close on pipe from separate threads hangs
	on Mac OS X
In-Reply-To: <1259277745.82.0.939130045667.issue7401@psf.upfronthosting.co.za>
Message-ID: <1259307686.92.0.495011956906.issue7401@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Why do you think this is a bug in Python, and not an operating system
bug? I.e. if you would redo the script in C, would it still hang?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7401>
_______________________________________

From report at bugs.python.org  Fri Nov 27 10:54:49 2009
From: report at bugs.python.org (Robert Collins)
Date: Fri, 27 Nov 2009 09:54:49 +0000
Subject: [issue1515] deepcopy doesn't copy instance methods
In-Reply-To: <1196296860.13.0.0113919656838.issue1515@psf.upfronthosting.co.za>
Message-ID: <1259315689.26.0.753250744156.issue1515@psf.upfronthosting.co.za>


Robert Collins <robertc at robertcollins.net> added the comment:

Ran into this trying to do some test isolation stuff.

Notwithstanding the questions about 'why', this is a clear limitation
hat can be solved quite simply - is there any harm that will occur if we
fix it?

I've attached a patch, with a test (in the style of the current tests)
which shows the copy works correctly.

----------
keywords: +patch
nosy: +rbcollins
Added file: http://bugs.python.org/file15405/issue1515.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1515>
_______________________________________

From report at bugs.python.org  Fri Nov 27 10:55:23 2009
From: report at bugs.python.org (Robert Collins)
Date: Fri, 27 Nov 2009 09:55:23 +0000
Subject: [issue1515] deepcopy doesn't copy instance methods
In-Reply-To: <1196296860.13.0.0113919656838.issue1515@psf.upfronthosting.co.za>
Message-ID: <1259315723.65.0.236488006847.issue1515@psf.upfronthosting.co.za>


Robert Collins <robertc at robertcollins.net> added the comment:

This affects 2.7 too.

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1515>
_______________________________________

From report at bugs.python.org  Fri Nov 27 11:47:22 2009
From: report at bugs.python.org (Christoph Zwerschke)
Date: Fri, 27 Nov 2009 10:47:22 +0000
Subject: [issue7402] reduce() is an anti-example in "Idioms and Anti-Idioms"
In-Reply-To: <1259318842.77.0.740725384087.issue7402@psf.upfronthosting.co.za>
Message-ID: <1259318842.77.0.740725384087.issue7402@psf.upfronthosting.co.za>


New submission from Christoph Zwerschke <cito at online.de>:

In the section "Using the batteries" of the "Idioms and Anti-Idioms in
Python" document
(http://docs.python.org/dev/howto/doanddont.html#using-the-batteries),
the reduce statement is used for summing up numbers as an example. I
think this is rather an anti-example, because Python already has a sum
function built-in, i.e. reduce(operator.add, nums)/len(nums) can be
written much simpler as sum(nums)/len(nums).

----------
assignee: georg.brandl
components: Documentation
messages: 95762
nosy: cito, georg.brandl
severity: normal
status: open
title: reduce() is an anti-example in "Idioms and Anti-Idioms"
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7402>
_______________________________________

From report at bugs.python.org  Fri Nov 27 12:27:20 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 27 Nov 2009 11:27:20 +0000
Subject: [issue7401] os.write and os.close on pipe from separate threads hangs
	on Mac OS X
In-Reply-To: <1259277745.82.0.939130045667.issue7401@psf.upfronthosting.co.za>
Message-ID: <1259321240.62.0.616807302429.issue7401@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I agree with martin, this is probably an OS bug. 

BTW. I can confirm that the issue occurs on OSX 10.6 as well (using the 
binary 2.6.4 installer on the python.org website).

I might get around to writing a C equivalent of the script in the future, 
but wouldn't mind if someone else did that work.  Such a script would 
pinpoint if the problem is in the OS or Python, and if it is in the OS it 
would allow filing a clear bug report at Apple.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7401>
_______________________________________

From report at bugs.python.org  Fri Nov 27 12:42:41 2009
From: report at bugs.python.org (Gavin Panella)
Date: Fri, 27 Nov 2009 11:42:41 +0000
Subject: [issue7403] Race condition in logging._acquireLock()?
In-Reply-To: <1259322161.32.0.385116687037.issue7403@psf.upfronthosting.co.za>
Message-ID: <1259322161.32.0.385116687037.issue7403@psf.upfronthosting.co.za>


New submission from Gavin Panella <gavin at gromper.net>:

The logging module create a global _lock in what looks like a
thread-unsafe manner:

{{{
_lock = None

def _acquireLock():
    """
    Acquire the module-level lock for serializing access to shared data.

    This should be released with _releaseLock().
    """
    global _lock
    if (not _lock) and thread:
        _lock = threading.RLock()
    if _lock:
        _lock.acquire()
}}}

If two threads call _acquireLock() at the same time, and _lock is
None, it's possible that two locks will be created, one of which will
get clobbered.

I think the above could be made thread-safe if written as:

{{{
if thread:
    _lock = threading.RLock()
else:
    _lock = None

def _acquireLock():
    """
    Acquire the module-level lock for serializing access to shared data.

    This should be released with _releaseLock().
    """
    if _lock:
        _lock.acquire()
}}}

----------
components: Library (Lib)
messages: 95764
nosy: allenap
severity: normal
status: open
title: Race condition in logging._acquireLock()?
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7403>
_______________________________________

From report at bugs.python.org  Fri Nov 27 12:44:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Nov 2009 11:44:40 +0000
Subject: [issue7403] Race condition in logging._acquireLock()?
In-Reply-To: <1259322161.32.0.385116687037.issue7403@psf.upfronthosting.co.za>
Message-ID: <1259322280.81.0.0975793259055.issue7403@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> vinay.sajip
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7403>
_______________________________________

From report at bugs.python.org  Fri Nov 27 14:25:22 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Nov 2009 13:25:22 +0000
Subject: [issue6845] Restart support in binary upload for ftplib
In-Reply-To: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>
Message-ID: <1259328322.91.0.77376999123.issue6845@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch has been committed in r76546 and r76547. Thank you for your
contribution!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6845>
_______________________________________

From report at bugs.python.org  Fri Nov 27 14:39:04 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 27 Nov 2009 13:39:04 +0000
Subject: [issue1515] deepcopy doesn't copy instance methods
In-Reply-To: <1196296860.13.0.0113919656838.issue1515@psf.upfronthosting.co.za>
Message-ID: <1259329144.93.0.210384319859.issue1515@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Robert's patch looks fine to me.  My concern is changing this in a point
release (e.g. 2.6.5).  I know Guido said he was fine for this going into
2.6 but that was in January 08, before 2.6 final was released in October
08.  At this point, the question is whether this is safe to change in a
patch release or whether this needs to go in 2.7.

Probably a question for python-dev.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1515>
_______________________________________

From report at bugs.python.org  Fri Nov 27 14:47:33 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Nov 2009 13:47:33 +0000
Subject: [issue1515] deepcopy doesn't copy instance methods
In-Reply-To: <1196296860.13.0.0113919656838.issue1515@psf.upfronthosting.co.za>
Message-ID: <1259329653.35.0.678421423831.issue1515@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The test should be a real unittest in Lib/test/test_copy, not something
in the __main__ section of Lib/copy.py. Nobody runs these, as a matter
of fact if you run Lib/copy.py under the py3k branch it fails.

To nitpick a bit, I also think Michael's test above was better, since it
was checking whether the copied method actually worked.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1515>
_______________________________________

From report at bugs.python.org  Fri Nov 27 14:58:42 2009
From: report at bugs.python.org (Hugh Secker-Walker)
Date: Fri, 27 Nov 2009 13:58:42 +0000
Subject: [issue7401] os.write and os.close on pipe from separate threads hangs
	on Mac OS X
In-Reply-To: <1259277745.82.0.939130045667.issue7401@psf.upfronthosting.co.za>
Message-ID: <1259330322.09.0.565364459061.issue7401@psf.upfronthosting.co.za>


Hugh Secker-Walker <hughsw at users.sourceforge.net> added the comment:

Well, from *my* perspective it's a Python bug because I code to Python's
API and Python misbehaves! ;-)  

If I start on it soon enough I'll look into duplicating the problem in C.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7401>
_______________________________________

From report at bugs.python.org  Fri Nov 27 15:04:44 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 27 Nov 2009 14:04:44 +0000
Subject: [issue7403] Race condition in logging._acquireLock()?
In-Reply-To: <1259322280.88.0.347413742944.issue7403@psf.upfronthosting.co.za>
Message-ID: <809694.22093.qm@web25803.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Thanks Gavin, fix checked into trunk, py3k and release26-maint (r76551).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7403>
_______________________________________

From report at bugs.python.org  Fri Nov 27 15:05:39 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 27 Nov 2009 14:05:39 +0000
Subject: [issue7403] Race condition in logging._acquireLock()?
In-Reply-To: <1259322161.32.0.385116687037.issue7403@psf.upfronthosting.co.za>
Message-ID: <1259330739.52.0.484175477299.issue7403@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7403>
_______________________________________

From report at bugs.python.org  Fri Nov 27 15:13:10 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 27 Nov 2009 14:13:10 +0000
Subject: [issue6508] expose setresuid
In-Reply-To: <1247869532.62.0.249757468331.issue6508@psf.upfronthosting.co.za>
Message-ID: <1259331190.07.0.379173651227.issue6508@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I have now added documentation to os.rst, and committed the patch as
r76550 and r76552.

Thanks for contributing it.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6508>
_______________________________________

From report at bugs.python.org  Fri Nov 27 15:25:33 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Nov 2009 14:25:33 +0000
Subject: [issue5725] process SysV-Semaphore support
In-Reply-To: <1239254455.57.0.547868960031.issue5725@psf.upfronthosting.co.za>
Message-ID: <1259331933.08.0.898161530794.issue5725@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

jvdias, have you looked at what the multiprocessing module offers?
http://docs.python.org/library/multiprocessing.html#synchronization-primitives

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5725>
_______________________________________

From report at bugs.python.org  Fri Nov 27 16:00:48 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 27 Nov 2009 15:00:48 +0000
Subject: [issue7401] os.write and os.close on pipe from separate threads hangs
	on Mac OS X
In-Reply-To: <1259277745.82.0.939130045667.issue7401@psf.upfronthosting.co.za>
Message-ID: <1259334048.8.0.347852787648.issue7401@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Hugh, for us as Python maintainers there is a distinction between issues 
with the Python implementation itself and those outside of Python. The 
former we can solve, the latter not. 

At best we can work around issues in the environment (I've recently 
committed a workaround for what basically amounts to a platform issue on 
OSX that caused crashes when importing an extension on a thread), but 
that's not always possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7401>
_______________________________________

From report at bugs.python.org  Fri Nov 27 19:42:45 2009
From: report at bugs.python.org (Geoffrey Bache)
Date: Fri, 27 Nov 2009 18:42:45 +0000
Subject: [issue4057] Popen(..., cwd=...) does not set PWD environment variable
In-Reply-To: <1223321283.05.0.79921922605.issue4057@psf.upfronthosting.co.za>
Message-ID: <1259347365.04.0.277434807562.issue4057@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

You misunderstand: I am not reading $PWD. I need to call a C program as
a subprocess, which is written by a third party and which determines its
current working directory by reading $PWD. os.chdir will not have any
effect on this script, nor will passing "cwd" to "subprocess.call". I
have to write os.environ["PWD"] = os.getcwd() in my code before it will
work.

Not only that, but of course I have to know about $PWD and the fact that
some people use it. Otherwise it just seems like Python isn't correctly
passing on the current working directory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4057>
_______________________________________

From report at bugs.python.org  Fri Nov 27 21:08:49 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 27 Nov 2009 20:08:49 +0000
Subject: [issue7402] reduce() is an anti-example in "Idioms and Anti-Idioms"
In-Reply-To: <1259318842.77.0.740725384087.issue7402@psf.upfronthosting.co.za>
Message-ID: <1259352529.36.0.438244985533.issue7402@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: georg.brandl -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7402>
_______________________________________

From report at bugs.python.org  Fri Nov 27 21:39:31 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 27 Nov 2009 20:39:31 +0000
Subject: [issue7403] Race condition in logging._acquireLock()?
In-Reply-To: <1259322161.32.0.385116687037.issue7403@psf.upfronthosting.co.za>
Message-ID: <1259354371.13.0.448939113556.issue7403@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fixes now also in release24-maint and release25-maint (as of r76555).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7403>
_______________________________________

From report at bugs.python.org  Fri Nov 27 22:24:33 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Nov 2009 21:24:33 +0000
Subject: [issue4057] Popen(..., cwd=...) does not set PWD environment variable
In-Reply-To: <1223321283.05.0.79921922605.issue4057@psf.upfronthosting.co.za>
Message-ID: <1259357073.62.0.777452546899.issue4057@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

What if you pass shell=True to the subprocess call?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4057>
_______________________________________

From report at bugs.python.org  Fri Nov 27 23:25:07 2009
From: report at bugs.python.org (Robert Collins)
Date: Fri, 27 Nov 2009 22:25:07 +0000
Subject: [issue1515] deepcopy doesn't copy instance methods
In-Reply-To: <1196296860.13.0.0113919656838.issue1515@psf.upfronthosting.co.za>
Message-ID: <1259360707.83.0.693425244986.issue1515@psf.upfronthosting.co.za>


Robert Collins <robertc at robertcollins.net> added the comment:

@Antoine, I agree that the tests for copy should be a proper unit test;
that seems orthogonal to this patch though :)

I don't have a checkout of 3 at the moment, but do you think the test
failure on 3 is shallow or deep?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1515>
_______________________________________

From report at bugs.python.org  Fri Nov 27 23:40:37 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Nov 2009 22:40:37 +0000
Subject: [issue1515] deepcopy doesn't copy instance methods
In-Reply-To: <1259360707.83.0.693425244986.issue1515@psf.upfronthosting.co.za>
Message-ID: <1259361658.3418.3.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> @Antoine, I agree that the tests for copy should be a proper unit test;
> that seems orthogonal to this patch though :)

Not really, since Lib/test/test_copy.py exists and contains tests for
deepcopy; you should add the new test there.

> I don't have a checkout of 3 at the moment, but do you think the test
> failure on 3 is shallow or deep?

What I mean is that Lib/copy.py fails without your changes under py3k.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1515>
_______________________________________

From report at bugs.python.org  Sat Nov 28 00:05:09 2009
From: report at bugs.python.org (Robert Collins)
Date: Fri, 27 Nov 2009 23:05:09 +0000
Subject: [issue1515] deepcopy doesn't copy instance methods
In-Reply-To: <1196296860.13.0.0113919656838.issue1515@psf.upfronthosting.co.za>
Message-ID: <1259363109.18.0.185062607719.issue1515@psf.upfronthosting.co.za>


Robert Collins <robertc at robertcollins.net> added the comment:

Oh man, I looked for a regular unit test - sorry that I missed it. Bah.

I've added a call to the method and moved it into test_copy.

----------
Added file: http://bugs.python.org/file15406/issue1515.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1515>
_______________________________________

From report at bugs.python.org  Sat Nov 28 00:59:38 2009
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 Nov 2009 23:59:38 +0000
Subject: [issue2811] doctest doesn't treat unicode literals as specified by
	the file declared encoding
In-Reply-To: <1210445230.87.0.512222933205.issue2811@psf.upfronthosting.co.za>
Message-ID: <1259366378.4.0.0312028054666.issue2811@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +Merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2811>
_______________________________________

From report at bugs.python.org  Sat Nov 28 01:00:12 2009
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 28 Nov 2009 00:00:12 +0000
Subject: [issue1293741] doctest runner cannot handle non-ascii characters
Message-ID: <1259366412.1.0.928806667068.issue1293741@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +Merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1293741>
_______________________________________

From report at bugs.python.org  Sat Nov 28 03:01:59 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 28 Nov 2009 02:01:59 +0000
Subject: [issue1515] deepcopy doesn't copy instance methods
In-Reply-To: <1196296860.13.0.0113919656838.issue1515@psf.upfronthosting.co.za>
Message-ID: <1259373719.68.0.00610460937908.issue1515@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Smells like a feature to me.

"Bug" == "coding error"

"Feature" == "change in (documented or intended) behavior"

I'm fine with this going into 2.7 / 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1515>
_______________________________________

From report at bugs.python.org  Sat Nov 28 04:12:46 2009
From: report at bugs.python.org (Mark Roddy)
Date: Sat, 28 Nov 2009 03:12:46 +0000
Subject: [issue7404] optparse Documentation References Example Files that do
	not Exist
In-Reply-To: <1259377966.36.0.486259270616.issue7404@psf.upfronthosting.co.za>
Message-ID: <1259377966.36.0.486259270616.issue7404@psf.upfronthosting.co.za>


New submission from Mark Roddy <markroddy at gmail.com>:

In the 'Terminology' section of the optparse module documentation, under
the description of the term 'required option', a reference to example
implementations of this concept are stated to be available in two
example files of the source distribution:

"See examples/required_1.py and examples/required_2.py in the optparse
source distribution for two ways to implement required options with
optparse."

These two files do not appear to have ever been available with python 
but are found in the original 'Optik' distribution that this module is
derived from.  I am guessing that this is a result of the documentation
being copied when the module was added to the standard library as it
also appears in the Optik documentation almost verbatim:
http://optik.sourceforge.net/doc/1.5/tao.html

Suggest the reference to these files:
1) Be removed as to prevent confusion as to their existence/location
2) Be updated to point to the Optik source on source forge
3) Merge the examples in line with the documentation
or
4) Some other option I have not thought of

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 95780
nosy: MarkRoddy, georg.brandl
severity: normal
status: open
title: optparse Documentation References Example Files that do not Exist
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7404>
_______________________________________

From report at bugs.python.org  Sat Nov 28 04:59:28 2009
From: report at bugs.python.org (Mark Roddy)
Date: Sat, 28 Nov 2009 03:59:28 +0000
Subject: [issue7404] optparse Documentation References Example Files that do
	not Exist
In-Reply-To: <1259377966.36.0.486259270616.issue7404@psf.upfronthosting.co.za>
Message-ID: <1259380768.41.0.731568455848.issue7404@psf.upfronthosting.co.za>


Mark Roddy <markroddy at gmail.com> added the comment:

Patch which removes reference to example_1.py and example_2.py

----------
keywords: +patch
Added file: http://bugs.python.org/file15407/remove-reference.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7404>
_______________________________________

From report at bugs.python.org  Sat Nov 28 05:01:04 2009
From: report at bugs.python.org (Mark Roddy)
Date: Sat, 28 Nov 2009 04:01:04 +0000
Subject: [issue7404] optparse Documentation References Example Files that do
	not Exist
In-Reply-To: <1259377966.36.0.486259270616.issue7404@psf.upfronthosting.co.za>
Message-ID: <1259380864.71.0.843712488059.issue7404@psf.upfronthosting.co.za>


Mark Roddy <markroddy at gmail.com> added the comment:

Patch which references the original optik module when referring to
example required option modules.

----------
Added file: http://bugs.python.org/file15408/reference-optik.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7404>
_______________________________________

From report at bugs.python.org  Sat Nov 28 05:03:00 2009
From: report at bugs.python.org (Mark Roddy)
Date: Sat, 28 Nov 2009 04:03:00 +0000
Subject: [issue7404] optparse Documentation References Example Files that do
	not Exist
In-Reply-To: <1259377966.36.0.486259270616.issue7404@psf.upfronthosting.co.za>
Message-ID: <1259380980.56.0.118450657495.issue7404@psf.upfronthosting.co.za>


Mark Roddy <markroddy at gmail.com> added the comment:

Patch takes the contents of required_1.py from the optik source adds it
in the optparse documentation as well as removing references to the two
files.

----------
Added file: http://bugs.python.org/file15409/example-inline.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7404>
_______________________________________

From report at bugs.python.org  Sat Nov 28 06:41:14 2009
From: report at bugs.python.org (jeff deifik)
Date: Sat, 28 Nov 2009 05:41:14 +0000
Subject: [issue7405] compiling python 3.1.1 using cygwin 1.7.0 and gcc 4.3.4
In-Reply-To: <1259386873.79.0.422049105742.issue7405@psf.upfronthosting.co.za>
Message-ID: <1259386873.79.0.422049105742.issue7405@psf.upfronthosting.co.za>


New submission from jeff deifik <jeff at jeffunit.com>:

In order to compile 3.1.1 with the cygwin environment, it was necessary
to edit Modules/main.c after running configure

There are a few tests that still fail when running 'make test', but
overall, python 3.1.1 works fine.

Included is the context diff.

----------
components: Build
files: the_diff.txt
messages: 95784
nosy: lopgok
severity: normal
status: open
title: compiling python 3.1.1 using cygwin 1.7.0 and gcc 4.3.4
versions: Python 3.1
Added file: http://bugs.python.org/file15410/the_diff.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7405>
_______________________________________

From report at bugs.python.org  Sat Nov 28 11:27:32 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 28 Nov 2009 10:27:32 +0000
Subject: [issue7272] test_multiprocessing fails consistently with 'signal 12'
	on FreeBSD 6.2 buildbot.
In-Reply-To: <1257523034.1.0.340985846807.issue7272@psf.upfronthosting.co.za>
Message-ID: <1259404052.95.0.935103140193.issue7272@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  It seems that hijacking the existing HAVE_BROKEN_POSIX_SEMAPHORES 
wasn't a good idea.  I was surprised to find that OS X defines 
_POSIX_SEMAPHORES to -1, indicating a lack of POSIX semaphore support.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7272>
_______________________________________

From report at bugs.python.org  Sat Nov 28 11:45:06 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 28 Nov 2009 10:45:06 +0000
Subject: [issue7272] test_multiprocessing fails consistently with 'signal 12'
	on FreeBSD 6.2 buildbot.
In-Reply-To: <1257523034.1.0.340985846807.issue7272@psf.upfronthosting.co.za>
Message-ID: <1259405106.09.0.875096401415.issue7272@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Variable clash should be fixed in r76558.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7272>
_______________________________________

From report at bugs.python.org  Sat Nov 28 13:54:26 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 28 Nov 2009 12:54:26 +0000
Subject: [issue7272] test_multiprocessing fails consistently with 'signal 12'
	on FreeBSD 6.2 buildbot.
In-Reply-To: <1257523034.1.0.340985846807.issue7272@psf.upfronthosting.co.za>
Message-ID: <1259412866.18.0.44554466676.issue7272@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Merged to py3k, release31-maint in r76566, r76567.

David, I think we're ready to enable POSIX semaphore support on the 
FreeBSD 7.2 buildbot now, if you get the chance.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7272>
_______________________________________

From report at bugs.python.org  Sat Nov 28 15:43:53 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 28 Nov 2009 14:43:53 +0000
Subject: [issue7048] decimal.py: logb: round the result if it is greater than
	prec
In-Reply-To: <1254577997.92.0.263128195563.issue7048@psf.upfronthosting.co.za>
Message-ID: <1259419433.87.0.428098457526.issue7048@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

There's a restriction on the second argument to scaleb in the spec, 
namely that scaleb should be in the range -2*(Emax + precision) to 
2*(Emax + precision) inclusive.

This restriction seems entirely arbitrary and unnecessary to me.  My
guess is that it's there to ease implementation in low-level languages, 
but it makes little sense for the Python implementation.

Here's a patch that removes this restriction on scaleb in the Python 
implementation, and skips the corresponding tests.

----------
Added file: http://bugs.python.org/file15411/scaleb.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7048>
_______________________________________

From report at bugs.python.org  Sat Nov 28 16:19:58 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 28 Nov 2009 15:19:58 +0000
Subject: [issue7098] g formatting for decimal types should always strip
	trailing zeros.
In-Reply-To: <1255198932.03.0.979291900289.issue7098@psf.upfronthosting.co.za>
Message-ID: <1259421598.95.0.980866528232.issue7098@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
components: +Documentation -Library (Lib)
priority: normal -> low
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7098>
_______________________________________

From report at bugs.python.org  Sat Nov 28 16:36:20 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 28 Nov 2009 15:36:20 +0000
Subject: [issue7046] decimal.py: use DivisionImpossible and DivisionUndefined
In-Reply-To: <1254576656.46.0.369353081628.issue7046@psf.upfronthosting.co.za>
Message-ID: <1259422580.67.0.791900725863.issue7046@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I think it's actually easier for the user if we keep the exception type 
as it is, so that it's clear which flag it corresponds to.  This didn't 
occur to me until I looked at the section of the doctests (around line 
100 in decimal.py) that looks like:

>>> print c.divide(Decimal(0), Decimal(0))
Traceback (most recent call last):
  ...
  ...
  ...
InvalidOperation: 0 / 0
>>> print c.flags[InvalidOperation]
1

If the traceback specified 'DivisionUndefined' instead then the user has 
to figure out that the corresponding flag/trap is InvalidOperation.

Of course this could be worked around by giving a more detailed error 
message, e.g. DivisionUndefined: (InvalidOperation) 0/0, but this 
doesn't seem worth changing to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7046>
_______________________________________

From report at bugs.python.org  Sat Nov 28 16:45:31 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 28 Nov 2009 15:45:31 +0000
Subject: [issue1515] deepcopy doesn't copy instance methods
In-Reply-To: <1196296860.13.0.0113919656838.issue1515@psf.upfronthosting.co.za>
Message-ID: <1259423131.39.0.483112753667.issue1515@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Guido - agreed!  Versions updated.

----------
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1515>
_______________________________________

From report at bugs.python.org  Sat Nov 28 16:54:40 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 28 Nov 2009 15:54:40 +0000
Subject: [issue7048] decimal.py: logb: round the result if it is greater than
	prec
In-Reply-To: <1254577997.92.0.263128195563.issue7048@psf.upfronthosting.co.za>
Message-ID: <1259423680.31.0.201313992788.issue7048@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
priority: high -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7048>
_______________________________________

From report at bugs.python.org  Sat Nov 28 16:59:34 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 28 Nov 2009 15:59:34 +0000
Subject: [issue1515] deepcopy doesn't copy instance methods
In-Reply-To: <1196296860.13.0.0113919656838.issue1515@psf.upfronthosting.co.za>
Message-ID: <1259423974.61.0.15256421857.issue1515@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch has been committed in r76571 (trunk) and r76572 (py3k). Thank you!

----------
resolution: accepted -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1515>
_______________________________________

From report at bugs.python.org  Sat Nov 28 17:01:05 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 28 Nov 2009 16:01:05 +0000
Subject: [issue3944] faster long multiplication
In-Reply-To: <1222165559.78.0.447355238601.issue3944@psf.upfronthosting.co.za>
Message-ID: <1259424065.39.0.0516374533376.issue3944@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm going to close this: it's a really nice idea, but after the 30-bit 
long digits were implemented, the speedup doesn't seem to be worth the 
extra code complication.

The only situation I've found where this optimization really does make a 
big difference is when using 60-bit digits, but allowing those in Python 
would take a bit more work (essentially because it requires using some 
inline assembler to get at the CPU widening multiply and 128-bit-by-64-bit 
division instructions).

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3944>
_______________________________________

From report at bugs.python.org  Sat Nov 28 17:16:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 28 Nov 2009 16:16:43 +0000
Subject: [issue4486] Exception traceback is incorrect for strange exception
	handling
In-Reply-To: <1228214038.9.0.934760513423.issue4486@psf.upfronthosting.co.za>
Message-ID: <1259425003.92.0.511469117224.issue4486@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Finally committed in py3k and 3.1. Thanks!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4486>
_______________________________________

From report at bugs.python.org  Sat Nov 28 17:40:13 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 28 Nov 2009 16:40:13 +0000
Subject: [issue1678380] 0.0 and -0.0 identified, with surprising results
Message-ID: <1259426413.16.0.288813056464.issue1678380@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Applied (along with a corresponding fix for the complex type) in
revisions r76575 through r76578.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1678380>
_______________________________________

From report at bugs.python.org  Sat Nov 28 17:43:47 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 28 Nov 2009 16:43:47 +0000
Subject: [issue7327] format: minimum width: UTF-8 separators and decimal points
In-Reply-To: <1258280971.1.0.983226181609.issue7327@psf.upfronthosting.co.za>
Message-ID: <1259426627.0.0.297205434236.issue7327@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7327>
_______________________________________

From report at bugs.python.org  Sat Nov 28 18:01:35 2009
From: report at bugs.python.org (Thomas Vander Stichele)
Date: Sat, 28 Nov 2009 17:01:35 +0000
Subject: [issue644744] bdist_rpm fails when installing man pages
Message-ID: <1259427695.28.0.759551414383.issue644744@psf.upfronthosting.co.za>


Thomas Vander Stichele <thomasvs at users.sourceforge.net> added the comment:

Ok, so this patch can go in as is except for changing .gz to * ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue644744>
_______________________________________

From report at bugs.python.org  Sat Nov 28 18:53:01 2009
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 28 Nov 2009 17:53:01 +0000
Subject: [issue7327] format: minimum width: UTF-8 separators and decimal points
In-Reply-To: <1258280971.1.0.983226181609.issue7327@psf.upfronthosting.co.za>
Message-ID: <1259430781.72.0.796349112792.issue7327@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Surely this is to be expected when working with bytestrings. You should
be working in Unicode and using UTF-8 only for input and output.

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7327>
_______________________________________

From report at bugs.python.org  Sat Nov 28 19:33:49 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 28 Nov 2009 18:33:49 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1259433229.06.0.237793622302.issue1859@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I notice that Greg Ward just resurfaced on the issue tracker (issue 6454).  
:)

Greg, any comment on this issue?

----------
nosy: +gward
stage:  -> test needed
type: behavior -> feature request
versions:  -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Sat Nov 28 19:47:26 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 28 Nov 2009 18:47:26 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1259434046.16.0.658982899493.issue1859@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The current patch is too simple:  it fails if lines end with ' \n', for 
example.  The simplest way to make this work may be to put each '\n' into 
its own chunk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Sat Nov 28 22:07:21 2009
From: report at bugs.python.org (David Bolen)
Date: Sat, 28 Nov 2009 21:07:21 +0000
Subject: [issue7272] test_multiprocessing fails consistently with 'signal 12'
	on FreeBSD 6.2 buildbot.
In-Reply-To: <1257523034.1.0.340985846807.issue7272@psf.upfronthosting.co.za>
Message-ID: <1259442441.92.0.383675765504.issue7272@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

> David, I think we're ready to enable POSIX semaphore support on the 
> FreeBSD 7.2 buildbot now, if you get the chance.

Done.  I'll double check that the module remains loaded across restarts
when there's some idle time for a restart.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7272>
_______________________________________

From report at bugs.python.org  Sat Nov 28 23:11:55 2009
From: report at bugs.python.org (Greg Ward)
Date: Sat, 28 Nov 2009 22:11:55 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1259446315.35.0.471335993351.issue1859@psf.upfronthosting.co.za>


Greg Ward <greg at gerg.ca> added the comment:

> Greg, any comment on this issue?

Yes, two:

1) textwrap does not handle paragraphs or paragraph breaks in any way.  
That was a deliberate limitation to keep the code from getting any 
hairier.  People have complained about this in the past, and I have 
studiously ignored such complaints.  The standard answer is that you 
should break your text into paragraphs and then feed those paragraphs 
individually to a TextWrapper.  But this does not look like that old 
complaint.

2) Test, test, test.  In case you hadn't already noticed, this is a 
hairy piece of code.  It's also a poster child for unit testing.  Any 
change should IMHO be accompanied by lots of new tests.

No wait, make that *three* comments:

3) I agree with tlynn that the example in msg95469 looks *awfully* 
fishy.  But I don't remember enough of the details to say what's likely 
to be broken.  That's probably your first test case right there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Sun Nov 29 02:01:24 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 29 Nov 2009 01:01:24 +0000
Subject: [issue3471] PyObject_GetAttr() to get special methods
In-Reply-To: <1217435914.82.0.412658814842.issue3471@psf.upfronthosting.co.za>
Message-ID: <1259456484.49.0.738436026762.issue3471@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I'm closing this now.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3471>
_______________________________________

From report at bugs.python.org  Sun Nov 29 11:39:00 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 29 Nov 2009 10:39:00 +0000
Subject: [issue3382] Make '%F' and float.__format__('F') convert results to
	upper case.
In-Reply-To: <1216232895.09.0.0435300563375.issue3382@psf.upfronthosting.co.za>
Message-ID: <1259491140.19.0.575512820952.issue3382@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Eric, any further thoughts about making this change in 2.7?  Here's a 
patch that does it (I think).

----------
keywords: +patch
Added file: http://bugs.python.org/file15412/issue3382_trunk.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3382>
_______________________________________

From report at bugs.python.org  Sun Nov 29 12:56:24 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 29 Nov 2009 11:56:24 +0000
Subject: [issue7406] int arithmetic relies on C signed overflow behaviour
In-Reply-To: <1259495783.96.0.0738564373709.issue7406@psf.upfronthosting.co.za>
Message-ID: <1259495783.96.0.0738564373709.issue7406@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Much of the code in Objects/intobject.c assumes that an arithmetic 
operation on signed longs will wrap modulo 2**(bits_in_long) on 
overflow.  However, signed overflow causes undefined behaviour according 
to the C standards (e.g., C99 6.5, para. 5), and gcc is known to assume 
that signed overflow never occurs in correct code, and to make use of 
this assumption when optimizing.

An obvious example is found in int_add, which looks like this:

static PyObject *
int_add(PyIntObject *v, PyIntObject *w)
{
	register long a, b, x;
	CONVERT_TO_LONG(v, a);
	CONVERT_TO_LONG(w, b);
	x = a + b;
	if ((x^a) >= 0 || (x^b) >= 0)
		return PyInt_FromLong(x);
	return PyLong_Type.tp_as_number->nb_add((PyObject *)v, (PyObject 
*)w);
}

Here Python is relying on the line 'x = a + b' wrapping on overflow.  
While this code doesn't seem to have caused any problems to date, it's 
not at all inconceivable that some future version of GCC is clever 
enough to figure out that (with its assumption that correct code never 
includes signed overflow) the if condition is always false, so can be 
optimized away.  At that point, a Python interpreter built with this 
version of GCC would produce incorrect results for int addition.


More generally, Python's source makes a number of assumptions about 
integer arithmetic that aren't guaranteed by the C standards.  Most of 
these assumptions are likely to be harmless on modern machines, but the 
assumptions should probably at least be documented somewhere, and 
ideally also checked somewhere in the configuration, so that attempts to 
port Python to machines that don't obey these assumptions complain 
loudly.  Namely, the source assumes at least that:

- C signed ints are represented in two's complement, not ones'
  complement or sign-and-magnitude.

- the bit pattern 1000....000 is not a trap representation (so
  e.g., INT_MIN = -INT_MAX-1, not -INT_MAX).

- conversion from an unsigned integer type to the corresponding signed
  type wraps modulo 2**(appropriate_number_of_bits).

(Relevant standard sections:  C99 6.2.6.2, C99 6.3.1.3p3.)


See also issue 1621.

----------
components: Interpreter Core
messages: 95803
nosy: mark.dickinson
severity: normal
stage: needs patch
status: open
title: int arithmetic relies on C signed overflow behaviour
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7406>
_______________________________________

From report at bugs.python.org  Sun Nov 29 13:47:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Nov 2009 12:47:20 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1259498840.1.0.0170783638258.issue3783@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It would be nice to try to advance this at PyCon, or at another time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Sun Nov 29 15:15:05 2009
From: report at bugs.python.org (Eric Smith)
Date: Sun, 29 Nov 2009 14:15:05 +0000
Subject: [issue3382] Make '%F' and float.__format__('F') convert results to
	upper case.
In-Reply-To: <1216232895.09.0.0435300563375.issue3382@psf.upfronthosting.co.za>
Message-ID: <1259504105.93.0.741535720669.issue3382@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Thanks for looking at this, Mark.

Your patch looks okay to me, but Objects/stringlib/formatter.h still has
some 'F' -> 'f' logic in it, although it turns out that it's wrong:

#if PY_VERSION_HEX < 0x0301000
    /* 'F' is the same as 'f', per the PEP */
    /* This is no longer the case in 3.x */
    if (type == 'F')
        type = 'f';
#endif

Note that it's missing a zero on the end, so this code is never (and I
guess never was) executed. I'll remove it and add a test.

It also looks like complex is still mapping 'F' to 'f'. I'll fix that,
too, and add a test for it.

Thanks again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3382>
_______________________________________

From report at bugs.python.org  Sun Nov 29 17:00:12 2009
From: report at bugs.python.org (Floris Bruynooghe)
Date: Sun, 29 Nov 2009 16:00:12 +0000
Subject: [issue7407] Minor Queue doc improvement
In-Reply-To: <1259510412.02.0.297127408529.issue7407@psf.upfronthosting.co.za>
Message-ID: <1259510412.02.0.297127408529.issue7407@psf.upfronthosting.co.za>


New submission from Floris Bruynooghe <floris.bruynooghe at gmail.com>:

The documentation of the queue module (Queue in 2.x) does not mention
that the constructors have a default argument of 0 for "maxsize".  The
trivial patch adds this (patch against py3k trunk).

----------
assignee: georg.brandl
components: Documentation
files: queue.diff
keywords: patch
messages: 95806
nosy: flub, georg.brandl
severity: normal
status: open
title: Minor Queue doc improvement
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15413/queue.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7407>
_______________________________________

From report at bugs.python.org  Sun Nov 29 18:06:59 2009
From: report at bugs.python.org (Eric Smith)
Date: Sun, 29 Nov 2009 17:06:59 +0000
Subject: [issue3382] Make '%F' and float.__format__('F') convert results to
	upper case.
In-Reply-To: <1216232895.09.0.0435300563375.issue3382@psf.upfronthosting.co.za>
Message-ID: <1259514419.06.0.946263310091.issue3382@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Here's a patch which adds some tests and fixes complex.

I'm currently testing with PY_NO_SHORT_FLOAT_REPR on Windows. If that's
okay, and if you don't have any objections, I'll commit this. While I'm
at it I'll modify Objects/stringlib/formatter.h in py3k to keep them it
sync with trunk.

----------
Added file: http://bugs.python.org/file15414/issue3382_trunk-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3382>
_______________________________________

From report at bugs.python.org  Sun Nov 29 18:07:08 2009
From: report at bugs.python.org (Eric Smith)
Date: Sun, 29 Nov 2009 17:07:08 +0000
Subject: [issue3382] Make '%F' and float.__format__('F') convert results to
	upper case.
In-Reply-To: <1216232895.09.0.0435300563375.issue3382@psf.upfronthosting.co.za>
Message-ID: <1259514428.2.0.679982738232.issue3382@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3382>
_______________________________________

From report at bugs.python.org  Sun Nov 29 18:12:14 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 29 Nov 2009 17:12:14 +0000
Subject: [issue3382] Make '%F' and float.__format__('F') convert results to
	upper case.
In-Reply-To: <1216232895.09.0.0435300563375.issue3382@psf.upfronthosting.co.za>
Message-ID: <1259514734.46.0.668928748778.issue3382@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3382>
_______________________________________

From report at bugs.python.org  Sun Nov 29 18:21:10 2009
From: report at bugs.python.org (Titus Brown)
Date: Sun, 29 Nov 2009 17:21:10 +0000
Subject: [issue7408] test_distutils fails on Mac OS X 10.5
In-Reply-To: <1259515270.43.0.427140625875.issue7408@psf.upfronthosting.co.za>
Message-ID: <1259515270.43.0.427140625875.issue7408@psf.upfronthosting.co.za>


New submission from Titus Brown <titus at idyll.org>:

Here's the error:

test_distutils
test test_distutils failed -- Traceback (most recent call last):
File
"/private/tmp/tmp8UfLPT/python27/Lib/distutils/tests/test_sdist.py",
line 342, in test_make_distribution_owner_group 
    self.assertEquals(member.gid, os.getgid())
AssertionError: 0 != 20

It has been a problem for over a week, at least.

----------
assignee: tarek
components: Distutils
messages: 95809
nosy: tarek, titus
severity: normal
status: open
title: test_distutils fails on Mac OS X 10.5
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7408>
_______________________________________

From report at bugs.python.org  Sun Nov 29 18:41:27 2009
From: report at bugs.python.org (Eric Smith)
Date: Sun, 29 Nov 2009 17:41:27 +0000
Subject: [issue3382] Make '%F' and float.__format__('F') convert results to
	upper case.
In-Reply-To: <1216232895.09.0.0435300563375.issue3382@psf.upfronthosting.co.za>
Message-ID: <1259516487.29.0.942044332283.issue3382@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Committed (with a few more tests) in r76583.

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3382>
_______________________________________

From report at bugs.python.org  Sun Nov 29 18:43:41 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 29 Nov 2009 17:43:41 +0000
Subject: [issue3754] minimal cross-compilation support for configure
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1259516621.92.0.598715624122.issue3754@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Added file: http://bugs.python.org/file15415/python-trunk-20091129-CROSS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Sun Nov 29 18:45:37 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 29 Nov 2009 17:45:37 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1259516737.14.0.0586189585775.issue3871@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Added file: http://bugs.python.org/file15416/python-trunk-20091129-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sun Nov 29 20:58:07 2009
From: report at bugs.python.org (Ned Deily)
Date: Sun, 29 Nov 2009 19:58:07 +0000
Subject: [issue7408] test_distutils fails on Mac OS X 10.5
In-Reply-To: <1259515270.43.0.427140625875.issue7408@psf.upfronthosting.co.za>
Message-ID: <1259524687.57.0.526437939463.issue7408@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Also seeing it on 10.5 ...

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7408>
_______________________________________

From report at bugs.python.org  Sun Nov 29 21:36:02 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 29 Nov 2009 20:36:02 +0000
Subject: [issue7408] test_distutils fails on Mac OS X 10.5
In-Reply-To: <1259515270.43.0.427140625875.issue7408@psf.upfronthosting.co.za>
Message-ID: <1259526962.62.0.24691260594.issue7408@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

This test makes sure that a tarball created with sidist has the same
owner/group than your current user in each one of its member. Maybe
somehow, the previous tarball creation breaks this test.

Can you try this on your side:

Comment everything in "test_make_distribution_owner_group" between these
lines (318)

   # now building a sdist

   ...

   # building a sdist again

And see if it works.  Thx!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7408>
_______________________________________

From report at bugs.python.org  Sun Nov 29 22:01:45 2009
From: report at bugs.python.org (David Bolen)
Date: Sun, 29 Nov 2009 21:01:45 +0000
Subject: [issue7408] test_distutils fails on Mac OS X 10.5
In-Reply-To: <1259515270.43.0.427140625875.issue7408@psf.upfronthosting.co.za>
Message-ID: <1259528505.66.0.988474601099.issue7408@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

I don't think its OSX specific.  My FreeBSD slaves (both 6.4 and 7.2)
have been getting the same error recently (sounds like probably around
the same time frame).  The error always seems to be that member.gid (0)
is not matching os.getgid (1001).  The os.getgid call is correct in
terms of that being the group under which the build slave is running.

In digging a little deeper I think the the generated distribution is
behaving correctly, just not how the test is expecting.  On my FreeBSD
systems (and my personal OSX 10.4 system for that matter), if I make a
directory in /tmp it gets my UID, but a GID of 0 (wheel).  Whether
that's because my id is also in the wheel group or because of the sticky
bit on /tmp I'm not totally sure.  Maybe it needs both (/tmp is sticky
on my Ubuntu system but my id is not in the root group, and this doesn't
happen).

So the files being created for the second half of this test are placed
in a temporary folder with a group of wheel(0), and the files appear to
get the same ownership.  This doesn't happen elsewhere, but appears to
be special behavior beneath tmp.

Perhaps if the test did a comparison to the UID/GID of tmp_dir rather
than os.getuid()/os.getgid() it would better reflect that the tarfile
was being built with the same ownership as found in the filesystem. 
Whether that's the correct ownership is a separate question, but as long
as distutils is accurately reflecting that it shouldn't be a failure on
a distutils test.

-- David

----------
nosy: +db3l

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7408>
_______________________________________

From report at bugs.python.org  Sun Nov 29 22:22:00 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 29 Nov 2009 21:22:00 +0000
Subject: [issue7408] test_distutils fails on Mac OS X 10.5
In-Reply-To: <1259515270.43.0.427140625875.issue7408@psf.upfronthosting.co.za>
Message-ID: <1259529720.93.0.933104724028.issue7408@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Thanks for the digging David, I'll check for /tmp rights in that case.
What's important in distutils, is to make sure it was able to create
tarballs with various uid/gid using the new tarfile feature.

----------
priority:  -> high
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7408>
_______________________________________

From report at bugs.python.org  Sun Nov 29 22:45:10 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 29 Nov 2009 21:45:10 +0000
Subject: [issue7408] test_distutils fails on Mac OS X 10.5
In-Reply-To: <1259515270.43.0.427140625875.issue7408@psf.upfronthosting.co.za>
Message-ID: <1259531110.7.0.881263985215.issue7408@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

David, could it be that the directories where a change of group occurs
also have the s-bit set? The sticky bit should have no such effect.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7408>
_______________________________________

From report at bugs.python.org  Sun Nov 29 22:52:20 2009
From: report at bugs.python.org (Titus Brown)
Date: Sun, 29 Nov 2009 21:52:20 +0000
Subject: [issue7408] test_distutils fails on Mac OS X 10.5
In-Reply-To: <1259515270.43.0.427140625875.issue7408@psf.upfronthosting.co.za>
Message-ID: <1259531540.77.0.988717640485.issue7408@psf.upfronthosting.co.za>


Titus Brown <titus at idyll.org> added the comment:

I can generate the error on my iMac but not my laptop, which are
equivalent versions/upgrades of Mac OS X AFAIK.  The /tmp directory
in both has drwxrwxrwt, and the subdirectories within which I'm doing
the builds are drwxr-xr-x, so it doesn't seem to be only dir permissions...

Both accounts are user accounts with +wheel permissions.

Tarek, after commenting out those lines (starting at line 309 of my
test_sdist.py), I still get the same error on my iMac.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7408>
_______________________________________

From report at bugs.python.org  Sun Nov 29 22:56:31 2009
From: report at bugs.python.org (David Bolen)
Date: Sun, 29 Nov 2009 21:56:31 +0000
Subject: [issue7408] test_distutils fails on Mac OS X 10.5
In-Reply-To: <1259515270.43.0.427140625875.issue7408@psf.upfronthosting.co.za>
Message-ID: <1259531791.12.0.603062136384.issue7408@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

>From Tarek:

> Thanks for the digging David, I'll check for /tmp rights in that case.
> What's important in distutils, is to make sure it was able to create
> tarballs with various uid/gid using the new tarfile feature.

Right, and that part of the test (explicitly making uid/gid=0/0) is
passing.  It's just the default case that is failing, and only because
the test's assumption doesn't match what is actually happening in the
filesystem in terms of default group ownership.

>From Martin:

> David, could it be that the directories where a change of group occurs
> also have the s-bit set? The sticky bit should have no such effect.

Not sure - I only noticed the "t" suffix on the directory "ls -ald"
listing, which the ls man page called sticky, but didn't think about it
much more than that.

-- David

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7408>
_______________________________________

From report at bugs.python.org  Sun Nov 29 22:58:11 2009
From: report at bugs.python.org (Ned Deily)
Date: Sun, 29 Nov 2009 21:58:11 +0000
Subject: [issue7408] test_distutils fails on Mac OS X 10.5
In-Reply-To: <1259515270.43.0.427140625875.issue7408@psf.upfronthosting.co.za>
Message-ID: <1259531891.32.0.757031822699.issue7408@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

This does seem to be a long standing Unix*-flavor behavior difference.  

The open(2) man page on OS X (and presumably FreeBSD) reads:

   When a new file is created, it is given the group of the directory
   which contains it.

The Linux open(2) page has:

       O_CREAT
          If the file does not exist it will be created.  The owner  
(user  ID)  of
          the  file is set to the effective user ID of the process.  The 
group own?
          ership (group ID) is set either to the effective group ID of 
the  process
          or to the group ID of the parent directory (depending on file 
system type
          and mount options, and the mode of the parent directory,  see  
the  mount
          options bsdgroups and sysvgroups described in mount(8)).

The Open Group Base Specifications (Issue 6, 2004) for open(1) has this 
rationale:

"The POSIX.1-1990 standard required that the group ID of a newly created 
file be set to the group ID of its parent directory or to the effective 
group ID of the creating process. FIPS 151-2 required that 
implementations provide a way to have the group ID be set to the group 
ID of the containing directory, but did not prohibit implementations 
also supporting a way to set the group ID to the effective group ID of 
the creating process. Conforming applications should not assume which 
group ID will be used. If it matters, an application can use chown() to 
set the group ID after the file is created, or determine under what 
conditions the implementation will set the desired group ID."

So the portable solution is to change the test to not assume which group 
ID is used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7408>
_______________________________________

From report at bugs.python.org  Sun Nov 29 22:59:39 2009
From: report at bugs.python.org (David Bolen)
Date: Sun, 29 Nov 2009 21:59:39 +0000
Subject: [issue7408] test_distutils fails on Mac OS X 10.5
In-Reply-To: <1259515270.43.0.427140625875.issue7408@psf.upfronthosting.co.za>
Message-ID: <1259531979.65.0.763846455923.issue7408@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

> I can generate the error on my iMac but not my laptop, which are
> equivalent versions/upgrades of Mac OS X AFAIK.  The /tmp directory
> in both has drwxrwxrwt, and the subdirectories within which I'm doing
> the builds are drwxr-xr-x, so it doesn't seem to be only dir 
> permissions...

No, it seems to be some combination of ... something.  My Ubuntu boxes
all have "t" on the /tmp directory as well, but don't seem to exhibit
this behavior (whether or not I add myself to the "root" group that
owns /tmp).

But on the FreeBSD and OSX systems I can show this just though "mkdir"
from the command line.

At some level, I'm not sure it really matters as long as the test uses
whatever actual filesystem ownership is in place checking for default
values.

-- David

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7408>
_______________________________________

From report at bugs.python.org  Sun Nov 29 23:06:15 2009
From: report at bugs.python.org (Ned Deily)
Date: Sun, 29 Nov 2009 22:06:15 +0000
Subject: [issue7408] test_distutils fails on Mac OS X 10.5
In-Reply-To: <1259515270.43.0.427140625875.issue7408@psf.upfronthosting.co.za>
Message-ID: <1259532375.99.0.295036155794.issue7408@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

BTW, it's trivial to demonstrate the difference.

On OS X:

$ cd $HOME
$ mkdir test
$ touch test/test
$ chown :musicg test
$ touch test/test2
$ ls -l test
total 0
-rw-r-----  1 nad  staff   0 Nov 29 14:01 test
-rw-r-----  1 nad  musicg  0 Nov 29 14:01 test2

On my linux system, the same test results in:

$ ls -l test
total 0
-rw-r----- 1 nad nad 0 2009-11-29 14:02 test
-rw-r----- 1 nad nad 0 2009-11-29 14:02 test2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7408>
_______________________________________

From report at bugs.python.org  Sun Nov 29 23:08:46 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 29 Nov 2009 22:08:46 +0000
Subject: [issue7408] test_distutils fails on Mac OS X 10.5
In-Reply-To: <1259531979.65.0.763846455923.issue7408@psf.upfronthosting.co.za>
Message-ID: <4B12F0EC.5040401@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> At some level, I'm not sure it really matters as long as the test uses
> whatever actual filesystem ownership is in place checking for default
> values.

I think that's difficult to implement, as the files are not there
anymore when the check is made (only the tarfile); somebody correct
me if I'm wrong. So I agree that the test for group ownership should
be dropped, in the failing case (i.e. where nothing was specified for
the tar command).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7408>
_______________________________________

From report at bugs.python.org  Sun Nov 29 23:15:52 2009
From: report at bugs.python.org (David Bolen)
Date: Sun, 29 Nov 2009 22:15:52 +0000
Subject: [issue7408] test_distutils fails on Mac OS X 10.5
In-Reply-To: <1259515270.43.0.427140625875.issue7408@psf.upfronthosting.co.za>
Message-ID: <1259532952.02.0.842358364406.issue7408@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

> I think that's difficult to implement, as the files are not there
> anymore when the check is made (only the tarfile); somebody correct
> me if I'm wrong.

The files are created during setup, and I think exist through the
duration of the test, only being removed during tearDown (via
TempDirManager mixin) - otherwise this test couldn't be creating two
separate archives from the same sources.

Worst case though, just have setup grab the test file ownership
information and hang onto it in general.  But I think this specific test
could also check filesystem ownership at any point in the test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7408>
_______________________________________

From report at bugs.python.org  Sun Nov 29 23:23:32 2009
From: report at bugs.python.org (Robert Collins)
Date: Sun, 29 Nov 2009 22:23:32 +0000
Subject: [issue7409] cleanup now deepcopy copies instance methods
In-Reply-To: <1259533410.59.0.838597204894.issue7409@psf.upfronthosting.co.za>
Message-ID: <1259533410.59.0.838597204894.issue7409@psf.upfronthosting.co.za>


New submission from Robert Collins <robertc at robertcollins.net>:

With deepcopy fixed, I ran across this little fixable component.

----------
components: Library (Lib)
files: deepcopy-works.patch
keywords: patch
messages: 95823
nosy: rbcollins
severity: normal
status: open
title: cleanup now deepcopy copies instance methods
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15417/deepcopy-works.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7409>
_______________________________________

From report at bugs.python.org  Sun Nov 29 23:26:47 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 29 Nov 2009 22:26:47 +0000
Subject: [issue7409] cleanup now deepcopy copies instance methods
In-Reply-To: <1259533410.59.0.838597204894.issue7409@psf.upfronthosting.co.za>
Message-ID: <1259533607.6.0.094678085025.issue7409@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r76591. Thanks!

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7409>
_______________________________________

From report at bugs.python.org  Sun Nov 29 23:30:38 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 29 Nov 2009 22:30:38 +0000
Subject: [issue7408] test_distutils fails on Mac OS X 10.5
In-Reply-To: <1259515270.43.0.427140625875.issue7408@psf.upfronthosting.co.za>
Message-ID: <1259533838.08.0.00880175416703.issue7408@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I've dropped the gid control and just check the uid.

>From Distutils PoV, as long as this uid test pass, I can defer the
complete uid/gid test to the dedicated tarfile tests.

What is important here is being able to check that I can force a
different uid/gid for sdist archives (the first part of my test) and
this works well.

Thanks everyone for the help !

done in r76588, r76590

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7408>
_______________________________________

From report at bugs.python.org  Sun Nov 29 23:57:15 2009
From: report at bugs.python.org (Titus Brown)
Date: Sun, 29 Nov 2009 22:57:15 +0000
Subject: [issue7408] test_distutils fails on Mac OS X 10.5
In-Reply-To: <1259515270.43.0.427140625875.issue7408@psf.upfronthosting.co.za>
Message-ID: <1259535435.77.0.231417855288.issue7408@psf.upfronthosting.co.za>


Titus Brown <titus at idyll.org> added the comment:

Fix verified, thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7408>
_______________________________________

From report at bugs.python.org  Mon Nov 30 00:22:31 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 29 Nov 2009 23:22:31 +0000
Subject: [issue7407] Minor Queue doc improvement
In-Reply-To: <1259510412.02.0.297127408529.issue7407@psf.upfronthosting.co.za>
Message-ID: <1259536951.22.0.895679235468.issue7407@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: georg.brandl -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7407>
_______________________________________

From report at bugs.python.org  Mon Nov 30 01:17:03 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 30 Nov 2009 00:17:03 +0000
Subject: [issue6077] Unicode issue with tempfile on Windows
In-Reply-To: <1242902281.19.0.785534921176.issue6077@psf.upfronthosting.co.za>
Message-ID: <1259540223.66.0.062766702077.issue6077@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed with r76593 (py3k) and r76594 (release31-maint)

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6077>
_______________________________________

From report at bugs.python.org  Mon Nov 30 01:56:22 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 30 Nov 2009 00:56:22 +0000
Subject: [issue5748] Objects/bytesobject.c should include stringdefs.h,
	instead of defining its own macros
In-Reply-To: <1239657309.78.0.97481273251.issue5748@psf.upfronthosting.co.za>
Message-ID: <1259542582.45.0.641514952592.issue5748@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This does not apply to 2.x. In both py3k and trunk,
Objects/bytearrayobject.c uses stringlib with some private defines. But
since those defines are only used in bytearrayobject.c, there's nothing
to be gained by factoring then out into a bytearraydef.h file.

So, I'm just going to fix this in Objects/bytesobjects.c, which only
appears in py3k.

----------
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5748>
_______________________________________

From report at bugs.python.org  Mon Nov 30 02:02:17 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 30 Nov 2009 01:02:17 +0000
Subject: [issue5748] Objects/bytesobject.c should include stringdefs.h,
	instead of defining its own macros
In-Reply-To: <1239657309.78.0.97481273251.issue5748@psf.upfronthosting.co.za>
Message-ID: <1259542937.61.0.675613092013.issue5748@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Fixed in r76595.

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5748>
_______________________________________

From report at bugs.python.org  Mon Nov 30 03:04:48 2009
From: report at bugs.python.org (Robert Collins)
Date: Mon, 30 Nov 2009 02:04:48 +0000
Subject: [issue7410] deepcopy of itertools.count resets the count
In-Reply-To: <1259546688.1.0.524850566864.issue7410@psf.upfronthosting.co.za>
Message-ID: <1259546688.1.0.524850566864.issue7410@psf.upfronthosting.co.za>


New submission from Robert Collins <robertc at robertcollins.net>:

>>> from copy import deepcopy
>>> from itertools import count
>>> c = count()
>>> c.next()
0
>>> deepcopy(c)
count(0)
>>> c.next()
1
>>> deepcopy(c)
count(0)
>>> c
count(2)
>>> deepcopy(c).next()
0


I don't see any reason why these shouldn't be deepcopyable (or picklable
for that reason - and that fails too)

----------
components: Library (Lib)
messages: 95830
nosy: rbcollins
severity: normal
status: open
title: deepcopy of itertools.count resets the count
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7410>
_______________________________________

From report at bugs.python.org  Mon Nov 30 06:47:06 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 Nov 2009 05:47:06 +0000
Subject: [issue7410] deepcopy of itertools.count resets the count
In-Reply-To: <1259546688.1.0.524850566864.issue7410@psf.upfronthosting.co.za>
Message-ID: <1259560025.91.0.958000519004.issue7410@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7410>
_______________________________________

From report at bugs.python.org  Mon Nov 30 07:09:00 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 Nov 2009 06:09:00 +0000
Subject: [issue7410] deepcopy of itertools.count resets the count
In-Reply-To: <1259546688.1.0.524850566864.issue7410@psf.upfronthosting.co.za>
Message-ID: <1259561340.7.0.393630729732.issue7410@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7410>
_______________________________________

From report at bugs.python.org  Mon Nov 30 07:58:06 2009
From: report at bugs.python.org (Phillip M. Feldman)
Date: Mon, 30 Nov 2009 06:58:06 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1259564286.69.0.191310718387.issue1859@psf.upfronthosting.co.za>


Phillip M. Feldman <pfeldman at verizon.net> added the comment:

As a temporary workaround, you can use the `wrap` function in my strnum
module (http://pypi.python.org/pypi/strnum/2.4).

Phillip

----------
nosy: +pfeldman at verizon.net

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Mon Nov 30 08:01:17 2009
From: report at bugs.python.org (Phillip M. Feldman)
Date: Mon, 30 Nov 2009 07:01:17 +0000
Subject: [issue7411] allow import from file having name containing hyphen or
	blank
In-Reply-To: <1259564476.99.0.910098142875.issue7411@psf.upfronthosting.co.za>
Message-ID: <1259564476.99.0.910098142875.issue7411@psf.upfronthosting.co.za>


New submission from Phillip M. Feldman <pfeldman at verizon.net>:

It appears that there is currently no way to import from a file whose
name contains a hyphen or blank.  This makes it difficult to encode a
version number or date in the file name.   The solution that I favor
would be to allow the name of the file to be specified via a quoted string.

----------
components: Interpreter Core
messages: 95832
nosy: pfeldman at verizon.net
severity: normal
status: open
title: allow import from file having name containing hyphen or blank
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7411>
_______________________________________

From report at bugs.python.org  Mon Nov 30 10:01:06 2009
From: report at bugs.python.org (Rene Dudfield)
Date: Mon, 30 Nov 2009 09:01:06 +0000
Subject: [issue7412] distutils install race condition
In-Reply-To: <1259571666.51.0.555227768726.issue7412@psf.upfronthosting.co.za>
Message-ID: <1259571666.51.0.555227768726.issue7412@psf.upfronthosting.co.za>


New submission from Rene Dudfield <illume at users.sourceforge.net>:

hello!

Pythons distutils has a race condition where it starts to copy files
into the python path whilst installing.

This is a race condition, since python programs can be importing the
package whilst the package is being installed.

It would be good for distutils to install things in an atomic manner.
Where things can be installed, or not installed. Like, on unix by moving
the files in from a temporary directory. This would also help reduce
breakages. Since if a package breaks half way installing a package then
the broken version will not over write the existing version.

It's not a very serious problem, since most people don't install things
on live important systems(but some do).  It does make hard to diagnose
problems though... which are good ones to fix.  Most packaging tools fix
the issues with the source installs (eg, using .deb installers).

I've only looked at the source install, but I imagine other install
methods might be affected too.  

os.rename
mkdtemp
http://docs.python.org/library/tempfile.html#tempfile.mkdtemp

Perhaps files should be created in the /tmp first, and then moved in.

/tmp/ can be in a different file system so a rename won't work in that
case on some OSes.  If you create the temp directory in the same
directory as the directory to install.  In that case rename doesn't
work, using the temp file system(eg /tmp) and then copying to a temp
directory in the site-packages directory, with finally a move into place.

If copying to the site-packages before moving, then there could be left
over temp files in the site-packages directory.  So these would need to
be considered, and cruft cleaned up.  This is why using the normal temp
directory would be better, since the temp files will be cleaned as
normal policy on the system.
  
setuptools/distribute writes the .egg-info at the end of the install. 
This should also use a move for install, for the same reasons.  However,
there might still be a separate race condition since that lives in a
different directory.  Since you can not atomically move two things at
once( I think? ) the .egg-info will continue to be a race condition,
unless both directories are moved into the same one.



Just as moving packages into place will make the installs more robust,
so will testing the packages before moving them into place.  Some way to
test the install before moving it into place would be good.  Or at least
trying to import the package in a sub process.  Taking advantage of the
test command could be an idea.  Test before moving into place would give
a better chance of good packages being used.  Import before moving into
place could also help.

----------
assignee: tarek
components: Distutils
messages: 95833
nosy: illume, tarek
severity: normal
status: open
title: distutils install race condition
type: security

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7412>
_______________________________________

From report at bugs.python.org  Mon Nov 30 12:15:52 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 Nov 2009 11:15:52 +0000
Subject: [issue7410] deepcopy of itertools.count resets the count
In-Reply-To: <1259546688.1.0.524850566864.issue7410@psf.upfronthosting.co.za>
Message-ID: <1259579752.26.0.529447604064.issue7410@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed in r76599.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7410>
_______________________________________

From report at bugs.python.org  Mon Nov 30 13:38:06 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 30 Nov 2009 12:38:06 +0000
Subject: [issue7406] int arithmetic relies on C signed overflow behaviour
In-Reply-To: <1259495783.96.0.0738564373709.issue7406@psf.upfronthosting.co.za>
Message-ID: <1259584686.49.0.015738287262.issue7406@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7406>
_______________________________________

From report at bugs.python.org  Mon Nov 30 13:50:22 2009
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 30 Nov 2009 12:50:22 +0000
Subject: [issue7046] decimal.py: use DivisionImpossible and DivisionUndefined
In-Reply-To: <1254576656.46.0.369353081628.issue7046@psf.upfronthosting.co.za>
Message-ID: <1259585422.64.0.481229566798.issue7046@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I agree that it might add confusion. In the C-module,I currently
do this:

>>> Decimal(0) / 0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
cdecimal.InvalidOperation: [<class 'cdecimal.DivisionUndefined'>]


But since you already have a detailed error message, this doesn't
seem necessary for decimal.py.

Close this one?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7046>
_______________________________________

From report at bugs.python.org  Mon Nov 30 14:04:05 2009
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 30 Nov 2009 13:04:05 +0000
Subject: [issue7327] format: minimum width: UTF-8 separators and decimal points
In-Reply-To: <1258280971.1.0.983226181609.issue7327@psf.upfronthosting.co.za>
Message-ID: <1259586245.27.0.0205788222291.issue7327@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

What you mean by "working with bytestrings"? The UTF-8 separators or
decimal points come directly from struct lconv (man localeconv). The
logical way to reach a minimum width of 19 is to have 19 UTF-8
characters, which can subsequently be converted to other formats.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7327>
_______________________________________

From report at bugs.python.org  Mon Nov 30 14:40:43 2009
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Mon, 30 Nov 2009 13:40:43 +0000
Subject: [issue7394] sqlite3: some OperationalError exceptions should be
	ProgrammingError (PEP 249)
In-Reply-To: <1259167159.55.0.802533140683.issue7394@psf.upfronthosting.co.za>
Message-ID: <1259588443.24.0.799117446695.issue7394@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I have created some naive patch, that makes sqlite module raise
ProgrammingError for SQLITE_ERROR code. But I don't know, whether it
might raise ProgrammingError in situation, when OperationalError should be.

Sqlite docs says: 

#define SQLITE_ERROR        1   /* SQL error or missing database */

and I don't really know, whether missing database is operational error
or a programming one. Seems like the first one, but this would error
message string parsing, that doesn't seem to pretty. Could anyone
suggest me, what else could be done?

----------
keywords: +patch
nosy: +gruszczy
Added file: http://bugs.python.org/file15418/sqlite_ProgrammingError.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7394>
_______________________________________

From report at bugs.python.org  Mon Nov 30 15:14:36 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 30 Nov 2009 14:14:36 +0000
Subject: [issue6452] urllib2.Request() will not work with long authorization
	headers
In-Reply-To: <1247171212.16.0.153578290973.issue6452@psf.upfronthosting.co.za>
Message-ID: <1259590476.99.0.099781964102.issue6452@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6452>
_______________________________________

From report at bugs.python.org  Mon Nov 30 16:51:23 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 30 Nov 2009 15:51:23 +0000
Subject: [issue7411] allow import from file having name containing hyphen or
	blank
In-Reply-To: <1259564476.99.0.910098142875.issue7411@psf.upfronthosting.co.za>
Message-ID: <1259596283.07.0.623874361481.issue7411@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Yes, there is:

$ cat > "file-with-hyphen and space.py"
x = 5

$ python
Python 2.6.4 (r264:75706, Oct 27 2009, 15:50:27) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> mod = __import__("file-with-hyphen and space")
>>> mod.x
5
>>>

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7411>
_______________________________________

From report at bugs.python.org  Mon Nov 30 17:32:25 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 30 Nov 2009 16:32:25 +0000
Subject: [issue7118] urllib2.urlopen() timeout argument ignored after redirect
In-Reply-To: <1255443588.46.0.439555512733.issue7118@psf.upfronthosting.co.za>
Message-ID: <1259598745.07.0.59468883851.issue7118@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

The timeout propagation fixed with Issue5102.

----------
resolution:  -> duplicate

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7118>
_______________________________________

From report at bugs.python.org  Mon Nov 30 17:32:36 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 30 Nov 2009 16:32:36 +0000
Subject: [issue7118] urllib2.urlopen() timeout argument ignored after redirect
In-Reply-To: <1255443588.46.0.439555512733.issue7118@psf.upfronthosting.co.za>
Message-ID: <1259598756.61.0.230182409639.issue7118@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7118>
_______________________________________

From report at bugs.python.org  Mon Nov 30 20:31:24 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 Nov 2009 19:31:24 +0000
Subject: [issue7046] decimal.py: use DivisionImpossible and DivisionUndefined
In-Reply-To: <1254576656.46.0.369353081628.issue7046@psf.upfronthosting.co.za>
Message-ID: <1259609484.56.0.676006377923.issue7046@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7046>
_______________________________________

From report at bugs.python.org  Mon Nov 30 20:45:21 2009
From: report at bugs.python.org (Geoffrey Bache)
Date: Mon, 30 Nov 2009 19:45:21 +0000
Subject: [issue4057] Popen(..., cwd=...) does not set PWD environment variable
In-Reply-To: <1223321283.05.0.79921922605.issue4057@psf.upfronthosting.co.za>
Message-ID: <1259610321.68.0.994929299158.issue4057@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

I tried that and it didn't work, though not for this reason. I'm also
trying to read the output from the subprocess via a pipe and that wasn't
being collected for some reason. I didn't really track down why so far,
if it makes or breaks this bug I can do so though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4057>
_______________________________________

From report at bugs.python.org  Mon Nov 30 20:50:23 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 30 Nov 2009 19:50:23 +0000
Subject: [issue4057] Popen(..., cwd=...) does not set PWD environment variable
In-Reply-To: <1223321283.05.0.79921922605.issue4057@psf.upfronthosting.co.za>
Message-ID: <1259610623.16.0.433317700908.issue4057@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

`Popen` is the wrong place to implement this functionality.  It may be
reasonable to introduce a higher-level wrapper API which does this sort
of thing.  Consider that if `Popen` itself does it, though, then there
is no way to launch a process with a particular working directory
*without* PWD set in its environment.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4057>
_______________________________________

From report at bugs.python.org  Mon Nov 30 21:21:22 2009
From: report at bugs.python.org (flox)
Date: Mon, 30 Nov 2009 20:21:22 +0000
Subject: [issue3599] test_pydoc after test_urllib2 causes exception in
	Popen.__del__
In-Reply-To: <1219157315.63.0.32622319144.issue3599@psf.upfronthosting.co.za>
Message-ID: <1259612482.22.0.0422263640717.issue3599@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Tested on debian with r76600 (/branches/release26-maint

No error.

~/dev/python/release26-maint $ ./python Lib/test/regrtest.py -uall
test_urllib2 test_pydoc
test_urllib2
test_pydoc
All 2 tests OK.
~/dev/python/release26-maint $ 

Is it specific to Windows?

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3599>
_______________________________________

From report at bugs.python.org  Mon Nov 30 23:02:58 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 Nov 2009 22:02:58 +0000
Subject: [issue7410] deepcopy of itertools.count resets the count
In-Reply-To: <1259546688.1.0.524850566864.issue7410@psf.upfronthosting.co.za>
Message-ID: <1259618578.84.0.855887304281.issue7410@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7410>
_______________________________________