From report at bugs.python.org  Fri Apr  1 00:07:16 2011
From: report at bugs.python.org (Jan Kaliszewski)
Date: Thu, 31 Mar 2011 22:07:16 +0000
Subject: [issue7796] No way to find out if an object is an instance of a
	namedtuple
In-Reply-To: <1264608669.85.0.379125118171.issue7796@psf.upfronthosting.co.za>
Message-ID: <1301609236.92.0.651767552327.issue7796@psf.upfronthosting.co.za>


Jan Kaliszewski <zuo at chopin.edu.pl> added the comment:

PS. For the record: the final recipe is here: http://code.activestate.com/recipes/577629-namedtupleabc-abstract-base-class-mix-in-for-named/

----------

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

From report at bugs.python.org  Fri Apr  1 00:08:52 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 31 Mar 2011 22:08:52 +0000
Subject: [issue11715] Building Python on multiarch Debian and Ubuntu
In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za>
Message-ID: <1301609332.76.0.958766659392.issue11715@psf.upfronthosting.co.za>


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

Python 2.5 is not open for bug fixes anymore, so this can't be applied to this branch. I suggest that Python 2.6 is closed for bug fixes as well.

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

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

From report at bugs.python.org  Fri Apr  1 00:13:25 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Thu, 31 Mar 2011 22:13:25 +0000
Subject: [issue11722] mingw64 does not link when building extensions
In-Reply-To: <1301502105.52.0.181374026279.issue11722@psf.upfronthosting.co.za>
Message-ID: <1301609605.39.0.043213496535.issue11722@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

pyconfig.h defines SIZEOF_SIZE_T depending on the preprocessor symbol MS_WIN64. The patch in #4709 would fix that.

----------
nosy: +schmir

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

From report at bugs.python.org  Fri Apr  1 00:46:56 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 31 Mar 2011 22:46:56 +0000
Subject: [issue7796] No way to find out if an object is an instance of a
	namedtuple
In-Reply-To: <1264608669.85.0.379125118171.issue7796@psf.upfronthosting.co.za>
Message-ID: <E1Q5Qdi-0001TS-Gb@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7aa3f1f7ac94 by Raymond Hettinger in branch '3.2':
Issue #7796: Add link to Jan Kaliszewski's alternate constructor and ABC for named tuples.
http://hg.python.org/cpython/rev/7aa3f1f7ac94

New changeset 330d3482cad8 by Raymond Hettinger in branch 'default':
Issue #7796: Add link to Jan Kaliszewski's alternate constructor and ABC for named tuples.
http://hg.python.org/cpython/rev/330d3482cad8

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Apr  1 00:52:58 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 31 Mar 2011 22:52:58 +0000
Subject: [issue11715] Building Python on multiarch Debian and Ubuntu
In-Reply-To: <1301609332.76.0.958766659392.issue11715@psf.upfronthosting.co.za>
Message-ID: <20110331185249.1ab41668@neurotica.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Mar 31, 2011, at 10:08 PM, Martin v. L?wis wrote:

>Martin v. L?wis <martin at v.loewis.de> added the comment:
>
>Python 2.5 is not open for bug fixes anymore, so this can't be applied to
>this branch. I suggest that Python 2.6 is closed for bug fixes as well.

Although I'd still like to apply it to 2.5, I defer to you as RM.  However,
if/when I ever need to do a 2.6 release I'll need to build and test it and I
don't want to have to keep an old version of Ubuntu around to do that.

So how about if I apply it to 2.6, 2.7, 3.1 - 3.3?

(I've also addressed the comment you made in the review.)

----------

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

From report at bugs.python.org  Fri Apr  1 00:59:39 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 31 Mar 2011 22:59:39 +0000
Subject: [issue11715] Building Python on multiarch Debian and Ubuntu
In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za>
Message-ID: <1301612379.62.0.96535813163.issue11715@psf.upfronthosting.co.za>


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

If Ubuntu stops supporting to build old Python releases, I rather consider this a serious bug in Debian, not one in Python.

If the issue is merely that certain extension modules fail to build, I see no real reason to do anything about it. Users affected by this issue can still edit Modules/Setup.

----------

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

From report at bugs.python.org  Fri Apr  1 01:50:38 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 31 Mar 2011 23:50:38 +0000
Subject: [issue11733] Implement a `Counter.elements_count` method
In-Reply-To: <1301607638.51.0.474843371118.issue11733@psf.upfronthosting.co.za>
Message-ID: <1301615438.69.0.261609222801.issue11733@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

The name isn't meaningful to me. My preference would be for something like "total_count".

----------
nosy: +mrabarnett

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

From report at bugs.python.org  Fri Apr  1 02:31:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Apr 2011 00:31:36 +0000
Subject: [issue11393] Integrate faulthandler module into Python 3.3
In-Reply-To: <1299194385.57.0.300728524683.issue11393@psf.upfronthosting.co.za>
Message-ID: <E1Q5SGx-00008S-Bo@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 8b1341d51fe6 by Victor Stinner in branch 'default':
Issue #11393: Fix faulthandler_thread(): release cancel lock before join lock
http://hg.python.org/cpython/rev/8b1341d51fe6

----------

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

From report at bugs.python.org  Fri Apr  1 02:40:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Apr 2011 00:40:07 +0000
Subject: [issue11393] Integrate faulthandler module into Python 3.3
In-Reply-To: <E1Q5SGx-00008S-Bo@dinsdale.python.org>
Message-ID: <1301618403.3523.0.camel@localhost.localdomain>


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

> New changeset 8b1341d51fe6 by Victor Stinner in branch 'default':
> Issue #11393: Fix faulthandler_thread(): release cancel lock before join lock
> http://hg.python.org/cpython/rev/8b1341d51fe6

This is wrong, it should always be released, not only when explicitly
cancelled.

----------

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

From report at bugs.python.org  Fri Apr  1 03:00:17 2011
From: report at bugs.python.org (Eli Stevens)
Date: Fri, 01 Apr 2011 01:00:17 +0000
Subject: [issue11734] Add half-float (16-bit) support to struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>


New submission from Eli Stevens <wickedgrey at gmail.com>:

Numpy 1.6.0 adds support for a half-float (16-bit) data type, but
cannot currently export a buffer interface to the data since neither PEP 3118 nor the struct module (referenced by PEP 3118) support the data type.

I am proposing that the struct module be extended to support half floats, and will be providing a patch that implements that behavior.

The current numpy implementation (1.6.0b1) uses the 'e' character to indicate half floats; I don't have a vested interest in what character is used.  If consensus between CPython and numpy is reached for using a different character, I will update my patches (but I don't plan on participating in the bike shedding prior to that point).

For reference:

python-ideas thread:
http://mail.python.org/pipermail/python-ideas/2011-March/009650.html

numpy-discussion thread:
http://mail.scipy.org/pipermail/numpy-discussion/2011-March/055667.html

cython-user thread (less relevant to this issue specifically):
http://groups.google.com/group/cython-users/browse_thread/thread/6bf811409cdab89e

----------
components: Library (Lib)
messages: 132722
nosy: Eli.Stevens
priority: normal
severity: normal
status: open
title: Add half-float (16-bit) support to struct module
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Fri Apr  1 03:00:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Apr 2011 01:00:22 +0000
Subject: [issue11393] Integrate faulthandler module into Python 3.3
In-Reply-To: <1299194385.57.0.300728524683.issue11393@psf.upfronthosting.co.za>
Message-ID: <E1Q5Sir-000299-00@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0fb0fbd442b4 by Victor Stinner in branch 'default':
Issue #11393: New try to fix faulthandler_thread()
http://hg.python.org/cpython/rev/0fb0fbd442b4

----------

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

From report at bugs.python.org  Fri Apr  1 03:17:37 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Apr 2011 01:17:37 +0000
Subject: [issue11393] Integrate faulthandler module into Python 3.3
In-Reply-To: <1299194385.57.0.300728524683.issue11393@psf.upfronthosting.co.za>
Message-ID: <E1Q5SzY-0003Ds-1t@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3558eecd84f0 by Victor Stinner in branch 'default':
Issue #11393: fix usage of locks in faulthandler
http://hg.python.org/cpython/rev/3558eecd84f0

----------

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

From report at bugs.python.org  Fri Apr  1 03:20:23 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Apr 2011 01:20:23 +0000
Subject: [issue4657] Doctest gets line numbers wrongs with <> in name
In-Reply-To: <1229242886.47.0.883564319605.issue4657@psf.upfronthosting.co.za>
Message-ID: <1301620823.3.0.995980329078.issue4657@psf.upfronthosting.co.za>


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

I have a vague memory of changing some code, in linecache I think, that involved anonymous names.  I might have fixed it by accident.

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

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

From report at bugs.python.org  Fri Apr  1 03:46:56 2011
From: report at bugs.python.org (Eli Stevens)
Date: Fri, 01 Apr 2011 01:46:56 +0000
Subject: [issue11734] Add half-float (16-bit) support to struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1301622416.92.0.709427959343.issue11734@psf.upfronthosting.co.za>


Eli Stevens <wickedgrey at gmail.com> added the comment:

Initial patch; tests pass.  A couple notes:

- I manually excised some commented changes to structmodule.{h,c} from the .patch; once I get a determination on if those files need to be updated or not I will discard the changes or implement what needs to be done there.  Hopefully I didn't damage the patch while editing.

- The code in _PyFloat_Pack2 and _PyFloat_Unpack2 is adapted from the numpy code in https://github.com/numpy/numpy/blob/master/numpy/core/src/npymath/halffloat.c .  This means that it is BSD licensed; I'm presuming that is acceptable for inclusion in CPython.  If not, I'll try a clean-room implementation.

----------
keywords: +patch
Added file: http://bugs.python.org/file21497/cpython-struct-float16-v1.patch

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

From report at bugs.python.org  Fri Apr  1 05:12:59 2011
From: report at bugs.python.org (mangeletti)
Date: Fri, 01 Apr 2011 03:12:59 +0000
Subject: [issue11735] Python Crash on strftime with %f
In-Reply-To: <1301627579.13.0.817048852294.issue11735@psf.upfronthosting.co.za>
Message-ID: <1301627579.13.0.817048852294.issue11735@psf.upfronthosting.co.za>


New submission from mangeletti <michael at angelettigroup.com>:

Win XP 32 bit 2.7.4

>>> import time
>>> time.strftime('%m/%d/%Y %H:%M:%S')
'03/31/2011 20:04:52'
>>> # ^^^ works fine
>>> time.strftime('%m/%d/%Y %H:%M:%S:%f')  # Oops, forgot `time.strftime` doesn't provide microseconds

Python crashes

Error Signature (sorry, didn't get full log):

AppName: python.exe	 AppVer: 0.0.0.0	 ModName: msvcr90.dll
ModVer: 9.0.30729.4148	 Offset: 0005bbac


I've never patched Python, but I might try to give it a whirl.

----------
components: Library (Lib)
messages: 132727
nosy: mangeletti
priority: normal
severity: normal
status: open
title: Python Crash on strftime with %f
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri Apr  1 08:12:46 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Fri, 01 Apr 2011 06:12:46 +0000
Subject: [issue11735] Python Crash on strftime with %f
In-Reply-To: <1301627579.13.0.817048852294.issue11735@psf.upfronthosting.co.za>
Message-ID: <1301638366.02.0.7862234167.issue11735@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

Hm, I can't reproduce this on darwin:

Python 2.7.1 (r271:86832, Jan 26 2011, 19:17:30) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.strftime('%m/%d/%Y %H:%M:%S:%f')
'03/31/2011 23:11:59:f'

----------
nosy: +santa4nt

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

From report at bugs.python.org  Fri Apr  1 08:33:18 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 01 Apr 2011 06:33:18 +0000
Subject: [issue6457] subprocess.Popen.communicate can lose data from
	output/error streams when broken input pipe occures
In-Reply-To: <1247229365.37.0.486388451669.issue6457@psf.upfronthosting.co.za>
Message-ID: <1301639598.04.0.607249734975.issue6457@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Closing as duplicate of #10963. See #10963 for more discussion.

----------
nosy: +rosslagerwall
resolution:  -> duplicate
status: open -> closed

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

From report at bugs.python.org  Fri Apr  1 08:34:04 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 01 Apr 2011 06:34:04 +0000
Subject: [issue10963] "subprocess" can raise OSError (EPIPE) when
	communicating with short-lived processes
In-Reply-To: <1295555014.31.0.879687826689.issue10963@psf.upfronthosting.co.za>
Message-ID: <1301639644.21.0.952014474611.issue10963@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Marked #6457 as a duplicate. See #6457 for more discussion.

----------
nosy: +Yaniv.Aknin, amaury.forgeotdarc, dwalczak, mcrute

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

From report at bugs.python.org  Fri Apr  1 08:43:20 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 01 Apr 2011 06:43:20 +0000
Subject: [issue11735] Python Crash on strftime with %f
In-Reply-To: <1301627579.13.0.817048852294.issue11735@psf.upfronthosting.co.za>
Message-ID: <1301640200.43.0.611985061624.issue11735@psf.upfronthosting.co.za>


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

This is a duplicate of issue10762, and only concerns the Windows C runtime library.

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed
superseder:  -> strftime('%f') segfault

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

From report at bugs.python.org  Fri Apr  1 09:55:13 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 01 Apr 2011 07:55:13 +0000
Subject: [issue11734] Add half-float (16-bit) support to struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1301644513.64.0.804231192146.issue11734@psf.upfronthosting.co.za>


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


----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Fri Apr  1 09:58:09 2011
From: report at bugs.python.org (Mark Wiebe)
Date: Fri, 01 Apr 2011 07:58:09 +0000
Subject: [issue11734] Add half-float (16-bit) support to struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1301644689.23.0.537464553473.issue11734@psf.upfronthosting.co.za>


Mark Wiebe <mwwiebe at gmail.com> added the comment:

Taking a look at the patch, I see you're using the single -> half conversion routine from NumPy. This has the double rounding problem when converting double -> float -> half, so it would be better to use the double -> half routine. I implemented it with 64-bit unsigned ints, so if there are platforms not supporting 64-bit ints, something else such as using the 32-bit routine will have to be done there.

----------
nosy: +mwiebe

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

From report at bugs.python.org  Fri Apr  1 10:19:35 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Fri, 01 Apr 2011 08:19:35 +0000
Subject: [issue10762] strftime('%f') segfault
In-Reply-To: <1293098262.29.0.661167233963.issue10762@psf.upfronthosting.co.za>
Message-ID: <1301645975.36.0.107700283535.issue10762@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

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

From report at bugs.python.org  Fri Apr  1 10:33:09 2011
From: report at bugs.python.org (=?utf-8?q?Greg_S=C5=82odkowicz?=)
Date: Fri, 01 Apr 2011 08:33:09 +0000
Subject: [issue9325] Add an option to pdb/trace/profile to run library module
	as a script
In-Reply-To: <1279743902.96.0.66207849175.issue9325@psf.upfronthosting.co.za>
Message-ID: <1301646789.28.0.409784419492.issue9325@psf.upfronthosting.co.za>


Changes by Greg S?odkowicz <jergosh at gmail.com>:


----------
nosy: +Greg.Slodkowicz

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

From report at bugs.python.org  Fri Apr  1 11:32:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2011 09:32:37 +0000
Subject: [issue11393] Integrate faulthandler module into Python 3.3
In-Reply-To: <1299194385.57.0.300728524683.issue11393@psf.upfronthosting.co.za>
Message-ID: <1301650357.24.0.274848668314.issue11393@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The last commits fixed test_faulthandler on FreeBSD, there are no more faulthandler bugs. Close this issue gain.

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

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

From report at bugs.python.org  Fri Apr  1 12:14:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Apr 2011 10:14:30 +0000
Subject: [issue11393] Integrate faulthandler module into Python 3.3
In-Reply-To: <1299194385.57.0.300728524683.issue11393@psf.upfronthosting.co.za>
Message-ID: <E1Q5bN6-0008SZ-IE@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset e51d8a160a8a by Victor Stinner in branch 'default':
Issue #11393: fault handler uses raise(signum) for SIGILL on Windows
http://hg.python.org/cpython/rev/e51d8a160a8a

New changeset a4fa79b0d478 by Victor Stinner in branch 'default':
Issue #11393: The fault handler handles also SIGABRT
http://hg.python.org/cpython/rev/a4fa79b0d478

----------

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

From report at bugs.python.org  Fri Apr  1 13:10:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Apr 2011 11:10:43 +0000
Subject: [issue11393] Integrate faulthandler module into Python 3.3
In-Reply-To: <1299194385.57.0.300728524683.issue11393@psf.upfronthosting.co.za>
Message-ID: <E1Q5cFV-0004Ha-Br@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a27755b10448 by Victor Stinner in branch 'default':
Issue #11393: Fix faulthandler.disable() and add a test
http://hg.python.org/cpython/rev/a27755b10448

----------

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

From report at bugs.python.org  Fri Apr  1 14:49:56 2011
From: report at bugs.python.org (Mads Kiilerich)
Date: Fri, 01 Apr 2011 12:49:56 +0000
Subject: [issue11736] windows installers ssl module / openssl broken for some
	sites
In-Reply-To: <1301662196.21.0.598409652154.issue11736@psf.upfronthosting.co.za>
Message-ID: <1301662196.21.0.598409652154.issue11736@psf.upfronthosting.co.za>


New submission from Mads Kiilerich <mads at kiilerich.com>:

(Probably the same root cause as issue11725 and using the same test case and analysis, but it seems like it isn't just somebody elses problem.)

Expected behaviour:

C:\Python26>python --version

Python 2.6.4


C:\Python26>python -c "import urllib2; urllib2.urlopen('https://www.finratrace.org')"

Traceback (most recent call last):

  File "<string>", line 1, in <module>

  File "C:\Python26\lib\urllib2.py", line 124, in urlopen

    return _opener.open(url, data, timeout)

  File "C:\Python26\lib\urllib2.py", line 395, in open

    response = meth(req, response)

  File "C:\Python26\lib\urllib2.py", line 508, in http_response

    'http', request, response, code, msg, hdrs)

  File "C:\Python26\lib\urllib2.py", line 433, in error

    return self._call_chain(*args)

  File "C:\Python26\lib\urllib2.py", line 367, in _call_chain

    result = func(*args)

  File "C:\Python26\lib\urllib2.py", line 516, in http_error_default

    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)

urllib2.HTTPError: HTTP Error 403: Forbidden



but

	

C:\Python26>python --version

Python 2.6.5



C:\Python26>python -c "import urllib2; urllib2.urlopen('https://www.finratrace.org')"
(hangs...)

the same behaviour is seen on all following versions up to 2.7.1.

I guess the Python windows installer started to contain an openssl that changed something?

I think this has caused a number of strange Mercurial bug reports.

----------
components: Windows
messages: 132736
nosy: kiilerix
priority: normal
severity: normal
status: open
title: windows installers ssl module / openssl broken for some sites
versions: Python 2.7

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

From report at bugs.python.org  Fri Apr  1 14:52:25 2011
From: report at bugs.python.org (Mads Kiilerich)
Date: Fri, 01 Apr 2011 12:52:25 +0000
Subject: [issue11725] httplib and urllib2 failed ssl connection
	httplib.BadStatusLine
In-Reply-To: <1301550234.98.0.946954388837.issue11725@psf.upfronthosting.co.za>
Message-ID: <1301662345.52.0.593573186393.issue11725@psf.upfronthosting.co.za>


Mads Kiilerich <mads at kiilerich.com> added the comment:

I have filed issue11736 as a more or less related (or bogus) issue.

----------
nosy: +kiilerix

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

From report at bugs.python.org  Fri Apr  1 15:40:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Apr 2011 13:40:00 +0000
Subject: [issue11393] Integrate faulthandler module into Python 3.3
In-Reply-To: <1299194385.57.0.300728524683.issue11393@psf.upfronthosting.co.za>
Message-ID: <E1Q5eZy-0000h7-Vr@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7e3ed426962f by Victor Stinner in branch 'default':
Issue #11393: _Py_DumpTraceback() writes the header even if there is no frame
http://hg.python.org/cpython/rev/7e3ed426962f

New changeset e609105dff64 by Victor Stinner in branch 'default':
Issue #11393: signal of user signal displays tracebacks even if tstate==NULL
http://hg.python.org/cpython/rev/e609105dff64

----------

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

From report at bugs.python.org  Fri Apr  1 15:57:38 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 01 Apr 2011 13:57:38 +0000
Subject: [issue11736] windows installers ssl module / openssl broken for some
	sites
In-Reply-To: <1301662196.21.0.598409652154.issue11736@psf.upfronthosting.co.za>
Message-ID: <1301666258.08.0.266864260243.issue11736@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
nosy: +orsenthil

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

From report at bugs.python.org  Fri Apr  1 16:00:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Apr 2011 14:00:13 +0000
Subject: [issue11727] Add a --timeout option to regrtest.py using the
	faulthandler module
In-Reply-To: <1301566785.42.0.872105634784.issue11727@psf.upfronthosting.co.za>
Message-ID: <E1Q5etX-0002qz-8p@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 15f6fe139181 by Victor Stinner in branch 'default':
Issue #11727: set regrtest default timeout to 15 minutes
http://hg.python.org/cpython/rev/15f6fe139181

----------

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

From report at bugs.python.org  Fri Apr  1 16:22:56 2011
From: report at bugs.python.org (Iain Henderson)
Date: Fri, 01 Apr 2011 14:22:56 +0000
Subject: [issue11737] and is not a logical conjugation
In-Reply-To: <1301667776.1.0.962151448477.issue11737@psf.upfronthosting.co.za>
Message-ID: <1301667776.1.0.962151448477.issue11737@psf.upfronthosting.co.za>


New submission from Iain Henderson <the_iain at mac.com>:

The documentation here: http://docs.python.org/library/stdtypes.html
indicates that and operates as such
{if x:
    return x
else:
    return y}

to be a logical conjugation it should function as
{if x:
    if y:
        return True
return False}

The it is now (False and True) will return True.  Basic logic asserts that this is not the case.

----------
messages: 132740
nosy: the_iain
priority: normal
severity: normal
status: open
title: and is not a logical conjugation
versions: Python 2.7

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

From report at bugs.python.org  Fri Apr  1 16:35:00 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Apr 2011 14:35:00 +0000
Subject: [issue11737] and is not a logical conjugation
In-Reply-To: <1301667776.1.0.962151448477.issue11737@psf.upfronthosting.co.za>
Message-ID: <1301668500.83.0.0910925174194.issue11737@psf.upfronthosting.co.za>


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

The doc[0] says:
"""
x and y: if x is false, then x, else y
"""
Boolean operators in Python always return one of the two values (rather than True/False), and they are also short-circuit operators, so:
  * if x is false, the whole expression is false regardless of the value of y, so x is returned without evaluating y;
  * if x is true, y could be either:
    * true: so the whole expression is true and y is returned;
    * false: so the whole expression is false and y is returned;

>>> '' and True
''
>>> True and ''
''
>>> True and 15
15

The behavior matches the documentation and (False and True) returns False, because x (False in this case) is false.

[0]: http://docs.python.org/library/stdtypes.html#boolean-operations-and-or-not

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

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

From report at bugs.python.org  Fri Apr  1 16:40:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Apr 2011 14:40:00 +0000
Subject: [issue10966] eliminate use of ImportError implicitly representing
	SkipTest
In-Reply-To: <1295566830.75.0.786153857799.issue10966@psf.upfronthosting.co.za>
Message-ID: <1301668800.38.0.0691958250597.issue10966@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 to Ezio?s last message.

----------

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

From report at bugs.python.org  Fri Apr  1 17:01:10 2011
From: report at bugs.python.org (Daniel Goertzen)
Date: Fri, 01 Apr 2011 15:01:10 +0000
Subject: [issue6501] Fatal error on startup with invalid PYTHONIOENCODING
In-Reply-To: <1247826105.17.0.941734297485.issue6501@psf.upfronthosting.co.za>
Message-ID: <1301670070.88.0.284031804334.issue6501@psf.upfronthosting.co.za>


Daniel Goertzen <daniel.goertzen at gmail.com> added the comment:

I run into this problem when I start a Python app as a subprocess from Erlang (open_port() function).  The PYTHONIOENCODING fix works when I launch my py app via pythonw.exe, but it does *not* work when I use the cx-freeze version of the app.

I am using the Win32GUI base for cx-freeze which appears to be a thin WinMain() wrapper around Py_Initialize().  I am going to continue investigating the cx-freeze related problems.

I am using Python 3.2 under Windows.  The failure is basically silent under Windows (generic MSVC runtime error), so I wasted a lot time figuring out what the problem actually was.  Python 2 doesn't seem to have this problem.

----------
nosy: +Daniel.Goertzen

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

From report at bugs.python.org  Fri Apr  1 17:19:00 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 01 Apr 2011 15:19:00 +0000
Subject: [issue11715] Building Python on multiarch Debian and Ubuntu
In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za>
Message-ID: <1301671140.48.0.550948674638.issue11715@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

"As I see it, the patch is uncontroversial for 3.3, 3.2, and 2.7.  And it definitely will not be applied to 3.0.  That leaves 2.5, 2.6, and 3.1.  If you really care one way or the other, please register your vote in the tracker."

2.5: +0
2.6: +1
3.1: +1

----------

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

From report at bugs.python.org  Fri Apr  1 17:30:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Apr 2011 15:30:15 +0000
Subject: [issue11715] Building Python on multiarch Debian and Ubuntu
In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za>
Message-ID: <1301671815.49.0.369909735764.issue11715@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m not opposed to the change.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Apr  1 17:38:57 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2011 15:38:57 +0000
Subject: [issue11727] Add a --timeout option to regrtest.py using the
	faulthandler module
In-Reply-To: <1301566785.42.0.872105634784.issue11727@psf.upfronthosting.co.za>
Message-ID: <1301672337.18.0.587623947855.issue11727@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Great! The timeout works:
-------------------------------------
...
[ 25/354] test_threadsignals
Thread 0xa000ed88:
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_threadsignals.py", line 46 in test_signals
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/unittest/case.py", line 442 in run
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/unittest/case.py", line 494 in __call__
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/support.py", line 1078 in run
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/support.py", line 1166 in _run_suite
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/support.py", line 1192 in run_unittest
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_threadsignals.py", line 210 in test_main
  File "./Lib/test/regrtest.py", line 1032 in runtest_inner
  File "./Lib/test/regrtest.py", line 826 in runtest
  File "./Lib/test/regrtest.py", line 650 in main
  File "./Lib/test/regrtest.py", line 1607 in <module>
make: *** [buildbottest] Error 1
program finished with exit code 2
elapsedTime=1103.489396
-------------------------------------
http://www.python.org/dev/buildbot/all/builders/PPC%20Tiger%203.x/builds/1685/steps/test/logs/stdio

Compare it without the same failure without the timeout:
-------------------------------------
...
[106/354] test_threadsignals

command timed out: 3600 seconds without output, killing pid 1745
process killed by signal 9
program finished with exit code -1
elapsedTime=4785.840329
-------------------------------------
http://www.python.org/dev/buildbot/all/builders/PPC%20Tiger%203.x/builds/1684/steps/test/logs/stdio

Thanks to this timeout, the build stops after 18 minutes instead of 80 minutes.... 18 minutes including the timeout of 15 minutes :-)

test_threadsignals hangs at:
----------------
class ThreadSignals(unittest.TestCase):
    def test_signals(self):
        signalled_all.acquire()
        self.spawnSignallingThread()
        signalled_all.acquire() <~~~~ here
        ...
----------------

self.spawnSignallingThread() calls:
----------------
def send_signals():
    os.kill(process_pid, signal.SIGUSR1)
    os.kill(process_pid, signal.SIGUSR2)
    signalled_all.release()
----------------

----------

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

From report at bugs.python.org  Fri Apr  1 17:55:32 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 01 Apr 2011 15:55:32 +0000
Subject: [issue11715] Building Python on multiarch Debian and Ubuntu
In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za>
Message-ID: <1301673332.59.0.527907213223.issue11715@psf.upfronthosting.co.za>


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

2.5: -1
2.6: -0
3.1: +0

As I see it, a large part of the "security fixes only" rule is for the benefit of folks auditing those security fixes, as it means there's very little noise in the branch to confuse the matter.

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

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

From report at bugs.python.org  Fri Apr  1 17:55:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2011 15:55:36 +0000
Subject: [issue11738] ThreadSignals.test_signals() of test_threadsignals hangs
	on PPC Tiger 3.x buildbot
In-Reply-To: <1301673336.69.0.136519124397.issue11738@psf.upfronthosting.co.za>
Message-ID: <1301673336.69.0.136519124397.issue11738@psf.upfronthosting.co.za>


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

Thanks to the new faulthandler module (#11393) and regrtest timeout (#11727, timeout of 15 minutes), I finally found why test_threadsignals hangs on PPC Tiger 3.x:
-------------------------------------
...
[ 25/354] test_threadsignals
Thread 0xa000ed88:
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_threadsignals.py", line 46 in test_signals
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/unittest/case.py", line 442 in run
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/unittest/case.py", line 494 in __call__
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/support.py", line 1078 in run
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/support.py", line 1166 in _run_suite
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/support.py", line 1192 in run_unittest
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_threadsignals.py", line 210 in test_main
  File "./Lib/test/regrtest.py", line 1032 in runtest_inner
  File "./Lib/test/regrtest.py", line 826 in runtest
  File "./Lib/test/regrtest.py", line 650 in main
  File "./Lib/test/regrtest.py", line 1607 in <module>
make: *** [buildbottest] Error 1
program finished with exit code 2
elapsedTime=1103.489396
-------------------------------------
http://www.python.org/dev/buildbot/all/builders/PPC%20Tiger%203.x/builds/1685/steps/test/logs/stdio

test_threadsignals hangs at:
----------------
class ThreadSignals(unittest.TestCase):
    def test_signals(self):
        signalled_all.acquire()
        self.spawnSignallingThread()
        signalled_all.acquire() <~~~~ here
        ...
----------------

self.spawnSignallingThread() calls:
----------------
def send_signals():
    os.kill(process_pid, signal.SIGUSR1)
    os.kill(process_pid, signal.SIGUSR2)
    signalled_all.release()
----------------

Before fixing the bug, we can workaroung the hang in the test using a timeout on the second acquire.

This issue may be related to #11223.

----------
assignee: ronaldoussoren
components: Interpreter Core, Macintosh, Tests
keywords: buildbot
messages: 132748
nosy: haypo, pitrou, ronaldoussoren, sable
priority: normal
severity: normal
status: open
title: ThreadSignals.test_signals() of test_threadsignals hangs on PPC Tiger 3.x buildbot
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Apr  1 18:02:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2011 16:02:43 +0000
Subject: [issue11738] ThreadSignals.test_signals() of test_threadsignals hangs
	on PPC Tiger 3.x buildbot
In-Reply-To: <1301673336.69.0.136519124397.issue11738@psf.upfronthosting.co.za>
Message-ID: <1301673763.87.0.219964946969.issue11738@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The trace is supposed to contain the traceback of all threads, and I see only one thread. So I suppose that send_signals() thread has exited. I don't know if it raises an exception or was interrupted before calling signalled_all.release().

----------

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

From report at bugs.python.org  Fri Apr  1 18:19:03 2011
From: report at bugs.python.org (Joaquin Sorianello)
Date: Fri, 01 Apr 2011 16:19:03 +0000
Subject: [issue11739] Python doesn't have a 2011 april fools joke
In-Reply-To: <1301674743.91.0.697715232995.issue11739@psf.upfronthosting.co.za>
Message-ID: <1301674743.91.0.697715232995.issue11739@psf.upfronthosting.co.za>


New submission from Joaquin Sorianello <joac at joac.com.ar>:

I found this bug today, and I am really sad.

We need to create a really good joke.
This languaje takes his name from "Monty Python Flying Circus" and IMHO this makes this languaje more funny.

I hope we can fix this for the next year.

Sorry if you considerate this a lost of time.

Best Regards

----------
components: None
messages: 132750
nosy: joac
priority: normal
severity: normal
status: open
title: Python doesn't have a 2011 april fools joke
type: feature request

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

From report at bugs.python.org  Fri Apr  1 18:30:19 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Apr 2011 16:30:19 +0000
Subject: [issue11690] Devguide: Add "communication" FAQ
In-Reply-To: <1301188192.33.0.9529618781.issue11690@psf.upfronthosting.co.za>
Message-ID: <1301675419.57.0.804525051324.issue11690@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/issue11690>
_______________________________________

From report at bugs.python.org  Fri Apr  1 18:33:03 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Apr 2011 16:33:03 +0000
Subject: [issue11710] Landing pages in docs for standard library packages
In-Reply-To: <1301401907.02.0.216152132906.issue11710@psf.upfronthosting.co.za>
Message-ID: <1301675583.67.0.814674542584.issue11710@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/issue11710>
_______________________________________

From report at bugs.python.org  Fri Apr  1 18:35:24 2011
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 01 Apr 2011 16:35:24 +0000
Subject: [issue11739] Python doesn't have a 2011 april fools joke
In-Reply-To: <1301674743.91.0.697715232995.issue11739@psf.upfronthosting.co.za>
Message-ID: <1301675724.36.0.187966999562.issue11739@psf.upfronthosting.co.za>


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

+1.  That was the first thing I looked for when I checked
my email today.

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

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

From report at bugs.python.org  Fri Apr  1 18:37:19 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Apr 2011 16:37:19 +0000
Subject: [issue11739] Python doesn't have a 2011 april fools joke
In-Reply-To: <1301674743.91.0.697715232995.issue11739@psf.upfronthosting.co.za>
Message-ID: <1301675839.08.0.88595023987.issue11739@psf.upfronthosting.co.za>


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


----------
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Apr  1 18:40:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Apr 2011 16:40:23 +0000
Subject: [issue11727] Add a --timeout option to regrtest.py using the
	faulthandler module
In-Reply-To: <1301566785.42.0.872105634784.issue11727@psf.upfronthosting.co.za>
Message-ID: <E1Q5hOW-0000ef-9Q@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 053bc5ca199b by Victor Stinner in branch 'default':
Issue #11727: set regrtest default timeout to 30 minutes
http://hg.python.org/cpython/rev/053bc5ca199b

----------

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

From report at bugs.python.org  Fri Apr  1 18:40:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Apr 2011 16:40:39 +0000
Subject: [issue11705] sys.excepthook doesn't work in imported modules
In-Reply-To: <1301351356.06.0.0947935400826.issue11705@psf.upfronthosting.co.za>
Message-ID: <1301676039.1.0.922138557745.issue11705@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +Valery.Lesin, amaury.forgeotdarc, benjamin.peterson, haypo, pitrou

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

From report at bugs.python.org  Fri Apr  1 18:42:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Apr 2011 16:42:43 +0000
Subject: [issue11710] Landing pages in docs for standard library packages
In-Reply-To: <1301401907.02.0.216152132906.issue11710@psf.upfronthosting.co.za>
Message-ID: <1301676163.42.0.298539827576.issue11710@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It works with docs.python.org/py3k/library/urllib

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Apr  1 18:44:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Apr 2011 16:44:43 +0000
Subject: [issue11723] Add support for mingw64 compiler
In-Reply-To: <1301503307.11.0.347710648609.issue11723@psf.upfronthosting.co.za>
Message-ID: <1301676283.56.0.967211799426.issue11723@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

As Mingw64 support is not currently claimed in the documentation, this is a feature request and can?t land in stable versions.  I suggest you wait a bit for the merge of distutils2 into the standard library an then refresh your patch.

----------
assignee:  -> tarek
components: +Distutils2 -Extension Modules
nosy: +alexis, eric.araujo, tarek
title: No proper support for mingw64 - patch to add -> Add support for mingw64 compiler
type: behavior -> feature request
versions: +Python 3.3 -Python 2.7

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

From report at bugs.python.org  Fri Apr  1 18:46:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Apr 2011 16:46:46 +0000
Subject: [issue11733] Implement a `Counter.elements_count` method
In-Reply-To: <1301607638.51.0.474843371118.issue11733@psf.upfronthosting.co.za>
Message-ID: <1301676406.35.0.877642364319.issue11733@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Apr  1 18:49:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2011 16:49:24 +0000
Subject: [issue11727] Add a --timeout option to regrtest.py using the
	faulthandler module
In-Reply-To: <1301566785.42.0.872105634784.issue11727@psf.upfronthosting.co.za>
Message-ID: <1301676564.07.0.677998309754.issue11727@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Failures on the default branch with a timeout of 15 minutes:

 - test_io on "x86 FreeBSD 3.x"
 - test_signal on "x86 FreeBSD 7.2 3.x"
 - test_stdin_none on "sparc solaris10 gcc 3.x"

I think that the tests failed because the buildbot is slow, not because of a hang. These tests did not fail before. So I changed the timeout from 15 minutes to 30 minutes.

Trace of the "x86 FreeBSD 3.x" failure:
--------------
...
[  2/354] test_io
Thread 0x081f3000:
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/unittest/case.py", line 574 in assertRaises
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_io.py", line 2647 in check_interrupted_write
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_io.py", line 2669 in test_interrupted_write_buffered
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/unittest/case.py", line 442 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/unittest/case.py", line 494 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/support.py", line 1078 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/support.py", line 1166 in _run_suite
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/support.py", line 1192 in run_unittest
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_io.py", line 2845 in test_main
  File "./Lib/test/regrtest.py", line 1032 in runtest_inner
  File "./Lib/test/regrtest.py", line 826 in runtest
  File "./Lib/test/regrtest.py", line 650 in main
  File "./Lib/test/regrtest.py", line 1607 in <module>
--------------

Trace of the "x86 FreeBSD 7.2 3.x" failure:
-----------
...
[ 19/354] test_signal
Thread 0x28401040:
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_signal.py", line 436 in test_itimer_real
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 442 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 494 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1078 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1166 in _run_suite
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1192 in run_unittest
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_signal.py", line 490 in test_main
  File "./Lib/test/regrtest.py", line 1032 in runtest_inner
  File "./Lib/test/regrtest.py", line 826 in runtest
  File "./Lib/test/regrtest.py", line 650 in main
  File "./Lib/test/regrtest.py", line 1607 in <module>
-----------
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%207.2%203.x/builds/1643/steps/test/logs/stdio

Trace of the Solaris failure:
------------
...
[277/354] test_subprocess
[37361 refs]
[37361 refs]
[37366 refs]
[37363 refs]
[37363 refs]
[37363 refs]
[37363 refs]
[37363 refs]
[37361 refs]
[37361 refs]
[37361 refs]
[37363 refs]
[37363 refs]
[37362 refs]
[37591 refs]
[37363 refs]
[37365 refs]
[37363 refs]
[37363 refs]
[44594 refs]
[37590 refs]
[37363 refs]
[37362 refs]
[37363 refs]
[37363 refs]
[37363 refs]
[37364 refs]
[37362 refs]
.
[37364 refs]
[37362 refs]
    this bit of output is from a test of stdout in a different process ...
[37362 refs]
[37362 refs]
[37590 refs]
[37590 refs]
[37363 refs]
[37361 refs]
[37361 refs]
[37361 refs]
[37361 refs]
[37363 refs]
[37372 refs]
[37372 refs]
[37372 refs]
[37363 refs]
[37372 refs]
[37363 refs]
[37372 refs]
[37363 refs]
[37372 refs]
[37363 refs]
[37372 refs]
[37363 refs]
[37372 refs]
[37363 refs]
[37372 refs]
[37363 refs]
[37372 refs]
[37363 refs]
[37372 refs]
[37363 refs]
[37372 refs]
[37363 refs]
[37372 refs]
[37363 refs]
[37364 refs]
[37365 refs]
[37361 refs]
[37361 refs]
[37361 refs]
[37361 refs]
[37362 refs]
[37364 refs]
[37363 refs]
[37368 refs]
[37366 refs]
[37368 refs]
[37366 refs]
[37363 refs]
[37361 refs]
[37361 refs]
[37361 refs]
[37361 refs]
[37361 refs]
[37361 refs]
[37366 refs]
[37363 refs]
[37363 refs]
[37363 refs]
[37363 refs]
[37363 refs]
[37363 refs]
[37372 refs]
[37372 refs]
[37361 refs]
[37361 refs]
[37361 refs]
[37363 refs]
[37363 refs]
[37362 refs]
[37591 refs]
[37363 refs]
[37365 refs]
[37363 refs]
[37363 refs]
[44594 refs]
[37372 refs]
[37363 refs]
[37372 refs]
[37363 refs]
[37372 refs]
[37363 refs]
[37372 refs]
[37363 refs]
[37372 refs]
[37363 refs]
[37372 refs]
[37363 refs]
[37372 refs]
[37363 refs]
[37372 refs]
[37363 refs]
[37372 refs]
[37363 refs]
[37372 refs]
[37363 refs]
[37372 refs]
[37363 refs]
[37364 refs]
[37590 refs]
[37365 refs]
[37361 refs]
[37361 refs]
[37361 refs]
[37361 refs]
[37362 refs]
[37364 refs]
[37363 refs]
[37362 refs]
[37363 refs]
[37363 refs]
[37363 refs]
[37364 refs]
[37362 refs]
.
[37364 refs]
[37362 refs]
    this bit of output is from a test of stdout in a different process ...
[37362 refs]
[37363 refs]
[37368 refs]
[37366 refs]
[37368 refs]
[37366 refs]
[37362 refs]
[37590 refs]
[37590 refs]
[37361 refs]
[37361 refs]
[37366 refs]
[37363 refs]
[37363 refs]
[37363 refs]
[37363 refs]
[37363 refs]
[37361 refs]
[37361 refs]
[37361 refs]
[37363 refs]
[37363 refs]
[37362 refs]
[37591 refs]
[37363 refs]
[37365 refs]
[37363 refs]
[37363 refs]
[44594 refs]
[37590 refs]
[37363 refs]
[37362 refs]
[37363 refs]
[37363 refs]
[37363 refs]
[37364 refs]
[37362 refs]
.
[37364 refs]
[37362 refs]
    this bit of output is from a test of stdout in a different process ...
[37362 refs]
[37362 refs]
[37590 refs]
[37590 refs]
[37361 refs]
[37361 refs]
[37366 refs]
[37363 refs]
[37363 refs]
[37363 refs]
[37363 refs]
[37363 refs]
[37361 refs]
[37361 refs]
[37361 refs]
[37363 refs]
[37363 refs]
[37362 refs]
[37591 refs]
[37363 refs]
[37365 refs]
[37363 refs]
[37363 refs]
[44594 refs]
[37590 refs]
[37363 refs]
[37363 refs]
[37362 refs]
[37363 refs]
[37363 refs]
Thread 0x00000001:
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/subprocess.py", line 466 in _eintr_retry_call
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/subprocess.py", line 1479 in _try_wait
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/subprocess.py", line 1521 in wait
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test_subprocess.py", line 155 in test_stdin_none
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/unittest/case.py", line 442 in run
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/unittest/case.py", line 494 in __call__
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/unittest/suite.py", line 105 in run
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/unittest/suite.py", line 67 in __call__
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/unittest/suite.py", line 105 in run
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/unittest/suite.py", line 67 in __call__
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/support.py", line 1078 in run
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/support.py", line 1166 in _run_suite
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/support.py", line 1192 in run_unittest
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test_subprocess.py", line 1607 in test_main
  File "./Lib/test/regrtest.py", line 1032 in runtest_inner
  File "./Lib/test/regrtest.py", line 826 in runtest
  File "./Lib/test/regrtest.py", line 650 in main
  File "./Lib/test/regrtest.py", line 1607 in <module>
*** Error code 1
make: Fatal error: Command failed for target `buildbottest'
------------
http://www.python.org/dev/buildbot/all/builders/sparc%20solaris10%20gcc%203.x/builds/2861/steps/test/logs/stdio

----------

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

From report at bugs.python.org  Fri Apr  1 18:51:02 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 01 Apr 2011 16:51:02 +0000
Subject: [issue11710] Landing pages in docs for standard library packages
In-Reply-To: <1301401907.02.0.216152132906.issue11710@psf.upfronthosting.co.za>
Message-ID: <1301676662.49.0.393283805958.issue11710@psf.upfronthosting.co.za>


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

That link goes to a 404 error page for me.

----------

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

From report at bugs.python.org  Fri Apr  1 18:52:08 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Fri, 01 Apr 2011 16:52:08 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1301676728.72.0.453943254055.issue10791@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Is following change in GzipFile class enough:

    def read1(self, n):
        return self.read(n)

? This satisfies TextIOWrapper to run readline correctly.

----------
nosy: +gruszczy

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

From report at bugs.python.org  Fri Apr  1 18:52:19 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 01 Apr 2011 16:52:19 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1301676739.26.0.832327067927.issue11707@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

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

From report at bugs.python.org  Fri Apr  1 18:54:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Apr 2011 16:54:19 +0000
Subject: [issue11710] Landing pages in docs for standard library packages
In-Reply-To: <1301401907.02.0.216152132906.issue11710@psf.upfronthosting.co.za>
Message-ID: <1301676859.24.0.523017484624.issue11710@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Okay, now I understand your request: a spam package should have a page at library/spam in addition to submodules pages.  +1.

----------
versions: +Python 2.7, Python 3.1

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

From report at bugs.python.org  Fri Apr  1 18:56:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Apr 2011 16:56:28 +0000
Subject: [issue11340] test_distutils fails because of borked compress program
In-Reply-To: <1298752200.14.0.360216595971.issue11340@psf.upfronthosting.co.za>
Message-ID: <1301676988.36.0.970611158207.issue11340@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for opening #11678 for the feature request.  To fix this in all versions, we would need a way to find that the current OS is Arch, and/or that the compress program is faulty.  Do you know how to do that?  Maybe with lsb_release?

----------
components: +Distutils2
nosy: +alexis
title: test_distutils fails -> test_distutils fails because of borked compress program
versions: +3rd party, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Apr  1 19:06:25 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 01 Apr 2011 17:06:25 +0000
Subject: [issue11710] Landing pages in docs for standard library packages
In-Reply-To: <1301401907.02.0.216152132906.issue11710@psf.upfronthosting.co.za>
Message-ID: <1301677585.74.0.78769663358.issue11710@psf.upfronthosting.co.za>


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

Oh, I see the confusion - yeah, the missing "library" in the URL in my first post was just a typo. It was actually present in my test URLs (otherwise the 4 packages with landing pages wouldn't have worked).

The problem in 2.7 is smaller, since there aren't as a many packages - only xml and xmlrpc are missing landing pages in that version.

----------

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

From report at bugs.python.org  Fri Apr  1 19:16:35 2011
From: report at bugs.python.org (Eli Stevens)
Date: Fri, 01 Apr 2011 17:16:35 +0000
Subject: [issue11734] Add half-float (16-bit) support to struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1301678195.83.0.786912034503.issue11734@psf.upfronthosting.co.za>


Eli Stevens <wickedgrey at gmail.com> added the comment:

I'm thinking of taking the current float implementation and wrapping it with something like:

#if HAS_INT64_TYPE
    // double implementation goes here
#else
    // float implementation here (what's in the current patch)
    ...
#endif

Does this seem like a reasonable approach?

Is there a CPython-canonical way to spell "HAS_INT64_TYPE" and/or find out what type that is on the current platform?

----------

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

From report at bugs.python.org  Fri Apr  1 19:28:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2011 17:28:33 +0000
Subject: [issue11705] sys.excepthook doesn't work in imported modules
In-Reply-To: <1301351356.06.0.0947935400826.issue11705@psf.upfronthosting.co.za>
Message-ID: <1301678913.02.0.245587773146.issue11705@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

python -c "import loggingTest" calls PyRun_SimpleStringFlags(). python import_loggingTest.py (import_loggingTest.py just contains "import loggingTest") calls PyRun_SimpleFileExFlags(). Both functions calls PyErr_Print() on error.

An error occurs ("raise Exception" in loggingTest.py) while importing the module, in PyImport_ExecCodeModuleEx().

The real problem is that the module is cleared because it raised an error. Extract of PyImport_ExecCodeModuleEx:

    v = PyEval_EvalCode((PyCodeObject *)co, d, d);
    if (v == NULL)
        goto error;
    ...
  error:
    remove_module(name);

(remove_module() does something like del sys.modules['loggingTest']: because there is only once reference, the destructor of the module is called)

--

You can workaround this corner case by keeping a reference to all used objects using a closure:

-----------
def create_closure(logger, print_exception):
    def handleException(excType, excValue, traceback):
            print_exception(excType, excValue, traceback)
            print "inside exception handler: logger = %s" % logger
            logger.error("Uncaught exception", exc_info=(excType, excValue, traceback))
    return handleException

sys.excepthook = create_closure(logger, tb.print_exception)
-----------

----------

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

From report at bugs.python.org  Fri Apr  1 19:51:37 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 01 Apr 2011 17:51:37 +0000
Subject: [issue11736] windows installers ssl module / openssl broken for some
	sites
In-Reply-To: <1301662196.21.0.598409652154.issue11736@psf.upfronthosting.co.za>
Message-ID: <1301680297.65.0.0267075183071.issue11736@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


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

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

From report at bugs.python.org  Fri Apr  1 20:08:26 2011
From: report at bugs.python.org (Anthony Tuininga)
Date: Fri, 01 Apr 2011 18:08:26 +0000
Subject: [issue6501] Fatal error on startup with invalid PYTHONIOENCODING
In-Reply-To: <1247826105.17.0.941734297485.issue6501@psf.upfronthosting.co.za>
Message-ID: <1301681306.99.0.536069773984.issue6501@psf.upfronthosting.co.za>


Changes by Anthony Tuininga <anthony.tuininga at gmail.com>:


----------
nosy: +atuining

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

From report at bugs.python.org  Fri Apr  1 20:11:50 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 01 Apr 2011 18:11:50 +0000
Subject: [issue11715] Building Python on multiarch Debian and Ubuntu
In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za>
Message-ID: <1301681510.05.0.0407472669524.issue11715@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
nosy: +sandro.tosi

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

From report at bugs.python.org  Fri Apr  1 20:24:51 2011
From: report at bugs.python.org (Carl Meyer)
Date: Fri, 01 Apr 2011 18:24:51 +0000
Subject: [issue6087] distutils.sysconfig.get_python_lib gives surprising
	result when used with a Python build
In-Reply-To: <1242995950.24.0.540152639281.issue6087@psf.upfronthosting.co.za>
Message-ID: <1301682291.64.0.260817508409.issue6087@psf.upfronthosting.co.za>


Changes by Carl Meyer <carl at dirtcircle.com>:


----------
nosy: +carljm

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

From report at bugs.python.org  Fri Apr  1 21:01:43 2011
From: report at bugs.python.org (Eli Stevens)
Date: Fri, 01 Apr 2011 19:01:43 +0000
Subject: [issue11734] Add half-float (16-bit) support to struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1301684503.25.0.16694526201.issue11734@psf.upfronthosting.co.za>


Eli Stevens <wickedgrey at gmail.com> added the comment:

I've spelled "HAS_INT64_TYPE" as follows:

+#if SIZEOF_LONG == 8 || SIZEOF_LONG_LONG == 8
+#if SIZEOF_LONG == 8
+    typedef unsigned long npy_uint64;
+#else
+#if SIZEOF_LONG_LONG == 8
+    typedef unsigned long long npy_uint64;
+#endif
+#endif
...

I left the Unpack2 function using floats, since there's no rounding issues there, and it didn't feel like the extra code complexity was justified.  If there's disagreement on that point, I can make a similar change for Unpack2.

----------
Added file: http://bugs.python.org/file21498/cpython-struct-float16-v2.patch

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

From report at bugs.python.org  Fri Apr  1 21:13:13 2011
From: report at bugs.python.org (Mark Wiebe)
Date: Fri, 01 Apr 2011 19:13:13 +0000
Subject: [issue11734] Add half-float (16-bit) support to struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1301685193.54.0.85396188899.issue11734@psf.upfronthosting.co.za>


Mark Wiebe <mwwiebe at gmail.com> added the comment:

I think this won't work on Windows since there the 64-bit int is generally __int64.  If you look at the long long and unsigned long long support in _struct.c you can see a better way to do this: "#ifdef HAVE_LONG_LONG" and "unsigned PY_LONG_LONG" for the type.

----------

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

From report at bugs.python.org  Fri Apr  1 21:40:42 2011
From: report at bugs.python.org (Eli Stevens)
Date: Fri, 01 Apr 2011 19:40:42 +0000
Subject: [issue11734] Add half-float (16-bit) support to struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1301686842.6.0.61511893168.issue11734@psf.upfronthosting.co.za>


Eli Stevens <wickedgrey at gmail.com> added the comment:

Ahh, yes, much cleaner.  Thank you.  :)  I'll remove the previous version.

----------
Added file: http://bugs.python.org/file21499/cpython-struct-float16-v3.patch

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

From report at bugs.python.org  Fri Apr  1 21:40:47 2011
From: report at bugs.python.org (Eli Stevens)
Date: Fri, 01 Apr 2011 19:40:47 +0000
Subject: [issue11734] Add half-float (16-bit) support to struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1301686847.27.0.826808883675.issue11734@psf.upfronthosting.co.za>


Changes by Eli Stevens <wickedgrey at gmail.com>:


Removed file: http://bugs.python.org/file21498/cpython-struct-float16-v2.patch

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

From report at bugs.python.org  Fri Apr  1 22:33:43 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 01 Apr 2011 20:33:43 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1301690023.68.0.852950481345.issue11707@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <stutzbach at google.com>:


----------
nosy: +stutzbach

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

From report at bugs.python.org  Fri Apr  1 23:08:52 2011
From: report at bugs.python.org (Jeff Dean)
Date: Fri, 01 Apr 2011 21:08:52 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za>
Message-ID: <1301692132.39.0.171681232066.issue7443@psf.upfronthosting.co.za>


Jeff Dean <chimalus at gmail.com> added the comment:

> * Patch Py_DeleteFileW in posixmodule.c so that it renames before
> deleting: should solve the problem overall but obviously has a
> possible wider impact, in general and on performance in particular.
> This rename might be a simple rename-to-guid or something more
> sophisticated such as the rename-to-recycler which cygwin uses.
> 
> * Patch support.unlink in the test package to do the rename dance on
> the basis that it'll fix at least some of the problems with less
> impact overall.
> 
> Opinions? I'm willing to do either.

I vote for fixing the test package.

File system "extensions" may track and record this activity.  To use DropBox as an example, doing the rename and delete will cause the renamed and deleted file to be recorded.

Just my opinion, but the code path to delete a file should be as short as possible.  Making lots of other OS calls just doesn't seem right.

I understand the wish to have a reliable unlink call but I'd be uncomfortable with a workaround that may be visible around the edges.

----------
nosy: +jdigital

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

From report at bugs.python.org  Fri Apr  1 23:25:39 2011
From: report at bugs.python.org (Michael O'Rourke)
Date: Fri, 01 Apr 2011 21:25:39 +0000
Subject: [issue11740] difflib html diff takes extremely long
In-Reply-To: <1301693139.57.0.361562219135.issue11740@psf.upfronthosting.co.za>
Message-ID: <1301693139.57.0.361562219135.issue11740@psf.upfronthosting.co.za>


New submission from Michael O'Rourke <mkorourk at adobe.com>:

If you try to difference the attached files with difflib and a html difference it take 10 minutes or more. In comparison other differencing tools like windiff and araxis merge will show the diff within a second.

Example code I'm using is:


sourceText = open("source.xml", "rU").readlines()
targetText = open("target.xml", "rU").readlines()

html_diff = difflib.HtmlDiff(tabsize=4)
result = html_diff.make_file(sourceText, targetText, "Source", "Target", context=True, numlines=10)
f = open('c:/libdiff_html.html', 'w')
f.write(result)
finish()

----------
components: None
files: Example.zip
messages: 132767
nosy: mkorourk at adobe.com
priority: normal
severity: normal
status: open
title: difflib html diff takes extremely long
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file21500/Example.zip

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

From report at bugs.python.org  Fri Apr  1 23:55:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2011 21:55:52 +0000
Subject: [issue11727] Add a --timeout option to regrtest.py using the
	faulthandler module
In-Reply-To: <1301566785.42.0.872105634784.issue11727@psf.upfronthosting.co.za>
Message-ID: <1301694952.8.0.228509456009.issue11727@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

(oh, "sparc solaris10 gcc 3.x" failed on test_subprocess, test_stdin_none is the function, not the file)

With a timeout of 30 minutes:

 - "sparc solaris10 gcc 3.x" doesn't fail anymore.
 - "x86 FreeBSD 3.x" still fails on the same test: test_io (test_interrupted_write_buffered)
 - "x86 FreeBSD 7.2 3.x" fails on another test: test_socket (test_sendall_interrupted)

"x86 FreeBSD 7.2 3.x" trace:
----------
...
[201/354] test_socket
Thread 0x28401040:
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_socket.py", line 729 in check_sendall_interrupted
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_socket.py", line 740 in test_sendall_interrupted
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 442 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 494 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1078 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1166 in _run_suite
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1192 in run_unittest
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_socket.py", line 2052 in test_main
  File "./Lib/test/regrtest.py", line 1032 in runtest_inner
  File "./Lib/test/regrtest.py", line 826 in runtest
  File "./Lib/test/regrtest.py", line 650 in main
  File "./Lib/test/regrtest.py", line 1607 in <module>
----------
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%207.2%203.x/builds/1644/steps/test/logs/stdio

"x86 FreeBSD 3.x" trace:
----------
...
[ 54/354] test_io
Thread 0x081f3000:
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/unittest/case.py", line 574 in assertRaises
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_io.py", line 2647 in check_interrupted_write
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_io.py", line 2669 in test_interrupted_write_buffered
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/unittest/case.py", line 442 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/unittest/case.py", line 494 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/support.py", line 1078 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/support.py", line 1166 in _run_suite
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/support.py", line 1192 in run_unittest
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_io.py", line 2845 in test_main
  File "./Lib/test/regrtest.py", line 1032 in runtest_inner
  File "./Lib/test/regrtest.py", line 826 in runtest
  File "./Lib/test/regrtest.py", line 650 in main
  File "./Lib/test/regrtest.py", line 1607 in <module>
----------
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%203.x/builds/1343/steps/test/logs/stdio

Reopen the issue because the story is not completly finished.

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

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

From report at bugs.python.org  Sat Apr  2 00:06:49 2011
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Fri, 01 Apr 2011 22:06:49 +0000
Subject: [issue11340] test_distutils fails because of borked compress program
In-Reply-To: <1298752200.14.0.360216595971.issue11340@psf.upfronthosting.co.za>
Message-ID: <1301695609.64.0.03019856882.issue11340@psf.upfronthosting.co.za>


Westley Mart?nez <anikom15 at gmail.com> added the comment:

I've already got a patch ready for #11678.

As for checking the compress command, perhaps we can accomplish it by comparing version information of the program:


$ compress --version
compress 1.4
Copyright (C) 2007 Free Software Foundation, Inc.
Copyright (C) 1993 Jean-loup Gailly.
This is free software.  You may redistribute copies of it under the terms of
the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
There is NO WARRANTY, to the extent permitted by law.

Written by Jean-loup Gailly.


The last line may be the key. It says Jean-loup Gailly; he invented the gzip compression method, but not the LZW method used by the original compress program.

----------

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

From report at bugs.python.org  Sat Apr  2 00:18:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2011 22:18:14 +0000
Subject: [issue11727] Add a --timeout option to regrtest.py using the
	faulthandler module
In-Reply-To: <1301566785.42.0.872105634784.issue11727@psf.upfronthosting.co.za>
Message-ID: <1301696294.52.0.163237527789.issue11727@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Because the timeout was 30 minutes, we missed where test_ssl hangs on "x86 Windows7 3.x":
--------------
...
[259/354] test_filecmp
[260/354] test_ssl

command timed out: 1200 seconds without output, killing pid 3012
SIGKILL failed to kill process
using fake rc=-1
program finished with exit code -1

remoteFailed: [Failure instance: Traceback from remote host -- Traceback (most recent call last):
Failure: buildbot.slave.commands.TimeoutError: SIGKILL failed to kill process
]
--------------
http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/2877/steps/test/logs/stdio

It looks like this buildbot has some network issues:

 * build 2877 failed on test_ssl
 * build 2872 failed on test_poplib
 * build 2866 failed on test_ftplib
 * build 2865 failed on test_smtplib
 * build 2864 failed on test_socket
 * ...

Note: build 2869 failed on test_multiprocessing.

----------

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

From report at bugs.python.org  Sat Apr  2 00:28:47 2011
From: report at bugs.python.org (Denis Barmenkov)
Date: Fri, 01 Apr 2011 22:28:47 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1301696927.98.0.657335338782.issue10496@psf.upfronthosting.co.za>


Denis Barmenkov <denis.barmenkov at gmail.com> added the comment:

I saw similar error on Python 2.6 installed on freeBSD.
I had test SVN server and wrote pre-commit hook using python. When remote developer commited his changes to repository, hook called os.path.expanduser and exception was raised:
        #  File "/usr/local/lib/python2.6/posixpath.py", line 259, in expanduser
        #    userhome = pwd.getpwuid(os.getuid()).pw_dir
        #KeyError: 'getpwuid(): uid not found: 12345'

So its not a just-Linux issue.

----------
nosy: +Denis.Barmenkov

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

From report at bugs.python.org  Sat Apr  2 00:37:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2011 22:37:12 +0000
Subject: [issue11727] Add a --timeout option to regrtest.py using the
	faulthandler module
In-Reply-To: <1301566785.42.0.872105634784.issue11727@psf.upfronthosting.co.za>
Message-ID: <1301697432.38.0.927572008998.issue11727@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

For test_subprocess timeout, see also:
http://bugs.python.org/issue8429#msg103368
For test_io timeout, see also: issue?#8431

----------

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

From report at bugs.python.org  Sat Apr  2 00:39:19 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 01 Apr 2011 22:39:19 +0000
Subject: [issue11674] list(obj),
	tuple(obj) swallow TypeError (in _PyObject_LengthHint)
In-Reply-To: <1301085490.36.0.28946733028.issue11674@psf.upfronthosting.co.za>
Message-ID: <1301697559.25.0.119144886866.issue11674@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Elvis, I agree that the masking is not nice. To call it a tracker bug (as opposed to design bug), you need to show that the behavior is different from what is documented. Of course, This issue illustrates why one should have unit tests that try to test each component as directly as possible.

>A certain amount of exception masking is inherent is Python's design. 

This issue comes up in other contexts, such as attribute access.

 >We use TypeError for a lot of things, including the exception raised by "len(obj)" when obj doesn't have length.

Using user-level Exceptions internally is convenient, but possibly a small design flaw. Leaving code breakage aside, would it be possible to define private, undocumented inaccessible-from-Python-code internal subclasses such as _TypeError that never show up in Python level tracebacks (absent extension errors)?

----------
nosy: +terry.reedy
stage:  -> test needed
type: behavior -> feature request

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

From report at bugs.python.org  Sat Apr  2 00:49:36 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 01 Apr 2011 22:49:36 +0000
Subject: [issue11674] list(obj),
	tuple(obj) swallow TypeError (in _PyObject_LengthHint)
In-Reply-To: <1301085490.36.0.28946733028.issue11674@psf.upfronthosting.co.za>
Message-ID: <1301698176.73.0.184299792063.issue11674@psf.upfronthosting.co.za>


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

I have a proposal: only call __length_hint__ on C types.

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

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

From report at bugs.python.org  Sat Apr  2 00:57:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2011 22:57:50 +0000
Subject: [issue11727] Add a --timeout option to regrtest.py using the
	faulthandler module
In-Reply-To: <1301566785.42.0.872105634784.issue11727@psf.upfronthosting.co.za>
Message-ID: <1301698670.56.0.973214350811.issue11727@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Timeout of 15 minutes on "x86 XP-4 3.x":
----------------------------
...
[334/354] test_threading
Thread 0x0000024c:
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 235 in wait
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 392 in f
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 37 in task

Thread 0x000002d8:
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 235 in wait
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 392 in f
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 37 in task

Thread 0x00000da4:
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 235 in wait
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 392 in f
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 37 in task

Thread 0x00000bb0:
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 16 in _wait
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 416 in _check_notify
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 433 in test_notify
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\case.py", line 387 in _executeTestPart
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\case.py", line 442 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\case.py", line 494 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 105 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 67 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 105 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 67 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\support.py", line 1078 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\support.py", line 1166 in _run_suite
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\support.py", line 1192 in run_unittest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_threading.py", line 728 in test_main
  File "../lib/test/regrtest.py", line 1032 in runtest_inner
  File "../lib/test/regrtest.py", line 826 in runtest
  File "../lib/test/regrtest.py", line 650 in main
  File "../lib/test/regrtest.py", line 1607 in <module>
s_push: parser stack overflow
program finished with exit code 1
elapsedTime=2601.059000
----------------------------
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4317/steps/test/logs/stdio

Hum, it looks like we have 4 threads, and all threads are waiting.

=> See issue #8799 and maybe also #4188 and #5114.

----------

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

From report at bugs.python.org  Sat Apr  2 01:06:37 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 Apr 2011 23:06:37 +0000
Subject: [issue11674] list(obj),
	tuple(obj) swallow TypeError (in _PyObject_LengthHint)
In-Reply-To: <1301085490.36.0.28946733028.issue11674@psf.upfronthosting.co.za>
Message-ID: <1301699197.28.0.373628590338.issue11674@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Am going to close this one because I don't see any straight-forward way around it and because it's technically not a bug (just an undesirable design artifact).  The use of TypeError for objects that don't define __len__ is deeply ingrained into Python (20 years).  If something inside a __len__ method raises a TypeError, it would be challenging to distinguish that from a missing __len__ method.  

[terry]
It might be possible to create internal subclasses of TypeError, AttributeError and whatnot, but that is a deep change with unknown implications for users, for other python implementations, for performance, for third-party modules, etc.  It would need a PEP and is likely to get rejected on a cost-benefit basis -- the substantial API churn wouldn't be worth the microscopic benefit (i.e. most people never encounter this or care about it).

[benjamin]
The __length_hint__ protocol is a public API, so anyone can use it.  Also, the issue is a broader than __length_hint__, it is really distinguishing multiple possible meanings for a TypeError raised by a call to __len__.

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

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

From report at bugs.python.org  Sat Apr  2 01:07:16 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 Apr 2011 23:07:16 +0000
Subject: [issue11661] test_collections.TestNamedTuple.test_source failing on
	many buildbots after f09f7ab40ce6
In-Reply-To: <1300968284.13.0.782582358366.issue11661@psf.upfronthosting.co.za>
Message-ID: <1301699236.73.0.923664541809.issue11661@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


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

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

From report at bugs.python.org  Sat Apr  2 01:10:21 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 01 Apr 2011 23:10:21 +0000
Subject: [issue11674] list(obj),
	tuple(obj) swallow TypeError (in _PyObject_LengthHint)
In-Reply-To: <1301699197.28.0.373628590338.issue11674@psf.upfronthosting.co.za>
Message-ID: <AANLkTim=p3c9UR8dEHv-axDHNk-ZTQb0sEhxpCZkwkTG@mail.gmail.com>


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

2011/4/1 Raymond Hettinger <report at bugs.python.org>:
> [benjamin]
> The __length_hint__ protocol is a public API, so anyone can use it. ?Also, the issue is a broader than __length_hint__, it is really distinguishing multiple possible meanings for a TypeError raised by a call to __len__.

What?? I certainly hope not. I thought it was supposed to be a performance hack.

----------

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

From report at bugs.python.org  Sat Apr  2 01:29:13 2011
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Fri, 01 Apr 2011 23:29:13 +0000
Subject: [issue11674] list(obj),
	tuple(obj) swallow TypeError (in _PyObject_LengthHint)
In-Reply-To: <1301085490.36.0.28946733028.issue11674@psf.upfronthosting.co.za>
Message-ID: <1301700553.56.0.722482281547.issue11674@psf.upfronthosting.co.za>


Elvis Pranskevichus <elprans at gmail.com> added the comment:

I guess, the best workaround would then be to use a decorator (or a metaclass) and wrap __len__ so that TypeError is caught and wrapped into some other exception.

On April 1, 2011 07:10:21 PM Benjamin Peterson wrote:
> What?? I certainly hope not. I thought it was supposed to be a performance
> hack.

__length_hint__ does indeed look like a hack and not a well-defined API.  It is also undocumented.

----------

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

From report at bugs.python.org  Sat Apr  2 01:39:29 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 01 Apr 2011 23:39:29 +0000
Subject: [issue11676] Improve imp.load_module and submodules doc
In-Reply-To: <1301089227.12.0.157951103986.issue11676@psf.upfronthosting.co.za>
Message-ID: <1301701169.01.0.138798729959.issue11676@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I verified this for 3.2 (and IDLE) with

import sys, tkinter
"ttk" in dir(sys.modules['tkinter']) # False
import tkinter.ttk
"ttk" in dir(sys.modules['tkinter']) # True

====reload========

import sys,imp
imp.load_module('tkinter',*imp.find_module('tkinter'))
imp.load_module('tkinter.ttk',*imp.find_module('ttk',
  sys.modules["tkinter"].__path__))
"ttk" in dir(sys.modules['tkinter']) # False
from tkinter import ttk # ImportError

Given that 'ttk' is only added to the tkinter entry when ttk is imported via tkinter, I am not surprised that the direct import with imp fails to affect the tkinter entry. Imp would have to notice that ttk is in a directory with __init__, get the name of the parent directory, and then check to see whether or not that parent had already been imported. Unlike import

import ttk #fails

imp does not require such a previous import:

imp.load_module('ttk',*imp.find_module('ttk',
 ["C:/programs/python32/Lib/tkinter"]))

succeeds, which shows again that import and imp act differently.

Dave, can you suggest added text and a location to put it?

Hmmm. How about after "If the load ...", add "A successful load does not affect previously loaded package modules as this function operates independently of package structure."

----------
nosy: +terry.reedy
title: imp.load_module and submodules - doc issue, or bug? -> Improve imp.load_module and submodules doc
versions: +Python 3.1, Python 3.2, Python 3.3 -Python 2.5, Python 2.6

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

From report at bugs.python.org  Sat Apr  2 01:56:50 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 01 Apr 2011 23:56:50 +0000
Subject: [issue11678] Add support for Arch
	Linux	to	platform.linux_distributions()
In-Reply-To: <1301098195.86.0.891765525403.issue11678@psf.upfronthosting.co.za>
Message-ID: <1301702210.01.0.524245832152.issue11678@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If today's multi-site message is not a joke, Arch, Debian, Gentoo, Grml, and openSUSE are about to be joined into the Canterbury distribution.

----------
nosy: +terry.reedy
stage:  -> patch review

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

From report at bugs.python.org  Sat Apr  2 02:06:28 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 02 Apr 2011 00:06:28 +0000
Subject: [issue11699] Doc for optparse.OptionParser.get_option_group is wrong
In-Reply-To: <1301301829.71.0.0713641718569.issue11699@psf.upfronthosting.co.za>
Message-ID: <1301702788.84.0.613751448296.issue11699@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Documentation for get_option_group is wrong -> Doc for optparse.OptionParser.get_option_group is wrong

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

From report at bugs.python.org  Sat Apr  2 02:08:49 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sat, 02 Apr 2011 00:08:49 +0000
Subject: [issue11740] difflib html diff takes extremely long
In-Reply-To: <1301693139.57.0.361562219135.issue11740@psf.upfronthosting.co.za>
Message-ID: <1301702929.15.0.522287572042.issue11740@psf.upfronthosting.co.za>


Changes by Filip Gruszczy?ski <gruszczy at gmail.com>:


----------
nosy: +gruszczy

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

From report at bugs.python.org  Sat Apr  2 02:26:39 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 02 Apr 2011 00:26:39 +0000
Subject: [issue11718] Teach IDLE's open-module command to find packages
In-Reply-To: <1301444586.78.0.773077705239.issue11718@psf.upfronthosting.co.za>
Message-ID: <1301703999.61.0.87594264375.issue11718@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I strongly agree. This would make it easy to see modules of 3rd party packages loaded, for instance, in site-packages. Once pack/__init__.py is opened, selecting File/Open in its edit window displays the package directory.

Dotted names work, but must be remembered

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Sat Apr  2 03:08:39 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 02 Apr 2011 01:08:39 +0000
Subject: [issue11726] linecache becomes specific to Python scripts in Python 3
In-Reply-To: <1301566082.59.0.198488725536.issue11726@psf.upfronthosting.co.za>
Message-ID: <1301706519.79.0.702124743663.issue11726@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The help(linecache) Description is more specific as to the intention (based on traceback usage):

"This is intended to read lines from modules imported -- hence if a filename is not found, it will look down the module search path for a file by that name."

My experiments show that this is too specific. It *can* read any file that it can find and decode as utf-8 (default, or you say, locale encoding or coding in cookie line). 

Find = absolute path
>>> linecache.getline('c:/programs/pydev/py32/LICENSE', 1)
'A. HISTORY OF THE SOFTWARE\n'

or relative path on sys.path
>>> linecache.getline('idlelib/ChangeLog', 1)
'Please refer to the IDLEfork and IDLE CVS repositories for\n'
>>> linecache.getline('idlelib/extend.txt', 1)
'Writing an IDLE extension\n'

Decode fails on byte illegal for utf-8:
>>> linecache.getline('idlelib/CREDITS.txt', 1)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xf6 in position 1566: invalid start byte

(It reads and decodes entire file even though only line 1 was requested. It choked on L?wis. I believe Py3 distributed text files should be utf-8 instead of latin-1.)

If I got rules right, doc should say "Filename must be an absolute path or relative path that can be found on sys.path." and "File must be utf-8 encoded or locale encoded or a Python file with a coding cookie."

(If you tried /etc/passwd, how did it fail?)

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Sat Apr  2 03:13:28 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 02 Apr 2011 01:13:28 +0000
Subject: [issue11730] Setting Invalid sys.stdin in interactive mode => loop
	forever.
In-Reply-To: <1301584644.8.0.189290691333.issue11730@psf.upfronthosting.co.za>
Message-ID: <1301706808.88.0.00407630304433.issue11730@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> test needed
title: Setting sys.stdin to an invalid input stream causes interpreter run loop forever. -> Setting Invalid sys.stdin in interactive mode =>  loop forever.

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

From report at bugs.python.org  Sat Apr  2 04:15:07 2011
From: report at bugs.python.org (ysj.ray)
Date: Sat, 02 Apr 2011 02:15:07 +0000
Subject: [issue11739] Python doesn't have a 2011 april fools joke
In-Reply-To: <1301674743.91.0.697715232995.issue11739@psf.upfronthosting.co.za>
Message-ID: <1301710507.99.0.265444591404.issue11739@psf.upfronthosting.co.za>


ysj.ray <ysj.ray at gmail.com> added the comment:

+1.  I was updating my hg clone all the time yesterday to see if there was anything interesting happened. But I was disappointed.

----------
nosy: +ysj.ray

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

From report at bugs.python.org  Sat Apr  2 04:34:13 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 02 Apr 2011 02:34:13 +0000
Subject: [issue11739] Python doesn't have a 2011 april fools joke
In-Reply-To: <1301674743.91.0.697715232995.issue11739@psf.upfronthosting.co.za>
Message-ID: <1301711653.67.0.652915365046.issue11739@psf.upfronthosting.co.za>


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

Perhaps 2012 will be extra special.

----------
nosy: +benjamin.peterson
resolution:  -> postponed
status: open -> closed

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

From report at bugs.python.org  Sat Apr  2 04:38:06 2011
From: report at bugs.python.org (ysj.ray)
Date: Sat, 02 Apr 2011 02:38:06 +0000
Subject: [issue11739] Python doesn't have a 2011 april fools joke
In-Reply-To: <1301674743.91.0.697715232995.issue11739@psf.upfronthosting.co.za>
Message-ID: <1301711886.6.0.183489015388.issue11739@psf.upfronthosting.co.za>


ysj.ray <ysj.ray at gmail.com> added the comment:

> Perhaps 2012 will be extra special.


I'm afraid 2012 April Fool may be the last April Fool of the world.

----------

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

From report at bugs.python.org  Sat Apr  2 06:15:03 2011
From: report at bugs.python.org (ysj.ray)
Date: Sat, 02 Apr 2011 04:15:03 +0000
Subject: [issue11740] difflib html diff takes extremely long
In-Reply-To: <1301693139.57.0.361562219135.issue11740@psf.upfronthosting.co.za>
Message-ID: <1301717703.77.0.18027980031.issue11740@psf.upfronthosting.co.za>


ysj.ray <ysj.ray at gmail.com> added the comment:

Reproduced in 3.3

----------
components: +Library (Lib) -None
nosy: +ysj.ray
versions: +Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Apr  2 06:33:01 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 02 Apr 2011 04:33:01 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za>
Message-ID: <1301718781.78.0.0223967183212.issue7443@psf.upfronthosting.co.za>


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

I'll throw in my 2 cents as to a possible way forward:

- fix test.support.unlink in all current maintenance branches (2.7, 3.1, 3.2, default)
- expose the feature to users as "shutil.rmfile" for 3.3

----------

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

From report at bugs.python.org  Sat Apr  2 07:21:27 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 02 Apr 2011 05:21:27 +0000
Subject: [issue11730] Setting Invalid sys.stdin in interactive mode => loop
	forever.
In-Reply-To: <1301584644.8.0.189290691333.issue11730@psf.upfronthosting.co.za>
Message-ID: <1301721687.85.0.506492792234.issue11730@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +haypo
stage: test needed -> needs patch

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

From report at bugs.python.org  Sat Apr  2 08:52:31 2011
From: report at bugs.python.org (Mark Hammond)
Date: Sat, 02 Apr 2011 06:52:31 +0000
Subject: [issue11717] conflicting definition of ssize_t in pyconfig.h
In-Reply-To: <1301443864.94.0.799403342642.issue11717@psf.upfronthosting.co.za>
Message-ID: <1301727151.28.0.539224220325.issue11717@psf.upfronthosting.co.za>


Mark Hammond <skippy.hammond at gmail.com> added the comment:

As Tim Roberts says on the python-win32 list:

> Actually, on closer examination, it may be a bit difficult to sell this.  The Microsoft compilers do not define this symbol at all.  The SDK defines SSIZE_T (as a long).  Nothing defines ssize_t. 

http://code.activestate.com/lists/python-win32/11231/ for the full post.

So yeah, the conclusion is that we shouldn't define such symbols incase someone else does too.  So conceptually I'm +1 on that patch (I'm yet to try it and probably will not get a chance for a week or 2)

----------

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

From report at bugs.python.org  Sat Apr  2 10:28:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 02 Apr 2011 08:28:54 +0000
Subject: [issue11730] Setting Invalid sys.stdin in interactive mode => loop
	forever.
In-Reply-To: <1301584644.8.0.189290691333.issue11730@psf.upfronthosting.co.za>
Message-ID: <1301732934.06.0.747279584934.issue11730@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I think that it is a duplicate of #8070.

----------
resolution:  -> duplicate
status: open -> closed

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

From report at bugs.python.org  Sat Apr  2 10:29:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 02 Apr 2011 08:29:10 +0000
Subject: [issue8070] Infinite loop in PyRun_InteractiveLoopFlags() if
	PyRun_InteractiveOneFlags() raises an error
In-Reply-To: <1267793425.09.0.566406511799.issue8070@psf.upfronthosting.co.za>
Message-ID: <1301732950.16.0.480984787727.issue8070@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Issue?#11730 has been marked as duplicate.

----------

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

From report at bugs.python.org  Sat Apr  2 10:43:08 2011
From: report at bugs.python.org (ysj.ray)
Date: Sat, 02 Apr 2011 08:43:08 +0000
Subject: [issue8070] Infinite loop in PyRun_InteractiveLoopFlags() if
	PyRun_InteractiveOneFlags() raises an error
In-Reply-To: <1267793425.09.0.566406511799.issue8070@psf.upfronthosting.co.za>
Message-ID: <1301733788.55.0.908667417365.issue8070@psf.upfronthosting.co.za>


ysj.ray <ysj.ray at gmail.com> added the comment:

I'd prefer not exit program but try to use Py_FileSystemDefaultEncoding as enc when sys.stdin is invalid. On most cases, setting sys.stdin to some other invalid value does means the program could not continue running.

----------

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

From report at bugs.python.org  Sat Apr  2 10:52:14 2011
From: report at bugs.python.org (ysj.ray)
Date: Sat, 02 Apr 2011 08:52:14 +0000
Subject: [issue8070] Infinite loop in PyRun_InteractiveLoopFlags() if
	PyRun_InteractiveOneFlags() raises an error
In-Reply-To: <1267793425.09.0.566406511799.issue8070@psf.upfronthosting.co.za>
Message-ID: <1301734334.53.0.969050695372.issue8070@psf.upfronthosting.co.za>


ysj.ray <ysj.ray at gmail.com> added the comment:

> On most cases, setting sys.stdin to some other invalid value does means the program could not continue running.


Sorry, it should be:

On most cases, setting sys.stdin to some other invalid value does not mean the program could not continue running.

----------

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

From report at bugs.python.org  Sat Apr  2 11:57:50 2011
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 02 Apr 2011 09:57:50 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za>
Message-ID: <1301738270.51.0.0243953266155.issue7443@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

FYI: implementation of unlink already has multiple calls for unicode version to process symlinks. Ansi version is the simple DeleteFileA call.
Now we have different behavior for unicode and ansi variants as I can see.

Now I'm working on unlink implementations partially borrowed from cygwin as Martin suggested. I still not have a final patch covering all known cases. Perhaps I can introduce it next week.

----------

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

From report at bugs.python.org  Sat Apr  2 12:27:46 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 02 Apr 2011 10:27:46 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1301740066.46.0.811537458694.issue10791@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nvawda

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

From report at bugs.python.org  Sat Apr  2 13:56:11 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sat, 02 Apr 2011 11:56:11 +0000
Subject: [issue11740] difflib html diff takes extremely long
In-Reply-To: <1301693139.57.0.361562219135.issue11740@psf.upfronthosting.co.za>
Message-ID: <1301745371.7.0.117232649738.issue11740@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

The culprit seems to be Differ._fancy_replace. There is a nasty quadratic loop there, that has pretty complex internal code. I have done a quick a fix, that makes example run below a second at the expense of not calling _fancy_replace for longer chunks and using _plain_replace instead.

Another solution for long chunks would be to split them into smaller parts and process separately. This way quadratic time will be smaller and we still can benefit from _fancy_helper logic.

----------
keywords: +patch
Added file: http://bugs.python.org/file21501/11740.patch

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

From report at bugs.python.org  Sat Apr  2 15:35:03 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 02 Apr 2011 13:35:03 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
	(issue4274045)
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1301751303.67.0.413930442474.issue5863@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Here is an updated patch that adds read1() to BZ2File. This should fix things
for issue10791 from the bz2 side. I also took the opportunity to clean up
_read_block() to be more readable. As per Martin's suggestion on python-dev, I
put the copyright notice in the patch header, rather than in the code itself.

----------
Added file: http://bugs.python.org/file21502/bz2-v5.diff

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

From report at bugs.python.org  Sat Apr  2 15:38:19 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 02 Apr 2011 13:38:19 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
	(issue4274045)
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1301751499.29.0.355989463994.issue5863@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Updated documentation.

----------
Added file: http://bugs.python.org/file21503/bz2-v5-doc.diff

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

From report at bugs.python.org  Sat Apr  2 16:02:23 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sat, 02 Apr 2011 14:02:23 +0000
Subject: [issue8905] difflib should accept arbitrary line iterators
In-Reply-To: <1275738341.19.0.989231664853.issue8905@psf.upfronthosting.co.za>
Message-ID: <1301752943.78.0.230147519493.issue8905@psf.upfronthosting.co.za>


Changes by Filip Gruszczy?ski <gruszczy at gmail.com>:


----------
nosy: +gruszczy

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

From report at bugs.python.org  Sat Apr  2 16:04:22 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sat, 02 Apr 2011 14:04:22 +0000
Subject: [issue6931] dreadful performance in difflib: ndiff and HtmlDiff
In-Reply-To: <1253199298.69.0.280559653373.issue6931@psf.upfronthosting.co.za>
Message-ID: <1301753062.68.0.366332141157.issue6931@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Check also this:

http://bugs.python.org/issue11740

----------
nosy: +gruszczy

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

From report at bugs.python.org  Sat Apr  2 16:11:39 2011
From: report at bugs.python.org (cournapeau david)
Date: Sat, 02 Apr 2011 14:11:39 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1301753499.65.0.317871008633.issue4709@psf.upfronthosting.co.za>


cournapeau david <cournape at gmail.com> added the comment:

Hi Martin,

It was nice meeting you at Pycon.

I finally took the time to set up a windows 64 bits environment, and here are the exact steps I needed to do to reproduce the issue, and fix it by hand:

  - Start fresh from windows 7 64 bits
  - clone python hg repository, and checkout the 2.6 branch (path referred as $PYTHON_ROOT from now on).
  - build python with VS 2008 pro, 64 bits (release mode)
  - install mingw-w64. I used this exact version: mingw-w64-1.0-bin_i686-mingw_20110328.zip (release 1.0, targetting win64 but running in 32 bits native mode), and unzipped it in C:?
  - I compiled a trivial C extension in foo.c as follows:

C:\mingw-w64\bin\x86_64-w64-mingw32-gcc.exe foo.c -I $PYTHON_ROOT\Include -I $PYTHON_ROOT\PC -shared -o foo.pyd  $PYTHON_ROOT\PCbuild\amd64\python26.lib -DMS_WIN64

The patch removes the need for defining MS_WIN64. I don't know exactly the policies for which branch this could be applied - anything below 2.6 does not make much sense since most win64 users use 2.6 at least. Ideally, it could be backported to 2.6, 2.7 and 3.1 ?

----------
nosy: +cournape

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

From report at bugs.python.org  Sat Apr  2 16:25:54 2011
From: report at bugs.python.org (Adam Matan)
Date: Sat, 02 Apr 2011 14:25:54 +0000
Subject: [issue11741] shutil2.copy fails with destination filenames
In-Reply-To: <1301754354.21.0.769652184716.issue11741@psf.upfronthosting.co.za>
Message-ID: <1301754354.21.0.769652184716.issue11741@psf.upfronthosting.co.za>


New submission from Adam Matan <adam at matan.name>:

shutil.copy2(file, dest) fails when dest has unicode characters:

[2011-04-02 17:19:54 adam at adam-laptop ~/personal :) ]$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import glob
>>> import shutil
>>> files=glob.glob('*.ods')
>>> for file in files:
...     shutil.copy2(file, '?') # This works, but:
...
>>> for file in files:
...     shutil.copy2(file, u'?')
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/usr/lib/python2.6/shutil.py", line 98, in copy2
    dst = os.path.join(dst, os.path.basename(src))
  File "/usr/lib/python2.6/posixpath.py", line 70, in join
    path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xd7 in position 1: ordinal not in range(128)


See discussion here: http://stackoverflow.com/questions/5523373/python-how-to-move-a-file-with-unicode-filename-to-a-unicode-folder/5523385#5523385

----------
components: Extension Modules
messages: 132799
nosy: Adam.Matan
priority: normal
severity: normal
status: open
title: shutil2.copy fails with destination filenames
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr  2 16:29:18 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 02 Apr 2011 14:29:18 +0000
Subject: [issue11741] shutil2.copy fails with destination filenames
In-Reply-To: <1301754354.21.0.769652184716.issue11741@psf.upfronthosting.co.za>
Message-ID: <1301754558.81.0.479063068331.issue11741@psf.upfronthosting.co.za>


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


----------
components: +Library (Lib) -Extension Modules
nosy: +ezio.melotti
stage:  -> test needed
type:  -> behavior

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

From report at bugs.python.org  Sat Apr  2 16:54:15 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 02 Apr 2011 14:54:15 +0000
Subject: [issue11741] shutil2.copy fails with destination filenames
In-Reply-To: <1301754354.21.0.769652184716.issue11741@psf.upfronthosting.co.za>
Message-ID: <1301756055.81.0.642642340544.issue11741@psf.upfronthosting.co.za>


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

The problem here is that you are mixing byte strings and unicode.
glob.glob('*.ods') returns a list of strings, so in shutil.copy2(file, '?') you are passing two byte strings and everything works fine.
In shutil.copy2(file, u'?') instead, file is a byte string, and u'?' is unicode, so the copy fails.
If you want to use u'?', you can pass u'*.ods' to glob.glob() in order to get a list of unicode strings from there too.

----------
resolution:  -> invalid
stage: test needed -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Apr  2 17:10:23 2011
From: report at bugs.python.org (Adam Matan)
Date: Sat, 02 Apr 2011 15:10:23 +0000
Subject: [issue11741] shutil2.copy fails with destination filenames
In-Reply-To: <1301754354.21.0.769652184716.issue11741@psf.upfronthosting.co.za>
Message-ID: <1301757023.4.0.183701376582.issue11741@psf.upfronthosting.co.za>


Adam Matan <adam at matan.name> added the comment:

Don't you think that shutil should be able to handle mixed data types, for example byte string as file name and unicode destination directory? This is, in my opinion, a very common scenario.

Would you consider converting all arguments to Unicode?

----------

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

From report at bugs.python.org  Sat Apr  2 17:10:32 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 02 Apr 2011 15:10:32 +0000
Subject: [issue11741] shutil2.copy fails with destination filenames
In-Reply-To: <1301754354.21.0.769652184716.issue11741@psf.upfronthosting.co.za>
Message-ID: <1301757032.73.0.546023764437.issue11741@psf.upfronthosting.co.za>


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

I should have added that both '?' and u'?' work as long as the file names in the list returned by glob() are ASCII: if u'?' is used they are simply coerced to unicode.
If there are non-ASCII file names in the glob() list, the copy fails because Python 2 tries to coerce the name to unicode decoding it implicitly with the 'ascii' codec, and that fails.

----------

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

From report at bugs.python.org  Sat Apr  2 17:42:11 2011
From: report at bugs.python.org (Andrew Sommerville)
Date: Sat, 02 Apr 2011 15:42:11 +0000
Subject: [issue11742] Possible bug in Python/import.c
In-Reply-To: <1301758931.53.0.147789887182.issue11742@psf.upfronthosting.co.za>
Message-ID: <1301758931.53.0.147789887182.issue11742@psf.upfronthosting.co.za>


New submission from Andrew Sommerville <aksommerville at gmail.com>:

Around line 1509 in Python/import.c, function "find_module", the importer is trying to fail with "No module named...". It is possible for "fp" to be NULL and "fdp" (the return value) to be non-NULL, which callers would see as success.

Solution: add "fdp=NULL;" to this block:
    if (fp == NULL) {
        PyErr_Format(PyExc_ImportError,
                     "No module named %.200s", name);
    }

(my apologies if this is not the correct place to post...)

----------
components: Interpreter Core
messages: 132803
nosy: aksommerville
priority: normal
severity: normal
status: open
title: Possible bug in Python/import.c
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr  2 18:09:04 2011
From: report at bugs.python.org (Patrick Gansterer)
Date: Sat, 02 Apr 2011 16:09:04 +0000
Subject: [issue8631] subprocess.Popen.communicate(...) hangs on Windows
In-Reply-To: <1273095906.37.0.582736332431.issue8631@psf.upfronthosting.co.za>
Message-ID: <1301760544.07.0.729689729952.issue8631@psf.upfronthosting.co.za>


Patrick Gansterer <paroga at paroga.com> added the comment:

I can reproduce this on WinXP with 2.5, 2.7 and 3.2. On my other box (Win7 64bit) the same code works without problems.
This problem happens only when I make a subprocess.call() to executables from my msysgit installation (e.g. echo, git). A call to 'notepad' or 'svn' works without problems.

After entering the following python does not respond to any input:
>>> import subprocess
>>> subprocess.call('echo')

----------
nosy: +paroga
versions: +Python 2.5, Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Apr  2 18:47:20 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 02 Apr 2011 16:47:20 +0000
Subject: [issue11678] Add support for Arch
	Linux	to	platform.linux_distributions()
In-Reply-To: <1301098195.86.0.891765525403.issue11678@psf.upfronthosting.co.za>
Message-ID: <1301762840.93.0.161899064809.issue11678@psf.upfronthosting.co.za>


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

And we all laughed :)

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Sat Apr  2 19:50:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Apr 2011 17:50:05 +0000
Subject: [issue10963] "subprocess" can raise OSError (EPIPE) when
	communicating with short-lived processes
In-Reply-To: <1301574920.0.0.273053702406.issue10963@psf.upfronthosting.co.za>
Message-ID: <1301766601.3494.2.camel@localhost.localdomain>


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

> I think it's best to remove all this inconsistency and fix it so that
> EPIPE is never generated and then backport it to 2.7, 3.1, 3.2.
> 
> Attached is a patch which fixes it for poll, select, windows and adds
> two tests.

The patch looks good to me.

----------

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

From report at bugs.python.org  Sat Apr  2 20:28:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Apr 2011 18:28:51 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
	(issue4274045)
In-Reply-To: <1301751303.67.0.413930442474.issue5863@psf.upfronthosting.co.za>
Message-ID: <1301768928.3494.36.camel@localhost.localdomain>


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

> Here is an updated patch that adds read1() to BZ2File. This should fix things
> for issue10791 from the bz2 side. I also took the opportunity to clean up
> _read_block() to be more readable. As per Martin's suggestion on python-dev, I
> put the copyright notice in the patch header, rather than in the code itself.

Thank you! A couple of comments:
- please avoid C++-style comments ("// ..."), some compilers don't like
them
- BZ2Decompressor.eof would be better as a T_BOOL than a T_INT, IMO
- BZ2Decompressor.eof should be documented as new in 3.3
- instead of using PyObject_GetBuffer(), I think it's better to call
PyArg_ParseTuple with the "y*" typecode: it makes sure it does the right
thing
- instead of "int(size)", use "size = size.__index__()" so as to forbid
floats

----------

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

From report at bugs.python.org  Sat Apr  2 22:19:28 2011
From: report at bugs.python.org (Adam Matan)
Date: Sat, 02 Apr 2011 20:19:28 +0000
Subject: [issue11741] shutil2.copy fails with destination filenames
In-Reply-To: <1301754354.21.0.769652184716.issue11741@psf.upfronthosting.co.za>
Message-ID: <1301775568.88.0.202067070498.issue11741@psf.upfronthosting.co.za>


Adam Matan <adam at matan.name> added the comment:

Don't you think it should be changed in Python 2.x, so that the ASCII filename will be automatically converted to to Unicode?

----------

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

From report at bugs.python.org  Sat Apr  2 22:22:27 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 02 Apr 2011 20:22:27 +0000
Subject: [issue11741] shutil2.copy fails with destination filenames
In-Reply-To: <1301754354.21.0.769652184716.issue11741@psf.upfronthosting.co.za>
Message-ID: <1301775747.4.0.12789310387.issue11741@psf.upfronthosting.co.za>


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

The ASCII filename is already converted to unicode, but in your case the program was most likely failing with some non-ASCII filename.

----------

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

From report at bugs.python.org  Sat Apr  2 22:25:36 2011
From: report at bugs.python.org (Adam Matan)
Date: Sat, 02 Apr 2011 20:25:36 +0000
Subject: [issue11741] shutil2.copy fails with destination filenames
In-Reply-To: <1301754354.21.0.769652184716.issue11741@psf.upfronthosting.co.za>
Message-ID: <1301775936.79.0.162197149393.issue11741@psf.upfronthosting.co.za>


Adam Matan <adam at matan.name> added the comment:

Do you think it should be fixed at the module level?

----------

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

From report at bugs.python.org  Sat Apr  2 22:33:29 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sat, 02 Apr 2011 20:33:29 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1301776409.83.0.870396002489.issue11707@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Here is a patch that passes functools tests. I'll be happy to work on it further.

----------
keywords: +patch
Added file: http://bugs.python.org/file21504/11707.patch

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

From report at bugs.python.org  Sat Apr  2 22:34:01 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 02 Apr 2011 20:34:01 +0000
Subject: [issue11741] shutil2.copy fails with destination filenames
In-Reply-To: <1301754354.21.0.769652184716.issue11741@psf.upfronthosting.co.za>
Message-ID: <1301776441.04.0.155816606179.issue11741@psf.upfronthosting.co.za>


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

Mixing byte and unicode strings should always be avoided, because the implicit coercion to unicode works only if the byte strings contains only ASCII, and fails otherwise.
Several modules -- including shutil, glob, and os.path -- have API that work with both byte and unicode strings, but fail when you mix the two:
>>> os.path.join('?', '?')  # both byte strings -- works
'\xd7\x90/\xd7\x90'
>>> os.path.join(u'?', u'?')  # both unicode -- works
u'\u05d0/\u05d0'
>>> os.path.join('a', u'?')  # mixed, ASCII-only byte string -- works
u'a/\u05d0'

>>> os.path.join(u'?', '?')  # mixed, non-ASCII -- fails
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/posixpath.py", line 70, in join
    path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xd7 in position 1: ordinal not in range(128)
>>> os.path.join('?', u'?')  # mixed, non-ASCII -- fails
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/posixpath.py", line 70, in join
    path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xd7 in position 0: ordinal not in range(128)
>>>

----------

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

From report at bugs.python.org  Sat Apr  2 22:39:51 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 02 Apr 2011 20:39:51 +0000
Subject: [issue11282] 3.3 unittest document not kept consist with code
In-Reply-To: <1298354999.37.0.375525915954.issue11282@psf.upfronthosting.co.za>
Message-ID: <1301776791.49.0.126606079832.issue11282@psf.upfronthosting.co.za>


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

Guido decided to leave the fail* methods and assertDictContainsSubset in 3.3 (and possibly even in the following versions), so that people moving from 2.7 to 3.3 don't have to change their code because these methods are missing.
Since assertSameElements is not in 2.7, it can be removed in 3.3.

I will therefore backout r88451 and add back the fail* methods and assertDictContainsSubset.

----------
nosy: +gvanrossum, rhettinger

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

From report at bugs.python.org  Sat Apr  2 22:47:22 2011
From: report at bugs.python.org (Eric Smith)
Date: Sat, 02 Apr 2011 20:47:22 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1301777242.72.0.64465684742.issue11707@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I haven't had time to look at this in detail, but the concept appears sound. I'll try to devote some time to it, but hopefully someone else on core-mentorship with more familiarity with this code will also be able to review it.

One thing: You don't want to delete the pure Python version, as that can be used by alternate implementations. You want to leave it in place, and then after it try to import the C version. If the import fails, the Python version will be used, if it succeeds, the C version will be used. I'm reasonably sure there are examples of testing both implementations elsewhere in the stdlib. Maybe ask on core-mentorship for pointers.

Thanks for working on this!

----------
nosy: +eric.smith

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

From report at bugs.python.org  Sat Apr  2 22:53:26 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sat, 02 Apr 2011 20:53:26 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1301777606.74.0.422447132235.issue11707@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Ok, here is patch that keep python implementation of cmp_to_key if C version can't be imported.

Thanks again for you help :-)

----------
Added file: http://bugs.python.org/file21505/11707_2.patch

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

From report at bugs.python.org  Sat Apr  2 23:33:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Apr 2011 21:33:02 +0000
Subject: [issue11743] Rewrite PipeConnection and Connection in pure Python
In-Reply-To: <1301779980.98.0.515045950536.issue11743@psf.upfronthosting.co.za>
Message-ID: <1301779980.98.0.515045950536.issue11743@psf.upfronthosting.co.za>


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

Here is a rewrite of multiprocessing.{PipeConnection,Connection} in pure Python, for ease of maintenance and improvement.

----------
components: Library (Lib)
files: mpconn.patch
keywords: patch
messages: 132816
nosy: asksol, brian.curtin, jnoller, pitrou, tim.golden
priority: normal
severity: normal
stage: patch review
status: open
title: Rewrite PipeConnection and Connection in pure Python
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file21506/mpconn.patch

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

From report at bugs.python.org  Sat Apr  2 23:40:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Apr 2011 21:40:00 +0000
Subject: [issue9205] Parent process hanging in multiprocessing if children
	terminate unexpectedly
In-Reply-To: <1278619251.36.0.833806205056.issue9205@psf.upfronthosting.co.za>
Message-ID: <1301780400.67.0.476177259846.issue9205@psf.upfronthosting.co.za>


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


----------
dependencies: +Rewrite PipeConnection and Connection in pure Python

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

From report at bugs.python.org  Sun Apr  3 00:19:54 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 02 Apr 2011 22:19:54 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1301782794.13.0.656792100315.issue11707@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Nice work.  There are a few nits (dealloc and traverse need to address both python objects in the struct).  I will look at the patch in detail when I get a chance (in the next week or so).

It would be great if more tests were added (in general, C equivalents require more testing than their pure Python counterparts).

If you get a chance, it would be great if we could see some timings to demonstrate that we're getting a significant improvement (that being the primary motivation for the patch).

----------

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

From report at bugs.python.org  Sun Apr  3 00:44:58 2011
From: report at bugs.python.org (Ka-Ping Yee)
Date: Sat, 02 Apr 2011 22:44:58 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1301784298.15.0.683633257101.issue2736@psf.upfronthosting.co.za>


Ka-Ping Yee <python at zesty.ca> added the comment:

> no one has come up with a satisfactory solution

Plenty have proposed a satisfactory solution.  No one has come up with a solution that is satisfactory to *you*, because you have overconstrained the problem.  The reason we still have no utctotimestamp() after all these years is that you, and you alone as far as I know, refuse to accept a method that inverts utcfromtimestamp() with microsecond precision over its working range.  Such a method is a perfectly reasonable and acceptable solution and would add a lot of value to Python as a language.

I suspect you don't realize just how much pain you have unintentionally caused the world of Python users by singlehandedly blocking progress on this issue.  I've seen them: students, friends, coworkers -- even very smart and capable people are stymied by it.  No one thinks of looking in the calendar module.  Maybe if you watched some of them struggle with this, you would understand.

> leave it as an exercise to the reader to solve

To take this perspective is to miss the point of Python.

----------

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

From report at bugs.python.org  Sun Apr  3 01:34:22 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 02 Apr 2011 23:34:22 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
	(issue4274045)
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1301787262.79.0.2065758755.issue5863@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Thanks for the review. I've made most of the changes you suggested, but there's
one thing I wanted to check about:

> - instead of "int(size)", use "size = size.__index__()" so as to forbid floats

The tests for readline() and readlines() expect a TypeError if size is None.
Calling size.__index__() in this case raises an AttributeError instead. Should I
change the tests to expect an AttributeError? Alternatively, something like this
would more closely match the behaviour of the old code:

    try:
        size = size.__index__()
    except AttributeError:
        raise TypeError("Integer argument expected")

----------

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

From report at bugs.python.org  Sun Apr  3 01:45:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Apr 2011 23:45:49 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
	(issue4274045)
In-Reply-To: <1301787262.79.0.2065758755.issue5863@psf.upfronthosting.co.za>
Message-ID: <1301787945.3494.38.camel@localhost.localdomain>


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

> The tests for readline() and readlines() expect a TypeError if size is None.
> Calling size.__index__() in this case raises an AttributeError instead. Should I
> change the tests to expect an AttributeError? Alternatively, something like this
> would more closely match the behaviour of the old code:
> 
>     try:
>         size = size.__index__()
>     except AttributeError:
>         raise TypeError("Integer argument expected")

Ah, you're right, TypeError should be raised.

----------

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

From report at bugs.python.org  Sun Apr  3 01:55:58 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 02 Apr 2011 23:55:58 +0000
Subject: [issue10712] 2to3 fixer for deprecated unittest method names
In-Reply-To: <1292441796.9.0.018359428873.issue10712@psf.upfronthosting.co.za>
Message-ID: <1301788558.45.0.879559171208.issue10712@psf.upfronthosting.co.za>


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


----------
assignee:  -> ezio.melotti

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

From report at bugs.python.org  Sun Apr  3 02:14:12 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 03 Apr 2011 00:14:12 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
	(issue4274045)
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1301789652.19.0.662270063744.issue5863@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Here's the updated patch.

----------
Added file: http://bugs.python.org/file21507/bz2-v6.diff

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

From report at bugs.python.org  Sun Apr  3 02:14:55 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 03 Apr 2011 00:14:55 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
	(issue4274045)
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1301789695.0.0.800572502684.issue5863@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

... and the corresponding updated documentation patch.

----------
Added file: http://bugs.python.org/file21508/bz2-v6-doc.diff

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

From report at bugs.python.org  Sun Apr  3 02:15:25 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Sun, 03 Apr 2011 00:15:25 +0000
Subject: [issue10762] strftime('%f') segfault
In-Reply-To: <1293098262.29.0.661167233963.issue10762@psf.upfronthosting.co.za>
Message-ID: <1301789725.57.0.208687725011.issue10762@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

There does not seem to be any mention of what an ANSI behavior should be upon encountering a non-supported format string. Hence, perhaps, the discrepancy among different platforms.

----------

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

From report at bugs.python.org  Sun Apr  3 02:15:31 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Sun, 03 Apr 2011 00:15:31 +0000
Subject: [issue10762] strftime('%f') segfault
In-Reply-To: <1293098262.29.0.661167233963.issue10762@psf.upfronthosting.co.za>
Message-ID: <1301789731.66.0.168806559774.issue10762@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
versions: +Python 3.3

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

From report at bugs.python.org  Sun Apr  3 02:35:44 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Sun, 03 Apr 2011 00:35:44 +0000
Subject: [issue10762] strftime('%f') segfault
In-Reply-To: <1293098262.29.0.661167233963.issue10762@psf.upfronthosting.co.za>
Message-ID: <1301790944.62.0.37190200704.issue10762@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

I don't think this is a Windows "bug" per se, because the behavior is undefined in the standards. The burden is up to us to validate the format string inputted [w]strftime and currently, our code mistakenly clears "%f" as valid.

I'm attaching a patch against 2.7 branch.

----------
keywords: +patch
Added file: http://bugs.python.org/file21509/issue11703.patch

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

From report at bugs.python.org  Sun Apr  3 02:43:38 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Sun, 03 Apr 2011 00:43:38 +0000
Subject: [issue10762] strftime('%f') segfault
In-Reply-To: <1293098262.29.0.661167233963.issue10762@psf.upfronthosting.co.za>
Message-ID: <1301791418.63.0.394840206734.issue10762@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


Removed file: http://bugs.python.org/file21509/issue11703.patch

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

From report at bugs.python.org  Sun Apr  3 02:44:45 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Sun, 03 Apr 2011 00:44:45 +0000
Subject: [issue10762] strftime('%f') segfault
In-Reply-To: <1293098262.29.0.661167233963.issue10762@psf.upfronthosting.co.za>
Message-ID: <1301791485.19.0.212405439071.issue10762@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

Wrong filename. Attaching again: against 2.7 and 3.1 branches.

----------
Added file: http://bugs.python.org/file21510/issue10762_py27.patch

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

From report at bugs.python.org  Sun Apr  3 02:44:52 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Sun, 03 Apr 2011 00:44:52 +0000
Subject: [issue10762] strftime('%f') segfault
In-Reply-To: <1293098262.29.0.661167233963.issue10762@psf.upfronthosting.co.za>
Message-ID: <1301791492.68.0.0873239525252.issue10762@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


Added file: http://bugs.python.org/file21511/issue10762_py31.patch

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

From report at bugs.python.org  Sun Apr  3 03:51:12 2011
From: report at bugs.python.org (Vlastimil Brom)
Date: Sun, 03 Apr 2011 01:51:12 +0000
Subject: [issue11744] re.LOCALE doesn't reflect locale.setlocale(...)
In-Reply-To: <1301795472.4.0.896243580236.issue11744@psf.upfronthosting.co.za>
Message-ID: <1301795472.4.0.896243580236.issue11744@psf.upfronthosting.co.za>


New submission from Vlastimil Brom <vlastimil.brom at gmail.com>:

Hi,
I just noticed a behaviour of the re.LOCALE flag I can't understand; I first reported this to the new regex implementation, which, however, only mimics the standard lib re in this case:
http://code.google.com/p/mrab-regex-hg/issues/detail?id=6
I also couldn't find anything relevant in the tracker, other than some older, already fixed issues; I'm sorry, if I missed something.
I thought, the search pattern (?L)\w would match any of the respective string.letters according to the current locale (and possibly additionally [0-9_]).

However, the locale doesn't seem to be reflected in an expected way.

>>> unicode_BMP = " " + "".join(unichr(i)for i in range(1, 0x10000))
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
'Czech_Czech Republic.1250'
>>> import re
>>> print("".join(re.findall(r"(?L)\w", unicode_BMP)))
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz??????????????????????????????????????????????????????????????????????????????????
>>> locale.setlocale(locale.LC_ALL, "Greek")
'Greek_Greece.1253'
>>> print("".join(re.findall(r"(?L)\w", unicode_BMP)))
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz?????????????????????????????????????????????????????????????????????????
>>> 

>>> unicode_BMP = " " + "".join(unichr(i)for i in range(1, 0x10000))

>>> locale.setlocale(locale.LC_ALL, "")
'Czech_Czech Republic.1250'
>>> print unicode(string.letters, "windows-1250")
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz??????????????????????????????????????????????????????????????????????????????????
>>> locale.setlocale(locale.LC_ALL, "Greek")
'Greek_Greece.1253'
>>> print unicode(string.letters, "windows-1253")
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz???????????????????????????????????????????????????????????????????????
>>> 

It seems that the nearest letter set to the result of the re/regex LOCALE flags migt be ascii or US locale:

>>> locale.setlocale(locale.LC_ALL, "US")
'English_United States.1252'
>>> print unicode(string.letters, "windows-1252")
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz?????????????????????????????????????????????????????????????????????????
>>> 

however, there are some differences too, namely between z? and ?
re (?L)\w : 
Czech
z??????????????????????
Greek
z????????????
string.letters -- US locale
z????????????
(as displayed in tkinter Idle shell)
(in either case, there are some items, one wouldn't consider usual word characters, cf. ?)

I am not sure whether there are no other issues (like some encoding/displaying peculiarities in Tkinter), but the re matching using the LOCALE flag don't reflect the locale.setlocale(...) in a transparent way.

Is it supposed to work this way and is there another possibility to get the expected locale aware matching, as one might expect according to:
http://docs.python.org/library/re.html#re.LOCALE
"""
Make \w, \W, \b, \B, \s and \S dependent on the current locale.
"""


using Python 2.7.1, 32 bit;  win 7 Home Premium 64-bit, Czech.

in Python 3.1.3 as well as 3.2 the result is the same (with the appropriately modified code): ...
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
'Czech_Czech Republic.1250'
>>> import re
>>> print("".join(re.findall(r"(?L)\w", unicode_BMP)))
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz??????????????????????????????????????????????????????????????????????????????????
>>> 

However, in Python 3, there is no comparison with string.letters available anymore.

Regards,
    Vlastimil Brom

----------
components: Regular Expressions, Unicode
messages: 132826
nosy: vbr
priority: normal
severity: normal
status: open
title: re.LOCALE doesn't reflect locale.setlocale(...)
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Apr  3 03:56:38 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 03 Apr 2011 01:56:38 +0000
Subject: [issue11744] re.LOCALE doesn't reflect locale.setlocale(...)
In-Reply-To: <1301795472.4.0.896243580236.issue11744@psf.upfronthosting.co.za>
Message-ID: <1301795798.73.0.200476704085.issue11744@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti, mrabarnett

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

From report at bugs.python.org  Sun Apr  3 03:59:24 2011
From: report at bugs.python.org (Denver Coneybeare)
Date: Sun, 03 Apr 2011 01:59:24 +0000
Subject: [issue1647489] zero-length match confuses re.finditer()
Message-ID: <1301795964.61.0.508794755362.issue1647489@psf.upfronthosting.co.za>


Denver Coneybeare <denver.coneybeare at gmail.com> added the comment:

I just re-tested this issue in trunk at changeset 053bc5ca199b and the issue is still exactly reproducible as originally reported.  That is, the match to the empty string skips a character of the match:

>>> import re
>>> [m.groups() for m in re.finditer(r'(^z*)|(\w+)', 'abc')]
[('', None), (None, 'bc')]

----------
nosy: +denversc

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

From report at bugs.python.org  Sun Apr  3 04:52:36 2011
From: report at bugs.python.org (Denver Coneybeare)
Date: Sun, 03 Apr 2011 02:52:36 +0000
Subject: [issue11745] idlelib/PyShell.py: incorrect module name reported in
	error message: Tkinter should be tkinter
In-Reply-To: <1301799156.61.0.675938234599.issue11745@psf.upfronthosting.co.za>
Message-ID: <1301799156.61.0.675938234599.issue11745@psf.upfronthosting.co.za>


New submission from Denver Coneybeare <denver.coneybeare at gmail.com>:

Just a very minor bug.  The error message in idlelib/PyShell.py that is printed when importing tkinter fails says that it failed to import "Tkinter", but the actual module name is "tkinter" (with a lowercase t).  

try:
    from tkinter import *
except ImportError:
    print("** IDLE can't import Tkinter.  " \
          "Your Python may not be configured for Tk. **", file=sys.__stderr__)

A patch is attached.

----------
components: IDLE
messages: 132828
nosy: denversc
priority: normal
severity: normal
status: open
title: idlelib/PyShell.py: incorrect module name reported in error message: Tkinter should be tkinter
versions: Python 3.3

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

From report at bugs.python.org  Sun Apr  3 04:53:49 2011
From: report at bugs.python.org (Denver Coneybeare)
Date: Sun, 03 Apr 2011 02:53:49 +0000
Subject: [issue11745] idlelib/PyShell.py: incorrect module name reported in
	error message: Tkinter should be tkinter
In-Reply-To: <1301799156.61.0.675938234599.issue11745@psf.upfronthosting.co.za>
Message-ID: <1301799229.82.0.814264813352.issue11745@psf.upfronthosting.co.za>


Changes by Denver Coneybeare <denver.coneybeare at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file21512/patch_idle_tkinter_import_v1.patch

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

From report at bugs.python.org  Sun Apr  3 04:54:00 2011
From: report at bugs.python.org (Denver Coneybeare)
Date: Sun, 03 Apr 2011 02:54:00 +0000
Subject: [issue11745] idlelib/PyShell.py: incorrect module name reported in
	error message: Tkinter should be tkinter
In-Reply-To: <1301799156.61.0.675938234599.issue11745@psf.upfronthosting.co.za>
Message-ID: <1301799240.91.0.109064355168.issue11745@psf.upfronthosting.co.za>


Changes by Denver Coneybeare <denver.coneybeare at gmail.com>:


----------
type:  -> behavior

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

From report at bugs.python.org  Sun Apr  3 05:00:21 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 03 Apr 2011 03:00:21 +0000
Subject: [issue11745] idlelib/PyShell.py: incorrect module name reported in
	error message: Tkinter should be tkinter
In-Reply-To: <1301799156.61.0.675938234599.issue11745@psf.upfronthosting.co.za>
Message-ID: <1301799621.17.0.262600115343.issue11745@psf.upfronthosting.co.za>


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

I think in this case "Tkinter" refers to the "Tkinter" library, rather than the "tkinter" module.

----------
nosy: +ezio.melotti
type: behavior -> 

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

From report at bugs.python.org  Sun Apr  3 05:08:11 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 03 Apr 2011 03:08:11 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1301800091.3.0.489101207974.issue11707@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


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

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

From report at bugs.python.org  Sun Apr  3 05:20:12 2011
From: report at bugs.python.org (umedoblock)
Date: Sun, 03 Apr 2011 03:20:12 +0000
Subject: [issue11746] ssl library load_cert_chain cannot use elliptic curve
	type private key
In-Reply-To: <1301800812.36.0.988775171179.issue11746@psf.upfronthosting.co.za>
Message-ID: <1301800812.36.0.988775171179.issue11746@psf.upfronthosting.co.za>


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

ssl library load_cert_chain cannot use elliptic curve type private key.

I resolved the problem, I attached patch file

----------
components: Library (Lib)
files: _ssl.c.diff
keywords: patch
messages: 132830
nosy: umedoblock
priority: normal
severity: normal
status: open
title: ssl library load_cert_chain cannot use elliptic curve type private key
versions: Python 3.2
Added file: http://bugs.python.org/file21513/_ssl.c.diff

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

From report at bugs.python.org  Sun Apr  3 05:32:38 2011
From: report at bugs.python.org (Daniel Goertzen)
Date: Sun, 03 Apr 2011 03:32:38 +0000
Subject: [issue6501] Fatal error on startup with invalid PYTHONIOENCODING
In-Reply-To: <1247826105.17.0.941734297485.issue6501@psf.upfronthosting.co.za>
Message-ID: <1301801558.69.0.0992943614849.issue6501@psf.upfronthosting.co.za>


Daniel Goertzen <daniel.goertzen at gmail.com> added the comment:

It turns out that cx-freeze deliberately sets Py_IgnoreEnvironmentFlag to ensure that the final executable is really an isolated, standalone executable (ie, it can't be subverted by setting PYTHONPATH.)  Therefore the PYTHONIOENCODING work-around does not work in this situation.

I am currently using a cx-freeze work-around from the author to enable the PYTHONIOENCODING work-around.  Altogether not that pleasant.

Could Python 3 could just default to some reasonable encoding and keep on chugging?

----------

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

From report at bugs.python.org  Sun Apr  3 06:57:16 2011
From: report at bugs.python.org (Jan Koprowski)
Date: Sun, 03 Apr 2011 04:57:16 +0000
Subject: [issue11747] unified_diff function product incorrect range information
In-Reply-To: <1301806636.68.0.728514553962.issue11747@psf.upfronthosting.co.za>
Message-ID: <1301806636.68.0.728514553962.issue11747@psf.upfronthosting.co.za>


New submission from Jan Koprowski <jan.koprowski at gmail.com>:

Python:
---------------------------
>>> import difflib
>>> dl = difflib.unified_diff([], ['a\n', 'b\n'])
>>> print ''.join(dl),
---
+++
@@ -1,0 +1,2 @@
+a
+b

Gnu diff:
---------------------------
$diff -uN a b
--- a   1970-01-01 01:00:00.000000000 +0100
+++ b   2011-04-03 06:56:28.330543000 +0200
@@ -0,0 +1,2 @@
+a
+b

----------
components: Library (Lib)
messages: 132832
nosy: jan.koprowski
priority: normal
severity: normal
status: open
title: unified_diff function product incorrect range information
versions: Python 2.7

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

From report at bugs.python.org  Sun Apr  3 07:44:16 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 03 Apr 2011 05:44:16 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1301809456.48.0.965743953643.issue11707@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Filip, can you please submit a contributor agreement?

http://docs.python.org/devguide/coredev.html#sign-a-contributor-agreement

----------

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

From report at bugs.python.org  Sun Apr  3 12:51:11 2011
From: report at bugs.python.org (Torsten Becker)
Date: Sun, 03 Apr 2011 10:51:11 +0000
Subject: [issue8269] Missing return values for PyUnicode C/API functions
In-Reply-To: <1269991617.43.0.918560470794.issue8269@psf.upfronthosting.co.za>
Message-ID: <1301827871.47.0.513887015397.issue8269@psf.upfronthosting.co.za>


Torsten Becker <torsten.becker at gmail.com> added the comment:

Hi, I read through unicodeobject.c and added the (IMO) proper reference counts to the missing functions.  I attached a first patch which adds this to Doc/data/refcounts.dat.

The patch also fixes 2 minor glitches in Doc/c-api/unicode.rst, PyUnicode_DecodeMBCSStateful stated int instead of Py_ssize_t for it's arguments and PyUnicode_FromString had it's return value wrongly formated.

----------
keywords: +patch
nosy: +torsten.becker
Added file: http://bugs.python.org/file21514/issue-8269-v1.patch

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

From report at bugs.python.org  Sun Apr  3 14:41:07 2011
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 03 Apr 2011 12:41:07 +0000
Subject: [issue11743] Rewrite PipeConnection and Connection in pure Python
In-Reply-To: <1301779980.98.0.515045950536.issue11743@psf.upfronthosting.co.za>
Message-ID: <1301834467.33.0.621049269912.issue11743@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Nothing jumps out at me at initial review; I've asked other contributors/interested parties to take a look too. Thanks a ton Antoine for doing this work

----------

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

From report at bugs.python.org  Sun Apr  3 16:02:28 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 03 Apr 2011 14:02:28 +0000
Subject: [issue11745] idlelib/PyShell.py: incorrect module name reported in
	error message: Tkinter should be tkinter
In-Reply-To: <1301799156.61.0.675938234599.issue11745@psf.upfronthosting.co.za>
Message-ID: <1301839348.6.0.593247090207.issue11745@psf.upfronthosting.co.za>


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

I'm going to reject this, thanks anyway for the patch!

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

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

From report at bugs.python.org  Sun Apr  3 16:07:55 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 03 Apr 2011 14:07:55 +0000
Subject: [issue10712] 2to3 fixer for deprecated unittest method names
In-Reply-To: <1292441796.9.0.018359428873.issue10712@psf.upfronthosting.co.za>
Message-ID: <1301839675.82.0.484112836877.issue10712@psf.upfronthosting.co.za>


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

Should this still go to the sandbox? and if so, what is the right sandbox?

----------

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

From report at bugs.python.org  Sun Apr  3 16:45:54 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 03 Apr 2011 14:45:54 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1301841954.1.0.639499727751.issue2650@psf.upfronthosting.co.za>


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

Georg, do you think a versionchanged note should be added for this? The change is minor and the patch updates the documentation to reflect the change.

----------

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

From report at bugs.python.org  Sun Apr  3 17:03:34 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Apr 2011 15:03:34 +0000
Subject: [issue11282] 3.3 unittest document not kept consist with code
In-Reply-To: <1298354999.37.0.375525915954.issue11282@psf.upfronthosting.co.za>
Message-ID: <E1Q6Opw-0005gL-Q3@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 1fd736395df3 by Ezio Melotti in branch '3.2':
#11282: the fail* methods will stay around a few more versions.
http://hg.python.org/cpython/rev/1fd736395df3

New changeset 110bb604bc2f by Ezio Melotti in branch 'default':
#11282: merge with 3.2.
http://hg.python.org/cpython/rev/110bb604bc2f

New changeset aa658836e090 by Ezio Melotti in branch 'default':
#11282: add back the fail* methods and assertDictContainsSubset.
http://hg.python.org/cpython/rev/aa658836e090

----------
nosy: +python-dev

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

From report at bugs.python.org  Sun Apr  3 17:09:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Apr 2011 15:09:20 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
	(issue4274045)
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <E1Q6OvO-0005zu-Kq@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 2cb07a46f4b5 by Antoine Pitrou in branch 'default':
Issue #5863: Rewrite BZ2File in pure Python, and allow it to accept
http://hg.python.org/cpython/rev/2cb07a46f4b5

----------
nosy: +python-dev

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

From report at bugs.python.org  Sun Apr  3 17:11:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Apr 2011 15:11:34 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
	(issue4274045)
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1301843494.43.0.376750698272.issue5863@psf.upfronthosting.co.za>


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

Thank you very much, Nadeem. The patch is now in.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Apr  3 17:12:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Apr 2011 15:12:32 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1301843552.24.0.177419178044.issue1625@psf.upfronthosting.co.za>


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

The patch here is totally out of date, following issue5863.

----------
nosy: +nvawda
stage: patch review -> needs patch
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Sun Apr  3 17:13:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 03 Apr 2011 15:13:36 +0000
Subject: [issue9424] Deprecate assertEquals, assertNotEquals, assert_,
	assertAlmostEquals, assertNotAlmostEquals
In-Reply-To: <1280448352.86.0.380978086896.issue9424@psf.upfronthosting.co.za>
Message-ID: <1301843616.44.0.0874549960691.issue9424@psf.upfronthosting.co.za>


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

The fail* methods and assertDictContainsSubset will be in 3.3 too, see #11282.  There is no version planned for their removal yet.
assertSameElements is gone from 3.3.

----------

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

From report at bugs.python.org  Sun Apr  3 17:17:44 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 03 Apr 2011 15:17:44 +0000
Subject: [issue7311] Bug on regexp of HTMLParser
In-Reply-To: <1258043150.41.0.372876851796.issue7311@psf.upfronthosting.co.za>
Message-ID: <1301843864.62.0.764013362125.issue7311@psf.upfronthosting.co.za>


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


----------
assignee:  -> ezio.melotti

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

From report at bugs.python.org  Sun Apr  3 17:28:30 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 03 Apr 2011 15:28:30 +0000
Subject: [issue11744] re.LOCALE doesn't reflect locale.setlocale(...)
In-Reply-To: <1301795472.4.0.896243580236.issue11744@psf.upfronthosting.co.za>
Message-ID: <1301844510.54.0.114220769896.issue11744@psf.upfronthosting.co.za>


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

I don't know what re is doing with respect to locale, but I do know that the implementation of string.letters is at least somewhat broken in 2.x.  It has no useful meaning in unicode, which is why it doesn't exist in 3.x.

A standard that talks about regex and locale is here:

http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap09.html

I don't know enough about locale or regex to comment further, but from the perspective of what I know about current developer resources and focus I would say that if anything is going to be changed, it would be by mrabarnett in the new engine.  Unless mrab (or you?) does it, the old engine is unlikely to be touched at this point.

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

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

From report at bugs.python.org  Sun Apr  3 17:29:35 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 03 Apr 2011 15:29:35 +0000
Subject: [issue11746] ssl library load_cert_chain cannot use elliptic curve
	type private key
In-Reply-To: <1301800812.36.0.988775171179.issue11746@psf.upfronthosting.co.za>
Message-ID: <1301844575.06.0.71612774499.issue11746@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/issue11746>
_______________________________________

From report at bugs.python.org  Sun Apr  3 18:03:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Apr 2011 16:03:00 +0000
Subject: [issue11743] Rewrite PipeConnection and Connection in pure Python
In-Reply-To: <1301779980.98.0.515045950536.issue11743@psf.upfronthosting.co.za>
Message-ID: <1301846580.0.0.309633790066.issue11743@psf.upfronthosting.co.za>


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

The patch slows down Pipe() a bit, by the way. On my machine, each message sent and received has an additional 10?s overhead. See attached benchmark script.

----------
Added file: http://bugs.python.org/file21515/mpconn.patch

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

From report at bugs.python.org  Sun Apr  3 18:03:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Apr 2011 16:03:06 +0000
Subject: [issue11743] Rewrite PipeConnection and Connection in pure Python
In-Reply-To: <1301779980.98.0.515045950536.issue11743@psf.upfronthosting.co.za>
Message-ID: <1301846586.35.0.0591172313033.issue11743@psf.upfronthosting.co.za>


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

The patch slows down Pipe() a bit, by the way. On my machine, each message sent and received has an additional 10?s overhead. See attached benchmark script.

----------
Added file: http://bugs.python.org/file21516/pipebench.py

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

From report at bugs.python.org  Sun Apr  3 18:03:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Apr 2011 16:03:27 +0000
Subject: [issue11743] Rewrite PipeConnection and Connection in pure Python
In-Reply-To: <1301779980.98.0.515045950536.issue11743@psf.upfronthosting.co.za>
Message-ID: <1301846607.1.0.062478939343.issue11743@psf.upfronthosting.co.za>


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

Woops, sorry for the duplicates...

----------

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

From report at bugs.python.org  Sun Apr  3 18:03:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Apr 2011 16:03:30 +0000
Subject: [issue11743] Rewrite PipeConnection and Connection in pure Python
In-Reply-To: <1301779980.98.0.515045950536.issue11743@psf.upfronthosting.co.za>
Message-ID: <1301846610.16.0.858909650048.issue11743@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file21515/mpconn.patch

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

From report at bugs.python.org  Sun Apr  3 18:03:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Apr 2011 16:03:36 +0000
Subject: [issue11743] Rewrite PipeConnection and Connection in pure Python
In-Reply-To: <1301779980.98.0.515045950536.issue11743@psf.upfronthosting.co.za>
Message-ID: <1301846616.57.0.781195162207.issue11743@psf.upfronthosting.co.za>


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


----------
Removed message: http://bugs.python.org/msg132847

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

From report at bugs.python.org  Sun Apr  3 18:06:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Apr 2011 16:06:54 +0000
Subject: [issue11748] test_ftplib failure in test for source_address
In-Reply-To: <1301846814.75.0.746123609794.issue11748@psf.upfronthosting.co.za>
Message-ID: <1301846814.75.0.746123609794.issue11748@psf.upfronthosting.co.za>


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

See http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/2475/steps/test/logs/stdio


test test_ftplib failed -- Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_ftplib.py", line 622, in test_source_address_passive_connection
    with self.client.transfercmd('list') as sock:
  File "D:\Buildslave\3.x.moore-windows\build\lib\ftplib.py", line 379, in transfercmd
    return self.ntransfercmd(cmd, rest)[0]
  File "D:\Buildslave\3.x.moore-windows\build\lib\ftplib.py", line 344, in ntransfercmd
    source_address=self.source_address)
  File "D:\Buildslave\3.x.moore-windows\build\lib\socket.py", line 407, in create_connection
    raise err
  File "D:\Buildslave\3.x.moore-windows\build\lib\socket.py", line 397, in create_connection
    sock.bind(source_address)
socket.error: [Errno 10048] Only one usage of each socket address (protocol/network address/port) is normally permitted

----------
assignee: giampaolo.rodola
components: Library (Lib), Tests
messages: 132849
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ftplib failure in test for source_address
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Apr  3 18:08:19 2011
From: report at bugs.python.org (Vlastimil Brom)
Date: Sun, 03 Apr 2011 16:08:19 +0000
Subject: [issue11744] re.LOCALE doesn't reflect locale.setlocale(...)
In-Reply-To: <1301795472.4.0.896243580236.issue11744@psf.upfronthosting.co.za>
Message-ID: <1301846899.59.0.373880444205.issue11744@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

Thanks for the comment for string.letters and further reference.
Given, that Mr. Barnett mentioned in his tracker to regex ( http://code.google.com/p/mrab-regex-hg/issues/detail?id=6 ), that he only supports the LOCALE flag because of the compatibility with re and given my zero knowledge of C, I suppose, we will live with the status quo.
I guess, if there were a well defined source of "letters" for the given locales, the implementation wouldn't necessarily have to be be that complex (in the context of the regex code), but as there is probably no agreement in this respect (if string.letters is questionable), it becomes pointless.
After all, one can define a needed regex pattern manually, and mrab's regex library makes it much easier due to the support for unicode properties and others.

vbr

----------

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

From report at bugs.python.org  Sun Apr  3 18:08:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Apr 2011 16:08:33 +0000
Subject: [issue11749] test_socket failure
In-Reply-To: <1301846913.96.0.368639647794.issue11749@psf.upfronthosting.co.za>
Message-ID: <1301846913.96.0.368639647794.issue11749@psf.upfronthosting.co.za>


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

http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/2473/steps/test/logs/stdio

======================================================================
FAIL: testSmallReadNonBlocking (test.test_socket.UnbufferedFileObjectClassTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_socket.py", line 1416, in testSmallReadNonBlocking
    self.assertEqual(n, 3)
AssertionError: None != 3

----------
components: Library (Lib), Tests
messages: 132851
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_socket failure
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Apr  3 18:20:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Apr 2011 16:20:11 +0000
Subject: [issue11748] test_ftplib failure in test for source_address
In-Reply-To: <1301846814.75.0.746123609794.issue11748@psf.upfronthosting.co.za>
Message-ID: <1301847611.2.0.85496775022.issue11748@psf.upfronthosting.co.za>


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

10048 is errno.EADDRINUSE.

----------

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

From report at bugs.python.org  Sun Apr  3 18:20:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Apr 2011 16:20:23 +0000
Subject: [issue11746] ssl library load_cert_chain cannot use elliptic curve
	type private key
In-Reply-To: <1301800812.36.0.988775171179.issue11746@psf.upfronthosting.co.za>
Message-ID: <E1Q6Q2F-0002yu-IV@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 88ed3de28520 by Antoine Pitrou in branch '3.2':
Issue #11746: Fix SSLContext.load_cert_chain() to accept elliptic curve private keys.
http://hg.python.org/cpython/rev/88ed3de28520

New changeset c11e05a60d36 by Antoine Pitrou in branch 'default':
Merge fix for issue #11746
http://hg.python.org/cpython/rev/c11e05a60d36

----------
nosy: +python-dev

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

From report at bugs.python.org  Sun Apr  3 18:21:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Apr 2011 16:21:48 +0000
Subject: [issue11746] ssl library load_cert_chain cannot use elliptic curve
	type private key
In-Reply-To: <1301800812.36.0.988775171179.issue11746@psf.upfronthosting.co.za>
Message-ID: <1301847708.8.0.988357138947.issue11746@psf.upfronthosting.co.za>


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

Committed, thank you.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.3

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

From report at bugs.python.org  Sun Apr  3 18:25:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 03 Apr 2011 16:25:38 +0000
Subject: [issue8252] add a metadata section in setup.cfg
In-Reply-To: <1269786516.47.0.241877166963.issue8252@psf.upfronthosting.co.za>
Message-ID: <1301847938.85.0.77295155656.issue8252@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
dependencies:  -update mkpkg to latest coding standards

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

From report at bugs.python.org  Sun Apr  3 18:26:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 03 Apr 2011 16:26:09 +0000
Subject: [issue8252] add a metadata section in setup.cfg
In-Reply-To: <1269786516.47.0.241877166963.issue8252@psf.upfronthosting.co.za>
Message-ID: <1301847969.97.0.252306911002.issue8252@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This was finished by Tarek and other people some months ago.

----------
resolution: accepted -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Apr  3 18:27:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 03 Apr 2011 16:27:16 +0000
Subject: [issue8591] update mkpkg to latest coding standards
In-Reply-To: <1272727331.63.0.427295643421.issue8591@psf.upfronthosting.co.za>
Message-ID: <1301848036.9.0.322055850033.issue8591@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FYI, the mkcfg module has seen a lot of change since last summer, some of which have bad style.  I still have this bug on my todo list to fix that.

----------

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

From report at bugs.python.org  Sun Apr  3 18:28:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 03 Apr 2011 16:28:09 +0000
Subject: [issue8253] add a resource+files section in setup.cfg
In-Reply-To: <1269786855.85.0.280361789745.issue8253@psf.upfronthosting.co.za>
Message-ID: <1301848089.24.0.35418663736.issue8253@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This is now done thanks to Tarek and sprinters.

----------
dependencies:  -update mkpkg to latest coding standards
resolution: accepted -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Apr  3 18:42:46 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 03 Apr 2011 16:42:46 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1301848966.74.0.325203272892.issue2771@psf.upfronthosting.co.za>


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

Testing

----------

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

From report at bugs.python.org  Sun Apr  3 18:46:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Apr 2011 16:46:35 +0000
Subject: [issue11748] test_ftplib failure in test for source_address
In-Reply-To: <1301846814.75.0.746123609794.issue11748@psf.upfronthosting.co.za>
Message-ID: <1301849195.58.0.812544636442.issue11748@psf.upfronthosting.co.za>


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

http://hg.python.org/cpython/rev/8a2d848244a2

----------

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

From report at bugs.python.org  Sun Apr  3 19:01:33 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 03 Apr 2011 17:01:33 +0000
Subject: [issue11282] 3.3 unittest document not kept consist with code
In-Reply-To: <1298354999.37.0.375525915954.issue11282@psf.upfronthosting.co.za>
Message-ID: <1301850093.92.0.531450800766.issue11282@psf.upfronthosting.co.za>


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


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Apr  3 19:14:30 2011
From: report at bugs.python.org (s7v7nislands)
Date: Sun, 03 Apr 2011 17:14:30 +0000
Subject: [issue11743] Rewrite PipeConnection and Connection in pure Python
In-Reply-To: <1301779980.98.0.515045950536.issue11743@psf.upfronthosting.co.za>
Message-ID: <1301850870.68.0.318746338707.issue11743@psf.upfronthosting.co.za>


Changes by s7v7nislands <s7v7nislands at gmail.com>:


----------
nosy: +s7v7nislands

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

From report at bugs.python.org  Sun Apr  3 19:30:56 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 03 Apr 2011 17:30:56 +0000
Subject: [issue7311] Bug on regexp of HTMLParser
In-Reply-To: <1258043150.41.0.372876851796.issue7311@psf.upfronthosting.co.za>
Message-ID: <1301851856.08.0.797086406819.issue7311@psf.upfronthosting.co.za>


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

Here's a patch that matches unquoted attribute values according to the HTML5 specifications.

The regex uses \s even if this includes the \v char that, according to the HTML5 specs, shouldn't be included.  I left it there for simplicity and backward-compatibility, and also because it's a rather obscure corner case.

----------
versions:  -Python 3.1
Added file: http://bugs.python.org/file21517/issue7311-2.diff

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

From report at bugs.python.org  Sun Apr  3 19:56:31 2011
From: report at bugs.python.org (Shashwat Anand)
Date: Sun, 03 Apr 2011 17:56:31 +0000
Subject: [issue8252] add a metadata section in setup.cfg
In-Reply-To: <1269786516.47.0.241877166963.issue8252@psf.upfronthosting.co.za>
Message-ID: <1301853391.96.0.387024556125.issue8252@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy:  -l0nwlf

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

From report at bugs.python.org  Sun Apr  3 19:57:00 2011
From: report at bugs.python.org (Shashwat Anand)
Date: Sun, 03 Apr 2011 17:57:00 +0000
Subject: [issue8253] add a resource+files section in setup.cfg
In-Reply-To: <1269786855.85.0.280361789745.issue8253@psf.upfronthosting.co.za>
Message-ID: <1301853420.26.0.0701147978722.issue8253@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy:  -l0nwlf

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

From report at bugs.python.org  Sun Apr  3 19:58:05 2011
From: report at bugs.python.org (Shashwat Anand)
Date: Sun, 03 Apr 2011 17:58:05 +0000
Subject: [issue4487] Add utf8 alias for email charsets
In-Reply-To: <1228223832.43.0.0399583143577.issue4487@psf.upfronthosting.co.za>
Message-ID: <1301853485.55.0.955262233424.issue4487@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy:  -l0nwlf

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

From report at bugs.python.org  Sun Apr  3 20:13:08 2011
From: report at bugs.python.org (Oliver Deppert)
Date: Sun, 03 Apr 2011 18:13:08 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
	(issue4274045)
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1301854388.85.0.482767446377.issue5863@psf.upfronthosting.co.za>


Oliver Deppert <Oliver.Deppert at stud.tu-darmstadt.de> added the comment:

Hi,

thanks for the patch. Could you also publish a version for older python 2.x ?

regards,
Olli

----------
nosy: +Kontr-Olli

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

From report at bugs.python.org  Sun Apr  3 20:27:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 03 Apr 2011 18:27:06 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
	(issue4274045)
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1301855226.85.0.696258394498.issue5863@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

As a new feature, this can?t go into older versions.

----------

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

From report at bugs.python.org  Sun Apr  3 20:27:12 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 03 Apr 2011 18:27:12 +0000
Subject: [issue9424] Deprecate assertEquals, assertNotEquals, assert_,
	assertAlmostEquals, assertNotAlmostEquals
In-Reply-To: <1280448352.86.0.380978086896.issue9424@psf.upfronthosting.co.za>
Message-ID: <1301855232.35.0.674535345471.issue9424@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

It probably would have been okay to remove assertDictContainsSubset which had nearly zero uptake (according to Google's code search).  That's probably because it addresses an uncommon use case, because it was only recently introduced, and because its arguments were in the wrong order.

That situation is much different that assertEquals and friends that have been around for a long time.

I don't care much how this gets resolved; just wanted to point-out that there is much less of a reason to keep assertDictContainsSubset..

----------

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

From report at bugs.python.org  Sun Apr  3 20:50:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Apr 2011 18:50:29 +0000
Subject: [issue11750] Mutualize win32 functions
In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za>
Message-ID: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za>


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

subprocess and multiprocessing both have their own private modules for wrappers of win32 functions: Modules/_multiprocessing/win32_functions.c and PC/_subprocess.c.

It would be nice to group them in a common module (_win32?) that could be used throughout the stdlib.

----------
components: Extension Modules, Windows
messages: 132868
nosy: asksol, brian.curtin, gregory.p.smith, jnoller, pitrou, tim.golden
priority: normal
severity: normal
status: open
title: Mutualize win32 functions
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Sun Apr  3 21:07:38 2011
From: report at bugs.python.org (Justin Love)
Date: Sun, 03 Apr 2011 19:07:38 +0000
Subject: [issue11751] Increase distutils/filelist test coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>


New submission from Justin Love <python at JustinLove.name>:

Increase test coverage of distutils/filelist.py from 49% to 100%.  One line was marked as excluded because it was a "this cannot happen" error, and I agreed.

----------
components: Tests
files: increase_distutils_filelist_test_coverage.patch
keywords: patch
messages: 132869
nosy: jlove
priority: normal
severity: normal
status: open
title: Increase distutils/filelist test coverage
type: behavior
Added file: http://bugs.python.org/file21518/increase_distutils_filelist_test_coverage.patch

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

From report at bugs.python.org  Sun Apr  3 21:20:03 2011
From: report at bugs.python.org (Joel Luellwitz)
Date: Sun, 03 Apr 2011 19:20:03 +0000
Subject: [issue11751] Increase distutils/filelist test coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <1301858403.28.0.970898443668.issue11751@psf.upfronthosting.co.za>


Changes by Joel Luellwitz <eviljoel at linux.com>:


----------
versions: +Python 3.3

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

From report at bugs.python.org  Sun Apr  3 21:35:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 03 Apr 2011 19:35:02 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1301859302.07.0.865008556351.issue10496@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, haypo

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

From report at bugs.python.org  Sun Apr  3 21:43:15 2011
From: report at bugs.python.org (gungor)
Date: Sun, 03 Apr 2011 19:43:15 +0000
Subject: [issue11752] Gungor Basa wants to stay in touch on LinkedIn
In-Reply-To: <2042837526.1662080.1301859792311.JavaMail.app@ela4-bed37.prod>
Message-ID: <2042837526.1662080.1301859792311.JavaMail.app@ela4-bed37.prod>


New submission from gungor <gungorbasa at gmail.com>:

LinkedIn
------------

Python,

I'd like to add you to my professional network on LinkedIn.

- Gungor Basa

Gungor Basa
Computer Engineer at CYMSOFT 
Turkey

Confirm that you know Gungor Basa
https://www.linkedin.com/e/-3qcne3-gm2dpgol-1s/isd/2626190363/ywqIa-UZ/

----------
files: unnamed
messages: 132870
nosy: gungorbasa
priority: normal
severity: normal
status: open
title: Gungor Basa wants to stay in touch on LinkedIn
Added file: http://bugs.python.org/file21519/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11752>
_______________________________________
-------------- next part --------------

<html>
  <body>

  

<table border="0" width="550" cellpadding="0" cellspacing="0" style="max-width:550px; border-top:4px solid #39C; font: 12px arial, sans-serif; margin: 0 auto;"><tr><td>  
  <h1 style="color: #000; font: bold 23px arial; margin:5px 0;" >LinkedIn</h1>

<div style="font:13px arial, sans-serif; width:540px">  
    
    <p>
      Python,<br/>
<br/>
I'd like to add you to my professional network on LinkedIn.<br/>
<br/>
- Gungor Basa
    </p>
    
    <table cellpadding="0" cellspacing="0" style="margin-bottom: 10px;">
      <tr>
          <td style="width: 50px;">
              <IMG style="padding: 5px;" src="http://media.linkedin.com/media/p/3/000/052/363/21bbe9e.jpg" class="photo" width="40" height="40">
          </td>
        <td style="font: 13px arial, sans-serif; width: 490px;">
          <div style="padding: 5px 5px 5px 0">
            Gungor Basa<br>
                Computer Engineer at CYMSOFT 
            <br>
                    Turkey
          </div>
          </div>
        </td>
      </tr>
    </table>

    <p>
              <a style="background-color:#ffcc00; display:inline-block; border-right: 1px solid #7a5a20; border-bottom: 1px solid #7a5a20; padding:10px; text-decoration: none; color: #000; text-align: center; white-space:none; font-weight: bold;" href="https://www.linkedin.com/e/-3qcne3-gm2dpgol-1s/isd/2626190363/ywqIa-UZ/EML-invg_59/">Confirm that you know Gungor</a>
    </p>
</div>



  <p style="width: 550px; margin: 3px auto; font: 10px arial, sans-serif; color: #999;">&#169; 2011, LinkedIn Corporation</p>
  
<img src="http://www.linkedin.com/emimp/-3qcne3-gm2dpgol-1s.gif" style="width:1px; height:1px;"/></body>
</html>

From report at bugs.python.org  Sun Apr  3 21:43:48 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 03 Apr 2011 19:43:48 +0000
Subject: [issue11751] Increase distutils/filelist test coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <1301859828.19.0.949246749202.issue11751@psf.upfronthosting.co.za>


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


----------
assignee:  -> tarek
components: +Distutils -Tests
nosy: +eric.araujo, tarek

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

From report at bugs.python.org  Sun Apr  3 21:44:16 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 03 Apr 2011 19:44:16 +0000
Subject: [issue11752] Gungor Basa wants to stay in touch on LinkedIn
In-Reply-To: <2042837526.1662080.1301859792311.JavaMail.app@ela4-bed37.prod>
Message-ID: <1301859856.76.0.599053423656.issue11752@psf.upfronthosting.co.za>


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


----------
nosy:  -gungorbasa
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Apr  3 21:44:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 03 Apr 2011 19:44:53 +0000
Subject: [issue11753] test_sendall_interrupted() of test_socket hangs on
	FreeBSD
In-Reply-To: <1301859893.52.0.614181082416.issue11753@psf.upfronthosting.co.za>
Message-ID: <1301859893.52.0.614181082416.issue11753@psf.upfronthosting.co.za>


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

I added a timeout of 30 minutes to regrtest. On "x86 FreeBSD 7.2 3.x" and "x86 FreeBSD 3.x" buildbot, test_sendall_interrupted() of test_socket does timeout after 30 minutes:
----------
...
[201/354] test_socket
Thread 0x28401040:
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_socket.py", line 729 in check_sendall_interrupted
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_socket.py", line 740 in test_sendall_interrupted
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 442 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 494 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1078 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1166 in _run_suite
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1192 in run_unittest
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_socket.py", line 2052 in test_main
  File "./Lib/test/regrtest.py", line 1032 in runtest_inner
  File "./Lib/test/regrtest.py", line 826 in runtest
  File "./Lib/test/regrtest.py", line 650 in main
  File "./Lib/test/regrtest.py", line 1607 in <module>
----------
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%207.2%203.x/builds/1644/steps/test/logs/stdio
another example:
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%203.x/builds/1344/steps/test/logs/stdio

It looks like the test should be done in less than 5 seconds. Extract of the code (with_timeout=False for test_sendall_interrupted):
-------------------------
def check_sendall_interrupted(self, with_timeout):
        # socketpair() is not stricly required, but it makes things easier.
        if not hasattr(signal, 'alarm') or not hasattr(socket, 'socketpair'):
            self.skipTest("signal.alarm and socket.socketpair required for this test")
        # Our signal handlers clobber the C errno by calling a math function
        # with an invalid domain value.
        def ok_handler(*args):
            self.assertRaises(ValueError, math.acosh, 0)
        def raising_handler(*args):
            self.assertRaises(ValueError, math.acosh, 0)
            1 // 0
        c, s = socket.socketpair()
        old_alarm = signal.signal(signal.SIGALRM, raising_handler)
        try:
            if with_timeout:
                # Just above the one second minimum for signal.alarm
                c.settimeout(1.5)
            with self.assertRaises(ZeroDivisionError):
                signal.alarm(1)
                c.sendall(b"x" * (1024**2)) <~~~~ HERE
            if with_timeout:
                signal.signal(signal.SIGALRM, ok_handler)
                signal.alarm(1)
                self.assertRaises(socket.timeout, c.sendall, b"x" * (1024**2))
        finally:
            signal.signal(signal.SIGALRM, old_alarm)
            c.close()
            s.close()
-------------------------
I suppose that sendall() should be interrupted by SIGALRM. sendall() calls PyErr_CheckSignals() after each system call to send(), and exits with an error if PyErr_CheckSignals() returns NULL. If send() fails with EINTR error, sendall() retries calls send() again (in a loop).

I don't know if this hang is new or not, and if it is (or not) a border effect of the timeout feature of regrtest...

But test_signal don't always fail, it looks like a race condition.

----------
components: Library (Lib)
messages: 132871
nosy: haypo
priority: normal
severity: normal
status: open
title: test_sendall_interrupted() of test_socket hangs on FreeBSD
versions: Python 3.3

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

From report at bugs.python.org  Sun Apr  3 21:46:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 03 Apr 2011 19:46:36 +0000
Subject: [issue8905] difflib should accept arbitrary line iterators
In-Reply-To: <1275738341.19.0.989231664853.issue8905@psf.upfronthosting.co.za>
Message-ID: <1301859996.91.0.220866287438.issue8905@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

A quick look at the code doesn?t immediately tells me that difflib accepts sequences, not only lists.  I?m not sure iterators are accepted too.  What specific functions or methods have you found too strict?

----------
stage: needs patch -> test needed
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Sun Apr  3 21:47:26 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 03 Apr 2011 19:47:26 +0000
Subject: [issue11742] Possible bug in Python/import.c
In-Reply-To: <1301758931.53.0.147789887182.issue11742@psf.upfronthosting.co.za>
Message-ID: <1301860046.59.0.902267722098.issue11742@psf.upfronthosting.co.za>


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

Thanks for the report, but this has been fixed in the code repo.

----------
nosy: +brett.cannon
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Sun Apr  3 21:49:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 03 Apr 2011 19:49:08 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1301860148.72.0.153143347915.issue4709@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions:  -Python 2.6

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

From report at bugs.python.org  Sun Apr  3 21:52:27 2011
From: report at bugs.python.org (Lynne Qu)
Date: Sun, 03 Apr 2011 19:52:27 +0000
Subject: [issue11754] Changed test to check calculated constants in
	test_string.py
In-Reply-To: <1301860347.11.0.319603986002.issue11754@psf.upfronthosting.co.za>
Message-ID: <1301860347.11.0.319603986002.issue11754@psf.upfronthosting.co.za>


New submission from Lynne Qu <lynne.qu at gmail.com>:

Changed test to check calculated constants in test_string.py

----------
components: Tests
files: test_calculated_constants.diff
keywords: patch
messages: 132874
nosy: Lynne.Qu
priority: normal
severity: normal
status: open
title: Changed test to check calculated constants in test_string.py
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file21520/test_calculated_constants.diff

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

From report at bugs.python.org  Sun Apr  3 21:55:21 2011
From: report at bugs.python.org (SilentGhost)
Date: Sun, 03 Apr 2011 19:55:21 +0000
Subject: [issue11752] Gungor Basa wants to stay in touch on LinkedIn
Message-ID: <1301860521.31.0.8537703422.issue11752@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
Removed message: http://bugs.python.org/msg132870

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

From report at bugs.python.org  Sun Apr  3 21:55:29 2011
From: report at bugs.python.org (SilentGhost)
Date: Sun, 03 Apr 2011 19:55:29 +0000
Subject: [issue11752] Gungor Basa wants to stay in touch on LinkedIn
Message-ID: <1301860529.0.0.434381457653.issue11752@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


Removed file: http://bugs.python.org/file21519/unnamed

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

From report at bugs.python.org  Sun Apr  3 21:56:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 03 Apr 2011 19:56:50 +0000
Subject: [issue11755] test_itimer_real() of test_signal hang on FreeBSD
In-Reply-To: <1301860610.2.0.465861463042.issue11755@psf.upfronthosting.co.za>
Message-ID: <1301860610.2.0.465861463042.issue11755@psf.upfronthosting.co.za>


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

test_itimer_real() of test_signal hang 30 minutes on FreeBSD "x86 FreeBSD 3.x" and "x86 FreeBSD 7.2 3.x" buildbots. Example:
----------------------------
...
[ 95/354] test_signal
Thread 0x28401040:
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_signal.py", line 436 in test_itimer_real
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 442 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 494 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1078 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1166 in _run_suite
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1192 in run_unittest
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_signal.py", line 490 in test_main
  File "./Lib/test/regrtest.py", line 1032 in runtest_inner
  File "./Lib/test/regrtest.py", line 826 in runtest
  File "./Lib/test/regrtest.py", line 650 in main
  File "./Lib/test/regrtest.py", line 1607 in <module>
*** Error code 1

Stop in /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build.
program finished with exit code 1
elapsedTime=4160.495190
----------------------------
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%207.2%203.x/builds/1645/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%203.x/builds/1345/steps/test/logs/stdio

I don't know if this issue is new or not, and if it is (or not) related to the new regrtest timeout.

See also issue #11753, another signal issue on FreeBSD.

----------
components: Library (Lib)
messages: 132875
nosy: haypo
priority: normal
severity: normal
status: open
title: test_itimer_real() of test_signal hang on FreeBSD
versions: Python 3.3

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

From report at bugs.python.org  Sun Apr  3 21:58:15 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 03 Apr 2011 19:58:15 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1301860695.83.0.0906184869692.issue1294232@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I would make the same guess about 'winner calculation'. I am surprised that the class statement does not result in the same calculation (why else would type_new do it). Perhaps __build_class__ (which I have not read) should either call type_new or a new function with the winner calculation factored out of type_new.

I suggest you repost your simplified example from the list here and use it as the basis of a test. Guido agreed that it shows a bug that might be backported to 3.2 (after discussion). If not also backported to 2.7, a separate 2.7 doc patch might be needed.

----------

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

From report at bugs.python.org  Sun Apr  3 22:06:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 03 Apr 2011 20:06:26 +0000
Subject: [issue11751] Increase distutils.filelist test coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <1301861186.67.0.758208554303.issue11751@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the patch!  Please use the Distutils and/or Distutils2 component in the future so that some people are automatically notified of the report.

I made a review (follow ?review? link on the right of the diff file).

----------
assignee: tarek -> eric.araujo
components: +Distutils2
nosy: +alexis
stage:  -> patch review
title: Increase distutils/filelist test coverage -> Increase distutils.filelist test coverage
versions: +3rd party, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Apr  3 22:07:25 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 03 Apr 2011 20:07:25 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1301861245.27.0.240890922321.issue1294232@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3

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

From report at bugs.python.org  Sun Apr  3 22:08:01 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Sun, 03 Apr 2011 20:08:01 +0000
Subject: [issue11743] Rewrite PipeConnection and Connection in pure Python
In-Reply-To: <1301779980.98.0.515045950536.issue11743@psf.upfronthosting.co.za>
Message-ID: <1301861281.78.0.563972949861.issue11743@psf.upfronthosting.co.za>


Changes by Alex Gaynor <alex.gaynor at gmail.com>:


----------
nosy: +alex

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

From report at bugs.python.org  Sun Apr  3 22:11:27 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 03 Apr 2011 20:11:27 +0000
Subject: [issue6895] locale._parse_localename fails when localename does not
	contain encoding information
In-Reply-To: <1252765618.77.0.920082811868.issue6895@psf.upfronthosting.co.za>
Message-ID: <1301861487.73.0.245870526894.issue6895@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Is there another (authoritative) source for locale aliases apart
from X.org? On Ubuntu Lucid, many aliases for installed locales
are missing:


f = open("/var/lib/locales/supported.d/local")
locale_list = [loc.split()[0] for loc in f.readlines() \
               if not loc.startswith('#')]

for loc in locale_list:
    x = locale.setlocale(locale.LC_ALL, loc)
    try:
        y = locale.getlocale()
    except ValueError:
        print(loc)

aa_DJ
aa_ER
aa_ER at saaho
aa_ET
an_ES
ar_IN
ast_ES
ber_DZ
ber_MA
bn_BD
bo_CN
bo_IN
byn_ER
ca_ES at valencia
crh_UA
csb_PL
dv_MV
dz_BT
el_CY
en_AG
en_DK
en_NG
eu_FR
fil_PH
fur_IT
fy_NL
fy_DE
gez_ER
gez_ER at abegede
gez_ET
gez_ET at abegede
ha_NG
hne_IN
hsb_DE
ht_HT
hy_AM
ia
ig_NG
ik_CA
kk_KZ
kk_KZ
ks_IN
ks_IN at devanagari
ku_TR
lg_UG
li_BE
li_NL
mai_IN
mg_MG
ml_IN
mn_MN
my_MM
nan_TW at latin
nds_DE
nds_NL
ne_NP
nl_AW
om_ET
om_KE
or_IN
pa_PK
pap_AN
ps_AF
sa_IN
sc_IT
sd_IN
sd_IN at devanagari
shs_CA
sid_ET
so_DJ
so_ET
so_KE
so_SO
te_IN
ti_ER
ti_ET
tig_ER
tk_TM
tr_CY
tt_RU at iqtelif.UTF-8
ug_CN
wal_ET
wo_SN
yo_NG
zh_SG

----------
nosy: +skrah

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

From report at bugs.python.org  Sun Apr  3 22:32:24 2011
From: report at bugs.python.org (Joel Luellwitz)
Date: Sun, 03 Apr 2011 20:32:24 +0000
Subject: [issue11754] Changed test to check calculated constants in
	test_string.py
In-Reply-To: <1301860347.11.0.319603986002.issue11754@psf.upfronthosting.co.za>
Message-ID: <1301862744.14.0.520881336551.issue11754@psf.upfronthosting.co.za>


Joel Luellwitz <eviljoel at linux.com> added the comment:

Make a slight change to diff file.

----------
nosy: +JoelLuellwitz
Added file: http://bugs.python.org/file21521/test_calculated_constants.diff

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

From report at bugs.python.org  Sun Apr  3 22:44:04 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 03 Apr 2011 20:44:04 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1301863444.2.0.0665079259826.issue1294232@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

The attached test case currently fails.  I'll try to make a patch soon.

> Perhaps __build_class__ (which I have not read) should either call
> type_new or a new function with the winner calculation factored out of
> type_new.

Yeah, that's exactly what I'm planning to do (the factoring out).

----------
components: +Interpreter Core
keywords: +patch
nosy: +benjamin.peterson, gvanrossum
type: feature request -> behavior
Added file: http://bugs.python.org/file21522/test_issue1294232.patch

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

From report at bugs.python.org  Sun Apr  3 22:51:05 2011
From: report at bugs.python.org (Ask Solem)
Date: Sun, 03 Apr 2011 20:51:05 +0000
Subject: [issue11743] Rewrite PipeConnection and Connection in pure Python
In-Reply-To: <1301779980.98.0.515045950536.issue11743@psf.upfronthosting.co.za>
Message-ID: <1301863865.9.0.713377386772.issue11743@psf.upfronthosting.co.za>


Ask Solem <ask at celeryproject.org> added the comment:

This is great!  I always wondered if it was really necessary to use C for this. 10?s overhead should be worth it ;)

I've read the patch, but not carefully.  So far nothing jumps at me either.

Cheers!

----------

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

From report at bugs.python.org  Sun Apr  3 22:58:33 2011
From: report at bugs.python.org (Tim Golden)
Date: Sun, 03 Apr 2011 20:58:33 +0000
Subject: [issue11750] Mutualize win32 functions
In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za>
Message-ID: <4D98DF75.9070701@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

+1

----------

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

From report at bugs.python.org  Sun Apr  3 22:58:50 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sun, 03 Apr 2011 20:58:50 +0000
Subject: [issue11753] test_sendall_interrupted() of test_socket hangs on
	FreeBSD
In-Reply-To: <1301859893.52.0.614181082416.issue11753@psf.upfronthosting.co.za>
Message-ID: <1301864330.96.0.884531681494.issue11753@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

This test assumes that send will necessarily return if interrupted by a signal, but the kernel can automatically restart the syscall when no data has been committed (instead of returning -1 with errno set to EINTR).
And, AFAIK, that's exactly what FreeBSD does, see http://www.freebsd.org/cgi/man.cgi?query=siginterrupt&apropos=0&sektion=0&manpath=FreeBSD+8.2-RELEASE&format=html :
"""
The siginterrupt() function is used to change the system call restart
     behavior when a system call is interrupted by the specified signal.  If
     the flag is false (0), then system calls will be restarted if they are
     interrupted by the specified signal and no data has been transferred yet.
     System call restart has been the default behavior since 4.2BSD, and is
     the default behaviour for signal(3) on FreeBSD.
"""

And http://www.gsp.com/cgi-bin/man.cgi?section=2&topic=sigaction :

"""
If a signal is caught during the system calls listed below, the call may be forced to terminate with the error EINTR, the call may return with a data transfer shorter than requested, or the call may be restarted. Restart of pending calls is requested by setting the SA_RESTART bit in sa_flags. The affected system calls include open(2), read(2), write(2), sendto(2), recvfrom(2), sendmsg(2) and recvmsg(2) on a communications channel or a slow device (such as a terminal, but not a regular file) and during a wait(2) or ioctl(2). However, calls that have already committed are not restarted, but instead return a partial success (for example, a short read count).
"""

So if the signal arrives while some data has been transferred, send will return with a partial write, but if the signal arrives before any data has been written, then you'll never see EINTR and remain stuck forever (unless SA_RESTART is unset).
Note that POSIX seems to require write to return with EINTR if interrupted before any data is written, see http://pubs.opengroup.org/onlinepubs/009695399/functions/write.html :

"""
If write() is interrupted by a signal before it writes any data, it shall return -1 with errno set to [EINTR].
"""

But send and sendto man pages don't require this behaviour.

----------
nosy: +neologix

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

From report at bugs.python.org  Sun Apr  3 23:04:08 2011
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 03 Apr 2011 21:04:08 +0000
Subject: [issue11750] Mutualize win32 functions
In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za>
Message-ID: <1301864648.11.0.865668403553.issue11750@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Agreed; I'm not personally the windows expert that should handle that consolidation though.

----------

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

From report at bugs.python.org  Sun Apr  3 23:05:37 2011
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 03 Apr 2011 21:05:37 +0000
Subject: [issue11750] Mutualize win32 functions
In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za>
Message-ID: <1301864737.96.0.801407753048.issue11750@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Big +1. I'll work up a patch.

----------
assignee:  -> brian.curtin

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

From report at bugs.python.org  Sun Apr  3 23:18:17 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sun, 03 Apr 2011 21:18:17 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1301865497.81.0.152361437023.issue11707@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I worked a little on the tests. Only then I have noticed, that cmp_to_key tests weren't run, so I have encountered some problems, when I finally turned them on. I have added some of my tests, fixed some things in the patch and now it seems to work fine. I have added traverse method and decrease reference counts in dealloc.

I haven't had yet time to run some performance tests, but I'll try to do that.

I'll try to submit contributor agreement. It's a pity, that I can't send a signed copy through email. It'll take some time, before it comes from Poland.

----------
Added file: http://bugs.python.org/file21523/11707_3.patch

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

From report at bugs.python.org  Sun Apr  3 23:21:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 03 Apr 2011 21:21:53 +0000
Subject: [issue11755] test_itimer_real() of test_signal hang on FreeBSD
In-Reply-To: <1301860610.2.0.465861463042.issue11755@psf.upfronthosting.co.za>
Message-ID: <1301865713.49.0.485927549625.issue11755@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ok, this issue is completly related to regrtest.py timeout (issue #11727): test_signal with regrtest.py timeout disabled.

----------

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

From report at bugs.python.org  Sun Apr  3 23:26:22 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 03 Apr 2011 21:26:22 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1301865982.08.0.275796899527.issue11707@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

FWIW, the PSF is working towards getting electronic signatures for contributor agreements.  In the mean time, a scan or photo would work just fine.

----------

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

From report at bugs.python.org  Sun Apr  3 23:27:25 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 03 Apr 2011 21:27:25 +0000
Subject: [issue11753] test_sendall_interrupted() of test_socket hangs on
	FreeBSD
In-Reply-To: <1301859893.52.0.614181082416.issue11753@psf.upfronthosting.co.za>
Message-ID: <1301866045.03.0.916698543319.issue11753@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

As issue #11755, this issue is a regression introduced by regrtest timeout (issue #11727): test_socket doesn't fail without regrtest timeout.

----------

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

From report at bugs.python.org  Sun Apr  3 23:39:03 2011
From: report at bugs.python.org (Jakub Wilk)
Date: Sun, 03 Apr 2011 21:39:03 +0000
Subject: [issue5228] multiprocessing not compatible with functools.partial
In-Reply-To: <1234448790.05.0.305625917638.issue5228@psf.upfronthosting.co.za>
Message-ID: <1301866743.35.0.723113812059.issue5228@psf.upfronthosting.co.za>


Changes by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy: +jwilk

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

From report at bugs.python.org  Sun Apr  3 23:46:50 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Apr 2011 21:46:50 +0000
Subject: [issue11727] Add a --timeout option to regrtest.py using the
	faulthandler module
In-Reply-To: <1301566785.42.0.872105634784.issue11727@psf.upfronthosting.co.za>
Message-ID: <E1Q6V88-0003Ff-Mm@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 394f0ea0d29e by Victor Stinner in branch 'default':
Issue #11727, issue #11753, issue #11755: disable regrtest timeout
http://hg.python.org/cpython/rev/394f0ea0d29e

----------

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

From report at bugs.python.org  Sun Apr  3 23:54:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 03 Apr 2011 21:54:01 +0000
Subject: [issue11744] re.LOCALE doesn't reflect locale.setlocale(...)
In-Reply-To: <1301795472.4.0.896243580236.issue11744@psf.upfronthosting.co.za>
Message-ID: <1301867641.08.0.445058524509.issue11744@psf.upfronthosting.co.za>


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

Yeah, as far as I could tell from a brief scan of google hits, locale support in regex in general is a legacy thing, and the "correct" thing to do is to use unicode properties.  So I'll close this as won't fix.  If someone comes along with motivation to fix it it can always be reopened.

----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Apr  4 00:02:19 2011
From: report at bugs.python.org (David Albert Torpey)
Date: Sun, 03 Apr 2011 22:02:19 +0000
Subject: [issue11756] bytes.hex()
In-Reply-To: <1301868139.62.0.934615407924.issue11756@psf.upfronthosting.co.za>
Message-ID: <1301868139.62.0.934615407924.issue11756@psf.upfronthosting.co.za>


New submission from David Albert Torpey <dtorp at users.sourceforge.net>:

Floats have fromhex() and hex() to round-trip from and to hexadecimal, but bytes only have fromhex(), so it's hard to reliably round-trip.

----------
messages: 132892
nosy: dtorp
priority: normal
severity: normal
status: open
title: bytes.hex()
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr  4 00:13:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Apr 2011 22:13:08 +0000
Subject: [issue11688] SQLite trace callback
In-Reply-To: <1301177361.02.0.994780961602.issue11688@psf.upfronthosting.co.za>
Message-ID: <E1Q6VXd-0004nv-U9@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 575ee55081dc by Antoine Pitrou in branch 'default':
Issue #11688: Add sqlite3.Connection.set_trace_callback().  Patch by Torsten Landschoff.
http://hg.python.org/cpython/rev/575ee55081dc

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Apr  4 00:14:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Apr 2011 22:14:13 +0000
Subject: [issue11688] SQLite trace callback
In-Reply-To: <1301177361.02.0.994780961602.issue11688@psf.upfronthosting.co.za>
Message-ID: <1301868853.38.0.305508604042.issue11688@psf.upfronthosting.co.za>


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

Patch committed, thank you!

----------
assignee: ghaering -> 
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Apr  4 00:17:14 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 03 Apr 2011 22:17:14 +0000
Subject: [issue11756] bytes.hex()
In-Reply-To: <1301868139.62.0.934615407924.issue11756@psf.upfronthosting.co.za>
Message-ID: <1301869034.25.0.0940449230963.issue11756@psf.upfronthosting.co.za>


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

binascci.(un)hexlify

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Mon Apr  4 00:20:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 03 Apr 2011 22:20:54 +0000
Subject: [issue11755] test_itimer_real() of test_signal hang on FreeBSD
In-Reply-To: <1301860610.2.0.465861463042.issue11755@psf.upfronthosting.co.za>
Message-ID: <1301869254.45.0.382589515988.issue11755@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Duplicate of #11753.

----------
resolution:  -> duplicate

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

From report at bugs.python.org  Mon Apr  4 00:20:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 03 Apr 2011 22:20:59 +0000
Subject: [issue11755] test_itimer_real() of test_signal hang on FreeBSD
In-Reply-To: <1301860610.2.0.465861463042.issue11755@psf.upfronthosting.co.za>
Message-ID: <1301869259.66.0.418775738581.issue11755@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
status: open -> closed

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

From report at bugs.python.org  Mon Apr  4 00:21:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 03 Apr 2011 22:21:01 +0000
Subject: [issue11753] test_sendall_interrupted() of test_socket hangs on
	FreeBSD
In-Reply-To: <1301859893.52.0.614181082416.issue11753@psf.upfronthosting.co.za>
Message-ID: <1301869261.98.0.619506019865.issue11753@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Issue #11755 (test_itimer_real() of test_signal hang on FreeBSD) has been marked as a duplicate of this issue.

----------

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

From report at bugs.python.org  Mon Apr  4 00:28:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Apr 2011 22:28:25 +0000
Subject: [issue11757] test_subprocess failure
In-Reply-To: <1301869705.52.0.173979620005.issue11757@psf.upfronthosting.co.za>
Message-ID: <1301869705.52.0.173979620005.issue11757@psf.upfronthosting.co.za>


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

In http://www.python.org/dev/buildbot/all/builders/AMD64%20OpenIndiana%203.x/builds/904/steps/test/logs/stdio :

test test_subprocess failed -- Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_subprocess.py", line 452, in test_communicate_timeout_large_ouput
    self.assertRaises(subprocess.TimeoutExpired, p.communicate, timeout=0.4)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/unittest/case.py", line 574, in assertRaises
    callableObj(*args, **kwargs)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/subprocess.py", line 846, in communicate
    stdout, stderr = self._communicate(input, endtime, timeout)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/subprocess.py", line 1539, in _communicate
    orig_timeout)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/subprocess.py", line 1670, in _communicate_with_select
    self._remaining_time(endtime))
select.error: (22, 'Invalid argument')

Traceback (most recent call last):
  File "<string>", line 1, in <module>
IOError: [Errno 32] Broken pipe

----------
components: Library (Lib), Tests
messages: 132898
nosy: gregory.p.smith, pitrou, rnk
priority: normal
severity: normal
stage: needs patch
status: open
title: test_subprocess failure
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr  4 00:28:49 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 03 Apr 2011 22:28:49 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1301869729.01.0.184154211485.issue10791@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> Is following change in GzipFile class enough:
> 
>     def read1(self, n):
>         return self.read(n)
> 
> ? This satisfies TextIOWrapper to run readline correctly.

Looks good to me.

By the way, BZ2File now works correctly - the fix for issue5863 adds read1().

----------

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

From report at bugs.python.org  Mon Apr  4 00:35:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Apr 2011 22:35:34 +0000
Subject: [issue11757] test_subprocess failure
In-Reply-To: <1301869705.52.0.173979620005.issue11757@psf.upfronthosting.co.za>
Message-ID: <1301870134.58.0.584955366228.issue11757@psf.upfronthosting.co.za>


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

According to POSIX, EINVAL in select() means either "an invalid timeout interval was specified" or "the nfds argument is less than 0 or greater than FD_SETSIZE".

(http://www.opengroup.org/onlinepubs/007904875/functions/pselect.html)

Additionally, Python's select.select() should raise ValueError if a file descriptor is outside of [0; FD_SETSIZE[, so the invalid timeout interval seems possible.

----------

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

From report at bugs.python.org  Mon Apr  4 00:35:42 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 03 Apr 2011 22:35:42 +0000
Subject: [issue11756] bytes.hex()
In-Reply-To: <1301868139.62.0.934615407924.issue11756@psf.upfronthosting.co.za>
Message-ID: <1301870142.97.0.234903761301.issue11756@psf.upfronthosting.co.za>


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

Actually, this is a duplicate of issue 9951.

----------
nosy: +r.david.murray
resolution: invalid -> duplicate
stage:  -> committed/rejected
superseder:  -> introduce bytes.hex method

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

From report at bugs.python.org  Mon Apr  4 00:41:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Apr 2011 22:41:02 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1301869729.01.0.184154211485.issue10791@psf.upfronthosting.co.za>
Message-ID: <1301870460.3512.28.camel@localhost.localdomain>


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

> Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:
> 
> > Is following change in GzipFile class enough:
> > 
> >     def read1(self, n):
> >         return self.read(n)
> > 
> > ? This satisfies TextIOWrapper to run readline correctly.
> 
> Looks good to me.

Well, ideally, read1() should satisfy the condition stated in the
BufferedIOBase documentation - namely, that it issues at most one read()
call on the underlying stream.

----------

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

From report at bugs.python.org  Mon Apr  4 01:10:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Apr 2011 23:10:31 +0000
Subject: [issue11688] SQLite trace callback
In-Reply-To: <1301177361.02.0.994780961602.issue11688@psf.upfronthosting.co.za>
Message-ID: <1301872231.42.0.0331068452753.issue11688@psf.upfronthosting.co.za>


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

Reopening, a failure appeared on some of the buildbots. I've made the failure message a bit more explicit:

test_sqlite: testing with version '2.6.0', sqlite_version '3.6.12'
[...]

======================================================================
FAIL: CheckUnicodeContent (sqlite3.test.hooks.TraceCallbackTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/sqlite3/test/hooks.py", line 220, in CheckUnicodeContent
    % (ascii(unicode_value), ', '.join(map(ascii, traced_statements))))
AssertionError: False is not true : Unicode data '\xf6\xe4\xfc\xd6\xc4\xdc\xdf\u20ac' garbled in trace callback: 'create table foo(x)', 'BEGIN ', 'insert into foo(x) values (?)', 'COMMIT'


See e.g. http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%202%203.x/builds/168/steps/test/logs/stdio

----------
status: closed -> open

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

From report at bugs.python.org  Mon Apr  4 01:21:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 03 Apr 2011 23:21:59 +0000
Subject: [issue11753] test_sendall_interrupted() of test_socket hangs on
	FreeBSD
In-Reply-To: <1301859893.52.0.614181082416.issue11753@psf.upfronthosting.co.za>
Message-ID: <1301872919.9.0.645478347687.issue11753@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The problem is that faulthandler's thread (faulthandler_thread) receives the SIGALRM signal: the signal interrupts sem_timedwait() which returns EINTR. PyThread_acquire_lock_timed() retries sem_timedwait() and so the other thread executing sendall() is not interrupted.

The solution is to configure which signals are handled by faulthandler_thread() using pthread_sigmask():
http://hg.python.org/sandbox/haypo/rev/4257fdfa5661

I forced a build on x86 FreeBSD (custom) buildbot:
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%20custom

I already tested sigprocmask() on FreeBSD (in my VM) and it works as expected: test_socket doesn't block anymore.

----------

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

From report at bugs.python.org  Mon Apr  4 01:22:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Apr 2011 23:22:36 +0000
Subject: [issue11749] test_socket failure
In-Reply-To: <1301846913.96.0.368639647794.issue11749@psf.upfronthosting.co.za>
Message-ID: <E1Q6Wcs-00009u-Le@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 68a319ef70fc by Antoine Pitrou in branch '3.2':
Issue #11749: try to fix transient test_socket failure
http://hg.python.org/cpython/rev/68a319ef70fc

New changeset 44fc5f94bc90 by Antoine Pitrou in branch 'default':
Issue #11749: try to fix transient test_socket failure
http://hg.python.org/cpython/rev/44fc5f94bc90

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Apr  4 01:25:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 03 Apr 2011 23:25:18 +0000
Subject: [issue11738] ThreadSignals.test_signals() of test_threadsignals hangs
	on PPC Tiger 3.x buildbot
In-Reply-To: <1301673336.69.0.136519124397.issue11738@psf.upfronthosting.co.za>
Message-ID: <1301873118.52.0.0797711044337.issue11738@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

May be related to #11753.

----------

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

From report at bugs.python.org  Mon Apr  4 01:42:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Apr 2011 23:42:26 +0000
Subject: [issue11688] SQLite trace callback
In-Reply-To: <1301177361.02.0.994780961602.issue11688@psf.upfronthosting.co.za>
Message-ID: <1301874146.35.0.900888999054.issue11688@psf.upfronthosting.co.za>


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

Ok, it seems that expanding the value of bound parameters in the statement passed to the trace callback is a recent SQLite feature:

http://www.sqlite.org/draft/releaselog/3_6_21.html
    ?The SQL output resulting from sqlite3_trace() is now modified to include the values of bound parameters.?

----------

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

From report at bugs.python.org  Mon Apr  4 01:50:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Apr 2011 23:50:58 +0000
Subject: [issue11688] SQLite trace callback
In-Reply-To: <1301177361.02.0.994780961602.issue11688@psf.upfronthosting.co.za>
Message-ID: <E1Q6X4K-0001qs-MF@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ce37570768f5 by Antoine Pitrou in branch 'default':
Fix TraceCallbackTests to not use bound parameters (followup to issue #11688)
http://hg.python.org/cpython/rev/ce37570768f5

----------

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

From report at bugs.python.org  Mon Apr  4 02:14:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Apr 2011 00:14:46 +0000
Subject: [issue9347] Calling argparse add_argument with a sequence as 'type'
	causes spurious error message
In-Reply-To: <1279891670.23.0.306869867423.issue9347@psf.upfronthosting.co.za>
Message-ID: <E1Q6XRK-00034A-L7@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f961e9179998 by Steven Bethard in branch '2.7':
Issue #9347: Fix formatting for tuples in argparse type= error messages.
http://hg.python.org/cpython/rev/f961e9179998

New changeset 69ab5251f3f0 by Steven Bethard in branch '3.2':
Issue #9347: Fix formatting for tuples in argparse type= error messages.
http://hg.python.org/cpython/rev/69ab5251f3f0

New changeset 1f3f6443810a by Steven Bethard in branch 'default':
Issue #9347: Fix formatting for tuples in argparse type= error messages.
http://hg.python.org/cpython/rev/1f3f6443810a

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Apr  4 02:15:33 2011
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 04 Apr 2011 00:15:33 +0000
Subject: [issue9347] Calling argparse add_argument with a sequence as 'type'
	causes spurious error message
In-Reply-To: <1279891670.23.0.306869867423.issue9347@psf.upfronthosting.co.za>
Message-ID: <1301876133.88.0.484487602617.issue9347@psf.upfronthosting.co.za>


Changes by Steven Bethard <steven.bethard at gmail.com>:


----------
assignee:  -> bethard
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions: +Python 3.3

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

From report at bugs.python.org  Mon Apr  4 02:22:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Apr 2011 00:22:02 +0000
Subject: [issue11688] SQLite trace callback
In-Reply-To: <1301177361.02.0.994780961602.issue11688@psf.upfronthosting.co.za>
Message-ID: <1301876522.08.0.256762314022.issue11688@psf.upfronthosting.co.za>


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

Should be fixed now.

----------
status: open -> closed

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

From report at bugs.python.org  Mon Apr  4 02:25:37 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 04 Apr 2011 00:25:37 +0000
Subject: [issue9951] introduce bytes.hex method
In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za>
Message-ID: <1301876737.69.0.44072104721.issue9951@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

See also: issue11756

----------
nosy: +rhettinger
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Mon Apr  4 03:58:43 2011
From: report at bugs.python.org (Mark Mc Mahon)
Date: Mon, 04 Apr 2011 01:58:43 +0000
Subject: [issue1104] msilib.SummaryInfo.GetProperty() truncates the string by
	one character
In-Reply-To: <1188943421.22.0.776458935296.issue1104@psf.upfronthosting.co.za>
Message-ID: <1301882323.96.0.652418521011.issue1104@psf.upfronthosting.co.za>


Mark Mc Mahon <mtnbikingmark at gmail.com> added the comment:

I have updated the patch for current trunk (though no real changes required). I also include a testcase.

One thing to review is that I added functionality to the tests to create the MSI to be tested. (felt this was safer than touching one of the ones under %systemroot%\installer.

----------
keywords: +patch
nosy: +markm
Added file: http://bugs.python.org/file21524/issue1104_msi_2.patch

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

From report at bugs.python.org  Mon Apr  4 04:02:46 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 04 Apr 2011 02:02:46 +0000
Subject: [issue1104] msilib.SummaryInfo.GetProperty() truncates the string by
	one character
In-Reply-To: <1188943421.22.0.776458935296.issue1104@psf.upfronthosting.co.za>
Message-ID: <1301882566.66.0.64342751086.issue1104@psf.upfronthosting.co.za>


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

+        path, msilib.schema, "Ptyhon Tests", "product_code", "1.0", "PSF")
s/Ptyhon/Python/

----------
nosy: +ezio.melotti
stage: test needed -> patch review

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

From report at bugs.python.org  Mon Apr  4 04:38:44 2011
From: report at bugs.python.org (Mark Mc Mahon)
Date: Mon, 04 Apr 2011 02:38:44 +0000
Subject: [issue1104] msilib.SummaryInfo.GetProperty() truncates the string by
	one character
In-Reply-To: <1188943421.22.0.776458935296.issue1104@psf.upfronthosting.co.za>
Message-ID: <1301884724.22.0.518929727201.issue1104@psf.upfronthosting.co.za>


Mark Mc Mahon <mtnbikingmark at gmail.com> added the comment:

And fix the typo... (thanks Ezio)

----------
Added file: http://bugs.python.org/file21525/issue1104_msi_3.patch

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

From report at bugs.python.org  Mon Apr  4 06:47:14 2011
From: report at bugs.python.org (mdorn)
Date: Mon, 04 Apr 2011 04:47:14 +0000
Subject: [issue11758] increase xml.dom.minidom test coverage
In-Reply-To: <1301892434.54.0.122832391998.issue11758@psf.upfronthosting.co.za>
Message-ID: <1301892434.54.0.122832391998.issue11758@psf.upfronthosting.co.za>


New submission from mdorn <matt.dorn at gmail.com>:

Added some tests to ensure xml.dom.NotFoundErr where appropriate, and for a handful of previously untested methods.  Increased coverage from 52% to 53%.

----------
components: Tests, XML
files: increase_minidom_test_coverage.patch
keywords: patch
messages: 132915
nosy: mdorn
priority: normal
severity: normal
status: open
title: increase xml.dom.minidom test coverage
versions: Python 3.3
Added file: http://bugs.python.org/file21526/increase_minidom_test_coverage.patch

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

From report at bugs.python.org  Mon Apr  4 07:52:51 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 04 Apr 2011 05:52:51 +0000
Subject: [issue9670] Exceed Recursion Limit in Thread
In-Reply-To: <1282656201.3.0.572219885558.issue9670@psf.upfronthosting.co.za>
Message-ID: <1301896371.77.0.393210184013.issue9670@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Here's an updated combined patch.  I've revised Ronald's test to run via subprocess so it should be safe to add to the standard tests.  It works as expected on OS X.  If there are no objections, I will commit it and monitor the buildbots.

----------
nosy: +ned.deily
stage: patch review -> commit review
Added file: http://bugs.python.org/file21527/issue9670-v3.patch

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

From report at bugs.python.org  Mon Apr  4 08:07:01 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 04 Apr 2011 06:07:01 +0000
Subject: [issue10433] Document unique behavior of 'getgroups' on OSX
In-Reply-To: <1289916367.38.0.763799196023.issue10433@psf.upfronthosting.co.za>
Message-ID: <1301897221.89.0.978878476458.issue10433@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Here's a revised doc patch. As noted from my investigation in Issue7900, the key getgroups behavior change is with the OS X 10.6 ABI (so > 10.5), not 10.5.

----------
stage: needs patch -> commit review
Added file: http://bugs.python.org/file21528/issue10433-v2.patch

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

From report at bugs.python.org  Mon Apr  4 08:39:24 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 04 Apr 2011 06:39:24 +0000
Subject: [issue11571] Turtle window pops under the terminal on OSX
In-Reply-To: <1300287451.35.0.164099198094.issue11571@psf.upfronthosting.co.za>
Message-ID: <1301899164.3.0.988144870261.issue11571@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Looks good to me.  I tested on OS X with both Tk 8.5 on 10.6 and Tk 8.4 on 10.5.  The demo runs fine under IDLE.app and bin/idle3.  If no objections, I'll commit the patch with the nit addressed.

----------
keywords: +patch
stage:  -> commit review
versions: +Python 2.7, Python 3.2
Added file: http://bugs.python.org/file21529/issue11571.patch

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

From report at bugs.python.org  Mon Apr  4 08:49:15 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 04 Apr 2011 06:49:15 +0000
Subject: [issue11759] assert for exception parameters
In-Reply-To: <1301899755.88.0.769835930918.issue11759@psf.upfronthosting.co.za>
Message-ID: <1301899755.88.0.769835930918.issue11759@psf.upfronthosting.co.za>


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

I've just realized that unittest doesn't provide a way to test arguments of exception thrown during assertRaises check.

----------
components: Tests
messages: 132919
nosy: techtonik
priority: normal
severity: normal
status: open
title: assert for exception parameters

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

From report at bugs.python.org  Mon Apr  4 09:23:34 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Mon, 04 Apr 2011 07:23:34 +0000
Subject: [issue11757] test_subprocess failure
In-Reply-To: <1301869705.52.0.173979620005.issue11757@psf.upfronthosting.co.za>
Message-ID: <1301901814.56.0.805476252113.issue11757@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

_remaining_time doesn't check that endtime > current time and can return a negative number, which would trigger an EINVAL when passed to select (select_select doesn't seem to check for negative double).
Note that a check is performed through _check_timeout but after having called select, so there are at least two possible ways to get this error:
The process blocks a little before calling select for the first time. This can at least happen here:
    if self.stdin and not self._communication_started:
        # Flush stdio buffer.  This might block, if the user has
        # been writing to .stdin in an uncontrolled fashion.
        self.stdin.flush()
        if not input:
            self.stdin.close()

There's also a short race window if the endtime deadline expires between the call to _check_timeout and remaining_time.

----------
nosy: +neologix

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

From report at bugs.python.org  Mon Apr  4 10:55:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Apr 2011 08:55:43 +0000
Subject: [issue11757] test_subprocess failure
In-Reply-To: <1301869705.52.0.173979620005.issue11757@psf.upfronthosting.co.za>
Message-ID: <1301907343.88.0.570179969595.issue11757@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

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

From report at bugs.python.org  Mon Apr  4 11:06:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Apr 2011 09:06:08 +0000
Subject: [issue11753] test_sendall_interrupted() of test_socket hangs on
	FreeBSD
In-Reply-To: <1301859893.52.0.614181082416.issue11753@psf.upfronthosting.co.za>
Message-ID: <E1Q6fjL-0005Ka-Ja@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ebc03d7e7110 by Victor Stinner in branch 'default':
Issue #11753: faulthandler thread uses pthread_sigmask()
http://hg.python.org/cpython/rev/ebc03d7e7110

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Apr  4 11:08:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Apr 2011 09:08:06 +0000
Subject: [issue11753] test_sendall_interrupted() of test_socket hangs on
	FreeBSD
In-Reply-To: <1301859893.52.0.614181082416.issue11753@psf.upfronthosting.co.za>
Message-ID: <1301908086.12.0.405156075773.issue11753@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_socket and test_signal succeed on "x86 FreeBSD custom":
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%20custom/builds/4
(there are other issues, but there are not related)

I pushed the fix in Python 3.3 (ebc03d7e7110).

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

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

From report at bugs.python.org  Mon Apr  4 11:27:10 2011
From: report at bugs.python.org (Daniel Urban)
Date: Mon, 04 Apr 2011 09:27:10 +0000
Subject: [issue11759] assert for exception parameters
In-Reply-To: <1301899755.88.0.769835930918.issue11759@psf.upfronthosting.co.za>
Message-ID: <1301909230.08.0.5199735245.issue11759@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

What about this:

>>> class MyTestCase(TestCase):
...     def test_foo(self):
...             with self.assertRaises(SyntaxError) as cm:
...                     compile('asdf jkl', 'file.py', 'eval')
...             self.assertEqual('file.py', cm.exception.filename)

This isn't good enough?

----------
nosy: +durban

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

From report at bugs.python.org  Mon Apr  4 11:37:04 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 04 Apr 2011 09:37:04 +0000
Subject: [issue11759] assert for exception parameters
In-Reply-To: <1301899755.88.0.769835930918.issue11759@psf.upfronthosting.co.za>
Message-ID: <1301909824.12.0.685677614032.issue11759@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
resolution:  -> invalid
stage:  -> committed/rejected

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

From report at bugs.python.org  Mon Apr  4 11:43:22 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 04 Apr 2011 09:43:22 +0000
Subject: [issue11759] assert for exception parameters
In-Reply-To: <1301899755.88.0.769835930918.issue11759@psf.upfronthosting.co.za>
Message-ID: <1301910202.7.0.625027417803.issue11759@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Looks like a hack (and not the obvious one). I guess no asserts return values like this, so that usage is not really intuitive for me.

----------

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

From report at bugs.python.org  Mon Apr  4 11:46:58 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 04 Apr 2011 09:46:58 +0000
Subject: [issue11759] assert for exception parameters
In-Reply-To: <1301899755.88.0.769835930918.issue11759@psf.upfronthosting.co.za>
Message-ID: <1301910418.88.0.444416073887.issue11759@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I found that successful assert in twisted returns exception object. But thanks for workaround anyway.

----------

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

From report at bugs.python.org  Mon Apr  4 11:50:46 2011
From: report at bugs.python.org (Daniel Urban)
Date: Mon, 04 Apr 2011 09:50:46 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1301910646.82.0.17268612839.issue1294232@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

The attached patch seems to correct this issue.  It contains the test attached yesterday, and it passes now.

I factored out the winner calculation from type_new to a new _PyType_CalculateWinner function, and type_new calls this.  I've put the declaration of this function into object.h, so __build_class__ can also call it, instead of using the metaclass of the first base.  (Am I correct in thinking that the underscore prefix keeps it out of the public API?)

A slight problem may be, that in some cases this function will be called twice.  But it is quite simple, so I don't think it matters much:

Without patch:
$ ./python -m timeit -- "class A(type): pass
class B: pass
class C(metaclass=A): pass
class D(B, C): pass
"
10000 loops, best of 3: 371 usec per loop

With patch:
$ ./python -m timeit -- "class A(type): pass
class B: pass
class C(metaclass=A): pass
class D(B, C): pass
"
10000 loops, best of 3: 381 usec per loop

(Note, that I generated the patch with hg extdiff, because the output of hg qdiff was much more unreadable than simple diff.  I can provide an equivalent patch generated by hg if needed.)

----------
Added file: http://bugs.python.org/file21530/issue_1294232.patch

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

From report at bugs.python.org  Mon Apr  4 12:15:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Apr 2011 10:15:35 +0000
Subject: [issue11760] Bus error in test_big_buffer() of test_zlib on "AMD64
	Snow Leopard 3.x" buildbot
In-Reply-To: <1301912134.97.0.847966944656.issue11760@psf.upfronthosting.co.za>
Message-ID: <1301912134.97.0.847966944656.issue11760@psf.upfronthosting.co.za>


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

Trace:
--------------------
...
[ 79/354] test_time
[ 80/354] test_zlib
Fatal Python error: Bus error

Traceback (most recent call first):
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/test_zlib.py", line 85 in test_big_buffer
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/case.py", line 442 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/case.py", line 494 in __call__
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/support.py", line 1078 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/support.py", line 1166 in _run_suite
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/support.py", line 1192 in run_unittest
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/test_zlib.py", line 611 in test_main
  File "./Lib/test/regrtest.py", line 1032 in runtest_inner
  File "./Lib/test/regrtest.py", line 826 in runtest
  File "./Lib/test/regrtest.py", line 650 in main
  File "./Lib/test/regrtest.py", line 1607 in <module>
make: *** [buildbottest] Bus error
program finished with exit code 2
elapsedTime=1400.363321
--------------------
http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%203.x/builds/44/steps/test/logs/stdio

----------
components: Library (Lib)
messages: 132927
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: Bus error in test_big_buffer() of test_zlib on "AMD64 Snow Leopard 3.x" buildbot
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr  4 12:37:26 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 04 Apr 2011 10:37:26 +0000
Subject: [issue6895] locale._parse_localename fails when localename does not
	contain encoding information
In-Reply-To: <1252765618.77.0.920082811868.issue6895@psf.upfronthosting.co.za>
Message-ID: <1301913446.88.0.491922975507.issue6895@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Stefan, theoretically this is

        A valid locale description (as understood by S-SYS) is:

                language[_TERRITORY[.CODESET[@Modifier]]]

        where language is indeed a ISO 639 language code (see
        doc/iso639.txt) and _TERRITORY is indeed a ISO 3166 country code
        (see doc/iso3166.txt).
..
        The ISO3166 Maintenance Agency can be found at:
        #       http://www.iso.ch/iso/en/prods-services/iso3166ma/index.html
..
        http://www.loc.gov/standards/iso639-2/

A good UNIX has copies of the files in /usr/share/misc/{iso639,iso3166}.
I may be out-of-date a bit, though.
(And: this is not about Python, of course.)

----------
nosy: +sdaoden

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

From report at bugs.python.org  Mon Apr  4 12:39:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Apr 2011 10:39:21 +0000
Subject: [issue6895] locale._parse_localename fails when localename does not
	contain encoding information
In-Reply-To: <1252765618.77.0.920082811868.issue6895@psf.upfronthosting.co.za>
Message-ID: <1301913561.78.0.827729438276.issue6895@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

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

From report at bugs.python.org  Mon Apr  4 12:54:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Apr 2011 10:54:09 +0000
Subject: [issue11761] fragile tests in test_gc
In-Reply-To: <1301914448.96.0.658655701177.issue11761@psf.upfronthosting.co.za>
Message-ID: <1301914448.96.0.658655701177.issue11761@psf.upfronthosting.co.za>


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

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4329/steps/test/logs/stdio

======================================================================
FAIL: test_collect_generations (test.test_gc.GCTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\support.py", line 1142, in wrapper
    return func(*args, **kwargs)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_gc.py", line 269, in test_collect_generations
    assertEqual(gc.get_count(), (0, 0, 0))
AssertionError: Tuples differ: (3, 0, 0) != (0, 0, 0)

First differing element 0:
3
0

- (3, 0, 0)
+ (0, 0, 0)

======================================================================
FAIL: test_get_count (test.test_gc.GCTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\support.py", line 1142, in wrapper
    return func(*args, **kwargs)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_gc.py", line 252, in test_get_count
    assertEqual(gc.get_count(), (0, 0, 0))
AssertionError: (4, 0, 0) != (0, 0, 0)

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

----------
components: Tests
messages: 132929
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: fragile tests in test_gc
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Apr  4 12:54:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Apr 2011 10:54:51 +0000
Subject: [issue11738] ThreadSignals.test_signals() of test_threadsignals hangs
	on PPC Tiger 3.x buildbot
In-Reply-To: <1301673336.69.0.136519124397.issue11738@psf.upfronthosting.co.za>
Message-ID: <E1Q6hQl-0005Io-LY@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 9d59ae98013c by Victor Stinner in branch 'default':
Reenable regrtest.py timeout (30 min): #11738 and #11753 looks to be fixed
http://hg.python.org/cpython/rev/9d59ae98013c

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Apr  4 12:56:02 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 04 Apr 2011 10:56:02 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1301914562.3.0.751656997461.issue10791@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Here's an implementation of read1() that satisfies that condition, along with
some relevant unit tests.

----------
keywords: +patch
Added file: http://bugs.python.org/file21531/gzipfile_read1.diff

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

From report at bugs.python.org  Mon Apr  4 12:56:30 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 04 Apr 2011 10:56:30 +0000
Subject: [issue6895] locale._parse_localename fails when localename does
	not	contain encoding information
In-Reply-To: <1301861487.73.0.245870526894.issue6895@psf.upfronthosting.co.za>
Message-ID: <4D99A3A3.8080807@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Stefan Krah wrote:
> 
> Stefan Krah <stefan-usenet at bytereef.org> added the comment:
> 
> Is there another (authoritative) source for locale aliases apart
> from X.org? On Ubuntu Lucid, many aliases for installed locales
> are missing:
> 
> f = open("/var/lib/locales/supported.d/local")
> locale_list = [loc.split()[0] for loc in f.readlines() \
>                if not loc.startswith('#')]
> 
> for loc in locale_list:
>     x = locale.setlocale(locale.LC_ALL, loc)
>     try:
>         y = locale.getlocale()
>     except ValueError:
>         print(loc)
> 
> aa_DJ

Hmm, I get:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/locale.py", line 513, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

The "local" file you mention only contains "en_US.UTF-8 UTF-8" on
our Ubuntu 10.04.1 default installation.

Have you installed some other package to get support for all those
locales ?

----------
title: locale._parse_localename fails when localename does not contain encoding information -> locale._parse_localename fails when localename does not	contain encoding information

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

From report at bugs.python.org  Mon Apr  4 13:00:32 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 04 Apr 2011 11:00:32 +0000
Subject: [issue11678] Add support for Arch	Linux to
	platform.linux_distributions()
In-Reply-To: <1301580467.08.0.808985189683.issue11678@psf.upfronthosting.co.za>
Message-ID: <4D99A493.9010309@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Westley Mart?nez wrote:
> 
> Westley Mart?nez <anikom15 at gmail.com> added the comment:
> 
> Perhaps I wasn't clear. That release version isn't for the system. It's for the installation disc. There's no way to get that info and it means nothing to anyone anyways. All users of Arch are expected to have their system fully up to date. There are no releases; Just do "pacman -Syu" and the system is made up to date.

Interesting. In that case, I guess version and id don't make sense
for Arch Linux.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

----------
title: Add support for Arch Linux	to	platform.linux_distributions() -> Add support for Arch	Linux to platform.linux_distributions()

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

From report at bugs.python.org  Mon Apr  4 13:02:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Apr 2011 11:02:40 +0000
Subject: [issue11749] test_socket failure
In-Reply-To: <1301846913.96.0.368639647794.issue11749@psf.upfronthosting.co.za>
Message-ID: <1301914960.29.0.526648667594.issue11749@psf.upfronthosting.co.za>


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

Looks fixed now.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Apr  4 13:07:48 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 04 Apr 2011 11:07:48 +0000
Subject: [issue6895] locale._parse_localename fails when localename does not
	contain encoding information
In-Reply-To: <4D99A3A3.8080807@egenix.com>
Message-ID: <20110404110639.GA24241@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Marc-Andre Lemburg <report at bugs.python.org> wrote:
> The "local" file you mention only contains "en_US.UTF-8 UTF-8" on
> our Ubuntu 10.04.1 default installation.
> 
> Have you installed some other package to get support for all those
> locales ?

On Ubuntu it is a bit messy:

cp /usr/share/i18n/SUPPORTED /var/lib/locales/supported.d/local
locale-gen

On Debian it should be:

# Select 'all' in the dialog
dpkg-reconfigure locales

Stefan Krah

----------
title: locale._parse_localename fails when localename does not	contain encoding information -> locale._parse_localename fails when localename does not contain encoding information

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

From report at bugs.python.org  Mon Apr  4 13:17:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Apr 2011 11:17:13 +0000
Subject: [issue11760] Bus error in test_big_buffer() of test_zlib on "AMD64
	Snow Leopard 3.x" buildbot
In-Reply-To: <1301912134.97.0.847966944656.issue11760@psf.upfronthosting.co.za>
Message-ID: <1301915833.93.0.965929279519.issue11760@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Another failure on test_zlib on the same buildbot: build 30
http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%203.x/builds/30/steps/test/logs/stdio

--

I already noticed some failures on test_mmap: build 8, 25 and 36
http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%203.x/builds/36/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%203.x/builds/25/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%203.x/builds/8/steps/test/logs/stdio

--

and on test_urllibnet: build 7

http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%203.x/builds/7/steps/test/logs/stdio

(network issue?)

--

and on test_threadsignals
http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%203.x/builds/2/steps/test/logs/stdio

Issue #11738?

----------

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

From report at bugs.python.org  Mon Apr  4 13:23:39 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Apr 2011 11:23:39 +0000
Subject: [issue11760] Bus error in test_big_buffer() of test_zlib on "AMD64
	Snow Leopard 3.x" buildbot
In-Reply-To: <1301912134.97.0.847966944656.issue11760@psf.upfronthosting.co.za>
Message-ID: <1301916219.73.0.709237127592.issue11760@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_zlib failure is on zlib.crc32(mmap.mmap(...)) with a mapping bigger than 4 GB:
----------------------
# Issue #10276 - check that inputs >=4GB are handled correctly.
class ChecksumBigBufferTestCase(unittest.TestCase):

    def setUp(self):
        with open(support.TESTFN, "wb+") as f:
            f.seek(_4G)
            f.write(b"asdf")
        with open(support.TESTFN, "rb") as f:
            self.mapping = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)

    def tearDown(self):
        self.mapping.close()
        support.unlink(support.TESTFN)

    @unittest.skipUnless(mmap, "mmap() is not available.")
    @unittest.skipUnless(sys.maxsize > _4G, "Can't run on a 32-bit system.")
    @unittest.skipUnless(support.is_resource_enabled("largefile"),
                         "May use lots of disk space.")
    def test_big_buffer(self):
        self.assertEqual(zlib.crc32(self.mapping), 3058686908) <~~~ HERE
        self.assertEqual(zlib.adler32(self.mapping), 82837919)
----------------------

It looks to be related to #11277 (and #10276).

----------

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

From report at bugs.python.org  Mon Apr  4 13:30:39 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Apr 2011 11:30:39 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1301916639.63.0.704838722353.issue11277@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue is not dead: test_zlib failed twice on "AMD64 Snow Leopard 3.x" buildbot: build 30 (024967cdc2f0e850f0b338e7593a12d965017a6a, Mar 31 01:40:00 2011) and 44 (ebc03d7e711052c0b196aacdbec6778c0a6d5c0c, Apr 4 10:11:20 2011).

Build 44 has a traceback thanks to faulthandler:
--------------------
...
[ 79/354] test_time
[ 80/354] test_zlib
Fatal Python error: Bus error

Traceback (most recent call first):
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/test_zlib.py", line 85 in test_big_buffer
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/case.py", line 442 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/case.py", line 494 in __call__
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/support.py", line 1078 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/support.py", line 1166 in _run_suite
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/support.py", line 1192 in run_unittest
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/test_zlib.py", line 611 in test_main
  File "./Lib/test/regrtest.py", line 1032 in runtest_inner
  File "./Lib/test/regrtest.py", line 826 in runtest
  File "./Lib/test/regrtest.py", line 650 in main
  File "./Lib/test/regrtest.py", line 1607 in <module>
make: *** [buildbottest] Bus error
program finished with exit code 2
elapsedTime=1400.363321
--------------------
http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%203.x/builds/44/steps/test/logs/stdio

test_zlib.py:85 is the crc32(+4 GB) test:
----------------------
# Issue #10276 - check that inputs >=4GB are handled correctly.
class ChecksumBigBufferTestCase(unittest.TestCase):

    def setUp(self):
        with open(support.TESTFN, "wb+") as f:
            f.seek(_4G)
            f.write(b"asdf")
        with open(support.TESTFN, "rb") as f:
            self.mapping = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)

    def tearDown(self):
        self.mapping.close()
        support.unlink(support.TESTFN)

    @unittest.skipUnless(mmap, "mmap() is not available.")
    @unittest.skipUnless(sys.maxsize > _4G, "Can't run on a 32-bit system.")
    @unittest.skipUnless(support.is_resource_enabled("largefile"),
                         "May use lots of disk space.")
    def test_big_buffer(self):
        self.assertEqual(zlib.crc32(self.mapping), 3058686908) <~~~ HERE
        self.assertEqual(zlib.adler32(self.mapping), 82837919)
----------------------

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

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

From report at bugs.python.org  Mon Apr  4 13:31:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Apr 2011 11:31:10 +0000
Subject: [issue11760] Bus error in test_big_buffer() of test_zlib on "AMD64
	Snow Leopard 3.x" buildbot
In-Reply-To: <1301912134.97.0.847966944656.issue11760@psf.upfronthosting.co.za>
Message-ID: <1301916670.5.0.354677195935.issue11760@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue is a duplicate of #11277.

----------
resolution:  -> duplicate
status: open -> closed

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

From report at bugs.python.org  Mon Apr  4 13:31:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Apr 2011 11:31:24 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1301916684.3.0.92517424954.issue11277@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Issue?#11760 has been marked as a duplicate of this issue.

----------

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

From report at bugs.python.org  Mon Apr  4 13:40:28 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 04 Apr 2011 11:40:28 +0000
Subject: [issue6895] locale._parse_localename fails when localename does not
	contain encoding information
In-Reply-To: <1252765618.77.0.920082811868.issue6895@psf.upfronthosting.co.za>
Message-ID: <1301917228.09.0.569986421387.issue6895@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


----------
nosy:  -sdaoden

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

From report at bugs.python.org  Mon Apr  4 13:57:26 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Mon, 04 Apr 2011 11:57:26 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1301918246.59.0.691597804153.issue11277@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Is the SIGBUS generated on the first page access ?
How much memory does this buildbot have ?

----------

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

From report at bugs.python.org  Mon Apr  4 15:28:53 2011
From: report at bugs.python.org (Jakub Wilk)
Date: Mon, 04 Apr 2011 13:28:53 +0000
Subject: [issue8323] multiprocessing.Queue ignores pickle restrictions in
	.put()
In-Reply-To: <1270507518.5.0.340159262485.issue8323@psf.upfronthosting.co.za>
Message-ID: <1301923733.3.0.175872243479.issue8323@psf.upfronthosting.co.za>


Changes by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy: +jwilk

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

From report at bugs.python.org  Mon Apr  4 15:35:24 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 04 Apr 2011 13:35:24 +0000
Subject: [issue11734] Add half-float (16-bit) support to struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1301924124.28.0.139325272642.issue11734@psf.upfronthosting.co.za>


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

I've only glanced at the patch, but a couple of things:

(1) It looks as though the patch assumes that a C double is IEEE 754 binary64 format, and that a C float is IEEE 754 binary32 format.  Is that correct?

If so, that's a significant break with tradition:  Python's supposed to be able to work with the native doubles, no matter what their format.  I, for one, wouldn't object if IEEE floating-point were made a requirement for Python >= 3.3, but this change would need to be discussed on the python-dev mailing list.

(2)  The

  typedef PY_LONG_LONG npy_uint64;

looks wrong to me for two reasons:  first, PY_LONG_LONG is a signed type.  Second, while it's guaranteed (by the C standard) that unsigned long long will have width at least 64, it's not guaranteed that it'll be exactly 64.  Does the code depend on this assumption?  Similarly when using unsigned int in the union for the 32-bit code;  here it's not even guaranteed by the standards that unsigned int has width at least 32.

It may be better to use the PY_UINT64_T type and the HAVE_UINT64_T macros, and similarly for the 32-bit types.

----------

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

From report at bugs.python.org  Mon Apr  4 15:38:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Apr 2011 13:38:42 +0000
Subject: [issue8428] buildbot: test_multiprocessing timeout (test_notify_all?
	test_pool_worker_lifetime?)
In-Reply-To: <1271451412.83.0.723333785051.issue8428@psf.upfronthosting.co.za>
Message-ID: <1301924322.11.0.0435448563064.issue8428@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here is a nice trace on "PPC Leopard 3.x" thanks to faulthandler + regrtest timeout (30 minutes):
-------------------------------
...
[218/354] test_multiprocessing
Thread 0xf0617000:
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 235 in wait
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/queue.py", line 185 in get
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/multiprocessing/pool.py", line 372 in _handle_results
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 688 in run
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 735 in _bootstrap_inner
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 708 in _bootstrap

Thread 0xf0595000:
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 235 in wait
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/queue.py", line 185 in get
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/multiprocessing/pool.py", line 331 in _handle_tasks
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 688 in run
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 735 in _bootstrap_inner
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 708 in _bootstrap

Thread 0xf0513000:
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/multiprocessing/pool.py", line 324 in _handle_workers
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 688 in run
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 735 in _bootstrap_inner
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 708 in _bootstrap

Thread 0xf0491000:
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 235 in wait
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/queue.py", line 185 in get
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/multiprocessing/pool.py", line 102 in worker
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 688 in run
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 735 in _bootstrap_inner
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 708 in _bootstrap

Thread 0xf040f000:
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 235 in wait
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/queue.py", line 185 in get
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/multiprocessing/pool.py", line 102 in worker
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 688 in run
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 735 in _bootstrap_inner
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 708 in _bootstrap

Thread 0xf038d000:
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 235 in wait
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/queue.py", line 185 in get
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/multiprocessing/pool.py", line 102 in worker
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 688 in run
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 735 in _bootstrap_inner
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 708 in _bootstrap

Thread 0xf030b000:
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 235 in wait
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/queue.py", line 185 in get
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/multiprocessing/pool.py", line 102 in worker
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 688 in run
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 735 in _bootstrap_inner
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/threading.py", line 708 in _bootstrap

Thread 0xa09e1820:
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/multiprocessing/forking.py", line 134 in poll
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/multiprocessing/forking.py", line 149 in wait
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/multiprocessing/process.py", line 149 in join
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/multiprocessing/pool.py", line 458 in join
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/test/test_multiprocessing.py", line 1195 in test_pool_worker_lifetime
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/unittest/case.py", line 442 in run
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/unittest/case.py", line 494 in __call__
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/test/support.py", line 1078 in run
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/test/support.py", line 1166 in _run_suite
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/test/support.py", line 1192 in run_unittest
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/test/test_multiprocessing.py", line 2141 in test_main
  File "./Lib/test/regrtest.py", line 1032 in runtest_inner
  File "./Lib/test/regrtest.py", line 826 in runtest
  File "./Lib/test/regrtest.py", line 650 in main
  File "./Lib/test/regrtest.py", line 1607 in <module>
make: *** [buildbottest] Error 1
-------------------------------
http://www.python.org/dev/buildbot/all/builders/PPC%20Leopard%203.x/builds/1634/steps/test/logs/stdio

 * The main thread (thread 0xa09e1820) is joining the pool (p.join()), wait in Popen.poll(): os.waitpid(self.pid, 0)
 * There are 4 workers waiting on their get() function, _Condition.wait(): if timeout is None: waiter.acquire()
 * The multiprocess Pool has 3 threads:

   * _handle_workers() (Thread 0xf0513000) is waiting in its polling loop:
       while pool._worker_handler._state == RUN and pool._state == RUN:
            pool._maintain_pool()
            time.sleep(0.1)
   * _handle_tasks() (thread 0xf0595000) is waiting on taskqueue.get()
   * _handle_results() (thread 0xf0617000) is waiting on get() method of another Queue

The main thread is waiting a child process, but we don't have the state of this process.

----------

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

From report at bugs.python.org  Mon Apr  4 15:39:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Apr 2011 13:39:51 +0000
Subject: [issue9592] Limitations in objects returned by multiprocessing Pool
In-Reply-To: <1281726168.11.0.648826556363.issue9592@psf.upfronthosting.co.za>
Message-ID: <1301924391.55.0.85629622585.issue9592@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

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

From report at bugs.python.org  Mon Apr  4 15:45:23 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 Apr 2011 13:45:23 +0000
Subject: [issue11759] assert for exception parameters
In-Reply-To: <1301899755.88.0.769835930918.issue11759@psf.upfronthosting.co.za>
Message-ID: <1301924723.35.0.164875122709.issue11759@psf.upfronthosting.co.za>


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

Using assertRaises as a context manager is not a hack, and is the correct way to do this in unittest.

----------
nosy: +r.david.murray
status: open -> closed

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

From report at bugs.python.org  Mon Apr  4 15:48:31 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 04 Apr 2011 13:48:31 +0000
Subject: [issue9815] assertRaises as a context manager keeps tracebacks and
	frames alive
In-Reply-To: <1284103100.0.0.404704166803.issue9815@psf.upfronthosting.co.za>
Message-ID: <1301924911.19.0.759606392375.issue9815@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/issue9815>
_______________________________________

From report at bugs.python.org  Mon Apr  4 15:59:38 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 04 Apr 2011 13:59:38 +0000
Subject: [issue11759] assert for exception parameters
In-Reply-To: <1301899755.88.0.769835930918.issue11759@psf.upfronthosting.co.za>
Message-ID: <1301925578.94.0.717944849935.issue11759@psf.upfronthosting.co.za>


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

See also #6275.

----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Mon Apr  4 16:04:41 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 04 Apr 2011 14:04:41 +0000
Subject: [issue11759] assert for exception parameters
In-Reply-To: <1301899755.88.0.769835930918.issue11759@psf.upfronthosting.co.za>
Message-ID: <1301925881.84.0.128845157092.issue11759@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I've also found #9587. Now I wonder how many people requested return vs context, and how many would vote for one vs another. Nothing personal - just a pure curiosity.

----------

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

From report at bugs.python.org  Mon Apr  4 16:17:17 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 04 Apr 2011 14:17:17 +0000
Subject: [issue11759] assert for exception parameters
In-Reply-To: <1301899755.88.0.769835930918.issue11759@psf.upfronthosting.co.za>
Message-ID: <1301926637.82.0.0755375787258.issue11759@psf.upfronthosting.co.za>


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

That was a design decision made by Guido (iirc), and even if it might seem not obvious at first, it's probably just because not everyone is Dutch.
Many people would probably vote on sequence.join(sep) too, but it's unlikely that another way to do it will be introduced.

The doc for assertRaises[0] also is quite clear and even includes an example where the exception args are checked.

[0]: http://docs.python.org/py3k/library/unittest.html#unittest.TestCase.assertRaises

----------

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

From report at bugs.python.org  Mon Apr  4 16:18:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Apr 2011 14:18:23 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1301914562.3.0.751656997461.issue10791@psf.upfronthosting.co.za>
Message-ID: <1301926699.3538.13.camel@localhost.localdomain>


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

> Here's an implementation of read1() that satisfies that condition, along with
> some relevant unit tests.

Something looks fishy: what happens if size is -1 and EOFError is not
raised?

----------

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

From report at bugs.python.org  Mon Apr  4 16:27:04 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 04 Apr 2011 14:27:04 +0000
Subject: [issue11759] assert for exception parameters
In-Reply-To: <1301899755.88.0.769835930918.issue11759@psf.upfronthosting.co.za>
Message-ID: <1301927224.47.0.614759408547.issue11759@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Thanks for clarification, Ezio. I am still using Python 2.7 - that's why I've missed this part.

----------

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

From report at bugs.python.org  Mon Apr  4 16:57:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Apr 2011 14:57:01 +0000
Subject: [issue11738] ThreadSignals.test_signals() of test_threadsignals hangs
	on PPC Tiger 3.x buildbot
In-Reply-To: <1301673336.69.0.136519124397.issue11738@psf.upfronthosting.co.za>
Message-ID: <1301929021.37.0.392129694491.issue11738@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I think that the last test_threadsignals failures on PPC Tiger were related to the new regrtest timeout, and it is now fixed.

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

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

From report at bugs.python.org  Mon Apr  4 18:12:23 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 04 Apr 2011 16:12:23 +0000
Subject: [issue11754] Changed test to check calculated constants in
	test_string.py
In-Reply-To: <1301860347.11.0.319603986002.issue11754@psf.upfronthosting.co.za>
Message-ID: <1301933543.16.0.551560003219.issue11754@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
nosy: +brian.curtin

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

From report at bugs.python.org  Mon Apr  4 18:12:40 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 04 Apr 2011 16:12:40 +0000
Subject: [issue11758] increase xml.dom.minidom test coverage
In-Reply-To: <1301892434.54.0.122832391998.issue11758@psf.upfronthosting.co.za>
Message-ID: <1301933560.19.0.417266122184.issue11758@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
nosy: +brian.curtin

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

From report at bugs.python.org  Mon Apr  4 18:16:01 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 04 Apr 2011 16:16:01 +0000
Subject: [issue11762] Ast doc: warning and version number
In-Reply-To: <1301933761.05.0.937546235723.issue11762@psf.upfronthosting.co.za>
Message-ID: <1301933761.05.0.937546235723.issue11762@psf.upfronthosting.co.za>


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

Two related proposals.

1. Add a warning similar to the one for the dis module. As modified:

"CPython implementation detail: The ast definition is specific to the CPython interpreter! Ast nodes may be added, removed, or changed between versions. Use *ast.__version__* to work across versions."

I omitted " Use of this module should not be considered to work across Python VMs or Python releases." as redundant and too legalistic.
*ast.__version__* should link to its (new) entry).

2. Add a full entry for __version__. Currently (3.2):

"The module defines a string constant __version__ which is the decimal Subversion revision number of the file shown below."

Proposed replacement (with hidden reference point):

ast.__version__         [__version__ in normal entry boldface]
    String constant with version number of abstract grammar file.
    3.1: 67616; 3.2: 82163; 3.3: xxxxxxxxx

----------
assignee: docs at python
components: Documentation
messages: 132951
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Ast doc: warning and version number
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Apr  4 18:18:59 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 04 Apr 2011 16:18:59 +0000
Subject: [issue11762] Ast doc: warning and version number
In-Reply-To: <1301933761.05.0.937546235723.issue11762@psf.upfronthosting.co.za>
Message-ID: <1301933939.77.0.629346600192.issue11762@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Modify entry slightly to
    String constant with version number of the abstract grammar file.
    3.1: '67616'; 3.2: '82163'; 3.3: 'xxxxxxxxx'

----------
keywords: +patch

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

From report at bugs.python.org  Mon Apr  4 19:01:25 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 04 Apr 2011 17:01:25 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1301936485.6.0.268378912084.issue10791@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> Something looks fishy: what happens if size is -1 and EOFError is not raised?

You're right - I missed that possibility. In that case, extrasize and offset get
updated incorrectly, which will break subsequent calls to seek() and tell().
However, it seems that subsequent reads work fine, because slicing a bytes object
with a too-large upper bound doesn't raise an exception.

The attached patch fixes this bug, and updates test_read1() to catch regressions.

----------
Added file: http://bugs.python.org/file21532/gzipfile_read1.diff

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

From report at bugs.python.org  Mon Apr  4 19:22:08 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 04 Apr 2011 17:22:08 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1301937728.06.0.2429640816.issue11707@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

[Question from python-list]
Would a C version only be for 3.3 or backported to 3.2 and 2.7. The rationale for backport to 2.7 is that .cmp_to_key was added to 2.7 to aid transition to 3.x. A faster version would make use in 2.7 more inviting.

I understand that there is concern that performance enhancements may have unforseen effects.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Mon Apr  4 19:26:26 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 04 Apr 2011 17:26:26 +0000
Subject: [issue10175] vs version for win32 compilation of extension modules is
	undocumented.
In-Reply-To: <1287795744.75.0.288699311556.issue10175@psf.upfronthosting.co.za>
Message-ID: <1301937986.86.0.0111687128268.issue10175@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
nosy: +brian.curtin

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

From report at bugs.python.org  Mon Apr  4 19:53:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Apr 2011 17:53:22 +0000
Subject: [issue11761] fragile tests in test_gc
In-Reply-To: <1301914448.96.0.658655701177.issue11761@psf.upfronthosting.co.za>
Message-ID: <E1Q6nxo-0001rs-Bs@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 36d92e923a1a by Antoine Pitrou in branch '3.1':
Issue #11761: make tests for gc.get_count() less fragile
http://hg.python.org/cpython/rev/36d92e923a1a

New changeset 5daf9a8dc4e8 by Antoine Pitrou in branch '3.2':
Issue #11761: make tests for gc.get_count() less fragile
http://hg.python.org/cpython/rev/5daf9a8dc4e8

New changeset 24d4c5fd3bc6 by Antoine Pitrou in branch 'default':
Issue #11761: make tests for gc.get_count() less fragile
http://hg.python.org/cpython/rev/24d4c5fd3bc6

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Apr  4 20:05:33 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 04 Apr 2011 18:05:33 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1301940333.87.0.622869741116.issue11707@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I was only aiming for Py3.3.  

If someone wanted to push for a backport to 3.2, it would be up to the release manager to decide whether a performance booster would be worth the risk of introducing a bug in a point release.

ISTM that if someone really cared about performance, they would probably already be using an O(n) key-function approach.  This patch eliminates most of the overhead for calling a cmp-function, but it can't do anything about the body of the user-supplied cmp-function which will dominate the running time if it does anything useful.

----------

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

From report at bugs.python.org  Mon Apr  4 20:11:35 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 04 Apr 2011 18:11:35 +0000
Subject: [issue10023] test_lib2to3 leaks under 3.1
In-Reply-To: <1286227982.74.0.164487876735.issue10023@psf.upfronthosting.co.za>
Message-ID: <1301940695.36.0.954845554614.issue10023@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

As discussed with Ezio on IRC, this doesn't apply anymore in 3.2 nor in 3.3, so we guess we can simply mark is already fixed in a later version.

----------
nosy: +sandro.tosi
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Mon Apr  4 20:57:36 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 04 Apr 2011 18:57:36 +0000
Subject: [issue10339] test_lib2to3 leaks
In-Reply-To: <1289044173.26.0.233554890418.issue10339@psf.upfronthosting.co.za>
Message-ID: <1301943456.12.0.995584316221.issue10339@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

closing like issue10023

----------
nosy: +sandro.tosi
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Mon Apr  4 21:01:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Apr 2011 19:01:58 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <E1Q6p2D-0008Mp-HB@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 9775d67c9af9 by Antoine Pitrou in branch 'default':
Issue #10791: Implement missing method GzipFile.read1(), allowing GzipFile
http://hg.python.org/cpython/rev/9775d67c9af9

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Apr  4 21:02:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Apr 2011 19:02:53 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1301943773.65.0.620174310213.issue10791@psf.upfronthosting.co.za>


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

Patch now committed, thank you!
Since the patch adds a new API (GzipFile.read1()), I think it's better not to backport it.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
type: behavior -> feature request
versions:  -Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Apr  4 21:12:33 2011
From: report at bugs.python.org (Mark Wiebe)
Date: Mon, 04 Apr 2011 19:12:33 +0000
Subject: [issue11734] Add half-float (16-bit) support to struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1301944353.62.0.726753795968.issue11734@psf.upfronthosting.co.za>


Mark Wiebe <mwwiebe at gmail.com> added the comment:

The patch currently assumes IEEE 754 with byte-order matching the integer type. I see that pyconfig.h defines three possible cases when IEEE 754 doubles are supported, DOUBLE_IS_LITTLE_ENDIAN_IEEE754, DOUBLE_IS_BIG_ENDIAN_IEEE754, and DOUBLE_IS_ARM_MIXED_ENDIAN_IEEE754. The code should have some byte swapping to match it to the integer endianness.

If support for non-IEEE systems is still desired, implementing a conversion using isnan/isinf/frexp/ldexp should be pretty easy, though off hand I can't see an efficient way to extract the significand bits.

Regarding the PY_LONG_LONG, it should have been unsigned PY_LONG_LONG. Using PY_UINT64_T is better, though, since a bigger PY_LONG_LONG would cause trouble in the union.

For the UINT32, maybe just using the double/PY_UINT64_T versions is better, since there is no macro for FLOAT_IS_IEEE754? Falling back to a frexpr implementation if double isn't IEEE or there is no 64-bit integer type may be a reasonable tradeoff to support the few platforms where that's the case, and 2 instead of 3 separate conversion codes is a bit better maintenance-wise.

----------

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

From report at bugs.python.org  Mon Apr  4 21:34:59 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 04 Apr 2011 19:34:59 +0000
Subject: [issue4431] Distutils MSVC doesn't create manifest file (with fix)
In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za>
Message-ID: <1301945699.25.0.690115359546.issue4431@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

And also with an extension module I'm trying to build with Python-2.7.1 AMD64. Schnur's suggestion fixes it.

----------
nosy: +santa4nt

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

From report at bugs.python.org  Mon Apr  4 21:38:42 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 Apr 2011 19:38:42 +0000
Subject: [issue11731] Simplify email API via 'policy' objects
In-Reply-To: <1301597340.87.0.239759427177.issue11731@psf.upfronthosting.co.za>
Message-ID: <1301945922.33.0.648770547303.issue11731@psf.upfronthosting.co.za>


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

For some reason the create patch button isn't working (perhaps because I'm using a named branch?), so here is a patch representing the current state of the feature branch.

----------
keywords: +patch
Added file: http://bugs.python.org/file21533/policy.patch

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

From report at bugs.python.org  Mon Apr  4 22:13:00 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 04 Apr 2011 20:13:00 +0000
Subject: [issue6040] bdist_msi does not deal with pre-release version
In-Reply-To: <1242472106.67.0.523299229524.issue6040@psf.upfronthosting.co.za>
Message-ID: <1301947980.44.0.313235986293.issue6040@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Is there any workaround we can use in setup.py to set correct version for build_msi subcommand only?

----------
nosy: +techtonik

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

From report at bugs.python.org  Mon Apr  4 22:16:04 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 04 Apr 2011 20:16:04 +0000
Subject: [issue11763] assertEqual memory issues with large text inputs
In-Reply-To: <1301948164.44.0.0206798295308.issue11763@psf.upfronthosting.co.za>
Message-ID: <1301948164.44.0.0206798295308.issue11763@psf.upfronthosting.co.za>


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

>>> s = "x" * (2**29)
>>> case.assertEqual(s + "a", s + "b")
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "/home/antoine/cpython/default/Lib/unittest/case.py", line 643,
in assertEqual assertion_func(first, second, msg=msg)
 File "/home/antoine/cpython/default/Lib/unittest/case.py", line 984,
in assertMultiLineEqual secondlines = [second + '\n']
MemoryError

assertEqual delegates to assertMultilineEqual for comparing text which uses difflib for comparisons. This has performance issues (as well as memory issues) for very large inputs, so should fallback to a simple comparison (or simpler diff generation technique) for very large inputs.

----------
assignee: michael.foord
messages: 132965
nosy: ezio.melotti, michael.foord, pitrou
priority: normal
severity: normal
status: open
title: assertEqual memory issues with large text inputs
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Apr  4 22:23:27 2011
From: report at bugs.python.org (Christoph Gohlke)
Date: Mon, 04 Apr 2011 20:23:27 +0000
Subject: [issue1425127] os.remove OSError: [Errno 13] Permission denied
Message-ID: <1301948607.08.0.339366001463.issue1425127@psf.upfronthosting.co.za>


Changes by Christoph Gohlke <cgohlke at uci.edu>:


----------
nosy: +cgohlke

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

From report at bugs.python.org  Mon Apr  4 22:25:06 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 04 Apr 2011 20:25:06 +0000
Subject: [issue4431] Distutils MSVC doesn't create manifest file (with fix)
In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za>
Message-ID: <1301948706.08.0.974576092865.issue4431@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

Another workaround is by adding the linker argument to Extension() as extra_link_args:

    extra_link_args=['/MANIFEST']

----------

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

From report at bugs.python.org  Mon Apr  4 22:35:22 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 04 Apr 2011 20:35:22 +0000
Subject: [issue11764] inspect.getattr_static code execution w/ class body as
	non dict
In-Reply-To: <1301949322.52.0.106729359313.issue11764@psf.upfronthosting.co.za>
Message-ID: <1301949322.52.0.106729359313.issue11764@psf.upfronthosting.co.za>


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

In Python 3 a metclass can create a class __dict__ that is not a true dictionary. This can trigger code execution when accessing __dict__ members. getattr_static should not access them directly but do so using dict methods directly for dict subclasses and skipping classes that have non-dicts for __dict__.

The documentation should mention explicitly that the "no code execution" feature of this function is *not* a security feature and should not be relied on for security purposes.

----------
assignee: michael.foord
components: Library (Lib)
messages: 132967
nosy: michael.foord
priority: normal
severity: normal
stage: test needed
status: open
title: inspect.getattr_static code execution w/ class body as non dict
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Apr  4 23:00:24 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 Apr 2011 21:00:24 +0000
Subject: [issue11731] Simplify email API via 'policy' objects
In-Reply-To: <1301597340.87.0.239759427177.issue11731@psf.upfronthosting.co.za>
Message-ID: <1301950824.66.0.942281024803.issue11731@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file21533/policy.patch

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

From report at bugs.python.org  Mon Apr  4 23:00:58 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 Apr 2011 21:00:58 +0000
Subject: [issue11731] Simplify email API via 'policy' objects
In-Reply-To: <1301597340.87.0.239759427177.issue11731@psf.upfronthosting.co.za>
Message-ID: <1301950858.94.0.564466586066.issue11731@psf.upfronthosting.co.za>


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

Try again with a patch going in the expected direction :)

----------
Added file: http://bugs.python.org/file21534/policy.patch

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

From report at bugs.python.org  Mon Apr  4 23:07:18 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Mon, 04 Apr 2011 21:07:18 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1301951238.42.0.370079186754.issue11707@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Here are some example performance results:

def cmp(x, y):
    return y - x
    
sorted(range(1, 10000000), key=cmp_to_key(cmp))

'''
C version:
real	0m19.994s
user	0m8.053s
sys	0m1.044s

Python version:
real	0m28.825s
user	0m28.046s
sys	0m0.728s

'''


def cmp(x, y):
    x = int(x)
    y = int(y)
    return (x > y) - (y > x)
    
sorted([str(i) for i in reversed(range(1, 2000000))], key=cmp_to_key(cmp))

'''
Python version

real	0m15.930s
user	0m15.629s
sys	0m0.284s

C version

real	0m10.880s
user	0m10.585s
sys	0m0.284s
'''

There is some performance gain. I don't know however, if it's enough to use C version instead of Python, that's for Raymond to decide.

----------

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

From report at bugs.python.org  Mon Apr  4 23:08:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Apr 2011 21:08:57 +0000
Subject: [issue11765] test_faulthandler failure
In-Reply-To: <1301951337.94.0.471175067329.issue11765@psf.upfronthosting.co.za>
Message-ID: <1301951337.94.0.471175067329.issue11765@psf.upfronthosting.co.za>


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

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4334/steps/test/logs/stdio

======================================================================
FAIL: test_dump_tracebacks_later (test.test_faulthandler.FaultHandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 420, in test_dump_tracebacks_later
    self.check_dump_tracebacks_later()
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 417, in check_dump_tracebacks_later
    self._check_dump_tracebacks_later(repeat, cancel, None)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 404, in _check_dump_tracebacks_later
    self.assertRegex(trace, regex)
AssertionError: Regex didn't match: '^Thread 0x[0-9a-f]+:\n  File "<string>", line 12 in func\n  File "<string>", line 27 in <module>$' not found in 'Thread 0x00000100:\n  File "<string>", line 12 in func\n  File "<string>", line 27 in <module>\nTraceback (most recent call last):\n  File "<string>", line 27, in <module>\n  File "<string>", line 16, in func\nAssertionError: 0.997999906539917 < 1.125'

======================================================================
FAIL: test_dump_tracebacks_later_cancel (test.test_faulthandler.FaultHandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 426, in test_dump_tracebacks_later_cancel
    self.check_dump_tracebacks_later(cancel=True)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 417, in check_dump_tracebacks_later
    self._check_dump_tracebacks_later(repeat, cancel, None)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 406, in _check_dump_tracebacks_later
    self.assertEqual(trace, '')
AssertionError: 'Traceback (most recent call last):\n  File "<string>", line 27, in <module>\n   [truncated]... != ''
- Traceback (most recent call last):
-   File "<string>", line 27, in <module>
-   File "<string>", line 16, in func
- AssertionError: 0.9980001449584961 < 1.125

======================================================================
FAIL: test_dump_tracebacks_later_file (test.test_faulthandler.FaultHandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 429, in test_dump_tracebacks_later_file
    self.check_dump_tracebacks_later(file=True)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 415, in check_dump_tracebacks_later
    self._check_dump_tracebacks_later(repeat, cancel, filename)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 394, in _check_dump_tracebacks_later
    trace, exitcode = self.get_output(code, filename)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 61, in get_output
    self.assertEqual(output, '')
AssertionError: 'Traceback (most recent call last):\n  File "<string>", line 27, in <module>\n   [truncated]... != ''
- Traceback (most recent call last):
-   File "<string>", line 27, in <module>
-   File "<string>", line 16, in func
- AssertionError: 0.9980001449584961 < 1.125
- sys:1: ResourceWarning: unclosed file <_io.BufferedWriter name='c:\\docume~1\\db3l\\locals~1\\temp\\tmph6ch7_'>

======================================================================
FAIL: test_dump_tracebacks_later_repeat (test.test_faulthandler.FaultHandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 423, in test_dump_tracebacks_later_repeat
    self.check_dump_tracebacks_later(repeat=True)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 417, in check_dump_tracebacks_later
    self._check_dump_tracebacks_later(repeat, cancel, None)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 404, in _check_dump_tracebacks_later
    self.assertRegex(trace, regex)
AssertionError: Regex didn't match: '^Thread 0x[0-9a-f]+:\n  File "<string>", line 12 in func\n  File "<string>", line 27 in <module>\nThread 0x[0-9a-f]+:\n  File "<string>", line 12 in func\n  File "<string>", line 27 in <module>$' not found in 'Thread 0x00000ff4:\n  File "<string>", line 12 in func\n  File "<string>", line 27 in <module>\nThread 0x00000ff4:\n  File "<string>", line 12 in func\n  File "<string>", line 27 in <module>\nTraceback (most recent call last):\n  File "<string>", line 27, in <module>\n  File "<string>", line 16, in func\nAssertionError: 0.9700000286102295 < 1.125'

----------
assignee: haypo
components: Tests
keywords: buildbot
messages: 132970
nosy: haypo, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_faulthandler failure
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr  4 23:13:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Apr 2011 21:13:52 +0000
Subject: [issue11619] On Windows,
	don't encode filenames in the import machinery
In-Reply-To: <1300665531.85.0.426527059221.issue11619@psf.upfronthosting.co.za>
Message-ID: <E1Q6r5r-0003Bw-5k@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 1b7f484bab6e by Victor Stinner in branch 'default':
Issue #11619: _PyImport_LoadDynamicModule() doesn't encode the path to bytes
http://hg.python.org/cpython/rev/1b7f484bab6e

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Apr  4 23:15:05 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 04 Apr 2011 21:15:05 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1301951705.98.0.653307829477.issue11707@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'm working on cleaning-up (and speeding-up) the patch.  I'll post new timings once that's done.

----------

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

From report at bugs.python.org  Mon Apr  4 23:30:06 2011
From: report at bugs.python.org (BM)
Date: Mon, 04 Apr 2011 21:30:06 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1301952606.25.0.974467264854.issue2193@psf.upfronthosting.co.za>


BM <shourisha at yandex.ru> added the comment:

To Carsten Klein:
It would be great if you turn your eyes on and try to read more carefully before posting something here.

----------------------------
NAME=VALUE 
NAME is the cookie?s name, and VALUE is its value. Thus the header Set-Cookie: id=waldo sets a cookie with name id and value waldo. Both the cookie NAME  and its VALUE may be any sequence of characters except semi-colon, comma, or whitespace. 
----------------------------

In the above it says "any sequence of characters" EXCEPT a three characters: 
1. semi-colon
2. comma
3. whitespace

In English this means that "any sequence of characters" INCLUDES a colon and thus colon IS a valid character. BTW, this stupid bug is three years old, while the rest of the world implemented it right (Java, Ruby etc).

Also Python implementation of this part is at least... strange (being polite here). Because instead of excluding illegal chars, they actually going opposite by including the entire world and then going mad in the whole code inside... :-(

----------

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

From report at bugs.python.org  Mon Apr  4 23:31:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Apr 2011 21:31:27 +0000
Subject: [issue11766] test_multiprocessing failure (test_pool_worker_lifetime)
In-Reply-To: <1301952687.8.0.704166844851.issue11766@psf.upfronthosting.co.za>
Message-ID: <1301952687.8.0.704166844851.issue11766@psf.upfronthosting.co.za>


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

This sometimes happens on the buildbots:

test test_multiprocessing failed -- Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_multiprocessing.py", line 1191, in test_pool_worker_lifetime
    self.assertNotIn(None, finalworkerpids)
AssertionError: None unexpectedly found in [1788, 3984, None]

e.g. http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4334/steps/test/logs/stdio

----------
components: Library (Lib), Tests
messages: 132974
nosy: asksol, jnoller, pitrou
priority: normal
severity: normal
status: open
title: test_multiprocessing failure (test_pool_worker_lifetime)
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Apr  4 23:31:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Apr 2011 21:31:40 +0000
Subject: [issue11765] test_faulthandler failure
In-Reply-To: <1301951337.94.0.471175067329.issue11765@psf.upfronthosting.co.za>
Message-ID: <1301952700.38.0.0566976914657.issue11765@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I wrote the assertion while dump_tracebacks_later() was implemented using SIGALRM + alarm(timeout). A simple fix for this issue is just to remove the assertion. But... I'm curious, and I would like to understand.

The problem is on the following code:

    timeout = 0.5
    pause = timeout * 2.5
    # on Windows XP, b-a gives 1.249931 after sleep(1.25)
    min_pause = pause * 0.9
    a = time.time()
    time.sleep(pause)
    b = time.time()
    faulthandler.cancel_dump_tracebacks_later()
    # Check that sleep() was not interrupted
    assert (b - a) >= min_pause, "{{}} < {{}}".format(b - a, min_pause)

So time.sleep(1.25) gives a time delta of 0.998 or 0.970 seconds. Hum, this value is close to 1.0 seconds, but not to 1.25 seconds.

I see different reasons why the assertion may fail:

 * sleep() was really interrupted (by faulthandler thread writing the tracebacks?)
 * time.time() and/or sleep() are not accurate on Windows XP

----------
nosy: +belopolsky

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

From report at bugs.python.org  Mon Apr  4 23:36:24 2011
From: report at bugs.python.org (Eli Stevens)
Date: Mon, 04 Apr 2011 21:36:24 +0000
Subject: [issue11734] Add half-float (16-bit) support to struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1301952984.7.0.810300674459.issue11734@psf.upfronthosting.co.za>


Eli Stevens <wickedgrey at gmail.com> added the comment:

There seems to be some disagreement about the double-rounding issue; Mark Dickinson posted on python-ideas that he doesn't think that there is one.  If possible, I think that removing code paths that aren't needed are generally a good thing, especially if I'm going to have to add support for non-IEEE floats.

I'll start working on the isnan/isinf/frexp/ldexp implementation for the cases where either we don't have a UINT64 type, or doubles aren't IEEE.  Given my current schedule, I don't think that I'll have this done today; hopefully tomorrow morning.  :)

----------

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

From report at bugs.python.org  Mon Apr  4 23:42:05 2011
From: report at bugs.python.org (Jay Taylor)
Date: Mon, 04 Apr 2011 21:42:05 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1301953325.82.0.162674835519.issue2736@psf.upfronthosting.co.za>


Jay Taylor <outtatime at gmail.com> added the comment:

I couldn't agree more with ping's position on this.  It is against the spirit of what Python has set out to be, and the blocking needs to stop.

Any chance we could get a .epoch() function into python 2.7 as well?

----------
nosy: +Jay.Taylor

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

From report at bugs.python.org  Mon Apr  4 23:42:37 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Apr 2011 21:42:37 +0000
Subject: [issue11765] test_faulthandler failure
In-Reply-To: <1301951337.94.0.471175067329.issue11765@psf.upfronthosting.co.za>
Message-ID: <E1Q6rXe-0005Q7-Oz@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 8da8cd1ba9d9 by Victor Stinner in branch 'default':
Issue #11765: don't test time.sleep() in test_faulthandler
http://hg.python.org/cpython/rev/8da8cd1ba9d9

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Apr  4 23:44:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Apr 2011 21:44:11 +0000
Subject: [issue11765] test_faulthandler failure
In-Reply-To: <1301951337.94.0.471175067329.issue11765@psf.upfronthosting.co.za>
Message-ID: <1301953451.75.0.903976919392.issue11765@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

8da8cd1ba9d9 should fix this issue. Please reopen it if it doesn't solved it.

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

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

From report at bugs.python.org  Tue Apr  5 00:03:59 2011
From: report at bugs.python.org (Mark Wiebe)
Date: Mon, 04 Apr 2011 22:03:59 +0000
Subject: [issue11734] Add half-float (16-bit) support to struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1301954639.57.0.839844777165.issue11734@psf.upfronthosting.co.za>


Mark Wiebe <mwwiebe at gmail.com> added the comment:

There's no disagreement, since they're different cases. Taking an arbitrary double, rounding to float, then rounding to half definitely has double-rounding issues. (And I would recommend constructing an example to add to the test case to make sure you understand what's going on.) Taking two halfs, doing a primitive arithmetic operation on them as floats, then rounding back to half is what Mark was referring to on the list.

In NumPy I also tried to err more towards accuracy and performance than having each intermediate be strictly half. The einsum function retains intermediate values as floats when operating on half, for example, and that's what I recommended in the documentation.

I'd also suggest adding some more to the test suite here to verify that ties are rounding to the nearest even properly. You can see some tests for this here:

https://github.com/numpy/numpy/blob/master/numpy/core/tests/test_half.py#L124

----------

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

From report at bugs.python.org  Tue Apr  5 00:12:16 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 04 Apr 2011 22:12:16 +0000
Subject: [issue11754] Changed test to check calculated constants in
	test_string.py
In-Reply-To: <1301860347.11.0.319603986002.issue11754@psf.upfronthosting.co.za>
Message-ID: <1301955136.07.0.804532425262.issue11754@psf.upfronthosting.co.za>


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

Being rather circular, that doesn't seem to be a particularly useful test. (Not that the original is either.) It'd be more "correct" if you actually tested that hex numbers are contained within string.hexdigits, for example.

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

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

From report at bugs.python.org  Tue Apr  5 00:13:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Apr 2011 22:13:27 +0000
Subject: [issue11761] fragile tests in test_gc
In-Reply-To: <1301914448.96.0.658655701177.issue11761@psf.upfronthosting.co.za>
Message-ID: <1301955207.86.0.920137769143.issue11761@psf.upfronthosting.co.za>


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

Should be fixed now.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Apr  5 00:34:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Apr 2011 22:34:28 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1301956468.06.0.331075112853.issue11277@psf.upfronthosting.co.za>


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

The new FreeBSD buildbot had a sporadic SIGKILL in http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.x/builds/1/steps/test/logs/stdio

(apparently, faulthandler didn't dump a traceback)

By the way, we can be fairly certain now that the problem is on the OS side rather than on our (Python) side, so I'm lowering the priority.

----------
nosy: +skrah
priority: critical -> high

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

From report at bugs.python.org  Tue Apr  5 00:41:37 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 04 Apr 2011 22:41:37 +0000
Subject: [issue6792] Distutils-based installer does not detect 64bit versions
	of Python
In-Reply-To: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>
Message-ID: <1301956897.23.0.385764092464.issue6792@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
nosy: +jaraco

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

From report at bugs.python.org  Tue Apr  5 00:45:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Apr 2011 22:45:50 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1301957150.13.0.0399744466944.issue11277@psf.upfronthosting.co.za>


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

By the way, at this point I think we could simply skip the test on BSDs and OS X. The tested functionality is cross-platform, so testing under a limited set of systems should be ok.

----------

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

From report at bugs.python.org  Tue Apr  5 00:47:11 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 04 Apr 2011 22:47:11 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1301957231.14.0.542218966723.issue11277@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

For the new FreeBSD bot, the issue was simply insufficient swap space.
With 1GB of memory and 2GB of swap test_zlib runs fine.

----------

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

From report at bugs.python.org  Tue Apr  5 00:59:40 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 04 Apr 2011 22:59:40 +0000
Subject: [issue11763] assertEqual memory issues with large text inputs
In-Reply-To: <1301948164.44.0.0206798295308.issue11763@psf.upfronthosting.co.za>
Message-ID: <1301957980.31.0.62242935874.issue11763@psf.upfronthosting.co.za>


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

Attached patch adds a _diffThreshold attribute of 2**16 and uses _baseAssertEqual whenever one of the two string is longer than 2**16 chars.

----------
keywords: +patch
Added file: http://bugs.python.org/file21535/issue11763.diff

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

From report at bugs.python.org  Tue Apr  5 01:01:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Apr 2011 23:01:26 +0000
Subject: [issue11763] assertEqual memory issues with large text inputs
In-Reply-To: <1301948164.44.0.0206798295308.issue11763@psf.upfronthosting.co.za>
Message-ID: <1301958086.72.0.0823054391495.issue11763@psf.upfronthosting.co.za>


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

Rather than hardwiring `self.addCleanup(lambda: setattr(self, '_diffThreshold', 2**16))`, you should retrieve the previous value.

----------

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

From report at bugs.python.org  Tue Apr  5 01:11:10 2011
From: report at bugs.python.org (Brendan Dolan-Gavitt)
Date: Mon, 04 Apr 2011 23:11:10 +0000
Subject: [issue11767] Maildir iterator leaks file descriptors by default
In-Reply-To: <1301958670.39.0.218079408331.issue11767@psf.upfronthosting.co.za>
Message-ID: <1301958670.39.0.218079408331.issue11767@psf.upfronthosting.co.za>


New submission from Brendan Dolan-Gavitt <brendandg at gatech.edu>:

The default constructor for Maildir is rfc822.Message. This means that when iterating over a Maildir mailbox instantiated with default settings, the Mailbox class will return self._factory(self.get_file(key)), leaking the file descriptor returned by get_file(). Thus, iterating over any reasonably sized maildir mailbox will cause file descriptors to be leaked, and if a non-refcounting GC is used (as in PyPy), it is very likely that the process will run out of file descriptors.

I see that the default has changed to None, for Py3k, but this still means that using a message factory unavoidably leaks file descriptors. Ideally, I'd like the Mailbox class to close the file descriptor passed into the factory; this would mean that file descriptors are never leaked during iteration.

----------
components: Library (Lib)
messages: 132988
nosy: moyix
priority: normal
severity: normal
status: open
title: Maildir iterator leaks file descriptors by default
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Apr  5 01:30:14 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 04 Apr 2011 23:30:14 +0000
Subject: [issue11763] assertEqual memory issues with large text inputs
In-Reply-To: <1301948164.44.0.0206798295308.issue11763@psf.upfronthosting.co.za>
Message-ID: <1301959814.23.0.509017600455.issue11763@psf.upfronthosting.co.za>


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


----------
assignee: michael.foord -> ezio.melotti
components: +Library (Lib)
nosy: +rhettinger
stage:  -> patch review
type:  -> behavior
Added file: http://bugs.python.org/file21536/issue11763-2.diff

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

From report at bugs.python.org  Tue Apr  5 01:48:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Apr 2011 23:48:36 +0000
Subject: [issue10785] parser: store the filename as an unicode object
In-Reply-To: <1293504022.51.0.668746175929.issue10785@psf.upfronthosting.co.za>
Message-ID: <E1Q6tVL-00069u-S5@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6e9dc970ac0e by Victor Stinner in branch 'default':
Issue #10785: Store the filename as Unicode in the Python parser.
http://hg.python.org/cpython/rev/6e9dc970ac0e

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Apr  5 01:48:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Apr 2011 23:48:36 +0000
Subject: [issue9319] imp.find_module('test/badsyntax_pep3120') causes segfault
In-Reply-To: <1279693765.46.0.777254335316.issue9319@psf.upfronthosting.co.za>
Message-ID: <E1Q6tVL-00069u-Ry@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7b8d625eb6e4 by Victor Stinner in branch 'default':
Issue #9319: Include the filename in "Non-UTF8 code ..." syntax error.
http://hg.python.org/cpython/rev/7b8d625eb6e4

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Apr  5 01:52:37 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 04 Apr 2011 23:52:37 +0000
Subject: [issue9709] test_distutils warning: initfunc exported twice on Windows
In-Reply-To: <1283101838.76.0.73949668593.issue9709@psf.upfronthosting.co.za>
Message-ID: <1301961157.24.0.546920691002.issue9709@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

A workaround would be to define an arbitrary macro when building with distutils. For example, in setup.cfg:

    [build_ext]
    define = _DISTUTILS

Then in some main header file(s) in your project:

    #ifdef _DISTUTILS
    #undef PyMODINIT_FUNC
    #define PyMODINIT_FUNC void
    #endif

And you won't get the warning anymore.

----------
nosy: +santa4nt
versions: +Python 3.3 -3rd party

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

From report at bugs.python.org  Tue Apr  5 01:56:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Apr 2011 23:56:17 +0000
Subject: [issue9319] imp.find_module('test/badsyntax_pep3120') causes segfault
In-Reply-To: <1279693765.46.0.777254335316.issue9319@psf.upfronthosting.co.za>
Message-ID: <1301961377.15.0.72336506667.issue9319@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Hum, I'm not sure that my patch works if the locale encoding is not
> UTF-8: import.c manipulates path in the filesystem encoding, whereas
> PyTokenizer_FindEncodingFilename() expects UTF-8 filename.

Thanks to my work on #3080, the import machinery (and other functions using Python modules and filenames) manipulates filenames as Unicode, and so I don't have to care about the filename encoding anymore.

6e9dc970ac0e (of issue #10785) fixed the crash, 7b8d625eb6e4 added the filename into the SyntaxError.

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

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

From report at bugs.python.org  Tue Apr  5 01:56:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Apr 2011 23:56:24 +0000
Subject: [issue10785] parser: store the filename as an unicode object
In-Reply-To: <1293504022.51.0.668746175929.issue10785@psf.upfronthosting.co.za>
Message-ID: <1301961384.11.0.170032807326.issue10785@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


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

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

From report at bugs.python.org  Tue Apr  5 02:01:29 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 05 Apr 2011 00:01:29 +0000
Subject: [issue9709] test_distutils warning: initfunc exported twice on Windows
In-Reply-To: <1283101838.76.0.73949668593.issue9709@psf.upfronthosting.co.za>
Message-ID: <1301961689.27.0.517245398232.issue9709@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
versions: +3rd party

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

From report at bugs.python.org  Tue Apr  5 02:06:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Apr 2011 00:06:29 +0000
Subject: [issue7805] test_multiprocessing failure
In-Reply-To: <1264773760.19.0.248393154087.issue7805@psf.upfronthosting.co.za>
Message-ID: <1301961989.23.0.82970869409.issue7805@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

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

From report at bugs.python.org  Tue Apr  5 02:19:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Apr 2011 00:19:18 +0000
Subject: [issue11768] test_signals() of test_threadsignals failure on Mac OS X
	Tiger
In-Reply-To: <1301962757.99.0.598461435574.issue11768@psf.upfronthosting.co.za>
Message-ID: <1301962757.99.0.598461435574.issue11768@psf.upfronthosting.co.za>


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

test_threadsignals hangs on "x86 Tiger 3.x" and "PPC Tiger 3.x":
---------------------
[279/354] test_threadsignals
Thread 0xa000d000:
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_threadsignals.py", line 46 in test_signals
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py", line 442 in run
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py", line 494 in __call__
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 1078 in run
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 1166 in _run_suite
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 1192 in run_unittest
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_threadsignals.py", line 210 in test_main
  File "./Lib/test/regrtest.py", line 1032 in runtest_inner
  File "./Lib/test/regrtest.py", line 826 in runtest
  File "./Lib/test/regrtest.py", line 650 in main
  File "./Lib/test/regrtest.py", line 1607 in <module>
make: *** [buildbottest] Error 1
program finished with exit code 2
elapsedTime=3365.320090
---------------------
http://www.python.org/dev/buildbot/all/builders/x86%20Tiger%203.x/builds/2289/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/PPC%20Tiger%203.x/builds/1700/steps/test/logs/stdio

test_threadsignals hangs at:
----------------
class ThreadSignals(unittest.TestCase):
    def test_signals(self):
        signalled_all.acquire()
        self.spawnSignallingThread()
        signalled_all.acquire() <~~~~ here
----------------

self.spawnSignallingThread() calls:
----------------
def send_signals():
    os.kill(process_pid, signal.SIGUSR1)
    os.kill(process_pid, signal.SIGUSR2)
    signalled_all.release()
----------------

The hang may be related to regrtest timeout: faulthandler had a bug, but the bug is supposed to be fixed (#11753, #11755).

See also issue #11223.

----------
components: Library (Lib)
messages: 132993
nosy: haypo
priority: normal
severity: normal
status: open
title: test_signals() of test_threadsignals failure on Mac OS X Tiger
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr  5 02:29:51 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 05 Apr 2011 00:29:51 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1301953325.82.0.162674835519.issue2736@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=aP5GU8=AnxUkcAcMjKYCs2Za+2g@mail.gmail.com>


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

On Mon, Apr 4, 2011 at 5:42 PM, Jay Taylor <report at bugs.python.org> wrote:
..
> I couldn't agree more with ping's position on this.

Adding votes to a tracker issue without a working patch will not move
it any further.   There are several committers besides me in the nosy
list including the original author of the datetime module.  If it was
such a universally desired feature as Ka-Ping makes it sound, it would
be committed long before I became the maintainer of the datetime
module.

> ?It is against the spirit of what Python has set out to be, and the blocking needs to stop.

I don't think any committer has a power to *block* a patch.  I
certainly don't.  If  Ka-Ping wants to add a feature over my
objections, it is well within his power to do so. (Note that I
objected to timedelta.total_seconds(), but it was added nevertheless.)
 It would be best, however to bring this to python-dev or python-ideas
first.

> Any chance we could get a .epoch() function into python 2.7 as well?

No.

----------

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

From report at bugs.python.org  Tue Apr  5 02:30:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Apr 2011 00:30:08 +0000
Subject: [issue11768] test_signals() of test_threadsignals failure on Mac OS X
	Tiger
In-Reply-To: <1301962757.99.0.598461435574.issue11768@psf.upfronthosting.co.za>
Message-ID: <E1Q6u9n-00016Z-6O@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d14eac872a46 by Victor Stinner in branch 'default':
Issue #11768: add debug messages in test_threadsignals.test_signals
http://hg.python.org/cpython/rev/d14eac872a46

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Apr  5 02:35:39 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 05 Apr 2011 00:35:39 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1301963739.17.0.105584501551.issue11707@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Attaching timing code.

Results with and without patch (as cleaned-up):

  7.1 seconds without patch
  3.2 seconds with patch

----------
Added file: http://bugs.python.org/file21537/time_cmp_to_key.py

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

From report at bugs.python.org  Tue Apr  5 02:43:57 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 05 Apr 2011 00:43:57 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1301964237.09.0.355337631018.issue11707@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Attaching cleaned-up version of the patch, making it more like the pure python version:

* Made 'obj' a member so it is an accessible field
* Accept keyword arguments
* Create arg tuple like was done in the Py2.7 code
* Create the zero only once
* Expanded tests to cover all code paths

----------
Added file: http://bugs.python.org/file21538/11707_4.patch

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

From report at bugs.python.org  Tue Apr  5 02:45:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Apr 2011 00:45:30 +0000
Subject: [issue11769] test_notify() of test_threading hang on "x86 XP-4 3.x":
In-Reply-To: <1301964330.57.0.512119675756.issue11769@psf.upfronthosting.co.za>
Message-ID: <1301964330.57.0.512119675756.issue11769@psf.upfronthosting.co.za>


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

Timeout of 15 minutes on "x86 XP-4 3.x":
----------------------------
...
[334/354] test_threading
Thread 0x0000024c:
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 235 in wait
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 392 in f
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 37 in task

Thread 0x000002d8:
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 235 in wait
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 392 in f
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 37 in task

Thread 0x00000da4:
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 235 in wait
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 392 in f
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 37 in task

Thread 0x00000bb0:
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 16 in _wait
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 416 in _check_notify
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 433 in test_notify
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\case.py", line 387 in _executeTestPart
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\case.py", line 442 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\case.py", line 494 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 105 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 67 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 105 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 67 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\support.py", line 1078 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\support.py", line 1166 in _run_suite
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\support.py", line 1192 in run_unittest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_threading.py", line 728 in test_main
  File "../lib/test/regrtest.py", line 1032 in runtest_inner
  File "../lib/test/regrtest.py", line 826 in runtest
  File "../lib/test/regrtest.py", line 650 in main
  File "../lib/test/regrtest.py", line 1607 in <module>
s_push: parser stack overflow
program finished with exit code 1
elapsedTime=2601.059000
----------------------------
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4317/steps/test/logs/stdio

Hum, it looks like we have 4 threads, and all threads are waiting.

=> See issue #8799 and maybe also #4188 and #5114.

----------
components: Library (Lib)
messages: 132998
nosy: haypo
priority: normal
severity: normal
status: open
title: test_notify() of test_threading hang on "x86 XP-4 3.x":
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr  5 02:48:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Apr 2011 00:48:42 +0000
Subject: [issue11727] Add a --timeout option to regrtest.py using the
	faulthandler module
In-Reply-To: <1301566785.42.0.872105634784.issue11727@psf.upfronthosting.co.za>
Message-ID: <1301964522.93.0.694140265238.issue11727@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

regrtest default timeout is now 30 minutes.

I opened specific issues for each failure:

 * test_sendall_interrupted() of test_socket: issue #11753
 * test_itimer_real() of test_signal: issue #11755
 * test_threadsignals: issue #11768
 * test_notify() of test_threading: issue #11769

If you get new timeout issue, it's now better to open a new specific issue.

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

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

From report at bugs.python.org  Tue Apr  5 02:52:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Apr 2011 00:52:20 +0000
Subject: [issue5120] Disabling test_ttk_guionly on mac
In-Reply-To: <1233437150.39.0.445953575427.issue5120@psf.upfronthosting.co.za>
Message-ID: <1301964740.78.0.450672104652.issue5120@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Recent crash on "PPC Tiger 3.x":
----------------
[188/354] test_ttk_guionly
Fatal Python error: Segmentation fault

Traceback (most recent call first):
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/tkinter/ttk.py", line 47 in _load_tile
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/tkinter/ttk.py", line 559 in __init__
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/tkinter/ttk.py", line 614 in __init__
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_ttk_guionly.py", line 14 in <module>
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/importlib/_bootstrap.py", line 342 in _load_module
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/importlib/_bootstrap.py", line 141 in decorated
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/importlib/_bootstrap.py", line 437 in load_module
  File "./Lib/test/regrtest.py", line 1025 in runtest_inner
  File "./Lib/test/regrtest.py", line 826 in runtest
  File "./Lib/test/regrtest.py", line 650 in main
  File "./Lib/test/regrtest.py", line 1607 in <module>
make: *** [buildbottest] Segmentation fault
program finished with exit code 2
elapsedTime=1656.072954
----------------
http://www.python.org/dev/buildbot/all/builders/PPC%20Tiger%203.x/builds/1701/steps/test/logs/stdio

----------
nosy: +haypo

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

From report at bugs.python.org  Tue Apr  5 02:59:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Apr 2011 00:59:08 +0000
Subject: [issue5120] Disabling test_ttk_guionly on mac
In-Reply-To: <1233437150.39.0.445953575427.issue5120@psf.upfronthosting.co.za>
Message-ID: <1301965148.51.0.6275163466.issue5120@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

ttk_guionly creates a button (ttk.Button()) which calls _load_tile(), which crashs on: master.tk.eval('package require tile')

Code of the function:
-------------------------
def _load_tile(master):
    if _REQUIRE_TILE:
        import os
        tilelib = os.environ.get('TILE_LIBRARY')
        if tilelib:
            # append custom tile path to the the list of directories that
            # Tcl uses when attempting to resolve packages with the package
            # command
            master.tk.eval(
                    'global auto_path; '
                    'lappend auto_path {%s}' % tilelib)

        master.tk.eval('package require tile') # TclError may be raised here
        master._tile_loaded = True
-------------------------

----------

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

From report at bugs.python.org  Tue Apr  5 05:04:24 2011
From: report at bugs.python.org (Denver Coneybeare)
Date: Tue, 05 Apr 2011 03:04:24 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1301972664.34.0.360253752946.issue3905@psf.upfronthosting.co.za>


Denver Coneybeare <denver.coneybeare at gmail.com> added the comment:

I just re-tested this in cpython trunk at changeset and the issue does not appear to be reproducible.

I first launched IDLE by running "python lib\idlelib\idle.py".  Then I entered the following:

Python 3.3a0 (default, Apr  2 2011, 21:55:40) [MSC v.1500 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> import sys
>>> sys.getwindowsversion()
sys.getwindowsversion(major=5, minor=1, build=2600, platform=2, service_pack='Service Pack 3')
>>> import subprocess
>>> PIPE = subprocess.PIPE
>>> p = subprocess.Popen(["python", "-c", "print(32)"], stdin=None, stdout=PIPE, stderr=PIPE)
>>> p
<subprocess.Popen object at 0x00F85610>
>>> p.returncode
>>>

Popen() did not raise any exceptions.  I also tried in Python 2.7 and the Popen called succeeded there as well.  So my inability to reproduce the issue does not necessarily mean that the issue is fixed, but rather that it is likely dependent on the version of Windows on which Python is running.

That being said, the linked issue issue1124861 logs what appears to be the same issue and it was fixed in Python 2.6.  So maybe I'm just not old enough to have encountered this issue :)  Anyways, this issue probably can be closed as either a duplicate or fixed incidentally.

----------
nosy: +denversc

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

From report at bugs.python.org  Tue Apr  5 07:12:10 2011
From: report at bugs.python.org (Jesse Keating)
Date: Tue, 05 Apr 2011 05:12:10 +0000
Subject: [issue10332] Multiprocessing maxtasksperchild results in hang
In-Reply-To: <1288995752.47.0.110889938296.issue10332@psf.upfronthosting.co.za>
Message-ID: <1301980330.06.0.285081027761.issue10332@psf.upfronthosting.co.za>


Jesse Keating <jkeating at redhat.com> added the comment:

I can duplicate this using python-2.7-8.fc14.1 on Fedora 14, and using map_async with the pool.

----------
nosy: +jkeating

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

From report at bugs.python.org  Tue Apr  5 08:53:49 2011
From: report at bugs.python.org (Eli Stevens)
Date: Tue, 05 Apr 2011 06:53:49 +0000
Subject: [issue11734] Add half-float (16-bit) support to struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1301986429.17.0.414601790109.issue11734@psf.upfronthosting.co.za>


Eli Stevens <wickedgrey at gmail.com> added the comment:

I see the distinction about the rounding error now.  Thanks for clarifying; I've added more tests as suggested.

Looking at _struct.c, line 2085:

                    /* Skip float and double, could be
                       "unknown" float format */
                    if (ptr->format == 'd' || ptr->format == 'f')
                        break;
                    ptr->pack = native->pack;
                    ptr->unpack = native->unpack;
                    break;

I'm going to assume that it's okay to allow 'e' to pass through here, since the 'e' type is *always* going to be in IEEE 754 (not "unknown") floating point format, and the handling routines don't rely on the C conversions the way the float/double ones do.  Is that a good assumption to make?

Also, looking at the line in the native_table declaration:

    {'e',       sizeof(short),  SHORT_ALIGN,    nu_halffloat,   np_halffloat},

Does it make sense to have an entry here since there isn't actually a native representation?  ATM it's implemented as just figuring out the platform endianness, and then calling the corresponding lp_/lu_ or bp_/bu_ function.

----------

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

From report at bugs.python.org  Tue Apr  5 09:42:42 2011
From: report at bugs.python.org (Eli Stevens)
Date: Tue, 05 Apr 2011 07:42:42 +0000
Subject: [issue11734] Add half-float (16-bit) support to struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1301989362.45.0.494711991579.issue11734@psf.upfronthosting.co.za>


Eli Stevens <wickedgrey at gmail.com> added the comment:

More questions:

The current _PyFloat_Pack4 doesn't round to even:

        fbits = (unsigned int)(f + 0.5); /* Round */

Is the mismatch going to be a problem?  Should I change the _PyFloat_Pack4 implementation while I'm in there?

----------

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

From report at bugs.python.org  Tue Apr  5 09:49:44 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 05 Apr 2011 07:49:44 +0000
Subject: [issue11725] httplib and urllib2 failed ssl connection
	httplib.BadStatusLine
In-Reply-To: <1301550234.98.0.946954388837.issue11725@psf.upfronthosting.co.za>
Message-ID: <1301989784.49.0.28408139889.issue11725@psf.upfronthosting.co.za>


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

Ned: we could work around this platform issue by including openssl 1.0d in the OSX installer.  I'm not sure if that's acceptable for a bugfix release though.

----------

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

From report at bugs.python.org  Tue Apr  5 10:01:18 2011
From: report at bugs.python.org (ysj.ray)
Date: Tue, 05 Apr 2011 08:01:18 +0000
Subject: [issue11747] unified_diff function product incorrect range information
In-Reply-To: <1301806636.68.0.728514553962.issue11747@psf.upfronthosting.co.za>
Message-ID: <1301990478.87.0.615994422991.issue11747@psf.upfronthosting.co.za>


ysj.ray <ysj.ray at gmail.com> added the comment:

Since if one of the two comparing files is empty, gnu diff regards the beginning line of differences as line 0 (there is not any lines), but difflib regards it as line 1(there is a line, but empty). Not sure weather is correct since the practice usage of diff output is feeding it to "patch" program which determine the different line location mostly based on context identical lines instead of the line numbers in the hunk headers, so it doesn't matter weather it's line 0 or line 1. But it is still better to keep consist with gnu diff.

In context_diff() it is correct since if there is less then 2 different lines in a hunk, only ending line number is display in hunk header.

Here is a patch which fix this.

----------
keywords: +patch
nosy: +ysj.ray
type:  -> behavior
versions: +Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21539/issue_11747.diff

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

From report at bugs.python.org  Tue Apr  5 10:16:28 2011
From: report at bugs.python.org (ysj.ray)
Date: Tue, 05 Apr 2011 08:16:28 +0000
Subject: [issue11764] inspect.getattr_static code execution w/ class body as
	non dict
In-Reply-To: <1301949322.52.0.106729359313.issue11764@psf.upfronthosting.co.za>
Message-ID: <1301991388.73.0.392158211577.issue11764@psf.upfronthosting.co.za>


Changes by ysj.ray <ysj.ray at gmail.com>:


----------
nosy: +ysj.ray

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

From report at bugs.python.org  Tue Apr  5 10:33:29 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 05 Apr 2011 08:33:29 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <BANLkTi=aP5GU8=AnxUkcAcMjKYCs2Za+2g@mail.gmail.com>
Message-ID: <4D9AD3C5.7010700@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Just to add another data point to this discussion:

mxDateTime, which in large parts inspired the Python datetime module,
has had a .ticks() method (for local time) and a .gmticks() method
(for UTC) for more than a decade now and so far, I haven't seen a
single complaint about any of the issues raised in this discussion.

The methods naturally return the Unix ticks value as float,
since that's what the time module uses as basis and the whole purpose
of those methods is to make interaction with the time module easy
and straight-forward. Likewise, the epoch is also the same as the time
module's one.

Victor's patch could easily be updated to return floats as well,
to make it compatible with the time module.

There's only one catch that Victor's patch doesn't include: mktime()
doesn't always work with DST set to anything but -1. mxDateTime
checks the API at module load time and then determines whether
it can be used with a DST setting or not (see the mxDateTime code
for details). Not sure whether today's mktime() implementations
still have any issues with this, but it's better to double-check
than to get wrong results.

    http://www.egenix.com/products/python/mxBase/mxDateTime/

----------
nosy: +lemburg

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

From report at bugs.python.org  Tue Apr  5 10:49:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Apr 2011 08:49:33 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <4D9AD3C5.7010700@egenix.com>
Message-ID: <1301993176.2709.0.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Marc, could you maybe write a new patching taking care of the DST and
maybe also the timezone? It looks like you have a long experience in
timestamps :-)

----------

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

From report at bugs.python.org  Tue Apr  5 11:08:29 2011
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 05 Apr 2011 09:08:29 +0000
Subject: [issue11703] Bug in python >= 2.7 with urllib2 fragment
In-Reply-To: <1301347412.09.0.984655654688.issue11703@psf.upfronthosting.co.za>
Message-ID: <1301994509.89.0.170180299739.issue11703@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
nosy: +asvetlov

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

From report at bugs.python.org  Tue Apr  5 11:34:09 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Apr 2011 09:34:09 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <E1Q72eE-0004mY-4T@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a03fb2fc3ed8 by Raymond Hettinger in branch 'default':
Issue #11707: Fast C version of functools.cmp_to_key()
http://hg.python.org/cpython/rev/a03fb2fc3ed8

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Apr  5 11:50:43 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 05 Apr 2011 09:50:43 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1301993176.2709.0.camel@marge>
Message-ID: <4D9AE5E0.8060904@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> Marc, could you maybe write a new patching taking care of the DST and
> maybe also the timezone? It looks like you have a long experience in
> timestamps :-)

Sorry, but no. I'm not really a fan of the datetime module and
try to stay away from it whenever I can :-)

Note that dealing with DST in timezones other than the local time
zone, is bound to go wrong without direct access to the tz library.
The C lib doesn't provide any good way to access timezone
information other than the local timezone or UTC.

When dealing with date/time values, it is usually best to stay with
UTC and only transform those values into local times in user
interfaces on the front-end client.

Consequently, I'd suggest to only allow UTC and local timezone
conversions for the method in the datetime module.

----------

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

From report at bugs.python.org  Tue Apr  5 11:55:14 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 05 Apr 2011 09:55:14 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1301997314.6.0.00781682959927.issue11707@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the patch Filip.

Closing this.  If anyone wants to lobby the RM for a 3.2 backport, feel free to re-open and assign to the release manager for consideration.

----------
status: open -> closed

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

From report at bugs.python.org  Tue Apr  5 12:10:31 2011
From: report at bugs.python.org (Eli Stevens)
Date: Tue, 05 Apr 2011 10:10:31 +0000
Subject: [issue11734] Add half-float (16-bit) support to struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1301998231.02.0.934073455355.issue11734@psf.upfronthosting.co.za>


Eli Stevens <wickedgrey at gmail.com> added the comment:

Made the _PyFloat_Pack2 match the algo in _PyFloat_Pack4, and did similar for Unpack.  This should work on platforms that don't have IEEE 754 floats except for situations where an INF or NAN is unpacked (this is the same as the Unpack4 behavior).

This also gets rid of any need for #ifdef'd code (an ad-hoc speed test showed no noticeable difference between the numpy-based version and the CPython-based version of the functions).

I've also added a bit of documentation to this version, as well as more tests.

I haven't changed anything about the native_table entry or Pack4's non-round-to-even behavior.

----------
Added file: http://bugs.python.org/file21540/cpython-struct-float16-v4.patch

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

From report at bugs.python.org  Tue Apr  5 12:21:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Apr 2011 10:21:52 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <E1Q73OR-000181-1A@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 76ed6a061ebe by Victor Stinner in branch 'default':
Issue #11707: Fix compilation errors with Visual Studio
http://hg.python.org/cpython/rev/76ed6a061ebe

----------

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

From report at bugs.python.org  Tue Apr  5 12:33:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Apr 2011 10:33:55 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1301999635.94.0.261193311165.issue11707@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

functools_cmp_to_key() doesn't check that the argument is a callable.

>>> table=list(range(3))
>>> table.sort(key=functools.cmp_to_key(3))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not callable

PyCallable_Check() should be used, something like:

    if (!PyCallable_Check(cmp)) {
        PyErr_SetString(PyExc_TypeError, "parameter must be callable");
        return NULL;
    }

----------
nosy: +haypo

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

From report at bugs.python.org  Tue Apr  5 12:48:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Apr 2011 10:48:58 +0000
Subject: [issue11766] test_multiprocessing failure (test_pool_worker_lifetime)
In-Reply-To: <1301952687.8.0.704166844851.issue11766@psf.upfronthosting.co.za>
Message-ID: <1302000538.33.0.551787971959.issue11766@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

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

From report at bugs.python.org  Tue Apr  5 12:54:27 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 05 Apr 2011 10:54:27 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1302000867.8.0.992110848986.issue11707@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> functools_cmp_to_key() doesn't 
> check that the argument is a callable.

I don't think that is necessary; it will fail with a TypeError when the attempt is made to call it.  This is the approach we take elsewhere (look at the built-in filter() function for example).

That being said, if you really think the early check is necessary, feel free to check it in.

----------

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

From report at bugs.python.org  Tue Apr  5 12:54:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Apr 2011 10:54:28 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1302000868.81.0.110417848582.issue11277@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: test_zlib crashes under Snow Leopard buildbot -> test_zlib.test_big_buffer crashes under BSD (Mac OS X and FreeBSD)

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

From report at bugs.python.org  Tue Apr  5 12:57:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Apr 2011 10:57:18 +0000
Subject: [issue11757] test_subprocess.test_communicate_timeout_large_ouput
	failure on select(): negative timeout?
In-Reply-To: <1301869705.52.0.173979620005.issue11757@psf.upfronthosting.co.za>
Message-ID: <1302001038.12.0.90085833116.issue11757@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: test_subprocess failure -> test_subprocess.test_communicate_timeout_large_ouput failure on select(): negative timeout?

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

From report at bugs.python.org  Tue Apr  5 13:08:55 2011
From: report at bugs.python.org (Michael Foord)
Date: Tue, 05 Apr 2011 11:08:55 +0000
Subject: [issue11770] inspect.dir_static
In-Reply-To: <1302001735.74.0.572603626553.issue11770@psf.upfronthosting.co.za>
Message-ID: <1302001735.74.0.572603626553.issue11770@psf.upfronthosting.co.za>


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

A version of dir that returns all the members that can be seen by getattr_static.

----------
assignee: michael.foord
components: Library (Lib)
messages: 133017
nosy: michael.foord
priority: low
severity: normal
stage: needs patch
status: open
title: inspect.dir_static
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr  5 13:16:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Apr 2011 11:16:13 +0000
Subject: [issue11757] test_subprocess.test_communicate_timeout_large_ouput
	failure on select(): negative timeout?
In-Reply-To: <1301869705.52.0.173979620005.issue11757@psf.upfronthosting.co.za>
Message-ID: <E1Q74F2-00025q-GA@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3664fc29e867 by Victor Stinner in branch 'default':
Issue #11757: subprocess ensures that select() and poll() timeout >= 0
http://hg.python.org/cpython/rev/3664fc29e867

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Apr  5 13:33:58 2011
From: report at bugs.python.org (Michal Molhanec)
Date: Tue, 05 Apr 2011 11:33:58 +0000
Subject: [issue9390] Error in sys.excepthook on windows when redirecting
	output of the script
In-Reply-To: <1280235089.13.0.870066677678.issue9390@psf.upfronthosting.co.za>
Message-ID: <1302003238.75.0.702713463965.issue9390@psf.upfronthosting.co.za>


Michal Molhanec <molhanec at gmail.com> added the comment:

I've got the same problem with 2.7.1 (both 32bit and 64bit versions) under W7 SP1 64bit. Under WXP SP3 32bit it works OK. What's worse the output file is empty.

3.2 (tested 64bit version) behaves even worse -- it does not print the error like 2.7 but the resulting file is empty as well!

----------
nosy: +Michal.Molhanec

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

From report at bugs.python.org  Tue Apr  5 13:34:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Apr 2011 11:34:02 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1302003242.94.0.29677295736.issue1692335@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

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

From report at bugs.python.org  Tue Apr  5 13:36:54 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 Apr 2011 11:36:54 +0000
Subject: [issue11734] Add half-float (16-bit) support to struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1302003414.67.0.835138221774.issue11734@psf.upfronthosting.co.za>


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

> There's no disagreement, since they're different cases. [...]

What he said.

> Should I change the _PyFloat_Pack4 implementation while I'm in there?

No;  let's keep the patch as simple as possible.  We can open a separate issue for fixing _Pack4 if necessary.  Is the failure to round-to-even only for legacy formats, or is it for IEEE formats as well?  If the former, it's difficult to care much;  if the latter, it should definitely be fixed, but not as part of this issue.

> Made the _PyFloat_Pack2 match the algo in _PyFloat_Pack4, and did
> similar for Unpack.

Thanks;  haven't looked at the new patch yet, but hope to do so in the next few days.

----------

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

From report at bugs.python.org  Tue Apr  5 13:49:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Apr 2011 11:49:42 +0000
Subject: [issue11771] hashlib object cannot be pickled
In-Reply-To: <1302004182.5.0.155912208324.issue11771@psf.upfronthosting.co.za>
Message-ID: <1302004182.5.0.155912208324.issue11771@psf.upfronthosting.co.za>


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

$ ./python 
Python 3.3a0 (default:76ed6a061ebe, Apr  5 2011, 12:25:00) 
>>> import hashlib, pickle
>>> hash=hashlib.new('md5')
>>> pickle.dumps(hash)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
_pickle.PicklingError: Can't pickle <class '_hashlib.HASH'>: attribute lookup _hashlib.HASH failed

The problem is that _hashlib.HASH is not accessible at Python level. There is a C define to make it accessible, but it is disabled by default: "#if HASH_OBJ_CONSTRUCTOR". This test is as old as the _hashlib module (#1121611, 624918e1c1b2).

----------
components: Library (Lib)
messages: 133021
nosy: haypo
priority: normal
severity: normal
status: open
title: hashlib object cannot be pickled
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr  5 14:02:02 2011
From: report at bugs.python.org (ysj.ray)
Date: Tue, 05 Apr 2011 12:02:02 +0000
Subject: [issue11605] EMail generator.flatten() disintegrates over non-ascii
	multipart/alternative
In-Reply-To: <1300532156.44.0.386489107075.issue11605@psf.upfronthosting.co.za>
Message-ID: <1302004922.91.0.694403426471.issue11605@psf.upfronthosting.co.za>


Changes by ysj.ray <ysj.ray at gmail.com>:


----------
nosy: +ysj.ray

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

From report at bugs.python.org  Tue Apr  5 14:13:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Apr 2011 12:13:41 +0000
Subject: [issue11771] hashlib object cannot be pickled
In-Reply-To: <1302004182.5.0.155912208324.issue11771@psf.upfronthosting.co.za>
Message-ID: <1302005621.86.0.0431200954717.issue11771@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, I don't know if it is possible to serialize a OpenSSL hash object (EVP_MD_CTX)...

----------

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

From report at bugs.python.org  Tue Apr  5 14:14:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Apr 2011 12:14:00 +0000
Subject: [issue9592] Limitations in objects returned by multiprocessing Pool
In-Reply-To: <1281726168.11.0.648826556363.issue9592@psf.upfronthosting.co.za>
Message-ID: <1302005640.64.0.00697994651415.issue9592@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> 1) A multiprocessing worker can not return (return, not raise!) an
> Exception. (...) raise an error if multiple arguments are required:
> TypeError: ('__init__() takes exactly 2 arguments (1 given)', 
> <class '__main__.MyException'>, ())

This problem comes from pickle, not multiprocessing: issue #1692335.

> 2) A multiprocessing worker can not return an hashlib Object.
> If this is attempted, pickle returns an error:

It is related to pickle and hashlib:?#11771

----------

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

From report at bugs.python.org  Tue Apr  5 14:22:51 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 Apr 2011 12:22:51 +0000
Subject: [issue11734] Add half-float (16-bit) support to struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1302006171.27.0.256365065516.issue11734@psf.upfronthosting.co.za>


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

> Is the failure to round-to-even only for legacy formats, or is it for
> IEEE formats as well?

Ah;  I see it's just for the non-IEEE formats, so not really an issue.  When the float format is known, the code just depends on a (float) cast doing the right thing, which it generally will.

----------

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

From report at bugs.python.org  Tue Apr  5 14:23:52 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 Apr 2011 12:23:52 +0000
Subject: [issue11734] Add half-float (16-bit) support to struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1302006232.5.0.636822528147.issue11734@psf.upfronthosting.co.za>


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

> I'd also suggest adding some more to the test suite here to verify that > ties are rounding to the nearest even properly.

And I second this suggestion.

----------

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

From report at bugs.python.org  Tue Apr  5 14:24:27 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 05 Apr 2011 12:24:27 +0000
Subject: [issue10977] Concrete object C API needs abstract path for subclasses
	of builtin types
In-Reply-To: <1295653779.62.0.836506069174.issue10977@psf.upfronthosting.co.za>
Message-ID: <1302006267.12.0.189797992305.issue10977@psf.upfronthosting.co.za>


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

I may have found another use case for this functionality. Currently, the Python code in heapq.py accepts arbitrary sequences (that are sufficiently compatible with the Sequence ABC), but the C code in _heapq only permits use of a concrete list.

The two currently available approaches to address that discrepancy are:
1. Use PyObject_* calls instead of PyList_* calls throughout the code (yuck, we'd be making the common case significantly worse in the name of semantic purity)
2. Sprinkle type checks throughout the _heapq code to decide whether or not to call the concrete APIs or their abstract equivalents

The extensive use of the PyList macro API in _heapq means that a little bit of 2 might still be necessary even if the concrete API was updated as Raymond suggests, but I think there would be value in changing the meaning of the concrete APIs to include falling back to the abstract APIs if the type assumption is incorrect.

----------

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

From report at bugs.python.org  Tue Apr  5 14:43:13 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 05 Apr 2011 12:43:13 +0000
Subject: [issue10977] Concrete object C API needs abstract path for subclasses
	of builtin types
In-Reply-To: <1295653779.62.0.836506069174.issue10977@psf.upfronthosting.co.za>
Message-ID: <1302007393.55.0.842645907345.issue10977@psf.upfronthosting.co.za>


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

I added a few commments on Daniel's draft patch. However, I'm getting nervous about the performance impact of all these extra pointer comparisons.

We should probably hold off on this until more of the macro benchmark suite runs on Py3k so we can get as hint as to the possible speed impact on real application code.

----------

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

From report at bugs.python.org  Tue Apr  5 15:18:19 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 Apr 2011 13:18:19 +0000
Subject: [issue975330] Inconsistent newline handling in email module
Message-ID: <1302009499.01.0.629680538831.issue975330@psf.upfronthosting.co.za>


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

Well, it's two years later, but I did look at this during the sprints at PyCon, though I didn't get as far as posting it then (I only just now rediscovered the patch on my laptop).

Python3 no longer has a "binary" flag on base64mime.encode, so here is a proposed patch for Python3.  I'm not sure if this should be backported or not, but I'm leaning that way.  Theoretically it should be only an improvement, but I can easily imagine unix-only programs unknowingly depending on the previous non-translation of newlines.  Still, since email is about intermachine communication and this clearly makes it more RFC compliant, the change is a legitimate bug fix and the chance of breakage is relatively small.

Tests are still needed.

----------
Added file: http://bugs.python.org/file21541/crlf-body-encode.patch

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

From report at bugs.python.org  Tue Apr  5 15:33:13 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 Apr 2011 13:33:13 +0000
Subject: [issue11772] email header wrapping edge case failure
In-Reply-To: <1302010393.33.0.35644236516.issue11772@psf.upfronthosting.co.za>
Message-ID: <1302010393.33.0.35644236516.issue11772@psf.upfronthosting.co.za>


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

I discovered the attached failure case in the process of investigating another issue.  The bug (a continuation line with no leading white space) doesn't exist in 2.7, but in 2.7 the extra whitespace is not preserved (that is, the output of the new test looks just like the output of the Face2 test), which is consistent with email4's handling of header whitespace in general.

----------
assignee: r.david.murray
components: Library (Lib)
files: test_email_extra_test.patch
keywords: patch
messages: 133029
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: email header wrapping edge case failure
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21542/test_email_extra_test.patch

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

From report at bugs.python.org  Tue Apr  5 16:02:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Apr 2011 14:02:08 +0000
Subject: [issue11771] hashlib object cannot be pickled
In-Reply-To: <1302004182.5.0.155912208324.issue11771@psf.upfronthosting.co.za>
Message-ID: <1302012128.46.0.552990700902.issue11771@psf.upfronthosting.co.za>


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

Why on Earth would you want to serialize a hashlib object?
It makes as much sense as serializing, say, a JSONEncoder.

----------
nosy: +gregory.p.smith, pitrou

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

From report at bugs.python.org  Tue Apr  5 16:07:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Apr 2011 14:07:52 +0000
Subject: [issue11767] Maildir iterator leaks file descriptors by default
In-Reply-To: <1301958670.39.0.218079408331.issue11767@psf.upfronthosting.co.za>
Message-ID: <1302012472.12.0.368591158251.issue11767@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/issue11767>
_______________________________________

From report at bugs.python.org  Tue Apr  5 16:10:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Apr 2011 14:10:21 +0000
Subject: [issue10963] "subprocess" can raise OSError (EPIPE) when
	communicating with short-lived processes
In-Reply-To: <1295555014.31.0.879687826689.issue10963@psf.upfronthosting.co.za>
Message-ID: <E1Q76xR-00062I-Up@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c10d55c51d81 by Ross Lagerwall in branch '2.7':
Issue #10963: Ensure that subprocess.communicate() never raises EPIPE.
http://hg.python.org/cpython/rev/c10d55c51d81

New changeset 158495d49f58 by Ross Lagerwall in branch '3.1':
Issue #10963: Ensure that subprocess.communicate() never raises EPIPE.
http://hg.python.org/cpython/rev/158495d49f58

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Apr  5 16:12:59 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 05 Apr 2011 14:12:59 +0000
Subject: [issue10977] Concrete object C API needs abstract path for subclasses
	of builtin types
In-Reply-To: <1295653779.62.0.836506069174.issue10977@psf.upfronthosting.co.za>
Message-ID: <1302012779.37.0.446230135571.issue10977@psf.upfronthosting.co.za>


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

I find this extremely ugly. The correct way to handle this is to use the generic methods themselves. Really, the type-specific names should only be used when you have just created the type or done PyXXX_CheckExact() yourself on it.

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

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

From report at bugs.python.org  Tue Apr  5 16:14:29 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 05 Apr 2011 14:14:29 +0000
Subject: [issue10963] "subprocess" can raise OSError (EPIPE) when
	communicating with short-lived processes
In-Reply-To: <1295555014.31.0.879687826689.issue10963@psf.upfronthosting.co.za>
Message-ID: <1302012869.6.0.131910309345.issue10963@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Committed, thanks.

----------
assignee:  -> rosslagerwall
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/issue10963>
_______________________________________

From report at bugs.python.org  Tue Apr  5 16:31:05 2011
From: report at bugs.python.org (James Whisnant)
Date: Tue, 05 Apr 2011 14:31:05 +0000
Subject: [issue11652] urlib{,
	2} returns a pair of integers as the content-length value
In-Reply-To: <1300898627.63.0.121848868508.issue11652@psf.upfronthosting.co.za>
Message-ID: <1302013865.28.0.874410881081.issue11652@psf.upfronthosting.co.za>


James Whisnant <jwhisnant at gmail.com> added the comment:

Varnish on the sourceforge server has been upgraded and/or reconfigured (yesterday) to fix the issue that was happening with this file (and others).

Just an FYI that you will no longer be able to re-create the triggering error.

'content-length': '289519',
'via': '1.1 varnish'

----------
nosy: +jwhisnant

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

From report at bugs.python.org  Tue Apr  5 16:45:40 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 05 Apr 2011 14:45:40 +0000
Subject: [issue6040] bdist_msi does not deal with pre-release version
In-Reply-To: <1242472106.67.0.523299229524.issue6040@psf.upfronthosting.co.za>
Message-ID: <1302014740.24.0.294916493261.issue6040@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Metadata can be automatically figured out using regexp matching like ^\d+(\.\d+){2,3}, but for explicit handling there should be should some callback or msi-specific version property in metadata. In the end it is pretty logical if binary distribution process can be configured using distribution specific (bdist_* specific) properties.

In the meanwhile here is the workaround:
{{{

from distutils.command.bdist_msi import bdist_msi

class bdist_msi_version_hack(bdist_msi):
    """ bdist_msi requires version to be in x.x.x format
        because it is embedded into MSI
    """
    def run(self):
        # strip suffix from version, i.e. from 11.0.0+r3443
        saved = self.distribution.metadata.version
        self.distribution.metadata.version = saved.split('+')[0]
        bdist_msi.run(self)
        saved_version = self.distribution.metadata.version

setup(
    ...
    cmdclass={'bdist_msi': bdist_msi_version_hack},
)
}}}

----------

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

From report at bugs.python.org  Tue Apr  5 16:52:58 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 05 Apr 2011 14:52:58 +0000
Subject: [issue6040] bdist_msi does not deal with pre-release version
In-Reply-To: <1242472106.67.0.523299229524.issue6040@psf.upfronthosting.co.za>
Message-ID: <1302015178.06.0.636205938027.issue6040@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Wrong code. The last line in the bdist_msi_version_hack override should be:

  self.distribution.metadata.version = saved

----------

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

From report at bugs.python.org  Tue Apr  5 16:59:32 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 05 Apr 2011 14:59:32 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <4D9AD3C5.7010700@egenix.com>
Message-ID: <BANLkTinhd2fqrojOS=+zzzX8iHrQ8UiTxQ@mail.gmail.com>


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

On Tue, Apr 5, 2011 at 4:33 AM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
..
> mxDateTime, which in large parts inspired the Python datetime module,
> has had a .ticks() method (for local time) and a .gmticks() method
> (for UTC) for more than a decade now

Yes, mxDateTime's gmticks()/ticks() pair of functions present a much
more mature design than anything that has been proposed here.  It is
telling, however, that no one has mentioned mxDateTime's gmticks() on
this issue in four years.  On a duplicate issue 1673409, Marc did
bring it up, but as far as I can tell, no one responded.  See
msg75411.

Google code search,

http://www.google.com/codesearch?hl=en&sa=N&q=gmticks+lang:python

returns only 13 hits for "gmticks".  In several instances, the
resulting float is immediately converted to int, in other instances
"gmticks" is mentioned in comments and the code works around its bugs.

I would not use Google Code search as an ultimate arbiter on the
popularity of a feature, so I would really like to hear from the
proponents about real life uses of gmticks() or any other examples
where a similar method "has been reimplemented over and over again."

> so far, I haven't seen a single complaint about any of the issues raised in this discussion.

Well, search for gmticks does not return too many hits outside of
mxDateTime code and manuals, but I had no trouble finding this:

"""
 okay, all the MySQLdb dataobject tick-based time handling methods are
  broken in various ways -- reconstruct GMT ticks from time module's
  mktime...
"""
http://viewvc.tigris.org/ds/viewMessage.do?dsForumId=4251&dsMessageId=656863

Follow the link for some more colorful language describing developer's
experience with the feature.

Note that it is likely that the bug MySQLdb developer complained about
was fixed in mxDateTime at some point,
<http://www.egenix.com/www2002/python/mxDateTime-History.html>, but
this shows that implementing gmticks() correctly is not as trivial as
those who never tried might think.

>
> The methods naturally return the Unix ticks value as float,
> since that's what the time module uses as basis

Which in turn is a mistake IMO.  Note that POSIX does not use float
timestamps for a reason.

> and the whole purpose
> of those methods is to make interaction with the time module easy
> and straight-forward.

This is not the goal that I would support.  I would rather see code
that uses datetime module not require time module methods at all.

> Victor's patch could easily be updated to return floats as well,
> to make it compatible with the time module.
>

Victor reported implementing two methods, one to return a float and
another to return a tuple. See msg124259.  I am not sure I've seen
that code.

> There's only one catch that Victor's patch doesn't include ...

No, it is not  about "only one catch". Victor's patch is simply wrong.
 For an aware datetime instance it extracts DST flag from tzinfo, but
ignores the offset.

----------

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

From report at bugs.python.org  Tue Apr  5 17:19:00 2011
From: report at bugs.python.org (Abhijeet Rastogi)
Date: Tue, 05 Apr 2011 15:19:00 +0000
Subject: [issue11773] Unicode compared using "is" results in abnormal behavior
In-Reply-To: <1302016739.97.0.129069075348.issue11773@psf.upfronthosting.co.za>
Message-ID: <1302016739.97.0.129069075348.issue11773@psf.upfronthosting.co.za>


New submission from Abhijeet Rastogi <abhijeet.1989 at gmail.com>:

>>> a = u'0'
>>> a is u'0'
False
>>> a == u'0'
True
>>>

----------
components: Unicode
messages: 133038
nosy: shadyabhi
priority: normal
severity: normal
status: open
title: Unicode compared using "is" results in abnormal behavior
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr  5 17:22:52 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 05 Apr 2011 15:22:52 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1302016972.68.0.428520064904.issue2736@psf.upfronthosting.co.za>


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

MAL> Since most of the datetime module was inspired by mxDateTime,
MAL> I wonder why [ticks()/gmticks()] were left out. (msg75411)

"""
The datetime module intended to be an island of relative sanity.
Because the range of dates "timestamps" can represent varies across
platforms (and even "the epoch" varies), datetime doesn't even try to
produce timestamps directly -- datetime is more of an alternative to
"seconds from the epoch" schemes. Because datetime objects have
greater range and precision than timestamps, conversion is
problem-free in only one direction. It's not a coincidence that
that's the only direction datetime supplies ;-)
""" - Tim Peters
 
http://bytes.com/topic/python/answers/522572-datetime-timestamp

I will also add that fromtimestamp() is not invertible in the presence of DST.  That's why mxDatetime.ticks() takes a DST flag making it effectively a multi-valued function.  Note that naive users, who just want to pass datetime values to an OS function expecting a float, most likely will not have means of properly obtaining DST flag.

----------

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

From report at bugs.python.org  Tue Apr  5 17:23:24 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 05 Apr 2011 15:23:24 +0000
Subject: [issue11773] Unicode compared using "is" results in abnormal behavior
In-Reply-To: <1302016739.97.0.129069075348.issue11773@psf.upfronthosting.co.za>
Message-ID: <1302017004.93.0.836323354956.issue11773@psf.upfronthosting.co.za>


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

The fact that "is" works in this way here is just an implementation detail.  If you want to compare strings use ==, "is" is used to verify if two variables refer to the same object or not.

>>> x = 100
>>> x is 100
True
>>> x = 1000
>>> x is 1000
False

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

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

From report at bugs.python.org  Tue Apr  5 17:25:51 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 05 Apr 2011 15:25:51 +0000
Subject: [issue11605] EMail generator.flatten() disintegrates over non-ascii
	multipart/alternative
In-Reply-To: <1300532156.44.0.386489107075.issue11605@psf.upfronthosting.co.za>
Message-ID: <1302017151.57.0.404802932317.issue11605@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

ysj.ray, this rude workaround manages it yet for me
(self._msg is a BytesParser() generated Message):


            if not self._msg.is_multipart():
                return
            topmost = True
            for part in self._msg.walk():
                if topmost:
                    topmost = False
                    continue
                ct = part.get_content_type()
                if not ct.startswith('text'):
                    continue

                try:
                    payload = part.get_payload()
                    charset = part.get_param('charset')
                    if charset is not None:
                        del part['content-transfer-encoding']
                        part.set_payload(payload, charset)
                except:


Note you can't simply use encoders because those break
on byte messages.
(But it would be cool if you see quopri and base64 fail
and open issues for that!)

Have fun,
Steffen

----------

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

From report at bugs.python.org  Tue Apr  5 17:28:11 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 Apr 2011 15:28:11 +0000
Subject: [issue11605] EMail generator.flatten() disintegrates over non-ascii
	multipart/alternative
In-Reply-To: <1300532156.44.0.386489107075.issue11605@psf.upfronthosting.co.za>
Message-ID: <1302017291.43.0.513721457989.issue11605@psf.upfronthosting.co.za>


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

I'm working on this.  It appears to be a bug in the bytes parser, rather than the generator.

----------

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

From report at bugs.python.org  Tue Apr  5 17:28:51 2011
From: report at bugs.python.org (hasenpfeffer)
Date: Tue, 05 Apr 2011 15:28:51 +0000
Subject: [issue1596321] KeyError at exit after 'import threading' in other
	thread
Message-ID: <1302017331.57.0.716655609225.issue1596321@psf.upfronthosting.co.za>


hasenpfeffer <hasenpfeffer at rabbittsoup.com> added the comment:

I encountered this issue recently in Python 3.2 and wanted to make some observations about it.

The real problem here is not the KeyError.  Though the suggested patches would fix the KeyError symptom, they do not fix the underlying issue.  The underlying issue is the threading module assumes that it is imported from the Python main thread.  When alien threads exist, the threading module may be imported (directly or indirectly) from a thread that is not the Python main thread, causing the wrong thread to be marked as the Python main thread.

The resulting problems of the wrong thread being marked as the Python main thread appear to be minor.  The KeyError at exit is one of them.  Another problem I encountered was with confusion in a threaded debugger that displayed my alien thread as the Python main thread, and the Python main thread as the alien thread.

In my project I can easily work around this by importing the threading module in a root package that is extremely likely to be imported from the Python main thread, causing the correct thread to be marked as the main thread.

Since I have a workaround for my project, in addition to the relatively minor issues that result from this behavior, I haven't spent any time looking into how to fix the underlying issue.  If I have the time, I'll suggest one.

----------
nosy: +hasenpfeffer
versions: +Python 2.7, Python 3.2 -Python 2.6, Python 3.1

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

From report at bugs.python.org  Tue Apr  5 17:29:32 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 Apr 2011 15:29:32 +0000
Subject: [issue11605] EMail generator.flatten() disintegrates over non-ascii
	multipart/alternative
In-Reply-To: <1300532156.44.0.386489107075.issue11605@psf.upfronthosting.co.za>
Message-ID: <1302017372.84.0.181517969379.issue11605@psf.upfronthosting.co.za>


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

Although there's a (different) bug in the generator, too, I think :)

----------

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

From report at bugs.python.org  Tue Apr  5 18:18:32 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 05 Apr 2011 16:18:32 +0000
Subject: [issue4112] Subprocess: Popen'ed children hang due to open pipes
In-Reply-To: <1223894179.31.0.303015562598.issue4112@psf.upfronthosting.co.za>
Message-ID: <1302020312.02.0.594258407561.issue4112@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

This has been fixed with all the subprocess improvements in between 3.1 and 3.2 but the decision has been taken (msg125910) not to backport the fix to 3.1 and 2.7 which would involve a C extension.

However, a workaround on 2.7 and 3.1 is to set close_fds=True.

Closing as "wont fix".

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Tue Apr  5 18:20:41 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 05 Apr 2011 16:20:41 +0000
Subject: [issue2320] Race condition in subprocess using stdin
In-Reply-To: <1205760712.39.0.906940637593.issue2320@psf.upfronthosting.co.za>
Message-ID: <1302020441.03.0.644271293571.issue2320@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Closing this as fixed since it has been fixed on 3.2 and decided not to be backported on 3.1 and 2.7.

----------
nosy: +rosslagerwall
resolution: out of date -> fixed
status: open -> closed

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

From report at bugs.python.org  Tue Apr  5 18:21:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Apr 2011 16:21:32 +0000
Subject: [issue9840] Recursive Repr
In-Reply-To: <1284329600.42.0.558454209322.issue9840@psf.upfronthosting.co.za>
Message-ID: <1302020492.67.0.126332067986.issue9840@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FTR, the answer to my interrogation in my previous message is contained in Raymond?s PyCon talk about API design: http://pycon.blip.tv/file/4883290/ :)

----------

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

From report at bugs.python.org  Tue Apr  5 18:25:09 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Tue, 05 Apr 2011 16:25:09 +0000
Subject: [issue7101] tarfile: OSError with TarFile.add(...,
	recursive=True) about non-existing file
In-Reply-To: <1255218562.66.0.694569702907.issue7101@psf.upfronthosting.co.za>
Message-ID: <1302020709.35.0.723995114478.issue7101@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

I kept this issue open, because I have not yet come to a decision. I don't think the current behaviour is a bug, but these kinds of errors could be handled more intelligently.
For example, errors during extraction can be hidden depending on the TarFile.errorlevel attribute. Something similar could be done for creation of archives. What exactly, I don't know... I have not yet managed to make up my mind.

----------

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

From report at bugs.python.org  Tue Apr  5 18:26:25 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 05 Apr 2011 16:26:25 +0000
Subject: [issue6040] bdist_msi does not deal with pre-release version
In-Reply-To: <1242472106.67.0.523299229524.issue6040@psf.upfronthosting.co.za>
Message-ID: <1302020785.04.0.583081893146.issue6040@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

The above workaround still doesn't isolate version modification to bdist_msi command, because bdist_msi is calling `build` and `install` targets before doing its own stuff.

Any ideas how to override version for MSI without copying while `bdist_msi` contents?

Definitely something to think about in distutils2.

----------

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

From report at bugs.python.org  Tue Apr  5 18:27:24 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 05 Apr 2011 16:27:24 +0000
Subject: [issue6040] bdist_msi does not deal with pre-release version
In-Reply-To: <1242472106.67.0.523299229524.issue6040@psf.upfronthosting.co.za>
Message-ID: <1302020844.84.0.0132661916944.issue6040@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

s/while/whole/

Sorry.

----------

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

From report at bugs.python.org  Tue Apr  5 18:30:54 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 05 Apr 2011 16:30:54 +0000
Subject: [issue9861] subprocess module changed exposed attributes
In-Reply-To: <1284560392.0.0.232628441453.issue9861@psf.upfronthosting.co.za>
Message-ID: <1302021054.88.0.617270815226.issue9861@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

This changes seems to have been made from 2.5 to 2.6 which are security fix only.

Closing as "wont fix".

----------
nosy: +rosslagerwall
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Tue Apr  5 18:49:51 2011
From: report at bugs.python.org (Todd Whiteman)
Date: Tue, 05 Apr 2011 16:49:51 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1302022191.09.0.491047286647.issue3905@psf.upfronthosting.co.za>


Todd Whiteman <twhitema at yahoo.com.au> added the comment:

I still see this problem (in Python 2.7.1 and Python 3.1.2).

When testing using idle, you'll need to launch using "pythonw.exe", i.e.:

pythonw.exe lib\idlelib\idle.py

----------

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

From report at bugs.python.org  Tue Apr  5 19:16:35 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 05 Apr 2011 17:16:35 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <BANLkTinhd2fqrojOS=+zzzX8iHrQ8UiTxQ@mail.gmail.com>
Message-ID: <4D9B4E5D.2080003@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> On Tue, Apr 5, 2011 at 4:33 AM, Marc-Andre Lemburg
> <report at bugs.python.org> wrote:
> ..
>> mxDateTime, which in large parts inspired the Python datetime module,
>> has had a .ticks() method (for local time) and a .gmticks() method
>> (for UTC) for more than a decade now
> 
> Yes, mxDateTime's gmticks()/ticks() pair of functions present a much
> more mature design than anything that has been proposed here.  It is
> telling, however, that no one has mentioned mxDateTime's gmticks() on
> this issue in four years.  On a duplicate issue 1673409, Marc did
> bring it up, but as far as I can tell, no one responded.  See
> msg75411.
> 
> Google code search,
> 
> http://www.google.com/codesearch?hl=en&sa=N&q=gmticks+lang:python
> 
> returns only 13 hits for "gmticks".  In several instances, the
> resulting float is immediately converted to int, in other instances
> "gmticks" is mentioned in comments and the code works around its bugs.
> 
> I would not use Google Code search as an ultimate arbiter on the
> popularity of a feature, so I would really like to hear from the
> proponents about real life uses of gmticks() or any other examples
> where a similar method "has been reimplemented over and over again."

mxDateTime needs those two methods, since it doesn't natively
use timezones. The .ticks() method is used for local time values,
.gmticks() for UTC ones; that's why there are two methods.

The .gmticks() method is always used when storing UTC values
in mxDateTime instances, which actually is the preferred way
of storing data in databases. Google Code doesn't really count
much, since it only scans a limited number of OSS code bases.
Most of our users are commercial users who use the tools
in-house.

Note that implementing .gmticks() is fairly easy on POSIX
conform systems. On most others, timegm() can be used. If
that doesn't exist, things get tricky, but that case should
be rare nowadays.

>> so far, I haven't seen a single complaint about any of the issues raised in this discussion.
> 
> Well, search for gmticks does not return too many hits outside of
> mxDateTime code and manuals, but I had no trouble finding this:
> 
> """
>  okay, all the MySQLdb dataobject tick-based time handling methods are
>   broken in various ways -- reconstruct GMT ticks from time module's
>   mktime...
> """
> http://viewvc.tigris.org/ds/viewMessage.do?dsForumId=4251&dsMessageId=656863
> 
> Follow the link for some more colorful language describing developer's
> experience with the feature.
> 
> Note that it is likely that the bug MySQLdb developer complained about
> was fixed in mxDateTime at some point,
> <http://www.egenix.com/www2002/python/mxDateTime-History.html>, but
> this shows that implementing gmticks() correctly is not as trivial as
> those who never tried might think.

Note that he was referring to the .ticks() method, not the .gmticks()
method. The patch doesn't say which version of mxDateTime he was
using. The bug mentioned in the changelog was fixed in 1998. It is
possible, however, that the mktime() on his system was broken - which
is why I added a test for it in mxDateTime.

>>
>> The methods naturally return the Unix ticks value as float,
>> since that's what the time module uses as basis
> 
> Which in turn is a mistake IMO.  Note that POSIX does not use float
> timestamps for a reason.

The time module is our reference in this case and this tries hard
to add fractions of a second to the value :-)

Note that sub-second accuracy relies on a number of factors,
the storage format most certainly is the least important
aspect ;-)

On many systems, you only get 1/100s accuracy, on others, the timer
ticks in fixed increments, giving you even weirder sub-second values
(e.g. time appears to stay constant between time.time() calls).

OTOH, there's a new set of APIs for nano-second accuracy available
now, which the datetime module objects cannot represent at all due
to the integer-based storage format.

BTW: The integer format was chose in order to keep the memory
footprint of the objects low.

>> and the whole purpose
>> of those methods is to make interaction with the time module easy
>> and straight-forward.
> 
> This is not the goal that I would support.  I would rather see code
> that uses datetime module not require time module methods at all.

No chance :-) In practice, the time module gets used a lot
for date/time storage or to quickly measure time deltas.
Some people also prefer time module ticks due to their lower
memory footprint, esp. when it comes to storing thousands of
time values in time series.

>> Victor's patch could easily be updated to return floats as well,
>> to make it compatible with the time module.
>>
> 
> Victor reported implementing two methods, one to return a float and
> another to return a tuple. See msg124259.  I am not sure I've seen
> that code.

I had a look at the last patch on this ticket.

>> There's only one catch that Victor's patch doesn't include ...
> 
> No, it is not  about "only one catch". Victor's patch is simply wrong.
>  For an aware datetime instance it extracts DST flag from tzinfo, but
> ignores the offset.

True, so make that two issues ;-)

----------

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

From report at bugs.python.org  Tue Apr  5 19:39:45 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 05 Apr 2011 17:39:45 +0000
Subject: [issue11576] timedelta subtraction glitch on big timedelta values
In-Reply-To: <1300300374.42.0.323592740228.issue11576@psf.upfronthosting.co.za>
Message-ID: <1302025185.46.0.542055175062.issue11576@psf.upfronthosting.co.za>


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

> What happens is the second value is negated (__neg__)
> which causes it to become less than timedelta.min and
> that is causing OverflowError.

Yes, and running the test case without C acceleration makes this obvious:

>>> import sys
>>> sys.modules['_datetime'] = None
>>> from datetime import *
>>> timedelta(999999999, 86399, 999999) - timedelta(999999999, 86399, 999998)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "Lib/datetime.py", line 488, in __sub__
    return self + -other
  File "Lib/datetime.py", line 501, in __neg__
    -self._microseconds)
  File "Lib/datetime.py", line 426, in __new__
    raise OverflowError("timedelta # of days is too large: %d" % d)
OverflowError: timedelta # of days is too large: -1000000000

Attached patch fixes the issue.  I would like to think some more about C int overflow before committing.

----------
assignee:  -> belopolsky
keywords: +patch
nosy: +mark.dickinson
stage:  -> patch review
Added file: http://bugs.python.org/file21543/issue11576.diff

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

From report at bugs.python.org  Tue Apr  5 19:41:03 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Apr 2011 17:41:03 +0000
Subject: [issue7311] Bug on regexp of HTMLParser
In-Reply-To: <1258043150.41.0.372876851796.issue7311@psf.upfronthosting.co.za>
Message-ID: <E1Q7AFL-0000kv-B9@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7d4dea76c476 by Ezio Melotti in branch '2.7':
#7311: fix HTMLParser to accept non-ASCII attribute values.
http://hg.python.org/cpython/rev/7d4dea76c476

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Apr  5 19:45:15 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 05 Apr 2011 17:45:15 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1302016972.68.0.428520064904.issue2736@psf.upfronthosting.co.za>
Message-ID: <4D9B5516.8090606@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> MAL> Since most of the datetime module was inspired by mxDateTime,
> MAL> I wonder why [ticks()/gmticks()] were left out. (msg75411)
> 
> """
> The datetime module intended to be an island of relative sanity.
> Because the range of dates "timestamps" can represent varies across
> platforms (and even "the epoch" varies), datetime doesn't even try to
> produce timestamps directly -- datetime is more of an alternative to
> "seconds from the epoch" schemes. Because datetime objects have
> greater range and precision than timestamps, conversion is
> problem-free in only one direction. It's not a coincidence that
> that's the only direction datetime supplies ;-)
> """ - Tim Peters
>  
> http://bytes.com/topic/python/answers/522572-datetime-timestamp
> 
> I will also add that fromtimestamp() is not invertible in the presence of DST.  That's why mxDatetime.ticks() takes a DST flag making it effectively a multi-valued function.  Note that naive users, who just want to pass datetime values to an OS function expecting a float, most likely will not have means of properly obtaining DST flag.

IMHO, the whole concept of DST is broken, but that's not our fault :-)

Ditching the concept just because it is known to fail for
one hour out of 8760 you have in a typical year doesn't really
warrant breaking the "practicality beats purity" guideline.

Otherwise, we'd have to ditch the date support in the datetime module
too: after all, Feb 29 only exists every 4 years (well, most of the
time) - and that's one day out of 1461 in those 4 years, so an
even worse ratio :-)

And I'm not even starting to talk about ditching the concept
of Unix ticks to begin with, as a result of having leap seconds
causing POSIX ticks values not matching (real) UTC ticks.

In reality, all these things hardly ever matter and if they do,
users will either know that they have to make conscious decision,
simply don't care or decide not to care.

BTW: A "timestamp" usually refers to the combination of date and
time. The time.time() return value is "seconds since the Epoch".
I usually call those values "ticks" (not sure whether it's standard
term of not, but always writing "seconds since Epoch" wasn't an
option either ;-)).

Date/time is fun, isn't it ?

----------

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

From report at bugs.python.org  Tue Apr  5 20:02:16 2011
From: report at bugs.python.org (Carsten Klein)
Date: Tue, 05 Apr 2011 18:02:16 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1302026536.03.0.724135596442.issue2193@psf.upfronthosting.co.za>


Carsten Klein <carsten.klein at axn-software.de> added the comment:

Guess you are right...

I did overlook the quoted-string reference in the RFC:

   av-pair         =       attr ["=" value]        ; optional value
   attr            =       token
   value           =       word
   word            =       token | quoted-string

The actual production rules for quoted-string are not specified, so I guess that anything resembling unicode data would be allowed in that string provided that:

[...] from RFC 2109
10.1.3  Punctuation

   In Netscape's original proposal, the values in attribute-value pairs
   did not accept "-quoted strings.  Origin servers should be cautious
   about sending values that require quotes unless they know the
   receiving user agent understands them (i.e., "new" cookies).  A
   ("new") user agent should only use quotes around values in Cookie
   headers when the cookie's version(s) is (are) all compliant with this
   specification or later.

in RFC 2965 there is no such notice...

However, and this is important, the cookie values not matching token must be quoted by the origin server upon setting and the client must return these as quoted strings as well.

----------

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

From report at bugs.python.org  Tue Apr  5 20:06:37 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 05 Apr 2011 18:06:37 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1302026797.61.0.376646596976.issue2736@psf.upfronthosting.co.za>


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

Let me state my position on this issue once again.  Converting datetime values to float is easy.   If your dt is a naive instance representing UTC time:

   timestamp = (dt - datetime(1970, 1, 1)) / timedelta(seconds=1)

If your dt is an aware instance:

   timestamp = (dt - datetime(1970, 1, 1, tzinfo=timezone.utc)) / timedelta(seconds=1)

These recipes are easy to adjust for your application needs.  One application may want millisecond or microsecond ticks, another might want to carry subsecond presision in a separate integer, third may want to avoid timestamps before 1970 or after 2038 or ignore microseconds altogether.  No matter what a hypothetical datetime.epoch() will provide, most of applications will need to add a line or two to its code to serve their needs. Applications that will use dt.epoch() naively without thinking what dt represents (say local or UTC) will be buggy.

The only related feature that I think is missing from datetime module is the ability to obtain local time as an aware datetime instance and to convert a naive datetime instance assumed to represent local time to an aware one.

This is the subject of #9527, but there is a resistance to adding that feature.

----------

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

From report at bugs.python.org  Tue Apr  5 20:08:07 2011
From: report at bugs.python.org (Carsten Klein)
Date: Tue, 05 Apr 2011 18:08:07 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1302026887.79.0.830205267855.issue2193@psf.upfronthosting.co.za>


Carsten Klein <carsten.klein at axn-software.de> added the comment:

Ups forgot to also mention the production rule for token, which is defined in the HTTP RFC RFC2616:

       token          = 1*<any CHAR except CTLs or separators>
       separators     = "(" | ")" | "<" | ">" | "@"
                      | "," | ";" | ":" | "\" | <">
                      | "/" | "[" | "]" | "?" | "="
                      | "{" | "}" | SP | HT

and here it clearly states that a value that is not a quoted string
must not contain colons, and other characters as is specified by separators.

----------

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

From report at bugs.python.org  Tue Apr  5 20:08:20 2011
From: report at bugs.python.org (Eli Stevens)
Date: Tue, 05 Apr 2011 18:08:20 +0000
Subject: [issue11734] Add half-float (16-bit) support to struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1302026900.21.0.953235106762.issue11734@psf.upfronthosting.co.za>


Eli Stevens <wickedgrey at gmail.com> added the comment:

All four changes suggested via review from Mark Dickinson have been made.  One note: the else if (!(e == 0 && f == 0.0)) { change was made; this makes the Pack2 function parallel the Pack4 function slightly less.  I agree that it's cleaner this way, but I've left the original if in as a comment for comparison to Pack4.  I'll remove the comment if it's decided that it's better to be clean than parallel.

The suggested test cases were added in the v4 patch, just in case that wasn't clear.

I'm going to assume that my questions about _struct.c aren't issues unless someone explicitly says they are.

Thanks for all of the review and feedback!  :)

----------
Added file: http://bugs.python.org/file21544/cpython-struct-float16-v5.patch

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

From report at bugs.python.org  Tue Apr  5 20:08:27 2011
From: report at bugs.python.org (Eli Stevens)
Date: Tue, 05 Apr 2011 18:08:27 +0000
Subject: [issue11734] Add half-float (16-bit) support to struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1302026907.91.0.3759800357.issue11734@psf.upfronthosting.co.za>


Changes by Eli Stevens <wickedgrey at gmail.com>:


Removed file: http://bugs.python.org/file21497/cpython-struct-float16-v1.patch

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

From report at bugs.python.org  Tue Apr  5 20:08:33 2011
From: report at bugs.python.org (Eli Stevens)
Date: Tue, 05 Apr 2011 18:08:33 +0000
Subject: [issue11734] Add half-float (16-bit) support to struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1302026913.53.0.525174621915.issue11734@psf.upfronthosting.co.za>


Changes by Eli Stevens <wickedgrey at gmail.com>:


Removed file: http://bugs.python.org/file21499/cpython-struct-float16-v3.patch

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

From report at bugs.python.org  Tue Apr  5 20:10:55 2011
From: report at bugs.python.org (Carsten Klein)
Date: Tue, 05 Apr 2011 18:10:55 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1302027055.41.0.39162883098.issue2193@psf.upfronthosting.co.za>


Carsten Klein <carsten.klein at axn-software.de> added the comment:

Perhaps the best solution would be for the Python cookie module to
gracefully adapt to servers not quoting cookie values as is required
by the RFCs and make these quoted-strings instead?

----------

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

From report at bugs.python.org  Tue Apr  5 20:13:47 2011
From: report at bugs.python.org (Carsten Klein)
Date: Tue, 05 Apr 2011 18:13:47 +0000
Subject: [issue11774] Issue tracker sends notification mails twice...
In-Reply-To: <1302027226.99.0.081276499304.issue11774@psf.upfronthosting.co.za>
Message-ID: <1302027226.99.0.081276499304.issue11774@psf.upfronthosting.co.za>


New submission from Carsten Klein <carsten.klein at axn-software.de>:

Currently I am receiving duplicates of the notification mails by your issue tracker.

----------
messages: 133062
nosy: carsten.klein at axn-software.de
priority: normal
severity: normal
status: open
title: Issue tracker sends notification mails twice...

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

From report at bugs.python.org  Tue Apr  5 20:14:48 2011
From: report at bugs.python.org (Carsten Klein)
Date: Tue, 05 Apr 2011 18:14:48 +0000
Subject: [issue11774] Issue tracker sends notification mails twice...
In-Reply-To: <1302027226.99.0.081276499304.issue11774@psf.upfronthosting.co.za>
Message-ID: <1302027288.27.0.689877784904.issue11774@psf.upfronthosting.co.za>


Carsten Klein <carsten.klein at axn-software.de> added the comment:

It seems that it only happens when commenting upon an existing issue.

----------

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

From report at bugs.python.org  Tue Apr  5 20:15:56 2011
From: report at bugs.python.org (Carsten Klein)
Date: Tue, 05 Apr 2011 18:15:56 +0000
Subject: [issue11774] Issue tracker sends notification mails twice...
In-Reply-To: <1302027226.99.0.081276499304.issue11774@psf.upfronthosting.co.za>
Message-ID: <1302027356.51.0.453439206978.issue11774@psf.upfronthosting.co.za>


Carsten Klein <carsten.klein at axn-software.de> added the comment:

Nope, it only happens on issue [issue2193] Cookie Colon Name Bug
but not for this one.

----------

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

From report at bugs.python.org  Tue Apr  5 20:16:56 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 05 Apr 2011 18:16:56 +0000
Subject: [issue11774] Issue tracker sends notification mails twice...
In-Reply-To: <1302027226.99.0.081276499304.issue11774@psf.upfronthosting.co.za>
Message-ID: <1302027416.82.0.306739153934.issue11774@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

http://psf.upfronthosting.co.za/roundup/meta is the bug tracker for the bug tracker.

Also, consider that if you are subscribed to any of the tracker mailing lists such as python-bugs-list, you might get multiple copies of tracker comments.

----------
nosy: +brian.curtin
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Apr  5 20:18:21 2011
From: report at bugs.python.org (Carsten Klein)
Date: Tue, 05 Apr 2011 18:18:21 +0000
Subject: [issue11774] Issue tracker sends notification mails twice...
In-Reply-To: <1302027226.99.0.081276499304.issue11774@psf.upfronthosting.co.za>
Message-ID: <1302027501.64.0.78576646257.issue11774@psf.upfronthosting.co.za>


Carsten Klein <carsten.klein at axn-software.de> added the comment:

Ah, I see, thanks for the input. Will close this then.

----------

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

From report at bugs.python.org  Tue Apr  5 20:18:49 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 05 Apr 2011 18:18:49 +0000
Subject: [issue11774] Issue tracker sends notification mails twice...
In-Reply-To: <1302027226.99.0.081276499304.issue11774@psf.upfronthosting.co.za>
Message-ID: <1302027529.73.0.253340204552.issue11774@psf.upfronthosting.co.za>


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

Your name appears twice in the nosy list.

----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Tue Apr  5 20:19:05 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 05 Apr 2011 18:19:05 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1302027545.04.0.670582886126.issue2193@psf.upfronthosting.co.za>


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


----------
nosy:  -carsten.klein

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

From report at bugs.python.org  Tue Apr  5 20:21:06 2011
From: report at bugs.python.org (Carsten Klein)
Date: Tue, 05 Apr 2011 18:21:06 +0000
Subject: [issue11774] Issue tracker sends notification mails twice...
In-Reply-To: <1302027226.99.0.081276499304.issue11774@psf.upfronthosting.co.za>
Message-ID: <1302027666.41.0.437766571272.issue11774@psf.upfronthosting.co.za>


Carsten Klein <carsten.klein at axn-software.de> added the comment:

I wonder how this happened...
Thanks for the finding!

----------

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

From report at bugs.python.org  Tue Apr  5 20:23:42 2011
From: report at bugs.python.org (Carsten Klein)
Date: Tue, 05 Apr 2011 18:23:42 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1302027822.31.0.336500199032.issue2193@psf.upfronthosting.co.za>


Changes by Carsten Klein <carsten.klein at axn-software.de>:


----------
nosy: +carsten.klein -carsten.klein at axn-software.de

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

From report at bugs.python.org  Tue Apr  5 20:23:50 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 05 Apr 2011 18:23:50 +0000
Subject: [issue11774] Issue tracker sends notification mails twice...
In-Reply-To: <1302027226.99.0.081276499304.issue11774@psf.upfronthosting.co.za>
Message-ID: <1302027830.96.0.572094209218.issue11774@psf.upfronthosting.co.za>


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

Maybe you changed your id or registered a new one?
I removed the duplicate one from #2193, if I got the wrong one feel free to fix it as you prefer.

----------

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

From report at bugs.python.org  Tue Apr  5 20:25:02 2011
From: report at bugs.python.org (Carsten Klein)
Date: Tue, 05 Apr 2011 18:25:02 +0000
Subject: [issue11774] Issue tracker sends notification mails twice...
In-Reply-To: <1302027226.99.0.081276499304.issue11774@psf.upfronthosting.co.za>
Message-ID: <1302027902.6.0.081185651136.issue11774@psf.upfronthosting.co.za>


Carsten Klein <carsten.klein at axn-software.de> added the comment:

Actually I logged in using carsten.klein at axn-software.de
and the tracker changed my login name to that...
Will issue a bug against the tracker...

----------
nosy: +carsten.klein

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

From report at bugs.python.org  Tue Apr  5 20:27:12 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 05 Apr 2011 18:27:12 +0000
Subject: [issue11774] Issue tracker sends notification mails twice...
In-Reply-To: <1302027226.99.0.081276499304.issue11774@psf.upfronthosting.co.za>
Message-ID: <1302028032.25.0.336544771916.issue11774@psf.upfronthosting.co.za>


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

Yes, that sounds like a bug.

----------

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

From report at bugs.python.org  Tue Apr  5 20:29:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 05 Apr 2011 18:29:36 +0000
Subject: [issue6191] HTMLParser attribute parsing - 2 test cases when it fails
In-Reply-To: <1244101614.1.0.195769853623.issue6191@psf.upfronthosting.co.za>
Message-ID: <1302028176.36.0.50575566617.issue6191@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.2, Python 3.3 -Python 2.6

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

From report at bugs.python.org  Tue Apr  5 20:31:11 2011
From: report at bugs.python.org (Carsten Klein)
Date: Tue, 05 Apr 2011 18:31:11 +0000
Subject: [issue11774] Issue tracker sends notification mails twice...
In-Reply-To: <1302027226.99.0.081276499304.issue11774@psf.upfronthosting.co.za>
Message-ID: <1302028271.75.0.427746751853.issue11774@psf.upfronthosting.co.za>


Changes by Carsten Klein <carsten.klein at axn-software.de>:


----------
nosy:  -carsten.klein at axn-software.de

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

From report at bugs.python.org  Tue Apr  5 20:32:33 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 05 Apr 2011 18:32:33 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <4D9B5516.8090606@egenix.com>
Message-ID: <BANLkTik2QYcwLSNF-zHJn_-_o1VeCdoD6Q@mail.gmail.com>


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

On Tue, Apr 5, 2011 at 1:45 PM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
..
> BTW: A "timestamp" usually refers to the combination of date and
> time. The time.time() return value is "seconds since the Epoch".
> I usually call those values "ticks" (not sure whether it's standard
> term of not, but always writing "seconds since Epoch" wasn't an
> option either ;-)).

In Unix context, the term "timestamp" is usually associated with the
various time values that OS stores with the files.  I think this use
is due to the analogy with physical "received on" timestamps used on
paper documents.  Since it is well-known that Unix filesystems store
time values as seconds since Epoch, it is common to refer to these
values as "Unix timestamps".

See, for example:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/touch.html

----------

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

From report at bugs.python.org  Tue Apr  5 20:32:50 2011
From: report at bugs.python.org (Mark Wiebe)
Date: Tue, 05 Apr 2011 18:32:50 +0000
Subject: [issue11734] Add half-float (16-bit) support to struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1302028370.85.0.0175190902585.issue11734@psf.upfronthosting.co.za>


Mark Wiebe <mwwiebe at gmail.com> added the comment:

Just a few small tweaks.

I think you meant to subtract the second term here:
+    #('>e', b'\x80\x01', -2.0**-25 + 2.0**-35), # Rounds to minimum subnormal

Isn't the "x < 0" part unnecessary? Maybe a comment explaining why the signbit function is used, to preserve -0, would help people who otherwise might think to replace it with "x < 0".
+    if (x < 0 || signbit(x)) {

This is creating a signaling nan. It would be better to create a quiet nan by setting the highest order bit instead of the lowest order bit.
+    else if (isnan(x)) {
+        e = 0x1f;
+        bits = 1;
+    }

Otherwise it looks great to me, good work!

----------

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

From report at bugs.python.org  Tue Apr  5 20:46:41 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 05 Apr 2011 18:46:41 +0000
Subject: [issue11597] Can't get ConfigParser.write to write unicode strings
In-Reply-To: <1300468084.29.0.517380899901.issue11597@psf.upfronthosting.co.za>
Message-ID: <1302029201.86.0.476718895226.issue11597@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

In my opinion we should unfortunately close this with WONTFIX because:

* adding a feature in a point release is not an option
* this may be poorly documented but most of the standard library in 2.x assumes bytestrings (and fails with Unicode strings). Same goes for instance for csv.
* storing encoded data internally enables for direct reading and writing to compatible files
* having Unicode instead requires the possibility to specify an `encoding` parameter to read* and write* methods. I added this parameter in 3.2 exactly for this reason.

So, unless I missed something obvious and there's more discussion, I am closing this issue next week.

----------

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

From report at bugs.python.org  Tue Apr  5 20:51:55 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 05 Apr 2011 18:51:55 +0000
Subject: [issue7311] Bug on regexp of HTMLParser
In-Reply-To: <1258043150.41.0.372876851796.issue7311@psf.upfronthosting.co.za>
Message-ID: <1302029515.95.0.81455137429.issue7311@psf.upfronthosting.co.za>


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

With 3.2 the situation is more complicated because there is a strict and a non-strict mode.
The strict mode uses:
attrfind = re.compile(
    r'\s*([a-zA-Z_][-.:a-zA-Z_0-9]*)(\s*=\s*'
    r'(\'[^\']*\'|"[^"]*"|[-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~@]*))?')

and the tolerant mode uses:
attrfind_tolerant = re.compile(
    r'\s*([a-zA-Z_][-.:a-zA-Z_0-9]*)(\s*=\s*'
    r'(\'[^\']*\'|"[^"]*"|[^>\s]*))?')

This means that the strict mode doesn't allow valid non-ASCII chars, and that tolerant mode is a little too permissive.

The attached patch changes the strict regex to be more permissive and leaves the tolerant regex unchanged. The difference between the two are now so small that the tolerant version could be removed, except that re.search is used instead of re.match when the tolerant regex is used.

----------
nosy: +r.david.murray
Added file: http://bugs.python.org/file21545/issue7311-3.diff

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

From report at bugs.python.org  Tue Apr  5 20:57:11 2011
From: report at bugs.python.org (Ram Rachum)
Date: Tue, 05 Apr 2011 18:57:11 +0000
Subject: [issue11775] `bool(Counter({'a': 0'})) is True`
In-Reply-To: <1302029831.74.0.558006617631.issue11775@psf.upfronthosting.co.za>
Message-ID: <1302029831.74.0.558006617631.issue11775@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

bool(Counter({'a': 0'})) is True.

Is this wise? I want to be able to do:

    if my_counter:
        whatever

To check whether my counter has any elements. Currently this seems to be impossible because of this bug.

Will we have to keep this weird behavior because of backwards compatibility? If so, perhaps `.elements` could be turned into a smart object so we could at least do `if my_counter.elements():` and get the expected result.

If you want a patch let me know and I'll write one.

----------
components: Library (Lib)
messages: 133076
nosy: cool-RR
priority: normal
severity: normal
status: open
title: `bool(Counter({'a': 0'})) is True`
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr  5 20:57:54 2011
From: report at bugs.python.org (Ram Rachum)
Date: Tue, 05 Apr 2011 18:57:54 +0000
Subject: [issue11775] `bool(Counter({'a': 0})) is True`
In-Reply-To: <1302029831.74.0.558006617631.issue11775@psf.upfronthosting.co.za>
Message-ID: <1302029874.64.0.347772256852.issue11775@psf.upfronthosting.co.za>


Changes by Ram Rachum <cool-rr at cool-rr.com>:


----------
title: `bool(Counter({'a': 0'})) is True` -> `bool(Counter({'a': 0})) is True`

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

From report at bugs.python.org  Tue Apr  5 20:58:50 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 05 Apr 2011 18:58:50 +0000
Subject: [issue11775] `bool(Counter({'a': 0})) is True`
In-Reply-To: <1302029831.74.0.558006617631.issue11775@psf.upfronthosting.co.za>
Message-ID: <1302029930.41.0.720366154668.issue11775@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti, rhettinger
stage:  -> test needed
type:  -> behavior

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

From report at bugs.python.org  Tue Apr  5 21:01:13 2011
From: report at bugs.python.org (Ram Rachum)
Date: Tue, 05 Apr 2011 19:01:13 +0000
Subject: [issue11775] `bool(Counter({'a': 0})) is True`
In-Reply-To: <1302029831.74.0.558006617631.issue11775@psf.upfronthosting.co.za>
Message-ID: <1302030073.31.0.90491771511.issue11775@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

Before coding a test I want to know whether we can even make this change with regards to backwards compatibility.

----------

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

From report at bugs.python.org  Tue Apr  5 21:03:27 2011
From: report at bugs.python.org (Eli Stevens)
Date: Tue, 05 Apr 2011 19:03:27 +0000
Subject: [issue11734] Add half-float (16-bit) support to struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1302030207.06.0.335915957734.issue11734@psf.upfronthosting.co.za>


Eli Stevens <wickedgrey at gmail.com> added the comment:

Updated patch with changes suggested by Mark Wiebe.  I also removed the commented-out "if (!(e == 0 && f == 0.0))" part.

It feels like the patch is approaching an acceptable state; after both of you agree it's there, what do I need to do next?

----------

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

From report at bugs.python.org  Tue Apr  5 21:13:44 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 05 Apr 2011 19:13:44 +0000
Subject: [issue11775] `bool(Counter({'a': 0})) is True`
In-Reply-To: <1302029831.74.0.558006617631.issue11775@psf.upfronthosting.co.za>
Message-ID: <1302030824.44.0.228727550712.issue11775@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

It depends on what kind of object it's like. If it's like a dict then your example is clearly not empty, but if it's like a set then it /is/ empty, in which case it's empty if:

    all(count == 0 for count in my_counter.values())

----------
nosy: +mrabarnett

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

From report at bugs.python.org  Tue Apr  5 21:25:07 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 Apr 2011 19:25:07 +0000
Subject: [issue11597] Can't get ConfigParser.write to write unicode strings
In-Reply-To: <1300468084.29.0.517380899901.issue11597@psf.upfronthosting.co.za>
Message-ID: <1302031507.68.0.740846693626.issue11597@psf.upfronthosting.co.za>


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

No, the need for an encoding parameter for read/write makes it unambiguous that it is indeed a feature.

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Tue Apr  5 21:27:13 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 05 Apr 2011 19:27:13 +0000
Subject: [issue11775] `bool(Counter({'a': 0})) is True`
In-Reply-To: <1302029831.74.0.558006617631.issue11775@psf.upfronthosting.co.za>
Message-ID: <1302031633.86.0.520119411758.issue11775@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Sorry, this is at odds with how Guido wants bool to work with containers.  The bool check is all about whether or not a container is empty, not about its contents.

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

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

From report at bugs.python.org  Tue Apr  5 21:30:45 2011
From: report at bugs.python.org (Ram Rachum)
Date: Tue, 05 Apr 2011 19:30:45 +0000
Subject: [issue11775] `bool(Counter({'a': 0})) is True`
In-Reply-To: <1302029831.74.0.558006617631.issue11775@psf.upfronthosting.co.za>
Message-ID: <1302031845.59.0.158544915097.issue11775@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

Hmm... So how about making `elements` a smart object which will implement `__bool__`? Then we could give it a `__len__` too and be rid of issue11733.

----------

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

From report at bugs.python.org  Tue Apr  5 21:38:50 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 Apr 2011 19:38:50 +0000
Subject: [issue7311] Bug on regexp of HTMLParser
In-Reply-To: <1258043150.41.0.372876851796.issue7311@psf.upfronthosting.co.za>
Message-ID: <1302032330.54.0.553284996516.issue7311@psf.upfronthosting.co.za>


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

The goal of tolerant mode is to accept anything a typical browser would accept.  I suspect that means the tolerant regex should stay, but I don't remember the details.

As for the strict....as far as I know the current module follows 4.01, not 5.  I'm not sure what should be done about that.

----------
nosy: +orsenthil

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

From report at bugs.python.org  Tue Apr  5 22:35:22 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 Apr 2011 20:35:22 +0000
Subject: [issue11605] EMail generator.flatten() disintegrates over non-ascii
	multipart/alternative
In-Reply-To: <1300532156.44.0.386489107075.issue11605@psf.upfronthosting.co.za>
Message-ID: <1302035722.36.0.885914978897.issue11605@psf.upfronthosting.co.za>


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

Here is a patch against 3.2, with test.  Simple fix, but it took me a while to track down the critical piece of code.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file21546/parse_8bit_multipart.patch

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

From report at bugs.python.org  Tue Apr  5 22:38:54 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Tue, 05 Apr 2011 20:38:54 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1302035934.0.0.772316318672.issue11707@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I have a follow-up question: why keyobject_type needed traverse function? From what I read in docs I assumed it is required for GC tracked types. Why was it required here and how it is used?

----------

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

From report at bugs.python.org  Tue Apr  5 22:44:18 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 05 Apr 2011 20:44:18 +0000
Subject: [issue11775] `bool(Counter({'a': 0})) is True`
In-Reply-To: <1302029831.74.0.558006617631.issue11775@psf.upfronthosting.co.za>
Message-ID: <1302036258.96.0.235241641815.issue11775@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

We could do that, but that's not the Python way :-)

Really, you should be posting recipes somewhere else to see if there is interest and uptake.  The tracker is not the right place to toss one random idea after another.

We need to place some value on API simplicity.  At its core, a Counter is just a dict with an __missing__ method to supply implied zeros.  Much of its ease of use, speed, and flexibility all derive from that basic design.  For the most part, the best thing that could happen to this API is to become stable and remain completely untouched.  I only added subtract() in Py3.2 because there was substantial demand for it; otherwise, all the other ideas for expansion were rejected.

----------

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

From report at bugs.python.org  Tue Apr  5 22:46:45 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 05 Apr 2011 20:46:45 +0000
Subject: [issue11670] configparser read_file now iterates over f,
	docs still say it calls readline
In-Reply-To: <1301047699.5.0.476245530251.issue11670@psf.upfronthosting.co.za>
Message-ID: <1302036405.94.0.382557737015.issue11670@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

How about this? (available for review: http://codereview.appspot.com/4358054)

----------
keywords: +patch
Added file: http://bugs.python.org/file21547/issue11670.patch

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

From report at bugs.python.org  Tue Apr  5 22:47:13 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 05 Apr 2011 20:47:13 +0000
Subject: [issue11733] Implement a `Counter.elements_count` method
In-Reply-To: <1301607638.51.0.474843371118.issue11733@psf.upfronthosting.co.za>
Message-ID: <1302036433.17.0.883902681033.issue11733@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

After more thought, I've decided to close this feature request.  The operation is utterly trivial and isn't worth fattening the API.  I see no advantage in `c.total_count()` versus `sum(c.values())`.

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Tue Apr  5 22:53:25 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 05 Apr 2011 20:53:25 +0000
Subject: [issue11776] types.MethodType() params and usage is not documented
In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za>
Message-ID: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za>


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

types.MethodType(function, instance) is used as a replacement for new.instancemethod(function, instance, class), but this usage is not documented.

----------
assignee: docs at python
components: Documentation
messages: 133089
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: types.MethodType() params and usage is not documented
versions: Python 3.2

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

From report at bugs.python.org  Tue Apr  5 22:55:41 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 05 Apr 2011 20:55:41 +0000
Subject: [issue11776] types.MethodType() params and usage is not documented
In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za>
Message-ID: <1302036941.85.0.501409783271.issue11776@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
stage:  -> needs patch
type:  -> behavior

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

From report at bugs.python.org  Tue Apr  5 22:59:57 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 05 Apr 2011 20:59:57 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1302037197.52.0.739009338562.issue11707@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> why keyobject_type needed traverse function?

I used to know this but don't any more.  It might not be necessary.  Most of the types I write all use GC so it may just be habit.

----------

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

From report at bugs.python.org  Tue Apr  5 23:03:13 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 05 Apr 2011 21:03:13 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1302037393.91.0.707967445638.issue11707@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Georg, do you care to opine on whether this should go into 3.2.1?  (I don't have any preference).

There is a big thread on comp.lang.python where a number of people seem to be very concerned about the efficiency of cmp_to_key().  OTOH, we almost never backport performance patches unless the speed is so slow as to be unusable.

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

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

From report at bugs.python.org  Tue Apr  5 23:06:13 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Tue, 05 Apr 2011 21:06:13 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1302037573.82.0.695168633977.issue11707@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I see. Thanks :-)

----------

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

From report at bugs.python.org  Tue Apr  5 23:17:00 2011
From: report at bugs.python.org (Ram Rachum)
Date: Tue, 05 Apr 2011 21:17:00 +0000
Subject: [issue11775] `bool(Counter({'a': 0})) is True`
In-Reply-To: <1302029831.74.0.558006617631.issue11775@psf.upfronthosting.co.za>
Message-ID: <1302038220.94.0.68381105879.issue11775@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

How is it "not the Python way"? Why is it okay to make `dict.keys` into a smart object but it's not okay to make `Counter.elements` a smart object?

These are not random ideas. I'm using `Counter` in a contract project and I find the need to make `if counter:` checks.

I'll ask on Python-ideas to get people's opinions.

----------

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

From report at bugs.python.org  Tue Apr  5 23:39:40 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 05 Apr 2011 21:39:40 +0000
Subject: [issue6040] bdist_msi does not deal with pre-release version
In-Reply-To: <1242472106.67.0.523299229524.issue6040@psf.upfronthosting.co.za>
Message-ID: <1302039580.52.0.258371864759.issue6040@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

All right. The ultimate solution:

{{{
# Imports for converting version to MSI format for bdist_msi
from distutils.command.bdist_msi import bdist_msi
import inspect
import types
 
...

class bdist_msi_patch_version(bdist_msi):
    """ MSI builder requires version to be in the x.x.x format """
    def run(self):
        def monkey_get_version(self):
            """ monkey patch replacement for metadata.get_version() that
                returns MSI compatible version string for bdist_msi
            """
            # get filename of the calling function
            if inspect.stack()[1][1].endswith('bdist_msi.py'):
                # strip revision from version (if any), e.g. 11.0.0-r31546
                return self.version.split('-')[0]
            else:
                return self.version

        # monkeypatching get_version() call for DistributionMetadata
        self.distribution.metadata.get_version = \
            types.MethodType(monkey_get_version, self.distribution.metadata)
        bdist_msi.run(self)


...
setup(
    ...
    cmdclass={'bdist_msi': bdist_msi_version_hack},
)
}}}

----------

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

From report at bugs.python.org  Wed Apr  6 00:33:19 2011
From: report at bugs.python.org (Viktor Ferenczi)
Date: Tue, 05 Apr 2011 22:33:19 +0000
Subject: [issue11665] Regexp findall freezes
In-Reply-To: <1301005743.88.0.293616308721.issue11665@psf.upfronthosting.co.za>
Message-ID: <1302042799.77.0.270360397582.issue11665@psf.upfronthosting.co.za>


Viktor Ferenczi <python at cx.hu> added the comment:

I found this ugly regexp in old code and optimized this, certainly. I'll need to search for more of this in the code to make sure it won't freeze next time.

I think you can close this ticket, since it is only another way to write an infinite loop in Python, not a real bug.

----------

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

From report at bugs.python.org  Wed Apr  6 00:37:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 05 Apr 2011 22:37:11 +0000
Subject: [issue7311] Bug on regexp of HTMLParser
In-Reply-To: <1258043150.41.0.372876851796.issue7311@psf.upfronthosting.co.za>
Message-ID: <1302043031.89.0.372758902315.issue7311@psf.upfronthosting.co.za>


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

I don't see many use cases for the strict mode.  It is not strict enough to be used for validation, and while parsing HTML I can't think of any other case where I would want an exception raised (always as long as what is parsed by the tolerant mode is a superset of what is parsed by the strict mode).

If the parser is still able to parse what it was parsing before, I wouldn't worry too much about backward compatibility, because I can't imagine a valid use case where people would want the parser to fail (maybe someone else can?).

----------
stage: test needed -> commit review

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

From report at bugs.python.org  Wed Apr  6 00:55:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Apr 2011 22:55:08 +0000
Subject: [issue11665] Regexp findall freezes
In-Reply-To: <1301005743.88.0.293616308721.issue11665@psf.upfronthosting.co.za>
Message-ID: <1302044108.16.0.0367184541843.issue11665@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ok.

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

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

From report at bugs.python.org  Wed Apr  6 01:39:10 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 05 Apr 2011 23:39:10 +0000
Subject: [issue11775] `bool(Counter({'a': 0})) is True`
In-Reply-To: <1302029831.74.0.558006617631.issue11775@psf.upfronthosting.co.za>
Message-ID: <1302046750.93.0.132123531409.issue11775@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> How is it "not the Python way"? 

Because having an API within an API greatly complexifies the interface, making harder to implement, harder to understand, and harder to learn.

> Why is it okay to make `dict.keys` into a smart object
> but it's not okay to make `Counter.elements` a smart object?

That was the exception, not the rule.  For the most part,
we don't do multi-level APIs unless there is a *compelling*
reason.  In the case of dict views, there was already a
known successful model in Java using this API and Guido
liked it.  Subsequent experience in teaching Python shows
that people have a hard time grasping it as first.

----------

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

From report at bugs.python.org  Wed Apr  6 02:20:09 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 06 Apr 2011 00:20:09 +0000
Subject: [issue7108] test_commands.py failing on OS X 10.5.7 due to '@' in ls
	output
In-Reply-To: <1255304015.86.0.913588485284.issue7108@psf.upfronthosting.co.za>
Message-ID: <E1Q7GTd-0007Ax-Lz@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 5616cbce0bee by Ned Deily in branch '2.7':
Issue #7108: Fix test_commands to not fail when special attributes ('@'
http://hg.python.org/cpython/rev/5616cbce0bee

----------
nosy: +python-dev

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

From report at bugs.python.org  Wed Apr  6 02:23:23 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 06 Apr 2011 00:23:23 +0000
Subject: [issue7108] test_commands.py failing on OS X 10.5.7 due to '@' in ls
	output
In-Reply-To: <1255304015.86.0.913588485284.issue7108@psf.upfronthosting.co.za>
Message-ID: <1302049403.07.0.891810648186.issue7108@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for the suggested patch and extension to the SELinux case. (Note that getstatus is deprecated and removed in Python 3 so this patch only applies to 2.7.)

----------
assignee:  -> ned.deily
components:  -Macintosh
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Apr  6 02:35:12 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Apr 2011 00:35:12 +0000
Subject: [issue11492] email.header.Header doesn't fold headers
In-Reply-To: <1300087978.39.0.703069545984.issue11492@psf.upfronthosting.co.za>
Message-ID: <1302050112.96.0.46530234974.issue11492@psf.upfronthosting.co.za>


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

Ah, it isn't broken, it's just that the default changed.  In 2.x, the default was maxlinelen=78, in 3.x, the default is maxlinelen=None (unlimited), but generator passes in an override of 78 when formatting output.  So you can specify an explicit maxlinelen=78 and that will wrap the headers in both 2.x and 3.x.  (There are differences in the wrapping algorithms, though!)

----------
resolution:  -> invalid
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Apr  6 02:42:18 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 06 Apr 2011 00:42:18 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1302050538.62.0.0100209875742.issue4111@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Some more references:

Read the notes under the slides:
https://dgl.cx/2011/01/dtrace-and-perl

https://dgl.cx/dtrace

http://dtrace.org/blogs/

What do we need to unblock this?

----------

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

From report at bugs.python.org  Wed Apr  6 02:44:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 06 Apr 2011 00:44:02 +0000
Subject: [issue11576] timedelta subtraction glitch on big timedelta values
In-Reply-To: <1300300374.42.0.323592740228.issue11576@psf.upfronthosting.co.za>
Message-ID: <E1Q7Gqm-0000PX-Br@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 76180cc853b6 by Alexander Belopolsky in branch '3.2':
Issue #11576: Fixed timedelta subtraction glitch on big timedelta values
http://hg.python.org/cpython/rev/76180cc853b6

New changeset d492915cf76d by Alexander Belopolsky in branch 'default':
Issue #11576: Fixed timedelta subtraction glitch on big timedelta values
http://hg.python.org/cpython/rev/d492915cf76d

----------
nosy: +python-dev

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

From report at bugs.python.org  Wed Apr  6 03:16:35 2011
From: report at bugs.python.org (Brian Quinlan)
Date: Wed, 06 Apr 2011 01:16:35 +0000
Subject: [issue11777] Executor.map does not submit futures until iter.next()
	is called
In-Reply-To: <1302052595.78.0.918161508373.issue11777@psf.upfronthosting.co.za>
Message-ID: <1302052595.78.0.918161508373.issue11777@psf.upfronthosting.co.za>


New submission from Brian Quinlan <brian at sweetapp.com>:

from concurrent import futures

with futures.ThreadPoolExecutor(max_workers=5) as e:
  e.map(print, range(10))

# No output

----------
assignee: bquinlan
components: Library (Lib)
messages: 133104
nosy: bquinlan
priority: normal
severity: normal
status: open
title: Executor.map does not submit futures until iter.next() is called
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr  6 04:14:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 06 Apr 2011 02:14:30 +0000
Subject: [issue11576] timedelta subtraction glitch on big timedelta values
In-Reply-To: <1300300374.42.0.323592740228.issue11576@psf.upfronthosting.co.za>
Message-ID: <E1Q7IGJ-0006EK-6p@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 202a9feb1fd6 by Alexander Belopolsky in branch '2.7':
Issue #11576: Fixed timedelta subtraction glitch on big timedelta values
http://hg.python.org/cpython/rev/202a9feb1fd6

----------

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

From report at bugs.python.org  Wed Apr  6 04:16:58 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 06 Apr 2011 02:16:58 +0000
Subject: [issue11576] timedelta subtraction glitch on big timedelta values
In-Reply-To: <1300300374.42.0.323592740228.issue11576@psf.upfronthosting.co.za>
Message-ID: <1302056218.71.0.809890541852.issue11576@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
components: +Extension Modules
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 2.5, Python 2.6, Python 3.1

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

From report at bugs.python.org  Wed Apr  6 05:03:40 2011
From: report at bugs.python.org (Denver Coneybeare)
Date: Wed, 06 Apr 2011 03:03:40 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1302059020.61.0.836796655409.issue3905@psf.upfronthosting.co.za>


Denver Coneybeare <denver.coneybeare at gmail.com> added the comment:

Ahh okay.  I've reproduced it in trunk at changeset 053bc5ca199b.

As suggested, I ran: PCBuild\pythonw.exe lib\idlelib\idle.py

Python 3.3a0 (default, Apr  2 2011, 21:55:40) [MSC v.1500 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> import subprocess
>>> subprocess.Popen(["python", "-c", "print(32)"], stdin=None, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    subprocess.Popen(["python", "-c", "print(32)"], stdin=None, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
  File "C:\dev\cpython\cpython\lib\subprocess.py", line 732, in __init__
    errread, errwrite) = self._get_handles(stdin, stdout, stderr)
  File "C:\dev\cpython\cpython\lib\subprocess.py", line 903, in _get_handles
    p2cread = self._make_inheritable(p2cread)
  File "C:\dev\cpython\cpython\lib\subprocess.py", line 946, in _make_inheritable
    _subprocess.DUPLICATE_SAME_ACCESS)
WindowsError: [Error 6] The handle is invalid
>>> 

So, the issue is definitely not fixed.

----------

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

From report at bugs.python.org  Wed Apr  6 06:21:35 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 06 Apr 2011 04:21:35 +0000
Subject: [issue9390] Error in sys.excepthook on windows when redirecting
	output of the script
In-Reply-To: <1280235089.13.0.870066677678.issue9390@psf.upfronthosting.co.za>
Message-ID: <1302063695.63.0.679181316229.issue9390@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/issue9390>
_______________________________________

From report at bugs.python.org  Wed Apr  6 07:17:15 2011
From: report at bugs.python.org (ysj.ray)
Date: Wed, 06 Apr 2011 05:17:15 +0000
Subject: [issue11777] Executor.map does not submit futures until iter.next()
	is called
In-Reply-To: <1302052595.78.0.918161508373.issue11777@psf.upfronthosting.co.za>
Message-ID: <1302067035.21.0.214500489543.issue11777@psf.upfronthosting.co.za>


ysj.ray <ysj.ray at gmail.com> added the comment:

Isn't this the supposed behavior?

----------
nosy: +ysj.ray

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

From report at bugs.python.org  Wed Apr  6 08:12:37 2011
From: report at bugs.python.org (Brian Quinlan)
Date: Wed, 06 Apr 2011 06:12:37 +0000
Subject: [issue11777] Executor.map does not submit futures until iter.next()
	is called
In-Reply-To: <1302052595.78.0.918161508373.issue11777@psf.upfronthosting.co.za>
Message-ID: <1302070357.7.0.904627410899.issue11777@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

I think that it surprising behavior, especially considering that asking for the *first* element in the iterator causes *all* of the futures to be created.

----------

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

From report at bugs.python.org  Wed Apr  6 08:16:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 06 Apr 2011 06:16:36 +0000
Subject: [issue10762] strftime('%f') segfault
In-Reply-To: <1293098262.29.0.661167233963.issue10762@psf.upfronthosting.co.za>
Message-ID: <E1Q7M2c-0006H4-BG@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 2ca1bc677a60 by Senthil Kumaran in branch '3.1':
Issue #10762: Guard against invalid/non-supported format string '%f' on Windows. Patch Santoso Wijaya.
http://hg.python.org/cpython/rev/2ca1bc677a60

----------
nosy: +python-dev

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

From report at bugs.python.org  Wed Apr  6 08:33:01 2011
From: report at bugs.python.org (xBrawny)
Date: Wed, 06 Apr 2011 06:33:01 +0000
Subject: [issue11778] __subclasscheck__ : class P(M): __metaclass__=M causes
	maximum recursion depth exceeded.
In-Reply-To: <1302071581.19.0.711337712085.issue11778@psf.upfronthosting.co.za>
Message-ID: <1302071581.19.0.711337712085.issue11778@psf.upfronthosting.co.za>


New submission from xBrawny <andrei at newthot.com>:

I wonder if this is the desired behavior. According to docs, __instancecheck__ should be called,  but it never gets to it. If "return True" is replaced with "raise Exception" the result is the same.
=========================================
class M(type):
    def __instancecheck__(cls,obj):
        return True
    
class P(M):
    __metaclass__=M

isinstance(object,P)
========================================
    isinstance(object,P)
RuntimeError: maximum recursion depth exceeded while calling a Python object

----------
components: Interpreter Core
messages: 133110
nosy: xBrawny
priority: normal
severity: normal
status: open
title: __subclasscheck__ :  class P(M): __metaclass__=M causes maximum recursion depth exceeded.
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Apr  6 08:42:02 2011
From: report at bugs.python.org (the_isz)
Date: Wed, 06 Apr 2011 06:42:02 +0000
Subject: [issue11597] Can't get ConfigParser.write to write unicode strings
In-Reply-To: <1300468084.29.0.517380899901.issue11597@psf.upfronthosting.co.za>
Message-ID: <1302072122.84.0.832179258159.issue11597@psf.upfronthosting.co.za>


the_isz <the_isz at gmx.de> added the comment:

Well, the only thing I can add to this is that the json module (which I ended up
using) supports unicode with no problem. So I think the argument that most of
the standard library in 2.x assumes bytestrings is a bit... shaky.

Other than that, I can follow your reasoning and will just hope that all my
needed external libraries will soon make it to python 3 so I don't have to fight
such inconsistencies anymore :)

----------

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

From report at bugs.python.org  Wed Apr  6 08:45:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 06 Apr 2011 06:45:36 +0000
Subject: [issue10762] strftime('%f') segfault
In-Reply-To: <1293098262.29.0.661167233963.issue10762@psf.upfronthosting.co.za>
Message-ID: <E1Q7MUf-0008Jc-1Y@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 1320f29bcf98 by Senthil Kumaran in branch '2.7':
Issue #10762: Guard against invalid/non-supported format string '%f' on Windows. Patch Santoso Wijaya.
http://hg.python.org/cpython/rev/1320f29bcf98

----------

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

From report at bugs.python.org  Wed Apr  6 08:48:11 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 06 Apr 2011 06:48:11 +0000
Subject: [issue10762] strftime('%f') segfault
In-Reply-To: <1293098262.29.0.661167233963.issue10762@psf.upfronthosting.co.za>
Message-ID: <1302072491.47.0.634485402567.issue10762@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed it in relevant branches. I had to add condition around the test to verify that platform was win because this is unique to windows only. Thanks.

----------
nosy: +orsenthil

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

From report at bugs.python.org  Wed Apr  6 08:51:52 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 06 Apr 2011 06:51:52 +0000
Subject: [issue10762] strftime('%f') segfault
In-Reply-To: <1293098262.29.0.661167233963.issue10762@psf.upfronthosting.co.za>
Message-ID: <1302072712.79.0.408330714702.issue10762@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Apr  6 09:07:11 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 06 Apr 2011 07:07:11 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1302050538.62.0.0100209875742.issue4111@psf.upfronthosting.co.za>
Message-ID: <BANLkTimXJ-bucu99cV+VWZM64tpKjM4MZg@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

2011/4/6 Jes?s Cea Avi?n <report at bugs.python.org>:
>
> Jes?s Cea Avi?n <jcea at jcea.es> added the comment:
>
> Some more references:
>
> Read the notes under the slides:
> https://dgl.cx/2011/01/dtrace-and-perl
>
> https://dgl.cx/dtrace
>
> http://dtrace.org/blogs/
>
> What do we need to unblock this?

Summarize 30+ page discussion in a new issue.
Blog about it on http://blog.python.org/
--
anatoly t.

----------

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

From report at bugs.python.org  Wed Apr  6 09:59:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Apr 2011 07:59:22 +0000
Subject: [issue11779] test_mmap timeout (30 min) on "AMD64 Snow Leopard 3.x"
	buildbot
In-Reply-To: <1302076762.26.0.815715887004.issue11779@psf.upfronthosting.co.za>
Message-ID: <1302076762.26.0.815715887004.issue11779@psf.upfronthosting.co.za>


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

The creation of a file of 5.25 GB took more than 30 min on "AMD64 Snow Leopard 3.x" buildbot, and so regrtest exited:
-----------------
[ 27/354] test_mmap
Thread 0x00007fff70439ca0:
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/test_mmap.py", line 685 in test_large_offset
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/case.py", line 442 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/case.py", line 494 in __call__
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/support.py", line 1078 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/support.py", line 1166 in _run_suite
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/support.py", line 1192 in run_unittest
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/test_mmap.py", line 706 in test_main
  File "./Lib/test/regrtest.py", line 1032 in runtest_inner
  File "./Lib/test/regrtest.py", line 826 in runtest
  File "./Lib/test/regrtest.py", line 650 in main
  File "./Lib/test/regrtest.py", line 1607 in <module>
make: *** [buildbottest] Error 1
program finished with exit code 2
elapsedTime=1909.711111
-----------------
http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%203.x/builds/46/steps/test/logs/stdio

----------
components: Tests
messages: 133115
nosy: haypo
priority: normal
severity: normal
status: open
title: test_mmap timeout (30 min) on "AMD64 Snow Leopard 3.x" buildbot
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr  6 10:02:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Apr 2011 08:02:50 +0000
Subject: [issue11779] test_mmap timeout (30 min) on "AMD64 Snow Leopard 3.x"
	buildbot
In-Reply-To: <1302076762.26.0.815715887004.issue11779@psf.upfronthosting.co.za>
Message-ID: <1302076970.85.0.331848100314.issue11779@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The test step was interrupted after "38 mins, 45 secs" (including 30 min of timeout) at the test 27, whereas the previous (success) test step took "46 mins, 55 secs" to execute all (354) tests.

----------
nosy: +ixokai

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

From report at bugs.python.org  Wed Apr  6 10:53:51 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 06 Apr 2011 08:53:51 +0000
Subject: [issue11597] Can't get ConfigParser.write to write unicode strings
In-Reply-To: <1300468084.29.0.517380899901.issue11597@psf.upfronthosting.co.za>
Message-ID: <1302080031.96.0.68902529673.issue11597@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

As another core dev aptly said, most standard library Unicode support is probably accidental. As for `json`, this is one of the "newest" additions to stdlib, introduced in Python 2.6 (released at the same time as Python 3.0). Not the best example if you compare it to libraries that were added in 1.5 or so.

----------

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

From report at bugs.python.org  Wed Apr  6 11:36:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Apr 2011 09:36:09 +0000
Subject: [issue11597] Can't get ConfigParser.write to write unicode strings
In-Reply-To: <1300468084.29.0.517380899901.issue11597@psf.upfronthosting.co.za>
Message-ID: <1302082569.99.0.280991081785.issue11597@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I think it is more a question of "is this an easy fix?" 
> or would it require extensive changes to support unicode properly.

First of all, the question is: who would like to develop it. You can vote for an issue, but it doesn't change anything if you don't find a developer to implement your idea :-)

Anyway, try to use Python everywhere in Python 2 is a waste of time. The work has already been done in Python 3, and it's much easier to use Unicode in Python 3, just because everything uses Unicode (exceptions, filenames, file content, modules, etc.).

----------
nosy: +haypo

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

From report at bugs.python.org  Wed Apr  6 13:00:33 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 06 Apr 2011 11:00:33 +0000
Subject: [issue11605] EMail generator.flatten() disintegrates over non-ascii
	multipart/alternative
In-Reply-To: <1302035722.36.0.885914978897.issue11605@psf.upfronthosting.co.za>
Message-ID: <20110406110023.GA62408@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

On Tue, Apr 05, 2011 at 08:35:22PM +0000, R. David Murray wrote:
> Simple fix, but it took me a while to track down the critical piece of code.

I've really tried to break it, but i can't.

----------

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

From report at bugs.python.org  Wed Apr  6 13:04:58 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 06 Apr 2011 11:04:58 +0000
Subject: [issue11780] email.encoders are broken
In-Reply-To: <1302087898.67.0.0241600221025.issue11780@psf.upfronthosting.co.za>
Message-ID: <1302087898.67.0.0241600221025.issue11780@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

This is what one gets if using a BytesParser() generated message:


encoders.encode_7or8bit(msg)
AttributeError: 'list' object has no attribute 'decode'

encoders.encode_base64(msg)
TypeError: expected bytes, not list

encoders.encode_quopri(msg)
TypeError: 'list' does not support the buffer interface


I'll attach a diff against 3.3 test_email.py which adds stupid
tests (there is really no assertNoRaises()).
Maybe they should also be extended so that it is actually tested
wether the generated content is also correct.

----------
components: Library (Lib)
files: test_email.1.diff
keywords: patch
messages: 133120
nosy: sdaoden
priority: normal
severity: normal
status: open
title: email.encoders are broken
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21548/test_email.1.diff

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

From report at bugs.python.org  Wed Apr  6 13:28:59 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Apr 2011 11:28:59 +0000
Subject: [issue11780] email.encoders are broken
In-Reply-To: <1302087898.67.0.0241600221025.issue11780@psf.upfronthosting.co.za>
Message-ID: <1302089339.86.0.301710570221.issue11780@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


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

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

From report at bugs.python.org  Wed Apr  6 14:00:12 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 06 Apr 2011 12:00:12 +0000
Subject: [issue11781] test/test_email directory does not get installed by
	'make install'
Message-ID: <1302091212.24.0.8958212578.issue11781@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


----------
components: Installation
nosy: r.david.murray, sdaoden
priority: normal
severity: normal
status: open
title: test/test_email directory does not get installed by 'make install'
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr  6 14:16:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 06 Apr 2011 12:16:43 +0000
Subject: [issue11605] EMail generator.flatten() disintegrates over non-ascii
	multipart/alternative
In-Reply-To: <1300532156.44.0.386489107075.issue11605@psf.upfronthosting.co.za>
Message-ID: <E1Q7Rf7-0002qk-FT@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset b807cf929e26 by R David Murray in branch '3.2':
#11605: don't use set/get_payload in feedparser; they do conversions.
http://hg.python.org/cpython/rev/b807cf929e26

New changeset 642c0d6799c5 by R David Murray in branch 'default':
Merge #11605: don't use set/get_payload in feedparser; they do conversions.
http://hg.python.org/cpython/rev/642c0d6799c5

----------
nosy: +python-dev

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

From report at bugs.python.org  Wed Apr  6 14:17:52 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Apr 2011 12:17:52 +0000
Subject: [issue11605] EMail generator.flatten() disintegrates over non-ascii
	multipart/alternative
In-Reply-To: <1300532156.44.0.386489107075.issue11605@psf.upfronthosting.co.za>
Message-ID: <1302092272.91.0.779908545922.issue11605@psf.upfronthosting.co.za>


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

Thanks for the testing.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Apr  6 14:30:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Apr 2011 12:30:51 +0000
Subject: [issue11597] Can't get ConfigParser.write to write unicode strings
In-Reply-To: <1302082569.99.0.280991081785.issue11597@psf.upfronthosting.co.za>
Message-ID: <1302093044.2311.0.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Anyway, try to use Python everywhere in Python 2 is a waste of time.

Oh... I mean "use Unicode in Python 2"

----------

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

From report at bugs.python.org  Wed Apr  6 14:42:20 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 06 Apr 2011 12:42:20 +0000
Subject: [issue11280] urllib2 http_error_302 calls undefined "getheaders"
	method
In-Reply-To: <1298341349.41.0.55623221755.issue11280@psf.upfronthosting.co.za>
Message-ID: <1302093740.19.0.436495712912.issue11280@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Just for the explaination (as the report already closed), getheaders of HTTPMessage object is available by subclassing all the way from rfc822.py module. If you trace it through the debugger, you will come to know.

----------

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

From report at bugs.python.org  Wed Apr  6 15:12:51 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 06 Apr 2011 13:12:51 +0000
Subject: [issue8314] test_ctypes fails in test_ulonglong on sparc buildbots
In-Reply-To: <1270469885.55.0.752027246289.issue8314@psf.upfronthosting.co.za>
Message-ID: <1302095571.59.0.421164998914.issue8314@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

There seems to be also a problem with src/sparc/v9.S.
https://bugs.gentoo.org/show_bug.cgi?id=362065

FAIL: test_ulonglong (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/tmp/portage/dev-lang/python-2.7.2_pre20110403/work/python-2.7.2_pre20110403/Lib/ctypes/test/test_callbacks.py", line 72, in test_ulonglong
    self.check_type(c_ulonglong, 10955412242170339782)
  File "/var/tmp/portage/dev-lang/python-2.7.2_pre20110403/work/python-2.7.2_pre20110403/Lib/ctypes/test/test_callbacks.py", line 31, in check_type
    self.assertEqual(result, arg)
AssertionError: 10955412241121898851L != 10955412242170339782L

----------
nosy: +Arfrever
versions: +3rd party -Python 2.7

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

From report at bugs.python.org  Wed Apr  6 15:17:09 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 06 Apr 2011 13:17:09 +0000
Subject: [issue8314] test_ctypes fails in test_ulonglong on sparc buildbots
In-Reply-To: <1270469885.55.0.752027246289.issue8314@psf.upfronthosting.co.za>
Message-ID: <1302095829.21.0.189618221839.issue8314@psf.upfronthosting.co.za>


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


----------
versions: +Python 2.7 -3rd party

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

From report at bugs.python.org  Wed Apr  6 15:24:27 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 06 Apr 2011 13:24:27 +0000
Subject: [issue10977] Concrete object C API needs abstract path for subclasses
	of builtin types
In-Reply-To: <1295653779.62.0.836506069174.issue10977@psf.upfronthosting.co.za>
Message-ID: <1302096267.53.0.491295632503.issue10977@psf.upfronthosting.co.za>


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

"should" is a wonderful word when it comes to external APIs.

We currently have a couple of problems:

1. The concrete APIs will fail noisily if given an instance of something that isn't a list, but may fail *silently* if given a subclass that adds additional state that needs to be kept in sync.

2. We don't have a standard "fast path with fallback" idiom for containers, so any code that wants to support arbitrary sequences has to either accept the performance penalty, or code the fast path at every point it gets used.

Changing the concrete APIs to be more defensive and fall back to the abstract APIs if their assumptions are violated would be a win on both of those fronts.

I also retract my performance concern from above - all of the affected code paths already include a "Py<X>_Check()" that triggers PyErr_BadInternalCall() if it fails. All we would be doing is moving that check further down in the function and dealing with a negative result differently.

Some code paths would become slightly slower when used with subclasses of builtin types, but a lot of currently broken code would automatically start supporting subclasses of builtins correctly (and be well on its way to being duck-typed, instead of only working with the builtin types).

----------

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

From report at bugs.python.org  Wed Apr  6 15:44:43 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 06 Apr 2011 13:44:43 +0000
Subject: [issue11684] Add email.parser.BytesHeaderParser
In-Reply-To: <1301151932.52.0.667036895822.issue11684@psf.upfronthosting.co.za>
Message-ID: <1302097483.26.0.550382426625.issue11684@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

This is a complete thing including tests.
Note that the tests fail due to another error
in generator.py (or wherever the real source is):

    TypeError: 'str' does not support the buffer interface

Please do forget this mortifying first diff.

----------
nosy:  -r.david.murray
title: (Maybe) Add email.parser.BytesHeaderParser -> Add email.parser.BytesHeaderParser
versions: +Python 3.2
Added file: http://bugs.python.org/file21549/11684.1.diff

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

From report at bugs.python.org  Wed Apr  6 15:44:48 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 06 Apr 2011 13:44:48 +0000
Subject: [issue11684] Add email.parser.BytesHeaderParser
In-Reply-To: <1301151932.52.0.667036895822.issue11684@psf.upfronthosting.co.za>
Message-ID: <1302097488.93.0.903062028059.issue11684@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file21409/bytes-header-parser.1.diff

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

From report at bugs.python.org  Wed Apr  6 15:49:45 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 06 Apr 2011 13:49:45 +0000
Subject: [issue11782] email.generator.Generator.flatten() fails
In-Reply-To: <1302097785.46.0.28701143911.issue11782@psf.upfronthosting.co.za>
Message-ID: <1302097785.46.0.28701143911.issue11782@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

This snippet (for #11684, but it's simply BytesParser with
headersonly=True in the end)


        with openfile('msg_46.txt', 'rb') as fp:
            msgdata = fp.read()
        parser = email.parser.BytesHeaderParser()
        msg = parser.parsebytes(msgdata)
        out = BytesIO()
        gen = email.generator.BytesGenerator(out)
        gen.flatten(msg)
        self.assertEqual(out.getvalue(), msgdata)


causes this error:


ERROR: test_byte_message_rfc822_only (test_email.TestMessageAPI)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/steffen/usr/opt/py3k/lib/python3.3/test/test_email/test_email.py", line 200, in test_byte_message_rfc822_only
    gen.flatten(msg)
  File "/Users/steffen/usr/opt/py3k/lib/python3.3/email/generator.py", line 91, in flatten
    self._write(msg)
  File "/Users/steffen/usr/opt/py3k/lib/python3.3/email/generator.py", line 137, in _write
    self._dispatch(msg)
  File "/Users/steffen/usr/opt/py3k/lib/python3.3/email/generator.py", line 163, in _dispatch
    meth(msg)
  File "/Users/steffen/usr/opt/py3k/lib/python3.3/email/generator.py", line 304, in _handle_message
    self._fp.write(payload)
TypeError: 'str' does not support the buffer interface

----------
components: Library (Lib)
messages: 133128
nosy: sdaoden
priority: normal
severity: normal
status: open
title: email.generator.Generator.flatten() fails
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Apr  6 15:52:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 06 Apr 2011 13:52:24 +0000
Subject: [issue1690608] email.utils.formataddr() should be rfc2047 aware
Message-ID: <E1Q7T9i-0003aj-Po@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 184ddd9acd5a by R David Murray in branch 'default':
#1690608: make formataddr RFC2047 aware.
http://hg.python.org/cpython/rev/184ddd9acd5a

----------
nosy: +python-dev

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

From report at bugs.python.org  Wed Apr  6 15:54:54 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Apr 2011 13:54:54 +0000
Subject: [issue11684] Add email.parser.BytesHeaderParser
In-Reply-To: <1301151932.52.0.667036895822.issue11684@psf.upfronthosting.co.za>
Message-ID: <1302098094.94.0.780377461049.issue11684@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


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

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

From report at bugs.python.org  Wed Apr  6 15:55:13 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Apr 2011 13:55:13 +0000
Subject: [issue11782] email.generator.Generator.flatten() fails
In-Reply-To: <1302097785.46.0.28701143911.issue11782@psf.upfronthosting.co.za>
Message-ID: <1302098113.79.0.374901259676.issue11782@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


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

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

From report at bugs.python.org  Wed Apr  6 16:01:34 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 06 Apr 2011 14:01:34 +0000
Subject: [issue10977] Concrete object C API needs abstract path for subclasses
	of builtin types
In-Reply-To: <1302096267.53.0.491295632503.issue10977@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=2MHF0=7e-1+ktjGuz91aND9odVA@mail.gmail.com>


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

2011/4/6 Nick Coghlan <report at bugs.python.org>:
>
> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>
> "should" is a wonderful word when it comes to external APIs.
>
> We currently have a couple of problems:
>
> 1. The concrete APIs will fail noisily if given an instance of something that isn't a list, but may fail *silently* if given a subclass that adds additional state that needs to be kept in sync.
>
> 2. We don't have a standard "fast path with fallback" idiom for containers, so any code that wants to support arbitrary sequences has to either accept the performance penalty, or code the fast path at every point it gets used.
>
> Changing the concrete APIs to be more defensive and fall back to the abstract APIs if their assumptions are violated would be a win on both of those fronts.

Why not add fast paths to the generic functions if that's what you're
concerned about?

It's unexpected for the user of the functions and breaks years of
tradition. What if someone calls PyList_Append on a custom type that
doesn't do as they expect and then PyList_GET_ITEM?

It seems like asking for subtle bugs to me. The only correct way to is
change code that uses these type specific apis to use the generic
ones.

----------

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

From report at bugs.python.org  Wed Apr  6 16:04:38 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Apr 2011 14:04:38 +0000
Subject: [issue1690608] email.utils.formataddr() should be rfc2047 aware
Message-ID: <1302098678.09.0.771369044964.issue1690608@psf.upfronthosting.co.za>


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

Finally got around to committing this; thanks, Torsten.  As a reward, I'm going to make you nosy on a new, related issue I'm about to create.  It is, of course, your option whether you want to work on it :)

By the way, have you submitted a contributor agreement?  This patch isn't really big enough to require one, but having one on file is always a good idea, especially if you are going to keep contributing (and I hope you do).

----------
resolution:  -> accepted
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Apr  6 16:09:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Apr 2011 14:09:49 +0000
Subject: [issue10977] Concrete object C API needs abstract path for subclasses
	of builtin types
In-Reply-To: <BANLkTi=2MHF0=7e-1+ktjGuz91aND9odVA@mail.gmail.com>
Message-ID: <1302098983.3700.8.camel@localhost.localdomain>


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

> Why not add fast paths to the generic functions if that's what you're
> concerned about?
> 
> It's unexpected for the user of the functions and breaks years of
> tradition. What if someone calls PyList_Append on a custom type that
> doesn't do as they expect and then PyList_GET_ITEM?
> 
> It seems like asking for subtle bugs to me. The only correct way to is
> change code that uses these type specific apis to use the generic
> ones.

I agree with Benjamin.
IIRC we already have a bunch of fast paths in abstract.c.

----------

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

From report at bugs.python.org  Wed Apr  6 16:12:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Apr 2011 14:12:01 +0000
Subject: [issue11783] email parseaddr and formataddr should be IDNA aware
In-Reply-To: <1302099121.47.0.140525796896.issue11783@psf.upfronthosting.co.za>
Message-ID: <1302099121.47.0.140525796896.issue11783@psf.upfronthosting.co.za>


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

The patch for issue 1690608 adds support for unicode in the realname field to formataddr.  To complete the currently-workable internationalization of address specs, both parseaddr and formataddr should be made IDNA aware.  It is probably a good idea to do some research on this to double check, but it seems as though recognizing IDNA during parsing and generating it during formatting when the domain contains non-ASCII characters should be both safe and useful.

See also issue 963906, which contains some test cases that could be adapted.

----------
assignee: r.david.murray
components: Library (Lib)
keywords: easy
messages: 133133
nosy: r.david.murray, torsten.becker
priority: normal
severity: normal
stage: needs patch
status: open
title: email parseaddr and formataddr should be IDNA aware
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr  6 16:18:23 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Apr 2011 14:18:23 +0000
Subject: [issue963906] Unicode email address helper
Message-ID: <1302099503.64.0.605999588172.issue963906@psf.upfronthosting.co.za>


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

Issue 1690608 addresses part of this issue, and issue 11783 will address the IDNA part.

>From my point of view those two issues solve this problem from the perspective the email package infrastructure and *current* API.  In the email6 API I do plan to have an address helper class that will make managing addresses more conveniently OO, but that is part of the whole email6 process and I don't feel a need any longer to keep this issue open.  There's no good value for 'resolution' to express the resolution here (I've accepted the idea but not the code), so I used 'remind', since I will be coming back to the idea in a little while.

----------
resolution:  -> remind
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Apr  6 16:31:20 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Apr 2011 14:31:20 +0000
Subject: [issue11781] test/test_email directory does not get installed by
	'make install'
In-Reply-To: <1302100280.39.0.606654358464.issue11781@psf.upfronthosting.co.za>
Message-ID: <1302100280.39.0.606654358464.issue11781@psf.upfronthosting.co.za>


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

Attached is a patch.  I'm not sure that I've done everything that needs to be done on the Windows side, though.  Martin?

----------
keywords: +patch
nosy: +loewis
Added file: http://bugs.python.org/file21550/build_update_for_test_email.patch

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

From report at bugs.python.org  Wed Apr  6 16:31:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 06 Apr 2011 14:31:20 +0000
Subject: [issue7311] Bug on regexp of HTMLParser
In-Reply-To: <1258043150.41.0.372876851796.issue7311@psf.upfronthosting.co.za>
Message-ID: <1302100280.39.0.359448869209.issue7311@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think the stdlib should comply with HTML 4.01, and in the future HTML 5.

(FTR, I don?t think XHTML is useful, and deny that XHTML-compatible HTML exists.  See http://bugs.python.org/issue11567#msg131509 :)

----------

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

From report at bugs.python.org  Wed Apr  6 16:33:35 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Apr 2011 14:33:35 +0000
Subject: [issue11781] test/test_email directory does not get installed by
	'make install'
In-Reply-To: <1302100280.39.0.606654358464.issue11781@psf.upfronthosting.co.za>
Message-ID: <1302100415.85.0.734885967019.issue11781@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> r.david.murray

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

From report at bugs.python.org  Wed Apr  6 16:43:44 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 06 Apr 2011 14:43:44 +0000
Subject: [issue10977] Concrete object C API needs abstract path for subclasses
	of builtin types
In-Reply-To: <1295653779.62.0.836506069174.issue10977@psf.upfronthosting.co.za>
Message-ID: <1302101024.4.0.707613639345.issue10977@psf.upfronthosting.co.za>


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

1. It's an external API. We *don't control* most of the potentially broken code, so saying "just fix the call sites" effectively solves nothing and leaves classes like OrderedDict at risk of subtle silent corruption whenever they are passed to a 3rd party C extension.

2. The alternate "fix" is to tighten up the Py<X>_Check calls to Py<X>_CheckExact in order to reject subclasses. That would be a huge pain from a backwards compatibility point of view, so it isn't a realistic option.

3. Another alternate "fix" would be to exclude the concrete API from the stable ABI. That was already done for the macro interfaces, but it's too late for the functions - they were included in the stable interface for the 3.2 release.

4. The fact that the macros are irredeemably broken when used without ensuring that the supplied object is exactly the expected type is a very poor excuse for not fixing the function calls. It sounds like "The taillight is busted too, so let's not bother fixing the brakes".

5. There's a reason I put the "fast path" point second - that benefit is just an added bonus that comes from fixing the real design flaw that Raymond pointed out.

All that said, there really is one specific case where fixing this problem could cause a serious backwards compatibility issue: subclasses of builtin types that are *themselves* written in C. In such cases, the method implementations would quite likely use the concrete API to handle the base class state, then do their own thing to handle the rest of the update. Adding an implicit fallback to the concrete API implementations would cause such cases to trigger infinite recursion at the C level.

----------

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

From report at bugs.python.org  Wed Apr  6 16:49:01 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 06 Apr 2011 14:49:01 +0000
Subject: [issue10977] Concrete object C API needs abstract path for subclasses
	of builtin types
In-Reply-To: <1295653779.62.0.836506069174.issue10977@psf.upfronthosting.co.za>
Message-ID: <1302101341.7.0.44041677689.issue10977@psf.upfronthosting.co.za>


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

Having convinced myself that Raymond's original suggestion can't be implemented safely, I have an alternative (arguably even more radical) proposal:

Deprecate the public concrete API functions that modify object state.

Put an underscore in front of them for internal use, have the public versions trigger a deprecation warning (not to be removed until 3.6 or so), provide a C level mechanism to easily make the equivalent of a super() call and advise that everyone switch to the abstract API in order to handle subclasses properly.

----------

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

From report at bugs.python.org  Wed Apr  6 16:52:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Apr 2011 14:52:55 +0000
Subject: [issue10977] Concrete object C API needs abstract path for subclasses
	of builtin types
In-Reply-To: <1302101024.4.0.707613639345.issue10977@psf.upfronthosting.co.za>
Message-ID: <1302101571.3700.14.camel@localhost.localdomain>


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

> 1. It's an external API. We *don't control* most of the potentially
> broken code, so saying "just fix the call sites" effectively solves
> nothing and leaves classes like OrderedDict at risk of subtle silent
> corruption whenever they are passed to a 3rd party C extension.

But since that problem has been existing for ages, we're not in a rush
to fix it either, are we?
After all, people do have to fix their code from time to time (or port
it to Python 3). Using the right APIs for the job is part of that.
Pointing to the abstract alternatives in the documentation for concrete
APIs may help people do so.

In the long term, having a clean CPython API with a proper separation of
concerns is a major benefit.

----------

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

From report at bugs.python.org  Wed Apr  6 16:54:16 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 06 Apr 2011 14:54:16 +0000
Subject: [issue11732] Skip decorator for tests requiring manual intervention
	on Windows
In-Reply-To: <1301604811.48.0.519862680053.issue11732@psf.upfronthosting.co.za>
Message-ID: <1302101656.88.0.209856780813.issue11732@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Disabling and re-enabling is another possibility, and it's probably more likely to help in the long run. Most (all?) Windows machines have error reporting enabled unless you mess with the registry manually, so the only place tests would be run with my first patch would be on build slaves.

I don't currently have a Ubuntu or Fedora machine, but I could look into it. I'll write up a patch that disables/re-enables for Windows and see how it works.

----------

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

From report at bugs.python.org  Wed Apr  6 16:59:37 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 06 Apr 2011 14:59:37 +0000
Subject: [issue10977] Concrete object C API needs abstract path for subclasses
	of builtin types
In-Reply-To: <1295653779.62.0.836506069174.issue10977@psf.upfronthosting.co.za>
Message-ID: <1302101977.27.0.139580416211.issue10977@psf.upfronthosting.co.za>


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

Changing the affected components. Antoine and Benjamin are right, this needs to be handled as a documentation and education problem.

Raymond's suggestion can too easily trigger infinite recursion and mine would block legitimate use cases in 3rd party code.

For heapq, we can just fix it to include the fallbacks to the abstract versions if PyList_CheckExact() fails.

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python

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

From report at bugs.python.org  Wed Apr  6 17:14:52 2011
From: report at bugs.python.org (Patrick Sabin)
Date: Wed, 06 Apr 2011 15:14:52 +0000
Subject: [issue11784] multiprocessing.Process.join: timeout argument doesn't
	specify time unit.
In-Reply-To: <1302102892.38.0.716462659094.issue11784@psf.upfronthosting.co.za>
Message-ID: <1302102892.38.0.716462659094.issue11784@psf.upfronthosting.co.za>


New submission from Patrick Sabin <patricksabin at gmx.at>:

The documentation of multiprocessing.Process.join doesn't tell the user
of which time unit the timeout argument is. It seems to be seconds.

----------
assignee: docs at python
components: Documentation
files: join-timeout-doc-improvement.patch
keywords: patch
messages: 133142
nosy: docs at python, pyfex
priority: normal
severity: normal
status: open
title: multiprocessing.Process.join: timeout argument doesn't specify time unit.
type: behavior
Added file: http://bugs.python.org/file21551/join-timeout-doc-improvement.patch

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

From report at bugs.python.org  Wed Apr  6 17:57:47 2011
From: report at bugs.python.org (ysj.ray)
Date: Wed, 06 Apr 2011 15:57:47 +0000
Subject: [issue11785] email subpackages documentation problems
In-Reply-To: <1302105466.45.0.930997240631.issue11785@psf.upfronthosting.co.za>
Message-ID: <1302105466.45.0.930997240631.issue11785@psf.upfronthosting.co.za>


New submission from ysj.ray <ysj.ray at gmail.com>:

All the module name in the first line of email subpackages' documentation files(Doc/library/email.xxx.rst) are incorrect: all of them are "email" but not "email.xxx"

Besides, the Doc/library/email-examples.rst is not a module and it uses ":mod:`email`: xxx"

----------
assignee: docs at python
components: Documentation
files: email_subpackages_document_problems.diff
keywords: patch
messages: 133143
nosy: docs at python, ysj.ray
priority: normal
severity: normal
status: open
title: email subpackages documentation problems
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21552/email_subpackages_document_problems.diff

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

From report at bugs.python.org  Wed Apr  6 18:01:11 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Apr 2011 16:01:11 +0000
Subject: [issue11785] email subpackages documentation problems
In-Reply-To: <1302105466.45.0.930997240631.issue11785@psf.upfronthosting.co.za>
Message-ID: <1302105671.12.0.703298050177.issue11785@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/issue11785>
_______________________________________

From report at bugs.python.org  Wed Apr  6 18:01:41 2011
From: report at bugs.python.org (ysj.ray)
Date: Wed, 06 Apr 2011 16:01:41 +0000
Subject: [issue11785] email subpackages documentation problems
In-Reply-To: <1302105466.45.0.930997240631.issue11785@psf.upfronthosting.co.za>
Message-ID: <1302105701.62.0.0575938301293.issue11785@psf.upfronthosting.co.za>


ysj.ray <ysj.ray at gmail.com> added the comment:

And this causes the toctree in email doc(http://docs.python.org/dev/library/email.html) in correct. All of the tree elements' names are displayed as "email".

----------

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

From report at bugs.python.org  Wed Apr  6 18:27:22 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 06 Apr 2011 16:27:22 +0000
Subject: [issue7311] Bug on regexp of HTMLParser
In-Reply-To: <1258043150.41.0.372876851796.issue7311@psf.upfronthosting.co.za>
Message-ID: <1302107242.46.0.603478474491.issue7311@psf.upfronthosting.co.za>


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

I would agree if the HTMLParser was compliant with the HTML 4.01 specs, but since it's more permissive and uses its own heuristic to determine what should be parsed and what shouldn't, I think it's better to use already existing heuristics (either the HTML5 ones or the ones used by the browsers).
I.e., I'm not trying to make it HTML5 compliant, just to make it work with what works on the browsers.

----------

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

From report at bugs.python.org  Wed Apr  6 18:32:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 06 Apr 2011 16:32:23 +0000
Subject: [issue7311] Bug on regexp of HTMLParser
In-Reply-To: <1302107242.46.0.603478474491.issue7311@psf.upfronthosting.co.za>
Message-ID: <1e88ef4ef0d68cb1be55a732a485a207@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

Okay, sounds good.

----------

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

From report at bugs.python.org  Wed Apr  6 19:02:48 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 06 Apr 2011 17:02:48 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1302109368.18.0.0751375606404.issue4111@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

jcea: I notice that on 2011-02-22 you made these changes:
  assignee: dmalcolm -> dino.viehland
  nosy: +dino.viehland
  versions: +Python 3.3 -Python 3.2

Did you mean to change the assignee, or was this an accident?

----------

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

From report at bugs.python.org  Wed Apr  6 19:17:57 2011
From: report at bugs.python.org (Adam Groszer)
Date: Wed, 06 Apr 2011 17:17:57 +0000
Subject: [issue11786] ConfigParser.[Raw]ConfigParser optionxform()
In-Reply-To: <1302110277.82.0.57770456199.issue11786@psf.upfronthosting.co.za>
Message-ID: <1302110277.82.0.57770456199.issue11786@psf.upfronthosting.co.za>


New submission from Adam Groszer <agroszer at gmail.com>:

The documentation http://docs.python.org/library/configparser.html states that optionxform() is used only beginning ConfigParser.ConfigParser, whereas it is ALSO in effect for ConfigParser.RawConfigParser. (As I checked in the source)

----------
assignee: docs at python
components: Documentation
messages: 133148
nosy: Adam.Groszer, docs at python
priority: normal
severity: normal
status: open
title: ConfigParser.[Raw]ConfigParser optionxform()
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr  6 19:24:55 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 06 Apr 2011 17:24:55 +0000
Subject: [issue11786] ConfigParser.[Raw]ConfigParser optionxform()
In-Reply-To: <1302110277.82.0.57770456199.issue11786@psf.upfronthosting.co.za>
Message-ID: <1302110695.51.0.120615030111.issue11786@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
assignee: docs at python -> lukasz.langa
nosy: +lukasz.langa

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

From report at bugs.python.org  Wed Apr  6 19:27:58 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 06 Apr 2011 17:27:58 +0000
Subject: [issue7311] Bug on regexp of HTMLParser
In-Reply-To: <1258043150.41.0.372876851796.issue7311@psf.upfronthosting.co.za>
Message-ID: <1302110878.44.0.778621321956.issue7311@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

We need not base changes to html/parser.py on html5 spec, but rather make changes based on the requirements on parsers which may rely on this library. Like the tolerant mode was brought in issue1486713 for some practical reasons and it was seen useful tor parsers.

I don't know, how common is leaving out quotes for attributes is, but I think it can become really confusing to parsers (custom parsers). If we had not supported non-quote attributes I think, it is still okay still to not-to-support unless presented with case as very concrete bug. (like spec html 4.1 allows, which I see it does not).

The patch which added support for non-ascii characters is fine.

----------

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

From report at bugs.python.org  Wed Apr  6 19:43:33 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 06 Apr 2011 17:43:33 +0000
Subject: [issue11786] ConfigParser.[Raw]ConfigParser optionxform()
In-Reply-To: <1302110277.82.0.57770456199.issue11786@psf.upfronthosting.co.za>
Message-ID: <1302111813.68.0.479273620258.issue11786@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

The documentation may be poorly worded but `optionxform()` has always been used also by RawConfigParser. It has been that way since the introduction of this class in Python 2.3 (previously there was only one ConfigParser class which used `optionxform()` since at least Python 1.6).

Both the documentation and the code have seen significant updates in Python 3.2 and there the situation is more explicit.

I'll rephrase the docs for 2.7.

----------
resolution:  -> accepted

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

From report at bugs.python.org  Wed Apr  6 20:04:08 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 06 Apr 2011 18:04:08 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1302113048.7.0.567347857643.issue4111@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Malcolm, it was a mistake. I only wanted to change the TARGET.

I assign the issue to you again.

Dino, I delete you from the nosy list now. Sorry for the inconvenience.

My excuses to both.

----------
assignee: dino.viehland -> dmalcolm
nosy:  -dino.viehland

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

From report at bugs.python.org  Wed Apr  6 20:38:49 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 06 Apr 2011 18:38:49 +0000
Subject: [issue11779] test_mmap timeout (30 min) on "AMD64 Snow Leopard 3.x"
	buildbot
In-Reply-To: <1302076762.26.0.815715887004.issue11779@psf.upfronthosting.co.za>
Message-ID: <1302115129.85.0.0171888617264.issue11779@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

I can't confirm that.
On my cheap MacBook it takes some five minutes:


20:20 ~ $ time python3 -E -Wd -m test -r -w -uall test_mmap
Using random seed 1490092
[1/1] test_mmap
1 test OK.
[91067 refs]

real	4m50.301s
user	0m0.301s
sys	0m13.232s

...

20:21 ~ $ ll tmp/test_python_478/
total 6291456
 6291456 -rw-r-----  1 steffen  staff  6442450944  6 Apr 20:21 @test_478_tmp

...

Processes: 63 total, 2 running, 2 stuck, 59 sleeping, 251 threads                20:23:00
Load Avg: 0.85, 0.51, 0.24  CPU usage: 9.13% user, 15.38% sys, 75.48% idle
SharedLibs: 8260K resident, 9972K data, 0B linkedit.
MemRegions: 5563 total, 184M resident, 12M private, 391M shared.
PhysMem: 437M wired, 267M active, 113M inactive, 818M used, 1230M free.
VM: 140G vsize, 1042M framework vsize, 24419(0) pageins, 0(0) pageouts.
Networks: packets: 91/17K in, 101/17K out. Disks: 11128/551M read, 11089/8215M written.

PID   COMMAND      %CPU TIME     #TH  #WQ  #POR #MRE RPRVT  RSHRD  RSIZE  VPRVT  VSIZE
478   python3      4.0  00:07.22 2    0    37   137  13M    244K   15M    30M    2402M

...

20:24 ~ $ ll tmp/test_python_478/
total 5505024
 5505024 -rw-r-----  1 steffen  staff  5637144576  6 Apr 20:24 @test_478_tmp

...

Processes: 60 total, 2 running, 1 stuck, 57 sleeping, 246 threads                20:24:00
Load Avg: 1.28, 0.69, 0.33  CPU usage: 8.29% user, 16.9% sys, 75.60% idle
SharedLibs: 8260K resident, 9972K data, 0B linkedit.
MemRegions: 5444 total, 181M resident, 11M private, 535M shared.
PhysMem: 437M wired, 259M active, 124M inactive, 820M used, 1228M free.
VM: 133G vsize, 1042M framework vsize, 24421(0) pageins, 0(0) pageouts.
Networks: packets: 91/17K in, 101/17K out. Disks: 11128/551M read, 14697/11G written.

PID   COMMAND      %CPU TIME     #TH  #WQ  #POR #MRE RPRVT  RSHRD  RSIZE  VPRVT  VSIZE
478   python3      4.4  00:10.04 2    0    37   137  13M    244K   15M    30M    2402M


Is this the bot for which you've tracked those random failures?
Maybe this is a hardware failure, then?
(In the past i have had problems with my old PC and it's Elitegroup
K7S5A motherboard, running on FreeBSD 5.3.
That thing randomly produced "Stray IRQ 11" (about ~handful a day),
and it's ATA controller (i think) randomly caused complete hard disk
regions to become unreadable until after a restart.)

----------
nosy: +sdaoden

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

From report at bugs.python.org  Wed Apr  6 20:39:14 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 06 Apr 2011 18:39:14 +0000
Subject: [issue11715] Building Python on multiarch Debian and Ubuntu
In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za>
Message-ID: <1302115154.18.0.334184901027.issue11715@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee:  -> barry

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

From report at bugs.python.org  Wed Apr  6 20:42:55 2011
From: report at bugs.python.org (Pulin Shah)
Date: Wed, 06 Apr 2011 18:42:55 +0000
Subject: [issue11787] File handle leak in TarFile lib
In-Reply-To: <1302115375.88.0.984018215443.issue11787@psf.upfronthosting.co.za>
Message-ID: <1302115375.88.0.984018215443.issue11787@psf.upfronthosting.co.za>


New submission from Pulin Shah <shahpr at gmail.com>:

I ran into a problem the other day while trying to extract a slightly corrupted tar file.  I suspect this problem is really only an issue on Windows systems.  I am running Python 2.7.1 r271:86832 win32.

The following code (simplified) snipet

try:
	tar = tarfile.open(args.file)
	tar.extractall(basefolder)
	tar.close()
except tarfile.ReadError:
	shutil.rmtree(basefolder)
except IOError:
	shutil.rmtree(basefolder)

was throwing a WindowsError on the rmtree calls.

This is due to the tarfile library not closing file handles in the case of an exception in the copyfileobj function, and Windows inability to delete open files.  

I was able to patch the issue locally by modifying tarfile's makefile function as follows:

    def makefile(self, tarinfo, targetpath):
        """Make a file called targetpath.
        """
        source = self.extractfile(tarinfo)
        target = bltn_open(targetpath, "wb")
        try:
            copyfileobj(source, target)
        except:
            source.close()
            target.close()
            raise
        source.close()
        target.close()

There is probably a cleaner way of implementing it.

I'm hoping you can integrate this patch into later versions of the lib.

Thanks.

----------
components: Library (Lib)
messages: 133153
nosy: shahpr
priority: normal
severity: normal
status: open
title: File handle leak in TarFile lib
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr  6 20:48:17 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 06 Apr 2011 18:48:17 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1302115697.83.0.601913896043.issue11277@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

I can't confirm this for my MacBook:


20:39 ~ $ time python3 -E -Wd -m test -r -w -uall test_zlib
Using random seed 1960084
[1/1] test_zlib
1 test OK.
[91618 refs]

real	4m1.051s
user	0m15.031s
sys	0m26.908s

...

20:40 ~ $ ll tmp/test_python_6778/
4194308 -rw-r-----  1 steffen  staff  4294967300  6 Apr 20:40 @test_6778_tmp

...

Processes: 63 total, 2 running, 3 stuck, 58 sleeping, 246 threads                20:40:30
Load Avg: 0.59, 0.65, 0.56  CPU usage: 6.79% user, 13.10% sys, 80.9% idle
SharedLibs: 8260K resident, 9972K data, 0B linkedit.
MemRegions: 6043 total, 218M resident, 13M private, 185M shared.
PhysMem: 446M wired, 328M active, 138M inactive, 912M used, 1135M free.
VM: 143G vsize, 1042M framework vsize, 29610(0) pageins, 0(0) pageouts.
Networks: packets: 807/440K in, 933/129K out. Disks: 13881/581M read, 26057/16G written.

PID   COMMAND      %CPU TIME     #TH  #WQ  #PORT #MRE RPRVT  RSHRD  RSIZE  VPRVT  VSIZE
6778  python3      4.5  00:00.94 2    0    37    139  13M    320K   15M    38M    2403M

...

Processes: 63 total, 3 running, 60 sleeping, 253 threads                         20:41:30
Load Avg: 0.54, 0.62, 0.55  CPU usage: 12.98% user, 14.90% sys, 72.11% idle
SharedLibs: 8260K resident, 9972K data, 0B linkedit.
MemRegions: 6062 total, 269M resident, 13M private, 274M shared.
PhysMem: 443M wired, 329M active, 184M inactive, 955M used, 1091M free.
VM: 147G vsize, 1042M framework vsize, 41530(11520) pageins, 0(0) pageouts.
Networks: packets: 807/440K in, 933/129K out. Disks: 13950/627M read, 29598/19G written.

PID   COMMAND      %CPU TIME     #TH  #WQ  #PORT #MRE RPRVT  RSHRD  RSIZE  VPRVT  VSIZE
6778  python3      11.6 00:03.74 2    0    37    140  60M+   320K   62M+   4134M  6499M

...

20:43 ~ $ ll tmp/test_python_6778/
4194308 -rw-r-----  1 steffen  staff  4294967300  6 Apr 20:40 @test_6778_tmp


As i've stated for #11779, maybe these random errors of the bot
are caused by some strange hardware based error?

----------

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

From report at bugs.python.org  Wed Apr  6 21:25:41 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 06 Apr 2011 19:25:41 +0000
Subject: [issue11715] Building Python on multiarch Debian and Ubuntu
In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za>
Message-ID: <1302117941.99.0.888627605958.issue11715@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Since I do automated module testing against all Python versions,
my vote would be:

2.5: +1
2.6: +1
3.1: +1


This with the caveat that of course Martin has to decide for 2.5.
I'm just indicating my preference.

----------
nosy: +skrah

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

From report at bugs.python.org  Wed Apr  6 21:25:51 2011
From: report at bugs.python.org (Shereef Marzouk)
Date: Wed, 06 Apr 2011 19:25:51 +0000
Subject: [issue4735] An error occurred during the installation of assembly
In-Reply-To: <1230086140.51.0.868984437874.issue4735@psf.upfronthosting.co.za>
Message-ID: <1302117951.13.0.112721542113.issue4735@psf.upfronthosting.co.za>


Shereef Marzouk <sheefoz at gmail.com> added the comment:

here is the log.
P.S. i have VS Studio 2005 installed

----------
nosy: +Shereef
Added file: http://bugs.python.org/file21553/python.zip

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

From report at bugs.python.org  Wed Apr  6 21:30:54 2011
From: report at bugs.python.org (Shereef Marzouk)
Date: Wed, 06 Apr 2011 19:30:54 +0000
Subject: [issue4735] An error occurred during the installation of assembly
In-Reply-To: <1230086140.51.0.868984437874.issue4735@psf.upfronthosting.co.za>
Message-ID: <1302118254.52.0.88801730375.issue4735@psf.upfronthosting.co.za>


Shereef Marzouk <sheefoz at gmail.com> added the comment:

in my last message i forgot to give more details sorry

i first installed python 2.7.1 for amd64
but it made problems iwht pywin and buildbot-slave packeges
so i wanted to install python the i386 one
and i got this error i tried amd64 again now and it installed fine

----------

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

From report at bugs.python.org  Wed Apr  6 21:50:24 2011
From: report at bugs.python.org (Shereef Marzouk)
Date: Wed, 06 Apr 2011 19:50:24 +0000
Subject: [issue4735] An error occurred during the installation of assembly
In-Reply-To: <1230086140.51.0.868984437874.issue4735@psf.upfronthosting.co.za>
Message-ID: <1302119424.12.0.792634484307.issue4735@psf.upfronthosting.co.za>


Shereef Marzouk <sheefoz at gmail.com> added the comment:

uhm, i restarted my pc and everything went through fine

----------

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

From report at bugs.python.org  Wed Apr  6 21:52:43 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Wed, 06 Apr 2011 19:52:43 +0000
Subject: [issue11767] Maildir iterator leaks file descriptors by default
In-Reply-To: <1301958670.39.0.218079408331.issue11767@psf.upfronthosting.co.za>
Message-ID: <1302119563.15.0.895783720262.issue11767@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Shouldn't this be your responsibility to close this descriptor in the object used as self._factory? When self._factory is called it should read from the file like object and then simply close it, just as get_message (when self._factory is not provided) does.

----------
nosy: +gruszczy

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

From report at bugs.python.org  Wed Apr  6 21:59:45 2011
From: report at bugs.python.org (Brendan Dolan-Gavitt)
Date: Wed, 06 Apr 2011 19:59:45 +0000
Subject: [issue11767] Maildir iterator leaks file descriptors by default
In-Reply-To: <1301958670.39.0.218079408331.issue11767@psf.upfronthosting.co.za>
Message-ID: <1302119985.22.0.438422483615.issue11767@psf.upfronthosting.co.za>


Brendan Dolan-Gavitt <brendandg at gatech.edu> added the comment:

The _factory object didn't open the file, so why should it close it?

It's also worth noting that things one would naturally consider using as factories (like email.message_from_file) don't close the fd when they're done. I will grant that you could easily create a wrapper factory that does close the descriptor in this case, but that's not the obvious thing to do.

----------

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

From report at bugs.python.org  Wed Apr  6 22:11:35 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 06 Apr 2011 20:11:35 +0000
Subject: [issue11766] test_multiprocessing failure (test_pool_worker_lifetime)
In-Reply-To: <1301952687.8.0.704166844851.issue11766@psf.upfronthosting.co.za>
Message-ID: <1302120695.97.0.296723787225.issue11766@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Does this only happen on Cygwin buildbots ?
If yes, then it might simply be an issue with Cygwin's fork implementation, which is much slower than natively.
Right now, the test waits 0.5s before checking that the processes are started, after repopulating the pool. While 0.5s is normally way enough for forking a couple processes, it seems that under Cygwin this can take a surprising amount of time, see http://old.nabble.com/Slow-fork-issue---Win-x64-td19538601.html and also http://superuser.com/questions/133313/can-i-speed-up-cygwins-fork
Unless I misunderstand their benchmarks, the fork (+exec) rate of "date" from a shell can be as low as 5/sec, so I can only guess what forking cpython would take.
Maybe we could try to increase the timeout before checking the PIDs:

+    countdown = 10
-    countdown = 10
    while countdown and not all(w.is_alive() for w in p._pool):
        countdown -= 1
        time.sleep(DELTA)

----------
nosy: +neologix

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

From report at bugs.python.org  Wed Apr  6 22:18:52 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Apr 2011 20:18:52 +0000
Subject: [issue11767] Maildir iterator leaks file descriptors by default
In-Reply-To: <1301958670.39.0.218079408331.issue11767@psf.upfronthosting.co.za>
Message-ID: <1302121132.67.0.267209561637.issue11767@psf.upfronthosting.co.za>


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

It is not clear from the docs what the expected behavior of factory is.  It is certainly the case that the custom classes used by mailbox by default do not close the file they are passed.  So either those classes should close the input file and factory should be so documented, or all the methods that create a message object should close the input file when they create one.  Since the existing get_message methods take care to close any opened input files, I favor the latter (ie: the OP's suggestion).

Anyone care to propose a patch?

----------

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

From report at bugs.python.org  Wed Apr  6 22:31:35 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Wed, 06 Apr 2011 20:31:35 +0000
Subject: [issue11767] Maildir iterator leaks file descriptors by default
In-Reply-To: <1301958670.39.0.218079408331.issue11767@psf.upfronthosting.co.za>
Message-ID: <1302121895.64.0.783201825798.issue11767@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

How about this? Though I have no idea, how a test could be created for this. If someone could advise me on that, I'll be happy to write tests/work further on the patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file21554/11767.patch

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

From report at bugs.python.org  Wed Apr  6 22:32:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Apr 2011 20:32:32 +0000
Subject: [issue11766] test_multiprocessing failure (test_pool_worker_lifetime)
In-Reply-To: <1301952687.8.0.704166844851.issue11766@psf.upfronthosting.co.za>
Message-ID: <1302121952.51.0.592012179834.issue11766@psf.upfronthosting.co.za>


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

There is no Cygwin buildbot, this is a regular Windows buildbot (despite the path in the traceback).
That said, spawning processes is quite slow under Windows anyway (much slower than under Linux). So we could up the countdown.

----------

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

From report at bugs.python.org  Wed Apr  6 22:35:38 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 06 Apr 2011 20:35:38 +0000
Subject: [issue11715] Building Python on multiarch Debian and Ubuntu
In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za>
Message-ID: <E1Q7ZRw-0006mc-3i@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7582a78f573b by Barry Warsaw in branch '3.1':
Issue 11715: Build extension modules on multiarch Debian and Ubuntu by
http://hg.python.org/cpython/rev/7582a78f573b

New changeset 867937dd2279 by Barry Warsaw in branch '3.2':
Issue 11715: Merge multiarch fix from 3.1 branch.
http://hg.python.org/cpython/rev/867937dd2279

New changeset 3f00611c3daf by Barry Warsaw in branch 'default':
Issue 11715: Merge multiarch fix from 3.1 branch.
http://hg.python.org/cpython/rev/3f00611c3daf

----------
nosy: +python-dev

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

From report at bugs.python.org  Wed Apr  6 22:54:56 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 06 Apr 2011 20:54:56 +0000
Subject: [issue11766] test_multiprocessing failure (test_pool_worker_lifetime)
In-Reply-To: <1301952687.8.0.704166844851.issue11766@psf.upfronthosting.co.za>
Message-ID: <E1Q7Zkc-0008RC-G0@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c4a514199dba by Antoine Pitrou in branch '3.2':
Issue #11766: increase countdown waiting for a pool of processes to start
http://hg.python.org/cpython/rev/c4a514199dba

New changeset 3eac8302a448 by Antoine Pitrou in branch 'default':
Issue #11766: increase countdown waiting for a pool of processes to start
http://hg.python.org/cpython/rev/3eac8302a448

----------
nosy: +python-dev

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

From report at bugs.python.org  Wed Apr  6 22:58:47 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Apr 2011 20:58:47 +0000
Subject: [issue11785] email subpackages documentation problems
In-Reply-To: <1302105466.45.0.930997240631.issue11785@psf.upfronthosting.co.za>
Message-ID: <1302123527.6.0.104240229505.issue11785@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee: docs at python -> r.david.murray

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

From report at bugs.python.org  Wed Apr  6 23:01:42 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 06 Apr 2011 21:01:42 +0000
Subject: [issue11766] test_multiprocessing failure (test_pool_worker_lifetime)
In-Reply-To: <1301952687.8.0.704166844851.issue11766@psf.upfronthosting.co.za>
Message-ID: <E1Q7ZrA-0000ig-6E@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 2e4cdaffe493 by Antoine Pitrou in branch '2.7':
Issue #11766: increase countdown waiting for a pool of processes to start
http://hg.python.org/cpython/rev/2e4cdaffe493

----------

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

From report at bugs.python.org  Wed Apr  6 23:03:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Apr 2011 21:03:07 +0000
Subject: [issue11766] test_multiprocessing failure (test_pool_worker_lifetime)
In-Reply-To: <1301952687.8.0.704166844851.issue11766@psf.upfronthosting.co.za>
Message-ID: <1302123787.25.0.00938159983989.issue11766@psf.upfronthosting.co.za>


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

Hopefully fixed now, thanks for your diagnosis!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 3.1

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

From report at bugs.python.org  Wed Apr  6 23:19:27 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 06 Apr 2011 21:19:27 +0000
Subject: [issue11787] File handle leak in TarFile lib
In-Reply-To: <1302115375.88.0.984018215443.issue11787@psf.upfronthosting.co.za>
Message-ID: <1302124767.14.0.579343045663.issue11787@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +lars.gustaebel

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

From report at bugs.python.org  Wed Apr  6 23:21:47 2011
From: report at bugs.python.org (Scott Kitterman)
Date: Wed, 06 Apr 2011 21:21:47 +0000
Subject: [issue11492] email.header.Header doesn't fold headers
In-Reply-To: <1300087978.39.0.703069545984.issue11492@psf.upfronthosting.co.za>
Message-ID: <1302124907.09.0.0511352362153.issue11492@psf.upfronthosting.co.za>


Scott Kitterman <sklist at kitterman.com> added the comment:

Not so fast ...  I may have done this wrong, but I get:

print(Header(hdrin,maxlinelen=78))
Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by mailwash7.pair.com (Postfix) with ESMTP id 16BB5BAD5 for <bcc at kitterman.com>; Sun, 13 Mar 2011 23:46:05 -0400 (EDT)

all in one line with python3.2, so maxlinelen doesn't appear to do anything.  With python2.7 it seems to when invoked that way:

Python 2.7.1+ (r271:86832, Mar 24 2011, 00:39:14) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from email.header import Header
>>> hdrin = 'Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by mailwash7.pair.com (Postfix) with ESMTP id 16BB5BAD5 for <bcc at kitterman.com>; Sun, 13 Mar 2011 23:46:05 -0400 (EDT)'
>>> print(Header(hdrin))
Received: from mailout00.controlledmail.com (mailout00.controlledmail.com
 [72.81.252.19]) by mailwash7.pair.com (Postfix) with ESMTP id 16BB5BAD5 for
 <bcc at kitterman.com>; Sun, 13 Mar 2011 23:46:05 -0400 (EDT)
>>> print(Header(hdrin, maxlinelen=30))
Received: from
 mailout00.controlledmail.com
 (mailout00.controlledmail.com
 [72.81.252.19]) by
 mailwash7.pair.com (Postfix)
 with ESMTP id 16BB5BAD5 for
 <bcc at kitterman.com>;
 Sun, 13 Mar 2011 23:46:05
 -0400 (EDT)

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

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

From report at bugs.python.org  Wed Apr  6 23:43:12 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Apr 2011 21:43:12 +0000
Subject: [issue11492] email.header.Header doesn't fold headers at spaces
In-Reply-To: <1300087978.39.0.703069545984.issue11492@psf.upfronthosting.co.za>
Message-ID: <1302126192.21.0.304169086641.issue11492@psf.upfronthosting.co.za>


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

You have to do an 'encode' to get the wrapped header. __str__ uses maxlinelen=None.

However, there does seem to be a problem with the line wrapping algorithm revealed by your example: it is only doing a line break at the ';', not at any spaces.  I will look in to this.

----------
title: email.header.Header doesn't fold headers -> email.header.Header doesn't fold headers at spaces

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

From report at bugs.python.org  Wed Apr  6 23:46:54 2011
From: report at bugs.python.org (Carsten Klein)
Date: Wed, 06 Apr 2011 21:46:54 +0000
Subject: [issue11788] Decorator class with optional arguments and a __call__
	method gets not called when there are no arguments
In-Reply-To: <1302126414.93.0.377099378978.issue11788@psf.upfronthosting.co.za>
Message-ID: <1302126414.93.0.377099378978.issue11788@psf.upfronthosting.co.za>


New submission from Carsten Klein <carsten.klein at axn-software.de>:

Scenario:

class deco(object):
  def __init__(self, optional = False):
    self._optional = optional

  def __call__(self, decorated):
    decorated.optional = self._optional
    return decorated

@deco
class y(object):
  pass

will fail decorating the class since y is passed in as the first parameter to deco.__init__, and deco.__call__ will never be called.

@deco(optional = True)
class y(object):
  pass

will succeed.

I wonder why there is a distinction between decorator class w/ arguments and decorator class w/o arguments?

Guessing that one would like to have a decorator class decorating another class and also acting as a kind of proxy by implementing a __call__ method, this could also be achieved by further indirection, provided that it will not break existing code.

A working alternative would be a decorator function like this:

def deco(_decorated = None, optional = False):
  def _wrapped(decorated):
    decorated.optional = optional
    return decorated
  if _decorated is not None:
    return _wrapped(decorated)
  return _wrapped

Is there a chance that the behavior of the decorator class will be fixed in a future release?

Expected behavior for the decorator class would be:

if formal parameter list has optional parameters and actual parameter list is empty and there are no formal mandatory parameters:
   if decorator class is callable:
      deco = decorator class ()
      decor.__call__(decorated)
   else:
      fall back to old behaviour, requiring the decorator class __init__ method to have one mandatory parameter
else:
  deco = decorator class(actual parameters...)
  deco.__call__(decorated)

TIA

----------
components: Interpreter Core
messages: 133171
nosy: carsten.klein
priority: normal
severity: normal
status: open
title: Decorator class with optional arguments and a __call__ method gets not called when there are no arguments
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Apr  6 23:47:57 2011
From: report at bugs.python.org (Carsten Klein)
Date: Wed, 06 Apr 2011 21:47:57 +0000
Subject: [issue11788] Decorator class with optional arguments and a __call__
	method gets not called when there are no arguments
In-Reply-To: <1302126414.93.0.377099378978.issue11788@psf.upfronthosting.co.za>
Message-ID: <1302126477.8.0.253038610208.issue11788@psf.upfronthosting.co.za>


Carsten Klein <carsten.klein at axn-software.de> added the comment:

will fail decorating the class since y...

actually means that instead of an instance of class y, an instance of the decorator class will be returned, with y being lost along the way...

----------

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

From report at bugs.python.org  Wed Apr  6 23:55:21 2011
From: report at bugs.python.org (Carsten Klein)
Date: Wed, 06 Apr 2011 21:55:21 +0000
Subject: [issue11789] Extend upon metaclass/type class documentation,
	here: zope.interface and usage of instances of classes as base classes
In-Reply-To: <1302126921.15.0.0291977163306.issue11789@psf.upfronthosting.co.za>
Message-ID: <1302126921.15.0.0291977163306.issue11789@psf.upfronthosting.co.za>


New submission from Carsten Klein <carsten.klein at axn-software.de>:

In zope.interface, you have something the following construct:

class InterfaceBase:
  pass

Interface = InterfaceBase()



Using the above Interface as a derivation base for your own classes, will make that instance a type derived class:

class IFoo(Interface):
  pass

type(IFoo)
-> Interface

type(Interface)
-> type


I wonder why this behavior is not documented in the official documentation, or at least, I was unable to find it there...

----------
assignee: docs at python
components: Documentation
messages: 133173
nosy: carsten.klein, docs at python
priority: normal
severity: normal
status: open
title: Extend upon metaclass/type class documentation, here: zope.interface and usage of instances of classes as base classes
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Thu Apr  7 00:17:13 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 06 Apr 2011 22:17:13 +0000
Subject: [issue7311] Bug on regexp of HTMLParser
In-Reply-To: <1258043150.41.0.372876851796.issue7311@psf.upfronthosting.co.za>
Message-ID: <1302128233.85.0.680111577948.issue7311@psf.upfronthosting.co.za>


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

So is the issue7311-3.diff patch fine?  It changes the strict regex to match the 2.7 one, and leave the tolerant one unchanged (even if now the two regexs are really close).

----------

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

From report at bugs.python.org  Thu Apr  7 00:18:11 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Wed, 06 Apr 2011 22:18:11 +0000
Subject: [issue11788] Decorator class with optional arguments and a __call__
	method gets not called when there are no arguments
In-Reply-To: <1302126414.93.0.377099378978.issue11788@psf.upfronthosting.co.za>
Message-ID: <1302128291.78.0.958723368352.issue11788@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

I wonder if this is a valid use-case to begin with. The semantic of a decorator, as I understand it, is very straightforward in that this:

    @foo
    @bar
    class A:
        pass

is equivalent to this:

    class A:
        pass
    A = foo(bar(A))

In your example, the equivalent statement is:

    y = deco(y)

Which gives you the somewhat surprising result, but it is as the language is designed.

----------
nosy: +santa4nt

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

From report at bugs.python.org  Thu Apr  7 00:22:22 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 06 Apr 2011 22:22:22 +0000
Subject: [issue10977] Concrete object C API needs abstract path for subclasses
	of builtin types
In-Reply-To: <1295653779.62.0.836506069174.issue10977@psf.upfronthosting.co.za>
Message-ID: <1302128542.41.0.206474137119.issue10977@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

One thing that could be done is to have an optional warning in the mutating concrete C API functions that gets triggered whenever the input doesn't have an exact type match.  That will let people discover incorrect uses.

We could also scour our own stdlib code to see if there are any cases where there needs to be an alternate code patch for subclasses of builtin types.

I did a scan for PyList_SetItem and found that we were already pretty good about only using it when the target was known to be an exact list. Though those results were good, I'm not hopeful for a similar result with PyDict_SetItem.

In the mean time this bug will preclude a C version of OrderedDict from being a dict subclass.  That's unfortunate because it means that the C version can't be a drop-in replacement for the existing pure python OrderedDict.

----------

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

From report at bugs.python.org  Thu Apr  7 00:31:48 2011
From: report at bugs.python.org (Carsten Klein)
Date: Wed, 06 Apr 2011 22:31:48 +0000
Subject: [issue11788] Decorator class with optional arguments and a __call__
	method gets not called when there are no arguments
In-Reply-To: <1302126414.93.0.377099378978.issue11788@psf.upfronthosting.co.za>
Message-ID: <1302129108.93.0.297252666842.issue11788@psf.upfronthosting.co.za>


Carsten Klein <carsten.klein at axn-software.de> added the comment:

I think it is, actually, considering

    @foo
    @bar
    class A:
        pass

with foo and bar being both decorator classes, the chained call

foo(bar(A))

will return and instance of foo instead of A


With decorator classes you need to actually do this:

foo()(bar()(A))

which will give you the "required" result, an instance of class A.

----------

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

From report at bugs.python.org  Thu Apr  7 00:34:16 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 06 Apr 2011 22:34:16 +0000
Subject: [issue11788] Decorator class with optional arguments and a __call__
	method gets not called when there are no arguments
In-Reply-To: <1302126414.93.0.377099378978.issue11788@psf.upfronthosting.co.za>
Message-ID: <1302129256.77.0.188928208172.issue11788@psf.upfronthosting.co.za>


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

This is expected; it's the same with functions. Just do @deco().

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Thu Apr  7 00:38:14 2011
From: report at bugs.python.org (Carsten Klein)
Date: Wed, 06 Apr 2011 22:38:14 +0000
Subject: [issue11788] Decorator class with optional arguments and a __call__
	method gets not called when there are no arguments
In-Reply-To: <1302126414.93.0.377099378978.issue11788@psf.upfronthosting.co.za>
Message-ID: <1302129494.84.0.312423741958.issue11788@psf.upfronthosting.co.za>


Carsten Klein <carsten.klein at axn-software.de> added the comment:

Ok, looks like a valid work around to me.

However, IMO it is not the same as with decorator functions.
These will be called and will return the correct result,
whereas the decorator class will instead return an instance
of self instead of being called when no parameters are given.

----------

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

From report at bugs.python.org  Thu Apr  7 00:41:32 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 06 Apr 2011 22:41:32 +0000
Subject: [issue11788] Decorator class with optional arguments and a __call__
	method gets not called when there are no arguments
In-Reply-To: <1302126414.93.0.377099378978.issue11788@psf.upfronthosting.co.za>
Message-ID: <1302129692.17.0.524594796812.issue11788@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I concur with Benjamin.

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

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

From report at bugs.python.org  Thu Apr  7 00:47:44 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 06 Apr 2011 22:47:44 +0000
Subject: [issue11788] Decorator class with optional arguments and a __call__
	method gets not called when there are no arguments
In-Reply-To: <1302129494.84.0.312423741958.issue11788@psf.upfronthosting.co.za>
Message-ID: <BANLkTikR=PcgM2hGcsWpDgW-KnshFnnTVQ@mail.gmail.com>


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

2011/4/6 Carsten Klein <report at bugs.python.org>:
>
> Carsten Klein <carsten.klein at axn-software.de> added the comment:
>
> Ok, looks like a valid work around to me.

It's not a workaround. It's the way decorators work.

----------

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

From report at bugs.python.org  Thu Apr  7 01:04:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Apr 2011 23:04:35 +0000
Subject: [issue11790] transient failure in
	test_multiprocessing.WithProcessesTestCondition
In-Reply-To: <1302131075.81.0.79285380131.issue11790@psf.upfronthosting.co.za>
Message-ID: <1302131075.81.0.79285380131.issue11790@psf.upfronthosting.co.za>


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

http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%207.2%202.7/builds/519/steps/test/logs/stdio

======================================================================
FAIL: test_notify_all (test.test_multiprocessing.WithProcessesTestCondition)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/2.7.bolen-freebsd7/build/Lib/test/test_multiprocessing.py", line 757, in test_notify_all
    self.assertReturnsIfImplemented(6, get_value, woken)
  File "/usr/home/db3l/buildarea/2.7.bolen-freebsd7/build/Lib/test/test_multiprocessing.py", line 116, in assertReturnsIfImplemented
    return self.assertEqual(value, res)
AssertionError: 6 != 5

----------
components: Library (Lib), Tests
messages: 133182
nosy: pitrou
priority: normal
severity: normal
status: open
title: transient failure in test_multiprocessing.WithProcessesTestCondition
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Apr  7 01:54:48 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Wed, 06 Apr 2011 23:54:48 +0000
Subject: [issue11703] Bug in python >= 2.7 with urllib2 fragment
In-Reply-To: <1301347412.09.0.984655654688.issue11703@psf.upfronthosting.co.za>
Message-ID: <1302134088.59.0.475522240016.issue11703@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

It already does. ;-)

Python 2.7.1+ (default, Apr  6 2011, 16:25:38) [MSC v.1500 32 bit (Intel)] on wi
n32
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib2
[74578 refs]
>>> fp = urllib2.urlopen('http://16.foobnix-cms.appspot.com/test_base')
[75643 refs]
>>> fp.geturl()
"http://16.foobnix-cms.appspot.com/test_redirect#json={value:'OK'}"
[75645 refs]

I'm attaching patches with the appropriate unittest for the redirected case, though.

----------
Added file: http://bugs.python.org/file21555/issue11703_py27_with_redirect.patch

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

From report at bugs.python.org  Thu Apr  7 01:55:06 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Wed, 06 Apr 2011 23:55:06 +0000
Subject: [issue11703] Bug in python >= 2.7 with urllib2 fragment
In-Reply-To: <1301347412.09.0.984655654688.issue11703@psf.upfronthosting.co.za>
Message-ID: <1302134106.03.0.306700711098.issue11703@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


Added file: http://bugs.python.org/file21556/issue11703_py31_with_redirect.patch

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

From report at bugs.python.org  Thu Apr  7 02:03:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Apr 2011 00:03:18 +0000
Subject: [issue8428] buildbot: test_multiprocessing timeout (test_notify_all?
	test_pool_worker_lifetime?)
In-Reply-To: <1271451412.83.0.723333785051.issue8428@psf.upfronthosting.co.za>
Message-ID: <1302134598.15.0.703222189146.issue8428@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Another test_multiprocessing failure (30 min timeout) on x86 XP-4 3.x:
----------------------
[125/354] test_multiprocessing
Thread 0x00000e5c:
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 235 in wait
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\queue.py", line 185 in get
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\pool.py", line 372 in _handle_results
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 688 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 735 in _bootstrap_inner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 708 in _bootstrap

Thread 0x00000c14:
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 235 in wait
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\queue.py", line 185 in get
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\pool.py", line 331 in _handle_tasks
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 688 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 735 in _bootstrap_inner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 708 in _bootstrap

Thread 0x00000d78:
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\pool.py", line 324 in _handle_workers
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 688 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 735 in _bootstrap_inner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 708 in _bootstrap

Thread 0x000003b8:
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 235 in wait
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\queue.py", line 185 in get
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\pool.py", line 102 in worker
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 688 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 735 in _bootstrap_inner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 708 in _bootstrap

Thread 0x000001e8:
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 235 in wait
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\queue.py", line 185 in get
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\pool.py", line 102 in worker
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 688 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 735 in _bootstrap_inner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 708 in _bootstrap

Thread 0x000002ac:
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 235 in wait
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\queue.py", line 185 in get
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\pool.py", line 102 in worker
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 688 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 735 in _bootstrap_inner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 708 in _bootstrap

Thread 0x000005a4:
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 235 in wait
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\queue.py", line 185 in get
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\pool.py", line 102 in worker
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 688 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 735 in _bootstrap_inner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 708 in _bootstrap

Thread 0x00000c84:
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\forking.py", line 287 in wait
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\process.py", line 149 in join
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\pool.py", line 458 in join
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_multiprocessing.py", line 1143 in test_async_error_callback
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\case.py", line 387 in _executeTestPart
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\case.py", line 442 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\case.py", line 494 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 105 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 67 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 105 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 67 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 105 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 67 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\support.py", line 1078 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\support.py", line 1166 in _run_suite
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\support.py", line 1192 in run_unittest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_multiprocessing.py", line 2152 in test_main
  File "../lib/test/regrtest.py", line 1032 in runtest_inner
  File "../lib/test/regrtest.py", line 826 in runtest
  File "../lib/test/regrtest.py", line 650 in main
  File "../lib/test/regrtest.py", line 1607 in <module>

remoteFailed: [Failure instance: Traceback (failure with no frames): <class 'twisted.internet.error.ConnectionLost'>: Connection to the other side was lost in a non-clean fashion.
]
----------------------
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4349/steps/test/logs/stdio

----------

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

From report at bugs.python.org  Thu Apr  7 02:39:03 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 Apr 2011 00:39:03 +0000
Subject: [issue7311] Bug on regexp of HTMLParser
In-Reply-To: <1258043150.41.0.372876851796.issue7311@psf.upfronthosting.co.za>
Message-ID: <1302136743.17.0.286584171623.issue7311@psf.upfronthosting.co.za>


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

Sounds fine to me.

----------

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

From report at bugs.python.org  Thu Apr  7 02:43:59 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 Apr 2011 00:43:59 +0000
Subject: [issue11767] Maildir iterator leaks file descriptors by default
In-Reply-To: <1301958670.39.0.218079408331.issue11767@psf.upfronthosting.co.za>
Message-ID: <1302137039.98.0.93221962409.issue11767@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file21554/11767.patch

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

From report at bugs.python.org  Thu Apr  7 02:47:45 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 Apr 2011 00:47:45 +0000
Subject: [issue11767] Maildir iterator leaks file descriptors by default
In-Reply-To: <1301958670.39.0.218079408331.issue11767@psf.upfronthosting.co.za>
Message-ID: <1302137265.1.0.729096300689.issue11767@psf.upfronthosting.co.za>


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

get_file's promise is that what is returned is a file like object, so it not having a close() method would be an error.  So I don't think you need the try/except.  What I would suggest is to use the 'closing' context manager around the return statement.

As for tests, you could create a subclass with a custom get_file method that returns a mock object you can test to make sure the close method gets called, since Mailbox is the only place __getitem__ is defined.

Gah, I hit the wrong key an deleted your patch.  Reattaching.

----------
Added file: http://bugs.python.org/file21557/11767.patch

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

From report at bugs.python.org  Thu Apr  7 03:12:46 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 Apr 2011 01:12:46 +0000
Subject: [issue11700] mailbox.py proxy updates
In-Reply-To: <1301315190.34.0.276151285444.issue11700@psf.upfronthosting.co.za>
Message-ID: <1302138766.28.0.0220049130326.issue11700@psf.upfronthosting.co.za>


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

Given your problem report wouldn't the simplest solution be to change the close method to be:

   if hasattr(self, '_file'):
       if hasattr(self._file, 'close'):
           self._file.close()
       del self._file

As for a test, it seems to me that adding a test to the appropriate existing cases that calls get_file and then closes the returned object twice should be sufficient.

----------

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

From report at bugs.python.org  Thu Apr  7 03:27:55 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 07 Apr 2011 01:27:55 +0000
Subject: [issue7311] Bug on regexp of HTMLParser
In-Reply-To: <1258043150.41.0.372876851796.issue7311@psf.upfronthosting.co.za>
Message-ID: <1302139675.5.0.0781434376181.issue7311@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

> So is the issue7311-3.diff patch fine? 

Just that it allows unquoted attrs for unicode too.

My previous suggestion was not to allow unquoted attribute values, but as the change is already made in 2.7 and discussion pointed out a portion in 4.1 spec which allows unquoted attrs for ASCII, it seems fine. html/parse.py will be bit more permissive than what the spec says.

> It changes the strict regex to match the 2.7 one, and leave the tolerant one unchanged.

That is fine.

----------

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

From report at bugs.python.org  Thu Apr  7 04:03:25 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 07 Apr 2011 02:03:25 +0000
Subject: [issue7311] Bug on regexp of HTMLParser
In-Reply-To: <1258043150.41.0.372876851796.issue7311@psf.upfronthosting.co.za>
Message-ID: <1302141805.44.0.347752924054.issue7311@psf.upfronthosting.co.za>


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

On 3.2 the patch changes only the range of chars matched by the regex when the attribute value doesn't have quotes and strict=True.

The parser already allowed unquotes attribute values even before the patch (in both strict and tolerant mode), but used an explicit list of allowed chars that was limited to the ASCII range.

----------

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

From report at bugs.python.org  Thu Apr  7 04:15:00 2011
From: report at bugs.python.org (atppp)
Date: Thu, 07 Apr 2011 02:15:00 +0000
Subject: [issue6059] ctypes/uuid-related segmentation fault
In-Reply-To: <1242699417.24.0.211949858612.issue6059@psf.upfronthosting.co.za>
Message-ID: <1302142500.68.0.923462292651.issue6059@psf.upfronthosting.co.za>


atppp <wuxinan at gmail.com> added the comment:

crash with python/2.6.5, imagemagick/6.5.7.8, uuid/2.17.2, ubuntu/10.04:

import magickwand.image
import uuid
uuid.uuid4()

----------
nosy: +atppp

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

From report at bugs.python.org  Thu Apr  7 06:50:19 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 07 Apr 2011 04:50:19 +0000
Subject: [issue10977] Concrete object C API needs abstract path for subclasses
	of builtin types
In-Reply-To: <1295653779.62.0.836506069174.issue10977@psf.upfronthosting.co.za>
Message-ID: <1302151819.09.0.724675886969.issue10977@psf.upfronthosting.co.za>


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

I thought about a warning, but the problem is that a subclass using the concrete API as part of its *implementation* of the associated slot or method is actually perfectly correct usage.

I'm not sure this is enough to give up on the idea of OrderedDict being a dict subclass implemented in C, though. It seems to me that some defensive internal checks (to pick up state corruption due to this problem) would be a lesser evil than giving up on being a dict subclass.

----------

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

From report at bugs.python.org  Thu Apr  7 08:08:23 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 07 Apr 2011 06:08:23 +0000
Subject: [issue11771] hashlib object cannot be pickled
In-Reply-To: <1302012128.46.0.552990700902.issue11771@psf.upfronthosting.co.za>
Message-ID: <BANLkTimUcUw+w_vQsc7g0McXjqVQeWs3ZQ@mail.gmail.com>


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

heh yeah.  while all hash functions do have internal state and someone
could conceivably want to store such a state (it basically amounts to
queued up partial block of input data if any and the current starting
IV) there are not consistent APIs to expose that and I really don't
see why it'd be worth trying to find them.

remember, hashlib doesn't have to be openssl.  there are non openssl
libtomcrypt based versions and someone nice should write a libnss
based version someday.

i'd mark this "won't fix." :)

-Greg

On Tue, Apr 5, 2011 at 7:02 AM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Why on Earth would you want to serialize a hashlib object?
> It makes as much sense as serializing, say, a JSONEncoder.
>
> ----------
> nosy: +gregory.p.smith, pitrou
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue11771>
> _______________________________________
>

----------

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

From report at bugs.python.org  Thu Apr  7 08:17:49 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 07 Apr 2011 06:17:49 +0000
Subject: [issue11771] hashlib object cannot be pickled
In-Reply-To: <1302004182.5.0.155912208324.issue11771@psf.upfronthosting.co.za>
Message-ID: <1302157069.25.0.89212717279.issue11771@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I also recommend closing this one.

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

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

From report at bugs.python.org  Thu Apr  7 08:30:45 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 07 Apr 2011 06:30:45 +0000
Subject: [issue11715] Building Python on multiarch Debian and Ubuntu
In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za>
Message-ID: <1302157845.79.0.755367013796.issue11715@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The FreeBSD and Solaris bots are failing:

dpkg-architecture: not found
error: build/temp.freebsd-8.2-RELEASE-amd64-3.3-pydebug/multiarch: No such file or directory
[62607 refs]
*** Error code 1


find_executable.patch should solve the problem.

----------
Added file: http://bugs.python.org/file21558/find_executable.patch

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

From report at bugs.python.org  Thu Apr  7 09:12:51 2011
From: report at bugs.python.org (Devin Jeanpierre)
Date: Thu, 07 Apr 2011 07:12:51 +0000
Subject: [issue11791] python -m doctest has a -v flag that it ignores
In-Reply-To: <1302160371.62.0.724682728561.issue11791@psf.upfronthosting.co.za>
Message-ID: <1302160371.62.0.724682728561.issue11791@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre <jeanpierreda at gmail.com>:

The usage string details a -v option, but python -m doctest doesn't use a -v option.

The attached patch adds that.

----------
files: doctest_verbosity.diff
keywords: patch
messages: 133195
nosy: Devin Jeanpierre
priority: normal
severity: normal
status: open
title: python -m doctest has a -v flag that it ignores
versions: Python 3.2
Added file: http://bugs.python.org/file21559/doctest_verbosity.diff

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

From report at bugs.python.org  Thu Apr  7 09:38:07 2011
From: report at bugs.python.org (ysj.ray)
Date: Thu, 07 Apr 2011 07:38:07 +0000
Subject: [issue11777] Executor.map does not submit futures until iter.next()
	is called
In-Reply-To: <1302052595.78.0.918161508373.issue11777@psf.upfronthosting.co.za>
Message-ID: <1302161887.0.0.772450609847.issue11777@psf.upfronthosting.co.za>


ysj.ray <ysj.ray at gmail.com> added the comment:

Got it. Seems the behavior is not consist with the Executor.map() function:

"The returned iterator raises a TimeoutError if __next__() is called and the result isn't available after timeout seconds from ***the original call to map()***"

----------

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

From report at bugs.python.org  Thu Apr  7 10:13:22 2011
From: report at bugs.python.org (Brian Quinlan)
Date: Thu, 07 Apr 2011 08:13:22 +0000
Subject: [issue11777] Executor.map does not submit futures until iter.next()
	is called
In-Reply-To: <1302052595.78.0.918161508373.issue11777@psf.upfronthosting.co.za>
Message-ID: <1302164002.39.0.603301595934.issue11777@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

Nice catch. I hadn't noticed that the docs are lying :-)

----------

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

From report at bugs.python.org  Thu Apr  7 10:17:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Apr 2011 08:17:54 +0000
Subject: [issue11771] hashlib object cannot be pickled
In-Reply-To: <1302004182.5.0.155912208324.issue11771@psf.upfronthosting.co.za>
Message-ID: <1302164274.65.0.129242879384.issue11771@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Thu Apr  7 10:22:27 2011
From: report at bugs.python.org (Samuele Kaplun)
Date: Thu, 07 Apr 2011 08:22:27 +0000
Subject: [issue11792] asyncore module print to stdout
In-Reply-To: <1302164547.51.0.00796675638599.issue11792@psf.upfronthosting.co.za>
Message-ID: <1302164547.51.0.00796675638599.issue11792@psf.upfronthosting.co.za>


New submission from Samuele Kaplun <Samuele.Kaplun at cern.ch>:

The method "log_info" of the "dispatcher" class of the asyncore.py module, uses print statement to print to stdout.

This lead to conflicts when asyncore is used within e.g. mod_wsgi, as writing to stdout is not supposed to be valid.

----------
components: Library (Lib)
messages: 133198
nosy: kaplun
priority: normal
severity: normal
status: open
title: asyncore module print to stdout
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Thu Apr  7 10:48:34 2011
From: report at bugs.python.org (chaos)
Date: Thu, 07 Apr 2011 08:48:34 +0000
Subject: [issue11793] raw strings
In-Reply-To: <1302166114.84.0.402815371871.issue11793@psf.upfronthosting.co.za>
Message-ID: <1302166114.84.0.402815371871.issue11793@psf.upfronthosting.co.za>


New submission from chaos <846909323 at qq.com>:

>>> print(r'\')
      
SyntaxError: EOL while scanning string literal
>>> print(r'\'')
\'
>>>

----------
messages: 133199
nosy: chaos
priority: normal
severity: normal
status: open
title: raw strings
type: compile error
versions: Python 3.2

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

From report at bugs.python.org  Thu Apr  7 10:58:02 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 07 Apr 2011 08:58:02 +0000
Subject: [issue11794] Backport new logging docs to 2.7
In-Reply-To: <1302166682.89.0.483892888748.issue11794@psf.upfronthosting.co.za>
Message-ID: <1302166682.89.0.483892888748.issue11794@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Vinay did some great work on the logging documentation for 3.2 (http://docs.python.org/py3k/library/logging).

However, a lot of people will currently miss it, since they land on the existing 2.7 documentation (http://docs.python.org/library/logging) instead.

A backport would update the web site immediately, and then be incorporated in the bundled documentation when 2.7.2 is released (presumably later this year).

Backporting should be relatively straightforward (since logging hasn't changed *that* much between 2.7 and 3.2), but isn't completely trivial (since details of the Python 3 only items will need to be removed and the "changed in" and "added in" notices will need to be updated to reflect the information in the existing 2.x series documentation)

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 133200
nosy: docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Backport new logging docs to 2.7
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr  7 11:13:49 2011
From: report at bugs.python.org (chaos)
Date: Thu, 07 Apr 2011 09:13:49 +0000
Subject: [issue11793] raw strings
In-Reply-To: <1302166114.84.0.402815371871.issue11793@psf.upfronthosting.co.za>
Message-ID: <1302167629.87.0.573784688744.issue11793@psf.upfronthosting.co.za>


chaos <846909323 at qq.com> added the comment:

I think it should be

    >>> print(r'\')
    \
    >>> print(r'\'')

    SyntaxError: EOL while scanning string literal
    >>>

----------

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

From report at bugs.python.org  Thu Apr  7 11:31:56 2011
From: report at bugs.python.org (Torsten Becker)
Date: Thu, 07 Apr 2011 09:31:56 +0000
Subject: [issue1690608] email.utils.formataddr() should be rfc2047 aware
In-Reply-To: <1302098678.09.0.771369044964.issue1690608@psf.upfronthosting.co.za>
Message-ID: <BANLkTikUDGLujrS0PujpNRUaDiJVw=6TMA@mail.gmail.com>


Torsten Becker <torsten.becker at gmail.com> added the comment:

Hi David, thank you for polishing up the patch and committing it. :)
I am glad I could help and I was actually about to ask you if you knew
any follow-up issues.  I'll definitely continue contributing as time
allows.  I did not submit the agreement yet, but I'll look into that
ASAP.

----------

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

From report at bugs.python.org  Thu Apr  7 11:36:48 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 07 Apr 2011 09:36:48 +0000
Subject: [issue11793] raw strings
In-Reply-To: <1302166114.84.0.402815371871.issue11793@psf.upfronthosting.co.za>
Message-ID: <1302169008.68.0.811353608243.issue11793@psf.upfronthosting.co.za>


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

This is by design and documented:
http://docs.python.org/reference/lexical_analysis.html

"""
String quotes can be escaped with a backslash, but the backslash remains in the string; for example, r"\"" is a valid string literal consisting of two characters: a backslash and a double quote; r"\" is not a valid string literal (even a raw string cannot end in an odd number of backslashes).
Specifically, a raw string cannot end in a single backslash (since the backslash would escape the following quote character). Note also that a single backslash followed by a newline is interpreted as those two characters as part of the string, not as a line continuation.
"""

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Thu Apr  7 11:45:44 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 07 Apr 2011 09:45:44 +0000
Subject: [issue11762] Ast doc: warning and version number
In-Reply-To: <1301933761.05.0.937546235723.issue11762@psf.upfronthosting.co.za>
Message-ID: <1302169544.26.0.210991607077.issue11762@psf.upfronthosting.co.za>


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

Sounds good to me, except for "Use *ast.__version__* to work across versions." which is not quite clear.

While talking about version numbers, we should probably also document *what changed* between those versions.

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Thu Apr  7 11:50:47 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 07 Apr 2011 09:50:47 +0000
Subject: [issue11789] Extend upon metaclass/type class documentation,
	here: zope.interface and usage of instances of classes as base classes
In-Reply-To: <1302126921.15.0.0291977163306.issue11789@psf.upfronthosting.co.za>
Message-ID: <1302169847.86.0.805690528451.issue11789@psf.upfronthosting.co.za>


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

This doesn't work as you show.  What you probably meant was something like this:

class InterfaceBase(type):
    ...

Interface = InterfaceBase('Interface', (), {})

class IFoo(Interface):
    ...


which you can just as well do by using normal metaclass syntax.

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Thu Apr  7 12:07:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Apr 2011 10:07:37 +0000
Subject: [issue11792] asyncore module print to stdout
In-Reply-To: <1302164547.51.0.00796675638599.issue11792@psf.upfronthosting.co.za>
Message-ID: <1302170857.02.0.946729943103.issue11792@psf.upfronthosting.co.za>


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


----------
assignee:  -> giampaolo.rodola
nosy: +giampaolo.rodola
stage:  -> needs patch
versions: +Python 3.2, Python 3.3 -Python 2.6

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

From report at bugs.python.org  Thu Apr  7 12:11:33 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 07 Apr 2011 10:11:33 +0000
Subject: [issue11792] asyncore module print to stdout
In-Reply-To: <1302164547.51.0.00796675638599.issue11792@psf.upfronthosting.co.za>
Message-ID: <1302171093.34.0.695811681169.issue11792@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

What change are you proposing exactly?
Btw, overriding log_info() in such cases seems reasonable to me, without changing anything in asyncore.

----------

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

From report at bugs.python.org  Thu Apr  7 12:20:44 2011
From: report at bugs.python.org (Velko Ivanov)
Date: Thu, 07 Apr 2011 10:20:44 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1302026797.61.0.376646596976.issue2736@psf.upfronthosting.co.za>
Message-ID: <4D9D8FFA.2040800@ivanov-nest.com>


Velko Ivanov <vivanov at ivanov-nest.com> added the comment:

On 04/05/2011 18:22, Alexander Belopolsky wrote:
> """
> The datetime module intended to be an island of relative sanity.
> ....... """ - Tim Peters

Refusing to cooperate with the rest of the world is not sane by my books.

On 04/05/2011 21:06, Alexander Belopolsky wrote:
> Converting datetime values to float is easy.   If your dt is a naive instance representing UTC time:
>
>     timestamp = (dt - datetime(1970, 1, 1)) / timedelta(seconds=1)
>
> If your dt is an aware instance:
>
>     timestamp = (dt - datetime(1970, 1, 1, tzinfo=timezone.utc)) / timedelta(seconds=1)

Please add these lines to the datetime module's documentation. In some 
central, well lit place. I believe that if nothing else, the whole 
discussion should have proved to you that there are many people looking 
for them.

OTOH a sinceepoch(epoch=datetime(1970,1,1)) method of the datetime class 
should be equally easy. Would be especially useful if few of the more 
frequently used EPOCHs are provided as constants.

----------

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

From report at bugs.python.org  Thu Apr  7 13:33:40 2011
From: report at bugs.python.org (Samuele Kaplun)
Date: Thu, 07 Apr 2011 11:33:40 +0000
Subject: [issue11792] asyncore module print to stdout
In-Reply-To: <1302164547.51.0.00796675638599.issue11792@psf.upfronthosting.co.za>
Message-ID: <1302176020.94.0.622054105047.issue11792@psf.upfronthosting.co.za>


Samuele Kaplun <Samuele.Kaplun at cern.ch> added the comment:

Thanks for looking into it.

Indeed that's the workaround I implemented in our application. On the other hand it would be nice if either:

* the log_info method would print to stderr,
* would use warning.warn()
* would use the logging module to allow for fine grained configuration

The 1st solution would be already enough for mod_wsgi usage (also see: <http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Writing_To_Standard_Output>)

Cheers!

----------

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

From report at bugs.python.org  Thu Apr  7 14:01:12 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 07 Apr 2011 12:01:12 +0000
Subject: [issue11792] asyncore module print to stdout
In-Reply-To: <1302164547.51.0.00796675638599.issue11792@psf.upfronthosting.co.za>
Message-ID: <1302177672.26.0.625764550813.issue11792@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

asyncore is a minimalistic and generic framework; as such it should not "privilege" a specific application such as mod_wsgi or make any other assumption.

I'd say it's fine to let user decide what to do in its own subclass.

Furthermore, log_info() is used by asyncore only to warn about events which are supposed to be handled by user via method overriding (e.g. handle_read()). It's not something you want wsgi or any other application except yours to be aware of.

----------

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

From report at bugs.python.org  Thu Apr  7 14:05:53 2011
From: report at bugs.python.org (chaos)
Date: Thu, 07 Apr 2011 12:05:53 +0000
Subject: [issue11793] raw strings
In-Reply-To: <1302166114.84.0.402815371871.issue11793@psf.upfronthosting.co.za>
Message-ID: <1302177953.2.0.414863174379.issue11793@psf.upfronthosting.co.za>


chaos <846909323 at qq.com> added the comment:

Sorry for my poor english and thank you for the answer.
Since I'm a perler, I think this is counterintuitive.
(In perl:
    print '\';  #print \
    print '\''; #error
    print "\""; #print "
    print "\";  #error
)

----------

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

From report at bugs.python.org  Thu Apr  7 14:23:51 2011
From: report at bugs.python.org (Samuele Kaplun)
Date: Thu, 07 Apr 2011 12:23:51 +0000
Subject: [issue11792] asyncore module print to stdout
In-Reply-To: <1302164547.51.0.00796675638599.issue11792@psf.upfronthosting.co.za>
Message-ID: <1302179031.43.0.252132178471.issue11792@psf.upfronthosting.co.za>


Samuele Kaplun <Samuele.Kaplun at cern.ch> added the comment:

Hi Giampaolo,

shouldn't then the 2nd option I was proposing (i.e. to call warning.warn) the best behavior, given your explanation?

[...]
Warning messages are typically issued in situations where it is useful to alert the user of some condition in a program, where that condition (normally) doesn?t warrant raising an exception and terminating the program. For example, one might want to issue a warning when a program uses an obsolete module.

Python programmers issue warnings by calling the warn() function defined in this module. (C programmers use PyErr_WarnEx(); see Exception Handling for details).
[...]

In this case asyncore might want raise a warning, since the client code of asyncore was expected to handle the event.

If the semantic of log_info is to basically alert the developer is there any particular benefit in printing directly to stdout rather than raising a warning (or simply printing to stderr)?

Ciao!

----------

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

From report at bugs.python.org  Thu Apr  7 14:47:06 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 07 Apr 2011 12:47:06 +0000
Subject: [issue11795] Better core dev guidelines for committing submitted
	patches
In-Reply-To: <1302180426.35.0.989064957004.issue11795@psf.upfronthosting.co.za>
Message-ID: <1302180426.35.0.989064957004.issue11795@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Based on a core-mentoring thread, a couple more points for:
http://docs.python.org/devguide/committing.html#handling-other-s-code

Attribution:
- add to Misc/ACKS if they aren't already there (and didn't add themselves in their patch)
- mention "Patch by <x>" in the NEWS entry and the checkin message*
- If I had to substantially change or fix a patch, I'll usually amend the acknowledgement to "Initial patch by <x>"

*(If I forget to say something in the checkin message, I generally don't worry about it - ACKS and NEWS are the important ones)

Contributor Licensing Agreements
- it's unlikely bug fixes will require a CLA unless they touch a *lot* of code
- new features often get into CLA-preferred territory, as the associated comments, docstrings and documentation are far more likely to reach a copyrightable standard
- for sprints, we now just collect CLAs as a matter of course, since there isn't any real inconvenience in doing so

----------
assignee: ncoghlan
components: Devguide
messages: 133212
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Better core dev guidelines for committing submitted patches

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

From report at bugs.python.org  Thu Apr  7 14:55:21 2011
From: report at bugs.python.org (Menno Smits)
Date: Thu, 07 Apr 2011 12:55:21 +0000
Subject: [issue11796] list and generator expressions in a class definition
	fail if expression condition refers to a class variable
In-Reply-To: <1302180921.17.0.22284518515.issue11796@psf.upfronthosting.co.za>
Message-ID: <1302180921.17.0.22284518515.issue11796@psf.upfronthosting.co.za>


New submission from Menno Smits <menno at freshfoo.com>:

A list comprehension or generator expression in a class definition fails with NameError if it has a condition that refers to another class variable. This doesn't occur if the class variable is used the "in" part of the expression.

The following works:

class Foo:
    x = range(3)
    y = [z for z in x]

but this doesn't:

class Foo:
    x = 3
    y = [z for z in range(5) if z < x]

The error reported is: NameError: global name 'x' is not defined

Both of these examples work in Python 2.

Issue3692 suggests that class variables can't be referred to inside list comprehensions and gen expressions inside class definitions and that this won't be fixed, but these examples show that it is possible to refer to an outside class variable depending on usage. This is inconsistent and confusing.

The Python 2 behaviour makes much more sense. I understand that we don't want list comprehensions to leak internal variables but they should still be able to pull names from outside scopes in a consistent way.

----------
components: Interpreter Core
messages: 133213
nosy: mjs0
priority: normal
severity: normal
status: open
title: list and generator expressions in a class definition fail if expression condition refers to a class variable
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Apr  7 14:56:22 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 07 Apr 2011 12:56:22 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1302180982.38.0.15182068209.issue6715@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea -Christophe Simonis

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

From report at bugs.python.org  Thu Apr  7 15:02:06 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 07 Apr 2011 13:02:06 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1302181326.58.0.163686015184.issue6715@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Having "Christophe Simonis" in the nosy list is precluding NOSY changes. I guess the space is causing problems. Should we forbid spaces in usernames (maybe provided by OpenID, who knows)???

What do we need to progress in this issue?.

A rewrite to use Python 3 IO facilities?.

----------

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

From report at bugs.python.org  Thu Apr  7 15:09:49 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 07 Apr 2011 13:09:49 +0000
Subject: [issue11571] Turtle window pops under the terminal on OSX
In-Reply-To: <1300287451.35.0.164099198094.issue11571@psf.upfronthosting.co.za>
Message-ID: <1302181789.46.0.910761437296.issue11571@psf.upfronthosting.co.za>


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

+1 on applying the patch. 

I can do so on Sunday but feel to apply the patch before that.

----------

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

From report at bugs.python.org  Thu Apr  7 15:10:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Apr 2011 13:10:15 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1302181326.58.0.163686015184.issue6715@psf.upfronthosting.co.za>
Message-ID: <1302181811.3630.3.camel@localhost.localdomain>


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

> Having "Christophe Simonis" in the nosy list is precluding NOSY
> changes. I guess the space is causing problems. Should we forbid
> spaces in usernames (maybe provided by OpenID, who knows)???

Please report this in the meta-tracker (link on the left).

> What do we need to progress in this issue?.
> 
> A rewrite to use Python 3 IO facilities?.

See Nadeem's recent work on the bz2 module.

----------

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

From report at bugs.python.org  Thu Apr  7 15:12:23 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 07 Apr 2011 13:12:23 +0000
Subject: [issue9670] Exceed Recursion Limit in Thread
In-Reply-To: <1282656201.3.0.572219885558.issue9670@psf.upfronthosting.co.za>
Message-ID: <1302181943.05.0.0534458649789.issue9670@psf.upfronthosting.co.za>


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

Running the test in a separate process is a good idea.

The patch should be fine and fixes a problem on OSX, if the buildbot for FreeBSD starts to complain we can always removing the #if that tests for that platform.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9670>
_______________________________________

From report at bugs.python.org  Thu Apr  7 15:20:27 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 07 Apr 2011 13:20:27 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
	(issue4274045)
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1302182427.03.0.508273349677.issue5863@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5863>
_______________________________________

From report at bugs.python.org  Thu Apr  7 15:20:42 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 07 Apr 2011 13:20:42 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1302182442.29.0.934792106441.issue10791@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10791>
_______________________________________

From report at bugs.python.org  Thu Apr  7 15:30:17 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 07 Apr 2011 13:30:17 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1302183017.05.0.872054770923.issue6715@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Reported to metatracker. Thanks for the kick :-).

As a reference, I think you are refering to #5863 and #10791. Pretty fine job, I must say.

Nadeem, what do you think?. Is xz in your list?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Thu Apr  7 16:32:53 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 07 Apr 2011 14:32:53 +0000
Subject: [issue11715] Building Python on multiarch Debian and Ubuntu
In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za>
Message-ID: <1302186773.88.0.355656290098.issue11715@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Stefan, thanks for the patch.  The problem is that on FreeBSD and Solaris, if the command fails, I/O redirection does not create the file, whereas on Linux and OS X it does.  So I was going to wrap the os.remove() of the temp file in a try/except.  But I like your patch better because it avoids the dpkg-architecture call in the first place on systems that don't have it, albeit at the cost of traversing $PATH.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11715>
_______________________________________

From report at bugs.python.org  Thu Apr  7 16:42:06 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 07 Apr 2011 14:42:06 +0000
Subject: [issue11795] Better core dev guidelines for committing submitted
	patches
In-Reply-To: <1302180426.35.0.989064957004.issue11795@psf.upfronthosting.co.za>
Message-ID: <1302187326.85.0.0572624802797.issue11795@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11795>
_______________________________________

From report at bugs.python.org  Thu Apr  7 16:48:42 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 07 Apr 2011 14:48:42 +0000
Subject: [issue11715] Building Python on multiarch Debian and Ubuntu
In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za>
Message-ID: <E1Q7qVl-00008I-1z@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c8738114b962 by Barry Warsaw in branch '3.1':
Refinement by Stefan Krah (see issue 11715, msg133194) to exit early if the
http://hg.python.org/cpython/rev/c8738114b962

New changeset 3d7c9b38fbfd by Barry Warsaw in branch '3.2':
Refinement by Stefan Krah (see issue 11715, msg133194) to exit early if the
http://hg.python.org/cpython/rev/3d7c9b38fbfd

New changeset bbfc65d05588 by Barry Warsaw in branch 'default':
Refinement by Stefan Krah (see issue 11715, msg133194) to exit early if the
http://hg.python.org/cpython/rev/bbfc65d05588

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11715>
_______________________________________

From report at bugs.python.org  Thu Apr  7 17:22:32 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 07 Apr 2011 15:22:32 +0000
Subject: [issue11700] mailbox.py proxy updates
In-Reply-To: <1302138766.28.0.0220049130326.issue11700@psf.upfronthosting.co.za>
Message-ID: <20110407152214.GA904@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

On Thu, Apr 07, 2011 at 01:12:46AM +0000, R. David Murray wrote:
> [...] should be sufficient.

It is sufficient to fix the resource warning.
Having a completely dynamic language is a nice thing.
I would not do it like that.

Instead i would even consider to provide at least ProxyFile 
publically (i.e. in I/O), because it is a nifty thing which may 
be useful for a number of applications. 
(PartialFile is probably too complicated in respect to SMP and FD 
sharing to be public as a generic (non-abstract) class.) 

I don't want to come up with a C++ lib again, but there Device-s 
are doubly-linked (spinlock protected), and each has a list of 
attached Stream-s, and upon program exit the list(s) is/are 
walked:

    open:
	"IO::Device::open(): already open!!%@"
		"\tI'll fail with Errno::ebusy now.%@"
    close:
	"IO::Device::close(): device *not* open!!%@"
		"\tThis may break non-debug enabled code...%@"
		"\tI'll fail with Errno::enodev now.%@"

	"IO::Device::close(): error occurred while closing one%@"
		"\tof the still attached streams!%@"
    ~Device:
	"IO::Device::~Device(): still isOpen()!%@"
		"\tEither subclass::close() does not call Device::close(),%@"
		"\tor it's destructor does not check the open state.%@"
		"\tI'll clean up anyway. Expect crashes soon.%@"

Stream somewhat likewhat.  The Issues #11767, #11466, #11701, to 
name a few, would never happen there if at least one test uses at 
least one of the involved classes once.

Now this is not true for Python's I/O, but i think that the 
interface should at least be complete and act as documented, 
so saying "file-like object" implies raising of ValueError if 
an object is closed etc. 
Even if the class is a somewhat hidden implementation detail. 

So of course hasattr() could be used instead of a special member 
to test for is_open().  (I hope it's slower than the latter.) 
There is no IOXY.open(), so, well, ok.

By the way, mailbox.py also has some other pitfalls as far as 
i remember; i think i've even seen calls to _lock_file() for 
a successful is_locked() (self._locked or so) state, which results 
in unlocking because of cleanup due to lock-taking failure; 
it was a shallow look only. 
(That is, because: rescue me from here!!!)

I'll attach 11700.yeah.diff, which inherits from RawIOBase; 
it's test adds some stuff naively. 
Note this is a few-hours hack in an area i haven't touched that 
much yet; it's a bit mysterious which I/O base class implements 
which functions or expects which function to be present in 
a subclass ...  And which raises what and when. 
That is - i would need to regulary review that at least once 
before i would ship that out for real. 
And i'll attach 11700.sigh.diff, which does only what is 
necessary, following your suggestions.

Now this: choose the right diff and i'll implement #11783. 
:)

----------
Added file: http://bugs.python.org/file21560/11700.yeah.diff
Added file: http://bugs.python.org/file21561/11700.sigh.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11700>
_______________________________________
-------------- next part --------------
diff --git a/Lib/mailbox.py b/Lib/mailbox.py
--- a/Lib/mailbox.py
+++ b/Lib/mailbox.py
@@ -1864,40 +1864,125 @@
     """Message with MMDF-specific properties."""
 
 
-class _ProxyFile:
-    """A read-only wrapper of a file."""
+class _ProxyFile(io.RawIOBase):
+    """A io.RawIOBase inheriting read-only wrapper for a seekable file.
+    It supports __iter__() and the context-manager protocol.
+    """
+    def __init__(self, file, pos=None):
+        """If pos is not None then the file will keep track of its position."""
+        self._file = file
+        self._pos = pos
+        self._trackpos = True if pos is not None else False
+        self._close = True
+        self._is_open = True
 
-    def __init__(self, f, pos=None):
-        """Initialize a _ProxyFile."""
-        self._file = f
-        if pos is None:
-            self._pos = f.tell()
+    def _set_noclose(self):
+        """Subclass hook - use to avoid closing internal file object."""
+        self._close = False
+
+    def _closed_check(self):
+        """Raise ValueError if not open."""
+        if not self._is_open:
+            raise ValueError('I/O operation on closed file')
+
+    def close(self):
+        if self._close:
+            self._close = False
+            self._file.close()
+            del self._file
+        self._is_open = False
+
+    @property
+    def closed(self):
+        return not self._is_open
+
+    def _write_check(self):
+        """Raises io.UnsupportedOperation."""
+        raise io.UnsupportedOperation('ProxyFile is readonly')
+
+    #def fileno(self):
+    def flush(self):
+        self._closed_check()
+        self._write_check()
+
+    #def isatty(self):
+
+    def _read(self, size, read_method, add_arg=None):
+        if size < 0:
+            size = -1
+        if self._trackpos:
+            self._file.seek(self._pos)
+        if not add_arg:
+            result = read_method(size)
         else:
-            self._pos = pos
+            result = read_method(size, add_arg)
+        if self._trackpos:
+            self._pos = self._file.tell()
+        return result
 
-    def read(self, size=None):
-        """Read bytes."""
-        return self._read(size, self._file.read)
+    def readable(self):
+        self._closed_check()
+        return self._file.readable()
 
-    def read1(self, size=None):
-        """Read bytes."""
-        return self._read(size, self._file.read1)
-
-    def readline(self, size=None):
-        """Read a line."""
+    def readline(self, size=-1):
+        self._closed_check()
         return self._read(size, self._file.readline)
 
-    def readlines(self, sizehint=None):
-        """Read multiple lines."""
+    def readlines(self, sizehint=-1):
         result = []
         for line in self:
             result.append(line)
-            if sizehint is not None:
+            if sizehint >= 0:
                 sizehint -= len(line)
                 if sizehint <= 0:
                     break
         return result
 
+    def read(self, size=-1):
+        self._closed_check()
+        return self._read(size, self._file.read)
+
+    #def readall(self):
+
+    def readinto(self, by_arr):
+        self._closed_check()
+        return self._read(len(by_arr), self._file.readinto, by_arr)
+
+    def seekable(self):
+        self._closed_check()
+        return True
+
+    def seek(self, offset, whence=0):
+        self._closed_check()
+        if whence == 1:
+            if not self._trackpos:
+                self._pos = self._file.tell()
+            self._file.seek(self._pos)
+        self._pos = self._file.seek(offset, whence)
+        return self._pos
+
+    def tell(self):
+        self._closed_check()
+        if not self._trackpos:
+            self._pos = self._file.tell()
+        return self._pos
+
+    def truncate(self, size=None):
+        self._closed_check()
+        self._write_check()
+
+    def writable(self):
+        self._closed_check()
+        return False
+
+    def writelines(self, lines):
+        self._closed_check()
+        self._write_check()
+
+    def write(self, by_arr):
+        self._closed_check()
+        self._write_check()
+
     def __iter__(self):
         """Iterate over lines."""
         while True:
@@ -1906,32 +1991,6 @@
                 raise StopIteration
             yield line
 
-    def tell(self):
-        """Return the position."""
-        return self._pos
-
-    def seek(self, offset, whence=0):
-        """Change position."""
-        if whence == 1:
-            self._file.seek(self._pos)
-        self._file.seek(offset, whence)
-        self._pos = self._file.tell()
-
-    def close(self):
-        """Close the file."""
-        if hasattr(self._file, 'close'):
-            self._file.close()
-        del self._file
-
-    def _read(self, size, read_method):
-        """Read size bytes using read_method."""
-        if size is None:
-            size = -1
-        self._file.seek(self._pos)
-        result = read_method(size)
-        self._pos = self._file.tell()
-        return result
-
     def __enter__(self):
         """Context manager protocol support."""
         return self
@@ -1939,29 +1998,16 @@
     def __exit__(self, *exc):
         self.close()
 
-    def readable(self):
-        return self._file.readable()
-
-    def writable(self):
-        return self._file.writable()
-
-    def seekable(self):
-        return self._file.seekable()
-
-    def flush(self):
-        return self._file.flush()
-
-    @property
-    def closed(self):
-        return self._file.closed
-
 
 class _PartialFile(_ProxyFile):
     """A read-only wrapper of part of a file."""
 
     def __init__(self, f, start=None, stop=None):
         """Initialize a _PartialFile."""
+        if start is None:
+            start = f.tell()
         _ProxyFile.__init__(self, f, start)
+        super()._set_noclose()
         self._start = start
         self._stop = stop
 
@@ -1971,6 +2017,7 @@
 
     def seek(self, offset, whence=0):
         """Change position, possibly with respect to start or stop."""
+        self._closed_check()
         if whence == 0:
             self._pos = self._start
             whence = 1
@@ -1988,11 +2035,6 @@
             size = remaining
         return _ProxyFile._read(self, size, read_method)
 
-    def close(self):
-        # do *not* close the underlying file object for partial files,
-        # since it's global to the mailbox object
-        del self._file
-
 
 def _lock_file(f, dotlock=True):
     """Lock file f using lockf and dot locking."""
diff --git a/Lib/test/test_mailbox.py b/Lib/test/test_mailbox.py
--- a/Lib/test/test_mailbox.py
+++ b/Lib/test/test_mailbox.py
@@ -290,12 +290,14 @@
         key1 = self._box.add(_sample_message)
         with self._box.get_file(key0) as file:
             data0 = file.read()
-        with self._box.get_file(key1) as file:
-            data1 = file.read()
+        file1 = self._box.get_file(key1)
+        data1 = file1.read()
         self.assertEqual(data0.decode('ascii').replace(os.linesep, '\n'),
                          self._template % 0)
         self.assertEqual(data1.decode('ascii').replace(os.linesep, '\n'),
                          _sample_message)
+        file1.close()
+        file1.close()
 
     def test_iterkeys(self):
         # Get keys using iterkeys()
@@ -1833,10 +1835,35 @@
         self.assertFalse(proxy.read())
 
     def _test_close(self, proxy):
-        # Close a file
+        self.assertFalse(proxy.closed)
+        self.assertTrue(proxy.seekable())
+        self.assertRaises(io.UnsupportedOperation, proxy.flush)
+        self.assertRaises(io.UnsupportedOperation, proxy.truncate, 0)
+        self.assertFalse(proxy.writable())
+        self.assertRaises(io.UnsupportedOperation, proxy.writelines, ['AU'])
+        self.assertRaises(io.UnsupportedOperation, proxy.write, 'AU')
+
         proxy.close()
-        self.assertRaises(AttributeError, lambda: proxy.close())
+        self.assertTrue(proxy.closed)
+        try:
+            proxy.close()
+        except:
+            self.fail('Proxy.close() failure')
 
+        self.assertRaises(ValueError, proxy.flush)
+        self.assertRaises(ValueError, proxy.readable)
+        self.assertRaises(ValueError, proxy.readline)
+        self.assertRaises(ValueError, proxy.readlines)
+        self.assertRaises(ValueError, proxy.read)
+        self.assertRaises(ValueError, proxy.readall)
+        self.assertRaises(ValueError, proxy.readinto, bytearray())
+        self.assertRaises(ValueError, proxy.seekable)
+        self.assertRaises(ValueError, proxy.seek, 0)
+        self.assertRaises(ValueError, proxy.tell)
+        self.assertRaises(ValueError, proxy.truncate)
+        self.assertRaises(ValueError, proxy.writable)
+        self.assertRaises(ValueError, proxy.writelines, ['AU'])
+        self.assertRaises(ValueError, proxy.write, 'AU')
 
 class TestProxyFile(TestProxyFileBase):
 
-------------- next part --------------
diff --git a/Lib/mailbox.py b/Lib/mailbox.py
--- a/Lib/mailbox.py
+++ b/Lib/mailbox.py
@@ -1919,9 +1919,9 @@
 
     def close(self):
         """Close the file."""
-        if hasattr(self._file, 'close'):
+        if hasattr(self, '_file'):
             self._file.close()
-        del self._file
+            del self._file
 
     def _read(self, size, read_method):
         """Read size bytes using read_method."""
@@ -1953,7 +1953,7 @@
 
     @property
     def closed(self):
-        return self._file.closed
+        return not hasattr(self, '_file')
 
 
 class _PartialFile(_ProxyFile):
@@ -1991,7 +1991,8 @@
     def close(self):
         # do *not* close the underlying file object for partial files,
         # since it's global to the mailbox object
-        del self._file
+        if hasattr(self, '_file'):
+            del self._file
 
 
 def _lock_file(f, dotlock=True):
diff --git a/Lib/test/test_mailbox.py b/Lib/test/test_mailbox.py
--- a/Lib/test/test_mailbox.py
+++ b/Lib/test/test_mailbox.py
@@ -1834,9 +1834,13 @@
 
     def _test_close(self, proxy):
         # Close a file
+        self.assertFalse(proxy.closed)
         proxy.close()
-        self.assertRaises(AttributeError, lambda: proxy.close())
-
+        self.assertTrue(proxy.closed)
+        try:
+            proxy.close()
+        except:
+            self.fail('Proxy.close() failure')
 
 class TestProxyFile(TestProxyFileBase):
 

From report at bugs.python.org  Thu Apr  7 17:28:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 07 Apr 2011 15:28:52 +0000
Subject: [issue11715] Building Python on multiarch Debian and Ubuntu
In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za>
Message-ID: <E1Q7r8c-000476-Me@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset bd0f73a9538e by Barry Warsaw in branch '2.7':
Backport for Python 2.7 of issue 11715 support for building Python on
http://hg.python.org/cpython/rev/bd0f73a9538e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11715>
_______________________________________

From report at bugs.python.org  Thu Apr  7 17:32:05 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 07 Apr 2011 15:32:05 +0000
Subject: [issue11715] Building Python on multiarch Debian and Ubuntu
In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za>
Message-ID: <1302190325.82.0.622347745094.issue11715@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11715>
_______________________________________

From report at bugs.python.org  Thu Apr  7 17:57:24 2011
From: report at bugs.python.org (Miki Tebeka)
Date: Thu, 07 Apr 2011 15:57:24 +0000
Subject: [issue11797] 2to3 does not correct "reload"
In-Reply-To: <1302191844.85.0.922084217825.issue11797@psf.upfronthosting.co.za>
Message-ID: <1302191844.85.0.922084217825.issue11797@psf.upfronthosting.co.za>


New submission from Miki Tebeka <miki.tebeka at gmail.com>:

The following code is not changed by 2to3::
    
    import os
    reload(os)

reload has moved to the imp module.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 133223
nosy: tebeka
priority: normal
severity: normal
status: open
title: 2to3 does not correct "reload"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11797>
_______________________________________

From report at bugs.python.org  Thu Apr  7 18:15:05 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 07 Apr 2011 16:15:05 +0000
Subject: [issue11797] 2to3 does not correct "reload"
In-Reply-To: <1302191844.85.0.922084217825.issue11797@psf.upfronthosting.co.za>
Message-ID: <1302192905.9.0.82845165283.issue11797@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This should get fixed, but I'm *really* curious about what kind of code actually needs to do this ;-)

----------
keywords: +easy
nosy: +rhettinger
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11797>
_______________________________________

From report at bugs.python.org  Thu Apr  7 18:15:57 2011
From: report at bugs.python.org (Fabio Zadrozny)
Date: Thu, 07 Apr 2011 16:15:57 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>


New submission from Fabio Zadrozny <fabioz at users.sourceforge.net>:

Right now, when doing a test case, one must clear all the variables created in the test class, and I believe this shouldn't be needed...

E.g.:

class Test(TestCase):
  def setUp(self):
    self.obj1 = MyObject()

  ...

  def tearDown(self):
    del self.obj1

Ideally (in my view), right after running the test, it should be garbage-collected and the explicit tearDown wouldn't be needed (as the test would garbage-collected, that reference would automatically die), because this is currently very error prone... (and probably a source of leaks for any sufficiently big test suite).

If that's accepted, I can provide a patch.

----------
components: Library (Lib)
messages: 133225
nosy: fabioz
priority: normal
severity: normal
status: open
title: Test cases not garbage collected after run
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Thu Apr  7 18:21:53 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 07 Apr 2011 16:21:53 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1302193313.44.0.286376061233.issue11798@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

You don't have to clear them; you just have to finalize them. Anyway, this is essentially impossible to do in a backward compatible way given that TestCases are expected to stay around.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Thu Apr  7 18:30:10 2011
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 07 Apr 2011 16:30:10 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1302193810.58.0.843982573405.issue11798@psf.upfronthosting.co.za>


Jean-Paul Calderone <invalid at example.invalid> added the comment:

Trial lets test cases get garbaged collected.  When we noticed this wasn't happening, we treated it as a bug and fixed it.  No one ever complained about the change.  I don't see any obvious way in which an application would even be able to tell the difference (a user can tell the difference by looking at top).  In what case do you think this change would result in broken application code?

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Thu Apr  7 18:34:12 2011
From: report at bugs.python.org (Fabio Zadrozny)
Date: Thu, 07 Apr 2011 16:34:12 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1302194052.36.0.358533611817.issue11798@psf.upfronthosting.co.za>


Fabio Zadrozny <fabioz at users.sourceforge.net> added the comment:

I do get the idea of the backward incompatibility, although I think it's really minor in this case.

Just for some data, the pydev test runner has had a fix to clear those test cases for quite a while already and no one has complained about it (it actually makes each of the tests None after run, so, if someone tries to access it after that, it would be pretty clear that it's not there anymore).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Thu Apr  7 18:41:30 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 07 Apr 2011 16:41:30 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302193810.58.0.843982573405.issue11798@psf.upfronthosting.co.za>
Message-ID: <BANLkTikhhV5yGCZ--azSxe0h+5pWAxigEw@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/4/7 Jean-Paul Calderone <report at bugs.python.org>:
>
> Jean-Paul Calderone <invalid at example.invalid> added the comment:
>
> Trial lets test cases get garbaged collected. ?When we noticed this wasn't happening, we treated it as a bug and fixed it. ?No one ever complained about the change. ?I don't see any obvious way in which an application would even be able to tell the difference (a user can tell the difference by looking at top). ?In what case do you think this change would result in broken application code?

I thought unittest was just handed a bunch of TestCase instances and
couldn't do much about insuring they were garbage collected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Thu Apr  7 18:41:52 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 Apr 2011 16:41:52 +0000
Subject: [issue11700] mailbox.py proxy updates
In-Reply-To: <1301315190.34.0.276151285444.issue11700@psf.upfronthosting.co.za>
Message-ID: <1302194512.48.0.667616632922.issue11700@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't understand what you are saying about raising a ValueError on close.  f = open('x'); f.close(); f.close() does not raise any error, as Amaury pointed out.

So I still don't understand the motivation for a more complex fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11700>
_______________________________________

From report at bugs.python.org  Thu Apr  7 18:43:50 2011
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 07 Apr 2011 16:43:50 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1302194630.9.0.113155258335.issue11798@psf.upfronthosting.co.za>


Jean-Paul Calderone <invalid at example.invalid> added the comment:

> I thought unittest was just handed a bunch of TestCase instances and couldn't do much about insuring they were garbage collected.

True.  But unittest could ensure that it doesn't keep a reference to each TestCase instance after it finishes running it.  Then, if no one else has a reference either, it can be garbage collected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Thu Apr  7 18:50:51 2011
From: report at bugs.python.org (Michael Foord)
Date: Thu, 07 Apr 2011 16:50:51 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1302195051.17.0.814087508081.issue11798@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

A TestSuite (which is how tests are collected to run) holds all the tests and therefore keeps them all alive for the duration of the test run. (I presume this is the issue anyway.)

How would you solve this - by having calling a TestSuite (which is how a test run is executed) remove members from themselves after each test execution? (Any failure tracebacks etc stored by the TestResult would also have to not keep the test alive.)

My only concern would be backwards compatibility due to the change in behaviour.

----------
assignee:  -> michael.foord
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Thu Apr  7 18:51:14 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 07 Apr 2011 16:51:14 +0000
Subject: [issue11795] Better core dev guidelines for committing submitted
	patches
In-Reply-To: <1302180426.35.0.989064957004.issue11795@psf.upfronthosting.co.za>
Message-ID: <1302195074.51.0.092648451652.issue11795@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11795>
_______________________________________

From report at bugs.python.org  Thu Apr  7 18:53:01 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 07 Apr 2011 16:53:01 +0000
Subject: [issue11734] Add half-float (16-bit) support to struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1302195181.74.0.345515610901.issue11734@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11734>
_______________________________________

From report at bugs.python.org  Thu Apr  7 18:56:24 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 Apr 2011 16:56:24 +0000
Subject: [issue11492] email.header.Header doesn't fold headers at spaces if
	value contains '; 's
In-Reply-To: <1300087978.39.0.703069545984.issue11492@psf.upfronthosting.co.za>
Message-ID: <1302195384.14.0.63721501656.issue11492@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK, it looks like the wrapping problem arises when the line contains runs of blank delimited tokens longer than maxlinelen *and* the line also contains ';'s.  The line is then split at the ';' and the remaining overlong pieces are not split.

I'll work on a fix.

----------
stage: committed/rejected -> needs patch
title: email.header.Header doesn't fold headers at spaces -> email.header.Header doesn't fold headers at spaces if value contains ';'s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11492>
_______________________________________

From report at bugs.python.org  Thu Apr  7 19:03:51 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 07 Apr 2011 17:03:51 +0000
Subject: [issue11571] Turtle window pops under the terminal on OSX
In-Reply-To: <1300287451.35.0.164099198094.issue11571@psf.upfronthosting.co.za>
Message-ID: <1302195831.64.0.466771675243.issue11571@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

While you are at it, can you also fix the same issue with "python -m tkinter"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11571>
_______________________________________

From report at bugs.python.org  Thu Apr  7 19:04:48 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 07 Apr 2011 17:04:48 +0000
Subject: [issue11571] Turtle window pops under the terminal on OSX
In-Reply-To: <1300287451.35.0.164099198094.issue11571@psf.upfronthosting.co.za>
Message-ID: <1302195888.65.0.190506281957.issue11571@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

.. and "python -m turtledemo"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11571>
_______________________________________

From report at bugs.python.org  Thu Apr  7 19:11:42 2011
From: report at bugs.python.org (Fabio Zadrozny)
Date: Thu, 07 Apr 2011 17:11:42 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1302196302.8.0.705512619463.issue11798@psf.upfronthosting.co.za>


Fabio Zadrozny <fabioz at users.sourceforge.net> added the comment:

The current code I use in PyDev is below -- another option could be not adding the None to the list of tests, but removing it, but I find that a bit worse because in the current way if someone tries to access it after it's ran, it'll become clear it was removed.

def run(self, result):
    for index, test in enumerate(self._tests):
        if result.shouldStop:
            break
        test(result)

        # Let the memory be released! 
        self._tests[index] = None

    return result
    
    
I think the issue with the test result storing the test is much more difficult to deal with (because currently most unit test frameworks probably rely on having it there), so, that's probably not something I'd try to fix as it'd probably break many clients... in which case it should be expected that the test is kept alive if it fails -- but as the idea is that all has to turn green anyways, I don't see this as a big issue :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Thu Apr  7 19:16:03 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 07 Apr 2011 17:16:03 +0000
Subject: [issue11571] Turtle window pops under the terminal on OSX
In-Reply-To: <1300287451.35.0.164099198094.issue11571@psf.upfronthosting.co.za>
Message-ID: <1302196563.77.0.826188774844.issue11571@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11571>
_______________________________________

From report at bugs.python.org  Thu Apr  7 19:20:47 2011
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 07 Apr 2011 17:20:47 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1302196847.21.0.267094016623.issue11798@psf.upfronthosting.co.za>


Jean-Paul Calderone <invalid at example.invalid> added the comment:

Here's Trial's implementation: http://twistedmatrix.com/trac/browser/trunk/twisted/trial/runner.py#L138

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Thu Apr  7 19:27:22 2011
From: report at bugs.python.org (Justin Love)
Date: Thu, 07 Apr 2011 17:27:22 +0000
Subject: [issue11751] Increase distutils.filelist test coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <1302197242.02.0.996154324181.issue11751@psf.upfronthosting.co.za>


Justin Love <python at JustinLove.name> added the comment:

Removed NO COVER

Combined test_translate_pattern

Added on to some test names to make them more descriptive

----------
Added file: http://bugs.python.org/file21562/increase_distutils_filelist_test_coverage_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11751>
_______________________________________

From report at bugs.python.org  Thu Apr  7 19:27:48 2011
From: report at bugs.python.org (Michael Foord)
Date: Thu, 07 Apr 2011 17:27:48 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1302197268.04.0.981659004339.issue11798@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Not keeping tests alive for the whole run seems like a good thing and either implementation seems fine to me. I'd be interested to hear if anyone else had any backwards compatibility concerns though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Thu Apr  7 19:33:23 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 07 Apr 2011 17:33:23 +0000
Subject: [issue11795] Better core dev guidelines for committing submitted
	patches
In-Reply-To: <1302180426.35.0.989064957004.issue11795@psf.upfronthosting.co.za>
Message-ID: <1302197603.93.0.411636773001.issue11795@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I had some of the same questions, so I agree this would be a good addition.

----------
nosy: +terry.reedy
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11795>
_______________________________________

From report at bugs.python.org  Thu Apr  7 19:48:20 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 07 Apr 2011 17:48:20 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1302198500.22.0.366983661334.issue11798@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Not keeping tests alive for the whole run seems like a
> good thing 

+1

> and either implementation seems fine to me.

I slightly prefer Fabio;s assignment to None approach (for subtle reasons that I can't articulate at the moment).

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Thu Apr  7 19:51:17 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 Apr 2011 17:51:17 +0000
Subject: [issue11492] email.header.Header doesn't fold headers correctly
In-Reply-To: <1300087978.39.0.703069545984.issue11492@psf.upfronthosting.co.za>
Message-ID: <1302198677.57.0.889270289153.issue11492@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here is a patch containing three test cases that demonstrate three different failings of the header folding algorithm.  I'm working on the fix, but it is non-trivial.

----------
components: +Library (Lib) -None
keywords: +patch
title: email.header.Header doesn't fold headers at spaces if value contains ';'s -> email.header.Header doesn't fold headers correctly
Added file: http://bugs.python.org/file21563/header_folding_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11492>
_______________________________________

From report at bugs.python.org  Thu Apr  7 19:53:40 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 Apr 2011 17:53:40 +0000
Subject: [issue11492] email.header.Header doesn't fold headers correctly
In-Reply-To: <1300087978.39.0.703069545984.issue11492@psf.upfronthosting.co.za>
Message-ID: <1302198820.32.0.637124417314.issue11492@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file21563/header_folding_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11492>
_______________________________________

From report at bugs.python.org  Thu Apr  7 19:57:03 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 Apr 2011 17:57:03 +0000
Subject: [issue11492] email.header.Header doesn't fold headers correctly
In-Reply-To: <1300087978.39.0.703069545984.issue11492@psf.upfronthosting.co.za>
Message-ID: <1302199023.84.0.683826639436.issue11492@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Note that 2.7 fails two of these tests as well, but for different reasons.  I'm not currently planning to fix 2.7, as its behavior at least (a) doesn't lose non-whitespace information and (b) doesn't exceed the maxheaderlen.

----------
Added file: http://bugs.python.org/file21564/header_folding_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11492>
_______________________________________

From report at bugs.python.org  Thu Apr  7 20:20:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 07 Apr 2011 18:20:14 +0000
Subject: [issue6040] bdist_msi does not deal with pre-release version
In-Reply-To: <1242472106.67.0.523299229524.issue6040@psf.upfronthosting.co.za>
Message-ID: <1302200414.02.0.166944149901.issue6040@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

To keep this focused, we should first try to make a test and patch for the stdlib, then discuss a recipe to work around the bug in unfixed versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6040>
_______________________________________

From report at bugs.python.org  Thu Apr  7 20:32:02 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 07 Apr 2011 18:32:02 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <4D9D8FFA.2040800@ivanov-nest.com>
Message-ID: <BANLkTinDgP0f2ZozvEj2nzkOsoyUmtBH+Q@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Apr 7, 2011 at 6:20 AM, Velko Ivanov <report at bugs.python.org> wrote:
..
>> Converting datetime values to float is easy. ?? If your dt is a naive instance representing UTC time:
>>
>> ?? ?? timestamp = (dt - datetime(1970, 1, 1)) / timedelta(seconds=1)
>>
>> If your dt is an aware instance:
>>
>> ?? ?? timestamp = (dt - datetime(1970, 1, 1, tzinfo=timezone.utc)) / timedelta(seconds=1)
>
> Please add these lines to the datetime module's documentation. In some
> central, well lit place. I believe that if nothing else, the whole
> discussion should have proved to you that there are many people looking
> for them.

This is precisely what I suggested at the end of msg132697 above.  See
attached patch (issue2736-doc.diff) for a proposed documentation
enhancement.

----------
Added file: http://bugs.python.org/file21565/issue2736-doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________
-------------- next part --------------
diff --git a/Doc/library/datetime.rst b/Doc/library/datetime.rst
--- a/Doc/library/datetime.rst
+++ b/Doc/library/datetime.rst
@@ -720,6 +720,22 @@
    out of the range of values supported by the platform C :c:func:`gmtime` function.
    It's common for this to be restricted to years in 1970 through 2038. See also
    :meth:`fromtimestamp`.
+
+   On the POSIX compliant platforms, ``utcfromtimestamp(timestamp)``
+   is equivalent to the following expression::
+
+     datetime(1970, 1, 1) + timedelta(seconds=timestamp)
+
+   There is no method to obtain the timestamp from a :class:`datetime`
+   instance, but POSIX timestamp corresponding to a :class:`datetime`
+   instance ``dt`` can be easily calculated as follows.  For a naive
+   ``dt``::
+
+      timestamp = (dt - datetime(1970, 1, 1)) / timedelta(seconds=1)
+
+   And for an aware ``dt``::
+
+      timestamp = (dt - datetime(1970, 1, 1, tzinfo=timezone.utc)) / timedelta(seconds=1)
 
 
 .. classmethod:: datetime.fromordinal(ordinal)

From report at bugs.python.org  Thu Apr  7 20:33:49 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 07 Apr 2011 18:33:49 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1302201229.3.0.739706563453.issue11798@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/issue11798>
_______________________________________

From report at bugs.python.org  Thu Apr  7 21:14:53 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Thu, 07 Apr 2011 19:14:53 +0000
Subject: [issue11757] test_subprocess.test_communicate_timeout_large_ouput
	failure on select(): negative timeout?
In-Reply-To: <E1Q74F2-00025q-GA@dinsdale.python.org>
Message-ID: <BANLkTik06F=qCdwwV3t0HcUsx8OmgnZZaw@mail.gmail.com>


Charles-Francois Natali <neologix at free.fr> added the comment:

It seems to have fixed the failure, no ?
I don't know what's the policy regarding syscall parameters check, but
I think it'd be better to check that the timeout passed to select is
not negative, and raise an exception otherwise, instead of silently
storing it into struct timeval (with an overflow) before passing it to
select.
Attached is a patch + test that does just that.

----------
keywords: +patch
Added file: http://bugs.python.org/file21566/select_negative_timeout.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11757>
_______________________________________
-------------- next part --------------
diff -r bbfc65d05588 Lib/test/test_select.py
--- a/Lib/test/test_select.py	Thu Apr 07 10:48:29 2011 -0400
+++ b/Lib/test/test_select.py	Thu Apr 07 21:06:59 2011 +0200
@@ -20,6 +20,7 @@
         self.assertRaises(TypeError, select.select, [self.Nope()], [], [])
         self.assertRaises(TypeError, select.select, [self.Almost()], [], [])
         self.assertRaises(TypeError, select.select, [], [], [], "not a number")
+        self.assertRaises(ValueError, select.select, [], [], [], -1)
 
     def test_returned_list_identity(self):
         # See issue #8329
diff -r bbfc65d05588 Modules/selectmodule.c
--- a/Modules/selectmodule.c	Thu Apr 07 10:48:29 2011 -0400
+++ b/Modules/selectmodule.c	Thu Apr 07 21:06:59 2011 +0200
@@ -234,6 +234,11 @@
                             "timeout period too long");
             return NULL;
         }
+        if (timeout < 0) {
+            PyErr_SetString(PyExc_ValueError,
+                        "timeout must be non-negative");
+            return NULL;
+        }
         seconds = (long)timeout;
         timeout = timeout - (double)seconds;
         tv.tv_sec = seconds;

From report at bugs.python.org  Thu Apr  7 21:27:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 07 Apr 2011 19:27:26 +0000
Subject: [issue7311] Bug on regexp of HTMLParser
In-Reply-To: <1258043150.41.0.372876851796.issue7311@psf.upfronthosting.co.za>
Message-ID: <E1Q7urT-0000YX-2D@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 225400cb6e84 by Ezio Melotti in branch '3.2':
#7311: fix html.parser to accept non-ASCII attribute values.
http://hg.python.org/cpython/rev/225400cb6e84

New changeset a1dea7cde58f by Ezio Melotti in branch 'default':
#7311: merge with 3.2.
http://hg.python.org/cpython/rev/a1dea7cde58f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7311>
_______________________________________

From report at bugs.python.org  Thu Apr  7 21:29:03 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 07 Apr 2011 19:29:03 +0000
Subject: [issue7311] Bug on regexp of HTMLParser
In-Reply-To: <1258043150.41.0.372876851796.issue7311@psf.upfronthosting.co.za>
Message-ID: <1302204543.81.0.0320398060326.issue7311@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7311>
_______________________________________

From report at bugs.python.org  Thu Apr  7 21:32:50 2011
From: report at bugs.python.org (Yuval Greenfield)
Date: Thu, 07 Apr 2011 19:32:50 +0000
Subject: [issue11799] urllib HTTP authentication behavior with unrecognized
	auth method
In-Reply-To: <1302204770.2.0.571328195993.issue11799@psf.upfronthosting.co.za>
Message-ID: <1302204770.2.0.571328195993.issue11799@psf.upfronthosting.co.za>


New submission from Yuval Greenfield <ubershmekel at gmail.com>:

When trying to use urllib to open a page from a server with NTLM authentication python raises urllib.error.HTTPError: HTTP Error 401: Unauthorized

A python 3 code example: http://codepad.org/axPomYHw

This was a bit confusing for me as I had to debug urllib to figure out python doesn't support NTLM. I'd expect python to tell me the authentication method isn't supported in such cases.

I didn't add a test for the attached patch as it doesn't seem test-worthy.

----------
components: Library (Lib)
files: urllib.auth.patch
keywords: patch
messages: 133248
nosy: ubershmekel
priority: normal
severity: normal
status: open
title: urllib HTTP authentication behavior with unrecognized auth method
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file21567/urllib.auth.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11799>
_______________________________________

From report at bugs.python.org  Thu Apr  7 21:39:56 2011
From: report at bugs.python.org (Laurie Clark-Michalek)
Date: Thu, 07 Apr 2011 19:39:56 +0000
Subject: [issue11797] 2to3 does not correct "reload"
In-Reply-To: <1302191844.85.0.922084217825.issue11797@psf.upfronthosting.co.za>
Message-ID: <1302205196.08.0.209677431379.issue11797@psf.upfronthosting.co.za>


Laurie Clark-Michalek <bluepeppers at archlinux.us> added the comment:

Find a fixer for this attached. I really just did sed 's/intern/reload' fix_intern.py >fix_reload.py, but it seems to work. I didn't write any tests (I couldn't seem to find any for any other fixers).

----------
keywords: +patch
nosy: +BluePeppers
Added file: http://bugs.python.org/file21568/fix_reload.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11797>
_______________________________________

From report at bugs.python.org  Thu Apr  7 21:56:22 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 07 Apr 2011 19:56:22 +0000
Subject: [issue1475397] time.asctime_tz, time.strftime %z %C
Message-ID: <1302206182.67.0.0103122082308.issue1475397@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
dependencies:  -Add aware local time support to datetime module
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1475397>
_______________________________________

From report at bugs.python.org  Thu Apr  7 22:03:22 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Thu, 07 Apr 2011 20:03:22 +0000
Subject: [issue11767] Maildir iterator leaks file descriptors by default
In-Reply-To: <1301958670.39.0.218079408331.issue11767@psf.upfronthosting.co.za>
Message-ID: <1302206602.68.0.852641593087.issue11767@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Here is a new patch, that uses with in __getitem__. I wonder, if we shouldn't check for an AttributeError in case object returned by get_file doesn't have __exit__ method, but does have close and use close instead of with. But it's for you to decide, as I am very fresh to with statement.

----------
Added file: http://bugs.python.org/file21569/11767_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11767>
_______________________________________

From report at bugs.python.org  Thu Apr  7 22:09:17 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 07 Apr 2011 20:09:17 +0000
Subject: [issue11791] python -m doctest has a -v flag that it ignores
In-Reply-To: <1302160371.62.0.724682728561.issue11791@psf.upfronthosting.co.za>
Message-ID: <1302206957.95.0.599440521942.issue11791@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Why do you say "doctest doesn't use a -v option"?

Compare

$ python -m doctest Lib/doctest.py 

and

$ python -m doctest -v Lib/doctest.py 
Trying:
    runner = DebugRunner(verbose=False)
Expecting nothing
ok
...
66 tests in 112 items.
66 passed and 0 failed.
Test passed.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11791>
_______________________________________

From report at bugs.python.org  Thu Apr  7 22:26:48 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 07 Apr 2011 20:26:48 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1302208008.35.0.281625497321.issue3754@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Uhh after some pseudo multiarch improvements previous patch fail. So new one is uploaded.
Also with this version cross-build won't build pgen$(EXEEXT).

----------
Added file: http://bugs.python.org/file21570/python-py3k-20110407-CROSS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Thu Apr  7 22:27:47 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 07 Apr 2011 20:27:47 +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: <1302208067.22.0.38269121308.issue3871@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Follow up updated patch to #3754

----------
Added file: http://bugs.python.org/file21571/python-py3k-20110407-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Thu Apr  7 22:39:04 2011
From: report at bugs.python.org (Miki Tebeka)
Date: Thu, 07 Apr 2011 20:39:04 +0000
Subject: [issue11797] 2to3 does not correct "reload"
In-Reply-To: <1302191844.85.0.922084217825.issue11797@psf.upfronthosting.co.za>
Message-ID: <1302208744.27.0.674686058696.issue11797@psf.upfronthosting.co.za>


Miki Tebeka <miki.tebeka at gmail.com> added the comment:

Raymond: Sometimes I store configuration in Python files and would like to reload the configuration.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11797>
_______________________________________

From report at bugs.python.org  Thu Apr  7 22:41:54 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 07 Apr 2011 20:41:54 +0000
Subject: [issue11700] mailbox.py proxy updates
In-Reply-To: <1302194512.48.0.667616632922.issue11700@psf.upfronthosting.co.za>
Message-ID: <20110407204144.GC85782@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

On Thu, Apr 07, 2011 at 04:41:52PM +0000, R. David Murray wrote:
> 
> R. David Murray <rdmurray at bitdance.com> added the comment:
> 
> I don't understand what you are saying about raising a ValueError on close.
> f = open('x'); f.close(); f.close() does not raise any error, as Amaury pointed out.
> 
> So I still don't understand the motivation for a more complex fix.

Now i've indeed looked into io.rst and i've found this:

:class:`IOBase` provides these data attributes and methods:

.. method:: close()

  Flush and close this stream. This method has no effect if the file is
  [Mojo Risin', gotta Mojo Risin']
  already closed. Once the file is closed, any operation on the file
  (e.g. reading or writing) will raise a :exc:`ValueError`.
  [I gotta, wooo, yeah, risin']
  As a convenience, it is allowed to call this method more than once;
  only the first call, however, will have an effect.

And a minute ago i've also done this:

...     def __init__(self):
...             pass
... 
>>> dir(y)

and i've found out that i should have done that first, but i'm 
still surprised how easy Python is - 'am waiting for 
'as -o mb.o mailbox.py' to produce nice x86 pseudo machine code??

So i will reimplement yeah.diff even more fancy tomorrow, 
and (urgh!) add more tests for the new input functions. 
(I'll continue to discontinue support for read1().) 
That's what i will do.
Good night.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11700>
_______________________________________

From report at bugs.python.org  Thu Apr  7 22:49:38 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 Apr 2011 20:49:38 +0000
Subject: [issue11767] Maildir iterator leaks file descriptors by default
In-Reply-To: <1301958670.39.0.218079408331.issue11767@psf.upfronthosting.co.za>
Message-ID: <1302209378.87.0.12060345468.issue11767@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, that's exactly why I suggested using the 'closing' context manager from contextlib.  That context manager returns the object passed to it, and then when its __exit__ method is called, calls the close method of that object that was passed to it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11767>
_______________________________________

From report at bugs.python.org  Thu Apr  7 22:59:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Apr 2011 20:59:29 +0000
Subject: [issue11768] test_signals() of test_threadsignals failure on Mac OS X
In-Reply-To: <1301962757.99.0.598461435574.issue11768@psf.upfronthosting.co.za>
Message-ID: <1302209969.21.0.732568549612.issue11768@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The failure occurs also on Leopard:
----------------------
[159/354] test_threadsignals
Thread 0x00007fff7080f700:
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/test/test_threadsignals.py", line 53 in test_signals
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/unittest/case.py", line 442 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/unittest/case.py", line 494 in __call__
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/test/support.py", line 1078 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/test/support.py", line 1166 in _run_suite
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/test/support.py", line 1192 in run_unittest
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/test/test_threadsignals.py", line 218 in test_main
  File "./Lib/test/regrtest.py", line 1032 in runtest_inner
  File "./Lib/test/regrtest.py", line 826 in runtest
  File "./Lib/test/regrtest.py", line 650 in main
  File "./Lib/test/regrtest.py", line 1607 in <module>
make: *** [buildbottest] Error 1
program finished with exit code 2
elapsedTime=3089.949146
----------------------
http://www.python.org/dev/buildbot/all/builders/AMD64%20Leopard%203.x/builds/1132/steps/test/logs/stdio

Even with d14eac872a46, this trace doesn't give more information :-/ Should I flush manually sys.stderr?

----------
title: test_signals() of test_threadsignals failure on Mac OS X Tiger -> test_signals() of test_threadsignals failure on Mac OS X

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11768>
_______________________________________

From report at bugs.python.org  Thu Apr  7 23:01:05 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 07 Apr 2011 21:01:05 +0000
Subject: [issue11797] 2to3 does not correct "reload"
In-Reply-To: <1302191844.85.0.922084217825.issue11797@psf.upfronthosting.co.za>
Message-ID: <1302210065.87.0.404416938277.issue11797@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Miki:  That's a really great use case.  Thanks.

----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11797>
_______________________________________

From report at bugs.python.org  Thu Apr  7 23:05:16 2011
From: report at bugs.python.org (Devin Jeanpierre)
Date: Thu, 07 Apr 2011 21:05:16 +0000
Subject: [issue11791] python -m doctest has a -v flag that it ignores
In-Reply-To: <1302160371.62.0.724682728561.issue11791@psf.upfronthosting.co.za>
Message-ID: <1302210316.63.0.0374953965792.issue11791@psf.upfronthosting.co.za>


Devin Jeanpierre <jeanpierreda at gmail.com> added the comment:

*Sigh*, I'm just confused. Sorry, must have screwed up what I passed as verbose somewhere, so that it didn't check sys.argv.

----------
resolution:  -> invalid
status: open -> closed
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11791>
_______________________________________

From report at bugs.python.org  Thu Apr  7 23:14:28 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Thu, 07 Apr 2011 21:14:28 +0000
Subject: [issue11767] Maildir iterator leaks file descriptors by default
In-Reply-To: <1301958670.39.0.218079408331.issue11767@psf.upfronthosting.co.za>
Message-ID: <1302210868.35.0.993781826786.issue11767@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I am sorry. This is the first time I see contextlib and haven't understood, that I should use a function from it. Here is a version with mock object having close method and __getitem__ using contextlib.closing.

----------
Added file: http://bugs.python.org/file21572/11767_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11767>
_______________________________________

From report at bugs.python.org  Thu Apr  7 23:16:21 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 07 Apr 2011 21:16:21 +0000
Subject: [issue11757] test_subprocess.test_communicate_timeout_large_ouput
	failure on select(): negative timeout?
In-Reply-To: <BANLkTik06F=qCdwwV3t0HcUsx8OmgnZZaw@mail.gmail.com>
Message-ID: <BANLkTimQ+7jyqyo=qtCeMMCvyDNgXCfzVA@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

Adding that check with an exception to selectmodule.c is a good idea.
i like your patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11757>
_______________________________________

From report at bugs.python.org  Thu Apr  7 23:18:29 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 07 Apr 2011 21:18:29 +0000
Subject: [issue11797] 2to3 does not correct "reload"
In-Reply-To: <1302191844.85.0.922084217825.issue11797@psf.upfronthosting.co.za>
Message-ID: <1302211109.89.0.319402831375.issue11797@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/issue11797>
_______________________________________

From report at bugs.python.org  Thu Apr  7 23:38:48 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 07 Apr 2011 21:38:48 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1302212328.98.0.94083513561.issue6715@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
nosy: +Christophe Simonis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Thu Apr  7 23:39:06 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 07 Apr 2011 21:39:06 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1302212346.19.0.428297091593.issue6715@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
nosy:  -georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Thu Apr  7 23:39:23 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 07 Apr 2011 21:39:23 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1302212363.5.0.175555002182.issue6715@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Thu Apr  7 23:54:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Apr 2011 21:54:54 +0000
Subject: [issue11800] regrtest --timeout: apply the timeout on a function,
	not on the whole file
In-Reply-To: <1302213294.05.0.908920520464.issue11800@psf.upfronthosting.co.za>
Message-ID: <1302213294.05.0.908920520464.issue11800@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

I added recently a --timeout option to regrtest.py: dump the traceback of all threads and exit if a test takes more than TIMEOUT seconds (issue #11727). But my implementation was not correct: the timeout is applied on the whole file, not on a single function. Attached patch fixes this issue.

----------
components: Tests
files: regrtest_timeout.patch
keywords: patch
messages: 133262
nosy: haypo
priority: normal
severity: normal
status: open
title: regrtest --timeout: apply the timeout on a function, not on the whole file
versions: Python 3.3
Added file: http://bugs.python.org/file21573/regrtest_timeout.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11800>
_______________________________________

From report at bugs.python.org  Thu Apr  7 23:55:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Apr 2011 21:55:38 +0000
Subject: [issue11800] regrtest --timeout: apply the timeout on a function,
	not on the whole file
In-Reply-To: <1302213294.05.0.908920520464.issue11800@psf.upfronthosting.co.za>
Message-ID: <1302213338.92.0.290141112573.issue11800@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11800>
_______________________________________

From report at bugs.python.org  Fri Apr  8 00:00:10 2011
From: report at bugs.python.org (Yuval Greenfield)
Date: Thu, 07 Apr 2011 22:00:10 +0000
Subject: [issue11799] urllib HTTP authentication behavior with unrecognized
	auth method
In-Reply-To: <1302204770.2.0.571328195993.issue11799@psf.upfronthosting.co.za>
Message-ID: <1302213610.12.0.161082495346.issue11799@psf.upfronthosting.co.za>


Yuval Greenfield <ubershmekel at gmail.com> added the comment:

I noticed it's not only that python doesn't support NTLM, it's that I used Basic Auth which isn't NTLM. So I modified the patch to pertain to basic auth and digest as well.

----------
Added file: http://bugs.python.org/file21574/urllib.auth2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11799>
_______________________________________

From report at bugs.python.org  Fri Apr  8 00:00:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Apr 2011 22:00:32 +0000
Subject: [issue11757] test_subprocess.test_communicate_timeout_large_ouput
	failure on select(): negative timeout?
In-Reply-To: <1301869705.52.0.173979620005.issue11757@psf.upfronthosting.co.za>
Message-ID: <1302213632.89.0.773304849244.issue11757@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

You may also patch poll_poll().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11757>
_______________________________________

From report at bugs.python.org  Fri Apr  8 00:01:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Apr 2011 22:01:23 +0000
Subject: [issue11800] regrtest --timeout: apply the timeout on a function,
	not on the whole file
In-Reply-To: <1302213294.05.0.908920520464.issue11800@psf.upfronthosting.co.za>
Message-ID: <1302213683.03.0.761999899302.issue11800@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I forgot to patch some calls to runtest(): new patch.

----------
Added file: http://bugs.python.org/file21575/regrtest_timeout-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11800>
_______________________________________

From report at bugs.python.org  Fri Apr  8 00:01:39 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Apr 2011 22:01:39 +0000
Subject: [issue11800] regrtest --timeout: apply the timeout on a function,
	not on the whole file
In-Reply-To: <1302213294.05.0.908920520464.issue11800@psf.upfronthosting.co.za>
Message-ID: <1302213699.79.0.437133289932.issue11800@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file21573/regrtest_timeout.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11800>
_______________________________________

From report at bugs.python.org  Fri Apr  8 00:09:02 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 Apr 2011 22:09:02 +0000
Subject: [issue11492] email.header.Header doesn't fold headers correctly
In-Reply-To: <1300087978.39.0.703069545984.issue11492@psf.upfronthosting.co.za>
Message-ID: <1302214142.94.0.246345294352.issue11492@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file21564/header_folding_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11492>
_______________________________________

From report at bugs.python.org  Fri Apr  8 00:09:39 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 Apr 2011 22:09:39 +0000
Subject: [issue11492] email.header.Header doesn't fold headers correctly
In-Reply-To: <1300087978.39.0.703069545984.issue11492@psf.upfronthosting.co.za>
Message-ID: <1302214179.5.0.262218130889.issue11492@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here is an updated test patch that brings the test coverage of the relevant code much closer to 100%.  There are still three lines and one branch uncovered, but it appears as though one of the bugs is preventing the test case that would produce full coverage from getting to the relevant code path.  This gives me enough coverage to feel safer mucking about with the algorithm.

----------
Added file: http://bugs.python.org/file21576/header_folding_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11492>
_______________________________________

From report at bugs.python.org  Fri Apr  8 00:14:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Apr 2011 22:14:48 +0000
Subject: [issue11768] test_signals() of test_threadsignals failure on Mac OS X
In-Reply-To: <1301962757.99.0.598461435574.issue11768@psf.upfronthosting.co.za>
Message-ID: <1302214488.72.0.576495058847.issue11768@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

jseutter reproduced it after 112 and 49 runs on Snow Leopard using "regrtest.py -F -v --timeout=60 test_threadsignals" command:
-----------
[ 49] test_threadsignals
test_interrupted_timed_acquire (test.test_threadsignals.ThreadSignals) ... ok
test_lock_acquire_interruption (test.test_threadsignals.ThreadSignals) ... ok
test_lock_acquire_retries_on_intr (test.test_threadsignals.ThreadSignals) ... ok
test_rlock_acquire_interruption (test.test_threadsignals.ThreadSignals) ... ok
test_rlock_acquire_retries_on_intr (test.test_threadsignals.ThreadSignals) ... ok
test_signals (test.test_threadsignals.ThreadSignals) ... test_signals: acquire lock (thread 140735082572960)
test_signals: wait lock (thread 140735082572960)
Thread 0x00007fff709aaca0:
  File "/Users/jseutter/code/python/cpython/Lib/test/test_threadsignals.py", line 55 in test_signals
  File "/Users/jseutter/code/python/cpython/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/Users/jseutter/code/python/cpython/Lib/unittest/case.py", line 442 in run
  File "/Users/jseutter/code/python/cpython/Lib/unittest/case.py", line 494 in __call__
  File "/Users/jseutter/code/python/cpython/Lib/unittest/suite.py", line 105 in run
  File "/Users/jseutter/code/python/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/jseutter/code/python/cpython/Lib/unittest/suite.py", line 105 in run
  File "/Users/jseutter/code/python/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/jseutter/code/python/cpython/Lib/unittest/runner.py", line 168 in run
  File "/Users/jseutter/code/python/cpython/Lib/test/support.py", line 1166 in _run_suite
  File "/Users/jseutter/code/python/cpython/Lib/test/support.py", line 1192 in run_unittest
  File "/Users/jseutter/code/python/cpython/Lib/test/test_threadsignals.py", line 221 in test_main
  File "Lib/test/regrtest.py", line 1032 in runtest_inner
  File "Lib/test/regrtest.py", line 826 in runtest
  File "Lib/test/regrtest.py", line 650 in main
  File "Lib/test/regrtest.py", line 1607 in <module>
-----------

So for an unknown reason, send_signals() thread was not created or doesn't start.

Example of the output of a success:
----------
test_signals: acquire lock (thread 140735082572960)
test_signals: wait lock (thread 140735082572960)
send_signals: enter (thread 4326952960)
send_signals: raise SIGUSR1
send_signals: raise SIGUSR2
send_signals: release signalled_all
send_signals: exit (thread 4326952960)
test_signals: lock acquired
----------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11768>
_______________________________________

From report at bugs.python.org  Fri Apr  8 00:19:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Apr 2011 22:19:30 +0000
Subject: [issue11768] test_signals() of test_threadsignals failure on Mac OS X
In-Reply-To: <1301962757.99.0.598461435574.issue11768@psf.upfronthosting.co.za>
Message-ID: <1302214770.91.0.810141082764.issue11768@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, the traceback only contains one thread, so send_signals() thread was not created or failed very quickly (before its first print instruction).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11768>
_______________________________________

From report at bugs.python.org  Fri Apr  8 00:22:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Apr 2011 22:22:41 +0000
Subject: [issue11800] regrtest --timeout: apply the timeout on a function,
	not on the whole file
In-Reply-To: <1302213294.05.0.908920520464.issue11800@psf.upfronthosting.co.za>
Message-ID: <1302214961.46.0.220735902075.issue11800@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The question is: what's the point? Having an individual test timeout is not more "correct" than having a timeout for a test file. Both are arbitrary. Therefore, I'd prefer we choose the simplest solution and this patch brings complication. I'm -0.5 on it.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11800>
_______________________________________

From report at bugs.python.org  Fri Apr  8 00:30:59 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 07 Apr 2011 22:30:59 +0000
Subject: [issue11777] Executor.map does not submit futures until iter.next()
	is called
In-Reply-To: <1302052595.78.0.918161508373.issue11777@psf.upfronthosting.co.za>
Message-ID: <E1Q7xj8-0007fQ-Dx@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 126353bc7e94 by Brian Quinlan in branch 'default':
Issue #11777: Executor.map does not submit futures until iter.next() is called
http://hg.python.org/cpython/rev/126353bc7e94

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11777>
_______________________________________

From report at bugs.python.org  Fri Apr  8 00:33:02 2011
From: report at bugs.python.org (Brian Quinlan)
Date: Thu, 07 Apr 2011 22:33:02 +0000
Subject: [issue11777] Executor.map does not submit futures until iter.next()
	is called
In-Reply-To: <1302052595.78.0.918161508373.issue11777@psf.upfronthosting.co.za>
Message-ID: <1302215582.58.0.143206070396.issue11777@psf.upfronthosting.co.za>


Changes by Brian Quinlan <brian at sweetapp.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11777>
_______________________________________

From report at bugs.python.org  Fri Apr  8 00:37:02 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 07 Apr 2011 22:37:02 +0000
Subject: [issue11800] regrtest --timeout: apply the timeout on a function,
	not on the whole file
In-Reply-To: <1302213294.05.0.908920520464.issue11800@psf.upfronthosting.co.za>
Message-ID: <1302215822.73.0.0636728421131.issue11800@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

FWIW, I prefer the whole file approach.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11800>
_______________________________________

From report at bugs.python.org  Fri Apr  8 00:49:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Apr 2011 22:49:55 +0000
Subject: [issue11800] regrtest --timeout: apply the timeout on a function,
	not on the whole file
In-Reply-To: <1302213294.05.0.908920520464.issue11800@psf.upfronthosting.co.za>
Message-ID: <1302216595.57.0.354159763473.issue11800@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I would like a timeout per function call because some files contain many slow tests: the duration of a file depends on the number of tests. Imagine that all functions takes 1 second: a file with 200 functions takes 200 seconds, whereas a file with 1 test takes just 1 second.

The problem is some files having a lot of slow tests like test_io, test_largefile or test_subprocess (especially test_io).

Buildbots use currently a global timeout of 1 hour. I tried timeouts of 5, 15 and 30 minutes for a file, and I always got false positive. Using a timeout of 15 minutes per function, I don't expect any false positive anymore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11800>
_______________________________________

From report at bugs.python.org  Fri Apr  8 00:51:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Apr 2011 22:51:22 +0000
Subject: [issue11800] regrtest --timeout: apply the timeout on a function,
	not on the whole file
In-Reply-To: <1302216595.57.0.354159763473.issue11800@psf.upfronthosting.co.za>
Message-ID: <1302216677.3532.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Buildbots use currently a global timeout of 1 hour. I tried timeouts
> of 5, 15 and 30 minutes for a file, and I always got false positive.
> Using a timeout of 15 minutes per function, I don't expect any false
> positive anymore.

Still I don't see the point. Is a 60 minutes timeout too long?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11800>
_______________________________________

From report at bugs.python.org  Fri Apr  8 01:00:41 2011
From: report at bugs.python.org (Bryce Verdier)
Date: Thu, 07 Apr 2011 23:00:41 +0000
Subject: [issue4877] xml.parsers.expat ParseFile() causes segmentation fault
	when passed a closed file object
In-Reply-To: <1231390876.07.0.554090447949.issue4877@psf.upfronthosting.co.za>
Message-ID: <1302217241.22.0.00222673424132.issue4877@psf.upfronthosting.co.za>


Bryce Verdier <bryceverdier at gmail.com> added the comment:

I double checked this today. On my linux box with 2.6.6 the commands given did cause a segfault. On my windows VM with 2.7.1 it also created a segfault. And to back up Mark's claim, it did not segfault on my 3.1.2 linux install.

----------
nosy: +louiscipher

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4877>
_______________________________________

From report at bugs.python.org  Fri Apr  8 01:08:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Apr 2011 23:08:33 +0000
Subject: [issue11800] regrtest --timeout: apply the timeout on a function,
	not on the whole file
In-Reply-To: <1302213294.05.0.908920520464.issue11800@psf.upfronthosting.co.za>
Message-ID: <1302217713.0.0.770066647225.issue11800@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Still I don't see the point. Is a 60 minutes timeout too long?

If regrtest timeout is too close to the buildbot timeout, we may not get the traceback if the blocking test is the last test.

I don't know yet if we will get false positive with a timeout of 60 minutes.

Another *minor* advantage of a smaller regrtest timeout is to "protect" the buildbot: catching faster a hang avoids to wait one hour to start a new build. Most hangs are sporadic or introduced by recent commits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11800>
_______________________________________

From report at bugs.python.org  Fri Apr  8 01:10:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Apr 2011 23:10:20 +0000
Subject: [issue11800] regrtest --timeout: apply the timeout on a function,
	not on the whole file
In-Reply-To: <1302217713.0.0.770066647225.issue11800@psf.upfronthosting.co.za>
Message-ID: <1302217818.3532.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le jeudi 07 avril 2011 ? 23:08 +0000, STINNER Victor a ?crit :
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> > Still I don't see the point. Is a 60 minutes timeout too long?
> 
> If regrtest timeout is too close to the buildbot timeout, we may not
> get the traceback if the blocking test is the last test.

The buildbot timeout is 65 minutes right now. I don't think (I hope)
this is too close.

> I don't know yet if we will get false positive with a timeout of 60 minutes.

Ok, let's see.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11800>
_______________________________________

From report at bugs.python.org  Fri Apr  8 01:53:52 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Thu, 07 Apr 2011 23:53:52 +0000
Subject: [issue11778] __subclasscheck__ : class P(M): __metaclass__=M causes
	maximum recursion depth exceeded.
In-Reply-To: <1302071581.19.0.711337712085.issue11778@psf.upfronthosting.co.za>
Message-ID: <1302220432.73.0.972475173563.issue11778@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

That issue is already fixed in 2.7 and 3.x (by ae006386ec39). Also, it's a duplicate of issue #2325, hence I think this one can be closed.

----------
nosy: +Trundle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11778>
_______________________________________

From report at bugs.python.org  Fri Apr  8 02:09:27 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Apr 2011 00:09:27 +0000
Subject: [issue11793] raw strings
In-Reply-To: <1302166114.84.0.402815371871.issue11793@psf.upfronthosting.co.za>
Message-ID: <1302221367.7.0.402254342827.issue11793@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

To a pythonista, the perl behavior is counter-intuitive :)

That said, the behavior of r'\' *is* somewhat counter-intuitive.  See issue 1271 for a fairly thorough exploration of why it is the way it is.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11793>
_______________________________________

From report at bugs.python.org  Fri Apr  8 02:17:15 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Fri, 08 Apr 2011 00:17:15 +0000
Subject: [issue11770] inspect.dir_static
In-Reply-To: <1302001735.74.0.572603626553.issue11770@psf.upfronthosting.co.za>
Message-ID: <1302221835.81.0.910238141358.issue11770@psf.upfronthosting.co.za>


Changes by Andreas St?hrk <andy-python at hammerhartes.de>:


----------
nosy: +Trundle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11770>
_______________________________________

From report at bugs.python.org  Fri Apr  8 02:17:23 2011
From: report at bugs.python.org (Lane Stevens)
Date: Fri, 08 Apr 2011 00:17:23 +0000
Subject: [issue11801] difference in comparison behavior between 32 bit and 64
	bit releases
In-Reply-To: <1302221843.91.0.79714388976.issue11801@psf.upfronthosting.co.za>
Message-ID: <1302221843.91.0.79714388976.issue11801@psf.upfronthosting.co.za>


New submission from Lane Stevens <tiwula at gmail.com>:

I have two systems running 

python-2.6.4-27.fc13.x86_64
and
python-2.6.4-27.fc13.i686

respectively. Given the following statement the 64-bit version returns False and the 32-bit version returns True.

Decimal('1.0') > 0.0

Decimal('1.0') > 0 returns True on both systems.

----------
components: Interpreter Core
messages: 133279
nosy: Lane.Stevens
priority: normal
severity: normal
status: open
title: difference in comparison behavior between 32 bit and 64 bit releases
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11801>
_______________________________________

From report at bugs.python.org  Fri Apr  8 02:18:05 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Fri, 08 Apr 2011 00:18:05 +0000
Subject: [issue11764] inspect.getattr_static code execution w/ class body as
	non dict
In-Reply-To: <1301949322.52.0.106729359313.issue11764@psf.upfronthosting.co.za>
Message-ID: <1302221885.87.0.789654213409.issue11764@psf.upfronthosting.co.za>


Changes by Andreas St?hrk <andy-python at hammerhartes.de>:


----------
nosy: +Trundle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11764>
_______________________________________

From report at bugs.python.org  Fri Apr  8 02:20:04 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 08 Apr 2011 00:20:04 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1302222004.24.0.429181688506.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> As a reference, I think you are refering to #5863 and #10791. Pretty fine job, I must say.

Thank you :)

> Nadeem, what do you think?. Is xz in your list?.

Yes, it's the next substantial thing I was planning on working on. I don't have
a lot of free time at the moment, though, so it might take a while. But I'll
definitely have it done in time for the release of 3.3 ;)

Looking at the pyliblzma code, I see that it provides the same thread-safety
guarantees as bz2 does. In rewriting, I would like to remove the locking code,
as it complicates the control flow logic of the C code, and doesn't seem like
the sort of thing a compression library should be concerned with. Are there any
objections to this? (Also, if anyone knows why bz2 was written to be thread-safe
in the first place, please enlighten me)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Fri Apr  8 02:23:01 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 08 Apr 2011 00:23:01 +0000
Subject: [issue11801] difference in comparison behavior between 32 bit and 64
	bit releases
In-Reply-To: <1302221843.91.0.79714388976.issue11801@psf.upfronthosting.co.za>
Message-ID: <1302222181.13.0.0545718219992.issue11801@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think that's "normal", the 2.7 doc[0] says:
"""
Changed in version 2.7: A comparison between a float instance x and a Decimal instance y now returns a result based on the values of x and y. In earlier versions x < y returned the same (arbitrary) result for any Decimal instance x and any float instance y.
"""

This means that in Python 2.6 a comparison between Decimal and float is a meaningless operation that might return arbitrary values.

[0]: http://docs.python.org/library/decimal.html#decimal.Decimal

----------
nosy: +ezio.melotti, mark.dickinson
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11801>
_______________________________________

From report at bugs.python.org  Fri Apr  8 02:39:12 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 08 Apr 2011 00:39:12 +0000
Subject: [issue11778] __subclasscheck__ : class P(M): __metaclass__=M causes
	maximum recursion depth exceeded.
In-Reply-To: <1302071581.19.0.711337712085.issue11778@psf.upfronthosting.co.za>
Message-ID: <1302223152.51.0.400052359711.issue11778@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11778>
_______________________________________

From report at bugs.python.org  Fri Apr  8 02:50:10 2011
From: report at bugs.python.org (Dan Stromberg)
Date: Fri, 08 Apr 2011 00:50:10 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1302223810.41.0.989969683234.issue6715@psf.upfronthosting.co.za>


Dan Stromberg <strombrg at gmail.com> added the comment:

I don't know that much about compression, but I wonder if a threadsafe compression module would enable parallel forms of compression?  If yes, then multithreaded might be a big benefit, in light of multicore taking off.

EG: http://www.compression.ca/pbzip2/

It might be worthwhile to check with the authors (of bzip2 and pyliblzma modules) about why they went with thread safety.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Fri Apr  8 03:01:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 08 Apr 2011 01:01:31 +0000
Subject: [issue11492] email.header.Header doesn't fold headers correctly
In-Reply-To: <1300087978.39.0.703069545984.issue11492@psf.upfronthosting.co.za>
Message-ID: <E1Q804l-0000lJ-3B@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 10725fc76e11 by R David Murray in branch '3.1':
#11492: fix header truncation on folding when there are runs of split chars.
http://hg.python.org/cpython/rev/10725fc76e11

New changeset 74ec64dc3538 by R David Murray in branch '3.2':
Merge #11492: fix header truncation on folding when there are runs of split chars.
http://hg.python.org/cpython/rev/74ec64dc3538

New changeset 5ec2695c9c15 by R David Murray in branch 'default':
Merge #11492: fix header truncation on folding when there are runs of split chars.
http://hg.python.org/cpython/rev/5ec2695c9c15

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11492>
_______________________________________

From report at bugs.python.org  Fri Apr  8 03:06:04 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 08 Apr 2011 01:06:04 +0000
Subject: [issue10427] 24:00 Hour in DateTime
In-Reply-To: <1289831880.43.0.381934582888.issue10427@psf.upfronthosting.co.za>
Message-ID: <1302224764.41.0.315169021611.issue10427@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Is there still interest in pursuing this?   Normalizing out of bounds arguments to datetime constructor is easy, but rather pointless.  It is trivial to implement this functionality using existing timedelta constructor:

def normdatetime(Y, M, D, h, m, s):
    return datetime(Y, M, D) + timedelta(hours=h, minutes=m, seconds=s)

It would be much more interesting to allow datetime objects to store ISO 8601 data without loss of information.  It may be important to some applications that datetime(Y, M, D, 24).date() is date(Y, M, D) rather than the next day.  Other applications may want to distinguish between datetime(Y, M, D, 24) and datetime(Y, M, D) + timedelta(1) in some other ways.  For leap seconds accounting, normalizing ISO 8601 timestamps with seconds=60 to the next minute is certainly wrong.  An application that is unfortunate enough to record data during a leap second would clearly want to distinguish that data from data recorded a second later.

I believe that from practical applications point of view, it would be best to allow storing hour=24 and second=60 in datetime structure and order the resulting objects in the same way as ISO 8601 strings are ordered alphabetically.  In other words, 

Y-M-D 24:00 < Y-M-D+1 00:00

and

Y-M-D 23:59:60 < Y-M-D+1 00:00:00.

There is no sane choice for subtraction operation involving these special values or for adding timedeltas to them.  It is probably best to raise an exception in those cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10427>
_______________________________________

From report at bugs.python.org  Fri Apr  8 03:11:36 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 08 Apr 2011 01:11:36 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1302225096.5.0.911222483372.issue6715@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy:  -Christophe Simonis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Fri Apr  8 03:12:26 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 08 Apr 2011 01:12:26 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1302225146.73.0.59225513009.issue6715@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +Christophe Simonis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Fri Apr  8 03:13:17 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 08 Apr 2011 01:13:17 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1302225197.1.0.805802368444.issue6715@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy:  -jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Fri Apr  8 03:24:57 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 08 Apr 2011 01:24:57 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1302225897.29.0.642323765891.issue6715@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Fri Apr  8 03:36:17 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 08 Apr 2011 01:36:17 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1302226577.53.0.977880551733.issue6715@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I think doesn't makes sense for two threads using at the same time the same compress/decompress object. But I could guess ony reason for the locking code is to avoid crashing the interpreter just having two threads racing each other on an inherently mutable object.

Dan, parallel compression simply split the input data and compress each fragment independly. The actual compression object is not shared, each block is compressed with its own self-contained compression context.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Fri Apr  8 03:48:46 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Fri, 08 Apr 2011 01:48:46 +0000
Subject: [issue11764] inspect.getattr_static code execution w/ class body as
	non dict
In-Reply-To: <1301949322.52.0.106729359313.issue11764@psf.upfronthosting.co.za>
Message-ID: <1302227326.21.0.72952228848.issue11764@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

Can you perhaps elaborate on the first part? I really can't see right now how a class __dict__ can be something different from a dictionary. It's true that the class dict can be any mapping while the class is being created, but that's uninteresting for getattr_static as there is no class object yet that one can pass to getattr_static.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11764>
_______________________________________

From report at bugs.python.org  Fri Apr  8 04:12:17 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Apr 2011 02:12:17 +0000
Subject: [issue11767] Maildir iterator leaks file descriptors by default
In-Reply-To: <1301958670.39.0.218079408331.issue11767@psf.upfronthosting.co.za>
Message-ID: <1302228737.01.0.552501764197.issue11767@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I shouldn't have assumed that you knew about contextlib, and should have mentioned it by name the first time.

The patch looks good to me.  Not sure it is necessary to loop through ten fake mailboxes, but it doesn't hurt, either.  (Other potential reviewers note: 'looks' is the operative word, I haven't tested it myself yet.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11767>
_______________________________________

From report at bugs.python.org  Fri Apr  8 04:58:21 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 08 Apr 2011 02:58:21 +0000
Subject: [issue11797] 2to3 does not correct "reload"
In-Reply-To: <1302191844.85.0.922084217825.issue11797@psf.upfronthosting.co.za>
Message-ID: <1302231501.24.0.320928701842.issue11797@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11797>
_______________________________________

From report at bugs.python.org  Fri Apr  8 05:19:54 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 08 Apr 2011 03:19:54 +0000
Subject: [issue11799] urllib HTTP authentication behavior with unrecognized
	auth method
In-Reply-To: <1302204770.2.0.571328195993.issue11799@psf.upfronthosting.co.za>
Message-ID: <1302232794.77.0.0624377411646.issue11799@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

The patch seems ok. I think this should be applied to 3.2 and 3.3. Not sure about 3.1.

----------
keywords: +needs review -patch
nosy: +jcea
versions: +Python 3.2, Python 3.3 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11799>
_______________________________________

From report at bugs.python.org  Fri Apr  8 05:25:27 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 08 Apr 2011 03:25:27 +0000
Subject: [issue11799] urllib HTTP authentication behavior with unrecognized
	auth method
In-Reply-To: <1302204770.2.0.571328195993.issue11799@psf.upfronthosting.co.za>
Message-ID: <1302233127.53.0.317864020708.issue11799@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

With the patch there is a new exception with specific msg being raised in certain cases, so this may only pertain to 3.3

----------
assignee:  -> orsenthil
nosy: +orsenthil
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11799>
_______________________________________

From report at bugs.python.org  Fri Apr  8 05:37:24 2011
From: report at bugs.python.org (jeff deifik)
Date: Fri, 08 Apr 2011 03:37:24 +0000
Subject: [issue11802] filecmp.cmp needs a documented way to clear cache
In-Reply-To: <1302233844.4.0.517722747064.issue11802@psf.upfronthosting.co.za>
Message-ID: <1302233844.4.0.517722747064.issue11802@psf.upfronthosting.co.za>


New submission from jeff deifik <jeff at jeffunit.com>:

I have a program which calls filecmp.cmp a lot.
It runs out of memory.
I read the source to filecmp, and then I periodically set
filecmp._cache = {}

Without doing this, filecmp's cache uses up all the memory in the computer.

There needs to be a documented interface to clear the cache.

I suggest a function
def clear_cache:
    _cache = {}

Without a documented interface, there is no standard way to clear the
cache. It is possible different versions of python will require
different methods to clear the cache, which will reduce python code
portability and is a bad idea.

Alternatively, one might disable the caching code.

One shouldn't have to look at the source code of a library function
to see why it is consuming memory.

----------
messages: 133290
nosy: lopgok
priority: normal
severity: normal
status: open
title: filecmp.cmp needs a documented way to clear cache
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11802>
_______________________________________

From report at bugs.python.org  Fri Apr  8 07:34:55 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Fri, 08 Apr 2011 05:34:55 +0000
Subject: [issue11757] test_subprocess.test_communicate_timeout_large_ouput
	failure on select(): negative timeout?
In-Reply-To: <1302213632.89.0.773304849244.issue11757@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=fCDc+wc0O++TedYUS6h0R2Fi7Uw@mail.gmail.com>


Charles-Francois Natali <neologix at free.fr> added the comment:

> You may also patch poll_poll().
>

Poll accepts negative timeout values, since it's the only way to
specify an infinite wait (contrarily to select which can be passed
NULL).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11757>
_______________________________________

From report at bugs.python.org  Fri Apr  8 09:06:50 2011
From: report at bugs.python.org (Swapnil Talekar)
Date: Fri, 08 Apr 2011 07:06:50 +0000
Subject: [issue11803] Memory leak in sub-interpreters
In-Reply-To: <1302246410.34.0.932869842046.issue11803@psf.upfronthosting.co.za>
Message-ID: <1302246410.34.0.932869842046.issue11803@psf.upfronthosting.co.za>


New submission from Swapnil Talekar <swapnil.st at gmail.com>:

In the attached program, the total memory consumption of the process, goes up each time a new subinterpreter imports a bunch of modules. When the subinterpreter is shutdown with Py_EndInterpreter, the memory consumed with import of modules is not returned back. Hence the amount of memory consumed keeps increasing with each loop. It goes up from about 8MB to about 11MB after few loops. Strangely it doesn't rise any further.

I have tested this only for Python 2.6.5

----------
components: Interpreter Core
files: test_subinterpreter.c
messages: 133292
nosy: amaury.forgeotdarc, benjamin.peterson, christian.heimes, eric.araujo, grahamd, haypo, loewis, ncoghlan, pitrou, python-dev, swapnil
priority: normal
severity: normal
status: open
title: Memory leak in sub-interpreters
type: resource usage
versions: Python 2.6
Added file: http://bugs.python.org/file21577/test_subinterpreter.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11803>
_______________________________________

From report at bugs.python.org  Fri Apr  8 09:08:13 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 08 Apr 2011 07:08:13 +0000
Subject: [issue11803] Memory leak in sub-interpreters
In-Reply-To: <1302246410.34.0.932869842046.issue11803@psf.upfronthosting.co.za>
Message-ID: <1302246493.6.0.519814911361.issue11803@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Is this the same as #222684?

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11803>
_______________________________________

From report at bugs.python.org  Fri Apr  8 09:09:39 2011
From: report at bugs.python.org (Swapnil Talekar)
Date: Fri, 08 Apr 2011 07:09:39 +0000
Subject: [issue11803] Memory leak in sub-interpreters
In-Reply-To: <1302246410.34.0.932869842046.issue11803@psf.upfronthosting.co.za>
Message-ID: <1302246579.63.0.798114885072.issue11803@psf.upfronthosting.co.za>


Swapnil Talekar <swapnil.st at gmail.com> added the comment:

No. This is not the same as #222684?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11803>
_______________________________________

From report at bugs.python.org  Fri Apr  8 09:10:00 2011
From: report at bugs.python.org (Swapnil Talekar)
Date: Fri, 08 Apr 2011 07:10:00 +0000
Subject: [issue11803] Memory leak in sub-interpreters
In-Reply-To: <1302246410.34.0.932869842046.issue11803@psf.upfronthosting.co.za>
Message-ID: <1302246600.56.0.802646662358.issue11803@psf.upfronthosting.co.za>


Changes by Swapnil Talekar <swapnil.st at gmail.com>:


Added file: http://bugs.python.org/file21579/large_import.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11803>
_______________________________________

From report at bugs.python.org  Fri Apr  8 09:11:29 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 08 Apr 2011 07:11:29 +0000
Subject: [issue11803] Memory leak in sub-interpreters
In-Reply-To: <1302246410.34.0.932869842046.issue11803@psf.upfronthosting.co.za>
Message-ID: <1302246689.09.0.286774608959.issue11803@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Indeed, the code looks similar, but #222684 seems to be fixed, and doesn't use PyImport_ImportModule, so maybe the leak is there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11803>
_______________________________________

From report at bugs.python.org  Fri Apr  8 09:16:49 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 08 Apr 2011 07:16:49 +0000
Subject: [issue222684] Memory leak creating sub-interpreters
Message-ID: <1302247009.11.0.607772353638.issue222684@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

For the record, the changeset was 433458651eb4

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue222684>
_______________________________________

From report at bugs.python.org  Fri Apr  8 09:20:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Apr 2011 07:20:18 +0000
Subject: [issue11757] test_subprocess.test_communicate_timeout_large_ouput
	failure on select(): negative timeout?
In-Reply-To: <BANLkTi=fCDc+wc0O++TedYUS6h0R2Fi7Uw@mail.gmail.com>
Message-ID: <1302247212.14280.8.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le vendredi 08 avril 2011 ? 05:34 +0000, Charles-Francois Natali a
?crit :
> Charles-Francois Natali <neologix at free.fr> added the comment:
> 
> > You may also patch poll_poll().
> >
> 
> Poll accepts negative timeout values, since it's the only way to
> specify an infinite wait (contrarily to select which can be passed
> NULL).

Oh, I didn't know. In this case, is my commit 3664fc29e867 correct? I
think that it is, because without the patch, subprocess may call poll()
with a negative timeout, and so it is no more a timeout at all.

If I am correct, it is a real bug. Should it be fixed in Python 2.7, 3.1
and 3.2? ... Hum, it looks like communicate() timeout was introduced in
Python 3.3: c4a0fa6e687c. This commit has no reference to an issue: it
is the issue #5673. And as it was already written in msg130851, the doc
is wrong: the doc indicates that the feature was introduced in 3.2, but
it is 3.3 only. The change is not documented in Misc/NEWS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11757>
_______________________________________

From report at bugs.python.org  Fri Apr  8 09:23:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Apr 2011 07:23:18 +0000
Subject: [issue5673] Add timeout option to subprocess.Popen
In-Reply-To: <1238701276.41.0.515283298202.issue5673@psf.upfronthosting.co.za>
Message-ID: <1302247398.65.0.854835343393.issue5673@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I fixed a bug in _communicate_with_poll(): raise an error if the endtime-time() is negative. If poll() is called with a negative timeout, it blocks until it gets an event.

New changeset 3664fc29e867 by Victor Stinner in branch 'default':
Issue #11757: subprocess ensures that select() and poll() timeout >= 0
http://hg.python.org/cpython/rev/3664fc29e867

By the way, the doc modified by [c4a0fa6e687c] is still wrong: the timeout feature was introduced in 3.3, not in 3.2. And the change is not documented in Misc/NEWS.

@Reid Kleckner: Can you fix that? (I reopen this issue to not forget)

----------
nosy: +haypo
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5673>
_______________________________________

From report at bugs.python.org  Fri Apr  8 09:52:08 2011
From: report at bugs.python.org (Gertjan Klein)
Date: Fri, 08 Apr 2011 07:52:08 +0000
Subject: [issue11629] Reference implementation for PEP 397
In-Reply-To: <1300777913.25.0.357945805094.issue11629@psf.upfronthosting.co.za>
Message-ID: <1302249128.79.0.515605439577.issue11629@psf.upfronthosting.co.za>


Changes by Gertjan Klein <gklein at xs4all.nl>:


----------
nosy: +gklein

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11629>
_______________________________________

From report at bugs.python.org  Fri Apr  8 10:27:43 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 08 Apr 2011 08:27:43 +0000
Subject: [issue11629] Reference implementation for PEP 397
In-Reply-To: <1300777913.25.0.357945805094.issue11629@psf.upfronthosting.co.za>
Message-ID: <1302251263.92.0.00727318233923.issue11629@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Is it possible to add tl;dr chapter to this document. I am especially interested in extensive logging (to debug problems etc.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11629>
_______________________________________

From report at bugs.python.org  Fri Apr  8 10:33:43 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 08 Apr 2011 08:33:43 +0000
Subject: [issue5996] abstract class instantiable when subclassing dict
In-Reply-To: <1242050763.07.0.145569961651.issue5996@psf.upfronthosting.co.za>
Message-ID: <1302251623.85.0.585688707044.issue5996@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5996>
_______________________________________

From report at bugs.python.org  Fri Apr  8 11:16:43 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 08 Apr 2011 09:16:43 +0000
Subject: [issue11802] filecmp.cmp needs a documented way to clear cache
In-Reply-To: <1302233844.4.0.517722747064.issue11802@psf.upfronthosting.co.za>
Message-ID: <1302254203.38.0.743728960326.issue11802@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

I've looked at the code for Python 3, and there isn't anything there that
prevents this from happening there, either. So the fix should be applied
to 3.2 and 3.3 as well.

An alternative approach would be to limit the size of the cache, so that
the caller doesn't need to explicitly clear the cache. Something along
the lines of functools.lru_cache() should do the trick. I don't think
it'll be possible to use lru_cache() itself, though - it doesn't provide
a mechanism to invalidate cache entries when they become stale (and in
any case, it doesn't exist in 2.7).

----------
nosy: +nadeem.vawda
stage:  -> needs patch
type:  -> resource usage
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11802>
_______________________________________

From report at bugs.python.org  Fri Apr  8 11:33:03 2011
From: report at bugs.python.org (Panos Christeas)
Date: Fri, 08 Apr 2011 09:33:03 +0000
Subject: [issue11804] expat parser not xml 1.1 (breaks xmlrpclib)
In-Reply-To: <1302255183.42.0.728288108717.issue11804@psf.upfronthosting.co.za>
Message-ID: <1302255183.42.0.728288108717.issue11804@psf.upfronthosting.co.za>


New submission from Panos Christeas <xrg at hellug.gr>:

The expat library (in C level) is not xml 1.1 compliant, meaning that
it won't accept characters \x01-\x08,\x0b,\x0c and \x0e-\x1f .
At the same time, ElementTree (or custom XML creation, such as in xmlrpclib.py:694) allow these characters to pass through. They will get blocked on the receiving side.
Since 2.7, the expat library is the default parser for xml-rpc, so it
this is a regression, IMHO. According to the network principal, we should
accept these characters gracefully.

The attached test script demonstrates that we're not xml 1.1 compliant (but instead enforce the more strict 1.0 rule)

References:
http://bugs.python.org/issue5166
http://en.wikipedia.org/wiki/Valid_characters_in_XML

----------
components: XML
files: expat-test.py
messages: 133301
nosy: xrg
priority: normal
severity: normal
status: open
title: expat parser not xml 1.1 (breaks xmlrpclib)
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file21580/expat-test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11804>
_______________________________________

From report at bugs.python.org  Fri Apr  8 11:59:10 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 08 Apr 2011 09:59:10 +0000
Subject: [issue11794] Backport new logging docs to 2.7
In-Reply-To: <1302166682.89.0.483892888748.issue11794@psf.upfronthosting.co.za>
Message-ID: <1302256750.74.0.799343451874.issue11794@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
assignee: docs at python -> vinay.sajip
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11794>
_______________________________________

From report at bugs.python.org  Fri Apr  8 12:13:53 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 08 Apr 2011 10:13:53 +0000
Subject: [issue11571] Turtle window pops under the terminal on OSX
In-Reply-To: <1302195831.64.0.466771675243.issue11571@psf.upfronthosting.co.za>
Message-ID: <f7d7cbc9-11ed-ef6a-828f-a5045369e505@me.com>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

On 07 Apr, 2011,at 07:03 PM, Alexander Belopolsky <report at bugs.python.org> wrote:

Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

While you are at it, can you also fix the same issue with "python -m tkinter"?
??
Sure, I can add a hack to that module as well.

Ronald

----------
Added file: http://bugs.python.org/file21581/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11571>
_______________________________________
-------------- next part --------------
<html><body><div><br><br>On 07 Apr, 2011,at 07:03 PM, Alexander Belopolsky &lt;report at bugs.python.org&gt; wrote:<br><br></div><div><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><br>
Alexander Belopolsky &lt;<a href="mailto:belopolsky at users.sourceforge.net" _mce_href="mailto:belopolsky at users.sourceforge.net">belopolsky at users.sourceforge.net</a>&gt; added the comment:<br>
<br>
While you are at it, can you also fix the same issue with "python -m tkinter"?</div></div></blockquote><span>&nbsp;</span></div><div><span>Sure, I can add a hack to that module as well.</span></div><div><span><br></span></div><div><span>Ronald</span></div><div><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span style="color: rgb(0, 0, 0); "><span style="color: rgb(0, 51, 153); "><font class="Apple-style-span" color="#000000" face="Helvetica, Arial, sans-serif"><br></font></span></span></div></div></blockquote></div></body></html>

From report at bugs.python.org  Fri Apr  8 12:43:04 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 08 Apr 2011 10:43:04 +0000
Subject: [issue11794] Backport new logging docs to 2.7
In-Reply-To: <1302166682.89.0.483892888748.issue11794@psf.upfronthosting.co.za>
Message-ID: <E1Q899b-0000pP-3w@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6fb033af9310 by Vinay Sajip in branch '2.7':
Issue #11794: Reorganised logging documentation.
http://hg.python.org/cpython/rev/6fb033af9310

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11794>
_______________________________________

From report at bugs.python.org  Fri Apr  8 12:44:09 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 08 Apr 2011 10:44:09 +0000
Subject: [issue11794] Backport new logging docs to 2.7
In-Reply-To: <1302166682.89.0.483892888748.issue11794@psf.upfronthosting.co.za>
Message-ID: <1302259449.83.0.311247099786.issue11794@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/issue11794>
_______________________________________

From report at bugs.python.org  Fri Apr  8 12:53:57 2011
From: report at bugs.python.org (Matt Joiner)
Date: Fri, 08 Apr 2011 10:53:57 +0000
Subject: [issue3136] [PATCH] logging.config.fileConfig() compulsivly disable
	all existing loggers
In-Reply-To: <1213837323.33.0.0675974065144.issue3136@psf.upfronthosting.co.za>
Message-ID: <1302260037.12.0.509002010933.issue3136@psf.upfronthosting.co.za>


Changes by Matt Joiner <anacrolix at gmail.com>:


----------
nosy: +anacrolix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3136>
_______________________________________

From report at bugs.python.org  Fri Apr  8 13:09:17 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Apr 2011 11:09:17 +0000
Subject: [issue11802] filecmp.cmp needs a documented way to clear cache
In-Reply-To: <1302233844.4.0.517722747064.issue11802@psf.upfronthosting.co.za>
Message-ID: <1302260957.62.0.468150079694.issue11802@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Putting in a size limit is reasonable.  We did this for fnmatch not that long ago (issue 7846).  That was in fact the inspiration for lru_cache.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11802>
_______________________________________

From report at bugs.python.org  Fri Apr  8 13:49:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Apr 2011 11:49:11 +0000
Subject: [issue11800] regrtest --timeout: apply the timeout on a function,
	not on the whole file
In-Reply-To: <1302213294.05.0.908920520464.issue11800@psf.upfronthosting.co.za>
Message-ID: <1302263351.94.0.706036287176.issue11800@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Simplify the test and set the default timeout to 15 min.

----------
Added file: http://bugs.python.org/file21582/regrtest_timeout-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11800>
_______________________________________

From report at bugs.python.org  Fri Apr  8 13:49:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Apr 2011 11:49:16 +0000
Subject: [issue11800] regrtest --timeout: apply the timeout on a function,
	not on the whole file
In-Reply-To: <1302213294.05.0.908920520464.issue11800@psf.upfronthosting.co.za>
Message-ID: <1302263356.93.0.911721004546.issue11800@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file21575/regrtest_timeout-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11800>
_______________________________________

From report at bugs.python.org  Fri Apr  8 13:51:31 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 08 Apr 2011 11:51:31 +0000
Subject: [issue11800] regrtest --timeout: apply the timeout on a function,
	not on the whole file
In-Reply-To: <1302213294.05.0.908920520464.issue11800@psf.upfronthosting.co.za>
Message-ID: <1302263491.41.0.220444148432.issue11800@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Victor's reasons for wanting per-test timeout rather than per-file seem sound. Need to review the patch to see how much extra complexity it actually introduces (although on a casual reading the new custom result object it introduces is trivially simple, so not a maintenance burden).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11800>
_______________________________________

From report at bugs.python.org  Fri Apr  8 13:54:46 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 08 Apr 2011 11:54:46 +0000
Subject: [issue11803] Memory leak in sub-interpreters
In-Reply-To: <1302246410.34.0.932869842046.issue11803@psf.upfronthosting.co.za>
Message-ID: <1302263686.51.0.141964303551.issue11803@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As a first guess, I would suspect that this is just badly fragmenting the heap and we aren't freeing up any arenas to pass back to the OS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11803>
_______________________________________

From report at bugs.python.org  Fri Apr  8 14:12:47 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 08 Apr 2011 12:12:47 +0000
Subject: [issue11803] Memory leak in sub-interpreters
In-Reply-To: <1302246410.34.0.932869842046.issue11803@psf.upfronthosting.co.za>
Message-ID: <1302264767.7.0.940437223239.issue11803@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

The fact that the "leak" doesn't grow seems to confirm Nick supposition.

Close as invalid?

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11803>
_______________________________________

From report at bugs.python.org  Fri Apr  8 14:17:57 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 08 Apr 2011 12:17:57 +0000
Subject: [issue11803] Memory leak in sub-interpreters
In-Reply-To: <1302246410.34.0.932869842046.issue11803@psf.upfronthosting.co.za>
Message-ID: <1302265077.23.0.292733879827.issue11803@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Most builtin modules keep static references to common objects: exceptions, types, &co.  These references are currently never freed, but are reused by all sub-interpreters.
It the memory usage stays stable, even after many calls to Py_NewInterpreter()/Py_EndInterpreter(), this is not a bug!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11803>
_______________________________________

From report at bugs.python.org  Fri Apr  8 14:32:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Apr 2011 12:32:46 +0000
Subject: [issue11800] regrtest --timeout: apply the timeout on a function,
	not on the whole file
In-Reply-To: <1302213294.05.0.908920520464.issue11800@psf.upfronthosting.co.za>
Message-ID: <1302265966.22.0.951651678877.issue11800@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

With the current implementation of faulthandler.dump_tracebacks_later(), use a timeout per function means create a new thread for each function (the thread is interrupted and exits when the test is done).

Quick benchmark with test_io on Linux (lowest "real time" of 3 runs):

- time ./python Lib/test/regrtest.py -v (with timeout): 1 min 3 sec
- time ./python Lib/test/regrtest.py -v, without timeout: 1 min 3 sec
- time ./python Lib/test/test_io.py (without timeout): 1 min 3 sec

test_io have 403 tests and 8 are skipped, so it looks like the creation of ~400 threads is really fast on Linux! test_io is one of the biggest test suite I think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11800>
_______________________________________

From report at bugs.python.org  Fri Apr  8 14:53:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Apr 2011 12:53:20 +0000
Subject: [issue11804] expat parser not xml 1.1 (breaks xmlrpclib)
In-Reply-To: <1302255183.42.0.728288108717.issue11804@psf.upfronthosting.co.za>
Message-ID: <1302267200.81.0.217552403341.issue11804@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11804>
_______________________________________

From report at bugs.python.org  Fri Apr  8 15:07:03 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 08 Apr 2011 13:07:03 +0000
Subject: [issue11803] Memory leak in sub-interpreters
In-Reply-To: <1302246410.34.0.932869842046.issue11803@psf.upfronthosting.co.za>
Message-ID: <1302268023.35.0.345758340212.issue11803@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Please don't add everyone in existence to the nosy list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11803>
_______________________________________

From report at bugs.python.org  Fri Apr  8 15:07:15 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 08 Apr 2011 13:07:15 +0000
Subject: [issue11803] Memory leak in sub-interpreters
In-Reply-To: <1302246410.34.0.932869842046.issue11803@psf.upfronthosting.co.za>
Message-ID: <1302268035.36.0.298961026809.issue11803@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
nosy:  -benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11803>
_______________________________________

From report at bugs.python.org  Fri Apr  8 16:42:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Apr 2011 14:42:20 +0000
Subject: [issue11800] regrtest --timeout: apply the timeout on a function,
	not on the whole file
In-Reply-To: <1302213294.05.0.908920520464.issue11800@psf.upfronthosting.co.za>
Message-ID: <1302273740.49.0.453238576927.issue11800@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I did a similar test on Windows: test_io takes ~19.1 sec with and without timeout. If I look closer, the timeout overhead (call a thread per function call) is 112 ?s per function call. The average duration of a test is 48 ms (47,750 ?s), so the overhead is 0,2%. I am not sure of these numbers (it is difficult to get reliable numbers, especially in a VM), but I'm sure that the overflow is very low.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11800>
_______________________________________

From report at bugs.python.org  Fri Apr  8 16:57:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Apr 2011 14:57:57 +0000
Subject: [issue11803] Memory leak in sub-interpreters
In-Reply-To: <1302246410.34.0.932869842046.issue11803@psf.upfronthosting.co.za>
Message-ID: <1302274677.54.0.166343509022.issue11803@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy:  -eric.araujo
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11803>
_______________________________________

From report at bugs.python.org  Fri Apr  8 17:07:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Apr 2011 15:07:40 +0000
Subject: [issue11751] Increase distutils.filelist test coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <1302275260.92.0.78817039639.issue11751@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FYI, I currently only have sporadic Internet access, moreover with SSH blocked, and I want to wait for the merge of distutils2 into the stdlib before I commit some fixes, so don?t worry if this sits for a while.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11751>
_______________________________________

From report at bugs.python.org  Fri Apr  8 17:11:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Apr 2011 15:11:56 +0000
Subject: [issue5309] packaging doesn't parallelize extension module compilation
In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za>
Message-ID: <1302275516.36.0.616475752526.issue5309@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
title: setup.py doesn't parallelize extension module compilation -> packaging doesn't parallelize extension module compilation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5309>
_______________________________________

From report at bugs.python.org  Fri Apr  8 17:15:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Apr 2011 15:15:56 +0000
Subject: [issue11794] Backport new logging docs to 2.7
In-Reply-To: <1302166682.89.0.483892888748.issue11794@psf.upfronthosting.co.za>
Message-ID: <1302275756.75.0.447220670573.issue11794@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Great stuff!

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11794>
_______________________________________

From report at bugs.python.org  Fri Apr  8 17:18:57 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 08 Apr 2011 15:18:57 +0000
Subject: [issue11803] Memory leak in sub-interpreters
In-Reply-To: <1302246410.34.0.932869842046.issue11803@psf.upfronthosting.co.za>
Message-ID: <1302275937.61.0.188881476267.issue11803@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I think this is a non-issue. Closing.

If you have a testcase proving real leaks in a current release, reopen.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11803>
_______________________________________

From report at bugs.python.org  Fri Apr  8 17:27:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Apr 2011 15:27:03 +0000
Subject: [issue5996] abstract class instantiable when subclassing dict
In-Reply-To: <1242050763.07.0.145569961651.issue5996@psf.upfronthosting.co.za>
Message-ID: <1302276423.67.0.320949794299.issue5996@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5996>
_______________________________________

From report at bugs.python.org  Fri Apr  8 17:43:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Apr 2011 15:43:08 +0000
Subject: [issue11781] test/test_email directory does not get installed by
	'make install'
In-Reply-To: <1302100280.39.0.606654358464.issue11781@psf.upfronthosting.co.za>
Message-ID: <1302277388.43.0.885497193544.issue11781@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11781>
_______________________________________

From report at bugs.python.org  Fri Apr  8 17:45:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Apr 2011 15:45:35 +0000
Subject: [issue11785] email subpackages documentation problems
In-Reply-To: <1302105466.45.0.930997240631.issue11785@psf.upfronthosting.co.za>
Message-ID: <1302277535.8.0.605650476902.issue11785@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See also http://sphinx.pocoo.org/domains.html#directive-py:currentmodule

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11785>
_______________________________________

From report at bugs.python.org  Fri Apr  8 17:46:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Apr 2011 15:46:16 +0000
Subject: [issue11785] email subpackages documentation problems
In-Reply-To: <1302105466.45.0.930997240631.issue11785@psf.upfronthosting.co.za>
Message-ID: <1302277576.86.0.16877993012.issue11785@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Besides, the Doc/library/email-examples.rst is not a module and it
> uses ":mod:`email`: xxx"

Not a problem.  ?:mod:? is not ?.. module::?.  See above link.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11785>
_______________________________________

From report at bugs.python.org  Fri Apr  8 17:47:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Apr 2011 15:47:11 +0000
Subject: [issue11787] File handle leak in TarFile lib
In-Reply-To: <1302115375.88.0.984018215443.issue11787@psf.upfronthosting.co.za>
Message-ID: <1302277631.06.0.472201117215.issue11787@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

A try/except/finally construct would probably work.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11787>
_______________________________________

From report at bugs.python.org  Fri Apr  8 17:48:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Apr 2011 15:48:30 +0000
Subject: [issue11795] Better core dev guidelines for committing submitted
	patches
In-Reply-To: <1302180426.35.0.989064957004.issue11795@psf.upfronthosting.co.za>
Message-ID: <1302277710.79.0.616626970809.issue11795@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1

----------
nosy: +eric.araujo
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11795>
_______________________________________

From report at bugs.python.org  Fri Apr  8 17:49:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Apr 2011 15:49:11 +0000
Subject: [issue11770] inspect.dir_static
In-Reply-To: <1302001735.74.0.572603626553.issue11770@psf.upfronthosting.co.za>
Message-ID: <1302277751.55.0.283067159041.issue11770@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Would it respect __dir__?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11770>
_______________________________________

From report at bugs.python.org  Fri Apr  8 17:51:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Apr 2011 15:51:02 +0000
Subject: [issue11764] inspect.getattr_static code execution w/ class body as
	non dict
In-Reply-To: <1301949322.52.0.106729359313.issue11764@psf.upfronthosting.co.za>
Message-ID: <1302277862.82.0.91989077104.issue11764@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Andreas:  metaclass.__prepare__ can return any mapping object.  See http://docs.python.org/dev/reference/datamodel#customizing-class-creation

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11764>
_______________________________________

From report at bugs.python.org  Fri Apr  8 17:51:08 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 08 Apr 2011 15:51:08 +0000
Subject: [issue11770] inspect.dir_static
In-Reply-To: <1302001735.74.0.572603626553.issue11770@psf.upfronthosting.co.za>
Message-ID: <1302277868.42.0.0605511896564.issue11770@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

No. It would return all members accessible to getattr_static (which is completely unrelated to what __dir__ may or may not return). Also calling __dir__ would mean code execution, and the point of these functions is to avoid this where possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11770>
_______________________________________

From report at bugs.python.org  Fri Apr  8 17:55:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Apr 2011 15:55:13 +0000
Subject: [issue11764] inspect.getattr_static code execution w/ class body as
	non dict
In-Reply-To: <1301949322.52.0.106729359313.issue11764@psf.upfronthosting.co.za>
Message-ID: <1302278113.21.0.893504002732.issue11764@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I shot too fast, you were right.  The mapping returned by __prepare__ is used during class creation, but __dict__ on the instance is a basic dict afterwards (not sure the doc is clear, I tested it in a shell).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11764>
_______________________________________

From report at bugs.python.org  Fri Apr  8 17:55:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Apr 2011 15:55:46 +0000
Subject: [issue11802] filecmp.cmp needs a documented way to clear cache
In-Reply-To: <1302233844.4.0.517722747064.issue11802@psf.upfronthosting.co.za>
Message-ID: <1302278146.43.0.358262898512.issue11802@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11802>
_______________________________________

From report at bugs.python.org  Fri Apr  8 17:56:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Apr 2011 15:56:19 +0000
Subject: [issue11797] 2to3 does not correct "reload"
In-Reply-To: <1302191844.85.0.922084217825.issue11797@psf.upfronthosting.co.za>
Message-ID: <1302278179.77.0.437495636935.issue11797@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11797>
_______________________________________

From report at bugs.python.org  Fri Apr  8 17:56:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Apr 2011 15:56:34 +0000
Subject: [issue11797] 2to3 does not correct "reload"
In-Reply-To: <1302191844.85.0.922084217825.issue11797@psf.upfronthosting.co.za>
Message-ID: <1302278194.32.0.851231762755.issue11797@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11797>
_______________________________________

From report at bugs.python.org  Fri Apr  8 18:05:18 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 08 Apr 2011 16:05:18 +0000
Subject: [issue11764] inspect.getattr_static code execution w/ class body as
	non dict
In-Reply-To: <1301949322.52.0.106729359313.issue11764@psf.upfronthosting.co.za>
Message-ID: <1302278718.68.0.508784557775.issue11764@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11764>
_______________________________________

From report at bugs.python.org  Fri Apr  8 18:05:38 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 08 Apr 2011 16:05:38 +0000
Subject: [issue11700] mailbox.py proxy updates
In-Reply-To: <1302194512.48.0.667616632922.issue11700@psf.upfronthosting.co.za>
Message-ID: <20110408155603.GA10017@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

(Hrmpf, it seems a '>>> class y(io.RawIOBase):' line has been 
swallowed in at least Roundup.)

So here is the rewritten .yeah-2.diff. 
It drops the ._trackpos stuff once again due to problems with 
position tracking in case of failures, i.e. to go that path to the 
end a whole bunch of try..catch would have been necessary. 
So this is very expensive but let's hope the OS VFS is smarter 
than we are so that this ends up as two mostly no-op syscalls. 
:-(

I added more tests (i'm absolutely convinced that the tests i've 
found in test_mailbox.py really find all the cutting edges <;). 
On my box this is clean. 
(It's again a rewrite so it needs at least another review before 
i would ship that out, on the other hand.)

----------
Added file: http://bugs.python.org/file21583/11700.yeah-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11700>
_______________________________________
-------------- next part --------------
diff --git a/Lib/mailbox.py b/Lib/mailbox.py
--- a/Lib/mailbox.py
+++ b/Lib/mailbox.py
@@ -1864,97 +1864,137 @@
     """Message with MMDF-specific properties."""
 
 
-class _ProxyFile:
-    """A read-only wrapper of a file."""
+class _ProxyFile(io.RawIOBase):
+    """A io.RawIOBase inheriting read-only wrapper for a seekable file.
+    It supports __iter__() and the context-manager protocol.
+    """
+    def __init__(self, file, pos=None):
+        """If pos is not None then the file will keep track of its position."""
+        io.RawIOBase.__init__(self)
+        self._file = file
+        self._pos = file.tell() if pos is None else pos
+        self._close = True
+        self._is_open = True
 
-    def __init__(self, f, pos=None):
-        """Initialize a _ProxyFile."""
-        self._file = f
-        if pos is None:
-            self._pos = f.tell()
+    def _set_noclose(self):
+        """Subclass hook - use to avoid closing internal file object."""
+        self._close = False
+
+    def _closed_check(self):
+        """Raise ValueError if not open."""
+        if not self._is_open:
+            raise ValueError('I/O operation on closed file')
+
+    def close(self):
+        if self._close:
+            self._close = False
+            self._file.close()
+            del self._file
+        self._is_open = False
+
+    @property
+    def closed(self):
+        return not self._is_open
+
+    def flush(self):
+        raise io.UnsupportedOperation('flush')
+
+    def _read(self, size, read_method, readinto_arg=None):
+        if size is None or size < 0:
+            size = -1
+        self._file.seek(self._pos)
+        if not readinto_arg:
+            result = read_method(size)
         else:
-            self._pos = pos
+            if size < len(readinto_arg):
+                del readinto_arg[size:]
+            result = read_method(readinto_arg)
+            if result < len(readinto_arg):
+                del readinto_arg[result:]
+        self._pos = self._file.tell()
+        return result
 
-    def read(self, size=None):
-        """Read bytes."""
+    def readable(self):
+        self._closed_check()
+        return True
+
+    def read(self, size=-1):
+        self._closed_check()
+        if size is None or size < 0:
+            return self.readall()
         return self._read(size, self._file.read)
 
-    def read1(self, size=None):
-        """Read bytes."""
-        return self._read(size, self._file.read1)
+    def readinto(self, by_arr):
+        self._closed_check()
+        return self._read(len(by_arr), self._file.readinto, by_arr)
 
-    def readline(self, size=None):
-        """Read a line."""
+    def readall(self):
+        self._closed_check()
+        self._file.seek(self._pos)
+        if hasattr(self._file, 'readall'):
+            result = self._file.readall()
+        else:
+            dl = []
+            while 1:
+                i = self._file.read(8192)
+                if len(i) == 0:
+                    break
+                dl.append(i)
+            result = b''.join(dl)
+        self._pos = self._file.tell()
+        return result
+
+    def readline(self, size=-1):
+        self._closed_check()
         return self._read(size, self._file.readline)
 
-    def readlines(self, sizehint=None):
-        """Read multiple lines."""
+    def readlines(self, sizehint=-1):
         result = []
         for line in self:
             result.append(line)
-            if sizehint is not None:
+            if sizehint >= 0:
                 sizehint -= len(line)
                 if sizehint <= 0:
                     break
         return result
 
+    def seekable(self):
+        self._closed_check()
+        return True
+
+    def seek(self, offset, whence=0):
+        self._closed_check()
+        if whence == 1:
+            self._file.seek(self._pos)
+        self._pos = self._file.seek(offset, whence)
+        return self._pos
+
+    def tell(self):
+        self._closed_check()
+        return self._pos
+
+    def writable(self):
+        self._closed_check()
+        return False
+
+    def writelines(self, lines):
+        raise io.UnsupportedOperation('writelines')
+
+    def write(self, b):
+        raise io.UnsupportedOperation('write')
+
     def __iter__(self):
-        """Iterate over lines."""
         while True:
             line = self.readline()
             if not line:
                 raise StopIteration
             yield line
 
-    def tell(self):
-        """Return the position."""
-        return self._pos
-
-    def seek(self, offset, whence=0):
-        """Change position."""
-        if whence == 1:
-            self._file.seek(self._pos)
-        self._file.seek(offset, whence)
-        self._pos = self._file.tell()
-
-    def close(self):
-        """Close the file."""
-        if hasattr(self._file, 'close'):
-            self._file.close()
-        del self._file
-
-    def _read(self, size, read_method):
-        """Read size bytes using read_method."""
-        if size is None:
-            size = -1
-        self._file.seek(self._pos)
-        result = read_method(size)
-        self._pos = self._file.tell()
-        return result
-
     def __enter__(self):
-        """Context manager protocol support."""
         return self
-
     def __exit__(self, *exc):
         self.close()
 
-    def readable(self):
-        return self._file.readable()
-
-    def writable(self):
-        return self._file.writable()
-
-    def seekable(self):
-        return self._file.seekable()
-
-    def flush(self):
-        return self._file.flush()
-
-    @property
-    def closed(self):
-        return self._file.closed
-
 
 class _PartialFile(_ProxyFile):
     """A read-only wrapper of part of a file."""
@@ -1962,6 +2002,7 @@
     def __init__(self, f, start=None, stop=None):
         """Initialize a _PartialFile."""
         _ProxyFile.__init__(self, f, start)
+        super()._set_noclose()
         self._start = start
         self._stop = stop
 
@@ -1971,6 +2012,7 @@
 
     def seek(self, offset, whence=0):
         """Change position, possibly with respect to start or stop."""
+        self._closed_check()
         if whence == 0:
             self._pos = self._start
             whence = 1
@@ -1979,20 +2021,21 @@
             whence = 1
         _ProxyFile.seek(self, offset, whence)
 
-    def _read(self, size, read_method):
+    def _read(self, size, read_method, readinto_arg=None):
         """Read size bytes using read_method, honoring start and stop."""
         remaining = self._stop - self._pos
         if remaining <= 0:
             return b''
         if size is None or size < 0 or size > remaining:
             size = remaining
-        return _ProxyFile._read(self, size, read_method)
+        return _ProxyFile._read(self, size, read_method, readinto_arg)
 
-    def close(self):
-        # do *not* close the underlying file object for partial files,
-        # since it's global to the mailbox object
-        del self._file
-
+    def readall(self):
+        self._closed_check()
+        remaining = self._stop - self._pos
+        if remaining <= 0:
+            return b''
+        return _ProxyFile._read(self, remaining, self._file.read)
 
 def _lock_file(f, dotlock=True):
     """Lock file f using lockf and dot locking."""
diff --git a/Lib/test/test_mailbox.py b/Lib/test/test_mailbox.py
--- a/Lib/test/test_mailbox.py
+++ b/Lib/test/test_mailbox.py
@@ -290,12 +290,17 @@
         key1 = self._box.add(_sample_message)
         with self._box.get_file(key0) as file:
             data0 = file.read()
-        with self._box.get_file(key1) as file:
-            data1 = file.read()
+        file1 = self._box.get_file(key1)
+        data1 = file1.read()
         self.assertEqual(data0.decode('ascii').replace(os.linesep, '\n'),
                          self._template % 0)
         self.assertEqual(data1.decode('ascii').replace(os.linesep, '\n'),
                          _sample_message)
+        file1.close()
+        try:
+            file1.close()
+        except:
+            self.fail('.close() doesn\'t handle multiple invocations')
 
     def test_iterkeys(self):
         # Get keys using iterkeys()
@@ -1774,6 +1779,55 @@
         proxy.seek(2)
         self.assertEqual(proxy.read(1000), b'r')
 
+    def _test_readinto(self, proxy):
+        # Fill in bytearray
+        proxy.seek(0)
+        ba = bytearray(3)
+        self.assertEqual(proxy.readinto(ba), 3)
+        self.assertEqual(ba, b'bar')
+
+        proxy.seek(1)
+        ba = bytearray(2)
+        self.assertEqual(proxy.readinto(ba), 2)
+        self.assertEqual(ba, b'ar')
+
+        proxy.seek(0)
+        ba = bytearray(2)
+        self.assertEqual(proxy.readinto(ba), 2)
+        self.assertEqual(ba, b'ba')
+
+        proxy.seek(0)
+        ba = bytearray(2)
+        self.assertEqual(proxy.readinto(ba), 2)
+        self.assertEqual(ba, b'ba')
+
+        proxy.seek(1)
+        ba = bytearray(1000)
+        self.assertEqual(proxy.readinto(ba), 2)
+        self.assertEqual(ba, b'ar')
+
+        proxy.seek(2)
+        ba = bytearray(1000)
+        self.assertEqual(proxy.readinto(ba), 1)
+        self.assertEqual(ba, b'r')
+
+    def _test_readall(self, proxy):
+        # Read all the data
+        ls = os.linesep.encode()
+        lsl = len(ls)
+
+        proxy.seek(0)
+        x = b'fiesta' + ls + b'mexicana' + ls
+        self.assertEqual(proxy.readall(), x)
+
+        proxy.seek(6 + lsl)
+        x = b'mexicana' + ls
+        self.assertEqual(proxy.readall(), x)
+
+        proxy.seek(6+3 + lsl)
+        x = b'icana' + ls
+        self.assertEqual(proxy.readall(), x)
+
     def _test_readline(self, proxy):
         # Read by line
         linesep = os.linesep.encode()
@@ -1833,10 +1887,36 @@
         self.assertFalse(proxy.read())
 
     def _test_close(self, proxy):
-        # Close a file
+        self.assertFalse(proxy.closed)
+        self.assertRaises(io.UnsupportedOperation, proxy.flush)
+        self.assertTrue(proxy.readable())
+        self.assertTrue(proxy.seekable())
+        self.assertRaises(io.UnsupportedOperation, proxy.truncate, 0)
+        self.assertFalse(proxy.writable())
+        self.assertRaises(io.UnsupportedOperation, proxy.writelines, ['AU'])
+        self.assertRaises(io.UnsupportedOperation, proxy.write, 'AU')
+
         proxy.close()
-        self.assertRaises(AttributeError, lambda: proxy.close())
+        self.assertTrue(proxy.closed)
+        try:
+            proxy.close()
+        except:
+            self.fail('Proxy.close() failure')
 
+        self.assertRaises(io.UnsupportedOperation, proxy.flush)
+        self.assertRaises(ValueError, proxy.readable)
+        self.assertRaises(ValueError, proxy.read)
+        self.assertRaises(ValueError, proxy.readinto, bytearray())
+        self.assertRaises(ValueError, proxy.readall)
+        self.assertRaises(ValueError, proxy.readline)
+        self.assertRaises(ValueError, proxy.readlines)
+        self.assertRaises(ValueError, proxy.seekable)
+        self.assertRaises(ValueError, proxy.seek, 0)
+        self.assertRaises(ValueError, proxy.tell)
+        self.assertRaises(io.UnsupportedOperation, proxy.truncate, 0)
+        self.assertRaises(ValueError, proxy.writable)
+        self.assertRaises(io.UnsupportedOperation, proxy.writelines, ['AU'])
+        self.assertRaises(io.UnsupportedOperation, proxy.write, 'AU')
 
 class TestProxyFile(TestProxyFileBase):
 
@@ -1863,6 +1943,15 @@
         self._file.write(b'bar')
         self._test_read(mailbox._ProxyFile(self._file))
 
+    def test_readinto(self):
+        self._file.write(b'bar')
+        self._test_readinto(mailbox._ProxyFile(self._file))
+
+    def test_readall(self):
+        ls = os.linesep.encode()
+        self._file.write(b'fiesta' + ls + b'mexicana' + ls)
+        self._test_readall(mailbox._ProxyFile(self._file))
+
     def test_readline(self):
         self._file.write(bytes('foo%sbar%sfred%sbob' % (os.linesep, os.linesep,
                                                   os.linesep), 'ascii'))
@@ -1886,6 +1975,13 @@
         self._file.write(bytes('foo%sbar%s' % (os.linesep, os.linesep), 'ascii'))
         self._test_close(mailbox._ProxyFile(self._file))
 
+    def test_ctxman(self):
+        self._file.write(b'foo')
+        proxy = mailbox._ProxyFile(self._file)
+        with proxy as p:
+            pass
+        self.assertTrue(proxy.closed)
+
 
 class TestPartialFile(TestProxyFileBase):
 
@@ -1909,6 +2005,16 @@
         self._file.write(bytes('***bar***', 'ascii'))
         self._test_read(mailbox._PartialFile(self._file, 3, 6))
 
+    def test_readinto(self):
+        self._file.write(b'***bar***')
+        self._test_readinto(mailbox._PartialFile(self._file, 3, 6))
+
+    def test_readall(self):
+        ls = os.linesep.encode()
+        lsl = len(ls)
+        self._file.write(b'***fiesta' + ls + b'mexicana' + ls + b'***')
+        self._test_readall(mailbox._PartialFile(self._file, 3, 3+14+2*lsl))
+
     def test_readline(self):
         self._file.write(bytes('!!!!!foo%sbar%sfred%sbob!!!!!' %
                          (os.linesep, os.linesep, os.linesep), 'ascii'))
@@ -1937,6 +2043,14 @@
         self._test_close(mailbox._PartialFile(self._file, 1,
                                               6 + 3 * len(os.linesep)))
 
+    def test_ctxman(self):
+        self._file.write(bytes('foo' + os.linesep + 'bar', 'ascii'))
+        pos = self._file.tell()
+        proxy = mailbox._PartialFile(self._file, 2, 5)
+        with proxy as p:
+            pass
+        self.assertTrue(proxy.closed)
+
 
 ## Start: tests from the original module (for backward compatibility).
 

From report at bugs.python.org  Fri Apr  8 18:09:55 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 08 Apr 2011 16:09:55 +0000
Subject: [issue11770] inspect.dir_static
In-Reply-To: <1302001735.74.0.572603626553.issue11770@psf.upfronthosting.co.za>
Message-ID: <1302278995.86.0.473753480515.issue11770@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11770>
_______________________________________

From report at bugs.python.org  Fri Apr  8 18:16:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Apr 2011 16:16:48 +0000
Subject: [issue11796] list and generator expressions in a class definition
	fail if expression condition refers to a class variable
In-Reply-To: <1302180921.17.0.22284518515.issue11796@psf.upfronthosting.co.za>
Message-ID: <1302279408.45.0.239859505633.issue11796@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11796>
_______________________________________

From report at bugs.python.org  Fri Apr  8 18:20:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Apr 2011 16:20:28 +0000
Subject: [issue11792] asyncore module print to stdout
In-Reply-To: <1302164547.51.0.00796675638599.issue11792@psf.upfronthosting.co.za>
Message-ID: <1302279628.66.0.464985853006.issue11792@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Some guidance on print vs. warnings vs. logging on http://docs.python.org/dev/howto/logging#when-to-use-logging

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11792>
_______________________________________

From report at bugs.python.org  Fri Apr  8 18:26:26 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 08 Apr 2011 16:26:26 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1302279986.63.0.961762086808.issue11277@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Fri Apr  8 18:54:38 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 08 Apr 2011 16:54:38 +0000
Subject: [issue11802] filecmp.cmp needs a documented way to clear cache
In-Reply-To: <1302233844.4.0.517722747064.issue11802@psf.upfronthosting.co.za>
Message-ID: <1302281678.65.0.495646413999.issue11802@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Patch for 3.3 and 3.2

----------
keywords: +patch
Added file: http://bugs.python.org/file21584/filecmp-lru-cache-3.3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11802>
_______________________________________

From report at bugs.python.org  Fri Apr  8 18:56:00 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 08 Apr 2011 16:56:00 +0000
Subject: [issue11802] filecmp.cmp needs a documented way to clear cache
In-Reply-To: <1302233844.4.0.517722747064.issue11802@psf.upfronthosting.co.za>
Message-ID: <1302281760.13.0.294856759354.issue11802@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Patch for 2.7.

----------
Added file: http://bugs.python.org/file21585/filecmp-lru-cache-2.7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11802>
_______________________________________

From report at bugs.python.org  Fri Apr  8 18:56:15 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 08 Apr 2011 16:56:15 +0000
Subject: [issue11796] list and generator expressions in a class definition
	fail if expression condition refers to a class variable
In-Reply-To: <1302180921.17.0.22284518515.issue11796@psf.upfronthosting.co.za>
Message-ID: <1302281775.35.0.0226082671468.issue11796@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11796>
_______________________________________

From report at bugs.python.org  Fri Apr  8 18:56:51 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 08 Apr 2011 16:56:51 +0000
Subject: [issue11802] filecmp.cmp needs a documented way to clear cache
In-Reply-To: <1302233844.4.0.517722747064.issue11802@psf.upfronthosting.co.za>
Message-ID: <1302281811.09.0.188399970774.issue11802@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11802>
_______________________________________

From report at bugs.python.org  Fri Apr  8 19:10:00 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 08 Apr 2011 17:10:00 +0000
Subject: [issue11802] filecmp.cmp needs a documented way to clear cache
In-Reply-To: <1302233844.4.0.517722747064.issue11802@psf.upfronthosting.co.za>
Message-ID: <1302282600.02.0.601225411577.issue11802@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Oops, there was a typo in the 2.7 patch ("import _thread" instead of
"import thread"). Corrected patch attached.

----------
Added file: http://bugs.python.org/file21586/filecmp-lru-cache-2.7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11802>
_______________________________________

From report at bugs.python.org  Fri Apr  8 19:24:23 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Fri, 08 Apr 2011 17:24:23 +0000
Subject: [issue6931] dreadful performance in difflib: ndiff and HtmlDiff
In-Reply-To: <1301753062.68.0.366332141157.issue6931@psf.upfronthosting.co.za>
Message-ID: <BANLkTinbjcMSVkBekHjO3s2avx_iw8Z-kw@mail.gmail.com>


Charles-Francois Natali <neologix at free.fr> added the comment:

> Check also this:
>
> http://bugs.python.org/issue11740

You should indicate it as duplicate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6931>
_______________________________________

From report at bugs.python.org  Fri Apr  8 19:25:55 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Fri, 08 Apr 2011 17:25:55 +0000
Subject: [issue6931] dreadful performance in difflib: ndiff and HtmlDiff
In-Reply-To: <1253199298.69.0.280559653373.issue6931@psf.upfronthosting.co.za>
Message-ID: <1302283555.98.0.629562270168.issue6931@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I have no idea how I should do this. If you explain to me, how it should be done, I'll be happy to do this from now on :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6931>
_______________________________________

From report at bugs.python.org  Fri Apr  8 19:31:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Apr 2011 17:31:46 +0000
Subject: [issue11800] regrtest --timeout: apply the timeout on a function,
	not on the whole file
In-Reply-To: <1302273740.49.0.453238576927.issue11800@psf.upfronthosting.co.za>
Message-ID: <1302283903.3508.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I did a similar test on Windows: test_io takes ~19.1 sec with and
> without timeout.

You may want to test with test_argparse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11800>
_______________________________________

From report at bugs.python.org  Fri Apr  8 19:40:11 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Fri, 08 Apr 2011 17:40:11 +0000
Subject: [issue4877] xml.parsers.expat ParseFile() causes segmentation fault
	when passed a closed file object
In-Reply-To: <1231390876.07.0.554090447949.issue4877@psf.upfronthosting.co.za>
Message-ID: <1302284411.05.0.904854881754.issue4877@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

I concur. Attaching a refreshed patch (against current 2.7 branch) along with a unittest.

----------
nosy: +santa4nt
Added file: http://bugs.python.org/file21587/issue4877.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4877>
_______________________________________

From report at bugs.python.org  Fri Apr  8 19:49:23 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 08 Apr 2011 17:49:23 +0000
Subject: [issue11740] difflib html diff takes extremely long
In-Reply-To: <1301693139.57.0.361562219135.issue11740@psf.upfronthosting.co.za>
Message-ID: <1302284963.74.0.628974808241.issue11740@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> dreadful performance in difflib: ndiff and HtmlDiff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11740>
_______________________________________

From report at bugs.python.org  Fri Apr  8 20:10:16 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Fri, 08 Apr 2011 18:10:16 +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: <1302286216.71.0.496377618245.issue5166@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5166>
_______________________________________

From report at bugs.python.org  Fri Apr  8 20:10:27 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Fri, 08 Apr 2011 18:10:27 +0000
Subject: [issue11804] expat parser not xml 1.1 (breaks xmlrpclib)
In-Reply-To: <1302255183.42.0.728288108717.issue11804@psf.upfronthosting.co.za>
Message-ID: <1302286227.33.0.985154000076.issue11804@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11804>
_______________________________________

From report at bugs.python.org  Fri Apr  8 20:36:32 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 08 Apr 2011 18:36:32 +0000
Subject: [issue5907] repr of time.struct_time type does not eval
In-Reply-To: <1241281843.36.0.110450032545.issue5907@psf.upfronthosting.co.za>
Message-ID: <1302287792.11.0.829757325497.issue5907@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> Or whether to change it at all. It's hard to imagine that
> applications may rely on that aspect of the behavior - they
> have to use eval, after all.

I would like to see this fixed.  When working in interactive session, I find myself adding [:] to struct_time objects because otherwise I cannot copy the result and paste it back to CLI session.

Actually, the bigger problem for me is that struct_time repr is too verbose with repeated tm_ prefixes distracting from the data I want to see.  Chances are I will continue adding [:] or [:6] when I inspect struct_time values even if this issue gets fixed.

Overall I am +0 on fixing this.

----------
assignee: belopolsky -> 
priority: normal -> low
stage:  -> needs patch
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5907>
_______________________________________

From report at bugs.python.org  Fri Apr  8 20:40:36 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 08 Apr 2011 18:40:36 +0000
Subject: [issue11388] Implement MutableSequence.clear()
In-Reply-To: <1299177407.5.0.868573551727.issue11388@psf.upfronthosting.co.za>
Message-ID: <1302288036.67.0.28126405565.issue11388@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11388>
_______________________________________

From report at bugs.python.org  Fri Apr  8 20:43:12 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 08 Apr 2011 18:43:12 +0000
Subject: [issue9904] Cosmetic issues that may warrant a fix in symtable.h/c
In-Reply-To: <1284964146.62.0.95975690396.issue9904@psf.upfronthosting.co.za>
Message-ID: <1302288192.55.0.212995461241.issue9904@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Terry, Nick - is it OK to commit a fix for the comments?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9904>
_______________________________________

From report at bugs.python.org  Fri Apr  8 21:32:24 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 08 Apr 2011 19:32:24 +0000
Subject: [issue11783] email parseaddr and formataddr should be IDNA aware
In-Reply-To: <1302099121.47.0.140525796896.issue11783@psf.upfronthosting.co.za>
Message-ID: <1302291144.29.0.322170822937.issue11783@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

If Torsten does not have time for this i'll do that next.
I hate this useless Punycode (but for nameprep),
so it's exactly the right thing for me to do next in 2011.
Unless someone complains.
I've not looked at formataddr/parseaddr, so that's a motivation.
Torsten?

----------
nosy: +sdaoden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11783>
_______________________________________

From report at bugs.python.org  Fri Apr  8 21:51:21 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Fri, 08 Apr 2011 19:51:21 +0000
Subject: [issue5907] repr of time.struct_time type does not eval
In-Reply-To: <1241281843.36.0.110450032545.issue5907@psf.upfronthosting.co.za>
Message-ID: <1302292281.41.0.333375651306.issue5907@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

I have a feeling that a successful resolution of issue 1820 will make things simpler for this one, since time.struct_time uses structseq.

----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5907>
_______________________________________

From report at bugs.python.org  Fri Apr  8 21:51:33 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Fri, 08 Apr 2011 19:51:33 +0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and
	tuple	api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1302292293.98.0.252078644797.issue1820@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1820>
_______________________________________

From report at bugs.python.org  Fri Apr  8 21:55:53 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 08 Apr 2011 19:55:53 +0000
Subject: [issue11466] getpass.getpass doesn't close tty file
In-Reply-To: <1299844492.32.0.259676792362.issue11466@psf.upfronthosting.co.za>
Message-ID: <1302292553.22.0.38771033404.issue11466@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Future Buddha to Guru..
Future Buddha to Guru..
My code is like a two-wheeled indian Bullet, royal purple.
Wouldn't you agree with that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11466>
_______________________________________

From report at bugs.python.org  Fri Apr  8 22:22:50 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Apr 2011 20:22:50 +0000
Subject: [issue11783] email parseaddr and formataddr should be IDNA aware
In-Reply-To: <1302099121.47.0.140525796896.issue11783@psf.upfronthosting.co.za>
Message-ID: <1302294170.4.0.454389684878.issue11783@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I believe Torsten is interested, but he can of course speak for himself.

Just to make sure you are aware: Python has a built in idna codec, so this should be a fairly simple patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11783>
_______________________________________

From report at bugs.python.org  Fri Apr  8 22:25:26 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Apr 2011 20:25:26 +0000
Subject: [issue6931] dreadful performance in difflib: ndiff and HtmlDiff
In-Reply-To: <1253199298.69.0.280559653373.issue6931@psf.upfronthosting.co.za>
Message-ID: <1302294326.76.0.852313696463.issue6931@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Filip, you can look at the changed Benjamin made. One needs to be OP or have admin privileges to change the headers.

Could you reupload your patch to this issue?

----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6931>
_______________________________________

From report at bugs.python.org  Fri Apr  8 22:28:43 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Fri, 08 Apr 2011 20:28:43 +0000
Subject: [issue6931] dreadful performance in difflib: ndiff and HtmlDiff
In-Reply-To: <1253199298.69.0.280559653373.issue6931@psf.upfronthosting.co.za>
Message-ID: <1302294523.48.0.434220566889.issue6931@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Here it is.

----------
keywords: +patch
Added file: http://bugs.python.org/file21588/11740.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6931>
_______________________________________

From report at bugs.python.org  Fri Apr  8 22:53:05 2011
From: report at bugs.python.org (Jonathan Hartley)
Date: Fri, 08 Apr 2011 20:53:05 +0000
Subject: [issue11796] list and generator expressions in a class definition
	fail if expression condition refers to a class variable
In-Reply-To: <1302180921.17.0.22284518515.issue11796@psf.upfronthosting.co.za>
Message-ID: <1302295985.4.0.655481497349.issue11796@psf.upfronthosting.co.za>


Jonathan Hartley <tartley at tartley.com> added the comment:

Is also exhibited by other class variable being used in the 'output' clause of the list comprehension:

>>> class C:
...     x = 3
...     z = [z*x for z in range(4)]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in C
  File "<stdin>", line 3, in <listcomp>

----------
nosy: +jonathan.hartley
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11796>
_______________________________________

From report at bugs.python.org  Fri Apr  8 22:53:39 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Fri, 08 Apr 2011 20:53:39 +0000
Subject: [issue11796] list and generator expressions in a class definition
	fail if expression condition refers to a class variable
In-Reply-To: <1302180921.17.0.22284518515.issue11796@psf.upfronthosting.co.za>
Message-ID: <1302296019.17.0.018881127345.issue11796@psf.upfronthosting.co.za>


Changes by Andreas St?hrk <andy-python at hammerhartes.de>:


----------
nosy: +Trundle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11796>
_______________________________________

From report at bugs.python.org  Fri Apr  8 22:55:36 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Apr 2011 20:55:36 +0000
Subject: [issue9904] Cosmetic issues that may warrant a fix in symtable.h/c
In-Reply-To: <1284964146.62.0.95975690396.issue9904@psf.upfronthosting.co.za>
Message-ID: <1302296136.8.0.0131642807739.issue9904@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I would say yes (if you are sure changes are correct) unless Nick speaks up to say he wants to review first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9904>
_______________________________________

From report at bugs.python.org  Fri Apr  8 22:58:49 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 08 Apr 2011 20:58:49 +0000
Subject: [issue11796] list and generator expressions in a class definition
	fail if expression condition refers to a class variable
In-Reply-To: <1302180921.17.0.22284518515.issue11796@psf.upfronthosting.co.za>
Message-ID: <1302296329.84.0.437847099004.issue11796@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11796>
_______________________________________

From report at bugs.python.org  Fri Apr  8 23:03:51 2011
From: report at bugs.python.org (Torsten Becker)
Date: Fri, 08 Apr 2011 21:03:51 +0000
Subject: [issue11783] email parseaddr and formataddr should be IDNA aware
In-Reply-To: <1302294170.4.0.454389684878.issue11783@psf.upfronthosting.co.za>
Message-ID: <BANLkTinG_gDQGL8YQ6c1t060YC6B-A7DUg@mail.gmail.com>


Torsten Becker <torsten.becker at gmail.com> added the comment:

I was about to look into this over the weekend, but of course I don't
want to steal your fun, Steffen. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11783>
_______________________________________

From report at bugs.python.org  Fri Apr  8 23:17:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Apr 2011 21:17:32 +0000
Subject: [issue11800] regrtest --timeout: apply the timeout on a function,
	not on the whole file
In-Reply-To: <1302283903.3508.0.camel@localhost.localdomain>
Message-ID: <1302297447.29634.5.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le vendredi 08 avril 2011 ? 17:31 +0000, Antoine Pitrou a ?crit :
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> > I did a similar test on Windows: test_io takes ~19.1 sec with and
> > without timeout.
> 
> You may want to test with test_argparse.

Oh... test_argparse has 1608 test! Benchmark on Linux:
- without timeout: 18.931 sec
- with timeout/function call: 19.436 sec

So on this test suite, the overhead is 2.7%. The current timeout
implementation has an overhead near 0% on the same test suite (I tried
to compute the overhead, but I found -0.2% which looks wrong :-)).

I'm too lazy to start Windows for another benchmark tonight.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11800>
_______________________________________

From report at bugs.python.org  Sat Apr  9 00:05:46 2011
From: report at bugs.python.org (Jon Parise)
Date: Fri, 08 Apr 2011 22:05:46 +0000
Subject: [issue5755] "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for
	C++"
In-Reply-To: <1239729771.84.0.97828652099.issue5755@psf.upfronthosting.co.za>
Message-ID: <1302300346.19.0.764669922983.issue5755@psf.upfronthosting.co.za>


Changes by Jon Parise <jon at indelible.org>:


----------
nosy: +jon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5755>
_______________________________________

From report at bugs.python.org  Sat Apr  9 00:22:42 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Apr 2011 22:22:42 +0000
Subject: [issue11747] unified_diff function product incorrect range information
In-Reply-To: <1301806636.68.0.728514553962.issue11747@psf.upfronthosting.co.za>
Message-ID: <1302301362.31.0.404693206301.issue11747@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

@Tim: was it your intention that difflib track gnu diff?

I am on the fence with this issue. Without input from Tim other than the doc, I am tempted to call this a feature request and retitle it "Make unified_diff match gnu diff for [] input". The docs do not reference external definitions for context-diff and unified-diff. The entry for unified-diff does not give a format for the @@ control lines. So the current behavior cannot be said to violate the doc spec.

On the other hand, putting random garbage on @@ lines would clearly be a bug, so the doc must be taken as referencing some external definition, even if vague.
 
https://secure.wikimedia.org/wikipedia/en/wiki/Diff#Unified_format
says "Unified context diffs were originally developed by Wayne Davison in August 1990 (in unidiff which appeared in Volume 14 of comp.sources.misc). Richard Stallman added unified diff support to the GNU Project's diff utility one month later,". So using gnu diff as a standard is not unreasonable. (But did it give 0,0 for null files from the beginning?)

Now looking practically. If nothing but patch programs ever read and act on the control blocks, then, say Ray, a change would neither hurt nor be of any use. If any Python code does look, then a change could break code. I would in any case be reluntant to change 2.7. 

But if this is treated as a feature request and only 3.3 swere changed, then we would have to document the change:
"Version changed 3.3: for empty lists, the @@ block specification was changed from 1,0 to 0,0", which is pretty close to adding useless noise.
3.0 would have been the best time to make this change.

----------
nosy: +terry.reedy, tim_one
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11747>
_______________________________________

From report at bugs.python.org  Sat Apr  9 00:23:49 2011
From: report at bugs.python.org (Erik Bray)
Date: Fri, 08 Apr 2011 22:23:49 +0000
Subject: [issue11805] package_data only allows one glob per-package
In-Reply-To: <1302301429.27.0.797210396018.issue11805@psf.upfronthosting.co.za>
Message-ID: <1302301429.27.0.797210396018.issue11805@psf.upfronthosting.co.za>


New submission from Erik Bray <erik.m.bray at gmail.com>:

In distutils the package_data option can be supplied a list of glob patterns for each package.  distutils2 currently only supports one glob per package.

This could easily be fixed by simply allowing more than one `package_name = pattern` value in the package_data option.  For example:

package_data =
    mypackage = templates/*.html
    mypackage = static/css/*.css
    mypackage.subpackage = templates/*.html
    ...

----------
assignee: tarek
components: Distutils2
hgrepos: 16
messages: 133346
nosy: alexis, eric.araujo, erik.bray, tarek
priority: normal
severity: normal
status: open
title: package_data only allows one glob per-package
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11805>
_______________________________________

From report at bugs.python.org  Sat Apr  9 00:36:16 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Apr 2011 22:36:16 +0000
Subject: [issue11754] Changed test to check calculated constants in
	test_string.py
In-Reply-To: <1301860347.11.0.319603986002.issue11754@psf.upfronthosting.co.za>
Message-ID: <1302302176.84.0.35056799423.issue11754@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I do not understand 'circular'. The change is from 'attribute exists' to 'attribute has correct value'. If any are changed, I would think all should be changed.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11754>
_______________________________________

From report at bugs.python.org  Sat Apr  9 00:36:47 2011
From: report at bugs.python.org (Bryce Verdier)
Date: Fri, 08 Apr 2011 22:36:47 +0000
Subject: [issue4877] xml.parsers.expat ParseFile() causes segmentation fault
	when passed a closed file object
In-Reply-To: <1231390876.07.0.554090447949.issue4877@psf.upfronthosting.co.za>
Message-ID: <1302302207.87.0.575744970629.issue4877@psf.upfronthosting.co.za>


Bryce Verdier <bryceverdier at gmail.com> added the comment:

Modified patch to remove PyErr_SetString() as it doesn't do anything. Patch looks good to me otherwise and ran without issue.

----------
Added file: http://bugs.python.org/file21589/issue4877.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4877>
_______________________________________

From report at bugs.python.org  Sat Apr  9 00:46:22 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 08 Apr 2011 22:46:22 +0000
Subject: [issue11804] expat parser not xml 1.1 (breaks xmlrpclib)
In-Reply-To: <1302255183.42.0.728288108717.issue11804@psf.upfronthosting.co.za>
Message-ID: <1302302782.01.0.358348272367.issue11804@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/issue11804>
_______________________________________

From report at bugs.python.org  Sat Apr  9 00:56:51 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Fri, 08 Apr 2011 22:56:51 +0000
Subject: [issue4877] xml.parsers.expat ParseFile() causes segmentation fault
	when passed a closed file object
In-Reply-To: <1231390876.07.0.554090447949.issue4877@psf.upfronthosting.co.za>
Message-ID: <1302303411.07.0.576597850231.issue4877@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

You mean, PyErr_Clear()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4877>
_______________________________________

From report at bugs.python.org  Sat Apr  9 01:00:26 2011
From: report at bugs.python.org (Bryce Verdier)
Date: Fri, 08 Apr 2011 23:00:26 +0000
Subject: [issue4877] xml.parsers.expat ParseFile() causes segmentation fault
	when passed a closed file object
In-Reply-To: <1231390876.07.0.554090447949.issue4877@psf.upfronthosting.co.za>
Message-ID: <1302303626.92.0.211115427718.issue4877@psf.upfronthosting.co.za>


Bryce Verdier <bryceverdier at gmail.com> added the comment:

Yes I did. Sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4877>
_______________________________________

From report at bugs.python.org  Sat Apr  9 01:02:13 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 08 Apr 2011 23:02:13 +0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and
	tuple	api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1302303733.63.0.616003496153.issue1820@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Issue5907 would benefit of this change.
Unfortunately, structseq constructors already have keyword arguments; they are equivalent to "def __new__(cls, sequence, dict=NULL)".
OTOH these keywords arguments are not documented anywhere.

I suggest to change the constructor to something equivalent to:
"def __new__(cls, sequence=NULL, dict=NULL, *, field1=NULL,  field2=NULL)"

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1820>
_______________________________________

From report at bugs.python.org  Sat Apr  9 01:02:42 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 08 Apr 2011 23:02:42 +0000
Subject: [issue5907] repr of time.struct_time type does not eval
In-Reply-To: <1241281843.36.0.110450032545.issue5907@psf.upfronthosting.co.za>
Message-ID: <1302303762.85.0.743795400636.issue5907@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
dependencies: +Enhance Object/structseq.c to match namedtuple and tuple	api

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5907>
_______________________________________

From report at bugs.python.org  Sat Apr  9 01:10:19 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Apr 2011 23:10:19 +0000
Subject: [issue11776] types.MethodType() params and usage is not documented
In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za>
Message-ID: <1302304219.04.0.110922169366.issue11776@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

All the types in the types module are, being types, potentially callable to produce instances of that type. But they are in types rather than builtins precisely because it is not expected that they be called directly. They are bound to names in types primarily for isinstance checks, and possibly issubclass checks. So none of their signatures are documented in types. It would be an anomaly to add something special for MethodType. So my first impulse is to close this. Do you have a source for your statement?

----------
nosy: +terry.reedy
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11776>
_______________________________________

From report at bugs.python.org  Sat Apr  9 01:21:32 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 08 Apr 2011 23:21:32 +0000
Subject: [issue11776] types.MethodType() params and usage is not documented
In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za>
Message-ID: <1302304892.21.0.7169493925.issue11776@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Message is classified as spam. I am not sure if you see it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11776>
_______________________________________

From report at bugs.python.org  Sat Apr  9 01:23:57 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 08 Apr 2011 23:23:57 +0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and
	tuple	api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1302305037.8.0.91136547998.issue1820@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Also see issue 11698

----------
assignee: jackdied -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1820>
_______________________________________

From report at bugs.python.org  Sat Apr  9 01:25:19 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 08 Apr 2011 23:25:19 +0000
Subject: [issue5907] repr of time.struct_time type does not eval
In-Reply-To: <1241281843.36.0.110450032545.issue5907@psf.upfronthosting.co.za>
Message-ID: <1302305119.28.0.144861640216.issue5907@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Also see issue11698

----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5907>
_______________________________________

From report at bugs.python.org  Sat Apr  9 01:39:36 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Apr 2011 23:39:36 +0000
Subject: [issue11782] email.generator.Generator.flatten() fails
In-Reply-To: <1302097785.46.0.28701143911.issue11782@psf.upfronthosting.co.za>
Message-ID: <1302305976.41.0.299753392384.issue11782@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The error message suggests that somehow a str string has gotten mixed in with the bytes. Something like '\n' or ' '?

Steffen, if you want to help track this down:
1. What is a minimal msgdata that gives the same error; post it.
2. Add 'print(payload)' before line 304: self._fp.write(payload)
and perhaps further back to see what the offending string is and where it comes from.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11782>
_______________________________________

From report at bugs.python.org  Sat Apr  9 02:04:15 2011
From: report at bugs.python.org (Matt Joiner)
Date: Sat, 09 Apr 2011 00:04:15 +0000
Subject: [issue3831] Multiprocessing: Expose underlying pipe in queues
In-Reply-To: <1221095639.45.0.136100950642.issue3831@psf.upfronthosting.co.za>
Message-ID: <1302307455.68.0.360028644218.issue3831@psf.upfronthosting.co.za>


Changes by Matt Joiner <anacrolix at gmail.com>:


----------
nosy: +anacrolix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3831>
_______________________________________

From report at bugs.python.org  Sat Apr  9 02:13:27 2011
From: report at bugs.python.org (Matt Joiner)
Date: Sat, 09 Apr 2011 00:13:27 +0000
Subject: [issue3831] Multiprocessing: Expose underlying pipe in queues
In-Reply-To: <1221095639.45.0.136100950642.issue3831@psf.upfronthosting.co.za>
Message-ID: <1302308007.88.0.593398911118.issue3831@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

I look forward to this, or something similar. Inspiration can be taken from Golangs's select behaviour on channels.

select {
case i1 = <-c1:
	print("received ", i1, " from c1\n")
case c2 <- i2:
	print("sent ", i2, " to c2\n")

default:
	print("no communication\n")
}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3831>
_______________________________________

From report at bugs.python.org  Sat Apr  9 02:22:10 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Apr 2011 00:22:10 +0000
Subject: [issue11796] list and generator expressions in a class definition
	fail if expression condition refers to a class variable
In-Reply-To: <1302180921.17.0.22284518515.issue11796@psf.upfronthosting.co.za>
Message-ID: <1302308530.88.0.0436116215518.issue11796@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Devs are aware that there is an exception to the general rule for the 'for' clause. There is a technical reason why the exception is possible, though I have forgotten it.

Since you already know that changing the general behavior has been rejected, are you asking that the exception be removed (for consistency) , so that your first example would fail? If so, that will be rejected also.

I am changing this to a doc issue in case you or someone else wishes to suggest a doc improvement.

The solution to the limitation on generator expressions, of course, is to write out the generator one is trying to abbreviate.

def clipper(max):
    for i in range(5):
        if i < max:
            yield i

class Foo:
    x = 3
    y = list(clipper(x))

print(Foo.y)
# [0, 1, 2]

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python, terry.reedy
stage:  -> needs patch
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11796>
_______________________________________

From report at bugs.python.org  Sat Apr  9 02:29:52 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 09 Apr 2011 00:29:52 +0000
Subject: [issue11782] email.generator.Generator.flatten() fails
In-Reply-To: <1302097785.46.0.28701143911.issue11782@psf.upfronthosting.co.za>
Message-ID: <1302308992.31.0.0535940003353.issue11782@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Terry, the test is in the other issue, so this time Steffen has provided the test :).

I'll take a look at both issues, probably next week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11782>
_______________________________________

From report at bugs.python.org  Sat Apr  9 02:31:27 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Apr 2011 00:31:27 +0000
Subject: [issue11796] Comprehensions in a class definition mostly cannot
	access class variable
In-Reply-To: <1302180921.17.0.22284518515.issue11796@psf.upfronthosting.co.za>
Message-ID: <1302309087.58.0.583584173045.issue11796@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Title changed.
Generator expressions had the same limitation in 2.x.
All comprehensions have the same limitation in 3.x.

----------
title: list and generator expressions in a class definition fail if expression condition refers to a class variable -> Comprehensions in a class definition mostly cannot access class variable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11796>
_______________________________________

From report at bugs.python.org  Sat Apr  9 02:42:52 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 09 Apr 2011 00:42:52 +0000
Subject: [issue11796] Comprehensions in a class definition mostly cannot
	access class variable
In-Reply-To: <1302180921.17.0.22284518515.issue11796@psf.upfronthosting.co.za>
Message-ID: <1302309772.6.0.910712882813.issue11796@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Devs are aware that there is an exception to the general rule
>  for the 'for' clause. There is a technical reason why the 
> exception is possible, though I have forgotten it.

It is best understood when thinking about a gexexp that
gets run long after is created:

   ge = (result_exp(loop_var) for loop_var in iter_exp)
 
The idea was to have the body of the iterator expression, iter_exp, fail early, before the generator is run and while the local context is still set=up and available:

   ge = (1/0 for i in pow('a', 'b'))

We want the TypeError for pow to be raised immediately.  And if a valid expression were evaluated, we would want the body's ZeroDivisionError to be raised only when the generator is invoked using next(ge()).

In the former case, the local context is still available.  In the latter case, it could be long gone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11796>
_______________________________________

From report at bugs.python.org  Sat Apr  9 02:47:54 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Apr 2011 00:47:54 +0000
Subject: [issue4877] xml.parsers.expat ParseFile() causes segmentation fault
	when passed a closed file object
In-Reply-To: <1231390876.07.0.554090447949.issue4877@psf.upfronthosting.co.za>
Message-ID: <1302310074.26.0.213690269974.issue4877@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Elsewhere, Guido said that this appears *not* to be a security bug since the crash is "triggered by a logic bug in the user's code, not by bad data." Hence, not eligible for backport to 2.5/6, which are in security-fix only mode.

----------
nosy: +terry.reedy
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4877>
_______________________________________

From report at bugs.python.org  Sat Apr  9 02:53:03 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 09 Apr 2011 00:53:03 +0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and
	tuple	api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1302310383.86.0.124462711256.issue1820@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Hasn't this been fixed in the following changeset?

changeset:   43509:384f73a104e9
user:        Benjamin Peterson <benjamin at python.org>
date:        Wed Jul 07 20:54:01 2010 +0000
summary:     make struct sequences subclass tuple; kill lots of code

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1820>
_______________________________________

From report at bugs.python.org  Sat Apr  9 03:00:03 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Apr 2011 01:00:03 +0000
Subject: [issue11776] types.MethodType() params and usage is not documented
In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za>
Message-ID: <1302310803.64.0.348822747401.issue11776@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Messages that only consist of links are classified that way. To refer to other issues, use #xxxxx, as with #6040, but I have no idea which of the many messages you were referring to, so use msgxxxxxx.

The stack overflow link
http://stackoverflow.com/questions/972/adding-a-method-to-an-existing-object
which should be allowed given surrounding text, answers my question:
types.MethodType can be used as a replacement for 2.x new.instancemethod.

The question is where that should be mentioned. The types doc still seems like the wrong place. Perhaps somewhere in the language ref section on classes, if that is where bound methods are discussed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11776>
_______________________________________

From report at bugs.python.org  Sat Apr  9 03:00:09 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Apr 2011 01:00:09 +0000
Subject: [issue11776] types.MethodType() params and usage is not documented
In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za>
Message-ID: <1302310809.07.0.560134040277.issue11776@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
Removed message: http://bugs.python.org/msg133353

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11776>
_______________________________________

From report at bugs.python.org  Sat Apr  9 03:01:19 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Apr 2011 01:01:19 +0000
Subject: [issue11776] types.MethodType() params and usage is not documented
In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za>
Message-ID: <1302310879.93.0.354621290881.issue11776@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

For anyone curious, I removed the falsely classified as spam message after copying the links into my previous message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11776>
_______________________________________

From report at bugs.python.org  Sat Apr  9 03:02:31 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 09 Apr 2011 01:02:31 +0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and
	tuple	api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1302310951.25.0.275621951409.issue1820@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Hasn't this been fixed in the following changeset?

It was a major step forward.  Now there needs to be work on other namedtuple methods and whatnot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1820>
_______________________________________

From report at bugs.python.org  Sat Apr  9 03:04:24 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 09 Apr 2011 01:04:24 +0000
Subject: [issue4877] xml.parsers.expat ParseFile() causes segmentation fault
	when passed a closed file object
In-Reply-To: <1231390876.07.0.554090447949.issue4877@psf.upfronthosting.co.za>
Message-ID: <1302311064.79.0.516599851627.issue4877@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See also #9292.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4877>
_______________________________________

From report at bugs.python.org  Sat Apr  9 03:17:31 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 09 Apr 2011 01:17:31 +0000
Subject: [issue4877] xml.parsers.expat ParseFile() causes segmentation fault
	when passed a closed file object
In-Reply-To: <1231390876.07.0.554090447949.issue4877@psf.upfronthosting.co.za>
Message-ID: <1302311851.15.0.593693693974.issue4877@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

FWIW I tried to backport 825041fc8e2c and test_pyexpat runs without problem.
The snippet of code in msg79398 now raises a ValueError:
>>> from xml.parsers import expat
>>> f=open('/tmp/foo')
>>> p=expat.ParserCreate()
>>> f.close()
>>> p.ParseFile(f)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: I/O operation on closed file

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4877>
_______________________________________

From report at bugs.python.org  Sat Apr  9 03:29:10 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 09 Apr 2011 01:29:10 +0000
Subject: [issue4877] xml.parsers.expat ParseFile() causes segmentation fault
	when passed a closed file object
In-Reply-To: <1231390876.07.0.554090447949.issue4877@psf.upfronthosting.co.za>
Message-ID: <1302312550.45.0.158077173685.issue4877@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The attached patch combines the changes done to pyexpat in 825041fc8e2c (http://hg.python.org/cpython/diff/825041fc8e2c/Modules/pyexpat.c), the cleanup of c52f5df50448 and the tests of issue4877.patch.
The tests segfault without the changes on pyexpat, and pass once they are applied.

----------
Added file: http://bugs.python.org/file21590/issue4877-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4877>
_______________________________________

From report at bugs.python.org  Sat Apr  9 03:55:31 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Apr 2011 01:55:31 +0000
Subject: [issue11796] Comprehensions in a class definition mostly cannot
	access class variable
In-Reply-To: <1302180921.17.0.22284518515.issue11796@psf.upfronthosting.co.za>
Message-ID: <1302314131.5.0.681504806361.issue11796@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thanks. I remember now: the initial iter_exp is evaluated immediately because it always *can* be, because it is only evaluated once and can only involve 'outside' names, whereas the result expression and any conditional expressions and further iteration expressions cannot be (evaluated immediately) because in general they usually involve the loop_var and are evaluated many times, each time with a different value of the loop_var (which are not available until the code is run).

The current 3.2 doc more or less says this already, though in fewer words.

To put it another way, the iter_exp either becomes or is treated like a parameter default value expression, so that

ge = (result_exp(loop_var) for loop_var in iter_exp)

is like

def __gf__(_it=iter_exp):
    for loop_var in _it:
        yield result_exp(loop_var)
ge = __gf__()
del __gf__

I wonder if something like this should be added to 5.2.8. Generator expressions, with that section moved up before the set/list/dict displays sections, and with the comprehension grammar included therein.

If one does *not* want the immediately evaluation of the iter_exp (which does not normally happen in generator functions) then, again, one should write a generator function. 

I guess the real lesson is that in 3.x, while comprehensions (including g.e.'s are very similar to nested loops and conditions or generator functions with the same, they are not identical in scoping behavior and need to be thought of as their own thing and not only as syntactic sugar. This is probably easier for people who start with 3.x ;-).

Along that line, here is another replacement for the not-working example 2:

class Foo:
    x = 3
    y = []
    for z in range(5):
        if z < x:
            y.append(z)

print(Foo.y)
# [0, 1, 2]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11796>
_______________________________________

From report at bugs.python.org  Sat Apr  9 04:01:30 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sat, 09 Apr 2011 02:01:30 +0000
Subject: [issue11770] inspect.dir_static
In-Reply-To: <1302001735.74.0.572603626553.issue11770@psf.upfronthosting.co.za>
Message-ID: <1302314490.94.0.782015619517.issue11770@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

A first patch, misses any documentation changes. While working on it, I realised that modules technically shadow the __dict__ attribute (because modules use tp_dictoffset, hence module have a __dict__ member that points to the instance dict). I updated `_shadowed_dict()` so that it now disregards member descriptors as shadowing (as they will never trigger any code execution), but theoretically, the members can be any object (not just dicts), so I have to think a bit more about that case (as a custom object still can trigger code execution).

Also, `dir_static()` behaves slightly different from `dir()` (e.g. `dir()` raises a `TypeError` if the module's "__dict__" attribute isn't a dictionary, which is kind of impossible for `dir_static` as it doesn't even try to acccess `__dict__` if it is shadowed), but IMHO such edge-cases are expected to behave differently for a static version and hence we don't care at all about that.

----------
keywords: +patch
Added file: http://bugs.python.org/file21591/issue11770.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11770>
_______________________________________

From report at bugs.python.org  Sat Apr  9 04:38:30 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sat, 09 Apr 2011 02:38:30 +0000
Subject: [issue1228112] code.py use sys.excepthook to display exceptions
Message-ID: <1302316710.02.0.226357536243.issue1228112@psf.upfronthosting.co.za>


Changes by Andreas St?hrk <andy-python at hammerhartes.de>:


----------
nosy: +Trundle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1228112>
_______________________________________

From report at bugs.python.org  Sat Apr  9 05:20:49 2011
From: report at bugs.python.org (Tim Peters)
Date: Sat, 09 Apr 2011 03:20:49 +0000
Subject: [issue11747] unified_diff function product incorrect range information
In-Reply-To: <1301806636.68.0.728514553962.issue11747@psf.upfronthosting.co.za>
Message-ID: <1302319249.4.0.438285473703.issue11747@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Terry, I had no intention here at all - had nothing to do with unified_diff. Would have to look at the history to see who added it, and ask them.  That said, the very name "unified_diff" suggests someone did intend to mimic _some_ system's "unified diff" behavior ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11747>
_______________________________________

From report at bugs.python.org  Sat Apr  9 08:00:20 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 09 Apr 2011 06:00:20 +0000
Subject: [issue11776] types.MethodType() params and usage is not documented
In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za>
Message-ID: <1302328820.11.0.463788395133.issue11776@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Nevermind about #6040 - I just used the same technique to provide a workaround and then remembered I've seen this recipe on StackOverflow.

To me types is the right place, because that's exactly where are you sent from the docs of new module:

  Deprecated since version 2.6: The new module has been removed in Python 3.0. Use the types module?s classes instead.

http://docs.python.org/library/new.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11776>
_______________________________________

From report at bugs.python.org  Sat Apr  9 08:51:04 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 09 Apr 2011 06:51:04 +0000
Subject: [issue6040] bdist_msi does not deal with pre-release version
In-Reply-To: <1242472106.67.0.523299229524.issue6040@psf.upfronthosting.co.za>
Message-ID: <1302331864.2.0.478437909739.issue6040@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

What for? IIUC, it won't be fixed in distutils anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6040>
_______________________________________

From report at bugs.python.org  Sat Apr  9 09:08:24 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sat, 09 Apr 2011 07:08:24 +0000
Subject: [issue11787] File handle leak in TarFile lib
In-Reply-To: <1302115375.88.0.984018215443.issue11787@psf.upfronthosting.co.za>
Message-ID: <1302332904.26.0.337544399427.issue11787@psf.upfronthosting.co.za>


Changes by Lars Gust?bel <lars at gustaebel.de>:


----------
assignee:  -> lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11787>
_______________________________________

From report at bugs.python.org  Sat Apr  9 09:43:10 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 09 Apr 2011 07:43:10 +0000
Subject: [issue11776] types.MethodType() params and usage is not documented
In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za>
Message-ID: <1302334990.24.0.677134087993.issue11776@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

When we do document types, their constructors and methods should also be documented.  This is a valid request.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11776>
_______________________________________

From report at bugs.python.org  Sat Apr  9 10:36:37 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sat, 09 Apr 2011 08:36:37 +0000
Subject: [issue11806] Missing 2 hyphens in the docs
In-Reply-To: <1302338197.1.0.100311254016.issue11806@psf.upfronthosting.co.za>
Message-ID: <1302338197.1.0.100311254016.issue11806@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

Please see  http://docs.python.org/py3k/library/argparse.html#module-argparse  and read the first sentence which goes...

"The argparse module makes it easy to write user friendly command line interfaces."

Please fix this to...

"The argparse module makes it easy to write user-friendly command-line interfaces."

Note: "user friendly" --> "user-friendly"
      "command line" --> "command-line"

----------
assignee: docs at python
components: Documentation
messages: 133377
nosy: Retro, docs at python
priority: normal
severity: normal
status: open
title: Missing 2 hyphens in the docs
versions: Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11806>
_______________________________________

From report at bugs.python.org  Sat Apr  9 11:04:50 2011
From: report at bugs.python.org (Menno Smits)
Date: Sat, 09 Apr 2011 09:04:50 +0000
Subject: [issue11796] Comprehensions in a class definition mostly cannot
	access class variable
In-Reply-To: <1302180921.17.0.22284518515.issue11796@psf.upfronthosting.co.za>
Message-ID: <1302339890.02.0.540957324141.issue11796@psf.upfronthosting.co.za>


Menno Smits <menno at freshfoo.com> added the comment:

Thanks to everyone for the explanations.

I was hoping for behaviour along the lines of Python 2 (certainly not artificially blocking more cases in the name of consistency) but it doesn't look like that's going to happen. I think this is one slight and rare area where Python 3 has taken a step backwards when compared to Python 2 but I can live with it. As noted there's other ways to achieve the same thing.

The new Python 3 behaviour seems odd to me but perhaps that's just a bias due to many years of development with Python 2. A documentation improvement would help. 

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11796>
_______________________________________

From report at bugs.python.org  Sat Apr  9 11:21:13 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sat, 09 Apr 2011 09:21:13 +0000
Subject: [issue11807] Documentation of add_subparsers lacks information about
	parametres
In-Reply-To: <1302340872.99.0.0231583237732.issue11807@psf.upfronthosting.co.za>
Message-ID: <1302340872.99.0.0231583237732.issue11807@psf.upfronthosting.co.za>


New submission from Filip Gruszczy?ski <gruszczy at gmail.com>:

In argparse documentation parametres of add_subparsers are not listed. And yet there are some really useful parametres like parser_class. It would be useful, it they were described there well and one wouldn't have to look into the code to find them :-) I'll be happy to provide documentation patch tomorrow.

----------
assignee: docs at python
components: Documentation
messages: 133379
nosy: docs at python, gruszczy
priority: normal
severity: normal
status: open
title: Documentation of add_subparsers lacks information about parametres
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11807>
_______________________________________

From report at bugs.python.org  Sat Apr  9 11:22:12 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sat, 09 Apr 2011 09:22:12 +0000
Subject: [issue11807] Documentation of add_subparsers lacks information about
	parametres
In-Reply-To: <1302340872.99.0.0231583237732.issue11807@psf.upfronthosting.co.za>
Message-ID: <1302340932.93.0.0331531831605.issue11807@psf.upfronthosting.co.za>


Changes by Filip Gruszczy?ski <gruszczy at gmail.com>:


----------
nosy: +bethard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11807>
_______________________________________

From report at bugs.python.org  Sat Apr  9 12:07:10 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 09 Apr 2011 10:07:10 +0000
Subject: [issue9904] Cosmetic issues that may warrant a fix in symtable.h/c
In-Reply-To: <1284964146.62.0.95975690396.issue9904@psf.upfronthosting.co.za>
Message-ID: <1302343630.38.0.29175403119.issue9904@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

+1 for clarifying the comments. Adding comments for the apparently unused fields (as per my last tracker comment) would be good, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9904>
_______________________________________

From report at bugs.python.org  Sat Apr  9 13:37:21 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 09 Apr 2011 11:37:21 +0000
Subject: [issue11783] email parseaddr and formataddr should be IDNA aware
In-Reply-To: <BANLkTinG_gDQGL8YQ6c1t060YC6B-A7DUg@mail.gmail.com>
Message-ID: <20110409113716.GA40209@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

On Fri, Apr 08, 2011 at 09:03:51PM +0000, Torsten Becker wrote:
> I was about to look into this over the weekend, but of course I don't
> want to steal your fun, Steffen. :)

Toll, toll, toll!!
Still cherry blossom, thanks to the weather, apple blossom 
started, more than 20 degrees.
I really understand if a young german man rather prefers staying 
at home over the weekend, looking at its beautiful, intelligent 
chancellor whenever the TV is started, than doing whatever else!

Dear god, all these nice memories ...
14" BW CRT monitors, 30 hours at a time ...
Have a nice weekend!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11783>
_______________________________________

From report at bugs.python.org  Sat Apr  9 13:43:13 2011
From: report at bugs.python.org (Michael Foord)
Date: Sat, 09 Apr 2011 11:43:13 +0000
Subject: [issue11770] inspect.dir_static
In-Reply-To: <1302001735.74.0.572603626553.issue11770@psf.upfronthosting.co.za>
Message-ID: <1302349393.6.0.24043871424.issue11770@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Thanks for the patch Andreas. On a quick read through it looks good. I'll do a proper review shortly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11770>
_______________________________________

From report at bugs.python.org  Sat Apr  9 13:56:16 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 09 Apr 2011 11:56:16 +0000
Subject: [issue11782] email.generator.Generator.flatten() fails
In-Reply-To: <1302305976.41.0.299753392384.issue11782@psf.upfronthosting.co.za>
Message-ID: <20110409115611.GA46216@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

On Fri, Apr 08, 2011 at 11:39:36PM +0000, Terry J. Reedy wrote:
> 1. What is a minimal msgdata that gives the same error; post it.

Stepping a bit..  Remove 'Content-Type' header field and this does 
not crash.  Thus the real problem may again lie in get_payload() 
trying to convert data instead of leaving it alone. 
I'll try to instrument the path a bit ..

import email, email.parser, email.generator, io, textwrap
msgdata = textwrap.dedent("""\
            Date: Mon, 01 Feb 2010 12:21:16 +0100
            From: "three" <four at example.net>
            To: <one at two.com>
            Subject: Content-Type crash
            Content-Type: message/rfc822

            Remove Content-Type header field and no crash happens!
        """).encode('ascii')
msg = email.parser.BytesParser().parsebytes(msgdata, headersonly=True)
email.generator.BytesGenerator(io.BytesIO()).flatten(msg)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11782>
_______________________________________

From report at bugs.python.org  Sat Apr  9 14:36:17 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 09 Apr 2011 12:36:17 +0000
Subject: [issue11650] Faulty RESTART/EINTR handling in Parser/myreadline.c
In-Reply-To: <1300887352.61.0.261947274229.issue11650@psf.upfronthosting.co.za>
Message-ID: <1302352577.86.0.202138933824.issue11650@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Ping!
Note that whatever reason caused jesstess, to name a few,
to drop that loop (and the continue), Charles-Francois posted
a correctly working patch!
I have no idea why such a severe bug could sleep in code which is
executed for each and every input(), but it needs to be fixed!

Do you want a robot test?
I've tested it dozens of times and it still works fine!!
It's idiot-proof!
(And i definitely have no time in my free-time to write an
automated test which fiddles around with timeout values
and such to simulate user input.
To me all of this is mystic.
There are almost 14000 *registered* Python users here!!)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11650>
_______________________________________

From report at bugs.python.org  Sat Apr  9 15:27:32 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 09 Apr 2011 13:27:32 +0000
Subject: [issue11700] mailbox.py proxy updates
In-Reply-To: <20110408155603.GA10017@sherwood.local>
Message-ID: <20110409132704.GA52452@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

..
> So here is the rewritten .yeah-2.diff. 
..
> I added more tests (i'm absolutely convinced that the tests i've 
> found in test_mailbox.py really find all the cutting edges <;). 
> On my box this is clean. 

Haha, now this is *very* funny!

______
Traceback (most recent call last):
...
  File "/Users/steffen/usr/opt/py3k/lib/python3.3/email/parser.py", line 104, in parse
    return self.parser.parse(fp, headersonly)
  File "/Users/steffen/usr/opt/py3k/lib/python3.3/mailbox.py", line 1900, in flush
    raise io.UnsupportedOperation('flush')
Exception: io.UnsupportedOperation: flush
______

So, don't ask me why anyone tries to flush a readonly ProxyFile! 
BytesParser wraps this in TextIO, and in Modules/_io/textio.c i find:

c_STRVAR(textiowrapper_doc,
    "\n"
    "If line_buffering is True, a call to flush is implied when a call to\n"
    "write contains a newline character."
    );
..
typedef struct
{
..
    /* Reads and writes are internally buffered in order to speed things up.
       However, any read will first flush the write buffer if itsn't empty.
..
} textio;

No reason to call flush. 
So i replaced flush() and got this:

______
...
  File "/Users/steffen/usr/opt/py3k/lib/python3.3/email/parser.py", line 104, in parse
    return self.parser.parse(fp, headersonly)
  File "/Users/steffen/usr/opt/py3k/lib/python3.3/email/parser.py", line 48, in parse
    data = fp.read(8192)
Exception: AttributeError: '_PartialFile' object has no attribute 'read1'
______

Nice.  It seems that deriving _ProxyFile from io.RawIOBase will 
not work correctly with the current EMail package because 
BytesParser uses TextIOWrapper expects io.BufferedIOBase. 
Regardless of the fact i think TextIOWrapper should be 
configurable not to close the "buffer" - s...!

Anyway, it's seems not to be practical to implement ProxyFile 
*correctly*.  Therefore i'll attach yeah-3.diff which falsely 
ignores calls to flush(). 
To make this s... rock it is now also derived from 
io.BufferedIOBase, thus i've reintroduced read1() which - true - 
is now also tested!  *YES IT CAN*!
Nice weekend.

----------
Added file: http://bugs.python.org/file21592/11700.yeah-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11700>
_______________________________________
-------------- next part --------------
diff --git a/Lib/mailbox.py b/Lib/mailbox.py
--- a/Lib/mailbox.py
+++ b/Lib/mailbox.py
@@ -1864,97 +1864,145 @@
     """Message with MMDF-specific properties."""
 
 
-class _ProxyFile:
-    """A read-only wrapper of a file."""
+class _ProxyFile(io.BufferedIOBase):
+    """A io.BufferedIOBase inheriting read-only wrapper for a seekable file.
+    It supports __iter__() and the context-manager protocol.
+    """
+    def __init__(self, file, pos=None):
+        """If pos is not None then the file will keep track of its position."""
+        io.RawIOBase.__init__(self)
+        self._file = file
+        self._pos = file.tell() if pos is None else pos
+        self._close = True
+        self._is_open = True
 
-    def __init__(self, f, pos=None):
-        """Initialize a _ProxyFile."""
-        self._file = f
-        if pos is None:
-            self._pos = f.tell()
+    def _set_noclose(self):
+        """Subclass hook - use to avoid closing internal file object."""
+        self._close = False
+
+    def _closed_check(self):
+        """Raise ValueError if not open."""
+        if not self._is_open:
+            raise ValueError('I/O operation on closed file')
+
+    def close(self):
+        if self._close:
+            self._close = False
+            self._file.close()
+            del self._file
+        self._is_open = False
+
+    @property
+    def closed(self):
+        return not self._is_open
+
+    def flush(self):
+        # Not possible because it gets falsely called (issue 11700)!
+        #raise io.UnsupportedOperation('flush')
+        pass
+
+    def _read(self, size, read_method, readinto_arg=None):
+        if size is None or size < 0:
+            size = -1
+        self._file.seek(self._pos)
+        if not readinto_arg:
+            result = read_method(size)
         else:
-            self._pos = pos
+            if size < len(readinto_arg):
+                del readinto_arg[size:]
+            result = read_method(readinto_arg)
+            if result < len(readinto_arg):
+                del readinto_arg[result:]
+        self._pos = self._file.tell()
+        return result
 
-    def read(self, size=None):
-        """Read bytes."""
+    def readable(self):
+        self._closed_check()
+        return True
+
+    def read(self, size=-1):
+        self._closed_check()
+        if size is None or size < 0:
+            return self.readall()
         return self._read(size, self._file.read)
 
-    def read1(self, size=None):
-        """Read bytes."""
+    def read1(self, size=-1):
+        self._closed_check()
+        if size is None or size < 0:
+            return b''
         return self._read(size, self._file.read1)
 
-    def readline(self, size=None):
-        """Read a line."""
+    def readinto(self, by_arr):
+        self._closed_check()
+        return self._read(len(by_arr), self._file.readinto, by_arr)
+
+    def readall(self):
+        self._closed_check()
+        self._file.seek(self._pos)
+        if hasattr(self._file, 'readall'):
+            result = self._file.readall()
+        else:
+            dl = []
+            while 1:
+                i = self._file.read(8192)
+                if len(i) == 0:
+                    break
+                dl.append(i)
+            result = b''.join(dl)
+        self._pos = self._file.tell()
+        return result
+
+    def readline(self, size=-1):
+        self._closed_check()
         return self._read(size, self._file.readline)
 
-    def readlines(self, sizehint=None):
-        """Read multiple lines."""
+    def readlines(self, sizehint=-1):
         result = []
         for line in self:
             result.append(line)
-            if sizehint is not None:
+            if sizehint >= 0:
                 sizehint -= len(line)
                 if sizehint <= 0:
                     break
         return result
 
+    def seekable(self):
+        self._closed_check()
+        return True
+
+    def seek(self, offset, whence=0):
+        self._closed_check()
+        if whence == 1:
+            self._file.seek(self._pos)
+        self._pos = self._file.seek(offset, whence)
+        return self._pos
+
+    def tell(self):
+        self._closed_check()
+        return self._pos
+
+    def writable(self):
+        self._closed_check()
+        return False
+
+    def writelines(self, lines):
+        raise io.UnsupportedOperation('writelines')
+
+    def write(self, b):
+        raise io.UnsupportedOperation('write')
+
     def __iter__(self):
-        """Iterate over lines."""
         while True:
             line = self.readline()
             if not line:
                 raise StopIteration
             yield line
 
-    def tell(self):
-        """Return the position."""
-        return self._pos
-
-    def seek(self, offset, whence=0):
-        """Change position."""
-        if whence == 1:
-            self._file.seek(self._pos)
-        self._file.seek(offset, whence)
-        self._pos = self._file.tell()
-
-    def close(self):
-        """Close the file."""
-        if hasattr(self._file, 'close'):
-            self._file.close()
-        del self._file
-
-    def _read(self, size, read_method):
-        """Read size bytes using read_method."""
-        if size is None:
-            size = -1
-        self._file.seek(self._pos)
-        result = read_method(size)
-        self._pos = self._file.tell()
-        return result
-
     def __enter__(self):
-        """Context manager protocol support."""
         return self
-
     def __exit__(self, *exc):
         self.close()
 
-    def readable(self):
-        return self._file.readable()
-
-    def writable(self):
-        return self._file.writable()
-
-    def seekable(self):
-        return self._file.seekable()
-
-    def flush(self):
-        return self._file.flush()
-
-    @property
-    def closed(self):
-        return self._file.closed
-
 
 class _PartialFile(_ProxyFile):
     """A read-only wrapper of part of a file."""
@@ -1962,6 +2010,7 @@
     def __init__(self, f, start=None, stop=None):
         """Initialize a _PartialFile."""
         _ProxyFile.__init__(self, f, start)
+        super()._set_noclose()
         self._start = start
         self._stop = stop
 
@@ -1971,6 +2020,7 @@
 
     def seek(self, offset, whence=0):
         """Change position, possibly with respect to start or stop."""
+        self._closed_check()
         if whence == 0:
             self._pos = self._start
             whence = 1
@@ -1979,20 +2029,21 @@
             whence = 1
         _ProxyFile.seek(self, offset, whence)
 
-    def _read(self, size, read_method):
+    def _read(self, size, read_method, readinto_arg=None):
         """Read size bytes using read_method, honoring start and stop."""
         remaining = self._stop - self._pos
         if remaining <= 0:
             return b''
         if size is None or size < 0 or size > remaining:
             size = remaining
-        return _ProxyFile._read(self, size, read_method)
+        return _ProxyFile._read(self, size, read_method, readinto_arg)
 
-    def close(self):
-        # do *not* close the underlying file object for partial files,
-        # since it's global to the mailbox object
-        del self._file
-
+    def readall(self):
+        self._closed_check()
+        remaining = self._stop - self._pos
+        if remaining <= 0:
+            return b''
+        return _ProxyFile._read(self, remaining, self._file.read)
 
 def _lock_file(f, dotlock=True):
     """Lock file f using lockf and dot locking."""
diff --git a/Lib/test/test_mailbox.py b/Lib/test/test_mailbox.py
--- a/Lib/test/test_mailbox.py
+++ b/Lib/test/test_mailbox.py
@@ -290,12 +290,17 @@
         key1 = self._box.add(_sample_message)
         with self._box.get_file(key0) as file:
             data0 = file.read()
-        with self._box.get_file(key1) as file:
-            data1 = file.read()
+        file1 = self._box.get_file(key1)
+        data1 = file1.read()
         self.assertEqual(data0.decode('ascii').replace(os.linesep, '\n'),
                          self._template % 0)
         self.assertEqual(data1.decode('ascii').replace(os.linesep, '\n'),
                          _sample_message)
+        file1.close()
+        try:
+            file1.close()
+        except:
+            self.fail('.close() doesn\'t handle multiple invocations')
 
     def test_iterkeys(self):
         # Get keys using iterkeys()
@@ -1774,6 +1779,68 @@
         proxy.seek(2)
         self.assertEqual(proxy.read(1000), b'r')
 
+    def _test_read1(self, proxy):
+        # Read by byte
+        proxy.seek(0)
+        self.assertEqual(proxy.read1(3), b'bar')
+        proxy.seek(1)
+        self.assertEqual(proxy.read1(2), b'ar')
+        proxy.seek(0)
+        self.assertEqual(proxy.read1(2), b'ba')
+        proxy.seek(1)
+        self.assertEqual(proxy.read1(-1), b'')
+        self.assertEqual(proxy.read1(None), b'')
+        self.assertEqual(proxy.read1(1000), b'ar')
+
+    def _test_readinto(self, proxy):
+        # Fill in bytearray
+        proxy.seek(0)
+        ba = bytearray(3)
+        self.assertEqual(proxy.readinto(ba), 3)
+        self.assertEqual(ba, b'bar')
+
+        proxy.seek(1)
+        ba = bytearray(2)
+        self.assertEqual(proxy.readinto(ba), 2)
+        self.assertEqual(ba, b'ar')
+
+        proxy.seek(0)
+        ba = bytearray(2)
+        self.assertEqual(proxy.readinto(ba), 2)
+        self.assertEqual(ba, b'ba')
+
+        proxy.seek(0)
+        ba = bytearray(2)
+        self.assertEqual(proxy.readinto(ba), 2)
+        self.assertEqual(ba, b'ba')
+
+        proxy.seek(1)
+        ba = bytearray(1000)
+        self.assertEqual(proxy.readinto(ba), 2)
+        self.assertEqual(ba, b'ar')
+
+        proxy.seek(2)
+        ba = bytearray(1000)
+        self.assertEqual(proxy.readinto(ba), 1)
+        self.assertEqual(ba, b'r')
+
+    def _test_readall(self, proxy):
+        # Read all the data
+        ls = os.linesep.encode()
+        lsl = len(ls)
+
+        proxy.seek(0)
+        x = b'fiesta' + ls + b'mexicana' + ls
+        self.assertEqual(proxy.readall(), x)
+
+        proxy.seek(6 + lsl)
+        x = b'mexicana' + ls
+        self.assertEqual(proxy.readall(), x)
+
+        proxy.seek(6+3 + lsl)
+        x = b'icana' + ls
+        self.assertEqual(proxy.readall(), x)
+
     def _test_readline(self, proxy):
         # Read by line
         linesep = os.linesep.encode()
@@ -1833,10 +1900,38 @@
         self.assertFalse(proxy.read())
 
     def _test_close(self, proxy):
-        # Close a file
+        self.assertFalse(proxy.closed)
+        # Not possible (see issue 11700 thread)
+        #self.assertRaises(io.UnsupportedOperation, proxy.flush)
+        self.assertTrue(proxy.readable())
+        self.assertTrue(proxy.seekable())
+        self.assertRaises(io.UnsupportedOperation, proxy.truncate, 0)
+        self.assertFalse(proxy.writable())
+        self.assertRaises(io.UnsupportedOperation, proxy.writelines, ['AU'])
+        self.assertRaises(io.UnsupportedOperation, proxy.write, 'AU')
+
         proxy.close()
-        self.assertRaises(AttributeError, lambda: proxy.close())
+        self.assertTrue(proxy.closed)
+        try:
+            proxy.close()
+        except:
+            self.fail('Proxy.close() failure')
 
+        # Not possible (see issue 11700 thread)
+        #self.assertRaises(io.UnsupportedOperation, proxy.flush)
+        self.assertRaises(ValueError, proxy.readable)
+        self.assertRaises(ValueError, proxy.read)
+        self.assertRaises(ValueError, proxy.readinto, bytearray())
+        self.assertRaises(ValueError, proxy.readall)
+        self.assertRaises(ValueError, proxy.readline)
+        self.assertRaises(ValueError, proxy.readlines)
+        self.assertRaises(ValueError, proxy.seekable)
+        self.assertRaises(ValueError, proxy.seek, 0)
+        self.assertRaises(ValueError, proxy.tell)
+        self.assertRaises(io.UnsupportedOperation, proxy.truncate, 0)
+        self.assertRaises(ValueError, proxy.writable)
+        self.assertRaises(io.UnsupportedOperation, proxy.writelines, ['AU'])
+        self.assertRaises(io.UnsupportedOperation, proxy.write, 'AU')
 
 class TestProxyFile(TestProxyFileBase):
 
@@ -1863,6 +1958,19 @@
         self._file.write(b'bar')
         self._test_read(mailbox._ProxyFile(self._file))
 
+    def test_read1(self):
+        self._file.write(b'bar')
+        self._test_read1(mailbox._ProxyFile(self._file))
+
+    def test_readinto(self):
+        self._file.write(b'bar')
+        self._test_readinto(mailbox._ProxyFile(self._file))
+
+    def test_readall(self):
+        ls = os.linesep.encode()
+        self._file.write(b'fiesta' + ls + b'mexicana' + ls)
+        self._test_readall(mailbox._ProxyFile(self._file))
+
     def test_readline(self):
         self._file.write(bytes('foo%sbar%sfred%sbob' % (os.linesep, os.linesep,
                                                   os.linesep), 'ascii'))
@@ -1886,6 +1994,13 @@
         self._file.write(bytes('foo%sbar%s' % (os.linesep, os.linesep), 'ascii'))
         self._test_close(mailbox._ProxyFile(self._file))
 
+    def test_ctxman(self):
+        self._file.write(b'foo')
+        proxy = mailbox._ProxyFile(self._file)
+        with proxy as p:
+            pass
+        self.assertTrue(proxy.closed)
+
 
 class TestPartialFile(TestProxyFileBase):
 
@@ -1909,6 +2024,20 @@
         self._file.write(bytes('***bar***', 'ascii'))
         self._test_read(mailbox._PartialFile(self._file, 3, 6))
 
+    def test_read1(self):
+        self._file.write(bytes('***bar***', 'ascii'))
+        self._test_read1(mailbox._PartialFile(self._file, 3, 6))
+
+    def test_readinto(self):
+        self._file.write(b'***bar***')
+        self._test_readinto(mailbox._PartialFile(self._file, 3, 6))
+
+    def test_readall(self):
+        ls = os.linesep.encode()
+        lsl = len(ls)
+        self._file.write(b'***fiesta' + ls + b'mexicana' + ls + b'***')
+        self._test_readall(mailbox._PartialFile(self._file, 3, 3+14+2*lsl))
+
     def test_readline(self):
         self._file.write(bytes('!!!!!foo%sbar%sfred%sbob!!!!!' %
                          (os.linesep, os.linesep, os.linesep), 'ascii'))
@@ -1937,6 +2066,14 @@
         self._test_close(mailbox._PartialFile(self._file, 1,
                                               6 + 3 * len(os.linesep)))
 
+    def test_ctxman(self):
+        self._file.write(bytes('foo' + os.linesep + 'bar', 'ascii'))
+        pos = self._file.tell()
+        proxy = mailbox._PartialFile(self._file, 2, 5)
+        with proxy as p:
+            pass
+        self.assertTrue(proxy.closed)
+
 
 ## Start: tests from the original module (for backward compatibility).
 

From report at bugs.python.org  Sat Apr  9 15:49:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 09 Apr 2011 13:49:09 +0000
Subject: [issue11802] filecmp.cmp needs a documented way to clear cache
In-Reply-To: <1302233844.4.0.517722747064.issue11802@psf.upfronthosting.co.za>
Message-ID: <1302356949.98.0.116725709256.issue11802@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file21585/filecmp-lru-cache-2.7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11802>
_______________________________________

From report at bugs.python.org  Sat Apr  9 15:49:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 09 Apr 2011 13:49:58 +0000
Subject: [issue11802] filecmp.cmp needs a documented way to clear cache
In-Reply-To: <1302233844.4.0.517722747064.issue11802@psf.upfronthosting.co.za>
Message-ID: <1302356998.52.0.917930884485.issue11802@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Why use an ordered dict instead of functools.lru_cache?

----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11802>
_______________________________________

From report at bugs.python.org  Sat Apr  9 15:53:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 09 Apr 2011 13:53:08 +0000
Subject: [issue6040] bdist_msi does not deal with pre-release version
In-Reply-To: <1242472106.67.0.523299229524.issue6040@psf.upfronthosting.co.za>
Message-ID: <1302357188.67.0.945309262339.issue6040@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Well, this is the bug tracker for the stdlib.  We have first to define clearly what the bug is, then find how to fix it in packaging (the name of distutils2 merged into 3.3), then decide whether to backport it to distutils.  Half-tested recipes to work-around the bug on unpatched versions divert attention and are out of place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6040>
_______________________________________

From report at bugs.python.org  Sat Apr  9 15:57:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 09 Apr 2011 13:57:21 +0000
Subject: [issue11805] package_data only allows one glob per-package
In-Reply-To: <1302301429.27.0.797210396018.issue11805@psf.upfronthosting.co.za>
Message-ID: <1302357441.59.0.666726567171.issue11805@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

What?s the syntax described in the docs?

  package_data =
      mypackage = templates/*.html static/css/*.css

or

  package_data =
      mypackage = templates/*.html
      mypackage = static/css/*.css

?

On a related subject, I think the new resources system should obsolete data_files and package_data.  Putting files in arbitrary, OS-specific places (data_files) or alongside the Python files (package_data) was wrong, let?s move away from that.

----------
versions: +3rd party, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11805>
_______________________________________

From report at bugs.python.org  Sat Apr  9 16:02:04 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Apr 2011 14:02:04 +0000
Subject: [issue11650] Faulty RESTART/EINTR handling in Parser/myreadline.c
In-Reply-To: <1300887352.61.0.261947274229.issue11650@psf.upfronthosting.co.za>
Message-ID: <E1Q8Yji-0004dY-KA@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 2222f343ac51 by Victor Stinner in branch '3.1':
Issue #11650: PyOS_StdioReadline() retries fgets() if it was interrupted
http://hg.python.org/cpython/rev/2222f343ac51

New changeset fc2f251e660a by Victor Stinner in branch '3.2':
(Merge 3.1) Issue #11650: PyOS_StdioReadline() retries fgets() if it was
http://hg.python.org/cpython/rev/fc2f251e660a

New changeset 64de1ded0744 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #11650: PyOS_StdioReadline() retries fgets() if it was
http://hg.python.org/cpython/rev/64de1ded0744

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11650>
_______________________________________

From report at bugs.python.org  Sat Apr  9 16:09:18 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Apr 2011 14:09:18 +0000
Subject: [issue11650] Faulty RESTART/EINTR handling in Parser/myreadline.c
In-Reply-To: <1300887352.61.0.261947274229.issue11650@psf.upfronthosting.co.za>
Message-ID: <E1Q8Yqj-00053J-8A@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7febd5ef7619 by Victor Stinner in branch '2.7':
(Merge 3.1) Issue #11650: PyOS_StdioReadline() retries fgets() if it was
http://hg.python.org/cpython/rev/7febd5ef7619

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11650>
_______________________________________

From report at bugs.python.org  Sat Apr  9 16:16:18 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 09 Apr 2011 14:16:18 +0000
Subject: [issue11650] Faulty RESTART/EINTR handling in Parser/myreadline.c
In-Reply-To: <1300887352.61.0.261947274229.issue11650@psf.upfronthosting.co.za>
Message-ID: <1302358578.57.0.623667551525.issue11650@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Merci, STINNER Victor!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11650>
_______________________________________

From report at bugs.python.org  Sat Apr  9 16:18:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 09 Apr 2011 14:18:01 +0000
Subject: [issue11650] Faulty RESTART/EINTR handling in Parser/myreadline.c
In-Reply-To: <1300887352.61.0.261947274229.issue11650@psf.upfronthosting.co.za>
Message-ID: <1302358681.57.0.769544160302.issue11650@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I emulated Mac OS X behaviour on Linux by hacking my_fgets(): do { p=NULL; errno = EINTR; }, only after the first call to fgets(). Without the patch, Python does exit immediatly. With the patch, Python doesn't exit.

I applied neologix's patch to 3.1, 3.2, 3.3 and 2.7: thank you Charles-Francois!

Can someone retest on Mac OS X?

I noticied a strange behaviour:
----------
$ python
>>> 1+^Z
[1]+  Stopped                 ./python
$ fg
./python
2<ENTER>
2
----------
"1+2" input becomes "2". But we can not do better because buf doesn't contain "1+\0" when fgets() is interrupted.

Note: If the readline module is available, it is used, and readline doesn't have this issue. And "1+^Z(...)2" gives 3 with readline.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11650>
_______________________________________

From report at bugs.python.org  Sat Apr  9 16:39:25 2011
From: report at bugs.python.org (Davide Rizzo)
Date: Sat, 09 Apr 2011 14:39:25 +0000
Subject: [issue11650] Faulty RESTART/EINTR handling in Parser/myreadline.c
In-Reply-To: <1300887352.61.0.261947274229.issue11650@psf.upfronthosting.co.za>
Message-ID: <1302359965.08.0.146035661372.issue11650@psf.upfronthosting.co.za>


Davide Rizzo <sorcio at gmail.com> added the comment:

Victor, I have neither OS X nor Linux available right now, but if I remember correctly the same happens on both systems when programs call input() (but not from the REPL). See also my previous message with "python -c" tests and my second remark.

What about the Pexpect based tests? Could it be interesting to Python to test the behavior on the terminal?

About the committed patch: is it the right thing to do to call PyOS_InputHook at every restart?

Thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11650>
_______________________________________

From report at bugs.python.org  Sat Apr  9 16:40:50 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 09 Apr 2011 14:40:50 +0000
Subject: [issue11802] filecmp.cmp needs a documented way to clear cache
In-Reply-To: <1302233844.4.0.517722747064.issue11802@psf.upfronthosting.co.za>
Message-ID: <1302360050.78.0.273542773482.issue11802@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Because the lru_cache decorator doesn't provide any way to invalidate
stale cache entries.

Perhaps I should factor out the duplicated code into a separate class
that can then also be exposed to users of the stdlib. But that would only
apply to 3.3, so the uglier fix is still necessary for older versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11802>
_______________________________________

From report at bugs.python.org  Sat Apr  9 16:55:32 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 09 Apr 2011 14:55:32 +0000
Subject: [issue11808] $MACOSX_DEPLOYMENT_TARGET mismatch ... during configure
In-Reply-To: <1302360932.31.0.240480898156.issue11808@psf.upfronthosting.co.za>
Message-ID: <1302360932.31.0.240480898156.issue11808@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

Hello Mac OS X gurus, if i


else
	DEBUG='--with-pydebug'
	echo Using --with-pydebug
fi
./configure --prefix="$HOME/usr/opt/$PREFIX" $DEBUG
make -j2 all


i get this


/usr/bin/gcc -c -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes -O2 -O2  -I. -IInclude -I./Include    -DPy_BUILD_CORE \
	      -DHGVERSION="\"`LC_ALL=C hg id -i .`\"" \
	      -DHGTAG="\"`LC_ALL=C hg id -t .`\"" \
	      -DHGBRANCH="\"`LC_ALL=C hg id -b .`\"" \
	      -o Modules/getbuildinfo.o ./Modules/getbuildinfo.c
Traceback (most recent call last):
  File "/Users/steffen/usr/lib/python2.7/site.py", line 563, in <module>
    main()
  File "/Users/steffen/usr/lib/python2.7/site.py", line 545, in main
    known_paths = addusersitepackages(known_paths)
  File "/Users/steffen/usr/lib/python2.7/site.py", line 278, in addusersitepackages
    user_site = getusersitepackages()
  File "/Users/steffen/usr/lib/python2.7/site.py", line 253, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/Users/steffen/usr/lib/python2.7/site.py", line 243, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/Users/steffen/usr/lib/python2.7/sysconfig.py", line 535, in get_config_var
    return get_config_vars().get(name)
  File "/Users/steffen/usr/lib/python2.7/sysconfig.py", line 434, in get_config_vars
    _init_posix(_CONFIG_VARS)
  File "/Users/steffen/usr/lib/python2.7/sysconfig.py", line 313, in _init_posix
    raise IOError(msg)
IOError: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.4" but "10.6" during configure
Traceback (most recent call last):
  File "/Users/steffen/usr/lib/python2.7/site.py", line 563, in <module>
    main()
  File "/Users/steffen/usr/lib/python2.7/site.py", line 545, in main
    known_paths = addusersitepackages(known_paths)
  File "/Users/steffen/usr/lib/python2.7/site.py", line 278, in addusersitepackages
    user_site = getusersitepackages()
  File "/Users/steffen/usr/lib/python2.7/site.py", line 253, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/Users/steffen/usr/lib/python2.7/site.py", line 243, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/Users/steffen/usr/lib/python2.7/sysconfig.py", line 535, in get_config_var
    return get_config_vars().get(name)
  File "/Users/steffen/usr/lib/python2.7/sysconfig.py", line 434, in get_config_vars
    _init_posix(_CONFIG_VARS)
  File "/Users/steffen/usr/lib/python2.7/sysconfig.py", line 313, in _init_posix
    raise IOError(msg)
IOError: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.4" but "10.6" during configure
Traceback (most recent call last):
  File "/Users/steffen/usr/lib/python2.7/site.py", line 563, in <module>
    main()
  File "/Users/steffen/usr/lib/python2.7/site.py", line 545, in main
    known_paths = addusersitepackages(known_paths)
  File "/Users/steffen/usr/lib/python2.7/site.py", line 278, in addusersitepackages
    user_site = getusersitepackages()
  File "/Users/steffen/usr/lib/python2.7/site.py", line 253, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/Users/steffen/usr/lib/python2.7/site.py", line 243, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/Users/steffen/usr/lib/python2.7/sysconfig.py", line 535, in get_config_var
    return get_config_vars().get(name)
  File "/Users/steffen/usr/lib/python2.7/sysconfig.py", line 434, in get_config_vars
    _init_posix(_CONFIG_VARS)
  File "/Users/steffen/usr/lib/python2.7/sysconfig.py", line 313, in _init_posix
    raise IOError(msg)
IOError: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.4" but "10.6" during configure

----------
components: Build
messages: 133395
nosy: ned.deily, ronaldoussoren, sdaoden
priority: normal
severity: normal
status: open
title: $MACOSX_DEPLOYMENT_TARGET mismatch ... during configure
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11808>
_______________________________________

From report at bugs.python.org  Sat Apr  9 16:56:29 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 09 Apr 2011 14:56:29 +0000
Subject: [issue11808] $MACOSX_DEPLOYMENT_TARGET mismatch ... during configure
In-Reply-To: <1302360932.31.0.240480898156.issue11808@psf.upfronthosting.co.za>
Message-ID: <1302360989.8.0.825927585974.issue11808@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

P.S.: this does not happen if i use


./configure --prefix="$HOME/usr/opt/$PREFIX" $DEBUG MACOSX_DEPLOYMENT_TARGET=10.6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11808>
_______________________________________

From report at bugs.python.org  Sat Apr  9 17:03:29 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 09 Apr 2011 15:03:29 +0000
Subject: [issue11808] $MACOSX_DEPLOYMENT_TARGET mismatch ... during configure
In-Reply-To: <1302360932.31.0.240480898156.issue11808@psf.upfronthosting.co.za>
Message-ID: <1302361409.93.0.207400859104.issue11808@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

The problem goes away if i comment out all
the Mercurial queries in Makefile:


HGVERSION=      #hg id -i $(srcdir)
HGTAG=          #hg id -t $(srcdir)
HGBRANCH=       #hg id -b $(srcdir)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11808>
_______________________________________

From report at bugs.python.org  Sat Apr  9 17:57:18 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 09 Apr 2011 15:57:18 +0000
Subject: [issue11802] filecmp.cmp needs a documented way to clear cache
In-Reply-To: <1302233844.4.0.517722747064.issue11802@psf.upfronthosting.co.za>
Message-ID: <1302364638.18.0.53402579505.issue11802@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I question whether this should be backported.  Please discuss with the RM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11802>
_______________________________________

From report at bugs.python.org  Sat Apr  9 17:58:11 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 09 Apr 2011 15:58:11 +0000
Subject: [issue11808] $MACOSX_DEPLOYMENT_TARGET mismatch ... during configure
In-Reply-To: <1302360932.31.0.240480898156.issue11808@psf.upfronthosting.co.za>
Message-ID: <1302364691.79.0.724172613859.issue11808@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for the report.  This is another case of the problem described in Issue9516, in particular msg130666 except now it is hg invoking another Python during the build process.  The sysconfig part of the patch for Issue9516 applied to the "build" Python 2.7 used by hg will avoid the problem.  Or, as you found, as a workaround, ensure that the MACOSX_DEPLOYMENT_TARGET of the "build" Python matches that of the Python being built.  It's also only a problem if the "build" Python is 2.7 or 3.2.

By the way, since you've asked about it before, MACOSX_DEPLOYMENT_TARGET is a standard feature of the Apple gcc tool chain and is used to support builds for multiple versions.  See -mmacosx-version-min in the OS X man (1) gcc and http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html

----------
assignee:  -> ned.deily
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3" but "10.5" during configure

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11808>
_______________________________________

From report at bugs.python.org  Sat Apr  9 18:34:17 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 09 Apr 2011 16:34:17 +0000
Subject: [issue6040] bdist_msi does not deal with pre-release version
In-Reply-To: <1242472106.67.0.523299229524.issue6040@psf.upfronthosting.co.za>
Message-ID: <1302366857.89.0.961830518441.issue6040@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Feel free to copy this report for a clear user story - http://twistedmatrix.com/trac/ticket/5024

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6040>
_______________________________________

From report at bugs.python.org  Sat Apr  9 18:46:21 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 09 Apr 2011 16:46:21 +0000
Subject: [issue11802] filecmp.cmp needs a documented way to clear cache
In-Reply-To: <1302233844.4.0.517722747064.issue11802@psf.upfronthosting.co.za>
Message-ID: <1302367581.12.0.588665746021.issue11802@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> I question whether this should be backported.  Please discuss with the RM.

Will do. Are you referring specifically to 2.7, or to 3.1 and 3.2 as well?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11802>
_______________________________________

From report at bugs.python.org  Sat Apr  9 19:02:58 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 09 Apr 2011 17:02:58 +0000
Subject: [issue11779] test_mmap timeout (30 min) on "AMD64 Snow Leopard 3.x"
	buildbot
In-Reply-To: <1302076762.26.0.815715887004.issue11779@psf.upfronthosting.co.za>
Message-ID: <1302368578.71.0.0479412820251.issue11779@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

OS X filesystem does not support seeking ahead to create sparse files.
The test is supposed to skip the LargeMmapTests on OS X and Windows with (line 679 of test_mmap.py):

if sys.platform[:3] == 'win' or sys.platform == 'darwin':
   requires('largefile', 'test requires %s bytes and a long time to run' % str(0x180000000))

Perhaps on the Snow Leopard buildbot something causes this line not to become true (what does sys.platform give on the buildbot)?

As for why its creating the file slowly (encrypted fs?), I don't know but the test shouldn't be running anyway...

----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11779>
_______________________________________

From report at bugs.python.org  Sat Apr  9 19:04:32 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 09 Apr 2011 17:04:32 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1302368672.34.0.578298753953.issue11707@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Georg, would you opine on whether this should to into 3.2.1?

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11707>
_______________________________________

From report at bugs.python.org  Sat Apr  9 19:48:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Apr 2011 17:48:58 +0000
Subject: [issue11779] test_mmap timeout (30 min) on "AMD64 Snow Leopard 3.x"
	buildbot
In-Reply-To: <1302076762.26.0.815715887004.issue11779@psf.upfronthosting.co.za>
Message-ID: <1302371338.87.0.172252558402.issue11779@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, buildbots run tests with "-uall", so the "largefile" resource gets enabled.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11779>
_______________________________________

From report at bugs.python.org  Sat Apr  9 20:09:43 2011
From: report at bugs.python.org (Erik Bray)
Date: Sat, 09 Apr 2011 18:09:43 +0000
Subject: [issue11805] package_data only allows one glob per-package
In-Reply-To: <1302301429.27.0.797210396018.issue11805@psf.upfronthosting.co.za>
Message-ID: <1302372583.74.0.876049331605.issue11805@psf.upfronthosting.co.za>


Erik Bray <erik.m.bray at gmail.com> added the comment:

As far as I've been able to tell there is no proposed syntax in the docs specifically for package_data.  The docs for the resources option seems to suggest separating globs with spaces, which would be fine by me (wouldn't allow paths that contain spaces, but that's a bad idea anyways).

I think that allowing one glob string on each line is more readable, but I'm not too attached either way.  Another possibility would be to allow line breaks in the value, for example:

package data = 
    mypackage = templates/*.html
                static/css/*.css

But that's getting a little more complex syntax-wise.

Agreed on getting rid of data_files--it's dangerous.  But package_data I find very useful sometimes, and I don't think it's always wrong.  At the very least, it's not clear to me how the above use case is intended to be replaced.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11805>
_______________________________________

From report at bugs.python.org  Sat Apr  9 20:13:32 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sat, 09 Apr 2011 18:13:32 +0000
Subject: [issue11757] test_subprocess.test_communicate_timeout_large_ouput
	failure on select(): negative timeout?
In-Reply-To: <1302247212.14280.8.camel@marge>
Message-ID: <BANLkTim1QMEePYdewVD+EUcjKe0Mr20nvA@mail.gmail.com>


Charles-Francois Natali <neologix at free.fr> added the comment:

> Oh, I didn't know. In this case, is my commit 3664fc29e867 correct? I
> think that it is, because without the patch, subprocess may call poll()
> with a negative timeout, and so it is no more a timeout at all.
>

Yes, it looks correct.
But I think there are a couple places left where functions can be
called with a negative timeout, for example here :

  1537                 stdout, stderr =
self._communicate_with_select(input, endtime,
  1538
orig_timeout)
  1539
  1540             self.wait(timeout=self._remaining_time(endtime))

or here:

  1113             if self.stdout is not None:
  1114                 self.stdout_thread.join(self._remaining_time(endtime))
  1115                 if self.stdout_thread.isAlive():

Also, it might be simpler and cleaner to factorize the raising of the
TimeoutExpired exception inside _remaining_time, instead of scattering
this kind of checks around the file:

  1514                     remaining = self._remaining_time(endtime)
  1515                     if remaining <= 0:
  1516                         raise TimeoutExpired(self.args, timeout)

merging what's done in _check_timeout

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11757>
_______________________________________

From report at bugs.python.org  Sat Apr  9 20:37:31 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 09 Apr 2011 18:37:31 +0000
Subject: [issue11650] Faulty RESTART/EINTR handling in Parser/myreadline.c
In-Reply-To: <1302358681.57.0.769544160302.issue11650@psf.upfronthosting.co.za>
Message-ID: <20110409183719.GB79519@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

On Sat, Apr 09, 2011 at 02:18:01PM +0000, STINNER Victor wrote:
> I noticied a strange behaviour:

So forget all this girlie s...!
Here is a real man's patch!!
You'll notice mysterious function calls with a Py prefix -
they're necessary in this environment, but anyway sorry for that.
(L'ascenseur est l??, ?? gauche.
And i'll hope to come to lesson 2 soon...)

P.S.: this is very simple minded in respect to multibyte 
characters; our terminal library does something like this
(and the complete picture is even more complicated):

jnext:  uni = s_textcodec_decode_single(_sterm_io_codec, cbuf, cbuf_len,
                                        &bytes_consumed);
        cbuf += bytes_consumed;
        cbuf_len -= bytes_consumed;
        if (s_PREDICT_FALSE(uni < 0)) {
                if (uni == -s_ERROR_INPROGRESS) {
                        seq_cpl = s_FAL0;
                        goto jleave;
                }
                /*if (uni == -s_ERROR_ILSEQ || uni == -s_ERROR_INVAL) {*/
                        cbuf_len = 0;
                        uni = sterm_KEY_UNKNOWN;
                        goto jemit;
                /*}*/
        }

----------
Added file: http://bugs.python.org/file21593/11650.termios.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11650>
_______________________________________
-------------- next part --------------
diff --git a/Parser/myreadline.c b/Parser/myreadline.c
--- a/Parser/myreadline.c
+++ b/Parser/myreadline.c
@@ -10,6 +10,9 @@
 */
 
 #include "Python.h"
+#ifdef Py_PYPORT_H
+# include "signal.h"
+#endif
 #ifdef MS_WINDOWS
 #define WIN32_LEAN_AND_MEAN
 #include "windows.h"
@@ -29,117 +32,187 @@
 
 int (*PyOS_InputHook)(void) = NULL;
 
-/* This function restarts a fgets() after an EINTR error occurred
+/* This function restarts a fgetc() after an EINTR error occurred
    except if PyOS_InterruptOccurred() returns true. */
+static int
+my_fgets(char **store, FILE *fp)
+{
+    int estat;
+    char *buf, *cursor;
+    size_t buf_len;
 
-static int
-my_fgets(char *buf, int len, FILE *fp)
-{
-    char *p;
+    buf = (char*)PyMem_MALLOC(2*80);
+    estat = 1;
+    if (buf == NULL)
+        goto jreturn;
+
+    cursor = buf;
+    buf_len = 2*80 - 2;
+jrestart_input:
+    estat = 0;
+
+    if (PyOS_InputHook != NULL)
+        (void)(PyOS_InputHook)();
+
+    /* Fetch bytes until error or newline */
+    errno = 0;
     while (1) {
-        if (PyOS_InputHook != NULL)
-            (void)(PyOS_InputHook)();
-        errno = 0;
-        p = fgets(buf, len, fp);
-        if (p != NULL)
-            return 0; /* No error */
+        int c = fgetc(fp);
+#ifdef Py_PYPORT_H
+        if (!isprint(c))
+            switch (c) {
+            case '':
+                c = EOF;
+                /* FALLTHROUGH */
+            default:
+                break;
+            case '':
+                estat = SIGINT;
+                goto j_sigit;
+            case '':
+                estat = SIGTSTP;
+                goto j_sigit;
+            case '':
+                estat = SIGQUIT;
+                /* FALLTHROUGH */
+j_sigit:        kill(getpid(), estat);
+                errno = EINTR;
+                goto jcheck_fail;
+            }
+#endif
+        if (c == EOF)
+            goto jcheck_fail;
+        *(cursor++) = (char)c;
+        if (c == '\n')
+            break;
+
+        if ((size_t)(cursor-buf) >= buf_len) {
+            buf_len += 2+32;
+            cursor = buf = (char*)PyMem_REALLOC(buf, buf_len);
+            if (buf == NULL) {
+                estat = 1;
+                goto jreturn;
+            }
+            buf_len -= 2+32;
+            cursor += buf_len;
+            buf_len += 32;
+        }
+    }
+
+    *cursor = '\0';
+    *store = buf;
+jreturn:
+    return estat;
+
+jcheck_fail:
 #ifdef MS_WINDOWS
-        /* In the case of a Ctrl+C or some other external event
-           interrupting the operation:
-           Win2k/NT: ERROR_OPERATION_ABORTED is the most recent Win32
-           error code (and feof() returns TRUE).
-           Win9x: Ctrl+C seems to have no effect on fgets() returning
-           early - the signal handler is called, but the fgets()
-           only returns "normally" (ie, when Enter hit or feof())
+    /* In the case of a Ctrl+C or some other external event
+       interrupting the operation:
+       Win2k/NT: ERROR_OPERATION_ABORTED is the most recent Win32
+       error code (and feof() returns TRUE).
+       Win9x: Ctrl+C seems to have no effect on fgets() returning
+       early - the signal handler is called, but the fgets()
+       only returns "normally" (ie, when Enter hit or feof())
+    */
+    if (GetLastError()==ERROR_OPERATION_ABORTED) {
+        /* Signals come asynchronously, so we sleep a brief
+           moment before checking if the handler has been
+           triggered (we cant just return 1 before the
+           signal handler has been called, as the later
+           signal may be treated as a separate interrupt).
         */
-        if (GetLastError()==ERROR_OPERATION_ABORTED) {
-            /* Signals come asynchronously, so we sleep a brief
-               moment before checking if the handler has been
-               triggered (we cant just return 1 before the
-               signal handler has been called, as the later
-               signal may be treated as a separate interrupt).
-            */
-            Sleep(1);
-            if (PyOS_InterruptOccurred()) {
-                return 1; /* Interrupt */
-            }
-            /* Either the sleep wasn't long enough (need a
-               short loop retrying?) or not interrupted at all
-               (in which case we should revisit the whole thing!)
-               Logging some warning would be nice.  assert is not
-               viable as under the debugger, the various dialogs
-               mean the condition is not true.
-            */
+        Sleep(1);
+        if (PyOS_InterruptOccurred()) {
+            estat = 1;
+            goto jfail;
         }
+        /* Either the sleep wasn't long enough (need a
+           short loop retrying?) or not interrupted at all
+           (in which case we should revisit the whole thing!)
+           Logging some warning would be nice.  assert is not
+           viable as under the debugger, the various dialogs
+           mean the condition is not true.
+        */
+    }
 #endif /* MS_WINDOWS */
-        if (feof(fp)) {
-            return -1; /* EOF */
+
+#ifndef Py_PYPORT_H
+    if (feof(fp)) {
+        estat = -1; /* EOF */
+        goto jfail;
+    }
+#endif
+#ifdef EINTR
+    if (errno == EINTR) {
+# ifdef WITH_THREAD
+        PyEval_RestoreThread(_PyOS_ReadlineTState);
+# endif
+        estat = PyErr_CheckSignals();
+# ifdef WITH_THREAD
+        PyEval_SaveThread();
+# endif
+        if (estat < 0) {
+            estat = 1;
+            goto jfail;
         }
-#ifdef EINTR
-        if (errno == EINTR) {
-            int s;
-#ifdef WITH_THREAD
-            PyEval_RestoreThread(_PyOS_ReadlineTState);
+        /* EINTR is restarted */
+        goto jrestart_input;
+    }
 #endif
-            s = PyErr_CheckSignals();
-#ifdef WITH_THREAD
-            PyEval_SaveThread();
-#endif
-            if (s < 0)
-                    return 1;
-	    /* try again */
-            continue;
-        }
-#endif
-        if (PyOS_InterruptOccurred()) {
-            return 1; /* Interrupt */
-        }
-        return -2; /* Error */
+
+    if (PyOS_InterruptOccurred()) {
+        estat = 1; /* Interrupt */
+        goto jfail;
     }
-    /* NOTREACHED */
+    estat = -2; /* Error */
+    /* FALLTHROUGH */
+
+jfail:
+    PyMem_Free(buf);
+    goto jreturn;
 }
 
-
-/* Readline implementation using fgets() */
-
+/* Readline implementation using my_fgets() */
 char *
 PyOS_StdioReadline(FILE *sys_stdin, FILE *sys_stdout, char *prompt)
 {
-    size_t n;
-    char *p;
-    n = 100;
-    if ((p = (char *)PyMem_MALLOC(n)) == NULL)
-        return NULL;
+    auto char *result = NULL;
+#ifdef Py_PYPORT_H
+    auto struct termios told, tnew;
+    int infd = fileno(sys_stdin);
+
+    while (tcgetattr(infd, &told) != 0)
+        ;
+    memcpy(&tnew, &told, sizeof(told));
+    tnew.c_lflag &= ~(ECHOCTL | ICANON);
+    tnew.c_cc[VMIN] = 1;
+    while (tcsetattr(infd, TCSAFLUSH, &tnew) != 0)
+        ;
+#endif
+
     fflush(sys_stdout);
     if (prompt)
         fprintf(stderr, "%s", prompt);
     fflush(stderr);
-    switch (my_fgets(p, (int)n, sys_stdin)) {
+
+    switch (my_fgets(&result, sys_stdin)) {
     case 0: /* Normal case */
+    case 1: /* Interrupt */
         break;
-    case 1: /* Interrupt */
-        PyMem_FREE(p);
-        return NULL;
     case -1: /* EOF */
     case -2: /* Error */
     default: /* Shouldn't happen */
-        *p = '\0';
+        result = (char*)PyMem_MALLOC(sizeof(void*));
+        if (result != NULL)
+            *result = '\0';
         break;
     }
-    n = strlen(p);
-    while (n > 0 && p[n-1] != '\n') {
-        size_t incr = n+2;
-        p = (char *)PyMem_REALLOC(p, n + incr);
-        if (p == NULL)
-            return NULL;
-        if (incr > INT_MAX) {
-            PyErr_SetString(PyExc_OverflowError, "input line too long");
-        }
-        if (my_fgets(p+n, (int)incr, sys_stdin) != 0)
-            break;
-        n += strlen(p+n);
-    }
-    return (char *)PyMem_REALLOC(p, n+1);
+
+#ifdef Py_PYPORT_H
+    while (tcsetattr(infd, TCSANOW, &told) != 0)
+        ;
+#endif
+    return result;
 }
 
 

From report at bugs.python.org  Sat Apr  9 20:42:01 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Apr 2011 18:42:01 +0000
Subject: [issue11719] test_msilib skip unexpected on non-Windows platforms
In-Reply-To: <1301464610.3.0.910071471193.issue11719@psf.upfronthosting.co.za>
Message-ID: <E1Q8d6d-0005Ji-Rk@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d4730f14b6c0 by Ross Lagerwall in branch '3.1':
Issue #11719: Fix message about unexpected test_msilib skip.
http://hg.python.org/cpython/rev/d4730f14b6c0

New changeset 8b146103d29e by Ross Lagerwall in branch '2.7':
Issue #11719: Fix message about unexpected test_msilib skip.
http://hg.python.org/cpython/rev/8b146103d29e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11719>
_______________________________________

From report at bugs.python.org  Sat Apr  9 20:44:26 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 09 Apr 2011 18:44:26 +0000
Subject: [issue11719] test_msilib skip unexpected on non-Windows platforms
In-Reply-To: <1301464610.3.0.910071471193.issue11719@psf.upfronthosting.co.za>
Message-ID: <1302374666.04.0.887401610918.issue11719@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Thanks for the patch.

----------
assignee:  -> rosslagerwall
nosy: +rosslagerwall
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11719>
_______________________________________

From report at bugs.python.org  Sat Apr  9 20:45:35 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 09 Apr 2011 18:45:35 +0000
Subject: [issue11782] email.generator.Generator.flatten() fails
In-Reply-To: <20110409115611.GA46216@sherwood.local>
Message-ID: <20110409184527.GA99786@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

On Sat, Apr 09, 2011 at 11:56:16AM +0000, Steffen Daode Nurpmeso wrote:
> I'll try to instrument the path a bit ..

Sorry, no time today.  All the stuff next week.
Nice weekend.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11782>
_______________________________________

From report at bugs.python.org  Sat Apr  9 20:52:22 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 09 Apr 2011 18:52:22 +0000
Subject: [issue11809] Rietveld Code Review Tool can't handle well-known
	controls
In-Reply-To: <1302375142.87.0.0417169208521.issue11809@psf.upfronthosting.co.za>
Message-ID: <1302375142.87.0.0417169208521.issue11809@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

The file http://bugs.python.org/file21593/11650.termios.diff
cannot be parsed, i guess it's due to ^D, ^Z, ^\ and ^C being
embedded as ASCII control characters.
Maybe this is a feature, though.
Then someone should close this.
Nice weekend all of you.

----------
components: None
messages: 133411
nosy: sdaoden
priority: normal
severity: normal
status: open
title: Rietveld Code Review Tool can't handle well-known controls

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11809>
_______________________________________

From report at bugs.python.org  Sat Apr  9 20:53:08 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 09 Apr 2011 18:53:08 +0000
Subject: [issue11809] Rietveld Code Review Tool can't handle well-known
	controls
In-Reply-To: <1302375142.87.0.0417169208521.issue11809@psf.upfronthosting.co.za>
Message-ID: <1302375188.49.0.786220384871.issue11809@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This should go to the meta-tracker, http://psf.upfronthosting.co.za/roundup/meta/.

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11809>
_______________________________________

From report at bugs.python.org  Sat Apr  9 20:59:26 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 09 Apr 2011 18:59:26 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1302375566.17.0.541914519233.issue11707@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I would have to say that this looks hardly a trivial speed patch, and chances are we cannot guarantee 100% behavior compatibility with the pure-Python version.

If you disagree with these two points, then I'm okay with it going in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11707>
_______________________________________

From report at bugs.python.org  Sat Apr  9 21:14:49 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 09 Apr 2011 19:14:49 +0000
Subject: [issue11707] Create C version of functools.cmp_to_key()
In-Reply-To: <1301358147.85.0.729395241348.issue11707@psf.upfronthosting.co.za>
Message-ID: <1302376489.45.0.247565512183.issue11707@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I agree (and was going back and forth between +0 and -0).

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11707>
_______________________________________

From report at bugs.python.org  Sat Apr  9 21:48:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Apr 2011 19:48:31 +0000
Subject: [issue9670] Exceed Recursion Limit in Thread
In-Reply-To: <1282656201.3.0.572219885558.issue9670@psf.upfronthosting.co.za>
Message-ID: <E1Q8e8z-0001nB-E3@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset b0d2b696da19 by Ned Deily in branch '2.7':
Issue #9670: Increase the default stack size for secondary threads on
http://hg.python.org/cpython/rev/b0d2b696da19

New changeset 378b40d71175 by Ned Deily in branch '3.1':
Issue #9670: Increase the default stack size for secondary threads on
http://hg.python.org/cpython/rev/378b40d71175

New changeset 3fe8fd2fd1d0 by Ned Deily in branch '3.2':
Issue #9670: merge with 3.2
http://hg.python.org/cpython/rev/3fe8fd2fd1d0

New changeset 4c750091d8c5 by Ned Deily in branch 'default':
Issue #9670: merge with current
http://hg.python.org/cpython/rev/4c750091d8c5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9670>
_______________________________________

From report at bugs.python.org  Sat Apr  9 21:50:42 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 09 Apr 2011 19:50:42 +0000
Subject: [issue11747] unified_diff function product incorrect range information
In-Reply-To: <1301806636.68.0.728514553962.issue11747@psf.upfronthosting.co.za>
Message-ID: <1302378642.82.0.920107618877.issue11747@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

[Uncle Timmy]
> Would have to look at the history to see who added it, and ask them. 

That would be me :-)

At the time, the goals were to:

1) make an easy-to-use, readable output format for file comparisons,

2) use the unmodified output of the existing SequenceMatcher(None,a,b).get_grouped_opcodes(n) method,

3) create output that works with patch and ed, and

4) comply with the output format spec in the Single Unix Specification found at http://www.unix.org/single_unix_specification/ . See the attached excerpt.

No effort was made to exactly reproduce the output of GNU diff.  It was just an alternate output format for the SequenceMatcher.

----------
nosy: +rhettinger
Added file: http://bugs.python.org/file21594/Diff_Format.pdf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11747>
_______________________________________

From report at bugs.python.org  Sat Apr  9 21:53:03 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 09 Apr 2011 19:53:03 +0000
Subject: [issue9670] Exceed Recursion Limit in Thread
In-Reply-To: <1282656201.3.0.572219885558.issue9670@psf.upfronthosting.co.za>
Message-ID: <1302378783.17.0.887651355422.issue9670@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Applied in 2.7 (for release in 2.7.2), 3.1 (for 3.1.4). 3.2 (for 3.2.1), and default (for 3.3).

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9670>
_______________________________________

From report at bugs.python.org  Sat Apr  9 22:14:29 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 09 Apr 2011 20:14:29 +0000
Subject: [issue9670] Exceed Recursion Limit in Thread
In-Reply-To: <1282656201.3.0.572219885558.issue9670@psf.upfronthosting.co.za>
Message-ID: <1302380069.5.0.247129710423.issue9670@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Looks like the patch breaks the OpenIndiana buildbots:

http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.2/builds/168

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9670>
_______________________________________

From report at bugs.python.org  Sat Apr  9 22:19:44 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 09 Apr 2011 20:19:44 +0000
Subject: [issue11747] unified_diff function product incorrect range information
In-Reply-To: <1301806636.68.0.728514553962.issue11747@psf.upfronthosting.co.za>
Message-ID: <1302380384.98.0.888756843302.issue11747@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11747>
_______________________________________

From report at bugs.python.org  Sat Apr  9 22:36:02 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Apr 2011 20:36:02 +0000
Subject: [issue11747] unified_diff function product incorrect range information
In-Reply-To: <1301806636.68.0.728514553962.issue11747@psf.upfronthosting.co.za>
Message-ID: <1302381362.95.0.629365907417.issue11747@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thanks, Raymond. That file says (in the -u section) "If a range is empty, its beginning line number shall be the number of the line just before the range, or 0 if the empty range starts the file." The last clause says to me that gnu diff is right and that the 1,0 range of difflib.unified_diff is a bug.

I think we should add this link to the difflib doc (I am still thinking about place and wording).

News entry might be
Issue # 11747: Correct difflib.unified_diff empty file range from 1,0 to 0,0 in conformance with Single Unix Specification for diff output formats. Patch by ysj.ray.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11747>
_______________________________________

From report at bugs.python.org  Sat Apr  9 22:49:39 2011
From: report at bugs.python.org (Emile Heitor)
Date: Sat, 09 Apr 2011 20:49:39 +0000
Subject: [issue11810] _socket fails to build on OpenIndiana
In-Reply-To: <1302382179.44.0.700403156795.issue11810@psf.upfronthosting.co.za>
Message-ID: <1302382179.44.0.700403156795.issue11810@psf.upfronthosting.co.za>


New submission from Emile Heitor <imil at NetBSD.org>:

This issue http://bugs.python.org/issue8852 seems to happen again since python 2.6.6. Same cause, same consequences. Patching Modules/socketmodule.h with the following fixes it:

--- Modules/socketmodule.h.orig 2010-05-09 15:15:40.000000000 +0000             
+++ Modules/socketmodule.h                                                      
@@ -59,6 +59,10 @@ typedef int socklen_t;                                       
 #include <bluetooth.h>                                                         
 #endif                                                                         
                                                                                
+#if defined(__sun)                                                             
+#undef HAVE_NETPACKET_PACKET_H                                                 
+#endif                                                                         
+                                                                               
 #ifdef HAVE_NETPACKET_PACKET_H                                                 
 # include <sys/ioctl.h>                                                        
 # include <net/if.h>

----------
components: Build
messages: 133420
nosy: iMil
priority: normal
severity: normal
status: open
title: _socket fails to build on OpenIndiana
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11810>
_______________________________________

From report at bugs.python.org  Sat Apr  9 22:58:42 2011
From: report at bugs.python.org (Torsten Becker)
Date: Sat, 09 Apr 2011 20:58:42 +0000
Subject: [issue11783] email parseaddr and formataddr should be IDNA aware
In-Reply-To: <1302099121.47.0.140525796896.issue11783@psf.upfronthosting.co.za>
Message-ID: <1302382722.97.0.592159966121.issue11783@psf.upfronthosting.co.za>


Torsten Becker <torsten.becker at gmail.com> added the comment:

> Have a nice weekend!

Thank you for the wishes, I hope yours is going well, too!

I added IDNA awareness to formataddr() and parseaddr(), updated the docs and wrote 2 tests for it.

I wasn't sure if the IDNA awareness should be optional via a argument or always automatically enabled, I favored the latter.

Also, is it safe to split at "@" and encode/decode the last component?  I am not familiar with all the weird variants a email address could be in strictly after the RFCs.

----------
keywords: +patch
Added file: http://bugs.python.org/file21595/issue-11783-v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11783>
_______________________________________

From report at bugs.python.org  Sat Apr  9 23:18:20 2011
From: report at bugs.python.org (Paul Wouters)
Date: Sat, 09 Apr 2011 21:18:20 +0000
Subject: [issue11811] ssl.get_server_certificate() does not work for IPv6
	addresses
In-Reply-To: <1302383900.51.0.808943452569.issue11811@psf.upfronthosting.co.za>
Message-ID: <1302383900.51.0.808943452569.issue11811@psf.upfronthosting.co.za>


New submission from Paul Wouters <paul at xelerance.com>:

ssl.get_server_certificate() does not work for IPv6 addresses:

>>> ssl.get_server_certificate( ("2001:888:2003:1004:c2ff:eeff:fe00:133",443))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.7/ssl.py", line 403, in get_server_certificate
    s.connect(addr)
  File "/usr/lib64/python2.7/ssl.py", line 292, in connect
    socket.connect(self, addr)
  File "/usr/lib64/python2.7/socket.py", line 222, in meth
    return getattr(self._sock,name)(*args)
socket.gaierror: [Errno -9] Address family for hostname not supported

----------
messages: 133422
nosy: pwouters
priority: normal
severity: normal
status: open
title: ssl.get_server_certificate() does not work for IPv6 addresses
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11811>
_______________________________________

From report at bugs.python.org  Sat Apr  9 23:19:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Apr 2011 21:19:23 +0000
Subject: [issue11810] _socket fails to build on OpenIndiana
In-Reply-To: <1302382179.44.0.700403156795.issue11810@psf.upfronthosting.co.za>
Message-ID: <1302383963.67.0.0943400442645.issue11810@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It has been fixed in 2.7.x, not 2.6.x (which is in security fixes-only mode).
Can you try with 2.7.1?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11810>
_______________________________________

From report at bugs.python.org  Sat Apr  9 23:24:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Apr 2011 21:24:14 +0000
Subject: [issue11811] ssl.get_server_certificate() does not work for IPv6
	addresses
In-Reply-To: <1302383900.51.0.808943452569.issue11811@psf.upfronthosting.co.za>
Message-ID: <1302384254.43.0.32518445215.issue11811@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Confirmed. In the meantime, you can connect manually using socket.create_connection():

>>> import ssl, socket
>>> conn = socket.create_connection(("2001:888:2003:1004:c2ff:eeff:fe00:133", 443))
>>> sock = ssl.wrap_socket(conn)
>>> ssl.DER_cert_to_PEM_cert(sock.getpeercert(True))
'-----BEGIN CERTIFICATE-----\nMIID8DCCA1mgAwIBAgICVVUwDQYJKoZIhvcNAQEFBQAwgbExCzAJBgNVBAYTAi0t\nMRIwEAYDVQQIEwlTb21lU3RhdGUxETAPBgNVBAcTCFNvbWVDaXR5MRkwFwYDVQQK\nExBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLExZTb21lT3JnYW5pemF0aW9uYWxV\nbml0MRkwFwYDVQQDExB3cC54ZWxlcmFuY2UubmV0MSQwIgYJKoZIhvcNAQkBFhVy\nb290QHdwLnhlbGVyYW5jZS5uZXQwHhcNMTEwNDA4MjM0MzE3WhcNMTIwNDA3MjM0\nMzE3WjCBsTELMAkGA1UEBhMCLS0xEjAQBgNVBAgTCVNvbWVTdGF0ZTERMA8GA1UE\nBxMIU29tZUNpdHkxGTAXBgNVBAoTEFNvbWVPcmdhbml6YXRpb24xHzAdBgNVBAsT\nFlNvbWVPcmdhbml6YXRpb25hbFVuaXQxGTAXBgNVBAMTEHdwLnhlbGVyYW5jZS5u\nZXQxJDAiBgkqhkiG9w0BCQEWFXJvb3RAd3AueGVsZXJhbmNlLm5ldDCBnzANBgkq\nhkiG9w0BAQEFAAOBjQAwgYkCgYEAsLBCgvH5g8ypkuufFQ55BFoWcjpAocsRV+jN\nW5zylXzM7F9/cMyTli757JGRdwL0l+bLPdojdYwKb6XjTWfJonqentBMG6iktLXZ\n66oUQl77UHOyL7XKynmO6wSGFd/qAoA8O5O9IRLPNcD4+NMTQjGSMFPvjnUnOSH2\n8nMVmZUCAwEAAaOCARMwggEPMB0GA1UdDgQWBBRFGGojncjKvGfxjgU8EOapc0Yi\nyjCB3wYDVR0jBIHXMIHUgBRFGGojncjKvGfxjgU8EOapc0YiyqGBt6SBtDCBsTEL\nMAkGA1UEBhMCLS0xEjAQBgNVBAgTCVNvbWVTdGF0ZTERMA8GA1UEBxMIU29tZUNp\ndHkxGTAXBgNVBAoTEFNvbWVPcmdhbml6YXRpb24xHzAdBgNVBAsTFlNvbWVPcmdh\nbml6YXRpb25hbFVuaXQxGTAXBgNVBAMTEHdwLnhlbGVyYW5jZS5uZXQxJDAiBgkq\nhkiG9w0BCQEWFXJvb3RAd3AueGVsZXJhbmNlLm5ldIICVVUwDAYDVR0TBAUwAwEB\n/zANBgkqhkiG9w0BAQUFAAOBgQCnLIAJ8ghuqUUiVOuq6tiRby65dh+7L1ApSp8G\nwusWF/rYugvqUxL1O1vatd1ptyXpoCLM0XzQ5sBtY0yS8IjMON9++Uu+u5IkQ+24\nkwvpgWp3lX8Zuxhbnmym/LGoJq4PgqXl1bsGJ+SIALQ31g7nrNE2HQz1IYRQEj/k\neG8F7g==\n-----END CERTIFICATE-----\n'

----------
nosy: +pitrou
stage:  -> needs patch
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11811>
_______________________________________

From report at bugs.python.org  Sat Apr  9 23:30:34 2011
From: report at bugs.python.org (Emile Heitor)
Date: Sat, 09 Apr 2011 21:30:34 +0000
Subject: [issue11810] _socket fails to build on OpenIndiana
In-Reply-To: <1302382179.44.0.700403156795.issue11810@psf.upfronthosting.co.za>
Message-ID: <1302384634.4.0.803336645475.issue11810@psf.upfronthosting.co.za>


Emile Heitor <imil at NetBSD.org> added the comment:

Actually, python 2.6 is the default version in pkgsrc (http://www.netbsd.org/docs/software/packages.html), and the reason why i'm pulling up this bug is that python 2.6 failure on SunOS brings down more than 3000 packages :/ Nevertheless, i'll try a bulk build with python 2.7 as the default version, thanks for the heads up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11810>
_______________________________________

From report at bugs.python.org  Sat Apr  9 23:34:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Apr 2011 21:34:59 +0000
Subject: [issue11811] ssl.get_server_certificate() does not work for IPv6
	addresses
In-Reply-To: <1302383900.51.0.808943452569.issue11811@psf.upfronthosting.co.za>
Message-ID: <1302384899.59.0.0798666352257.issue11811@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Library (Lib)
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11811>
_______________________________________

From report at bugs.python.org  Sat Apr  9 23:42:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Apr 2011 21:42:20 +0000
Subject: [issue11810] _socket fails to build on OpenIndiana
In-Reply-To: <1302384634.4.0.803336645475.issue11810@psf.upfronthosting.co.za>
Message-ID: <1302385336.3537.11.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Actually, python 2.6 is the default version in pkgsrc
> (http://www.netbsd.org/docs/software/packages.html), and the reason
> why i'm pulling up this bug is that python 2.6 failure on SunOS brings
> down more than 3000 packages :/ Nevertheless, i'll try a bulk build
> with python 2.7 as the default version, thanks for the heads up.

Well, do you need to ship your own build of Python with pkgsrc?
OpenIndiana and recent Solaris versions should AFAIK ship a system
Python 2.6 by default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11810>
_______________________________________

From report at bugs.python.org  Sat Apr  9 23:50:04 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Apr 2011 21:50:04 +0000
Subject: [issue11757] test_subprocess.test_communicate_timeout_large_ouput
	failure on select(): negative timeout?
In-Reply-To: <1301869705.52.0.173979620005.issue11757@psf.upfronthosting.co.za>
Message-ID: <E1Q8g2c-0001Ig-Qf@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3982be773b54 by Antoine Pitrou in branch 'default':
Issue #11757: select.select() now raises ValueError when a negative timeout
http://hg.python.org/cpython/rev/3982be773b54

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11757>
_______________________________________

From report at bugs.python.org  Sat Apr  9 23:56:23 2011
From: report at bugs.python.org (Emile Heitor)
Date: Sat, 09 Apr 2011 21:56:23 +0000
Subject: [issue11810] _socket fails to build on OpenIndiana
In-Reply-To: <1302382179.44.0.700403156795.issue11810@psf.upfronthosting.co.za>
Message-ID: <1302386183.95.0.834147786356.issue11810@psf.upfronthosting.co.za>


Emile Heitor <imil at NetBSD.org> added the comment:

Well, pkgsrc is an independent, portable sources-based packaging system which provides a complete set of packages for many architectures. Python is provided as a package per-se, and we do not yet have the ability to fallback to native python version.
If this patch is not to be pulled up to python 2.6 then we'll provide it as a separate patch to pkgsrc, that's really not a problem, i understand perfectly that python 2.6 is now on a maintenance state.

Thanks for your feedback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11810>
_______________________________________

From report at bugs.python.org  Sat Apr  9 23:56:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Apr 2011 21:56:54 +0000
Subject: [issue11812] transient test_telnetlib failure
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/2920/steps/test/logs/stdio

test test_telnetlib failed -- Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_telnetlib.py", line 45, in testBasic
    telnet = telnetlib.Telnet(HOST, self.port)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\telnetlib.py", line 209, in __init__
    self.open(host, port, timeout)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\telnetlib.py", line 225, in open
    self.sock = socket.create_connection((host, port), timeout)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\socket.py", line 407, in create_connection
    raise err
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\socket.py", line 398, in create_connection
    sock.connect(sa)
socket.error: [Errno 10061] No connection could be made because the target machine actively refused it

----------
components: Library (Lib), Tests
messages: 133429
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: transient test_telnetlib failure
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Sat Apr  9 23:58:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Apr 2011 21:58:27 +0000
Subject: [issue11810] _socket fails to build on OpenIndiana
In-Reply-To: <1302382179.44.0.700403156795.issue11810@psf.upfronthosting.co.za>
Message-ID: <1302386307.01.0.255758212269.issue11810@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11810>
_______________________________________

From report at bugs.python.org  Sun Apr 10 00:01:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Apr 2011 22:01:22 +0000
Subject: [issue9670] Exceed Recursion Limit in Thread
In-Reply-To: <1282656201.3.0.572219885558.issue9670@psf.upfronthosting.co.za>
Message-ID: <E1Q8gDY-0005sl-Mm@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 42d5001e5845 by Ned Deily in branch '3.1':
Issue9670: Back out changeset 378b40d71175; test fails on other platforms
http://hg.python.org/cpython/rev/42d5001e5845

New changeset 54edabf2846d by Ned Deily in branch '3.2':
Issue9670: Merge backout to 3.2.
http://hg.python.org/cpython/rev/54edabf2846d

New changeset b7456c1b4aa4 by Ned Deily in branch 'default':
Issue9670: Merge backout from 3.2.
http://hg.python.org/cpython/rev/b7456c1b4aa4

New changeset 3630bc3d5a88 by Ned Deily in branch '2.7':
Issue9670: Back out changeset b0d2b696da19; test fails on other platforms
http://hg.python.org/cpython/rev/3630bc3d5a88

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9670>
_______________________________________

From report at bugs.python.org  Sun Apr 10 00:10:00 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 09 Apr 2011 22:10:00 +0000
Subject: [issue9670] Exceed Recursion Limit in Thread
In-Reply-To: <1282656201.3.0.572219885558.issue9670@psf.upfronthosting.co.za>
Message-ID: <1302387000.97.0.548082906028.issue9670@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Reverting the patch since it caused failures on failure on some other platform buildbots (for instance, Gentoo and OpenIndiana).  It also fails on OS X buildbots with pydebug enabled, something I hadn't tested:
http://www.python.org/dev/buildbot/all/builders/AMD64%20Leopard%203.2/builds/161

So the patch needs to address the stack size for OS X pydebug builds and what to do about other failing platforms - increase the stack size for each or disable the test there.

----------
stage: committed/rejected -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9670>
_______________________________________

From report at bugs.python.org  Sun Apr 10 00:44:20 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sat, 09 Apr 2011 22:44:20 +0000
Subject: [issue11813] inspect.getattr_static doesn't get module attributes
In-Reply-To: <1302389059.87.0.554654770337.issue11813@psf.upfronthosting.co.za>
Message-ID: <1302389059.87.0.554654770337.issue11813@psf.upfronthosting.co.za>


New submission from Andreas St?hrk <andy-python at hammerhartes.de>:

My patch for issue #11133 introduced a regression: it is no longer possible to get attributes of modules. That is because modules use "tp_dictoffset" (at C level). The instance __dict__ is exposed to Python code using a types.MemberDescriptorType. My patch for issue #11133 currently assumes that accessing the instance __dict__ can trigger code execution, but that is impossible: The access itself can't trigger code execution (it just returns a PyObject in the C struct). Theoretically, it could return any Python object, but that doesn't matter, as the code that uses the object only calls dict methods directly, hence a TypeError is the worst thing that can happen (although it shouldn't ever happen in practise).

Attached is a patch that adds a test and fixes the issue.

----------
components: Library (Lib)
files: getattr_static_modules.patch
keywords: patch
messages: 133432
nosy: Trundle, michael.foord
priority: normal
severity: normal
status: open
title: inspect.getattr_static doesn't get module attributes
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21596/getattr_static_modules.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11813>
_______________________________________

From report at bugs.python.org  Sun Apr 10 01:07:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Apr 2011 23:07:20 +0000
Subject: [issue11814] possible typo in multiprocessing.Pool._terminate
In-Reply-To: <1302390440.77.0.392480963039.issue11814@psf.upfronthosting.co.za>
Message-ID: <1302390440.77.0.392480963039.issue11814@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

There's the following code in pool.py, line 494 and following:

        debug('joining task handler')
        task_handler.join()

        debug('joining result handler')
        task_handler.join()

It seems the last line should read `result_handler.join()` instead.

Additionally, when _terminate() is called, it seems the worker_handler could still run while other threads shut down existing workers, meaning it could start new workers (in _repopulate_pool()) in parallel.

So perhaps the worker_handler should be joined before anything else in _terminate(). It would incur a small latency, though (because of the sleep() call there).

----------
messages: 133433
nosy: asksol, jnoller, pitrou
priority: normal
severity: normal
status: open
title: possible typo in multiprocessing.Pool._terminate
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11814>
_______________________________________

From report at bugs.python.org  Sun Apr 10 01:19:22 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sat, 09 Apr 2011 23:19:22 +0000
Subject: [issue11770] inspect.dir_static
In-Reply-To: <1302001735.74.0.572603626553.issue11770@psf.upfronthosting.co.za>
Message-ID: <1302391162.56.0.854338205365.issue11770@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

See issue #11813 for the module problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11770>
_______________________________________

From report at bugs.python.org  Sun Apr 10 01:27:50 2011
From: report at bugs.python.org (Jack Diederich)
Date: Sat, 09 Apr 2011 23:27:50 +0000
Subject: [issue11812] transient test_telnetlib failure
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1302391670.0.0.148314693492.issue11812@psf.upfronthosting.co.za>


Changes by Jack Diederich <jackdied at gmail.com>:


----------
nosy: +jackdied

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Sun Apr 10 01:37:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Apr 2011 23:37:47 +0000
Subject: [issue11815] Simplifications in concurrent.futures
In-Reply-To: <1302392267.12.0.152242610702.issue11815@psf.upfronthosting.co.za>
Message-ID: <1302392267.12.0.152242610702.issue11815@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Queue.get(block=True) cannot raise EmptyError, meaning there's some dead code that we can remove.

----------
components: Library (Lib)
files: cfsimplify.patch
keywords: patch
messages: 133435
nosy: bquinlan, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Simplifications in concurrent.futures
type: resource usage
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21597/cfsimplify.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11815>
_______________________________________

From report at bugs.python.org  Sun Apr 10 01:45:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Apr 2011 23:45:14 +0000
Subject: [issue11815] Simplifications in concurrent.futures
In-Reply-To: <1302392267.12.0.152242610702.issue11815@psf.upfronthosting.co.za>
Message-ID: <1302392714.47.0.0660711097053.issue11815@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

A further optimization would be to use a SimpleQueue (from multiprocessing.queues) for the result_queue in the ProcessPoolExecutor. A SimpleQueue is much more light-weight than a normal Queue, which has a bunch of additional locks and a dedicated thread.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11815>
_______________________________________

From report at bugs.python.org  Sun Apr 10 02:01:54 2011
From: report at bugs.python.org (Michael Foord)
Date: Sun, 10 Apr 2011 00:01:54 +0000
Subject: [issue11796] Comprehensions in a class definition mostly cannot
	access class variable
In-Reply-To: <1302180921.17.0.22284518515.issue11796@psf.upfronthosting.co.za>
Message-ID: <1302393714.64.0.383229315115.issue11796@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11796>
_______________________________________

From report at bugs.python.org  Sun Apr 10 02:20:10 2011
From: report at bugs.python.org (Eugene Toder)
Date: Sun, 10 Apr 2011 00:20:10 +0000
Subject: [issue11816] Add functions to return disassembly as string
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>


New submission from Eugene Toder <eltoder at gmail.com>:

As discussed in Issue11549 a couple of tests need to inspect disassembly of some code. Currently they have to override sys.stdout, run dis and restore stdout back. It would be much nicer if dis module provided functions that return disassembly as a string.

Provided is a patch that adds file argument to most dis functions, defaulting to sys.stdout. On top of that there are 2 new functions: dis_to_str and disassembly_to_str that return disassembly as a string instead of writing it to a file.

----------
components: Library (Lib)
files: dis.diff
keywords: patch
messages: 133437
nosy: eltoder
priority: normal
severity: normal
status: open
title: Add functions to return disassembly as string
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file21598/dis.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Sun Apr 10 02:23:11 2011
From: report at bugs.python.org (Eugene Toder)
Date: Sun, 10 Apr 2011 00:23:11 +0000
Subject: [issue11816] Add functions to return disassembly as string
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1302394991.81.0.135803546077.issue11816@psf.upfronthosting.co.za>


Changes by Eugene Toder <eltoder at gmail.com>:


Removed file: http://bugs.python.org/file21598/dis.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Sun Apr 10 02:23:23 2011
From: report at bugs.python.org (Eugene Toder)
Date: Sun, 10 Apr 2011 00:23:23 +0000
Subject: [issue11816] Add functions to return disassembly as string
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1302395003.18.0.0072012424779.issue11816@psf.upfronthosting.co.za>


Changes by Eugene Toder <eltoder at gmail.com>:


Added file: http://bugs.python.org/file21599/dis.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Sun Apr 10 02:24:39 2011
From: report at bugs.python.org (Eugene Toder)
Date: Sun, 10 Apr 2011 00:24:39 +0000
Subject: [issue11816] Add functions to return disassembly as string
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1302395079.61.0.830275849297.issue11816@psf.upfronthosting.co.za>


Changes by Eugene Toder <eltoder at gmail.com>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Sun Apr 10 04:08:58 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Apr 2011 02:08:58 +0000
Subject: [issue11816] Add functions to return disassembly as string
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1302401338.75.0.509321579544.issue11816@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Inspecting the text disassembly is a bit fragile for testing.  It would be better to scan a list of (opcode, oparg) pairs for given pattern (i.e. (LOAD_CONST, 3) where consts[3] --> some target value).

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Sun Apr 10 04:17:29 2011
From: report at bugs.python.org (Eugene Toder)
Date: Sun, 10 Apr 2011 02:17:29 +0000
Subject: [issue11816] Add functions to return disassembly as string
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1302401849.65.0.0341509419508.issue11816@psf.upfronthosting.co.za>


Eugene Toder <eltoder at gmail.com> added the comment:

Agreed, but that would require rewriting of all tests in test_peepholer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Sun Apr 10 04:28:39 2011
From: report at bugs.python.org (Eugene Toder)
Date: Sun, 10 Apr 2011 02:28:39 +0000
Subject: [issue5996] abstract class instantiable when subclassing dict
In-Reply-To: <1242050763.07.0.145569961651.issue5996@psf.upfronthosting.co.za>
Message-ID: <1302402519.35.0.369959954681.issue5996@psf.upfronthosting.co.za>


Eugene Toder <eltoder at gmail.com> added the comment:

This patch fixes the problem by moving the check from object_new to PyType_GenericAlloc. The check is very cheap, so this should not be an issue.

----------
keywords: +patch
nosy: +eltoder
Added file: http://bugs.python.org/file21600/abc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5996>
_______________________________________

From report at bugs.python.org  Sun Apr 10 04:44:13 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Apr 2011 02:44:13 +0000
Subject: [issue11816] Add functions to return disassembly as string
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1302403453.81.0.953813791017.issue11816@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Yep!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Sun Apr 10 04:52:08 2011
From: report at bugs.python.org (=?utf-8?q?Per_=C3=98yvind_Karlsen?=)
Date: Sun, 10 Apr 2011 02:52:08 +0000
Subject: [issue11817] berkeley db 5.1 support
In-Reply-To: <1302403928.0.0.111230204951.issue11817@psf.upfronthosting.co.za>
Message-ID: <1302403928.0.0.111230204951.issue11817@psf.upfronthosting.co.za>


New submission from Per ?yvind Karlsen <peroyvind at mandriva.org>:

This patch adds support for berkeley db <= 5.1.

----------
components: Extension Modules
files: Python-2.7.1-berkeley-db-5.1.patch
keywords: patch
messages: 133442
nosy: proyvind
priority: normal
severity: normal
status: open
title: berkeley db 5.1 support
versions: Python 2.7
Added file: http://bugs.python.org/file21601/Python-2.7.1-berkeley-db-5.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11817>
_______________________________________

From report at bugs.python.org  Sun Apr 10 04:58:21 2011
From: report at bugs.python.org (=?utf-8?q?Per_=C3=98yvind_Karlsen?=)
Date: Sun, 10 Apr 2011 02:58:21 +0000
Subject: [issue11817] berkeley db 5.1 support
In-Reply-To: <1302403928.0.0.111230204951.issue11817@psf.upfronthosting.co.za>
Message-ID: <1302404301.34.0.306731447793.issue11817@psf.upfronthosting.co.za>


Per ?yvind Karlsen <peroyvind at mandriva.org> added the comment:

forgot some additional config checks in setup.py in previous patch..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11817>
_______________________________________

From report at bugs.python.org  Sun Apr 10 05:36:42 2011
From: report at bugs.python.org (=?utf-8?q?Per_=C3=98yvind_Karlsen?=)
Date: Sun, 10 Apr 2011 03:36:42 +0000
Subject: [issue11817] berkeley db 5.1 support
In-Reply-To: <1302403928.0.0.111230204951.issue11817@psf.upfronthosting.co.za>
Message-ID: <1302406602.58.0.687538961581.issue11817@psf.upfronthosting.co.za>


Per ?yvind Karlsen <peroyvind at mandriva.org> added the comment:

sloppysloppy...

fix previous patch

----------
Added file: http://bugs.python.org/file21602/Python-2.7.1-berkeley-db-5.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11817>
_______________________________________

From report at bugs.python.org  Sun Apr 10 06:04:26 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 10 Apr 2011 04:04:26 +0000
Subject: [issue9904] Cosmetic issues that may warrant a fix in symtable.h/c
In-Reply-To: <1284964146.62.0.95975690396.issue9904@psf.upfronthosting.co.za>
Message-ID: <1302408266.3.0.818047096071.issue9904@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
stage:  -> needs patch
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9904>
_______________________________________

From report at bugs.python.org  Sun Apr 10 06:33:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Apr 2011 04:33:08 +0000
Subject: [issue9904] Cosmetic issues that may warrant a fix in symtable.h/c
In-Reply-To: <1284964146.62.0.95975690396.issue9904@psf.upfronthosting.co.za>
Message-ID: <E1Q8mKg-0004Ek-8R@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset b6fe63c914e4 by Eli Bendersky in branch 'default':
Issue #9904: fix and clarify some comments + fix indentation in symtable code
http://hg.python.org/cpython/rev/b6fe63c914e4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9904>
_______________________________________

From report at bugs.python.org  Sun Apr 10 06:34:43 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 10 Apr 2011 04:34:43 +0000
Subject: [issue9904] Cosmetic issues that may warrant a fix in symtable.h/c
In-Reply-To: <1284964146.62.0.95975690396.issue9904@psf.upfronthosting.co.za>
Message-ID: <1302410083.11.0.36117801062.issue9904@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I committed the fixes to 3.3 (see no reason to backport these). So unless there are objections I will close the issue in a few days.

----------
stage: needs patch -> commit review
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9904>
_______________________________________

From report at bugs.python.org  Sun Apr 10 07:11:34 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 10 Apr 2011 05:11:34 +0000
Subject: [issue11817] berkeley db 5.1 support
In-Reply-To: <1302403928.0.0.111230204951.issue11817@psf.upfronthosting.co.za>
Message-ID: <1302412294.02.0.168784736217.issue11817@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11817>
_______________________________________

From report at bugs.python.org  Sun Apr 10 09:10:39 2011
From: report at bugs.python.org (eduardo)
Date: Sun, 10 Apr 2011 07:10:39 +0000
Subject: [issue11818] tempfile.TemporaryFile example in docs doesnt work
In-Reply-To: <1302419439.43.0.340740214318.issue11818@psf.upfronthosting.co.za>
Message-ID: <1302419439.43.0.340740214318.issue11818@psf.upfronthosting.co.za>


New submission from eduardo <schettino72 at gmail.com>:

>From the example:
 http://docs.python.org/py3k/library/tempfile.html#examples

The error message is weird... but I guess the problem is the default mode 'w+b'.


Python 3.3a0 (default:78a66c98288d, Apr  9 2011, 16:13:31) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tempfile
>>> fp = tempfile.TemporaryFile()
>>> fp.write('hello')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'str' does not support the buffer interface
>>> fp2 = tempfile.TemporaryFile('w+')
>>> fp2.write('hello')
5
>>>

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 133447
nosy: docs at python, schettino72
priority: normal
severity: normal
status: open
title: tempfile.TemporaryFile example in docs doesnt work
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11818>
_______________________________________

From report at bugs.python.org  Sun Apr 10 09:33:06 2011
From: report at bugs.python.org (Carl Brewer)
Date: Sun, 10 Apr 2011 07:33:06 +0000
Subject: [issue11810] _socket fails to build on OpenIndiana
In-Reply-To: <1302382179.44.0.700403156795.issue11810@psf.upfronthosting.co.za>
Message-ID: <1302420786.98.0.833187011528.issue11810@psf.upfronthosting.co.za>


Carl Brewer <carl at bl.echidna.id.au> added the comment:

I know this is closed etc... but Plone (the CMS I use) is tied to various versions of Python, in particular 2.6 at this time.  Having it not build on Open[Solaris/Indiana] means I can't install current versions of Plone/Zope on this platform.  Any chance it could be fixed?

----------
nosy: +Bleve

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11810>
_______________________________________

From report at bugs.python.org  Sun Apr 10 09:35:31 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 10 Apr 2011 07:35:31 +0000
Subject: [issue11819] 'unittest -m' should not pretend it works on Python
	2.5/2.6
In-Reply-To: <1302420931.81.0.0491321221951.issue11819@psf.upfronthosting.co.za>
Message-ID: <1302420931.81.0.0491321221951.issue11819@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

The following command is broken on Python 2.5/2.6
  python -m unittest test_file
It outputs

----------------------------------------------------------------------
Ran 0 tests in 0.000s

OK

But in Python 2.7 the same command works

----------------------------------------------------------------------
Ran 1 tests in 0.000s

OK

It is even more confusing with test class method on command line:
  python26 -m unittest test_file.SomeTest
Traceback (most recent call last):
  ...
  File "C:\~env\Python26\lib\unittest.py", line 598, in loadTestsFromName
    test = obj()
  File "C:\~env\Python26\lib\unittest.py", line 216, in __init__
    (self.__class__, methodName)
ValueError: no such test method in <class 'test_file.SomeTest'>: runTest


--- 
I know that our <...> policy denies backporting such fixes to Python 2.5/2.6, but such things that make an illusion that they work while in fact they never did - see #6514, make Python really suxx. I can feel user frustration while trying to maintain 2.6 compatibility and wasting time trying to run test suite. I wouldn't mind if `-m unittest` won't work in non-supported versions, but it should at least point to bug report.

(if I'll ever switch to Ruby - this one will definitely be in the list reasons)

----------
components: Tests
messages: 133449
nosy: techtonik
priority: normal
severity: normal
status: open
title: 'unittest -m' should not pretend it works on Python 2.5/2.6
type: behavior
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11819>
_______________________________________

From report at bugs.python.org  Sun Apr 10 09:37:06 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 10 Apr 2011 07:37:06 +0000
Subject: [issue11819] 'unittest -m' should not pretend it works on Python
	2.5/2.6
In-Reply-To: <1302420931.81.0.0491321221951.issue11819@psf.upfronthosting.co.za>
Message-ID: <1302421026.41.0.0381431395689.issue11819@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11819>
_______________________________________

From report at bugs.python.org  Sun Apr 10 09:41:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Apr 2011 07:41:49 +0000
Subject: [issue11818] tempfile.TemporaryFile example in docs doesnt work
In-Reply-To: <1302419439.43.0.340740214318.issue11818@psf.upfronthosting.co.za>
Message-ID: <E1Q8pHH-0006yO-GW@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 87d89f767b23 by Ross Lagerwall in branch '3.2':
Issue #11818: Fix tempfile examples for Python 3.
http://hg.python.org/cpython/rev/87d89f767b23

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11818>
_______________________________________

From report at bugs.python.org  Sun Apr 10 09:43:38 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sun, 10 Apr 2011 07:43:38 +0000
Subject: [issue11818] tempfile.TemporaryFile example in docs doesnt work
In-Reply-To: <1302419439.43.0.340740214318.issue11818@psf.upfronthosting.co.za>
Message-ID: <1302421418.0.0.418277783509.issue11818@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Fixed the examples for Python 3.

It writes and reads bytes now. Also fixed the old Python 2 print statement.

----------
assignee: docs at python -> rosslagerwall
nosy: +rosslagerwall
resolution:  -> fixed
status: open -> closed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11818>
_______________________________________

From report at bugs.python.org  Sun Apr 10 09:45:41 2011
From: report at bugs.python.org (kent)
Date: Sun, 10 Apr 2011 07:45:41 +0000
Subject: [issue11820] idle3 shell os.system swallows shell command output
In-Reply-To: <1302421540.99.0.957938249964.issue11820@psf.upfronthosting.co.za>
Message-ID: <1302421540.99.0.957938249964.issue11820@psf.upfronthosting.co.za>


New submission from kent <fuzzballz at comcast.net>:

attempting to run an os.system command under the idle 3 shell swallows the out put.
Idle 3 is running on a 32 bit kde mandriva linux.

>>> import os
>>> os.system('ls')
0
>>> os.system('pwd')
0


as you can see it returns a 0 indicating successful completion, but no output. However os.getcwd works perfectly.

>>> os.getcwd()
'/home/kent/Documents' 

running the same code from python in an xwindow terminal works fine.

apparently the idle shell does not echo the the standard output or error output as the python interpreter does.

----------
components: IDLE
messages: 133452
nosy: Thekent
priority: normal
severity: normal
status: open
title: idle3 shell os.system swallows shell command output
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11820>
_______________________________________

From report at bugs.python.org  Sun Apr 10 10:02:33 2011
From: report at bugs.python.org (kent)
Date: Sun, 10 Apr 2011 08:02:33 +0000
Subject: [issue11820] idle3 shell os.system swallows shell command output
In-Reply-To: <1302421540.99.0.957938249964.issue11820@psf.upfronthosting.co.za>
Message-ID: <1302422553.07.0.18175932451.issue11820@psf.upfronthosting.co.za>


kent <fuzzballz at comcast.net> added the comment:

running it as a file from idle gives the same result.
import os
print (os.system('pwd'))

0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11820>
_______________________________________

From report at bugs.python.org  Sun Apr 10 10:52:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Apr 2011 08:52:51 +0000
Subject: [issue11810] _socket fails to build on OpenIndiana
In-Reply-To: <1302420786.98.0.833187011528.issue11810@psf.upfronthosting.co.za>
Message-ID: <1302425567.3494.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I know this is closed etc... but Plone (the CMS I use) is tied to
> various versions of Python, in particular 2.6 at this time.  Having it
> not build on Open[Solaris/Indiana] means I can't install current
> versions of Plone/Zope on this platform.  Any chance it could be
> fixed?

I would be surprised if Plone/Zope didn't work on 2.7 by the time.
Perhaps you want to ask their mailing-lists.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11810>
_______________________________________

From report at bugs.python.org  Sun Apr 10 11:14:01 2011
From: report at bugs.python.org (Carl Brewer)
Date: Sun, 10 Apr 2011 09:14:01 +0000
Subject: [issue11810] _socket fails to build on OpenIndiana
In-Reply-To: <1302382179.44.0.700403156795.issue11810@psf.upfronthosting.co.za>
Message-ID: <1302426841.66.0.571269434115.issue11810@psf.upfronthosting.co.za>


Carl Brewer <carl at bl.echidna.id.au> added the comment:

Plone ships with a "universal installer" which expects particular versions of python (and PIL etc etc) which makes it easy to build on, for example, many Linux distros, but it's just not working on Open[Solaris|Indiana] and also NetBSD (pkgsrc's python2.6 is broken too, but we're working on that).  The only time the installer gets bumped is when new versions of Plone get released, which means that only the bleeding edge might work.  This is a problem for many integrators who are tied to older versions of Plone|Zope that are unlikely to get migrated to more recent releases in any sort of a reasonable timeframe.

Is it really not possible to fix up python2.6 to solve this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11810>
_______________________________________

From report at bugs.python.org  Sun Apr 10 11:19:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Apr 2011 09:19:44 +0000
Subject: [issue11810] _socket fails to build on OpenIndiana
In-Reply-To: <1302382179.44.0.700403156795.issue11810@psf.upfronthosting.co.za>
Message-ID: <1302427184.78.0.923552354579.issue11810@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11810>
_______________________________________

From report at bugs.python.org  Sun Apr 10 11:20:55 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 10 Apr 2011 09:20:55 +0000
Subject: [issue11819] 'unittest -m' should not pretend it works on Python
	2.5/2.6
In-Reply-To: <1302420931.81.0.0491321221951.issue11819@psf.upfronthosting.co.za>
Message-ID: <1302427255.32.0.385192419223.issue11819@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Isn't this an exact duplicate of issue6514? Or do you suggest something else?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11819>
_______________________________________

From report at bugs.python.org  Sun Apr 10 11:24:29 2011
From: report at bugs.python.org (david)
Date: Sun, 10 Apr 2011 09:24:29 +0000
Subject: [issue11821] smtplib should provide a means to validate a remote
	server ssl certificate(s)
In-Reply-To: <1302427469.29.0.858818521824.issue11821@psf.upfronthosting.co.za>
Message-ID: <1302427469.29.0.858818521824.issue11821@psf.upfronthosting.co.za>


New submission from david <db.pub.mail at gmail.com>:

(This is similar to http://bugs.python.org/issue10274)
The smtplib module should provide a means to validate a remote server ssl certificate(s). 

It would be 'nice' if smtplib.SMTP_SSL & smtplib.starttls took in arguments to validate the remote SMTP's ssl certificate has been signed by a trusted certificate authority(and the common name matches what it should etc.).

----------
messages: 133457
nosy: db
priority: normal
severity: normal
status: open
title: smtplib should provide a means to validate a remote server ssl certificate(s)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11821>
_______________________________________

From report at bugs.python.org  Sun Apr 10 11:27:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Apr 2011 09:27:54 +0000
Subject: [issue8809] smtplib should support SSL contexts
In-Reply-To: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>
Message-ID: <1302427674.36.0.345931489014.issue8809@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
title: smptlib should support SSL contexts -> smtplib should support SSL contexts

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8809>
_______________________________________

From report at bugs.python.org  Sun Apr 10 11:28:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Apr 2011 09:28:20 +0000
Subject: [issue11821] smtplib should provide a means to validate a remote
	server ssl certificate(s)
In-Reply-To: <1302427469.29.0.858818521824.issue11821@psf.upfronthosting.co.za>
Message-ID: <1302427700.16.0.788900653925.issue11821@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Duplicate of issue11821.

----------
nosy: +pitrou
resolution:  -> duplicate
status: open -> closed
superseder:  -> smtplib should provide a means to validate a remote server ssl certificate(s)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11821>
_______________________________________

From report at bugs.python.org  Sun Apr 10 11:28:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Apr 2011 09:28:39 +0000
Subject: [issue11821] smtplib should provide a means to validate a remote
	server ssl certificate(s)
In-Reply-To: <1302427469.29.0.858818521824.issue11821@psf.upfronthosting.co.za>
Message-ID: <1302427719.9.0.00698137345098.issue11821@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Oops, I meant issue8809.

----------
superseder: smtplib should provide a means to validate a remote server ssl certificate(s) -> smtplib should support SSL contexts

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11821>
_______________________________________

From report at bugs.python.org  Sun Apr 10 11:30:46 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 10 Apr 2011 09:30:46 +0000
Subject: [issue6514] "python -m unittest <testmodule>" does not run any tests
In-Reply-To: <1247928686.78.0.475658449787.issue6514@psf.upfronthosting.co.za>
Message-ID: <1302427846.13.0.5583593309.issue6514@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/issue6514>
_______________________________________

From report at bugs.python.org  Sun Apr 10 11:35:22 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 10 Apr 2011 09:35:22 +0000
Subject: [issue11819] 'unittest -m' should not pretend it works on Python
	2.5/2.6
In-Reply-To: <1302420931.81.0.0491321221951.issue11819@psf.upfronthosting.co.za>
Message-ID: <1302428122.14.0.477339401729.issue11819@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, this is a duplicate.

----------
nosy: +georg.brandl
resolution:  -> duplicate
status: open -> closed
superseder:  -> "python -m unittest <testmodule>" does not run any tests

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11819>
_______________________________________

From report at bugs.python.org  Sun Apr 10 11:59:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Apr 2011 09:59:36 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <E1Q8rQd-0005mY-0k@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset dda33191f7f5 by Ezio Melotti in branch 'default':
#2650: re.escape() no longer escapes the "_".
http://hg.python.org/cpython/rev/dda33191f7f5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
_______________________________________

From report at bugs.python.org  Sun Apr 10 12:00:23 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 10 Apr 2011 10:00:23 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1302429623.74.0.161176295698.issue2650@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
_______________________________________

From report at bugs.python.org  Sun Apr 10 12:22:23 2011
From: report at bugs.python.org (david)
Date: Sun, 10 Apr 2011 10:22:23 +0000
Subject: [issue8809] smtplib should support SSL contexts
In-Reply-To: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>
Message-ID: <1302430943.1.0.763410567138.issue8809@psf.upfronthosting.co.za>


Changes by david <db.pub.mail at gmail.com>:


----------
nosy: +db

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8809>
_______________________________________

From report at bugs.python.org  Sun Apr 10 14:41:09 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sun, 10 Apr 2011 12:41:09 +0000
Subject: [issue8428] buildbot: test_multiprocessing timeout (test_notify_all?
	test_pool_worker_lifetime?)
In-Reply-To: <1271451412.83.0.723333785051.issue8428@psf.upfronthosting.co.za>
Message-ID: <1302439269.07.0.64097738993.issue8428@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

I think those lockups are due to a race in the Pool shutdown code.
In Lib/multiprocessing/pool.py:

    def close(self):
        debug('closing pool')
        if self._state == RUN:
            self._state = CLOSE
            self._worker_handler._state = CLOSE
            self._taskqueue.put(None) 

We set the current state to CLOSE, and send None to the taskqueue, so that task_handler detects that we want to shut down the queue and sends None (sentinel) to the inqueue for each worker process.
When a worker process receives this sentinel, it exists, and when Pool's join method is called, each process is joined successfully.
Now, there's a problem, because of the worker_hanler thread.
This thread constantly starts new threads if existing one exited after having completed their work:

    def _handle_workers(pool):
        while pool._worker_handler._state == RUN and pool._state == RUN:
            pool._maintain_pool()
            time.sleep(0.1)
        debug('worker handler exiting')

where 

    def _maintain_pool(self):
        """Clean up any exited workers and start replacements for them.
        """
        if self._join_exited_workers():
            self._repopulate_pool()

Imagine the following happens:

worker_handler checks that the pool is still running (state == RUN), but before calling maintain_pool, it's preempted (releasal of the GIL), and Pool's close() methode is called :
state is set to CLOSE, None is put to taskqueue, and worker threads exit.
Then, Pool's join is called:

    def join(self):
        debug('joining pool')
        assert self._state in (CLOSE, TERMINATE)
        self._worker_handler.join()
        self._task_handler.join()
        self._result_handler.join()
        for p in self._pool:
            p.join()


this blocks until worker_handler exits. This thread sooner or later resumes and calls maintain_pool.
maintain_pool calls repopulate_pool, which recreates new worker threads/processes.
Then, worker_handler checks the current state, sees CLOSE, and exists.
Then, Pool's join blocks  there:
        for p in self._pool:
            p.join()

since the newly created processes never receive the sentinels (already consumed by the previous worker processes)...

This race can be reproduced almost every time by just adding:


    def _handle_workers(pool):
        while pool._worker_handler._state == RUN and pool._state == RUN:
+            time.sleep(1)
            pool._maintain_pool()
            time.sleep(0.1)
        debug('worker handler exiting')

Then something as simple as this will block:

p = multiprocessing.Pool(3)
p.close()
p.join()

I still have to think of a clean way to solve this.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8428>
_______________________________________

From report at bugs.python.org  Sun Apr 10 15:47:46 2011
From: report at bugs.python.org (Thomas Scrace)
Date: Sun, 10 Apr 2011 13:47:46 +0000
Subject: [issue8809] smtplib should support SSL contexts
In-Reply-To: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>
Message-ID: <1302443266.78.0.555486481977.issue8809@psf.upfronthosting.co.za>


Thomas Scrace <tom at scrace.org> added the comment:

Is anybody working on this issue? If not, I think it looks like it might be a nice one for me to tackle. I'll go ahead unless there are any objections.

----------
nosy: +thomas.scrace

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8809>
_______________________________________

From report at bugs.python.org  Sun Apr 10 15:55:09 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 10 Apr 2011 13:55:09 +0000
Subject: [issue11816] Add functions to return disassembly as string
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1302443709.83.0.92487481363.issue11816@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I really like the idea of adding some lower level infrastructure to dis to make it generator based, making the disassembly more amenable to programmatic manipulation.

Consider if, for each line disassemble() currently prints, we had an underlying iterator that yielded a named tuple consisting of (index, opcode, oparg, linestart, details). I've created a proof-of-concept for that in my sandbox (http://hg.python.org/sandbox/ncoghlan/file/get_opinfo/Lib/dis.py) which adds a get_opinfo() function that does exactly. With disassemble() rewritten to use that, test_dis and test_peepholer still pass as currently written.

Near-term, test_peepholer could easily continue to do what it does now (i.e. use the higher level dis() function and redirect sys.stdout). Longer term, it could be written to analyse the opcode stream instead of doing string comparisons.

----------
hgrepos: +17

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Sun Apr 10 15:57:21 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 10 Apr 2011 13:57:21 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1302443841.35.0.8040851201.issue11816@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Changed issue title to cover ideas like get_opinfo().

----------
title: Add functions to return disassembly as string -> Refactor the dis module to provide better building blocks for bytecode analysis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Sun Apr 10 15:58:48 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 10 Apr 2011 13:58:48 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1302443928.16.0.127089113996.issue11816@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Oops, I forgot to edit my comment to match the OpInfo definition I used in the proof-of-concept:

OpInfo = collections.namedtuple("OpInfo",
            "opindex opcode opname oparg details starts_line is_jump_target")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Sun Apr 10 16:05:20 2011
From: report at bugs.python.org (Eugene Toder)
Date: Sun, 10 Apr 2011 14:05:20 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1302444320.37.0.651463388825.issue11816@psf.upfronthosting.co.za>


Eugene Toder <eltoder at gmail.com> added the comment:

So in the near term, dis-based tests should continue to copy/paste sys.stdout redirection code?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Sun Apr 10 16:35:04 2011
From: report at bugs.python.org (Rodrigue Alcazar)
Date: Sun, 10 Apr 2011 14:35:04 +0000
Subject: [issue8094] Multiprocessing infinite loop
In-Reply-To: <1268125314.35.0.202558750367.issue8094@psf.upfronthosting.co.za>
Message-ID: <1302446104.98.0.420831086258.issue8094@psf.upfronthosting.co.za>


Rodrigue Alcazar <rodriguealcazar at gmail.com> added the comment:

I have tried to clearly state that the main module is imported by a newly created process. I have also added a comment explaining that an infinite loop like the one Benjamin describes could be created.

----------
keywords: +patch
nosy: +Rodrigue.Alcazar
Added file: http://bugs.python.org/file21603/multiprocessing.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8094>
_______________________________________

From report at bugs.python.org  Sun Apr 10 17:26:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 10 Apr 2011 15:26:53 +0000
Subject: [issue11817] berkeley db 5.1 support
In-Reply-To: <1302403928.0.0.111230204951.issue11817@psf.upfronthosting.co.za>
Message-ID: <1302449213.42.0.553008853588.issue11817@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Python 2.7 is closed for new features, I afraid.  And Berkeley DB is not included in the Python3 stdlib.  It has reverted to being maintained entirely as a third party package.

----------
nosy: +r.david.murray
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11817>
_______________________________________

From report at bugs.python.org  Sun Apr 10 17:33:49 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 10 Apr 2011 15:33:49 +0000
Subject: [issue11802] filecmp.cmp needs a documented way to clear cache
In-Reply-To: <1302233844.4.0.517722747064.issue11802@psf.upfronthosting.co.za>
Message-ID: <1302449629.78.0.86430611219.issue11802@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Georg? Benjamin? Do you think this fix should be backported?

----------
nosy: +benjamin.peterson, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11802>
_______________________________________

From report at bugs.python.org  Sun Apr 10 17:46:22 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 10 Apr 2011 15:46:22 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1302450382.36.0.496079271384.issue11816@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

If we decide our long term goal is the use of the opcode stream for programmatic access, then yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Sun Apr 10 18:19:52 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sun, 10 Apr 2011 16:19:52 +0000
Subject: [issue11807] Documentation of add_subparsers lacks information about
	parametres
In-Reply-To: <1302340872.99.0.0231583237732.issue11807@psf.upfronthosting.co.za>
Message-ID: <1302452392.57.0.0471306451998.issue11807@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Here is a patch for this. I am not much of technical writer, so please be patient with me. I tried to provide all the information about parameters, that can be inferred from the code and experimenting. I have left out one parameter - action - because I don't see any use of it for a potential user and potential description seemed very complicated. I'll be happy to work further on the patch, if someone is willing to tutor me a little.

----------
keywords: +patch
Added file: http://bugs.python.org/file21604/11807.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11807>
_______________________________________

From report at bugs.python.org  Sun Apr 10 18:48:12 2011
From: report at bugs.python.org (Darren Dale)
Date: Sun, 10 Apr 2011 16:48:12 +0000
Subject: [issue11610] Improving property to accept abstract methods
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1302454092.2.0.602267451913.issue11610@psf.upfronthosting.co.za>


Darren Dale <dsdale24 at gmail.com> added the comment:

So, are there objections to this patch, or can it be merged?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sun Apr 10 18:59:34 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 10 Apr 2011 16:59:34 +0000
Subject: [issue11772] email header wrapping edge case failure
In-Reply-To: <1302010393.33.0.35644236516.issue11772@psf.upfronthosting.co.za>
Message-ID: <1302454774.58.0.872777895732.issue11772@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> email.header.Header doesn't fold headers correctly

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11772>
_______________________________________

From report at bugs.python.org  Sun Apr 10 19:37:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Apr 2011 17:37:38 +0000
Subject: [issue8809] smtplib should support SSL contexts
In-Reply-To: <1302443266.78.0.555486481977.issue8809@psf.upfronthosting.co.za>
Message-ID: <1302457055.3581.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Is anybody working on this issue? If not, I think it looks like it
> might be a nice one for me to tackle. I'll go ahead unless there are
> any objections.

Nobody is working on it AFAIK. Feel free to give it a try :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8809>
_______________________________________

From report at bugs.python.org  Sun Apr 10 19:41:38 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sun, 10 Apr 2011 17:41:38 +0000
Subject: [issue11650] Faulty RESTART/EINTR handling in Parser/myreadline.c
In-Reply-To: <1302358681.57.0.769544160302.issue11650@psf.upfronthosting.co.za>
Message-ID: <20110410174120.GA53612@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

On Sat, Apr 09, 2011 at 02:18:01PM +0000, STINNER Victor wrote:
> I noticied a strange behaviour:

Still fun, but this one could even make it except for termios
flags, multibyte and the real problem, signal handling.
Hm.

----------
Added file: http://bugs.python.org/file21605/11650.termios-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11650>
_______________________________________
-------------- next part --------------
diff --git a/Parser/myreadline.c b/Parser/myreadline.c
--- a/Parser/myreadline.c
+++ b/Parser/myreadline.c
@@ -10,6 +10,10 @@
 */
 
 #include "Python.h"
+#ifdef Py_PYPORT_H
+# define __USE_TERMIOS
+# include "signal.h"
+#endif
 #ifdef MS_WINDOWS
 #define WIN32_LEAN_AND_MEAN
 #include "windows.h"
@@ -19,6 +23,18 @@
 extern char* vms__StdioReadline(FILE *sys_stdin, FILE *sys_stdout, char *prompt);
 #endif
 
+typedef struct Args {
+    char            *input;
+    FILE            *fp;
+    int             tios_fd;
+    int             tios_is_init;
+#ifdef __USE_TERMIOS
+    int             tios_is_set;
+    int             __align;
+    struct termios  tios_old;
+    struct termios  tios_new;
+#endif
+} Args;
 
 PyThreadState* _PyOS_ReadlineTState;
 
@@ -29,117 +45,230 @@
 
 int (*PyOS_InputHook)(void) = NULL;
 
-/* This function restarts a fgets() after an EINTR error occurred
-   except if PyOS_InterruptOccurred() returns true. */
+/* This function restarts a fgetc() after an EINTR error occurred
+ * except if PyOS_InterruptOccurred() returns true */
+static int  my_fgets(Args *args);
+#ifdef __USE_TERMIOS
+static void termios_resume(Args *args);
+static void termios_suspend(Args *args);
+#endif
+
+#ifdef __USE_TERMIOS
+static void
+termios_resume(Args *args)
+{
+    if (!args->tios_is_init) {
+        args->tios_is_init = 1;
+
+        while (tcgetattr(args->tios_fd, &args->tios_old) != 0)
+            if (errno != EINTR) {
+                args->tios_fd = -1;
+                goto jleave;
+            }
+
+        memcpy(&args->tios_new, &args->tios_old, sizeof(args->tios_old));
+        args->tios_new.c_lflag &= ~(/*ECHOCTL |*/ ICANON);
+        args->tios_new.c_cc[VMIN] = 1;
+    }
+
+    if (args->tios_fd < 0)
+        goto jleave;
+
+    while (tcsetattr(args->tios_fd, TCSAFLUSH, &args->tios_new) != 0)
+        ;
+    args->tios_is_set = 1;
+
+jleave:
+    return;
+}
+
+static void
+termios_suspend(Args *args)
+{
+    if (args->tios_is_init && args->tios_is_set) {
+        while (tcsetattr(args->tios_fd, TCSANOW, &args->tios_old) != 0)
+            ;
+        args->tios_is_set = 0;
+    }
+    return;
+}
+#endif
 
 static int
-my_fgets(char *buf, int len, FILE *fp)
+my_fgets(Args *args)
 {
-    char *p;
+    int estat;
+    char *buf, *cursor;
+    size_t buf_len;
+
+    buf = (char*)PyMem_MALLOC(2*80);
+    estat = 1;
+    if (buf == NULL)
+        goto jreturn;
+
+    cursor = buf;
+    buf_len = 2*80 - 2;
+jrestart_input:
+    estat = 0;
+
+    if (PyOS_InputHook != NULL)
+        (void)(PyOS_InputHook)();
+#ifdef __USE_TERMIOS
+    termios_resume(args);
+#endif
+
+    /* Fetch bytes until error or newline */
+    errno = 0;
     while (1) {
-        if (PyOS_InputHook != NULL)
-            (void)(PyOS_InputHook)();
-        errno = 0;
-        p = fgets(buf, len, fp);
-        if (p != NULL)
-            return 0; /* No error */
+        int c = fgetc(args->fp);
+#ifdef __USE_TERMIOS
+        if (!isprint(c))
+            switch (c) {
+            case '\x04':
+                c = EOF;
+                /* FALLTHROUGH */
+            default:
+                break;
+            case '\x03':
+                estat = SIGINT;
+                goto j_sigit;
+            case '\x1A':
+                estat = SIGTSTP;
+                goto j_sigit;
+            case '\x1C':
+                estat = SIGQUIT;
+                /* FALLTHROUGH */
+j_sigit:        termios_suspend(args);
+                kill(getpid(), estat);
+                errno = EINTR;
+                goto jcheck_fail;
+            }
+#endif
+        if (c == EOF)
+            goto jcheck_fail;
+        *(cursor++) = (char)c;
+        if (c == '\n')
+            break;
+
+        if ((size_t)(cursor-buf) >= buf_len) {
+            buf_len += 2+32;
+            cursor = buf = (char*)PyMem_REALLOC(buf, buf_len);
+            if (buf == NULL) {
+                estat = 1;
+                goto jreturn;
+            }
+            buf_len -= 2+32;
+            cursor += buf_len;
+            buf_len += 32;
+        }
+    }
+
+    *cursor = '\0';
+    args->input = buf;
+jreturn:
+#ifdef __USE_TERMIOS
+    termios_suspend(args);
+#endif
+    return estat;
+
+jcheck_fail:
 #ifdef MS_WINDOWS
-        /* In the case of a Ctrl+C or some other external event
-           interrupting the operation:
-           Win2k/NT: ERROR_OPERATION_ABORTED is the most recent Win32
-           error code (and feof() returns TRUE).
-           Win9x: Ctrl+C seems to have no effect on fgets() returning
-           early - the signal handler is called, but the fgets()
-           only returns "normally" (ie, when Enter hit or feof())
+    /* In the case of a Ctrl+C or some other external event
+       interrupting the operation:
+       Win2k/NT: ERROR_OPERATION_ABORTED is the most recent Win32
+       error code (and feof() returns TRUE).
+       Win9x: Ctrl+C seems to have no effect on fgets() returning
+       early - the signal handler is called, but the fgets()
+       only returns "normally" (ie, when Enter hit or feof())
+    */
+    if (GetLastError()==ERROR_OPERATION_ABORTED) {
+        /* Signals come asynchronously, so we sleep a brief
+           moment before checking if the handler has been
+           triggered (we cant just return 1 before the
+           signal handler has been called, as the later
+           signal may be treated as a separate interrupt).
         */
-        if (GetLastError()==ERROR_OPERATION_ABORTED) {
-            /* Signals come asynchronously, so we sleep a brief
-               moment before checking if the handler has been
-               triggered (we cant just return 1 before the
-               signal handler has been called, as the later
-               signal may be treated as a separate interrupt).
-            */
-            Sleep(1);
-            if (PyOS_InterruptOccurred()) {
-                return 1; /* Interrupt */
-            }
-            /* Either the sleep wasn't long enough (need a
-               short loop retrying?) or not interrupted at all
-               (in which case we should revisit the whole thing!)
-               Logging some warning would be nice.  assert is not
-               viable as under the debugger, the various dialogs
-               mean the condition is not true.
-            */
+        Sleep(1);
+        if (PyOS_InterruptOccurred()) {
+            estat = 1;
+            goto jfail;
         }
+        /* Either the sleep wasn't long enough (need a
+           short loop retrying?) or not interrupted at all
+           (in which case we should revisit the whole thing!)
+           Logging some warning would be nice.  assert is not
+           viable as under the debugger, the various dialogs
+           mean the condition is not true.
+        */
+    }
 #endif /* MS_WINDOWS */
-        if (feof(fp)) {
-            return -1; /* EOF */
+
+    if (feof(args->fp)) {
+        estat = -1; /* EOF */
+        goto jfail;
+    }
+#ifdef EINTR
+    if (errno == EINTR) {
+# ifdef WITH_THREAD
+        PyEval_RestoreThread(_PyOS_ReadlineTState);
+# endif
+        estat = PyErr_CheckSignals();
+# ifdef WITH_THREAD
+        PyEval_SaveThread();
+# endif
+        if (estat < 0) {
+            estat = 1;
+            goto jfail;
         }
-#ifdef EINTR
-        if (errno == EINTR) {
-            int s;
-#ifdef WITH_THREAD
-            PyEval_RestoreThread(_PyOS_ReadlineTState);
+        /* EINTR is restarted */
+        goto jrestart_input;
+    }
 #endif
-            s = PyErr_CheckSignals();
-#ifdef WITH_THREAD
-            PyEval_SaveThread();
-#endif
-            if (s < 0)
-                    return 1;
-	    /* try again */
-            continue;
-        }
-#endif
-        if (PyOS_InterruptOccurred()) {
-            return 1; /* Interrupt */
-        }
-        return -2; /* Error */
+
+    if (PyOS_InterruptOccurred()) {
+        estat = 1; /* Interrupt */
+        goto jfail;
     }
-    /* NOTREACHED */
+    estat = -2; /* Error */
+    /* FALLTHROUGH */
+
+jfail:
+    PyMem_Free(buf);
+    goto jreturn;
 }
 
-
-/* Readline implementation using fgets() */
-
+/* Readline implementation using my_fgets() */
 char *
 PyOS_StdioReadline(FILE *sys_stdin, FILE *sys_stdout, char *prompt)
 {
-    size_t n;
-    char *p;
-    n = 100;
-    if ((p = (char *)PyMem_MALLOC(n)) == NULL)
-        return NULL;
+    char *result;
+    auto Args args;
+
     fflush(sys_stdout);
     if (prompt)
         fprintf(stderr, "%s", prompt);
     fflush(stderr);
-    switch (my_fgets(p, (int)n, sys_stdin)) {
+
+    args.input = NULL;
+    args.fp = sys_stdin;
+    args.tios_fd = fileno(sys_stdin);
+    args.tios_is_init = 0;
+
+    switch (my_fgets(&args)) {
     case 0: /* Normal case */
+    case 1: /* Interrupt */
+        result = args.input;
         break;
-    case 1: /* Interrupt */
-        PyMem_FREE(p);
-        return NULL;
     case -1: /* EOF */
     case -2: /* Error */
     default: /* Shouldn't happen */
-        *p = '\0';
+        result = (char*)PyMem_MALLOC(sizeof(void*));
+        if (result != NULL)
+            *result = '\0';
         break;
     }
-    n = strlen(p);
-    while (n > 0 && p[n-1] != '\n') {
-        size_t incr = n+2;
-        p = (char *)PyMem_REALLOC(p, n + incr);
-        if (p == NULL)
-            return NULL;
-        if (incr > INT_MAX) {
-            PyErr_SetString(PyExc_OverflowError, "input line too long");
-        }
-        if (my_fgets(p+n, (int)incr, sys_stdin) != 0)
-            break;
-        n += strlen(p+n);
-    }
-    return (char *)PyMem_REALLOC(p, n+1);
+
+    return result;
 }
 
 

From report at bugs.python.org  Sun Apr 10 19:44:53 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sun, 10 Apr 2011 17:44:53 +0000
Subject: [issue11700] mailbox.py proxy updates
In-Reply-To: <20110409132704.GA52452@sherwood.local>
Message-ID: <20110410174439.GB53612@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

I reviewed this.
And moved a _PartialFile-only _read() case to _PartialFile where
it belongs (*this* _ProxyFile will never be extended to stand
alone so i shouldn't have moved that the other direction at all).

----------
Added file: http://bugs.python.org/file21606/11700.yeah-review.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11700>
_______________________________________
-------------- next part --------------
diff --git a/Lib/mailbox.py b/Lib/mailbox.py
--- a/Lib/mailbox.py
+++ b/Lib/mailbox.py
@@ -1864,97 +1864,142 @@
     """Message with MMDF-specific properties."""
 
 
-class _ProxyFile:
-    """A read-only wrapper of a file."""
+class _ProxyFile(io.BufferedIOBase):
+    """A io.BufferedIOBase inheriting read-only wrapper for a seekable file.
+    It supports __iter__() and the context-manager protocol.
+    """
+    def __init__(self, file, pos=None):
+        io.BufferedIOBase.__init__(self)
+        self._file = file
+        self._pos = file.tell() if pos is None else pos
+        self._close = True
+        self._is_open = True
 
-    def __init__(self, f, pos=None):
-        """Initialize a _ProxyFile."""
-        self._file = f
-        if pos is None:
-            self._pos = f.tell()
+    def _set_noclose(self):
+        """Subclass hook - use to avoid closing internal file object."""
+        self._close = False
+
+    def _closed_check(self):
+        """Raise ValueError if not open."""
+        if not self._is_open:
+            raise ValueError('I/O operation on closed file')
+
+    def close(self):
+        if self._close:
+            self._close = False
+            self._file.close()
+            del self._file
+        self._is_open = False
+
+    @property
+    def closed(self):
+        return not self._is_open
+
+    def flush(self):
+        # Not possible because it gets falsely called (issue 11700)
+        #raise io.UnsupportedOperation('flush')
+        pass
+
+    def _read(self, size, read_method, readinto_arg=None):
+        if size is None or size < 0:
+            size = -1
+        self._file.seek(self._pos)
+        if not readinto_arg:
+            result = read_method(size)
         else:
-            self._pos = pos
+            result = read_method(readinto_arg)
+            if result < len(readinto_arg):
+                del readinto_arg[result:]
+        self._pos = self._file.tell()
+        return result
 
-    def read(self, size=None):
-        """Read bytes."""
+    def readable(self):
+        self._closed_check()
+        return True
+
+    def read(self, size=-1):
+        self._closed_check()
+        if size is None or size < 0:
+            return self.readall()
         return self._read(size, self._file.read)
 
-    def read1(self, size=None):
-        """Read bytes."""
+    def read1(self, size=-1):
+        self._closed_check()
+        if size is None or size < 0:
+            return b''
         return self._read(size, self._file.read1)
 
-    def readline(self, size=None):
-        """Read a line."""
+    def readinto(self, by_arr):
+        self._closed_check()
+        return self._read(len(by_arr), self._file.readinto, by_arr)
+
+    def readall(self):
+        self._closed_check()
+        self._file.seek(self._pos)
+        if hasattr(self._file, 'readall'):
+            result = self._file.readall()
+        else:
+            dl = []
+            while 1:
+                i = self._file.read(8192)
+                if len(i) == 0:
+                    break
+                dl.append(i)
+            result = b''.join(dl)
+        self._pos = self._file.tell()
+        return result
+
+    def readline(self, size=-1):
+        self._closed_check()
         return self._read(size, self._file.readline)
 
-    def readlines(self, sizehint=None):
-        """Read multiple lines."""
+    def readlines(self, sizehint=-1):
         result = []
         for line in self:
             result.append(line)
-            if sizehint is not None:
+            if sizehint >= 0:
                 sizehint -= len(line)
                 if sizehint <= 0:
                     break
         return result
 
+    def seekable(self):
+        self._closed_check()
+        return True
+
+    def seek(self, offset, whence=0):
+        self._closed_check()
+        if whence == 1:
+            self._file.seek(self._pos)
+        self._pos = self._file.seek(offset, whence)
+        return self._pos
+
+    def tell(self):
+        self._closed_check()
+        return self._pos
+
+    def writable(self):
+        self._closed_check()
+        return False
+
+    def writelines(self, lines):
+        raise io.UnsupportedOperation('writelines')
+
+    def write(self, b):
+        raise io.UnsupportedOperation('write')
+
     def __iter__(self):
-        """Iterate over lines."""
         while True:
             line = self.readline()
             if not line:
                 raise StopIteration
             yield line
 
-    def tell(self):
-        """Return the position."""
-        return self._pos
-
-    def seek(self, offset, whence=0):
-        """Change position."""
-        if whence == 1:
-            self._file.seek(self._pos)
-        self._file.seek(offset, whence)
-        self._pos = self._file.tell()
-
-    def close(self):
-        """Close the file."""
-        if hasattr(self._file, 'close'):
-            self._file.close()
-        del self._file
-
-    def _read(self, size, read_method):
-        """Read size bytes using read_method."""
-        if size is None:
-            size = -1
-        self._file.seek(self._pos)
-        result = read_method(size)
-        self._pos = self._file.tell()
-        return result
-
     def __enter__(self):
-        """Context manager protocol support."""
         return self
-
     def __exit__(self, *exc):
         self.close()
 
-    def readable(self):
-        return self._file.readable()
-
-    def writable(self):
-        return self._file.writable()
-
-    def seekable(self):
-        return self._file.seekable()
-
-    def flush(self):
-        return self._file.flush()
-
-    @property
-    def closed(self):
-        return self._file.closed
-
 
 class _PartialFile(_ProxyFile):
     """A read-only wrapper of part of a file."""
@@ -1962,6 +2007,7 @@
     def __init__(self, f, start=None, stop=None):
         """Initialize a _PartialFile."""
         _ProxyFile.__init__(self, f, start)
+        super()._set_noclose()
         self._start = start
         self._stop = stop
 
@@ -1971,6 +2017,7 @@
 
     def seek(self, offset, whence=0):
         """Change position, possibly with respect to start or stop."""
+        self._closed_check()
         if whence == 0:
             self._pos = self._start
             whence = 1
@@ -1979,20 +2026,23 @@
             whence = 1
         _ProxyFile.seek(self, offset, whence)
 
-    def _read(self, size, read_method):
+    def _read(self, size, read_method, readinto_arg=None):
         """Read size bytes using read_method, honoring start and stop."""
         remaining = self._stop - self._pos
         if remaining <= 0:
             return b''
         if size is None or size < 0 or size > remaining:
             size = remaining
-        return _ProxyFile._read(self, size, read_method)
+        if not not readinto_arg and size < len(readinto_arg):
+            del readinto_arg[size:]
+        return _ProxyFile._read(self, size, read_method, readinto_arg)
 
-    def close(self):
-        # do *not* close the underlying file object for partial files,
-        # since it's global to the mailbox object
-        del self._file
-
+    def readall(self):
+        self._closed_check()
+        remaining = self._stop - self._pos
+        if remaining <= 0:
+            return b''
+        return _ProxyFile._read(self, remaining, self._file.read)
 
 def _lock_file(f, dotlock=True):
     """Lock file f using lockf and dot locking."""
diff --git a/Lib/test/test_mailbox.py b/Lib/test/test_mailbox.py
--- a/Lib/test/test_mailbox.py
+++ b/Lib/test/test_mailbox.py
@@ -290,12 +290,17 @@
         key1 = self._box.add(_sample_message)
         with self._box.get_file(key0) as file:
             data0 = file.read()
-        with self._box.get_file(key1) as file:
-            data1 = file.read()
+        file1 = self._box.get_file(key1)
+        data1 = file1.read()
         self.assertEqual(data0.decode('ascii').replace(os.linesep, '\n'),
                          self._template % 0)
         self.assertEqual(data1.decode('ascii').replace(os.linesep, '\n'),
                          _sample_message)
+        file1.close()
+        try:
+            file1.close()
+        except:
+            self.fail('.close() doesn\'t handle multiple invocations')
 
     def test_iterkeys(self):
         # Get keys using iterkeys()
@@ -1774,6 +1779,68 @@
         proxy.seek(2)
         self.assertEqual(proxy.read(1000), b'r')
 
+    def _test_read1(self, proxy):
+        # Read by byte
+        proxy.seek(0)
+        self.assertEqual(proxy.read1(3), b'bar')
+        proxy.seek(1)
+        self.assertEqual(proxy.read1(2), b'ar')
+        proxy.seek(0)
+        self.assertEqual(proxy.read1(2), b'ba')
+        proxy.seek(1)
+        self.assertEqual(proxy.read1(-1), b'')
+        self.assertEqual(proxy.read1(None), b'')
+        self.assertEqual(proxy.read1(1000), b'ar')
+
+    def _test_readinto(self, proxy):
+        # Fill in bytearray
+        proxy.seek(0)
+        ba = bytearray(3)
+        self.assertEqual(proxy.readinto(ba), 3)
+        self.assertEqual(ba, b'bar')
+
+        proxy.seek(1)
+        ba = bytearray(2)
+        self.assertEqual(proxy.readinto(ba), 2)
+        self.assertEqual(ba, b'ar')
+
+        proxy.seek(0)
+        ba = bytearray(2)
+        self.assertEqual(proxy.readinto(ba), 2)
+        self.assertEqual(ba, b'ba')
+
+        proxy.seek(0)
+        ba = bytearray(2)
+        self.assertEqual(proxy.readinto(ba), 2)
+        self.assertEqual(ba, b'ba')
+
+        proxy.seek(1)
+        ba = bytearray(1000)
+        self.assertEqual(proxy.readinto(ba), 2)
+        self.assertEqual(ba, b'ar')
+
+        proxy.seek(2)
+        ba = bytearray(1000)
+        self.assertEqual(proxy.readinto(ba), 1)
+        self.assertEqual(ba, b'r')
+
+    def _test_readall(self, proxy):
+        # Read all the data
+        ls = os.linesep.encode()
+        lsl = len(ls)
+
+        proxy.seek(0)
+        x = b'fiesta' + ls + b'mexicana' + ls
+        self.assertEqual(proxy.readall(), x)
+
+        proxy.seek(6 + lsl)
+        x = b'mexicana' + ls
+        self.assertEqual(proxy.readall(), x)
+
+        proxy.seek(6+3 + lsl)
+        x = b'icana' + ls
+        self.assertEqual(proxy.readall(), x)
+
     def _test_readline(self, proxy):
         # Read by line
         linesep = os.linesep.encode()
@@ -1833,10 +1900,38 @@
         self.assertFalse(proxy.read())
 
     def _test_close(self, proxy):
-        # Close a file
+        self.assertFalse(proxy.closed)
+        # Not possible (see issue 11700 thread)
+        #self.assertRaises(io.UnsupportedOperation, proxy.flush)
+        self.assertTrue(proxy.readable())
+        self.assertTrue(proxy.seekable())
+        self.assertRaises(io.UnsupportedOperation, proxy.truncate, 0)
+        self.assertFalse(proxy.writable())
+        self.assertRaises(io.UnsupportedOperation, proxy.writelines, ['AU'])
+        self.assertRaises(io.UnsupportedOperation, proxy.write, 'AU')
+
         proxy.close()
-        self.assertRaises(AttributeError, lambda: proxy.close())
+        self.assertTrue(proxy.closed)
+        try:
+            proxy.close()
+        except:
+            self.fail('Proxy.close() failure')
 
+        # Not possible (see issue 11700 thread)
+        #self.assertRaises(io.UnsupportedOperation, proxy.flush)
+        self.assertRaises(ValueError, proxy.readable)
+        self.assertRaises(ValueError, proxy.read)
+        self.assertRaises(ValueError, proxy.readinto, bytearray())
+        self.assertRaises(ValueError, proxy.readall)
+        self.assertRaises(ValueError, proxy.readline)
+        self.assertRaises(ValueError, proxy.readlines)
+        self.assertRaises(ValueError, proxy.seekable)
+        self.assertRaises(ValueError, proxy.seek, 0)
+        self.assertRaises(ValueError, proxy.tell)
+        self.assertRaises(io.UnsupportedOperation, proxy.truncate, 0)
+        self.assertRaises(ValueError, proxy.writable)
+        self.assertRaises(io.UnsupportedOperation, proxy.writelines, ['AU'])
+        self.assertRaises(io.UnsupportedOperation, proxy.write, 'AU')
 
 class TestProxyFile(TestProxyFileBase):
 
@@ -1863,6 +1958,19 @@
         self._file.write(b'bar')
         self._test_read(mailbox._ProxyFile(self._file))
 
+    def test_read1(self):
+        self._file.write(b'bar')
+        self._test_read1(mailbox._ProxyFile(self._file))
+
+    def test_readinto(self):
+        self._file.write(b'bar')
+        self._test_readinto(mailbox._ProxyFile(self._file))
+
+    def test_readall(self):
+        ls = os.linesep.encode()
+        self._file.write(b'fiesta' + ls + b'mexicana' + ls)
+        self._test_readall(mailbox._ProxyFile(self._file))
+
     def test_readline(self):
         self._file.write(bytes('foo%sbar%sfred%sbob' % (os.linesep, os.linesep,
                                                   os.linesep), 'ascii'))
@@ -1886,6 +1994,13 @@
         self._file.write(bytes('foo%sbar%s' % (os.linesep, os.linesep), 'ascii'))
         self._test_close(mailbox._ProxyFile(self._file))
 
+    def test_ctxman(self):
+        self._file.write(b'foo')
+        proxy = mailbox._ProxyFile(self._file)
+        with proxy as p:
+            pass
+        self.assertTrue(proxy.closed)
+
 
 class TestPartialFile(TestProxyFileBase):
 
@@ -1909,6 +2024,20 @@
         self._file.write(bytes('***bar***', 'ascii'))
         self._test_read(mailbox._PartialFile(self._file, 3, 6))
 
+    def test_read1(self):
+        self._file.write(bytes('***bar***', 'ascii'))
+        self._test_read1(mailbox._PartialFile(self._file, 3, 6))
+
+    def test_readinto(self):
+        self._file.write(b'***bar***')
+        self._test_readinto(mailbox._PartialFile(self._file, 3, 6))
+
+    def test_readall(self):
+        ls = os.linesep.encode()
+        lsl = len(ls)
+        self._file.write(b'***fiesta' + ls + b'mexicana' + ls + b'***')
+        self._test_readall(mailbox._PartialFile(self._file, 3, 3+14+2*lsl))
+
     def test_readline(self):
         self._file.write(bytes('!!!!!foo%sbar%sfred%sbob!!!!!' %
                          (os.linesep, os.linesep, os.linesep), 'ascii'))
@@ -1937,6 +2066,14 @@
         self._test_close(mailbox._PartialFile(self._file, 1,
                                               6 + 3 * len(os.linesep)))
 
+    def test_ctxman(self):
+        self._file.write(bytes('foo' + os.linesep + 'bar', 'ascii'))
+        pos = self._file.tell()
+        proxy = mailbox._PartialFile(self._file, 2, 5)
+        with proxy as p:
+            pass
+        self.assertTrue(proxy.closed)
+
 
 ## Start: tests from the original module (for backward compatibility).
 

From report at bugs.python.org  Sun Apr 10 22:12:33 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 10 Apr 2011 20:12:33 +0000
Subject: [issue11492] email.header.Header doesn't fold headers correctly
In-Reply-To: <1300087978.39.0.703069545984.issue11492@psf.upfronthosting.co.za>
Message-ID: <1302466353.71.0.726298472772.issue11492@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This was quite the adventure.  The more I worked on fixing the tests, the more if/else cases the existing splitting algorithm grew.  When I reached the point where fixing one test broke two others, I thought maybe it was time to try a different approach.

Based on the knowledge gathered by banging my head on the old algorithm, I developed a new one.  This one is more RFC2822/RFC5322 compliant, I believe.  It breaks only at FWS, but still gives preference to breaking after commas or semicolons by default.

I had to adjust several tests that tested broken behavior: the "folded" lines were longer than maxlen even though there were suitable fold points.

I'm very happy with this patch because there are 70 fewer lines of code but the module passes more tests.

Even though the code changes are extensive, I plan to apply this to 3.2.  It fixes bugs, and the new code is at least somewhat easier to understand than the old code (if only because there is less of it!)  I don't plan to apply it to 3.1 because one older test fails if the patch is applied and I don't understand why (it appears to have nothing to do with line wrapping, and the same test works fine in 3.2).

----------
stage: needs patch -> patch review
versions:  -Python 3.1
Added file: http://bugs.python.org/file21607/better_header_spliter.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11492>
_______________________________________

From report at bugs.python.org  Sun Apr 10 22:25:52 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Apr 2011 20:25:52 +0000
Subject: [issue11822] Improve disassembly to show embedded code objects
In-Reply-To: <1302467152.39.0.854888976189.issue11822@psf.upfronthosting.co.za>
Message-ID: <1302467152.39.0.854888976189.issue11822@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Now that list comprehensions mask run their internals in code objects (the same way that genexps do), it is getting harder to use dis() to see what code is generated.  For example, the pow() call isn't shown in the following disassembly:

>>> dis('[x**2 for x in range(3)]')
  1           0 LOAD_CONST               0 (<code object <listcomp> at 0x1005d1e88, file "<dis>", line 1>) 
              3 MAKE_FUNCTION            0 
              6 LOAD_NAME                0 (range) 
              9 LOAD_CONST               1 (3) 
             12 CALL_FUNCTION            1 
             15 GET_ITER             
             16 CALL_FUNCTION            1 
             19 RETURN_VALUE    

I propose that dis() build-up a queue undisplayed code objects and then disassemble each of those after the main disassembly is done (effectively making it recursive and displaying code objects in the order that they are first seen in the disassembly).  For example, the output shown above would be followed by a disassembly of its internal code object:

<code object <listcomp> at 0x1005d1e88, file "<dis>", line 1>:
  1           0 BUILD_LIST               0 
              3 LOAD_FAST                0 (.0) 
        >>    6 FOR_ITER                16 (to 25) 
              9 STORE_FAST               1 (x) 
             12 LOAD_FAST                1 (x) 
             15 LOAD_CONST               0 (2) 
             18 BINARY_POWER         
             19 LIST_APPEND              2 
             22 JUMP_ABSOLUTE            6 
        >>   25 RETURN_VALUE

----------
components: Library (Lib)
messages: 133478
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Improve disassembly to show embedded code objects
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11822>
_______________________________________

From report at bugs.python.org  Sun Apr 10 22:28:30 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Sun, 10 Apr 2011 20:28:30 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1302467310.82.0.457213252153.issue11816@psf.upfronthosting.co.za>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

FWIW in PyPy we have https://bitbucket.org/pypy/pypy/src/default/lib_pypy/disassembler.py which we use for some of our tools.

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Sun Apr 10 22:30:55 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 10 Apr 2011 20:30:55 +0000
Subject: [issue11492] email.header.Header doesn't fold headers correctly
In-Reply-To: <1300087978.39.0.703069545984.issue11492@psf.upfronthosting.co.za>
Message-ID: <1302467455.3.0.657684922875.issue11492@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Note that this fix solves issue 11772, so I've closed that one as a duplicate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11492>
_______________________________________

From report at bugs.python.org  Sun Apr 10 22:33:45 2011
From: report at bugs.python.org (pyloz)
Date: Sun, 10 Apr 2011 20:33:45 +0000
Subject: [issue1602] windows console doesn't print or input Unicode
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1302467625.09.0.907801090566.issue1602@psf.upfronthosting.co.za>


Changes by pyloz <MerlinSchindlbeck at googlemail.com>:


----------
nosy: +smerlin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Sun Apr 10 23:11:40 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Apr 2011 21:11:40 +0000
Subject: [issue11823] disassembly needs to argument counts on calls with
	keyword args
In-Reply-To: <1302469900.48.0.983863495872.issue11823@psf.upfronthosting.co.za>
Message-ID: <1302469900.48.0.983863495872.issue11823@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

The argument to CALL_FUNCTION is overloaded to show both the number of positional arguments and keyword arguments (shifted by 8-bits):

>>> dis("foo(10, opt=True)")
  1           0 LOAD_NAME                0 (foo) 
              3 LOAD_CONST               0 (10) 
              6 LOAD_CONST               1 ('opt') 
              9 LOAD_CONST               2 (True) 
             12 CALL_FUNCTION          257 
             15 RETURN_VALUE         

It is not obvious that the 257 argument causes three stack arguments to be popped.

The disassembly should add a parenthetical to explain the composition:

>>> dis("foo(10, opt=True)")
  1           0 LOAD_NAME                0 (foo) 
              3 LOAD_CONST               0 (10) 
              6 LOAD_CONST               1 ('opt') 
              9 LOAD_CONST               2 (True) 
             12 CALL_FUNCTION          257 (1 positional, 1 keyword pair)
             15 RETURN_VALUE

----------
components: Library (Lib)
messages: 133481
nosy: rhettinger
priority: normal
severity: normal
status: open
title: disassembly needs to argument counts on calls with keyword args
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11823>
_______________________________________

From report at bugs.python.org  Sun Apr 10 23:17:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Apr 2011 21:17:51 +0000
Subject: [issue11823] disassembly needs to argument counts on calls with
	keyword args
In-Reply-To: <1302469900.48.0.983863495872.issue11823@psf.upfronthosting.co.za>
Message-ID: <1302470271.77.0.917317632829.issue11823@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
keywords: +easy
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11823>
_______________________________________

From report at bugs.python.org  Sun Apr 10 23:27:00 2011
From: report at bugs.python.org (=?utf-8?q?Greg_S=C5=82odkowicz?=)
Date: Sun, 10 Apr 2011 21:27:00 +0000
Subject: [issue9325] Add an option to pdb/trace/profile to run library module
	as a script
In-Reply-To: <1279743902.96.0.66207849175.issue9325@psf.upfronthosting.co.za>
Message-ID: <1302470820.25.0.448483964544.issue9325@psf.upfronthosting.co.za>


Greg S?odkowicz <jergosh at gmail.com> added the comment:

Following Nick's advice, I extended runpy.run_module to accept an extra parameter to be used as replacement __main__ namespace.

Having this, I can make this temporary __main__ accessible in main() in modules like trace/profile/pdb even if module execution fails with an exception. The problem is that it's visible only in the calling function but not in the global namespace. One way to make it accessible for post mortem debugging would be to create the replacement __main__ module in the global namespace and then pass as a parameter to main(), but this seems clumsy.

So maybe the way to go is to have runpy store last used __main__, sys.exc_info() style. In this case, would this be the correct way to store it in runpy:

try:
    import threading
except ImportError:
    temp_main = None
else:
    local_storage = threading.local()
    local_storage.temp_main = None
    temp_main = local_storage.temp_main

?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9325>
_______________________________________

From report at bugs.python.org  Sun Apr 10 23:35:43 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 10 Apr 2011 21:35:43 +0000
Subject: [issue11823] disassembly needs to argument counts on calls with
	keyword args
In-Reply-To: <1302469900.48.0.983863495872.issue11823@psf.upfronthosting.co.za>
Message-ID: <1302471343.38.0.743149619682.issue11823@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11823>
_______________________________________

From report at bugs.python.org  Mon Apr 11 00:00:41 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sun, 10 Apr 2011 22:00:41 +0000
Subject: [issue8428] buildbot: test_multiprocessing timeout (test_notify_all?
	test_pool_worker_lifetime?)
In-Reply-To: <1302439269.07.0.64097738993.issue8428@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=xBBWkNRjHo92n5A=ORuA8CMWXJg@mail.gmail.com>


Charles-Francois Natali <neologix at free.fr> added the comment:

Attached is a patch fixing this race, and a similar one in Pool's terminate.

----------
keywords: +patch
Added file: http://bugs.python.org/file21608/pool_shutdown_race.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8428>
_______________________________________
-------------- next part --------------
diff -r bbfc65d05588 Lib/multiprocessing/pool.py
--- a/Lib/multiprocessing/pool.py	Thu Apr 07 10:48:29 2011 -0400
+++ b/Lib/multiprocessing/pool.py	Sun Apr 10 23:52:22 2011 +0200
@@ -322,6 +322,8 @@
         while pool._worker_handler._state == RUN and pool._state == RUN:
             pool._maintain_pool()
             time.sleep(0.1)
+        # send sentinel to stop workers
+        pool._taskqueue.put(None)
         debug('worker handler exiting')
 
     @staticmethod
@@ -440,7 +442,6 @@
         if self._state == RUN:
             self._state = CLOSE
             self._worker_handler._state = CLOSE
-            self._taskqueue.put(None)
 
     def terminate(self):
         debug('terminating pool')
@@ -474,7 +475,6 @@
 
         worker_handler._state = TERMINATE
         task_handler._state = TERMINATE
-        taskqueue.put(None)                 # sentinel
 
         debug('helping task handler/workers to finish')
         cls._help_stuff_finish(inqueue, task_handler, len(pool))
@@ -484,6 +484,11 @@
         result_handler._state = TERMINATE
         outqueue.put(None)                  # sentinel
 
+        # we must wait for the worker handler to exit before terminating
+        # workers because we don't want workers to be restarted behind our back 
+        debug('joining worker handler')
+        worker_handler.join()
+
         # Terminate workers which haven't already finished.
         if pool and hasattr(pool[0], 'terminate'):
             debug('terminating workers')

From report at bugs.python.org  Mon Apr 11 00:03:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Apr 2011 22:03:20 +0000
Subject: [issue8428] buildbot: test_multiprocessing timeout (test_notify_all?
	test_pool_worker_lifetime?)
In-Reply-To: <1271451412.83.0.723333785051.issue8428@psf.upfronthosting.co.za>
Message-ID: <1302473000.42.0.0669534251784.issue8428@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Nice! See also issue11814.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8428>
_______________________________________

From report at bugs.python.org  Mon Apr 11 00:23:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Apr 2011 22:23:31 +0000
Subject: [issue8428] buildbot: test_multiprocessing timeout (test_notify_all?
	test_pool_worker_lifetime?)
In-Reply-To: <1271451412.83.0.723333785051.issue8428@psf.upfronthosting.co.za>
Message-ID: <E1Q932X-00048H-Ib@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d5e43afeede6 by Antoine Pitrou in branch '3.2':
Issue #8428: Fix a race condition in multiprocessing.Pool when terminating
http://hg.python.org/cpython/rev/d5e43afeede6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8428>
_______________________________________

From report at bugs.python.org  Mon Apr 11 00:23:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Apr 2011 22:23:31 +0000
Subject: [issue11814] possible typo in multiprocessing.Pool._terminate
In-Reply-To: <1302390440.77.0.392480963039.issue11814@psf.upfronthosting.co.za>
Message-ID: <E1Q932X-00048H-IU@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c046b7e1087b by Antoine Pitrou in branch '3.2':
Issue #11814: Fix likely typo in multiprocessing.Pool._terminate().
http://hg.python.org/cpython/rev/c046b7e1087b

New changeset 76a3fc180ce0 by Antoine Pitrou in branch 'default':
Merge from 3.2 (issue #11814, issue #8428)
http://hg.python.org/cpython/rev/76a3fc180ce0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11814>
_______________________________________

From report at bugs.python.org  Mon Apr 11 00:28:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Apr 2011 22:28:28 +0000
Subject: [issue8428] buildbot: test_multiprocessing timeout (test_notify_all?
	test_pool_worker_lifetime?)
In-Reply-To: <1271451412.83.0.723333785051.issue8428@psf.upfronthosting.co.za>
Message-ID: <E1Q937I-0004Qw-Nx@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset dfc61dc14f59 by Antoine Pitrou in branch '2.7':
Issue #8428: Fix a race condition in multiprocessing.Pool when terminating
http://hg.python.org/cpython/rev/dfc61dc14f59

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8428>
_______________________________________

From report at bugs.python.org  Mon Apr 11 00:30:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Apr 2011 22:30:29 +0000
Subject: [issue8428] buildbot: test_multiprocessing timeout (test_notify_all?
	test_pool_worker_lifetime?)
In-Reply-To: <1271451412.83.0.723333785051.issue8428@psf.upfronthosting.co.za>
Message-ID: <1302474629.49.0.386220358783.issue8428@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Should be fixed now, thank you Charles-Fran?ois.
As for the TestCondition failure, there's a separate issue11790 open.
(Victor, please don't file many bugs in a single issue!)

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8428>
_______________________________________

From report at bugs.python.org  Mon Apr 11 00:31:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Apr 2011 22:31:26 +0000
Subject: [issue11814] possible typo in multiprocessing.Pool._terminate
In-Reply-To: <1302390440.77.0.392480963039.issue11814@psf.upfronthosting.co.za>
Message-ID: <1302474686.34.0.296887927447.issue11814@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed. The _terminate() issue has been fixed separately in issue8428.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11814>
_______________________________________

From report at bugs.python.org  Mon Apr 11 01:40:37 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Apr 2011 23:40:37 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1302478837.36.0.990279099317.issue11816@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Mon Apr 11 02:24:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Apr 2011 00:24:47 +0000
Subject: [issue11747] unified_diff function product incorrect range information
In-Reply-To: <1301806636.68.0.728514553962.issue11747@psf.upfronthosting.co.za>
Message-ID: <E1Q94vp-0002Oh-M7@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 36648097fcd4 by Raymond Hettinger in branch '3.2':
Cleanup and modernize code prior to working on Issue 11747.
http://hg.python.org/cpython/rev/36648097fcd4

New changeset 58a3bfcc70f7 by Raymond Hettinger in branch 'default':
Cleanup and modernize code prior to working on Issue 11747.
http://hg.python.org/cpython/rev/58a3bfcc70f7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11747>
_______________________________________

From report at bugs.python.org  Mon Apr 11 02:45:57 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Apr 2011 00:45:57 +0000
Subject: [issue4877] xml.parsers.expat ParseFile() causes segmentation fault
	when passed a closed file object
In-Reply-To: <1231390876.07.0.554090447949.issue4877@psf.upfronthosting.co.za>
Message-ID: <E1Q95GN-0003kG-LX@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 28705a7987c5 by Ezio Melotti in branch '2.7':
#4877: Fix a segfault in xml.parsers.expat while attempting to parse a closed file.
http://hg.python.org/cpython/rev/28705a7987c5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4877>
_______________________________________

From report at bugs.python.org  Mon Apr 11 02:56:58 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 11 Apr 2011 00:56:58 +0000
Subject: [issue4877] xml.parsers.expat ParseFile() causes segmentation fault
	when passed a closed file object
In-Reply-To: <1231390876.07.0.554090447949.issue4877@psf.upfronthosting.co.za>
Message-ID: <1302483418.16.0.974319122433.issue4877@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is now fixed in 2.7, I also removed the unnecessary call to PyErr_Clear in ba699cf9bdbb (2.7), 6b4467e71872 (3.2), and 2d1d9759d3a4 (3.3).

----------
assignee:  -> ezio.melotti
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4877>
_______________________________________

From report at bugs.python.org  Mon Apr 11 03:07:21 2011
From: report at bugs.python.org (kent)
Date: Mon, 11 Apr 2011 01:07:21 +0000
Subject: [issue11820] idle3 shell os.system swallows shell command output
In-Reply-To: <1302421540.99.0.957938249964.issue11820@psf.upfronthosting.co.za>
Message-ID: <1302484041.57.0.394532964681.issue11820@psf.upfronthosting.co.za>


kent <fuzzballz at comcast.net> added the comment:

When starting idle from a terminal the output from the command is sent to the terminal.  When starting idle from the desktop, the output disappears except  for the exit status.  Same behavior with 2.65

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11820>
_______________________________________

From report at bugs.python.org  Mon Apr 11 03:27:25 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Apr 2011 01:27:25 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1302485245.54.0.829903242542.issue1028@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Nudge: report on the Ubuntu bug tracker that this is still an issue with 3.2:

https://bugs.launchpad.net/bugs/517552

----------
nosy: +r.david.murray
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Mon Apr 11 03:57:48 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 11 Apr 2011 01:57:48 +0000
Subject: [issue985064] plistlib crashes too easily on bad files
Message-ID: <1302487068.11.0.628850286847.issue985064@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee: jvr -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue985064>
_______________________________________

From report at bugs.python.org  Mon Apr 11 04:22:00 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Mon, 11 Apr 2011 02:22:00 +0000
Subject: [issue11824] freeze.py broken due to ABI flags
In-Reply-To: <1302488520.76.0.698152823885.issue11824@psf.upfronthosting.co.za>
Message-ID: <1302488520.76.0.698152823885.issue11824@psf.upfronthosting.co.za>


New submission from Andreas St?hrk <andy-python at hammerhartes.de>:

The recent addition of ABI flags broke the freeze tool as it doesn't construct the paths to required files correctly any longer. The attached patch fixes the issue for me, but I'm not too sure that I used the right config values.

----------
components: Demos and Tools
files: freeze.patch
keywords: patch
messages: 133495
nosy: Trundle
priority: normal
severity: normal
status: open
title: freeze.py broken due to ABI flags
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21609/freeze.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11824>
_______________________________________

From report at bugs.python.org  Mon Apr 11 04:26:30 2011
From: report at bugs.python.org (Reid Kleckner)
Date: Mon, 11 Apr 2011 02:26:30 +0000
Subject: [issue5673] Add timeout option to subprocess.Popen
In-Reply-To: <1238701276.41.0.515283298202.issue5673@psf.upfronthosting.co.za>
Message-ID: <1302488790.77.0.935278029715.issue5673@psf.upfronthosting.co.za>


Reid Kleckner <rnk at mit.edu> added the comment:

Thanks for fixing the negative timeout issue.  I assumed incorrectly that a negative timeout would cause it to check and return immediately if it would otherwise block.

As for the docs, the 3.2/3.3 issue was fixed in [[72e49cb7fcf5]].

I just added a Misc/NEWS entry for 3.3's What's New in [[9140f2363623]].

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5673>
_______________________________________

From report at bugs.python.org  Mon Apr 11 04:29:48 2011
From: report at bugs.python.org (Reid Kleckner)
Date: Mon, 11 Apr 2011 02:29:48 +0000
Subject: [issue11757] test_subprocess.test_communicate_timeout_large_ouput
	failure on select(): negative timeout?
In-Reply-To: <1301869705.52.0.173979620005.issue11757@psf.upfronthosting.co.za>
Message-ID: <1302488988.7.0.734017284331.issue11757@psf.upfronthosting.co.za>


Reid Kleckner <rnk at mit.edu> added the comment:

I think the best behavior would be to go ahead and check one last time before raising the exception, so _remaining_time should turn a negative value into 0 (assuming that a timeout value of zero does the right thing for our use case).

If people don't feel that is best, refactoring _remaining_time to incorporate the check in _check_timeout would also be good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11757>
_______________________________________

From report at bugs.python.org  Mon Apr 11 05:54:39 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 11 Apr 2011 03:54:39 +0000
Subject: [issue985064] plistlib crashes too easily on bad files
Message-ID: <1302494079.77.0.433599380164.issue985064@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/issue985064>
_______________________________________

From report at bugs.python.org  Mon Apr 11 06:12:12 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 11 Apr 2011 04:12:12 +0000
Subject: [issue775321] plistlib error handling
Message-ID: <1302495132.04.0.58532456055.issue775321@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Note that this behavior is documented[0]:
"""
The XML data is parsed using the Expat parser from xml.parsers.expat ? see its documentation for possible exceptions on ill-formed XML. Unknown elements will simply be ignored by the plist parser.
"""

Since this is documented and expat only has an exception type (xml.parsers.expat.ExpatError) I don't think is necessary to do anything here.
Unless you think that the doc should be rephrased, this can be closed again.

[0]: http://docs.python.org/library/plistlib.html#plistlib.readPlist

----------
assignee: jvr -> 
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue775321>
_______________________________________

From report at bugs.python.org  Mon Apr 11 06:41:48 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 11 Apr 2011 04:41:48 +0000
Subject: [issue775321] plistlib error handling
Message-ID: <1302496908.3.0.204433024105.issue775321@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I agree.  If it were important to make plistlib error handling more useful, using a different parser would be the way to go, I think.  In any case, Apple has deprecated the use of XML plists and moved to a binary plist format that plistlib does not recognize or handle.

----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue775321>
_______________________________________

From report at bugs.python.org  Mon Apr 11 08:26:32 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 11 Apr 2011 06:26:32 +0000
Subject: [issue11825] faulthandler: failure without threads
In-Reply-To: <1302503192.32.0.414479230775.issue11825@psf.upfronthosting.co.za>
Message-ID: <1302503192.32.0.414479230775.issue11825@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Hi, the tests fail on Debian if the option --without-threads is used:

./configure --with-pydebug --without-threads
make
make test

./python -Wd -E -bb  ./Lib/test/regrtest.py -l 
== CPython 3.3a0 (default:9140f2363623+, Jan 30 2011, 04:52:32) [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)]
==   Linux-2.6.23.1-i686-with-debian-4.0 little-endian
==   /home/stefan/hg/default/build/test_python_24329
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, verbose=0, bytes_warning=2, quiet=0)
[  1/355] test_grammar
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 1607, in <module>
    main()
  File "./Lib/test/regrtest.py", line 650, in main
    rerun_failed=verbose3, timeout=timeout)
  File "./Lib/test/regrtest.py", line 824, in runtest
    faulthandler.dump_tracebacks_later(timeout, exit=True)
AttributeError: 'module' object has no attribute 'dump_tracebacks_later'

----------
assignee: haypo
components: Tests
messages: 133500
nosy: haypo, skrah
priority: normal
severity: normal
status: open
title: faulthandler: failure without threads
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11825>
_______________________________________

From report at bugs.python.org  Mon Apr 11 08:56:19 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 11 Apr 2011 06:56:19 +0000
Subject: [issue11826] Leak in atexitmodule
In-Reply-To: <1302504979.95.0.857272040465.issue11826@psf.upfronthosting.co.za>
Message-ID: <1302504979.95.0.857272040465.issue11826@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Valgrind reports a leak (definitely lost) in atexitmodule.c. The
patch fixes the problem.

----------
components: Extension Modules
files: atexit-leak.patch
keywords: patch
messages: 133501
nosy: skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Leak in atexitmodule
type: resource usage
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21610/atexit-leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11826>
_______________________________________

From report at bugs.python.org  Mon Apr 11 09:31:08 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 11 Apr 2011 07:31:08 +0000
Subject: [issue10156] Initialization of globals in unicodeobject.c
In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za>
Message-ID: <1302507068.4.0.410410529727.issue10156@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

[Merging with issue 11402]

Daniel's patch is much simpler, but I think that unicode_empty and
unicode_latin1 would need to be protected before _PyUnicode_Init
is called.

Is the module initialization procedure documented somewhere? I get
the impression that unicodeobject.c depends on dict.c and dict.c
depends on unicodeobject.c.

----------
nosy: +stutzbach
Added file: http://bugs.python.org/file21611/unicode-leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10156>
_______________________________________

From report at bugs.python.org  Mon Apr 11 09:32:27 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 11 Apr 2011 07:32:27 +0000
Subject: [issue11402] _PyUnicode_Init leaks a little memory once
In-Reply-To: <1299283849.1.0.295176765442.issue11402@psf.upfronthosting.co.za>
Message-ID: <1302507147.85.0.169733103516.issue11402@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

This should be a duplicate of issue 10156.

----------
nosy: +skrah
resolution:  -> duplicate
stage: patch review -> committed/rejected
status: open -> closed
superseder:  -> Initialization of globals in unicodeobject.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11402>
_______________________________________

From report at bugs.python.org  Mon Apr 11 09:36:31 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 11 Apr 2011 07:36:31 +0000
Subject: [issue10156] Initialization of globals in unicodeobject.c
In-Reply-To: <1302507068.4.0.410410529727.issue10156@psf.upfronthosting.co.za>
Message-ID: <20110411073525.GA27438@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Stefan Krah <report at bugs.python.org> wrote:
> Is the module initialization procedure documented somewhere? I get
> the impression that unicodeobject.c depends on dict.c and dict.c
> depends on unicodeobject.c.

s/dict.c/dictobject.c/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10156>
_______________________________________

From report at bugs.python.org  Mon Apr 11 09:51:07 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 11 Apr 2011 07:51:07 +0000
Subject: [issue11593] Add encoding parameter to logging.basicConfig
In-Reply-To: <1300424025.83.0.489741781073.issue11593@psf.upfronthosting.co.za>
Message-ID: <1302508267.32.0.831899810895.issue11593@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

"handlers" parameter now added to logging.basicConfig(), which covers this use case:

logging.basicConfig(handlers=[logging.FileHandler('test.log', 'w', 'utf-8')])

Ref: changeset c9e9142d82d6

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11593>
_______________________________________

From report at bugs.python.org  Mon Apr 11 09:54:39 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 11 Apr 2011 07:54:39 +0000
Subject: [issue11369] Add caching for the isEnabledFor() computation
In-Reply-To: <1299035016.51.0.282905880953.issue11369@psf.upfronthosting.co.za>
Message-ID: <1302508479.52.0.721613623226.issue11369@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I'll regretfully have to mark this as wontfix, since adding threading interlocks for correct operation in multi-threaded environments will negate the performance benefit.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11369>
_______________________________________

From report at bugs.python.org  Mon Apr 11 10:38:17 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 11 Apr 2011 08:38:17 +0000
Subject: [issue11827] mention of list2cmdline() in docs of subprocess.Popen
In-Reply-To: <1302511097.53.0.993242324349.issue11827@psf.upfronthosting.co.za>
Message-ID: <1302511097.53.0.993242324349.issue11827@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

The documentation of subprocess.Popen mentions a function named list2cmdline():

----
  On Windows: the Popen class uses CreateProcess() to execute the child program, which operates on strings. If args is a sequence, it will be converted to a string using the list2cmdline() method. Please note that not all MS Windows applications interpret the command line the same way: list2cmdline() is designed for applications using the same rules as the MS C runtime.
----

I find this rather opaque and useless. list2cmdline() in subprocess is publicly accessible (doesn't begin with underscores) but it isn't documented.

The solution can be one of the following:

1. Document list2cmdline in the docs of subprocess, making the reference to is useful
2. Don't mention list2cmdline and instead mention what it does with the command-line list

----------
assignee: docs at python
components: Documentation
messages: 133507
nosy: docs at python, eli.bendersky
priority: normal
severity: normal
stage: needs patch
status: open
title: mention of list2cmdline() in docs of subprocess.Popen
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11827>
_______________________________________

From report at bugs.python.org  Mon Apr 11 11:59:50 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 11 Apr 2011 09:59:50 +0000
Subject: [issue11782] email.generator.Generator.flatten() fails
In-Reply-To: <1302097785.46.0.28701143911.issue11782@psf.upfronthosting.co.za>
Message-ID: <20110411095940.GA11391@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

So here is a patch which steps forward the not-yet-fully-completed 
transition to the mixed bytes/str EMail stuff. 
Test coverage is available if you patch in 
http://bugs.python.org/file21549/11684.1.diff from #11684.
(Because i leak the great picture of this module ... say.)

----------
keywords: +patch
Added file: http://bugs.python.org/file21612/11782.1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11782>
_______________________________________
-------------- next part --------------
diff --git a/Lib/email/generator.py b/Lib/email/generator.py
--- a/Lib/email/generator.py
+++ b/Lib/email/generator.py
@@ -297,10 +297,12 @@
         # message/rfc822.  Such messages are generated by, for example,
         # Groupwise when forwarding unadorned messages.  (Issue 7970.)  So
         # in that case we just emit the string body.
-        payload = msg.get_payload()
+        payload = msg._payload
         if isinstance(payload, list):
             g.flatten(msg.get_payload(0), unixfrom=False, linesep=self._NL)
             payload = s.getvalue()
+        else:
+            payload = self._encode(payload)
         self._fp.write(payload)
 
     # This used to be a module level function; we use a classmethod for this

From report at bugs.python.org  Mon Apr 11 12:22:33 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 11 Apr 2011 10:22:33 +0000
Subject: [issue11808] $MACOSX_DEPLOYMENT_TARGET mismatch ... during configure
In-Reply-To: <1302364691.79.0.724172613859.issue11808@psf.upfronthosting.co.za>
Message-ID: <20110411102107.GB11391@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

On Sat, Apr 09, 2011 at 03:58:11PM +0000, Ned Deily wrote:
> By the way, since you've asked about it before, 
> MACOSX_DEPLOYMENT_TARGET is a standard feature of the Apple gcc 
> tool chain and is used to support builds for multiple versions.  
> See -mmacosx-version-min in the OS X man (1) gcc and 
> http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html

P.S.:
Thank you for this information. 
You know, we here (and i personally too) don't fiddle around 
with this, because there is no time left over for such things.

We have discovered flags which work (especially hairy for ld(1) 
and dynamic libraries and concurrent installs), wrote a bunch of 
Perl configure scripts which use '$^O eq' and, for performance, 
&$COMPILE_PTF($TCC, $TEXE, 'sysdeps/generic/x86/cnf.cpuid.c'), 
and try to realize the rest with good coding style. 
No '.weak' and other maybe object file format dependend stuff 
around here.

And i just wanted to try Mac OS once, so i bought a MacBook. 
It looks beautiful and fancontrol is automatic and fantastic and 
i try hard to forget that i'm looking at OpenGL and myriads of 
floating-point calculations.

But i was out of this game once i've written an OGG player (there 
was none and no /dev/whatever accessible here), trying AudioUnit 
and CoreAudio, which confirm something in an event handler and 
have forgotten it after that returns.  And then there was a crash 
and i discovered that Mazzoni's Audacity includes comments on this 
crash in the Mac OS sources from a *long* time ago. 
And so i decided that i don't want to do Apple, and lucky me 
i don't need to make money with doing so nonetheless.

And now i think you have the complete picture on that. 
Thanks again.
:)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11808>
_______________________________________

From report at bugs.python.org  Mon Apr 11 12:31:12 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Apr 2011 10:31:12 +0000
Subject: [issue11827] mention of list2cmdline() in docs of subprocess.Popen
In-Reply-To: <1302511097.53.0.993242324349.issue11827@psf.upfronthosting.co.za>
Message-ID: <1302517872.99.0.319677950301.issue11827@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I vote for (2) (I presume 'it' in that sentence is 'subprocess').  list2cmdline shouldn't be a "real" public method, at least not without the issues surrounding being given careful design attention.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11827>
_______________________________________

From report at bugs.python.org  Mon Apr 11 12:37:51 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 11 Apr 2011 10:37:51 +0000
Subject: [issue11827] mention of list2cmdline() in docs of subprocess.Popen
In-Reply-To: <1302511097.53.0.993242324349.issue11827@psf.upfronthosting.co.za>
Message-ID: <1302518271.81.0.112447241164.issue11827@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I also prefer (2) since I see no reason for the user to use list2cmdline() directly, let alone from subprocess (had there been rationale for such a public function it should probably be in another module).

As for 'it', I guess you can say it means 'subprocess' or 'list2cmdline', doesn't matter which.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11827>
_______________________________________

From report at bugs.python.org  Mon Apr 11 13:11:06 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Apr 2011 11:11:06 +0000
Subject: [issue11783] email parseaddr and formataddr should be IDNA aware
In-Reply-To: <1302099121.47.0.140525796896.issue11783@psf.upfronthosting.co.za>
Message-ID: <1302520266.92.0.824190052914.issue11783@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Patch mostly looks good to me, modulo some English wording that I'll fix up when I commit it.

The issue with the '@' is that it might not be there.  So you do need to check for that case (it means the domain part defaults to the 'local' domain).  I should double check the RFC to make sure that's the only special case, but I believe it is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11783>
_______________________________________

From report at bugs.python.org  Mon Apr 11 13:55:32 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 11 Apr 2011 11:55:32 +0000
Subject: [issue11650] Faulty RESTART/EINTR handling in Parser/myreadline.c
In-Reply-To: <1300887352.61.0.261947274229.issue11650@psf.upfronthosting.co.za>
Message-ID: <1302522932.92.0.973505523607.issue11650@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

I've opened it and it's fixed, so i'll close it now.

If someone finds the single bug in 11650.termios-1.diff
in termios_resume() and also has an idea of how to call
termios_suspend() in case Python crashes or gives back
the terminal in any other way i would vote for reopening
this and using my version, because it is better.

Take care otherwise.
Thanks, haypo.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11650>
_______________________________________

From report at bugs.python.org  Mon Apr 11 14:21:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Apr 2011 12:21:01 +0000
Subject: [issue11827] mention of list2cmdline() in docs of subprocess.Popen
In-Reply-To: <1302511097.53.0.993242324349.issue11827@psf.upfronthosting.co.za>
Message-ID: <1302524461.86.0.935093604946.issue11827@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, right.  I guess I was advocating that the docs be written from the perspective that list2cmdline doesn't exist as an identifiable entity.  From the POV of the updated docs, it is just subprocess's behavior, and list2cmdline is an implementation detail.  Which is what you were saying.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11827>
_______________________________________

From report at bugs.python.org  Mon Apr 11 14:41:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Apr 2011 12:41:22 +0000
Subject: [issue11825] faulthandler: failure without threads
In-Reply-To: <1302503192.32.0.414479230775.issue11825@psf.upfronthosting.co.za>
Message-ID: <1302525682.18.0.127643931887.issue11825@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Attached patch disables regrtest.py timeout if faulthandler.dump_tracebacks_later() is missing. It prints a warning at startup, and an error if --timeout option is used.

----------
keywords: +patch
Added file: http://bugs.python.org/file21613/timeout.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11825>
_______________________________________

From report at bugs.python.org  Mon Apr 11 14:41:27 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 11 Apr 2011 12:41:27 +0000
Subject: [issue11817] berkeley db 5.1 support
In-Reply-To: <1302403928.0.0.111230204951.issue11817@psf.upfronthosting.co.za>
Message-ID: <1302525687.62.0.677312688654.issue11817@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

The 3rd party package is activelly maintained (by me :) in http://www.jcea.es/programacion/pybsddb.htm. BDB 5.1 support is there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11817>
_______________________________________

From report at bugs.python.org  Mon Apr 11 14:45:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Apr 2011 12:45:32 +0000
Subject: [issue8428] buildbot: test_multiprocessing timeout (test_notify_all?
	test_pool_worker_lifetime?)
In-Reply-To: <1302474629.49.0.386220358783.issue8428@psf.upfronthosting.co.za>
Message-ID: <201104111445.29765.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> (Victor, please don't file many bugs in a single issue!)

I thought that these issues were the same.

Victor

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8428>
_______________________________________

From report at bugs.python.org  Mon Apr 11 14:49:48 2011
From: report at bugs.python.org (olt)
Date: Mon, 11 Apr 2011 12:49:48 +0000
Subject: [issue4606] Passing 'None' if argtype is set to POINTER(...) doesn't
	always result in NULL
In-Reply-To: <1228816020.28.0.155864486659.issue4606@psf.upfronthosting.co.za>
Message-ID: <1302526188.12.0.21170853873.issue4606@psf.upfronthosting.co.za>


olt <olt at bogosoft.com> added the comment:

For anyone that has to use a Python version where this bug is present, it is possible to manually create a NULL pointer.

For the example:

POINTER(c_double)()

This works, at least in my case.

----------
nosy: +olt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4606>
_______________________________________

From report at bugs.python.org  Mon Apr 11 15:02:21 2011
From: report at bugs.python.org (Torsten Becker)
Date: Mon, 11 Apr 2011 13:02:21 +0000
Subject: [issue11783] email parseaddr and formataddr should be IDNA aware
In-Reply-To: <1302099121.47.0.140525796896.issue11783@psf.upfronthosting.co.za>
Message-ID: <1302526941.82.0.592177079162.issue11783@psf.upfronthosting.co.za>


Torsten Becker <torsten.becker at gmail.com> added the comment:

> modulo some English wording that I'll fix up when I commit it.

Yeah, sorry for that, I seem to have trouble with writing good documentation. :)  I'll have a look at the documents referenced by [1] to improve my writing.

> The issue with the '@' is that it might not be there.

I added a fix and a test for this in v2.  However, when reading through the RFC [2] and Wikipedia [3], it seems like this is not actually allowed.

Is there a way to internationalize the local-part as well?  That is the only part which is missing now that domain and real name are covered.


[1]: http://docs.python.org/devguide/docquality.html
[2]: http://tools.ietf.org/html/rfc5322#section-3.4
[3]: http://en.wikipedia.org/wiki/Email_address#Invalid_email_addresses

----------
Added file: http://bugs.python.org/file21614/issue-11783-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11783>
_______________________________________

From report at bugs.python.org  Mon Apr 11 16:05:43 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 11 Apr 2011 14:05:43 +0000
Subject: [issue11810] _socket fails to build on OpenIndiana
In-Reply-To: <1302382179.44.0.700403156795.issue11810@psf.upfronthosting.co.za>
Message-ID: <1302530743.11.0.174507236661.issue11810@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11810>
_______________________________________

From report at bugs.python.org  Mon Apr 11 16:07:05 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 11 Apr 2011 14:07:05 +0000
Subject: [issue11825] faulthandler: failure without threads
In-Reply-To: <1302503192.32.0.414479230775.issue11825@psf.upfronthosting.co.za>
Message-ID: <1302530825.48.0.629275377203.issue11825@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The patch works. Is it expected that dump_tracebacks_later is missing
when building --without-threads? If so, the warning is probably
confusing for the uninitiated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11825>
_______________________________________

From report at bugs.python.org  Mon Apr 11 16:16:06 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 11 Apr 2011 14:16:06 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1302531366.57.0.269659922875.issue11816@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Mon Apr 11 16:18:44 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 11 Apr 2011 14:18:44 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1302531524.59.0.0487940616925.issue11816@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Do not forget to update docs too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Mon Apr 11 16:21:23 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Apr 2011 14:21:23 +0000
Subject: [issue11783] email parseaddr and formataddr should be IDNA aware
In-Reply-To: <1302099121.47.0.140525796896.issue11783@psf.upfronthosting.co.za>
Message-ID: <1302531683.7.0.284819272238.issue11783@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  You are correct.  I thought the RFC's covered this case, but apparently they don't.

The email package gets used in MUA contexts, where the domain part of the address may be omitted and the MUA must fill it in before transmitting the message to the MTA.  And some MTAs will fill in the local domain if it is omitted, so actually it applies in an MTA context, too.  So we need to support this case even if it isn't covered by the RFCs.

Thanks, the revised patch looks good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11783>
_______________________________________

From report at bugs.python.org  Mon Apr 11 16:21:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Apr 2011 14:21:35 +0000
Subject: [issue5162] multiprocessing cannot spawn child from a Windows service
In-Reply-To: <1233885632.9.0.0484597105973.issue5162@psf.upfronthosting.co.za>
Message-ID: <1302531695.9.0.567917184814.issue5162@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Windows
nosy: +brian.curtin, tim.golden
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5162>
_______________________________________

From report at bugs.python.org  Mon Apr 11 16:21:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Apr 2011 14:21:39 +0000
Subject: [issue5162] multiprocessing cannot spawn child from a Windows service
In-Reply-To: <1233885632.9.0.0484597105973.issue5162@psf.upfronthosting.co.za>
Message-ID: <1302531699.6.0.555898176037.issue5162@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5162>
_______________________________________

From report at bugs.python.org  Mon Apr 11 16:27:38 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 11 Apr 2011 14:27:38 +0000
Subject: [issue5162] multiprocessing cannot spawn child from a Windows service
In-Reply-To: <1233885632.9.0.0484597105973.issue5162@psf.upfronthosting.co.za>
Message-ID: <1302532058.85.0.0134458471543.issue5162@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

This looks reasonable to me. If no one beats me to it, I'll check it in tonight.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5162>
_______________________________________

From report at bugs.python.org  Mon Apr 11 16:28:12 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 11 Apr 2011 14:28:12 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1302532092.03.0.770088817475.issue11816@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Mon Apr 11 16:29:18 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 11 Apr 2011 14:29:18 +0000
Subject: [issue11822] Improve disassembly to show embedded code objects
In-Reply-To: <1302467152.39.0.854888976189.issue11822@psf.upfronthosting.co.za>
Message-ID: <1302532158.23.0.0582901335419.issue11822@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11822>
_______________________________________

From report at bugs.python.org  Mon Apr 11 16:42:04 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 11 Apr 2011 14:42:04 +0000
Subject: [issue11822] Improve disassembly to show embedded code objects
In-Reply-To: <1302467152.39.0.854888976189.issue11822@psf.upfronthosting.co.za>
Message-ID: <1302532924.71.0.981181549516.issue11822@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Would you like to display lambdas as well?


>>> dis('lambda x: x**2')
  1           0 LOAD_CONST               0 (<code object <lambda> at 0x1005c9ad0, file "<dis>", line 1>) 
              3 MAKE_FUNCTION            0 
              6 RETURN_VALUE         

<code object <lambda> at 0x1005cb140, file "<dis>", line 1>:
  1           0 LOAD_FAST                0 (x) 
              3 LOAD_CONST               1 (2) 
              6 BINARY_POWER         
              7 RETURN_VALUE         


I like the idea, but would rather see code objects expanded in-line, possibly indented rather than at the end.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11822>
_______________________________________

From report at bugs.python.org  Mon Apr 11 16:48:19 2011
From: report at bugs.python.org (Swapnil Talekar)
Date: Mon, 11 Apr 2011 14:48:19 +0000
Subject: [issue11803] Memory leak in sub-interpreters
In-Reply-To: <1302246410.34.0.932869842046.issue11803@psf.upfronthosting.co.za>
Message-ID: <1302533299.68.0.0624144435529.issue11803@psf.upfronthosting.co.za>


Swapnil Talekar <swapnil.st at gmail.com> added the comment:

Sorry about the previous report. I should have tested it thoroughly. Yes, it does not seem to rise but eventually it does. This time, I'v added garbage collection right after the subinterpreter is shutdown. The memory consumption does not seem to rise above 8MB when you start the test. But if you leave it running for couple of hours I have seen it grown upto 24MB. I haven't tested more that that but it seems that if you run it for couple of days, memory consumption will grow upto few 100 MB.
This is strange because mod_python doesn't seem to be doing anything special to handle this, then how does it work with mod_python?

----------
Added file: http://bugs.python.org/file21615/test_subinter_with_gc.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11803>
_______________________________________

From report at bugs.python.org  Mon Apr 11 16:50:08 2011
From: report at bugs.python.org (Swapnil Talekar)
Date: Mon, 11 Apr 2011 14:50:08 +0000
Subject: [issue11803] Memory leak in sub-interpreters
In-Reply-To: <1302246410.34.0.932869842046.issue11803@psf.upfronthosting.co.za>
Message-ID: <1302533408.94.0.656244621159.issue11803@psf.upfronthosting.co.za>


Changes by Swapnil Talekar <swapnil.st at gmail.com>:


----------
resolution: invalid -> 
status: closed -> open
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11803>
_______________________________________

From report at bugs.python.org  Mon Apr 11 17:06:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Apr 2011 15:06:06 +0000
Subject: [issue11818] tempfile.TemporaryFile example in docs doesnt work
In-Reply-To: <1302419439.43.0.340740214318.issue11818@psf.upfronthosting.co.za>
Message-ID: <1302534366.58.0.0644265144121.issue11818@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

May I ask why 3.1 was not fixed too?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11818>
_______________________________________

From report at bugs.python.org  Mon Apr 11 17:09:08 2011
From: report at bugs.python.org (Marijn Schouten)
Date: Mon, 11 Apr 2011 15:09:08 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>


New submission from Marijn Schouten <hkBst at gentoo.org>:

startswith and endswith don't accept None as slice index, as shown by below interaction. Same behavior for python-3.1.3(with print()) and python-2.7.1. If instead this is intended behavior then the error message is wrong.

$ python -c "print 'abc'[-1:None]"
c
$ python -c "print 'abc'.endswith('c',-1,None)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: slice indices must be integers or None or have an __index__ method

----------
components: None
messages: 133527
nosy: hkBst
priority: normal
severity: normal
status: open
title: startswith and endswith don't accept None as slice index
type: behavior
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Mon Apr 11 17:12:56 2011
From: report at bugs.python.org (Marijn Schouten)
Date: Mon, 11 Apr 2011 15:12:56 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1302534776.46.0.599042163441.issue11828@psf.upfronthosting.co.za>


Marijn Schouten <hkBst at gentoo.org> added the comment:

I remark that `find' and `index' do accept None:

$ python3 -c "print('abc'.find('c',None,None))"
2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Mon Apr 11 17:16:53 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 11 Apr 2011 15:16:53 +0000
Subject: [issue11803] Memory leak in sub-interpreters
In-Reply-To: <1302246410.34.0.932869842046.issue11803@psf.upfronthosting.co.za>
Message-ID: <1302535013.05.0.947755884572.issue11803@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

a) Python 2.6 is open only for security fixes. Could you possibly try in 2.7, 3.1 and 3.2?

b) Could you run the test a bit longer and confirm that the leak is slowly growing?

c) I assume your mod_python is running under Apache. Apache restarts processes after X requests are served, so any (slow growing) leak would be not aparent.

Thanks for your effort.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11803>
_______________________________________

From report at bugs.python.org  Mon Apr 11 17:17:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Apr 2011 15:17:40 +0000
Subject: [issue11813] inspect.getattr_static doesn't get module attributes
In-Reply-To: <1302389059.87.0.554654770337.issue11813@psf.upfronthosting.co.za>
Message-ID: <1302535060.65.0.254017432356.issue11813@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11813>
_______________________________________

From report at bugs.python.org  Mon Apr 11 17:26:34 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 11 Apr 2011 15:26:34 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1302535594.03.0.2563569381.issue11828@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Mon Apr 11 17:27:55 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 11 Apr 2011 15:27:55 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1302535675.39.0.0361261266933.issue11828@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Since this is not a regression, this would be solved in 3.3 only. I guess.

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Mon Apr 11 17:39:55 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Apr 2011 15:39:55 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1302536395.94.0.562051137547.issue11828@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, if it is judged a bug (and it seems to me that it is), then it can get fixed in 2.7 and 3.2 (and yes I did confirm that the same bug is present in 2.7).

It appears to be the result of startswith/endswith applying naive parsing to their arguments rather than the more sophisticated stringlib calls used by find and index.

----------
nosy: +r.david.murray
versions: +Python 2.7, Python 3.1, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Mon Apr 11 18:01:28 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 Apr 2011 16:01:28 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1302537688.28.0.987329579305.issue11828@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Letting None be used as an index has always been treated as a feature request; however, in this case, it can be deemed a bug because the error message is making a promise that isn't kept.

It would be nice if once and for all this got solved by making argument parsing codes for indices and slices; otherwise, we're doomed to get some variant of this feature request over and over again.

FWIW, Google's code search shows that this slicing feature for startswith/endswith was of dubious worth -- no one seems to uses it.  The feature should probably have not been added in the first place.

Now that it is in, we still need to handle this report because people will need to make method wrappers for string-like classes.

----------
nosy: +rhettinger
priority: normal -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Mon Apr 11 18:08:30 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Mon, 11 Apr 2011 16:08:30 +0000
Subject: [issue11790] transient failure in
	test_multiprocessing.WithProcessesTestCondition
In-Reply-To: <1302131075.81.0.79285380131.issue11790@psf.upfronthosting.co.za>
Message-ID: <1302538110.4.0.216338278823.issue11790@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

One possible cause for those intermittent failures is the preemtion of a thread while waiting on the condition:

 def wait(self, timeout=None):
   233         assert self._lock._semlock._is_mine(), \
   234                'must acquire() condition before using wait()'
   235 
   236         # indicate that this thread is going to sleep
   237         self._sleeping_count.release()
   238 
   239         # release lock
   240         count = self._lock._semlock._count()
   241         for i in range(count):
   242             self._lock.release()
   243 
<-- here
   244         try:
   245             # wait for notification or timeout
   246             ret = self._wait_semaphore.acquire(True, timeout)


For example, if the last thread/process is preempted after having released the condition's lock (and hence performed a up on the "sleeping" semaphore sooner in the "f" function) but before waiting on the condition's semaphore, since the main thread only waits 0.1s before locking the condition and performing a notify_all on it (it will proceed since all the threads performed an up on "sleeping"), only the threads already waiting on the condition will be woken up, this last thread won't be woken up, triggering a failure in this assertion
   764         self.assertReturnsIfImplemented(0, get_value, woken)
with woken.get_value() == 5

It's just a guess, but I'd suggest increasing the sleep before trying to signal the condition a bit:

   762         # check no process/thread has woken up
   763         time.sleep(10 * DELTA)

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11790>
_______________________________________

From report at bugs.python.org  Mon Apr 11 18:08:54 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 11 Apr 2011 16:08:54 +0000
Subject: [issue11823] disassembly needs to argument counts on calls with
	keyword args
In-Reply-To: <1302469900.48.0.983863495872.issue11823@psf.upfronthosting.co.za>
Message-ID: <1302538134.23.0.111425979952.issue11823@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am posting an unfinished patch (needs additional tests and possibly documentation) to get feedback on whether it would make sense to wait for issue11816 refactoring before implementing this.  Note the code duplication between disassemble and _disassemble_bytes.  I am also not happy about the need for another constant exported from opcode.

----------
keywords: +patch
nosy: +belopolsky
Added file: http://bugs.python.org/file21616/issue11823.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11823>
_______________________________________

From report at bugs.python.org  Mon Apr 11 18:15:37 2011
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 11 Apr 2011 16:15:37 +0000
Subject: [issue2202] urllib2 fails against IIS 6.0 (No support for MD5-sess
	auth)
In-Reply-To: <1204223194.19.0.670418970441.issue2202@psf.upfronthosting.co.za>
Message-ID: <1302538537.94.0.46281239358.issue2202@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Is this moving anywhere?  I was asked to apply this patch locally and am curious as to whether it is moving into the stdlib.

----------
nosy: +krisvale

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2202>
_______________________________________

From report at bugs.python.org  Mon Apr 11 18:18:26 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Mon, 11 Apr 2011 16:18:26 +0000
Subject: [issue11790] transient failure in
	test_multiprocessing.WithProcessesTestCondition
In-Reply-To: <1302131075.81.0.79285380131.issue11790@psf.upfronthosting.co.za>
Message-ID: <1302538706.05.0.322059803267.issue11790@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Sorry, wrong copy-paste, the failing assertion will of course be this one:
   773         self.assertReturnsIfImplemented(6, get_value, woken)

since woken.get_value() == 5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11790>
_______________________________________

From report at bugs.python.org  Mon Apr 11 19:40:24 2011
From: report at bugs.python.org (=?utf-8?q?Wojciech_Mu=C5=82a?=)
Date: Mon, 11 Apr 2011 17:40:24 +0000
Subject: [issue11354] argparse: nargs could accept range of options count
In-Reply-To: <1298911895.1.0.590272861033.issue11354@psf.upfronthosting.co.za>
Message-ID: <1302543624.07.0.227650524426.issue11354@psf.upfronthosting.co.za>


Wojciech Mu?a <wojciech_mula at poczta.onet.pl> added the comment:

Steven, thank you for links, I prepared patch against trunk.
All tests passed.

----------
Added file: http://bugs.python.org/file21617/issue11354.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11354>
_______________________________________

From report at bugs.python.org  Mon Apr 11 20:19:47 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 11 Apr 2011 18:19:47 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1302545987.09.0.83923679232.issue11828@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Anybody taking care of this, should check also "byte" and "bytearray".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Mon Apr 11 20:21:02 2011
From: report at bugs.python.org (William Hart)
Date: Mon, 11 Apr 2011 18:21:02 +0000
Subject: [issue11369] Add caching for the isEnabledFor() computation
In-Reply-To: <1302508479.52.0.721613623226.issue11369@psf.upfronthosting.co.za>
Message-ID: <BANLkTimqkCij_6GsQMurRBtn87Gnb_0p4A@mail.gmail.com>


William Hart <whart222 at gmail.com> added the comment:

Understood!  FYI, we worked around this caching issue explicitly in our
code.  This wound up being simpler than supporting a hacked version of the
logger.

Thanks for looking into this!

On Mon, Apr 11, 2011 at 1:54 AM, Vinay Sajip <report at bugs.python.org> wrote:

>
> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:
>
> I'll regretfully have to mark this as wontfix, since adding threading
> interlocks for correct operation in multi-threaded environments will negate
> the performance benefit.
>
> ----------
> resolution:  -> wont fix
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue11369>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file21618/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11369>
_______________________________________
-------------- next part --------------
Understood!?? FYI, we worked around this caching issue explicitly in our code.?? This wound up being simpler than supporting a hacked version of the logger.<br><br>Thanks for looking into this!<br><br><div class="gmail_quote">
On Mon, Apr 11, 2011 at 1:54 AM, Vinay Sajip <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="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Vinay Sajip &lt;<a href="mailto:vinay_sajip at yahoo.co.uk">vinay_sajip at yahoo.co.uk</a>&gt; added the comment:<br>
<br>
I&#39;ll regretfully have to mark this as wontfix, since adding threading interlocks for correct operation in multi-threaded environments will negate the performance benefit.<br>
<br>
----------<br>
resolution: ??-&gt; wont fix<br>
status: open -&gt; closed<br>
<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/issue11369" target="_blank">http://bugs.python.org/issue11369</a>&gt;<br>
_______________________________________<br>
</blockquote></div><br>

From report at bugs.python.org  Mon Apr 11 20:37:32 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 11 Apr 2011 18:37:32 +0000
Subject: [issue2202] urllib2 fails against IIS 6.0 (No support for MD5-sess
	auth)
In-Reply-To: <1204223194.19.0.670418970441.issue2202@psf.upfronthosting.co.za>
Message-ID: <1302547052.58.0.476485059651.issue2202@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

Adding some minor fixes to the original patch to apply cleanly to current 2.7 tip.

Also, add a conditional branch in the case that the server returns none of the supported algorithm strings, to raise a ValueError (the previous patch adds support for 'MD5-sess' but the original non-descript stack trace would be seen again with some other unsupported algorithm string).

----------
nosy: +santa4nt
Added file: http://bugs.python.org/file21619/issue2202_py27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2202>
_______________________________________

From report at bugs.python.org  Mon Apr 11 20:41:44 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 11 Apr 2011 18:41:44 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1302547305.0.0.816622180582.issue11828@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Mon Apr 11 22:11:19 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Apr 2011 20:11:19 +0000
Subject: [issue11747] unified_diff function product incorrect range information
In-Reply-To: <1301806636.68.0.728514553962.issue11747@psf.upfronthosting.co.za>
Message-ID: <E1Q9NS2-0005ty-Rs@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a2ee967de44f by Raymond Hettinger in branch '3.2':
Issue #11747: Fix range formatting in context and unified diffs.
http://hg.python.org/cpython/rev/a2ee967de44f

New changeset 1e5e3bb3e1f1 by Raymond Hettinger in branch 'default':
Issue #11747: Fix range formatting in context and unified diffs.
http://hg.python.org/cpython/rev/1e5e3bb3e1f1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11747>
_______________________________________

From report at bugs.python.org  Mon Apr 11 23:01:10 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 Apr 2011 21:01:10 +0000
Subject: [issue11747] unified_diff function product incorrect range information
In-Reply-To: <1301806636.68.0.728514553962.issue11747@psf.upfronthosting.co.za>
Message-ID: <1302555670.17.0.0489521474911.issue11747@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11747>
_______________________________________

From report at bugs.python.org  Mon Apr 11 23:08:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Apr 2011 21:08:07 +0000
Subject: [issue11822] Improve disassembly to show embedded code objects
In-Reply-To: <1302467152.39.0.854888976189.issue11822@psf.upfronthosting.co.za>
Message-ID: <1302556087.78.0.593491576178.issue11822@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think it should be enabled with an optional argument. Otherwise in some cases you'll get lots of additional output while you're only interested in the top-level code.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11822>
_______________________________________

From report at bugs.python.org  Mon Apr 11 23:13:10 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 Apr 2011 21:13:10 +0000
Subject: [issue11822] Improve disassembly to show embedded code objects
In-Reply-To: <1302467152.39.0.854888976189.issue11822@psf.upfronthosting.co.za>
Message-ID: <1302556390.79.0.361647840169.issue11822@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

If you disassemble a function, you typically want to see all the code in that function.  This isn't like pdb where you're choosing to step over or into another function outside the one being viewed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11822>
_______________________________________

From report at bugs.python.org  Mon Apr 11 23:21:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Apr 2011 21:21:03 +0000
Subject: [issue11822] Improve disassembly to show embedded code objects
In-Reply-To: <1302556390.79.0.361647840169.issue11822@psf.upfronthosting.co.za>
Message-ID: <1302556860.3783.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If you disassemble a function, you typically want to see all the code
> in that function.

That depends on the function. If you do event-driven programming (say,
Twisted deferreds with addCallback()), you don't necessarily want to see
the disassembly of the callbacks that are passed to the various
framework functions. Also, if you do so recursively, it might become
*very* unwieldy.

So I don't think there's anything "typical" here. It depends on what you
intend to focus on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11822>
_______________________________________

From report at bugs.python.org  Mon Apr 11 23:48:24 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 11 Apr 2011 21:48:24 +0000
Subject: [issue11822] Improve disassembly to show embedded code objects
In-Reply-To: <1302556860.3783.3.camel@localhost.localdomain>
Message-ID: <BANLkTin5apJYUFHJwkdVuA+qaucLasGahw@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, Apr 11, 2011 at 5:21 PM, Antoine Pitrou <report at bugs.python.org> wrote:
..
Raymond>> If you disassemble a function, you typically want to see all the code
Raymond>> [defined] in that function.

+1 (with clarification in [])

If the function calls a function defined elsewhere, I don't want to
see the called function disassembly when I disassemble the caller.  In
this case it is very easy to disassemble interesting functions with
separate dis() calls.  In the case like the following, however:

def f():
  def g(x):
      return x**2
dis(f)
2           0 LOAD_CONST               1 (<code object g at
0x10055ce88, file "x.py", line 2>)
              3 MAKE_FUNCTION            0
              6 STORE_FAST               0 (g)
...

when I see '<code object g at 0x10055ce88, ..>', I have to do
something unwieldy such as

  3           0 LOAD_FAST                0 (x)
              3 LOAD_CONST               1 (2)
              6 BINARY_POWER
              7 RETURN_VALUE

>
> That depends on the function. If you do event-driven programming (say,
> Twisted deferreds with addCallback()), you don't necessarily want to see
> the disassembly of the callbacks that are passed to the various
> framework functions. Also, if you do so recursively, it might become
> *very* unwieldy.

Can you provide some examples of this?  Nested functions are typically
short and even if they are long, the size disassembly would be
proportional to the line count of the function being disassembled,
which is expected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11822>
_______________________________________

From report at bugs.python.org  Mon Apr 11 23:53:40 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 Apr 2011 21:53:40 +0000
Subject: [issue11747] unified_diff function product incorrect range information
In-Reply-To: <1301806636.68.0.728514553962.issue11747@psf.upfronthosting.co.za>
Message-ID: <1302558820.37.0.927206524105.issue11747@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Re-opening.  There are some problems with the fix.  Context diff ranges need to show the ending line number, not the length.  Also for unified diffs, GNU diff is showing (x,0) as just (x).

----------
priority: low -> high
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11747>
_______________________________________

From report at bugs.python.org  Tue Apr 12 00:39:36 2011
From: report at bugs.python.org (Torsten Becker)
Date: Mon, 11 Apr 2011 22:39:36 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1302561576.18.0.596230925842.issue11828@psf.upfronthosting.co.za>


Torsten Becker <torsten.becker at gmail.com> added the comment:

Hi, I started working on a first patch for this.  A function _ParseTupleFinds() exists which does the proper parsing for this kind of arguments in unicodeobject.c, I adapted it to be usable for startswith() and endswith() besides find() and friends.

In issue-8282-v1.patch I fixed this for startswith() and endswith().  count() suffered from the same behavior and I updated it there as well.

----------
keywords: +patch
nosy: +torsten.becker
Added file: http://bugs.python.org/file21620/issue-11828-v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Tue Apr 12 00:42:00 2011
From: report at bugs.python.org (Graham Dumpleton)
Date: Mon, 11 Apr 2011 22:42:00 +0000
Subject: [issue11803] Memory leak in sub-interpreters
In-Reply-To: <1302246410.34.0.932869842046.issue11803@psf.upfronthosting.co.za>
Message-ID: <1302561720.56.0.420081853325.issue11803@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

I wouldn't use mod_python as any guide for how to use sub interpreters as its usage of sub interpreters and threading in conjunction with them is technically broken, not following properly the Python C API requirements. It doesn't even shutdown the Python interpreters properly resulting in memory leaks on Apache restarts into the Apache parent process which is then inherited by all forked Apache child processes.

Also, mod_python does not destroy sub interpreters within the life of the process and then create replacements. It is a bit of a misconception that some have that mod_python creates a new sub interpreter for each request, it doesn't. Instead once a sub interpreter is created it persists for the life of the process. Thus it doesn't even trigger the scenario you talk about.

In early versions of mod_wsgi the recycling of sub interpreters within the lifetime of the process was tried but was found not to be practical and feature was removed. The big stumbling block was third party C extensions. Various C extensions do not cope well with being initialised within context of one sub interpreter, with the sub interpreter being destroyed, and the C extension then being used in context of another sub interpreter. This usage pattern caused memory leaks in some cases and in worst case the process would crash.

In short, use of sub interpreters for short periods of time and then destroying them is all but unusable except within very constrained situations where no use is made of complex C extensions.

For related information see:

http://blog.dscpl.com.au/2009/03/python-interpreter-is-not-created-for.html
http://blog.dscpl.com.au/2009/11/save-on-memory-with-modwsgi-30.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11803>
_______________________________________

From report at bugs.python.org  Tue Apr 12 00:46:41 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Mon, 11 Apr 2011 22:46:41 +0000
Subject: [issue11829] inspect.getattr_static code execution with
	meta-metaclasses
In-Reply-To: <1302562001.85.0.31491141999.issue11829@psf.upfronthosting.co.za>
Message-ID: <1302562001.85.0.31491141999.issue11829@psf.upfronthosting.co.za>


New submission from Andreas St?hrk <andy-python at hammerhartes.de>:

The commit for issue #11133 omitted a part of the patch that checked whether the __dict__ attribute of metaclasses are shadowed. That makes it possible to trigger code execution in the case of metaclasses that have metaclasses.

Attached is a patch with a test and a fix.

----------
components: Library (Lib)
files: getattr_static_metaclasses.patch
keywords: patch
messages: 133549
nosy: Trundle, michael.foord
priority: normal
severity: normal
status: open
title: inspect.getattr_static code execution with meta-metaclasses
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21621/getattr_static_metaclasses.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11829>
_______________________________________

From report at bugs.python.org  Tue Apr 12 00:46:57 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 11 Apr 2011 22:46:57 +0000
Subject: [issue11830] "import decimal" fails in Turkish locale
In-Reply-To: <1302562017.26.0.78208251188.issue11830@psf.upfronthosting.co.za>
Message-ID: <1302562017.26.0.78208251188.issue11830@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

For Python 2 (here with 2.7.1):
$ python -c 'import locale; locale.setlocale(locale.LC_ALL, "tr_TR.UTF-8"); import decimal'

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib64/python2.7/decimal.py", line 3715, in <module>
    val = globals()[globalname]
KeyError: 'ROUND_CEiLiNG'

The issue is that 'round_ceiling'.upper() is 'ROUND_CEiLiNG' in the Turkish locale, rather than 'ROUND_CEILING', as one might expect.

A workaround for this may be to convert the str instances to unicode
first, then call upper on them, then convert back to str.

This would work since upper() for a unicode instance is locale-independent as
per issue 1528802.
(though there seems to have been some debate there).

Patch attached, though it doesn't yet contain a test case.

Only affects Python 2; with Python 3, the symbols are already stored as unicode internally.

Reported downstream as:
  https://bugzilla.redhat.com/show_bug.cgi?id=694928
which has links to various other reports on this

----------
components: Library (Lib)
files: decimal.py.patch
keywords: patch
messages: 133550
nosy: dmalcolm
priority: normal
severity: normal
status: open
title: "import decimal" fails in Turkish locale
versions: Python 2.7
Added file: http://bugs.python.org/file21622/decimal.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11830>
_______________________________________

From report at bugs.python.org  Tue Apr 12 00:48:04 2011
From: report at bugs.python.org (Torsten Becker)
Date: Mon, 11 Apr 2011 22:48:04 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1302562084.68.0.815813277112.issue11828@psf.upfronthosting.co.za>


Torsten Becker <torsten.becker at gmail.com> added the comment:

While working on this, I discovered anther problem.  find(), etc. all use the same parsing function (_ParseTupleFinds()).  So when an error occurs, the exception message will always start with "find()" even though index() or rfind() might have caused the error:

>>> "asd".index("x", None, None, None)
TypeError: find() takes at most 3 arguments (4 given)

I attached a patch (issue-8282-error-message-tests.patch) which adds test cases for the wrong error messages.

I was thinking about fixing this as well but wanted make sure my approach is correct first:

  - I would like to add another argument to _ParseTupleFinds(): const char * function_name
  - in _ParseTupleFinds(): allocate a buffer of 50 chars on the stack to hold "O|OO:" + function name
  - copy "O|OO:" into buffer
  - copy max(strlen(function_name), 44) chars from function_name into buffer
  - use buffer as format argument of PyArg_ParseTuple()
  - change all calls of _ParseTupleFinds to include the function name as first argument

Would that approach work with Python's C style or are there any Python-specific helper functions I could use?

----------
Added file: http://bugs.python.org/file21623/issue-8282-error-message-tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Tue Apr 12 01:01:38 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Apr 2011 23:01:38 +0000
Subject: [issue5162] multiprocessing cannot spawn child from a Windows service
In-Reply-To: <1233885632.9.0.0484597105973.issue5162@psf.upfronthosting.co.za>
Message-ID: <E1Q9Q6y-0002gQ-89@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 1f41b1ab8924 by brian.curtin in branch '3.1':
Fix #5162. Allow child spawning from Windows services (via pywin32).
http://hg.python.org/cpython/rev/1f41b1ab8924

New changeset 184ae02e3221 by brian.curtin in branch '3.2':
Fix #5162. Allow child spawning from Windows services (via pywin32).
http://hg.python.org/cpython/rev/184ae02e3221

New changeset 3c2bdea18b5c by brian.curtin in branch 'default':
Fix #5162. Allow child spawning from Windows services (via pywin32).
http://hg.python.org/cpython/rev/3c2bdea18b5c

New changeset 6507a5ba5c27 by brian.curtin in branch '2.7':
Fix #5162. Allow child spawning from Windows services (via pywin32).
http://hg.python.org/cpython/rev/6507a5ba5c27

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5162>
_______________________________________

From report at bugs.python.org  Tue Apr 12 01:02:39 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 11 Apr 2011 23:02:39 +0000
Subject: [issue5162] multiprocessing cannot spawn child from a Windows service
In-Reply-To: <1233885632.9.0.0484597105973.issue5162@psf.upfronthosting.co.za>
Message-ID: <1302562959.3.0.135407143504.issue5162@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Thanks for the patch!

----------
assignee: jnoller -> brian.curtin
resolution:  -> fixed
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5162>
_______________________________________

From report at bugs.python.org  Tue Apr 12 01:06:20 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 Apr 2011 23:06:20 +0000
Subject: [issue11830] "import decimal" fails in Turkish locale
In-Reply-To: <1302562017.26.0.78208251188.issue11830@psf.upfronthosting.co.za>
Message-ID: <1302563180.7.0.682314338367.issue11830@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11830>
_______________________________________

From report at bugs.python.org  Tue Apr 12 01:06:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Apr 2011 23:06:58 +0000
Subject: [issue5162] multiprocessing cannot spawn child from a Windows service
In-Reply-To: <1233885632.9.0.0484597105973.issue5162@psf.upfronthosting.co.za>
Message-ID: <E1Q9QC8-000343-Qs@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a280672d3d8d by brian.curtin in branch '2.7':
Add NEWS item for #5162.
http://hg.python.org/cpython/rev/a280672d3d8d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5162>
_______________________________________

From report at bugs.python.org  Tue Apr 12 01:20:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Apr 2011 23:20:08 +0000
Subject: [issue5162] multiprocessing cannot spawn child from a Windows service
In-Reply-To: <1233885632.9.0.0484597105973.issue5162@psf.upfronthosting.co.za>
Message-ID: <E1Q9QOt-0003yG-B7@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c26474c6504a by brian.curtin in branch '3.1':
Add NEWS item for #5162.
http://hg.python.org/cpython/rev/c26474c6504a

New changeset 68ef2bf1aa99 by brian.curtin in branch '3.2':
Add NEWS item for #5162.
http://hg.python.org/cpython/rev/68ef2bf1aa99

New changeset 2c4043070f05 by brian.curtin in branch 'default':
Add NEWS item for #5162.
http://hg.python.org/cpython/rev/2c4043070f05

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5162>
_______________________________________

From report at bugs.python.org  Tue Apr 12 02:28:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Apr 2011 00:28:07 +0000
Subject: [issue11830] "import decimal" fails in Turkish locale
In-Reply-To: <1302562017.26.0.78208251188.issue11830@psf.upfronthosting.co.za>
Message-ID: <E1Q9RSc-000098-PO@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset b4b1f557d563 by Raymond Hettinger in branch '2.7':
Issue #11830: Remove unnecessary introspection code in the decimal module.
http://hg.python.org/cpython/rev/b4b1f557d563

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11830>
_______________________________________

From report at bugs.python.org  Tue Apr 12 02:28:59 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Apr 2011 00:28:59 +0000
Subject: [issue11830] "import decimal" fails in Turkish locale
In-Reply-To: <1302562017.26.0.78208251188.issue11830@psf.upfronthosting.co.za>
Message-ID: <1302568139.89.0.0170050227295.issue11830@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11830>
_______________________________________

From report at bugs.python.org  Tue Apr 12 02:42:45 2011
From: report at bugs.python.org (Susam Pal)
Date: Tue, 12 Apr 2011 00:42:45 +0000
Subject: [issue11831] "python -w" causes "no Python documentation found" error
	when the path is not current directory
In-Reply-To: <1302568965.6.0.204734578124.issue11831@psf.upfronthosting.co.za>
Message-ID: <1302568965.6.0.204734578124.issue11831@psf.upfronthosting.co.za>


New submission from Susam Pal <susam at susam.in>:

Steps to reproduce:

susam at nifty:~/pydoc-test$ tree ../pydoc-subject/
../pydoc-subject/
|-- calc
|   |-- formulae.py
|   `-- __init__.py
|-- config.py
|-- default.conf
|-- main.py
`-- spal.conf

1 directory, 6 files

susam at nifty:~/pydoc-test$ pydoc -w ../pydoc-subject/
no Python documentation found for 'calc'
no Python documentation found for 'config'
no Python documentation found for 'main'

----------
components: Library (Lib)
messages: 133557
nosy: susam
priority: normal
severity: normal
status: open
title: "python -w" causes "no Python documentation found" error when the path is not current directory
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11831>
_______________________________________

From report at bugs.python.org  Tue Apr 12 02:46:54 2011
From: report at bugs.python.org (Susam Pal)
Date: Tue, 12 Apr 2011 00:46:54 +0000
Subject: [issue11831] "python -w" causes "no Python documentation found" error
	when the path is not current directory
In-Reply-To: <1302568965.6.0.204734578124.issue11831@psf.upfronthosting.co.za>
Message-ID: <1302569214.25.0.583741904.issue11831@psf.upfronthosting.co.za>


Susam Pal <susam at susam.in> added the comment:

Attached a one line fix that fixes this issue.

susam at nifty:~/pydoc-test$ pydoc -w ../pydoc-subject/
wrote calc.html
wrote calc.formulae.html
wrote config.html
wrote main.html
susam at nifty:~/pydoc-test$ ls
calc.formulae.html  calc.html  config.html  main.html

Diff:

--- /usr/lib/python2.7/pydoc.py.original	2011-04-12 04:56:19.000000000 +0530
+++ /usr/lib/python2.7/pydoc.py	2011-04-12 05:37:20.000000000 +0530
@@ -2299,6 +2299,7 @@
                 if ispath(arg) and os.path.isfile(arg):
                     arg = importfile(arg)
                 if writing:
+                    sys.path.insert(0, arg)
                     if ispath(arg) and os.path.isdir(arg):
                         writedocs(arg)
                     else:

----------
keywords: +patch
Added file: http://bugs.python.org/file21624/pydoc-27-syspath.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11831>
_______________________________________

From report at bugs.python.org  Tue Apr 12 03:08:05 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Apr 2011 01:08:05 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1302570485.27.0.790267826894.issue11828@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/issue11828>
_______________________________________

From report at bugs.python.org  Tue Apr 12 05:23:49 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 12 Apr 2011 03:23:49 +0000
Subject: [issue11832] Add option to pause regrtest to attach a debugger
In-Reply-To: <1302578628.99.0.388714550632.issue11832@psf.upfronthosting.co.za>
Message-ID: <1302578628.99.0.388714550632.issue11832@psf.upfronthosting.co.za>


New submission from Brian Curtin <brian at python.org>:

Patch to add -a/--attach option to Lib/test/regrtest.py to pause before beginning test runs. This would allow a user to attach Visual Studio or some other debugger. Very simply, this option just blocks waiting for a keystroke during argument parsing - once you're ready, hit any key.

My use case is with Visual Studio, where I've wanted to debug C code used by tests and would prefer to attach to an external command prompt, rather than have to initiate the test from within VS.

----------
assignee: brian.curtin
components: Tests
files: attach.diff
keywords: patch
messages: 133559
nosy: brian.curtin
priority: normal
severity: normal
stage: patch review
status: open
title: Add option to pause regrtest to attach a debugger
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file21625/attach.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11832>
_______________________________________

From report at bugs.python.org  Tue Apr 12 05:42:43 2011
From: report at bugs.python.org (Alec Taylor)
Date: Tue, 12 Apr 2011 03:42:43 +0000
Subject: [issue11833] ord() doesn't show complete UNICODE
In-Reply-To: <1302579763.25.0.785259570503.issue11833@psf.upfronthosting.co.za>
Message-ID: <1302579763.25.0.785259570503.issue11833@psf.upfronthosting.co.za>


New submission from Alec Taylor <alec.taylor6 at gmail.com>:

Unfortunately ord() doesn't show complete UNICODE. This can cause incorrectness problems.

>>> ord('?')
151
>>> ord('?')
165

Proof: Type Alt+0151, then type Alt+151. They should give you ? and ? respectively.

Please correct the UNICODE numbering.

Thanks,

Alec Taylor

----------
components: Unicode
messages: 133560
nosy: AlecTaylor
priority: normal
severity: normal
status: open
title: ord() doesn't show complete UNICODE
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11833>
_______________________________________

From report at bugs.python.org  Tue Apr 12 05:59:38 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Apr 2011 03:59:38 +0000
Subject: [issue11833] ord() doesn't show complete UNICODE
In-Reply-To: <1302579763.25.0.785259570503.issue11833@psf.upfronthosting.co.za>
Message-ID: <1302580778.65.0.398786686898.issue11833@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

For the chars you pasted, on Python 3 I get:
>>> ord('?')  # U+2014 EM DASH
8212
>>> ord('?')  # U+00A5 YEN SIGN
165

If I type alt+8212 I get '?' and if I type alt+0165 I get '?'.
What version of Python are you using and on what OS?

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11833>
_______________________________________

From report at bugs.python.org  Tue Apr 12 06:21:52 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 12 Apr 2011 04:21:52 +0000
Subject: [issue11818] tempfile.TemporaryFile example in docs doesnt work
In-Reply-To: <1302419439.43.0.340740214318.issue11818@psf.upfronthosting.co.za>
Message-ID: <1302582112.18.0.30224418086.issue11818@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

http://docs.python.org/release/3.1.3/library/tempfile.html doesn't to have an "Examples" section like 3.2 and 3.3.

It appears to have been introduced in b172d7537b99 with #5178.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11818>
_______________________________________

From report at bugs.python.org  Tue Apr 12 06:27:58 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 12 Apr 2011 04:27:58 +0000
Subject: [issue11827] mention of list2cmdline() in docs of subprocess.Popen
In-Reply-To: <1302511097.53.0.993242324349.issue11827@psf.upfronthosting.co.za>
Message-ID: <1302582478.84.0.555004563406.issue11827@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

#10838 has a bit of discussion about list2cmdline and being part of the public api (generally agreeing that it should be made private, I think).

----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11827>
_______________________________________

From report at bugs.python.org  Tue Apr 12 06:57:36 2011
From: report at bugs.python.org (Alec Taylor)
Date: Tue, 12 Apr 2011 04:57:36 +0000
Subject: [issue11833] ord() doesn't show complete UNICODE
In-Reply-To: <1302579763.25.0.785259570503.issue11833@psf.upfronthosting.co.za>
Message-ID: <1302584256.36.0.175674302727.issue11833@psf.upfronthosting.co.za>


Alec Taylor <alec.taylor6 at gmail.com> added the comment:

Python 2.7.1, Win7 64-bit

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11833>
_______________________________________

From report at bugs.python.org  Tue Apr 12 07:36:01 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Apr 2011 05:36:01 +0000
Subject: [issue11833] ord() doesn't show complete UNICODE
In-Reply-To: <1302579763.25.0.785259570503.issue11833@psf.upfronthosting.co.za>
Message-ID: <1302586561.27.0.270107773609.issue11833@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The problem is not with ord() but with the stdin encoding used by the windows terminal.
If you write a non-ASCII character (e.g. '?') in the windows terminal with Python 2 without using the u'' prefix, it will be encoded with the encoding specified by sys.stdin.encoding.  If this encoding is a single-byte encoding (e.g. cp850) the result for non-ASCII character might be misleading.
If you want the correct result use ord(u'?') and ord(u'?').

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11833>
_______________________________________

From report at bugs.python.org  Tue Apr 12 07:50:30 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 12 Apr 2011 05:50:30 +0000
Subject: [issue11827] mention of list2cmdline() in docs of subprocess.Popen
In-Reply-To: <1302511097.53.0.993242324349.issue11827@psf.upfronthosting.co.za>
Message-ID: <1302587430.75.0.239915440818.issue11827@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Thanks for the pointer, Ross. 

So I propose to remove the mention of list2cmdline from the documentation of subprocess, explaining instead what it does to the path (since I think this should be publicly known, otherwise it's just black magic). 

I will prepare a patch for this and post it for review here before committing.

Do you folks think we should also prepend an underscore to list2cmdline, thus settling the doubt about its "public-ness" once and for all? Other private functions in subprocess do have underscores prepended.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11827>
_______________________________________

From report at bugs.python.org  Tue Apr 12 07:52:57 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 12 Apr 2011 05:52:57 +0000
Subject: [issue10838] subprocess __all__ is incomplete
In-Reply-To: <1294260769.5.0.0970426129524.issue10838@psf.upfronthosting.co.za>
Message-ID: <1302587577.86.0.822095428494.issue10838@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Issue #11827 seems to be strongly related

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10838>
_______________________________________

From report at bugs.python.org  Tue Apr 12 08:26:55 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Apr 2011 06:26:55 +0000
Subject: [issue11827] mention of list2cmdline() in docs of subprocess.Popen
In-Reply-To: <1302511097.53.0.993242324349.issue11827@psf.upfronthosting.co.za>
Message-ID: <1302589615.07.0.276959700442.issue11827@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If a _ is added to list2cmdline the old name should be kept and deprecated.
The function is also on 2.x and it's not deprecated there (and it's probably too late to deprecate it now), so we might have to wait a few versions before it will be possible to remove list2cmdline from 3.x.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11827>
_______________________________________

From report at bugs.python.org  Tue Apr 12 08:28:10 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 12 Apr 2011 06:28:10 +0000
Subject: [issue11832] Add option to pause regrtest to attach a debugger
In-Reply-To: <1302578628.99.0.388714550632.issue11832@psf.upfronthosting.co.za>
Message-ID: <1302589690.17.0.266147012836.issue11832@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I can't judge if the functionality is needed, but I don't think the option should be called "attach" if all it does is input() somewhere...

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11832>
_______________________________________

From report at bugs.python.org  Tue Apr 12 11:12:01 2011
From: report at bugs.python.org (Catalin Iacob)
Date: Tue, 12 Apr 2011 09:12:01 +0000
Subject: [issue7484] smtplib: verify breaks with Postfix servers
In-Reply-To: <1260600956.23.0.0101749869854.issue7484@psf.upfronthosting.co.za>
Message-ID: <1302599521.38.0.697516308868.issue7484@psf.upfronthosting.co.za>


Changes by Catalin Iacob <iacobcatalin at gmail.com>:


----------
nosy: +catalin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7484>
_______________________________________

From report at bugs.python.org  Tue Apr 12 11:23:34 2011
From: report at bugs.python.org (Torsten Becker)
Date: Tue, 12 Apr 2011 09:23:34 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1302600214.88.0.231115114476.issue11828@psf.upfronthosting.co.za>


Torsten Becker <torsten.becker at gmail.com> added the comment:

Just realized that part of my v1 patch did not conform to PEP 7, I hope, I fixed that in v2.

Please also excuse for the wrong name of the error message patch, it was supposed to be named "issue-11828-error-msg-tests.patch".

----------
Added file: http://bugs.python.org/file21626/issue-11828-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Tue Apr 12 11:24:43 2011
From: report at bugs.python.org (Torsten Becker)
Date: Tue, 12 Apr 2011 09:24:43 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1302600283.3.0.899441006756.issue11828@psf.upfronthosting.co.za>


Changes by Torsten Becker <torsten.becker at gmail.com>:


Added file: http://bugs.python.org/file21627/issue-11828-error-msg-tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Tue Apr 12 11:24:58 2011
From: report at bugs.python.org (Torsten Becker)
Date: Tue, 12 Apr 2011 09:24:58 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1302600298.94.0.350235994433.issue11828@psf.upfronthosting.co.za>


Changes by Torsten Becker <torsten.becker at gmail.com>:


Removed file: http://bugs.python.org/file21623/issue-8282-error-message-tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Tue Apr 12 12:47:36 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 12 Apr 2011 10:47:36 +0000
Subject: [issue11834] wrong module installation dir on Windows
In-Reply-To: <1302605256.31.0.234550103785.issue11834@psf.upfronthosting.co.za>
Message-ID: <1302605256.31.0.234550103785.issue11834@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

http://docs.python.org/install/index.html#how-installation-works

Correct standard installation location for third-party modules on Windows for Python 2.x is
    prefix/Lib/site-packages

----------
assignee: docs at python
components: Documentation
messages: 133571
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: wrong module installation dir on Windows
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11834>
_______________________________________

From report at bugs.python.org  Tue Apr 12 12:48:27 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Apr 2011 10:48:27 +0000
Subject: [issue11834] wrong module installation dir on Windows
In-Reply-To: <1302605256.31.0.234550103785.issue11834@psf.upfronthosting.co.za>
Message-ID: <1302605307.2.0.549320143604.issue11834@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11834>
_______________________________________

From report at bugs.python.org  Tue Apr 12 13:12:05 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 12 Apr 2011 11:12:05 +0000
Subject: [issue11834] wrong module installation dir on Windows
In-Reply-To: <1302605256.31.0.234550103785.issue11834@psf.upfronthosting.co.za>
Message-ID: <1302606725.35.0.913061702265.issue11834@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Other Windows prefixes are probably wrong too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11834>
_______________________________________

From report at bugs.python.org  Tue Apr 12 13:45:25 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Apr 2011 11:45:25 +0000
Subject: [issue11313] Speed up default encode()/decode()
In-Reply-To: <1298586589.12.0.407554806858.issue11313@psf.upfronthosting.co.za>
Message-ID: <1302608725.66.0.907112819819.issue11313@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> Committed issue11313.diff in revision 88553.

The revision number seems to be wrong -- maybe the commit got lost during the mercurial migration.

All the changes of the patch seem to be there though, even if they went in with other commits:
  unicodeobjects.c: 7ab569b18c98 together with changes from #11303.
  test_bytes.py: be6c38d1817b together with the normalization of encoding names.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11313>
_______________________________________

From report at bugs.python.org  Tue Apr 12 14:32:04 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 12 Apr 2011 12:32:04 +0000
Subject: [issue11834] wrong module installation dir on Windows
In-Reply-To: <1302605256.31.0.234550103785.issue11834@psf.upfronthosting.co.za>
Message-ID: <1302611524.47.0.196157376602.issue11834@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11834>
_______________________________________

From report at bugs.python.org  Tue Apr 12 14:39:33 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Apr 2011 12:39:33 +0000
Subject: [issue9233] json.load failure when C optimizations aren't built
In-Reply-To: <1278949665.57.0.214129757073.issue9233@psf.upfronthosting.co.za>
Message-ID: <1302611973.3.0.521731524225.issue9233@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I ran the tests again on 2.7 and got 3 failures:

======================================================================
ERROR: test_c_scanstring (json.tests.test_scanstring.TestScanString)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/wolf/dev/py/issue9233/Lib/json/tests/test_scanstring.py", line 13, in test_c_scanstring
    self._test_scanstring(json.decoder.c_scanstring)
  File "/home/wolf/dev/py/issue9233/Lib/json/tests/test_scanstring.py", line 17, in _test_scanstring
    scanstring('"z\\ud834\\udd20x"', 1, None, True),
TypeError: 'NoneType' object is not callable

======================================================================
FAIL: test_encode_basestring_ascii (json.tests.test_speedups.TestSpeedups)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/wolf/dev/py/issue9233/Lib/json/tests/test_speedups.py", line 14, in test_encode_basestring_ascii
    self.assertEqual(encoder.encode_basestring_ascii.__module__, "_json")
AssertionError: 'json.encoder' != '_json'

======================================================================
FAIL: test_scanstring (json.tests.test_speedups.TestSpeedups)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/wolf/dev/py/issue9233/Lib/json/tests/test_speedups.py", line 11, in test_scanstring
    self.assertTrue(decoder.scanstring is decoder.c_scanstring)
AssertionError: False is not true


The attached patch checks if _json is importable and skip the tests if it's not.

----------
Added file: http://bugs.python.org/file21628/issue9233.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9233>
_______________________________________

From report at bugs.python.org  Tue Apr 12 14:50:52 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 12 Apr 2011 12:50:52 +0000
Subject: [issue11834] wrong module installation dir on Windows
In-Reply-To: <1302605256.31.0.234550103785.issue11834@psf.upfronthosting.co.za>
Message-ID: <1302612652.39.0.431836705595.issue11834@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

How about 'easy' keyword?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11834>
_______________________________________

From report at bugs.python.org  Tue Apr 12 14:51:20 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Apr 2011 12:51:20 +0000
Subject: [issue11834] wrong module installation dir on Windows
In-Reply-To: <1302605256.31.0.234550103785.issue11834@psf.upfronthosting.co.za>
Message-ID: <1302612680.81.0.955668741667.issue11834@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11834>
_______________________________________

From report at bugs.python.org  Tue Apr 12 14:52:48 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 Apr 2011 12:52:48 +0000
Subject: [issue11834] wrong module installation dir on Windows
In-Reply-To: <1302605256.31.0.234550103785.issue11834@psf.upfronthosting.co.za>
Message-ID: <1302612768.05.0.636965395892.issue11834@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It's a doc issue.  Doc issues are pretty much by definition easy in the sense of the easy keyword (doable in a day) (unless they are controversial), so we don't bother to attach the easy keyword to them.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11834>
_______________________________________

From report at bugs.python.org  Tue Apr 12 15:00:28 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 12 Apr 2011 13:00:28 +0000
Subject: [issue11834] wrong module installation dir on Windows
In-Reply-To: <1302605256.31.0.234550103785.issue11834@psf.upfronthosting.co.za>
Message-ID: <1302613228.94.0.380134157704.issue11834@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Target auditory for the `easy` keyword are largely unaware of this fact. It also may keep people off if they run into uneasy doc problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11834>
_______________________________________

From report at bugs.python.org  Tue Apr 12 15:04:08 2011
From: report at bugs.python.org (Torsten Becker)
Date: Tue, 12 Apr 2011 13:04:08 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1302613448.76.0.163444271651.issue11828@psf.upfronthosting.co.za>


Torsten Becker <torsten.becker at gmail.com> added the comment:

Hi, since nobody stopped me by complaining about the approach or the first patch, I now fixed this for bytes and bytearray as well. :)

I renamed the old _ParseTupleFinds function to stringlib_parse_tuple_finds, added a parameter for function name, and another if it shall do unicode conversion.  I used this helper function throughout all 3 files now.

I am new to writing C code for Python, so any comments on how to improve the patch are welcome.

----------
Added file: http://bugs.python.org/file21629/issue-11828-v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Tue Apr 12 15:07:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Apr 2011 13:07:29 +0000
Subject: [issue9233] json.load failure when C optimizations aren't built
In-Reply-To: <1278949665.57.0.214129757073.issue9233@psf.upfronthosting.co.za>
Message-ID: <E1Q9dJX-0008IH-Rs@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 500063f6ae5a by Ezio Melotti in branch '2.7':
#9233: skip _json-specific tests when _json is not available.
http://hg.python.org/cpython/rev/500063f6ae5a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9233>
_______________________________________

From report at bugs.python.org  Tue Apr 12 15:08:16 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 12 Apr 2011 13:08:16 +0000
Subject: [issue11834] wrong module installation dir on Windows
In-Reply-To: <1302605256.31.0.234550103785.issue11834@psf.upfronthosting.co.za>
Message-ID: <1302613696.89.0.756218038013.issue11834@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
nosy:  -brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11834>
_______________________________________

From report at bugs.python.org  Tue Apr 12 15:09:01 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Apr 2011 13:09:01 +0000
Subject: [issue9233] json.load failure when C optimizations aren't built
In-Reply-To: <1278949665.57.0.214129757073.issue9233@psf.upfronthosting.co.za>
Message-ID: <1302613741.81.0.505444851224.issue9233@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> ezio.melotti
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9233>
_______________________________________

From report at bugs.python.org  Tue Apr 12 15:12:30 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 12 Apr 2011 13:12:30 +0000
Subject: [issue11832] Add option to pause regrtest to attach a debugger
In-Reply-To: <1302578628.99.0.388714550632.issue11832@psf.upfronthosting.co.za>
Message-ID: <1302613950.18.0.873963829075.issue11832@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

True. In the end all it does is wait for input not specific to attaching debuggers. How about ``--wait``?


I'm used to this functionality being `-x` in another app, so we're iteratively getting better :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11832>
_______________________________________

From report at bugs.python.org  Tue Apr 12 15:52:52 2011
From: report at bugs.python.org (Ben Bass)
Date: Tue, 12 Apr 2011 13:52:52 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1302616372.35.0.53865462248.issue1692335@psf.upfronthosting.co.za>


Ben Bass <benpaulbass at googlemail.com> added the comment:

Perhaps this should be addressed separately, but subprocess.CalledProcessError is subject to this problem (can't be unpickled) (it has separate returncode and cmd attributes, but no args).

It's straightforward to conform user-defined Exceptions to including .args and having reasonable __init__ functions, but not possible in the case of stdlib exceptions.

>>> import subprocess, pickle
>>> try:
...   subprocess.check_call('/bin/false')
... except Exception as e:
...   pickle.loads(pickle.dumps(e))
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/usr/lib/python3.1/subprocess.py", line 435, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '/bin/false' returned non-zero exit status 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
  File "/usr/lib/python3.1/pickle.py", line 1363, in loads
    encoding=encoding, errors=errors).load()
TypeError: __init__() takes at least 3 positional arguments (1 given)

----------
nosy: +bpb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Tue Apr 12 16:01:44 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 12 Apr 2011 14:01:44 +0000
Subject: [issue11830] "import decimal" fails in Turkish locale
In-Reply-To: <1302562017.26.0.78208251188.issue11830@psf.upfronthosting.co.za>
Message-ID: <1302616904.35.0.802771246345.issue11830@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Shouldn't this be forward ported to 3.3?  Even though there is no bug in 3.x, code using an explicit dict is cleaner and more robust than the current code that relies on introspection to find methods that start with '_round_'.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11830>
_______________________________________

From report at bugs.python.org  Tue Apr 12 16:09:47 2011
From: report at bugs.python.org (Catalin Iacob)
Date: Tue, 12 Apr 2011 14:09:47 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1302617387.95.0.991437014118.issue3244@psf.upfronthosting.co.za>


Changes by Catalin Iacob <iacobcatalin at gmail.com>:


----------
nosy: +catalin.iacob

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3244>
_______________________________________

From report at bugs.python.org  Tue Apr 12 17:39:26 2011
From: report at bugs.python.org (Abraham Soedjito)
Date: Tue, 12 Apr 2011 15:39:26 +0000
Subject: [issue11835] python (x64) ctypes incorrectly pass structures parameter
In-Reply-To: <1302622766.46.0.0398461644853.issue11835@psf.upfronthosting.co.za>
Message-ID: <1302622766.46.0.0398461644853.issue11835@psf.upfronthosting.co.za>


New submission from Abraham Soedjito <abraham.soedjito at gmail.com>:

void __cdecl foo(unsigned __int32 a,
                 unsigned __int32 b,
                 unsigned __int32 c,
                 unsigned __int32 d,
                 unsigned __int32 e,
                 unsigned __int32 f,
                 unsigned __int32 g);

struct myStruct
{
   unsigned __int32 a;
   unsigned __int32 b;
   unsigned __int32 c;
   unsigned __int32 d;
   unsigned __int32 e;
   unsigned __int32 f;
   unsigned __int32 g;
}
void __cdecl bar(myStruct s);

void __cdecl errorPassingParameter(myStruct s1,
                                   myStruct s2,
                                   unsigned __int32 x);    

Calling foo and bar from python completed successfully, calling errorParsingParameter resulted in stack corruption. It seems that python passed an extra pointer in the stack for s2.

----------
assignee: theller
components: ctypes
messages: 133583
nosy: Abraham.Soedjito, theller
priority: normal
severity: normal
status: open
title: python (x64) ctypes incorrectly pass structures parameter
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11835>
_______________________________________

From report at bugs.python.org  Tue Apr 12 17:50:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Apr 2011 15:50:31 +0000
Subject: [issue11815] Simplifications in concurrent.futures
In-Reply-To: <1302392267.12.0.152242610702.issue11815@psf.upfronthosting.co.za>
Message-ID: <E1Q9frH-0007Cx-CF@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset bfc586c558ed by Antoine Pitrou in branch '3.2':
Issue #11815: Remove dead code in concurrent.futures (since a blocking Queue
http://hg.python.org/cpython/rev/bfc586c558ed

New changeset eb751e3cb753 by Antoine Pitrou in branch 'default':
Issue #11815: Remove dead code in concurrent.futures (since a blocking Queue
http://hg.python.org/cpython/rev/eb751e3cb753

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11815>
_______________________________________

From report at bugs.python.org  Tue Apr 12 17:54:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Apr 2011 15:54:15 +0000
Subject: [issue11827] mention of list2cmdline() in docs of subprocess.Popen
In-Reply-To: <1302511097.53.0.993242324349.issue11827@psf.upfronthosting.co.za>
Message-ID: <1302623655.23.0.799212838016.issue11827@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11827>
_______________________________________

From report at bugs.python.org  Tue Apr 12 17:55:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Apr 2011 15:55:34 +0000
Subject: [issue11818] tempfile.TemporaryFile example in docs doesnt work
In-Reply-To: <1302419439.43.0.340740214318.issue11818@psf.upfronthosting.co.za>
Message-ID: <1302623734.4.0.930514372315.issue11818@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Alright, thanks for replying :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11818>
_______________________________________

From report at bugs.python.org  Tue Apr 12 17:56:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Apr 2011 15:56:25 +0000
Subject: [issue11836] multiprocessing.queues.SimpleQueue is undocumented
In-Reply-To: <1302623785.46.0.16009713021.issue11836@psf.upfronthosting.co.za>
Message-ID: <1302623785.46.0.16009713021.issue11836@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

multiprocessing.queues.SimpleQueue is undocumented and doesn't appear in multiprocessing.__all__.

----------
assignee: docs at python
components: Documentation, Library (Lib)
keywords: easy
messages: 133586
nosy: docs at python, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: multiprocessing.queues.SimpleQueue is undocumented
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11836>
_______________________________________

From report at bugs.python.org  Tue Apr 12 17:58:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Apr 2011 15:58:17 +0000
Subject: [issue11815] Simplifications in concurrent.futures
In-Reply-To: <1302392267.12.0.152242610702.issue11815@psf.upfronthosting.co.za>
Message-ID: <E1Q9fyq-0007o7-1V@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c26d015cbde8 by Antoine Pitrou in branch 'default':
Issue #11815: Use a light-weight SimpleQueue for the result queue in concurrent.futures.ProcessPoolExecutor.
http://hg.python.org/cpython/rev/c26d015cbde8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11815>
_______________________________________

From report at bugs.python.org  Tue Apr 12 18:01:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Apr 2011 16:01:33 +0000
Subject: [issue11815] Simplifications in concurrent.futures
In-Reply-To: <1302392267.12.0.152242610702.issue11815@psf.upfronthosting.co.za>
Message-ID: <1302624093.61.0.318113970837.issue11815@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/issue11815>
_______________________________________

From report at bugs.python.org  Tue Apr 12 18:06:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Apr 2011 16:06:12 +0000
Subject: [issue11830] "import decimal" fails in Turkish locale
In-Reply-To: <1302562017.26.0.78208251188.issue11830@psf.upfronthosting.co.za>
Message-ID: <E1Q9g6T-0000B3-T1@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f4adc2926bf5 by Raymond Hettinger in branch '2.7':
Neaten-up the fix to issue 11830
http://hg.python.org/cpython/rev/f4adc2926bf5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11830>
_______________________________________

From report at bugs.python.org  Tue Apr 12 18:08:30 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Apr 2011 16:08:30 +0000
Subject: [issue11830] "import decimal" fails in Turkish locale
In-Reply-To: <1302562017.26.0.78208251188.issue11830@psf.upfronthosting.co.za>
Message-ID: <1302624510.82.0.649471360163.issue11830@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

+0 on forward porting

----------
assignee: rhettinger -> belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11830>
_______________________________________

From report at bugs.python.org  Tue Apr 12 18:13:40 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 Apr 2011 16:13:40 +0000
Subject: [issue11830] "import decimal" fails in Turkish locale
In-Reply-To: <1302562017.26.0.78208251188.issue11830@psf.upfronthosting.co.za>
Message-ID: <1302624820.84.0.184710397675.issue11830@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +mark.dickinson, skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11830>
_______________________________________

From report at bugs.python.org  Tue Apr 12 18:20:08 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 12 Apr 2011 16:20:08 +0000
Subject: [issue11835] python (x64) ctypes incorrectly pass structures parameter
In-Reply-To: <1302622766.46.0.0398461644853.issue11835@psf.upfronthosting.co.za>
Message-ID: <1302625208.93.0.452512390102.issue11835@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11835>
_______________________________________

From report at bugs.python.org  Tue Apr 12 19:09:21 2011
From: report at bugs.python.org (Axel Rau)
Date: Tue, 12 Apr 2011 17:09:21 +0000
Subject: [issue11837] smtplib._quote_periods triggers spurious type error in
	re.sub
In-Reply-To: <1302628161.84.0.82021620589.issue11837@psf.upfronthosting.co.za>
Message-ID: <1302628161.84.0.82021620589.issue11837@psf.upfronthosting.co.za>


New submission from Axel Rau <Axel.Rau at Chaos1.DE>:

While debugging this
  http://article.gmane.org/gmane.comp.python.general/687767
email problem, I'm getting:
---
 File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/smtplib.py", line 794, in send_message
    rcpt_options)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/smtplib.py", line 762, in sendmail
    (code, resp) = self.data(msg)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/smtplib.py", line 518, in data
    q = _quote_periods(msg)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/smtplib.py", line 166, in _quote_periods
    return re.sub(br'(?m)^\.', '..', bindata)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/re.py", line 168, in sub
    return _compile(pattern, flags).sub(repl, string, count)
TypeError: sequence item 1: expected bytes, str found
---
The following instrumentation:
---
def sub(pattern, repl, string, count=0, flags=0):
    print('re.sub: pattern=%s, repl=%s, string=%s' % (pattern.__class__.__name__, repl.__class__.__name__, string.__class__.__name__))
    return _compile(pattern, flags).sub(repl, string, count)
---
shows (in my test case with 2nd mail):
---
re.sub: pattern=bytes, repl=str, string=bytes
---
Changing smtplib._quote_periods(bindata) from
---
def _quote_periods(bindata):
    return re.sub(br'(?m)^\.', '..', bindata)
---
to:
---
def _quote_periods(bindata):
    return re.sub(br'(?m)^\.', b'..', bindata)
---
Fixes the problem for me.

Platform is Mac OS X 10.6.7, 64-bit.
Problem happens always on 2nd mail being sent.
Problem still exists with python 3.2.1a

----------
components: Library (Lib)
messages: 133590
nosy: axel
priority: normal
severity: normal
status: open
title: smtplib._quote_periods triggers spurious type error in re.sub
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11837>
_______________________________________

From report at bugs.python.org  Tue Apr 12 19:22:12 2011
From: report at bugs.python.org (Axel Rau)
Date: Tue, 12 Apr 2011 17:22:12 +0000
Subject: [issue11837] smtplib._quote_periods triggers spurious type error in
	re.sub
In-Reply-To: <1302628161.84.0.82021620589.issue11837@psf.upfronthosting.co.za>
Message-ID: <1302628932.72.0.235678813748.issue11837@psf.upfronthosting.co.za>


Changes by Axel Rau <Axel.Rau at Chaos1.DE>:


----------
type: behavior -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11837>
_______________________________________

From report at bugs.python.org  Tue Apr 12 19:56:44 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 12 Apr 2011 17:56:44 +0000
Subject: [issue11836] multiprocessing.queues.SimpleQueue is undocumented
In-Reply-To: <1302623785.46.0.16009713021.issue11836@psf.upfronthosting.co.za>
Message-ID: <1302631004.24.0.0662237448583.issue11836@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11836>
_______________________________________

From report at bugs.python.org  Tue Apr 12 20:00:33 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 12 Apr 2011 18:00:33 +0000
Subject: [issue11835] python (x64) ctypes incorrectly pass structures parameter
In-Reply-To: <1302622766.46.0.0398461644853.issue11835@psf.upfronthosting.co.za>
Message-ID: <1302631233.15.0.0343160936163.issue11835@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

I can reproduce this with 2.7 and 3.2 64-bit builds on Windows:

D:\Temp\cdll\x64\Release>C:\Python32\python.exe
Python 3.2 (r32:88445, Feb 20 2011, 21:30:00) [MSC v.1500 64 bit (AMD64)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *
>>> libcdll = CDLL('cdll')
>>> libcdll.foo(1, 2, 3, 4, 5, 6, 7)
a: 1; b: 2; c: 3; d: 4; e: 5; f: 6; g: 7
0
>>> class MyStruct(Structure):
...     _fields_ = [
... ('a', c_int32),
... ('b', c_int32),
... ('c', c_int32),
... ('d', c_int32),
... ('e', c_int32),
... ('f', c_int32),
... ('g', c_int32),
... ]
...
>>> s1 = MyStruct(1, 2, 3, 4, 5, 6, 7)
>>> s2 = MyStruct(0, 9, 8, 7, 6, 5, 4)
>>> libcdll.bar(s2)
s.a: 0; s.b: 9; s.c: 8; s.d: 7; s.e: 6; s.f: 5; s.g: 4
0
>>> libcdll.errorPassingParameter(s1, s2, 42)
s1.a: 1; s1.b: 2; s1.c: 3; s1.d: 4; s1.e: 5; s1.f: 6; s1.g: 7
s2.a: 28; s2.b: 0; s2.c: 851972; s2.d: 0; s2.e: 31545776; s2.f: 0; s2.g: 0
x: 39805032
0
>>>

----------
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11835>
_______________________________________

From report at bugs.python.org  Tue Apr 12 20:03:09 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 12 Apr 2011 18:03:09 +0000
Subject: [issue11838] IDLE: make interactive code runnable.
In-Reply-To: <1302631389.12.0.305553029462.issue11838@psf.upfronthosting.co.za>
Message-ID: <1302631389.12.0.305553029462.issue11838@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

One can currently save the contents of a shell window exactly as is, with opening message, prompts, and restarts. This essentially a screenshot of the frame -- fine for an IDLE doc but not useful for rerunning the code.
Similarly, if one pastes in interactive input/output, with or without secondary prompts, into an edit window, it is a nuisance to edit.

This issue proposes an option to 'flip' code and output lines, with prompts deleted and outputs commented, so that

Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> 1+2
3

becomes

#Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32
#Type "copyright", "credits" or "license()" for more information.
1+2
#3

(Ignore linewrap artifact on first line).

----------
components: IDLE
messages: 133592
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: make interactive code runnable.
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11838>
_______________________________________

From report at bugs.python.org  Tue Apr 12 20:06:31 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 12 Apr 2011 18:06:31 +0000
Subject: [issue11835] python (x64) ctypes incorrectly pass structures parameter
In-Reply-To: <1302622766.46.0.0398461644853.issue11835@psf.upfronthosting.co.za>
Message-ID: <1302631591.3.0.329990747568.issue11835@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

32-bit (2.6) is fine:

D:\Temp\cdll\Release>C:\Python26\python.exe
Python 2.6.6 (r266:84297, Aug 24 2010, 18:46:32) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *
>>> libcdll = CDLL('cdll')
>>> class MyStruct(Structure):
...     _fields_ = []
...     for name in ('a', 'b', 'c', 'd', 'e', 'f', 'g'):
...         _fields_.append((name, c_int32))
...
>>> MyStruct._fields_
[('a', <class 'ctypes.c_long'>), ('b', <class 'ctypes.c_long'>), ('c', <class 'c
types.c_long'>), ('d', <class 'ctypes.c_long'>), ('e', <class 'ctypes.c_long'>),
 ('f', <class 'ctypes.c_long'>), ('g', <class 'ctypes.c_long'>)]
>>> s1 = MyStruct(1, 2, 3, 4, 5, 6, 7)
>>> s2 = MyStruct(0, 9, 8, 7, 6, 5, 4)
>>> libcdll.errorPassingParameter(s1, s2, 42)
s1.a: 1; s1.b: 2; s1.c: 3; s1.d: 4; s1.e: 5; s1.f: 6; s1.g: 7
s2.a: 0; s2.b: 9; s2.c: 8; s2.d: 7; s2.e: 6; s2.f: 5; s2.g: 4
x: 42
0
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11835>
_______________________________________

From report at bugs.python.org  Tue Apr 12 20:13:19 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 12 Apr 2011 18:13:19 +0000
Subject: [issue10019] json.dumps with indent = 0 not adding newlines
In-Reply-To: <1286122957.24.0.240376565719.issue10019@psf.upfronthosting.co.za>
Message-ID: <1302631999.7.0.465492440623.issue10019@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi,
I updated the patch, making one for 2.7, 3.1 and 3.2 (this last one applies cleanly on default too).

As of merging simplejson, it's more a matter of porting it to Python 3. I'll drop an email to Bob soon, let's see how it goes.

----------
nosy: +sandro.tosi
stage: patch review -> commit review
versions: +Python 3.3
Added file: http://bugs.python.org/file21630/issue10019-py3.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10019>
_______________________________________

From report at bugs.python.org  Tue Apr 12 20:13:36 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 12 Apr 2011 18:13:36 +0000
Subject: [issue10019] json.dumps with indent = 0 not adding newlines
In-Reply-To: <1286122957.24.0.240376565719.issue10019@psf.upfronthosting.co.za>
Message-ID: <1302632016.71.0.139891803357.issue10019@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


Added file: http://bugs.python.org/file21631/issue10019-py3.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10019>
_______________________________________

From report at bugs.python.org  Tue Apr 12 20:13:48 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 12 Apr 2011 18:13:48 +0000
Subject: [issue10019] json.dumps with indent = 0 not adding newlines
In-Reply-To: <1286122957.24.0.240376565719.issue10019@psf.upfronthosting.co.za>
Message-ID: <1302632028.57.0.525315382249.issue10019@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


Added file: http://bugs.python.org/file21632/issue10019-py2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10019>
_______________________________________

From report at bugs.python.org  Tue Apr 12 20:15:18 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 12 Apr 2011 18:15:18 +0000
Subject: [issue10019] json.dumps with indent = 0 not adding newlines
In-Reply-To: <1286122957.24.0.240376565719.issue10019@psf.upfronthosting.co.za>
Message-ID: <1302632118.1.0.827814123592.issue10019@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Oh, just to say I took the version as of http://code.google.com/p/simplejson/source/detail?r=234

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10019>
_______________________________________

From report at bugs.python.org  Tue Apr 12 20:19:37 2011
From: report at bugs.python.org (Jonathan White)
Date: Tue, 12 Apr 2011 18:19:37 +0000
Subject: [issue11835] python (x64) ctypes incorrectly pass structures parameter
In-Reply-To: <1302622766.46.0.0398461644853.issue11835@psf.upfronthosting.co.za>
Message-ID: <1302632378.0.0.467891588577.issue11835@psf.upfronthosting.co.za>


Changes by Jonathan White <jonathan.white at ni.com>:


----------
nosy: +jwhitecl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11835>
_______________________________________

From report at bugs.python.org  Tue Apr 12 20:46:35 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 12 Apr 2011 18:46:35 +0000
Subject: [issue11835] python (x64) ctypes incorrectly pass structures parameter
In-Reply-To: <1302622766.46.0.0398461644853.issue11835@psf.upfronthosting.co.za>
Message-ID: <1302633995.51.0.474694745033.issue11835@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

Attaching a ctypes unittest (against 2.7 branch) that will expose this bug in regrtest.

----------
keywords: +patch
Added file: http://bugs.python.org/file21633/test_issue11835.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11835>
_______________________________________

From report at bugs.python.org  Tue Apr 12 20:59:14 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 12 Apr 2011 18:59:14 +0000
Subject: [issue9233] json.load failure when C optimizations aren't built
In-Reply-To: <1278949665.57.0.214129757073.issue9233@psf.upfronthosting.co.za>
Message-ID: <1302634754.65.0.619789563746.issue9233@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Do those new check finish this issue and should it be closed?
If not, what is left?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9233>
_______________________________________

From report at bugs.python.org  Tue Apr 12 21:56:30 2011
From: report at bugs.python.org (Paolo Elvati)
Date: Tue, 12 Apr 2011 19:56:30 +0000
Subject: [issue11839] argparse: unexpected behavior of default for
	FileType('w')
In-Reply-To: <1302638190.31.0.523851627026.issue11839@psf.upfronthosting.co.za>
Message-ID: <1302638190.31.0.523851627026.issue11839@psf.upfronthosting.co.za>


New submission from Paolo Elvati <elvati at umich.edu>:

Hi,
when a default is specified for a file argument that is open with writing permission (FileType('w')), the default file is always created even if the argument is specified in the command line. 
For example he code:

import argparse 
parser = argparse.ArgumentParser() 
parser.add_argument( 
"-o", 
default = 'fake', 
dest = 'OutputFile', 
type = argparse.FileType('w') 
) 
args = parser.parse_args() 

will create the empty file "fake" even if the -o option is given. 
The value inside the code of args.Outputfile is not affected.

Paolo

----------
components: Library (Lib)
messages: 133598
nosy: Paolo.Elvati, bethard
priority: normal
severity: normal
status: open
title: argparse: unexpected behavior of default for FileType('w')
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11839>
_______________________________________

From report at bugs.python.org  Tue Apr 12 22:18:53 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 12 Apr 2011 20:18:53 +0000
Subject: [issue11827] mention of list2cmdline() in docs of subprocess.Popen
In-Reply-To: <1302511097.53.0.993242324349.issue11827@psf.upfronthosting.co.za>
Message-ID: <1302639533.22.0.535305187589.issue11827@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Attaching a proposed patch for 3.2, focusing only on the documentation for the time being (I realize that deprecation is a loaded issue and should be probably handled in a centralized manner).

The patch removes mention of list2cmdline, instead explaining its intention (using the docstring of list2cmdline quite literally). I realize this isn't an ideal approach, but IMHO it's much better than what we have now. Suggestions are most welcome.

----------
keywords: +patch
Added file: http://bugs.python.org/file21634/issue11827.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11827>
_______________________________________

From report at bugs.python.org  Tue Apr 12 22:26:12 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 12 Apr 2011 20:26:12 +0000
Subject: [issue11806] Missing 2 hyphens in the docs
In-Reply-To: <1302338197.1.0.100311254016.issue11806@psf.upfronthosting.co.za>
Message-ID: <1302639972.4.0.449898257318.issue11806@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11806>
_______________________________________

From report at bugs.python.org  Tue Apr 12 23:19:32 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 12 Apr 2011 21:19:32 +0000
Subject: [issue11840] Improvements to c-api/unicode documentation
In-Reply-To: <1302643172.01.0.948666081662.issue11840@psf.upfronthosting.co.za>
Message-ID: <1302643172.01.0.948666081662.issue11840@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hi,
After reading tomo cocoa mail at docs@ I gave a look at c-api/unicode file and fixed some minor editing issues.

Regards,
Sandro

----------
assignee: docs at python
components: Documentation
files: unicode_doc-default.patch
keywords: patch
messages: 133600
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Improvements to c-api/unicode documentation
versions: Python 3.3
Added file: http://bugs.python.org/file21635/unicode_doc-default.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11840>
_______________________________________

From report at bugs.python.org  Tue Apr 12 23:21:27 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 12 Apr 2011 21:21:27 +0000
Subject: [issue11840] Improvements to c-api/unicode documentation
In-Reply-To: <1302643172.01.0.948666081662.issue11840@psf.upfronthosting.co.za>
Message-ID: <1302643287.14.0.889819232295.issue11840@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

In addition, is there a reason for the sorting of UTF-8 UTF-32 UTF-16 and UTF-7 sections? why not alphabetically?

Also, several parts of the doc would need paragraph re-indentation (not done in this patch due to clarity).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11840>
_______________________________________

From report at bugs.python.org  Tue Apr 12 23:22:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2011 21:22:36 +0000
Subject: [issue11840] Improvements to c-api/unicode documentation
In-Reply-To: <1302643172.01.0.948666081662.issue11840@psf.upfronthosting.co.za>
Message-ID: <1302643356.88.0.470026444528.issue11840@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11840>
_______________________________________

From report at bugs.python.org  Tue Apr 12 23:34:23 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 12 Apr 2011 21:34:23 +0000
Subject: [issue11840] Improvements to c-api/unicode documentation
In-Reply-To: <1302643287.14.0.889819232295.issue11840@psf.upfronthosting.co.za>
Message-ID: <4DA4C55A.50400@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Sandro Tosi wrote:
> 
> Sandro Tosi <sandro.tosi at gmail.com> added the comment:
> 
> In addition, is there a reason for the sorting of UTF-8 UTF-32 UTF-16 and UTF-7 sections? why not alphabetically?

No particular reason. Alphabetical order would be just as good.

Note that such changes would have to be backported in order to
keep the merge conflicts to a minimum.

> Also, several parts of the doc would need paragraph re-indentation (not done in this patch due to clarity).

Not sure what you mean here.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11840>
_______________________________________

From report at bugs.python.org  Tue Apr 12 23:34:44 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 12 Apr 2011 21:34:44 +0000
Subject: [issue11840] Improvements to c-api/unicode documentation
In-Reply-To: <1302643172.01.0.948666081662.issue11840@psf.upfronthosting.co.za>
Message-ID: <4DA4C571.7080009@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Sandro Tosi wrote:
> 
> New submission from Sandro Tosi <sandro.tosi at gmail.com>:
> 
> Hi,
> After reading tomo cocoa mail at docs@ I gave a look at c-api/unicode file and fixed some minor editing issues.

Thanks. Looks good !

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11840>
_______________________________________

From report at bugs.python.org  Tue Apr 12 23:44:45 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Apr 2011 21:44:45 +0000
Subject: [issue11186] pydoc: HTMLDoc.index() doesn't support PEP 383
In-Reply-To: <1297428909.69.0.247564466299.issue11186@psf.upfronthosting.co.za>
Message-ID: <E1Q9lO8-0005lY-AV@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 506cab8fc329 by Victor Stinner in branch 'default':
Issue #11186: pydoc ignores a module if its name contains a surrogate character
http://hg.python.org/cpython/rev/506cab8fc329

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11186>
_______________________________________

From report at bugs.python.org  Tue Apr 12 23:44:52 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 12 Apr 2011 21:44:52 +0000
Subject: [issue11840] Improvements to c-api/unicode documentation
In-Reply-To: <4DA4C55A.50400@egenix.com>
Message-ID: <BANLkTimTi2-qXotJtkkr96HNVdAJQp83Pw@mail.gmail.com>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

On Tue, Apr 12, 2011 at 23:34, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
> Sandro Tosi wrote:
>>
>> Sandro Tosi <sandro.tosi at gmail.com> added the comment:
>>
>> In addition, is there a reason for the sorting of UTF-8 UTF-32 UTF-16 and UTF-7 sections? why not alphabetically?
>
> No particular reason. Alphabetical order would be just as good.
>
> Note that such changes would have to be backported in order to
> keep the merge conflicts to a minimum.

It applies cleanly on 3.2 (module some offsets), not as good on 3.1
and 2.7: do you want me to prepare patches specifically for those 2
brances?

>> Also, several parts of the doc would need paragraph re-indentation (not done in this patch due to clarity).
>
> Not sure what you mean here.

sorry, I meant wrap at 80th column (or so) :)

Cheers.
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11840>
_______________________________________

From report at bugs.python.org  Tue Apr 12 23:45:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2011 21:45:14 +0000
Subject: [issue11186] pydoc: HTMLDoc.index() doesn't support PEP 383
In-Reply-To: <1297428909.69.0.247564466299.issue11186@psf.upfronthosting.co.za>
Message-ID: <1302644714.05.0.741579447677.issue11186@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11186>
_______________________________________

From report at bugs.python.org  Tue Apr 12 23:56:12 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 12 Apr 2011 21:56:12 +0000
Subject: [issue11840] Improvements to c-api/unicode documentation
In-Reply-To: <BANLkTimTi2-qXotJtkkr96HNVdAJQp83Pw@mail.gmail.com>
Message-ID: <4DA4CA78.4090607@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Sandro Tosi wrote:
> 
> Sandro Tosi <sandro.tosi at gmail.com> added the comment:
> 
> On Tue, Apr 12, 2011 at 23:34, Marc-Andre Lemburg
> <report at bugs.python.org> wrote:
>> Sandro Tosi wrote:
>>>
>>> Sandro Tosi <sandro.tosi at gmail.com> added the comment:
>>>
>>> In addition, is there a reason for the sorting of UTF-8 UTF-32 UTF-16 and UTF-7 sections? why not alphabetically?
>>
>> No particular reason. Alphabetical order would be just as good.
>>
>> Note that such changes would have to be backported in order to
>> keep the merge conflicts to a minimum.
> 
> It applies cleanly on 3.2 (module some offsets), not as good on 3.1
> and 2.7: do you want me to prepare patches specifically for those 2
> brances?

I think you misunderstood: when reorganizing the contents of
a file, it's better to apply the patch to all branches, rather
than just the current, since otherwise future patches that do
have to be merged to all branches would cause lots of merge
conflicts.

>>> Also, several parts of the doc would need paragraph re-indentation (not done in this patch due to clarity).
>>
>> Not sure what you mean here.
> 
> sorry, I meant wrap at 80th column (or so) :)

Ah, ok.

That's the same category of change as the reorg above
(due to diff working line-based and not word based).

Such changes are fine, but should only be applied occasionally
and then preferably as one big commit to minimize disruption.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11840>
_______________________________________

From report at bugs.python.org  Wed Apr 13 00:20:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2011 22:20:58 +0000
Subject: [issue11005] Assertion error on RLock._acquire_restore
In-Reply-To: <1295959468.18.0.305168366567.issue11005@psf.upfronthosting.co.za>
Message-ID: <1302646858.37.0.245857915462.issue11005@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here is a patch: Antoine, would you like to review it?

----------
keywords: +patch
nosy: +pitrou
Added file: http://bugs.python.org/file21636/rlock_release_save.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11005>
_______________________________________

From report at bugs.python.org  Wed Apr 13 00:25:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2011 22:25:12 +0000
Subject: [issue8776] Bytes version of sys.argv
In-Reply-To: <1274357456.02.0.0768864678422.issue8776@psf.upfronthosting.co.za>
Message-ID: <1302647112.01.0.837548186101.issue8776@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

One year after opening the issue, I don't have any real use case. And there are technical issues to implement this feature, so I prefer just to close this issue. Reopen it if you really want it, but please give an use case ;-)

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8776>
_______________________________________

From report at bugs.python.org  Wed Apr 13 00:26:11 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Apr 2011 22:26:11 +0000
Subject: [issue11747] unified_diff function product incorrect range information
In-Reply-To: <1301806636.68.0.728514553962.issue11747@psf.upfronthosting.co.za>
Message-ID: <E1Q9m2E-0000gm-BU@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 707078ca0a77 by Raymond Hettinger in branch '3.1':
Issue 11747: Fix output format for context diffs.
http://hg.python.org/cpython/rev/707078ca0a77

New changeset e3387295a24f by Raymond Hettinger in branch '3.2':
Issue 11747: Fix output format for context diffs.
http://hg.python.org/cpython/rev/e3387295a24f

New changeset fbfd5435889c by Raymond Hettinger in branch 'default':
Issue 11747: Fix output format for context diffs.
http://hg.python.org/cpython/rev/fbfd5435889c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11747>
_______________________________________

From report at bugs.python.org  Wed Apr 13 00:48:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Apr 2011 22:48:36 +0000
Subject: [issue11747] unified_diff function product incorrect range information
In-Reply-To: <1301806636.68.0.728514553962.issue11747@psf.upfronthosting.co.za>
Message-ID: <E1Q9mNu-0002Ds-LU@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 09459397f807 by Raymond Hettinger in branch '2.7':
Issue 11747: Fix output format for context diffs.
http://hg.python.org/cpython/rev/09459397f807

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11747>
_______________________________________

From report at bugs.python.org  Wed Apr 13 00:52:22 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Apr 2011 22:52:22 +0000
Subject: [issue11747] unified_diff function product incorrect range information
In-Reply-To: <1301806636.68.0.728514553962.issue11747@psf.upfronthosting.co.za>
Message-ID: <1302648742.84.0.399926388423.issue11747@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11747>
_______________________________________

From report at bugs.python.org  Wed Apr 13 00:58:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2011 22:58:35 +0000
Subject: [issue8448] buildbot: test_subprocess failure (test_no_leaking,
	Broken pipe)
In-Reply-To: <1271629678.61.0.824360658357.issue8448@psf.upfronthosting.co.za>
Message-ID: <1302649115.65.0.418085669349.issue8448@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I did not see this failure since one year. flox saw it 7 months ago.

I close this issue because I think that it is fixed. Reopen it if the issue was not fixed.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8448>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:00:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2011 23:00:31 +0000
Subject: [issue8429] buildbot: test_subprocess timeout
In-Reply-To: <1271454999.83.0.583856946737.issue8429@psf.upfronthosting.co.za>
Message-ID: <1302649231.18.0.407036411842.issue8429@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I developed the faulthandler module to get more information after a timeout. I close this issue: I already opened more specific issues with more information.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8429>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:00:37 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Apr 2011 23:00:37 +0000
Subject: [issue11806] Missing 2 hyphens in the docs
In-Reply-To: <1302338197.1.0.100311254016.issue11806@psf.upfronthosting.co.za>
Message-ID: <1302649237.79.0.174051006311.issue11806@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

IMO these are a waste of time and add zero value.  Also, the English hyphenation conventions vary depending on who you ask and they vary over time.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11806>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:01:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2011 23:01:28 +0000
Subject: [issue8431] buildbot: hung on ARM Debian
In-Reply-To: <1271512264.44.0.220821397982.issue8431@psf.upfronthosting.co.za>
Message-ID: <1302649288.75.0.679102684035.issue8431@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

There are no more ARM buildbots, so let's close this issue.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8431>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:02:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2011 23:02:41 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures (test_traversal,
	test_tab_identifiers, test_identify, test_heading_callback)
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1302649361.1.0.921578675553.issue8445@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I don't understand why this issue is still open, so let's close it.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8445>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:07:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Apr 2011 23:07:14 +0000
Subject: [issue11825] faulthandler: failure without threads
In-Reply-To: <1302503192.32.0.414479230775.issue11825@psf.upfronthosting.co.za>
Message-ID: <E1Q9mfw-0003dI-RE@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 64e8d371812c by Victor Stinner in branch 'default':
Fix #11825: disable regrtest timeout if Python doesn't support threads
http://hg.python.org/cpython/rev/64e8d371812c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11825>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:07:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2011 23:07:51 +0000
Subject: [issue11825] faulthandler: failure without threads
In-Reply-To: <1302503192.32.0.414479230775.issue11825@psf.upfronthosting.co.za>
Message-ID: <1302649671.33.0.412478139622.issue11825@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11825>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:10:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2011 23:10:31 +0000
Subject: [issue11779] test_mmap timeout (30 min) on "AMD64 Snow Leopard 3.x"
	buildbot
In-Reply-To: <1302076762.26.0.815715887004.issue11779@psf.upfronthosting.co.za>
Message-ID: <1302649831.57.0.359906172265.issue11779@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Antoine changed regrtest default timeout to 60 minutes. It should workaround test_mmap timeout, so can we close this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11779>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:20:20 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Tue, 12 Apr 2011 23:20:20 +0000
Subject: [issue11506] b'' += gives SystemError instead of SyntaxError
In-Reply-To: <1300131696.51.0.411697636242.issue11506@psf.upfronthosting.co.za>
Message-ID: <1302650420.37.0.79636540309.issue11506@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

Benjamin told me that "test_syntax" is the right place for the test and indeed, there are quite some literals already tested.

----------
nosy: +benjamin.peterson
Added file: http://bugs.python.org/file21637/issue_11506_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11506>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:21:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2011 23:21:10 +0000
Subject: [issue9592] Limitations in objects returned by multiprocessing Pool
In-Reply-To: <1281726168.11.0.648826556363.issue9592@psf.upfronthosting.co.za>
Message-ID: <1302650470.95.0.937117805055.issue9592@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Thanks Freek - we're actually discussing some stuff like this
> in issue9205 as well

I'm unable to see the relation between the issue #9205 and the point (3) of this issue (RuntimeError: maximum recursion depth exceeded while calling a Python object // WindowsError: [Error 5] Access is denied).

--

Are "RuntimeError: maximum recursion depth exceeded while calling a Python object" and "WindowsError: [Error 5] Access is denied)" errors the issue or not?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9592>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:24:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2011 23:24:40 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1302650680.41.0.613513612087.issue6715@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy:  -haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:26:06 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 12 Apr 2011 23:26:06 +0000
Subject: [issue11506] b'' += gives SystemError instead of SyntaxError
In-Reply-To: <1300131696.51.0.411697636242.issue11506@psf.upfronthosting.co.za>
Message-ID: <1302650766.54.0.0360261437166.issue11506@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
components: +Interpreter Core
type:  -> behavior
versions: +Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11506>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:26:16 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Apr 2011 23:26:16 +0000
Subject: [issue11703] Bug in python >= 2.7 with urllib2 fragment
In-Reply-To: <1301347412.09.0.984655654688.issue11703@psf.upfronthosting.co.za>
Message-ID: <E1Q9myK-0004rB-Ny@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3f240a1cd245 by Senthil Kumaran in branch '3.1':
Fix Issue11703 - urllib2.geturl() does not return correct url when the original url contains #fragment. Patch Contribution by Santoso Wijaya.
http://hg.python.org/cpython/rev/3f240a1cd245

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11703>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:28:01 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 12 Apr 2011 23:28:01 +0000
Subject: [issue11703] Bug in python >= 2.7 with urllib2 fragment
In-Reply-To: <1301347412.09.0.984655654688.issue11703@psf.upfronthosting.co.za>
Message-ID: <1302650881.28.0.0761831011802.issue11703@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

It should be noted that the bug surfaced in 2.7 and above due to changes made as part of Issue8280.

----------
assignee:  -> orsenthil
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11703>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:33:59 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Apr 2011 23:33:59 +0000
Subject: [issue11506] b'' += gives SystemError instead of SyntaxError
In-Reply-To: <1300131696.51.0.411697636242.issue11506@psf.upfronthosting.co.za>
Message-ID: <E1Q9n5p-0005Js-Ps@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 4d9a8e84279a by Benjamin Peterson in branch '3.1':
make assigning to a bytes literal a syntax error (closes #11506)
http://hg.python.org/cpython/rev/4d9a8e84279a

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11506>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:34:17 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 12 Apr 2011 23:34:17 +0000
Subject: [issue11806] Missing 2 hyphens in the docs
In-Reply-To: <1302649237.79.0.174051006311.issue11806@psf.upfronthosting.co.za>
Message-ID: <BANLkTim3CPcxj5h7aCqkqTyDc5y=oOoSBg@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

There are more of this typos in the same chapter. Just a little below the
one of the reported sentence. Check this out...

"Assuming the Python code above is saved into a file called prog.py, it can
be run at the !! command line !! and provides useful help messages:"  --> it
has to be: command-line

But then this...

"When run with the appropriate arguments, it prints either the sum or the
max of the !! command-line !! integers:"  --> here it is correct!

I don't get it. Please be consistent. Thanks.

----------
Added file: http://bugs.python.org/file21638/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11806>
_______________________________________
-------------- next part --------------
There are more of this typos in the same chapter. Just a little below the one of the reported sentence. Check this out...<div><br></div><div><span class="Apple-style-span" style="font-family: sans-serif; font-size: 16px; line-height: 20px; ">&quot;Assuming the Python code above is saved into a file called??<tt class="docutils literal" style="background-color: rgb(236, 240, 243); padding-top: 0px; padding-right: 1px; padding-bottom: 0px; padding-left: 1px; font-size: 0.95em; "><span class="pre">prog.py</span></tt>, it can be run at the !! command line !! and provides useful help messages:&quot; ??--&gt; it has to be: command-line</span></div>
<div><span class="Apple-style-span" style="font-family: sans-serif; font-size: 16px; line-height: 20px; "><br></span></div><div><span class="Apple-style-span" style="font-family: sans-serif; font-size: 16px; line-height: 20px; ">But then this...</span></div>
<div><span class="Apple-style-span" style="font-family: sans-serif; font-size: 16px; line-height: 20px; "><br></span></div><div><span class="Apple-style-span" style="font-family: sans-serif; font-size: 16px; line-height: 20px; ">&quot;When run with the appropriate arguments, it prints either the sum or the max of the !! command-line !! integers:&quot; ??--&gt; here it is correct!</span></div>
<div><span class="Apple-style-span" style="font-family: sans-serif; font-size: 16px; line-height: 20px; "><br></span></div><div><span class="Apple-style-span" style="font-family: sans-serif; font-size: 16px; line-height: 20px; ">I don&#39;t get it. Please be consistent. Thanks.</span></div>

From report at bugs.python.org  Wed Apr 13 01:36:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Apr 2011 23:36:28 +0000
Subject: [issue11703] Bug in python >= 2.7 with urllib2 fragment
In-Reply-To: <1301347412.09.0.984655654688.issue11703@psf.upfronthosting.co.za>
Message-ID: <E1Q9n8B-0005ZK-Te@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6e73f75ee034 by Senthil Kumaran in branch '2.7':
Fix Issue11703 - urllib2.get_url does not handle fragment in url properly.
http://hg.python.org/cpython/rev/6e73f75ee034

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11703>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:38:52 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 12 Apr 2011 23:38:52 +0000
Subject: [issue11703] Bug in python >= 2.7 with urllib2 fragment
In-Reply-To: <1301347412.09.0.984655654688.issue11703@psf.upfronthosting.co.za>
Message-ID: <1302651532.55.0.392614303979.issue11703@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

This is fixed in all the codelines. Thanks for the patch, Santoso.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11703>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:57:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2011 23:57:32 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory (sysconfig._getuserbase)
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1302652652.69.0.162301786788.issue10496@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue remembers me the issue #6612 (failure if the current directory was removed): the fix was to ignore os.getcwd().

Attached patch ignores os.path.expanduser() error (KeyError) and keeps ~ in the path. Example without HOME var and with an non existent user (uid 12345):

----------------------
$ env -i ./python
>>> import sysconfig
>>> sysconfig.get_config_var('userbase')
'~/.local'

>>> sysconfig.get_paths(scheme='posix_user', expand=False)
{'platstdlib': '{userbase}/lib/python{py_version_short}', 'platlib': '{userbase}/lib/python{py_version_short}/site-packages', 'purelib': '{userbase}/lib/python{py_version_short}/site-packages', 'stdlib': '{userbase}/lib/python{py_version_short}', 'scripts': '{userbase}/bin', 'include': '{userbase}/include/python{py_version_short}', 'data': '{userbase}'}

>>> sysconfig.get_paths(scheme='posix_user')              
{'platstdlib': '~/.local/lib/python3.3', 'platlib': '~/.local/lib/python3.3/site-packages', 'purelib': '~/.local/lib/python3.3/site-packages', 'stdlib': '~/.local/lib/python3.3', 'scripts': '~/.local/bin', 'include': '~/.local/include/python3.3', 'data': '~/.local'}
----------------------

Example with an existant user but without HOME var:
----------------------
marge$ env -i ./python
>>> import sysconfig
>>> sysconfig.get_config_var('userbase')
'/home/haypo/.local'
>>> sysconfig.get_paths(scheme='posix_user')      
{'platstdlib': '/home/haypo/.local/lib/python3.3', 'platlib': '/home/haypo/.local/lib/python3.3/site-packages', 'purelib': '/home/haypo/.local/lib/python3.3/site-packages', 'stdlib': '/home/haypo/.local/lib/python3.3', 'scripts': '/home/haypo/.local/bin', 'include': '/home/haypo/.local/include/python3.3', 'data': '/home/haypo/.local'}
----------------------

----------
nosy: +tarek
title: "import site failed" when Python can't find home directory -> "import site failed" when Python can't find home directory (sysconfig._getuserbase)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10496>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:58:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2011 23:58:59 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory (sysconfig._getuserbase)
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1302652739.31.0.187690165264.issue10496@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file21639/sysconfig_getuserbase.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10496>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:59:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2011 23:59:41 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory (sysconfig._getuserbase)
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1302652781.31.0.309825021866.issue10496@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file21639/sysconfig_getuserbase.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10496>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:59:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2011 23:59:49 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory (sysconfig._getuserbase)
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1302652789.73.0.986302996727.issue10496@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file21640/sysconfig_getuserbase.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10496>
_______________________________________

From report at bugs.python.org  Wed Apr 13 02:15:43 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 13 Apr 2011 00:15:43 +0000
Subject: [issue11806] Missing 2 hyphens in the docs
In-Reply-To: <BANLkTim3CPcxj5h7aCqkqTyDc5y=oOoSBg@mail.gmail.com>
Message-ID: <BANLkTinVeD-LLVSfG1oFTdKVKCik06FJjA@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/4/12 Bo?tjan Mejak <report at bugs.python.org>:
>
> Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:
>
> There are more of this typos in the same chapter. Just a little below the
> one of the reported sentence. Check this out...
>
> "Assuming the Python code above is saved into a file called prog.py, it can
> be run at the !! command line !! and provides useful help messages:" ?--> it
> has to be: command-line
>
> But then this...
>
> "When run with the appropriate arguments, it prints either the sum or the
> max of the !! command-line !! integers:" ?--> here it is correct!
>
> I don't get it. Please be consistent. Thanks.

"A foolish consistency is the hobgoblin of little minds."

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11806>
_______________________________________

From report at bugs.python.org  Wed Apr 13 03:22:33 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Apr 2011 01:22:33 +0000
Subject: [issue10019] json.dumps with indent = 0 not adding newlines
In-Reply-To: <1286122957.24.0.240376565719.issue10019@psf.upfronthosting.co.za>
Message-ID: <E1Q9oms-0005nZ-3O@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 8264f68e8251 by R David Murray in branch '2.7':
#10019: Fix regression relative to 2.6: add newlines if indent=0
http://hg.python.org/cpython/rev/8264f68e8251

New changeset 4a1048257995 by R David Murray in branch '3.1':
#10019: Fix regression relative to 2.6: add newlines if indent=0
http://hg.python.org/cpython/rev/4a1048257995

New changeset fe8bbaff5a27 by R David Murray in branch '3.2':
Merge #10019: Fix regression relative to 2.6: add newlines if indent=0
http://hg.python.org/cpython/rev/fe8bbaff5a27

New changeset 2d0d0850335e by R David Murray in branch 'default':
Merge #10019: Fix regression relative to 2.6: add newlines if indent=0
http://hg.python.org/cpython/rev/2d0d0850335e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10019>
_______________________________________

From report at bugs.python.org  Wed Apr 13 03:22:51 2011
From: report at bugs.python.org (Felipe Cruz)
Date: Wed, 13 Apr 2011 01:22:51 +0000
Subject: [issue7484] smtplib: verify breaks with Postfix servers
In-Reply-To: <1260600956.23.0.0101749869854.issue7484@psf.upfronthosting.co.za>
Message-ID: <1302657771.23.0.588523325313.issue7484@psf.upfronthosting.co.za>


Felipe Cruz <felipecruz at loogica.net> added the comment:

I've rewrote those patches to 'default' and 2.7

----------
nosy: +felipecruz
Added file: http://bugs.python.org/file21641/issue7484-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7484>
_______________________________________

From report at bugs.python.org  Wed Apr 13 03:23:17 2011
From: report at bugs.python.org (Felipe Cruz)
Date: Wed, 13 Apr 2011 01:23:17 +0000
Subject: [issue7484] smtplib: verify breaks with Postfix servers
In-Reply-To: <1260600956.23.0.0101749869854.issue7484@psf.upfronthosting.co.za>
Message-ID: <1302657797.1.0.721260217477.issue7484@psf.upfronthosting.co.za>


Changes by Felipe Cruz <felipecruz at loogica.net>:


Added file: http://bugs.python.org/file21642/issue7484-27.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7484>
_______________________________________

From report at bugs.python.org  Wed Apr 13 03:24:18 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Apr 2011 01:24:18 +0000
Subject: [issue10019] json.dumps with indent = 0 not adding newlines
In-Reply-To: <1286122957.24.0.240376565719.issue10019@psf.upfronthosting.co.za>
Message-ID: <1302657858.06.0.668273748379.issue10019@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks, Sandro.

----------
assignee: bob.ippolito -> 
nosy: +r.david.murray
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10019>
_______________________________________

From report at bugs.python.org  Wed Apr 13 03:25:30 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 13 Apr 2011 01:25:30 +0000
Subject: [issue3056] Simplify the Integral ABC
In-Reply-To: <1212803845.73.0.399511532431.issue3056@psf.upfronthosting.co.za>
Message-ID: <1302657930.4.0.424207663495.issue3056@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I've long since lost interest in this.
If anyone wants to push it forward,
feel free to re-open.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3056>
_______________________________________

From report at bugs.python.org  Wed Apr 13 03:35:45 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Apr 2011 01:35:45 +0000
Subject: [issue11718] Teach IDLE's open-module command to find packages
In-Reply-To: <1301444586.78.0.773077705239.issue11718@psf.upfronthosting.co.za>
Message-ID: <E1Q9ozg-0006fT-J1@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 27eda70c25b1 by Raymond Hettinger in branch '3.2':
Issue 11718: Teach IDLE's open module dialog to find packages.
http://hg.python.org/cpython/rev/27eda70c25b1

New changeset 65c39e9eb262 by Raymond Hettinger in branch 'default':
Issue 11718: Teach IDLE's open module dialog to find packages.
http://hg.python.org/cpython/rev/65c39e9eb262

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11718>
_______________________________________

From report at bugs.python.org  Wed Apr 13 03:36:34 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 13 Apr 2011 01:36:34 +0000
Subject: [issue11506] b'' += gives SystemError instead of SyntaxError
In-Reply-To: <1300131696.51.0.411697636242.issue11506@psf.upfronthosting.co.za>
Message-ID: <1302658594.6.0.621308335804.issue11506@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thanks all for fixing. This 'silently' crashes IDLE with no message.
Just 'poof'.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11506>
_______________________________________

From report at bugs.python.org  Wed Apr 13 03:43:32 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Apr 2011 01:43:32 +0000
Subject: [issue11703] Bug in python >= 2.7 with urllib2 fragment
In-Reply-To: <1301347412.09.0.984655654688.issue11703@psf.upfronthosting.co.za>
Message-ID: <E1Q9p7C-00074D-Vb@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 8ee48ec69844 by Senthil Kumaran in branch '3.1':
Update the News for the fix to Issue11703.
http://hg.python.org/cpython/rev/8ee48ec69844

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11703>
_______________________________________

From report at bugs.python.org  Wed Apr 13 03:47:55 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Apr 2011 01:47:55 +0000
Subject: [issue11703] Bug in python >= 2.7 with urllib2 fragment
In-Reply-To: <1301347412.09.0.984655654688.issue11703@psf.upfronthosting.co.za>
Message-ID: <E1Q9pBR-0007S9-66@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 502bb809b03b by Senthil Kumaran in branch '2.7':
update news in 2.7  for Issue #11703
http://hg.python.org/cpython/rev/502bb809b03b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11703>
_______________________________________

From report at bugs.python.org  Wed Apr 13 03:55:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Apr 2011 01:55:02 +0000
Subject: [issue11718] Teach IDLE's open-module command to find packages
In-Reply-To: <1301444586.78.0.773077705239.issue11718@psf.upfronthosting.co.za>
Message-ID: <E1Q9pIJ-0007sC-N4@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset e391f7005b0f by Raymond Hettinger in branch '2.7':
Issue 11718: Teach IDLE's open module dialog to find packages.
http://hg.python.org/cpython/rev/e391f7005b0f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11718>
_______________________________________

From report at bugs.python.org  Wed Apr 13 03:59:48 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Apr 2011 01:59:48 +0000
Subject: [issue7484] smtplib: verify breaks with Postfix servers
In-Reply-To: <1260600956.23.0.0101749869854.issue7484@psf.upfronthosting.co.za>
Message-ID: <1302659988.82.0.297568784942.issue7484@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for working on this.

The tests seem to be missing, as is the line that adds 'clean' to the def, so the patches won't work as is.

However, now that I've looked at the patch in more detail, adding a parameter to a public method is not something we can do in a bug fix release.  So, this solution would work for 3.3, but not for 2.7 and 3.2.  In any case, Guido thinks that parameters that have only two values should be replaced by methods with two different names.  In this case that makes a lot of sense.  I've checked the RFC and the code, and there are two cases: MAIL FROM and RCPT TO, which require the address to be in <>s, and VRFY and EXPN, which prefer that it not be in <>s.  So I think we should introduce a new, private function for use in the VRFY and EXPN cases:

    def _addronly(addr):
        (fullname, email) = email.utils.parseaddr(addr)
        return email

Can you do a new patch, adding the above function and using it at the right places?  Tests are also needed...it should be possible to modify the test that the original patch modified so that it checks to make sure the <> are not added.  If you need help with that let me know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7484>
_______________________________________

From report at bugs.python.org  Wed Apr 13 04:02:35 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 13 Apr 2011 02:02:35 +0000
Subject: [issue11718] Teach IDLE's open-module command to find packages
In-Reply-To: <1301444586.78.0.773077705239.issue11718@psf.upfronthosting.co.za>
Message-ID: <1302660155.81.0.712200456893.issue11718@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11718>
_______________________________________

From report at bugs.python.org  Wed Apr 13 04:04:31 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 13 Apr 2011 02:04:31 +0000
Subject: [issue11806] Missing 2 hyphens in the docs
In-Reply-To: <1302338197.1.0.100311254016.issue11806@psf.upfronthosting.co.za>
Message-ID: <1302660271.37.0.72694755163.issue11806@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11806>
_______________________________________

From report at bugs.python.org  Wed Apr 13 04:07:20 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 13 Apr 2011 02:07:20 +0000
Subject: [issue11823] disassembly needs argument counts on calls with keyword
	args
In-Reply-To: <1302469900.48.0.983863495872.issue11823@psf.upfronthosting.co.za>
Message-ID: <1302660440.04.0.859672506712.issue11823@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Looks good.  Please apply.

----------
assignee:  -> belopolsky
resolution:  -> accepted
title: disassembly needs to argument counts on calls with keyword args -> disassembly needs argument counts on calls with keyword args
type: feature request -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11823>
_______________________________________

From report at bugs.python.org  Wed Apr 13 04:10:50 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Apr 2011 02:10:50 +0000
Subject: [issue11840] Improvements to c-api/unicode documentation
In-Reply-To: <1302643172.01.0.948666081662.issue11840@psf.upfronthosting.co.za>
Message-ID: <1302660650.7.0.000887380692897.issue11840@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/issue11840>
_______________________________________

From report at bugs.python.org  Wed Apr 13 04:28:27 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 13 Apr 2011 02:28:27 +0000
Subject: [issue11822] Improve disassembly to show embedded code objects
In-Reply-To: <1302467152.39.0.854888976189.issue11822@psf.upfronthosting.co.za>
Message-ID: <1302661707.65.0.762518785752.issue11822@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11822>
_______________________________________

From report at bugs.python.org  Wed Apr 13 04:31:15 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 13 Apr 2011 02:31:15 +0000
Subject: [issue1721083] Add File - Reload
Message-ID: <1302661875.97.0.10585928713.issue1721083@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: kbk -> rhettinger
keywords: +needs review -patch
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1721083>
_______________________________________

From report at bugs.python.org  Wed Apr 13 04:38:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Apr 2011 02:38:20 +0000
Subject: [issue9233] json.load failure when C optimizations aren't built
In-Reply-To: <1278949665.57.0.214129757073.issue9233@psf.upfronthosting.co.za>
Message-ID: <E1Q9pyC-0002I4-Bs@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d58c63ff5bb2 by Ezio Melotti in branch '2.7':
#9233: Fix json.loads({}) to return a dict (instead of a list), when _json is not available.
http://hg.python.org/cpython/rev/d58c63ff5bb2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9233>
_______________________________________

From report at bugs.python.org  Wed Apr 13 05:09:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Apr 2011 03:09:07 +0000
Subject: [issue11830] "import decimal" fails in Turkish locale
In-Reply-To: <1302562017.26.0.78208251188.issue11830@psf.upfronthosting.co.za>
Message-ID: <E1Q9qRz-0004va-4n@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f5d5f3f4c081 by Alexander Belopolsky in branch '3.2':
Issue #11830: Remove unnecessary introspection code in the decimal module.
http://hg.python.org/cpython/rev/f5d5f3f4c081

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11830>
_______________________________________

From report at bugs.python.org  Wed Apr 13 05:10:42 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 13 Apr 2011 03:10:42 +0000
Subject: [issue11830] "import decimal" fails in Turkish locale
In-Reply-To: <1302562017.26.0.78208251188.issue11830@psf.upfronthosting.co.za>
Message-ID: <1302664242.22.0.068781723618.issue11830@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
stage:  -> committed/rejected
type:  -> behavior
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11830>
_______________________________________

From report at bugs.python.org  Wed Apr 13 05:17:51 2011
From: report at bugs.python.org (Ryan Kelly)
Date: Wed, 13 Apr 2011 03:17:51 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1302664671.16.0.668473839484.issue10399@psf.upfronthosting.co.za>


Changes by Ryan Kelly <ryan at rfk.id.au>:


----------
nosy: +rfk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10399>
_______________________________________

From report at bugs.python.org  Wed Apr 13 06:21:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Apr 2011 04:21:53 +0000
Subject: [issue9233] json.load failure when C optimizations aren't built
In-Reply-To: <1278949665.57.0.214129757073.issue9233@psf.upfronthosting.co.za>
Message-ID: <E1Q9raR-0000xq-07@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 36e676a8541d by Ezio Melotti in branch '3.1':
#9233: skip _json-specific tests when _json is not available.
http://hg.python.org/cpython/rev/36e676a8541d

New changeset 7019fc1a9663 by Ezio Melotti in branch '3.1':
#9233: Fix json to work properly even when _json is not available.
http://hg.python.org/cpython/rev/7019fc1a9663

New changeset a220458179ed by Ezio Melotti in branch '3.1':
#9233: Fix json.loads({}) to return a dict (instead of a list), when _json is not available.
http://hg.python.org/cpython/rev/a220458179ed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9233>
_______________________________________

From report at bugs.python.org  Wed Apr 13 06:25:47 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Apr 2011 04:25:47 +0000
Subject: [issue9233] json.load failure when C optimizations aren't built
In-Reply-To: <1278949665.57.0.214129757073.issue9233@psf.upfronthosting.co.za>
Message-ID: <1302668747.95.0.777092533216.issue9233@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in 2.7 and 3.1 and ported to 3.2 (b279611146d7) and 3.3 (e8e3f2b72a32).
In 3.1 json was completely broken without _json, so I fixed that too.
I also did some minor cleanup in ec6d881f5b02.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions: +Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9233>
_______________________________________

From report at bugs.python.org  Wed Apr 13 06:55:12 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Apr 2011 04:55:12 +0000
Subject: [issue11840] Improvements to c-api/unicode documentation
In-Reply-To: <1302643172.01.0.948666081662.issue11840@psf.upfronthosting.co.za>
Message-ID: <1302670512.3.0.354475161366.issue11840@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Rewrapping the paragraphs you are changing is fine, the others can be left as they are.
Patches should be against the oldest branch where they can be applied, and since this is a doc patch it can go in 2.7 and 3.1 too.
Regarding the order of the codecs, I would leave UTF-7 last because it's not commonly used, changing them to 8/16/32/7 is probably OK though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11840>
_______________________________________

From report at bugs.python.org  Wed Apr 13 09:18:10 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Apr 2011 07:18:10 +0000
Subject: [issue5723] Incomplete json tests
In-Reply-To: <1239205406.15.0.353111609778.issue5723@psf.upfronthosting.co.za>
Message-ID: <1302679090.31.0.750625297796.issue5723@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Some tests for py_make_scanner have been added in c3ad883b940b.

I agree that having the tested method as an attribute of the class and changing it on a different subclass is the best approach, but it's not currently done by the json tests.
Do you think the test should be refactored to use this approach?  This will also make easier to skip _json-specific tests when _json is not available and for other Python implementations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5723>
_______________________________________

From report at bugs.python.org  Wed Apr 13 09:23:28 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Apr 2011 07:23:28 +0000
Subject: [issue10976] json.loads() throws TypeError on bytes object
In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za>
Message-ID: <1302679408.69.0.132075677423.issue10976@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Now it's too late for 3.2, should this be done for 3.3?

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10976>
_______________________________________

From report at bugs.python.org  Wed Apr 13 09:36:02 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Apr 2011 07:36:02 +0000
Subject: [issue9101] reference json format in file formats chapter
In-Reply-To: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>
Message-ID: <1302680162.2.0.612535033489.issue9101@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The json module is listed in the Internet Data Handling section[0], and the description says:
"""
This chapter describes modules which support handling data formats commonly used on the Internet.
"""
This seems OK for json.


The File Format section[1] says:
"""
The modules described in this chapter parse various miscellaneous file formats that aren?t markup languages and are not related to e-mail.
"""
And this description might work for json too.

I'm not sure it's worth moving it though.


[0]: http://docs.python.org/py3k/library/netdata.html
[1]: http://docs.python.org/py3k/library/fileformats.html

----------
nosy: +ezio.melotti, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9101>
_______________________________________

From report at bugs.python.org  Wed Apr 13 09:51:53 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 13 Apr 2011 07:51:53 +0000
Subject: [issue11806] Missing 2 hyphens in the docs
In-Reply-To: <1302660271.44.0.512254417762.issue11806@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=C2sRDiPQVZs6c68te+AfZhOV5nQ@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Georg Brandl, please fix this typos. You would understand. Thank you.

----------
Added file: http://bugs.python.org/file21643/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11806>
_______________________________________
-------------- next part --------------
Georg Brandl, please fix this typos. You would understand. Thank you.

From report at bugs.python.org  Wed Apr 13 10:19:52 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 13 Apr 2011 08:19:52 +0000
Subject: [issue10332] Multiprocessing maxtasksperchild results in hang
In-Reply-To: <1288995752.47.0.110889938296.issue10332@psf.upfronthosting.co.za>
Message-ID: <1302682792.7.0.614141789982.issue10332@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

This problem arises because the pool's close method is called before all the tasks have completed. Putting a sleep(1) before pool.close() won't exhibit this lockup.
The root cause is that close makes the workers handler thread exit: since the maxtasksperchild argument is used, workers exit when they've processed their max number of tasks. But since the workers handler thread exited, it doesn't maintain the pool of workers anymore, and thus the remaining tasks are not treated anymore, and the task handler thread waits indefinitely (since it waits until the cache is empty).
The solution is to prevent the worker handler thread from exiting until the cache has been drained (unless the pool is terminated in which case it must exit right away).
Attached is a patch and relevant test.

Note: I noticed that there are some thread-unsafe operations (the cache that can be modified from different threads, and thread states are modified also from different threads). While this isn't an issue with the current cPython implementation (GIL), I wonder if this should be fixed.

----------
keywords: +patch
nosy: +neologix
Added file: http://bugs.python.org/file21644/pool_lifetime_close.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10332>
_______________________________________

From report at bugs.python.org  Wed Apr 13 10:22:17 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 13 Apr 2011 08:22:17 +0000
Subject: [issue9101] reference json format in file formats chapter
In-Reply-To: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>
Message-ID: <1302682937.6.0.434535386073.issue9101@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

JSON is not file format, it is data-interchange format.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9101>
_______________________________________

From report at bugs.python.org  Wed Apr 13 10:24:18 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Apr 2011 08:24:18 +0000
Subject: =?utf-8?q?=5Bissue4783=5D_document_that_json=2Eload/dump_can=E2=80=99t_be?=
	=?utf-8?q?_used_twice_on_the_same_stream?=
In-Reply-To: <1230657409.93.0.0443603821797.issue4783@psf.upfronthosting.co.za>
Message-ID: <1302683058.98.0.549074512654.issue4783@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attached patch adds a note about the effects of using dump several times on the same file.

----------
keywords: +easy, needs review, patch
nosy: +ezio.melotti
stage:  -> patch review
Added file: http://bugs.python.org/file21645/issue4783.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4783>
_______________________________________

From report at bugs.python.org  Wed Apr 13 10:28:56 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Apr 2011 08:28:56 +0000
Subject: [issue9101] reference json format in file formats chapter
In-Reply-To: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>
Message-ID: <1302683336.03.0.617764705705.issue9101@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

We don't have a "Data-interchange Formats" section, so the "Internet Data Handling" section seems more appropriate than the "File Formats" one, right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9101>
_______________________________________

From report at bugs.python.org  Wed Apr 13 10:30:49 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Apr 2011 08:30:49 +0000
Subject: [issue11489] json.dumps not parsable by json.loads (on Linux only)
In-Reply-To: <1300058240.59.0.513243746739.issue11489@psf.upfronthosting.co.za>
Message-ID: <1302683449.68.0.0997390311637.issue11489@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file21135/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11489>
_______________________________________

From report at bugs.python.org  Wed Apr 13 10:34:13 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Apr 2011 08:34:13 +0000
Subject: [issue11489] json.dumps not parsable by json.loads (on Linux only)
In-Reply-To: <1300058240.59.0.513243746739.issue11489@psf.upfronthosting.co.za>
Message-ID: <1302683653.85.0.341272300019.issue11489@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/issue11489>
_______________________________________

From report at bugs.python.org  Wed Apr 13 10:43:28 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 13 Apr 2011 08:43:28 +0000
Subject: [issue9101] reference json format in file formats chapter
In-Reply-To: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>
Message-ID: <1302684208.14.0.373451894716.issue9101@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Right.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9101>
_______________________________________

From report at bugs.python.org  Wed Apr 13 10:44:01 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 13 Apr 2011 08:44:01 +0000
Subject: [issue9101] reference json format in file formats chapter
In-Reply-To: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>
Message-ID: <1302684241.47.0.763142234305.issue9101@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

But having a reference from File Formats will help people find this information easier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9101>
_______________________________________

From report at bugs.python.org  Wed Apr 13 10:51:50 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 13 Apr 2011 08:51:50 +0000
Subject: [issue8426] multiprocessing.Queue fails to get() very large objects
In-Reply-To: <1271443086.56.0.51527518355.issue8426@psf.upfronthosting.co.za>
Message-ID: <1302684710.15.0.312275782078.issue8426@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

It's documented in http://docs.python.org/library/multiprocessing.html#multiprocessing-programming :
"""
Joining processes that use queues

Bear in mind that a process that has put items in a queue will wait before terminating until all the buffered items are fed by the ?feeder? thread to the underlying pipe. (The child process can call the Queue.cancel_join_thread() method of the queue to avoid this behaviour.)

This means that whenever you use a queue you need to make sure that all items which have been put on the queue will eventually be removed before the process is joined. Otherwise you cannot be sure that processes which have put items on the queue will terminate. Remember also that non-daemonic processes will be automatically be joined.
"""

Suggesting to close.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8426>
_______________________________________

From report at bugs.python.org  Wed Apr 13 10:59:35 2011
From: report at bugs.python.org (=?utf-8?b?RGFyw61vIFN1w6FyZXogR3JhY2lh?=)
Date: Wed, 13 Apr 2011 08:59:35 +0000
Subject: [issue6766] Cannot modify dictionaries inside dictionaries using
	Managers from multiprocessing
In-Reply-To: <1251049590.58.0.809281249474.issue6766@psf.upfronthosting.co.za>
Message-ID: <1302685175.1.0.972565542742.issue6766@psf.upfronthosting.co.za>


Dar?o Su?rez Gracia <dario.suarez at telefonica.net> added the comment:

Hello,
Trying to share a dictionary of dictionaries of lists with a manager I get the same problem with the patch applied in Python 2.7 (r27:82500, Nov 24 2010, 18:24:29) [GCC 4.1.2 20080704 (Red Hat 4.1.2-48)] on linux2.

The shared variable in results and what I'm trying to do is simultaneously parsing multiple files.

The quality of the code is not very good because I'm a newbie python programmer.

Best regards,
Dar?o

----------
nosy: +dariosg
Added file: http://bugs.python.org/file21646/test_dict_dict_arrays.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6766>
_______________________________________

From report at bugs.python.org  Wed Apr 13 11:19:40 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 13 Apr 2011 09:19:40 +0000
Subject: [issue11841] Bug in the verson comparison
In-Reply-To: <1302686380.66.0.407051830429.issue11841@psf.upfronthosting.co.za>
Message-ID: <1302686380.66.0.407051830429.issue11841@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

The NormalizedVersion class is not correctly sorting rc1:

>>> from packaging.version import NormalizedVersion
>>> NormalizedVersion('0.7.0') < NormalizedVersion('0.7.0rc1')
True
>>> NormalizedVersion('0.7.0rc1')
NormalizedVersion('0.7rc1')
>>> NormalizedVersion('0.7.0') < NormalizedVersion('0.7.0a1')
False
>>> NormalizedVersion('0.7.0') < NormalizedVersion('0.7.0c1')
False

----------
assignee: tarek
components: Distutils2
messages: 133656
nosy: alexis, brett.cannon, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Bug in the verson comparison
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11841>
_______________________________________

From report at bugs.python.org  Wed Apr 13 11:25:26 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 13 Apr 2011 09:25:26 +0000
Subject: [issue10121] test_multiprocessing stuck in test_make_pool if run in a
	loop
In-Reply-To: <1287232773.28.0.893033557088.issue10121@psf.upfronthosting.co.za>
Message-ID: <1302686726.16.0.885974672477.issue10121@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

It's probably a duplicate of http://bugs.python.org/issue8428
It would be nice if you could try to reproduce it with a py3k snapshot though, just to be sure.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10121>
_______________________________________

From report at bugs.python.org  Wed Apr 13 12:22:52 2011
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Wed, 13 Apr 2011 10:22:52 +0000
Subject: [issue9101] reference json format in file formats chapter
In-Reply-To: <1302684241.47.0.763142234305.issue9101@psf.upfronthosting.co.za>
Message-ID: <BANLkTimzCaTobwSDXS-bNzL4hXjreurCaA@mail.gmail.com>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

And what are these people looking for?  "json"?  If so, there's
already an entry in the module index.  That seems sufficient.

----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9101>
_______________________________________

From report at bugs.python.org  Wed Apr 13 13:27:31 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 13 Apr 2011 11:27:31 +0000
Subject: [issue11701] email.parser.BytesParser().parse() closes file argument
In-Reply-To: <1301315420.28.0.123524956156.issue11701@psf.upfronthosting.co.za>
Message-ID: <1302694051.45.0.00195111271161.issue11701@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

This patch fixes the problem.
It was introduced in e727cf35.

David Murray, i've looked into test_email.py to add tests
for this, and i found TestIdempotent().
What i would do is try to split that thing up so that it covers
str() as well as bytes(), rewriting ._msgobj() to use a xy
parser instance so that the file-argument-is-not-closed test
could be embedded in there as a side-effect.

This is however your area, so please let me know if i may
touch this or if you have local modifications to this one
which will make my snail-slow work on it pointless.
Thanks.

----------
keywords: +patch
nosy: +brett.cannon
title: email.parser.BytesParser() uses TextIOWrapper -> email.parser.BytesParser().parse() closes file argument
Added file: http://bugs.python.org/file21647/11701.1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11701>
_______________________________________

From report at bugs.python.org  Wed Apr 13 13:31:49 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 13 Apr 2011 11:31:49 +0000
Subject: [issue11700] mailbox.py proxy updates
In-Reply-To: <1301315190.34.0.276151285444.issue11700@psf.upfronthosting.co.za>
Message-ID: <1302694309.56.0.0650024114933.issue11700@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Amaury Forgeot d'Arc wrote:
> mbf.close() should not fail when called twice. The close() method in the > io module states that "This method has no effect if the file is already > closed."
> But then, is "close=False" necessary?

I see you've detached.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11700>
_______________________________________

From report at bugs.python.org  Wed Apr 13 13:54:03 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 13 Apr 2011 11:54:03 +0000
Subject: [issue11806] Missing 2 hyphens in the docs
In-Reply-To: <BANLkTi=C2sRDiPQVZs6c68te+AfZhOV5nQ@mail.gmail.com>
Message-ID: <BANLkTin7HMUqE10AmQA_Bps4z0cONYcM=A@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Also, please fix the main title of the argparse section...

from
15.4. argparse<http://docs.python.org/dev/library/argparse.html#module-argparse>
???
Parser for command line options, arguments and sub-commands
to
15.4. argparse<http://docs.python.org/dev/library/argparse.html#module-argparse>
???
Parser for command-line options, arguments and sub-commands
Please note the added hyphen (-) for the word command-line. Since this is
actually one word, it needs the hyphen. This is not Python related, but is
orthology related. Please fix all this documentation imprecisions in the
section argparse. Won't take a minute.

----------
Added file: http://bugs.python.org/file21648/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11806>
_______________________________________
-------------- next part --------------
Also, please fix the main title of the argparse section...<div><br></div><div>from</div><div><span class="Apple-style-span" style="font-family: sans-serif; font-size: 16px; "><h1 style="font-family: &#39;Trebuchet MS&#39;, sans-serif; background-color: rgb(242, 242, 242); font-weight: normal; color: rgb(32, 67, 92); border-bottom-width: 1px; border-bottom-style: solid; border-bottom-color: rgb(204, 204, 204); margin-top: 0px; margin-right: -20px; margin-bottom: 10px; margin-left: -20px; padding-top: 3px; padding-right: 0px; padding-bottom: 3px; padding-left: 10px; font-size: 32px; ">
15.4.??<a class="reference internal" href="http://docs.python.org/dev/library/argparse.html#module-argparse" title="argparse: Command-line option and argument parsing library." style="color: rgb(53, 95, 124); text-decoration: none; "><tt class="xref py py-mod docutils literal" style="background-color: transparent; padding-top: 0px; padding-right: 1px; padding-bottom: 0px; padding-left: 1px; font-size: 0.95em; font-weight: bold; "><span class="pre">argparse</span></tt></a>????? Parser for command line options, arguments and sub-commands</h1>
<div>to</div><div><h1 style="font-family: &#39;Trebuchet MS&#39;, sans-serif; background-color: rgb(242, 242, 242); font-weight: normal; color: rgb(32, 67, 92); border-bottom-width: 1px; border-bottom-style: solid; border-bottom-color: rgb(204, 204, 204); margin-top: 0px; margin-right: -20px; margin-bottom: 10px; margin-left: -20px; padding-top: 3px; padding-right: 0px; padding-bottom: 3px; padding-left: 10px; font-size: 32px; ">
15.4.??<a class="reference internal" href="http://docs.python.org/dev/library/argparse.html#module-argparse" title="argparse: Command-line option and argument parsing library." style="color: rgb(53, 95, 124); text-decoration: none; "><tt class="xref py py-mod docutils literal" style="background-color: transparent; padding-top: 0px; padding-right: 1px; padding-bottom: 0px; padding-left: 1px; font-size: 0.95em; font-weight: bold; "><span class="pre">argparse</span></tt></a>????? Parser for command-line options, arguments and sub-commands</h1>
</div><div>Please note the added hyphen (-) for the word command-line. Since this is actually one word, it needs the hyphen. This is not Python related, but is orthology related. Please fix all this documentation imprecisions in the section argparse. Won&#39;t take a minute.</div>
</span></div>

From report at bugs.python.org  Wed Apr 13 14:37:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Apr 2011 12:37:45 +0000
Subject: [issue11489] json.dumps not parsable by json.loads (on Linux only)
In-Reply-To: <1300058240.59.0.513243746739.issue11489@psf.upfronthosting.co.za>
Message-ID: <1302698265.11.0.222002159918.issue11489@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

print(repr(json.loads(json.dumps({u"my_key": u'\uda00'}))['my_key'])):
 - displays u'\uda00' in Python 2.7, 3.2 and 3.3
 - raises a ValueError('Invalid \uXXXX escape: ...') on loads() in Python 2.6
 - raises a ValueError('Unpaired high surrogate: ...') on loads() in Python 3.1

json version changed in Python 2.7: see the issue #4136.

See also this important change in simplejson:
http://code.google.com/p/simplejson/source/detail?r=113

We only fix security bugs in Python 2.6, not bugs. I don't think that this issue is a security bug in Python 2.6.

We might change Python 3.1 behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11489>
_______________________________________

From report at bugs.python.org  Wed Apr 13 14:38:11 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 13 Apr 2011 12:38:11 +0000
Subject: [issue11806] Missing 2 hyphens in the docs
In-Reply-To: <BANLkTin7HMUqE10AmQA_Bps4z0cONYcM=A@mail.gmail.com>
Message-ID: <BANLkTikm_shp_-msVunjn5oLJpHoUKcYEw@mail.gmail.com>


Eli Bendersky <eliben at gmail.com> added the comment:

On Wed, Apr 13, 2011 at 14:54, Bo?tjan Mejak <report at bugs.python.org> wrote:
>
> Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:
>
> Also, please fix the main title of the argparse section...
>
> from
> 15.4. argparse<http://docs.python.org/dev/library/argparse.html#module-argparse>
> ???
> Parser for command line options, arguments and sub-commands
> to
> 15.4. argparse<http://docs.python.org/dev/library/argparse.html#module-argparse>
> ???
> Parser for command-line options, arguments and sub-commands
> Please note the added hyphen (-) for the word command-line. Since this is
> actually one word, it needs the hyphen. This is not Python related, but is
> orthology related. Please fix all this documentation imprecisions in the
> section argparse. Won't take a minute.
>

Bo?tjan, please stop this trolling. You were told by two core-devs
that it won't be fixed. There's no use keeping spamming the mailing
list.

A short googling shows that the jury is still out on the question of
whether command-line is more correct than command line. Some places
use a hyphen, some don't. This really isn't important enough to call
for hunting out hyphen-less spellings throughout the docs.

If you want to contribute to Python, please find issues with substance
to raise. As it is now, you're only harming Python by wasting the time
of core developers.

Eli

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11806>
_______________________________________

From report at bugs.python.org  Wed Apr 13 15:07:28 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Apr 2011 13:07:28 +0000
Subject: [issue11701] email.parser.BytesParser().parse() closes file argument
In-Reply-To: <1301315420.28.0.123524956156.issue11701@psf.upfronthosting.co.za>
Message-ID: <1302700048.48.0.105095789744.issue11701@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

For easy reference, here's a hash for that changeset that roundup will turn into a link: e727cf354720.

TestIdempotent is already run for both the bytes and str cases (they are widely separated in the test file...I'll fix that at some point).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11701>
_______________________________________

From report at bugs.python.org  Wed Apr 13 15:10:32 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Apr 2011 13:10:32 +0000
Subject: [issue8809] smtplib should support SSL contexts
In-Reply-To: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>
Message-ID: <1302700232.12.0.112331010701.issue8809@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/issue8809>
_______________________________________

From report at bugs.python.org  Wed Apr 13 15:34:54 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 13 Apr 2011 13:34:54 +0000
Subject: [issue11701] email.parser.BytesParser().parse() closes file argument
In-Reply-To: <1302700048.48.0.105095789744.issue11701@psf.upfronthosting.co.za>
Message-ID: <20110413133444.GA81644@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

On Wed, Apr 13, 2011 at 01:07:28PM +0000, R. David Murray wrote:
> TestIdempotent is already run for both the bytes and str cases

(*^.^*)
Ouch.  Searching is only for the experienced.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11701>
_______________________________________

From report at bugs.python.org  Wed Apr 13 15:52:35 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 13 Apr 2011 13:52:35 +0000
Subject: [issue11701] email.parser.BytesParser().parse() closes file argument
In-Reply-To: <1301315420.28.0.123524956156.issue11701@psf.upfronthosting.co.za>
Message-ID: <20110413135226.GA89719@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

So i'll changed the existing message_from_(binary_)?file() tests
to also test the file closing.

----------
Added file: http://bugs.python.org/file21649/11701.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11701>
_______________________________________
-------------- next part --------------
diff --git a/Lib/email/parser.py b/Lib/email/parser.py
--- a/Lib/email/parser.py
+++ b/Lib/email/parser.py
@@ -100,9 +100,9 @@
         meaning it parses the entire contents of the file.
         """
         fp = TextIOWrapper(fp, encoding='ascii', errors='surrogateescape')
-        with fp:
-            return self.parser.parse(fp, headersonly)
-
+        msg = self.parser.parse(fp, headersonly)
+        fp.detach()
+        return msg
 
     def parsebytes(self, text, headersonly=False):
         """Create a message structure from a byte string.
diff --git a/Lib/test/test_email/test_email.py b/Lib/test/test_email/test_email.py
--- a/Lib/test/test_email/test_email.py
+++ b/Lib/test/test_email/test_email.py
@@ -2268,16 +2268,18 @@
         self.assertEqual(text, s.getvalue())
 
     def test_message_from_file(self):
-        with openfile('msg_01.txt') as fp:
-            text = fp.read()
-            fp.seek(0)
-            msg = email.message_from_file(fp)
-            s = StringIO()
-            # Don't wrap/continue long headers since we're trying to test
-            # idempotency.
-            g = Generator(s, maxheaderlen=0)
-            g.flatten(msg)
-            self.assertEqual(text, s.getvalue())
+        fp = openfile('msg_01.txt')
+        text = fp.read()
+        fp.seek(0)
+        msg = email.parser.Parser().parse(fp)
+        self.assertFalse(fp.closed)
+        fp.close()
+        s = StringIO()
+        # Don't wrap/continue long headers since we're trying to test
+        # idempotency.
+        g = Generator(s, maxheaderlen=0)
+        g.flatten(msg)
+        self.assertEqual(text, s.getvalue())
 
     def test_message_from_string_with_class(self):
         unless = self.assertTrue
@@ -3181,9 +3183,11 @@
         self.addCleanup(unlink, fn)
         with open(fn, 'wb') as testfile:
             testfile.write(self.non_latin_bin_msg)
-        with open(fn, 'rb') as testfile:
-            m = email.parser.BytesParser().parse(testfile)
+        fp = open(fn, 'rb')
+        m = email.parser.BytesParser().parse(fp)
+        self.assertFalse(fp.closed)
         self.assertEqual(str(m), self.non_latin_bin_msg_as7bit)
+        fp.close()
 
     latin_bin_msg = textwrap.dedent("""\
         From: foo at bar.com

From report at bugs.python.org  Wed Apr 13 15:53:25 2011
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 13 Apr 2011 13:53:25 +0000
Subject: [issue10332] Multiprocessing maxtasksperchild results in hang
In-Reply-To: <1302682792.7.0.614141789982.issue10332@psf.upfronthosting.co.za>
Message-ID: <BANLkTin7H6HLQqnD4Pjrj03n-zYWaUFgWw@mail.gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

> Note: I noticed that there are some thread-unsafe operations (the cache that can be modified from different threads, and thread states are modified also from different threads). While this isn't an issue with the current cPython implementation (GIL), I wonder if this should be fixed.
>

Yes. We should fix those.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10332>
_______________________________________

From report at bugs.python.org  Wed Apr 13 17:12:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Apr 2011 15:12:33 +0000
Subject: [issue11186] pydoc: HTMLDoc.index() doesn't support PEP 383
In-Reply-To: <1297428909.69.0.247564466299.issue11186@psf.upfronthosting.co.za>
Message-ID: <1302707553.69.0.741847199767.issue11186@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The wording ?pydoc ignores a module? is confusing to me: I can?t tell whether it is a description of the bug (?pydoc ignored a module?) or the new, correct behavior (?pydoc now ignores a module?).

Regarding the problem and fix itself, I?m wondering.  If a user unknowingly creates such a module with an unencodable filename, will they understand why pydoc does not display it?

----------
nosy: +eric.araujo, lemburg, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11186>
_______________________________________

From report at bugs.python.org  Wed Apr 13 17:18:11 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 13 Apr 2011 15:18:11 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1302707891.42.0.11532547286.issue11828@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Some comments posted in the review.

Could you possibly post a patch for 2.7 too?.

Thanks.

If any other reviewer agree, I will commit the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Wed Apr 13 17:24:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Apr 2011 15:24:09 +0000
Subject: [issue11186] pydoc: HTMLDoc.index() doesn't support PEP 383
In-Reply-To: <1297428909.69.0.247564466299.issue11186@psf.upfronthosting.co.za>
Message-ID: <1302708249.86.0.453357634007.issue11186@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> If a user unknowingly creates such a module with an unencodable
> filename, will they understand why pydoc does not display it?

It is really a bad idea to choose an *undecodable* name for a module. You will not be able to write its name using "import name" syntax.

(It is possible to import such module using __import__, but it is just ugly)

For the changelog, feel free to rephrase it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11186>
_______________________________________

From report at bugs.python.org  Wed Apr 13 17:25:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Apr 2011 15:25:05 +0000
Subject: [issue3051] heapq change breaking compatibility
In-Reply-To: <1212755858.43.0.854603033808.issue3051@psf.upfronthosting.co.za>
Message-ID: <1302708305.32.0.800755773675.issue3051@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The global docs index has one entry for ?comparison?, which is http://docs.python.org/dev/reference/expressions#not-in
This other page says that ?in general, __lt__() and __eq__() are sufficient, if you want the conventional meanings of the comparison operators?: http://docs.python.org/dev/library/stdtypes.html#comparisons

Other useful bits:
http://docs.python.org/dev/reference/datamodel#object.__lt__
http://docs.python.org/dev/library/functions#sorted
http://docs.python.org/dev/library/functools#functools.cmp_to_key
http://docs.python.org/dev/howto/sorting#odd-and-ends

It may be useful to add more cross-links between those places (especially pointing to the first link).

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3051>
_______________________________________

From report at bugs.python.org  Wed Apr 13 17:40:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Apr 2011 15:40:47 +0000
Subject: [issue10976] json.loads() throws TypeError on bytes object
In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za>
Message-ID: <1302709247.01.0.847888785279.issue10976@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If you?re talking about deprecating the obsolete encoding argument (maybe it?s time for a new bug report), +1.

----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10976>
_______________________________________

From report at bugs.python.org  Wed Apr 13 17:42:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Apr 2011 15:42:18 +0000
Subject: [issue11827] mention of list2cmdline() in docs of subprocess.Popen
In-Reply-To: <1302511097.53.0.993242324349.issue11827@psf.upfronthosting.co.za>
Message-ID: <1302709338.92.0.94796661657.issue11827@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

LGTM.

----------
versions: +Python 2.7, Python 3.1, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11827>
_______________________________________

From report at bugs.python.org  Wed Apr 13 17:43:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Apr 2011 15:43:38 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory (sysconfig._getuserbase)
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1302709418.28.0.256955405287.issue10496@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can someone explain how it can happen that a user has no home directory?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10496>
_______________________________________

From report at bugs.python.org  Wed Apr 13 17:50:09 2011
From: report at bugs.python.org (Brian Bi)
Date: Wed, 13 Apr 2011 15:50:09 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory (sysconfig._getuserbase)
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1302709809.06.0.326273454237.issue10496@psf.upfronthosting.co.za>


Brian Bi <bbi5291 at gmail.com> added the comment:

I discovered this while I was implementing and testing a sandbox for automatic evaluation of programs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10496>
_______________________________________

From report at bugs.python.org  Wed Apr 13 18:21:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Apr 2011 16:21:38 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory (sysconfig._getuserbase)
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1302711698.04.0.385198295738.issue10496@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can you be more precise?  IOW, why is this a Python bug rather than a system misconfiguration?  Note that I don?t know a lot about POSIX, so I?m open to change my mind.

----------
stage: needs patch -> 
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10496>
_______________________________________

From report at bugs.python.org  Wed Apr 13 18:29:48 2011
From: report at bugs.python.org (Armin Rigo)
Date: Wed, 13 Apr 2011 16:29:48 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1302712188.88.0.74086272522.issue10399@psf.upfronthosting.co.za>


Changes by Armin Rigo <arigo at users.sourceforge.net>:


----------
nosy:  -arigo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10399>
_______________________________________

From report at bugs.python.org  Wed Apr 13 18:30:18 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 13 Apr 2011 16:30:18 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1302712218.34.0.932204864343.issue11277@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> By the way, at this point I think we could simply skip the test on BSDs
> and OS X. The tested functionality is cross-platform, so testing under
> a limited set of systems should be ok.

Another solution would be to rewrite the test to not use mmap() at all:

    @precisionbigmemtest(size=_4G + 4, memuse=1)
    def test_big_buffer(self, size):
        if size < _4G + 4:
            self.skipTest("not enough free memory, need at least 4 GB")
        data = bytearray(_4G + 4)
        data[-4:] = b"asdf"
        self.assertEqual(zlib.crc32(data), 3058686908)
        self.assertEqual(zlib.adler32(data), 82837919)

This is more consistent with the other bigmem tests in test_zlib, but
I'm guessing it will mean that the test gets run much less often (since a
lot of machines won't have enough memory). If that's OK, then I'd prefer
doing it this way (since it keeps things simpler). Otherwise, skipping
the test on OS X sounds fine to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Wed Apr 13 18:53:31 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Wed, 13 Apr 2011 16:53:31 +0000
Subject: [issue11841] Bug in the verson comparison
In-Reply-To: <1302686380.66.0.407051830429.issue11841@psf.upfronthosting.co.za>
Message-ID: <1302713611.38.0.270921512024.issue11841@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Here is a patch that I made against distutils2 tip. I have changed _FINAL_MARKER from 'f' to 'z', which works with rc. Also I have added constant _FINAL_MARKER_CHAR, since later in the code you make a check against 'f' and it surprised me a little at first. There are also tests in the patch. I hope it's good to make patch against the distutils2, since I couldn't yet find packaging in cpython default branch.

----------
keywords: +patch
nosy: +gruszczy
Added file: http://bugs.python.org/file21650/11841.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11841>
_______________________________________

From report at bugs.python.org  Wed Apr 13 19:23:51 2011
From: report at bugs.python.org (Torsten Becker)
Date: Wed, 13 Apr 2011 17:23:51 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1302715431.31.0.809026334816.issue11828@psf.upfronthosting.co.za>


Torsten Becker <torsten.becker at gmail.com> added the comment:

> Some comments posted in the review.

I'm not sure if my review reply got mailed as I did not get a copy and nothing showed up here.  I added some responses/follow up questions in the review.

> Could you possibly post a patch for 2.7 too?.

Sure, I'll write the next version against 3.3 and 2.7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Wed Apr 13 19:33:54 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 13 Apr 2011 17:33:54 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1302716034.71.0.187171345517.issue11828@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I got your comments, Torsten. I finds funny too that the tracker is not notified.

I wrote new comments too, but not using "the right way", so now I am the one not sure you got them... :-)

Go for the 3.3/2.7 patch. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Wed Apr 13 19:43:42 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 13 Apr 2011 17:43:42 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1302716622.5.0.36770637313.issue11828@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Better to have a 3.1/2.7 patch. The current workflow requires to patch the old version first (3.1), and up-port the change to 3.2 and 3.3.

So, 2.7 and 3.1 would be more useful. Al least if the patch applies to 3.2 and 3.3 easily. If major surgery is needed, let me know.

PS: If you use mercurial, try to upload the patch directly from it. See the "Remote hg repo" box.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Wed Apr 13 20:16:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Apr 2011 18:16:13 +0000
Subject: [issue3051] heapq change breaking compatibility
In-Reply-To: <1212755858.43.0.854603033808.issue3051@psf.upfronthosting.co.za>
Message-ID: <E1QA4bo-00065N-PV@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 103a2eb61069 by Raymond Hettinger in branch '2.7':
Issue 3051: make pure python code pass the same tests as the C version.
http://hg.python.org/cpython/rev/103a2eb61069

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3051>
_______________________________________

From report at bugs.python.org  Wed Apr 13 20:19:03 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 13 Apr 2011 18:19:03 +0000
Subject: [issue3051] heapq change breaking compatibility
In-Reply-To: <1212755858.43.0.854603033808.issue3051@psf.upfronthosting.co.za>
Message-ID: <1302718743.08.0.937462990853.issue3051@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Maciek, I added the compatability code to the Python version as requested.  Now the tests pass for both versions.  There is still work to be done to automatically run both versions against the test suite.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3051>
_______________________________________

From report at bugs.python.org  Wed Apr 13 20:48:04 2011
From: report at bugs.python.org (Felipe Cruz)
Date: Wed, 13 Apr 2011 18:48:04 +0000
Subject: [issue7484] smtplib: verify breaks with Postfix servers
In-Reply-To: <1260600956.23.0.0101749869854.issue7484@psf.upfronthosting.co.za>
Message-ID: <1302720484.53.0.332389924655.issue7484@psf.upfronthosting.co.za>


Felipe Cruz <felipecruz at loogica.net> added the comment:

David..

I extracted quoteaddr code to _addrformat and now quoteaddr and _addronly call _addrformat passing a format (<%s> or %s).

I've also created quoteaddr and _addronly test functions as well modified VRFY and EXPN tests to make sure they call _addronly and pointed brackets aren't added.

Let me know if those patches still need improvements.

----------
Added file: http://bugs.python.org/file21651/issue7484-py3k_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7484>
_______________________________________

From report at bugs.python.org  Wed Apr 13 20:48:21 2011
From: report at bugs.python.org (Felipe Cruz)
Date: Wed, 13 Apr 2011 18:48:21 +0000
Subject: [issue7484] smtplib: verify breaks with Postfix servers
In-Reply-To: <1260600956.23.0.0101749869854.issue7484@psf.upfronthosting.co.za>
Message-ID: <1302720501.99.0.133552518103.issue7484@psf.upfronthosting.co.za>


Changes by Felipe Cruz <felipecruz at loogica.net>:


Added file: http://bugs.python.org/file21652/issue7484-27_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7484>
_______________________________________

From report at bugs.python.org  Wed Apr 13 20:51:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Apr 2011 18:51:06 +0000
Subject: [issue3051] heapq change breaking compatibility
In-Reply-To: <1212755858.43.0.854603033808.issue3051@psf.upfronthosting.co.za>
Message-ID: <E1QA59d-00013B-2v@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 83e4765ec4cb by Raymond Hettinger in branch '3.2':
Issue 3051: make pure python code pass the same tests as the C version.
http://hg.python.org/cpython/rev/83e4765ec4cb

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3051>
_______________________________________

From report at bugs.python.org  Wed Apr 13 21:14:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Apr 2011 19:14:53 +0000
Subject: [issue11783] email parseaddr and formataddr should be IDNA aware
In-Reply-To: <1302099121.47.0.140525796896.issue11783@psf.upfronthosting.co.za>
Message-ID: <1302722093.81.0.651536462549.issue11783@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK, so when I went to apply this, I figured out that the patch isn't quite right.  I've redone the doc updates, and am attaching a version of the patch containing them.

The issue is that the place that the IDNA decode support needs to be added isn't in parseaddr, it's in _parseaddr.py's AddresslistClass.  Tests are then needed to make sure that the IDNA decoding gets done both when parseaddr and getaddresslist are used.

Do you want to tackle this, Torsten?

----------
Added file: http://bugs.python.org/file21653/email_address_idna.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11783>
_______________________________________

From report at bugs.python.org  Wed Apr 13 21:27:17 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 13 Apr 2011 19:27:17 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1302722837.2.0.582549331697.issue11277@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Just to give another data point: A couple of days ago I reduced the
memory on the AMD64 FreeBSD bot to (375MB RAM, 2GB swap) and the zlib
tests still pass.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Wed Apr 13 22:25:42 2011
From: report at bugs.python.org (Bryce Verdier)
Date: Wed, 13 Apr 2011 20:25:42 +0000
Subject: =?utf-8?q?=5Bissue4783=5D_document_that_json=2Eload/dump_can=E2=80=99t_be?=
	=?utf-8?q?_used_twice_on_the_same_stream?=
In-Reply-To: <1230657409.93.0.0443603821797.issue4783@psf.upfronthosting.co.za>
Message-ID: <1302726342.56.0.245369966892.issue4783@psf.upfronthosting.co.za>


Bryce Verdier <bryceverdier at gmail.com> added the comment:

Not to nitpick, but what about the wording used in the simplejson documentation that Bob wrote almost 3 years ago? 

Note
JSON is not a framed protocol so unlike pickle or marshal it does not make sense to serialize more than one JSON document without some container protocol to delimit them

I also feel that it sounds a little bit cleaner.

http://simplejson.github.com/simplejson/#simplejson.dump

----------
nosy: +louiscipher

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4783>
_______________________________________

From report at bugs.python.org  Wed Apr 13 22:35:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Apr 2011 20:35:07 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1302712218.34.0.932204864343.issue11277@psf.upfronthosting.co.za>
Message-ID: <1302726903.3600.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Another solution would be to rewrite the test to not use mmap() at all:
> 
>     @precisionbigmemtest(size=_4G + 4, memuse=1)
>     def test_big_buffer(self, size):
>         if size < _4G + 4:
>             self.skipTest("not enough free memory, need at least 4 GB")
>         data = bytearray(_4G + 4)
>         data[-4:] = b"asdf"
>         self.assertEqual(zlib.crc32(data), 3058686908)
>         self.assertEqual(zlib.adler32(data), 82837919)
> 
> This is more consistent with the other bigmem tests in test_zlib, but
> I'm guessing it will mean that the test gets run much less often (since a
> lot of machines won't have enough memory). If that's OK, then I'd prefer
> doing it this way (since it keeps things simpler).

I think there's basically noone and nothing (even among the buildbots)
that runs bigmem tests on a regular basis, so I'd much rather keep the
mmap() solution, even if that means it must be skipped on OS X.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Wed Apr 13 22:46:39 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Apr 2011 20:46:39 +0000
Subject: [issue11684] Add email.parser.BytesHeaderParser
In-Reply-To: <1301151932.52.0.667036895822.issue11684@psf.upfronthosting.co.za>
Message-ID: <E1QA6xR-0003LT-Hp@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a95d936ce8eb by R David Murray in branch 'default':
#11684: Complete parser bytes interface by adding BytesHeaderParser
http://hg.python.org/cpython/rev/a95d936ce8eb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11684>
_______________________________________

From report at bugs.python.org  Wed Apr 13 22:48:03 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Apr 2011 20:48:03 +0000
Subject: [issue11782] email.generator.Generator.flatten() fails
In-Reply-To: <1302097785.46.0.28701143911.issue11782@psf.upfronthosting.co.za>
Message-ID: <1302727683.61.0.269547587422.issue11782@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I applied this as part of #11684.  Thanks.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11782>
_______________________________________

From report at bugs.python.org  Wed Apr 13 22:48:14 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 13 Apr 2011 20:48:14 +0000
Subject: [issue11806] Missing 2 hyphens in the docs
In-Reply-To: <BANLkTikm_shp_-msVunjn5oLJpHoUKcYEw@mail.gmail.com>
Message-ID: <BANLkTi=4W4qCiQNGL5CoCzm1PzkTSJ1Uzg@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

If you'd look into the English dictionary, you'd find words like
coffee-table and command-line and built-in and user-friendly. The main
bother in this issue is the inconsistency with the wording "command-line".
Somewhere under the argparse section of the docs it is "command line" and
then shortly after it is "command-line". Make up your mind and be consistent
with one wording. I propose to let it be "command-line" as the major
dictionary of English language writes it, with a hyphen that is. Thank you.

----------
Added file: http://bugs.python.org/file21654/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11806>
_______________________________________
-------------- next part --------------
If you&#39;d look into the English dictionary, you&#39;d find words like coffee-table and command-line and built-in and user-friendly. The main bother in this issue is the inconsistency with the wording &quot;command-line&quot;. Somewhere under the argparse section of the docs it is &quot;command line&quot; and then shortly after it is &quot;command-line&quot;. Make up your mind and be consistent with one wording. I propose to let it be &quot;command-line&quot; as the major dictionary of English language writes it, with a hyphen that is. Thank you.

From report at bugs.python.org  Wed Apr 13 22:48:35 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Apr 2011 20:48:35 +0000
Subject: [issue11684] Add email.parser.BytesHeaderParser
In-Reply-To: <1301151932.52.0.667036895822.issue11684@psf.upfronthosting.co.za>
Message-ID: <1302727715.67.0.555728274967.issue11684@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for correcting my oversight :)

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11684>
_______________________________________

From report at bugs.python.org  Wed Apr 13 22:48:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Apr 2011 20:48:53 +0000
Subject: [issue11684] Add email.parser.BytesHeaderParser
In-Reply-To: <1301151932.52.0.667036895822.issue11684@psf.upfronthosting.co.za>
Message-ID: <1302727733.1.0.59267939562.issue11684@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11684>
_______________________________________

From report at bugs.python.org  Wed Apr 13 22:50:53 2011
From: report at bugs.python.org (Daniel Urban)
Date: Wed, 13 Apr 2011 20:50:53 +0000
Subject: [issue11842] slice.indices with negative step and default stop
In-Reply-To: <1302727853.06.0.703796407001.issue11842@psf.upfronthosting.co.za>
Message-ID: <1302727853.06.0.703796407001.issue11842@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

slice.indices behaves strangely with negative step and default stop values (note that the doc says that it "computes information about the slice that the slice object would describe if applied to a sequence of length items"):

>>> s = slice(None, None, -2)
>>> s.indices(10)
(9, -1, -2)
>>> list(range(10))[9:-1:-2]
[]
>>> list(range(10))[s]
[9, 7, 5, 3, 1]
>>> 

Also with start given:

>>> s = slice(8, None, -2)
>>> s.indices(10)
(8, -1, -2)
>>> list(range(10))[8:-1:-2]
[]
>>> list(range(10))[s]
[8, 6, 4, 2, 0]
>>> 

Strangely giving these indices to range works:

>>> s = slice(8, None, -2)
>>> s.indices(10)
(8, -1, -2)
>>> list(range(8, -1, -2))
[8, 6, 4, 2, 0]
>>>

----------
components: Interpreter Core
messages: 133694
nosy: durban, mark.dickinson
priority: normal
severity: normal
status: open
title: slice.indices with negative step and default stop
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11842>
_______________________________________

From report at bugs.python.org  Wed Apr 13 23:19:52 2011
From: report at bugs.python.org (Torsten Becker)
Date: Wed, 13 Apr 2011 21:19:52 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1302729592.32.0.410992270036.issue11828@psf.upfronthosting.co.za>


Torsten Becker <torsten.becker at gmail.com> added the comment:

> I got your comments, Torsten. I finds funny too that the tracker is
> not notified.
> I wrote new comments too, but not using "the right way", so now I am
> the one not sure you got them... :-)

That time I actually got a separate mail. :)

> Better to have a 3.1/2.7 patch. The current workflow requires to
> patch the old version first (3.1), and up-port the change to 3.2 and
> 3.3.
> So, 2.7 and 3.1 would be more useful. Al least if the patch applies
> to 3.2 and 3.3 easily. If major surgery is needed, let me know.

I uploaded an improved v4 patch against 2.7 and 3.1.  patch does not apply it cleanly in the 3.2 and 3.3 branches, though.

This is mostly because Objects/stringlib/find.h has changed too much and the #define STRINGLIB_IS_UNICODE (3.3, 3.2) is called FROM_UNICODE in 3.1.  The other files work fine.

It should be no problem to merge this up by hand, though.

> PS: If you use mercurial, try to upload the patch directly from it.
> See the "Remote hg repo" box.

I'm using Mercurial, but unfortunately hg hangs forever when trying to push to bitbucket, so I am just sticking with patches for now.

----------
Added file: http://bugs.python.org/file21655/issue-11828-v4-3.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Wed Apr 13 23:20:11 2011
From: report at bugs.python.org (Torsten Becker)
Date: Wed, 13 Apr 2011 21:20:11 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1302729611.5.0.844452957466.issue11828@psf.upfronthosting.co.za>


Changes by Torsten Becker <torsten.becker at gmail.com>:


Added file: http://bugs.python.org/file21656/issue-11828-v4-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Wed Apr 13 23:42:22 2011
From: report at bugs.python.org (Torsten Becker)
Date: Wed, 13 Apr 2011 21:42:22 +0000
Subject: [issue11783] email parseaddr and formataddr should be IDNA aware
In-Reply-To: <1302722093.81.0.651536462549.issue11783@psf.upfronthosting.co.za>
Message-ID: <BANLkTiktd95wHehWnrYX-XTA7Gnkwv4sbw@mail.gmail.com>


Torsten Becker <torsten.becker at gmail.com> added the comment:

> OK, so when I went to apply this, I figured out that the patch isn't quite right. ?I've redone the doc updates, and am attaching a version of the patch containing them.
>
> The issue is that the place that the IDNA decode support needs to be added isn't in parseaddr, it's in _parseaddr.py's AddresslistClass. ?Tests are then needed to make sure that the IDNA decoding gets done both when parseaddr and getaddresslist are used.
>
> Do you want to tackle this, Torsten?

I would like to, but I probably will not get to it before Monday.  So
if anybody wants to work on this before that time, please feel free to
fix it properly. :)

Just two questions for the implementation:
  1. Would it be fine to move the helper _encode_decode_addr() into
_parseaddr.py and then import it in util.py, so it can be shared
between the two?
  2. Would line 232 in _parseaddr.py (AddrlistClass.getaddrlist) be a
good place to integrate it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11783>
_______________________________________

From report at bugs.python.org  Wed Apr 13 23:43:24 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 13 Apr 2011 21:43:24 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1302731004.67.0.123840940949.issue11277@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> I think there's basically noone and nothing (even among the buildbots)
> that runs bigmem tests on a regular basis, so I'd much rather keep the
> mmap() solution, even if that means it must be skipped on OS X.

Fair enough.

(As an aside, if it is preferable to use an mmap() hack for this sort of
test, it would be good to add some machinery to test.support to make it
easier to use. But that's something for a separate issue.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Wed Apr 13 23:43:39 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 13 Apr 2011 21:43:39 +0000
Subject: [issue11840] Improvements to c-api/unicode documentation
In-Reply-To: <4DA4CA78.4090607@egenix.com>
Message-ID: <BANLkTikfMrU7FmRLkf3sntnE2NXLAvUjeA@mail.gmail.com>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

On Tue, Apr 12, 2011 at 23:56, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
> I think you misunderstood: when reorganizing the contents of
> a file, it's better to apply the patch to all branches, rather
> than just the current, since otherwise future patches that do
> have to be merged to all branches would cause lots of merge
> conflicts.

the problem is: the file Doc/c-api/unicode.rst is already different
between all the "open" branches. I'll provide patches for each of
them, or specify where the patch can be merged (and from where).

> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
>
> Rewrapping the paragraphs you are changing is fine, the others can be left as they are.

Once I was told not to, since in this case it will hide the changes I
made in between the rewrap.

> Patches should be against the oldest branch where they can be applied, and since this is a doc patch it can go in 2.7 and 3.1 too.

I'm just about to prepare patches for all the supported branches
(where a merge is not possible).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11840>
_______________________________________

From report at bugs.python.org  Thu Apr 14 00:02:22 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Apr 2011 22:02:22 +0000
Subject: [issue11783] email parseaddr and formataddr should be IDNA aware
In-Reply-To: <1302099121.47.0.140525796896.issue11783@psf.upfronthosting.co.za>
Message-ID: <1302732142.93.0.537615932331.issue11783@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, putting the function in _parseaddr is fine.  And yes, 232 looks like a good place.  The alternative would be understanding the rfc822 parser, which is pretty mind bending, and of doubtful additional benefit.  (At most it would save a pair of split/join calls.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11783>
_______________________________________

From report at bugs.python.org  Thu Apr 14 00:05:26 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 13 Apr 2011 22:05:26 +0000
Subject: [issue9544] xdrlib.Packer().pack_fstring throws a TypeError when
	called with a str()
In-Reply-To: <1281333086.43.0.820305754452.issue9544@psf.upfronthosting.co.za>
Message-ID: <1302732326.63.0.869150826452.issue9544@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This doesn't really make sense, since XDR doesn't seem to say anything about unicode strings, just bytes.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9544>
_______________________________________

From report at bugs.python.org  Thu Apr 14 00:26:46 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 13 Apr 2011 22:26:46 +0000
Subject: [issue9101] reference json format in file formats chapter
In-Reply-To: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>
Message-ID: <1302733606.36.0.595284556787.issue9101@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

These people look for alternative configuration format to .ini, for example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9101>
_______________________________________

From report at bugs.python.org  Thu Apr 14 00:40:09 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 13 Apr 2011 22:40:09 +0000
Subject: [issue11840] Improvements to c-api/unicode documentation
In-Reply-To: <1302643172.01.0.948666081662.issue11840@psf.upfronthosting.co.za>
Message-ID: <1302734409.78.0.887473901055.issue11840@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


Added file: http://bugs.python.org/file21657/unicode_doc-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11840>
_______________________________________

From report at bugs.python.org  Thu Apr 14 00:40:25 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 13 Apr 2011 22:40:25 +0000
Subject: [issue11840] Improvements to c-api/unicode documentation
In-Reply-To: <1302643172.01.0.948666081662.issue11840@psf.upfronthosting.co.za>
Message-ID: <1302734425.73.0.0472719958028.issue11840@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


Added file: http://bugs.python.org/file21658/unicode_doc-3.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11840>
_______________________________________

From report at bugs.python.org  Thu Apr 14 00:42:01 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 13 Apr 2011 22:42:01 +0000
Subject: [issue11840] Improvements to c-api/unicode documentation
In-Reply-To: <1302643172.01.0.948666081662.issue11840@psf.upfronthosting.co.za>
Message-ID: <1302734521.54.0.307180059817.issue11840@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

The status of the patches is this:

unicode_doc-2.7.patch - to be applied on 2.7
unicode_doc-3.1.patch - to be applied on 3.1
unicode_doc-default.patch - to be applied on 3.2 and then merged on default

I had to prepare multiple patches since the files are very different between supported branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11840>
_______________________________________

From report at bugs.python.org  Thu Apr 14 01:12:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Apr 2011 23:12:54 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1302736374.37.0.163839653612.issue2771@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file21659/sometext.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Thu Apr 14 01:41:07 2011
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Sebasti=C3=A3o_de_Oliveira_Bueno?=)
Date: Wed, 13 Apr 2011 23:41:07 +0000
Subject: [issue11842] slice.indices with negative step and default stop
In-Reply-To: <1302727853.06.0.703796407001.issue11842@psf.upfronthosting.co.za>
Message-ID: <1302738067.23.0.62178921904.issue11842@psf.upfronthosting.co.za>


Jo?o Sebasti?o de Oliveira Bueno <gwidion at gmail.com> added the comment:

I don't see this as a bug. The indices returned in both cases are exactly what you need to feed to range, in order to get the correct indices for the provided slice parameters.

Perceive that if for 
s = slice(None, None, -2)

It would return anything different from
(9, -1, -2)
It would be impossible to properly generate the desired indices. (With a 0 instead of -1, we would be missing the last index).

When you pass these numbers with the "[" "]" notation for being used as indices, the negative index is interpreted as "len(sequence) - index". In the case of "-1" in your example it is the same as "9" not the same as "one before zero".

I recommend closing this as not a bug.

----------
nosy: +Jo?o.Sebasti?o.de.Oliveira.Bueno

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11842>
_______________________________________

From report at bugs.python.org  Thu Apr 14 02:04:28 2011
From: report at bugs.python.org (Dirk Pranke)
Date: Thu, 14 Apr 2011 00:04:28 +0000
Subject: [issue4106] multiprocessing occasionally spits out exception during
	shutdown
In-Reply-To: <1223695822.85.0.145044917765.issue4106@psf.upfronthosting.co.za>
Message-ID: <1302739468.31.0.815001471458.issue4106@psf.upfronthosting.co.za>


Changes by Dirk Pranke <dpranke at chromium.org>:


----------
nosy: +dpranke

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4106>
_______________________________________

From report at bugs.python.org  Thu Apr 14 02:08:01 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 14 Apr 2011 00:08:01 +0000
Subject: [issue11701] email.parser.BytesParser().parse() closes file argument
In-Reply-To: <1301315420.28.0.123524956156.issue11701@psf.upfronthosting.co.za>
Message-ID: <1302739681.59.0.957628181849.issue11701@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/issue11701>
_______________________________________

From report at bugs.python.org  Thu Apr 14 04:51:42 2011
From: report at bugs.python.org (ackounts)
Date: Thu, 14 Apr 2011 02:51:42 +0000
Subject: [issue4537] webbrowser.UnixBrowser should use builtins.open
In-Reply-To: <1228427350.73.0.444727846196.issue4537@psf.upfronthosting.co.za>
Message-ID: <1302749502.72.0.861679362827.issue4537@psf.upfronthosting.co.za>


ackounts <ackounts at gmail.com> added the comment:

This problem is happening in my linux box:

Python 3.2 (r32:88445, Feb 21 2011, 01:55:53) 
[GCC 4.5.2 20110127 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import antigravity
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/antigravity.py", line 5, in <module>
    webbrowser.open("http://xkcd.com/353/")
  File "/usr/lib/python3.2/webbrowser.py", line 62, in open
    if browser.open(url, new, autoraise):
  File "/usr/lib/python3.2/webbrowser.py", line 276, in open
    success = self._invoke(args, True, autoraise)
  File "/usr/lib/python3.2/webbrowser.py", line 239, in _invoke
    stderr=inout, preexec_fn=setsid)
  File "/usr/lib/python3.2/subprocess.py", line 736, in __init__
    restore_signals, start_new_session)
  File "/usr/lib/python3.2/subprocess.py", line 1330, in _execute_child
    raise child_exception_type(errno_num, err_msg)
OSError: [Errno 9] Bad file descriptor
>>>

----------
nosy: +ackounts
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4537>
_______________________________________

From report at bugs.python.org  Thu Apr 14 05:01:35 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Apr 2011 03:01:35 +0000
Subject: =?utf-8?q?=5Bissue4783=5D_document_that_json=2Eload/dump_can=E2=80=99t_be?=
	=?utf-8?q?_used_twice_on_the_same_stream?=
In-Reply-To: <1230657409.93.0.0443603821797.issue4783@psf.upfronthosting.co.za>
Message-ID: <1302750095.36.0.177143558894.issue4783@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I saw that and found it not clear, that's why I rephrased it.
In order to understand that one has to know what is a "framed protocol", what can be considered a "JSON document" (is a single object a JSON document? or does it need to be serialized first?), what is a "container protocol" (can I use one? where can I find it? is there a default one for JSON?).

I think it's clearer to just say that you can't do json.dump(obj1, f); dump(obj2, f).
I also omitted the note on `load`, because if you can't add more objects to the same file using json.dump you won't even try to use json.load to extract them one by one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4783>
_______________________________________

From report at bugs.python.org  Thu Apr 14 05:54:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 Apr 2011 03:54:17 +0000
Subject: [issue9101] reference json format in file formats chapter
In-Reply-To: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>
Message-ID: <E1QADdH-0007gS-Qk@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d0ada1e369cd by Ezio Melotti in branch '3.1':
#9101: backport json reference in configparser doc.
http://hg.python.org/cpython/rev/d0ada1e369cd

New changeset 5a09a335e8e7 by Ezio Melotti in branch '2.7':
#9101: backport json reference in configparser doc.
http://hg.python.org/cpython/rev/5a09a335e8e7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9101>
_______________________________________

From report at bugs.python.org  Thu Apr 14 05:55:53 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Apr 2011 03:55:53 +0000
Subject: [issue9101] reference json format in file formats chapter
In-Reply-To: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>
Message-ID: <1302753353.65.0.109467575056.issue9101@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9101>
_______________________________________

From report at bugs.python.org  Thu Apr 14 06:52:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 Apr 2011 04:52:12 +0000
Subject: [issue11840] Improvements to c-api/unicode documentation
In-Reply-To: <1302643172.01.0.948666081662.issue11840@psf.upfronthosting.co.za>
Message-ID: <E1QAEXL-0003ba-8u@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 11c72a305eb5 by Ezio Melotti in branch '3.1':
#11840: Improve c-api/unicode documentation. Patch by Sandro Tosi.
http://hg.python.org/cpython/rev/11c72a305eb5

New changeset 62679f2ca9e5 by Ezio Melotti in branch '3.2':
#11840: Merge with 3.1.
http://hg.python.org/cpython/rev/62679f2ca9e5

New changeset 1f767f834e67 by Ezio Melotti in branch 'default':
#11840: Merge with 3.2.
http://hg.python.org/cpython/rev/1f767f834e67

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11840>
_______________________________________

From report at bugs.python.org  Thu Apr 14 06:54:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 Apr 2011 04:54:22 +0000
Subject: [issue11840] Improvements to c-api/unicode documentation
In-Reply-To: <1302643172.01.0.948666081662.issue11840@psf.upfronthosting.co.za>
Message-ID: <E1QAEZQ-0003f9-8S@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7f873729484c by Ezio Melotti in branch '2.7':
#11840: Improve c-api/unicode documentation. Patch by Sandro Tosi.
http://hg.python.org/cpython/rev/7f873729484c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11840>
_______________________________________

From report at bugs.python.org  Thu Apr 14 06:59:04 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 Apr 2011 04:59:04 +0000
Subject: [issue11474] url2pathname() handling of '/C|/' on Windows
In-Reply-To: <1299943823.36.0.437320049664.issue11474@psf.upfronthosting.co.za>
Message-ID: <E1QAEdy-0003vl-5y@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 4556f17356f2 by Senthil Kumaran in branch '2.7':
Fix Issue11474 - url2pathname() handling of '/C|/' on Windows
http://hg.python.org/cpython/rev/4556f17356f2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11474>
_______________________________________

From report at bugs.python.org  Thu Apr 14 07:02:16 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Apr 2011 05:02:16 +0000
Subject: [issue11840] Improvements to c-api/unicode documentation
In-Reply-To: <1302643172.01.0.948666081662.issue11840@psf.upfronthosting.co.za>
Message-ID: <1302757336.07.0.798896772361.issue11840@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the patch!

About the rewrapping:
  * rewrapping what you change is OK, because I know that you changed something and had to rewrap it;
  * leaving what you changed badly-wrapped is not OK, because it makes the doc a mess after a while;
  * rewrapping unrelated things with no changes in the same patch is not OK, because it's hard to see if it's just rewrapping or changes+rewrapping;
  * doing rewrap-only changes might be OK but usually not worth it, and if done it should be done on all the branches.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11840>
_______________________________________

From report at bugs.python.org  Thu Apr 14 07:05:00 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Apr 2011 05:05:00 +0000
Subject: [issue11840] Improvements to c-api/unicode documentation
In-Reply-To: <1302643172.01.0.948666081662.issue11840@psf.upfronthosting.co.za>
Message-ID: <1302757500.5.0.675877755851.issue11840@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: docs at python -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11840>
_______________________________________

From report at bugs.python.org  Thu Apr 14 07:20:45 2011
From: report at bugs.python.org (Buck Golemon)
Date: Thu, 14 Apr 2011 05:20:45 +0000
Subject: [issue8326] Cannot import name SemLock on Ubuntu lucid
In-Reply-To: <1270549791.67.0.929964356468.issue8326@psf.upfronthosting.co.za>
Message-ID: <1302758445.62.0.594730626517.issue8326@psf.upfronthosting.co.za>


Buck Golemon <buck.golemon at amd.com> added the comment:

On Ubuntu 10.10 (maverick), python2.6 is functioning correctly, but python2.7 is giving this error again.


$ /usr/bin/python2.7
>>> from multiprocessing.synchronize import Semaphore
ImportError: This platform lacks a functioning sem_open implementation, therefore, the required synchronization primitives needed will not function, see issue 3770.

----------
nosy: +bukzor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8326>
_______________________________________

From report at bugs.python.org  Thu Apr 14 07:21:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 Apr 2011 05:21:00 +0000
Subject: [issue11474] url2pathname() handling of '/C|/' on Windows
In-Reply-To: <1299943823.36.0.437320049664.issue11474@psf.upfronthosting.co.za>
Message-ID: <E1QAEzC-0005Lh-C1@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset de0da2759c8c by Senthil Kumaran in branch '3.1':
Fix Issue11474 - fix url2pathname() handling of '/C|/' on Windows
http://hg.python.org/cpython/rev/de0da2759c8c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11474>
_______________________________________

From report at bugs.python.org  Thu Apr 14 07:21:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 Apr 2011 05:21:00 +0000
Subject: [issue1147] string exceptions inconsistently deprecated/disabled
In-Reply-To: <1189523795.09.0.87571084132.issue1147@psf.upfronthosting.co.za>
Message-ID: <E1QAEzC-0005Lh-C9@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7563f10275a2 by Senthil Kumaran in branch 'default':
merge from 3.2.
http://hg.python.org/cpython/rev/7563f10275a2

----------
nosy: +python-dev
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1147>
_______________________________________

From report at bugs.python.org  Thu Apr 14 07:22:43 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 14 Apr 2011 05:22:43 +0000
Subject: [issue11474] url2pathname() handling of '/C|/' on Windows
In-Reply-To: <1299943823.36.0.437320049664.issue11474@psf.upfronthosting.co.za>
Message-ID: <1302758563.79.0.874794314962.issue11474@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Fixed in all the codelines. Thanks for the patch, Santoso.

----------
assignee:  -> orsenthil
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11474>
_______________________________________

From report at bugs.python.org  Thu Apr 14 08:07:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Apr 2011 06:07:45 +0000
Subject: [issue6191] HTMLParser attribute parsing - 2 test cases when it fails
In-Reply-To: <1244101614.1.0.195769853623.issue6191@psf.upfronthosting.co.za>
Message-ID: <1302761265.13.0.204677945555.issue6191@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The first case has been fixed already in 1cbfeffea19f, the second case is not even handled by browsers, so I'm closing this.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6191>
_______________________________________

From report at bugs.python.org  Thu Apr 14 08:22:00 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 14 Apr 2011 06:22:00 +0000
Subject: [issue8326] Cannot import name SemLock on Ubuntu lucid
In-Reply-To: <1270549791.67.0.929964356468.issue8326@psf.upfronthosting.co.za>
Message-ID: <1302762120.81.0.323898960656.issue8326@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I cannot reproduce this on Lucid with:

$ uname -r
2.6.32-28-generic


Isn't this an Ubuntu problem if sem_open only works with some
specific kernels?

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8326>
_______________________________________

From report at bugs.python.org  Thu Apr 14 08:55:07 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Apr 2011 06:55:07 +0000
Subject: [issue11710] Landing pages in docs for standard library packages
In-Reply-To: <1301401907.02.0.216152132906.issue11710@psf.upfronthosting.co.za>
Message-ID: <1302764107.64.0.113685415154.issue11710@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The packages without a landing page on 3.2 are:
  concurrent
  xml
  urllib
  http
  xmlrpc
  
In the concurrent case the problem could be solved with redirects too, since there's only one module in the package.  The other modules could provide a landing page that lists the modules in the package. (Note that the html page only lists html.escape, so the other modules could be added there too.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11710>
_______________________________________

From report at bugs.python.org  Thu Apr 14 12:01:45 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 14 Apr 2011 10:01:45 +0000
Subject: [issue9101] reference json format in file formats chapter
In-Reply-To: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>
Message-ID: <1302775305.28.0.415753499393.issue9101@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Wow. That's much better - python makes progress. Does this `robot` stuff flies back to Roundup? Is it possible to specify "closes bug #9101" directly in commit message?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9101>
_______________________________________

From report at bugs.python.org  Thu Apr 14 12:19:43 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Thu, 14 Apr 2011 10:19:43 +0000
Subject: [issue9544] xdrlib.Packer().pack_fstring throws a TypeError when
	called with a str()
In-Reply-To: <1281333086.43.0.820305754452.issue9544@psf.upfronthosting.co.za>
Message-ID: <1302776383.32.0.643373117253.issue9544@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Actually documentation doesn't say that it supports only bytes, but:

"The following methods support packing strings, bytes, and opaque data:"

Also under python2 you can easily do this:

In [1]: import xdrlib

In [2]: p = xdrlib.Packer()

In [3]: p.pack_string('some str')

In [4]: p.pack_string(u'some str')

So to conclude I believe either docs for python3 should be changed to say that only bytes are allowed or it should be changed to work as in python2. It's clear that in python2 some unicode string are accepted and I think we should allow such strings to be accepted in python3 too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9544>
_______________________________________

From report at bugs.python.org  Thu Apr 14 12:21:20 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Apr 2011 10:21:20 +0000
Subject: [issue9101] reference json format in file formats chapter
In-Reply-To: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>
Message-ID: <1302776480.45.0.17823147764.issue9101@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

It's just a mercurial hook that sends email, and yes, it's possible to close the issues automatically writing "closes #xxxx" in the commit message, but I prefer to close the issue manually.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9101>
_______________________________________

From report at bugs.python.org  Thu Apr 14 12:53:19 2011
From: report at bugs.python.org (Prashant Kumar)
Date: Thu, 14 Apr 2011 10:53:19 +0000
Subject: [issue10932] distutils.core.setup - data_files misbehaviour ?
In-Reply-To: <1295353825.23.0.755300594789.issue10932@psf.upfronthosting.co.za>
Message-ID: <1302778399.13.0.354487004147.issue10932@psf.upfronthosting.co.za>


Prashant Kumar <contactprashantat at gmail.com> added the comment:

I have added a test for the modification in msg127191. Though, inside zip-file we get files without its parent dir, nothing changes in manifest file(should it change?). Please have a look at the changeset https://bitbucket.org/pkumar/distutils2_bugs/changeset/7473385c23f2.

----------
hgrepos: +18
nosy: +Prashant.Kumar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10932>
_______________________________________

From report at bugs.python.org  Thu Apr 14 12:57:56 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 14 Apr 2011 10:57:56 +0000
Subject: [issue9101] reference json format in file formats chapter
In-Reply-To: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>
Message-ID: <1302778676.28.0.269963248451.issue9101@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Awesome. Especially links to actual changesets. BTW, there are only backport commits - where is the notification about the main one?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9101>
_______________________________________

From report at bugs.python.org  Thu Apr 14 12:59:30 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Apr 2011 10:59:30 +0000
Subject: [issue9101] reference json format in file formats chapter
In-Reply-To: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>
Message-ID: <1302778770.94.0.844275329571.issue9101@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

In msg123296, r86976.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9101>
_______________________________________

From report at bugs.python.org  Thu Apr 14 13:24:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Apr 2011 11:24:49 +0000
Subject: [issue8326] Cannot import name SemLock on Ubuntu lucid
In-Reply-To: <1270549791.67.0.929964356468.issue8326@psf.upfronthosting.co.za>
Message-ID: <1302780289.48.0.380504874535.issue8326@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8326>
_______________________________________

From report at bugs.python.org  Thu Apr 14 13:32:05 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Apr 2011 11:32:05 +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: <1302780725.86.0.482931658963.issue5057@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The attached patch skips the peepholer optimizations for BINARY_SUBSCR if the resulting char is a surrogate on narrow builds or a non-bmp char in wide builds.
Note that this affects the optimization of lone surrogates on narrow builds too, but I think it's not worth to adding more complexity on the peepholer and check if they are part of a surrogate pair.
The patch still lacks comments and could have better tests.

----------
keywords: +needs review, patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file21660/issue5057.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5057>
_______________________________________

From report at bugs.python.org  Thu Apr 14 13:36:39 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Apr 2011 11:36:39 +0000
Subject: [issue4537] webbrowser.UnixBrowser should use builtins.open
In-Reply-To: <1228427350.73.0.444727846196.issue4537@psf.upfronthosting.co.za>
Message-ID: <1302780999.76.0.564108515299.issue4537@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Despite the apparent similarity, your issue is something different from what was reported in this issue.  Could you please open a new issue for your problem?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4537>
_______________________________________

From report at bugs.python.org  Thu Apr 14 13:48:49 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 14 Apr 2011 11:48:49 +0000
Subject: [issue5057] Unicode-width dependent optimization leads
	to	non-portable pyc file
In-Reply-To: <1302780725.86.0.482931658963.issue5057@psf.upfronthosting.co.za>
Message-ID: <4DA6DF1B.2080201@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ezio Melotti wrote:
> 
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> 
> The attached patch skips the peepholer optimizations for BINARY_SUBSCR if the resulting char is a surrogate on narrow builds or a non-bmp char in wide builds.
> Note that this affects the optimization of lone surrogates on narrow builds too, but I think it's not worth to adding more complexity on the peepholer and check if they are part of a surrogate pair.
> The patch still lacks comments and could have better tests.

             newconst = PyObject_GetItem(v, w);
+            if (PyUnicode_Check(v)) {
+                Py_UNICODE ch = PyUnicode_AS_UNICODE(newconst)[0];

Without checking, you shouldn't assume that newconst is a PyUnicodeObject.

Other than that the patch looks fine.

----------
nosy: +lemburg
title: Unicode-width dependent optimization leads to non-portable pyc file -> Unicode-width dependent optimization leads to	non-portable pyc file

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5057>
_______________________________________

From report at bugs.python.org  Thu Apr 14 13:52:15 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Apr 2011 11:52:15 +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: <1302781935.69.0.298914461927.issue5057@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Are there any cases where v[w] -- where v is a unicode object -- returns a non-unicode object?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5057>
_______________________________________

From report at bugs.python.org  Thu Apr 14 13:53:58 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 14 Apr 2011 11:53:58 +0000
Subject: [issue9101] reference json format in file formats chapter
In-Reply-To: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>
Message-ID: <1302782038.22.0.444621535534.issue9101@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9101>
_______________________________________

From report at bugs.python.org  Thu Apr 14 13:57:14 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Apr 2011 11:57:14 +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: <1302782234.08.0.599071131147.issue5057@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5057>
_______________________________________

From report at bugs.python.org  Thu Apr 14 13:58:19 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 14 Apr 2011 11:58:19 +0000
Subject: [issue5057] Unicode-width dependent optimization
	leads	to	non-portable pyc file
In-Reply-To: <1302781935.69.0.298914461927.issue5057@psf.upfronthosting.co.za>
Message-ID: <4DA6E153.7020503@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ezio Melotti wrote:
> 
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> 
> Are there any cases where v[w] -- where v is a unicode object -- returns a non-unicode object?

There could be: either from subclasses or from buggy code. In any case,
macros should only be used if you're certain that the object cannot
be anything else.

Also note that newconst can well be NULL.

----------
title: Unicode-width dependent optimization leads to	non-portable pyc file -> Unicode-width dependent optimization leads	to	non-portable pyc file

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5057>
_______________________________________

From report at bugs.python.org  Thu Apr 14 14:05:32 2011
From: report at bugs.python.org (Steven Samuel Cole)
Date: Thu, 14 Apr 2011 12:05:32 +0000
Subject: [issue11843] distutils doc: duplicate line in table
In-Reply-To: <1302782732.33.0.79290372609.issue11843@psf.upfronthosting.co.za>
Message-ID: <1302782732.33.0.79290372609.issue11843@psf.upfronthosting.co.za>


New submission from Steven Samuel Cole <steven.samuel.cole at gmail.com>:

in the first table on http://docs.python.org/distutils/builtdist.html (search for 'available formats for built distributions'), the line with 'rpm / RPM / (5)' is in there twice

----------
assignee: docs at python
components: Documentation
messages: 133730
nosy: docs at python, ssc
priority: normal
severity: normal
status: open
title: distutils doc: duplicate line in table
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11843>
_______________________________________

From report at bugs.python.org  Thu Apr 14 14:31:06 2011
From: report at bugs.python.org (=?utf-8?q?Pawe=C5=82_Widera?=)
Date: Thu, 14 Apr 2011 12:31:06 +0000
Subject: [issue6191] HTMLParser attribute parsing - 2 test cases when it fails
In-Reply-To: <1244101614.1.0.195769853623.issue6191@psf.upfronthosting.co.za>
Message-ID: <1302784266.4.0.601948742163.issue6191@psf.upfronthosting.co.za>


Pawe? Widera <momat at man.poznan.pl> added the comment:

Great! With one "but"... the second case *is* handled by browsers. Browsers do not throw an exception on it as HTMLParser do. So improvement is definitely possible here. If it is worth an effort, it is not for me to judge.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6191>
_______________________________________

From report at bugs.python.org  Thu Apr 14 14:39:55 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Apr 2011 12:39:55 +0000
Subject: [issue6191] HTMLParser attribute parsing - 2 test cases when it fails
In-Reply-To: <1244101614.1.0.195769853623.issue6191@psf.upfronthosting.co.za>
Message-ID: <1302784795.75.0.0257200883481.issue6191@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

So you are suggesting that 
  <a href="http://xxx.org/xxx.php?a=1 target="_blank">click me</a>
should result in an 'a' element with an href attribute equals to "http://xxx.org/xxx.php?a=1 target=" and then discard _blank" as extra data?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6191>
_______________________________________

From report at bugs.python.org  Thu Apr 14 14:42:08 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Apr 2011 12:42:08 +0000
Subject: [issue11843] distutils doc: duplicate line in table
In-Reply-To: <1302782732.33.0.79290372609.issue11843@psf.upfronthosting.co.za>
Message-ID: <1302784928.03.0.523080543534.issue11843@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Distutils
nosy: +eric.araujo
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11843>
_______________________________________

From report at bugs.python.org  Thu Apr 14 14:56:37 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Apr 2011 12:56:37 +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: <1302785797.28.0.828421149704.issue5057@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here's a new patch that checks that newconst is not NULL and that it's a unicode object.
I added a test for the case where it's NULL.  I don't think it's possible to test the case when newconst is not unicode though, because unicode subclasses are not literals and don't get optimized in the first place.

----------
Added file: http://bugs.python.org/file21661/issue5057-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5057>
_______________________________________

From report at bugs.python.org  Thu Apr 14 15:02:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Apr 2011 13:02: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: <1302786161.87.0.938780638129.issue5057@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> ... which does not give the same result in UCS-2 and UCS-4 builds.
> As a result, the pyc file is not portable across those builds.

Since Python 3.2, the pyc filename contains a tag (u) to indicate wide build (sys.maxunicode==0x10FFFF), instead of narrow (sys.maxunicode==0xFFFF).

I think we can keep the optimizer for Python >= 3.2. I suppose that Python 3.1 has the bug.

----------
nosy: +haypo
versions: +Python 3.1 -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5057>
_______________________________________

From report at bugs.python.org  Thu Apr 14 15:03:48 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 14 Apr 2011 13:03:48 +0000
Subject: [issue9544] xdrlib.Packer().pack_fstring throws a TypeError when
	called with a str()
In-Reply-To: <1302776383.32.0.643373117253.issue9544@psf.upfronthosting.co.za>
Message-ID: <BANLkTinvgN-hdidTkPy3=KyqErYY0FcRJg@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/4/14 Filip Gruszczy?ski <report at bugs.python.org>:
>
> Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:
>
> Actually documentation doesn't say that it supports only bytes, but:
>
> "The following methods support packing strings, bytes, and opaque data:"
>
> Also under python2 you can easily do this:
>
> In [1]: import xdrlib
>
> In [2]: p = xdrlib.Packer()
>
> In [3]: p.pack_string('some str')
>
> In [4]: p.pack_string(u'some str')

I doubt u"?", will, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9544>
_______________________________________

From report at bugs.python.org  Thu Apr 14 15:11:56 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Thu, 14 Apr 2011 13:11:56 +0000
Subject: [issue9544] xdrlib.Packer().pack_fstring throws a TypeError when
	called with a str()
In-Reply-To: <1281333086.43.0.820305754452.issue9544@psf.upfronthosting.co.za>
Message-ID: <1302786716.5.0.611590215693.issue9544@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I am well aware of this, Benjamin. I am not trying to force any solution, but rather trying to point out, that current documentation is misleading. There might be no need for patching the code, but rather updating the docs to say, that only bytes are allowed and that will be sufficient.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9544>
_______________________________________

From report at bugs.python.org  Thu Apr 14 15:15:39 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 14 Apr 2011 13:15:39 +0000
Subject: [issue9544] xdrlib.Packer().pack_fstring throws a TypeError when
	called with a str()
In-Reply-To: <1302786716.5.0.611590215693.issue9544@psf.upfronthosting.co.za>
Message-ID: <BANLkTikzo9u5XvmLKjWNO05vS_xhDF7dGQ@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/4/14 Filip Gruszczy?ski <report at bugs.python.org>:
>
> Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:
>
> I am well aware of this, Benjamin. I am not trying to force any solution, but rather trying to point out, that current documentation is misleading. There might be no need for patching the code, but rather updating the docs to say, that only bytes are allowed and that will be sufficient.

Yes, I think a doc patch is the correct thing to do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9544>
_______________________________________

From report at bugs.python.org  Thu Apr 14 15:15:56 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 14 Apr 2011 13:15:56 +0000
Subject: [issue5057] Unicode-width dependent
	optimization	leads	to	non-portable pyc file
In-Reply-To: <1302785797.28.0.828421149704.issue5057@psf.upfronthosting.co.za>
Message-ID: <4DA6F387.2060903@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ezio Melotti wrote:
> 
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> 
> Here's a new patch that checks that newconst is not NULL and that it's a unicode object.
> I added a test for the case where it's NULL.  I don't think it's possible to test the case when newconst is not unicode though, because unicode subclasses are not literals and don't get optimized in the first place.

Thank you.

----------
title: Unicode-width dependent optimization leads	to	non-portable pyc file -> Unicode-width dependent optimization	leads	to	non-portable pyc file

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5057>
_______________________________________

From report at bugs.python.org  Thu Apr 14 15:22:05 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Thu, 14 Apr 2011 13:22:05 +0000
Subject: [issue9544] xdrlib.Packer().pack_fstring throws a TypeError when
	called with a str()
In-Reply-To: <1281333086.43.0.820305754452.issue9544@psf.upfronthosting.co.za>
Message-ID: <1302787325.6.0.499462852472.issue9544@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I'll provide docs patch.

----------
assignee:  -> docs at python
components: +Documentation -None
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9544>
_______________________________________

From report at bugs.python.org  Thu Apr 14 16:10:50 2011
From: report at bugs.python.org (Jack Andrews)
Date: Thu, 14 Apr 2011 14:10:50 +0000
Subject: [issue2571] can cmd.py's API/docs for the use of an alternate stdin
	be improved?
In-Reply-To: <1207594702.67.0.73869549091.issue2571@psf.upfronthosting.co.za>
Message-ID: <1302790250.07.0.104560675642.issue2571@psf.upfronthosting.co.za>


Jack Andrews <effbiae at gmail.com> added the comment:

hi guys,

this makes Cmd a bit more useful.

my use case is talking to pdb via pipe
(ie. subprocess module).  pdb doesn't 
behave very well if stdin is not a tty.


===================================================================
--- cmdpy.orig/cmd.py   2011-04-14 23:55:01.102867999 +1000
+++ cmdpy/cmd.py        2011-04-14 23:55:16.272868002 +1000
@@ -92,6 +92,8 @@
             self.stdin = stdin
         else:
             self.stdin = sys.stdin
+        if not stdin.isatty():
+            self.use_rawinput = 0
         if stdout is not None:
             self.stdout = stdout

----------
nosy: +Jack.Andrews

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2571>
_______________________________________

From report at bugs.python.org  Thu Apr 14 16:16:57 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 14 Apr 2011 14:16:57 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1302790617.52.0.308908133547.issue11277@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Pfff.
Now i really spent some time on Mac OS X memory management.
I did it for Wanda.  :)

(First: i don't know why you want to drop that nice mmap(2),
it's wonderful to test harddisk performance!
And if you want to support Apple, then you have to spend
some blood - right???
Implement a state machine, disallow mmap(2) if the file has
been written to.  Maybe i should spend some more hours and
try to find rules behind this??)

Situation is a follows.
Also here there are some nice sysctl(8) variables:

    hw.memsize: 2147483648
    hw.usermem = 1651843072
    vm.global_no_user_wire_amount: 67108864
    vm.global_user_wire_limit: 1811939328
    vm.user_wire_limit: 1811939328

That doesn't mean much though.
I've searched Apples developer pages with their unbelievable
stupid search engine and found
    developer.apple.com/library/mac/#documentation/Darwin/Conceptual/KernelProgramming/About/About.html

I've downloaded that as a PDF (upper right corner).
That doesn't mean much though.

So i finally did some tests using Nadeem's code snippet
from msg133677.  The largest top(1) i ever got was
    30477  python3      2.7       00:09.77 1    0    18    77    912M+  240K
but the system is unusable then.

I killed all tests which spent more than about three minutes first,
later i did so whenever 900M was not reached in top(1) output -
it seems to me that Apple's VM is not intelligent enough to detect
that it effectively has entered an endless loop!!!

The result of all that is that i think i can savely give you the
following advice for my MacBook (Mac OS X 10.6.7, but uname 10.7):

    x = bytearray(hw.usermem=1651843072   // 2)
responses in few fractions of a second almost regardless of system
load and gives that top(1) line:
    31369  python3      0.0       00:01.29 1    0    18    71    794M   240K

    x = bytearray(hw.user_wire_limit=1811939328   // 2)
responses in noticably more fractions of a second and gives the
following top(1) line:
   32899  python3      0.0       00:01.39 1    0    18    71    870M   240K

Note that the system seemed to handle the first case somewhat
easily, whereas the latter resulted in unresponsive window
switching etc. etc., so that it seems as if...

I don't know wether Python offers the available memory size values
somewhere, but note that Apple has moved sysctl(8) from /sbin
to /usr/sbin, which is a lie if you would ask me to express my
opinion.

Except for all this i don't understand this thread.
Isn't that bot the one for which haypo has noticed those
random failures???

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Thu Apr 14 17:08:31 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Thu, 14 Apr 2011 15:08:31 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory (sysconfig._getuserbase)
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1302793711.73.0.289534958092.issue10496@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

I'm not sure whether POSIX warrants anything about this behavior, but nothing prevents a process from running with a UID not listed in /etc/passwd (or NIS, whatever). For example, sudo allows running a command with a UID not listed in the password database, see http://linux.die.net/man/5/sudoers :
"""
targetpw

If set, sudo will prompt for the password of the user specified by the -u flag (defaults to root) instead of the password of the invoking user. Note that this precludes the use of a uid not listed in the passwd database as an argument to the -u flag. This flag is off by default.
"""

UIDs not backed by users are useful for example if you're working with a sandbox, or virtual users such as in some FTP servers http://www.proftpd.org/docs/howto/VirtualUsers.html :
"""
Question: What makes a user "virtual", then?
Answer: A virtual user is, quite simply, a user that is not defined in the system /etc/passwd file. This file associates a user name, given by the system administrator, to a user ID (commonly shortened to UID) and a group ID (GID), among other details. The Unix kernel does not deal with users in terms of their user names; it only "knows" about UIDs and GIDs. This means that an application like proftpd can look up the IDs to use for a given user name however it sees fit. Using /etc/passwd is not strictly required.
"""

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10496>
_______________________________________

From report at bugs.python.org  Thu Apr 14 17:32:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Apr 2011 15:32:31 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory (sysconfig._getuserbase)
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1302795151.57.0.725148919602.issue10496@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Because the patch is simple (just add a try/except), I think that it doesn't matter if only few people use users without entry in /etc/passwd and we should fix this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10496>
_______________________________________

From report at bugs.python.org  Thu Apr 14 17:38:00 2011
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 14 Apr 2011 15:38:00 +0000
Subject: [issue11842] slice.indices with negative step and default stop
In-Reply-To: <1302727853.06.0.703796407001.issue11842@psf.upfronthosting.co.za>
Message-ID: <1302795480.42.0.573313464152.issue11842@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

I see. Thanks for the explanation. If indeed this is the expected behaviour (as it seems), then I suggest clarifying the documentation. I think it would be good to mention that the returned values are for range(), and not for creating another slice object.

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11842>
_______________________________________

From report at bugs.python.org  Thu Apr 14 18:12:19 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Apr 2011 16:12:19 +0000
Subject: [issue11731] Simplify email API via 'policy' objects
In-Reply-To: <1301597340.87.0.239759427177.issue11731@psf.upfronthosting.co.za>
Message-ID: <1302797539.59.0.746023928626.issue11731@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

?ric did a review of the previous patch (mostly doc stuff) which should
be pretty much addressed in this new version of the patch.

I'd like to propose this version (modulo any forthcoming comments) for
commit to trunk.  I've removed some parameters that I have not (yet)
implemented.  I've decided that it is better to commit the framework now
and have it there as the skeleton on which to attach the remaining items
(and some new ones I'm finding I need for the remaining email6 work)
when I'm really ready to implement those remaining items.

----------
Added file: http://bugs.python.org/file21662/policy_for_review.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11731>
_______________________________________

From report at bugs.python.org  Thu Apr 14 18:21:22 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 14 Apr 2011 16:21:22 +0000
Subject: [issue10121] test_multiprocessing stuck in test_make_pool if run in a
	loop
In-Reply-To: <1287232773.28.0.893033557088.issue10121@psf.upfronthosting.co.za>
Message-ID: <1302798082.49.0.193409133681.issue10121@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Thanks for reminding me of this issue. I let the same tight loop run on an up-to-date python for a whole day and not stuck happened.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10121>
_______________________________________

From report at bugs.python.org  Thu Apr 14 18:26:19 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Apr 2011 16:26:19 +0000
Subject: [issue11731] Simplify email API via 'policy' objects
In-Reply-To: <1301597340.87.0.239759427177.issue11731@psf.upfronthosting.co.za>
Message-ID: <1302798379.66.0.666188814523.issue11731@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file21662/policy_for_review.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11731>
_______________________________________

From report at bugs.python.org  Thu Apr 14 18:26:37 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Apr 2011 16:26:37 +0000
Subject: [issue11731] Simplify email API via 'policy' objects
In-Reply-To: <1301597340.87.0.239759427177.issue11731@psf.upfronthosting.co.za>
Message-ID: <1302798397.56.0.0048707911294.issue11731@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Added file: http://bugs.python.org/file21663/policy_for_review.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11731>
_______________________________________

From report at bugs.python.org  Thu Apr 14 18:49:44 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 14 Apr 2011 16:49:44 +0000
Subject: [issue11467] urlparse.urlsplit() regression for paths consisting of
	digits
In-Reply-To: <1299851262.1.0.3225912326.issue11467@psf.upfronthosting.co.za>
Message-ID: <1302799784.24.0.119131321329.issue11467@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11467>
_______________________________________

From report at bugs.python.org  Thu Apr 14 18:53:37 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 14 Apr 2011 16:53:37 +0000
Subject: [issue7990] xml.etree.cElementTree lacks full dir() on Element
In-Reply-To: <1266856563.54.0.534391635456.issue7990@psf.upfronthosting.co.za>
Message-ID: <1302800017.28.0.0609554070524.issue7990@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

Is this a right approach? I converted the hard-coded "attributes" into real, C-API attributes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7990>
_______________________________________

From report at bugs.python.org  Thu Apr 14 18:54:51 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 14 Apr 2011 16:54:51 +0000
Subject: [issue10605] ElementTree documentation
In-Reply-To: <1291301477.25.0.932243074052.issue10605@psf.upfronthosting.co.za>
Message-ID: <1302800091.76.0.30339760276.issue10605@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi Adrian,
where do you see the 'entity' argument to class TreeBuilder?

In case I'm just missing in, would be interested in preparing a patch? you seem to be knowledgeable about the matter, so it would be nice if you can share it with us. You can also provide just the text you'd like to see, and I'll do the rest.

----------
nosy: +sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10605>
_______________________________________

From report at bugs.python.org  Thu Apr 14 18:56:56 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 14 Apr 2011 16:56:56 +0000
Subject: [issue11397] os.path.realpath() may produce incorrect results
In-Reply-To: <1299259038.05.0.675723191983.issue11397@psf.upfronthosting.co.za>
Message-ID: <1302800216.21.0.888614255598.issue11397@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

ping?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11397>
_______________________________________

From report at bugs.python.org  Thu Apr 14 19:02:40 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 14 Apr 2011 17:02:40 +0000
Subject: [issue11397] os.path.realpath() may produce incorrect results
In-Reply-To: <1299259038.05.0.675723191983.issue11397@psf.upfronthosting.co.za>
Message-ID: <1302800560.09.0.651115832.issue11397@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Sorry, patches sometimes sit awhile before a developer who can do something does do something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11397>
_______________________________________

From report at bugs.python.org  Thu Apr 14 19:12:33 2011
From: report at bugs.python.org (Arc Riley)
Date: Thu, 14 Apr 2011 17:12:33 +0000
Subject: [issue7990] xml.etree.cElementTree lacks full dir() on Element
In-Reply-To: <1266856563.54.0.534391635456.issue7990@psf.upfronthosting.co.za>
Message-ID: <1302801153.93.0.311584477628.issue7990@psf.upfronthosting.co.za>


Arc Riley <arcriley at gmail.com> added the comment:

It looks right to me, but I would include more verbose pydoc strings.  

IE, "The tail attribute can be used to hold additional data associated with the element" tells me nothing.  You could explain here what .tail actually is, a few XML examples of what would be put in tail or what tail would become, and the API design reason why tail is used in addition to text.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7990>
_______________________________________

From report at bugs.python.org  Thu Apr 14 19:15:55 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 14 Apr 2011 17:15:55 +0000
Subject: [issue2571] can cmd.py's API/docs for the use of an alternate stdin
	be improved?
In-Reply-To: <1207594702.67.0.73869549091.issue2571@psf.upfronthosting.co.za>
Message-ID: <1302801355.77.0.858793279961.issue2571@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Jack, several questions.
Are you saying that when stdin is a pipe and not a tty, pdb works better with use_rawinput set False? 
Are you sure that the auto setting is correct in all use cases?
Are you aware that you can set use_rawinput 'manually'?
Have you read my previous response msg118093?
Are you willing to help sort out the questions and issues therein?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2571>
_______________________________________

From report at bugs.python.org  Thu Apr 14 19:29:39 2011
From: report at bugs.python.org (Buck Golemon)
Date: Thu, 14 Apr 2011 17:29:39 +0000
Subject: [issue8326] Cannot import name SemLock on Ubuntu lucid
In-Reply-To: <1270549791.67.0.929964356468.issue8326@psf.upfronthosting.co.za>
Message-ID: <1302802179.78.0.999208746325.issue8326@psf.upfronthosting.co.za>


Buck Golemon <buck.golemon at amd.com> added the comment:

> Isn't this an Ubuntu problem if sem_open only works with some specific kernels?

sem_open works fine (python2.6 is using it), but the python2.7 build process didn't detect it properly. This is either a bug with Ubuntu's python2.7 build configuration, or with python2.7's feature detection for sem_open.

I'm not sure which.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8326>
_______________________________________

From report at bugs.python.org  Thu Apr 14 19:30:36 2011
From: report at bugs.python.org (Buck Golemon)
Date: Thu, 14 Apr 2011 17:30:36 +0000
Subject: [issue8326] Cannot import name SemLock on Ubuntu
In-Reply-To: <1270549791.67.0.929964356468.issue8326@psf.upfronthosting.co.za>
Message-ID: <1302802236.47.0.0908968153901.issue8326@psf.upfronthosting.co.za>


Changes by Buck Golemon <buck.golemon at amd.com>:


----------
title: Cannot import name SemLock on Ubuntu lucid -> Cannot import name SemLock on Ubuntu

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8326>
_______________________________________

From report at bugs.python.org  Thu Apr 14 19:33:51 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 14 Apr 2011 17:33:51 +0000
Subject: [issue11783] email parseaddr and formataddr should be IDNA aware
In-Reply-To: <BANLkTiktd95wHehWnrYX-XTA7Gnkwv4sbw@mail.gmail.com>
Message-ID: <20110414173307.GB57093@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

On Wed, Apr 13, 2011 at 09:42:22PM +0000, Torsten Becker wrote:
> So if anybody wants to work on this before that time,
> please feel free to fix it properly. :)

(The word anybody made me think.
But "fix properly" ... i'm sure you cannot refer to myself.
:))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11783>
_______________________________________

From report at bugs.python.org  Thu Apr 14 19:47:16 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 14 Apr 2011 17:47:16 +0000
Subject: [issue8326] Cannot import name SemLock on Ubuntu
In-Reply-To: <1270549791.67.0.929964356468.issue8326@psf.upfronthosting.co.za>
Message-ID: <1302803236.08.0.0999257468258.issue8326@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

This line...

>>> from multiprocessing.synchronize import Semaphore

... works on Ubuntu Lucid with the 2.7, 3.1, 3.2 and default
branches from:

http://hg.python.org/cpython


Since you mention Ubuntu's build configuration, I suggest that you
try to build from the above mercurial repository and see if the problem
persists.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8326>
_______________________________________

From report at bugs.python.org  Thu Apr 14 19:49:35 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 14 Apr 2011 17:49:35 +0000
Subject: [issue6634] sys.exit() called from threads other than the main one:
	undocumented behaviour
In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za>
Message-ID: <1302803375.98.0.576932521024.issue6634@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <stutzbach at google.com>:


----------
nosy: +stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6634>
_______________________________________

From report at bugs.python.org  Thu Apr 14 19:56:14 2011
From: report at bugs.python.org (Buck Golemon)
Date: Thu, 14 Apr 2011 17:56:14 +0000
Subject: [issue8326] Cannot import name SemLock on Ubuntu
In-Reply-To: <1270549791.67.0.929964356468.issue8326@psf.upfronthosting.co.za>
Message-ID: <1302803774.05.0.341913565031.issue8326@psf.upfronthosting.co.za>


Buck Golemon <buck.golemon at amd.com> added the comment:

> I suggest that you try to build from the above mercurial repository and see if the problem persists.

How do I know the configuration options that the Ubuntu packager used?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8326>
_______________________________________

From report at bugs.python.org  Thu Apr 14 20:05:59 2011
From: report at bugs.python.org (Torsten Becker)
Date: Thu, 14 Apr 2011 18:05:59 +0000
Subject: [issue11783] email parseaddr and formataddr should be IDNA aware
In-Reply-To: <20110414173307.GB57093@sherwood.local>
Message-ID: <BANLkTinoCZEGSrmokGVcU-s3V2FzaacoeA@mail.gmail.com>


Torsten Becker <torsten.becker at gmail.com> added the comment:

> (The word anybody made me think.
> But "fix properly" ... i'm sure you cannot refer to myself.
> :))

"fix properly" referred to my inferior implementation and "anybody"
should probably have been worded "Steffen or David".  So sure .. go
ahead. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11783>
_______________________________________

From report at bugs.python.org  Thu Apr 14 20:14:00 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 14 Apr 2011 18:14:00 +0000
Subject: [issue11397] os.path.realpath() may produce incorrect results
In-Reply-To: <1299259038.05.0.675723191983.issue11397@psf.upfronthosting.co.za>
Message-ID: <1302804840.68.0.961289635955.issue11397@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

Oh, I understand. I'm just wondering especially for this one because it has no assigned dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11397>
_______________________________________

From report at bugs.python.org  Thu Apr 14 20:21:09 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 14 Apr 2011 18:21:09 +0000
Subject: [issue8326] Cannot import name SemLock on Ubuntu
In-Reply-To: <1302803774.05.0.341913565031.issue8326@psf.upfronthosting.co.za>
Message-ID: <BANLkTinfSzB++5qLPACutC1+mcxO5+MfVA@mail.gmail.com>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

> How do I know the configuration options that the Ubuntu packager used?

the make file (likely) used is at:

http://bazaar.launchpad.net/~doko/python/pkg2.7-debian/view/head:/rules

Note: he is also a python developer, so you can add him to nosy and
ask clarification.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

----------
nosy: +sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8326>
_______________________________________

From report at bugs.python.org  Thu Apr 14 20:46:00 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 14 Apr 2011 18:46:00 +0000
Subject: [issue8326] Cannot import name SemLock on Ubuntu
In-Reply-To: <1302803774.05.0.341913565031.issue8326@psf.upfronthosting.co.za>
Message-ID: <20110414184450.GA32067@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Buck Golemon <report at bugs.python.org> wrote:
> > I suggest that you try to build from the above mercurial repository and see if the problem persists.
> 
> How do I know the configuration options that the Ubuntu packager used?

I'd use the default configuration and check if sem_open is detected
correctly by ./configure and if the import works.

As Matthias Klose stated earlier, the issue seems to be the kernel version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8326>
_______________________________________

From report at bugs.python.org  Thu Apr 14 20:48:56 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Apr 2011 18:48:56 +0000
Subject: [issue8326] Cannot import name SemLock on Ubuntu
In-Reply-To: <1270549791.67.0.929964356468.issue8326@psf.upfronthosting.co.za>
Message-ID: <1302806936.89.0.498329751416.issue8326@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Like Stefan says, use the default build options with the checkout.  If it works, then the problem is an Ubuntu bug, and not a Python bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8326>
_______________________________________

From report at bugs.python.org  Thu Apr 14 21:11:56 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Thu, 14 Apr 2011 19:11:56 +0000
Subject: [issue11806] Missing 2 hyphens in the docs
In-Reply-To: <BANLkTi=4W4qCiQNGL5CoCzm1PzkTSJ1Uzg@mail.gmail.com>
Message-ID: <BANLkTi=W7=PtvL2L_hYZ8gtewH+vu0oRfw@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

I did a little mistake with the "coffee-table" thing. It's written as
"coffee table" (no hyphen). But other words listed are written with the
hyphen. Fix those damn things mentioned in the issue.

----------
Added file: http://bugs.python.org/file21664/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11806>
_______________________________________
-------------- next part --------------
I did a little mistake with the &quot;coffee-table&quot; thing. It&#39;s written as &quot;coffee table&quot; (no hyphen). But other words listed are written with the hyphen. Fix those damn things mentioned in the issue.

From report at bugs.python.org  Thu Apr 14 21:21:50 2011
From: report at bugs.python.org (sisco)
Date: Thu, 14 Apr 2011 19:21:50 +0000
Subject: [issue9631] Python 2.7 installation issue for Linux gcc-4.1.0-3
	(Fedora Core 5?)
In-Reply-To: <1282108953.92.0.943632360126.issue9631@psf.upfronthosting.co.za>
Message-ID: <1302808910.58.0.402445521845.issue9631@psf.upfronthosting.co.za>


sisco <asisco at gmail.com> added the comment:

make install fails on Fedora Core 13 as well:

make distclean
./configure
make
make install

/usr/bin/install -c -m 644 ./LICENSE /usr/local/lib/python2.7/LICENSE.txt
PYTHONPATH=/usr/local/lib/python2.7   \
                ./python -Wi -tt /usr/local/lib/python2.7/compileall.py \
                -d /usr/local/lib/python2.7 -f \
                -x 'bad_coding|badsyntax|site-packages|lib2to3/tests/data' \
                /usr/local/lib/python2.7
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/compileall.py", line 17, in <module>
    import struct
  File "/usr/local/lib/python2.7/struct.py", line 1, in <module>
    from _struct import *
ImportError: No module named _struct
make: *** [libinstall] Error 1
[root at freebie Python-2.7.1]# df -T
Filesystem    Type   1K-blocks      Used Available Use% Mounted on
/dev/sda3     ext4    50395844   2899168  46984864   6% /
tmpfs        tmpfs     2020464       864   2019600   1% /dev/shm
/dev/sda1     ext4      396672     29566    346626   8% /boot
/dev/sda2     ext4   898537912 146927532 705967272  18% /db
[root at freebie Python-2.7.1]# uname -av
Linux freebie 2.6.33.3-85.fc13.x86_64 #1 SMP Thu May 6 18:09:49 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
[root at freebie Python-2.7.1]# cat /etc/fedora-release
Fedora release 13 (Goddard)

----------
nosy: +asisco

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9631>
_______________________________________

From report at bugs.python.org  Thu Apr 14 21:29:47 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 14 Apr 2011 19:29:47 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <20110414192937.GA58041@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

And about mmap(2):

import os,sys,time,mmap

MP0 = ((2**30)-1)
MP1 = ((2**31)-1)
MP2 = ((2**32)-1)
MPV = (2**20) * 100
SIZES = (MP0-MPV, MP0, MP0+MPV,
         MP1-MPV, MP1, MP1+MPV,
         MP2-MPV, MP2, MP2+MPV)

FILE = 'test.dat'

print('Start:', time.gmtime())
for i in SIZES:
    print('Testing file size ', i, ': ', sep='', end='')
    sys.stdout.flush()
    with open(FILE, "wb+") as f:
        f.seek(i)
        f.write(b'asdf')
        f.flush()
        sb = os.stat(FILE) 
        if sb.st_size != i+4:
            print('size failure:', sb.st_size, ' != ', i, sep='', end='')
            sys.stdout.flush()
        mem = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
        if mem[0] != ord('\0'):
            print('offset 0 failed: ', ord(mem[0]), ' ', end='', sep='')
        else:
            print('offset 0 ok ', end='', sep='')
        sys.stdout.flush()
        if mem[i] != ord('a'):
            print('offset i failed: ', ord(mem[i]), ' ', end='', sep='')
        else:
            print('offset i ok ', end='', sep='')
        print()
        sys.stdout.flush()
    os.unlink(FILE)
print('End:', time.gmtime())

...

Start: time.struct_time(tm_year=2011, tm_mon=4, tm_mday=14, tm_hour=17, tm_min=27, tm_sec=30, tm_wday=3, tm_yday=104, tm_isdst=0)
Testing file size 968884223: offset 0 ok offset i ok 
Testing file size 1073741823: offset 0 ok offset i ok 
Testing file size 1178599423: offset 0 ok offset i ok 
Testing file size 2042626047: offset 0 ok offset i ok 
Testing file size 2147483647: offset 0 ok offset i ok 
Testing file size 2252341247: offset 0 ok offset i ok 
Testing file size 4190109695: offset 0 ok offset i ok 
Testing file size 4294967295: offset 0 ok offset i ok 
Testing file size 4399824895: offset 0 ok offset i ok 
End: time.struct_time(tm_year=2011, tm_mon=4, tm_mday=14, tm_hour=17, tm_min=27, tm_sec=30, tm_wday=3, tm_yday=104, tm_isdst=0)

Now i think that can't be any faster.
Changing to
    MP0 = ((2**30)-0)
    MP1 = ((2**31)-0)
    MP2 = ((2**32)-0)
results in

Start: time.struct_time(tm_year=2011, tm_mon=4, tm_mday=14, tm_hour=17, tm_min=27, tm_sec=55, tm_wday=3, tm_yday=104, tm_isdst=0)
Testing file size 968884224: offset 0 ok offset i ok 
Testing file size 1073741824: offset 0 ok offset i ok 
Testing file size 1178599424: offset 0 ok offset i ok 
Testing file size 2042626048: offset 0 ok offset i ok 
Testing file size 2147483648: offset 0 ok offset i ok 
Testing file size 2252341248: offset 0 ok offset i ok 
Testing file size 4190109696: offset 0 ok offset i ok 
Testing file size 4294967296: <- EOF here

Manually adjusted SIZES:

Testing file size 4294967295: offset 0 ok offset i ok 
Testing file size 4296015872: offset 0 ok offset i ok (MP2+1024*1024)
Testing file size 4295491584: offset 0 ok offset i ok (MP2+1024*512)
Testing file size 4295229440: offset 0 ok offset i ok (MP2+1024*256)
...
Testing file size 4294971392: offset 0 ok offset i ok (MP2+1024*4)
Testing file size 4294969344: <- EOF here (MP2+1024*2)

Pagesize = 4096.
I think the state machine can be easier than i thought.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Thu Apr 14 21:31:38 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 14 Apr 2011 19:31:38 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1302809498.63.0.210111351077.issue2771@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Added file: http://bugs.python.org/file21665/foo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Thu Apr 14 21:35:48 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 14 Apr 2011 19:35:48 +0000
Subject: [issue11844] Update json to upstream simplejson latest release
In-Reply-To: <1302809748.45.0.3421678902.issue11844@psf.upfronthosting.co.za>
Message-ID: <1302809748.45.0.3421678902.issue11844@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

This issue is to track the update process of json to the latest upstream release (2.1.3).

As a start, here's the p-dev thread: http://mail.python.org/pipermail/python-dev/2011-April/110704.html

----------
assignee: sandro.tosi
components: Library (Lib)
messages: 133765
nosy: sandro.tosi
priority: normal
severity: normal
status: open
title: Update json to upstream simplejson latest release
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11844>
_______________________________________

From report at bugs.python.org  Thu Apr 14 21:50:48 2011
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 14 Apr 2011 19:50:48 +0000
Subject: [issue11845] Refcounting error in compute_slice_indices in
	rangeobject.c
In-Reply-To: <1302810648.64.0.569357364768.issue11845@psf.upfronthosting.co.za>
Message-ID: <1302810648.64.0.569357364768.issue11845@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

The attached crash.py script reliably crashes the 3.2 and 3.3 interpreter on my machine. The script does a lot of range slicing.

I think there is a typo in compute_slice_indices() in rangeobject.c, in line 475. In line 474 there is an assign to tmp_stop, and on the next line tmp_start is incref'd (I think instead of tmp_stop).

With this patch, the interpreter doesn't crash any more:

diff -r 7563f10275a2 Objects/rangeobject.c
--- a/Objects/rangeobject.c	Thu Apr 14 13:20:41 2011 +0800
+++ b/Objects/rangeobject.c	Thu Apr 14 21:40:32 2011 +0200
@@ -472,7 +472,7 @@
                     if (tmp_stop == NULL) goto Fail;
                 } else {
                     tmp_stop = r->length;
-                    Py_INCREF(tmp_start);
+                    Py_INCREF(tmp_stop);
                 }
             }
         }

----------
components: Interpreter Core
files: crash.py
messages: 133766
nosy: durban, ncoghlan
priority: normal
severity: normal
status: open
title: Refcounting error in compute_slice_indices in rangeobject.c
type: crash
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21666/crash.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11845>
_______________________________________

From report at bugs.python.org  Thu Apr 14 21:52:33 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 14 Apr 2011 19:52:33 +0000
Subject: [issue11783] email parseaddr and formataddr should be IDNA aware
In-Reply-To: <BANLkTinoCZEGSrmokGVcU-s3V2FzaacoeA@mail.gmail.com>
Message-ID: <20110414195225.GB58041@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

On Thu, Apr 14, 2011 at 06:05:59PM +0000, Torsten Becker wrote:
> So sure .. go ahead. :)

Grrrrr....
Wuah, Wuuuah, Wuuuuuuaaaah!
No.  Now i'm exhausted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11783>
_______________________________________

From report at bugs.python.org  Thu Apr 14 21:53:45 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 14 Apr 2011 19:53:45 +0000
Subject: [issue11783] email parseaddr and formataddr should be IDNA aware
In-Reply-To: <BANLkTinoCZEGSrmokGVcU-s3V2FzaacoeA@mail.gmail.com>
Message-ID: <20110414195338.GC58041@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

On Thu, Apr 14, 2011 at 06:05:59PM +0000, Torsten Becker wrote:
> :)

Mumble...
:)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11783>
_______________________________________

From report at bugs.python.org  Thu Apr 14 22:27:57 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 14 Apr 2011 20:27:57 +0000
Subject: [issue11845] Refcounting error in compute_slice_indices in
	rangeobject.c
In-Reply-To: <1302810648.64.0.569357364768.issue11845@psf.upfronthosting.co.za>
Message-ID: <1302812877.78.0.682028145257.issue11845@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/issue11845>
_______________________________________

From report at bugs.python.org  Thu Apr 14 23:12:47 2011
From: report at bugs.python.org (Anthony Long)
Date: Thu, 14 Apr 2011 21:12:47 +0000
Subject: [issue11846] Implementation question for (-5) - 256 caching,
	and doc update for c-api/int.html
In-Reply-To: <1302815567.28.0.789640613127.issue11846@psf.upfronthosting.co.za>
Message-ID: <1302815567.28.0.789640613127.issue11846@psf.upfronthosting.co.za>


New submission from Anthony Long <antlong at gmail.com>:

http://docs.python.org/c-api/int.html

"The current implementation keeps an array of integer objects for all integers between -5 and 256, when you create an int in that range you actually just get back a reference to the existing object. So it should be possible to change the value of 1. I suspect the behaviour of Python in this case is undefined. :-)"

This paragraph should be changed to reflect that you can (by construction) mutate anything you want in C, and (as per suggestion of dmalcolm)

"The current implementatin consolidates integers in the range -5 to 256 (inclusive) into singleton instances.  Do not manipulate the internal value of a PyIntObject after creation."

Also, the last line of that paragraph insinuates this functionality (caching of -5 to 256) is undocumented. I searched for a good while for an answer for this, and I didn't find one. If there is something written on the implementation details surrounding why '-5 is -5' works, while -6 is -6' wouldn't. 

If there is nothing written about this, I will put something together. My final question however which I have not been able to find an answer for, is: Is this even necessary functionality?

I encountered around 100 blog posts and a couple of stackoverflow questions about why this fails, and it seems like 1) a source of confusion 2) a point of ridicule. Is it really necessary?

>>> id(1)
4298196440
>>> a = 1
>>> id(a)
4298196440
>>> id(3000)
4320396376
>>> a = 3000
>>> id(a)
4320396160
>>>

----------
components: Library (Lib)
messages: 133769
nosy: antlong
priority: normal
severity: normal
status: open
title: Implementation question for (-5) - 256 caching, and doc update for c-api/int.html
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11846>
_______________________________________

From report at bugs.python.org  Thu Apr 14 23:17:05 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 14 Apr 2011 21:17:05 +0000
Subject: [issue11846] Implementation question for (-5) - 256 caching,
	and doc update for c-api/int.html
In-Reply-To: <1302815567.28.0.789640613127.issue11846@psf.upfronthosting.co.za>
Message-ID: <1302815825.55.0.411716078212.issue11846@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

>From IRC discussion, how about something like:

The current implementation consolidates integers in the range -5 to 256 (inclusive) into singleton PyIntObject instances, whereas other integer values have unique PyIntObject instances created for them.

This means that on CPython::

   >>> -5 is -5
   True

but::

   >>> -6 is not -6
   False

This behavior is an implementation detail of CPython, and is not required by other implementations of Python.

In particular:
  - do not manipulate the internal value of a PyIntObject after creation
  - do not use "is" for comparing integer values, use "==" instead.

----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11846>
_______________________________________

From report at bugs.python.org  Thu Apr 14 23:18:34 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 14 Apr 2011 21:18:34 +0000
Subject: [issue11846] Implementation question for (-5) - 256 caching,
	and doc update for c-api/int.html
In-Reply-To: <1302815567.28.0.789640613127.issue11846@psf.upfronthosting.co.za>
Message-ID: <1302815914.77.0.929865280529.issue11846@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Perhaps should also note that this is done for the purposes of optimization (both speed and memory).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11846>
_______________________________________

From report at bugs.python.org  Thu Apr 14 23:19:56 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 14 Apr 2011 21:19:56 +0000
Subject: [issue11845] Refcounting error in compute_slice_indices in
	rangeobject.c
In-Reply-To: <1302810648.64.0.569357364768.issue11845@psf.upfronthosting.co.za>
Message-ID: <1302815996.68.0.984626901882.issue11845@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <stutzbach at google.com>:


----------
nosy: +stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11845>
_______________________________________

From report at bugs.python.org  Thu Apr 14 23:20:26 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 14 Apr 2011 21:20:26 +0000
Subject: [issue11846] Implementation question for (-5) - 256 caching,
	and doc update for c-api/int.html
In-Reply-To: <1302815567.28.0.789640613127.issue11846@psf.upfronthosting.co.za>
Message-ID: <1302816026.93.0.90981759768.issue11846@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Interpreter idea: "<int> is <int>" could trigger a compatibility warning, perhaps, to help people avoid relying on CPython quirks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11846>
_______________________________________

From report at bugs.python.org  Thu Apr 14 23:22:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Apr 2011 21:22:02 +0000
Subject: [issue11846] Implementation question for (-5) - 256 caching,
	and doc update for c-api/int.html
In-Reply-To: <1302815567.28.0.789640613127.issue11846@psf.upfronthosting.co.za>
Message-ID: <1302816122.36.0.115346948868.issue11846@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't think it's in the business of the C API docs to explain Python-visible semantics, or the difference between "==" and "is". I would just rephrase the original paragraph, removing the last sentence joke:

?Since integer objects are very frequently created, certain optimizations can be applied on their allocation. For example, the current implementation keeps an array of integer objects for all integers between -5 and 256: when you create an int in that range, you actually just get back a reference to the existing object.?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11846>
_______________________________________

From report at bugs.python.org  Thu Apr 14 23:39:25 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 14 Apr 2011 21:39:25 +0000
Subject: [issue11846] Implementation question for (-5) - 256 caching,
	and doc update for c-api/int.html
In-Reply-To: <1302815567.28.0.789640613127.issue11846@psf.upfronthosting.co.za>
Message-ID: <1302817165.08.0.275078955654.issue11846@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

We should remove the documentation entries that discuss non-guaranteed implementation details (i.e. which integers are singletons).

Instead, there should probably be a brief tutorial entry on what aspects of object identity people can rely on:

* None, True, and False are singletons.  PEP 8 recommends testing for None with "is".

* Most internal equality comparisons (i.e. that in list.count or list.__contains__) assume that identity-implied-equality regardless of how __eq__ is defined (i.e. an object is always equal to itself).

* Once created, an object doesn't change its identity.  So, you can use "is" to find the exact same object at a later stage in a program.

* Unless documented otherwise (a singleton class telling you that it returns the same object every time), no other assumptions should be made about object identity.  In particular, one cannot assume that an object id won't be re-used after the object is reclaimed.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11846>
_______________________________________

From report at bugs.python.org  Thu Apr 14 23:49:44 2011
From: report at bugs.python.org (ackounts)
Date: Thu, 14 Apr 2011 21:49:44 +0000
Subject: [issue4537] webbrowser.UnixBrowser should use builtins.open
In-Reply-To: <1228427350.73.0.444727846196.issue4537@psf.upfronthosting.co.za>
Message-ID: <1302817784.03.0.712932803941.issue4537@psf.upfronthosting.co.za>


ackounts <ackounts at gmail.com> added the comment:

yes, you right, I will create a new issue, thanks.

----------
components: +None -Library (Lib)
type: crash -> 
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4537>
_______________________________________

From report at bugs.python.org  Fri Apr 15 00:03:51 2011
From: report at bugs.python.org (ackounts)
Date: Thu, 14 Apr 2011 22:03:51 +0000
Subject: [issue11847] OSError importing antigravity module
In-Reply-To: <1302818631.56.0.0963133113635.issue11847@psf.upfronthosting.co.za>
Message-ID: <1302818631.56.0.0963133113635.issue11847@psf.upfronthosting.co.za>


New submission from ackounts <ackounts at gmail.com>:

When I try to import antigravity module on Linux I get an error (on Windows it runs fine):

Python 3.2 (r32:88445, Feb 21 2011, 01:55:53) 
[GCC 4.5.2 20110127 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import antigravity
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/antigravity.py", line 5, in <module>
    webbrowser.open("http://xkcd.com/353/")
  File "/usr/lib/python3.2/webbrowser.py", line 62, in open
    if browser.open(url, new, autoraise):
  File "/usr/lib/python3.2/webbrowser.py", line 276, in open
    success = self._invoke(args, True, autoraise)
  File "/usr/lib/python3.2/webbrowser.py", line 239, in _invoke
    stderr=inout, preexec_fn=setsid)
  File "/usr/lib/python3.2/subprocess.py", line 736, in __init__
    restore_signals, start_new_session)
  File "/usr/lib/python3.2/subprocess.py", line 1330, in _execute_child
    raise child_exception_type(errno_num, err_msg)
OSError: [Errno 9] Bad file descriptor

----------
components: Library (Lib)
messages: 133776
nosy: ackounts
priority: normal
severity: normal
status: open
title: OSError importing antigravity module
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11847>
_______________________________________

From report at bugs.python.org  Fri Apr 15 00:24:45 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 14 Apr 2011 22:24:45 +0000
Subject: [issue11847] OSError importing antigravity module
In-Reply-To: <1302818631.56.0.0963133113635.issue11847@psf.upfronthosting.co.za>
Message-ID: <1302819885.0.0.569775480684.issue11847@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11847>
_______________________________________

From report at bugs.python.org  Fri Apr 15 00:54:21 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 14 Apr 2011 22:54:21 +0000
Subject: [issue11710] Landing pages in docs for standard library packages
In-Reply-To: <1301401907.02.0.216152132906.issue11710@psf.upfronthosting.co.za>
Message-ID: <1302821661.04.0.782880081485.issue11710@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11710>
_______________________________________

From report at bugs.python.org  Fri Apr 15 01:20:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Apr 2011 23:20:18 +0000
Subject: [issue11397] os.path.realpath() may produce incorrect results
In-Reply-To: <1299259038.05.0.675723191983.issue11397@psf.upfronthosting.co.za>
Message-ID: <1302823218.91.0.0344900442575.issue11397@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I tested issue11397_py32.patch:
 - you should use os.fsencode(sep) instead of sep.encode()
 - os.path.realpath('../'*10) raises IndexError('pop from empty list') instead of giving '/'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11397>
_______________________________________

From report at bugs.python.org  Fri Apr 15 01:41:43 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 14 Apr 2011 23:41:43 +0000
Subject: [issue11710] Landing pages in docs for standard library packages
In-Reply-To: <1301401907.02.0.216152132906.issue11710@psf.upfronthosting.co.za>
Message-ID: <1302824503.48.0.114519500808.issue11710@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> georg.brandl
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11710>
_______________________________________

From report at bugs.python.org  Fri Apr 15 02:06:34 2011
From: report at bugs.python.org (Graeme Perrow)
Date: Fri, 15 Apr 2011 00:06:34 +0000
Subject: [issue9176] module termios doesn't build on HP-UX
In-Reply-To: <1278409886.91.0.742762759895.issue9176@psf.upfronthosting.co.za>
Message-ID: <1302825994.06.0.152044889114.issue9176@psf.upfronthosting.co.za>


Changes by Graeme Perrow <graeme.perrow at gmail.com>:


----------
nosy: +gperrow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9176>
_______________________________________

From report at bugs.python.org  Fri Apr 15 04:39:54 2011
From: report at bugs.python.org (Jack Andrews)
Date: Fri, 15 Apr 2011 02:39:54 +0000
Subject: [issue2571] can cmd.py's API/docs for the use of an alternate stdin
	be improved?
In-Reply-To: <1302801355.77.0.858793279961.issue2571@psf.upfronthosting.co.za>
Message-ID: <BANLkTin_2w7pZOdTe5s+VXz0q8uvse9Hjw@mail.gmail.com>


Jack Andrews <effbiae at gmail.com> added the comment:

> Terry J. Reedy <tjreedy at udel.edu> added the comment:
>
> Jack, several questions.
> Are you saying that when stdin is a pipe and not a tty, pdb works better with use_rawinput set False?

yes.  well, at least i thought so.  today, pdb works fine
with no patch.  i must have stumbled across my bug
in the middle of patching cmd.py.

if i notice anything strange, i'll let you know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2571>
_______________________________________

From report at bugs.python.org  Fri Apr 15 06:06:05 2011
From: report at bugs.python.org (higery)
Date: Fri, 15 Apr 2011 04:06:05 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1302840365.74.0.419112251172.issue828450@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

I will join GSOC2011 and I find this bug is a good test for me to submit my patch as a scoring judgment.

I have created a diff file to confirm this bug, but setuptools may have already fix it, because when using 'python setup.py sdist' to create the source distribution, file paths in SOURCES.txt are correctly with '/' as separator. However, when running the test_sdist.py tests, the problem Jeremy raised exists. 

So, it means that distutils still has this problem, but setuptools fix it.

----------
keywords: +patch
nosy: +higery
Added file: http://bugs.python.org/file21667/test_sdist.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Fri Apr 15 06:17:07 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 15 Apr 2011 04:17:07 +0000
Subject: [issue9904] Cosmetic issues that may warrant a fix in symtable.h/c
In-Reply-To: <1284964146.62.0.95975690396.issue9904@psf.upfronthosting.co.za>
Message-ID: <1302841027.79.0.730680440771.issue9904@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
resolution:  -> fixed
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9904>
_______________________________________

From report at bugs.python.org  Fri Apr 15 06:21:21 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Apr 2011 04:21:21 +0000
Subject: [issue11846] Implementation question for (-5) - 256 caching,
	and doc update for c-api/int.html
In-Reply-To: <1302815567.28.0.789640613127.issue11846@psf.upfronthosting.co.za>
Message-ID: <1302841281.78.0.214608734259.issue11846@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/issue11846>
_______________________________________

From report at bugs.python.org  Fri Apr 15 06:29:42 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Apr 2011 04:29:42 +0000
Subject: [issue11827] mention of list2cmdline() in docs of subprocess.Popen
In-Reply-To: <1302511097.53.0.993242324349.issue11827@psf.upfronthosting.co.za>
Message-ID: <E1QAaf5-0006ed-UJ@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset e7a55e236b8b by Eli Bendersky in branch '3.1':
Issue #11827: remove mention of list2cmdline in the doc of subprocess
http://hg.python.org/cpython/rev/e7a55e236b8b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11827>
_______________________________________

From report at bugs.python.org  Fri Apr 15 06:33:29 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Apr 2011 04:33:29 +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: <1302842009.31.0.831235852774.issue5057@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

PEP 3147 says[0]:
"""
For backward compatibility, Python will still support pyc-only distributions, however it will only do so when the pyc file lives in the directory where the py file would have been, i.e. not in the __pycache__ directory. pyc file outside of __pycache__ will only be imported if the py source file is missing.
"""

Does that mean that there could be cases where untagged pyc files are used in 3.2+?
In that case the patch should be ported to 3.2 and 3.3 too.

[0]: http://www.python.org/dev/peps/pep-3147/#rationale

----------
assignee:  -> ezio.melotti
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5057>
_______________________________________

From report at bugs.python.org  Fri Apr 15 06:35:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Apr 2011 04:35:05 +0000
Subject: [issue11827] mention of list2cmdline() in docs of subprocess.Popen
In-Reply-To: <1302511097.53.0.993242324349.issue11827@psf.upfronthosting.co.za>
Message-ID: <E1QAakI-0007BY-9x@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f38489a3394f by Eli Bendersky in branch '2.7':
Issue #11827: remove mention of list2cmdline in the doc of subprocess
http://hg.python.org/cpython/rev/f38489a3394f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11827>
_______________________________________

From report at bugs.python.org  Fri Apr 15 06:36:54 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 15 Apr 2011 04:36:54 +0000
Subject: [issue11827] mention of list2cmdline() in docs of subprocess.Popen
In-Reply-To: <1302511097.53.0.993242324349.issue11827@psf.upfronthosting.co.za>
Message-ID: <1302842214.29.0.11730393025.issue11827@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11827>
_______________________________________

From report at bugs.python.org  Fri Apr 15 06:38:14 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 15 Apr 2011 04:38:14 +0000
Subject: [issue11827] mention of list2cmdline() in docs of subprocess.Popen
In-Reply-To: <1302511097.53.0.993242324349.issue11827@psf.upfronthosting.co.za>
Message-ID: <1302842294.92.0.849808467007.issue11827@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Patch committed to 3.3, 3.2, 3.1, 2.7

In case no objections arise, I will close this issue in a couple of days

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11827>
_______________________________________

From report at bugs.python.org  Fri Apr 15 06:40:56 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Apr 2011 04:40:56 +0000
Subject: =?utf-8?q?=5Bissue4783=5D_document_that_json=2Eload/dump_can=E2=80=99t_be?=
	=?utf-8?q?_used_twice_on_the_same_stream?=
In-Reply-To: <1230657409.93.0.0443603821797.issue4783@psf.upfronthosting.co.za>
Message-ID: <E1QAapy-0007wz-VK@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 8dbf072556b9 by Ezio Melotti in branch '2.7':
#4783: document that is not possible to use json.dump twice on the same stream.
http://hg.python.org/cpython/rev/8dbf072556b9

New changeset 2ec08aa2c566 by Ezio Melotti in branch '3.1':
#4783: document that is not possible to use json.dump twice on the same stream.
http://hg.python.org/cpython/rev/2ec08aa2c566

New changeset 1e315794ac8c by Ezio Melotti in branch '3.2':
#4783: Merge with 3.1.
http://hg.python.org/cpython/rev/1e315794ac8c

New changeset 91881e304e13 by Ezio Melotti in branch 'default':
#4783: Merge with 3.2.
http://hg.python.org/cpython/rev/91881e304e13

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4783>
_______________________________________

From report at bugs.python.org  Fri Apr 15 06:41:56 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Apr 2011 04:41:56 +0000
Subject: =?utf-8?q?=5Bissue4783=5D_document_that_json=2Eload/dump_can=E2=80=99t_be?=
	=?utf-8?q?_used_twice_on_the_same_stream?=
In-Reply-To: <1230657409.93.0.0443603821797.issue4783@psf.upfronthosting.co.za>
Message-ID: <1302842516.66.0.897864434388.issue4783@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: bob.ippolito -> ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4783>
_______________________________________

From report at bugs.python.org  Fri Apr 15 06:54:14 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Apr 2011 04:54:14 +0000
Subject: [issue11847] OSError importing antigravity module
In-Reply-To: <1302818631.56.0.0963133113635.issue11847@psf.upfronthosting.co.za>
Message-ID: <1302843254.26.0.293506291466.issue11847@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This seems to be a duplicate of #11432.
Can you try to compile the latest Python 3.2 (or 3.3) and see if you still get the problem?

You can do it by following these steps:
hg clone http://hg.python.org/cpython
cd cpython
hg up 3.2
./configure && make
./python
import antigravity

See also http://docs.python.org/devguide/setup.html

----------
nosy: +ezio.melotti
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11847>
_______________________________________

From report at bugs.python.org  Fri Apr 15 06:57:49 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Apr 2011 04:57:49 +0000
Subject: [issue11844] Update json to upstream simplejson latest release
In-Reply-To: <1302809748.45.0.3421678902.issue11844@psf.upfronthosting.co.za>
Message-ID: <1302843469.44.0.557447169425.issue11844@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11844>
_______________________________________

From report at bugs.python.org  Fri Apr 15 07:03:26 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 15 Apr 2011 05:03:26 +0000
Subject: [issue11847] OSError importing antigravity module
In-Reply-To: <1302818631.56.0.0963133113635.issue11847@psf.upfronthosting.co.za>
Message-ID: <1302843806.93.0.693845682196.issue11847@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

As an extra, presumably if you just do:
import webbrowser
webbrowser.open("http://www.python.org")

it also fails?

----------
nosy: +rosslagerwall
status: pending -> open
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11847>
_______________________________________

From report at bugs.python.org  Fri Apr 15 07:04:07 2011
From: report at bugs.python.org (Brandon W Maister)
Date: Fri, 15 Apr 2011 05:04:07 +0000
Subject: [issue11848] Comment for random.betavariate is intriguing and
	incomplete
In-Reply-To: <1302843847.91.0.747010170012.issue11848@psf.upfronthosting.co.za>
Message-ID: <1302843847.91.0.747010170012.issue11848@psf.upfronthosting.co.za>


New submission from Brandon W Maister <quodlibetor at gmail.com>:

The comment just before the random.betavariate method reads in part:

## See
## http://sourceforge.net/bugs/?func=detailbug&bug_id=130030&group_id=5470
## for Ivan Frohne's insightful analysis of why the original implementation:
## (snip original implementation) was dead wrong, and how it propbably got that way.

And I would like to read that comment, but the buglink is pretty deeply dead. I'm not sure what the correct thing to do here is, maybe stick the text of the bug into the comment, or just update the link.

But I'm definitely curious. Thanks.

----------
components: Demos and Tools
messages: 133788
nosy: quodlibetor
priority: normal
severity: normal
status: open
title: Comment for random.betavariate is intriguing and incomplete

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11848>
_______________________________________

From report at bugs.python.org  Fri Apr 15 07:11:16 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Apr 2011 05:11:16 +0000
Subject: [issue11848] Comment for random.betavariate is intriguing and
	incomplete
In-Reply-To: <1302843847.91.0.747010170012.issue11848@psf.upfronthosting.co.za>
Message-ID: <1302844276.69.0.280965080766.issue11848@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See http://mail.python.org/pipermail/python-bugs-list/2001-January/003753.html

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11848>
_______________________________________

From report at bugs.python.org  Fri Apr 15 07:19:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Apr 2011 05:19:49 +0000
Subject: [issue11845] Refcounting error in compute_slice_indices in
	rangeobject.c
In-Reply-To: <1302810648.64.0.569357364768.issue11845@psf.upfronthosting.co.za>
Message-ID: <E1QAbRY-0001Yw-3E@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 8025fb83dece by Ezio Melotti in branch '3.2':
#11845: Fix typo in rangeobject.c that caused a crash in compute_slice_indices.  Patch by Daniel Urban.
http://hg.python.org/cpython/rev/8025fb83dece

New changeset 724e2e84a74f by Ezio Melotti in branch 'default':
#11845: Merge with 3.2.
http://hg.python.org/cpython/rev/724e2e84a74f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11845>
_______________________________________

From report at bugs.python.org  Fri Apr 15 07:20:44 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Apr 2011 05:20:44 +0000
Subject: [issue11845] Refcounting error in compute_slice_indices in
	rangeobject.c
In-Reply-To: <1302810648.64.0.569357364768.issue11845@psf.upfronthosting.co.za>
Message-ID: <1302844844.69.0.516836014019.issue11845@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the patch!

----------
assignee:  -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11845>
_______________________________________

From report at bugs.python.org  Fri Apr 15 07:27:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Apr 2011 05:27:53 +0000
Subject: [issue11848] Comment for random.betavariate is intriguing and
	incomplete
In-Reply-To: <1302843847.91.0.747010170012.issue11848@psf.upfronthosting.co.za>
Message-ID: <E1QAbZP-00023u-0u@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset e1f0881d2cb4 by Ezio Melotti in branch '2.7':
#11848: replace dead link in random.betavariate comment.
http://hg.python.org/cpython/rev/e1f0881d2cb4

New changeset f5b9ad73157c by Ezio Melotti in branch '3.1':
#11848: replace dead link in random.betavariate comment.
http://hg.python.org/cpython/rev/f5b9ad73157c

New changeset 40656d8ae2c6 by Ezio Melotti in branch '3.2':
#11848: Merge with 3.1.
http://hg.python.org/cpython/rev/40656d8ae2c6

New changeset 2acb16023fbe by Ezio Melotti in branch 'default':
#11848: Merge with 3.2.
http://hg.python.org/cpython/rev/2acb16023fbe

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11848>
_______________________________________

From report at bugs.python.org  Fri Apr 15 07:28:44 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Apr 2011 05:28:44 +0000
Subject: [issue11848] Comment for random.betavariate is intriguing and
	incomplete
In-Reply-To: <1302843847.91.0.747010170012.issue11848@psf.upfronthosting.co.za>
Message-ID: <1302845324.55.0.841621780642.issue11848@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I replaced the link, thanks for noticing it!

----------
assignee:  -> ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11848>
_______________________________________

From report at bugs.python.org  Fri Apr 15 07:52:38 2011
From: report at bugs.python.org (Brandon W Maister)
Date: Fri, 15 Apr 2011 05:52:38 +0000
Subject: [issue11848] Comment for random.betavariate is intriguing and
	incomplete
In-Reply-To: <1302843847.91.0.747010170012.issue11848@psf.upfronthosting.co.za>
Message-ID: <1302846758.26.0.803435553395.issue11848@psf.upfronthosting.co.za>


Brandon W Maister <quodlibetor at gmail.com> added the comment:

Oh, awesome, thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11848>
_______________________________________

From report at bugs.python.org  Fri Apr 15 08:26:06 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Apr 2011 06:26:06 +0000
Subject: [issue11787] File handle leak in TarFile lib
In-Reply-To: <1302115375.88.0.984018215443.issue11787@psf.upfronthosting.co.za>
Message-ID: <1302848766.75.0.170672523091.issue11787@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attached trivial patch to fix the issue. Needs tests.

----------
keywords: +easy, patch
nosy: +ezio.melotti
stage:  -> test needed
Added file: http://bugs.python.org/file21668/issue11787.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11787>
_______________________________________

From report at bugs.python.org  Fri Apr 15 09:58:28 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 15 Apr 2011 07:58:28 +0000
Subject: [issue5057] Unicode-width
	dependent	optimization	leads	to	non-portable pyc file
In-Reply-To: <1302842009.31.0.831235852774.issue5057@psf.upfronthosting.co.za>
Message-ID: <4DA7FA99.5040200@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ezio Melotti wrote:
> 
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> 
> PEP 3147 says[0]:
> """
> For backward compatibility, Python will still support pyc-only distributions, however it will only do so when the pyc file lives in the directory where the py file would have been, i.e. not in the __pycache__ directory. pyc file outside of __pycache__ will only be imported if the py source file is missing.
> """
> 
> Does that mean that there could be cases where untagged pyc files are used in 3.2+?

Yes... even though we did discuss using the same tagging support
in that scenario as well, at least for 3.3.

> In that case the patch should be ported to 3.2 and 3.3 too.
> 
> [0]: http://www.python.org/dev/peps/pep-3147/#rationale

----------
title: Unicode-width dependent optimization	leads	to	non-portable pyc file -> Unicode-width dependent	optimization	leads	to	non-portable pyc file

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5057>
_______________________________________

From report at bugs.python.org  Fri Apr 15 11:08:38 2011
From: report at bugs.python.org (Kaifeng Zhu)
Date: Fri, 15 Apr 2011 09:08:38 +0000
Subject: [issue11849] ElementTree memory leak
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>


New submission from Kaifeng Zhu <cafeeee at gmail.com>:

I'm using xml.etree.ElementTree to parse large XML file, while the memory keep increasing consistently.

You can run attached test script to reproduce it.  From 'top' in Linux or 'Task Manager' in Windows, the memory usage of python is not decreased as expected when 'Done' is printed.

Tested with Python 2.5/3.1 in Windows 7, and Python 2.5 in CentOS 5.3.

----------
components: XML
files: test.py
messages: 133797
nosy: Kaifeng.Zhu
priority: normal
severity: normal
status: open
title: ElementTree memory leak
type: resource usage
versions: Python 2.5, Python 3.1
Added file: http://bugs.python.org/file21669/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Fri Apr 15 11:26:31 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 15 Apr 2011 09:26:31 +0000
Subject: [issue11652] urlib{,
	2} returns a pair of integers as the content-length value
In-Reply-To: <1300898627.63.0.121848868508.issue11652@psf.upfronthosting.co.za>
Message-ID: <1302859591.73.0.350059998306.issue11652@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

It is better to close this issue as it was a Server Error. Standard just says that when there two headers with different values, combine them comma separated as urllib2 does.  Making special case exception for 'Content-Length' header when the server is at fault would be bad idea. We will not know which value to choose from if the values are different.

Closing this bug as Invalid.


>>> import urllib2
>>> req = urllib2.urlopen('http://wwwsearch.sourceforge.net/mechanize/src/mechanize-0.1.11.zip')
>>> req.info()['content-length']
'289519'

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11652>
_______________________________________

From report at bugs.python.org  Fri Apr 15 11:33:32 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 15 Apr 2011 09:33:32 +0000
Subject: [issue11849] ElementTree memory leak
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1302860012.85.0.912948689141.issue11849@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Do you experience same issue with current versions of Python? (3.2 or 2.7)
The package was upgraded in latest versions.

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Fri Apr 15 11:52:27 2011
From: report at bugs.python.org (Kaifeng Zhu)
Date: Fri, 15 Apr 2011 09:52:27 +0000
Subject: [issue11849] ElementTree memory leak
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1302861147.06.0.0522103033652.issue11849@psf.upfronthosting.co.za>


Kaifeng Zhu <cafeeee at gmail.com> added the comment:

Yes. Just tested with Python 2.7 and 3.2 in Windows 7, the memory usage is still unexpected high after 'Done' is printed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Fri Apr 15 12:08:33 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Apr 2011 10:08:33 +0000
Subject: [issue11467] urlparse.urlsplit() regression for paths consisting of
	digits
In-Reply-To: <1299851262.1.0.3225912326.issue11467@psf.upfronthosting.co.za>
Message-ID: <E1QAfx2-0005gb-AR@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7a693e283c68 by Senthil Kumaran in branch '2.7':
Issue #11467: Fix urlparse behavior when handling urls which contains scheme
http://hg.python.org/cpython/rev/7a693e283c68

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11467>
_______________________________________

From report at bugs.python.org  Fri Apr 15 12:22:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Apr 2011 10:22:36 +0000
Subject: [issue11467] urlparse.urlsplit() regression for paths consisting of
	digits
In-Reply-To: <1299851262.1.0.3225912326.issue11467@psf.upfronthosting.co.za>
Message-ID: <E1QAgAc-0006j7-SI@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 495d12196487 by Senthil Kumaran in branch '3.1':
Issue #11467: Fix urlparse behavior when handling urls which contains scheme specific part only digits.
http://hg.python.org/cpython/rev/495d12196487

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11467>
_______________________________________

From report at bugs.python.org  Fri Apr 15 12:23:52 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 15 Apr 2011 10:23:52 +0000
Subject: [issue11467] urlparse.urlsplit() regression for paths consisting of
	digits
In-Reply-To: <1299851262.1.0.3225912326.issue11467@psf.upfronthosting.co.za>
Message-ID: <1302863032.18.0.974810011242.issue11467@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Fixed this in all codelines. Thanks Santoso.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11467>
_______________________________________

From report at bugs.python.org  Fri Apr 15 12:25:02 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 15 Apr 2011 10:25:02 +0000
Subject: [issue11819] '-m unittest' should not pretend it works on Python
	2.5/2.6
In-Reply-To: <1302420931.81.0.0491321221951.issue11819@psf.upfronthosting.co.za>
Message-ID: <1302863102.54.0.893882849662.issue11819@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

#6514 is to make `-m unittest` work run on 2.5/2.6.

This bug is not to fix it, but to stop displaying confusing messages. It will be enough to exit with a message like:

  "`-m unittest` call is not supported in Python 2.5/2.6 - use something else (nose?) instead"

----------
status: closed -> open
title: 'unittest -m' should not pretend it works on Python 2.5/2.6 -> '-m unittest' should not pretend it works on Python 2.5/2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11819>
_______________________________________

From report at bugs.python.org  Fri Apr 15 13:01:38 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 15 Apr 2011 11:01:38 +0000
Subject: [issue11819] '-m unittest' should not pretend it works on Python
	2.5/2.6
In-Reply-To: <1302420931.81.0.0491321221951.issue11819@psf.upfronthosting.co.za>
Message-ID: <1302865298.58.0.993317354336.issue11819@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

2.5 / 2.6 are in security fix only mode. So this won't get fixed. Please don't reopen.

----------
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11819>
_______________________________________

From report at bugs.python.org  Fri Apr 15 13:11:18 2011
From: report at bugs.python.org (JoeKuan)
Date: Fri, 15 Apr 2011 11:11:18 +0000
Subject: [issue11850] mktime - OverflowError: mktime argument out of range -
	on very specific time
In-Reply-To: <1302865878.94.0.0974910959.issue11850@psf.upfronthosting.co.za>
Message-ID: <1302865878.94.0.0974910959.issue11850@psf.upfronthosting.co.za>


New submission from JoeKuan <kuan.joe at gmail.com>:

>>> a = (1970, 1, 1, 0, 59, 58, 0, 0, 0)
>>> time.mktime(a)
-2.0

>>> a = (1970, 1, 1, 0, 59, 59, 0, 0, 0)
>>> time.mktime(a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: mktime argument out of range

>>> a = (1970, 1, 1, 1, 0, 0, 0, 0, 0)
>>> time.mktime(a)
0.0

>>> a = (1970, 1, 1, 0, 59, 60, 0, 0, 0)
>>> time.mktime(a)
0.0

----------
messages: 133806
nosy: JoeKuan
priority: normal
severity: normal
status: open
title: mktime - OverflowError: mktime argument out of range - on very specific time
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11850>
_______________________________________

From report at bugs.python.org  Fri Apr 15 13:24:49 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Apr 2011 11:24:49 +0000
Subject: [issue11850] mktime - OverflowError: mktime argument out of range -
	on very specific time
In-Reply-To: <1302865878.94.0.0974910959.issue11850@psf.upfronthosting.co.za>
Message-ID: <1302866689.1.0.710918778425.issue11850@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11850>
_______________________________________

From report at bugs.python.org  Fri Apr 15 13:35:53 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 15 Apr 2011 11:35:53 +0000
Subject: [issue11850] mktime - OverflowError: mktime argument out of range
	-	on very specific time
In-Reply-To: <1302865878.94.0.0974910959.issue11850@psf.upfronthosting.co.za>
Message-ID: <4DA82D8E.5020202@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

JoeKuan wrote:
> 
> New submission from JoeKuan <kuan.joe at gmail.com>:
> 
>>>> a = (1970, 1, 1, 0, 59, 58, 0, 0, 0)
>>>> time.mktime(a)
> -2.0

On Windows, you get an OverflowError for this tuple as well.

>>>> a = (1970, 1, 1, 0, 59, 59, 0, 0, 0)
>>>> time.mktime(a)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> OverflowError: mktime argument out of range
> 
>>>> a = (1970, 1, 1, 1, 0, 0, 0, 0, 0)
>>>> time.mktime(a)
> 0.0
> 
>>>> a = (1970, 1, 1, 0, 59, 60, 0, 0, 0)
>>>> time.mktime(a)
> 0.0

Note that time.mktime() is direct interface to the C lib
funtion of the same name. As a result, the support for
the various values is platform dependent. In general,
dates before the epoch tend not to work or give wrong
results.

Since mktime() works on local time, the time zone
in affect on 1970-01-01 matters and that's why you are
seeing the OverflowError even for values after
1970-01-01 00:00:00.

----------
nosy: +lemburg
title: mktime - OverflowError: mktime argument out of range - on very specific time -> mktime - OverflowError: mktime argument out of range -	on very specific time

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11850>
_______________________________________

From report at bugs.python.org  Fri Apr 15 13:39:27 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 15 Apr 2011 11:39:27 +0000
Subject: [issue11849] ElementTree memory leak
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1302867567.89.0.0213290959368.issue11849@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I've tested a small variant of your script, on OSX.
It seems to behave correctly (with 2.5, 2.6, 2.7 and 3.1).

You can force Python to release memory immediately by calling "gc.collect()".

----------
Added file: http://bugs.python.org/file21670/issue11849_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Fri Apr 15 13:41:27 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 15 Apr 2011 11:41:27 +0000
Subject: [issue11849] ElementTree memory leak
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1302867687.31.0.124686900408.issue11849@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

this is the output for 2.7.1:

 $ python2.7 issue11849_test.py 
*** Python 2.7.1 final
---   PID STAT      TIME  SL  RE PAGEIN      VSZ    RSS   LIM     TSIZ  %CPU %MEM COMMAND
  0  2754 S+     0:00.07   0   0      0  2441472   5372     -        0  11,7  0,1 python2.7 issue11849_test.py
  1  2754 S+     0:02.36   0   0      0  2520740  83720     -        0 100,0  2,0 python2.7 issue11849_test.py
  2  2754 S+     0:04.89   0   0      0  2596784 158888     -        0 100,0  3,8 python2.7 issue11849_test.py
  3  2754 S+     0:07.28   0   0      0  2668740 230972     -        0 100,0  5,5 python2.7 issue11849_test.py
  4  2754 S+     0:10.11   0   0      0  2740932 303200     -        0 100,0  7,2 python2.7 issue11849_test.py
  5  2754 S+     0:12.85   0   0      0  2812876 375276     -        0  98,4  8,9 python2.7 issue11849_test.py
  6  2754 R+     0:14.95   0   0      0  2885868 447740     -        0  98,9 10,7 python2.7 issue11849_test.py
  7  2754 S+     0:17.91   0   0      0  2962156 522560     -        0  99,1 12,5 python2.7 issue11849_test.py
  8  2754 S+     0:21.08   0   0      0  3034092 594620     -        0  98,3 14,2 python2.7 issue11849_test.py
  9  2754 S+     0:23.20   0   0      0  3106028 667004     -        0 100,0 15,9 python2.7 issue11849_test.py
END  2754 S+     0:27.50   0   0      0  2551160 114480     -        0  96,3  2,7 python2.7 issue11849_test.py
 GC  2754 S+     0:27.75   0   0      0  2454904  18992     -        0  97,2  0,5 python2.7 issue11849_test.py
***  2754 S+     0:27.75   0   0      0  2454904  18992     -        0   3,0  0,5 python2.7 issue11849_test.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Fri Apr 15 13:53:46 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Apr 2011 11:53:46 +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: <1302868426.2.0.417895969537.issue5057@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Do you think this should go in 3.1 too?

----------
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5057>
_______________________________________

From report at bugs.python.org  Fri Apr 15 14:00:49 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 15 Apr 2011 12:00:49 +0000
Subject: [issue5057]
	Unicode-width	dependent	optimization	leads	to	non-portable pyc file
In-Reply-To: <1302868426.2.0.417895969537.issue5057@psf.upfronthosting.co.za>
Message-ID: <4DA83367.7040304@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ezio Melotti wrote:
> 
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> 
> Do you think this should go in 3.1 too?

If the problem triggers there as well: Yes.

Is the problem also visible on Python 2.7 ?

----------
title: Unicode-width dependent	optimization	leads	to	non-portable pyc file -> Unicode-width	dependent	optimization	leads	to	non-portable pyc file

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5057>
_______________________________________

From report at bugs.python.org  Fri Apr 15 14:02:26 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Apr 2011 12:02:26 +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: <1302868946.29.0.447860669565.issue5057@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Yes. The original report was for 2.6.
I will apply the patch on all the 4 branches then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5057>
_______________________________________

From report at bugs.python.org  Fri Apr 15 14:32:48 2011
From: report at bugs.python.org (kaifeng)
Date: Fri, 15 Apr 2011 12:32:48 +0000
Subject: [issue11849] ElementTree memory leak
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1302870768.44.0.01660289776.issue11849@psf.upfronthosting.co.za>


kaifeng <cafeeee at gmail.com> added the comment:

Python 3.2 On Linux (CentOS 5.3)

*** Python 3.2.0 final
---   PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
  0 15116 pts/0    S+     0:00      1  1316 11055  6452  0.6 python3.2 issue11849_test.py
  1 15116 pts/0    S+     0:02      1  1316 53155 47340  4.5 python3.2 issue11849_test.py
  2 15116 pts/0    S+     0:05      1  1316 91051 86364  8.3 python3.2 issue11849_test.py
  3 15116 pts/0    S+     0:08      1  1316 129067 124232 12.0 python3.2 issue11849_test.py
  4 15116 pts/0    S+     0:10      1  1316 166587 162096 15.6 python3.2 issue11849_test.py
  5 15116 pts/0    S+     0:13      1  1316 204483 198824 19.2 python3.2 issue11849_test.py
  6 15116 pts/0    S+     0:17      1  1316 242375 236692 22.8 python3.2 issue11849_test.py
  7 15116 pts/0    S+     0:19      1  1316 284383 277528 26.8 python3.2 issue11849_test.py
  8 15116 pts/0    S+     0:23      1  1316 318371 312452 30.1 python3.2 issue11849_test.py
  9 15116 pts/0    S+     0:25      1  1316 360235 353288 34.1 python3.2 issue11849_test.py
END 15116 pts/0    S+     0:30      1  1316 393975 388176 37.4 python3.2 issue11849_test.py
 GC 15116 pts/0    S+     0:30      1  1316 352035 347656 33.5 python3.2 issue11849_test.py
*** 15116 pts/0    S+     0:30      1  1316 352035 347656 33.5 python3.2 issue11849_test.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Fri Apr 15 14:39:15 2011
From: report at bugs.python.org (JoeKuan)
Date: Fri, 15 Apr 2011 12:39:15 +0000
Subject: [issue11850] mktime - OverflowError: mktime argument out of range
	-	on very specific time
In-Reply-To: <1302865878.94.0.0974910959.issue11850@psf.upfronthosting.co.za>
Message-ID: <1302871155.02.0.792914270576.issue11850@psf.upfronthosting.co.za>


JoeKuan <kuan.joe at gmail.com> added the comment:

I don't think it is to do with the underlying C mktime. Because it works fine with 00:59:58 and 01:00:00, 1, Jan 1970. It is to do with some specific value -1 in the internal code of time.mktime

Here is the C code.

int main(int argc, char *argv[]) {

        struct tm aTime = { 58, 59, 0, 1, 0, 70, 0, 0, 0, 0 };
        time_t mTime = mktime(&aTime);
        printf("%s\n", ctime(&mTime));

        aTime.tm_sec = 59;
        mTime = mktime(&aTime);
        printf("%s\n", ctime(&mTime));

        aTime.tm_sec = 0;
        aTime.tm_min = 0;
        aTime.tm_hour = 1;
        mTime = mktime(&aTime);
        printf("%s\n", ctime(&mTime));
}

-------------------------------------------------------
Output from the same machine which gives the python error message


Thu Jan  1 00:59:58 1970

Thu Jan  1 00:59:59 1970

Thu Jan  1 01:00:00 1970

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11850>
_______________________________________

From report at bugs.python.org  Fri Apr 15 14:44:10 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 15 Apr 2011 12:44:10 +0000
Subject: [issue11850] mktime - OverflowError: mktime argument out of range -
	on very specific time
In-Reply-To: <1302871155.02.0.792914270576.issue11850@psf.upfronthosting.co.za>
Message-ID: <DF94C296-17CD-4949-AFCC-FDDE85B7B06E@gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Isn't this a duplicate of issue1726687?

>

----------
nosy: +Alexander.Belopolsky
title: mktime - OverflowError: mktime argument out of range -	on very specific time -> mktime - OverflowError: mktime argument out of range - on very specific time

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11850>
_______________________________________

From report at bugs.python.org  Fri Apr 15 15:10:48 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 15 Apr 2011 13:10:48 +0000
Subject: [issue11850] mktime - OverflowError: mktime argument out of range
	-	on very specific time
In-Reply-To: <1302871155.02.0.792914270576.issue11850@psf.upfronthosting.co.za>
Message-ID: <4DA843CD.4090901@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

JoeKuan wrote:
> 
> JoeKuan <kuan.joe at gmail.com> added the comment:
> 
> I don't think it is to do with the underlying C mktime. Because it works fine with 00:59:58 and 01:00:00, 1, Jan 1970. It is to do with some specific value -1 in the internal code of time.mktime

Here's the module code:

    buf.tm_wday = -1;  /* sentinel; original value ignored */
    tt = mktime(&buf);
    /* Return value of -1 does not necessarily mean an error, but tm_wday
     * cannot remain set to -1 if mktime succedded. */
    if (tt == (time_t)(-1) && buf.tm_wday == -1) {
        PyErr_SetString(PyExc_OverflowError,
                        "mktime argument out of range");
        return NULL;
    }

This is correct by the books, since the Linux man-page states (the
POSIX page is similar):

"""
       The  mktime()  function  modifies  the fields of the tm structure as follows:
       tm_wday and tm_yday are set to values determined from  the  contents  of  the
       other  fields;  if  structure  members are outside their valid interval, they
       will be normalized (so that, for example, 40 October is changed into 9 Novem-
       ber);  tm_isdst  is set (regardless of its initial value) to a positive value
       or to 0, respectively, to indicate whether DST is or is not in effect at  the
       specified time.  Calling mktime() also sets the external variable tzname with
       information about the current timezone.

       If the specified broken-down time cannot  be  represented  as  calendar  time
       (seconds  since  the Epoch), mktime() returns a value of (time_t) -1 and does
       not alter the members of the broken-down time structure.
"""

On which platform are you trying this ?

> Here is the C code.
> 
> int main(int argc, char *argv[]) {
> 
>         struct tm aTime = { 58, 59, 0, 1, 0, 70, 0, 0, 0, 0 };
>         time_t mTime = mktime(&aTime);
>         printf("%s\n", ctime(&mTime));
> 
>         aTime.tm_sec = 59;
>         mTime = mktime(&aTime);
>         printf("%s\n", ctime(&mTime));
> 
>         aTime.tm_sec = 0;
>         aTime.tm_min = 0;
>         aTime.tm_hour = 1;
>         mTime = mktime(&aTime);
>         printf("%s\n", ctime(&mTime));
> }
> 
> -------------------------------------------------------
> Output from the same machine which gives the python error message
> 
> 
> Thu Jan  1 00:59:58 1970
> 
> Thu Jan  1 00:59:59 1970
> 
> Thu Jan  1 01:00:00 1970

On Windows, you get errors for the first two.

----------
title: mktime - OverflowError: mktime argument out of range - on very specific time -> mktime - OverflowError: mktime argument out of range -	on very specific time

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11850>
_______________________________________

From report at bugs.python.org  Fri Apr 15 15:17:16 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 15 Apr 2011 13:17:16 +0000
Subject: [issue11850] mktime - OverflowError: mktime argument out of range
	-	on very specific time
In-Reply-To: <DF94C296-17CD-4949-AFCC-FDDE85B7B06E@gmail.com>
Message-ID: <4DA84552.3050109@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:
> 
> Isn't this a duplicate of issue1726687?

Could be, but that patch is not yet in Python 2.7, since Python 2.7.1
was release in Nov 2010.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11850>
_______________________________________

From report at bugs.python.org  Fri Apr 15 15:27:41 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 15 Apr 2011 13:27:41 +0000
Subject: [issue11850] mktime - OverflowError: mktime argument out of range
	-	on very specific time
In-Reply-To: <1302865878.94.0.0974910959.issue11850@psf.upfronthosting.co.za>
Message-ID: <1302874061.9.0.318605727357.issue11850@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

If we can rely on the "versions" field, OP is using python 2.6.  I don't think this can be classified as a security issue, so it won't be appropriate to backport issue1726687 to 2.6.

----------
assignee:  -> belopolsky
components: +Extension Modules
nosy:  -Alexander.Belopolsky
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11850>
_______________________________________

From report at bugs.python.org  Fri Apr 15 15:29:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Apr 2011 13:29:02 +0000
Subject: [issue11850] mktime - OverflowError: mktime argument out of range
	-	on very specific time
In-Reply-To: <1302865878.94.0.0974910959.issue11850@psf.upfronthosting.co.za>
Message-ID: <1302874142.21.0.739400701362.issue11850@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue is a duplicate of #1726687 which is already fixed in Python 2.7 by 7a89f4a73d1a (Feb 15 2011): it will be part of 2.7.2.

Only security vulnerabilities are fixed in Python 2.6, so I change the version field to 2.7 only.

----------
nosy: +haypo
resolution:  -> duplicate
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11850>
_______________________________________

From report at bugs.python.org  Fri Apr 15 15:29:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Apr 2011 13:29:17 +0000
Subject: [issue11850] mktime - OverflowError: mktime argument out of range
	-	on very specific time
In-Reply-To: <1302865878.94.0.0974910959.issue11850@psf.upfronthosting.co.za>
Message-ID: <1302874157.22.0.945838519931.issue11850@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11850>
_______________________________________

From report at bugs.python.org  Fri Apr 15 15:36:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Apr 2011 13:36:08 +0000
Subject: [issue11787] File handle leak in TarFile lib
In-Reply-To: <1302115375.88.0.984018215443.issue11787@psf.upfronthosting.co.za>
Message-ID: <1302874568.19.0.786259497711.issue11787@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

LGTM.  Is an automated test really needed, or just a manual run with a pydebug build?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11787>
_______________________________________

From report at bugs.python.org  Fri Apr 15 15:41:26 2011
From: report at bugs.python.org (Edzard Pasma)
Date: Fri, 15 Apr 2011 13:41:26 +0000
Subject: [issue11851] Flushing the standard input causes an error
Message-ID: <1302874886.31.0.794832456015.issue11851@psf.upfronthosting.co.za>


Changes by Edzard Pasma <pasma10 at concepts.nl>:


----------
components: None
nosy: pasma10 at concepts.nl
priority: normal
severity: normal
status: open
title: Flushing the standard input causes an error
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11851>
_______________________________________

From report at bugs.python.org  Fri Apr 15 15:45:00 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 15 Apr 2011 13:45:00 +0000
Subject: [issue11851] Flushing the standard input causes an error
In-Reply-To: <1302875100.13.0.0605513663919.issue11851@psf.upfronthosting.co.za>
Message-ID: <1302875100.13.0.0605513663919.issue11851@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

Could you provide more details on the problem? What version of Python did
you encounter this error under? A short code fragment that triggers the
error would also be useful.

(I get no errors executing "sys.stdin.flush()" on 2.6.6 or 3.3)

----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11851>
_______________________________________

From report at bugs.python.org  Fri Apr 15 15:46:27 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Apr 2011 13:46:27 +0000
Subject: [issue11787] File handle leak in TarFile lib
In-Reply-To: <1302115375.88.0.984018215443.issue11787@psf.upfronthosting.co.za>
Message-ID: <1302875187.98.0.503864493028.issue11787@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

An automated test would be better.  It should be enough to create an invalid tar file, do something similar to the snippet in the first message, but checking that an error is raised and that all the files are closed anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11787>
_______________________________________

From report at bugs.python.org  Fri Apr 15 15:51:23 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 15 Apr 2011 13:51:23 +0000
Subject: [issue11819] '-m unittest' should not pretend it works on Python
	2.5/2.6
In-Reply-To: <1302420931.81.0.0491321221951.issue11819@psf.upfronthosting.co.za>
Message-ID: <1302875483.11.0.687813813436.issue11819@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I need a "why-python-suxx" keyword to point people with dumb questions about why they should not use specific Python versions to a query that lists all sensitive issues for this specific version that won't be fixed due to security fix only mode.

----------
resolution: duplicate -> wont fix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11819>
_______________________________________

From report at bugs.python.org  Fri Apr 15 15:53:03 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Apr 2011 13:53:03 +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: <E1QAjSH-0006nW-5n@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3cffa2009a92 by Ezio Melotti in branch '2.7':
Issue #5057: fix a bug in the peepholer that led to non-portable pyc files between narrow and wide builds while optimizing BINARY_SUBSCR on non-BMP chars (e.g. u"\U00012345"[0]).
http://hg.python.org/cpython/rev/3cffa2009a92

New changeset 4679d0fef389 by Ezio Melotti in branch '3.1':
Issue #5057: fix a bug in the peepholer that led to non-portable pyc files between narrow and wide builds while optimizing BINARY_SUBSCR on non-BMP chars (e.g. "\U00012345"[0]).
http://hg.python.org/cpython/rev/4679d0fef389

New changeset 503578ddf286 by Ezio Melotti in branch '3.2':
#5057: Merge with 3.1.
http://hg.python.org/cpython/rev/503578ddf286

New changeset 9801e1f78264 by Ezio Melotti in branch 'default':
#5057: Merge with 3.2.
http://hg.python.org/cpython/rev/9801e1f78264

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5057>
_______________________________________

From report at bugs.python.org  Fri Apr 15 15:54:25 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Apr 2011 13:54:25 +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: <1302875665.93.0.211576640155.issue5057@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5057>
_______________________________________

From report at bugs.python.org  Fri Apr 15 15:59:38 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Apr 2011 13:59:38 +0000
Subject: [issue11819] '-m unittest' should not pretend it works on Python
	2.5/2.6
In-Reply-To: <1302420931.81.0.0491321221951.issue11819@psf.upfronthosting.co.za>
Message-ID: <1302875978.13.0.44054596477.issue11819@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

At some point we have to draw the line, otherwise we would have to backport things to 2.3 and 2.4 too.  We are already maintaining 4 branches (2.7, 3.1, 3.2, 3.3).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11819>
_______________________________________

From report at bugs.python.org  Fri Apr 15 16:04:59 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 15 Apr 2011 14:04:59 +0000
Subject: [issue11850] mktime - OverflowError: mktime argument out of range
	-	on very specific time
In-Reply-To: <4DA84552.3050109@egenix.com>
Message-ID: <4DA85080.8060902@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Marc-Andre Lemburg wrote:
> 
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
> 
> Alexander Belopolsky wrote:
>>
>> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:
>>
>> Isn't this a duplicate of issue1726687?
> 
> Could be, but that patch is not yet in Python 2.7, since Python 2.7.1
> was release in Nov 2010.

FWIW: The fix does work on Linux for the mentioned special case.

Aside: mxDateTime will have a similar fix in the next release and
that will also be available for Python 2.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11850>
_______________________________________

From report at bugs.python.org  Fri Apr 15 16:10:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Apr 2011 14:10:26 +0000
Subject: [issue11851] Flushing the standard input causes an error
In-Reply-To: <1302875100.13.0.0605513663919.issue11851@psf.upfronthosting.co.za>
Message-ID: <1302876626.68.0.852098672416.issue11851@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11851>
_______________________________________

From report at bugs.python.org  Fri Apr 15 16:26:26 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 15 Apr 2011 14:26:26 +0000
Subject: [issue11819] '-m unittest' should not pretend it works on Python
	2.5/2.6
In-Reply-To: <1302420931.81.0.0491321221951.issue11819@psf.upfronthosting.co.za>
Message-ID: <1302877586.19.0.777101144728.issue11819@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I know. But stuff like this is necessary for proper release management and future planning. Using "why-python-suxx per module" ? metric, it is possible to pinpoint badly designed parts that should be removed or replaced in Python4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11819>
_______________________________________

From report at bugs.python.org  Fri Apr 15 16:45:40 2011
From: report at bugs.python.org (Edzard Pasma)
Date: Fri, 15 Apr 2011 14:45:40 +0000
Subject: [issue11851] Flushing the standard input causes an error
In-Reply-To: <1302875100.13.0.0605513663919.issue11851@psf.upfronthosting.co.za>
Message-ID: <1302878740.35.0.947520121641.issue11851@psf.upfronthosting.co.za>


Edzard Pasma <pasma10 at concepts.nl> added the comment:

Hello,

The error occured in the APSW shell, when using its .output command. Looking at the apsw source, it appears to perform a sys.stdin.flush() at that point. Trying this in the Python interpreto gives the same error:

$ python
Python 2.7.1 (r271:86882M, Nov 30 2010, 09:39:13) 
[GCC 4.0.1 (Apple Inc. build 5494)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.stdin.flush
<built-in method flush of file object at 0x28020>
>>> sys.stdin.flush()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 9] Bad file descriptor

But in Python3 it no longer occurs. I'd like to report this to the developer of the APSW module as it appears most easy to avoid it there (also there are more frequent releases). I hope it is useful to report it here too.

Regards, E. Pasma
(sorry that the original post was empty)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11851>
_______________________________________

From report at bugs.python.org  Fri Apr 15 16:57:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Apr 2011 14:57:10 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1302879430.75.0.335047826342.issue828450@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

setuptools sdist uses a wholly different machinery than distutils, so it?s a red herring.

Have you tested that your patch does reproduce the bug?  From the diff header, I see that you?ve patched your installed Python instead of using a developpers? environment.  The guide at docs.python.org/devguide should help you get set up.

If the patch does reproduce the bug, can you also fix it?

----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Fri Apr 15 16:58:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Apr 2011 14:58:55 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory (sysconfig._getuserbase)
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1302879535.33.0.960810870229.issue10496@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It?s not just a try/except, it?s a behavior change: after the patch, paths returned by sysconfig may not be fully expanded paths.  I would like Tarek to make a call on this.

----------
assignee:  -> tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10496>
_______________________________________

From report at bugs.python.org  Fri Apr 15 17:00:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Apr 2011 15:00:12 +0000
Subject: [issue11843] distutils doc: duplicate line in table
In-Reply-To: <1302782732.33.0.79290372609.issue11843@psf.upfronthosting.co.za>
Message-ID: <1302879612.91.0.859005449081.issue11843@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report; I?ll fix it when I get Internet access without port 22 blocked, or any committer interested in documentation can do it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11843>
_______________________________________

From report at bugs.python.org  Fri Apr 15 17:00:14 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 15 Apr 2011 15:00:14 +0000
Subject: [issue11844] Update json to upstream simplejson latest release
In-Reply-To: <1302809748.45.0.3421678902.issue11844@psf.upfronthosting.co.za>
Message-ID: <1302879614.08.0.113267469579.issue11844@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am not sure anyone other that Bob Ippolito can contribute later versions of simplejson (or patches derived from those versions) to python.

ISTM that simplejson distribution is covered by MIT license [1] which is not one of the valid "initial licenses." [2]

I was trying to find what was the plan for maintaining json package in stdlib when it was initially included, but the only discussion I could find was a short thread [3] and issue #2750.  Neither seem to address the issue of future maintenance.
 

[1] https://github.com/simplejson/simplejson/blob/master/LICENSE.txt
[2] http://www.python.org/psf/contrib/contrib-form/
[3] http://mail.python.org/pipermail/python-3000/2008-March/012583.html

----------
nosy: +belopolsky, benjamin.peterson, bob.ippolito, brett.cannon, christian.heimes, georg.brandl, pjenvey, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11844>
_______________________________________

From report at bugs.python.org  Fri Apr 15 17:02:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Apr 2011 15:02:41 +0000
Subject: [issue10932] distutils.core.setup - data_files misbehaviour ?
In-Reply-To: <1295353825.23.0.755300594789.issue10932@psf.upfronthosting.co.za>
Message-ID: <1302879761.59.0.975746119913.issue10932@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
hgrepos: +19

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10932>
_______________________________________

From report at bugs.python.org  Fri Apr 15 17:03:09 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 15 Apr 2011 15:03:09 +0000
Subject: [issue9325] Add an option to pdb/trace/profile to run library module
	as a script
In-Reply-To: <1279743902.96.0.66207849175.issue9325@psf.upfronthosting.co.za>
Message-ID: <1302879789.88.0.292379565108.issue9325@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Good point about the extra parameter just pushing the problem one layer up the stack rather than completely solving the problem.

However, on further reflection, I've realised that I really don't like having runpy import the threading module automatically, since that means even single-threaded applications run via "-m" will end up initialising the thread support, including the GIL. That's something we try reasonably hard to avoid doing in applications that don't actually need it (it does happen in library modules that genuinely need thread-local storage, such as the decimal module).

If you look at the way Pdb._runscript currently works, it imports __main__ and then cleans it out ready to let the child script run. So replacing that with a simple module level global that refers to the runpy execution namespace would probably be an improvement.

Looking at this use case more closely, though, shows that it isn't as simple as handing the whole task over to the runpy module, as the debugger needs access to the filename before it starts executing code in order to configure the trace function correctly.

That means runpy needs to support a two stage execution process that allows a client script like pdb to retrieve details of the code to be executed, and then subsequently request that it be executed in a specific namespace. My first thought is to switch to a more object-oriented API along the lines of the following:

- get_path_runner()
- get_module_runner()
    These functions would parallel the current run_module() and run_path() functions, but would return a CodeRunner object instead of directly executing the specified module

- CodeRunner.run(module=None)
    This method would actually execute the code, using the specified namespace if given, or an automatic temporary namespace otherwise.

CodeRunner would store sufficient state to support the delayed execution, as well as providing access to key pieces of information (such as the filename) before code execution actually occurs.

pdb could then largely be left alone from a semantic point of view (i.e. still execute everything in the true __main__ module), except that its current code for finding the script to execute would be replaced by a call to runpy.get_runner_for_path(), a new "-m" switch would be added that tweaked that path to invoke runp.get_runner_for_module() instead, the debugger priming step would query the CodeRunner object for the filename, and finally, the actual code execution step would invoke the run() method of the CodeRunner object (passing in __main__ itself as the target module).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9325>
_______________________________________

From report at bugs.python.org  Fri Apr 15 17:07:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Apr 2011 15:07:47 +0000
Subject: [issue10932] distutils.core.setup - data_files misbehaviour ?
In-Reply-To: <1295353825.23.0.755300594789.issue10932@psf.upfronthosting.co.za>
Message-ID: <1302880067.97.0.148361134207.issue10932@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks great, thanks.  You haven?t addressed this part of my previous message: ?I think the fix may be in the wrong place: You fixed sdist but not bdists.  I think the root of the problem is in the manifest (distutils2) / filelist (distutils1) module.?

I don?t understand this comment: ?Though, inside zip-file we get files without its parent dir, nothing changes in manifest file(should it change?).?

This bug should be fixed in packaging and distutils2, but I?m not sure about distutils: it?s an important change in behavior.  Tarek, Fred, what do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10932>
_______________________________________

From report at bugs.python.org  Fri Apr 15 17:08:27 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Apr 2011 15:08:27 +0000
Subject: [issue11843] distutils doc: duplicate line in table
In-Reply-To: <1302782732.33.0.79290372609.issue11843@psf.upfronthosting.co.za>
Message-ID: <E1QAkdF-0005E1-Nd@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 9e49f4d81f54 by Ezio Melotti in branch '2.7':
#11843: remove duplicate line from table in distutil doc.
http://hg.python.org/cpython/rev/9e49f4d81f54

New changeset 1d6e28df2fb7 by Ezio Melotti in branch '3.1':
#11843: remove duplicate line from table in distutil doc.
http://hg.python.org/cpython/rev/1d6e28df2fb7

New changeset 850a659d9e6f by Ezio Melotti in branch '3.2':
#11843: Merge with 3.1.
http://hg.python.org/cpython/rev/850a659d9e6f

New changeset bf1bf8fb5d55 by Ezio Melotti in branch 'default':
#11843: Merge with 3.2.
http://hg.python.org/cpython/rev/bf1bf8fb5d55

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11843>
_______________________________________

From report at bugs.python.org  Fri Apr 15 17:09:44 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Apr 2011 15:09:44 +0000
Subject: [issue11843] distutils doc: duplicate line in table
In-Reply-To: <1302782732.33.0.79290372609.issue11843@psf.upfronthosting.co.za>
Message-ID: <1302880184.99.0.285156925959.issue11843@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Done, thanks for the report.

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11843>
_______________________________________

From report at bugs.python.org  Fri Apr 15 17:20:58 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 15 Apr 2011 15:20:58 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <20110415152034.GA384@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

I was able to spend more time on that this afternoon.
'Got an unkillable diff(1) along the way which required me to
force a cold reboot.  Well.

I attach a C version (11277.mmap.c) which i've used for testing.
The file 11277.zsum32.c is a quick-and-dirty C program to
calculate CRC-32 and Adler-32 checksums (i had none for the
latter and maybe you want to test some more, so); it requires zlib.
I also attach 11277.1.diff which updates test/test_zlib.py, though
this is rather useless, because that still results in a bus error.

This is the real interesting thing however, because the C version
actually works quite well for the chosen value, and the resulting
files are identical, as zsum32 shows:

    Adler-32 <14b9018b> CRC-32 <c6e340bf> -- test_python_413/@test_413_tmp
    Adler-32 <14b9018b> CRC-32 <c6e340bf> -- c-mmap-testfile

I thought
             os.fsync(f.fileno())
does the trick because it does it in C (hi, Charles-Francois),
but no.
So what do i come up with?
Nothing.  A quick look into 11277.mmap.c will show you this:

    /* *Final* sizes (string written after lseek(2): "abcd") */
...
        /* Tested good */
        //0x100000000 - PAGESIZE - 5,
        //0x100000000 - 4,
        //0x100000000 - 3,
        //0x100000000 - 1,
        0x100000000 + PAGESIZE + 4,
        //0x100000000 + PAGESIZE + 5,
        /* Tested bad */
        //0x100000000,
        //0x100000000 + PAGESIZE,
        //0x100000000 + PAGESIZE + 1,
        //0x100000000 + PAGESIZE + 3,

Hm!
Now i have to go but maybe i can do some more testing tomorrow to
answer the question why test_zlib.py fails even though there is
the fsync() and even though the values work in C.
Any comments?

----------
Added file: http://bugs.python.org/file21671/11277.1.diff
Added file: http://bugs.python.org/file21672/11277.mmap.c
Added file: http://bugs.python.org/file21673/11277.zsum32.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________
-------------- next part --------------
diff --git a/Lib/test/test_zlib.py b/Lib/test/test_zlib.py
--- a/Lib/test/test_zlib.py
+++ b/Lib/test/test_zlib.py
@@ -3,6 +3,7 @@
 import binascii
 import random
 import sys
+import os
 from test.support import precisionbigmemtest, _1G, _4G
 
 zlib = support.import_module('zlib')
@@ -68,9 +69,10 @@
 
     def setUp(self):
         with open(support.TESTFN, "wb+") as f:
-            f.seek(_4G)
-            f.write(b"asdf")
-        with open(support.TESTFN, "rb") as f:
+            f.seek(_4G + mmap.PAGESIZE)
+            f.write(b"abcd")
+            f.flush()
+            os.fsync(f.fileno())
             self.mapping = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
 
     def tearDown(self):
@@ -82,9 +84,8 @@
     @unittest.skipUnless(support.is_resource_enabled("largefile"),
                          "May use lots of disk space.")
     def test_big_buffer(self):
-        self.assertEqual(zlib.crc32(self.mapping), 3058686908)
-        self.assertEqual(zlib.adler32(self.mapping), 82837919)
-
+        self.assertEqual(zlib.crc32(self.mapping), 0xc6e340bf)
+        self.assertEqual(zlib.adler32(self.mapping), 0x14b9018b)
 
 class ExceptionTestCase(unittest.TestCase):
     # make sure we generate some expected errors
-------------- next part --------------

#include <errno.h>
#include <signal.h>
#include <stdio.h>
#include <string.h>

#include <fcntl.h>
#include <unistd.h>

#include <sys/mman.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/uio.h>

#define PATH        "c-mmap-testfile"
#define PAGESIZE    4096

static void sighdl(int);

static void
sighdl(int signo)
{
    const char errmsg[] = "\nSignal occurred, cleaning up\n";
    (void)signo;
    (void)signal(SIGSEGV, SIG_DFL);
    (void)signal(SIGBUS, SIG_DFL);
    write(2, errmsg, sizeof(errmsg)-1);
    (void)unlink(PATH);
    return;
}

int
main(void) {
    int fd, estat = 0;
    void *addr;
    auto struct stat s;
    /* *Final* sizes (string written after lseek(2): "abcd") */
    const size_t *ct, tests[] = {
        /* Tested good */
        //0x100000000 - PAGESIZE - 5,
        //0x100000000 - 4,
        //0x100000000 - 3,
        //0x100000000 - 1,
        0x100000000 + PAGESIZE + 4,
        //0x100000000 + PAGESIZE + 5,
        /* Tested bad */
        //0x100000000,
        //0x100000000 + PAGESIZE,
        //0x100000000 + PAGESIZE + 1,
        //0x100000000 + PAGESIZE + 3,
        0
    };

    if (signal(SIGSEGV, &sighdl) == SIG_ERR)
        goto jerror;
    if (signal(SIGBUS, &sighdl) == SIG_ERR)
        goto jerror;

    for (ct = tests; *ct != 0; ++ct) {
        fprintf(stderr, "Size %lu/0x%lX: open", *ct, *ct);
        fd = open(PATH, O_RDWR|O_TRUNC|O_CREAT, 0666);
        if (fd < 0)
            goto jerror;
        fprintf(stderr, ". ");

        fprintf(stderr, "lseek");
        if (lseek(fd, *ct-4, SEEK_END) < 0)
            goto jerror;
        fprintf(stderr, ". ");

        fprintf(stderr, "write");
        if (write(fd, "abcd", 4) != 4)
            goto jerror;
        fprintf(stderr, ". ");

        fprintf(stderr, "fsync");
        if (fsync(fd) != 0)
            goto jerror;
        fprintf(stderr, ". ");

        fprintf(stderr, "fstat");
        if (fstat(fd, &s) != 0)
            goto jerror;
        fprintf(stderr, ". ");

        if (*ct != (size_t)s.st_size) {
            fprintf(stderr, "fstat size mismatch: %lu is not %lu\n",
                    (size_t)s.st_size, *ct);
            continue;
        }

        fprintf(stderr, "mmap");
        addr = mmap(NULL, s.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
        if (addr == NULL)
            goto jerror;
        fprintf(stderr, ". ");

        (void)close(fd);

        fprintf(stderr, "[0]");
        if (((char*)addr)[0] != '\0')
            goto jerror;
        fprintf(stderr, ". ");

        fprintf(stderr, "[s.st_size-4]");
        if (((char*)addr)[s.st_size-4] != 'a')
            goto jerror;
        fprintf(stderr, ". ");

        fprintf(stderr, "munmap");
        if (munmap(addr, s.st_size) != 0)
            goto jerror;
        fprintf(stderr, ".");

        fprintf(stderr, "\n");
    }

jleave:
    (void)unlink(PATH);
    return estat;

jerror:
    fprintf(stderr, "\n%s\n", strerror(errno));
    estat = 1;
    goto jleave;
}
-------------- next part --------------
/* POSIX crc32/adler32 checksum program; requires zlib (a.k.a. libz)
 * Compile:    cc -o zsum32 zsum32.c -lz
 */

#include <zlib.h>

#include <errno.h>
#include <stdio.h>
#include <string.h>

#define BUFSIZE     (8192*4)

int
main(int argc, char **argv) {
    int estat = 0, erri = 0;
    FILE *f;
    uLong adler, crc;
    const char *errs = NULL;
    auto char buffer[BUFSIZE];

    if (argc != 2) {
        erri = EINVAL;
        errs = "Usage zsum32 FILE";
        goto jerror_noc;
    }
    ++argv;

    f = fopen(*argv, "rb");
    if (f == NULL) {
        erri = errno;
        errs = "fopen()ing the file failed";
        goto jerror_noc;
    }

    adler = adler32(0L, Z_NULL, 0);
    crc = 0;
    for (;;) {
        size_t rb = fread(buffer, 1, BUFSIZE, f);
        if (rb > 0) {
            adler = adler32(adler, (const Bytef*)buffer, (uInt)rb);
            crc = crc32(crc, (const Bytef*)buffer, (uInt)rb);
            continue;
        }
        if (feof(f))
            break;
        erri = errno;
        errs = "fread()ing the file failed";
        goto jerror;
    }
    printf("Adler-32 <%lx> CRC-32 <%lx> -- %s\n",
           (unsigned long)adler, (unsigned long)crc, *argv);

    (void)fclose(f);
jleave:
    return estat;

jerror:
    (void)fclose(f);
jerror_noc:
    fprintf(stderr, "%s: %s\n", errs, strerror(erri));
    estat = 1;
    goto jleave;
}

From report at bugs.python.org  Fri Apr 15 17:24:28 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 15 Apr 2011 15:24:28 +0000
Subject: [issue11731] Simplify email API via 'policy' objects
In-Reply-To: <1301597340.87.0.239759427177.issue11731@psf.upfronthosting.co.za>
Message-ID: <1302881068.01.0.446472623046.issue11731@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

What I hope is the final patch, after Barry's review, and ?ric's second.

----------
Added file: http://bugs.python.org/file21674/policy_final.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11731>
_______________________________________

From report at bugs.python.org  Fri Apr 15 17:27:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Apr 2011 15:27:05 +0000
Subject: [issue11843] distutils doc: duplicate line in table
In-Reply-To: <1302782732.33.0.79290372609.issue11843@psf.upfronthosting.co.za>
Message-ID: <1302881225.34.0.0923863511906.issue11843@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks Ezio.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11843>
_______________________________________

From report at bugs.python.org  Fri Apr 15 17:33:29 2011
From: report at bugs.python.org (higery)
Date: Fri, 15 Apr 2011 15:33:29 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1302881609.82.0.904713210618.issue828450@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

Yes, the test fails and the output msg is: 
AssertionError: '\\' unexpectedly found in '# file GENERATED by distutils, do NOT edit\nREADME\nsetup.py\nsomecode\\__init__.py\n'

It means that distutils generates MANIFEST with '\' as file path separator.

OK, I'll try to make the diff and patch against the dev environment to fix this bug ASAP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Fri Apr 15 17:34:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Apr 2011 15:34:59 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1302881699.49.0.551361917959.issue828450@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks!  I would also like it if you could use a more specific test, comparing a line with a path instead of using the overly broad assertIn, to make the intent of the test clearer.

----------
assignee: tarek -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Fri Apr 15 17:44:39 2011
From: report at bugs.python.org (higery)
Date: Fri, 15 Apr 2011 15:44:39 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1302882279.93.0.1512106476.issue828450@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

OK. I used this method just because I thought '\' is a special character and if it's in a file path line, then it must be the separator. 

As you say, it may be not that clear for others to know what does this test do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Fri Apr 15 18:17:50 2011
From: report at bugs.python.org (Bob Ippolito)
Date: Fri, 15 Apr 2011 16:17:50 +0000
Subject: [issue11844] Update json to upstream simplejson latest release
In-Reply-To: <1302809748.45.0.3421678902.issue11844@psf.upfronthosting.co.za>
Message-ID: <1302884270.48.0.184998628828.issue11844@psf.upfronthosting.co.za>


Bob Ippolito <bob at redivi.com> added the comment:

That's not a problem, I'm more than happy to give permission for any patch. If it's easier I can consider dual-licensing in the simplejson source.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11844>
_______________________________________

From report at bugs.python.org  Fri Apr 15 18:23:11 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 15 Apr 2011 16:23:11 +0000
Subject: [issue11844] Update json to upstream simplejson latest release
In-Reply-To: <1302884270.48.0.184998628828.issue11844@psf.upfronthosting.co.za>
Message-ID: <BANLkTik=7Vo4ra9rSFN6Rc88xGV19huW4w@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Apr 15, 2011 at 12:17 PM, Bob Ippolito <report at bugs.python.org> wrote:
..
> That's not a problem, I'm more than happy to give permission for any patch.
> If it's easier I can consider dual-licensing in the simplejson source.

Can someone who can speak for PSF clarify the mechanics of how this
should be done?  The contributor form seems to suggest that

"""
Contributor shall identify each Contribution by placing the following
notice in its source code adjacent to Contributor's valid copyright
notice: "Licensed to PSF under a Contributor Agreement."
"""

Would it be enough for Bob to add this text here:

 https://github.com/simplejson/simplejson/blob/master/LICENSE.txt

?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11844>
_______________________________________

From report at bugs.python.org  Fri Apr 15 18:28:40 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Apr 2011 16:28:40 +0000
Subject: [issue10665] Expand unicodedata module documentation
In-Reply-To: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za>
Message-ID: <1302884920.14.0.458657401187.issue10665@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Alexander suggested on IRC to use the 'unicode' directive[0], but even if that works in the HTML (only outside code blocks), it still breaks the PDF.
Another alternative that might work is the 'raw' role[1].

[0]: http://docutils.sourceforge.net/docs/ref/rst/directives.html#unicode-character-codes
[1]: http://docutils.sourceforge.net/docs/ref/rst/roles.html#specialized-roles

----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10665>
_______________________________________

From report at bugs.python.org  Fri Apr 15 18:49:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Apr 2011 16:49:37 +0000
Subject: [issue11819] '-m unittest' should not pretend it works on Python
	2.5/2.6
In-Reply-To: <1302420931.81.0.0491321221951.issue11819@psf.upfronthosting.co.za>
Message-ID: <1302886177.59.0.411685501919.issue11819@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I need a "why-python-suxx" keyword to point people with dumb
> questions about why they should not use specific Python versions to a
> query that lists all sensitive issues for this specific version that
> won't be fixed due to security fix only mode.

You may not know it, but repeating over and other that Python, its docs, its development process and/or its developers suck does not raise the incentive to change things.  We?re all volunteers doing our best in our free time, please keep that in mind.  Also consider that when one person keeps saying that everything sucks while other people say that the overall quality is good, it may be that the first person is wrong.

As Ezio said, we have to draw the line.  A constructive outcome of this bug would be a doc patch adding a versionadded directive to the 2.7 docs, which we can fix (and we know that people tend to use the latest version of the docs). 

Leaving aside the inconsiderate comments about suckage, constructive proposals do help.  A lot of things in the current process are good, and you should accept the word of the actual developers for it.  Also remember that both PSF and python-dev are increasingly welcoming of   contributors and trying to improve things.  However, I think it?s best to let the people who actually manage the releases to judge whether changes are required for ?proper release management and future planning?.

In other words, you catch more flies with wine than vinegar.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11819>
_______________________________________

From report at bugs.python.org  Fri Apr 15 18:58:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Apr 2011 16:58:13 +0000
Subject: [issue11824] freeze.py broken due to ABI flags
In-Reply-To: <1302488520.76.0.698152823885.issue11824@psf.upfronthosting.co.za>
Message-ID: <1302886693.06.0.00579433898491.issue11824@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +barry, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11824>
_______________________________________

From report at bugs.python.org  Fri Apr 15 19:00:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Apr 2011 17:00:16 +0000
Subject: [issue11831] "pydoc -w" causes "no Python documentation found" error
	when the path is not current directory
In-Reply-To: <1302568965.6.0.204734578124.issue11831@psf.upfronthosting.co.za>
Message-ID: <1302886816.16.0.997463124586.issue11831@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, ron_adam
title: "python -w" causes "no Python documentation found" error when the path is not current directory -> "pydoc -w" causes "no Python documentation found" error when the path is not current directory

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11831>
_______________________________________

From report at bugs.python.org  Fri Apr 15 19:02:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Apr 2011 17:02:22 +0000
Subject: [issue11834] wrong module installation dir on Windows
In-Reply-To: <1302605256.31.0.234550103785.issue11834@psf.upfronthosting.co.za>
Message-ID: <1302886942.73.0.934026230773.issue11834@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Distutils, Distutils2
nosy: +alexis, eric.araujo
versions: +Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11834>
_______________________________________

From report at bugs.python.org  Fri Apr 15 19:04:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Apr 2011 17:04:46 +0000
Subject: [issue11846] Implementation question for (-5) - 256 caching,
	and doc update for c-api/int.html
In-Reply-To: <1302815567.28.0.789640613127.issue11846@psf.upfronthosting.co.za>
Message-ID: <1302887086.83.0.127906490442.issue11846@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11846>
_______________________________________

From report at bugs.python.org  Fri Apr 15 19:05:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Apr 2011 17:05:00 +0000
Subject: [issue11851] Flushing the standard input causes an error
In-Reply-To: <1302875100.13.0.0605513663919.issue11851@psf.upfronthosting.co.za>
Message-ID: <1302887100.58.0.481330450228.issue11851@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11851>
_______________________________________

From report at bugs.python.org  Fri Apr 15 19:05:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Apr 2011 17:05:57 +0000
Subject: [issue11838] IDLE: make interactive code savable as a runnable script
In-Reply-To: <1302631389.12.0.305553029462.issue11838@psf.upfronthosting.co.za>
Message-ID: <1302887157.99.0.0697410199821.issue11838@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
title: IDLE: make interactive code runnable. -> IDLE: make interactive code savable as a runnable script

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11838>
_______________________________________

From report at bugs.python.org  Fri Apr 15 19:07:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Apr 2011 17:07:16 +0000
Subject: [issue11841] Bug in the verson comparison
In-Reply-To: <1302686380.66.0.407051830429.issue11841@psf.upfronthosting.co.za>
Message-ID: <1302887236.95.0.882062018832.issue11841@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks, looks great!

Why does the code use both a string and a singleton tuple?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11841>
_______________________________________

From report at bugs.python.org  Fri Apr 15 19:09:23 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 15 Apr 2011 17:09:23 +0000
Subject: [issue10665] Expand unicodedata module documentation
In-Reply-To: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za>
Message-ID: <1302887363.22.0.438317319467.issue10665@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> The "PDF generator" is PDFLaTeX, whose range of Unicode characters
> is very limited, so no, I can't fix it.

My search for pdflatex and unicode has quickly revealed this 4-year old howto:

http://tclab.kaist.ac.kr/ipe/pdftex_2.html

I'll experiment with some recent LaTeX distributions before making further effort to work around current unicode limitations.  For example, XeTeX appears to have good unicode support:

http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=xetex

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10665>
_______________________________________

From report at bugs.python.org  Fri Apr 15 19:09:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Apr 2011 17:09:30 +0000
Subject: [issue11776] types.MethodType() params and usage is not documented
In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za>
Message-ID: <1302887370.16.0.664042544755.issue11776@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11776>
_______________________________________

From report at bugs.python.org  Fri Apr 15 19:10:34 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 15 Apr 2011 17:10:34 +0000
Subject: [issue10665] Expand unicodedata module documentation
In-Reply-To: <1302884920.14.0.458657401187.issue10665@psf.upfronthosting.co.za>
Message-ID: <4DA87BFF.2070401@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ezio Melotti wrote:
> 
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> 
> Alexander suggested on IRC to use the 'unicode' directive[0], but even if that works in the HTML (only outside code blocks), it still breaks the PDF.
> Another alternative that might work is the 'raw' role[1].
> 
> [0]: http://docutils.sourceforge.net/docs/ref/rst/directives.html#unicode-character-codes
> [1]: http://docutils.sourceforge.net/docs/ref/rst/roles.html#specialized-roles

I don't think we should include Unicode code points as literals
in Python source code examples, for much the same reason we
don't want them in the stdlib source code.

Why don't you use the standard literal escapes for the examples
and annotate the code points with the code point names ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10665>
_______________________________________

From report at bugs.python.org  Fri Apr 15 19:11:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Apr 2011 17:11:52 +0000
Subject: [issue9904] Cosmetic issues that may warrant a fix in symtable.h/c
In-Reply-To: <1284964146.62.0.95975690396.issue9904@psf.upfronthosting.co.za>
Message-ID: <1302887512.05.0.774488487766.issue9904@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Yep, code cleanup is not done in the stable branches (except as a by-product of a bugfix).

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9904>
_______________________________________

From report at bugs.python.org  Fri Apr 15 19:13:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Apr 2011 17:13:52 +0000
Subject: [issue11186] pydoc: HTMLDoc.index() doesn't support PEP 383
In-Reply-To: <1297428909.69.0.247564466299.issue11186@psf.upfronthosting.co.za>
Message-ID: <1302887632.84.0.533161165711.issue11186@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> It is really a bad idea to choose an *undecodable* name for a module.
> You will not be able to write its name using "import name" syntax.

Okay, makes sense that pydoc ignores those.  You speak about a user choosing to create such a filename though; is it possible to create such a name without knowing it?

> For the changelog, feel free to rephrase it.

I don?t currently have SSH access, so please do it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11186>
_______________________________________

From report at bugs.python.org  Fri Apr 15 19:15:47 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Apr 2011 17:15:47 +0000
Subject: [issue10665] Expand unicodedata module documentation
In-Reply-To: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za>
Message-ID: <1302887747.85.0.115725716249.issue10665@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

One reason is that unicodedata.lookup actually returns a unicode char, so if we want to show a code snippet that uses unicodedata.lookup we either have to use a unicode literal or limit the chars in the examples to latin1 to make sure it works nice with the PDF generator.

Using escape sequences elsewhere might work, but in some examples it's better to use the actual chars IMHO (except that they don't work with the PDF).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10665>
_______________________________________

From report at bugs.python.org  Fri Apr 15 19:23:36 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 15 Apr 2011 17:23:36 +0000
Subject: [issue10665] Expand unicodedata module documentation
In-Reply-To: <1302887747.85.0.115725716249.issue10665@psf.upfronthosting.co.za>
Message-ID: <4DA87F0D.1050800@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ezio Melotti wrote:
> 
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> 
> One reason is that unicodedata.lookup actually returns a unicode char, so if we want to show a code snippet that uses unicodedata.lookup we either have to use a unicode literal or limit the chars in the examples to latin1 to make sure it works nice with the PDF generator.

Why not wrap the calls with a repr() ?

> Using escape sequences elsewhere might work, but in some examples it's better to use the actual chars IMHO (except that they don't work with the PDF).

Sure, it'll look nicer, but it will also make comparing the examples
with the actual output users see on the screen error-prone (e.g. if
the fonts don't have the necessary glyphs).

Copy&paste will also often fail.

I think it's more useful to show examples that more or less always
work, than ones which display all available goodies.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10665>
_______________________________________

From report at bugs.python.org  Fri Apr 15 19:25:01 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 15 Apr 2011 17:25:01 +0000
Subject: [issue10665] Expand unicodedata module documentation
In-Reply-To: <4DA87BFF.2070401@egenix.com>
Message-ID: <BANLkTik-+O1GWjE52Nh+MjK4TROSG772Mw@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Apr 15, 2011 at 1:10 PM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
>..
> Why don't you use the standard literal escapes for the examples
> and annotate the code points with the code point names ?

A am neutral on how to enter unicode characters in source reST.   In
the previous discussions most people seemed to prefer WISIWYG.  If
literal escapes solved the PDF issue, I would use it even at the
expense of loosing testability of the output displays.

Code point names as usually very long for exotic characters that
illustrate UCD features.  I like presenting them, but in tables I'd
rather present more examples and still keep column width reasonable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10665>
_______________________________________

From report at bugs.python.org  Fri Apr 15 19:25:18 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Fri, 15 Apr 2011 17:25:18 +0000
Subject: [issue11841] Bug in the verson comparison
In-Reply-To: <1302686380.66.0.407051830429.issue11841@psf.upfronthosting.co.za>
Message-ID: <1302888318.63.0.447382325349.issue11841@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

The reason for the use of two constants is that previously there was comparison in the code with a hardcoded 'f':

            if postdev[0] == 'f':

I think it's a common practice to create constants for such hardcoded values. Also this hit when I was making a patch. I didn't know, that 'f' was used in the code and when I changed _FINAL_MARKER to ('f',), some tests failed. Alternatively to what I did in the patch you can use:

             if postdev[0] == _FINAL_MARKER[0]:

but it just doesn't feel right for me.

Anyway, I can't find packaging package in default branch of python. Where is the development done? I'd be happy to try to provide some more patches for this package, if there is a need for any.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11841>
_______________________________________

From report at bugs.python.org  Fri Apr 15 19:30:58 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Fri, 15 Apr 2011 17:30:58 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1302888658.14.0.475034719995.issue828450@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Fri Apr 15 19:37:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Apr 2011 17:37:23 +0000
Subject: [issue11841] Bug in the verson comparison
In-Reply-To: <1302686380.66.0.407051830429.issue11841@psf.upfronthosting.co.za>
Message-ID: <1302889043.6.0.467787104388.issue11841@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I think it's a common practice to create constants for such hardcoded
> values.

Yep, _FINAL_MARKER is clearer here that a cryptic character.  An alternate fix would be to use a c as rc marker (like what Python itself does in sys.hexversion and elsewhere).

I?ll see if I can use only one object instead of two.

> Anyway, I can't find packaging package in default branch of python.
The merge started at the PyCon sprints is still underway at https://bitbucket.org/tarek/cpython/  Follow the fellowship ML for details.  There?ll be an announcement on python-dev too when it?s complete, and then we?ll restart fixing bugs.

----------
assignee: tarek -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11841>
_______________________________________

From report at bugs.python.org  Fri Apr 15 19:38:40 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 15 Apr 2011 17:38:40 +0000
Subject: [issue10665] Expand unicodedata module documentation
In-Reply-To: <4DA87F0D.1050800@egenix.com>
Message-ID: <BANLkTi=zzNYo3M2Sfi=eb+LNZkG_2bbDJw@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Apr 15, 2011 at 1:23 PM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
>..
> Why not wrap the calls with a repr() ?
>

Won't help:

"'?'"

I think you meant ascii(), but that's ugly IMO:

"'\\u04dc'"

Maybe

'\u04dc'

but that's too much of scaffolding.

..
> I think it's more useful to show examples that more or less always
> work, than ones which display all available goodies.

I disagree.  Users that are advanced enough to be interested in
reading unicodedata reference documentation should be capable of
either fixing their environment or understanding its limitations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10665>
_______________________________________

From report at bugs.python.org  Fri Apr 15 19:40:13 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Fri, 15 Apr 2011 17:40:13 +0000
Subject: [issue11841] Bug in the verson comparison
In-Reply-To: <1302686380.66.0.407051830429.issue11841@psf.upfronthosting.co.za>
Message-ID: <1302889213.38.0.676001331155.issue11841@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I understand that ML is mailing list, but I have no idea what is fellowship mailing list. Could you elaborate on this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11841>
_______________________________________

From report at bugs.python.org  Fri Apr 15 20:04:28 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 15 Apr 2011 18:04:28 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1302890668.67.0.822499010654.issue11277@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file20838/issue11277.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Fri Apr 15 20:12:24 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 15 Apr 2011 18:12:24 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <20110415181212.GA14988@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

My last idea for today was to split the writes.
This also works for the C version, but it does not for test_zlib.py.
I attach the updated files.  And for completeness:

    Adler-32 <7a54018b> CRC-32 <7f1be672> -- @test_13713_tmp
    Adler-32 <7a54018b> CRC-32 <7f1be672> -- c-mmap-testfile

----------
Added file: http://bugs.python.org/file21675/11277.2.diff
Added file: http://bugs.python.org/file21676/11277.mmap-1.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________
-------------- next part --------------
diff --git a/Lib/test/test_zlib.py b/Lib/test/test_zlib.py
--- a/Lib/test/test_zlib.py
+++ b/Lib/test/test_zlib.py
@@ -3,6 +3,7 @@
 import binascii
 import random
 import sys
+import os
 from test.support import precisionbigmemtest, _1G, _4G
 
 zlib = support.import_module('zlib')
@@ -68,9 +69,11 @@
 
     def setUp(self):
         with open(support.TESTFN, "wb+") as f:
-            f.seek(_4G)
-            f.write(b"asdf")
-        with open(support.TESTFN, "rb") as f:
+            f.write(b"a")
+            f.seek(_4G + mmap.PAGESIZE + 1)
+            f.write(b"bcd")
+            f.flush()
+            os.fsync(f.fileno())
             self.mapping = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
 
     def tearDown(self):
@@ -82,9 +85,8 @@
     @unittest.skipUnless(support.is_resource_enabled("largefile"),
                          "May use lots of disk space.")
     def test_big_buffer(self):
-        self.assertEqual(zlib.crc32(self.mapping), 3058686908)
-        self.assertEqual(zlib.adler32(self.mapping), 82837919)
-
+        self.assertEqual(zlib.crc32(self.mapping), 0x7f1be672)
+        self.assertEqual(zlib.adler32(self.mapping), 0x7a54018b)
 
 class ExceptionTestCase(unittest.TestCase):
     # make sure we generate some expected errors
-------------- next part --------------

#include <errno.h>
#include <signal.h>
#include <stdio.h>
#include <string.h>

#include <fcntl.h>
#include <unistd.h>

#include <sys/mman.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/uio.h>

#define PATH        "c-mmap-testfile"
#define PAGESIZE    4096

static void sighdl(int);

static void
sighdl(int signo)
{
    const char errmsg[] = "\nSignal occurred, cleaning up\n";
    (void)signo;
    (void)signal(SIGSEGV, SIG_DFL);
    (void)signal(SIGBUS, SIG_DFL);
    write(2, errmsg, sizeof(errmsg)-1);
    (void)unlink(PATH);
    return;
}

int
main(void) {
    int fd, estat = 0;
    void *addr;
    auto struct stat s;
    /* *Final* sizes (string written after lseek(2): "abcd") */
    const size_t *ct, tests[] = {
        /* Tested good */
        //0x100000000 - PAGESIZE - 5,
        //0x100000000 - 4,
        //0x100000000 - 3,
        //0x100000000 - 1,
        0x100000000 + PAGESIZE + 4,
        //0x100000000 + PAGESIZE + 5,
        /* Tested bad */
        //0x100000000,
        //0x100000000 + PAGESIZE,
        //0x100000000 + PAGESIZE + 1,
        //0x100000000 + PAGESIZE + 3,
        0
    };

    if (signal(SIGSEGV, &sighdl) == SIG_ERR)
        goto jerror;
    if (signal(SIGBUS, &sighdl) == SIG_ERR)
        goto jerror;

    for (ct = tests; *ct != 0; ++ct) {
        fprintf(stderr, "Size %lu/0x%lX: open", *ct, *ct);
        fd = open(PATH, O_RDWR|O_TRUNC|O_CREAT, 0666);
        if (fd < 0)
            goto jerror;
        fprintf(stderr, ". ");

        fprintf(stderr, "write-I");
        if (write(fd, "a", 1) != 1)
            goto jerror;
        fprintf(stderr, ". ");

        fprintf(stderr, "lseek");
        if (lseek(fd, *ct-4, SEEK_END) < 0)
            goto jerror;
        fprintf(stderr, ". ");

        fprintf(stderr, "write-II");
        if (write(fd, "bcd", 3) != 3)
            goto jerror;
        fprintf(stderr, ". ");

        fprintf(stderr, "fsync");
        if (fsync(fd) != 0)
            goto jerror;
        fprintf(stderr, ". ");

        fprintf(stderr, "fstat");
        if (fstat(fd, &s) != 0)
            goto jerror;
        fprintf(stderr, ". ");

        if (*ct != (size_t)s.st_size) {
            fprintf(stderr, "fstat size mismatch: %lu is not %lu\n",
                    (size_t)s.st_size, *ct);
            continue;
        }

        fprintf(stderr, "mmap");
        addr = mmap(NULL, s.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
        if (addr == NULL)
            goto jerror;
        fprintf(stderr, ". ");

        (void)close(fd);

        fprintf(stderr, "[0]");
        if (((char*)addr)[0] != 'a')
            goto jerror;
        fprintf(stderr, ". ");

        fprintf(stderr, "[s.st_size-3]");
        if (((char*)addr)[s.st_size-3] != 'b')
            goto jerror;
        fprintf(stderr, ". ");

        fprintf(stderr, "munmap");
        if (munmap(addr, s.st_size) != 0)
            goto jerror;
        fprintf(stderr, ".");

        fprintf(stderr, "\n");
    }

jleave:
    (void)unlink(PATH);
    return estat;

jerror:
    fprintf(stderr, "\n%s\n", strerror(errno));
    estat = 1;
    goto jleave;
}

From report at bugs.python.org  Fri Apr 15 20:24:05 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 15 Apr 2011 18:24:05 +0000
Subject: [issue11851] Flushing the standard input causes an error
In-Reply-To: <1302875100.13.0.0605513663919.issue11851@psf.upfronthosting.co.za>
Message-ID: <1302891845.35.0.0950799059469.issue11851@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I can't reproduce this Under Solaris 10 or Ubuntu. Maybe is it something Apple related?.

Anyway, does it makes sense to flush sys.stdin, at all?.

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11851>
_______________________________________

From report at bugs.python.org  Fri Apr 15 20:34:53 2011
From: report at bugs.python.org (Baptiste Lepilleur)
Date: Fri, 15 Apr 2011 18:34:53 +0000
Subject: [issue11852] New QueueListener is unusable due to threading and queue
	import
In-Reply-To: <1302892493.02.0.649799543417.issue11852@psf.upfronthosting.co.za>
Message-ID: <1302892493.02.0.649799543417.issue11852@psf.upfronthosting.co.za>


New submission from Baptiste Lepilleur <blep at users.sourceforge.net>:

How to reproduce:

>>> from logging.handlers import QueueListener
>>> from multiprocessing import Queue
>>> q = Queue(100)
>>> l = QueueListener(q)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python32\lib\logging\handlers.py", line 1234, in __init__
    self._stop = threading.Event()
NameError: global name 'threading' is not defined

And after adding the 'threading' import, you run into a second missing module:

Traceback (most recent call last):
  File "C:\Python32\lib\threading.py", line 736, in _bootstrap_inner
    self.run()
  File "C:\Python32\lib\threading.py", line 689, in run
    self._target(*self._args, **self._kwargs)
  File "C:\Python32\lib\logging\handlers.py", line 1297, in _monitor
    except queue.Empty:
NameError: global name 'queue' is not defined
 
Solution:

Adds import of 'threading' and 'queue' module in logging.handlers module.

----------
components: Library (Lib)
messages: 133862
nosy: blep
priority: normal
severity: normal
status: open
title: New QueueListener is unusable due to threading and queue import
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11852>
_______________________________________

From report at bugs.python.org  Fri Apr 15 20:42:31 2011
From: report at bugs.python.org (Baptiste Lepilleur)
Date: Fri, 15 Apr 2011 18:42:31 +0000
Subject: [issue11852] New QueueListener is unusable due to threading and queue
	import
In-Reply-To: <1302892493.02.0.649799543417.issue11852@psf.upfronthosting.co.za>
Message-ID: <1302892951.75.0.620710829172.issue11852@psf.upfronthosting.co.za>


Baptiste Lepilleur <blep at users.sourceforge.net> added the comment:

Forgot to give the precise python version:
Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11852>
_______________________________________

From report at bugs.python.org  Fri Apr 15 20:43:10 2011
From: report at bugs.python.org (Baptiste Lepilleur)
Date: Fri, 15 Apr 2011 18:43:10 +0000
Subject: [issue11852] New QueueListener is unusable due to missing threading
	and queue import
In-Reply-To: <1302892493.02.0.649799543417.issue11852@psf.upfronthosting.co.za>
Message-ID: <1302892990.67.0.12100465103.issue11852@psf.upfronthosting.co.za>


Changes by Baptiste Lepilleur <blep at users.sourceforge.net>:


----------
title: New QueueListener is unusable due to threading and queue import -> New QueueListener is unusable due to missing threading and queue import

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11852>
_______________________________________

From report at bugs.python.org  Fri Apr 15 21:00:07 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Fri, 15 Apr 2011 19:00:07 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1302894007.21.0.539884709421.issue10517@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

This is due to a bug in the TLS key management when mixed with fork.
Here's what happens:
When a thread is created, a tstate is allocated and stored in the thread's TLS:
thread_PyThread_start_new_thread -> t_bootstrap -> _PyThreadState_Init -> _PyGILState_NoteThreadState:

    if (PyThread_set_key_value(autoTLSkey, (void *)tstate) < 0)
        Py_FatalError("Couldn't create autoTLSkey mapping");

where 
int
PyThread_set_key_value(int key, void *value)
{
    int fail;
    void *oldValue = pthread_getspecific(key);
    if (oldValue != NULL)
        return 0;
    fail = pthread_setspecific(key, value);
    return fail;
}

A pthread_getspecific(key) is performed to see if there was already a value associated to this key.
The problem is that, if a process has a thread with a given thread ID (and a tstate stored in its TLS), and then the process forks (from another thread), if a new thread is created with the same thread ID as the thread in the child process, pthread_getspecific(key) will return the value stored by the other thread (with the same thread ID). In short, thread-specific values are inherited across fork, and if you're unlucky and create a thread with a thread ID already existing in the parent process, you're screwed.
To conclude, PyGILState_GetThisThreadState, which calls PyThread_get_key_value(autoTLSkey) will return the other thread's tstate, which will triggers this fatal error in PyThreadState_Swap.

The patch attached fixes this issue by removing the call to pthread_getspecific(key) from PyThread_set_key_value. This solves the problem and doesn't seem to cause any regression in test_threading and test_multiprocessing, and I think that if we were to call PyThread_set_key_value twice on the same key it's either an error, or we want the last version to be stored, not the old one.
test_threading and test_multiprocessing now run fine without any fatal error.

Note that this is probably be a bug in RHEL pthread's implementation, but given how widespread RHEL and derived distros are, I think this should be fixed.
I've attached a patch and a small test program to check if thread-specific data is inherited across a fork.
Here's a sample run on a RHEL4U8 box:

$ /tmp/test
PID: 17922, TID: 3086187424, init value: (nil)
PID: 17924, TID: 3086187424, init value: 0xdeadbeef

The second thread has been created in the child process and inherited the first thread's (created by the parent) key's value (one condition for this to happen is of course that the second thread is allocated the same thread ID as the first one).

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Fri Apr 15 21:00:40 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Fri, 15 Apr 2011 19:00:40 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1302894040.91.0.0805145392332.issue10517@psf.upfronthosting.co.za>


Changes by Charles-Francois Natali <neologix at free.fr>:


Added file: http://bugs.python.org/file21677/test_specific.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Fri Apr 15 21:05:02 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Fri, 15 Apr 2011 19:05:02 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1302894302.63.0.0909415379044.issue10517@psf.upfronthosting.co.za>


Changes by Charles-Francois Natali <neologix at free.fr>:


----------
keywords: +patch
Added file: http://bugs.python.org/file21678/thread_invalid_key.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Fri Apr 15 21:22:15 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Fri, 15 Apr 2011 19:22:15 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1302895335.09.0.326977961348.issue10517@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Note: this seems to be fixed in RHEL6.
(Sorry for the noise).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Fri Apr 15 21:23:33 2011
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 15 Apr 2011 19:23:33 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1302895413.46.0.724419355986.issue10517@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Now, I'd be super happy to see this strange semantics of PyThread_set_key_value go away.  Its very un-standard and complicates the mapping from an native implementation to the python one.
But I think I did once bring up this issue, and was told that it was a bad idea.
But your logic is sound.  Doing two Sets, is an error regardless.  Hiding the error by ignoring the second set is arbitrarily as bad as ignoring the first thing.
So, if it is possible to fix this and remove this weird special case and cast it into the abyss, then by all means, you have my 10 thumbs up.  Not that it counts for much :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Fri Apr 15 21:30:39 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Apr 2011 19:30:39 +0000
Subject: [issue11803] Memory leak in sub-interpreters
In-Reply-To: <1302246410.34.0.932869842046.issue11803@psf.upfronthosting.co.za>
Message-ID: <1302895839.63.0.307569242124.issue11803@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Swapnil, please pay attention to what people write.
PYTHON 2.6 IS NOT OPEN FOR BUGFIXES.
Please do not add 2.6 to this issue again or reopen until you find a problem with 2.7.1 or 3.2.0.

----------
nosy: +terry.reedy
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11803>
_______________________________________

From report at bugs.python.org  Fri Apr 15 21:39:33 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Apr 2011 19:39:33 +0000
Subject: [issue11812] transient test_telnetlib failure
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1302896373.37.0.476702972133.issue11812@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

What do you propose for a fix?
1. Find a more reliable host to test with?
2. Change test to catch the error and convert failure to a skip?
3. Both ;-?
4. Something else?

Something like 2 would seem like a good idea for all tests dependent on a resource out of developers' control.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Fri Apr 15 21:52:12 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 15 Apr 2011 19:52:12 +0000
Subject: [issue11851] Flushing the standard input causes an error
In-Reply-To: <1302875100.13.0.0605513663919.issue11851@psf.upfronthosting.co.za>
Message-ID: <1302897132.93.0.596611528176.issue11851@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I get the same:


$ python2.7
Python 2.7.1 (r271:86882M, Nov 30 2010, 10:35:34) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.stdin.flush()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 9] Bad file descriptor

I'll look further.

----------
assignee:  -> belopolsky
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11851>
_______________________________________

From report at bugs.python.org  Fri Apr 15 21:53:45 2011
From: report at bugs.python.org (Nir Aides)
Date: Fri, 15 Apr 2011 19:53:45 +0000
Subject: [issue10037] multiprocessing.pool processes started by worker handler
	stops working
In-Reply-To: <1286364358.68.0.746245038707.issue10037@psf.upfronthosting.co.za>
Message-ID: <1302897225.9.0.837672565493.issue10037@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


----------
nosy: +nirai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10037>
_______________________________________

From report at bugs.python.org  Fri Apr 15 21:56:16 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 15 Apr 2011 19:56:16 +0000
Subject: [issue11852] New QueueListener is unusable due to missing threading
	and queue import
In-Reply-To: <1302892493.02.0.649799543417.issue11852@psf.upfronthosting.co.za>
Message-ID: <1302897376.77.0.971111481082.issue11852@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
assignee:  -> vinay.sajip
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11852>
_______________________________________

From report at bugs.python.org  Fri Apr 15 21:57:15 2011
From: report at bugs.python.org (ackounts)
Date: Fri, 15 Apr 2011 19:57:15 +0000
Subject: [issue11847] OSError importing antigravity module
In-Reply-To: <1302818631.56.0.0963133113635.issue11847@psf.upfronthosting.co.za>
Message-ID: <1302897435.31.0.0166520471479.issue11847@psf.upfronthosting.co.za>


ackounts <ackounts at gmail.com> added the comment:

You right, webbrowser.open fails too. It was a duplicate one, sorry guys.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11847>
_______________________________________

From report at bugs.python.org  Fri Apr 15 22:09:19 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 15 Apr 2011 20:09:19 +0000
Subject: [issue11851] Flushing the standard input causes an error
In-Reply-To: <1302875100.13.0.0605513663919.issue11851@psf.upfronthosting.co.za>
Message-ID: <1302898159.86.0.0144162031611.issue11851@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

In python 2.x, sys.stdin.flush() is more or less equivalent to C fflush(stdin).  The behavior of fflush() on streams that are open for reading only is undefined. [1]

Python 3.x io does not use C stdio library and therefore it is not surprising that the behavior is different.

[1] http://pubs.opengroup.org/onlinepubs/009695399/functions/fflush.html

----------
components: +Interpreter Core -None
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11851>
_______________________________________

From report at bugs.python.org  Fri Apr 15 22:32:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Apr 2011 20:32:35 +0000
Subject: [issue11812] transient test_telnetlib failure
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1302899555.06.0.317875824583.issue11812@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> 1. Find a more reliable host to test with?

Well, if you find a more reliable host than "localhost", why not ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Fri Apr 15 22:47:41 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Apr 2011 20:47:41 +0000
Subject: [issue11820] idle3 shell os.system swallows shell command output
In-Reply-To: <1302421540.99.0.957938249964.issue11820@psf.upfronthosting.co.za>
Message-ID: <1302900461.16.0.730290368986.issue11820@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am not sure if this should be called a bug or feature request, but that does not matter so much with IDLE. 

Os.system is documented as executing in a subshell and returning the exit code, which is does. The doc also says "If command generates any output, it will be sent to the interpreter standard output stream."

IDLE tries to imitate the interpreter, but it is not the interpreter, and I am not sure if that is always possible. The problem is that IDLE sends code (or, I presume, a filename) to a windowless interpreter (via socket or pipe) and receives and displays whatever is sent back. So I suspect the problem and fix is and would have to be with how a windowless interpreter executes os.system (in a third process). But for all I know, it may be the OS that decides not to hook the output of a system process to a no-window process that calls it.

On Windows, os.system('dir') ('dir' == 'ls') within IDLE pops up a command window to display the output, which immediately disappears. The same within the interactive interpreter (in a Command Prompt window) displays the output, just as with your XTerminal case.

Os.getcwd is documented as returning a string, so of course it does. It is not relevant to this issue.

Because of problems with os.system, the docs end with a suggestion to use subprocess instead. So there may be reluctance to 'fix' os.system calls.

The subprocess doc has an example for 'ls'. For 3.2 it is

>>> subprocess.check_output(["ls", "-l", "/dev/null"])
b'crw-rw-rw- 1 root root 1, 3 Oct 18  2007 /dev/null\n'

but the quotes and \n suggest that multiline output would not display properly.

On Windows with 3.2, the following works

>>> print(subprocess.check_output(['dir'], shell=True).decode())
 Volume in drive C is HP_PAVILION
 Volume Serial Number is 6C44-B700

 Directory of C:\Programs\Python32

shell=True is needed for 'dir' to be recognized.
Both print and .decode() are needed for proper line breaks.

The same info for the current directory is also available in an Open File or Save File dialog, so the ls/dir is really not needed.

----------
components: +Interpreter Core
nosy: +terry.reedy
versions: +Python 3.2, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11820>
_______________________________________

From report at bugs.python.org  Fri Apr 15 23:11:01 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Apr 2011 21:11:01 +0000
Subject: [issue11851] Flushing the standard input causes an error
In-Reply-To: <1302875100.13.0.0605513663919.issue11851@psf.upfronthosting.co.za>
Message-ID: <1302901861.21.0.819469738969.issue11851@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Python 2.7.1  ... 32 bit (Intel)] on win32
>>> import sys
>>> sys.stdin.flush()
>>>

stdin.flush() could mean to clear (discard) the input buffer. Given that it is undefined, the puzzle is that it exists at all, even to be called. 
Consistency across platforms is why we wrote io for Py3. Agreed not a bug for 2.x.

----------
components: +Macintosh
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11851>
_______________________________________

From report at bugs.python.org  Fri Apr 15 23:23:34 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Fri, 15 Apr 2011 21:23:34 +0000
Subject: [issue9650] format codes in time.strptime docstrings
In-Reply-To: <1282319380.5.0.724924373031.issue9650@psf.upfronthosting.co.za>
Message-ID: <1302902614.32.0.0799670602389.issue9650@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9650>
_______________________________________

From report at bugs.python.org  Fri Apr 15 23:29:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Apr 2011 21:29:47 +0000
Subject: [issue11852] New QueueListener is unusable due to missing threading
	and queue import
In-Reply-To: <1302892493.02.0.649799543417.issue11852@psf.upfronthosting.co.za>
Message-ID: <E1QAqaC-0002no-Ec@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3b700e6704b3 by Vinay Sajip in branch '3.2':
Issue #11852: Add missing imports and update tests.
http://hg.python.org/cpython/rev/3b700e6704b3

New changeset f5a6367e11e2 by Vinay Sajip in branch 'default':
Issue #11852: Merge fix from 3.2.
http://hg.python.org/cpython/rev/f5a6367e11e2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11852>
_______________________________________

From report at bugs.python.org  Fri Apr 15 23:30:44 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 15 Apr 2011 21:30:44 +0000
Subject: [issue11852] New QueueListener is unusable due to missing threading
	and queue import
In-Reply-To: <1302892493.02.0.649799543417.issue11852@psf.upfronthosting.co.za>
Message-ID: <1302903044.28.0.536601303678.issue11852@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/issue11852>
_______________________________________

From report at bugs.python.org  Sat Apr 16 00:39:08 2011
From: report at bugs.python.org (Edzard Pasma)
Date: Fri, 15 Apr 2011 22:39:08 +0000
Subject: [issue11851] Flushing the standard input causes an error
In-Reply-To: <1302875100.13.0.0605513663919.issue11851@psf.upfronthosting.co.za>
Message-ID: <1302907148.13.0.178521546857.issue11851@psf.upfronthosting.co.za>


Edzard Pasma <pasma10 at concepts.nl> added the comment:

Thanks a lot, especially for making clear what flushing an input stream means (or that it is meaningless). I hope it will be solved in APSW, there is an issue now: http://code.google.com/p/apsw/issues/detail?id=117

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11851>
_______________________________________

From report at bugs.python.org  Sat Apr 16 03:52:29 2011
From: report at bugs.python.org (kent)
Date: Sat, 16 Apr 2011 01:52:29 +0000
Subject: [issue11820] idle3 shell os.system swallows shell command output
In-Reply-To: <1302421540.99.0.957938249964.issue11820@psf.upfronthosting.co.za>
Message-ID: <1302918749.54.0.847104259546.issue11820@psf.upfronthosting.co.za>


kent <fuzzballz at comcast.net> added the comment:

I tried using subprocess.Popen and subprocess.call, both of which did the same behavior. Under the interpreter I get the desired string output:
>>> subprocess.call('ls')
bin      Documents  eclipse  local  Pictures   tmp     workspace
Desktop  Downloads  hamlib   Music  Templates  Videos
0

Under Idle:

>>> subprocess.call('ls')
0
Thus the subprocess.call method provides the string output.  Why should I have to use the subprocess.check_output('command').decode() when subprocess.call() gives me what I want?

Thus it does not seem to be an os.system issue, but a failure of Idle to capture the sysoutput string as the interpreter does  The xterminal example highlights this.  The sysoutput is echoed at the xterminal not in idle.

You are correct there are other ways to get the specific information for ls.  I was using that as test command.  I was experimenting with the commands in order to a write a program which will run an executable under either windows or linux.  I wanted to see the output in the interpreter in order to test it.  I was using Idle for the testing.  It does NOT work the same as the interpreter.  If Idle is to be useful as an IDE, shouldn't it's shell work the same as the interpreter? If it doesn't why use Idle ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11820>
_______________________________________

From report at bugs.python.org  Sat Apr 16 05:48:27 2011
From: report at bugs.python.org (John DeNero)
Date: Sat, 16 Apr 2011 03:48:27 +0000
Subject: [issue11853] idle3.2 on mac unresponsive on input() called from a
	source file
In-Reply-To: <1302925707.76.0.539725680969.issue11853@psf.upfronthosting.co.za>
Message-ID: <1302925707.76.0.539725680969.issue11853@psf.upfronthosting.co.za>


New submission from John DeNero <denero at google.com>:

idle3.2 becomes unresponsive if the input() function is called from a source file run via F5.

To repeat:
- Create a script file with the contents: "input()"
- Press F5 to run
- Idle is now unresponsive and ^C interrupt is not caught unless issued at the command line

Note that calling input() from idle's interactive shell works fine, as does running the script from the command line.

----------
components: IDLE
files: input.py
messages: 133878
nosy: John.DeNero
priority: normal
severity: normal
status: open
title: idle3.2 on mac unresponsive on input() called from a source file
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file21679/input.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11853>
_______________________________________

From report at bugs.python.org  Sat Apr 16 05:51:00 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 16 Apr 2011 03:51:00 +0000
Subject: [issue9904] Cosmetic issues that may warrant a fix in symtable.h/c
In-Reply-To: <1284964146.62.0.95975690396.issue9904@psf.upfronthosting.co.za>
Message-ID: <1302925860.81.0.847415986371.issue9904@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Thanks for the clarification, ?ric

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9904>
_______________________________________

From report at bugs.python.org  Sat Apr 16 07:29:55 2011
From: report at bugs.python.org (Robert Burke)
Date: Sat, 16 Apr 2011 05:29:55 +0000
Subject: [issue11854] __or__, __and__, __sub__,
	and __xor__ instantiate subclass of set without calling __init__
In-Reply-To: <1302931795.31.0.443472549499.issue11854@psf.upfronthosting.co.za>
Message-ID: <1302931795.31.0.443472549499.issue11854@psf.upfronthosting.co.za>


New submission from Robert Burke <sharpobject at gmail.com>:

If you create a subclass of set but do not override __or__, __and__, __xor__, and __sub__, calling these functions will yield a new instance of your subclass.  The new instance will never have __init__ called on it.  Depending on what you expect __init__ to do, this can cause problems later on.

The simplest solution would be to make these functions work like list.__add__.  If you have two instances of some list subclass (foo and bar), type(foo.__add__(bar)) will just be list.

----------
files: demo
messages: 133880
nosy: Robert.Burke
priority: normal
severity: normal
status: open
title: __or__, __and__, __sub__, and __xor__ instantiate subclass of set without calling __init__
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file21680/demo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11854>
_______________________________________

From report at bugs.python.org  Sat Apr 16 07:35:06 2011
From: report at bugs.python.org (Robert Burke)
Date: Sat, 16 Apr 2011 05:35:06 +0000
Subject: [issue11854] __or__ et al instantiate subclass of set without calling
	__init__
In-Reply-To: <1302931795.31.0.443472549499.issue11854@psf.upfronthosting.co.za>
Message-ID: <1302932106.43.0.940248928138.issue11854@psf.upfronthosting.co.za>


Changes by Robert Burke <sharpobject at gmail.com>:


----------
title: __or__, __and__, __sub__, and __xor__ instantiate subclass of set without calling __init__ -> __or__ et al instantiate subclass of set without calling __init__

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11854>
_______________________________________

From report at bugs.python.org  Sat Apr 16 08:17:16 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 16 Apr 2011 06:17:16 +0000
Subject: [issue11820] idle3 shell os.system swallows shell command output
In-Reply-To: <1302421540.99.0.957938249964.issue11820@psf.upfronthosting.co.za>
Message-ID: <1302934636.68.0.870845495219.issue11820@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I agree that it is kind of odd behavior and, after a quick look back through open issues, I was a bit surprised to not find an open issue about it (although I may have overlooked one).

"Thus it does not seem to be an os.system issue, but a failure of Idle to capture the sysoutput string as the interpreter does  The xterminal example highlights this.  The sysoutput is echoed at the xterminal not in idle."

The reason this is an issue is because the interpreter does *not* do anything special to capture stdout from subprocesses.  If you're running the interpreter in a terminal window both stdout from the interpreter process and, by default, stdout from any child processes, like those created by os.system or subprocess (if you don't override it), inherit the same stdout and so the output from both processes show up in the same place (i.e. terminal session) automatically.  When running under IDLE though, IDLE uses its own proxy output object to intercept the output from the interpreter but does not do anything special for stdout from subprocesses so that output ends up in unexpected places: the terminal session from which IDLE was launched or the transient window on Windows or into the system log with the OS X IDLE.app.  I think IDLE could do a better job of intercepting stdout for these cases but it might be a bit tricky to make it work across all platforms.

----------
components:  -Interpreter Core
nosy: +ned.deily
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11820>
_______________________________________

From report at bugs.python.org  Sat Apr 16 08:18:47 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 16 Apr 2011 06:18:47 +0000
Subject: [issue11854] __or__ et al instantiate subclass of set without calling
	__init__
In-Reply-To: <1302931795.31.0.443472549499.issue11854@psf.upfronthosting.co.za>
Message-ID: <1302934727.1.0.133503325019.issue11854@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11854>
_______________________________________

From report at bugs.python.org  Sat Apr 16 08:26:16 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 16 Apr 2011 06:26:16 +0000
Subject: [issue11853] idle3.2 on mac unresponsive on input() called from a
	source file
In-Reply-To: <1302925707.76.0.539725680969.issue11853@psf.upfronthosting.co.za>
Message-ID: <1302935176.48.0.013328277586.issue11853@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for the report. This is the same problem as reported in Issue11088.  A fix will be available in the next releases of Python 3.2 and 2.7.  A workaround is to use the 32-bit-only version of Python 3.2 which uses the Tcl/Tk 8.4 or to not try to do input() in an editor window.

----------
assignee:  -> ned.deily
nosy: +ned.deily
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> IDLE on OS X with Cocoa Tk 8.5 can hang waiting on input / raw_input
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11853>
_______________________________________

From report at bugs.python.org  Sat Apr 16 08:33:17 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 16 Apr 2011 06:33:17 +0000
Subject: [issue11851] Flushing the standard input causes an error
In-Reply-To: <1302875100.13.0.0605513663919.issue11851@psf.upfronthosting.co.za>
Message-ID: <1302935597.28.0.0163812249731.issue11851@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

"Given that it is undefined, the puzzle is that it exists at all, even to be called."  No puzzle at all: in Python 2, stdin is a file object which automatically has a flush method. And the behavior seen here is not limited to OS X; FreeBSD, for one, gives exactly the same error.

----------
components:  -Macintosh
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11851>
_______________________________________

From report at bugs.python.org  Sat Apr 16 08:46:12 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 16 Apr 2011 06:46:12 +0000
Subject: [issue10665] Expand unicodedata module documentation
In-Reply-To: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za>
Message-ID: <1302936372.2.0.795197497285.issue10665@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Can y'all please accept the limitation to latin-1?  Like Marc-Andre says, the more "exotic" the examples, the less likely it is that users reading the HTML can display it anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10665>
_______________________________________

From report at bugs.python.org  Sat Apr 16 09:32:03 2011
From: report at bugs.python.org (kent)
Date: Sat, 16 Apr 2011 07:32:03 +0000
Subject: [issue11820] idle3 shell os.system swallows shell command output
In-Reply-To: <1302421540.99.0.957938249964.issue11820@psf.upfronthosting.co.za>
Message-ID: <1302939123.84.0.154005675414.issue11820@psf.upfronthosting.co.za>


kent <fuzzballz at comcast.net> added the comment:

I had kind of figured it might be something like this.  I ran the following code in the xterm interpreter:
>>> x=subprocess.call('ls')
bin      Documents  eclipse  local  Pictures   tmp     workspace
Desktop  Downloads  hamlib   Music  Templates  Videos
>>> print(x)
0
It does not capture the output.

----------
components: +Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11820>
_______________________________________

From report at bugs.python.org  Sat Apr 16 09:50:47 2011
From: report at bugs.python.org (kent)
Date: Sat, 16 Apr 2011 07:50:47 +0000
Subject: [issue11820] idle3 shell os.system swallows shell command output
In-Reply-To: <1302421540.99.0.957938249964.issue11820@psf.upfronthosting.co.za>
Message-ID: <1302940247.5.0.171593008291.issue11820@psf.upfronthosting.co.za>


kent <fuzzballz at comcast.net> added the comment:

The getoutput and getstatusoutput provide the expect output which can be captured

>>> x=subprocess.getoutput('ls')
>>> print(x)
hs_err_pid28274.log
LP4E-examples
mydir.pth
mydir.pth~
PP4E-Examples-1.2
ProgMan
Python_dir


Would it be a good thing to have the interpreter capture the sysout of all child processes automatically?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11820>
_______________________________________

From report at bugs.python.org  Sat Apr 16 13:46:52 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sat, 16 Apr 2011 11:46:52 +0000
Subject: [issue11806] Missing 2 hyphens in the docs
In-Reply-To: <1302338197.1.0.100311254016.issue11806@psf.upfronthosting.co.za>
Message-ID: <1302954412.21.0.303352463807.issue11806@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


Removed file: http://bugs.python.org/file21638/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11806>
_______________________________________

From report at bugs.python.org  Sat Apr 16 13:46:55 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sat, 16 Apr 2011 11:46:55 +0000
Subject: [issue11806] Missing 2 hyphens in the docs
In-Reply-To: <1302338197.1.0.100311254016.issue11806@psf.upfronthosting.co.za>
Message-ID: <1302954415.75.0.0285512573426.issue11806@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


Removed file: http://bugs.python.org/file21643/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11806>
_______________________________________

From report at bugs.python.org  Sat Apr 16 13:46:58 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sat, 16 Apr 2011 11:46:58 +0000
Subject: [issue11806] Missing 2 hyphens in the docs
In-Reply-To: <1302338197.1.0.100311254016.issue11806@psf.upfronthosting.co.za>
Message-ID: <1302954418.53.0.570065305022.issue11806@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


Removed file: http://bugs.python.org/file21648/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11806>
_______________________________________

From report at bugs.python.org  Sat Apr 16 13:47:01 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sat, 16 Apr 2011 11:47:01 +0000
Subject: [issue11806] Missing 2 hyphens in the docs
In-Reply-To: <1302338197.1.0.100311254016.issue11806@psf.upfronthosting.co.za>
Message-ID: <1302954421.38.0.686198345803.issue11806@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


Removed file: http://bugs.python.org/file21654/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11806>
_______________________________________

From report at bugs.python.org  Sat Apr 16 13:47:03 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sat, 16 Apr 2011 11:47:03 +0000
Subject: [issue11806] Missing 2 hyphens in the docs
In-Reply-To: <1302338197.1.0.100311254016.issue11806@psf.upfronthosting.co.za>
Message-ID: <1302954423.85.0.204504887501.issue11806@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


Removed file: http://bugs.python.org/file21664/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11806>
_______________________________________

From report at bugs.python.org  Sat Apr 16 13:54:05 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sat, 16 Apr 2011 11:54:05 +0000
Subject: [issue11855] urlretrieve --> urlretrieve()
In-Reply-To: <1302954844.99.0.142574002037.issue11855@psf.upfronthosting.co.za>
Message-ID: <1302954844.99.0.142574002037.issue11855@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

A typo in the docs was found here: http://docs.python.org/library/urllib.html#urllib.urlretrieve

Two instances of the word "urlretrieve" need to be "urlretrieve()", as other instances of it are, with that fancy color and a link-like look. You know what I mean. If you care, please fix this.

----------
assignee: docs at python
components: Documentation
messages: 133887
nosy: Retro, docs at python
priority: normal
severity: normal
status: open
title: urlretrieve --> urlretrieve()
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11855>
_______________________________________

From report at bugs.python.org  Sat Apr 16 14:05:53 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 16 Apr 2011 12:05:53 +0000
Subject: [issue11855] urlretrieve --> urlretrieve()
In-Reply-To: <1302954844.99.0.142574002037.issue11855@psf.upfronthosting.co.za>
Message-ID: <1302955553.19.0.656612116792.issue11855@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Agreed. Will fix

----------
keywords: +easy
nosy: +eli.bendersky
priority: normal -> low
resolution:  -> accepted
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11855>
_______________________________________

From report at bugs.python.org  Sat Apr 16 14:10:56 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Apr 2011 12:10:56 +0000
Subject: [issue11855] urlretrieve --> urlretrieve()
In-Reply-To: <1302954844.99.0.142574002037.issue11855@psf.upfronthosting.co.za>
Message-ID: <E1QB4L0-0002FM-7b@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d3e0bc155ca2 by Eli Bendersky in branch '2.7':
Issue #11855: Apply missing formatting for urlretrieve
http://hg.python.org/cpython/rev/d3e0bc155ca2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11855>
_______________________________________

From report at bugs.python.org  Sat Apr 16 14:18:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Apr 2011 12:18:22 +0000
Subject: [issue11855] urlretrieve --> urlretrieve()
In-Reply-To: <1302954844.99.0.142574002037.issue11855@psf.upfronthosting.co.za>
Message-ID: <E1QB4SC-0002hk-7G@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a6d9f9329070 by Eli Bendersky in branch '3.1':
Issue #11855: Apply missing formatting for urlretrieve
http://hg.python.org/cpython/rev/a6d9f9329070

New changeset 0f1199858714 by Eli Bendersky in branch '3.2':
Issue #11855: merge from 3.1
http://hg.python.org/cpython/rev/0f1199858714

New changeset c49c595e4214 by Eli Bendersky in branch 'default':
Issue #11855: merge from 3.2
http://hg.python.org/cpython/rev/c49c595e4214

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11855>
_______________________________________

From report at bugs.python.org  Sat Apr 16 14:19:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Apr 2011 12:19:22 +0000
Subject: [issue11856] Optimize parsing of JSON numbers
In-Reply-To: <1302956362.08.0.216789404235.issue11856@psf.upfronthosting.co.za>
Message-ID: <1302956362.08.0.216789404235.issue11856@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

In Python 3.x, parsing JSON numbers involve calling PyLong_FromUnicode or PyFloat_FromString with an unicode object. These functions are quite costly because they call PyUnicode_TransformDecimalToASCII(). But JSON numbers are always pure ASCII. This patch does the ASCII conversion ourselves.

Small benchmark with integers:
./python -m timeit -s \
  "from json import loads, dumps; d=list(i for i in range(1000)); s=dumps(d)" \
  "loads(s)"

-> without patch: 705 usec per loop
-> with patch: 103 usec per loop

----------
components: Library (Lib)
files: jsonnumbers.patch
keywords: patch
messages: 133891
nosy: mark.dickinson, pitrou, rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: Optimize parsing of JSON numbers
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file21681/jsonnumbers.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11856>
_______________________________________

From report at bugs.python.org  Sat Apr 16 14:19:50 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 16 Apr 2011 12:19:50 +0000
Subject: [issue11855] urlretrieve --> urlretrieve()
In-Reply-To: <1302954844.99.0.142574002037.issue11855@psf.upfronthosting.co.za>
Message-ID: <1302956390.79.0.367011482493.issue11855@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
resolution: accepted -> fixed
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11855>
_______________________________________

From report at bugs.python.org  Sat Apr 16 14:20:02 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 16 Apr 2011 12:20:02 +0000
Subject: [issue11856] Optimize parsing of JSON numbers
In-Reply-To: <1302956362.08.0.216789404235.issue11856@psf.upfronthosting.co.za>
Message-ID: <1302956402.25.0.414584133766.issue11856@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/issue11856>
_______________________________________

From report at bugs.python.org  Sat Apr 16 16:55:28 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 16 Apr 2011 14:55:28 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1302965728.97.0.514651707441.issue11277@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> So i finally did some tests using Nadeem's code snippet
> from msg133677.  The largest top(1) i ever got was
>    30477  python3      2.7       00:09.77 1    0    18    77    912M+  240K
> but the system is unusable then.

The code I posted was only intended to run on machines with at least
4GB of free memory. The precisionbigmemtest decorator should cause it to
be skipped on machines with less RAM.

> Except for all this i don't understand this thread.
> Isn't that bot the one for which haypo has noticed those
> random failures???

The current status of this issue (as I understand it) is:
* test_zlib's test_big_buffer() is failing sporadically on the AMD64
   Snow Leopard buildbot (http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%203.x/)
* The cause seems to be a bug in OS X's handling of mmap()'d files, not a
   problem with the Python code.
* Antoine has proposed skipping this test on OS X as a workaround, and
   no-one has objected to this.

I don't think it is necessary to further investigate the behaviour of
Snow Leopard's mmap() - we know that it's broken, and we have a fix.

At the moment, we need someone to actually write and commit the fix.
I would do it myself, but I'm hesitant to commit code without testing it,
and don't have access to a Mac system.

----------
stage: committed/rejected -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Sat Apr 16 17:33:27 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sat, 16 Apr 2011 15:33:27 +0000
Subject: [issue11857] Hyphenate the argparse.rst file, patch added
In-Reply-To: <1302968007.13.0.0484662149603.issue11857@psf.upfronthosting.co.za>
Message-ID: <1302968007.13.0.0484662149603.issue11857@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

Please apply this patch. And fix the occurences where you think the word "command line" acts as a noun.

----------
assignee: docs at python
components: Documentation
files: argparse.patch
keywords: patch
messages: 133893
nosy: Retro, docs at python, georg.brandl
priority: normal
severity: normal
status: open
title: Hyphenate the argparse.rst file, patch added
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file21682/argparse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11857>
_______________________________________

From report at bugs.python.org  Sat Apr 16 18:13:54 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 16 Apr 2011 16:13:54 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <20110416161340.GA52575@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Yet another bug of Mac OS X: it sometimes creates messed up sparse
regions:

14:00 ~/tmp/test $ ~/src/cpython/python.exe test_mmap.py 
..
14:01 ~/tmp/test $ zsum32 py-mmap-testfile 
Adler-32 <db8d743c> CRC-32 <78ebae7a> -- py-mmap-testfile
14:03 ~/tmp/test $ ./test_mmap
Size 4294971396/0x100001004: open. lseek. write. fsync. fstat. mmap. [0]. [s.st_size-4]. munmap.
14:04 ~/tmp/test $ zsum32 c-mmap-testfile 
Adler-32 <14b9018b> CRC-32 <c6e340bf> -- c-mmap-testfile
14:08 ~/tmp/test $ hexdump -C -s 4000 -n 128 c-mmap-testfile 
00000fa0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001020
14:08 ~/tmp/test $ hexdump -C -s 4000 -n 128 py-mmap-testfile 
00000fa0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001000  db db db db db db db db  db db db db db db db db  |................|
*
00001020

Conclusions:

1. It is unwise to create memory regions GT
       hw.usermem=1651843072   // 2
   and extremely unwise to do so for regions GT
       hw.user_wire_limit=1811939328   // 2

   Exceeding this limit and Mac OS X effectively enters an endless
   loop which may cause so much paging activity that the system is
   almost locked.

   (P.S.: if you invoke diff(1) on two extremely large files you
   may produce an unkillable process which survives SIGKILL and
   "Activity Monitor" initiated "Force Quit"s; not to talk about
   termination of the parent shell.)

2. Mac OS X does not reliably produce sparse files.
   If the attached files 11277.mmap-2.c and 11277.mmap-2.py are
   modified not to unlink(2) the produced files (not hard for the
   Python version), then:

       cmp --verbose py-mmap-testfile c-mmap-testfile | wc
       95832  287496 1820808

3. For at least sparse files the VMS of Mac OS X is unable to
   create an accessible mmap(2)ing if the size of the mapping is
   in the inclusive range
       UINT32_MAX+1 .. UINT32_MAX + PAGESIZE (== 4096)
   and the file has been written to.

   Closing the file and reopening it will make the mapping not
   only succeed but also accessible (talking about Python).

4. If you chose a size which does not fail immediately, then
   if you don't reopen but only instrument mmapmodule.c then
       subscript self=0x100771350
           CALCULATED SUBSCRIPT 4095
       subscript self=0x100771350
           CALCULATED SUBSCRIPT 4096
       Bus Error
   Thus, accessing the first byte of the second page causes
   Python to fail with SIGBUS, *even* if you explicitely fsync()
   the fd in new_mmap_object(); fstat(2) code runs anyway.
   The C version does *not* have this problem, here fsync() alone
   does the magic.

5. Python's C code: mumble mumble mumble.
   That really needs to be said at least.

6. The error is in mmapmodule.c, function new_mmap_object().
   It is the call to mmap(2).
   Wether i dup(2) or not.  Whatever i do.
   Even if i reduce new_mmap_object() to the running code from
   11277.mmap-2.c:

if (fd != -1 && fstat(fd, &st) == 0 && S_ISREG(st.st_mode) &&
    map_size == 0)
    map_size = st.st_size;
fprintf(stderr,"before mmap(2): size=%lu,fd=%d\n",(size_t)map_size, fd);
{void *addr = mmap(NULL, (size_t)map_size, PROT_READ, MAP_SHARED, fd, 0);
fprintf(stderr, "after mmap(2): size=%lu,fd=%d got address=%p\n",(size_t)map_size, fd, addr);
{size_t j;
for (j = 0; j < map_size; ++j) {
    char x; 
    if (j % 1024 == 0)
        fprintf(stderr, "INDEX %lu\n",j);
    x = ((volatile char*)addr)[j]
}
fprintf(stderr, "PASSED ALL INDICIES\n");
exit(1);
}
}

...

17:41 ~/tmp/test $ ~/src/cpython/python.exe 11277.mmap-2.py
DESCRIPTOR FLAGS WILL BE 0
DESCRIPTOR FLAGS WILL BE 0
Start: time.struct_time(tm_year=2011, tm_mon=4, tm_mday=16, tm_hour=15, tm_min=41, tm_sec=22, tm_wday=5, tm_yday=106, tm_isdst=0)
Testing file size 4294971400: DESCRIPTOR FLAGS WILL BE 1538
new_mmap_object
_GetMapSize o=0x1001f5d10
before mmap(2): size=4294971396,fd=3
after mmap(2): size=4294971396,fd=3 got address=0x101140000
INDEX 0
INDEX 1024
INDEX 2048
INDEX 3072
INDEX 4096
Bus error

7. Note the C version also works if i prepend many malloc(3)
   calls.

8. I have no idea what Python does here.
   Maybe it's ld(1) and dynamic module-loading related.
   Maybe Apples VM gets confused about memory regions if several
   conditions come together.  I have no idea of what Python does
   along it's way to initialize itself.  It's a lot.

   And i'm someone who did not even look into Doc/c-api/ at all
   yet except for a
        grep -Fr tp_as_buf Doc/
   today (the first version of the iterate-cpl-buffer used buffer
   interface).  So please explain any comments you might give.
   Maybe i'll write a patch to add tests to test_mmap.py.
   Beside that i'm out of this.

9. Maybe it's really better to simply skip this on Mac OS X.

Z. ... and maybe someone with a name should ask someone with
   a name-name-name to ask those californian ocean surfers to fix
   at least some of the OS bugs?  My bug reports are not even
   adhered by Opera, even if i attach reproducable scripts or
   URLs...

----------
Added file: http://bugs.python.org/file21683/11277.mmap-2.c
Added file: http://bugs.python.org/file21684/11277.mmap-2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________
-------------- next part --------------

#include <errno.h>
#include <signal.h>
#include <stdio.h>
#include <string.h>

#include <fcntl.h>
#include <unistd.h>

#include <sys/mman.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/uio.h>

#define PATH        "c-mmap-testfile"
#define PAGESIZE    4096

static void sighdl(int);

static void
sighdl(int signo)
{
    const char errmsg[] = "\nSignal occurred, cleaning up\n";
    (void)signo;
    (void)signal(SIGSEGV, SIG_DFL);
    (void)signal(SIGBUS, SIG_DFL);
    write(2, errmsg, sizeof(errmsg)-1);
    (void)unlink(PATH);
    return;
}

int
main(void) {
    int fd, estat = 0;
    void *addr;
    size_t i;
    auto struct stat s;
    /* *Final* sizes (string written after lseek(2): "abcd") */
    const size_t *ct, tests[] = {
        /* Tested good */
        //0x100000000 - PAGESIZE - 5,
        //0x100000000 - 4,
        //0x100000000 - 3,
        //0x100000000 - 1,
        0x100000000 + PAGESIZE + 4,
        //0x100000000 + PAGESIZE + 5,
        /* Tested bad */
        //0x100000000,
        //0x100000000 + PAGESIZE,
        //0x100000000 + PAGESIZE + 1,
        //0x100000000 + PAGESIZE + 3,
        0
    };

    if (signal(SIGSEGV, &sighdl) == SIG_ERR)
        goto jerror;
    if (signal(SIGBUS, &sighdl) == SIG_ERR)
        goto jerror;

    for (ct = tests; *ct != 0; ++ct) {
        fprintf(stderr, "Size %lu/0x%lX: open", *ct, *ct);
        fd = open(PATH, O_RDWR|O_TRUNC|O_CREAT, 0666);
        if (fd < 0)
            goto jerror;
        fprintf(stderr, ". ");

        fprintf(stderr, "lseek");
        if (lseek(fd, *ct-4, SEEK_END) < 0)
            goto jerror;
        fprintf(stderr, ". ");

        fprintf(stderr, "write");
        if (write(fd, "abcd", 4) != 4)
            goto jerror;
        fprintf(stderr, ". ");

        fprintf(stderr, "fsync");
        if (fsync(fd) != 0)
            goto jerror;
        fprintf(stderr, ". ");

        fprintf(stderr, "fstat");
        if (fstat(fd, &s) != 0)
            goto jerror;
        fprintf(stderr, ". ");

        if (*ct != (size_t)s.st_size) {
            fprintf(stderr, "fstat size mismatch: %lu is not %lu\n",
                    (size_t)s.st_size, *ct);
            continue;
        }

        fprintf(stderr, "mmap");
        addr = mmap(NULL, s.st_size, PROT_READ, MAP_SHARED, fd, 0);
        if (addr == NULL)
            goto jerror;
        fprintf(stderr, ". ");

        (void)close(fd); /* Can also be left off, doesn't matter */

        fprintf(stderr, "[0]");
        if (((char*)addr)[0] != '\0')
            goto jerror;
        fprintf(stderr, ". ");

        fprintf(stderr, "[s.st_size-4]");
        if (((char*)addr)[s.st_size-4] != 'a')
            goto jerror;
        fprintf(stderr, ". ");

        fprintf(stderr, "[ALL IN ORDER]");
        for (i = 0; i < (size_t)s.st_size; ++i) {
            char x = ((volatile char*)addr)[0];
            (void)x;
        }
        fprintf(stderr, ". ");

        fprintf(stderr, "munmap");
        if (munmap(addr, s.st_size) != 0)
            goto jerror;
        fprintf(stderr, ".");

        fprintf(stderr, "\n");
    }

jleave:
    (void)unlink(PATH);
    return estat;

jerror:
    fprintf(stderr, "\n%s\n", strerror(errno));
    estat = 1;
    goto jleave;
}
-------------- next part --------------
import os,sys,time,mmap,zlib

PAGESIZE = 4096
SIZES = ((2**32) + PAGESIZE + 4, 0)

FILE = 'py-mmap-testfile'

print('Start:', time.gmtime())
for i in SIZES:
    if i == 0:
        break
    print('Testing file size ', str(i), ': ', sep='', end='')
    sys.stdout.flush()
    with open(FILE, "wb+") as f:
        f.seek(i-4)
        f.write(b'abcd')
        f.flush()
        sb = os.stat(FILE) 
        if sb.st_size != i:
            print('size failure:', sb.st_size, ' != ', i, sep='', end='')
            sys.stdout.flush()
        mem = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
        if mem[0] != ord('\0'):
            print('offset 0 failed: ', ord(mem[0]), ' ', end='', sep='')
        else:
            print('offset 0 ok ', end='', sep='')
        sys.stdout.flush()
        if mem[i-4] != ord('a'):
            print('offset i-4 failed: ', ord(mem[i-4]), ' ', end='', sep='')
        else:
            print('offset i-4 ok ', end='', sep='')
        print('[ALL IN ORDER] ', sep='', end='')
        sys.stdout.flush()
        for j in range(0, sb.st_size):
            y = mem[j]
        print('ok')
        sys.stdout.flush()
    os.unlink(FILE)
print('End:', time.gmtime())

From report at bugs.python.org  Sat Apr 16 18:17:27 2011
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Sat, 16 Apr 2011 16:17:27 +0000
Subject: [issue11155] multiprocessing.Queue's put() signature differs from docs
In-Reply-To: <1297211747.04.0.707896670759.issue11155@psf.upfronthosting.co.za>
Message-ID: <1302970647.16.0.592545971092.issue11155@psf.upfronthosting.co.za>


Westley Mart?nez <anikom15 at gmail.com> added the comment:

Can this patch be commited?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11155>
_______________________________________

From report at bugs.python.org  Sat Apr 16 18:19:58 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 16 Apr 2011 16:19:58 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1302965728.97.0.514651707441.issue11277@psf.upfronthosting.co.za>
Message-ID: <20110416161947.GA56075@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

On Sat, Apr 16, 2011 at 02:55:29PM +0000, Nadeem Vawda wrote:
> I don't think it is necessary to further investigate the behaviour of
> Snow Leopard's mmap() - we know that it's broken, and we have a fix.
> 
> At the moment, we need someone to actually write and commit the fix.
> I would do it myself, but I'm hesitant to commit code without testing it,
> and don't have access to a Mac system.

I see.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Sat Apr 16 18:48:34 2011
From: report at bugs.python.org (Pink)
Date: Sat, 16 Apr 2011 16:48:34 +0000
Subject: [issue11858] configparser.ExtendedInterpolation and section case
In-Reply-To: <1302972514.64.0.403074363027.issue11858@psf.upfronthosting.co.za>
Message-ID: <1302972514.64.0.403074363027.issue11858@psf.upfronthosting.co.za>


New submission from Pink <ciasoms at gmail.com>:

configparser.ExtendedInterpolation in Python 3.2 has a bug that it will convert the section name in the interpolation to lowercase, and lead to an exception of NoSectionError if the section name has letters in uppercase.

In fact it just cannot pass the test of the second example in the doc (http://docs.python.org/py3k/library/configparser.html#configparser.ExtendedInterpolation).

The attached patch should fix it.

----------
components: Library (Lib)
files: configparser.diff
keywords: patch
messages: 133897
nosy: ciasoms, lukasz.langa
priority: normal
severity: normal
status: open
title: configparser.ExtendedInterpolation and section case
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file21685/configparser.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11858>
_______________________________________

From report at bugs.python.org  Sat Apr 16 18:49:16 2011
From: report at bugs.python.org (Roger Binns)
Date: Sat, 16 Apr 2011 16:49:16 +0000
Subject: [issue11851] Flushing the standard input causes an error
In-Reply-To: <1302875100.13.0.0605513663919.issue11851@psf.upfronthosting.co.za>
Message-ID: <1302972556.05.0.237247104129.issue11851@psf.upfronthosting.co.za>


Roger Binns <python at rogerbinns.com> added the comment:

I'm the APSW author.  The reason why this apparent nonsense is done is due to using readline and completion.  That requires being able to write to standard input when it is a terminal - something that Windows and Linux are happy to do.

In any event I'll put a try/catch around this and ignore.

----------
nosy: +rogerbinns

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11851>
_______________________________________

From report at bugs.python.org  Sat Apr 16 19:18:16 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 16 Apr 2011 17:18:16 +0000
Subject: [issue11854] __or__ et al instantiate subclass of set without calling
	__init__
In-Reply-To: <1302931795.31.0.443472549499.issue11854@psf.upfronthosting.co.za>
Message-ID: <1302974296.66.0.188814807899.issue11854@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <stutzbach at google.com>:


----------
nosy: +stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11854>
_______________________________________

From report at bugs.python.org  Sat Apr 16 19:30:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Apr 2011 17:30:27 +0000
Subject: [issue11856] Optimize parsing of JSON numbers
In-Reply-To: <1302956362.08.0.216789404235.issue11856@psf.upfronthosting.co.za>
Message-ID: <1302975027.79.0.913077654396.issue11856@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Cleaned up patch.

----------
Added file: http://bugs.python.org/file21686/jsonnumbers2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11856>
_______________________________________

From report at bugs.python.org  Sat Apr 16 20:00:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Apr 2011 18:00:54 +0000
Subject: [issue11005] Assertion error on RLock._acquire_restore
In-Reply-To: <1302646858.37.0.245857915462.issue11005@psf.upfronthosting.co.za>
Message-ID: <1302976847.3490.58.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Here is a patch: Antoine, would you like to review it?
> 
> ----------
> keywords: +patch
> nosy: +pitrou
> Added file: http://bugs.python.org/file21636/rlock_release_save.patch

Well, it looks ok to me. Is the assert still needed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11005>
_______________________________________

From report at bugs.python.org  Sat Apr 16 20:59:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Apr 2011 18:59:46 +0000
Subject: [issue11790] transient failure in
	test_multiprocessing.WithProcessesTestCondition
In-Reply-To: <1302131075.81.0.79285380131.issue11790@psf.upfronthosting.co.za>
Message-ID: <1302980386.74.0.770709148845.issue11790@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Indeed, it just seems that the sleep period is sometimes too low. Will commit a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11790>
_______________________________________

From report at bugs.python.org  Sat Apr 16 21:03:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Apr 2011 19:03:08 +0000
Subject: [issue11790] transient failure in
	test_multiprocessing.WithProcessesTestCondition
In-Reply-To: <1302131075.81.0.79285380131.issue11790@psf.upfronthosting.co.za>
Message-ID: <E1QBAlu-0001t1-Oy@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 88f1907fe312 by Antoine Pitrou in branch '3.2':
Issue #11790: Fix sporadic failures in test_multiprocessing.WithProcessesTestCondition.
http://hg.python.org/cpython/rev/88f1907fe312

New changeset 0ecfa2ce6561 by Antoine Pitrou in branch 'default':
Issue #11790: Fix sporadic failures in test_multiprocessing.WithProcessesTestCondition.
http://hg.python.org/cpython/rev/0ecfa2ce6561

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11790>
_______________________________________

From report at bugs.python.org  Sat Apr 16 21:03:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Apr 2011 19:03:59 +0000
Subject: [issue11790] transient failure in
	test_multiprocessing.WithProcessesTestCondition
In-Reply-To: <1302131075.81.0.79285380131.issue11790@psf.upfronthosting.co.za>
Message-ID: <1302980639.12.0.153222887664.issue11790@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11790>
_______________________________________

From report at bugs.python.org  Sat Apr 16 21:16:55 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sat, 16 Apr 2011 19:16:55 +0000
Subject: [issue11857] Hyphenate the argparse.rst file, patch added
In-Reply-To: <1302968007.13.0.0484662149603.issue11857@psf.upfronthosting.co.za>
Message-ID: <1302981415.57.0.299329841863.issue11857@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


Removed file: http://bugs.python.org/file21682/argparse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11857>
_______________________________________

From report at bugs.python.org  Sat Apr 16 21:21:40 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Sat, 16 Apr 2011 19:21:40 +0000
Subject: [issue11854] __or__ et al instantiate subclass of set without calling
	__init__
In-Reply-To: <1302931795.31.0.443472549499.issue11854@psf.upfronthosting.co.za>
Message-ID: <1302981700.52.0.76413378193.issue11854@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

Python 2.7.1 (r271:86832, Nov 27 2010, 17:19:03) [MSC v.1500 64 bit (AMD64)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class SetSub(set):
...     def __init__(self, *args, **kwargs):
...             print 'foo'
...             set.__init__(self, *args, **kwargs)
...
>>> a = SetSub([2,7])
foo
>>> b = set([1,7])
>>> a ^ b
SetSub([1, 2])


Python 3.2 (r32:88445, Feb 20 2011, 21:30:00) [MSC v.1500 64 bit (AMD64)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> class SetSub(set):
...     def __init__(self, *args, **kwargs):
...             print('foo')
...             set.__init__(self, *args, **kwargs)
...
>>> a = SetSub([2,7])
foo
>>> b = set([1,7])
>>> a ^ b
{1, 2}

----------
nosy: +santa4nt
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11854>
_______________________________________

From report at bugs.python.org  Sat Apr 16 21:22:48 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Sat, 16 Apr 2011 19:22:48 +0000
Subject: [issue11854] __or__ et al instantiate subclass of set without calling
	__init__
In-Reply-To: <1302931795.31.0.443472549499.issue11854@psf.upfronthosting.co.za>
Message-ID: <1302981768.37.0.172106620275.issue11854@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
versions:  -Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11854>
_______________________________________

From report at bugs.python.org  Sat Apr 16 21:44:24 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sat, 16 Apr 2011 19:44:24 +0000
Subject: [issue11857] Hyphenate the argparse.rst file, patch added
In-Reply-To: <1302968007.13.0.0484662149603.issue11857@psf.upfronthosting.co.za>
Message-ID: <1302983064.88.0.579069389658.issue11857@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Added the new and improved patch. Now it is perfect. Please apply it.

----------
Added file: http://bugs.python.org/file21687/argparse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11857>
_______________________________________

From report at bugs.python.org  Sat Apr 16 21:59:28 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 16 Apr 2011 19:59:28 +0000
Subject: [issue11701] email.parser.BytesParser().parse() closes file argument
In-Reply-To: <1301315420.28.0.123524956156.issue11701@psf.upfronthosting.co.za>
Message-ID: <1302983968.72.0.136565517694.issue11701@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11701>
_______________________________________

From report at bugs.python.org  Sat Apr 16 22:00:37 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Sat, 16 Apr 2011 20:00:37 +0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and
	tuple	api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1302984037.31.0.466554002992.issue1820@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1820>
_______________________________________

From report at bugs.python.org  Sat Apr 16 22:16:06 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 16 Apr 2011 20:16:06 +0000
Subject: [issue11857] Hyphenate the argparse.rst file, patch added
In-Reply-To: <1302968007.13.0.0484662149603.issue11857@psf.upfronthosting.co.za>
Message-ID: <1302984966.68.0.668709365935.issue11857@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Done in cc65cf9a9ce5, c33596e6f723, and fcce2f49ef6d. Thanks for the patch.

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11857>
_______________________________________

From report at bugs.python.org  Sat Apr 16 22:17:09 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 16 Apr 2011 20:17:09 +0000
Subject: [issue11855] urlretrieve --> urlretrieve()
In-Reply-To: <1302954844.99.0.142574002037.issue11855@psf.upfronthosting.co.za>
Message-ID: <1302985029.99.0.459203772855.issue11855@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> committed/rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11855>
_______________________________________

From report at bugs.python.org  Sat Apr 16 22:17:30 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 16 Apr 2011 20:17:30 +0000
Subject: [issue11700] mailbox.py proxy updates
In-Reply-To: <1301315190.34.0.276151285444.issue11700@psf.upfronthosting.co.za>
Message-ID: <1302985050.59.0.848109362051.issue11700@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here's a patch that fixes the reported bug (calling close twice fails with an AttributeError) the simple way.

Note that there was actually a test for the buggy behavior, which is rather odd considering that there is also a 'closed' method that would fail similarly if close was ever called.  (The only use for the existing 'closed' method that I can see is to see if somebody else closed the file out from under the ProxyFile, a 'feature' that seems of dubious utility.)

It seems clear to me that calling close more than once should be legal, so I fixed the test.  closed will still report if the underlying file has been closed out from under ProxyFile.

Steffen, I still don't understand what you are trying to achieve with your patches.  I plan to close this issue by applying my patch.

----------
assignee:  -> r.david.murray
Added file: http://bugs.python.org/file21688/mailbox_close_twice.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11700>
_______________________________________

From report at bugs.python.org  Sun Apr 17 00:33:00 2011
From: report at bugs.python.org (Wojciech Wojtyniak)
Date: Sat, 16 Apr 2011 22:33:00 +0000
Subject: =?utf-8?q?=5Bissue10946=5D_bdist_doesn=E2=80=99t_pass_--skip-build_on_to_?=
	=?utf-8?q?subcommands?=
In-Reply-To: <1295451169.68.0.9980803941.issue10946@psf.upfronthosting.co.za>
Message-ID: <1302993180.51.0.363669842101.issue10946@psf.upfronthosting.co.za>


Wojciech Wojtyniak <radious at gmail.com> added the comment:

Could you please at least describe the test that you mentioned (link doesn't work). I added line that passes skip_build from bdist.py to its subcommands and it worked for me (at least for simple cases) - base.py is not called.

If bdist wouldn't call any install_* in other way then via bdist_*, then we could use set_undefined_options in the last ones, but I'm not sure if it's safe. (If it is, I can provide appropriate patch.) 

Using set_undefined_options in install_* is definitely not safe, because it fails if parent process has not set skip_build. Also skip_build has to be set to None in install_* (set_... needs that to work) which obviously breaks it. Actually bdist_* sets skip_build like in my patch.

Patch attached.

Anyway test_skip_build() is still broken and needs a fix.

----------
keywords: +patch
nosy: +radious
Added file: http://bugs.python.org/file21689/skip_build.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10946>
_______________________________________

From report at bugs.python.org  Sun Apr 17 00:57:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Apr 2011 22:57:12 +0000
Subject: [issue11859] test_interrupted_write_text() of test_io failed of
	Python 3.3 on FreeBSD 7.2
In-Reply-To: <1302994631.38.0.484484359613.issue11859@psf.upfronthosting.co.za>
Message-ID: <1302994631.38.0.484484359613.issue11859@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

test_interrupted_write_text() of test_io failed of Python 3.3 on FreeBSD 7.2:
-----------------------------------------------
[250/354] test_io
Exception in thread Thread-1316:
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 735, in _bootstrap_inner
    self.run()
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 688, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_io.py", line 2630, in _read
    s = os.read(r, 1)
OSError: [Errno 4] Interrupted system call

Timeout (1:00:00)!
Thread 0x28401040:
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_io.py", line 2651 in check_interrupted_write
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_io.py", line 2672 in test_interrupted_write_text
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 442 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 494 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1078 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1166 in _run_suite
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1192 in run_unittest
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_io.py", line 2845 in test_main
  File "./Lib/test/regrtest.py", line 1041 in runtest_inner
  File "./Lib/test/regrtest.py", line 835 in runtest
  File "./Lib/test/regrtest.py", line 659 in main
  File "./Lib/test/regrtest.py", line 1619 in <module>
*** Error code 1

Stop in /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build.
program finished with exit code 1
elapsedTime=8703.824572
-----------------------------------------------
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%207.2%203.x/builds/1695/steps/test/logs/stdio

----------
components: Tests
messages: 133908
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: test_interrupted_write_text() of test_io failed of Python 3.3 on FreeBSD 7.2
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11859>
_______________________________________

From report at bugs.python.org  Sun Apr 17 01:17:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Apr 2011 23:17:28 +0000
Subject: [issue11859] test_interrupted_write_text() of test_io failed of
	Python 3.3 on FreeBSD 7.2
In-Reply-To: <1302994631.38.0.484484359613.issue11859@psf.upfronthosting.co.za>
Message-ID: <1302995848.52.0.313058287904.issue11859@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I already read somewhere that on FreeBSD, any thread can receive a signal, not only the main thread. I suppose that it should be the same on Linux, but Linux tries maybe to send a signal to the main thread if the main thread and other threads are calling a system call.

In this case, "_read" thread gets the SIGARLM signal and so its os.read() system call is interrupted. It means that os.read() is blocked at least one second, whereas wio.write() is supposed to send data to unblock _read() thread.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11859>
_______________________________________

From report at bugs.python.org  Sun Apr 17 01:23:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Apr 2011 23:23:54 +0000
Subject: [issue11859] test_interrupted_write_text() of test_io failed of
	Python 3.3 on FreeBSD 7.2
In-Reply-To: <1302994631.38.0.484484359613.issue11859@psf.upfronthosting.co.za>
Message-ID: <1302996234.67.0.791286078375.issue11859@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

One solution to fix this problem is to use pthread_sigmask() on the _read() thread to not handle SIGARLM. For example, the faulthandler uses the following code to not handle any thread in its timeout thread:

#ifdef HAVE_PTHREAD_H
    sigset_t set;

    /* we don't want to receive any signal */
    sigfillset(&set);
#if defined(HAVE_PTHREAD_SIGMASK) && !defined(HAVE_BROKEN_PTHREAD_SIGMASK)
    pthread_sigmask(SIG_SETMASK, &set, NULL);
#else
    sigprocmask(SIG_SETMASK, &set, NULL);
#endif
#endif

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11859>
_______________________________________

From report at bugs.python.org  Sun Apr 17 01:37:54 2011
From: report at bugs.python.org (Robert Burke)
Date: Sat, 16 Apr 2011 23:37:54 +0000
Subject: [issue11854] __or__ et al instantiate subclass of set without calling
	__init__
In-Reply-To: <1302931795.31.0.443472549499.issue11854@psf.upfronthosting.co.za>
Message-ID: <1302997074.6.0.177985191365.issue11854@psf.upfronthosting.co.za>


Robert Burke <sharpobject at gmail.com> added the comment:

I've only observed this in 2.6.  Does 2.6 not belong in the bug's versions list if 2.7 is also affected?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11854>
_______________________________________

From report at bugs.python.org  Sun Apr 17 01:44:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Apr 2011 23:44:19 +0000
Subject: [issue11779] test_mmap timeout (30 min) on "AMD64 Snow Leopard 3.x"
	buildbot
In-Reply-To: <1302076762.26.0.815715887004.issue11779@psf.upfronthosting.co.za>
Message-ID: <1302997459.66.0.0650009025897.issue11779@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Let's close this issue. I will reopen it if a timeout of 60 min was not the right choice to workaround this failure.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11779>
_______________________________________

From report at bugs.python.org  Sun Apr 17 02:12:06 2011
From: report at bugs.python.org (Hans Lellelid)
Date: Sun, 17 Apr 2011 00:12:06 +0000
Subject: [issue9631] Python 2.7 installation issue for Linux gcc-4.1.0-3
	(Fedora Core 5?)
In-Reply-To: <1282108953.92.0.943632360126.issue9631@psf.upfronthosting.co.za>
Message-ID: <1302999126.21.0.500267441828.issue9631@psf.upfronthosting.co.za>


Hans Lellelid <hans at velum.net> added the comment:

I'm having apparently the same issue when attempting to build an RPM (based on EPEL 2.6.5 SPEC) on CentOS 5.5 i386.

A straight configure/make/make install will work fine, but when editing Modules/Setup.dist to enabled *shared* (and then uncommenting the modules that I want to enable), and passing  --enable-shared to configure, I now get the following error during make-install phase:

PYTHONPATH=/var/tmp/python27-2.7.1-1.wt_el5-root-hans//usr/lib/python2.7  LD_LIBRARY_PATH=/home/hans/rpm/python27/Python-2.7.1: \
                ./python -Wi -tt /var/tmp/python27-2.7.1-1.wt_el5-root-hans//usr/lib/python2.7/compileall.py \
                -d /usr/lib/python2.7 -f \
                -x 'bad_coding|badsyntax|site-packages|lib2to3/tests/data' \
                /var/tmp/python27-2.7.1-1.wt_el5-root-hans//usr/lib/python2.7
Traceback (most recent call last):
  File "/var/tmp/python27-2.7.1-1.wt_el5-root-hans//usr/lib/python2.7/compileall.py", line 17, in <module>
    import struct
  File "/var/tmp/python27-2.7.1-1.wt_el5-root-hans/usr/lib/python2.7/struct.py", line 1, in <module>
    from _struct import *
ImportError: No module named _struct

I have cleaned out and rebuilt this many times.  I'm going to continue digging to see if I can figure out how to get the the .so files in the right place (or put the right dir on the path).  I'm also curious what changed from version 2.6 in this regard (and hopefully I'll figure it out with some more work).

----------
nosy: +hozn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9631>
_______________________________________

From report at bugs.python.org  Sun Apr 17 02:13:55 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 17 Apr 2011 00:13:55 +0000
Subject: [issue9041] raised exception is misleading
In-Reply-To: <1277123013.52.0.887079191328.issue9041@psf.upfronthosting.co.za>
Message-ID: <1302999235.72.0.0674924059336.issue9041@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

This problem still occurs in the main development branch.  I think the 
'PyErr_ExceptionMatches' check that Pauli suggested will work.  The same 
problem exist for 'c_float', 'c_double', and 'c_longdouble'.

Attached is a patch that fixes the issue and includes covering tests.
Tested on OS X 10.6.5.

----------
assignee: theller -> 
keywords: +patch
nosy: +amaury.forgeotdarc, belopolsky, meador.inge -theller
stage:  -> patch review
versions: +Python 3.3 -Python 2.6
Added file: http://bugs.python.org/file21690/issue9041.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9041>
_______________________________________

From report at bugs.python.org  Sun Apr 17 02:45:55 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 17 Apr 2011 00:45:55 +0000
Subject: [issue9651] ctypes crash when writing zerolength string buffer to file
In-Reply-To: <1282324201.94.0.528743574069.issue9651@psf.upfronthosting.co.za>
Message-ID: <1303001155.37.0.569373426645.issue9651@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

This crash still occurs in the main development branch and Amaury's patch
still fixes the problem.  I verified that all tests pass on OS X 10.6.5.
It should be OK to commit.

----------
assignee: theller -> 
nosy: +meador.inge -theller
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9651>
_______________________________________

From report at bugs.python.org  Sun Apr 17 03:53:24 2011
From: report at bugs.python.org (Mike Kamermans)
Date: Sun, 17 Apr 2011 01:53:24 +0000
Subject: [issue11860] reference 2.3 has text that runs past the page
In-Reply-To: <1303005204.18.0.459182918365.issue11860@psf.upfronthosting.co.za>
Message-ID: <1303005204.18.0.459182918365.issue11860@psf.upfronthosting.co.za>


New submission from Mike Kamermans <nihongo at gmail.com>:

page 8 for the python 3.2 refernce document ("identifiers and keywords") has text that runs way past the page. This document (and probably every other document) should be run through LaTeX again with draft, to find all instances where text doesn't fit on the page, so that this can be fixed.

----------
assignee: docs at python
components: Documentation
messages: 133916
nosy: Mike.Kamermans, docs at python
priority: normal
severity: normal
status: open
title: reference 2.3 has text that runs past the page
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11860>
_______________________________________

From report at bugs.python.org  Sun Apr 17 04:33:33 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 Apr 2011 02:33:33 +0000
Subject: [issue11854] __or__ et al instantiate subclass of set without calling
	__init__
In-Reply-To: <1302931795.31.0.443472549499.issue11854@psf.upfronthosting.co.za>
Message-ID: <1303007613.44.0.672070298437.issue11854@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

2.6 is closed for anything except security patches at this point.

2.7 is only open for flat-out bugs, not API changes.  So, we might be able to add code that could call the __init__ method (if it exists) whenever a new set is created, but we couldn't change whether __or__ returns a new set or frozenset instead of one of its subtypes.  Existing, working code may reasonably rely on the current behavior of returning the subtype (FWIW, this also matches what was done in the original sets.py).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11854>
_______________________________________

From report at bugs.python.org  Sun Apr 17 05:14:44 2011
From: report at bugs.python.org (Hans Lellelid)
Date: Sun, 17 Apr 2011 03:14:44 +0000
Subject: [issue9631] Python 2.7 installation issue for Linux gcc-4.1.0-3
	(Fedora Core 5?)
In-Reply-To: <1282108953.92.0.943632360126.issue9631@psf.upfronthosting.co.za>
Message-ID: <1303010084.98.0.228096435392.issue9631@psf.upfronthosting.co.za>


Hans Lellelid <hans at velum.net> added the comment:

Ok, I think I have tracked down the problem to a change that happened in site.py.  In comparing against a build that worked fine for Python 2.6.5, I noticed that the Modules subdir (which contains the shared .so files) was present on the sys.path for Python 2.6 but not for 2.7.  Digging deeper let me to the site.py module.  In Python 2.7 the behavior was changed so that the Modules path element was removed from sys.path. 

This is probably best explained by the patch I applied to revert to 2.6.x behavior, which fixed the compile problem for me:

--- Python-2.7.1/Lib/site.py    2010-10-12 18:53:51.000000000 -0400
+++ Python-2.7.1/Lib/site.py.addbuilddir-revert 2011-04-16 23:03:47.000000000 -0400
@@ -122,7 +122,7 @@
     s = "build/lib.%s-%.3s" % (get_platform(), sys.version)
     if hasattr(sys, 'gettotalrefcount'):
         s += '-pydebug'
-    s = os.path.join(os.path.dirname(sys.path.pop()), s)
+    s = os.path.join(os.path.dirname(sys.path[-1]), s)
     sys.path.append(s)

Obviously I imagine there was a reason why this change was made, so the above patch is probably not an appropriate universal fix.  I don't know anything about the original reasoning, but this change does seem to work for me on CentOS 5.5 now.

Notably, the issue I'm describing doesn't appear to have anything to do with gcc.  (Incidentally, I'm using gcc-4.1.2-48.el5.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9631>
_______________________________________

From report at bugs.python.org  Sun Apr 17 06:15:29 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 Apr 2011 04:15:29 +0000
Subject: [issue11854] __or__ et al instantiate subclass of set without calling
	__init__
In-Reply-To: <1302931795.31.0.443472549499.issue11854@psf.upfronthosting.co.za>
Message-ID: <1303013729.84.0.00377297547815.issue11854@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

If some code were added to call __init__ for the new instance of a set/frozenset subclass, it would have to make an assumption that the method's signature allowed it to be called without any arguments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11854>
_______________________________________

From report at bugs.python.org  Sun Apr 17 07:19:12 2011
From: report at bugs.python.org (higery)
Date: Sun, 17 Apr 2011 05:19:12 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1303017552.32.0.499753538626.issue828450@psf.upfronthosting.co.za>


Changes by higery <shoulderhigher at gmail.com>:


Removed file: http://bugs.python.org/file21667/test_sdist.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Sun Apr 17 07:25:20 2011
From: report at bugs.python.org (higery)
Date: Sun, 17 Apr 2011 05:25:20 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1303017920.52.0.982433099409.issue828450@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

It may be just necessary to hack the write_manifest funtion in sdist.py- replace all '\' in MANIFEST with '/', thus it will not have other bad side effects, for instance, it would not change the content of self.filelist and people can also use '/' in MANIFEST template file on windows as usual.

----------
Added file: http://bugs.python.org/file21691/change_path_separator_in_MANIFEST.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Sun Apr 17 13:09:14 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 17 Apr 2011 11:09:14 +0000
Subject: [issue9041] raised exception is misleading
In-Reply-To: <1277123013.52.0.887079191328.issue9041@psf.upfronthosting.co.za>
Message-ID: <1303038554.2.0.751876989185.issue9041@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/issue9041>
_______________________________________

From report at bugs.python.org  Sun Apr 17 13:20:25 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 17 Apr 2011 11:20:25 +0000
Subject: [issue11860] reference 2.3 has text that runs past the page
In-Reply-To: <1303005204.18.0.459182918365.issue11860@psf.upfronthosting.co.za>
Message-ID: <1303039225.16.0.710475973535.issue11860@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/issue11860>
_______________________________________

From report at bugs.python.org  Sun Apr 17 13:51:51 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 17 Apr 2011 11:51:51 +0000
Subject: [issue9896] Introspectable range objects
In-Reply-To: <1284835167.56.0.979385376089.issue9896@psf.upfronthosting.co.za>
Message-ID: <1303041111.52.0.257045423952.issue9896@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

Now that the moratorium has already ended, I'll try again.  I've updated the patch.

It seems, that this idea has already came up in the past: Guido in msg70525 said: "I also think ranges should be introspectable, exposing their start, stop and step values just like slice objects."

A possible use case: the range slicing logic is quite complex (with a lot of corner cases).  It would be good, if this logic would be accessible from Python code, for example to compute a slice of a slice-like-thing.  Currently slicing a range object returns another range object, but there is no way to determine the bounds of this new object.

----------
versions: +Python 3.3 -Python 3.2
Added file: http://bugs.python.org/file21692/range_attrs_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9896>
_______________________________________

From report at bugs.python.org  Sun Apr 17 15:12:20 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 17 Apr 2011 13:12:20 +0000
Subject: [issue11861] 2to3 fails with a ParseError
In-Reply-To: <1303045938.22.0.287313368996.issue11861@psf.upfronthosting.co.za>
Message-ID: <1303045938.22.0.287313368996.issue11861@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

2to3 fails on boto/rds/__init__.py with a ParseError:

vinay at eta-natty:~/tools/boto$ 2to3 boto/rds/__init__.py 
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 boto/rds/__init__.py: ParseError: bad input: type=1, value='RDSRegionInfo', context=('\n            ', (48, 12))
RefactoringTool: No files need to be modified.
RefactoringTool: There was 1 error:
RefactoringTool: Can't parse boto/rds/__init__.py: ParseError: bad input: type=1, value='RDSRegionInfo', context=('\n            ', (48, 12))

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: __init__.py
messages: 133922
nosy: vinay.sajip
priority: normal
severity: normal
status: open
title: 2to3 fails with a ParseError
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21693/__init__.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11861>
_______________________________________

From report at bugs.python.org  Sun Apr 17 15:30:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Apr 2011 13:30:12 +0000
Subject: [issue11859] test_interrupted_write_text() of test_io failed of
	Python 3.3 on FreeBSD 7.2
In-Reply-To: <1302994631.38.0.484484359613.issue11859@psf.upfronthosting.co.za>
Message-ID: <1303047012.67.0.536387912261.issue11859@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Agreed with your analysis. The problem is that the signal module doesn't expose pthread_sigmask. We could grab Jean-Paul's implementation from http://bazaar.launchpad.net/~exarkun/python-signalfd/trunk/view/head:/signalfd/_signalfd.c (although I'm not sure why the method is called "sigprocmask" while it calls pthread_sigmask).

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11859>
_______________________________________

From report at bugs.python.org  Sun Apr 17 15:31:33 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 17 Apr 2011 13:31:33 +0000
Subject: [issue11861] 2to3 fails with a ParseError
In-Reply-To: <1303045938.22.0.287313368996.issue11861@psf.upfronthosting.co.za>
Message-ID: <1303047093.92.0.597137070293.issue11861@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +benjamin.peterson, ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11861>
_______________________________________

From report at bugs.python.org  Sun Apr 17 15:38:29 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 17 Apr 2011 13:38:29 +0000
Subject: [issue11276] 2to3: imports fixer doesn't update references to modules
	specified without attributes
In-Reply-To: <1298320370.6.0.707528298714.issue11276@psf.upfronthosting.co.za>
Message-ID: <1303047509.86.0.878764414846.issue11276@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Another example: when processing

if hasattr(httplib, 'ssl'):
    pass

It doesn't spot that httplib should be changed to http.client.

----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11276>
_______________________________________

From report at bugs.python.org  Sun Apr 17 15:46:43 2011
From: report at bugs.python.org (Jan Groenewald)
Date: Sun, 17 Apr 2011 13:46:43 +0000
Subject: [issue9762] PEP 3149 related build failures
In-Reply-To: <1283542817.2.0.95523590272.issue9762@psf.upfronthosting.co.za>
Message-ID: <1303048003.95.0.0638649218562.issue9762@psf.upfronthosting.co.za>


Jan Groenewald <jan.groenewald at gmail.com> added the comment:

I am trying to build www.sagemath.org on ubuntu 10.04 natty beta 2 for amd64. Bear with me.

Sage includes a patched version of python2.6.4, and it fails to build
modules nis and crypt.

Upstream python 2.6.4, 2.6.6, and 2.7.1 fail to build with the same
error with ./configure, make, as per the README. The patch proposed is for setup.py, which is not used here?

Ubuntu has a packaged python 2.6.6 and 2.7.1 (default) which I assume
is patched, and builds on their toolchain.

----------
nosy: +Jan.Groenewald
versions: +Python 2.6 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9762>
_______________________________________

From report at bugs.python.org  Sun Apr 17 15:47:27 2011
From: report at bugs.python.org (Jan Groenewald)
Date: Sun, 17 Apr 2011 13:47:27 +0000
Subject: [issue9762] PEP 3149 related build failures
In-Reply-To: <1283542817.2.0.95523590272.issue9762@psf.upfronthosting.co.za>
Message-ID: <1303048047.62.0.42384134449.issue9762@psf.upfronthosting.co.za>


Jan Groenewald <jan.groenewald at gmail.com> added the comment:

Oops, correction. Ubuntu 11.04 beta 2 for amd64.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9762>
_______________________________________

From report at bugs.python.org  Sun Apr 17 15:50:41 2011
From: report at bugs.python.org (lekma)
Date: Sun, 17 Apr 2011 13:50:41 +0000
Subject: [issue10271] warnings.showwarning should allow any callable object
In-Reply-To: <1288551215.82.0.402250167562.issue10271@psf.upfronthosting.co.za>
Message-ID: <1303048241.91.0.692391027578.issue10271@psf.upfronthosting.co.za>


lekma <lekmalek at gmail.com> added the comment:

- split the patch between the actual fix and the test
- rewrote the test a little bit (I'm not sure it's even needed, hence the split)
- rediff against 3.3 (should still apply cleanly on top of 3.2 (modulo offset))

----------
versions: +Python 3.3
Added file: http://bugs.python.org/file21694/Issue10271.33.fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10271>
_______________________________________

From report at bugs.python.org  Sun Apr 17 15:51:15 2011
From: report at bugs.python.org (lekma)
Date: Sun, 17 Apr 2011 13:51:15 +0000
Subject: [issue10271] warnings.showwarning should allow any callable object
In-Reply-To: <1288551215.82.0.402250167562.issue10271@psf.upfronthosting.co.za>
Message-ID: <1303048275.51.0.218659114964.issue10271@psf.upfronthosting.co.za>


Changes by lekma <lekmalek at gmail.com>:


Added file: http://bugs.python.org/file21695/Issue10271.33.test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10271>
_______________________________________

From report at bugs.python.org  Sun Apr 17 16:04:26 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 17 Apr 2011 14:04:26 +0000
Subject: [issue9762] PEP 3149 related build failures
In-Reply-To: <1303048003.95.0.0638649218562.issue9762@psf.upfronthosting.co.za>
Message-ID: <20110417100416.7605d971@neurotica.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Apr 17, 2011, at 01:46 PM, Jan Groenewald wrote:

>Jan Groenewald <jan.groenewald at gmail.com> added the comment:
>
>I am trying to build www.sagemath.org on ubuntu 10.04 natty beta 2 for amd64. Bear with me.

As described in your follow up, the problem is really on 11.04.

>Sage includes a patched version of python2.6.4, and it fails to build
>modules nis and crypt.
>
>Upstream python 2.6.4, 2.6.6, and 2.7.1 fail to build with the same
>error with ./configure, make, as per the README. The patch proposed is for setup.py, which is not used here?
>
>Ubuntu has a packaged python 2.6.6 and 2.7.1 (default) which I assume
>is patched, and builds on their toolchain.

This is not related to PEP 3149 failures.  Ubuntu 11.04 introduced multiarch
directories for the underlying shared libraries used to link to the Python
extension modules.  Unpatched, Python's setup.py does not add the necessary
multiarch directories to the search paths, so some extensions won't build.

Ubuntu 11.04's Python packages have been patched to add the correct search
paths.  Upstream Python 2.7, 3.1, 3.2, and 3.3 have also been patched to
include the correct search paths, but fixed versions have not been released
upstream yet.  Python 2.6 won't be patched.

See issue 11715 for details.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9762>
_______________________________________

From report at bugs.python.org  Sun Apr 17 16:39:40 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sun, 17 Apr 2011 14:39:40 +0000
Subject: [issue11849] ElementTree memory leak
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1303051180.62.0.0195417236337.issue11849@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

The "problem" is not with Python, but with your libc.
When a program - such as Python - returns memory, it uses the free(3) library call.
But the libc is free to either return the memory immediately to the kernel using the relevant syscall (brk, munmap), or keep it around just in case (to simplify).
It seems that RHEL5 and onwards tend to keep a lot of memory around, at least in this case (probably because of the allocation pattern).

To sum up, python is returning memory, but your libc is not.
You can force it using malloc_trim, see the attached patch (I'm not at all suggesting its inclusion, it's just an illustration).

Results with current code:

*** Python 3.3.0 alpha
---   PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
  0 29823 pts/0    S+     0:00      1  1607 168176 8596  0.2 ./python /tmp/issue11849_test.py
  1 29823 pts/0    S+     0:01      1  1607 249400 87088  2.2 ./python /tmp/issue11849_test.py
  2 29823 pts/0    S+     0:03      1  1607 324080 161704  4.1 ./python /tmp/issue11849_test.py
  3 29823 pts/0    S+     0:04      1  1607 398960 235036  5.9 ./python /tmp/issue11849_test.py
  4 29823 pts/0    S+     0:06      1  1607 473356 309464  7.8 ./python /tmp/issue11849_test.py
  5 29823 pts/0    S+     0:07      1  1607 548120 384624  9.8 ./python /tmp/issue11849_test.py
  6 29823 pts/0    S+     0:09      1  1607 622884 458332 11.6 ./python /tmp/issue11849_test.py
  7 29823 pts/0    S+     0:10      1  1607 701864 535736 13.6 ./python /tmp/issue11849_test.py
  8 29823 pts/0    S+     0:12      1  1607 772440 607988 15.5 ./python /tmp/issue11849_test.py
  9 29823 pts/0    S+     0:13      1  1607 851156 685384 17.4 ./python /tmp/issue11849_test.py
END 29823 pts/0    S+     0:16      1  1607 761712 599400 15.2 ./python /tmp/issue11849_test.py
 GC 29823 pts/0    S+     0:16      1  1607 680900 519280 13.2 ./python /tmp/issue11849_test.py
*** 29823 pts/0    S+     0:16      1  1607 680900 519288 13.2 ./python /tmp/issue11849_test.py


Results with the malloc_trim:

*** Python 3.3.0 alpha
---   PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
  0 30020 pts/0    S+     0:00      1  1607 168180 8596  0.2 ./python /tmp/issue11849_test.py
  1 30020 pts/0    S+     0:01      1  1607 249404 86160  2.1 ./python /tmp/issue11849_test.py
  2 30020 pts/0    S+     0:03      1  1607 324084 160596  4.0 ./python /tmp/issue11849_test.py
  3 30020 pts/0    S+     0:04      1  1607 398964 235036  5.9 ./python /tmp/issue11849_test.py
  4 30020 pts/0    S+     0:06      1  1607 473360 309808  7.9 ./python /tmp/issue11849_test.py
  5 30020 pts/0    S+     0:07      1  1607 548124 383896  9.7 ./python /tmp/issue11849_test.py
  6 30020 pts/0    S+     0:09      1  1607 622888 458716 11.7 ./python /tmp/issue11849_test.py
  7 30020 pts/0    S+     0:10      1  1607 701868 536124 13.6 ./python /tmp/issue11849_test.py
  8 30020 pts/0    S+     0:12      1  1607 772444 607212 15.4 ./python /tmp/issue11849_test.py
  9 30020 pts/0    S+     0:14      1  1607 851160 684608 17.4 ./python /tmp/issue11849_test.py
END 30020 pts/0    S+     0:16      1  1607 761716 599524 15.3 ./python /tmp/issue11849_test.py
 GC 30020 pts/0    S+     0:16      1  1607 680776 10744  0.2 ./python /tmp/issue11849_test.py
*** 30020 pts/0    S+     0:16      1  1607 680776 10752  0.2 ./python /tmp/issue11849_test.py

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Sun Apr 17 16:41:41 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sun, 17 Apr 2011 14:41:41 +0000
Subject: [issue11849] ElementTree memory leak
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1303051301.26.0.232915633261.issue11849@psf.upfronthosting.co.za>


Changes by Charles-Francois Natali <neologix at free.fr>:


----------
keywords: +patch
Added file: http://bugs.python.org/file21696/gc_trim.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Sun Apr 17 17:34:38 2011
From: report at bugs.python.org (higery)
Date: Sun, 17 Apr 2011 15:34:38 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1303054478.46.0.51737914788.issue828450@psf.upfronthosting.co.za>


Changes by higery <shoulderhigher at gmail.com>:


Removed file: http://bugs.python.org/file21691/change_path_separator_in_MANIFEST.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Sun Apr 17 17:35:46 2011
From: report at bugs.python.org (higery)
Date: Sun, 17 Apr 2011 15:35:46 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1303054546.98.0.812449007379.issue828450@psf.upfronthosting.co.za>


Changes by higery <shoulderhigher at gmail.com>:


Added file: http://bugs.python.org/file21697/change_path_separator_in_MANIFEST.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Sun Apr 17 17:39:36 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sun, 17 Apr 2011 15:39:36 +0000
Subject: [issue11700] mailbox.py proxy updates
In-Reply-To: <1302985050.59.0.848109362051.issue11700@psf.upfronthosting.co.za>
Message-ID: <20110417153923.GA723@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

On Sat, Apr 16, 2011 at 08:17:30PM +0000, R. David Murray wrote:
> [...] rather odd considering that there is also a 'closed'
> method that would fail similarly if close was ever called.

Maybe someone got not enough feedback after she wrote the patch.

> (The only use for the existing 'closed' method that I can see is
> to see if somebody else closed the file out from under the
> ProxyFile, a 'feature' that seems of dubious utility.)

After i've read io.rst - as above - i thought someone started to
comply to one of the interfaces shown therein, went away because
the current bug was fixed and there was no more time left at the
moment to continue the work ... and actually never found back to
do so.  This really made sense to me because that actually happened
a few days after i first got on the Internet to contact python.org.

I would like to say that if someone reads "file-like objects" in
io.rst and then also in mailbox.rst, and uses a box.get_file()
returned object with that description in mind, there will be
inconsistent failures.

> Steffen, [...] I plan to close this issue by applying my patch.

That is a pity.  But the main thing is that the bug gets fixed.

- .closed is better than my version (talking about .sigh).
- I would add a self.assertFalse(proxy.closed) test before the
  first .close().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11700>
_______________________________________

From report at bugs.python.org  Sun Apr 17 17:57:35 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 17 Apr 2011 15:57:35 +0000
Subject: [issue11700] mailbox.py proxy updates
In-Reply-To: <1301315190.34.0.276151285444.issue11700@psf.upfronthosting.co.za>
Message-ID: <1303055855.19.0.564710057546.issue11700@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah.  Well, since the io module and its classes didn't exist when that code in mailbox.py was written, no, that's not what happened :)

Nor does 'file like object' in Python necessarily mean conformance to the io specification.  We are *tending* in that direction, but the actual expected method set is really considerably smaller (and I'm not sure it is documented anywhere).

I will incorporate your suggestion into the patch, thanks.  Ezio also pointed out that I should be checking for the 'closed' method's existence before calling it, so I will add that as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11700>
_______________________________________

From report at bugs.python.org  Sun Apr 17 19:01:35 2011
From: report at bugs.python.org (Bob Ippolito)
Date: Sun, 17 Apr 2011 17:01:35 +0000
Subject: [issue5723] Incomplete json tests
In-Reply-To: <1239205406.15.0.353111609778.issue5723@psf.upfronthosting.co.za>
Message-ID: <1303059695.64.0.519623058757.issue5723@psf.upfronthosting.co.za>


Bob Ippolito <bob at redivi.com> added the comment:

I did this some time ago in simplejson by defining a TestSuite subclass and instrumenting simplejson so that speedups can be enabled and disabled easily with a private API.

https://github.com/simplejson/simplejson/blob/master/simplejson/tests/__init__.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5723>
_______________________________________

From report at bugs.python.org  Sun Apr 17 20:03:26 2011
From: report at bugs.python.org (Prashant Kumar)
Date: Sun, 17 Apr 2011 18:03:26 +0000
Subject: [issue10932] distutils.core.setup - data_files misbehaviour ?
In-Reply-To: <1295353825.23.0.755300594789.issue10932@psf.upfronthosting.co.za>
Message-ID: <1303063406.11.0.556600234014.issue10932@psf.upfronthosting.co.za>


Prashant Kumar <contactprashantat at gmail.com> added the comment:

I made changes in manifest.py which can be viewed here: https://bitbucket.org/pkumar/distutils2_bugs/changeset/111c1253ea7a

I'm not sure if I should modify test_command_sdist.py for the failing tests of manifest contents(since it is mentioned not to edit). 

msg133834:
>> I don?t understand this comment: ?Though, inside zip-file we get files without its parent dir, nothing changes in manifest file(should it change?)

code from test_command_sdist.py:

        zip_file = zipfile.ZipFile(join(dist_folder, 'fake-1.0.zip'))
        try:
            content = zip_file.namelist()
        finally:
            zip_file.close()
after the change as mentioned in msg127191, the value of content changed, i.e. 'fake-1.0/some/other_file.txt' was changed to 'fake-1.0/other_file.txt'.But modifications were still required for the manifest. Above change should serve the purpose, I guess.

----------
hgrepos: +20

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10932>
_______________________________________

From report at bugs.python.org  Sun Apr 17 20:23:14 2011
From: report at bugs.python.org (Tomasz Melcer)
Date: Sun, 17 Apr 2011 18:23:14 +0000
Subject: [issue11862] urlparse.ParseResult to have meaningful __str__
In-Reply-To: <1303064594.29.0.64850729087.issue11862@psf.upfronthosting.co.za>
Message-ID: <1303064594.29.0.64850729087.issue11862@psf.upfronthosting.co.za>


New submission from Tomasz Melcer <liori at o2.pl>:

I find it a minor annoyance that a result of `urlparse.urlparse` (an object of class urlparse.ParseResult) doesn't have a meaningful __str__/__unicode__ methods. `urlparse.ParseResult` is a subclass of `namedtuple` with __slots__, so I can't easily add it, too.

I propose to make __str__/__unicode__ equivalent to geturl() call.

----------
components: Extension Modules
messages: 133934
nosy: liori
priority: normal
severity: normal
status: open
title: urlparse.ParseResult to have meaningful __str__
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11862>
_______________________________________

From report at bugs.python.org  Sun Apr 17 21:06:31 2011
From: report at bugs.python.org (Torsten Becker)
Date: Sun, 17 Apr 2011 19:06:31 +0000
Subject: [issue11783] email parseaddr and formataddr should be IDNA aware
In-Reply-To: <1302099121.47.0.140525796896.issue11783@psf.upfronthosting.co.za>
Message-ID: <1303067191.51.0.627601440961.issue11783@psf.upfronthosting.co.za>


Torsten Becker <torsten.becker at gmail.com> added the comment:

Hi, here is my revised patch with email.utils.getaddresses() also decoding IDNs.

I decided to integrate IDN decoding in AddrlistClass.getaddress() instead of AddrlistClass.getaddrlist() since that function is one level lower and if somebody should ever all it directly, the conversion would not happen.

I also fixed a glitch in the docs, "versionchanged" seems to need two colons to end up in the generated HTML.


As a follow up, wouldn't it be helpful if email.Message would do the conversions directly?  So when you parse a mail into a Message and access the "To" field, you get a list of tuples which are decoded properly?

For example the following test currently still fails because the quoted header value is not decoded by email.feedparser.FeedParser nor email.Message:

    def test_email_decodes_idns_and_unicode(self):
        text = '''\
To: =?utf-8?b?SMOkbnMgV8O8cnN0?= <hans at xn--dm-fka.ain>

Hello World!'''
        msg = Parser().parsestr(text)
        self.assertEqual(utils.getaddresses(msg.get_all('To')),
            [('H\xe4ns W\xfcrst', 'hans at d\xf6m.ain')])

Am I using the package wrong here or is this actually missing?  email.header.decode_header seems to be able to do this already but it is not used.  Would it be safe to integrate this into the email.message._sanitize_header helper?

----------
Added file: http://bugs.python.org/file21698/issue-11783-v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11783>
_______________________________________

From report at bugs.python.org  Sun Apr 17 21:37:50 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 17 Apr 2011 19:37:50 +0000
Subject: [issue11783] email parseaddr and formataddr should be IDNA aware
In-Reply-To: <1302099121.47.0.140525796896.issue11783@psf.upfronthosting.co.za>
Message-ID: <1303069070.53.0.302495014299.issue11783@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks.  I should be able to look at this tomorrow.

You are correct about the fact that Message currently doesn't do any decoding.  That is part of the design: you get the string out of Message and use the helper decoding functions (decode_header, getaddresses, etc) to get actual usable data out of it.

Part of the email6 design addresses this with a new API that will make it much easier to get at the parsed data (methods on a header object returned from msg['xxx']).  But for the current package the way it works it the way it is supposed to work ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11783>
_______________________________________

From report at bugs.python.org  Sun Apr 17 21:58:35 2011
From: report at bugs.python.org (akira)
Date: Sun, 17 Apr 2011 19:58:35 +0000
Subject: [issue984870] curses: getmaxyx() breaks when the window shrinks
Message-ID: <1303070315.27.0.954914947287.issue984870@psf.upfronthosting.co.za>


akira <4kir4.1i at gmail.com> added the comment:

The test produces a traceback while shrinking a window (increasing the window size works ok):

Traceback (most recent call last):
  File "screen-resize-bug-curses.py", line 22, in <module>
    curses.wrapper(main)
  File "/.../python2.7/curses/wrapper.py", line 43, in wrapper
    return func(stdscr, *args, **kwds)
  File "screen-resize-bug-curses.py", line 17, in main
    init_display(stdscr)
  File "screen-resize-bug-curses.py", line 9, in init_display
    rootwin = stdscr.derwin(20, 50, 0, 0)
_curses.error: curses function returned NULL

Version info:

$ python2.7 -c'import curses; print curses.version'
2.2

----------
nosy: +akira

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue984870>
_______________________________________

From report at bugs.python.org  Sun Apr 17 23:01:37 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 Apr 2011 21:01:37 +0000
Subject: [issue11442] list_directory() in SimpleHTTPServer.py should add
	charset=... to Content-type header
In-Reply-To: <1299611115.64.0.389023379939.issue11442@psf.upfronthosting.co.za>
Message-ID: <E1QBZ67-0003oZ-Bx@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset bb1695c6cea1 by Martin v. L?wis in branch '2.5':
Issue 11442: Add NEWS entry for e9724d7abbc2
http://hg.python.org/cpython/rev/bb1695c6cea1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11442>
_______________________________________

From report at bugs.python.org  Mon Apr 18 00:22:13 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 17 Apr 2011 22:22:13 +0000
Subject: [issue11700] mailbox.py proxy updates
In-Reply-To: <1301315190.34.0.276151285444.issue11700@psf.upfronthosting.co.za>
Message-ID: <1303078933.2.0.187241088369.issue11700@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Updated patch addressing Stefen and Ezio's comments.

----------
Added file: http://bugs.python.org/file21699/mailbox_close_twice.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11700>
_______________________________________

From report at bugs.python.org  Mon Apr 18 00:27:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Apr 2011 22:27:54 +0000
Subject: [issue11849] ElementTree memory leak
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1303079274.27.0.606416332962.issue11849@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> To sum up, python is returning memory, but your libc is not.
> You can force it using malloc_trim, see the attached patch (I'm not at 
> all suggesting its inclusion, it's just an illustration).

That's an interesting thing, perhaps you want to open a feature request as a separate issue?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Mon Apr 18 01:12:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 17 Apr 2011 23:12:23 +0000
Subject: [issue11768] test_signals() of test_threadsignals failure on Mac OS X
In-Reply-To: <1301962757.99.0.598461435574.issue11768@psf.upfronthosting.co.za>
Message-ID: <1303081943.95.0.108556181578.issue11768@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, I reproduced the bug.
------------------------
[3021] test_threadsignals
test_signals (test.test_threadsignals.ThreadSignals) ... test_signals: acquire lock (thread -1610559488)
test_signals: wait lock (thread -1610559488)
send_signals: enter (thread 27159552)
send_signals: raise SIGUSR1
send_signals: raise SIGUSR2
send_signals: release signalled_all
send_signals: exit (thread 27159552)

^C
------------------------

There are 2 threads: faulthandler thread and the mainthread. Trace of the main thread:
-------
(gdb) where
#0  0xffff027a in ___spin_lock () at /System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h:216
#1  0x90001433 in pthread_mutex_lock ()
#2  0x0011b34c in PyThread_acquire_lock_timed (lock=0x1124f10, microseconds=0, intr_flag=0) at Python/thread_pthread.h:450
#3  0x0011b73e in PyThread_acquire_lock (lock=0x1124f10, waitflag=0) at Python/thread_pthread.h:531
#4  0x000775b2 in Py_AddPendingCall (func=0x713dd <checksignals_witharg>, arg=0x0) at Python/ceval.c:509
#5  0x00071445 in signal_handler (sig_num=31) at ./Modules/signalmodule.c:189
#6  <signal handler called>
#7  0x9010d494 in spin_unlock ()
#8  0x90001620 in pthread_mutex_lock ()
#9  0x0011b34c in PyThread_acquire_lock_timed (lock=0x1124f10, microseconds=0, intr_flag=0) at Python/thread_pthread.h:450
#10 0x0011b73e in PyThread_acquire_lock (lock=0x1124f10, waitflag=0) at Python/thread_pthread.h:531
#11 0x000775b2 in Py_AddPendingCall (func=0x713dd <checksignals_witharg>, arg=0x0) at Python/ceval.c:509
#12 0x00071445 in signal_handler (sig_num=30) at ./Modules/signalmodule.c:189
#13 <signal handler called>
#14 0x900248c7 in semaphore_wait_signal_trap ()
#15 0x900288b4 in pthread_cond_wait ()
#16 0x0011b52c in PyThread_acquire_lock_timed (lock=0x1171180, microseconds=-1, intr_flag=1) at Python/thread_pthread.h:476
#17 0x00180746 in acquire_timed (lock=0x1171180, microseconds=-1) at ./Modules/_threadmodule.c:66
#18 0x001809aa in lock_PyThread_acquire_lock (self=0x14ff820, args=0x512038, kwds=0x0) at ./Modules/_threadmodule.c:133
#19 0x0005f58e in PyCFunction_Call (func=0x166c5f8, arg=0x512038, kw=0x0) at Objects/methodobject.c:84
#20 0x0008c1cd in call_function (pp_stack=0xbfff5f64, oparg=0) at Python/ceval.c:3859
#21 0x000869dd in PyEval_EvalFrameEx (f=0x1193798, throwflag=0) at Python/ceval.c:2657
...
-------

The main thread was waiting test_signals() lock (signalled_all) while it is was interrupted by a signal. The signal handler calls Py_AddPendingCall() which blocks on acquiring "pending_lock".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11768>
_______________________________________

From report at bugs.python.org  Mon Apr 18 01:27:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 17 Apr 2011 23:27:40 +0000
Subject: [issue11768] test_signals() of test_threadsignals failure on Mac OS X
In-Reply-To: <1301962757.99.0.598461435574.issue11768@psf.upfronthosting.co.za>
Message-ID: <1303082860.22.0.443264505113.issue11768@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The main thread was waiting test_signals() lock (signalled_all) 
> while it is was interrupted by a signal. The signal handler calls
> Py_AddPendingCall() which blocks on acquiring "pending_lock".

Oh, the main thread receives SIGUSR1: the signal handler calls Py_AddPendingCall() to process it later. But while calling Py_AddPendingCall(), it receives a SIGUSR2: the same signal handler is called, and it calls Py_AddPendingCall().

And we have a deadlock because we try to acquire the lock twice, or try to acquire the lock before the lock was released.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11768>
_______________________________________

From report at bugs.python.org  Mon Apr 18 01:59:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Apr 2011 23:59:24 +0000
Subject: [issue11768] test_signals() of test_threadsignals failure on Mac OS X
In-Reply-To: <1301962757.99.0.598461435574.issue11768@psf.upfronthosting.co.za>
Message-ID: <1303084764.95.0.139736664942.issue11768@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The signal handler calls Py_AddPendingCall() which blocks on acquiring 
> "pending_lock".

It blocks in taking the mutex, not on waiting for the condition variable. Otherwise it wouldn't block (microseconds = 0).

I think the solution is to protect signal_handler() against reentrancy: 

diff --git a/Modules/signalmodule.c b/Modules/signalmodule.c
--- a/Modules/signalmodule.c
+++ b/Modules/signalmodule.c
@@ -185,10 +185,12 @@ signal_handler(int sig_num)
         Handlers[sig_num].tripped = 1;
         /* Set is_tripped after setting .tripped, as it gets
            cleared in PyErr_CheckSignals() before .tripped. */
-        is_tripped = 1;
-        Py_AddPendingCall(checksignals_witharg, NULL);
-        if (wakeup_fd != -1)
-            write(wakeup_fd, "\0", 1);
+        if (!is_tripped) {
+            is_tripped = 1;
+            Py_AddPendingCall(checksignals_witharg, NULL);
+            if (wakeup_fd != -1)
+                write(wakeup_fd, "\0", 1);
+        }
     }
 
 #ifndef HAVE_SIGACTION

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11768>
_______________________________________

From report at bugs.python.org  Mon Apr 18 02:08:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Apr 2011 00:08:57 +0000
Subject: [issue11863] Enforce PEP 11 - remove support for legacy systems
In-Reply-To: <1303085337.86.0.669937619549.issue11863@psf.upfronthosting.co.za>
Message-ID: <1303085337.86.0.669937619549.issue11863@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

PEP 11 calls for removing support for the following systems in 3.3:

    Name:             Systems using Mach C Threads
    Unsupported in:   Python 3.2
    Code removed in:  Python 3.3

    Name:             SunOS lightweight processes (LWP)
    Unsupported in:   Python 3.2
    Code removed in:  Python 3.3

    Name:             Systems using --with-pth (GNU pth threads)
    Unsupported in:   Python 3.2
    Code removed in:  Python 3.3

    Name:             Systems using Irix threads
    Unsupported in:   Python 3.2
    Code removed in:  Python 3.3

    Name:             OSF* systems (issue 8606)
    Unsupported in:   Python 3.2 
    Code removed in:  Python 3.3

----------
components: Build, Interpreter Core
keywords: easy
messages: 133944
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Enforce PEP 11 - remove support for legacy systems
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11863>
_______________________________________

From report at bugs.python.org  Mon Apr 18 02:12:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Apr 2011 00:12:53 +0000
Subject: [issue11864] sporadic failure in test_concurrent_futures
In-Reply-To: <1303085572.99.0.967761591602.issue11864@psf.upfronthosting.co.za>
Message-ID: <1303085572.99.0.967761591602.issue11864@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Happened on a buildbot:
http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/2957/steps/test/logs/stdio

test test_concurrent_futures failed -- Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_concurrent_futures.py", line 276, in test_timeout
    future1]), finished)
AssertionError: Items in the first set but not the second:
<Future at 0xb802dc8 state=running>

----------
components: Library (Lib), Tests
messages: 133945
nosy: bquinlan, pitrou
priority: normal
severity: normal
status: open
title: sporadic failure in test_concurrent_futures
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11864>
_______________________________________

From report at bugs.python.org  Mon Apr 18 02:37:29 2011
From: report at bugs.python.org (kaifeng)
Date: Mon, 18 Apr 2011 00:37:29 +0000
Subject: [issue11849] ElementTree memory leak
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1303087049.93.0.497125129893.issue11849@psf.upfronthosting.co.za>


kaifeng <cafeeee at gmail.com> added the comment:

I added 'malloc_trim' to the test code and rerun the test with Python 2.5 / 3.2 on CentOS 5.3.  The problem still exists.


*** Python 2.5.5 final
---   PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
  0  2567 pts/0    S+     0:00      0     1  8206  4864  0.4 /home/zkf/.programs/python/bin/python issue11849_test.py
  1  2567 pts/0    S+     0:03      0     1 44558 41140  3.9 /home/zkf/.programs/python/bin/python issue11849_test.py
  2  2567 pts/0    S+     0:07      0     1 81166 77728  7.5 /home/zkf/.programs/python/bin/python issue11849_test.py
  3  2567 pts/0    S+     0:12      0     1 117798 114316 11.0 /home/zkf/.programs/python/bin/python issue11849_test.py
  4  2567 pts/0    S+     0:17      0     1 154402 150912 14.5 /home/zkf/.programs/python/bin/python issue11849_test.py
  5  2567 pts/0    S+     0:23      0     1 191018 187500 18.1 /home/zkf/.programs/python/bin/python issue11849_test.py
  6  2567 pts/0    S+     0:29      0     1 227630 224084 21.6 /home/zkf/.programs/python/bin/python issue11849_test.py
  7  2567 pts/0    S+     0:36      0     1 264242 260668 25.1 /home/zkf/.programs/python/bin/python issue11849_test.py
  8  2567 pts/0    S+     0:44      0     1 300882 297288 28.7 /home/zkf/.programs/python/bin/python issue11849_test.py
  9  2567 pts/0    S+     0:53      0     1 337230 333860 32.2 /home/zkf/.programs/python/bin/python issue11849_test.py
END  2567 pts/0    S+     1:02      0     1 373842 370444 35.7 /home/zkf/.programs/python/bin/python issue11849_test.py
 GC  2567 pts/0    S+     1:02      0     1 373842 370444 35.7 /home/zkf/.programs/python/bin/python issue11849_test.py
***  2567 pts/0    S+     1:02      0     1 373714 370436 35.7 /home/zkf/.programs/python/bin/python issue11849_test.py


*** Python 3.2.0 final
---   PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
  0  2633 pts/0    S+     0:00      1  1316 11051  6448  0.6 python3.2 issue11849_test.py
  1  2633 pts/0    S+     0:02      1  1316 53151 47340  4.5 python3.2 issue11849_test.py
  2  2633 pts/0    S+     0:05      1  1316 91051 85216  8.2 python3.2 issue11849_test.py
  3  2633 pts/0    S+     0:08      1  1316 128943 124228 12.0 python3.2 issue11849_test.py
  4  2633 pts/0    S+     0:11      1  1316 166803 162296 15.6 python3.2 issue11849_test.py
  5  2633 pts/0    S+     0:14      1  1316 204475 199972 19.3 python3.2 issue11849_test.py
  6  2633 pts/0    S+     0:17      1  1316 243831 238180 23.0 python3.2 issue11849_test.py
  7  2633 pts/0    S+     0:20      1  1316 284371 277532 26.8 python3.2 issue11849_test.py
  8  2633 pts/0    S+     0:23      1  1316 318187 312456 30.1 python3.2 issue11849_test.py
  9  2633 pts/0    S+     0:26      1  1316 360231 353296 34.1 python3.2 issue11849_test.py
END  2633 pts/0    S+     0:30      1  1316 393971 388184 37.4 python3.2 issue11849_test.py
 GC  2633 pts/0    S+     0:30      1  1316 352031 347652 33.5 python3.2 issue11849_test.py
***  2633 pts/0    S+     0:31      1  1316 351903 347524 33.5 python3.2 issue11849_test.py

----------
versions: +Python 2.7, Python 3.2
Added file: http://bugs.python.org/file21700/issue11849_test2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Mon Apr 18 03:03:48 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 18 Apr 2011 01:03:48 +0000
Subject: [issue11863] Enforce PEP 11 - remove support for legacy systems
In-Reply-To: <1303085337.86.0.669937619549.issue11863@psf.upfronthosting.co.za>
Message-ID: <1303088628.79.0.110828437687.issue11863@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I think I toke care of OSF cleanup already.

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11863>
_______________________________________

From report at bugs.python.org  Mon Apr 18 03:07:46 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 18 Apr 2011 01:07:46 +0000
Subject: [issue11241] ctypes: subclassing an already subclassed ArrayType
	generates AttributeError
In-Reply-To: <1297987167.42.0.900007110424.issue11241@psf.upfronthosting.co.za>
Message-ID: <1303088866.51.0.294452571885.issue11241@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Verified that this is still broken in the main development branch.  
The base type should be checked for '_type_' or '_length_' before throwing
an error.  Attached is a patch that fixes the problem and adds covering
tests.  The full test suite passed on OS X 10.6.5 and I ran
'./python.exe -m test -R : -v test_ctype' to verify that I didn't
introduce any resource leaks.

----------
assignee: theller -> 
keywords: +patch
nosy: +amaury.forgeotdarc, belopolsky, meador.inge -theller
stage:  -> patch review
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21701/issue-11241.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11241>
_______________________________________

From report at bugs.python.org  Mon Apr 18 03:20:47 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 18 Apr 2011 01:20:47 +0000
Subject: [issue10910] pyport.h FreeBSD/Mac OS X "fix" causes errors in C++
	compilation
In-Reply-To: <1295040100.28.0.0907494738582.issue10910@psf.upfronthosting.co.za>
Message-ID: <1303089647.11.0.346812766679.issue10910@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

This doesn't look like it has anything to to with the 'ctypes' library
component (http://docs.python.org/library/ctypes).  So I am removing
'ctypes' from the 'Components' selection.  Please correct me if I am
wrong ...

----------
components:  -Extension Modules, Library (Lib), Macintosh, Unicode, ctypes
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10910>
_______________________________________

From report at bugs.python.org  Mon Apr 18 04:45:11 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 18 Apr 2011 02:45:11 +0000
Subject: [issue11862] urlparse.ParseResult to have meaningful __str__
In-Reply-To: <1303064594.29.0.64850729087.issue11862@psf.upfronthosting.co.za>
Message-ID: <1303094711.96.0.780681319014.issue11862@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

What would be a 'meaning' __str__ or __unicode__ of urlparse.urlparse  and how would it be useful to you? 

I would think that people would except a tuple, list or a ParsedResult for such a call. 

I cannot understand the rational behind the expectation that __str__ or __unicode__ of ParsedResult to be equivalent to the geturl call.

If you can, please elaborate.

----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11862>
_______________________________________

From report at bugs.python.org  Mon Apr 18 04:55:14 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 18 Apr 2011 02:55:14 +0000
Subject: [issue10910] pyport.h FreeBSD/Mac OS X "fix" causes errors in C++
	compilation
In-Reply-To: <1295040100.28.0.0907494738582.issue10910@psf.upfronthosting.co.za>
Message-ID: <1303095314.53.0.568595083527.issue10910@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
components: +Macintosh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10910>
_______________________________________

From report at bugs.python.org  Mon Apr 18 05:40:45 2011
From: report at bugs.python.org (ysj.ray)
Date: Mon, 18 Apr 2011 03:40:45 +0000
Subject: [issue11785] email subpackages documentation problems
In-Reply-To: <1302105466.45.0.930997240631.issue11785@psf.upfronthosting.co.za>
Message-ID: <1303098045.35.0.505041501436.issue11785@psf.upfronthosting.co.za>


ysj.ray <ysj.ray at gmail.com> added the comment:

Oh, sorry, I didn't differ :mod:, :module:, :currentmodule: clearly.

But shouldn't the modules link titles in http://docs.python.org/dev/library/email.html display correct module names instead just the "email" package name?
"""email: Representing character sets""" seems a little wearied.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11785>
_______________________________________

From report at bugs.python.org  Mon Apr 18 08:42:50 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 18 Apr 2011 06:42:50 +0000
Subject: [issue11241] ctypes: subclassing an already subclassed ArrayType
	generates AttributeError
In-Reply-To: <1297987167.42.0.900007110424.issue11241@psf.upfronthosting.co.za>
Message-ID: <1303108970.28.0.904884117264.issue11241@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

In the patch, _length_ is searched in the class and its base class. But what happens with a third level?
class my_array3(my_array2):
    pass

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11241>
_______________________________________

From report at bugs.python.org  Mon Apr 18 08:51:14 2011
From: report at bugs.python.org (Zhiping Deng)
Date: Mon, 18 Apr 2011 06:51:14 +0000
Subject: [issue11865] typo in Py_AddPendingCall document
In-Reply-To: <1303109474.81.0.645690585196.issue11865@psf.upfronthosting.co.za>
Message-ID: <1303109474.81.0.645690585196.issue11865@psf.upfronthosting.co.za>


New submission from Zhiping Deng <kofreestyler at gmail.com>:

http://docs.python.org/c-api/init.html?highlight=py_addpendingcall#Py_AddPendingCall

void Py_AddPendingCall(int (*func)(void *, void *arg))
which should be 
void Py_AddPendingCall(int (*func)(void *), void *arg)

----------
assignee: docs at python
components: Documentation
messages: 133953
nosy: Zhiping.Deng, docs at python
priority: normal
severity: normal
status: open
title: typo in Py_AddPendingCall document
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11865>
_______________________________________

From report at bugs.python.org  Mon Apr 18 09:15:11 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Apr 2011 07:15:11 +0000
Subject: [issue11865] typo in Py_AddPendingCall document
In-Reply-To: <1303109474.81.0.645690585196.issue11865@psf.upfronthosting.co.za>
Message-ID: <E1QBifu-0000Ng-CC@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset fc2def15ab11 by Ezio Melotti in branch '2.7':
#11865: fix typo in init.rst.
http://hg.python.org/cpython/rev/fc2def15ab11

New changeset 6e090d78857c by Ezio Melotti in branch '3.1':
#11865: fix typo in init.rst.
http://hg.python.org/cpython/rev/6e090d78857c

New changeset ce804653c752 by Ezio Melotti in branch '3.2':
#11865: Merge with 3.1.
http://hg.python.org/cpython/rev/ce804653c752

New changeset d8dd02f6db1a by Ezio Melotti in branch 'default':
#11865: Merge with 3.2.
http://hg.python.org/cpython/rev/d8dd02f6db1a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11865>
_______________________________________

From report at bugs.python.org  Mon Apr 18 09:16:12 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 18 Apr 2011 07:16:12 +0000
Subject: [issue11865] typo in Py_AddPendingCall document
In-Reply-To: <1303109474.81.0.645690585196.issue11865@psf.upfronthosting.co.za>
Message-ID: <1303110972.88.0.882210124933.issue11865@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11865>
_______________________________________

From report at bugs.python.org  Mon Apr 18 10:23:51 2011
From: report at bugs.python.org (Christoph Gohlke)
Date: Mon, 18 Apr 2011 08:23:51 +0000
Subject: [issue11835] python (x64) ctypes incorrectly pass structures parameter
In-Reply-To: <1302622766.46.0.0398461644853.issue11835@psf.upfronthosting.co.za>
Message-ID: <1303115031.62.0.520262476351.issue11835@psf.upfronthosting.co.za>


Changes by Christoph Gohlke <cgohlke at uci.edu>:


----------
nosy: +cgohlke

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11835>
_______________________________________

From report at bugs.python.org  Mon Apr 18 12:01:26 2011
From: report at bugs.python.org (kaifeng)
Date: Mon, 18 Apr 2011 10:01:26 +0000
Subject: [issue11849] ElementTree memory leak
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1303120886.8.0.944542755923.issue11849@psf.upfronthosting.co.za>


kaifeng <cafeeee at gmail.com> added the comment:

Found a minor defect of Python 3.2 / 3.3: line 1676 of xml/etree/ElementTree.py
was:
    del self.target, self._parser # get rid of circular references
should be:
    del self.target, self._target, self.parser, self._parser # get rid of circular references

While it doesn't help this issue...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Mon Apr 18 12:02:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Apr 2011 10:02:12 +0000
Subject: [issue11768] test_signals() of test_threadsignals failure on Mac OS X
In-Reply-To: <1301962757.99.0.598461435574.issue11768@psf.upfronthosting.co.za>
Message-ID: <1303120932.5.0.749044510538.issue11768@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It looks like pthread_mutex_lock() and pthread_mutex_unlock() are not reentrant on some platforms (in some implementations of the pthread API).

Antoine: if I understand correctly your patch, if we have a pending signal, all next signals will be simply ignored.

I think that this issue is not specific to Mac OS X: signal_handler() can be called twice at the same time in two different threads or in the same thread (reentrant call).

pthread_sigmask() can be used to avoid reentrant call, but it has no effect on the second case: "signal_handler() called twice at the same time in two different threads".

Note: SA_NODEFER flag of sigaction() has no effect on this issue because signal_handler() is called twice to handle two different signals (SIGUSR1 and SIGUSR2).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11768>
_______________________________________

From report at bugs.python.org  Mon Apr 18 12:17:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Apr 2011 10:17:14 +0000
Subject: [issue11768] test_signals() of test_threadsignals failure on Mac OS X
In-Reply-To: <1303120932.5.0.749044510538.issue11768@psf.upfronthosting.co.za>
Message-ID: <1303121831.3472.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine: if I understand correctly your patch, if we have a pending
> signal, all next signals will be simply ignored.

I don't think so, please re-read.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11768>
_______________________________________

From report at bugs.python.org  Mon Apr 18 12:19:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Apr 2011 10:19:00 +0000
Subject: [issue11768] test_signals() of test_threadsignals failure on Mac OS X
In-Reply-To: <1301962757.99.0.598461435574.issue11768@psf.upfronthosting.co.za>
Message-ID: <1303121940.82.0.172655754994.issue11768@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> pthread_sigmask() can be used to avoid reentrant call, 
> but it has no effect on the second case: "signal_handler() 
> called twice at the same time in two different threads".

Same problem if we use sa_mask field of sigaction() (e.g. use sigfillset(&context.sa_mask); in PyOS_setsig()).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11768>
_______________________________________

From report at bugs.python.org  Mon Apr 18 12:40:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Apr 2011 10:40:31 +0000
Subject: [issue11768] test_signals() of test_threadsignals failure on Mac OS X
In-Reply-To: <1301962757.99.0.598461435574.issue11768@psf.upfronthosting.co.za>
Message-ID: <1303123231.01.0.0893225357862.issue11768@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I don't think so, please re-read.

Oh, I thought that Py_AddPendingCall() was used to store the pending signal. But no, it asks Python main loop to check which signal has been trigerred, and we can only do it once for all signals.

Attached patch should fix this issue:

 - signal_handler() and PyErr_SetInterrupt() only call Py_AddPendingCall() on the first signal (if is_tripped is zero): it should fix the deadlock and it is a micro optimization (win-win !)
 - PyErr_SetInterrupt() uses the wake up API (write "\0" into wakeup_fd, API introduced by issue #1583)
 - Remove debug code in test_threadsignals

Python 2.7 (and 2.6?) should also be patched: signal.set_wakeup_fd() and PySignal_SetWakeupFd() were introduced in 2.6, but there is no versionadded tag => signal_versionadded.patch

----------
keywords: +patch
Added file: http://bugs.python.org/file21702/signal_reentrant.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11768>
_______________________________________

From report at bugs.python.org  Mon Apr 18 12:42:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Apr 2011 10:42:02 +0000
Subject: [issue11768] signal_handler() is not reentrant: deadlock in
	Py_AddPendingCall()
In-Reply-To: <1301962757.99.0.598461435574.issue11768@psf.upfronthosting.co.za>
Message-ID: <1303123322.08.0.8089673331.issue11768@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: test_signals() of test_threadsignals failure on Mac OS X -> signal_handler() is not reentrant: deadlock in Py_AddPendingCall()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11768>
_______________________________________

From report at bugs.python.org  Mon Apr 18 12:52:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Apr 2011 10:52:49 +0000
Subject: [issue11768] test_signals() of test_threadsignals failure on Mac OS X
In-Reply-To: <1303123231.01.0.0893225357862.issue11768@psf.upfronthosting.co.za>
Message-ID: <1303123970.27664.6.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le lundi 18 avril 2011 ? 10:40 +0000, STINNER Victor a ?crit :
> Attached patch should fix this issue:
> 
>  - signal_handler() and PyErr_SetInterrupt() only call Py_AddPendingCall() on the first signal (if is_tripped is zero): it should fix the deadlock and it is a micro optimization (win-win !)

Tested on OSX: yes, it does fix this issue.

Should I apply the fix on 2.7, 3.1, 3.2 and 3.3? (or only 3.3)

----------
title: signal_handler() is not reentrant: deadlock in Py_AddPendingCall() -> test_signals() of test_threadsignals failure on Mac OS X

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11768>
_______________________________________

From report at bugs.python.org  Mon Apr 18 12:57:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Apr 2011 10:57:11 +0000
Subject: [issue11768] test_signals() of test_threadsignals failure on Mac OS X
In-Reply-To: <1301962757.99.0.598461435574.issue11768@psf.upfronthosting.co.za>
Message-ID: <1303124231.74.0.876520630098.issue11768@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file21703/signal_versionadded.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11768>
_______________________________________

From report at bugs.python.org  Mon Apr 18 12:59:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Apr 2011 10:59:13 +0000
Subject: [issue11768] signal_handler() is not reentrant: deadlock in
	Py_AddPendingCall()
In-Reply-To: <1301962757.99.0.598461435574.issue11768@psf.upfronthosting.co.za>
Message-ID: <1303124353.75.0.559518505443.issue11768@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: test_signals() of test_threadsignals failure on Mac OS X -> signal_handler() is not reentrant: deadlock in Py_AddPendingCall()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11768>
_______________________________________

From report at bugs.python.org  Mon Apr 18 13:18:28 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 18 Apr 2011 11:18:28 +0000
Subject: [issue11861] 2to3 fails with a ParseError
In-Reply-To: <1303045938.22.0.287313368996.issue11861@psf.upfronthosting.co.za>
Message-ID: <1303125508.45.0.732475633403.issue11861@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This file has a SyntaxError!
A comma is certainly missing at the end of line 47

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11861>
_______________________________________

From report at bugs.python.org  Mon Apr 18 13:29:03 2011
From: report at bugs.python.org (Peter Saveliev)
Date: Mon, 18 Apr 2011 11:29:03 +0000
Subject: [issue11866] race condition in threading._newname()
In-Reply-To: <1303126142.97.0.491583907596.issue11866@psf.upfronthosting.co.za>
Message-ID: <1303126142.97.0.491583907596.issue11866@psf.upfronthosting.co.za>


New submission from Peter Saveliev <svinota.saveliev at gmail.com>:

The _newname() function has no locking.

It is called from the new thread constructor. Such constructor is executed within parent thread. So, when several threads create new threads simultaneously, there can be race condition, leading to the same name for two (or even more) threads.

8<--------------------------------

>>> import threading
>>> import dis
>>> dis.dis(threading._newname)
403           0 LOAD_GLOBAL              0 (_counter)
              3 LOAD_CONST               1 (1)
              6 BINARY_ADD         
              7 STORE_GLOBAL             0 (_counter)

404          10 LOAD_FAST                0 (template)
             13 LOAD_GLOBAL              0 (_counter)
             16 BINARY_MODULO      
             17 RETURN_VALUE       
>>> 
8<--------------------------------

The race condition can be achieved between BINARY_ADD and STORE_GLOBAL. Several threads can do BINARY_ADD before the first one will do STORE_GLOBAL. All racing threads will get the same name.

8<--------------------------------
$ for i in `seq 0 100`; do python thread_test.py |\
 awk -F Thread- '{print $2}' |\
 grep -vE '^$' |\
 sort |\
 uniq -c -d; done
      2 35
      2 12
      ...
8<--------------------------------

As you see, there are cases when several threads can get same name.

Proposals: use thread-safe increment counter (with atomic get-increment) like itertools.counter() (that does not release GIL)

----------
components: Extension Modules
files: thread_test.py
messages: 133963
nosy: Peter.Saveliev
priority: normal
severity: normal
status: open
title: race condition in threading._newname()
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file21704/thread_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11866>
_______________________________________

From report at bugs.python.org  Mon Apr 18 14:13:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Apr 2011 12:13:07 +0000
Subject: [issue11768] signal_handler() is not reentrant: deadlock in
	Py_AddPendingCall()
In-Reply-To: <1301962757.99.0.598461435574.issue11768@psf.upfronthosting.co.za>
Message-ID: <1303128787.37.0.344339014123.issue11768@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, since it is a bugfix, you should apply it to all versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11768>
_______________________________________

From report at bugs.python.org  Mon Apr 18 14:55:50 2011
From: report at bugs.python.org (Tomasz Melcer)
Date: Mon, 18 Apr 2011 12:55:50 +0000
Subject: [issue11862] urlparse.ParseResult to have meaningful __str__
In-Reply-To: <1303064594.29.0.64850729087.issue11862@psf.upfronthosting.co.za>
Message-ID: <1303131350.65.0.0180303514479.issue11862@psf.upfronthosting.co.za>


Tomasz Melcer <liori at o2.pl> added the comment:

If __str__ is meant to be a user-understandable way of expressing an URL, the best way to do that is to show it the same way user sees it in usually. This is now done by .geturl() call.

This way I wouldn't have to remember to serialize it in cases where I want to display an URL to user:

    url = urlparse.urlparse(sys.args[1])
    ...
    print "Downloading {1}".format(url)

would mean: "show me that URL".

And if you would like to display its internal representation as a record of scheme/host/path/..., you always have __repr__. Currently both __str__ and __repr__ return `ParsedResult(scheme="http", netloc='example.com', ...)`

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11862>
_______________________________________

From report at bugs.python.org  Mon Apr 18 15:01:55 2011
From: report at bugs.python.org (=?utf-8?q?Ernst_Sj=C3=B6strand?=)
Date: Mon, 18 Apr 2011 13:01:55 +0000
Subject: [issue5115] Extend subprocess.kill to be able to kill process groups
In-Reply-To: <1233370260.58.0.70597374825.issue5115@psf.upfronthosting.co.za>
Message-ID: <1303131715.52.0.972638095008.issue5115@psf.upfronthosting.co.za>


Changes by Ernst Sj?strand <ernstp at gmail.com>:


----------
nosy: +Ernst.Sj?strand

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5115>
_______________________________________

From report at bugs.python.org  Mon Apr 18 15:06:25 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 18 Apr 2011 13:06:25 +0000
Subject: [issue5115] Extend subprocess.kill to be able to kill process groups
In-Reply-To: <1233370260.58.0.70597374825.issue5115@psf.upfronthosting.co.za>
Message-ID: <1303131985.48.0.379146760302.issue5115@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
versions: +Python 3.3 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5115>
_______________________________________

From report at bugs.python.org  Mon Apr 18 15:16:31 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 18 Apr 2011 13:16:31 +0000
Subject: [issue11862] urlparse.ParseResult to have meaningful __str__
In-Reply-To: <1303064594.29.0.64850729087.issue11862@psf.upfronthosting.co.za>
Message-ID: <1303132591.03.0.610645551648.issue11862@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Tomasz,

I think, you misunderstood the purpose of urlparse library. urlparse is for parsing the URL and into its components. The url could be a mailto:, svn+ssh or http,https. The requirement for parsing comes when you are designing systems which take up URL and you need to do parse it for certain purposes for your application and then do action based on the parsed result.  That is why there are parse,unparse,split, unsplit functions provided.

If you have to get the original url back it is reverse call, send the parsed result to urlunparse.

The urllib, which provides facilties for doing http at higher level provides you geturl (which is getting the url from the header values).

I don't see the use of __str__ or __unicode__ for parse library. I am closing this report as Invalid.

Thank you.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11862>
_______________________________________

From report at bugs.python.org  Mon Apr 18 15:19:04 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Apr 2011 13:19:04 +0000
Subject: [issue11867] Make test_mailbox deterministic
In-Reply-To: <1303132744.64.0.479347573965.issue11867@psf.upfronthosting.co.za>
Message-ID: <1303132744.64.0.479347573965.issue11867@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Attached is a patch to remove the last sleeps from test_mailbox.  I believe this makes the test suite deterministic.  It also shaves 4 seconds of fixed overhead off the test run time.

----------
components: Tests
files: mailbox_fork_with_ipc.patch
keywords: buildbot, patch
messages: 133967
nosy: r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Make test_mailbox deterministic
type: resource usage
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21705/mailbox_fork_with_ipc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11867>
_______________________________________

From report at bugs.python.org  Mon Apr 18 15:31:52 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Apr 2011 13:31:52 +0000
Subject: [issue11867] Make test_mailbox deterministic
In-Reply-To: <1303132744.64.0.479347573965.issue11867@psf.upfronthosting.co.za>
Message-ID: <1303133512.82.0.194722918125.issue11867@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11867>
_______________________________________

From report at bugs.python.org  Mon Apr 18 15:44:50 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Apr 2011 13:44:50 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1303134290.73.0.152524305923.issue11828@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Mon Apr 18 16:03:24 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 18 Apr 2011 14:03:24 +0000
Subject: [issue11241] ctypes: subclassing an already subclassed ArrayType
	generates AttributeError
In-Reply-To: <1297987167.42.0.900007110424.issue11241@psf.upfronthosting.co.za>
Message-ID: <1303135404.52.0.386999203844.issue11241@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> But what happens with a third level?

That doesn't work.  I have a test case for that, but the test case has
a typo that caused it to pass.  I will fix the test case and the code.
Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11241>
_______________________________________

From report at bugs.python.org  Mon Apr 18 16:12:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Apr 2011 14:12:31 +0000
Subject: [issue11492] email.header.Header doesn't fold headers correctly
In-Reply-To: <1300087978.39.0.703069545984.issue11492@psf.upfronthosting.co.za>
Message-ID: <E1QBpBk-0001MZ-Ll@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 51a551acb60d by R David Murray in branch '3.2':
#11492: rewrite header folding algorithm.  Less code, more passing tests.
http://hg.python.org/cpython/rev/51a551acb60d

New changeset fcd20a565b95 by R David Murray in branch 'default':
Merge: #11492: rewrite header folding algorithm.  Less code, more passing tests.
http://hg.python.org/cpython/rev/fcd20a565b95

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11492>
_______________________________________

From report at bugs.python.org  Mon Apr 18 16:27:32 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Apr 2011 14:27:32 +0000
Subject: [issue11492] email.header.Header doesn't fold headers correctly
In-Reply-To: <1300087978.39.0.703069545984.issue11492@psf.upfronthosting.co.za>
Message-ID: <1303136852.03.0.702469553575.issue11492@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11492>
_______________________________________

From report at bugs.python.org  Mon Apr 18 16:30:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Apr 2011 14:30:29 +0000
Subject: [issue11768] signal_handler() is not reentrant: deadlock in
	Py_AddPendingCall()
In-Reply-To: <1301962757.99.0.598461435574.issue11768@psf.upfronthosting.co.za>
Message-ID: <E1QBpT7-00039T-0G@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 319f7af9ee5e by Victor Stinner in branch '3.1':
Issue #11768: The signal handler of the signal module only calls
http://hg.python.org/cpython/rev/319f7af9ee5e

New changeset 28ab8c6ad8f9 by Victor Stinner in branch '3.2':
(Merge 3.1) Issue #11768: The signal handler of the signal module only calls
http://hg.python.org/cpython/rev/28ab8c6ad8f9

New changeset fdcbc8453304 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #11768: The signal handler of the signal module only calls
http://hg.python.org/cpython/rev/fdcbc8453304

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11768>
_______________________________________

From report at bugs.python.org  Mon Apr 18 16:34:34 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Apr 2011 14:34:34 +0000
Subject: [issue11768] signal_handler() is not reentrant: deadlock in
	Py_AddPendingCall()
In-Reply-To: <1301962757.99.0.598461435574.issue11768@psf.upfronthosting.co.za>
Message-ID: <E1QBpX7-0003SO-B0@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7d355c2ff3d4 by Victor Stinner in branch '2.7':
(Merge 3.1) Issue #11768: The signal handler of the signal module only calls
http://hg.python.org/cpython/rev/7d355c2ff3d4

New changeset ebd080593351 by Victor Stinner in branch '2.7':
Issue #11768: signal.set_wakeup_fd() and PySignal_SetWakeupFd() added in 2.6
http://hg.python.org/cpython/rev/ebd080593351

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11768>
_______________________________________

From report at bugs.python.org  Mon Apr 18 16:45:34 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Apr 2011 14:45:34 +0000
Subject: [issue8769] Straightforward usage of email package fails to round-trip
In-Reply-To: <1274302519.83.0.146401120937.issue8769@psf.upfronthosting.co.za>
Message-ID: <1303137934.11.0.848116693483.issue8769@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is fixed in 3.2/3.3 by the fix for issue 11492.  The suggested fix for 2.7 is more radical than I'm comfortable with for a point release. I'm open to argument on that, but in the meantime I'm closing the issue with 11492 as the superseder.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> email.header.Header doesn't fold headers correctly

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8769>
_______________________________________

From report at bugs.python.org  Mon Apr 18 16:48:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Apr 2011 14:48:13 +0000
Subject: [issue11768] signal_handler() is not reentrant: deadlock in
	Py_AddPendingCall()
In-Reply-To: <1301962757.99.0.598461435574.issue11768@psf.upfronthosting.co.za>
Message-ID: <1303138093.35.0.352271765412.issue11768@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The deadlock is fixed. Reopen the issue if you still see test_threadsignals hang on a buildbot.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11768>
_______________________________________

From report at bugs.python.org  Mon Apr 18 17:05:41 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Apr 2011 15:05:41 +0000
Subject: [issue1372770] email.Header should preserve original FWS
Message-ID: <1303139141.68.0.946081666031.issue1372770@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

As of the fix for issue 11492, the email package only uses continuation_ws when folding RFC2047 encoded words.  So I consider this issue fixed.  (I have, by the way, come around to the view that we should never be introducing or deleting whitespace except when RFC 2047 encoding/decoding...we are still deleting it in a couple places, and I will address that by and by).

----------
components: +Library (Lib) -Extension Modules
resolution:  -> duplicate
stage: test needed -> committed/rejected
status: open -> closed
superseder:  -> email.header.Header doesn't fold headers correctly

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1372770>
_______________________________________

From report at bugs.python.org  Mon Apr 18 17:11:16 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Apr 2011 15:11:16 +0000
Subject: [issue5612] whitespace folding in the email package could be better ; 
	-)
In-Reply-To: <1238437516.03.0.51001864383.issue5612@psf.upfronthosting.co.za>
Message-ID: <1303139476.63.0.28776696897.issue5612@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This now works correctly in 3.2/3.3 (see issue 11492).  Note that the whitespace compression is too deeply embeded in the 2.7 email package for there to be any way to fix it there.

----------
resolution:  -> duplicate
stage: test needed -> committed/rejected
status: open -> closed
superseder:  -> email.header.Header doesn't fold headers correctly

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5612>
_______________________________________

From report at bugs.python.org  Mon Apr 18 17:23:46 2011
From: report at bugs.python.org (Torsten Becker)
Date: Mon, 18 Apr 2011 15:23:46 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1303140226.99.0.909778934736.issue11828@psf.upfronthosting.co.za>


Torsten Becker <torsten.becker at gmail.com> added the comment:

I pushed my changes to a hg repository, they are in the two branches "startswith-slices-issue11828-2.7" and "startswith-slices-issue11828-3.1".

----------
hgrepos: +21

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Mon Apr 18 17:26:06 2011
From: report at bugs.python.org (Torsten Becker)
Date: Mon, 18 Apr 2011 15:26:06 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1303140366.31.0.518804192329.issue11828@psf.upfronthosting.co.za>


Changes by Torsten Becker <torsten.becker at gmail.com>:


Added file: http://bugs.python.org/file21706/2b48fd451c85.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Mon Apr 18 17:27:05 2011
From: report at bugs.python.org (Torsten Becker)
Date: Mon, 18 Apr 2011 15:27:05 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1303140425.86.0.175092403148.issue11828@psf.upfronthosting.co.za>


Changes by Torsten Becker <torsten.becker at gmail.com>:


----------
hgrepos: +22

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Mon Apr 18 17:29:01 2011
From: report at bugs.python.org (Torsten Becker)
Date: Mon, 18 Apr 2011 15:29:01 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1303140541.79.0.511925870195.issue11828@psf.upfronthosting.co.za>


Changes by Torsten Becker <torsten.becker at gmail.com>:


Removed file: http://bugs.python.org/file21706/2b48fd451c85.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Mon Apr 18 17:43:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Apr 2011 15:43:46 +0000
Subject: [issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1303141426.83.0.956016350402.issue8407@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Mon Apr 18 18:00:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Apr 2011 16:00:16 +0000
Subject: [issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1303142416.82.0.51113181918.issue8407@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

sigprocmask or (better) pthread_sigmask is required to fix #11859 bug.

---

Python has a test for "broken pthread_sigmask". Extract of configure.in:

      AC_MSG_CHECKING(if PTHREAD_SCOPE_SYSTEM is supported)
      AC_CACHE_VAL(ac_cv_pthread_system_supported,
      [AC_RUN_IFELSE([AC_LANG_SOURCE([[#include <pthread.h>
      void *foo(void *parm) {
        return NULL;
      }
      main() {
        pthread_attr_t attr;
        pthread_t id;
        if (pthread_attr_init(&attr)) exit(-1);
        if (pthread_attr_setscope(&attr, PTHREAD_SCOPE_SYSTEM)) exit(-1);
        if (pthread_create(&id, &attr, foo, NULL)) exit(-1);
        exit(0);
      }]])],
      [ac_cv_pthread_system_supported=yes],
      [ac_cv_pthread_system_supported=no],
      [ac_cv_pthread_system_supported=no])
      ])
      AC_MSG_RESULT($ac_cv_pthread_system_supported)
      if test "$ac_cv_pthread_system_supported" = "yes"; then
        AC_DEFINE(PTHREAD_SYSTEM_SCHED_SUPPORTED, 1, [Defined if PTHREAD_SCOPE_SYSTEM supported.])
      fi
      AC_CHECK_FUNCS(pthread_sigmask,
        [case $ac_sys_system in
        CYGWIN*)
          AC_DEFINE(HAVE_BROKEN_PTHREAD_SIGMASK, 1,
            [Define if pthread_sigmask() does not work on your system.])
            ;;
        esac])

Extract of Python/thread_pthread.h:

/* On platforms that don't use standard POSIX threads pthread_sigmask()
 * isn't present.  DEC threads uses sigprocmask() instead as do most
 * other UNIX International compliant systems that don't have the full
 * pthread implementation.
 */
#if defined(HAVE_PTHREAD_SIGMASK) && !defined(HAVE_BROKEN_PTHREAD_SIGMASK)
#  define SET_THREAD_SIGMASK pthread_sigmask
#else
#  define SET_THREAD_SIGMASK sigprocmask
#endif

---

Because today more and more programs rely on threads, it is maybe not a good idea to provide a binding of sigprocmask(). I would prefer to only add pthread_sigmask() which has a determistic behaviour with threads. So only compile signal.pthread_sigmask() if pthread API is present and pthread_sigmask "is not broken".

---

About the patch: the doc should explain that the signal masks are inherited for child processes (fork() and execve()). I don't know if this behaviour is specific to Linux or not.

If we only use pthread_sigmask(), the doc is wrong: "Set the signal mask for the process." It's not for the process but only for the current thread.

How does it work if I change the signal mask of the main thread and then I create a new thread: the signal mask is inherited, or a default mask is used instead?

---

The new faulthandler uses a thread to implement a timeout: the thread uses pthread_sigmask() or sigprocmask() to ignore all signals. If I don't set the signal mask, some tests fail: check that a system call (like reading from a pipe) can be interrupted by signal. The problem is that signal may be send to the faulthandler thread, instead of the main thread. Hum, while I'm writing this, I realize that I should maybe not fallback to sigprocmask() because it may mask signals for the whole process (all threads)!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Mon Apr 18 18:09:45 2011
From: report at bugs.python.org (Carl Meyer)
Date: Mon, 18 Apr 2011 16:09:45 +0000
Subject: [issue11868] Minor word-choice improvement in devguide "lifecycle of
	a patch" opening paragraph
In-Reply-To: <1303142985.47.0.930183800843.issue11868@psf.upfronthosting.co.za>
Message-ID: <1303142985.47.0.930183800843.issue11868@psf.upfronthosting.co.za>


New submission from Carl Meyer <carl at dirtcircle.com>:

The opening paragraph of the "lifecycle of a patch" devguide page contains a confusing parenthetical aside implying that an "svn-like" workflow would mean never *saving* anything to your working copy and using "hg diff" to generate a patch. This is obviously wrong given the usual meaning of "save": if you never save anything to your working copy, "hg diff" will be empty.

Patch attached with proposed alternative wording.

----------
components: Devguide
files: svn-like-wording.diff
keywords: patch
messages: 133978
nosy: carljm
priority: normal
severity: normal
status: open
title: Minor word-choice improvement in devguide "lifecycle of a patch" opening paragraph
versions: 3rd party
Added file: http://bugs.python.org/file21707/svn-like-wording.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11868>
_______________________________________

From report at bugs.python.org  Mon Apr 18 18:21:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Apr 2011 16:21:29 +0000
Subject: [issue11785] email subpackages documentation problems
In-Reply-To: <1302105466.45.0.930997240631.issue11785@psf.upfronthosting.co.za>
Message-ID: <1303143689.4.0.097041435327.issue11785@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Sure, +1 on using the submodule name in the module or currentmodule directive.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11785>
_______________________________________

From report at bugs.python.org  Mon Apr 18 18:41:04 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Mon, 18 Apr 2011 16:41:04 +0000
Subject: [issue11849] ElementTree memory leak
In-Reply-To: <1303087049.93.0.497125129893.issue11849@psf.upfronthosting.co.za>
Message-ID: <BANLkTik7DLmP8hAbG_Gu9GXzpJGiGT1BkQ@mail.gmail.com>


Charles-Francois Natali <neologix at free.fr> added the comment:

> kaifeng <cafeeee at gmail.com> added the comment:
>
> I added 'malloc_trim' to the test code and rerun the test with Python 2.5 / 3.2 on CentOS 5.3. ?The problem still exists.
>

Well, malloc_trim can fail, but how did you "add" it ? Did you use
patch to apply the diff ?
Also, could you post the output of a
ltrace -e malloc_trim python <test script>

For info, the sample outputs I posted above come from a RHEL6 box.

Anyway, I'm 99% sure this isn't a leak but a malloc issue (valgrind
--tool=memcheck could confirm this if you want to try, I could be
wrong, it wouldn't be the first time ;-) ).
By the way, look at what I just found:
http://mail.gnome.org/archives/xml/2008-February/msg00003.html

> Antoine Pitrou <pitrou at free.fr> added the comment:
> That's an interesting thing, perhaps you want to open a feature request as a separate issue?

Dunno.
Memory management is a domain which belongs to the operating
system/libc, and I think applications should mess with it (apart from
specific cases) .
I don't have time to look at this precise problem in greater detail
right now, but AFAICT, this looks either like a glibc bug, or at least
a corner case with default malloc parameters (M_TRIM_THRESHOLD and
friends), affecting only RHEL and derived distributions.
malloc_trim should be called automatically by free if the amount of
memory that could be release is above M_TRIM_THRESHOLD.
Calling it systematically can have a non-negligible performance impact.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Mon Apr 18 18:45:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Apr 2011 16:45:56 +0000
Subject: [issue10932] distutils.core.setup - data_files misbehaviour ?
In-Reply-To: <1295353825.23.0.755300594789.issue10932@psf.upfronthosting.co.za>
Message-ID: <1303145156.05.0.518842090843.issue10932@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The ?remote hg repo? is supposed to be the URI of a clone (not of a changeset) of cpython (not distutils2), so the repos you added don?t work.  Can you remove them and add a patch file instead?  Thanks.

The first changeset looks good; I don?t understand the second one.

> I'm not sure if I should modify test_command_sdist.py for the failing
> tests of manifest contents
Hm.  It looks like the tests were in contradiction with the docs.  The safest way here is to fix the behavior in packaging/d2 and mention the bug in the distutils docs.

> (since it is mentioned not to edit).
It?s a comment aimed at software developers reading the generated MANIFEST file, not at distutils2 hackers working on the tests :)  See #8688.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10932>
_______________________________________

From report at bugs.python.org  Mon Apr 18 18:56:56 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 18 Apr 2011 16:56:56 +0000
Subject: [issue11858] configparser.ExtendedInterpolation and section case
In-Reply-To: <1302972514.64.0.403074363027.issue11858@psf.upfronthosting.co.za>
Message-ID: <1303145816.29.0.169990771599.issue11858@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
assignee:  -> lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11858>
_______________________________________

From report at bugs.python.org  Mon Apr 18 19:09:58 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 18 Apr 2011 17:09:58 +0000
Subject: [issue11858] configparser.ExtendedInterpolation and section case
In-Reply-To: <1302972514.64.0.403074363027.issue11858@psf.upfronthosting.co.za>
Message-ID: <1303146598.94.0.342594600483.issue11858@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Thanks for the catch. I'll add some tests and push it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11858>
_______________________________________

From report at bugs.python.org  Mon Apr 18 19:17:21 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 18 Apr 2011 17:17:21 +0000
Subject: [issue11826] Leak in atexitmodule
In-Reply-To: <1302504979.95.0.857272040465.issue11826@psf.upfronthosting.co.za>
Message-ID: <1303147041.25.0.899376207829.issue11826@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It's the very first usage of PyModuleDef::m_free.
Martin, do you agree with the path?

----------
nosy: +amaury.forgeotdarc, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11826>
_______________________________________

From report at bugs.python.org  Mon Apr 18 19:19:12 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Mon, 18 Apr 2011 17:19:12 +0000
Subject: [issue9319] imp.find_module('test/badsyntax_pep3120') causes segfault
In-Reply-To: <1279693765.46.0.777254335316.issue9319@psf.upfronthosting.co.za>
Message-ID: <1303147152.96.0.518743857226.issue9319@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

How about applying the workaround patch to Python 3.2? An unprecise error message is way better than a segfault.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9319>
_______________________________________

From report at bugs.python.org  Mon Apr 18 19:25:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Apr 2011 17:25:22 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1303147522.82.0.686111753763.issue828450@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the patch.  Follow the ?review? link above to find my review.

+1 on making the smallest possible change.  The paths inside the Filelist/Manifest objects can continue to use os.sep, we only care about write_file for this bug.  Oh, and also read_file: can you add tests for MANIFEST reading?  It will be a bit more complicated: write a MANIFEST file with /-separated paths, set os.sep to \\, check that sdist works.  You should learn a lot about our tests helpers (mostly TempdirManager).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Mon Apr 18 19:42:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Apr 2011 17:42:24 +0000
Subject: =?utf-8?q?=5Bissue10946=5D_bdist_doesn=E2=80=99t_pass_--skip-build_on_to_?=
	=?utf-8?q?subcommands?=
In-Reply-To: <1295451169.68.0.9980803941.issue10946@psf.upfronthosting.co.za>
Message-ID: <1303148544.59.0.251843023564.issue10946@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Could you please at least describe the test that you mentioned (link
> doesn't work).
I still have a local copy \o/.  Yannick?s patch looks like this:

    def test_skip_build(self):
        pkg_pth, dist = self.create_dist()

        # With the skip_build option, command.build is not called.
        cmd = bdist(dist)
        cmd.skip_build = True
        cmd.ensure_finalized()
        cmd.run()
        self.assertFalse(dist.have_run['build'])

        # Without skip_build option, command.build is called.
        cmd = bdist(dist)
        cmd.skip_build = False
        cmd.ensure_finalized()
        cmd.run()
        self.assertTrue(dist.have_run['build'])

> I added line that passes skip_build from bdist.py to its subcommands
> and it worked for me (at least for simple cases)
What about non-simple cases?  They need to work too.

>- base.py is not called.
(Assuming you meant ?build is not called?)

> Using set_undefined_options in install_* is definitely not safe,
> because it fails if parent process has not set skip_build.
Really?  Also, what is ?parent process??  Do you mean that it fails if the command used as source in set_undefined_options does not define the skip_build option in its user_options?

I?m not sure it?d be good to make the install_* skip_build option depend on (== set_undefined_options from) bdist?s skip_build.  I?ve written a bit of code to make testing interaction between commands easier (for example, to test that ?setup.py build bdist --skip-build install? runs the second install command without skip_build set to True), I should put it in the main repo so that it can be used for this bug.  Getting good test coverage before we change code is absolute requisite for those dark areas.  Removing the easy keyword :)

> Anyway test_skip_build() is still broken and needs a fix.
Okay, so maybe fix that first.

----------
keywords:  -easy
stage: needs patch -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10946>
_______________________________________

From report at bugs.python.org  Mon Apr 18 20:00:39 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Apr 2011 18:00:39 +0000
Subject: [issue11731] Simplify email API via 'policy' objects
In-Reply-To: <1301597340.87.0.239759427177.issue11731@psf.upfronthosting.co.za>
Message-ID: <E1QBskY-0004rZ-He@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 2f3fda9d3906 by R David Murray in branch 'default':
#11731: simplify/enhance parser/generator API by introducing policy objects.
http://hg.python.org/cpython/rev/2f3fda9d3906

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11731>
_______________________________________

From report at bugs.python.org  Mon Apr 18 20:31:51 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Apr 2011 18:31:51 +0000
Subject: [issue11868] Minor word-choice improvement in devguide "lifecycle of
	a patch" opening paragraph
In-Reply-To: <1303142985.47.0.930183800843.issue11868@psf.upfronthosting.co.za>
Message-ID: <1303151511.91.0.581567599731.issue11868@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for the improvement. Applied in changeset cc43ed7af5f2.

----------
nosy: +ned.deily
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11868>
_______________________________________

From report at bugs.python.org  Mon Apr 18 22:00:08 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Apr 2011 20:00:08 +0000
Subject: [issue11869] Include information about the bug tracker Rietveld code
	review tool
In-Reply-To: <1303156808.41.0.477083927136.issue11869@psf.upfronthosting.co.za>
Message-ID: <1303156808.41.0.477083927136.issue11869@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

As far as I can see, the developer's guide does not mention at all the new Rietveld code review tool integration with the Python bug tracker.  The guide should describe how the tool is expected to be used both by core developers reviewing submitted patches and by patch submitters.

----------
components: Devguide
messages: 133989
nosy: ned.deily
priority: normal
severity: normal
status: open
title: Include information about the bug tracker Rietveld code review tool

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11869>
_______________________________________

From report at bugs.python.org  Mon Apr 18 22:18:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Apr 2011 20:18:01 +0000
Subject: [issue11870] test_3_join_in_forked_from_thread() of test_threading
	hangs 1 hour on "x86 Ubuntu Shared 3.x"
In-Reply-To: <1303157880.98.0.834054534396.issue11870@psf.upfronthosting.co.za>
Message-ID: <1303157880.98.0.834054534396.issue11870@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

test_3_join_in_forked_from_thread() of test_threading failed on "x86 Ubuntu Shared 3.x" buildbot:
-----------------------------------
[201/354] test_threading
[41179 refs]
[40407 refs]
[40407 refs]
[40407 refs]
Timeout (1:00:00)!
Thread 0x404218c0:
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/subprocess.py", line 466 in _eintr_retry_call
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/subprocess.py", line 1486 in _try_wait
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/subprocess.py", line 1528 in wait
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_threading.py", line 455 in _run_and_join
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_threading.py", line 518 in test_3_join_in_forked_from_thread
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 442 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 494 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 105 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 67 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 105 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 67 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support.py", line 1078 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support.py", line 1166 in _run_suite
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support.py", line 1192 in run_unittest
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_threading.py", line 728 in test_main
  File "./Lib/test/regrtest.py", line 1041 in runtest_inner
  File "./Lib/test/regrtest.py", line 835 in runtest
  File "./Lib/test/regrtest.py", line 659 in main
  File "./Lib/test/regrtest.py", line 1619 in <module>
make: *** [buildbottest] Error 1
program finished with exit code 2
elapsedTime=4426.776675
http://www.python.org/dev/buildbot/all/builders/x86%20Ubuntu%20Shared%203.x/builds/3577/steps/test/logs/stdio
-----------------------------------

Code of the test:
----------------------------------
    def _run_and_join(self, script):
        script = """if 1:
            import sys, os, time, threading

            # a thread, which waits for the main program to terminate
            def joiningfunc(mainthread):
                mainthread.join()
                print('end of thread')
                # stdout is fully buffered because not a tty, we have to flush
                # before exit.
                sys.stdout.flush()
        \n""" + script

        p = subprocess.Popen([sys.executable, "-c", script], stdout=subprocess.PIPE)
        rc = p.wait() <~~~ HANG HERE?~~~~
        data = p.stdout.read().decode().replace('\r', '')
        p.stdout.close()
        self.assertEqual(data, "end of main\nend of thread\n")
        self.assertFalse(rc == 2, "interpreter was blocked")
        self.assertTrue(rc == 0, "Unexpected error")

    @unittest.skipUnless(hasattr(os, 'fork'), "needs os.fork()")
    def test_3_join_in_forked_from_thread(self):
        # Like the test above, but fork() was called from a worker thread
        # In the forked process, the main Thread object must be marked as stopped.

        # Skip platforms with known problems forking from a worker thread.
        # See http://bugs.python.org/issue3863.
        if sys.platform in ('freebsd4', 'freebsd5', 'freebsd6', 'netbsd5',
                           'os2emx'):
            raise unittest.SkipTest('due to known OS bugs on ' + sys.platform)
        script = """if 1:
            main_thread = threading.current_thread()
            def worker():
                childpid = os.fork()
                if childpid != 0:
                    os.waitpid(childpid, 0)
                    sys.exit(0)

                t = threading.Thread(target=joiningfunc,
                                     args=(main_thread,))
                print('end of main')
                t.start()
                t.join() # Should not block: main_thread is already stopped

            w = threading.Thread(target=worker)
            w.start()
            """
        self._run_and_join(script)
----------------------------------

----------
components: Tests
messages: 133990
nosy: haypo
priority: normal
severity: normal
status: open
title: test_3_join_in_forked_from_thread() of test_threading hangs 1 hour on "x86 Ubuntu Shared 3.x"
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11870>
_______________________________________

From report at bugs.python.org  Mon Apr 18 22:19:08 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 18 Apr 2011 20:19:08 +0000
Subject: [issue11869] Include information about the bug tracker Rietveld code
	review tool
In-Reply-To: <1303156808.41.0.477083927136.issue11869@psf.upfronthosting.co.za>
Message-ID: <1303157948.4.0.692362751901.issue11869@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/issue11869>
_______________________________________

From report at bugs.python.org  Mon Apr 18 22:20:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Apr 2011 20:20:32 +0000
Subject: [issue11779] test_mmap timeout (1 hour) on "AMD64 Snow Leopard 3.x"
	buildbot
In-Reply-To: <1302076762.26.0.815715887004.issue11779@psf.upfronthosting.co.za>
Message-ID: <1303158032.42.0.0864932705365.issue11779@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Hum, it does still fail with a timeout of 1 hour:
-------------------------------------------
[ 41/354] test_mmap
Timeout (1:00:00)!
Thread 0x00007fff70439ca0:
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/test_mmap.py", line 685 in test_large_offset
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/case.py", line 442 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/case.py", line 494 in __call__
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/support.py", line 1078 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/support.py", line 1166 in _run_suite
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/support.py", line 1192 in run_unittest
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/test_mmap.py", line 706 in test_main
  File "./Lib/test/regrtest.py", line 1041 in runtest_inner
  File "./Lib/test/regrtest.py", line 835 in runtest
  File "./Lib/test/regrtest.py", line 659 in main
  File "./Lib/test/regrtest.py", line 1619 in <module>
make: *** [buildbottest] Error 1
program finished with exit code 2
elapsedTime=4261.520698
-------------------------------------------
http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%203.x/builds/62/steps/test/logs/stdio

----------
resolution: out of date -> 
status: closed -> open
title: test_mmap timeout (30 min) on "AMD64 Snow Leopard 3.x" buildbot -> test_mmap timeout (1 hour) on "AMD64 Snow Leopard 3.x" buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11779>
_______________________________________

From report at bugs.python.org  Mon Apr 18 23:25:00 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 18 Apr 2011 21:25:00 +0000
Subject: [issue11863] Enforce PEP 11 - remove support for legacy systems
In-Reply-To: <1303085337.86.0.669937619549.issue11863@psf.upfronthosting.co.za>
Message-ID: <1303161900.69.0.518429383806.issue11863@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/issue11863>
_______________________________________

From report at bugs.python.org  Mon Apr 18 23:26:20 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Mon, 18 Apr 2011 21:26:20 +0000
Subject: [issue10888] os.stat(filepath).st_mode gives wrong 'executable
	permission' result
In-Reply-To: <1294751581.52.0.421644635374.issue10888@psf.upfronthosting.co.za>
Message-ID: <1303161980.36.0.512423030071.issue10888@psf.upfronthosting.co.za>


Sijin Joseph <sijinjoseph at gmail.com> added the comment:

>From reading http://support.microsoft.com/kb/899147 it does look like the .dll extension needs to have the "Read & Execute" permission in order to have code from the .dll be executed. It's odd that there isn't documentation that's easily searchable to confirm this.

Also what about scripts, .vbs, .ps1 etc. Should those be considered executables as well?

----------
nosy: +sijinjoseph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10888>
_______________________________________

From report at bugs.python.org  Mon Apr 18 23:42:31 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 18 Apr 2011 21:42:31 +0000
Subject: [issue10888] os.stat(filepath).st_mode gives wrong 'executable
	permission' result
In-Reply-To: <1294751581.52.0.421644635374.issue10888@psf.upfronthosting.co.za>
Message-ID: <1303162951.35.0.194765368801.issue10888@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Jeroen: I'm tempted to close this issue with no change. The code, as it stands, models what Microsoft does in it's CRT (see crt/src/stat.c:__tdtoxmode). There is also a straight-forward motivation to this: this is the list of extensions that you can pass to system() and friends (i.e. ultimately to CreateProcess, if cmd.exe can get involved).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10888>
_______________________________________

From report at bugs.python.org  Mon Apr 18 23:49:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Apr 2011 21:49:31 +0000
Subject: [issue11800] regrtest --timeout: apply the timeout on a function,
	not on the whole file
In-Reply-To: <1302213294.05.0.908920520464.issue11800@psf.upfronthosting.co.za>
Message-ID: <1303163371.97.0.17932681504.issue11800@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

A timeout of 60 minutes looks to be fine. Today I debuged a thread+signal issue which gave me an headache, so I prefer to close this issue: only add create thread per file, and not a thread per function.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11800>
_______________________________________

From report at bugs.python.org  Mon Apr 18 23:59:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Apr 2011 21:59:04 +0000
Subject: [issue11871] test_default_timeout() of test_threading.BarrierTests
	failure: BrokenBarrierError
In-Reply-To: <1303163944.05.0.666091618845.issue11871@psf.upfronthosting.co.za>
Message-ID: <1303163944.05.0.666091618845.issue11871@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

While trying to reproduce issue #11870 using "gdb -args ./python Lib/test/regrtest.py -F -v --timeout=600 test_threading", I had the following error on Linux:
----------------------
test_default_timeout (test.test_threading.BarrierTests) ... [Thread 0x7ffff1acf700 (LWP 27178) exited]
[New Thread 0x7ffff1acf700 (LWP 27181)]
[New Thread 0x7ffff12ce700 (LWP 27182)]
[New Thread 0x7ffff3c99700 (LWP 27183)]
[New Thread 0x7ffff325a700 (LWP 27184)]
Unhandled exception in thread started by <function task at 0x1302340>
Unhandled exception in thread started by <function task at 0x1302340>
Unhandled exception in thread started by <function task at 0x1302340>
Traceback (most recent call last):
Unhandled exception in thread started by <function task at 0x1302340>
  File "/home/haypo/prog/HG/cpython/Lib/test/lock_tests.py", line 37, in task
Traceback (most recent call last):
Traceback (most recent call last):
  File "/home/haypo/prog/HG/cpython/Lib/test/lock_tests.py", line 37, in task
Traceback (most recent call last):
  File "/home/haypo/prog/HG/cpython/Lib/test/lock_tests.py", line 37, in task
    f()
    f()
  File "/home/haypo/prog/HG/cpython/Lib/test/lock_tests.py", line 37, in task
  File "/home/haypo/prog/HG/cpython/Lib/test/lock_tests.py", line 838, in f
ERROR
----------------------

----------------------
ERROR: test_default_timeout (test.test_threading.BarrierTests)

Traceback (most recent call last):
  File "/home/haypo/prog/HG/cpython/Lib/test/lock_tests.py", line 843, in test_default_timeout
    self.run_threads(f)
  File "/home/haypo/prog/HG/cpython/Lib/test/lock_tests.py", line 672, in run_threads
    f()
  File "/home/haypo/prog/HG/cpython/Lib/test/lock_tests.py", line 838, in f
    i = barrier.wait()
  File "/home/haypo/prog/HG/cpython/Lib/threading.py", line 472, in wait
    self._enter() # Block while the barrier drains.
  File "/home/haypo/prog/HG/cpython/Lib/threading.py", line 496, in _enter
    raise BrokenBarrierError
threading.BrokenBarrierError
----------------------

The error occured on:

 * Ubuntu 10.04
 * Python 3.3 (2127df2c972e)
 * Intel(R) Core(TM)2 Quad  CPU   Q9300  @ 2.50GHz
 * 4 GB of memory

----------
components: Tests
messages: 133995
nosy: haypo
priority: normal
severity: normal
status: open
title: test_default_timeout() of test_threading.BarrierTests failure: BrokenBarrierError
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11871>
_______________________________________

From report at bugs.python.org  Tue Apr 19 00:26:12 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Apr 2011 22:26:12 +0000
Subject: [issue11779] test_mmap timeout (1 hour) on "AMD64 Snow Leopard 3.x"
	buildbot
In-Reply-To: <1302076762.26.0.815715887004.issue11779@psf.upfronthosting.co.za>
Message-ID: <1303165572.22.0.892657075363.issue11779@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Note that the various HFS variants, the default file system types on OS X, do not support sparse files at all. So any tests of large files require at some point that the system writes out all the data in the file.

http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPFileSystem/Articles/Comparisons.html

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11779>
_______________________________________

From report at bugs.python.org  Tue Apr 19 00:52:42 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Apr 2011 22:52:42 +0000
Subject: [issue11779] test_mmap timeout (1 hour) on "AMD64 Snow Leopard 3.x"
	buildbot
In-Reply-To: <1302076762.26.0.815715887004.issue11779@psf.upfronthosting.co.za>
Message-ID: <1303167162.17.0.947324168025.issue11779@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

That said, on my iMac (2.4 Ghz Intel Core 2 Duo):

$ time ./python -m test -v -u largefile test_mmap
[...]

----------------------------------------------------------------------
Ran 24 tests in 87.673s

OK
1 test OK.

real	1m27.875s
user	0m0.186s
sys	0m8.626s

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11779>
_______________________________________

From report at bugs.python.org  Tue Apr 19 00:57:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Apr 2011 22:57:31 +0000
Subject: [issue11779] test_mmap timeout (1 hour) on "AMD64 Snow Leopard 3.x"
	buildbot
In-Reply-To: <1302076762.26.0.815715887004.issue11779@psf.upfronthosting.co.za>
Message-ID: <1303167451.07.0.320712532328.issue11779@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

We can use the following function to check if the filesystem does support sparse files:

def support_sparse_file(directory):
    import tempfile

    with tempfile.NamedTemporaryFile(dir=directory) as tmpfile:
        # Create a file with a size of 1 byte but without content
        # (only zeros)
        with open(tmpfile.name, "wb") as f:
            f.truncate(1)
        filestat = os.stat(tmpfile.name)
        return (filestat.st_blocks == 0)

We may skip the test if the filesystem doesn't support sparse file... But I think that it is already the purpose of the "largefile" resource.

If this issue is not a bug, but just that the timeout is too low, we should use a bigger timeout on this specific buildbot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11779>
_______________________________________

From report at bugs.python.org  Tue Apr 19 01:07:30 2011
From: report at bugs.python.org (Alexander Boyd)
Date: Mon, 18 Apr 2011 23:07:30 +0000
Subject: [issue10042] total_ordering stack overflow
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1303168050.97.0.280457047547.issue10042@psf.upfronthosting.co.za>


Alexander Boyd <alex at opengroove.org> added the comment:

This is not fixed. The accepted fix doesn't take NotImplemented into account, with the result that comparing two mutually-incomparable objects whose ordering operations were generated with total_ordering causes a stack overflow instead of the expected "TypeError: unorderable types: Foo() op Bar()".

I've attached a fix for this. It properly takes NotImplemented into account. It also generates __eq__ from __ne__ and vice versa if only one of them exists.

----------
nosy: +javawizard
Added file: http://bugs.python.org/file21708/sane_total_ordering.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Tue Apr 19 01:12:37 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 18 Apr 2011 23:12:37 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1303168357.47.0.706187357476.issue11828@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Torsten, could you possibly publish branches too for 3.2 and default (3.3)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Tue Apr 19 01:14:23 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 18 Apr 2011 23:14:23 +0000
Subject: [issue10042] total_ordering stack overflow
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1303168463.03.0.15915689856.issue10042@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'm not sure that we really care about handling NotImplemented (practicality beats purity).  At some point, if someone writing a class wants complete control over the rich comparison methods, then they're going to have to write those methods.

----------
assignee: eric.araujo -> rhettinger
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Tue Apr 19 01:17:18 2011
From: report at bugs.python.org (Alexander Boyd)
Date: Mon, 18 Apr 2011 23:17:18 +0000
Subject: [issue10042] total_ordering stack overflow
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1303168638.3.0.163656349919.issue10042@psf.upfronthosting.co.za>


Alexander Boyd <alex at opengroove.org> added the comment:

But it seems pointless to force someone to implement all of the rich comparison methods when they may want to do something as simple as this:

class Foo:
    ...
    def __lt__(self, other):
        if not isinstance(other, Foo):
            return NotImplemented
        return self.some_value < other.some_value

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Tue Apr 19 01:28:37 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 18 Apr 2011 23:28:37 +0000
Subject: [issue5162] multiprocessing cannot spawn child from a Windows service
In-Reply-To: <1233885632.9.0.0484597105973.issue5162@psf.upfronthosting.co.za>
Message-ID: <1303169317.27.0.802818468843.issue5162@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5162>
_______________________________________

From report at bugs.python.org  Tue Apr 19 01:32:00 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 18 Apr 2011 23:32:00 +0000
Subject: [issue10042] total_ordering
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1303169520.17.0.284245598895.issue10042@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

It may seem pointless, but it takes less than a minute to do it and it would be both faster and clearer to do it manually.  There's a limit to how much implicit code generation can or should be done automatically.  

Also, I'm not too keen on the feature creep, or having the tool grow in complexity (making it harder to understand what it actually does).  I would also be concerned about subtly changing the semantics for code that may already be using total_ordering -- the proposed change is probably harmless in most cases with only a minor performance hit, but it might break some code that currently works. 

BTW, in Py3.x you get __ne__ for free whenever __eq__ is supplied.

----------
title: total_ordering stack overflow -> total_ordering
type: behavior -> feature request
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Tue Apr 19 01:33:31 2011
From: report at bugs.python.org (Alexander Boyd)
Date: Mon, 18 Apr 2011 23:33:31 +0000
Subject: [issue10042] total_ordering
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1303169611.78.0.717175635887.issue10042@psf.upfronthosting.co.za>


Alexander Boyd <alex at opengroove.org> added the comment:

Ok. I did write that against Python 2, so I wasn't aware of __eq__ and __ne__. I'll keep that in mind.

I am curious, however, as to how this could break existing code. It seems like code that relies on a stack overflow is already broken as it is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Tue Apr 19 01:39:50 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 18 Apr 2011 23:39:50 +0000
Subject: [issue10042] total_ordering
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1303169990.75.0.858671988078.issue10042@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> I am curious, however, as to how this could break existing code. 
> It seems like code that relies on a stack overflow is already 
> broken as it is.

Probably so.  I worry about changes in semantics but it might be harmless.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Tue Apr 19 01:44:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Apr 2011 23:44:21 +0000
Subject: [issue11779] test_mmap timeout (1 hour) on "AMD64 Snow Leopard 3.x"
	buildbot
In-Reply-To: <1302076762.26.0.815715887004.issue11779@psf.upfronthosting.co.za>
Message-ID: <1303170261.11.0.932515210124.issue11779@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Timing on the x86 Tiger buildbot: "time ./python.exe -m test -v -u largefile test_mmap" gives approx 5 minutes. The buildbot is a Mac mini, Intel Core Duo 1.8 GHz, 2 GB of memory, Mac OS X 10.4.10, HD: 232 GB (182 GB available) WDC WD2500BEVT-00A23T0.

/usr/sbin/system_profiler gives a lot of information about the OS and the hardware, great tool!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11779>
_______________________________________

From report at bugs.python.org  Tue Apr 19 02:22:13 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 19 Apr 2011 00:22:13 +0000
Subject: [issue11779] test_mmap timeout (1 hour) on "AMD64 Snow Leopard 3.x"
	buildbot
In-Reply-To: <1302076762.26.0.815715887004.issue11779@psf.upfronthosting.co.za>
Message-ID: <1303172533.88.0.652641752244.issue11779@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Maybe that buildbot machine is just overloaded.  If I understand the buildbot waterfall output correctly, it looks like there are often 4 simultaneous test runs happening on that machine, one each for 2.7, 3.1, 3.2 and 3.x.

http://www.python.org/dev/buildbot/all/waterfall?builder=AMD64+Snow+Leopard+3.x&builder=AMD64+Snow+Leopard+3.2&builder=AMD64+Snow+Leopard+3.1&builder=AMD64+Snow+Leopard+2.7&builder=AMD64+Snow+Leopard+custom&reload=none

Maybe the buildbot config could be changed to stagger the builds a bit?  Otherwise, perhaps it will often take a long time to run.  On my system, a full run of just 3.x with a similar ./configure and regrtest parameters takes about 30 minutes by itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11779>
_______________________________________

From report at bugs.python.org  Tue Apr 19 02:43:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Apr 2011 00:43:03 +0000
Subject: [issue11870] test_3_join_in_forked_from_thread() of test_threading
	hangs 1 hour on "x86 Ubuntu Shared 3.x"
In-Reply-To: <1303157880.98.0.834054534396.issue11870@psf.upfronthosting.co.za>
Message-ID: <1303173783.93.0.947877727315.issue11870@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +gps

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11870>
_______________________________________

From report at bugs.python.org  Tue Apr 19 04:41:39 2011
From: report at bugs.python.org (kaifeng)
Date: Tue, 19 Apr 2011 02:41:39 +0000
Subject: [issue11849] ElementTree memory leak
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1303180899.72.0.186167652301.issue11849@psf.upfronthosting.co.za>


kaifeng <cafeeee at gmail.com> added the comment:

I applied your patch to Python 3.2, also I added a function call to 'malloc_trim' via ctypes, as you can see in issue11849_test2.py.

In fact I have a daemon written in Python 2.5, parsing an XML of size 10+ MB every 5 minutes, after 16+ hours running, the program finally exhausted 4 GB memory and died.  I simplified the logic of the daemon and found ElementTree eats too much memory.  There comes the attached test script.

BTW, after utilize lxml instead of ElementTree, such phenomenon of increasing memory usage disappeared.


$ ltrace -e malloc_trim python3.2 Issue11849_test2.py
--- SIGCHLD (Child exited) ---
--- SIGCHLD (Child exited) ---
*** Python 3.2.0 final
--- SIGCHLD (Child exited) ---
---   PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
--- SIGCHLD (Child exited) ---
  0 13708 pts/1    S+     0:00      1    65  1742   636  0.0 ltrace -e malloc_trim python3.2 Issue11849_test2.py
13709 pts/1    S+     0:00      1  1316 11055  6440  0.6 python3.2 Issue11849_test2.py
--- SIGCHLD (Child exited) ---
  1 13708 pts/1    S+     0:00      1    65  1742   636  0.0 ltrace -e malloc_trim python3.2 Issue11849_test2.py
13709 pts/1    S+     0:03      1  1316 53155 47332  4.5 python3.2 Issue11849_test2.py
--- SIGCHLD (Child exited) ---
  2 13708 pts/1    S+     0:00      1    65  1742   636  0.0 ltrace -e malloc_trim python3.2 Issue11849_test2.py
13709 pts/1    S+     0:06      1  1316 91055 85204  8.2 python3.2 Issue11849_test2.py
--- SIGCHLD (Child exited) ---
  3 13708 pts/1    S+     0:01      1    65  1742   636  0.0 ltrace -e malloc_trim python3.2 Issue11849_test2.py
13709 pts/1    S+     0:10      1  1316 128947 124212 11.9 python3.2 Issue11849_test2.py
--- SIGCHLD (Child exited) ---
  4 13708 pts/1    S+     0:01      1    65  1742   636  0.0 ltrace -e malloc_trim python3.2 Issue11849_test2.py
13709 pts/1    S+     0:13      1  1316 166807 162280 15.6 python3.2 Issue11849_test2.py
--- SIGCHLD (Child exited) ---
  5 13708 pts/1    S+     0:01      1    65  1742   636  0.0 ltrace -e malloc_trim python3.2 Issue11849_test2.py
13709 pts/1    S+     0:16      1  1316 204483 198808 19.2 python3.2 Issue11849_test2.py
--- SIGCHLD (Child exited) ---
  6 13708 pts/1    S+     0:02      1    65  1742   636  0.0 ltrace -e malloc_trim python3.2 Issue11849_test2.py
13709 pts/1    S+     0:20      1  1316 242379 236672 22.8 python3.2 Issue11849_test2.py
--- SIGCHLD (Child exited) ---
  7 13708 pts/1    S+     0:02      1    65  1742   636  0.0 ltrace -e malloc_trim python3.2 Issue11849_test2.py
13709 pts/1    S+     0:23      1  1316 284383 277508 26.8 python3.2 Issue11849_test2.py
--- SIGCHLD (Child exited) ---
  8 13708 pts/1    S+     0:03      1    65  1742   636  0.0 ltrace -e malloc_trim python3.2 Issue11849_test2.py
13709 pts/1    S+     0:27      1  1316 318191 312436 30.1 python3.2 Issue11849_test2.py
--- SIGCHLD (Child exited) ---
  9 13708 pts/1    S+     0:03      1    65  1742   636  0.0 ltrace -e malloc_trim python3.2 Issue11849_test2.py
13709 pts/1    S+     0:29      1  1316 360199 353272 34.1 python3.2 Issue11849_test2.py
--- SIGCHLD (Child exited) ---
END 13708 pts/1    S+     0:03      1    65  1742   636  0.0 ltrace -e malloc_trim python3.2 Issue11849_test2.py
13709 pts/1    S+     0:34      1  1316 393975 388164 37.4 python3.2 Issue11849_test2.py
malloc_trim(0, 0, 0x818480a, 0x81a0114, 0xbfb6c940)                                              = 1
--- SIGCHLD (Child exited) ---
 GC 13708 pts/1    S+     0:03      1    65  1742   648  0.0 ltrace -e malloc_trim python3.2 Issue11849_test2.py
13709 pts/1    S+     0:35      1  1316 351871 347480 33.5 python3.2 Issue11849_test2.py
--- SIGCHLD (Child exited) ---
*** 13708 pts/1    S+     0:03      1    65  1742   648  0.0 ltrace -e malloc_trim python3.2 Issue11849_test2.py
13709 pts/1    S+     0:35      1  1316 351871 347480 33.5 python3.2 Issue11849_test2.py
+++ exited (status 0) +++

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Tue Apr 19 04:54:11 2011
From: report at bugs.python.org (Brian Cain)
Date: Tue, 19 Apr 2011 02:54:11 +0000
Subject: [issue8426] multiprocessing.Queue fails to get() very large objects
In-Reply-To: <1302684710.15.0.312275782078.issue8426@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=R8RmypH58bVCjaCnGSFskONRkzA@mail.gmail.com>


Brian Cain <brian.cain at gmail.com> added the comment:

Please don't close the issue.

Joining aside, the basic point ("But when size = 7279, the data submitted
reaches 64k, so the writting thread blocks on the write syscall.") is not
clear from the docs, right?

IMO, it would be nice if I could ask my queue, "Just what is your capacity
(in bytes, not entries) anyways?  I want to know how much I can put in here
without worrying about whether the remote side is dequeueing."  I guess I'd
settle for explicit documentation that the bound exists.  But how should I
expect my code to be portable?  Are there platforms which provide less than
64k?  Less than 1k?  Less than 256 bytes?

----------
Added file: http://bugs.python.org/file21709/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8426>
_______________________________________
-------------- next part --------------
Please don&#39;t close the issue.<div><br></div><div>Joining aside, the basic point (&quot;<span class="Apple-style-span" style="font-family: monospace; font-size: 12px; line-height: 17px; white-space: pre-wrap; ">But when size = 7279, the data submitted reaches 64k, so the writting thread blocks on the write syscall.</span><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">&quot;) is not clear from the docs, right?</span></div>
<div><span style="border-collapse:collapse;font-family:arial, sans-serif;font-size:13px"><br></span></div><div><span style="border-collapse:collapse;font-family:arial, sans-serif;font-size:13px">IMO, it would be nice if I could ask my queue, &quot;Just what is your capacity (in bytes, not entries) anyways? ??I want to know how much I can put in here without worrying about whether the remote side is dequeueing.&quot; ??I guess I&#39;d settle for explicit documentation that the bound exists. ??But how should I expect my code to be portable? ??Are there platforms which provide less than 64k? ??Less than 1k? ??Less than 256 bytes?</span></div>


From report at bugs.python.org  Tue Apr 19 05:35:40 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 19 Apr 2011 03:35:40 +0000
Subject: [issue8426] multiprocessing.Queue fails to get() very large objects
In-Reply-To: <1271443086.56.0.51527518355.issue8426@psf.upfronthosting.co.za>
Message-ID: <1303184140.49.0.971656258809.issue8426@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


Removed file: http://bugs.python.org/file21709/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8426>
_______________________________________

From report at bugs.python.org  Tue Apr 19 05:38:30 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 19 Apr 2011 03:38:30 +0000
Subject: [issue8426] multiprocessing.Queue fails to get() very large objects
In-Reply-To: <1271443086.56.0.51527518355.issue8426@psf.upfronthosting.co.za>
Message-ID: <1303184310.81.0.77027356822.issue8426@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Please do not send html responses, as they result in a spurious 'unnamed' file being attached.

Please do suggest a specific change.

Should this be changed to a doc issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8426>
_______________________________________

From report at bugs.python.org  Tue Apr 19 05:45:45 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 19 Apr 2011 03:45:45 +0000
Subject: [issue11750] Mutualize win32 functions
In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za>
Message-ID: <1303184745.41.0.59815316487.issue11750@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Here's a patch replacing Modules/_multiprocessing/win32_functions.c and PC/_subprocess.c with a common PC/_windows.c. There's not much to the patch despite its size -- it just shuffles around the C code and does a few renames in the appropriate Python modules. All tests pass.

I left the copyright notice from PC/_subprocess.c at the top. No idea if that needs to stay or not.

----------
keywords: +patch
Added file: http://bugs.python.org/file21710/issue11750.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11750>
_______________________________________

From report at bugs.python.org  Tue Apr 19 05:46:14 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 19 Apr 2011 03:46:14 +0000
Subject: [issue11750] Mutualize win32 functions
In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za>
Message-ID: <1303184774.29.0.331540784428.issue11750@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
keywords: +needs review
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11750>
_______________________________________

From report at bugs.python.org  Tue Apr 19 07:17:03 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 19 Apr 2011 05:17:03 +0000
Subject: [issue11750] Mutualize win32 functions
In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za>
Message-ID: <1303190223.02.0.848146067399.issue11750@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11750>
_______________________________________

From report at bugs.python.org  Tue Apr 19 08:31:15 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 19 Apr 2011 06:31:15 +0000
Subject: [issue11750] Mutualize win32 functions
In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za>
Message-ID: <1303194675.67.0.673643094585.issue11750@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Two high-level remarks about the patch:
- IMO there is no reason to put _windows.c in the PC directory.  After all, there is no such distinction for posix-specific modules.
- wxPython already has a submodule named _windows.py.  I wonder if this will cause problems.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11750>
_______________________________________

From report at bugs.python.org  Tue Apr 19 09:32:10 2011
From: report at bugs.python.org (Lennart Regebro)
Date: Tue, 19 Apr 2011 07:32:10 +0000
Subject: [issue10042] total_ordering
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1303198330.19.0.204077220192.issue10042@psf.upfronthosting.co.za>


Lennart Regebro <regebro at gmail.com> added the comment:

We *do* care about NotImplemented, that's the whole point of this bug report. I don't see how this is a problem in the new_total_ordering.py example. Can you give an example of when you get a stack overflow?

The examples in new_total_ordering are in themselves badly implemented, as they do check of the class with an isinstance, but if it is not the correct instance, they will return False or raise a TypeError. That's wrong, they should return NotImplemented, to give the other class a chance. But that is not a problem for the tests, it's only a problem if you use the tests as examples of how to implement a comparable class.

But in no case am I able to get a stack overflow here, which I can with the old total_ordering recipe.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Tue Apr 19 09:40:18 2011
From: report at bugs.python.org (Lennart Regebro)
Date: Tue, 19 Apr 2011 07:40:18 +0000
Subject: [issue10042] total_ordering
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1303198818.91.0.151311240532.issue10042@psf.upfronthosting.co.za>


Lennart Regebro <regebro at gmail.com> added the comment:

I'm attaching a file with the example classes returning NotImplemented, and a different implementation of a total ordering, as an example of how returning NotImplemented by one class will give the chance to the other class. This is the ultimate cause of the bug, and new_total_ordering handles it properly.

----------
Added file: http://bugs.python.org/file21711/new_total_ordering_notimplemented.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Tue Apr 19 09:40:33 2011
From: report at bugs.python.org (Alexander Boyd)
Date: Tue, 19 Apr 2011 07:40:33 +0000
Subject: [issue10042] total_ordering
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1303198833.91.0.571758281886.issue10042@psf.upfronthosting.co.za>


Alexander Boyd <alex at opengroove.org> added the comment:

I've attached a file demonstrating the stack overflow. It assumes total_ordering has been defined as per new_total_ordering.py.

----------
Added file: http://bugs.python.org/file21712/new_total_ordering_overflow.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Tue Apr 19 10:01:58 2011
From: report at bugs.python.org (Lennart Regebro)
Date: Tue, 19 Apr 2011 08:01:58 +0000
Subject: [issue10042] total_ordering
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1303200118.67.0.135155677321.issue10042@psf.upfronthosting.co.za>


Lennart Regebro <regebro at gmail.com> added the comment:

Ah! I see how you mean. The problem isn't just if you turn the conversion around from self > other to other < self. The problem in fact appears when a rich text function uses the <>!= operators on self directly.

I tried a version which uses the __xx__ operators directly and that works for the ones that does not use "not". "not NotImplemented" is false, for obvious reasons, and that means that with for example "lambda self, other: not self.__ge__(other)" will return False, when it should return NotImplemented.

In effect this means that the total ordering recipe only works as long as you don't compare two classes that use the total ordering recipe. :-)

I don't think the lambda technique is going to work properly. Of course we can say that we should care about NotImplemented, but then first of all this recipe needs a big "this is broken, don't use it unless you know what you are doing" label, and secondly I don't think it should have been included in the first place if we can't make it work properly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Tue Apr 19 10:06:02 2011
From: report at bugs.python.org (MattyG)
Date: Tue, 19 Apr 2011 08:06:02 +0000
Subject: [issue11872] cPickle gives strange error for large objects.
In-Reply-To: <1303200362.9.0.587954333494.issue11872@psf.upfronthosting.co.za>
Message-ID: <1303200362.9.0.587954333494.issue11872@psf.upfronthosting.co.za>


New submission from MattyG <meawoppl at gmail.com>:

from numpy import *
import cPickle

a = zeros((300000, 1000)) 
f = open("test.pkl", "w") 
cPickle.dump(a, f)

------
SystemError: Traceback (most recent call last)

/home/kddcup/code/matt/svd-projection/take5/<ipython console> in <module>()

SystemError?: error return without exception set

Or using the .dump function:

a.dump("test.pkl")

SystemError? Traceback (most recent call last)

/home/kddcup/code/matt/svd-projection/take5/<ipython console> in <module>()

SystemError: NULL result without error in PyObject?_Call

I am not sure if this is a numpy or Pickle/cPickle glitch. In either case, even if this is a semi-known behavior, a more instructive error message would certainly help. I think the problem only happens for arrays larger than 2**(32-1) bytes but I would have to experiment more to be sure.

----------
components: Extension Modules
messages: 134017
nosy: meawoppl
priority: normal
severity: normal
status: open
title: cPickle gives strange error for large objects.
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11872>
_______________________________________

From report at bugs.python.org  Tue Apr 19 10:06:33 2011
From: report at bugs.python.org (Alexander Boyd)
Date: Tue, 19 Apr 2011 08:06:33 +0000
Subject: [issue10042] total_ordering
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1303200393.64.0.697594393003.issue10042@psf.upfronthosting.co.za>


Alexander Boyd <alex at opengroove.org> added the comment:

That's my point. My version, sane_total_ordering.py, fixes this by using traditional functions and explicit NotImplemented checks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Tue Apr 19 10:12:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2011 08:12:22 +0000
Subject: [issue11873] test_regexp() of test_compileall failure on "x86
	OpenIndiana 3.x"
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Trace:
----------------------------------------------------------------------
[ 30/354] test_compileall
test test_compileall failed -- Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_compileall.py", line 253, in test_regexp
    self.assertCompiled(self.initfn)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_compileall.py", line 149, in assertCompiled
    self.assertTrue(os.path.exists(imp.cache_from_source(fn)))
AssertionError: False is not true
----------------------------------------------------------------------
http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.x/builds/1097/steps/test/logs/stdio

----------
components: Tests
messages: 134019
nosy: haypo
priority: normal
severity: normal
status: open
title: test_regexp() of test_compileall failure on "x86 OpenIndiana 3.x"
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11873>
_______________________________________

From report at bugs.python.org  Tue Apr 19 10:19:55 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 19 Apr 2011 08:19:55 +0000
Subject: [issue11872] cPickle gives strange error for large objects.
In-Reply-To: <1303200362.9.0.587954333494.issue11872@psf.upfronthosting.co.za>
Message-ID: <1303201195.46.0.748090978499.issue11872@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

See also issue11564 and issue9614.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11872>
_______________________________________

From report at bugs.python.org  Tue Apr 19 10:20:52 2011
From: report at bugs.python.org (Hartmut Niemann)
Date: Tue, 19 Apr 2011 08:20:52 +0000
Subject: [issue11874] argparse assertion failure with brackets in metavars
In-Reply-To: <1303201252.58.0.236363581255.issue11874@psf.upfronthosting.co.za>
Message-ID: <1303201252.58.0.236363581255.issue11874@psf.upfronthosting.co.za>


New submission from Hartmut Niemann <Hartmut.Niemann at siemens.com>:

I run this script with option --help
-----8<------------------
import argparse
parser = argparse.ArgumentParser()
parser.add_argument ('--from-itm', dest="from_itm",action="store",default=None,help ="Source ITM file", metavar="ITMFILENAME")
parser.add_argument ("--from-fbm-sigtab",dest="from_sigtab",action="store",default=None,help="Source signal FB", metavar=" [LIB,]FBNAME")
parser.add_argument ("--c",dest="f",metavar="x]d")
args = parser.parse_args()
---------8<--------------------
and I get an assertion failure:
---------8<--------------------
D:\temp>argparsebug.py --help
Traceback (most recent call last):
  File "D:\temp\argparsebug.py", line 6, in <module>
    args = parser.parse_args()
  File "C:\Python27\lib\argparse.py", line 1678, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "C:\Python27\lib\argparse.py", line 1710, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "C:\Python27\lib\argparse.py", line 1916, in _parse_known_args
    start_index = consume_optional(start_index)
  File "C:\Python27\lib\argparse.py", line 1856, in consume_optional
    take_action(action, args, option_string)
  File "C:\Python27\lib\argparse.py", line 1784, in take_action
    action(self, namespace, argument_values, option_string)
  File "C:\Python27\lib\argparse.py", line 993, in __call__
    parser.print_help()
  File "C:\Python27\lib\argparse.py", line 2303, in print_help
    self._print_message(self.format_help(), file)
  File "C:\Python27\lib\argparse.py", line 2277, in format_help
    return formatter.format_help()
  File "C:\Python27\lib\argparse.py", line 278, in format_help
    help = self._root_section.format_help()
  File "C:\Python27\lib\argparse.py", line 208, in format_help
    func(*args)
  File "C:\Python27\lib\argparse.py", line 329, in _format_usage
    assert ' '.join(opt_parts) == opt_usage
AssertionError
--------------8<-------------------------------
It must be the combination of several argument lines because when I 
comment out one of the add_arguments, it works.

Is this a bug or do I do things I shouln't?
If it is not allowed to use [] in metavars (what I wanted was metavar='[optional,]mantatory'), I' like to receive a readable error message.

With best regards
Hartmut Niemann

----------
components: None
messages: 134021
nosy: htnieman
priority: normal
severity: normal
status: open
title: argparse assertion failure with brackets in metavars
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11874>
_______________________________________

From report at bugs.python.org  Tue Apr 19 10:24:53 2011
From: report at bugs.python.org (Lennart Regebro)
Date: Tue, 19 Apr 2011 08:24:53 +0000
Subject: [issue10042] total_ordering
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1303201493.78.0.111441023489.issue10042@psf.upfronthosting.co.za>


Lennart Regebro <regebro at gmail.com> added the comment:

Yeah, I can't say it's pretty though. :) Anyway this is an issue for 3.2 and 2.7 as well, then, so I add them back.

----------
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Tue Apr 19 10:28:24 2011
From: report at bugs.python.org (Mario Juric)
Date: Tue, 19 Apr 2011 08:28:24 +0000
Subject: [issue11875] OrderedDict.__reduce__ not threadsafe
In-Reply-To: <1303201704.87.0.690807992306.issue11875@psf.upfronthosting.co.za>
Message-ID: <1303201704.87.0.690807992306.issue11875@psf.upfronthosting.co.za>


New submission from Mario Juric <mjuric at ias.edu>:

The implementation of OrderedDict.__reduce__() in Python 2.7.1 is not thread safe because of the following four lines:

        tmp = self.__map, self.__root
        del self.__map, self.__root
        inst_dict = vars(self).copy()
        self.__map, self.__root = tmp

If one thread is pickling an OrderedDict, while another accesses it, a race condition occurs if the accessing thread accesses the dict after self.__map and self.__root have been delated, and before they've been set again (above).

This leads to an extremely difficult bug to diagnose when using multiprocessing.Queue to exchange OrderedDicts between multiple processes (because Queue uses a separate feeder thread to do the pickling).

The fix seems relatively easy -- use:

        inst_dict = vars(self).copy()
        del inst_dict['_OrderedDict__map'], inst_dict['_OrderedDict__root']

instead of the above four lines.

PS: This issue+fix may also apply to Python 3.x, although I haven't tested it there.

----------
components: Library (Lib)
messages: 134023
nosy: mjuric
priority: normal
severity: normal
status: open
title: OrderedDict.__reduce__ not threadsafe
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11875>
_______________________________________

From report at bugs.python.org  Tue Apr 19 10:30:17 2011
From: report at bugs.python.org (higery)
Date: Tue, 19 Apr 2011 08:30:17 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1303201817.5.0.95842477557.issue828450@psf.upfronthosting.co.za>


Changes by higery <shoulderhigher at gmail.com>:


Removed file: http://bugs.python.org/file21697/change_path_separator_in_MANIFEST.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Tue Apr 19 10:30:43 2011
From: report at bugs.python.org (higery)
Date: Tue, 19 Apr 2011 08:30:43 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1303201843.76.0.113984750865.issue828450@psf.upfronthosting.co.za>


Changes by higery <shoulderhigher at gmail.com>:


Added file: http://bugs.python.org/file21713/change_path_separator_in_MANIFEST.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Tue Apr 19 10:44:44 2011
From: report at bugs.python.org (Alexander Boyd)
Date: Tue, 19 Apr 2011 08:44:44 +0000
Subject: [issue10042] total_ordering
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1303202684.13.0.883915667697.issue10042@psf.upfronthosting.co.za>


Alexander Boyd <alex at opengroove.org> added the comment:

Ok. Yeah, I won't argue that it's pretty :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Tue Apr 19 10:46:24 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 19 Apr 2011 08:46:24 +0000
Subject: [issue11875] OrderedDict.__reduce__ not threadsafe
In-Reply-To: <1303201704.87.0.690807992306.issue11875@psf.upfronthosting.co.za>
Message-ID: <1303202784.43.0.552456700087.issue11875@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11875>
_______________________________________

From report at bugs.python.org  Tue Apr 19 11:25:55 2011
From: report at bugs.python.org (Jonas H.)
Date: Tue, 19 Apr 2011 09:25:55 +0000
Subject: [issue11258] ctypes: Speed up find_library() on Linux by 500%
In-Reply-To: <1298217839.35.0.775539629492.issue11258@psf.upfronthosting.co.za>
Message-ID: <1303205155.88.0.762264642362.issue11258@psf.upfronthosting.co.za>


Jonas H. <jonas at lophus.org> added the comment:

*push* Any way to get this into the codebase?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11258>
_______________________________________

From report at bugs.python.org  Tue Apr 19 11:26:35 2011
From: report at bugs.python.org (Tim Golden)
Date: Tue, 19 Apr 2011 09:26:35 +0000
Subject: [issue10888] os.stat(filepath).st_mode gives wrong 'executable
	permission' result
In-Reply-To: <1303162951.35.0.194765368801.issue10888@psf.upfronthosting.co.za>
Message-ID: <4DAD5547.4050808@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

FWIW I agree with MvL: os.stat is one of those awkward customers
left over from the idea that Windows could be posix-compliant,
even though the relevant concepts don't actually map particularly
well. ISTM that anyone seriously wanting to determine whether
something's executable or not on Windows is going to have in
mind the precise semantics of a particular use-case and will
employ whatever API calls meet that need. I genuinely don't
believe there's any mileage in shoehorning more and more
corner-cases into os.stat on Windows.

----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10888>
_______________________________________

From report at bugs.python.org  Tue Apr 19 11:34:06 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 19 Apr 2011 09:34:06 +0000
Subject: [issue11875] OrderedDict.__reduce__ not threadsafe
In-Reply-To: <1303201704.87.0.690807992306.issue11875@psf.upfronthosting.co.za>
Message-ID: <1303205646.54.0.915409424324.issue11875@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

To avoid hardcoding the mangled names:

@@ -155,10 +155,9 @@
     def __reduce__(self):
         'Return state information for pickling'
         items = [[k, self[k]] for k in self]
-        tmp = self.__map, self.__root, self.__hardroot
-        del self.__map, self.__root, self.__hardroot
         inst_dict = vars(self).copy()
-        self.__map, self.__root, self.__hardroot = tmp
+        for k in vars(OrderedDict()):
+            inst_dict.pop(k, None)
         if inst_dict:
             return (self.__class__, (items,), inst_dict)
         return self.__class__, (items,)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11875>
_______________________________________

From report at bugs.python.org  Tue Apr 19 11:39:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2011 09:39:00 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1303205940.82.0.79335775323.issue11223@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> ?If a signal is delivered to a thread waiting for a condition variable, 
> upon return from the signal handler the thread resumes waiting for the condition
> variable as if it was not interrupted, or it shall return zero due to spurious
> wakeup.?

Confirmed on Linux (kernel 2.6.37, eglibc 2.11.2) using strace:
--------
10:42:59.942455 futex(0x173fabc, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, {1303202584, 942432000}, ffffffff) = ? ERESTART_RESTARTBLOCK (To be restarted)
10:43:00.941777 --- SIGALRM (Alarm clock) @ 0 (0) ---
10:43:00.941848 rt_sigreturn(0x1462eac) = -1 EINTR (Interrupted system call)
10:43:00.941926 futex(0x173fabc, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, {1303202584, 942432000}, ffffffff) = -1 ETIMEDOUT (Connection timed out)
10:43:04.942650 futex(0x173fae8, FUTEX_WAKE_PRIVATE, 1) = 0
--------
pthread_cond_timedwait() is interrupted: the system call returns ERESTART_RESTARTBLOCK (To be restarted), and then the system call is restarted.

I think that we should just skip the test if Python uses pthread without semaphore and pthread_cond_timedwait() restarts if it is interrupted by a signal. Attached C program checks if pthread_cond_timedwait() does restart or not. On Linux, it should be compiled using:
gcc -pthread -lrt pthread_cond_timedwait_signal.c -o pthread_cond_timedwait_signal

I don't know how to integrate pthread_cond_timedwait_signal.c into configure.in. I don't know if any OS does NOT restart pthread_cond_timedwait() after an interruption, so it's maybe simpler to always skip test_lock_acquire_interruption() and test_rlock_acquire_interruption() of test_threadsignals if Python uses pthread without semaphore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Tue Apr 19 11:39:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2011 09:39:45 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1303205985.55.0.128040181756.issue11223@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file21714/pthread_cond_timedwait_signal.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Tue Apr 19 11:45:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2011 09:45:44 +0000
Subject: [issue11876] SGI Irix threads, SunOS lightweight processes,
	GNU pth threads, Mach C Threads are now unsupported,
	and code will be removed in 3.3
In-Reply-To: <1303206344.55.0.955794008969.issue11876@psf.upfronthosting.co.za>
Message-ID: <1303206344.55.0.955794008969.issue11876@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Python/thread.c contains the following messages:

#ifdef SGI_THREADS
#error SGI Irix threads are now unsupported, and code will be removed in 3.3.
#include "thread_sgi.h"
#endif


#ifdef SUN_LWP
#error SunOS lightweight processes are now unsupported, and code will be removed in 3.3.
#include "thread_lwp.h"
#endif

#ifdef HAVE_PTH
#error GNU pth threads are now unsupported, and code will be removed in 3.3.
#include "thread_pth.h"
#undef _POSIX_THREADS
#endif

#ifdef C_THREADS
#error Mach C Threads are now unsupported, and code will be removed in 3.3.
#include "thread_cthread.h"
#endif

----------
components: Interpreter Core
messages: 134029
nosy: haypo
priority: normal
severity: normal
status: open
title: SGI Irix threads, SunOS lightweight processes, GNU pth threads, Mach C Threads are now unsupported, and code will be removed in 3.3
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11876>
_______________________________________

From report at bugs.python.org  Tue Apr 19 11:55:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2011 09:55:04 +0000
Subject: [issue11876] SGI Irix threads, SunOS lightweight processes,
	GNU pth threads, Mach C Threads are now unsupported,
	and code will be removed in 3.3
In-Reply-To: <1303206344.55.0.955794008969.issue11876@psf.upfronthosting.co.za>
Message-ID: <1303206904.45.0.987339562003.issue11876@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, the file contains also a reference to a missing file:

#ifdef PLAN9_THREADS
#include "thread_plan9.h"
#endif

But I don't see where PLAN9_THREADS is defined.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11876>
_______________________________________

From report at bugs.python.org  Tue Apr 19 12:01:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2011 10:01:38 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1303207298.12.0.616377909935.issue11223@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The problem is that I don't know how to check in test_threadsignals which thread implementation is used in Python. It would be nice to have some functions providing such information in the sys or sysconfig module, maybe something like sys.float_info.

For example, sys._thread_info can be a dict like {'name': 'pthread', 'use_semaphore': True}.

Keys:
 - name: cthread, lwp, nt, os2, pth, pthread, sgi, solaris or wince (sgi, lwp, pth, cthread may be removed from Python 3.3: #11876)
 - maxproc: max # of threads that can be started (SGI only)
 - stacksize: default stacksize for a thread (lwp, pthread and os2 only)
 - min_stacksize: minimum stacksize for a thread (pthread, nt and os2 only)
 - max_stacksize: maximum stacksize for a thread (nt and os2 only)

thread_pthread.h contains many #ifdef which may be interesting to have in thread_info:
 - if _HAVE_BSDI is defined, don't use pthread_init()
 - if THREAD_STACK_SIZE is defined, set the size of the thread stack
 - if PTHREAD_SYSTEM_SCHED_SUPPORTED is defined: set scope to PTHREAD_SCOPE_SYSTEM
 - if (defined(_POSIX_SEMAPHORES) && defined(HAVE_BROKEN_POSIX_SEMAPHORES) && defined(HAVE_SEM_TIMEDWAIT)): use semaphore

Well, the most important informations for this issue is the name of the thread implementation (pthread) and know if pthread semaphore are used or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Tue Apr 19 12:08:12 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 19 Apr 2011 10:08:12 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <20110419100803.GA39684@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Took some time, but here is a patch that makes mmap(2) work on
Mac OS X.
This also applies to #11779.

Background:
on OS X, fsync(2) seems to behave as fdatasync(2).
To give people the possibility to do some kind of fync(2)
nonetheless, a new fcntl(2) has been introduced: F_FULLFSYNC.
If you use that, the ,sparse` file is synchronized with physical
backing store immediately and all is fine.
Vampire magic!

----------
Added file: http://bugs.python.org/file21715/11277.3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________
-------------- next part --------------
diff --git a/Lib/test/test_zlib.py b/Lib/test/test_zlib.py
--- a/Lib/test/test_zlib.py
+++ b/Lib/test/test_zlib.py
@@ -70,7 +70,7 @@
         with open(support.TESTFN, "wb+") as f:
             f.seek(_4G)
             f.write(b"asdf")
-        with open(support.TESTFN, "rb") as f:
+            f.flush()
             self.mapping = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
 
     def tearDown(self):
diff --git a/Modules/mmapmodule.c b/Modules/mmapmodule.c
--- a/Modules/mmapmodule.c
+++ b/Modules/mmapmodule.c
@@ -23,6 +23,9 @@
 
 #ifndef MS_WINDOWS
 #define UNIX
+# ifdef __APPLE__
+#  include <fcntl.h>
+# endif
 #endif
 
 #ifdef MS_WINDOWS
@@ -1122,6 +1125,10 @@
                             "mmap invalid access parameter.");
     }
 
+#ifdef __APPLE__
+    if (fd != -1)
+        (void)fcntl(fd, F_FULLFSYNC);
+#endif
 #ifdef HAVE_FSTAT
 #  ifdef __VMS
     /* on OpenVMS we must ensure that all bytes are written to the file */

From report at bugs.python.org  Tue Apr 19 12:10:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2011 10:10:38 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1303207838.28.0.848771340305.issue11277@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@sdaoden: This issue has a lot of patches, can you remove old patches?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Apr 19 12:11:41 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 19 Apr 2011 10:11:41 +0000
Subject: [issue11779] test_mmap timeout (1 hour) on "AMD64 Snow Leopard 3.x"
	buildbot
In-Reply-To: <1303170261.11.0.932515210124.issue11779@psf.upfronthosting.co.za>
Message-ID: <20110419101134.GB39684@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

I think that will also be healed with the patch i've just posted
to #11277.
(However, though i can't ,reproduce`, it seems the
Microkernel/IOKit interaction sometimes has a problem, because
i *really* had messed up sparse files (about 1-2 percent or so)
during the testing phase.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11779>
_______________________________________

From report at bugs.python.org  Tue Apr 19 12:12:09 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 19 Apr 2011 10:12:09 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1303207929.81.0.9117400077.issue11277@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file20861/doc_lib_mmap.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Apr 19 12:12:15 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 19 Apr 2011 10:12:15 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1303207935.17.0.673070140765.issue11277@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file21671/11277.1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Apr 19 12:12:24 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 19 Apr 2011 10:12:24 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1303207944.14.0.0182827165369.issue11277@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file21675/11277.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Apr 19 12:13:18 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 19 Apr 2011 10:13:18 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1303207998.63.0.638188442543.issue11277@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

(The working patch is http://bugs.python.org/file21715/11277.3.diff.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Apr 19 12:14:50 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 19 Apr 2011 10:14:50 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1303208090.61.0.0257182009844.issue11277@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file21672/11277.mmap.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Apr 19 12:14:55 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 19 Apr 2011 10:14:55 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1303208095.46.0.254229984495.issue11277@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file21676/11277.mmap-1.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Apr 19 12:14:59 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 19 Apr 2011 10:14:59 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1303208099.74.0.185447788194.issue11277@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file21683/11277.mmap-2.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Apr 19 12:15:03 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 19 Apr 2011 10:15:03 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1303208103.1.0.245809907971.issue11277@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file21684/11277.mmap-2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Apr 19 12:15:21 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 19 Apr 2011 10:15:21 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1303208121.51.0.542952295345.issue11277@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

(Dropped the tests, too.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Apr 19 12:30:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2011 10:30:18 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1303209018.12.0.948277137346.issue11223@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

threading_info.patch:
 - Add thread._info() function -> dict with 'name' and 'use_semaphores' (pthread only) keys
 - Skip test_lock_acquire_interruption() and test_rlock_acquire_interruption() if Python uses pthread without semaphores

thread._info() creates a new dict at each call.

----------
Added file: http://bugs.python.org/file21716/threading_info.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Tue Apr 19 12:34:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2011 10:34:11 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1303209251.11.0.345047351016.issue11277@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

11277.3.diff: this patch looks correct (I'm unable to test it), but can you add a sentence in mmap doc to explain that mmap.mmap() does flush the file on Mac OS X and VMS?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Apr 19 12:38:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2011 10:38:46 +0000
Subject: [issue11277] Crash with mmap and sparse files on Mac OS X
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1303209526.4.0.580462810855.issue11277@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: test_zlib.test_big_buffer crashes under BSD (Mac OS X and FreeBSD) -> Crash with mmap and sparse files on Mac OS X

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Apr 19 12:43:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2011 10:43:04 +0000
Subject: [issue11277] Crash with mmap and sparse files on Mac OS X
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1303209784.62.0.265192126594.issue11277@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, fcntl has already a F_FULLFSYNC constant, so we can use like fcntl.fcntl(fd, fcntl.F_FULLFSYNC) in Python.

> can you add a sentence in mmap doc to explain that mmap.mmap()
> does flush the file on Mac OS X and VMS?

Hum, it does flush the file on VMS using fsync(), but on Mac OS X, it does just set F_FULLFSYNC flag using fcntl. It doesn't call fsync() explicitly. Does mmap() "call fsync()" implicitly?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Apr 19 12:47:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2011 10:47:42 +0000
Subject: [issue11277] Crash with mmap and sparse files on Mac OS X
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1303210062.46.0.62989606441.issue11277@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, and can you add a comment explaining why F_FULLFSYNC is needed on Mac OS X in your patch? (If I understood correctly, it is needed to avoid crash with sparse files).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Apr 19 13:14:30 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 19 Apr 2011 11:14:30 +0000
Subject: [issue11876] SGI Irix threads, SunOS lightweight processes,
	GNU pth threads, Mach C Threads are now unsupported,
	and code will be removed in 3.3
In-Reply-To: <1303206344.55.0.955794008969.issue11876@psf.upfronthosting.co.za>
Message-ID: <1303211670.47.0.141347208457.issue11876@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11876>
_______________________________________

From report at bugs.python.org  Tue Apr 19 13:14:56 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 19 Apr 2011 11:14:56 +0000
Subject: [issue11277] Crash with mmap and sparse files on Mac OS X
In-Reply-To: <1303210062.46.0.62989606441.issue11277@psf.upfronthosting.co.za>
Message-ID: <20110419111447.GA58896@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Updated 11277.4.diff also includes mmap.rst update.
(Maybe os.fsync() and os.sync() should be modified to really do
that fcntl, too?  I'll think i'll open an issue with patch soon.)

----------
Added file: http://bugs.python.org/file21717/11277.4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________
-------------- next part --------------
diff --git a/Doc/library/mmap.rst b/Doc/library/mmap.rst
--- a/Doc/library/mmap.rst
+++ b/Doc/library/mmap.rst
@@ -86,6 +86,10 @@
    defaults to 0.  *offset* must be a multiple of the PAGESIZE or
    ALLOCATIONGRANULARITY.
 
+   To ensure validity of the created memory mapping the file specified
+   by the descriptor *fileno* is internally automatically synchronized
+   with physical backing store on Mac OS X and OpenVMS.
+
    This example shows a simple way of using :class:`mmap`::
 
       import mmap
diff --git a/Lib/test/test_zlib.py b/Lib/test/test_zlib.py
--- a/Lib/test/test_zlib.py
+++ b/Lib/test/test_zlib.py
@@ -70,7 +70,7 @@
         with open(support.TESTFN, "wb+") as f:
             f.seek(_4G)
             f.write(b"asdf")
-        with open(support.TESTFN, "rb") as f:
+            f.flush()
             self.mapping = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
 
     def tearDown(self):
diff --git a/Modules/mmapmodule.c b/Modules/mmapmodule.c
--- a/Modules/mmapmodule.c
+++ b/Modules/mmapmodule.c
@@ -23,6 +23,9 @@
 
 #ifndef MS_WINDOWS
 #define UNIX
+# ifdef __APPLE__
+#  include <fcntl.h>
+# endif
 #endif
 
 #ifdef MS_WINDOWS
@@ -1122,6 +1125,13 @@
                             "mmap invalid access parameter.");
     }
 
+#ifdef __APPLE__
+    /* Issue 11277: due to lack of sparse file support on OS X synchronization
+     * with physical backing store is required to ensure validity of the mmap.
+     * Since fsync(2) acts like fdatasync(2) a special fcntl(2) is necessary */
+    if (fd != -1)
+        (void)fcntl(fd, F_FULLFSYNC);
+#endif
 #ifdef HAVE_FSTAT
 #  ifdef __VMS
     /* on OpenVMS we must ensure that all bytes are written to the file */

From report at bugs.python.org  Tue Apr 19 13:29:41 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 19 Apr 2011 11:29:41 +0000
Subject: [issue11300] mmap() large file failures on Mac OS X docfix
In-Reply-To: <1298493292.2.0.2203680343.issue11300@psf.upfronthosting.co.za>
Message-ID: <1303212581.21.0.811638968381.issue11300@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Outdated due to found #11277 solution.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11300>
_______________________________________

From report at bugs.python.org  Tue Apr 19 13:35:38 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 19 Apr 2011 11:35:38 +0000
Subject: [issue11877] Mac OS X fsync() should really be fcntl(F_FULLFSYNC)
In-Reply-To: <1303212938.57.0.821096700769.issue11877@psf.upfronthosting.co.za>
Message-ID: <1303212938.57.0.821096700769.issue11877@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

Issue 11277 revealed that Mac OS X fsync() does not always
and gracefully synchronize file data to physical backing store.
To gain real fsync(2) behaviour fcntl(2) must be called with
the F_FULLFSYNC flag.

----------
components: Library (Lib)
files: fsync.diff
keywords: patch
messages: 134043
nosy: sdaoden
priority: normal
severity: normal
status: open
title: Mac OS X fsync() should really be fcntl(F_FULLFSYNC)
versions: Python 3.3
Added file: http://bugs.python.org/file21718/fsync.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Tue Apr 19 14:01:53 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 19 Apr 2011 12:01:53 +0000
Subject: [issue11877] Mac OS X fsync() should really be fcntl(F_FULLFSYNC)
In-Reply-To: <1303212938.57.0.821096700769.issue11877@psf.upfronthosting.co.za>
Message-ID: <1303214513.42.0.17894785521.issue11877@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Tue Apr 19 14:07:56 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 19 Apr 2011 12:07:56 +0000
Subject: [issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X
	and FreeBSD)
In-Reply-To: <1303209251.11.0.345047351016.issue11277@psf.upfronthosting.co.za>
Message-ID: <20110419120740.GB58896@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

On Tue, Apr 19, 2011 at 10:34:11AM +0000, STINNER Victor wrote:
> 11277.3.diff: this patch looks correct

Unbelievable - you really fought yourself through this immense
bunch of code in such a short time!
:)

----------
title: Crash with mmap and sparse files on Mac OS X -> test_zlib.test_big_buffer crashes under BSD (Mac OS X and FreeBSD)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Apr 19 14:29:27 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 19 Apr 2011 12:29:27 +0000
Subject: [issue11277] Crash with mmap and sparse files on Mac OS X
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1303216167.23.0.405445860116.issue11277@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

(My last reply-mail changed the title.  Fixing.)

----------
title: test_zlib.test_big_buffer crashes under BSD (Mac OS X and FreeBSD) -> Crash with mmap and sparse files on Mac OS X

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Apr 19 14:30:42 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 19 Apr 2011 12:30:42 +0000
Subject: [issue8271] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2.0
In-Reply-To: <1270002492.52.0.790856673013.issue8271@psf.upfronthosting.co.za>
Message-ID: <1303216242.56.0.0884250115593.issue8271@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attached patch against 3.1 fixes the number of FFFD.
A test for the range in the error message should probably be added.  I haven't done any benchmark yet.  There's some code duplication, but I'm not sure it can be factored out.

----------
versions: +Python 3.3 -Python 2.6
Added file: http://bugs.python.org/file21719/issue8271v6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8271>
_______________________________________

From report at bugs.python.org  Tue Apr 19 14:56:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2011 12:56:26 +0000
Subject: [issue11277] Crash with mmap and sparse files on Mac OS X
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1303217786.65.0.927540329769.issue11277@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> (My last reply-mail changed the title.  Fixing.)

Yeah, it's a common problem if you use the email interface :-/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Apr 19 15:06:05 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 19 Apr 2011 13:06:05 +0000
Subject: [issue11750] Mutualize win32 functions
In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za>
Message-ID: <1303218365.37.0.514593501651.issue11750@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

For the first point, I just put it there since other Windows-only modules already exist there. _subprocess did, msvcrt and winreg currently do, and there's a few other Windows-only things in there. It's not a big deal, so I can move it into Modules if we want -- winreg and msvcrt should probably get moved as well (in another issue).

As for the name clash, I could shorten it to _win, but I'd rather not name it _win32. Microsoft got away from calling it the "Win32 API" and instead say "Windows API" now since it also covers 64-bit. It's just an internal name so I won't fight too hard on this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11750>
_______________________________________

From report at bugs.python.org  Tue Apr 19 15:08:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Apr 2011 13:08:46 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1303209018.12.0.948277137346.issue11223@psf.upfronthosting.co.za>
Message-ID: <1303218523.3489.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> threading_info.patch:
>  - Add thread._info() function -> dict with 'name' and
> 'use_semaphores' (pthread only) keys

Most of these names will be removed in 3.3:
http://bugs.python.org/issue11863

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Tue Apr 19 15:13:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2011 13:13:20 +0000
Subject: [issue11876] SGI Irix threads, SunOS lightweight processes,
	GNU pth threads, Mach C Threads are now unsupported,
	and code will be removed in 3.3
In-Reply-To: <1303206344.55.0.955794008969.issue11876@psf.upfronthosting.co.za>
Message-ID: <1303218800.32.0.4841324555.issue11876@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, this is a duplicate of #11863.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11876>
_______________________________________

From report at bugs.python.org  Tue Apr 19 15:13:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2011 13:13:37 +0000
Subject: [issue11863] Enforce PEP 11 - remove support for legacy systems
In-Reply-To: <1303085337.86.0.669937619549.issue11863@psf.upfronthosting.co.za>
Message-ID: <1303218817.0.0.410227285176.issue11863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Issue #11876 has been marked as a duplicate of this issue.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11863>
_______________________________________

From report at bugs.python.org  Tue Apr 19 15:26:49 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 19 Apr 2011 13:26:49 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1303219609.04.0.959062575311.issue1294232@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yep, the leading underscore and the fact you added it to a block of code that is skipped when Py_LIMITED_API is defined makes it OK to include the prototype in object.h.

However, I would suggest _PyType_CalculateMetaclass as the name - CalculateWinner is a bit vague without the specific context of calculating the metaclass.

On a broader point, I think there is an issue that needs to be brought up on python-dev: in light of PEP 3115, "type(name, bases, ns)" is no longer an entirely safe way to create dynamic types, as it bypasses __prepare__ methods. There should be an official way to access the full class building process, including correct invocation of __prepare__ methods (likely by making __build_class__ an official part of the language spec rather than a CPython implementation detail).

----------
assignee: docs at python -> 
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Tue Apr 19 15:27:50 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 19 Apr 2011 13:27:50 +0000
Subject: [issue11867] Make test_mailbox deterministic
In-Reply-To: <1303132744.64.0.479347573965.issue11867@psf.upfronthosting.co.za>
Message-ID: <1303219670.28.0.381906872681.issue11867@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Nice ping pong you play..
I, buildbot get:

Using random seed 2215045
[1/1] test_mailbox
test test_mailbox failed -- multiple errors occurred; run in verbose mode for details
test test_mailbox failed -- Traceback (most recent call last):
  File "/Users/steffen/usr/opt/py3k/lib/python3.3/test/test_mailbox.py", line 1033, in test_lock_conflict
    ipc.signal('done')
  File "/Users/steffen/usr/opt/py3k/lib/python3.3/test/test_mailbox.py", line 1007, in __exit__
    self.c_sock.shutdown(socket.SHUT_RDWR)
socket.error: [Errno 57] Socket is not connected

test test_mailbox failed -- Traceback (most recent call last):
  File "/Users/steffen/usr/opt/py3k/lib/python3.3/test/test_mailbox.py", line 1033, in test_lock_conflict
    ipc.signal('done')
  File "/Users/steffen/usr/opt/py3k/lib/python3.3/test/test_mailbox.py", line 1007, in __exit__
    self.c_sock.shutdown(socket.SHUT_RDWR)
socket.error: [Errno 57] Socket is not connected

/Users/steffen/usr/opt/py3k/lib/python3.3/test/regrtest.py:1082: ResourceWarning: unclosed <socket.socket object, fd=5, family=2, type=1, proto=0>
  gc.collect()
1 test failed:
    test_mailbox
Re-running failed tests in verbose mode
Re-running test 'test_mailbox' in verbose mode

...

======================================================================
ERROR: test_lock_conflict (test.test_mailbox.TestMbox)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/steffen/usr/opt/py3k/lib/python3.3/test/test_mailbox.py", line 1033, in test_lock_conflict
    ipc.signal('done')
  File "/Users/steffen/usr/opt/py3k/lib/python3.3/test/test_mailbox.py", line 1007, in __exit__
    self.c_sock.shutdown(socket.SHUT_RDWR)
socket.error: [Errno 57] Socket is not connected

======================================================================
ERROR: test_lock_conflict (test.test_mailbox.TestMMDF)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/steffen/usr/opt/py3k/lib/python3.3/test/test_mailbox.py", line 1033, in test_lock_conflict
    ipc.signal('done')
  File "/Users/steffen/usr/opt/py3k/lib/python3.3/test/test_mailbox.py", line 1007, in __exit__
    self.c_sock.shutdown(socket.SHUT_RDWR)
socket.error: [Errno 57] Socket is not connected

----------------------------------------------------------------------
Ran 332 tests in 55.487s

FAILED (errors=2)
test test_mailbox failed -- multiple errors occurred
ok

... repeats yet another two times (very long output though)

----------------------------------------------------------------------
Ran 332 tests in 151.484s

OK
[118424 refs]

----------
nosy: +sdaoden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11867>
_______________________________________

From report at bugs.python.org  Tue Apr 19 15:37:08 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 19 Apr 2011 13:37:08 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1303220228.66.0.68818612566.issue1294232@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Removed 2.7 from the affected versions - with neither __build_class__ nor __prepare__ in 2.x, there's no alternate metaclass calculation to go wrong.

This should definitely be fixed for the final 3.1 release and for 3.2 though. An updated patch against current 3.1 would be most convenient (hg should take care of the forward porting from that point).

----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Tue Apr 19 16:03:33 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 19 Apr 2011 14:03:33 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1303221813.58.0.772209328973.issue1294232@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Sorry, my last review wasn't right and the patch is incorrect as it stands. After digging a little deeper, there is still a case that isn't covered correctly in __build_class__.

Specifically, the case where the most derived class has a declared metatype that is the *parent* of the metaclass that *should* be used.

This can be seen in type_new, where it does the "if (winner != metatype)" check. There is no equivalent check in __build_class__ - instead, the explicitly declared metaclass always wins.

What needs to happen is that the call to _PyType_CalculateMetaclass in __build_class__ should be moved out so that it is unconditional. The passed in metatype will either by the explicitly declared one (if it exists) or else PyType_Type. An additional test to pick up this case is also needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Tue Apr 19 16:04:40 2011
From: report at bugs.python.org (Prashant Kumar)
Date: Tue, 19 Apr 2011 14:04:40 +0000
Subject: [issue10932] distutils.core.setup - data_files misbehaviour ?
In-Reply-To: <1295353825.23.0.755300594789.issue10932@psf.upfronthosting.co.za>
Message-ID: <1303221880.56.0.530578846782.issue10932@psf.upfronthosting.co.za>


Changes by Prashant Kumar <contactprashantat at gmail.com>:


Added file: http://bugs.python.org/file21720/test_command_sdist.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10932>
_______________________________________

From report at bugs.python.org  Tue Apr 19 16:11:40 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Apr 2011 14:11:40 +0000
Subject: [issue11867] Make test_mailbox deterministic
In-Reply-To: <1303132744.64.0.479347573965.issue11867@psf.upfronthosting.co.za>
Message-ID: <1303222300.69.0.486996761371.issue11867@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for testing this.  I was afraid something like that would happen, since socket implementations are different on different platforms.  I presume you ran it on OSX.

Now I have to decide if I want to fix it, or if I should just switch to using threads.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11867>
_______________________________________

From report at bugs.python.org  Tue Apr 19 16:17:29 2011
From: report at bugs.python.org (Prashant Kumar)
Date: Tue, 19 Apr 2011 14:17:29 +0000
Subject: [issue10932] distutils.core.setup - data_files misbehaviour ?
In-Reply-To: <1295353825.23.0.755300594789.issue10932@psf.upfronthosting.co.za>
Message-ID: <1303222649.81.0.161331121141.issue10932@psf.upfronthosting.co.za>


Prashant Kumar <contactprashantat at gmail.com> added the comment:

If I'm not wrong, the contents in the manifest file should be:
 'data.cfg' (not cfg/data.cgg)
 I've added a patch which fixes the above issue.

----------
Added file: http://bugs.python.org/file21721/fix-manifest.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10932>
_______________________________________

From report at bugs.python.org  Tue Apr 19 16:20:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2011 14:20:23 +0000
Subject: [issue11863] Enforce PEP 11 - remove support for legacy systems
In-Reply-To: <1303085337.86.0.669937619549.issue11863@psf.upfronthosting.co.za>
Message-ID: <1303222823.25.0.695819723856.issue11863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch removing cpthread, pth, lwp and solaris thread implementations. The patch on configure.in, around the following diff, is invalid:
----
     AC_DEFINE(_REENTRANT)
-    AC_CHECK_HEADER(cthreads.h, [AC_DEFINE(WITH_THREAD)
-    AC_DEFINE(C_THREADS)
-    AC_DEFINE(HURD_C_THREADS, 1,
-    [Define if you are using Mach cthreads directly under /include])
-    LIBS="$LIBS -lthreads"
-    THREADOBJ="Python/thread.o"],[
-    AC_CHECK_HEADER(mach/cthreads.h, [AC_DEFINE(WITH_THREAD)
-    AC_DEFINE(C_THREADS)
-    AC_DEFINE(MACH_C_THREADS, 1,
-    [Define if you are using Mach cthreads under mach /])
-    THREADOBJ="Python/thread.o"],[
     # Just looking for pthread_create in libpthread is not enough:
     # on HP/UX, pthread.h renames pthread_create to a different symbol name.
     # So we really have to include pthread.h, and then link.
----

autoconf will have to be run to update configure.

I am not sure that the patch removes all code related to these threads.

----------
keywords: +patch
Added file: http://bugs.python.org/file21722/remove_threads.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11863>
_______________________________________

From report at bugs.python.org  Tue Apr 19 16:21:53 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Tue, 19 Apr 2011 14:21:53 +0000
Subject: [issue8933] Invalid detection of metadata version
In-Reply-To: <1275927761.19.0.897367518837.issue8933@psf.upfronthosting.co.za>
Message-ID: <1303222913.59.0.384753721722.issue8933@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Bump! How about commiting this patch, Eric?

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8933>
_______________________________________

From report at bugs.python.org  Tue Apr 19 16:24:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2011 14:24:18 +0000
Subject: [issue11863] Enforce PEP 11 - remove support for legacy systems
In-Reply-To: <1303085337.86.0.669937619549.issue11863@psf.upfronthosting.co.za>
Message-ID: <1303223058.76.0.127690086972.issue11863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

FYI Hurd only supports cthread, without cthread support, Python will not support threads on Hurd anymore.

There are two Hurd issues to move from cthread to pthread
http://savannah.gnu.org/task/?5487 (opened 5 years ago)
http://savannah.gnu.org/task/?7895 (opened 3 years ago)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11863>
_______________________________________

From report at bugs.python.org  Tue Apr 19 16:35:43 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 19 Apr 2011 14:35:43 +0000
Subject: [issue11867] Make test_mailbox deterministic
In-Reply-To: <1303132744.64.0.479347573965.issue11867@psf.upfronthosting.co.za>
Message-ID: <1303223743.26.0.299504535353.issue11867@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Short glance into it, and after
commenting out 
    self.c_sock_close = self.c_sock_shutdown = True
in the parent process it ends up as
(maybe i can spend more time this evening):


15:36 ~/tmp $ python3 -E -Wd -m test -r -w -uall test_mailbox
Using random seed 9754656
[1/1] test_mailbox
/Users/steffen/usr/opt/py3k/lib/python3.3/mailbox.py:723:  ResourceWarning: unclosed <socket.socket object, fd=5, family=2, type=1, proto=0>
  return self._toc[key]
/Users/steffen/usr/opt/py3k/lib/python3.3/mailbox.py:77: ResourceWarning: unclosed <socket.socket object, fd=5, family=2, type=1, proto=0>
  return self.get_message(key)
1 test OK.
[118589 refs]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11867>
_______________________________________

From report at bugs.python.org  Tue Apr 19 16:52:52 2011
From: report at bugs.python.org (Axel Rau)
Date: Tue, 19 Apr 2011 14:52:52 +0000
Subject: [issue11837] smtplib._quote_periods triggers spurious type error in
	re.sub
In-Reply-To: <1302628161.84.0.82021620589.issue11837@psf.upfronthosting.co.za>
Message-ID: <1303224772.13.0.545611908996.issue11837@psf.upfronthosting.co.za>


Axel Rau <Axel.Rau at Chaos1.DE> added the comment:

One more hint: The bug does not happen with plain text mails, but can easily be reproduced with MIME attachments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11837>
_______________________________________

From report at bugs.python.org  Tue Apr 19 17:04:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2011 15:04:01 +0000
Subject: [issue11877] Mac OS X fsync() should really be fcntl(F_FULLFSYNC)
In-Reply-To: <1303212938.57.0.821096700769.issue11877@psf.upfronthosting.co.za>
Message-ID: <1303225441.09.0.748606256469.issue11877@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, it remembers a long story around ext3/ext4 and write barrier, with a specific problem in Firefox with SQLite.

http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man2/fsync.2.html
"     For applications that require tighter guarantees about the integrity of their data, Mac OS X provides
     the F_FULLFSYNC fcntl.  The F_FULLFSYNC fcntl asks the drive to flush all buffered data to permanent
     storage.  Applications, such as databases, that require a strict ordering of writes should use F_FULLF-
     SYNC to ensure that their data is written in the order they expect.  Please see fcntl(2) for more
     detail."

http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/
"fsync on Mac OS X: Since on Mac OS X the fsync command does not make the guarantee that bytes are written, SQLite sends a F_FULLFSYNC request to the kernel to ensures that the bytes are actually written through to the drive platter."

http://lwn.net/Articles/283161/

http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2008-September/001356.html
"
OTP-7471  On Mac OS X, file:sync/1 now guarantees that all filesystem
	      buffers are written to the disk by using the fcntl() with
	      F_FULLFSYNC option. Previously, file:sync/1 called fsync(),
	      which only guaranteed that the data had been transferred to
	      the disk drive. (Thanks to Jan Lehnardt.)"

http://lists.mindrot.org/pipermail/portawiki-discuss/2005-November/000002.html

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Tue Apr 19 17:17:29 2011
From: report at bugs.python.org (Michiel Van den Berghe)
Date: Tue, 19 Apr 2011 15:17:29 +0000
Subject: [issue11878] No SOAP libraries available for Python 3.x
In-Reply-To: <1303226249.65.0.757912799322.issue11878@psf.upfronthosting.co.za>
Message-ID: <1303226249.65.0.757912799322.issue11878@psf.upfronthosting.co.za>


New submission from Michiel Van den Berghe <michiel.vdb at gmail.com>:

There doesn't seem to exist a SOAP library for Python 3.x. Several different third party libraries exist for the 2.x releases, but none of these are being ported to 3.x. None of these modules are easily ported using 2to3 due to string encoding issues.

Seeing how SOAP is a major webservices technologies, I think Python should get its own standard SOAP module to keep up with its "batteries included" principle.

----------
components: Library (Lib)
messages: 134064
nosy: Michiel.Van.den.Berghe
priority: normal
severity: normal
status: open
title: No SOAP libraries available for Python 3.x
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11878>
_______________________________________

From report at bugs.python.org  Tue Apr 19 17:23:29 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 19 Apr 2011 15:23:29 +0000
Subject: [issue11878] No SOAP libraries available for Python 3.x
In-Reply-To: <1303226249.65.0.757912799322.issue11878@psf.upfronthosting.co.za>
Message-ID: <1303226609.88.0.372981291854.issue11878@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

This is something that should be handled on the trackers of any of the external SOAP libraries. If they are ported to Python 3 and are seen as best in class and are willing to move all development into the standard library, then inclusion could be considered.

It's unlikely that all of that will come together in time for the 3.3 release, as the library needs to be proven in the wild after being ported.

If someone does come up with a popular 3.x SOAP library, an email to python-dev or python-ideas would be enough to kick off an inclusion discussion.

----------
nosy: +brian.curtin
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11878>
_______________________________________

From report at bugs.python.org  Tue Apr 19 17:31:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Apr 2011 15:31:49 +0000
Subject: [issue8982] argparse docs cross reference Namespace as a class but
	the Namespace class is not documented
In-Reply-To: <1276350269.78.0.816004374409.issue8982@psf.upfronthosting.co.za>
Message-ID: <1303227109.21.0.185633304096.issue8982@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Attached patch adds a link target for :class:`Namespace` (already used in the docs) and adds a reference to it from for the first mentions of ?namespace object?.

Use ?hg import blah.diff? (after ?hg up 3.2?) to get the patch in the repo directly (with checkin message and my committer name) or usual patch(1) if you want to make amendments.

----------
keywords: +patch
Added file: http://bugs.python.org/file21723/fix-argparse-class-directive.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8982>
_______________________________________

From report at bugs.python.org  Tue Apr 19 17:33:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Apr 2011 15:33:31 +0000
Subject: [issue9896] Introspectable range objects
In-Reply-To: <1284835167.56.0.979385376089.issue9896@psf.upfronthosting.co.za>
Message-ID: <1303227211.89.0.459238149033.issue9896@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good, apart from the use of assertEquals (deprecated in favor of assertEqual).  I?d also remove ?merely? from the doc addition.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9896>
_______________________________________

From report at bugs.python.org  Tue Apr 19 17:33:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Apr 2011 15:33:38 +0000
Subject: [issue11276] 2to3: imports fixer doesn't update references to modules
	specified without attributes
In-Reply-To: <1298320370.6.0.707528298714.issue11276@psf.upfronthosting.co.za>
Message-ID: <1303227218.95.0.570711033643.issue11276@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11276>
_______________________________________

From report at bugs.python.org  Tue Apr 19 17:33:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Apr 2011 15:33:53 +0000
Subject: [issue11863] Enforce PEP 11 - remove support for legacy systems
In-Reply-To: <1303085337.86.0.669937619549.issue11863@psf.upfronthosting.co.za>
Message-ID: <1303227233.72.0.130990046895.issue11863@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11863>
_______________________________________

From report at bugs.python.org  Tue Apr 19 17:34:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2011 15:34:23 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1303227263.19.0.537963289868.issue11223@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Most of these names will be removed in 3.3:
> http://bugs.python.org/issue11863

Yeah, I know. My patch should be updated if #11863 is fixed before this issue.

Updated patch:
 - add 'pthread_version' key to threading._info()
 - test_os uses threading._info() to check if we are using linuxthreads

----------
Added file: http://bugs.python.org/file21724/threading_info-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Tue Apr 19 17:34:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Apr 2011 15:34:38 +0000
Subject: [issue11858] configparser.ExtendedInterpolation and section case
In-Reply-To: <1302972514.64.0.403074363027.issue11858@psf.upfronthosting.co.za>
Message-ID: <1303227278.66.0.387237637082.issue11858@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
stage:  -> test needed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11858>
_______________________________________

From report at bugs.python.org  Tue Apr 19 17:37:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2011 15:37:15 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1303227435.78.0.600276197028.issue11223@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Example on my Debian Sid:

>>> threading._info()
{'pthread_version': 'NPTL 2.11.2', 'use_semaphores': True, 'name': 'pthread'}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Tue Apr 19 17:42:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Apr 2011 15:42:07 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1303227263.19.0.537963289868.issue11223@psf.upfronthosting.co.za>
Message-ID: <1303227723.3489.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Yeah, I know. My patch should be updated if #11863 is fixed before this issue.
> 
> Updated patch:
>  - add 'pthread_version' key to threading._info()
>  - test_os uses threading._info() to check if we are using linuxthreads

The path which sets "pthread_version" should be inside "#ifdef
_POSIX_THREADS".

Also, some comments about the doc:
- you need a "versionadded" tag
- "use_semaphores" should explain that these semaphores are used for
locks; also the alternative is "use mutexes and condition variables",
not "use mutexes"
- you should not document unsupported platform names ("lwp", etc.); they
are already disabled (#error)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Tue Apr 19 17:44:42 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 19 Apr 2011 15:44:42 +0000
Subject: [issue11877] Mac OS X fsync() should really be fcntl(F_FULLFSYNC)
In-Reply-To: <1303212938.57.0.821096700769.issue11877@psf.upfronthosting.co.za>
Message-ID: <1303227882.99.0.244463586551.issue11877@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Traditionally the functions in os are thin wrappers around OS functions, this patch changes that for os.fsync.


Two nits wrt. the patch itself:
1) The behaviour on OSX should be documented in the stdlib reference,
   that currently says that os.fsync will call the C function fsync

2) The comment in the __APPLE__ case can be clearer, and should 
   explain the issue (as short as possible).


I'm -1 on merging this patch though, as the fsync function on OSX behaves just like the one on Linux, the fnctl option adds a stronger guarantee in that it forces a flush of the buffers on the storage device as well. The manpage for fsync on a linux host says:

   In case the hard disk has write cache enabled, the data may not really be on permanent storage when fsync/fdatasync return.

Adding the F_FULLSYNC option to os.fsync would be fine though (if it isn't already implemented)

The linux

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Tue Apr 19 17:45:37 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Apr 2011 15:45:37 +0000
Subject: [issue11867] Make test_mailbox deterministic
In-Reply-To: <1303132744.64.0.479347573965.issue11867@psf.upfronthosting.co.za>
Message-ID: <1303227937.84.0.159541070707.issue11867@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think the fix is to either put a try/except around the socket shutdown call, or to remove it entirely (I think things will still work right on linux without it).  If you leave the self.c_sock_close = True in, it should take care of the resource warning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11867>
_______________________________________

From report at bugs.python.org  Tue Apr 19 17:58:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Apr 2011 15:58:08 +0000
Subject: [issue8933] Invalid detection of metadata version
In-Reply-To: <1275927761.19.0.897367518837.issue8933@psf.upfronthosting.co.za>
Message-ID: <1303228688.68.0.54013816617.issue8933@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

?I?m putting this on standby until distutils2 is fully merged into the standard library and we have a clear workflow from packaging to d2 to d1.?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8933>
_______________________________________

From report at bugs.python.org  Tue Apr 19 18:03:35 2011
From: report at bugs.python.org (Michael Gold)
Date: Tue, 19 Apr 2011 16:03:35 +0000
Subject: [issue11879] TarFile.chown: should use TarInfo.uid if user lookup
	fails
In-Reply-To: <1303229015.7.0.433519463198.issue11879@psf.upfronthosting.co.za>
Message-ID: <1303229015.7.0.433519463198.issue11879@psf.upfronthosting.co.za>


New submission from Michael Gold <mgold at qnx.com>:

In TarFile.chown, if the lookup
  u = pwd.getpwnam(tarinfo.uname)[2]
fails, this line is used:
  u = pwd.getpwuid(tarinfo.uid)[2]

This will fail if the uid isn't in /etc/passwd.  I think "u = tarinfo.uid" would make more sense.  This fallback could also be used if the pwd module isn't present or tarinfo.uname isn't filled.  Here's a code sample:
    u = tarinfo.uid
    if tarinfo.uname and pwd:
        try: u = pwd.getpwnam(tarinfo.uname)[2]
        except KeyError: pass

The same issue applies to group lookup.

----------
components: Library (Lib)
messages: 134074
nosy: mgold-qnx
priority: normal
severity: normal
status: open
title: TarFile.chown: should use TarInfo.uid if user lookup fails
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11879>
_______________________________________

From report at bugs.python.org  Tue Apr 19 18:11:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Apr 2011 16:11:41 +0000
Subject: [issue10932] distutils.core.setup - data_files misbehaviour ?
In-Reply-To: <1295353825.23.0.755300594789.issue10932@psf.upfronthosting.co.za>
Message-ID: <1303229501.98.0.954546604543.issue10932@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can you remove all obsolete repositories and patches from this report and upload one complete patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10932>
_______________________________________

From report at bugs.python.org  Tue Apr 19 18:49:23 2011
From: report at bugs.python.org (higery)
Date: Tue, 19 Apr 2011 16:49:23 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1303231763.95.0.492689812537.issue828450@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

I'm not sure it is necessary to use TempdirManager here to write tests for MANIFEST reading.
The attachment is the test diff file against my last patch with the latest version.

Detail:
Step 1: Write sample MANIFEST strings to the MANIFEST file with '/' as separator and get the filelist of this file(actually just created from the sample strings)
Step 2: Change the os.sep to '\' and then run the sdist command, and a FileList will be generated. Bad effect is MANIFEST file will be re-written: write_manifest function called(method calling route: run->get_file_list->write_manifest). Because the content in MANIFEST has already been changed, we can just use the FileList object to get the filelist, instead of construct it from reading MANIFEST file again as other tests do.
Step 3: Compare filelist_1 generated in Step1 with filelist_2 in Step2, making sure that we have replace '\' with '/' for filelist_2. Yes, we just compare the content to make sure that we has done right thing and reading MANIFEST file with '/' as separator on the platform which os.sep is '\' is ok.

That's all.

----------
Added file: http://bugs.python.org/file21725/test_manifest_reading_sdist.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Tue Apr 19 18:51:05 2011
From: report at bugs.python.org (dholth)
Date: Tue, 19 Apr 2011 16:51:05 +0000
Subject: [issue11880] add a {dist-info} category to distutils2
In-Reply-To: <1303231865.42.0.936595329467.issue11880@psf.upfronthosting.co.za>
Message-ID: <1303231865.42.0.936595329467.issue11880@psf.upfronthosting.co.za>


New submission from dholth <dholth at fastmail.fm>:

In distutils2 there is currently no way to add files such as egg_info.txt that should be part of the package metadata. A new category named the same as the .dist-info directory would be a nice way to do it.

distutils2 should raise an error if any of the reserved files are overwritten with this feature or it should just copy these first overwriting with the reserved names.

It might be a good idea to disallow subdirectories in dist-info.

----------
assignee: tarek
components: Distutils2
messages: 134077
nosy: alexis, dholth, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: add a {dist-info} category to distutils2
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11880>
_______________________________________

From report at bugs.python.org  Tue Apr 19 18:53:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Apr 2011 16:53:45 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1303232025.22.0.505576927402.issue828450@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I'm not sure it is necessary to use TempdirManager here to write tests
> for MANIFEST reading.

Well, the sdist command has to run on some directory where some files exist, right?  So it?s better to do it in a temp dir that will automatically get cleaned up.

> Bad effect is MANIFEST file will be re-written:

You should read the docs for MANIFEST and sdist: a MANIFEST without the magic comment will not get overwritten (unless there?s a bug :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Tue Apr 19 18:55:04 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Apr 2011 16:55:04 +0000
Subject: [issue11875] OrderedDict.__reduce__ not threadsafe
In-Reply-To: <1303201704.87.0.690807992306.issue11875@psf.upfronthosting.co.za>
Message-ID: <E1QCECZ-0000ry-6a@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3150b6939731 by Raymond Hettinger in branch '2.7':
Issue 11875: Keep OrderedDict's __reduce__ from temporarily mutating the object.
http://hg.python.org/cpython/rev/3150b6939731

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11875>
_______________________________________

From report at bugs.python.org  Tue Apr 19 18:55:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Apr 2011 16:55:09 +0000
Subject: [issue11880] add a {dist-info} category to distutils2
In-Reply-To: <1303231865.42.0.936595329467.issue11880@psf.upfronthosting.co.za>
Message-ID: <1303232109.13.0.246089942998.issue11880@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This feature is two-fold: add a method to install_distinfo to make it write some data in some file; add a new resource category.

----------
assignee: tarek -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11880>
_______________________________________

From report at bugs.python.org  Tue Apr 19 19:13:37 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 19 Apr 2011 17:13:37 +0000
Subject: [issue10596] modulo operator bug
In-Reply-To: <1291204399.82.0.975884133816.issue10596@psf.upfronthosting.co.za>
Message-ID: <1303233217.33.0.652070050566.issue10596@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Uncle Timmy, was this the right thing to do?

----------
assignee: mark.dickinson -> tim_one
nosy: +rhettinger, tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10596>
_______________________________________

From report at bugs.python.org  Tue Apr 19 19:17:09 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 19 Apr 2011 17:17:09 +0000
Subject: [issue8426] multiprocessing.Queue fails to get() very large objects
In-Reply-To: <1271443086.56.0.51527518355.issue8426@psf.upfronthosting.co.za>
Message-ID: <1303233429.24.0.224654159341.issue8426@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> IMO, it would be nice if I could ask my queue, "Just what is your capacity
(in bytes, not entries) anyways?  I want to know how much I can put in here
without worrying about whether the remote side is dequeueing."  I guess I'd
settle for explicit documentation that the bound exists.

It is documented.
See the comment about the "underlying pipe".

>  But how should I
expect my code to be portable?  Are there platforms which provide less than
64k?  Less than 1k?  Less than 256 bytes?

It depends :-)
If the implementation is using pipes, under Linux before 2.6.9 (I think), a pipe was limited by the size of a page, i.e. 4K on x86.
Now, it's 64K.
If it's a Unix socket (via socketpair), the maximum size can be set through sysctl, etc.
So you can't basically state a limit, and IMHO, you should't be concerned with that if you want your code to be portable.
I find the warning excplicit enough, be that's maybe because I'm familiar with this low-level details.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8426>
_______________________________________

From report at bugs.python.org  Tue Apr 19 19:26:47 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 19 Apr 2011 17:26:47 +0000
Subject: [issue11849] ElementTree memory leak
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1303234007.74.0.486589590701.issue11849@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> BTW, after utilize lxml instead of ElementTree, such phenomenon of increasing memory usage disappeared.

If you looked at the link I posted, you'll see that lxml had some similar issues and solved it by calling malloc_trim systematically when freeing memory.
It could also be heap fragmentation, though.

To go further, it'd be nice if you could provide the output of
valgrind --tool=memcheck --leak-check=full --suppressions=Misc/valgrind-python.supp python <test script>
after uncommenting relevant lines in Misc/valgrind-python.supp (see http://svn.python.org/projects/python/trunk/Misc/README.valgrind ).
It will either confirm a memory leak or malloc issue (I still favour the later).

By the way, does

while True:
    XML(gen_xml())

lead to a constant memory usage increase ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Tue Apr 19 19:39:22 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 19 Apr 2011 17:39:22 +0000
Subject: [issue11877] Mac OS X fsync() should really be fcntl(F_FULLFSYNC)
In-Reply-To: <1303212938.57.0.821096700769.issue11877@psf.upfronthosting.co.za>
Message-ID: <1303234762.52.0.706759541504.issue11877@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

I know that POSIX makes no guarantee regarding durable writes, but IMHO that's definitely wrong, in the sense that when one calls fsync, he expects the data to be committed to disk and be durable.
Fixing this deficiency through Python's exposed fsync might thus be a good idea (for example, the Window version probably doesn't call fsync, so it's already not a direct mapping).

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Tue Apr 19 20:15:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Apr 2011 18:15:36 +0000
Subject: [issue11875] OrderedDict.__reduce__ not threadsafe
In-Reply-To: <1303201704.87.0.690807992306.issue11875@psf.upfronthosting.co.za>
Message-ID: <E1QCFSX-0007yb-S7@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 50a89739836f by Raymond Hettinger in branch '3.1':
Issue 11875: Keep OrderedDict's __reduce__ from temporarily mutating the object.
http://hg.python.org/cpython/rev/50a89739836f

New changeset a7ac7a7c8c78 by Raymond Hettinger in branch '3.2':
Issue 11875: Keep OrderedDict's __reduce__ from temporarily mutating the object.
http://hg.python.org/cpython/rev/a7ac7a7c8c78

New changeset 928f17923b0d by Raymond Hettinger in branch 'default':
Issue 11875: Keep OrderedDict's __reduce__ from temporarily mutating the object.
http://hg.python.org/cpython/rev/928f17923b0d

New changeset 937385024601 by Raymond Hettinger in branch '3.2':
Issue 11875: Keep OrderedDict's __reduce__ from temporarily mutating the object.
http://hg.python.org/cpython/rev/937385024601

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11875>
_______________________________________

From report at bugs.python.org  Tue Apr 19 20:17:02 2011
From: report at bugs.python.org (Torsten Becker)
Date: Tue, 19 Apr 2011 18:17:02 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1303237022.63.0.757237525412.issue11828@psf.upfronthosting.co.za>


Torsten Becker <torsten.becker at gmail.com> added the comment:

Hi, Jes?s, I merged the patch up in the branches "startswith-slices-issue11828-3.2" [1] and "startswith-slices-issue11828-3.3" [2] in my hg repository.

[1]: https://bitbucket.org/t0rsten/cpython/changeset/49028581e43a
[2]: https://bitbucket.org/t0rsten/cpython/changeset/eafafe258362

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Tue Apr 19 20:17:10 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Tue, 19 Apr 2011 18:17:10 +0000
Subject: [issue11881] Add list.get
In-Reply-To: <1303237030.15.0.691261083336.issue11881@psf.upfronthosting.co.za>
Message-ID: <1303237030.15.0.691261083336.issue11881@psf.upfronthosting.co.za>


New submission from Filip Gruszczy?ski <gruszczy at gmail.com>:

I have proposed on Core Mentorship list to add get(index, default) method to list object. I was suggested to bring it up here and also told, that improving operator module could be a better solution. This is why I would like to ask, if it makes sense to work on this?

I attach a patch for list objects. I would post a link to Core Mentorship thread, but I believe the archive is private.

The original idea came from a question on StackOverflow: http://stackoverflow.com/questions/2492087/how-to-get-the-nth-element-of-a-python-list-or-a-default-if-not-available

----------
components: Interpreter Core
files: list.get.patch
keywords: patch
messages: 134087
nosy: gruszczy
priority: normal
severity: normal
status: open
title: Add list.get
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file21726/list.get.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11881>
_______________________________________

From report at bugs.python.org  Tue Apr 19 20:20:46 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 19 Apr 2011 18:20:46 +0000
Subject: [issue11881] Add list.get
In-Reply-To: <1303237030.15.0.691261083336.issue11881@psf.upfronthosting.co.za>
Message-ID: <1303237246.44.0.00652071256684.issue11881@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Sorry, this has come up before and was rejected.

----------
nosy: +rhettinger
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11881>
_______________________________________

From report at bugs.python.org  Tue Apr 19 21:08:53 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 19 Apr 2011 19:08:53 +0000
Subject: [issue11875] OrderedDict.__reduce__ not threadsafe
In-Reply-To: <1303201704.87.0.690807992306.issue11875@psf.upfronthosting.co.za>
Message-ID: <1303240133.82.0.88643890056.issue11875@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Mario, I removed the unnecessary mutation, but remember that OrderedDict's are not thread-safe in general.  Anything that updates an OrderedDict will temporarily leave it in an inconsistent state while the links and mappings are being updated.  

That being said, it isn't hard to create a subclass with a lock around each of the mutating methods: setitem, delitem, clear, popitem, pop, move_to_end, setdefault, init, and update.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11875>
_______________________________________

From report at bugs.python.org  Tue Apr 19 21:10:58 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 19 Apr 2011 19:10:58 +0000
Subject: [issue11881] Add list.get
In-Reply-To: <1303237030.15.0.691261083336.issue11881@psf.upfronthosting.co.za>
Message-ID: <1303240258.23.0.99036483042.issue11881@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

What did you have in mind for the operator module?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11881>
_______________________________________

From report at bugs.python.org  Tue Apr 19 21:41:53 2011
From: report at bugs.python.org (Kasun Herath)
Date: Tue, 19 Apr 2011 19:41:53 +0000
Subject: [issue11882] test_imaplib failed on x86 ubuntu
In-Reply-To: <1303242113.82.0.307299264452.issue11882@psf.upfronthosting.co.za>
Message-ID: <1303242113.82.0.307299264452.issue11882@psf.upfronthosting.co.za>


New submission from Kasun Herath <kasunh01 at gmail.com>:

test_imaplib failed on x86 ubuntu machine with following error(s)

======================================================================
FAIL: test_Internaldate2tuple (test.test_imaplib.TestImaplib)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/kasun/workplace/cpython/Lib/test/test_imaplib.py", line 31, in test_Internaldate2tuple
    self.assertEqual(time.mktime(tt), t0)
AssertionError: 946683000.0 != 946684800

----------------------------------------------------------------------
Ran 2 tests in 0.002s

FAILED (failures=1)
test test_imaplib failed -- Traceback (most recent call last):
  File "/home/kasun/workplace/cpython/Lib/test/test_imaplib.py", line 31, in test_Internaldate2tuple
    self.assertEqual(time.mktime(tt), t0)
AssertionError: 946683000.0 != 946684800

1 test failed:
    test_imaplib

----------
components: Tests
messages: 134091
nosy: kasun
priority: normal
severity: normal
status: open
title: test_imaplib failed on x86 ubuntu
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11882>
_______________________________________

From report at bugs.python.org  Tue Apr 19 21:42:13 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Tue, 19 Apr 2011 19:42:13 +0000
Subject: [issue11881] Add list.get
In-Reply-To: <1303237030.15.0.691261083336.issue11881@psf.upfronthosting.co.za>
Message-ID: <1303242133.24.0.14380879582.issue11881@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Nick Coghlan suggested, that operator.getitem could be extended to accept default value. How does it sound to you?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11881>
_______________________________________

From report at bugs.python.org  Tue Apr 19 21:49:39 2011
From: report at bugs.python.org (Prashant Kumar)
Date: Tue, 19 Apr 2011 19:49:39 +0000
Subject: [issue10932] distutils.core.setup - data_files misbehaviour ?
In-Reply-To: <1295353825.23.0.755300594789.issue10932@psf.upfronthosting.co.za>
Message-ID: <1303242579.87.0.497531213217.issue10932@psf.upfronthosting.co.za>


Changes by Prashant Kumar <contactprashantat at gmail.com>:


Removed file: http://bugs.python.org/file21720/test_command_sdist.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10932>
_______________________________________

From report at bugs.python.org  Tue Apr 19 21:49:52 2011
From: report at bugs.python.org (Prashant Kumar)
Date: Tue, 19 Apr 2011 19:49:52 +0000
Subject: [issue10932] distutils.core.setup - data_files misbehaviour ?
In-Reply-To: <1295353825.23.0.755300594789.issue10932@psf.upfronthosting.co.za>
Message-ID: <1303242592.58.0.361936475633.issue10932@psf.upfronthosting.co.za>


Changes by Prashant Kumar <contactprashantat at gmail.com>:


Removed file: http://bugs.python.org/file21721/fix-manifest.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10932>
_______________________________________

From report at bugs.python.org  Tue Apr 19 22:00:06 2011
From: report at bugs.python.org (Prashant Kumar)
Date: Tue, 19 Apr 2011 20:00:06 +0000
Subject: [issue10932] distutils.core.setup - data_files misbehaviour ?
In-Reply-To: <1295353825.23.0.755300594789.issue10932@psf.upfronthosting.co.za>
Message-ID: <1303243206.05.0.690741815511.issue10932@psf.upfronthosting.co.za>


Prashant Kumar <contactprashantat at gmail.com> added the comment:

Sure, patch.diff is a complete one.

----------
Added file: http://bugs.python.org/file21727/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10932>
_______________________________________

From report at bugs.python.org  Tue Apr 19 22:00:52 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 19 Apr 2011 20:00:52 +0000
Subject: [issue11881] Add list.get
In-Reply-To: <1303237030.15.0.691261083336.issue11881@psf.upfronthosting.co.za>
Message-ID: <1303243252.32.0.594010696101.issue11881@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> operator.getitem could be extended to accept default value

That would be relatively harmless.  And because it isn't type specific to lists, it would be applicable to other types that might better use cases than lists do.

If you want to pursue this, please change the name of this tracker item and re-open it.

Do spend some time thinking about whether it is good language design.  Is "getitem(s, i, dft)" better than "s[i] if i < len(s) else dft" or list unpacking, etc.?  Various meanings of better include 1) the preferred way to do it, 2) a faster way to do it, 3) surrounding code reads significantly better using the new construct, and 4) it's worth taking the time to learn and remember it.  By adding this to the language, you're telling people that this is the RightThingToDo(tm).  

Programming this is easy -- the hard part is knowing whether it is worthwhile (a question on StackOverflow is not sufficient motivation).  You might also want to grep lots of real world code to see if there would be actual benefits to real code or whether it will end-up being cruft that we put in because it was easy and cute.  Python has had 20+ years of development without needing this, so it's worth really thinking about it before going ahead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11881>
_______________________________________

From report at bugs.python.org  Tue Apr 19 22:16:20 2011
From: report at bugs.python.org (Nasos Dousis)
Date: Tue, 19 Apr 2011 20:16:20 +0000
Subject: [issue10910] pyport.h FreeBSD/Mac OS X "fix" causes errors in C++
	compilation
In-Reply-To: <1303089647.11.0.346812766679.issue10910@psf.upfronthosting.co.za>
Message-ID: <BANLkTikrMwUrRZO8jLzoX+R0uokdpbHaxg@mail.gmail.com>


Nasos Dousis <ndousis at gmail.com> added the comment:

Meador et al,

Thanks for your attention to this issue.  Just to clarify, I can eliminate
the compile errors by prepending

#include "Python.h"

to any source file with

#include<boost/python.hpp>

Also, my code compiles in Linux, with and without the Python.h header:

$ uname -a
Linux nxx.xx.com 2.6.18-128.1.14.el5 #1 SMP Wed Jun 17 06:38:05 EDT 2009
x86_64 x86_64 x86_64 GNU/Linux

with the same flags as before:

cd $(BOOST); ./bootstrap.sh --prefix=$(CURDIR)/$(BOOST)
--with-python-root=$(CURDIR)/$(PYTHON_DIR) --with-python-version=2.7
--with-libraries=mpi

cd $(PYTHON_SRCDIR) ; ./configure --enable-shared
--prefix=$(CURDIR)/$(PYTHON_DIR)
cd $(PYTHON_SRCDIR) ; make -j $(NUMPROC) && make install

Thanks again,
Nasos

----------
Added file: http://bugs.python.org/file21728/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10910>
_______________________________________
-------------- next part --------------
Meador et al,<div><br></div><div>Thanks for your attention to this issue. ??Just to clarify, I can eliminate the compile errors by prepending??</div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br>
</span></div><div>#<span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">include &quot;Python.h&quot;</span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br>
</span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">to any source file with??</span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br>
</span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">#include&lt;boost/python.hpp&gt;</span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br>
</span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">Also,??</span>my code compiles in Linux, with and without the Python.h header:</div><div>
<meta charset="utf-8"><div><br></div><div>$ uname -a</div><div>Linux <a href="http://nxx.xx.com">nxx.xx.com</a> 2.6.18-128.1.14.el5 #1 SMP Wed Jun 17 06:38:05 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux<br></div></div><div><br>
</div><div>with the same flags as before:</div><div><br></div><div><meta charset="utf-8"><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">cd $(BOOST); ./bootstrap.sh --prefix=$(CURDIR)/$(BOOST) --with-python-root=$(CURDIR)/$(PYTHON_DIR) --with-python-version=2.7 --with-libraries=mpi<br>
<br>cd $(PYTHON_SRCDIR) ; ./configure --enable-shared --prefix=$(CURDIR)/$(PYTHON_DIR)<br>cd $(PYTHON_SRCDIR) ; make -j $(NUMPROC) &amp;&amp; make install<br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br>
</span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">Thanks again,</span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">Nasos</span></div>

From report at bugs.python.org  Tue Apr 19 22:26:40 2011
From: report at bugs.python.org (Mario Juric)
Date: Tue, 19 Apr 2011 20:26:40 +0000
Subject: [issue11875] OrderedDict.__reduce__ not threadsafe
In-Reply-To: <1303201704.87.0.690807992306.issue11875@psf.upfronthosting.co.za>
Message-ID: <1303244800.95.0.979903024953.issue11875@psf.upfronthosting.co.za>


Mario Juric <mjuric at ias.edu> added the comment:

Hi Raymond,

Excellent! Many thanks for such a quick fix, this has been bugging us for months!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11875>
_______________________________________

From report at bugs.python.org  Tue Apr 19 22:43:31 2011
From: report at bugs.python.org (Daniel Urban)
Date: Tue, 19 Apr 2011 20:43:31 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1303245811.02.0.750959202745.issue1294232@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

Thanks for the review!

I've updated my patch:
- renamed it to _PyType_CalculateMetaclass
- in __build_class__ call it even when a metaclass is declared
- added a test for this case (which fails with my previous patch)

However I noticed another problem: the declared metaclass (the object passed with the metaclass keyword in the class definition) according to PEP 3115 can be any callable object, not only a PyTypeObject. Problems:

1. In this case, PyType_IsSubtype will be called on something that is not a PyTypeObject (I don't know if that's a big problem, currently it seems to work).

2. The bigger problem: a simple construct, like:

class X(object, metaclass=func):
    pass

(where func is for example a function) won't work, because in _PyType_CalculateMetaclass it will detect, that func isn't a super- or subtype of object.__class__, and will raise an exception: "metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases".

My first idea to solve this problem is to ignore this case in __build_class__ (check for a returned NULL, and call PyErr_Clear), and use the declared metaclass. (I don't know, if this can cause other problems, I haven't thought much about it yet.)

----------
Added file: http://bugs.python.org/file21729/issue_1294232_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Tue Apr 19 22:54:07 2011
From: report at bugs.python.org (Kasun Herath)
Date: Tue, 19 Apr 2011 20:54:07 +0000
Subject: [issue8809] smtplib should support SSL contexts
In-Reply-To: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>
Message-ID: <1303246447.1.0.806966649607.issue8809@psf.upfronthosting.co.za>


Kasun Herath <kasunh01 at gmail.com> added the comment:

I did a patch that allows smtplib.SMTP_SSL constructor to accept an optional SSLContext

----------
keywords: +patch
nosy: +kasun
Added file: http://bugs.python.org/file21730/smtp_sslcontext.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8809>
_______________________________________

From report at bugs.python.org  Tue Apr 19 22:58:10 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 19 Apr 2011 20:58:10 +0000
Subject: [issue11875] OrderedDict.__reduce__ not threadsafe
In-Reply-To: <1303201704.87.0.690807992306.issue11875@psf.upfronthosting.co.za>
Message-ID: <1303246690.53.0.190220791239.issue11875@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The call to self.__class__() can break subclasses of OrderedDict for two reasons:
- The subclass constructor may have a different signature
- Attributes set by the subclass.__init__ are removed from the pickle::

import collections, pickle

class Mydict(collections.OrderedDict):
    def __init__(self, *args, name=None, **kwargs):
        super().__init__(*args, **kwargs)
        self.name = name

a = Mydict(name='foo')
b = pickle.loads(pickle.dumps(a))
print(a.name, b.name)

Previously, the 'name' would be correctly copied, now it is reset to None.

----------
nosy: +amaury.forgeotdarc
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11875>
_______________________________________

From report at bugs.python.org  Tue Apr 19 22:59:23 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 19 Apr 2011 20:59:23 +0000
Subject: [issue11883] Call connect() before sending an email with smtplib
In-Reply-To: <1303246763.2.0.10135500331.issue11883@psf.upfronthosting.co.za>
Message-ID: <1303246763.2.0.10135500331.issue11883@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hi, following up http://mail.python.org/pipermail/docs/2011-April/003742.html here are a couple of patches to call connect() after smtplib.SMTP() and sendmail(). Patches are:

2.7: to be applied in 2.7 and merged into 3.1
3.2: to be applied in 3.2 and merged into default

That's because in 3.2 we have a change in the example to use send_message() instead of sendmail() (in order to allow binary contents), and so there's also a small fix to actually make use of send_message() email-simple.

----------
assignee: docs at python
components: Documentation
files: smtp_connect-2.7.patch
keywords: patch
messages: 134100
nosy: docs at python, r.david.murray, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Call connect() before sending an email with smtplib
Added file: http://bugs.python.org/file21731/smtp_connect-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11883>
_______________________________________

From report at bugs.python.org  Tue Apr 19 23:00:43 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 19 Apr 2011 21:00:43 +0000
Subject: [issue11883] Call connect() before sending an email with smtplib
In-Reply-To: <1303246763.2.0.10135500331.issue11883@psf.upfronthosting.co.za>
Message-ID: <1303246843.1.0.793426088657.issue11883@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


Added file: http://bugs.python.org/file21732/smtp_connect-3.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11883>
_______________________________________

From report at bugs.python.org  Tue Apr 19 23:04:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2011 21:04:14 +0000
Subject: [issue11863] Enforce PEP 11 - remove support for legacy systems
In-Reply-To: <1303085337.86.0.669937619549.issue11863@psf.upfronthosting.co.za>
Message-ID: <1303247054.29.0.294311351259.issue11863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Python/thread.c contains a reference to a missing file:

#ifdef PLAN9_THREADS
#include "thread_plan9.h"
#endif

But I don't see where PLAN9_THREADS is defined.

remove_threads.patch removes these 3 lines.

--

There is also an unused file: Python/thread_wince.c. Can it be removed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11863>
_______________________________________

From report at bugs.python.org  Tue Apr 19 23:06:56 2011
From: report at bugs.python.org (Daniel Urban)
Date: Tue, 19 Apr 2011 21:06:56 +0000
Subject: [issue9896] Introspectable range objects
In-Reply-To: <1284835167.56.0.979385376089.issue9896@psf.upfronthosting.co.za>
Message-ID: <1303247216.7.0.205399374978.issue9896@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

Thanks, I've corrected my patch.

----------
Added file: http://bugs.python.org/file21733/range_attrs_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9896>
_______________________________________

From report at bugs.python.org  Tue Apr 19 23:08:45 2011
From: report at bugs.python.org (Daniel Urban)
Date: Tue, 19 Apr 2011 21:08:45 +0000
Subject: [issue11875] OrderedDict.__reduce__ not threadsafe
In-Reply-To: <1303201704.87.0.690807992306.issue11875@psf.upfronthosting.co.za>
Message-ID: <1303247325.79.0.309750559097.issue11875@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11875>
_______________________________________

From report at bugs.python.org  Tue Apr 19 23:13:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Apr 2011 21:13:56 +0000
Subject: [issue11863] Enforce PEP 11 - remove support for legacy systems
In-Reply-To: <1303247054.29.0.294311351259.issue11863@psf.upfronthosting.co.za>
Message-ID: <1303247633.3741.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Python/thread.c contains a reference to a missing file:
> 
> #ifdef PLAN9_THREADS
> #include "thread_plan9.h"
> #endif
> 
> But I don't see where PLAN9_THREADS is defined.
> 
> remove_threads.patch removes these 3 lines.
> 
> --
> 
> There is also an unused file: Python/thread_wince.c. Can it be removed?

+1 to both.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11863>
_______________________________________

From report at bugs.python.org  Tue Apr 19 23:15:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Apr 2011 21:15:11 +0000
Subject: [issue11882] test_imaplib failed on x86 ubuntu
In-Reply-To: <1303242113.82.0.307299264452.issue11882@psf.upfronthosting.co.za>
Message-ID: <1303247711.97.0.584753031272.issue11882@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/issue11882>
_______________________________________

From report at bugs.python.org  Tue Apr 19 23:19:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2011 21:19:42 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1303227723.3489.4.camel@localhost.localdomain>
Message-ID: <1303247977.21240.15.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The path which sets "pthread_version" should be inside "#ifdef
> _POSIX_THREADS".
> Also, some comments about the doc:
> - you need a "versionadded" tag

Right, fixed.

> - "use_semaphores" should explain that these semaphores are used for
> locks; also the alternative is "use mutexes and condition variables",
> not "use mutexes"

Hum, a boolean was not a good idea. I replaced this key by:

 * 'lock' (string): name of the lock implementation

   * 'semaphore': a lock uses a semaphore
   * 'mutex+cond': a lock uses a mutex and a condition variable

I also renamed 'name' key to 'thread', so 'thread' is the name of the
*thread* implementation, and 'lock' is the name of the *lock*
implementation.

For example, test_threadsignals now uses:
-----------
USING_PTHREAD_COND = (info['thread'] == 'pthread'
                      and info['lock'] == 'mutex+cond')
...
@unittest.skipIf(USING_PTHREAD_COND,
                 'POSIX condition variables cannot be interrupted')
-----------

I think that the test is more clear than:
-----------
@unittest.skipIf(info['name'] == 'pthread' and not
info['use_semaphores'],
                'POSIX mutexes cannot be interrupted')
-----------

(the message was wrong, the interrupt issue is on the condition, not on
the mutex)

> - you should not document unsupported platform names ("lwp", etc.); they
> are already disabled (#error)

Oh, I didn't realize that they were already unsupported as a compilation
error. Ok, fixed. I also removed "wince": I realized that thread_wince.h
is not used (see #11863).

The new patch (version 3) marks also PyThread_Info() as private (rename
it to _PyThread_Info).

----------
Added file: http://bugs.python.org/file21734/threading_info-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________
-------------- next part --------------
diff --git a/Doc/library/threading.rst b/Doc/library/threading.rst
--- a/Doc/library/threading.rst
+++ b/Doc/library/threading.rst
@@ -175,6 +175,27 @@ This module defines the following functi
    Availability: Windows, systems with POSIX threads.
 
 
+.. function:: _info()
+
+   Return a dictionary with informations about the thread implementation.
+   The ``'thread'`` key gives the name of the thread implementation:
+
+    * ``'nt'``: Windows threads
+    * ``'os2'``: OS/2 threads
+    * ``'pthread'``: POSIX threads
+    * ``'solaris'``: Solaris threads
+
+   POSIX threads have two more keys:
+
+    * ``'pthread_version'`` (string): name and version of the pthread library
+    * ``'lock'`` (string): name of the lock implementation
+
+      * ``'semaphore'``: a lock uses a semaphore
+      * ``'mutex+cond'``: a lock uses a mutex and a condition variable
+
+   .. versionadded:: 3.3
+
+
 This module also defines the following constant:
 
 .. data:: TIMEOUT_MAX
diff --git a/Include/pythread.h b/Include/pythread.h
--- a/Include/pythread.h
+++ b/Include/pythread.h
@@ -32,7 +32,7 @@ PyAPI_FUNC(int) PyThread_acquire_lock(Py
    on a lock (see PyThread_acquire_lock_timed() below).
    PY_TIMEOUT_MAX is the highest usable value (in microseconds) of that
    type, and depends on the system threading API.
-   
+
    NOTE: this isn't the same value as `_thread.TIMEOUT_MAX`.  The _thread
    module exposes a higher-level API, with timeouts expressed in seconds
    and floating-point numbers allowed.
@@ -74,6 +74,8 @@ PyAPI_FUNC(void) PyThread_release_lock(P
 PyAPI_FUNC(size_t) PyThread_get_stacksize(void);
 PyAPI_FUNC(int) PyThread_set_stacksize(size_t);
 
+PyAPI_FUNC(PyObject*) _PyThread_Info(void);
+
 /* Thread Local Storage (TLS) API */
 PyAPI_FUNC(int) PyThread_create_key(void);
 PyAPI_FUNC(void) PyThread_delete_key(int);
diff --git a/Lib/test/test_os.py b/Lib/test/test_os.py
--- a/Lib/test/test_os.py
+++ b/Lib/test/test_os.py
@@ -27,12 +27,15 @@ except ImportError:
 # and unmaintained) linuxthreads threading library.  There's an issue
 # when combining linuxthreads with a failed execv call: see
 # http://bugs.python.org/issue4970.
-if (hasattr(os, "confstr_names") and
-    "CS_GNU_LIBPTHREAD_VERSION" in os.confstr_names):
-    libpthread = os.confstr("CS_GNU_LIBPTHREAD_VERSION")
-    USING_LINUXTHREADS= libpthread.startswith("linuxthreads")
-else:
-    USING_LINUXTHREADS= False
+USING_LINUXTHREADS = False
+if threading:
+    info = threading._info()
+    try:
+        pthread_version = info['pthread_version']
+    except KeyError:
+        pass
+    else:
+        USING_LINUXTHREADS = pthread_version.startswith("linuxthreads")
 
 # Tests creating TESTFN
 class FileTests(unittest.TestCase):
diff --git a/Lib/test/test_threading.py b/Lib/test/test_threading.py
--- a/Lib/test/test_threading.py
+++ b/Lib/test/test_threading.py
@@ -718,6 +718,16 @@ class BoundedSemaphoreTests(lock_tests.B
 class BarrierTests(lock_tests.BarrierTests):
     barriertype = staticmethod(threading.Barrier)
 
+
+class MiscTests(unittest.TestCase):
+    def test_info(self):
+        info = threading._info()
+        self.assertIn(info['thread'],
+                      'nt os2 pthread solaris'.split())
+        if info['thread'] == 'pthread':
+            self.assertIn(info['lock'], ('semaphore', 'mutex+cond'))
+
+
 def test_main():
     test.support.run_unittest(LockTests, PyRLockTests, CRLockTests, EventTests,
                               ConditionAsRLockTests, ConditionTests,
@@ -725,7 +735,7 @@ def test_main():
                               ThreadTests,
                               ThreadJoinOnShutdown,
                               ThreadingExceptionTests,
-                              BarrierTests
+                              BarrierTests, MiscTests,
                               )
 
 if __name__ == "__main__":
diff --git a/Lib/test/test_threadsignals.py b/Lib/test/test_threadsignals.py
--- a/Lib/test/test_threadsignals.py
+++ b/Lib/test/test_threadsignals.py
@@ -14,6 +14,9 @@ if sys.platform[:3] in ('win', 'os2') or
 process_pid = os.getpid()
 signalled_all=thread.allocate_lock()
 
+info = thread.info()
+USING_PTHREAD_COND = (info['thread'] == 'pthread'
+                      and info['lock'] == 'mutex+cond')
 
 def registerSignals(for_usr1, for_usr2, for_alrm):
     usr1 = signal.signal(signal.SIGUSR1, for_usr1)
@@ -70,6 +73,8 @@ class ThreadSignals(unittest.TestCase):
     def alarm_interrupt(self, sig, frame):
         raise KeyboardInterrupt
 
+    @unittest.skipIf(USING_PTHREAD_COND,
+                     'POSIX condition variables cannot be interrupted')
     def test_lock_acquire_interruption(self):
         # Mimic receiving a SIGINT (KeyboardInterrupt) with SIGALRM while stuck
         # in a deadlock.
@@ -91,6 +96,8 @@ class ThreadSignals(unittest.TestCase):
         finally:
             signal.signal(signal.SIGALRM, oldalrm)
 
+    @unittest.skipIf(USING_PTHREAD_COND,
+                     'POSIX condition variables cannot be interrupted')
     def test_rlock_acquire_interruption(self):
         # Mimic receiving a SIGINT (KeyboardInterrupt) with SIGALRM while stuck
         # in a deadlock.
diff --git a/Lib/threading.py b/Lib/threading.py
--- a/Lib/threading.py
+++ b/Lib/threading.py
@@ -19,7 +19,7 @@ from collections import deque
 
 __all__ = ['active_count', 'Condition', 'current_thread', 'enumerate', 'Event',
            'Lock', 'RLock', 'Semaphore', 'BoundedSemaphore', 'Thread', 'Barrier',
-           'Timer', 'setprofile', 'settrace', 'local', 'stack_size']
+           'Timer', 'setprofile', 'settrace', 'local', 'stack_size', '_info']
 
 # Rename some stuff so "from threading import *" is safe
 _start_new_thread = _thread.start_new_thread
@@ -31,6 +31,7 @@ try:
 except AttributeError:
     _CRLock = None
 TIMEOUT_MAX = _thread.TIMEOUT_MAX
+_info = _thread.info
 del _thread
 
 
diff --git a/Modules/_threadmodule.c b/Modules/_threadmodule.c
--- a/Modules/_threadmodule.c
+++ b/Modules/_threadmodule.c
@@ -1221,13 +1221,22 @@ requiring allocation in multiples of the
 (4kB pages are common; using multiples of 4096 for the stack size is\n\
 the suggested approach in the absence of more specific information).");
 
+static PyObject *
+thread_info(PyObject *self)
+{
+    return _PyThread_Info();
+}
+
+PyDoc_STRVAR(thread_info_doc,
+"info() -> dict\n\
+\n\
+Informations about the thread implementation.");
+
 static PyMethodDef thread_methods[] = {
     {"start_new_thread",        (PyCFunction)thread_PyThread_start_new_thread,
-                            METH_VARARGS,
-                            start_new_doc},
+     METH_VARARGS, start_new_doc},
     {"start_new",               (PyCFunction)thread_PyThread_start_new_thread,
-                            METH_VARARGS,
-                            start_new_doc},
+     METH_VARARGS, start_new_doc},
     {"allocate_lock",           (PyCFunction)thread_PyThread_allocate_lock,
      METH_NOARGS, allocate_doc},
     {"allocate",                (PyCFunction)thread_PyThread_allocate_lock,
@@ -1243,8 +1252,9 @@ static PyMethodDef thread_methods[] = {
     {"_count",                  (PyCFunction)thread__count,
      METH_NOARGS, _count_doc},
     {"stack_size",              (PyCFunction)thread_stack_size,
-                            METH_VARARGS,
-                            stack_size_doc},
+     METH_VARARGS, stack_size_doc},
+    {"info",                    (PyCFunction)thread_info,
+     METH_NOARGS, thread_info_doc},
     {NULL,                      NULL}           /* sentinel */
 };
 
@@ -1310,7 +1320,7 @@ PyInit__thread(void)
     d = PyModule_GetDict(m);
     ThreadError = PyExc_RuntimeError;
     Py_INCREF(ThreadError);
-    
+
     PyDict_SetItemString(d, "error", ThreadError);
     Locktype.tp_doc = lock_doc;
     Py_INCREF(&Locktype);
diff --git a/Python/thread.c b/Python/thread.c
--- a/Python/thread.c
+++ b/Python/thread.c
@@ -100,6 +100,7 @@ static size_t _pythread_stacksize = 0;
 #endif
 
 #ifdef SOLARIS_THREADS
+#define PYTHREAD_NAME "solaris"
 #include "thread_solaris.h"
 #endif
 
@@ -115,6 +116,7 @@ static size_t _pythread_stacksize = 0;
 #endif
 
 #ifdef _POSIX_THREADS
+#define PYTHREAD_NAME "pthread"
 #include "thread_pthread.h"
 #endif
 
@@ -124,14 +126,17 @@ static size_t _pythread_stacksize = 0;
 #endif
 
 #ifdef NT_THREADS
+#define PYTHREAD_NAME "nt"
 #include "thread_nt.h"
 #endif
 
 #ifdef OS2_THREADS
+#define PYTHREAD_NAME "os2"
 #include "thread_os2.h"
 #endif
 
 #ifdef PLAN9_THREADS
+#define PYTHREAD_NAME "plan9"
 #include "thread_plan9.h"
 #endif
 
@@ -409,3 +414,55 @@ PyThread_ReInitTLS(void)
 }
 
 #endif /* Py_HAVE_NATIVE_TLS */
+
+PyObject*
+_PyThread_Info(void)
+{
+    PyObject *info, *value;
+    int ret;
+    char buffer[255];
+    int len;
+
+    info = PyDict_New();
+    if (info == NULL)
+        return NULL;
+
+    value = PyUnicode_FromString(PYTHREAD_NAME);
+    ret = PyDict_SetItemString(info, "thread", value);
+    Py_DECREF(value);
+    if (ret)
+        goto error;
+
+#ifdef _POSIX_THREADS
+#ifdef USE_SEMAPHORES
+    value = PyUnicode_FromString("semaphore");
+#else
+    value = PyUnicode_FromString("mutex+cond");
+#endif
+    if (value == NULL)
+        return NULL;
+    ret = PyDict_SetItemString(info, "lock", value);
+    Py_DECREF(value);
+    if (ret)
+        goto error;
+
+#if defined(HAVE_CONFSTR) && defined(_CS_GNU_LIBPTHREAD_VERSION)
+    len = confstr(_CS_GNU_LIBPTHREAD_VERSION, buffer, sizeof(buffer));
+    if (0 < len && len < sizeof(buffer)) {
+        value = PyUnicode_DecodeFSDefaultAndSize(buffer, len-1);
+        if (value == NULL)
+            goto error;
+        ret = PyDict_SetItemString(info, "pthread_version", value);
+        Py_DECREF(value);
+        if (ret)
+            goto error;
+    }
+#endif
+#endif
+
+    return info;
+
+error:
+    Py_DECREF(info);
+    return NULL;
+}

From report at bugs.python.org  Tue Apr 19 23:27:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Apr 2011 21:27:34 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1303247977.21240.15.camel@marge>
Message-ID: <1303248451.3741.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I also renamed 'name' key to 'thread', so 'thread' is the name of the
> *thread* implementation, and 'lock' is the name of the *lock*
> implementation.

Not that I want to bikeshed, but I think 'name' was ok (since you get
the dict by calling threading._info(), it's obvious it has to do with
threading).
'lock_implementation' would be better than 'lock', OTOH.

Also, the 'pthread_version' documentation should state that it is
optional (only works on GNU).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Tue Apr 19 23:59:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Apr 2011 21:59:28 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <E1QCIxC-00028T-BY@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 383a7301616b by Victor Stinner in branch 'default':
Issue #11223: Add threading._info() function providing informations about the
http://hg.python.org/cpython/rev/383a7301616b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Wed Apr 20 00:06:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2011 22:06:37 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1303250797.83.0.184909311904.issue11223@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Let's wait 6 hours for "x86 FreeBSD 6.4 3.x":
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%206.4%203.x

The first build including my fix (383a7301616b) should be:
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%206.4%203.x/builds/1395

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Wed Apr 20 00:28:38 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Apr 2011 22:28:38 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <E1QCJPQ-0004FD-FX@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset bc1c6bd7eeb0 by Victor Stinner in branch 'default':
Issue #11223: fix test_dummy_threading, add _dummy_thread.info()
http://hg.python.org/cpython/rev/bc1c6bd7eeb0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Wed Apr 20 02:01:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Apr 2011 00:01:13 +0000
Subject: [issue11875] OrderedDict.__reduce__ not threadsafe
In-Reply-To: <1303201704.87.0.690807992306.issue11875@psf.upfronthosting.co.za>
Message-ID: <E1QCKr1-00023o-SF@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset db66eaf353a6 by Raymond Hettinger in branch '2.7':
Issue #11875: Alter the previous fix to work better with subclasses
http://hg.python.org/cpython/rev/db66eaf353a6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11875>
_______________________________________

From report at bugs.python.org  Wed Apr 20 02:19:27 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Apr 2011 00:19:27 +0000
Subject: [issue11875] OrderedDict.__reduce__ not threadsafe
In-Reply-To: <1303201704.87.0.690807992306.issue11875@psf.upfronthosting.co.za>
Message-ID: <E1QCL8f-00037Z-Vd@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 408f23b6cec5 by Raymond Hettinger in branch '3.1':
Issue #11875: Alter the previous fix to work better with subclasses
http://hg.python.org/cpython/rev/408f23b6cec5

New changeset 4e6840477d96 by Raymond Hettinger in branch '3.2':
Issue #11875: Alter the previous fix to work better with subclasses
http://hg.python.org/cpython/rev/4e6840477d96

New changeset 64968d226b61 by Raymond Hettinger in branch 'default':
Issue #11875: Alter the previous fix to work better with subclasses
http://hg.python.org/cpython/rev/64968d226b61

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11875>
_______________________________________

From report at bugs.python.org  Wed Apr 20 02:22:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2011 00:22:31 +0000
Subject: [issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1303258951.17.0.709161809992.issue8407@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

signal_pthread_sigmask.patch:
 - add signal.pthread_sigmask() function with doc and tests
 - add SIG_BLOCK, SIG_UNBLOCK, SIG_SETMASK constants
 - fix #11859: fix tests of test_io using threads and an alarm: use pthread_sigmask() to ensure that only the main thread receives the SIGALRM signal

The code is based on the last version of python-signalfd:
https://code.launchpad.net/~exarkun/python-signalfd/trunk

Changes between python-signalfd and my patch:
 - rename "sigprocmask" function to "pthread_sigmask"
 - I added an unit test and the doc
 - catch PyIter_Next() error
 - set signum variable (the result of PyLong_AsLong) type to long (instead of int) and check its value (0 < signum < NSIG)
 - I adapted the code to my coding style :-)

I will work on a similar patch for signalfd() after the pthread_sigmask() patch is accepted.

----------
keywords: +patch
Added file: http://bugs.python.org/file21735/signal_pthread_sigmask.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Wed Apr 20 02:22:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2011 00:22:56 +0000
Subject: [issue11859] test_interrupted_write_text() of test_io failed of
	Python 3.3 on FreeBSD 7.2
In-Reply-To: <1302994631.38.0.484484359613.issue11859@psf.upfronthosting.co.za>
Message-ID: <1303258976.58.0.987687774237.issue11859@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
dependencies: +expose signalfd(2) and sigprocmask(2) in the signal module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11859>
_______________________________________

From report at bugs.python.org  Wed Apr 20 02:38:29 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Apr 2011 00:38:29 +0000
Subject: [issue11882] test_imaplib failed on x86 ubuntu
In-Reply-To: <1303242113.82.0.307299264452.issue11882@psf.upfronthosting.co.za>
Message-ID: <1303259909.12.0.957718711203.issue11882@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is a repeatable error?  What is your system timezone set to?  The difference is exactly one half hour.  Does the test pass if you change the calendar.timegm call to have '0' or '1' as the last element of the tuple instead of '-1'?

----------
nosy: +belopolsky
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11882>
_______________________________________

From report at bugs.python.org  Wed Apr 20 02:49:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2011 00:49:31 +0000
Subject: [issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1303260571.32.0.645448637755.issue8407@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, I forget to read again http://codereview.appspot.com/1132041.

Here is an updated patch reusing some tests and with a better documentation.

----------
Added file: http://bugs.python.org/file21736/signal_pthread_sigmask-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Wed Apr 20 02:50:37 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 20 Apr 2011 00:50:37 +0000
Subject: [issue8944] test_winreg.test_reflection_functions fails on Windows
	Server 2003
In-Reply-To: <1276023433.0.0.59191647284.issue8944@psf.upfronthosting.co.za>
Message-ID: <1303260637.79.0.691858502878.issue8944@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

I no longer have access to a Server 2003 machine and I don't remember this happening the last few times I worked on that OS so it may have been fixed.

If this occurs for anyone else, feel free to reopen.

----------
resolution:  -> rejected
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8944>
_______________________________________

From report at bugs.python.org  Wed Apr 20 02:51:57 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Apr 2011 00:51:57 +0000
Subject: [issue11873] test_regexp() of test_compileall failure on "x86
	OpenIndiana 3.x"
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1303260717.97.0.531175266707.issue11873@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/issue11873>
_______________________________________

From report at bugs.python.org  Wed Apr 20 02:55:11 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 20 Apr 2011 00:55:11 +0000
Subject: [issue10540] test_shutil fails on Windows after r86733
In-Reply-To: <1290787235.82.0.346184396433.issue10540@psf.upfronthosting.co.za>
Message-ID: <1303260911.47.0.19191425159.issue10540@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

This hasn't been an issue for quite some time, and I suspect the follow-up work on symbolic and hard links and their supporting functions corrected any problems in this area.

----------
resolution:  -> works for me
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10540>
_______________________________________

From report at bugs.python.org  Wed Apr 20 03:07:32 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 20 Apr 2011 01:07:32 +0000
Subject: [issue1294232] Error in metaclass search order
In-Reply-To: <1303245811.02.0.750959202745.issue1294232@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=3RC5asgr9hPO37e7AjeTLsK0qiw@mail.gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This last point sounds like an error in PEP 3115 rather than an error
in the implementation - as the exception says, the metaclass of a
derived class must be the same as or a subclass of the metaclasses of
all of its bases. Since that rule applies recursively, and all classes
in 3.x implicitly inherit from object, it follows that all metaclasses
must directly or indirectly inherit from type.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Wed Apr 20 03:28:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Apr 2011 01:28:36 +0000
Subject: [issue11619] On Windows,
	don't encode filenames in the import machinery
In-Reply-To: <1300665531.85.0.426527059221.issue11619@psf.upfronthosting.co.za>
Message-ID: <E1QCMDX-0007LJ-Ah@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset e4e92d68ba3a by Victor Stinner in branch 'default':
Close #11619: write_compiled_module() doesn't encode the filename
http://hg.python.org/cpython/rev/e4e92d68ba3a

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11619>
_______________________________________

From report at bugs.python.org  Wed Apr 20 03:43:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2011 01:43:41 +0000
Subject: [issue11619] On Windows,
	don't encode filenames in the import machinery
In-Reply-To: <1300665531.85.0.426527059221.issue11619@psf.upfronthosting.co.za>
Message-ID: <1303263821.79.0.716029876941.issue11619@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> c) parse_source_module()
> => covered by the issue #10785.

Issue #10785 didn't change parse_source_module(): it does still encode the filename.

We need Unicode version of PyParser_ASTFromFile() and PyAST_Compile(): a new version of these functions accepting a filename as a Unicode string.

For PyParser_ASTFromFile(): #10785 prepared the work.

For PyAST_Compile(): struct compiler stores the filename as a byte string, the filename should be stored as Unicode.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11619>
_______________________________________

From report at bugs.python.org  Wed Apr 20 04:16:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Apr 2011 02:16:07 +0000
Subject: [issue8886] zipfile.ZipExtFile is a context manager,
	but that is not documented
In-Reply-To: <1275565167.77.0.94387257463.issue8886@psf.upfronthosting.co.za>
Message-ID: <E1QCMxV-00029V-Vm@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 83a426e969f5 by Brian Curtin in branch '2.7':
Fix #8886. Use context managers throughout zipfile tests.
http://hg.python.org/cpython/rev/83a426e969f5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8886>
_______________________________________

From report at bugs.python.org  Wed Apr 20 04:16:58 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 20 Apr 2011 02:16:58 +0000
Subject: [issue8886] zipfile.ZipExtFile is a context manager,
	but that is not documented
In-Reply-To: <1275565167.77.0.94387257463.issue8886@psf.upfronthosting.co.za>
Message-ID: <1303265818.62.0.490910206567.issue8886@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8886>
_______________________________________

From report at bugs.python.org  Wed Apr 20 04:36:11 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Apr 2011 02:36:11 +0000
Subject: [issue8809] smtplib should support SSL contexts
In-Reply-To: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>
Message-ID: <1303266971.31.0.549407577357.issue8809@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This sentence is awkward, at best.
"Alternative to a private key and a certificate key an optional SSLContext could be specified."

I suggest something like: "SSLcontext, also optional, is an alternative to keyfile and certfile; if it is specified, keyfile and certfile must be None."

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8809>
_______________________________________

From report at bugs.python.org  Wed Apr 20 04:48:12 2011
From: report at bugs.python.org (david)
Date: Wed, 20 Apr 2011 02:48:12 +0000
Subject: [issue8809] smtplib should support SSL contexts
In-Reply-To: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>
Message-ID: <1303267692.83.0.54120427437.issue8809@psf.upfronthosting.co.za>


david <db.pub.mail at gmail.com> added the comment:

It should also explain how the context can be used. 
An example of how to use it to establish a 'secured' connection would be a nice to have.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8809>
_______________________________________

From report at bugs.python.org  Wed Apr 20 06:14:56 2011
From: report at bugs.python.org (Tim Peters)
Date: Wed, 20 Apr 2011 04:14:56 +0000
Subject: [issue10596] modulo operator bug
In-Reply-To: <1291204399.82.0.975884133816.issue10596@psf.upfronthosting.co.za>
Message-ID: <1303272896.49.0.16316157873.issue10596@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Raymond, Mark pointed to the footnote explaining the first result.  As to the second, Kahan tried his best, but I'm afraid nobody can make me care about the sign bit on a zero ;-)  Whatever Mark thought best is fine by me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10596>
_______________________________________

From report at bugs.python.org  Wed Apr 20 07:37:10 2011
From: report at bugs.python.org (Jonathon Rossi)
Date: Wed, 20 Apr 2011 05:37:10 +0000
Subject: [issue7549] 2.6.4 Win32 linked to debug DLLs?
In-Reply-To: <1261267523.81.0.700619941365.issue7549@psf.upfronthosting.co.za>
Message-ID: <1303277830.7.0.822125756359.issue7549@psf.upfronthosting.co.za>


Jonathon Rossi <jono at jonorossi.com> added the comment:

I just encountered this error with an older version (2.6.2) of python on Windows Server 2008 R2.

>From looking at the logs it looks like the Customer Experience Improvement Program (CEIP) functionality is causing this problem because it has a scheduled task (Application Experience\ProgramDataUpdater) which runs every day at 12.30am, even if you are not participating in the CEIP (i.e. it is not sending the info to Microsoft). After a quick look around, it seems like the scheduled task collects program information to report to Microsoft, which must cause the side-by-side when it loads the EXE to get version information.

Based on Martin's comments I plan to just remove this file, until we work out what version of python this was fixed in and upgrade.

----------
nosy: +jonorossi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7549>
_______________________________________

From report at bugs.python.org  Wed Apr 20 08:36:04 2011
From: report at bugs.python.org (Kasun Herath)
Date: Wed, 20 Apr 2011 06:36:04 +0000
Subject: [issue8809] smtplib should support SSL contexts
In-Reply-To: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>
Message-ID: <1303281364.02.0.544592798009.issue8809@psf.upfronthosting.co.za>


Kasun Herath <kasunh01 at gmail.com> added the comment:

I'm submitting a new patch with changes suggested by Terry. But I feel an example of how to use a SSLContext inside the Docstring of SMTP_SSL constructor is unnecessary since no smtp specific things are done to the passed SSLContext. Any ideas about this suggestion?

----------
Added file: http://bugs.python.org/file21737/smtp_sslcontext_updated.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8809>
_______________________________________

From report at bugs.python.org  Wed Apr 20 08:39:51 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 20 Apr 2011 06:39:51 +0000
Subject: [issue11875] OrderedDict.__reduce__ not threadsafe
In-Reply-To: <1303201704.87.0.690807992306.issue11875@psf.upfronthosting.co.za>
Message-ID: <1303281591.84.0.139274492283.issue11875@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Mario, thanks for the bug report.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11875>
_______________________________________

From report at bugs.python.org  Wed Apr 20 09:36:50 2011
From: report at bugs.python.org (John O'Hagan)
Date: Wed, 20 Apr 2011 07:36:50 +0000
Subject: [issue11884] Argparse calls ngettext but doesn't import it
In-Reply-To: <1303285010.85.0.710971435429.issue11884@psf.upfronthosting.co.za>
Message-ID: <1303285010.85.0.710971435429.issue11884@psf.upfronthosting.co.za>


New submission from John O'Hagan <research at johnohagan.com>:

Argparse in python3.2 includes two calls to ngettext to handle error messages, but ngettext is not imported. This causes NameError to be raised instead of ArgumentError.

Changing line 93 from:

    from gettext import gettext

to:

    from gettext import gettext, ngettext 

seems to fix the problem.

----------
components: Library (Lib)
messages: 134126
nosy: johnohagan
priority: normal
severity: normal
status: open
title: Argparse calls ngettext but doesn't import it
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11884>
_______________________________________

From report at bugs.python.org  Wed Apr 20 09:42:45 2011
From: report at bugs.python.org (ysj.ray)
Date: Wed, 20 Apr 2011 07:42:45 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1303285365.51.0.146040996065.issue9523@psf.upfronthosting.co.za>


ysj.ray <ysj.ray at gmail.com> added the comment:

Updated patch following C code review comments from http://bugs.python.org/review/9523/show

Two big changes:

1. Add check for each time assign a Py_ssize_t variable to datum.dsize(int), if value not fit, raise a ValueError(following PEP 353)

2. Simplify dbm.update(), behave more like dict.update().

----------
Added file: http://bugs.python.org/file21738/issue_9523_4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9523>
_______________________________________

From report at bugs.python.org  Wed Apr 20 09:48:30 2011
From: report at bugs.python.org (higery)
Date: Wed, 20 Apr 2011 07:48:30 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1303285710.44.0.89771998196.issue828450@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

>> I'm not sure it is necessary to use TempdirManager here to write tests
>> for MANIFEST reading.

>Well, the sdist command has to run on some directory where some files >exist, right?  So it?s better to do it in a temp dir that will automatically get >cleaned up.

Because the MANIFEST file finally will be filled with file-paths which takes '/' as path separator and that's what we can make sure if we already hacked the write_manifest function in sdist.py, so we can just write the imitated paths strings  into the MANIFEST file , not needing to really create these files at first. As a test, it makes sense. So, I think we maynot need to use TempdirManager here.

>> Bad effect is MANIFEST file will be re-written:

>You should read the docs for MANIFEST and sdist: a MANIFEST without >the magic comment will not get overwritten (unless there?s a bug :)

Oh, you are right. Thus this bad effect would not exist for this test. But future discussing is still needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Wed Apr 20 09:54:24 2011
From: report at bugs.python.org (Albert Hopkins)
Date: Wed, 20 Apr 2011 07:54:24 +0000
Subject: [issue4608] urllib.request.urlopen does not return an iterable object
In-Reply-To: <1228824822.91.0.748607079368.issue4608@psf.upfronthosting.co.za>
Message-ID: <1303286064.73.0.0388391633092.issue4608@psf.upfronthosting.co.za>


Albert Hopkins <marduk at python.net> added the comment:

This issue appears to persist when the protocol used is FTP:


root at tp-db $ cat test.py
from urllib.request import urlopen
for line in urlopen('ftp://gentoo.osuosl.org/pub/gentoo/releases/'):
        print(line)
        break

root at tp-db $ python3.2 test.py
Traceback (most recent call last):
  File "test.py", line 2, in <module>
    for line in urlopen('ftp://gentoo.osuosl.org/pub/gentoo/releases/'):
TypeError: 'addinfourl' object is not iterable

----------
nosy: +marduk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4608>
_______________________________________

From report at bugs.python.org  Wed Apr 20 09:56:52 2011
From: report at bugs.python.org (Albert Hopkins)
Date: Wed, 20 Apr 2011 07:56:52 +0000
Subject: [issue4608] urllib.request.urlopen does not return an iterable object
In-Reply-To: <1228824822.91.0.748607079368.issue4608@psf.upfronthosting.co.za>
Message-ID: <1303286212.03.0.425795182059.issue4608@psf.upfronthosting.co.za>


Albert Hopkins <marduk at python.net> added the comment:

Oops, previous example was a directory, but it's the same if the url points to a ftp file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4608>
_______________________________________

From report at bugs.python.org  Wed Apr 20 10:29:53 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 20 Apr 2011 08:29:53 +0000
Subject: [issue4608] urllib.request.urlopen does not return an iterable object
In-Reply-To: <1228824822.91.0.748607079368.issue4608@psf.upfronthosting.co.za>
Message-ID: <1303288193.05.0.682384591238.issue4608@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4608>
_______________________________________

From report at bugs.python.org  Wed Apr 20 10:30:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2011 08:30:36 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1303288236.96.0.804965406453.issue11223@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

"Builder x86 FreeBSD 6.4 3.x Build #1394. Results: Build successful"
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%206.4%203.x/builds/1394

Great! It should be the first success on this buildbot since... 4 months (r87292, issue?#8844))? Let's close this issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Wed Apr 20 10:50:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2011 08:50:50 +0000
Subject: [issue11779] test_mmap.test_large_offset() timeout (1 hour) on "AMD64
	Snow Leopard 3.x" buildbot
In-Reply-To: <1302076762.26.0.815715887004.issue11779@psf.upfronthosting.co.za>
Message-ID: <1303289450.61.0.98034952149.issue11779@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: test_mmap timeout (1 hour) on "AMD64 Snow Leopard 3.x" buildbot -> test_mmap.test_large_offset() timeout (1 hour) on "AMD64 Snow Leopard 3.x" buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11779>
_______________________________________

From report at bugs.python.org  Wed Apr 20 11:19:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2011 09:19:45 +0000
Subject: [issue11738] ThreadSignals.test_signals() of test_threadsignals hangs
	on PPC Tiger 3.x buildbot
In-Reply-To: <1301673336.69.0.136519124397.issue11738@psf.upfronthosting.co.za>
Message-ID: <1303291185.34.0.303607207096.issue11738@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I think that the last test_threadsignals failures on PPC Tiger
> were related to the new regrtest timeout, and it is now fixed.

Wrong, it was a deadlock. It is a duplicate of #11768 and it is now fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11738>
_______________________________________

From report at bugs.python.org  Wed Apr 20 11:58:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Apr 2011 09:58:17 +0000
Subject: [issue11557] Increase coverage in logging module
In-Reply-To: <1300202455.33.0.229381478379.issue11557@psf.upfronthosting.co.za>
Message-ID: <E1QCUAo-0001D0-Pw@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 41dc66528c4e by Vinay Sajip in branch 'default':
Attempt fix of #11557 by changing teardown logic.
http://hg.python.org/cpython/rev/41dc66528c4e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11557>
_______________________________________

From report at bugs.python.org  Wed Apr 20 12:20:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2011 10:20:10 +0000
Subject: [issue11557] Increase coverage in logging module
In-Reply-To: <1300202455.33.0.229381478379.issue11557@psf.upfronthosting.co.za>
Message-ID: <1303294810.9.0.0891451939883.issue11557@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue is not fixed: the test does still fail... sometimes. Recent example (AMD64 FreeBSD 8.2 3.x buildbot):
----------------------------------------------------------------------
(...)
[283/354] test_logging
Warning -- logging._handlerList was modified by test_logging
test test_logging failed -- Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_logging.py", line 2449, in test_no_kwargs
    self.assertEqual(logging.root.level, logging.WARNING)
AssertionError: 20 != 30
(...)
1 test failed:
    test_logging
(...)
Re-running test 'test_logging' in verbose mode
(...)
test_log (test.test_logging.BasicConfigTest) ... ok
test_no_kwargs (test.test_logging.BasicConfigTest) ... FAIL
test_stream (test.test_logging.BasicConfigTest) ... ok
(...)
test_compute_rollover_W0 (test.test_logging.TimedRotatingFileHandlerTest) ... Warning -- logging._handlerList was modified by test_logging
test test_logging failed -- Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_logging.py", line 2449, in test_no_kwargs
    self.assertEqual(logging.root.level, logging.WARNING)
AssertionError: 20 != 30

ok

FAIL: test_no_kwargs (test.test_logging.BasicConfigTest)

Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_logging.py", line 2449, in test_no_kwargs
    self.assertEqual(logging.root.level, logging.WARNING)
AssertionError: 20 != 30
----------------------------------------------------------------------
http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.x/builds/98/steps/test/logs/stdio

----------
resolution: fixed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11557>
_______________________________________

From report at bugs.python.org  Wed Apr 20 12:24:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Apr 2011 10:24:06 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <E1QCUZo-00033b-H9@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 64008d17fb54 by Victor Stinner in branch 'default':
Issue #11223: fix compiler warnings
http://hg.python.org/cpython/rev/64008d17fb54

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Wed Apr 20 12:26:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2011 10:26:07 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when
	locks are implemented using POSIX condition variables
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1303295167.69.0.0443570610272.issue11223@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: interruption of locks by signals not guaranteed when the semaphore implementation is not used -> interruption of locks by signals not guaranteed when locks are implemented using POSIX condition variables

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Wed Apr 20 12:51:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Apr 2011 10:51:06 +0000
Subject: [issue11557] Increase coverage in logging module
In-Reply-To: <1300202455.33.0.229381478379.issue11557@psf.upfronthosting.co.za>
Message-ID: <E1QCUzw-0004yR-UO@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 31bb4788aa1c by Vinay Sajip in branch 'default':
Attempt fix of #11557 by changing setup/teardown logic.
http://hg.python.org/cpython/rev/31bb4788aa1c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11557>
_______________________________________

From report at bugs.python.org  Wed Apr 20 12:52:44 2011
From: report at bugs.python.org (Brian Quinlan)
Date: Wed, 20 Apr 2011 10:52:44 +0000
Subject: [issue11864] sporadic failure in test_concurrent_futures
In-Reply-To: <1303085572.99.0.967761591602.issue11864@psf.upfronthosting.co.za>
Message-ID: <1303296764.03.0.893342994858.issue11864@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

It looks like the timing is too sensitive.

----------
assignee:  -> bquinlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11864>
_______________________________________

From report at bugs.python.org  Wed Apr 20 13:04:14 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 20 Apr 2011 11:04:14 +0000
Subject: [issue11867] Make test_mailbox deterministic
In-Reply-To: <1303227937.84.0.159541070707.issue11867@psf.upfronthosting.co.za>
Message-ID: <20110420110405.GA60812@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

'Was not allowed to look yesterday.
If the child only closes and not
                self.c_sock_shutdown = True
(shutdown is an ugly word for a child anyway) then
(and i hope Apple did not modify the BSD network stack):

12:59 ~/tmp $ python3 -E -Wd -m test -r -w  test_mailbox
Using random seed 1985762
[1/1] test_mailbox
1 test OK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11867>
_______________________________________

From report at bugs.python.org  Wed Apr 20 13:21:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Apr 2011 11:21:02 +0000
Subject: [issue11557] Increase coverage in logging module
In-Reply-To: <1300202455.33.0.229381478379.issue11557@psf.upfronthosting.co.za>
Message-ID: <E1QCVSu-00079f-28@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0494afdc8615 by Vinay Sajip in branch 'default':
Attempt fix of #11557 by refining setup/teardown logic.
http://hg.python.org/cpython/rev/0494afdc8615

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11557>
_______________________________________

From report at bugs.python.org  Wed Apr 20 13:50:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Apr 2011 11:50:52 +0000
Subject: [issue11557] Increase coverage in logging module
In-Reply-To: <1300202455.33.0.229381478379.issue11557@psf.upfronthosting.co.za>
Message-ID: <E1QCVvl-00013D-Vb@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d93e18e6a3e8 by Vinay Sajip in branch 'default':
Attempt fix of #11557 by refining test logic.
http://hg.python.org/cpython/rev/d93e18e6a3e8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11557>
_______________________________________

From report at bugs.python.org  Wed Apr 20 13:58:40 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 20 Apr 2011 11:58:40 +0000
Subject: [issue11885] argparse docs needs fixing
In-Reply-To: <1303300720.91.0.791889164093.issue11885@psf.upfronthosting.co.za>
Message-ID: <1303300720.91.0.791889164093.issue11885@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

Hello, I am returning to report new fixes to be made to argparse docs. The issues can be observed in this link:

http://docs.python.org/dev/library/argparse.html#upgrading-optparse-code


1) "When most everything in optparse had either been copy-pasted over or monkey-patched ..."

"When most in optparse had either been copy-pasted over or monkey-patched ..."

Word "everything" was removed.

2) "- Replace strings with implicit arguments such as %default or %prog with the standard python syntax to use dictionaries to format strings, that is, %(default)s and %(prog)s."

"- Replace strings with implicit arguments such as %default or %prog with the standard Python syntax to use dictionaries to format strings, that is %(default)s and %(prog)s."

Word "python" was fixed to "Python" and comma was deleted after "that is".


Please fix this. Thanks.

----------
messages: 134141
nosy: Retro
priority: normal
severity: normal
status: open
title: argparse docs needs fixing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11885>
_______________________________________

From report at bugs.python.org  Wed Apr 20 13:59:20 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 20 Apr 2011 11:59:20 +0000
Subject: [issue11885] argparse docs needs fixing
In-Reply-To: <1303300720.91.0.791889164093.issue11885@psf.upfronthosting.co.za>
Message-ID: <1303300760.34.0.501141100764.issue11885@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11885>
_______________________________________

From report at bugs.python.org  Wed Apr 20 14:00:17 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 20 Apr 2011 12:00:17 +0000
Subject: [issue11885] argparse docs needs fixing
In-Reply-To: <1303300720.91.0.791889164093.issue11885@psf.upfronthosting.co.za>
Message-ID: <1303300817.81.0.0776513296495.issue11885@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +eric.araujo, ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11885>
_______________________________________

From report at bugs.python.org  Wed Apr 20 14:01:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2011 12:01:40 +0000
Subject: [issue11864] sporadic failure in test_concurrent_futures
In-Reply-To: <1303085572.99.0.967761591602.issue11864@psf.upfronthosting.co.za>
Message-ID: <1303300900.67.0.927358587188.issue11864@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11864>
_______________________________________

From report at bugs.python.org  Wed Apr 20 14:08:08 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 20 Apr 2011 12:08:08 +0000
Subject: [issue11877] Mac OS X fsync() should really be fcntl(F_FULLFSYNC)
In-Reply-To: <1303234762.52.0.706759541504.issue11877@psf.upfronthosting.co.za>
Message-ID: <20110420120759.GB60812@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

> when one calls fsync, he expects [...]
> Fixing this deficiency through Python's exposed fsync [...]

I think so, too.
http://pubs.opengroup.org/onlinepubs/009695399/functions/fsync.html
even permits "null implementation"s etc. etc. etc.
(I like the last paragraph of "Rationale" the most.)
os.rst states for fsync():

    [...] to ensure that all internal buffers associated with *f*
    are written to disk.

If a platform offers the opportunity to actually implement the
desired behaviour then i would do so, regardless of what needs to
be done internally to achieve it.

(And the single question on apple is simply what to do otherwise
with that VMS/VFS bug for at least large sparse files.
I can only imagine adding multiple notes in the documentation,
here and there.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Wed Apr 20 14:16:39 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 20 Apr 2011 12:16:39 +0000
Subject: [issue11877] Mac OS X fsync() should really be fcntl(F_FULLFSYNC)
In-Reply-To: <1303212938.57.0.821096700769.issue11877@psf.upfronthosting.co.za>
Message-ID: <1303301799.41.0.773549718516.issue11877@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

See <http://www.kernel.org/doc/man-pages/online/pages/man2/fsync.2.html> for linux' behavior, in particular: linux doesn't guarantee that data gets writting to the disk when you call fsync, only that the data gets pushed to the storage device.

This is the same behavior as fsync on OSX, and OSX also has a second API that provides stronger guarantees. 

With your patch it is no longer possible to call the C function fsync on OSX, even though it is good enough for a lot of use cases. As os.fcntl already supports F_FULLSYNC I see no good reason to change the implementation of os.fsync on OSX.

BTW. The need to use F_FULLSYNC in issue 11277 might be a bug in OSX itself, have you filed an issue in Apple's tracker?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Wed Apr 20 14:18:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2011 12:18:46 +0000
Subject: [issue11877] Mac OS X fsync() should really be fcntl(F_FULLFSYNC)
In-Reply-To: <1303212938.57.0.821096700769.issue11877@psf.upfronthosting.co.za>
Message-ID: <1303301926.83.0.17354918123.issue11877@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

A different approach for this issue is to document fcntl.fcntl(fd, fcntl.F_FULLFSYNC) in fsync() documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Wed Apr 20 14:38:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Apr 2011 12:38:25 +0000
Subject: [issue11877] Mac OS X fsync() should really be fcntl(F_FULLFSYNC)
In-Reply-To: <1303212938.57.0.821096700769.issue11877@psf.upfronthosting.co.za>
Message-ID: <1303303105.12.0.0944856170695.issue11877@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Agreed with Ronald. If Apple thinks fsync() shouldn't flush the hardware cache, there's no reason for us to override that.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Wed Apr 20 14:45:39 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 20 Apr 2011 12:45:39 +0000
Subject: [issue11557] Increase coverage in logging module
In-Reply-To: <1303294810.9.0.0891451939883.issue11557@psf.upfronthosting.co.za>
Message-ID: <555700.89208.qm@web25807.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Hi Victor,

----- Original Message ----

> From: STINNER Victor <report at bugs.python.org>
> To: vinay_sajip at yahoo.co.uk
> Sent: Wed, 20 April, 2011 11:20:11
> Subject: [issue11557] Increase coverage in logging module
> 
> 
> STINNER Victor <victor.stinner at haypocalc.com>  added the comment:
> 
> This issue is not fixed: the test does still fail...  sometimes. Recent example 
>(AMD64 FreeBSD 8.2 3.x  buildbot):

Yes, I know it's not fixed yet - I'm still working on it. The annoying thing, it 
works for me locally, and just fails on some of the buildbots. So I have to make 
changes, check them in, and wait for the buildbots to pick them up ... if I 
don't get a solution in the time I have at the moment to work on this, I'll 
leave the test as skipped so that further failures are avoided, until I get time 
to look at this again. But I've got some time today, so I hope to make progress 
on this issue, as it looks as if Natalia couldn't find the time ...

Regards,

Vinay

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11557>
_______________________________________

From report at bugs.python.org  Wed Apr 20 14:50:25 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 20 Apr 2011 12:50:25 +0000
Subject: [issue11877] Mac OS X fsync() should really be fcntl(F_FULLFSYNC)
In-Reply-To: <1303212938.57.0.821096700769.issue11877@psf.upfronthosting.co.za>
Message-ID: <1303303825.55.0.153918683031.issue11877@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> in particular: linux doesn't guarantee that data gets writting to the disk when you call fsync, only that the data gets pushed to the storage device.

Barriers are now enable by default in EXT4, and Theodore Tso has been favourable to that for quite some time now:
http://lwn.net/Articles/283288/

As for OS-X, this is definitely a bug (I mean, having to call fsync before mmap is a huge bug in itself).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Wed Apr 20 15:32:18 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 20 Apr 2011 13:32:18 +0000
Subject: [issue11877] Mac OS X fsync() should really be fcntl(F_FULLFSYNC)
In-Reply-To: <1303301799.41.0.773549718516.issue11877@psf.upfronthosting.co.za>
Message-ID: <20110420133205.GA2432@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

On Wed, Apr 20, 2011 at 12:16:39PM +0000, Ronald Oussoren wrote:
> This is the same behavior as fsync on OSX, and OSX also has
> a second API that provides stronger guarantees.
> With your patch it is no longer possible to call the C function
> fsync on OSX, even though it is good enough for a lot of use
> cases. As os.fcntl already supports F_FULLSYNC I see no good
> reason to change the implementation of os.fsync on OSX.

I don't see it that way for multiple reasons.

One of it is that Python states that it "is a beginner language",
and the sentence i've quoted a part of in my last message is very
beginner friendly.  Now i don't think you can require that much
further knowledge from a beginner at all than what is described in
that very sentence.

(Just think of an african kid with a sponsored laptop and possibly
10 minutes internet access per day which tries hard to rise up and
puts *galaxies of trust* in what it reads in os.rst, maybe because
it is the only documentation he has available!)

Then Python is a high-level language.  It's true that there are
many shallow wrappers around lower-level functions, but still.
It is cross-platform.  Just have a look into a, say, file I/O
implementation of a C library/program which aims to be portable.
If all that #if#endif would be necessary in a high-level language,
then why don't write a Makefile and compile that thing?
Not that much more work, then - many thanks to the GCC people!
You know - i wouldn't talk about subtleties of filesystems here.

And then - at least half a dozen of programmers with altogether
maybe many decades of experience, full-time internet access
(talking about you :) required two months to get around the Apple
bug.  A simple "man 2 fsync" would have sufficed for a starter!
And how ridiculous - i've spend the free time of four days :-(
It's a shame, it's a bug, i wouldn't it let pass through to users.

Apple?  No, i'm looking forward to return to a private BSD/Linux
X/ahwm/aterm/vim laptop.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Wed Apr 20 15:32:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2011 13:32:28 +0000
Subject: [issue11557] Increase coverage in logging module
In-Reply-To: <555700.89208.qm@web25807.mail.ukl.yahoo.com>
Message-ID: <1303306344.9838.0.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> > This issue is not fixed: the test does still fail...  sometimes. Recent example 
> >(AMD64 FreeBSD 8.2 3.x  buildbot):
> 
> Yes, I know it's not fixed yet - I'm still working on it. (...)

I realized just after writing my message that the last (commit) message
marking the issue as fixed was very recent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11557>
_______________________________________

From report at bugs.python.org  Wed Apr 20 15:37:59 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 20 Apr 2011 13:37:59 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1303306679.08.0.259002842368.issue11828@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file21739/87be2a5e22ed.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Wed Apr 20 15:45:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2011 13:45:03 +0000
Subject: [issue11873] test_regexp() of test_compileall failure on "x86
	OpenIndiana 3.x"
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1303307103.92.0.144521886538.issue11873@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It failed also on "AMD64 FreeBSD 8.2 3.x" buildbot:
-----------------
test test_compileall failed -- Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_compileall.py", line 253, in test_regexp
    self.assertCompiled(self.initfn)
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_compileall.py", line 149, in assertCompiled
    self.assertTrue(os.path.exists(imp.cache_from_source(fn)))
AssertionError: False is not true
-----------------
http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.x/builds/102/steps/test/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11873>
_______________________________________

From report at bugs.python.org  Wed Apr 20 15:47:23 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 20 Apr 2011 13:47:23 +0000
Subject: [issue11877] Mac OS X fsync() should really be fcntl(F_FULLFSYNC)
In-Reply-To: <1303301799.41.0.773549718516.issue11877@psf.upfronthosting.co.za>
Message-ID: <20110420134715.GA21728@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

On Wed, Apr 20, 2011 at 12:16:39PM +0000, Ronald Oussoren wrote:
> This is the same behavior as fsync on OSX, and OSX also has
> a second API that provides stronger guarantees.
> With your patch it is no longer possible to call the C function
> fsync on OSX, even though it is good enough for a lot of use
> cases. As os.fcntl already supports F_FULLSYNC I see no good
> reason to change the implementation of os.fsync on OSX.

I don't see it that way for multiple reasons.

One of it is that Python states that it "is a beginner language",
and the sentence i've quoted a part of in my last message is very
beginner friendly.  Now i don't think you can require that much
further knowledge from a beginner at all than what is described in
that very sentence.

(Just think of an african kid with a sponsored laptop and possibly
10 minutes internet access per day which tries hard to rise up and
puts *galaxies of trust* in what it reads in os.rst, maybe because
it is the only documentation he has available!)

Then Python is a high-level language.  It's true that there are
many shallow wrappers around lower-level functions, but still.
It is cross-platform.  Just have a look into a, say, file I/O
implementation of a C library/program which aims to be portable.
If all that #if#endif would be necessary in a high-level language,
then why don't write a Makefile and compile that thing?
Not that much more work, then - many thanks to the GCC people!
You know - i wouldn't talk about subtleties of filesystems here.

And then - at least half a dozen of programmers with altogether
maybe many decades of experience, full-time internet access
(talking about you :) required two months to get around the Apple
bug.  A simple "man 2 fsync" would have sufficed for a starter!
And how ridiculous - i've spend the free time of four days :-(
It's a shame, it's a bug, i wouldn't it let pass through to users.

Apple?  No, i'm looking forward to return to a private BSD/Linux
X/ahwm/aterm/vim laptop.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Wed Apr 20 15:49:53 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 20 Apr 2011 13:49:53 +0000
Subject: [issue11885] argparse docs needs fixing
In-Reply-To: <1303300720.91.0.791889164093.issue11885@psf.upfronthosting.co.za>
Message-ID: <1303307393.62.0.877111929217.issue11885@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

I have also discovered some non-capitalised "python" words in the very same argparse docs. These 2 subtitles have those typos:

1) 15.4.1.1. Creating a parser
2) 15.4.6. Upgrading optparse code


Please fix this as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11885>
_______________________________________

From report at bugs.python.org  Wed Apr 20 15:53:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2011 13:53:13 +0000
Subject: [issue11886] test_time.test_tzset() fails on "x86 FreeBSD 7.2 3.x":
	AEST timezone called "EST"
In-Reply-To: <1303307593.46.0.897474878267.issue11886@psf.upfronthosting.co.za>
Message-ID: <1303307593.46.0.897474878267.issue11886@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

test_time.test_tzset() fails on "x86 FreeBSD 7.2 3.x": 'AEST-10AEDT-11,M10.5.0,M3.5.0' timezone becomes 'EST'.
======================================================================
FAIL: test_tzset (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_time.py", line 209, in test_tzset
    self.assertTrue(time.tzname[0] == 'AEST', str(time.tzname[0]))
AssertionError: False is not true : EST

----------------------------------------------------------------------
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%207.2%203.x/builds/1705/steps/test/logs/stdio

See also http://en.wikipedia.org/wiki/Time_in_Australia

----------
components: Library (Lib), Tests
messages: 134153
nosy: belopolsky, haypo
priority: normal
severity: normal
status: open
title: test_time.test_tzset() fails on "x86 FreeBSD 7.2 3.x": AEST timezone called "EST"
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11886>
_______________________________________

From report at bugs.python.org  Wed Apr 20 16:06:24 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 20 Apr 2011 14:06:24 +0000
Subject: [issue11877] Mac OS X fsync() should really be fcntl(F_FULLFSYNC)
In-Reply-To: <1303212938.57.0.821096700769.issue11877@psf.upfronthosting.co.za>
Message-ID: <20110420140615.GA25362@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

8-}
The real message was:

On Wed, Apr 20, 2011 at 12:16:39PM +0000, Antoine Pitrou wrote:
> If Apple thinks [...] there's no reason for us

Apple thinks (KernelProgramming.pdf, BPFileSystem.pdf):

    Kernel code must be nearly perfect.

    Kernel programming is a black art that should be avoided if at
    all possible. Fortunately, kernel programming is usually
    unnecessary.  You can write most software entirely in user
    space.

    Sparse files and zero filling. UFS supports sparse files,
    which are a way for the file system to store the data in files
    without storing unused space allocated for those files. HFS+
    does not support sparse files and, in fact, zero-fills all
    bytes allocated for a file until end-of-file.
    [Steffen thinks HFS+ is driven from "user-space" through IOKit.]

POSIX says:

    It would also not be unreasonable to omit testing for fsync(),
    allowing it to be treated as a quality-of-implementation
    issue.

It seems someone needs a hand.
Nice afternoon with an untrashed INBOX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Wed Apr 20 16:23:09 2011
From: report at bugs.python.org (Francesco Ricciardi)
Date: Wed, 20 Apr 2011 14:23:09 +0000
Subject: [issue10042] total_ordering
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1303309389.25.0.226449353823.issue10042@psf.upfronthosting.co.za>


Francesco Ricciardi <francescor2010 at yahoo.it> added the comment:

I think the whole issue is indeed how NotImplemented is treated. To me saying that 'not NotImplemented' is True is wrong. About the stack overflow I found there are various possible fixes, however none will nice.

By definition, NotImplemented is the way that a method or operation have to signal to the interpreter that it doesn't know how to handle given operand types. IMHO, it shouldn't be possible to receive NotImplemented as operand value, and it shouldn't have a boolean value. Indeed, t should be handled as a special case by the interpreter.

To go further, I am not really sure that NotImplemented should be a return value. Probably, an exception that is trapped by the interpreter when evaluating an expression would be easier to define and handle.

Of course, such a change should be deeply grokked before being put in place, also because of the high impact on code that already relies on NotImplemented having a value.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Wed Apr 20 16:38:51 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 20 Apr 2011 14:38:51 +0000
Subject: [issue11557] Increase coverage in logging module
In-Reply-To: <1300202455.33.0.229381478379.issue11557@psf.upfronthosting.co.za>
Message-ID: <1303310331.86.0.254806580503.issue11557@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Marking as closed, since d93e18e6a3e8 now appears to pass on all 3.x buildbots.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11557>
_______________________________________

From report at bugs.python.org  Wed Apr 20 17:04:02 2011
From: report at bugs.python.org (pola)
Date: Wed, 20 Apr 2011 15:04:02 +0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1303311842.09.0.509158579631.issue1322@psf.upfronthosting.co.za>


pola <pola.work at gmail.com> added the comment:

Has there been any progress on incorporating the suggested here patch?  

A suggested patch is found here also:

http://code.google.com/p/google-highly-open-participation-psf/issues/detail?id=216


And a patch is applied to python in ubuntu packages:
see reference - https://bugs.launchpad.net/python/+bug/196526

But the original platform still doesn't support this and it can't be counted on. 
Will the patch given by zooko be applied? If not, what is missing in it?

----------
nosy: +pola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Wed Apr 20 17:24:45 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 20 Apr 2011 15:24:45 +0000
Subject: [issue4608] urllib.request.urlopen does not return an iterable object
In-Reply-To: <1228824822.91.0.748607079368.issue4608@psf.upfronthosting.co.za>
Message-ID: <1303313085.55.0.0782050049316.issue4608@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/issue4608>
_______________________________________

From report at bugs.python.org  Wed Apr 20 17:35:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2011 15:35:53 +0000
Subject: [issue11887] unittest fails on comparing str with bytes if python has
	the -bb option
In-Reply-To: <1303313753.3.0.8744280471.issue11887@psf.upfronthosting.co.za>
Message-ID: <1303313753.3.0.8744280471.issue11887@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

assertEqual(), assertListEqual(), assertSequenceEqual() emits a BytesWarning warning or raise a BytesWarning exception if python has -b or -bb option. Attached patch adds tests to demonstrate this issue.

----------
components: Library (Lib), Tests, Unicode
messages: 134158
nosy: eric.araujo, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: unittest fails on comparing str with bytes if python has the -bb option
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11887>
_______________________________________

From report at bugs.python.org  Wed Apr 20 17:58:52 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 20 Apr 2011 15:58:52 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

The three most popular logarithm bases are 10, e, and 2.  The math library has direct function calls for the first two but not the latter which is important in informatics.

Since a direct call can use a custom algorithm or native hardware support (such as the FLDLN2 fpu instruction), it provides better speed and accuracy than our existing math.log(x, 2) option.

----------
assignee: mark.dickinson
messages: 134159
nosy: mark.dickinson, rhettinger
priority: normal
severity: normal
status: open
title: Add C99's log2() function to the math library
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Wed Apr 20 17:59:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Apr 2011 15:59:52 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <E1QCZok-0007Mj-Pq@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f4da64529e8c by Jesus Cea in branch '2.7':
startswith and endswith don't accept None as slice index. Patch by Torsten Becker. (closes #11828)
http://hg.python.org/cpython/rev/f4da64529e8c

New changeset 77c657e47b5c by Jesus Cea in branch '3.1':
startswith and endswith don't accept None as slice index. Patch by Torsten Becker. (closes #11828)
http://hg.python.org/cpython/rev/77c657e47b5c

New changeset e5f11efe89a6 by Jesus Cea in branch '3.2':
MERGE: startswith and endswith don't accept None as slice index. Patch by Torsten Becker. (closes #11828)
http://hg.python.org/cpython/rev/e5f11efe89a6

New changeset b8d1cf9fde04 by Jesus Cea in branch 'default':
MERGE: startswith and endswith don't accept None as slice index. Patch by Torsten Becker. (closes #11828)
http://hg.python.org/cpython/rev/b8d1cf9fde04

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Wed Apr 20 18:00:56 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 20 Apr 2011 16:00:56 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1303315256.85.0.38321786814.issue11828@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
assignee:  -> jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Wed Apr 20 18:03:49 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Wed, 20 Apr 2011 16:03:49 +0000
Subject: [issue4608] urllib.request.urlopen does not return an iterable object
In-Reply-To: <1228824822.91.0.748607079368.issue4608@psf.upfronthosting.co.za>
Message-ID: <1303315429.27.0.848116332512.issue4608@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4608>
_______________________________________

From report at bugs.python.org  Wed Apr 20 18:04:41 2011
From: report at bugs.python.org (Yoann Aubineau)
Date: Wed, 20 Apr 2011 16:04:41 +0000
Subject: [issue6785] IncompleteRead / BadStatus when parsing
	http://peakoil.mobi
In-Reply-To: <1251294693.63.0.748199046509.issue6785@psf.upfronthosting.co.za>
Message-ID: <1303315481.91.0.44281891673.issue6785@psf.upfronthosting.co.za>


Yoann Aubineau <yoann.aubineau at gmail.com> added the comment:

Chunked transfer encoding has been introduced in HTTP/1.1. Sending an HTTP/1.0 request would then force the server to not use this mechanism.

Module httplib sends HTTP/1.1 requests by default but, as far as I know, does not offer any option to downgrade.

My suggestion would be to monkey patch httplib.HTTPConnection prior to using it :

    import httplib
    httplib.HTTPConnection._http_vsn = 10
    httplib.HTTPConnection._http_vsn_str = 'HTTP/1.0'

----------
nosy: +yaubi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6785>
_______________________________________

From report at bugs.python.org  Wed Apr 20 18:08:57 2011
From: report at bugs.python.org (Peter Hammer)
Date: Wed, 20 Apr 2011 16:08:57 +0000
Subject: [issue11889] 'enumerate' 'start' parameter documentation is confusing
In-Reply-To: <1303315736.72.0.416681647484.issue11889@psf.upfronthosting.co.za>
Message-ID: <1303315736.72.0.416681647484.issue11889@psf.upfronthosting.co.za>


New submission from Peter Hammer <phammer at cardious.com>:

"""
A point of confusion using the builtin function 'enumerate' and
enlightenment for those who, like me, have been confused.

Note, this confusion was discussed at length at

  http://bugs.python.org/issue2831

prior to the 'start' parameter being added to 'enumerate'.  The
confusion discussed herein was forseen in that discussion, and
ultimately discounted.  There remains, IMO, an issue with the
clarity of the documentation that needs to be addressed.  That
is, the closed issue at

  http://bugs.python.org/issue8635

concerning the 'enumerate' docstring does not address the confusion
that prompted this posting.

Consider:

x=['a','b','c','d','e']
y=['f','g','h','i','j']
print 0,y[0]
for i,c in enumerate(y,1):
  print i,c
  if c=='g':
    print x[i], 'y[%i]=g' % (i)
    continue
  print x[i]


This code produces the following unexpected output, using python 2.7,
which is apparently the correct behavior (see commentary below).  This
example is an abstract simplification of a program defect encountered
in practice:

>>> 
0 f
1 f
b
2 g
c y[2]=g
3 h
d
4 i
e
5 j

Traceback (most recent call last):
  File "Untitled", line 9
    print x[i]
IndexError: list index out of range


Help on 'enumerate' yields:

>>> help(enumerate)
Help on class enumerate in module __builtin__:

class enumerate(object)
 |  enumerate(iterable[, start]) -> iterator for index, value of iterable
 |  
 |  Return an enumerate object.  iterable must be another object that supports
 |  iteration.  The enumerate object yields pairs containing a count (from
 |  start, which defaults to zero) and a value yielded by the iterable argument.
 |  enumerate is useful for obtaining an indexed list:
 |      (0, seq[0]), (1, seq[1]), (2, seq[2]), ...
 |  
 |  Methods defined here:
 |  
 |  __getattribute__(...)
 |      x.__getattribute__('name') <==> x.name
 |  
 |  __iter__(...)
 |      x.__iter__() <==> iter(x)
 |  
 |  next(...)
 |      x.next() -> the next value, or raise StopIteration
 |  
 |  ----------------------------------------------------------------------
 |  Data and other attributes defined here:
 |  
 |  __new__ = <built-in method __new__ of type object>
 |      T.__new__(S, ...) -> a new object with type S, a subtype of T

>>> 

Commentary:

The expected output was:
>>>
0 f
1 g
b y[2]=g
2 h
c
3 i
d
4 j
e
>>>

That is, it was expected that the iterator would yield a value
corresponding to the index, whether the index started at zero or not.
Using the notation of the doc string, with start=1, the expected
behavior was:

 |      (1, seq[1]), (2, seq[2]), (3, seq[3]), ...

while the actual behavior is:

 |      (1, seq[0]), (2, seq[1]), (3, seq[2]), ...

The practical problem in the real world code was to do something
special with the zero index value of x and y, then run through the
remaining values, doing one of two things with x and y, correlated,
depending on the value of y.

I can see now that the doc string does in fact correctly specify the
actual behavior: nowhere does it say the iterator will begin at any
other place than the beginning, so this is not a python bug.  I do
however question the general usefulness of such behavior.  Normally,
indices and values are expected to be correlated.

The correct behavior can be simply implemented without using
'enumerate':

x=['a','b','c','d','e']
y=['f','g','h','i','j']
print 0,y[0]
for i in xrange(1,len(y)):
  c=y[i]
  print i,c
  if c=='g':
    print x[i], 'y[%i]=g' % (i)
    continue
  print x[i]

This produces the expected results.

If one insists on using enumerate to produce the correct behavior in
this example, it can be done as follows:
"""
x=['a','b','c','d','e']
y=['f','g','h','i','j']
seq=enumerate(y)
print '%s %s' % seq.next()
for i,c in seq:
  print i,c
  if c=='g':
    print x[i], 'y[%i]=g' % (i)
    continue
  print x[i]
"""
This version produces the expected results, while achieving clarity
comparable to that which was sought in the original incorrect code.

Looking a little deeper, the python documentation on enumerate states:

enumerate(sequence[, start=0])
Return an enumerate object. sequence must be a sequence, an iterator,
or some other object which supports iteration. The next() method of the
iterator returned by enumerate() returns a tuple containing a count
(from start which defaults to 0) and the corresponding value obtained
from iterating over iterable. enumerate() is useful for obtaining an
indexed series:
  (0, seq[0]), (1, seq[1]), (2, seq[2]),


This makes a pretty clear implication the value corresponds to the
index, so perhaps there really is an issue here.  Have at it.  I'm
going back to work, using 'enumerate' as it actually is, now that I
clearly understand it.

One thing is certain: the documentation has to be clarified, for the
confusion foreseen prior to adding the start parameter is very real.
"""

----------
components: None
messages: 134162
nosy: phammer
priority: normal
severity: normal
status: open
title: 'enumerate' 'start' parameter documentation is confusing
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11889>
_______________________________________

From report at bugs.python.org  Wed Apr 20 18:09:57 2011
From: report at bugs.python.org (Lennart Regebro)
Date: Wed, 20 Apr 2011 16:09:57 +0000
Subject: [issue10042] total_ordering
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1303315797.52.0.566650464636.issue10042@psf.upfronthosting.co.za>


Lennart Regebro <regebro at gmail.com> added the comment:

I was also surprised by the special return value, but it seems a bit overkill to change the implementation of rich comparison operators just because it's tricky to make a short and pretty class decorator that extends some operators to all operators. :)

And removing the support for returning NotImplemented is something that only can be done at the earliest in 3.4 anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Wed Apr 20 18:41:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2011 16:41:41 +0000
Subject: [issue11887] unittest fails on comparing str with bytes if python has
	the -bb option
In-Reply-To: <1303313753.3.0.8744280471.issue11887@psf.upfronthosting.co.za>
Message-ID: <1303317701.78.0.236648058302.issue11887@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file21740/unittest_str_bytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11887>
_______________________________________

From report at bugs.python.org  Wed Apr 20 18:59:51 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 20 Apr 2011 16:59:51 +0000
Subject: [issue11890] COMPILER WARNING: warning: offset outside bounds of
	constant string
In-Reply-To: <1303318791.56.0.411259673759.issue11890@psf.upfronthosting.co.za>
Message-ID: <1303318791.56.0.411259673759.issue11890@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

Compiling current 3.1 and 3.2 show this warning:

"""
Python/sysmodule.c:1378: warning: offset outside bounds of constant string
"""

This is a bit scary. Could be a security/stability hazard?.

----------
messages: 134164
nosy: jcea
priority: normal
severity: normal
status: open
title: COMPILER WARNING: warning: offset outside bounds of constant string
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11890>
_______________________________________

From report at bugs.python.org  Wed Apr 20 19:17:39 2011
From: report at bugs.python.org (Gary Yee)
Date: Wed, 20 Apr 2011 17:17:39 +0000
Subject: [issue11891] Poll call in multiprocessing/forking.py is not thread
	safe. Results in "OSError: [Errno 10] No child processes" exceptions.
In-Reply-To: <1303319858.78.0.604473058282.issue11891@psf.upfronthosting.co.za>
Message-ID: <1303319858.78.0.604473058282.issue11891@psf.upfronthosting.co.za>


New submission from Gary Yee <gyee at penguincomputing.com>:

Background: 

I'm using multiprocessing not to run jobs in parallel, but to run functions in a different process space so they can be done as a different user.  I am thus using multiprocessing in a multithreaded (Linux) application.

Problem:

In multiprocessing/forking.py the poll() function is not thread safe.  If multiple threads call poll() you could have two back-to-back calls to os.waitpid() on the same PID (this happens frequently when multiprocessing's _cleanup() function is called).

Traceback (most recent call last):
  File "/opt/scyld/foo.py", line 178, in call
    pool = Pool(processes=1)
  File "/opt/scyld/python/2.6.5/lib/python2.6/multiprocessing/__init__.py", line 227, in Pool
    return Pool(processes, initializer, initargs)
  File "/opt/scyld/python/2.6.5/lib/python2.6/multiprocessing/pool.py", line 104, in __init__
    w.start()
  File "/opt/scyld/python/2.6.5/lib/python2.6/multiprocessing/process.py", line 99, in start
    _cleanup()
  File "/opt/scyld/python/2.6.5/lib/python2.6/multiprocessing/process.py", line 53, in _cleanup
    if p._popen.poll() is not None:
  File "/opt/scyld/python/2.6.5/lib/python2.6/multiprocessing/forking.py", line 106, in poll
    pid, sts = os.waitpid(self.pid, flag)
OSError: [Errno 10] No child processes


Suggested Fix:

Wrap the os.waitpid() call in a try/except block looking for OSError 10 exceptions and return the returncode currently available in that event.  The one potential problem this introduces is if someone calls os.waitpid() on that PID on the process without going through forking.py.  This will result in self.returncode never being set to a non-None value.  If you're using the multiprocessing module to create processes, however, you should be also using it to clean up after itself.

I've attached a test file.

----------
components: Library (Lib)
files: foo.py
messages: 134165
nosy: Gary.Yee
priority: normal
severity: normal
status: open
title: Poll call in multiprocessing/forking.py is not thread safe.  Results in "OSError: [Errno 10] No child processes" exceptions.
type: crash
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file21741/foo.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11891>
_______________________________________

From report at bugs.python.org  Wed Apr 20 19:19:08 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 20 Apr 2011 17:19:08 +0000
Subject: [issue11891] Poll call in multiprocessing/forking.py is not thread
	safe. Results in "OSError: [Errno 10] No child processes" exceptions.
In-Reply-To: <1303319858.78.0.604473058282.issue11891@psf.upfronthosting.co.za>
Message-ID: <1303319948.52.0.887611876881.issue11891@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
type: crash -> behavior
versions:  -Python 2.5, Python 2.6, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11891>
_______________________________________

From report at bugs.python.org  Wed Apr 20 19:21:48 2011
From: report at bugs.python.org (Gary Yee)
Date: Wed, 20 Apr 2011 17:21:48 +0000
Subject: [issue11891] Poll call in multiprocessing/forking.py is not thread
	safe. Results in "OSError: [Errno 10] No child processes" exceptions.
In-Reply-To: <1303319858.78.0.604473058282.issue11891@psf.upfronthosting.co.za>
Message-ID: <1303320108.31.0.0848391851436.issue11891@psf.upfronthosting.co.za>


Gary Yee <gyee at penguincomputing.com> added the comment:

Here's how I changed poll() in multiprocessing/forking.py:

        def poll(self, flag=os.WNOHANG):
            if self.returncode is None:
                try:
                    pid, sts = os.waitpid(self.pid, flag)
                except OSError, e:
                    if e.errno == 10:
                        return self.returncode
                    else:
                        raise
                if pid == self.pid:
                    if os.WIFSIGNALED(sts):
                        self.returncode = -os.WTERMSIG(sts)
                    else:
                        assert os.WIFEXITED(sts)
                        self.returncode = os.WEXITSTATUS(sts)
            return self.returncode

----------
versions: +Python 2.5, Python 2.6, Python 3.4 -Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11891>
_______________________________________

From report at bugs.python.org  Wed Apr 20 19:28:14 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 20 Apr 2011 17:28:14 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1303320494.19.0.417861166435.issue11888@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Wed Apr 20 19:44:56 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 20 Apr 2011 17:44:56 +0000
Subject: [issue11890] COMPILER WARNING: warning: offset outside bounds of
	constant string
In-Reply-To: <1303318791.56.0.411259673759.issue11890@psf.upfronthosting.co.za>
Message-ID: <1303321496.05.0.312244052557.issue11890@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

This was introduced in 7327b4dbd4f0 and related changesets.

The problem doesn't affect 2.7 because of d52b1faa7b11. I would suggest to upport that changeset to 3.1 and 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11890>
_______________________________________

From report at bugs.python.org  Wed Apr 20 19:51:01 2011
From: report at bugs.python.org (Gary Yee)
Date: Wed, 20 Apr 2011 17:51:01 +0000
Subject: [issue11891] Poll call in multiprocessing/forking.py is not thread
	safe. Results in "OSError: [Errno 10] No child processes" exceptions.
In-Reply-To: <1303319858.78.0.604473058282.issue11891@psf.upfronthosting.co.za>
Message-ID: <1303321861.14.0.322364254467.issue11891@psf.upfronthosting.co.za>


Gary Yee <gyee at penguincomputing.com> added the comment:

It looks like this has been addressed in the svn trunk as part of bug: #1731717.  I was using version 2.6.5.  Any chance that this gets backported?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11891>
_______________________________________

From report at bugs.python.org  Wed Apr 20 19:52:42 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Apr 2011 17:52:42 +0000
Subject: [issue11889] 'enumerate' 'start' parameter documentation is confusing
In-Reply-To: <1303315736.72.0.416681647484.issue11889@psf.upfronthosting.co.za>
Message-ID: <1303321962.21.0.914408770974.issue11889@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If you know what an iterator is, the documentation, it seems to me, is clear.  That is, an iterator cannot be indexed, so the behavior you expected could not be implemented by enumerate.

That doesn't meant the docs shouldn't be improved.  An example with a non-zero start would make things clear.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11889>
_______________________________________

From report at bugs.python.org  Wed Apr 20 19:53:55 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 20 Apr 2011 17:53:55 +0000
Subject: [issue11891] Poll call in multiprocessing/forking.py is not thread
	safe. Results in "OSError: [Errno 10] No child processes" exceptions.
In-Reply-To: <1303319858.78.0.604473058282.issue11891@psf.upfronthosting.co.za>
Message-ID: <1303322035.24.0.835374579458.issue11891@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

2.6 is only receiving security fixes at the moment, so it won't make it into there.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11891>
_______________________________________

From report at bugs.python.org  Wed Apr 20 20:00:31 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 20 Apr 2011 18:00:31 +0000
Subject: [issue11890] COMPILER WARNING: warning: offset outside bounds of
	constant string
In-Reply-To: <1303318791.56.0.411259673759.issue11890@psf.upfronthosting.co.za>
Message-ID: <1303322431.8.0.600913777894.issue11890@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Sorry, the correct changeset was 5cf8f6da8743.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11890>
_______________________________________

From report at bugs.python.org  Wed Apr 20 20:26:09 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 20 Apr 2011 18:26:09 +0000
Subject: [issue11890] COMPILER WARNING: warning: offset outside bounds of
	constant string
In-Reply-To: <1303318791.56.0.411259673759.issue11890@psf.upfronthosting.co.za>
Message-ID: <1303323969.2.0.179224338479.issue11890@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
assignee:  -> jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11890>
_______________________________________

From report at bugs.python.org  Wed Apr 20 20:26:23 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 20 Apr 2011 18:26:23 +0000
Subject: [issue11891] Poll call in multiprocessing/forking.py is not thread
	safe. Results in "OSError: [Errno 10] No child processes" exceptions.
In-Reply-To: <1303319858.78.0.604473058282.issue11891@psf.upfronthosting.co.za>
Message-ID: <1303323983.16.0.413428857948.issue11891@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11891>
_______________________________________

From report at bugs.python.org  Wed Apr 20 21:14:38 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Apr 2011 19:14:38 +0000
Subject: [issue11890] COMPILER WARNING: warning: offset outside bounds of
	constant string
In-Reply-To: <1303318791.56.0.411259673759.issue11890@psf.upfronthosting.co.za>
Message-ID: <E1QCcrF-0007UO-Ej@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset febb6cf195e7 by Jesus Cea in branch '3.1':
Up-port changeset 5cf8f6da8743 (closes #11890)
http://hg.python.org/cpython/rev/febb6cf195e7

New changeset 063b4ab49fcc by Jesus Cea in branch '3.2':
MERGE: Up-port changeset 5cf8f6da8743 (closes #11890)
http://hg.python.org/cpython/rev/063b4ab49fcc

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11890>
_______________________________________

From report at bugs.python.org  Wed Apr 20 21:26:38 2011
From: report at bugs.python.org (Daniel Urban)
Date: Wed, 20 Apr 2011 19:26:38 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1303327598.83.0.887294701404.issue1294232@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

That may be, but with my latest patch, this works (func is a function):

class X(metaclass=func):
    pass

But this blows up with a TypeError:

class X(object, metaclass=func):
    pass

Is this the desired behaviour? Or should we disallow non-class metaclasses in every case? (And what about backwards-compatibility?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Wed Apr 20 21:27:27 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 20 Apr 2011 19:27:27 +0000
Subject: [issue11889] 'enumerate' 'start' parameter documentation is confusing
In-Reply-To: <1303315736.72.0.416681647484.issue11889@psf.upfronthosting.co.za>
Message-ID: <1303327647.59.0.486652742454.issue11889@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
components: +Documentation -None
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11889>
_______________________________________

From report at bugs.python.org  Wed Apr 20 21:31:12 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 20 Apr 2011 19:31:12 +0000
Subject: [issue11886] test_time.test_tzset() fails on "x86 FreeBSD 7.2 3.x":
	AEST timezone called "EST"
In-Reply-To: <1303307593.46.0.897474878267.issue11886@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=Oia0wp0+i7m-FFj7DJbtbyP_Zvw@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Apr 20, 2011 at 9:53 AM, STINNER Victor <report at bugs.python.org> wrote:
..
> test_time.test_tzset() fails on "x86 FreeBSD 7.2 3.x": 'AEST-10AEDT-11,M10.5.0,M3.5.0' timezone becomes 'EST'.

I was able to reproduce this error by faking a file named
'AEST-10AEDT-11,M10.5.0,M3.5.0' in /usr/share/zoneinfo/ on Mac OS X.
(As far as I know, OSX is not that different from BSD with respect to
basic posix interfaces.)

$ cd /usr/share/zoneinfo/
$ sudo cp EST AEST-10AEDT-11,M10.5.0,M3.5.0

Is it possible that the buildbot has such a file?  What I find strange
is that autoconf logic tests for working tzset using exactly the same
TZ spec:

"""
        putenv("TZ=AEST-10AEDT-11,M10.5.0,M3.5.0");
        tzset();
        if (localtime(&groundhogday)->tm_hour != 11)
            exit(1);
#if HAVE_TZNAME
        if (strcmp(tzname[0], "AEST") || strcmp(tzname[1], "AEDT"))
            exit(1);
#endif
"""  See 'configure' script.

In other words, if TZ=AEST-10AEDT-11,M10.5.0,M3.5.0 breaks tzset, this
should be detected at the configure stage and the tzset tests should
be skipped.   Is there a way to force configure run on the bot?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11886>
_______________________________________

From report at bugs.python.org  Wed Apr 20 21:35:29 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 20 Apr 2011 19:35:29 +0000
Subject: [issue11892] Compiler warning: warning: implicit declaration of
	function 'finite'
In-Reply-To: <1303328129.11.0.303568754057.issue11892@psf.upfronthosting.co.za>
Message-ID: <1303328129.11.0.303568754057.issue11892@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

Compiling 3.1, I get this warning:

"""
/export/home/buildbot/32bits/3.1.cea-indiana-x86/build/Modules/cmathmodule.c:77: warning: implicit declaration of function 'finite'
/export/home/buildbot/32bits/3.1.cea-indiana-x86/build/Modules/mathmodule.c:149: warning: implicit declaration of function 'finite'
/export/home/buildbot/32bits/3.1.cea-indiana-x86/build/Modules/_json.c:1222: warning: implicit declaration of function 'finite'
"""

----------
assignee: jcea
components: Build
messages: 134175
nosy: jcea
priority: normal
severity: normal
status: open
title: Compiler warning: warning: implicit declaration of function 'finite'
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11892>
_______________________________________

From report at bugs.python.org  Wed Apr 20 21:40:36 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 20 Apr 2011 19:40:36 +0000
Subject: [issue11892] Compiler warning: warning: implicit declaration of
	function 'finite'
In-Reply-To: <1303328129.11.0.303568754057.issue11892@psf.upfronthosting.co.za>
Message-ID: <1303328436.35.0.812201218429.issue11892@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you please check whether math.h hides the finite declaration for some reason?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11892>
_______________________________________

From report at bugs.python.org  Wed Apr 20 21:58:15 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 20 Apr 2011 19:58:15 +0000
Subject: [issue11879] TarFile.chown: should use TarInfo.uid if user lookup
	fails
In-Reply-To: <1303229015.7.0.433519463198.issue11879@psf.upfronthosting.co.za>
Message-ID: <1303329495.38.0.247889699266.issue11879@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11879>
_______________________________________

From report at bugs.python.org  Wed Apr 20 21:59:20 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 20 Apr 2011 19:59:20 +0000
Subject: [issue11884] Argparse calls ngettext but doesn't import it
In-Reply-To: <1303285010.85.0.710971435429.issue11884@psf.upfronthosting.co.za>
Message-ID: <1303329560.42.0.993547966461.issue11884@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +bethard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11884>
_______________________________________

From report at bugs.python.org  Wed Apr 20 22:03:59 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 20 Apr 2011 20:03:59 +0000
Subject: [issue11892] Compiler warning: warning: implicit declaration of
	function 'finite'
In-Reply-To: <1303328129.11.0.303568754057.issue11892@psf.upfronthosting.co.za>
Message-ID: <1303329839.25.0.874151304929.issue11892@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Porting 5b607cd8c71b...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11892>
_______________________________________

From report at bugs.python.org  Wed Apr 20 22:22:32 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 20 Apr 2011 20:22:32 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1303330952.82.0.328442792697.issue1294232@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

class X(metaclass=func) should definitely continue to work; that is a long-standing (if relatively unknown, and very advanced) feature. In fact, metaclasses have their origins in this, via the "Don Beaudry hook" -- see http://python-history.blogspot.com/2009/04/metaclasses-and-extension-classes-aka.html .

IMO we should also keep class X(object, metaclass=func) working; it should just construct a tuple of bases (object,) and pass it to func.

I realize there is now a circular dependency: you need the metaclass computation in order to find the metaclass and you need the metaclass in order to find the prepare hook, but you need to call the prepare hook before you call the metaclass and hence before the metaclass computation is carried out.  I'm not sure how to reconcile that but I think we should look harder rather than give up.

As to how PEP 3115 seems to imply that all classes derive from object, that only applies as long as their metaclass is (derived from) type.  And that is in a sense a tautology since (dynamically) we only call something a class if its metaclass is (derived from) type.  However the class statement does not necessarily create a class object!  It creates whatever the metaclass creates, with suitable defaults: if there's no explicit metaclass, look at the class of the first given base; if no bases are given either, use object.  But an explicit metaclass should win.

Maybe the metaclass computation (which should come up with the "most derived" metaclass if there are multiple bases or bases and a metaclass) is something that we can give a name as another attribute on the "initial" metaclass, and a suitable default?  Let's say __compute_metaclass__(tuple_of_bases).  The default could be the initial metaclass, and type could override it to do the correct computation (which computes the most derived metaclass, and raises an error if any of the bases has a metaclass that is not in the answer's ancestor).  Then this computation could run before we get __prepare__ (from the answer).  When metaclass=func is given one could have __prepare__ as a function attribute and even the __compute_metacass__ could be overridden as a function attribute, so everything is still fully general.

[Sorry for blathering on. Not feeling great.]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Wed Apr 20 22:38:01 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 20 Apr 2011 20:38:01 +0000
Subject: [issue11877] Mac OS X fsync() should really be fcntl(F_FULLFSYNC)
In-Reply-To: <1303212938.57.0.821096700769.issue11877@psf.upfronthosting.co.za>
Message-ID: <20110420203749.GA55302@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Ronald Oussoren wrote:
> Adding the F_FULLSYNC option to os.fsync would be fine though

To show you that i'm not unteachable i'll attach a patch which
does that.
This approach can be heavily extended, then, e.g. by using
sync_file_range(all_the_flags) on Linux if the "full_fsync"
argument is true?!  (And then there is sync_file_range2() on
PowerPC and nice ARM...)

(The first time that i use PyArg_xy plus plus - please review.
test_os is ok and using "os.fsync(xy, True)" makes test_zlib
succeed on unpatched hg checkout.
os.rst change is really ugly.)

----------
Added file: http://bugs.python.org/file21742/11877.optarg-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________
-------------- next part --------------
diff --git a/Doc/library/os.rst b/Doc/library/os.rst
--- a/Doc/library/os.rst
+++ b/Doc/library/os.rst
@@ -798,7 +798,7 @@
    Availability: Unix.
 
 
-.. function:: fsync(fd)
+.. function:: fsync(fd, full_fsync=False)
 
    Force write of file with filedescriptor *fd* to disk.  On Unix, this calls the
    native :c:func:`fsync` function; on Windows, the MS :c:func:`_commit` function.
@@ -807,6 +807,13 @@
    ``f.flush()``, and then do ``os.fsync(f.fileno())``, to ensure that all internal
    buffers associated with *f* are written to disk.
 
+   Note that :c:func:`fsync` only ensures that the OS flushs all data to
+   the disk device, *not* that the data is actually written by the
+   device itself.  For this to happen, use the *full_fsync* argument.
+   If this is true Python tries to accomplish even the device write,
+   e.g. on Mac OS X by calling  :c:func:`fcntl` with the
+   :data:`F_FULLFSYNC` command.
+
    Availability: Unix, and Windows.
 
 
diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -2119,12 +2119,38 @@
 
 #ifdef HAVE_FSYNC
 PyDoc_STRVAR(posix_fsync__doc__,
-"fsync(fildes)\n\n\
-force write of file with filedescriptor to disk.");
-
-static PyObject *
-posix_fsync(PyObject *self, PyObject *fdobj)
-{
+"fsync(fildes, full_fsync=False)\n\n"
+"force write of file with filedescriptor to disk.\n"
+"if full_fsync is True it also ensures write to physical backing store.");
+
+static PyObject *
+posix_fsync(PyObject *self, PyObject *args, PyObject *kwargs)
+{
+    auto PyObject *fdobj;
+    auto int full_fsync = 1;
+    static char *keywords[] = {"fd", "full_fsync", NULL };
+
+    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "O|i", keywords,
+                                     &fdobj, &full_fsync))
+        return NULL;
+
+# ifdef __APPLE__
+    /* See issue 11877 discussion and issue 11277 for OS X sparse file bug */
+    if (full_fsync != 0) {
+        int res, fd = PyObject_AsFileDescriptor(fdobj);
+        if (fd < 0)
+            return NULL;
+        if (!_PyVerify_fd(fd))
+            return posix_error();
+        Py_BEGIN_ALLOW_THREADS
+        res = fcntl(fd, F_FULLFSYNC);
+        Py_END_ALLOW_THREADS
+        if (res < 0)
+            return posix_error();
+        Py_INCREF(Py_None);
+        return Py_None;
+    }
+# endif
     return posix_fildes(fdobj, fsync);
 }
 #endif /* HAVE_FSYNC */
@@ -9484,7 +9510,8 @@
     {"fchdir",          posix_fchdir, METH_O, posix_fchdir__doc__},
 #endif
 #ifdef HAVE_FSYNC
-    {"fsync",       posix_fsync, METH_O, posix_fsync__doc__},
+    {"fsync",           (PyCFunction)posix_fsync, METH_VARARGS|METH_KEYWORDS,
+                        posix_fsync__doc__},
 #endif
 #ifdef HAVE_SYNC
     {"sync",        posix_sync, METH_NOARGS, posix_sync__doc__},

From report at bugs.python.org  Wed Apr 20 22:41:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Apr 2011 20:41:49 +0000
Subject: [issue11892] Compiler warning: warning: implicit declaration of
	function 'finite'
In-Reply-To: <1303328129.11.0.303568754057.issue11892@psf.upfronthosting.co.za>
Message-ID: <E1QCeDY-0006iH-KL@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 358a0dd0a9f2 by Jesus Cea in branch '3.1':
Port 5b607cd8c71b (closes #11892)
http://hg.python.org/cpython/rev/358a0dd0a9f2

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11892>
_______________________________________

From report at bugs.python.org  Wed Apr 20 22:52:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Apr 2011 20:52:37 +0000
Subject: [issue8809] smtplib should support SSL contexts
In-Reply-To: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>
Message-ID: <1303332757.26.0.816338857595.issue8809@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the patch. A couple of comments:
- it would be nice to have some tests, but of course there are no tests for SMTP_SSL currently. If you are motivated, perhaps you could investigate into adding some.
- there are some tab characters in your patch. Please only use spaces for indentation (see PEP 8 if you have any doubts); make sure your editor is configured for that :)
- starttls() should probably get a context parameter too. You can take a look at imaplib for an example.
- you need to update the API docs in Doc/library/smtplib.rst

I don't think an example of using a context is necessary. By using proper ReST markup a link will be generated to the SSLContext documentation, and that's probably enough for people to understand.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8809>
_______________________________________

From report at bugs.python.org  Wed Apr 20 22:54:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Apr 2011 20:54:45 +0000
Subject: [issue11893] Obsolete SSLFakeFile in smtplib?
In-Reply-To: <1303332884.98.0.410323888418.issue11893@psf.upfronthosting.co.za>
Message-ID: <1303332884.98.0.410323888418.issue11893@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

smtplib uses a wrapper class "SSLFakeFile" in order to call readline() on an SSL socket. But modern SSL sockets have makefile(), so using that wrapper class really shouldn't necessary (of course, it must be investigated whether that's true - and we have no tests for SMTP-over-SSL AFAIK :/).

----------
components: Library (Lib)
keywords: easy
messages: 134182
nosy: giampaolo.rodola, janssen, kasun, pitrou
priority: low
severity: normal
status: open
title: Obsolete SSLFakeFile in smtplib?
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11893>
_______________________________________

From report at bugs.python.org  Wed Apr 20 23:16:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2011 21:16:55 +0000
Subject: [issue11619] On Windows,
	don't encode filenames in the import machinery
In-Reply-To: <1300665531.85.0.426527059221.issue11619@psf.upfronthosting.co.za>
Message-ID: <1303334215.12.0.00816616818311.issue11619@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

compile_filename.patch:
 - Add PyErr_ProgramTextObject() and PyErr_WarnExplicitObject() functions
 - Store the filename as Unicode in compile.c
 - Remove the filename from get_ref_type() fatal error (I never see such fatal error, and I hope that it does never happen, so the filename should not really matter here)

The patch prepares the work to pass the filename to the compiler directly as Unicode.

----------
Added file: http://bugs.python.org/file21743/compile_filename.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11619>
_______________________________________

From report at bugs.python.org  Wed Apr 20 23:22:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2011 21:22:51 +0000
Subject: [issue11894] test_multiprocessing failure on "AMD64 OpenIndiana 3.x":
	KeyError on id_to_obj[ident] in serve_client()
In-Reply-To: <1303334571.86.0.241463514894.issue11894@psf.upfronthosting.co.za>
Message-ID: <1303334571.86.0.241463514894.issue11894@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

[129/354] test_multiprocessing
Process Process-72:
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/multiprocessing/process.py", line 263, in _bootstrap
    self.run()
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/multiprocessing/process.py", line 118, in run
    self._target(*self._args, **self._kwargs)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_multiprocessing.py", line 799, in _test_event
    event.set()
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/multiprocessing/managers.py", line 1009, in set
    return self._callmethod('set')
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/multiprocessing/managers.py", line 776, in _callmethod
    raise convert_to_error(kind, result)
multiprocessing.managers.RemoteError: 
---------------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/multiprocessing/managers.py", line 245, in serve_client
    obj, exposed, gettypeid = id_to_obj[ident]
KeyError: '4e17d80'
---------------------------------------------------------------------------
test test_multiprocessing failed -- Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_multiprocessing.py", line 831, in test_event
    self.assertEqual(wait(), True)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_multiprocessing.py", line 98, in __call__
    return self.func(*args, **kwds)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/multiprocessing/managers.py", line 1013, in wait
    return self._callmethod('wait', (timeout,))
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/multiprocessing/managers.py", line 776, in _callmethod
    raise convert_to_error(kind, result)
multiprocessing.managers.RemoteError: 
---------------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/multiprocessing/managers.py", line 245, in serve_client
    obj, exposed, gettypeid = id_to_obj[ident]
KeyError: '4e17d80'
---------------------------------------------------------------------------
http://www.python.org/dev/buildbot/all/builders/AMD64%20OpenIndiana%203.x/builds/1025/steps/test/logs/stdio

----------
components: Library (Lib)
messages: 134184
nosy: haypo
priority: normal
severity: normal
status: open
title: test_multiprocessing failure on "AMD64 OpenIndiana 3.x": KeyError on id_to_obj[ident] in serve_client()
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11894>
_______________________________________

From report at bugs.python.org  Wed Apr 20 23:42:25 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2011 21:42:25 +0000
Subject: [issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1303335745.54.0.786623488989.issue8407@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file21735/signal_pthread_sigmask.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Thu Apr 21 00:17:49 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 20 Apr 2011 22:17:49 +0000
Subject: [issue7796] No way to find out if an object is an instance of a
	namedtuple
In-Reply-To: <1264608669.85.0.379125118171.issue7796@psf.upfronthosting.co.za>
Message-ID: <1303337869.55.0.025931617059.issue7796@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Detecting _fields is the simplest thing we can do right now.  There are too many structseq API differences to warrant bringing them under a single ABC umbrella.

----------
dependencies:  -Enhance Object/structseq.c to match namedtuple and tuple	api
resolution: later -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7796>
_______________________________________

From report at bugs.python.org  Thu Apr 21 00:25:22 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 20 Apr 2011 22:25:22 +0000
Subject: [issue10977] Concrete object C API considered harmful to subclasses
	of builtin types
In-Reply-To: <1295653779.62.0.836506069174.issue10977@psf.upfronthosting.co.za>
Message-ID: <1303338322.77.0.0881194379046.issue10977@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
title: Concrete object C API needs abstract path for subclasses of builtin types -> Concrete object C API considered harmful to subclasses of builtin types

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10977>
_______________________________________

From report at bugs.python.org  Thu Apr 21 00:45:06 2011
From: report at bugs.python.org (Darren Dale)
Date: Wed, 20 Apr 2011 22:45:06 +0000
Subject: [issue8094] Multiprocessing infinite loop
In-Reply-To: <1268125314.35.0.202558750367.issue8094@psf.upfronthosting.co.za>
Message-ID: <1303339506.21.0.967518498466.issue8094@psf.upfronthosting.co.za>


Darren Dale <dsdale24 at gmail.com> added the comment:

I think I have a similar situation:

C:\Py\Scripts\foo
---
if __name__ == '__main__':
    import bar
    bar.main()

C:\Py\Lib\site-packages\bar.py
---
from multiprocessing import Pool

def task(arg):
    return arg

def main():
    pool = Pool()
    res = pool.apply_async(task, (3.14,))

    print res.get()

if __name__ == '__main__':
    main()


I can run "python bar.py". "python C:\Py\Scripts\foo" yields an infinite stream of errors:

 File "<string>", line 1 in <module>
 File "C:\Python27\lib\multiprocessing\forking.py", line 346, in main
     prepare(preparation_data)
 File "C:\Python27\lib\multiprocessing\forking.py", line 455, in prepare
     file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named foo

This same scheme works fine on linux. Have I just overlooked something simple?

----------
nosy: +dsdale24

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8094>
_______________________________________

From report at bugs.python.org  Thu Apr 21 01:15:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2011 23:15:22 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when
	locks are implemented using POSIX condition variables
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1303341322.01.0.722397594727.issue11223@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

sys_thread_info.patch:
 - Replace threading._info() by sys.thread_info: it now always have 3 values, but all values are optional (can be None). sys.thread_info.name is None if Python is compiled without threads.
 - Reorder sys internal doc (Static objects) and replace "dict" by "struct sequence" for float_info
 - Rename _PyThread_Info() to PyThread_GetInfo() (consistent name with PyFloat_GetInfo() and PyLong_GetInfo())
 - Always compile thread.c, but add #ifdef WITH_THREAD around most the file (except PyThread_GetInfo())

Example:

>>> sys.thread_info
sys.thread_info(name='pthread', lock='semaphore', version='NPTL 2.11.2')

----------
nosy: +benjamin.peterson
Added file: http://bugs.python.org/file21744/sys_thread_info.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Thu Apr 21 01:15:33 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Apr 2011 23:15:33 +0000
Subject: [issue8094] Multiprocessing infinite loop
In-Reply-To: <1268125314.35.0.202558750367.issue8094@psf.upfronthosting.co.za>
Message-ID: <1303341333.25.0.568860782479.issue8094@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Your code doesn't appear to have anything to do with the reported bug, which is about an infinite loop.  But FYI to my understanding your script can't work on windows, since foo can't be imported.  On linux, foo doesn't need to be imported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8094>
_______________________________________

From report at bugs.python.org  Thu Apr 21 01:20:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Apr 2011 23:20:24 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when
	locks are implemented using POSIX condition variables
In-Reply-To: <1303341322.01.0.722397594727.issue11223@psf.upfronthosting.co.za>
Message-ID: <1303341621.3493.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

>  - Rename _PyThread_Info() to PyThread_GetInfo() (consistent name with
> PyFloat_GetInfo() and PyLong_GetInfo())

I don't think we want that API to be public, so it should be
_PyThread_GetInfo().

>  - Always compile thread.c, but add #ifdef WITH_THREAD around most the
> file (except PyThread_GetInfo())

What's the point? Sounds like pointless complication.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Thu Apr 21 05:20:13 2011
From: report at bugs.python.org (Mikhail Terekhov)
Date: Thu, 21 Apr 2011 03:20:13 +0000
Subject: [issue11895] pybench prep_times calculation error
In-Reply-To: <1303356013.22.0.66518331753.issue11895@psf.upfronthosting.co.za>
Message-ID: <1303356013.22.0.66518331753.issue11895@psf.upfronthosting.co.za>


New submission from Mikhail Terekhov <termim at gmail.com>:

For some time now my builds of python 3.2 on x86_64 platform in SuSE OBS are failing depending on the phase of the moon. The spec file for the python3-base package uses 'make profile-opt' command to build and Makefile.pre.in uses pybench.py for profile guided optimization. The pybench.py fails sometimes with the '* Internal Error (use --debug to display the traceback)' error. Adding --debug gives 'calibration setup did not work' i.e. some of the self.overhead_times values in the Test.calibrate_test method became negative. It happens for the  NestedForLoops test. The source inspection shows that most probably it was forgotten to divide by CALIBRATION_LOOPS when calculating prep_times. The patch against current head is attached, it solves the problem.

----------
components: Demos and Tools, Installation
files: pybench.patch
keywords: patch
messages: 134192
nosy: termim
priority: normal
severity: normal
status: open
title: pybench prep_times calculation error
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file21745/pybench.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11895>
_______________________________________

From report at bugs.python.org  Thu Apr 21 05:55:38 2011
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Thu, 21 Apr 2011 03:55:38 +0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1303358138.62.0.769146298551.issue1322@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

For what it is worth, here is the current version of this code that we are using in Tahoe-LAFS:

http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/__init__.py?annotate=blame&rev=5033#L36

You can see the results on our buildbot:

http://tahoe-lafs.org/buildbot/waterfall?show_events=false

In the tahoe-version build step, e.g.:

http://tahoe-lafs.org/buildbot/builders/Eugen%20lenny-amd64/builds/820/steps/tahoe-version/logs/stdio

Which says:

platform: Linux-debian_5.0.6-x86_64-64bit

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Thu Apr 21 08:06:06 2011
From: report at bugs.python.org (marcus harris)
Date: Thu, 21 Apr 2011 06:06:06 +0000
Subject: [issue11896] Save on Close fails in IDLE, from Linux system
In-Reply-To: <1303365966.87.0.683808502897.issue11896@psf.upfronthosting.co.za>
Message-ID: <1303365966.87.0.683808502897.issue11896@psf.upfronthosting.co.za>


New submission from marcus harris <harrismh777 at charter.net>:

Under some circumstances, which I will detail later down the note, if I click File --> Close without explicitly saving, and without running the module with Run --> Run Module , then the last changes I made to the file do not get saved. The save dialogue pop-up does appear, and I do select YES--- I want to save before closing--- but when I re-open the file (IDLE or vi) the changes are not there... as though the save binding did not work, or like there was some timing glitch that prevented the save somehow before the edit window closed down. The error is not solid, in that, if the file is larger (significantly) then the File --> Close (select Yes on the dialogue) does work... ??

The work around is to do either 1) run the module, or 2) explicitly click File --> Save.

The alleged bug can be reproduced on both of my primary desk machines, Linux systems, using IDLE on 2.6, 2.7, and 3.2/  These are the instructions for reproducing this little snag:

1) Open a new edit window with File --> New Window

2) Enter the following code on the first two lines:
def testfunc():
    return None

3) Click File --> Save    ( testit.py )

4) Click File --> Close

5) Open the file with  File --> Recent Files   ( select testit.py )

6) Use the edit window to place these three lines above testfunc:
############################
# comment block
##############################

7) Click    File --> Close

8) When the Save on Close dialogue appears select "Yes"

9) Re-open the file with   File --> Recent Files   ( select testit.py )

10) The comment block will not be there...  didn't save. 


Running on Ubuntu 9.10  (all updates)

Tk  8.5.x

reproduced on built-in 2.6
   & compiled from sources...   2.7  &  3.2

kind regards,
m harris

----------
components: IDLE, Library (Lib), Tkinter
messages: 134194
nosy: marcus777, terry.reedy
priority: normal
severity: normal
status: open
title: Save on Close fails in IDLE, from Linux system
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11896>
_______________________________________

From report at bugs.python.org  Thu Apr 21 08:14:34 2011
From: report at bugs.python.org (marcus harris)
Date: Thu, 21 Apr 2011 06:14:34 +0000
Subject: [issue11896] Save on Close fails in IDLE, from Linux system
In-Reply-To: <1303365966.87.0.683808502897.issue11896@psf.upfronthosting.co.za>
Message-ID: <1303366474.56.0.956257356232.issue11896@psf.upfronthosting.co.za>


marcus harris <harrismh777 at charter.net> added the comment:

Terry Reedy was not able to reproduce this snag on an XP system; however, suggested there might be a real save on close error on the linux side... also requested to be place on the nosy list...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11896>
_______________________________________

From report at bugs.python.org  Thu Apr 21 09:39:38 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 21 Apr 2011 07:39:38 +0000
Subject: [issue11896] Save on Close fails in IDLE, from Linux system
In-Reply-To: <1303365966.87.0.683808502897.issue11896@psf.upfronthosting.co.za>
Message-ID: <1303371578.28.0.0137066787434.issue11896@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for the precise test case.  I am able to reproduce the failure on OS X using the MacPorts X11-Tk Tkinter but not with the standard OS X AquaTk Tkinter.

----------
assignee:  -> ned.deily
nosy: +ned.deily
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11896>
_______________________________________

From report at bugs.python.org  Thu Apr 21 10:46:02 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 21 Apr 2011 08:46:02 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1303375562.98.0.283914305209.issue11888@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

See also issue 3724.

I'm -0 on this:  between log(x, 2) and int.bit_length, there's not much need for log2.  log(x, 2) should be plenty accurate enough for most numerical needs;  the exception is when you're taking log base 2 of an integer and need a guarantee of exact results for powers of 2, and int.bit_length generally solves that problem.

The main issue is that we'd have to provide (and maintain) our own implementation of log2 for Windows (and other OSs that don't have all the C99 support.  Solaris?)  That implementation should, ideally:

 - provide exact values for powers of 2, and
 - be monotonic.

and that's not trivial.  As Raymond points out, on x86 / x64 we might be able to use inline assembly directly;  that would probably cover us for Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Thu Apr 21 10:48:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Apr 2011 08:48:35 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1303375715.89.0.376029336109.issue11888@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The main issue is that we'd have to provide (and maintain) our own
> implementation of log2 for Windows (and other OSs that don't have all
> the C99 support.  Solaris?)

No, we don't have to. Python has already a lot of optional functions, see for example the os module. We can provide log2() only if the C library has this function.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Thu Apr 21 10:50:09 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 21 Apr 2011 08:50:09 +0000
Subject: [issue10596] modulo operator bug
In-Reply-To: <1291204399.82.0.975884133816.issue10596@psf.upfronthosting.co.za>
Message-ID: <1303375809.14.0.593599595122.issue10596@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Raymond: just curious---why do you ask?  Did this fix break something?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10596>
_______________________________________

From report at bugs.python.org  Thu Apr 21 10:52:10 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 21 Apr 2011 08:52:10 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1303375930.2.0.0782065651268.issue11888@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> We can provide log2() only if the C library has this function.

Big -1 from me:  I'd hate to see working Python scripts written on Unix fail on Windows because of a missing log2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Thu Apr 21 10:59:49 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 21 Apr 2011 08:59:49 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1303376389.35.0.559981660634.issue11888@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Rather than reinventing the wheel, it may be worth looking at what numpy does here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Thu Apr 21 11:16:31 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 21 Apr 2011 09:16:31 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1303377391.11.0.971336768502.issue11888@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> it may be worth looking at what numpy does here.

... or it may not.  NumPy just uses (approximation to 1/log(2)) * log(x) when log2 doesn't already exist.  And indeed, on Windows:

Python 2.7.1 |EPD 7.0-2 (64-bit)| (r271:86832, Dec  2 2010, 10:23:25) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> numpy.log2(8.0)
2.9999999999999996

I think we should be able to do better than this. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Thu Apr 21 11:30:25 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 21 Apr 2011 09:30:25 +0000
Subject: [issue11895] pybench prep_times calculation error
In-Reply-To: <1303356013.22.0.66518331753.issue11895@psf.upfronthosting.co.za>
Message-ID: <4DAFF92A.7090106@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Mikhail Terekhov wrote:
> 
> New submission from Mikhail Terekhov <termim at gmail.com>:
> 
> For some time now my builds of python 3.2 on x86_64 platform in SuSE OBS are failing depending on the phase of the moon. The spec file for the python3-base package uses 'make profile-opt' command to build and Makefile.pre.in uses pybench.py for profile guided optimization. The pybench.py fails sometimes with the '* Internal Error (use --debug to display the traceback)' error. Adding --debug gives 'calibration setup did not work' i.e. some of the self.overhead_times values in the Test.calibrate_test method became negative. It happens for the  NestedForLoops test. The source inspection shows that most probably it was forgotten to divide by CALIBRATION_LOOPS when calculating prep_times. The patch against current head is attached, it solves the problem.

Good catch. Your analysis is correct.

Interesting that it took more than
6 years to discover this bug... looks like CPUs got more than
20 times faster since back then.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11895>
_______________________________________

From report at bugs.python.org  Thu Apr 21 11:56:00 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 21 Apr 2011 09:56:00 +0000
Subject: [issue11892] Compiler warning: warning: implicit declaration of
	function 'finite'
In-Reply-To: <1303328129.11.0.303568754057.issue11892@psf.upfronthosting.co.za>
Message-ID: <1303379760.52.0.927778850364.issue11892@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11892>
_______________________________________

From report at bugs.python.org  Thu Apr 21 11:58:39 2011
From: report at bugs.python.org (Francesco Ricciardi)
Date: Thu, 21 Apr 2011 09:58:39 +0000
Subject: [issue10042] total_ordering
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1303379919.81.0.70339406906.issue10042@psf.upfronthosting.co.za>


Francesco Ricciardi <francescor2010 at yahoo.it> added the comment:

On the one hand, it's not just a matter of total_ordering and rich comparison operators, because all user defined operators may return NotImplemented when they get types that they don't know how to handle.

On the other hand, if such a decision is taken, a long path should be planned to move handling of unknown types from one way to the other.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Thu Apr 21 12:09:21 2011
From: report at bugs.python.org (intgr)
Date: Thu, 21 Apr 2011 10:09:21 +0000
Subject: [issue11897] [PATCH] Documentation: fix typo,
	absolute_import not absolute_imports
In-Reply-To: <1303380560.99.0.860911638141.issue11897@psf.upfronthosting.co.za>
Message-ID: <1303380560.99.0.860911638141.issue11897@psf.upfronthosting.co.za>


New submission from intgr <marti at juffo.org>:

The "Porting Python 2 Code to Python 3" guide currently says:
   from __future__ import absolute_imports

However it should be singular:
   from __future__ import absolute_import

----------
assignee: docs at python
components: Documentation
files: absolute_import_singular.patch
keywords: patch
messages: 134206
nosy: docs at python, intgr
priority: normal
severity: normal
status: open
title: [PATCH] Documentation: fix typo, absolute_import not absolute_imports
versions: Python 3.2
Added file: http://bugs.python.org/file21746/absolute_import_singular.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11897>
_______________________________________

From report at bugs.python.org  Thu Apr 21 13:50:39 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Apr 2011 11:50:39 +0000
Subject: [issue11897] [PATCH] Documentation: fix typo,
	absolute_import not absolute_imports
In-Reply-To: <1303380560.99.0.860911638141.issue11897@psf.upfronthosting.co.za>
Message-ID: <E1QCsP2-0001dk-OG@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 05a7d3048c49 by Ezio Melotti in branch '3.2':
#11897: Fix typo in porting howto. Patch by Marti Raudsepp.
http://hg.python.org/cpython/rev/05a7d3048c49

New changeset 968fba3f34b3 by Ezio Melotti in branch 'default':
#11897: Merge with 3.2.
http://hg.python.org/cpython/rev/968fba3f34b3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11897>
_______________________________________

From report at bugs.python.org  Thu Apr 21 13:54:20 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Apr 2011 11:54:20 +0000
Subject: [issue11897] [PATCH] Documentation: fix typo,
	absolute_import not absolute_imports
In-Reply-To: <1303380560.99.0.860911638141.issue11897@psf.upfronthosting.co.za>
Message-ID: <1303386860.28.0.335927560118.issue11897@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the patch!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11897>
_______________________________________

From report at bugs.python.org  Thu Apr 21 14:29:45 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Apr 2011 12:29:45 +0000
Subject: [issue11885] argparse docs needs fixing
In-Reply-To: <1303300720.91.0.791889164093.issue11885@psf.upfronthosting.co.za>
Message-ID: <E1QCt0u-0005m2-WB@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0f084f150198 by Ezio Melotti in branch '2.7':
#11885: capitalize Python.
http://hg.python.org/cpython/rev/0f084f150198

New changeset fb6affc7b973 by Ezio Melotti in branch '3.2':
#11885: capitalize Python.
http://hg.python.org/cpython/rev/fb6affc7b973

New changeset 9fece8c3a1a9 by Ezio Melotti in branch 'default':
#11885: Merge with 3.2.
http://hg.python.org/cpython/rev/9fece8c3a1a9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11885>
_______________________________________

From report at bugs.python.org  Thu Apr 21 14:30:35 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Apr 2011 12:30:35 +0000
Subject: [issue11885] argparse docs needs fixing
In-Reply-To: <1303300720.91.0.791889164093.issue11885@psf.upfronthosting.co.za>
Message-ID: <1303389035.62.0.164086565741.issue11885@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11885>
_______________________________________

From report at bugs.python.org  Thu Apr 21 15:15:23 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Apr 2011 13:15:23 +0000
Subject: [issue11885] argparse docs needs fixing
In-Reply-To: <1303300720.91.0.791889164093.issue11885@psf.upfronthosting.co.za>
Message-ID: <1303391723.82.0.580909205934.issue11885@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: docs at python -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11885>
_______________________________________

From report at bugs.python.org  Thu Apr 21 15:42:34 2011
From: report at bugs.python.org (Bernhard Rosenkraenzer)
Date: Thu, 21 Apr 2011 13:42:34 +0000
Subject: [issue11898] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1303393354.57.0.483160590848.issue11898@psf.upfronthosting.co.za>
Message-ID: <1303393354.57.0.483160590848.issue11898@psf.upfronthosting.co.za>


New submission from Bernhard Rosenkraenzer <bero at arklinux.org>:

Sending e.g. a JPEG file with a httplib POST request (e.g. through mechanize) can result in an error like this:

  File "/usr/lib64/python2.7/httplib.py", line 947, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib64/python2.7/httplib.py", line 988, in _send_request
    self.endheaders(body)
  File "/usr/lib64/python2.7/httplib.py", line 941, in endheaders
    self._send_output(message_body)
  File "/usr/lib64/python2.7/httplib.py", line 802, in _send_output
    msg += message_body
UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 2566: invalid start byte


The code triggering this is the attempt to merge the msg and message_body into a single request in httplib.py lines 791+

The patch I'm attaching treats an invalid string of unknown encoding (e.g. binary data wrapped as string) like something that isn't a string.

Works for me with the patch.

----------
components: Library (Lib)
files: python-2.7.1-fix-httplib-UnicodeDecodeError.patch
keywords: patch
messages: 134211
nosy: bero
priority: normal
severity: normal
status: open
title: Sending binary data with a POST request in httplib can cause Unicode exceptions
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file21747/python-2.7.1-fix-httplib-UnicodeDecodeError.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11898>
_______________________________________

From report at bugs.python.org  Thu Apr 21 15:44:13 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Apr 2011 13:44:13 +0000
Subject: [issue11898] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1303393354.57.0.483160590848.issue11898@psf.upfronthosting.co.za>
Message-ID: <1303393453.36.0.534469809232.issue11898@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11898>
_______________________________________

From report at bugs.python.org  Thu Apr 21 16:11:30 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 21 Apr 2011 14:11:30 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1303395090.87.0.854813703923.issue1294232@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I think PEP 3115 is OK - the error about all metaclasses inheriting from type was a mistake on my part (I thought the ability to create non-type metaclasses went away along with old-style classes, but I was simply wrong on that point).

That got me curious as to how the explicit inheritance from object + explicit non-type metaclass case was working in 2.7, and it turns out it *does* share the same initial metaclass determination error as 3.x - it is just that build_class() is embedded in ceval.c rather than being published as a builtin.

So I have two conclusions:

- to match existing behaviour when __metaclass__ is not an instance of type(), __build_class__ still needs one special case where it bypasses the normal metaclass calculation: when an explicit metaclass exists and is *not* an instance of type.

- after we get 3.x sorted, we will want to backport this to the ceval version of build_class() in 2.7

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Thu Apr 21 16:20:12 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 21 Apr 2011 14:20:12 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <1303212938.57.0.821096700769.issue11877@psf.upfronthosting.co.za>
Message-ID: <20110421142000.GA20466@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

I'm convinced.  And i've rewritten the patch.
Now fsync(2) is always called first *regardless* of the new
optional argument.  The documentation is (a little bit) better
now.  And i've added support for NetBSD, AIX and Linux; though:

- for AIX i'm testing (O_SYNC && O_DSYNC) which is almost
  definitely the wrong test for this, but (a) i don't know when
  fsync_range() has been introduced (seems to be many years) and
  (b) i've never really worked on AIX.
  (I only have the documentation:
  http://www.filibeto.org/unix/aix/lib/rel/5.3/basetrf1.pdf.)

- i've added sync_file_range() on Linux because of
  SYNC_FILE_RANGE_WAIT_AFTER in the hope that it means something
  even though the manual page says something else - but Linux and
  documentation is something by itself.
  http://lwn.net/Articles/178199/ states

    Providing all three flags guarantees that those pages are
    actually on disk when the call returns.

- it seems OpenBSD, FreeBSD, Solaris 11 and HP/UX provide data
  reliability through fsync(2) alone, see e.g. the notes near EOF
  of the following Solaris 11 file:

    http://www.filibeto.org/sun/lib/solaris11-express-docs/2010.11/E19963_01/html/821-1464/fcntl.h-3head.html#fcntl.h-3head

----------
title: Mac OS X fsync() should really be fcntl(F_FULLFSYNC) -> Change os.fsync() to support physical backing store syncs
Added file: http://bugs.python.org/file21748/11877.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________
-------------- next part --------------
diff --git a/Doc/library/os.rst b/Doc/library/os.rst
--- a/Doc/library/os.rst
+++ b/Doc/library/os.rst
@@ -798,7 +798,7 @@
    Availability: Unix.
 
 
-.. function:: fsync(fd)
+.. function:: fsync(fd, full_fsync=False)
 
    Force write of file with filedescriptor *fd* to disk.  On Unix, this calls the
    native :c:func:`fsync` function; on Windows, the MS :c:func:`_commit` function.
@@ -807,6 +807,14 @@
    ``f.flush()``, and then do ``os.fsync(f.fileno())``, to ensure that all internal
    buffers associated with *f* are written to disk.
 
+   Note that on most operating systems :c:func:`fsync` only ensures that
+   the data is flushed to the disk device, *not* that it has been written
+   by the device itself.  The optional *full_fsync* argument can be used to
+   issue a physical backing store synchronization request on operating
+   systems which do support such an operation, e.g. on NetBSD by calling
+   :c:func:`fsync_range` with the :data:`FDISKSYNC` flag, or on Mac OS X by
+   calling  :c:func:`fcntl` with the :data:`F_FULLFSYNC` command.
+
    Availability: Unix, and Windows.
 
 
diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -13,6 +13,9 @@
 
 /* See also ../Dos/dosmodule.c */
 
+#ifdef __linux__
+# define _GNU_SOURCE
+#endif
 #ifdef __APPLE__
    /*
     * Step 1 of support for weak-linking a number of symbols existing on
@@ -2119,13 +2122,74 @@
 
 #ifdef HAVE_FSYNC
 PyDoc_STRVAR(posix_fsync__doc__,
-"fsync(fildes)\n\n\
-force write of file with filedescriptor to disk.");
-
-static PyObject *
-posix_fsync(PyObject *self, PyObject *fdobj)
-{
-    return posix_fildes(fdobj, fsync);
+"fsync(fildes, full_fsync=False)\n\n"
+"force write of file buffers with fildes to disk;\n"
+"if full_fsync is True it is tried to synchronize physical backing store.");
+
+static PyObject *
+posix_fsync(PyObject *self, PyObject *args, PyObject *kwargs)
+{
+    PyObject *retval;
+    auto PyObject *fdobj;
+    auto int full_fsync = 1;
+    static char *keywords[] = {"fd", "full_fsync", NULL };
+
+    retval = NULL;
+    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "O|i", keywords,
+                                     &fdobj, &full_fsync))
+        goto jleave;
+
+    retval = posix_fildes(fdobj, fsync);
+    if (retval != Py_None)
+        goto jleave;
+
+    /* See issue 11877 discussion (and issue 11277 for OS X sparse file bug) */
+# if (((defined __AIX || defined _AIX) && \
+       defined O_SYNC && defined O_DSYNC) || \
+      (defined __APPLE__ && defined F_FULLFSYNC) || \
+      (defined __NetBSD__ && defined FDISKSYNC) || \
+      (defined __linux__ && defined SYNC_FILE_RANGE_WAIT_AFTER))
+    if (full_fsync != 0) {
+        int res, fd;
+        Py_DECREF(retval);
+
+        retval = NULL;
+        fd = PyObject_AsFileDescriptor(fdobj);
+        if (fd < 0)
+            goto jleave;
+        if (!_PyVerify_fd(fd)) {
+            retval = posix_error();
+            goto jleave;
+        }
+
+        Py_BEGIN_ALLOW_THREADS
+#  if defined __AIX || defined _AIX
+        res = fsync_range(fd, O_SYNC, 0, 0);
+#  endif
+#  ifdef __APPLE__
+        res = fcntl(fd, F_FULLFSYNC);
+#  endif
+#  ifdef __NetBSD__
+        res = fsync_range(fd, FFILESYNC|FDISKSYNC, 0, 0);
+#  endif
+#  ifdef __linux__
+        res = sync_file_range(fd, 0, 0, (SYNC_FILE_RANGE_WAIT_BEFORE |
+                                         SYNC_FILE_RANGE_WRITE |
+                                         SYNC_FILE_RANGE_WAIT_AFTER));
+#  endif
+        Py_END_ALLOW_THREADS
+
+        if (res < 0) {
+            retval = posix_error();
+            goto jleave;
+        }
+        Py_INCREF(Py_None);
+        retval = Py_None;
+    }
+# endif
+
+jleave:
+    return retval;
 }
 #endif /* HAVE_FSYNC */
 
@@ -9484,7 +9548,8 @@
     {"fchdir",          posix_fchdir, METH_O, posix_fchdir__doc__},
 #endif
 #ifdef HAVE_FSYNC
-    {"fsync",       posix_fsync, METH_O, posix_fsync__doc__},
+    {"fsync",           (PyCFunction)posix_fsync, METH_VARARGS|METH_KEYWORDS,
+                        posix_fsync__doc__},
 #endif
 #ifdef HAVE_SYNC
     {"sync",        posix_sync, METH_NOARGS, posix_sync__doc__},

From report at bugs.python.org  Thu Apr 21 16:23:25 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 21 Apr 2011 14:23:25 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <1303212938.57.0.821096700769.issue11877@psf.upfronthosting.co.za>
Message-ID: <1303395805.57.0.0659364101651.issue11877@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file21718/fsync.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Thu Apr 21 16:28:06 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 21 Apr 2011 14:28:06 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <1303212938.57.0.821096700769.issue11877@psf.upfronthosting.co.za>
Message-ID: <1303396086.95.0.126669460759.issue11877@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

P.S.: dito Linux and NetBSD.  I've reused preprocessor tests
      we've discovered internally over the past years, but
      i cannot test this here.
      I could test Linux next Tuesday, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Thu Apr 21 16:42:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Apr 2011 14:42:31 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <1303212938.57.0.821096700769.issue11877@psf.upfronthosting.co.za>
Message-ID: <1303396951.76.0.406950838245.issue11877@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

11877.2.diff: On Mac OS X, fsync(fd, full_sync=True); fsync(fd) do a full sync twice. You should restore the old file flags at fsync() exit. Or this surprising behaviour should be documented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Thu Apr 21 17:01:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Apr 2011 15:01:45 +0000
Subject: [issue11885] argparse docs needs fixing
In-Reply-To: <1303300720.91.0.791889164093.issue11885@psf.upfronthosting.co.za>
Message-ID: <1303398105.46.0.867592577357.issue11885@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>> "When most in optparse had either been copy-pasted over or monkey-patched ..."
> Word "everything" was removed.
The result is grammatically incorrect :)  I?d suggest ?most of argparse?.

> comma was deleted after "that is".
Both versions were grammatically correct, it was a style thing, in which case I would respect the choice of the original author.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11885>
_______________________________________

From report at bugs.python.org  Thu Apr 21 17:02:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Apr 2011 15:02:02 +0000
Subject: [issue11885] argparse docs needs fixing
In-Reply-To: <1303300720.91.0.791889164093.issue11885@psf.upfronthosting.co.za>
Message-ID: <1303398122.47.0.713384830746.issue11885@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

most of optparse*

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11885>
_______________________________________

From report at bugs.python.org  Thu Apr 21 17:08:41 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Apr 2011 15:08:41 +0000
Subject: [issue11584] email.decode_header fails if msg.__getitem__ returns
	Header object
In-Reply-To: <1300362827.23.0.229630674906.issue11584@psf.upfronthosting.co.za>
Message-ID: <1303398521.43.0.306822535872.issue11584@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

My fix (and the tests) for this are wrong.  decode_header returns (binary, charset) pairs, but the chunks list is (string, charset) pairs.

----------
stage: committed/rejected -> needs patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11584>
_______________________________________

From report at bugs.python.org  Thu Apr 21 17:15:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Apr 2011 15:15:25 +0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1303398925.93.0.650776119298.issue1322@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

[Zooko]
> I just read back through this ticket, but I didn't understand exactly
> what MAL wanted to have different from what this Python function
> currently does:

It may be this:

> It's better to follow the approach taken by lsb_release and then
> add calling lsb_release as one of the methods taken by
> _dist_try_harder() (using platform.popen()) should the parsers
> fail.
> This avoids spawning a process in most cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Thu Apr 21 17:16:38 2011
From: report at bugs.python.org (Michael Gold)
Date: Thu, 21 Apr 2011 15:16:38 +0000
Subject: [issue11899] TarFile.gettarinfo modifies self.inodes
In-Reply-To: <1303398997.96.0.910828864.issue11899@psf.upfronthosting.co.za>
Message-ID: <1303398997.96.0.910828864.issue11899@psf.upfronthosting.co.za>


New submission from Michael Gold <mgold at qnx.com>:

When I call tar.gettarinfo (where tar is a TarFile instance), the inode information is inserted into tar.inodes.  If I later call tar.gettarinfo on a linked file, the returned TarInfo will have type LNKTYPE.

I think it's incorrect to store this information in gettarinfo.  It should be done in addfile.

A comment in gettarinfo states "Is it a hardlink to an already archived file?".  But tar.inodes is modified in gettarinfo, and there's no reason to expect that the file will actually be archived, or will be archived with the same properties.  Bad links could result if the returned tarinfo object were modified before calling addfile.

I suggest changing the code as follows:
 - Create a static method (or non-member function) to fill in a given TarInfo object with stat/lstat/fstat results.  This would need a boolean "dereference" parameter.  (No TarFile instance should be required to create a TarInfo.)
 - Have tar.gettarinfo call the above function; then fill in tarinfo.tarfile, and modify tarinfo.type to LNKNAME if applicable.  Don't modify self.inodes.
 - In tar.addfile, call fstat, and store the inode info into self.inodes.

----------
components: Library (Lib)
messages: 134220
nosy: lars.gustaebel, mgold-qnx
priority: normal
severity: normal
status: open
title: TarFile.gettarinfo modifies self.inodes
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11899>
_______________________________________

From report at bugs.python.org  Thu Apr 21 17:19:25 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 21 Apr 2011 15:19:25 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <1303396951.76.0.406950838245.issue11877@psf.upfronthosting.co.za>
Message-ID: <20110421151913.GA66104@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Ok, 11877.3.diff uses either-or.

----------
Added file: http://bugs.python.org/file21749/11877.3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________
-------------- next part --------------
diff --git a/Doc/library/os.rst b/Doc/library/os.rst
--- a/Doc/library/os.rst
+++ b/Doc/library/os.rst
@@ -798,7 +798,7 @@
    Availability: Unix.
 
 
-.. function:: fsync(fd)
+.. function:: fsync(fd, full_fsync=False)
 
    Force write of file with filedescriptor *fd* to disk.  On Unix, this calls the
    native :c:func:`fsync` function; on Windows, the MS :c:func:`_commit` function.
@@ -807,6 +807,14 @@
    ``f.flush()``, and then do ``os.fsync(f.fileno())``, to ensure that all internal
    buffers associated with *f* are written to disk.
 
+   Note that on most operating systems :c:func:`fsync` only ensures that
+   the data is flushed to the disk device, *not* that it has been written
+   by the device itself.  The optional *full_fsync* argument can be used to
+   issue a physical backing store synchronization request on operating
+   systems which do support such an operation, e.g. on NetBSD by calling
+   :c:func:`fsync_range` with the :data:`FDISKSYNC` flag, or on Mac OS X by
+   calling  :c:func:`fcntl` with the :data:`F_FULLFSYNC` command.
+
    Availability: Unix, and Windows.
 
 
diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -13,6 +13,9 @@
 
 /* See also ../Dos/dosmodule.c */
 
+#ifdef __linux__
+# define _GNU_SOURCE
+#endif
 #ifdef __APPLE__
    /*
     * Step 1 of support for weak-linking a number of symbols existing on
@@ -2119,13 +2122,66 @@
 
 #ifdef HAVE_FSYNC
 PyDoc_STRVAR(posix_fsync__doc__,
-"fsync(fildes)\n\n\
-force write of file with filedescriptor to disk.");
-
-static PyObject *
-posix_fsync(PyObject *self, PyObject *fdobj)
-{
-    return posix_fildes(fdobj, fsync);
+"fsync(fildes, full_fsync=False)\n\n"
+"force write of file buffers with fildes to disk;\n"
+"if full_fsync is True it is tried to synchronize physical backing store.");
+
+static PyObject *
+posix_fsync(PyObject *self, PyObject *args, PyObject *kwargs)
+{
+    PyObject *retval = NULL;
+    auto PyObject *fdobj;
+    auto int full_fsync = 1;
+    static char *keywords[] = {"fd", "full_fsync", NULL };
+
+    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "O|i", keywords,
+                                     &fdobj, &full_fsync))
+        goto jleave;
+
+    /* See issue 11877 discussion (and issue 11277 for OS X sparse file bug) */
+# if (((defined __AIX || defined _AIX) && \
+       defined O_SYNC && defined O_DSYNC) || \
+      (defined __APPLE__ && defined F_FULLFSYNC) || \
+      (defined __NetBSD__ && defined FDISKSYNC) || \
+      (defined __linux__ && defined SYNC_FILE_RANGE_WAIT_AFTER))
+    if (full_fsync != 0) {
+        int res, fd = PyObject_AsFileDescriptor(fdobj);
+        if (fd < 0)
+            goto jleave;
+        if (!_PyVerify_fd(fd)) {
+            retval = posix_error();
+            goto jleave;
+        }
+
+        Py_BEGIN_ALLOW_THREADS
+#  if defined __AIX || defined _AIX
+        res = fsync_range(fd, O_SYNC, 0, 0);
+#  endif
+#  ifdef __APPLE__
+        res = fcntl(fd, F_FULLFSYNC);
+#  endif
+#  ifdef __NetBSD__
+        res = fsync_range(fd, FFILESYNC|FDISKSYNC, 0, 0);
+#  endif
+#  ifdef __linux__
+        res = sync_file_range(fd, 0, 0, (SYNC_FILE_RANGE_WAIT_BEFORE |
+                                         SYNC_FILE_RANGE_WRITE |
+                                         SYNC_FILE_RANGE_WAIT_AFTER));
+#  endif
+        Py_END_ALLOW_THREADS
+
+        if (res < 0) {
+            retval = posix_error();
+            goto jleave;
+        }
+        Py_INCREF(Py_None);
+        retval = Py_None;
+    } else
+# endif
+        retval = posix_fildes(fdobj, fsync);
+
+jleave:
+    return retval;
 }
 #endif /* HAVE_FSYNC */
 
@@ -9484,7 +9540,8 @@
     {"fchdir",          posix_fchdir, METH_O, posix_fchdir__doc__},
 #endif
 #ifdef HAVE_FSYNC
-    {"fsync",       posix_fsync, METH_O, posix_fsync__doc__},
+    {"fsync",           (PyCFunction)posix_fsync, METH_VARARGS|METH_KEYWORDS,
+                        posix_fsync__doc__},
 #endif
 #ifdef HAVE_SYNC
     {"sync",        posix_sync, METH_NOARGS, posix_sync__doc__},

From report at bugs.python.org  Thu Apr 21 17:20:11 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 21 Apr 2011 15:20:11 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <1303212938.57.0.821096700769.issue11877@psf.upfronthosting.co.za>
Message-ID: <1303399211.98.0.787672229532.issue11877@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file21742/11877.optarg-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Thu Apr 21 17:20:16 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 21 Apr 2011 15:20:16 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <1303212938.57.0.821096700769.issue11877@psf.upfronthosting.co.za>
Message-ID: <1303399216.6.0.169501221747.issue11877@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file21748/11877.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Thu Apr 21 17:22:48 2011
From: report at bugs.python.org (David Schnur)
Date: Thu, 21 Apr 2011 15:22:48 +0000
Subject: [issue9742] Python 2.7: math module fails to build on Solaris 9
In-Reply-To: <1283438135.42.0.361314007633.issue9742@psf.upfronthosting.co.za>
Message-ID: <1303399368.89.0.343445796387.issue9742@psf.upfronthosting.co.za>


David Schnur <david.schnur at dartware.com> added the comment:

I encountered this problem when updating from 2.6.4 to 2.7.1 on Solaris 8, which also doesn't have 'round'.  I tried srmadsen's --whole-archive option, but it wasn't recognized by the (somewhat ancient) tools on that machine.

I solved the problem by just editing the $(BUILDPYTHON) target to include Python/pymath.o, as Jerzy Kozera did.

Should configure perhaps take care of this when it detects no round?  It seems like this has slipped in simply because very few people still use systems without round.

----------
nosy: +dschnur

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9742>
_______________________________________

From report at bugs.python.org  Thu Apr 21 17:28:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Apr 2011 15:28:49 +0000
Subject: [issue11777] Executor.map does not submit futures until iter.next()
	is called
In-Reply-To: <1302052595.78.0.918161508373.issue11777@psf.upfronthosting.co.za>
Message-ID: <1303399729.68.0.739257273154.issue11777@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Just a bystander remark: when you use present in the commit message and Misc/NEWS entry (like in ?Executor.map does not submit futures until iter.next() is called?), I don?t know whether it is the behavior being fixed (?X used to do Y?) or the new, correct behavior (?X now does Z?).

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11777>
_______________________________________

From report at bugs.python.org  Thu Apr 21 17:45:09 2011
From: report at bugs.python.org (Michael Gold)
Date: Thu, 21 Apr 2011 15:45:09 +0000
Subject: [issue11899] TarFile.gettarinfo modifies self.inodes
In-Reply-To: <1303398997.96.0.910828864.issue11899@psf.upfronthosting.co.za>
Message-ID: <1303400709.32.0.668732189774.issue11899@psf.upfronthosting.co.za>


Michael Gold <mgold at qnx.com> added the comment:

Actually, TarFile should also have a separate method to take a TarInfo instance and modify its type to LNKTYPE if applicable.  gettarinfo can call that.

This way the user can use a TarInfo object created before any files are added, and can easily get this linking behaviour if desired.

(Note: In my initial message, I had LNKNAME where I meant LNKTYPE.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11899>
_______________________________________

From report at bugs.python.org  Thu Apr 21 17:48:22 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 21 Apr 2011 15:48:22 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1303400902.76.0.375031078604.issue1294232@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Thanks for diving deep! How much of this can we claim as a bug and how much as a feature?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Thu Apr 21 18:08:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Apr 2011 16:08:48 +0000
Subject: [issue10932] distutils.core.setup - data_files misbehaviour ?
In-Reply-To: <1295353825.23.0.755300594789.issue10932@psf.upfronthosting.co.za>
Message-ID: <1303402128.74.0.767683819997.issue10932@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch looks good.  Detail: I?d find a call to basename more readable than i.split('/')[-1:][0].

Does this need a test in test_manifest too?  A doc update?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10932>
_______________________________________

From report at bugs.python.org  Thu Apr 21 18:36:47 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 21 Apr 2011 16:36:47 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1303403807.45.0.804676159046.issue1294232@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As near as I can tell, the only visible behavioural change with Daniel's patch (updated as per my last comment) will be that the two error cases noted above (i.e. when an explicit metaclass or the first parent type's metaclass is not the most derived metaclass) will now correctly invoke the real metaclass immediately, instead of first traversing up the chain to type(), which then jumps all the way back down to the most derived metaclass.

The "new" special case is actually just a matter of preserving the current behaviour in the one situation where that is the right thing to do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Thu Apr 21 18:46:52 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 21 Apr 2011 16:46:52 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1303404412.87.0.927317413989.issue1294232@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Commenting on the latest patch here, since the Rietveld integration isn't coping with the "hg extdiff" output (I would guess that the revision numbers in the pathnames are confusing the script that attempts to determine the base revision).

Aside from the note above about needing to restore the special case handling for non-type metaclasses, the only other recommendation I have is for the new metaclass invocation tests to add a second metaclass to the hierarchy and explicitly check the order of the __new__ calls, as in the original examples above that invoked the wrong M_A/M_B/M_A sequence. Those tests will then also be applicable to Python 2.7 (which doesn't have __prepare___).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Thu Apr 21 19:20:42 2011
From: report at bugs.python.org (=?utf-8?q?Pawe=C5=82_Widera?=)
Date: Thu, 21 Apr 2011 17:20:42 +0000
Subject: [issue6191] HTMLParser attribute parsing - 2 test cases when it fails
In-Reply-To: <1244101614.1.0.195769853623.issue6191@psf.upfronthosting.co.za>
Message-ID: <1303406442.47.0.203705572025.issue6191@psf.upfronthosting.co.za>


Pawe? Widera <momat at man.poznan.pl> added the comment:

No. As the value of the href attribute is not suppose to contain spaces, I'd rather expect the parser to assume that there is an ending " missing before the space.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6191>
_______________________________________

From report at bugs.python.org  Thu Apr 21 19:29:56 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 21 Apr 2011 17:29:56 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <1303212938.57.0.821096700769.issue11877@psf.upfronthosting.co.za>
Message-ID: <1303406996.91.0.319838875708.issue11877@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Thu Apr 21 19:37:57 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 21 Apr 2011 17:37:57 +0000
Subject: [issue11898] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1303393354.57.0.483160590848.issue11898@psf.upfronthosting.co.za>
Message-ID: <1303407477.02.0.594104532166.issue11898@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11898>
_______________________________________

From report at bugs.python.org  Thu Apr 21 19:51:51 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Thu, 21 Apr 2011 17:51:51 +0000
Subject: [issue11382] some posix module functions unnecessarily release the GIL
In-Reply-To: <1299147333.52.0.465056224972.issue11382@psf.upfronthosting.co.za>
Message-ID: <1303408311.31.0.701171798642.issue11382@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Is there anything I can do to help this move forward ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11382>
_______________________________________

From report at bugs.python.org  Thu Apr 21 20:14:28 2011
From: report at bugs.python.org (Dave Opstad)
Date: Thu, 21 Apr 2011 18:14:28 +0000
Subject: [issue11900] 2.7.1 unicode subclasses not calling __str__() for print
	statement
In-Reply-To: <1303409668.43.0.708975922523.issue11900@psf.upfronthosting.co.za>
Message-ID: <1303409668.43.0.708975922523.issue11900@psf.upfronthosting.co.za>


New submission from Dave Opstad <dave.opstad at monotypeimaging.com>:

Python 2.7.1 doesn't appear to do the usual implicit call to str() for subclasses of unicode. In the following snippet, I would have expected print myTest and print str(myTest) to behave the same:

>>> class Test(unicode):
...   def __str__(self):
...     print "In __str__"
...     return (u"*** " + self + u" ***").encode('utf-8')
...   def __unicode__(self):
...     print "In __unicode__"
...     return u"*** " + self + u" ***"
... 
>>> myTest = Test(u"abc")
>>> print myTest
abc
>>> print str(myTest)
In __str__
*** abc ***
>>> print unicode(myTest)
In __unicode__
*** abc ***

----------
components: Unicode
messages: 134231
nosy: opstad
priority: normal
severity: normal
status: open
title: 2.7.1 unicode subclasses not calling __str__() for print statement
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11900>
_______________________________________

From report at bugs.python.org  Thu Apr 21 20:24:23 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Apr 2011 18:24:23 +0000
Subject: [issue11901] Docs for sys.hexversion should give the algorithm
In-Reply-To: <1303410263.92.0.721904855375.issue11901@psf.upfronthosting.co.za>
Message-ID: <1303410263.92.0.721904855375.issue11901@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

I went to write a test that would trigger something if it was run on 3.3.0, and had to look in the source code to figure out what the hexversion for that would be.  I think the hexversion algorithm should be documented in its sys entry.

----------
assignee: docs at python
components: Documentation
messages: 134232
nosy: docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Docs for sys.hexversion should give the algorithm
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11901>
_______________________________________

From report at bugs.python.org  Thu Apr 21 20:28:25 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Apr 2011 18:28:25 +0000
Subject: [issue11900] 2.7.1 unicode subclasses not calling __str__() for print
	statement
In-Reply-To: <1303409668.43.0.708975922523.issue11900@psf.upfronthosting.co.za>
Message-ID: <1303410505.35.0.00671053001486.issue11900@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You subclassed unicode.  So print printed the value of your unicode object, which didn't need coercion.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11900>
_______________________________________

From report at bugs.python.org  Thu Apr 21 20:33:57 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Thu, 21 Apr 2011 18:33:57 +0000
Subject: [issue11885] argparse docs needs fixing
In-Reply-To: <1303398122.47.0.713384830746.issue11885@psf.upfronthosting.co.za>
Message-ID: <BANLkTimu7gR1rOatnxk_FCu9HSctUdC5uw@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Eric, you are great! Thanks for fixing the docs. ;)

----------
Added file: http://bugs.python.org/file21750/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11885>
_______________________________________
-------------- next part --------------
Eric, you are great! Thanks for fixing the docs. ;)

From report at bugs.python.org  Thu Apr 21 20:37:36 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Apr 2011 18:37:36 +0000
Subject: [issue11900] 2.7.1 unicode subclasses not calling __str__() for print
	statement
In-Reply-To: <1303409668.43.0.708975922523.issue11900@psf.upfronthosting.co.za>
Message-ID: <1303411056.5.0.294570949275.issue11900@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

For the record, this isn't as simple as I made it sound.  See, for example, issue 9196.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11900>
_______________________________________

From report at bugs.python.org  Thu Apr 21 20:53:07 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Thu, 21 Apr 2011 18:53:07 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <1303212938.57.0.821096700769.issue11877@psf.upfronthosting.co.za>
Message-ID: <1303411987.24.0.672069847024.issue11877@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

I'm -10 on sync_file_range on Linux:
- it doesn't update the file metadata, so there's a high chance of corruption after a crash
- last time I checked, it didn't flush the disk cache (well, it probably does if barriers are enabled, but that's also the case with fsync)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Thu Apr 21 21:15:50 2011
From: report at bugs.python.org (Vladimir Rutsky)
Date: Thu, 21 Apr 2011 19:15:50 +0000
Subject: [issue11902] typo in argparse doc's: "action.."
In-Reply-To: <1303413350.17.0.602462261272.issue11902@psf.upfronthosting.co.za>
Message-ID: <1303413350.17.0.602462261272.issue11902@psf.upfronthosting.co.za>


New submission from Vladimir Rutsky <altsysrq at gmail.com>:

There is a typo in argparse module documentation:
"The ``nargs`` keyword argument associates a different number of command-line arguments with a single action.." (two dots at end).

Patch based on official http://svn.python.org/projects/python/branches/py3k/ repository, but typo is also noted in Python 2.7 documentation.

----------
assignee: docs at python
components: Documentation
files: argparse_typo_action_dot_dot.patch
keywords: patch
messages: 134237
nosy: docs at python, rutsky
priority: normal
severity: normal
status: open
title: typo in argparse doc's: "action.."
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file21751/argparse_typo_action_dot_dot.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11902>
_______________________________________

From report at bugs.python.org  Thu Apr 21 21:22:53 2011
From: report at bugs.python.org (Dave Opstad)
Date: Thu, 21 Apr 2011 19:22:53 +0000
Subject: [issue11900] 2.7.1 unicode subclasses not calling __str__() for print
	statement
In-Reply-To: <1303409668.43.0.708975922523.issue11900@psf.upfronthosting.co.za>
Message-ID: <1303413773.93.0.253346402266.issue11900@psf.upfronthosting.co.za>


Dave Opstad <dave.opstad at monotypeimaging.com> added the comment:

I guess I was confused by the inconsistency with Python 3, which *does* call the __str__ method, even though, again, no coercion is needed:

Python 3.2 (r32:88452, Feb 20 2011, 10:19:59) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class X(str):
...   def __str__(self):
...     print("In __str__")
...     return "*** " + self + " ***"
... 
>>> x = X("abcde")
>>> print(x)
In __str__
*** abcde ***
>>> print(str(x))
In __str__
*** abcde ***

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11900>
_______________________________________

From report at bugs.python.org  Thu Apr 21 21:24:11 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 21 Apr 2011 19:24:11 +0000
Subject: [issue11903] Incorrect test code in test_logging.py
In-Reply-To: <1303413851.9.0.62222052132.issue11903@psf.upfronthosting.co.za>
Message-ID: <1303413851.9.0.62222052132.issue11903@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

In test file test_logging.py, around line 2359, list.append() is called with two arguments instead of one. I suppose it is meant to be called with a tuple.

class ModuleLevelMiscTest(BaseTest):
    [...]
    def _test_log(self, method, level=None):
        called = []
        patch(self, logging, 'basicConfig',
              lambda *a, **kw: called.append(a, kw))  # <====

----------
components: Tests
messages: 134239
nosy: scoder
priority: normal
severity: normal
status: open
title: Incorrect test code in test_logging.py
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11903>
_______________________________________

From report at bugs.python.org  Thu Apr 21 21:50:13 2011
From: report at bugs.python.org (Vladimir Rutsky)
Date: Thu, 21 Apr 2011 19:50:13 +0000
Subject: [issue11904] incorrect reStructuredText formatting in argparse module
In-Reply-To: <1303415412.97.0.882157170829.issue11904@psf.upfronthosting.co.za>
Message-ID: <1303415412.97.0.882157170829.issue11904@psf.upfronthosting.co.za>


New submission from Vladimir Rutsky <altsysrq at gmail.com>:

In Python 2.7 and 3 branch at http://svn.python.org/projects/python/branches/py3k/ file Doc/library/argparse.rst has incorrectly formatted list at line 648:

> * ``'store'`` - This just stores the argument's value.  This is the default
>    action. For example::

Second line must be indented according to first line.

Next item at line 656 has invalid indentation too.

----------
assignee: docs at python
components: Documentation
messages: 134240
nosy: docs at python, rutsky
priority: normal
severity: normal
status: open
title: incorrect reStructuredText formatting in argparse module
versions: Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11904>
_______________________________________

From report at bugs.python.org  Thu Apr 21 21:57:18 2011
From: report at bugs.python.org (Vladimir Rutsky)
Date: Thu, 21 Apr 2011 19:57:18 +0000
Subject: [issue11905] typo in argparse doc's: missing dot at end of sentence
In-Reply-To: <1303415838.79.0.720051714713.issue11905@psf.upfronthosting.co.za>
Message-ID: <1303415838.79.0.720051714713.issue11905@psf.upfronthosting.co.za>


New submission from Vladimir Rutsky <altsysrq at gmail.com>:

There is missed dot at end of sentence in argparse module documentation. Please see attached patch for details.

Patch based on official http://svn.python.org/projects/python/branches/py3k/ repository, but typo is also noted in Python 2.7 documentation.

----------
assignee: docs at python
components: Documentation
files: argparse_typo_missing_dot.patch
keywords: patch
messages: 134241
nosy: docs at python, rutsky
priority: normal
severity: normal
status: open
title: typo in argparse doc's: missing dot at end of sentence
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file21752/argparse_typo_missing_dot.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11905>
_______________________________________

From report at bugs.python.org  Thu Apr 21 21:59:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Apr 2011 19:59:28 +0000
Subject: [issue11902] typo in argparse doc's: "action.."
In-Reply-To: <1303413350.17.0.602462261272.issue11902@psf.upfronthosting.co.za>
Message-ID: <E1QD024-0001a5-C1@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset e8464256b4d7 by Ezio Melotti in branch '2.7':
#11902: Fix typo in argparse doc. Noticed by Vladimir Rutsky.
http://hg.python.org/cpython/rev/e8464256b4d7

New changeset 88df1ef4eec8 by Ezio Melotti in branch '3.2':
#11902: Fix typo in argparse doc. Noticed by Vladimir Rutsky.
http://hg.python.org/cpython/rev/88df1ef4eec8

New changeset 56825d54dc84 by Ezio Melotti in branch 'default':
#11902: Merge with 3.2.
http://hg.python.org/cpython/rev/56825d54dc84

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11902>
_______________________________________

From report at bugs.python.org  Thu Apr 21 22:00:17 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 21 Apr 2011 20:00:17 +0000
Subject: [issue11903] Incorrect test code in test_logging.py
In-Reply-To: <1303413851.9.0.62222052132.issue11903@psf.upfronthosting.co.za>
Message-ID: <1303416017.9.0.108547637676.issue11903@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

Introduced in changeset c7f7672b70a9.

----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11903>
_______________________________________

From report at bugs.python.org  Thu Apr 21 22:02:35 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Apr 2011 20:02:35 +0000
Subject: [issue11902] typo in argparse doc's: "action.."
In-Reply-To: <1303413350.17.0.602462261272.issue11902@psf.upfronthosting.co.za>
Message-ID: <1303416155.51.0.937060422874.issue11902@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report.

BTW we are using HG now (http://hg.python.org/cpython) and patches should be submitted against the oldest applicable branch (either 2.7 or 3.2 is fine in this case).
More info at http://docs.python.org/devguide/.

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2, Python 3.3 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11902>
_______________________________________

From report at bugs.python.org  Thu Apr 21 22:07:28 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Apr 2011 20:07:28 +0000
Subject: [issue11584] email.decode_header fails if msg.__getitem__ returns
	Header object
In-Reply-To: <1300362827.23.0.229630674906.issue11584@psf.upfronthosting.co.za>
Message-ID: <1303416448.08.0.166969469408.issue11584@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Note that when this is fixed, make_header on the return value from decode_header will fail because it doesn't know now to handle unknown-8bit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11584>
_______________________________________

From report at bugs.python.org  Thu Apr 21 22:10:23 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 21 Apr 2011 20:10:23 +0000
Subject: [issue11903] Incorrect test code in test_logging.py
In-Reply-To: <1303413851.9.0.62222052132.issue11903@psf.upfronthosting.co.za>
Message-ID: <1303416623.05.0.897521064907.issue11903@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

Simple fix.

----------
keywords: +patch
Added file: http://bugs.python.org/file21753/issue11903_py33.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11903>
_______________________________________

From report at bugs.python.org  Thu Apr 21 22:13:35 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Apr 2011 20:13:35 +0000
Subject: [issue11905] typo in argparse doc's: missing dot at end of sentence
In-Reply-To: <1303415838.79.0.720051714713.issue11905@psf.upfronthosting.co.za>
Message-ID: <E1QD0Fp-0002mL-3w@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f6ea7abc4eb2 by Ezio Melotti in branch '2.7':
#11905: fix missing full stop in argparse doc. Noticed by Vladimir Rutsky.
http://hg.python.org/cpython/rev/f6ea7abc4eb2

New changeset 15f482996880 by Ezio Melotti in branch '3.2':
#11905: fix missing full stop in argparse doc. Noticed by Vladimir Rutsky.
http://hg.python.org/cpython/rev/15f482996880

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11905>
_______________________________________

From report at bugs.python.org  Thu Apr 21 22:13:35 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Apr 2011 20:13:35 +0000
Subject: [issue11904] incorrect reStructuredText formatting in argparse module
In-Reply-To: <1303415412.97.0.882157170829.issue11904@psf.upfronthosting.co.za>
Message-ID: <E1QD0Fp-0002mL-3o@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 79f3ae389dae by Ezio Melotti in branch '2.7':
#11904: fix indentation in argparse doc. Noticed by Vladimir Rutsky.
http://hg.python.org/cpython/rev/79f3ae389dae

New changeset 473fada5f1b7 by Ezio Melotti in branch '3.2':
#11904: fix indentation in argparse doc. Noticed by Vladimir Rutsky.
http://hg.python.org/cpython/rev/473fada5f1b7

New changeset 8568762381b4 by Ezio Melotti in branch 'default':
#11904-#11905: Merge typo fixes with 3.2.
http://hg.python.org/cpython/rev/8568762381b4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11904>
_______________________________________

From report at bugs.python.org  Thu Apr 21 22:15:10 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Apr 2011 20:15:10 +0000
Subject: [issue11905] typo in argparse doc's: missing dot at end of sentence
In-Reply-To: <1303415838.79.0.720051714713.issue11905@psf.upfronthosting.co.za>
Message-ID: <1303416910.01.0.0477373508671.issue11905@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2, Python 3.3 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11905>
_______________________________________

From report at bugs.python.org  Thu Apr 21 22:16:06 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Apr 2011 20:16:06 +0000
Subject: [issue11904] incorrect reStructuredText formatting in argparse module
In-Reply-To: <1303415412.97.0.882157170829.issue11904@psf.upfronthosting.co.za>
Message-ID: <1303416966.54.0.788181167724.issue11904@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2, Python 3.3 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11904>
_______________________________________

From report at bugs.python.org  Thu Apr 21 22:22:23 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Apr 2011 20:22:23 +0000
Subject: [issue11900] 2.7.1 unicode subclasses not calling __str__() for print
	statement
In-Reply-To: <1303409668.43.0.708975922523.issue11900@psf.upfronthosting.co.za>
Message-ID: <1303417343.51.0.0850279783927.issue11900@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, it's possible I'm wrong and you've found a bug.  There are numerous differences between 2 and 3 in both string handling and special method handling, though, so it may be hard to pin down.  If you poke around a bit more and still think it is a bug, please reopen.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11900>
_______________________________________

From report at bugs.python.org  Thu Apr 21 22:27:08 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 21 Apr 2011 20:27:08 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <1303411987.24.0.672069847024.issue11877@psf.upfronthosting.co.za>
Message-ID: <20110421202659.GA82546@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Charles-Francois Natali wrote:
> I'm -10 on sync_file_range on Linux:
> [...] last time I checked [...]

I just looked at
    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=fs/sync.c;h=c38ec163da6ccba00a0146c75606c1b548b31343;hb=HEAD
and it seems - as far as i understand what i read - that you're
still right; and, furthermore, that fsync() does everything
anyway.  (But here an idiot is talking about *very* complicated
stuff.)

I've also "search"ed for the called filemap_write_and_wait_range()
and found the commit message for
2daea67e966dc0c42067ebea015ddac6834cef88 as part of that;
very interesting in respect to our issue here.

I will wait before i update the patch though, just in case some
experienced NetBSD or AIX user posts some message.  For OpenBSD
i think i can confirm that fsync(2) alone is enough after taking
a (shallow, all shallow) look into kernel/vfs_syscalls.c and
ufs/ffs/{ffs_softdep.c,softdep.h}.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Thu Apr 21 23:24:19 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Thu, 21 Apr 2011 21:24:19 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <20110421202659.GA82546@sherwood.local>
Message-ID: <BANLkTin_c2hfwV0Vn+BNGA_2yf=byX-=oQ@mail.gmail.com>


Charles-Francois Natali <neologix at free.fr> added the comment:

> and it seems - as far as i understand what i read - that you're
> still right; and, furthermore, that fsync() does everything
> anyway. ?(But here an idiot is talking about *very* complicated
> stuff.)
>

I just double-checked, and indeed, fsync does flush the disk cache
when barriers are enabled on several FS, while sync_file_range does
not. So sync_file_range should definitely not be used on Linux.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Fri Apr 22 00:00:37 2011
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 21 Apr 2011 22:00:37 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1303423237.86.0.90711424699.issue1294232@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

I'm attaching the updated patch.  Changes:
- Special casing objects we can't do the metaclass computation for.
- Tests for these.
- Adding tests for the order of __new__ calls.

The special case isn't just checking if the object is a class, but instead checking if "isinstance(obj, type) and issubclass(obj, type)", because I think only these are the objects we can do the metaclass calculation for.  All other objects (including classes which are not "real" metaclasses (they do not derive from type) and functions) are used "as is", without any metaclass calculation.  (It's late here, so it is quite possible that I've overlooked someting in this part.)

(I'm using "hg extdiff" because the normal hg diff results in a longer and harder to read patch, but if it's needed I will send a normal diff.)

----------
Added file: http://bugs.python.org/file21754/issue_1294232_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Fri Apr 22 00:02:41 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 21 Apr 2011 22:02:41 +0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1303398925.93.0.650776119298.issue1322@psf.upfronthosting.co.za>
Message-ID: <4DB0A97B.3020400@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

?ric Araujo wrote:
> 
> ?ric Araujo <merwok at netwok.org> added the comment:
> 
> [Zooko]
>> I just read back through this ticket, but I didn't understand exactly
>> what MAL wanted to have different from what this Python function
>> currently does:
> 
> It may be this:
> 
>> It's better to follow the approach taken by lsb_release and then
>> add calling lsb_release as one of the methods taken by
>> _dist_try_harder() (using platform.popen()) should the parsers
>> fail.
>> This avoids spawning a process in most cases.

Indeed.

You also need to make sure that the function doesn't suddenly
return different output for setups that are supported and work
as advertised.

Note that the Debian mention in the string output is not really
incorrect, given that Ubuntu and other distros are based on the
work done by the Debian project.

Looking back, I shouldn't have added the function to begin
with and just use "Linux" in the platform string. It's causing
too much maintenance overhead.
Perhaps deprecating it altogether is more appropriate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Fri Apr 22 00:35:35 2011
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 21 Apr 2011 22:35:35 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1303425335.3.0.887930178781.issue1294232@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

I've just realized, that my patch still breaks a case, that previously worked: when the bases are not classes.

This works in 3.2, but not with my patch:

>>> class Foo:  # not a subclass of type!
...     def __new__(mcls, name='foo', bases=(), namespace={}):
...             self = super().__new__(mcls)
...             self.name = name
...             return self
... 
>>> foo1 = Foo('foo1')
>>> foo1.name
'foo1'
>>> 
>>> foo2 = Foo('foo2')
>>> foo2.name
'foo2'
>>> 
>>> class foo3(foo1, foo2):pass
... 
>>> foo3
<__main__.Foo object at 0xb74aa96c>
>>> foo3.name
'foo3'

This raises a TypeError: "metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases".  In this case the *type* of all of its bases is the same (Foo), but that type is not a metaclass, but a regular class.

Right now I don't know if this is a real problem, or how to solve it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Fri Apr 22 01:20:16 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 21 Apr 2011 23:20:16 +0000
Subject: [issue11903] Incorrect test code in test_logging.py
In-Reply-To: <1303413851.9.0.62222052132.issue11903@psf.upfronthosting.co.za>
Message-ID: <1303428016.5.0.600463428622.issue11903@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Checked in, see changeset fecf9e6d7630 - thanks.

----------
assignee:  -> vinay.sajip
nosy: +vinay.sajip
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11903>
_______________________________________

From report at bugs.python.org  Fri Apr 22 02:21:16 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 22 Apr 2011 00:21:16 +0000
Subject: [issue9196] Improve docs for string interpolation "%s" re Unicode
	strings
In-Reply-To: <1278572830.17.0.148747735024.issue9196@psf.upfronthosting.co.za>
Message-ID: <1303431676.72.0.567725422804.issue9196@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/issue9196>
_______________________________________

From report at bugs.python.org  Fri Apr 22 04:12:15 2011
From: report at bugs.python.org (Anthony Long)
Date: Fri, 22 Apr 2011 02:12:15 +0000
Subject: [issue11846] Remove non-guaranteed implementation details from docs.
In-Reply-To: <1302815567.28.0.789640613127.issue11846@psf.upfronthosting.co.za>
Message-ID: <1303438335.73.0.0301550045814.issue11846@psf.upfronthosting.co.za>


Anthony Long <antlong at gmail.com> added the comment:

I'll have a doc patch shortly.

Also, I am working on defining a solid range. Memory is not an issue like it was back in 1991 when this range was originally implemented, so we can go higher and get a bigger performance boost. This will be very important (to some, admittedly) in Python 3, where there is no distinction between PyInts and PyLongs (more processing req'd), which could benefit from further optimization of the range.

Going to be doing benchmarking, -256 to 256 seems like a good place to start. If anyone has app's i should benchmark with in mind, feel free to let me know.

----------
resolution:  -> accepted
title: Implementation question for (-5) - 256 caching, and doc update for c-api/int.html -> Remove non-guaranteed implementation details from docs.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11846>
_______________________________________

From report at bugs.python.org  Fri Apr 22 05:26:11 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Apr 2011 03:26:11 +0000
Subject: [issue11906] Test_argparse failure but only in interactive mode
In-Reply-To: <1303442771.01.0.0867760921949.issue11906@psf.upfronthosting.co.za>
Message-ID: <1303442771.01.0.0867760921949.issue11906@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

(3.1 not checked because it seems not to have test_argparse)
Python 2.7 or 3.2, WinXP these pass:
C:\Programs\Python27>python -m test.regrtest test_argparse
C:\Programs\Python32>python -m test test_argparse
[1/1] test_argparse
1 test OK.

C:\Programs\Python32>python -m test -v test_argparse
C:\Programs\Python32>python -c "from test import test_argparse as t; t.test_main()"
Ran 1536 tests in 6.188s
OK

but interactively (command window interpreter or IDLE shell, 3.2 or 2.7)
>>> from test import test_argparse as t; t.test_main()

gives two failures related to extra spaces in usage string (I added a couple of newlines for clarity). I have no idea if problem is with argparse, test_argparse, regrtest, unittest, or interactive versus batch mode.

======================================================================
FAIL: test_groups_parents (test.test_argparse.TestParentParsers)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Programs\Python32\lib\test\test_argparse.py", line 2217, in test_groups_parents
    '''.format(self.main_program)))
  File "C:\Programs\Python32\lib\test\test_argparse.py", line 29, in assertEqual
    super(TestCase, self).assertEqual(obj1, obj2)
AssertionError:
'usage: [-h] [-w W] [-x X] [-y Y | -z Z]\n\noptional arguments:\n  -h, --help  s [truncated]... != 
'usage:  [-h] [-w W] [-x X] [-y Y | -z Z]\n\noptional arguments:\n  -h, --help   [truncated]...
- usage: [-h] [-w W] [-x X] [-y Y | -z Z]
+ usage:  [-h] [-w W] [-x X] [-y Y | -z Z]
?        +
  
  optional arguments:
    -h, --help  show this help message and exit
    -y Y
    -z Z
  
  g:
    gd
  
    -w W
    -x X


======================================================================
FAIL: test_parent_help (test.test_argparse.TestParentParsers)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Programs\Python32\lib\test\test_argparse.py", line 2188, in test_parent_help
    '''.format(self.main_program)))
  File "C:\Programs\Python32\lib\test\test_argparse.py", line 29, in assertEqual
    super(TestCase, self).assertEqual(obj1, obj2)
AssertionError:
'usage: [-h] [-b B] [--d D] [--w W] [-y Y] a z\n\npositional arguments:\n  a\n   [truncated]... != 
'usage:  [-h] [-b B] [--d D] [--w W] [-y Y] a z\n\npositional arguments:\n  a\n  [truncated]...
- usage: [-h] [-b B] [--d D] [--w W] [-y Y] a z
+ usage:  [-h] [-b B] [--d D] [--w W] [-y Y] a z
?        +
  
  positional arguments:
    a
    z
  
  optional arguments:
    -h, --help  show this help message and exit
    -b B
    --w W
  
  c:
    --d D
  
  x:
    -y Y


----------------------------------------------------------------------
Ran 1536 tests in 29.438s

FAILED (failures=2)
Traceback (most recent call last):
  File "<pyshell#11>", line 1, in <module>
    from test import test_argparse as t; t.test_main()
  File "C:\Programs\Python32\lib\test\test_argparse.py", line 4423, in test_main
    support.run_unittest(__name__)
  File "C:\Programs\Python32\lib\test\support.py", line 1145, in run_unittest
    _run_suite(suite)
  File "C:\Programs\Python32\lib\test\support.py", line 1128, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: multiple errors occurred

----------
components: Library (Lib)
messages: 134259
nosy: bethard, terry.reedy
priority: normal
severity: normal
status: open
title: Test_argparse failure but only in interactive mode
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11906>
_______________________________________

From report at bugs.python.org  Fri Apr 22 06:14:31 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 22 Apr 2011 04:14:31 +0000
Subject: [issue9228] Make changes in the PATH and PATHEXT on installation
In-Reply-To: <1278892287.6.0.671523214632.issue9228@psf.upfronthosting.co.za>
Message-ID: <1303445671.17.0.453637664383.issue9228@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

That's not correct - we've merely pointed out that it isn't as easy as most people seem to think.

For the POSIX world, there is a version management scheme based on symlinks in /usr/bin (or /usr/local/bin) and it is easy to add and remove entries independently.

PATH on windows, on the other hand, is a size limited string that can easily exceed the bounds on development machines due to the absurdly long installation paths used by many Windows development tools (with Visual Studio itself being one of the worst offenders).

PEP 397 goes into some detail as to how the (lack of) version management is an issue for the automatically created file associations, and similar problems exist for the command line equivalents.

Batch files that launch development environments with changes to set PATH/PATHEXT/INCLUDES/LIBS etc correctly are not an uncommon sight in Windows development, so including the correct Python directory just becomes one more line in the launch scripts.

Non-command line users simply rely on the existing start menu shortcuts and the file associations to launch double-clicked files.

That limits the beneficiaries of this change to people that:
1. Want to use the command line; and
2. Do not already have a custom "Development Environment" command line launch script.

Fixing this is NOT trivial, and, to my knowledge, we have never been offered a patch that implements it.

----------
nosy: +ncoghlan
resolution: rejected -> 
stage: committed/rejected -> 
status: pending -> open
title: Make changes in the path and pathext on installation -> Make changes in the PATH and PATHEXT on installation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9228>
_______________________________________

From report at bugs.python.org  Fri Apr 22 06:34:48 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 22 Apr 2011 04:34:48 +0000
Subject: [issue11846] Remove non-guaranteed implementation details from docs.
In-Reply-To: <1302815567.28.0.789640613127.issue11846@psf.upfronthosting.co.za>
Message-ID: <1303446888.83.0.407621832606.issue11846@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Memory is not an issue like it was back in 1991 when 
> this range was originally implemented, so we can go 
> higher and get a bigger performance boost.

Please don't do this.  Memory is still important to a lot of people.  Also, there is *very* little payoff for numbers outside the -5 to 256 range.

If we're to spend memory, we can do it in other places (like bigger freelists or somesuch).

> We should remove the documentation entries that discuss 
> non-guaranteed implementation details

FWIW, I've changed my thinking on this.  With documentation, these details are very difficult to find-out about.  Instead of removing them, they should be marked as non-guaranteed implementation specific details or they can be moved to a separate section.

----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11846>
_______________________________________

From report at bugs.python.org  Fri Apr 22 06:39:07 2011
From: report at bugs.python.org (Anthony Long)
Date: Fri, 22 Apr 2011 04:39:07 +0000
Subject: [issue11846] Remove non-guaranteed implementation details from docs.
In-Reply-To: <1302815567.28.0.789640613127.issue11846@psf.upfronthosting.co.za>
Message-ID: <1303447147.12.0.0331841565889.issue11846@psf.upfronthosting.co.za>


Anthony Long <antlong at gmail.com> added the comment:

My plan is to document it, as it exists, in the current implementation. That's a start atleast, and will provide an entry point for further documentation in the future should it be changed again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11846>
_______________________________________

From report at bugs.python.org  Fri Apr 22 07:41:26 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 22 Apr 2011 05:41:26 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1303450886.25.0.131529016318.issue1294232@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

Okay, probably the check in my previous patch was too strict (sorry for the noise).  I'm attaching an updated patch again.  Now the algorithm in __build_class__ is this:

1. If an object is explicitly given with the metaclass keyword, that is the "starting metaclass".
2. Else if there are bases, the type of the first base is the starting metaclass (note, that this possibly will be replaced later, but before the __prepare__ call).
3. Else the starting metaclass is type.

4. If the starting metaclass is a class, do the metaclass calculation, so the starting metaclass may be replaced with its most derived descendant.
5. Else we cannot do the metaclass calculation, so use the starting metaclass as is.

There are also tests for these cases, and the example in msg134256 now works too.

----------
Added file: http://bugs.python.org/file21755/issue11256_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Fri Apr 22 07:42:57 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 22 Apr 2011 05:42:57 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1303450977.79.0.968536475028.issue1294232@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


Removed file: http://bugs.python.org/file21755/issue11256_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Fri Apr 22 07:43:21 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 22 Apr 2011 05:43:21 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1303451001.92.0.443708991445.issue1294232@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


Added file: http://bugs.python.org/file21756/issue_1294232_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Fri Apr 22 10:12:20 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Fri, 22 Apr 2011 08:12:20 +0000
Subject: [issue11899] TarFile.gettarinfo modifies self.inodes
In-Reply-To: <1303398997.96.0.910828864.issue11899@psf.upfronthosting.co.za>
Message-ID: <1303459940.28.0.960817252008.issue11899@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Good point. Do you happen to have a working implementation already?

----------
assignee:  -> lars.gustaebel
priority: normal -> low
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11899>
_______________________________________

From report at bugs.python.org  Fri Apr 22 13:09:57 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Fri, 22 Apr 2011 11:09:57 +0000
Subject: [issue11879] TarFile.chown: should use TarInfo.uid if user lookup
	fails
In-Reply-To: <1303229015.7.0.433519463198.issue11879@psf.upfronthosting.co.za>
Message-ID: <1303470597.48.0.328459000072.issue11879@psf.upfronthosting.co.za>


Changes by Lars Gust?bel <lars at gustaebel.de>:


----------
assignee:  -> lars.gustaebel
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11879>
_______________________________________

From report at bugs.python.org  Fri Apr 22 15:41:03 2011
From: report at bugs.python.org (Jonathan Hartley)
Date: Fri, 22 Apr 2011 13:41:03 +0000
Subject: [issue9228] Make changes in the PATH and PATHEXT on installation
In-Reply-To: <1278892287.6.0.671523214632.issue9228@psf.upfronthosting.co.za>
Message-ID: <1303479663.24.0.160977919081.issue9228@psf.upfronthosting.co.za>


Changes by Jonathan Hartley <tartley at tartley.com>:


----------
nosy: +jonathan.hartley

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9228>
_______________________________________

From report at bugs.python.org  Fri Apr 22 15:52:18 2011
From: report at bugs.python.org (=?utf-8?b?THVrw6HFoSBMYWxpbnNrw70=?=)
Date: Fri, 22 Apr 2011 13:52:18 +0000
Subject: [issue11907] SysLogHandler can't send long messages
In-Reply-To: <1303480338.6.0.255798757577.issue11907@psf.upfronthosting.co.za>
Message-ID: <1303480338.6.0.255798757577.issue11907@psf.upfronthosting.co.za>


New submission from Luk?? Lalinsk? <lalinsky at gmail.com>:

It seems that logging.handlers.SysLogHandler can't handle messages that can't be passed atomically via the socket. I'm not sure what is the right behavior (the syslog() function truncates the message), but I think it shouldn't propagate the exception to the application.

Python 2.7.1 (r271:86832, Apr 18 2011, 08:47:29) 
[GCC 4.2.1 20070719  [FreeBSD]] on freebsd8
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging.handlers
>>> handler = logging.handlers.SysLogHandler('/dev/log')
>>> logger = logging.getLogger()
>>> logger.addHandler(handler)
>>> logger.warn('x' * 4096)
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/logging/handlers.py", line 808, in emit
    self.socket.send(msg)
error: [Errno 40] Message too long
Logged from file <stdin>, line 1

----------
messages: 134265
nosy: lukas.lalinsky
priority: normal
severity: normal
status: open
title: SysLogHandler can't send long messages
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11907>
_______________________________________

From report at bugs.python.org  Fri Apr 22 16:29:25 2011
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 22 Apr 2011 14:29:25 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1303482565.47.0.708541846774.issue2292@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/issue2292>
_______________________________________

From report at bugs.python.org  Fri Apr 22 17:40:07 2011
From: report at bugs.python.org (=?utf-8?q?Greg_S=C5=82odkowicz?=)
Date: Fri, 22 Apr 2011 15:40:07 +0000
Subject: [issue9325] Add an option to pdb/trace/profile to run library module
	as a script
In-Reply-To: <1279743902.96.0.66207849175.issue9325@psf.upfronthosting.co.za>
Message-ID: <1303486807.03.0.601105106767.issue9325@psf.upfronthosting.co.za>


Greg S?odkowicz <jergosh at gmail.com> added the comment:

Thanks, Nick. Before your last comment, I haven't looked much into Pdb, instead focusing on profile.py and trace.py because they looked like simpler cases. I think the approach with CodeRunner objects would work just fine for profile and trace but Pdb uses run() inherited from Bdb. In order to make it work with a CodeRunner object, it seems run() would have to be reimplemented in Pdb (effectively becoming a 'runCodeRunner()'), and we could probably do without _runscript(). Is that what you had in mind?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9325>
_______________________________________

From report at bugs.python.org  Fri Apr 22 17:46:29 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 22 Apr 2011 15:46:29 +0000
Subject: [issue11513] chained exception/incorrect exception from tarfile.open
	on a non-existent file
In-Reply-To: <1300146032.78.0.080952835314.issue11513@psf.upfronthosting.co.za>
Message-ID: <1303487189.87.0.208734963846.issue11513@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Commented on the patch.  I'll be happy to land this for Evan.

----------
assignee:  -> barry
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11513>
_______________________________________

From report at bugs.python.org  Fri Apr 22 18:33:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Apr 2011 16:33:54 +0000
Subject: [issue11885] argparse docs needs fixing
In-Reply-To: <1303300720.91.0.791889164093.issue11885@psf.upfronthosting.co.za>
Message-ID: <1303490034.14.0.643763589649.issue11885@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file21750/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11885>
_______________________________________

From report at bugs.python.org  Fri Apr 22 18:34:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Apr 2011 16:34:14 +0000
Subject: [issue11885] argparse docs needs fixing
In-Reply-To: <1303300720.91.0.791889164093.issue11885@psf.upfronthosting.co.za>
Message-ID: <1303490054.46.0.4950404398.issue11885@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

No problem, it?s Ezio who did the work.

----------
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11885>
_______________________________________

From report at bugs.python.org  Fri Apr 22 18:37:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Apr 2011 16:37:36 +0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1303490256.23.0.162465407568.issue1322@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The hard part was supporting distro-specific release files; I think that now most of them provide the lsb_release info.  If it proves more complicated than that, then let?s deprecate the function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Fri Apr 22 18:47:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Apr 2011 16:47:47 +0000
Subject: [issue11881] Add list.get
In-Reply-To: <1303237030.15.0.691261083336.issue11881@psf.upfronthosting.co.za>
Message-ID: <1303490867.86.0.25031284635.issue11881@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11881>
_______________________________________

From report at bugs.python.org  Fri Apr 22 18:49:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Apr 2011 16:49:47 +0000
Subject: [issue11862] urlparse.ParseResult to have meaningful __str__
In-Reply-To: <1303064594.29.0.64850729087.issue11862@psf.upfronthosting.co.za>
Message-ID: <1303490987.6.0.960123482908.issue11862@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Why couldn?t ParseResult call urlunparse to implement a useful __str__?

----------
components: +Library (Lib) -Extension Modules
nosy: +eric.araujo
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11862>
_______________________________________

From report at bugs.python.org  Fri Apr 22 18:52:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Apr 2011 16:52:05 +0000
Subject: [issue11869] Include information about the bug tracker Rietveld code
	review tool
In-Reply-To: <1303156808.41.0.477083927136.issue11869@psf.upfronthosting.co.za>
Message-ID: <1303491125.68.0.575241207625.issue11869@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11869>
_______________________________________

From report at bugs.python.org  Fri Apr 22 18:52:40 2011
From: report at bugs.python.org (Piotr Sikora)
Date: Fri, 22 Apr 2011 16:52:40 +0000
Subject: [issue10154] locale.normalize strips "-" from UTF-8,
	which fails on Mac
In-Reply-To: <1287588685.92.0.0691926945263.issue10154@psf.upfronthosting.co.za>
Message-ID: <1303491160.48.0.573407173763.issue10154@psf.upfronthosting.co.za>


Piotr Sikora <piotr.sikora at frickle.com> added the comment:

It's the same on OpenBSD (and I'm pretty sure it's true for other BSDs as well).

>>> locale.resetlocale()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.6/locale.py", line 523, in resetlocale
    _setlocale(category, _build_localename(getdefaultlocale()))
locale.Error: unsupported locale setting
>>> locale._build_localename(locale.getdefaultlocale())
'en_US.UTF8'

Works fine with Marc-Andre's alias table fix.

Any chances this will be eventually fixed in 2.x?

----------
nosy: +PiotrSikora

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10154>
_______________________________________

From report at bugs.python.org  Fri Apr 22 18:53:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Apr 2011 16:53:25 +0000
Subject: [issue11873] test_regexp() of test_compileall failure on "x86
	OpenIndiana 3.x"
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1303491205.12.0.921964017959.issue11873@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

How do we debug this?  Does someone have access to a similar box to see whether the pyc files do get created and where?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11873>
_______________________________________

From report at bugs.python.org  Fri Apr 22 18:53:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Apr 2011 16:53:49 +0000
Subject: [issue11874] argparse assertion failure with brackets in metavars
In-Reply-To: <1303201252.58.0.236363581255.issue11874@psf.upfronthosting.co.za>
Message-ID: <1303491229.7.0.430687397836.issue11874@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +bethard, eric.araujo
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11874>
_______________________________________

From report at bugs.python.org  Fri Apr 22 18:54:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Apr 2011 16:54:41 +0000
Subject: [issue11879] TarFile.chown: should use TarInfo.uid if user lookup
	fails
In-Reply-To: <1303229015.7.0.433519463198.issue11879@psf.upfronthosting.co.za>
Message-ID: <1303491281.28.0.302543114681.issue11879@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If you make the suggested change to your Python, do the tests still pass?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11879>
_______________________________________

From report at bugs.python.org  Fri Apr 22 18:57:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Apr 2011 16:57:09 +0000
Subject: [issue11884] Argparse calls ngettext but doesn't import it
In-Reply-To: <1303285010.85.0.710971435429.issue11884@psf.upfronthosting.co.za>
Message-ID: <1303491429.76.0.765763769526.issue11884@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I added the import and calls in 1827a8ac9b18, so this report is strange.  What is your exact version and where did you get it?

----------
assignee:  -> eric.araujo
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11884>
_______________________________________

From report at bugs.python.org  Fri Apr 22 19:00:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Apr 2011 17:00:07 +0000
Subject: [issue11901] Docs for sys.hexversion should give the algorithm
In-Reply-To: <1303410263.92.0.721904855375.issue11901@psf.upfronthosting.co.za>
Message-ID: <1303491607.22.0.24970852937.issue11901@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11901>
_______________________________________

From report at bugs.python.org  Fri Apr 22 19:02:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Apr 2011 17:02:07 +0000
Subject: [issue11906] Test_argparse failure but only in interactive mode
In-Reply-To: <1303442771.01.0.0867760921949.issue11906@psf.upfronthosting.co.za>
Message-ID: <1303491727.99.0.262166295878.issue11906@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11906>
_______________________________________

From report at bugs.python.org  Fri Apr 22 19:04:17 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 22 Apr 2011 17:04:17 +0000
Subject: [issue11901] Docs for sys.hexversion should give the algorithm
In-Reply-To: <1303410263.92.0.721904855375.issue11901@psf.upfronthosting.co.za>
Message-ID: <1303491857.26.0.122655013186.issue11901@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

+1

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11901>
_______________________________________

From report at bugs.python.org  Fri Apr 22 19:37:26 2011
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 22 Apr 2011 17:37:26 +0000
Subject: [issue11908] Weird `slice.stop or sys.maxint`
In-Reply-To: <1303493846.17.0.214651551769.issue11908@psf.upfronthosting.co.za>
Message-ID: <1303493846.17.0.214651551769.issue11908@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

In the documentation for `itertools.islice` I see this line:

    it = iter(xrange(s.start or 0, s.stop or sys.maxint, s.step or 1))

Is it really okay to do `s.stop or sys.maxint`? I'm assuming this was targeting `None`, but what if `s.stop == 0`? And `s.step` could (pathologically) be `0` too, no?

----------
assignee: docs at python
components: Documentation
messages: 134276
nosy: cool-RR, docs at python
priority: normal
severity: normal
status: open
title: Weird `slice.stop or sys.maxint`
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11908>
_______________________________________

From report at bugs.python.org  Fri Apr 22 20:01:51 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 22 Apr 2011 18:01:51 +0000
Subject: [issue11908] Weird `slice.stop or sys.maxint`
In-Reply-To: <1303493846.17.0.214651551769.issue11908@psf.upfronthosting.co.za>
Message-ID: <1303495311.33.0.206671401317.issue11908@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11908>
_______________________________________

From report at bugs.python.org  Fri Apr 22 20:49:57 2011
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Fri, 22 Apr 2011 18:49:57 +0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1303498197.85.0.322720778107.issue1322@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

There seems to be some mistake, re #msg134219 and #msg134255. The current version of may patch *does* avoid the cost of a subprocess in the common case. I described this new strategy in #msg73744 and as far as I know it satisfies all of MAL's earlier objection about that.

To recap, this code here: http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/__init__.py?annotate=blame&rev=5033#L36 does the following strategy:

1. Parse the /etc/lsb-release file. /etc/lsb-release is not part of the de jure standard, but it is a de facto standard that is available on many distributions. Parsing it is fast and gives the right answer on many distributions.

2. If that didn't work (which can happen on some distributions, including common ones when a certain optional "lsb base" package isn't installed), then invoke the current platform.dist() code. This is a lot of code, its code has to be changed before it can recognize any new distribution or a change in a distribution, and it gives answers on Ubuntu and Arch Linux which users say are the wrong answer, but it is fast and it gives the answer users want in most cases.

3. If that didn't work (which presumably only happens on distributions that the authors of platform.dist() didn't know about or didn't bother to support), then invoke the de jure standard executable "lsb_release". This works on any LSB-compliant system, but it costs a subprocess.

4. If that didn't work, check for /etc/arch-release to signal Arch Linux.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Fri Apr 22 21:31:22 2011
From: report at bugs.python.org (Devin Jeanpierre)
Date: Fri, 22 Apr 2011 19:31:22 +0000
Subject: [issue11909] Doctest sees directives in strings when it should only
	see them in comments
In-Reply-To: <1303500682.88.0.595944133083.issue11909@psf.upfronthosting.co.za>
Message-ID: <1303500682.88.0.595944133083.issue11909@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre <jeanpierreda at gmail.com>:

>From the doctest source:

'Option directives are comments starting with "doctest:".  Warning: this may give false  positives for string-literals that contain the string "#doctest:".  Eliminating these false positives would require actually parsing the string; but we limit them by ignoring any line containing "#doctest:" that is *followed* by a quote mark.'

This isn't a huge deal, but it's a bit annoying. Above being confusing, this is in contradiction with the doctest documentation, which states:

'Doctest directives are expressed as a special Python comment following an example?s source code'

No mention is made of this corner case where the regexp breaks.

As per the comment in the source, the patched version parses the source using the tokenize module, and runs a modified directive regex on all comment tokens to find directives.

----------
components: Library (Lib)
files: comments.diff
keywords: patch
messages: 134278
nosy: Devin Jeanpierre
priority: normal
severity: normal
status: open
title: Doctest sees directives in strings when it should only see them in comments
Added file: http://bugs.python.org/file21757/comments.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11909>
_______________________________________

From report at bugs.python.org  Fri Apr 22 21:47:07 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 22 Apr 2011 19:47:07 +0000
Subject: [issue11909] Doctest sees directives in strings when it should only
	see them in comments
In-Reply-To: <1303500682.88.0.595944133083.issue11909@psf.upfronthosting.co.za>
Message-ID: <1303501627.66.0.297042274394.issue11909@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> patch review
type:  -> feature request
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11909>
_______________________________________

From report at bugs.python.org  Fri Apr 22 21:53:50 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 22 Apr 2011 19:53:50 +0000
Subject: [issue11873] test_regexp() of test_compileall failure on "x86
	OpenIndiana 3.x"
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1303502030.18.0.166341951096.issue11873@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Given that it happens randomly I suspect a timing issue, but without having reviewed the code in question.  I'm not sure when I'll have time to look at this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11873>
_______________________________________

From report at bugs.python.org  Fri Apr 22 22:25:06 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 22 Apr 2011 20:25:06 +0000
Subject: [issue9319] imp.find_module('test/badsyntax_pep3120') causes segfault
In-Reply-To: <1279693765.46.0.777254335316.issue9319@psf.upfronthosting.co.za>
Message-ID: <1303503906.71.0.623112277349.issue9319@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9319>
_______________________________________

From report at bugs.python.org  Sat Apr 23 00:24:33 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Fri, 22 Apr 2011 22:24:33 +0000
Subject: [issue11885] argparse docs needs fixing
In-Reply-To: <1303490054.46.0.4950404398.issue11885@psf.upfronthosting.co.za>
Message-ID: <BANLkTimvR_vsx3DipVRe=b6EzSzdBKfKtQ@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

I ment to say Ezio. Got confused. Thanks, Ezio!

----------
Added file: http://bugs.python.org/file21758/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11885>
_______________________________________
-------------- next part --------------
I ment to say Ezio. Got confused. Thanks, Ezio!

From report at bugs.python.org  Sat Apr 23 00:29:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Apr 2011 22:29:46 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1303511386.91.0.632332885955.issue8407@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: expose signalfd(2) and sigprocmask(2) in the signal module -> expose signalfd(2) and pthread_sigmask in the signal module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Sat Apr 23 00:42:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Apr 2011 22:42:28 +0000
Subject: [issue9319] imp.find_module('test/badsyntax_pep3120') causes segfault
In-Reply-To: <1279693765.46.0.777254335316.issue9319@psf.upfronthosting.co.za>
Message-ID: <E1QDP3S-00012G-HO@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset fa5e348889c2 by Victor Stinner in branch '3.2':
Issue #9319: Fix a crash on parsing a Python source code without encoding
http://hg.python.org/cpython/rev/fa5e348889c2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9319>
_______________________________________

From report at bugs.python.org  Sat Apr 23 00:44:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Apr 2011 22:44:08 +0000
Subject: [issue9319] imp.find_module('test/badsyntax_pep3120') causes segfault
In-Reply-To: <1279693765.46.0.777254335316.issue9319@psf.upfronthosting.co.za>
Message-ID: <1303512248.77.0.339372743289.issue9319@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed in 3.2 (fa5e348889c2) and 3.3 (7b8d625eb6e4). The bug is a regression introduced in Python 3.2, so Python 3.1 doesn't need to be fixed.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9319>
_______________________________________

From report at bugs.python.org  Sat Apr 23 01:27:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Apr 2011 23:27:46 +0000
Subject: [issue9319] imp.find_module('test/badsyntax_pep3120') causes segfault
In-Reply-To: <1279693765.46.0.777254335316.issue9319@psf.upfronthosting.co.za>
Message-ID: <E1QDPlI-0003bU-GH@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 701069f9888c by Victor Stinner in branch '3.2':
Issue #9319: Fix the unit test
http://hg.python.org/cpython/rev/701069f9888c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9319>
_______________________________________

From report at bugs.python.org  Sat Apr 23 01:37:49 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Apr 2011 23:37:49 +0000
Subject: [issue11906] Test_argparse failure but only in interactive mode
In-Reply-To: <1303442771.01.0.0867760921949.issue11906@psf.upfronthosting.co.za>
Message-ID: <1303515469.69.0.790895935243.issue11906@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If I put the same line I ran interactively in a file and run it

from test import test_argparse as t; t.test_main()

all tests pass. So it is specifically a problem from the interactive prompt.

----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11906>
_______________________________________

From report at bugs.python.org  Sat Apr 23 01:44:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Apr 2011 23:44:54 +0000
Subject: [issue11619] On Windows,
	don't encode filenames in the import machinery
In-Reply-To: <1300665531.85.0.426527059221.issue11619@psf.upfronthosting.co.za>
Message-ID: <1303515894.17.0.279506757113.issue11619@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Another huge patch to support Unicode filenames: parser_unicode.patch


 Doc/c-api/exceptions.rst |   26 +++++++++++---
 Include/ast.h            |    5 ++
 Include/compile.h        |   15 +++++++-
 Include/parsetok.h       |   42 ++++++++++++++++++-----
 Include/pyerrors.h       |    7 +++
 Include/pythonrun.h      |   16 ++++++++
 Include/symtable.h       |    6 ++-
 Include/warnings.h       |    8 ++++
 Modules/parsermodule.c   |   49 +++++++++++++++++----------
 Modules/symtablemodule.c |   10 +++--
 Parser/parsetok.c        |   82 +++++++++++++++++++++++++++++++++++++--------
 Python/_warnings.c       |   31 +++++++++++------
 Python/ast.c             |   40 ++++++++++++----------
 Python/compile.c         |   69 +++++++++++++++++++++-----------------
 Python/errors.c          |   57 ++++++++++++++++++++++---------
 Python/future.c          |   27 +++++++++++---
 Python/import.c          |   20 +++--------
 Python/pythonrun.c       |   85 +++++++++++++++++++++++++++++++++++++----------
 Python/symtable.c        |   73 +++++++++++++++++++++++++++-------------
 19 files changed, 480 insertions(+), 188 deletions(-)

It creates new functions of the following functions which are undocumented:
 - PyAST_FromNode
 - PyFuture_FromAST
 - PyAST_Compile
 - PyParser_ParseFileFlagsEx
 - PyParser_ParseStringFlagsFilenameEx
 - PyErr_ProgramText
 - PyParser_ASTFromString
 - PyParser_ASTFromFile
 - PySymtable_Build

We might remove these functions, but they are part of the public API (but they are undocumented).

----------
Added file: http://bugs.python.org/file21759/parser_unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11619>
_______________________________________

From report at bugs.python.org  Sat Apr 23 01:44:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Apr 2011 23:44:58 +0000
Subject: [issue11619] On Windows,
	don't encode filenames in the import machinery
In-Reply-To: <1300665531.85.0.426527059221.issue11619@psf.upfronthosting.co.za>
Message-ID: <1303515898.92.0.215363644734.issue11619@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file21743/compile_filename.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11619>
_______________________________________

From report at bugs.python.org  Sat Apr 23 01:51:15 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Fri, 22 Apr 2011 23:51:15 +0000
Subject: [issue11906] Test_argparse failure but only in interactive mode
In-Reply-To: <1303442771.01.0.0867760921949.issue11906@psf.upfronthosting.co.za>
Message-ID: <1303516275.57.0.372298778118.issue11906@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

That happens because argparse uses `os.basename(sys.argv[0])` (per default) as program name, but `sys.argv[0]` is usually a string of length 0 at interactive sessions. The tests use ``"usage: {} ...".format(program_name)`` (note that there will be two spaces for an empty `program_name`) for the expected output, while argparse only outputs one space in that case.

----------
nosy: +Trundle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11906>
_______________________________________

From report at bugs.python.org  Sat Apr 23 02:45:14 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Apr 2011 00:45:14 +0000
Subject: [issue11860] reference 2.3 has text that runs past the page
In-Reply-To: <1303005204.18.0.459182918365.issue11860@psf.upfronthosting.co.za>
Message-ID: <1303519514.82.0.641720487818.issue11860@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I presume you are talking about long boxed grammar or example lines that run horizontally past the right edge of the window, like

id_start     ::=  <all characters in general categories Lu, Ll, Lt, Lm, Lo, Nl, the underscore, and characters with the Other_ID_Start property>

For both the .html (online) and .chm (windows help) versions of the docs, these boxes have horizontal scroll bars. For both types of files, regular text is wrapped according to the size of the window, which the user can change. Neither involved latex and there is no such thing as the width of the page, and there are no page numbers either.

Are you, possibly, referring to a .pdf version, which I believe is run through latex?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11860>
_______________________________________

From report at bugs.python.org  Sat Apr 23 03:23:10 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Apr 2011 01:23:10 +0000
Subject: [issue11860] reference 2.3 has text that runs past the page
In-Reply-To: <1303005204.18.0.459182918365.issue11860@psf.upfronthosting.co.za>
Message-ID: <1303521790.35.0.87596409089.issue11860@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Yes, the problem is with the PDF. See also #4173.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11860>
_______________________________________

From report at bugs.python.org  Sat Apr 23 03:23:43 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Apr 2011 01:23:43 +0000
Subject: [issue4173] PDF documentation: long verbatim lines are cut off at
	right hand side
In-Reply-To: <1224684717.3.0.110027961744.issue4173@psf.upfronthosting.co.za>
Message-ID: <1303521823.93.0.461421019855.issue4173@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See also #11860.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4173>
_______________________________________

From report at bugs.python.org  Sat Apr 23 03:31:47 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Apr 2011 01:31:47 +0000
Subject: [issue11889] 'enumerate' 'start' parameter documentation is confusing
In-Reply-To: <1303315736.72.0.416681647484.issue11889@psf.upfronthosting.co.za>
Message-ID: <1303522307.14.0.324299016663.issue11889@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Note: 3.x correct gives the signature at enumerate(iterable, start) rather that enumerate(sequence, start).

I agree that the current entry is a bit awkward. Perhaps the doc would be clearer with a reference to zipping. Removing the unneeded definition of *iterable* (which should be linked to the definition in the glossary, along with *iterator*), my suggestion is:
'''
enumerate(iterable, start=0)
Return an enumerate object, an *iterator* of tuples, that zips together a sequence of counts and *iterable*. Each tuple contain a count and an item from *iterable*, in that order. The counts begin with *start*, which defaults to 0. enumerate() is useful for obtaining an indexed series: enumerate(seq) produces (0, seq[0]), (1, seq[1]), (2, seq[2]), .... For another example, which uses *start*:

>>> for i, season in enumerate(['Spring','Summer','Fall','Winter'], 1):
...     print(i, season)
1 Spring
2 Summer
3 Fall
4 Winter
'''
Note that I changed the example to use a start of 1 instead of 0, to produce a list in traditional form, which is one reason to have the parameter!

----------
nosy: +terry.reedy
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11889>
_______________________________________

From report at bugs.python.org  Sat Apr 23 03:34:02 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Apr 2011 01:34:02 +0000
Subject: [issue11906] Test_argparse failure but only in interactive mode
In-Reply-To: <1303442771.01.0.0867760921949.issue11906@psf.upfronthosting.co.za>
Message-ID: <1303522442.47.0.877036243476.issue11906@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thanks for the diagnosis. I am glad it is something simple.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11906>
_______________________________________

From report at bugs.python.org  Sat Apr 23 03:43:34 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Apr 2011 01:43:34 +0000
Subject: [issue11860] reference 2.3 has text that runs past the page
In-Reply-To: <1303005204.18.0.459182918365.issue11860@psf.upfronthosting.co.za>
Message-ID: <1303523014.21.0.946835946021.issue11860@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Then this appears to be a duplicate. Closing

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> PDF documentation: long verbatim lines are cut off at right hand side

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11860>
_______________________________________

From report at bugs.python.org  Sat Apr 23 04:04:19 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Apr 2011 02:04:19 +0000
Subject: [issue11910] test_heapq C tests are not skipped when _heapq is missing
In-Reply-To: <1303524259.87.0.426176819457.issue11910@psf.upfronthosting.co.za>
Message-ID: <1303524259.87.0.426176819457.issue11910@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

When _heapq is missing, test_heapq still runs both the Py and the C tests instead of skipping the C ones.  The attached patch skips the C tests when _heapq is missing.

----------
files: issue11910.diff
keywords: patch
messages: 134293
nosy: ezio.melotti
priority: normal
severity: normal
status: open
title: test_heapq C tests are not skipped when _heapq is missing
Added file: http://bugs.python.org/file21760/issue11910.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11910>
_______________________________________

From report at bugs.python.org  Sat Apr 23 04:05:13 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Apr 2011 02:05:13 +0000
Subject: [issue11910] test_heapq C tests are not skipped when _heapq is missing
In-Reply-To: <1303524259.87.0.426176819457.issue11910@psf.upfronthosting.co.za>
Message-ID: <1303524313.24.0.659748623459.issue11910@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Tests
nosy: +brett.cannon
stage:  -> patch review
type:  -> behavior
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11910>
_______________________________________

From report at bugs.python.org  Sat Apr 23 06:48:32 2011
From: report at bugs.python.org (John O'Hagan)
Date: Sat, 23 Apr 2011 04:48:32 +0000
Subject: [issue11884] Argparse calls ngettext but doesn't import it
In-Reply-To: <1303285010.85.0.710971435429.issue11884@psf.upfronthosting.co.za>
Message-ID: <1303534112.75.0.723550922176.issue11884@psf.upfronthosting.co.za>


John O'Hagan <research at johnohagan.com> added the comment:

It's argparse version 1.1 (1.1-1) from current Debian testing, Python 3.2 (r32:88445, Feb 20 2011, 18:43:30)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11884>
_______________________________________

From report at bugs.python.org  Sat Apr 23 09:00:42 2011
From: report at bugs.python.org (Prashant Kumar)
Date: Sat, 23 Apr 2011 07:00:42 +0000
Subject: [issue10932] distutils.core.setup - data_files misbehaviour ?
In-Reply-To: <1295353825.23.0.755300594789.issue10932@psf.upfronthosting.co.za>
Message-ID: <1303542042.21.0.733942424288.issue10932@psf.upfronthosting.co.za>


Prashant Kumar <contactprashantat at gmail.com> added the comment:

Certainly, a test is needed to check that ('config', ['cfg/data.cfg']) would create a file in config/data.cfg and not config/cfg/data.cfg.

Though, I've added a patch 'test_command_sdist.diff' for the changes made in 'patch.diff'.

----------
Added file: http://bugs.python.org/file21761/test_command_sdist.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10932>
_______________________________________

From report at bugs.python.org  Sat Apr 23 10:17:59 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 23 Apr 2011 08:17:59 +0000
Subject: [issue11911] Interlink Python versions docs
In-Reply-To: <1303546679.67.0.126016913542.issue11911@psf.upfronthosting.co.za>
Message-ID: <1303546679.67.0.126016913542.issue11911@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

I want to be able to jump from latest Python 2 docs to the same page in stable Python 3 doc in one click. E.g. from http://docs.python.org/library/string.html to http://docs.python.org/py3k/library/strings.html

----------
assignee: docs at python
components: Documentation
messages: 134296
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: Interlink Python versions docs
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11911>
_______________________________________

From report at bugs.python.org  Sat Apr 23 10:18:11 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 23 Apr 2011 08:18:11 +0000
Subject: [issue11911] Interlink Python versions docs
In-Reply-To: <1303546679.67.0.126016913542.issue11911@psf.upfronthosting.co.za>
Message-ID: <1303546691.09.0.0532223044566.issue11911@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

sorry, to http://docs.python.org/py3k/library/string.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11911>
_______________________________________

From report at bugs.python.org  Sat Apr 23 11:14:40 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 23 Apr 2011 09:14:40 +0000
Subject: [issue11907] SysLogHandler can't send long messages
In-Reply-To: <1303480338.6.0.255798757577.issue11907@psf.upfronthosting.co.za>
Message-ID: <1303550080.23.0.591116177244.issue11907@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
assignee:  -> vinay.sajip
nosy: +vinay.sajip
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11907>
_______________________________________

From report at bugs.python.org  Sat Apr 23 12:24:36 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 23 Apr 2011 10:24:36 +0000
Subject: [issue11907] SysLogHandler can't send long messages
In-Reply-To: <1303480338.6.0.255798757577.issue11907@psf.upfronthosting.co.za>
Message-ID: <1303554276.79.0.411331653938.issue11907@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The entire part of emit() which sends to the socket is wrapped in an except: which should catch all except KeyboardInterrupt and SystemExit. The except clause calls the handleError method of the handler. See

http://hg.python.org/cpython/file/fa277cbd66bb/Lib/logging/handlers.py#l804

So I can't see exactly what's happening, and moreover I can't reproduce this on Linux even when sending messages of > 16384 on the Unix socket. I don't have access to a FreeBSD system.

Can you do a little more investigation, since I'm not sure what your source says? (The line nos. don't seem to match up exactly - in Mercurial, line 808 is an except socket.error clause).

----------
components: +Library (Lib)
status: open -> pending
type: crash -> behavior
versions:  -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11907>
_______________________________________

From report at bugs.python.org  Sat Apr 23 15:23:28 2011
From: report at bugs.python.org (Michael Gold)
Date: Sat, 23 Apr 2011 13:23:28 +0000
Subject: [issue11899] TarFile.gettarinfo modifies self.inodes
In-Reply-To: <1303398997.96.0.910828864.issue11899@psf.upfronthosting.co.za>
Message-ID: <1303565008.88.0.699416169283.issue11899@psf.upfronthosting.co.za>


Michael Gold <mgold at ncf.ca> added the comment:

No, I don't have a working implementation.  (I basically reimplemented TarFile.inodes to work around this; I was using TarFile.dereference, so I already had to do the hard-linking manually.)

----------
nosy: +mgold

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11899>
_______________________________________

From report at bugs.python.org  Sat Apr 23 15:30:09 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Apr 2011 13:30:09 +0000
Subject: [issue11911] Interlink Python versions docs
In-Reply-To: <1303546679.67.0.126016913542.issue11911@psf.upfronthosting.co.za>
Message-ID: <1303565409.1.0.502011521779.issue11911@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is a duplicated of #8040.

----------
nosy: +ezio.melotti
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> It would be nice if documentation pages linked to other versions of the same document

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11911>
_______________________________________

From report at bugs.python.org  Sat Apr 23 15:45:54 2011
From: report at bugs.python.org (Michael Gold)
Date: Sat, 23 Apr 2011 13:45:54 +0000
Subject: [issue11879] TarFile.chown: should use TarInfo.uid if user lookup
	fails
In-Reply-To: <1303229015.7.0.433519463198.issue11879@psf.upfronthosting.co.za>
Message-ID: <1303566354.85.0.539598099259.issue11879@psf.upfronthosting.co.za>


Michael Gold <mgold at ncf.ca> added the comment:

The tests passed on Linux (with Python 3.2 under fakeroot):
Ran 240 tests in 9.613s
OK

But I don't see any tests that check the uid/gid of extracted files.

----------
nosy: +mgold

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11879>
_______________________________________

From report at bugs.python.org  Sat Apr 23 16:42:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 23 Apr 2011 14:42:01 +0000
Subject: [issue11889] 'enumerate' 'start' parameter documentation is confusing
In-Reply-To: <1303315736.72.0.416681647484.issue11889@psf.upfronthosting.co.za>
Message-ID: <1303569721.41.0.508525872665.issue11889@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 to what David says.

Terry?s patch is a good starting point; I think Raymond will commit something along its lines.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11889>
_______________________________________

From report at bugs.python.org  Sat Apr 23 16:49:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 23 Apr 2011 14:49:14 +0000
Subject: [issue11884] Argparse calls ngettext but doesn't import it
In-Reply-To: <1303285010.85.0.710971435429.issue11884@psf.upfronthosting.co.za>
Message-ID: <1303570154.14.0.905907900802.issue11884@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Confirmed.  It?s a Debian-specific problem, please use ?reportbug python3.2? to report it to them.

----------
nosy: +doko
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11884>
_______________________________________

From report at bugs.python.org  Sat Apr 23 17:21:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Apr 2011 15:21:43 +0000
Subject: [issue11382] some posix module functions unnecessarily release the GIL
In-Reply-To: <1299147333.52.0.465056224972.issue11382@psf.upfronthosting.co.za>
Message-ID: <E1QDeeU-0006yH-0h@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset eb7297fd5840 by Antoine Pitrou in branch 'default':
Issue #11382: Trivial system calls, such as dup() or pipe(), needn't
http://hg.python.org/cpython/rev/eb7297fd5840

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11382>
_______________________________________

From report at bugs.python.org  Sat Apr 23 17:34:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Apr 2011 15:34:10 +0000
Subject: [issue11382] some posix module functions unnecessarily release the GIL
In-Reply-To: <1299147333.52.0.465056224972.issue11382@psf.upfronthosting.co.za>
Message-ID: <1303572850.74.0.477564281802.issue11382@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Sorry for the delay, I had forgotten about this issue. Thank you for the patch!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11382>
_______________________________________

From report at bugs.python.org  Sat Apr 23 17:35:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 23 Apr 2011 15:35:10 +0000
Subject: [issue444582] Finding programs in PATH, adding shutil.which
Message-ID: <1303572910.64.0.532236279753.issue444582@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can someone remove obsolete files from the file list and post an up-to-date patch?

----------
keywords:  -easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue444582>
_______________________________________

From report at bugs.python.org  Sat Apr 23 17:37:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 23 Apr 2011 15:37:13 +0000
Subject: [issue482531] python directory not added to PATH
Message-ID: <1303573033.98.0.212018183835.issue482531@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
superseder:  -> Windows installer should add Python and Scripts directories to the PATH environment variable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue482531>
_______________________________________

From report at bugs.python.org  Sat Apr 23 17:41:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 23 Apr 2011 15:41:15 +0000
Subject: [issue9325] Add an option to pdb/trace/profile to run library module
	as a script
In-Reply-To: <1279743902.96.0.66207849175.issue9325@psf.upfronthosting.co.za>
Message-ID: <1303573275.72.0.137122985664.issue9325@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9325>
_______________________________________

From report at bugs.python.org  Sat Apr 23 17:46:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 23 Apr 2011 15:46:10 +0000
Subject: [issue10154] locale.normalize strips "-" from UTF-8,
	which fails on Mac
In-Reply-To: <1287588685.92.0.0691926945263.issue10154@psf.upfronthosting.co.za>
Message-ID: <1303573570.67.0.0266736918828.issue10154@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage:  -> needs patch
title: locale.normalize strips "-" from UTF-8,	which fails on Mac -> locale.normalize strips "-" from UTF-8, which fails on Mac
versions: +Python 3.3 -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10154>
_______________________________________

From report at bugs.python.org  Sat Apr 23 17:47:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 23 Apr 2011 15:47:41 +0000
Subject: [issue9228] Make changes in the PATH and PATHEXT on installation
In-Reply-To: <1278892287.6.0.671523214632.issue9228@psf.upfronthosting.co.za>
Message-ID: <1303573661.12.0.634811902498.issue9228@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This is rejected every few months by Martin.

----------
nosy: +eric.araujo
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Windows installer should add Python and Scripts directories to the PATH environment variable
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9228>
_______________________________________

From report at bugs.python.org  Sat Apr 23 17:51:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 23 Apr 2011 15:51:40 +0000
Subject: [issue11340] test_distutils fails because of borked compress program
In-Reply-To: <1298752200.14.0.360216595971.issue11340@psf.upfronthosting.co.za>
Message-ID: <1303573900.07.0.835739436718.issue11340@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Okay.  It?s not a very beautiful check, but it will do.  Do you want to make a patch to disable compress if it?s a fake compress program?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11340>
_______________________________________

From report at bugs.python.org  Sat Apr 23 17:56:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Apr 2011 15:56:29 +0000
Subject: [issue11258] ctypes: Speed up find_library() on Linux by 500%
In-Reply-To: <1298217839.35.0.775539629492.issue11258@psf.upfronthosting.co.za>
Message-ID: <E1QDfC4-0000eD-BS@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 19d9f0a177de by Antoine Pitrou in branch 'default':
Issue #11258: Speed up ctypes.util.find_library() under Linux by a factor
http://hg.python.org/cpython/rev/19d9f0a177de

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11258>
_______________________________________

From report at bugs.python.org  Sat Apr 23 17:57:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Apr 2011 15:57:05 +0000
Subject: [issue11258] ctypes: Speed up find_library() on Linux by 500%
In-Reply-To: <1298217839.35.0.775539629492.issue11258@psf.upfronthosting.co.za>
Message-ID: <1303574225.84.0.700179970645.issue11258@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I committed a modified patch. Hopefully the buildbots won't break this time :)

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11258>
_______________________________________

From report at bugs.python.org  Sat Apr 23 18:54:46 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 23 Apr 2011 16:54:46 +0000
Subject: [issue11889] 'enumerate' 'start' parameter documentation is confusing
In-Reply-To: <1303315736.72.0.416681647484.issue11889@psf.upfronthosting.co.za>
Message-ID: <1303577686.14.0.70123158029.issue11889@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I've got it from here.  Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11889>
_______________________________________

From report at bugs.python.org  Sat Apr 23 20:24:48 2011
From: report at bugs.python.org (=?utf-8?b?THVrw6HFoSBMYWxpbnNrw70=?=)
Date: Sat, 23 Apr 2011 18:24:48 +0000
Subject: [issue11907] SysLogHandler can't send long messages
In-Reply-To: <1303480338.6.0.255798757577.issue11907@psf.upfronthosting.co.za>
Message-ID: <1303583088.75.0.884405562286.issue11907@psf.upfronthosting.co.za>


Luk?? Lalinsk? <lalinsky at gmail.com> added the comment:

It seems that I was wrong, the exception is indeed not propagated to the application, but handled by the handleError() method. I was confused by seeing the traceback in my uWSGI log file.

I'm unable to find a way to determine the maximum allowed syslog message size, otherwise the proper behavior would be probably to truncate the message. Specifically on FreeBSD, the clib source code seems to be using a buffer with 2048 bytes for the whole syslog line and 1024 bytes for the message formatting, so they are just arbitrary numbers. :(

There probably isn't a way to solve this cleanly. Truncating the message would be much preferable to dropping it, but I really don't know what would be the right size. 

I'll write a LocalSysLogHandler for me that uses the syslog module.

Regarding the line numbers, this is the version corresponding to the 2.7.1 release - http://hg.python.org/cpython/file/5395f96588d4/Lib/logging/handlers.py#l808

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11907>
_______________________________________

From report at bugs.python.org  Sat Apr 23 21:07:03 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 23 Apr 2011 19:07:03 +0000
Subject: [issue11907] SysLogHandler can't send long messages
In-Reply-To: <1303480338.6.0.255798757577.issue11907@psf.upfronthosting.co.za>
Message-ID: <1303585623.56.0.782310073928.issue11907@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I've managed to get access to a FreeBSD system and done some investigation. The system is working as designed, and the error message is being printed by the handleError() method of the handler. To handle the exception differently, you either set logging.raiseExceptions to False (which will cause logging to swallow the exception) or you need to implement your own handler which takes appropriate action (e.g truncates the message).

Closing as invalid.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11907>
_______________________________________

From report at bugs.python.org  Sun Apr 24 01:39:45 2011
From: report at bugs.python.org (Nils Breunese)
Date: Sat, 23 Apr 2011 23:39:45 +0000
Subject: [issue11912] Python shouldn't use the mprotect() system call
In-Reply-To: <1303601985.39.0.925824346967.issue11912@psf.upfronthosting.co.za>
Message-ID: <1303601985.39.0.925824346967.issue11912@psf.upfronthosting.co.za>


New submission from Nils Breunese <nils at breun.nl>:

When I try to run iotop [0] on CentOS 5.6 on a kernel with grsecurity [1] then iotop won't start because grsecurity is blocking Python because of its use of the mprotect() system call.

Please see http://www.atomicorp.com/wiki/index.php/ASL_FAQ#grsec:_denied_RWX_mprotect for more information. The authors of this hardened Linux kernel suggested to file a bug with Python because using mprotect() is apparently a very bad thing to do.

[0] http://guichaz.free.fr/iotop/
[1] http://grsecurity.net/

----------
messages: 134314
nosy: breun
priority: normal
severity: normal
status: open
title: Python shouldn't use the mprotect() system call
type: security
versions: 3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11912>
_______________________________________

From report at bugs.python.org  Sun Apr 24 01:48:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Apr 2011 23:48:10 +0000
Subject: [issue11912] Python shouldn't use the mprotect() system call
In-Reply-To: <1303601985.39.0.925824346967.issue11912@psf.upfronthosting.co.za>
Message-ID: <1303602490.22.0.213108465626.issue11912@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Where have you seen that Python is calling mprotect()? There's no sign of it in the whole source tree.

----------
nosy: +neologix, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11912>
_______________________________________

From report at bugs.python.org  Sun Apr 24 02:00:37 2011
From: report at bugs.python.org (Nils Breunese)
Date: Sun, 24 Apr 2011 00:00:37 +0000
Subject: [issue11912] Python shouldn't use the mprotect() system call
In-Reply-To: <1303601985.39.0.925824346967.issue11912@psf.upfronthosting.co.za>
Message-ID: <1303603237.66.0.049041899254.issue11912@psf.upfronthosting.co.za>


Nils Breunese <nils at breun.nl> added the comment:

I got this error message in /var/log/messages when trying to start iotop:

----
Apr 13 08:49:37 hostname kernel: grsec: From xxx.xxx.xxx.xxx: denied RWX mprotect of /lib64/ld-2.5.so by /usr/bin/iotop[iotop:9836] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:9351] uid/euid:0/0 gid/egid:0/0
Apr 13 08:49:37 hostname kernel: iotop[9836]: segfault at 6248c405dda0 ip 00006248c3e489ec sp 00007fffa52e8410 error 7 in ld-2.5.so[6248c3e42000+1c000]
----

/usr/bin/iotop is a Python script and according to that log message grsecurity detected a call to mprotect().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11912>
_______________________________________

From report at bugs.python.org  Sun Apr 24 02:20:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Apr 2011 00:20:14 +0000
Subject: [issue11912] Python shouldn't use the mprotect() system call
In-Reply-To: <1303603237.66.0.049041899254.issue11912@psf.upfronthosting.co.za>
Message-ID: <1303604411.3495.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> /usr/bin/iotop is a Python script and according to that log message
> grsecurity detected a call to mprotect().

Well, does Python itself run ok? That Python script could use
third-party extension modules which issue the offending mprotect() call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11912>
_______________________________________

From report at bugs.python.org  Sun Apr 24 02:25:43 2011
From: report at bugs.python.org (Nils Breunese)
Date: Sun, 24 Apr 2011 00:25:43 +0000
Subject: [issue11912] Python shouldn't use the mprotect() system call
In-Reply-To: <1303601985.39.0.925824346967.issue11912@psf.upfronthosting.co.za>
Message-ID: <1303604743.0.0.276158345575.issue11912@psf.upfronthosting.co.za>


Nils Breunese <nils at breun.nl> added the comment:

I haven't had any problems with other Python applications like this, Python seems fine otherwise.

I just noticed that iotop has a dependency on python-ctypes, which sounds like it could be iotop doing the mprotect() calls via ctypes. Does that make sense?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11912>
_______________________________________

From report at bugs.python.org  Sun Apr 24 02:30:57 2011
From: report at bugs.python.org (Rafael Zanella)
Date: Sun, 24 Apr 2011 00:30:57 +0000
Subject: [issue4608] urllib.request.urlopen does not return an iterable object
In-Reply-To: <1228824822.91.0.748607079368.issue4608@psf.upfronthosting.co.za>
Message-ID: <1303605057.73.0.578024935987.issue4608@psf.upfronthosting.co.za>


Rafael Zanella <rafael.zanella at yahoo.com.br> added the comment:

The patch that makes addinfourl() iterable was not commited due to the change to HTTP request see: msg86365 (http://bugs.python.org/issue4608#msg86365).

Since urllib is protocol agnostic it should behave the same with FTP, right?

So, where to fix? Change the addinfourl() to become itrable or change the FTPHandler return?

----------
nosy: +zanella

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4608>
_______________________________________

From report at bugs.python.org  Sun Apr 24 03:10:57 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sun, 24 Apr 2011 01:10:57 +0000
Subject: [issue11912] Python shouldn't use the mprotect() system call
In-Reply-To: <1303601985.39.0.925824346967.issue11912@psf.upfronthosting.co.za>
Message-ID: <1303607457.15.0.0967468543303.issue11912@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

glibc's `dlopen()` can call `mprotect()`, which is used for loading C extensions.

----------
nosy: +Trundle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11912>
_______________________________________

From report at bugs.python.org  Sun Apr 24 03:57:58 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 24 Apr 2011 01:57:58 +0000
Subject: [issue6780] startswith error message is incomplete
In-Reply-To: <1251149593.57.0.654081758843.issue6780@psf.upfronthosting.co.za>
Message-ID: <1303610278.21.0.528898091822.issue6780@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attached an updated patch for 2.7 with tests that check that UnicodeErrors are still raised and that the error message mentions 'str', 'unicode' and 'tuple'.

----------
Added file: http://bugs.python.org/file21762/issue6780-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6780>
_______________________________________

From report at bugs.python.org  Sun Apr 24 04:48:42 2011
From: report at bugs.python.org (Ingy dot Net)
Date: Sun, 24 Apr 2011 02:48:42 +0000
Subject: [issue11913] sdist should allow for README.rst
In-Reply-To: <1303613322.81.0.629577121535.issue11913@psf.upfronthosting.co.za>
Message-ID: <1303613322.81.0.629577121535.issue11913@psf.upfronthosting.co.za>


New submission from Ingy dot Net <ingy at ingy.net>:

When I upload modules to PyPI, distutils is clucking about a missing README, even though PyPI accepts README.rst, and I am providing that.

Registering pyplay to http://pypi.python.org/pypi
Server response (200): OK
python setup.py sdist upload
running sdist
warning: sdist: standard file not found: should have one of README, README.txt

----------
assignee: tarek
components: Distutils
messages: 134322
nosy: eric.araujo, ingy, tarek
priority: normal
severity: normal
status: open
title: sdist should allow for README.rst
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11913>
_______________________________________

From report at bugs.python.org  Sun Apr 24 05:34:54 2011
From: report at bugs.python.org (Ben Okopnik)
Date: Sun, 24 Apr 2011 03:34:54 +0000
Subject: [issue11914] pydoc modules/help('modules') crash in dirs with
	unreadable subdirs
In-Reply-To: <1303616093.87.0.65824226669.issue11914@psf.upfronthosting.co.za>
Message-ID: <1303616093.87.0.65824226669.issue11914@psf.upfronthosting.co.za>


New submission from Ben Okopnik <ben at okopnik.com>:

Long-standing problem (happens in every Python version I've tested). The usual situation is when invoking Python (and then "help('modules')") or "pydoc modules" in /tmp, but also happens when located anywhere with unreadable subdirs:

ben at Jotunheim:~$ mkdir /tmp/foo; cd /tmp/foo
ben at Jotunheim:/tmp/foo$ mkdir bar; sudo chmod 000 bar
[sudo] password for ben: 
ben at Jotunheim:/tmp/foo$ pydoc modules

Please wait a moment while I gather a list of all available modules...

Traceback (most recent call last):
  File "/usr/bin/pydoc2.6", line 5, in <module>
    pydoc.cli()
  File "/usr/lib/python2.6/pydoc.py", line 2309, in cli
    help.help(arg)
  File "/usr/lib/python2.6/pydoc.py", line 1765, in help
    elif request == 'modules': self.listmodules()
  File "/usr/lib/python2.6/pydoc.py", line 1886, in listmodules
    ModuleScanner().run(callback, onerror=onerror)
  File "/usr/lib/python2.6/pydoc.py", line 1937, in run
    for importer, modname, ispkg in pkgutil.walk_packages(onerror=onerror):
  File "/usr/lib/python2.6/pkgutil.py", line 105, in walk_packages
    for importer, name, ispkg in iter_modules(path, prefix):
  File "/usr/lib/python2.6/pkgutil.py", line 147, in iter_modules
    for name, ispkg in iter_importer_modules(i, prefix):
  File "/usr/lib/python2.6/pkgutil.py", line 211, in iter_modules
    for fn in os.listdir(path):
OSError: [Errno 13] Permission denied: './bar'

Proposed patch:

Seems like an easy fix. In Python 3.1.2, change line 206 in /usr/lib/python3.1/pkgutil.py from

if not modname and os.path.isdir(path) and '.' not in fn:

to

if not modname and os.path.isdir(path) and '.' not in fn and os.access(path, os.R_OK):

Other versions much the same (although the specified line number will probably be different.)


Best regards,
Ben Okopnik

----------
components: Demos and Tools
messages: 134323
nosy: okopnik
priority: normal
severity: normal
status: open
title: pydoc modules/help('modules') crash in dirs with unreadable subdirs
type: crash
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11914>
_______________________________________

From report at bugs.python.org  Sun Apr 24 05:56:22 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Sun, 24 Apr 2011 03:56:22 +0000
Subject: [issue9269] Cannot pickle self-referencing sets
In-Reply-To: <1279234902.88.0.629141543515.issue9269@psf.upfronthosting.co.za>
Message-ID: <1303617382.85.0.36303800061.issue9269@psf.upfronthosting.co.za>


Changes by Alex Gaynor <alex.gaynor at gmail.com>:


----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9269>
_______________________________________

From report at bugs.python.org  Sun Apr 24 07:26:17 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 24 Apr 2011 05:26:17 +0000
Subject: [issue11907] SysLogHandler can't send long messages
In-Reply-To: <1303583088.75.0.884405562286.issue11907@psf.upfronthosting.co.za>
Message-ID: <114237.30014.qm@web25804.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> I'll write a LocalSysLogHandler for me  that uses the syslog module.

Sure, but bear in mind that on some Linux systems at least, the syslog module 
has thread safety issues because the underlying C APIs are not thread-safe. (I'm 
not sure of the situation on FreeBSD.) This shouldn't be a problem if the only 
calls to the module are from the handler, since logging has handler locks - but 
it could be a problem if other code in your process calls syslog APIs directly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11907>
_______________________________________

From report at bugs.python.org  Sun Apr 24 08:18:24 2011
From: report at bugs.python.org (=?utf-8?b?THVrw6HFoSBMYWxpbnNrw70=?=)
Date: Sun, 24 Apr 2011 06:18:24 +0000
Subject: [issue11907] SysLogHandler can't send long messages
In-Reply-To: <1303480338.6.0.255798757577.issue11907@psf.upfronthosting.co.za>
Message-ID: <1303625904.3.0.899578277687.issue11907@psf.upfronthosting.co.za>


Luk?? Lalinsk? <lalinsky at gmail.com> added the comment:

It will be called only from the handler, so I think it should be fine. The reason why I started using syslog was that I need to log into a single file from multiple processes, but it seems to be showing up as too much trouble.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11907>
_______________________________________

From report at bugs.python.org  Sun Apr 24 11:43:44 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Apr 2011 09:43:44 +0000
Subject: [issue3561] Windows installer should add Python and Scripts
	directories to the PATH environment variable
In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za>
Message-ID: <1303638224.15.0.557655456667.issue3561@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Reopening this issue since #9228 was closed as a duplicate of this one. Given the significant level of user demand for this behaviour, it should NOT be closed again until a PEP has been written and either accepted or rejected. If such a PEP is not written and championed through to a final decision, then this issue should remain open indefinitely.

Such a PEP should canvas the option of installing development shell launch scripts into the Start menu and updating the documentation accordingly as an alternative to messing with the system-wide PATH setting.

An install-time option to allow power users to disable the PATH manipulation should also be considered. The interests of novice Python users and experienced Windows system administrators are not in alignment on this topic, and the current installer behaviour favours the latter at the expense of the former.

----------
nosy: +ncoghlan
resolution: wont fix -> 
status: closed -> open
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3561>
_______________________________________

From report at bugs.python.org  Sun Apr 24 11:44:50 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Apr 2011 09:44:50 +0000
Subject: [issue9228] Make changes in the PATH and PATHEXT on installation
In-Reply-To: <1278892287.6.0.671523214632.issue9228@psf.upfronthosting.co.za>
Message-ID: <1303638290.05.0.684863214215.issue9228@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

If it is being requested every few months, then we should reconsider rejecting it. I have now reopened #3561 instead of this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9228>
_______________________________________

From report at bugs.python.org  Sun Apr 24 12:07:25 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Apr 2011 10:07:25 +0000
Subject: [issue3561] Windows installer should add Python and Scripts
	directories to the PATH environment variable
In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za>
Message-ID: <1303639645.51.0.242021909414.issue3561@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Now, another factor to consider is that Windows 7 makes manipulating the system PATH even more difficult to do correctly (e.g. see http://www.symantec.com/connect/forums/wise-7-win-7-problems-updating-environment-variable-current-user).

I believe ActiveState handle this by making the PATH modification optional and having it off by default (I found docs for ActivePerl stating this explicitly, but no equivalent for ActivePython).

Regardless, for a product intended for heavy command line use, we should definitely do better in either providing a way for users to request that the installer modify PATH directly, or else a way to easily launch a command shell with PATH updated appropriately.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3561>
_______________________________________

From report at bugs.python.org  Sun Apr 24 12:25:32 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sun, 24 Apr 2011 10:25:32 +0000
Subject: [issue11912] Python shouldn't use the mprotect() system call
In-Reply-To: <1303601985.39.0.925824346967.issue11912@psf.upfronthosting.co.za>
Message-ID: <1303640732.75.0.0701123932415.issue11912@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

PaX doesn't block mprotect in itself, but prevents pages from being both writable and executable.
Andreas's right, it's probably due to a dlopen of an object requiring executable stack via ctypes.
So you should report this to iotop's developpers. In the meantime, you could use "paxctl -m /usr/bin/python".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11912>
_______________________________________

From report at bugs.python.org  Sun Apr 24 13:25:12 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sun, 24 Apr 2011 11:25:12 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
Message-ID: <1303644312.18.0.70903753797.issue3526@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

S?bastien:
I'm chiming in late, but doesn't AIX have something like LD_PRELOAD?
Why not use it to transparently replace AIX's legacy malloc by another malloc implementation like dlmalloc or ptmalloc?
That would not require any patching of Python, and could also be used for other applications.

As a side note, while mmap has some advantages, it is way slower than brk (because pages must be zero-filled, and since mmap/munmap is called at every malloc/free call, this zero-filling is done every time contrarily to brk pools). See http://sources.redhat.com/ml/libc-alpha/2006-03/msg00033.html

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Sun Apr 24 15:35:21 2011
From: report at bugs.python.org (Rafael Zanella)
Date: Sun, 24 Apr 2011 13:35:21 +0000
Subject: [issue11697] Unsigned type in mmap_move_method
In-Reply-To: <1301260401.14.0.178270138539.issue11697@psf.upfronthosting.co.za>
Message-ID: <1303652121.74.0.690750563013.issue11697@psf.upfronthosting.co.za>


Rafael Zanella <rafael.zanella at yahoo.com.br> added the comment:

Seems like it should use size_t since it deals with memory location/obj size, but Python doesn't have size_t only ssize_t, and ssize_t is signed...

"m.move(2**32, 10, 4)   # Should throw a ValueError" <- Won't it wrap around and become 0 once truncated ?

I've attached a patch that I believe fixes the bounds check, though it's still wrong on the types, since it's not portable.

----------
keywords: +patch
nosy: +zanella
Added file: http://bugs.python.org/file21763/mmap.move.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11697>
_______________________________________

From report at bugs.python.org  Sun Apr 24 16:16:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 24 Apr 2011 14:16:36 +0000
Subject: [issue6780] startswith error message is incomplete
In-Reply-To: <1251149593.57.0.654081758843.issue6780@psf.upfronthosting.co.za>
Message-ID: <1303654596.17.0.223546179392.issue6780@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +needs review
stage: needs patch -> patch review
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6780>
_______________________________________

From report at bugs.python.org  Sun Apr 24 16:20:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Apr 2011 14:20:47 +0000
Subject: [issue11258] ctypes: Speed up find_library() on Linux by 500%
In-Reply-To: <1298217839.35.0.775539629492.issue11258@psf.upfronthosting.co.za>
Message-ID: <1303654847.39.0.0204831595233.issue11258@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11258>
_______________________________________

From report at bugs.python.org  Sun Apr 24 16:54:21 2011
From: report at bugs.python.org (higery)
Date: Sun, 24 Apr 2011 14:54:21 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1303656861.85.0.748458321166.issue828450@psf.upfronthosting.co.za>


Changes by higery <shoulderhigher at gmail.com>:


Added file: http://bugs.python.org/file21764/test_manifest_reading_sdist_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Sun Apr 24 18:07:19 2011
From: report at bugs.python.org (Kasun Herath)
Date: Sun, 24 Apr 2011 16:07:19 +0000
Subject: [issue11882] test_imaplib failed on x86 ubuntu
In-Reply-To: <1303242113.82.0.307299264452.issue11882@psf.upfronthosting.co.za>
Message-ID: <1303661239.31.0.342968276334.issue11882@psf.upfronthosting.co.za>


Kasun Herath <kasunh01 at gmail.com> added the comment:

Yes this is a repeatable error. My timezone is GMT + 5:30.

The test fails even if the last element of 'calendar.timegm's tuple is changed to 0 or 1 but pass if the function is changed as follows

print calendar.timegm((1999, 12, 31, 23, 30, 0, -1, -1, -1))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11882>
_______________________________________

From report at bugs.python.org  Sun Apr 24 18:33:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Apr 2011 16:33:38 +0000
Subject: [issue11882] test_imaplib failed on x86 ubuntu
In-Reply-To: <1303242113.82.0.307299264452.issue11882@psf.upfronthosting.co.za>
Message-ID: <1303662818.29.0.995465301949.issue11882@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11882>
_______________________________________

From report at bugs.python.org  Sun Apr 24 18:59:35 2011
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sun, 24 Apr 2011 16:59:35 +0000
Subject: [issue3561] Windows installer should add Python and Scripts
	directories to the PATH environment variable
In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za>
Message-ID: <1303664375.01.0.41042072947.issue3561@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

> I believe ActiveState handle this by making the PATH modification 
> optional and having it off by default (I found docs for ActivePerl 
> stating this explicitly, but no equivalent for ActivePython).

ActivePython 2.x has it on by default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3561>
_______________________________________

From report at bugs.python.org  Sun Apr 24 19:08:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Apr 2011 17:08:16 +0000
Subject: [issue10914] Python sub-interpreter test
In-Reply-To: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za>
Message-ID: <1303664896.25.0.921280975468.issue10914@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

After wrestling with startup issues on the OS X buildbots, here is a new patch, tested on several different UNIX platforms.

----------
Added file: http://bugs.python.org/file21765/embedtest2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10914>
_______________________________________

From report at bugs.python.org  Sun Apr 24 19:13:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Apr 2011 17:13:27 +0000
Subject: [issue10914] Python sub-interpreter test
In-Reply-To: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za>
Message-ID: <1303665207.3.0.733478336278.issue10914@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Unless someone objects, I would like to commit that latest patch, since at least it enables the start of a regression suite for Python embedding.
(it also allowed me to notice how crufty and incredibly obscure the getpath.c mechanisms are)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10914>
_______________________________________

From report at bugs.python.org  Sun Apr 24 19:30:25 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Apr 2011 17:30:25 +0000
Subject: [issue10914] Python sub-interpreter test
In-Reply-To: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za>
Message-ID: <1303666225.86.0.933909010633.issue10914@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Sounds good. I still have that embedded pickle module issue to deal with, and this should let me actually add a test for it along with the fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10914>
_______________________________________

From report at bugs.python.org  Sun Apr 24 19:33:51 2011
From: report at bugs.python.org (Carl Nobile)
Date: Sun, 24 Apr 2011 17:33:51 +0000
Subject: [issue1346874] httplib simply ignores CONTINUE
Message-ID: <1303666431.79.0.494729555999.issue1346874@psf.upfronthosting.co.za>


Carl Nobile <carl.nobile at gmail.com> added the comment:

I have run into this same issue. It does violate RFC2616 in section 4.3 "All 1xx (informational), 204 (no content), and 304 (not modified) responses MUST NOT include a message-body. All other responses do include a message-body, although it MAY be of zero length."

The embedded while loop is looking for entity data coming back from the server which will never be seen. In my tests the code dies with an exception. I don't see why anything is being done special for a 100 CONTINUE at all. My fix was to eliminate the code previously quoted and replace it with a single line of code so that it would now look like the code snippet below.

   def begin(self):
        if self.msg is not None:
            # we've already started reading the response
            return
        version, status, reason = self._read_status()
        self.status = status
        self.reason = reason.strip()

Note on providing a patch as stated previously.

Having this restriction on providing a patch is a large deterrent to people. I spent a lot of time myself finding the cause of the issues I was having. I don't really have the time to fix tests and documentation also. I understand the reason for asking, but it certainly is a discouragement to helping when bugs are found.

----------
nosy: +Carl.Nobile

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1346874>
_______________________________________

From report at bugs.python.org  Sun Apr 24 20:34:59 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Sun, 24 Apr 2011 18:34:59 +0000
Subject: [issue1062277] Pickle breakage with reduction of recursive structures
Message-ID: <1303670099.73.0.0954674623878.issue1062277@psf.upfronthosting.co.za>


Changes by Alex Gaynor <alex.gaynor at gmail.com>:


----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1062277>
_______________________________________

From report at bugs.python.org  Sun Apr 24 20:38:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Apr 2011 18:38:23 +0000
Subject: [issue11750] Mutualize win32 functions
In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za>
Message-ID: <1303670303.95.0.613194046107.issue11750@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I agree with Amaury that it would be better in Modules. In my experience, code that is in PC/ is a pain to discover.
A couple of nits about the patch:
- the functions in the PyMethodDef array could be sorted alphabetically
- the defint() macro isn't necessary, PyModule_AddIntMacro() should do the trick
- the "_win_handle_object" thing seems misguided, I would vote to remove it, and call CloseHandle() from Python code instead

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11750>
_______________________________________

From report at bugs.python.org  Sun Apr 24 20:39:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Apr 2011 18:39:20 +0000
Subject: [issue11750] Mutualize win32 functions
In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za>
Message-ID: <1303670360.4.0.466270007284.issue11750@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

PS: I don't think there's a problem with the "_windows" name, as long as wxPython doesn't depend on a *toplevel* module named "_windows".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11750>
_______________________________________

From report at bugs.python.org  Sun Apr 24 21:37:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Apr 2011 19:37:39 +0000
Subject: [issue8065] Memory leak in readline.get_current_history_length
In-Reply-To: <1267784862.24.0.455687340788.issue8065@psf.upfronthosting.co.za>
Message-ID: <1303673859.78.0.00264129620464.issue8065@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For the record, I tried Alexander's tests on the buildbots and it failed on OS X Leopard:
http://www.python.org/dev/buildbot/all/builders/AMD64%20Leopard%20custom/builds/12/steps/test/logs/stdio
but succeeded on OS X Tiger:
http://www.python.org/dev/buildbot/all/builders/x86%20Tiger%20custom/builds/18/steps/test/logs/stdio

----------
nosy: +pitrou
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8065>
_______________________________________

From report at bugs.python.org  Sun Apr 24 21:38:16 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 24 Apr 2011 19:38:16 +0000
Subject: [issue11915] test_ctypes hangs in sandbox
In-Reply-To: <1303673896.39.0.0238599913513.issue11915@psf.upfronthosting.co.za>
Message-ID: <1303673896.39.0.0238599913513.issue11915@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

After 19d9f0a177de and 020ebe0be33e, test_ctypes hangs when test suite is run in sandbox. This problem occurs only in Python 3.3.

$ sandbox python3.3 -B -m test.regrtest --timeout=10 -v test_ctypes
== CPython 3.3a0 (default:020ebe0be33e+, Apr 24 2011, 17:52:58) [GCC 4.5.2]
==   Linux-${version}
==   /tmp/test_python_23902
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=1, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0)
[1/1] test_ctypes
Timeout (0:00:10)!
Thread 0x00007fc205f54700:
  File "/usr/lib64/python3.3/subprocess.py", line 466 in _eintr_retry_call
  File "/usr/lib64/python3.3/subprocess.py", line 1412 in _execute_child
  File "/usr/lib64/python3.3/subprocess.py", line 766 in __init__
  File "/usr/lib64/python3.3/ctypes/util.py", line 198 in _findSoname_ldconfig
  File "/usr/lib64/python3.3/ctypes/util.py", line 206 in find_library
  File "/usr/lib64/python3.3/ctypes/test/test_find.py", line 15 in <module>
  File "/usr/lib64/python3.3/ctypes/test/__init__.py", line 64 in get_tests
  File "/usr/lib64/python3.3/test/test_ctypes.py", line 11 in test_main
  File "/usr/lib64/python3.3/test/regrtest.py", line 1094 in runtest_inner
  File "/usr/lib64/python3.3/test/regrtest.py", line 887 in runtest
  File "/usr/lib64/python3.3/test/regrtest.py", line 587 in _runtest
  File "/usr/lib64/python3.3/test/regrtest.py", line 711 in main
  File "/usr/lib64/python3.3/test/regrtest.py", line 1672 in <module>
  File "/usr/lib64/python3.3/runpy.py", line 73 in _run_code
  File "/usr/lib64/python3.3/runpy.py", line 160 in _run_module_as_main

----------
components: ctypes
messages: 134341
nosy: Arfrever, pitrou
priority: normal
severity: normal
status: open
title: test_ctypes hangs in sandbox
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11915>
_______________________________________

From report at bugs.python.org  Sun Apr 24 21:46:56 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 24 Apr 2011 19:46:56 +0000
Subject: [issue11915] test_ctypes hangs in sandbox
In-Reply-To: <1303673896.39.0.0238599913513.issue11915@psf.upfronthosting.co.za>
Message-ID: <1303674416.84.0.313330770059.issue11915@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Reverting of 19d9f0a177de is sufficient to avoid this problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11915>
_______________________________________

From report at bugs.python.org  Sun Apr 24 21:50:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Apr 2011 19:50:48 +0000
Subject: [issue11915] test_ctypes hangs in sandbox
In-Reply-To: <1303673896.39.0.0238599913513.issue11915@psf.upfronthosting.co.za>
Message-ID: <1303674648.95.0.269017863172.issue11915@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

What do you call "sandbox" ?
Also, would be nice if you investigated a bit more about the causes. From the traceback, it looks like the child process is stuck inside exec().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11915>
_______________________________________

From report at bugs.python.org  Sun Apr 24 21:53:17 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 24 Apr 2011 19:53:17 +0000
Subject: [issue11915] test_ctypes hangs in sandbox
In-Reply-To: <1303673896.39.0.0238599913513.issue11915@psf.upfronthosting.co.za>
Message-ID: <1303674797.64.0.799396679918.issue11915@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

wget http://gentoo.osuosl.org/distfiles/sandbox-2.5.tar.xz
tar -xJf sandbox-2.5.tar.xz
cd sandbox-2.5
./configure
make
make install

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11915>
_______________________________________

From report at bugs.python.org  Sun Apr 24 23:18:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 24 Apr 2011 21:18:45 +0000
Subject: [issue11915] test_ctypes hangs in sandbox
In-Reply-To: <1303673896.39.0.0238599913513.issue11915@psf.upfronthosting.co.za>
Message-ID: <1303679925.32.0.10854076126.issue11915@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> http://gentoo.osuosl.org/distfiles/sandbox-2.5.tar.xz

What is this file? Where does it come from?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11915>
_______________________________________

From report at bugs.python.org  Sun Apr 24 23:31:04 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 24 Apr 2011 21:31:04 +0000
Subject: [issue11915] test_ctypes hangs in sandbox
In-Reply-To: <1303673896.39.0.0238599913513.issue11915@psf.upfronthosting.co.za>
Message-ID: <1303680664.59.0.159983069924.issue11915@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

It's a source tarball of sandbox implementation used by default in Gentoo. Sandbox is enabled during building/testing/installation of all packages in Gentoo. Sandbox e.g. disallows write access to directories outside of build directory (even when run by root).

Alternatively you can download sources from git repository:
http://git.overlays.gentoo.org/gitweb/?p=proj/sandbox.git;a=summary

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11915>
_______________________________________

From report at bugs.python.org  Sun Apr 24 23:42:27 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 24 Apr 2011 21:42:27 +0000
Subject: [issue11915] test_ctypes hangs in sandbox
In-Reply-To: <1303673896.39.0.0238599913513.issue11915@psf.upfronthosting.co.za>
Message-ID: <E1QE74T-00015L-Ls@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 2c0da1c4f063 by Victor Stinner in branch 'default':
Issue #11915: threading.RLock()._release_save() raises a RuntimeError if the
http://hg.python.org/cpython/rev/2c0da1c4f063

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11915>
_______________________________________

From report at bugs.python.org  Sun Apr 24 23:43:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 24 Apr 2011 21:43:40 +0000
Subject: [issue11005] Assertion error on RLock._acquire_restore
In-Reply-To: <1295959468.18.0.305168366567.issue11005@psf.upfronthosting.co.za>
Message-ID: <1303681420.92.0.0154747959897.issue11005@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Is the assert still needed?

The assertion is in RLock()._acquire_restore(), not in RLock._release_save(). I prefer to keep it, it doesn't hurt.

 close this issue because I commited my fix.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11005>
_______________________________________

From report at bugs.python.org  Sun Apr 24 23:45:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 24 Apr 2011 21:45:28 +0000
Subject: [issue11005] Assertion error on RLock._acquire_restore
In-Reply-To: <1295959468.18.0.305168366567.issue11005@psf.upfronthosting.co.za>
Message-ID: <E1QE77P-0001IK-Fb@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 996b9c9dc10a by Victor Stinner in branch 'default':
Issue #11005, issue #11915: fix issue number of commit 2c0da1c4f063.
http://hg.python.org/cpython/rev/996b9c9dc10a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11005>
_______________________________________

From report at bugs.python.org  Sun Apr 24 23:45:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 24 Apr 2011 21:45:50 +0000
Subject: [issue11005] Assertion error on RLock._acquire_restore
In-Reply-To: <1295959468.18.0.305168366567.issue11005@psf.upfronthosting.co.za>
Message-ID: <1303681550.39.0.0469550232098.issue11005@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The commit:

New changeset 2c0da1c4f063 by Victor Stinner in branch 'default':
Issue #11915: threading.RLock()._release_save() raises a RuntimeError if the
http://hg.python.org/cpython/rev/2c0da1c4f063

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11005>
_______________________________________

From report at bugs.python.org  Sun Apr 24 23:57:55 2011
From: report at bugs.python.org (Pierre Carrier)
Date: Sun, 24 Apr 2011 21:57:55 +0000
Subject: [issue11916] A few errnos from OSX
In-Reply-To: <1303682275.04.0.607267182641.issue11916@psf.upfronthosting.co.za>
Message-ID: <1303682275.04.0.607267182641.issue11916@psf.upfronthosting.co.za>


New submission from Pierre Carrier <prc at redhat.com>:

A few errnos from OSX are missing in the eponymous module.

--- 8< ---
#ifdef EAUTH
    inscode(d, ds, de, "EAUTH", EAUTH, "Authentication error");
#endif
#ifdef EBADARCH
    inscode(d, ds, de, "EBADARCH", EBADARCH, "Bad CPU type in executable");
#endif
#ifdef EBADEXEC
    inscode(d, ds, de, "EBADEXEC", EBADEXEC, "Bad executable (or shared library)");
#endif
#ifdef EBADMACHO
    inscode(d, ds, de, "EBADMACHO", EBADMACHO, "Malformed Mach-o file");
#endif
#ifdef EBADRPC
    inscode(d, ds, de, "EBADRPC", EBADRPC, "RPC struct is bad");
#endif
#ifdef ECANCELED
    inscode(d, ds, de, "ECANCELED", ECANCELED, "Operation canceled");
#endif
#ifdef EDEVERR
    inscode(d, ds, de, "EDEVERR", EDEVERR, "Device error");
#endif
#ifdef EFTYPE
    inscode(d, ds, de, "EFTYPE", EFTYPE, "Inappropriate file type or format");
#endif
#ifdef ENEEDAUTH
    inscode(d, ds, de, "ENEEDAUTH", ENEEDAUTH, "Need authenticator");
#endif
#ifdef ENOATTR
    inscode(d, ds, de, "ENOATTR", ENOATTR, "Attribute not found");
#endif
#ifdef ENOPOLICY
    inscode(d, ds, de, "ENOPOLICY", ENOPOLICY, "Policy not found");
#endif
#ifdef ENOTSUP
    inscode(d, ds, de, "ENOTSUP", ENOTSUP, "Operation not supported");
#endif
#ifdef EPROCLIM
    inscode(d, ds, de, "EPROCLIM", EPROCLIM, "Too many processes");
#endif
#ifdef EPROCUNAVAIL
    inscode(d, ds, de, "EPROCUNAVAIL", EPROCUNAVAIL, "Bad procedure for program");
#endif
#ifdef EPROGMISMATCH
    inscode(d, ds, de, "EPROGMISMATCH", EPROGMISMATCH, "Program version wrong");
#endif
#ifdef EPROGUNAVAIL
    inscode(d, ds, de, "EPROGUNAVAIL", EPROGUNAVAIL, "RPC prog. not avail");
#endif
#ifdef EPWROFF
    inscode(d, ds, de, "EPWROFF", EPWROFF, "Device power is off");
#endif
#ifdef ERPCMISMATCH
    inscode(d, ds, de, "ERPCMISMATCH", ERPCMISMATCH, "RPC version wrong");
#endif
#ifdef ESHLIBVERS
    inscode(d, ds, de, "ESHLIBVERS", ESHLIBVERS, "Shared library version mismatch");
#endif
--- >8 ---

(PS: catched by scripting around https://github.com/pcarrier/stuff/blob/master/sys/errnos.c if someone wants to play with other "exotic" architectures)

----------
components: Extension Modules
messages: 134351
nosy: pcarrier
priority: normal
severity: normal
status: open
title: A few errnos from OSX
type: feature request
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11916>
_______________________________________

From report at bugs.python.org  Mon Apr 25 00:13:03 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 24 Apr 2011 22:13:03 +0000
Subject: [issue11258] ctypes: Speed up find_library() on Linux by 500%
In-Reply-To: <1298217839.35.0.775539629492.issue11258@psf.upfronthosting.co.za>
Message-ID: <1303683183.71.0.401877629626.issue11258@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

19d9f0a177de causes that test_ctypes hangs when test suite is run in Gentoo sandbox. Please reopen this issue.

$ sandbox python3.3 -B -m test.regrtest --timeout=10 -v test_ctypes
== CPython 3.3a0 (default:020ebe0be33e+, Apr 24 2011, 17:52:58) [GCC 4.5.2]
==   Linux-${version}
==   /tmp/test_python_23902
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=1, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0)
[1/1] test_ctypes
Timeout (0:00:10)!
Thread 0x00007fc205f54700:
  File "/usr/lib64/python3.3/subprocess.py", line 466 in _eintr_retry_call
  File "/usr/lib64/python3.3/subprocess.py", line 1412 in _execute_child
  File "/usr/lib64/python3.3/subprocess.py", line 766 in __init__
  File "/usr/lib64/python3.3/ctypes/util.py", line 198 in _findSoname_ldconfig
  File "/usr/lib64/python3.3/ctypes/util.py", line 206 in find_library
  File "/usr/lib64/python3.3/ctypes/test/test_find.py", line 15 in <module>
  File "/usr/lib64/python3.3/ctypes/test/__init__.py", line 64 in get_tests
  File "/usr/lib64/python3.3/test/test_ctypes.py", line 11 in test_main
  File "/usr/lib64/python3.3/test/regrtest.py", line 1094 in runtest_inner
  File "/usr/lib64/python3.3/test/regrtest.py", line 887 in runtest
  File "/usr/lib64/python3.3/test/regrtest.py", line 587 in _runtest
  File "/usr/lib64/python3.3/test/regrtest.py", line 711 in main
  File "/usr/lib64/python3.3/test/regrtest.py", line 1672 in <module>
  File "/usr/lib64/python3.3/runpy.py", line 73 in _run_code
  File "/usr/lib64/python3.3/runpy.py", line 160 in _run_module_as_main

----------
nosy: +Arfrever, vapier

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11258>
_______________________________________

From report at bugs.python.org  Mon Apr 25 00:15:36 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 24 Apr 2011 22:15:36 +0000
Subject: [issue11915] test_ctypes hangs in sandbox
In-Reply-To: <1303673896.39.0.0238599913513.issue11915@psf.upfronthosting.co.za>
Message-ID: <1303683336.19.0.0365902478065.issue11915@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Moving discussion to issue #11258.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11915>
_______________________________________

From report at bugs.python.org  Mon Apr 25 00:16:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Apr 2011 22:16:08 +0000
Subject: [issue11258] ctypes: Speed up find_library() on Linux by 500%
In-Reply-To: <1303683183.71.0.401877629626.issue11258@psf.upfronthosting.co.za>
Message-ID: <1303683365.3507.11.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> 19d9f0a177de causes that test_ctypes hangs when test suite is run in
> Gentoo sandbox. Please reopen this issue.

I'd prefer having a separate issue (which you already opened :-)).
The fact that all buildbots work fine after the change suggests to me
that the issue is not really the patch I committed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11258>
_______________________________________

From report at bugs.python.org  Mon Apr 25 00:16:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Apr 2011 22:16:30 +0000
Subject: [issue11915] test_ctypes hangs in sandbox
In-Reply-To: <1303673896.39.0.0238599913513.issue11915@psf.upfronthosting.co.za>
Message-ID: <1303683390.26.0.225114695325.issue11915@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution: duplicate -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11915>
_______________________________________

From report at bugs.python.org  Mon Apr 25 00:18:57 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 24 Apr 2011 22:18:57 +0000
Subject: [issue11258] ctypes: Speed up find_library() on Linux by 500%
In-Reply-To: <1298217839.35.0.775539629492.issue11258@psf.upfronthosting.co.za>
Message-ID: <1303683537.91.0.0693752419859.issue11258@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

OK. We will use issue #11915.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11258>
_______________________________________

From report at bugs.python.org  Mon Apr 25 00:19:16 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 24 Apr 2011 22:19:16 +0000
Subject: [issue11915] test_ctypes hangs in sandbox
In-Reply-To: <1303673896.39.0.0238599913513.issue11915@psf.upfronthosting.co.za>
Message-ID: <1303683556.33.0.811075010402.issue11915@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +jonash, vapier

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11915>
_______________________________________

From report at bugs.python.org  Mon Apr 25 00:21:31 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 24 Apr 2011 22:21:31 +0000
Subject: [issue11915] test_ctypes hangs in sandbox
In-Reply-To: <1303673896.39.0.0238599913513.issue11915@psf.upfronthosting.co.za>
Message-ID: <1303683691.53.0.987206300975.issue11915@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

(Revision 2c0da1c4f063 mistakenly refers to this issue. This revision is actually for issue #11005.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11915>
_______________________________________

From report at bugs.python.org  Mon Apr 25 00:39:05 2011
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 24 Apr 2011 22:39:05 +0000
Subject: [issue11846] Remove non-guaranteed implementation details from docs.
In-Reply-To: <1302815567.28.0.789640613127.issue11846@psf.upfronthosting.co.za>
Message-ID: <1303684745.42.0.90591601354.issue11846@psf.upfronthosting.co.za>


Changes by Ned Batchelder <nedbat at users.sourceforge.net>:


----------
nosy: +nedbat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11846>
_______________________________________

From report at bugs.python.org  Mon Apr 25 00:43:04 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 24 Apr 2011 22:43:04 +0000
Subject: [issue11916] A few errnos from OSX
In-Reply-To: <1303682275.04.0.607267182641.issue11916@psf.upfronthosting.co.za>
Message-ID: <1303684984.17.0.0748997795712.issue11916@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions:  -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11916>
_______________________________________

From report at bugs.python.org  Mon Apr 25 00:45:46 2011
From: report at bugs.python.org (Rafael Zanella)
Date: Sun, 24 Apr 2011 22:45:46 +0000
Subject: [issue1490929] urllib.retrieve's reporthook called with non-helpful
	value
Message-ID: <1303685146.15.0.733574185445.issue1490929@psf.upfronthosting.co.za>


Rafael Zanella <azraellzanella at gmail.com> added the comment:

Simple (lazy) test case added.

It just replicates one test case of reporthook to work with progresshook.

The testcases assume the hard-coded value of blocksize on urllib, maybe it should become a public property.

Also commented on diff: http://bugs.python.org/review/1490929/show

----------
nosy: +zanella
Added file: http://bugs.python.org/file21766/test_urllib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1490929>
_______________________________________

From report at bugs.python.org  Mon Apr 25 00:58:45 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sun, 24 Apr 2011 22:58:45 +0000
Subject: [issue11849] ElementTree memory leak
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1303685925.24.0.292984878452.issue11849@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

This is definitely a malloc bug.
Test with default malloc on a Debian box:

cf at neobox:~/cpython$ ./python ../issue11849_test.py 
*** Python 3.3.0 alpha
---   PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
  0  3778 pts/2    S+     0:00      1  1790  8245  7024  0.5 ./python ../issue11849_test.py
  1  3778 pts/2    S+     0:17      1  1790 61937 60404  4.6 ./python ../issue11849_test.py
  2  3778 pts/2    S+     0:35      1  1790 110841 108300  8.3 ./python ../issue11849_test.py
  3  3778 pts/2    S+     0:53      1  1790 159885 158540 12.2 ./python ../issue11849_test.py
  4  3778 pts/2    S+     1:10      1  1790 209369 206724 15.9 ./python ../issue11849_test.py
  5  3778 pts/2    S+     1:28      1  1790 258505 255956 19.7 ./python ../issue11849_test.py
  6  3778 pts/2    S+     1:46      1  1790 307669 304964 23.5 ./python ../issue11849_test.py
  7  3778 pts/2    S+     2:02      1  1790 360705 356952 27.5 ./python ../issue11849_test.py
  8  3778 pts/2    S+     2:21      1  1790 405529 404172 31.2 ./python ../issue11849_test.py
  9  3778 pts/2    S+     2:37      1  1790 458789 456128 35.2 ./python ../issue11849_test.py
END  3778 pts/2    S+     3:00      1  1790 504189 501624 38.7 ./python ../issue11849_test.py
 GC  3778 pts/2    S+     3:01      1  1790 454689 453476 35.0 ./python ../issue11849_test.py
***  3778 pts/2    S+     3:01      1  1790 454689 453480 35.0 ./python ../issue11849_test.py
[56426 refs]


The heap is not trimmed, even after GC collection.
Now, using a smaller mmap threshold so that malloc uses mmap instead of brk:

cf at neobox:~/cpython$ MALLOC_MMAP_THRESHOLD_=1024 ./python ../issue11849_test.py 
*** Python 3.3.0 alpha
---   PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
  0  3843 pts/2    S+     0:00      1  1790  8353  7036  0.5 ./python ../issue11849_test.py
  1  3843 pts/2    S+     0:17      1  1790 62593 59240  4.5 ./python ../issue11849_test.py
  2  3843 pts/2    S+     0:35      1  1790 112321 108304  8.3 ./python ../issue11849_test.py
  3  3843 pts/2    S+     0:53      1  1790 162313 157372 12.1 ./python ../issue11849_test.py
  4  3843 pts/2    S+     1:11      1  1790 212057 206456 15.9 ./python ../issue11849_test.py
  5  3843 pts/2    S+     1:29      1  1790 261749 255484 19.7 ./python ../issue11849_test.py
  6  3843 pts/2    S+     1:47      1  1790 311669 304484 23.5 ./python ../issue11849_test.py
  7  3843 pts/2    S+     2:03      1  1790 365485 356488 27.5 ./python ../issue11849_test.py
  8  3843 pts/2    S+     2:22      1  1790 411341 402568 31.1 ./python ../issue11849_test.py
  9  3843 pts/2    S+     2:38      1  1790 465141 454552 35.1 ./python ../issue11849_test.py
END  3843 pts/2    S+     3:02      1  1790 67173 63892  4.9 ./python ../issue11849_test.py
 GC  3843 pts/2    S+     3:03      1  1790  9925  8664  0.6 ./python ../issue11849_test.py
***  3843 pts/2    S+     3:03      1  1790  9925  8668  0.6 ./python ../issue11849_test.py
[56428 refs]

Just to be sure, with ptmalloc3 malloc implementation:

cf at neobox:~/cpython$ LD_PRELOAD=../ptmalloc3/libptmalloc3.so ./python ../issue11849_test.py 
*** Python 3.3.0 alpha
---   PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
  0  3898 pts/2    S+     0:00      1  1790  8369  7136  0.5 ./python ../issue11849_test.py
  1  3898 pts/2    S+     0:17      1  1790 62825 60264  4.6 ./python ../issue11849_test.py
  2  3898 pts/2    S+     0:34      1  1790 112641 110176  8.5 ./python ../issue11849_test.py
  3  3898 pts/2    S+     0:52      1  1790 162689 160048 12.3 ./python ../issue11849_test.py
  4  3898 pts/2    S+     1:09      1  1790 212285 209732 16.2 ./python ../issue11849_test.py
  5  3898 pts/2    S+     1:27      1  1790 261881 259460 20.0 ./python ../issue11849_test.py
  6  3898 pts/2    S+     1:45      1  1790 311929 309332 23.9 ./python ../issue11849_test.py
  7  3898 pts/2    S+     2:01      1  1790 365625 362004 27.9 ./python ../issue11849_test.py
  8  3898 pts/2    S+     2:19      1  1790 411445 408812 31.5 ./python ../issue11849_test.py
  9  3898 pts/2    S+     2:35      1  1790 465205 461536 35.6 ./python ../issue11849_test.py
END  3898 pts/2    S+     2:58      1  1790 72141 69688  5.3 ./python ../issue11849_test.py
 GC  3898 pts/2    S+     2:59      1  1790 15001 13748  1.0 ./python ../issue11849_test.py
***  3898 pts/2    S+     2:59      1  1790 15001 13752  1.0 ./python ../issue11849_test.py
[56428 refs]

So the problem is really that glibc/eglibc malloc implementations don't automatically trim memory upon free (this happens if you're only allocating/deallocating small chunks < 64B that come from fastbins, but that's not the case here).
By the way, I noticed that dictionnaries are never allocated through pymalloc, since a new dictionnary takes more than 256B...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Mon Apr 25 01:20:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Apr 2011 23:20:06 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1303687206.78.0.703904628306.issue11849@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The MALLOC_MMAP_THRESHOLD improvement is less visible here:

$ MALLOC_MMAP_THRESHOLD_=1024 ../opt/python issue11849_test.py 
*** Python 3.3.0 alpha
--- USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
  0 antoine   7703  0.0  0.1  57756  8560 pts/2    S+   01:16   0:00 ../opt/python issue11849_test.py
  1 antoine   7703 62.0  1.0 138892 86100 pts/2    S+   01:16   0:01 ../opt/python issue11849_test.py
  2 antoine   7703 84.6  2.0 213580 160552 pts/2   S+   01:16   0:02 ../opt/python issue11849_test.py
  3 antoine   7703 97.0  2.9 288080 234972 pts/2   S+   01:16   0:03 ../opt/python issue11849_test.py
  4 antoine   7703 85.6  3.9 362852 309408 pts/2   S+   01:16   0:05 ../opt/python issue11849_test.py
  5 antoine   7703 93.4  4.8 437616 383844 pts/2   S+   01:16   0:06 ../opt/python issue11849_test.py
  6 antoine   7703 99.0  5.7 512380 458276 pts/2   S+   01:16   0:07 ../opt/python issue11849_test.py
  7 antoine   7703 89.6  6.7 591360 535672 pts/2   S+   01:16   0:08 ../opt/python issue11849_test.py
  8 antoine   7703 94.9  7.6 661676 607156 pts/2   S+   01:16   0:10 ../opt/python issue11849_test.py
  9 antoine   7703 95.5  8.6 740652 684556 pts/2   S+   01:16   0:11 ../opt/python issue11849_test.py
END antoine   7703 96.1  7.5 650432 597736 pts/2   S+   01:16   0:13 ../opt/python issue11849_test.py
 GC antoine   7703 97.2  6.5 570316 519228 pts/2   S+   01:16   0:13 ../opt/python issue11849_test.py
*** antoine   7703 90.8  6.5 569876 518792 pts/2   S+   01:16   0:13 ../opt/python issue11849_test.py


By the way, an easy fix is to use cElementTree instead of ElementTree. It still won't release all memory but it will eat a lot less of it, and be much faster as well.

----------
title: ElementTree memory leak -> glibc allocator doesn't release all free()ed memory
versions: +Python 3.3 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Mon Apr 25 01:22:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Apr 2011 23:22:18 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1303687338.05.0.893242047962.issue11849@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> By the way, I noticed that dictionnaries are never allocated through
> pymalloc, since a new dictionnary takes more than 256B...

On 64-bit builds indeed. pymalloc could be improved to handle allocations up to 512B. Want to try and write a patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Mon Apr 25 01:49:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Apr 2011 23:49:59 +0000
Subject: [issue11916] A few errnos from OSX
In-Reply-To: <1303682275.04.0.607267182641.issue11916@psf.upfronthosting.co.za>
Message-ID: <1303688999.18.0.409369333554.issue11916@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> ronaldoussoren
components: +Library (Lib), Macintosh -Extension Modules
nosy: +ned.deily, ronaldoussoren
stage:  -> patch review
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11916>
_______________________________________

From report at bugs.python.org  Mon Apr 25 03:06:06 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Apr 2011 01:06:06 +0000
Subject: [issue8809] smtplib should support SSL contexts
In-Reply-To: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>
Message-ID: <1303693566.32.0.399501386632.issue8809@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8809>
_______________________________________

From report at bugs.python.org  Mon Apr 25 03:06:58 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Apr 2011 01:06:58 +0000
Subject: [issue8808] imaplib should support SSL contexts
In-Reply-To: <1274717637.39.0.0073929793702.issue8808@psf.upfronthosting.co.za>
Message-ID: <1303693618.83.0.654900002635.issue8808@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8808>
_______________________________________

From report at bugs.python.org  Mon Apr 25 03:08:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Apr 2011 01:08:16 +0000
Subject: [issue11915] test_ctypes hangs in sandbox
In-Reply-To: <1303673896.39.0.0238599913513.issue11915@psf.upfronthosting.co.za>
Message-ID: <1303693696.23.0.680044501579.issue11915@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue comes from sandbox, not from ctypes.

Using sandbox, execv() C function doesn't close files with FD_CLOEXEC flag if the child program is a static program.

test_ctypes hangs on find_library() in subprocess.Popen._execute_child():
 - create a pipe for the child exception (if any)
 - fork
 - the parent reads this pipe
 - the child calls exec()
 - exec() closes the pipe and the parent continues its work
 - etc.

find_library() runs "ldconfig -p" in a subprocess, and so everything hangs on "the parent reads this pipe" because "exec() closes the pipe and the parent continues its work" doesn't occur.

----------
Added file: http://bugs.python.org/file21767/sandbox_exec_bug.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11915>
_______________________________________

From report at bugs.python.org  Mon Apr 25 03:09:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Apr 2011 01:09:59 +0000
Subject: [issue11915] test_ctypes hangs in sandbox
In-Reply-To: <1303673896.39.0.0238599913513.issue11915@psf.upfronthosting.co.za>
Message-ID: <1303693799.89.0.823991089847.issue11915@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

If you would like to reproduce sandbox bug:

gcc sandbox_exec_bug.c -o sandbox_exec_bug
gcc -static static.c -o static
sandbox ./sandbox_exec_bug

The bug doesn't occur if static.c is not compiled with -static.

Note: I don't know if "sandbox ./sandbox_exec_bug" is the right command to run ./sandbox_exec_bug in the sandbox, I used directly LD_PRELOAD.

----------
Added file: http://bugs.python.org/file21768/static.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11915>
_______________________________________

From report at bugs.python.org  Mon Apr 25 03:10:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Apr 2011 01:10:49 +0000
Subject: [issue11915] test_ctypes hangs in sandbox
In-Reply-To: <1303673896.39.0.0238599913513.issue11915@psf.upfronthosting.co.za>
Message-ID: <1303693849.95.0.291682084948.issue11915@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I close this issue because it is not a Python. I will try to open an issue in Gentoo bugtracker, but now I am too tired to do that :-)

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11915>
_______________________________________

From report at bugs.python.org  Mon Apr 25 03:18:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Apr 2011 01:18:41 +0000
Subject: [issue11915] test_ctypes hangs in sandbox
In-Reply-To: <1303673896.39.0.0238599913513.issue11915@psf.upfronthosting.co.za>
Message-ID: <1303694321.09.0.66664545224.issue11915@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

If the child program is static, sandbox protects it using a tracing mechanism (based on ptrace with PTRACE_SYSCALL). Output is debug mode:

trace_main tracing: ./static
TRACE (pid=10377):trace_main: parent waiting for child (pid=10378) to signal
TRACE (pid=10378):trace_main: child setting up ...
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGSTOP(19)
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGCONT(18)
TRACE (pid=10377):trace_loop: >IDK:62TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
(...pre-exec...) = ...
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
TRACE (pid=10377):trace_loop: >IDK:11TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
(...pre-exec...) = ...
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
TRACE (pid=10377):trace_loop: >IDK:3TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
(...pre-exec...) = ...
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 0
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 0
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = -1 (errno: 38: Function not implemented)
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 0
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = -1 (errno: 38: Function not implemented)
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 36896768
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = -1 (errno: 38: Function not implemented)
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 36901248
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = -1 (errno: 38: Function not implemented)
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 0
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = -1 (errno: 38: Function not implemented)
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 37036416
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = -1 (errno: 38: Function not implemented)
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 37040128
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = -1 (errno: 38: Function not implemented)
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 1264893952
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = -1 (errno: 38: Function not implemented)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11915>
_______________________________________

From report at bugs.python.org  Mon Apr 25 03:47:50 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Apr 2011 01:47:50 +0000
Subject: [issue11895] pybench prep_times calculation error
In-Reply-To: <1303356013.22.0.66518331753.issue11895@psf.upfronthosting.co.za>
Message-ID: <E1QEAtw-0006Qw-Vi@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset e4fcfb8066ff by Jesus Cea in branch '2.7':
pybench prep_times calculation error (closes #11895)
http://hg.python.org/cpython/rev/e4fcfb8066ff

New changeset 7569870a8236 by Jesus Cea in branch '3.1':
pybench prep_times calculation error (closes #11895)
http://hg.python.org/cpython/rev/7569870a8236

New changeset 66ef5e844e6c by Jesus Cea in branch '3.2':
pybench prep_times calculation error (closes #11895)
http://hg.python.org/cpython/rev/66ef5e844e6c

New changeset 8a277949d904 by Jesus Cea in branch 'default':
pybench prep_times calculation error (closes #11895)
http://hg.python.org/cpython/rev/8a277949d904

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11895>
_______________________________________

From report at bugs.python.org  Mon Apr 25 03:47:50 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Apr 2011 01:47:50 +0000
Subject: [issue9319] imp.find_module('test/badsyntax_pep3120') causes segfault
In-Reply-To: <1279693765.46.0.777254335316.issue9319@psf.upfronthosting.co.za>
Message-ID: <E1QEAtw-0006Qw-W2@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset bb62908896fe by Jesus Cea in branch 'default':
Correctly merging #9319 into 3.3?
http://hg.python.org/cpython/rev/bb62908896fe

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9319>
_______________________________________

From report at bugs.python.org  Mon Apr 25 03:49:42 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Apr 2011 01:49:42 +0000
Subject: [issue9319] imp.find_module('test/badsyntax_pep3120') causes segfault
In-Reply-To: <1279693765.46.0.777254335316.issue9319@psf.upfronthosting.co.za>
Message-ID: <1303696182.43.0.957563431474.issue9319@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9319>
_______________________________________

From report at bugs.python.org  Mon Apr 25 03:51:17 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Apr 2011 01:51:17 +0000
Subject: [issue11895] pybench prep_times calculation error
In-Reply-To: <1303356013.22.0.66518331753.issue11895@psf.upfronthosting.co.za>
Message-ID: <1303696277.23.0.834843582478.issue11895@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea
resolution: fixed -> 
stage: committed/rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11895>
_______________________________________

From report at bugs.python.org  Mon Apr 25 04:12:00 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Apr 2011 02:12:00 +0000
Subject: [issue11901] Docs for sys.hexversion should give the algorithm
In-Reply-To: <1303410263.92.0.721904855375.issue11901@psf.upfronthosting.co.za>
Message-ID: <1303697520.49.0.747184149766.issue11901@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

+1!.

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11901>
_______________________________________

From report at bugs.python.org  Mon Apr 25 04:18:33 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Apr 2011 02:18:33 +0000
Subject: [issue11910] test_heapq C tests are not skipped when _heapq is missing
In-Reply-To: <1303524259.87.0.426176819457.issue11910@psf.upfronthosting.co.za>
Message-ID: <1303697913.89.0.0818948056934.issue11910@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Patch seems good. Ezio, can you commit?.

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11910>
_______________________________________

From report at bugs.python.org  Mon Apr 25 04:22:57 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Apr 2011 02:22:57 +0000
Subject: [issue11912] Python shouldn't use the mprotect() system call
In-Reply-To: <1303601985.39.0.925824346967.issue11912@psf.upfronthosting.co.za>
Message-ID: <1303698177.15.0.122388553911.issue11912@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11912>
_______________________________________

From report at bugs.python.org  Mon Apr 25 04:30:42 2011
From: report at bugs.python.org (Matt Goodman)
Date: Mon, 25 Apr 2011 02:30:42 +0000
Subject: [issue8426] multiprocessing.Queue fails to get() very large objects
In-Reply-To: <1271443086.56.0.51527518355.issue8426@psf.upfronthosting.co.za>
Message-ID: <1303698642.98.0.280733489962.issue8426@psf.upfronthosting.co.za>


Matt Goodman <meawoppl at gmail.com> added the comment:

You can not pickle individual objects larger than 2**31.  This failure is not handled cleanly in the core module, and I suspect masked by above processes. 

Try piping "a"*(2**31) through you pipe, or pickling it to disk . . .

----------
nosy: +Matt.Goodman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8426>
_______________________________________

From report at bugs.python.org  Mon Apr 25 04:57:43 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 25 Apr 2011 02:57:43 +0000
Subject: [issue10616] Change PyObject_AsCharBuffer() error message
In-Reply-To: <1291394615.71.0.46026990965.issue10616@psf.upfronthosting.co.za>
Message-ID: <1303700263.82.0.239452025974.issue10616@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10616>
_______________________________________

From report at bugs.python.org  Mon Apr 25 04:58:53 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 25 Apr 2011 02:58:53 +0000
Subject: [issue6780] startswith error message is incomplete
In-Reply-To: <1251149593.57.0.654081758843.issue6780@psf.upfronthosting.co.za>
Message-ID: <1303700333.24.0.425667438163.issue6780@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6780>
_______________________________________

From report at bugs.python.org  Mon Apr 25 07:03:49 2011
From: report at bugs.python.org (Buck Golemon)
Date: Mon, 25 Apr 2011 05:03:49 +0000
Subject: [issue8326] Cannot import name SemLock on Ubuntu
In-Reply-To: <1270549791.67.0.929964356468.issue8326@psf.upfronthosting.co.za>
Message-ID: <1303707829.02.0.628516929112.issue8326@psf.upfronthosting.co.za>


Buck Golemon <buck.golemon at amd.com> added the comment:

python2.7.1+ from mercurial supports sem_open (and multiprocessing) just fine.

doko: Could you help us figure out why the ubuntu 10.10 python2.7 build has this issue? I believe this issue should be assigned to you?

Relevant lines from the config.log:


configure:9566: checking for sem_open
configure:9566: gcc -pthread -o conftest -g -O2   conftest.c -lpthread -ldl  >&5
configure:9566: $? = 0
configure:9566: result: yes

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8326>
_______________________________________

From report at bugs.python.org  Mon Apr 25 08:24:39 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 25 Apr 2011 06:24:39 +0000
Subject: [issue8040] It would be nice if documentation pages linked to other
	versions of the same document
In-Reply-To: <1267543845.91.0.112810116218.issue8040@psf.upfronthosting.co.za>
Message-ID: <1303712679.42.0.542193194387.issue8040@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8040>
_______________________________________

From report at bugs.python.org  Mon Apr 25 08:34:40 2011
From: report at bugs.python.org (ysj.ray)
Date: Mon, 25 Apr 2011 06:34:40 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1303713280.03.0.207469400173.issue9523@psf.upfronthosting.co.za>


ysj.ray <ysj.ray at gmail.com> added the comment:

Sorry, previous patch(issue_9523_4.diff) missed a file(Lib/test/dbm_tests.py)
Here is an intact one.

----------
Added file: http://bugs.python.org/file21769/issue_9523_5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9523>
_______________________________________

From report at bugs.python.org  Mon Apr 25 09:09:14 2011
From: report at bugs.python.org (ysj.ray)
Date: Mon, 25 Apr 2011 07:09:14 +0000
Subject: [issue11908] Weird `slice.stop or sys.maxint`
In-Reply-To: <1303493846.17.0.214651551769.issue11908@psf.upfronthosting.co.za>
Message-ID: <1303715354.76.0.469654613413.issue11908@psf.upfronthosting.co.za>


ysj.ray <ysj.ray at gmail.com> added the comment:

`step` argument for xrange() could not be 0.

But `s.stop or sys.maxint` is really a problem, in the case of `s.stop == 0`.

So the given `Equivalent to` python code in the doc is not precisely equivalent to the c implementation. The doc needs a fix.

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11908>
_______________________________________

From report at bugs.python.org  Mon Apr 25 09:47:40 2011
From: report at bugs.python.org (Nils Breunese)
Date: Mon, 25 Apr 2011 07:47:40 +0000
Subject: [issue11912] Python shouldn't use the mprotect() system call
In-Reply-To: <1303601985.39.0.925824346967.issue11912@psf.upfronthosting.co.za>
Message-ID: <1303717660.47.0.335775290451.issue11912@psf.upfronthosting.co.za>


Nils Breunese <nils at breun.nl> added the comment:

I contacted the author of iotop and he told me iotop does not use mprotect (but it does use dlopen).

Guess I'll have to do some more digging to find what is exactly doing the call to mprotect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11912>
_______________________________________

From report at bugs.python.org  Mon Apr 25 09:51:05 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 25 Apr 2011 07:51:05 +0000
Subject: [issue11908] Weird `slice.stop or sys.maxint`
In-Reply-To: <1303493846.17.0.214651551769.issue11908@psf.upfronthosting.co.za>
Message-ID: <1303717865.59.0.442954527882.issue11908@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I've got from here.  Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11908>
_______________________________________

From report at bugs.python.org  Mon Apr 25 10:01:33 2011
From: report at bugs.python.org (kaifeng)
Date: Mon, 25 Apr 2011 08:01:33 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1303718493.1.0.475643832984.issue11849@psf.upfronthosting.co.za>


kaifeng <cafeeee at gmail.com> added the comment:

Sorry for the later update.

Valgrind shows there is no memory leak (see attached valgrind.log).

The following code,
    while True:
        XML(gen_xml())
has an increasing memory usage in the first 5~8 iterations, and waves around a constant level afterwards.

So I guess there's a component, maybe libc, Python interpreter, ElementTree/pyexpat module or someone else, hold some memory until process ends.

----------
Added file: http://bugs.python.org/file21770/valgrind.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Mon Apr 25 10:17:47 2011
From: report at bugs.python.org (ysj.ray)
Date: Mon, 25 Apr 2011 08:17:47 +0000
Subject: [issue11882] test_imaplib failed on x86 ubuntu
In-Reply-To: <1303242113.82.0.307299264452.issue11882@psf.upfronthosting.co.za>
Message-ID: <1303719467.15.0.999349278492.issue11882@psf.upfronthosting.co.za>


ysj.ray <ysj.ray at gmail.com> added the comment:

Guess the problem is with time.mktime() and time.localtime(). Could you  debug into the Internaldate2Tuple() function and see at which step the time value(a time_struct or a float which represents seconds) is wrong?

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11882>
_______________________________________

From report at bugs.python.org  Mon Apr 25 12:45:10 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Apr 2011 10:45:10 +0000
Subject: [issue11662] Redirect vulnerability in urllib/urllib2
In-Reply-To: <1300979217.98.0.998462672739.issue11662@psf.upfronthosting.co.za>
Message-ID: <1303728310.36.0.86624043404.issue11662@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11662>
_______________________________________

From report at bugs.python.org  Mon Apr 25 12:51:56 2011
From: report at bugs.python.org (Jonathan Hartley)
Date: Mon, 25 Apr 2011 10:51:56 +0000
Subject: [issue3561] Windows installer should add Python and Scripts
	directories to the PATH environment variable
In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za>
Message-ID: <1303728716.43.0.935101384211.issue3561@psf.upfronthosting.co.za>


Changes by Jonathan Hartley <tartley at tartley.com>:


----------
nosy: +jonathan.hartley

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3561>
_______________________________________

From report at bugs.python.org  Mon Apr 25 13:08:42 2011
From: report at bugs.python.org (Hamid)
Date: Mon, 25 Apr 2011 11:08:42 +0000
Subject: [issue11917] Test Error
In-Reply-To: <1303729722.53.0.730816268009.issue11917@psf.upfronthosting.co.za>
Message-ID: <1303729722.53.0.730816268009.issue11917@psf.upfronthosting.co.za>


New submission from Hamid <abbaszadeh.h at gmail.com>:

== CPython 3.2 (r32:88445, Apr 24 2011, 14:27:42) [GCC 4.4.4 20100726 (Red Hat 4.4.4-13)]
==   Linux-2.6.32-71.el6.x86_64-x86_64-with-redhat-6.0-Santiago little-endian
==   /usr/local/src/Python-3.2/build/test_python_2976
Testing with flags: sys.flags(debug=0, division_warning=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0)
[1/1] test_whatever
test test_whatever crashed -- <class 'ImportError'>: No module named test_whatever
Traceback (most recent call last):
  File "/usr/local/src/Python-3.2/Lib/test/regrtest.py", line 962, in runtest_inner
    the_package = __import__(abstest, globals(), locals(), [])
ImportError: No module named test_whatever
1 test failed:
    test_whatever

----------
components: Tests
messages: 134377
nosy: Abbaszadeh
priority: normal
severity: normal
status: open
title: Test Error
type: compile error
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11917>
_______________________________________

From report at bugs.python.org  Mon Apr 25 13:21:26 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Apr 2011 11:21:26 +0000
Subject: [issue11856] Optimize parsing of JSON numbers
In-Reply-To: <1302956362.08.0.216789404235.issue11856@psf.upfronthosting.co.za>
Message-ID: <1303730486.24.0.597454173161.issue11856@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Patch seems OK. Please, commit.

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11856>
_______________________________________

From report at bugs.python.org  Mon Apr 25 13:39:10 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 25 Apr 2011 11:39:10 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <1303212938.57.0.821096700769.issue11877@psf.upfronthosting.co.za>
Message-ID: <20110425113859.GA38742@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

I'll attach 11877.4.diff:

- Docu change (i hope to be better)
- Kept NetBSD after looking into
    http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/vfs_syscalls.c?rev=1.423&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
  because fsync_range() with FDISKSYNC set causes a FSYNC_CACHE
  flag to be passed through to VOP_FSYNC() in addition to
  FSYNC_WAIT, which is what plain fsync() passes exclusively.
  (I have not furtherly discovered that.  FDISKSYNC was introduced
  2005.  I believe existence of such a flag will sooner or later
  force somebody to make a difference in wether it is set or not.)
- Drop of AIX.  According to the systems manual (link in
  msg134213) there does not seem to be a difference in between
  fsync() and fsync_range()
- Drop of Linux sync_file_range() (see messages above).
  By the way, does Linux still require

----------
Added file: http://bugs.python.org/file21771/11877.4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________
-------------- next part --------------
diff --git a/Doc/library/os.rst b/Doc/library/os.rst
--- a/Doc/library/os.rst
+++ b/Doc/library/os.rst
@@ -798,7 +798,7 @@
    Availability: Unix.
 
 
-.. function:: fsync(fd)
+.. function:: fsync(fd, full_fsync=False)
 
    Force write of file with filedescriptor *fd* to disk.  On Unix, this calls the
    native :c:func:`fsync` function; on Windows, the MS :c:func:`_commit` function.
@@ -807,6 +807,12 @@
    ``f.flush()``, and then do ``os.fsync(f.fileno())``, to ensure that all internal
    buffers associated with *f* are written to disk.
 
+   The POSIX standart only requires that :c:func:`fsync` must transfer the
+   buffered data to the storage device, not that the data is actually
+   written by the device itself.  On operating systems where it is
+   necessary and possible the optional *full_fsync* argument can be used to
+   initiate additional steps to synchronize the physical backing store.
+
    Availability: Unix, and Windows.
 
 
diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -2119,13 +2119,55 @@
 
 #ifdef HAVE_FSYNC
 PyDoc_STRVAR(posix_fsync__doc__,
-"fsync(fildes)\n\n\
-force write of file with filedescriptor to disk.");
-
-static PyObject *
-posix_fsync(PyObject *self, PyObject *fdobj)
-{
-    return posix_fildes(fdobj, fsync);
+"fsync(fildes, full_fsync=False)\n\n"
+"force write of file buffers with fildes to disk;\n"
+"full_fsync forces flush of disk caches in case fsync() alone is not enough.");
+
+static PyObject *
+posix_fsync(PyObject *self, PyObject *args, PyObject *kwargs)
+{
+    PyObject *retval = NULL;
+    auto PyObject *fdobj;
+    auto int full_fsync = 1;
+    static char *keywords[] = {"fd", "full_fsync", NULL };
+
+    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "O|i", keywords,
+                                     &fdobj, &full_fsync))
+        goto jleave;
+
+    /* See issue 11877 discussion */
+# if ((defined __APPLE__ && defined F_FULLFSYNC) || \
+      (defined __NetBSD__ && defined FDISKSYNC))
+    if (full_fsync != 0) {
+        int res, fd = PyObject_AsFileDescriptor(fdobj);
+        if (fd < 0)
+            goto jleave;
+        if (!_PyVerify_fd(fd)) {
+            retval = posix_error();
+            goto jleave;
+        }
+
+        Py_BEGIN_ALLOW_THREADS
+#  ifdef __APPLE__
+        res = fcntl(fd, F_FULLFSYNC);
+#  endif
+#  ifdef __NetBSD__
+        res = fsync_range(fd, FFILESYNC|FDISKSYNC, 0, 0);
+#  endif
+        Py_END_ALLOW_THREADS
+
+        if (res < 0) {
+            retval = posix_error();
+            goto jleave;
+        }
+        Py_INCREF(Py_None);
+        retval = Py_None;
+    } else
+# endif
+        retval = posix_fildes(fdobj, fsync);
+
+jleave:
+    return retval;
 }
 #endif /* HAVE_FSYNC */
 
@@ -9470,7 +9512,8 @@
     {"fchdir",          posix_fchdir, METH_O, posix_fchdir__doc__},
 #endif
 #ifdef HAVE_FSYNC
-    {"fsync",       posix_fsync, METH_O, posix_fsync__doc__},
+    {"fsync",           (PyCFunction)posix_fsync, METH_VARARGS|METH_KEYWORDS,
+                        posix_fsync__doc__},
 #endif
 #ifdef HAVE_SYNC
     {"sync",        posix_sync, METH_NOARGS, posix_sync__doc__},

From report at bugs.python.org  Mon Apr 25 13:49:20 2011
From: report at bugs.python.org (Hamid)
Date: Mon, 25 Apr 2011 11:49:20 +0000
Subject: [issue11917] Test Error
In-Reply-To: <1303729722.53.0.730816268009.issue11917@psf.upfronthosting.co.za>
Message-ID: <1303732160.07.0.238544496662.issue11917@psf.upfronthosting.co.za>


Changes by Hamid <abbaszadeh.h at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11917>
_______________________________________

From report at bugs.python.org  Mon Apr 25 14:36:05 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Mon, 25 Apr 2011 12:36:05 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1303718493.1.0.475643832984.issue11849@psf.upfronthosting.co.za>
Message-ID: <BANLkTimFzWwMwtDtmY3TnMj=w=_B6i83SQ@mail.gmail.com>


Charles-Francois Natali <neologix at free.fr> added the comment:

> The MALLOC_MMAP_THRESHOLD improvement is less visible here:
>

Are you running on 64-bit ?
If yes, it could be that you're exhausting M_MMAP_MAX (malloc falls
back to brk when there are too many mmap mappings).
You could try with
MALLOC_MMAP_THRESHOLD_=1024 MALLOC_MMAP_MAX_=16777216 ../opt/python
issue11849_test.py

By the way, never do that in real life, it's a CPU and memory hog ;-)

I think the root cause is that glibc's malloc coalescing of free
chunks is called far less often than in the original ptmalloc version,
but I still have to dig some more.

>> By the way, I noticed that dictionnaries are never allocated through
>> pymalloc, since a new dictionnary takes more than 256B...
>
> On 64-bit builds indeed. pymalloc could be improved to handle allocations up
> to 512B. Want to try and write a patch?

Sure.
I'll open another issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Mon Apr 25 15:55:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Apr 2011 13:55:45 +0000
Subject: [issue9319] imp.find_module('test/badsyntax_pep3120') causes segfault
In-Reply-To: <1279693765.46.0.777254335316.issue9319@psf.upfronthosting.co.za>
Message-ID: <1303739745.06.0.994172978215.issue9319@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Correctly merging #9319 into 3.3?

No, this issue was fixed differently in Python 3.3. I see that you reverted (bb62908896fe) this merge (except the test, which is a good idea).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9319>
_______________________________________

From report at bugs.python.org  Mon Apr 25 16:00:35 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 25 Apr 2011 14:00:35 +0000
Subject: [issue11882] test_imaplib failed on x86 ubuntu
In-Reply-To: <1303242113.82.0.307299264452.issue11882@psf.upfronthosting.co.za>
Message-ID: <1303740035.6.0.393421814671.issue11882@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yeah, I looked at the source of calendar.gmtime, and it turns out it ignores the isdst flag, which it also seems should be irrelevant anyway, looking at the test code again.

I tried setting my /etc/localtime to /usr/share/zoneinfo/posix/Asia/Calcutta, which gives me IST/GMT +5:30, but test_imaplib still passes for me on default.

Here is what an interpreter session looks like for me with my timezone set to IST:

>>> import calendar
>>> calendar.timegm((2000, 1, 1, 0, 0, 0, -1, -1, -1))
946684800
>>> import imaplib
>>> x = imaplib.Internaldate2tuple(b'25 (INTERNALDATE "01-Jan-2000 00:00:00 +0000")')
>>> x
time.struct_time(tm_year=2000, tm_mon=1, tm_mday=1, tm_hour=5, tm_min=30, tm_sec=0, tm_wday=5, tm_yday=1, tm_isdst=0)
>>> import time
>>> time.mktime(x)
946684800.0

Can you show us what yours looks like?  Comparing the above numbers to
yours, it appears to be your mktime that is giving the anomalous results.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11882>
_______________________________________

From report at bugs.python.org  Mon Apr 25 16:06:54 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 25 Apr 2011 14:06:54 +0000
Subject: [issue11917] Test Error
In-Reply-To: <1303729722.53.0.730816268009.issue11917@psf.upfronthosting.co.za>
Message-ID: <1303740414.87.0.298255622407.issue11917@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

For the record: yes this is the way regrtest works when a test named on the command line doesn't exist. Not pretty, I'll grant you.  Maybe someone will propose a patch/feature request to improve the error message some day.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11917>
_______________________________________

From report at bugs.python.org  Mon Apr 25 16:21:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Apr 2011 14:21:45 +0000
Subject: [issue11918] Drop OS/2 and VMS support in Python 3.3
In-Reply-To: <1303741305.45.0.808920067617.issue11918@psf.upfronthosting.co.za>
Message-ID: <1303741305.45.0.808920067617.issue11918@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Because we don't have any OS/2 and VMS maintainer for Python 3, I propose to drop OS/2 and VMS support in Python 3.3: OSes unsupported in 3.3, code removed in 3.4 (see the PEP 11 for the process).

----------
components: Interpreter Core
messages: 134384
nosy: haypo
priority: normal
severity: normal
status: open
title: Drop OS/2 and VMS support in Python 3.3
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11918>
_______________________________________

From report at bugs.python.org  Mon Apr 25 16:46:37 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 25 Apr 2011 14:46:37 +0000
Subject: [issue8326] Cannot import name SemLock on Ubuntu
In-Reply-To: <1270549791.67.0.929964356468.issue8326@psf.upfronthosting.co.za>
Message-ID: <1303742797.96.0.913673324923.issue8326@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Is this still a problem for people?  Ubuntu 11.04's python2.7 has been fixed:

@neurotica[~:1000]% type python2.7
python2.7 is /usr/bin/python2.7
@neurotica[~:1001]% python2.7 -c 'from _multiprocessing import SemLock'
@neurotica[~:1002]% 

The Launchpad bug for the issue is here:

https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/672209

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8326>
_______________________________________

From report at bugs.python.org  Mon Apr 25 16:50:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Apr 2011 14:50:45 +0000
Subject: [issue10616] Change PyObject_AsCharBuffer() error message
In-Reply-To: <1291394615.71.0.46026990965.issue10616@psf.upfronthosting.co.za>
Message-ID: <1303743045.23.0.0663059988965.issue10616@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

+1 to Victor's proposal ("expected bytes, bytearray or buffer compatible object").

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10616>
_______________________________________

From report at bugs.python.org  Mon Apr 25 16:54:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Apr 2011 14:54:22 +0000
Subject: [issue11919] test_imp failures
In-Reply-To: <1303743262.64.0.49678573377.issue11919@psf.upfronthosting.co.za>
Message-ID: <1303743262.64.0.49678573377.issue11919@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

http://www.python.org/dev/buildbot/all/builders/AMD64%20Leopard%203.2/builds/215/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/AMD64%20Leopard%203.x/builds/1223/steps/test/logs/stdio

======================================================================
ERROR: test_issue9319 (test.test_imp.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/pythonbuildbot/buildarea/3.2.hansen-osx-x86-2/build/Lib/test/test_imp.py", line 175, in test_issue9319
    imp.find_module, "test/badsyntax_pep3120")
  File "/Users/pythonbuildbot/buildarea/3.2.hansen-osx-x86-2/build/Lib/unittest/case.py", line 574, in assertRaises
    callableObj(*args, **kwargs)
ImportError: No module named test/badsyntax_pep3120

----------
assignee: haypo
components: Tests
messages: 134387
nosy: haypo, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: test_imp failures
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11919>
_______________________________________

From report at bugs.python.org  Mon Apr 25 16:55:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Apr 2011 14:55:17 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <BANLkTimFzWwMwtDtmY3TnMj=w=_B6i83SQ@mail.gmail.com>
Message-ID: <1303743309.3537.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > The MALLOC_MMAP_THRESHOLD improvement is less visible here:
> >
> 
> Are you running on 64-bit ?

Yes.

> If yes, it could be that you're exhausting M_MMAP_MAX (malloc falls
> back to brk when there are too many mmap mappings).
> You could try with
> MALLOC_MMAP_THRESHOLD_=1024 MALLOC_MMAP_MAX_=16777216 ../opt/python
> issue11849_test.py

It isn't better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Mon Apr 25 16:57:15 2011
From: report at bugs.python.org (Hamid)
Date: Mon, 25 Apr 2011 14:57:15 +0000
Subject: [issue11917] Test Error
In-Reply-To: <1303740414.87.0.298255622407.issue11917@psf.upfronthosting.co.za>
Message-ID: <BANLkTimMip07uUdTSFbbg+yhk-UGcFBG0g@mail.gmail.com>


Hamid <abbaszadeh.h at gmail.com> added the comment:

Dear sir;

I will try to compile python-3.2 in REDHAT EL 6.0. There are a lot of
failure in "make test". How can I fix them?

for example test_import, test_httpserver, ....

Thanks
Abbaszadeh

On Mon, Apr 25, 2011 at 6:36 PM, R. David Murray <report at bugs.python.org>wrote:

>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> For the record: yes this is the way regrtest works when a test named on the
> command line doesn't exist. Not pretty, I'll grant you.  Maybe someone will
> propose a patch/feature request to improve the error message some day.
>
> ----------
> nosy: +r.david.murray
> resolution:  -> invalid
> stage:  -> committed/rejected
> type: compile error -> behavior
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue11917>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file21772/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11917>
_______________________________________
-------------- next part --------------
<div dir="ltr"><font size="2"><font face="tahoma,sans-serif">Dear sir;<br><br>I will try to compile python-3.2 in REDHAT EL 6.0. There are a lot of failure in &quot;make test&quot;. How can I fix them?<br><br>for example test_import, test_httpserver, ....<br>

<br>Thanks<br>Abbaszadeh<br></font></font><br><div class="gmail_quote">On Mon, Apr 25, 2011 at 6:36 PM, R. David Murray <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="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><br>
R. David Murray &lt;<a href="mailto:rdmurray at bitdance.com">rdmurray at bitdance.com</a>&gt; added the comment:<br>
<br>
For the record: yes this is the way regrtest works when a test named on the command line doesn&#39;t exist. Not pretty, I&#39;ll grant you. ??Maybe someone will propose a patch/feature request to improve the error message some day.<br>


<br>
----------<br>
nosy: +r.david.murray<br>
resolution: ??-&gt; invalid<br>
stage: ??-&gt; committed/rejected<br>
type: compile error -&gt; behavior<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/issue11917" target="_blank">http://bugs.python.org/issue11917</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><b><i>Hamid Abbaszadeh</i></b><br>website: <a href="http://www.respinar.com" target="_blank">www.respinar.com</a><br>email: <a href="mailto:info at respinar.com" target="_blank">info at respinar.com</a><br>

</div><br>
</div>

From report at bugs.python.org  Mon Apr 25 17:17:08 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Mon, 25 Apr 2011 15:17:08 +0000
Subject: [issue10616] Change PyObject_AsCharBuffer() error message
In-Reply-To: <1291394615.71.0.46026990965.issue10616@psf.upfronthosting.co.za>
Message-ID: <1303744628.5.0.973136616399.issue10616@psf.upfronthosting.co.za>


Sijin Joseph <sijinjoseph at gmail.com> added the comment:

Looking at object.h the buffer interface is defined as 

/* buffer interface */
typedef struct bufferinfo {
    void *buf;
    PyObject *obj;        /* owned reference */
    Py_ssize_t len;
    Py_ssize_t itemsize;  /* This is Py_ssize_t so it can be
                             pointed to by strides in simple case.*/
    int readonly;
    int ndim;
    char *format;
    Py_ssize_t *shape;
    Py_ssize_t *strides;
    Py_ssize_t *suboffsets;
    Py_ssize_t smalltable[2];  /* static store for shape and strides of
                                  mono-dimensional buffers. */
    void *internal;
} Py_buffer;

typedef int (*getbufferproc)(PyObject *, Py_buffer *, int);
typedef void (*releasebufferproc)(PyObject *, Py_buffer *);

typedef struct {
     getbufferproc bf_getbuffer;
     releasebufferproc bf_releasebuffer;
} PyBufferProcs;

The code that's throwing that error looks like

if (pb == NULL || pb->bf_getbuffer == NULL) {
        PyErr_SetString(PyExc_TypeError,
                        "expected an object with the buffer interface");

I would argue that the error message gives appropriate information because it is expecting the object to have a bf_getbuffer member.

Maybe the friendly error message is best handled at a higher level?

----------
nosy: +sijinjoseph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10616>
_______________________________________

From report at bugs.python.org  Mon Apr 25 17:34:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 25 Apr 2011 15:34:01 +0000
Subject: [issue11917] Test Error
In-Reply-To: <1303729722.53.0.730816268009.issue11917@psf.upfronthosting.co.za>
Message-ID: <1303745641.71.0.356360879176.issue11917@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Your best resources would probably be the python mailing list (python-list, see http://mail.python.org) which is also comp.lang.python, or the #python irc channel on freenode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11917>
_______________________________________

From report at bugs.python.org  Mon Apr 25 17:57:10 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Mon, 25 Apr 2011 15:57:10 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1303747030.31.0.895832936836.issue11849@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> It isn't better.

Requests above 256B are directly handled by malloc, so MALLOC_MMAP_THRESHOLD_ should in fact be set to 256 (with 1024 I guess that on 64-bit every mid-sized dictionnary gets allocated with brk).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Mon Apr 25 18:52:56 2011
From: report at bugs.python.org (Steve Thompson)
Date: Mon, 25 Apr 2011 16:52:56 +0000
Subject: [issue11920] ctypes: Strange bitfield structure sizing issue
In-Reply-To: <1303750376.54.0.894731507231.issue11920@psf.upfronthosting.co.za>
Message-ID: <1303750376.54.0.894731507231.issue11920@psf.upfronthosting.co.za>


New submission from Steve Thompson <steve.f.thompson at gmail.com>:

Consider the following:
import ctypes

class struct1( ctypes.Structure ):
    _pack_ = 1
    _fields_ =  [
                    ( "first",  ctypes.c_uint8,  1  ),
                    ( "second", ctypes.c_uint8,  1  ),
                    ( "third",  ctypes.c_uint8,  1  ),
                    ( "fourth", ctypes.c_uint8,  1  ),
                    ( "fifth",  ctypes.c_uint8,  1  ),
                    ( "pad",    ctypes.c_uint16, 11 ),
                ]
                
s1 = struct1()
print ctypes.sizeof( s1 )

class struct2( ctypes.Structure ):
    _pack_ = 1
    _fields_ =  [
                    ( "first",  ctypes.c_uint16, 1  ),
                    ( "second", ctypes.c_uint16, 1  ),
                    ( "third",  ctypes.c_uint16, 1  ),
                    ( "fourth", ctypes.c_uint16, 1  ),
                    ( "fifth",  ctypes.c_uint16, 1  ),
                    ( "pad",    ctypes.c_uint16, 11 ),
                ]
                
s2 = struct2()
print ctypes.sizeof( s2 )

The output is:
3
2

I'm generating python code from real c code.  The compiler I'm using for the real c code packs both of these structures into two bytes.  I need a way to make the first example work in python like the compiler without having to modify the source code.

Is this possible?

----------
components: ctypes
messages: 134393
nosy: Steve.Thompson
priority: normal
severity: normal
status: open
title: ctypes: Strange bitfield structure sizing issue
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11920>
_______________________________________

From report at bugs.python.org  Mon Apr 25 18:56:37 2011
From: report at bugs.python.org (dholth)
Date: Mon, 25 Apr 2011 16:56:37 +0000
Subject: [issue11921] distutils2 should be able to compile an Extension based
	on the Python implementation version
In-Reply-To: <1303750597.71.0.868083563179.issue11921@psf.upfronthosting.co.za>
Message-ID: <1303750597.71.0.868083563179.issue11921@psf.upfronthosting.co.za>


New submission from dholth <dholth at fastmail.fm>:

It might be useful to be able to declare optional Extensions that for example won't attempt to compile on Jython or any implementation of Python for which the extension (a) doesn't work or (b) would be slower than the Python fallback.

I suppose this could be accomplished without changing anything by packaging the extension separately and using the extant "; plat=win32" style dependency qualifiers?

----------
assignee: tarek
components: Distutils2
messages: 134394
nosy: alexis, dholth, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: distutils2 should be able to compile an Extension based on the Python implementation version
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11921>
_______________________________________

From report at bugs.python.org  Mon Apr 25 19:01:35 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Apr 2011 17:01:35 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <E1QEPAE-0001vM-2P@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset b55eac85e39c by Alexander Belopolsky in branch 'default':
Issue #2736: Documented how to compute seconds since epoch.
http://hg.python.org/cpython/rev/b55eac85e39c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Mon Apr 25 19:03:30 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 25 Apr 2011 17:03:30 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1303751010.23.0.011401526523.issue2736@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
components: +Documentation -Library (Lib)
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Mon Apr 25 19:07:50 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Apr 2011 17:07:50 +0000
Subject: [issue11918] Drop OS/2 and VMS support in Python 3.3
In-Reply-To: <1303741305.45.0.808920067617.issue11918@psf.upfronthosting.co.za>
Message-ID: <1303751270.86.0.438392751586.issue11918@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11918>
_______________________________________

From report at bugs.python.org  Mon Apr 25 19:16:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Apr 2011 17:16:21 +0000
Subject: [issue11856] Optimize parsing of JSON numbers
In-Reply-To: <1302956362.08.0.216789404235.issue11856@psf.upfronthosting.co.za>
Message-ID: <E1QEPOV-000384-DZ@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d60f9d9983bb by Antoine Pitrou in branch 'default':
Issue #11856: Speed up parsing of JSON numbers.
http://hg.python.org/cpython/rev/d60f9d9983bb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11856>
_______________________________________

From report at bugs.python.org  Mon Apr 25 19:16:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Apr 2011 17:16:39 +0000
Subject: [issue11856] Optimize parsing of JSON numbers
In-Reply-To: <1302956362.08.0.216789404235.issue11856@psf.upfronthosting.co.za>
Message-ID: <1303751799.65.0.398777364619.issue11856@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/issue11856>
_______________________________________

From report at bugs.python.org  Mon Apr 25 19:16:50 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 25 Apr 2011 17:16:50 +0000
Subject: [issue11918] Drop OS/2 and VMS support in Python 3.3
In-Reply-To: <1303741305.45.0.808920067617.issue11918@psf.upfronthosting.co.za>
Message-ID: <1303751810.77.0.226083444348.issue11918@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11918>
_______________________________________

From report at bugs.python.org  Mon Apr 25 19:19:46 2011
From: report at bugs.python.org (Bryce Verdier)
Date: Mon, 25 Apr 2011 17:19:46 +0000
Subject: [issue11834] wrong module installation dir on Windows
In-Reply-To: <1302605256.31.0.234550103785.issue11834@psf.upfronthosting.co.za>
Message-ID: <1303751986.59.0.0404852483118.issue11834@psf.upfronthosting.co.za>


Bryce Verdier <bryceverdier at gmail.com> added the comment:

Here is a patch for the documentation. I'm not quite sure about the scripts and data part. Tested with Paramiko and a new install of 2.7 to see what would happen and that was the result.

----------
keywords: +patch
nosy: +louiscipher
Added file: http://bugs.python.org/file21773/issue133572.py33.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11834>
_______________________________________

From report at bugs.python.org  Mon Apr 25 19:21:47 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 25 Apr 2011 17:21:47 +0000
Subject: [issue11922] Add General Index to Windows .chm help file Contents
In-Reply-To: <1303752107.55.0.594682028964.issue11922@psf.upfronthosting.co.za>
Message-ID: <1303752107.55.0.594682028964.issue11922@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

The Windows distribution comes with the docs in a very nice Windows help file .chm form. When displayed, they is a left side bar with a Contents tab. The top entry is 'Python vx.y documentation' followed by 'Python Module Index' and 'What's New in Python' and so on down to 'History and Licence'. Everything on the "Python vx.y documentation' page is listed in the Contents EXCEPT the General Index. Consequently, if one only uses the contents lists, one might not even know it exists. In any case, it is harder to get to than anything else.

I presume the omission is unintentional. In any case, I would like to see it fixed, with 'General Index' added right after the module index entry. I presume this should be easy for someone who knows how the contents list is generated.

----------
assignee: docs at python
components: Documentation, Windows
keywords: easy
messages: 134398
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Add General Index to Windows .chm help file Contents
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11922>
_______________________________________

From report at bugs.python.org  Mon Apr 25 20:04:08 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Mon, 25 Apr 2011 18:04:08 +0000
Subject: [issue11901] Docs for sys.hexversion should give the algorithm
In-Reply-To: <1303410263.92.0.721904855375.issue11901@psf.upfronthosting.co.za>
Message-ID: <1303754648.34.0.219879530833.issue11901@psf.upfronthosting.co.za>


Sijin Joseph <sijinjoseph at gmail.com> added the comment:

Patch attached.

----------
keywords: +patch
nosy: +sijinjoseph
Added file: http://bugs.python.org/file21774/11901.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11901>
_______________________________________

From report at bugs.python.org  Mon Apr 25 20:06:16 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Mon, 25 Apr 2011 18:06:16 +0000
Subject: [issue11901] Docs for sys.hexversion should give the algorithm
In-Reply-To: <1303410263.92.0.721904855375.issue11901@psf.upfronthosting.co.za>
Message-ID: <1303754776.91.0.617129757744.issue11901@psf.upfronthosting.co.za>


Changes by Sijin Joseph <sijinjoseph at gmail.com>:


Removed file: http://bugs.python.org/file21774/11901.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11901>
_______________________________________

From report at bugs.python.org  Mon Apr 25 20:06:46 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Mon, 25 Apr 2011 18:06:46 +0000
Subject: [issue11901] Docs for sys.hexversion should give the algorithm
In-Reply-To: <1303410263.92.0.721904855375.issue11901@psf.upfronthosting.co.za>
Message-ID: <1303754806.33.0.628544092427.issue11901@psf.upfronthosting.co.za>


Sijin Joseph <sijinjoseph at gmail.com> added the comment:

Fixed minor typo.

----------
Added file: http://bugs.python.org/file21775/11901.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11901>
_______________________________________

From report at bugs.python.org  Mon Apr 25 20:10:51 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 25 Apr 2011 18:10:51 +0000
Subject: [issue11908] Weird `slice.stop or sys.maxint`
In-Reply-To: <1303493846.17.0.214651551769.issue11908@psf.upfronthosting.co.za>
Message-ID: <1303755051.1.0.0618991430147.issue11908@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.5, Python 2.6, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11908>
_______________________________________

From report at bugs.python.org  Mon Apr 25 20:18:07 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 25 Apr 2011 18:18:07 +0000
Subject: [issue11920] ctypes: Strange bitfield structure sizing issue
In-Reply-To: <1303750376.54.0.894731507231.issue11920@psf.upfronthosting.co.za>
Message-ID: <1303755487.79.0.303455450494.issue11920@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11920>
_______________________________________

From report at bugs.python.org  Mon Apr 25 20:45:59 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 25 Apr 2011 18:45:59 +0000
Subject: [issue11846] Remove non-guaranteed implementation details from docs.
In-Reply-To: <1302815567.28.0.789640613127.issue11846@psf.upfronthosting.co.za>
Message-ID: <1303757159.56.0.644157720301.issue11846@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The range of interned ints was once much smaller, but it was expanded upwards to 256 so that the bytes extracted from bytes and bytearray objects, as when indexing or iterating, would *all* be pre-allocated objects. I should presume that their indexers and iterators are cognizant of this and take advantage of this to bypass int() creation and directly index into the the array of preallocated ints without a range check.

As for space and some time saving, just on startup,
a nearly fresh IDLE shell shows

>>> sum((sys.getrefcount(i) for i in range(-5, 257)))
4432

There are hundreds of references for each of 0 and 1.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11846>
_______________________________________

From report at bugs.python.org  Mon Apr 25 20:57:44 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 25 Apr 2011 18:57:44 +0000
Subject: [issue11920] ctypes: Strange bitfield structure sizing issue
In-Reply-To: <1303750376.54.0.894731507231.issue11920@psf.upfronthosting.co.za>
Message-ID: <1303757864.36.0.484041283971.issue11920@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The output is: "3 2" on windows. It is "2 2" on the linux 64bit I tried.
This is consistent with what the usual compilers do on these platforms: MSVC on windows, and gcc on linux.

The specification of the C language specifies that """If an adjacent bitfield will not fit into the remainder of the unit, the implementation defines whether bitfields are allowed to span units or whether another unit is allocated for the second bitfield"""

Are you using gcc on windows? In this case I suggest to always use the largest type to declare the bitfields.

----------
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file21776/bitfields.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11920>
_______________________________________

From report at bugs.python.org  Mon Apr 25 21:02:09 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 25 Apr 2011 19:02:09 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1303758129.53.0.18702127559.issue11849@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/issue11849>
_______________________________________

From report at bugs.python.org  Mon Apr 25 21:02:44 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 25 Apr 2011 19:02:44 +0000
Subject: [issue1346874] httplib simply ignores CONTINUE
Message-ID: <1303758164.1.0.709046372734.issue1346874@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Carl, anyone is free to submit an incomplete patch, and people often do, but if people who are affected by an issue do not think it worth their time to complete it, or even move it along, there is no reason to expect people who are not affected by it to think so either. All of us volunteers are busy doing whatever it is we do.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1346874>
_______________________________________

From report at bugs.python.org  Mon Apr 25 21:23:42 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Apr 2011 19:23:42 +0000
Subject: [issue10914] Python sub-interpreter test
In-Reply-To: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za>
Message-ID: <E1QERNk-0005aN-Fp@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d195ff5c44f4 by Antoine Pitrou in branch '3.2':
Issue #10914: Add a minimal embedding test to test_capi.
http://hg.python.org/cpython/rev/d195ff5c44f4

New changeset 77cf9e4b144b by Antoine Pitrou in branch '3.2':
Issue #10914: add NEWS item.
http://hg.python.org/cpython/rev/77cf9e4b144b

New changeset ef1ad39e3c40 by Antoine Pitrou in branch 'default':
Issue #10914: Add a minimal embedding test to test_capi.
http://hg.python.org/cpython/rev/ef1ad39e3c40

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10914>
_______________________________________

From report at bugs.python.org  Mon Apr 25 21:25:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Apr 2011 19:25:05 +0000
Subject: [issue10914] Python sub-interpreter test
In-Reply-To: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za>
Message-ID: <1303759505.32.0.373499043892.issue10914@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Should be fixed.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10914>
_______________________________________

From report at bugs.python.org  Mon Apr 25 21:34:57 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 25 Apr 2011 19:34:57 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1303760097.61.0.252329704769.issue1943@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I just found that the extension zope.i18nmessageid: http://pypi.python.org/pypi/zope.i18nmessageid subclasses unicode at the C level:
http://svn.zope.org/zope.i18nmessageid/trunk/src/zope/i18nmessageid/_zope_i18nmessageid_message.c?rev=120914&view=markup

Notably, the Message structure is defined this way:
typedef struct {
  PyUnicodeObject base;
  PyObject *domain;
  PyObject *default_;
  PyObject *mapping;
} Message;

How would such an extension type behave after the patch? Is there a workaround we can propose?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1943>
_______________________________________

From report at bugs.python.org  Mon Apr 25 21:40:09 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Apr 2011 19:40:09 +0000
Subject: [issue11919] test_imp failures
In-Reply-To: <1303743262.64.0.49678573377.issue11919@psf.upfronthosting.co.za>
Message-ID: <E1QERdb-000725-A9@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 2f2c7eb27437 by Antoine Pitrou in branch '3.2':
Issue #11919: try to fix test_imp failure on some buildbots.
http://hg.python.org/cpython/rev/2f2c7eb27437

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11919>
_______________________________________

From report at bugs.python.org  Mon Apr 25 21:46:10 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Apr 2011 19:46:10 +0000
Subject: [issue11919] test_imp failures
In-Reply-To: <1303743262.64.0.49678573377.issue11919@psf.upfronthosting.co.za>
Message-ID: <E1QERjU-0007hK-Pn@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0c70c24750fd by Antoine Pitrou in branch 'default':
Issue #11919: try to fix test_imp failure on some buildbots.
http://hg.python.org/cpython/rev/0c70c24750fd

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11919>
_______________________________________

From report at bugs.python.org  Mon Apr 25 21:49:34 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 25 Apr 2011 19:49:34 +0000
Subject: [issue11920] ctypes: Strange bitfield structure sizing issue
In-Reply-To: <1303750376.54.0.894731507231.issue11920@psf.upfronthosting.co.za>
Message-ID: <1303760974.06.0.721393925879.issue11920@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

What compilers were used to build your Python distro and the native structure?

I found out in _ctypes/cfield.c (lns. 76-95):

    if (bitsize /* this is a bitfield request */
        && *pfield_size /* we have a bitfield open */
#ifdef MS_WIN32
        /* MSVC, GCC with -mms-bitfields */
        && dict->size * 8 == *pfield_size
#else
        /* GCC */
        && dict->size * 8 <= *pfield_size
#endif
        && (*pbitofs + bitsize) <= *pfield_size) {
        /* continue bit field */
        fieldtype = CONT_BITFIELD;
#ifndef MS_WIN32
    } else if (bitsize /* this is a bitfield request */
        && *pfield_size /* we have a bitfield open */
        && dict->size * 8 >= *pfield_size
        && (*pbitofs + bitsize) <= dict->size * 8) {
        /* expand bit field */
        fieldtype = EXPAND_BITFIELD;
#endif

So the allocation of the extra byte for the structure seems to depend on Python's compiler. To make sure, I compiled a native structure using MSVC:

#pragma pack(1)
typedef struct _struct1
{
    UINT8 first   : 1;
    UINT8 second  : 1;
    UINT8 third   : 1;
    UINT8 fourth  : 1;
    UINT8 fifth   : 1;
    UINT16 pad    : 11;
} struct1;

And I got the same value (sizeof == 3).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11920>
_______________________________________

From report at bugs.python.org  Mon Apr 25 22:02:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Apr 2011 20:02:26 +0000
Subject: [issue11918] Drop OS/2 and VMS support in Python 3.3
In-Reply-To: <1303741305.45.0.808920067617.issue11918@psf.upfronthosting.co.za>
Message-ID: <1303761746.66.0.173456695866.issue11918@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11918>
_______________________________________

From report at bugs.python.org  Mon Apr 25 22:07:14 2011
From: report at bugs.python.org (Paul Griffith)
Date: Mon, 25 Apr 2011 20:07:14 +0000
Subject: [issue11923] gcc: unrecognized option '-n32'
In-Reply-To: <1303762034.43.0.96724336471.issue11923@psf.upfronthosting.co.za>
Message-ID: <1303762034.43.0.96724336471.issue11923@psf.upfronthosting.co.za>


New submission from Paul Griffith <paulg at cse.yorku.ca>:

In compiling Python 2.7.1 on RHEL I run into the following error message when running make.

gcc: unrecognized option '-n32'
gcc -pthread -n32  -Xlinker -export-dynamic -o python \
			Modules/python.o \
			-L. -lpython2.7 -lpthread -ldl  -lutil   -lm  
gcc: unrecognized option '-n32'
running build
running build_ext


Configured with:

./configure --prefix=/cs/local --enable-shared --libdir=/cs/local/lib64 --with-gcc=yes

GCC:

 # gcc --version
gcc (GCC) 4.4.4 20100726 (Red Hat 4.4.4-13)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I checked the bug tracker, but I only thing I see related deals with IRIX.

----------
components: Build
messages: 134410
nosy: paulg_ca
priority: normal
severity: normal
status: open
title: gcc: unrecognized option '-n32'
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11923>
_______________________________________

From report at bugs.python.org  Mon Apr 25 22:15:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Apr 2011 20:15:02 +0000
Subject: [issue11901] Docs for sys.hexversion should give the algorithm
In-Reply-To: <1303410263.92.0.721904855375.issue11901@psf.upfronthosting.co.za>
Message-ID: <E1QESBP-0001bs-36@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 48758cd0769b by R David Murray in branch '2.7':
#11901: add description of how bitfields are laid out to hexversion docs
http://hg.python.org/cpython/rev/48758cd0769b

New changeset b84384fbdbf0 by R David Murray in branch '3.1':
#11901: add description of how bitfields are laid out to hexversion docs
http://hg.python.org/cpython/rev/b84384fbdbf0

New changeset cca4c92bf337 by R David Murray in branch '3.2':
Merge #11901: add description of how bitfields are laid out to hexversion docs
http://hg.python.org/cpython/rev/cca4c92bf337

New changeset 07149918bce1 by R David Murray in branch 'default':
Merge #11901: add description of how bitfields are laid out to hexversion docs
http://hg.python.org/cpython/rev/07149918bce1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11901>
_______________________________________

From report at bugs.python.org  Mon Apr 25 22:19:36 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 25 Apr 2011 20:19:36 +0000
Subject: [issue11901] Docs for sys.hexversion should give the algorithm
In-Reply-To: <1303410263.92.0.721904855375.issue11901@psf.upfronthosting.co.za>
Message-ID: <1303762776.03.0.805739847133.issue11901@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks!  I tidied up the ReST formatting a bit and changed the bit numbering to the more standard left to right order (standard for bit fields...I realize hexversion is a number, but conceptually one deals with it as a bit field).

----------
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11901>
_______________________________________

From report at bugs.python.org  Mon Apr 25 23:05:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Apr 2011 21:05:54 +0000
Subject: [issue11919] test_imp failures
In-Reply-To: <1303743262.64.0.49678573377.issue11919@psf.upfronthosting.co.za>
Message-ID: <1303765554.75.0.365816839747.issue11919@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11919>
_______________________________________

From report at bugs.python.org  Mon Apr 25 23:06:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Apr 2011 21:06:29 +0000
Subject: [issue10914] Python sub-interpreter test
In-Reply-To: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za>
Message-ID: <1303765589.52.0.189616520644.issue10914@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There's a failure on certain locales that Victor, I believe, is currently investigating.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10914>
_______________________________________

From report at bugs.python.org  Mon Apr 25 23:21:58 2011
From: report at bugs.python.org (Steve Thompson)
Date: Mon, 25 Apr 2011 21:21:58 +0000
Subject: [issue11920] ctypes: Strange bitfield structure sizing issue
In-Reply-To: <1303760974.06.0.721393925879.issue11920@psf.upfronthosting.co.za>
Message-ID: <BANLkTinn4zhSsHEFd0bitLhPNOUSEhWxyw@mail.gmail.com>


Steve Thompson <steve.f.thompson at gmail.com> added the comment:

So, knowing there's a potential cross platform inconsistency here, is there
a proposed way to deal with this that doesn't involve modifying the real c
code I'm interfacing with?  That's not always an option.

On Mon, Apr 25, 2011 at 2:49 PM, Santoso Wijaya <report at bugs.python.org>wrote:

>
> Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:
>
> What compilers were used to build your Python distro and the native
> structure?
>
> I found out in _ctypes/cfield.c (lns. 76-95):
>
>    if (bitsize /* this is a bitfield request */
>        && *pfield_size /* we have a bitfield open */
> #ifdef MS_WIN32
>        /* MSVC, GCC with -mms-bitfields */
>        && dict->size * 8 == *pfield_size
> #else
>        /* GCC */
>        && dict->size * 8 <= *pfield_size
> #endif
>        && (*pbitofs + bitsize) <= *pfield_size) {
>        /* continue bit field */
>        fieldtype = CONT_BITFIELD;
> #ifndef MS_WIN32
>    } else if (bitsize /* this is a bitfield request */
>        && *pfield_size /* we have a bitfield open */
>        && dict->size * 8 >= *pfield_size
>        && (*pbitofs + bitsize) <= dict->size * 8) {
>        /* expand bit field */
>        fieldtype = EXPAND_BITFIELD;
> #endif
>
> So the allocation of the extra byte for the structure seems to depend on
> Python's compiler. To make sure, I compiled a native structure using MSVC:
>
> #pragma pack(1)
> typedef struct _struct1
> {
>    UINT8 first   : 1;
>    UINT8 second  : 1;
>    UINT8 third   : 1;
>    UINT8 fourth  : 1;
>    UINT8 fifth   : 1;
>    UINT16 pad    : 11;
> } struct1;
>
> And I got the same value (sizeof == 3).
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue11920>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file21777/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11920>
_______________________________________
-------------- next part --------------
So, knowing there&#39;s a potential cross platform inconsistency here, is there a proposed way to deal with this that doesn&#39;t involve modifying the real c code I&#39;m interfacing with? ??That&#39;s not always an option.<br>
<br><div class="gmail_quote">On Mon, Apr 25, 2011 at 2:49 PM, Santoso Wijaya <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="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Santoso Wijaya &lt;<a href="mailto:santoso.wijaya at gmail.com">santoso.wijaya at gmail.com</a>&gt; added the comment:<br>
<br>
What compilers were used to build your Python distro and the native structure?<br>
<br>
I found out in _ctypes/cfield.c (lns. 76-95):<br>
<br>
 ?? ??if (bitsize /* this is a bitfield request */<br>
 ?? ?? ?? ??&amp;&amp; *pfield_size /* we have a bitfield open */<br>
#ifdef MS_WIN32<br>
 ?? ?? ?? ??/* MSVC, GCC with -mms-bitfields */<br>
 ?? ?? ?? ??&amp;&amp; dict-&gt;size * 8 == *pfield_size<br>
#else<br>
 ?? ?? ?? ??/* GCC */<br>
 ?? ?? ?? ??&amp;&amp; dict-&gt;size * 8 &lt;= *pfield_size<br>
#endif<br>
 ?? ?? ?? ??&amp;&amp; (*pbitofs + bitsize) &lt;= *pfield_size) {<br>
 ?? ?? ?? ??/* continue bit field */<br>
 ?? ?? ?? ??fieldtype = CONT_BITFIELD;<br>
#ifndef MS_WIN32<br>
 ?? ??} else if (bitsize /* this is a bitfield request */<br>
 ?? ?? ?? ??&amp;&amp; *pfield_size /* we have a bitfield open */<br>
 ?? ?? ?? ??&amp;&amp; dict-&gt;size * 8 &gt;= *pfield_size<br>
 ?? ?? ?? ??&amp;&amp; (*pbitofs + bitsize) &lt;= dict-&gt;size * 8) {<br>
 ?? ?? ?? ??/* expand bit field */<br>
 ?? ?? ?? ??fieldtype = EXPAND_BITFIELD;<br>
#endif<br>
<br>
So the allocation of the extra byte for the structure seems to depend on Python&#39;s compiler. To make sure, I compiled a native structure using MSVC:<br>
<br>
#pragma pack(1)<br>
typedef struct _struct1<br>
{<br>
 ?? ??UINT8 first ?? : 1;<br>
 ?? ??UINT8 second ??: 1;<br>
 ?? ??UINT8 third ?? : 1;<br>
 ?? ??UINT8 fourth ??: 1;<br>
 ?? ??UINT8 fifth ?? : 1;<br>
 ?? ??UINT16 pad ?? ??: 11;<br>
} struct1;<br>
<br>
And I got the same value (sizeof == 3).<br>
<br>
----------<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/issue11920" target="_blank">http://bugs.python.org/issue11920</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Mon Apr 25 23:24:07 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Mon, 25 Apr 2011 21:24:07 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1303766647.3.0.893629842394.issue10517@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> So, if it is possible to fix this and remove this weird special case and cast it into the abyss, then by all means, you have my 10 thumbs up.  Not that it counts for much :)

Me too.
We still have a couple hundred RHEL4/5 boxes at work, and I guess we're not alone in this case. It's a really specific case, but I think it would be nice to fix it, especially since it also makes the code more understandable and less error-prone. Unless of course this special treatment is really necessary, in which case I'll have to think of another solution or just drop it.
I'm adding Antoine to the noisy list, since he's noted as thread expert in the Experts Index.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Mon Apr 25 23:27:43 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Apr 2011 21:27:43 +0000
Subject: [issue11924] Pickle and copyreg modules doesn't document the interface
In-Reply-To: <1303766863.75.0.154822649898.issue11924@psf.upfronthosting.co.za>
Message-ID: <1303766863.75.0.154822649898.issue11924@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

Python 3.2 here.

"copyreg" module documentation says "See the pickle module for more details on the interface expected of function and constructor.", but I don't see any useful "copyreg" reference in pickle documentation.

Some examples would be useful here, too.

----------
assignee: docs at python
messages: 134416
nosy: docs at python, jcea
priority: normal
severity: normal
status: open
title: Pickle and copyreg modules doesn't document the interface
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11924>
_______________________________________

From report at bugs.python.org  Mon Apr 25 23:28:24 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Apr 2011 21:28:24 +0000
Subject: [issue11924] Pickle and copyreg modules don't document the interface
In-Reply-To: <1303766863.75.0.154822649898.issue11924@psf.upfronthosting.co.za>
Message-ID: <1303766904.49.0.895742176177.issue11924@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
title: Pickle and copyreg modules doesn't document the interface -> Pickle and copyreg modules don't document the interface

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11924>
_______________________________________

From report at bugs.python.org  Mon Apr 25 23:28:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Apr 2011 21:28:56 +0000
Subject: [issue10914] Python sub-interpreter test
In-Reply-To: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za>
Message-ID: <1303766936.91.0.748736513625.issue10914@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Modules/_testembed fails with ISO-8859-15 locale encoding because of a bootstrap issue. The problem is that the filesystem encoding codec is implemented in Python: Python requires the codec to loads modules, but it has to load a module to load the codec. I already solved this issue in Python using C functions instead of the Python codec until Python is able to load modules (able to load the Python codec).

The problem is the test on the "python initialization": PyUnicode_EncodeFSDefault / PyUnicode_DecodeFSDefaultAndSize check the global Py_FileSystemDefaultEncoding variable (use C functions if it is NULL).

We should use C functions if Py_FileSystemDefaultEncoding is NULL *or* if interp->codecs_initialized is zero.

I think that Python used interp->codecs_initialized flag. I removed the test on interp->codecs_initialized because I thought that it was useless.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10914>
_______________________________________

From report at bugs.python.org  Mon Apr 25 23:39:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Apr 2011 21:39:33 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1303767573.16.0.846282359543.issue10517@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I think that if we were to call PyThread_set_key_value twice on the
> same key it's either an error, or we want the last version to be
> stored, not the old one.

Not necessarily. You can have several interpreters (and therefore several thread states) in a single thread, using Py_NewInterpreter(). It's used by mod_wsgi and probably other software. If you overwrite the old value with the new one, it may break such software.

Would it be possible to cleanup the autoTLS mappings in PyOS_AfterFork() instead?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Mon Apr 25 23:46:19 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Mon, 25 Apr 2011 21:46:19 +0000
Subject: [issue8808] imaplib should support SSL contexts
In-Reply-To: <1274717637.39.0.0073929793702.issue8808@psf.upfronthosting.co.za>
Message-ID: <1303767979.02.0.97798450505.issue8808@psf.upfronthosting.co.za>


Sijin Joseph <sijinjoseph at gmail.com> added the comment:

Is anyone working on this?

----------
nosy: +sijinjoseph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8808>
_______________________________________

From report at bugs.python.org  Mon Apr 25 23:48:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Apr 2011 21:48:42 +0000
Subject: [issue8808] imaplib should support SSL contexts
In-Reply-To: <1274717637.39.0.0073929793702.issue8808@psf.upfronthosting.co.za>
Message-ID: <1303768122.85.0.149719509438.issue8808@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Is anyone working on this?

I don't think so, you could try if you are interested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8808>
_______________________________________

From report at bugs.python.org  Mon Apr 25 23:51:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Apr 2011 21:51:09 +0000
Subject: [issue10914] Python sub-interpreter test
In-Reply-To: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za>
Message-ID: <1303768269.04.0.928915307898.issue10914@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I think that Python used interp->codecs_initialized flag

Yes in PyUnicode_AsEncodedString(), in Python 3.0 and 3.1. Python 3.2 has also the test, but PyUnicode_AsEncodedString() is no more used to encode filenames. I removed the test in Python 3.3.

Extract of Python 3.1:

        /* During bootstrap, we may need to find the encodings
           package, to load the file system encoding, and require the
           file system encoding in order to load the encodings
           package.

           Break out of this dependency by assuming that the path to
           the encodings module is ASCII-only.  XXX could try wcstombs
           instead, if the file system encoding is the locale's
           encoding. */
        else if (Py_FileSystemDefaultEncoding &&
                 strcmp(encoding, Py_FileSystemDefaultEncoding) == 0 &&
                 !PyThreadState_GET()->interp->codecs_initialized)
            return PyUnicode_AsASCIIString(unicode);

I implemented the "XXX could try wcstombs" part, but in new functions:  PyUnicode_EncodeFSDefault and PyUnicode_DecodeFSDefaultAndSize.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10914>
_______________________________________

From report at bugs.python.org  Mon Apr 25 23:58:50 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Mon, 25 Apr 2011 21:58:50 +0000
Subject: [issue9390] Error in sys.excepthook on windows when redirecting
	output of the script
In-Reply-To: <1280235089.13.0.870066677678.issue9390@psf.upfronthosting.co.za>
Message-ID: <1303768730.47.0.41015135863.issue9390@psf.upfronthosting.co.za>


Sijin Joseph <sijinjoseph at gmail.com> added the comment:

I was not able to reproduce this on Python 2.7 x64 or Python 3.2 x64 on Win 7 SP1.

I am curious what the output is if you just run test.py, do you still get an error?

----------
nosy: +sijinjoseph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9390>
_______________________________________

From report at bugs.python.org  Tue Apr 26 00:01:14 2011
From: report at bugs.python.org (Graham Dumpleton)
Date: Mon, 25 Apr 2011 22:01:14 +0000
Subject: [issue10914] Python sub-interpreter test
In-Reply-To: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za>
Message-ID: <1303768874.11.0.0165010318337.issue10914@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

Hmmm, I wander if that is related to the workaround I have added in mod_wsgi recently of:

    /*
     * Force loading of codecs into interpreter. This has to be
     * done as not otherwise done in sub interpreters and if not
     * done, code running in sub interpreters can fail on some
     * platforms if a unicode string is added in sys.path and an
     * import then done.
     */

    item = PyCodec_Encoder("ascii");
    Py_XDECREF(item);

This fixes problem some have seen where one gets:

  LookupError: no codec search functions registered: can't find encoding

I haven't been able to reproduce the problem myself so no bug report ever lodged.

Have been told it affects some other embedded systems as well which use sub interpreters but other systems don't employ the workaround that I am now using.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10914>
_______________________________________

From report at bugs.python.org  Tue Apr 26 00:04:14 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Mon, 25 Apr 2011 22:04:14 +0000
Subject: [issue9035] os.path.ismount on windows doesn't support windows
	mount	points
In-Reply-To: <1277023751.91.0.438330382261.issue9035@psf.upfronthosting.co.za>
Message-ID: <1303769054.84.0.172130938799.issue9035@psf.upfronthosting.co.za>


Changes by Sijin Joseph <sijinjoseph at gmail.com>:


----------
nosy: +sijinjoseph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9035>
_______________________________________

From report at bugs.python.org  Tue Apr 26 00:04:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Apr 2011 22:04:45 +0000
Subject: [issue11923] gcc: unrecognized option '-n32'
In-Reply-To: <1303762034.43.0.96724336471.issue11923@psf.upfronthosting.co.za>
Message-ID: <1303769085.08.0.413459102387.issue11923@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Can you check CFLAGS and friends? Also, attach of output of "configure"?

----------
nosy: +dmalcolm, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11923>
_______________________________________

From report at bugs.python.org  Tue Apr 26 00:19:50 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Mon, 25 Apr 2011 22:19:50 +0000
Subject: [issue11893] Obsolete SSLFakeFile in smtplib?
In-Reply-To: <1303332884.98.0.410323888418.issue11893@psf.upfronthosting.co.za>
Message-ID: <1303769990.38.0.181478884631.issue11893@psf.upfronthosting.co.za>


Changes by Sijin Joseph <sijinjoseph at gmail.com>:


----------
nosy: +sijinjoseph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11893>
_______________________________________

From report at bugs.python.org  Tue Apr 26 01:02:04 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Apr 2011 23:02:04 +0000
Subject: [issue11923] gcc: unrecognized option '-n32'
In-Reply-To: <1303762034.43.0.96724336471.issue11923@psf.upfronthosting.co.za>
Message-ID: <1303772524.98.0.104011115278.issue11923@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11923>
_______________________________________

From report at bugs.python.org  Tue Apr 26 01:27:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Apr 2011 23:27:36 +0000
Subject: [issue10914] Python sub-interpreter test
In-Reply-To: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za>
Message-ID: <1303774056.54.0.539241963569.issue10914@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The problem is the test on the "python initialization":
> PyUnicode_EncodeFSDefault / PyUnicode_DecodeFSDefaultAndSize
> check the global Py_FileSystemDefaultEncoding variable (use
> C functions if it is NULL).

The problem is a little bit more complex. interp->codecs_initialized is set to 1 by _PyCodecRegistry_Init(), but the filesystem codec is not loaded yet. We need another variable: interp->fscodec_initialized.

fscodec_subinterpreter.patch fixes this issue.

Note: the patch replaces also PyErr_Print() by PyErr_PrintEx(0) to avoid a crash on error, if PyErr_PrintEx(0) is called before the sys module is initialized. For example, if PyModule_GetDict(_PyImport_FindBuiltin("builtins")) is NULL. Anyway, it's useless to set sys attributes on error, because sys is destroyed just after printing the error.

----------
Added file: http://bugs.python.org/file21778/fscodec_subinterpreter.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10914>
_______________________________________

From report at bugs.python.org  Tue Apr 26 01:30:22 2011
From: report at bugs.python.org (Michal Molhanec)
Date: Mon, 25 Apr 2011 23:30:22 +0000
Subject: [issue9390] Error in sys.excepthook on windows when redirecting
	output of the script
In-Reply-To: <1280235089.13.0.870066677678.issue9390@psf.upfronthosting.co.za>
Message-ID: <1303774222.34.0.823444912413.issue9390@psf.upfronthosting.co.za>


Michal Molhanec <molhanec at gmail.com> added the comment:

Running it without redirecting output, like
c:\p\test.py
works OK

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9390>
_______________________________________

From report at bugs.python.org  Tue Apr 26 01:39:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Apr 2011 23:39:42 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1303774782.24.0.575696519169.issue11888@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The main issue is that we'd have to provide (and maintain) our own
> implementation of log2 for Windows (and other OSs that don't have all
> the C99 support.  Solaris?)

Can't we simply use (approximation to 1/log(2)) * log(x)? Is it worse than reimplementing it using log(x)/log(2) in Python?

> That implementation should, ideally: ...

Because some platforms are less accurate, you prefer to not provide a more accurate function when log2() is available? Can't we start with something simple and improve it later?

It can be documented than the Python log2 function may be the same than log(x)/log(2) if the platform/CPU doesn't provide a C log2 function.

--

"... And indeed, on Windows ...

>>> numpy.log2(8.0)
2.9999999999999996"

Oh. Python is better on Linux:

Python 2.6.6 (r266:84292, Dec 26 2010, 22:31:48) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> math.log(8) / math.log(2)
3.0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Tue Apr 26 01:43:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Apr 2011 23:43:48 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1303775028.23.0.455371203888.issue11888@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Can't we simply use (approximation to 1/log(2)) * log(x)?
> Is it worse than reimplementing it using log(x)/log(2) in Python?

Hum. With a x86 and the right compiler optimization level, log(x)/log(2) in C can be more accurate than log(x)/log(2) in Python, because the FPU works with 80 bits float internally, and the result is only "truncated" to 64 bits float at the end. In Python, the result is truncated to 64 bits on each Python instruction.

I don't know if it should be called a feature or a bug. In PHP world, it would be called a bug :-D http://bugs.php.net/bug.php?id=53632

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Tue Apr 26 01:57:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Apr 2011 23:57:20 +0000
Subject: [issue11915] test_ctypes hangs in sandbox
In-Reply-To: <1303673896.39.0.0238599913513.issue11915@psf.upfronthosting.co.za>
Message-ID: <1303775840.95.0.575926477957.issue11915@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I reported the bug on Gentoo bug tracker:
http://bugs.gentoo.org/show_bug.cgi?id=364877

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11915>
_______________________________________

From report at bugs.python.org  Tue Apr 26 02:00:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2011 00:00:12 +0000
Subject: [issue11925] test_ttk_guionly.test_traversal() failed on "x86
	Windows7 3.x"
In-Reply-To: <1303776010.8.0.380054844246.issue11925@psf.upfronthosting.co.za>
Message-ID: <1303776010.8.0.380054844246.issue11925@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

test_ttk_guionly.test_traversal() failed on "x86 Windows7 3.x":
---------------
[120/354] test_ttk_guionly
test test_ttk_guionly failed -- Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\tkinter\test\test_ttk\test_widgets.py", line 713, in test_traversal
    self.assertEqual(self.nb.select(), str(self.child2))
AssertionError: '.116458816' != '.116461336'
- .116458816
+ .116461336
---------------
http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/2984/steps/test/logs/stdio

----------
components: Tests, Tkinter, Windows
messages: 134430
nosy: haypo
priority: normal
severity: normal
status: open
title: test_ttk_guionly.test_traversal() failed on "x86 Windows7 3.x"
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11925>
_______________________________________

From report at bugs.python.org  Tue Apr 26 02:01:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2011 00:01:09 +0000
Subject: [issue11925] test_ttk_guionly.test_traversal() failed on "x86
	Windows7 3.x"
In-Reply-To: <1303776010.8.0.380054844246.issue11925@psf.upfronthosting.co.za>
Message-ID: <1303776069.41.0.205034979563.issue11925@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Code of the test:
-----------------------------------------
class NotebookTest(unittest.TestCase):

    def setUp(self):
        support.root_deiconify()
        self.nb = ttk.Notebook(padding=0)
        self.child1 = ttk.Label()
        self.child2 = ttk.Label()
        self.nb.add(self.child1, text='a')
        self.nb.add(self.child2, text='b')



    def test_traversal(self):
        self.nb.pack()
        self.nb.wait_visibility()

        self.nb.select(0)

        support.simulate_mouse_click(self.nb, 5, 5)
        self.nb.focus_force()
        self.nb.event_generate('<Control-Tab>')
        self.assertEqual(self.nb.select(), str(self.child2)) <~~~ HERE
        ...
-----------------------------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11925>
_______________________________________

From report at bugs.python.org  Tue Apr 26 02:12:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2011 00:12:31 +0000
Subject: [issue11918] Drop OS/2 and VMS support in Python 3.3
In-Reply-To: <1303741305.45.0.808920067617.issue11918@psf.upfronthosting.co.za>
Message-ID: <1303776751.41.0.383992052934.issue11918@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@loewis: Would you like to review the patch?

You wrote on python-dev:

"For OS/2, I propose to syntactically break the makefile"
and
"For VMS, I *think* the build process is configure-based (but I may
misremember); if so, adding an exit into configure.in would be
appropriate."

But I don't know how to do that.

I added two #error for each OS, I hope that it is enough. But I am unable to test my patch, I don't have access to these OSes :-)

----------
keywords: +patch
Added file: http://bugs.python.org/file21779/unsupport_os2_vms.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11918>
_______________________________________

From report at bugs.python.org  Tue Apr 26 02:16:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2011 00:16:44 +0000
Subject: [issue11918] Drop OS/2 and VMS support in Python 3.3
In-Reply-To: <1303741305.45.0.808920067617.issue11918@psf.upfronthosting.co.za>
Message-ID: <1303777004.83.0.12953280668.issue11918@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, I just realized that the PEP 11 doesn't ask to mention unsupported OSes in the What's new document. New patch to mention that OS/2 and VMS are no more supported.

----------
Added file: http://bugs.python.org/file21780/unsupport_os2_vms-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11918>
_______________________________________

From report at bugs.python.org  Tue Apr 26 02:17:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2011 00:17:36 +0000
Subject: [issue11918] Drop OS/2 and VMS support in Python 3.3
In-Reply-To: <1303741305.45.0.808920067617.issue11918@psf.upfronthosting.co.za>
Message-ID: <1303777056.04.0.285915159417.issue11918@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file21779/unsupport_os2_vms.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11918>
_______________________________________

From report at bugs.python.org  Tue Apr 26 02:26:44 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Tue, 26 Apr 2011 00:26:44 +0000
Subject: [issue9035] os.path.ismount on windows doesn't support windows
	mount	points
In-Reply-To: <1277023751.91.0.438330382261.issue9035@psf.upfronthosting.co.za>
Message-ID: <1303777604.98.0.0069873359263.issue9035@psf.upfronthosting.co.za>


Sijin Joseph <sijinjoseph at gmail.com> added the comment:

I'd like to add the win_ismount function mentioned by Tim. Is anyone else working on this presently?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9035>
_______________________________________

From report at bugs.python.org  Tue Apr 26 02:36:51 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 26 Apr 2011 00:36:51 +0000
Subject: [issue9035] os.path.ismount on windows doesn't support windows
	mount	points
In-Reply-To: <1277023751.91.0.438330382261.issue9035@psf.upfronthosting.co.za>
Message-ID: <1303778211.24.0.863244030466.issue9035@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9035>
_______________________________________

From report at bugs.python.org  Tue Apr 26 03:34:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2011 01:34:44 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when
	locks are implemented using POSIX condition variables
In-Reply-To: <1303341621.3493.5.camel@localhost.localdomain>
Message-ID: <1303781690.30079.2.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> >  - Rename _PyThread_Info() to PyThread_GetInfo() (consistent name with
> > PyFloat_GetInfo() and PyLong_GetInfo())
> 
> I don't think we want that API to be public, so it should be
> _PyThread_GetInfo().

Why should it be private in C, but not in Python?

Why should it be private whereas PyLong_GetInfo() and PyFloat_GetInfo()
are public?

> >  - Always compile thread.c, but add #ifdef WITH_THREAD around most the
> > file (except PyThread_GetInfo())
> 
> What's the point? Sounds like pointless complication.

Complication? It does *simplify* configure.in.

I don't want to create a new file just for a small function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Tue Apr 26 03:56:00 2011
From: report at bugs.python.org (Carl M. Johnson)
Date: Tue, 26 Apr 2011 01:56:00 +0000
Subject: [issue11926] help("keywords") returns incomplete list of keywords
In-Reply-To: <1303782960.65.0.80653815306.issue11926@psf.upfronthosting.co.za>
Message-ID: <1303782960.65.0.80653815306.issue11926@psf.upfronthosting.co.za>


New submission from Carl M. Johnson <cmjohnson.mailinglist at gmail.com>:

In Python 3.2, help("keywords") returns the following:



Here is a list of the Python keywords.  Enter any keyword to get more help.

and                 elif                import              raise
as                  else                in                  return
assert              except              is                  try
break               finally             lambda              while
class               for                 nonlocal            with
continue            from                not                 yield
def                 global              or                  
del                 if                  pass                

- - - -

This list is missing True, False, and None.

----------
assignee: docs at python
components: Documentation
messages: 134440
nosy: Carl.M.Johnson, docs at python
priority: normal
severity: normal
status: open
title: help("keywords") returns incomplete list of keywords
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11926>
_______________________________________

From report at bugs.python.org  Tue Apr 26 04:00:26 2011
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 26 Apr 2011 02:00:26 +0000
Subject: [issue11926] help("keywords") returns incomplete list of keywords
In-Reply-To: <1303782960.65.0.80653815306.issue11926@psf.upfronthosting.co.za>
Message-ID: <1303783226.49.0.419679369818.issue11926@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/issue11926>
_______________________________________

From report at bugs.python.org  Tue Apr 26 04:03:55 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Apr 2011 02:03:55 +0000
Subject: [issue11926] help("keywords") returns incomplete list of keywords
In-Reply-To: <1303782960.65.0.80653815306.issue11926@psf.upfronthosting.co.za>
Message-ID: <1303783435.29.0.491442975979.issue11926@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

True, False and None are also included in keyword.kwlist:
>>> keyword.kwlist
['False', 'None', 'True', 'and', 'as', 'assert', 'break', 'class', 'continue', 'def', 'del', 'elif', 'else', 'except', 'finally', 'for', 'from', 'global', 'if', 'import', 'in', 'is', 'lambda', 'nonlocal', 'not', 'or', 'pass', 'raise', 'return', 'try', 'while', 'with', 'yield']

The help() is also missing for 'None' and 'False', but works for 'True':

>>> help('None')
no Python documentation found for 'None'
>>> help('False')
no Python documentation found for 'False'
>>> help('True')
Help on bool object:

True = class bool(int)
 |  bool(x) -> bool
 ...

On 3.3 it's the same.

----------
nosy: +ezio.melotti
stage:  -> needs patch
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11926>
_______________________________________

From report at bugs.python.org  Tue Apr 26 05:45:18 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Apr 2011 03:45:18 +0000
Subject: [issue6780] startswith error message is incomplete
In-Reply-To: <1251149593.57.0.654081758843.issue6780@psf.upfronthosting.co.za>
Message-ID: <E1QEZDB-0007VT-Bi@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3ceeccbc2c3b by Ezio Melotti in branch '2.7':
#6780: fix starts/endswith error message to mention that tuples are accepted too.
http://hg.python.org/cpython/rev/3ceeccbc2c3b

New changeset bcbf8c3c4a88 by Ezio Melotti in branch '3.1':
#6780: fix starts/endswith error message to mention that tuples are accepted too.
http://hg.python.org/cpython/rev/bcbf8c3c4a88

New changeset f393c507717a by Ezio Melotti in branch '3.2':
#6780: merge with 3.1.
http://hg.python.org/cpython/rev/f393c507717a

New changeset a1a1296556d7 by Ezio Melotti in branch 'default':
#6780: merge with 3.2.
http://hg.python.org/cpython/rev/a1a1296556d7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6780>
_______________________________________

From report at bugs.python.org  Tue Apr 26 05:46:41 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Apr 2011 03:46:41 +0000
Subject: [issue6780] startswith error message is incomplete
In-Reply-To: <1251149593.57.0.654081758843.issue6780@psf.upfronthosting.co.za>
Message-ID: <1303789601.58.0.447316334998.issue6780@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> 
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6780>
_______________________________________

From report at bugs.python.org  Tue Apr 26 06:16:03 2011
From: report at bugs.python.org (Kasun Herath)
Date: Tue, 26 Apr 2011 04:16:03 +0000
Subject: [issue8809] smtplib should support SSL contexts
In-Reply-To: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>
Message-ID: <1303791363.76.0.257702256402.issue8809@psf.upfronthosting.co.za>


Kasun Herath <kasunh01 at gmail.com> added the comment:

I did another patch based on feedback given. A test for SMTP_SSL wasn't added; will look into it later. Tab character that were present are removed. Also SSLContext support was added to starttls() but it is slightly different from the starttls() implementation of imaplib. Further feedback would be much appreciated.

----------
Added file: http://bugs.python.org/file21781/smtp_sslcontext_updated2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8809>
_______________________________________

From report at bugs.python.org  Tue Apr 26 06:21:56 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 26 Apr 2011 04:21:56 +0000
Subject: [issue11925] test_ttk_guionly.test_traversal() failed on "x86
	Windows7 3.x"
In-Reply-To: <1303776010.8.0.380054844246.issue11925@psf.upfronthosting.co.za>
Message-ID: <1303791716.85.0.788785358165.issue11925@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Might be a duplicate of Issue10736.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11925>
_______________________________________

From report at bugs.python.org  Tue Apr 26 07:31:18 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 26 Apr 2011 05:31:18 +0000
Subject: [issue11918] Drop OS/2 and VMS support in Python 3.3
In-Reply-To: <1303741305.45.0.808920067617.issue11918@psf.upfronthosting.co.za>
Message-ID: <1303795878.34.0.378547926582.issue11918@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch looks fine; please add a reference to PEP 11 into the error messages, though (so that people can find out that they can volunteer to maintain it).

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11918>
_______________________________________

From report at bugs.python.org  Tue Apr 26 08:32:14 2011
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 26 Apr 2011 06:32:14 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1303799534.12.0.208490109087.issue11682@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy: +Yury.Selivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11682>
_______________________________________

From report at bugs.python.org  Tue Apr 26 08:43:02 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Apr 2011 06:43:02 +0000
Subject: [issue11918] Drop OS/2 and VMS support in Python 3.3
In-Reply-To: <1303741305.45.0.808920067617.issue11918@psf.upfronthosting.co.za>
Message-ID: <1303800182.87.0.638973639039.issue11918@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I wrote to the maintainer of vmspython, and he said this:

"Python on VMS is actively maintained, for example you can take a look at
http://www.vmspython.org/ and http://www.vmspython.org/History
Our plan are to port, this year 2.7, then 3.x."


So the vmspython project looks active, but that still does not help
us of course. I hope Jean-Fran?ois will comment here.

----------
nosy: +pieronne, skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11918>
_______________________________________

From report at bugs.python.org  Tue Apr 26 09:48:53 2011
From: report at bugs.python.org (=?utf-8?q?Pi=C3=A9ronne_Jean-Fran=C3=A7ois?=)
Date: Tue, 26 Apr 2011 07:48:53 +0000
Subject: [issue11918] Drop OS/2 and VMS support in Python 3.3
In-Reply-To: <1303741305.45.0.808920067617.issue11918@psf.upfronthosting.co.za>
Message-ID: <1303804133.62.0.707417411946.issue11918@psf.upfronthosting.co.za>


Pi?ronne Jean-Fran?ois <pieronne at users.sourceforge.net> added the comment:

How can we help you ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11918>
_______________________________________

From report at bugs.python.org  Tue Apr 26 10:24:21 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 26 Apr 2011 08:24:21 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1303767573.16.0.846282359543.issue10517@psf.upfronthosting.co.za>
Message-ID: <BANLkTimiTTG+41f8tHuMsGyvY5uLRp13pA@mail.gmail.com>


Charles-Francois Natali <neologix at free.fr> added the comment:

> Not necessarily. You can have several interpreters (and therefore several thread states) in a single thread, using Py_NewInterpreter(). It's used by mod_wsgi and probably other software. If you overwrite the old value with the new one, it may break such software.
>

OK, I didn't know. Better not to change that in that case.

> Would it be possible to cleanup the autoTLS mappings in PyOS_AfterFork() instead?
>

Well, after fork, all threads have exited, so you'll be running on the
behalf of the child process' main - and only - thread, so by
definition you can't access other threads' thread-specific data, no?
As an alternate solution, I was thinking of calling
PyThread_delete_key_value(autoTLSkey) in the path of thread bootstrap,
i.e. starting in Modules/_threadmodule.c t_bootstrap. Obviously, this
should be done before calling _PyThreadState_Init, since it can also
be called from Py_NewInterpreter.
The problem is that it would require exporting autoTLSkey whose scope
is now limited to pystate.c (we could also create a small wrapper
function in pystate.c to delete the autoTLSkey, since it's already
done in PyThreadState_DeleteCurrent and PyThreadState_Delete).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Tue Apr 26 12:11:33 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 26 Apr 2011 10:11:33 +0000
Subject: [issue11918] Drop OS/2 and VMS support in Python 3.3
In-Reply-To: <1303741305.45.0.808920067617.issue11918@psf.upfronthosting.co.za>
Message-ID: <1303812693.13.0.640791006108.issue11918@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Would be possible to publish a notice in "python insider" blog?.Enigmail

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11918>
_______________________________________

From report at bugs.python.org  Tue Apr 26 12:18:55 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 26 Apr 2011 10:18:55 +0000
Subject: [issue10154] locale.normalize strips "-" from UTF-8,
	which fails on Mac
In-Reply-To: <1303491160.48.0.573407173763.issue10154@psf.upfronthosting.co.za>
Message-ID: <4DB69C05.8010204@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Piotr Sikora wrote:
> 
> Piotr Sikora <piotr.sikora at frickle.com> added the comment:
> 
> It's the same on OpenBSD (and I'm pretty sure it's true for other BSDs as well).
> 
>>>> locale.resetlocale()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "/usr/local/lib/python2.6/locale.py", line 523, in resetlocale
>     _setlocale(category, _build_localename(getdefaultlocale()))
> locale.Error: unsupported locale setting
>>>> locale._build_localename(locale.getdefaultlocale())
> 'en_US.UTF8'
> 
> Works fine with Marc-Andre's alias table fix.
> 
> Any chances this will be eventually fixed in 2.x?

This can go into Python 2.7, and, of course, into the 3.x
branches.

----------
title: locale.normalize strips "-" from UTF-8, which fails on Mac -> locale.normalize strips "-" from UTF-8,	which fails on Mac

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10154>
_______________________________________

From report at bugs.python.org  Tue Apr 26 13:49:58 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 26 Apr 2011 11:49:58 +0000
Subject: [issue9390] Error in sys.excepthook on windows when redirecting
	output of the script
In-Reply-To: <1280235089.13.0.870066677678.issue9390@psf.upfronthosting.co.za>
Message-ID: <1303818598.37.0.492764839987.issue9390@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This post: http://stackoverflow.com/questions/3018848/cannot-run-python-script-on-windows-with-output-redirected
suggests that there is a difference between "python test.py > out.log" and "test.py > out.log".
It also suggests a change in the registry that fixed the problem for me some months ago. Can you try it?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9390>
_______________________________________

From report at bugs.python.org  Tue Apr 26 13:54:26 2011
From: report at bugs.python.org (Kasun Herath)
Date: Tue, 26 Apr 2011 11:54:26 +0000
Subject: [issue11882] test_imaplib failed on x86 ubuntu
In-Reply-To: <1303242113.82.0.307299264452.issue11882@psf.upfronthosting.co.za>
Message-ID: <1303818866.22.0.138053212294.issue11882@psf.upfronthosting.co.za>


Kasun Herath <kasunh01 at gmail.com> added the comment:

Yes problem seems to be with time.mktime(). Here is my output,

>>> calendar.timegm((2000, 1, 1, 0, 0, 0, -1, -1, -1))
946684800

>>> x = imaplib.Internaldate2tuple(b'25 (INTERNALDATE "01-Jan-2000 00:00:00 +0000")')

>>> x
time.struct_time(tm_year=2000, tm_mon=1, tm_mday=1, tm_hour=5, tm_min=30, tm_sec=0, tm_wday=5, tm_yday=1, tm_isdst=0)

>>> time.mktime(x)
946683000.0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11882>
_______________________________________

From report at bugs.python.org  Tue Apr 26 14:10:42 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Apr 2011 12:10:42 +0000
Subject: [issue11882] test_imaplib failed on x86 ubuntu
In-Reply-To: <1303242113.82.0.307299264452.issue11882@psf.upfronthosting.co.za>
Message-ID: <1303819842.03.0.943553541216.issue11882@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

So this is probably not a python problem at all, but a problem with your system c library time functions. time.mktime is a thin wrapper around the mktime libc call.  Perhaps you could write a short C program to test it?  I've added Barry as nosy since he has some interest in ubuntu issues.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11882>
_______________________________________

From report at bugs.python.org  Tue Apr 26 14:30:35 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 26 Apr 2011 12:30:35 +0000
Subject: [issue11907] SysLogHandler can't send long messages
In-Reply-To: <1303480338.6.0.255798757577.issue11907@psf.upfronthosting.co.za>
Message-ID: <1303821035.83.0.38555110936.issue11907@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

For other options you might like to consider, see:

http://plumberjack.blogspot.com/2010/09/improved-queuehandler-queuelistener.html

which refers to QueueHandler and QueueListener classes. These were added in 3.2 but are available for Python 2.x:

http://code.google.com/p/logutils/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11907>
_______________________________________

From report at bugs.python.org  Tue Apr 26 14:31:25 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 26 Apr 2011 12:31:25 +0000
Subject: [issue11907] SysLogHandler can't send long messages
In-Reply-To: <1303480338.6.0.255798757577.issue11907@psf.upfronthosting.co.za>
Message-ID: <1303821085.76.0.552849786029.issue11907@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Also:

http://plumberjack.blogspot.com/2010/09/using-logging-with-multiprocessing.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11907>
_______________________________________

From report at bugs.python.org  Tue Apr 26 14:46:33 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Tue, 26 Apr 2011 12:46:33 +0000
Subject: [issue11926] help("keywords") returns incomplete list of keywords
In-Reply-To: <1303782960.65.0.80653815306.issue11926@psf.upfronthosting.co.za>
Message-ID: <1303821993.24.0.24817028973.issue11926@psf.upfronthosting.co.za>


Sijin Joseph <sijinjoseph at gmail.com> added the comment:

Should True, False and None be keywords? Technically True and False are objects of type bool, in fact the only objects of that type allowed. And None is a specially designated object as well.

P.S: Can anyone point me to where the help function is defined in the source?

----------
nosy: +sijinjoseph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11926>
_______________________________________

From report at bugs.python.org  Tue Apr 26 14:50:23 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Tue, 26 Apr 2011 12:50:23 +0000
Subject: [issue11926] help("keywords") returns incomplete list of keywords
In-Reply-To: <1303782960.65.0.80653815306.issue11926@psf.upfronthosting.co.za>
Message-ID: <1303822223.09.0.806201079476.issue11926@psf.upfronthosting.co.za>


Sijin Joseph <sijinjoseph at gmail.com> added the comment:

@Ezio - help(True), help(False) and help(None) all return the correct documentation for me using latest trunk. I think the quotes around True, False and None might be throwing things off in your case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11926>
_______________________________________

From report at bugs.python.org  Tue Apr 26 15:01:34 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Apr 2011 13:01:34 +0000
Subject: [issue11236] getpass.getpass does not respond to ctrl-c or ctrl-z
In-Reply-To: <1297976188.87.0.766078134711.issue11236@psf.upfronthosting.co.za>
Message-ID: <E1QEhtN-0000Ke-AH@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 154b323e0e7f by Senthil Kumaran in branch '3.1':
Fix for issue11236 getpass.getpass to respond ctrl-c or ctrl-z
http://hg.python.org/cpython/rev/154b323e0e7f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11236>
_______________________________________

From report at bugs.python.org  Tue Apr 26 15:01:38 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Tue, 26 Apr 2011 13:01:38 +0000
Subject: [issue9390] Error in sys.excepthook on windows when redirecting
	output of the script
In-Reply-To: <1280235089.13.0.870066677678.issue9390@psf.upfronthosting.co.za>
Message-ID: <1303822898.59.0.819592866064.issue9390@psf.upfronthosting.co.za>


Sijin Joseph <sijinjoseph at gmail.com> added the comment:

@Amaury - That sounds exactly like the issue described.

To summarize the error is caused because in some versions of windows there is a bug that causes the handles to stdin/stdout to not be inherited correctly for apps run from the console "via file association".

This is the kb article, http://support.microsoft.com/default.aspx?kbid=321788

In fact looks like this issue was discussed in the Python mailing list in 2004 as well, see http://mail.python.org/pipermail/python-bugs-list/2004-August/024923.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9390>
_______________________________________

From report at bugs.python.org  Tue Apr 26 15:03:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Apr 2011 13:03:07 +0000
Subject: [issue11236] getpass.getpass does not respond to ctrl-c or ctrl-z
In-Reply-To: <1297976188.87.0.766078134711.issue11236@psf.upfronthosting.co.za>
Message-ID: <E1QEhuz-0000UY-0K@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a3b4887edba4 by Senthil Kumaran in branch '2.7':
issue11236 getpass.getpass to respond ctrl-c or ctrl-z
http://hg.python.org/cpython/rev/a3b4887edba4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11236>
_______________________________________

From report at bugs.python.org  Tue Apr 26 15:08:25 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 26 Apr 2011 13:08:25 +0000
Subject: [issue11236] getpass.getpass does not respond to ctrl-c or ctrl-z
In-Reply-To: <1297976188.87.0.766078134711.issue11236@psf.upfronthosting.co.za>
Message-ID: <1303823305.22.0.880868423894.issue11236@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I have made the changes in 3.3,3.2,3.1 and 2.7 codeline. The behavior is aligned with the 2.5 (and earlier) behaviors. I cannot change this 2.6 because this is not a security issue to be back-ported. (rather it was misinterpreted problem and resulted in changed behavior in 2.6). 

I shall update this in README file just that people note this change

----------
resolution:  -> fixed
stage: test needed -> committed/rejected
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11236>
_______________________________________

From report at bugs.python.org  Tue Apr 26 15:14:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Apr 2011 13:14:47 +0000
Subject: [issue11236] getpass.getpass does not respond to ctrl-c or ctrl-z
In-Reply-To: <1297976188.87.0.766078134711.issue11236@psf.upfronthosting.co.za>
Message-ID: <E1QEi6G-0001Sb-L3@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f799530dbde7 by Senthil Kumaran in branch '3.1':
Update News entry for Issue11236
http://hg.python.org/cpython/rev/f799530dbde7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11236>
_______________________________________

From report at bugs.python.org  Tue Apr 26 15:18:34 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Apr 2011 13:18:34 +0000
Subject: [issue11236] getpass.getpass does not respond to ctrl-c or ctrl-z
In-Reply-To: <1297976188.87.0.766078134711.issue11236@psf.upfronthosting.co.za>
Message-ID: <E1QEi9x-0001sp-4r@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 1b261f3bef09 by Senthil Kumaran in branch '2.7':
Update NEWS for Issue11236.
http://hg.python.org/cpython/rev/1b261f3bef09

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11236>
_______________________________________

From report at bugs.python.org  Tue Apr 26 15:20:00 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 26 Apr 2011 13:20:00 +0000
Subject: [issue11236] getpass.getpass does not respond to ctrl-c or ctrl-z
In-Reply-To: <1297976188.87.0.766078134711.issue11236@psf.upfronthosting.co.za>
Message-ID: <1303824000.84.0.257814236754.issue11236@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Updated the NEWS entry.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11236>
_______________________________________

From report at bugs.python.org  Tue Apr 26 15:25:51 2011
From: report at bugs.python.org (Paul Griffith)
Date: Tue, 26 Apr 2011 13:25:51 +0000
Subject: [issue11923] gcc: unrecognized option '-n32'
In-Reply-To: <1303762034.43.0.96724336471.issue11923@psf.upfronthosting.co.za>
Message-ID: <1303824351.91.0.31395704683.issue11923@psf.upfronthosting.co.za>


Paul Griffith <paulg at cse.yorku.ca> added the comment:

I have included the config.log file and a script of configure and make process. CFAGS and friends are not set.

----------
Added file: http://bugs.python.org/file21782/typescript.python-2.7.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11923>
_______________________________________

From report at bugs.python.org  Tue Apr 26 15:27:26 2011
From: report at bugs.python.org (Paul Griffith)
Date: Tue, 26 Apr 2011 13:27:26 +0000
Subject: [issue11923] gcc: unrecognized option '-n32'
In-Reply-To: <1303762034.43.0.96724336471.issue11923@psf.upfronthosting.co.za>
Message-ID: <1303824446.09.0.223659099329.issue11923@psf.upfronthosting.co.za>


Paul Griffith <paulg at cse.yorku.ca> added the comment:

Here is the config.log file!

----------
Added file: http://bugs.python.org/file21783/config.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11923>
_______________________________________

From report at bugs.python.org  Tue Apr 26 15:40:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Apr 2011 13:40:26 +0000
Subject: [issue11923] gcc: unrecognized option '-n32'
In-Reply-To: <1303762034.43.0.96724336471.issue11923@psf.upfronthosting.co.za>
Message-ID: <1303825226.56.0.552239778182.issue11923@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> CFAGS and friends are not set.

How about LDFLAGS?

By the way, the build should have succeeded anyway: the "python" executable should be at the root of your build directory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11923>
_______________________________________

From report at bugs.python.org  Tue Apr 26 16:17:07 2011
From: report at bugs.python.org (Paul Griffith)
Date: Tue, 26 Apr 2011 14:17:07 +0000
Subject: [issue11923] gcc: unrecognized option '-n32'
In-Reply-To: <1303762034.43.0.96724336471.issue11923@psf.upfronthosting.co.za>
Message-ID: <1303827427.59.0.0108572361104.issue11923@psf.upfronthosting.co.za>


Paul Griffith <paulg at cse.yorku.ca> added the comment:

I found the problem, it is with my system. In the past we used to support SGI hosts and I had the SGI_ABI environmental variable set to -n32.


Please consider this issue closed.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11923>
_______________________________________

From report at bugs.python.org  Tue Apr 26 16:22:04 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 26 Apr 2011 14:22:04 +0000
Subject: [issue11923] gcc: unrecognized option '-n32'
In-Reply-To: <1303762034.43.0.96724336471.issue11923@psf.upfronthosting.co.za>
Message-ID: <1303827724.34.0.205688716637.issue11923@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11923>
_______________________________________

From report at bugs.python.org  Tue Apr 26 16:52:19 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 26 Apr 2011 14:52:19 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
Message-ID: <1303829539.1.0.983983549419.issue3526@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Hi Charles-Fran?ois,

it is possible to impact the memory allocation system on AIX using some environment variables (MALLOCOPTIONS and others), but it is not very elegant (it will impact all applications running with this environment and it is difficult to ensure that those environment variables will be correctly set when distributing an application to a customer) and I am afraid most users will never hear about that and will just use the default behavior.

Concerning mmap performances, dlmalloc has a pool mechanism and Python has its own pool mechanism on top of that.
As a result, system calls to allocate memory do not happen frequently since the memory allocation is usually handled internally in those pools and dlmalloc is often faster than the native malloc.

I have been distributing a version of Python which integrates this patch with the application on which I work to various customers for the last few years and the benchmarks have not shown any significant performance degradation. On the other hand, the decrease in memory consumption has been clearly noticed and appreciated.

Also note that dlmalloc (or a derivative - ptmalloc) is part of GNU glibc which is used by most Linux systems, and is what you get when you call malloc.
http://en.wikipedia.org/wiki/Malloc#dlmalloc_and_its_derivatives

So by using dlmalloc on SunOS and AIX you would get the same level of performance for memory operations that you already probably can appreciate on Linux systems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Tue Apr 26 16:56:49 2011
From: report at bugs.python.org (Xuanji Li)
Date: Tue, 26 Apr 2011 14:56:49 +0000
Subject: [issue11837] smtplib._quote_periods triggers spurious type error in
	re.sub
In-Reply-To: <1302628161.84.0.82021620589.issue11837@psf.upfronthosting.co.za>
Message-ID: <1303829809.95.0.272848738727.issue11837@psf.upfronthosting.co.za>


Changes by Xuanji Li <xuanji at gmail.com>:


----------
nosy: +xuanji

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11837>
_______________________________________

From report at bugs.python.org  Tue Apr 26 17:01:49 2011
From: report at bugs.python.org (Xuanji Li)
Date: Tue, 26 Apr 2011 15:01:49 +0000
Subject: [issue5115] Extend subprocess.kill to be able to kill process groups
In-Reply-To: <1233370260.58.0.70597374825.issue5115@psf.upfronthosting.co.za>
Message-ID: <1303830109.98.0.572479949386.issue5115@psf.upfronthosting.co.za>


Changes by Xuanji Li <xuanji at gmail.com>:


----------
nosy: +xuanji

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5115>
_______________________________________

From report at bugs.python.org  Tue Apr 26 17:02:01 2011
From: report at bugs.python.org (Xuanji Li)
Date: Tue, 26 Apr 2011 15:02:01 +0000
Subject: [issue11872] cPickle gives strange error for large objects.
In-Reply-To: <1303200362.9.0.587954333494.issue11872@psf.upfronthosting.co.za>
Message-ID: <1303830121.92.0.260419742193.issue11872@psf.upfronthosting.co.za>


Changes by Xuanji Li <xuanji at gmail.com>:


----------
nosy: +xuanji

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11872>
_______________________________________

From report at bugs.python.org  Tue Apr 26 17:03:32 2011
From: report at bugs.python.org (Xuanji Li)
Date: Tue, 26 Apr 2011 15:03:32 +0000
Subject: [issue5723] Incomplete json tests
In-Reply-To: <1239205406.15.0.353111609778.issue5723@psf.upfronthosting.co.za>
Message-ID: <1303830212.13.0.0884830878155.issue5723@psf.upfronthosting.co.za>


Changes by Xuanji Li <xuanji at gmail.com>:


----------
nosy: +xuanji

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5723>
_______________________________________

From report at bugs.python.org  Tue Apr 26 17:18:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Apr 2011 15:18:07 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <BANLkTimiTTG+41f8tHuMsGyvY5uLRp13pA@mail.gmail.com>
Message-ID: <1303831074.3518.15.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Well, after fork, all threads have exited, so you'll be running on the
> behalf of the child process' main - and only - thread, so by
> definition you can't access other threads' thread-specific data, no?

A rather good point :)
How about deleting the mapping (pthread_key_delete) and recreating it
from scratch, then?

> As an alternate solution, I was thinking of calling
> PyThread_delete_key_value(autoTLSkey) in the path of thread bootstrap,
> i.e. starting in Modules/_threadmodule.c t_bootstrap.

That would somewhat alleviate the problem, but only for Python-created
threads. Threads created through other means (for example mod_wsgi, or
database wrappers having their own thread pools) would still face the
original issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Tue Apr 26 17:35:57 2011
From: report at bugs.python.org (Buck Golemon)
Date: Tue, 26 Apr 2011 15:35:57 +0000
Subject: [issue8326] Cannot import name SemLock on Ubuntu
In-Reply-To: <1270549791.67.0.929964356468.issue8326@psf.upfronthosting.co.za>
Message-ID: <1303832157.48.0.545377863664.issue8326@psf.upfronthosting.co.za>


Buck Golemon <buck.golemon at amd.com> added the comment:

@Barry: Yes, it's still a problem.

The ubuntu 10.10 python2.7 still has no multiprocessing.
Since the EOL is April 2012, it needs fixed.

It may be considered an invalid python bug, since it seems to be strictly related to Ubuntu packaging, but I thought the python maintainers should know.

--Buck

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8326>
_______________________________________

From report at bugs.python.org  Tue Apr 26 17:41:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 26 Apr 2011 15:41:27 +0000
Subject: [issue11913] sdist should allow for README.rst
In-Reply-To: <1303613322.81.0.629577121535.issue11913@psf.upfronthosting.co.za>
Message-ID: <1303832487.43.0.677648862191.issue11913@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If it?s only a warning, just ignore it.  This would be easy to fix, but as it would be considered a new feature, it can?t go into distutils, which is frozen.  I am however willing to edit the documentation to tell that PyPI will accept README.rst and that people need not worry about the unfortunate warning.  Would that be okay with you?

In distutils2, the replacement for distutils, we don?t included README by default.  I don?t know why this was changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11913>
_______________________________________

From report at bugs.python.org  Tue Apr 26 18:08:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 26 Apr 2011 16:08:01 +0000
Subject: [issue11921] distutils2 should be able to compile an Extension based
	on the Python implementation version
In-Reply-To: <1303750597.71.0.868083563179.issue11921@psf.upfronthosting.co.za>
Message-ID: <1303834081.52.0.160382333165.issue11921@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The environment markers are specific to PEP 345, that is metadata, which includes dependencies, so that you can depend on something only on a given platform.  Your proposal of putting C extensions in another distribution and optionally depend on it should work right now, but is IMO too cumbersome.  Why not extend the format of the Extensions section in setup.cfg so that it supports environment markers?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11921>
_______________________________________

From report at bugs.python.org  Tue Apr 26 18:20:08 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 26 Apr 2011 16:20:08 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1303834808.9.0.968329581521.issue10517@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> How about deleting the mapping (pthread_key_delete) and recreating it
> from scratch, then?

Sounds good.
So the idea would be to retrieve the current thread's tstate, destroy the current autoTLSkey, re-create it, and re-associate the current tstate to this new key. I just did a quick test on RHEL4 and it works.
PyThread_ReinitTLS looks like a good candidate for that, but it's the same problem, autoTLSkey scope is limited to pystates.c (and I'm not sure that the tstate should be exposed to platform thread implementations).
There's also PyEval_ReinitThreads in ceval.c, exposing the autoTLSkey would make more sense (and it already knows about tstate, of course).
Where would you put it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Tue Apr 26 18:26:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Apr 2011 16:26:19 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1303834808.9.0.968329581521.issue10517@psf.upfronthosting.co.za>
Message-ID: <1303835169.3518.19.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > How about deleting the mapping (pthread_key_delete) and recreating it
> > from scratch, then?
> 
> Sounds good.
> So the idea would be to retrieve the current thread's tstate, destroy
> the current autoTLSkey, re-create it, and re-associate the current
> tstate to this new key. I just did a quick test on RHEL4 and it works.
> PyThread_ReinitTLS looks like a good candidate for that, but it's the
> same problem, autoTLSkey scope is limited to pystates.c (and I'm not
> sure that the tstate should be exposed to platform thread
> implementations).
> There's also PyEval_ReinitThreads in ceval.c, exposing the autoTLSkey
> would make more sense (and it already knows about tstate, of course).
> Where would you put it?

You could add a new _PyGILState_ReInit() function and call it from
PyOS_AfterFork() or PyEval_ReInitThreads().

(perhaps you also need to add a TLS-destroying function to thread.c, I
haven't looked)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Tue Apr 26 18:32:42 2011
From: report at bugs.python.org (Jeremy Kloth)
Date: Tue, 26 Apr 2011 16:32:42 +0000
Subject: [issue11921] distutils2 should be able to compile an Extension based
	on the Python implementation version
In-Reply-To: <1303750597.71.0.868083563179.issue11921@psf.upfronthosting.co.za>
Message-ID: <1303835562.99.0.493382975979.issue11921@psf.upfronthosting.co.za>


Changes by Jeremy Kloth <jeremy.kloth at gmail.com>:


----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11921>
_______________________________________

From report at bugs.python.org  Tue Apr 26 18:39:36 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Tue, 26 Apr 2011 16:39:36 +0000
Subject: [issue11921] distutils2 should be able to compile an Extension based
	on the Python implementation version
In-Reply-To: <1303750597.71.0.868083563179.issue11921@psf.upfronthosting.co.za>
Message-ID: <1303835976.08.0.744183020861.issue11921@psf.upfronthosting.co.za>


Alexis Metaireau <alexis at notmyidea.org> added the comment:

This raises a concern about python specific python implementations dependencies. 

We probably could extend PEP 345 in order to support things such as 'platform.python_implementation == "cpython"'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11921>
_______________________________________

From report at bugs.python.org  Tue Apr 26 18:48:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Apr 2011 16:48:22 +0000
Subject: [issue11927] SMTP_SSL doesn't use port 465 by default
In-Reply-To: <1303836501.95.0.366662026013.issue11927@psf.upfronthosting.co.za>
Message-ID: <1303836501.95.0.366662026013.issue11927@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The SMTP_SSL doc says ?If port is omitted, the standard SMTP-over-SSL port (465) is used?, but actually port 25 is used by default. The fix is trivial: make "default_port" a class attribute (in both SMTP and SMTP_SSL) instead of setting it inside the constructor.

test_smtpnet uses an explicit port to connect to gmail, which is why it doesn't exhibit the issue.

(Kasun, I'm adding you since you might be interested. Sorry if it isn't the case)

----------
components: Library (Lib)
keywords: easy
messages: 134478
nosy: kasun, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: SMTP_SSL doesn't use port 465 by default
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11927>
_______________________________________

From report at bugs.python.org  Tue Apr 26 18:49:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Apr 2011 16:49:01 +0000
Subject: [issue8809] smtplib should support SSL contexts
In-Reply-To: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>
Message-ID: <1303836541.13.0.819611240599.issue8809@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For the record, issue11927 reminds me that test_smtpnet actually has a trivial test for SMTP-over-SSL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8809>
_______________________________________

From report at bugs.python.org  Tue Apr 26 18:51:47 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 26 Apr 2011 16:51:47 +0000
Subject: [issue11928] fail if file with space at the end is present
In-Reply-To: <1303836707.17.0.285457821827.issue11928@psf.upfronthosting.co.za>
Message-ID: <1303836707.17.0.285457821827.issue11928@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

I know this is a minor bug, but still.. Windows allows creation of filenames like "use MoveBufferArea " (note space at the end). When such file is present in current directory, `setup.py sdist` fails with `error: use MoveBufferArea : The system cannot find the file specified`.

----------
assignee: tarek
components: Distutils
messages: 134480
nosy: eric.araujo, tarek, techtonik
priority: normal
severity: normal
status: open
title: fail if file with space at the end is present
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11928>
_______________________________________

From report at bugs.python.org  Tue Apr 26 18:52:06 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 26 Apr 2011 16:52:06 +0000
Subject: [issue11928] fail on filename with space at the end
In-Reply-To: <1303836707.17.0.285457821827.issue11928@psf.upfronthosting.co.za>
Message-ID: <1303836726.08.0.286886983805.issue11928@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
title: fail if file with space at the end is present -> fail on filename with space at the end

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11928>
_______________________________________

From report at bugs.python.org  Tue Apr 26 18:52:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Apr 2011 16:52:31 +0000
Subject: [issue8809] smtplib should support SSL contexts
In-Reply-To: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>
Message-ID: <1303836751.9.0.663535247665.issue8809@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

So, thanks for the new patch. I tested it with my ISP's server and it works fine!

Two remaining issues though:
- in the SMTP_SSL constructor, you must add the "context" argument at the end of the argument list (after "timeout"), otherwise someone passing "timeout" as a positional argument will find their code breaking
- in the doc, you need a "versionchanged" tag for the "context" argument (in both instances)

Thank you again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8809>
_______________________________________

From report at bugs.python.org  Tue Apr 26 19:33:11 2011
From: report at bugs.python.org (Michal Molhanec)
Date: Tue, 26 Apr 2011 17:33:11 +0000
Subject: [issue9390] Error in sys.excepthook on windows when redirecting
	output of the script
In-Reply-To: <1280235089.13.0.870066677678.issue9390@psf.upfronthosting.co.za>
Message-ID: <1303839191.07.0.30609473762.issue9390@psf.upfronthosting.co.za>


Michal Molhanec <molhanec at gmail.com> added the comment:

Thanks, the fix looks working.
The questions are:
a) can this situation be detected at runtime to provide better error message?
b) can it be detected during the installation so that the installation program can offer to the user to set the flag (or it could be set always? are there any disadvantages in doing so?}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9390>
_______________________________________

From report at bugs.python.org  Tue Apr 26 19:36:46 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 26 Apr 2011 17:36:46 +0000
Subject: [issue9614] _pickle is not entirely 64-bit safe
In-Reply-To: <1281895982.89.0.760453311109.issue9614@psf.upfronthosting.co.za>
Message-ID: <1303839406.0.0.86372159622.issue9614@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9614>
_______________________________________

From report at bugs.python.org  Tue Apr 26 19:39:50 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 26 Apr 2011 17:39:50 +0000
Subject: [issue11564] pickle not 64-bit ready
In-Reply-To: <1300229909.71.0.853987934234.issue11564@psf.upfronthosting.co.za>
Message-ID: <1303839590.85.0.214745781835.issue11564@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11564>
_______________________________________

From report at bugs.python.org  Tue Apr 26 19:40:00 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 26 Apr 2011 17:40:00 +0000
Subject: [issue9614] _pickle is not entirely 64-bit safe
In-Reply-To: <1281895982.89.0.760453311109.issue9614@psf.upfronthosting.co.za>
Message-ID: <1303839600.2.0.542554549326.issue9614@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9614>
_______________________________________

From report at bugs.python.org  Tue Apr 26 19:40:35 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 26 Apr 2011 17:40:35 +0000
Subject: [issue11872] cPickle gives strange error for large objects.
In-Reply-To: <1303200362.9.0.587954333494.issue11872@psf.upfronthosting.co.za>
Message-ID: <1303839635.63.0.149370946553.issue11872@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11872>
_______________________________________

From report at bugs.python.org  Tue Apr 26 19:41:22 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 26 Apr 2011 17:41:22 +0000
Subject: [issue9614] _pickle is not entirely 64-bit safe
In-Reply-To: <1281895982.89.0.760453311109.issue9614@psf.upfronthosting.co.za>
Message-ID: <1303839682.87.0.492615702689.issue9614@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

See also issue 10640.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9614>
_______________________________________

From report at bugs.python.org  Tue Apr 26 19:43:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Apr 2011 17:43:09 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when
	locks are implemented using POSIX condition variables
In-Reply-To: <1303781690.30079.2.camel@marge>
Message-ID: <1303839779.3518.66.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le mardi 26 avril 2011 ? 01:34 +0000, STINNER Victor a ?crit :
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> > >  - Rename _PyThread_Info() to PyThread_GetInfo() (consistent name with
> > > PyFloat_GetInfo() and PyLong_GetInfo())
> > 
> > I don't think we want that API to be public, so it should be
> > _PyThread_GetInfo().
> 
> Why should it be private in C, but not in Python?

Well, if it's called _info() in Python, it's private too!

> > >  - Always compile thread.c, but add #ifdef WITH_THREAD around most the
> > > file (except PyThread_GetInfo())
> > 
> > What's the point? Sounds like pointless complication.
> 
> Complication? It does *simplify* configure.in.
> 
> I don't want to create a new file just for a small function.

What I mean is that the "#ifdef WITH_THREAD" could be done in
sysmodule.c rather than in thread.c

Also, when Python is compiled without threads, I don't think thread_info
should be a structseq. It should probably be None instead.

Another small thing: your doc says "name" is optional, but it shouldn't.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Tue Apr 26 19:47:59 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 26 Apr 2011 17:47:59 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1303829539.1.0.983983549419.issue3526@psf.upfronthosting.co.za>
Message-ID: <BANLkTinGgGdVr0J7KjrAF4hpKtnffgop_A@mail.gmail.com>


Charles-Francois Natali <neologix at free.fr> added the comment:

> it is possible to impact the memory allocation system on AIX using some environment variables (MALLOCOPTIONS and others)

LD_PRELOAD won't impact AIX's malloc behaviour, but allows you to
replace it transparently by any other implementation you like
(dlmalloc, ptmalloc, ...), without touching neither cpython nor your
application.

For example, let's says I want a Python version where getpid always returns 42.

$ cat /tmp/pid.c
int getpid(void)
{
        return 42;
}

$ gcc -o /tmp/pid.so /tmp/pid.c -fpic -shared

Now,

$ LD_PRELOAD=/tmp/pid.so python -c 'import os; print(os.getpid())'
42

That's it. If you replace pid.so by dlmalloc.so, you'll be using
dlmalloc instead of AIX's malloc, without having modified a single
line of code.
If you're concerned with impacting other applications, then you could
do something like:

$ cat python.c
#include <stdlib.h>
#include <unistd.h>

int main(int argc, char *argv[])
{
        setenv("LD_PRELOAD", "/tmp/pid.so", 1);
        execvl(<path to real python>, argv);

        return 1;
}

And then:
$ ./python -c 'import os; print(os.getpid())'
42

> Also note that dlmalloc (or a derivative - ptmalloc) is part of GNU glibc which is used by most Linux systems, and is what you get when you call malloc.
> http://en.wikipedia.org/wiki/Malloc#dlmalloc_and_its_derivatives
>

Actually, glibc/eglibc versions have diverged quite a lot from the
original ptmalloc2, see for example http://bugs.python.org/issue11849
(that's one reason why embedding such a huge piece of code into Python
is probably not a good idea as highlighted by Antoine, it's updated
fairly frequently).

> So by using dlmalloc on SunOS and AIX you would get the same level of performance for memory operations that you already probably can appreciate on Linux systems.

Yes, but with the above "trick", you can do that without patching
python nor your app.
I mean, if you start embedding malloc in python, why stop there, and
not embed the whole glibc ;-)
Note that I realize this won't solve the problem for other AIX users
(if there are any left :-), but since this patch doesn't seem to be
gaining adhesion, I'm just proposing an alternative that I find
cleaner, simpler and easier to maintain.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Tue Apr 26 19:51:32 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 26 Apr 2011 17:51:32 +0000
Subject: [issue10640] SystemError on pickling bytes >= 4GB
In-Reply-To: <1291663989.87.0.429691501814.issue10640@psf.upfronthosting.co.za>
Message-ID: <1303840292.74.0.281997428164.issue10640@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10640>
_______________________________________

From report at bugs.python.org  Tue Apr 26 20:19:19 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 26 Apr 2011 18:19:19 +0000
Subject: [issue11929] Improve usage of PEP8 in Docs/includes/*
In-Reply-To: <1303841958.69.0.324750983113.issue11929@psf.upfronthosting.co.za>
Message-ID: <1303841958.69.0.324750983113.issue11929@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Following up http://mail.python.org/pipermail/docs/2011-April/004032.html I made a run of pep8 on Doc/includes/ py files.

i've prepared a patch against default; if it's considered worth I can prepare patches for the other branches (for sure 2.7 needs a different patch, and probably also 3.1).

----------
assignee: docs at python
components: Documentation
files: pep8_doc_includes.patch
keywords: patch
messages: 134486
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Improve usage of PEP8 in Docs/includes/*
versions: Python 3.3
Added file: http://bugs.python.org/file21784/pep8_doc_includes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11929>
_______________________________________

From report at bugs.python.org  Tue Apr 26 20:47:10 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2011 18:47:10 +0000
Subject: [issue11929] Improve usage of PEP8 in Docs/includes/*
In-Reply-To: <1303841958.69.0.324750983113.issue11929@psf.upfronthosting.co.za>
Message-ID: <1303843630.24.0.859434660933.issue11929@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

IMO, this is a complete waste of time and much of the code doesn't actually read any better afterwards.  Some of the mathematical expressions look worse.

There may be some merit to splitting the imports but that isn't worth much either, perhaps not enough to warrant trouncing the version control history on those lines.

----------
nosy: +rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11929>
_______________________________________

From report at bugs.python.org  Tue Apr 26 20:53:37 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2011 18:53:37 +0000
Subject: [issue11929] Improve usage of PEP8 in Docs/includes/*
In-Reply-To: <1303841958.69.0.324750983113.issue11929@psf.upfronthosting.co.za>
Message-ID: <1303844017.76.0.392193321167.issue11929@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11929>
_______________________________________

From report at bugs.python.org  Tue Apr 26 20:59:58 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 26 Apr 2011 18:59:58 +0000
Subject: [issue11929] Improve usage of PEP8 in Docs/includes/*
In-Reply-To: <1303841958.69.0.324750983113.issue11929@psf.upfronthosting.co.za>
Message-ID: <1303844398.63.0.390725375331.issue11929@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Another -1 from me.  Similar changes to inline examples in the docs have been rejected in the past for the same reasons as Raymond wrote.  See issue 4649.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11929>
_______________________________________

From report at bugs.python.org  Tue Apr 26 21:16:11 2011
From: report at bugs.python.org (Floris Bruynooghe)
Date: Tue, 26 Apr 2011 19:16:11 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <BANLkTinGgGdVr0J7KjrAF4hpKtnffgop_A@mail.gmail.com>
Message-ID: <BANLkTimL2Sei36=xqky6FwyLZ9o9eR80Jw@mail.gmail.com>


Floris Bruynooghe <floris.bruynooghe at gmail.com> added the comment:

> > So by using dlmalloc on SunOS and AIX you would get the same level
> > of performance for memory operations that you already probably can
> > appreciate on Linux systems.
>
> Yes, but with the above "trick", you can do that without patching
> python nor your app.
> I mean, if you start embedding malloc in python, why stop there, and
> not embed the whole glibc ;-)
> Note that I realize this won't solve the problem for other AIX users
> (if there are any left :-), but since this patch doesn't seem to be
> gaining adhesion, I'm just proposing an alternative that I find
> cleaner, simpler and easier to maintain.

This trick is hard to find however and I don't think it serves Solaris
and AIX users very much (and sadly IBM keeps pushing AIX so yes it's
used more then I like :-( ).

So how about a --with-dlmalloc=path/to/dlmalloc.c?  This way the
dlmalloc code does not live inside Python and doesn't need to be
maintained by python.  But python still supports the code and will
easily be built using it.  Add a note in the README for AIX and
Solaris and I think this would be a lot friendlier to users.  This is
similar in how python uses e.g. openssl to provide optional extra
functionality/performance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Tue Apr 26 21:18:27 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 26 Apr 2011 19:18:27 +0000
Subject: [issue11929] Improve usage of PEP8 in Docs/includes/*
In-Reply-To: <1303841958.69.0.324750983113.issue11929@psf.upfronthosting.co.za>
Message-ID: <1303845507.94.0.805680134563.issue11929@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On the other hand, I would be +0 for the tzinfo-examples fixes of the form:

foo(x=default) vs. foo(x = default)

(This was also the fix suggested on the ML.)

Overall, I think it is good to judicially point out to PEP 8 violations where fixes would improve readability, but mechanical reformatting is likely to be net loss.  I may fix tzinfo-examples next time I touch it.  With addition of timezone class in 3.3, this set of examples needs to be updated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11929>
_______________________________________

From report at bugs.python.org  Tue Apr 26 21:21:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Apr 2011 19:21:57 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <BANLkTimL2Sei36=xqky6FwyLZ9o9eR80Jw@mail.gmail.com>
Message-ID: <1303845693.3518.68.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> So how about a --with-dlmalloc=path/to/dlmalloc.c?

Can't you just add dlmalloc to LDFLAGS or something? Or would the
default malloc still be selected?

> This is
> similar in how python uses e.g. openssl to provide optional extra
> functionality/performance.

It's not really similar. OpenSSL provides functionality that's not
available through the standard library. Here, we're talking about an
alternative implementation of the standard C routines.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Tue Apr 26 21:32:23 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2011 19:32:23 +0000
Subject: [issue11929] Improve usage of PEP8 in Docs/includes/*
In-Reply-To: <1303841958.69.0.324750983113.issue11929@psf.upfronthosting.co.za>
Message-ID: <1303846343.3.0.202330575343.issue11929@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> foo(x=default) vs. foo(x = default)

That's fine.  Most of the rest of it isn't.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11929>
_______________________________________

From report at bugs.python.org  Tue Apr 26 21:37:42 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 26 Apr 2011 19:37:42 +0000
Subject: [issue11930] Remove time.accept2dyear
In-Reply-To: <1303846662.46.0.339847524577.issue11930@psf.upfronthosting.co.za>
Message-ID: <1303846662.46.0.339847524577.issue11930@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

As implemented in issue 10827, use of 2-digits years in timetuples to mean 4-digit years straddling year 2000 is deprecated in 3.3.  There is no mechanism for issuing deprecation warning for access to a module variable, but a deprecation note was added to its documentation.

Attached patch removes time.accept2dyear and the associated behaviors.

----------
files: remove-accept2dyear.diff
keywords: patch
messages: 134493
nosy: belopolsky, haypo
priority: normal
severity: normal
stage: patch review
status: open
title: Remove time.accept2dyear
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file21785/remove-accept2dyear.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11930>
_______________________________________

From report at bugs.python.org  Tue Apr 26 22:15:38 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 26 Apr 2011 20:15:38 +0000
Subject: [issue11918] Drop OS/2 and VMS support in Python 3.3
In-Reply-To: <1303804133.62.0.707417411946.issue11918@psf.upfronthosting.co.za>
Message-ID: <4DB727E7.6080505@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> How can we help you ?

Please contribute a full, complete, working VMS port to Python 3.3.

I never understood whether the code that we have is supposed to be
complete, in the sense that you get a working Python out of it
(rather, I understood that this never was the case - that you always
needed additional pieces to make it do something useful).

Another step to demonstrate ongoing support would be to contribute
a VMS build slave, so that committers without VMS (which is nearly
100%) can actually find out whether it continues to work after
changes.

I'd also like to see a dedicated maintainer nominated - a person who'll
respond to bug reports about the VMS support; if that person ever
leaves, and no new maintainer is nominated, the code would again be
up for removal.

If no demonstrable improvement is contributed to Python 3.3, I'd
continue with the PEP 11 process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11918>
_______________________________________

From report at bugs.python.org  Tue Apr 26 22:46:06 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 26 Apr 2011 20:46:06 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
Message-ID: <1303850766.19.0.903313820326.issue3526@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

I just noticed there's already a version of dlmalloc in Modules/_ctypes/libffi/src/dlmalloc.c

Compiling with gcc -shared -fpic -o /tmp/dlmalloc.so ./Modules/_ctypes/libffi/src/dlmalloc.c

Then LD_PRELOAD=/tmp/dlmalloc.so ./python

works just fine (and by the way, it solves the problem with glibc's version in #11849, it's somewhat slower though).

Or am I missing something?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Tue Apr 26 22:48:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Apr 2011 20:48:28 +0000
Subject: [issue11918] Drop OS/2 and VMS support in Python 3.3
In-Reply-To: <1303741305.45.0.808920067617.issue11918@psf.upfronthosting.co.za>
Message-ID: <E1QEpBK-00077X-Qv@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ec754f8d2917 by Victor Stinner in branch 'default':
Issue #11918: OS/2 and VMS are no more supported because of the lack of
http://hg.python.org/cpython/rev/ec754f8d2917

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11918>
_______________________________________

From report at bugs.python.org  Tue Apr 26 22:53:12 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 26 Apr 2011 20:53:12 +0000
Subject: [issue11834] wrong module installation dir on Windows
In-Reply-To: <1302605256.31.0.234550103785.issue11834@psf.upfronthosting.co.za>
Message-ID: <1303851192.66.0.949612031167.issue11834@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11834>
_______________________________________

From report at bugs.python.org  Tue Apr 26 22:55:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2011 20:55:18 +0000
Subject: [issue11918] Drop OS/2 and VMS support in Python 3.3
In-Reply-To: <1303741305.45.0.808920067617.issue11918@psf.upfronthosting.co.za>
Message-ID: <1303851318.41.0.385891733103.issue11918@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The patch looks fine; please add a reference to PEP 11 
> into the error messages

Ok, done.

> "Our plan are to port, this year 2.7, then 3.x."

VMS is unsupported in 3.3 and the code will be removed in 3.4. If anyone comes with patches to have a working VMS version before Python 3.4, we can support VMS again and just forget the PEP 11 deprecation.

> Would be possible to publish a notice in "python insider" blog?

Sure, but I don't want to write it. Contact Doug Hellmann for that. Marc Andre Lemburg is also volunteer to write such notice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11918>
_______________________________________

From report at bugs.python.org  Tue Apr 26 22:59:22 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2011 20:59:22 +0000
Subject: [issue11929] Improve usage of PEP8 in Docs/includes/*
In-Reply-To: <1303841958.69.0.324750983113.issue11929@psf.upfronthosting.co.za>
Message-ID: <1303851562.58.0.351580359657.issue11929@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I put a few of these in (ones where it looked like readability was improved).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11929>
_______________________________________

From report at bugs.python.org  Tue Apr 26 23:00:16 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Apr 2011 21:00:16 +0000
Subject: [issue11929] Improve usage of PEP8 in Docs/includes/*
In-Reply-To: <1303841958.69.0.324750983113.issue11929@psf.upfronthosting.co.za>
Message-ID: <E1QEpMk-00087f-OY@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 5e93c5cdc378 by Raymond Hettinger in branch '3.2':
Issue 11929: Minor whitespace clean-ups.
http://hg.python.org/cpython/rev/5e93c5cdc378

New changeset 89fcadbc49df by Raymond Hettinger in branch 'default':
Issue 11929: Minor whitespace clean-ups.
http://hg.python.org/cpython/rev/89fcadbc49df

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11929>
_______________________________________

From report at bugs.python.org  Tue Apr 26 23:09:53 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 26 Apr 2011 21:09:53 +0000
Subject: [issue5115] Extend subprocess.kill to be able to kill process groups
In-Reply-To: <1233370260.58.0.70597374825.issue5115@psf.upfronthosting.co.za>
Message-ID: <1303852193.31.0.0822730569267.issue5115@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Note that the setpgid creation part is now somewhat redundant with Popen's start_new_session flag (which calls setsid). Also, this should probably be an option, since with that patch every subprocess is in its own process group.

> I was wondering... what if process A runs a subprocess B which runs a
> subprocess C. Is C still considered a children of A and gets killed as
> well?

No.
When setpgid/setsid is called, a new group is created, so process C will be not be part of the same group as B.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5115>
_______________________________________

From report at bugs.python.org  Tue Apr 26 23:11:11 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 26 Apr 2011 21:11:11 +0000
Subject: [issue8326] Cannot import name SemLock on Ubuntu
In-Reply-To: <1270549791.67.0.929964356468.issue8326@psf.upfronthosting.co.za>
Message-ID: <1303852271.52.0.749298238057.issue8326@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm closing this as invalid for Python, since I believe this is strictly an Ubuntu bug caused by an out-of-date kernel on the build farm.  I'm working on an SRU to fix that.  Please track further status on the Launchpad bug page given below.

----------
assignee:  -> barry
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8326>
_______________________________________

From report at bugs.python.org  Tue Apr 26 23:20:14 2011
From: report at bugs.python.org (Scott Leerssen)
Date: Tue, 26 Apr 2011 21:20:14 +0000
Subject: [issue10761] tarfile.extractall fails to overwrite symlinks
In-Reply-To: <1293063436.61.0.0994372418071.issue10761@psf.upfronthosting.co.za>
Message-ID: <1303852814.18.0.526279653558.issue10761@psf.upfronthosting.co.za>


Scott Leerssen <sleerssen at gmail.com> added the comment:

I just hit the same issue.  This seems to work:


Modified:Lib/tarfile.py
===================================================================
---Lib/tarfile.py	2011-04-26 20:36:33 UTC (rev 49502)
+++Lib/tarfile.py	2011-04-26 21:01:24 UTC (rev 49503)
@@ -2239,6 +2239,8 @@
        if hasattr(os, "symlink") and hasattr(os, "link"):
            # For systems that support symbolic and hard links.
            if tarinfo.issym():
+                if os.path.exists(targetpath):
+                    os.unlink(targetpath)
                os.symlink(tarinfo.linkname, targetpath)
            else:
                # See extract().

----------
nosy: +Scott.Leerssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10761>
_______________________________________

From report at bugs.python.org  Tue Apr 26 23:22:10 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2011 21:22:10 +0000
Subject: [issue9614] _pickle is not entirely 64-bit safe
In-Reply-To: <1281895982.89.0.760453311109.issue9614@psf.upfronthosting.co.za>
Message-ID: <1303852930.86.0.900373984022.issue9614@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +rhettinger
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9614>
_______________________________________

From report at bugs.python.org  Tue Apr 26 23:45:53 2011
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 26 Apr 2011 21:45:53 +0000
Subject: [issue8326] Cannot import name SemLock on Ubuntu
In-Reply-To: <1270549791.67.0.929964356468.issue8326@psf.upfronthosting.co.za>
Message-ID: <1303854353.75.0.75952821771.issue8326@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

> Barry A. Warsaw<barry at python.org>  added the comment:
> 
> I'm closing this as invalid for Python, since I believe this is strictly an
> Ubuntu bug caused by an out-of-date kernel on the build farm.

that's where I disagree. a configure check should not be dependent on the running kernel.  I assume in the majority of cases you won't build against a current kernel, so the a fix in python maybe could be a runtime check.  Such configure checks will fail for cross builds too.

Note that packages on Ubuntu are always built on the current kernel of the current LTS release, on Debian on current kernels of the current stable release.  So there is nothing "out-of-date".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8326>
_______________________________________

From report at bugs.python.org  Tue Apr 26 23:47:44 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 26 Apr 2011 21:47:44 +0000
Subject: [issue9614] _pickle is not entirely 64-bit safe
In-Reply-To: <1281895982.89.0.760453311109.issue9614@psf.upfronthosting.co.za>
Message-ID: <1303854464.04.0.715376651777.issue9614@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> The warnings at lines 284, 301, 461, 647 are benign.

I agree.  There is no loss of data because Py_ssize_t variable bounds are checked before these lines are reached.

> The attached patch fixes them.

I don't like these changes:

-Pdata_poptuple(Pdata *self, Py_ssize_t start)
+Pdata_poptuple(Pdata *self, int start)

-Pdata_poplist(Pdata *self, Py_ssize_t start)
+Pdata_poplist(Pdata *self, int start)

These seem to attempt to fix

    Py_SIZE(self) = start;

assignments, but as far as I can tell, Py_SIZE(self) type is Py_ssize_t.

What do I miss here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9614>
_______________________________________

From report at bugs.python.org  Tue Apr 26 23:48:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2011 21:48:12 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when
	locks are implemented using POSIX condition variables
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1303854492.3.0.110377840468.issue11223@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Well, if it's called _info() in Python, it's private too!

My patch replaces thread._info() by sys.thread_info: it becomes public.

> What I mean is that the "#ifdef WITH_THREAD" could be done in
> sysmodule.c rather than in thread.c

PyThread_GetInfo() requires some informations that are only available at the end of thread.c: USE_SEMAPHORES define from thread_pthread.h and PYTHREAD_NAME from thread.c. It is easier to define PyThread_GetInfo() here, instead of giving access to these defines outside thread.c (and these defines should remaing private).

> Another small thing: your doc says "name" is optional, but it shouldn't.

By optional I mean that its value is None if Python is compiled without threads.

> Also, when Python is compiled without threads, 
> I don't think thread_info should be a structseq. 
> It should probably be None instead.

Terry Reedy proposed an empty string for name if Python is compiled without threads. Antoine suggested None instead of an empty string for lock and version fields, so I chose to use also None for None.

But yes, I like the idea of sys.thread_info being None.

--

Updated patch (sys_thread_info-2.patch):
 - sys.thread_info is None if Python is compiled without threads
 - sys.thread_info.name is no more optional
 - change the documentation of the lock and version fields
 - fix test_os (version is now a attribute and no more a key of a dict)

----------
Added file: http://bugs.python.org/file21786/sys_thread_info-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Wed Apr 27 00:06:27 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 26 Apr 2011 22:06:27 +0000
Subject: [issue11931] Regular expression documentation patch
In-Reply-To: <1303855586.52.0.604026571441.issue11931@psf.upfronthosting.co.za>
Message-ID: <1303855586.52.0.604026571441.issue11931@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

I have read and fixed the regular expression documentation and made a patch. Ezio, please review it and apply it. Thanks.

----------
assignee: docs at python
components: Documentation
files: re.patch
keywords: patch
messages: 134506
nosy: Retro, docs at python, ezio.melotti
priority: normal
severity: normal
status: open
title: Regular expression documentation patch
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21787/re.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11931>
_______________________________________

From report at bugs.python.org  Wed Apr 27 00:09:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2011 22:09:23 +0000
Subject: [issue11930] Remove time.accept2dyear
In-Reply-To: <1303846662.46.0.339847524577.issue11930@psf.upfronthosting.co.za>
Message-ID: <1303855763.43.0.366677912188.issue11930@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

time.rst:

* **Year 2000 (Y2K) issues**: Python depends on the platform's C library, which
  generally doesn't have year 2000 issues, since all dates and times are
  represented internally as seconds since the epoch.  Function :func:`strptime`
  can parse 2-digit years when given ``%y`` format code.  When 2-digit years are
  parsed, they are converted according to the POSIX and ISO C standards: values
  69--99 are mapped to 1969--1999, and values 0--68 are mapped to 2000--2068.

.. class:: struct_time (...) A year value will be handled as described under :ref:`Year 2000 (Y2K) issues <time-y2kissues>` above.

.. [#] The use of ``%Z`` is now deprecated, but the ``%z`` escape that expands to the
   preferred  hour/minute offset is not supported by all ANSI C libraries. Also, a
   strict reading of the original 1982 :rfc:`822` standard calls for a two-digit
   year (%y rather than %Y), but practice moved to 4-digit years long before the
   year 2000.  The 4-digit year has been mandated by :rfc:`2822`, which obsoletes
   :rfc:`822`.

Are these 3 notes still valid? It looks like struct_time note is wrong: the year 70 is now 70 and not interpreted as 1970 anymore.

---

timemodule.c:

PyDoc_STRVAR(module_doc,
"...
The tuple items are:\n\
  year (four digits, e.g. 1998)\n\
...")

=> That's wrong. Example: time.gmtime(-55582200000).tm_year gives 208.

---

/home/haypo/prog/HG/cpython/Modules/timemodule.c: In function 'PyInit_time':
/home/haypo/prog/HG/cpython/Modules/timemodule.c:872: warning: unused variable 'p'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11930>
_______________________________________

From report at bugs.python.org  Wed Apr 27 00:13:35 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 26 Apr 2011 22:13:35 +0000
Subject: [issue11930] Remove time.accept2dyear
In-Reply-To: <1303855763.43.0.366677912188.issue11930@psf.upfronthosting.co.za>
Message-ID: <BANLkTin34RPnRm1w_LzErW5vaoVPp-YuUg@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Apr 26, 2011 at 6:09 PM, STINNER Victor <report at bugs.python.org> wrote:
> It looks like struct_time note is wrong: the year 70 is now 70 and not interpreted as 1970 anymore.

What makes you say so?

1970

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11930>
_______________________________________

From report at bugs.python.org  Wed Apr 27 00:20:57 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 26 Apr 2011 22:20:57 +0000
Subject: [issue11930] Remove time.accept2dyear
In-Reply-To: <1303855763.43.0.366677912188.issue11930@psf.upfronthosting.co.za>
Message-ID: <BANLkTikCLg7yT1grQDTr05eAQOudkR_OMg@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Apr 26, 2011 at 6:09 PM, STINNER Victor <report at bugs.python.org> wrote:
..
>
> timemodule.c:
>
> PyDoc_STRVAR(module_doc,
> "...
> The tuple items are:\n\
> ?year (four digits, e.g. 1998)\n\
> ...")
>
> => That's wrong. Example: time.gmtime(-55582200000).tm_year gives 208.

This is wrong regardless of this patch.   I don't mind fixing this,
but it would be a different issue.  Can you suggest a change?  I would
like the docstring to still inform the user that 1998 should be given
as 1998 and not as 98.  Maybe s/four/all/?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11930>
_______________________________________

From report at bugs.python.org  Wed Apr 27 00:24:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Apr 2011 22:24:26 +0000
Subject: [issue10914] Python sub-interpreter test
In-Reply-To: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za>
Message-ID: <E1QEqgC-00063E-NC@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c8338cfa3578 by Victor Stinner in branch 'default':
Issue #10914: Py_NewInterpreter() uses PyErr_PrintEx(0)
http://hg.python.org/cpython/rev/c8338cfa3578

New changeset d3af2a2b621b by Victor Stinner in branch 'default':
Issue #10914: Initialize correctly the filesystem codec when creating a new
http://hg.python.org/cpython/rev/d3af2a2b621b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10914>
_______________________________________

From report at bugs.python.org  Wed Apr 27 00:26:45 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 26 Apr 2011 22:26:45 +0000
Subject: [issue8326] Cannot import name SemLock on Ubuntu
In-Reply-To: <1303854353.75.0.75952821771.issue8326@psf.upfronthosting.co.za>
Message-ID: <20110426182623.38e29a1e@neurotica.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Apr 26, 2011, at 09:45 PM, Matthias Klose wrote:

>Matthias Klose <doko at debian.org> added the comment:
>
>> Barry A. Warsaw<barry at python.org>  added the comment:
>> 
>> I'm closing this as invalid for Python, since I believe this is strictly an
>> Ubuntu bug caused by an out-of-date kernel on the build farm.
>
>that's where I disagree. a configure check should not be dependent on the
>running kernel.  I assume in the majority of cases you won't build against a
>current kernel, so the a fix in python maybe could be a runtime check.  Such
>configure checks will fail for cross builds too.

Perhaps so, but that's a totally different issue.  Such a change wouldn't be
appropriate for stable releases, so it could only make it into Python 3.3.  It
might be an interesting thing to work on, but I'd suggest opening a new bug
and seeing if anyone wants to work up a patch for that.

>Note that packages on Ubuntu are always built on the current kernel of the
>current LTS release, on Debian on current kernels of the current stable
>release.  So there is nothing "out-of-date".

"Out-of-date" was probably an incorrect choice of words.  My understanding was
that this bug was caused by a problem in the kernel that caused the configure
check to fail, at the time the Maverick Python 2.7 package was built, and that
the build machines have since been updated, correcting the problem.  At least,
current PPA builds don't have this problem.

In any case, I still think this specific issue is more appropriately tracked
in the Launchpad bug, and I have requested an SRU for a rebuild.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8326>
_______________________________________

From report at bugs.python.org  Wed Apr 27 00:30:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2011 22:30:24 +0000
Subject: [issue11930] Remove time.accept2dyear
In-Reply-To: <1303846662.46.0.339847524577.issue11930@psf.upfronthosting.co.za>
Message-ID: <1303857024.51.0.16592346217.issue11930@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

"What makes you say so?

1970"

Don't write ">>> " using the email interface :-)

--


>>> t
time.struct_time(tm_year=70, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=0)
>>> time.mktime(t)
-59958144561.0
>>> time.localtime(_)
time.struct_time(tm_year=70, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=2, tm_yday=1, tm_isdst=0)

Year 70 is considered as the year 70.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11930>
_______________________________________

From report at bugs.python.org  Wed Apr 27 00:32:42 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2011 22:32:42 +0000
Subject: [issue11931] Regular expression documentation patch
In-Reply-To: <1303855586.52.0.604026571441.issue11931@psf.upfronthosting.co.za>
Message-ID: <1303857162.43.0.216523728905.issue11931@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The section heads should remain in title case.

The colon in the octal escape section should remain, but the "If" following it should be lower cased.

"Phonebook" should remain a single word.

"vs" is fine without the period in a section head.

It would be better to replace all of the "e.g." and "i.e" with "for example" and "such as".

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11931>
_______________________________________

From report at bugs.python.org  Wed Apr 27 00:38:07 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 26 Apr 2011 22:38:07 +0000
Subject: [issue11931] Regular expression documentation patch
In-Reply-To: <1303855586.52.0.604026571441.issue11931@psf.upfronthosting.co.za>
Message-ID: <1303857487.6.0.81507399063.issue11931@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Raymond, what about the title "search() vs. match()"? There is a dot there! Please add the dot where I added it. Or remove it here as well. Also, "Checking For a Pair" is "Checking for a Pair". The word "for" must be lowercase.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11931>
_______________________________________

From report at bugs.python.org  Wed Apr 27 00:39:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2011 22:39:22 +0000
Subject: [issue10914] Python sub-interpreter test
In-Reply-To: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za>
Message-ID: <1303857562.04.0.737164469703.issue10914@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_capi pass on x86 debian parallel 3.x: I close this issue again :-)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10914>
_______________________________________

From report at bugs.python.org  Wed Apr 27 00:42:33 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 26 Apr 2011 22:42:33 +0000
Subject: [issue11930] Remove time.accept2dyear
In-Reply-To: <1303857024.51.0.16592346217.issue11930@psf.upfronthosting.co.za>
Message-ID: <BANLkTik5arm1KUypgoS21D+O_4kSmgcrOQ@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Apr 26, 2011 at 6:30 PM, STINNER Victor <report at bugs.python.org> wrote:
>
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
> "What makes you say so?
>
> 1970"
>
> Don't write ">>> " using the email interface :-)
>

Sorry.  That was the output of time.strptime('70', '%y')[0].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11930>
_______________________________________

From report at bugs.python.org  Wed Apr 27 00:52:19 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 26 Apr 2011 22:52:19 +0000
Subject: [issue11930] Remove time.accept2dyear
In-Reply-To: <1303855763.43.0.366677912188.issue11930@psf.upfronthosting.co.za>
Message-ID: <BANLkTin+MJTyGzPrYuzpwc_3vvts7SoV+w@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Apr 26, 2011 at 6:09 PM, STINNER Victor <report at bugs.python.org> wrote:
..
> .. class:: struct_time (...) A year value will be handled as described under :ref:`Year 2000 (Y2K) issues <time-y2kissues>` above.

This one needs to be removed.  Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11930>
_______________________________________

From report at bugs.python.org  Wed Apr 27 00:53:36 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2011 22:53:36 +0000
Subject: [issue11931] Regular expression documentation patch
In-Reply-To: <1303855586.52.0.604026571441.issue11931@psf.upfronthosting.co.za>
Message-ID: <1303858416.48.0.908247564921.issue11931@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11931>
_______________________________________

From report at bugs.python.org  Wed Apr 27 00:57:14 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2011 22:57:14 +0000
Subject: [issue11931] Regular expression documentation patch
In-Reply-To: <1303855586.52.0.604026571441.issue11931@psf.upfronthosting.co.za>
Message-ID: <1303858634.0.0.891530222946.issue11931@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'll do these fix-ups but wish you would shift your focus to making substantive changes.  You're wasting developer time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11931>
_______________________________________

From report at bugs.python.org  Wed Apr 27 01:23:58 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 26 Apr 2011 23:23:58 +0000
Subject: [issue10761] tarfile.extractall fails to overwrite symlinks
In-Reply-To: <1293063436.61.0.0994372418071.issue10761@psf.upfronthosting.co.za>
Message-ID: <1303860238.25.0.327847671257.issue10761@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Scott- which platform did you observe this? I can't reproduce this on the 2.7 code on Linux.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10761>
_______________________________________

From report at bugs.python.org  Wed Apr 27 01:30:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2011 23:30:07 +0000
Subject: [issue11930] Remove time.accept2dyear
In-Reply-To: <1303846662.46.0.339847524577.issue11930@psf.upfronthosting.co.za>
Message-ID: <1303860607.41.0.437876910936.issue11930@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The next step is to update the datetime module: something like the attached patch (datetime_y2k.patch).

----------
Added file: http://bugs.python.org/file21788/datetime_y2k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11930>
_______________________________________

From report at bugs.python.org  Wed Apr 27 02:11:55 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Wed, 27 Apr 2011 00:11:55 +0000
Subject: [issue10761] tarfile.extractall fails to overwrite symlinks
In-Reply-To: <1293063436.61.0.0994372418071.issue10761@psf.upfronthosting.co.za>
Message-ID: <1303863115.81.0.999879841326.issue10761@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10761>
_______________________________________

From report at bugs.python.org  Wed Apr 27 02:54:15 2011
From: report at bugs.python.org (Mark Mc Mahon)
Date: Wed, 27 Apr 2011 00:54:15 +0000
Subject: [issue11834] wrong module installation dir on Windows
In-Reply-To: <1302605256.31.0.234550103785.issue11834@psf.upfronthosting.co.za>
Message-ID: <1303865655.17.0.843422308314.issue11834@psf.upfronthosting.co.za>


Mark Mc Mahon <mtnbikingmark at gmail.com> added the comment:

Reviewing the patch (issue133572.py33.patch):
You have used forward slashes for the first change - but back slashes for the others. I see that other places in the existing docs use back slashes when referring to windows paths.

I have never used the --prefix option - but I am surprised that it would install scripts to prefix\Lib\site-packages (without the prefix option scripts are installed in pythondir\Scripts.

Maybe installing something like grin/pylint/etc which has an executable script is a way to verify?

----------
nosy: +markm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11834>
_______________________________________

From report at bugs.python.org  Wed Apr 27 04:17:05 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Apr 2011 02:17:05 +0000
Subject: [issue11926] help("keywords") returns incomplete list of keywords
In-Reply-To: <1303782960.65.0.80653815306.issue11926@psf.upfronthosting.co.za>
Message-ID: <1303870625.22.0.635869550977.issue11926@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This can be fixed by adding 'False', 'None', and 'True' to the Helper.keywords dict in Lib/pydoc.py.  I'm not sure what the topic for these should be though.  True/False/None are documented in the "built-in constants" section[0] of the doc.  An alternative might be to point to 'bool'[1] for True/False or just show the same help of help(True/False/None) (without quotes).

[0]: http://docs.python.org/dev/py3k/library/constants.html#built-in-constants
[1]: http://docs.python.org/dev/py3k/library/functions.html#bool

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11926>
_______________________________________

From report at bugs.python.org  Wed Apr 27 05:49:17 2011
From: report at bugs.python.org (David Strauss)
Date: Wed, 27 Apr 2011 03:49:17 +0000
Subject: [issue11932] Email multipart boundary detection fails on a wrapped
	header
In-Reply-To: <1303876157.91.0.419040488355.issue11932@psf.upfronthosting.co.za>
Message-ID: <1303876157.91.0.419040488355.issue11932@psf.upfronthosting.co.za>


New submission from David Strauss <david at davidstrauss.net>:

I've attached a multipart message produced by Thunderbird. For some reason, the email.message parser doesn't properly recognize the boundary. This causes legitimate multipart messages to parse as if no boundary were specified. Simply removing the newline on the line starting with " boundary" allows it to parse correctly.

To see why this is valid, refer to section 2.2.3 of RFC2822 [1].

[1] http://tools.ietf.org/html/rfc2822#section-2.2.3

----------
components: Library (Lib)
files: wrapped_multipart.txt
messages: 134523
nosy: davidstrauss
priority: normal
severity: normal
status: open
title: Email multipart boundary detection fails on a wrapped header
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file21789/wrapped_multipart.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11932>
_______________________________________

From report at bugs.python.org  Wed Apr 27 05:50:00 2011
From: report at bugs.python.org (David Strauss)
Date: Wed, 27 Apr 2011 03:50:00 +0000
Subject: [issue11932] Email multipart boundary detection fails on a wrapped
	header
In-Reply-To: <1303876157.91.0.419040488355.issue11932@psf.upfronthosting.co.za>
Message-ID: <1303876200.83.0.830427410187.issue11932@psf.upfronthosting.co.za>


Changes by David Strauss <david at davidstrauss.net>:


Removed file: http://bugs.python.org/file21789/wrapped_multipart.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11932>
_______________________________________

From report at bugs.python.org  Wed Apr 27 05:50:22 2011
From: report at bugs.python.org (David Strauss)
Date: Wed, 27 Apr 2011 03:50:22 +0000
Subject: [issue11932] Email multipart boundary detection fails on a wrapped
	header
In-Reply-To: <1303876157.91.0.419040488355.issue11932@psf.upfronthosting.co.za>
Message-ID: <1303876222.24.0.629765566473.issue11932@psf.upfronthosting.co.za>


David Strauss <david at davidstrauss.net> added the comment:

Replacing the file with a proper example.

----------
Added file: http://bugs.python.org/file21790/wrapped_multipart.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11932>
_______________________________________

From report at bugs.python.org  Wed Apr 27 05:55:38 2011
From: report at bugs.python.org (David Strauss)
Date: Wed, 27 Apr 2011 03:55:38 +0000
Subject: [issue11932] Email multipart boundary detection fails on a wrapped
	header
In-Reply-To: <1303876157.91.0.419040488355.issue11932@psf.upfronthosting.co.za>
Message-ID: <1303876538.58.0.420792352811.issue11932@psf.upfronthosting.co.za>


David Strauss <david at davidstrauss.net> added the comment:

Never mind. I was manipulating some text that broke the parser.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11932>
_______________________________________

From report at bugs.python.org  Wed Apr 27 06:29:51 2011
From: report at bugs.python.org (John S. Gruber)
Date: Wed, 27 Apr 2011 04:29:51 +0000
Subject: [issue11933] newer() function in dep_util.py mixes up new vs. old
	files due stat.st_mtime vs stat[ST_MTIME]
In-Reply-To: <1303878590.96.0.749813744893.issue11933@psf.upfronthosting.co.za>
Message-ID: <1303878590.96.0.749813744893.issue11933@psf.upfronthosting.co.za>


New submission from John S. Gruber <johnsgruber at gmail.com>:

In researching a bug I was surprised that a newly created file was being replaced when being processed a second time (it shouldn't have been processed a second time). 

I tracked the surprise to diff Lib/distutils/dep_util.py @ 57642:9211a5d7d0b4 where a comparison with a resolution of 1 second was replaced by a floating point comparison, though the new file was copied by file_util.py which tried to preserve the time using a method accurate to only 1 second (truncating the fraction). Since a new file with a truncated modification time looks older than an older file with a full precision stamp the problem resulted.

(For convenience--stat.st_mtime is floating point, stat[ST_MTIME] is integer seconds unless os.stat_float_times has been called to change the floating point behavior.

Using all floating point doesn't resolve the issue as OS timestamped files can have more resolution than python floating point may hold, again causing truncation and confusion. For reference see Python issue 10148.

In my humble opinion time setting and comparison should all be done consistently, and, if sub-second comparisons are desired, some fuzz should be used such that the comparison makes sense for the platform with the least amount of precision available with its floating point implementation.

I briefly looked at branches other than 2.7 and they don't seem to have the above change.

Probably of minor importance in most cases.

Thanks all for the good work, all. I've been learning python and I love it!

----------
assignee: tarek
components: Distutils
messages: 134526
nosy: eric.araujo, jsjgruber, tarek
priority: normal
severity: normal
status: open
title: newer() function in dep_util.py mixes up new vs. old files due stat.st_mtime vs stat[ST_MTIME]
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11933>
_______________________________________

From report at bugs.python.org  Wed Apr 27 06:31:29 2011
From: report at bugs.python.org (John O'Hagan)
Date: Wed, 27 Apr 2011 04:31:29 +0000
Subject: [issue11884] Argparse calls ngettext but doesn't import it
In-Reply-To: <1303285010.85.0.710971435429.issue11884@psf.upfronthosting.co.za>
Message-ID: <1303878689.28.0.656806016494.issue11884@psf.upfronthosting.co.za>


John O'Hagan <research at johnohagan.com> added the comment:

Reported to Debian, bug #624277

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11884>
_______________________________________

From report at bugs.python.org  Wed Apr 27 08:00:56 2011
From: report at bugs.python.org (Kasun Herath)
Date: Wed, 27 Apr 2011 06:00:56 +0000
Subject: [issue8809] smtplib should support SSL contexts
In-Reply-To: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>
Message-ID: <1303884056.14.0.405485910109.issue8809@psf.upfronthosting.co.za>


Kasun Herath <kasunh01 at gmail.com> added the comment:

Thanks for the quick review. I'm submitting a new patch with changes suggested.

----------
Added file: http://bugs.python.org/file21791/smtp_sslcontext_updated3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8809>
_______________________________________

From report at bugs.python.org  Wed Apr 27 09:21:41 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Apr 2011 07:21:41 +0000
Subject: [issue11763] assertEqual memory issues with large text inputs
In-Reply-To: <1301948164.44.0.0206798295308.issue11763@psf.upfronthosting.co.za>
Message-ID: <E1QEz44-0000Dz-Ry@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 8dbf661c0a63 by Ezio Melotti in branch '2.7':
#11763: don't use difflib in TestCase.assertMultiLineEqual if the strings are too long.
http://hg.python.org/cpython/rev/8dbf661c0a63

New changeset 04e64f77c6c7 by Ezio Melotti in branch '3.1':
#11763: don't use difflib in TestCase.assertMultiLineEqual if the strings are too long.
http://hg.python.org/cpython/rev/04e64f77c6c7

New changeset b316019638df by Ezio Melotti in branch '3.2':
#11763: merge with 3.1.
http://hg.python.org/cpython/rev/b316019638df

New changeset df154c872b0c by Ezio Melotti in branch 'default':
#11763: merge with 3.2.
http://hg.python.org/cpython/rev/df154c872b0c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11763>
_______________________________________

From report at bugs.python.org  Wed Apr 27 09:30:50 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Apr 2011 07:30:50 +0000
Subject: [issue11763] assertEqual memory issues with large text inputs
In-Reply-To: <1301948164.44.0.0206798295308.issue11763@psf.upfronthosting.co.za>
Message-ID: <1303889450.93.0.909818392156.issue11763@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I committed a slightly modified version of the patch, so the issue should be fixed now.

There are two related problems though:
1) difflib is used in other places, so those should probably be checked too;
2) _baseAssertEqual should check if the len of the msg (or the sum of the lengths of the two args) is greater than maxDiff and use safe_repr(arg, short=True) to avoid long diffs.

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11763>
_______________________________________

From report at bugs.python.org  Wed Apr 27 09:50:32 2011
From: report at bugs.python.org (Tim Golden)
Date: Wed, 27 Apr 2011 07:50:32 +0000
Subject: [issue11922] Add General Index to Windows .chm help file Contents
In-Reply-To: <1303752107.55.0.594682028964.issue11922@psf.upfronthosting.co.za>
Message-ID: <4DB7CAC2.8040806@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

I can't say I'd object as such, but the [Index] tab already
contains the items in the General Index and is arguably the
killer feature of the CHM in any case.

----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11922>
_______________________________________

From report at bugs.python.org  Wed Apr 27 10:19:10 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Apr 2011 08:19:10 +0000
Subject: [issue9390] Error in sys.excepthook on windows when redirecting
	output of the script
In-Reply-To: <1280235089.13.0.870066677678.issue9390@psf.upfronthosting.co.za>
Message-ID: <1303892350.2.0.750801339487.issue9390@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I've seen the same question/answer on other forums, about Perl, Lua and Javascript http://stackoverflow.com/questions/3018848/cannot-run-python-script-on-windows-with-output-redirected
but nobody suggested to set this flag by default. I don't know if it can have unwanted effects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9390>
_______________________________________

From report at bugs.python.org  Wed Apr 27 10:28:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Apr 2011 08:28:58 +0000
Subject: [issue11921] distutils2 should be able to compile an Extension based
	on the Python implementation version
In-Reply-To: <1303750597.71.0.868083563179.issue11921@psf.upfronthosting.co.za>
Message-ID: <1303892938.5.0.692985212813.issue11921@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Alexis is right, the implementation name is not currently available as an environment marker.  Maybe another approach could be used: consider all extensions optional on non-CPython platforms?

----------
versions: +3rd party -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11921>
_______________________________________

From report at bugs.python.org  Wed Apr 27 10:30:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Apr 2011 08:30:29 +0000
Subject: [issue11928] fail on filename with space at the end
In-Reply-To: <1303836707.17.0.285457821827.issue11928@psf.upfronthosting.co.za>
Message-ID: <1303893029.37.0.202107862868.issue11928@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Do you get the bug if you put such a filename in the MANIFEST file, or MANIFEST.in, or data_files argument, or something else, or all of them?  If it?s a MANIFEST bug, can you test with quotes around the filename?

----------
assignee: tarek -> eric.araujo
components: +Distutils2
nosy: +alexis
versions: +3rd party -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11928>
_______________________________________

From report at bugs.python.org  Wed Apr 27 10:31:57 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Apr 2011 08:31:57 +0000
Subject: [issue9614] _pickle is not entirely 64-bit safe
In-Reply-To: <1281895982.89.0.760453311109.issue9614@psf.upfronthosting.co.za>
Message-ID: <1303893117.51.0.182512648317.issue9614@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The warnings above are a bit old: 027f81579b4a changed Pdata into a PyVarObject, and the "int length" member is now accessed with the Py_SIZE() macro.
Unfortunately, the only win64 buildbot is offline, and I could not find any recent log of compilation warnings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9614>
_______________________________________

From report at bugs.python.org  Wed Apr 27 10:36:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Apr 2011 08:36:49 +0000
Subject: [issue10148] st_mtime differs after shutil.copy2
In-Reply-To: <1287530071.19.0.608159353416.issue10148@psf.upfronthosting.co.za>
Message-ID: <1303893409.87.0.49467375532.issue10148@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10148>
_______________________________________

From report at bugs.python.org  Wed Apr 27 10:39:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Apr 2011 08:39:22 +0000
Subject: [issue11933] newer() function in dep_util.py mixes up new vs. old
	files due stat.st_mtime vs stat[ST_MTIME]
In-Reply-To: <1303878590.96.0.749813744893.issue11933@psf.upfronthosting.co.za>
Message-ID: <1303893562.52.0.236519994226.issue11933@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi!  Welcome to the joy of Python and thanks for the bug report and analysis.

> In researching a bug
Is it public?  I?d be curious to look at it.

> I was surprised that a newly created file was being replaced when
> being processed a second time
What created the file?  What king of ?processing? happened after?

> I tracked the surprise to diff Lib/distutils/dep_util.py @ 57642:9211a5d7d0b4
> where a comparison with a resolution of 1 second was replaced by a
> floating point comparison
Indeed.  The whole distutils codebase should use ST_MTIME or st_mtime consistently.

> Using all floating point doesn't resolve the issue as OS timestamped
> files can have more resolution than python floating point may hold,
If I understand this bug correctly, it?s a platform-specific limitation.  We can try changing all distutils files to use st_mtime and see if tests break.  Would you like to work on a additional test case to reproduce your bug?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11933>
_______________________________________

From report at bugs.python.org  Wed Apr 27 10:50:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Apr 2011 08:50:26 +0000
Subject: [issue11914] pydoc modules/help('modules') crash in dirs with
	unreadable subdirs
In-Reply-To: <1303616093.87.0.65824226669.issue11914@psf.upfronthosting.co.za>
Message-ID: <1303894226.52.0.628978923421.issue11914@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Library (Lib) -Demos and Tools
nosy: +eric.araujo
stage:  -> test needed
versions:  -Python 2.5, Python 2.6, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11914>
_______________________________________

From report at bugs.python.org  Wed Apr 27 10:52:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Apr 2011 08:52:44 +0000
Subject: [issue6625] UnicodeEncodeError on pydoc's CLI
In-Reply-To: <1249218048.23.0.0483172452601.issue6625@psf.upfronthosting.co.za>
Message-ID: <1303894364.25.0.565146245734.issue6625@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6625>
_______________________________________

From report at bugs.python.org  Wed Apr 27 11:05:21 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Apr 2011 09:05:21 +0000
Subject: [issue9614] _pickle is not entirely 64-bit safe
In-Reply-To: <1281895982.89.0.760453311109.issue9614@psf.upfronthosting.co.za>
Message-ID: <1303895121.5.0.740154497153.issue9614@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes there are still warnings, but in different places; here is an extract of the previous buildlog.html file:

 ..\Modules\_pickle.c(156) : warning C4244:'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
 ..\Modules\_pickle.c(195) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
 ..\Modules\_pickle.c(754) : warning C4244: 'return' : conversion from 'Py_ssize_t' to 'int', possible loss of data
 ..\Modules\_pickle.c(1278) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'long', possible loss of data
 ..\Modules\_pickle.c(1285) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
 ..\Modules\_pickle.c(1952) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
 ..\Modules\_pickle.c(2233) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
 ..\Modules\_pickle.c(2493) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
 ..\Modules\_pickle.c(4350) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
 ..\Modules\_pickle.c(4615) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
 ..\Modules\_pickle.c(4655) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
 ..\Modules\_pickle.c(4896) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
 ..\Modules\_pickle.c(4943) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
 ..\Modules\_pickle.c(4960) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
 ..\Modules\_pickle.c(4991) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
 ..\Modules\_pickle.c(5147) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9614>
_______________________________________

From report at bugs.python.org  Wed Apr 27 11:24:48 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 27 Apr 2011 09:24:48 +0000
Subject: [issue11928] fail on filename with space at the end
In-Reply-To: <1303836707.17.0.285457821827.issue11928@psf.upfronthosting.co.za>
Message-ID: <1303896288.53.0.0588087023694.issue11928@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

The mere presence of this file in directory with setup.py files this error. It is not added in any files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11928>
_______________________________________

From report at bugs.python.org  Wed Apr 27 11:26:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Apr 2011 09:26:24 +0000
Subject: [issue11928] fail on filename with space at the end
In-Reply-To: <1303836707.17.0.285457821827.issue11928@psf.upfronthosting.co.za>
Message-ID: <1303896384.1.0.434687447106.issue11928@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Wow.  Can you set DISTUTILS_DEBUG=1 in your environment and then copy the full traceback here?  Try to see if other commands like build or check cause the error too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11928>
_______________________________________

From report at bugs.python.org  Wed Apr 27 11:33:55 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 27 Apr 2011 09:33:55 +0000
Subject: [issue11928] fail on filename with space at the end
In-Reply-To: <1303836707.17.0.285457821827.issue11928@psf.upfronthosting.co.za>
Message-ID: <1303896835.48.0.116611646596.issue11928@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

>python setup.py sdist
{{{
Distribution.parse_config_files():
options (after parsing config files):
no commands known yet
options (after parsing command line):
option dict for 'sdist' command:
  {}
running sdist
Distribution.get_command_obj(): creating 'sdist' command object
checking if setup.py newer than MANIFEST
error: some file : The system cannot find the file specified
Traceback (most recent call last):
  File "setup.py", line 17, in <module>
    'Operating System :: OS Independent',
  File "C:\Python25\lib\distutils\core.py", line 151, in setup
    dist.run_commands()
  File "C:\Python25\lib\distutils\dist.py", line 974, in run_commands
    self.run_command(cmd)
  File "C:\Python25\lib\distutils\dist.py", line 994, in run_command
    cmd_obj.run()
  File "C:\Python25\lib\distutils\command\sdist.py", line 143, in run
    self.get_file_list()
  File "C:\Python25\lib\distutils\command\sdist.py", line 237, in get_file_list
    self.filelist.findall()
  File "C:\Python25\lib\distutils\filelist.py", line 48, in findall
    self.allfiles = findall(dir)
  File "C:\Python25\lib\distutils\filelist.py", line 298, in findall
    stat = os.stat(fullname)
WindowsError: [Error 2] The system cannot find the file specified: 'some file '
}}}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11928>
_______________________________________

From report at bugs.python.org  Wed Apr 27 11:39:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Apr 2011 09:39:59 +0000
Subject: [issue11928] fail on filename with space at the end
In-Reply-To: <1303836707.17.0.285457821827.issue11928@psf.upfronthosting.co.za>
Message-ID: <1303897199.93.0.696369713829.issue11928@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> WindowsError: [Error 2] The system cannot find the file specified: 'some file '

The strange thing is that the filename is correct (I feared it was a strip() call somewhere that caused the bug), and that you get a WindowsError.  This makes me think that the fault lies in the OS, not in distutils.  I can?t reproduce your bug on linux2.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11928>
_______________________________________

From report at bugs.python.org  Wed Apr 27 12:04:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Apr 2011 10:04:55 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1303898695.39.0.84003869301.issue10318@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> There are a lot of examples that use a bare ?python?; changing all of
> those would cause merging pains.

I?ve changed my mind.  Given the python/python2/python3 drama with distributions, I now think that we should use ?python3? in the 3.x docs.  Merging is not hard.

----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Wed Apr 27 12:07:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Apr 2011 10:07:48 +0000
Subject: [issue11182] remove unused undocumented pydoc.Scanner class
In-Reply-To: <1297405755.94.0.782663220355.issue11182@psf.upfronthosting.co.za>
Message-ID: <1303898868.07.0.187184857741.issue11182@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
stage:  -> needs patch
title: pydoc.Scanner class not used by anything -> remove unused undocumented pydoc.Scanner class

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11182>
_______________________________________

From report at bugs.python.org  Wed Apr 27 12:09:32 2011
From: report at bugs.python.org (ysj.ray)
Date: Wed, 27 Apr 2011 10:09:32 +0000
Subject: [issue11934] build with --prefix=/dev/null and zlib enabled in
	Modules/Setup failed
In-Reply-To: <1303898972.2.0.53608607185.issue11934@psf.upfronthosting.co.za>
Message-ID: <1303898972.2.0.53608607185.issue11934@psf.upfronthosting.co.za>


New submission from ysj.ray <ysj.ray at gmail.com>:

The development guide(http://docs.python.org/devguide/setup.html) suggested that one can build with "--prefix=/dev/null" in order to avoid accidentally install it. But in the Modules/Setup.dist the zlib module is defined as:

zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz

So configure with "--prefix=/dev/null " and enable zlib in Module/Setup and then make results in such error: (debian 5)

cc1: error: /dev/null/include: Not a directory


Not sure if this is really a problem. But I need to modify the Module/Setup zlib line to
"""
zlib zlibmodule.c -L$(exec_prefix)/lib -lz
"""
instead of just uncomment it to make my build process success. I think it's better to be improved.

----------
components: Build
messages: 134544
nosy: ysj.ray
priority: normal
severity: normal
status: open
title: build with --prefix=/dev/null and zlib enabled in Modules/Setup failed
type: compile error
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11934>
_______________________________________

From report at bugs.python.org  Wed Apr 27 12:11:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Apr 2011 10:11:16 +0000
Subject: [issue10616] Change PyObject_AsCharBuffer() error message
In-Reply-To: <1291394615.71.0.46026990965.issue10616@psf.upfronthosting.co.za>
Message-ID: <1303899076.4.0.816901656783.issue10616@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 to Antoine?s +1.

----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10616>
_______________________________________

From report at bugs.python.org  Wed Apr 27 12:13:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Apr 2011 10:13:16 +0000
Subject: [issue6780] startswith error message is incomplete
In-Reply-To: <1251149593.57.0.654081758843.issue6780@psf.upfronthosting.co.za>
Message-ID: <1303899196.85.0.843862223075.issue6780@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I would have used with self.assertRaises to write the tests, thinking it would be less verbose/cumbersome.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6780>
_______________________________________

From report at bugs.python.org  Wed Apr 27 12:14:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Apr 2011 10:14:37 +0000
Subject: [issue11924] Pickle and copyreg modules don't document the interface
In-Reply-To: <1303766863.75.0.154822649898.issue11924@psf.upfronthosting.co.za>
Message-ID: <1303899277.95.0.757472365115.issue11924@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Documentation
nosy: +eric.araujo
stage:  -> needs patch
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11924>
_______________________________________

From report at bugs.python.org  Wed Apr 27 12:16:12 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Apr 2011 10:16:12 +0000
Subject: [issue6780] startswith error message is incomplete
In-Reply-To: <1251149593.57.0.654081758843.issue6780@psf.upfronthosting.co.za>
Message-ID: <1303899372.55.0.210728547199.issue6780@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

In 3.1 I had to use try/except because cm.exception is new in 2.7/3.2.
I used assertRaises on the other branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6780>
_______________________________________

From report at bugs.python.org  Wed Apr 27 12:20:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Apr 2011 10:20:25 +0000
Subject: [issue11918] Drop OS/2 and VMS support in Python 3.3
In-Reply-To: <1303741305.45.0.808920067617.issue11918@psf.upfronthosting.co.za>
Message-ID: <1303899625.78.0.271979800159.issue11918@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11918>
_______________________________________

From report at bugs.python.org  Wed Apr 27 12:23:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Apr 2011 10:23:44 +0000
Subject: [issue11926] help("keywords") returns incomplete list of keywords
In-Reply-To: <1303782960.65.0.80653815306.issue11926@psf.upfronthosting.co.za>
Message-ID: <1303899824.04.0.675339241267.issue11926@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

True and False are keywords in 3.x for the parser (IIUC), even though they?re still instances of bool.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11926>
_______________________________________

From report at bugs.python.org  Wed Apr 27 12:24:27 2011
From: report at bugs.python.org (Xuanji Li)
Date: Wed, 27 Apr 2011 10:24:27 +0000
Subject: [issue9938] Documentation for argparse interactive use
In-Reply-To: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za>
Message-ID: <1303899867.28.0.142696158033.issue9938@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

I don't think it's best to create a new subclass to throw an ArgumentParserExit exception; if I read the stack trace I'd see that an ArgumentError was thrown, then caught, then an ArgumentParserExit was thrown, which IMHO is confusing. In the current design, parse_known_errors catches an ArgumentError and then exits. I propose that the user be optionally allowed to turn off the handling of ArgumentError and to handle it himself instead through an exit_on_argument_error flag. 

Attached patch does this. Also I think this issue falls under component 'Lib' too.

----------
components: +Library (Lib)
keywords: +patch
Added file: http://bugs.python.org/file21793/issue9938.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9938>
_______________________________________

From report at bugs.python.org  Wed Apr 27 12:26:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Apr 2011 10:26:04 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1303899964.83.0.766762636547.issue11682@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

(?Create patch? does not work for some reason, I?ll report that to the metatracker in a few days if nobody does it first)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11682>
_______________________________________

From report at bugs.python.org  Wed Apr 27 12:47:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Apr 2011 10:47:29 +0000
Subject: [issue11918] Drop OS/2 and VMS support in Python 3.3
In-Reply-To: <1303741305.45.0.808920067617.issue11918@psf.upfronthosting.co.za>
Message-ID: <1303901249.7.0.106613494737.issue11918@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11918>
_______________________________________

From report at bugs.python.org  Wed Apr 27 10:57:25 2011
From: report at bugs.python.org (Tim Golden)
Date: Wed, 27 Apr 2011 08:57:25 +0000
Subject: [issue9614] _pickle is not entirely 64-bit safe
In-Reply-To: <1303893117.51.0.182512648317.issue9614@psf.upfronthosting.co.za>
Message-ID: <4DB7DA6F.3080103@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

Attached. Looks like they're still there.

----------
nosy: +tim.golden
Added file: http://bugs.python.org/file21792/BuildLog.htm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9614>
_______________________________________
-------------- next part --------------
??<html>

<head>

<META HTTP-EQUIV="Content-Type" content="text/html; charset=utf-16">

</head>

<body>

<pre>

<table width=100% bgcolor=#CFCFE5><tr> <td> <font face=arial size=+3>

Build Log

</font></table><table width=* cellspacing=0 cellpadding=0><tr><td width=0 bgcolor=#EDEDF5>&nbsp;</td><td width=0 bgcolor=#FFFFFF>&nbsp;</td><td width=*><pre>

<h3>Build started: Project: pythoncore, Configuration: Debug|x64</h3>

</pre></table><table width=100% bgcolor=#DFDFE5><tr><td><font face=arial size=+2>

Command Lines

</font></table><table width=* cellspacing=0 cellpadding=0><tr><td width=0 bgcolor=#EDEDF5>&nbsp;</td><td width=0 bgcolor=#FFFFFF>&nbsp;</td><td width=*><pre>Creating temporary file "C:\Users\goldent\AppData\Local\Temp\RSP00000155121672.rsp" with contents

[

/Od /I &quot;..\Python&quot; /I &quot;..\Modules\zlib&quot; /I &quot;..\Include&quot; /I &quot;..\PC&quot; /D &quot;_USRDLL&quot; /D &quot;Py_BUILD_CORE&quot; /D &quot;Py_ENABLE_SHARED&quot; /D &quot;WIN32&quot; /D &quot;_DEBUG&quot; /D &quot;_WIN64&quot; /D &quot;_M_X64&quot; /D &quot;_WIN32&quot; /D &quot;_WINDLL&quot; /GF /FD /MDd /Gy /Fo&quot;C:\work-in-progress\python\cpython\PCbuild\x64-temp-Debug\pythoncore\\&quot; /Fd&quot;C:\work-in-progress\python\cpython\PCbuild\x64-temp-Debug\pythoncore\\vc90.pdb&quot; /W3 /c /Zi  /Zm200  /USECL:MS_OPTERON /GS-


&quot;..\Python\traceback.c&quot;


&quot;..\Python\thread.c&quot;


&quot;..\Python\sysmodule.c&quot;


&quot;..\Python\symtable.c&quot;


&quot;..\Python\structmember.c&quot;


&quot;..\Python\pythonrun.c&quot;


&quot;..\Python\Python-ast.c&quot;


&quot;..\Python\dtoa.c&quot;


&quot;..\Python\pystrtod.c&quot;


&quot;..\Python\pystrcmp.c&quot;


&quot;..\Python\pystate.c&quot;


&quot;..\Python\pytime.c&quot;


&quot;..\Python\pymath.c&quot;


&quot;..\Python\pyctype.c&quot;


&quot;..\Python\pyarena.c&quot;


&quot;..\Python\peephole.c&quot;


&quot;..\Python\mystrtoul.c&quot;


&quot;..\Python\mysnprintf.c&quot;


&quot;..\Python\modsupport.c&quot;


&quot;..\Python\marshal.c&quot;


&quot;..\Python\importdl.c&quot;


&quot;..\Python\import.c&quot;


&quot;..\Python\graminit.c&quot;


&quot;..\Python\getversion.c&quot;


&quot;..\Python\getplatform.c&quot;


&quot;..\Python\getopt.c&quot;


&quot;..\Python\getcopyright.c&quot;


&quot;..\Python\getcompiler.c&quot;


&quot;..\Python\getargs.c&quot;


&quot;..\Python\future.c&quot;


&quot;..\Python\frozen.c&quot;


&quot;..\Python\formatter_unicode.c&quot;


&quot;..\Python\fileutils.c&quot;


&quot;..\Python\errors.c&quot;


&quot;..\Python\dynload_win.c&quot;


&quot;..\Python\compile.c&quot;


&quot;..\Python\codecs.c&quot;


&quot;..\Python\ceval.c&quot;


&quot;..\Python\bltinmodule.c&quot;


&quot;..\Python\ast.c&quot;


&quot;..\Python\asdl.c&quot;


&quot;..\Python\_warnings.c&quot;


&quot;..\PC\msvcrtmodule.c&quot;


&quot;..\PC\import_nt.c&quot;


&quot;..\PC\getpathp.c&quot;


&quot;..\PC\dl_nt.c&quot;


&quot;..\PC\config.c&quot;


&quot;..\PC\winreg.c&quot;


&quot;..\PC\_subprocess.c&quot;


&quot;..\Parser\tokenizer.c&quot;


&quot;..\Parser\parsetok.c&quot;


&quot;..\Parser\parser.c&quot;


&quot;..\Parser\node.c&quot;


&quot;..\Parser\myreadline.c&quot;


&quot;..\Parser\metagrammar.c&quot;


&quot;..\Parser\listnode.c&quot;


&quot;..\Parser\grammar1.c&quot;


&quot;..\Parser\grammar.c&quot;


&quot;..\Parser\firstsets.c&quot;


&quot;..\Parser\bitset.c&quot;


&quot;..\Parser\acceler.c&quot;


&quot;..\Objects\weakrefobject.c&quot;


&quot;..\Objects\unicodeobject.c&quot;


&quot;..\Objects\unicodectype.c&quot;


&quot;..\Objects\typeobject.c&quot;


&quot;..\Objects\tupleobject.c&quot;


&quot;..\Objects\structseq.c&quot;


&quot;..\Objects\sliceobject.c&quot;


&quot;..\Objects\setobject.c&quot;


&quot;..\Objects\rangeobject.c&quot;


&quot;..\Objects\obmalloc.c&quot;


&quot;..\Objects\object.c&quot;


&quot;..\Objects\moduleobject.c&quot;


&quot;..\Objects\methodobject.c&quot;


&quot;..\Objects\memoryobject.c&quot;


&quot;..\Objects\longobject.c&quot;


&quot;..\Objects\listobject.c&quot;


&quot;..\Objects\iterobject.c&quot;


&quot;..\Objects\genobject.c&quot;


&quot;..\Objects\funcobject.c&quot;


&quot;..\Objects\frameobject.c&quot;


&quot;..\Objects\floatobject.c&quot;


&quot;..\Objects\fileobject.c&quot;


&quot;..\Objects\exceptions.c&quot;


&quot;..\Objects\enumobject.c&quot;


&quot;..\Objects\dictobject.c&quot;


&quot;..\Objects\descrobject.c&quot;


&quot;..\Objects\complexobject.c&quot;


&quot;..\Objects\codeobject.c&quot;


&quot;..\Objects\classobject.c&quot;


&quot;..\Objects\cellobject.c&quot;


&quot;..\Objects\capsule.c&quot;


&quot;..\Objects\bytesobject.c&quot;


&quot;..\Objects\bytearrayobject.c&quot;


&quot;..\Objects\bytes_methods.c&quot;


&quot;..\Objects\boolobject.c&quot;


&quot;..\Objects\abstract.c&quot;


&quot;..\Modules\cjkcodecs\multibytecodec.c&quot;


&quot;..\Modules\cjkcodecs\_codecs_tw.c&quot;


&quot;..\Modules\cjkcodecs\_codecs_kr.c&quot;


&quot;..\Modules\cjkcodecs\_codecs_jp.c&quot;


&quot;..\Modules\cjkcodecs\_codecs_iso2022.c&quot;


&quot;..\Modules\cjkcodecs\_codecs_hk.c&quot;


&quot;..\Modules\cjkcodecs\_codecs_cn.c&quot;


&quot;..\Modules\_io\_iomodule.c&quot;


&quot;..\Modules\_io\textio.c&quot;


&quot;..\Modules\_io\iobase.c&quot;


&quot;..\Modules\_io\bufferedio.c&quot;


&quot;..\Modules\_io\stringio.c&quot;


&quot;..\Modules\_io\bytesio.c&quot;


&quot;..\Modules\_io\fileio.c&quot;


&quot;..\Modules\zlibmodule.c&quot;


&quot;..\Modules\zipimport.c&quot;


&quot;..\Modules\xxsubtype.c&quot;


&quot;..\Modules\timemodule.c&quot;


&quot;..\Modules\_threadmodule.c&quot;


&quot;..\Modules\symtablemodule.c&quot;


&quot;..\Modules\signalmodule.c&quot;


&quot;..\Modules\sha512module.c&quot;


&quot;..\Modules\sha256module.c&quot;


&quot;..\Modules\sha1module.c&quot;


&quot;..\Modules\posixmodule.c&quot;


&quot;..\Modules\parsermodule.c&quot;


&quot;..\Modules\operator.c&quot;


&quot;..\Modules\mmapmodule.c&quot;


&quot;..\Modules\md5module.c&quot;


&quot;..\Modules\mathmodule.c&quot;


&quot;..\Modules\main.c&quot;


&quot;..\Modules\itertoolsmodule.c&quot;


&quot;..\Modules\gcmodule.c&quot;


&quot;..\Modules\faulthandler.c&quot;


&quot;..\Modules\errnomodule.c&quot;


&quot;..\Modules\_datetimemodule.c&quot;


&quot;..\Modules\cmathmodule.c&quot;


&quot;..\Modules\binascii.c&quot;


&quot;..\Modules\audioop.c&quot;


&quot;..\Modules\atexitmodule.c&quot;


&quot;..\Modules\arraymodule.c&quot;


&quot;..\Modules\_weakref.c&quot;


&quot;..\Modules\_time.c&quot;


&quot;..\Modules\_struct.c&quot;


&quot;..\Modules\_sre.c&quot;


&quot;..\Modules\_randommodule.c&quot;


&quot;..\Modules\_pickle.c&quot;


&quot;..\Modules\_math.c&quot;


&quot;..\Modules\_lsprof.c&quot;


&quot;..\Modules\_localemodule.c&quot;


&quot;..\Modules\_json.c&quot;


&quot;..\Modules\_heapqmodule.c&quot;


&quot;..\Modules\_functoolsmodule.c&quot;


&quot;..\Modules\_csv.c&quot;


&quot;..\Modules\_collectionsmodule.c&quot;


&quot;..\Modules\_codecsmodule.c&quot;


&quot;..\Modules\_bisectmodule.c&quot;

]

Creating command line "cl.exe @C:\Users\goldent\AppData\Local\Temp\RSP00000155121672.rsp /nologo /errorReport:prompt"

Creating command line "rc.exe /d "_DEBUG" /l 0x409 /I "..\Include" /I "..\PC" /fo"C:\work-in-progress\python\cpython\PCbuild\x64-temp-Debug\pythoncore\/python_nt.res" "..\PC\python_nt.rc""

Creating temporary file "C:\Users\goldent\AppData\Local\Temp\BAT00000255121672.bat" with contents

[

@echo off


&quot;C:\work-in-progress\python\cpython\PCbuild\make_buildinfo.exe&quot; Debug &quot;C:\work-in-progress\python\cpython\PCbuild\x64-temp-Debug\pythoncore\\&quot;


if errorlevel 1 goto VCReportError


goto VCEnd


:VCReportError


echo Project : error PRJ0019: A tool returned an error code from &quot;Generate build information...&quot;


exit 1


:VCEnd

]

Creating command line "C:\Users\goldent\AppData\Local\Temp\BAT00000255121672.bat"

Creating temporary file "C:\Users\goldent\AppData\Local\Temp\RSP00000355121672.rsp" with contents

[

/OUT:&quot;C:\work-in-progress\python\cpython\PCbuild\\amd64\\python33_d.dll&quot; /INCREMENTAL:NO /LIBPATH:&quot;C:\work-in-progress\python\cpython\PCbuild\\amd64\\&quot; /DLL /MANIFEST /MANIFESTFILE:&quot;C:\work-in-progress\python\cpython\PCbuild\x64-temp-Debug\pythoncore\\python33_d.dll.intermediate.manifest&quot; /MANIFESTUAC:&quot;level='asInvoker' uiAccess='false'&quot; /NODEFAULTLIB:&quot;libc&quot; /DEBUG /PDB:&quot;C:\work-in-progress\python\cpython\PCbuild\\amd64\python33_d.pdb&quot; /SUBSYSTEM:WINDOWS /BASE:&quot;0x1e000000&quot; /DYNAMICBASE:NO /IMPLIB:&quot;C:\work-in-progress\python\cpython\PCbuild\\amd64\python33_d.lib&quot; /MACHINE:X64 &quot;C:\work-in-progress\python\cpython\PCbuild\x64-temp-Debug\pythoncore\getbuildinfo.o&quot; kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib


&quot;.\x64-temp-Debug\pythoncore\_bisectmodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_codecsmodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_collectionsmodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_csv.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_functoolsmodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_heapqmodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_json.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_localemodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_lsprof.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_math.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_pickle.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_randommodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_sre.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_struct.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_time.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_weakref.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\arraymodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\atexitmodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\audioop.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\binascii.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\cmathmodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_datetimemodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\errnomodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\faulthandler.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\gcmodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\itertoolsmodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\main.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\mathmodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\md5module.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\mmapmodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\operator.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\parsermodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\posixmodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\rotatingtree.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\sha1module.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\sha256module.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\sha512module.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\signalmodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\symtablemodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_threadmodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\timemodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\xxsubtype.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\zipimport.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\zlibmodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\fileio.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\bytesio.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\stringio.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\bufferedio.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\iobase.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\textio.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_iomodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\adler32.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\compress.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\crc32.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\deflate.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\gzio.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\infback.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\inffast.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\inflate.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\inftrees.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\trees.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\uncompr.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\zutil.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_codecs_cn.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_codecs_hk.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_codecs_iso2022.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_codecs_jp.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_codecs_kr.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_codecs_tw.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\multibytecodec.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\abstract.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\boolobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\bytes_methods.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\bytearrayobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\bytesobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\capsule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\cellobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\classobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\codeobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\complexobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\descrobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\dictobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\enumobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\exceptions.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\fileobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\floatobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\frameobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\funcobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\genobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\iterobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\listobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\longobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\memoryobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\methodobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\moduleobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\object.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\obmalloc.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\rangeobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\setobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\sliceobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\structseq.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\tupleobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\typeobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\unicodectype.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\unicodeobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\weakrefobject.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\acceler.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\bitset.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\firstsets.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\grammar.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\grammar1.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\listnode.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\metagrammar.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\myreadline.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\node.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\parser.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\parsetok.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\tokenizer.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_subprocess.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\winreg.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\config.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\dl_nt.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\getpathp.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\import_nt.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\msvcrtmodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\_warnings.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\asdl.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\ast.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\bltinmodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\ceval.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\codecs.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\compile.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\dynamic_annotations.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\dynload_win.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\errors.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\fileutils.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\formatter_unicode.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\frozen.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\future.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\getargs.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\getcompiler.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\getcopyright.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\getopt.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\getplatform.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\getversion.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\graminit.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\import.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\importdl.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\marshal.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\modsupport.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\mysnprintf.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\mystrtoul.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\peephole.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\pyarena.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\pyctype.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\pyfpe.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\pymath.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\pytime.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\pystate.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\pystrcmp.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\pystrtod.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\dtoa.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\Python-ast.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\pythonrun.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\structmember.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\symtable.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\sysmodule.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\thread.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\traceback.obj&quot;


&quot;.\x64-temp-Debug\pythoncore\python_nt.res&quot;

]

Creating command line "link.exe @C:\Users\goldent\AppData\Local\Temp\RSP00000355121672.rsp /NOLOGO /ERRORREPORT:PROMPT"

Creating temporary file "C:\Users\goldent\AppData\Local\Temp\RSP00000455121672.rsp" with contents

[

/outputresource:&quot;.\amd64\python33_d.dll;#2&quot; /manifest


&quot;.\x64-temp-Debug\pythoncore\python33_d.dll.intermediate.manifest&quot;

]

Creating command line "mt.exe @C:\Users\goldent\AppData\Local\Temp\RSP00000455121672.rsp /nologo"

Creating temporary file "C:\Users\goldent\AppData\Local\Temp\BAT00000555121672.bat" with contents

[

@echo Manifest resource last updated at %TIME% on %DATE% &gt; &quot;.\x64-temp-Debug\pythoncore\mt.dep&quot;

]

Creating command line "C:\Users\goldent\AppData\Local\Temp\BAT00000555121672.bat"

</pre></table><table width=100% bgcolor=#DFDFE5><tr><td><font face=arial size=+2>

Output Window

</font></table><table width=* cellspacing=0 cellpadding=0><tr><td width=0 bgcolor=#EDEDF5>&nbsp;</td><td width=0 bgcolor=#FFFFFF>&nbsp;</td><td width=*><pre>Compiling...

traceback.c

..\Python\traceback.c(500) : warning C4267: 'function' : conversion from 'size_t' to 'unsigned int', possible loss of data

..\Python\traceback.c(508) : warning C4267: 'function' : conversion from 'size_t' to 'unsigned int', possible loss of data

..\Python\traceback.c(519) : warning C4267: 'function' : conversion from 'size_t' to 'unsigned int', possible loss of data

..\Python\traceback.c(533) : warning C4267: 'function' : conversion from 'size_t' to 'unsigned int', possible loss of data

..\Python\traceback.c(541) : warning C4267: 'function' : conversion from 'size_t' to 'unsigned int', possible loss of data

..\Python\traceback.c(546) : warning C4267: 'function' : conversion from 'size_t' to 'unsigned int', possible loss of data

..\Python\traceback.c(548) : warning C4267: 'function' : conversion from 'size_t' to 'unsigned int', possible loss of data

..\Python\traceback.c(554) : warning C4267: 'function' : conversion from 'size_t' to 'unsigned int', possible loss of data

..\Python\traceback.c(566) : warning C4267: 'function' : conversion from 'size_t' to 'unsigned int', possible loss of data

..\Python\traceback.c(575) : warning C4267: 'function' : conversion from 'size_t' to 'unsigned int', possible loss of data

..\Python\traceback.c(601) : warning C4267: 'function' : conversion from 'size_t' to 'unsigned int', possible loss of data

..\Python\traceback.c(603) : warning C4267: 'function' : conversion from 'size_t' to 'unsigned int', possible loss of data

..\Python\traceback.c(605) : warning C4267: 'function' : conversion from 'size_t' to 'unsigned int', possible loss of data

..\Python\traceback.c(628) : warning C4267: 'function' : conversion from 'size_t' to 'unsigned int', possible loss of data

thread.c

sysmodule.c

symtable.c

structmember.c

pythonrun.c

Python-ast.c

..\Python\Python-ast.c(3403) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(3409) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(3439) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(3445) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(3498) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(3504) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(3606) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(3612) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(3631) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(3637) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(3697) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(3703) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(3722) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(3728) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(3769) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(3775) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(3794) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(3800) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(3853) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(3859) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(3890) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(3896) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4014) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4020) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4039) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4045) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4090) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4096) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4115) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4121) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4165) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4171) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4190) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4196) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4251) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4257) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4324) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4330) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4349) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4355) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4374) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4380) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4412) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4418) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4437) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4443) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4508) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4514) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4557) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4563) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4605) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4611) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4641) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4647) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4787) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4793) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(4994) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5000) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5019) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5025) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5055) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5061) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5104) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5110) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5153) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5159) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5215) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5221) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5265) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5271) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5337) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5343) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5362) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5368) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5415) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5421) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5440) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5446) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5749) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5755) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5798) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5804) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5968) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(5974) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(6323) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(6329) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(6423) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(6429) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(6473) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(6479) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(6520) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(6526) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(6567) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(6573) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(6592) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\Python-ast.c(6598) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

dtoa.c

..\Python\dtoa.c(1529) : warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data

..\Python\dtoa.c(1539) : warning C4244: '-=' : conversion from '__int64' to 'int', possible loss of data

..\Python\dtoa.c(1545) : warning C4244: '+=' : conversion from '__int64' to 'int', possible loss of data

pystrtod.c

..\Python\pystrtod.c(902) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\pystrtod.c(1023) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

pystrcmp.c

pystate.c

pytime.c

pymath.c

pyctype.c

pyarena.c

peephole.c

..\Python\peephole.c(134) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data

..\Python\peephole.c(252) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data

..\Python\peephole.c(303) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data

..\Python\peephole.c(375) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data

..\Python\peephole.c(422) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\peephole.c(477) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data

..\Python\peephole.c(492) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data

..\Python\peephole.c(535) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\peephole.c(588) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\peephole.c(606) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\peephole.c(634) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\peephole.c(645) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data

..\Python\peephole.c(677) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\peephole.c(691) : warning C4244: '-=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\peephole.c(722) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\peephole.c(751) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data

..\Python\peephole.c(761) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data

mystrtoul.c

mysnprintf.c

modsupport.c

marshal.c

Generating Code...

Compiling...

importdl.c

import.c

graminit.c

getversion.c

getplatform.c

getopt.c

getcopyright.c

getcompiler.c

getargs.c

..\Python\getargs.c(372) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\getargs.c(484) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\getargs.c(869) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\getargs.c(924) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\getargs.c(932) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\getargs.c(977) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\getargs.c(1123) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\getargs.c(1454) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\getargs.c(1455) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

future.c

frozen.c

formatter_unicode.c

c:\work-in-progress\python\cpython\python\../Objects/stringlib/formatter.h(979) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

c:\work-in-progress\python\cpython\python\../Objects/stringlib/formatter.h(1151) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

c:\work-in-progress\python\cpython\python\../Objects/stringlib/formatter.h(1155) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

fileutils.c

..\Python\fileutils.c(410) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data

errors.c

dynload_win.c

compile.c

..\Python\compile.c(340) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'long', possible loss of data

..\Python\compile.c(385) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'long', possible loss of data

..\Python\compile.c(480) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\compile.c(535) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\compile.c(949) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'long', possible loss of data

..\Python\compile.c(964) : warning C4244: 'return' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\compile.c(1256) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\compile.c(1401) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\compile.c(3687) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\compile.c(3713) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\compile.c(3739) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\compile.c(3907) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\compile.c(3911) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\compile.c(3951) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\compile.c(3958) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

codecs.c

ceval.c

..\Python\ceval.c(3955) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Python\ceval.c(4143) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

bltinmodule.c

ast.c

Generating Code...

Compiling...

asdl.c

_warnings.c

msvcrtmodule.c

import_nt.c

getpathp.c

dl_nt.c

config.c

winreg.c

_subprocess.c

tokenizer.c

..\Parser\tokenizer.c(661) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data

..\Parser\tokenizer.c(692) : warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data

parsetok.c

..\Parser\parsetok.c(206) : warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data

parser.c

node.c

myreadline.c

metagrammar.c

listnode.c

grammar1.c

grammar.c

..\Parser\grammar.c(66) : warning C4244: 'return' : conversion from '__int64' to 'int', possible loss of data

..\Parser\grammar.c(108) : warning C4244: 'return' : conversion from '__int64' to 'int', possible loss of data

firstsets.c

bitset.c

Generating Code...

Compiling...

acceler.c

weakrefobject.c

unicodeobject.c

unicodectype.c

typeobject.c

tupleobject.c

structseq.c

sliceobject.c

setobject.c

rangeobject.c

..\Objects\rangeobject.c(310) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'long', possible loss of data

obmalloc.c

..\Objects\obmalloc.c(912) : warning C4244: '=' : conversion from '__int64' to 'unsigned int', possible loss of data

object.c

moduleobject.c

methodobject.c

memoryobject.c

longobject.c

listobject.c

iterobject.c

genobject.c

funcobject.c

..\Objects\funcobject.c(632) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Objects\funcobject.c(633) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Objects\funcobject.c(633) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

Generating Code...

Compiling...

frameobject.c

..\Objects\frameobject.c(480) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Objects\frameobject.c(513) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Objects\frameobject.c(871) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Objects\frameobject.c(872) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Objects\frameobject.c(918) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Objects\frameobject.c(919) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

floatobject.c

fileobject.c

exceptions.c

enumobject.c

dictobject.c

descrobject.c

..\Objects\descrobject.c(897) : warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data

complexobject.c

codeobject.c

classobject.c

cellobject.c

capsule.c

bytesobject.c

bytearrayobject.c

bytes_methods.c

boolobject.c

abstract.c

multibytecodec.c

_codecs_tw.c

_codecs_kr.c

Generating Code...

Compiling...

_codecs_jp.c

_codecs_iso2022.c

_codecs_hk.c

_codecs_cn.c

_iomodule.c

textio.c

..\Modules\_io\textio.c(2281) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

iobase.c

bufferedio.c

stringio.c

bytesio.c

fileio.c

..\Modules\_io\fileio.c(617) : warning C4267: 'function' : conversion from 'size_t' to 'unsigned int', possible loss of data

..\Modules\_io\fileio.c(673) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'unsigned int', possible loss of data

zlibmodule.c

..\Modules\zlibmodule.c(133) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned int', possible loss of data

..\Modules\zlibmodule.c(224) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned int', possible loss of data

..\Modules\zlibmodule.c(231) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data

..\Modules\zlibmodule.c(285) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data

..\Modules\zlibmodule.c(436) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Modules\zlibmodule.c(448) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data

..\Modules\zlibmodule.c(465) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data

..\Modules\zlibmodule.c(519) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Modules\zlibmodule.c(540) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data

..\Modules\zlibmodule.c(570) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data

..\Modules\zlibmodule.c(959) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data

..\Modules\zlibmodule.c(962) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data

..\Modules\zlibmodule.c(997) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data

..\Modules\zlibmodule.c(1000) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data

zipimport.c

xxsubtype.c

timemodule.c

_threadmodule.c

symtablemodule.c

signalmodule.c

sha512module.c

..\Modules\sha512module.c(313) : warning C4244: '+=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Modules\sha512module.c(328) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

sha256module.c

..\Modules\sha256module.c(287) : warning C4244: '+=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Modules\sha256module.c(302) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

Generating Code...

Compiling...

sha1module.c

..\Modules\sha1module.c(223) : warning C4244: '+=' : conversion from 'Py_ssize_t' to 'SHA1_INT32', possible loss of data

posixmodule.c

..\Modules\posixmodule.c(374) : warning C4244: '=' : conversion from '__int64' to 'off_t', possible loss of data

..\Modules\posixmodule.c(5472) : warning C4244: 'function' : conversion from 'Py_intptr_t' to 'long', possible loss of data

parsermodule.c

operator.c

mmapmodule.c

md5module.c

..\Modules\md5module.c(248) : warning C4244: '+=' : conversion from 'Py_ssize_t' to 'MD5_INT32', possible loss of data

mathmodule.c

main.c

itertoolsmodule.c

gcmodule.c

faulthandler.c

..\Modules\faulthandler.c(263) : warning C4267: 'function' : conversion from 'size_t' to 'unsigned int', possible loss of data

..\Modules\faulthandler.c(264) : warning C4267: 'function' : conversion from 'size_t' to 'unsigned int', possible loss of data

..\Modules\faulthandler.c(265) : warning C4267: 'function' : conversion from 'size_t' to 'unsigned int', possible loss of data

..\Modules\faulthandler.c(442) : warning C4267: 'function' : conversion from 'size_t' to 'unsigned int', possible loss of data

errnomodule.c

_datetimemodule.c

cmathmodule.c

binascii.c

audioop.c

atexitmodule.c

arraymodule.c

_weakref.c

_time.c

Generating Code...

Compiling...

_struct.c

_sre.c

c:\work-in-progress\python\cpython\modules\_sre.c(1895) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

c:\work-in-progress\python\cpython\modules\_sre.c(1898) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

c:\work-in-progress\python\cpython\modules\_sre.c(1932) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

c:\work-in-progress\python\cpython\modules\_sre.c(1935) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

c:\work-in-progress\python\cpython\modules\_sre.c(2079) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

c:\work-in-progress\python\cpython\modules\_sre.c(2082) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

c:\work-in-progress\python\cpython\modules\_sre.c(2209) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

c:\work-in-progress\python\cpython\modules\_sre.c(2212) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

c:\work-in-progress\python\cpython\modules\_sre.c(2361) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

c:\work-in-progress\python\cpython\modules\_sre.c(2364) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

c:\work-in-progress\python\cpython\modules\_sre.c(3750) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

c:\work-in-progress\python\cpython\modules\_sre.c(3753) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

c:\work-in-progress\python\cpython\modules\_sre.c(3783) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

c:\work-in-progress\python\cpython\modules\_sre.c(3786) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

_randommodule.c

..\Modules\_randommodule.c(237) : warning C4244: 'initializing' : conversion from 'Py_hash_t' to 'long', possible loss of data

_pickle.c

..\Modules\_pickle.c(156) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Modules\_pickle.c(195) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Modules\_pickle.c(754) : warning C4244: 'return' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Modules\_pickle.c(1278) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'long', possible loss of data

..\Modules\_pickle.c(1285) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data

..\Modules\_pickle.c(1952) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Modules\_pickle.c(2233) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Modules\_pickle.c(2493) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Modules\_pickle.c(4350) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Modules\_pickle.c(4615) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Modules\_pickle.c(4655) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Modules\_pickle.c(4896) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Modules\_pickle.c(4943) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Modules\_pickle.c(4960) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Modules\_pickle.c(4991) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

..\Modules\_pickle.c(5147) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

_math.c

_lsprof.c

_localemodule.c

_json.c

_heapqmodule.c

_functoolsmodule.c

_csv.c

_collectionsmodule.c

_codecsmodule.c

_bisectmodule.c

Generating Code...

Compiling resources...

Microsoft (R) Windows (R) Resource Compiler Version 6.0.5724.0

Copyright (C) Microsoft Corporation.  All rights reserved.

Generate build information...

cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -D_DEBUG -MDd ..\Modules\getbuildinfo.c -Fo"C:\work-in-progress\python\cpython\PCbuild\x64-temp-Debug\pythoncore\\getbuildinfo.o" -I..\Include -I..\PC

Microsoft (R) C/C++ Optimizing Compiler Version 15.00.21022.08 for x64

Copyright (C) Microsoft Corporation.  All rights reserved.

getbuildinfo.c

Linking...

   Creating library C:\work-in-progress\python\cpython\PCbuild\\amd64\python33_d.lib and object C:\work-in-progress\python\cpython\PCbuild\\amd64\python33_d.exp

Embedding manifest...

</pre></table><table width=100% bgcolor=#DFDFE5><tr><td><font face=arial size=+2>

Results

</font></table><table width=* cellspacing=0 cellpadding=0><tr><td width=0 bgcolor=#EDEDF5>&nbsp;</td><td width=0 bgcolor=#FFFFFF>&nbsp;</td><td width=*><pre>Build log was saved at "file://C:\work-in-progress\python\cpython\PCbuild\x64-temp-Debug\pythoncore\BuildLog.htm"

pythoncore - 0 error(s), 239 warning(s)

</pre></table><table   width=100% height=20 bgcolor=#CFCFE5><tr><td><font face=arial size=+2>

</font></table></body></html>

From report at bugs.python.org  Wed Apr 27 13:23:43 2011
From: report at bugs.python.org (Kasun Herath)
Date: Wed, 27 Apr 2011 11:23:43 +0000
Subject: [issue11927] SMTP_SSL doesn't use port 465 by default
In-Reply-To: <1303836501.95.0.366662026013.issue11927@psf.upfronthosting.co.za>
Message-ID: <1303903423.69.0.129389299124.issue11927@psf.upfronthosting.co.za>


Kasun Herath <kasunh01 at gmail.com> added the comment:

I did a quick patch based on the suggested solution.

(pitrou, thanks for adding to the nosy list or could have missed this)

----------
keywords: +patch
Added file: http://bugs.python.org/file21794/smtplib_default_ports.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11927>
_______________________________________

From report at bugs.python.org  Wed Apr 27 13:39:37 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 27 Apr 2011 11:39:37 +0000
Subject: [issue11935] MMDF/MBOX mailbox need utime
In-Reply-To: <1303904377.39.0.820877441013.issue11935@psf.upfronthosting.co.za>
Message-ID: <1303904377.39.0.820877441013.issue11935@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

According to the de-facto MBOX standard [1] and the MMDF
description [2] mtime and atime are used to detect wether
a mailbox has new mail:

   If the mtime on a nonempty mbox file is greater than the
   atime, the file has new mail.

For [1] this is documented under "UNSPECIFIED DETAILS", though.
The attached patch enables MUAs like mutt(1) to show the
new-mail-has-arrived status in the overview, too.
Note i've randomly chosen 3 seconds; it also could have been 5.

[1] http://qmail.org/man/man5/mbox.html
[2] http://linux.die.net/man/5/mmdf

----------
components: Library (Lib)
files: mailbox.diff
keywords: patch
messages: 134552
nosy: sdaoden
priority: normal
severity: normal
status: open
title: MMDF/MBOX mailbox need utime
versions: Python 3.3
Added file: http://bugs.python.org/file21795/mailbox.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11935>
_______________________________________

From report at bugs.python.org  Wed Apr 27 13:44:38 2011
From: report at bugs.python.org (=?utf-8?q?Pi=C3=A9ronne_Jean-Fran=C3=A7ois?=)
Date: Wed, 27 Apr 2011 11:44:38 +0000
Subject: [issue11918] Drop OS/2 and VMS support in Python 3.3
In-Reply-To: <1303741305.45.0.808920067617.issue11918@psf.upfronthosting.co.za>
Message-ID: <1303904678.64.0.840910181471.issue11918@psf.upfronthosting.co.za>


Pi?ronne Jean-Fran?ois <pieronne at users.sourceforge.net> added the comment:

What we have planed is to release 2.7 in september, and I think we will be on time, so we can start working on 3.x in october, is it compatible with your schedule?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11918>
_______________________________________

From report at bugs.python.org  Wed Apr 27 13:57:55 2011
From: report at bugs.python.org (Xuanji Li)
Date: Wed, 27 Apr 2011 11:57:55 +0000
Subject: [issue3451] Asymptotically faster divmod and str(long)
In-Reply-To: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za>
Message-ID: <1303905475.95.0.908094266479.issue3451@psf.upfronthosting.co.za>


Changes by Xuanji Li <xuanji at gmail.com>:


----------
nosy: +xuanji

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3451>
_______________________________________

From report at bugs.python.org  Wed Apr 27 14:19:34 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 27 Apr 2011 12:19:34 +0000
Subject: [issue10912] PyObject_RichCompare differs in behaviour from
	PyObject_RichCompareBool ; difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1303906774.73.0.946669403282.issue10912@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Reopening, as a 2.7 backport of this would be a nice thing to have.

----------
assignee: rhettinger -> 
status: closed -> open
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Wed Apr 27 14:24:42 2011
From: report at bugs.python.org (Scott Leerssen)
Date: Wed, 27 Apr 2011 12:24:42 +0000
Subject: [issue10761] tarfile.extractall fails to overwrite symlinks
In-Reply-To: <1293063436.61.0.0994372418071.issue10761@psf.upfronthosting.co.za>
Message-ID: <1303907082.34.0.851657990451.issue10761@psf.upfronthosting.co.za>


Scott Leerssen <sleerssen at gmail.com> added the comment:

It happens on RedHat and CentOS 5, but I suspect it would happen on any Unix variant.  Here's a test that exacerbates the issue:


#
# test_tarfile.py
#
# Description:
#       tests for python tarfile module
#
# $Id$
#

import os
import shutil
import tarfile
import tempfile

def test_tar_overwrites_symlink():
    d = tempfile.mkdtemp()
    try:
        new_dir_name = os.path.join(d, 'newdir')
        archive_name = os.path.join(d, 'newdir.tar')
        os.mkdir(new_dir_name)
        source_file_name = os.path.join(new_dir_name, 'source')
        target_link_name = os.path.join(new_dir_name, 'symlink')
        with open(source_file_name, 'w') as f:
            f.write('something\n')
        os.symlink(source_file_name, target_link_name)
        with tarfile.open(archive_name, 'w') as tar:
            for f in [source_file_name, target_link_name]:
                tar.add(f, arcname=os.path.basename(f))
        # this should not raise OSError: [Errno 17] File exists
        with tarfile.open(archive_name, 'r') as tar:
            tar.extractall(path=new_dir_name)
    finally:
        shutil.rmtree(d)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10761>
_______________________________________

From report at bugs.python.org  Wed Apr 27 14:26:15 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 27 Apr 2011 12:26:15 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1303907175.52.0.703682803461.issue11682@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It's because it isn't a true Mercurial clone-and-update - it's a patch queue, which the review generation code doesn't know how to interpret.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11682>
_______________________________________

From report at bugs.python.org  Wed Apr 27 14:35:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Apr 2011 12:35:04 +0000
Subject: [issue11918] Drop OS/2 and VMS support in Python 3.3
In-Reply-To: <1303741305.45.0.808920067617.issue11918@psf.upfronthosting.co.za>
Message-ID: <1303907704.27.0.956825406229.issue11918@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

PEP 398 -- Python 3.3 Release Schedule
http://www.python.org/dev/peps/pep-0398/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11918>
_______________________________________

From report at bugs.python.org  Wed Apr 27 14:41:51 2011
From: report at bugs.python.org (Manveru)
Date: Wed, 27 Apr 2011 12:41:51 +0000
Subject: [issue11874] argparse assertion failure with brackets in metavars
In-Reply-To: <1303201252.58.0.236363581255.issue11874@psf.upfronthosting.co.za>
Message-ID: <1303908111.67.0.371980525792.issue11874@psf.upfronthosting.co.za>


Manveru <manveru at manveru.pl> added the comment:

I was a victim of the same issue, but only after my usage list does not fit in one line. Please fix!

----------
nosy: +manveru

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11874>
_______________________________________

From report at bugs.python.org  Wed Apr 27 14:44:01 2011
From: report at bugs.python.org (Manveru)
Date: Wed, 27 Apr 2011 12:44:01 +0000
Subject: [issue11839] argparse: unexpected behavior of default for
	FileType('w')
In-Reply-To: <1302638190.31.0.523851627026.issue11839@psf.upfronthosting.co.za>
Message-ID: <1303908241.49.0.934533752357.issue11839@psf.upfronthosting.co.za>


Manveru <manveru at manveru.pl> added the comment:

I have the same issue with default here with 2.7.

Fortunately I have my own type function so I can prevent is by changing my internal state. This is however only a workaround for real bug in the argparse.

----------
nosy: +manveru
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11839>
_______________________________________

From report at bugs.python.org  Wed Apr 27 14:54:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Apr 2011 12:54:13 +0000
Subject: [issue11935] MMDF/MBOX mailbox need utime
In-Reply-To: <1303904377.39.0.820877441013.issue11935@psf.upfronthosting.co.za>
Message-ID: <1303908853.46.0.506725003355.issue11935@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/issue11935>
_______________________________________

From report at bugs.python.org  Wed Apr 27 14:55:55 2011
From: report at bugs.python.org (Manveru)
Date: Wed, 27 Apr 2011 12:55:55 +0000
Subject: [issue11588] Add "necessarily inclusive" groups to argparse
In-Reply-To: <1300377092.03.0.159307937388.issue11588@psf.upfronthosting.co.za>
Message-ID: <1303908955.16.0.380282719412.issue11588@psf.upfronthosting.co.za>


Manveru <manveru at manveru.pl> added the comment:

I am subscribing to this idea as I've just fall into such use case where I need it. I would like to submit a patch, but I still have difficulties to understand argparse code not much spare time to spent on this.

----------
nosy: +manveru

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11588>
_______________________________________

From report at bugs.python.org  Wed Apr 27 15:07:02 2011
From: report at bugs.python.org (sorin)
Date: Wed, 27 Apr 2011 13:07:02 +0000
Subject: [issue11936] plistlib.writePlistToBytes does not exist on 2.6 (osx)
	and documentation does not include information about version
In-Reply-To: <1303909622.91.0.842334291068.issue11936@psf.upfronthosting.co.za>
Message-ID: <1303909622.91.0.842334291068.issue11936@psf.upfronthosting.co.za>


New submission from sorin <sorin.sbarnea at gmail.com>:

On OS X (10.6) with Python 2.6 

import plistlib
plistlib.writePlistToBytes(dict())
AttributeError: 'module' object has no attribute 'writePlistToBytes'

Python documentation contains no information regarding when writePlistToBytes was add. http://docs.python.org/dev/library/plistlib.html#plistlib.writePlistToBytes

----------
assignee: ronaldoussoren
components: Library (Lib), Macintosh
messages: 134561
nosy: ronaldoussoren, sorin
priority: normal
severity: normal
status: open
title: plistlib.writePlistToBytes does not exist on 2.6  (osx) and documentation does not include information about version
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11936>
_______________________________________

From report at bugs.python.org  Wed Apr 27 15:36:24 2011
From: report at bugs.python.org (dholth)
Date: Wed, 27 Apr 2011 13:36:24 +0000
Subject: [issue11921] distutils2 should be able to compile an Extension based
	on the Python implementation version
In-Reply-To: <1303750597.71.0.868083563179.issue11921@psf.upfronthosting.co.za>
Message-ID: <1303911384.93.0.484430013536.issue11921@psf.upfronthosting.co.za>


dholth <dholth at fastmail.fm> added the comment:

Yes, putting implementation-specific environment markers in the Extensions section is the idea (instead of the haphazard and occasionally-applied 'Python code in setup.py appends to a list of extensions' method).

An Extension can only be optional when there is equivalent and working Python code. This isn't likely to happen for libraries like PIL where the foreign code provides core functionality instead of a speedup.

The reason I submitted this bug is that as Pypy's C API improves it can successfully compile Extensions to its detriment. Unlike Jython which IIRC has no C API, Pypy cannot patch Extension to always fail, but some of those Extensions are slower than the equivalent Python.

I think there ought to be a declarative way to mark an extension as

a. Required
b. Optional and preferred
c. Optional, not preferred

depending on the Python implementation. For (b) and (c) it would also be quite cool to have a standard flag or runtime mechanism to switch between the C and Python implementation to see which one was really faster (could be done with an import hook?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11921>
_______________________________________

From report at bugs.python.org  Wed Apr 27 15:39:32 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Wed, 27 Apr 2011 13:39:32 +0000
Subject: [issue11927] SMTP_SSL doesn't use port 465 by default
In-Reply-To: <1303836501.95.0.366662026013.issue11927@psf.upfronthosting.co.za>
Message-ID: <1303911572.91.0.894485678114.issue11927@psf.upfronthosting.co.za>


Sijin Joseph <sijinjoseph at gmail.com> added the comment:

Should we add a unit test for this as well?

----------
nosy: +sijinjoseph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11927>
_______________________________________

From report at bugs.python.org  Wed Apr 27 15:43:46 2011
From: report at bugs.python.org (Markus Duft)
Date: Wed, 27 Apr 2011 13:43:46 +0000
Subject: [issue11937] Interix support
In-Reply-To: <1303911825.14.0.5833510557.issue11937@psf.upfronthosting.co.za>
Message-ID: <1303911825.14.0.5833510557.issue11937@psf.upfronthosting.co.za>


New submission from Markus Duft <markus.duft at salomon.at>:

Hey!

For a while now, i'm maintaining python build patches for interix for the gentoo prefix project. I thought maybe i can bring them upstream :) currently i have python 2.7.1 building, and i'll start testing python 3.2 in a while...

may i ask your opinions on my patch, and maybe inclusion in the repository...?

Regards, Markus

----------
components: Build
files: python-2.7.1-interix.patch
keywords: patch
messages: 134564
nosy: mduft
priority: normal
severity: normal
status: open
title: Interix support
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file21796/python-2.7.1-interix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11937>
_______________________________________

From report at bugs.python.org  Wed Apr 27 15:51:24 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Wed, 27 Apr 2011 13:51:24 +0000
Subject: [issue11938] duplicated test name in getattr_static's test case
In-Reply-To: <1303912284.26.0.777560143006.issue11938@psf.upfronthosting.co.za>
Message-ID: <1303912284.26.0.777560143006.issue11938@psf.upfronthosting.co.za>


New submission from Andreas St?hrk <andy-python at hammerhartes.de>:

There are two tests called "test_descriptor" in getattr_static's test case. Attached is a patch that renames one.

----------
components: Tests
files: duplicated_test_descriptor.patch
keywords: patch
messages: 134565
nosy: Trundle, michael.foord
priority: normal
severity: normal
status: open
title: duplicated test name in getattr_static's test case
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21797/duplicated_test_descriptor.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11938>
_______________________________________

From report at bugs.python.org  Wed Apr 27 16:17:07 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 27 Apr 2011 14:17:07 +0000
Subject: [issue11277] Crash with mmap and sparse files on Mac OS X
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <20110427141656.GA3211@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

What do you think - i think this issue can really be closed now.
I'll attach a final 11277.5.diff which has a less irritated and
thus better understandable comment than .4.diff.
I'll also drop .3 and .4.
A lot of noise again 8|

----------
Added file: http://bugs.python.org/file21798/11277.5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________
-------------- next part --------------
diff --git a/Doc/library/mmap.rst b/Doc/library/mmap.rst
--- a/Doc/library/mmap.rst
+++ b/Doc/library/mmap.rst
@@ -86,6 +86,10 @@
    defaults to 0.  *offset* must be a multiple of the PAGESIZE or
    ALLOCATIONGRANULARITY.
 
+   To ensure validity of the created memory mapping the file specified
+   by the descriptor *fileno* is internally automatically synchronized
+   with physical backing store on Mac OS X and OpenVMS.
+
    This example shows a simple way of using :class:`mmap`::
 
       import mmap
diff --git a/Lib/test/test_zlib.py b/Lib/test/test_zlib.py
--- a/Lib/test/test_zlib.py
+++ b/Lib/test/test_zlib.py
@@ -70,7 +70,7 @@
         with open(support.TESTFN, "wb+") as f:
             f.seek(_4G)
             f.write(b"asdf")
-        with open(support.TESTFN, "rb") as f:
+            f.flush()
             self.mapping = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
 
     def tearDown(self):
diff --git a/Modules/mmapmodule.c b/Modules/mmapmodule.c
--- a/Modules/mmapmodule.c
+++ b/Modules/mmapmodule.c
@@ -23,6 +23,9 @@
 
 #ifndef MS_WINDOWS
 #define UNIX
+# ifdef __APPLE__
+#  include <fcntl.h>
+# endif
 #endif
 
 #ifdef MS_WINDOWS
@@ -1122,6 +1125,12 @@
                             "mmap invalid access parameter.");
     }
 
+#ifdef __APPLE__
+    /* Issue 11277: fsync(2) is not enough on OS X - a special, OS X specific
+     * fcntl(2) is necessary to force DISKSYNC and get around mmap(2) bug */
+    if (fd != -1)
+        (void)fcntl(fd, F_FULLFSYNC);
+#endif
 #ifdef HAVE_FSTAT
 #  ifdef __VMS
     /* on OpenVMS we must ensure that all bytes are written to the file */

From report at bugs.python.org  Wed Apr 27 16:17:23 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 27 Apr 2011 14:17:23 +0000
Subject: [issue11277] Crash with mmap and sparse files on Mac OS X
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1303913843.83.0.254249440098.issue11277@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file21715/11277.3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Wed Apr 27 16:17:34 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 27 Apr 2011 14:17:34 +0000
Subject: [issue11277] Crash with mmap and sparse files on Mac OS X
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1303913854.67.0.193158844601.issue11277@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file21717/11277.4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Wed Apr 27 16:18:58 2011
From: report at bugs.python.org (=?utf-8?q?G=C3=B6k=C3=A7en_Eraslan?=)
Date: Wed, 27 Apr 2011 14:18:58 +0000
Subject: [issue8296] multiprocessing.Pool hangs when issuing KeyboardInterrupt
In-Reply-To: <1270265835.83.0.251816264221.issue8296@psf.upfronthosting.co.za>
Message-ID: <1303913938.56.0.1492361068.issue8296@psf.upfronthosting.co.za>


Changes by G?k?en Eraslan <gokcen at pardus.org.tr>:


----------
nosy: +G?k?en.Eraslan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8296>
_______________________________________

From report at bugs.python.org  Wed Apr 27 16:19:25 2011
From: report at bugs.python.org (=?utf-8?q?G=C3=B6k=C3=A7en_Eraslan?=)
Date: Wed, 27 Apr 2011 14:19:25 +0000
Subject: [issue9205] Parent process hanging in multiprocessing if children
	terminate unexpectedly
In-Reply-To: <1278619251.36.0.833806205056.issue9205@psf.upfronthosting.co.za>
Message-ID: <1303913965.57.0.065154683013.issue9205@psf.upfronthosting.co.za>


Changes by G?k?en Eraslan <gokcen at pardus.org.tr>:


----------
nosy: +G?k?en.Eraslan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9205>
_______________________________________

From report at bugs.python.org  Wed Apr 27 16:19:41 2011
From: report at bugs.python.org (=?utf-8?q?G=C3=B6k=C3=A7en_Eraslan?=)
Date: Wed, 27 Apr 2011 14:19:41 +0000
Subject: [issue9207] multiprocessing occasionally spits out exception during
	shutdown (_handle_workers)
In-Reply-To: <1278619533.83.0.0853433126095.issue9207@psf.upfronthosting.co.za>
Message-ID: <1303913981.65.0.186081666869.issue9207@psf.upfronthosting.co.za>


Changes by G?k?en Eraslan <gokcen at pardus.org.tr>:


----------
nosy: +G?k?en.Eraslan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9207>
_______________________________________

From report at bugs.python.org  Wed Apr 27 16:37:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Apr 2011 14:37:36 +0000
Subject: [issue10252] Fix resource warnings in distutils
In-Reply-To: <1288448574.25.0.83148173886.issue10252@psf.upfronthosting.co.za>
Message-ID: <E1QF5ry-0003B1-Q2@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 85fefd41ef5d by ?ric Araujo in branch '3.2':
Fix double use of f.close().
http://hg.python.org/cpython/rev/85fefd41ef5d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10252>
_______________________________________

From report at bugs.python.org  Wed Apr 27 16:37:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Apr 2011 14:37:36 +0000
Subject: [issue11591] "python -S" should be robust against e.g. "from site
	import addsitedir"
In-Reply-To: <1300391220.57.0.0581670249847.issue11591@psf.upfronthosting.co.za>
Message-ID: <E1QF5ry-0003B1-QB@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 9a1ca0062950 by ?ric Araujo in branch 'default':
Add versionchanged for a364719e400a (#11591)
http://hg.python.org/cpython/rev/9a1ca0062950

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11591>
_______________________________________

From report at bugs.python.org  Wed Apr 27 16:37:41 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Apr 2011 14:37:41 +0000
Subject: [issue10998] Remove last traces of -Q / sys.flags.division_warning /
	Py_DivisionWarningFlag
In-Reply-To: <1295897150.32.0.288530737397.issue10998@psf.upfronthosting.co.za>
Message-ID: <E1QF5ry-0003B1-QG@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f9e2b2b17e58 by ?ric Araujo in branch 'default':
Add versionchanged for c19752ea037f (#10998)
http://hg.python.org/cpython/rev/f9e2b2b17e58

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10998>
_______________________________________

From report at bugs.python.org  Wed Apr 27 16:40:53 2011
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 27 Apr 2011 14:40:53 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1303915253.47.0.0442754855539.issue10517@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Antoine, I wonder if we can restore PyThread_set_key_value to behave like a canonical TLS api function (always setting) but fix the cases that want to "set if it has not already been set" like the cases you mention.
It is very unorthodox to have such "only set if it hasn't been set before" built into your only TLS function.  This wart on python's TLS api has bugged me for yearsand it would be cool to fix it.

The init functions (that internally call the python TLS apis) could simply do a TLS get explicitly themselves, to make it explicit and clear that they _want_ to use any pre-existing tls value.

Of course, that won't fix _this_ problem (which is that the main thread's tls value gets inherited on fork).  The right way to do that is to explicitly clearthe main thread's TLS value after fork...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Wed Apr 27 16:48:31 2011
From: report at bugs.python.org (Dev Player)
Date: Wed, 27 Apr 2011 14:48:31 +0000
Subject: [issue10060] python.exe crashes or hangs on help() modules when bad
	modules found
In-Reply-To: <1286676227.2.0.62342583611.issue10060@psf.upfronthosting.co.za>
Message-ID: <1303915711.0.0.856375457857.issue10060@psf.upfronthosting.co.za>


Dev Player <devplayer at gmail.com> added the comment:

mhammond added a recent note at:

python.exe help() modules crashes - ID: 3150027 
https://sourceforge.net/tracker/?func=detail&aid=3150027&group_id=78018&atid=551954

Scroll down below the detail and click the "Comments" link. View the  note from mhammond's on 4/24/2011. 

Although this note will likely solve my particular problem, I suspect it does not directly solve "any corrput package" that would cause "python.exe" "help()" "modules" to crash or "appear to crash" (i.e. the modal popup appearing behind it's parent window).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10060>
_______________________________________

From report at bugs.python.org  Wed Apr 27 16:51:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Apr 2011 14:51:38 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1303915898.07.0.255113546359.issue9264@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Nesting of class/method and class/data directives recommended in 584f9c213a6d.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Wed Apr 27 16:57:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Apr 2011 14:57:56 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1303915253.47.0.0442754855539.issue10517@psf.upfronthosting.co.za>
Message-ID: <1303916246.3591.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine, I wonder if we can restore PyThread_set_key_value to behave
> like a canonical TLS api function (always setting) but fix the cases
> that want to "set if it has not already been set" like the cases you
> mention.
> It is very unorthodox to have such "only set if it hasn't been set
> before" built into your only TLS function.  This wart on python's TLS
> api has bugged me for yearsand it would be cool to fix it.

Well, these functions are supposed to be private so, while I agree their
behaviour is a bit unusual, I'm not sure there's any point to "fix" them
if it shifts the burden of reproducing the old behaviour on another part
of our code.

> The init functions (that internally call the python TLS apis) could
> simply do a TLS get explicitly themselves, to make it explicit and
> clear that they _want_ to use any pre-existing tls value.

Granted.

> Of course, that won't fix _this_ problem (which is that the main
> thread's tls value gets inherited on fork).  The right way to do that
> is to explicitly clearthe main thread's TLS value after fork...

The main thread is fine, actually, it's the other (disappeared) threads
which cause this problem when the same TID is re-used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Wed Apr 27 16:59:21 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 27 Apr 2011 14:59:21 +0000
Subject: [issue9614] _pickle is not entirely 64-bit safe
In-Reply-To: <1303893117.51.0.182512648317.issue9614@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=Sp8NxLcav0Cc7A3p3nqJin8VdFw@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Apr 27, 2011 at 4:31 AM, Amaury Forgeot d'Arc
<report at bugs.python.org> wrote:
>.. 027f81579b4a changed Pdata into a PyVarObject, and the "int length" member
> is now accessed with the Py_SIZE() macro.

ISTM that with this change Pdata struct is now indistinguishable from
a list.  I wonder if the code could be simplified by using a regular
list instead of a custom object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9614>
_______________________________________

From report at bugs.python.org  Wed Apr 27 17:06:24 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 27 Apr 2011 15:06:24 +0000
Subject: [issue11926] help("keywords") returns incomplete list of keywords
In-Reply-To: <1303782960.65.0.80653815306.issue11926@psf.upfronthosting.co.za>
Message-ID: <1303916784.68.0.952590904513.issue11926@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

As part of fixing this we should add a unit test to pydoc that goes something like this:

  assertEqual(sorted(pydoc.Helper.keywords.keys())), sorted(keyword.kwlist))

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11926>
_______________________________________

From report at bugs.python.org  Wed Apr 27 17:09:55 2011
From: report at bugs.python.org (John S. Gruber)
Date: Wed, 27 Apr 2011 15:09:55 +0000
Subject: [issue11933] newer() function in dep_util.py mixes up new vs. old
	files due stat.st_mtime vs stat[ST_MTIME]
In-Reply-To: <1303878590.96.0.749813744893.issue11933@psf.upfronthosting.co.za>
Message-ID: <1303916995.82.0.476368226289.issue11933@psf.upfronthosting.co.za>


John S. Gruber <johnsgruber at gmail.com> added the comment:

Thanks for considering my report so quickly. Attached is a simple test to reproduce the bug, as you suggested. 

Please note that I am not suggesting the code base use stat.st_mtime.

Running the attached with ext4, which keeps sub-second file timestamps:

gruber at gruber-Satellite-L355D:~$ ~/setuptest
running build
running build_py
creating build
creating build/lib.linux-i686-2.7
copying charley.py -> build/lib.linux-i686-2.7
running build
running build_py
copying charley.py -> build/lib.linux-i686-2.7

Under an ext3 filesystem which only accounts to the nearest second:

gruber at gruber-Satellite-L355D:~$ pushd /media/EXT3/
/media/EXT3 ~
gruber at gruber-Satellite-L355D:/media/EXT3$ ~/setuptest
running build
running build_py
copying charley.py -> build/lib.linux-i686-2.7
running build
running build_py

You can see under ext3 the newer() function of dep_util.py works correctly and the redundant copy of charley.py to the build directory, when setup.py is run a second time, is skipped. 

Above, with ext4, the mtime comparison was confused.

As I said in the report, not a big problem--but it obviously isn't what was intended so I hoped a problem report would be worthwhile to the distutils developers.

Thanks.

----------
Added file: http://bugs.python.org/file21799/setuptest

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11933>
_______________________________________

From report at bugs.python.org  Wed Apr 27 17:21:08 2011
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 27 Apr 2011 15:21:08 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1303917668.61.0.60177508438.issue10517@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Ah, using the fallback implementation of tls?  Surely this isn't a problem with the pthreads tls, I'd be surprised if it retains TLS values after fork.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Wed Apr 27 17:21:20 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 27 Apr 2011 15:21:20 +0000
Subject: [issue9614] _pickle is not entirely 64-bit safe
In-Reply-To: <1281895982.89.0.760453311109.issue9614@psf.upfronthosting.co.za>
Message-ID: <1303917680.99.0.484114848382.issue9614@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I believe attached issue9614.diff should fix the warnings, but I don't have a box to test this on.

----------
Added file: http://bugs.python.org/file21800/issue9614.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9614>
_______________________________________

From report at bugs.python.org  Wed Apr 27 17:25:29 2011
From: report at bugs.python.org (John S. Gruber)
Date: Wed, 27 Apr 2011 15:25:29 +0000
Subject: [issue11933] newer() function in dep_util.py mixes up new vs. old
	files due stat.st_mtime vs stat[ST_MTIME]
In-Reply-To: <1303878590.96.0.749813744893.issue11933@psf.upfronthosting.co.za>
Message-ID: <1303917929.36.0.496803519477.issue11933@psf.upfronthosting.co.za>


John S. Gruber <johnsgruber at gmail.com> added the comment:

The original bug report is at: https://bugs.launchpad.net/ubuntu/+source/python-distutils-extra/+bug/770566

As you can see it had to do with a symbolic link created by distutils-extra before distutils was called upon to copy anything. Since this was done behind distutils back, LP: 770566 really was a distutils-extra problem and Martin's fix means this issue no longer arises there.

To recreate the problem in that environment distutils-extra had to be modified to coerce processing to happen in a particular order so setup.py would complete, and then results compared between an ext4 run and the build farm's presumably ext3 run. In the ext4 case the symbolic link was predictably replaced by the file itself. 

The test case I posted above should be easier to follow and doesn't involve any smoke and mirrors being done behind distutils back!

Please let me know if I provide any further information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11933>
_______________________________________

From report at bugs.python.org  Wed Apr 27 17:27:34 2011
From: report at bugs.python.org (Xuanji Li)
Date: Wed, 27 Apr 2011 15:27:34 +0000
Subject: [issue11588] Add "necessarily inclusive" groups to argparse
In-Reply-To: <1300377092.03.0.159307937388.issue11588@psf.upfronthosting.co.za>
Message-ID: <1303918054.24.0.0711811624694.issue11588@psf.upfronthosting.co.za>


Changes by Xuanji Li <xuanji at gmail.com>:


----------
nosy: +xuanji

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11588>
_______________________________________

From report at bugs.python.org  Wed Apr 27 17:28:16 2011
From: report at bugs.python.org (Xuanji Li)
Date: Wed, 27 Apr 2011 15:28:16 +0000
Subject: [issue11874] argparse assertion failure with brackets in metavars
In-Reply-To: <1303201252.58.0.236363581255.issue11874@psf.upfronthosting.co.za>
Message-ID: <1303918096.97.0.770509559477.issue11874@psf.upfronthosting.co.za>


Changes by Xuanji Li <xuanji at gmail.com>:


----------
nosy: +xuanji

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11874>
_______________________________________

From report at bugs.python.org  Wed Apr 27 17:30:17 2011
From: report at bugs.python.org (Xuanji Li)
Date: Wed, 27 Apr 2011 15:30:17 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1303918217.73.0.214470875292.issue9723@psf.upfronthosting.co.za>


Changes by Xuanji Li <xuanji at gmail.com>:


----------
nosy: +xuanji

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Wed Apr 27 17:30:25 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 27 Apr 2011 15:30:25 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1303918225.0.0.374756441876.issue10517@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> Ah, using the fallback implementation of tls?  Surely this isn't a 
> problem with the pthreads tls, I'd be surprised if it retains TLS values 
> after fork.

It surprised me too when I found that out, but it's really with the pthread TLS, on RHEL 4 and 5 (fixed in RHEL6).
See the attached test_specific.c test script.

> You could add a new _PyGILState_ReInit() function and call it from
> PyOS_AfterFork() or PyEval_ReInitThreads().

See attached tls_reinit.diff patch.
But I really find this redundant with PyThread_ReInitTLS, because what we're really doing is reinit the TLS.
Also, this calls this for every thread implementation, while it's only necessary for pthreads (and for other implementation it will redo the work done by PyThread_ReInitTLS).
So I've written another patch which does this in pthread's PyThread_ReInitTLS.

You've got much more experience than me, so it's really your call.
Actually, I kind of feel bad for adding such a hack for a pthread's bug affecting only RHEL 4 and 5, I'm wondering whether it's really worth fixing it.

----------
Added file: http://bugs.python.org/file21801/tls_reinit.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Wed Apr 27 17:30:45 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 27 Apr 2011 15:30:45 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1303918245.7.0.965455662407.issue10517@psf.upfronthosting.co.za>


Changes by Charles-Francois Natali <neologix at free.fr>:


Added file: http://bugs.python.org/file21802/tls_reinit_bis.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Wed Apr 27 17:31:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Apr 2011 15:31:26 +0000
Subject: [issue11933] newer() function in dep_util.py mixes up new vs. old
	files due stat.st_mtime vs stat[ST_MTIME]
In-Reply-To: <1303878590.96.0.749813744893.issue11933@psf.upfronthosting.co.za>
Message-ID: <1303918286.59.0.419664555828.issue11933@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Please note that I am not suggesting the code base use stat.st_mtime.
Yep, I did :)  Do you have another idea for a fix?  We have to walk on eggshells with the distutils codebase: it has often happened that changes made to fix bugs were causing problems in third-party code relying on undocumented behavior (and/or bugs), so we want to fix bugs without causing undesired effects.  (In the next-generation version, distutils2, we can break compatibility for the better.)

I think using only ST_MTIME or only st_mtime could prevent the bug you?re reporting without doing harm otherwise.

> Running the attached with ext4, which keeps sub-second file timestamps:
I think filesystems with this precision are becoming widespread.  Python 3 doesn?t have the bug AFAICT but Python 2.7 will be used for years, so it?s a worthwhile bug to fix.

> You can see under ext3 the newer() function of dep_util.py works
> correctly and the redundant copy of charley.py to the build
> directory, when setup.py is run a second time, is skipped. 
This would be particularly annoying with larger projects involving C extensions.  Would you be willing to turn your test file to a patch, and then fix the code?  We have some basic unit tests in test_dep_util.py and test_build_py.py, you could see how they work and add a test for this bug.  If you?re inclined to do so, please read the developpers guide at http://docs.python.org/devguide .  It not, thanks for what you?ve already done, and I?ll take up from here.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11933>
_______________________________________

From report at bugs.python.org  Wed Apr 27 17:35:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Apr 2011 15:35:09 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1303918225.0.0.374756441876.issue10517@psf.upfronthosting.co.za>
Message-ID: <1303918482.3591.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > You could add a new _PyGILState_ReInit() function and call it from
> > PyOS_AfterFork() or PyEval_ReInitThreads().
> 
> See attached tls_reinit.diff patch.

Thank you. I like this patch, except that _PyGILState_ReInit() should be
declared in the appropriate .h file, not in signalmodule.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Wed Apr 27 17:37:27 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 27 Apr 2011 15:37:27 +0000
Subject: [issue11871] test_default_timeout() of test_threading.BarrierTests
	failure: BrokenBarrierError
In-Reply-To: <1303163944.05.0.666091618845.issue11871@psf.upfronthosting.co.za>
Message-ID: <1303918647.87.0.86586282784.issue11871@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

The most obvious explanation for that failure is that the barrier's timeout is too low.

   def test_default_timeout(self):
       """
       Test the barrier's default timeout
       """
       #create a barrier with a low default timeout
       barrier = self.barriertype(self.N, timeout=0.1)

If the last thread waits on the barrier more than 0.1s after the first thread, then you'll get a BrokenBarrierError.
A 0.1s delay is not that much, 100ms was the default quantum with Linux O(1) scheduler...

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11871>
_______________________________________

From report at bugs.python.org  Wed Apr 27 17:39:58 2011
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 27 Apr 2011 15:39:58 +0000
Subject: [issue8400] zipimporter find_module fullname mis-documented
In-Reply-To: <1271258442.34.0.660774695694.issue8400@psf.upfronthosting.co.za>
Message-ID: <1303918798.01.0.30871761555.issue8400@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

I was bitten now as well...

----------
nosy: +cool-RR

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8400>
_______________________________________

From report at bugs.python.org  Wed Apr 27 17:42:30 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 27 Apr 2011 15:42:30 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1303918950.18.0.0771320633678.issue10517@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> Thank you. I like this patch, except that _PyGILState_ReInit() should be
> declared in the appropriate .h file, not in signalmodule.c.

I asked myself this question when writing the patch: what's the convention  regarding functions ? Should they always be declared in a header with PyAPI_FUNC, or should this be reserved to functions exported through the API?
I've seen a couple external function declarations in several places, so I was wondering (and since this one isn't meant to be exported, I chose the later option).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Wed Apr 27 17:43:35 2011
From: report at bugs.python.org (Ben Okopnik)
Date: Wed, 27 Apr 2011 15:43:35 +0000
Subject: [issue11914] pydoc modules/help('modules') crash in dirs with
	unreadable subdirs
In-Reply-To: <1303616093.87.0.65824226669.issue11914@psf.upfronthosting.co.za>
Message-ID: <1303919015.83.0.0851059566671.issue11914@psf.upfronthosting.co.za>


Ben Okopnik <ben at okopnik.com> added the comment:

Here's a test that should exercise every version of "pydoc" installed on the system:

mkdir -p /tmp/foo/bar; cd /tmp/foo; chmod 0 bar
for n in `whereis -b pydoc`; do echo "**** $n ****"; $n modules; done

Tested under Ubuntu with bash and sh; should work fine with any Bourne-derived shell that supports 'whereis'. Please see attached file.

----------
Added file: http://bugs.python.org/file21803/pydoc_crash_test

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11914>
_______________________________________

From report at bugs.python.org  Wed Apr 27 17:46:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Apr 2011 15:46:37 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1303918950.18.0.0771320633678.issue10517@psf.upfronthosting.co.za>
Message-ID: <1303919170.3591.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > Thank you. I like this patch, except that _PyGILState_ReInit() should be
> > declared in the appropriate .h file, not in signalmodule.c.
> 
> I asked myself this question when writing the patch: what's the
> convention  regarding functions ? Should they always be declared in a
> header with PyAPI_FUNC, or should this be reserved to functions
> exported through the API?

IMO they should always be exposed in header files. It makes them easier
to discover and re-use than with some "extern" decls sprinkled in .c
files. As for PyAPI_FUNC, I think we always use it out of convention,
although it's probably not useful for private API functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Wed Apr 27 17:49:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Apr 2011 15:49:30 +0000
Subject: [issue11914] pydoc modules/help('modules') crash in dirs with
	unreadable subdirs
In-Reply-To: <1303616093.87.0.65824226669.issue11914@psf.upfronthosting.co.za>
Message-ID: <1303919370.71.0.367021797013.issue11914@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The script is bugged, since whereis prefixes its output with its argument (i.e. here ?pydoc: ?).  It?s not a concern anyway: branches open for bugfixes are 2.7, 3.1, 3.2 and 3.3, so when we have a test (preferably as a patch to test_pydoc.py, see http://docs.python.org/devguide for more guidelines on testing and contributing) we check versions and fix where needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11914>
_______________________________________

From report at bugs.python.org  Wed Apr 27 18:03:19 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 27 Apr 2011 16:03:19 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1303920199.07.0.604412803134.issue10517@psf.upfronthosting.co.za>


Changes by Charles-Francois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file21802/tls_reinit_bis.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Wed Apr 27 18:03:22 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 27 Apr 2011 16:03:22 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1303920202.63.0.721963819847.issue10517@psf.upfronthosting.co.za>


Changes by Charles-Francois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file21801/tls_reinit.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Wed Apr 27 18:03:29 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 27 Apr 2011 16:03:29 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1303920209.79.0.729191468688.issue10517@psf.upfronthosting.co.za>


Changes by Charles-Francois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file21678/thread_invalid_key.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Wed Apr 27 18:04:35 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 27 Apr 2011 16:04:35 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1303920275.02.0.389563996048.issue10517@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Here's an updated patch, tested on RHEL4U8.

----------
Added file: http://bugs.python.org/file21804/tls_reinit.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Wed Apr 27 18:07:52 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 27 Apr 2011 16:07:52 +0000
Subject: [issue10632] multiprocessing generates a fatal error
In-Reply-To: <1291575231.48.0.0739915325097.issue10632@psf.upfronthosting.co.za>
Message-ID: <1303920472.29.0.377665177884.issue10632@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

It's a duplicate of http://bugs.python.org/issue10517

----------
nosy: +neologix, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10632>
_______________________________________

From report at bugs.python.org  Wed Apr 27 18:10:10 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 27 Apr 2011 16:10:10 +0000
Subject: [issue11247] Error sending packets to multicast IPV4 address
In-Reply-To: <1298087823.89.0.505533825955.issue11247@psf.upfronthosting.co.za>
Message-ID: <1303920610.74.0.374422007833.issue11247@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Suggesting to close.

----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11247>
_______________________________________

From report at bugs.python.org  Wed Apr 27 18:14:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Apr 2011 16:14:36 +0000
Subject: [issue11670] configparser read_file now iterates over f,
	docs still say it calls readline
In-Reply-To: <1301047699.5.0.476245530251.issue11670@psf.upfronthosting.co.za>
Message-ID: <E1QF7Nq-0003dl-SJ@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6f937d6369b6 by ?ukasz Langa in branch '3.2':
Closes #11670: configparser read_file now iterates over f.
http://hg.python.org/cpython/rev/6f937d6369b6

New changeset 9da06f771a57 by ?ukasz Langa in branch 'default':
Merged #11670 from 3.2
http://hg.python.org/cpython/rev/9da06f771a57

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11670>
_______________________________________

From report at bugs.python.org  Wed Apr 27 18:17:33 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 27 Apr 2011 16:17:33 +0000
Subject: [issue11670] configparser read_file now iterates over f,
	docs still say it calls readline
In-Reply-To: <1301047699.5.0.476245530251.issue11670@psf.upfronthosting.co.za>
Message-ID: <1303921053.73.0.692162689883.issue11670@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Closed in http://hg.python.org/cpython/rev/6f937d6369b6.

----------
resolution: fixed -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11670>
_______________________________________

From report at bugs.python.org  Wed Apr 27 18:31:06 2011
From: report at bugs.python.org (Dev Player)
Date: Wed, 27 Apr 2011 16:31:06 +0000
Subject: [issue10060] python.exe crashes or hangs on help() modules when bad
	modules found
In-Reply-To: <1286676227.2.0.62342583611.issue10060@psf.upfronthosting.co.za>
Message-ID: <1303921866.44.0.491601399316.issue10060@psf.upfronthosting.co.za>


Dev Player <devplayer at gmail.com> added the comment:

What about this application modal popup window appearing behind the DOS window? (See attached) That popup window may only need to have a system style flag to push it to the top of the window z-order stack.

What causes that popup to appear? Is it Python source code or compiled C code built into python.exe?

There is a MS-Windows win32 function called SetForegroundWindow() that may be the issue if it's not Python source code.
Maybe this URL might shed some light on the popup issue?

http://stackoverflow.com/questions/3772233/win32-setforegroundwindow-unreliable

I am grasping for straws here.

Perhaps the python.exe app crashes in the cmd.exe window because of attempts to do something with the cmd.exe window while the app modal popup windows is behind it? 

As per my previous post is seems mhammond has a solution for his pythonwin package causing python.exe-help()-modules to crash. (If that's the case) it still doesn't address "other" packages having the same ability to crash python.exe, IDLE and other interactive interpreters thru help()-modules.

----------
Added file: http://bugs.python.org/file21805/python_exe_help()_modules_app_modal_popup_window_behind_main_window_a.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10060>
_______________________________________

From report at bugs.python.org  Wed Apr 27 18:59:43 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Apr 2011 16:59:43 +0000
Subject: [issue11939] Implement stat.st_dev and os.path.samefile on windows
In-Reply-To: <1303923583.07.0.177662562381.issue11939@psf.upfronthosting.co.za>
Message-ID: <1303923583.07.0.177662562381.issue11939@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

Since 9cd1036455e7, os.stat() on Windows fills the st_ino member;
it could fill st_dev just as easily;
then os.path.samefile() could be shared with the posix implementation.

----------
components: Windows
messages: 134595
nosy: amaury.forgeotdarc
priority: normal
severity: normal
status: open
title: Implement stat.st_dev and os.path.samefile on windows
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11939>
_______________________________________

From report at bugs.python.org  Wed Apr 27 19:08:01 2011
From: report at bugs.python.org (Bryce Verdier)
Date: Wed, 27 Apr 2011 17:08:01 +0000
Subject: [issue11834] wrong module installation dir on Windows
In-Reply-To: <1302605256.31.0.234550103785.issue11834@psf.upfronthosting.co.za>
Message-ID: <1303924081.22.0.301158598886.issue11834@psf.upfronthosting.co.za>


Bryce Verdier <bryceverdier at gmail.com> added the comment:

Ok, so after getting some off list help, I changed the defaults to what they should be. Also, Mark was right, "--install-scripts" generally puts things in pythondir\Scripts... as tested with pylint, mako, and some others.

I changed data back to Data... though I could no verify it. Even with --install-data, I couldn't seem to find a new Data directory. Maybe I was doing something wrong.

Anyway, here is the new patch.

----------
nosy:  -brian.curtin, markm
Added file: http://bugs.python.org/file21806/issue133572.py33.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11834>
_______________________________________

From report at bugs.python.org  Wed Apr 27 19:11:19 2011
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 27 Apr 2011 17:11:19 +0000
Subject: [issue10632] multiprocessing generates a fatal error
In-Reply-To: <1291575231.48.0.0739915325097.issue10632@psf.upfronthosting.co.za>
Message-ID: <1303924279.39.0.0825470402569.issue10632@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Dupe of issue10517

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10632>
_______________________________________

From report at bugs.python.org  Wed Apr 27 19:12:05 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 27 Apr 2011 17:12:05 +0000
Subject: [issue11937] Interix support
In-Reply-To: <1303911825.14.0.5833510557.issue11937@psf.upfronthosting.co.za>
Message-ID: <1303924325.65.0.829249589742.issue11937@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I don't agree with some details of the patch (I would move the log-like calculation to a inline function, and document WHY it is needed at all, for instance), but supporting a new platform is good, moreover when the patch is so small.

I would ask for a seasoned Python-developer to decide the target for this. Personally I would be OK to target 2.7.2, 3.2.1 and 3.3. But since this would be considered a new feature the target would be 3.3. Given the special status of 2.7 (to be maintained for a long time), I would target it too. In any case, this is something that the release managers of each version should consider.

I am "nosy-ing" Benjamin Peterson (2.7) and Georg Brandl (3.2) as release managers. I am interested in their opinion. I don't think we should involucrate 3.1 with this, with 3.2 already published.

After that, we can discuss the patch details.

PS: Markus, could you possibly summarize intierix?. We would need a patch for 3.3 too. Maybe too for 3.2, if Georg opinion is favourable.

----------
nosy: +benjamin.peterson, georg.brandl, jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11937>
_______________________________________

From report at bugs.python.org  Wed Apr 27 19:16:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Apr 2011 17:16:19 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1303924579.47.0.952739894559.issue10517@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
dependencies:  -multiprocessing generates a fatal error
stage:  -> commit review
superseder:  -> multiprocessing generates a fatal error
versions: +Python 2.7, Python 3.1, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Wed Apr 27 19:16:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Apr 2011 17:16:34 +0000
Subject: [issue10632] multiprocessing generates a fatal error
In-Reply-To: <1291575231.48.0.0739915325097.issue10632@psf.upfronthosting.co.za>
Message-ID: <1303924594.28.0.690106351853.issue10632@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
superseder:  -> multiprocessing generates a fatal error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10632>
_______________________________________

From report at bugs.python.org  Wed Apr 27 19:16:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Apr 2011 17:16:36 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1303924596.68.0.186095670733.issue10517@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
superseder: multiprocessing generates a fatal error -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Wed Apr 27 19:16:50 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 27 Apr 2011 17:16:50 +0000
Subject: [issue10419] distutils command build_scripts fails with
	UnicodeDecodeError
In-Reply-To: <1289766753.91.0.865805184241.issue10419@psf.upfronthosting.co.za>
Message-ID: <1303924610.56.0.0911396994424.issue10419@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever, haypo
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10419>
_______________________________________

From report at bugs.python.org  Wed Apr 27 19:21:40 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Wed, 27 Apr 2011 17:21:40 +0000
Subject: [issue11921] distutils2 should be able to compile an Extension based
	on the Python implementation version
In-Reply-To: <1303750597.71.0.868083563179.issue11921@psf.upfronthosting.co.za>
Message-ID: <1303924900.84.0.36048815222.issue11921@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11921>
_______________________________________

From report at bugs.python.org  Wed Apr 27 19:22:18 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Apr 2011 17:22:18 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <E1QF8RL-00016J-Ls@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f6feed6ec3f9 by Antoine Pitrou in branch '2.7':
Issue #10517: After fork(), reinitialize the TLS used by the PyGILState_*
http://hg.python.org/cpython/rev/f6feed6ec3f9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Wed Apr 27 19:27:45 2011
From: report at bugs.python.org (Ben Okopnik)
Date: Wed, 27 Apr 2011 17:27:45 +0000
Subject: [issue11914] pydoc modules/help('modules') crash in dirs with
	unreadable subdirs
In-Reply-To: <1303616093.87.0.65824226669.issue11914@psf.upfronthosting.co.za>
Message-ID: <1303925265.82.0.276365644012.issue11914@psf.upfronthosting.co.za>


Ben Okopnik <ben at okopnik.com> added the comment:

Trivial fix: please see attached. As to test_pydoc.py, I don't know the system well enough to fiddle with it, but something like this should work (untested):

    def test_unreadable_dir(self):
        ''' pydoc should handle unreadable subdirs gracefully '''

    @contextmanager
    def mk_unreadable_dir():
        top_level_dir = tempfile.mkdtemp()
        bad_dir = tempfile.mkdtemp(dir=top_level_dir)
        os.chmod(bad_dir, 0)
        os.chdir(top_level_dir)
        yield
        os.removedirs(top_level_dir)

    with mk_unreadable_dir():
        doc = pydoc.render_doc('modules')
        self.assertTrue("modules" in doc)

----------
Added file: http://bugs.python.org/file21807/pydoc_crash_test

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11914>
_______________________________________

From report at bugs.python.org  Wed Apr 27 19:30:16 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 27 Apr 2011 17:30:16 +0000
Subject: [issue11937] Interix support
In-Reply-To: <1303911825.14.0.5833510557.issue11937@psf.upfronthosting.co.za>
Message-ID: <1303925416.75.0.287459823233.issue11937@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Markus, could you possibly provide a buildbot running under Interix?. A virtual machine could be OK, if available 24x7, with reasonable resources (CPU, memory).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11937>
_______________________________________

From report at bugs.python.org  Wed Apr 27 19:32:14 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 27 Apr 2011 17:32:14 +0000
Subject: [issue11939] Implement stat.st_dev and os.path.samefile on windows
In-Reply-To: <1303923583.07.0.177662562381.issue11939@psf.upfronthosting.co.za>
Message-ID: <1303925534.65.0.00893315399353.issue11939@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

I created/assigned #10646 to myself for other samefile issues - I can cover this as well unless someone beats me to it.

----------
assignee:  -> brian.curtin
nosy: +brian.curtin
stage:  -> needs patch
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11939>
_______________________________________

From report at bugs.python.org  Wed Apr 27 19:34:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Apr 2011 17:34:17 +0000
Subject: [issue11937] Interix support
In-Reply-To: <1303911825.14.0.5833510557.issue11937@psf.upfronthosting.co.za>
Message-ID: <1303925657.37.0.288916609283.issue11937@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11937>
_______________________________________

From report at bugs.python.org  Wed Apr 27 19:36:10 2011
From: report at bugs.python.org (John S. Gruber)
Date: Wed, 27 Apr 2011 17:36:10 +0000
Subject: [issue11933] newer() function in dep_util.py mixes up new vs. old
	files due stat.st_mtime vs stat[ST_MTIME]
In-Reply-To: <1303878590.96.0.749813744893.issue11933@psf.upfronthosting.co.za>
Message-ID: <1303925770.06.0.8293729599.issue11933@psf.upfronthosting.co.za>


John S. Gruber <johnsgruber at gmail.com> added the comment:

I can understand what you are saying about side effects.

I was trying to suggest that the move to stat.st_mtime in dep_util.py in the hg commit I mentioned be reverted back to use stat[ST_MTIME], thereby matching the other python releases and the old behavior (and matching file_util.py). It seems to me that would be the safest course when it comes to side-effects.

If it were desired to determine which file was newer using sub-second values, perhaps that would make a reasonable change in distutils2, but files created with a few microseconds would have to be considered equivalent due to the reduced precision available in python floats (53 bits on my platform, if I understand correctly) as compared to the 64 bit precision used by some operating systems and file systems.

However, I think I'd prefer to turn the decision and further process over to you, if you don't mind. I thank you and your colleagues for your excellent work with python, and with making it platform independent--a very difficult part of the work indeed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11933>
_______________________________________

From report at bugs.python.org  Wed Apr 27 19:38:19 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Apr 2011 17:38:19 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <E1QF8gs-0002Si-Bd@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7b7ad9a88451 by Antoine Pitrou in branch '3.2':
Issue #10517: After fork(), reinitialize the TLS used by the PyGILState_*
http://hg.python.org/cpython/rev/7b7ad9a88451

New changeset c8f283cd3e6e by Antoine Pitrou in branch 'default':
Issue #10517: After fork(), reinitialize the TLS used by the PyGILState_*
http://hg.python.org/cpython/rev/c8f283cd3e6e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Wed Apr 27 19:39:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Apr 2011 17:39:10 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1303925950.05.0.287646607964.issue10517@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It should be fixed now! Thank you.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Wed Apr 27 19:48:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Apr 2011 17:48:11 +0000
Subject: [issue10914] Python sub-interpreter test
In-Reply-To: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za>
Message-ID: <1303926491.86.0.328733887933.issue10914@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Victor, the fix needs to go into 3.2 as well.

----------
assignee:  -> haypo
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10914>
_______________________________________

From report at bugs.python.org  Wed Apr 27 20:02:56 2011
From: report at bugs.python.org (Dev Player)
Date: Wed, 27 Apr 2011 18:02:56 +0000
Subject: [issue10060] python.exe crashes or hangs on help() modules when bad
	modules found
In-Reply-To: <1286676227.2.0.62342583611.issue10060@psf.upfronthosting.co.za>
Message-ID: <1303927376.67.0.253863869248.issue10060@psf.upfronthosting.co.za>


Dev Player <devplayer at gmail.com> added the comment:

This is an acedmic note. This is not really the place and perhaps better moved to a PEP or a forum. 

In my search to discover more about Python ( and its interactive interpreter and its help() function? statement? on my own) I noticed it was kind of a wart in Python world. It seems like the print statement or the exit() interactive interpreter command in someways.

I was not able to pass in any arguments into "help()" or pipe in "modules" into it from the DOS command line.

For example while you are in the Python interactive command interpreter; you can not call "help()" like a function; such as:
 "help(modules)" 

Nor will this work: ">>>help();modules" in the interactive interpreter  as "modules" is considered a seperate attempted statement (which raises and exception because "modules" is not a valid __builtin__ object.

It seemed like Python's help() command is its own little interactive interpreter. Like it's own seperate subprocess. Is it? I don't know, not likely. But that's how it behaves to me. Which lead me thinking in another direction. 

So I tried these commands knowing they wouldn't work but leads to an idea:

c:\python.exe -c help(modules)   # help() is not a classic function it seems; perhaps it should be
c:\python.exe -c help();modules  # definitly wrong
c:\python.exe -h modules         # looks like a viable idea; perhaps a nice PEP?

Which led me to try to find a way to run the help() command in it's own seperate process or subprocess. So if it failed it wouldn't effect python.exe. Well the help() command appears to be baked right into the python.exe program. So perahps a seperate second python.exe subprocess to test the idea that help() should eventaully be an actual subprocess with the ability to check on failure of "help()"-"modules"; or anything like it; a design change of python.exe

I started with:
c:\python.exe -c "import os; os.system('python.exe -c help()')"

Some problems with this attempt is: 1. os.system() is being obseleted for the subprocess.Popen() module. 2. There are MS-DOS command prompt quotation issues with trying to get "modules" piped into the new process somewhere at the end of that. 3. Lots of other stuff.

Anyway I moved forward with the idea to test this code within the python.exe interactive interpreter to test:

# code
from subprocess import Popen, PIPE
cmds = ['python.exe', '-c', 'help()']
p1 = Popen(cmds, stdout=PIPE, stdin=PIPE)
print p1.communicate("modules")[0]
# end code

On my system the app model popup still pop's up behind the ORIGINAL cmd.exe window. Therefore still the same problem and potential of crashing. 

So digging further I came to 
http://docs.python.org/library/subprocess.html

Quoted from website "The startupinfo and creationflags, if given, will be passed to the underlying CreateProcess() function. They can specify things such as appearance of the main window and priority for the new process. (Windows only)" and then changing the code to:

# code
from subprocess import Popen, PIPE, CREATE_NEW_CONSOLE
cmds = ['python.exe', '-c', 'help()']
p1 = Popen(cmds, stdout=PIPE, stdin=PIPE, creationflags=CREATE_NEW_CONSOLE)
print p1.communicate("modules")[0]
# end code

which does seem to force the modal popup to the top of the DOS command window. See URL: 
http://msdn.microsoft.com/en-us/library/ms684863(v=VS.85).aspx


Why this tangent on a basically esoteric issue? 
One reason is security. I see this as a way a hacker can crash Python apps easily. A horrible thing on a webserver with Python served webpages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10060>
_______________________________________

From report at bugs.python.org  Wed Apr 27 20:30:15 2011
From: report at bugs.python.org (Dev Player)
Date: Wed, 27 Apr 2011 18:30:15 +0000
Subject: [issue10060] python.exe crashes or hangs on help() modules when bad
	modules found
In-Reply-To: <1286676227.2.0.62342583611.issue10060@psf.upfronthosting.co.za>
Message-ID: <1303929015.76.0.807964202374.issue10060@psf.upfronthosting.co.za>


Dev Player <devplayer at gmail.com> added the comment:

Just delete the previous message... please.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10060>
_______________________________________

From report at bugs.python.org  Wed Apr 27 21:29:19 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 27 Apr 2011 19:29:19 +0000
Subject: [issue10060] python.exe crashes or hangs on help() modules when bad
	modules found
In-Reply-To: <1286676227.2.0.62342583611.issue10060@psf.upfronthosting.co.za>
Message-ID: <1303932559.53.0.316701674026.issue10060@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
Removed message: http://bugs.python.org/msg134607

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10060>
_______________________________________

From report at bugs.python.org  Wed Apr 27 21:29:54 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 27 Apr 2011 19:29:54 +0000
Subject: [issue10060] python.exe crashes or hangs on help() modules when bad
	modules found
In-Reply-To: <1286676227.2.0.62342583611.issue10060@psf.upfronthosting.co.za>
Message-ID: <1303932594.36.0.685256035035.issue10060@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

(Note: the word is 'separate', 2 e's and 2 a's, not 'seperate')
(Note: We already know that using unbound unquoted names does not work. Please do not waste our time telling us the obvious.)
(Note: I am removing IDLE because this does not seem to be an IDLE issue but a help() issue. I marked 'Library' because 'help' is installed by the site module.)

Help is not built in to python.exe. It is added to builtins when the site module is imported. That import can be suppressed with the '-S' startup option. It is strictly intended for interactive use.

I do not see this as much of a security issue. Crashing apps and especially servers should not be an issue because neither should be using help. Anyway, I should think that a hacker that can install a broken C extension could do much worse things.

Help has three modes.
1) the direct response mode of help(ob)
2) the direct response mode of help(somestring), where help looks to see if it recognizes somestring before returning help for str.
help('modules') works fine.
3) the mini-interpreter mode of help(). People can run the mini-interpreter in a separate interactive instance of the interpreter if they wish. I do not think this needs to be done automatically.

I am inclined to close this issue as I do not see any action needed by Cpython developers. Contrary to your assertion, running corrupt C-coded extensions *does* crash the process, and I do not think there is much we can do about it, as C lacks try:...except:. Certainly, there is no promise to guard against such. In my view, removing a corrupt package is an answer, not a workaround!

----------
components: +Library (Lib) -IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10060>
_______________________________________

From report at bugs.python.org  Wed Apr 27 21:47:47 2011
From: report at bugs.python.org (John S. Gruber)
Date: Wed, 27 Apr 2011 19:47:47 +0000
Subject: [issue11933] newer() function in dep_util.py mixes up new vs. old
	files due stat.st_mtime vs stat[ST_MTIME]
In-Reply-To: <1303878590.96.0.749813744893.issue11933@psf.upfronthosting.co.za>
Message-ID: <1303933667.85.0.91304691178.issue11933@psf.upfronthosting.co.za>


John S. Gruber <johnsgruber at gmail.com> added the comment:

As I thought about it, I suppose I should demonstrate the problem with stat.st_mtime. Here's an example and its output on an ext4 file system:

gruber at gruber-Satellite-L355D:~$ ./mtime.py
(1303933305.5525582, 1303933305.5525582) (1303933305.552558, 1303933305.552558) (1303933305.552557, 1303933305.552557) (1303933305.552556, 1303933305.552556)
(1303933305.5525581837 1303933305.5525581837) (1303933305.5525579453 1303933305.5525579453) (1303933305.5525569916 1303933305.5525569916) (1303933305.5525560379 1303933305.5525560379)
total 0
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:45.552558258 -0400 one
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:45.552558000 -0400 target1
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:45.552557000 -0400 target2
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:45.552556000 -0400 target3

Traceback (most recent call last):
  File "./mtime.py", line 28, in <module>
    assert timetargetthree == timetargettwo
AssertionError
gruber at gruber-Satellite-L355D:~$ ./mtime.py
(1303933306.3885624, 1303933306.3885624) (1303933306.388562, 1303933306.388562) (1303933306.388561, 1303933306.388561) (1303933306.388561, 1303933306.388561)
(1303933306.3885624409 1303933306.3885624409) (1303933306.3885619640 1303933306.3885619640) (1303933306.3885610104 1303933306.3885610104) (1303933306.3885610104 1303933306.3885610104)
total 0
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:46.388562342 -0400 one
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:46.388562000 -0400 target1
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:46.388561000 -0400 target2
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:46.388561000 -0400 target3

Traceback (most recent call last):
  File "./mtime.py", line 29, in <module>
    assert timetargettwo == timetargetone
AssertionError
gruber at gruber-Satellite-L355D:~$ ./mtime.py
(1303933307.0525656, 1303933307.0525656) (1303933307.052565, 1303933307.052565) (1303933307.052565, 1303933307.052565) (1303933307.052565, 1303933307.052565)
(1303933307.0525655746 1303933307.0525655746) (1303933307.0525650978 1303933307.0525650978) (1303933307.0525650978 1303933307.0525650978) (1303933307.0525650978 1303933307.0525650978)
total 0
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:47.052565592 -0400 one
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:47.052565000 -0400 target1
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:47.052565000 -0400 target2
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:47.052565000 -0400 target3

Traceback (most recent call last):
  File "./mtime.py", line 30, in <module>
    assert timetargetone == timeone
AssertionError
gruber at gruber-Satellite-L355D:~$ ./mtime.py
(1303933308.2285714, 1303933308.2285714) (1303933308.228571, 1303933308.228571) (1303933308.22857, 1303933308.22857) (1303933308.228569, 1303933308.228569)
(1303933308.2285714149 1303933308.2285714149) (1303933308.2285709381 1303933308.2285709381) (1303933308.2285699844 1303933308.2285699844) (1303933308.2285690308 1303933308.2285690308)
total 0
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:48.228571344 -0400 one
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:48.228571000 -0400 target1
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:48.228570000 -0400 target2
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:48.228569000 -0400 target3

Traceback (most recent call last):
  File "./mtime.py", line 28, in <module>
    assert timetargetthree == timetargettwo
AssertionError
gruber at gruber-Satellite-L355D:~$ ./mtime.py
(1303933309.0685754, 1303933309.0685754) (1303933309.068575, 1303933309.068575) (1303933309.068574, 1303933309.068574) (1303933309.068573, 1303933309.068573)
(1303933309.0685753822 1303933309.0685753822) (1303933309.0685749054 1303933309.0685749054) (1303933309.0685739517 1303933309.0685739517) (1303933309.0685729980 1303933309.0685729980)
total 0
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:49.068575446 -0400 one
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:49.068575000 -0400 target1
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:49.068574000 -0400 target2
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:49.068573000 -0400 target3

Traceback (most recent call last):
  File "./mtime.py", line 28, in <module>
    assert timetargetthree == timetargettwo
AssertionError
gruber at gruber-Satellite-L355D:~$ ./mtime.py
(1303933309.6765785, 1303933309.6765785) (1303933309.676578, 1303933309.676578) (1303933309.676578, 1303933309.676578) (1303933309.676578, 1303933309.676578)
(1303933309.6765785217 1303933309.6765785217) (1303933309.6765780449 1303933309.6765780449) (1303933309.6765780449 1303933309.6765780449) (1303933309.6765780449 1303933309.6765780449)
total 0
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:49.676578416 -0400 one
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:49.676578000 -0400 target1
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:49.676578000 -0400 target2
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:49.676578000 -0400 target3

Traceback (most recent call last):
  File "./mtime.py", line 30, in <module>
    assert timetargetone == timeone
AssertionError
gruber at gruber-Satellite-L355D:~$ ./mtime.py
(1303933310.396582, 1303933310.396582) (1303933310.396581, 1303933310.396581) (1303933310.39658, 1303933310.39658) (1303933310.396579, 1303933310.396579)
(1303933310.3965818882 1303933310.3965818882) (1303933310.3965809345 1303933310.3965809345) (1303933310.3965799809 1303933310.3965799809) (1303933310.3965790272 1303933310.3965790272)
total 0
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:50.396581938 -0400 one
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:50.396581000 -0400 target1
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:50.396580000 -0400 target2
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:50.396579000 -0400 target3

Traceback (most recent call last):
  File "./mtime.py", line 28, in <module>
    assert timetargetthree == timetargettwo
AssertionError
gruber at gruber-Satellite-L355D:~$ ./mtime.py
(1303933311.056585, 1303933311.056585) (1303933311.056585, 1303933311.056585) (1303933311.056585, 1303933311.056585) (1303933311.056585, 1303933311.056585)
(1303933311.0565850735 1303933311.0565850735) (1303933311.0565850735 1303933311.0565850735) (1303933311.0565850735 1303933311.0565850735) (1303933311.0565850735 1303933311.0565850735)
total 0
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:51.056585165 -0400 one
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:51.056585000 -0400 target1
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:51.056585000 -0400 target2
-rw-r--r-- 1 gruber gruber 0 2011-04-27 15:41:51.056585000 -0400 target3

gruber at gruber-Satellite-L355D:~$

Please excuse my total lack of Python style.

----------
Added file: http://bugs.python.org/file21808/mtime.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11933>
_______________________________________

From report at bugs.python.org  Wed Apr 27 21:50:39 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 27 Apr 2011 19:50:39 +0000
Subject: [issue11936] plistlib.writePlistToBytes does not exist on 2.6 (osx)
	and documentation does not include information about version
In-Reply-To: <1303909622.91.0.842334291068.issue11936@psf.upfronthosting.co.za>
Message-ID: <1303933839.73.0.196319388735.issue11936@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

You are looking at the documentation for Python 3, not Python 2.  For Python 2.6, you should refer to its documentation: http://docs.python.org/release/2.6.6/library/plistlib.html

For Python 3, many references to strings were changed to bytes as part of the changing of Unicode strings and 8-bit strings in Python 2 to strings and bytes in Python 3.  This was one of them.

----------
assignee: ronaldoussoren -> ned.deily
nosy: +ned.deily
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: behavior -> 
versions:  -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11936>
_______________________________________

From report at bugs.python.org  Wed Apr 27 22:04:31 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 27 Apr 2011 20:04:31 +0000
Subject: [issue11940] Howto/Advocacy - update the link to John Ousterhout paper
In-Reply-To: <1303934671.48.0.846798146708.issue11940@psf.upfronthosting.co.za>
Message-ID: <1303934671.48.0.846798146708.issue11940@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Following up http://mail.python.org/pipermail/docs/2011-April/004031.html here's a patch to update the link to John Ousterhout paper. It can be applied on all active branches.

----------
assignee: docs at python
components: Documentation
files: howto_advocacy_ousterhout_link.patch
keywords: patch
messages: 134612
nosy: docs at python, sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: Howto/Advocacy - update the link to John Ousterhout paper
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21809/howto_advocacy_ousterhout_link.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11940>
_______________________________________

From report at bugs.python.org  Wed Apr 27 22:21:16 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 27 Apr 2011 20:21:16 +0000
Subject: [issue11922] Add General Index to Windows .chm help file Contents
In-Reply-To: <1303752107.55.0.594682028964.issue11922@psf.upfronthosting.co.za>
Message-ID: <1303935676.99.0.386048159756.issue11922@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I had not really noticed that the Index *was* the General Index. In trying it out, I discovered that double-clicking on entries with multiple links in the General Index, such as 'name,binding' with 7 links, brings up a sub-box with all seven.

So I will close this at least until I decide that I would really want the addition enough to help make the change.

----------
resolution:  -> later
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11922>
_______________________________________

From report at bugs.python.org  Wed Apr 27 22:47:49 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Wed, 27 Apr 2011 20:47:49 +0000
Subject: [issue8808] imaplib should support SSL contexts
In-Reply-To: <1274717637.39.0.0073929793702.issue8808@psf.upfronthosting.co.za>
Message-ID: <1303937269.56.0.923533246133.issue8808@psf.upfronthosting.co.za>


Sijin Joseph <sijinjoseph at gmail.com> added the comment:

I am attaching a patch for the default branch that adds a ssl_context parameter to IMAP4_SSL. Also added a couple of tests to test_imaplib to test the existing ctor with certfile and file and also the new one that accepts an SSLContext.

Currently if the ssl_context param is provided then the keyfile and certfile are ignored, I wasn't sure if the ssl_context should be loaded with the certfile if that is provided along with the ssl_context.

If this looks ok, I can add something similar for smtplib as well.

----------
keywords: +patch
Added file: http://bugs.python.org/file21810/8808.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8808>
_______________________________________

From report at bugs.python.org  Wed Apr 27 22:55:00 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 27 Apr 2011 20:55:00 +0000
Subject: [issue11940] Howto/Advocacy - update the link to John Ousterhout paper
In-Reply-To: <1303934671.48.0.846798146708.issue11940@psf.upfronthosting.co.za>
Message-ID: <1303937700.45.0.792169837817.issue11940@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This looks good.  Thanks for the patch.

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11940>
_______________________________________

From report at bugs.python.org  Wed Apr 27 23:00:22 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 27 Apr 2011 21:00:22 +0000
Subject: [issue11941] Support st_atim,
	st_mtim and st_ctim attributes in os.stat_result
In-Reply-To: <1303938022.85.0.623572797729.issue11941@psf.upfronthosting.co.za>
Message-ID: <1303938022.85.0.623572797729.issue11941@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

I would like to suggest to add st_atim, st_mtim and st_ctim attributes in os.stat_result objects returned by os.stat(). These attributes would be 2-tuples containing number of seconds and number of nanoseconds. They would expose relevant functionality from libc's stat() and provide better precision than floating-point-based st_atime, st_mtime and st_ctime attributes.

st_atim, st_mtim and st_ctim attributes would be available only if Python has been built on system with libc supporting st_atim, st_mtim and st_ctim in stat structure.

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html

----------
messages: 134616
nosy: Arfrever
priority: normal
severity: normal
status: open
title: Support st_atim, st_mtim and st_ctim attributes in os.stat_result
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11941>
_______________________________________

From report at bugs.python.org  Wed Apr 27 23:01:40 2011
From: report at bugs.python.org (Ben Okopnik)
Date: Wed, 27 Apr 2011 21:01:40 +0000
Subject: [issue11914] pydoc modules/help('modules') crash in dirs with
	unreadable subdirs
In-Reply-To: <1303616093.87.0.65824226669.issue11914@psf.upfronthosting.co.za>
Message-ID: <1303938100.13.0.0426257671672.issue11914@psf.upfronthosting.co.za>


Ben Okopnik <ben at okopnik.com> added the comment:

Whoops... with all of that, I just realized that this bug should be filed against pkgutil, not pydoc (pydoc, of course, calls pkgutil to do the path resolution, which is where this crash occurs.) My bad.

>>> import pkgutil
>>> inst = pkgutil.ImpImporter(path='/tmp')
>>> list(inst.iter_modules())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.1/pkgutil.py", line 209, in iter_modules
    for fn in os.listdir(path):
OSError: [Errno 13] Permission denied: '/tmp/orbit-gdm'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11914>
_______________________________________

From report at bugs.python.org  Wed Apr 27 23:02:30 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 27 Apr 2011 21:02:30 +0000
Subject: [issue11811] ssl.get_server_certificate() does not work for IPv6
	addresses
In-Reply-To: <1302383900.51.0.808943452569.issue11811@psf.upfronthosting.co.za>
Message-ID: <1303938150.16.0.872505393751.issue11811@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

A patch is attached, along with corresponding test.
Notes:
- since I don't have an IPv6 internet connectivity, I could only test it locally
- I chose 'ipv6.google.com' as SSL server for the test. If it's a problem, I can change it for svn.python.org (it'll just take a couple more lines to make sure that we're using IPv6 and not IPv4)
- while writting the test, I needed a way to find whether IPv6 is supported on the current host (socket.has_ipv6 only tells you that the interpreter has been built with IPv6 support, not that the OS has an IPv6 stack enabled). So instead of rewritting what's already done in test_socket, I added a new is_ipv6_enabled function in Lib/test/support.py, and modified test_socket, test_ftplib and test_ssl to use it. This patch (is_ipv6_enabled.diff) must be applied before ssl_ipv6.diff.

----------
keywords: +patch
nosy: +neologix
Added file: http://bugs.python.org/file21811/ssl_ipv6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11811>
_______________________________________

From report at bugs.python.org  Wed Apr 27 23:03:21 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 27 Apr 2011 21:03:21 +0000
Subject: [issue11811] ssl.get_server_certificate() does not work for IPv6
	addresses
In-Reply-To: <1302383900.51.0.808943452569.issue11811@psf.upfronthosting.co.za>
Message-ID: <1303938201.75.0.181954572712.issue11811@psf.upfronthosting.co.za>


Changes by Charles-Francois Natali <neologix at free.fr>:


Added file: http://bugs.python.org/file21812/is_ipv6_enabled.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11811>
_______________________________________

From report at bugs.python.org  Wed Apr 27 23:03:59 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 27 Apr 2011 21:03:59 +0000
Subject: [issue10148] st_mtime differs after shutil.copy2
In-Reply-To: <1287530071.19.0.608159353416.issue10148@psf.upfronthosting.co.za>
Message-ID: <1303938239.55.0.0685519488063.issue10148@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Python >=3.3 contains os.futimens() and os.utimensat() functions.

I have filed issue #11941, which suggests to add support for nanosecond resolution in result of os.stat().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10148>
_______________________________________

From report at bugs.python.org  Wed Apr 27 23:07:23 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 27 Apr 2011 21:07:23 +0000
Subject: [issue11942] Fix signature of Py_AddPendingCall
In-Reply-To: <1303938443.0.0.0267122808218.issue11942@psf.upfronthosting.co.za>
Message-ID: <1303938443.0.0.0267122808218.issue11942@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Following up with http://mail.python.org/pipermail/docs/2011-April/004021.html here's a couple of patch (the first for 2.7/3.1, the other for 3.2/default) to fix the signature of Py_AddPendingCall (in particular the return type).

Adding in CC Ezio since he fixed issue11865.

----------
assignee: docs at python
components: Documentation
files: py_addpendingcall-py27.patch
keywords: patch
messages: 134620
nosy: docs at python, ezio.melotti, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Fix signature of Py_AddPendingCall
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21813/py_addpendingcall-py27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11942>
_______________________________________

From report at bugs.python.org  Wed Apr 27 23:07:28 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 27 Apr 2011 21:07:28 +0000
Subject: [issue11942] Fix signature of Py_AddPendingCall
In-Reply-To: <1303938443.0.0.0267122808218.issue11942@psf.upfronthosting.co.za>
Message-ID: <1303938448.67.0.77875515002.issue11942@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


Added file: http://bugs.python.org/file21814/py_addpendingcall-py32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11942>
_______________________________________

From report at bugs.python.org  Wed Apr 27 23:42:46 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Apr 2011 21:42:46 +0000
Subject: [issue11926] help("keywords") returns incomplete list of keywords
In-Reply-To: <1303782960.65.0.80653815306.issue11926@psf.upfronthosting.co.za>
Message-ID: <1303940566.47.0.0693512121085.issue11926@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

+1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11926>
_______________________________________

From report at bugs.python.org  Wed Apr 27 23:52:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Apr 2011 21:52:11 +0000
Subject: [issue11811] ssl.get_server_certificate() does not work for IPv6
	addresses
In-Reply-To: <1303938150.16.0.872505393751.issue11811@psf.upfronthosting.co.za>
Message-ID: <1303941107.3591.15.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hello,

> This patch (is_ipv6_enabled.diff) must be applied before
> ssl_ipv6.diff.

is_ipv6_enabled.diff is fine.
As for ssl_ipv6.diff, it fails on certificate verification:

======================================================================
ERROR: test_get_server_certificate (test.test_ssl.NetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/test/test_ssl.py", line 630, in test_get_server_certificate
    _test_get_server_certificate('ipv6.google.com', 443)
  File "/home/antoine/cpython/default/Lib/test/test_ssl.py", line 622, in _test_get_server_certificate
    pem = ssl.get_server_certificate((host, port), ca_certs=SVN_PYTHON_ORG_ROOT_CERT)
  File "/home/antoine/cpython/default/Lib/ssl.py", line 548, in get_server_certificate
    cert_reqs=cert_reqs, ca_certs=ca_certs)
  File "/home/antoine/cpython/default/Lib/ssl.py", line 498, in wrap_socket
    ciphers=ciphers)
  File "/home/antoine/cpython/default/Lib/ssl.py", line 255, in __init__
    raise x
  File "/home/antoine/cpython/default/Lib/ssl.py", line 251, in __init__
    self.do_handshake()
  File "/home/antoine/cpython/default/Lib/ssl.py", line 430, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [Errno 1] _ssl.c:389: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

I think you should simply use ca_certs=None when testing with the Google
host.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11811>
_______________________________________

From report at bugs.python.org  Wed Apr 27 23:54:01 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Apr 2011 21:54:01 +0000
Subject: [issue11942] Fix signature of Py_AddPendingCall
In-Reply-To: <1303938443.0.0.0267122808218.issue11942@psf.upfronthosting.co.za>
Message-ID: <E1QFCgI-0007GC-Rm@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6739b9ab7ced by Ezio Melotti in branch '2.7':
#11942: Fix return type of Py_AddPendingCall. Patch by Sandro Tosi.
http://hg.python.org/cpython/rev/6739b9ab7ced

New changeset fd1f47a57ba2 by Ezio Melotti in branch '3.1':
#11942: Fix return type of Py_AddPendingCall. Patch by Sandro Tosi.
http://hg.python.org/cpython/rev/fd1f47a57ba2

New changeset 119c7219b1ac by Ezio Melotti in branch '3.2':
#11942: merge with 3.1.
http://hg.python.org/cpython/rev/119c7219b1ac

New changeset 1cdcd1a25025 by Ezio Melotti in branch 'default':
#11942: merge with 3.2.
http://hg.python.org/cpython/rev/1cdcd1a25025

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11942>
_______________________________________

From report at bugs.python.org  Wed Apr 27 23:54:44 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Apr 2011 21:54:44 +0000
Subject: [issue11942] Fix signature of Py_AddPendingCall
In-Reply-To: <1303938443.0.0.0267122808218.issue11942@psf.upfronthosting.co.za>
Message-ID: <1303941284.6.0.0790126590696.issue11942@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the patch!

----------
assignee: docs at python -> ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11942>
_______________________________________

From report at bugs.python.org  Thu Apr 28 00:00:35 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Apr 2011 22:00:35 +0000
Subject: [issue11938] duplicated test name in getattr_static's test case
In-Reply-To: <1303912284.26.0.777560143006.issue11938@psf.upfronthosting.co.za>
Message-ID: <E1QFCmg-0007ru-HW@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ef35dae58077 by Ezio Melotti in branch '3.2':
#11938: Fix duplicated test name in test_inspect. Patch by Andreas St?hrk.
http://hg.python.org/cpython/rev/ef35dae58077

New changeset bdd6d8631994 by Ezio Melotti in branch 'default':
#11938: merge with 3.2.
http://hg.python.org/cpython/rev/bdd6d8631994

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11938>
_______________________________________

From report at bugs.python.org  Thu Apr 28 00:01:29 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Apr 2011 22:01:29 +0000
Subject: [issue11938] duplicated test name in getattr_static's test case
In-Reply-To: <1303912284.26.0.777560143006.issue11938@psf.upfronthosting.co.za>
Message-ID: <1303941689.29.0.408017283147.issue11938@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the patch!

----------
assignee:  -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11938>
_______________________________________

From report at bugs.python.org  Thu Apr 28 00:28:52 2011
From: report at bugs.python.org (Quinn Slack)
Date: Wed, 27 Apr 2011 22:28:52 +0000
Subject: [issue11943] Add TLS-SRP (RFC 5054) support to ssl, _ssl, http,
	and urllib
In-Reply-To: <1303943331.28.0.343800117154.issue11943@psf.upfronthosting.co.za>
Message-ID: <1303943331.28.0.343800117154.issue11943@psf.upfronthosting.co.za>


New submission from Quinn Slack <sqs at cs.stanford.edu>:

This patch adds support for TLS-SRP (RFC 5054[1]) to Python ssl.SSLSocket, _ssl.c, http, and urllib. TLS-SRP lets a client and server establish a mutually authenticated SSL channel using only a username and password (a certificate may also be used to supplement authentication).

TLS-SRP is supported in GnuTLS, OpenSSL 1.0.1 (soon to be released), cURL, TLSLite (a Python module), and mod_gnutls. There are also patches for Chrome, NSS, mod_ssl, Django, Firefox, WordPress, and SJCL (see [2]). Much of the
growing interest in TLS-SRP is because a couple key PAKE patents expired recently. Also, CAs are perceived as more vulnerable now than a few years ago, and in certain cases TLS-SRP is a good substitute for or supplement to certificate auth. Two Python-specific use cases for TLS-SRP are calling HTTP APIs that require auth, and test suites written in Python for networked software (e.g., Chromium uses TLSLite for network testing).

I'm submitting this patch now to begin gathering feedback.

###########################################################
EXAMPLE USAGE
###########################################################

import urllib.request
res = urllib.request.urlopen("https://tls-srp.test.trustedhttp.org/"
                             tls_username='jsmith', tls_password='abc')
print(res.read())
# => "user: jsmith"

###########################################################

import ssl, http
context = ssl.SSLContext(ssl.PROTOCOL_TLSv1)
context.set_tls_username_password('jsmith', 'abc')
h = http.client.HTTPSConnection('tls-srp.test.trustedhttp.org', 443, context=context)
h.request('GET', '/')
resp = h.getresponse()
print(resp.status)
# => 200
print(resp.read())
# => "user: jsmith"

###########################################################

import socket, ssl
with socket.socket() as sock:
    s = ssl.wrap_socket(sock,
                        ssl_version=ssl.PROTOCOL_TLSv1,
                        ciphers='SRP',
                        tls_username='jsmith',
                        tls_password='abc')
    s.connect(('tls-srp.test.trustedhttp.org', 443))
    s.write(b"GET / HTTP/1.0\n\n")
    print(s.read())

###########################################################



[1] http://tools.ietf.org/html/rfc5054
[2] http://trustedhttp.org/
[3] http://trustedhttp.org/wiki/TLS-SRP_in_Python

----------
components: Library (Lib)
files: python+tls-srp-20110427.patch
hgrepos: 23
keywords: patch
messages: 134627
nosy: sqs
priority: normal
severity: normal
status: open
title: Add TLS-SRP (RFC 5054) support to ssl, _ssl, http, and urllib
versions: Python 3.3
Added file: http://bugs.python.org/file21815/python+tls-srp-20110427.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11943>
_______________________________________

From report at bugs.python.org  Thu Apr 28 00:55:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Apr 2011 22:55:08 +0000
Subject: [issue11943] Add TLS-SRP (RFC 5054) support to ssl, _ssl, http,
	and urllib
In-Reply-To: <1303943331.28.0.343800117154.issue11943@psf.upfronthosting.co.za>
Message-ID: <1303944908.08.0.245155422.issue11943@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +debatem1, pitrou
stage:  -> patch review
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11943>
_______________________________________

From report at bugs.python.org  Thu Apr 28 01:33:16 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Apr 2011 23:33:16 +0000
Subject: [issue11940] Howto/Advocacy - update the link to John Ousterhout paper
In-Reply-To: <1303934671.48.0.846798146708.issue11940@psf.upfronthosting.co.za>
Message-ID: <E1QFEEM-0005zs-GV@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 4c5babbf7a73 by Raymond Hettinger in branch '3.1':
Issue #11940: Update external link.
http://hg.python.org/cpython/rev/4c5babbf7a73

New changeset 08647ab0ead7 by Raymond Hettinger in branch '3.2':
Issue #11940: Update external link.
http://hg.python.org/cpython/rev/08647ab0ead7

New changeset 618642ba7551 by Raymond Hettinger in branch 'default':
Issue #11940: Update external link.
http://hg.python.org/cpython/rev/618642ba7551

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11940>
_______________________________________

From report at bugs.python.org  Thu Apr 28 01:34:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Apr 2011 23:34:17 +0000
Subject: [issue11940] Howto/Advocacy - update the link to John Ousterhout paper
In-Reply-To: <1303934671.48.0.846798146708.issue11940@psf.upfronthosting.co.za>
Message-ID: <E1QFEFM-000641-HC@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset eb7c4526ccbf by Raymond Hettinger in branch '2.7':
Issue #11940: Update external link.
http://hg.python.org/cpython/rev/eb7c4526ccbf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11940>
_______________________________________

From report at bugs.python.org  Thu Apr 28 01:34:56 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 27 Apr 2011 23:34:56 +0000
Subject: [issue11940] Howto/Advocacy - update the link to John Ousterhout paper
In-Reply-To: <1303934671.48.0.846798146708.issue11940@psf.upfronthosting.co.za>
Message-ID: <1303947296.42.0.114339444993.issue11940@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11940>
_______________________________________

From report at bugs.python.org  Thu Apr 28 01:38:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Apr 2011 23:38:57 +0000
Subject: [issue10419] distutils command build_scripts fails with
	UnicodeDecodeError
In-Reply-To: <1289766753.91.0.865805184241.issue10419@psf.upfronthosting.co.za>
Message-ID: <1303947537.31.0.43411102261.issue10419@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m not sure how I feel about using surrogateescape.  The distutils source is very similar across 2.7, 3.1, 3.2 and default, especially after the Great Revert and freeze last year to restore buggy-but-known behavior while the distutils2 project was created and allowed to fix things and break stuff.  Haypo added a fix using surrogateescape in 3.2, so it couldn?t be backported to all stable branches.  You may say that at least it was fixed in one version, which is something good.  I don?t know if I?d prefer to apply the patch (if a test is provided) or to raise an exception instead of silently changing behavior.

----------
components: +Distutils2
nosy: +alexis
versions: +3rd party, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10419>
_______________________________________

From report at bugs.python.org  Thu Apr 28 01:39:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Apr 2011 23:39:48 +0000
Subject: [issue10060] python.exe crashes or hangs on help() modules when bad
	modules found
In-Reply-To: <1286676227.2.0.62342583611.issue10060@psf.upfronthosting.co.za>
Message-ID: <1303947588.09.0.227747843187.issue10060@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10060>
_______________________________________

From report at bugs.python.org  Thu Apr 28 02:12:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Apr 2011 00:12:48 +0000
Subject: [issue11883] Call connect() before sending an email with smtplib
In-Reply-To: <1303246763.2.0.10135500331.issue11883@psf.upfronthosting.co.za>
Message-ID: <1303949568.2.0.639656532178.issue11883@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?d remove the ?Connect to the SMTP server? comment before ?s.connect()?.  It?s redundant, contrary to the other comment (which no doubt prompted you to add a comment too) ?Send the message via local SMTP server? which helpfully introduces the next lines of code.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11883>
_______________________________________

From report at bugs.python.org  Thu Apr 28 02:20:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Apr 2011 00:20:25 +0000
Subject: [issue11726] linecache becomes specific to Python scripts in Python 3
In-Reply-To: <1301566082.59.0.198488725536.issue11726@psf.upfronthosting.co.za>
Message-ID: <1303950025.8.0.0198692026696.issue11726@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11726>
_______________________________________

From report at bugs.python.org  Thu Apr 28 03:00:47 2011
From: report at bugs.python.org (Jeong-Min Lee)
Date: Thu, 28 Apr 2011 01:00:47 +0000
Subject: [issue11944] Function call with * and generator hide exception raised
	by generator.
In-Reply-To: <1303952447.32.0.22528411021.issue11944@psf.upfronthosting.co.za>
Message-ID: <1303952447.32.0.22528411021.issue11944@psf.upfronthosting.co.za>


New submission from Jeong-Min Lee <falsetru at gmail.com>:

Expected "TypeError: cannot concatenate 'str' and 'int' objects" exception raised, but got following result.


>>> def g():
...     '1' + 0
...     yield 1, 2
...     yield 3, 4
...
>>> zip(*g())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: zip() argument after * must be a sequence, not generator
>>> (lambda xs: 0)(*g())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: <lambda>() argument after * must be a sequence, not generator
>>> list(*g())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type object argument after * must be a sequence, not generator
>>> list(g())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in g
TypeError: cannot concatenate 'str' and 'int' objects

----------
components: Interpreter Core
messages: 134632
nosy: falsetru
priority: normal
severity: normal
status: open
title: Function call with * and generator hide exception raised by generator.
type: behavior
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11944>
_______________________________________

From report at bugs.python.org  Thu Apr 28 03:00:58 2011
From: report at bugs.python.org (Jeong-Min Lee)
Date: Thu, 28 Apr 2011 01:00:58 +0000
Subject: [issue11944] Function call with * and generator hide exception raised
	by generator.
In-Reply-To: <1303952447.32.0.22528411021.issue11944@psf.upfronthosting.co.za>
Message-ID: <1303952458.98.0.0505905662949.issue11944@psf.upfronthosting.co.za>


Changes by Jeong-Min Lee <falsetru at gmail.com>:


----------
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11944>
_______________________________________

From report at bugs.python.org  Thu Apr 28 03:11:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Apr 2011 01:11:28 +0000
Subject: [issue11762] Ast doc: warning and version number
In-Reply-To: <1301933761.05.0.937546235723.issue11762@psf.upfronthosting.co.za>
Message-ID: <1303953088.41.0.415660313875.issue11762@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Please improve this rough phrasing: ?Check the value of *ast.__version__* to write version-specific code blocks if you need to work across versions.?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11762>
_______________________________________

From report at bugs.python.org  Thu Apr 28 03:11:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Apr 2011 01:11:36 +0000
Subject: [issue11762] Ast doc: warning and version number
In-Reply-To: <1301933761.05.0.937546235723.issue11762@psf.upfronthosting.co.za>
Message-ID: <1303953096.11.0.426287402348.issue11762@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11762>
_______________________________________

From report at bugs.python.org  Thu Apr 28 03:39:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Apr 2011 01:39:59 +0000
Subject: [issue11933] newer() function in dep_util.py mixes up new vs. old
	files due stat.st_mtime vs stat[ST_MTIME]
In-Reply-To: <1303878590.96.0.749813744893.issue11933@psf.upfronthosting.co.za>
Message-ID: <1303954799.95.0.928122586517.issue11933@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I was trying to suggest that the move to stat.st_mtime in dep_util.py
> in the hg commit I mentioned be reverted back to use stat[ST_MTIME],
> thereby matching the other python releases and the old behavior (and
> matching file_util.py). It seems to me that would be the safest
> course when it comes to side-effects.
Agreed.

> If it were desired to determine which file was newer using sub-second
> values, perhaps that would make a reasonable change in distutils2,
> but files created with a few microseconds would have to be considered
> equivalent due to the reduced precision available in python floats
> (53 bits on my platform, if I understand correctly) as compared to
> the 64 bit precision used by some operating systems and file systems.
Interesting.  Can you open another bug, using type ?feature request? and component ?distutils2? so that we discuss that?  Alternatively, send an email to the-fellowship-of-the-packaging Google group (more people (including distutils wizards) follow the group than the bug tracker).

> However, I think I'd prefer to turn the decision and further process
> over to you, if you don't mind.
No problem.  Thanks to your patch and diagnosis, it should be easy to write a test and fix.  I hope you?ll be available to run the test on your machine.

> I thank you and your colleagues for your excellent work with python,
Thank you for doing your part as a user!  (It?s weird to see ?colleagues? used with something that?s not a job.  We do this for fun, you know :)

> and with making it platform independent--a very difficult part of the
> work indeed.
Heh, the more I learn about Python, the more I hate hardware and operating systems :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11933>
_______________________________________

From report at bugs.python.org  Thu Apr 28 04:20:30 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 28 Apr 2011 02:20:30 +0000
Subject: [issue11926] help("keywords") returns incomplete list of keywords
In-Reply-To: <1303782960.65.0.80653815306.issue11926@psf.upfronthosting.co.za>
Message-ID: <1303957230.86.0.438522962225.issue11926@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attached patch adds True/False/None to the list of keywords and a special-cased path to have help('True'/'False'/'None') return the same as help(True/False/None).  I also added tests and found out that nonlocal was missing too, so I added it to the list (the changes to Lib/pydoc_data/topics.py are not included in the patch -- use make pydoc-topics in Doc/ to see them).

----------
assignee: docs at python -> ezio.melotti
keywords: +needs review, patch
stage: needs patch -> patch review
versions: +Python 3.1
Added file: http://bugs.python.org/file21816/issue11926.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11926>
_______________________________________

From report at bugs.python.org  Thu Apr 28 04:53:26 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 28 Apr 2011 02:53:26 +0000
Subject: [issue11944] Function call with * and generator hide exception raised
	by generator.
In-Reply-To: <1303952447.32.0.22528411021.issue11944@psf.upfronthosting.co.za>
Message-ID: <1303959206.53.0.707913864462.issue11944@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It's not just hiding the real error, it's also saying something that isn't true. If you remove the deliberate error from the generator definition, it is clear that generators are perfectly acceptable as *arg inputs:

>>> def g(): yield 1, 2
... 
>>> list(*g())
[1, 2]

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11944>
_______________________________________

From report at bugs.python.org  Thu Apr 28 04:59:25 2011
From: report at bugs.python.org (Eric Rannaud)
Date: Thu, 28 Apr 2011 02:59:25 +0000
Subject: [issue1669349] make install fails if no previous Python installation
Message-ID: <1303959565.41.0.999571285515.issue1669349@psf.upfronthosting.co.za>


Eric Rannaud <eric.rannaud at gmail.com> added the comment:

I get the same error when building Python-2.5.6c1 on Fedora 14 (with python2.7 installed).

./configure --prefix=$PREFIX && make install

Just to clarify the workaround used by lkraav on Gentoo, I attached a patch that manually enables unicodedata in Modules/Setup.dist

----------
keywords: +patch
nosy: +Eric.Rannaud
versions: +Python 2.5
Added file: http://bugs.python.org/file21817/Python-2.5.6c1-issue1669349-workaround.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1669349>
_______________________________________

From report at bugs.python.org  Thu Apr 28 05:04:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Apr 2011 03:04:03 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1303959843.13.0.131075493936.issue9723@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Someone on Stack Overflow suggested subprocess.list2cmdline.  It?s one of those functions undocumented and absent from __all__ that somehow get found and used by some people.  So when we make the patch, let?s include links to the new function doc from subprocess and pipes, and reply to the Stack Overflow thread.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Thu Apr 28 05:05:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Apr 2011 03:05:28 +0000
Subject: [issue11944] Function call with * and generator hide exception raised
	by generator.
In-Reply-To: <1303952447.32.0.22528411021.issue11944@psf.upfronthosting.co.za>
Message-ID: <1303959928.18.0.782640347109.issue11944@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11944>
_______________________________________

From report at bugs.python.org  Thu Apr 28 05:42:25 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 28 Apr 2011 03:42:25 +0000
Subject: [issue11945] Adopt and document consistent semantics for handling NaN
	values in containers
In-Reply-To: <1303962145.0.0.00759154980454.issue11945@psf.upfronthosting.co.za>
Message-ID: <1303962145.0.0.00759154980454.issue11945@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The question of the way Python handles NaN came up again on python-dev recently. The current semantics have been assessed as a reasonable compromise, but a poorly explained and inconsistently implemented one.

Based on a suggestion from Terry Reedy [1] I propose that a new glossary entry be added for "Reflexive Equality":

"Part of the standard mathematical definition of equality is that it is reflexive, that is ``x is y`` necessarily implies that ``x == y``. This is an essential property that is relied upon when designing and implementing container classes such as ``list`` and ``dict``.

However, the IEEE754 committee defined the float Not_a_Number (NaN) values as being unequal with all others floats, including themselves. While this design choice violates the basic mathematical definition of equality, it is still considered desirable to be able to correctly implement IEEE754 floating point semantics, and those of similar types such as ``decimal.Decimal``, directly in Python.

Accordingly, Python makes the follow compromise in order to cope with types that use non-reflexive definitions of equality without breaking the invariants of container classes that rely on reflexive definitions of equality:

1. Direct equality comparisons involving ``NaN``, such as ``nan=float('NaN'); nan == nan``, follow the IEEE754 rule and return False (or True in the case of ``!=``). This rule applies to ``float`` and ``decimal.Decimal`` within the builtins and standard library.

2. Indirect comparisons conducted internally by container classes, such as ``x in someset`` or ``seq.count(x)`` or ``somedict[x]``, enforce reflexivity by using the expressions ``x is y or x == y`` and ``x is not y and x != y`` respectively rather than assuming that ``x == y`` and ``x != y`` will always respect the reflexivity requirement. This rule applies to all container types within the builtins and standard library that may contain values of arbitrary types.

Also see [1] for a more comprehensive theoretical discussion of this topic.

[1] http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/"

Specific container methods that have currently been identified as relying on the reflexivity assumption are:
- __contains__() (for x in c: assert x in c)
- __eq__() (assert [x] == [x])
- __ne__() (assert not [x] != [x])
- index() (for x in c: assert 0 <= c.index(x) < len(c))
- count() (for x in c: assert c.count(x) > 0)

collections.Sequence and array.array (with the 'f' or 'd' type indicators) have already been identified as container classes in the standard library that fails to follow the second guideline and hence fail to correctly implement the above invariants in the presence of non-reflexive definitions of equality. They will be fixed as part of implementing this patch. Other container types that fail to correctly enforce reflexivity can be fixed as they are identified.

[1] http://mail.python.org/pipermail/python-dev/2011-April/110962.html

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 134639
nosy: docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Adopt and document consistent semantics for handling NaN values in containers
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11945>
_______________________________________

From report at bugs.python.org  Thu Apr 28 05:50:39 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 28 Apr 2011 03:50:39 +0000
Subject: [issue11945] Adopt and document consistent semantics for handling NaN
	values in containers
In-Reply-To: <1303962145.0.0.00759154980454.issue11945@psf.upfronthosting.co.za>
Message-ID: <1303962639.29.0.237718412796.issue11945@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Actually, based on the NumPy precedent [1], array.array should be fine as is. Since it uses raw C floats and doubles internally, rather than Python objects, there is no clear concept of "object identity" to use to enforce reflexivity.

[1] http://mail.python.org/pipermail/python-dev/2011-April/110987.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11945>
_______________________________________

From report at bugs.python.org  Thu Apr 28 06:02:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Apr 2011 04:02:27 +0000
Subject: [issue11926] help("keywords") returns incomplete list of keywords
In-Reply-To: <1303782960.65.0.80653815306.issue11926@psf.upfronthosting.co.za>
Message-ID: <1303963347.48.0.571453621732.issue11926@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I asked about nonlocal in #9724.

Patch looks good (I has to repress a gut reaction ?eval is evil? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11926>
_______________________________________

From report at bugs.python.org  Thu Apr 28 06:46:56 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 28 Apr 2011 04:46:56 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1303966016.18.0.186848050157.issue11457@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Closed #11941 as a duplicate of this.

----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11457>
_______________________________________

From report at bugs.python.org  Thu Apr 28 06:47:27 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 28 Apr 2011 04:47:27 +0000
Subject: [issue11941] Support st_atim,
	st_mtim and st_ctim attributes in os.stat_result
In-Reply-To: <1303938022.85.0.623572797729.issue11941@psf.upfronthosting.co.za>
Message-ID: <1303966047.72.0.0533445234221.issue11941@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

I think this is a duplicate of #11457.

----------
nosy: +rosslagerwall
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11941>
_______________________________________

From report at bugs.python.org  Thu Apr 28 06:59:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Apr 2011 04:59:51 +0000
Subject: [issue11926] help("keywords") returns incomplete list of keywords
In-Reply-To: <1303782960.65.0.80653815306.issue11926@psf.upfronthosting.co.za>
Message-ID: <E1QFJKN-0002gy-NY@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 99d5542399a1 by Ezio Melotti in branch '3.1':
#11926: add missing keywords to help("keywords").
http://hg.python.org/cpython/rev/99d5542399a1

New changeset 7b4c853aa07d by Ezio Melotti in branch '3.2':
#11926: merge with 3.1.
http://hg.python.org/cpython/rev/7b4c853aa07d

New changeset 0d8a6833f5be by Ezio Melotti in branch 'default':
#11926: merge with 3.2.
http://hg.python.org/cpython/rev/0d8a6833f5be

New changeset ffd83aeb0b67 by Ezio Melotti in branch '2.7':
Backport test from #11926.
http://hg.python.org/cpython/rev/ffd83aeb0b67

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11926>
_______________________________________

From report at bugs.python.org  Thu Apr 28 07:06:23 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 28 Apr 2011 05:06:23 +0000
Subject: [issue11926] help("keywords") returns incomplete list of keywords
In-Reply-To: <1303782960.65.0.80653815306.issue11926@psf.upfronthosting.co.za>
Message-ID: <1303967183.43.0.964522120578.issue11926@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed True/False/None in 3.1/3.2/3.3, nonlocal in 3.1 (it was already ok in 3.2/3.3), and backported tests on 2.7.  Thanks for the pointer to #9724.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11926>
_______________________________________

From report at bugs.python.org  Thu Apr 28 07:32:54 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 28 Apr 2011 05:32:54 +0000
Subject: [issue11945] Adopt and document consistent semantics for handling NaN
	values in containers
In-Reply-To: <1303962145.0.0.00759154980454.issue11945@psf.upfronthosting.co.za>
Message-ID: <1303968774.09.0.597738647828.issue11945@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Bertrand Meyer's exposition is flowery, and he is a learned man, but the basic argument he makes is:

Reflexivity of equality  is something that we expect for any data type, and it seems hard to justify that a value is not equal to itself. As to assignment, what good can it be if it does not make the target equal to the source value?  

The argument is flawed: now that NaN exists, and is not equal to itself in value, there should be, and need be, no expectation that assignment elsewhere should make the target equal to the source in value.  It can, and in Python, should, make them match in identity (is) but not in value (==, equality).

I laud the idea of adding to definition of reflexive equality to the glossary.  However, I think it is presently a bug that a list containing a NaN value compares equal to itself.  Yes, such a list should have the same identity (is), but should not be equal.

----------
nosy: +v+python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11945>
_______________________________________

From report at bugs.python.org  Thu Apr 28 07:38:32 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 28 Apr 2011 05:38:32 +0000
Subject: [issue9724] help('nonlocal') missing
In-Reply-To: <1283264506.65.0.891353538251.issue9724@psf.upfronthosting.co.za>
Message-ID: <1303969112.06.0.622909657414.issue9724@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I backported it to 3.1 as part of 99d5542399a1.

----------
nosy: +ezio.melotti
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9724>
_______________________________________

From report at bugs.python.org  Thu Apr 28 07:55:57 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Thu, 28 Apr 2011 05:55:57 +0000
Subject: [issue11811] ssl.get_server_certificate() does not work for IPv6
	addresses
In-Reply-To: <1302383900.51.0.808943452569.issue11811@psf.upfronthosting.co.za>
Message-ID: <1303970157.89.0.346145156646.issue11811@psf.upfronthosting.co.za>


Changes by Charles-Francois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file21811/ssl_ipv6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11811>
_______________________________________

From report at bugs.python.org  Thu Apr 28 07:56:10 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Thu, 28 Apr 2011 05:56:10 +0000
Subject: [issue11811] ssl.get_server_certificate() does not work for IPv6
	addresses
In-Reply-To: <1302383900.51.0.808943452569.issue11811@psf.upfronthosting.co.za>
Message-ID: <1303970170.67.0.207248994277.issue11811@psf.upfronthosting.co.za>


Changes by Charles-Francois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file21812/is_ipv6_enabled.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11811>
_______________________________________

From report at bugs.python.org  Thu Apr 28 07:59:45 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Thu, 28 Apr 2011 05:59:45 +0000
Subject: [issue11811] ssl.get_server_certificate() does not work for IPv6
	addresses
In-Reply-To: <1302383900.51.0.808943452569.issue11811@psf.upfronthosting.co.za>
Message-ID: <1303970385.62.0.764121411522.issue11811@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> As for ssl_ipv6.diff, it fails on certificate verification:

Of course.
The new version should fix this (tested on google.com).

> is_ipv6_enabled.diff is fine.

Since IPv6 capability is unlikely to change in the middle of a test, I replaced the function is_ipv6_enabled() by a boolean IPV6_ENABLED. That way, it's closer to socket.has_ipv6, and spares a socket creation/bind/close at each call.

----------
Added file: http://bugs.python.org/file21818/ssl_ipv6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11811>
_______________________________________

From report at bugs.python.org  Thu Apr 28 08:00:10 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Thu, 28 Apr 2011 06:00:10 +0000
Subject: [issue11811] ssl.get_server_certificate() does not work for IPv6
	addresses
In-Reply-To: <1302383900.51.0.808943452569.issue11811@psf.upfronthosting.co.za>
Message-ID: <1303970410.4.0.48546668026.issue11811@psf.upfronthosting.co.za>


Changes by Charles-Francois Natali <neologix at free.fr>:


Added file: http://bugs.python.org/file21819/is_ipv6_enabled.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11811>
_______________________________________

From report at bugs.python.org  Thu Apr 28 08:06:49 2011
From: report at bugs.python.org (Markus Duft)
Date: Thu, 28 Apr 2011 06:06:49 +0000
Subject: [issue11937] Interix support
In-Reply-To: <1303911825.14.0.5833510557.issue11937@psf.upfronthosting.co.za>
Message-ID: <1303970809.4.0.52216488517.issue11937@psf.upfronthosting.co.za>


Markus Duft <markus.duft at salomon.at> added the comment:

if the buildbot does not need to be reached from the outside, i could provide one, yes (i'm behind a company firewall/proxy infrastructure)

as for the patch: comments and improvement suggestions welcome :)

as for interix (actually SUA - Subsystem for UNIX Applications): It is a POSIX compatible layer on top of MS Windows (since 2000, up to currently 2008R2/7). I'm working on building gentoo prefix there, which brings a lot improvement to the rather outdated userland of interix (new GCC, python ;), new perl, etc.). Interix suffers from a few smaller problems, making it feel unstable in certain situations. For example, fork() tends to fail with EAGAIN, poll() does not work correctly, etc. To compensate this, i have build a library (suacomp.sf.net) which wraps a lot of library functions. my python fixes python just enough to work with suacomp installed. without suacomp, python will still build (as suacomp only wraps existing apis), but will not work too well (depending on what your doing).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11937>
_______________________________________

From report at bugs.python.org  Thu Apr 28 08:19:51 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 28 Apr 2011 06:19:51 +0000
Subject: [issue11937] Interix support
In-Reply-To: <1303911825.14.0.5833510557.issue11937@psf.upfronthosting.co.za>
Message-ID: <1303971591.17.0.375149613156.issue11937@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Guido established a policy a few years ago that we should rather not incorporate support for every minority platform for which people contribute patches. While I'd personally agree that an Interix port would certainly be "fun", pragmatically, I'm -1 on having the code in the code basis, and propose to close this issue as "won't fix".

We would certainly be happy to link to gentoo prefix from the "other ports" page on python.org.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11937>
_______________________________________

From report at bugs.python.org  Thu Apr 28 08:21:27 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 28 Apr 2011 06:21:27 +0000
Subject: [issue11945] Adopt and document consistent semantics for handling NaN
	values in containers
In-Reply-To: <1303962145.0.0.00759154980454.issue11945@psf.upfronthosting.co.za>
Message-ID: <1303971687.93.0.32783991787.issue11945@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> I think it is presently a bug that a list containing
> a NaN value compares equal to itself. 

Moreover, it also compares equal to another list containing the same NaN:

>>> [nan] is [nan]
False
>>> [nan] == [nan]
True

Here is another case of is implies == optimization breaking NaN property in stdlib:

>>> import ctypes
>>> x = ctypes.c_double(nan)
>>> x == x
True

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11945>
_______________________________________

From report at bugs.python.org  Thu Apr 28 08:23:08 2011
From: report at bugs.python.org (Markus Duft)
Date: Thu, 28 Apr 2011 06:23:08 +0000
Subject: [issue11937] Interix support
In-Reply-To: <1303911825.14.0.5833510557.issue11937@psf.upfronthosting.co.za>
Message-ID: <1303971788.5.0.741487917415.issue11937@psf.upfronthosting.co.za>


Markus Duft <markus.duft at salomon.at> added the comment:

since the patch is rather small, and prove to not "fluctuate" too much on releases, i'd be willing to keep maintaining them, although i think that it would not cause too much problems to integrate it into the code base.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11937>
_______________________________________

From report at bugs.python.org  Thu Apr 28 08:51:25 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 28 Apr 2011 06:51:25 +0000
Subject: [issue11397] os.path.realpath() may produce incorrect results
In-Reply-To: <1299259038.05.0.675723191983.issue11397@psf.upfronthosting.co.za>
Message-ID: <1303973485.59.0.801034556401.issue11397@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

(For 3.2) Patch v2. Added some more corner case tests.

----------
Added file: http://bugs.python.org/file21820/issue11397_py32_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11397>
_______________________________________

From report at bugs.python.org  Thu Apr 28 09:01:49 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 28 Apr 2011 07:01:49 +0000
Subject: [issue11945] Adopt and document consistent semantics for handling NaN
	values in containers
In-Reply-To: <1303962145.0.0.00759154980454.issue11945@psf.upfronthosting.co.za>
Message-ID: <1303974109.28.0.0343646743138.issue11945@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The status quo works. Proposals to change it on theoretical grounds have a significantly higher bar to meet than proposals to simply document it clearly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11945>
_______________________________________

From report at bugs.python.org  Thu Apr 28 09:07:14 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 28 Apr 2011 07:07:14 +0000
Subject: [issue11945] Adopt and document consistent semantics for handling NaN
	values in containers
In-Reply-To: <1303962145.0.0.00759154980454.issue11945@psf.upfronthosting.co.za>
Message-ID: <1303974434.69.0.478222305966.issue11945@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11945>
_______________________________________

From report at bugs.python.org  Thu Apr 28 09:16:34 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 28 Apr 2011 07:16:34 +0000
Subject: [issue11945] Adopt and document consistent semantics for handling NaN
	values in containers
In-Reply-To: <1303974109.28.0.0343646743138.issue11945@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=4LRRp67+ZRW5QdQaorP9dBY=jPQ@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Apr 28, 2011 at 3:01 AM, Nick Coghlan <report at bugs.python.org> wrote:
..
> The status quo works.

No it does not. I am yet to see a Python program that uses
non-reflexivity of NaN in a meaningful way.  What I've seen was either
programmers ignore it and write slightly buggy programs ("slightly"
because it is actually hard to produce a NaN in Python code) or they
add extra code to filter out NaN values before numbers are compared.

> Proposals to change it on theoretical grounds have a significantly higher bar to meet than proposals
> to simply document it clearly.

Documenting the status quo is necessary for any proposal to change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11945>
_______________________________________

From report at bugs.python.org  Thu Apr 28 09:26:50 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 28 Apr 2011 07:26:50 +0000
Subject: [issue11945] Adopt and document consistent semantics for handling NaN
	values in containers
In-Reply-To: <1303962145.0.0.00759154980454.issue11945@psf.upfronthosting.co.za>
Message-ID: <1303975610.29.0.536082648672.issue11945@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

By "works" I merely meant that you can currently achieve both of the following:

1. Write fully conformant implementations of IEEE754 floating point types, including the non-reflexive NaN comparisons (keeping in mind that, as a value-based specification, "same payload" is the closest IEEE754 can get to "same object")

2. Explicitly force reflexivity when you need it, either by filtering out nonconformant values, or by checking identity before checking equality.

The "pure" equality-tests-are-always-reflexive approach advocated by Meyer rules out option 1. Given that one of the use cases for Python is to prototype algorithms that are later translated to C or C++, formally disallowing that use case would be problematic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11945>
_______________________________________

From report at bugs.python.org  Thu Apr 28 09:32:18 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Apr 2011 07:32:18 +0000
Subject: [issue10761] tarfile.extractall fails to overwrite symlinks
In-Reply-To: <1293063436.61.0.0994372418071.issue10761@psf.upfronthosting.co.za>
Message-ID: <E1QFLhw-0004TG-Jn@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0c8bc3a0130a by Senthil Kumaran in branch '2.7':
Fix closes  issue10761: tarfile.extractall failure  when symlinked files are present.
http://hg.python.org/cpython/rev/0c8bc3a0130a

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10761>
_______________________________________

From report at bugs.python.org  Thu Apr 28 09:35:30 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 28 Apr 2011 07:35:30 +0000
Subject: [issue10761] tarfile.extractall fails to overwrite symlinks
In-Reply-To: <1293063436.61.0.0994372418071.issue10761@psf.upfronthosting.co.za>
Message-ID: <1303976130.6.0.813632859881.issue10761@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I had tried/tested against 3.x branch and did not find the problem. Later realized that it was only again 2.7. Pushed in the changes and the tests. I shall the tests only in 3.x codeline.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10761>
_______________________________________

From report at bugs.python.org  Thu Apr 28 09:40:07 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 28 Apr 2011 07:40:07 +0000
Subject: [issue11945] Adopt and document consistent semantics for handling NaN
	values in containers
In-Reply-To: <1303962145.0.0.00759154980454.issue11945@psf.upfronthosting.co.za>
Message-ID: <1303976407.92.0.622817588638.issue11945@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Nick says (and later explains better what he meant): 
The status quo works. Proposals to change it on theoretical grounds have a significantly higher bar to meet than proposals to simply document it clearly.

I say:
What the status quo doesn't provide is containers that "work".  In this case what I mean by "work" is that equality of containers is based on value, and value comparisons, and accept and embrace non-reflexive equality.  It might be possible to implement alternate containers with these characteristics, but that requires significantly more effort than simply filtering values.

Nonetheless, I totally agree with msg134654, and agree that properly documenting the present implementation would be a great service to users of the present implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11945>
_______________________________________

From report at bugs.python.org  Thu Apr 28 09:55:05 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 28 Apr 2011 07:55:05 +0000
Subject: [issue11945] Adopt and document consistent semantics for handling NaN
	values in containers
In-Reply-To: <1303975610.29.0.536082648672.issue11945@psf.upfronthosting.co.za>
Message-ID: <BANLkTikf18q7_zEdeVxx9i4bnD7ohqPyAA@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Apr 28, 2011 at 3:26 AM, Nick Coghlan <report at bugs.python.org> wrote:
..
> 1. Write fully conformant implementations of IEEE754 floating point types, including the non-reflexive NaN comparisons
> (keeping in mind that, as a value-based specification, "same payload" is the closest IEEE754 can get to "same object")
>

If being "fully conformant" with various IEEE standards was a design
goal for Python, we would have leap seconds in the datetime module.
:-)

Python builtin float equality being reflexive does not in any way
inhibits anyone's ability to *write* a fully conforming
implementation.  In fact, if we ever get arithmetic operations
implemented for ctypes types, I would argue that c_double comparison
of c_double values would need to be changed to match C behavior.  (I
am +0 on changing that even without implementing arithmetics.)

I realize, however that by "status quo" you mean container operations
not calling __eq__ on identical objects.  I agree that this should not
change.  Making float comparison reflexive will actually make this
feature less controversial.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11945>
_______________________________________

From report at bugs.python.org  Thu Apr 28 10:20:33 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 28 Apr 2011 08:20:33 +0000
Subject: [issue10419] distutils command build_scripts fails
	with	UnicodeDecodeError
In-Reply-To: <1303947537.31.0.43411102261.issue10419@psf.upfronthosting.co.za>
Message-ID: <4DB92345.3010105@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

?ric Araujo wrote:
> 
> ?ric Araujo <merwok at netwok.org> added the comment:
> 
> I?m not sure how I feel about using surrogateescape.  The distutils source is very similar across 2.7, 3.1, 3.2 and default, especially after the Great Revert and freeze last year to restore buggy-but-known behavior while the distutils2 project was created and allowed to fix things and break stuff.  Haypo added a fix using surrogateescape in 3.2, so it couldn?t be backported to all stable branches.  You may say that at least it was fixed in one version, which is something good.  I don?t know if I?d prefer to apply the patch (if a test is provided) or to raise an exception instead of silently changing behavior.

I think this patch should be applied to all 3.x versions, since
all of them are affected by the same problem: reading a file with
unknown encoding, adding a shebang and writing it back again.

Python shouldn't really care about the script file's encoding and
since the "surrogateescape" error handler is the only way to
more or less cleanly get around the problem, I'm +1 on adding the
patch to the 3.x series.

I don't think this is needed for 2.7, since Python 2.x's open()
doesn't care about the file encoding anyway.

----------
nosy: +lemburg
title: distutils command build_scripts fails with UnicodeDecodeError -> distutils command build_scripts fails with	UnicodeDecodeError

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10419>
_______________________________________

From report at bugs.python.org  Thu Apr 28 11:00:19 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Apr 2011 09:00:19 +0000
Subject: [issue11858] configparser.ExtendedInterpolation and section case
In-Reply-To: <1302972514.64.0.403074363027.issue11858@psf.upfronthosting.co.za>
Message-ID: <E1QFN56-0003Rw-SD@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 57c076ab4bbd by ?ukasz Langa in branch '3.2':
Closes #11858: configparser.ExtendedInterpolation and section case.
http://hg.python.org/cpython/rev/57c076ab4bbd

----------
nosy: +python-dev
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11858>
_______________________________________

From report at bugs.python.org  Thu Apr 28 11:01:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Apr 2011 09:01:29 +0000
Subject: [issue11858] configparser.ExtendedInterpolation and section case
In-Reply-To: <1302972514.64.0.403074363027.issue11858@psf.upfronthosting.co.za>
Message-ID: <E1QFN6F-0003Vq-Rh@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 2afaef6cda8a by ?ukasz Langa in branch 'default':
Merged solution for #11858 from 3.2.
http://hg.python.org/cpython/rev/2afaef6cda8a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11858>
_______________________________________

From report at bugs.python.org  Thu Apr 28 11:03:14 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 28 Apr 2011 09:03:14 +0000
Subject: [issue11858] configparser.ExtendedInterpolation and section case
In-Reply-To: <1302972514.64.0.403074363027.issue11858@psf.upfronthosting.co.za>
Message-ID: <1303981394.5.0.555970315775.issue11858@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Pink, please give your name so I can include you in Misc/ACKS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11858>
_______________________________________

From report at bugs.python.org  Thu Apr 28 11:22:43 2011
From: report at bugs.python.org (Jeong-Min Lee)
Date: Thu, 28 Apr 2011 09:22:43 +0000
Subject: [issue11944] Function call with * and generator hide exception raised
	by generator.
In-Reply-To: <1303952447.32.0.22528411021.issue11944@psf.upfronthosting.co.za>
Message-ID: <1303982563.47.0.41022129712.issue11944@psf.upfronthosting.co.za>


Jeong-Min Lee <falsetru at gmail.com> added the comment:

Some exceptions are reported correctly.


>>> def g():
...     1 / 0
...     yield 1, 2
...     yield 3, 4
... 
>>> zip(*g())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in g
ZeroDivisionError: integer division or modulo by zero



>>> def g():
...     [][0]
...     yield 1, 2
...     yield 3, 4
... 
>>> zip(*g())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in g
IndexError: list index out of range

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11944>
_______________________________________

From report at bugs.python.org  Thu Apr 28 12:03:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Apr 2011 10:03:14 +0000
Subject: [issue11670] configparser read_file now iterates over f,
	docs still say it calls readline
In-Reply-To: <1301047699.5.0.476245530251.issue11670@psf.upfronthosting.co.za>
Message-ID: <E1QFO40-0008JA-9x@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 1bbda00bbe78 by ?ukasz Langa in branch '3.2':
Style updates for the #11670 solution after post-commit review by Ezio Melotti:
http://hg.python.org/cpython/rev/1bbda00bbe78

New changeset 339cd1d9b21a by ?ukasz Langa in branch 'default':
Merged styling updates for #11670 from 3.2.
http://hg.python.org/cpython/rev/339cd1d9b21a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11670>
_______________________________________

From report at bugs.python.org  Thu Apr 28 13:00:52 2011
From: report at bugs.python.org (Pink)
Date: Thu, 28 Apr 2011 11:00:52 +0000
Subject: [issue11858] configparser.ExtendedInterpolation and section case
In-Reply-To: <1303981394.5.0.555970315775.issue11858@psf.upfronthosting.co.za>
Message-ID: <BANLkTinLZQqJUu_jivyRsO_R4=nMTBDEQg@mail.gmail.com>


Pink <ciasoms at gmail.com> added the comment:

Oh, all right :)
My name is Yuxiao Zeng.

2011/4/28 ?ukasz Langa <report at bugs.python.org>:
>
> ?ukasz Langa <lukasz at langa.pl> added the comment:
>
> Pink, please give your name so I can include you in Misc/ACKS.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue11858>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11858>
_______________________________________

From report at bugs.python.org  Thu Apr 28 13:08:56 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 28 Apr 2011 11:08:56 +0000
Subject: [issue11945] Adopt and document consistent semantics for handling NaN
	values in containers
In-Reply-To: <1303962145.0.0.00759154980454.issue11945@psf.upfronthosting.co.za>
Message-ID: <1303988936.53.0.474583064801.issue11945@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11945>
_______________________________________

From report at bugs.python.org  Thu Apr 28 13:13:20 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 28 Apr 2011 11:13:20 +0000
Subject: [issue11332] Increase logging/__init__.py coverage to 97%
In-Reply-To: <1298719084.44.0.947118780186.issue11332@psf.upfronthosting.co.za>
Message-ID: <1303989200.77.0.153062119518.issue11332@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Though I did not use this patch verbatim, thank you, Oliver, for the impetus to improve coverage. Now, coverage of the logging package is:

logging/__init__.py 99% (97%)
logging/config.py 89% (85%)
logging/handlers.py 65% (60%)

where the brackets include branch coverage measurements. Not too shabby, so I'll close this issue now: I think future coverage increases will need to focus on the handlers.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11332>
_______________________________________

From report at bugs.python.org  Thu Apr 28 13:50:20 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 28 Apr 2011 11:50:20 +0000
Subject: [issue11862] urlparse.ParseResult to have meaningful __str__
In-Reply-To: <1303064594.29.0.64850729087.issue11862@psf.upfronthosting.co.za>
Message-ID: <1303991420.68.0.876049216084.issue11862@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

?ric, ParseResult is a class which provides tuple for urlparse/unparse. People should hardly (/never) use ParseResult directly. The original poster's concern was to get something like geturl() from this class which  was not suitable and it should be obtained by other meaningful methods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11862>
_______________________________________

From report at bugs.python.org  Thu Apr 28 13:56:09 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 28 Apr 2011 11:56:09 +0000
Subject: [issue9035] os.path.ismount on windows doesn't support windows
	mount	points
In-Reply-To: <1277023751.91.0.438330382261.issue9035@psf.upfronthosting.co.za>
Message-ID: <1303991769.17.0.584826776457.issue9035@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Sijin, please go ahead and submit a patch. No one is working on this at the moment.

----------
nosy: +markm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9035>
_______________________________________

From report at bugs.python.org  Thu Apr 28 14:36:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Apr 2011 12:36:51 +0000
Subject: [issue11926] help("keywords") returns incomplete list of keywords
In-Reply-To: <1303782960.65.0.80653815306.issue11926@psf.upfronthosting.co.za>
Message-ID: <1303994211.68.0.479328685778.issue11926@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Out of curiosity: Any reason you used a containment test with a list instead of a set (IMO more idiomatic, and in 3.2+ also optimized)?  I guess it?s to match the rest of the file, but using sets would not change any behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11926>
_______________________________________

From report at bugs.python.org  Thu Apr 28 14:41:57 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 28 Apr 2011 12:41:57 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1303994517.2.0.958985091868.issue11457@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11457>
_______________________________________

From report at bugs.python.org  Thu Apr 28 14:44:20 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 28 Apr 2011 12:44:20 +0000
Subject: [issue11926] help("keywords") returns incomplete list of keywords
In-Reply-To: <1303782960.65.0.80653815306.issue11926@psf.upfronthosting.co.za>
Message-ID: <1303994660.16.0.812247131256.issue11926@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Good question. I considered using sets but then decided to use lists because they don't get rid of duplicates and would make the test fail in the (indeed unlikely) case that a keyword gets added twice (that's actually not possible in Test.keywords because it's a dict, but keyword.kwlist is a list and the implementation of either one could change at some point).
In any case it probably doesn't make much difference -- I just preferred to err on the safe side.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11926>
_______________________________________

From report at bugs.python.org  Thu Apr 28 14:52:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Apr 2011 12:52:46 +0000
Subject: [issue11926] help("keywords") returns incomplete list of keywords
In-Reply-To: <1303782960.65.0.80653815306.issue11926@psf.upfronthosting.co.za>
Message-ID: <1303995166.2.0.664713677325.issue11926@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I was too vague.  I referred only to ?if something in ['True', 'False', 'None']? in pydoc.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11926>
_______________________________________

From report at bugs.python.org  Thu Apr 28 14:59:14 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 28 Apr 2011 12:59:14 +0000
Subject: [issue11943] Add TLS-SRP (RFC 5054) support to ssl, _ssl, http,
	and urllib
In-Reply-To: <1303943331.28.0.343800117154.issue11943@psf.upfronthosting.co.za>
Message-ID: <1303995554.86.0.77884183694.issue11943@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11943>
_______________________________________

From report at bugs.python.org  Thu Apr 28 15:07:29 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 28 Apr 2011 13:07:29 +0000
Subject: [issue11943] Add TLS-SRP (RFC 5054) support to ssl, _ssl, http,
	and urllib
In-Reply-To: <1303943331.28.0.343800117154.issue11943@psf.upfronthosting.co.za>
Message-ID: <1303996049.46.0.924101998221.issue11943@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11943>
_______________________________________

From report at bugs.python.org  Thu Apr 28 15:16:17 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Thu, 28 Apr 2011 13:16:17 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>


New submission from Jason Vas Dias <jason.vas.dias at gmail.com>:

After building from source in Python-2.7.1.tar.bz2 ,
I get this 'make test' failure :

test_commands
test test_commands failed -- Traceback (most recent call last): 
  File "/usr/src/Python-2.7/Lib/test/test_commands.py", line 61, in test_getstatus
    self.assertTrue(re.match(pat, commands.getstatus("/."),re.VERBOSE)) 
AssertionError: None is not True

I don't get this error when building from Python-2.7.tar.bz2

----------
components: Tests
messages: 134674
nosy: Jason.Vas.Dias
priority: normal
severity: normal
status: open
title: 2.7.1 'test_commands' build test fails
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Thu Apr 28 15:20:40 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 28 Apr 2011 13:20:40 +0000
Subject: [issue11943] Add TLS-SRP (RFC 5054) support to ssl, _ssl, http,
	and urllib
In-Reply-To: <1303943331.28.0.343800117154.issue11943@psf.upfronthosting.co.za>
Message-ID: <1303996840.42.0.890759677905.issue11943@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

The idea seems interesting. I will check the RFC ASAP. The patch should include documentation updates, though. You can update the issue number in the NEWS file, also.

Do you plan to complete the sections marked as "TODO"? 

PS: The mercurial repository URL you are linking has an unnedeed username, and firefox complains about it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11943>
_______________________________________

From report at bugs.python.org  Thu Apr 28 15:23:22 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 28 Apr 2011 13:23:22 +0000
Subject: [issue11943] Add TLS-SRP (RFC 5054) support to ssl, _ssl, http,
	and urllib
In-Reply-To: <1303943331.28.0.343800117154.issue11943@psf.upfronthosting.co.za>
Message-ID: <1303997002.2.0.506823816434.issue11943@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Also, I will not invest too much time on this until OpenSSL 1.0.1 is released, with support for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11943>
_______________________________________

From report at bugs.python.org  Thu Apr 28 16:02:48 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Apr 2011 14:02:48 +0000
Subject: [issue11858] configparser.ExtendedInterpolation and section case
In-Reply-To: <1302972514.64.0.403074363027.issue11858@psf.upfronthosting.co.za>
Message-ID: <E1QFRnk-0004Vy-9G@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 17b4378689e6 by ?ukasz Langa in branch '3.2':
Added Yuxiao Zeng for finding and resolving #11858. Thanks!
http://hg.python.org/cpython/rev/17b4378689e6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11858>
_______________________________________

From report at bugs.python.org  Thu Apr 28 16:29:29 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 28 Apr 2011 14:29:29 +0000
Subject: [issue10419] distutils command build_scripts fails with
	UnicodeDecodeError
In-Reply-To: <1289766753.91.0.865805184241.issue10419@psf.upfronthosting.co.za>
Message-ID: <1304000969.15.0.836171915027.issue10419@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Alternatively it's possible to use binary mode. I'm attaching the patch, which shows this possibility.

----------
title: distutils command build_scripts fails with	UnicodeDecodeError -> distutils command build_scripts fails with UnicodeDecodeError
Added file: http://bugs.python.org/file21821/build_scripts-binary_mode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10419>
_______________________________________

From report at bugs.python.org  Thu Apr 28 16:34:22 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 28 Apr 2011 14:34:22 +0000
Subject: [issue11941] Support st_atim,
	st_mtim and st_ctim attributes in os.stat_result
In-Reply-To: <1303938022.85.0.623572797729.issue11941@psf.upfronthosting.co.za>
Message-ID: <1304001262.31.0.765964370256.issue11941@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Actually issue #11941 should be a dependency of issue #11457. Issue #11941 is only about os.stat(), while issue #11457 proposes changes also in other places (e.g. tarfile module).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11941>
_______________________________________

From report at bugs.python.org  Thu Apr 28 16:39:16 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 28 Apr 2011 14:39:16 +0000
Subject: [issue11397] os.path.realpath() may produce incorrect results
In-Reply-To: <1299259038.05.0.675723191983.issue11397@psf.upfronthosting.co.za>
Message-ID: <1304001556.24.0.221052451978.issue11397@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


Removed file: http://bugs.python.org/file21820/issue11397_py32_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11397>
_______________________________________

From report at bugs.python.org  Thu Apr 28 16:39:31 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 28 Apr 2011 14:39:31 +0000
Subject: [issue11397] os.path.realpath() may produce incorrect results
In-Reply-To: <1299259038.05.0.675723191983.issue11397@psf.upfronthosting.co.za>
Message-ID: <1304001571.33.0.760255952514.issue11397@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


Added file: http://bugs.python.org/file21822/issue11397_py32_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11397>
_______________________________________

From report at bugs.python.org  Thu Apr 28 16:49:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Apr 2011 14:49:00 +0000
Subject: [issue10419] distutils command build_scripts fails with
	UnicodeDecodeError
In-Reply-To: <1289766753.91.0.865805184241.issue10419@psf.upfronthosting.co.za>
Message-ID: <1304002140.38.0.691646703885.issue10419@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Was the patch tested in 2.7 only?  I think the first_line_re needs to be changed to bytes too.  (3.x would have disallowed mixing bytes and str for a regex.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10419>
_______________________________________

From report at bugs.python.org  Thu Apr 28 16:52:43 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 28 Apr 2011 14:52:43 +0000
Subject: [issue10419] distutils command build_scripts fails with
	UnicodeDecodeError
In-Reply-To: <1289766753.91.0.865805184241.issue10419@psf.upfronthosting.co.za>
Message-ID: <1304002363.6.0.812622190025.issue10419@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Which patch do you mean?
(My patch already changes first_line_re to bytes. My patch was tested only with 3.2. Lib/distutils/command/build_scripts.py is currently identical in 3.1, 3.2 and 3.3.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10419>
_______________________________________

From report at bugs.python.org  Thu Apr 28 17:04:45 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Apr 2011 15:04:45 +0000
Subject: [issue11324] ConfigParser(interpolation=None) doesn't work
In-Reply-To: <1298666228.44.0.489583826736.issue11324@psf.upfronthosting.co.za>
Message-ID: <E1QFSll-00020k-NG@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 32031e33d793 by ?ukasz Langa in branch '3.2':
Closes #11324: ConfigParser(interpolation=None) doesn't work.
http://hg.python.org/cpython/rev/32031e33d793

New changeset de7dc59260b1 by ?ukasz Langa in branch 'default':
Merged solution for #11324 from 3.2.
http://hg.python.org/cpython/rev/de7dc59260b1

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11324>
_______________________________________

From report at bugs.python.org  Thu Apr 28 17:07:31 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Thu, 28 Apr 2011 15:07:31 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304003251.31.0.511148649851.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

Oops, bash <TAB> completion was a bit over-eager, and I inadvertently
built /usr/src/Python-2.7 instead  of /usr/src/Python-2.7.1 .

Nevertheless, when I finally do build Python-2.7.1, I get the same 
error :

test_commands                                                                                                                                               
test test_commands failed -- Traceback (most recent call last):                                                                                             
  File "/usr/src/Python-2.7.1/Lib/test/test_commands.py", line 61, in test_getstatus                                                                        
    self.assertTrue(re.match(pat, commands.getstatus("/."), re.VERBOSE))                                                                                    
AssertionError: None is not True                                                                                                                            


I guess if python-2.7 cannot run command I'd know about it, and
it has the same bug.

I guess you ship a broken 'test_commands' test script for Python-2.7
AND Python-2.7.1 .

This does not increase my already meager confidence in Python's 
robustness and reliability.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Thu Apr 28 17:13:03 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 28 Apr 2011 15:13:03 +0000
Subject: [issue11397] os.path.realpath() may produce incorrect results
In-Reply-To: <1299259038.05.0.675723191983.issue11397@psf.upfronthosting.co.za>
Message-ID: <1304003583.19.0.405754735929.issue11397@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


Added file: http://bugs.python.org/file21823/issue11397_py27_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11397>
_______________________________________

From report at bugs.python.org  Thu Apr 28 17:13:15 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 28 Apr 2011 15:13:15 +0000
Subject: [issue11397] os.path.realpath() may produce incorrect results
In-Reply-To: <1299259038.05.0.675723191983.issue11397@psf.upfronthosting.co.za>
Message-ID: <1304003595.92.0.184927209177.issue11397@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


Added file: http://bugs.python.org/file21824/issue11397_py31_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11397>
_______________________________________

From report at bugs.python.org  Thu Apr 28 17:25:27 2011
From: report at bugs.python.org (Quinn Slack)
Date: Thu, 28 Apr 2011 15:25:27 +0000
Subject: [issue11943] Add TLS-SRP (RFC 5054) support to ssl, _ssl, http,
	and urllib
In-Reply-To: <1303943331.28.0.343800117154.issue11943@psf.upfronthosting.co.za>
Message-ID: <1304004327.13.0.753446818702.issue11943@psf.upfronthosting.co.za>


Quinn Slack <sqs at cs.stanford.edu> added the comment:

Thanks for checking this out. Yes, this should wait for OpenSSL 1.0.1.

I will fix the TODO. It is there because the current TLS-SRP patch to OpenSSL uses old (pre-RFC 5054) TLS alert values for when the SRP username isn't in the Client Hello. I'm preparing another patch to OpenSSL to fix these, and then I'll update this patch.

I'll also include docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11943>
_______________________________________

From report at bugs.python.org  Thu Apr 28 17:41:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Apr 2011 15:41:26 +0000
Subject: [issue11786] ConfigParser.[Raw]ConfigParser optionxform()
In-Reply-To: <1302110277.82.0.57770456199.issue11786@psf.upfronthosting.co.za>
Message-ID: <E1QFTLI-0005Ml-JM@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c7ce67c9237a by ?ukasz Langa in branch '2.6':
Closes #11786: ConfigParser.[Raw]ConfigParser optionxform().
http://hg.python.org/cpython/rev/c7ce67c9237a

New changeset a6b772599594 by ?ukasz Langa in branch '2.7':
Merged solution for #11786 from 2.6
http://hg.python.org/cpython/rev/a6b772599594

----------
nosy: +python-dev
resolution: accepted -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11786>
_______________________________________

From report at bugs.python.org  Thu Apr 28 17:42:31 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 28 Apr 2011 15:42:31 +0000
Subject: [issue11786] ConfigParser.[Raw]ConfigParser optionxform()
In-Reply-To: <1302110277.82.0.57770456199.issue11786@psf.upfronthosting.co.za>
Message-ID: <1304005351.26.0.205216999756.issue11786@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11786>
_______________________________________

From report at bugs.python.org  Thu Apr 28 17:55:17 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Apr 2011 15:55:17 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304006117.6.0.964294351753.issue11946@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

We don't ship unless all tests pass on all of our test platforms (and we have quite a few).  If you look at that test it says the regex "should match 'ls -ld /.' on any posix system, however perversely configured".  Perhaps your system has managed a new brand of perversity :)

Seriously, though, it looks like the test is broken in the face of some edge case present on your system and not on any of our test machines.  Can you provide the output of 'ls -ld /.' from your system please?  And also your OS and filesystem types and versions.

----------
nosy: +r.david.murray
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Thu Apr 28 17:56:50 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Thu, 28 Apr 2011 15:56:50 +0000
Subject: [issue11620] winsound.PlaySound() with SND_MEMORY should accept bytes
	instead of strings
In-Reply-To: <1300667681.04.0.269037633009.issue11620@psf.upfronthosting.co.za>
Message-ID: <1304006210.77.0.0778862026008.issue11620@psf.upfronthosting.co.za>


Changes by Sijin Joseph <sijinjoseph at gmail.com>:


----------
nosy: +sijinjoseph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11620>
_______________________________________

From report at bugs.python.org  Thu Apr 28 18:00:55 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Thu, 28 Apr 2011 16:00:55 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304006455.69.0.77382531571.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

$ uname -a
Linux jvdspc 2.6.38.2-jvd #1 SMP Sun Apr 3 00:55:29 BST 2011 x86_64 GNU/Linux
$ ls -ld /
drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /
$ ls --version
ls (GNU coreutils) 8.10
...
$ eval {gcc,g++,cpp,ld,as,ar,ranlib,objdump,objcopy,make,bash,ldconfig}' --version;' | egrep '[(]G|bash'
gcc (GCC) 4.6.0
g++ (GCC) 4.6.0
cpp (GCC) 4.6.0
GNU ld (GNU Binutils) 2.21.51.20110407
GNU assembler (GNU Binutils) 2.21.51.20110407
GNU ar (GNU Binutils) 2.21.51.20110407
GNU ranlib (GNU Binutils) 2.21.51.20110407
GNU objdump (GNU Binutils) 2.21.51.20110407
GNU objcopy (GNU Binutils) 2.21.51.20110407
GNU bash, version 4.2.8(2)-release (x86_64-pc-linux-gnu)
ldconfig (GNU libc) 2.13

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Thu Apr 28 18:08:55 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Thu, 28 Apr 2011 16:08:55 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304006935.41.0.578620216664.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

$ ldd /usr/bin/python
        linux-vdso.so.1 =>  (0x00007fff1edff000)
        libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 (0x00007f16aa8c0000)
        libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x00007f16aa6a3000)
        libdl.so.2 => /usr/lib64/libdl.so.2 (0x00007f16aa49f000)
        libutil.so.1 => /lib64/libutil.so.1 (0x00007f16aa29c000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f16aa01a000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f16a9c92000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f16aac90000)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Thu Apr 28 18:11:04 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Thu, 28 Apr 2011 16:11:04 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304007064.26.0.760717403989.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

$ ls -ld /.
drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /.

(oops, forgot the '.' suffix before)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Thu Apr 28 18:14:16 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Apr 2011 16:14:16 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304007256.04.0.85215380491.issue11946@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The re matches for me if I call it manually with your ls -ld output.

What output do you get if you do a 'print commands.getstatus("/.")' using your build of the python interpreter?

By the way, this is a deprecated function under test here, so I'm setting this bug to low priority.  But I'm certainly curious as to what the problem is.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Thu Apr 28 18:15:00 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 28 Apr 2011 16:15:00 +0000
Subject: [issue11941] Support st_atim,
	st_mtim and st_ctim attributes in os.stat_result
In-Reply-To: <1303938022.85.0.623572797729.issue11941@psf.upfronthosting.co.za>
Message-ID: <1304007300.33.0.194957477417.issue11941@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Ok, that's true, reopening.

----------
resolution: duplicate -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11941>
_______________________________________

From report at bugs.python.org  Thu Apr 28 18:15:34 2011
From: report at bugs.python.org (Marc Sibson)
Date: Thu, 28 Apr 2011 16:15:34 +0000
Subject: [issue7517] freeze.py not ported to python3
In-Reply-To: <1260903379.83.0.360315644527.issue7517@psf.upfronthosting.co.za>
Message-ID: <1304007334.8.0.393731746232.issue7517@psf.upfronthosting.co.za>


Marc Sibson <sibson at gmail.com> added the comment:

I think the original issue has been fixed by http://hg.python.org/cpython/rev/fd20eba1f201. 

freeze.py is now broken due to pep3149 and ABIFLAGS, freeze-pep3149-compat.patch adds awareness of ABIFLAGS to Tools/freeze/freeze.py.

For me "python3.3 freeze.py hello.py && make && ./hello" now works.

----------
keywords: +patch
nosy: +marcs
Added file: http://bugs.python.org/file21825/freeze-pep3149-compat.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7517>
_______________________________________

From report at bugs.python.org  Thu Apr 28 18:15:49 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 28 Apr 2011 16:15:49 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1304007349.56.0.254609890992.issue11457@psf.upfronthosting.co.za>


Changes by Ross Lagerwall <rosslagerwall at gmail.com>:


----------
dependencies: +Support st_atim, st_mtim and st_ctim attributes in os.stat_result

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11457>
_______________________________________

From report at bugs.python.org  Thu Apr 28 18:18:58 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Thu, 28 Apr 2011 16:18:58 +0000
Subject: [issue7517] freeze.py not ported to python3
In-Reply-To: <1260903379.83.0.360315644527.issue7517@psf.upfronthosting.co.za>
Message-ID: <1304007538.67.0.165804929054.issue7517@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

Note that I also opened issue #11824 for the abiflags problem.

----------
nosy: +Trundle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7517>
_______________________________________

From report at bugs.python.org  Thu Apr 28 18:25:58 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Thu, 28 Apr 2011 16:25:58 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304007958.22.0.685699454512.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

Seeing the source , I see some complicated RE - should this test
maybe be better off in the RE testing module ?

I'd have used a simple RE like '^.*(\/.*)$' .

Might my newly built & installed pcre-8.02 be a suspect here ?

Here is an strace of the installed python  2.7 (not 2.7.1!)
failing with test_commands.py :

$ strace -s8192 -f -e trace=execve python /usr/src/Python-2.7.1/Lib/test/test_commands.py
execve("/usr/bin/python", ["python", "/usr/src/Python-2.7.1/Lib/test/test_commands.py"], [/* 23 vars */]) = 0
test_getoutput (__main__.CommandTests) ... syscall_293(0x7fffa0d6a400, 0x80000, 0x7f4029a834dd, 0x7fffa0d6a200, 0x7f4029abf700, 0x100, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0                                                                                                                    
Process 30803 attached                                                                                                                                                
[pid 30803] execve("/bin/sh", ["sh", "-c", "{ echo xyzzy; } 2>&1"], [/* 23 vars */]) = 0                                                                              
Process 30803 detached                                                                                                                                                
--- SIGCHLD (Child exited) @ 0 (0) ---                                                                                                                                
syscall_293(0x7fffa0d6a550, 0x80000, 0x7f4029a834dd, 0, 0x7f4029abf700, 0x100, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0      
Process 30804 attached                                                                                                                                                
[pid 30804] execve("/bin/sh", ["sh", "-c", "{ echo xyzzy; } 2>&1"], [/* 23 vars */]) = 0                                                                              
Process 30804 detached                                                                                                                                                
--- SIGCHLD (Child exited) @ 0 (0) ---                                                                                                                                
syscall_293(0x7fffa0d6a550, 0x80000, 0x7f4029a834dd, 0, 0x7f4029abf700, 0x100, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0      
Process 30805 attached                                                                                                                                                
[pid 30805] execve("/bin/sh", ["sh", "-c", "{ cat /tmp/tmpZ2sqbO/foo; } 2>&1"], [/* 23 vars */]) = 0                                                                  
Process 30806 attached                                                                                                                                                
[pid 30806] execve("/bin/cat", ["cat", "/tmp/tmpZ2sqbO/foo"], [/* 21 vars */]) = 0                                                                                    
Process 30805 suspended                                                                                                                                               
Process 30805 resumed                                                                                                                                                 
Process 30806 detached
[pid 30805] --- SIGCHLD (Child exited) @ 0 (0) ---
Process 30805 detached
--- SIGCHLD (Child exited) @ 0 (0) ---
ok
test_getstatus (__main__.CommandTests) ... syscall_293(0x7fffa0d6a2b0, 0x80000, 0x7f4029a834dd, 0, 0x7f4029abf700, 0x100, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0
Process 30807 attached
[pid 30807] execve("/bin/sh", ["sh", "-c", "{ ls -ld \'/.\'; } 2>&1"], [/* 23 vars */]) = 0
Process 30808 attached
Process 30807 suspended
[pid 30808] execve("/bin/ls", ["ls", "-ld", "/."], [/* 21 vars */]) = 0
Process 30807 resumed
Process 30808 detached
[pid 30807] --- SIGCHLD (Child exited) @ 0 (0) ---
Process 30807 detached
--- SIGCHLD (Child exited) @ 0 (0) ---
FAIL

======================================================================
FAIL: test_getstatus (__main__.CommandTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/Python-2.7.1/Lib/test/test_commands.py", line 61, in test_getstatus
    self.assertTrue(re.match(pat, commands.getstatus("/."), re.VERBOSE))
AssertionError: None is not True

----------------------------------------------------------------------
Ran 2 tests in 0.202s

FAILED (failures=1)
Traceback (most recent call last):
  File "/usr/src/Python-2.7.1/Lib/test/test_commands.py", line 70, in <module>
    test_main()
  File "/usr/src/Python-2.7.1/Lib/test/test_commands.py", line 65, in test_main
    run_unittest(CommandTests)
  File "/usr/lib/python2.7/test/test_support.py", line 1055, in run_unittest
    _run_suite(suite)
  File "/usr/lib/python2.7/test/test_support.py", line 1038, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "/usr/src/Python-2.7.1/Lib/test/test_commands.py", line 61, in test_getstatus
    self.assertTrue(re.match(pat, commands.getstatus("/."), re.VERBOSE))
AssertionError: None is not True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Thu Apr 28 18:29:40 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Thu, 28 Apr 2011 16:29:40 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304008180.36.0.82319625112.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

Hmm.. investigating that "syscall_293..." stuff - I did 
  $ cd /usr/src/linux; make headers_install
and then built glibc-2.13 with the new header OK, but
strace is rather old . I'll rebuild strace ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Thu Apr 28 18:32:26 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Thu, 28 Apr 2011 16:32:26 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304008346.07.5.77823966524e-05.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

$ python
Python 2.7 (r27:82500, Jul  4 2010, 23:30:10)
[GCC 4.4.2 20090927 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import re
>>> import sys
>>> import commands
>>> print commands.getstatus("/.")
drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /.
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Thu Apr 28 18:52:02 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Thu, 28 Apr 2011 16:52:02 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304009522.72.0.47333313683.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

new strace 4.6 of newly built python 2.7.1 failing test_commands.py

$ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython2.7.so.1.0 strace -s8192 -f -e trace=execve ./python /usr/src/Python-2.7.1/Lib/test/test_commands.py
execve("./python", ["./python", "/usr/src/Python-2.7.1/Lib/test/test_commands.py"], [/* 25 vars */]) = 0                                              
test_getoutput (__main__.CommandTests) ... Process 1327 attached                                                                                      
[pid  1327] execve("/bin/sh", ["sh", "-c", "{ echo xyzzy; } 2>&1"], [/* 25 vars */]) = 0                                                              
Process 1327 detached                                                                                                                                 
--- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1327, si_status=0, si_utime=0, si_stime=1} (Child exited) ---                                       
Process 1328 attached                                                                                                                                 
[pid  1328] execve("/bin/sh", ["sh", "-c", "{ echo xyzzy; } 2>&1"], [/* 25 vars */]) = 0                                                              
Process 1328 detached                                                                                                                                 
--- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1328, si_status=0, si_utime=0, si_stime=1} (Child exited) ---                                       
Process 1329 attached                                                                                                                                 
[pid  1329] execve("/bin/sh", ["sh", "-c", "{ cat /tmp/tmp2EkRJK/foo; } 2>&1"], [/* 25 vars */]) = 0                                                  
Process 1330 attached                                                                                                                                 
Process 1329 suspended                                                                                                                                
[pid  1330] execve("/bin/cat", ["cat", "/tmp/tmp2EkRJK/foo"], [/* 23 vars */]) = 0
Process 1329 resumed
Process 1330 detached
[pid  1329] --- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1330, si_status=1, si_utime=0, si_stime=0} (Child exited) ---
Process 1329 detached
--- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1329, si_status=1, si_utime=0, si_stime=1} (Child exited) ---
ok
test_getstatus (__main__.CommandTests) ... Process 1338 attached
[pid  1338] execve("/bin/sh", ["sh", "-c", "{ ls -ld '/.'; } 2>&1"], [/* 25 vars */]) = 0
Process 1339 attached
Process 1338 suspended
[pid  1339] execve("/bin/ls", ["ls", "-ld", "/."], [/* 23 vars */]) = 0
Process 1338 resumed
Process 1339 detached
[pid  1338] --- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1339, si_status=0, si_utime=0, si_stime=0} (Child exited) ---
Process 1338 detached
--- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1338, si_status=0, si_utime=0, si_stime=1} (Child exited) ---
FAIL

======================================================================
FAIL: test_getstatus (__main__.CommandTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/Python-2.7.1/Lib/test/test_commands.py", line 61, in test_getstatus
    self.assertTrue(re.match(pat, commands.getstatus("/."), re.VERBOSE))
AssertionError: None is not True

----------------------------------------------------------------------
Ran 2 tests in 0.289s

FAILED (failures=1)
Traceback (most recent call last):
  File "/usr/src/Python-2.7.1/Lib/test/test_commands.py", line 70, in <module>
    test_main()
  File "/usr/src/Python-2.7.1/Lib/test/test_commands.py", line 65, in test_main
    run_unittest(CommandTests)
  File "/usr/src/Python-2.7.1/Lib/test/test_support.py", line 1087, in run_unittest
    _run_suite(suite)
  File "/usr/src/Python-2.7.1/Lib/test/test_support.py", line 1070, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "/usr/src/Python-2.7.1/Lib/test/test_commands.py", line 61, in test_getstatus
    self.assertTrue(re.match(pat, commands.getstatus("/."), re.VERBOSE))
AssertionError: None is not True

So, now with strace-4.6, that syscall_293* is shown to be an old strace anomaly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Thu Apr 28 18:54:15 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Thu, 28 Apr 2011 16:54:15 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304009655.79.0.238494464387.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

Newly built python 2.7.1 commands.getstatus succeeds :

$ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython2.7.so.1.0 ./python
Python 2.7.1 (r271:86832, Apr 28 2011, 15:53:47)
[GCC 4.6.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import re
>>> import sys
>>> import commands
>>> print commands.getstatus("/.")
drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /.
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Thu Apr 28 18:57:42 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Apr 2011 16:57:42 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304009862.16.0.800652069865.issue11946@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  This is very odd.  The output from getstatus is the same as your ls output, and that output passes the re.  Python has its own regular expression implementation, so your pcre version shouldn't have anything to do with it.

That complicated re, by the way, is trying to confirm that what comes back from getstatus is something that looks like the output of ls, so no, it can't really be simplified and still be testing getstatus.

It looks like something weird is going on inside the test machinery.  Are you willing to do a little Python hacking?  If I were seeing this error on my box I'd split up that assert statement.  Get the value of the getstatus call, print it out.  Then pass the output to the re, and print the result (which should be None, given that the test is failing).  If the getstatus output looks right at that point, then something very odd indeed is going on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Thu Apr 28 19:02:56 2011
From: report at bugs.python.org (Robert Meerman)
Date: Thu, 28 Apr 2011 17:02:56 +0000
Subject: [issue11947] re.IGNORECASE does not match literal "_" (underscore)
In-Reply-To: <1304010176.69.0.487843608928.issue11947@psf.upfronthosting.co.za>
Message-ID: <1304010176.69.0.487843608928.issue11947@psf.upfronthosting.co.za>


New submission from Robert Meerman <robert.meerman at gmail.com>:

Regular expressions which are written match literal underscores ("_", ASCII 
ordinal 95) and specify `re.IGNORECASE` during compilation do not consistently 
match underscores: it seems some occurrences are matched, but others are not.

The following session log shows the problem:

    Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) 
    [GCC 4.4.3] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import re
    >>> subject = "[Conclave-Mendoi]_ef_-_a_tale_of_memories_00-12_H264"
    >>> print subject.encode("base64")  # Incase my environment encoding is to blame
    W0NvbmNsYXZlLU1lbmRvaV1fZWZfLV9hX3RhbGVfb2ZfbWVtb3JpZXNfMDAtMTJfSDI2NA==

    >>> re.sub("_", "X", subject)  # No flags, does what I expect
    '[Conclave-Mendoi]XefX-XaXtaleXofXmemoriesX00-12XH264'
    >>> 
    >>> re.sub("_", "X", subject, re.IGNORECASE)  # Misses some matches
    '[Conclave-Mendoi]XefX-_a_tale_of_memories_00-12_H264'
    >>> 
    >>> re.sub("_", "X", subject, re.IGNORECASE | re.LOCALE)  # Misses fewer matches
    '[Conclave-Mendoi]XefX-XaXtaleXofXmemories_00-12_H264'
    >>> 
    >>> re.sub("_", "X", subject, re.IGNORECASE | re.LOCALE | re.UNICODE)  # Works OK
    '[Conclave-Mendoi]XefX-XaXtaleXofXmemoriesX00-12XH264'
    >>> 
    >>> re.sub("_", "X", subject, re.IGNORECASE | re.UNICODE) # Works OK
    '[Conclave-Mendoi]XefX-XaXtaleXofXmemoriesX00-12XH264'
    >>> 
    >>> type(subject)  # Don't think this is a unicode string
    <type 'str'>
    >>> 

Since my `subject` variable is of type `str` and only contains ASCII characters
I do not believe that the `re.UNICODE` flag should be required.

----------
components: Regular Expressions
messages: 134700
nosy: RobM, effbot, ezio.melotti, pitrou
priority: normal
severity: normal
status: open
title: re.IGNORECASE does not match literal "_" (underscore)
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11947>
_______________________________________

From report at bugs.python.org  Thu Apr 28 19:04:10 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Apr 2011 17:04:10 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304010250.22.0.199025414558.issue11946@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You are running selinux, right?  Have you checked for things in the log that might indicate selinux is blocking the ls call for some reason?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Thu Apr 28 19:04:55 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Thu, 28 Apr 2011 17:04:55 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304010295.12.0.714790591277.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

Aha ! Fixed ! : patch :

[ root at jvdspc:/mnt/sda3/Python-2.7 18:02:22 1685:1178 ]
$ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython2.7.so.1.0 ./python /tmp/test_commands.py
test_getoutput (__main__.CommandTests) ... ok
test_getstatus (__main__.CommandTests) ... ok

----------------------------------------------------------------------
Ran 2 tests in 0.068s

OK
[ root at jvdspc:/mnt/sda3/Python-2.7 18:03:34 1686:1179 ]
$ diff -U0 /usr/src/Python-2.7/Lib/test/test_commands.py /tmp/test_commands.py
--- /usr/src/Python-2.7/Lib/test/test_commands.py       2010-03-31 23:01:03.000000000 +0100
+++ /tmp/test_commands.py       2011-04-28 18:03:27.821395320 +0100
@@ -27,2 +27,2 @@
-        self.assertEquals(commands.getoutput('echo xyzzy'), 'xyzzy')
-        self.assertEquals(commands.getstatusoutput('echo xyzzy'), (0, 'xyzzy'))
+        self.assertEqual(commands.getoutput('echo xyzzy'), 'xyzzy')
+        self.assertEqual(commands.getstatusoutput('echo xyzzy'), (0, 'xyzzy'))
@@ -39 +39 @@
-            self.assertNotEquals(status, 0)
+            self.assertNotEqual(status, 0)
@@ -52,5 +52 @@
-        pat = r'''d.........   # It is a directory.
-                  \+?          # It may have ACLs.
-                  \s+\d+       # It has some number of links.
-                  [^/]*        # Skip user, group, size, and date.
-                  /\.          # and end with the name of the file.
+        pat = r'''^.*(\/\.)[\ ]*[\n\r]*$

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Thu Apr 28 19:07:49 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Thu, 28 Apr 2011 17:07:49 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304010469.3.0.0423389153761.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

oops, over-eager bash <tab> again - 
I've certainly had one too many bash <tab>s today :-)
Here's the patch against 2.7.1's test_commands.py, not 2.7's :


[ root at jvdspc:/mnt/sda3/Python-2.7 18:04:15 1687:1180 ]
$ diff -U0 /usr/src/Python-2.7.1/Lib/test/test_commands.py /tmp/test_commands.py
--- /usr/src/Python-2.7.1/Lib/test/test_commands.py     2010-11-21 13:34:58.000000000 +0000
+++ /tmp/test_commands.py       2011-04-28 18:03:27.821395320 +0100
@@ -52,5 +52 @@
-        pat = r'''d.........   # It is a directory.
-                  \+?          # It may have ACLs.
-                  \s+\d+       # It has some number of links.
-                  [^/]*        # Skip user, group, size, and date.
-                  /\.          # and end with the name of the file.
+        pat = r'''^.*(\/\.)[\ ]*[\n\r]*$
[ root at jvdspc:/mnt/sda3/Python-2.7 18:05:52 1688:1181 ]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Thu Apr 28 19:18:31 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 28 Apr 2011 17:18:31 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Following up http://mail.python.org/pipermail/docs/2011-April/004029.html here's a small patch (applicable on all the active branches) to "actually" :) connects the two paragraphs about modules search path.

----------
assignee: docs at python
components: Documentation
files: tutorial_modules_actually.patch
keywords: patch
messages: 134704
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Tutorial/Modules - small fix to better clarify the modules search path
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21826/tutorial_modules_actually.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Thu Apr 28 19:19:58 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Thu, 28 Apr 2011 17:19:58 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304011198.16.0.599650593965.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

Not sure if relevant, but ls is appending a ' ' (0x20 == space) after
the filename :

$ ls -ld -d /. | od -x
0000000 7264 7877 2d72 7278 782d 202e 3532 7220
0000020 6f6f 2074 6f72 746f 3420 3930 2036 7041
0000040 2072 3032 3120 3a35 3832 2f20 0a2e
0000056

See the ending "200a2e" - maybe there should not be an 0x20 there .
Should I raise a GNU coreutils 8.10 bug about this ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Thu Apr 28 19:24:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Apr 2011 17:24:54 +0000
Subject: [issue11811] ssl.get_server_certificate() does not work for IPv6
	addresses
In-Reply-To: <1302383900.51.0.808943452569.issue11811@psf.upfronthosting.co.za>
Message-ID: <E1QFUxR-0005xa-2J@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0518f32cb747 by Antoine Pitrou in branch 'default':
Issue #11811: Factor out detection of IPv6 support on the current host
http://hg.python.org/cpython/rev/0518f32cb747

New changeset d3166c359714 by Antoine Pitrou in branch 'default':
Issue #11811: ssl.get_server_certificate() is now IPv6-compatible.  Patch
http://hg.python.org/cpython/rev/d3166c359714

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11811>
_______________________________________

From report at bugs.python.org  Thu Apr 28 19:26:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Apr 2011 17:26:51 +0000
Subject: [issue11811] ssl.get_server_certificate() does not work for IPv6
	addresses
In-Reply-To: <1302383900.51.0.808943452569.issue11811@psf.upfronthosting.co.za>
Message-ID: <1304011611.03.0.762021596281.issue11811@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed, thank you!

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11811>
_______________________________________

From report at bugs.python.org  Thu Apr 28 19:38:39 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Thu, 28 Apr 2011 17:38:39 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304012319.38.0.702104493442.issue11946@psf.upfronthosting.co.za>


Changes by Jason Vas Dias <jason.vas.dias at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file21827/bug_11946.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Thu Apr 28 19:46:03 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Thu, 28 Apr 2011 17:46:03 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304012763.93.0.390542770229.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

Wow, GNU have respun two major releases of coreutils since I built
coreutils-2.10 two weeks ago !

Now moving to latest version of coreutils : 8.12 and retesting .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Thu Apr 28 20:16:54 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Thu, 28 Apr 2011 18:16:54 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304014614.55.0.337635312705.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

$ ls -dl /. | od -x
0000000 7264 7877 2d72 7278 782d 202e 3532 7220
0000020 6f6f 2074 6f72 746f 3420 3930 2036 7041
0000040 2072 3032 3120 3a35 3832 2f20 0a2e
0000056
[ root at jvdspc:/tmp 19:15:01 1730:1223 ]
$ ls --version
ls (GNU coreutils) 8.12


Either GNU coreutils 8.12 's ls is wrong to append a ' ', or 
test_commands.py is wrong not to be expecting it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Thu Apr 28 20:41:11 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Apr 2011 18:41:11 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304016071.45.0.356153236399.issue11946@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I would say that coreutils is wrong to be appending a space.  If a program were to parse the output of ls, it would reasonably expect the filename to be rendered exactly as it appears in the directory.  That is, a program should treat a trailing space as *part* of the filename, which it clearly isn't in this case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Thu Apr 28 20:50:07 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Apr 2011 18:50:07 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304016607.05.0.150258985952.issue11946@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

By the way, I wouldn't expect most programs to ever notice that trailing space parsing -l output, but if it also attaches the trailing space in regular ls output, *that* I would expect more programs would trip over.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Thu Apr 28 20:52:54 2011
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 28 Apr 2011 18:52:54 +0000
Subject: [issue11944] Function call with * and generator hide exception raised
	by generator.
In-Reply-To: <1303952447.32.0.22528411021.issue11944@psf.upfronthosting.co.za>
Message-ID: <1304016774.14.0.489220852308.issue11944@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

This may be the same/similar as issue4806 (which has a patch).

----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11944>
_______________________________________

From report at bugs.python.org  Thu Apr 28 21:08:59 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 28 Apr 2011 19:08:59 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Rationale:

"""
IEEE 754 assigns values to all relational expressions involving NaN.
In the syntax of C, the predicate x != y is True but all others, x <
y , x <= y , x == y , x >= y and x > y, are False whenever x or y or
both are NaN, and then all but x != y and x == y are INVALID
operations too and must so signal.
"""
-- Lecture Notes on the Status of IEEE Standard 754 for Binary
Floating-Point Arithmetic by Prof. W. Kahan
http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps

The problem with faithfully implementing IEEE 754 in Python is that
exceptions in IEEE standard don't have the same meaning as in Python.
 IEEE 754 requires that a value is computed even when the operation
signals an exception.  The program can then decide whether to
terminate computation or propagate the value. In Python, we have to
choose between raising an exception and returning the value.  We
cannot have both.  It appears that in most cases IEEE 754 "INVALID"
exception is treated as a terminating exception by Python and
operations that signal INVALID in IEEE 754 raise an exception in
Python.  Therefore making <, >, etc. raise on NaN while keeping the
status quo for != and == would bring Python floats closer to
compliance with IEEE 754.

See http://mail.python.org/pipermail/python-ideas/2011-April/010057.html for discussion.

An instructive part of the patch is

--- a/Lib/test/test_math.py
+++ b/Lib/test/test_math.py
@@ -174,10 +174,22 @@
                    flags
                   )
 
+def is_negative_zero(x):
+    return x == 0 and math.copysign(1, x) < 0
+
+def almost_equal(value, expected):
+    if math.isfinite(expected) and math.isfinite(value):
+        return abs(value-expected) <= eps
+    if math.isnan(expected):
+        return math.isnan(value)
+    if is_negative_zero(expected):
+        return is_negative_zero(value)
+    return value == expected
+
 class MathTests(unittest.TestCase):
 
     def ftest(self, name, value, expected):
-        if abs(value-expected) > eps:
+        if not almost_equal(value, expected):


Although it may look like proposed change makes it harder to compare floats for approximate equality, the change actually helped to highlight a programming mistake: old ftest() accepts 0.0 where -0.0 is expected.

This is a typical situation when someone attempts to write clever code relying on unusual properties of NaNs. In most cases clever code does not account for all possibilities and it is always hard reason about such code.

----------
components: Interpreter Core
files: unorderable-nans.diff
keywords: patch
messages: 134713
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Make float('nan') unorderable
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file21828/unorderable-nans.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________

From report at bugs.python.org  Thu Apr 28 21:14:58 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 28 Apr 2011 19:14:58 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1304018098.49.0.774960666535.issue11949@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file21829/unorderable-nans.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________

From report at bugs.python.org  Thu Apr 28 21:15:22 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 28 Apr 2011 19:15:22 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1304018122.11.0.955960227547.issue11949@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file21828/unorderable-nans.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________

From report at bugs.python.org  Thu Apr 28 21:29:19 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Thu, 28 Apr 2011 19:29:19 +0000
Subject: [issue11950] logger use dict for loggers instead of
	WeakValueDictionary
In-Reply-To: <1304018959.77.0.656415451022.issue11950@psf.upfronthosting.co.za>
Message-ID: <1304018959.77.0.656415451022.issue11950@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

logger use dict for loggers instead of WeakValueDictionary

Now, when object returned by getLogger() gets unreferenced - it will not be garbage collected, as reference is stored in logging module. This will results in leaked file object, that cannot be closed in easy way. Some modules (notable yum) opens dozen of loggers that prevents me to unmount directory where logs placed. Now, I use workaround:

-----------------------
try:
    # work with yum
finally:
    yum_base_cli.close()
    yum_base_cli.closeRpmDB()
    yum_base_cli.doUnlock()
    del yum_base_cli
    # gc.collect() may be called here, but it does not actually change anything....
    for logger_name,logger in cli.logging.Logger.manager.loggerDict.iteritems():
        if not logger_name.startswith('yum'):
            continue
        for h in logger.handlers:
            h.flush()
            h.close()
-----------------------
The problem in that logging module stores many references in lists and dicts. So just replacing {} with WeakValueDictionary() 
does not eliminate problem fully.

I have checked, problem exists in all python versions

----------
components: Library (Lib)
messages: 134714
nosy: mmarkk
priority: normal
severity: normal
status: open
title: logger use dict for loggers instead of WeakValueDictionary
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11950>
_______________________________________

From report at bugs.python.org  Thu Apr 28 21:30:32 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 28 Apr 2011 19:30:32 +0000
Subject: [issue11945] Adopt and document consistent semantics for handling NaN
	values in containers
In-Reply-To: <1303962145.0.0.00759154980454.issue11945@psf.upfronthosting.co.za>
Message-ID: <1304019032.11.0.216492727708.issue11945@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

To repeat concisely what I said on pydev list, I think Reference 5.9. Comparisons, which says

"Tuples and lists are compared lexicographically using comparison of corresponding elements. This means that to compare equal, each element must compare equal and the two sequences must be of the same type and have the same length.".

needs 'be indentical or ' added before 'compare equal and ...'

"Mappings (dictionaries) compare equal if and only if they have the same (key, value) pairs."

may be ok, depending on how one interprets 'same (key, value) pairs'.

Alexander has opened a separate issue to change behavior in 3.3.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11945>
_______________________________________

From report at bugs.python.org  Thu Apr 28 21:33:26 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 28 Apr 2011 19:33:26 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1304019206.48.0.719743438859.issue4296@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Thu Apr 28 21:54:49 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 28 Apr 2011 19:54:49 +0000
Subject: [issue11947] re.IGNORECASE does not match literal "_" (underscore)
In-Reply-To: <1304010176.69.0.487843608928.issue11947@psf.upfronthosting.co.za>
Message-ID: <1304020489.31.0.398676069702.issue11947@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

help(re.sub) says:

    sub(pattern, repl, string, count=0)

and re.IGNORECASE has a value of 2.

Therefore this:

    re.sub("_", "X", subject, re.IGNORECASE)

is telling it to replace at most 2 occurrences of "_".

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11947>
_______________________________________

From report at bugs.python.org  Thu Apr 28 22:49:19 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 28 Apr 2011 20:49:19 +0000
Subject: [issue11947] re.IGNORECASE does not match literal "_" (underscore)
In-Reply-To: <1304010176.69.0.487843608928.issue11947@psf.upfronthosting.co.za>
Message-ID: <1304023759.83.0.359386071579.issue11947@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Closing as invalid.
I wonder if it would be better to have count as a keyword-only argument though, since this problem seems to come up pretty often and it's not easy to debug.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11947>
_______________________________________

From report at bugs.python.org  Thu Apr 28 23:00:59 2011
From: report at bugs.python.org (Brian Buckley)
Date: Thu, 28 Apr 2011 21:00:59 +0000
Subject: [issue11951] Mac OSX IDLE 3.2 does not allow entering text into
	toolbar windows (such as the help search box) unless all shells
	are closed or minimized
Message-ID: <1304024459.77.0.476340315499.issue11951@psf.upfronthosting.co.za>


Changes by Brian Buckley <bbuckley at gmail.com>:


----------
components: IDLE
nosy: Brian.Buckley
priority: normal
severity: normal
status: open
title: Mac OSX IDLE 3.2 does not allow entering text into toolbar windows (such as the help search box) unless all shells are closed or minimized
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11951>
_______________________________________

From report at bugs.python.org  Thu Apr 28 23:07:27 2011
From: report at bugs.python.org (Brian Buckley)
Date: Thu, 28 Apr 2011 21:07:27 +0000
Subject: [issue11951] Mac OSX IDLE 3.2 does not allow entering text into
	toolbar windows (such as the help search box) unless all shells
	are closed or minimized
In-Reply-To: <1304024847.78.0.114369305609.issue11951@psf.upfronthosting.co.za>
Message-ID: <1304024847.78.0.114369305609.issue11951@psf.upfronthosting.co.za>


New submission from Brian Buckley <bbuckley at gmail.com>:

text enters directly to the window closest to the front rather than to the selected text box.

----------
Added file: http://bugs.python.org/file21830/Screen shot 2011-04-28 at 5.07.07 PM.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11951>
_______________________________________

From report at bugs.python.org  Thu Apr 28 23:16:28 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Thu, 28 Apr 2011 21:16:28 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304025388.97.0.505381711735.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

Oops, Paul is right here - I asked bug-coreutils at gnu.org, and Paul
responds:
<quote>
Re: bug#8578: 8.12 and 8.10 'ls -dl' appends ' ' (0x20: space) to file  output lines
From:  Paul Eggert <eggert at cs.ucla.edu>  (UCLA Computer Science Department)
  To: jason.vas.dias at gmail.com
  CC: 8578 at debbugs.gnu.org
Date: 2011-04-28 20:34
   
On 04/28/11 11:34, Jason Vas Dias wrote:

> $ ls -dl /. | od -cx
> ...
> 0000040   r       2   0       1   5   :   2   8       /   .  \n
>            2072    3032    3120    3a35    3832    2f20    0a2e
> 0000056
> 
> Please could the ls developer let me know if it 100% POSIXLY correct
> that ls appends 0x20 to the filename '/.'  here ?

I don't see any space appended there.  The last four bytes of
output are 0x20, 0x2f, 0x2e, 0x0a (space, /, ., newline).
Perhaps you're misunderstanding the little-endian nature of
od -x output?
</quote>

Yes, of course, when 'od' says ' 2f20    0a2e' it means it received:
  0x20 0x2f 0x2e 0x0a
sorry - I'm just trying to understand why your original RE fails -
it isn't because of the spaces !

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Thu Apr 28 23:35:33 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Thu, 28 Apr 2011 21:35:33 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304026533.65.0.95597255108.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

I imagine lots of other python REs fail if this one is failing ? :

$ cat test.py

import os
import sys
import re

pat = r'''d.........   # It is a directory.
          \+?          # It may have ACLs.
          \s+\d+       # It has some number of links.
          [^/]*        # Skip user, group, size, and date.
          /\.          # and end with the name of the file.
       '''
str = 'drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /.'
if re.match(pat, str, re.VERBOSE) :
   print "MATCHED\n"
else :
   print "DID NOT MATCH"

$ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython2.7.so.1.0 ./python ./test.py
DID NOT MATCH

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Thu Apr 28 23:50:54 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 28 Apr 2011 21:50:54 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1304027454.41.0.522319540243.issue11948@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

It would be better to drop the introductory phrase entirely.

----------
nosy: +rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Thu Apr 28 23:51:06 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 28 Apr 2011 21:51:06 +0000
Subject: [issue11926] help("keywords") returns incomplete list of keywords
In-Reply-To: <1303782960.65.0.80653815306.issue11926@psf.upfronthosting.co.za>
Message-ID: <1304027466.51.0.969377617505.issue11926@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

That's just because I'm used to Python 2 where the {} syntax for sets was not available.  I'll try to keep that in mind for the next time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11926>
_______________________________________

From report at bugs.python.org  Fri Apr 29 00:21:59 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 28 Apr 2011 22:21:59 +0000
Subject: [issue11947] re.IGNORECASE does not match literal "_" (underscore)
In-Reply-To: <1304010176.69.0.487843608928.issue11947@psf.upfronthosting.co.za>
Message-ID: <1304029319.35.0.20753612806.issue11947@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I don't know how much code that might break. It might not be that much; I can't remember when I last used re.sub without the default count.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11947>
_______________________________________

From report at bugs.python.org  Fri Apr 29 00:27:48 2011
From: report at bugs.python.org (akira)
Date: Thu, 28 Apr 2011 22:27:48 +0000
Subject: [issue11952] typo in multiprocessing documentation: __main__ method
	should be replaced by __main__ module
In-Reply-To: <1304029668.08.0.895041183069.issue11952@psf.upfronthosting.co.za>
Message-ID: <1304029668.08.0.895041183069.issue11952@psf.upfronthosting.co.za>


New submission from akira <4kir4.1i at gmail.com>:

s/method/module/:

    Functionality within this package requires that the ``__main__`` method be
    importable by the children.

----------
assignee: docs at python
components: Documentation
messages: 134724
nosy: akira, docs at python
priority: normal
severity: normal
status: open
title: typo in multiprocessing documentation: __main__ method should be replaced by __main__ module
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11952>
_______________________________________

From report at bugs.python.org  Fri Apr 29 00:38:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Apr 2011 22:38:50 +0000
Subject: [issue11953] Missing WSA* error codes
In-Reply-To: <1304030330.14.0.209711289978.issue11953@psf.upfronthosting.co.za>
Message-ID: <1304030330.14.0.209711289978.issue11953@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Apparently not all Windows socket error codes (see http://msdn.microsoft.com/en-us/library/ms740668%28v=vs.85%29.aspx) are mapped in the errno module.

For example, a buildbot recently got a 11004 error (see http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/3001/steps/test/logs/stdio), which is:

?WSANO_DATA
11004

Valid name, no data record of requested type.

    The requested name is valid and was found in the database, but it does not have the correct associated data being resolved for. The usual example for this is a host name-to-address translation attempt (using gethostbyname or WSAAsyncGetHostByName) which uses the DNS (Domain Name Server). An MX record is returned but no A record?indicating the host itself exists, but is not directly reachable.?


Not sure how this should be handled.

----------
messages: 134725
nosy: amaury.forgeotdarc, loewis, pitrou
priority: low
severity: normal
status: open
title: Missing WSA* error codes
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11953>
_______________________________________

From report at bugs.python.org  Fri Apr 29 00:39:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Apr 2011 22:39:24 +0000
Subject: [issue11953] Missing WSA* error codes
In-Reply-To: <1304030330.14.0.209711289978.issue11953@psf.upfronthosting.co.za>
Message-ID: <1304030364.45.0.867949956112.issue11953@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brian.curtin, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11953>
_______________________________________

From report at bugs.python.org  Fri Apr 29 00:45:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Apr 2011 22:45:31 +0000
Subject: [issue11832] Add option to pause regrtest to attach a debugger
In-Reply-To: <1302578628.99.0.388714550632.issue11832@psf.upfronthosting.co.za>
Message-ID: <E1QFZxe-0006wS-NL@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3d9800fcce7f by Brian Curtin in branch 'default':
Implement #11832. Add an option to start regrtest and wait for input
http://hg.python.org/cpython/rev/3d9800fcce7f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11832>
_______________________________________

From report at bugs.python.org  Fri Apr 29 00:46:43 2011
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 28 Apr 2011 22:46:43 +0000
Subject: [issue11832] Add option to pause regrtest to attach a debugger
In-Reply-To: <1302578628.99.0.388714550632.issue11832@psf.upfronthosting.co.za>
Message-ID: <1304030803.11.0.18264789238.issue11832@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11832>
_______________________________________

From report at bugs.python.org  Fri Apr 29 00:47:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Apr 2011 22:47:32 +0000
Subject: [issue11953] Missing WSA* error codes
In-Reply-To: <1304030330.14.0.209711289978.issue11953@psf.upfronthosting.co.za>
Message-ID: <1304030852.62.0.74465833639.issue11953@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, it was raised by getaddrinfo(), so should perhaps belong in the socket module instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11953>
_______________________________________

From report at bugs.python.org  Fri Apr 29 00:48:29 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Thu, 28 Apr 2011 22:48:29 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304030909.8.0.0296885125825.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

When I see messages like this in the "make test" log it makes me
want to remove python and all python using software from my system :

test_dl
test test_dl crashed -- <type 'exceptions.SystemError'>: module dl requires sizeof(int) == sizeof(long) == sizeof(char*)

NO, GEE, THAT'S RIGHT ! 

      ( sizeof( int ) == 4 ) == ( ( sizeof(long) == 8) == 
                                  (sizeof(void*) == 8 )
                                )

which actually makes sense in "C" on my system, and produces
a true value, ( 1 ) == ( ( 1 ) == ( 1 ) )
when gcc is run with the $CFLAGS given to the python build,
unlike the message's pseudo-code.

So I think some internal python components think they are getting
compiled in 32-bit mode, on a native 64-bit compiler - how ? 
Is anything in the python build appending any '-m32' flag ? 
Because my environment certainly does not contain '-m32' :

$ export -p | egrep 'CC|CXX|FLAG'
declare -x CC="/usr/bin/gcc"
declare -x CFLAGS="-march=x86-64 -mtune=k8 -O2 -g -fPIC -DPIC -pipe"
declare -x CXX="/usr/bin/g++"
declare -x CXXFLAGS="-march=x86-64 -mtune=k8 -O2 -g -fPIC -DPIC -pipe"


`uname -m` says 'x86_64' - a 64-bit arch . And the dl* objects 
are actually 64-bit:
$ find . -name 'dl*' -exec file '{}' ';'
./Modules/dlmodule.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
./build/temp.linux-x86_64-2.7/usr/src/Python-2.7.1/Modules/_ctypes/libffi/src/dlmalloc.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

So why this message :

test_dl
test test_dl crashed -- <type 'exceptions.SystemError'>: module dl requires sizeof(int) == sizeof(long) == sizeof(char*)

hmm, time to get out gdb I guess .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Fri Apr 29 01:18:10 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 28 Apr 2011 23:18:10 +0000
Subject: [issue11945] Adopt and document consistent semantics for handling NaN
	values in containers
In-Reply-To: <1303962145.0.0.00759154980454.issue11945@psf.upfronthosting.co.za>
Message-ID: <1304032690.64.0.27210825566.issue11945@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

After further discussion on python-dev, it is clear that this identity checking behaviour handles more than just NaNs - it also allows containers to cope more gracefully with objects like NumPy arrays that make use of rich comparisons to return something other than simple True/False values for equality checks.

Also, since I neglected to mention it in the initial post, merely *adding* the glossary entry is just the first step. It then needs to be referenced from the appropriate points in the language and library reference.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11945>
_______________________________________

From report at bugs.python.org  Fri Apr 29 01:28:44 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 28 Apr 2011 23:28:44 +0000
Subject: [issue11945] Adopt and document consistent semantics for handling NaN
	values in containers
In-Reply-To: <1303962145.0.0.00759154980454.issue11945@psf.upfronthosting.co.za>
Message-ID: <1304033324.0.0.686826699611.issue11945@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Scratch the first half of that last comment - Guido pointed out that false positives rear their ugly head almost immediately if you try to store rich comparison objects in other containers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11945>
_______________________________________

From report at bugs.python.org  Fri Apr 29 01:37:00 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 28 Apr 2011 23:37:00 +0000
Subject: [issue11951] Mac OSX IDLE 3.2 does not allow entering text into
	toolbar windows (such as the help search box) unless all shells
	are closed or minimized
In-Reply-To: <1304024847.78.0.114369305609.issue11951@psf.upfronthosting.co.za>
Message-ID: <1304033820.23.0.668222691635.issue11951@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for the report: yet another Aqua Tk oddity.  This one is a problem in Tk itself. It can be seen using a recent Wish 8.4 with a simple Tcl script to create a help menu.  The relevant Tk bug is here:

http://sourceforge.net/tracker/index.php?func=detail&aid=1884667&group_id=12997&atid=112997

For the record, I can reproduce the problem when using a Tkinter linked with current ActiveState Tcl/Tk 8.4.19 on either OS X 10.5 or 10.6 or with the Apple Tcl/Tk 8.4 on OS X 10.6.  All of those are Tk 8.4.19.  The problem does not appear when using the Apple-supplied Tcl/Tk 8.4 (8.4.7) on OS X 10.5.  It also does not appear when using Tkinter linked with Aqua Tk 8.5 (as is the case with the 3.2 64-bit/32-bit python.org installer).  Unfortunately, there is nothing Tkinter or IDLE can do to work around this.

----------
assignee:  -> ned.deily
nosy: +ned.deily
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: feature request -> behavior
versions: +Python 2.7, Python 3.1, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11951>
_______________________________________

From report at bugs.python.org  Fri Apr 29 01:44:12 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 28 Apr 2011 23:44:12 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1304034252.98.0.883023969041.issue11949@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Actually, my first attempt to fix the test was faulty.  The correct logic seems to be

+def is_negative_zero(x):
+    return x == 0 and math.copysign(1, x) < 0
+
+def almost_equal(value, expected):
+    if math.isfinite(expected) and math.isfinite(value):
+        if is_negative_zero(expected):
+            return is_negative_zero(value)
+        if is_negative_zero(value):
+            return is_negative_zero(expected)
+        return abs(value-expected) <= eps
+    if math.isnan(expected):
+        return math.isnan(value)
+    return value == expected
+
 class MathTests(unittest.TestCase):
+    
+    def test_xxx(self):
+        self.assertTrue(is_negative_zero(-0.0))
+        self.assertFalse(almost_equal(0.0, -0.0))
 
     def ftest(self, name, value, expected):
-        if abs(value-expected) > eps:
+        if not almost_equal(value, expected):

Now, the attached patch has two failures:

AssertionError: fmod(-10,1) returned -0.0, expected 0

and 

AssertionError: sqrt0002:sqrt(-0.0) returned -0.0, expected 0.0

The first seems to be a typo in the test, but I would not expect sqrt(-0.0) to return -0.0.  Does anyone know what the relevant standard says?

----------
Added file: http://bugs.python.org/file21831/unorderable-nans.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________

From report at bugs.python.org  Fri Apr 29 02:11:51 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 29 Apr 2011 00:11:51 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1304035911.49.0.659390427863.issue11949@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file21829/unorderable-nans.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________

From report at bugs.python.org  Fri Apr 29 03:19:01 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Fri, 29 Apr 2011 01:19:01 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1304039941.03.0.26072785725.issue11949@psf.upfronthosting.co.za>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

The C standard (and/or the POSIX one, I forget) says sqrt(-0.0) returns -0.0.

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________

From report at bugs.python.org  Fri Apr 29 03:32:39 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 Apr 2011 01:32:39 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304040759.31.0.674066486762.issue11946@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Oh, drat.  We could have figured this out much sooner if I'd been paying closer attention.  I was testing based on current 2.7 tip instead of 2.7.1, and indeed this test bug was only recently (April 4th!) fixed.  And the issue is indeed selinux; the fix was to the regex to take into account the selinux extra attributes.  My apologies for dragging you through unnecessary debugging :(

As for the other issue, please open a new ticket.  (The pseudo-code, by the way, is saying that all three sizes must be the same.)

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> test_commands.py failing on OS X 10.5.7 due to '@' in ls output

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Fri Apr 29 06:13:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Apr 2011 04:13:24 +0000
Subject: [issue11952] typo in multiprocessing documentation: __main__ method
	should be replaced by __main__ module
In-Reply-To: <1304029668.08.0.895041183069.issue11952@psf.upfronthosting.co.za>
Message-ID: <E1QFf50-00026c-LV@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ef9bccfe64de by Ezio Melotti in branch '2.7':
#11952: Fix typo in multiprocessing doc.
http://hg.python.org/cpython/rev/ef9bccfe64de

New changeset 1d3c5df88589 by Ezio Melotti in branch '3.1':
#11952: Fix typo in multiprocessing doc.
http://hg.python.org/cpython/rev/1d3c5df88589

New changeset 56c187b81d2b by Ezio Melotti in branch '3.2':
#11952: merge with 3.1.
http://hg.python.org/cpython/rev/56c187b81d2b

New changeset 8eb794bbb967 by Ezio Melotti in branch 'default':
#11952: merge with 3.2.
http://hg.python.org/cpython/rev/8eb794bbb967

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11952>
_______________________________________

From report at bugs.python.org  Fri Apr 29 06:14:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 29 Apr 2011 04:14:36 +0000
Subject: [issue11952] typo in multiprocessing documentation: __main__ method
	should be replaced by __main__ module
In-Reply-To: <1304029668.08.0.895041183069.issue11952@psf.upfronthosting.co.za>
Message-ID: <1304050476.37.0.687175833539.issue11952@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11952>
_______________________________________

From report at bugs.python.org  Fri Apr 29 10:59:42 2011
From: report at bugs.python.org (blokeley)
Date: Fri, 29 Apr 2011 08:59:42 +0000
Subject: [issue11344] Add os.path.splitpath(path) function
In-Reply-To: <1298795208.87.0.771920756626.issue11344@psf.upfronthosting.co.za>
Message-ID: <1304067582.61.0.184647295489.issue11344@psf.upfronthosting.co.za>


blokeley <blokeley at gmail.com> added the comment:

The unit tests on the cpython tip revision fail even before applying my patches and I'm afraid haven't got the time to debug the threading module or existing unit tests.

The traceback is:

C:\workspace\cpython\Lib\test> C:\Python32\python.exe test_ntpath.py

Traceback (most recent call last):
  File "test_ntpath.py", line 4, in <module>
    from test.support import TestFailed
  File "C:\workspace\cpython\Lib\test\support.py", line 14, in <module>
    import shutil
  File "C:\workspace\cpython\Lib\shutil.py", line 17, in <module>
    import bz2
  File "C:\workspace\cpython\Lib\bz2.py", line 13, in <module>
    import threading
  File "C:\workspace\cpython\Lib\threading.py", line 34, in <module>
    _info = _thread.info
AttributeError: 'module' object has no attribute 'info'


It happens with cpython hg rev 8eb794bbb967

If there's a quick fix for this, please advise and I'll get working. 

If not, I'll probably not have the time to fix it myself and then write the os.path.splitpath patches as well which would be a pity.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11344>
_______________________________________

From report at bugs.python.org  Fri Apr 29 11:06:45 2011
From: report at bugs.python.org (ysj.ray)
Date: Fri, 29 Apr 2011 09:06:45 +0000
Subject: [issue11874] argparse assertion failure with brackets in metavars
In-Reply-To: <1303201252.58.0.236363581255.issue11874@psf.upfronthosting.co.za>
Message-ID: <1304068005.75.0.644940112365.issue11874@psf.upfronthosting.co.za>


ysj.ray <ysj.ray at gmail.com> added the comment:

Seem as a problem in optparse.HelpFormatter._format_usage(): when the generated usage string is too long(longer than 78, e.g.), python tries to break the usage string into parts at some proper positions and group them to multiple lines, then join the parts with space and assert it equal with original usage string. The regular expression used to break the usage string into parts is:
    """r'\(.*?\)+|\[.*?\]+|\S+'"""
So when there is '[]' in usage string, like in the example(there is '[]' in metavar), the assertion fails.

metavar="[LIB,]FBNAME" seems quite reasonable and usable, in the case that one want to define an option who has tow values and the first is optional. So I suggest '[]' should be allowed in metavar, and the _format_usage() needs fixed.

Here is a patch that fixes by changing the way breaking the usage string to parts and remove joining the parts and assert it equal to original usage string. Now the usage string is broken into intact each action of group usage strings. I think this breaking granularity is enough.

----------
keywords: +patch
nosy: +ysj.ray
Added file: http://bugs.python.org/file21832/issue_11874.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11874>
_______________________________________

From report at bugs.python.org  Fri Apr 29 11:14:52 2011
From: report at bugs.python.org (ysj.ray)
Date: Fri, 29 Apr 2011 09:14:52 +0000
Subject: [issue11874] argparse assertion failure with brackets in metavars
In-Reply-To: <1303201252.58.0.236363581255.issue11874@psf.upfronthosting.co.za>
Message-ID: <1304068492.87.0.467339961326.issue11874@psf.upfronthosting.co.za>


Changes by ysj.ray <ysj.ray at gmail.com>:


----------
components: +Library (Lib) -None

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11874>
_______________________________________

From report at bugs.python.org  Fri Apr 29 12:12:04 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 10:12:04 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304071924.8.0.242075841223.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

RE: msg134737 :
 > indeed this test bug was only recently (April 4th!) fixed.  
Please can you let me know how to get the patch / source / that fixes this ? The bug # of the original bug ? Should I be building from GIT ? Which GIT tag ? I'll try that next ...
 
> And the issue is indeed selinux; the fix was to the regex to take 
> into account the selinux extra attributes.  

selinux is disabled on my system, there were no SELinux attributes
in the string emitted by 'ls -dl' - and the python executable does
not link to libselinux - so you're saying that, in this code :
        pat = r'''d.........   # It is a directory.
                  \+?          # It may have ACLs.
'\+?' is incorrectly requiring '+' ?
Surely this is a bug in the regexp code ?

Nope, I don't think it has anything to do with SELinux attributes -
when I remove the '\+?', the RE still fails :


$ cat test.py

import os
import sys
import re

pat = r'''d.........   # It is a directory.
          \s+\d+       # It has some number of links.
          [^/]*        # Skip user, group, size, and date.
          /\.          # and end with the name of the file.
       '''
str = 'drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /.'
if re.match(pat, str, re.VERBOSE) :
   print "MATCHED\n"
else :
   print "DID NOT MATCH"

$ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython2.7.so.1.0 ./python ./test.py
DID NOT MATCH

RE:
>  As for the other issue, please open a new ticket.  (The pseudo-code, 
>  by the way, is saying that all three sizes must be the same.)

This really frightens me - do you really believe that 
   "all three sizes must be the same" on an x86_64 ? :
test_dl
test test_dl crashed -- <type 'exceptions.SystemError'>: module dl requires sizeof(int) == sizeof(long) == sizeof(char*)

That your dynamic linking module should give the impression in its
test script that it thinks 'sizeof(int)' (==4) should be equal to
'sizeof(char*)' (==8) is rather disconcerting to say the least -
and terrifying if it actually acts on this fundamental misconception
in its code - the fact that it crashed suggests maybe this is the
case. I'll see what happens with this test for the new code build
and raise another issue if not fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Fri Apr 29 12:22:06 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 10:22:06 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304072526.46.0.0397510491235.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

Aha ! Yes, I see, it is the extra '.' - this test now works :


$ cat test.py

import os
import sys
import re

pat = r'''d.........   # It is a directory.
          [+.@]?
          \s+\d+       # It has some number of links.
          [^/]*        # Skip user, group, size, and date.
          /\.          # and end with the name of the file.
       '''
str = 'drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /.'
if re.match(pat, str, re.VERBOSE) :
   print "MATCHED\n"
else :
   print "DID NOT MATCH"

[ root at jvdspc:/mnt/sda3/Python-2.7 11:19:30 1758:1251 ]
$ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython2.7.so.1.0 ./python ./test.py
MATCHED


I still think that RE belongs in a 'test_re' script, not in the
'test_commands' script - this whole series of issues could have
been avoided if the programmer had refrained from "showing off"
their RE prowess for no purpose here and just used a simple RE
like '^.*/\.$' .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Fri Apr 29 12:23:55 2011
From: report at bugs.python.org (ysj.ray)
Date: Fri, 29 Apr 2011 10:23:55 +0000
Subject: [issue11206] test_readline unconditionally calls clear_history()
In-Reply-To: <1297592798.04.0.448231212835.issue11206@psf.upfronthosting.co.za>
Message-ID: <1304072635.25.0.115671231406.issue11206@psf.upfronthosting.co.za>


ysj.ray <ysj.ray at gmail.com> added the comment:

This seems has already been fixed in issue11496, should be closed.

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11206>
_______________________________________

From report at bugs.python.org  Fri Apr 29 12:35:01 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 10:35:01 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304073301.44.0.122454074735.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

In case you don't believe me, believe a "C" compiler :

$ echo -e '#include <stdio.h>\nint main(){ printf("%u %u\\n",sizeof(int),sizeof(void*));}' > si.c
$ gcc -o si si.c
$ ./si
4 8

Any code that assumes that "sizeof(int) == sizeof(char*)" on
an x86_64 is broken, and any test that emits messages to this
effect is profoundly disconcerting . I wish I didn't have to
support python on my system.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Fri Apr 29 12:53:38 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 10:53:38 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304074418.33.0.609870555562.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

Furthermore, look at your configure script output :

checking for int32_t... yes                                                                                                                                           
checking for int64_t... yes                                                                                                                                           
checking for ssize_t... yes                                                                                                                                           
checking size of int... 4                                                                                                                                             
checking size of long... 8                                                                                                                                            
checking size of void *... 8                                                                                                                                          
checking size of short... 2                                                                                                                                           
checking size of float... 4                                                                                                                                           
checking size of double... 8                                                                                                                                          
checking size of fpos_t... 16                                                                                                                                         
checking size of size_t... 8                                                                                                                                          
checking size of pid_t... 4                                                                                                                                           
checking for long long support... yes                                                                                                                                 
checking size of long long... 8       



So why does your test_dl script say "sizeof(int)==sizeof(char*)" ??

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Fri Apr 29 13:23:15 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 11:23:15 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304076195.42.0.379252605708.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

OK, the test failures reported for this bug now succeed with Python-3.3
from latest HG head . 
But Python-3.3 now has its own new test failures :



[149/354] test_import                                                                                                                                                 
test test_import failed -- Traceback (most recent call last):                                                                                                         
  File "/usr/src/cpython/Lib/test/test_import.py", line 545, in test_unwritable_directory                                                                             
    '__pycache__', '{}.{}.pyc'.format(TESTFN, self.tag))))                                                                                                            
AssertionError: True is not false                                                                                                                                     

Hmm, don't want a python that can't do 'import' .

So my choices are, in order to get a working modern python release  :

  o fix the broken dynamic loader in Python-2.7
  o fix the broken import mechanism in Python-3.3

Thanks !  



BTW, this error occurs because I don't have RPM :
[ 93/354] test_distutils
error: error creating temporary file ${prefix}/var/tmp/rpm-tmp.amzIxR: No such file or directory
error: Unable to open temp file.
error: error creating temporary file ${prefix}/var/tmp/rpm-tmp.nwKS2z: No such file or directory
error: Unable to open temp file.
test test_distutils failed -- multiple errors occurred; run in verbose mode for details

this is because I don't have RPM (or maybe an old broken RPM inst) -
I suggest this test should test for the existence and usability
of rpm before using rpm - and should skip itself if rpm not usable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Fri Apr 29 13:28:50 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 Apr 2011 11:28:50 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304076530.49.0.753246930213.issue11946@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

No, if you take a look at tip, the problem is that bit of re is not covering all cases, and should look like this:

  [.+@]?       # It may have special attributes.

I assumed the "." was selinux, but I don't actually know, as I don't see them on my system (I don't use selinux or, apparently, any other special attributes).

So, the reason the re is failing is the trailing '.' in the first token in your ls -ld result, whatever that comes from.  The fixed test re allows for the '.'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Fri Apr 29 13:32:06 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 Apr 2011 11:32:06 +0000
Subject: [issue11344] Add os.path.splitpath(path) function
In-Reply-To: <1298795208.87.0.771920756626.issue11344@psf.upfronthosting.co.za>
Message-ID: <1304076726.88.0.725890417606.issue11344@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Did you try a make distclean/configure/make?  _thread.info is a new attribute introduced by a relatively recent patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11344>
_______________________________________

From report at bugs.python.org  Fri Apr 29 13:36:30 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 Apr 2011 11:36:30 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304076990.88.0.569256964469.issue11946@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Sorry, didn't see that you'd figured it out in the midst of your other comments not relevant to this bug.

If the re were simpler it wouldn't actually be *testing* the function under test, and so would be a useless test.  (It would show that the function produced output, but not that the output was from the ls -ld command)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Fri Apr 29 13:38:08 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 29 Apr 2011 11:38:08 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304077088.74.0.564251150246.issue11946@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Jason, that the dl module requires sizeof(int) == sizeof(char *) does not mean that it (or we) thinks this to be true on every platform.  Rather, the module is written in a way that requires this equality, and rather than crashing it does this check beforehand.

As you may have noticed, the dl module is deprecated anyway in favor of ctypes, and removed in Python 3.x.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Fri Apr 29 13:53:33 2011
From: report at bugs.python.org (Robert Meerman)
Date: Fri, 29 Apr 2011 11:53:33 +0000
Subject: [issue11947] re.IGNORECASE does not match literal "_" (underscore)
In-Reply-To: <1304010176.69.0.487843608928.issue11947@psf.upfronthosting.co.za>
Message-ID: <1304078013.48.0.627686157933.issue11947@psf.upfronthosting.co.za>


Robert Meerman <robert.meerman at gmail.com> added the comment:

Oh, that's embarrassing. :-)

Could a type-check be used to alert the user to their mistake? I suppose that would require re.IGNORECASE (et al) to be of some new type (presumably sub-classed from Integer).

(Thanks for the quick response, and sorry to waste your time)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11947>
_______________________________________

From report at bugs.python.org  Fri Apr 29 14:01:18 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 12:01:18 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>


New submission from Jason Vas Dias <jason.vas.dias at gmail.com>:

I do :
$  hg clone http://hg.python.org/cpython
( my existing Python-2.7, following upgrade to glibc-2.13, started
  producing erroneous results - see gnome.org glib bug :
    https://bugzilla.gnome.org/show_bug.cgi?id=648863
  So I tried downloading and building Python-2.7.1 , whose build
  tests fail ( Issue #11946 ) , and was recommended to try building
  latest python from HG . So I try that :
)
$ mkdir /mnt/sda3/Python-2.7 ; cd /mnt/sda3/Python-2.7
$ cat configure.sh
$ cat configure.sh
/usr/src/cpython/configure \
 --prefix=/usr --libdir=/usr/lib64 --enable-shared --with-pic \
 --with-system-ffi \
 --with-system-expat \
 --with-signal-module \
 --with-dbmliborder=bdb:gdbm \
 --with-threads \
 --without-pymalloc \
 --host=x86_64-pc-linux-gnu \
 --build=x86_64-pc-linux-gnu \
 --target=x86_64-pc-linux-gnu \
 --with-libs='-ldb-4.5 -lgdbm' \
 CPPFLAGS='-I/usr/include/db4 -I/usr/include/gdbm' \
 CC="${CC}" \
 CFLAGS="${CFLAGS}" \
 CXX="${CXX}" \
 CXXFLAGS="${CXXFLAGS}"
$ export -p | egrep 'CC|CXX|FLAG|LD|PATH|ARCH|ABI'
declare -x ABI="64"
declare -x ARCH="x86_64"
declare -x CC="/usr/bin/gcc"
declare -x CFLAGS="-march=x86-64 -mtune=k8 -O2 -g -fPIC -DPIC -pipe"
declare -x CXX="/usr/bin/g++"
declare -x CXXFLAGS="-march=x86-64 -mtune=k8 -O2 -g -fPIC -DPIC -pipe"
declare -x LD="/usr/bin/ld"
declare -x OLDPWD="/usr/src/cpython"
declare -x PATH=".:/bin:/usr/bin:/sbin:/usr/sbin"
$ bash -xf ./configure.sh 
...
$ echo $?
0
$ make -j2 2>&1 | tee make.log
$ echo $?
0
$ make test 2>&1 | tee make.test.log
...
[ 16/354] test_argparse
test test_argparse failed -- multiple errors occurred; run in verbose mode for details
...
[146/354] test_httpservers
/usr/src/cpython/Lib/unittest/case.py:799: BytesWarning: str() on a bytes instance
  (i, item1, item2))
test test_httpservers failed -- multiple errors occurred; run in verbose mode for details
[147/354] test_imaplib
[148/354] test_imp
[149/354] test_import
test test_import failed -- Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_import.py", line 545, in test_unwritable_directory
    '__pycache__', '{}.{}.pyc'.format(TESTFN, self.tag))))
AssertionError: True is not false

[150/354] test_importhooks
[151/354] test_importlib
[152/354] test_index
..[200/354] test_os
test test_os failed -- Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_os.py", line 675, in test_exist_ok_existing_directory
    os.makedirs(path, mode=mode, exist_ok=True)
  File "/usr/src/cpython/Lib/os.py", line 152, in makedirs
    mkdir(name, mode)
OSError: [Errno 17] File exists: '@test_28453_tmp/dir1'

...
[237/354] test_pyexpat
Fatal Python error: Segmentation fault

Traceback (most recent call first):
  File "/usr/src/cpython/Lib/test/test_pyexpat.py", line 591 in test1
  File "/usr/src/cpython/Lib/unittest/case.py", line 391 in _executeTestPart
  File "/usr/src/cpython/Lib/unittest/case.py", line 446 in run
  File "/usr/src/cpython/Lib/unittest/case.py", line 498 in __call__
  File "/usr/src/cpython/Lib/unittest/suite.py", line 105 in run
  File "/usr/src/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/src/cpython/Lib/unittest/suite.py", line 105 in run
  File "/usr/src/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/src/cpython/Lib/test/support.py", line 1094 in run
  File "/usr/src/cpython/Lib/test/support.py", line 1182 in _run_suite
  File "/usr/src/cpython/Lib/test/support.py", line 1208 in run_unittest
  File "/usr/src/cpython/Lib/test/test_pyexpat.py", line 676 in test_main
  File "/usr/src/cpython/Lib/test/regrtest.py", line 1044 in runtest_inner
  File "/usr/src/cpython/Lib/test/regrtest.py", line 838 in runtest
  File "/usr/src/cpython/Lib/test/regrtest.py", line 662 in main
  File "/usr/src/cpython/Lib/test/regrtest.py", line 1622 in <module>
make: *** [test] Segmentation fault
...

Any suggestions for a python source HG commit or tarball that will
pass its 'make test' on a Linux x86_64 platform ?

Am I doing something wrong here ?

I don't like having to pass '-I/usr/include/db4' '-ldb-4.5', but when
one has both libdb-5.1 installed with 'libdb.so' linking to it, and
/usr/include/db being from libdb-5.1, what else to do ?

Come to think of it, why must python force me to enable any DB* modules
at all ? And why must the whole python executable require linking with
berkeley DB when only the bsddb DL module need do so ?

----------
messages: 134753
nosy: Jason.Vas.Dias
priority: normal
severity: normal
status: open
title: 3.3 - 'make test' fails

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 14:01:44 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 12:01:44 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304078504.5.0.678696407651.issue11954@psf.upfronthosting.co.za>


Changes by Jason Vas Dias <jason.vas.dias at gmail.com>:


----------
components: +Build
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 14:01:59 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 12:01:59 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304078519.74.0.923807393169.issue11954@psf.upfronthosting.co.za>


Changes by Jason Vas Dias <jason.vas.dias at gmail.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 14:12:24 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 12:12:24 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304079144.25.0.667349964844.issue11954@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

my expat was just built a few weeks ago from expat-2.0.1.tar.gz:

$ ls -l /usr/lib64/libexpat*
-rw-r--r-- 1 root root 577052 Apr  8 21:52 /usr/lib64/libexpat.a
lrwxrwxrwx 1 root root     17 Apr  8 21:52 /usr/lib64/libexpat.so -> libexpat.so.1.5.2
lrwxrwxrwx 1 root root     28 Dec  3 17:37 /usr/lib64/libexpat.so.0 -> /usr/lib64/libexpat.so.1.5.2
lrwxrwxrwx 1 root root     17 Apr  8 21:52 /usr/lib64/libexpat.so.1 -> libexpat.so.1.5.2
-rwxr-xr-x 1 root root 387709 Apr  8 21:52 /usr/lib64/libexpat.so.1.5.2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 14:15:50 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 12:15:50 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304079350.81.0.945352423751.issue11954@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

suspect cause #1 - bad system libffi ? I just built it, but :

$ ls -l /usr/lib64/libffi*
-rwxr-xr-x 1 root root  36839 May 25  2008 /usr/lib64/libffi-2.00-beta.so
-rw-r--r-- 1 root root 201320 Apr  8 03:46 /usr/lib64/libffi.a
lrwxrwxrwx 1 root root     15 Apr  8 03:50 /usr/lib64/libffi.so -> libffi.so.4.0.1
lrwxrwxrwx 1 root root     15 Apr  8 03:50 /usr/lib64/libffi.so.4 -> libffi.so.4.0.1
-rwxr-xr-x 1 root root 134245 Apr  8 03:46 /usr/lib64/libffi.so.4.0.1
lrwxrwxrwx 1 root root     16 Jan  1 10:49 /usr/lib64/libffi.so.5 -> libffi.so.5.0.10
-rwxr-xr-x 1 root root  31520 Jan  1 10:49 /usr/lib64/libffi.so.5.0.10

/usr/lib64/libffi-3.0.6:
total 4
drwxr-xr-x 2 root root 4096 Nov 13  2008 include

/usr/lib64/libffi-3.0.9:
total 4
drwxr-xr-x 2 root root 4096 Jan  1 10:49 include

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 14:33:14 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 12:33:14 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304080394.01.0.22239311811.issue11954@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

$ ls -l /usr/lib64/libffi*
-rwxr-xr-x 1 root root  36839 May 25  2008 /usr/lib64/libffi-2.00-beta.so
-rw-r--r-- 1 root root 193480 Apr 29 13:22 /usr/lib64/libffi.a
-rwxr-xr-x 1 root root    904 Apr 29 13:22 /usr/lib64/libffi.la
lrwxrwxrwx 1 root root     15 Apr 29 13:22 /usr/lib64/libffi.so -> libffi.so.6.0.0
lrwxrwxrwx 1 root root     15 Apr  8 03:50 /usr/lib64/libffi.so.4 -> libffi.so.4.0.1
-rwxr-xr-x 1 root root 134245 Apr  8 03:46 /usr/lib64/libffi.so.4.0.1
lrwxrwxrwx 1 root root     16 Jan  1 10:49 /usr/lib64/libffi.so.5 -> libffi.so.5.0.10
-rwxr-xr-x 1 root root  31520 Jan  1 10:49 /usr/lib64/libffi.so.5.0.10
lrwxrwxrwx 1 root root     15 Apr 29 13:22 /usr/lib64/libffi.so.6 -> libffi.so.6.0.0
-rwxr-xr-x 1 root root 129109 Apr 29 13:22 /usr/lib64/libffi.so.6.0.0

/usr/lib64/libffi-3.0.10rc9:
total 4
drwxr-xr-x 2 root root 4096 Apr 29 13:22 include


NO - STILL FAILS :
$ make test 2>&1 | tee make.test.log                                                                                                                                  
running build                                                                                                                                                         
running build_ext                                                                                                                                                     
building dbm using bdb
running build_scripts
copying and adjusting /usr/src/cpython/Tools/scripts/pydoc3 -> build/scripts-3.3
copying and adjusting /usr/src/cpython/Tools/scripts/idle3 -> build/scripts-3.3
copying and adjusting /usr/src/cpython/Tools/scripts/2to3 -> build/scripts-3.3
changing mode of build/scripts-3.3/pydoc3 from 644 to 755
changing mode of build/scripts-3.3/idle3 from 644 to 755
changing mode of build/scripts-3.3/2to3 from 644 to 755
renaming build/scripts-3.3/pydoc3 to build/scripts-3.3/pydoc3.3
renaming build/scripts-3.3/idle3 to build/scripts-3.3/idle3.3
renaming build/scripts-3.3/2to3 to build/scripts-3.3/2to3-3.3
LD_LIBRARY_PATH=/mnt/sda3/Python-2.7: ./python -E -c 'import sys ; from sysconfig import get_platform ; print(get_platform()+"-"+sys.version[0:3])' >platform
find /usr/src/cpython/Lib -name '*.py[co]' -print | xargs rm -f
LD_LIBRARY_PATH=/mnt/sda3/Python-2.7: ./python -Wd -E -bb  /usr/src/cpython/Lib/test/regrtest.py -l
== CPython 3.3a0 (default:1768fed3aedb, Apr 29 2011, 13:27:16) [GCC 4.6.0]
==   Linux-2.6.38.2-jvd-x86_64-with-gentoo-1.12.13 little-endian
==   /usr/src/cpython/build/test_python_15034
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, verbose=0, bytes_warning=2, quiet=0)
[  1/354] test_grammar
[  2/354] test_opcodes
[  3/354] test_dict
[  4/354] test_builtin
[  5/354] test_exceptions
[  6/354] test_types
[  7/354] test_unittest
[  8/354] test_doctest
[  9/354] test_doctest2
[ 10/354] test___all__
[ 11/354] test___future__
[ 12/354] test__locale
[ 13/354] test_abc
[ 14/354] test_abstract_numbers
[ 15/354] test_aifc
[ 16/354] test_argparse
test test_argparse failed -- multiple errors occurred; run in verbose mode for details

gee, I'm glad to hear 'make test' has a verbose mode - 
don't suppose you could let me know how to invoke it
in that message ?  I guess 'make test V=1' ??

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 14:37:03 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 12:37:03 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304080623.9.0.564129557388.issue11954@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

no, 'make test V=1' still fails with 'run in verbose mode for details' .
does it mean 'make test verbose=1' ?  'make test mode=verbose' ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 14:45:20 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 12:45:20 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304081120.2.0.0511975715463.issue11954@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

OK, so getting out strace shows I need to do :

$ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython3.3.so.1.0 ./python -Wd -E -bb /usr/src/cpython/Lib/test/regrtest.py  -l -v 2>&1 | tee make.test.verbose.log

I'll show the failures from the above command when it has completed .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 14:52:31 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 12:52:31 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304081551.62.0.367373814357.issue11954@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

[ 16/354] test_argparse
... # all ok up to:
test_wb_1 (test.test_argparse.TestFileTypeRepr) ... ok
test_failures_many_groups_listargs (test.test_argparse.TestFileTypeW) ... FAIL
test_failures_many_groups_sysargs (test.test_argparse.TestFileTypeW) ... FAIL
test_failures_no_groups_listargs (test.test_argparse.TestFileTypeW) ... FAIL
test_failures_no_groups_sysargs (test.test_argparse.TestFileTypeW) ... FAIL
test_failures_one_group_listargs (test.test_argparse.TestFileTypeW) ... FAIL
test_failures_one_group_sysargs (test.test_argparse.TestFileTypeW) ... FAIL
test_successes_many_groups_listargs (test.test_argparse.TestFileTypeW) ... ok
...
test_successes_one_group_sysargs (test.test_argparse.TestTypeUserDefined) ... test test_argparse failed -- multiple errors occurred
ok

======================================================================
FAIL: test_failures_many_groups_listargs (test.test_argparse.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_many_groups_sysargs (test.test_argparse.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_no_groups_listargs (test.test_argparse.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_no_groups_sysargs (test.test_argparse.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_one_group_listargs (test.test_argparse.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_one_group_sysargs (test.test_argparse.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

----------------------------------------------------------------------
Ran 1608 tests in 6.725s

FAILED (failures=6)
[ 17/354] test_array

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 14:54:40 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 12:54:40 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304081680.4.0.957078801288.issue11954@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

test_successes_one_group_sysargs (test.test_argparse.TestTypeUserDefined) ... test test_argparse failed -- multiple errors occurred
ok

======================================================================
FAIL: test_failures_many_groups_listargs (test.test_argparse.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_many_groups_sysargs (test.test_argparse.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_no_groups_listargs (test.test_argparse.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_no_groups_sysargs (test.test_argparse.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_one_group_listargs (test.test_argparse.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_one_group_sysargs (test.test_argparse.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

----------------------------------------------------------------------
Ran 1608 tests in 6.725s

FAILED (failures=6)
[ 17/354] test_array

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 14:56:47 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 12:56:47 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304081807.26.0.712678961631.issue11954@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

test_start_with_double_slash (test.test_httpservers.SimpleHTTPRequestHandlerTestCase) ... /usr/src/cpython/Lib/unittest/case.py:799: BytesWarning: str() on a bytes instance
  (i, item1, item2))
test test_httpservers failed -- multiple errors occurred
ok

======================================================================
FAIL: test_get (test.test_httpservers.SimpleHTTPServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_httpservers.py", line 266, in test_get
    self.check_status_and_reason(response, 404)
  File "/usr/src/cpython/Lib/test/test_httpservers.py", line 242, in check_status_and_reason
    self.assertEqual(response.status, status)
AssertionError: 200 != 404

======================================================================
FAIL: test_authorization (test.test_httpservers.CGIHTTPServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_httpservers.py", line 427, in test_authorization
    (res.read(), res.getheader('Content-type'), res.status))
AssertionError: Tuples differ: (b'Hello World\n', 'text/html'... != (b'', None, 200)

First differing element 0:
b'Hello World\n'
b''

- (b'Hello World\n', 'text/html', 200)
+ (b'', None, 200)

======================================================================
FAIL: test_headers_and_content (test.test_httpservers.CGIHTTPServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_httpservers.py", line 407, in test_headers_and_content
    (res.read(), res.getheader('Content-type'), res.status))
AssertionError: Tuples differ: (b'Hello World\n', 'text/html'... != (b'', None, 200)

First differing element 0:
b'Hello World\n'
b''

- (b'Hello World\n', 'text/html', 200)
+ (b'', None, 200)

======================================================================
FAIL: test_no_leading_slash (test.test_httpservers.CGIHTTPServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_httpservers.py", line 433, in test_no_leading_slash
    (res.read(), res.getheader('Content-type'), res.status))
AssertionError: Tuples differ: (b'Hello World\n', 'text/html'... != (b'', None, 200)

First differing element 0:
b'Hello World\n'
b''

- (b'Hello World\n', 'text/html', 200)
+ (b'', None, 200)

======================================================================
FAIL: test_os_environ_is_not_altered (test.test_httpservers.CGIHTTPServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_httpservers.py", line 440, in test_os_environ_is_not_altered
    (res.read(), res.getheader('Content-type'), res.status))
AssertionError: Tuples differ: (b'Hello World\n', 'text/html'... != (b'', None, 200)

First differing element 0:
b'Hello World\n'
b''

- (b'Hello World\n', 'text/html', 200)
+ (b'', None, 200)

======================================================================
FAIL: test_post (test.test_httpservers.CGIHTTPServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_httpservers.py", line 415, in test_post
    self.assertEqual(res.read(), b'1, python, 123456\n')
AssertionError: b'' != b'1, python, 123456\n'

----------------------------------------------------------------------
Ran 37 tests in 2.971s

FAILED (failures=6)
[147/354] test_imaplib
test_Internaldate2tuple (test.test_imaplib.TestImaplib) ... ok
test_that_Time2Internaldate_returns_a_result (test.test_imaplib.TestImaplib) ... ok

----------------------------------------------------------------------
Ran 2 tests in 0.002s

OK
[148/354] test_imp

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 14:57:48 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 12:57:48 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304081868.02.0.028475349272.issue11954@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

test_too_high_from_package (test.test_import.RelativeImportFromImportlibTests) ... test test_import failed -- Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_import.py", line 545, in test_unwritable_directory
    '__pycache__', '{}.{}.pyc'.format(TESTFN, self.tag))))
AssertionError: True is not false

ok

======================================================================
FAIL: test_unwritable_directory (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_import.py", line 545, in test_unwritable_directory
    '__pycache__', '{}.{}.pyc'.format(TESTFN, self.tag))))
AssertionError: True is not false

----------------------------------------------------------------------
Ran 40 tests in 0.878s

FAILED (failures=1)
[150/354] test_importhooks
testBlocker (test.test_importhooks.ImportHooksTestCase) ... ok
testImpWrapper (test.test_importhooks.ImportHooksTestCase) ... ok
testMetaPath (test.test_importhooks.ImportHooksTestCase) ... ok
testPathHook (test.test_importhooks.ImportHooksTestCase) ... ok

----------------------------------------------------------------------
Ran 4 tests in 0.052s

OK
[151/354] test_importlib

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 15:00:08 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 13:00:08 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304082008.28.0.243740710344.issue11954@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

[237/354] test_pyexpat
test_ordered_attributes (test.test_pyexpat.SetAttributeTest) ... ok
test_specified_attributes (test.test_pyexpat.SetAttributeTest) ... ok
test_parse_file (test.test_pyexpat.ParseTest) ... ok
test_unicode (test.test_pyexpat.ParseTest) ... ok
test_illegal (test.test_pyexpat.NamespaceSeparatorTest) ... ok
test_legal (test.test_pyexpat.NamespaceSeparatorTest) ... ok
test_zero_length (test.test_pyexpat.NamespaceSeparatorTest) ... ok
test (test.test_pyexpat.InterningTest) ... ok
test_issue9402 (test.test_pyexpat.InterningTest) ... ok
test1 (test.test_pyexpat.BufferTextTest) ... ok
test2 (test.test_pyexpat.BufferTextTest) ... ok
test3 (test.test_pyexpat.BufferTextTest) ... ok
test4 (test.test_pyexpat.BufferTextTest) ... ok
test5 (test.test_pyexpat.BufferTextTest) ... ok
test6 (test.test_pyexpat.BufferTextTest) ... ok
test7 (test.test_pyexpat.BufferTextTest) ... ok
test_buffering_enabled (test.test_pyexpat.BufferTextTest) ... ok
test_default_to_disabled (test.test_pyexpat.BufferTextTest) ... ok
test (test.test_pyexpat.HandlerExceptionTest) ... ok
test (test.test_pyexpat.PositionTest) ... ok
test_parse_only_xml_data (test.test_pyexpat.sf1296433Test) ... ok
test_1000_bytes (test.test_pyexpat.ChardataBufferTest) ... ok
test_1025_bytes (test.test_pyexpat.ChardataBufferTest) ... ok
test_change_size_1 (test.test_pyexpat.ChardataBufferTest) ... ok
test_change_size_2 (test.test_pyexpat.ChardataBufferTest) ... ok
test_disabling_buffer (test.test_pyexpat.ChardataBufferTest) ... ok
test_unchanged_size (test.test_pyexpat.ChardataBufferTest) ... ok
test_wrong_size (test.test_pyexpat.ChardataBufferTest) ... ok
test1 (test.test_pyexpat.MalformedInputTest) ... Fatal Python error: Segmentation fault

Traceback (most recent call first):
  File "/usr/src/cpython/Lib/test/test_pyexpat.py", line 591 in test1
  File "/usr/src/cpython/Lib/unittest/case.py", line 391 in _executeTestPart
  File "/usr/src/cpython/Lib/unittest/case.py", line 446 in run
  File "/usr/src/cpython/Lib/unittest/case.py", line 498 in __call__
  File "/usr/src/cpython/Lib/unittest/suite.py", line 105 in run
  File "/usr/src/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/src/cpython/Lib/unittest/suite.py", line 105 in run
  File "/usr/src/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/src/cpython/Lib/unittest/runner.py", line 168 in run
  File "/usr/src/cpython/Lib/test/support.py", line 1182 in _run_suite
  File "/usr/src/cpython/Lib/test/support.py", line 1208 in run_unittest
  File "/usr/src/cpython/Lib/test/test_pyexpat.py", line 676 in test_main
  File "/usr/src/cpython/Lib/test/regrtest.py", line 1044 in runtest_inner
  File "/usr/src/cpython/Lib/test/regrtest.py", line 838 in runtest
  File "/usr/src/cpython/Lib/test/regrtest.py", line 662 in main
  File "/usr/src/cpython/Lib/test/regrtest.py", line 1622 in <module>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 15:05:06 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 Apr 2011 13:05:06 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304082306.7.0.0784099773304.issue11954@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Just so you know, you aren't likely to get much help using this approach to bug reporting.  A single, focused bug report is much more likely to get attention.

You might also want to try starting with a "vanilla configure" and see how things go with that first, and once you have that working add the custom configure flags that you showed in your first post one by one.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 15:15:34 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 13:15:34 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304082934.64.0.759622042877.issue11954@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

In reply to last comment :
RE: > a single, focused bug

What is this bug if not single and focused ?

The "SINGLE FOCUS" of this bug, in case you missed it , is that
there appears to be no source release of python that can build
and pass its make tests on my platform ; I then "FOCUSED" on
detailing each test failure found ; maybe you really don't
want people to be able to see these failures , which is why
the build hides the "-v" verbose option so effectively ?

I did first try :

$ ./configure --prefix=/usr --libdir=/usr/lib64 --enable-shared 

but this fails because no db module can build - again, back to 
my previous question - why must I enable any dbm module ?

I'll append the output of the failures from this "vanilla configure".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 15:31:19 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 13:31:19 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304083879.9.0.214044072452.issue11954@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

OK, so the ' vanilla configure ' build succeeds too - using DB module
only gdbm , and with internal libffi:

$ make clean
$/usr/src/cpython/configure --prefix=/usr --libdir=/usr/lib64 --enable-shared
...
$ echo $?
0
$ make -j2
...
$ echo $?
0

But exactly the same 'make test' errors result using gdm db module
and the internal libffi . Now running the verbose tests and will
append the failure details again.

Is there some special "vanilla configure" set of options
required by Python to pass its make tests ? If so, please
let me know what they are .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 15:53:49 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 13:53:49 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304085229.45.0.620388323651.issue11954@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

'make test' failures after 
$ /usr/src/cypython/configure --prefix=/usr --libdir=/usr/lib64 --enable-shared
$ make -j2 && make test
(make test fails)

So, to run in "verbose mode", I do :

$ LD_LIBRARY_PATH=`pwd` LD_PRELOAD=`pwd`/libpython3.so \
./python -Wd -E -bb /usr/src/cpython/Lib/test/regrtest.py -l -v
...
test test_argparse failed -- multiple errors occurred
ok

======================================================================
FAIL: test_failures_many_groups_listargs (test.test_argparse.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_many_groups_sysargs (test.test_argparse.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_no_groups_listargs (test.test_argparse.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_no_groups_sysargs (test.test_argparse.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_one_group_listargs (test.test_argparse.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_one_group_sysargs (test.test_argparse.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args
----------------------------------------------------------------------
Ran 1608 tests in 5.199s

FAILED (failures=6)
[ 17/354] test_array
...
======================================================================
ERROR: test_quiet (distutils.tests.test_bdist_rpm.BuildRpmTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/distutils/tests/test_bdist_rpm.py", line 81, in test_quiet
    cmd.run()
  File "/usr/src/cpython/Lib/distutils/command/bdist_rpm.py", line 367, in run
    self.spawn(rpm_cmd)
  File "/usr/src/cpython/Lib/distutils/cmd.py", line 368, in spawn
    spawn(cmd, search_path, dry_run=self.dry_run)
  File "/usr/src/cpython/Lib/distutils/spawn.py", line 34, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/usr/src/cpython/Lib/distutils/spawn.py", line 138, in _spawn_posix
    % (cmd[0], exit_status))
distutils.errors.DistutilsExecError: command 'rpmbuild' failed with exit status 1

----------------------------------------------------------------------
Ran 160 tests in 9.559s

FAILED (errors=2, skipped=5)
[ 94/354] test_docxmlrpc
test_autolink_dotted_methods (test.test_docxmlrpc.DocXMLRPCHTTPGETServer)
Test that selfdot values are made strong automatically in the ... ok
test_autolinking (test.test_docxmlrpc.DocXMLRPCHTTPGETServer)
Test that the server correctly automatically wraps references to ... ok
test_invalid_get_response (test.test_docxmlrpc.DocXMLRPCHTTPGETServer) ... ok
test_lambda (test.test_docxmlrpc.DocXMLRPCHTTPGETServer)
Test that lambda functionality stays the same.  The output produced ... ok
test_system_methods (test.test_docxmlrpc.DocXMLRPCHTTPGETServer)
Test the precense of three consecutive system.* methods. ... ok
test_valid_get_response (test.test_docxmlrpc.DocXMLRPCHTTPGETServer) ... ok

----------------------------------------------------------------------
Ran 6 tests in 0.688s

OK
[ 95/354] test_dummy_thread
...
test_too_high_from_package (test.test_import.RelativeImportFromImportlibTests) ... test test_import failed -- Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_import.py", line 545, in test_unwritable_directory
    '__pycache__', '{}.{}.pyc'.format(TESTFN, self.tag))))
AssertionError: True is not false

ok

======================================================================
FAIL: test_unwritable_directory (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_import.py", line 545, in test_unwritable_directory
    '__pycache__', '{}.{}.pyc'.format(TESTFN, self.tag))))
AssertionError: True is not false

----------------------------------------------------------------------
Ran 40 tests in 1.403s

FAILED (failures=1)
[150/354] test_importhooks
testBlocker (test.test_importhooks.ImportHooksTestCase) ... ok
testImpWrapper (test.test_importhooks.ImportHooksTestCase) ... ok
testMetaPath (test.test_importhooks.ImportHooksTestCase) ... ok
testPathHook (test.test_importhooks.ImportHooksTestCase) ... ok

----------------------------------------------------------------------
Ran 4 tests in 0.062s

OK
[151/354] test_importlib
test_failure (importlib.test.builtin.test_finder.FinderTests) ... ok
test_too_high_from_package (test.test_import.RelativeImportFromImportlibTests) ... test test_import failed -- Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_import.py", line 545, in test_unwritable_directory
    '__pycache__', '{}.{}.pyc'.format(TESTFN, self.tag))))
AssertionError: True is not false

ok

======================================================================
FAIL: test_unwritable_directory (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_import.py", line 545, in test_unwritable_directory
    '__pycache__', '{}.{}.pyc'.format(TESTFN, self.tag))))
AssertionError: True is not false

----------------------------------------------------------------------
Ran 40 tests in 1.403s

FAILED (failures=1)
[150/354] test_importhooks
testBlocker (test.test_importhooks.ImportHooksTestCase) ... ok
testImpWrapper (test.test_importhooks.ImportHooksTestCase) ... ok
testMetaPath (test.test_importhooks.ImportHooksTestCase) ... ok
testPathHook (test.test_importhooks.ImportHooksTestCase) ... ok

----------------------------------------------------------------------
Ran 4 tests in 0.062s

OK
[151/354] test_importlib
test_failure (importlib.test.builtin.test_finder.FinderTests) ... ok
test_too_high_from_package (test.test_import.RelativeImportFromImportlibTests) ... test test_import failed -- Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_import.py", line 545, in test_unwritable_directory
    '__pycache__', '{}.{}.pyc'.format(TESTFN, self.tag))))
AssertionError: True is not false

ok

======================================================================
FAIL: test_unwritable_directory (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_import.py", line 545, in test_unwritable_directory
    '__pycache__', '{}.{}.pyc'.format(TESTFN, self.tag))))
AssertionError: True is not false

----------------------------------------------------------------------
Ran 40 tests in 1.403s

FAILED (failures=1)
[150/354] test_importhooks
testBlocker (test.test_importhooks.ImportHooksTestCase) ... ok
testImpWrapper (test.test_importhooks.ImportHooksTestCase) ... ok
testMetaPath (test.test_importhooks.ImportHooksTestCase) ... ok
testPathHook (test.test_importhooks.ImportHooksTestCase) ... ok

----------------------------------------------------------------------
Ran 4 tests in 0.062s

OK
[151/354] test_importlib
test_failure (importlib.test.builtin.test_finder.FinderTests) ... ok


est_send_whole_file (test.test_os.TestSendfile) ... ok
test_set_get_priority (test.test_os.ProgramPriorityTests) ... test test_os failed -- Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_os.py", line 675, in test_exist_ok_existing_directory
    os.makedirs(path, mode=mode, exist_ok=True)
  File "/usr/src/cpython/Lib/os.py", line 152, in makedirs
    mkdir(name, mode)
OSError: [Errno 17] File exists: '@test_30733_tmp/dir1'

ok

======================================================================
ERROR: test_exist_ok_existing_directory (test.test_os.MakedirTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_os.py", line 675, in test_exist_ok_existing_directory
    os.makedirs(path, mode=mode, exist_ok=True)
  File "/usr/src/cpython/Lib/os.py", line 152, in makedirs
    mkdir(name, mode)
OSError: [Errno 17] File exists: '@test_30733_tmp/dir1'

----------------------------------------------------------------------
Ran 91 tests in 1.735s

FAILED (errors=1, skipped=13)
[201/354] test_ossaudiodev

...

test_successes_one_group_sysargs (test.test_argparse.TestTypeUserDefined) ... test test_argparse failed -- multiple errors occurred
ok

======================================================================
FAIL: test_failures_many_groups_listargs (test.test_argparse.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_many_groups_sysargs (test.test_argparse.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_no_groups_listargs (test.test_argparse.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_no_groups_sysargs (test.test_argparse.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_one_group_listargs (test.test_argparse.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_one_group_sysargs (test.test_argparse.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

----------------------------------------------------------------------
Ran 1608 tests in 5.199s

FAILED (failures=6)
[ 17/354] test_array
test_constructor (test.test_array.BadConstructorTest) ... ok




OK, at least it doesn't SEGV - I guess python doesn't like berkeley
DB anymore - but still the same failures . I'm not confident to
start using this build until I can pin down why eg test_argparse
and test_import are failing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 16:11:44 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 Apr 2011 14:11:44 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304086304.02.0.447414552738.issue11954@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

A focused bug report would focus on *one* of the test failures (as in the failures from running a single test_xxxxx).

Python3 does not support Berkeley DB out of the box, you need a third party library to get bdb support.

You might be interested to look at our buildbot status page; that will show any tests failing on the tips of all the branches current getting modifications.  http://www.python.org/dev/buildbot/all/console

You will note that we do not currently have a 64bit buildbot for Ubuntu, and that the Gentoo 64bit bot is currently offline.  So there may be problems on tip of which we aren't aware.  I doubt that argparse is one of them, but you never know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 16:16:01 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 29 Apr 2011 14:16:01 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304086561.22.0.653610852663.issue11954@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

> I'm not confident to start using this build until I can pin down why eg
> test_argparse and test_import are failing.

Feel free to look into the failures in Lib/test/test_argparse.py and Lib/test/test_import.py

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 16:23:45 2011
From: report at bugs.python.org (blokeley)
Date: Fri, 29 Apr 2011 14:23:45 +0000
Subject: [issue11344] Add os.path.splitpath(path) function
In-Reply-To: <1298795208.87.0.771920756626.issue11344@psf.upfronthosting.co.za>
Message-ID: <1304087025.53.0.271443290598.issue11344@psf.upfronthosting.co.za>


blokeley <blokeley at gmail.com> added the comment:

My runtime came from the Python32 Windows installer and I don't have a C compiler on this machine. Therefore I updated to the 3.2 branch in hg and worked on that. This patch is pretty simple so should work on 3.3 without modifications.

I have attached my first iteration of the patch (patched against hg rev 56c187b81d2b).

Disclaimers and suspected issues:

* A path given as a byte array is converted to a string so 
  splitpath() only returns lists of strings and never lists of 
  byte arrays. I don't know if splitpath() should return a list 
  of byte arrays if the path was a byte array. The way split() 
  is tested implies not. Please advise.
  
* We might need more tests to cover more path variations on Windows.

* I haven't implemented splitpath() in os2emxpath.py because 
  I couldn't find test/test_os2emxpath.py or the equivalent. 
  Please advise if there is one or if I should create one.

Feedback and patches most welcome.

----------
keywords: +patch
Added file: http://bugs.python.org/file21833/issue11344.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11344>
_______________________________________

From report at bugs.python.org  Fri Apr 29 16:25:27 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 29 Apr 2011 14:25:27 +0000
Subject: [issue11344] Add os.path.splitpath(path) function
In-Reply-To: <1298795208.87.0.771920756626.issue11344@psf.upfronthosting.co.za>
Message-ID: <1304087127.04.0.280484891282.issue11344@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11344>
_______________________________________

From report at bugs.python.org  Fri Apr 29 16:51:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Apr 2011 14:51:30 +0000
Subject: [issue11786] ConfigParser.[Raw]ConfigParser optionxform()
In-Reply-To: <1302110277.82.0.57770456199.issue11786@psf.upfronthosting.co.za>
Message-ID: <1304088690.81.0.287416439716.issue11786@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

2.5 and 2.6 are in security mode.  Other bug fixes, build changes, documentation improvements, etc. should not go in these branches.  Your commit does not break anything, but for process clarity, please back it out.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11786>
_______________________________________

From report at bugs.python.org  Fri Apr 29 16:53:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Apr 2011 14:53:27 +0000
Subject: [issue11324] ConfigParser(interpolation=None) doesn't work
In-Reply-To: <1298666228.44.0.489583826736.issue11324@psf.upfronthosting.co.za>
Message-ID: <1304088807.6.0.436887720242.issue11324@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

You forgot the Misc/NEWS entry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11324>
_______________________________________

From report at bugs.python.org  Fri Apr 29 17:19:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Apr 2011 15:19:20 +0000
Subject: [issue10419] distutils command build_scripts fails with
	UnicodeDecodeError
In-Reply-To: <1289766753.91.0.865805184241.issue10419@psf.upfronthosting.co.za>
Message-ID: <1304090360.65.0.291817574028.issue10419@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Indeed, I missed those two lines.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10419>
_______________________________________

From report at bugs.python.org  Fri Apr 29 17:30:14 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 29 Apr 2011 15:30:14 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
Message-ID: <1304091014.49.0.613904654138.issue3526@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

> I'm just proposing an alternative that I find cleaner, simpler and easier to maintain.

I understand how LD_PRELOAD works but I find it neither clean nor simple to maintain.

Also by using a wrapper to call Python you still impact all the applications that may be executed from Python since the environment variables are propagated. You also need to configure the path to the alternative malloc library at runtime.

And as I said above, I am afraid most AIX and SunOS users will never hear about that and will just use the default behavior, with their Python application taking much more memory than necessary.

As mentioned by Floris, AIX is being pushed by IBM quite a lot, and in some markets it is very common (if not predominant in finance for example - 50/50 with SunOS for my clients I would say).

> I mean, if you start embedding malloc in python, why stop there, and
not embed the whole glibc ;-)

Concerning AIX, that would not be such a bad idea given the number of bugs in the native C library (cf some of my other issues reported in python bug tracker) - just kidding ;-)

Concerning the fact that dlmalloc or ptmalloc evolve "quickly":
* dlmalloc V2.8.3 Thu Sep 22 11:16:32 2005
* ptmalloc2 release Jun 5th, 2006
* ptmalloc3 release May 31st, 2006
* dlmalloc V2.8.4 Wed May 27 09:56:23 2009
I think we can cope with that kind of "fast" evolution ;-)

Also an old dlmalloc is better than no dlmalloc at all.
And as you noticed, an old dlmalloc is already provided in libffi.

> So how about a --with-dlmalloc=path/to/dlmalloc.c?

That looks like a good alternative. I can implement that if that can help to get the patch in Python.

> Can't you just add dlmalloc to LDFLAGS or something? Or would the
default malloc still be selected?

There is a USE_DL_PREFIX in malloc.c. If this flag is defined, all functions will be prefixed by dl (dlmalloc, dlfree, dlrealloc...).
If it is not set, the functions will be named as usual (malloc, free...).

In my patch, I preferred to set USE_DL_PREFIX and call dlmalloc/dlfree explicitly where needed.

Since I want PyMem_MALLOC to call dlmalloc, I would need to export the "malloc" symbol from libpython so that Python extensions could use it when calling PyMem_MALLOC, but that would impact all malloc calls in applications which embed Python for example.

So I think it is probably better to explicitly distinguish when you want to call dlmalloc and leave the native malloc for the host application.

Also this only addresses the --with-dlmalloc part of my patch.
The other part concerning --with-pymalloc-mmap ensures that pymalloc uses mmap to allocate arenas rather than malloc.

I perfectly understand that people are reluctant to make the memory allocation system more complex than it is already in Python in order to bypass some limitations of systems which are not very widespread among Python users.

But Python eating a lot of memory on SunOS and AIX does not look very good either.

I have some strong requirements as far as memory is concerned for my application so I have maintained this patch internally and distributed it as part of my application.

I will probably change of job soon and will not have access to AIX systems anymore. I don't really expect this patch to be accepted soon as few people have expressed some interest and I don't have much time/interest to push it on python-dev, but I will update the patch for Python 2.7 and 3.2 before leaving so that people impacted by this problem could a least manually patch their Python if they find this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Fri Apr 29 17:45:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Apr 2011 15:45:41 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1304091014.49.0.613904654138.issue3526@psf.upfronthosting.co.za>
Message-ID: <1304091918.3587.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Since I want PyMem_MALLOC to call dlmalloc, I would need to export the
> "malloc" symbol from libpython so that Python extensions could use it
> when calling PyMem_MALLOC, but that would impact all malloc calls in
> applications which embed Python for example.

Well, that would be a rather good thing. There are, IIRC, Python API
calls which require that the caller manually frees memory. If the API
call malloc()s memory with a certain allocator and the caller free()s it
with another allocator, the result won't be pretty :)

(a similar discrepancy occurs between function-based APIs and
macro-based APIs: functions get compiled inside the Python library while
macros get compiled within the embedding executable; if library and
application have an incompatible malloc()/free() pair, you will get
similarly funny results)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Fri Apr 29 18:00:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Apr 2011 16:00:44 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1304092844.34.0.74256719064.issue828450@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> accepted
stage: test needed -> patch review
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Fri Apr 29 18:01:11 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Fri, 29 Apr 2011 16:01:11 +0000
Subject: [issue9756] Crash with custom __getattribute__
In-Reply-To: <1283515984.36.0.673218996521.issue9756@psf.upfronthosting.co.za>
Message-ID: <1304092871.56.0.959871727461.issue9756@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

I think it is reasonable to restrict the self argument of method descriptors and slot wrapper descriptors to real instances of the type. The called method can't cope with the value anyway (in the general case). Alternative Python implementations like Jython and PyPy already enforce this.

Attached is a patch against default branch that enforces this.

----------
keywords: +patch
Added file: http://bugs.python.org/file21834/issue9756.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9756>
_______________________________________

From report at bugs.python.org  Fri Apr 29 18:04:02 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 29 Apr 2011 16:04:02 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
Message-ID: <1304093042.03.0.680855314337.issue3526@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Yes, I was probably not clear:
When --with-dlmalloc is activated, PyMem_MALLOC/PyMem_Malloc will call dlmalloc, PyMem_REALLOC/PyMem_Realloc will call dlrealloc and PyMem_FREE/PyMem_Free will call dlfree.

While calls to malloc/free/realloc will use the platform implementation.

So I think there should not be any mix, since as it is mentioned in pymem.h, people should not mix PyMem_MALLOC/PyMem_FREE with malloc/free:

/* BEWARE:

   Each interface exports both functions and macros.  Extension modules should
   use the functions, to ensure binary compatibility across Python versions.
   Because the Python implementation is free to change internal details, and
   the macros may (or may not) expose details for speed, if you do use the
   macros you must recompile your extensions with each Python release.

   Never mix calls to PyMem_ with calls to the platform malloc/realloc/
   calloc/free.  For example, on Windows different DLLs may end up using
   different heaps, and if you use PyMem_Malloc you'll get the memory from the
   heap used by the Python DLL; it could be a disaster if you free()'ed that
   directly in your own extension.  Using PyMem_Free instead ensures Python
   can return the memory to the proper heap.  As another example, in
   PYMALLOC_DEBUG mode, Python wraps all calls to all PyMem_ and PyObject_
   memory functions in special debugging wrappers that add additional
   debugging info to dynamic memory blocks.  The system routines have no idea
   what to do with that stuff, and the Python wrappers have no idea what to do
   with raw blocks obtained directly by the system routines then.

   The GIL must be held when using these APIs.
*/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Fri Apr 29 18:04:17 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Fri, 29 Apr 2011 16:04:17 +0000
Subject: [issue11343] Make errors due to full parser stack identifiable
In-Reply-To: <1298759991.59.0.16834388397.issue11343@psf.upfronthosting.co.za>
Message-ID: <1304093057.74.0.864393511751.issue11343@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

FWIW, this also affects `ast.literal_eval()`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11343>
_______________________________________

From report at bugs.python.org  Fri Apr 29 18:15:42 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 16:15:42 +0000
Subject: [issue11955] 3.3 : test_argparse.py fails 'make test'
In-Reply-To: <1304093741.94.0.09129303291.issue11955@psf.upfronthosting.co.za>
Message-ID: <1304093741.94.0.09129303291.issue11955@psf.upfronthosting.co.za>


New submission from Jason Vas Dias <jason.vas.dias at gmail.com>:

Hi - I've been experiencing many errors trying to build any version
of Python that will pass its test suite - see issues : #11946 , #11954 -
and now I've been advised to raise bugs about each test failure -
hence this bug. For details of my config and build procedure, please
see : issue #11954 .

So, running the new ./python fails test_argparse :

$ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython3.3.so.1.0 \
  ./python /usr/src/cpython/Lib/test/test_argparse.py
...
======================================================================
FAIL: test_failures_many_groups_listargs (__main__.TestFileTypeW)     
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)                                                      
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)                       
AssertionError: ArgumentParserError not raised by parse_args                   

======================================================================
FAIL: test_failures_many_groups_sysargs (__main__.TestFileTypeW)      
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)                                                      
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)                       
AssertionError: ArgumentParserError not raised by parse_args                   

======================================================================
FAIL: test_failures_no_groups_listargs (__main__.TestFileTypeW)       
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)                                                      
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)                       
AssertionError: ArgumentParserError not raised by parse_args                   

======================================================================
FAIL: test_failures_no_groups_sysargs (__main__.TestFileTypeW)        
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)                                                      
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)                       
AssertionError: ArgumentParserError not raised by parse_args                   

======================================================================
FAIL: test_failures_one_group_listargs (__main__.TestFileTypeW)       
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)                                                      
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)                       
AssertionError: ArgumentParserError not raised by parse_args                   

======================================================================
FAIL: test_failures_one_group_sysargs (__main__.TestFileTypeW)        
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)                                                      
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)                       
AssertionError: ArgumentParserError not raised by parse_args                   

----------------------------------------------------------------------
Ran 1608 tests in 5.293s                                              

FAILED (failures=6)
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 4712, in <module>
    test_main()                                                            
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 4704, in test_main
    support.run_unittest(__name__)                                          
  File "/usr/src/cpython/Lib/test/support.py", line 1208, in run_unittest   
    _run_suite(suite)                                                       
  File "/usr/src/cpython/Lib/test/support.py", line 1191, in _run_suite     
    raise TestFailed(err)                                                   
test.support.TestFailed: multiple errors occurred 


Now, as someone with not too recent python programming experience,
I find it very difficult to understand exactly what is being
tested by :

class TestFileTypeW(TempDirMixin, ParserTestCase):
    """Test the FileType option/argument type for writing files"""

    def setUp(self):
        super(TestFileTypeW, self).setUp()
        self.create_readonly_file('readonly')

    argument_signatures = [
        Sig('-x', type=argparse.FileType('w')),
        Sig('spam', type=argparse.FileType('w')),
    ]
    failures = ['-x', '', 'readonly']
    successes = [
        ('foo', NS(x=None, spam=WFile('foo'))),
        ('-x foo bar', NS(x=WFile('foo'), spam=WFile('bar'))),
        ('bar -x foo', NS(x=WFile('foo'), spam=WFile('bar'))),
        ('-x - -', NS(x=sys.stdout, spam=sys.stdout)),
    ]


But it seems at least one bug is self-evident : test_argparse.py's
error messages are essentially meaningless, and contain no useful
information (beyond the name) about what failed or why - they are
all essentially duplicates of :

Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)

So why emit 6 copies of the same meaningless message ? 

I'm curious: how do you expect those error messages to help people
track down the source of the bug when every error message contains
the same data and line numbers, and they are line numbers not
of specific tests, but of some "error handler" routine ?

----------
components: Build
messages: 134779
nosy: Jason.Vas.Dias
priority: normal
severity: normal
status: open
title: 3.3 : test_argparse.py fails 'make test'
type: crash
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11955>
_______________________________________

From report at bugs.python.org  Fri Apr 29 18:16:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Apr 2011 16:16:49 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1304093042.03.0.680855314337.issue3526@psf.upfronthosting.co.za>
Message-ID: <1304093795.3587.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Yes, I was probably not clear:
> When --with-dlmalloc is activated, PyMem_MALLOC/PyMem_Malloc will call
> dlmalloc, PyMem_REALLOC/PyMem_Realloc will call dlrealloc and
> PyMem_FREE/PyMem_Free will call dlfree.
> 
> While calls to malloc/free/realloc will use the platform implementation.

I'm not sure why you would want that. If dlmalloc is clearly superior,
why not use it for all allocations inside the application (not only
Python ones)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Fri Apr 29 18:21:26 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 16:21:26 +0000
Subject: [issue11956] 3.3 : test_import.py causes 'make test' to fail
In-Reply-To: <1304094086.01.0.944392387954.issue11956@psf.upfronthosting.co.za>
Message-ID: <1304094086.01.0.944392387954.issue11956@psf.upfronthosting.co.za>


New submission from Jason Vas Dias <jason.vas.dias at gmail.com>:

Hi - I've been experiencing many errors trying to build any version
of Python that will pass its test suite - see issues : #11946 , #11954 -
and now I've been advised to raise bugs about each test failure -
hence this bug. For details of my config and build procedure, please
see : issue #11954 .

So, running the new ./python fails test_import.py :

$ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython3.3.so.1.0 \
  ./python /usr/src/cpython/Lib/test/test_import.py
======================================================================
FAIL: test_unwritable_directory (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_import.py", line 545, in test_unwritable_directory
    '__pycache__', '{}.{}.pyc'.format(TESTFN, self.tag))))
AssertionError: True is not false

----------------------------------------------------------------------
Ran 40 tests in 0.851s

FAILED (failures=1)
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_import.py", line 658, in <module>
    test_main()
  File "/usr/src/cpython/Lib/test/test_import.py", line 652, in test_main
    RelativeImportFromImportlibTests)
  File "/usr/src/cpython/Lib/test/support.py", line 1208, in run_unittest
    _run_suite(suite)
  File "/usr/src/cpython/Lib/test/support.py", line 1191, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_import.py", line 545, in test_unwritable_directory
    '__pycache__', '{}.{}.pyc'.format(TESTFN, self.tag))))
AssertionError: True is not false


Thanks for the helpful error backtrace ! 

This function is somehow failing (test_import.py @ line 545 ):

   @unittest.skipUnless(os.name == 'posix',
                         "test meaningful only on posix systems")
    def test_unwritable_directory(self):
        # When the umask causes the new __pycache__ directory to be
        # unwritable, the import still succeeds but no .pyc file is written.
        with temp_umask(0o222):
            __import__(TESTFN)
        self.assertTrue(os.path.exists('__pycache__'))
        self.assertFalse(os.path.exists(os.path.join(
            '__pycache__', '{}.{}.pyc'.format(TESTFN, self.tag))))





Running the same command under strace shows what the test is trying
to assert shouldn't exist really doesn't :
umask(022)                              = 0222
stat("__pycache__", {st_mode=S_IFDIR|S_ISGID|0555, st_size=4096, ...}) = 0
stat("__pycache__/@test_9634_tmp.cpython-32.pyc", {st_mode=S_IFREG|0444, st_size=110, ...}) = 0
unlink("/usr/src/cpython/Lib/test/@test_9634_tmp.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/test/@test_9634_tmp.pyo") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/test/__pycache__/@test_9634_tmp.cpython-32.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/test/__pycache__/@test_9634_tmp.cpython-32.pyo") = -1 ENOENT (No such file or directory)
unlink("/usr/lib/python33.zip/@test_9634_tmp.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/lib/python33.zip/@test_9634_tmp.pyo") = -1 ENOENT (No such file or directory)
unlink("/usr/lib/python33.zip/__pycache__/@test_9634_tmp.cpython-32.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/lib/python33.zip/__pycache__/@test_9634_tmp.cpython-32.pyo") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/@test_9634_tmp.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/@test_9634_tmp.pyo") = -1 ENOENT (No such file or directory)

(see full listing below)

 




umask(022)                              = 0222
stat("__pycache__", {st_mode=S_IFDIR|S_ISGID|0555, st_size=4096, ...}) = 0
stat("__pycache__/@test_9634_tmp.cpython-32.pyc", {st_mode=S_IFREG|0444, st_size=110, ...}) = 0
unlink("/usr/src/cpython/Lib/test/@test_9634_tmp.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/test/@test_9634_tmp.pyo") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/test/__pycache__/@test_9634_tmp.cpython-32.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/test/__pycache__/@test_9634_tmp.cpython-32.pyo") = -1 ENOENT (No such file or directory)
unlink("/usr/lib/python33.zip/@test_9634_tmp.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/lib/python33.zip/@test_9634_tmp.pyo") = -1 ENOENT (No such file or directory)
unlink("/usr/lib/python33.zip/__pycache__/@test_9634_tmp.cpython-32.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/lib/python33.zip/__pycache__/@test_9634_tmp.cpython-32.pyo") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/@test_9634_tmp.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/@test_9634_tmp.pyo") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/__pycache__/@test_9634_tmp.cpython-32.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/__pycache__/@test_9634_tmp.cpython-32.pyo") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/plat-linux2/@test_9634_tmp.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/plat-linux2/@test_9634_tmp.pyo") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/plat-linux2/__pycache__/@test_9634_tmp.cpython-32.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/plat-linux2/__pycache__/@test_9634_tmp.cpython-32.pyo") = -1 ENOENT (No such file or directory)
unlink("/mnt/sda3/Python-2.7/build/lib.linux-x86_64-3.3/@test_9634_tmp.pyc") = -1 ENOENT (No such file or directory)
unlink("/mnt/sda3/Python-2.7/build/lib.linux-x86_64-3.3/@test_9634_tmp.pyo") = -1 ENOENT (No such file or directory)
unlink("/mnt/sda3/Python-2.7/build/lib.linux-x86_64-3.3/__pycache__/@test_9634_tmp.cpython-32.pyc") = -1 ENOENT (No such file or directory)
unlink("/mnt/sda3/Python-2.7/build/lib.linux-x86_64-3.3/__pycache__/@test_9634_tmp.cpython-32.pyo") = -1 ENOENT (No such file or directory)
unlink("/home/root/.local/lib/python3.3/site-packages/@test_9634_tmp.pyc") = -1 ENOENT (No such file or directory)
unlink("/home/root/.local/lib/python3.3/site-packages/@test_9634_tmp.pyo") = -1 ENOENT (No such file or directory)
unlink("/home/root/.local/lib/python3.3/site-packages/__pycache__/@test_9634_tmp.cpython-32.pyc") = -1 ENOENT (No such file or directory)
unlink("/home/root/.local/lib/python3.3/site-packages/__pycache__/@test_9634_tmp.cpython-32.pyo") = -1 ENOENT (No such file or directory)
lstat("__pycache__", {st_mode=S_IFDIR|S_ISGID|0555, st_size=4096, ...}) = 0
open("__pycache__", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
getdents64(3, /* 3 entries */, 32768)   = 104
getdents64(3, /* 0 entries */, 32768)   = 0
close(3)                                = 0
lstat("__pycache__/@test_9634_tmp.cpython-32.pyc", {st_mode=S_IFREG|0444, st_size=110, ...}) = 0
unlink("__pycache__/@test_9634_tmp.cpython-32.pyc") = 0
rmdir("__pycache__")                    = 0
unlink("@test_9634_tmp.py")             = 0
stat("/usr/src/cpython/Lib/test/test_import.py", {st_mode=S_IFREG|0644, st_size=24532, ...}) = 0
open("/usr/src/cpython/Lib/test/test_import.py", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=24532, ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7fff7ef66e98) = -1 ENOTTY (Inappropriate ioctl for device)
fstat(3, {st_mode=S_IFREG|0644, st_size=24532, ...}) = 0
lseek(3, 0, SEEK_CUR)                   = 0
read(3, "import builtins\nimport imp\nfrom importlib.test.import_ import test_relative_imports\nfrom importlib.test.import_ import util as importlib_util\nimport marshal\nimport os\nimport py_compile\nimport random\nimport stat\nimport sys\nimport unittest\nimport textwrap\n\nfrom test.support import (\n    EnvironmentVarGuard, TESTFN, check_warnings, forget, is_jython,\n    make_legacy_pyc, rmtree, run_unittest, swap_attr, swap_item, temp_umask,\n    unlink, unload)\nfrom test import script_helper\n\n\ndef remove_files(name):\n    for f in (name + \".py\",\n              name + \".pyc\",\n              name + \".pyo\",\n              name + \".pyw\",\n              name + \"$py.class\"):\n        unlink(f)\n    rmtree('__pycache__')\n\n\nclass ImportTests(unittest.TestCase):\n\n    def setUp(self):\n        remove_files(TESTFN)\n\n    def tearDown(self):\n        unload(TESTFN)\n\n    setUp = tearDown\n\n    def test_case_sensitivity(self):\n        # Brief digression to test that import is case-sensitive:  if we got\n        # this far, we know for sure that \"random\" exists.\n        with self.assertRaises(ImportError):\n            import RAnDoM\n\n    def test_double_const(self):\n        # Another brief digression to test the accuracy of manifest float\n        # constants.\n        from test import double_const  # don't blink -- that *was* the test\n\n    def test_import(self):\n        def test_with_extension(ext):\n            # The extension is normally \".py\", perhaps \".pyw\".\n            source = TESTFN + ext\n            pyo = TESTFN + \".pyo\"\n            if is_jython:\n                pyc = TESTFN + \"$py.class\"\n            else:\n                pyc = TESTFN + \".pyc\"\n\n            with open(source, \"w\") as f:\n                print(\"# This tests Python's ability to import a\",\n                      ext, \"file.\", file=f)\n                a = random.randrange(1000)\n                b = random.randrange(1000)\n                print(\"a =\", a, file=f)\n                print(\"b =\", b, file=f)\n\n            if TESTFN in sys.modules:\n                del sys.modules[TESTFN]\n            try:\n                try:\n                    mod = __import__(TESTFN)\n                except ImportError as err:\n                    self.fail(\"import from %s failed: %s\" % (ext, err))\n\n                self.assertEqual(mod.a, a,\n                    \"module loaded (%s) but contents invalid\" % mod)\n                self.assertEqual(mod.b, b,\n                    \"module loaded (%s) but contents invalid\" % mod)\n            finally:\n                forget(TESTFN)\n                unlink(source)\n                unlink(pyc)\n                unlink(pyo)\n\n        sys.path.insert(0, os.curdir)\n        try:\n            test_with_extension(\".py\")\n            if sys.platform.startswith(\"win\"):\n                for ext in [\".PY\", \".Py\", \".pY\", \".pyw\", \".PYW\", \".pYw\"]:\n                    test_with_extension(ext)\n        finally:\n            del sys.path[0]\n\n    @unittest.skipUnless(os.name == 'posix',\n                         \"test meaningful only on posix systems\")\n    def test_execute_bit_not_copied(self):\n        # Issue 6070: under posix .pyc files got their execute bit set if\n        # the .py file had the execute bit set, but they aren't executable.\n        with temp_umask(0o022):\n            sys.path.insert(0, os.curdir)\n            try:\n                fname = TESTFN + os.extsep + \"py\"\n                open(fname, 'w').close()\n                os.chmod(fname, (stat.S_IRUSR | stat.S_IRGRP | stat.S_IROTH |\n                                 stat.S_IXUSR | stat.S_IXGRP | stat.S_IXOTH))\n                __import__(TESTFN)\n                fn = imp.cache_from_source(fname)\n                if not os.path.exists(fn):\n                    self.fail(\"__import__ did not result in creation of \"\n                              \"either a .pyc or .pyo file\")\n                    s = os.stat(fn)\n                    self.assertEqual(\n                        stat.S_IMODE(s.st_mode),\n                        stat.S_IRUSR | stat.S_IRGRP | stat.S_IROTH)\n            finally:\n                del sys.path[0]\n                remove_files(TESTFN)\n                u", 4096) = 4096
lseek(3, 0, SEEK_CUR)                   = 4096
read(3, "nload(TESTFN)\n\n    def test_imp_module(self):\n        # Verify that the imp module can correctly load and find .py files\n        # XXX (ncoghlan): It would be nice to use support.CleanImport\n        # here, but that breaks because the os module registers some\n        # handlers in copy_reg on import. Since CleanImport doesn't\n        # revert that registration, the module is left in a broken\n        # state after reversion. Reinitialising the module contents\n        # and just reverting os.environ to its previous state is an OK\n        # workaround\n        orig_path = os.path\n        orig_getenv = os.getenv\n        with EnvironmentVarGuard():\n            x = imp.find_module(\"os\")\n            self.addCleanup(x[0].close)\n            new_os = imp.load_module(\"os\", *x)\n            self.assertIs(os, new_os)\n            self.assertIs(orig_path, new_os.path)\n            self.assertIsNot(orig_getenv, new_os.getenv)\n\n    def test_module_with_large_stack(self, module='longlist'):\n        # Regression test for http://bugs.python.org/issue561858.\n        filename = module + '.py'\n\n        # Create a file with a list of 65000 elements.\n        with open(filename, 'w') as f:\n            f.write('d = [\\n')\n            for i in range(65000):\n                f.write('\"\",\\n')\n            f.write(']')\n\n        try:\n            # Compile & remove .py file; we only need .pyc (or .pyo).\n            # Bytecode must be relocated from the PEP 3147 bytecode-only location.\n            py_compile.compile(filename)\n        finally:\n            unlink(filename)\n\n        # Need to be able to load from current dir.\n        sys.path.append('')\n\n        try:\n            make_legacy_pyc(filename)\n            # This used to crash.\n            exec('import ' + module)\n        finally:\n            # Cleanup.\n            del sys.path[-1]\n            unlink(filename + 'c')\n            unlink(filename + 'o')\n\n    def test_failing_import_sticks(self):\n        source = TESTFN + \".py\"\n        with open(source, \"w\") as f:\n            print(\"a = 1/0\", file=f)\n\n        # New in 2.4, we shouldn't be able to import that no matter how often\n        # we try.\n        sys.path.insert(0, os.curdir)\n        if TESTFN in sys.modules:\n            del sys.modules[TESTFN]\n        try:\n            for i in [1, 2, 3]:\n                self.assertRaises(ZeroDivisionError, __import__, TESTFN)\n                self.assertNotIn(TESTFN, sys.modules,\n                                 \"damaged module in sys.modules on %i try\" % i)\n        finally:\n            del sys.path[0]\n            remove_files(TESTFN)\n\n    def test_import_name_binding(self):\n        # import x.y.z binds x in the current namespace\n        import test as x\n        import test.support\n        self.assertTrue(x is test, x.__name__)\n        self.assertTrue(hasattr(test.support, \"__file__\"))\n\n        # import x.y.z as w binds z as w\n        import test.support as y\n        self.assertTrue(y is test.support, y.__name__)\n\n    def test_failing_reload(self):\n        # A failing reload should leave the module object in sys.modules.\n        source = TESTFN + os.extsep + \"py\"\n        with open(source, \"w\") as f:\n            f.write(\"a = 1\\nb=2\\n\")\n\n        sys.path.insert(0, os.curdir)\n        try:\n            mod = __import__(TESTFN)\n            self.assertIn(TESTFN, sys.modules)\n            self.assertEqual(mod.a, 1, \"module has wrong attribute values\")\n            self.assertEqual(mod.b, 2, \"module has wrong attribute values\")\n\n            # On WinXP, just replacing the .py file wasn't enough to\n            # convince reload() to reparse it.  Maybe the timestamp didn't\n            # move enough.  We force it to get reparsed by removing the\n            # compiled file too.\n            remove_files(TESTFN)\n\n            # Now damage the module.\n            with open(source, \"w\") as f:\n                f.write(\"a = 10\\nb=20//0\\n\")\n\n            self.assertRaises(ZeroDivisionError, imp.reload, mod)\n            # But we still expect the module to be in sys.modules.\n            mod = sys.modules.get(TESTFN)\n            self.assertIsNot", 4096) = 4096
read(3, "(mod, None, \"expected module to be in sys.modules\")\n\n            # We should have replaced a w/ 10, but the old b value should\n            # stick.\n            self.assertEqual(mod.a, 10, \"module has wrong attribute values\")\n            self.assertEqual(mod.b, 2, \"module has wrong attribute values\")\n\n        finally:\n            del sys.path[0]\n            remove_files(TESTFN)\n            unload(TESTFN)\n\n    def test_file_to_source(self):\n        # check if __file__ points to the source file where available\n        source = TESTFN + \".py\"\n        with open(source, \"w\") as f:\n            f.write(\"test = None\\n\")\n\n        sys.path.insert(0, os.curdir)\n        try:\n            mod = __import__(TESTFN)\n            self.assertTrue(mod.__file__.endswith('.py'))\n            os.remove(source)\n            del sys.modules[TESTFN]\n            make_legacy_pyc(source)\n            mod = __import__(TESTFN)\n            base, ext = os.path.splitext(mod.__file__)\n            self.assertIn(ext, ('.pyc', '.pyo'))\n        finally:\n            del sys.path[0]\n            remove_files(TESTFN)\n            if TESTFN in sys.modules:\n                del sys.modules[TESTFN]\n\n    def test_import_name_binding(self):\n        # import x.y.z binds x in the current namespace.\n        import test as x\n        import test.support\n        self.assertIs(x, test, x.__name__)\n        self.assertTrue(hasattr(test.support, \"__file__\"))\n\n        # import x.y.z as w binds z as w.\n        import test.support as y\n        self.assertIs(y, test.support, y.__name__)\n\n    def test_import_initless_directory_warning(self):\n        with check_warnings(('', ImportWarning)):\n            # Just a random non-package directory we always expect to be\n            # somewhere in sys.path...\n            self.assertRaises(ImportError, __import__, \"site-packages\")\n\n    def test_import_by_filename(self):\n        path = os.path.abspath(TESTFN)\n        encoding = sys.getfilesystemencoding()\n        try:\n            path.encode(encoding)\n        except UnicodeEncodeError:\n            self.skipTest('path is not encodable to {}'.format(encoding))\n        with self.assertRaises(ImportError) as c:\n            __import__(path)\n\n    def test_import_in_del_does_not_crash(self):\n        # Issue 4236\n        testfn = script_helper.make_script('', TESTFN, textwrap.dedent(\"\"\"\\\n            import sys\n            class C:\n               def __del__(self):\n                  import imp\n            sys.argv.insert(0, C())\n            \"\"\"))\n        script_helper.assert_python_ok(testfn)\n\n\nclass PycRewritingTests(unittest.TestCase):\n    # Test that the `co_filename` attribute on code objects always points\n    # to the right file, even when various things happen (e.g. both the .py\n    # and the .pyc file are renamed).\n\n    module_name = \"unlikely_module_name\"\n    module_source = \"\"\"\nimport sys\ncode_filename = sys._getframe().f_code.co_filename\nmodule_filename = __file__\nconstant = 1\ndef func():\n    pass\nfunc_filename = func.__code__.co_filename\n\"\"\"\n    dir_name = os.path.abspath(TESTFN)\n    file_name = os.path.join(dir_name, module_name) + os.extsep + \"py\"\n    compiled_name = imp.cache_from_source(file_name)\n\n    def setUp(self):\n        self.sys_path = sys.path[:]\n        self.orig_module = sys.modules.pop(self.module_name, None)\n        os.mkdir(self.dir_name)\n        with open(self.file_name, \"w\") as f:\n            f.write(self.module_source)\n        sys.path.insert(0, self.dir_name)\n\n    def tearDown(self):\n        sys.path[:] = self.sys_path\n        if self.orig_module is not None:\n            sys.modules[self.module_name] = self.orig_module\n        else:\n            unload(self.module_name)\n        unlink(self.file_name)\n        unlink(self.compiled_name)\n        rmtree(self.dir_name)\n\n    def import_module(self):\n        ns = globals()\n        __import__(self.module_name, ns, ns)\n        return sys.modules[self.module_name]\n\n    def test_basics(self):\n        mod = self.import_module()\n        self.assertEqual(mod.module_filename, self.file_name)\n        self.assertEqual(mod.code_filename, self.fil", 4096) = 4096
read(3, "e_name)\n        self.assertEqual(mod.func_filename, self.file_name)\n        del sys.modules[self.module_name]\n        mod = self.import_module()\n        self.assertEqual(mod.module_filename, self.file_name)\n        self.assertEqual(mod.code_filename, self.file_name)\n        self.assertEqual(mod.func_filename, self.file_name)\n\n    def test_incorrect_code_name(self):\n        py_compile.compile(self.file_name, dfile=\"another_module.py\")\n        mod = self.import_module()\n        self.assertEqual(mod.module_filename, self.file_name)\n        self.assertEqual(mod.code_filename, self.file_name)\n        self.assertEqual(mod.func_filename, self.file_name)\n\n    def test_module_without_source(self):\n        target = \"another_module.py\"\n        py_compile.compile(self.file_name, dfile=target)\n        os.remove(self.file_name)\n        pyc_file = make_legacy_pyc(self.file_name)\n        mod = self.import_module()\n        self.assertEqual(mod.module_filename, pyc_file)\n        self.assertEqual(mod.code_filename, target)\n        self.assertEqual(mod.func_filename, target)\n\n    def test_foreign_code(self):\n        py_compile.compile(self.file_name)\n        with open(self.compiled_name, \"rb\") as f:\n            header = f.read(8)\n            code = marshal.load(f)\n        constants = list(code.co_consts)\n        foreign_code = test_main.__code__\n        pos = constants.index(1)\n        constants[pos] = foreign_code\n        code = type(code)(code.co_argcount, code.co_kwonlyargcount,\n                          code.co_nlocals, code.co_stacksize,\n                          code.co_flags, code.co_code, tuple(constants),\n                          code.co_names, code.co_varnames, code.co_filename,\n                          code.co_name, code.co_firstlineno, code.co_lnotab,\n                          code.co_freevars, code.co_cellvars)\n        with open(self.compiled_name, \"wb\") as f:\n            f.write(header)\n            marshal.dump(code, f)\n        mod = self.import_module()\n        self.assertEqual(mod.constant.co_filename, foreign_code.co_filename)\n\n\nclass PathsTests(unittest.TestCase):\n    SAMPLES = ('test', 'test\\u00e4\\u00f6\\u00fc\\u00df', 'test\\u00e9\\u00e8',\n               'test\\u00b0\\u00b3\\u00b2')\n    path = TESTFN\n\n    def setUp(self):\n        os.mkdir(self.path)\n        self.syspath = sys.path[:]\n\n    def tearDown(self):\n        rmtree(self.path)\n        sys.path[:] = self.syspath\n\n    # Regression test for http://bugs.python.org/issue1293.\n    def test_trailing_slash(self):\n        with open(os.path.join(self.path, 'test_trailing_slash.py'), 'w') as f:\n            f.write(\"testdata = 'test_trailing_slash'\")\n        sys.path.append(self.path+'/')\n        mod = __import__(\"test_trailing_slash\")\n        self.assertEqual(mod.testdata, 'test_trailing_slash')\n        unload(\"test_trailing_slash\")\n\n    # Regression test for http://bugs.python.org/issue3677.\n    def _test_UNC_path(self):\n        with open(os.path.join(self.path, 'test_trailing_slash.py'), 'w') as f:\n            f.write(\"testdata = 'test_trailing_slash'\")\n        # Create the UNC path, like \\\\myhost\\c$\\foo\\bar.\n        path = os.path.abspath(self.path)\n        import socket\n        hn = socket.gethostname()\n        drive = path[0]\n        unc = \"\\\\\\\\%s\\\\%s$\"%(hn, drive)\n        unc += path[2:]\n        sys.path.append(path)\n        mod = __import__(\"test_trailing_slash\")\n        self.assertEqual(mod.testdata, 'test_trailing_slash')\n        unload(\"test_trailing_slash\")\n\n    if sys.platform == \"win32\":\n        test_UNC_path = _test_UNC_path\n\n\nclass RelativeImportTests(unittest.TestCase):\n\n    def tearDown(self):\n        unload(\"test.relimport\")\n    setUp = tearDown\n\n    def test_relimport_star(self):\n        # This will import * from .test_import.\n        from . import relimport\n        self.assertTrue(hasattr(relimport, \"RelativeImportTests\"))\n\n    def test_issue3221(self):\n        # Note for mergers: the 'absolute' tests from the 2.x branch\n        # are missing in Py3k because implicit relative imports are\n        # a thing of the past\n        #\n        # Regression test for htt", 4096) = 4096
read(3, "p://bugs.python.org/issue3221.\n        def check_relative():\n            exec(\"from . import relimport\", ns)\n\n        # Check relative import OK with __package__ and __name__ correct\n        ns = dict(__package__='test', __name__='test.notarealmodule')\n        check_relative()\n\n        # Check relative import OK with only __name__ wrong\n        ns = dict(__package__='test', __name__='notarealpkg.notarealmodule')\n        check_relative()\n\n        # Check relative import fails with only __package__ wrong\n        ns = dict(__package__='foo', __name__='test.notarealmodule')\n        self.assertRaises(SystemError, check_relative)\n\n        # Check relative import fails with __package__ and __name__ wrong\n        ns = dict(__package__='foo', __name__='notarealpkg.notarealmodule')\n        self.assertRaises(SystemError, check_relative)\n\n        # Check relative import fails with package set to a non-string\n        ns = dict(__package__=object())\n        self.assertRaises(ValueError, check_relative)\n\n    def test_absolute_import_without_future(self):\n        # If explicit relative import syntax is used, then do not try\n        # to perform an absolute import in the face of failure.\n        # Issue #7902.\n        with self.assertRaises(ImportError):\n            from .os import sep\n            self.fail(\"explicit relative import triggered an \"\n                      \"implicit absolute import\")\n\n\nclass OverridingImportBuiltinTests(unittest.TestCase):\n    def test_override_builtin(self):\n        # Test that overriding builtins.__import__ can bypass sys.modules.\n        import os\n\n        def foo():\n            import os\n            return os\n        self.assertEqual(foo(), os)  # Quick sanity check.\n\n        with swap_attr(builtins, \"__import__\", lambda *x: 5):\n            self.assertEqual(foo(), 5)\n\n        # Test what happens when we shadow __import__ in globals(); this\n        # currently does not impact the import process, but if this changes,\n        # other code will need to change, so keep this test as a tripwire.\n        with swap_item(globals(), \"__import__\", lambda *x: 5):\n            self.assertEqual(foo(), os)\n\n\nclass PycacheTests(unittest.TestCase):\n    # Test the various PEP 3147 related behaviors.\n\n    tag = imp.get_tag()\n\n    def _clean(self):\n        forget(TESTFN)\n        rmtree('__pycache__')\n        unlink(self.source)\n\n    def setUp(self):\n        self.source = TESTFN + '.py'\n        self._clean()\n        with open(self.source, 'w') as fp:\n            print('# This is a test file written by test_import.py', file=fp)\n        sys.path.insert(0, os.curdir)\n\n    def tearDown(self):\n        assert sys.path[0] == os.curdir, 'Unexpected sys.path[0]'\n        del sys.path[0]\n        self._clean()\n\n    def test_import_pyc_path(self):\n        self.assertFalse(os.path.exists('__pycache__'))\n        __import__(TESTFN)\n        self.assertTrue(os.path.exists('__pycache__'))\n        self.assertTrue(os.path.exists(os.path.join(\n            '__pycache__', '{}.{}.py{}'.format(\n            TESTFN, self.tag, __debug__ and 'c' or 'o'))))\n\n    @unittest.skipUnless(os.name == 'posix',\n                         \"test meaningful only on posix systems\")\n    def test_unwritable_directory(self):\n        # When the umask causes the new __pycache__ directory to be\n        # unwritable, the import still succeeds but no .pyc file is written.\n        with temp_umask(0o222):\n            __import__(TESTFN)\n        self.assertTrue(os.path.exists('__pycache__'))\n        self.assertFalse(os.path.exists(os.path.join(\n            '__pycache__', '{}.{}.pyc'.format(TESTFN, self.tag))))\n\n    def test_missing_source(self):\n        # With PEP 3147 cache layout, removing the source but leaving the pyc\n        # file does not satisfy the import.\n        __import__(TESTFN)\n        pyc_file = imp.cache_from_source(self.source)\n        self.assertTrue(os.path.exists(pyc_file))\n        os.remove(self.source)\n        forget(TESTFN)\n        self.assertRaises(ImportError, __import__, TESTFN)\n\n    def test_missing_source_legacy(self):\n        # Like test_missing_source() ", 4096) = 4096
read(3, "except that for backward compatibility,\n        # when the pyc file lives where the py file would have been (and named\n        # without the tag), it is importable.  The __file__ of the imported\n        # module is the pyc location.\n        __import__(TESTFN)\n        # pyc_file gets removed in _clean() via tearDown().\n        pyc_file = make_legacy_pyc(self.source)\n        os.remove(self.source)\n        unload(TESTFN)\n        m = __import__(TESTFN)\n        self.assertEqual(m.__file__,\n                         os.path.join(os.curdir, os.path.relpath(pyc_file)))\n\n    def test___cached__(self):\n        # Modules now also have an __cached__ that points to the pyc file.\n        m = __import__(TESTFN)\n        pyc_file = imp.cache_from_source(TESTFN + '.py')\n        self.assertEqual(m.__cached__, os.path.join(os.curdir, pyc_file))\n\n    def test___cached___legacy_pyc(self):\n        # Like test___cached__() except that for backward compatibility,\n        # when the pyc file lives where the py file would have been (and named\n        # without the tag), it is importable.  The __cached__ of the imported\n        # module is the pyc location.\n        __import__(TESTFN)\n        # pyc_file gets removed in _clean() via tearDown().\n        pyc_file = make_legacy_pyc(self.source)\n        os.remove(self.source)\n        unload(TESTFN)\n        m = __import__(TESTFN)\n        self.assertEqual(m.__cached__,\n                         os.path.join(os.curdir, os.path.relpath(pyc_file)))\n\n    def test_package___cached__(self):\n        # Like test___cached__ but for packages.\n        def cleanup():\n            rmtree('pep3147')\n        os.mkdir('pep3147')\n        self.addCleanup(cleanup)\n        # Touch the __init__.py\n        with open(os.path.join('pep3147', '__init__.py'), 'w'):\n            pass\n        with open(os.path.join('pep3147', 'foo.py'), 'w'):\n            pass\n        unload('pep3147.foo')\n        unload('pep3147')\n        m = __import__('pep3147.foo')\n        init_pyc = imp.cache_from_source(\n            os.path.join('pep3147', '__init__.py'))\n        self.assertEqual(m.__cached__, os.path.join(os.curdir, init_pyc))\n        foo_pyc = imp.cache_from_source(os.path.join('pep3147', 'foo.py'))\n        self.assertEqual(sys.modules['pep3147.foo'].__cached__,\n                         os.path.join(os.curdir, foo_pyc))\n\n    def test_package___cached___from_pyc(self):\n        # Like test___cached__ but ensuring __cached__ when imported from a\n        # PEP 3147 pyc file.\n        def cleanup():\n            rmtree('pep3147')\n        os.mkdir('pep3147')\n        self.addCleanup(cleanup)\n        unload('pep3147.foo')\n        unload('pep3147')\n        # Touch the __init__.py\n        with open(os.path.join('pep3147', '__init__.py'), 'w'):\n            pass\n        with open(os.path.join('pep3147', 'foo.py'), 'w'):\n            pass\n        m = __import__('pep3147.foo')\n        unload('pep3147.foo')\n        unload('pep3147')\n        m = __import__('pep3147.foo')\n        init_pyc = imp.cache_from_source(\n            os.path.join('pep3147', '__init__.py'))\n        self.assertEqual(m.__cached__, os.path.join(os.curdir, init_pyc))\n        foo_pyc = imp.cache_from_source(os.path.join('pep3147', 'foo.py'))\n        self.assertEqual(sys.modules['pep3147.foo'].__cached__,\n                         os.path.join(os.curdir, foo_pyc))\n\n\nclass RelativeImportFromImportlibTests(test_relative_imports.RelativeImports):\n\n    def setUp(self):\n        self._importlib_util_flag = importlib_util.using___import__\n        importlib_util.using___import__ = True\n\n    def tearDown(self):\n        importlib_util.using___import__ = self._importlib_util_flag\n\n\ndef test_main(verbose=None):\n    run_unittest(ImportTests, PycacheTests,\n                 PycRewritingTests, PathsTests, RelativeImportTests,\n                 OverridingImportBuiltinTests,\n                 RelativeImportFromImportlibTests)\n\n\nif __name__ == '__main__':\n    # Test needs to be a package, so we can do relative imports.\n    from test.test_import import test_main\n    test_main()\n", 4096) = 4052
read(3, "", 4096)                       = 0
close(3)                                = 0
write(1, "FAIL\ntest_basics (test.test_import.PycRewritingTests) ... ", 58FAIL

----------
messages: 134781
nosy: Jason.Vas.Dias
priority: normal
severity: normal
status: open
title: 3.3 : test_import.py causes 'make test' to fail

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11956>
_______________________________________

From report at bugs.python.org  Fri Apr 29 18:21:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Apr 2011 16:21:31 +0000
Subject: [issue10761] tarfile.extractall fails to overwrite symlinks
In-Reply-To: <1293063436.61.0.0994372418071.issue10761@psf.upfronthosting.co.za>
Message-ID: <1304094091.98.0.0131315570405.issue10761@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Senthil, Windows buildbots on 3.1, 3.2 and 3.x show test failures.
See e.g. http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.1/builds/1780/steps/test/logs/stdio

----------
assignee: lars.gustaebel -> orsenthil
nosy: +pitrou
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10761>
_______________________________________

From report at bugs.python.org  Fri Apr 29 18:21:50 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 16:21:50 +0000
Subject: [issue11956] 3.3 : test_import.py causes 'make test' to fail
In-Reply-To: <1304094086.01.0.944392387954.issue11956@psf.upfronthosting.co.za>
Message-ID: <1304094110.1.0.397405999395.issue11956@psf.upfronthosting.co.za>


Changes by Jason Vas Dias <jason.vas.dias at gmail.com>:


----------
components: +Build
type:  -> crash
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11956>
_______________________________________

From report at bugs.python.org  Fri Apr 29 18:26:58 2011
From: report at bugs.python.org (Floris Bruynooghe)
Date: Fri, 29 Apr 2011 16:26:58 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1304093795.3587.7.camel@localhost.localdomain>
Message-ID: <BANLkTi=hAYpBif4fWtaQOWbxa_ugZLxNOg@mail.gmail.com>


Floris Bruynooghe <floris.bruynooghe at gmail.com> added the comment:

On 29 April 2011 17:16, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
>> Yes, I was probably not clear:
>> When --with-dlmalloc is activated, PyMem_MALLOC/PyMem_Malloc will call
>> dlmalloc, PyMem_REALLOC/PyMem_Realloc will call dlrealloc and
>> PyMem_FREE/PyMem_Free will call dlfree.
>>
>> While calls to malloc/free/realloc will use the platform implementation.
>
> I'm not sure why you would want that. If dlmalloc is clearly superior,
> why not use it for all allocations inside the application (not only
> Python ones)?

For the same reason that extension modules can choose between
PyMem_Malloc and plain malloc (or whatever else).  Python has never
forced it's malloc on extension modules why should it now?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Fri Apr 29 18:31:24 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 16:31:24 +0000
Subject: [issue11956] 3.3 : test_import.py causes 'make test' to fail
In-Reply-To: <1304094086.01.0.944392387954.issue11956@psf.upfronthosting.co.za>
Message-ID: <1304094684.75.0.0118653726845.issue11956@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

So, in the statement that fails :

self.assertFalse(os.path.exists(os.path.join(...))) .

either self.assertFalse is failing or os.path.exists is failing 
or os.path.join is failing.

The fact that the error message is 'AssertionError: True is not false'
suggests that os.path.exists is returning True . 

So how can this be if we see only 'ENOENT' errors for every file
that is a target of unlink() between the umask() and the write of
"FAIL\n..." ?

I think that this suggests that os.path.exists is failing for this build.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11956>
_______________________________________

From report at bugs.python.org  Fri Apr 29 18:36:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Apr 2011 16:36:39 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <BANLkTi=hAYpBif4fWtaQOWbxa_ugZLxNOg@mail.gmail.com>
Message-ID: <1304094994.3587.9.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> For the same reason that extension modules can choose between
> PyMem_Malloc and plain malloc (or whatever else).  Python has never
> forced it's malloc on extension modules why should it now?

We're talking about a platform-specific feature request due to the fact
that dlmalloc is (supposedly) superior to AIX malloc(). If it's superior
than I don't see any *practical* reason not to want to use it for other
purposes than allocating Python objects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Fri Apr 29 18:40:39 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 29 Apr 2011 16:40:39 +0000
Subject: [issue11950] logger use dict for loggers instead of
	WeakValueDictionary
In-Reply-To: <1304018959.77.0.656415451022.issue11950@psf.upfronthosting.co.za>
Message-ID: <1304095239.1.0.00337454202502.issue11950@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

It sounds to me as if there's a problem in yum that needs sorting out: I'm not sure why it would need dozens of loggers.

As your workaround snippet shows, leaking files is not due to loggers but due to handlers - they're a different animal. Handlers need not be leaked - they can just be closed when you're done with them. Handlers *are* stored in with weak references.

The design contract for loggers precludes using weak references for them. For example, if I use a library and from my logging initialization code get a reference to its top-level logger and e.g. set that logger's level, then when I've finished, there may not be any other references to that logger until I do an import of some library module. I wouldn't want the reference to the logger to go away, because then the library wouldn't know my intention regarding the level setting.

Normal practice would be to add a few handlers to yum's top-level logger and let descendant loggers inherit them. I'm not familiar with yum, so I don't know if/why it deviates from this common and best practice approach.

As you state, replacing {} with WeakValueDictionary() wouldn't solve the problem, and would the design assumptions/contract relating to loggers.

By the way the logging module does not store loggers in lists and dicts - just in a single dict in a manager. Handlers are stored in weak reference dicts as well as lists but that does not mean they are guaranteed to be garbage collected, since there could also be references to them in user code.

I don't know if you are just a yum user or a yum developer - in the latter case I'll be happy to work with you to look at yum's use of logging, and in the former case, feel free to post on yum mailing lists to the effect that I am willing to work with yum developers to improve the situation.

So I'll close this issue as invalid for the reasons given above, but I'm happy to work with yum developers to improve the situation you're experiencing. If in the course of doing that we find some way to improve the implementation of logging (in a backwards-compatible way, of course) then that's fine.

----------
assignee:  -> vinay.sajip
nosy: +vinay.sajip
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11950>
_______________________________________

From report at bugs.python.org  Fri Apr 29 18:41:36 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 29 Apr 2011 16:41:36 +0000
Subject: [issue11950] logger use dict for loggers instead of
	WeakValueDictionary
In-Reply-To: <1304018959.77.0.656415451022.issue11950@psf.upfronthosting.co.za>
Message-ID: <1304095296.46.0.981961495412.issue11950@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
Removed message: http://bugs.python.org/msg134786

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11950>
_______________________________________

From report at bugs.python.org  Fri Apr 29 18:47:31 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 16:47:31 +0000
Subject: [issue11956] 3.3 : test_import.py causes 'make test' to fail
In-Reply-To: <1304094086.01.0.944392387954.issue11956@psf.upfronthosting.co.za>
Message-ID: <1304095651.33.0.951186187761.issue11956@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

oops, no sorry it was this bit from the strace log :

umask(0222)                             = 022
stat("./@test_9634_tmp", 0x7fff7ef64130) = -1 ENOENT (No such file or directory)
open("./@test_9634_tmp.cpython-33m.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("./@test_9634_tmpmodule.cpython-33m.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("./@test_9634_tmp.abi3.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("./@test_9634_tmpmodule.abi3.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("./@test_9634_tmp.so", O_RDONLY)   = -1 ENOENT (No such file or directory)
open("./@test_9634_tmpmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("./@test_9634_tmp.py", O_RDONLY)   = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=48, ...}) = 0
open("./__pycache__/@test_9634_tmp.cpython-32.pyc", O_RDONLY) = -1 ENOENT (No such file or directory)
fstat(3, {st_mode=S_IFREG|0644, st_size=48, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd261c4a000
read(3, "# This is a test file written by test_import.py\n", 4096) = 48
read(3, "", 4096)                       = 0
mkdir("./__pycache__", 0100777)         = 0
unlink("./__pycache__/@test_9634_tmp.cpython-32.pyc") = -1 ENOENT (No such file or directory)
open("./__pycache__/@test_9634_tmp.cpython-32.pyc", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0100644) = 4
fcntl(4, F_GETFL)                       = 0x8001 (flags O_WRONLY|O_LARGEFILE)
fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd261c49000
lseek(4, 0, SEEK_CUR)                   = 0
write(4, "l\f\r\n\0\0\0\0c\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0@\0\0\0s\4\0\0\0d\0\0S(\1\0\0\0N(\0\0\0\0(\0\0\0\0(\0\0\0\0(\0\0\0\0u\23\0\0\0./@test_9634_tmp.pyu\10\0\0\0<module>\1\0\0\0s\0\0\0\0", 110) = 110
lseek(4, 4, SEEK_SET)                   = 4
write(4, "?\342\272M", 4)               = 4
close(4)                                = 0
munmap(0x7fd261c49000, 4096)            = 0
close(3)                                = 0
munmap(0x7fd261c4a000, 4096)            = 0
umask(022)                              = 0222
stat("__pycache__", {st_mode=S_IFDIR|S_ISGID|0555, st_size=4096, ...}) = 0
stat("__pycache__/@test_9634_tmp.cpython-32.pyc", {st_mode=S_IFREG|0444, st_size=110, ...}) = 0


So the test succeeds ; ie. is correctly detecting being able to
create a file in a directory with umask 0222 ; I think if you
are the super-user (root) - and I am - w bits on directories
owned by root are ignored - double-checking this now.

So I think the fix is simply to say : if I am root user, skip this test,
because it will always fail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11956>
_______________________________________

From report at bugs.python.org  Fri Apr 29 18:48:26 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 29 Apr 2011 16:48:26 +0000
Subject: [issue11950] logger use dict for loggers instead of
	WeakValueDictionary
In-Reply-To: <1304018959.77.0.656415451022.issue11950@psf.upfronthosting.co.za>
Message-ID: <1304095706.72.0.567265130559.issue11950@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I had to delete my previous response to the initial post, as something got mangled in it. Here's what I meant to say:
----------------------------------------------
It sounds to me as if there's a problem in yum that needs sorting out: I'm not sure why it would need dozens of loggers.

As your workaround snippet shows, leaking files is not due to loggers but due to handlers - they're a different animal. Handlers need not be leaked - they can just be closed when you're done with them. Handlers *are* stored with weak references.

The design contract for loggers precludes using weak references for them. For example, if I use a library and from my logging initialization code get a reference to its top-level logger and e.g. set that logger's level, then when I've finished, there may not be any other references to that logger until I do an import of some library module. I wouldn't want the reference to the logger to go away, because then the library wouldn't know my intention regarding the level setting.

Normal practice would be to add a few handlers to yum's top-level logger and let descendant loggers inherit them. I'm not familiar with yum, so I don't know if/why it deviates from this common and best practice approach.

As you state, replacing {} with WeakValueDictionary() wouldn't solve the problem, and would violate the design assumptions/contract relating to loggers.

By the way, the logging module does not store loggers in lists and dicts - just in a single dict in a manager. Handlers are stored in weak reference dicts as well as lists but that does not mean they are guaranteed to be garbage collected, since there could also be references to them in user code. Likewise for loggers - typically there would be references to them in lines like

logger = logging.getLogger(__name__)

in numerous modules. Even if yum consists of dozens of modules (which perhaps explains dozens of loggers), they needn't leak files, as just adding a single FileHandler to yum's top-level logger would serve to capture logging events from the entire yum package hierarchy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11950>
_______________________________________

From report at bugs.python.org  Fri Apr 29 19:06:16 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 17:06:16 +0000
Subject: [issue11956] 3.3 : test_import.py causes 'make test' to fail
In-Reply-To: <1304094086.01.0.944392387954.issue11956@psf.upfronthosting.co.za>
Message-ID: <1304096776.65.0.374085231836.issue11956@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

Aha ! Yes, the test DOES succeed as a non-root user , and yes,
if you are super user you can override any write bits in
directory permissions if you own the directory.

So the fix ? : skip 'unwritable_directory' test if you are root -
here's the patch

----------
keywords: +patch
Added file: http://bugs.python.org/file21835/bug_11956.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11956>
_______________________________________

From report at bugs.python.org  Fri Apr 29 19:09:19 2011
From: report at bugs.python.org (David Kirkby)
Date: Fri, 29 Apr 2011 17:09:19 +0000
Subject: [issue1759169] clean up Solaris port and allow C99 extension modules
Message-ID: <1304096959.94.0.538060412626.issue1759169@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

Is there any progress on this? I see it is marked as 

Status: closed
Resolution: accepted
Stage: patch review
    

That apparently means:

''There is a patch, but it needs reviewing or is in the process of being reviewed. This can be done by any triager as well as a core developer.''

So is there any movement on this, which will allow it to be fixed? 

I'm somewhat puzzled the Status is marked as "closed" when apparently the patch is still awaiting review. 

Dave

----------
nosy: +drkirkby

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1759169>
_______________________________________

From report at bugs.python.org  Fri Apr 29 19:12:43 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 29 Apr 2011 17:12:43 +0000
Subject: [issue11924] Pickle and copyreg modules don't document the interface
In-Reply-To: <1303766863.75.0.154822649898.issue11924@psf.upfronthosting.co.za>
Message-ID: <1304097163.73.0.124735212534.issue11924@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11924>
_______________________________________

From report at bugs.python.org  Fri Apr 29 19:12:58 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 29 Apr 2011 17:12:58 +0000
Subject: [issue11955] 3.3 : test_argparse.py fails 'make test'
In-Reply-To: <1304093741.94.0.09129303291.issue11955@psf.upfronthosting.co.za>
Message-ID: <1304097178.02.0.291912940559.issue11955@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
components: +Tests -Build
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11955>
_______________________________________

From report at bugs.python.org  Fri Apr 29 19:13:19 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 29 Apr 2011 17:13:19 +0000
Subject: [issue11945] Adopt and document consistent semantics for handling NaN
	values in containers
In-Reply-To: <1303962145.0.0.00759154980454.issue11945@psf.upfronthosting.co.za>
Message-ID: <1304097199.24.0.996485380461.issue11945@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11945>
_______________________________________

From report at bugs.python.org  Fri Apr 29 19:13:37 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 29 Apr 2011 17:13:37 +0000
Subject: [issue11956] 3.3 : test_import.py causes 'make test' to fail
In-Reply-To: <1304094086.01.0.944392387954.issue11956@psf.upfronthosting.co.za>
Message-ID: <1304097217.89.0.755527355755.issue11956@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
components: +Tests -Build
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11956>
_______________________________________

From report at bugs.python.org  Fri Apr 29 19:13:38 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 29 Apr 2011 17:13:38 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1304097218.34.0.124650710602.issue11949@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________

From report at bugs.python.org  Fri Apr 29 19:14:05 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 29 Apr 2011 17:14:05 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304097245.91.0.553671812002.issue11954@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
components: +Tests -Build
nosy:  -brian.curtin
type: crash -> behavior
versions: +Python 3.3 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 19:14:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Apr 2011 17:14:33 +0000
Subject: [issue1759169] clean up Solaris port and allow C99 extension modules
Message-ID: <1304097273.56.0.325384174269.issue1759169@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As noted by Martin above (he quoted the Subversion revision numbers), this was actually fixed.

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1759169>
_______________________________________

From report at bugs.python.org  Fri Apr 29 19:16:00 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 17:16:00 +0000
Subject: [issue11955] 3.3 : test_argparse.py fails 'make test'
In-Reply-To: <1304093741.94.0.09129303291.issue11955@psf.upfronthosting.co.za>
Message-ID: <1304097360.82.0.0414698644633.issue11955@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

Aha ! the test succeeds as a non root (super-) user .
This is because as a root user I can override w bit
settings on directories I own: see issue #11956 
for fix I applied to test_import.py to fix same
issue. Thanks !

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11955>
_______________________________________

From report at bugs.python.org  Fri Apr 29 19:18:50 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 Apr 2011 17:18:50 +0000
Subject: [issue11955] 3.3 : test_argparse.py fails 'make test'
In-Reply-To: <1304093741.94.0.09129303291.issue11955@psf.upfronthosting.co.za>
Message-ID: <1304097530.84.0.323761953794.issue11955@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The six error messages tell you that six different tests failed.  Yes, the failures are probably all due to the same cause, but that's just how unit testing works.  (And yes, the argparse tests are a bit more terse and difficult to understand than many of our tests, but that is because they are trying to economically test a lot of different edge cases.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11955>
_______________________________________

From report at bugs.python.org  Fri Apr 29 19:19:54 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Fri, 29 Apr 2011 17:19:54 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
Message-ID: <1304097594.15.0.0778335617686.issue3526@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Even worse than that, mixing to malloc implementations could lead to trouble.
For example, the trimming code ensures that the heap is where it last set it. So if an allocation has been made by another implementation in the meantime, the heap won't be trimmed, and your memory usage won't decrease. Also, it'll increase memory fragmentation.
Finally, I've you've got two threads inside different malloc implementations at the same time, well, some really bad things could happen.
And there are probably many other reasons why it's a bad idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Fri Apr 29 19:20:30 2011
From: report at bugs.python.org (Daniel Holth)
Date: Fri, 29 Apr 2011 17:20:30 +0000
Subject: [issue11921] distutils2 should be able to compile an Extension based
	on the Python implementation version
In-Reply-To: <1303750597.71.0.868083563179.issue11921@psf.upfronthosting.co.za>
Message-ID: <1304097630.4.0.260229704066.issue11921@psf.upfronthosting.co.za>


Daniel Holth <dholth at fastmail.fm> added the comment:

from docs.python.org:

platform.python_implementation()

    Returns a string identifying the Python implementation. Possible return values are: ?CPython?, ?IronPython?, ?Jython?.

    New in version 2.6.

... and it seems pypy identifies itself as 'PyPy'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11921>
_______________________________________

From report at bugs.python.org  Fri Apr 29 19:24:55 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Fri, 29 Apr 2011 17:24:55 +0000
Subject: [issue11247] Error sending packets to multicast IPV4 address
In-Reply-To: <1298087823.89.0.505533825955.issue11247@psf.upfronthosting.co.za>
Message-ID: <1304097895.31.0.986227286014.issue11247@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Closing as invalid, since it's definitely not a Python issue, but much more likely a network configuration problem.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11247>
_______________________________________

From report at bugs.python.org  Fri Apr 29 19:32:11 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 29 Apr 2011 17:32:11 +0000
Subject: [issue11887] unittest fails on comparing str with bytes if python has
	the -bb option
In-Reply-To: <1303313753.3.0.8744280471.issue11887@psf.upfronthosting.co.za>
Message-ID: <1304098331.25.0.39217492943.issue11887@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11887>
_______________________________________

From report at bugs.python.org  Fri Apr 29 19:38:00 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 29 Apr 2011 17:38:00 +0000
Subject: [issue11786] ConfigParser.[Raw]ConfigParser optionxform()
In-Reply-To: <1302110277.82.0.57770456199.issue11786@psf.upfronthosting.co.za>
Message-ID: <1304098680.17.0.342946807913.issue11786@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Sorry about that. Since I'm not technically touching the source code, I thought the security fixes restriction does not necessarily apply. Especially that my patch only updates what ends up here:

http://docs.python.org/release/2.6.6/library/configparser.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11786>
_______________________________________

From report at bugs.python.org  Fri Apr 29 19:38:15 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Fri, 29 Apr 2011 17:38:15 +0000
Subject: [issue11344] Add os.path.splitpath(path) function
In-Reply-To: <1298795208.87.0.771920756626.issue11344@psf.upfronthosting.co.za>
Message-ID: <1304098695.87.0.738261284363.issue11344@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11344>
_______________________________________

From report at bugs.python.org  Fri Apr 29 19:54:59 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 17:54:59 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304099699.79.0.647334956227.issue11954@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

OK, so those test_argparse.py and test_import.py tests succeed if run
as a non-root user , because as the super-user one is allowed to
override mode 0300 ( lack of 'w' bit for owner ) on a directory ,
so some tests that check if they are unable to create files when
directory 'w' permissions would not allow this for a non-root 
user fail .

I think if users are not meant to be running the test scripts as root,
then the first thing the test suite should do is :

    if os.getuid() == 0 :
       print( "The test suite will fail if run as the super-user." )
       sys.exit(1)  # or is it os.exit ? I forget ...

But if, as I hope, you will allow the root user to run the test suite,
then please skip tests that test if a non-root user shouldn't be
allowed to do something as I did for the patch attached to issue #11956 :
       @unittest.skipUnless( (os.name == 'posix') and not ( os.getuid() == 0 ),
                         "test meaningful only on posix systems as non-root user")
    def test_unwritable_directory(self):
...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 19:57:09 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 17:57:09 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304099829.62.0.973232019703.issue11954@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

argparse.py needs a similar fix, but I'm not sure where - I raised
issue #11955 on this .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 20:02:47 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 18:02:47 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304100167.43.0.404408969604.issue11954@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

hmm... not sure if "make test" completely succeeds as non-root user yet:
"test_subprocess" has been sitting in this state for @ 30mins :

[282/354] test_subprocess
.
    this bit of output is from a test of stdout in a different process ...

and is getting rather large ( 'top' output for process ) :

20092 jason     21   1  549m 251m 7392 R   45 15.0   5:46.73 python            

how long is 'test_subprocess' meant to take ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 20:03:50 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 29 Apr 2011 18:03:50 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304100230.3.0.949218335164.issue11954@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 20:08:30 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 18:08:30 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304100510.35.0.990749265591.issue11954@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

Nope, all tests except rpm dependant test_distutils OK as non-root 
with the patch I submitted for #11956 - so I guess that's good
enough .
Please fix the python 'make test' to work when run as root user .
Thank You!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 20:12:09 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 18:12:09 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304100729.82.0.822837010401.issue11954@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

One last niggle : when I do 
$ DESTDIR=`pwd`/inst make install

The configure '--libdir=/usr/lib64' setting I specified is ignored
and python installs itself under /usr/lib . I guess I need to raise
a different bug on this ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 20:17:45 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 Apr 2011 18:17:45 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304101065.83.0.441005407833.issue11954@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

test_distutils should not be dependent on the existence of rpm (if it references the system rpm it should skip if it doesn't exist).

It is difficult to find someone willing to run a buildbot as the root user, so while we will see about fixing the test suite to run as the root user, it may get broken again by and by unintentionally.

Thanks for figuring out what was going wrong.

I think there may already be an open bug for your last niggle, you might search the tracker to check.  I know there is an open question about what to do about /usr/lib64.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11954>
_______________________________________

From report at bugs.python.org  Fri Apr 29 20:23:20 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Fri, 29 Apr 2011 18:23:20 +0000
Subject: [issue11921] distutils2 should be able to compile an Extension
	based	on the Python implementation version
In-Reply-To: <1304097630.4.0.260229704066.issue11921@psf.upfronthosting.co.za>
Message-ID: <4DBB0216.8040802@notmyidea.org>


Alexis Metaireau <alexis at notmyidea.org> added the comment:

On 29/04/2011 18:20, Daniel Holth wrote:
>      New in version 2.6.

Yep that's it. We would need to backport it in the python2 port of 
packaging (namely distutils2), but it would do the trick.

I just started a discussion about that on the fellowship (to know if we 
can add this to PEP 345).
-- 
Alexis

----------
title: distutils2 should be able to compile an Extension based on the Python implementation version -> distutils2 should be able to compile an Extension based	on the Python implementation version

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11921>
_______________________________________

From report at bugs.python.org  Fri Apr 29 20:27:10 2011
From: report at bugs.python.org (Mindaugas)
Date: Fri, 29 Apr 2011 18:27:10 +0000
Subject: [issue11957] re.sub problem with unicode string
In-Reply-To: <1304101630.86.0.175815070517.issue11957@psf.upfronthosting.co.za>
Message-ID: <1304101630.86.0.175815070517.issue11957@psf.upfronthosting.co.za>


New submission from Mindaugas <mindaugas.rucys at gmail.com>:

re.sub don't substitute not ASCII characters:

Python 2.7.1 (r271:86832, Apr 15 2011, 12:11:58) Arch Linux

>>>import re

>>>a=u'aaa'
>>>print re.search('(\w+)',a,re.U).groups()
(u'aaa')
>>>print re.sub('(\w+)','x',a,re.U)
x

      BUT:

>>>a=u'???'
>>>print re.search('(\w+)',a,re.U).groups()
(u'\u0105\u0105\u0105')
>>>print re.sub('(\w+)','x',a,re.U)
???

----------
components: Regular Expressions, Unicode
messages: 134806
nosy: mindauga
priority: normal
severity: normal
status: open
title: re.sub problem with unicode string
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11957>
_______________________________________

From report at bugs.python.org  Fri Apr 29 20:39:00 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 29 Apr 2011 18:39:00 +0000
Subject: [issue11950] logger use dict for loggers instead of
	WeakValueDictionary
In-Reply-To: <1304018959.77.0.656415451022.issue11950@psf.upfronthosting.co.za>
Message-ID: <1304102340.07.0.213374923333.issue11950@psf.upfronthosting.co.za>


???? ????????? <socketpair at gmail.com> added the comment:

I'm not YUM developer, I'm very sad user of YUM API. Also, I'm novice in python logging complex system.

1. There is no way to remove logger once it added via getLogger(). why?
2. When yum should close handlers? In destructor (cleanup function) of module?
3. Why this code does not close log files?
----------------
def test():
    import yum
    # work with yum

test()
gc.collect() # to sure that nothing have extra references.
# yum logs still alive in spite of that yum module (and imported logging module) 'is unloaded'
-----------------
3. Also, logger.handlers is not documented...it's definitely the bug as I think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11950>
_______________________________________

From report at bugs.python.org  Fri Apr 29 21:10:18 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 29 Apr 2011 19:10:18 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
Message-ID: <1304104218.69.0.807559566999.issue3526@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I share the opinion of Floris on this: just because you link your application with python does not mean you want it to handle all memory management.

If you want the memory to be handled by Python, you should call PyMem_Malloc.

Otherwise people may want to use different malloc implementations in different parts of their application/libraries for different reasons (dmalloc for debugging http://dmalloc.com/ for example - we have seen that libffi bundles its own dlmalloc - someone may prefer a derivative of ptmalloc for performance reasons with threads...).

My application is linked with various libraries including libpython, glib and gmp, and I sometimes like to be able to distinguish how much memory is allocated by which library for profiling/debugging purpose for example.

I don't understand the point concerning trimming/fragmentation/threading by Charles-Francois: dlmalloc will allocate its own memory segment using mmap and handle memory inside that segment when you do a dlmalloc/dlfree/dlrealloc. Other malloc implementations will work in their own separate space and so won't impact or be impacted by what happens in dlmalloc segments.

dlmalloc is not that much different from pymalloc in that regard: it handles its own memory pool on top of the system memory implementations.
Yet you can have an application that uses the ordinary malloc while calling some Python code which uses pymalloc without any trimming/fragmentation/threading issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Fri Apr 29 22:03:51 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 29 Apr 2011 20:03:51 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1304107431.25.0.486745152338.issue11948@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi Raymond, thanks for looking into it! What do you think of this patch? I tried to save what I think was nice in the first paragraph and collapse it into the second one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Fri Apr 29 22:04:16 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 29 Apr 2011 20:04:16 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1304107456.89.0.344601049735.issue11948@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


Added file: http://bugs.python.org/file21836/issue11948.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Fri Apr 29 23:01:07 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Fri, 29 Apr 2011 21:01:07 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1304104218.69.0.807559566999.issue3526@psf.upfronthosting.co.za>
Message-ID: <BANLkTinpi_qM3OFy-iO6=HNo=689yUuySw@mail.gmail.com>


Charles-Francois Natali <neologix at free.fr> added the comment:

> I don't understand the point concerning trimming/fragmentation/threading by
> Charles-Francois: dlmalloc will allocate its own memory segment using mmap
> and handle memory inside that segment when you do a
> dlmalloc/dlfree/dlrealloc. Other malloc implementations will work in their
> own separate space and so won't impact or be impacted by what happens in
> dlmalloc segments.

Most of the allocations come from the heap - through sbrk - which is a
shared resource, and is a contiguous space. mmap is only used for big
allocations.

>
> dlmalloc is not that much different from pymalloc in that regard: it handles
> its own memory pool on top of the system memory implementations.
> Yet you can have an application that uses the ordinary malloc while calling
> some Python code which uses pymalloc without any
> trimming/fragmentation/threading issues.

It's completely different. Pymalloc is used *on top* of libc's malloc,
while dlmalloc would be be used in parallel.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Fri Apr 29 23:08:01 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Fri, 29 Apr 2011 21:08:01 +0000
Subject: [issue11958] test.test_ftplib.TestIPv6Environment failure
In-Reply-To: <1304111281.72.0.014569295805.issue11958@psf.upfronthosting.co.za>
Message-ID: <1304111281.72.0.014569295805.issue11958@psf.upfronthosting.co.za>


New submission from Charles-Francois Natali <neologix at free.fr>:

test_ftplib fails in TestIPv6Environment:

======================================================================
ERROR: test_makepasv (test.test_ftplib.TestIPv6Environment)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cf/cpython/Lib/test/test_ftplib.py", line 651, in setUp
    self.server = DummyFTPServer((HOST, 0), af=socket.AF_INET6)
  File "/home/cf/cpython/Lib/test/test_ftplib.py", line 220, in __init__
    self.bind(address)
  File "/home/cf/cpython/Lib/asyncore.py", line 339, in bind
    return self.socket.bind(addr)
socket.gaierror: [Errno -2] Name or service not known

======================================================================
ERROR: test_transfer (test.test_ftplib.TestIPv6Environment)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cf/cpython/Lib/test/test_ftplib.py", line 651, in setUp
    self.server = DummyFTPServer((HOST, 0), af=socket.AF_INET6)
  File "/home/cf/cpython/Lib/test/test_ftplib.py", line 220, in __init__
    self.bind(address)
  File "/home/cf/cpython/Lib/asyncore.py", line 339, in bind
    return self.socket.bind(addr)
socket.gaierror: [Errno -2] Name or service not known

----------------------------------------------------------------------
Ran 74 tests in 6.595s

FAILED (errors=2)
test test_ftplib failed -- multiple errors occurred
1 test failed:
    test_ftplib

The reason is that support.HOST is 'localhost'. and on most machines, localhost is an alias for 127.0.0.1, and not the IPv6 loopback, so the address resolution fails.
One possible solution is simply to pass ::1 (IPv6 loopback address) instead of support.HOST.
Patch attached.

----------
components: Tests
files: test_ftplib_ipv6.diff
keywords: patch
messages: 134811
nosy: giampaolo.rodola, neologix
priority: normal
severity: normal
status: open
title: test.test_ftplib.TestIPv6Environment failure
type: behavior
Added file: http://bugs.python.org/file21837/test_ftplib_ipv6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11958>
_______________________________________

From report at bugs.python.org  Fri Apr 29 23:12:30 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 29 Apr 2011 21:12:30 +0000
Subject: [issue11959] smtpd cannot be used without affecting global state
In-Reply-To: <1304111550.3.0.684224980767.issue11959@psf.upfronthosting.co.za>
Message-ID: <1304111550.3.0.684224980767.issue11959@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

It seems not possible to use smtpd in certain contexts, because it forces use of global state. For example, I'm looking at implementing a test SMTP server to test logging's SMTPHandler. Neither SMTPServer nor SMTPChannel allow a map to be passed in, forcing use of the global socket_map in asyncore. Both of these classes should accept an optional map argument - the map passed to SMTPServer should be stored in the server instance and passed when creating an SMTPChannel in handle_accepted.

----------
components: Library (Lib)
messages: 134812
nosy: giampaolo.rodola, vinay.sajip
priority: normal
severity: normal
status: open
title: smtpd cannot be used without affecting global state
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11959>
_______________________________________

From report at bugs.python.org  Fri Apr 29 23:29:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Apr 2011 21:29:17 +0000
Subject: [issue7838] Undocumented subprocess functions on Windows
In-Reply-To: <1265130024.2.0.807929500007.issue7838@psf.upfronthosting.co.za>
Message-ID: <E1QFvFU-00048V-6X@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 80971f71b0d9 by Brian Curtin in branch '3.1':
Further fix #7838. CREATE_NEW_CONSOLE was exposed, but none of the
http://hg.python.org/cpython/rev/80971f71b0d9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7838>
_______________________________________

From report at bugs.python.org  Fri Apr 29 23:40:03 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 Apr 2011 21:40:03 +0000
Subject: [issue11912] Python shouldn't use the mprotect() system call
In-Reply-To: <1303601985.39.0.925824346967.issue11912@psf.upfronthosting.co.za>
Message-ID: <1304113203.03.0.784497516441.issue11912@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Is there any reason not to close this as a CPython issue?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11912>
_______________________________________

From report at bugs.python.org  Fri Apr 29 23:50:29 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 Apr 2011 21:50:29 +0000
Subject: [issue11959] smtpd cannot be used without affecting global state
In-Reply-To: <1304111550.3.0.684224980767.issue11959@psf.upfronthosting.co.za>
Message-ID: <1304113829.82.0.653906169944.issue11959@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/issue11959>
_______________________________________

From report at bugs.python.org  Sat Apr 30 00:06:29 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 Apr 2011 22:06:29 +0000
Subject: [issue11928] fail on filename with space at the end
In-Reply-To: <1303836707.17.0.285457821827.issue11928@psf.upfronthosting.co.za>
Message-ID: <1304114789.74.0.722990093665.issue11928@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Windows Explorer does not so allow, but yes, Windows does. With xp
>>> os.stat('some file ')
nt.stat_result(st_mode=33206, st_ino=6473924464520118, st_dev=0, st_nlink=1, st_uid=0, st_gid=0, st_size=13, st_atime=1304114221, st_mtime=1304114055, st_ctime=1304113961)

Same with full path.

I would go into distutils\filelist.py and print(repr(fullname)) just before the os.stat call to see if there is anything strange. Maybe also try same call interactively like I did above, outside disutils context.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11928>
_______________________________________

From report at bugs.python.org  Sat Apr 30 00:12:41 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Apr 2011 22:12:41 +0000
Subject: [issue10761] tarfile.extractall fails to overwrite symlinks
In-Reply-To: <1293063436.61.0.0994372418071.issue10761@psf.upfronthosting.co.za>
Message-ID: <E1QFvvT-0007Gu-6r@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 2665a28643b8 by Senthil Kumaran in branch 'default':
Wrap the correct test with the skip decorator for the issue10761.
http://hg.python.org/cpython/rev/2665a28643b8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10761>
_______________________________________

From report at bugs.python.org  Sat Apr 30 00:14:41 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 29 Apr 2011 22:14:41 +0000
Subject: [issue10761] tarfile.extractall fails to overwrite symlinks
In-Reply-To: <1304094091.98.0.0131315570405.issue10761@psf.upfronthosting.co.za>
Message-ID: <20110429221433.GA2681@kevin>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I had wrapped skipUnless decorator for the wrong test (test_extractall
instead of test_extractall_symlinks) in the 3.x code.  Corrected it
and waiting for next bb reports.

Thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10761>
_______________________________________

From report at bugs.python.org  Sat Apr 30 00:42:52 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 29 Apr 2011 22:42:52 +0000
Subject: [issue11206] test_readline unconditionally calls clear_history()
In-Reply-To: <1297592798.04.0.448231212835.issue11206@psf.upfronthosting.co.za>
Message-ID: <1304116972.28.0.165907179406.issue11206@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for noticing!

----------
nosy: +ned.deily
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> test_readline fails when readline was installed after running configure (and was not re-run)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11206>
_______________________________________

From report at bugs.python.org  Sat Apr 30 00:57:19 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 Apr 2011 22:57:19 +0000
Subject: [issue11937] Interix support
In-Reply-To: <1303911825.14.0.5833510557.issue11937@psf.upfronthosting.co.za>
Message-ID: <1304117839.24.0.285254706231.issue11937@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Markus, I agree with Martin that this patch would go against current policy and should be closed. Rather than close it myself, I will try to persuade you to do so.

First, CPython is actually in the process of 'slimming down', of removing, not adding support for minority platforms. Please look at
ttp://python.org/dev/peps/pep-0011/
and notice that support for 5 types of systems has been removed for 3.3 and 2 more are slated for removal in 3.4.

Second, buildbots are intended to be remote slaves of the master. When they finish one build, test, and report, there is (or soon will be) usually another version ready to test. I am pretty sure that does not work behind a corparate firewall. In any case, if you want to use a machine for anything else, you are better with a script that pulls, builds, and tests when *you* decide. Also, buildbots are usually dedicated to one version. You might want to test your patch with multiple versions.

Third, if you keep the code, then no one else can mess with it, even accidentally. You also get to decide exactly which Python versions you wish to support or not support.

Fourth, I think the few advantages of integration can be obtained by other means that are not much more difficult. This includes a link on the 'Other ports' page for the appropriate versions.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11937>
_______________________________________

From report at bugs.python.org  Sat Apr 30 00:58:41 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 29 Apr 2011 22:58:41 +0000
Subject: [issue11957] re.sub problem with unicode string
In-Reply-To: <1304101630.86.0.175815070517.issue11957@psf.upfronthosting.co.za>
Message-ID: <1304117921.39.0.563774733318.issue11957@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

The 4th parameter to re.sub() is a count, not flags.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11957>
_______________________________________

From report at bugs.python.org  Sat Apr 30 01:04:25 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 Apr 2011 23:04:25 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
	mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1304118265.74.0.663138057225.issue4806@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

#11944 is probably a duplicate of this and should be checked when this is fixed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4806>
_______________________________________

From report at bugs.python.org  Sat Apr 30 01:06:36 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 Apr 2011 23:06:36 +0000
Subject: [issue11950] logger use dict for loggers instead of
	WeakValueDictionary
In-Reply-To: <1304018959.77.0.656415451022.issue11950@psf.upfronthosting.co.za>
Message-ID: <1304118396.44.0.608299443639.issue11950@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.6, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11950>
_______________________________________

From report at bugs.python.org  Sat Apr 30 01:28:50 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 Apr 2011 23:28:50 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1304119730.52.0.0211547566528.issue11948@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I believe the patch produces the following as the first sentence

"When a module named :mod:`spam` is imported, the interpreter searches for a file named :file:`spam.py` in a list of directories given by the variable ``sys.path`` which is initialized from the directory containing the input script (or the current directory), :envvar:`PYTHONPATH` (a list of directory names, with the same syntax as the shell variable :envvar:`PATH`) and the installation-dependent default."

This is more that a 'mouthful', especially for a tutorial, and I think is should be split into two:
variable ``sys.path``.  ``Sys.path`` is initialized ...

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Sat Apr 30 01:39:01 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 Apr 2011 23:39:01 +0000
Subject: [issue11950] logger use dict for loggers instead of
	WeakValueDictionary
In-Reply-To: <1304018959.77.0.656415451022.issue11950@psf.upfronthosting.co.za>
Message-ID: <1304120341.13.0.680412999014.issue11950@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Mark, this is a feature request to change the storage of loggers.  A behavior issue (bug report) must report a discrepancy between doc and behavior. Vinay rejected that request as not really possible.

Questions about using yum should go to a yum list or to python-list.
The tracker is not a tutorial list.

"logger.handlers is not documented"
Please look at section 15.9. logging.handlers ? Logging handlers
Are you referring specifically to how they are stored?
We do not usually document the internal details of modules.

----------
nosy: +terry.reedy
type: behavior -> feature request
versions:  -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11950>
_______________________________________

From report at bugs.python.org  Sat Apr 30 02:11:31 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Apr 2011 00:11:31 +0000
Subject: [issue11898] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1303393354.57.0.483160590848.issue11898@psf.upfronthosting.co.za>
Message-ID: <1304122291.65.0.696701525838.issue11898@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Did you run the httplib test with your patch? Interactively
>>> from test.test_httplib import test_main as f; f()
(verbose mode, over 40 tests)

In 3.x, the patch would be to http/client.py, line 802 in 3.2 release
if isinstance(message_body, str) # becomes
if isinstance(message_body, bytes)

Will this be an issue in 3.x?

----------
nosy: +terry.reedy
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11898>
_______________________________________

From report at bugs.python.org  Sat Apr 30 03:02:52 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 30 Apr 2011 01:02:52 +0000
Subject: [issue11959] smtpd cannot be used without affecting global state
In-Reply-To: <1304111550.3.0.684224980767.issue11959@psf.upfronthosting.co.za>
Message-ID: <1304125372.37.0.82282353548.issue11959@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

The fact that you need to keep two separate maps makes me think that the approach you have in mind might be wrong, as in - that's something you usually don't want to do -.
The fact that asyncore uses a default socket map is surely unfortunate, but it's something you rarely want to deal with, therefore changing the __init__ notation of those classes is debatable at least.
What are you trying to achieve exactly?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11959>
_______________________________________

From report at bugs.python.org  Sat Apr 30 03:03:14 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 30 Apr 2011 01:03:14 +0000
Subject: [issue11959] smtpd cannot be used without affecting global state
In-Reply-To: <1304111550.3.0.684224980767.issue11959@psf.upfronthosting.co.za>
Message-ID: <1304125394.97.0.801648221888.issue11959@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
Removed message: http://bugs.python.org/msg134825

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11959>
_______________________________________

From report at bugs.python.org  Sat Apr 30 03:03:58 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 30 Apr 2011 01:03:58 +0000
Subject: [issue11959] smtpd cannot be used without affecting global state
In-Reply-To: <1304111550.3.0.684224980767.issue11959@psf.upfronthosting.co.za>
Message-ID: <1304125438.69.0.73924863725.issue11959@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

The fact that you need to keep two separate maps makes me think that the approach you have in mind might be wrong, as in - that's something you usually don't want to do -. The fact that asyncore uses a global socket map is surely unfortunate, but it's something you rarely want to deal with, therefore changing the __init__ notation of those classes is debatable at least.
What are you trying to achieve exactly?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11959>
_______________________________________

From report at bugs.python.org  Sat Apr 30 03:16:30 2011
From: report at bugs.python.org (Alex Lai)
Date: Sat, 30 Apr 2011 01:16:30 +0000
Subject: [issue11960] Python crashes when running numpy test
In-Reply-To: <1304126190.62.0.557405108675.issue11960@psf.upfronthosting.co.za>
Message-ID: <1304126190.62.0.557405108675.issue11960@psf.upfronthosting.co.za>


New submission from Alex Lai <alex_lai at scotiacapital.com>:

Hi experts,

            I?m wondering if anyone would look into this issue. We recently installed Python 3.1.2 on a Solaris 10 machine. While testing numpy package, Python crashed with the following error:

sbtorsvr391:~ $ cd /home/dcottr/local/tests
sbtorsvr391:~/local/tests $ export PYTHONPATH=$PYTHONPATH:~/local/lib/python3.1/site-packages

sbtorsvr391:~/local/tests $ /usr/local/bin/python3 -c "import numpy; numpy.test()"
Running unit tests for numpy
NumPy version 1.5.1
NumPy is installed in /home/dcottr/local/lib/python3.1/site-packages/numpy

Python version 3.1.2 (r312:79147, Mar 23 2010, 02:42:06) [GCC 3.4.6]
nose version 1.0.0
..S...............................................................................................................................................S........Warning: invalid value encountered in isfinite
............................................................................................................................................................................................Warning: invalid value encountered in isinf
Warning: invalid value encountered in isinf
......................................................................................................SSS........................K...........................................................K.....................................................................................................................................................F.F....................K.............................................................................................K...SK.F.......S...........................................................................................Segmentation Fault (core dumped)


            Below is the stack trace from the core dump:

 

# mdb core_sbtorsvr391_python3_10439_5000_1304101376_11246

Loading modules: [ libc.so.1 libavl.so.1 libuutil.so.1 ld.so.1 ]

> 
> ::stack
libc.so.1`strlen+0x50(fba55238, ffbf9ef8, ffbf9761, 0, 0, 0)
libc.so.1`sprintf+0x40(ffbf9f18, 7fffffff, 7ffffc00, 2, 2, 1b74cc)
test_array_from_pyobj_ext.so`array_from_pyobj+0x4e0(6, 17d3ec0, 1, 7, 16176c0, ff13a5a0)
test_array_from_pyobj_ext.so`f2py_rout_wrap_call+0xbc(1, 1, 0, 17f000, fffffffe, fba65b94)
PyCFunction_Call+0x90(15ff350, 1841900, 1844e90, 0, 1, 183df38)
PyEval_EvalFrameEx+0x4f10(0, ffbfa1c0, 1615770, 1, 16491b0, 15ff350)
PyEval_EvalCodeEx+0x874(1615770, 161ff60, 0, 160cf3c, 5, 0)
function_call+0x8c(162e270, 160cf30, 0, 17f000, fffffffe, 40)
PyObject_Call+0x44(162e270, 160cf30, 0, 160cf3c, 4, 16176c0)
method_call+0x8c(162e270, 18418d0, 0, 1849f60, 1, 3f)
PyObject_Call+0x44(176b620, 18418d0, 0, 2ed5c, 2efe0, 176b620)
slot_tp_init+0x7c(176b620, 18418d0, 0, 2, 1, 16296d0)
type_call+0xdc(16521a0, 18418d0, 0, 17f000, fffffffe, 3e)
PyObject_Call+0x44(16521a0, 18418d0, 0, 18418d8, 1820030, 183ddbc)
PyEval_EvalFrameEx+0x37b4(0, ffbfa688, 162e9b0, 1, 16259c0, 16521a0)
PyEval_EvalFrameEx+0x5c98(0, ffbfa788, 16154e8, 1, 1626030, 162eb28)
PyEval_EvalFrameEx+0x5c98(0, ffbfa888, 52b260, 1, 57ec00, 162e468)
PyEval_EvalCodeEx+0x874(52b260, 5229c0, 0, 1808834, 2, 1ac03c)
function_call+0x8c(5a36a8, 1808828, 0, 17f000, fffffffe, 3a)
PyObject_Call+0x44(5a36a8, 1808828, 1825a50, 19b000, 163ab30, fe36c4)
PyEval_EvalFrameEx+0x13bc(0, fe36c8, 52b2f0, 1, 526d50, 1808828)
PyEval_EvalCodeEx+0x874(52b2f0, 1, 0, 1808c1c, 2, 0)
function_call+0x8c(5a3738, 1808c10, 0, 17f000, fffffffe, 38)
PyObject_Call+0x44(5a3738, 1808c10, 0, 1808c10, 1, 1849e50)
method_call+0x8c(5a3738, 1630450, 0, 1630440, 9, 37)
PyObject_Call+0x44(1612850, 1630450, 0, 193618, 2, 1612850)
slot_tp_call+0x7c(163ab30, 1630450, 0, 17f000, fffffffe, 36)
PyObject_Call+0x44(163ab30, 1630450, 0, 1630458, 1849e50, fe355c)
PyEval_EvalFrameEx+0x37b4(0, ffbfaf78, b1e0f8, 1, a873a0, 163ab30)
PyEval_EvalFrameEx+0x5c98(0, ffbfb078, b1e0b0, 1, b1db58, b1ed20)
PyEval_EvalCodeEx+0x874(b1e0b0, b0e810, 0, 180b67c, 2, 1ac03c)
function_call+0x8c(b1ecd8, 180b670, 0, 17f000, fffffffe, 33)
PyObject_Call+0x44(b1ecd8, 180b670, 18258a0, 19b000, 163abf0, fe2f3c)
PyEval_EvalFrameEx+0x13bc(0, fe2f40, b1ccc8, 1, b1a350, 180b670)
PyEval_EvalCodeEx+0x874(b1ccc8, 1, 0, 1844dac, 2, 0)
function_call+0x8c(b1ea50, 1844da0, 0, 17f000, fffffffe, 31)
PyObject_Call+0x44(b1ea50, 1844da0, 0, 1844da0, 1, e4ddf0)
method_call+0x8c(b1ea50, 16306d0, 0, 16306c0, b, 30)
PyObject_Call+0x44(176b5a8, 16306d0, 0, 1ab728, 18f708, 176b5a8)
slot_tp_call+0x7c(163abf0, 16306d0, 0, 17f000, fffffffe, 2f)
PyObject_Call+0x44(163abf0, 16306d0, 0, 16306d8, e4ddf0, 18374d8)
PyEval_EvalFrameEx+0x37b4(0, ffbfb768, b2e4e8, 1, ad9ce8, 163abf0)
PyEval_EvalCodeEx+0x874(b2e4e8, b1b4b0, 0, 18087bc, 2, 1ac03c)
function_call+0x8c(a00390, 18087b0, 0, 17f000, fffffffe, 2d)
PyObject_Call+0x44(a00390, 18087b0, 176c810, 19b000, 165c450, 182ea24)
PyEval_EvalFrameEx+0x13bc(0, 182ea28, b2e380, 1, b1ad50, 18087b0)
PyEval_EvalCodeEx+0x874(b2e380, 1, 0, 176b8ac, 2, 0)
function_call+0x8c(a002b8, 176b8a0, 0, 17f000, fffffffe, 2b)
PyObject_Call+0x44(a002b8, 176b8a0, 0, 176b8a0, 1, e4ddf0)
method_call+0x8c(a002b8, 16141b0, 0, 16141a0, 9, 2a)
PyObject_Call+0x44(1612c10, 16141b0, 0, 1ab728, 18f708, 1612c10)
slot_tp_call+0x7c(165c450, 16141b0, 0, 17f000, fffffffe, 29)
PyObject_Call+0x44(165c450, 16141b0, 0, 16141b8, e4ddf0, 1645cf0)
PyEval_EvalFrameEx+0x37b4(0, ffbfbe58, b2e4e8, 1, ad9ce8, 165c450)
PyEval_EvalCodeEx+0x874(b2e4e8, b1b4b0, 0, 16296a4, 2, 1ac03c)
function_call+0x8c(a00390, 1629698, 0, 17f000, fffffffe, 27)
PyObject_Call+0x44(a00390, 1629698, 161f8a0, 19b000, 176a270, 124868c)
PyEval_EvalFrameEx+0x13bc(0, 1248690, b2e380, 1, b1ad50, 1629698)
PyEval_EvalCodeEx+0x874(b2e380, 1, 0, 16127bc, 2, 0)
> ::quit

The C library used by Python is as follows:


sbtorsvr391:~/local/tests $ ldd /usr/local/bin/python3|grep libc
        libc.so.1 =>        /lib/libc.so.1
        /platform/SUNW,Sun-Fire-V490/lib/libc_psr.so.1
 
sbtorsvr391:~ $ ls -l /lib/libc.so.1
-rwxr-xr-x 1 root bin 1640776 Aug 10  2010 /lib/libc.so.1

sbtorsvr391:~ $ pkgchk -l -p /lib/libc.so.1
NOTE: Couldn't lock the package database.
Pathname: /lib/libc.so.1
Type: regular file
Expected mode: 0755
Expected owner: root
Expected group: bin
Expected file size (bytes): 1640776
Expected sum(1) of contents: 50250
Expected last modification: Aug 10 13:55:34 2010
Referenced by the following packages:
        SUNWcslr
Current status: installed

sbtorsvr391:~ $ pkginfo -l SUNWcslr
   PKGINST:  SUNWcslr
      NAME:  Core Solaris Libraries (Root)
  CATEGORY:  system
      ARCH:  sparc
   VERSION:  11.10.0,REV=2005.01.21.15.53
   BASEDIR:  /
    VENDOR:  Sun Microsystems, Inc.
      DESC:  core software for a specific instruction-set architecture
    PSTAMP:  on10-patch20100511083333
  INSTDATE:  Jan 22 2011 16:10
   HOTLINE:  Please contact your local service provider
    STATUS:  completely installed
     FILES:      245 installed pathnames
                   2 shared pathnames
                   5 directories
                 133 executables
               34303 blocks used (approx)


The same problem doesn't occur when the command is run as root.

I opened a ticket with Oracle support for the libc isse, they responsed with the comment "The python program is passing an invalid address to the third parameter of sprintf. This is not a Solaris issue. Please contact python support."

I'm hoping I will find answer to this issue here...


Thanks in advance,

Alex

----------
components: Interpreter Core
messages: 134827
nosy: alex_lai
priority: normal
severity: normal
status: open
title: Python crashes when running numpy test
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11960>
_______________________________________

From report at bugs.python.org  Sat Apr 30 03:17:04 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 30 Apr 2011 01:17:04 +0000
Subject: [issue10761] tarfile.extractall fails to overwrite symlinks
In-Reply-To: <1293063436.61.0.0994372418071.issue10761@psf.upfronthosting.co.za>
Message-ID: <1304126224.51.0.438770790061.issue10761@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

buildbots are green again.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10761>
_______________________________________

From report at bugs.python.org  Sat Apr 30 04:16:45 2011
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 30 Apr 2011 02:16:45 +0000
Subject: [issue11961] Document STARTUPINFO and creationflags options for
	Windows
In-Reply-To: <1304129805.59.0.427649985572.issue11961@psf.upfronthosting.co.za>
Message-ID: <1304129805.59.0.427649985572.issue11961@psf.upfronthosting.co.za>


New submission from Brian Curtin <brian at python.org>:

Attached is a patch that adds documentation for a few things that have existed in subprocess for a while without documentation.

The "startupinfo" parameter takes subprocess.STARTUPINFO object which takes a few different options for its attributes, but none of this was documented.

The "creationflags" parameter takes subprocess.CREATE_NEW_WINDOW or subprocess.CREATE_NEW_PROCESS_GROUP, but neither were documented as options or what the options mean.

----------
assignee: brian.curtin
components: Documentation, Windows
files: windows_additions.diff
keywords: needs review, patch
messages: 134829
nosy: brian.curtin
priority: normal
severity: normal
stage: patch review
status: open
title: Document STARTUPINFO and creationflags options for Windows
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21838/windows_additions.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11961>
_______________________________________

From report at bugs.python.org  Sat Apr 30 04:23:35 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 30 Apr 2011 02:23:35 +0000
Subject: [issue11957] re.sub confusion between count and flags args
In-Reply-To: <1304101630.86.0.175815070517.issue11957@psf.upfronthosting.co.za>
Message-ID: <1304130215.79.0.491137776612.issue11957@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Since this has been reported already several times (see e.g. #11947), and it's a fairly common mistake, I think we should do something to avoid it.

A few possibilities are:
  1) add a warning in the doc;
  2) make count and flag keyword-only argument (raising a deprecation warning in 3.3 and actually change it later);
  3) change the regex flags to some object that can be distinguished from ints and raise an error when a flag is passed to count;

----------
nosy: +ezio.melotti, mrabarnett
title: re.sub problem with unicode string -> re.sub confusion between count and flags args
versions: +Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11957>
_______________________________________

From report at bugs.python.org  Sat Apr 30 04:24:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 30 Apr 2011 02:24:11 +0000
Subject: [issue11947] re.IGNORECASE does not match literal "_" (underscore)
In-Reply-To: <1304010176.69.0.487843608928.issue11947@psf.upfronthosting.co.za>
Message-ID: <1304130251.46.0.679966355602.issue11947@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See also #11957.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11947>
_______________________________________

From report at bugs.python.org  Sat Apr 30 04:38:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 30 Apr 2011 02:38:45 +0000
Subject: [issue11961] Document STARTUPINFO and creationflags options for
	Windows
In-Reply-To: <1304129805.59.0.427649985572.issue11961@psf.upfronthosting.co.za>
Message-ID: <1304131125.38.0.0233543629153.issue11961@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

You can indent the "attribute" directives and avoid to repeat "STARTUPINFO." before every attribute. If STD_INPUT_HANDLE and the other constants are attributes of STARTUPINFO they should be indented too, otherwise a line that says that subprocess also provides those at module level might be better.
Another short note at the beginning of the section that mentions that this class/attributes are available on Windows only would be good too.
There's also some trailing whitespace that should be removed.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11961>
_______________________________________

From report at bugs.python.org  Sat Apr 30 04:45:48 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 30 Apr 2011 02:45:48 +0000
Subject: [issue11960] Python crashes when running numpy test
In-Reply-To: <1304126190.62.0.557405108675.issue11960@psf.upfronthosting.co.za>
Message-ID: <1304131548.39.0.743038896286.issue11960@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Can you try with Python 3.2 (and/or get the dev version of 3.3 from http://hg.python.org/cpython and compile it)?
It would be also useful to know what test exactly causes the segfault and see its code.
Note that this might also be a numpy issue, so it might be useful to report it to the numpy bug tracker too.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11960>
_______________________________________

From report at bugs.python.org  Sat Apr 30 04:54:19 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 30 Apr 2011 02:54:19 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1304132059.1.0.0697315642153.issue9723@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See also #11827 about subprocess.list2cmdline.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Sat Apr 30 04:57:16 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 30 Apr 2011 02:57:16 +0000
Subject: [issue11762] Ast doc: warning and version number
In-Reply-To: <1301933761.05.0.937546235723.issue11762@psf.upfronthosting.co.za>
Message-ID: <1304132236.47.0.767362699102.issue11762@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/issue11762>
_______________________________________

From report at bugs.python.org  Sat Apr 30 04:59:29 2011
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 30 Apr 2011 02:59:29 +0000
Subject: [issue11361] suggestion for os.kill(pid,CTRL_C_EVENT) in tests
In-Reply-To: <1298986221.06.0.20392871991.issue11361@psf.upfronthosting.co.za>
Message-ID: <1304132369.35.0.0381284917381.issue11361@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
assignee:  -> brian.curtin
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11361>
_______________________________________

From report at bugs.python.org  Sat Apr 30 05:24:42 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Apr 2011 03:24:42 +0000
Subject: [issue11961] Document STARTUPINFO and creationflags options for
	Windows
In-Reply-To: <1304129805.59.0.427649985572.issue11961@psf.upfronthosting.co.za>
Message-ID: <E1QG0nM-0002UI-Qu@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 609ca9d71aba by Brian Curtin in branch '3.1':
Fix #11961. Document STARTUPINFO and creation flag options.
http://hg.python.org/cpython/rev/609ca9d71aba

New changeset f0092c611004 by Brian Curtin in branch '3.2':
Fix #11961. Document STARTUPINFO and creation flag options.
http://hg.python.org/cpython/rev/f0092c611004

New changeset f8fae22a1ff0 by Brian Curtin in branch 'default':
Fix #11961. Document STARTUPINFO and creation flag options.
http://hg.python.org/cpython/rev/f8fae22a1ff0

New changeset 9a31422649f1 by Brian Curtin in branch '2.7':
Fix #11961. Document STARTUPINFO and creation flag options.
http://hg.python.org/cpython/rev/9a31422649f1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11961>
_______________________________________

From report at bugs.python.org  Sat Apr 30 05:26:20 2011
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 30 Apr 2011 03:26:20 +0000
Subject: [issue11961] Document STARTUPINFO and creationflags options for
	Windows
In-Reply-To: <1304129805.59.0.427649985572.issue11961@psf.upfronthosting.co.za>
Message-ID: <1304133980.02.0.31631682101.issue11961@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Thanks for having a look, Ezio.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11961>
_______________________________________

From report at bugs.python.org  Sat Apr 30 07:53:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Apr 2011 05:53:12 +0000
Subject: [issue10912] PyObject_RichCompare differs in behaviour from
	PyObject_RichCompareBool ; difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <E1QG379-0003g7-8W@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d27f95e3b52f by Eli Bendersky in branch '2.7':
Issue #10912: add clarification for PyObject_RichCompareBool comparing identical objects
http://hg.python.org/cpython/rev/d27f95e3b52f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sat Apr 30 07:56:06 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 30 Apr 2011 05:56:06 +0000
Subject: [issue11827] mention of list2cmdline() in docs of subprocess.Popen
In-Reply-To: <1302511097.53.0.993242324349.issue11827@psf.upfronthosting.co.za>
Message-ID: <1304142966.69.0.157443594403.issue11827@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11827>
_______________________________________

From report at bugs.python.org  Sat Apr 30 07:56:48 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 30 Apr 2011 05:56:48 +0000
Subject: [issue10912] PyObject_RichCompare differs in behaviour from
	PyObject_RichCompareBool ; difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1304143008.55.0.375283158851.issue10912@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sat Apr 30 08:06:06 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 30 Apr 2011 06:06:06 +0000
Subject: [issue11034] Build problem on Windows with MSVC++ Express 2008
In-Reply-To: <1296200256.35.0.305421418262.issue11034@psf.upfronthosting.co.za>
Message-ID: <1304143566.76.0.18622123651.issue11034@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Can this be committed and closed? [it's still an annoying problem for some Windows users who want to compile Python]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11034>
_______________________________________

From report at bugs.python.org  Sat Apr 30 08:43:11 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 30 Apr 2011 06:43:11 +0000
Subject: [issue11962] FreeBSD-AMD64 bot sporadic hanging
In-Reply-To: <1304145791.54.0.116120198788.issue11962@psf.upfronthosting.co.za>
Message-ID: <1304145791.54.0.116120198788.issue11962@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

The FreeBSD-AMD64 bot exhibits sporadic hanging in unspecific places.
FreeBSD is running under kvm in the background. When the hanging occurs,
the virtual machine uses 100% CPU and I can't log in via ssh, so I have
to kill the kvm process.

The fact that the ssh login fails if a user process is misbehaving
seems like a FreeBSD/kvm issue to me. However, this problem did not
occur when I set up the bot a couple of weeks ago.


I've started a series of older revision builds to see if anything
recent causes this.

----------
components: Tests
messages: 134839
nosy: pitrou, skrah
priority: normal
severity: normal
status: open
title: FreeBSD-AMD64 bot sporadic hanging
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11962>
_______________________________________

From report at bugs.python.org  Sat Apr 30 08:57:05 2011
From: report at bugs.python.org (Bernhard Rosenkraenzer)
Date: Sat, 30 Apr 2011 06:57:05 +0000
Subject: [issue11898] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1303393354.57.0.483160590848.issue11898@psf.upfronthosting.co.za>
Message-ID: <1304146625.73.0.853643188278.issue11898@psf.upfronthosting.co.za>


Bernhard Rosenkraenzer <bero at arklinux.org> added the comment:

Not sure how to get it into verbose mode (I presume you don't mean "python -v"), but normal mode (22 tests) works fine:


Python 2.7.1 (r271:86832, Apr 22 2011, 13:40:40)
[GCC 4.6.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from test.test_httplib import test_main as f
>>> f()
test_auto_headers (test.test_httplib.HeaderTests) ... ok
test_ipv6host_header (test.test_httplib.HeaderTests) ... ok
test_putheader (test.test_httplib.HeaderTests) ... ok
test_responses (test.test_httplib.OfflineTest) ... ok
test_bad_status_repr (test.test_httplib.BasicTest) ... ok
test_chunked (test.test_httplib.BasicTest) ... ok
test_chunked_head (test.test_httplib.BasicTest) ... ok
test_epipe (test.test_httplib.BasicTest) ... ok
test_filenoattr (test.test_httplib.BasicTest) ... ok
test_host_port (test.test_httplib.BasicTest) ... ok
test_incomplete_read (test.test_httplib.BasicTest) ... ok
test_negative_content_length (test.test_httplib.BasicTest) ... ok
test_partial_reads (test.test_httplib.BasicTest) ... ok
test_read_head (test.test_httplib.BasicTest) ... ok
test_response_headers (test.test_httplib.BasicTest) ... ok
test_send (test.test_httplib.BasicTest) ... ok
test_send_file (test.test_httplib.BasicTest) ... ok
test_status_lines (test.test_httplib.BasicTest) ... ok
testTimeoutAttribute (test.test_httplib.TimeoutTest)
This will prove that the timeout gets through ... ok
test_attributes (test.test_httplib.HTTPSTimeoutTest) ... ok
testHTTPConnectionSourceAddress (test.test_httplib.SourceAddressTest) ... ok
testHTTPSConnectionSourceAddress (test.test_httplib.SourceAddressTest) ... ok

----------------------------------------------------------------------
Ran 22 tests in 0.004s

OK


Not sure if this is an issue with 3.x - I haven't used 3.x so far.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11898>
_______________________________________

From report at bugs.python.org  Sat Apr 30 09:15:02 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 30 Apr 2011 07:15:02 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1304147702.37.0.859026695622.issue11949@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________

From report at bugs.python.org  Sat Apr 30 09:21:10 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 30 Apr 2011 07:21:10 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1304148070.84.0.656544492677.issue11949@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> sqrt(-0.0) to return -0.0.  Does anyone know what the relevant standard says?

sqrt(-0.0) should indeed be -0.0, according to IEEE 754.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________

From report at bugs.python.org  Sat Apr 30 09:23:42 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 30 Apr 2011 07:23:42 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1304148222.71.0.956310188715.issue11949@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Alexander,

There are lots of almost-equality tests in the test-suite already, between test_math, test_float, test_cmath and test_complex.  Do you need to implement another one here, or can you reuse one of the existing ones?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________

From report at bugs.python.org  Sat Apr 30 09:33:56 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 30 Apr 2011 07:33:56 +0000
Subject: [issue11597] Can't get ConfigParser.write to write unicode strings
In-Reply-To: <1300468084.29.0.517380899901.issue11597@psf.upfronthosting.co.za>
Message-ID: <1304148836.76.0.585899629702.issue11597@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

the_isz, for serious Unicode support you might try using the configparser 3.2 backport:

http://pypi.python.org/pypi/configparser

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11597>
_______________________________________

From report at bugs.python.org  Sat Apr 30 09:47:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Apr 2011 07:47:30 +0000
Subject: [issue11324] ConfigParser(interpolation=None) doesn't work
In-Reply-To: <1298666228.44.0.489583826736.issue11324@psf.upfronthosting.co.za>
Message-ID: <E1QG4tl-0001Th-8u@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 08996a664ed3 by ?ukasz Langa in branch '3.2':
Mentioned issues #11324 and #11858.
http://hg.python.org/cpython/rev/08996a664ed3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11324>
_______________________________________

From report at bugs.python.org  Sat Apr 30 09:47:42 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Apr 2011 07:47:42 +0000
Subject: [issue11324] ConfigParser(interpolation=None) doesn't work
In-Reply-To: <1298666228.44.0.489583826736.issue11324@psf.upfronthosting.co.za>
Message-ID: <E1QG4tx-0001Uw-HP@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0c21de0cca44 by ?ukasz Langa in branch 'default':
Merged mentions of issues #11324 and #11858.
http://hg.python.org/cpython/rev/0c21de0cca44

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11324>
_______________________________________

From report at bugs.python.org  Sat Apr 30 09:50:41 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 30 Apr 2011 07:50:41 +0000
Subject: [issue11034] Build problem on Windows with MSVC++ Express 2008
In-Reply-To: <1296200256.35.0.305421418262.issue11034@psf.upfronthosting.co.za>
Message-ID: <1304149841.97.0.294914019023.issue11034@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm closing it as rejected. Python doesn't use subversion anymore.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11034>
_______________________________________

From report at bugs.python.org  Sat Apr 30 10:52:45 2011
From: report at bugs.python.org (the_isz)
Date: Sat, 30 Apr 2011 08:52:45 +0000
Subject: [issue11597] Can't get ConfigParser.write to write unicode strings
In-Reply-To: <1300468084.29.0.517380899901.issue11597@psf.upfronthosting.co.za>
Message-ID: <1304153565.87.0.896995977822.issue11597@psf.upfronthosting.co.za>


the_isz <the_isz at gmx.de> added the comment:

Thanks for the hint, ?ukasz, but like I stated earlier, I already worked around
this problem by using the json module instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11597>
_______________________________________

From report at bugs.python.org  Sat Apr 30 11:00:14 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 30 Apr 2011 09:00:14 +0000
Subject: [issue10775] assertRaises as a context manager should accept a 'msg'
	keyword argument.
In-Reply-To: <1293391143.22.0.15906903458.issue10775@psf.upfronthosting.co.za>
Message-ID: <1304154014.2.0.712582708446.issue10775@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: michael.foord -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10775>
_______________________________________

From report at bugs.python.org  Sat Apr 30 11:25:12 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 30 Apr 2011 09:25:12 +0000
Subject: [issue11960] Python crashes when running numpy test
In-Reply-To: <1304126190.62.0.557405108675.issue11960@psf.upfronthosting.co.za>
Message-ID: <1304155512.18.0.543657025493.issue11960@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The issue is actually in numpy. In numpy/f2py/src/fortranobject.c, function array_from_pyobj(), there is::

        sprintf(mess,"failed to initialize intent(inout|inplace|cache) array"
                " -- input must be array but got %s",
                PyString_AsString(PyObject_Str(PyObject_Type(obj)))
                );

(In numpy headers, PyString_AsString is aliased to PyBytes_AsString.)
Besides the reference leaks, this function will fail when given the unicode string returned by PyObject_Str(), and sprintf receives the null string...
Please report this to numpy.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11960>
_______________________________________

From report at bugs.python.org  Sat Apr 30 12:54:05 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 30 Apr 2011 10:54:05 +0000
Subject: [issue10775] assertRaises as a context manager should accept a 'msg'
	keyword argument.
In-Reply-To: <1293391143.22.0.15906903458.issue10775@psf.upfronthosting.co.za>
Message-ID: <1304160845.15.0.994773658234.issue10775@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attached a revised patch.
While I agree that an error should be raised when extra args are provided in the context manager form, this is out of the scope of the issue, so I didn't include those changes.

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file21839/issue10775-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10775>
_______________________________________

From report at bugs.python.org  Sat Apr 30 12:55:28 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 30 Apr 2011 10:55:28 +0000
Subject: [issue10775] assertRaises as a context manager should accept a 'msg'
	keyword argument.
In-Reply-To: <1293391143.22.0.15906903458.issue10775@psf.upfronthosting.co.za>
Message-ID: <1304160928.48.0.664363444888.issue10775@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file21840/issue10775-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10775>
_______________________________________

From report at bugs.python.org  Sat Apr 30 12:55:41 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 30 Apr 2011 10:55:41 +0000
Subject: [issue10775] assertRaises as a context manager should accept a 'msg'
	keyword argument.
In-Reply-To: <1293391143.22.0.15906903458.issue10775@psf.upfronthosting.co.za>
Message-ID: <1304160941.51.0.706710851707.issue10775@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file21840/issue10775-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10775>
_______________________________________

From report at bugs.python.org  Sat Apr 30 13:13:14 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Sat, 30 Apr 2011 11:13:14 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304161994.39.0.748903853523.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

RE: msg134751 - Thanks for responding, George -

This bug is still an issue for me, as even though I now have Python-3.3
having passed its test suite, installed and running OK, and even
went so far as to 'cd /usr/bin; rm -f python; ln -s python3.3 python;'
(/usr/bin/python2.7 executable still exists) all the software
I now attempt to build insists on using python2 , which is built
against an old glibc and has started giving anomalous results
after upgrade to newer glibc - see : 
https://bugzilla.gnome.org/show_bug.cgi?id=648863
where I found that my python-2.7 was failing to 
 'from . import config'
whereas the FC-14 python 2.7 got past this .

So I still need to find a way of building python 2.7.1 to replace
my broken old system python2 .

When I tried this, doing :
$ /usr/src/Python-2.7.1/configure --prefix=/usr --libdir=/usr/lib64 --enable-shared CXX=${CXX} CXXFLAGS="$CXXFLAGS"

(I only added the CXX= args because configure complained that while
 I did have $CXX set to /usr/bin/g++ , "c++" would be used )

the build failed complaining that the 'bsddb185 dl gdbm' modules
could not be built; I had to change the $CPPFLAGS to contain
'-I/usr/include/db4' and --libs to contain '-ldb-4.5 -lgdbm' and
comment out and modify the lines in Module/Setup :

  #dl dlmodule.c
...
  #gdbm gdbmmodule.c -I/usr/local/include -L/usr/local/lib -lgdbm
...
  #_bsddb _bsddb.c -I$(DBINC) -L$(DBLIB) -ldb-$(DBLIBVER)

and then the build succeeded , but with these errors from dlmodule :

test_dl
test test_dl crashed -- <type 'exceptions.SystemError'>: module dl requires sizeof(int) == sizeof(long) == sizeof(char*)

My point is, if this test_dl works only in 32-bit mode, it should
have failed during its build, not during test !
If it is meant to be 32-bit only, say something like :

#if __LONG_MAX__ > 0xffffffff
#error dlmodule only works in 32-bit mode.
#endif

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Sat Apr 30 13:22:50 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Apr 2011 11:22:50 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304162570.88.0.84049642786.issue11946@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Not sure why you would prefer an unstable, unreleased hg trunk version to a stable, released one.

And as you've seen, Python 2 and Python 3 are quite different things.

As for dl failing on build, you've already stated that it does *not* build, together with bsddb185 and gdbm (for which the library headers are missing).  setup.py does exactly that test for 64-bit platforms.  Then you activate it explicitly, and complain that it does build...

And lastly, all these things are *not* a build failure of Python: missing modules just means that, well, these modules won't be there.  And failing tests just means that there *may* be a problem when using the respective module -- but for platform-dependent modules it could just as well mean that your system is configured in a special way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Sat Apr 30 13:25:21 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Apr 2011 11:25:21 +0000
Subject: [issue11786] ConfigParser.[Raw]ConfigParser optionxform()
In-Reply-To: <1302110277.82.0.57770456199.issue11786@psf.upfronthosting.co.za>
Message-ID: <1304162721.69.0.924074091851.issue11786@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The point is, all gratuitous changes to such branches are a nuisance to the release manager who decides what needs to go into a security release.

Also, doc changes in 2.6 are almost completely gratuitous, since the docs are never again built and put online somewhere.  (Source-only releases don't have build doc releases.)

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11786>
_______________________________________

From report at bugs.python.org  Sat Apr 30 13:48:26 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Sat, 30 Apr 2011 11:48:26 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304164106.92.0.287722612757.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

Now I'm really confused.

After linked /usr/bin/python to python3.3  :

  $ cd /usr/bin; rm -f python; ln -s python3.3 python;

the 2.7.1 build now succeeds ! 
(with the patched Lib/test/test_commands.py and the 'make test'
 run as non-root ).
This time I don't get any build errors for missing modules
and don't have to edit Module/Setup .
BTW, the missing modules that caused the build to fail before
was :
    'bsddb185 dl gdbm imageop'
; after the new ./python executable was built, it did some 
'configure modules' stage which DID fail with these missing
modules, but now /usr/bin/python is python3.3, it DOESN'T fail.

I don't think the current state of the installed system python
should be able to affect in any way the build of a new python -
that to me is a fundamental, critical bug in the build system.

Maybe I should open a new bug on that issue ?

But yes, the issue of this specific bug is now closed -
python-2.7.1 now builds OK - but PLEASE, put these 
lines or something like them in dlmodule.c :

#if __LONG_MAX__ > 0xffffffffU /* cpp -dM  builtin : __LONG_MAX__ */
#error dlmodule only works in 32-bit mode.
#endif

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Sat Apr 30 13:57:48 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Sat, 30 Apr 2011 11:57:48 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304164668.55.0.688899223563.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

BTW, while I'm here :

Any advice on how to setup a truly multi-architecture python installation? 

I'm considering doing something like :

1. build same python source for both 32-bit and 64-bit, with
   64-bit installing /usr/lib/python-$V as /usr/lib64/python-$V  &
   32-bit installing /usr/lib/python-$V as /usr/lib32/python-$V

2. Replace /usr/bin/python with a shell script or program which does
   something like (in shell):
  
   #!/bin/sh
   if "`uname -m`" = i686 ; then # I'm in a 'setarch i686' env
      exec /usr/bin/32/python${0#python} $*
   else
      exec /usr/bin/python${0#python} $*
   fi

Any thoughts about / advice on doing something like this ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Sat Apr 30 14:17:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Apr 2011 12:17:52 +0000
Subject: [issue10914] Python sub-interpreter test
In-Reply-To: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za>
Message-ID: <E1QG97L-0007ST-7i@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 5a983773c09a by Victor Stinner in branch '3.2':
Issue #10914: Py_NewInterpreter() uses PyErr_PrintEx(0)
http://hg.python.org/cpython/rev/5a983773c09a

New changeset 2caf82aee7a4 by Victor Stinner in branch '3.2':
Issue #10914: Initialize correctly the filesystem codec when creating a new
http://hg.python.org/cpython/rev/2caf82aee7a4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10914>
_______________________________________

From report at bugs.python.org  Sat Apr 30 14:20:12 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Sat, 30 Apr 2011 12:20:12 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304166012.48.0.887141649485.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

Aha ! Is the above multi-arch config what would result if I did :

  --with-universal-archs=ARCH
                          select architectures for universal build  
                         ("32-bit",
                          "64-bit", "3-way", "intel" or "all")

ie: --with-univeral-archs='64-bit 32-bit' 

??

The fact that the python --configure ignores my '--libdir=/usr/lib64'
setting and installs files under /usr/lib regardless suggest this
would NOT work as I expect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Sat Apr 30 14:21:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 30 Apr 2011 12:21:20 +0000
Subject: [issue10914] Python sub-interpreter test
In-Reply-To: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za>
Message-ID: <1304166080.45.0.723186849481.issue10914@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Victor, the fix needs to go into 3.2 as well.

Oh, I thought that Modules/_testembed.c was only in 3.3. Anyway, it is a real bug in 3.2, and it is now fixed (I backported the 2 fixes in 3.2).

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10914>
_______________________________________

From report at bugs.python.org  Sat Apr 30 14:23:01 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 30 Apr 2011 12:23:01 +0000
Subject: [issue11762] Ast doc: warning and version number
In-Reply-To: <1301933761.05.0.937546235723.issue11762@psf.upfronthosting.co.za>
Message-ID: <1304166181.59.0.554742949277.issue11762@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11762>
_______________________________________

From report at bugs.python.org  Sat Apr 30 14:53:52 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Sat, 30 Apr 2011 12:53:52 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304168032.39.0.839624293418.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

So to get python multi-arch working as I expect I'd have to wrap the C header:

   /usr/include/python-2.7/pyconfig.h

with something like:

#ifdef __i386__
#include <python-2.7/32/pyconfig.h>
#else
#include <python-2.7/64/pyconfig.h>
#endif

and that's it ! After building i686-Python-2.7.1,  I can do
"my standard python post-install script" :

$ ABI=64; V=2.7
$ DESTDIR=`pwd`/inst make install
$ cd inst/usr
$ mv lib${ABI}/python${V}/* lib/python$V
$ rmdir lib${ABI}/python-${V}
$ mv lib/python-${V} lib$ABI
$ rmdir lib

And then:
$ cd inst/usr/include/python$V
$ for f in *; do cmp $f /usr/include/python2.7/$f; done
pyconfig.h /usr/include/python2.7/pyconfig.h differ: char 11124, line 393
$ $ diff -U0 pyconfig.h /usr/include/python2.7/pyconfig.h
--- pyconfig.h  2011-04-30 13:34:21.000000000 +0100
+++ /usr/include/python2.7/pyconfig.h   2011-04-30 12:34:23.000000000 +0100
@@ -393 +393 @@
-#define HAVE_LARGEFILE_SUPPORT 1
+/* #undef HAVE_LARGEFILE_SUPPORT */
@@ -989 +989 @@
-#define SIZEOF_LONG 4
+#define SIZEOF_LONG 8
@@ -992 +992 @@
-#define SIZEOF_LONG_DOUBLE 12
+#define SIZEOF_LONG_DOUBLE 16
@@ -1004 +1004 @@
-#define SIZEOF_PTHREAD_T 4
+#define SIZEOF_PTHREAD_T 8
@@ -1010 +1010 @@
-#define SIZEOF_SIZE_T 4
+#define SIZEOF_SIZE_T 8
@@ -1013 +1013 @@
-#define SIZEOF_TIME_T 4
+#define SIZEOF_TIME_T 8
@@ -1016 +1016 @@
-#define SIZEOF_UINTPTR_T 4
+#define SIZEOF_UINTPTR_T 8
@@ -1019 +1019 @@
-#define SIZEOF_VOID_P 4
+#define SIZEOF_VOID_P 8
@@ -1069 +1069 @@
-/* #undef VA_LIST_IS_ARRAY */
+#define VA_LIST_IS_ARRAY 1
@@ -1121 +1121 @@
-#define X87_DOUBLE_ROUNDING 1
+/* #undef X87_DOUBLE_ROUNDING */

so this is the ONLY file that needs to be wrapped to work in a 
multi-arch environment.

BTW, I know you can't use runtime expressions such as 
  'sizeof(char*)' 
in cpp macros, but you CAN get much the same effect by
using cpp 'builtin macros' :
e.g. you could write :

#if __LONG_MAX__ > 0xffffffffU 
#define SIZEOF_LONG 8 /*works until you want to support 128 / 256 bit */
#else
#define SIZEOF_LONG 4 /* guess you don't want to support 16 or 8 bit ?*/
#endif

and then pyconfig.h would not need to be wrapped .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Sat Apr 30 14:53:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 30 Apr 2011 12:53:54 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when
	locks are implemented using POSIX condition variables;
	add sys.thread_info
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1304168034.35.0.382218263781.issue11223@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: interruption of locks by signals not guaranteed when locks are implemented using POSIX condition variables -> interruption of locks by signals not guaranteed when locks are implemented using POSIX condition variables; add sys.thread_info

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Sat Apr 30 15:01:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Apr 2011 13:01:54 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when
	locks are implemented using POSIX condition variables;
	add sys.thread_info
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <E1QG9o0-0001W7-O4@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 2b21fcf3d9a9 by Victor Stinner in branch 'default':
Issue #11223: Replace threading._info() by sys.thread_info
http://hg.python.org/cpython/rev/2b21fcf3d9a9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Sat Apr 30 15:09:31 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Apr 2011 13:09:31 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304168971.08.0.574761305017.issue11946@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'm going to state this one again: missing modules are *NOT* a build failure.

It is pretty common to not install a certain library (or headers for them), if you don't need/want the Python module using it.  (And editing Modules/Setup to add modules that setup.py detects as not buildable won't make them buildable in 99% of cases.)

As for the dl module, the existing check in setup.py is just fine, especially since dl is deprecated and not present anymore in 3.x.  There will always be ways to shoot yourself in the foot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Sat Apr 30 15:22:09 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Apr 2011 13:22:09 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <E1QGA7b-0002b3-Op@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 28b9702a83d1 by Victor Stinner in branch 'default':
Issue #8407, issue #11859: Add signal.pthread_sigmask() function to fetch
http://hg.python.org/cpython/rev/28b9702a83d1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Sat Apr 30 15:22:17 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Sat, 30 Apr 2011 13:22:17 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304169737.07.0.129174618244.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

OK, the last two comment contained complete instructions for setting
up a working dual 64-bit + 32-bit python installation.

Final, working /usr/bin/python :

$ cat /usr/bin/python
#!/bin/sh
ME=$0
ME=${ME##*/}
VERSION=${ME#python}
VERSION=${VERSION:-2.7}
ARCH=`uname -m`
case $ARCH in
  i686)
     exec /usr/bin/32/${ME} $*
     ;;
  *)
     exec /usr/bin/python${VERSION} $*
     ;;
esac

So now, in a native 64-bit env :

$ python
Python 2.7.1 (r271:86832, Apr 30 2011, 11:55:52)
[GCC 4.6.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
^D
$ setarch i686
$ python
Python 2.7.1 (r271:86832, Apr 30 2011, 13:29:12)
[GCC 4.6.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>

See the build times, they are different executables !

And final, complete working /usr/include/python2.7/pyconfig.h :

$ echo '#include <python2.7/pyconfig.h>' > pyc.c
$ cpp pyc.c
$ cpp pyc.c
# 1 "pyc.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "pyc.c"
# 1 "/usr/include/python2.7/pyconfig.h" 1 3 4



# 1 "/usr/include/python2.7/64/pyconfig.h" 1 3 4
# 5 "/usr/include/python2.7/pyconfig.h" 2 3 4
# 1 "pyc.c" 2
$ cpp -m32 pyc.c
# 1 "pyc.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "pyc.c"
# 1 "/usr/include/python2.7/pyconfig.h" 1 3 4

# 1 "/usr/include/python2.7/32/pyconfig.h" 1 3 4
# 3 "/usr/include/python2.7/pyconfig.h" 2 3 4
# 1 "pyc.c" 2


$ cat /usr/include/python2.7/pyconfig.h
#ifdef __i386__
#include <python2.7/32/pyconfig.h>
#else
#include <python2.7/64/pyconfig.h>
#endif

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Sat Apr 30 15:23:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 30 Apr 2011 13:23:02 +0000
Subject: [issue11859] test_interrupted_write_text() of test_io failed of
	Python 3.3 on FreeBSD 7.2
In-Reply-To: <1302994631.38.0.484484359613.issue11859@psf.upfronthosting.co.za>
Message-ID: <1304169782.78.0.0585571136079.issue11859@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New changeset 28b9702a83d1 by Victor Stinner in branch 'default':
Issue #8407, issue #11859: Add signal.pthread_sigmask() function to fetch
http://hg.python.org/cpython/rev/28b9702a83d1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11859>
_______________________________________

From report at bugs.python.org  Sat Apr 30 16:00:29 2011
From: report at bugs.python.org (Vegar)
Date: Sat, 30 Apr 2011 14:00:29 +0000
Subject: [issue11147] _Py_ANNOTATE_MEMORY_ORDER has unused argument,
	effects code which includes Python.h
In-Reply-To: <1297134966.47.0.813239114372.issue11147@psf.upfronthosting.co.za>
Message-ID: <1304172029.78.0.117563038185.issue11147@psf.upfronthosting.co.za>


Changes by Vegar <storvann at gmail.com>:


----------
nosy: +storvann

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11147>
_______________________________________

From report at bugs.python.org  Sat Apr 30 16:33:40 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 30 Apr 2011 14:33:40 +0000
Subject: [issue11786] ConfigParser.
In-Reply-To: <1304162721.69.0.924074091851.issue11786@psf.upfronthosting.co.za>
Message-ID: <CF62D5F3-A180-40F6-8E4D-199EE662AA86@langa.pl>


?ukasz Langa <lukasz at langa.pl> added the comment:

Yup, the fact that the docs won't be rebuilt ever again makes my 2.6 commit effectively pointless and harmful for the RM. I will clean it up when I get home.

Thanks for the thorough explanation.

----------
title: ConfigParser.[Raw]ConfigParser optionxform() -> ConfigParser.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11786>
_______________________________________

From report at bugs.python.org  Sat Apr 30 16:40:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 30 Apr 2011 14:40:54 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304174454.98.0.172899236707.issue8407@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

signalfd.patch: Add signal.signalfd(), signal.SFD_CLOEXEC and signal.SFD_NONLOCK.

The patch is based on http://codereview.appspot.com/1132041 and the last version (bzr) of python-signalfd.

The patch uses also PyModule_AddIntMacro() for the 3 constants added in my last (pthread_sigmask), and changes pthread_sigmask() to raise an OSError instead of a RuntimeError.

Note: python-signalfd has a bug: it doesn't pass the fd argument to signalfd(), it always pass -1.

----------
Added file: http://bugs.python.org/file21841/signalfd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Sat Apr 30 17:24:07 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 30 Apr 2011 15:24:07 +0000
Subject: [issue11959] smtpd cannot be used without affecting global state
In-Reply-To: <1304111550.3.0.684224980767.issue11959@psf.upfronthosting.co.za>
Message-ID: <1304177047.14.0.270149852599.issue11959@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I don't want to use two different maps - I just want to use a single map which is not the global "socket_map" in asyncore.

asyncore.dispatcher and asynchat.async_chat allow for a map to be passed in so that the default global is not used, but smtpd does not allow this. Note that asyncore.loop() also allows a map to be passed in, so I'm sure this functionality is by design.

I mentioned two places where the map is to be used - passed to SMTPServer constructor (and saved in SMPTServer instance) and the *same* map used to initialise the SMTPChannel from SMTPServer.handle_accepted().

Since asyncore and asynchat support using a passed-in map to avoid using a global, it's not unreasonable to expect smtpd to support it too. After all, using it relies on asyncore.loop(), and passing an explicit map is allowed here.

I initially came across this because I got some warnings from regrtest.py about changed state, when I was trying to implement a TestSMTPServer class (derived from smtpd.SMTPServer) to test the SMTPHandler in logging.

I've taken out the functionality from test_logging for now, but I have a test script here:

https://gist.github.com/949744

This successfully uses a non-global map ("my_map"), but notice how much I had to resort to copypasta.

If I've missed some neat solution which avoids this hackery, please let me know! This is my first use of the smtpd module :-)

As I say, what I'm trying to do is to avoid changing global state in the unit test suite.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11959>
_______________________________________

From report at bugs.python.org  Sat Apr 30 17:38:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Apr 2011 15:38:19 +0000
Subject: [issue7517] freeze.py not ported to python3
In-Reply-To: <1260903379.83.0.360315644527.issue7517@psf.upfronthosting.co.za>
Message-ID: <1304177899.17.0.044503467985.issue7517@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file15570/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7517>
_______________________________________

From report at bugs.python.org  Sat Apr 30 17:39:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Apr 2011 15:39:34 +0000
Subject: [issue7517] freeze.py not ported to python3
In-Reply-To: <1260903379.83.0.360315644527.issue7517@psf.upfronthosting.co.za>
Message-ID: <1304177974.38.0.429957544195.issue7517@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Closing as duplicate, please use the other bug report to discuss.

----------
nosy: +eric.araujo
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> freeze.py broken due to ABI flags

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7517>
_______________________________________

From report at bugs.python.org  Sat Apr 30 17:43:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Apr 2011 15:43:26 +0000
Subject: [issue11963] Use real assert* for test_trigger_memory_error
	(test_parser)
In-Reply-To: <1304178205.97.0.319156485187.issue11963@psf.upfronthosting.co.za>
Message-ID: <1304178205.97.0.319156485187.issue11963@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I?ve always found strange that one test relied on visual (i.e. human) checking instead of using an assert* method.  I changed it and found that the test still passed (see attached patch).  Is there any reason to do it the old way?

----------
components: Tests
files: real-assert-in-test_parser.diff
keywords: patch
messages: 134868
nosy: benjamin.peterson, eric.araujo, mark.dickinson
priority: normal
severity: normal
stage: patch review
status: open
title: Use real assert* for test_trigger_memory_error (test_parser)
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file21842/real-assert-in-test_parser.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11963>
_______________________________________

From report at bugs.python.org  Sat Apr 30 17:47:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Apr 2011 15:47:15 +0000
Subject: [issue11964] Undocumented change to indent param of json.dump in 3.2
In-Reply-To: <1304178435.78.0.522459822796.issue11964@psf.upfronthosting.co.za>
Message-ID: <1304178435.78.0.522459822796.issue11964@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I found out that the indent parameter of json.dump was changed in 3.2: it can be a string as well as an int.  The docstring was not updated; the reST doc was, but without a versionchanged directive.

This probably applies to the doc and docstring of the classes implementing dump, too, and there may be other half-documented changes.

----------
assignee: docs at python
components: Documentation, Library (Lib)
keywords: easy
messages: 134869
nosy: bob.ippolito, docs at python, eric.araujo, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Undocumented change to indent param of json.dump in 3.2
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11964>
_______________________________________

From report at bugs.python.org  Sat Apr 30 17:49:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Apr 2011 15:49:30 +0000
Subject: [issue11965] Simplify context manager in os.popen
In-Reply-To: <1304178570.81.0.335603645525.issue11965@psf.upfronthosting.co.za>
Message-ID: <1304178570.81.0.335603645525.issue11965@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Previous to 3.2, os.popen was made a context manager thanks to a private helper, os._wrap_close (contextlib.closing was maybe unavailable due to a bootstrapping issue).  Now that subprocess.Popen directly implements the context manager protocol, this could be cleaned up.

----------
components: Library (Lib)
keywords: easy
messages: 134870
nosy: eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Simplify context manager in os.popen
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11965>
_______________________________________

From report at bugs.python.org  Sat Apr 30 17:51:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Apr 2011 15:51:08 +0000
Subject: [issue11956] 3.3 : test_import.py causes 'make test' to fail
In-Reply-To: <1304094086.01.0.944392387954.issue11956@psf.upfronthosting.co.za>
Message-ID: <1304178668.46.0.590610854649.issue11956@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It seems strange to build and test Python as root.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11956>
_______________________________________

From report at bugs.python.org  Sat Apr 30 17:53:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Apr 2011 15:53:19 +0000
Subject: [issue11955] 3.3 : test_argparse.py fails 'make test'
In-Reply-To: <1304093741.94.0.09129303291.issue11955@psf.upfronthosting.co.za>
Message-ID: <1304178799.51.0.757270326772.issue11955@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The helpers in test_argparse could be enhanced to print the tested string and expected result in case of failure.  Or the real line number.

----------
nosy: +bethard, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11955>
_______________________________________

From report at bugs.python.org  Sat Apr 30 17:55:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Apr 2011 15:55:24 +0000
Subject: [issue11344] Add os.path.splitpath(path) function
In-Reply-To: <1298795208.87.0.771920756626.issue11344@psf.upfronthosting.co.za>
Message-ID: <1304178924.37.0.577814958465.issue11344@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

To clarify one point: Python does not try to mimic the shell, but the os module exposes system calls as they are.

(Unrelated remark: pkgutil.get_data can replace a lot of uses of dirname(dirname(__file__)))

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11344>
_______________________________________

From report at bugs.python.org  Sat Apr 30 18:06:11 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Sat, 30 Apr 2011 16:06:11 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304179571.03.0.920600241867.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

Oops, thought there may be gotchas to that multi-arch python wrapper -
it wasn't quoting its arguments properly - here is now what I have as
/usr/bin/python :

$ cat python
#!/bin/bash
ME=$0
ME=${ME##*/}
VERSION=${ME#python}
VERSION=${VERSION:-2.7}
ARCH=`uname -m`
CMD=''
case $ARCH in
  i686)
     CMD="/usr/bin/32/${ME}"
     ;;
  *)
     CMD="/usr/bin/python${VERSION}.bin"
     ;;
esac
for((a=1;a<=$#;a++));do CMD="${CMD} '"$(eval 'echo -n "$'$a'"')"' ";done
eval "exec $CMD"

I had to move the /usr/bin/python${VERSION} executables to 
/usr/bin/python${VERSION}.bin , and replace them with copies
of this python script (which runs whichever version it is named by).

And I can do:

$ python -c 'import os
import sys
import commands
print commands.getstatus("ls -ld /.")
'
drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /.

under both the native x86_64 and a 'setarch i686' environment with
the same results.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Sat Apr 30 18:06:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Apr 2011 16:06:27 +0000
Subject: [issue11956] 3.3 : test_import.py causes 'make test' to fail
In-Reply-To: <1304094086.01.0.944392387954.issue11956@psf.upfronthosting.co.za>
Message-ID: <1304179587.46.0.788672017411.issue11956@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Disregard my remark; David in msg134804 expressed support for this, and given that there are Python programs run as root for sysadmin tasks, it makes sense to make sure the code is tested when run by root.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11956>
_______________________________________

From report at bugs.python.org  Sat Apr 30 18:14:54 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 30 Apr 2011 16:14:54 +0000
Subject: [issue11964] Undocumented change to indent param of json.dump in 3.2
In-Reply-To: <1304178435.78.0.522459822796.issue11964@psf.upfronthosting.co.za>
Message-ID: <1304180094.23.0.965840215922.issue11964@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This change was made by Raymond in issue 5729.  It is the only feature added by that patch; the missing versionchanged was an oversight and I don't think it makes any more likely that other features were added that weren't documented.

If you are updating doc strings, note that there is more than one docstring that mentions indent and all should be updated.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11964>
_______________________________________

From report at bugs.python.org  Sat Apr 30 18:26:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Apr 2011 16:26:59 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1304180819.94.0.311805066018.issue11948@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

One caveat to Terry?s suggestion: never ever change the case of a Python identifier or keyword (?Sys?).

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Sat Apr 30 18:30:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Apr 2011 16:30:08 +0000
Subject: [issue11898] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1303393354.57.0.483160590848.issue11898@psf.upfronthosting.co.za>
Message-ID: <1304181008.91.0.208877536103.issue11898@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Not sure how to get it into verbose mode

See http://diveintopython.org/http_web_services/debugging.html

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11898>
_______________________________________

From report at bugs.python.org  Sat Apr 30 18:32:23 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sat, 30 Apr 2011 16:32:23 +0000
Subject: [issue11966] Typo in PyModule_AddIntMacro's documentation
In-Reply-To: <1304181143.38.0.500156763216.issue11966@psf.upfronthosting.co.za>
Message-ID: <1304181143.38.0.500156763216.issue11966@psf.upfronthosting.co.za>


New submission from Andreas St?hrk <andy-python at hammerhartes.de>:

The example says "PyModule_AddConstant" instead of "PyModule_AddIntMacro". Attached is a patch for 3.1 branch, but it applies to all branches.

----------
assignee: docs at python
components: Documentation
files: PyModule_AddIntMacro_doc.patch
keywords: patch
messages: 134879
nosy: Trundle, docs at python
priority: normal
severity: normal
status: open
title: Typo in PyModule_AddIntMacro's documentation
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21843/PyModule_AddIntMacro_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11966>
_______________________________________

From report at bugs.python.org  Sat Apr 30 18:34:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Apr 2011 16:34:12 +0000
Subject: [issue11964] Undocumented change to indent param of json.dump in 3.2
In-Reply-To: <1304178435.78.0.522459822796.issue11964@psf.upfronthosting.co.za>
Message-ID: <1304181252.74.0.414441324431.issue11964@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> This change was made by Raymond in issue 5729.  It is the only feature
> added by that patch; the missing versionchanged was an oversight and I
> don't think it makes any more likely that other features were added
> that weren't documented.
Ah, I?m relieved, thanks.  I can fix it but I don?t know when I?ll be able to push again.

> If you are updating doc strings, note that there is more than one
> docstring that mentions indent and all should be updated.
I?m aware of that: ?This probably applies to the doc and docstring of the classes implementing dump too?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11964>
_______________________________________

From report at bugs.python.org  Sat Apr 30 19:31:39 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Sat, 30 Apr 2011 17:31:39 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1304184699.31.0.641045772144.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

final python wrapper script :

$ cat python
#!/bin/bash
ME=$0
ME=${ME##*/}
VERSION=${ME#python}
VERSION=${VERSION:-2.7.1}
ARCH=`uname -m`
CMD=''
case $ARCH in
  i686)
     CMD="/usr/bin/32/${ME}"
     ;;
  *)
     CMD="/usr/bin/python${VERSION}.bin"
     ;;
esac
for((a=1;a<=$#;a++));do CMD="${CMD} '$(eval 'echo -e "$'$a'"' | sed 's/['"'"']/'"'"'"'"'"'"'"'"'/g')' " ;done
eval "exec $CMD"


now handles:

$ ./python -c 'import os
import sys
import commands
print commands.getstatus('"'"'/.'"'"')
'
drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Sat Apr 30 20:14:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Apr 2011 18:14:14 +0000
Subject: [issue11966] Typo in PyModule_AddIntMacro's documentation
In-Reply-To: <1304181143.38.0.500156763216.issue11966@psf.upfronthosting.co.za>
Message-ID: <E1QGEgF-0004aX-RK@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset b3e7ffe6d727 by Benjamin Peterson in branch '3.1':
fix function name in example (closes #11966)
http://hg.python.org/cpython/rev/b3e7ffe6d727

New changeset fb709d9fe92a by Benjamin Peterson in branch '2.7':
fix function name in example (closes #11966)
http://hg.python.org/cpython/rev/fb709d9fe92a

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11966>
_______________________________________

From report at bugs.python.org  Sat Apr 30 22:25:48 2011
From: report at bugs.python.org (Prashanth Raghu)
Date: Sat, 30 Apr 2011 20:25:48 +0000
Subject: [issue11964] Undocumented change to indent param of json.dump in 3.2
In-Reply-To: <1304178435.78.0.522459822796.issue11964@psf.upfronthosting.co.za>
Message-ID: <1304195148.31.0.553544645929.issue11964@psf.upfronthosting.co.za>


Prashanth Raghu <p.is.prashanth at gmail.com> added the comment:

The .rst file that was downloaded as of 30-04-2011 (dd-mm-yyyy) had the updated doc .

----------
nosy: +Prashanth.Raghu

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11964>
_______________________________________

From report at bugs.python.org  Sat Apr 30 22:36:59 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Apr 2011 20:36:59 +0000
Subject: [issue11901] Docs for sys.hexversion should give the algorithm
In-Reply-To: <1303410263.92.0.721904855375.issue11901@psf.upfronthosting.co.za>
Message-ID: <E1QGGuJ-0005TH-Fu@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 34d2fb56de9a by R David Murray in branch '2.7':
#11901: post-commit review fixes per Georg Brandl
http://hg.python.org/cpython/rev/34d2fb56de9a

New changeset 2ddb4d6f826a by R David Murray in branch '3.1':
#11901: post-commit review fixes per Georg Brandl
http://hg.python.org/cpython/rev/2ddb4d6f826a

New changeset 591a09cf9e62 by R David Murray in branch '3.2':
Merge #11901: post-commit review fixes per Georg Brandl
http://hg.python.org/cpython/rev/591a09cf9e62

New changeset ca8e2fe68ecb by R David Murray in branch 'default':
Merge #11901: post-commit review fixes per Georg Brandl
http://hg.python.org/cpython/rev/ca8e2fe68ecb

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11901>
_______________________________________

From report at bugs.python.org  Sat Apr 30 23:21:04 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Apr 2011 21:21:04 +0000
Subject: [issue11883] Call connect() before sending an email with smtplib
In-Reply-To: <1303246763.2.0.10135500331.issue11883@psf.upfronthosting.co.za>
Message-ID: <E1QGHb5-00085a-0D@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 5c61c1d583fd by R David Murray in branch '3.2':
#11883: replace incorrect call to sendmail with correct call to send_message
http://hg.python.org/cpython/rev/5c61c1d583fd

New changeset fcfaeab42f6e by R David Murray in branch 'default':
Merge #11883: replace incorrect call to sendmail with correct call to send_message
http://hg.python.org/cpython/rev/fcfaeab42f6e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11883>
_______________________________________

From report at bugs.python.org  Sat Apr 30 23:29:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Apr 2011 21:29:40 +0000
Subject: [issue11883] Call connect() before sending an email with smtplib
In-Reply-To: <1303246763.2.0.10135500331.issue11883@psf.upfronthosting.co.za>
Message-ID: <E1QGHjP-00005p-1O@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a9cb47d0241e by R David Murray in branch '2.7':
#11883: fix email examples by adding 'localhost' to SMTP constructor calls
http://hg.python.org/cpython/rev/a9cb47d0241e

New changeset 00ff8825f551 by R David Murray in branch '3.1':
#11883: fix email examples by adding 'localhost' to SMTP constructor calls
http://hg.python.org/cpython/rev/00ff8825f551

New changeset 0f14dd4e644e by R David Murray in branch '3.2':
Merge #11883: fix email examples by adding 'localhost' to SMTP constructor calls
http://hg.python.org/cpython/rev/0f14dd4e644e

New changeset cfc02e132c12 by R David Murray in branch 'default':
Merge #11883: fix email examples by adding 'localhost' to SMTP constructor calls
http://hg.python.org/cpython/rev/cfc02e132c12

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11883>
_______________________________________

From report at bugs.python.org  Sat Apr 30 23:31:30 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 30 Apr 2011 21:31:30 +0000
Subject: [issue11883] Call connect() before sending an email with smtplib
In-Reply-To: <1303246763.2.0.10135500331.issue11883@psf.upfronthosting.co.za>
Message-ID: <1304199090.07.0.787734663276.issue11883@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The call to connect() is not required in the first example, since the hostname is passed to the constructor in that case.  Since these examples are about the email package rather than smtplib, I preferred to change the other examples to pass localhost to the constructor as well, rather than call connect with no arguments after a no argument call to the constructor.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11883>
_______________________________________